Dear Patricia,
I do not understand your point that the standards that were brought forward in this discussion group would make a distinction between "identification" and "localisation" as you call them. Even the most basic frameworks (like DNS,PURL,URI,URN) already make use of the principle redirection, which is the underlying technology to implement the resolution of the identifiers. More advanced digital identification frameworks (like DOI,LSID,ARK) offer designs of more extensive redirection schemes that granular resolution of objects, multiple resolution, persistence, context-dependent resolution, intellectual property, federated resolution. All of these merely can be considered as extensions on the basic principle of separation between the (preferably dumb) identifiers and its resolution (= localisation).
Kind regards,
Peter
----------------------------------------------------------- Dr. Peter Dawyndt Laboratorium voor Microbiologie Universiteit Gent Ledeganckstraat 35 B9000 Gent, Belgie
Tel.: (32)9.264.51.32 Fax.: (32)9.264.50.92 Email: Peter.Dawyndt@UGent.be -----------------------------------------------------------
On Tue, 11 Oct 2005, Patricia Mergen wrote:
Dear Donald and colleagues from the GUID group
Please find some comments here below
There are two concepts which may be kept separated: Identify an item (object or representations of the object) which should be unique and stable which can be understood as a GUID. Localisation of an object or its representation which may and often is not stable.
Many of the tools and systems suggested so far often mix up these two concepts and intend to identify and localise at the same time. Problems than occur often because localisation is not stable and apparently not workable as a GUID.
Maybe for solving the problem, we could try for GBIF/TDWG to keep these two concepts separated and look for a system which is most appropriate to identify uniquely and in a stable way the unit level data. This can be an Accession number with no meaning like those used for Sequence data. Localisation of the object can be dealt with as being information about the object that can change in time like any other.
Best regards
Patricia Mergen --- Donald Hobern dhobern@GBIF.ORG wrote:
[ I will be trying to provide some structure to discussions in this mailing list by raising specific topics and looking for comments. Please keep the Topic number in responses ]
Topic 1: What do we mean by GUID?
The most fundamental thing that we need to establish as we consider a GUID implementation is a definition for "GUID" in this context. We have been using a number of terms to describe the identifiers we need (unique, resolvable, persistent, etc.).
I've been spending some time following up on Rod Page's recommendation that we consider the use of Archival Resource Keys (ARK) from the California Digital Library (see http://wiki.gbif.org/guidwiki/wikka.php?wakka=ARK). The CDL web site includes an excellent overview of this GUID model, which also serves as an excellent introduction to the issues involved. I would urge you all to read this document - it's only nine pages long!):
http://www.cdlib.org/inside/diglib/ark/arkcdl.pdf
This document arrives at the following problem definition for persistent, actionable identifiers:
The goal: long-term actionable identifiers.a. Requirement: that identifiers deliver you to objects (where feasible). b. Requirement: that identifiers deliver you to object metadata. c. Desirable: each object should wear its own identifier. d. Requirement: that identifiers deliver you to statements of commitment.
The problem: URLs break for some objects(that is, associations between URLs and objects are not maintained), and we have no way to tell which ones will or won't break. 3. Why URLs break: because objects are moved, removed, and replaced - completely normal activities - and the provider in each case demonstrates insufficient commitment to update indirection tables, or to plan identifier assignment carefully. Persistence is in the mission of few organizations. 4. Conventional hypothesis: use indirect names (PURLs, URNs, Handles) instead of URLs; what worked for DNS should work for digital object references. Wrong. Indirection is spectacularly successful and elegant in DNS, but it's a side issue in the provision of digital object persistence.
This document clearly identifies issues around provider service commitments as the key problem that needs solving. The construction of ARKs seeks to address this in a couple of ways. It separates the role of Name Assigning Authority (i.e. who initially assigns the identifier) from that of the Name Mapping Authority (i.e. who is able to map the identifier to the data object at any particular time). It also defines a simple standard relationship between three things: the data object, the metadata for the object, and a commitment statement from the provider as to what aspects of persistence are guaranteed.
ARK is a technology that we have not really considered up to this point. My question for discussion is what, if anything, is missing or wrong about the problem definition provided in this document? If we agree that it provides a crisp definition of what we need, that in itself will be a major step forward.
Please provide your thoughts.
Donald
Donald Hobern (dhobern@gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480
Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs