openurl discussion on NGC4LIB mailing list

[Ashley Sanders <a.sanders@manchester.ac.uk>]

Just copying some discussion off the NGC4LIB mailing list concerning
OpenURL, Holdings information and Z39.50/SRU.

What the message below seem to me to be saying is that they'd
like to fire an OpenURL at something and get a list of
Holdings in return. That something possibly being Z39.50 or SRU.

Ashley.

---- Message from Karen Coyle -------------------------------------

Jonathan Rochkind wrote:
 > Karen Coyle wrote:
 >> Can you elaborate on this Eric? It sounds interesting, but I don't know
 >> what you mean by having the OPAC be a resolver. Probably an example
 >> would help me.
 > Well, all a 'link resolver' is is something that takes an OpenURL, and
 > provides a web page to the user with information/services about the
 > citation in that OpenURL.
 >
 > So the ILS/OPAC should be able to take an OpenURL, and provide
 > information to the user on the holdings that match that citation that
 > are controlled by the ILS. The ILS already has information in it about a
 > LOT of our holdings.

Isn't that what Z39.50 does for us? (Or SRU/SRW). I think of the link
resolver as doing more than returning holdings - in fact, it should be
able to offer a range of services. I suppose we could add that to the
catalog, but a lot of the things we want services around aren't in the
catalog -- that's kind of how link resolvers got started. And I think
that many of them do query the catalog when that's appropriate.

kc
-- 
-----------------------------------
Karen Coyle / Digital Library Consultant
kcoyle@kcoyle.net http://www.kcoyle.net
ph.: 510-540-7596   skype: kcoylenet
fx.: 510-848-3913
mo.: 510-435-8234
------------------------------------

---- Message from Eric Lease Morgan -------------------
On Sep 11, 2007, at 1:23 PM, Jonathan Rochkind wrote:

 >> Isn't that what Z39.50 does for us? (Or SRU/SRW).
 >
 > Well, it's perhaps what they are _supposed_ to do for us.

Psst. SRU/SRW are not necessarily designed to return holdings.
Instead, they are protocols designed to interface with indexes. Send
a query. Return a list of hits. Using SRU/SRW to return holdings
would be a novel use of the protocol; using SRU/SRW for this purpose
would be akin to using something like OpenSearch for this purpose.

-- 
Eric Lease Morgan
University Libraries of Notre Dame

-----Message from Ross Singer ---------------------------------

On 9/11/07, Karen Coyle <kcoyle@kcoyle.net> wrote:

 > > Isn't that what Z39.50 does for us? (Or SRU/SRW). I think of the link
 > > resolver as doing more than returning holdings - in fact, it should be
 > > able to offer a range of services. I suppose we could add that to the
 > > catalog, but a lot of the things we want services around aren't in the
 > > catalog -- that's kind of how link resolvers got started. And I think
 > > that many of them do query the catalog when that's appropriate.

I don't think it's unreasonable, however, to think that we should be
able to send an OpenURL to an ILS and it give back a response
(preferably machine-readable, IMO) as to whether or not that
particular 'thing' is in 'the catalog'.

The problem with falling back to Z39.50 and SRU is that 1) these
interfaces would need to be configured to work with holdings and 2)
the OpenURL (which is the more 'standard way' in our current landscape
to ask for a specific item) which we already have would need to be
expressed in RPN or CQL (which then have to parsed and translated into
something that makes sense to the ILS in question).

This would vastly improve the catalog's presence in the current
incarnation of link resolvers, if nothing else.

-Ross.

-------Message From Jonathon Rochkind ------------------------
Karen Coyle wrote:
 > Jonathan Rochkind wrote:
 >> So the ILS/OPAC should be able to take an OpenURL, and provide
 >> information to the user on the holdings that match that citation that
 >> are controlled by the ILS. The ILS already has information in it about a
 >> LOT of our holdings.
 >
 > Isn't that what Z39.50 does for us? (Or SRU/SRW).
Well, it's perhaps what they are _supposed_ to do for us. Have you tried
to use them to answer link-resolver type questions in confident
machine-readable ways?   You will find it amazingly horrible.

But yes, _if_ the Catalog/ILS were capable of answer these questions
properly with either of those interfaces, then simply adding on an
OpenURL input interface would indeed be trivial (which doesn't mean our
vendors would do it).
 > I think of the link
 > resolver as doing more than returning holdings
Well, different link resolvers provide different services. I am fairly
confident in saying that links to electronic full text is the number one
service that our users are interested in, the biggest priority to do
right.  But yeah, I'm interested in other services too. I think making
the 'get me access to a copy' service work as well as possible is number
1 priority though, and right now it doesn't work nearly as well as it
ought to.
 > - in fact, it should be
 > able to offer a range of services. I suppose we could add that to the
 > catalog, but a lot of the things we want services around aren't in the
 > catalog -- that's kind of how link resolvers got started.
Is that really how link resolvers got started? I thought link resolvers
got started to handle the 'appropriate copy' problem--that is, to find
full text.  Why couldn't our existing ILS/OPACs handle this?  1) It
required a standard for submitting citation information, such as
OpenURL, that none of our existing software handled (and to this date
ILS/OPACs typically don't). 2) It required the software to have access
to a 'knowledge base' of electronic holdings. Few of our libraries were
actually succesfully maintaining this information in our catalogs, which
is why the link resolver business ended up actually being in large part
about the outsourcing of this management 2b) Even if we DID manage to
keep all that info up to date in our catalogs, our catalogs are mostly
not capable of storing and providing that data broken down into the
machine readable parts neccesary to provide an answer to 'do we have
access in any medium to this article citaton', which is what the
'appropriate copy' problem is all about.

 > And I think
 > that many of them do query the catalog when that's appropriate.
Well, they try. Most of them don't do it very well.

But yes, I don't think it's important exactly what piece of software
holds this information, or exactly what that piece of software is
called. What is important is:
1) We provide that information to the user at the point of need in an
integrated holistic fashion. Not "look in one place for print and
another for electronic." We are not currently very good at doing this.

2) We provide back-end workflow support that actually supports a sane
workflow. Not "enter the same information multiple places, and exactly
where it's entered depends on whether it's electronic or print and a
bunch of other factors that it shouldn't depend on." We are not good at
doing this.

3) The data is kept in such a way that it can be querryed through a
single integrated holistic sane API, not look one place with one kind of
hack to get print data, and another place with another hack for
electronic serials, and yet another for e-books, etc. etc." And yeah,
this is currently horrible.

To some extent it's a red herring which part of the environment you call
a 'link resolver' and which part you don't. Personally I think it makes
most sense to use the phrase 'link resolver' to refer to _any_ service
that takes an OpenURL and provides any kind of response---hopefully a
machine readable one that can be aggregated. That is to me most in
keeping with the domain the term is currently applied to.

I also think anyone that thinks our commercial link resolver products
are right _now_ capable of providing significant progress toward those
1,2 and 3 above---if only we used them in the right way... I think
that's sadly mistaken. But I would love to be proven wrong.

Jonathan
-- 
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu

----------------------------------------------------------

-- 
Ashley Sanders               a.sanders@manchester.ac.uk
Copac http://copac.ac.uk A Mimas service funded by JISC