Sorry, yes.  I'm referring to the particular example you made.

There was a lot of resistance to the overhead that OpenURL 1.0 brought over 0.1.

You have just presented one scenario (how to search from rft.aulast to
cql) and that is an order of magnitude more complex.  My argument is
that nobody is going to do that and carve out either:
1) a direct mapping in something like CQL that uses Z39.88 SAP keys
2) throw their hands in the air and adopt OpenSearch with Lucene
syntax or something

I truly don't mean to sound snarky with this, but how arcane can we
make this spec?  If we expect adoption and uptake (and, quite frankly,
there are considerably more OpenURL enabled sites than SRU, I'd wager
- and the truth is that they have rft.aulast and not rft.au
specified), the path to adoption won't happen if the spec is this
obtuse.

This next statement is not meant as OpenSearch advocacy, but: the
argument I repeatedly hear for SRU is the sophistication of its
searching capability.  Are there any examples of where the sort of
search, bib.NamePersonal=/bib.role=author/bib.roleAuthority=marcrelator/sap.namepart
=last  "Orwell", is technically feasible that has high user satisfaction?

Are there any examples of highly granular SRU services that have high
user satisfaction?  And if there are (and I'm certainly not saying
there aren't), what sorts of purposes did these services serve?

-Ross.
On 6/12/07, Ray Denenberg, Library of Congress <[log in to unmask]> wrote:
> From: "Ross Singer" <[log in to unmask]>
> > No, I get the utility to mapping an OpenURL to SRU for a variety of
> reasons.
> >
> > I guess what I don't see is how you're going to sell this particular
> > syntactical mapping to OpenURL enabled SRU providers.
>
> I'm not following you Ross.  By "this particular syntactic mapping" are you
> refering to the specific example I gave?  It's just a hypothetical example.
> None of this mapping is developed yet. Or are you referring to basing the
> mapping on the bibliographic indexes we're developing?
>
> --Ray
>
>