One of our biggest frustrations with WorldCat Local has been the difficulties involved in surfacing e-book collections. The standard way of adding an ebook set to your catalog--uploading a file of MARC records provided by the vendor--doesn't surface records in WCL.
To get records for an e book set in WCL, you need to add records to your local ILS catalog, make sure those records have OCLC numbers in them and have your holdings set on the corresponding records in OCLC. This can be hard to achieve if vendor provided record sets don't have OCLC numbers on them to start with.
OCLC has an initiative in place to get vendor supplied MARC records into WorldCat, but agreements are not in place for all vendors and the process is somewhat cumbersome. Also, as I understand it, in some cases these vendor record sets aren't truly in WorldCat, they just show up in certain WorldCat Local instances where the library subscribes to the ebook collection. Effectively, this is creating "shadow" records in WorldCat that are only available to certain subscribers.
I really wish that we could just flip on and off collections of ebooks in WCL in the same way that one adds and removes collections of e journals in Serials Solutions' management interface. Having to load records into a local system and worry about connecting those records to OCLC records is a big hassle. I realize that there may be some vendor licensing issues that prevent this, but this seems like a good goal.
Perhaps there could be some kind of connection between Serials Solutions and OCLC along the same lines as their e serials holdings project that would achieve this sort of ease in adding and removing e book sets.
Another question to ask within the e book arena: why are we so dependent on vendors for bibliographic records? Libraries should be able to collectively catalog e book sets, especially in cases where the vendors want to hold their records tightly to their chest. Some kind of crowdsourcing application for cataloging an entire e book set might achieve this. Any libraries who want records for a certain e book set sign up, and the app divvies up cataloging between them.
Tuesday, February 16, 2010
Monday, February 15, 2010
shared ILS concept
The Orbis Cascade Alliance's Collaborative Tech Services Team has been charged with implementing "a Shared Best Practices working group to develop guidelines for effective technical services policies and operations that support the Alliance goal of a shared ILS (Integrated Library System)."
At our team's first meeting, I was charged with taking a shot at what an ideal Alliance shared ILS might look like. I am supposed to produce a white paper on this topic for consideration by the Team.
The work of the Shared Bibliographic Database Task Force serves as a good starting point in this thinking process. Their report points out many of the potential implications of a shared ILS as well as advantages and drawbacks (scenario 3).
Perhaps the most common notion of a shared ILS would be all 36 Alliance members piling on board a traditional ILS software package that was designed for large, complex organizations (but might not be designed to handle as many separate and large organizations and sub organizations as comprise the Alliance). A big advantage in doing this would be savings on system maintenance, local system administration and hardware costs.
To make this happen successfully, member libraries would have to standardize their operations around certain system settings like circulation loan rules because the system simply couldn't handle as much local variation as is in place now. This standardization might create efficiencies in itself in that it would promote common best-practices workflows around the shared settings. A shared system could also create efficiencies through the reuse and sharing of data. For example, by sharing bibliographic records, we could reduce the overall time and effort required for database maintenance.
The big disadvantage in sharing a system this way would be a potential lack of flexibility to tailor the system to the each institution's needs: whether this customization came in the form of special loan rules, distinct subject headings, etc. Another issue might be that the system would simply become unwieldy for staff to use because data from all the institutions would overload user interfaces for staff. Imagine having to wade through hundreds of item records for a given bibiliographic record (of course these effects could be mitigated by special views, etc.) And finally another disadvantage would be the potential red tape needed to make any change to system settings.
Another model of a "shared ILS" would provide every library with an independent "virtual" ILS delivered in a Software As a Service (SAAS) fashion. Because the software would be delivered over the web, we would "share" the underlying software and computing infrastructure. We'd be "sharing" an ILS with other Alliance members (and perhaps whomever else the vendor contracted with) but we wouldn't even know it. By doing things this way, we wouldn't lose any independence and we'd still potentially save money on system maintenance (both vendor supplied and via our own staff). But we wouldn't be gaining any potential benefits possible through the sharing of data.
The third option would be a hybrid of the two above and is the one that probably corresponds to the most likely reality. The ILS would be shared where there were benefits to be gained, separate where there were not. For example, in circulation every library could have their own patron types and loan rules, but those patron types and loan rules would map to higher consortial levels of abstraction in order to support borrowing between institutions (kind of like they do now in Navigator but in the same system). In acquisitions, data about what materials were on order at each institution would be shared, but fund data wouldn't. In cataloging, we would share bibliographic records but perhaps control some of our own fields. In e resources, both individual and group purchases and licenses would be supported.
Another twist, of course, is the notion of sharing the ILS on a global level, which is more or less the vision of OCLC webscale management services. This creates the need for an even higher level of abstraction than at that of the consortium.
In coming up with a model for an ideal shared ILS for the Alliance, I'll be considering all of these scenarios.
At our team's first meeting, I was charged with taking a shot at what an ideal Alliance shared ILS might look like. I am supposed to produce a white paper on this topic for consideration by the Team.
The work of the Shared Bibliographic Database Task Force serves as a good starting point in this thinking process. Their report points out many of the potential implications of a shared ILS as well as advantages and drawbacks (scenario 3).
Perhaps the most common notion of a shared ILS would be all 36 Alliance members piling on board a traditional ILS software package that was designed for large, complex organizations (but might not be designed to handle as many separate and large organizations and sub organizations as comprise the Alliance). A big advantage in doing this would be savings on system maintenance, local system administration and hardware costs.
To make this happen successfully, member libraries would have to standardize their operations around certain system settings like circulation loan rules because the system simply couldn't handle as much local variation as is in place now. This standardization might create efficiencies in itself in that it would promote common best-practices workflows around the shared settings. A shared system could also create efficiencies through the reuse and sharing of data. For example, by sharing bibliographic records, we could reduce the overall time and effort required for database maintenance.
The big disadvantage in sharing a system this way would be a potential lack of flexibility to tailor the system to the each institution's needs: whether this customization came in the form of special loan rules, distinct subject headings, etc. Another issue might be that the system would simply become unwieldy for staff to use because data from all the institutions would overload user interfaces for staff. Imagine having to wade through hundreds of item records for a given bibiliographic record (of course these effects could be mitigated by special views, etc.) And finally another disadvantage would be the potential red tape needed to make any change to system settings.
Another model of a "shared ILS" would provide every library with an independent "virtual" ILS delivered in a Software As a Service (SAAS) fashion. Because the software would be delivered over the web, we would "share" the underlying software and computing infrastructure. We'd be "sharing" an ILS with other Alliance members (and perhaps whomever else the vendor contracted with) but we wouldn't even know it. By doing things this way, we wouldn't lose any independence and we'd still potentially save money on system maintenance (both vendor supplied and via our own staff). But we wouldn't be gaining any potential benefits possible through the sharing of data.
The third option would be a hybrid of the two above and is the one that probably corresponds to the most likely reality. The ILS would be shared where there were benefits to be gained, separate where there were not. For example, in circulation every library could have their own patron types and loan rules, but those patron types and loan rules would map to higher consortial levels of abstraction in order to support borrowing between institutions (kind of like they do now in Navigator but in the same system). In acquisitions, data about what materials were on order at each institution would be shared, but fund data wouldn't. In cataloging, we would share bibliographic records but perhaps control some of our own fields. In e resources, both individual and group purchases and licenses would be supported.
Another twist, of course, is the notion of sharing the ILS on a global level, which is more or less the vision of OCLC webscale management services. This creates the need for an even higher level of abstraction than at that of the consortium.
In coming up with a model for an ideal shared ILS for the Alliance, I'll be considering all of these scenarios.
Liberal Arts and Web Collaboration
Pete Vidito, of our Environmental Studies program, recently published a web page that suggests how elements of liberal arts learning can be developed using Web 2.0 tools.
Subscribe to:
Posts (Atom)
