Addressing a few points...
Alan Kent wrote:
> To me one of the main potential benefits of SRW
> is to get away from the current vagueness of Bib-1 etc attributes.
> I think SRW should define clear semantics that should be possible
> for different implementations to map on to Bib-1 etc. But not
> everyone agrees on what Bib-1 attributes mean, so how can you
> come up with a single SRW definition if mandates Bib-1 bindings?
I'm leaning in the direction of a preference towards the attribute
architecture over bib-1 as providing a model for srw semantics (if AA isn't
providing clear semantics then we are in trouble).
We all do agree (?) it's legitimate to define an index as a "choice", for
example to say it corresponds to one of the following attribute
1. combination A
2. combination B
Now if combination A is bib-1, and B is AA, then if a server chooses B as
its representation, then it's going to be clearer what that index is, and
if it chooses A it's going to be less clear. (And as a by-product of this
process maybe the Z39.50 community will have more motivation to move to
attribute architecture, but that's not really the point; the point is that
there will be a way to express the intended semantics of the index.) (And,
as a second parenthetical note, this doesn't apply for an index we're
trying to represent but whose definition is the responsibility of some
other body, for example, Bath.)
And I don't think that binding is an issue. We're just talking about
definitions. Binding, as far as I can see, comes into play only when there
is a Z39.50 server behind the srw server. So the binding is going to be
> I also disagree that SRW's existance mandates a Z39.50 basis.
> Its a natural fit, sure. But I don't see why it should mandate
> Z39.50 behind the scenes.
What I'm saying is that srw's existence mandates *the possibility of*
Z39.50 behind the scenes, not that it *mandates Z39.50 behind the scenes*.
We have to be able to say how a given srw search can be represented in
Z39.50. We're not saying that every srw search will be turned into one.
Robert Sanderson wrote:
> 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.
That just seems to me too complicated and too confusing. If you want an
"all these words" search, there's a very straightforward way, using AA: the
utility set format/structure attribute "allTheseWords". We would define an
index "dc.titleAllWords" as such, in terms of AA only, that is, with no
bib-1 mapping. If you need to map it to bib-1, you do a boolean search.
> 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.
If you want "any of these words" , there's an "anyOfTheseWords" attriubute
too. I'm not sure that's what you want for relevance though. But the
requirement to "map" to Z39.50 is not per index, it's per search. CQL has
a relevance relation, and so does AA, so there's an obvious basis for
mapping there. It might be that AA doesn't have exactly the right attribute
for this, so I would prefer to add it to AA ("some of these words" or
"relevant words" or "set of words") rather than fake it. (I don't know
why we added these to format/structure and not expansion/interpretation but
we can deal with that separately.)