Re: [handle-dev] Proposed Technology Workshop

[Larry Lannom <llannom@cnri.reston.va.us>]

Three reactions to all of this:

1. As Norman has, I think, already pointed out the proposed Workshop is
a joint IDF/CNRI effort in which probably the first day will be
dedicated to generic DOI issues, irrespective of resolution system, and
the second day is really a handle developer day. They are, conceptually
anyway, fairly distinct, but we know that there will probably be some
overlap in attendance and wanted to make them convenient to each other,
esp for potential overseas attendees (such as Tony).

2. Using the typing mechanisms available via the handle system is an
expected way to build up a complex set of associated data for any given
digital object -- we have been hoping/assuming that that would be
application specific and Tony is laying out such an approach. But we
don't recommend using the index value, which is intended to be an
instance identifier and not a typing mechanism. We introduced the index
value in this version of the handle system because we had no other way
to distinguish two or more handle values of the same type. One option
for subtyping would be to extend the type codes, e.g., A.1, A.2, etc.

3. The type codes will be one of a number of things, including genres,
which will have to be agreed upon by some group, e.g., IDF members, and
then documented and made usable, e.g., in some sort of metadata
registry.

Larry

tony_hammond@harcourt.com wrote:
> 
> 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

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