> Date: Wed, 25 Feb 2004 18:14:47 +1100
> From: Alan Kent <[log in to unmask]>
>
> Does this therefore mean 'exact' should really be a relation
> modifier (not a relation)?
It is -- the relation modified "cql.string" is defined at
http://www.loc.gov/z3950/agency/zing/cql/context-sets/cql.html
in the default ("cql") context set to mean:
"The term is a single item, and should not be broken up."
So the "exact" relation is merely a convenient shorthand for
"=/cql.string".
>
> dc.title = 'fish' - keyword search
> dc.title =/exact 'fish' - string search (exact/complete value)
> dc.title > 'fish' - all title keywords after fish
> dc.title >/exact 'fish' - all titles after fish
>
> If I was relating CQL closely to Z39.50, I would have actually said
> [...]
> dc.title =/keyword 'fish' - guaranteed to be keyword search
This modifier also exists: it's called "cql.word".
> Regarding 'within', again worrying about Z39.50, how to know how to
> split the search term into two values? If its a keyword search, you
> can split on spaces: year within "2001 2003". If its exact value,
> how to parse the two terms out?
>
> dc.title within/exact "Fishing trips Jaws the movie"
I don't recall whether this made it into the official documentation
anywhere along the line, but consensus when we last discussed this
was that the way to parse a term with multiple values is specified by
a relation modifier (which functions in this case analogously to a
Z39.50 BIB-1 structure attribute). So for example:
dc.title within/cql.string/alan.EndpointsSeparatedBySlash
"Fishing trips/Jaws the movie"
(For convenience, the default structure when used with ordered indexes
is "endpoints separated by space", so that ``length within "10 20"''
Just Works.
> For CQL, I think the above may be ambiguous so a different syntax
> would be required (unless "TO" is made a reserved word in CQL).
I really, really don't want to go down that route. Such an extension
is unnecessary and would quite possibly break the grammar.
> Maybe...
>
> dc.title within/exact "Fishing trips" "Jaws the movie"
No. All of these ideas have been considered before and rejected in
favour of the approach we've chosen with relation modifiers indicating
how to parse a single term. Not least because this requires no
special cases, and generalises nicely to cases with more than two
bounding points:
location within/mike.polygonSpecifiedAsSpaceSeparatedListOfCommaSeparatedCoordinatePairs "0,0 10,0 10,10 0,10"
> Interesting issues. The above is canon fodder.
It's also recycled cannon fodder :-) This list does have a nasty
habit of perpetually revisiting issues it's already worked through. I
suppose I should take this as a well-deserved prod to rework the
tutorial.
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "The problem appeared after I changed the stack implementation
to a linked list instead of an array: you need that to speed
up deep halibuts" -- Steve "Haldane" Sykes on the joys of
ETA programming.
--
Listen to my wife's new CD of kids' music, _Child's Play_, at
http://www.pipedreaming.org.uk/childsplay/
