Dear Marc, dear ELI group,
that was a fairly disappointing answer to our
compromise proposal. In fact, we felt it was not even a search
of compromise, but a hardening of reciprocal position of
distrust. It would be very sorry if that was the case. We would
have welcomed counterproposals and discussions, rather than a
plain and cold yes/no judgment on individual items.
The proposed compromise was meant exactly to
accommodate a number of other naming conventions, including
country-specific ELI implementations as well as URN:LEX and
others. This was meant that ELI implementations could be used
transparently within Akoma Ntoso documents with a modicum of
effort (ONE ADDITIONAL ELEMENT, that's all).
This shrill reaction seems to mean that you are not
interested in considering the compatibility with Akoma Ntoso,
but only in excusing yourself from finding good reason to look
carefully into it.
In summary:
Thanks for taking up the idea of the
functionally equivalent naming convention. However,
currently the ELI naming convention seems to be only
partially accommodated but subject to AKN conditions as
opposed to being on “ an equal
footing” and this will need to evolve significantly.
We never meant to introduce an equal footing for the ELI naming
convention specifically. We aimed at allowing reasonably
sophisticated naming conventions different from the native Akoma
Ntoso to be used everywhere an URI ref is allowed. Nothing
specific for ELI, but we fully expected that most ELI
Implementations that we are aware of, including UK, EU, FR, and
others, could immediately apply.
Dear John & John,
during the last LegalDocML TC, on June 29th, the group has analyzed your comments and discussed about a possible way to satisfy both your concerns and our need to preserve the consistency of our overall design of the Akoma Ntoso proposal.
In this message we would like to advance to you, informally, the gist of the solution, and once we receive your approval, proceed to actually draft and emit a new version of the documentation for the formal approval procedure.
Briefly, the most relevant and pivotal comment is on the naming convention and on your request to allow on an equal footing other naming conventions than Akoma Ntoso's own one. We understand the request and the underlying need, and we are inclined to accept that as long as we can express a few simple and reasonable requirements.
In brief, we would like to adopt your concept of functionally equivalent naming convention (FENC), specify that only FENCs are acceptable in Akoma Ntoso XML documents, and provide a few reasonable indications of what we mean by functional equivalence.
A functionally equivalent naming convention is defined as follows:
[ELI + OP] Disagree with most of these requirements. Why are they needed? Some of these requirements are highly subjective (when is something memorizable , global etc.)? Who would measure these and decide on the possible compliance as functionally equivalent naming convention?
It may be difficult to follow this, but compliance cannot be
requested nor enforced. Akoma Ntoso does not have guns, and no
institution is emitting licenses allowing one to use Akoma Ntoso
if an only if some requirement is followed.
You can use the Akoma Ntoso XML vocabulary and your own
naming convention in it and nobody will sue you.
The only thing we can do is to provide a series of guidelines
on how to use the language. These guidelines are only meant to
guarantee interoperability of tools and datasets. Adopting only
part of these guidelines means only that you admit that you do
not care very much for interoperability of tools and datasets.
Which you are absolutely free to do, but it is not fully
compliant with LegalDocML OASIS conformance rules that we intend
to provide to the world.
Any naming convention that declares itself to be functionally equivalent, is persistent and well publicly documented must qualify.
1) * recognizable * : a syntactical means exists to recognize the specific syntax used for the URI (e.g., a specific prefix);
[ELI + OP] This would largely be the case for ELI (and ECLI), but why this requirement? Also the /eli/ part is _not_ a mandatory part of the ELI identifier syntax (and the UK doesn't have it…).
No part of ELI is mandatory, not even the eli prefix
itself. In fact, we do not look at ELI, which in our mind does
not even exist for exactly this reason, but to individual ELI
implementations, which usually DO adopt such prefix. In an
interoperable world (which is where we would like to exist),
recognizing that a URI is, in fact, a UK uri as opposed to a
French URI is interesting. This is the reason to require such
a syntactical means.
2) * published * : a sufficiently detailed description of the syntax is publicly available and backed by a recognizable institution;
[ELI + OP] OK (assuming that recognizeable institution = relevant stakeholder). Otherwise, badly defined
please provide a better definition. We did not plan to define it
at all, we only tried to find a common ground. Simply sying Not
enough, try again does not help the cooperation.
3) * FRBR compliant * : A full distinction between distinct intellectual creations , specific intellectual forms , physical embodiments and exemplars of relevant documents must be explicitly supported and aligned with the FRBR conceptualizations. Support for items is not necessary nor requested.
[ELI + OP] Why is this relevant at the identifier level? As it is formulated, it is unclear if ELI complies to this or not
actually ELI conformance rules do not exist. Many individual ELI
implementations, including UK, EU, FR, as far as we are aware
of, do comply.
As to the reason for this: FRBR is FUNDAMENTAL everywhere in
Akoma Ntoso. It is one of the basic building blocks of Akoma
Ntoso. We are NOT going to requiring a good support for FRBR
just because within the ELI group you were not able to reach a
consensus on its meaning.
4) * CEN Metalex compliant * : the seven rules in CEN Metalex requirements (section 6.1 of [1]) must be fully implemented:
To allow for the discovery of IRI identifiers, names must be:
1. Persistent: names at all levels must maintain the same form over time regardless of the political,
archival and technical events happened since their first generation;
[ELI + OP] OK
2. Global: all relevant documents by all relevant bodies must be represented;
[ELI + OP] What does this mean? Documents are globally accessible or the scheme is globally applicable? If the last, why?
What are all relevant bodies ?
As explicitly specified, we are mentioning a third party
document (CEN Metalex, ftp://ftp.cen.eu/CEN/Sectors/List/ICT/CWAs/CWA15710-2010-Metalex2.pdf )
which existed before this naming convention. This document
lists in a very generic form a set of requirements for CEN
Metalex compliancy. The Akoma Ntoso Naming Convention, in the
mind of its proponents, does its best to comply with them.
Functional equivalence, in our mind, means exactly that the
candidate naming convention must have the same consideration
for the CEN Metalex requirements that we had.
The actual answers can and must be found in the CEN Metalex
document, if anywhere. Both questions you raise, nonetheless,
are easy to answer:
1) The scheme must be globally applicable to all documents
to which it claims to apply. Easy.
2) The relevant bodies are all organizations emitting
documents for which the candidate naming convention claims to
apply. Also easy.
3. Memorizable: names should be easy to write down, easy to remember, easy to correct if they were written
down wrongly;
[ELI + OP] In principle OK, though subjective
Ok.
4. Meaningful: names should mean something; It should be possible to make assumption about the kind, freshness
and relevance of a citation by looking only at the document’s name;
[ELI + OP] OK (but what does freshness mean)
Our take: in a versioned document, it should be possible
to make assumption about the actual version you are interested
in.
5. Guessable across levels: references to different levels of the same document must be similar; e.g.,
given a reference to an _expression_ a user should be able to deduce the name of the work;
[ELI + OP] OK
6. Guessable across document classes: references to different instances of the same document type must
be similar; and
[ELI + OP] OK
7. Guessable across document components: references to different components of the same document at the
same level must be similar.
[ELI + OP] OK
4) * active * : at least one working, accessible, available, robust resolver must exist that provides dereferencing of URIs/IRIs according to the specific syntax;
[ELI + OP] No resolver must be required, unless this includes is the general http resolution mechanism
IF the resolution of your identifier can happen through the
general http resolution, THEN you automatically comply. This
is NOT the case for ALL candidate naming convention, so we
felt the need to add this requirement.
5) * equivalent * : at least one working, accessible, available, robust converter must exist that converts URIs/IRIs according to the specific syntax into equivalent URIs/IRIs according to the Akoma Ntoso Naming convention;
[ELI + OP] In this case the Akoma Ntoso Naming convention is the privileged partner and not a choice on an equal footing .
In practical terms, who would maintain such a converter?
Being an Akoma Ntoso document means BOTH using the Akoma
Ntoso XML vocabulary AND being part of a network of document
collections that talk to each other. This is probably NOT a
requirement for ELI, but it is one for Akoma Ntoso.
Interoperability, thus, means that a resolver should be
able to resolve URIs regardless of the naming convention used,
and in particular source documents using internally a naming
convention which is different than the one used by the
document base where the destination document is stored should
be able to access the destination document anyway.
The opposite, i.e., requiring that the author of the source
document KNOWS which naming convention is used in the
destination document collection, hardly seems robust and
interoperable.
6) * evident * : Akoma Ntoso XML documents identifying themselves (in <FRBRUri> and <FRBRThis> elements) using a FENC URI, must also provide equivalent <FRBRalias> elements with the URI ref corresponding to <FRBRThis> according to the Akoma Ntoso Naming Convention, one for each of the first three FRBR levels.
[ELI + OP] Unacceptable. As an effect of this everybody would have to support the Akoma Ntoso naming convention in any case, the only difference being that in this case ELI is the primary schema and Akoma Ntoso the obligatory second one. In this, the Akoma Ntoso naming convention retains a privileged position and is not at all on an equal footing
Equal footing, in our mind, does not mean ignoring each
other. It means actively looking for a compromise situation
where the syntax may differ, but the functionalities stay the
same. Interoperability is the MOST IMPORTANT functional
requirement for being part of the Akoma Ntoso world. You
cannot have interoperability if you do not allow resolver to
access documents using a different naming convention that the
source document uses. This is the only justification for this
requirement.
In practice, this requires that ONE element per FRBR level
(THREE element total) are added to an Akoma Ntoso XML document
to be compliant with this requirement. All links, all
components, all references, all annotations
As said, you can use Akoma Ntoso XML documents with no
legal consequences. Nonetheless, if you want OUR resolvers to
access your documents, you must allow them to discover the
Akoma Ntoso equivalent URIs.
Any Naming Convention that complies with these requirements is termed a * functionally-equivalent Naming Convention * and its URIs can be used in any situation where Akoma Ntoso URIs/IRIs are appropriate.
Finally we resist at allowing custom syntaxes for inner-document ids in eId and wId, because
a) inner document identifiers are a reflection of the overall XML structure, which is still Akoma Ntoso, and not of the document-level URI syntax adopted,
b) allowing multiple syntaxes for the same attributes would create havocs in any decent resolver and editor trying to deal with documents coming from different sources, and
c) a good destination for custom ids already exists, attribute guid, that has exactly the stated purpose and allows custom ids without polluting the id space expressed by eIds and wIds.
[ELI + OP] Using the prescribed syntax must not be requirement for compliance to Akoma Ntoso nor for the use of the eId / wId attributes. If desired, an additional compliance level could be defined for those users of Akoma Ntoso who want to use a resolver. The use of a resolver must not be forced on users of the schema who have no interest in using this functionality. So, usage of a predefined inner identifier structure should be an option (CAN), not an obligation (MUST), except perhaps in said specific compliance level
This is exactly the case it is now. You can use GUID
attributes at the first level of compliancy. Using eId and wId
is only at the second level of compliancy. but IF you use eId
and wId, we insist on you adopting the syntax provided for
these attributes. This guarantees that the resolution can take
place with no ill effects and without misunderstandings,
especially in the case of renumbered fragments in a versioned
context.
Regards,
Fabio Vitali & Monica
Il 22/07/2016 12:32, KUSTER Marc (OP) ha scritto:
Dear
Monica, Fabio,
Thanks
for taking up the idea of the functionally equivalent naming
convention. However, currently the ELI naming convention
seems to be only partially accommodated but subject to AKN
conditions as opposed to being on “ an equal footing”
and
this will need to evolve significantly.
Please
find here the ELI TF's and OP's reactions. I am, of course,
at your disposal for further discussions.
Best
regards
Marc
From: monica.palmirani [ mailto:
monica.palmirani@unibo.it ]
Sent: 20 July 2016 11:44
To: John Dann; John Sheridan
Cc: Fabio Vitali; Catherine Tabone; 'Søren
Broberg Nielsen (957sbn)'; Patrice Platel; 'Matthews,
Gerry'; Jean-Michel THIVEL; 'Nina Koch (957nko)';
'Hietanen Aki (OM) (
aki.hietanen@om.fi )'; SCIARRINO Valeria (OP); KOENIG Kurt
(OP); MALAGON Carmen (OP); SCHMITZ Peter (OP);
PAPPALARDO Roberto (OP); KARDAMI Maria (OP); BAGOLA
Holger (OP)
Subject: Re: [legaldocml] Public Comments
Dear John & John,
we were wondering if you have received any comment about
our proposal for the modification to the compliance with
the Akoma Ntoso naming convention.
Tomorrow we will have our LegalDocML TC meeting and it
would be nice to have some inputs on this issue.
We intend to speed up the standardization process soon,
especially since Monica was elected in the OASIS Board of
Directors.
All the best,
Monica and Fabio
Il 12/07/2016 13:57, John Dann ha scritto:
Hi Monica,
Thanks for taking into
consideration our comments.
I forward your
proposition to the ELI TF, as I sent the comments on
behalf of all, and also the OPUE, whose comments we all
supported, so they can also react.
I am sure we will find
a suitable flexible solution.
John
From: monica.palmirani [ mailto:
monica.palmirani@unibo.it ]
Sent: Tuesday, July 12, 2016 12:04 PM
To: John Dann <
John.Dann@scl.etat.lu> ; 'Sheridan, John'
<
jsheridan@nationalarchives.gsi.gov.uk>
Cc: Fabio Vitali <
fabio@CS.UniBO.IT>
Subject: [legaldocml] Public Comments
Dear John & John,
during the last LegalDocML TC, on June 29th, the group has analyzed your comments and discussed about a possible way to satisfy both your concerns and our need to preserve the consistency of our overall design of the Akoma Ntoso proposal.
In this message we would like to advance to you, informally, the gist of the solution, and once we receive your approval, proceed to actually draft and emit a new version of the documentation for the formal approval procedure.
Briefly, the most relevant and pivotal comment is on the naming convention and on your request to allow on an equal footing other naming conventions than Akoma Ntoso's own one. We understand the request and the underlying need, and we are inclined to accept that as long as we can express a few simple and reasonable requirements.
In brief, we would like to adopt your concept of functionally equivalent naming convention (FENC), specify that only FENCs are acceptable in Akoma Ntoso XML documents, and provide a few reasonable indications of what we mean by functional equivalence.
A functionally equivalent naming convention is defined as follows:
[ELI + OP] Disagree with most of these requirements. Why are they needed? Some of these requirements are highly subjective (when is something memorizable , global etc.)? Who would measure these and decide on the possible compliance as functionally equivalent naming convention?
Any naming convention that declares itself to be functionally equivalent, is persistent and well publicly documented must qualify.
1) * recognizable * : a syntactical means exists to recognize the specific syntax used for the URI (e.g., a specific prefix);
[ELI + OP] This would largely be the case for ELI (and ECLI), but why this requirement? Also the /eli/ part is _not_ a mandatory part of the ELI identifier syntax (and the UK doesn't have it…).
2) * published * : a sufficiently detailed description of the syntax is publicly available and backed by a recognizable institution;
[ELI + OP] OK (assuming that recognizeable institution = relevant stakeholder). Otherwise, badly defined
3) * FRBR compliant * : A full distinction between distinct intellectual creations , specific intellectual forms , physical embodiments and exemplars of relevant documents must be explicitly supported and aligned with the FRBR conceptualizations. Support for items is not necessary nor requested.
[ELI + OP] Why is this relevant at the identifier level? As it is formulated, it is unclear if ELI complies to this or not
4) * CEN Metalex compliant * : the seven rules in CEN Metalex requirements (section 6.1 of [1]) must be fully implemented:
To allow for the discovery of IRI identifiers, names must be:
1. Persistent: names at all levels must maintain the same form over time regardless of the political,
archival and technical events happened since their first generation;
[ELI + OP] OK
2. Global: all relevant documents by all relevant bodies must be represented;
[ELI + OP] What does this mean? Documents are globally accessible or the scheme is globally applicable? If the last, why?
What are all relevant bodies ?
3. Memorizable: names should be easy to write down, easy to remember, easy to correct if they were written
down wrongly;
[ELI + OP] In principle OK, though subjective
4. Meaningful: names should mean something; It should be possible to make assumption about the kind, freshness
and relevance of a citation by looking only at the document’s name;
[ELI + OP] OK (but what does freshness mean)
5. Guessable across levels: references to different levels of the same document must be similar; e.g.,
given a reference to an _expression_ a user should be able to deduce the name of the work;
[ELI + OP] OK
6. Guessable across document classes: references to different instances of the same document type must
be similar; and
[ELI + OP] OK
7. Guessable across document components: references to different components of the same document at the
same level must be similar.
[ELI + OP] OK
4) * active * : at least one working, accessible, available, robust resolver must exist that provides dereferencing of URIs/IRIs according to the specific syntax;
[ELI + OP] No resolver must be required, unless this includes is the general http resolution mechanism
5) * equivalent * : at least one working, accessible, available, robust converter must exist that converts URIs/IRIs according to the specific syntax into equivalent URIs/IRIs according to the Akoma Ntoso Naming convention;
[ELI + OP] In this case the Akoma Ntoso Naming convention is the privileged partner and not a choice on an equal footing .
In practical terms, who would maintain such a converter?
6) * evident * : Akoma Ntoso XML documents identifying themselves (in <FRBRUri> and <FRBRThis> elements) using a FENC URI, must also provide equivalent <FRBRalias> elements with the URI ref corresponding to <FRBRThis> according to the Akoma Ntoso Naming Convention, one for each of the first three FRBR levels.
[ELI + OP] Unacceptable. As an effect of this everybody would have to support the Akoma Ntoso naming convention in any case, the only difference being that in this case ELI is the primary schema and Akoma Ntoso the obligatory second one. In this, the Akoma Ntoso naming convention retains a privileged position and is not at all on an equal footing
Any Naming Convention that complies with these requirements is termed a * functionally-equivalent Naming Convention * and its URIs can be used in any situation where Akoma Ntoso URIs/IRIs are appropriate.
Finally we resist at allowing custom syntaxes for inner-document ids in eId and wId, because
a) inner document identifiers are a reflection of the overall XML structure, which is still Akoma Ntoso, and not of the document-level URI syntax adopted,
b) allowing multiple syntaxes for the same attributes would create havocs in any decent resolver and editor trying to deal with documents coming from different sources, and
c) a good destination for custom ids already exists, attribute guid, that has exactly the stated purpose and allows custom ids without polluting the id space expressed by eIds and wIds.
[ELI + OP] Using the prescribed syntax must not be requirement for compliance to Akoma Ntoso nor for the use of the eId / wId attributes. If desired, an additional compliance level could be defined for those users of Akoma Ntoso who want to use a resolver. The use of a resolver must not be forced on users of the schema who have no interest in using this functionality. So, usage of a predefined inner identifier structure should be an option (CAN), not an obligation (MUST), except perhaps in said specific compliance level
[1] ftp://ftp.cen.eu/CEN/Sectors/List/ICT/CWAs/CWA15710-2010-Metalex2.pdf
We plan to work on a new draft including this kind of flexibility, and would appreciate your opinion within the next week.
Thank you for your comments and opinions on this.
Monica and Fabio
Il 21/06/2016 08:48, John Dann ha scritto:
Dear members of
the LegalDocumentML
As Chair of the
ELI Task Force, and on behalf of
·
Denmark
·
Finland
·
Ireland
·
Luxembourg
·
Publications
Office of the European Union
(comments also sent individually)
·
United-Kingdom
(comments also sent individually)
·
France
we would like to
send the following comments.
Constructing a
universal naming convention, given the differences in
national legal systems, is very complex and does not
cover all national legislation cases and especially
hinder existing naming conventions.
In line with the
principle of proportionality and the principle of
decentralization, each country and company should
continue to operate its own national Official Journals,
Legal Gazettes or legal databases in the way they
prefer. We should therefore carefully consider not to
impose a naming convention in order to respect the legal
and constitutional differences between countries, and
authorize on equal footing other naming conventions,
e.g. URN-Lex, ECLI, ELI etc.
This flexibility
would help the implementation of the revised version of
AKN.
We therefore fully
support the comments of the Office of Publications of
the EU sent earlier by email.
Best
regards,
John
John
Dann
Directeur
LE GOUVERNEMENT DU GRAND-DUCHÉ DE LUXEMBOURG
Ministère
d'État
Service
central de législation
43, bd
Roosevelt .
L-2450 Luxembourg
Tél.
(+352) 247-82961 . Fax (+352) 46 74 58
E-mail :
john.dann@scl.etat.lu www.legilux.public.lu --
===================================
Associate professor of Legal Informatics
School of Law
Alma Mater Studiorum Università di Bologna
C.I.R.S.F.I.D.
http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3
I - 40121 BOLOGNA (ITALY)
Tel +39 051 277217
Fax +39 051 260782
E-mail
monica.palmirani@unibo.it ====================================
--
===================================
Associate professor of Legal Informatics
School of Law
Alma Mater Studiorum Università di Bologna
C.I.R.S.F.I.D.
http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3
I - 40121 BOLOGNA (ITALY)
Tel +39 051 277217
Fax +39 051 260782
E-mail
monica.palmirani@unibo.it ====================================
--
===================================
Associate professor of Legal Informatics
School of Law
Alma Mater Studiorum Università di Bologna
C.I.R.S.F.I.D.
http://www.cirsfid.unibo.it/ Palazzo Dal Monte Gaudenzi - Via Galliera, 3
I - 40121 BOLOGNA (ITALY)
Tel +39 051 277217
Fax +39 051 260782
E-mail
monica.palmirani@unibo.it ====================================