Re: URN UUID question

[Joel Kalvesmaki <[e-mail]>]

Thanks for the suggestion. I had considered that option, but the string
must conform to XML schema's <anyURI>,[1] to suit the purposes I mentioned
(RDF, etc.). And no <anyURI> may begin with a numeral. It would also be
important to have a scheme that any human or computer would recognize
immediately as a URN.

I had also considered the following (where NN = a suitable project-specific
abbreviation or dt = date-time, as a project-agnostic urn scheme):

urn:uuid-NN:f60330fd-1900-44ac-a825-de70074e142e::2014-02-07Z
urn:uuid-dt:f60330fd-1900-44ac-a825-de70074e142e::2014-02-07Z

But would either one require registration with IANA? If so, what what's the
process and is it worthwhile? I have heard of at least one project that has
simply coined its own urn:NNN: scheme on its own, but I do not fully
understand what consequences face anyone setting out on that direction.

One other possibility occurs to me, that of treating the time-date stamp as
a fragment identifier:
urn:uuid:f60330fd-1900-44ac-a825-de70074e142e#2014-02-07Z

But I suspect that would violate the RFC 4122 definition, no?

Best wishes,

jk

[1] http://www.w3.org/TR/xmlschema-2/#anyURI


On Tue, Mar 11, 2014 at 1:24 PM, Peter Saint-Andre <[e-mail]>wrote:

> On 3/4/14, 8:32 AM, Joel Kalvesmaki wrote:
>
>> I am developing an XML data model that requires users to name versions
>> of a document. Each version's name should be unique, but patterned to
>> allow anyone (human or computer) to associate it with the names of other
>> versions of that document and to place it in chronological sequence. The
>> name of each version must be a single string, specifically a IRI/URI (to
>> facilitate, among other things, straightforward declarations in RDF). It
>> should not be split into two elements. Naming must be as decentralized
>> as possible.
>>
>> My favored scheme for naming these entities would concatenate a UUID
>> (any style), a middle delimiter, and an ISO date/dateTime, e.g.,
>>
>> urn:uuid:f60330fd-1900-44ac-a825-de70074e142e::2014-02-07Z
>> urn:uuid:f60330fd-1900-44ac-a825-de70074e142e::2014-02-28T00:20:58.3Z
>>
>> Would it be misleading to begin such a string with "urn:uuid:" and if
>> so, what are the alternative best practices?
>>
>> Perhaps there already exists a urn scheme that does what I intend?
>>
>> Are there any other issues I should consider before adopting a naming
>> scheme like this?
>>
>
> As far as I can see, you don't really need or necessarily want the
> "urn:uuid:" string at the front. Why not things like this?
>
> f60330fd-1900-44ac-a825-de70074e142e::2014-02-07Z
> f60330fd-1900-44ac-a825-de70074e142e::2014-02-28T00:20:58.3Z
>
> Peter
>
>
>


-- 
Joel Kalvesmaki
kalvesmaki.com