It’s been a long time since the last post here, but that doesn’t mean unAPI adoption (such as it is) hasn’t moved forward since then.

• Zotero, the amazing online research manager, now (as of 1.0) fully supports unAPI.
• The unAPI plugin for Wordpress was recently updated.
• Koha 3 supports unAPI.
• unAPI made into its own Wikipedia page.
• In theory, Scriblio supports unAPI, too.

To me, the most exciting thing here is the level of integration possible now. And when I say “integration”, I mean “making things easier for users, so they can get on with their work without worrying about backend nonsense.” The most prominent FLOSS library systems - Koha and Evergreen - both support unAPI now. Scriblio is an important up-and-comer which proves the value of its build-on-commodity-apps strategy because it simply gains unAPI support when WordPress gained unAPI support.

Add Zotero - with an active user count apparently now in the hundreds of thousands - to the mix, and we have the makings of a real case for broader adoption… in the form of real users, the only kind that matters. Hopefully 2008 will bring much more attention, especially with the growth of linked data resources.

Michael Giarlo has updated the Wordpress plugin to be “fully” “Wordpressy”. Check it out - it even comes with its own admin pane under the Options / unAPI:

That’s what it looks like when running here, on this blog. Which it is, now.

Great work!

Our latest article is “Introducing unAPI” and is available in Ariadne 48:

“Daniel Chudnov, Peter Binkley, Jeremy Frumkin, Michael J. Giarlo, Mike Rylander, Ross Singer and Ed Summers describe unAPI, a tiny HTTP API for serving information objects in next-generation Web applications.”

That’s right, seven authors! For the record, everybody on the list was invited to participate; those listed here are those willing and able folks who responded. Here’s the intro:

“Common Web tools and techniques cannot easily manipulate library resources. While photo sharing, link logging, and Web logging sites make it easy to use and reuse content, barriers still exist that limit the reuse of library resources within new Web services. To support the reuse of library information in Web 2.0-style services, we need to allow many types of applications to connect with our information resources more easily. One such connection is a universal method to copy any resource of interest. Because the copy-and-paste paradigm resonates with both users and Web developers, it makes sense that users should be able to copy items they see online and paste them into desktop applications or other Web applications. Recent developments proposed in weblogs and discussed at technical conferences suggest exactly this: extending the ‘clipboard’ copy-and-paste paradigm onto the Web. To fit this new, extended paradigm, we need to provide a uniform, simple method for copying rich digital objects out of any Web application.” [citations elided; see the full article!]

In the article we quickly survey ongoing efforts to support web copy-and-paste, and tell the tale of early attempts to provide a “copy” function via OpenURL and OAI-PMH. Then we explain why we think that failed, and our simpler solution: unAPI.

The best part of the article is the long list of working examples. The authors contributed live links to their own unAPI-enabled sites and descriptions thereof; read the article and follow their links to see unAPI in action.

Xiaoming Liu has started a unAPI wiki and seeded it with a list of existing formats found in unAPI services.

This will be really useful as more unAPI services come online… if you’re starting to implement unAPI yourself, check this list first. If your formats aren’t on the list, follow the format name recommendation process to come up with and register it..

unAPI Version 1 is finished.

The only changes from revision 3, the previous revision, were those needed for the history section and minor wording tweaks.

Many thanks to everybody who generously contributed their time and attention to help make unAPI the best darned specification for copying objects out of webapps by format using their identifiers via a simple set of HTTP functions developed in public on an open mailing list in a very brief period of time using a wacky set of rules. The *best* one of those!

unAPI mentions appear in both the latest issue of Ariadne: “Serving Services in Web 2.0” by Theo van Veen, and in the latest issue of D-Lib — “Digital Library Federation (DLF) Aquifer Project” by Katherine Kott et al.

Alf Eaton’s excellent HubMed now supports unAPI revision 3.

Try it for yourself: look for the unAPI LINK after an arbitrary search, and the ABBR elements on each hit with class=’unapi-id’, and compose these into a unAPI formats list for some hit.

Particularly cool in this implementation is the addition of alternate biblographic citation formats such as RDF, BibTeX, RIS, and MODS to those already available from Pubmed.

mjgiarlo has posted a revision of pbinkley’s unAPI plugin for wordpress.  It is up and running on his blog, and here on all entries at unapi.info/news (including this very one!).
This also means that the “complete example” links in the informative section of revision 3 are alive and working again.

Thanks, Michael and Peter!

unAPI revision 3 is available.

This revision incorporates many significant changes from revision 2 and has become much simpler and shorter to boot!  Specific changes include:

• Any kind of identifier may now be used (previously required URIs)
• SPAN changed to ABBR
• unAPI class changed to “unapi-id”
• unAPI LINK rel changed to “unapi-server”
• Response format simplified, optional namespace_uri and schema_location removed
• Several informative notes added including a complete example, a response format schema, and suggestions for choosing identifiers and handling empty ABBR elements
• Contributor list updated
• Edited throughout for concision, clarity

Hopefully you will agree that this is the best unAPI yet.  Please consider adding unAPI to your web apps!

Due to holidays and other reasons, the publishing dates of the next revision of unAPI and the final version have been pushed back two weeks each.

Revision 3, the “ballot spec”, will be released on Thursday, May 4, 2006.

Version 1, the final version, will be published on Thursday, June 1, 2006.