Enrico,
On 9/15/17 12:03 PM, Enrico Francesconi wrote:
Dear Paul and Alexey,
thanks for your remarks. We are pleased to work with you to fix all the
issues still remaining in the current urn:lex version.
As regards the quoted issue on names or queries, the urn:lex draft actually
talks about names. As pointed out by Alexey, any reference to queries is meant
to clarify the principles of the resolution process for urn:lex, moreover the
section “resolution” is expected in the draft template.
As regards Paul’s remarks on the possibility to arrive at different forms of
urn:lex starting from document metadata, this is actually meant to facilitate
interoperability. A typical example is the possibility to create equivalent
urn:lex names in different languages. Moreover, the addressed flexibility is
also meant to cope with promoting interoperability when, for example, it is
necessary to link legal resources from incomplete textual citations. In this
case the suggested behavior of the resolution system can facilitate the
discovery of the target resource.
I still have trouble understanding this except as a form of query.
Let me try to explain. I'm drawing a distinction between two classes of
users for these URNs:
1) The authority who is formally assigning lex URNs to documents. The
authority can choose which of the various optional parts of the urn are
applicable to a given document. A question is whether the goal of the
authority should be to choose the "best" name for the document, or
should attempt to assign every possible name that any reasonable person
might guess to be the name of the document.
2) Someone interested in referencing the document. Some people may only
be interested in obtaining a name to use to point at the document, but
that always implies an assumption that someone will want to retrieve the
document using that name, so I'll assume that the goal here is to
retrieve the document.
2a) One possibility is that this person is given the name by someone who
obtained it directly from (1), so that it is known to refer to a document.
2b) This person is aware of some metatdata about the document, and
attempts to independently construct a URN identifying the document from
this metatdata. (I take this to be an important use case from the point
of view of the draft.) In this case, this person may get lucky and come
up with an identical URN to one assigned by (1). On the other hand,
given the number of possible optional fields, he may not be so lucky.
His chances are better if (1) attempted to define every imaginable
permutation, but that is a lot of work and I doubt one can count on this.
You imply an environment where such an undefined URN can be resolved by
a smart resolver. But in this case the input URN is not actually a URN
to the document in question - it is a query for some document. And that
is my point.
ISTM that the definition of the URN should be concerned with (1) and
(2a). But as I read the draft it certainly feels to me that it has a
heavy concern for (2b).
Thanks,
Paul
For the other issues raised, we will analyse them in details and get back to
you soon.
Best regards
Pierluigi and Enrico
---------------------------------------------------------
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-4399-665
Fax: +39-055-4399-605
email: [email protected]
---------------------------------------------------------
On 14 set 2017, at 19:04, Paul Kyzivat <[email protected]> wrote:
Hi Alexey,
On 9/14/17 12:25 PM, Alexey Melnikov wrote:
Hi Paul,
I am not an author, but let me disagree with one of your reported issues:
On 14 Sep 2017, at 16:45, Paul Kyzivat <[email protected]> wrote:
(2) MAJOR: Name or query?
A URN is by definition a *name*. Some parts of this document do focus on the
lex URN as a name. But the document also proposes using the lex URN as a
*query*. The following text from section 2 highlights this:
"To cope with possible incomplete or inaccurate uniform names,
the implementation of a catalogue, based on a relational-
database, able to associate a URN to related URLs, is
suggested, as it will lead to a higher flexibility in the
resolution process. A resolver can provide names normalization,
completion of inaccurate or incomplete names, and finally their
resolution in network locations (see Section 8.2 and 8.3 for
characteristics and behaviour of a catalogue for resolution)."
This behavior is inconsistent with the intent of URNs.
I think the document is only talking about names. Association with URLs is the
result of URN resolution process, which is a part of URN architecture. If this
is not clear, I think it should be clarified (if authors agree that this is the
intent).
I found it very difficult to sort out what was fundamental and normative
regarding the URN from the parts that are aspirational about resolution and
use. Hence my recommendation that this document be split. Such a split may well
resolve this issue for me.
I only pointed to this one place, but there are other places that express an intention
that it be possible to "guess" or recreate a lex URN based on metadata about
the document. That only makes sense if then intent is that the resulting URN be
resolvable to the document. But there are so many elements to chosen and used or not for
a given document that reasonable people are likely to arrive at different forms of the
URN. That ties in to the quote above.
Thanks,
Paul
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
