Jonathan,
Thanks for the response - I'm still trying to think through some of
these issues, so please read the following as 'thinking aloud' rather
than me digging into my position.
That said, I think I've more or less convinced myself that (at my
institution) we ought to get our print holdings data into our link
resolver as a relatively simple step forward (whether this is as well,
or instead of in the ILS) - and assessing how much work this is and
thinking through the practicalities of doing it are probably the biggest
challenges here.
Now on with the debate...
Jonathan wrote:
>>Well, the ILS has support for work flow built into it for the staff
that
>>enters this information. Our link resolvers do not.
If we put the monograph issue to one side for a moment. I'm not sure
that our ILS really has much in the way of work flow for serials. Our
(i.e. the institution I work for, but I suspect more generally true)
holdings statements are manually entered, not generated from 'check in'
of issues. We could simply stop entering these into the ILS and rather
enter them into the Link Resolver.
As another part of this thread suggests, you could argue this the other
way round - if we simply started to enter machine parsable holdings into
our ILS then this could be used as the 'knowledge base'. I'm going to
argue for the existing link resolver knowledge base as the better place
to store the journals holding information because:
1) It already is where we store the vast majority of our holdings data
(albeit for e-journals, these make up the majority of our journal
holdings)
2) It has a lot of information about journals built in - alternative
titles, ISSN and eISSN, title abbrevations etc. It also works on the
basis of a single 'bib' expression for the journal, and then a
structured way of representing routes of access, so it is better
structured than our ILS to deal with journal type information
3) It is built specifically to answer the questions that our users want
the answer to in terms of journals - 'where can I get this
article/issue/volume?'
4) By using the link resolver we avoid getting caught up in discussions
about the MARC format for holdings (and changes required to make this
all work), the role of the ILS etc. It breaks the monopoly of the ILS,
but does it in a way that is clearly of real value to our users.
>>And as me and Karen
>>suggested before, we do not think current link resolver products are
>>actually up to it.
I can see this is an argument for monographs, but not for print journal
holdings
>>And if it were entered in the link resolver database,
>>it would still need to be displayed in the OPAC of course.
This is an interesting point, and perhaps one that we could debate
endlessly. My argument is that link resolvers have lead some libraries
to stop putting in holdings statements for their e-journals, and rather
asking the user to click through to the electronic holdings by using the
OpenURL. Why is this not satisfactory for print journals as well?
Of course, I would also say that just because the holdings aren't stored
in the ILS that doesn't mean that the ILS display screen couldn't query
the link resolver to get the holdings data on the fly, or you couldn't
push data from the Link Resolver to the ILS on a daily basis (just
coming back to the machine readable holdings, this is another point in
favour of storing the holdings in the link resolver - this is already
designed to store the holdings in a machine readable format, but display
or export them in a human readable format - whereas this would require
development on the ILS side).
>>If you are interested in deploying Umlaut at your library, feel free
to
>>contact me. Some time in the next couple months, once I've got Umlaut
in
>>a state where I'm comfortable doing it, I'm going to start trying to
>>aggresively recruit more Umlaut participants.
I may well be interested - perhaps we can have a chat off list about
this?
Received on Tue Sep 11 2007 - 09:53:21 EDT