biblios.net and the future of cataloging

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.

Open Access

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.

Multi-Format

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.

Target Markets

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.

15 thoughts on “biblios.net and the future of cataloging

  1. Jonathan,

    Great write up. Thank you. VERY INTERESTING stuff here.

    “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.”

    Jonathan – do you know if it can give reports everyday of records that have been updated and has an “opt out” option for individual record improvements?

    If so, I can see this being very useful – if not, perhaps it could become a nuisance and unwieldy.

    “I can think of various scenarios for using biblios.net and Worldcat together, but I’m not really an expert in current cataloging workflows.”

    But I would guess WorldCat needs to have persons using them for all functions in order for them to remain useful and viable.

    It seems to me that this move might force some OCLC changes that otherwise would be much slower in coming…

    ~Nathan

  2. How long do you think it will take before OCLC:

    a) Takes legal action against LibLime
    or
    b) Makes an offer to purchase LibLime

    I would be quite surprised if they have not inquired about option b yet.

  3. I doubt LibLime is up for sale. They are currently doing quite well, have been expanding rapidly lately, and like what they’re doing.

    It’s not clear to me what legal action OCLC could take against LibLime, if they have any legal basis whatsoever to try and stop them. I can’t think of any. There’s no law that says you can’t compete with OCLC.

    Nathan, what makes you say that WorldCat can’t be useful and valuable to it’s customers unless it’s the _only_ service it’s customers use for copy cataloging? Of course, that’s already not true, many OCLC members already buy cataloging records from various for-profit vendors, in addition to using WorldCat for copy cataloging.

    I don’t see any reason OCLC needs a monopoly to stay useful and valuable.

  4. Jonathan,

    I said:

    “But I would guess WorldCat needs to have persons using them for all functions in order for them to remain useful and viable.”

    I should be more careful. I wasn’t thinking people need to exclusively use WorldCat. But the fact of the matter is if certain, committed people do not loyally and selflessly produce many records for WorldCat, there will be fewer and fewer records that people can download. I think that many institutions do not put much in but get a lot out of it.

  5. Good point Nathan.

    Please note, because some people mis-read me, I am not encouraging anyone to stop submitting records to WorldCat. In fact, I am encouraging people to share their records far and wide in _as many_ places as possible. What bothers me about WorldCat’s attempt to control all our records is that it places _limits_ on sharing. I’d never stop sharing my records and holdings with WorldCat–so long as I was allowed to share them with others too. The more the merrier.

  6. “There’s no law that says you can’t compete with OCLC…I don’t see any reason OCLC needs a monopoly to stay useful and valuable.”

    I’m not sure OCLC sees it that way. The OCLC records policy certainly makes it seem to me they are doing everything they can to maintain their monopoly.

  7. To answer one of Nathan’s questions, we’re planning to add an OAI-PMH service to ‡biblios.net to allow users to drink from the firehose of new and updated records. Furthermore, once we add the ability to formally register a library’s holdings in ‡biblios.net, more customized record update feeds won’t be far behind.

  8. Aha, I was curious if holdings tracking was part of the biblios.net plan. So it is. Interesting.

    I’m not sure OAI-PMH is the best way to get records, but perhaps. Is there any way to limit your OAI-PMH (or any other API) feed to only certain records, and/or only records that have been modified since X date?

  9. We would define a few simple sets for use by OAI-PMH clients – updates in the past 24 hours, new records in the past week, etc. We already have most of the code we need to implement OAI-PMH support, which is why it would be released sooner, but we also plan to add support for Atom feeds.

  10. Jonathan,

    You can selectively harvest based on date ranges and other criteria. See: http://www.openarchives.org/OAI/openarchivesprotocol.html#SelectiveHarvestingandDatestamps

    And if your OAI server is flexible enough, you can come up with all manner of virtual feeds to cater to whims.

    I don’t like OAI-PMH as a protocol much, being a re-invention of some wheels. But it is mature enough and so widely adopted that it has become a de-facto standard. And that is often the best ones.

  11. when i try to add new caltalog i gat the error
    pls help me

    Koha error

    The following fatal error has occurred:

    Can’t call method “fields” on an undefined value at /home/koha/koha-3.00.01-stable/C4/Biblio.pm line 1765
    Apache Server version: Apache/2.2.16 (Debian) Server built: Mar 22 2011 20:56:31
    Koha 3.00.01.005
    Koha DB 3.0001005
    MySQL mysql Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (i486) using readline 6.1
    OS Linux debian 2.6.32-5-686 #1 SMP Mon Jun 13 04:13:06 UTC 2011 i686
    Perl 5.010001

Leave a comment