On Fri, 27 Aug 2004, Eliot Christian wrote:
> At 03:50 AM 8/27/2004, Theo van Veen wrote:
>> I agree, but the solution is that when not specifying the dc. prefix, it
>> is up to the server to choose an index. So when you specify "title" it
>> is up to the server to use this as bath.title or dc.title or both. This
>> is part of the SRU specs but - when it does not lead to ambiguity - the
>> support of this feature should be encouraged.
> Yes, as Rob pointed out, the mere fact that no context was specified
> does not change the semantics. Referencing the index "title" on
> a server with the default context set of "dc" is just a shorthand
> for "dc.title".
The CQL rule is:
"An index name always includes a base name and may also include a prefix,
the name of the context set of which the index is a part. If not supplied,
the default context is determined by the server. If no index is supplied,
then it is determined by the server."
There's nothing to say that the server -has- to use a single default
context set. For example, a server could have a default of dc, but if I
send 'anywhere' it would be handy and appropriate if it decided to use
'cql.anywhere' rather than the non-existant 'dc.anywhere'
However it doesn't allow the server to choose multiple indexes that have
the same name in different context sets.
> (BTW, I find the word "default" a bit ambiguous. It seems to be
> implied that the CQL context set itself is "the default", see
> http://www.loc.gov/z3950/agency/zing/cql/context-sets.html )
It is the default for everything other than indexes.
So when we say:
dc.date >/isoDate "2004-08-26"
we actually mean:
dc.date cql.>/cql.isoDate "2004-08-26"
(But don't put that into a CQL parser because 'cql.>' isn't legal)
,'/:. Dr Robert Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. University of Liverpool
____/:::::::::::::. L5R Shop: http://www.cardsnotwords.com/
I L L U M I N A T I