Update: Mike Giarlo is now maintaining the unAPI Server for WordPress plug-in.

Here’s a unAPI server for Wordpress blogs. It conforms with Revision 1-14 of the unAPI spec, worked out last week at code4libcon. This is based on my OAI-PMH plugin, but unlike its ancestor, the unAPI server is properly plugged into Wordpress’s methods of accessing blog postings. Functionally, it does everything the spec says it should do to distribute oai_dc and MODS records for every blog posting.

Installation instructions:

  • copy this file to the main directory of your Wordpress installation
  • choose a URI prefix for your blog, e.g. oai:wallandbinkley.com:quaedam: (I’m using oai prefixes for compatibility with my Wordpress OAI-PMH plugin). Note the final colon.
  • edit unapi.php to put your uri prefix in the variable $uriPrefix (right after the initial comment section)
  • modify files in /wp-content/themes/:
  • in header.php, after the list of “link” elements, add this: <link rel="meta" type="application/xml" title="unAPI" xhref="http://your.domain/your-wp-path/unapi.php" />
  • in post.php and single.php, under the posting title, add this:
    <span title="your:uri:prefix:<?php echo the_ID(); ?>" class="unapi-uri" /></span>

If you’ve already installed the OAI-PMH plugin, just put the new unAPI tags beside the OAI-PMH tags.

I don’t know of a unAPI client to test this with yet, but here are some urls to show the unAPI output for this posting:

What next? This is a minimal implementation, without much thought given to what ought to go into a MODS or oai_dc record for a blog posting. The metadata can therefore probably be improved a lot.

Beyond that, let’s think about what can be distributed this way, beyond simple metadata. Should a posting like this, whose sole purpose is to announce the existence of a digital object, also offer metadata about that object as well as about itself? Should one of the unAPI formats be the zipped PHP file? How would we make that work with Wordpress? There’s still lots to think about…