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

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

Wouldn't it be cleaner to just say that CQL itself has some few
"built-in indexes" in addition to "serverChoice" and "anywhere",
and it is these which are in force when no context is given?
Semantically, these abstract concepts would be restrictions on
"serverChoice". An un-contextualized "title" search would be
understood as "server choice, among indexes that are titles".

It seems to me this would be simply giving explicit recognition
to the semantics that will be implemented anyway. And, I see
this as a way to help solve the problem of having context sets
re-use concepts rather than inventing scads of new index names.

Eliot