(sorry hit send too soon)

Ralph suggests that instead of this:

 bib.NamePersonal=/bib.role=author/bib.roleAuthority=marcrelator/
 sap.namepart=last "Orwell"

(which is based on the bib context set with a partname modifier, possibly
defined in an openURL context set)

that this would be preferable:

sap.aulast="orwell"

Which would mean defining an actual index for aulast.

We did decide against the latter, defining explicit openURL indexes, but
that decision was more than a year ago and certainly can be revisited.

--Ray




----- Original Message ----- 
From: "Ray Denenberg, Library of Congress" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, June 14, 2007 10:25 AM
Subject: Re: Searching on OpenURL keys


> Given this exchange, and the suggestion from Ralph --- should we revisit
the
> decision we made a year ago?  Which was: don't define direct openURL
> indexes, instead define a mapping.   Ralph suggests: sap.aulast="orwell"
>
> ----- Original Message ----- 
> From: "Ross Singer" <[log in to unmask]>
> To: <[log in to unmask]>
> Sent: Wednesday, June 13, 2007 5:17 PM
> Subject: Re: Searching on OpenURL keys
>
>
> > Well, yes, this is more what I'm angling at, I guess (and more
> > diplomatically, thanks Ryan).
> >
> > Perhaps, rather than worry about a perfect mapping, we should focus on
> > a practical mapping between the two.
> >
> > There are quite a few indexes that the bib context set opens up that
> > are useful, especially in the context of OpenURL resolving (volume,
> > issue, etc. come to mind, atitle/jtitle as well - but these I see as a
> > quite a bit trickier).
> >
> > On 6/13/07, Scherle, Ryan <[log in to unmask]> wrote:
> > > But one of the reasons for creating the bib context set was to avoid a
> > > lot of specialized context sets like this.
> >
> > The only problem I have with this logic is that:
> > In many of the same places that SRU is trying to be implemented, we
> > are also trying to implement OpenURL, so why can't we make that
> > process as painless as can be?
> >
> > I understand abstracting this, certainly, but at some point
> > concessions need to made to the communities that actually want to use
> > this.
> >
> > -Ross.