Changing thoughts

After a few busy weeks and a lot of interaction with Lukas Koster, Martin Malmsteen and others, I can say that there’s been some turmoil in my rock-solid (!) approach to what we do at the dirty, business end of library tech.

Following SWIB13, Lukas has pointed out repeatedly that working with vendors is a realistic way forward, whereas heavyweight development is something that very few libraries can actually sustain. His point is that in order for libraries to move forward, tools need to be provided within the existing framework; bolt-on and adapt rather than develop afresh.

Librarians (the vocal ones at least) largely hold vendors in contempt; vendors on the other hand provide ample opportunity for anyone bitten by the openness & freedom bug to be irked. This opposition obviously isn’t constructive. In believing that we can get to where we want to be without reference to the current status quo, where vendors largely dictate the technology platform we use, we’re looking for saltation while most speciation is gradual. Thus, to move forward in a realistic way, we need to move forward together.

There’s a lot to say about commercial bodies that work in the non-commercial sector. Let’s face it, libraries are a place populated by idealists, while commercial interests dictate that idealism takes a back burner to profit. At the same time, commercial interests that don’t respond to customer needs tend to fail.

What vendors get from libraries is surface noise from a small portion of librarians that claims that vendors are a) evil and b) should be doing linked data; under the surface, in the contracts they’re signing, they’re being asked to support a format dreamed up in the sixties on top of the Web stack. In light of this, there’s really very little reason for vendors to do very much — there’s no money in providing semantic web features when there’s no contract stating that without these features, there’s no deal.

Currently my thoughts here are that, at a minimum, outwardly facing pages from vendors should contain openly licensed, harvestable schema.org as both microdata and RDFa (both because I don’t think that I know which of these is preferable). This simple step takes us further than any attempt at saltation driven by EU funding or private initiative ever will.

Further reading

1. Poor person’s linked open data workbench

Advertisements
Posted in Uncategorized
4 comments on “Changing thoughts
  1. Adrian Pohl says:

    “Currently my thoughts here are that, at a minimum, outwardly facing pages from vendors should contain openly licensed, harvestable schema.org as both microdata and RDFa (both because I don’t think that I know which of these is preferable).”

    Two things:

    1. Structured data in “outwardly facing pages” would be a step forward and vendors – at least OCLC and Ex Libris – are already working on that one. But what is more important IMO is the possibility to get all your data (bibliographic data, authority data, circulation and access statistics etc.) out of the system in near real-time so that you can do the stuff yourselves that the vendor can’t or won’t do. (At least, this is what we want to achieve at lobid/hbz.) In the case of Ex Libris Alma, this obviously isn’t made easy as for example a recent thread on the code4lib mailing list shows: https://listserv.nd.edu/cgi-bin/wa?A1=ind1312&L=code4lib#16

    2. Why didn’t you add JSON-LD here? JSON-LD might even be the better way to provide structured data embedded in web pages. (At least there are strong arguments for dropping microdata/RDFa in Drupal, see http://lin-clark.com/blog/2013/12/08/drop-rdfa-drupal-8/. Though there are a lot differences between library software and Drupal, a lot of arguments against RDFa/microdata and for JSON-LD also hold for library systems.)

  2. brinxmat says:

    @AdrianPohl: I’m going a bit further than just requiring structured data, the data must be open so that it can be harvested without prior agreement — here we have our API. I certainly agree that a full API for all data is necessary, but I really don’t see that happening right now — indeed because of the information you link to.

    As regards adding JSON-LD + schema.org, yes, sure, but there aren’t any good reasons for not using RDFa and microdata in vendor interfaces — Lin Clark’s arguments regard Drupal.

    On the other hand, I guess that the sudden rush to JSON is based on the belief that it’s simpler and therefore better — processing JSON is generally OK, but I certainly don’t ingest large quantities of JSON in applications if I can use a simpler serialization. In the case of ingesting triples, I wouldn’t touch JSON or any other nested format with a bargepole.

  3. magnusenger says:

    I for one am commercial vendor packed to the brim with idealism…

    Koha (http://koha-community.org/) version 3.14 has Schema.org microdata in the OPAC (at least for MARC21). See this bug for the gory details: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6594 or this blogpost: http://www.coffeecode.net/archives/271-RDFa-and-schema.org-all-the-library-things.html

    In the next 5 months I intend to make sure that Koha has
    1. The ability to convert MARC records to RDF and store them in a triplestore whenever they are added or updated
    2. The ability to let users do basic browsing of the RDF data in the OPAC
    http://lists.koha-community.org/pipermail/koha-devel/2013-December/040126.html

    If y’all were using Free Software systems you could either write the code to improve and semantify them yourselves, or pay someone else to do it. Libraries do not have to be guests in their own houses, with Free Software they can be kings in their own castles!

    • brinxmat says:

      @magnusenger

      Yes you are! It’s great that someone has stepped up in Norway to provide support for Koha and try to change our closed market.

      The big issue for academic libraries is, as we have discussed in other places, the lack of ownership of and access to metadata. Even in jurisdictions where metadata isn’t covered by intellectual property law, restrictions on access (the no-storage clause) make this irrelevant.

      Typically, we’re talking about electronic texts, here and specifically article metadata, which don’t feature as part of our ILS, but as part of the third-party application portfolio we’re forced to maintain.

      Of course, open source is a way of inverting this sick control structure, so that library management gets to decide what happens, how and when, rather than having this dictated by the companies we sign contracts with. Unfortunately, as long as the product is actually the metadata, we have to work with the vendor.

      Open source solutions like Koha are valid tools and service providers like yourself are compelling alternatives to providers that work with closed solutions, however, it is a long road to take given the vested interests in many large organizations, particularly those that have “special relationships” with their suppliers. In these latter cases — and there are many of them — the fight to move to open source isn’t a simple financial or technical appraisal, it’s a political and personal battle that can’t easily be won.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s