As I'm completely out of step here in Japan, I'll reply to multiple
messages at once.

Mike (paraphrased):
You can't do word searches in string indexes because of multiple white
space characters.

String indexes with no normalisation, correct.  If by String we mean the
exact characters in the field, then this won't work.  If there is
normalisation applied before indexing, then it would.  I mean, who doesn't
strip new lines before indexing?? Perhaps because we work with XML as our
native format this has just never come up as whitespace is irrelevant past
the first.  I accept the argument for non XML file formats though.

The implication is that we need a beginning of field anchor to be used in
a fooWord index to get 'first words in field'.

Ralph (paraphrased):
Word indexes maintain relative position.

Why?  This is your implementation's version of a keyword index, but we
deal with multi megabyte full text documents.  For these, building
proximity indexes takes a long time and uses a lot of disk space.
For some types of index (as above) proximity is not really feasable.

I suggest an explain tag per index which records if it supports proximity
or not.  If it doesn't then a multi word search term would be treated as
implicit AND as oposed to implicit PROX.


On Fri, 20 Sep 2002, Ray Denenberg wrote:

> 1. srw indexes must map to Z39.50 attribute
> combinations.  I understand the philosophical

Okay, but at least don't expect that these will be readily available in
machine readable form.  For example, as below, 'we just point to the
profile' -- there's no machine readable version of the bath profile to
point to.

Perhaps some people will do it, but client writers will -certainly- have
to deal with servers that don't, so probably will just not bother even
when they are available as it's just extra network transfers and parsing.

Consider how well Explain Classic was implemented. ALmost no one did it.
We can ask for one level of explain, as it serves a real purpose. But two
levels of explain is just not a realistic expectation.

> 3. If we accept Ralph (and Rob K.) 's view of
> string and word indexes, I don't really see that
> this presents major limitations for those who take
> the different (I.e. Rob S.'s) view.  If you want
> to accept only single-word terms, fine.

I don't mind multiple word terms, I don't like the current implicit
operator between the words.  In fact, I think it should be specifiable per
index.  A date index searched with multiple terms ... obviously not a
proximity search, possily a range search, or an AND search or an OR search
depending on the data (eg birthdate would be OR, others might be AND, and
a lot would be range)
A 'relevance' search should be OR not PROX or AND -- I want things which
are relevant, not necessarily contain all of the words specified.  Many
more examples are easily constructed.


My Position:

*  Define a beginning of field character (^) and end of field character
($) for use in adjacentWordList searches to get first and last words in
field searches.

*  Define the implicit operator in Explain.

*  Don't assume that all servers will have the second level Explain
definitions for Z attributes, even if the spec requires it.


Rob
--
      ,'/:.          Rob Sanderson ([log in to unmask])
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      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