RE: [search-ws] container

["LeVan,Ralph" <levan@oclc.org>]

> From: Ray Denenberg, Library of Congress [mailto:rden@loc.gov] 
> Sent: Wednesday, April 07, 2010 6:00 PM

>> In the second example, it appears that cql.any can be used in the
>> "author" container.  If the intent was some sort of shorthand for
>> "author=jack prox/container=author author=jones", ...
> 
> I'm not even sure what that means, or whether it makes sense.  The intent is
> really fulltext searching. Find the string 'jack' and the string 'jones' within the
> same author field.  I don't think you mean cql.any, do you,  as that's a relation,
> not an index, and we're looking for an appropriate (abstract) index, aren't we?

Well, I've got cql.any as an index and have had it from the beginning.  It means that the server gets to choose the best index.

Specifically, in that example, there is no index specified.  That means that the server gets to choose and that's what I thought cql.any was.

 
> I would like to define a new (pseudo) index: 'text'.  Thus:
> 
> "text=jack prox/container=author text=jones"

What would you expect to happen if you saw simply "text=jack"?  I'd prefer not to go there.

In my implementation (not knowing if it is typical) proximity is implemented through indexes.  So, I'd say something like "firstName=Ralph prox/container=author lastName=LeVan" to find Ralph and LeVan in the same author field.  It could just have easily been "author=Ralph prox/container=author author=LeVan".  In either case, I would have expected there to be indexes to support the terms being searched.  The "container" is the object that I don't expect to be backed by a searchable index.

Ralph