[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[handle-dev] RE: [Members] Proposed Technology Workshop
It's great to see the recent activity on the members@doi.org mailing list.
I suspect someone has done this simply so I can't complain about it not
being used again at the members meeting ;-). However clearly we need to
segragate in some way the specific technical issues from general issues
about Foundation governance (voting procedures etc). I still intend to set
up separate lists for metadata/identifers technical issues and information
interchange issues (with indecs). The handle-dev list seems to be a useful
forum for DOI folk to participate in if they want to follow the resoultion
narea in detail.
In the meantime: Re the second part of Tony's message: I'll leave the Handle
dev group to comment on whether using index values in this way is
appropriate, or whether another means of accomplishing the same result might
be preferable. I understood that index values are intended as a means of
specifying individual resolution tuples for admin purposes, so if one uses
them for other purposes, is this perhaps removing a useful administrative
tool?
I did want to comment on two points:
1. I am sure this is a metter of semantics but nevertheless it's important.
When Tony says the "current DOI implementation.. only supports one
manifestation value (standing in as work identifier)" I take it he means
what I refer to as the initial implementation : single point resolution; and
specifically the Crossref implementation (which uses a genre identifying
works). The full DOI implementation supports of course multiple resolution.
But let us not lose sight of the fact that a DOI identifies ONE thing but
can resolve to MANY services about that thing (including related entities
etc). That thing the DOi identifies can be a Work, or a manifestation, (or
other entity); but it can't be both at the same time- hence the need for
metadata.
2. Local namespaces issues is the local or appropriate copy problem, already
on our list for investigation.
-----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