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.