EBSCOhost Connect was announced in the spring of 2006 as near as I can recall. (I can’t find the press release about it on the EBSCO website. As close as I can come to a date is from an announcement at the Oregon School Library Information System.) After three years, I’ve finally seen an EBSCOhost Connect in Google web search results. This screencast and accompanying transcript (below) show what I’ve found.

Screencast Video

Video Transcript with Links

EBSCOhost Connection is designed to bridge the gap between a search of Google and other search engines and the valuable content of EBSCOhost that is available to you, courtesy of your library. EBSCOhost Connection is intended to promote and expedite access to this quality content by infusing brief citation-only records from EBSCOhost databases within result lists generated by these search engines. As such, you can click on the EBSCOhost record in these result lists, and be appropriately directed to the database pages within your library’s EBSCOhost resources.

This sounds like a good idea, but until I saw a post last week from Aaron Schmidt on his Walking Paper blog, I hadn’t really seen any of these EBSCOhost Connect records in Google web search results. Aaron found that a Google search for “triumph triple connection” will show an EBSCOhost Connect record. In my testing, I found it to be in either the sixth or seventh position on the first screen of results. Your experiences will, of course, vary by your geographic location and past search history, but — in any case — I made this screencast to show you what it looks like from both inside and outside an IP address range recognized as subscribing to EBSCOhost.

In the simplest case, your machine is using an IP address configured as part of an EBSCOhost subscription. Starting at Google, we’ll do a search for “triumph triple connection” and scroll down to see the EBSCOhost Connect record. Clicking on it gives this brief citation display with a note at the top to access the complete article on EBSCOhost courtesy of my place of work. Selecting that link indeed takes you to the full record display with all of the EBSCOhost functionality.

It is a little more complicated if your machine is using an IP address that is not recognized by EBSCOhost as coming from a subscribing institution. To demonstrate this, we’ll start again at Google and search for “triumph triple connection”. This time when we select the search result from Google we get a page with with this heading where the link directly into EBSCOhost used to be. We need to come over to the left sidebar to find our institution — either by institution name, by ZIP code, or by using a narrowing down browse process. I’ll search for “Ohio” as part of the institution name. And indeed my place of work shows up as a choice.

It is at this point that things start to go wrong. As Aaron noted in his post, he couldn’t get past this screen. I had the benefit of looking at the EBSCOadmin configuration for my place of work, and unfortunately that still didn’t help. What we get is this rather unhelpful, generic EBSCOhost login. Even though our consortial configuration in EBSCOadmin is set to use our EZproxy server to authenticate users, we still get this generic login prompt. The EBSCO Support knowledge bank entry for How do I set up EBSCOhost Connection? describes an authentication setting: – “From the drop-down list, select the method of authentication you want to use: User ID/Password, CPID, or Patron ID.” The problem is that I don’t want to use any of those. I want to send our users through our proxy server and EBSCOhost Connect seems to be ignoring the proxy profile setting, and that option isn’t even listed in the documentation.

This might be worth a call to EBSCO to clear up, but frankly if it has taken this long for me to stumble across one of these Google search hits I’m not sure how often our users actually get this far. I’ll probably put that call on the “if-I-have-nothing-else-better-to-do” list, and if I ever get to it or this somehow magically gets resolved, I’ll post an update on this blog post. Thanks for listening.

In June, a new service that speeds access to life sciences literature reached a milestone. Called PubGet, it is a service that reduces the number of clicks to the full text of an article, and the milestone was activating the 50th institution using its service. Using its own proprietary “pathing engine”, it links directly to the full text on the publisher’s website. PubGet does this by understanding the link structure for each journal of each publisher and constructing the link to the full-text based on information from the citation. The PubGet service focuses on the life sciences journals indexed in PubMed — hence the play on names: PubMed to PubGet.

How It Works

Link Resolver screen for Christensen article

EBSCOhost screen for Christensen article

Typical View of a PubGet Article Display

The pathing engine is one of three components that make up the service. The other two are a search engine and a personalization feature. The search engine indexes the citation and abstract fields; it is not nearly as sophisticated as the thesauri-driven search engine native to PubMed, but it does the job for cases when you have a known citation. The personalization feature allows you to tie your account on PubGet to an institution, and with that knowledge the PubGet service can know exactly what digital rights your institution has for each journal and can create links to the full-text article that go through your institution’s proxy server. The account system also enables you to have new articles matching your search criteria sent to you and to mark articles in the search results for later bulk downloading (via a Firefox plugin).¹

Thinking About PubGet in a Wider Information Ecosystem

It would be nice if PubGet could be set up as an OpenURL target, and when it receives a request translates it to the direct link to the full-text using its pathing engine. That way I could set up PubGet as the OpenURL resolver in my PubMed account, and the article links in PubMed would automatically go to the full text. I don’t know how this would work as a business model for PubGet, though, because as an OpenURL resolver is this manner, it makes the PubGet website invisible — through a series of browser redirects I’d go from PubMed to PubGet to the publisher site. (If the point is to make money selling advertising for related industries, a configuration that completely by-passes any visible signs of PubGet would cut into that revenue source.)

As I was sharing background on PubGet with Thomas Dowling, a colleague at OhioLINK, he pointed out something I didn’t know about OpenURL: it is within the standard to specify a “service type” in the OpenURL Context Object. Section 5.1 of the NISO standard for OpenURL says a service type is “The resource that defines the type of service (pertaining to the Referent) that is requested.” And there are indeed service types registered as part of the SAP2 Community Profile: abstract, citation, fulltext, holdings, ill, and any. So the recipient of an OpenURL request, using the “fulltext” Service Type, should be able to replicate the proprietary PubGet pathing engine using a standard OpenURL structure. In a brief bit of experimentation, though, I was not able to find an OpenURL resolver that a) knew how to handle a Service Type parameter, and/or b) knew how to honor that parameter by getting directly to the full text. As OpenURL undergoes its 5-year review this year, it might be worthwhile to emphasize this part of the standard with examples and descriptions of best practices so it is more widely adopted.

Other Articles on PubGet

• Got PubMed? Pubget Searches and Delivers Scientific PDFs, Bio-IT World, June 10, 2009, By Kevin Davies
• Recommended Website of the month – Pubget, Information Service based at ScHARR at The University of Sheffield, June 9, 2009
• Pubget — useful, growing resource for anyone interested in research, ResearchBlogging.org news, June 10, 2009, By Dave Munger
• Pubget Speeds Up Science Journal Searches, Provides Marketing Tools, Xconomy, June 23, 2009, By Ryan McBride
• Get PDFs ASAP with Pubget, Bitesize Bio, June 25, 2009, By Carrie Iwema

Footnotes

1. Since the articles are not held within the PubGet service itself, the bulk article downloading function requires a Firefox plugin so that the article requests come from your browser to the publisher’s site.

Earlier this week I received an e-mail from the director of the ISSN International Center announcing a session at the ALA Annual Conference in Anaheim to talk about the “linking ISSN”. Abbreviated ISSN-L, this is a new addition to the revised ISSN standard (ISO 3297, published last August) that allows for the collocation of separate ISSNs under a single ISSN-L. The ISSN standard now explicitly states that an ISSN is a unique identifier for a specific serial in a defined medium. In other words, separate ISSN should be assigned to each different medium version of a serial. The ISSN-L table brings these separate ISSNs together.

The FAQ I received that goes along with the e-mail announcement has several interesting statements. I’ve extracted the most interesting, at least from my perspective, here:

The purpose of the linking ISSN is to provide a tool for grouping, or collocating, the various medium versions of a resource, for instance, the print and online versions of a journal. … Those involved in the production, distribution, management of, and access to serial resources have expressed the strong desire that the ISSN system meet two different needs:

• The need for the ISSN to identify the various medium versions of a continuing resource, for product management purposes. To meet this need, separate ISSN are assigned to the various medium versions of a resource.
• The need for a collocating, or grouping mechanism that would bring together various medium versions, and thus facilitate content management. The linking ISSN (ISSN-L) has been defined to meet this currently unmet need.

The linking ISSN is a new function for the ISSN system — not a new identifier. … The first ISSN assigned in the ISSN Register to any medium version of a continuing resource is designated by default to function also as the linking ISSN and applies to all other medium versions of that resource identified in the ISSN Register. The linking ISSN is labelled (for eye-readable purposes) as “linking ISSN” or “ISSN-L”. A linking ISSN is designated for each continuing resource identified in the ISSN Register, even if the continuing resource is issued in only one medium. Only one linking ISSN is designated regardless of how many different medium versions of a continuing resource exist.

The ISSN-L should always be treated, for computer processing purposes, as a separate data element. For example, in MARC formats, which are used in the ISSN Register, ISSN-L is input in a separately tagged subfield in each of the ISSN Register metadata records to which it pertains. It is important to note that ISSN-L should be processed and used separately from medium-specific ISSN. In applications based on tables or indexes, ISSN-L should not be included in the same tables or indexes as medium-specific ISSN.

The designated ISSN-L is made available in several different ways:

• via a table which lists the ISSN-L and the corresponding ISSN linked to the ISSN-L. This table is available free of charge on the ISSN IC web site. [See note below.]
• via the ISSN Register: (each metadata record in the ISSN Register includes the medium-specific ISSN assigned to the resource described in the record, and the designated linking ISSN, as separate data elements);
• via the ISSN National Centres, which communicates to publishers the ISSN-L designated for newly-assigned ISSN,
• via the resources themselves, provided that publishers print or display this information according to the recommendations in the standard.

In order for the ISSN-L to work effectively, publishers will need to clearly indicate when they are using an ISSN-L as opposed to an ISSN. The ISO standard’s recommendations for printing and displaying ISSN-L are as follows: the linking ISSN shall be clearly distinguished as such by use of the label ISSN-L. In such cases, the label ISSN-L shall be written in uppercase and a space shall precede the 8 digits of the linking ISSN. Example: ‘ISSN-L 0251-1479′.

No programmatic method can be used to determine ISSN-L on the basis of one of the medium-specific ISSN, nor is there a programmatic way to determine the group of medium-specific ISSN associated with one ISSN-L. This is due to fundamental characteristics of the ISSN system: ISSN have no inherent meaning, and they are distributed sequentially. ISSN are assigned by national centres around the world, and a new medium version may appear at any time, perhaps published in a different country; this cannot be predicted and thus there is no programmatic way to associate an ISSN with its corresponding ISSN-L.

The assignment policy of the Standard now explicitly specifies that ISSN is a unique identifier for a specific serial in a defined medium. Therefore separate ISSN are assigned to each particular medium version of a serial. … If some publishers use the same ISSN for different medium versions of a serial, they deprive their users of the means to identify the medium- specific versions of that serial for ordering, claiming, etc. However, this should not interfere with the ISSN-L. The single ISSN will become the ISSN-L that can be used for collocating functions.

ISSN-L is a tool that aims at facilitating collocating functions. To perform these functions adequately, ISSN-L and the related ISSN have to be present in OpenURL knowledge bases. At this time, various scenarios can be envisaged. The desired end result is described as follows: The request must use the data available in the citation. It is the job of the resolver to match the identifier to the appropriate resource. It is the resolver that will make use of ISSN-L to relate the various medium of an ISSN to each other and find one to satisfy the request. One should be able to put in a request (for example an OpenURL) using any of the ISSN and separately and additionally request that the electronic copy is desired.

One note: I can’t find the ISSN-L table on the http://www.issn.org/ website. In a follow up discussion with Françoise Pellé (Director of the ISSN International Centre) I learned that it isn’t there yet, but they intend to put it there.

This is an interesting, well, kluge. It provides a neat amount of backwards compatibility — for publications that only have one medium, that publication’s ISSN automatically becomes its ISSN-L. The publishers (presumably) would need to take proactive action to tell the ISSN registrar that two ISSN are two mediums of the same publication; hopefully the word will get out and all affected publishers will do so.

It doesn’t effectively replace the xISSN service from OCLC because the ISSN-L table only gives current links. The description of xISSN says ISSNs are related in two different ways: different editions of same serial (such as print and online editions) and historical relationships (ISSN changes that result from title changes, mergers, splits, etc.). ISSN-L only handles the former (different editions) relationship type, not the latter (historical) relationship type. The ISSN-L table is (reportedly) free, however, and the xID service require an OCLC network membership. (While this posting was in draft form, Tim McCormick of OCLC announced that effective immediately, xID services from OCLC — that is, xISBN, and the forthcoming xISSN — will be included at no additional cost with all OCLC cataloguing subscriptions.

I hope to hear more after ALA Annual. Unfortunately, I think I have a conflict with the proposed meeting on Friday afternoon of ALA, so if anyone else hears anything please blog about it. (Trackbacks to here would be appreciated.)

Updates from Information at ALA

MARC codes were approved by MARBI a few months ago. Current ISSN-L identifiers will be put in MARC21 field 022 subfield ‘l’. Cancelled ISSN-L identifiers will be put in MARC21 field 022 subfield ‘m’. (Every record will have a subfield ‘l’ or a subfield ‘m’, even if it is in a single format.)

Retrospective designation uses lowest ISSN from the cluster linked via 776 field. As on-going ISSN assignments are made, the ISSN-L will be the first assigned out of any media. (May not always be the lowest in numerical order because of how ISSNs are allocated to ISSN centers.)

The crossreferencing linking table for ISSN-L has not yet been published. The international ISSN center is also considering a web service that would send back all of the associated ISSNs for an ISSN-L.

Launch is at IFLA in August 2008. Expected implementation before end of 2008. (There is of course some catch-up time as library automation vendors add this capability to individual systems.)

The text was modified to remove a link to http://ala.org/ala/lita/litamembership/litaigs/igstandards/standards.cfm on June 9th, 2011.

As a result of discussions coming from the OAI-ORE open meeting in Baltimore in the first week of March, the document editors released a new version of the ORE alpha specifications (labeled “0.3″) earlier this month to coincide with the open meeting at Southampton, UK. In a message to the technical committee, Herbert Van de Sompel summarized the changes as:

• Data Model: changes in the relationship between Resource Map and Aggregation; introduction of a solution regarding the reference in context; revised approach regarding nesting aggregations.
• Atom serialization: Significant revision of the mapping from the ORE Model to Atom.
• Introduction of an ORE Primer (formerly called the data model overview)
• Introduction of a document describing implementation issues regarding HTTP URIs for Aggregations and Resource Maps.
• RDF serialization document: This document was first made available in alpha 0.2. It deals with RDF/XML but also RDFa that can, for example be used, in splash pages.

Comments are still welcome, and the OAI-ORE discussion list has been quite active the past few weeks. The document editors are aiming for a beta release of the specification in mid-May.

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.

Here is a pair of papers that I’d like a chance to digest at some point. The first is “Recommending Related Papers Based on Digital Library Access Records” by Stefan Pohl, Filip Radlinski, and Thorsten Joachims. According to the notes on the paper, it is to appear in proceedings of JCDL’07. The abstract:

An important goal for digital libraries is to enable researchers to more easily explore related work. While citation data is often used as an indicator of relatedness, in this paper we demonstrate that digital access records (e.g. http-server logs) can be used as indicators as well. In particular, we show that measures based on co-access provide better coverage than co-citation, that they are available much sooner, and that they are more accurate for recent papers.

This is a two-page summary, with the meatier version being “Using Access Data for Paper Recommendations on ArXiv.org”, a masters thesis written by Stefan Pohl. This one is about 70 pages. The abstract is:

This thesis investigates in the use of access log data as a source of information for identifying related scientific papers. This is done for arXiv.org, the authority for publication of e-prints in several fields of physics.

Compared to citation information, access logs have the advantage of being immediately available, without manual or automatic extraction of the citation graph. Because of that, a main focus is on the question, how far user behavior can serve as a replacement for explicit meta-data, which potentially might be expensive or completely unavailable. Therefore, we compare access, content, and citation-based measures of relatedness on different recommendation tasks. As a final result, an online recommendation system has been built that can help scientists to find further relevant literature, without having to search for them actively.

Stefan’s work would seem to bring the old adage “Do as I Do (access), Not as I Say (cite)” to bear on information retrieval. More fluid and dynamic than using PageRank — or web citation — “co-access” would seem to allow the wisdom of the crowds to become more apparent.

I had a need for a survey of the metadata namespaces used by OAI-PMH repositories, so I wrote up a quick shell script and XSLT style sheet to parse through the list of Registered Data Providers at the OpenArchives.org website. The results of this effort are pretty interesting. Some of them:

• Dublin Core is, as you would expect, the highest-used descriptive metadata standard. Every service — or at least those that reported using any namespace at all — reported Dublin Core as a record harvesting option. For some, it was the only option (which I find rather sad). One problem, though, comes in with the variety of namespace URIs declared that all appear to be semantically the same thing: http://www.openarchives.org/OAI/2.0/oai_dc/, http://www.openarchives.org/OAI/2.0/oai_dc (note the missing trailing slash), http://purl.org/dc/elements/2.0/ (used exclusively by the ProQuest Digital Commons product, it would seem), and http://purl.org/dc/elements/1.1/ (the difference between 2.0 and 1.1 is not clear to me). In order to be processable, there must be an exact string match of the namespace URI — so even that missing trailing slash is significant!
• The next most popular namespace URI is http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1807.txt, which semantically would seem to identify the IETF RFC 1807 on a Format for Bibliographic Records. You can see what one of these things looks like — although RFC1807 predates XML (it was approved by the IETF in mid-1995), it looks like someone turned the metadata format into XML along the way. Very interesting…
• The next most popular is http://www.ndltd.org/standards/metadata/etdms/1.0/ — corresponding to the Interoperability Metadata Standard for Electronic Theses and Dissertations — followed closely by http://www.openarchives.org/OAI/1.1/oai_marc — which fell out of favor years ago with the publication of MARC21 by the Library of Congress (which goes by the namespace http://www.loc.gov/MARC21/slim). Unfortunately, it doesn’t seem to have been picked up by the majority of OAI-PMH data providers that used the older oai_marc schema.
• As you get towards the bottom of the first list, there are all sorts of interesting variants on qualified Dublin Core and other one-off schemas.

Your thoughts and observations? I’ve filed away the UNIX script and XSLT style sheet. If there is interest in seeing something like this in the future, let me know and I can dig them out.

The text was modified to remove a link to http://dltj.org/misc/oai-pmh-namespace-report.html on December 30th, 2010.

The text was modified to remove a link to http://www.umi.com/umi/digitalcommons/ on January 19th, 2011.

The text was modified to update a link from http://www.ndltd.org/standards/metadata/current.html to http://www.ndltd.org/standards/metadata/etd-ms-v1.00-rev2.html/ on January 19th, 2011.

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.

In the past few months a new group has formed to tackle the problem of representing and exchanging complex digital objects in a web-based environment. I am proud to serve on the technical committee for this group and over the next few postings I’m aiming to introduce the library community to the work of the Open Archives Initiative Object Exchange and Reuse group and seek the feedback of the wisdom of this crowd.

Vision and Scope

OAI Object Reuse and Exchange (ORE) is a new effort conducted under the umbrella of the Open Archives Initiative. The summary vision statement is to develop, identify, and profile extensible standards and protocols to allow repositories, agents, and services to interoperate in the context of use and reuse of compound digital objects beyond the boundaries of the holding repositories. A key aspect of this statement is that it refers to working with objects, not about metadata only. In that way, the ORE work is set apart from the previous OAI work, the Protocol for Metadata Harvesting (PMH).

The aim of the ORE effort is to promote (through creation or endorsement) effective and consistent mechanisms:

• to facilitate discovery of compound digital objects;
• to reference (or ‘link to’) these objects (as well as parts thereof);
• to obtain a variety of disseminations of these objects;
• to aggregate and disaggregate objects; and
• to enable processing of objects by automated agents.

Although these mechanisms may apply to more general web activities, the use cases we are working from are firmly bounded to the needs of the academic community. Generally speaking, those use cases seek to establish the basis for a digital scholarly communication system composed of two types of systems: a) applications that manage content (such as institutional repositories); and b) applications that leverage managed content (such as search engines, personal productivity tools, and data and text analysis services). Of course, other application domains are possible, but like the initial OAI-PMH, the intent is to start with a domain with which we are familiar with an eye towards more general applications as appropriate.

Compound Digital Objects

Key to understanding the ORE vision and scope is a definition of the phrase “compound digital object.” In the case, a compound digital object is content with multiple components that vary on:

• Content, or semantic, types (including: text, datasets, simulations, software, dynamic knowledge representations, machine readable chemical structures, bibliographic and other types of metadata);
• Media types (including IANA registered MIME types and other type/format registries such as GDFR);
• Network locations (including content from institutional repositories, scientific data repositories, social networking sites and the general web); and
• Relationships (where the digital object is part of a complex graph of objects related by lineage, versions, and derivations).

In the abstract, this definition is understandably hard to grasp. There are some conceptual examples the technical committee uses to keep focus on the task at hand. One example is a paper in the arXiv repository with different disseminations. Although the primary artifact in this example might be simply the paper itself, in even this case there is a compound digital object surrounding that artifact with components that represent the paper in PDF and Postscript formats, Dublin Core descriptive metadata, and an HTML “splash page” for the paper. Another example is that of an issue of an overlay journal built from distributed ePrints from different repositories. The nature of “the paper” itself is changing: in e-science the text of the paper is combined with data sets and simulations; in e-humanities, the text of the paper is combined with primary content (such as scanned items) and the scholar’s derived content.

Description of Work

So an accurate perspective on the OAI-ORE work is that it seeks to enrich the content sharing landscape. ORE is about enabling digital objects to float between systems that manage content and systems that leverage managed content. In the first category are applications such as institutional repositories, research-group and managed personal (ePortfolio) repositories, discipline-oriented repositories, publisher repositories, dataset repositories, cultural heritage repositories, learning object repositories, and digitized book and manuscript collections. In the second category are applications such as search engines, authoring tools, citation management, collaborative environments, social network applications, data/text mining applications, relationship graph analysis tools, preservation services, workflow tools, and report generation tools.

A key point to remember is that OAI-ORE is not necessarily about transferring the digital assets from one system to another. It is the goal of the technical work to enable new, complex objects to be built without necessarily transferring all of the component parts from disparate content repositories to a single system. (Reflect for a moment on the overlay journal concept — the papers that make up the issue of the overlay journal could certainly remain dispersed in the repositories where they are originally located; the overlay journal pulls together the contents in a virtual construct that represents an issue of that overlay journal.) In some use cases, transfer of the digital object content is required; preservation mirroring is one such example. In many cases, however, full transfer is not permitted (by terms of use), impractical (as in a dataset that is terabytes in size) or simply superfluous.

At its first meeting, the technical committee identified some motivating use cases to guide our work. At this point they are little more than general statements of the activities that can be done better with an ORE framework in place. Over the course of the next few weeks the technical committee will elaborate on these general statements and turn them into stories.

• Find, collect, analyze, relate, and publish data-oriented scholarly objects
• Preserve compound digital objects
• Remote submission of compound digital objects
• Citation management
• Object equivalence recognition (de-duping) to aid resource discovery
• Graph-based quality assessment of data-centric scholarship

OAI-ORE Project Organization

The character of the project organization is similar to that of the Protocol for Metadata Harvesting effort. Carl Lagoze (Cornell University) and Herbert Van de Sompel (Los Alamos National Laboratory) are the principle investigators on the project. They coordinate the efforts of an international group of volunteers that form an Advisory Committee, a Technical Committee (of which I am a member) and a Liaison Committee. The membership lists for these committees are available on the OAI-ORE website. It is worth noting that the participants are not exclusively from the library domain. In particular, there is an emphasis not just on text/image/video objects but also scientific data objects. The Andrew W. Mellon Foundation is funding the work for a 24-month period that began in October 2006 with additional support from the National Science Foundation.

The impetus behind the OAI-ORE effort was a meeting in April 2006 of representatives from institutional repository projects, scholarly content repositories, registry projects, and various other projects that touch on interoperability. See http://msc.mellon.org/Meetings/Interop/ or more information.

The ORE work does not imply that the OAI-PMH specification is being dropped or replaced. OAI-PMH will continue to exist as one approach to interoperability. OAI-ORE will complement OAI-PMH when richer functionality is desired as part of a multi-level interoperability stack. In fact, one might consider OAI-ORE to be resource centric in contrast to OAI-PMH’s metadata-centric approach.

The technical committee has met once (the report of the meeting is available from the ORE website) and will be conducting a conference call this week leading up to a second face-to-face meeting in May. Right now we are fleshing out the use cases as a tool for testing models that we create or adapt from other uses. We want to make sure what we’re specifying will really work in our application domain. Once we have a good sense of what a model of the ORE scope of work entails, we’ll review existing related technologies with the intent of adapting what is currently available to meet the needs of the ORE model and only creating new specifications and protocols when it is really necessary. Some early candidates of related technologies are OAI-PMH, RSS/ATOM, OpenURL, and METS/DIDL.

The technical committee has agreed amongst itself to use a tag of ‘oaiore’ in the various social web tools (Technorati, Connotea, and del.icio.us for example) as a way to co-locate material on this topic. Others are encouraged to do the same. Fellow technical committee member Pete Johnson (with follow up) has already started a conversation, and you can listen to an interview with Herbert van de Sompel via EDUCAUSE.

In a subsequent postings, I’ll go into some detail about the inner workings of “The Web Architecture” and how it is both a help and a hindrance to the interaction of compound digital objects in our domain, and how it is a force too powerful to be ignored in either case.

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