Topic 1: What do we mean by "GUID"?
Roderic Page
r.page at BIO.GLA.AC.UK
Wed Oct 12 12:14:39 CEST 2005
I think this is a very nice statement of the issues.
My own view is that ARK is interesting, but I'm not sure ARK is the
best way forward. Persistence is a (perhaps the) key issue, and it is a
social one not a technological one, as the DOI people make very clear.
DOIs only work because the publishing industry has invested in the
infrastructure to support them.
In some ways, DOIs and ARK are very similar. If I use the DOI resolver
to resolve a DOI
http://dx.doi.org/10.1086/303303
\--------/ \-----/ \----/
| | |
| Name Name
Name mapping Assigning
Authority Authority Number (NAAN)
Hostport (NMAH)
then I have a URL very like an ARK, where the authority assigning the
name (such as a publisher, in this case the University of Chicago) is
different from the authority makes the identifier actionable (doi.org).
One could imagine that if DOI.org were to fall over, one could
substitute another authority, such as doi.reborn.org. Indeed some
publishers almost do essentially this, for example
http://www.journals.uchicago.edu/cgi-bin/resolve?id=doi:10.1086/303303
(although this will only resolve local DOIs). ARK simply makes this
possibility explicit. LSIDs are more strongly tied to the DNS (the
uniqueness of an LSID is partly guaranteed by using Internet domain
names), although they do have limited support for foreign authorities
(other providers that can serve metadata for objects that those
providers don't actually own).
ARK also adds the ability to retrieve a statement of commitment. I'm
less impressed by this, as a statement is all very well, but will
service providers actually honour it? I guess this is an issue of
trust. I suspect that user's rating of service providers will be much
more accurate than a rating provided by a service provider.
One issue not on this list is who generates GUIDs? ARKs and DOIs
require some degree of centralisation because both require unique
identifiers for organisations providing data (e.g., 10.10086 identifies
the University of Chicago Press). This in itself requires some degree
of service commitment. LSIDs are decentralised, in that the unique
identifier for an organisation is provided by the DNS. If, for example,
GBIF took on the role of providing unique identifiers for
organisations, but then closed due to funding issues (heaven forbid),
then we have a problem. If the DNS goes belly up, then we will have
much more pressing issues to worry about...
Regards
Rod
On 11 Oct 2005, at 15:37, Donald Hobern 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:
>
> 1 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.
> 2 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 at 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
> ---------------------------------------------------------------
>
>
Professor Roderic D. M. Page
Editor, Systematic Biology
DEEB, IBLS
Graham Kerr Building
University of Glasgow
Glasgow G12 8QP
United Kingdom
Phone: +44 141 330 4778
Fax: +44 141 330 2792
email: r.page at bio.gla.ac.uk
web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html
Subscribe to Systematic Biology through the Society of Systematic
Biologists Website: http://systematicbiology.org
Search for taxon names at http://darwin.zoology.gla.ac.uk/~rpage/portal/
--Apple-Mail-51-484624406
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
charset=WINDOWS-1252
I think this is a very nice statement of the issues.
My own view is that ARK is interesting, but I'm not sure ARK is the
best way forward. Persistence is a (perhaps the) key issue, and it is
a social one not a technological one, as the DOI people make very
clear. DOIs only work because the publishing industry has invested in
the infrastructure to support them.
In some ways, DOIs and ARK are very similar. If I use the DOI resolver
to resolve a DOI
<fontfamily><param>Courier</param>http://dx.doi.org/10.1086/303303
\--------/ \-----/ \----/
| | |
| Name Name
Name mapping Assigning
Authority Authority Number (NAAN)
Hostport (NMAH)
</fontfamily>
then I have a URL very like an ARK, where the authority assigning the
name (such as a publisher, in this case the University of Chicago) is
different from the authority makes the identifier actionable
(doi.org). One could imagine that if DOI.org were to fall over, one
could substitute another authority, such as doi.reborn.org. Indeed
some publishers almost do essentially this, for example
http://www.journals.uchicago.edu/cgi-bin/resolve?id=doi:10.1086/303303
(although this will only resolve local DOIs). ARK simply makes this
possibility explicit. LSIDs are more strongly tied to the DNS (the
uniqueness of an LSID is partly guaranteed by using Internet domain
names), although they do have limited support for foreign authorities
(other providers that can serve metadata for objects that those
providers don't actually own).
ARK also adds the ability to retrieve a statement of commitment. I'm
less impressed by this, as a statement is all very well, but will
service providers actually honour it? I guess this is an issue of
trust. I suspect that user's rating of service providers will be much
more accurate than a rating provided by a service provider.
One issue not on this list is who generates GUIDs? ARKs and DOIs
require some degree of centralisation because both require unique
identifiers for organisations providing data (e.g., 10.10086
identifies the University of Chicago Press). This in itself requires
some degree of service commitment. LSIDs are decentralised, in that
the unique identifier for an organisation is provided by the DNS. If,
for example, GBIF took on the role of providing unique identifiers for
organisations, but then closed due to funding issues (heaven forbid),
then we have a problem. If the DNS goes belly up, then we will have
much more pressing issues to worry about...
Regards
Rod
On 11 Oct 2005, at 15:37, Donald Hobern wrote:
<excerpt>
[ 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:
1 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.
2 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 at 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
---------------------------------------------------------------
</excerpt>Professor Roderic D. M. Page
Editor, Systematic Biology
DEEB, IBLS
Graham Kerr Building
University of Glasgow
Glasgow G12 8QP
United Kingdom
Phone: +44 141 330 4778
Fax: +44 141 330 2792
email: r.page at bio.gla.ac.uk
web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html
reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html
Subscribe to Systematic Biology through the Society of Systematic
Biologists Website: http://systematicbiology.org
Search for taxon names at
http://darwin.zoology.gla.ac.uk/~rpage/portal/
More information about the tdwg-tag
mailing list