This is a history of OpenURL, followed by a summary of its capabilities, and a discussion of the extent to which it can address the requirements of the learning content federations being supported by the FRED project.

Open URL in libraries

Rather than giving an historically accurate account of OpenURL, we will couch the entire discussion in terms of identifiers, since that has been the main framework for FRED to deal with object retrieval.

Say you're browsing a Nature article in an online repository. The Nature article includes in its bibliography a reference to a paper in Science. As Elsevier (or whoever publishes Nature), you would like to provide a hyperlink from Nature to the Science paper.

Now, by 1998 this problem was already solved: you could link to the DOI of the Science paper: 

 * <a href="doi:10.234/3478"> Stalin, J.V. 1953. On Marxism and Linguistics. Science 43: 856-899. </a>

That DOI, 10.234/3478, provides an identifier for Stalin's paper; it's persistent, it's registered, and it's resolvable.
The catch is, where that DOI resolves to. By default, it takes you to Elsevier's homepage, with maybe some metadata about "Marxism and Linguistics", and an invitation to buy the PDF for $4000.

Now that's no good. If I'm at Melbourne Uni, I want the URL to point to the Melbourne Uni Library copy of the paper (if available). I don't want to be sent off to Elsevier.

So we can add the Melbourne Uni PDF URL to the Handle record for 10.234/3478, right?

Well, no, because there are two problems:

  1. Every university under the sun will want to put their local URLs, once they've licenced the content, into 10.234/3478 ; that Elsevier Handle is going to be nightmarish to maintain, and Elsevier is not about to turn the Handle record over for updating by 4000 institutions anyway.
  2. Every university wants the DOI to resolve to their own copy of the PDF, not someone else's. Which means someone has to create a smarter Handle server, to pick the URL specific to a particular university; and not --- as now happens --- a random URL.

Now, the link is not actually a doi:10.234/3478 link at all. It is a http://hdl.handle.net/10.234/3478. So I'm saying that instead of http://hdl.handle.net/10.234.3478 always resolving to http://elsevier.com/mucho-dinero/10.234/3478, I want it to resolve to http://lib.unimelb.edu.au/nature/nature3478.pdf if I'm at Melbourne Uni, to http://lib.monash.edu.au/pubs/10/234/nature3478.pdf if I'm at Monash, etc.

But Elsevier want to create only one link, for all instances of the PDF it sends out to universities. They shouldn't be handcrafting different URLs for different customers. They should just link to something that looks like http://hdl.handle.net/10.234/3478.

What we want is an appropriate copy service. This service is given an identifier, and resolves to your instance of the identified resource. http://hdl.handle.net can't do that.

Van de Stompel's solution was simple. Way too simple in fact. Each university knows what the URL its DOI resolves to is, right? Well, don't insert a full URL into the PDF at Elsevier at all. Instead:

What have we achieved by this?

It's not a good solution for static content: you have to be able to insert a server name into the URL at runtime. But it does the job: you have your own database, at openurl.unimelb.edu.au , tell you where your copy of 10.234/3478 lives, without having to edit or even consult the Handles record maintained by Elsevier.
Now IDs are not the only way to identify a record. You could identify a record by Author+Title. Or ISSN. Or anything you want:

Definition

DOI, Author, Title, ISSN --- they're all just attributes of a record. So I need to define which attributes I can query by, to retrieve a matching record.

Notice that these attributes (or combinations of them) act as database keys. The idea is that each query retrieves a single item as the appropriate copy. This is not a search: you would not have a hyperlink to http://________/?author=Stalin, because you don't want to look at the complete works of Stalin: links are always to specific resources.

The attributes of the object you're looking for determine what the URL is going to be. But that's not the only object involved:

So Van de Stompel ended up creating OpenURL.

Because it's a consistent syntax, any number of vendors can use it to formulate links to appropriate copies, without worrying about the details of local systems.

Because it's extensible (you can make up your own schemas), any number of attributes can be invoked to further customise the URL retrieved to user requirements.

That's the promise of OpenURL. However:

So what do OpenURLs actually look like?

Data Model

OpenURLs are all about changing the resolution of the query based on context. The link should be different if I'm in Melbourne Uni or at Monash, if I'm visually disabled or not, if the web page with the link is in French or English, and so on.

OpenURL has philosophised context into SIX entities. Each of these entities has attributes you can use to refer to them by. Each entity has a schema for those attributes.

Some entities are more obviously relevant than others.

Let's run through this in our library scenario.

Jock McJock is reading an article by Lenin in Bolshevik Quarterly. He's reading it through Omsk Uni's library. Bolshevik Quarterly is put online by Komsomol Press, and that's who Omsk Uni have licensed the content from. The Lenin article has a hyperlink to an article by Stalin in Communist Daily. Ideally, that hyperlink should link to the full-text article by Stalin in the Omsk Uni copy of Communist Daily. Omsk Uni has licensed Communist Daily from Comintern Publishers.

Why do these entities matter?

Let's try that again with an e-learning example:

Shane, a student at Cairns High, is looking at a learning object on volcanoes. They are accessing the learning object through Learning Place, the Queensland school jurisdiction server. The learning object was created at the e-learning provider TLF --- who embedded "see also" links in the metadata to other related objects; for instance, a learning object on Sicily. When the student clicks on these links, they are meant to get abstracts of the learning objects, and links to the local full version where available.

Let's go further and see what values we might need.

OpenURL Parameters

So let's look at the parameters:

The metadata formats, serialisations, namespaces, transports, etc. etc. get profiled as community profiles. The San Antonio Community Profiles define OpenURL as used by libraries, with key-value pairs and XML.
A FRED customisation of the OpenURL for the Sicily example above could look like this: 

http://openurl.tlf.edu.au?
  ctx_ver = Z39.88-2004                         # We're using the Z39.88 (OpenURL) standard for key-value pairs
  rft_id = info:hdl/100.200.1/7348 &            # I'm retrieving the appropriate copy of Handle 100.200.1/7348, the Sicily object
  req_val_fmt = info:hdl/100.200.1/72 &         # I've created a format for requester metadata -- and made it a Handle. This metadata record contains:
  req.id = shane@cairns.hs.edu.au &             # Shane's email address
  req.location = cairnsHS &                     # Shane's location, using a vocabulary
  svc_id = http://tlf.edu.au/svc/abstract &     # IDs belong to a registered namespace; I'll just use a URL to specify the "abstract" service, rather than make up a metadata format
  res_id = http://learningplace.qld.edu.au &    # I'll resolve at Learning Place by default...
  res_id = http://openurl.tlf.edu.au &          # but I'll keep TLF in there as a backup resolver
  rfr_id = http://www.tlf.edu.au &              # The OpenURL appears in TLF-generated content
  rfe_id = info:hdl/100.200.1/7347              # This link appears in TLF7347, the Volcano object