Re: draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00
worley@ariadne.com (Dale R. Worley) Wed, 17 December 2014 18:51 UTC
Return-Path: <worley@alum.mit.edu>
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 F42371A7029 for <urn-nid@ietfa.amsl.com>; Wed, 17 Dec 2014 10:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_35=0.6, SPF_SOFTFAIL=0.665] autolearn=no
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 lkv6aBsozmxE for <urn-nid@ietfa.amsl.com>; Wed, 17 Dec 2014 10:51:28 -0800 (PST)
Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCBB1A702E for <urn-nid@ietf.org>; Wed, 17 Dec 2014 10:51:25 -0800 (PST)
Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-06v.sys.comcast.net with comcast id Uiqb1p0092TL4Rh01irQXM; Wed, 17 Dec 2014 18:51:24 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by resomta-ch2-17v.sys.comcast.net with comcast id UirP1p0051KKtkw01irPLD; Wed, 17 Dec 2014 18:51:24 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id sBHIpMQ7025415; Wed, 17 Dec 2014 13:51:22 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id sBHIpMWr025412; Wed, 17 Dec 2014 13:51:22 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Sean Leonard <dev+ietf@seantek.com>
Subject: Re: draft-seantek-rdf-urn-00 and draft-seantek-xmlns-urn-00
In-Reply-To: <01A05285-E4B8-4BDD-9010-C7B6D83D5F1A@seantek.com> (dev+ietf@seantek.com)
Sender: worley@ariadne.com
Date: Wed, 17 Dec 2014 13:51:22 -0500
Message-ID: <87fvcep0t1.fsf@hobgoblin.ariadne.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418842284; bh=R9hdxLkdYm1a+f0ko5YTn0fZj0s8TbFSFXk6MPLAKRI=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=KaSOmMG4Sjx/7GPHvezPnx2ia/8VKAzdXe7pX5E8VCuTsdrHqlDDbE4Ylxu3wiQqa ICUpjRvi5UDNvezxuu1qbdSYWnkeweKlUSO4gnM0Qj4Z43yYn0sSvXyG0dPH3zzI6U B6h0BWTE4Yc9muAr1aGUwgDF4RKesW+6EEVUSbpHNQHRiZoK1V3xHPLjrtd9QeSs8f C6VyjvH28okX1vB6MuQ6lCoIkbnSdZt5lsmq1DujKK1aNVrDZPdkBVxReHYR2o2FE6 6GqMaUqh2YmQaFy97mOPT3Zmds05ObRpkGzOa96queE3Tz3+/DQoV0Ahq6LJ20AXTz +Uuw9QwsS5qGA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn-nid/UV5FUniYaCBoRN7OmV_zZdGmiNw
Cc: 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: Wed, 17 Dec 2014 18:51:30 -0000
Sean Leonard <dev+ietf@seantek.com> writes: > Thought about it. But urn:xmlns:foobar and urn:rdf:foobar are > preferable to urn:SOMENID:xmlns:foobar and urn:SOMENID:rdf:foobar. The > shorter the better--remember that we are competing with > http://example.com/foobar. I was considering not syntactically distinguishing XML namespaces and RDF references, so both would be of the form urn:id:foobar. ("id" is available as a NID!) That would be even shorter. In regard to "remember that we are competing with http://example.com/foobar", I know of no such "competition". Can you update the draft to explain why this is important? > Furthermore, urn:xmlns and urn:rdf represent distinct namespaces. The > (abstract) resources accessible via and relevant to urn:xmlns are > different from urn:rdf, and additional utility is gained by having > particular classes of resources made permanently accessible in those > distinct namespaces. I don't see any value for syntactically distinguishing which URNs are XML namespace identifiers and which are RDF references, since the contexts in which the two would be used are disjoint. Can you update the draft to explain why this is important? For that matter, I don't see any value for ensuring the URNs are brief. To my knowledge, humans rarely input or output URNs. The draft says "several URN namespace registrations have been proposed over the years, where the primary (yet only occasionally stated) purpose is to create short URIs for the registrant's XML namespaces". But it seems to me that generally NIDs are created to delegate the ability to create URNs to some industry consortium, not to ensure that the consortium can create brief URNs. Can you update the draft to explain why this is important? >> In regard to the registration of the URIs associated with URNs and the >> resolution of the URNs into the associated URIs, let me propose that >> this data be be retrievable from some suitable zone of the DNS along >> the following lines: > > Thanks, it's a good idea. > > However, I was thinking that the URIs be accessible at the resource(s) > at something starting with: > http://www.iana.org/assignments/urn-xmlns-names > http://www.iana.org/assignments/urn-rdf-names Whatever the resolution mechanism is, it's clear that the method of accessing the resolution database is intrinsic to your proposal. But your proposal gives no details as to how to access the resolution database, or how IANA would implement it. The former is an intrinsic part of the definition of the namespace. The latter is a critical piece of IANA infrastructure. So you need to discuss these and ensure that there is a robust conversation about these questions. In regard to comparison with using "http://example.com/foobar", the latter has the advantage that *IANA* doesn't have to maintain resolution information, the URL itself can be used to fetch resolution information, and the server for the information can be maintained by someone else. Dale
- Review and URN assignment for draft-seantek-rdf-u… Sean Leonard
- Comments on draft-seantek-rdf-urn-00 Dale R. Worley
- Re: Comments on draft-seantek-rdf-urn-00 Sean Leonard
- draft-seantek-rdf-urn-00 and draft-seantek-xmlns-… Dale R. Worley
- Re: draft-seantek-rdf-urn-00 and draft-seantek-xm… Sean Leonard
- Re: draft-seantek-rdf-urn-00 and draft-seantek-xm… Dale R. Worley
- Re: draft-seantek-rdf-urn-00 and draft-seantek-xm… Sean Leonard
- Re: draft-seantek-rdf-urn-00 and draft-seantek-xm… Sean Leonard
- Re: draft-seantek-rdf-urn-00 and draft-seantek-xm… Dale R. Worley