[urn] R: [apps-discuss] URNs are not URIs (another look at RFC 3986)

Maurizio Lunghi <Lunghi@rinascimento-digitale.it> Thu, 24 April 2014 08:25 UTC

Return-Path: <Lunghi@rinascimento-digitale.it>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238F91A0564; Thu, 24 Apr 2014 01:25:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.615
X-Spam-Level: **
X-Spam-Status: No, score=2.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RDNS_DYNAMIC=0.982] 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 AFm9Bc59XoKo; Thu, 24 Apr 2014 01:25:44 -0700 (PDT)
Received: from remote.rinascimento-digitale.it (93-63-166-139.ip28.fastwebnet.it [93.63.166.139]) by ietfa.amsl.com (Postfix) with ESMTP id 952241A03A8; Thu, 24 Apr 2014 01:25:43 -0700 (PDT)
Received: from FRD01.frd.local ([fe80::30bc:ca96:e16f:8923]) by FRD01.frd.local ([fe80::30bc:ca96:e16f:8923%10]) with mapi id 14.03.0174.001; Thu, 24 Apr 2014 10:25:31 +0200
From: Maurizio Lunghi <Lunghi@rinascimento-digitale.it>
To: Phillip Hallam-Baker <hallam@gmail.com>
Thread-Topic: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)
Thread-Index: AQHPXvsdozmNQKT390aYaUTyYZpG/ZsgVovA
Date: Thu, 24 Apr 2014 08:25:30 +0000
Message-ID: <E3A975140557FF40879935411BB02C6C07034EB4@FRD01.frd.local>
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> <E0E032D69C38D6405A505541@JcK-HP8200.jck.com> <CAMm+LwgowVh=+Sr8DST6=NeizkO9RsgePegrEFNsv2sXQaz=0g@mail.gmail.com> <80E9D81C-B469-4499-A7F2-983FBDE228A7@rinascimento-digitale.it> <CAMm+Lwh1hHhJyGqZ-LSvVkgKhivsUVRc7ye3g1im9sHh2of7pw@mail.gmail.com>
In-Reply-To: <CAMm+Lwh1hHhJyGqZ-LSvVkgKhivsUVRc7ye3g1im9sHh2of7pw@mail.gmail.com>
Accept-Language: it-IT, en-US
Content-Language: it-IT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.103]
x-tm-as-product-ver: SMEX-10.5.0.1057-7.500.1017-20652.005
x-tm-as-result: No--29.511200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/qLT-vGVibgMIwhJuHxpqfLURqGU
Cc: General discussion of application-layer protocols <apps-discuss@ietf.org>, "Julian F. Reschke" <julian.reschke@gmx.de>, Graham Klyne <GK@ninebynine.org>, Mark Nottingham <mnot@mnot.net>, "urn@ietf.org" <urn@ietf.org>
Subject: [urn] R: [apps-discuss] URNs are not URIs (another look at RFC 3986)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 24 Apr 2014 08:25:46 -0000

Maybe I was not clear, but a wish list is to think that your technical solutions can be considered 'Persistent Identifiers'
First, in the digital preservation arena we consider that policy are more important than technology actually, all the digital preservation applications have a strong and well defined policy in support of their goals, technology will be migrated in the years. As you said, any technology can become a PI if supported by an appropriate policy and application.
Second, in our recent work we agreed on that a PI is not only a number or string, a PI is a service where to that code an information service is granted by a trusted agency with a defined mandate in time and for a specific user community, this is then case for all the most relevant PI systems like DOI, Handle, ARK, NBN, and for the emerging PI systems for people also. In our work a PI system is composed by a reliable technology, a trusted body offering the service, a policy and mandate by the user community.
That's why I have the impression that we should define criteria for a trusted PI system in another document, as we have done about the trusted digital repositories issue with RLG, OCLC, TRAC, OAIS, ISO16363 ....

thanks

Maurizio Lunghi
direttore scientifico
Fondazione Rinascimento Digitale
lunghi@rinascimento-digitale.it  
+393351396371

-----Messaggio originale-----
Da: Phillip Hallam-Baker [mailto:hallam@gmail.com] 
Inviato: mercoledì 23 aprile 2014 15:51
A: Maurizio Lunghi
Cc: John C Klensin; Julian F. Reschke; Mark Nottingham; urn@ietf.org; Graham Klyne; General discussion of application-layer protocols
Oggetto: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

On Wed, Apr 23, 2014 at 6:04 AM, Maurizio Lunghi <Lunghi@rinascimento-digitale.it> wrote:
> I am wondering if it is useful and maybe necessary to define what a 'persistent identifier' is .... as many of you said technology is mot persistent per se but policy underpinning the system can make persistent the identifiers and the service linked to them .... in the APARSEN project www.aparsen.eu in WP 22 we reached agreement with many experts about a list of criteria that a 'trusted persistent identifier system' must have and we could start from this work to define a broader consensus .... doing so in my view we  could clearly distinguish between a URN or URI and a PI ... does it sound reasonable?
>

People have been compiling wish lists for properties of names for 20+ years. The issue is not what people would want, it is what they can get.

I can't take the 'urn' approach seriously until someone provides an explanation of

1) How the persistence properties are to be achieved

2) Why a taxonomic distinction between URLs and URNs helps achieve the persistence properties.


A name is by definition a signifier that bears only a conventional relationship to the thing signified. In the case of DNS that relationship is mediated by the DNS infrastructure.

There are only two ways to make an identifier persistent. The first being to use an index rather than a name. SHA256(c) is a persistent identifier for the content c. Which is what we use in the ni: scheme.

The second is to have a first come, first served registry that never revokes previous assignments. Now one could imagine a whole new infrastructure for establishing such a scheme. But really, wouldn't anyone setting up such a scheme apply for a TLD?

So now imagine we have .pid which is a first come, first served registry that never revokes an assignment or alternatively requires the date to be inserted into the HTTP URIs.

I can give you a HTTP method identifier which is persistent using such an infrastructure.

Now we can argue over whether the proposal I make is actually practical. But I think it is at least as practical as all the 'persistent identifier' schemes based on a new registry.


The bottom line is that persistence is a qualified property of a naming infrastructure, not a syntactic distinction.

If people want to argue further, I want them to put up and show HOW their persistence scheme actually works. No more wish lists or requirements for identifiers. I want to see how the scheme works at a technical and political level to achieve the persistence requirements.



--
Website: http://hallambaker.com/