Mark wrote
> So why not? I'm not a database guy, but it seems to me that if a
> standard database scheme was created to store all the types of data an
> ILS needed, wouldn't that solve 99% of the problem? Couldn't we tack
> on any company's circ software, assuming it knew how to read and write
> to our database? In terms of what the user wants to accomplish,
> aren't the basic tasks pretty much predictable?
>
I'm not sure you need to go as far as a standard database. Considering
the small number of large LMS suppliers in the market, actually even
building an interface to each one is a minimal amount of work (6 major
systems, 4 major suppliers?) - if only they all had published API to
work with...
In some cases standard APIs already exist. For Circulation SIP2 or NCIP
would surely cover the vast majority of tasks you want to carry out. In
my previous employment we implemented Self Issue using RFID and we were
achieving >90% of loan transactions at the self service machines. These
had their own client s/w which the user interacted with, with the
communication back to the LMS by SIP2.
There might be some circ stuff ('supervisory' functions?) that isn't
covered here, but this should be a minimal number of transactions.
To pick up Mark's example of a cataloguing client, an easy approach
would be simply to create MARC records in a stand alone client that
could then be imported into one or more LMS (solving Mark's problem of
cataloguing over several different LMS systems). As Karen noted, Mark
isn't asking for the world - the stuff he suggests is relatively
straightforward I think. There are questions about where the data comes
from perhaps, but if things such as the Authority files and encoded
field lists could be supplied via a web service, then the client itself
would be quite 'lite'.
Are there any good standalone cataloguing clients already? What are
there drawbacks compared to the LMS? (I guess you lose some workflow
benefits?)
Owen
Received on Mon Oct 22 2007 - 12:01:21 EDT