Subject: URN UUID question

From: Joel Kalvesmaki <[email-masked]>
Date: Tue, 4 Mar 2014 10:32:03 -0500

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?

Best wishes,

jk
-- 
Joel Kalvesmaki
kalvesmaki.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Mar 2014 11:24:01 -0600

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
> 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.,
>
> Would it be misleading to begin such a string with "urn:uuid:" and if
> so, what are the alternative best practices?
>

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

---

From: Joel Kalvesmaki <[email-masked]>
Date: Tue, 11 Mar 2014 15:31:11 -0400

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

-- 
Joel Kalvesmaki
kalvesmaki.com

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Mar 2014 14:01:22 -0600

It sounds to me as if you might want to use the 'tag' URI scheme:

https://tools.ietf.org/html/rfc4151

Peter

On 3/11/14, 1:31 PM, Joel Kalvesmaki wrote:
> 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
>
> On Tue, Mar 11, 2014 at 1:24 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         urn:uuid:f60330fd-1900-44ac-__a825-de70074e142e::2014-02-07Z
>         urn:uuid:f60330fd-1900-44ac-__a825-de70074e142e::2014-02-__28T00:20:58.3Z
>
>     f60330fd-1900-44ac-a825-__de70074e142e::2014-02-07Z
>     f60330fd-1900-44ac-a825-__de70074e142e::2014-02-28T00:__20:58.3Z
>
>     Peter
>

---

From: Joel Kalvesmaki <[email-masked]>
Date: Tue, 11 Mar 2014 18:57:38 -0400

Thank you, Peter--I had never heard of this URN format before. It deserves
to be better known. I love the elegance of the tag URI. It just might suit
my needs even better than UUIDs.

Best wishes,

jk

-- 
Joel Kalvesmaki
kalvesmaki.com

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 19 Mar 2014 17:39:38 -0400

> From: Joel Kalvesmaki <[email-masked]>

> Are there any other issues I should consider before adopting a naming

There are many issues to be considered.  As you state it, the problem
is very unconstrained.  At the very least, why you want it to be a URN
is not explained.

> [1:text/plain Hide]

Given that the resulting string would not be a legitimate URN, the
format is somewhat deceiving.  I suggest that the delimiter between
the parts be a character that is not valid in URIs, thus clearly
separating the URN from the version.

Another alternative is to assign documents object IDs, and using the
last number in the object ID to indicate the sequence.  Thus,

urn:oid:1.3.6.1.4.1.14490.4.23178

designates a document (through its history), wile the various versions
of it are:

urn:oid:1.3.6.1.4.1.14490.4.23178.1
urn:oid:1.3.6.1.4.1.14490.4.23178.2
urn:oid:1.3.6.1.4.1.14490.4.23178.3
urn:oid:1.3.6.1.4.1.14490.4.23178.4
urn:oid:1.3.6.1.4.1.14490.4.23178.5

Dale

---

From: Joel Kalvesmaki <[email-masked]>
Date: Wed, 19 Mar 2014 20:15:02 -0400

Dear Dale,

Thanks for your response. Your "why" could be interpreted in multiple ways,
so forgive me if I've picked the wrong one.

I need unique, persistent names. The name needs to be a single IRI/URI to
allow any version of any document to be named easily in any RDF
declarations any third party might want to make.

As I understand it, all IRI/URIs are either URLs or URNs. My naming scheme
cannot rely upon URLs (I know I'm at odds with the recommendations of
Semantic Web advocates) because the names of these documents, which may be
used or referred to centuries from now, need to outlive any domain owners.
Plus I anticipate some users of this XML data model who will not be domain
name registrants (or have access to a domain name, or be interested in that
extra step). So that leaves me with URNs, right?

After reading the specs on the tag URN, I'm very impressed, and think that
it will suit the XML model nicely. Tag URNs provide two extra bonuses I
hadn't anticipated: human readability and decentralized unique agent
identification.

I do wish IRI forms of tag URNs had gotten off the ground, but maybe that
will come some day?

Best wishes,

jk

On Wed, Mar 19, 2014 at 5:39 PM, Dale R. Worley <[email-masked]> wrote:

> of a

-- 
Joel Kalvesmaki
kalvesmaki.com

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 24 Mar 2014 18:48:26 +0900

> I do wish IRI forms of tag URNs had gotten off the ground, but maybe that

Looking at https://tools.ietf.org/html/rfc4151, that indeed seems to be 
an unfortunate oversight.

Instead of
    In the interests of tractability to humans, tags SHOULD NOT be minted
    with percent-encoded parts.  However, the tag syntax does allow
    percent-encoded characters in the "pchar" elements (defined in RFC
    3986 [1]).

It should allow percent-encoded parts also in the authorityName part, 
and specify that in all cases, such percent-encoded parts must be 
created and interpreted using UTF-8. After all, that's what RFC 3986 
(which is heavily cited) says for authority names.

Sandro, Tim, is there a chance this can be fixed sooner or later?

Regards,   Martin.

---

From: Sandro Hawke <[email-masked]>
Date: Mon, 24 Mar 2014 14:44:36 +0300

On 03/24/2014 12:48 PM, "Martin J. Dürst" wrote:
> Looking at https://tools.ietf.org/html/rfc4151, that indeed seems to 
> be an unfortunate oversight.
>
> Instead of
> >>>>

Interesting.   I'm trying to remember the motivations here.

Certainly unnecessary percent encoding is a problem because it causes 
confusion about whether two URIs are the same.   (If you have to ask 
that, they are not.   But people may not realize that.   Some people 
might think "tag:[email-masked],2014:A" and 
"tag:[email-masked],2014:%41" are the same, but they are not.)

On the authorityName, if it's a DNSName, presumably you'd use punycode, 
not percent encoding, right?   If it's an emailAddress, presumably you'd 
use punycode for the DNSname part of it.  I don't know what one's 
supposed to use for the part before the @ in an email address?      I 
haven't kept up on the email standards.    Is there consensus about that?

> Sandro, Tim, is there a chance this can be fixed sooner or later?

I'm not using or endorsing tag: URIs at all these days.   From my 
perspective, http or https URLs are better in very-nearly every 
situation.    But I wouldn't be opposed to someone else updating the tag 
URI spec.

Joel, can I ask why you can't or don't want to use an http or https URL 
instead of a tag?

      -- Sandro

---

From: Joel Kalvesmaki <[email-masked]>
Date: Mon, 24 Mar 2014 10:20:17 -0400

Dear Sandro,

I would like people who do not own or have access to a domain name to be
able to mint names. Further, it's important that names be valid for
centuries to come.

Another important but less critical point is that HTTP URIs give the
impression that one can and should get more information about the item by
making an HTTP request to that string. But the majority of things named in
my data model would have no further online representation, and it would be
nice to avoid giving readers of data the impression that there are or
editors of the data the impression that they ought to be writing and
providing supplementary RDF. The naming system I adopt needs to be
immediately intelligible to ordinary people. And when most people see a URL
they don't think about names, they think about locations to visit--it can
be very confusing, even to very intelligent people.

My concerns are akin to those that have motivated the architects of
Canonical Text Services[1][2][3] to develop the convention "urn:cts:……" to
provide names for ancient literary works, their fragments, and their
versions. their naming scheme stands independent of server performance,
etc. But it also can be easily incorporated into registries that facilitate
Semantic Web applications.

I would appreciate reading reflections and reactions from you and others on
this list.

Best wishes,

jk

[1] http://www.homermultitext.org/hmt-doc/cite/cts-urn-overview.html
[2] Smith, Neel. “Citation in Classical Studies.” *Digital Humanities
Quarterly* 3, no. 1 (2009).
http://www.digitalhumanities.org/dhq/vol/003/1/000028/000028.html.
 [3] Smith, Neel, and C. W. Blackwell. “Four URLs, Limitless Apps:
Separation of Concerns in the Homer Multitext Architecture.” In *Donum
Natalicium Digitaliter Confectum Gregorio Nagy Septuagenario a Discipulis
Collegis Familiaribus Oblatum: A Virtual Birthday Gift Presented to Gregory
Nagy on Turning Seventy by His Students, Colleagues, and Friends*.
Washington, D.C.: Center for Hellenic Studies, 2012.
http://chs.harvard.edu/wa/pageR?tn=ArticleWrapper&bdc=12&mn=4846.

On Mon, Mar 24, 2014 at 7:44 AM, Sandro Hawke <[email-masked]> wrote:

>> It should allow percent-encoded parts also in the authorityName part, and
>> specify that in all cases, such percent-encoded parts must be created and
>> interpreted using UTF-8. After all, that's what RFC 3986 (which is heavily
>> cited) says for authority names.
>>
>>
> confusion about whether two URIs are the same.   (If you have to ask that,
> they are not.   But people may not realize that.   Some people might think "
> tag:[email-masked],2014:A" and "tag:[email-masked],2014:%41" are the
> same, but they are not.)
>
> use punycode for the DNSname part of it.  I don't know what one's supposed
> to use for the part before the @ in an email address?      I haven't kept
> up on the email standards.    Is there consensus about that?
>
>
> perspective, http or https URLs are better in very-nearly every situation.
>    But I wouldn't be opposed to someone else updating the tag URI spec.
>

-- 
Joel Kalvesmaki
kalvesmaki.com

---

From: Sandro Hawke <[email-masked]>
Date: Mon, 24 Mar 2014 23:29:03 +0300

On 03/24/2014 05:20 PM, Joel Kalvesmaki wrote:
> Dear Sandro,
>
> I would like people who do not own or have access to a domain name to 
> be able to mint names. Further, it's important that names be valid for 
> centuries to come.
>
> impression that one can and should get more information about the item 
> by making an HTTP request to that string. But the majority of things 
> named in my data model would have no further online representation, 
> and it would be nice to avoid giving readers of data the impression 
> that there are or editors of the data the impression that they ought 
> to be writing and providing supplementary RDF. The naming system I 
> adopt needs to be immediately intelligible to ordinary people. And 
> when most people see a URL they don't think about names, they think 
> about locations to visit--it can be very confusing, even to very 
> intelligent people.
>
> Canonical Text Services[1][2][3] to develop the convention 
> "urn:cts:……" to provide names for ancient literary works, their 
> fragments, and their versions. their naming scheme stands independent 
> of server performance, etc. But it also can be easily incorporated 
> into registries that facilitate Semantic Web applications.
>
> I would appreciate reading reflections and reactions from you and 
> others on this list.
>

It seems to me like nice, working URLs are always good to have.   I do 
understand sometimes they are too expensive, though, yes.

       -- Sandro

> [2] Smith, Neel. “Citation in Classical Studies.” /Digital Humanities 
> Quarterly/3, no. 1 (2009). 
> Separation of Concerns in the Homer Multitext Architecture.” In /Donum 
> Natalicium Digitaliter Confectum Gregorio Nagy Septuagenario a 
> Discipulis Collegis Familiaribus Oblatum: A Virtual Birthday Gift 
> Presented to Gregory Nagy on Turning Seventy by His Students, 
> Colleagues, and Friends/. Washington, D.C.: Center for Hellenic 
> Studies, 2012. 
> On Mon, Mar 24, 2014 at 7:44 AM, Sandro Hawke <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>         Looking at https://tools.ietf.org/html/rfc4151, that indeed
>         seems to be an unfortunate oversight.
>
>         Instead of
>         >>>>
>         It should allow percent-encoded parts also in the
>         authorityName part, and specify that in all cases, such
>         percent-encoded parts must be created and interpreted using
>         UTF-8. After all, that's what RFC 3986 (which is heavily
>     Certainly unnecessary percent encoding is a problem because it
>     causes confusion about whether two URIs are the same. (If you have
>     to ask that, they are not.   But people may not realize that.  
>     Some people might think "tag:[email-masked]
>     <mailto:[email-masked]>,2014:A" and "tag:[email-masked]
>     <mailto:[email-masked]>,2014:%41" are the same, but they
>     are not.)
>
>     On the authorityName, if it's a DNSName, presumably you'd use
>     punycode, not percent encoding, right?   If it's an emailAddress,
>     presumably you'd use punycode for the DNSname part of it.  I don't
>     know what one's supposed to use for the part before the @ in an
>     email address?      I haven't kept up on the email standards.  
>      Is there consensus about that?
>
>
>     situation.    But I wouldn't be opposed to someone else updating
>     the tag URI spec.
>
>     Joel, can I ask why you can't or don't want to use an http or
>     https URL instead of a tag?
>
>          -- Sandro
>
>         Regards, Martin.
>
>
>
>
>
> -- 
> Joel Kalvesmaki
> kalvesmaki.com <http://kalvesmaki.com>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 25 Mar 2014 10:21:44 -0400

I don't have much opinion on what the "best" type of URI to use is.
And I know nothing about IRIs, though I'm fairly versed in URIs.

> From: "Martin J. Dürst" <[email-masked]>

> From: Sandro Hawke <[email-masked]>

> haven't kept up on the email standards.    Is there consensus about that?

If the tag URI authorityName is a DNSname, then we can use the current
"punycode" conversion (RFC 3490), and anyone who cares can recognize
and convert for display purposes any DNS label that is punycoded.
That output is within the syntax for tag URIs.

The same holds for the DNSname part of an emailAddress authorityName.

The local-part (per RFC 822) part of an emailAddress is more difficult
to handle.  To start with, the syntax specified in RFC 4151 (tag URIs)
is neither a subset nor a superset of of the syntax specified in RFC
822.  (E.g., RFC 4151 permits two adjacent ".", but RFC 822 permits
"~".)  So RFC 4151 already has a problem that it does not admit all
e-mail addresses that RFC 822 admits.  OTOH, there are tag URI
emailAddresses that are syntactically forbidden by RFC 822, which may
allow some space for extensions.

The internationalization of e-mail address local-names is in RFC 5335,
essentially by permitting non-ASCII UTF-8 characters much as if they
are ASCII letters.  Since URIs cannot contain non-ASCII characters
that doesn't help us.

Perhaps we could define an extension, where the local-name in the
emailAddress is ".." followed by the punycode encoding of the actual
internationalized e-mail local-part?  That is similar to what is done
with domain names and could be automatically recognized and translated
for display.  This convention would also allow representation of
local-parts that conform to RFC 822 but not to RFC 4151.  And it
remains within the syntax of RFC 4151.  (Though it looks like Punycode
would have to be modified to understand that some ASCII characters
aren't in the base character set.)

In regard to the "specific" part of the URI, the arbitrary part which
comes after taggingEntity, though the narrative of RFC 4151 says
percent-encoding shouldn't be used, the syntax explicitly permits it,
and the narrative only forbids percent-encoding at "SHOULD" strength,
which officially means "there may exist valid reasons in particular
circumstances to ignore a particular item, but the full implications
must be understood and carefully weighed before choosing a different
course."  And internationalization seems to be a valid reason to me.

Similarly, percent-encoding can be automatically recognized and
parsed for display purposes.

> "tag:[email-masked],2014:%41" are the same, but they are not.)

You have to be careful with that, because the equivalence rule depends
on the URI scheme.  In the case of tag URIs, the rule is given in RFC
4151 section 2.4, and it requires that different strings are never
equivalent:

   2.4.  Equality of Tags

   Tags are simply strings of characters and are considered equal if and
   only if they are completely indistinguishable in their machine
   representations when using the same character encoding.  That is, one
   can compare tags for equality by comparing the numeric codes of their
   characters, in sequence, for numeric equality.  This criterion for
   equality allows for simplification of tag-handling software, which
   does not have to transform tags in any way to compare them.

> able to mint names. 

The current tag scheme doesn't allow that, but it's fairly simple to
get around that problem.  (Although it's difficult to imagine anyone
who would use this system but not have an e-mail address.)  We need
some person or enterprise that has a legitimate authorityName to
delegate parts of its URI space to owners who do not have
authorityNames.  So we could separate:

    tag:[email-masked],2014:delegations:person-A:[person A's string]
    tag:[email-masked],2014:delegations:person-B:[person B's string]
    tag:[email-masked],2014:delegations:person-C:[person C's string]
    tag:[email-masked],2014:delegations:person-D:[person D's string]

We could probably set up an automatic delegation system much
resembling how tag URIs are delegated by allowing each possessor of a
telephone number a set of strings:

    tag:[email-masked],2014:delegations:17816479199,2014:[my string]

would be automatically delegated to me because I possessed the use of
that E.164 number on 2014-01-01.

> Further, it's important that names be valid for centuries to come.

Fortunately, that's fairly easy to arrange as long as people don't
mis-construct the URIs.

> "urn:cts:..." to provide names for ancient literary works, their
> fragments, and their versions. their naming scheme stands
> independent of server performance, etc. But it also can be easily
> incorporated into registries that facilitate Semantic Web
> applications.

Good Lord, haven't they thought to properly register those schemes?  I
don't see them listed in
http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml .

Dale

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 26 Mar 2014 11:35:57 +0900

Hello Sandro,

> "tag:[email-masked],2014:%41" are the same, but they are not.)

Actually, they are not the same for XML namespaces and for RDF, but for 
http and for search engines, they are (pretty much) the same. Now tag: 
URIs are probably more used in RDF than in http, so your point is 
certainly important.

> not percent encoding, right?

Well, if it's an IRI, just use the original characters :-).

> If it's an emailAddress, presumably you'd

Please see https://tools.ietf.org/html/rfc6531 and 
https://tools.ietf.org/html/rfc6532. Essentially, UTF-8 is used in the 
mail protocol and format. For URIs, see 
http://tools.ietf.org/html/rfc6068. So again, just using the actual 
characters is the best thing to do.

> situation.    But I wouldn't be opposed to someone else updating the tag

Noted!

Regards,   Martin.

---

From: Joel Kalvesmaki <[email-masked]>
Date: Wed, 26 Mar 2014 10:27:53 -0400

Thanks, Dale,

> that E.164 number on 2014-01-01.

My caveat on users' access to domain names wouldn't apply to email
addresses (I can safely assume users of this data model will have, at some
point, some email address), but your delegations idea is very interesting
to see.

> http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml .

Sorry I can't speak to this, since I'm not using any CTS urns, and I wanted
to avoid creating a new urn scheme. I think what the architects have
published so far suggests that they still have work to do, esp. on defining
validity and developing rules for a registry (or explaining why no registry
would be needed).

Best wishes,

jk
-- 
Joel Kalvesmaki
kalvesmaki.com