A brief overview of the Open Archives Initiative and OpenURL

1. A brief overview of the Open Archives Initiative and OpenURL Steve Hitchcock Open Citation Project (OpCit) Southampton University Prepared for Z39.50/OAI/OpenURL plenary session at the JISC DNER All-Projects Synthesis Meeting, Manchester. 24 January 2002

2. Open Archives initiative timeline Conceived as the Universal Preprint Service (UPS). Oct. 1999 First meeting in Santa Fe, NM, a forum to discuss and solve matters of interoperability between author self-archiving solutions (I.e. eprints). Re-named the Open Archives Initiative. Feb. 2000 Santa Fe Convention released, defining the technical and organizational framework. Sept. 2000 OAi extends interoperability framework beyond eprints –develops and promotes interoperability standards that aim to facilitate the efficient dissemination of content– and appoints steering committee.

3. OAi technical framework Feb. 2000 Santa Fe Convention, defines: Open Archives Metadata Set Harvesting interface based on a subset of the Dienst protocol two classes of participants Data providers expose metadata about content Service providers issue protocol requests to data providers Jan. 2001 OAI Metadata HarvestingProtocol (MHP) Version 1.0, an application-independent interoperability framework that can be used by a variety of communities engaged in publishing content on the Web Jun. 2001 MHP Version 1.1 updated for W3C XML Schema specification recommendation of May 2001

4. Key papers on OAi Carl Lagoze and Herbert Van de Sompel The Open Archives Initiative: Building a low-barrier interoperability framework. Joint Conference on Digital LibrariesRoanoke, VA, June, 2001 http://www.cs.cornell.edu/lagoze/papers/oai-final.pdf Clifford A. Lynch Metadata Harvesting and the Open Archives Initiative. ARL Bimonthly Report, No. 217, August 2001 http://www.arl.org/newsltr/217/mhp.html For more papers see Perspectives on Electronic Publishing on OAi http://aims.ecs.soton.ac.uk/pep.nsf/IndirectLinkAgent?OpenAgent&context=TopicalTerms&keyword=Open%20Archives%20initiative&

5. OAi: key architectural decisions From Lynch (2001) “Participants at Santa Fe made a key architectural decision: they adopted a model that rejected distributed search in favor of simply having servers provide metadata in bulk for harvesting services” “The Santa Fe group wanted a very simple, low-barrier-to-entry interface, and to shift implementation complexity and operational processing load away from the repositories and to the developers of federated search services, repository redistribution services, and the like.”

6. OAi metadata All OAI data providers supply metadata in a common format – the unqualified Dublin Core Metadata Element Set “In the spirit of experimentation”, all elements remain optional Parallel metadata sets: no limitations on the nature of such sets, other than that the metadata records be structured as XML documents, which have a corresponding XML schema for validation

7. OAi Metadata Harvesting Protocol Six requests or verbs carried within HTTP POST or GET methods: GetRecord Required arguments specify the identifier, or key, of the requested record and the format of the metadata that should be included Identify Information about a repository ListIdentifier Retrieve the identifiers of records that can be harvested from a repository. Optional arguments permit selectivity ListMetadataFormats ListRecords ListSets

8. OAi MHP or Z39.50? More from Lynch (2001) “We should not think about the world becoming partitioned between Z39.50-based resources and MHP-speaking resources, but rather about bridges and gateways. “It is quite reasonable to think about a service that is constructed using the Open Archives Metadata Harvesting Protocol offering a Z39.50 interface to its user community. “A Z39.50-speaking server can fairly easily be made MHP-compliant, and I would expect to see the development of gateway or broker services that make Z39.50 servers available for open archives metadata harvesting in cases where the individual server operators do not want to undertake this development work.”

9. The future for OAi Is OAi an initiative or a protocol? Who will use it – eprints services, digital libraries, publishers? Will OAi be standardised? How can you build an OAi archive? e.g. EPrints.org free archive-creation software is OAi-compliant http://www.eprints.org To follow OAi developments see Open Archives Initiative Web site http://www.openarchives.org/ OpCit news http://opcit.eprints.org/opcitnews.shtml

10. The origins of OpenURL There may be many versions of a publication. Confronted with the growth in the published scholarly literature and the serials crisis, libraries subscribe to fewer, non-core journals and use a variety of agents and services to acquire materials, e.g. Just-in-time document delivery Collections from e.g.licensed full-text aggregators With the appearance of links, e.g. reference links from services such as CrossRef, in electronic versions of papers, how can the link creator anticipate which version of a paper a user will have access to? This has become know as the ‘appropriate copy’ problem

11. Syntax of OpenURL http://(who you are, where you are, your institution)/(where you want to go ABC An OpenURL is mediated by the HTTP protocol BASEURL, data about the user, typically inserted during transport between servers. One interim mechanism is to store the BASEURL as a cookie in the user’s browser. The cookie identifies the resolver that provides context-sensitive services for the user. QUERY, points to the referenced object, which might be an identifier, e.g. Digital Object Identifier (DOI) Explicit metadata derived from an authored reference Partial metadata, allowing a secondary service to identify the required document Metadata can be described in Dublin Core format, e.g. an OAi identifier

12. Example OpenURL service architecture OpenURLs might be based on CrossRef–DOI services(from Beit-Arie et al. 2001)

13. How simple is OpenURL? OpenURLs contain three types of entities: the referenced item (OBJECT-DESCRIPTION) the information service in which the item is referenced (ORIGIN-DESCRIPTION) the service component that will deliver the extended services (BASEURL) An extension of this approach, the Bison-Futé model, adds the following entities: the user requesting the services (the requester) the type of service that is requested (serviceType) the information entity that makes the reference to the item (the referring-entity). All entities are contained in the ContextObject and turned into an HTTP request, which is called an OpenResolutionLink.

14. Finding out more about OpenURL Good starting point, an excellent tutorial with practical examples Powell, OpenResolver: a Simple OpenURL Resolver. Ariadne, Issue 28, June 2001 http://www.ariadne.ac.uk/issue28/resolver/ Authoritative, technical specifications Van de Sompel and Beit-Arie, Open Linking in the Scholarly Information Environment Using the OpenURL Framework. D-Lib, Vol. 7 No. 3, March 2001 http://www.dlib.org/dlib/march01/vandesompel/03vandesompel.html Van de Sompel and Beit-Arie, Generalizing the OpenURL Framework beyond References to Scholarly Works: The Bison-Futé Model. D-Lib, Vol. 7 No. 7/8, July/August 2001 http://www.dlib.org/dlib/july01/vandesompel/07vandesompel.html Beit-Arie et al., Linking to the Appropriate Copy: Report of a DOI-Based Prototype. D-Lib, Vol. 7 No. 9, September 2001 http://www.dlib.org/dlib/september01/caplan/09caplan.html A copy of these slides will be found on the Open Citation Project site http://opcit.eprints.org/. Look for Papers and presentations