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 Harvesting Protocol (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 Libraries Roanoke, 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/IndirectLinkAg
  ent?OpenAgentcontextTopicalTermskeywordOpen20
  Archives20initiative

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.shtm
  l

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
• A
  B
  
  C
• 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 users 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 CrossRefDOI 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/03van
  desompel.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/07vand
  esompel.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/09capl
  an.html
• A copy of these slides will be found on the Open
  Citation Project site http//opcit.eprints.org/.
  Look for Papers and presentations