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@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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content