oss4lib About - Contact    History 
Listserv         Projects
Readings         Submit  


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: open source and librarianship



> > And reason number two: most -- no, make that all -- of the online card
> > catalog systems I've seen just plain suck.
> 
> No argument there.  Unfortunately, one of the reasons they suck will also
> work against the adoption of any open source alternative: it is such a
> wracking experience for a library to migrate integrated library systems
> that many will literally put up with major flaws for a decade rather than
> change systems.  They will also pay high premiums for a single-vendor
> ("single point of complaint") integrated system that handles the OPAC,
> circulation, cataloging, acquisitions, and inter-library loan functions,
> which means few libraries will seriously consider a competing solution
> with an incomplete set of modules.
> 
I know I am coming into this thread from way behind but I was away from
email for a while and Thomas' and other's messages on the list had so many
great points that I would like to revisit a few. I agree that the
reluctance to go through systems changes is extremely important, and I
don't think libraries are unique in this. A lot of other organizations that
deal with "niche" systems usually have to go through so much sweat to fit
their operations into the constraints of any replacement that systems
migrations probably have a direct correlation with high levels of stress
and employee turnover. 

I also agree that it is important to emphasis the point that the OPAC is
typically one of several components of an integrated system because it
means that the same building blocks that provide everything from
circulation transactions to serials control patterns are often utilized to
construct the public interface. This a big part of the reason why OPAC
interfaces may seem primitive compared to many other information systems,
the programmers behind them need to cover a lot of ground with a set of
tools that can function at a lot of levels but have no where near the power
that specialized search engines can provide. I was at a conference session
last week describing the back end of Chapters online book searching system
(Chapters Online is like a Canadian equivalent of Amazon, though so far
they seem to be hiring rather than laying off staff (:-). The architecture
of the system had an amazing amount of processing overhead and some very
pricey tools were required to put it together and keep it running. Few
libraries would have the deep pockets to buy this kind of solution, and
very few vendors isolate the searching component from the rest of the
system like the online book vendors do.

> None of this is to say that Epixtech will be more clueful than Ameritech
> was--it's the same people, they just own the company now.  Nor is it to
> say that an open source alternative to library systems can't get its foot
> in the door.  It's just to point out how big that door is.  Targeting an
> open source ILS right now is like trying to invent Linux before inventing
> gcc and emacs.
> 
This being said, I wonder if some of the above could be an argument why
open source solutions can possibly work better than commercial options. The
key may be to work with standards that allow a high level of flexibility in
the components that make up a modern ILS. For example, some of the
calendaring systems, both open source and commercial, may be a foundation
for circulation and serials control functions in an ILS through standards
like iCalendar. XML is fostering the creation of DTDs that may provide an
entry point to map library requirements into some mainstream tools. A
library may also be able to leverage the savings from using an open source
solution to implement or buy a search engine to layer on top of the ILS, so
that the search interface really is a "high-octane boolean or relativistic"
option for querying the collection. Library systems are indeed a "big door"
but maybe they don't have to build everything from the ground up. Linux had a
meteoric rise in part because it made such good use of the BSD toolset, I
think part of the difficulty with the ILS is that we may not always see the
relationship between what we need and existing tools that have proven
themselves in the non-library world. 

> 
> Z39.50 in many ways parallels SGML.  It's in the NISO -> ANSI -> ISO
> family of standards bodies and was designed with too much complexity and
> too much flexibility for implementors, to the point that it really doesn't
> interoperate the way it was supposed to.  It needs to be reinvented as a
> slimmer, stricter standard--it needs an XML to its SGML.
> 
I like the analogy between Z39.50 and SGML/XML, and like XML, there have been 
attempts to "lighten" Z39.50 over the last few years in the same manner that 
XML became "SGML-lite". Keith Belton has pointed out that the Z39.50 development
community is friendly to the open source community and it would be great to
see the current W3C work on XML Query Requirements be a point where the web
community can take advantage of the huge investment that Z39.50 represents.
There are very real complexities associated with information retrieval that
take a phenomenal amount of control to specify in a search and retrieval
protocol, and I wonder if another useful analogy with Z39.50 is LDAP. Not
in the sense that Z39.50 and LDAP do the same sort of things, but LDAP was
a simplified version of X.500 that dropped some of the same baggage that
was making X.500 hard to work with, such as ASN (though it keeps some
aspects, such as BER requirements, that raise the bar significantly for
developing LDAP tools directly). Now, LDAP has the huge advantage that some
big vendors, particularly Novell, have made it available in a lot of tools
(Z39.50 probably has never been of particular concern to any of the vendors
listed in the NASDAQ!), but the LDAP connection is of interest because it
may be a model for Z39.50 to slim down. For that matter, maybe the
XML-based DSML (Directory Service Markup Language) which is modelled on
LDAP offers some ideas for fitting Z39.50 into the XML Query Language.

Anyway, just some more thoughts to add to the mix, this is a very
interesting thread that I hope I have not completely missed.

art
---
Art Rhyno, Systems Librarian
Leddy Library, University of Windsor
Internet: arhyno@uwindsor.ca
Tel: (519) 253-4232, EXT. 3163
FAX: (519) 973-7076
WWW: <http://www.uwindsor.ca/library/leddy/people/art.html>


SourceForge Logo © Copyright 1999-2005, The oss4lib Community, except for readings and comments, which are owned by their posters.
oss4lib is graciously hosted by the good folks at sourceforge.net.
Site URL: http://oss4lib.org/ Questions or comments to maintainers.


library