Versions Compared

Old Version 13

changes.mady.by.user Brian D. Caruso

Saved on

compared with

New Version Current

changes.mady.by.user user-f44b9

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

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

 

HDL

PURL

PURLz

HNRS

DOI

permanent

Yes  

 

 

 

 

Yes

permanently resolve to a digital object

Yes  

 

 

 

 

Yes

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

 

 

 

 

 

URL

 

 

 

 

 

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

For Resolver and System

 

HDL PURL

PURLz

HNRS

DOI

Supports billions of identifiers

 

 

 

 

 

Robust architecture

 

 

 

 

 

Robust implementation

 

 

 

 

 

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

 

 

 

 

 

useful error when check digit is wrong

 

 

 

 

 

?

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

Governance Issues

 

HDL

PURL

PURLz

HNRS

DOI

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

HDL is Corporation of National Research Initiatives's Handle system.
PURL is OCLC's PURL system.
PURLz is Zepheira's and OCLC's new persistent URL work.
HNRS is the Harvard Name Resolution Service.
DOI is IDF's DOI system

Footnotes

  • Anchor
    unique
    unique
    Uniqueness: We think PURLZ will reject the creation of a duplicate PURL, but we're not entirely sure how it deals with duplication when a PURL name component overlaps a PURL domain component – e.g., if we inadvertently created a domain /a/b/ with resource 1234 and someone later used the name b/1234 in domain /a/. Maybe pure string comparison for non-uniqueness is all that's required, but conventions need to be established to avoid confusion.