Jonathan Rochkind recently wrote a good blog post about using HTML5 Microdata to help citation managers like Mendeley and Zotero discover citation metadata that is available in formats such as RIS. It’s an excellent and detailed complement to Eric Hellman’s piece on the same subject.

I contributed to the unAPI effort 5 years ago, which aimed to fix the same problem: making citation metadata available to browsers. I wrote the unAPI validator which helped implementors confirm they were doing things right, articles were written, and we saw implementations in software such as the opensource integrated library system Evergreen and the popular citation manager Zotero, which at one point looked first for unAPI metadata in pages…perhaps it still does.

As Jonathan points out, there are some issues with unAPI, such as accessibility problems around Microformats in general, which unAPI was partly modeled on. HTML5 Microdata and RDFa weren’t around when we were working on unAPI, so I think Jonathan is right that it definitely makes sense to think about using these technologies nowadays instead of unAPI when making structured metadata available in HTML. I personally think the same thing goes for COinS where OpenURL key value pairs are used to express the metadata. Companies like Google, Microsoft, Yahoo and Facebook actively scrape HTML5 Microdata and RDFa, and there are vocabularies for describing books and articles. And because these technologies are deployed wider than the small niche that libraries occupy, they fit the Web better.

But there is a fair bit of turmoil in the structured-data-on-the-Web space. Today’s F8 product announcements seemed to indicate that Facebook is deepening its use of the OpenGraphProtocol, which is their rebranding of RDFa. We’re seeing the International Press Telecommunications Council standardizing rNews as an RDFa vocabulary for expressing online news metadata. And meanwhile Google, Microsoft and Yahoo are continuing to work on Microdata vocabularies. The recent Workshop seems to anticipate significant changes in that space in the near future, particularly regarding the output of the W3C Web Schema and HTML Data task forces.

At LODLAM-DC we had a good conversation about RDFa, Microdata, Microformats and JSON publishing options for the cultural heritage sector. Perhaps I was just projecting, but it seemed like there was a fair bit of uncertainty about which to use. At the end of the day it seems like making your decisions based on things you want to enable is a good way forward. Are you trying to get your content to show up nicely on Facebook or Google–or both?

…or are you trying to do something else, like advertise some RIS citation metadata that is related to an HTML page so a citation manager can pick it up?

Even before the pixels had dried on the first version of the unAPI spec I was left with the nagging feeling that it had missed the point. I felt like we hadn’t really used the mechanics of the Web that were already there, and had sort of inadvertently succumbed to how standards development would be lampooned later by XKCD:

Specifically, I felt like we could have documented an even simpler pattern, namely using a <link> or <a> elements in conjunction with the rel and type parameters. So if you have a search result that is available as RIS, why not add this to your <head> element:

My IRC conversation with Jonathan about his blog post was rolling around in my head when this Kurt Vonnegut quote went by in my Twitter stream:

It seemed oddly appropriate given the uncertainty in the structured-data-on-the-web marketplace, and some missteps with unAPI. If all we want to do is replace unAPI with something easier and more web-friendly, then why not fall back on basic functionality that has been in HTML for years?

If you want to make structured metadata available directly in HTML, sure HTML5 Microdata and RDFa are important technologies to use. But if all you want to do is link to an external metadata file I personally think the scholarly community would be better served by a simpler and less controversial approach.