[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[handle-dev] RE: [Members] Proposed Technology Workshop
We haven't yet determined a final agenda for this workshop; I discussed it
with CNRI yesterday. We have proposed dates (Sept 19 and 20) and currently
envisage this as a joint CNRI/IDF event, at CNRI, with two separate days
(and overlapping but not identical attendance). One day would be entirely
on Handle (hence a CNRI -focussed developers day); the other on DOI
specifics. I don't intend the DOI session to deal with specific metadata
(genres); but I do envisage that it will deal with genre definition
porocesses and management as there is clearly some clarification/development
still neeeded here. There are also some interesting synergies with the
overall digital object architecture in which Handle fits, and the issues of
genre registries etc.
When we have some specific proposals I'll post them to the members list for
further comment.
-----Original Message-----
From: tony_hammond@harcourt.com [mailto:tony_hammond@harcourt.com]
Sent: 07 June 2000 11:49
To: 'members@doi.org'
Cc: handle-dev@cnri.reston.va.us
Subject: [Members] Proposed Technology Workshop
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
------------------------------------------------------
Members maillist - Members@doi.org
http://www.doi.org/mailman/listinfo/members
_______________________________________________
handle-dev mailing list
handle-dev@cnri.reston.va.us
http://www.cnri.reston.va.us/mailman/listinfo/handle-dev