Karen 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 think that the point about using the ILS as the 'link resolver' is
actually really about where you store the data from which you generate a
list of services for the user.
Jonathan has argued (and I've disagreed) that the ILS is where we should
store 'journal holdings' type data, and so, the software which presents
services to the user should be able to easily look up journal holdings
data from the ILS when offering services of this type.
The question is why do we currently have two 'knowledge bases' (to use
SFX jargon) rather than a single one for journal holdings. I'm arguing
that we should consolidate in the Link Resolver, Jonathan argues we
should consolidate in the ILS - we both agree (I think) that we need to
consolidate.
I would agree with Karen that I'm not sure that I see the logic of
making the ILS the link resolver (add yet another system to something I
would argue we ought to be dis-aggregating?), but I agree that making
the ILS the 'Knowledge Base' for holdings information could make sense.
Owen
PS - one final thought, support for transporting holdings across z39.50
etc can be done, but seems to have been patchily implemented across ILS
software - see Ross's comments on what they did with Voyager when they
were getting it to work with Umlaut.
Received on Tue Sep 11 2007 - 10:40:06 EDT