1.1. Purpose of the "lex" Namespace

The purpose of the "lex" namespace is to assign a unique identifier in a well-defined format to documents that are sources of law. In this context, "sources of law" include any legal document within the domain of legislation, case law, administrative acts, or regulations. Potential sources of law (acts under the process of law formation, such as bills) are included as well. "Legal doctrine", that is, the body of knowledge and theoretical speculation typical of legal scholars (e.g., commentary on judgment, jurisprudence review, commentary on legislation, encyclopedic entries, monographs, articles in magazines, manuals, etc.) is explicitly not covered.¶

The identifier is conceived so that its construction depends only on the content of the document itself and not its online availability, physical location, and access mode. The identifier itself is assigned by the jurisdiction of the identified document. A document that is not available online may, nevertheless, have a LEX URN identifier.¶

The lex URN may be used as a way to represent references (and more generally, any type of relation) among various sources of law. In an online environment with resources distributed among different web publishers, lex URNs allow a simplified global interconnection of legal documents by means of automated resolution. LEX URNs consist of persistent and location-independent identifiers and are particularly useful when they can be mapped into or associated with locators such as HTTP URLs. Moreover, LEX URN details can be used as a reference to create persistent and location-independent identifiers that are HTTP-based [RFC3986].¶

1.2. Background

This specification of a unique identifier for legal documents follows a number of initiatives in the field of legal document management.¶

Since 2001, the Italian Government promoted the NormeInRete project through the National Center for Information Technology in the Public Administration, the Ministry of Justice, and the National Research Council of Italy (CNR). The NormeInRete project was aimed at introducing standards for describing and identifying sources of law using XML and URN techniques.¶

Other national initiatives in Europe introduced standards for the description of legal sources [FRAN]. Collaborations 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 of 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 (EU) member states, as well as the increasing integration of the worldwide legal and economic processes, are causing a growing interest in the exchange of legal information knowledge at national and transnational 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 an 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. In several conferences (such as [LVI]), representatives of the Publications Office of the European Union (OP) have expressed the need for a unique identifier for sources of law, based on open standards and able to provide advanced modalities of document hyperlinking, 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] encourages 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 the European level, towards the definition of a standard interchange format for sources of law, including recommendations for defining naming conventions for them.¶

Additionally, the need for unique identifiers for sources of law is of particular interest in the domain of case law. This is acutely felt within both common law systems, where cases are the main law sources, and civil law systems, in order to provide 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 of (directly applicable) EU laws and also 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 Council of the European Union has underlined the importance of cross-border access to national case law, as well as the need for its standardization, 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, in 2009, the Council of the European Union decided to elaborate on a uniform European system for the identification of case law (i.e., the European Case-Law Identifier (ECLI)) and a uniform set of metadata based on the Dublin Core.¶

The Council of the European Union invited the Member States to introduce the European Legislation Identifier (ELI) in the legal information systems, which is an http-based, Semantic Web-oriented identification system for legislation of the European Union and Member States.¶

The LEX identifier (also referred to in this text as "LEX name") is conceived to be general enough to provide guidance at the core of the standard and offer sufficient flexibility to cover a wide variety of needs for identifying legal documents of different types, 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).¶

Specifications and syntax rules for the LEX identifier can also be used for http-based naming conventions to cope with different requirements in legal information management, for example, the need to have an identifier that is 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.¶

1.3. General Characteristics of the System

The specifications in this document promote interoperability among legal information systems by defining a namespace convention and structure that will create and manage identifiers for legal documents. The identifiers are intended to have the following qualities:¶

• globally unique¶

• transparent¶

• reversible¶

• persistent¶

• location-independent¶

• language-neutral¶

These qualities facilitate management of legal documents and a mechanism for stable cross-collection and cross-country references.¶

Transparency means that, for a given act and its relevant metadata (issuing authority, type of measure, etc.), it is possible to create a related URN that is able to uniquely identify the act in a way that is reversible (from an act to its URN and from a URN to the act).¶

Language neutrality, in particular, is an important feature that promotes adoption of the standard by organizations that must adhere to official language requirements. This specification provides 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.¶

The challenge is to provide the right amount guidance at the core of the specification while providing sufficient flexibility to cover a wide variety of needs. LEX does this by splitting the identifier into parts. The first part uses a preexisting 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.¶

The second part depends only on the identification system for sources of law 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:¶

• A schema for assigning names capable of unambiguously representing any addressed source of law (namely legislation, case law, and administrative acts) issued by any authority (intergovernmental, supranational, national, regional, and local) at any time (past, present, and future).¶

• A resolution mechanism -- in a distributed environment -- that ties a uniform name to the online location of the corresponding resource(s).¶

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.¶

1.4. Linking a LEX Name to a Document

The LEX name is linked to the document through meta-information, which may be specified as follows:¶

• Within the document itself through a specific element within an XML schema or by a meta tag [W3C.HTML].¶

• Externally by means of a Resource Description Framework [W3C.RDF-SCHEMA] triple, a specific attribute in a database, etc.¶

At least one of these references is necessary to enable automated construction, an update of catalogues (distributed and centralized), and the implementation of resolvers that associate the uniform name of a document with its physical location. LEX assumes no particular relationship between the originator of the document, its publisher, the implementer of catalogues, or resolution services.¶

1.5. Use of LEX Names in References

LEX names can be used in references as an HREF attribute value of the hypertext link to the referred document. This link can be created in two ways:¶

• Manually inserting the link with the uniform name in the referring document. This is a burdensome procedure, especially for documents that are already online.¶

• Automatically constructing (either permanently or temporarily) the link with the uniform name through reference parsers of a text. This procedure offers more time savings, even if it is subject to a certain percentage of errors, since references are not always accurate or complete. Nevertheless, this solution could be acceptable for already-published documents.¶

No matter which method is adopted, new documents produced in a certain format (for example, XML, XHTML, etc.) should express references through the uniform name of the document referred to.¶

1.6. Definitions

The following terms are used in this document:¶

Source of Law:

A general concept that refers to legislation, case law, regulations, and administrative acts. In its broadest sense, the source of law is anything that can be conceived as the originator of 'erga omnes' legal rules. In this document, "source of law" also refers to acts during their creation, such as bills, that might or might not become laws.¶

Jurisdictional Registrar:

An organization in any jurisdiction that shares and defines the assignment of the main components of the resource identifier through which the identifier uniqueness is guaranteed.¶

1.7. Terminology

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.¶

1.8. Syntax Used in This Document

This document uses a syntax that is based on the Augmented Backus-Naur Form (ABNF) [RFC5234] meta-language, which is used in many RFCs.¶

1.9. Namespace Registration

The "lex" namespace has been registered in the "Formal URN Namespaces" registry. See Section 12.¶

2.1. Identifier Structure

The identifier has the following hierarchical structure:¶

   "urn:lex:" NSS

where NSS is the Namespace Specific String composed as follows:¶

   NSS = jurisdiction ":" local-name

where:¶

jurisdiction:

Identifies the scope (state, regional, municipal, supranational, or organizational) where a set of sources of law have validity. It is also possible to represent international organizations (either states, public administrations, or private entities).¶

local-name:

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 represents all aspects of an intellectual production, from its initial idea, through its evolution during the time, to its realization by different means (paper, digital, etc.).¶

The jurisdiction element is composed of two specific fields:¶

   jurisdiction = jurisdiction-code *(";" jurisdiction-unit)

where:¶

jurisdiction-code:

Usually the identification code of the country where the source of law is issued. To facilitate the transparency of the name, the jurisdiction-code usually follows the rules of identification of other Internet applications, based on domain name (for details and special cases, see Section 2.2).¶

Due to the differences in representation in the various languages of a country, the use of the standard [ISO.3166-1] is strongly RECOMMENDED for easier identification of the country. Therefore, a urn-lex ID always begins with a sequence of ASCII characters: "urn:lex:ccTLD". For all the other components that follow the jurisdiction-code, the Jurisdictional Registrar decides the mode of representation (ASCII or UTF-8 percent-encoding; see Section 3.4).¶

Where applicable, the domain name of the country or multinational or international organization 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 assume that the corresponding domain name is used for the jurisdiction-code.¶

jurisdiction-unit

The possible administrative hierarchical sub-structures defined by each country or organization within their specific legal system. This additional information can be used when 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.¶

The following is an example:¶

"br:governo:decreto" (decree of federal government)
"br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state)
"br;sao.paulo;campinas:governo:decreto" (decree of Campinas
municipality)

¶

The following are fictitious examples of sources of law identifiers:¶

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)

2.2. Jurisdiction-Code Register

A new jurisdiction-code registry has been created. Note that this is a CNR registry and not an IANA registry.¶

Each entry contains the following elements:¶

jurisdiction-code:

The identifier of jurisdiction assigned to the country or organization.¶

jurisdiction:

The official name of the jurisdiction, country or organization.¶

registrant:

Essential information that identifies the organization that requested the registration of the code. The registrant will be responsible for its DNS zone, the attribution of sub-zone delegations, and so on. It is RECOMMENDED that each jurisdiction create a registry of all delegated levels so that the organization responsible for each sub-zone can easily be identified.¶

reference:

A reference to the defining document (if any).¶

The registry is initially empty. The following are possible example entries:¶

"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 is responsible for the jurisdiction-code and the root lex-nameserver.nic.it registries of the resolution routing.¶

A new Jurisdictional Registrar will contact CNR or the designated expert(s) according to the established rules of governance (published on the CNR website dedicated to 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 evaluations of the DNS. Typically, such applications should come from public administrations, as authorities enacting sources of law.¶

The adopted registration policy is similar to that of the "Expert Review" policy specified in [RFC8126]. The designated expert(s) will assign jurisdiction codes based on the following principles:¶

• If a request comes from a jurisdiction that corresponds to a country and the jurisdiction code is the same as a top-level Country Code Top-Level Domain (ccTLD), then the top-level ccTLD should be used as the jurisdiction code.¶

• If a request comes from a jurisdiction that corresponds to a multi-national organization (e.g., European Union) or international organization (e.g., United Nations and World Trade Organization), the Top-Level Domain Name (e.g., "eu") or the Domain Name (e.g., "un.org" and "wto.org") of the organization should be used as the jurisdiction code.¶

• If a multi-national or international organization does not have a registered domain, the designated expert(s) should assign something like "name.lex.arpa", where the name will be the acronym of the organization name in the language chosen by the organization itself. For example, the jurisdiction code of the European Economic Community could be "eec.lex.arpa". The alias mechanism allows for acronyms in different languages.¶

Jurisdiction codes MUST NOT be renamed, because that would violate the rule that URN assignments be persistent.¶

Jurisdiction codes MUST NOT ever 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 the designated expert(s).¶

Designated expert(s) can unilaterally initiate allocation or obsolescence of a jurisdiction code.¶

Requests for new jurisdiction code assignments must include the organization or country requesting it and contact information (email) of who requested the assignment.¶

2.3. Conformance with URN Syntax

The "lex" namespace identifier (NID) syntax conforms to [RFC8141]. However, a series of characters are reserved for identifying elements or sub-elements, or for future extensions of the LEX naming convention (see Section 3.2).¶

2.4. Validation Mechanism

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).¶

2.5. Scope

Global interest. In fact, each body that enacts sources of law can identify them by this scheme. Furthermore, other bodies (even non-enacting sources of law, such as newspapers, magazine publishers, etc.) that aim to reference legal documents can unequivocally identify them by this scheme.¶

3.1. Allowed and Not Allowed Characters

The characters are defined in accordance with [RFC8141]. For various reasons that are explained later, only a subset of characters is allowed in the "lex" NSS. All other characters are either eliminated or converted.¶

For the full syntax of the uniform names in the "lex" space, please see Section 8.¶

3.2. Reserved Characters

The following characters are reserved 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 the 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 between different formats of the same element (e.g., date).¶

","

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).¶

"*"

Reserved for future expansions.¶

"!"

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 is always converted into "-", except in the formal annexes (see Section 6.4.1).¶

3.3. Case Sensitivity

For all the languages where different cases (uppercase or lowercase) or different spellings of the same word are possible, names belonging to "lex" namespace are case-insensitive. For the Latin alphabet, it is RECOMMENDED that names be created in lower case, but names that differ only in case or in the spelling of the same word MUST be considered equivalent (e.g., "Ministry" will be recorded as "ministry").¶

3.4. Unicode Characters Outside the ASCII Range

In order to exploit the DNS as a routing tool towards the proper resolution system, keep editing and communication more simple, and avoid character percent-encoding, it is RECOMMENDED that characters outside the ASCII range (e.g., national characters, diacritic signs, etc.) be replaced by base ASCII characters. For example, the Italian term "sanitU+00E0" can be replaced by "sanita", the French term "ministU+00E8re" can be replaced by "ministere", and "MU+00FCnchen" can be replaced by "muenchen" (transliteration).¶

This mapping consists of:¶

• Transcription from non-Latin alphabets¶

• Transliteration of some signs (e.g., diaeresis and eszett)¶

• Preservation of only the basic characters, eliminating the signs placed above (e.g., accents and tilde), below (e.g., cedilla and little tail), or on (e.g., oblique cut)¶

The most suitable, well-known, and widespread mapping system for a given language MUST be chosen by the jurisdiction, or in agreement with this one, by the jurisdiction-unit in case of different languages in various regions, also taking into account the choices made for the same language by other jurisdictions. This mapping is simpler and more feasible for languages that use the Latin alphabet and gradually becomes more complex for other alphabets and for writing systems that use opposite orientation (from right to left) or are based on ideographic symbols.¶

If this conversion is not acceptable by a specific jurisdiction or it is not available in a given language, Unicode MUST be used, and for accessing network protocols, any Unicode code points outside the ASCII range MUST be converted to UTF-8 percent-encoding according to [RFC3986] and [RFC3629] .¶

In this case, it should be noted that the generated URN (as some of its parts) cannot be used directly for routing through the DNS. Therefore, the jurisdiction must adopt one of the following strategies:¶

• Convert non-ASCII characters within the DNS into IDN encoding using Punycode translation [RFC5894] (e.g., mU+00FCnchen in xn--mnchen-3ya) and develop a software interface that converts the URN before the navigation in the DNS.¶

• Create a routing service relying on a software, outside of the DNS, that addresses a proper resolution service.¶

Note that the urn:lex ID could contain groups of characters (UTF-8 percent-encoded) of some languages with different orientations. In this case, the BiDi rules apply [RFC5893].¶

The preferred order is summarized as follows:¶

• Conversion into basic ASCII is the RECOMMENDED solution (for not having to make conversions for network protocols and the DNS).¶

• Using Unicode and converting to UTF-8 percent-encoding [RFC3629] for accessing network protocols and to Punycode [RFC5894] only for navigation in DNS via software interface.¶

• Creation of a routing service relying on a software outside of DNS and addressing a proper resolution service.¶

The first solution allows native DNS routing while the other two solutions require software development for the interface or the routing. However, it is up to the specific jurisdiction to choose the preferred solution.¶

The following are two examples (Latin and Cyrillic alphabets) relating to the different solutions adopted:¶

• A circular adopted by the Municipality of Munich (Rundschreiben der Stadt MU+00FCnchen):¶

  • ASCII:¶

    urn:lex:de:stadt.munchen:rundschreiben: ...
    

    ¶

  • Unicode:¶

    urn:lex:de:stadt.mU+00FCnchen:rundschreiben: ...
    

    ¶

  • UTF-8:¶

    urn:lex:de:stadt.m%xC3%xBCnchen: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: ...
    

    ¶

  • Unicode:¶

    urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D
    U+0438U+0435:U+0437U+0430U+043AU+043EU+043D: ...
    

    ¶

  • UTF-8:¶

    urn:lex:ru:%xD1%x81%xD0%xBE%xD1%x81%xD1%x82%xD0%xBE%xD1
    %x8F%xD0%xBD%xD0%xB8%xD0%xB5:%xD0%xB7%xD0%xB0%xD0%xBA
    %xD0%xBE%xD0%xBD: ...
    

    ¶

  • Punycode:¶

    urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme: ...
    

    ¶

3.5. Abbreviations

Abbreviations are often used in law for indicating institutions (e.g., Min.), structures (e.g., Dept.), or legal measures (e.g., Reg.), but they are not used in a uniform way. Therefore, their expansion is highly RECOMMENDED (e.g., "Min." is expanded as "ministry").¶

3.6. Date Format

[ISO.8601.1988] describes the international format for representing dates. Dates MUST always be represented in this format (4 digits for the year, 2 digits for the month, and 2 digits for the day):¶

    date-iso = yyyy-mm-dd

For example, "September 2, 99" will be written as "1999-09-02".¶

This format ensures interoperability between different representation systems, and there are several programs for mapping other formats to this one.¶

However, to facilitate reading and understanding other formats (e.g., Jewish calendar), the urn:lex scheme allows for the date to be added in the jurisdiction's own format. For example, the date in the previous example would be 21.Elul,5759, that is:¶

• In Hebrew characters:¶

   U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.U+05EA
   U+05E9U+05E0U+05F4U+05D8
  

  ¶

• In UTF-8:¶

   %x5c%x75%x30%x35%x44%x42%x5c%x75%x30%x35%x46%x34%x5c%x75%x30%x35
   %x44%x30%x2e%x5c%x75%x30%x35%x44%x30%x5c%x75%x30%x35%x42%x31%x5c
   %x75%x30%x35%x44%x43%x5c%x75%x30%x35%x44%x35%x5c%x75%x30%x35%x42
   %x43%x5c%x75%x30%x35%x44%x43%x2e%x5c%x75%x30%x35%x45%x41%x5c%x75
   %x30%x35%x45%x39%x5c%x75%x30%x35%x45%x30%x5c%x75%x30%x35%x46%x34
   %x5c%x75%x30%x35%x44%x38
  

  ¶

Therefore, for all the dates in the urn:lex identifier (see Sections 6.3 and 7.1.2), it is possible to indicate the date in the local format:¶

    date = date-iso [ "|" date-loc ]

For example, "September 2, 99" will be written in ISO format and Hebrew format as follows:¶

  1999-09-02|U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.
  U+05EAU+05E9U+05E0U+05F4U+05D8

The characters that are not allowed (e.g., "/") or reserved (e.g., ",") cannot exist inside the date-loc and therefore MUST be turned into ".".¶

4.1. Spaces, Connectives, and Punctuation Marks

When explicitly present, all language connectives (e.g., articles, prepositions, etc.), punctuation marks, and special characters (e.g., apostrophes, dashes, etc.) are eliminated (no transformation occurs in cases of languages with declensions or agglutinating languages). The words that are left are connected to each other by a dot ("."), which substitutes for the space (e.g., "Ministry of Finances, Budget, and Economic Planning" becomes "ministry.finances.budget.economic.planning" and "Ministerstvo Finansov" becomes "ministerstvo.finansov").¶

4.2. Acronyms

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").¶

4.3. Ordinal Numbers

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 Roman numerals, an adjective, Arabic numerals with an apex, etc. (such as IV, third, 1U+00B0, and 2^). For example, "Department IV" becomes "department.4".¶

5.1. Basic Principles

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:¶

• self-explanatory,¶

• identifiable through simple and clear rules,¶

• compatible with the practice commonly used for references,¶

• able to be created from references in the text, automatically (by parser) or manually, and¶

• representative of both the formal and the substantive aspects of the document.¶

5.2. Model of Sources of Law Representation

According to the Functional Requirements for Bibliographic Records (FRBR) [FRBR] model developed by IFLA (International Federation of Library Associations and Institutions), four fundamental entities (or aspects) can be specified in a source of law, as in any intellectual production.¶

The first two entities reflect its contents:¶

work:

Identifies a distinct intellectual creation; in our case, it identifies a source of law both in its original form as amended over time.¶

expression:

Identifies a specific intellectual realization of a work; in our case, it identifies every different (original or up-to-date) version of the source of law over time and/or language in which the text is expressed.¶

The other two entities relate to its form:¶

manifestation:

Identifies a physical embodiment of an expression of a work; in our case, it identifies embodiments in different media (printing, digital, etc.), encoding formats (XML, PDF, etc.), or other publishing characteristics.¶

item:

Identifies a specific copy of a manifestation; in our case, it identifies individual physical copies as they are found in particular physical locations.¶

In this document, the [FRBR] model has been interpreted for the specific characteristics of the legal domain. In particular, apart from the language that 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, and 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 may change as a result of amendments or annulments of other legislative or jurisprudential acts. Therefore, notes, summaries, comments, anonymizations, and other editorial activities over the same text do not produce different expressions. Instead, they produce different manifestations.¶

5.3. Structure of the Local Name

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, three components are always present at the "work" level: the enacting authority, the type of provision, and the details. A fourth component, the annex, can also be added. It is often necessary to differentiate various expressions, that is:¶

• the original version and all the amended versions of the same document, and¶

• the versions of the text expressed in the different official languages of the state or organization.¶

Finally, the uniform name allows a distinction among diverse manifestations that may be produced by multiple publishers using different means and formats.¶

In 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 that forms a uniform name for a source of law at each level (work, expression, and manifestation) is expressed in the official language of the relevant jurisdiction. More language-dependent names (aliases) are created in cases where there are multiple official languages (as in Switzerland) or more involved jurisdictions (as in international treaties).¶

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 that includes the following: the original main document, the annexes, and all the versions, languages, and formats that are subsequently generated.¶

5.4. Structure of the Document Identifier at "Work" Level

The structure of the document identifier is comprised of the four fundamental elements mentioned above, distinguished one from the other and ordered by increasingly narrow domains and competencies:¶

   work = authority ":" measure ":" details *(":" annex)

where:¶

authority:

The issuing or proposing authority of the measure (e.g., state, ministry, municipality, court, etc.).¶

measure:

The type of the measure, both public (e.g., constitution, act, treaty, regulation, decree, decision, etc.) and private (e.g., license, agreement, etc.).¶

details:

The terms associated with the measure, typically the date (usually the signature date) and the number included in the heading of the act.¶

annex:

The identifier of the annex, if any (e.g., Annex 1).¶

Both the main document and its annexes have their own uniform names so that they can be referenced individually; the identifier of the annex adds a suffix to that of the main document. In a similar way, the identifier of an annex of an annex adds an ending to that of the annex that it is attached to.¶

The main elements of the work name are generally divided into several elementary components, and for each component, specific rules of representation are established (criteria, modalities, syntax, and order). For the details regarding each element, see Section 6. The following are hypothetical examples of work identifiers:¶

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

The type of measure is important to identify case law and legislation, especially within legal systems where cases are traditionally identified only through the year of release and a number. Since the aim of the lex schema is to identify specific materials, the type of measure or the full date are able to differentiate between materials belonging to a specific case.¶

The following is an example where the type of measure or the full date are essential for identify specific materials of a case:¶

• 4/59 Judgment 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
  

  ¶

5.5. Aliases

International treaties involve multiple signatory jurisdictions and are therefore represented through multiple identifiers, each of them related to a signatory. For example, a bilateral France and Germany treaty is identified through two URNs (aliases) belonging to either the "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 German jurisdictions).¶

In the states or organizations that have multiple official languages, a document has multiple identifiers. Each identifier is expressed in a different official language and is 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" and "urn:lex:eu:consiglio:direttiva:2004-12-07;31").¶

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).¶

5.6. Structure of the Document Identifier at "Expression" Level

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 to be 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:¶

• amendments due to the issuing of other legal acts and to the subsequent production of updated or consolidated texts,¶

• correction of publication errors (rectification or errata corrige), and¶

• entry into or departure from a particular time span, depending on the specific date in which different partitions of a text come into force.¶

Each version 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:¶

version:

The identifier of the version of the original or amended source of law. In general, it is expressed by the promulgation date of the amending act; other specific information can be used for particular documents. If necessary, the original version is specified by the string "original" and is expressed in the language of the act or version (for the details regarding this element, please see Section 7).¶

language:

The identification code of the language in which the document is expressed, according to [RFC5646] (it=Italian, fr=French, de=German, etc.). The granularity level of the language (for example, the specification of the German language as used in Switzerland rather than standard German) is left to each specific jurisdiction. The information is not necessary when the text is expressed in the sole official language of the country or jurisdiction.¶

The following are hypothetical examples of document identifiers for expressions:¶

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)

5.7. Structure of the Document Identifier at "Manifestation" Level

To identify a specific manifestation, the uniform name of the expression is followed by a suitable suffix containing the following main elements:¶

editor:

Editorial staff who produced it, expressed according to the publisher's Internet domain name. Since publishers' domain names may vary over time, manifestations already assigned by a publisher remain unchanged, even if the identified object is no longer accessible. In this case, in order to make its materials accessible, the publisher will have to create a new manifestation with a new domain name for each of them.¶

format:

The digital format (e.g., XML, HTML, PDF, etc.) expressed according to the MIME Content-Type standard [RFC2045], where the "/" character is to be substituted with the "-" sign.¶

component:

Possible components of the expressions contained in the manifestation. Such components are expressed by language-dependent labels representing the whole document (in English "all"), the main part of the document (in English "body"), or the caption label of the component itself (e.g., Table 1, Figure 2, etc.).¶

feature:

Other features of the document (e.g., anonymized decision text).¶

Thus, the manifestation suffix reads:¶

    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 following forms:¶

    editor = publisher *(";" specification)
    format = mime *(";" specification)
    component = part *(";" specification)
    feature = attribute *(";" specification)

The syntax details of the manifestation element are shown in Section 8 in the related part.¶

The following are hypothetical examples:¶

• The original version of 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 Judgment of the European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, published in the Jurifast database in anonymized form:¶

  urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08
  @original:es$text-html:juradmin.eu;jurifast:todo:anonimo
  

  ¶

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 (e.g., image scans of documents).¶

5.8. Sources of Law References

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.¶

In the digital representation, a partition is represented by an element (a block of text) with its own ID; this ID aims to identify the related element and locate it. Therefore, it is possible to either extract or point to a partition.¶

For markup that does not fit the logical structure of the text (like HTML), generally only the starting point of the partition, rather than the whole block of text or element, is identified through a label (e.g., <a id=partitionID></a> tag in the HTML markup language [W3C.HTML]). In this case, it is only possible to point to a partition but not extract it.¶

Partitions should be assigned unique labels or IDs within the including document, and their value should be the same regardless of document format.¶

To enable 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. For example, in legislation, paragraph 2 of article 3 might have the value "art3;par2" as the label or ID; similarly, for case law, paragraph 22 of the judgment in Case 46/76 Bauhuis v Netherlands might have the value "par22" as the label or ID.¶

Furthermore, it is useful to foresee the compatibility with applications that are 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 be transmitted to the servers (resolution and application). 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]

For example, referring to paragraph 3 of 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 is transmitted to the resolution process. If the partition syntax is compatible with the media type used, this enables the resolver to retrieve (for example, out of a database) only the referred partition; otherwise, the whole act is returned.¶

When resolving to HTTP, the resolver SHALL transform the partition ID to an appropriate internal reference (#) on the page or at the beginning if that point cannot be found. The transformation in the URI fragment is obtained by appending the "#" character followed by the partition ID to the URL (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 by eliminating sub-partitions that are not addressed. In the previous example, if only the article was identified in the act, 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 always be retrieved.¶

6.1. The Authority Element

   authority = issuer *("+" issuer)

   issuer = (institution *(";" body-function)) / office

6.2. The Measure Element

      measure = measure-type *(";" specification)

6.3. The Details Element

    details = (dates / period) ";" numbers

dates = date *("," date)

  personal.data.protection.authority:measure:1999-12-30,2000-01-
  13;1-p-2000

   number-lex = "lex-" 1*DIGIT

  numbers = document-id *("," document-id)

6.4. The Annex Element

    annex = annex-id *(";" specification)

  region.sicily;council:deliberation:1998-02-12;14:annex.a;
  borders.park

  region.sicily;council:deliberation:1998-02-12;14:annex.a;
  borders.park:table.1;municipality.territories

7.1. The Version Element

   version = (amendment-date / specification)
             *(";" (event-date / event))

9.1. Specifying the Jurisdiction Element of the LEX Identifier

Under the "lex" namespace, each country or international organization is assigned 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 organizations) representation, and it is the value of the jurisdiction-code element, which preserves cross-country uniqueness of the identifiers.¶

9.2. Jurisdictional Registrar for Names Assignment

Any country or jurisdiction that intends to adopt this schema MUST identify a Jurisdictional Registrar, an organization that 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.paulo", "br;minas.gerais", etc.) may be defined.¶

The process of assigning the local-name is 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.¶

The Jurisdictional Registrar MUST establish, according to the guidelines indicated in this document, a uniform procedure within the country or organization to define local-name elements, make decisions about normalizations, solve and avoid possible name collisions, and 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 Jurisdictional Registrar shares and defines the rules to construct partition IDs for each document type, possibly in accordance with those already defined in other jurisdictions.¶

Finally, the Jurisdictional Registrar will develop and publish the rules and guidelines for the local-name construction as well as the predefined values and codes. The Jurisdictional 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. Each of them will be responsible for assigning names to their domains.¶

9.3. Identifier Uniqueness

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 is 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 its registries and make them accessible.¶

Any enacting authority is responsible for defining formal parameters to guarantee local name uniqueness by attributing, if necessary, a conventional internal number, which when combined with the other local-name components (authority, measure, and date), builds a unique identifier. Uniqueness is achieved by checking against the catalogue of previously assigned names.¶

9.4. Identifier Persistence Considerations

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, CNR is responsible for 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 associated code for country or organization 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 that is identified within each country or organization.¶

Therefore, each authority is responsible for assigning URNs that 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 national scope down to very local scope, MUST equally take responsibility for the persistence of identifiers within their scope.¶

10.1. General Architecture of the System

The task of the resolution service is to associate a LEX identifier with a specific document address on the Internet. In 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 inputs that are incomplete or partially incorrect, particularly those created by the automated extraction of references from 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 the DNS 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 followed.¶

For the "lex" namespace, CNR will 1) maintain the root zone of the chain resolution, equivalent to "lex.urn.arpa" (see [RFC3405]), in the lex-nameserver.nic.it (see Section 12) and 2) update the DNS information with a new record to delegate the relative resolution in correspondence with the adhesion (see Section 2.2) of a new country (e.g., "br") or organization. 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 a 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 a DNS routing chain does not work for all the URN components containing percent-encoded characters. Therefore, when converting a "lex" URN in UTF-8 code to a DNS query, clients MUST perform any necessary 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 software to query the knowledge base.¶

10.2. Catalogues for Resolution

Incompleteness and inaccuracy are rather frequent in legal citations; thus, incomplete or inaccurate uniform names of the referred document are 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 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, and the related manifestations.¶

It is suggested that each enacting authority implement its own catalogue, assigning a corresponding unambiguous uniform name to each resource.¶

10.3. Suggested Resolver Behavior

First, the resolver SHOULD separate the part corresponding to the partition ID from the document name, with the "~" separator.¶

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 that corresponds exactly to the given one (normalized if necessary). Since the names coming from the references may be inaccurate or incomplete, an iterative and heuristic approach (based on partial matches) is indicated. 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, the entire document is returned.¶

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 the "#" character followed by the partition ID to URLs, to create URI fragments for browser pointing.¶