OpenURL 1.0
On this page:
Background Information
The OpenURL 1.0 specification is formally titled, The OpenURL Framework for Context-Sensitive Services, and revolves around the definition, representation and transport of an information construct called a ContextObject. Just like OpenURL 0.1, OpenURL 1.0 can transport information using HTTP GET and POST methods.
What is a ContextObject?
A ContextObject is the formal representation of what a 0.1 OpenURL represents. A ContextObject is an information construct to describe a referenced resource, the network context in which the resource is referenced, and the context in which the service request takes place.
A reference situation from NISO [1, pg. 11]:
Caltech has an institutional linker server with URI 'http://links.caltech.edu/menu'.
Jane Doe, a Caltech student with e-mail address jane.doe@caltech.edu, reads the following electronic scholarly article in the Elsevier ScienceDirect® collection:
McArthur, James G. et al. 2001. p27-p16 Chimera: A Superior Antiproliferative for the Prevention of Neointimal Hyperplasia. Molecular Therapy. 3(1) 8-13. <doi:10.1006/mthe.2000.0239>
In the reference list of that article, she comes across a reference to the following article:
Bergelson, J. 1997. Isolation of a common receptor for coxsackie B viruses and adenoviruses 2 and 5. Science. (275) 1320-1323. <doi:10.1126/science.275.5304.1320> <pmid:9036860>
The ContextObject data structure captures relevant information for the delivery of context-sensitive services pertaining to a referenced resource. Based on a study of real-world OpenURL 0.1 usage, the
Committee included the following in the ContextObject data structure:
- a description of the referenced resource itself (the Bergelson article),
- a description of the resource that makes the reference (the McArthur article), and
- a description of four other resources that are useful in fulfilling service requests pertaining to the referenced resource:
- the agent requesting the service (Jane Doe),
- the type of service that is requested (full text),
- the system at which the service request is targeted (Caltech linking server), and
- the system where the service request originates (ScienceDirect®).
A ContextObject consists of the following Entities [1, pg. 11]:
- a Referent: A resource that is referenced on a network and about which the ContextObject is created
- a ReferringEntity: The resource that references the Referent
- a Requester: The resource that requests services pertaining to the Referent
- a ServiceType: The resource that defines the type of service (pertaining to the Referent) that is requested
- a Resolver: The resource at which a service request pertaining to the Referent is targeted
- a Referrer: The resource that generates the ContextObject
Example 1 uses the scenario introduced above to illustrate all Entities of the ContextObject.
Entity |
Example |
---|---|
Referent |
The scholarly article by Bergelson |
ReferringEntity |
The scholarly article by McArthur |
Requester |
Jane Doe |
ServiceType |
Full text of the Bergelson article |
Resolver |
The Caltech linking server |
Referrer |
Elsevier's ScienceDirect® |
The ContextObject is created to enable the delivery of services pertaining to the Referent, which is at the core of the ContextObject. The descriptions of the ReferringEntity, the Requester, the ServiceType, the Resolver, and the Referrer express the Context in which the Referent is referenced and in which the request for services pertaining to the Referent takes place.
What is a Community Profile? An OpenURL Framework Application?
A Community Profile describes the core characteristics of an OpenURL Framework Application. An OpenURL Framework Application is a networked service environment for the transportation of ContextObject Representations.
[1, pg. xi]:
The initial Registry contains two Formats to express ContextObjects: the Key/Encoded-Value Format and the XML Format. Communities may define and register new ContextObject Formats, thereby enabling the creation of new OpenURL Framework Applications. The initial Registry also contains a suite of HTTP(S)-based methods to transport representations of ContextObjects. Two Community Profiles are included in the initial content of the Registry. The Committee created these to provide support for the existing OpenURL 0.1 application as used in the scholarly-information community under this Standard.
The Level 1 San Antonio Community Profile (SAP1): A Community Profile that is based on the Key/Encoded-Value Format to represent ContextObjects. It uses Namespaces and Metadata Formats that are important to the scholarly-information community. In the definition of this Community Profile, care has been taken to provide a certain level of backward compatibility with the OpenURL 0.1 specification, while at the same time providing enhanced capabilities to describe referenced resources and the network context in which the references occur. See attached: SanAntonioProfileLevel1-2004.pdf.
The Level 2 San Antonio Community Profile (SAP2): A Community Profile that is based on the XML Format to represent ContextObjects. It uses Namespaces and Metadata Formats that are important to the scholarly-information community. It introduces a new level of expressiveness to describe referenced resources and the network context in which the references occur. [1, pg. xi]
Another, trial Community Profile that may be of interest to us is the Dublin Core Community Profile. This profile uses the Dublin Core metadata element set. See attached: DublinCoreProfile-2004.pdf.
The following table compares a 0.1 OpenURL to a 1.0 OpenURL following the Level 1 San Antonio Community Profile:
OpenURL 0.1 |
OpenURL 1.0 (SAP1) |
---|---|
http://www.example.com/resolver?genre=article |
http://www.example.com/resolver?url_ver=Z39.88-2004 |
&atitle=p27-p16 Chimera: A Superior Antiproliferative |
&url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx |
&title=Molecular Theory |
&rft_val_fmt=info:ofi/fmt:kev:mtx:journal |
&aulast=McArthur |
&rft.genre=article |
&aufirst=James |
&rft.atitle=p27-p16 Chimera: A Superior Antiproliferative |
&date=2001 |
&rft.jtitle=Molecular Theory |
&volume=3 |
&rft.aulast=McArthur |
&issue=1 |
&rft.aufirst=James |
&spage=8 |
&rft.date=2001 |
&epage=13 |
&rft.volume=3 |
|
&rft.issue=1 |
|
&rft.spage=8 |
|
&rft.epage=13 |
Sakaibrary Implementation
For use in Sakaibrary, I suggest implementing the Level 1 San Antonio Community Profile (SAP1). It provides backwards compatability with OpenURL 0.1 (using a Hybrid OpenURL), is geared towards the scholarly-information community and has developed and clearly defined OpenURL 1.0 Namespaces and Metadata Formats that are registered in the OpenURL 1.0 Registry.
What are Namespaces and Metadata Formats?
Namespaces and Metadata Formats are used to define how to represent Entities of ContextObjects. Namespaces work exactly the same in OpenURL 1.0 as they do in XML. Metadata Formats are Namespaces, but they are specific to the realm of how to structure the metadata of various resources. In the case of the SAP1, there are defined Metadata Formats for resources such as journals, books, patents, service types for the scholarly-information community and dissertations. Using these Namespaces and Metadata Formats, resources such as journals, can be represented in a consistent way within context-sensitive linking applications. The Metadata Format for Journals in the SAP1 is linked below in the Links, Implementation section.
What is a Hybrid OpenURL?
A Hybrid OpenURL is an OpenURL that is compatible with both version 0.1 and version 1.0 OpenURL resolvers. It contains both version 0.1 and version 1.0 keys. It is expected that OpenURL resolvers will deal gracefully with foreign keys that they do not understand by ignoring them [2, pg. 38].
Given the following information:
OpenURL 0.1 |
OpenURL 1.0 (SAP1) |
---|---|
http://example.org/myResolver? |
http://example.org/myResolver? |
sid=myid:mydb |
url_ver=Z39.88-2004 |
&id=doi:10.1126/science.275.5304.1320 |
&url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx |
&id=pmid:9036860 |
&rfr_id=info:sid/myid.com:mydb |
&genre=article |
&rft_id=info:doi/10.1126/science.275.5304.1320 |
&atitle=Isolation of a common receptor for coxsackie B |
&rft_id=info:pmid/9036860 |
&title=Science |
&rft_val_fmt=info:ofi/fmt:kev:mtx:journal |
&aulast=Bergelson |
&rft.genre=article |
&auinit=J |
&rft.atitle=Isolation of a common receptor for coxsackie B |
&date=1997 |
&rft.jtitle=Science |
&volume=275 |
&rft.aulast=Bergelson |
&spage=1320 |
&rft.auinit=J |
&epage=1323 |
&rft.date=1997 |
|
&rft.volume=275 |
|
&rft.spage=1320 |
|
&rft.epage=1323 |
A Hybrid OpenURL built from the above information would look like the following:
Hybrid OpenURL |
---|
http://example.org/myResolver? |
url_ver=Z39.88-2004 |
&url_ctx_fmt=info:ofi/fmt:kev:mtx:ctx |
&rfr_id=info:sid/myid.com:mydb |
&sid=myid:mydb |
&rft_id=info:doi/10.1126/science.275.5304.1320 |
&rft_id=info:ofi/pmid:9036860 |
&id=doi:10.1126/science.275.5304.1320 |
&id=pmid:9036860 |
&rft_val_fmt=info:ofi/fmt:kev:mtx:journal |
&rft.genre=article |
&rft.atitle=Isolation of a common receptor for coxsackie B |
&rft.jtitle=Science |
&rft.aulast=Bergelson |
&rft.auinit=J |
&rft.date=1997 |
&rft.volume=275 |
&rft.spage=1320 |
&rft.epage=1323 |
&genre=article |
&atitle=Isolation of a common receptor for coxsackie B |
&title=Science |
&aulast=Bergelson |
&auinit=J |
&date=1997 |
&volume=275 |
&spage=1320 |
&epage=1323 |
As you can see, the Hybrid OpenURL becomes almost twice as long as a standard OpenURL and contains redundant data.
Links
Background:
- Ex Libris OpenURL Overview - an overview of OpenURL in the context of SFX.
- OpenURL 0.1 spec - a reference for OpenURL 0.1.
- NISO Committee AX - the NISO Committee in charge of the OpenURL 1.0 Standard.
Implementation:
- OpenURL 1.0 Registry - the OpenURL 1.0 Registry contains information imperative to the development of an OpenURL 1.0 application. It defines Namespaces, Metadata Formats and Community Profiles, among other core components, of an OpenURL 1.0 application.
- OpenURL 1.0 SAP1 Journal Metadata Format - the Key/Encoded-Value Format for representing a journal article within the context of OpenURL 1.0 SAP1.
- OpenURL 1.0 Java code from OCLC - have not evaluated this code as yet, but it looks real interesting: "...this service can be configured to support any context-sensitive service within the confines of the OpenURL 1.0 protocol."
References (Attached)
- Z39.88-2004(OpenURL).pdf - OpenURL 1.0 Standard: The OpenURL Framework for Context-Sensitive Services.
- KEV_Guidelines-20041209.pdf - The OpenURL 1.0 Key/Encoded-Value (KEV) Format, Implementation Guidelines.
- SanAntonioProfileLevel1-2004.pdf - The Level 1 San Antonio Community Profile (SAP1) for the OpenURL Framework for Context-Sensitive Services: this document lists all the Core Components of an OpenURL application that SAP1 uses (i.e. Namespaces, Metadata Formats, etc...).
- DublinCoreProfile-2004.pdf - The Dublin Core Community Profile (DCCP) for OpenURL 1.0. This documenet lists all the Core Components of an OpenURL application that DCCP uses (i.e. Namespaces, Metadata Formats, etc...).
- OpenURL0.1.pdf - the OpenURL 0.1 standard. This document contains the format and syntax used in building 0.1 OpenURLs which will be useful for Hybrid OpenURLs.