Page History

permanent

Yes

Yes

permanently resolve to a digital object

Yes

Yes

unique within our PID system without the DNS name portion of the

Yes; very flexible naming, including pseudo/paths

Yes, but

URL

?

Yes

works with VIVO, arXiv, OAIS (CUL), Voyager Catalog, and WorldCat etc.

Yes

does nothing in and of itself to not work with existing systems;

resolvable through a web browser

Yes

Yes

Simplicity

Yes

Yes

support for a local namespace prefix and an identifier part

Yes

Yes

support for opaque identifiers

Yes

Yes

Local part should not be Cornell branded

completely flexible

Yes

may be surrogate for physical object

Yes

Yes

should be short (so use 26 letters plus numbers)

Yes

Yes

should be easy to copy by hand

depends on the length

depends on the length and/or layout

Supports billions of identifiers

Don't know; limited to the practical capacity of the underlying database.

Don't know – mention of 1996 tests resolving 50 resolutions/sec with a database of 500,000 PURLS in Long Introduction to PURLs

Robust architecture

Yes

Yes; PURLz is just a simple HTTP server using MySQL

Robust implementation

Yes

No - alpha stage

ability to request metadata about the identifier

Yes

Yes

lightweight understanding of identifier equivalence

Yes

Cloning an existing PURL and chaining a PURL

should be easily discoverable by Google

Yes;  the resolvers can't be crawled without providing a dump

Yes;  the resolvers can't be crawled without providing a dump

integrate well with the "web architecture"

Yes

Yes

vitality checking

? 

not built in

Need to avoid unbounded generation of surrogate persistent identifiers

?

?

PID corresponding to every Cornell NetID

?

Depends on the Partial Redirect working – e.g., http://resolver.cornell.edu/netid/bdc34

Requires payment to external organization

one-time $50 payment per named resolver (not mirrors)

no

Can continue resolve IDs in absence of external organization

Yes

Yes