Stephens, Owen wrote:
> SFX jargon) rather than a single one for journal holdings. I'm
> arguingthat we should consolidate in the Link Resolver, Jonathan
> argues weshould consolidate in the ILS - we both agree (I think) that
> we need to consolidate.
Perhaps I was playing devil's advocate to some extent, and misled you.
I do not think either our _current_ ILSs _or_ our current link resolvers
are up to the task.
I think we need a new architecture that is. I think it's irrelevant
whether the piece of software that controls this 'knowledge base' is
called an 'ILS' or a 'link resolver', and probably it should be called
neither.
Rather than debeate what to call the piece of software that does what we
need, we need to start laying out functional requirements for what this
software needs to _do_. And it needs to provide back-end workflow
support in an integrated sane way, AND support an integrated holistic
end-user environment. We've started to discuss these kinds of
requirements in thsi thread, and that's the important part of this
thread, not debating terminology---which is essentially what the 'is it
an ILS or is it a link resolver' debate is.
Jonathan
> 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.
>
>
--
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:33:37 EDT