BIBSYS modernization


[This is a draft, I’ll be revising it]

The stream of mail on the Biblioteknorge mailing list about BIBSYS’ modernization has been almost unstoppable — at least five mails 🙂 — and names like Knut Hegna, Hans Martin Fagerli, Kim Tallerås and Dagmar Langeggen have been connected to the topic.

What’s the fuss? Well, it seems like BIBSYS will continue developing its own library management system, rather than buying off the shelf software. This contradicts the findings of “that there report” — you know, the one that recommended getting a new, off-the-shelf system. Full of wackiness — especially points at which it contravened the standard rules that a report should contain information about its subject from commonly accepted reality rather than the creative imagination — it is easy to ignore that report, but maybe it shouldn’t have been simply “ignored”.

My take on the whole thing: really very dull, I’m sorry.

Starting at the outside edge: the online public access catalogue is a relatively uninteresting concept today, and is becoming less interesting with each day that passes, here’s why:

  • Users aren’t finding their information there, they’re finding it on the web (report)
  • University libraries aren’t registering their information in an OPAC (at best they import a subset of the e-journal and e-book data they are spending the majority of their finances on)
  • The metadata a researcher needs is not registered in an OPAC, it is available only in research databases
  • Attempts at integrating/federating search in metadata for academic content have failed
  • Portals cost money, and this is money wasted when the user doesn’t want or need to use it

The internals of a monolithic library management system are also past their sell-by-date for the majority of academic institutions:

  • Packages and subscriptions increasingly account for the majority of spending
  • Metadata import related to packages are typically limited
  • Acquisitions are increasingly expected to conform to norms applied in the rest of the institution
  • User systems are in place that register users’ role and access privileges

Given that the majority of spending goes on resources that are already findable using other methods (the metadata we’re importing must come from somewhere, and Google is the preferred tool of discovery), there is really very little need to register the majority of objects we’re currently registering.

Academic institutions — especially publicly funded ones — have resource management systems that ensure that every economic transaction is done by the book, i.e. ensuring that things are put out to tender, and that an economic overview is available to the various controllers around and about. This means that an economy module in a library management system is not a good thing, it encourages practices that go outside normal routines, and hinders the financial controllers from doing their job (you do not want or need more than one system for this kind of thing).

Another aspect of the library management system is that of loan data, where a user profile system provides what data is needed about a borrower, and then attaches various objects to this. At a modern academic institution integration of the insitutional user-profile system with the library management system’s user-profile system is one big headache…so why do things that way around? Why not implement the necessary slots for library data in the existing institutional system? The framework for the kind of query across several thousand records is already in palce, so why not use it? There is time and money to be saved here too.

We’ve got rid of a few subsystems here, but were back to the sticky issues:

  • registration of items in a library’s collections
  • sharing of data

Simplicity itself would be requiring all third parties to supply Linked Data for their products (and yes, this is a realistic thing to ask), and then registering the remainder by creating a local linked data store containing either totally unique metadata for items that are otherwise not registered anywhere, or by linking to existing items registered in other Linked Data stores (and this can include non-Norwegian sources). In this way, a massive web of data is available to the library’s users, containing references not only to things in the local library’s holdings, but potentially to all existing items in any library that provides Linked Data.

The OPAC can now either be replaced by the generic, or domain specific semantic browser that a given user prefers, or a user interface that provides a wrapper for SPARQL queries and a presentation format for the data returned from the dereferenced URIs contained in the Linked Data. The latter here could be something created locally by the library IT staff, or an enterprising librarian who knows a bit of Javascript, and can follow the instructions given in a typical Javascript library.

BIBSYS can potentially be a provider of tools for a) creating Linked Data, and b) storage and retrieval of this. Modules for solving issues related to lending and finances could be off-the-shelf software, supplied where these were deemed necessary.


Linked data [wikipedia]

Semantic Marc, MARC21 and the Semantic Web

BIBLIOTEKNORGE om vedtak om modernisering av BIBSYS Biblioteksystem


Tags: , ,

%d bloggers like this: