Page History

...

Since the PIDs are URLs they could be used as the href attribute in an <a> element in HTML. When requested via HTTP GET the response should be a digital object or digital surrogate. Wrinkle in this goal is that many web browsers do not respect the MIME type of responses. A digital object such as a PDF might need to have the part after the final slash end if .pdf to be interpreted as a PDF file by a browser. Some browsers will attempt to open a result as a PDF file on a GET of a URL like http://resolver.org/234/b233.pdf^{Image Removed} that has a reply status of 400.

...

The hope is that the URL can be of the form http://hostname.com/localNamespacePrefix/identifierPart^{Image Removed} or something similar. The localNamespacePrefix could also be called a collectionPrefix. The resolver system should place no additional restrictions on the identifierPart beyond conforming URL syntax.

...

In an attempt to avoid problems in situations where the labels associated with resources change, the PIDs should support partially opaque identifiers such as http://hostname.com/170/2a33-ffff^{Image Removed} instead of http://hostname.com/SuperMegaCollection/WalterCarlos1^{Image Removed}. Since the resolver system places no additional restrictions on the identifier part, we cannot stop systems from requesting new identifiers with a syntax that they attach meaning to.

Ex. A collection administrator might register the following Identifiers: http://resolver.cornell.edu/170/article23332^{Image Removed} -> http://collectionX.cornell.edu/article/23332^{Image Removed}http://resolver.cornell.edu/170/article23332.pdf^{Image Removed} -> http://collectionX.cornell.edu/article/23332?format=pdf^{Image Removed}http://resolver.cornell.edu/170/article23332.tex^{Image Removed} -> http://collectionX.cornell.edu/article/23332?format=tex^{Image Removed}
The resolver system will not attempt to parse these identifiers and will not record or track relationships between identifiers.

...