5 Basic Akoma Ntoso building blocks (Nonnormative)

5.1 An introduction to document types

As we have seen, the seven document types differ mainly in the way the “main content” of the document is structured. In the table below we describe the main characteristics of the structure of the “main content” part of the different document types.

Document type	Akoma Ntoso main element	Description
bill/act	<body>	The body is used for bills and acts and presents an explicit hierarchy of parts each part of which can be identified with a meaningful name (such as section, tome, etc.) and possibly provided with numbers and various types of headings. Akoma Ntoso provides a large number of names for these parts (title, book, tome, part, chapter, section, paragraph, article, clause, division, level, list, subtitle, subpart, subchapter, subsection, subparagraph, subclause, sublist, point, indent, alinea). Some legislative traditions may use names which may not match the part names specified above – for such use cases a generic container called an hcontainer' (i.e. hierarchical container) is provided which can be identified with a name and supports the same hierarchical structures provided by the named parts.
debate record	<debateBody>	The debateBody contain a hierarchy of subdivisions at the bottom of which can be specified blocks of text or individual utterances of individuals participating in the debate, as well as comments from the drafters. Subdivisions are explicitly listed (administrationOfOath, declarationOfVote, communication, petitions, papers, noticesOfMotion, questions, address, proceduralMotions, pointOfOrder, adjournment, rollCall, prayers, oralStatements, writtenStatements, personalStatements, ministerialStatements, resolutions, nationalInterest), plus a generic element debateSection for all unnamed subdivisions and all those subdivisions whose appropriate name is not listed here. Within debateSection, individual text structures can be marked up with one of eight containers, speechGroup, speech, question, answer, scene, narrative, summary, and other. It is worth noting that those containers that refer to actual utterances (i.e. speech, question, answer) have a peculiar structure which imposes the identification of a speaker through the from element (which is displayed on the print version of the document) plus references to individuals and roles expressed through the by, as, and to attributes, specifying, respectively, the id of the individual uttering the speech, the role (if any) the individual is assuming when uttering the speech, and the addressee (if any) of the speech. For this reason, these elements are enriched with special attributes: by: who is the speaker; as: the role of the speaker; to: who is the addresser of the speech. <question by="#Smith" to="#deputyPresident" as="#member">
judgment	<judgmentBody>	The judgmentBody contains four sections (introduction, background, motivation, and decision - the standard does not mandate an order), that need to be present one or more times as needed. These sections may contain basically any kind of substructure (containers, blocks, hierarchical elements, etc.).
document, debateReport, statement	<mainBody>	The mainContent element of an open structure is a generic collector of all preceding structural elements in any order and number. This kind of open structure is meant for collecting and marking up those document types whose structure is too varied, or too different from the norm, or not well standardized, or too full of exceptions to be worth describing explicitly.
collections	<collectionBody>	The collectionContent is used for including multiple documents that maintain their autonomy, but can be managed as a unique container. It is thus possible to compose an issue of the Official Gazette as a combination collection of several acts. The same for the Amendment List document composed of a set of separate amendment documents. This structure permits two different approaches: 1 to include directly in the collectionBody element the other documents (bill, doc, debate, act, etc.); 2 to include in the collectionBody element references to the documents using the element <documentRef>. The documentRef includes the attribute href that specifies the URI/IRI of the document. It is possible to describe the cited document in the same file inside of the element <component> or to link an external file using the URI/IRI convention. <documentRef eId="dRef_1" href="#bill" showAs="bill"/> It is possible to associate with each sub document a num and a heading. A <documentRef> is a work-level or expression-level reference to a document that has independent existence, namely that it has a work-level or expression-level identifier, and that it is hosted within a containing document.
amendment	<amendmentBody>	This element includes the body of the amendment that is composed of several important parts: amendmentHeading, amendmentContent, amendmentReference, and amendmentJustification.
portion	<portionBody>	This element permits including a portion of any other document. It is possible to refer to the portion inside of another Akoma Ntoso document using the <componentRef> element.

5.2 The basic structure of Akoma Ntoso XML resources

The document structures of Akoma Ntoso (bill/act, debate, debateReport, judgment, amendment, statement, and document) have the same external organization: a place for metadata elements, a cover page, a place for the introductory matters (e.g. preface/ preamble or header for Judgments), the main content part of the document (which is different in the four structures), a place for conclusive remarks, and lastly, a place for listing the attachments if any. The table below describes briefly the “text sequence” and their parts:

Text sequence	Akoma Ntoso <elements>	Description
cover page	<coverPage>	Information intrinsic to the document such as: name of the publisher, serial number, issuing authority, number of committee, number of legislature, number of the session, etc.
information on the document	<metadata>	Information on the document that qualifies and classifies the text as a whole or each fragment. An example is the keywords for assigning the topic to the document (e.g. privacy, commercial law, etc.)
introductory text	<preface> / <header>	Information related to the title of the document, the proponent authority, the identification numbers, the date of approval. In other word, the essential information for citing the document. It can also contain the long title and a table of contents.
justificatory text	<preamble> that can include <formula> <recitals> and <citations>	The introductory part of a document stating its purpose, aims, and justification. Introduction, motivations, purposes, legal basis of a document, in formula, recitals and citations. Formula describes the enacting sentences that, in many legal traditions, are regular and fixed linguistic expressions. Recitals block includes motivations and justifications of the legal document. Citation blocks include references to other legal documents that are fundamental to the current text: legal basis, preparatory acts as well as the legislative procedures.
main content	<body>: for bill/act <debateBody>: for debate record <judgmentBody>: for judgments <mainBody>: for open structure and for the debate report <amendmentBody>: for the amendment <collectionBody>: for the collection documents <portionBody>: for the portion of document	The main part of the document, the part that is prescriptive or states a declaration (enacting terms). The text is characterized by a structural complexity that can vary depending on the document’s typology and purpose.
conclusions	<conclusions>	Part in which we may find closing formulas date and signature.
authorial notes	<authorialNote>	Part dedicated to including the authorial notes added by the author of the document.
attachments	<attachments>	Documents can also include attachments with the precise functionality of completing and integrating the information of the main text. Attachments can be an annex (informative or technical data which, for practical reasons, does not appear in the body). Attachments or others types of Components can also be another act or international agreement that is approved by this act. Those documents are not annexed but attached to the act that approves them. Those documents are not annexed but attached to the act that approves them.
components	<components>	Document can also include components that are independent works, expressions, or manifestations. Each component can have a num and/or a heading before the document.

5.3 An introduction to generic elements

All elements in this schema fall under one of six content models: hierarchical container, container, subFlow, block, inline and markerBesides named elements, the schema also provides for a generic element for each of them that can be used for markup and that fits the content models but can be specified by a precise name that is not used in this schema. The 'name' attribute must be used for naming the element. When required, the attribute name gives a name to the element.

hcontainer	The hcontainer element is a generic element for a hierarchical container. It can be placed in a hierarchy instead of any of the other hierarchical containers. The attribute name is required and gives a name to the element.
container	The container element is a generic element for a container. It includes elements belonging to the block pattern.
subFlow	The subFlow element is a generic element for a sub-flow. It includes elements belonging to the hcontainer, container and/or block patterns.
block	The block element is a generic element for a container. It can be placed in a container instead of any of the other blocks. The attribute name is required and gives a name to the element.
blockContainer	The element blockContainer is used as a container of many individual block elements in a block context.
tblock	The tblock element (titled block) is used to specify a container for blocks introduced by heading elements, similarly to a hierarchical structure
inline	The inline element is a generic element for an inline. It can be placed inside a block instead of any of the other inlines. The attribute name is required and gives a name to the element
marker	The marker element is a generic element for a marker. It can be placed in a block instead of any of the other markers. The attribute name is required and gives a name to the element.

5.4 An introduction to borrowed HTML elements

Akoma Ntoso uses some elements that look like HTML but they do not belong to the HTML namespace. Even though they are similar tags and have similar meaning, they are not HTML elements. For this reason, they are reused inside of Akoma Ntoso avoiding inventing new vocabulary. Sometimes the semantic are identical (e.g. span) and sometimes it is different (e.g. div).

Name of the element	Group in Akoma Ntoso	Description
div	HTMLcontainers	The element div is an HTML element, but is NOT used in Akoma Ntoso as in HTML. Instead of being used as a generic block, Akoma Ntoso uses div as a generic container (as in common practice). The div is used any time you need to define a container not included in the regular vocabulary. <div eId="div_1" class="alignedRight"><p>Address: av. Smith</p><p>Name: mr. Brown</p></div>
p	HTMLblock	The element p is an HTML element and is used in Akoma Ntoso as in HTML, for the generic paragraph of text (a block)
ul/ol	HTMLblock	The elements ul/ol are HTML element for defining unnumbered or numbered list.
li	HTMLblock	The element li is an HTML item of ul or ol.
table	HTMLblock	The element table is HTML element for defining a table.
th/tr/td/caption	HTMLblock	The elements th/tr/td/caption are HTML elements of the table.
span	HTMLinline	The element span is an HTML element and is used in Akoma Ntoso as in HTML, for the generic inline.
b	HTMLinline	The element b is an HTML element and is used in Akoma Ntoso as in HTML, for indicating bold style.
i	HTMLinline	The element i is an HTML element and is used in Akoma Ntoso as in HTML, for indicating italic style.
a	HTMLinline	The element a is an HTML element and is used in Akoma Ntoso as in HTML, for indicating a link to hypertext resources.
u	HTMLinline	The element u is an HTML element and is used in Akoma Ntoso as in HTML, for indicating underline style.
sub	HTMLinline	The element sub is an HTML element and is used in Akoma Ntoso as in HTML, for indicating text as subscripts.
sup	HTMLinline	The element sup is an HTML element and is used in Akoma Ntoso as in HTML, for indicating text as superscripts.
abbr	HTMLinline	Sometime the act is named with an abbreviation. Akoma Ntoso manages abbreviation using HTML element abbr (e.g. FOIA for the "Freedom of Information Act").
br	HTMLmarker	It is the line break used in the HTML definition.
img	HTMLmarker	It is used as pointer for declaring the position where to embed an image in the XML manifestation.

5.5 An introduction to shared elements

Other elements inline are shared by all the type of documents:

date	The date element permits marking up any date in the text and associating a particular meaning using the refersTo attribute. <date date="2013-04-04" refersTo="#signatureDate">four April 2013</date> or to specify the time and zone <date date="2013-04-04T12:00:00" refersTo="#signatureDate">four April 2013</date> The attribute date is used to give a normalized value for a date according to the XSD syntax YYYY-MM-DD or a normalized value for a dateTime according to the XSD syntax YYYY-MM-DDThh:mm:ss(zzzz)
time	The time element is an inline element to identify a time expressed in the text and to propose a normalized representation in the time attribute
person	The person element is an inline element to identify a person expressed in the text and connect he/she to the ontological class
organization	The organization element is an inline element to identify an organization expressed in the text and connect it to the ontological class
concept	The concept element is an inline element to identify a concept expressed in the text and connect it to the ontological class
object	The object element is an inline element to identify an object expressed in the text and to connect it to the ontological class
event	The event element is an inline element to identify an event (e.g. Thanksgiving Day, Royal Assent) expressed in the text and to connect it to the ontological class
location	The location element is an inline element to identify a location (e.g. Montevideo, Senate Palace) expressed in the text and connect it to the ontological class
process	The process element is an inline element to identify a process (e.g. voting of the bill) expressed in the text and to connect it to the ontological class
role	The role element is an inline element to identify a role (e.g. member of assembly, secretary, president, judge, solicitor, etc.) expressed in the text and connect it to the ontological class
term	The term element is an inline element to identify a term (e.g. privacy, IPR, etc.) expressed in the text and to connect it to the ontological class
quantity	The quantity element quantity is an inline element to identify a quantity (e.g. 20 attendees, IPR, etc.) expressed in the text and to connect it to the ontological class
Def	The def element is an inline element to identify a definition (e.g. “stalking” is defined as.....) expressed in the text and to connect it to the ontological class
entity	The entity element is an inline element to identify an entity expressed in the text and to connect it to the ontological class

5.6 Attributes for managing the presentation

Sometimes it is necessary to represent the text as it is presented in the official publication. The page and line endings are often fundamental parts of the official manifestation of the legal document.

For this reason, we have the elements <eol> as the end of line markers and <eop> as the end of page markers. The following example shows a bill from South Africa where each line is numbered to indicate the number of lines.

The corresponding XML is shown below. Please notice the for managing the “drop cap” B with the attribute @class="dropCap" in order to provide the appropriate instructions for the presentation processing. Secondly the line numbering is managed using the attribute @numer in the <eol/> element.

<preamble> <formula name="enactingFormula"> BE IT ENACTED by the Parliament of the Republic of South Africa, as follows:- </formula> </preamble> <body> <section eId="sec_1"> <num>1.</num> <heading> <ref eId="ref_1" href="/akn/za/act1996-10-10/84/!main#sec_1">Amendment of section 1 of Act 84 of 1996</ref>, as amended by <ref eId="ref_2" href="/akn/za/act1997-05-10/100/!main">section 1 of Act 100 of 1997</ref>, <ref eId="ref_3" href="/akn/za/act1999-05-10/48/!main#sec_6">section 6 of Act 48 of 1999</ref> and <ref eId="ref_4" href="/akn/za/act2001-05-10/50/!main">section 1 of Act 50 of 2002</ref> </heading> <list eId="sec_1__list_1"> <intro> <ref eId="ref_6" href="/akn/za/act1996-10-10/84/!main#sec_1">Section 1 of the South African Schools Act, 1996</ref>, is hereby amended by<eol class="numbering" number="5"/> </intro> <point eId="sec_1__list_1__point_a"> <num>(a)</num> <content> <mod eId="mod_1">the insertion after the definition of “<quotedText eId="mod_1__qstr_1">Minister</quotedText>”of the following definitions: “<quotedStructure eId="mod_1__qstr_2"> <paragraph eId="mod_1__qstr_2__para_1"> <content> <ins> <def>‘no fee threshold’</def> means the level of funding per learner contemplated in the norms and standards for school funding applicable to a public school which enables the Minister to declare a school a no fee school in terms of this Act;</ins><eol number="10"/>

Another example is the following fragment of Public Law US (PUBLIC LAW 112–61—NOV. 29, 2011) where the syllabication interrupts the words “America” and “management”.

Currently, the <eop> and <eol> are used to identify the end of page (and respectively end of line) as markers-- by their mere presence at a given position. Therefore, they are placed nearest to the end of the page and line according to the reference copy in printed form. There is the assumption that the corresponding beginning of page and line are immediately after the previous <eop> and <eol> elements.

Additionally, the syntax of <eop> and <eol> allow for the adding of three attributes. The first attribute, @breakAt, specifies the number of characters within the next word that the page (or line) actually breaks at. This allows in-word breaks to happen even if the word is not actually broken in the XML. The second parameter, @number, allows specifying a page number or line number for the element, especially if we did not start at zero (which may happen if the document belongs to a container, e.g. a gazette). The third attribute, @breakWith, is for storing the character used for the syllabication interruption (e.g., hyphen or M dash — or N dash –).

<point eId="sec_2__list_1__point_2"> <num>(2) </num> <content eId="sec_2__list_1__point_2__content"> <def refersTo="#americaCupRaceManagement" class="definition">America's cup race management.</def>--The term ``America<eol breakAt="4" breakWith="-"/>'s Cup Race Management'' means the entity established to provide for independent, professional, and neutral race management of the America's Cup sailing competitions. </content> </point>

5.7 Modifications and versioning

Akoma Ntoso includes a sophisticated mechanism to keep track of the life cycle and evolution of a legal document. This is particularly useful for acts that are amended and modified in time, while maintaining their fundamental nature.

The management of the evolution of a document makes two important assumptions:

▪ Modifications and events in the life cycle of a document (including original approval, final repeal and any other event affecting its presence in the law system or its content) happen in precise moments in time that can be determined objectively (albeit possibly with difficulty) and are attributed to a specific date.
▪ Modifications and events in the life cycle are due to the enactment of a specific, individual document that can be objectively traced back and identified with an IRI. If two different documents affect the same act on the same date, then these must be counted as two different and separate events on the amended act.

Handling events in Akoma Ntoso centres around the <lifecycle> element in the <meta> section. The <meta> section contains two containers, among the others, <temporalData> and <references>, used to list the dates of all the events affecting a document, and the references to the IRIs of all the documents generating these events. Each reference is provided with a required identifier, which is used by the event list to specify which document is responsible for which events. These elements must appear in all documents that have undergone two or more events (e.g., all acts except the ones that still have no amendments).

Documents in Akoma Ntoso are organized in three main categories, as specified in the @contains attribute of the document type element:

▪ originalVersion: this value reflects the fact that the content on the document is exactly the content that has been formally and explicitly approved by the relevant authority, with no amendments applied.
▪ singleVersion: this value reflects the fact that the content of the document is an editorially modified version of the original document, according to one or more subsequent amendment documents. These amendment documents and the enactment dates of the amendments must be all mentioned in the <lifecycle> element. Individual additions and deletions are not marked in the content.
▪ multipleVersions: this value reflects the fact that the content of the document is the juxtaposition of fragments belonging to two or more different versions of the same document, each fragment marked as belonging to one or many of these versions. Thus, in a multipleVersions act there could be two or more copies of section 2, each associated to the date it started enactment and ended enactment.

The <lifecycle> element is a required element for all singleVersion and multipleVersion documents, and must be complete up to the enactment date of the latest document referenced in the <lifecycle> element (i.e., there can potentially exist subsequent amendments not included, but all amendments preceding the document’s date must be correctly listed and referenced, even if they play no part in the displayed content). OriginalVersion documents need not have the <lifecycle> element, but surely can have it if the editors decide so. In case a multipleVersions document is being generated, each element and text fragment may be associated with an enactment specification through the means of the five attributes: @start, @end (for validity), @startEfficacy, @endEfficacy (for efficacy) and @status. Each fragment (a whole element if appropriate, otherwise a newly inserted or <inline> element for text fragments for which no exact containing element exists) must use these attributes to specify its nature. The @start and @end attributes (and similarly the @startEfficacy and @endEfficacy attributes) contain a reference to the ID of the event that has marked the beginning or the end of the enactment (or of the efficacy) of the fragment. A @start attribute with no @end attribute marks a fragment that has appeared in an amendment and still exists in the latest recorded version of the document. An @end attribute with no @start attribute mark a fragment that was part of the original document but has been repealed before or at the latest recorded version of the document. The @status attribute records the type of amendment of the fragment. The value “omissis” can only be used by non-authoritative publications that need to display only part of the whole document: when status="omissis", the structure must be complete as if all contents are present, but unrequired parts of the actual content may be removed. Similarly, the value “editorial” can be used to add fragments of text of an editorial nature (i.e., that are generated by editors rather than authors). Examples include annotations and translated sentences. For instance:

Partye wat deel wil vorm van die proses van regering, is vol verligting. "Sien,'' sˆ die Nuwe NP, "die ANC is nie magshonger nie!'' Ryke ironie, komende van waar die Nuwe NP sit. (Translation of Afrikaans paragraph follows.) [Parties who want to form part of government are quite relieved. "You see'', says the New NP, "the ANC is not power-hungry!'' Such irony, if one considers where the New NP is sitting.]

The part of the provision that includes the quoted text is wrapped with <quotedText> or <quotedStructure> elements depending if the modification affects a portion of paragraph (<quotedText) or a structured hierarchy (<quotedStrcture>). Sometime the quoted text portion is not clearly understandable because the quoted character is missing or simply this character is repeated in each paragraph. It is the case of the US Amending acts. For this purpose, we use the attribute @inlineQuote. @inlineQuote is used for marking the character showing continuation of a quote e.g. at the beginning of each page or at the beginning of each line of the quote.

(a) DEFINITION OF DISABILITY.—Section 3 of the Americans with Disabilities Act of 1990 (42 U.S.C. 12102) is amended to read as follows: ‘‘SEC. 3. DEFINITION OF DISABILITY. ‘‘As used in this Act: ‘‘(1) DISABILITY.—The term ‘disability’ means, with respect to an individual‘‘(A) a physical or mental impairment that substantially limits one or more major life activities of such individual;

<point eId="point_a"> <num>(a)</num> <content> DEFINITION OF DISABILITY.—Section 3 of the Americans <eol/> with Disabilities Act of 1990 (42 U.S.C. 12102) is amended to <eol/> read as follows: <mod eId="point_a__mod_1">‘‘ <quotedStructure inlineQuote="‘‘"> <section eId="point_a__mod_1__sec_3"> <num>SEC. 3.</num> <heading>DEFINITION OF DISABILITY.</heading> <list eId="point_a__mod_1__sec_3__list_1"> <intro eId="point_a__mod_1__sec_3__list_1__intro"> As used in this Act: </intro> <point eId="point_a__mod_1__sec_3__list_1__point_1"> <num>(1)</num> <heading> DISABILITY.</heading> <list> <intro eId="point_a__mod_1__sec_3__list_1__point_1__list_1__intro"> —The term ‘disability’ means, with respect<eol/> to an individual— </intro> <point eId="point_a__mod_1__sec_3__list_1__point_1__list_1__point_A"> <num>(A)</num> <content> physical or mental impairment that substantially<eol/> limits one or more major life activities of such individual; </content> </point> </list> </point> </list> </section> </quotedStructure></mod> </content> </point>

5.8 References

Documents make references to external entities that need to be identified with clarity and no ambiguity. The current release of Akoma Ntoso includes a section where references to external concepts, people and places are specified. These include references to other Akoma Ntoso documents, to other nonAkoma Ntoso documents that are accessible through the net, or to individual instances of classes specified in a local ontology.

5.8.1 The structure of references

All references to external concepts share the same structure, in that they are empty elements in the references section provided with exactly four attributes:

▪ href: the IRI reference describing the entity being referred to. This can be a whole document (for instance, the act containing amendments to the current document), or a fragment of a document (for instance, the identifier of the unique record identifying precisely the person being referred to in the document).
▪ eId: this is the string that identifies within the document the entity being described. All internal references will thus use this eId. For instance, every event in the document lifecycle has a source attribute containing a reference to the IRI of the document affecting or being affected by the document.
▪ showAs: this is the string that can and must be used in displaying information about this entity. For instance, this attribute contains the name of the speaker as it must be displayed.
▪ shortForm: this optional attribute contains a secondary form of the display information of the entity. For instance, in some reports it is necessary to provide the full name of a person at the first utterance, and only the name in any further utterance from the same person.

5.8.2 Referring to precise concepts in the document

Akoma Ntoso provides a series of mechanisms for referring to precise concepts in the documents being marked up. Regardless of whether the textual content of the document is sufficiently explicit and unambiguous, the marker of the document may and should provide additional disambiguating information about individual pieces of fragment denoting precise concepts through the aid of the appropriate attributes.

This disambiguation happens systematically as a two-step process: first of all, a mention to the ontological concept is added to the references section and provided with an id, and then one or more attributes in the document elements are used to refer to it.

For instance, every individual in a debate is associated via the id to an element TLCPerson in the references section: the by attribute of the speech element indicates the speaker (this must be a TLCPerson), the as attribute specifies the role of the speaker (and it must be a TLCRole) and the to attribute indicates the addressee (this can either be a person or a role).

The following are the attributes used for this purpose:

▪ refersTo: points to any instance of a Top Level Class of the ontology. It is used to notify the reader in a generic way to what specific concept is the element referring to.
▪ href: contains the IRI of an instance of an FRBR document class or of a web page. Furthermore, it signals the application that the reference must be considered navigable, i.e., activatable by the user (e.g. via a link).
▪ upTo: for range references (e.g., rref and rmod) this specifies the IRI of the last, or highest, element of the range being referred to.
▪ by: points to a person, i.e., an instance of the class TLCPerson in the references section, relative to the person by which the content has been provided.
▪ as: points to a role, i.e., an instance of the class TLCRole in the references, relative to the role held by the person when uttering the content.
▪ to: points either to a role, a person or an organization, relative to the kind of addressee of the content being provided.

Thus, any fragment in the text content of the document referring to Events, Concepts, or other instances of the Top Level Classes need to use the refersTo attribute to point to the id of the corresponding element in the references section.

A few elements can be considered of some use:

▪ The element entity provides a standard mechanism to refer to mentions of instances of Top Level Classes in the content of the document. Any instance of any class can be referred to via an instance element.
▪ ref, mref, and rref provide a mechanism to refer to other documents in the Akoma Ntoso domain. These elements may use the refersTo attribute, but will most frequently directly use the href attribute to specify a navigable reference to the document they refer to. The element ref specifies a single reference, the element mref a group of references (a list of individual ref elements must be placed inside the mref element, one for each reference) and the rref element specifies a range of references delimited by the from and upTo attributes.
▪ mod, mmod and rmod provide a mechanism to specify modifications to other documents. The mod element contains one ref element identifying the destination of the modification, and may contain as many quotedStructure and quotedText elements as needed providing the textual modification (if any) in terms of either whole structures or individual words. The element mod specifies a single modification, the element mmod a group of modifications (a list of individual mod elements must be placed inside the mmod element, one for each modification) and the rmod element specifies a range of modifications delimited by the from and upTo attributes.

mod

(3) In subsection (4) of that section, after “that person” insert “(whether or not the person is in the United Kingdom)”. <subsection eId="sec_4__subsec_3"> <num>3</num> <content> <mod eId="sec_4__subsec_3__mod_1">In <ref eId="ref_4" href="/akn/uk/act/2000-07-28/!chapter23~sec_11__subsec_4">subsection (4)</ref> of that section, after <quotedText eId="sec_4__subsec_3__mod_1__qtext_1" startQuote="“" endQuote="“">that person</quotedText> insert “<quotedText eId="sec_4__subsec_3__mod_1__qtext_2">(whether or not the person is in the United Kingdom)</quotedText>”.</mod> </content> </subsection>

include the attribute @for in order to connect the modification portion of the text with the related reference in another part of the text.

@for

<subsection eId="sec_4__subsec_2"> <num>2</num> <content> In <ref eId="ref_2" href="/akn/uk/act/2000-07-28/!chapter23~sec_11__subsec_2">section 11 (implementation of interception warrants), after subsection (2)</ref> insert— <mod eId="sec_4__subsec_2__mod_1" for="#ref_2"> <quotedStructure eId="sec_4__subsec_2__mod_1__qstr_1" class="primary main" startQuote="“" endQuote="”"> <subsection eId="sec_4__subsec_2__mod_1__qstr_1__subsec_2A"> <num>2A</num> <content> A copy of a warrant may be served under subsection (2) on a person outside the United Kingdom (and may relate to conduct outside the United Kingdom).</content> </subsection> </quotedStructure> </mod> </content> </subsection>

5.8.3 Referring to legal sources

Another important situation where we use a combination of metadata and semantic annotation in the content is the relationship of a normative citation to a legal source using multiple naming convention (both functionally equivalent and non-equivalent). If implementers want to use multiple citation schemes in parallel, they can use the following markup method, here exemplified with the Akoma Ntoso naming convention. :

<content> <p><ref eId="ref_13" href="/akn/uk/act/2000-07-28/chapter23/!main#sec_58">Section 58 of the Regulation of Investigatory Powers Act 2000 </ref>(reports by the Interception of Communications Commissioner) is amended as follows.</p> </content>
<analysis source="#palmirani"> <otherReferences source="#FV"> <alternativeReference for="#ref_13" refersTo="#ELI" href="http://www.legislation.gov.uk/id/ukpga/2000/23/section/58"/> <implicitReference for="#span_10" href="/akn/it/act/2014/123"/> </otherReferences> </analysis>

In the first XML snippet we have marked up the reference ref_13. In the second XML snippet we have modelled the metadata <otherReference>using <alternativeReference> and annotating the URI/IRI alternative syntax in the @href attribute. Additionally using <implicitReference> we can express implicit reference expressed in the @href attribute and connected with a specific location in the text linked using @for. Additionally the ELI/ECLI/URN:LEX reference can be assigned to the legal source as an alias in the FRBR block as follows:

<FRBRWork> <FRBRthis value="/akn/uk/act/2016-03-16/5/!main"/> <FRBRuri value="/akn/uk/act/2016-03-16/5"/> <FRBRalias name="ELI" value="http://www.legislation.gov.uk/id/ukpga/2016/5/”/> <FRBRalias name="short title” value=”Childcare Act 2016"/>

5.9 Metadata

By definition, all metadata is editorial in nature, it is not content, but statements about the content, and as such it is, in its entirety, the responsibility of the editor who marks up the document to provide them. So metadata are editorial additions, they are information and values that are not in the original content of the document and that are added to improve comprehension and classification of the document and are essential to make a document “machine readable” since they are meant to provide, together with the markup the understanding and legal knowledge of the documents that “machine” can then use to “read/understand” the document.

Metadata are a way to provide an interpretation of a set of information embedded into the document (objective interpretation) - e.g. date of publication - or as an intellectual elaboration of the text (subjective interpretation) - e.g. incomplete references. Even if, as a user, you will never see any of the tags or the actual metadata section, it is important to understand its articulation and what scope it serves so that its role can better be appreciated.

At the metadata level Akoma Ntoso provides the necessary mechanisms for annotating the text with enriched data collected in; a separate block (metadata section) or in place in the text (inline elements).

The Akoma Ntoso metadata section provides a separate place for enriching a document with metadata, a place that is clearly identified as such and is dated and authored differently than the content of the text itself.

The metadata elements of Akoma Ntoso are organized in a block called <meta> and inside we find few main sections:

identification:	containing all relevant facts about document, dates and authors. This block also includes translation information when the document is derived by other languages and properties such as the prescriptiveness of the document and the authoritativeness.
publication:	publication metadata
classification:	keyword classification
lifecycle:	list of the events that modify the document.
workflow:	list of the procedural steps necessary for delivery of the document or that have some role in the legislative process.
analysis:	list of the qualification of the provisions and assertions on the text.
temporalData	list of temporal parameters as a set of events (e.g. time intervals of enter into force and time of efficacy).
references:	list of the external resources connected with the document as well as of all individuals, organizations, and concepts that are relevant to understanding the content and the history of the document.
notes:	annotations inserted by the editor or by the author to explain and detail the text content of the document
proprietary:	local and proprietary metadata
presentation	specifications of metadata useful for assisting with the document rendering.

5.9.1 Identification

Akoma Ntoso, unlike everyday language, describes documents according to the Functional Requirements for Bibliographic Records (FRBR) model, a standard nomenclature by IFLA (International Federation of Bibliographic Associations). FRBR is a conceptual entity-relationship model that relates user tasks of retrieval and access in online library catalogues and bibliographic databases from a user’s perspective. It represents a more holistic approach to retrieval and access as the relationships between the entities provide links to navigate through the hierarchy of relationships.

Since the most important concepts in Akoma Ntoso are connected to documents, the main part of this section is devoted to detailing the URIs/IRIs of document-related concepts, and in particular Works, Expressions, and Manifestations. Items are, by definition, outside of the scope of this standard, and are only briefly described. The final part of the section provides a URI-based naming mechanism for nondocument entities (as well as for document entities when they are handled in a similar way to nondocument entities).

All documents at all levels can be composed of sub-elements, that when combined form the whole document. These are called components and abstractly represent the notion that several independent subdocuments form the whole document as it appears to the reader (i.e., a main body possibly followed by a number of attachments such as schedules and tables):

WorkComponents (e.g., main, schedule, table, etc) - the WorkComponents are abstract entities that can be referenced to refer to different ExpressionComponents in time.

ExpressionComponent (e.g., main, schedule, table, etc.) - the ExpressionComponents represent the visible division of the document as generated by the content author (Parliament, etc.)

ManifestationComponent (e.g., xml files, PDF files, TIFF images, etc.) - the ManifestationComponents represent the division of the document as generated by the manifestation author (e.g., the XML editor).

ItemComponent - the actual files corresponding to the ManifestationComponents. Other concepts dealt by the Akoma Ntoso informal ontology also derive from the IFLA FRBR ontology, and include but are not limited to individuals (Person), organizations (Corporate Body), actions and occurrences (Event), locations (Place), ideas (Concept) and physical objects (Object). The full list of such concepts is provided in section 4.11.1 of the Akoma Ntoso Naming Convention Version 1.0. The scope of the naming convention is to identify in a unique way all Akoma Ntoso concepts and resources on the network and in general all collections thereof. Some principles and characteristics should be respected in the naming convention:

MEANINGFULNESS: the name is a meaningful and logical description of the resource and not of its physical path
PERMANENCE: the name must be permanent and stable over time
INVARIANCE: the name must derive from invariant properties of the resource so as to provide some degree of certainty in obtaining the same name for the same resource regardless of process, tool and person.
FRBR concepts are used differently when taking about documents in a variety of situations. In each case it is important to use the URI/IRI for the correct FRBR level of document. We describe here a few particularly frequent situations:
1. Legislative references will most probably refer to WORKs: acts referring to other acts do so regardless of the actual version, and references must be to something independent of all possible expressions, e.g., to the work.
1. The list of attachments and schedules belong to a specific EXPRESSION, so references to ExpressionComponents is specific of the expression level.
1. Yet the specific Manifestation that is the Akoma Ntoso XML format uses an XML-based syntax to refer to ExpressionComponents, and associate them to the corresponding ManifestationComponents containing the appropriate content. Therefore, within XML files the URI/IRI of the Manifestation must be used to refer to all components, including the main document, all attachments and all schedules.
1. Multimedia fragments within an XML manifestation (e.g., a drawing, a schema, a map, etc.) do not exist as independent ExpressionComponents, as they are only a part of some ExpressionComponents (even when they are the only part). In fact, they are only ManifestationComponents, and as such are referred to in object and img elements with the appropriate ManifestationComponents URI/IRI. Even if the same multimedia content appears in different parts of the content of a Manifestation, each instance of that content must correspond to a different ManifestationComponent, and must be considered independently of the other.
1. It is an Item-level decision, once ascertained that the content is exactly identical, to provide space-saving policies by storing only one copy of the multimedia content. This Item-level decision has no impact on references and names, which are still individually different from each other.
1. Non-document concepts are referred to within the metadata and content of Akoma Ntoso documents. References are always performed in two steps: the first step ties the reference point in the document to an item in the Reference section using internal (and not standardized) IDs; the second step ties the item in the reference section to the actual concept through the URI/IRI of the concept as specified in this document.

The FRBR model offers an excellent framework to deal with legal texts. In legal domain, we’ve a lot of derivations due to the constant amendments of normative acts.

FRBR identifies four different abstractions about documents that are carefully and clearly differentiated and that relate to each other:

	Bibliographical context	Legal Context
work	“Work” is a distinct intellectual or artistic creation at the conceptual level. Qualifying characteristics: identity e.g. Hamlet = work Regardless of versions, variants, revisions, data formats and location. Even if a “Work” is translated in different languages that have no words in common with the original, it is still the same document, the same “work”.	“Work” refers to the original “content” of the legal document. For examples, the abstract concept of the legal resource; e.g. act 3 of 2005)
expression	“Expression” is the specific intellectual or artistic form that a work takes each time it is ‘realized. Qualifying characteristics: content e.g. Hamlet original version book = expression or Hamlet original version video = expression All different editions of the same version of the document, all the different data format in which the content of a document can be expressed, all are unified by the fact that they express the same actual content.	“Expression” refers to “form” of the legal document. For examples, any version of the “work” whose content is specified and different from others for any reason: language, versions, etc.; e.g. act 3 of 2005 as in the version following the amendments entered into force on July 3rd, 2006
manifestation	“Manifestation” is the physical embodiment of an “expression” of a “work”. It is a specific form that the document assumes once it takes a concrete representation. Qualifying characteristics: data format e.g. Hamlet original version book – hardback version or Hamlet original version video DVD version For physical documents, it could be a specific edition as published in a specific choice of paper, binding, typographical characteristics, etc. For electronic documents, it is the choice of a specific data format, process method, and so on.	“Manifestation” refers to the realization of the publishing work either on paper or in any electronic format. For examples, any electronic or physical format of the “expression” MS Word, Open Office, XML, TIFF, PDF, etc.; e.g. PDF version of act 3 of 2005 as in the version following the amendments entered into force on July 3rd, 2006.
item	“Item” is one physical copy of a document in a concrete form of a “manifestation” of an “expression” of a “work”. Qualifying characteristics: location e.g. Hamlet original version book – hardback version of the Shakespeare Library, London It could be an individual volume in a bookshelf, or a specific file in a specific directory of a specific computer. Qualifying Characteristic: positions or address	“Item” refers to a univocally identified exemplar of a certain manifestation. For examples, the physical copy of any manifestation in the form of a file stored somewhere in some computer on the net or disconnected; e.g. the file called act32005.pdf on my computer containing a PDF representation of act 3, 2005

Akoma Ntoso makes careful use of the FRBR hierarchy of document definitions: a legal document (such as an act), which may assume different content after being revised and amended throughout its useful life, is nonetheless a single work - which gets multiple expressions whenever some specific content is generated (for instance, through an amendment). Each of these expressions has the chance of then being expressed in some electronic form (as a PDF document, or an HTML document, or, in our case, as a specific XML document using vocabulary and grammar from the Akoma Ntoso markup language) thereby generating at least one manifestation. Each physical file where the manifestation is located is therefore an item. Besides the FRBR levels, an identifier must conform to the URI/IRI syntax and the Akoma Ntoso Naming Convention. While defining a URI/IRI it is important to define

1. the country,

2. the type of the document,

3. the date of the document and, where applicable, also the version,

4. the main language, and also

1. the different parts like annexes, exhibits, table, etc.

In fact, all documents at all levels of the FRBR classification be composed of sub-elements, that when combined form the whole document. These are called components, they abstractly represent the notion that several independent subdocuments form the whole document as it appears to the reader (i.e., a main body possibly followed by a number of attachments such as schedules and tables).

It is important, during the URI/IRI identification, to analyse the structure of the parts of a document in order to separate the logical organization coming from the author (parliament, judge) from the physical organization of the content usually decided by some technical criteria. In other words, the work URI/IRI should reflect the original logical structure as organized by the author for preserving over time the original forms and hierarchy of the annexes or of the other material composing the full document. The physical organization can follow different criteria connected to the application purposes or technical choices. We can find in the URI/IRI of the Work three components but in the Manifestation we can find a unique URI/IRI component for managing document in any easier way.

The Akoma Ntoso language allows names for documents that are free of restrictions and can be used everywhere (except in the markup of references) instead of the corresponding URIs/IRIs. If desired, these names can be specified to record “well-known” natural language names for the document, as well as shortened names or even acronyms commonly used to refer to a document, as in the example below.

identification	<identification source="#oasis">
Work Act n. 10 of 22 November 2011. It is created on the same date by the parliament (author) The Work is composed by two parts: main document and one annex. ComponentInfo details the composition of the package.	<FRBRWork> <FRBRthis value="/akn/un/act/2011-11-22/10/!main"/> <FRBRuri value="/akn/un/act/2011-11-22/10"/> <FRBRalias name=”long name” value=”Business Development Act no.10 of 22 November 2011”/> <FRBRdate date="2011-11-22" name="Generation"/> <FRBRauthor href="#parliament" as="#author"/> <componentInfo> <componentData eId="wmain" href="#emain" name="main" showAs="Main document"/> <componentData eId="wannex" href="#eannex" name="annex" showAs="Provisions as to the conduct of business of the board"/> </componentInfo> <FRBRcountry value="us"/> <FRBRnumber value="395-2010"/> <FRBRname value="bill"/> <FRBRprescriptive value="true"/> <FRBRauthoritative value="true"/> </FRBRWork>
Expression Version in force at 19 December 2013. The date is the date of the expression. The author is the parliament. This means version officially approved.	<FRBRExpression> <FRBRthis value="/akn/un/act/2011-11-22/10/eng@2013-12-19/!main"/> <FRBRuri value="/akn/un/act/2011-11-22/10/eng@2013-12-19"/> <FRBRdate date="2013-12-19" name="Generation"/> <FRBRauthor href="#palmirani" as="#editor"/> <componentInfo> <componentData eId="emain" href="#mmain" name="main" showAs="Main document"/> <componentData eId="eannex" href="#mannex" name="schedule" showAs="Provisions as to the conduct of business of the board"/> </componentInfo> <FRBRauthoritative value="true"/> <FRBRlanguage language="eng"/> </FRBRExpression>
Manifestation The date of creation is when the editor marks up the document: 2016-01-30.	<FRBRManifestation> <FRBRthis value="/akn/un/act/2011-11-22/10/eng@2013-1219/!main.xml"/> <FRBRuri value="/akn/un/act/2011-11-22/10/eng@2013-12- 19.akn"/> <FRBRdate date="2016-01-30" name="Generation"/> <FRBRauthor href="#palmirani" as="#editor"/> <FRBRauthor href="#vitali" as="#editor"/> <componentInfo> <componentData eId="mmain" href="main.xml" name="main" showAs="Main document"/> <componentData eId="mannex" href="annex.xml" name="annex" showAs="Provisions as to the conduct of business of the board"/> </componentInfo> <FRBRformat value="xml"/> </FRBRManifestation>
	</identification>

The expression also includes metadata for capturing the linguistic aspects. In particular, FRBRlanguage and FRBRtranslation permit to creating a relationship among expressions that are the outcome of a translation process. The following example shows that the current document is a translation made by the Paliament (by) from Swahili (fromLanguage), to English (FRBRlanguage), passing through French (pivot).

<FRBRlanguage language="eng"/> <FRBRtranslation href="/akn/ke/act/1997-08-22/3/swa@" fromLanguage="swa" by="#parliament" pivot="fra"/>

It is possible in some particular situations (e.g., internal legal drafting) to not have the version date, but rather a version number. In order to capture this number we can use the element <FRBRversionNumber>

<FRBRExpression> <FRBRthis value="/akn/un/doc/2015-11-22/10/eng@v_3/!main"/> <FRBRuri value="/akn/un/ doc/2015-11-22/10/eng@v_3"/> <FRBRdate date="2015-11-22" name="Generation"/> <FRBRauthor href="#palmirani" as="#editor"/> <FRBRversionNumber value="3"/> <FRBRlanguage language="eng"/>

5.9.1.1 Preservation

The element preservation is the FRBR metadata property containing an arbitrary list of elements detailing the preservation actions taken for the document is the respective level of the FRBR hierarchy. It is fundamental for permitting to understand at each level (work, expression, manifestation). The example below shows the Public Law 112-613 of US Government Printing Office package in MODS4 representation embedded inside of the Akoma Ntoso FRBRManifestation block.

<FRBRManifestation> <FRBRthis value="/akn/us/act/2011-11-29/112-61/eng@/!main.xml"/> <FRBRuri value="/akn/us/act/2011-11-29/112-61/eng@.akn"/> <FRBRdate date="2012-05-09" name="Generation"/> <FRBRauthor href="#palmirani" as="#editor"/> <preservation xmlns:my="http://my"> <my:mods ID="P0b002ee183eb812a" version="3.3" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-33.xsd" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchemainstance" xmlns="http://www.loc.gov/mods/v3"> <my:name type="corporate"> <namePart>United States Government Printing Office</namePart> </my:name> <my:name type="corporate"> <my:namePart>United States</namePart> <my:namePart> National Archives and Records Administration</namePart> <my:namePart> Office of the Federal Register</namePart> <my:description>Government Organization</description> </my:name> <my:typeOfResource>text</typeOfResource> <my:genre authority="marcgt">government publication</genre> <my:titleInfo type=”alternative”> <my:title>An act to facilitate the hosting in the United States of the 34th America's Cup by authorizing certain eligible vessels to participate in activities related to the competition, and for other purposes</title> </my:titleInfo> <my: titleInfo type=”alternative”> <my:title>America's Cup Act of 2011</title> </my:titleInfo> <my:titleInfo> <my:title>Public Law 112-61</title> </my:titleInfo> <my:physicalDescription> <my:note type="source content type">deposited</note> <my:digitalOrigin>born digital</digitalOrigin> <my:extent>3 p.</extent> </my:physicalDescription> </my:mods> </my:preservation> </FRBRManifestation>

5.9.2 Publication

The publication is a part of the meta block and captures the metadata concerning the official publication process. The name of the source (Official Journal), the date (in normal format), the label for the presentation (showAs), the number of the source of publication (number). The publication is mandatory for the act type but not for the bill type of document.

publication	<publication name="Official Journal" date="1980-01-01" showAs="Official Journal of UN" number="234"/>

5.9.3 Classification

The classification section is dedicated to assigning keywords to the document or fragment of the document, on the base of the topic treated in the legal content. The content of the keyword is stored in the attribute value, the dictionary attribute stores the name of the vocabulary used. It is possible to use a different vocabulary and to use href for connecting the keyword to the external ontology. The kewords are connected with the text using @refersTo value (e.g., "#k_ familyLaw") and the element <term>. Keyword can be connected using @refersTo value with TLC <references> part.

classification	<classification source="#oasis"> <keyword eId="k_humanRight" value="humanRight" showAs="Human Right" dictionary="EuroVOC" href="/EuroVoc/Law/ humanRight" refersTo="#TLCConcept_humanRight"/> <keyword eId="k_ familyLaw" value="familyLaw" showAs="Family Law" dictionary="EuroVOC" href="/EuroVoc/Law/familyLaw" refersTo=”#TLCConcept_familyLaw”/> </classification> <p>The <term refersTo="#k_ familyLaw">Family Law</term> is applied to the following situations</p>
	<term refersTo="#copyright">license</term> <keyword value="copyright " dictionary="http://sinatra.cirsfid.unibo.it/rdf/IPR/ copyright " refersTo="#IPR"/> <TLCConcept href="/ontology/concept/ipr" eId="IPR" showAs="IPR "/>

classification

<classification source="#oasis"> <keyword eId="k_humanRight" value="humanRight" showAs="Human Right" dictionary="EuroVOC" href="/EuroVoc/Law/ humanRight" refersTo="#TLCConcept_humanRight"/> <keyword eId="k_ familyLaw" value="familyLaw" showAs="Family Law" dictionary="EuroVOC" href="/EuroVoc/Law/familyLaw" refersTo=”#TLCConcept_familyLaw”/> </classification> The <term refersTo="#k_ familyLaw">Family Law</term> is applied to the following situations

<term refersTo="#copyright">license</term> <keyword value="copyright " dictionary="http://sinatra.cirsfid.unibo.it/rdf/IPR/ copyright " refersTo="#IPR"/> <TLCConcept href="/ontology/concept/ipr" eId="IPR" showAs="IPR "/>

5.9.4 Lifecycle

The lifecycle lists all the events that are involved within the chain of modifications of the document. These events modify the expression.

lifecycle	<lifecycle source="#oasis"> <eventRef eId="eventRef_1" date="1997-08-29" source="#ro_1" type="generation"/> <eventRef eId="eventRef_2" date="2003-12-19" source="#rp_1" type="amendment"/> </lifecycle>

5.9.5 Workflow

The workflow blocks list the events that are involved with the legislative or judiciary or parliament process. A workflow step does not necessarily change the expression. However, when a new expression occurs, we record all the workflow steps connected to it. The following example lists three workflow steps: firstReading, secondReading, thirdReading. In this case, the firstReading did not modify the expression. The secondReading and the thirdReading are connected to their correspondent expression by href (uk/bill/1345/eng@2004-12-15– bill URI). We notice that the proprietary tags include local specifications that support the workflow management system import/export of the data.

workflow

5.10 Analytical metadata

5.10.1 Analysis

The block Analysis includes all the juridical metadata coming from a specific interpretation of the legal source. The Analysis block describes information concerning modifications, restrictions of the normative effects e.g. by jurisdiction limitation, judgment result, qualification of the judgment’s citations, parliamentary voting, mapping history concerning the original wId and the current eId.

activeModifications:	Block of metadata for managing the modifications made by the current document to another document.
passiveModifications:	Block of metadata for managing the modifications arrived to the current document.
restrictions:	Block of metadata for managing the limitation of the normative effect, in particular this block permits defining the jurisdiction restrictions.
judicial:	Block of metadata for managing the judiciary metadata such as the qualification of the case-law references and the result of the decision.
parliamentary:	Block of metadata for managing the parliamentary metadata such as the quorum information, the voting results, and the recall data.
mappings:	Block of metadata for managing the changes of ids when a renumbering occurs and also whenever this expression is not the master expression of the document (e.g. linguistic variants with different numbering of the partitions imposed by the translation process).
otherReferences	Used to specify a number of <otherRef> elements that are meant to specify implicit references associated with fragments of the document (identified through a source element).
otherAnalysis	Any other proprietary metadata.

5.10.2 activeModifications

In all of the document types it is possible to model the modificatory provisions. Especially in the amendment (official document for proposing modifications to a bill), bill, act, debate (e.g. oral amendment) and doc (e.g. veto of the executive) the modificatory provision is a legal normative statement that disposes modifications to another legal document. In the legal text we model the textual elements (e.g. quotedText, quotedStructure, ref, etc.) and in the meta block activeModification we provide the semantic information like: source of modification, destination of the modification, position where to apply the modification in the destination, action of the modification, temporal parameters, conditions or limitation of the modification, other peculiar parameters for managing special modifications (e.g. renumbering).

The following table provides some examples of textual modifications: repeal, substitution, insertion, split, join, renumbering.

<textualMod>: it provides the type of modification to apply. The attribute @incomplete permits specifying the incompleteness of the information for applying in an automatic manner the modification action (e.g. lack of precision concerning the destination). The attribute @exclusion (values true or false) is a boolean data that indicates that exists exception avoiding an automatic consolidation. <source>: it provides the reference to the fragment or portion of the legal text where the modification is expressed; <destination>: it provides the IRI where the modification should be applied. @pos in the destination element permits specifying some information concerning the precise location where to apply the modification: after, before, end, start, inside, unspecified.

<old>: it provides the reference to the quotedText or quotedStructure where to find the old text that should be modified <new>: it provides the reference to the quotedText or quotedStructure where to find the new text involved in the modifications; <previous>: it provides the reference to the eId of the element affected by renumbering as located in the structure in the previous version/expression.

repeal	<textualMod type="repeal" eId="textualMod_1" incomplete="true" exclusion="true"> <source href="#mod_1"/> <destination href=“/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18 #art_16"/> <old href="#mod_1__qtext_1"/> </textualMod> The previous XML fragment means: in the bill n. 1055, at 2008-02-25 article 16, it is repealed the word “male” (referenced to the text pointed out by the element <old>) but there are exceptions (the exception is expressed in the @exclusion=”true” and so also the @incomplete=”true”).
substitution insertion	<textualMod type="substitution" eId="activeModifications__textualMod_2"> <source href="#mod_1"/> <destination href=“/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18art_16"/> <old href="#mod_1__qstr_1"/> <new href="#mod_1__qstr_2"/> </textualMod> The previous XML fragment means: in the bill n. 1055, at 2008-02-25, art. 16, the old text specified in mod_1_qstr_1 is substituted by the text defined in the mod_1__qstr_2. <textualMod type="insertion" eId="activeModifications__textualMod_3"> <source href="#mod_1"/> <destination href=“/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18/!mainart_16" pos="before"/> <old href="#mod_1__qtext_1"/> <new href="#mod_1__qtext_2"/> </textualMod> The previous XML fragment means: Insert the new text contained in mod_1__qtext_2 in the art. 16 before the text specified by the href attribute of <old> <textualMod type="insertion" eId="activeModifications__textualMod_3"> <source href="#mod_1"/> <destination href=“/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18/!main~art_16" pos="before"/> <new href="#mod_1__qstr_1"/> </textualMod> The previous XML fragment means: insert a new structure (mod_1__qstr_1) before the art. 16.
join	<textualMod type="join" eId="activeModifications__textualMod_4"> <source href="#mod_1"/> <destination href="/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18/~art_16__para_1"/> <destination href=“/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18/~art_16__para_2"/> <new href="#mod_1__qstr_2"/> </textualMod> The previous XML fragment means: take the paragraph 1 and the paragraph 2 of the art. 16 and join in the unique element as defined in “new”.. For example “new” can contain the number of the new joined partition.
split	<textualMod type="split" eId="activeModifications__textualMod_5"> <source href="#mod_1"/> <destination href=“/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18/~art_16__para_1"/> <new href="#mod_1__qstr_2"/> </textualMod> The previous XML fragment means: take the paragraph 1 of the art. 16 and split it following the structure defined in “new” element. For example “new” can contain the number of the new splitted partition.
renumbering	<textualMod type="renumbering" eId="activeModifications__textualMod_6"> <source href="#mod_1"/> <destination href=“/akn/uy/bill/camera/2008-02- 25/carpeta1055-2008/esp@2009-08-18/~art_23"/> <previous href=“/akn/uy/bill/camera/2008-02-25/carpeta1055-2008/esp@2009-08-18/~art_16" eId="activeModifications__textualMod_6_previous"/> </textualMod> The previous XML fragment means: renumber the art. 16 in art. 23.
	</activeModifications>

5.10.3 passiveModifications

The passiveModifications block records the modifications received from other legal documents or the changes applied to the current version of the document. The passiveModifications provides relevant information to permit the reverse engineering of the changes applied.

passiveModifications
repeal	<textualMod eId="passiveModifications__textualMod_1" type="repeal" period="#tmpg_1"> <source href="/akn/uy/amendment/senate/2009-09-25/34/"/> <destination href="#art_10__para_1__list_1__point_1"/> <old> <uy:text>por el incumplimiento injustificado de las contrapartidas a que refiere el artículo 8º.</uy:text> </old> </textualMod> In this passive modification the Uruguay Parliament added a proprietary element (uy:text) for storing the old text that is repealed in the current version of the document. .
substitution	<textualMod eId="passiveModifications__textualMod_2" type="substitution" period="#cmp_1__tmpg_4"> <source href="/akn/uy/amendment/senate/2009-09-25/34/"/> <destination href="#cmp_1__docType_1"/> <old> <uy:text>TEXTO APROBADO </uy:text> </old> <new href="#cmp_1__docType_1__ins_1"/> </textualMod> This passive modification models the substitution of the old text in the new text, with particular regard to the modification in the <preface> of the type of document.
insertion	<textualMod eId="passiveModifications__textualMod_3" type="insertion" period="#tmpg_4"> <source href="/akn/uy/amendment/senate/2009-09-25/34"/> <destination href="#art_7__para_3"/> </textualMod> Insertion of the paragraph 3 in the new versioned document.
join	<textualMod eId="passiveModifications__textualMod_4" type="join" period="#tmpg_4"> <source href="/akn/uy/amendment/senate/2009-09-25/34"/> <destination href="#art_6__para_1"/> <old href="/uy/bill/ejecutivo/carpeta/2005-04-04/137- 2005/esp@2005-05-02T24:00:00-03:00/!main~~art_6__para_2"/> <old href="/uy/bill/ejecutivo/carpeta/2005-04-04/137-2005/esp@2005-05-02T24:00:00-03:00/!main~~art_6_para_3"/> <new href="#art_6__del_1"/> </textualMod> This fragment models the join effect on the current document. The destination is the current point in the text where the join was applied. The two old elements provide two original elements that are joined. The new indicates the point where was deleted the disjunction between the two elements. We use <del/> for indicating where was applied the conjunction.
split	<textualMod eId="passiveModifications__textualMod_5" type="split" period="#tmpg_3"> <source href="/akn/uy/amendment/senate/2009-09-25/34"/> <destination href="#art_6__ins_1"/> <destination href="#art_6_ins_3"/> <old href="#art_6__para_1"/> <new href="#art_6_ins_2"/> </textualMod> This fragment models the result of a split modification. Two destinations are pointed out to the results of the split, in this case two element <ins> that delimitates the result of the divisions. The old represents the partition involved by the subdivision. The new indicates where the split is done (art_6__ins_2).
renumbering	<textualMod eId="passiveModifications__textualMod_6" type="renumbering" period="#tmpg_3"> <source href="/akn/uy/amendment/senate/2009-09-25/34"/> <destination href="#art7__para_2"/> <previous href=“/akn/uy/bill/ejecutivo/2005-04- 04/carpeta137-2005/esp@2005-05-02/!main~art7__para_3" showAs="previous" eId="previous_1"/> </textualMod> This markup shows the effect of the renumbering on the destination document. The source says where the renumbering come from; destination says the partition affected by the renumbering in the current document; previous describes the previous partition expression ID.

5.10.4 restrictions

<restrictions> block contains <restriction> elements that describe jurisdiction specifications and other types of restrictions of normative effectively. Each restriction element associates a TLCConcept identified by a @refersTo attribute to a fragment of the document identified by an href attribute. In the following example we have @href attribute hosting multiple references: art. 12, art. 32, art. 56 for avoiding the redundancy. At the moment only one type of restriction is possible, namely jurisdiction. Other types of restrictions may be specified in future by adding values to the new type restrictionType. This can be used to specify jurisdiction restrictions (frequent, e.g., in UK legislation) to individual fragments of the legislation.

restrictions

<restrictions source="#fv"> <restriction type="jurisdiction" eId="restriction_1" refersTo="#gbeaw" href="#art_12"/> <restriction type="jurisdiction" eId="restriction_2" refersTo="#gb- eaw" href="#art_32"/> <restriction type="jurisdiction" eId="restriction_3" refersTo="#gb- eaw" href="#art_56"/> </restrictions> <restrictions source="#palmirani"> <restriction type="juridiction" eId="restriction_1" refersTo#="#jurisdictionEnglandWales" href="#art_12/> <restriction type="juridiction" eId="restriction_2" refersTo#="#jurisdictionEnglandWales" href="#art_32"/> <restriction type="juridiction" eId="restriction_3" refersTo#="#jurisdictionEnglandWales" href="#art_56"/> </restrictions> And in the <references> block we have also this specification: <references source=”…”> <TLCLocation eId="england.wales" href="..." showAs="England and Wales" /> </references>

5.10.5 judicial

In a judgment document type it is possible to qualify the citation made by the judge supporting his/her thesis and final decision. In the following example, the reference ref_1 supports the judge thesis and it is accessible in the href /it/judgment/2000/123.

The result element expresses the final outcome of the case-law, using the attribute type (in our case approve). The complete list of result is:

deny
dismiss
uphold
revert
replaceOrder
remit
decide
approve.

The list of the qualifications for classifying the citations are:

<supports>: The element supports is a metadata element specifying a reference to a source supported by the argument being described
<isAnalogTo>: The element isAnalogTo is a metadata element specifying a reference to a source analog to the argument being described
<applies>: The element applies is a metadata element specifying a reference to a source applied by the argument being described
<extends>: The element extends is a metadata element specifying a reference to a source extended by the argument being described.
<restricts>: The element restricts is a metadata element specifying a reference to a source restricted by the argument being described
<derogates>: The element derogates is a metadata element specifying a reference to a source derogated by the argument being described
<contrasts>: The element contrasts is a metadata element specifying a reference to a source contrasted by the argument being described.
<overrules>: The element overrules is a metadata element specifying a reference to a source overruled by the argument being described
<dissentsFrom>: The element dissentsFrom is a metadata element specifying a reference to a source dissented from the argument being described
<putsInQuestion>: The element putsInQuestions is a metadata element specifying a reference to a source questioned by the argument being described.
<distinguishes>: The element distinguishes is a metadata element specifying a reference to a source being distinguished by the argument being described.

judicial	<judicial> <result type="approve"/> <supports> <source href="#ref_1"/> <destination href="akn/it/judgment/2000/123"/> </supports> </judicial>

5.10.6 parliamentary

In an analysis it is possible to track the metadata connected to the parliamentary events recorded in the debate such as the call of quorum, recount of quorum, voting recount, voting.

The following fragment presents a simple example where it is possible to connect the analysis annotation with the text using href attribute and the semantic meaning of the annotation with refersTo attribute.

For example, the voting is recorded in a fragment of text in the debate called <summary>. Inside of the summary we have marked up <quantity> and inside of the <voting> metadata we connect the quantities with the respective legal meaning inside of the voting event: 72 votes are “ayes” and 34 votes are “noes” using the @refersTo attribute connected with a TLCConcept. Before the voting event the

<quorum> was checked. Because we have different graduation of quorum, refersTo expresses the type of quorum defined in the TLConcept (e.g. majority). After the voting a recount occurred and the positive votes are 76.

parliamentary

<parliamentary> <quorumVerification> <quorum eId="quorum_1" refersTo="#majority" value="80"/> <count eId="count_1" refersTo="#present" href="#quantity_1" value="110"/> </quorumVerification> <voting eId="voting_1" href="#summary_1" refersTo="#voting" outcome="#approved"> <quorum eId="voting_1__quorum_1" refersTo="#majority" value="80"/> <count eId="voting_1__count_2" refersTo="#ayes" href="#quantity_2" value="72"/> <count eId="voting_1__count_3" refersTo="#noes" href="#quantity_3" value="34"/> </voting> <recount eId="recount_1" href="#dbsect_2" refersTo="#recount" outcome="#approved"> <count eId="recount_1__count_1" refersTo="#ayes" href="#quantity_4" value="76"/> </recount> </parliamentary> --- in the text --<debateSection eId=”dbsect_2” name=”…”> <summary eId="summary_1">(Question carried by <quantity eId="quantity_2" normalized="72" refersTo="#ayes">72</quantity> to <quantity normalized="34" eId ="quantity_3" refersTo="#noes"> 34</quantity> votes)</summary> </debateSection>

5.10.7 mappings

The mappings block records the history of the modifications of the original wId over time. <mappings> supplies a place where to record the fact that changes in IDs do not happen only when a renumbering occurs, but also whenever this expression is not the master expression of the document, i.e., whenever eIds and wIds diverge. The attribute @original stores the first wId, that never evolves, @current stores the eId of the expression valid in a given temporal period. The attributes @start and @end link the temporal data.

mappings	<mappings source="#palmirani"> <mapping eId="mapping_1" original="#art_1" current="#art_4" start="#t_1" end="#t_3"/> <mapping eId="mapping_2" original="#art_1" current="#art_7" start="#_t4" end="#t_7"/> </mappings>

5.10.8 otherReferences

Sometime there is the need to annotate implicit references that connect one part of the text with other legal sources, including other fragments of text within the same document. For example, a semantic implicit reference is used between the recital and the body of a European Directive. In order to capture this relationship, we use the <otherReferences> element.Content model of <otherReferences> in the <analysis> section of the metadata contains <implicitReference> and <alternativeReference> elements, to stress that they can be used for expressing either a legal reference not explicitly mentioned in the text, or alternative syntaxes for the URI specified in the actual reference.

otherReferences	<otherReferences source="#FV-MP"> <alternativeReference for="#ref12" refersTo="#ELI" href=" http://www.legislation.gov.uk/id/ukpga/2014/27/enacted/"/> <implicitReference for="#ref_10" href="/akn/uk/act/2000-07-28/chapter23/main#sec_12__subsec_7"/> </otherReferences>

5.10.9 otherAnalysis

Sometimes there is the need to express another legal analysis not yet included in Akoma Ntoso. Each institution can use this container for defining this additional legal metadata. The following examples, coming from the Library of Congress of Chile, show the metadata used for classifying specific RDF classes.

otherAnalysis

5.10.10 TemporalData

The temporalData describes all the events grouped together in order to model intervals. In the following example we find the <temporalGroup> that models the interval of enter into force and the interval of efficacy. The @refersTo attribute connects the temporal parameters with the TLConcept defined in the references block.

temporalData	<temporalData source="#oasis"> <temporalGroup eId="temporalGroup_1"> <timeInterval refersTo="#inforce" start="eef_1" end="eref_2"/> <timeInterval refersTo="#efficacy" start="#ef_1" end="#ef_2"/> </temporalGroup> <temporalGroup eId="temporalGroup_2"> <timeInterval refersTo="#inforce" start="#ref_2"/> <timeInterval refersTo="#efficacy" start="#ref_2"/> </temporalGroup> </temporalData>

5.10.11 Notes

The note is a block where we record non-authorial notes. For the authorial notes we use <authorialNote> element which is an inline element. The authorial notes are provided by the author of the document and it is placed in the text. An example of authorial note is the side note (approved by the Assembly) or any note of the Parliament.

The attribute @placement specifies where to place the note (bottom, inline, left, right, side). The attribute @marker specifies the simple for marking the note. The attribute @placementBase provides a mechanism to specify exactly the placement of the note with regards to other elements of the document using a local href (i.e. a #id reference) to the element near which the note should be placed.

authorialNote	<paragraph><content><p><authorialNote marker="2" placement="side" placementBase="#sec_1__para_1"><p>this is a authorial note approved by the Parliament</p></authorialNote> </paragraph>

Any other editorial annotation is included in the tag <note> in the <meta> block.

notes	<notes source="#palmirani"> <note eId="note_1"> <p> Some footnotes from editors. Non authorial note.</p> </note> </notes>

5.10.12 Ontological references

5.10.12.1 References

The reference block models all the references with other documents or with ontology classes (Top Level Classes – TLC). The active references are the normative modifications from the current document to external documents, while the passive references are the external documents that point out the current document because they modify the current document. <original>: it is the original expression of the Work; <activeRef>: it is any external document that is modified by the current document; <passiveRef>: it is any external document that affects the current document; <attachmentOf>: it is the reference to the main document where the current document is the attachment <hasAttachment>: it is the reference to any attachment of the current document; <jurisprudence>: it is any reference to relevant case-law; <TLCReference>: it is any reference to an ontological class.

references

5.10.13 Additional annotation

5.10.13.1 Proprietary

The proprietary block allows for the addition of any other local tags which are useful for managing legacy systems.

proprietary	<proprietary source="#oasis"> <my:tag> any tag useful for the local document management</my:tag> </proprietary>

Akoma Ntoso makes no restriction as to the vocabulary or containment constraints of the content within the proprietary block. The only requirement (as shown by the compliant fragment) is that all elements belong to namespaces different than that of Akoma Ntoso. This guarantees the immediate identification of the new elements.

Proprietary elements can still use existing core Akoma Ntoso attributes and, whenever possible, should. In particular, the following attributes should be used whenever possible:

@eId: an identification word unique within the whole document
@refersTo: the id of an ontological concept, person, organization, location etc. defined in the reference section of the metadata.
@href: the address of another document, or the id of a section of the document referenced by the individual metadata element.
@source: the id of a person or organization (placed in the reference section) providing the metadata element.

5.10.13.2 Presentation

The presentation block allows for tags and specifications that facilitate the visual rendering of the document (e.g. specifications on the paper format, or the numbering of the lines, etc.). For advanced specifications see also 5.6 and 5.7.

presentation

Example from UK <presentation source="#palmirani"> <my:oddPageHeading> <my:left class="normal"> Legislation Publication Ordinance</my:left> <my:right class="normal"> CAP. 614 </my:right> </my:oddPageHeading> <my:oddPageFooter> <my:left class="normal"> Authorized Loose-left and Printed and Published </my:left> <my:right class="normal"> Issue 47</my:right> </my:oddPageFooter> </presentation> Example from Federal Chancellor of Switzerland: <proprietary source="#palmirani"> <ch:evenPageHeading> <ch:left class="two-third">Iniziativa popolare «Basta con la costruzione sfrenata di abitazioni secondarie!» DF</ch:left> <ch:right class="one-third">RU 2012</ch:right> </ch:evenPageHeading> </proprietary>

One of the main problems in the rendering of an XML file is preserving the format over time by providing enough information to process the document in the future in a similar manner. In the following example we specify the URL where to get the CSS as well as the hash code of the CSS in order to be sure that the CSS is not modified over time.

presentation	<presentation source="#palmirani"> <uy:myCssForRendering>http://europe.eu/akomantoso30.css</uy:m yCssForPreservation> <uy:myCssHash>d7402662a7a744c0b3689dc863e91761</uy:myCs sHash> </presentation>

The following Indian example shows an example where it is necessary specific presentation instructions5:

5[12. Cognizance and trial of offences. -- (1) No court inferior to that of a Metropolitan Magistrate or a Judicial Magistrate of the first class shall try any offence punishable under this Act. (2) No court shall take cognizance of an offence punishable under this Act except upon— (a) its own knowledge or upon a complaint made by the appropriate Government or an officer authorized by it in this behalf; or (b) a complaint made by the person aggrieved by the offence or by any recognized welfare institution or organization. Explanation. –For the purposes of this sub-section “recognized welfare institution or organization” means a social welfare organization or institution recognized in this behalf by the Central or State Government.] 5. Substituted by Act 49 of 1987, S.4.

The fragment of the following XML snippet shows how to manage the situation using CSS instructions: :

<akomaNtoso xmlns="`http://docs.oasis-open.org/legaldocml/ns/akn/3.0/WD16`" xmlns:x="http://www.fabioVitali.com">

5 http://pblabour.gov.in/pdf/acts_rules/equal_remuneration_act_1976.pdf

<presentation source="#FV"> <x:css> .removed::before { content: "["; } .removed::after { content: "]" ; } noteRef { vertical-align: super; font-size: 80%; } </x:css> </presentation>

This XML fragment shows the <presentation> block where a x namespace is defined and an element <x:css> is defined for including CSS presentation instructions. In particular, this fragment of CSS wraps the text between two square brackets.

5.11 Table

A table can be included in any type of document. A table element uses the same element children of the HTML table model. It includes also the attribute: border, width, cellpadding, cellspacing, title. Caption element is possible and the content model of the <td> element permits including blocks elements such as block, blockContainer, blockList, tblock. This permits modelling particular tables, like the following example, where the amendments are included directly in the table. The corresponding XML code is following:

<table eId="table_1" cellpadding="10" border="1" cellspacing="0" width="100" title="LAWS AMENDED OR REPEALED" > <caption>LAWS AMENDED OR REPEALED</caption> <tr> <th> No. and year of law </th> <th> Short title </th> <th> Extent of amendment or repeal </th> </tr> <tr> <td> Act No. 153 of 1993 </td> <td> Independent Broadcasting Act, 1993 </td> <td> <td> <blockList eId="table_1__list_1"> <item eId="table_1__list_1__item_1"> <num>1.</num> <blockList eId="table_1__list_1__item_1__list_1"> <listIntroduction eId="table_1__list_1__item_1__list_1__intro">The amendment of section 1 by the substitution for the definitions of ‘‘Authority’’, ‘‘chairperson’’, ‘‘Council’’ and ‘‘councillor’’ of the following definitions, respectively:</listIntroduction> <item eId="table_1__list_1__item_1__list_1__item_a"> <num>(a)</num> ‘‘<mod eId="table_1__list_1__item_1__list_1__item_a__mod_1"> <quotedStructure eId="table_1__list_1__item_1__list_1__item_a__mod_1__qstr_1"> <point eId="table_1__list_1__item_1__list_1__item_a__mod_1__qstr_1__point_a"> <content> ‘Authority’ means the Independent Communications Authority of South Africa established by section 3 of the Independent Communications Authority of South Africa Act, 2000; </content> </point> </quotedStructure>’’;</mod></item> <blockList> </item> </blockList> </td> </tr> </table>

Another use for the table is the application form, where some parts are dedicated to filling parts of the form. Sometime these application forms are schedules of law, regulations, or bills, like the following example.

It is possible with Akoma Ntoso to capture the blank part that permits an easy transformation of the template in an online web application form.

<table eId="table_1"> <tr> <td>At</td> <td><fillin>............................</fillin></td> <td>on this</td> <td><fillin>............................</fillin></td> <td>day of</td> <td><fillin>............................</fillin></td> <td>19</td> <td><fillin>............................</fillin></td> </tr> <tr> <td>G.H.,Magistrate.</td> </tr> </table>

It is also possible to model very complex tables that includes images or irregular cells. We use colspan attribute with the same meaning of HTML.

<paragraph eId="sec_2-5-7__para_4"> <content eId="sec_2-5-7__para_4__content"> <table eId="table_1" border="1"> <caption eId="table_1__caption">Thermoplastic rooflights and light fittings with diffusers</caption> <tr> <th> </th> <th> Protected zone or fire-fighting shaft </th> <th colspan="2"> Unprotected zone or protected enclosure </th> <th colspan="2"> Room </th> </tr> <tr> <th> Classification of lower surface </th> <th> Any thermoplastic </th> <th> TP(a) rigid </th> <th> TP(a) flexible and TP(b) </th> <th> TP(a) rigid </th> <th> TP(a) flexible and TP(b) </th> </tr> </table> </content> </paragraph>

Or including forms and images:

<preface> <docTitle>Form XV Public Service Vehicle Licence original REPUBLIC OF KENYA THE TRAFFIC ACT</docTitle> </preface> <mainBody> <container eId="container_1" class="table" name="table"> (Section 97 (1)) <table eId="container_1 table_1"> <tr> <td> <img src="signalxv.jpg"/> </td> <td> <fillIn>Cheque No.............................</fillIn> <fillIn>Cash ................................</fillIn> </td> </tr> <tr> <td> STATION ......................................................................... ISSUING OFFICER ..................................................... </td> </tr>

Finally if you need to use structured caption the following XML fragment provides a correct solution for including it in table element:

<table> <caption> <span class="autoNum">Table 1</span> <subFlow name="structuredCaption"> <p>First line</p> <p>Second line</p> </subFlow> </caption> <tr> <th><p>Head 1</p></th> <th><p>Head 2</p></th> </tr> <tr> <td><p>Data 1</p></td> <td><p>Data 2</p></td> </tr> </table>

5.12 Akoma Ntoso alternative to represent a list

Three models can be used to represent a list

1. a list as a hierarchical container

the list is marked using the <list> element;
the list introduction is marked using <intro> and the list conclusion is marked using the <wrapUp> element.

Each item of the list is a hierarchical container (for example, point or indent)

Example :

<list eId="...__list_1" > <intro eId="...__list_1__intro" wId="2013-619260-2"> The Decisions referred to in Article 13(1) shall not impede the free movement in the Union and the production, manufacture, making available on the market including importation to the Union, transport, and exportation from the Union of new psychoactive substances: </intro> <point eId="...__list_1__point_a" wId="2013-619261"> <num>(a)</num> <content eId="...__list_1__point_a__content" wId="2013-619261-1"> for scientific research and development purposes; </content> </point> <point eId="...__list_1__point_b" wId="2013-619262"> <num>(b)</num> <content eId="...__list_1__point_b__content" wId="2013-619262-1"> for uses authorised under Union legislation; </content> </point> </list>

<blockList eId="...__list_1"> <listIntroduction eId="...__list_1__intro">The Commission conducted an impact assessment of policy alternatives, taking into account the consultation of interested parties and the results of external studies. The impact assessment concluded that the following solution would be preferred:</listIntroduction> <item eId="...__list_1__item_1"> <num>–</num> a more graduated and better targeted set of restriction measures on new psychoactive substances, which should not hinder the industrial use of substances. </item> <item eId="...__list_1__item_2"> <num>–</num> restriction measures should be introduced earlier and substances suspected to pose immediate public health risks should be subjected to temporary restrictions. </item> <listWrapUp eId="...__list_1__wrapup">finally we have …</listWrapUp> </blockList>

2. a list as a block

Each item of the list is marked using the <item> element. Example:

the list is marked using the <blockList>
the list introduction is marked using the <listIntroduction> element and the list conclusion is marked using the <listWrapUp> element.

3. a list as an HTML element

the list is marked using the <ol> element for ordered list or <ul> for unordered list
Each item of the list is marked using the <li> element.

Example:

<ul eId="...__ul_1"> <li eId="...__ul_1__li_1"> a more graduated and better targeted set of restriction measures on new psychoactive substances, which should not hinder the industrial use of substances. </li> <li eId="...__ul_1__li_2"> restriction measures should be introduced earlier and substances suspected to pose immediate public health risks should be subjected to temporary restrictions. </li> </ul>

5.13 Akoma Ntoso alternative to represent a set of provisions

Two models can be used to represent a set of provisions

<chapter eId=",,,__chp_I"> <num>CHAPTER I</num> <heading eId=",,,__chp_I__heading">Subject matter - Scope - Definitions</heading> <article eId="art_1"> <num>Article 1</num> <heading eId="art_1__heading">Subject matter and scope</heading> <paragraph eId="art_1__para_1"> <num>1.</num> <content eId="art_1__para_1__content"> This Regulation establishes rules for restrictions to the free movement of new psychoactive substances in the internal market. For that purpose it sets up a mechanism for information exchange on, risk assessment and submission to market restriction measures of new psychoactive substances at Union level. </content> </paragraph> ... </article> ... </chapter>

1. as a hierarchical container This is the model for the set of sections in the body of an act or a bill. Example:
1. as a block This is used for documents without a well-defined structure. Example:

<tblock eId="...__tblock_3"> <num>3.</num> <heading eId="...__tblock_3__heading">LEGAL ELEMENTS OF THE PROPOSAL</heading> <tblock eId="...__tblock_3.1"> <num>3.1.</num> <heading eId="...__tblock_3.1__heading">The legal base</heading> <p>The proposal aims at ensuring that trade in new psychoactive

substances having industrial and commercial uses is not hindered and that the functioning of this market is improved, while the health and safety of individuals are protected from harmful substances, which cause concern at the EU level.</p> </tblock> </tblock>

5.14 The element foreign

Akoma Ntoso does not provide markup for situations that are very specific and for which better suited vocabularies already exist. For instance, mathematical formulas and drawings have well-known standard XML vocabularies that should be used rather than inventing new ones. For these situations, the <foreign> element can be used to specify fragments of content that correspond to structures and data that are not currently managed by Akoma Ntoso.

For instance, the following is a valid Akoma Ntoso fragment to show the equation ax2+bx+c:

<foreign> <math xmlns="http://www.w3.org/1998/Math/MathML"> mrow> <mi>a</mi> <mo>⁢</mo> <msup> <mi>x</mi> <mn>2</mn> </msup> <mo>+</mo> <mi>b</mi> <mo>⁢</mo> <mi>x</mi> <mo>+</mo> <mi>c</mi> </mrow> </math> </foreign>

The <foreign> element is a block-level element. This means that it is presumed that its content appears in a vertically isolated block. Furthermore, only fully qualified XML fragments can appear within the <foreign> element, and they must belong to different namespaces than Akoma Ntoso’s. Finally, it should be noted that <foreign> should only be used when Akoma Ntoso does not provide support for the notation rather than to simply include XML fragments from other vocabularies. Thus, it is not appropriate to place HTML fragments within a <foreign> element as there is no feature of HTML that cannot be expressed in Akoma Ntoso. In general, you cannot use elements from a foreign namespace for elements for which a correspondence in Akoma Ntoso exists.

5.1 An introduction to document types​

5.2 The basic structure of Akoma Ntoso XML resources​

5.3 An introduction to generic elements​

5.4 An introduction to borrowed HTML elements​

5.5 An introduction to shared elements​

5.6 Attributes for managing the presentation​

5.7 Modifications and versioning​

5.8 References​

5.8.1 The structure of references​

5.8.2 Referring to precise concepts in the document​

5.8.3 Referring to legal sources​

5.9 Metadata​

5.9.1 Identification​

1. the country,​

2. the type of the document,​

3. the date of the document and, where applicable, also the version,​

4. the main language, and also​

5.9.1.1 Preservation​

5.9.2 Publication​

5.9.3 Classification​

5.9.4 Lifecycle​

5.9.5 Workflow​

5.10 Analytical metadata​

5.10.1 Analysis​

5.10.2 activeModifications​

5.10.3 passiveModifications​

5.10.4 restrictions​

5.10.5 judicial​

5.10.6 parliamentary​

5.10.7 mappings​

5.10.8 otherReferences​

5.10.9 otherAnalysis​

5.10.10 TemporalData​

5.10.11 Notes​

5.10.12 Ontological references​

5.10.12.1 References​

5.10.13 Additional annotation​

5.10.13.1 Proprietary​

5.10.13.2 Presentation​

5.11 Table​

Or including forms and images:​

5.12 Akoma Ntoso alternative to represent a list​

1. a list as a hierarchical container​

2. a list as a block​

3. a list as an HTML element​

5.13 Akoma Ntoso alternative to represent a set of provisions​

5.14 The element foreign​