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
>
> 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
> ------------------------------------
>
--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu
Received on Tue Sep 11 2007 - 11:48:40 EDT