> I do not like the "=^" and so on proposal. Again this is mixing
> user interface and protocol. "=^" adds nothing to the functionality
> of the protocol. It is an idea for a new style of user interface.
> protocol. Let the server do it's magic.
There is one case in particular where I feel that the requirement of one
word per term is not sustainable. This is using a relevance query to find
similar records to the one that the user requested. We have a server side
mechanism for this, but in a distributed environment this doesn't work so
we have to create very long lists of the interesting terms from the record
and submit the search across multiple servers and then rerank the records
by relevance after getting them all back.
So in CQL our query currently would look like:
description =~ "art history medieval manuscript 14th century froissart
french painter historian ....."
If this had to be split up into one word per term:
(((((description =~ "art" OR description =~ "history) OR description =~
"medieval") OR description =~ "14th") OR description =~ "century") OR
description =~ "froissart") ...
There are times when non adjacent word lists are very important and this
(IMO) is one of them.
Given that one word per term is not a realstic option, I think that
Mike's set of operators are the best. In particular from Ray's set I
think that '= =' is too much of a pain to parse with the space in it.
Is the use of ^ and v from set notation? I'd be happy just with =* etc but
have no concrete arguments apart from the '= =' one.
Especially as no users will really be entering this directly.
,'/:. Rob Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I