You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Background

unAPI is an HTTP API for the few basic operations necessary to copy discrete, identified content from any kind of web application. Although there's general utility in having Fedora support unAPI, the real motivation is enabling the automatic capture of citation information in Zotero.

There are three components to an unAPI implementation:

  1. an identifier microformat
  2. an autodiscovery link pointing to an unAPI service
  3. an unAPI HTTP service

The unAPI HTTP service interface defines three methods:

  1. listFormats (e.g.: http://www.example.org/unapi/fedora)
  2. listFormats for a given identifier (e.g. http://www.example.org/unapi/fedora?identifier=info:fedora/demo:1)
  3. getObject for a given identifier and format (e.g. http://www.example.org/unapi/fedora?identifer=info:fedora/demo:1&format=oai_dc)

The response format for 1 & 2 is an XML document that includes the name of the format, its mime-type, and an optional description of the format. For example:

<formats id="info:fedora/demo:1">
  <format name="oai_dc" type="text/xml" docs="http://www.openarchives.org/OAI/2.0/oai_dc.xsd" />
  <format name="mods" type="application/xml" docs="http://www.loc.gov/standards/mods/" />
</formats>

Fedora Implementation

Implementing the first two components of unAPI is quite straightforward. The identifier microformat for a Fedora resource would look like:

<abbr class="unapi-id" title="info:fedora/demo:1" />

The autodiscovery link might look like:

<link rel="unapi-server" type="application/xml" title="unAPI" href="http://www.example.org:8080/unapi/fedora"   />

For the moment, I've just modified the viewObjectProfile.xslt (located in $FEDORA_HOME/server/access/) to include these two elements. As a result, the rendering of say, http://www.example.org:8080/fedora/get/demo:1, would now include those elements.

There are any number of ways to implement the unAPI HTTP service. One approach might take a Fedora digital object (e.g. demo:1), and consider each of its component datastreams as a format. Imagine demo:1 represents a journal article and contains four datastreams, DC, RELS-EXT, XML, and IMAGE.

However, I find this approach unsatisfactory because it doesn't allow for the author's notion of the different formats of the object. For example, the IMAGE datastream might just be a component in an HTML rendering of the journal article and oughtn't be considered a format on its own. Moreover, this object might be bound to services that can generate different representations of the object which wouldn't be captured at all by this approach.

What's called for is a programmatic means of indicating which representations of an object should be considered formats, at least as far as unAPI is concerned. A content model savvy approach might enable a dissemination that returned the unAPI formats appropriate for a given content model instance.

[ diagram here]

In my prototype, I've added an XML datastream, UNAPI-FORMATS, to a content model object. This datastream describes the disseminations that should be considered an unAPI format.

Zotero Integration

Enabling automatic citation capture in Zotero typically involves the creation of a site translator. However...

DSpace Integration

 As a proof of concept, I implemented an OAI-PMH resolver, designed to provide unAPI services for any application that exposes OAI-PMH. As DSpace provides OAI-PMH, providing Zotero support only involved the additional steps of enabling the MODS crosswalk and adding the unAPI microformat identifier and unAPI service link to display-item.jsp.

  • No labels