ReadingList

.h2 Issues in Permanent Identifiers.

Here is a workshop on PI?s.

http://www.dcc.ac.uk/training/pi-2005/

Lots of excellent papers.

What are some use cases ? where do we need persistent identifiers?
1) Preservation ? finding the thing we have preserved.
2) Long term referencing ? independent of delivery system. For example, user should be able to reference particular ?May anti-slavery pamphlet? independent of what system delivers it.

Questions:

1) Are we talking about a permanent ?locator? ? something which will always get you to a particular resource?
2) Or, are we talking about an ?identifier?,? ? something which will always identify a specific resource, but may, or may not, get you to the resource.

This distinction is made, and I think importantly, in this document:
http://www.cdlib.org/inside/diglib/ark/

.h2 SYSTEMS

.h3 ARK

To quote: (http://www.cdlib.org/inside/diglib/ark/)
The Archival Resource Key (ARK) identifier is a naming scheme for persistent access to digital objects (including images, texts, data sets, and finding aids), currently being tested and implemented by the California Digital Library (CDL) for collections that it manages.
An identifier is an association between a string (a sequence of characters) and an information resource. That association is made manifest by a record (in the case of this service, a METS record ) that binds th[e identifier string to a set of identifying resource characteristics. The ARK identifier is a specially constructed, globally unique, actionable URL. Each ARK links end-users to three things:

• Digital object metadata
• Digital object content files
• A commitment statement made by the CDL concerning the digital object.

And this:
http://www.sspnet.org/files/public/Kunze.htm

.h3 PURL
http://purl.oclc.org/docs/inet96.html

But PURL are actually persistent locators ? that is after all their name. A PURL does not offer any service except that of resolution to its destination. There is no way to get metadata about the object, and no way to determine an institutions commitment to maintain a PURL. No way to store alternate, or backup URL?s, and no way to provide context specific resolution.

.h3 Handles

http://www.handle.net/introduction.html
The LOC has this writeup on Handles: http://lcweb2.loc.gov/ammem/award/docs/h-s2.html
http://www.handle.net/rfc/rfc3651.html

DOI?s ? I think DOI?s are an implementation of handles, but commercially, so each DOI costs money. Other than that, I don?t see any difference between doi?s and handles.
To quote:
The DOI System is an application of the Handle System to intellectual property. The DOI is managed and developed by the International DOI Foundation, a not-for-profit membership organization. The DOI system adds to the Handle System an approach based on structured associated metadata; policies regarding scope and application; procedures for ensuring consistency and quality control across applications; business models; and specific application tools. Initial implementations are now being supplemented by increasingly sophisticated value-added tools for metadata management and content management, which will use the Handle System multiple resolution function. More information is available in the DOI Handbook.

Handles can store arbitrary data:
http://www.handle.net/hs_manual/server_manual_2.html#SEC3
says:
A handle has a set of values assigned to it and may be thought of as a record that consists of a group of fields. Each handle value must have a data type specified in its <type> field, that defines the syntax and semantics of its data, and a unique <index> value that distinguishes it from the other values of the set. A set of handle data types has been pre-defined for administrative use. (See Handle System Namespace and Service Definition.)
<type> can be any UTF8-string. Handle System users acknowledge, however, that there are potential conflicts for handle clients if users assign types that are not registered and recognized across the user community. How <types> should be defined and how they should be used is currently under discussion. The non-administrative types that have been registered and defined to date are listed below.

• URL: Values of type URL are UTF8-encoded URIs that specify the location of the object identified by a handle.
• EMAIL: Values of type EMAIL are UTF8-encoded email addresses.

PID Pros and Cons: