| Internet-Draft | URN LEX Namespace for Sources of Law | February 2023 |
| Spinosa, et al. | Expires 14 August 2023 | [Page] |
This document describes a Uniform Resource Name (URN) Namespace Identification (NID) convention for identifying, naming, assigning, and managing persistent resources in the legal domain. This specification is published to allow adoption of a common convention by multiple jurisdictions to facilitate ease of reference and access to resources in the legal domain.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 14 August 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The purpose of the "lex" namespace is to assign an unequivocal identifier, in well-defined format, to documents that are sources of law. To the extent of this namespace, "sources of law" include any legal document within the domain of legislation, case law and administrative acts or regulations; moreover potential "sources of law" (acts under the process of law formation, as bills) are included as well. Therefore "legal doctrine" is explicitly not covered.¶
The identifier is conceived so that its construction depends only on the characteristics (details) of the document itself and, therefore, it is independent from the document on-line availability, its physical location, and access mode. The identifier itself is assigned by the jurisdiction of the identified document. Even a document that is not available online may, nevertheless, have a LEX URN identifier.¶
Such an identifier can be used as a way to represent references (and more generally, any type of relation) among various sources of law. In an on-line environment with resources distributed among different Web publishers, identifiers, in terms of uniform resource names, allow a simplified global interconnection of legal documents by means of automated hypertext linking. LEX URNs are therefore particularly useful when they can be mapped into or associated with locators such as HTTP URLs. Moreover, LEX URNs details can be used as a reference to create HTTP-based persistent and location-independent identifiers [RFC3986]. Such kind of identifiers have been suggested within the set of principles and technologies, known as "Linked Data", as a basic infrastructure of the semantic web to enable data sharing and reuse on a massive scale.¶
The following entities support the publication of this proposal:¶
This specification of an unequivocal identifier for legal documents follows a number of initiatives in the field of legal document management. These specifications for an an unequivocal identifier of legal documents follows a number of initiatives in the field of legal document management.¶
Since 2001 the Italian Government, through the National Center for Information Technology in the Public Administration, the Ministry of Justice and CNR (the National Research Council of Italy) promoted the NormeInRete project. It was aimed at introducing standards for sources of law description and identification using XML and URN techniques.¶
Other national initiatives in Europe introduced standards for the description of legal sources [FRAN]. Such initiatives, based in synergies between government, national research institutes, and universities, have defined national XML standards for legal document management, as well as schemes for legal document identification. Outside Europe, similar initiatives have addressed similar problems [FRAN]. Several of these identifiers are based on a URN schema.¶
In today's information society the processes of political, social and
economic integration of European Union member states as well as the
increasing integration of the world-wide legal and economic processes
are causing a growing interest in exchanging legal information
knowledge at national and trans-national levels.
The growing desire for improved quality and accessibility of legal
information amplifies the need for interoperability among legal
information systems across national boundaries. A common well-defined
schema used to identify sources of law at international level is an
essential prerequisite for interoperability.¶
Interest groups within several countries have already expressed their
intention to adopt a shared solution based on a URN technique.
The need for an unequivocal identifier of sources of law in different
EU Member States, based on open standards and able to provide
advanced modalities of document hyper-linking, has been expressed in
several conferences (as [LVI]) by representatives of the Publications
Office of the European Union (OP), with the aim of promoting
interoperability among national and European institution information
systems. Similar concerns have been raised by international groups
concerned with free access to legal information, and the Permanent
Bureau of the Hague Conference on Private International Law [HCPIL]
that encourage State Parties to "adopt neutral methods of citation of
their legal materials, including methods that are medium-neutral,
provider-neutral and internationally consistent.". In a similar
direction the CEN Metalex initiative is moving, at European level,
towards the definition of a standard interchange format for sources
of law, including recommendations for defining naming conventions to
them.¶
The need of unequivocal identifiers for sources of law is of
particular interest also in the domain of case law. Such need is
extremely felt within both common law systems, where cases are the
main law sources, and civil law systems, for the importance of
providing an integrated access to cases and legislation, as well as
to track the relationships between them. This domain is characterized
by a high degree of fragmentation in case law information systems,
which usually lack interoperability.
In the European Union, the community institutions have stressed the
need for citizens, businesses, lawyers, prosecutors and judges to
become more aware not only of (directly applicable) EU law, but also
of the various national legal systems. The growing importance of
national judiciaries for the application of Community law was
stressed in the resolution of the European Parliament of 9 July 2008
on the role of the national judge in the European judicial system.
Similarly the the Council of the European Union has underlined the
importance of cross-border access to national case law, as well as
the need for its standardisation, in view of an integrated access in
a decentralized architecture. In this view the Working Party on Legal
Data Processing (e-Law) of the Council of the European Union formed a
task group to study the possibilities for improving cross-border
access to national case law. Taking notice of the report of the
Working Party's task group the Council of the EU decided in 2009 to
elaborate on a uniform, European system for the identification of
case law (ECLI: European Case-Law Identifier) and uniform Dublin
Core-based set of metadata.
The Council of the European Union invited the Member States to
introduce in the legal information systems the European Legislation
Identifier (ELI), an http-based Semantic Web oriented identification
system for European Union and Member States legislation.¶
The LEX identifier (also referred in this text as "LEX name") is conceived to be general enough so as to provide guidance at the core of the standard and sufficient flexibility to cover a wide variety of needs for identifying all the legal documents of different nature, namely legislative, case-law and administrative acts. Moreover, it can be effectively used within a federative environment where different publishers (public and private) can provide their own items of a legal document (that is there is more than one manifestation of the same legal document).¶
However specifications and syntax rules of LEX identifier can be used also for http-based naming convention to cope with different requirements in legal information management, for example the need of having an identifier compliant with the Linked Open Data principles.¶
This document supplements the required name syntax with a naming convention that interprets all these recommendations into an original solution for sources of law identification.¶
The specification contained in this document promote interoperability among legal information systems by the definition of a namespace convention and structure that will create and manage identifiers for legal documents. The identifiers will be:¶
These qualities will facilitate legal document management as well as providing a mechanism of stable cross-collections and cross-country references.¶
Transparency means that given an act and its relevant metadata (issuing authority, type of measure, etc.) it is possible to create the related urn identifier. Moreover this identifier is able to unequivocally identify the related act. These two properties make the identification system reversible (from an act to its URN and from a URN to the related act).¶
Language-neutrality is an especially important feature that will promote adoption of the standard by organizations that must adhere to official-language requirements. This specification provides useful guidance to both public and private groups that create, promulgate, and publish legal documents. Registrants wish to minimize the potential for creating conflicting proprietary schemes, while preserving sufficient flexibility to allow for diverse document types and to respect the need for local control of collections by an equally diverse assortment of administrative entities.¶
As usual, the problem is to provide the right amount guidance at the core of the specification while providing sufficient flexibility to cover a wide variety of needs. This LEX specification does this by splitting the identifier into parts. The first part uses a pre- existing standard specification ("country/jurisdiction name standard") to indicate the country (or more generally the jurisdiction) of origin for the legal document being identified; the remainder ("local name") is intended for local use in identifying documents issued in that country or jurisdiction. This second part depends only on the system of sources of law identification operating in that nation and it is mainly composed by formalized information related to the enacting authority, the type of measure, the details and possibly the annex.¶
The identification system based on uniform names includes:¶
This document considers the first of these requirements. It also contains a few references to the architecture of the resolution service and to the corresponding software.¶
The LEX name is linked to the document through meta-information which may be specified:¶
At least one of these modalities is necessary for enabling automated construction and updating of catalogues (distributed and centralized) and the implementation of resolvers that associate the uniform name of a document with its physical location(s). LEX assumes no particular relationship between the originator of the document, its publisher, and the implementer of catalogues or resolution services. They may be the same entity, or not.¶
LEX names can be used in references as a HREF attribute value of the hypertext link to the referred document. This link can be created in two ways:¶
In any case, whatever the method adopted is, new documents produced in XML format (compliant with the DTD/XMLSchema defined in the related country) should express references through the uniform name of the document referred to.¶
According to this document, the following terms are used in the following meaning:¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the syntax common to many Internet RFCs, which is based on the ABNF (Augmented Backus-Naur Form) [RFC5234] meta- language.¶
The "lex" namespace has already been registered in the "Formal URN Namespaces" registry.¶
The identifier has a hierarchical structure as follows:¶
"urn:lex:" NSS¶
where <NSS> is the Namespace Specific String composed as follows:¶
NSS = jurisdiction ":" local-name¶
where:¶
<jurisdiction> is the part providing the identification of the jurisdiction, identifying the scope (state, regional, municipal, supranational or of an organization) where a set of sources of law have validity. It is also possible to represent international organizations (either states or public administrations or private entities);¶
<local-name> is the uniform name of the source of law in the country or jurisdiction where it is issued; its internal structure is common to the already adopted schemas. It is able to represent all the aspects of an intellectual production, as it is a legal document, from its initial idea, through its evolution during the time, to its realisation by different means (paper, digital, etc.).¶
The <jurisdiction> element is composed of two specific fields:¶
jurisdiction = jurisdiction-code *(";" jurisdiction-unit)
¶
where:¶
<jurisdiction-code> is usually the identification code of the country where the source of law is issued.¶
To facilitate the transparency of the name, the <jurisdiction-code> follows usually the rules of identification of other Internet applications, based on Domain Name (for details or special cases see Section 2.2).¶
Where applicable, the ccTLD, or the TLD, or the Domain Name of the country or multinational or international organisation is used. If such information is not available for a particular institution, a specific code will be defined (see Section 2.2). Examples reported in this document are hypothetical and assumed that the corresponding Domain Name is used for the <jurisdiction-code>.¶
However, a special register for the <jurisdiction-code> is required, the rules of which are defined in Section 2.2.¶
<jurisdiction-unit> are the possible administrative hierarchical sub- structures defined by each country or organisation within their specific legal system. This additional information can be used in case two or more levels of legislative or judicial production exist (e.g., federal, state and municipality level) and the same bodies may be present in each jurisdiction. Therefore acts of the same type issued by similar authorities in different areas differ for the jurisdiction-unit specification. An example can be the following: "br:governo:decreto" (decree of federal government), "br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state) and "br;sao.paulo;campinas:governo:decreto" (decree of Campinas municipality).¶
Examples (hypothetical) of sources of law identifiers are:¶
urn:lex:it:stato:legge:2003-09-21;456
(Italian act)
urn:lex:fr:etat:loi:2004-12-06;321
(French act)
urn:lex:es:estado:ley:2002-07-12;123
(Spanish act)
urn:lex:ch;glarus:regiere:erlass:2007-10-15;963
(Glarus Swiss Canton decree)
urn:lex:eu:commission:directive:2010-03-09;2010-19-EU
(EU Commission Directive)
urn:lex:us:supreme.court:decision:1978-04-28;77-5953
(US SC decision: Riley vs Illinois)
urn:lex:be:conseil.etat:decision:2008-07-09;185.273
(Decision of the Belgian Council of State)
¶
It is planned to create a new registry for <jurisdiction-code>, with the following format:¶
The table is initially empty. Possible example entries are:¶
"br"; "Brazil"; "Prodasen, Federal Senate, \<address>, \<contact>";
\[reference\]
"eu"; "European Union"; "DG Digit, European Commission, \<address>,
\<contact>"; \[reference\]
"un.org"; "United Nations"; "DPI, United Nations, \<address>,
\<contact>"; \[reference\]
¶
CNR will take care to create and maintain the registry for <jurisdiction-code> and the root <lex-nameserver> of the resolution routing.¶
A new Jurisdictional Registrar will contact CNR or the Designated Expert(s) according to the established rules of governance (published in the CNR website dedicated to the LEX governance). The application will be evaluated according to the Jurisdictional Registrar authoritativeness and the offered guarantees. The Designated Expert(s) will evaluate such applications, with a similar approach as of the DNS. Typically such applications should come from public administrations, as authorities enacting sources of law.¶
The adopted registration policy is compliant with the "Expert Review" as specified in [RFC8126]. Designated Expert(s) will assign jurisdiction codes based on the following principles:¶
Jurisdiction codes can't be renamed, because allowing for renames would violate rules that URN assignments are persistent.¶
Jurisdiction codes can never be deleted. They can only be marked as "obsolete", i.e. closed for new assignments within the jurisdiction. Requests to obsolete a jurisdiction code are also processed by Designated Expert.¶
Designated Expert(s) can unilaterally initiate allocation or obsolescence of a jurisdiction code.¶
Request for new jurisdiction code assignment must include Organization or Country requesting it and Contact information (email) of who requested the assignment.¶
The "lex" NID syntax conforms to [RFC8141]. However, a series of characters are reserved to identify elements or sub-elements, or for future extensions of the LEX naming convention (see Section 3.2).¶
The Jurisdictional Registrar (or those it delegates) of each adhering country or organization is responsible for the definition or acceptance of the uniform name's primary elements (issuing authority and type of legal measure).¶
This section lists the general features applicable to all jurisdictions.¶
These characters are defined in accordance with the [RFC8141] "Uniform Resource Names (URNs)". For various reasons, later explained, in the "lex" <NSS> only a sub-set of characters is allowed. All other characters are either eliminated or converted.¶
For the full syntax of the uniform names in the "lex" space, please see Appendix A.¶
These characters MUST always and uniquely be used for the purpose assigned below. The first category includes those characters bearing a specific meaning in the general creation of the URI (Uniform Resource Identifier)(see Section 2 of [RFC3986]) such as "%", "?", "#" , etc.¶
The following characters instead are reserved in the specific "lex" namespace: However, the following reserved characters are given special meaning in the specific "lex" namespace:¶
"@" separator of the expression, that contains information on
version and language;
"$" separator of the manifestation, that contains information on
format, editor, etc.;
":" separator of the main elements of the name at any entity;
";" separator of level. It identifies the introduction of an element
at a hierarchically lower level, or the introduction of a
specification;
"+" separator of the repetitions of an entire main element (e.g.,
multiple authorities);
"," separator of the repetitions of individual components in the main
elements, each bearing the same level of specificity (e.g.,
multiple numbers);
"~" separator of the partition identifier in references (e.g.,
paragraph of an article);
"*" and "!" are reserved for future expansions.
¶
To keep backward compatibility with existing applications in some jurisdictions, the "lex" NID syntax does not include the use of the character "/" in this version. This character will be converted into "-" (see Section 5.7 and Appendix B.3.4) or into "." (see Appendix B.4.1).¶
Names belonging to the "lex" namespace are case-insensitive. It is RECOMMENDED that they be created in lower case, but names that differ only in case MUST be considered to be equivalent. (e.g., "Ministry" will be recorded as "ministry").¶
In order to exploit DNS as a routing tool towards the proper resolution system, to keep editing and communication more simple and to avoid character percent-encoding, it is strongly RECOMMENDED that national characters and diacritic signs are turned into base ASCII characters (e.g., the Italian term "sanitU+00E0" converted into "sanita", the French term "ministU+00E8re" converted into "ministere"), in case by transliteration (e.g. "MU+00FCnchen" converted into "muenchen"). This conversion consists of:¶
If this conversion is not acceptable by a specific jurisdiction or is not available in a given language, UTF-8 %-encoding [RFC3629] MUST be used. In this case it should be noted that the generated URN (as some of its parts) can not be used directly for routing through DNS, and therefore the jurisdiction must adopt one of the following strategies:¶
Summarizing, the preference order is the following:¶
The first solution allows native DNS routing, while the other two require a software development for the interface or the routing. However it is up to the specific jurisdiction to choose the preferred solution.¶
Two examples (Latin and Cyrillic alphabet) relating to the different solutions adopted are here reported:¶
a circular adopted by the Municipality of Munich (Rundschreiben der Stadt MU+00FCnchen): - ascii = urn:lex:de:stadt.munchen:rundschreiben:... - utf-8 = urn:lex:de:stadt.mU+00FCnchen:rundschreiben:... - punycode = urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben:...¶
a state law of the Russian Federation (latin: gosudarstvo zakon;
cyrillic: U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435
U+0437U+0430U+043AU+043EU+043D):
- ascii = urn:lex:ru:gosudarstvo:zakon:...
- utf-8 = urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D
U+0438U+0435:U+0437U+0430U+043AU+043EU+043D:...
- punycode = urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme:...
assuming that the Russia jurisdiction-code is expressed
in ASCII ("ru"),
while the Cyrillic version ("U+0440U+0444") has the
puny-code "xn--p1ai".
¶
Abbreviations are often used in law for indicating institutions (e.g. Min.), structures (e.g. Dept.), or legal measures (e.g. Reg.) but not in a uniform way, therefore their expansion is highly RECOMMENDED. (e.g., "Min." is reported as "ministry")¶
Dates are expressed by numbers in the [ISO.8601.1988] format:¶
yyyy-mm-dd
¶
(e.g., "September 2, 99" will be written as "1999-09-02")¶
In this section there are other features related to specific jurisdictions and the implementation of which is RECOMMENDED.¶
All the language connectives (e.g., articles, prepositions, etc.),
the punctuation marks and all the special characters (as apostrophes,
dashes, etc.), when explicitly present, are eliminated (no
transformation occurs in cases of languages with declensions or
agglutinating languages). The words left are connected to each other
by a dot (".") which substitutes the "space".
(e.g., "Ministry of Finances, Budget and of Economic Planning"
becomes "ministry.finances.budget.economic.planning";
"Ministerstvo Finansov" becomes "ministerstvo.finansov")¶
The use of acronyms might be confusing and encourage ambiguity in
uniform names (the same acronym may indicate two different
institutions or structures), therefore their expansion is highly
RECOMMENDED.
(e.g., "FAO" is expanded as "food.agriculture.organization")¶
To even the representation, it is highly RECOMMENDED that any ordinal
number included in a component of a document name (e.g., in the
description of an institution body) is indicated in Western Arabic
numerals, regardless to the original expression: whether in Roman
numerals, or with an adjective, or in Arabic numeral with apex, etc.
(IV, third, 1U+00B0, 2^, etc.).
(e.g., "Department IV" becomes "department.4")¶
The uniform name must identify one and only one document (more precisely a "bibliographic resource" [ISBD], see also Section 5.2) and is created in such a way that it is:¶
According to [FRBR] (Functional Requirements for Bibliographic Records) model developed by IFLA (International Federation of Library Associations and Institutions), in a source of law, as in any intellectual production, 4 fundamental entities (or aspects) can be specified.¶
The first 2 entities reflect its contents:¶
while the other 2 entities relate to its form:¶
In this document the [FRBR] model has been interpreted for the specific characteristics of the legal domain. In particular, apart from the language which does produce a specific expression, the discriminative criterion between expression and manifestation is based on the difference of the juridical effects that a variation can provide with respect to the involved actors (citizens, parties, institutions). In this scenario the main characteristic of the expression of an act is represented by its validity over the time, during which it provides the same juridical effects. These effects change for amendments or annulments of other legislative or jurisprudential acts. Therefore notes, summarizations, comments, anonymizations and other editorial activities over the same text do not produce different expressions, but different manifestations.¶
The <local-name> within the "lex" namespace MUST contain all the necessary pieces of information enabling the unequivocal identification of a legal document. If the <local-name> violates this requirement, the related URN is not a valid one within the "lex" namespace.¶
In the legal domain, at the "work" level, three components are always present: the enacting authority, the type of provision and the details. A fourth component, the annex, can be added if any. It is often necessary to differentiate various expressions, that is:¶
Finally the uniform name allows a distinction among diverse manifestations, which may be produced by multiple publishers using different means and formats.¶
In the every case, the basic identifier of the source of law (work) remains the same, but information is added regarding the specific version under consideration (expression); similarly a suffix is added to the expression for representing the characteristics of the publication (manifestation).¶
Information which forms a source of law uniform name at each level (work, expression, manifestation) is expressed in the official language of the related jurisdiction; in case of multiple official languages (as in Switzerland) or more involved jurisdictions (as in international treaties), more language-dependent names (aliases) are created.¶
Therefore, the more general structure of the local name appears as follows:¶
local-name = work ["@" expression] ["$" manifestation]
¶
However, consistent with legislative practice, the uniform name of the main original provision (work) becomes the identifier of an entire class of documents which includes: the original main document, the annexes, and all their versions, languages and formats subsequently generated.¶
The structure of the document identifier is made of the four fundamental elements mentioned above, clearly distinguished one from the other in accordance with an order identifying increasingly narrow domains and competences:¶
work = authority ":" measure ":" details *(":" annex)
¶
where:¶
In case of annexes, both the main document and its annexes have their own uniform name so that they can individually be referenced; the identifier of the annex adds a suffix to that of the main document. In similar way the identifier of an annex of an annex adds an ending to that of the annex which it is attached to.¶
The main elements of the work name are generally divided into several elementary components, and, for each, specific rules of representation are established (criteria, modalities, syntax and order). For the details regarding each element, please see the Appendix B. Examples (hypothetical) of <work> identifiers are:¶
urn:lex:it:stato:legge:2006-05-14;22
urn:lex:uk:ministry.justice:decree:1999-10-07;45
urn:lex:ch;glarus:regiere:erlass:2007-10-15;963
urn:lex:es:tribunal.supremo:decision:2001-09-28;68
urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762
urn:lex:br:estado:constituicao:1988-10-05;lex-1
urn:lex:un.org:united.nations;general.assembly:resolution:
1961-11-28;a-res-1661
urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581
¶
It is worth to note that the type of measure is important to identify case law, as well as legislation, especially within the legal systems where cases, by tradition, are identified only through the year of release and a number. Since the aim of the "urn:lex" schema is to identify specific materials, the type of measure or the full date are able to provide discrimination between materials belonging to a specific case.¶
Here below is an example where the type of measure or the full date are essential for identify specific materials of a case:¶
- 4/59 Judgement of the EEC Court of Justice 04/04/1960, Mannesmann AG and others / ECSC High Authority urn:lex:eec.lex.arpa:court.justice:judgement:1960-04-04;4-59 - 4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG and others / ECSC High Authority urn:lex:eec.lex.arpa:court.justice:order:1960-05-18;4-59¶
International treaties involve more jurisdictions (the signing ones)
so they are represented through more identifiers, each of them related
to an involved jurisdiction. For example, a bilateral France and
Germany treaty is identified through two URNs (aliases) belonging to
either "fr" or "de" jurisdiction
(e.g., "urn:lex:fr:etat:traite:..." and "urn:lex:de:staat:vertrag:...")
since it pertains to both the French and the German jurisdiction.¶
In the states or organisations that have more than one official
language, a document has more identifiers, each of them expressed in
a different official language, basically a set of equivalent aliases.
This system permits manual or automated construction of the uniform
name of the referred source of law in the same language used in the
document itself.
(e.g., "urn:lex:eu:council:directive:2004-12-07;31",
"urn:lex:eu:consiglio:direttiva:2004-12-07;31", etc.)¶
Moreover, a document can be assigned more than one uniform name in order to facilitate its linking from other documents. This option can be used for documents that, although unique, are commonly referenced from different perspectives. For example, the form of a document's promulgation and its specific content (e.g., a Regulation promulgated through a Decree of the President of the Republic).¶
There may be several expressions of a legal text, connected to specific versions or languages.¶
Each version is characterized by the period of time during which that text is to be considered as the valid text (in force or effective). The lifetime of a version ends with the issuing of the subsequent version. New versions of a text may be brought into existence by:¶
Each of such versions may be expressed in more than one language, with each language-version having its own specific identifier. The identifier of a source of law expression adds such information to the work identifier, using the following main structure:¶
expression = version [":" language]
¶
where:¶
Examples (hypothetical) of document identifiers for expressions are:¶
urn:lex:ch:etat:loi:2006-05-14;22@originel:fr
(original version in French)
urn:lex:ch:staat:gesetz:2006-05-14;22@original:de
(original version in German)
urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr
(amended version in French)
urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de
(amended version in German)
urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr
(original version in French of a Belgian decision)
¶
To identify a specific manifestation, the uniform name of the expression is followed by a suitable suffix containing the following main elements:¶
The <manifestation> suffix will thus read:¶
manifestation = editor ":" format
[":" component [":" feature]]
¶
To indicate possible features or peculiarities, each main element of the manifestation MAY be followed by further specifications (separated by ";"), for example as regards <editor> the archive name and the electronic publisher, for <format> the version, etc. Therefore the main elements of the manifestation will assume the forms:¶
editor = publisher *(";" specification)
format = mime *(";" specification)
component = part *(";" specification)
feature = attribute *(";" specification)
¶
The syntax details of the <manifestation> element is shown in Appendix A, in the related section.¶
(examples (hypothetical):¶
the original version the Italian act 3 April 2000, n. 56 might have the following manifestations with their relative uniform names:¶
- PDF format (vers. 1.7) of the whole act edited by the Italian Parliament: "urn:lex:it:stato:legge:2000-04-03;56$application-pdf; 1.7:parlamento.it" - XML format (version 2.2 DTD NIR) of the text of the act and PDF format (version 1.7) of the "Figura 1" (figure 1) contained in the body, edited by the Italian Senate: "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir-2.2: senato.it:testo" "urn:lex:it:stato:legge:2000-04-03;56$application-pdf;1.7: senato.it:figura.1"¶
the Spanish URN of the html format of the whole Judgement of the European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, published in the Jurifast data base in anonymized form:¶
"urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08 @original:es$text-html:juradmin.eu;jurifast:todo:anonimo")¶
Furthermore, it is useful to be able to assign a uniform name to a manifestation (or to a part of it) in case non-textual objects are involved. These may be multimedia objects that are non-textual in their own right (e.g. geographic maps, photographs, etc.), or texts recorded in non-textual formats, such as image scans of documents.¶
In these ways, a LEX name permits:¶
References to sources of law often refer to specific partitions of the act (article, paragraph, etc.) and not to the entire document.¶
From a legal point of view, a partition is always a text block, that represents a logical subdivision of an act.¶
As regards the digital representation, in a structured format (as XML) perfectly fitting the document logical structure, a partition is represented by an element (a block of text) with its own ID; this ID aims to identify the related element and to locate it. In this case, therefore, it is possible either to extract or to point to a partition.¶
In a mark-up not fitting the logical structure of the text (as HTML), generally only the starting point of the partition, rather than the whole block of text or element, is identified through a label (a <a id=partitionID></a> tag in Html Markup Language [W3C.HTML]). In this case therefore it is not possible to extract a partition but only to point to it.¶
In both cases, having a partition identifier is useful; therefore, for allowing browsers to point to a specific partition, it is necessary that such partition is endowed with an unequivocal label or ID within the including document and its value is the same independently from the document format.¶
For enabling the construction of the partition identifier between different collections of documents, specific construction rules for IDs or labels will be defined and shared, within each country or jurisdiction, for any document type (e.g., for legislation, the paragraph 2 of the article 3 might have as label or ID the value "art3;par2", similarly for case-law, paragraph 22 of the judgement in Case 46/76 Bauhuis v Netherlands, might have as label or ID the value "par22").¶
Furthermore, it is useful to foresee the compatibility with applications able to manage this information (e.g., returning the proper element); these procedures are particularly useful in the case of rather long acts, such as codes, constitutions, regulations, etc. For this purpose it is necessary that the partition identifier is transmitted to the servers (resolution and application) and therefore it cannot be separated by the typical "#" character of URI fragment, which is not transmitted to the server.¶
According to these requirements, the syntax of a reference is:¶
URN-reference = URN-document ["~" partition-id]
¶
(e.g., to refer to the paragraph 3 of the article 15 of the French Act of 15 may 2004, n. 106, the reference can be "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3").¶
Using a different separator ("~") from the document name, the partition ID is not withheld by the browser but it is transmitted to the resolution process. This enables the resolver to retrieve (for example, out of a database) only the referred partition, if the partition syntax is compatible with the media type used, otherwise to return the whole act.¶
To make it effective in a browser pointing to the indicated partition, the resolver SHOULD transform the partition ID of each returned URL in a URI fragment. If this operation cannot be accomplished, the browser is positioned at the beginning of the document. The transformation in URI fragment is obtained appending to the URL the "#" character followed by the partition ID (in the example above, the returned URL will be <URL-document>#art15;par3). Doing this, knowing the granularity of the act markup, the resolver could exploit the hierarchical structure of the ID, eliminating sub- partitions not addressed. If only the article was identified in the act, in the previous example it could return <URL-document>#art15 only.¶
It is possible to use the general syntax (with "#"); in this case only the URN document component of the reference is transmitted to the resolver, therefore the whole document will be always retrieved.¶
Under the "lex" namespace, each country or international organization is assigned with a jurisdiction code, which characterizes the URNs of the source of law of that country or jurisdiction. This code is assigned according to ccTLD (as well as TLDN (Top Level Domain Name) or DN (Domain Name) for the organizations) representation and it is the value of the <jurisdiction-code> element, which preserves cross- country uniqueness of the identifiers.¶
Any country or jurisdiction, who intends to adopt this schema, MUST
identify a Jurisdictional Registrar, an organization which shares and
defines the structure of the optional part (<jurisdiction-unit>) of
the name, according to the organization of the state or institution
(for details see Section 2.2). It must appoint a Jurisdictional
Registrar and inform the Designed Experts, together with the
registration of a jurisdiction code. For example, in a federal state
a <jurisdiction-unit> corresponding to the name of each member state
(e.g. "br;sao.paolo", "br;minas.gerais", etc.) may be defined.¶
The process of assigning the <local-name> will be managed by each specific country or jurisdiction under the related <jurisdiction> element.¶
In any country the Jurisdictional Registrar shares and defines the assignment of the primary elements (issuing authority and type of legal measure) of the local names considering the characteristics of its own state or institution organization.¶
Such a Registrar MUST establish, according to the guidelines indicated in the current document, a uniform procedure within the country or organization to define <local-name> elements, to take decisions upon normalizations and finally to solve and avoid possible name collisions as well as to maintain authoritative registries of various kinds (e.g., for authorities, types of measures, etc.). In particular, accurate point-in-time representations of the structure and naming of government entities are important to semantically-aware applications in this domain.¶
Moreover, the Registrar shares and defines the rules to construct partition IDs for each document type.¶
Finally, the Registrar will develop and publish the rules and the guidelines for the <local-name> construction as well as the predefined values and codes. The Registrar should also promote the urn:lex identifier for the sources of law of its jurisdiction.¶
Such a set of rules will have to be followed by all institutional bodies adopting the URN LEX identification system in a country or jurisdiction, as well as by private publishers, and each of them will be responsible for assigning names to their domains.¶
Identifiers in the "lex" namespace are defined through a <jurisdiction> element assigned to the sources of law of a specific country or organization, and a <local-name> assigned by the issuing authority, in conformance with the syntax defined in Section 5. The main elements (authority and type of measure) of the <local-name> are defined by the Jurisdictional Registrar, so that it is ensured that the constructed URNs are unique. The Jurisdictional Registrar MUST provide clear documentation of rules by which names are to be constructed, and MUST update and make accessible its registries.¶
Any issuing authority is responsible to define formal parameters to guarantee local name uniqueness by attributing, if necessary, a conventional internal number, which, combined with the other <local- name> components (authority, measure and date), builds an unequivocal identifier. Uniqueness is achieved by checking against the catalogue of previously assigned names.¶
The persistence of identifiers depends on the durability of the institutions that assign and administer them. The goal of the LEX schema is to maintain uniqueness and persistence of all resources identified by the assigned URNs.¶
In particular, the CNR, as proposer, is responsible of maintaining the uniqueness of the <jurisdiction> element; given that the <jurisdiction> is assigned on the basis of the long-held ccTLD representation of the country (or the TLDN or DN of the organization) and that the country or organization associated code is expected to continue indefinitely, the URN also persists indefinitely.¶
The rules for the construction of the name are conceived to delegate the responsibility of their uniqueness to a set of authorities which is identified within each country or organization.¶
Therefore, each authority is responsible for assigning URNs which have a very long life expectancy and can be expected to remain unique for the foreseeable future. Practical and political considerations, as well as diverse local forms of government organization, will result in different methods of assigning responsibility for different levels of the name.¶
Where this cannot be accomplished by the implementation of an authoritative hierarchy, it is highly desirable that it be done by creating consensus around a series of published rules for the creation and administration of names by institutions and bodies that operate by means of collaboration rather than compulsion.¶
Issuing authorities that operate in more localized scopes, ranging from the national down to the very local, MUST equally take responsibility for the persistence of identifiers within their scope.¶
The task of the resolution service is that of associating a LEX identifier with a specific document address on the network. By contrast with systems that can be constructed around rigorous and enforceable engineering premises, such as DNS, the "lex" namespace resolver will be expected to cope with a wide variety of "dirty" inputs, particularly those created by the automated extraction of references from incomplete or inaccurate texts. In this document, the result is a particular emphasis on a flexible and robust resolver design.¶
The system has a distributed architecture based on two fundamental components: a chain of information in DNS (Domain Name System) and a series of resolution services from URNs to URLs, each competent within a specific domain of the namespace.¶
The client retrieves the document associated with this URN using the procedure described in [RFC3404], which starts with a DNS NAPTR query.¶
A resolution service can delegate the resolution and management of hierarchically-dependent portions of the name. Delegation of this responsibility will not be unreasonably withheld provided that the processes for their resolution and management are robust and are followed.¶
For the "lex" namespace, CNR will maintain in the <lex-nameserver> (see Section 9 the root zone of the chain resolution (equivalent to "lex.urn.arpa" (see [RFC3405]) and, in correspondence with the adhesion (see Section 2.2) of a new country (e.g., "br") or organization, will update the DNS information with a new record to delegate the relative resolution. This may be obtained by a regular expression that matches the initial part of the URN (e.g., "urn:lex:br") and redirects towards the proper zone (e.g., "lex.senado.gov.br").¶
Likewise the institution responsible for the jurisdiction uniform names (e.g., "urn:lex:br") has the task of managing the relative root in the DNS system (e.g., "lex.senado.gov.br" zone) and routing the resolution towards its resolvers on the basis of parts of the uniform names. In similar way it can delegate the resolution of country/organization sub-levels (e.g., "urn:lex:br;sao.paolo") towards the relative zone (e.g., "lex.sao-paolo.gov.br").¶
Such DNS routing chain does not work for all the URN components containing %-encoded characters. Therefore, when converting a lex:URN in UTF-8 code to a DNS query, clients MUST perform punycode conversion [RFC5891] before sending the query.¶
The resolution service is made up of two elements: a knowledge base (consisting in a catalogue or a set of transformation rules) and a software to query the knowledge base itself.¶
Incompleteness and inaccuracy are rather frequent in legal citations, and incomplete or inaccurate uniform names of the referred document are thus likely to be built from textual references (this is even more frequent if they are created automatically through a specific parser). For this reason, the implementation of a catalogue, based on a relational-database, is suggested, as it will lead to a higher flexibility in the resolution process.¶
In addition the catalogue must manage the aliases, the various versions and languages of the same source of law as well as the related manifestations.¶
It is suggested that each enacting authority implements its own catalogue, assigning a corresponding unambiguous uniform name to each resource.¶
First of all the resolver should separate the part corresponding to the partition ID, through the "~" separator, from the document name.¶
So, the resolution process SHOULD implement a normalization of the uniform name to be resolved. This may involve transforming some components to the canonical form (e.g., filling out the acronyms, expanding the abbreviations, unifying the institution names, standardizing the type of measures, etc.). For this function authorities and types of measure registers are useful.¶
The resolver SHOULD then query the catalogue searching for the URN which corresponds exactly to the given one (normalized if necessary). Since the names coming from the references may be inaccurate or incomplete, an iterative, heuristic approach (based on partial matches) is indicated. It is worth remarking that incomplete references (not including all the elements to create the canonical uniform name) are normal and natural; for a human reader, the reference would be "completed" by contextual understanding of the reference in the document in which it occurs.¶
In this phase, the resolver should use the partition ID information to retrieve, if it is possible, only the referred partition, otherwise to return of the entire document.¶
Lacking more specific indications, the resolver SHOULD select the best (most recent) version of the requested source of law, and provide all the manifestations with their related items. A more specific indication in the uniform name to be resolved will, of course, result in a more selective retrieval, based on any suggested expression and/or manifestations components (e.g. date, language, format, etc.).¶
Finally, the resolver SHOULD append to URLs the "#" character followed by partition ID, transforming it in a URI fragment for browser pointing.¶
In collaboration with the legislative XML community, registrants carried out a preliminary study [SART] of the URI alternatives to satisfy the key requirements.¶
The options analysed were: a private URI scheme, URL, PURL and URN. URN was considered the most appropriate URI given the requirements analysis.¶
Advantages we would emphasize are:¶
The use of the "lex" namespace facilitates the interoperability of information systems used in the Public Administration at the national and international level. Moreover it allows the distribution of the legal information towards a federated architecture. In such an architecture, documents are directly managed by the issuing authorities, with resulting benefits in information authenticity, quality and currency. A shared identification mechanism of resources guarantees that a distributed system will be as efficient and effective as a comparable centralized system.¶
Creators of Internet content that references legal materials - including publishers operating well outside the traditional arenas of legal publishing - benefit by the registration of the namespace because it facilitates the linking of legal documents, whether by manual or automated means, and reduces the cost of maintaining documents that contain such references.¶
Any citizen or organisation with Internet web browser capability will have the possibility to use the namespace and its associated application, registers, and resolution services, to facilitate document access (if available).¶
IANA has already registered the "lex" namespace, according to the template at section 2. Registration has been accomplished as the Formal URN Namespace registry described by [RFC8141].¶
In addition, to activate a distributed resolution system, the one-off registration of the following NAPTR records is requested:¶
in the URN.ARPA domain:¶
IN NAPTR 1 0 "" "" "!^urn:lex:!_lex!i" .
_lex IN NAPTR 10 10 "" "" "" \<lex-nameserver>.
¶
in the URN.URI.ARPA domain:¶
IN NAPTR 1 0 "" "" "!^urn:lex:!_lex!i" .
_lex IN NAPTR 10 10 "" "" "" \<lex-nameserver>.
¶
where <lex-nameserver> indicates the server of the organization that is responsible for the resolution of the "lex" namespace and will be communicated by the applicant when the application is approved.¶
The authors of this document wish to thank all the supporters for giving suggestions and comments.¶
They are also grateful to the Legislative XML community for the interesting discussions on this topic and to the Working Group "Identification of the legal resources through URNs" of Italian NormeInRete project for the provided guidance [SPIN].¶
The authors owe a debt of gratitude to Tom Bruce, director of the Legal Information Institute of the Cornell University Law School, for his contribution in revising this document and sharing fruitful discussions which greatly improved the final draft. The authors wish to specially thank Marc van Opijnen (Dutch Ministry of Security and Justice) for his valuable comments on LEX specifications which contributed to improve the final result, as well as for the common work aimed to harmonize ECLI and LEX specifications. Thanks also to Joao Alberto de Oliveira Lima, legislative system analyst of the Brazilian Federal Senate, and to Attila Torcsvari, information management consultant, for their detailed comments on the first drafts of this document, which provided significant hints to the final version of the standard, and to Robert Richards of the Legal Information Institute (Cornell University Law School), promoter and maintainer of the Legal Informatics Research social network, as well as to the members of this network, for their valuable comments on this proposal.¶
Finally, many thanks go to Loriana Serrotti who significantly contributed to the first drafting of this document.¶
;-------------------------------------------------------------------
; Structure of a Uniform Resource Name (URN) of the "lex" namespace
; - NID-lex = namespace
; - NSS-lex = specific name
;-------------------------------------------------------------------¶
URN-lex = "urn:" NID-lex ":" NSS-lex NID-lex = "lex"¶
;-------------------------------------------------------------------
; Structure of a "lex" specific name
;-------------------------------------------------------------------¶
NSS-lex = jurisdiction ":" local-name¶
;-------------------------------------------------------------------
; Structure of the <jurisdiction> element
;-------------------------------------------------------------------¶
jurisdiction = jurisdiction-code *(";" jurisdiction-unit)
jurisdiction-code = 2*alf-dot
jurisdiction-unit = alf-dot
¶
;-------------------------------------------------------------------
; Structure of the <local-name> element
;-------------------------------------------------------------------¶
local-name = work ["@" expression] ["$" manifestation]¶
;-------------------------------------------------------------------
; Structure of the <work> element
;-------------------------------------------------------------------¶
work = authority ":" measure ":" details *(":" annex)
¶
;-------------------------------------------------------------------
; Structure of the <authority> element
;-------------------------------------------------------------------¶
authority = issuer *("+" issuer)
issuer = (institution *(";" body-function)) / office
institution = alf-dot
body-function = alf-dot
office = alf-dot
¶
;-------------------------------------------------------------------
; Structure of the <measure> element
;-------------------------------------------------------------------¶
measure = measure-type *(";" specification)
measure-type = alf-dot
specification = alf-dot
¶
;-------------------------------------------------------------------
; Structure of the <details> element
;-------------------------------------------------------------------¶
details = (dates / period) ";" numbers
dates = date *("," date)
period = alf-dot
numbers = (document-id *("," document-id)) / number-lex
document-id = alf-dot-oth
number-lex = "lex-" 1*DIGIT
¶
;-------------------------------------------------------------------
; Structure of the <annex> element
;-------------------------------------------------------------------¶
annex = annex-id *(";" specification)
annex-id = alf-dot
¶
;-------------------------------------------------------------------
; Structure of the <expression> element
;-------------------------------------------------------------------¶
expression = version [":" language]¶
;-------------------------------------------------------------------
; Structure of the <version> element
;-------------------------------------------------------------------¶
version = (amendment-date / specification)
*(";" (event-date / event))
amendment-date = date
event-date = date
event = alf-dot
¶
;-------------------------------------------------------------------
; Structure of the <language> element
;-------------------------------------------------------------------¶
language = 2*3alfa *["-" extlang] / 4*8alfa
extlang = 3alfa *2("-" 3alfa)
¶
;-------------------------------------------------------------------
; Structure of the <manifestation> element
;-------------------------------------------------------------------¶
manifestation = format ":" editor
[":" component [":" feature]]
format = mime *(";" specification)
mime = alf-dot-hyp
editor = publisher *(";" specification)
publisher = alf-dot-hyp
component = part *(";" specification)
part = alf-dot-hyp
feature = attribute *(";" specification)
attribute = alf-dot-hyp
¶
;-------------------------------------------------------------------
; Structure of the date
;-------------------------------------------------------------------¶
date = year "-" month "-" day year = 4DIGIT month = 2DIGIT day = 2DIGIT¶
;-------------------------------------------------------------------
; Allowed, reserved and future characters
;-------------------------------------------------------------------
; - allowed = alfadot / other / reserved
; - reserved = ":" / "@" / "$" / "+" / ";" / "," / "~"
; - future = "*" / "!"¶
alf-dot = alfanum *alfadot
alf-dot-hyp = alfanum *(alfadot / "-")
alf-dot-oth = alfanum *(alfadot / other)
alfadot = alfanum / "."
alfa = lowercase / uppercase
alfanum = alfa / DIGIT / encoded
lowercase = %x61-7A ; lower-case ASCII letters (a-z)
uppercase = %x41-5A ; upper-case ASCII letters (A-Z)
DIGIT = %x30-39 ; decimal digits (0-9)
encoded = "%" 2HEXDIG
HEXDIG = DIGIT / %x41-46 / %x61-66 ; hex digits (0-9,A-F,a-f)
other = "-" / "_" / "'" / "=" / "(" / ")"
¶
In uniform names the issuing authority of a document is mandatory. This makes unnecessary to indicate any further qualification of the measure (e.g., ministerial decree, directorial ordinance, etc.), even if it is widely used. When the authority-measure combination clearly identifies a specific document, the type of measure is not defined through attributes referring to the enacting authority. (e.g., "region.tuscany:act" and not "region.tuscany:regional.act")¶
In the <measure> element, it is usually sufficient to indicate the type of a measure. As usual, references to sources of law, rather than through the formal details (date and number), may be made through some of their characteristics such as the subject-matter covered (e.g., accounting regulations), nicknames referring to the promoter (e.g., Bassanini Act) or to the topic of the act (e.g., Bankruptcy Law), etc.. In these cases, the type of measure MAY be followed by further specifications useful in referencing even if the details are lacking:¶
measure = measure-type *(";" specification)
¶
(e.g., "regulations;accounting" or "act;bankruptcy")¶
There are legislative measures that, although unique, are usually cited in different ways, for example through the legislative act introducing them into the legal order (President's decree, legislative decree, etc.) or through their legislative category (regulations, consolidation, etc.). In order to ensure, in all the cases, the validity of the references, an alias (additional URN LEX identifier), that takes into account the measure category, is added to what represents the legislative form of the same act.¶
(e.g., "state:decree.legislative:1992-07-24;358" and "state:consolidation;public.contracts:1992-07-24;358").¶
The details of a source of law usually include the date of the enactment and the identification number (inclusion in the body of laws, register, protocol, etc.).¶
Some measures can have multiple dates; there are also cases in which the number of the measure does not exist (unnumbered measures) or a measure has multiple numbers (e.g., unified cases). For these reasons, the set up of both elements (date and number) includes multiple values.¶
Some institutions (e.g., the Parliaments) usually identify documents through their period of reference (e.g., the legislature number) rather than through a date, which would be much less meaningful and never used in references (e.g., Senate bill S.2544 of the XIV legislature). In these cases, the component <period> is used in substitution of the component <dates>.¶
Usually details of a measure are not reported according to a specific sequence; in accordance with the global structure of the uniform name, which goes from the general to the specific, the sequence date- number has the following form:¶
details = (dates / period) ";" numbers
¶
(e.g., "2000-12-06;126", "14.legislature;s.2544")¶
Some sources of law, even if unique, are identified by more than one date; in this case, in the field <dates> all the given dates are to be reported and indicated as follows:¶
dates = date *("," date)
¶
(e.g., the measure of the Data Protection Authority of December 30, 1999- January 13, 2000, No. 1/P/2000 has the following uniform name: "personal.data.protection.authority:measure:1999-12-30,2000-01-13; 1-p-2000").¶
Measures not officially numbered in the publications may have a non- unequivolcal identifier, because several measures of the same type can exist, issued on the same day by the same authority. To ensure that the uniform name is unambiguous, the <numbers> field MUST, in any case, contain a discriminating element, which can be any identifier used internally, and not published, by the authority (e.g., protocol).¶
If the authority does not have its own identifier, one identifier MUST be created for the name system. In order to easily differentiate it, such number is preceded by the string "lex-":¶
number-lex = "lex-" 1*DIGIT¶
(e.g., "ministry.finances:decree:1999-12-20;lex-3")¶
It is responsibility of the authority issuing a document to assign a discriminating specification to it; in case of multiple authorities, only one of them is responsible for the assignment of the number to the document (e.g., the proponent).¶
The unnumbered measures published on an official publication (e.g., the Official Gazette), instead of by a progressive number are recognized by the univocal identifying label printed on the paper. Such an identifier, even if unofficial but assigned to a document in an official publication, is to be preferred because it has the clear advantage to be public and therefore easier to be found.¶
Some legal documents (e.g., bills), even if unique, are identified by a set of numbers (e.g., the unification of cases or bills). In this case, in the <numbers> field, all the identifiers are reported, according to the following structure:¶
numbers = document-id *("," document-id)
¶
(e.g., "2000-06-12;c-10-97,c-11-97,c-12-97")¶
The characters which are not allowed (e.g., "/") or reserved (e.g., ":"), including the comma, cannot exist inside the <document-id>, and therefore MUST be turned into "-".¶
Where special characters contained in the number of the act are distinctive of the act itself (e.g. bill n. 123-bis (removal of 123) and n. 123/bis (return of 123)) and would disappear with the conversion to "-", a further ending must be added, allowing to distinguish the acts (e.g. bill n.123-bis-removal and 123-bis- return).¶
Although annexes are an integral part of the legal document, they may be referred to and undergo amendments separately from the act to which they are annexed. It is, therefore, necessary that both the main document as well as each formal individual annex is unequivocally identified.¶
Formal annexes may be registered as separate parts or together with a legal provision; they may also be autonomous in nature or not. In any case, they MUST be given a uniform name, which includes the uniform name of the source of law to which they are attached, and a suffix which identifies the annex itself.¶
The suffix of formal annexes includes the official heading of the annex and, possibly, further specifications (e.g., the title) which will facilitate the retrieval of the annex in case the identifier is missing:¶
annex = annex-id *(";" specification)
¶
(e.g., "region.sicily;council:deliberation:1998-02-12;14:annex.a; borders.park")¶
The characters which are not allowed (e.g. "/") or which are reserved (e.g. ":") must not be featured in the <annex-id> and therefore MUST be turned into ".".¶
When there are annexes to an annex, their corresponding identifiers are created by adding to the identifier of the original annex those of the annexes that are connected with it (that is, attached to it).¶
(e.g., Table 1 attached to the Annex A of the preceding legal act has the following uniform name: "region.sicily;council:deliberation:1998-02-12;14:annex.a; borders.park:table.1;municipality.territories").¶
The creation of an updated text of a document may have one of the following forms:¶
In a "multi-version" document each time interval should have a link to the related in-force document version which can be therefore displayed. In a "single-version" document, the metadata should contain links to the all the previous modifications and a link only to the following version, if any.¶
[RFC8288] can be used as reference to establish links between different document versions, either in the "multi-version" or in the¶
"single-version" document. According to [RFC8288] the following relations are useful:¶
It is RECOMMENDED that these relations are inserted in the header of each version (if "single-version") or associated to each entry containing a single URN (if "multi-version").¶
In order to identify the different time versions of the same act, to the uniform name of the original document has to be added a specific suffix.¶
Such a suffix identifies each version of a legal provision and includes, first and foremost, one of the following elements:¶
It is possible to add further specifications that will distinguish each of the different versions of the text to guarantee identifier unequivocalness. For example with regard to changes of the in-force or effectiveness of any partition or portion of the text itself (e.g., when the amendments introduced by an act are applied at different times) or different events occurring in the same date.¶
version = (amendment-date / specification)
*(";" (event-date / event))
¶
where:¶
The issuing date of an amending act was chosen as identifier of a version because it can be obtained from the heading (formal data).¶
(e.g., the name "state:royal.decree:1941-01-30;12@1998-02-19" identifies the updated text of the "Royal Decree of 30/1/1941, No. 12" with the amendments introduced by the "Law Decree of 19/2/1998, No. 51", without any indication of its actual entry into force. The same uniform name with the additional ending ";1999-01-01" indicates the in-force or effective version starting in a different date (from 1/1/99).¶
For a full compatibility, every updating of a text or of the effectiveness of a "multi-version" document implies the creation of a new uniform name, even if the object remains only one, containing the identifier of the virtually generated version, exactly as in the case of a "single-version" document. A specific meta-data will associate every uniform name with the period of time during which such a name together with its corresponding text is to be considered valid.¶
(e.g., the multi-version document containing the "R.D. of 01/30/1941, no. 12", updated by the amendments introduced by the "D.Lgs. of 02/19/1998, no. 51", contains the name of the original "state:royal.decree:1941-01-30;12" as well as the name of the updated version "state:royal.decree:1941-01-30;12@1998-02-19").¶
Please note that in case of attachments or annexes, the creation of a new version (even in the case of only one component) would imply the creation of a new uniform name for all the connected objects in order to guarantee their alignment (i.e., the main document, the attachments and annexes).¶