I am quite excited about LibLime’s biblios.net.
Not to be confused with just “Biblios“, which is LibLime’s new open source cataloger’s editor. That’s cool too, but I’m talking about biblios.net, which is basically a shared metadata store. That is, technological support for ‘cooperative cataloging’. That is, what we used to call a ‘bibliographic utility’. The Biblios editor uses the biblios.net shared metadata store, but it’s not restricted to use by the Biblios editor, anyone can use it.
I think it has the sorts of features we need to take our cataloging infrastructure into the 21st century. Some things I am excited about:
Policy on changes
Our cooperative cataloging has traditionally been based on the notion that we can get the highest quality cataloging data by restricting access to editing it, to only trained professionals who have been verified/credentialed. I’m not even talking about ‘to only librarians’, but to only subsets of librarians who have gone through certain training and/or work for certain institutions.
I think this makes less and less sense in the “wiki-fied” internet world–and especially less and less sense as the ranks of advanced professional catalogers have been diminished by the downsizing and the de-professionalization of cataloging departments (which is, as I’ve said before, an unfortunate thing). While restricting edits to only those who will probably do it right, we exclude many willing volunteers’ labor.
I think the results have not been salutory. The quality of our existing cataloging records is, in fact, not that great.
biblios.net instead will let anyone edit records to add or fix information. If they make a mistake, well, someone else can fix it. We will have to wait and see, but I think in the long-run evidence will support that this strategy leads to better cataloging data.
(I’m not sure if biblios.net plans to provide web-based public access to editing ala OpenLibrary‘s stated plans (not sure if OL actually provides that yet either!), or instead limit to registered librarian-type users. Either way could work, and either way is a huge opening of the field compared to what we currently do.)
Read and Write APIs
The other barrier to harnessing more of our collective data to improve our cooperative cataloging quality is technological/workflow. We need software supporting cataloging workflow that both automatically sends changes to the shared store, and automatically downloads any new changes to one’s local catalog. It can’t be an extra step to submit or fetch corrected and enhanced records, we need the machines to do this for us.
biblios.net supports well-designed open APIs for both reading and writing, to make this process feasible.
This is also an issue of policy/business-model. It’s not feasible to have your software automatically getting all new changes to records you in your catalog every night, if you’re going to be charged per record download. That business model in fact discourages taking advantage of others enhancements, it’s based on the idea of a cataloging record as a more or less fixed static thing, rather than a thing constantly being improved.
biblios.net doesn’t charge you per download.
In fact, biblios.net doesn’t charge you for downloads at all, or attempt to place copyright or licensing restrictions on what you can do with the data downloaded. All cataloging data in biblios.net is open access. Anyone can download it without fee, and re-distribute it as they like.
This is crucial for providing a cooperative cataloging infrastructure to support innovation, and support the inter-connected web.
You can pay LibLime for a hosted Biblios cataloging editor solution, and for work to integrate Biblios with your ILS. But you can read and write data to and from biblios.net without paying anyone.
It will be interesting to see how this business model works out for LibLime, as biblios.net hopefully catches on. It’s definitely a good one for the library community.
We are increasing being called upon to deal in non-MARC formats. My understanding from chatting with Josh Ferraro is that biblios.net architecture supports holding multiple formats/schemas representing the same resource. For instance, perhaps a MARC record, an ONYX record, a DC record, some future XML-RDA record, etc. biblios.net knows they all represent the same resource, and in some cases can even translate from one to another, to provide a representation that hasn’t been individually uploaded. Say, a MARC record has been uploaded, but you’d like a DC record based on it.
It’s not clear to me how sophisticated biblios.net format handling and converting architecture is at present. Ideally it would maintain different formats in parallel. Someone could make a change to a DC record, submit it to biblios.net, and have that change reflected in Biblios.net’s MARC record too. That example makes it clear how this can quickly become complicated, as if you’re not careful you can lose information overwriting the rich and complicated MARC with changes taken from a much more basic DC record. But continued experimentation in this area is crucial, and biblios.net seems a good platform for it, with the right people working on it.
The Elephant in the Room
Is OCLC. This service clearly provides some of the same functionality as OCLC WorldCat.
(Note, that as far as I know, biblios.net does not (currently?) track which individual libraries hold which titles, so it does not compete with OCLC’s important support for ILL and discovery. But it does compete with WorldCat as a source of cooperative cataloging).
This means that OCLC is unlikely to ‘allow’ records from WorldCat to be entered into biblios.net. Of course, as we’ve discussed before, it’s unclear if OCLC actually has the legal capability to prevent this or not. And it is pretty clear to everyone (including OCLC) that they can’t prevent libraries from sharing their own original cataloging with anyone they want, in addition to with OCLC.
So for starters, it’s unclear where biblios.net has/will build up it’s initial database from. Perhaps records put ‘into the wild’ before OCLC recently clarified it’s attempts to restrict this.
Most LibLime customers, and the target market for biblios.net, aren’t current OCLC cataloging members (can’t afford to be), and probably have smaller collections than OCLC members. So it’s easier to build up a corpus filling their needs. This also means that biblios.net at the moment isn’t actually directly targetting OCLC customers.
However, biblios.net is providing exactly the kind of innovation we need in a shared cataloging environment. Our current environment is not powerful enough and not flexible enough. No doubt OCLC is working on similar things. For better or for worse, OCLC’s giant legacy database and need to support thousands of existing customers without problems neccesarily makes it harder for them to innovate in these areas.
Even if OCLC pulled off very similar functionality, I think the library is well served by having several options for shared metadata stores, that can be used as alternatives, or better yet, used in concert.
(Note that Ex Libris also has voiced plans to create a shared cataloging metadata store, as part of their URM plans, which still aren’t mentioned anywhere on their website, which perhaps can be taken as indication of their seriousness, although they sure TALK like their serious at the user group meetings.)
What would you do if you were Head of Cataloging?
If I were an administrator with control over a library’s cataloging practices (which I am not), I would not be looking to leave OCLC. Even without their metadata (which is currently indispensible), we’d need access to the Worldcat ILL infrastructure, we’d want our records to show up in worldcat.org for discoverability, and I like the increasingly powerful WorldCat API features like xID too.
But I would be looking to use biblios.net in concert with OCLC, and thinking about how I can use them both together for maximum effect. This requires re-thinking what our standards are for cataloging records. (We frequently spend excruciatingly large amounts of staff time on ensuring the highest quality for some records, while bulk downloading other records of dubious quality from vendors without review. A happy medium must be found, and I think this medium would allow for biblios.net). It also requires thinking through workflow, and figuring out how to do it without violating any OCLC policies.
I can think of various scenarios for using biblios.net and Worldcat together, but I’m not really an expert in current cataloging workflows.
In any event, I think it is to the benefit of the library community if biblios.net is a success, and I hope that some large ARL/OCLC libraries start experimenting with it, not just leave it to the non-OCLC market. I hope that developers of ILSs (open source and proprietary) work on integrating biblios.net support into their products.