Source: http://docs.oasis-open.org/legaldocml/akn-nc/v1.0/csprd03/akn-nc-v1.0-csprd03.html
Timestamp: 2019-04-25 23:49:17+00:00

Document:
Véronique Parisse (V.PARISSE@aubay.lu), Aubay S.A.
o Akoma Ntoso Version 1.0 Part 1: XML Vocabulary. http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd03/part1-vocabulary/akn-core-v1.0-csprd03-part1-vocabulary.html.
o Akoma Ntoso Version 1.0 Part 2: Specifications. http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd03/part2-specs/akn-core-v1.0-csprd03-part2-specs.html.
o Akoma Ntoso Version 1.0 XML schemas. http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd03/part2-specs/schemas/.
o Akoma Ntoso Version 1.0 XML examples. http://docs.oasis-open.org/legaldocml/akn-core/v1.0/csprd03/part2-specs/examples/.
· Akomo Ntoso: XML for parliamentary, legislative & judiciary documents. http://www.akomantoso.org.
This document provides the naming convention for defining IRIs and ids related to the Akoma Ntoso XML standard. Within the schema of Akoma Ntoso, id attributes are declared as optional, but whenever attributes eId and wId are actually used the specifications in this document are mandatory.
This document was last revised or approved by the OASIS LegalDocumentML TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document. Any other numbered Versions and other technical work produced by the Technical Committee (TC) are listed at https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legaldocml#technical.
TC members should send comments on this specification to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the TC’s web page at https://www.oasis-open.org/committees/legaldocml/.
This Committee Specification Public Review Draft is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/legaldocml/ipr.php).
Akoma Ntoso Naming Convention Version 1.0. Edited by Fabio Vitali, Monica Palmirani, and Véronique Parisse. 05 April 2017. OASIS Committee Specification Draft 03 / Public Review Draft 03. http://docs.oasis-open.org/legaldocml/akn-nc/v1.0/csprd03/akn-nc-v1.0-csprd03.html. Latest version: http://docs.oasis-open.org/legaldocml/akn-nc/v1.0/akn-nc-v1.0.html.
This Committee Specification Public Review Draft is provided under the RF on Limited Terms Mode of the OASIS IPR Policy, the mode chosen when the Technical Committee was established.
For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the TC’s web page (https://www.oasis-open.org/committees/legaldocml/ipr.php).
[IRI] International Resource Identifiers as per RFC 3987 (http://tools.ietf.org/html/rfc3987).
[ISO639-2] ISO 639-2 alpha-3. (http://www.loc.gov/standards/iso639-2/).
[FRBR] Functional requirements for bibliographic records: final report / IFLA Study Group on the Functional Requirements for Bibliographic Records. — München: K.G. Saur, 1998. — viii, 136 p. — (UBCIM publications; new series, vol. 19). — ISBN 978-3-598-11382-6. http://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf.
The present specification defines the naming convention that needs to be implemented in order to conform to the second level of compliance with the Akoma Ntoso schema.
In this specification, when MUST is used in the text, it MUST be understood as “in order to conform to level 2 of compliance with the Akoma Ntoso schema” (see section 6).
In HTML, the primary link type is anchor-to-document, while anchor-to-anchor links are a minor addition for uncharacteristic cases. For this reason identifiers are never required: authors are expected to provide identifiers only for those structures that are likely destinations of anchor-to-anchor links – often just a few section headings.
In legislation, on the other hand, ALL references are to a precise substructure of a highly hierarchical document flow, and any substructure may become a destination. This is the reason why identifiers are useful for most structures of a legislative document.
Additionally, in HTML the reference is usually meant for navigation by human users. It is only necessary to come close enough to the intended destination that a human eye can scan the surrounding text or elements and find the exact destination in the vicinity.
In legislation, there is an additional type of reference, “modification”. Modifications require that a specific substructure be precisely identified and modified by a modification instruction. In this case, one cannot be satisfied with the fact that the intended destination is somewhat near the arrived destination -- they must coincide.
By using the layering provided by the Functional Requirements for Bibliographic Records (FRBR) (See Section 4.1), Akoma Ntoso strongly differentiates between the legislative context and the markup used to represent it. References are legislative concepts, and exist regardless of whether they exist in the markup. The same content, for instance, could be represented in a number of different XML files created by various authors. They would all be distinct manifestations of the same Expression, each of which may have the same body, but different markup choices, metadata, commentary, etc. References would need to work regardless of the specific Manifestation chosen as the destination, and, indeed, it is important that all manifestations use the same identifiers for the same structures, standardized by the LegalDocML Technical Committee. This is affected by the fact that an author may not even have the document of the destination, or that it may not even exist yet (time-based alchemies frequently occur in legislation, one might need to create links to documents that have yet to be converted into Akoma Ntoso, etc.). Thus, providing a forced and precise syntax for identifiers is the best guarantee that all different manifestations of the same content have the same identifiers and that one does not need to read an XML file to divine the values of its identifiers.
Legal references have peculiar traits regarding time. For instance, in the case of an evolving document (e.g., a piece of legislation receiving references and being actively modified by the legislator), the actual destination of the reference is neither the original version, nor the current version, but in many cases the version of the document that was valid at the moment in time when the case took place. References are dynamic rather than static, because the destination moves in time and jurisdiction according to the needs rather than being fixed to a specific sentence or fragment. This means that point-in-time consolidation is an important affair, and that determining the destination of a dynamic link requires, at the very least, that structures existing in multiple versions are named consistently. For example, it must be clear that, if section 35 of the initial version of a title of a U.S. code had some identifier y, then ALL subsequent versions of that same section 35 (even after a renumbering action) have the same identifier y, so that once you determine the needed version, arriving at the right structure is easy and straightforward.
The syntax of identifiers is defined to ensure that identifiers can be used regardless of the versions of the same document, regardless of the author of individual XML markups, regardless of usage of navigational or modification references, and knowing full well that point-to-point references are the norm rather than the exception.
The Akoma Ntoso naming convention does not assume that the document is stored in Akoma Ntoso XML, but only that there is a mapping between the FRBR IRI reference and the URL of a file stored somewhere on the Internet, and to which our reference can be resolved into.
In the case of identifiers, the Akoma Ntoso naming convention does not assume, yet again, that the document is stored in Akoma Ntoso XML, but only that identifiers work in whatever format has been used. This means that any XML-based language, including Akoma Ntoso, HTML, TEI, DocBook, ePub, kf8, or Mobi are acceptable and can make use of the Naming Convention presented here.
The Akoma Ntoso Naming convention also assumes that it is the job of the author of the linked-to document to use identifiers that are consistent with the naming convention. This is necessary because, in HTTP, the fragment identifier is never sent with the request and is only known and handled by the user agent, so we must assume that identifiers are present in the response and have the correct form. In particular, it would make no sense to convert all fragment identifiers in references using the syntax of the destination documents, as these syntaxes can be quite innumerable.
Identifiers are the main way Akoma Ntoso identifies fragments and parts of the document in an unambiguous form. They can be used in document references (e.g., links and amendment commands) as a precise pointer to the actual part of the document mentioned (as opposed to simply referring to a document as a whole).
Identifiers are systematically used in Akoma Ntoso. All Akoma Ntoso elements allow up to three identifiers. Even internal links need to use identifiers. Most relevant elements and sections require at least one identifier.
1. MEANINGFULNESS: the name is a meaningful and logical description of the resource and not of its physical path.
2. PERMANENCE: the name must be permanent and stable over time.
3. 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.
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.
2. The list of attachments and schedules belong to a specific Expression, so references to ExpressionComponents are specific to the Expression-level.
3. 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 IRI of the ManifestationComponents must be used to refer to all components including the main document, all attachments, and all schedules.
4. Multimedia fragments within an XML Manifestation (e.g., a drawing, a schema, or a map.) do not exist as independent ExpressionComponents as they are only a part of some ExpressionComponent (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 ManifestationComponent 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.
5. 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.
6. 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 References section using internal (and not standardized) identifiers; the second step ties the item in the reference section to the actual concept through the IRI of the concept as specified in this Naming Convention.
Since the most primary concepts in Akoma Ntoso are connected to documents, the main part of this section is devoted to detailing the 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 an IRI-based naming mechanism for non-document entities (as well as for document entities when they are handled in a similar way to non-document entities).
The Akoma Ntoso standard defines a number of referenceable concepts that are used in many situations in the lifecycle of legal documents.
b) a set of requirements for other naming conventions to be usable within Akoma Ntoso XML resources in a proper way (Functionally Equivalent Naming Conventions see 4.12).
(a) Work – the abstract concept of the legal resource (e.g., act 3 of 2015).
(b) Expression - any version of the Work whose content is specified and different from others for any reason: language, versions, etc. (e.g., act 3 of 2015 as in the version following the amendments entered into force on July 3rd, 2016).
(c) Manifestation - any electronic or physical format of the Expression: MS Word, Open Office, XML, TIFF, PDF, etc. (e.g., PDF representation of act 3 of 2015 as in the version following the amendments entered into force on July 3rd, 2016).
(d) Item – the physical copy of any Manifestation in the form of a file stored somewhere in some computer on the network or disconnected (e.g., the file called act32015.pdf on my computer containing a PDF representation of act 3, 2015 as in the version following the amendments entered into force on July 3rd, 2016).
· WorkComponents (e.g., main, schedule, annexes, table) - the WorkComponents are abstract entities that can be referenced to refer to different ExpressionComponents in time.
· ExpressionComponent (e.g., main, schedule, annexes, or table.) - the ExpressionComponents represent the visible division of the document as generated by the content author (Parliament, etc.) for a specific Expression of the Work.
· ManifestationComponent (e.g., xml files, PDF files, or TIFF images.) - the ManifestationComponents represent the division of the document as generated by the Manifestation author (e.g., the XML editor) for a specific Manifestation of a specific Expression.
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).
At all levels, the Akoma Ntoso IRIs belong to the http:// scheme and are normally resolved using mechanisms widely available in browsers and web servers. Within documents, IRIs are used as references to addressable resources, and are thus called IRI references.
According to the authoritative source RFC 3986, all http:// IRI references are divided into absolute IRI and relative IRI references. An absolute IRI starts with the string “http://”, which is then followed by an officially registered domain name, and the local part that starts off the first individual “/” character. A relative reference, on the other hand, has no indication of the scheme, no indication of the domain name, and may have further missing parts at the beginning of the whole string (no missing parts on the end, though). Browsers are able to build the absolute IRI corresponding to the relative IRI by adding at the beginning of the provided IRI the missing parts that are taken from the IRI of a base resource.
In XML manifestations of Akoma Ntoso documents, IRI references are always expressed in relative forms.
This implies that any resolution is carried out by the source of the base document (e.g., the one where the IRI reference is stored). This makes all IRIs independent of the actual resolution mechanism, and allows for very flexible storage, access, and reference mechanisms. This means that all resolution mechanisms used to access an Akoma Ntoso document from another Akoma Ntoso document will rely on the same resolution mechanism as the original one, regardless of the resolution mechanism employed to generate the documents themselves. In case the hosting document lacks a base IRI, it is the responsibility of the active application to provide a base IRI in its stead.
Since it is a requirement of Akoma Ntoso that all existing FRBR items of a Manifestation are byte-per-byte identical to each other, it is a natural consequence that it is not abstractly relevant which resolution engine dereferences the actual Item whose IRI is resolved out of a Work-level, an Expression-level, or a Manifestation-level IRI reference. This, in practice, means that protocol and authority are not contributing information to the resolution, and are thus interchangeable. Parties interested in absolute IRIs for Akoma Ntoso are required to produce their own resolution engine and use its protocol and authority for the purpose.
Another distinction is between global and local IRI references. A global IRI reference is a relative IRI reference where all parts are present except for protocol and authority (i.e., domain name). Thus, a global IRI reference always starts with a slash, to indicate that all other parts are explicitly specified. A local IRI reference, on the other hand, may have one or more parts missing (necessarily from left to right), and the corresponding global (and, subsequently, absolute) IRI reference is determined by adding the corresponding parts taken from the base document, as usual with relative IRI references with missing parts. In the following we will call all IRI references as simply IRI (they are all references, after all), and distinguish between absolute IRIs, global IRIs and local IRIs.
In XML manifestations of Akoma Ntoso documents, all Work, Expression, and Manifestation-level references to whole documents must be global, and all references to individual components within the same level (or lower levels) must be local and are stored simply as the name of the corresponding component.
Thus, for instance, "/akn/kn/act/2015-01-01/1/!schedule_1" is the relative, global Work-level IRI for schedule 1 of act 1/2007 of Kenya. However, a Work-level reference to schedule 1 placed within the main document of the act will only contain the local IRI "1/!schedule1". This guarantees that these references continue to work even after new expressions are created of the same Work, either if the part containing the reference is changed or if it remains untouched.
Akoma Ntoso XML elements refer to other documents according to different levels of the FRBR hierarchy. In particular, <ref>, <mref>, and <rref> point to Work-level and occasionally Expression-level IRIs only, while <object>, <img>, and <attachment> always point to Manifestation-level IRIs. As the global/local distinction is involved, <ref>, <mref>, and <rref> elements always use global IRIs for documents different than the host, while <img> or <attachment> always refer to components of the host document, and thus always use local references.
This means that whenever referring to a different document it is necessary to provide the full list of identification parts even when they are identical to the ones of the base document. On the other hand, local IRI references are used in the Akoma Ntoso naming convention for references to components or fragments, and implicitly make use of the identification parts of the base document for the correct resolution of the IRI reference.
Global IRI references are discussed in sections 4.4 through 4.8, while local IRI references are discussed in section 4.9.
The Akoma Ntoso naming architecture is built so as not to rely on the existence of a single storage architecture, since the IRIs stored within documents are differentiated from the ones physically representing the resource being sought.
The mapping from architecture-independent IRIs into accessible architecture-dependent URLs (representing the best Item for the document being sought) is realized through specific applications called IRI resolvers. The Akoma Ntoso naming architecture is built so as not to rely on the existence of any individual IRI resolver, but assumes that all IRIs are always correctly resolved to the best available Item regardless of the resolving mechanisms. In fact, each naming authority is given the global task of resolving any possible Akoma Ntoso IRIs, regardless of whether it belongs or not to the country or countries managed by the naming authority. This implies that the authority-specific details of IRIs are purposefully omitted in this specification, and need to be considered only when first accessing a document.
For this reason, all IRIs in this specification are prefixed with the arbitrary domain name [http://www.authority.org] that stands for any of an arbitrarily large number of equivalent naming authorities.
The IRI reference for the Work is the baseline for building the IRI reference for the Expression (section 4.5), which is the baseline for the IRI reference of the Manifestation (section 4.6). Additionally, all IRI references can be enriched with information about the component and the fragment requested (section 4.8). IRI references for items are beyond the scope of this Naming Convention.
· The base URL of a naming authority with IRI-resolving capabilities (not relevant for the Naming Convention). In all our examples this will always be described as [http://www.authority.org], as explained in section 4.3.
– Any specification of document subtype, if appropriate. For an Akoma Ntoso XML representation, this value MUST correspond to the content of the element <FRBRsubtype> in the metadata or, in its absence, to the “name” attribute of the document type (optional).
– The emanating actor, unless implicitly deducible by the document type (e.g., acts and bills do not usually require actor, while ministerial decrees and European legislation do). For an Akoma Ntoso XML representation, this value MUST correspond to the content of the element <FRBRauthor> in the <FRBRWork> section of the metadata (optional).
– Original creation date (expressed in YYYY-MM-DD format or just YYYY if the year is sufficient for identification purposes). For an Akoma Ntoso XML representation, this value MUST correspond to the content of the element <FRBRdate> in the <FRBRWork> section of the metadata (required).
– Number or title or other disambiguating feature of the Work (when appropriate, otherwise optionally the string nn). For an Akoma Ntoso XML representation, this value MUST correspond to the content of element <FRBRnumber> or <FRBRname>, respectively, in the metadata (required when necessary for disambiguation, optional otherwise).
Algerian parliamentary debate record, 21st December 2004.
Sierra Leone enacted Legislation. Act number 2 of 2004.
FAO standard CODEXSTAN33-1981 of 1981.
Characterizing the Expression is the specific identification of the features of the content. This includes specifications of the version and the language of the Expression. Therefore, different versions of the same Work, or the same version of the same Work expressed in different languages correspond to different Expressions and will have different IRIs. Expressions are organized in components (the ExpressionComponents), and therefore we need to identify separately the Expression as a whole from the individual IRIs for each ExpressionComponent. All of them are all immediately derived from the baseline, which is the IRI for the Work.
- If an approved act, the version date of the Expression in syntax YYYY-MM-DD. For an Akoma Ntoso XML representation, this value MUST correspond to the content of element <FRBRdate> in the <FRBRExpression> section of the metadata. If appropriate, the date can be integrated with a time using values for the XSD:dataTime datatype: Thh:mm:ss±hh:mm. The difference between the local time and Coordinated Universal Time (UTC) is specified using the sign + or - followed by the difference from UTC represented as hh:mm (note: the minutes part is required). See ISO 8601 Date and Time Formats and XML Schema Part 2: Datatypes (http://www.w3.org/TR/xmlschema-2/).
· Any content-specification date (as opposed to validity dates) (optional).
· Any content authoring information to determine the authoriality of the text content (optional). This is separate and independent of the authoring information relative to the metadata and markup, which are among the features of the Manifestation (optional). For an Akoma Ntoso XML representation, this value MUST correspond to the content of element <FRBRauthor> in the <FRBRExpression> section of the metadata.
- If the document is not versioned (e.g., the debate record of an assembly) then version identifier need not and cannot be present.
- If the document is versioned (e.g., an act in force), then the lack of version identifiers refers to the version in force at the moment of the resolution of the IRI (i.e., the “current” version of the act, where “current” refers to the moment in time in which the IRI is dereferenced, rather than the moment in time in which the document containing the IRI was created: today for the reader, as opposed to today for the author of the references).
A particular Expression is the first version of a Work. This Expression should not be confused with the Work itself (which considers the first Expression in no special way to all other possible expressions), and it is a very specific, although peculiar, Expression. The first version of an Expression is referred to with an IRI with a dangling "@" character (which implies that the actual version date is the first appropriate date for that Work).
Algerian parliamentary debate record, 21st December 2004, French version, with nn optional undefined number.
Uruguay bill. Number 137-2005, at 2005-04-04. Spanish version, as amended on May 2nd, 2005, at 10.30 Montevideo time.
Madagascar. Act 3 from 2003, current version (as accessed today [according to the reader]) in multilingual text (in this case, French and Malagasy).
Sierra Leone enacted Legislation. Act number 2 of 2004. English version, as amended on July 2004. Official version. Emitted by publisher body.
Proposal for an European directive of the Council – English variant, version “final/2”.
Act of Uruguay n. 18331 in the version of 2009, Dec 12, with a retroactive modification happened in 2010.
1. The information is not known by the author of the reference (e.g., the legislator), in which case the act of actually retrieving the correct information is in itself an act of interpretation.
2. The information is not known by the editor of the text containing the reference (e.g., the publisher of the XML version of the document), in which case the information can theoretically be available, but is too much of a burden for the publisher to retrieve it.
3. The information is not known by the query system when evaluating the reference.
In these cases, the syntax for the IRI of the virtual Expression uses a similar syntax to the specification of the actual Expression, but the character “:” is used before each unknown value and instead of the “@” at the end of the specification of the Work-level IRI. For instance, if we need to reference the Expression of an act in force on date “1/1/2007”, we will probably need to refer to some Expression whose enter in force date was in a previous date to 1/1/2007.
Similarly, if we need to refer dynamically to the expressions in German of a specific act, we need to make a virtual reference whose date is left unspecified, and the language is forced to be German, as follows (deu is SO 639-2 alpha-3 code for German).
Swiss enacted Legislation. Act number 432 of 2009. Dynamic reference to any of the German versions.
Italian enacted Legislation. Act number 82 of 2005-03-07. Dynamic reference to any of the Italian versions valid within the interval January 1st 2010 to December, 31st 2015.
Characterizing the Manifestation is the specific process that generates an electronic document in a specific format. This includes specifications of the data format used. Therefore, different Manifestations of the same Expression generated in different data formats will have different IRI references.
All of them are all immediately derived from the baseline, which is the IRI for the Expression.
- The markup authoring information (useful to determine the authoritativeness of the markup and metadata) (optional). For an Akoma Ntoso XML representation, this value MUST correspond to the content of element <FRBRauthor> in the <FRBRManifestation> section of the metadata.
- Any relevant markup-specific date (optional). For an Akoma Ntoso XML representation, this value MUST correspond to the content of element <FRBRdate> in the <FRBRManifestation> section of the metadata.
- A unique three or four letter extension signifying the data format in which the Manifestation is drafted (required). For instance, such extension can be “pdf” for PDF, “doc” or “docx” for MS Word, “htm” or “html” for HTML “xml” for an XML Manifestation, or “akn” for the package of all documents including XML versions of the main document(s) according to the Akoma Ntoso vocabulary. For an Akoma Ntoso XML representation, this value MUST correspond to the content of element <FRBRformat> in the <FRBRManifestation> section of the metadata.
Package of all documents in Akoma Ntoso XML of the Sierra Leone act number 2 of 2004. English version, as amended in July 7th 2004.
Package of all documents including XML versions of the Sierra Leone enacted Legislation. Act number 2 of 2004. English version, as amended in July 2004. Rendered in Akoma Ntoso by CIRSFID on 15 July 2011.
Referring to within-documents destination is possible by adding to a whole-document reference an additional item pointing to the specific destination. Within this specification we distinguish between components and portions.
Some documents are made of many components; some are only composed of a main document. Within each component, structured portions can be localized and referred to by means of identifying information. Legal citations often point to a specific portions of the abstract document, as in “Article 3 of Directive 2003/87/EC”.
In order to explicitly refer to individual components and portions, it is therefore necessary to introduce a naming convention that identifies them, and allows an easy connection between the component and the document it belongs to.
Components and portions are a way to organize content. As such, they are naturally Expression-level concepts, which is where content is actually expressed and structured. Yet, it is sometimes appropriate to refer to components and portions in Work-level references, and therefore a syntax for these situations is provided. For instance, consider an original act that refers to table A of schedule 1. After a little time, schedule 1 is completely abrogated and table A thus becomes (implicitly) an attachment of the main document. As such, it is important that all references to table A of schedule 1 are considered as references to table A of the main document after that event. This brings about the necessity to have IRIs for Work Components. These are to be used when referring in a Work-level style to components that have official names and positions, but may change in name and position with time.
Components and portions are specified at the end of the IRI for Work-level and Expression-level references, and just before the data format for Manifestation-level references. They are introduced by a special character to separate the parts of the IRI reference identifying the document as a whole from the parts identifying the component and/or portion.
– A unique name for the attachment, optionally followed by the number associated to this component in the document. If this number is provided, it is separated from the name with “_”.
In order to allow the specification of the data format of a Manifestation to be the last item of the IRI as usual in web addresses, Manifestation-level IRI references are built differently than Work-level and Expression-level IRI references.
o A unique name for the attachment, optionally followed by the number associated to this component in the document. If this number is provided, it is separated from the name with “_”.
Italian bill number C245 as of 2004-02-13, second version, official expression, manifestation released on 2004-02-15 by publisher in pdf format.
A frequent situation occurs when an attachment has itself further attachments. This creates a complex hierarchical situation in which the component should be considered, in a way, as a document by itself, composed of components which need to be listed and properly differentiated. The process is further iterated whenever its attachments also have further attachments and so on. The situation must also foresee the situation in which attachments at different levels of the hierarchy end up having the same name (e.g., table A in schedule 1 and table A in schedule 2).
- If the component does not have attachments, its IRI reference is determined as detailed in the previous sections, without further additions.
- If the component has attachments, the IRI reference detailed in the previous sections is meant to refer to the component as a whole, including its attachments.
- To refer to the main document of a component that has further attachments, an additional “/main” part is specified.
- To refer to any further attachment of component, a further “/” followed by a unique name for the attachment is added.
Attachment “schedule01” of the Sierra Leone Act number 2 of 2004. English version, as amended on July 21st, 2004.
Main component of the attachment “schedule01” of Sierra Leone Act number 2 of 2004, English version, as amended on July 21st, 2004.
Attachment “Table A” of attachment “schedule01” of Sierra Leone act number 2 of 2004, English version, as amended on July 21st, 2004.
Annex 1 of the proposal for a Council directive, second version.
The Akoma Ntoso package Manifestation is a very specific Manifestation using a number of data formats (mainly XML but other multimedia formats could be present as needed) with a very specific organization of parts and components. Since it makes explicit choices in terms of data formats and reciprocal references, it is important to provide clear and non-ambiguous rules as to the internal naming mechanism and its overall structure. An Akoma Ntoso package manifestation is a package composed of one or more files organized in a flat fashion. The transportable format is a ZIP file whose extension is “.akn”. Other formats are possible and acceptable as long as they adhere to these rules.
1. If the document is just composed of text and does not refer to any multimedia fragment of any form, then the ZIP package contains a single document called “main.xml”.
2. If the document is composed of many Manifestation-level components but does not refer to any multimedia fragment of any form, then the zip package is composed of many XML files, one for each Expression-level component. Each Manifestation-level component is then called as its corresponding Expression-level component, plus the “.xml” extension. The name “main” is reserved for the main component. Numbers are never used except when they are already part of the Expression-level component’s name.
3. If the document contains multimedia fragments of any kind, these fragments do not have a corresponding Expression-level component, but are just Manifestation-level components specified in “src” attributes, for instance in <img> elements. All multimedia components MUST be stored within an inner structure (e.g., a folder) called “media”. Multimedia components can be called freely, but MUST use the appropriate extension to refer to their content type. Thus a logo can be called “logo.tif” or any other name, as long as the extension is correctly specifying the content type.
A portion is a specific document type in Akoma Ntoso XML, that contains a only a part of a whole document. Portion documents are used when the full document is large, and only a smaller part is necessary, such as a few sections or articles.
Requesting a portion is therefore only appropriate for Akoma Ntoso XML Manifestations, and is not guaranteed to be supported by all servers. A request for a portion therefore MUST return a manifestations containing at least the requested part, but possibly containing much more than the requested part, up to and including the whole document the part belongs to.
In an Akoma Ntoso IRI reference, the specification for the portion of a document is introduced by the special character “~”.
– A pair of eIds of the first and last elements of the sequence of parts being requested, separated by a dash “->“.
The portion containing article 3 of schedule 1 of the XML Manifestation of the European Directive 2003/87/EC in English at the version dated 2015-01-20.
Akoma Ntoso makes no assumption about the physical storage mechanism employed to record actual manifestations. As such, there is NO rule for IRIs of the items, which are free to assume any form whatsoever and correspond to whatever storage mechanism has been employed locally.
On the other hand, the actual URL for the Item must be provided to a resolution mechanism in order for the hyper-textual feature of the Akoma Ntoso publication systems to work correctly and automatically.
A global IRI reference is a relative IRI reference where all parts are present except for protocol and authority (i.e., domain name). A global IRI reference always starts with a slash, to indicate that all other parts are explicitly specified. A local IRI reference, on the other hand, has one or more parts missing (necessarily from left to right), and the corresponding global (and, subsequently, absolute) IRI reference is determined by adding the corresponding parts taken from the base document, as described in RFC 3986.
In the Akoma Ntoso Naming Convention, a reference to a different document is always global. Local IRI references are used for references to components, portions or fragments, and implicitly make use of the identification parts of the base document for the correct resolution of the IRI reference.
As per RFC 3986, dereferencing this IRI reference does not imply making a request to the origin server. This request scrolls the current document so as to bring into view the part of the document whose eId has been requested.
The implication of using this type of local references is that the requested part of the document is already dereferenced and available at the client. On the other hand, any Akoma Ntoso document can contain this type of references.
Dereferencing this IRI reference implies making a new request to the origin server. The server may choose to return the requested component either as an autonomous document or as a component of a document collection document type.
The implication of using this type of local references is that the base IRI MUST already contain either the component or the portion part. It is unspecified and usually incorrect to use a local component reference in a document whose base IRI does NOT include a component or portion part.
Dereferencing this IRI reference implies making a new request to the origin server. The server MUST either return the requested part as a portion document type containing at least the part being requested, OR the full document or component containing the part being requested, even when they correspond to the current document.
a portion document containing at least the sequence from article 3 to article 5 of the component called schedule 1 of the current document. When dereferenced, scroll to article 4.
The object of all discourses within the Akoma Ntoso framework can be described as a set of abstract classes and their instances and of the relationship among them. Cumulatively, definition of classes, relationships and instances are called an ontology.
The four most important classes of the Akoma Ntoso informal ontology (Work, Expression, Manifestation, and Item) are surely connected to documents, but many more exist, even if they are not connected directly to physical documents. The purpose of this section is to provide syntax for non-document entities (i.e., instances of non-document classes such as people, organizations, or concepts.) Furthermore, the syntax described here can also be used for document entities as an equivalent syntax to the one specified in the previous sections.
Akoma Ntoso entities are always associated to a class, providing a structure of properties and relationships to other instances of the same and other classes. Classes in the Akoma Ntoso informal ontology are organized in a complex maze of sub/superclasses. These are useful to give shape and meaning to a domain, and to provide structure to the overall set of instances of a base class. It is important to notice that sub/superclasses do not form necessarily a tree, but can form a more complex structure, namely a directed graph.
For instance, the class of Kenyan judges can be considered a sub class of both Kenyan persons and of persons whose job description is judge. That is, there is a (implicit or explicit) subclass of Judges and (implicit or explicit) subclasses of Kenyans, both of which are, in turn, subclasses of Person, and Kenyan Judges is a subclass of both. In fact, we immediately derive the principle that every different value in every different property or relationship implicitly generates a class, that turns into an explicit class only because of our whim or need. For instance, the class of all persons named “Joe” exists implicitly, identifies all persons whose first name is “Joe”, and, if so desired, can be made explicit through the definition of a subclass of Person.
While this is very useful for determining relationships between entities, it affects the mechanism to associate IRIs to such entities. In particular, being that there is no single hierarchy of classes, it is not appropriate to propose a single path of specifications from the super class to the final class. As such, ideally /person/judge/ken/JoeSmith must point to the same individual as /person/ken/judge/JoeSmith.
In order to maintain meaningfulness, permanence and invariance (which are the main requirements for our naming convention, as specified in the introduction of this document) we need to find a reliable naming mechanism for clearly identifying entities that does not depend on the sub/superclass organization except when strictly necessary.
In particular, we define the concept of Top Level Classes (TLC) that are guaranteed to be a partition of the overall domain of the Akoma Ntoso standard. TLC include Work, Expression, Manifestation, Item, Person, Organization, Concept, Object, Event, Process, Role, Term and Location. The list of TLC may, in the future, include more, as long as they keep on generating a partition (i.e., that they are disjoint and cumulatively describe all possible instance of the Akoma Ntoso domain). Members of the TLC classes can be subclassed at will and with no theoretical constraints.
Given the high number of foreseeable subclasses of the TLC, and the pointlessness of determining a fixed hierarchy in such number, the naming of entities should not depend on the presence or absence of a given class except for TLC. This means that it is necessary that each instance of each TLC is provided with an ID string that is guaranteed to be unique within the TLC. The syntax of this ID is dependent of the TLC class, and the syntax for each of the existing TLC is provided in the next section.
– The ID of the instance, guaranteed to be unique within the TLC.
All components are separated by forward slashes (“/”) so as to exploit relative IRIs in references.
As mentioned in the previous section, the hierarchy of path elements is of no use for identifying instances of each TLC, given the fact that there can be no unique hierarchy of subclasses in the Akoma Ntoso informal ontology. Thus, each instance of the ontology needs to be provided with an ID guaranteed to be unique within the TLC it belongs to. The syntax of the ID depends on the actual TLC, and is briefly explained in the following schema.
A dot-separated string composed of the country of citizenship, the first name, the family name, the birth date in yyyy-mm-dd format, and an optional arbitrary string if ambiguity exists (e.g., if two individuals with the same name and the same birth date exist in the same country).
A dot-separated string composed of the country of registration (or the string “int” if international, or the string “unreg” if not registered anywhere), a recognizable form of the organization name and an optional arbitrary string if ambiguity exists (e.g., if two organizations with the same name exist in the same country).
Concepts differ from terms as they refer to some concept regardless of the linguistic form used. For instance, "pope" and "pontiff" are different linguistic forms for the same concept, while "date" is a single linguistic form potentially referring to two different concepts (a calendar date as opposed to a type of fruit). TLCConcepts must be associated to a specific reference resource that disambiguates it. This must be an item of a thesaurus, of an encyclopedia, or of a commonly available dictionary. The identifier of the TLCConcept is a unique representation of the name of the concept joined with dots and preceded by an unambiguous name for the resource being used. No country specifications are necessary for concepts.
the concept of Presidential Election as defined in Wikipedia.
Objects must refer to a specific reference resource that can be used to disambiguate the object being referred to. This must be a thesaurus, an encyclopedia, or a commonly available dictionary. A unique form of the terms specifying the concept joined with dots preceded by an unambiguous name for the resource being used. No country specifications are necessary for objects.
Events must refer to a specific reference resource that can be used to disambiguate the object being referred to. This must be a thesaurus, an encyclopedia, or a commonly available dictionary. A unique form of the terms specifying the concept joined with dots preceded by an unambiguous name for the resource being used. No country specifications are necessary for events.
Places must refer to a specific reference resource that can be used to disambiguate the object being referred to. This must be a thesaurus, an encyclopedia, or a commonly available dictionary. A unique form of the terms specifying the concept joined with dots preceded by an unambiguous name for the resource being used. No country specifications are necessary for places.
Processes must refer to a specific reference resource that can be used to disambiguate the object being referred to. This must be a thesaurus, an encyclopedia, or a commonly available dictionary. A unique form of the terms specifying the concept joined with dots preceded by an unambiguous name for the resource being used. Country specifications are necessary for processes since processes with the same name may exist with different steps across different countries.
The promulgation as defined in Wikipedia and as carried out in Kenya.
Roles must refer to a specific reference resource that can be used to disambiguate the object being referred to. This must be a thesaurus, an encyclopedia, or a commonly available dictionary. A unique form of the terms specifying the concept joined with dots preceded by an unambiguous name for the resource being used. Country specifications are necessary for roles since roles with the same name may exist with different characteristics across different countries.
The role of the speaker of the house as defined in Wikipedia and as conceived in Kenya.
Terms differ from concepts as they refer to a linguistic form, rather than to the concept expressed by it. Therefore, for instance, "majority vote" and "mayoría de votos" are different linguistic forms in different languages for the same concept. TLCTerms must be associated to a specific reference resource that disambiguates it. This must be an item of a thesaurus, of an encyclopedia, or of a commonly available dictionary. The identifier of the TLCTerm is a unique representation of the words of the linguistic form joined with dots and preceded by an unambiguous name for the resource being used. No country specifications are necessary for terms, but a language reference is necessary for the correct attribution.
The meaning of the majority vote as defined in Eurovoc and expressed in English.
The domain-less IRI of the Work, Expression, Manifestation, as specified in this document, or the full IRI of the Item, with all slash substituted with dots.
European proposal for a Council directive. English variant in second version.
3. FRBR compliant: A full distinction between "distinct intellectual creations", "specific intellectual forms", "physical embodiments" and "exemplars" of relevant documents must be explicitly supported and aligned with the FRBR conceptualizations. Support for items is not necessary nor requested.
* FRBRportion (REQUIRED if the the document is split into portions).Any Naming Convention that complies with these requirements (items 1. through 6.) is termed a functionally-equivalent Naming Convention (FENC) and its URIs/IRIs can be used in any context where Akoma Ntoso URIs/IRIs are appropriate.
Many references need to point to items smaller than whole documents. In sections 4.7, 4.9 and 4.10 the syntax is provided to create IRI references to subdocument units, such as fragments, components and portions.
The description of these syntaxes include the specification for the name or for the identifier of the component or portion being referred to. In this section we discuss how the name and the identifier of these parts should be created and managed, in case the Manifestation being referred to uses the Akoma Ntoso XML vocabulary.
The Akoma Ntoso XML vocabulary uses three different attributes for the attribution of ids to elements. All of them are optional for basic conformance, and required for higher level conformance. For one of these attributes, GUID, no syntax is prescribed. The two others, eId and wId, have a prescribed syntax in conformance level 2. Therefore, while the use of eIds and wIds is not required for conformance level 1, in conformance level 2 they MUST use the syntax described here IF used.
Non XML-based manifestations that use identifiers SHOULD adopt values for ids that are consistent with that specified in this section.
- Universality: this specification applies to all document types that Akoma Ntoso deals with now or will deal with in the future. It works for amendable parts as well as non-amendable parts, for frequently modified parts as well as never modified parts. It works for original versions, single versions, multiple versions, and chains of versions.
- Proportionality of impact: the approach taken for a rare occurrence does not affect the solutions taken for the more frequent occurrences. It is better for the solution of a rare occurrence to be very convoluted than for the solution to a frequent occurrence to be even only mildly convoluted.
- Uniqueness: the identifier of a part is unique within the document.
- Persistency: the identifier of a part is persistent across versions, i.e., across all expressions of the same work. The persistency refers to the identity of the part, and not of the name or the number (i.e., if a part is moved and renamed the identifier accompanies the part, and does not stay with the number), so that it is possible to track the movement of the part across versions.
- Navigability: the identifier of a part is usable in an IRI reference as the fragment part (after the # character) or as the portion part (after the ~ character), even in hypertext links to a separate document, and the link remains traversable to the right place regardless of what happened to the destination document.
- Self-sufficiency: the identifier of a part is the only information needed to perform the basic operations (in particular, navigation and tracking). Explanatory metadata are always optional so that it is not necessary to deal with tracking in a separate metadata section.
- Contiguity: the identifier of a part is near the part it refers to, e.g., as an attribute to the relevant element.
- Meaningfulness: the identifier of a part expresses, as much as possible, basic facts about its nature, position, or relation to superior and/or neighboring elements that are meaningful to the local tradition.
- Transferability: the identifier of a part is transferable when the part is transferred from a document to another, or from a document type to another. For instance, identifiers of bills are transferable to the identifiers of the corresponding act once the document has been promulgated, and similarly, the identifier of a structure within an amendment proposal, possibly even in an oral discussion reported in a Hansard, is transferable to the identifier of the structure in a new version of the bill.
This is the first and most important identifier. An eId attribute provides uniqueness of an element within a specific Expression. The value of eId is specified as connected to the structural role of the corresponding element. So, it needs to be updated regularly whenever the structural role of the element changes in a new Expression (i.e., if the element is renumbered or changed in nature, e.g., from article to clause).
This attribute is only needed if the eId is not also a Work-level identifier. It is meant for mapping the identity and position of the same elements in different Expressions and variants of the same Work – wId identifier will be explicitly included when the eId changes from one Expression to another. The value of the wId attribute never changes; it must be the same values for the same elements in all the Expressions of a document. In order to allow this, a master Expression needs to be identified, i.e., the Expression whose eId attribute becomes the references for the wId attribute of all other Expressions.
This attribute is an application-specific identifier that a local implementation may need to add to elements according to local rules and syntaxes. GUID is not a required attribute. Its use and specification is totally dependent on the representation and storage requirements of the author of the Manifestation. Despite the name, GUID do not even have to be globally unique across documents of the same collection. They are meant as a way to place ids from legacy formats and collections and that are still in use. The usage of GUID attribute has no required syntax and does not impact on compliance with this specification.
Most elements in the Akoma Ntoso XML vocabulary allow two optional attributes, called eId and wId. They are optional for compliance level 1, and are required for compliance levels 2 and above.
- for the wId attribute, the reference element is the one in the master Expression, as specified in section 5.4.
number is a (possibly empty) representation of the numbering of the element within its context.
Frequently elements appear in different parts of the same document with the same number and they need to be identified by the context in which they appear: for instance, a Chapter 2 may exist within both Book I and Book II, and a line 5 most probably exists in every page of some document.
The context is the part of the identifier that provides the required uniqueness. Thus, the context of the two instances of Chapter 2 is Book I or Book II respectively, while the context for each line 5 (i.e., each <eol> element) will be the page number of the page in which it appears (i.e., the immediately preceding <eop> element).
The prefix is a (possibly empty) string providing uniqueness to the remaining part of the identifier, and it is based on the context in which the element appears. In fact, by construction the prefix is the full identifier of the context element.
The prefix part of Chapter 2 within Book I is “book_I”, which is the identifier of the element “Book I” that provides the context for the rest of the identifier.
The prefix part of the line 5 of page 3 is “eop_2”, which is the identifier of the element between page 2 and page 3 that provides the context for the rest of the identifier.
Composite documents make it more complex to reach uniqueness of identifiers over the whole XML document, since they might be the result of composing individual documents where the same identifiers may exist independently. For instance, an element called section 2 may exist independently in the main component and in an annex of the same document.
The identifier of an element MUST therefore include the full identifier of the context element that guarantees its uniqueness, and it CAN be the identifier of the individual document in a composite document, the identifier of a wrapping element that restarts the numbering, or the identifier of a preceding element that restarts the numbering.
Structures within the <quotedStructure> and <embeddedStructure> elements add the relevant mod identifier before their “natural” identifiers. In a way, <quotedStructure> and <embeddedStructure> act as the context for the contained structures. So for instance if clause 3 of article 15 has an amendment that adds article 4/a to a different act, the identifier of the <quotedStructure> element that contains the new article will be “art_15__cl_3__mod_1__qstr_1”, and the identifier of article 4/a inside it will be “art_15__cl_3__mod_1__qstr_1__art_4a”. Of course, automatic systems that create current versions of texts should and will remove the prefix belonging to the modification law and will only keep the identifier “art_4a” in the final result.
- All document classes (<act>, <bill>, <doc>, etc.) are always contexts. This means that, except particular cases, all numbers restart whenever a new document class is started (e.g., in a composite document each document component has its own local numbering).
- Elements <quotedStructure> and <embeddedStructure> are always contexts, even if they do not force a restart of the numbering, but just a different numbering context within themselves.
- Plain inline elements are never contexts. Exception: element <mod> is always a context.
The reason for these elements to have the same element_ref is to reduce the complexity whenever the structures are functionally identical.
depending on the document inside, the identifier can be “annex” or “attachment” or the name of the component , with an explicit number.
The number part of an identifier is a (possibly empty) representation of the numbering of the element within its context.
If the element is necessarily unique within its context, no numbering is used, and therefore there is no number part. For instance, since there is exactly one body in acts and bills, its identifier can be simply “body” (or, of course, “doc_1__body” in case of a composite document). Analogously, since there is at most one content element inside articles or sections, the identifier of the <content> element of article 12 will be simply “art_12__content”.
An explicitly numbered element has its number determined in the Expression itself in the form of a <num> sub-element. The number part of the identifiers of such elements corresponds to the stripping of all final punctuation, meaningless separations as well as redundant characters in the content of the <num> element. The representation is case-sensitive. For instance, if article 12 contains <num>Art. 11.2 bis</num> then the number part of the identifier will be “11-2bis”. It is the job of the author of the Manifestation to determine whether the numbering expressed in the <num> element is global (i.e., it starts at 1 at the beginning of the document) or local (i.e., it restarts at 1 inside or after every instance of an intermediate element). This is usually made clear within every legal tradition and usually can be established by briefly examining a few or even just one document in its original form. Meaningful separations and punctuation are never stripped. For instance, article -1 (in some jurisdictions it represents a late insertion before article 1) will be “art_-1”.
An implicitly numbered element has no <num> sub-element, and its numbering is established by counting the occurrences of similar elements within the same context, always using Arabic numbers. It is the job of the author of the Manifestation to determine whether the best way to count these elements is globally (i.e., starting at 1 at the beginning of the document class) or locally (i.e., restarting at 1 inside or after every instance of an intermediate element). This naming convention provides no rules on this choice, but there are a few common sense approaches. For instance, it is very natural that <eop> elements are globally counted, and <eol> are locally counted by their preceding <eop> element, and as such, the third <eop> element (the one separating the third page from the fourth) has identifier “eop_3” (note no prefix), while the fifteenth end of line after such eop (the one separating the fifteenth line from the sixteenth) will have as identifier “eop_3__eol_15”. On the other hand, <p> elements within a given structure are probably counted locally (as in “third <p> of section 12”). This is not necessarily the immediately containing element (which in this case would be the <content> element), but any containing or preceding element that in the opinion of the author of the Manifestation provides context for the counting. Thus the third <p> of section 12 could reasonably have “sec_12__p_3” as its identifier.
Documents are complex structures. Sometime, it is important to record the fact that the (conceptually) same structure may have different content (e.g., for different languages, different versions or different audiences).
Permanent identifiers are the basic tool to be able to identify the concept of sameness across situations that require different content to be known as really being the same. Unfortunately, relying only on a permanent identifier prevents some common and very useful operations to be performed on documents that present multiple instances of the same structure. For this reason the concepts of Expression identifiers (eId) and Work identifiers (wId) have been introduced.
The use of attribute eId is optional for conformance level 1, and required for conformance level 2. If attribute eId is used at all, then it MUST be used according to the syntax defined in section 5.4. If attribute eId is used in a document, then it is required for all elements that use or include attribute group idreq, and optional in all elements using or including attribute group idfac.
(b) its Work-level identifiers are the same as Expression-level identifiers.
If this is NOT the Master Expression, then the Work-level identifiers NEED to be present as soon as they become different from the corresponding Expression-level Identifiers.
Master Expressions are necessarily the FIRST (or the ONLY) time-related versions of a document that either is intrinsically MONOLINGUAL or is expressed in the MASTER LANGUAGE, which is country- and jurisdiction- dependent and may even not exist (as in EU).
A Manifestation author must know whether the document being marked up should be considered as the Master Expression for a Work or not.
The Expression-level identifiers use a semantic naming convention based on the structure of their Expression. The Work-level identifiers use a semantic naming convention based on the structure of their Master Expression, if one exists, or of a conceptual Ur-Expression, if none exists.
The decision to use two separate identifiers is to avoid the risk of collapsing two potentially very different meanings of “identification” into just one identifier: the identifier of the right place (the one that I mean now when I use this identifier) and the identifier of the same place (the one that had such an identifier in a different version or in a different variant of this document).
1. In multilingual works, the concurrence of multiple similarly named structures in multiple expressions, say article 2 in the French version of a document and section 2 in the English version of the same document, both referring to the same conceptual structure. A first subcase of this situation is when a master language can be identified, which provides a clear Master Expression, and a second subcase is when no master language is provided (e.g., in European legislation), so that no Master Expression exists.
2. In a multi-version file, the co-occurrence of two similarly named structures from two versions, say article 2 in the past version and article 2 in the current version, both contained in the same (multi-version) Manifestation.
3. In a modification act, the concurrence of two similarly named structures of the amending and of the amended document, say I am amending art.2 of the amended act, and of course an art.2 that exists already somewhere else in the amending act.
4. In a chain of versions, the requirement to renumber a few structures that completely desynchronizes the old identification mechanisms from the new one, e.g., article 2 is from now on known as article 15. Such renumbering is frequent in bills, and rare in acts. But external references to bills are mainly static (i.e., they refer to a specific version of a bill), while external references to acts are often dynamic (i.e., they refer to any of a number of versions depending on the nature of the quest).
- First use case – renumbering in bills: an approved amendment A inserts a new article between art.1 and art.2 of version 1 of bill B. Because of this decision, art.2 is known in version 2 of B as art.3, art.3 is known as art.4, etc.
- Second use case – renumbering in acts: while act Y is in version 1, on date D1 act X makes a (dynamic) reference to art.2 of act Y. Subsequently, on date D2, act Y gets renumbered, and in version 2 art.2 becomes art.15 and a new art.2 is introduced in its stead. Subsequently, on date 3, act W makes a (dynamic) reference to art.15 of act Y (which is the new name for art.2) and on date D4 act Z makes a reference to art.2 of act Y (which is a new article that did not exist previously).
Given the above-mentioned principles, the natural solution is to have two identifiers to deal with. One is persistent and associated to the Work, while the other is evolving in time and associated to the Expression. Whenever the persistent identifier and the evolving identifier do not differ, only one of them is specified in the document, but when they differ, then the evolving identifier follows the structure of the Expression, while the permanent identifier is anchored to the structure of one specific Expression, called Master Expression, which is considered as the fundamental Expression for the permanent identification of fragments.
When a situation occurs that requires the two identifiers to differ from each other, such as one of the above-mentioned situations 1, 2, 3 or 4, then the eId attribute is set to reflect the new role and number of the element in the structure, while the wId attribute is added and set to reflect the identity that such fragment had, has or would have in the Master Expression. Thus, after any change in the document, the Work-level identifier (wId) is added and never changes, and the Expression identifier (eId) keeps on being updated according to the condition of the Expression it belongs to.
Tracking is always based on the wId, navigation is always based on the identifier that was the eId at the moment, and transfer is always based on the eId. If the evolving identifier changes in time more than once, the Akoma Ntoso vocabulary provides the <mapping> metadata to hold a complete map in time of the relationships between the persistent identifier wId and each of the evolving identifiers eId.
For instance, we can describe the four situations as follows.
Two expressions exist in two different languages. One is in the master, or default language, and the other is an additional variant in a different language. As such, the version in the default language is the master Expression, and the other version uses the master Expression’s identifiers as wIds.
Two expressions exist in two different languages, but neither can be determined as the default or master language. This happens, for instance, in European legislation. As such, the master Expression does not exist in a concrete Expression, but must be determined abstractly (it could be called an UR-Expression), and both versions uses the UR-Expression’s identifiers as wIds.
In a multi-version file, two similarly named structures exist coming from two different versions, say article 2 in the past version and article 2 in the current version, both must be placed in the same (multi-version) Manifestation.
The “default” structure (e.g., the current version) uses a plain eId identifier; the “secondary” structure (e.g., the past version) uses a modified eId identifier and is associated to the default structure via the wId identifier.
In this situation it is assumed that the expected default behavior when traversing documents is to go to the newer version of the document, and if the navigation mechanism knows something more specific about the needs of the user, it would lead to the older version of the fragment instead.
In the second version of the bill a new article 2 was inserted, which generated a renumbering of the subsequent articles. This version uses identifiers to specify the original identifiers, regardless of the position, and uses eId to specify the identifier each article should have if this were a new document.
Since bills mostly receive static references, and since static references always include the version number, it is always very clear what refers to what – references to art_2 in version 1 of the bill will lead to the same article as references to art_3 in version 2, while references to art_2 in version 2 will lead to the newly inserted article.
Suppose that, while act Y is in version 1, on date D1 act X makes a (Work-level) reference to art.2 of act Y. Subsequently, on date D2, act Y gets renumbered, and in version 2 art.2 becomes art.15 and a new art.2 is introduced in its stead. Subsequently, on date 3, act W makes a (dynamic) reference to art.15 of act Y (which is the new name for art.2) and on date D4 act Z makes a reference to art.2 of act Y (which is a new article that did not exist previously)”.
- In act X the Work-level reference to art.2 of act Y would be is Y/~art_2. This corresponds to the structure that in version 1 had eId=”art_2”.
- In act Z the Work-level reference to art.2 of act Y is Y/~art_2. This corresponds to the structure that in version 2 had eId=”art_2” and no wId.
When accessing one of these references, the date of the source Expression (i.e., the one containing the reference must be compared with the date of the Expression of the destination document. If the date of the source is before the date of the destination, then the wId must be used for navigation. Otherwise the eId must be used.
This chapter defines Akoma Ntoso conformance clauses.
3. The values of the href and src attributes in ALL elements (except <a>) follows the specifications detailed in chapter 4 and 5 of this document or any functionally equivalent naming convention as detailed in chapter 4.12.
Beatch, Richard, Bloomberg Finance L.P.
Cabral, James, MTG Management Consultants, LLC.
Junge, Peter, Beijing Sursen Electronic Technology Co, Ltd.
Vergottini, Grant, Xcential Group, LLC.
Wintermann, John, Bloomberg Finance L.P.
Better definitions of TLCConcept and TLCTerm.
 this is a simplification of RFC 3986, that calls global IRI refs as “absolute path references” and local IRI refs as “relative path references”.
 Transferability does not mean "identical value", but only that a transformation between the two values must be possible in an automatic way.
 We use here a simplified version of the Naming Convention, [doc]/~[portion], where [doc] is the IRI reference for the whole document, and [portion] is the identifier of the portion.

References: art.2
 art.2
 art.1
 art.2
 art.2
 art.3
 art.3
 art.4
 art.2
 art.2
 art.15
 art.2
 art.15
 art.2
 art.2
 art.2
 art.2
 art.15
 art.2
 art.15
 art.2
 art.2
 art.2
 art.2