On Thu, Sep 19, 2002 at 01:19:22PM -0400, LeVan,Ralph wrote:
> I don't have any interest in supporting an index that only allows single
> term searches.

I just wanted to say I agree with Ralph.

But changing tack slightly, I have a different question. (I might be off
track - I was not at the meeting so might be missing some semantics here.)

It seems to me that existing Z39.50 implementations have not really agreed
on what all the different Bib-1 attributes etc mean. So I am a little wary
about defining the DC indexes in terms of Bib-1 attributes. Won't that be
buying into the old arguments about what Bib-1 means, when there is not
really concensus there (in terms of implementations anyway)?

Would it therefore instead be better to define the semantics of the indexes
independently of attribute lists. That is, define how it should behave.
*Example* or *recommended* attribute lists could be given, but I would
rather not rely on the attribute list semantics to dictate the CQL
semantics.

This would allow individual implementations to choose the appropriate
attribute list per server implementation. For example, we use 'phrase'
to implement 'wordAdjacenyList' now (if I understand it correctly).
[In fact, our server treats 'word' and 'phrase' identically - if the
client only sends one term, fine. If they send multiple, fine - we will
do an adjacency query for them. Since clients don't know the word parsing
rules a server uses, this gives the best results (for example, is
'fine-grained' one word or two in an index? Different people may
index it differently. We generally index it as two words then do an
adjacency query.) But I am digressing.]

My point is, I don't think you will get universal consensus in existing
Z39.50 implementations as to what attributes mean. So define CQL etc with
nice clean semantics, and allow flexibility in mapping those semantics
onto existing servers. Provide suggested attribute lists to make things
clearer, but don't rely on Bib-1 attribute semantics to define CQL
semantics. (Someone might want to bind CQL onto SQL for example and so
never go anywhere near attribute lists...)

Sorry if I have missed the point.
Alan