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