If people are going to just define attribute combinations once per
indexSet (which is true) and you suppose that this will happen rarely
(which I think is debatable) then why does it need to be machine readable?
If there's only a similar number of indexSets as there are Attriute sets
in the AA, then why bother?

Let's have the combinations around for us Z39.50 folks who like things
like that, but not force it on Amazon or Google if they want to
standardise on SRW instead of their proprietary interfaces.

If we wanted attributes, why wouldn't we just use Matthew's SOAP binding
for the Z39.50 PDUs rather than reimplementing everything from scratch.
There's no savings currently and it's impossible to recommend it to anyone
outside of the Z39.50 community, and surely that's the goal here?

Rob

On Tue, 24 Sep 2002, LeVan,Ralph wrote:

> > -----Original Message-----
> > From: Alan Kent [mailto:[log in to unmask]]
> > Sent: Sunday, September 22, 2002 10:11 PM
> > To: [log in to unmask]
> > Subject: Re: index definitions
> >
> > This may be what this list agrees to, but personally I disagree
> > with this point. 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?
> >
> > Hence I prefer mandating semantics of the SRW queries, then
> > providing *suggested* Bib-1 etc bindings. Maybe the new attribute
> > set stuff is better here, but SRW relying on agreement as to
> > what Bib-1 means is doomed to failure I suspect.
>
> There are a number of issues being raised here, so lets try to untangle
> them.
>
> First, it is critical that we have some mechanism to transmit the semantics
> of the indexes.  When I say that I have a SubjectHeading index, what does
> that mean?  Is there some way that I can clue a client in that it is a MeSH
> subject index?  The new attribute architecture was about just that.  It
> provides the mechanism to explain the rich semantics of an index.  I want to
> use that mechanism somehow.  There is no point in having all these tools and
> then miscommunicate that the Title index in my heraldry database doesn't
> have document titles in it.
>
> Our IndexSet definitions must find some way to use this mechanism to explain
> the database.  But, IndexSets only get defined once and then reused by the
> rest of us.
>
> The next problem is for a local site to define what subset of the IndexSet
> it supports.  I've been building a trivial variant of my IndexSet schema
> called IndexSubset.  It is identical to IndexSet, with an attribute on the
> IndexSubset root element that points to the IndexSet that it subsets.  The
> rest of the IndexSubset just lists the indexes that are locally supported.
>
> I am also using the IndexSubset to provide the mapping from Indexes to
> z39.50 attributes.  That mapping should not be mandatory in the schema and
> can be ignored by any client that wants to.  I do that so that I can use the
> file to configure my code, not to provide semantics to the client.  It can
> get the semantics of the indexes from the original IndexSet.
>
> Hopefully, with these clarifications, we can stop talking about the admitted
> weaknesses of Bib-1.
>
> Ralph
>

--
      ,'/:.          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