Re: [urn] URN fragments

Peter Saint-Andre <> Fri, 22 February 2013 03:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C947821E8054 for <>; Thu, 21 Feb 2013 19:37:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.586
X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5UZUv6Wy3KYG for <>; Thu, 21 Feb 2013 19:37:06 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 029CA21E803D for <>; Thu, 21 Feb 2013 19:37:06 -0800 (PST)
Received: from [] (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 773A54060C; Thu, 21 Feb 2013 20:44:38 -0700 (MST)
Message-ID: <>
Date: Thu, 21 Feb 2013 20:36:54 -0700
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: Juha Hakala <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [urn] URN fragments
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Feb 2013 03:37:11 -0000

Hash: SHA1

On 2/21/13 4:36 AM, Juha Hakala wrote:
> Hello Peter; all,
> Concerning this:
>> Could you also explain (perhaps in a separate thread) the
>> intended use of the fragment identifier?
> It took a while before the bibliographic community got a
> sufficient grasp of how fragment can best be used in the URN
> context. Initially we thought that fragment should be part of the
> URN namespace specific string, but we realized soon that that would
> complicate things a lot. Since many (most, probably) standard
> namespaces do not allow add-ons to identifier strings, this:
> Ex. 1
> would have been possible, but not this (NOTE: this is only an
> example)
> Ex. 2
> Moreover, adding a fragment to an existing URN would in this case
> have been an act of identifier assignment, which in some namespaces
> is a managed process, so too few people would have been allowed to
> use fragments with URNs.
> Eventually Alfred Hoenes, myself and others concluded that the
> best solution is to separate identification & URN assignment from
> fragment assignment, that is, not to include fragment in the NSS.
> Which means that fragments can be added to the URN by anybody, any
> time after the URN has been assigned and the document made
> available (via URN resolution) in the Internet.

Hi Juha, this model sounds similar to what you described for the query
component: the fragment can be "added to the URN". I'm not sure what
that means. When you add a query component or a fragment identifier to
the URN, is that now a different URN (which wasn't assigned by the
minting organization or in accordance with the minting algorithm)? Or
is "a URN with some additional data appended" and therefore not really
a URN anymore? Or is actually a URI (such as an HTTP URI) whose path
is the URN itself as just a string of characters embedded in the
broader URI?

Still confused,


- -- 
Peter Saint-Andre

Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Thunderbird -