A data model for interoperability between scholarly repositories

This 2007 paper (actually submitted October 2006) from the International Journal of Digital Libraries proposes a model for improving interoperability of metadata and data between scholarly journals. Regardless the proposed model presented here, the authors point the most pressing shortcomings in the current state of the art. But as a side note, since this article was written about three years ago, and since I haven't done much scholarly research or any publishing, let me know if a critique is no longer true.

They start out by noting, as we have in class, that the traditional unit in paper publishing, the article (a single "unit of communication"), need not prevail in digital publishing where units of communication can be tracked and displayed. Repositories are already housing complex digital objects that do service to these units of communication (datasets, citations) but interoperability is limited to the OAI-PMH and its mandatory stipulation of a Dublin Core metadata format for sharing.

The authors establish three "high-level requirements" in their Pathways project that would allow much greater interoperability:

• a shared data model for the digital objects
• a surrogate format that serializes the digital object according to the digital model
• support for a universal way of handling repository materials as surrogates: obtain, harvest and put.

As you might imagine, the authors proceed to explain their terms and concepts. I will do that briefly and then relate an example that illustrates how their model would work.

Their data model consists of an entity with leaves of datastreams attached. Entities are recursive: one entity could be the ACM Digital Library holding multiple entities of conference proceedings, which in turn contain entities of talks and speakers. An entity has any number of datastreams attached to it, these point to actual bits stored somewhere that constitute an instance of that entity or components of that entity. This allows for both abstract (entity) and concrete (datastreams) representations of the digital object. Entities and datastreams have various values attached to them like providerInfo, format, and crucially hasLineage. This lets entities unambiguously point to the repositories of origin. Since entities are recursive this allows evidential citation chain that preserves the complex interrelationships of scholars and their work. For example, translations would natively point to the original article, the original article would natively point to preprint articles it references, and so on.

The surrogate format would serialize the digital object so it could be represented by reference. This is like creating a skeleton of the digital object where each bone points to the actual corresponding bone in a repository. That way, unless a user or repository wants to ingest the digital object, work can be done without shipping the entire digital object over the network. The authors found RDF useful for modeling surrogates.

The last piece is three proposed essential services for repositories: obtain, harvest, put. Obtain requests a surrogate of an identified object, harvest reads the surrogate, and put would submit the surrogate or parts of the surrogate to a repository.

Their example details a user selecting articles from three different repository types (DSpace, arXiv and aDORe) and putting them, to various degrees, in his own Fedora repository so they can be issued in a single journal. The enhanced usability described mainly entails the user ingest the surrogates of these articles. This lets the new journal point to the articles by reference and point to all the complex data about the objects as well (any citations, data and so on). The custodial chain of the articles is preserved as well.

A central registry of repositories is the key to their model. Although this registry is not necessarily complex (a single line for each participating repository) it is essential for the success of their model because every entity would have a providerInfo set that would let a harvester application (they argue OAI-PMH would work with some adjustments) look up the provider in a registry, contact it, etc.

The main drift of their work is to move interoperability away from simply discovering resources with a federated search via stripped-down, minimal metadata markup (Dublin Core) and allow repositories their more custom, nuanced handling. They do this by providing some very (they argue) low-barrier principles to which participating repositories can subscribe. The two most fundamental of these are the shared data model of entities and datastreams and support for the three services of obtain, harvest and put.