Goals for Persistent Identifiers

Goals

Note: Questionable goals are in red

For Identifiers (just the complete URI and local part, not about mechanisms)

1. Identifiers must be permanent
2. Identifiers must permanently resolve to a digital object
3. Simplicity (of description and implementation)
4. Support for vitality checking
5. Needs to support multiple repositories and naming schemes
6. Makes sense in context of VIVO, arXiv, OAIS (CUL), Voyager Catalog, and WorldCat
7. Local part should not be Cornell branded so that it is compatible with multi-institution collections where Cornell branding is inappropriate. Generally, these identifiers should be branded to Cornell through the use of a Cornell-based DNS name for the full URI/resolver. It should also be possible to use the local part with non-Cornell resolver for consortia and other non-Cornell-branded needs (cf. DOI, handle; not our purl)
8. Identifiers should be short (so use 26 letters plus numbers)
9. Identifiers should be easy to copy by hand - separate every 4 characters with a dash
10. It must be possible to support opaque identifiers
11. Must be resolvable through a web browser
12. Must be unique without the DNS name portion of the URL (only possible when space defined)
13. Should include a check digit

For Resolver and System

1. Supports billions of identifiers with very fast resolution
2. Robust architecture and implementation - a highly available system
3. Compatible with the Handle System and supports Handle System metadata - Should we support authorization, storage of checksum, multiple resolution, storage of arbitrary XML documents (ala cugir buckets) – these facilities not used by CUL handles at present
4. Support for "private" identifiers (e.g. for dark archive or internal digital objects) (this is about metadata stored with id and facilities provided depending on it)
5. Support for OAI-ORE structuring
6. Need to avoid unbounded generation of surrogate persistent identifiers
7. Should support multiple delivery formats for an identifier _ (does this mean doing content negotiation at the resolver?)_
8. Must support splitting collections (what does this mean?)
9. Need a lightweight understanding of identifier equivalence
10. Need a way to integrate outside PIDs with Cornell (what does this mean? examples?)
11. The identifiers and the associated content should be easily discoverable by Google
12. The overall system should integrate well with the "web architecture"
13. Should have a PID corresponding to every Cornell NetID and potentially other non-digital resources, not necessarily at Cornell?

Out of scope / Not goals

1. Any extra characters for error correction (as an extension of any possible error detection)
2. Attempt to create a fixed-length of fixed-syntax form (that would aid recognition but cost in flexibility/length)