I pretty much agree with all of this.

Robert Sanderson writes:
 > 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/
 > >