Just wanted to comment that what you yearn for here, a short URL that
links to the full metadata for an object, is indeed a feature of OpemURL
v. 10. It's called "by-reference", and I believe you'll find it
described in the Part 2 document. It's not a hash, as you describe,
however. In the same vein, I've thought that the "get PURL info" of the
Ark identifier should be expanded to create a convention for retrieving
the metadata related to the resource to an persistent identifier.
(http://www.ietf.org/internet-drafts/draft-kunze-ark-06.txt, section 6)
What I like in particular about the Ark concept is that the same URL can
be used to retrieve the document, or information about the document. In
that sense, it really is acting as an identifier. And It would mean that
you could ask the same questions about any resource (and not always get
answers, of course).
On Tue, 2003-12-09 at 14:30, Morbus Iff wrote:
> One of my largest annoyances with OpenURL, ignoring everything else, is
> the length of its URLs. In my head, having a non-sensical URL like:
> is nicer - it's smaller, more happily portable in email programs, can
> fit on business cards, promotional materials, blah blah blah blah.
> Dissatisfied, for that reason, with OpenURL, but not willing to
> "death knoll" it until I read the spec, I moved on to some
> five minute readings, where I came upon this:
> Thinking about Reference Linking
> I believe someone else mentioned this URL to me as part of my initial
> question about unique identifiers. One paragraph tickles me:
> These links are effected through Digital Object Identifiers (DOIs),
> a unique identifier tagged to article metadata. Unlike URLs, which
> can be inconsistent and point only to a manifestation of an article
> or other piece of electronic content, DOIs are persistent and identify
> the object itself. DOIs link to URLs through a resolver system, such
> as the one run by the International DOI Foundation.
> So, let me wax maddeningly:
> * $system supports OpenURL fully. everything OpenURL
> purports to do can be done, great, super.
> * $system supports the first URL in this email, as a DOI
> to the OpenURL itself. The DOI (note that "DOI" would be a
> misnomer in the $system I'd want, since not all OpenURLs would
> represent purely digital content, but also DVDs, books,
> serials, records, etc.) is generated from the OpenURL
> itself, creating a unique hash for that record.
> So, for example, something like:
> would be hashed down to:
> Only the query string itself would be hashed (NOT
> http://demo.1cate.com/) to allow for differing base URLs,
> and the hashing mechanism would be public (the query
> string is certainly long enough to do an MD5 of it,
> which would create a healthy unique key).
> The problem, of course, is what sort of OpenURL to hash from. Presumably,
> one digital object could be unique enough that it could be referenced with,
> and without, the "aulast" and "aufirst" fields (creating different MD5s).
> Likewise, with two ISBN's referencing one expression, you'll get different
> hashes there too, but both of those problems seem to exist in OpenURL
> itself too (if OpenURLs are portable amongst baseURLs, that is).
> Thoughts? The goal here is to create a smaller, "happier" URL whilst
> also creating a uniquish-key to reference the expression by.
Digital Library Specialist
Ph: 510-540-7596 Fax: 510-848-3913