Following some discussion with Mike Rylander, Ross Singer, Jenn Riley
and Ryan Scherle off list, we came up with some thoughts following on
from the discussion below.

There should be an index (called for example cql.keywords) that is a
subset of the terms from the record, as determined by the server, with
the intent of providing an access point that acts like a general keyword
sort of search.  It might include points such as subject, title, author,
description, date, but not metadata level access points such as
the record's lastModificationDate or information about the current
physical location of the item and so forth.

Although this is possible via cql.serverChoice (as the server can choose
this sort of index) it's not guaranteed and the main tenet of the query
language is to foster specificity whenever possible.

If a server gets the query:

  cql.serverChoice = 2006

it can appropriately choose to search only dc.date, when the user
wants a very general search for 2006, but not so general as to extend to
things like the date the record was entered into the database (the
nature of 'generalness' being determined by the server) which would be
cql.anywhere.

For cql.serverChoice, the server could also choose a random index (say
an ISBN index) and get 0 hits for one query and then choose date and get
1000 hits next time.

However if the server gets the query:

  cql.keywords = 2006

It must choose the same index every time, it can't change based on the
term, whereas with cql.serverChoice this is quite legitimate.

cql.serverChoice is potentially unable to be scanned, as it can be
dynamically determined based on the term.  cql.keyword is able to be
scanned, as although it consists of a server determined set of terms, it
is a single, relatively persistent set.  cql.serverChoice will very
commonly be pointed at cql.keywords (as per Ralph's BasicIndex).
It's also not a default index, as you might default to a title search,
rather than a general search.

Rob

(discussion from: irc://irc.freenode.org:6667/#code4lib)


On Wed, 12 Jul 2006, Rob Sanderson wrote:

>On Tue, 2006-07-11 at 16:30 -0400, Ray Denenberg, Library of Congress
>wrote:
>> > 2) Add a bib.keywords index (or cql.keywords?), and note how it differs
>> > from cql.anywhere. This is reasonable,  but may be confusing.
>> It may be that the simplest approach is to simply define bib.keyword and let
>> the server decide what it maps to (and explain it in explain).   I don't
>> think this would be confusing.
>
>
>I think this is related to the serverChoice distinctions previously
>discussed.  In this case, the excludeOriginInfo is a data format
>specific way to improve relevance of very general searches.
>In other words: we don't have a particular index in mind, just search
>what you think is right, but not OriginInfo.
>
>Which is one of the definitions for cql.serverChoice.
>
>
>  http://listserv.loc.gov/cgi-bin/wa?A2=ind0501&L=ZNG&D=0&I=-3&P=4512
>
>
>Follow on a couple of messages and Ralph says:
>
>"I produce an index for my databases named BasicIndex.  It is the index
>that is searched when the user doesn't specify an index.  It is the
>union, more or less, of a number of subject rich indexes, but is by no
>means all the indexes.  It is the index that you get when you ask for
>cql.serverchoice."
>
>If you have half an hour, read through the rest of the thread as well
>which is enlightening, IMO.
>
>Therefore, I don't think that we need either bib.keywords or
>bib.excludeOriginInfo.  bib.keywords has the same semantics, as far as I
>understand exactly what is wanted, as cql.serverChoice (or
>cql.anyIndexes below)
>
>Compare:
>
>cql.allFields    -- Search all fields in the data
>cql.allIndexedFields - Search all indexed fields, exposed via CQL or not
>cql.allIndexes   -- search in all indexes exposed via CQL (n)
>cql.anyIndexes   -- search in any indexes you think appropriate (1..n)
>cql.anyIndex     -- search in any single index you think appropriate (1)
>cql.defaultIndex -- search in the index declared as default in Explain
>
>
>Rob
>
>--
>Dr Robert Sanderson
>Dept of Computer Science, University of Liverpool
>Home:     http://www.csc.liv.ac.uk/~azaroth/
>Cheshire: http://www.cheshire3.org/
>