[tdwg-content] RFC 4122 as motivation, was Re: Why UUIDs alone are not adequate as GUIDs

[Bob Morris]

For better or worse, the TDWG Applicability Statement for GUID's, and
most of the TDWG community, uses "GUID" in a generic sense, not
conformant to RFC 4122 which declares "GUID" and "UUID" to be
equivalent terms.

Also, according to http://www.rfc-editor.org, ---which by STD 1 always
contains the current status of any RFC---it seems that RFC 4122 has
never advanced past "Proposed Standard" in the 6 years since it was
proposed.  So, however one reads RFC 4122 on the question of "*ONE*
GUID" (meaning in the 4122 context "*ONE* UUID"), at best "*ONE* GUID"
is a proposal, not a standard in the sense of IETF. Not even a Draft
Standard.

Finally, FWIW, the author of
http://en.wikipedia.org/wiki/Universally_unique_identifier seems to
not take "Unique" to mean at most one per resource:

"The intent of UUIDs is to enable distributed systems to uniquely
identify information without significant central coordination. Thus,
anyone can create a UUID and use it to identify something with
reasonable confidence that the identifier will never be
unintentionally used by anyone for anything else. Information labeled
with UUIDs can therefore be later combined into a single database
without needing to resolve name conflicts."

I find nothing in the above, nor in RFC 4122 that prohibits multiple
UUIDs for the same resource, counterproductive as that might be. The
TDWG GUID Applicability standard, however, needs some cleaning on
related points, since it has some internally confusing narrative on
this issue. On balance, it comes  out implicitly in favor of a single
UUID (or any other kind of "GUID") for each resource, issued only by
the resource provider; but explicitly permits multiple schemes for
identifying a resource.

Bob Morris

On Wed, Jun 8, 2011 at 10:56 PM, Paul Murray <pmurray at anbg.gov.au> wrote:
>
> On 08/06/2011, at 8:05 AM, Steve Baskauf wrote:
>
> ... I think it's foolish to regard all of these different
> resolution mechanisms as distinct "identifiers".  There is *ONE* GUID.  It
> is: A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523.  There are ten different ways to
> make it actionable. It therefore meets the recommendations of the
> applicability statement.
>
> The problem is that when you create an HTTP URI out of a UUID, you are
> creating an identifier whether you think you are or not.
>
> Jumping in again, but perhaps RFC 4122 might help a little here.
> A GUID (or UUID) is a set of 128 bits, 16 octets, 32 hex digits, 5 inches of
> punched paper tape. However you choose to write or express it, there is
> indeed "*ONE* GUID".
> A URI is not a GUID. This:
> http://example.org/A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523
> is a different URI to this
> http://my.organisation.org/A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523
> is a different URI to this:
> http://example.org/A9F435E08ED746DDBAB4EA8E5BF41523
> Furthermore, these uris have nothing whatever to do with the guid - apart
> from the fact that it's obvious to we humans that they do.
> Fortunately, there is a standard for expressing a guid/uuid as a URI, and it
> is the "uuid" urn namespace, defined in RFC-4122. Thus:
> urn:uuid:A9F435E0-8ED7-46DD-BAB4-EA8E5BF41523
> is a URI that - according to a w3c standard - corresponds to the 128-bit
> guid. This:
> urn:uuid:A9F435E08ED746DDBAB4EA8E5BF41523
> is *not valid* - it doesn't conform to the schema. There is one unique (case
> insensitive) uuid urn for any guid, and a defined equivalence between them.
> These are not "cool uris", but guids are inherently uncool so that's to be
> expected.
> If you want to use GUIDs for identifiers and need equivalent URIs (for use
> in RDF and the semweb), then urn:uuid:<the guid> might be a good way to go.
>
> If you have received this transmission in error please notify us immediately
> by return e-mail and delete all copies. If this e-mail or any attachments
> have been sent to you in error, that error does not constitute waiver of any
> confidentiality, privilege or copyright in respect of information in the
> e-mail or attachments. Please consider the environment before printing this
> email.
>
> _______________________________________________
> tdwg-content mailing list
> tdwg-content at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>
>



-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390
IT Staff
Filtered Push Project
Department of Organismal and Evolutionary Biology
Harvard University


email: morris.bob at gmail.com
web: http://efg.cs.umb.edu/
web: http://etaxonomy.org/mw/FilteredPush
http://www.cs.umb.edu/~ram
phone (+1) 857 222 7992 (mobile)