[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
> 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.
/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.
> 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>
> 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).
> 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.
> 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.
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.
> 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.
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]