[OAI-implementers] DOI and OAI experiences anyone?
Hammond, Tony (ELSLON)
Thu, 7 Aug 2003 11:22:26 +0100
The following passages from the latest 'doi:' Internet-Draft
may be of assistance here. Note that the 'resource' identified by a 'doi'
URI is not just a given representation (i.e. an HTML or PDF document) but is
a 'set of service descriptions' - see below. This follows the definition of
'resource' in RFC 2396 as being a 'resource is the conceptual mapping to an
entity or set of entities'.
"DOIs are identifiers for entities of significance to the content
industries. The "doi" URI scheme allows a resource associated with an entity
identified by a DOI to be referenced by a URI for Internet applications. A
"doi" URI is dereferenced to a set of service descriptions through
discoverable resolution mechanisms."
"A "doi" URI references a set of service descriptions which is
returned on dereference of the URI. Following such a dereference a service
description is typically selected and the corresponding service activated.
This process of service indirection is commonly referred to as "resolution"
a DOI. Examples of services that can be accessed by the resolution of a DOI
include redirection to another network resource, return of a metadata record
describing the entity identified by the DOI, etc. A discussion of such
services is beyond the scope of this document."
From: herbert van de sompel [mailto:email@example.com]
Sent: 07 August 2003 02:16
To: Alan Kent
Cc: OAI Implementors
The issue you describe (or part thereof) is generally known as "the
copy problem", and I happen to have been involved in proposing a solution to
which is now commonly known as the OpenURL Framework (for Context-Sensitive
Services). I have also been involved in the creation of a specific instance
solution to resolve DOIs at the 'local' level. That DOI local resolution
is operational, and is described in:
* Van de Sompel, Herbert and Beit-Arie, Oren. Open Linking in the Scholarly
Information Environment Using the OpenURL Framework. 2001. D-Lib Magazine.
* Beit-Arie, Oren, Miriam Blake, Priscilla Caplan, Dale Flecker, Tim
Laurence W. Lannom, William H.Mischo, Edward Pentz, Sally Rogers, Herbert
Sompel. Linking to the Appropriate Copy: Report of a DOI-Based Prototype.
D-Lib Magazine. <http://www.dlib.org/dlib/september01/caplan/09caplan.html>
Regarding using the doi of the resource as the oai-identifier:
The thing to understand here, is that an oai-identifier is the identifier of
oai "item" (as defined in the protocol document). It is not the identifier
"resource" about which the oai "item" holds metadata. The identifier of the
"resource" would typically go into dc.identifier; that is if there is a DC
;-) . Having said that, there are OAI repositories that do use the
the "resource" as the oai-identifier, i.e. the identifier of the "item". If
not mistaken, arXiv.org does so. I think one would have to ask the DOI
this list (Tony Hammond are you there?) how kosher it would be to do that
DOIs. My initial impression is that it might very well be acceptable,
CrossRef metadata-lookup system also uses DOIs to get after metadata, not
resource. Although in that case, the look-up is considered to be a specific
service for the specified DOI (if I am not mistaken - I am sure Tony Hammond
Alan Kent wrote:
> I have been reading up recently on DOI a bit more closely, and looking
> and the 'Handle System' (www.handle.net). I was wondering what experiences
> there were out there. Maybe this is what D-space and similar projects
> address. The specific situation I am trying to come up with a "good"
> solution for is below. But I am interested in generic solutions and
> the "best" way to solve these sorts of problems as I think its relevant
> in all sorts of situations. Sorry, the following wanders around a bit
> before it gets back to OAI.
> I actually started looking at SCORM. The idea of SCORM is you develop
> small reusable units of learning material (lets call them a 'lesson')
> and then assemble larger 'courses' etc from those units. SCORM talks
> about 'content repositories' but does not really seem to have addressed
> the issues properly (yet). I was looking at it from a utopian point of
> view (not worrying about implementation practicalities).
> SCORM uses XML encoded metadata (based on IMS) to describe each reusable
> unit. Good stuff for searching. It even recommends a way to bundle up
> a set of files into a single ZIP file to down load. So you end up with
> single files that have XML encoded metadata describing the content of
> the file.
> Each unit however needs to make references to other units. For example,
> courses need to reference lessons. You can use a HTTP URL to point to
> it on some site, but this is pretty location specific.
> For example, consider a University A that authors SCORM material with
> copyright restrictions that it sells rights to for other organisations.
> Or they may only publish the metadata on their web site (or via OAI).
> University B buys a subset of the material (eg: two courses where some
> of the lessons in that course are shared between different courses).
> To avoid network bills etc, University B wants to locate all the content
> locally - they dont want to access the material directly from University
> web site.
> So it makes sense to me to use a location independent identification
> scheme such as DOI to do references. (I guess PURLs are an option too.)
> This is where it gets a bit more interesting. Within University B, it
> wants to resolve the DOI to a local copy of the file. It does not want
> anyone external to the University however to use that resolution. So
> I guess it wants a 'DOI Proxy Server' which allows additional location
> information to be associated with DOIs that it has access to (??).
> Or if using PURL, you want something like a HTTP proxy server that
> can intercept the reference to the external resource and redirect it
> to a local copy of that resource.
> So how does OAI fit in?
> Well, it makes sense to me to publish the metadata records via OAI.
> Then authors can publish metdata information about lessons or courses
> they develop for consumers to find (and purchase etc). I was then
> thinking what OAI identifier to use for the metadata records. I am
> guessing it would make sense to use the DOI as the OAI identifier.
> This lead me to wonder (and this is treading on thin ice!) whether
> an OAI repository implementation could actually be the local cache
> instead of using a special DOI or HTTP proxy server. If someone asks
> for a specific identifier and its not in the local repository, go out
> and try to find it and then cache the value locally. This feels a bit
> unclean however - its not using OAI for its intended purpose. It also
> does not address the issue of the real content (instead of just the
> Then it gets even more interesting when you don't want to rely on
> having external network access. (SCORM was originally funded I believe
> by DoD and I could imagine having closed environments there.) This
> makes HTTP URLs to me a risky sort of way to go. So a DOI handle
> server that can run standalone or connected to the Internet, that can
> add local information to information returned by public hosts?
> Is this the whole idea of digital libraries in the first place?
> Any pointers to relevant projects or papers would be greatly appreciated.
> I don't want to reinvent the wheel.
> Alan Kent (mailto:Alan.Kent@teratext.com.au,
> Project: TeraText Technical Director (http://teratext.com.au) InQuirion
> Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
> Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC
> Phone: +61 3 9925 4114 Reception: +61 3 9925 4099 Fax: +61 3 9925 4098
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
Herbert Van de Sompel
digital library research & prototyping
Los Alamos National Laboratory - Research Library
+ 1 (505) 667 1267 / http://lib-www.lanl.gov/~herbertv/
"your argument is absolutely logical. but people will be confused"
anonymous participant in OpenURL Standardization Committee
OAI-implementers mailing list
List information, archives, preferences and to unsubscribe: