RFC 9676
LEX: A Uniform Resource Name (URN) Namespace for Sources of Law
RFC 9676: LEX, a URN Namespace for Sources of Law ๐
okay bestie, this one is LEX, a Uniform Resource Name (URN) namespace for legal stuff ๐โจ It's RFC 9676, published in May 2025. It's an Informational doc (so it's not an official Internet Standard, no cap), and it's an Independent Submission to the RFC Series, which means it didn't come out of the IETF consensus process. The authors are P. Spinosa, E. Francesconi, and C. Lupo, all from the National Research Council of Italy (CNR) ๐ฎ๐น It's catalogued under ISSN 2070-1721. The header doesn't list anything it obsoletes or updates, so nothing is being retired here ๐ธ
Abstract
okay so the main idea: LEX is a URN namespace that gives persistent names to resources in the legal domain ๐ฆ It's built so that multiple jurisdictions can agree on one shared convention, which makes it way easier to refer to legal resources and get to them. ngl it's giving global interoperability for lawyers ๐
This is an Independent Submission to the RFC Series. It is not a standard and it doesn't have IETF consensus, so keep that in mind while you read ๐ซถ
Status of This Memo
this doc is not an Internet Standards Track spec. It's published just for information ๐
It's a contribution to the RFC Series, independent of any other RFC stream. The RFC Editor picked to publish it at their discretion, and they make no statement about how valuable it is for implementation or deployment. Docs the RFC Editor approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 ๐
For the current status of this document, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9676 ๐
Copyright Notice
Copyright (c) 2025 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) as they stand on the publication date. Please read these carefully, bestie, because they describe your rights and restrictions for this document ๐
Table of Contents ๐ง
1. Introduction
1.1. The Purpose of Namespace LEX
1.2. Background
1.3. General Characteristics of the System
1.4. Linking a LEX Name to a Document
1.5. Use of LEX Names in References
1.6. Definitions
1.7. Terminology
1.8. Syntax Used in This Document
1.9. Namespace Registration
2. Registration of LEX
2.1. Identifier Structure
2.2. Jurisdiction-Code Registry
2.3. Conformance with URN Syntax
2.4. Validation Mechanism
2.5. Scope
3. General Syntax and Features of the LEX Identifier
3.1. Allowed and Not Allowed Characters
3.2. Reserved Characters
3.3. Case Sensitivity
3.4. Unicode Characters Outside the ASCII Range
3.5. Abbreviations
3.6. Date Format
4. Specific Syntax and Features of the LEX Identifier
4.1. Spaces, Connectives, and Punctuation Marks
4.2. Acronyms
4.3. Ordinal Numbers
5. Creation of the Source of Law LEX Identifier: Baseline
Structure
5.1. Basic Principles
5.2. Model of Sources of Law Representation
5.3. Structure of the Local-Name
5.4. Structure of the Document Identifier at "Work" Level
5.5. Aliases
5.6. Structure of the Document Identifier at "Expression" Level
5.7. Structure of the Document Identifier at "Manifestation"
Level
5.8. Sources of Law References
6. Specific Syntax of the Identifier at "Work" Level
6.1. The Authority Element
6.1.1. Indication of the Authority
6.1.2. Multiple Issuers
6.1.3. Indication of the Issuer
6.1.4. Indication of the Body
6.1.5. Indication of the Function
6.1.6. Conventions for the Authority
6.2. The Measure Element
6.2.1. Criteria for the Indication of the Type of Measure
6.2.2. Further Specification to the Type of Measure
6.2.3. Aliases for Sources of Law with Different Normative
References
6.2.4. Relations Between Measure and Authority in the Aliases
6.3. The Details Element
6.3.1. Indication of the Details
6.3.2. Multiple Dates
6.3.3. Unnumbered Measures
6.3.4. Multiple Numbers
6.4. The Annex Element
6.4.1. Formal Annexes
6.4.2. Annexes of Annexes
7. Specific Syntax of the Version Element of the "Expression"
7.1. The Version Element
7.1.1. Different Versions of a Legislative Document
7.1.2. Identification of the Version
8. Summary of the Syntax of the Uniform Names of the LEX Namespace
9. Procedure of Uniform Names Assignment
9.1. Specifying the Jurisdiction Element of the LEX Identifier
9.2. Jurisdictional Registrar for Names Assignment
9.3. Identifier Uniqueness
9.4. Identifier Persistence Considerations
10. Recommendations for the Resolution Process
10.1. General Architecture of the System
10.2. Catalogues for Resolution
10.3. Suggested Resolver Behavior
11. Security Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction โจ
1.1. The Purpose of Namespace LEX ๐
okay so the whole point of the LEX namespace is to give each document that counts as a source of law its own unique identifier, in a well-defined format ๐ "Sources of law" covers any legal document in legislation, case law, administrative acts, or regulations. Potential sources of law (acts that are still being formed, like bills) are included too ๐ What's not included is "legal doctrine", the body of knowledge and theory that legal scholars produce (commentary on judgments, jurisprudence reviews, commentary on legislation, encyclopedic entries, monographs, magazine articles, manuals, and so on). Those are explicitly not covered, so don't go looking for them here ๐
The identifier is designed so that it's built only from the content of the document itself, not from where it's posted online, where it physically lives, or how you can access it. The jurisdiction of the identified document is the one that assigns the identifier itself. A document that isn't available online can still have a LEX URN identifier, and that's lowkey the best part ๐ธ
The LEX URN can be used to represent references (and any other kind of relation) among different sources of law ๐ In an online world where resources are spread across lots of web publishers, LEX URNs make it possible to link legal documents together globally through automated resolution, which is so iconic ๐ LEX URNs are persistent and location-independent identifiers, and they're especially useful when they can be mapped to, or associated with, locators such as HTTP URLs. And LEX URN details can also be used as a reference to create persistent, location-independent identifiers that are HTTP-based [RFC3986] ๐
1.2. Background ๐
Okay so this spec is the newest chapter in a LONG story about giving legal documents unique IDs ๐โจ. It builds on a bunch of earlier initiatives, so let's do the tour.
Since 2001, the Italian Government has been pushing the NormeInRete project ๐ฎ๐น. It worked through the National Center for Information Technology in the Public Administration, the Ministry of Justice, and the National Research Council of Italy (CNR). The goal was to introduce standards for describing and identifying sources of law using XML and URN techniques ๐.
Other national initiatives in Europe came up with standards for describing legal sources [FRAN]. Teams made up of government folks, national research institutes, and universities have defined national XML standards for legal document management, plus schemes for legal document identification ๐ค. Outside Europe, similar initiatives have tackled similar problems [FRAN]. A bunch of these identifiers are built on a URN schema ๐ฆ.
In today's information society, the European Union (EU) Member States are becoming more politically, socially, and economically integrated ๐. The worldwide legal and economic processes are also integrating more and more. Put those together and people are super interested in swapping legal information at both national and transnational levels ๐. Everyone wants better quality and easier access to legal information, which makes interoperability among legal information systems across national boundaries a HUGE need ๐ญ. A common, well-defined schema for identifying sources of law at an international level is basically the essential prerequisite for interoperability ๐.
Several interest groups in different countries have already said they want to adopt a shared solution based on a URN technique ๐. At several conferences (such as [LVI]), reps from the Publications Office of the European Union (OP) have talked about needing a unique identifier for sources of law. It should be based on open standards and offer advanced ways to hyperlink documents, all so national and European institution information systems can work together better ๐. Similar concerns have come up with international groups that care about free access to legal information. 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". Meanwhile, the CEN Metalex initiative is working at the European level toward a standard interchange format for sources of law. That includes recommendations for defining naming conventions for them ๐.
Unique identifiers for sources of law are especially important for case law ๐ฉโโ๏ธ. This need is acutely felt in both common law systems (where cases are the main law sources) and civil law systems. Unique identifiers can give integrated access to cases and legislation and let you track the relationships between them. The catch is that this domain is super fragmented, with case law information systems that usually don't play nicely together ๐ค.
In the European Union, the community institutions have stressed that citizens, businesses, lawyers, prosecutors, and judges need to be more aware of (directly applicable) EU laws and the various national legal systems ๐ช๐บ. The European Parliament's resolution of 9 July 2008 on the role of the national judge in the European judicial system stressed how much national judiciaries matter for applying community law ๐. The Council of the European Union has also underlined how important cross-border access to national case law is, plus the need to standardize it. Its vision is a decentralized architecture with integrated access ๐งฉ. The Working Party on Legal Data Processing (e-Law) of the Council of the European Union formed a task group to study ways to improve cross-border access to national case law. After the task group's report, the Council of the European Union decided in 2009 to work out a uniform European system for identifying case law, the European Case-Law Identifier (ECLI), plus a uniform set of metadata based on the Dublin Core ๐ .
The Council of the European Union also invited Member States to bring the European Legislation Identifier (ELI) into their legal information systems. ELI is an HTTP-based, Semantic Web-oriented identification system for legislation of the European Union and Member States ๐.
The LEX identifier (also called the "LEX name" in this text) is designed to be general enough to give guidance at the core of the standard. It's also flexible enough to cover lots of different needs for identifying legal documents, like legislative, case law, and administrative acts ๐. It works well in a federative environment, where different publishers (public and private) can each provide their own items of a legal document. Those items are in the [FRBR] sense (see Section 5.2). In other words, there can be more than one manifestation (see Section 5.2) of the same legal document ๐.
The name syntax and rules for the LEX identifier can also be used for HTTP-based naming conventions. That helps with different requirements in legal information management. For example, you might want an identifier that fits the Linked Open Data principles ๐๐.
This document adds to the required name syntax with a naming convention. It takes all these recommendations and turns them into an original solution for identifying sources of law โจ.
1.3. General Characteristics of the System ๐ธ
This document promotes interoperability among legal information systems by defining a namespace convention and structure. That structure creates and manages identifiers for legal documents ๐ . The identifiers are meant to have these qualities:
- globally unique
- transparent
- reversible
- persistent
- location-independent
- language-neutral
Together, these qualities make it easier to manage legal documents and give a reliable way to make cross-collection and cross-country references ๐ฆ.
Transparency means that, for a given act and its relevant metadata (issuing authority, type of measure, etc.), you can create a related URN that uniquely identifies the act. It's reversible, too, so you can go from an act to its URN and from a URN back to the act ๐.
Language neutrality is a big deal ๐. It helps organizations that have to follow official language requirements adopt the standard. This specification gives guidance to both public and private groups that create, promulgate, and publish legal documents. Registrants want to avoid creating conflicting proprietary schemes, but they also need enough flexibility for diverse document types. They also need to respect local control of collections by a diverse assortment of administrative entities ๐.
It's a tricky balance: give the right amount of guidance at the core, but still leave enough flexibility for all sorts of needs ๐คนโโ๏ธ. LEX does this by splitting the identifier into parts. The first part uses a preexisting standard specification (the "country/jurisdiction name standard") to show the country (or more generally, the jurisdiction) where the legal document came from. The rest (the "local-name") is for local use, identifying documents issued in that country or jurisdiction ๐บ๏ธ.
The second part depends only on the identification system for sources of law used in that nation. It's mainly made up of formalized information about 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 that can unambiguously represent 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 covers the first of these requirements. It also has 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 gets linked to the document through metadata, which can be specified in these ways ๐:
- 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. That's what enables automated construction, updating of catalogues (distributed and centralized), and implementing resolvers that match a document's uniform name with its physical location ๐ง. LEX doesn't assume any particular relationship between the document's originator, its publisher, the implementer of catalogues, or the resolution services. No drama, no assumptions ๐ .
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 ๐. There are two ways to create that link:
- 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 the link with the uniform name from references in the text, using a parser. Constructing it either permanently or temporarily. This saves way more time, even though it comes with a certain percentage of errors, since references aren't always accurate or complete ๐ค. This solution could still be acceptable for documents that are already published ๐.
No matter which method you pick, new documents produced in a certain format (for example, XML, XHTML, etc.) should express references through the uniform name of the document being referred to โจ.
1.6. Definitions ๐
These are the terms 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. That's how 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
okay so this doc is written in ABNF ([RFC5234]), the grammar language tons of RFCs use, so if you've seen it before you'll feel right at home ๐
1.9. Namespace Registration
the LEX namespace got registered in the "Formal URN Namespaces" registry ๐ see Section 12 for the deets โจ
2. Registration of LEX
2.1. Identifier Structure
the identifier has this hierarchical vibe ๐ธ
"urn:lex:" NSSwhere NSS is the Namespace Specific String, and it's built like this:
NSS = jurisdiction ":" local-namewhere:
- jurisdiction: tells you the scope (state, regional, municipal, supranational, or organizational) where a set of sources of law is valid. international organizations can be represented too (states, public administrations, or private entities) ๐
- local-name: the uniform name of the source of law in the country or jurisdiction where it's issued. its internal structure is common to the schemas that are already adopted. it covers the whole life of an intellectual production, from the initial idea, through its evolution over time, to how it finally shows up in different forms (paper, digital, etc.) ๐
the jurisdiction element is made 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 keep the name transparent, it usually follows the same identification rules as other Internet apps, which are based on domain names (for details and special cases, see Section 2.2).
because countries represent things differently across their languages, using the standard [ISO.3166-1] is strongly RECOMMENDED for easier identification of the country. so a LEX URN ID always begins with a sequence of ASCII characters: "urn:lex:ccTLD". for all the other components after the jurisdiction-code, the Jurisdictional Registrar decides the mode of representation (ASCII or UTF-8 percent-encoding; see Section 3.4).
where it applies, the domain name of the country or multinational or international organization is used. if that info isn't available for a particular institution, a specific code will be defined (see Section 2.2). examples in this document are hypothetical and assume the corresponding domain name is used for the jurisdiction-code.
- jurisdiction-unit: the possible administrative hierarchical sub-structures each country or organization defines within its own legal system. this extra info is super useful when two or more levels of legislative or judicial production exist (e.g., federal, state, and municipality level) and the same bodies show up in each one. so the jurisdiction-unit differs for acts of the same type issued by similar authorities but covering different geographical areas. here's an example:
"br:governo:decreto" (decree of federal government),
"br;sao.paulo:governo:decreto" (decree of Sรฃo (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 Registry
a brand new jurisdiction-code registry just dropped! ๐ quick heads-up though: it's a CNR registry and not an IANA registry ๐
each entry has these elements:
- jurisdiction-code: the identifier assigned to the jurisdiction (aka the country or organization).
- jurisdiction: the official name of the jurisdiction (aka the country or organization).
- registrant: essential info that identifies the organization that requested the registration of the code. the registrant is 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 the organization responsible for each sub-zone can easily be identified ๐ซถ
- reference: a reference to the defining document (if any).
the table lives at lex-urn.nic.it and it's initially empty, and so is the registry ๐ฅบ here are some 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) following the established rules of governance (published on the CNR website dedicated to LEX governance). the application gets evaluated based on the Jurisdictional Registrar's authoritativeness and the guarantees it offers. the designated expert(s) will evaluate these applications with a similar approach to DNS evaluations. typically, these applications should come from public administrations, as the authorities enacting sources of law.
the adopted registration policy is similar to the "Expert Review" policy specified in [RFC8126]. the designated expert(s) will assign jurisdiction-codes based on these 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 start the allocation or obsolescence of a jurisdiction-code ๐
requests for new jurisdiction-code assignments must include the organization or country requesting it and the contact information (email) of whoever requested the assignment.
2.3. Conformance with URN Syntax
the LEX namespace identifier (NID) syntax conforms to [RFC8141]. however, a bunch 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 whoever it delegates to) of each adhering country or organization is responsible for defining or accepting the uniform name's primary elements (issuing authority and type of legal measure) ๐ผ
2.5. Scope
the scope is global ๐ each Body that enacts sources of law can identify them with this scheme. on top of that, other bodies (even non-enacting ones, like newspapers, magazine publishers, etc.) that want to reference legal documents can identify them unequivocally with this scheme too ๐ฆ
3. General Syntax and Features of the LEX Identifier
this section lists the general features that apply to all jurisdictions โจ
3.1. Allowed and Not Allowed Characters
the characters are defined in accordance with [RFC8141]. for various reasons 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 uniform names in the LEX space, check out 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 doesn't include the use of the character "/" in this version ๐ that character always gets 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 in the 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 โจ
Okay so, to let the DNS work as a routing tool toward the right resolution system ๐งญ, keep editing and communication simple ๐, and avoid character percent-encoding ๐, it is RECOMMENDED that characters outside the ASCII range (national characters, diacritic signs, and so on) get turned into plain basic ASCII. The examples are the Italian term "sanitร " (sanitU+00E0)), which becomes "sanita", and the French term "ministรจre" (ministU+00E8re), which becomes "ministere". If that's not possible, transliteration is the backup, like "Mรผnchen" (MU+00FCnchen) becoming "muenchen". ๐ฆ
This mapping has three parts:
- Transcription from non-Latin alphabets
- Transliteration of some signs (for example, diaeresis and eszett)
- Keeping only the basic characters and dropping the signs placed above (accents and tilde), below (cedilla and little tail), or on (oblique cut)
The most suitable, well-known, and widespread mapping system for a given language MUST be chosen by the jurisdiction, or by the jurisdiction-unit in agreement with the jurisdiction when different languages are used in different regions. The choices other jurisdictions made for the same language should also be taken into account. ๐ This mapping is simpler for languages that use the Latin alphabet and gets more complex for other alphabets, for writing systems that run right to left, and for ideographic writing systems. ๐ธ
If this conversion is not acceptable to a specific jurisdiction, or it isn't available for a given language, Unicode MUST be used. 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] . ๐ฅ
Here's the tea โ: in this case, the generated URN (and some of its parts) cannot be used directly for routing through the DNS. So the jurisdiction should adopt one of the following strategies:
- Convert non-ASCII characters within the DNS into IDN encoding using Punycode translation [RFC5894] (for example, "mรผnchen" (
mU+00FCnchen) becomesxn--mnchen-3ya), and develop a software interface that converts the URN before navigating the DNS. - Create a routing service, built in software outside of the DNS, that points to a proper resolution service.
Note that the LEX URN ID could contain groups of characters (UTF-8 percent-encoded) from some languages with different orientations. In this case, the BiDi rules apply [RFC5893]. ๐
The preferred order goes like this ๐:
- Conversion into basic ASCII is the RECOMMENDED solution, because conversions for network protocols and the DNS are not needed. โจ
- Using Unicode and converting to UTF-8 percent-encoding [RFC3629] for accessing network protocols, and to Punycode [RFC5894] only for navigation in the DNS via a software interface.
- Creating a routing service outside of the DNS that addresses a proper resolution service.
The first solution allows native DNS routing, while the other two need software development for the interface or the routing. Still, it's up to the specific jurisdiction to choose the preferred solution. ๐
Here are two examples (Latin and Cyrillic alphabets) for the different solutions:
- A circular adopted by the Municipality of Munich (Rundschreiben der Stadt "Mรผnchen" (
MU+00FCnchen)):- ASCII:
urn:lex:de:stadt.munchen:rundschreiben:...; - Unicode:
urn:lex:de:stadt.mU+00FCnchen:rundschreiben:...; - UTF-8:
urn:lex:de:stadt.m%C3%BCnchen:rundschreiben:...; - PUNYCODE:
urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben:...
- ASCII:
- A state law of the Russian Federation (Latin: gosudarstvo zakon; Cyrillic: "ัะพััะพัะฝะธะต ะทะฐะบะพะฝ" (
U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435U+0437U+0430U+043AU+043EU+043D)). This assumes the Russia jurisdiction-code is written in ASCII asru, while the Cyrillic version would be "ัั" (U+0440U+0444):
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:%D1%81%D0%BE%D1%81%D1%82%D0%BE%D1
%8F%D0%BD%D0%B8%D0%B5:%D0%B7%D0%B0%D0%BA
%D0%BE%D0%BD:...
PUNYCODE: urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme:...3.5. Abbreviations โจ
Abbreviations pop up all the time in law ๐. They show up for institutions (like Min.), structures (like Dept.), or legal measures (like Reg.), but nobody uses them in a uniform way, so it's a mess ๐ญ. That's why their expansion is highly RECOMMENDED. For example, "Min." is expanded as "ministry". ๐
3.6. Date Format โจ
[ISO.8601-1.2019] and [ISO.8601-2.2019] describe the international format for dates ๐๏ธ. Dates MUST always be represented in this format, with 4 digits for the year, 2 digits for the month, and 2 digits for the day:
date-iso = year "-" month "-" dayFor example, "September 2, 99" gets written as "1999-09-02". ๐
This format keeps different representation systems interoperable, and there are plenty of programs that map other formats onto it. But to make other formats (like the Jewish calendar) easier to read and understand, the LEX URN scheme lets you add the date in the jurisdiction's own format ๐ง. The date from the example above (1999-09-02) can be shown like this:
- in Hebrew characters (21 Elul 5759):
ืืดื-ืึถึผืึฑืืึผื-ืชืฉื ืดืNote that this example uses right-to-left (RTL) script, which may be displayed differently by different document presentation environments depending on the context of this specification. The descriptive text is usually more reliable to follow than the device- and application-specific rendering. ๐
- in U+ notation:
U+05D8U+05F4U+05E0U+05E9U+05EAU+002DU+05DCU+05D5U+05BCU+05DC
U+05D0U+05B1U+05D1U+05B6U+05BCU+002DU+05D0U+05F4U+05DB- in UTF-8 code:
%d7%98%d7%b4%d7%a0%d7%a9%d7%aa-%d7%9c%d7%95%d6%bc%d7%9c%d7%
90%d6%b1%d7%91%d6%b6%d6%bc-%d7%90%d7%b4%d7%9bSo for all the dates in the LEX URN identifier (see Sections 6.3 and 7.1.2), you can show the date in the local format too ๐:
date = date-iso ["|" date-loc]For example, 1999-09-02 gets written in ISO plus Hebrew format as 1999-09-02|ืืดื-ืึถึผืึฑืืึผื-ืชืฉื ืดื. That gets converted into UTF-8 for network protocols and for resolution (see Section 3.4). Characters that aren't allowed (like "/") or are reserved (like ",") cannot exist inside the date-loc, so they MUST be turned into ".". To line up with the ISO format, any blank between day, month, and year MUST be converted into "-". ๐ฅ
Now for the Hebrew example, the sequence of characters goes: "ื" (HEBREW LETTER KAF, U+05DB), "ืด" (HEBREW PUNCTUATION GERSHAYIM, U+05F4), "ื" (HEBREW LETTER ALEF, U+05D0), "-" (HYPHEN-MINUS, U+002D), "ืึถึผ" (HEBREW LETTER BET, HEBREW POINT SEGOL, HEBREW POINT DAGESH OR MAPIQ, U+05D1 U+05B6 U+05BC), "ืึฑ" (HEBREW LETTER ALEF, HEBREW POINT HATAF SEGOL, U+05D0 U+05B1), "ื" (HEBREW LETTER LAMED, U+05DC), "ืึผ" (HEBREW LETTER VAV, HEBREW POINT DAGESH OR MAPIQ, U+05D5 U+05BC), "ื" (HEBREW LETTER LAMED, U+05DC), "-" (HYPHEN-MINUS, U+002D), "ืช" (HEBREW LETTER TAV, U+05EA), "ืฉ" (HEBREW LETTER SHIN, U+05E9), "ื " (HEBREW LETTER NUN, U+05E0), "ืด" (HEBREW PUNCTUATION GERSHAYIM, U+05F4), and "ื" (HEBREW LETTER TET, U+05D8). ๐งฉ
4. Specific Syntax and Features of the LEX Identifier โจ
This section talks about features tied to specific jurisdictions ๐. Implementing these features is RECOMMENDED. ๐
4.1. Spaces, Connectives, and Punctuation Marks โจ
When they're explicitly present, all language connectives (like articles and prepositions), punctuation marks, and special characters (like apostrophes and dashes) get eliminated ๐งน. (Languages with declensions or agglutinating languages don't get any transformation.) The words that are left are joined together with a dot ("."), which takes the place of the space. For example, "Ministry of Finances, Budget, and Economic Planning" becomes ministry.finances.budget.economic.planning, and "Ministerstvo Finansov" becomes ministerstvo.finansov. ๐ฆ
4.2. Acronyms โจ
Acronyms can be confusing and invite ambiguity in uniform names, since the same acronym can point to two different institutions or structures ๐ฌ. So their expansion is highly RECOMMENDED. For example, "FAO" is expanded as food.agriculture.organization. ๐
4.3. Ordinal Numbers โจ
To standardise the representation ๐
, it is highly RECOMMENDED that any ordinal number in a component of a document name (for example, in the description of an institution Body) is written in Western Arabic numerals. That's true no matter how the original was written, whether as Roman numerals, an adjective, Arabic numerals with an apex, and so on (such as IV, third, 1ยฐ (1U+00B0), and 2^). For example, "Department IV" becomes department.4. ๐
5. Creation of the Source of Law LEX Identifier: Baseline Structure โจ
5.1. Basic Principles โจ
The uniform name has to identify one and only one document (more precisely, a "bibliographic resource" [ISBD]; see also Section 5.2) ๐. It gets created so 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 ๐โจ
Okay bestie, so the Functional Requirements for Bibliographic Records (FRBR) [FRBR] model, made by IFLA (International Federation of Library Associations and Institutions), says a source of law has four fundamental entities (or aspects) ๐ง . Same as any intellectual production, honestly. It's giving librarian meets lawyer ๐ .
The first two entities are about its contents ๐:
work: a distinct intellectual creation. Here it's a source of law in both its original form and its amended form over time ๐ฆ.expression: a specific intellectual realization of a work. Here it's every different version of the source of law over time (original or up-to-date) and/or language the text is written in ๐.
The other two are about its form ๐:
manifestation: a physical embodiment of an expression of a work. Here it's the different media (printing, digital, etc.), encoding formats (XML, PDF, etc.), or other publishing characteristics ๐จ๏ธ.item: a specific copy of a manifestation. Here it's individual physical copies as they show up in particular physical locations ๐.
Now here's the lowkey important bit ๐. In this document, the [FRBR] model has been adjusted for the legal world. Apart from language (which does make a specific expression), the way we tell expression and manifestation apart is by the juridical effects a change can have on the people involved (citizens, parties, and institutions) โ๏ธ. So the main thing about an expression of an act is how long it stays valid while it keeps the same juridical effects โณ. Those effects can change when other legislative or jurisprudential acts amend or annul things ๐.
That means notes, summaries, comments, anonymizations, and other editorial stuff on the same text do NOT make a new expression ๐ โโ๏ธ. They make a new manifestation instead ๐ธ. Not me being picky, just the rules ๐.
5.3. Structure of the Local-Name ๐งฉ
Main vibe: the local-name inside the LEX namespace MUST contain all the info needed to uniquely identify a legal document ๐. If the local-name doesn't do that, the related URN is not a valid one in the LEX namespace ๐ซ. Iconic, no notes ๐.
In the legal domain, three components are always there at the "work" level: the enacting authority, the measure type, and the details ๐ฏ. A fourth one, the annex, gets added if there is one ๐.
Sometimes you need to tell different expressions apart too, like:
- the original version and all the amended versions of the same document, and
- the versions of the text written in the different official languages of the state or organization ๐ฃ๏ธ.
Last but not least, the uniform name lets you tell apart the different manifestations that multiple publishers might make using different means and formats ๐ฅ๏ธ.
In every case the basic identifier of the source of law (the work) stays the same ๐ซถ, but extra info gets added about the specific version (the expression) ๐. Same idea for manifestations: a suffix gets added to the expression to show the publication's characteristics ๐.
The uniform name for a source of law at each level (work, expression, and manifestation) is written in the official language of the relevant jurisdiction ๐ฎ๐น. Aliases are the more language-dependent names, and they get made when there are multiple official languages (like Switzerland) or more jurisdictions involved (like international treaties) ๐โจ.
So the general structure of the local-name looks like this ๐:
local-name = work ["@" expression] ["$" manifestation]Now, consistent with legislative practice, the uniform name of the main original provision (the work) becomes the identifier for a whole class of documents ๐ง. That class includes the original main document, the annexes, and all the versions, languages, and formats generated afterwards ๐.
5.4. Structure of the Document Identifier at "Work" Level ๐๏ธ
The document identifier is made up of the four fundamental elements we talked about earlier ๐ . They're kept distinct from each other and ordered from broadest domain and competence to narrowest ๐:
work = authority ":" measure ":" details *(":" annex)Here's the breakdown ๐ง:
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 tied to the measure, usually the date (normally the signature date) and the number in the heading of the act ๐ .annex: the identifier of the annex, if there is one (e.g., Annex 1) ๐.
Both the main document and its annexes get their own uniform names so you can reference each one individually ๐ฅฐ. The annex identifier adds a suffix to the main document's identifier. And an annex of an annex adds an ending to the annex it's attached to ๐ช.
The main parts of the work name are usually split into several elementary components, and each component has its own rules for how it's represented (criteria, modalities, syntax, and order) ๐งฉ. For the details on each element, check out Section 6 ๐. Here are some 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;bc8581The type of measure matters a lot for telling apart legislation and case law ๐. This is especially true in legal systems where cases are traditionally identified only by the year of release and a number ๐๏ธ. Since the whole point of the LEX schema is to pin down specific materials, the type of measure or the full date can tell apart materials that belong to the same case ๐ฅ.
Here's an example where the type of measure or the full date is essential to identify specific materials from one 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-595.5. Aliases ๐ช
International treaties involve multiple signatory jurisdictions ๐ค, so they get represented through multiple identifiers, one for each signatory. For example, a bilateral France and Germany treaty gets two URNs (aliases) under either the fr or de jurisdiction (e.g., urn:lex:fr:etat:traite:... and urn:lex:de:staat:vertrag:...), since it belongs to both the French and German jurisdictions ๐ซ๐ท๐ฉ๐ช.
In states or organizations with multiple official languages, a document has multiple identifiers ๐ธ. Each identifier is written in a different official language, and it's basically a set of equivalent aliases. This setup lets people (or software) build the uniform name of the source of law in the same language the document itself uses ๐ฃ๏ธ (e.g., urn:lex:eu:council:directive:2004-12-07;31 and urn:lex:eu:consiglio:direttiva:2004-12-07;31) ๐.
A document can also get more than one uniform name, so other documents can link to it more easily ๐. This is useful for documents that are unique but get referenced from different angles, like 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 ๐ฆ
A legal text can have several expressions linked to specific versions or languages ๐.
Each version is defined by the period during which that text is considered in force or effective โณ. A version's lifetime ends when the next version is issued ๐. New versions of a text can come into existence through:
- amendments, from the issuing of other legal acts and the later 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 when different parts of a text come into force ๐ .
Each version can be expressed in more than one language, and every language version gets its own specific identifier ๐. The identifier of a source of law expression adds that info to the work identifier using this main structure ๐ง :
expression = version [":" language]Here's what each part means ๐:
version: the identifier of the version of the original or amended source of law. Usually it's the promulgation date of the amending act, though other specific info can be used for particular documents ๐. If needed, the original version is specified by the stringoriginal, and it's written in the language of the act or version (check Section 7 for the details on this element) ๐.language: the identification code of the language the document is written in, according to [RFC5646] (it=Italian, fr=French, de=German, etc.) ๐บ๏ธ. How specific the language gets (like Swiss German compared to standard German) is up to each jurisdiction ๐จ๐ญ. You don't need this info when the text is only in the sole official language of the country or jurisdiction ๐.
Here are some 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
okay so to point at one specific manifestation, you take the uniform name of the expression and slap on a suffix with these main pieces ๐
editor: the editorial staff who produced it, written using the publisher's Internet domain name. Publishers' domain names can change over time, so manifestations a publisher already assigned stay exactly as they are, even if the object they identify isn't reachable anymore ๐ญ If the publisher wants its materials accessible again, it has to create a new manifestation with a new domain name for each object.format: the digital format (XML, HTML, PDF, etc.) written using the MIME Content-Type standard [RFC2045], with the "/" swapped for a "-" sign ๐component: possible components of the expressions inside the manifestation. These get language-dependent labels for the whole document (in English, "all"), the main part of the document (in English, "body"), or the caption label of the component itself (like Table 1, Figure 2, etc.) ๐ฆfeature: other features of the document, like anonymized decision text โจ
So the manifestation suffix reads like this:
manifestation = editor ":" format
[":" component [":" feature]]Each main element of the manifestation MAY be followed by extra specifications (separated by ";") to show features or quirks. Think the archive name and electronic publisher for the editor, or the version for the format ๐ง That means the main elements take these forms:
editor = publisher *(";" specification)
format = mime *(";" specification)
component = part *(";" specification)
feature = attribute *(";" specification)The nitty-gritty syntax details of the manifestation element live in Section 8 in the related part ๐
Now for the hypothetical examples, because they're giving everything ๐
First up, the original version of the Italian act 3 April 2000, n. 56 could have these manifestations and their 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$parlamento.it:
application-pdf;1.7- XML format (version 2.2 DTD NIR) of the text of the act, plus PDF format (version 1.7) of the "Figura 1" (figure 1) in the body, edited by the Italian Senate:
urn:lex:it:stato:legge:2000-04-03;56$senato.it:text-xml;
dtd-nir-2.2:testo
urn:lex:it:stato:legge:2000-04-03;56$senato.it:
application-pdf;1.7:figura.1Next, the Spanish URN for the HTML format of the whole Judgment of the European Court of Justice n. 33/08 of 11/06/2009, in Spanish, published in the Jurifast database in anonymized form ๐ซถ
urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08
@original:es$juradmin.eu;jurifast:text-html:todo:anonimoIt's really useful to be able to give a manifestation (or part of one) a uniform name when non-textual objects are involved ๐ These could be multimedia objects that aren't text in their own right (like geographic maps or photographs), or texts stored in non-textual formats (like image scans of documents).
5.8. Sources of Law References
References to sources of law usually point at specific partitions of the act (an article, a paragraph, etc.), not the whole document ๐
From a legal point of view, a partition is always a text block that represents a logical subdivision of an act. Iconic ๐
In the digital version, a partition is an element (a block of text) with its own ID. That ID is there to identify the element and find it, so you can either extract a partition or point to it ๐ฅ
For markup that doesn't match the logical structure of the text (like HTML), usually only the starting point of the partition gets identified, using a label like <a id=partitionID></a> in the HTML markup language [W3C.HTML]. Not the whole block or element, just the spot where it starts. So with this approach you can point to a partition but you can't extract it ๐
Partitions should get unique labels or IDs within the including document, and their value should be the same no matter what the document format is โจ
To build partition identifiers that work across different collections of documents, specific construction rules for IDs or labels get defined and shared within each country or jurisdiction for every document type. For example, in legislation, paragraph 2 of article 3 might have the label or ID "art3;par2", and for case law, paragraph 22 of the judgment in Case 46/76 Bauhuis v Netherlands might have the value "par22" ๐ฆ
It's also nice to stay compatible with apps that can handle this info (like returning the right element). This is especially handy for really long acts, like codes, constitutions, regulations, etc. For that to work, the partition identifier has to be sent to the servers (for resolution and application). So it can't be split off with the usual "#" character of a URI fragment, because that one never gets sent to the server ๐
With all that in mind, the syntax of a reference is:
URN-reference = URN-document ["~" partition-id]For example, to refer 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" ๐ซ๐ท
If a different separator ("~") comes after the document name, the browser doesn't keep the partition ID. It gets sent along to the resolution process instead. If the partition syntax works with the media type being used, the resolver can grab just the referred partition (say, from a database). Otherwise, the whole act comes back ๐ธ
When resolving to HTTP, the resolver SHALL transform the partition ID into an appropriate internal reference (#) on the page, or go to the beginning if that point can't be found. The transformation goes into the URI fragment by adding the "#" character followed by the partition ID to the URL. So in the example above, the returned URL will be <URL-document>#art15;par3. Since the resolver knows how granular the act's markup is, it can use the hierarchical structure of the ID and drop any sub-partitions that aren't being addressed. In the previous example, if only the article was identified in the act, it could return just <URL-document>#art15 ๐ง
You're also allowed to use the general syntax (with "#"). In that case, only the URN document part of the reference gets sent to the resolver, so the whole document will always be retrieved ๐
6. Specific Syntax of the Identifier at "Work" Level
6.1. The Authority Element
6.1.1. Indication of the Authority
The authority element of a uniform name can indicate any of these, depending on the case ๐
- The actual authority issuing the legal provision. To be specific, that's the authority adopting it or enacting it.
- The institution where the provision is registered, known, and referenced, even if someone else produced it (for example, bills identified through a reference to the Chamber where they're presented).
- The institution regulated by the legal provision (and referred to in citations), even when another authority issued it (for example, the statute of a Body).
- The entity that proposed the legal material that hasn't entered the institutional process yet (for example, a proposed bill written by a political party).
6.1.2. Multiple Issuers
Some sources of law get enacted by several issuing parties (like inter-ministerial decrees, agreements, etc.). In that case, the authority element contains all the issuing parties, properly separated, like this:
authority = issuer *("+" issuer)Here's an example: "ministry.justice+ministry.finances" ๐
6.1.3. Indication of the Issuer
Each issuing authority is basically represented by either an institutional office (like Prime Minister) or an institution (like Ministry). If it's an institution, the authority gets indicated following the institution's hierarchy, going from more general to more specific (Council, Department, etc.), and ending with the relevant office (President, Director, etc.). So the structure of the issuer looks like this:
issuer = (institution *(";" body-function)) / officeHere's an example: "ministry.finances;department.revenues;manager" ๐ท
6.1.4. Indication of the Body
Depending on the kind of measure, the body inside the issuing authority is unambiguously determined (like the Council for Regional Acts), and it's usually left out of references. Just like in practice, the enacting authority only gets indicated to the minimum needed for the type of measure. So you'd write "region.tuscany:act" and not "region.tuscany;council:act" ๐
6.1.5. Indication of the Function
Generally, the function gets indicated, sometimes instead of the Body itself ๐
- For political, representative, or elective offices. For example,
"university.oxford;rector:decree"instead of"university.oxford;rectorship:decree". - When referring to a top officer in the institution (like a general manager, general secretary, etc.), where it isn't always possible to tie a specific internal institutional structure to them. For example,
"national.council.research;general.manager".
The function does NOT get indicated when it clearly matches the person in charge of an institution (usually a general director). In that case, only the structure gets indicated, not the person in charge. For example, "ministry.justice;department.penitentiary.administration" โจ
The function MUST be indicated when:
- It isn't the same as the director or the person in charge of the structure (for example, an undersecretary, a deputy director, etc.).
- The type of measure can be either monocratic or collegial. Indicating the office clears up the ambiguity ๐ฅ
6.1.6. Conventions for the Authority
Acts and measures with the same relevance as an act, issued or enacted since the foundation of the State, have conventionally used "state" (written in each country's official language) as the authority ๐ฎ๐น The same convention applies to constitutions, codes (civil, criminal, civil procedure, criminal procedure, etc.), and international treaties ๐
6.2. The Measure Element
6.2.1. Criteria for the Indication of the Type of Measure
In uniform names, the issuing authority of a document is mandatory. That means there's no need to add any further qualification of the measure (like ministerial decree or directorial ordinance), even though those are widely used ๐ฆ When the authority and measure combination already identifies a specific document, the type of measure isn't defined through attributes that refer to the enacting authority. So it's "region.tuscany:act" and not "region.tuscany:regional.act" ๐
6.2.2. Further Specification to the Type of Measure ๐
okay so in the measure element, it's usually enough to just say the type of measure ๐ . but people can't always pin a source of law down with the formal details (date and number), so they reference it by its vibes instead โจ. that means the subject matter it covers (like accounting regulations), a nickname tied to whoever promoted it (like the Bolkestein directive), or the topic of the act (like Bankruptcy Law), and so on. when that happens, the type of measure MAY be followed by extra specifics that help with referencing, even if the formal details are missing ๐ฆ:
measure = measure-type *(";" specification)examples: "regulations;accounting" or "act;bankruptcy" ๐
6.2.3. Aliases for Sources of Law with Different Normative References ๐
some legislative measures are unique, but people cite them in different ways ๐. one act might get brought into the legal order as a presidential decree, a legislative decree, and so on, or it gets referred to by its legislative category, like regulations or consolidation. so the references still work in every case, an alias (an additional URN LEX identifier) gets added to the legislative form of the same act, and it takes the measure category into account ๐. examples: "state:decree.legislative:1992-07-24;358" and "state:consolidation;public.contracts:1992-07-24;358" ๐
6.2.4. Relations Between Measure and Authority in the Aliases ๐
sources of law with different normative references usually get introduced into legislation when an act is adopted or issued, and they're either included in it or attached to it. so you need an alias that links the two sides of the same document ๐ซถ. the different measures can be:
- Adopted or issued by an authority that's different from the one the provision regulates (like the statute of a Body). Here the link goes between two uniform names that each have a completely different authority element (e.g.,
italian.society.authors.publishers:statuteandministry.cultural.activities+ministry.finances.budget.economic.planning:decree). ๐ญ - Issued by the institution itself, either because it has issuing authority or through a proxy (e.g., a provision about how the Body itself functions). Then the two aliases share the first part of the authority (e.g.,
municipality.firenze:statuteandmunicipality.firenze;council:deliberation). ๐๏ธ - Issued by the same Body to regulate a particular sector of its own competence. In this case the authority element is the same (e.g.,
ministry.justice:regulation;use.information.tools.telematic.processandministry.justice:decree). โจ
6.3. The Details Element ๐
6.3.1. Indication of the Details
the details of a source of law usually include the date it was enacted and its identification number (the inclusion in the body of laws, registry, protocol, etc.) ๐
some measures have multiple dates. there are also cases where a measure has no number (unnumbered measures) or has several numbers (e.g., unified cases). for all these reasons, setting up both the date and number elements includes multiple values ๐ซถ.
some institutions (e.g., Parliaments) usually identify documents by their period of reference (e.g., the legislature number) rather than by a date, which would be much less meaningful and never gets used in references (e.g., Senate bill S.2544 of the XIV legislature). in these cases, the period component gets swapped in for the date components ๐.
usually the details of a measure aren't reported in any specific sequence. but the uniform name goes from general to specific, so the date-number sequence looks like this:
details = (dates / period) ";" numbersexamples: "2000-12-06;126" and "14.legislature;s.2544" ๐
6.3.2. Multiple Dates ๐๏ธ
some sources of law are unique, but they're still identified by more than one date. in that case, all the given dates get reported like this:
dates = date *("," date)for example, the measure of the Data Protection Authority of December 30, 1999-January 13, 2000, No. 1/P/2000 has this uniform name:
personal.data.protection.authority:measure:1999-12-30,2000-01-13;1-p-2000as Section 3.6 says, all the dates can use the date typical of the jurisdiction in addition to the ISO format ๐.
6.3.3. Unnumbered Measures ๐ต๏ธ
measures that aren't officially numbered in the publications might have a non-unequivocal identifier, because several measures of the same type can exist and can be issued on the same day by the same authority ๐ฌ. so the uniform name is unambiguous, the numbers field MUST, in any case, contain a discriminating element. this can be any identifier used internally and not published by the authority (e.g., protocol) ๐.
if the authority doesn't have its own identifier, one identifier MUST be created for the name system. to tell it apart easily, that number gets the prefix "lex-":
number-lex = "lex-" 1*DIGITexample: "ministry.finances:decree:1999-12-20;lex-3" โจ
it's the responsibility of the authority issuing a document to assign it a discriminating specification. when there are multiple authorities, only one of them is responsible for assigning the number to the document (e.g., the proponent) ๐ค.
unnumbered measures published in an official publication (e.g., the Official Gazette) are recognized by the univocal identifying label printed on the paper, instead of a progressive number ๐จ๏ธ. even if that identifier is unofficial but assigned to a document in an official publication, it's preferred, because it has the clear advantage of being public and therefore easier to find ๐.
6.3.4. Multiple Numbers ๐ข
some legal documents (e.g., bills) are unique, but they're still identified by a set of numbers (e.g., the unification of cases or bills). in this case, all the identifiers go in the numbers field, following this structure:
number = document-id *("," document-id)example: "2000-06-12;c-10-97,c-11-97,c-12-97" ๐
the characters that aren't allowed (e.g., "/") or are reserved (e.g., ":"), including the comma, can't exist inside the document-id, so they MUST be turned into "-". no sneaking commas in there, bestie ๐ โโ๏ธ
when special characters 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 when converted to "-", a further ending must be added to tell the acts apart (e.g., bill n.123-bis-removal and 123-bis-return) ๐.
6.4. The Annex Element ๐
6.4.1. Formal Annexes
annexes are an integral part of a legal document, but they can get referred to and amended separately from the act they're annexed to ๐ง. so both the main document as well as each formal individual annex need to be unequivocally identified ๐ชช.
formal annexes can be registered as separate parts or together with a legal provision, and they may or may not be autonomous in nature. either way, they MUST be given a uniform name that includes the uniform name of the source of law they're attached to, plus a suffix that identifies the annex itself ๐.
the suffix of a formal annex includes the official heading of the annex and, maybe, further specifications (e.g., the title) that make it easier to retrieve the annex if the identifier goes missing:
annex = annex-id *(";" specification)example:
region.sicily;council:deliberation:1998-02-12;14:annex.a;borders.parkthe characters that aren't allowed (e.g., "/") or that are reserved (e.g., ":") must not be featured in the annex-id, so they MUST be turned into ".". ๐ธ
6.4.2. Annexes of Annexes ๐ช
when there are annexes to an annex, their identifiers get created by adding the identifiers of the annexes connected to it (meaning attached to it) onto the identifier of the original annex. for example, Table 1 attached to Annex A of the preceding legal act has this uniform name:
region.sicily;council:deliberation:1998-02-12;14:annex.a;borders.park:table.1;municipality.territories7. Specific Syntax of the Version Element of the "Expression" ๐
7.1. The Version Element ๐ฆ
7.1.1. Different Versions of a Legislative Document ๐
an updated text of a document can take one of the following forms:
- "multi-version": specific markups identify the modified parts (added, substituted, or deleted parts) and their related periods of effectiveness, all inside a single object (e.g., an XML file). this kind of document can show up in different forms depending on the requested date of effectiveness. a set of metadata usually holds the life cycle of the document (from the original to the last modification), including the validity time interval of each version and of each related text portion. ๐งฉ
- "single-version": a new and distinct object is created for each amendment to the text at a given time. each object is characterized by its own period of validity. either way, all the versions SHOULD be linked to one another and immediately navigable. ๐
in a "multi-version" document, each time interval should have a link to the related in-force document version that can be displayed. in a "single-version" document, the metadata should contain links to all the previous modifications and a link only to the following version, if any. ๐
[RFC8288] can be used as a 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:
current(orlastorlast-version): in-force version โจself: this version ๐ชnext: next version โญ๏ธprevious: previous version โฎ๏ธfirst: original version ๐ฑ
It is RECOMMENDED that these relations be inserted in the header of each version (if "single-version") or associated to each entry containing a single URN (if "multi-version"). main character energy, fr fr ๐
7.1.2. Identification of the Version โจ
okay bestie, so if you want to tell the different time versions of the same act apart, you have to slap a special suffix onto the uniform name of the original document ๐
That suffix is all about each version of a legal provision, and it starts with (first and foremost) one of these:
- The issuing date of the last amending measure taken into account. ๐
- The date that the communication of the rectification or errata corrige was published. ๐ฉท
- A specification that must identify the reason concerning the amendment (e.g., the specific phase of the legislative process), for the cases in which the date is not usually used (e.g., bills). ๐ธ
It's also possible to add extra specifications so each version stays distinct and the identifier is totally unequivocal ๐ Examples include changes to the in-force or effectiveness of a formal partition or portion of the text (e.g., when the amendments introduced by an act are applied at different times), or different events happening on the same date. Main character energy for the identifier ๐
version = (amendment-date / specification)
*(";" (event-date / event))where:
amendment-date: Contains the issuing date of the last considered amendment or of the last communication of amendment. If the original text introduces differentiated periods in which an act is effective and the information system produces one version for each of them, this element contains the string"original"expressed in the language of the act or version. ๐ฆspecification: Contains any information that is useful to identify the version unambiguously and univocally. ๐event-date: Contains the date in which a version is put into force, is effective, or is published. ๐event: A name assigned to the event producing a further version (e.g., amendment, decision, etc.). โจ
So why use the issuing date of an amending act as the identifier? Because it can be pulled straight from the heading (formal data), and that's iconic ๐
For example, 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. Then the same uniform name with the extra ending ;1999-01-01 points to the in-force or effective version starting on a different date (1/1/99). ๐๏ธ
Here's the big one ๐จ For full compatibility, every update of text, or of the effectiveness, of a "multi-version" document means creating a new uniform name, even if the object is single, containing the identifier of the virtually generated version, the same way a "single-version" document does. Specific metadata will link every uniform name to the period of time during which that name, and its matching text, is considered valid. For instance, the "multi-version" document containing "R.D. of 01/30/1941, no. 12", updated by the amendments introduced by the "D.Lgs. of 02/19/1998, no. 51", holds the name of the original version state:royal.decree:1941-01-30;12 AND the name of the updated version state:royal.decree:1941-01-30;12@1998-02-19. It's giving organized ๐๏ธ
Heads up ๐ If there are attachments or annexes, creating a new version (even if only one component changed) means creating a new uniform name for ALL the connected objects, so everything stays aligned: the main document, the attachments, and the annexes.
And as specified in Section 3.6, all the dates can have the date typical of the jurisdiction in addition to the date in ISO format ๐โจ
8. Summary of the Syntax of the Uniform Names of the LEX Namespace ๐
Okay, this is the grammar recap, and it's honestly so satisfying to look at ๐ซถ
; Structure of a Uniform Resource Name (URN) of the LEX namespace
; - NID = LEX namespace identifier
; - NSS = LEX Namespace Specific String
URN = "urn:" NID ":" NSS
NID = "lex"
; Structure of a LEX specific name
NSS = 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 = number / number-lex
number = (document-id *("," document-id))
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 = editor ":" format
[":" component [":" feature]]
editor = publisher *(";" specification)
publisher = alf-dot-hyp
format = mime *(";" specification)
mime = alf-dot-hyp
component = part *(";" specification)
part = alf-dot-hyp
feature = attribute *(";" specification)
attribute = alf-dot-hyp
; Structure of the date
date = date-iso ["|" date-loc]
date-iso = year "-" month "-" day
year = 4DIGIT
month = 2DIGIT
day = 2DIGIT
date-loc = *(alfadot / other)
; 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 = "-" / "_" / "'" / "=" / "(" / ")"9. Procedure of Uniform Names Assignment ๐
9.1. Specifying the Jurisdiction Element of the LEX Identifier ๐
So under the LEX namespace, every country or international organization gets a jurisdiction-code, which characterizes the URNs of that country's or jurisdiction's sources of law ๐ The code is assigned based on the ccTLD representation (or the TLDN (Top-Level Domain Name) or DN (Domain Name) for organizations), and it's the value of the jurisdiction-code element, which keeps the identifiers unique across countries. Cross-country uniqueness, iykyk ๐ซถ
9.2. Jurisdictional Registrar for Names Assignment ๐๏ธ
Any country or jurisdiction that wants to adopt this schema MUST identify a Jurisdictional Registrar. This is the organization that shares and defines the structure of the optional part (jurisdiction-unit) of the name, depending on how the state or institution is organized (for details, see Section 2.2). It must appoint a Jurisdictional Registrar and must apply the Designated Experts to register the new jurisdiction-code ๐
For example, in a federal state, a jurisdiction-unit matching 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 how the primary elements (issuing authority and type of legal measure) of the local-names get assigned, based on the characteristics of its own state or institution organization ๐๏ธ
The Jurisdictional Registrar MUST establish, following the guidelines in this document, a uniform procedure within the country or organization for defining local-name elements, making decisions about normalizations, solving and avoiding possible name collisions, and maintaining authoritative registries of various kinds (e.g., for authorities, types of measures, etc.). Accurate point-in-time representations of the structure and naming of government entities are important to semantically aware applications in this domain, so this really matters ๐
The Jurisdictional Registrar also shares and defines the rules for constructing partition IDs for each document type, possibly matching those already defined in other jurisdictions ๐
Finally, the Jurisdictional Registrar will develop and publish the rules and guidelines for constructing the local-name, plus the predefined values and codes. It should also promote the LEX URN identifier for the sources of law of its jurisdiction ๐ฃ
All institutional bodies that adopt the LEX URN identification system in a country or jurisdiction have to follow these rules, and so do private publishers. Each of them is responsible for assigning names within their own 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 the constructed URNs are guaranteed to be unique ๐ The Jurisdictional Registrar MUST provide clear documentation of the 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 that guarantee local-name uniqueness. If necessary, it attributes a conventional internal number which, 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. Name collisions? Not on my watch ๐
9.4. Identifier Persistence Considerations ๐ฆ
okay bestie, so persistence is all about how long the institutions handing out identifiers stick around ๐๏ธ๐ like the names are only as durable as the orgs behind them. The whole goal of the LEX schema is to keep every resource named by an assigned URN unique and persistent โจ main character energy for sure.
In particular, CNR is responsible for maintaining the uniqueness of the jurisdiction element ๐. The jurisdiction is based on the long-held ccTLD representation of the country (or the TLDN or DN of the organization), and that code is expected to continue indefinitely, so the URN also persists indefinitely ๐ literally forever vibes.
The naming rules are designed to hand off the job of keeping names unique to a set of authorities identified within each country or organization ๐ซถ.
So each authority is responsible for assigning URNs with a very long life expectancy that can stay unique for the foreseeable future ๐ฎ. Practical and political considerations, plus all the different ways governments organize themselves, will result in different methods of assigning responsibility for different levels of the name ๐ธ.
When an authoritative hierarchy can't pull this off, it's highly desirable to build consensus around a series of published rules for creating and administering names, run by institutions and bodies that operate through collaboration rather than compulsion ๐ค๐.
Issuing authorities that work at more localized scopes, from national all the way down to very local, MUST equally take responsibility for the persistence of identifiers within their scope ๐จ.
10. Recommendations for the Resolution Process ๐ง
10.1. General Architecture of the System ๐
okay so the job of the resolution service is to match a LEX identifier with a specific document address on the Internet ๐ฆ. Unlike systems built around rigorous, enforceable engineering premises, like DNS, the LEX namespace resolver is going to be expected to handle a wide variety of inputs that are incomplete or partially incorrect ๐, especially the ones created by automatically pulling references out of texts. So this document really leans into a flexible, robust resolver design ๐ .
The system has a distributed architecture built on two fundamental pieces: a chain of information in the DNS, and a series of resolution services going from URNs to URLs, each one competent within its own specific domain of the namespace ๐ซง.
The client grabs the document linked to this URN using the procedure in [RFC3404], which kicks off 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 resolving and managing them are robust and actually 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 when a new country (e.g., br) or organization is added (see Section 2.2). This delegation 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., the lex.senado.gov.br zone) and routing the resolution towards its resolvers based on 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 pretty frequent in legal citations, so incomplete or inaccurate uniform names of the referred document are likely to be built from textual references (this is even more frequent if they're created automatically through a specific parser ๐ค). For this reason, implementing a catalogue based on a relational database is suggested, since it leads 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 registries 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 ๐.
11. Security Considerations ๐
Security considerations are the ones normally associated with using and resolving URNs in general ๐ก๏ธ. Additional security considerations about the authenticity of a document don't pertain to the LEX specifications, but they do pertain to security and trust issues that can be addressed with other means, like digital signatures, data encryption, etc. ๐ So that part is on other tools, not LEX alone, bestie.
12. IANA Considerations ๐
IANA has registered LEX namespace in the "Formal URN Namespaces" registry [RFC8141] ๐.
In addition, to activate a distributed resolution system, IANA has registered the following NAPTR record in the URN.ARPA domain ๐ง:
lex.urn.arpa.
IN NAPTR 100 10 "" "" "" lex-nameserver.nic.it.Note that lex-nameserver.nic.it indicates the CNR server (see Section 2.2) that is responsible for the resolution of the LEX namespace at the time of this writing ๐ธ.
13. References โจ
13.1. Normative References ๐
[ISO.8601-1.2019]ISO, "Date and time - Representations for information interchange", ISO 8601-1:2019, February 2019,<https://www.iso.org/standard/70907.html>.[ISO.8601-2.2019]ISO, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO 8601-2:2019, February 2019,<https://www.iso.org/standard/70908.html>.[RFC2045]Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,<https://www.rfc-editor.org/info/rfc2045>.[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,<https://www.rfc-editor.org/info/rfc2119>.[RFC3404]Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, DOI 10.17487/RFC3404, October 2002,<https://www.rfc-editor.org/info/rfc3404>.[RFC3405]Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", BCP 65, RFC 3405, DOI 10.17487/RFC3405, October 2002,<https://www.rfc-editor.org/info/rfc3405>.[RFC3629]Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003,<https://www.rfc-editor.org/info/rfc3629>.[RFC3986]Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,<https://www.rfc-editor.org/info/rfc3986>.[RFC5234]Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,<https://www.rfc-editor.org/info/rfc5234>.[RFC5646]Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009,<https://www.rfc-editor.org/info/rfc5646>.[RFC5891]Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010,<https://www.rfc-editor.org/info/rfc5891>.[RFC5893]Alvestrand, H., Ed. and C. Karp, "Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)", RFC 5893, DOI 10.17487/RFC5893, August 2010,<https://www.rfc-editor.org/info/rfc5893>.[RFC5894]Klensin, J., "Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale", RFC 5894, DOI 10.17487/RFC5894, August 2010,<https://www.rfc-editor.org/info/rfc5894>.[RFC8126]Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,<https://www.rfc-editor.org/info/rfc8126>.[RFC8141]Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,<https://www.rfc-editor.org/info/rfc8141>.[RFC8174]Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,<https://www.rfc-editor.org/info/rfc8174>.[RFC8288]Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017,<https://www.rfc-editor.org/info/rfc8288>.[W3C.HTML]"HTML", W3C REC HTML, W3C HTML,<https://www.w3.org/TR/html/>.
13.2. Informative References ๐ฆ
[FRAN]Francesconi, E., "Technologies for European Integration. Standards-based Interoperability of Legal Information Systems", ISBN 978-88-8398-050-3, 2007.[FRBR]International Federation of Library Associations and Institutions, "Functional Requirements for Bibliographic Records", February 2009,<https://www.ifla.org/files/assets/cataloguing/frbr/frbr_2008.pdf>.[HCPIL]The European Commission, "Access to Foreign Law in Civil and Commercial Matters", The Hague Conference on Private International Law, February 2012,<https://assets.hcch.net/docs/b093f152-a4b3-4530-949e-65c1bfc9cda1.pdf>.[ISBD]The Standing Committee of the IFLA Cataloguing Section Berlin/Munich: De Gruyter Saur, "ISBD: International Standard Bibliographic Description โ Consolidated Edition", ISBN 978-3-11-026379-4, 2011.[ISO.3166-1]ISO, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes, ISO 3166-1:2020, 2020.", 2020.[LVI]Peruginelli, G., Ed. and M. Ragona, Ed., "Law via the Internet. Free Access, Quality of Information, Effectiveness of Rights", ISBN 9788883980589, April 2009.[SART]Sartor, G., Palmirani, M., Francesconi, E., and M. Biasiotti, "Legislative XML for the Semantic Web: Principles, Models, Standards for Document Management", ISBN 978-94-007-1887-6, 2011.[SPIN]Spinosa, P., "Identification of Legal Documents through URNs (Uniform Resource Names)", Proceedings of the EuroWeb 2001, The Web in Public Administration , 2001.[W3C.RDF-SCHEMA]Brickley, D., Ed. and R. Guha, Ed., "RDF Schema 1.1", W3C REC rdf-schema, W3C rdf-schema, February 2014,<https://www.w3.org/TR/rdf-schema/>.
Acknowledgements โจ
The authors wish to thank all those who provided suggestions and comments. ๐ซถ
The authors are grateful to the Legislative XML community [SART] for the interesting discussions on this topic, and to the Working Group "Identification of the legal resources through URNs" of the Italian NormeInRete project for the guidance provided [SPIN]. ๐
The authors owe a debt of gratitude to Tom Bruce, former director of the Legal Information Institute of the Cornell University Law School, for his contribution in revising this document and sharing fruitful discussions that greatly improved the document. 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 improving this document, as well as for the common work aimed to harmonize the 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 draft versions of this document, which provided significant improvements to the final document. Thanks also 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 document. ๐
Finally, many thanks go to Loriana Serrotti, who significantly contributed to the first draft versions of this document. ๐
Authors' Addresses ๐
PierLuigi Spinosa
Via Zanardelli, 15
50136 Firenze
Italy
Phone: +39 339 5614056
Email: pierluigi.spinosa@gmail.comEnrico Franceseconi
National Research Council of Italy (CNR)
Via de' Barucci, 20
50127 Firenze
Italy
Phone: +39 055 43995
Email: enrico.francesconi@cnr.itCaterina Lupo
Via San Fabiano, 25
117 Roma
Italy
Phone: +39 3382632348
Email: caterina.lupo@gmail.com๐ฆ where this page comes from
- ietf: rfc9676 2025-05
- ๐ girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms