(sorry hit send too soon)
Ralph suggests that instead of this:
(which is based on the bib context set with a partname modifier, possibly
defined in an openURL context set)
that this would be preferable:
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.
----- 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
> 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.