Last night, Herbert Van de Sompel announced the availability of the draft specifications and user guide for Object Reuse and Exchange (ORE). This effort, under the auspices of the Open Archives Initiative (OAI), seeks to define a standard for the description and exchange of aggregations of web resources.

If you stop to think about it, the world of the web is at once a simple and a complex place. It is simple in that it is made up of resources (this HTML page, the jester’s cap graphic in the upper right corner, the text-to-speech audio version of this posting, etc.) that are uniquely addressed by URLs.¹ It is complex in that there is a relationship between this HTML page, the jester’s cap graphic, and the audio version that is not explicitly stated — at least not stated in a way understandable by machines processing content on the web. Which is to say, how does a web crawler know that the linked audio file is an alternate version of the text of this posting rather than a link to some holiday music file that I am critiquing?

This is where OAI-ORE comes in. It offers a machine-parsable way to describe relationships between various web resources. In a manner of speaking, an “ORE file” is a new kind of web resource that encapsulates and describes the complexity of real-world compound documents that already exist on the web. The neat thing now, though, is that there is a formal specification for those compound documents that allows their nature to be understood by web crawlers, indexers, and content repositories.

There is lots more about OAI-ORE in the user’s guide and specifications. Keep in mind, though, that these are alpha specifications that represent the best thinking and compromises of a couple dozen people. ² There are undoubtedly issues and ideas that haven’t been considered yet, so don’t go too far in coding up an implementation that may change (in subtle or dramatic ways) as the public conversation gets going. An OAI-ORE Google Group has been set up to discuss these documents. Those working on ORE to date welcome your comments there, and to reinforce that, I’ve taken the until now unprecedented step of closing comments here on DLTJ — put your comments into the Google Groups area.

Also remember that there are two open meetings scheduled to focus on the specifications:

Download iCal file

March 3th, 2008 — OAI-ORE U.S. Open Meeting at Johns Hopkins University

On March 3, 2008 the Open Archives Initiative (OAI) will hold a public meeting at Johns Hopkins University in Baltimore, MD to introduce the Object Reuse and Exchange (ORE) specifications. Space is limited, please register. Supported by Microsoft.

Download iCal file

April 4th, 2008 — OAI-ORE European Open Meeting at University of Southampton

On April 4, 2008 the Open Archives Initiative (OAI) will hold a public meeting at the University of Southampton, in conjunction with the Open Repositories 2008 conference, to introduce the Object Reuse and Exchange (ORE) specifications. Supported by JISC.

We’re looking forward to your questions and comments on the OAI-ORE draft documents.

The text was modified to remove a link to http://www.talkr.com/app/fetch.app?feed_id=16975&perma_link=http://dltj.org/2007/12/ore-draft-specs/ on December 30th, 2010.

Footnotes

1. Technically called “URIs”, but let’s not go down that path for the sake of trying to speak the vernacular of the public web and not that of the technicalities of the underlying standards.
2. I’m honored to be among those serving on the ORE Technical Committee.

Here is the press release describing the event:

FOR IMMEDIATE RELEASE:

Open Archives Initiative Announces Public Meeting on March 3, 2008 to Release Object Reuse and Exchange Specifications

Ithaca, NY and Los Alamos, NM, October 31, 2007 – On March 3, 2008 the Open Archives Initiative (OAI) will hold a public meeting at Johns Hopkins University in Baltimore, MD to introduce the Object Reuse and Exchange (ORE) specifications. The ORE specifications are developed in response to a significant challenge that has emerged in eScholarship. In contrast to the paper publications of traditional scholarship, or even their digital counterparts, the artifacts of eScholarship are complex aggregations. These aggregations consist of multiple resources with varying media types, semantics types, network locations, and intra- and inter-relationships. The future scholarly communication, research, and higher education infrastructure requires standardized approaches to identify, describe, and exchange these new outputs of scholarship.

The ORE specifications address this challenge with the ORE data model that defines how to associate an identifier, a URI, with aggregations of web resources. By referring to these identifiers, aggregations can then be linked to, cited, and described with metadata, in the same manner as any web resource. The ORE data model also makes it possible to describe the structure and semantics of these aggregations. The ORE specifications define how these descriptions can then be packaged in the XML-based Atom syndication format or in RDF/XML, making them available to a variety of applications.

In addition to their utility in eScholarship, the ORE specifications also apply to our everyday web use where we often encounter aggregations such as multi-page HTML documents, and collections of multi-format images on sites like flickr. OAI-ORE descriptions of these aggregations can be used to improve search engine behavior, provide input for browser-based navigation tools, and develop automated web services to analyze and preserve this information.

The March 3 meeting at Hopkins is intended for information managers and strategists, and implementers of networked information systems. It will be led by the two coordinators of OAI- ORE, Carl Lagoze of Cornell University and Herbert Van de Sompel of Los Alamos National Laboratory. Attendees will learn about the ORE data model. They will also learn about the translation of this data model to the XML-based ATOM syndication format. In addition, they will hear the results of initial experiments with the specifications by OAI-ORE community members. There will be ample time for discussion and questions and to meet other members of the OAI- ORE community. Detailed information for the meeting is at the registration page at http://www.regonline.com/oai-ore (NOTE: attendees must register in advance and attendance is limited). A subsequent meeting with similar content will be held in the UK in connection with the Open Repositories 2008 Conference. An announcement will be made when details are settled.

About the Open Archives Initiative: The Open Archives Initiative (OAI) develops and promotes interoperability standards that aim to facilitate the efficient dissemination, sharing, and reuse of web-based content. OAI-ORE work is supported by the Andrew W. Mellon Foundation, Microsoft Corporation, and the National Science Foundation (IIS-0430906). More information is available at http://www.openarchives.org.

March 3th, 2008 — OAI-ORE Open Meeting at Johns Hopkins University

On March 3, 2008 the Open Archives Initiative (OAI) will hold a public meeting at Johns Hopkins University in Baltimore, MD to introduce the Object Reuse and Exchange (ORE) specifications.

Two previous posts on dltj.org have described the OAI Object Reuse and Exchange (ORE) project and the theory behind what has become known as the ‘Web Architecture’. These two areas meet up now in this post which describes the issues surrounding the raw Web Architecture as applied to a web of scholarly communication and a basic outline of what the ORE project hopes to accomplish.

Problems With the Web Architecture

The concepts behind the Web Architecture are clearly successful. I believe it is safe to assert that the genius behind the creation of Tim Berners-Lee and his colleagues is the simplicity with which the vast web of world wide connections has sprung into existence with relatively little coordination. That said, some of the fundamental concepts behind the Web Architecture do not fit well with the web of interactions known as “scholarly communication.”

The first issue is aggregation. The Web Architecture does not provide a way to describe a finite set of Resources and relationships as a citable complex digital object resource structure. As scholarly communication becomes more than just papers — it can also now include data sets, supplementary graphics, primary source material as well as references to previously publish objects — this concept of aggregation becomes important.

Second, the relationships between Resources are usually untyped and link type ontologies are not well defined. (Capital-R “Resources” carries the meaning of this term as defined by the standards related to the Web Architecture; see the previous posting for a definition and examples.) Is this link within the text of a document a citation? A data set? An explanatory graphic? In general, it is not good practice to try to guess the relationship based on the contents of the URI itself. In fact, the Web Architecture technical report suggests “agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource.” ¹ In the absence of additional standards (such as OAI-ORE) layered on top of the core Web Architecture, this notion of “URI Opacity” encourages independence between an identifier in one document and the Representation of another object. One thing the ORE work seeks to accomplish is to build a framework for the semantics of links between objects in a scholarly communication environment.

The Problems From a Scholarly Communication Perspective

Take, for example, a paper in an example repository as described by this graphic. The article, identified by the number “012345″ has six Resources with five Representations: an HTML splash page generated by the repository software (Resource #1), the article in PDF format (Resource #2), the article in Postscript format (Resource #4), metadata in Dublin Core XML (Resource #5), metadata in BibTex format (Resource #6), and the article in a format decided by agent/server content negotiation (#3). ². Keep in mind that views of digital object must be bound to Resources in order to be reference-able (e.g. they must have URIs).

Although it may be possible to infer that all six Resources are related by comparing the leading fragment of the URIs, the Web Architecture principle of URI opacity dictates that we shouldn’t make those assumptions. Furthermore, even if we could determine that they are related based on examining the URIs, we do not have a consistent vocabulary to define that relationship. Is “…meta/bibtex” the citation data for this article or is it the list of citations used in the article?

Modeling Complex Objects

Because the Web Architecture does not allow for the definition of a boundary for a compound digital object, the ORE project proposes the definition of a Resource — called the ORE Model, for lack of a better name at the moment — that formally expresses a bounded aggregation of resources and relationships that corresponds to a compound digital object. Put another way, an instantiation of the ORE Model is a map of other resources that expresses the boundaries of the compound digital object. A URI identifies the compound digital object — the ORE Resource — and a service request on that URI returns a Representation that is some serialization of the ORE Model.

The preliminary version of the model describes two types of relationships: intra-aggregation relationships (inside the boundaries of the compound digital object) and inter-aggregation relationships (to Resources outside the boundary of this compound digital object). The intra-aggregation relationships come in two forms: hasPart (where one Resource contains other Resources, such as books contain chapters or journal issues contain articles) and hasView (where the target Resource is a semantically equivalent presentation format, such as Word and PDF versions of an article). The inter-aggregation relationship has only one verb, “hasRelationshipTo,” which simply means the target of the relationship is considered outside the boundaries of the complex digital object. From a base verb of “hasRelationshipTo” other communities can apply specialized relationships.

The result describes a connected sub-graph with a finite set of resources and relationships among those resources to form a compound digital object plus relationships to resources that are external to the aggregation. With that in place, we can consider services that can be applied to portions of the graph.

ORE Services

One half of the work of the ORE project is to define a model for compound digital objects in a Web Architecture environment. The other half of the work is to define the meaning of services that exchange instances of the model to form the basis of a Web Architecture-aware scholarly communication environment.

Conceived based on the experiences with the OAI Protocol for Metadata Harvesting (PMH), there are three archetypes of services.

• Harvest: a request for a batch of instances that correspond to the ORE model from a set of ORE Resources.
• Obtain: A request for an instance that corresponds to the ORE Model from a specific ORE Resource.
• Register: A request to add new nodes or relationships to an ORE aggregation.

Service requests against the ORE Resource URI are the access points for these activities.

For more information…

This is a basic introduction to the work of the technical committee so far. For a more in-depth view into the outcomes of the first face-to-face meeting, including expanded definitions and examples of what was outlined here, see the Report of the January 2007 ORE-TC Meeting. In addition, there is a interview with Herbert van de Sompel recorded at the CNI 2006 Fall Task Force to go along with a project briefing presented at that meeting. (Keep in mind that these were recorded and presented before the first technical committee meeting, so some of the concepts of the implementation have changed.) Pete Johnson, a member of the ORE technical committee, posted his thoughts on the topic on his blog: Prospecting for ORE, More ORE, and More ruminations on compoundness and complexity (and metadata). The presentation slides from Carl Lagoze’s talk at Open Repositories 2007 are also available, of which Chris Wilper and Jim Downing posed summaries and reactions. Also keep an eye on the OAI-ORE tag on Technorati for more updates and reactions.

The text was modified to remove a link to http://technorati.com/tag/OAI-ORE on January 19th, 2011.

Footnotes

1. “Architecture of the World Wide Web, Volume One” paragraph #98. Available from http://www.w3.org/TR/2004/REC-webarch-20041215/#p98 Accessed Feb 16 2007.
2. The Web Architecture allows for the Representation of a Resource to be decided through content negotiation between the agent/browser and the server.

As you may have noticed, the web has evolved a set of common principles that are a mix of ratified standards and ad hoc practices. The notion of a Web Architecture was codified in a W3C technical report called “Architecture of the World Wide Web” http://www.w3.org/TR/2004/REC-webarch-20041215/ or simply ‘Web Architecture.’ Those projects and protocols that align with the ‘Web Architecture’ are more likely to be picked up and used than those that do not. As a result, the OAI Object Reuse and Exchange (ORE) project seeks to provide an infrastructure for web-based information systems that exploit and enhance the Web Architecture, and therefore overlay cleanly on the existing web.

Given that we want to align closely with this ‘Web Architecture’ how far does the Web Architecture report go to define what is needed to make an ORE environment happen? The answer lies in the definition of three terms and the interaction of these three concepts.

• Resource: “A network data object or service that can be identified by a URI…. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, and resolutions) or vary in other ways.” ¹
• Uniform Resource Identifier (URI): “A compact string of characters for identifying an abstract or physical resource.” ²
• Representation: “An entity included with a response that is subject to content negotiation…. There may exist multiple representations associated with a particular response status.” ¹

This is perhaps best explained by this graphic from the “Architecture of the World Wide Web” document. All three terms are included: a URI identifies a resource which is in turn expressed as one representation. The key part of how the web works, though, lies in the definition of “representation” — that there may exist multiple representations for a single URI. Believe it or not, you already know this. The representation of the resource identified by the URI ‘cnn.com‘ at noon today is different from the one that existed at noon yesterday. You might say, “well so what…it is a dynamic website,” and I would agree — what is important here is that the web architecture does not give you a way to identify with a URI that representation of the cnn.com resource at noon yesterday. Put another way, in the words of the Web Architecture technical report, “Agents [web browsers and the like] may use a URI to access the referenced resource; this is called dereferencing the URI.” ³ The representation comes into being as a result of a service request by an agent for a resource via a URI.

The Web Architecture technical report lists four factors that determine which representation(s) are retrieved as a result of a service request: ⁴

1. Whether the URI owner makes available any representations at all;
2. Whether the agent making the request has access privileges for those representations…;
3. If the URI owner has provided more than one representation (in different formats such as HTML, PNG, or RDF; in different languages such as English and Spanish; or transformed dynamically according to the hardware or software capabilities of the recipient), the resulting representation may depend on negotiation between the user agent and server.
4. The time of the request; the world changes over time, so representations of resources are also likely to change over time.

When a URI is accessed by a browser, one goes through a content negotiation to get a representation. Representations may vary by device or time or IP address or authorization or any number of factors. In a graph or type-based thinking, a resource is a first class object: it is linkable — one can cite a resource. Representations, on the other hand, are second class objects: identified only in the context of a resource. A representation is not linkable, there may be many representations per resource, and a representation only comes about as a result of an action.

Observations

Footnotes

1. “Hypertext Transfer Protocol — HTTP/1.1″ RFC 2616. Available from http://www.ietf.org/rfc/rfc2616 Accessed Feb 15 2007.
2. “Uniform Resource Identifiers (URI): Generic Syntax” RFC 2396. Available from http://www.rfc-editor.org/rfc/rfc2396.txt Accessed Feb 15 2007.
3. “Architecture of the World Wide Web, Volume One” paragraph #117. Available from http://www.w3.org/TR/2004/REC-webarch-20041215/#p117 Accessed Feb 15 2007.
4. “Architecture of the World Wide Web, Volume One” paragraph #122. http://www.w3.org/TR/2004/REC-webarch-20041215/#p117 Accessed Feb 15 2007.