Fwd: Publication request for draft-spinosa-urn-lex

Enrico Francesconi <francesconi@ittig.cnr.it> Thu, 19 March 2015 22:17 UTC

Return-Path: <enrico.francesconi@gmail.com>
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 8A9421B2AF4 for <urn-nid@ietfa.amsl.com>; Thu, 19 Mar 2015 15:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 NPLnA5U17rLj for <urn-nid@ietfa.amsl.com>; Thu, 19 Mar 2015 15:17:18 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2E911A88EE for <urn-nid@ietf.org>; Thu, 19 Mar 2015 15:17:17 -0700 (PDT)
Received: by wgbcc7 with SMTP id cc7so74454861wgb.0 for <urn-nid@ietf.org>; Thu, 19 Mar 2015 15:17:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to; bh=eUZ0ntj8OgKEokbdLhkzSjiX9RhW/WVuQaj+l4W+uPI=; b=RySrrUzP5GvW9qRea21x2hKD8enrV6v94jrEftzc5+b6kbPMe4PBa14DcuOgRheu77 oyrCxZ5woezh56c+5SLEk9JPU1xSFfOWKGh1TcCqSyP4WyZAivgsSDpxT3gA5jNyTO1q nLgMhnz4LcO32SGjSpegDE9Pkv89JWKj5j2UhyyWvvwoyzvlPzJl+IemWC+UQABwmWG9 rrlZV1ClxHx7f/16AjxatsSi/axP/R8Z7v2+UUEPmFXR3c2puoZF4Vcx1sdSYFKFUg3D m/j/tTpL8bRVyZ1HnYquZI47C/egukEaXOpm7J1hbKFLXSBMQ4a/EmaMISIk2zPhe/Go 40mQ==
X-Received: by 10.194.110.69 with SMTP id hy5mr159563346wjb.121.1426803436596; Thu, 19 Mar 2015 15:17:16 -0700 (PDT)
Received: from [192.168.0.4] (catv-178-249-195-145.internet.lu. [178.249.195.145]) by mx.google.com with ESMTPSA id a13sm3721117wjx.30.2015.03.19.15.17.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Mar 2015 15:17:15 -0700 (PDT)
Sender: Enrico Francesconi <enrico.francesconi@gmail.com>
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Subject: Fwd: Publication request for draft-spinosa-urn-lex
From: Enrico Francesconi <francesconi@ittig.cnr.it>
Date: Thu, 19 Mar 2015 23:17:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F01A9E4-9D82-4154-95A6-7B60E54087B0@ittig.cnr.it>
References: <550ABF16.3050705@ittig.cnr.it>
To: Barry Leiba <barryleiba@computer.org>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/urn-nid/jLABo69sJHYwI67qPZi80OywGfI>
Cc: "urn-nid@ietf.org" <urn-nid@ietf.org>, Andrew Newton <andy@hxr.us>, Pierluigi Spinosa <pierluigi.spinosa@ittig.cnr.it>
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: Thu, 19 Mar 2015 22:17:21 -0000

Dear Barry,
   first of all sorry for our delay, but in this period several changes have occurred in our organization (among the others my (Enrico's) moving to Luxembourg for a role in the European Commission), so we haven’t had the chance to meet and talk about this issue regularly.
Anyway please find below our considerations:


>        On 14/dic/2014, at 20:53, Barry Leiba
>        <barryleiba@computer.org
>        <https://e-aj.my.com/compose/?mailto=mailto%3abarryleiba@computer.org>>
>        wrote:
> 
>        OK, I've looked again at your responses to my review, and at the
>        changes you've made.  I see that you've made some of the
>        minor changes
>        I suggested, but that you're holding firm on some of the
>        major points,
>        which you haven't made changes for. I'll come back to the two of
>        those that I think are most important:
> 
>        * You very much want to mandate a mapping between the title
>        of the
>        document and the URN.  I think this is very much
>        ill-advised. You
>        think this provides discoverability, in that someone can
>        look at a
>        document title and determine the URN without having to look
>        it up.  I
>        think this will fail miserably in practice, because there
>        are too many
>        variables and there will be no way to get it right, in general.
>        Surely it will work sometimes, but it will fail to work
>        often enough
>        that people will have to use searches to find the URN
>        anyway, and the
>        mandated mapping will simple run counter to the filing
>        systems that
>        some jurisdictions will need to use.
> 
>        So I stand by my suggestion that you make that a suggested
>        mechanism,
>        and soften the language that mandates it as the only way.

We think that there might be a misunderstanding here and probably we weren’t enough clear to describe the metadata used.
Actually urn:lex standard is not based on the title of the document: the title is suggested to be used only if the other metadata are not sufficient to guarantee the identification.
We have revised the document and we are wondering whether the term “header” might be misleading. For example when we talk about the metadata at work level, for the field <details> we say:
"<details> are the terms associated to the measure, typically the date (usually the signature date) and the number included in the heading of the act”.

For “header” here we mean the section of a legal document containing the formal parameters with which a legal document is usually identified in the legal practice, and used for example in legal citations. Let’s consider for example the following:
Legislative decree, 18 February 2015 n .7 "Urgent measures against terrorism”
We consider:
Header= Legislative decree, 18 February 2015 n .7 (metadata used: issuing authority=“state"; type of act=“legislative.decree"; date="2015-02-18"; number=“7",
hence => urn:lex:[country-code]:state:legislative.decree:2015-02-18;7) Title= "Urgent measures against terrorism” (not used)

If using the term “header” is a source of misunderstanding, we can definitely change it in something more specific.
On the other hand the use of the title is limited to the cases in which the title itself, rather than other formal parameters, is commonly used to refer to a legal act. In these cases the title is considered as an additional information that can be added to the formal parameters to facilitate the identification.
Obviously we can have such advantages by using a resolver allowing partial matches (always to be suggested), therefore able to select all the URNs having parts in common with the one deduced from the citation.
For example if "consolidated act on public procurements” is the way the "consolidated act of 20 March 2008, n. 21" is better known and typically used in citations, the related urn:lex can be created as follows
"urn:lex:it:state:consolidated.act;public.procurements:2008-03-20;21”
so that the identification of the related document can be facilitated from a citation including the title only and no other formal parameter, thus limiting the set of documents actually retrieved.

In our case the URN deduced from the citation is "urn:lex:it:state:consolidated.act;public.procurements” that matches a very little number of act URNs, probably only one.
If the title is not used, the URN derived from the citation would be “urn:lex:it:state:consolidated.act” which would retrieve back all the existing consolidated acts (on immigration, on education, etc), therefore being not enough selective.

> 
>        * There's a bunch of other stuff that I suggested that you
>        soften the
>        language about, making it clear that it's stuff you have
>        found useful,
>        without making it a mandatory part of how the URNs are done.
>        Again,
>        you think it's important to keep it as it is, and I think
>        that's very
>        much ill-advised.
> 
>        I don't see how this scheme can be generally useful as a
>        worldwide
>        "lex" URN namespace with the kinds of mandatory handling you
>        specify
>        in this document.

The set of metadata suggested in the urn:lex specifications have been selected after having analyzed the legal citations in different jurisdictions: such metadata are those ones typically used to identify legal documents in different countries. Urn:lex only formalizes such metadata in a structure and a syntax.
On the other hand, if such metadata are used in natural language citations within acts, legal doctrine articles, etc., in our opinion it means that this system is considered valid for identification. Moreover, all the legal digital archives we have analyzed make use of these metadata as primary keys for identifying legal documents.
The main difference we have found is between common law and civil law countries.
In civil law countries, citations are always made of formal parameters (type of the act, date or year, number).
In common law countries, having a lower number of laws, the use of citation including the title of the act (i.e. Human Right Act 1998) is more frequent than the use of the number (Act 1998, chapter 42). In this case using the title in a URN can facilitate document identification from its citation (see above), therefore in the case of the example the urn suggested is "urn:lex:uk:state:act;human.right:1998-11-09;42”.
Therefore the schema proposed, in our opinion, is able to cover both cases and to facilitate the construction of the URNs from citations.
However, such schema has the sufficient flexibility allowing every jurisdiction to adapt it to different needs.


> 
>        If you absolutely insist on leaving it as it is, I will go
>        ahead and
>        ask someone to be a document shepherd so we can process this
>        document
>        and its registration... and the document shepherd will weigh
>        in with
>        his opinion (which I will not influence), so you'll get
>        another view
>        on this.  After that it would go out for last call to get
>        the IETF's
>        and the IESG's view, and see where we are.
> 
>        I'll stress that I think it's valuable to register this and
>        have the
>        details recorded, so I *want* this to go forward.  I'd just
>        rather see
>        it go forward in a form that's flexible enough to actually
>        be useful
>        internationally, while still representing your model for how
>        you'd
>        like the URNs to be formed.  My view is that if you put it
>        that way,
>        then anyone who wants to play your way can do so... and that
>        it's best
>        not to *require* that in order for "urn:lex:" URNs to
>        confirm to this
>        spec.
> 
>        Let me know whether you'd like to continue discussing this,
>        or whether
>        you'd like me to find a shepherd now, and get a new opinion
>        on it.

We do hope to have clarified the issues you raised and that we can find a common agreement as well as the right form in which this spec can be confirmed.

Best regards
   Pierluigi and Enrico

> 
>        Barry

   	

--
---------------------------------------------------------
Enrico Francesconi
ITTIG - CNR
Institute of Legal Information Theory and Techniques
Italian National Research Council

Via de' Barucci 20
50127 Florence
Italy

Tel: +39 055 4399665
Fax: +39 055 4399605
email:francesconi@ittig.cnr.it
---------------------------------------------------------