[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legaldocml] Public Comments
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.
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.
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.
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.
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.
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.
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.
Our take: in a versioned document, it should be possible to make assumption about the actual version you are interested in.
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.
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.
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.
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.
Fabio Vitali & Monica
Il 22/07/2016 12:32, KUSTER Marc (OP) ha scritto:
-- =================================== 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 email@example.com ====================================