Re: [urn] URN fragments

"Svensson, Lars" <L.Svensson@dnb.de> Wed, 27 February 2013 08:37 UTC

Return-Path: <L.Svensson@dnb.de>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEE621F85EE for <urn@ietfa.amsl.com>; Wed, 27 Feb 2013 00:37:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.649
X-Spam-Level:
X-Spam-Status: No, score=-9.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw9ZaVeqvJco for <urn@ietfa.amsl.com>; Wed, 27 Feb 2013 00:37:50 -0800 (PST)
Received: from nordpol.ddb.de (nordpol.ddb.de [193.175.100.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2387721F85FD for <urn@ietf.org>; Wed, 27 Feb 2013 00:37:49 -0800 (PST)
Received: from dnbf-ex1.AD.DDB.DE (unknown [10.69.63.245]) by nordpol.ddb.de (Postfix) with ESMTP id 079B6C1E34; Wed, 27 Feb 2013 09:36:25 +0100 (CET)
From: "Svensson, Lars" <L.Svensson@dnb.de>
To: Juha Hakala <juha.hakala@helsinki.fi>, Julian Reschke <julian.reschke@gmx.de>
Thread-Topic: [urn] URN fragments
Thread-Index: AQHOFEQvb/Brr29raE+r4pMD+ef6CZiMdQSAgAAHigCAALsyAIAAJrvg
Date: Wed, 27 Feb 2013 08:37:46 +0000
Message-ID: <24637769D123E644A105A0AF0E1F92EFA403A537@dnbf-ex1.AD.DDB.DE>
References: <512606BC.7020902@helsinki.fi> <5126E7D6.6050301@stpeter.im> <512716C6.4090308@helsinki.fi> <512CDC48.9070703@gmx.de> <512CEC80.8020702@stpeter.im> <20130226212621.Horde.y3L08bLxxMiNJYU7FS9abA1.jehakala@webmail.helsinki.fi> <512D12B0.4050304@gmx.de> <512DAFB8.7070704@helsinki.fi>
In-Reply-To: <512DAFB8.7070704@helsinki.fi>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.69.12.122]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] URN fragments
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2013 08:37:51 -0000

Juha, Julian, all,

On February 27, 2013, 08:03, Juha wrote 
> On 26.2.2013 21:53, Julian Reschke wrote:
> >
> >> It is a different string, thus a different URI, as dictated by RFC
> 3986.
> >>
> >> But it is the same URN, since fragment is not part of the Namespace
> >> specific string, as specified by the Alfred Hoenes' version of the
> >> URN syntax, or any other syntax specification which approves the
> >> current idea that fragment is not part of the NSS. And we know
> >> already that incorporating the fragment into NSS would cause a lot
> of
> >> avoidable trouble (for instance, many namespaces could not use
> fragment at all).
> >
> > I was actually talking about the query part; sorry for the confusion.
> >
> > It's up to the URN or NIS syntax to describe what the query part
> > means, and how it applies to different namespaces. But in *general*,
> > adding a query part to a URI changes the resource being identified.
> 
> You have to be careful with the word "identify" in the URN context.
> 
>  From the URN point of view, the resource identified does not change
> when a query is added, if queries are used to facilitate the services
> specified in RFC 2483. All these services are related to one and only
> one identified resource.  A user can request for instance the resource
> itself, metadata about it, its current URL or URLs, and so forth. In
> practice, HTTP URIs (locations) the URN resolves to and the things that
> are being retrieved change, but the resource identified by the
> (location
> independent) URN does not.

I think this depends on your urn namespace. In my opinion, we need to differ between queries that "operate on the urn itself" (in lack of a better description) and queries aimed at passing information to resolution services. As to the question if the query is part of the urn or not, my reading of rfc 3986 §3.4 is that it _is_ part of the urn
[[
The query component is indicated by the first question mark ("?") character and terminated by a number sign ("#") character or by the end of the URI.]]
If the query component ends at the end of the URI, it must be part of it.

Regarding the difference between queries in the context of the urn itself and in the context of resolution services, I made up a case to illustrate my point (thereby deliberately moving away from urn:nbn and urn:isbn).

In order to ensure that we can always identify integers in a location-independent way, we have registered the urn namespace 'int'. The NSS is defined as eight hexadecimal digits. Examples would be urn:int:0000000F ; urn:int:A0001234 . By doing this, we have unique names for those numbers and nothing more.

1)	Now we want to define other representations (decimal, octal, binary) of those hex numbers, and we do that by adding query parts to the urn. Example: urn:int:0000000F?base=10 would identify 15 (decimal). In this case adding the query does not change the resource (the integer remains the same, the query merely changes its representation). In this case we have two different URIs identifying the same thing (the number 15 = 0x0F = 00001111 = .)

2)	We also want to be able to identify the next and the previous integer and we do that through the relations "next" and "previous". As an example: urn:int:0000000F?rel=next would identify the same as urn:int:00000010. In this case the query part turns urn:int:000000F into another resource identifying something else (the number 16 = 0x10 = 00010000 = . ).

In the second case, the query part modifies the resource itself. You could say that the query "belongs to the urn".
In the first case, the query part modifies the representation of the resource. This should (in my opinion) be handled by a resolution service.

In this discussion we need to differ between queries in the context of the urns themselves and queries in the context of resolution services. Those are in my opinion not the same.

I hope this helps.

All the best,

Lars


***Lesen. Hören. Wissen. Deutsche Nationalbibliothek***
***Reading. Listening. Understanding. German National Library***

-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek / Informationstechnik
http://www.dnb.de/
l.svensson@dnb.de