Picking up on an idea Jeff Young raised on #code4lib the other day, here are some thoughts on a way of meshing unAPI and COinS to enable interesting uses of bibliographic metadata in web pages. I’m calling it Pilcrow because that’s my favorite word this week.

Suppose I’m blogging about a book, maybe using a book review microformat, and I want you to see your local library’s holdings of that book when you visit my blog posting. And suppose you want the same thing. You could just use Book Burro, of course, with suitable customization to make it pick up ISBNs from my page, but we want a more integrated presentation as befits a proper mashup. What do we need to make this happen reliably?

  • I have to provide the book reference in a good parsable format suitable for linking, i.e. COinS.
  • I also have to tell your browser that I want it to treat this COinS a little differently than it treats other COinS: not (just) create an OpenURL link to your link resolver, but also point the COinS at a suitable server to retrieve an HTML snippet containing the holdings, which the browser will insert into the page in the position I have specified.
  • You have to have a COinS activator in your browser that understands not just ordinary COinS but also the special instructions I’m going to give.
  • And you have to have access to an OpenURL-addressable service that provides holdings statements in HTML snippets.

The COinS part is easy. Telling the browser what to do with this COinS is a little more intricate. First of all, you are of course free to resolve the COinS in the usual way, to produce a link to your OpenURL resolver. You may do this instead of or in addition to the special display that Pilcrow provides.

How do you know that this is a special COinS? I originally thought of copying Jeff Young’s plan and putting something in the service request field of the context object. But after a little more thought I’m thinking of handling this with an additional class in the COinS span, since what I want from this has everything to do with the display in the current HTML page, not with the resolution of the COinS per se. So, this COinS might look like this:

<span title="..." class="Z3988 coins-holdings"></span>

This tells a smart activator that it suits my page’s design for the activator to fetch library holdings and display them here.

The activator is configured to resolve coins-holdings requests by means of a custom resolver. It composes an OpenURL out of the resolver address and the COinS, fetches the holdings snippet with an xmlHttpRequest, and displays the holdings in a div right after the COinS span:

<div class="coins-holdings">
  <h2>Pilcrow Public Library</h2>
  <div class="coins-holdings-statement">Central Branch, 1245.2134, on shelf.</div>
</div>

It’s up to the library to provide the holdings resolver, as part of its extensive web services API. Or perhaps an enterprising third party will undertake to scrape holdings statements out of the OPAC or fetch them by Z39.50.

So far we haven’t used unAPI. Its role would be to reduce the amount of convention involved in generating that snippet of HTML. A traditional COinS is a “fire-and-forget” weapon: the server provides the COinS and cares not a whit what the activator does with it. Pilcrow extends the COinS idea to give the source more control over the presentation of the COinS, so as to allow a pleasingly integrated presentation. Instead of arbitrarily putting the library name in an h2, for example, we prefer to let my server provide a template which your activator can use to generate the HTML snippet. You get that template by means of unAPI. Your activator would hit my unAPI server with a request for a coins-holdings document for this posting. The document might contain something like this:

<div class="someclass">
  <h2>{library_name}</h2>
  <div class="someotherclass">{holdings_statement}</div>
</div>

In this case the activator would fetch XML or JSON from the holdings resolver and use the data to populate the template. This allows me to control the appearance of the page by means of my own HTML design and CSS, while your activator just worries about the data. All we need is a set of conventions around the field names.

This looks doable, and I mean to try it out as a first project for a unAPI client. How useful might it be in the real world? I think it might be the basis for a very flexible system of bibliographic mashups, bringing OpenURL into the Web 2.0 era. OpenURL was built on the “just-in-time” model, but Web 2.0 likes to do things “just-in-case”. This mechanism gives us a the basis for a standards-based version of Book Burro’s functionality.

The range of services could be broad: you might want to display cover art, reviews, table-of-contents, etc., all derived from a local server. Perhaps your library licenses this kind of enhanced content; with the COinS/unAPI system, your users can see that content in all sorts of useful places that you don’t control. Or perhaps you want to display external metadata about a blog posting drawn from Technorati or another tagging site: Pilcrow could govern the presentation, while you configure your favorite source of such enhanced metadata in your activator. The service document provided by unAPI might contain information about a default service (such as Amazon), which users who don’t have a local service could use. It might also contain human-readable information about the service, with links to suitable activators, to provide the “dial-tone” that tells users there’s an enhanced service available here.

Or it may just be a fun little toy of a unAPI client. I hope to build something shortly and see where it goes.