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
> 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.
> (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
> >> > 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
> >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)
> >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
> >Dr Robert Sanderson
> >Dept of Computer Science, University of Liverpool
> >Home: http://www.csc.liv.ac.uk/~azaroth/
> >Cheshire: http://www.cheshire3.org/