Re: URN UUID question

Sandro Hawke <sandro@w3.org> Mon, 24 March 2014 20:29 UTC

Return-Path: <sandro@w3.org>
X-Original-To: urn-nid@ietfa.amsl.com
Delivered-To: urn-nid@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD781A02AC for <urn-nid@ietfa.amsl.com>; Mon, 24 Mar 2014 13:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSftBqg1LuEZ for <urn-nid@ietfa.amsl.com>; Mon, 24 Mar 2014 13:29:12 -0700 (PDT)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id E389F1A0268 for <urn-nid@ietf.org>; Mon, 24 Mar 2014 13:29:11 -0700 (PDT)
Received: from [78.100.51.155] (helo=[172.20.1.82]) by jay.w3.org with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <sandro@w3.org>) id 1WSBUa-0003V1-3H; Mon, 24 Mar 2014 16:29:08 -0400
Message-ID: <5330958F.2020903@w3.org>
Date: Mon, 24 Mar 2014 23:29:03 +0300
From: Sandro Hawke <sandro@w3.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Joel Kalvesmaki <kalvesmaki@gmail.com>
Subject: Re: URN UUID question
References: <CALPpAZ_fLwK80dcM5ty5pp2pLiafpW36uvK2WoJdKpuaWX6PQw@mail.gmail.com> <201403192139.s2JLdchi012675@hobgoblin.ariadne.com> <CALPpAZ8oqUMg6Q+HZjhkyCDPGOnFYYrrrXY=Jxr8OJH2YU39FQ@mail.gmail.com> <532FFF6A.6080206@it.aoyama.ac.jp> <53301AA4.30402@w3.org> <CALPpAZ83YDVFuCZottF0xV3AWbxk0t8krcYQyTuSCFb+w8zWUw@mail.gmail.com>
In-Reply-To: <CALPpAZ83YDVFuCZottF0xV3AWbxk0t8krcYQyTuSCFb+w8zWUw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------070501010300060406030701"
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/yxncPEpy5JoHlzbPAKC-WSX1zPY
Cc: timothy@hpl.hp.com, urn-nid@ietf.org
X-BeenThere: urn-nid@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: discussion of new namespace identifiers for URNs <urn-nid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn-nid/>
List-Post: <mailto:urn-nid@ietf.org>
List-Help: <mailto:urn-nid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn-nid>, <mailto:urn-nid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Mar 2014 20:29:17 -0000

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.
>
> 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.
>

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

       -- Sandro

> 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 <sandro@w3.org 
> <mailto:sandro@w3.org>> 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 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.
>
>
>     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:sandro@hawke.org
>     <mailto:tag%3Asandro@hawke.org>,2014:A" and "tag:sandro@hawke.org
>     <mailto:tag%3Asandro@hawke.org>,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
> kalvesmaki.com <http://kalvesmaki.com>