>> It does make sense in some cases and it doesn't in other
>> cases. That we can at least make a reasonable showing of the
>> syntactic searching is good, and that it becomes very
>> complicated when you want to mix semantics and syntax is
>> quite understandable.
>'Records containing MARC 500 field with an indicator1 value of 1 and a
>$a subfield which contains "baz"'
You proposed this as a requirement, rather than the person asking about
the CQL and MARC. I'd like to hear if this is actually a requirement or
not.
>Not an overly complex requirement
Given that it
>was felt to be a misuse of relational modifiers and would not allow
>marc.500$a any/indicator1 any "1 2 3" "baz" (although you could expand
>that to the obvious long disjunction).
How? You can't put boolean OR into a relation either.
>Rob suggested that
>marc.500$a any "baz" prox/unit=element/distance=0 marc.500:1 = 1
I suggested unit=element for cases where it was actually in the same
element.
>My rescue attempt of this which was
>marc.500$a any "baz" prox/unit=parent/distance=0 marc.500:1 = 1
>equally unreadable, went without comment as everyone got involved in an
>abstract philosophical debate on proximity in structural data...
I don't have any complaints about unit=parent, beyond that it should be
profiled rather than put into CQL itself, as it leads to the inevitable
unit=grandparent, unit=greatgrandparent, unit=ancestor, unit=child,
unit=grandchild, unit=greatgrandchild, unit=descendant, etc etc.
Rob
|