First I have to say that I appreciate the work being done on CQL and
Explain. Nevertheless I think that we should make use of some new
opportunities now we are defining a new query language.

First as a reaction on Ralph:

>So, if I support both dc.title and bath.title and you send me
>unqualified title, what do you expect me to do?  It just so happens
>that I specified in my explain record that the default index set was
>bath, but what if you were expecting it to be dc?

What should the client do in this case? Explain to the user that
there are different sorts of titles? Or just make an arbitrary choice
for the user?

Reaction on Ray:
> > Can anyone explain to me the added value of distinction between
> > dc.title and bath.title in CQL.
>
> Well for one thing,  that there is no Bath.title; there are
> .bath.titleWord, bath.titleWordRT, bath.titleExact,
> bath.titleFirstWords, and bath.titleFirstCharacters.
>

I simplified my example but that does not effect my point.

> We haven't defined DC abstract indexes yet but it's likely that there
> will be a single title index for dc title: "dc.title"  which will be
> defined in terms of a single use attribute, title, with no other
> attributes listed (or it may be defined in terms of the cross domain
> set) or it may just be defined as "a dublin core title", which, in
> some sytems, means a different index than a Bath title.

dc is defined for description and not for searching. Using the prefix
dc as search attribute prefix is wrong, when it is being used in this
way. But if it is supposed that a user will have a general
understanding that dc.author means author, because he has an
understanding of author, the prefix is not relevant and even
misleading. It could mean that it was the indexed field that was
originally called dc.author in the origial record but as a user I don't
not care whether it was the index of dc.title or for example MARC
tag 100.

> > In my point of view not supporting Ralph's premises means
> > not supporting prefixes. Or did I misunderstood previous
> > discussions and
> > is everyone already on this track?
> Yes, I think you misunderstood.  I believe the consensus is
> this:
> 1.There will be some well-know prefixes, e.g., bath and dc, and
>    you  won't have to use Explain to discover  a server-specific
>   definition  for these.

In this case a client has to know the prefix exactly. Searching for
"dc.title:abc or bath.title:abc"  will return an error message if one of
both is not supported.

> 2.A server is free to define server-specific prefixes (as
>    long as they don't clash with the well-known prefixes) and you
>    might have to use explain to discover those.

In distributed searching I do not think any client will search for
prefixes or indexes that it doesn't know.

> 3.You can send an index name
>    without a prefix, but in that case the server applies the default
>    prefix, and you'll need to use explain to find out what that is for
>    a given server (there won't be any global-default).

This is all I want: reasonable defaults. But I am not able to write
clients that are intelligent enough to find out whether the servers
default corresponds to the users expectations.

> 4.Distributed  searching is theoretically possible, but all indexes
>    should have well-known prefixes. (Or, you could send non-
>    prefixed indexes to  different servers but you cannot assume
>    that they mean the same thing to different servers.)
> --Ray

What (default) prefixes should be used in distributed searching?
Ralph will return an error message if I try "dc.title:abc or
bath.title:abc". Why isn't the default just no prefix?

I have the strong feeling that we are currently on the wrong track.
We are mixing up Z39.50 attribute sets with dc name spaces, while
the solution is quite simple: use user understandable names for
search fields. It is possible in Dublin Core for description, why is it
not possible in CQL for searching?
The abstract Z39.50 attributes were usefull in case of MARC
descriptions, but in line with Dublin Core  I think we should map the
Z39.50 search attributes to user understandable names instead of
sticking to the attributes.

Theo
Theo