*** This version of Confluence is for testing only and contains a copy of content from June 29th 2026. No changes will be preserved. ***
This document is intended to contain examples possible of persistent identifier strings and their pros and cons.
Issues
Behaviors supported by the resolver
A straw man proposal
Start with a 3-part uri structure:
| domain name | prefix | identifier |
|---|---|---|---|
simplest form | http://resolver.cornell.edu | 173 | 1234.5678 |
variation 1 | http://resolver.cornell.edu | 173 | 1234.5678/v1 |
variation 2 | http://resolver.cornell.edu | 173 | 1234.5678/v1/pdf |
variation 3 | http://resolver.cornell.edu | 173 | 1234.5678/ps |
The resolver has one lookup table with an entry for each known prefix. That lookup table specifies one of 2 behaviors for that prefix, which in our case we anticipate to correspond to a collection (but it could be used for distinct services redirecting to the same collection – the resolver wouldn't care).
Strict behavior
The resolver would have a 2nd lookup table specific to that prefix (never mind for now how this would be efficiently implemented). If an entry matching the entire identifier part as an indivisible string is found, the resolver redirects to that entry. Otherwise the resolver returns an error. Any of the 4 distinct URI forms above would fail unless the resolver had been provided a unique redirection location for that URI.
Pass through behavior
The resolver would never return an error, but instead pass the entire identifier string along to a single redirection address (e.g., http://arxiv.org
). This allows the collection to treat the different forms of the URI however it needs to.
It would be possible for a collection to use more than one prefix to allow different behaviors for different circumstances. There could also be additional behaviors, as for example a behavior involving authentication and/or authorization before redirecting.
Components of the URI (and their ordering)
An example showing different paths for different representations of a resource as an alternative to content negotiation
...
| Panel |
|---|
http://purl.org/commons/record/ncbi_gene/24866 |
Discussion at the 11/7/08 meeting did not favor this pattern of inserting a format or service designation in the middle of the URI (note that this would require a different behavior in the resolver than the 2 described above). Simeon also pointed out that many browsers do not behave correctly based on a MIME type specification alone, and that file extensions are usually needed (e.g., 1234.5678.pdf).
Layering to achieve branding without having branded identifiers
...