[handle-dev] Proposed Technology Workshop

[tony_hammond@harcourt.com]

Regarding the proposed Handle technology workshop at CNRI I would very much urge
that other aspects of DOI technology, such as DOI metadata, *not* be discussed
at that time. The reason is that genre specific vocabularies can readily be (and
have been) discussed in other fora, whereas what the Handle *as DOI* most
requires is a semantic interpretation of the multiple data values (to be) stored
in the Handle. Also time would be too constrained and there would be the obvious
danger of "missing the point". Genre specific metadata is an out-of-line
description.

As an ongoing illustration of multiple resolution, the IDEAL Objects
Demonstrator makes use of the following values:

Index 0: Handle map.
  [Handle which can be resolved to this "object" Handle's schema.]

Index 1: Self value: Object label.
  [Human readable label as bibliographic citation.]

Index 2: Self value: Object metadata.
  [Obtained by XPointer addressing into out-of-band XML holdings descriptions.]

Index 3: Self value: Object resource..
  [URL.]

Index 4: Link to parent Handle.
  [Provides upward links through Handle "object" hierarchy]

Indexes 5-8: Links to related "objects" (parent, children, immediate siblings).
  [Uses XPointer addressing into out-of-band XML holdings descriptions
   (provides upward, downward and side links). Note that the XPointer
   parent link can be compared with the Handle parent link to ensure correct
   "alignment" of external (or out-of-band) linkage with internal linkage.]

To my mind the critical value in the above disposition is the map or schema
which would enable the Handle to be "read". There would only need to be a select
number of maps as most "objects" would share common semantics.

Interestingly also, this implementation of Handle values is very much oriented
towards being a work identifier. All values (apart from index 3) are purely work
rather than manifestation identifier values - they could just as well describe
the print as well as the electronic manifestation. This is in contrast to the
current DOI implementation which only supports one manifestation value (standing
in as work identifier).

Another data value that would be of extreme utility is a Handle to a local
namespace. This in fact could be one means of kickstaring mutiple resolution.
There will (almost certainly) be a growing requirement to associate private or
custom data values (hence schemas) with an object identified via a DOI. Handing
off to a local namespace provides a simple mechanism for extensibility. Of
course, IDF could not be expected in any way to be seen to "endorse" private
data types which would fall outside of any formal DOI schema, but a "handing
off" to another namespace may be a sufficient means to "draw the line". In
practical terms this could be made publicly invisible by setting admin read only
on that value. In practical terms it could also be implemented now (or at any
rate not in the distant future). The only other way forward for the time being
is to "shadow" DOIs on a local service.

Tony









_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev