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