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
6. The identifier itself needs to support two parts: a local namespace prefix and a (fairly) arbitrary identifier part
7. Makes sense in context of VIVO, arXiv, OAIS (CUL), Voyager Catalog, and WorldCat
8. 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)
9. Identifiers should be short (so use 26 letters plus numbers)
10. Identifiers should be easy to copy by hand - separate every 4 characters with a dash
11. It must be possible to support opaque identifiers
12. Must be resolvable through a web browser
13. Must be unique within our PID system without the DNS name portion of the URL
14. Recommended that newly created local identifier namespaces use identifiers that include a check "digit" (so that typing errors are not likely to result in a valid identifier).

For Resolver and System

1. Supports billions of identifiers with very fast resolution
2. Robust architecture and implementation - a highly available system
3. 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)
4. Support for OAI-ORE structuring
5. Need to avoid unbounded generation of surrogate persistent identifiers
6. Should support multiple delivery formats for an identifier _ (does this mean doing content negotiation at the resolver?)_
7. Must support splitting collections (what does this mean?)
8. Need a lightweight understanding of identifier equivalence
9. Need a way to integrate outside PIDs with Cornell (what does this mean? examples?)
10. The identifiers and the associated content should be easily discoverable by Google
11. The overall system should integrate well with the "web architecture"
12. Should have a PID corresponding to every Cornell NetID and potentially other non-digital resources, not necessarily at Cornell?
13. Should give useful error when check digit is wrong.

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)