Re: URN UUID question

Joel Kalvesmaki <> Mon, 24 March 2014 14:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 874CA1A0254 for <>; Mon, 24 Mar 2014 07:20:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aj2BGx7eRuHa for <>; Mon, 24 Mar 2014 07:20:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::22d]) by (Postfix) with ESMTP id A879A1A0246 for <>; Mon, 24 Mar 2014 07:20:18 -0700 (PDT)
Received: by with SMTP id il7so5752908vcb.4 for <>; Mon, 24 Mar 2014 07:20:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7xSZi5CsQoFrKQCc1u+k2o0irqQ0d/7I5irfMdfhKZE=; b=B6Hc6Y4mYhLiegeY9uC1nH+xogh9mtqrExxQAuN5LcnmFD1oYEd2lkN2qln62QQ+7U 24GENSgwySCrL4iFNwaOb3IX5DquY6Vcmupl1VCO7N2hGcL3wpbbgNyjceNDSy5jEAbP Va9NH6MJxEi5X8Qy8T/GKwZQUj/Li+PE9+UARzMifwcs7z5M4QtO2ZICejgB4SY9yjuY FlxtX8h/F4Mxs1crgPxymEOYlaDmCLTw2OzXaJCoVHX+R7akndJOjWuP9sQtf31u2eCj 3IhsFbC3gns+/ecCCHPmD6JTixNrd4uaOQxR3Ve5HbsInM8TUwCDNMbPzr7UarpcvDH5 GRBw==
MIME-Version: 1.0
X-Received: by with SMTP id mx11mr271357vdb.41.1395670817738; Mon, 24 Mar 2014 07:20:17 -0700 (PDT)
Received: by with HTTP; Mon, 24 Mar 2014 07:20:17 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Mon, 24 Mar 2014 10:20:17 -0400
Message-ID: <>
Subject: Re: URN UUID question
From: Joel Kalvesmaki <>
To: Sandro Hawke <>
Content-Type: multipart/alternative; boundary=bcaec520f6895096a904f55aef22
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Mar 2014 14:20:24 -0000

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,


[2] Smith, Neel. “Citation in Classical Studies.” *Digital Humanities
Quarterly* 3, no. 1 (2009).
 [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.;mn=4846.

On Mon, Mar 24, 2014 at 7:44 AM, Sandro Hawke <> wrote:

> On 03/24/2014 12:48 PM, "Martin J. Dürst" wrote:
>> On 2014/03/20 09:15, Joel Kalvesmaki wrote:
>>  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.
>>  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?
>> Looking at, 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.
> 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 "
>,2014:A" and ",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
>  Regards, Martin.

Joel Kalvesmaki