Re: NGLMS4LIB?

That also presumes that once something is cataloged, it never has to be changed. (Updated authority forms? Changed locations? Typos that you see only after the fact? And so forth.)


--

Jean Harden, Music Catalog Librarian
Libraries
University of North Texas
PO Box 305190
Denton, TX  76203-5190
(940) 565-2860
jharden_at_library.unt.edu


>>> On 10/23/2007 at 10:39 AM, in message
<E42A3F65D4A8114DBD3AA327AF33DF2F1606014F29_at_natasha.rpl.local>, Lynn Reynish
<lreynish_at_REGINALIBRARY.CA> wrote:
> That, of course, presumes that one can afford the fees to belong to OCLC.
> I've worked with or assisted 29 libraries in my career (school, public,
> academic and special) and only 2 were able to afford joining OCLC. A
> standalone client that could act as a front end to both OCLC and the LMS
> might be a reasonable compromise.
>
> Lynn
>
>
> ---
> Lynn Reynish
> ILS Librarian
> Regina Public Library
> lreynish_at_reginalibrary.ca
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Frances Dean McNamara
> Sent: Tuesday, October 23, 2007 9:24 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> I think an alternate suggestion is not to have a cataloging module at all
> and to only use OCLC.  Why create a standalone cataloging module when that is
> what OCLC specializes in?
>
> So, can you have a "disintegrated library system" (DLS instead of ILS?)
> where there is no cataloging module, all cataloging is done on OCLC?
>
> Frances McNamara
> University of Chicago
>
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Stephens, Owen
> Sent: Monday, October 22, 2007 10:39 AM
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] NGLMS4LIB?
>
> 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