RE:[legaldocml] [legaldocml] URGENT: Summary of Naming Convention

Hello Fabio,

My comment in blue hereafter.

Please note that the current use of the separator is ok for me so I don't make more comment on it.

Kind regards

Véronique

Véronique Parisse
AUBAY Luxembourg
Orco House
38, Parc d’activités - L-8308 Capellen
Standard : +352 2992501
Fax : +352 299251
www.aubay.com

________________________________________
De : Fabio Vitali [fvitali@gmail.com]
Envoyé : vendredi 20 novembre 2015 10:32
À : PARISSE, Véronique
Cc : monica.palmirani; legaldocml@lists.oasis-open.org
Objet : Re: [legaldocml] [legaldocml] URGENT: Summary of Naming Convention - D3

Dear Veronique, all:

On 12/nov/2015, at 10:47, "PARISSE, Véronique" <V.PARISSE@aubay.lu> wrote:

> Hello Monica and everybody
>
> see my comment hereafter
>
> But before, I have something that I want to add in the specification (but we don't have the time to discussed it yesterday) :
>
> Akoma Ntoso documents are divided into containers : <preface>, <preamble>, the main content of the document, <conclusions> and <attachments>.
>
> The <preface>, <preamble> <attachments> and <conclusions> elements are available in all types of documents.
> But the "main content of a document" is marked by different kind of elements, depending on the type of the akoma ntoso documents (the content are differently structured). For single document (so, not a document collection), we have: <body>, <mainBody>, <amendmentBody>, <debateBody>, <judgmentBody>.
>
> I propose that, for all these elements (<body>, <mainBody>, <amendmentBody>, <debateBody>, <judgmentBody>), the Akn naming convention provide a common prefix (for example, « body »), so that we can use it for selecting the whole body of an act
> ([http://www.authority.org]/akn/sl/act/2004-02-13/2~body

Yes, I agree, but I believe that these elements already can be identified using their id, there is no need to specify it separately. Just use their id.

Yes, I agree, and I propose to use the prefix "body" to compose the eId of <body>, <mainBody>, <amendmentBody>, <debateBody>, <judgmentBody>.

> For the rest, see my comments below (in blue)
>
>
> Kind regards
>
> Véronique
>
> Véronique Parisse
> AUBAY Luxembourg
> Orco House
> 38, Parc d’activités - L-8308 Capellen
> Standard : +352 2992501
> Fax : +352 299251
> www.aubay.com
>
> ________________________________________
> De : legaldocml@lists.oasis-open.org [legaldocml@lists.oasis-open.org] de la part de monica.palmirani [monica.palmirani@unibo.it]
> Envoyé : jeudi 12 novembre 2015 8:56
> À : legaldocml@lists.oasis-open.org
> Objet : [legaldocml] URGENT: Summary of Naming Convention - D3
>
>> Dear all,
>>
>> thanks for the yesterday TC meeting.
>>
>> I would like to summarize the decision taken and to consolidate the
>> pending issues in order to close the D3 remotely before the next TC
>> meeting scheduled Nov. 25th.
>>
>> We agree on this syntax where (see the Adobe Connect minutes below):
>>
>> WORK
>> /akn/eu/act/2015/123~art_12 - simple situation
>> /akn/eu/act/2015/123!main/~art_12 - main is optional
> also, I don't think that the / is necessary before the ~
> => /akn/eu/act/2015/123!main~art_12

Correct. There should be NO / before ~

>> /akn/eu/act/2015/123!main/annex_1/annex_5~art_12 - complex situation
> or
> /akn/eu/act/2015/123!annex_1/annex_5~art_12 (main optional)

Correct.

>> _expression_
>> /akn/eu/act/2015/123/fr@2015~art_12 - simple situation
>> /akn/eu/act/2015/123/fr@2015!main/~art_12 - main is optional
> /akn/eu/act/2015/123/fr@2015!main~art_12 - main is optional

Correct.

>> /akn/eu/act/2015/123/fr@2015!main/annex_1/annex_5~art_12 - complex
>> situation with components
> or
> /akn/eu/act/2015/123/fr@2015!annex_1/annex_5~art_12 (main is optional)

Correct.

>> /akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12 - complex
>> situation with components and optional metadata of the _expression_ (eupub)
> also
> /akn/eu/bill/2015/123/fr@ver_final!annex_1/annex_5~art_12 (version "final" of the bill for example when a proposal for an act is adopted by the Commission)

Please do NOT use ver_ before the name of the version. It is NOT necessary.

I think that it is necessary because at the same location, you can have the stage, that it also a string. So it is impossible to differentiate the version from the stage and. The "ver_" add a better lisibility on the reference, so please, I would like to maintain it.

/akn/eu/bill/2015/123/fr@final!annex_1/annex_5~art_12?

>> MANIFESTATION
>> /akn/eu/act/2015/123/fr@2015~art_12.xml - simple situation
>> /akn/eu/act/2015/123/fr@2015!main/~art_12.xml - main is optional
> /akn/eu/act/2015/123/fr@2015!main~art_12.xml - main is optional

Correct

>> /akn/eu/act/2015/123/fr@2015!main/annex_1/annex_5~art_12.xml - complex
>> situation with components
> or
> /akn/eu/act/2015/123/fr@2015!annex_1/annex_5~art_12.xml (main optional)

Yes.

>> /akn/eu/act/2015/123/fr@2015/eupub!main/annex_1/annex_5~art_12.xml-
>> complex situation with components and optional metadata of the
>> _expression_ (eupub)
> /akn/eu/act/2015/123/fr@2015/eupub!annex_1/annex_5~art_12.xml- (main optional)

Yes.

> Another point
> For the fragment/portion, we explain the mapping between the structure and the name used in the reference ("art" for article, "chp" for chapter, name of the element in general, how is make the numbering, ...)

The fragment part MUST be the id of the element. Exactly the id.

The eId is depending on XML constraint (so, for example, whether you put or not the content of the subdocument. That is an implementation, so a Manifestation information). The author of the reference has not necesseraly the knowledge of this information
He build the reference on the logical structure.

For example,
<documentCollection>
<collectionBody>
    <act>
    </act>
    <doc>
    </doc>
</collectionBody>
</documentCollection>
The eId inside the act and the doc must be unique inside the documentCollection;

that is not the case with the following manifestation :
<documentCollection>
    <act>
    </act>
    <doc>
    </doc>
</collectionBody>
</documentCollection>
<component>
   <act>
   </act>
</component>
<component>
   <doc>
   </doc>
</component>

When you make a reference to a work or an _expression_, it is the job of the resolver to find the correct manifestation fragment. This can include, eventually, a mapping of the fragment/portion because the author of the legal reference has nothing to do we the xml stuff.

> For the component, we need also to specify where we find the information (which part of metadata correspond to the name of the component (annex, appendix, schedule, ... : is it the name attribute of the akn document element ? is it the metadata subType, other ?),

We already have this information: it is the content of the FRBRthis element

<xsd:element name="FRBRthis" type="valueType">
<xsd:annotation><xsd:documentation>
<type>Element</type>
<name>FRBRthis</name>
<comment>The element FRBRthis is the metadata property containing the IRI of the specific component of the document in the respective level of the FRBR hierarchy</comment>
</xsd:documentation></xsd:annotation>
</xsd:element>

Yes, but again, there is a need to specify how the IRI of a work that is annexed to another work is specified : for the main document, the specification is "the element name, a subtype, the author, ..."
And for the uri of a document that is annexed ?

If we do the same algorithm for the IRI of a document annexed, it will never be taken into account for the reference as we reference it relatively to the main document as something that is annexed.
(<iri-main-document>![fragment-name]_1)

- regarding the ![fragment-name]_1 part of the reference, where is the corresponding information in the metadata of the document annexed : how to know if [fragment-name] is "fragment" or "appendice" or ... ?
(because the reference can be <iri-main-document>!annex_1 or <iri-main-document>!appendix_1 or <iri-main-document>!schedule_1)

for me, "annex"-"appendix"-"schedule" can be
- the attribute "name" of the document element or
- the attribute type (or subtype) in the identification/work part of the metadata.

But I think that it is important to specify it.

> We need also to explain how to design a component that has no component name (for example, documents that are attached and not included, like the agreement attached to a decision act).

Whether a component is physically attached or not to its main, is a Manifestation-level aspect of the document, not a Work-level or _expression_-level characteristic: at the Work or _expression_ level, the secondary component IS ALWAYS attached to the primary.

Therefore this information is only relevant for Manifestation-level references (i.e., src attributes) and not for Work-level and _expression_-level references (i.e., href attributes).

So, we reference an agreement that is attached to the act that adopts it, as "<iri-adoptionAct>!annex_1" and the annex 1 of the agreement as "<iri-adoptionAct>!annex_1/annex_1" ?

> Finally, we need also to provide some examples for documentCollection (where you have two type of component : one inside the main body and one inside the attachment).

Similarly, this problem is only relevant at the Manifestation level. This means that it is the business of the URI resolver to identify the physical entity where the requested component is placed if a Work-level or _expression_-level reference is used.

Then I don't understand the meaning of the identification/FRBRwork and identification/FRBRexpression part of metadata and why the spec says that the IRI of the manifestation is build on the IRI of the _expression_ that is build on the IRI of the work

> PENDING ISSUES sub-fragments:
>
> To clarify my position
>
> I think that it is dommage that the "/" separator is used for two type of information in the structure of the IRI
> - separate different metadata (for example, in "eu/act", the slash separate different type of information ( the country and the type of the act).
> - mark the hierarchy (for example, annex_1/appendix_3/attachment_2 ...)

To clarify MY position: we need separators. The main separator is the slash "/", but in order to allow optional parameters to appear in the middle of the URI without ambiguity, we need to place different separators strategically here and there. Currently we use FOUR other separators: "@" (or ":") for the version/variant/view, "." for the format, and recently "~" for the fragment and (unnecessarily, but alas...) "!" for the component. We do not need more than these, I think.

> On another point, we have another syntax for marking a hierarchy : "__" So why can we not do this :
> /akn/eu/act/2015/123/fr@2015/eupub!annex_1__annex_5~art_12__para_1.xml

This is a different aspect: the content of the fragment part of the URI (the thing after the "~") MUST BE EXACTLY LIKE the id of the element specified. Not an interpretation, not a conversion: exactly the id. This is important.

This is impossible when you make reference relative to a work or an _expression_, I think. The exact content of id is purely related to xml constraint. You cannot build a legal reference with taken into account the XML unicity, because a reference to a work or an _expression_ can in fact reference different manifestation, depending on the time it is activated.
So it is a business of the resolver to make the mapping between the fragment specification of the reference and the eId value in some manifestation(s)

So, separately, we decided to use "__" to mark the separation between context and element name of ids because all other characters were possible in element numbers. Please note that technically, "__" is a separation between context and element name, not a hierarchical structure: the hierarchicality of the context is a consequence of the fact that some ids are built by juxtaposing the ids of their containing elements to create a full context. "art_12" is a full and complete id without its context, since "tome_3__book_5__chp_1__art_12" is clearly NOT necessary.

> Alternatively, if you consider that "__" is not enough esthetic, then we can continue to use the "/" meltingpot, but EVERYWHERE, so
> /akn/eu/act/2015/123/fr@2015/eupub!annex_1/annex_5~art_12/para_23/list_2/point_9.xml#art_12/para_23/list_2/point_9

As I said, I believe that the id of the element MUST BE TAKEN AS IT IS, without considerations as its hierarchical level or anything. The id is a single STRING, not a sequence of parts separated by "__" separators.

I agree on the the current syntax

> Consider that it is the syntax of referencing but it can never be considered as the "exact value" of the eId attribute, because, as it was clearly explained yesterday, the "eId" value is completely dependant on the organisation of the manifestation and whether you physically group or not the component manifestations in the same xml document (in fact, eId is constained by the XML syntax and rules on the unicity of the attribute) but of course, the author of a citation has not to take this into account.
> So, the naming convention of the reference is more generic and cannot be build on the real organisation of the manifestations.
>
> Much more, the naming convention of the reference must, for my point of view, be considered as a generic syntax allowing to find information in documents independently of its format: I can use the akn naming convention to reference fragment/portion in pdf or word document (in fact, I do it for referencing portion/fragment in a Formex document that has a completely different syntax for the naming of the text structure. So, I establish a mapping between these two syntaxes).

I disagree. As soon as we enter into the inner-document referencing, then necessarily the organization and structure of the manifestation must come into play. We can (and might) assume that, if you are using an Akoma Ntoso naming convention syntax for the document, then you must assume to use the same syntax for the fragments, which are based on the assumption that you are using the XML vocabulary for the content. You may NOT use the XML syntax, but the ids you are using implicitly assume that the inner document references are based on what the XML syntax of the document would be.

It is impossible to specify a work or an _expression_ reference that take into account the Manifestation structure : a legal reference dont specify a specific manifestation and so, does not know how the manifestation is done.
A reference must also remain valid even if there is a redefinition of the structure of the manifestations.
This is the reason to transmit the fragment/portion to the server. This is the job of the resolver to make the mapping between the specification of the fragment / portion in a reference and the eId of the corresponding element, taken into account the structure of the Manifestation selected.

> So, choice between the / or the __ (my preference is for the "__") but please, adopt it everywhere a hierarchy is expressed (for component hierarchy also),
> Of course, we need to align the syntax of the eId accordingly (hoping that "/" is allowed for eId ;-) ).

We MUST use "__" whenever the ids use "__" EXACTLY BECAUSE the ids use "__" . In other places we must use other separators, "/" whenever possible and "@", "~", "!" and "." where appropriate.

Ciao

Fabio

--

Fabio Vitali The sage and the fool
Dept. of Informatics go to their graves
Univ. of Bologna ITALY alike in this respect:
phone: +39 051 2094872 both believe the sage to be a fool.
e-mail: fabio@cs.unibo.it Where, then, may wisdom be found?
http://vitali.web.cs.unibo.it/ Qi, "Neither Yes nor No", The codeless code

legaldocml message