> >'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.

A few examples from the MARC spec where you would need this to do
certain searches:

marc.260:1=3 means current/latest publisher whereas
marc.260:1=2 means intervening publisher

marc.270:1=1 AND marc.270:2=0 means primary mailing address
marc.270:1=2 means secondary (unspecied type) address
 
marc.545:1=0 means biographical data
marc.545:1=1 means historical data

marc.852:1=0 means location using Library of Congress classification
marc.852:1=1 means location using Dewey Decimal location

marc.650:2=0 means subject (topical) in LCSH
marc.650:2=1 means subject (topical) in LCSH (Childrens)
marc.650:2=2 means subject (topical) in MESH

etc.

> >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.

Oh, clearly the obvious disjunction isn't that obvious. I didn't want to
have to type out the following in full, but if you wanted to do
marc.500$a any/indicator1 any "1 2 3" "baz", you could use this query:

marc.500$a any/indicator1="1" "baz" OR marc.500$a any/indicator1="2"
"baz" OR marc.500$a any/indicator1="3" "baz"
 
> >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.

Errr not in your original e-mail (unless there's another Rob Sanderson
about (see below) - not least of all because we hadn't been discussing
such cases at that point!

> -----Original Message-----
> From: SRU (Search and Retrieve Via URL) Implementors 
> [mailto:[log in to unmask]] On Behalf Of Rob Sanderson
> Sent: 28 November 2005 14:19
> To: [log in to unmask]
> Subject: Re: CQL and Marc record fields
> 
> > Also for indicators you may want to form a query of the form 
> > marc.245$a = "Smith" where the Indicator1 = 4 Which isn't 
> the same as 
> > marc.245$a = "Smith" and marc.245i1 = 4 (as this does not 
> imply that 
> > the second operand applies to the same marc field as the first).
> > 
> > Hence for indicators is seems likely that these would have to be 
> > handled by relational modifiers.
> 
> A cleaner version is:
> 
>   marc.245$a = "Smith"
>     prox/unit=element/distance=0
>   marc.245i1 = "4"
> 
> See also the discussion on the ZeeRex context set concerning 
> searching for attributes with an attribute set.
> 
> One issue with putting sub-searches in relational modifiers 
> is that the following query is invalid:
> 
>   marc.245$a =/marc.245i1 any "4 6 8" "Smith"
> 
> as 'any' cannot be used as the central token of a relational modifier.
> 
> Rob
> 
> --
> Dr Robert Sanderson
> Dept of Computer Science, University of Liverpool
> Home:     http://www.csc.liv.ac.uk/~azaroth/
> Cheshire: http://www.cheshire3.org/
> ------------------------


> >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

I took that as read!

Matthew