!! DRAFT FOR TRIAL USE, SUBJECT TO CHANGE !!
Recently, there has been very compelling work by thought leaders in the library information community focussing on the possibilities of embedding metadata in html web pages using OpenURL. (for example, see the obscurely named GCS-PCS list )
Although the possibility to embed OpenURLs in conventional HTML documents has been around for a while, implementation has been almost nonexistent. For a number of reasons, this situation may be rapidly changing.
What has been missing so far is agreement (or even awareness) among the diverse actors on the best way to implement OpenURL in conventional HTML. Example implementations have been reported by Van de Sompel (DLIB) and by Chudnov et al. (working paper) (Ariadne). The intent of the current document is to distill the essence of previous proposals into the simplest convention necessary for the majority of applications to make use of an OpenURL embedded in HTML.
To add a Latent OpenURL to an HTML document, put a NISO 1.0 OpenURL into the "
REL" attribute of an HTML anchor ("
A") tag with
REL attribute set to "
a latent or unactivated OpenURL link:
This latent OpenURL is placed directly below this line:
If you are being served by a compliant activating agent, you will see a link, if not, the line above should be empty.
The same link, after (hypothetical) activation:
This hypothetically activated OpenURL is placed directly below this line:
Find at Example Library
If you are being served by a compliant activating agent, you will see a link, different from "Find at Example Library"
To activate Latent OpenURLs in an HTML document,
?" with the baseurl of the local link server.
The example above shows an empty anchor tag, and the OpenURL is present with an empty baseurl. In the absence of an activating agent, the link will be completely invisible to the user. The page assumes that user or institutional activating agents will fill in anchor text to make the link visible; its layout and design should gracefully accommodate additions. Alternatively, the web page might use a default baseurl (see below) and anchor text for users without access to activating agents.
The use of
REL (relation) attributes to mark the elements with latent OpenURL links is chosen because the
REL attribute has been used in a similar way in a number of other applications.
In HTML, multiple relations can be associated with an element using a single attribute:
REL='rel1 rel2' Activating agents should recognize the
Z39.88 relation even when combined with other relations.
The official designator for the NISO OpenURL standard is Z39.88-2004; we removed year. If activating agent require version information they should look inside the OpenURL. "
OpenURL" as an alternative to "
Z39.88" was considered, but "
Z39.88" was considered to be extremely unlikely to be chosen for any other application, and compatibility was judged to trump other considerations.
In HTML, relations are not case sensitive. Activating agents should recognize "
z39.88" as being equivalent to "
To make it easier for activating agents to deal with the complexities of having to deal with multiple embedded OpenURL formats, this convention requires use of a single format, a specific form of the NISO 1.0 version of OpenURL. By using the NISO standard, embedded OpenURLs can be used with ANY resolver system. Embedded 1.0 OpenURLs are restricted to using the "in-line ContextObject format" and "in-line metadata" for the referent. (In addition to transporting metadata in the key-value pairs of a query string, the full 1.0 OpenURL standard allows metadata objects to be transported "by-reference" using a network pointer and "by-value" in an encoded blob; these forms must not be used in latent OpenURLs.) A simple guide to OpenURL 1.0 implementation is HERE.
(for OpenURL aficionados) There are no format or transport restrictions on ContextObject entities other than the referent.
Activating agents will need to adjust the OpenURL for use with specific resolver systems such as those which only understand version 0.1. This is a straightforward process, which is outlined here in gory detail:
rft." from the book and journal referent metadata keys the OpenURL can be made functional for all known 0.1-only resolver systems.
jtitle" should be replaced by "
btitle" should be replaced by "
genreshould be set to "article" or "book" if it is not already present in the 1.0 OpenURL.
rft_id=info:pmid/" should be replaced by "
rft_id=info:doi/" should be replaced by "
rft_id=info:bibcode/" should be replaced by "
sid=something. In 0.1 OpenURL, the value of sid is more or less a proprietary value, so you can't really convert the OpenURL 1.0 equivalent. So just use it to identify your activating agent.
Our example above starts the latent OpenURL with "?". HTML processing software will typically interpret this as a relative URI and will use the document URI (or the URI specified in a BASE tag) to determine an absolute URI for the anchor element. Thus the latent OpenURL will often point back to the document to which it resides until activating agents have a chance to add a resolver baseURL and anchor. Software that is not aware the latent OpenURL convention may mistake the latent URL for a real one. In most cases this should not be a problem, but embedding sites should expect some odd log entries from ignorant spidering robots. For this reason, it may be useful to specify a default or dummy baseURL in the latent OpenURL.
Dummy baseURLs are urls that don't resolve. The DNS system defines "example.com" and "example.org" as domains that will not resolve to real addresses, and these might be used as dummy baseURL. Similarly, new URI schemes, such as "info" might be used to signify that a URI can be activated into an OpenURL.
Default baseURLs (and default anchor text) can be used when a publisher wants to provide default services for users that do not have OpenURL services available. A default baseURL might be a special purpase resolver, and it migh also be just a static web page address, taking advantage of the fact that web-servers ignore query data when serving static pages. This has been done for the link to the Van de Sompel article cited above.
This specification does not provide means to embed or activate latent OpenURL information in HTML forms.
In this section we list implementations of latent OpenURLs
Note that, for clarity, our displayed examples have not converted ampersand to "&" as they should.
<link rel="Z39.88" title="OpenURL enabled"/>