Network Working Group
Independent Submission P. Spinosa
Internet-Draft
Intended status:
Request for Comments: 9676
Category: Informational E. Francesconi
Expires: 18 February 2025
ISSN: 2070-1721 National Research Council of Italy (CNR)
C. Lupo
17 August
November 2024
A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)
draft-spinosa-urn-lex-24
Abstract
This document describes a Uniform Resource Name (URN) Namespace
Identifier namespace
identifier for identifying, naming, assigning, and managing
persistent resources in the legal domain. This specification is
published to allow allows
adoption of a common convention by multiple jurisdictions to
facilitate ease of reference and access to resources in the legal
domain.
This specification is an independent submission Independent Submission to the RFC series. Series.
It is not a standard, standard and does not have the consensus of the IETF.
Status of This Memo
This Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
published for informational purposes.
This is a contribution to the
provisions RFC Series, independently of BCP 78 any other
RFC stream. The RFC Editor has chosen to publish this document at
its discretion and BCP 79.
Internet-Drafts makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are working documents not candidates for any level of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list Standard;
see Section 2 of RFC 7841.
Information about the current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 18 February 2025.
https://www.rfc-editor.org/info/rfc9676.
Copyright Notice
Copyright (c) 2024 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)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Purpose of Namespace the "lex" . . . . . . . . . . . . . 4 Namespace
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. General Characteristics of the System . . . . . . . . . . 6
1.4. Linking a LEX Name to a Document . . . . . . . . . . . . 8
1.5. Use of LEX Names in References . . . . . . . . . . . . . 8
1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9
1.7. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9
1.8. Syntax Used in this This Document . . . . . . . . . . . . . . 9
1.9. Namespace Registration . . . . . . . . . . . . . . . . . 9
2. Registration of LEX . . . . . . . . . . . . . . . . . . . . . 9
2.1. Identifier Structure . . . . . . . . . . . . . . . . . . 9
2.2. Jurisdiction-code Jurisdiction-Code Register . . . . . . . . . . . . . . . 11
2.3. Conformance with URN Syntax . . . . . . . . . . . . . . . 13
2.4. Validation Mechanism . . . . . . . . . . . . . . . . . . 13
2.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. General Syntax and Features of the LEX Identifier . . . . . . 13
3.1. Allowed and Not Allowed Characters . . . . . . . . . . . 13
3.2. Reserved Characters . . . . . . . . . . . . . . . . . . . 14
3.3. Case Sensitivity . . . . . . . . . . . . . . . . . . . . 14
3.4. Unicode Characters outside Outside the ASCII Range . . . . . . . 14
3.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16
3.6. Date Format . . . . . . . . . . . . . . . . . . . . . . . 17
4. Specific Syntax and Features of the LEX Identifier . . . . . 17
4.1. Spaces, Connectives Connectives, and Punctuation Marks . . . . . . . . 18
4.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Ordinal Numbers . . . . . . . . . . . . . . . . . . . . . 18
5. Creation of the Source of Law LEX Identifier - Identifier: Baseline
structure . . . . . . . . . . . . . . . . . . . . . . . . 18
Structure
5.1. Basic Principles . . . . . . . . . . . . . . . . . . . . 18
5.2. Model of Sources of Law Representation . . . . . . . . . 19
5.3. The Structure of the Local Name . . . . . . . . . . . . . 20
5.4. Structure of the Document Identifier at "Work" Level . . 21
5.5. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.6. Structure of the Document Identifier at "Expression" Level . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.7. Structure of the Document Identifier at "Manifestation"
Level . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.8. Sources of Law References . . . . . . . . . . . . . . . . 25
6. Specific Syntax of the Identifier at "Work" Level . . . . . . 27
6.1. The authority Authority Element . . . . . . . . . . . . . . . . . . 27
6.1.1. Indication of the Authority . . . . . . . . . . . . . 27
6.1.2. Multiple Issuers . . . . . . . . . . . . . . . . . . 28
6.1.3. Indication of the Issuer . . . . . . . . . . . . . . 28
6.1.4. Indication of the Body . . . . . . . . . . . . . . . 28
6.1.5. Indication of the Function . . . . . . . . . . . . . 28
6.1.6. Conventions for the Authority . . . . . . . . . . . . 29
6.2. The measure Measure Element . . . . . . . . . . . . . . . . . . . 29
6.2.1. Criteria for the Indication of the Type of Measure . 29
6.2.2. Further Specification to the Type of Measure . . . . 29
6.2.3. Aliases for Sources of Law with Different Normative
References . . . . . . . . . . . . . . . . . . . . . 30
6.2.4. Relations between Between Measure and Authority in the Aliases . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. The Details Element . . . . . . . . . . . . . . . . . . . 30
6.3.1. Indication of the Details . . . . . . . . . . . . . . 31
6.3.2. Multiple Dates . . . . . . . . . . . . . . . . . . . 31
6.3.3. Unnumbered Measures . . . . . . . . . . . . . . . . . 32
6.3.4. Multiple Numbers . . . . . . . . . . . . . . . . . . 32
6.4. The annex Annex Element . . . . . . . . . . . . . . . . . . . . 33
6.4.1. Formal Annexes . . . . . . . . . . . . . . . . . . . 33
6.4.2. Annexes of Annexes . . . . . . . . . . . . . . . . . 33
7. Specific Syntax of the Version Element of the "Expression" . 34
7.1. The version Version Element . . . . . . . . . . . . . . . . . . . 34
7.1.1. Different Versions of a Legislative Document . . . . 34
7.1.2. Identification of the Version . . . . . . . . . . . . 35
8. Summary of the Syntax of the Uniform Names of the "lex"
Namespace . . . . . . . . . . . . . . . . . . . . . . . . 36
9. The Procedure of Uniform Names Assignment . . . . . . . . . . 40
9.1. Specifying the jurisdiction Jurisdiction Element of the LEX Identifier . . . . . . . . . . . . . . . . . . . . . . . 40
9.2. Jurisdictional Registrar for Names Assignment . . . . . . 40
9.3. Identifier Uniqueness . . . . . . . . . . . . . . . . . . 41
9.4. Identifier Persistence Considerations . . . . . . . . . . 42
10. Recommendations for the Resolution Process . . . . . . . . . 42
10.1. The General Architecture of the System . . . . . . . . . 43
10.2. Catalogues for Resolution . . . . . . . . . . . . . . . 44
10.3. Suggested Resolver Behaviour . . . . . . . . . . . . . . 44 Behavior
11. Security Considerations . . . . . . . . . . . . . . . . . . . 45
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
14.1.
13.1. Normative References . . . . . . . . . . . . . . . . . . 46
14.2.
13.2. Informative References . . . . . . . . . . . . . . . . . 48
Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction
1.1. The Purpose of Namespace 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 and law, administrative acts 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 is, the
body of knowledge and theoretical speculation typical of legal
scholars (e.g. (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 on-line online availability,
its
physical location, and access mode. The identifier itself is
assigned by the jurisdiction of the identified document. Even a 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
on-line
online environment with resources distributed among different web
publishers, lex URNs allow a simplified global interconnection of
legal documents by means of automated resoluton. 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 URNs URN details can be used as
a reference to create HTTP-based 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 2001, the Italian Government, Government promoted the NormeInRete project
through the National Center for Information Technology in the Public
Administration, the Ministry of
Justice Justice, and CNR (the the National Research
Council of Italy) promoted the Italy (CNR). The NormeInRete project. It project was aimed at
introducing standards for describing and identifying sources of law description and identification
using XML and URN techniques.
Other national initiatives in Europe introduced standards for the
description of legal sources [FRAN]. Collaborations between
government, national research institutes, and universities, 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 society, the processes of political, social social,
and economic integration of European Union (EU) member states states, as
well as the increasing integration of the world-wide worldwide legal and
economic processes processes, are causing a growing interest in exchanging the exchange of
legal information knowledge at national and trans-national 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 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.
The In
several conferences (such as [LVI]), representatives of the
Publications Office of the European Union (OP) have expressed the
need for a unique identifier of for sources of law in different EU
Member States, law, based on open
standards and able to provide advanced modalities of document hyper-linking, has been expressed in several
conferences (as [LVI]) by representatives of the Publications Office
of the European Union (OP),
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]
that encourage encourages State
Parties to "adopt neutral methods of citation of their legal
materials, including methods that are medium-neutral,
provider-neutral provider-
neutral and internationally consistent.". consistent". In a similar
direction 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 to for them.
The
Additionally, the need of for unique identifiers for sources of law is
of particular interest also 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 prosecutors, and judges to
become more aware not only of (directly applicable) EU law, but laws and also
of the
various national legal systems. The growing importance of national
judiciaries for the application of Community 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 Similarly, the
Council of the European Union has underlined the importance of cross-border cross-
border access to national case law, as well as the need for its standardisation,
standardization, in view of an integrated access in a decentralized
architecture. In this view 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 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 EU European Union
decided in 2009 to elaborate on a uniform, uniform European system for the
identification of case law (ECLI: (i.e., the European Case-Law Identifier) Identifier
(ECLI)) and a uniform Dublin
Core-based set of metadata. metadata based on the Dublin Core.
The Council of the European Union invited the Member States to
introduce in the legal information systems the European Legislation Identifier (ELI), (ELI) in the legal
information systems, which is an http-based http-based, Semantic Web oriented Web-oriented
identification system for legislation of the European Union and
Member States legislation. States.
The LEX identifier (also referred to in this text as "LEX name") is
conceived to be general enough so as to provide guidance at the core of the
standard and offer sufficient flexibility to cover a wide variety of
needs for identifying all the legal documents of different nature,
namely types, namely,
legislative, case-law 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 is, there is more than one manifestation of the
same legal document).
Specifications and syntax rules of for the LEX identifier can also be
used also for http-based naming convention conventions to cope with different
requirements in legal information management, for example example, the need of having
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 be: have the following
qualities:
* globally unique
* transparent
* reversible
* persistent
* location-independent, and location-independent
* language-neutral. language-neutral
These qualities facilitate legal document management of legal documents and a
mechanism
of for stable cross-collections cross-collection and cross-country references.
Transparency means that that, for a given an act and its relevant metadata
(issuing authority, type of measure, etc.), it is possible to create
the
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,
Language neutrality, in particular, is an important feature that
promotes adoption of the standard by organizations that must adhere
to official-language 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 pre-existing preexisting standard specification
("country/jurisdiction name standard") to indicate the country (or
more generally 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 identification
system operating in that nation nation, and it is mainly composed by
formalized information related to the enacting authority, the type of
measure, the details details, and possibly the annex.
The identification system based on uniform names includes:
* a A schema for assigning names capable of representing unambiguously representing
any addressed source of law (namely legislation, case law law, and
administrative acts), acts) issued by any authority (intergovernmental,
supranational, national, regional regional, and local) at any time (past,
present
present, and future); future).
* a A resolution mechanism - -- in a distributed environment - -- that
ties a uniform name to the on-line 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 meta-information,
which may be specified as follows:
* within Within the document itself through a specific element within an
XML schema or by an [W3C.HTML] META tag; a meta tag [W3C.HTML].
* externally Externally by means of a Resource Description Framework
[W3C.rdf-schema]
[W3C.RDF-SCHEMA] triple, a specific attribute in a database, etc.
At least one of these references is necessary to enable automated
construction and
construction, an update of catalogues (distributed and centralized) centralized),
and the implementation of resolvers that associate the uniform name
of a document with its physical location(s). location. LEX assumes no particular
relationship between the originator of the document, its publisher, and
the implementer of catalogues 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:
* by manually Manually inserting in the referring document the link with the uniform name: this name in the referring
document. This is a burdensome procedure, especially for
documents that are already on-line; online.
* by automatically Automatically constructing (either permanently or temporarily) the
link with the uniform name, name through reference parsers of a
text: this is a more time-saving 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. This Nevertheless, this solution could nevertheless be
acceptable for already published already-published documents.
Whatever
No matter which method is adopted, new documents produced in whatever a
certain format (for example example, XML, XHTML, etc) etc.) should express
references through the uniform name of the document referred to.
1.6. Definitions
The following terms are used in these specifications:
* this document:
Source of Law: a A general concept to refer that refers to legislation, case
law, regulations 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 document, "source
of Law" refers law" also refers to acts during their making creation, such as bills bills,
that might or might not become laws;
* laws.
Jurisdictional Registrar: an An organization in any jurisdiction that
shares and defines
in any jurisdiction 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 This Document
This document uses the a syntax common to many Internet RFCs, which that is based on the ABNF (Augmented Backus-Naur Form) Augmented Backus-
Naur Form (ABNF) [RFC5234] meta-
language. meta-language, which is used in many RFCs.
1.9. Namespace Registration
The "lex" namespace has already been registered in the "Formal URN
Namespaces" registry. See Section 12.
2. Registration of LEX
2.1. Identifier Structure
The identifier has a the following hierarchical structure as follows: structure:
"urn:lex:" NSS
where NSS is the Namespace Specific String composed as follows:
NSS = jurisdiction ":" local-name
where:
* jurisdiction identifies
jurisdiction: Identifies the scope (state, regional, municipal,
supranational
supranational, or of an organization) organizational) where a set of sources of law
have validity. It is also possible to represent international
organizations (either states or states, public administrations administrations, or private
entities);
* local-name is the
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 already-adopted schemas. It represents all aspects of an
intellectual production, from its initial idea, through its
evolution during the time, to its realisation realization by different means
(paper, digital, etc.).
The jurisdiction element is composed of two specific fields:
jurisdiction = jurisdiction-code *(";" jurisdiction-unit)
where:
* jurisdiction-code is usually
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
follows usually follows the rules of
identification of other Internet applications, based on domain
name (for details and special cases cases, see Section 2.2).
Due to the differences in representation in the various languages
of a country, for an easier identification of the country the use of the standard [ISO3166-1] [ISO.3166-1] is strongly RECOMMENDED.
Therefore
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 %-encoding) (see percent-encoding; see
Section 3.4).
Where applicable, the domain name of the country or multinational
or international organisation 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 are the The possible administrative hierarchical
sub-structures sub-
structures defined by each country or organisation organization within their
specific legal system. This additional information can be used in case
when two or more levels of legislative or judicial production
exist (e.g., federal, state state, and municipality level) and the same
bodies may be present in each jurisdiction. Therefore Therefore, acts of
the same type issued by similar authorities in different areas
differ for the jurisdiction-unit specification.
An example can be the following:
The following is an example:
"br:governo:decreto" (decree of federal government), government)
"br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state)
"br;sao.paulo;campinas:governo:decreto" (decree of Campinas
municipality).
Fictitious
municipality)
The following are fictitious examples of sources of law identifiers are: 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 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 The identifier of jurisdiction, jurisdiction assigned to the
country or organisation;
* organization.
jurisdiction: the The official name of the jurisdiction, country or
organisation;
*
organization.
registrant: essential Essential information to identify that identifies the organization
that requested the registration of the code. The registrant will
be responsible for its DNS zone and for zone, the attribution of sub-
zone sub-zone
delegations, and so on. It is RECOMMENDED that each jurisdiction
create a registry of all delegated levels so that the organization
responsible of for each sub-zone can easily be
identified;
* identified.
reference: a A reference to the defining document (if any).
The table registry is initially empty. Possible The following are possible example entries are:
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\]
Note that this is a CNR registry and *not* an IANA registry.
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) designated
expert(s) according to the established rules of governance (published
in
on the CNR website dedicated to the LEX governance). The application
will be evaluated according to the Jurisdictional Registrar
authoritativeness and the offered guarantees. The Designated
Expert(s) designated
expert(s) will evaluate such applications, applications with a similar approach as
evaluations of the DNS. Typically 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" as policy specified in [RFC8126]. Designated Experts 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
ccTLD, top-level
Country Code Top-Level Domain (ccTLD), then the top level top-level ccTLD
should be used as the jurisdiction
code; 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, Nations and World Trade Organization) organizations
Organization), the Top
Level Top-Level Domain Name (e.g., "eu") or the
Domain Name (e.g., "un.org", "un.org" and "wto.org") of the organization
should be used as the jurisdiction
code; code.
* in case when such If a multi-national or international organization does not have a
registered domain, Designated Expert(s) the designated expert(s) should assign
something like name.lex.arpa, "name.lex.arpa", where the name will be the acronym
of the organization name, name in the language chosen by the
organization itself. For example, the jurisdiction code of the
European Economic Community could be "eec.lex.arpa". Anyway the The alias
mechanism allows to have for acronyms in different languages.
Jurisdiction codes MUST NOT be renamed, because that would violate
rules
the rule that URN assignments are be persistent.
Jurisdiction codes MUST NOT ever be deleted. They can only be marked
as "obsolete", i.e. 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).
Designated Expert(s) expert(s) can unilaterally initiate allocation or
obsolescence of a jurisdiction code.
Request
Requests for new jurisdiction code assignment assignments must include the
organization or country requesting it and Contact 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 to identify 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 fact, each body that enacts sources of law can
identify them by this scheme. Furthermore, other bodies (even not non-
enacting sources of law, such as newspaper or newspapers, magazine publishers,
etc.) aiming that aim to refer reference legal documents, documents can unequivocally
identify them by this scheme.
3. General Syntax and Features of the LEX Identifier
This section lists the general features applicable to all
jurisdictions.
3.1. Allowed and Not Allowed Characters
These
The characters are defined in accordance with the [RFC8141]
"Uniform Resource Names (URNs)". [RFC8141]. For various reasons, later
explained, in the "lex" NSS
reasons that are explained later, only a subset of characters is allowed.
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 Separator of the expression, expression that contains information on
version and language; language.
"$" separator Separator of the manifestation, manifestation that contains information on
format, editor, etc.; etc.
":" separator Separator of the main elements of the name at any entity; entity.
";" separator Separator of the level. It identifies the introduction of an
element at a hierarchically lower level, level or the introduction of
a
specification; specification.
"+" separator Separator of the repetitions of an entire main element (e.g.,
multiple authorities); authorities).
"|" separator Separator between different formats of the same element (e.g.,
date);
date).
"," separator Separator of the repetitions of individual components in the
main elements, each bearing the same level of specificity
(e.g., multiple numbers); numbers).
"~" separator Separator of the partition identifier in references (e.g.,
paragraph of an article); article).
"*" and Reserved for future expansions.
"!" are reserved 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 (upper (uppercase or lower cases) lowercase)
or different spelling spellings of the same word are possible, names belonging
to "lex" namespace are case-insensitive. It For the Latin alphabet, it
is RECOMMENDED that, in
latin alphabet, they that names be created in lower case, but names that
differ only in case, case or in the spelling, spelling of the same word MUST be
considered
to be equivalent (e.g., "Ministry" will be recorded as
"ministry").
3.4. Unicode Characters outside Outside the ASCII Range
In order to exploit the DNS as a routing tool towards the proper
resolution system, to keep editing and communication more simple simple, and
to
avoid character percent-encoding, it is RECOMMENDED that the characters
outside the ASCII range (e.g. (e.g., national characters, diacritic signs, ...) are turned into
etc.) be replaced by base ASCII characters (e.g., characters. For example, the Italian
term "sanitU+00E0" can be replaced into by "sanita", the French term
"ministU+00E8re" can be replaced into "ministere"), in case by
transliteration (e.g. "ministere", and "MU+00FCnchen"
can be replaced into "muenchen"). by "muenchen" (transliteration).
This mapping consists of:
* transcription Transcription from non-Latin alphabets; alphabets
* transliteration Transliteration of some signs (diaeresis, eszett, ...); (e.g., diaeresis and eszett)
* preservation Preservation of the only the basic characters, eliminating the signs
placed above (accents, tilde, ...), (e.g., accents and tilde), below (cedilla, (e.g., cedilla and
little tail,
...) tail), or on (oblique cut, ...). (e.g., oblique cut)
The most suitable, well-known well-known, and widespread mapping system for a
given language MUST be chosen by the jurisdiction, or, or in agreement
with this one, by the jurisdiction-unit in case of different
languages in the various regions, also taking into account the choices
made for the same language by other jurisdictions.
Certainly this This mapping is
simpler and more feasible for languages that use the Latin alphabet
and gradually becomes more complex both for other alphabets and for
writing systems with 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 Unicode MUST be used and, used, and for
accessing network protocols, any UNICODE Unicode code points outside the
ASCII range MUST be converted in to UTF-8 %-encoding percent-encoding according to
[RFC3986] and [RFC3629]. [RFC3629] .
In this case case, it should be noted that the generated URN (as some of
its parts) cannot be used directly for routing through DNS, and
therefore the DNS.
Therefore, the jurisdiction must adopt one of the following
strategies:
* to convert Convert non-ASCII characters within the DNS into the IDN
encoding, encoding
using the [RFC5894] punycode Punycode translation (e.g. [RFC5894] (e.g., mU+00FCnchen in xn--mnchen-3ya), xn--
mnchen-3ya) and to develop a software interface that converts the URN
before the navigation in DNS, or the DNS.
* to create Create a routing service relying on a software, out outside of the
DNS,
addressing that addresses a proper resolution service.
Note that the urn:lex ID, ID could contain groups of characters (UTF-8
%-encoded)
percent-encoded) of some languages with different orientations: in orientations. In
this
case case, the BiDi rules apply [RFC5893].
Summarizing, the preference
The preferred order is the following: summarized as follows:
* Conversion into basic ASCII, ASCII is the RECOMMENDED solution (for not
having to make conversions for network protocols and DNS); the DNS).
* Using UNICODE, Unicode and convert into converting to UTF-8 %-encoding [RFC3629], percent-encoding [RFC3629]
for accessing network protocols, protocols and to punycode [RFC5894], Punycode [RFC5894] only for
navigation in DNS, DNS via software interface; interface.
* Creation of a routing service relying on a software, out software outside of DNS, DNS
and addressing a proper resolution service.
The first solution allows native DNS routing, routing while the other two
solutions require software development for the interface or the
routing.
However However, it is up to the specific jurisdiction to choose
the preferred solution.
Two
The following are two examples (Latin and Cyrillic alphabet) alphabets)
relating to the different solutions adopted are here reported:
a adopted:
* A circular adopted by the Municipality of Munich (Rundschreiben
der Stadt MU+00FCnchen):
- ascii = urn:lex:de:stadt.munchen:rundschreiben:... ASCII:
urn:lex:de:stadt.munchen:rundschreiben: ...
- unicode = urn:lex:de:stadt.mU+00FCnchen:rundschreiben:... Unicode:
urn:lex:de:stadt.mU+00FCnchen:rundschreiben: ...
- utf-8 = urn:lex:de:stadt.m%xC3%xBCnchen:rundschreiben:... UTF-8:
urn:lex:de:stadt.m%xC3%xBCnchen:rundschreiben: ...
- punycode = urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben:...
a Punycode:
urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben: ...
* A state law of the Russian Federation (latin: (Latin: gosudarstvo zakon;
cyrillic:
Cyrillic: U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435
U+0437U+0430U+043AU+043EU+043D):
- ascii = urn:lex:ru:gosudarstvo:zakon:... ASCII:
urn:lex:ru:gosudarstvo:zakon: ...
- unicode = Unicode:
urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D
U+0438U+0435:U+0437U+0430U+043AU+043EU+043D:...
U+0438U+0435:U+0437U+0430U+043AU+043EU+043D: ...
- utf-8 = 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:...
%xD0%xBE%xD0%xBD: ...
- punycode = urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme:...
assuming Punycode:
urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme: ...
| Note: The above assumes that the Russia jurisdiction-code is
| expressed in ASCII ("ru"), while the Cyrillic version
| ("U+0440U+0444") has the
puny-code Punycode "xn--p1ai".
3.5. Abbreviations
Abbreviations are often used in law for indicating institutions (e.g.
(e.g., Min.), structures (e.g. (e.g., Dept.), or legal measures (e.g. Reg.) (e.g.,
Reg.), but they are not used in a uniform way, therefore way. Therefore, their
expansion is highly RECOMMENDED (e.g., "Min." is reported expanded as
"ministry").
3.6. Date Format
The
[ISO.8601.1988] is describes the international format for representing
dates: therefore dates
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
(e.g.,
For example, "September 2, 99" will be written as "1999-09-02"). "1999-09-02".
This format ensures interoperability between different representation
systems
systems, and there are several programs for mapping other formats to
this one.
However, to make facilitate reading and understanding such other formats (e.g. (e.g.,
Jewish calendar), the urn:lex scheme provides that allows for the date can to be added
in the jurisdiction's own format
(e.g. format. For example, the date in the
previous example would be 21.Elul,5759, that is:
- in
* In Hebrew characters:
"U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.U+05EA
U+05E9U+05E0U+05F4U+05D8";
- in UTF-8 code:
"%x5c%x75%x30%x35%x44%x42%x5c%x75%x30%x35%x46%x34%x5c%x75%x30%x35
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").
%x5c%x75%x30%x35%x44%x38
Therefore, for all the dates in the urn:lex identifier (see
Section Sections
6.3 and Section 7.1.2), it is also possible to indicate the
one date in the local
format:
date = date-iso [ "|" date-loc ]
(e.g.,
For example, "September 2, 99" will be written in ISO plus format and
Hebrew format as
"1999-09-02|U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.
U+05EAU+05E9U+05E0U+05F4U+05D8"). follows:
1999-09-02|U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.
U+05EAU+05E9U+05E0U+05F4U+05D8
The characters which that are not allowed (e.g. (e.g., "/") or which are reserved
(e.g. (e.g.,
",") cannot exist inside the date-loc and therefore MUST be turned
into ".".
4. Specific Syntax and Features of the LEX Identifier
In this
This section there are other discusses features related to specific
jurisdictions and the jurisdictions.
The implementation of which these features is RECOMMENDED.
4.1. Spaces, Connectives Connectives, and Punctuation Marks
All the
When explicitly present, all language connectives (e.g., articles,
prepositions, etc.),
the punctuation marks marks, and all the special characters (as (e.g.,
apostrophes, dashes, etc.), when explicitly present, 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". space (e.g., "Ministry of Finances, Budget Budget,
and of Economic Planning" becomes "ministry.finances.budget.economic.planning";
"ministry.finances.budget.economic.planning" and "Ministerstvo
Finansov" becomes "ministerstvo.finansov") "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 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: expression, whether in Roman
numerals, or with an adjective, or in Arabic numeral numerals with an apex, etc.
(IV, (such as
IV, third, 1U+00B0, 2^, etc.)
(e.g., and 2^). For example, "Department IV" becomes "department.4").
"department.4".
5. Creation of the Source of Law LEX Identifier - Identifier: Baseline structure Structure
5.1. Basic Principles
The uniform name must identify one and only one document (more
precisely a "bibliographic resource" [ISBD], [ISBD]; see also Section 5.2)
and is created in such a way that it is:
* self-explanatory; self-explanatory,
* identifiable through simple and clear rules; rules,
* compatible with the practice commonly used for references; references,
* able to be created from references in the text, automatically (by
parser) or manually; 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 [FRBR] (Functional Functional Requirements for Bibliographic
Records) 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, four fundamental entities (or aspects) can
be specified.
production.
The first two entities reflect its contents:
*
work: identifies Identifies a distinct intellectual creation; in our case, it
identifies a source of law both in its original form as amended
over time;
* time.
expression: identifies Identifies a specific intellectual realisation realization of a
work; in our case 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 Identifies a physical embodiment of an expression of
a work; in our case case, it identifies embodiments in different media
(printing, digital, etc.), encoding formats (XML, PDF, etc.), or
other publishing characteristics;
* characteristics.
item: identifies Identifies a specific copy of a manifestation; in our case case, it
identifies individual physical copies as they are found in
particular physical locations.
In this document 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 scenario, the main characteristic of the
expression of an act is represented by its validity over the time, 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 Therefore, notes,
summarizations, summaries,
comments, anonymizations anonymizations, and other editorial activities over the
same text do not produce different expressions,
but expressions. Instead, they
produce different manifestations.
5.3. The 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, at "work" level, three components are always
present: present at the
"work" level: the enacting authority, the type of provision provision, and the
details. A fourth component, the annex, can also be added if any. added. It is
often necessary to differentiate various expressions, that is:
* the original version and all the amended versions of the same
document;
document, and
* the versions of the text expressed in the different official
languages of the state or organization.
Finally
Finally, the uniform name allows a distinction among diverse
manifestations, which
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 (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 uniform name at each
level (work, expression, and manifestation) is expressed in the
official language of the relevant jurisdiction; jurisdiction. More language-
dependent names (aliases) are created in case of cases where there are
multiple official languages (as in Switzerland) or more involved
jurisdictions (as in international treaties), more language-dependent names (aliases) are
created. 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 which includes: that includes the following: the original
main document, the annexes, and all their the versions, languages 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,
other and ordered by increasingly narrow domains and competencies:
work = authority ":" measure ":" details *(":" annex)
where:
* authority is the
authority: The issuing or proposing authority of the measure (e.g., State, Ministry, Municipality, Court, etc.);
* measure is the
state, ministry, municipality, court, etc.).
measure: The type of the measure, both public nature (e.g., constitution,
act, treaty, regulation, decree, decision, etc.) as
well as and private one
(e.g., license, agreement, etc);
* details are the etc.).
details: The terms associated to with the measure, typically the date
(usually the signature date) and the number included in the
heading of the act;
* annex is the act.
annex: The identifier of the annex, if any (e.g., Annex 1).
In case of annexes, both
Both the main document and its annexes have their own uniform name names
so that they can individually be referenced; referenced individually; the identifier of the
annex adds a suffix to that of the main document. In a similar way way,
the identifier of an annex of an annex adds an ending to that of the
annex which 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 syntax, and
order). For the details regarding each element, please see the Section 6. Examples (hypothetical) The
following are hypothetical examples of work identifiers are: 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, as well as law and
legislation, especially within the legal systems where cases are
identified
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.
Here below
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, 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 the German jurisdiction). jurisdictions).
In the states or organisations organizations that have multiple official languages,
a document has multiple identifiers, each of them identifiers. Each identifier is expressed in
a different official language, 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",
"urn:lex:eu:consiglio:direttiva:2004-12-07;31", etc.).
"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 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, 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; texts,
* correction of publication errors (rectification or errata
corrige);
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 such version may be expressed in more than one language, with each language-version
language version having its own specific identifier. The identifier
of a source of law expression adds such information to the work identifier,
identifier using the following main structure:
expression = version [":" language]
where:
* version is the
version: The identifier of the version of the original or amended
source of law. In general 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", "original" and is expressed in the
language of the act or version (for the details regarding this
element, please see the Section 7);
* language is the 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 example, the specification of the German language as
used in Switzerland rather than the 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.
Hypothetical
The following are hypothetical examples of document identifiers for expressions are:
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 Editorial staff who produced it, expressed according to
its the
publisher's Internet domain name. Since publishers' domain names
may vary over time, manifestations already assigned by a publisher
remain
unchanged 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 for each of them a new manifestation
with the a new domain name;
* name for each of them.
format: the 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 by with the "-" sign;
* sign.
component: possible Possible components of the expressions contained in the
manifestation. Such components are expressed by language-
dependent labels representing the whole document (in English
"all") or
"all"), the main part of the document (in English "body") "body"), or the
caption label of the component itself (e.g. (e.g., Table 1, Figure 2,
etc.);
*
etc.).
feature: other Other features of the document (e.g., anonymized decision
text).
The
Thus, the manifestation suffix thus 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
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 is are shown in
Section 8, 8 in the related part.
(examples (hypothetical):
the
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"
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
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 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")
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.
(e.g., geographic maps, photographs, etc.), etc.) or texts recorded in non-
textual formats, such as formats (e.g., image scans of documents. 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, block that
represents a logical subdivision of an act.
As regards
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 to locate it. In this case,
therefore, Therefore, it is possible either to
either extract or to point to a partition.
In a mark-up
For markup that does not fitting fit the logical structure of the text (as (like
HTML), generally only the starting point of the partition, rather
than the whole block of text or element, is identified through a
label (a (e.g., <a id=partitionID></a> tag in Html Markup Language the HTML markup language
[W3C.HTML]). In this
case therefore case, it is not only possible to extract point to a
partition but only to
point to not extract it.
Partitions should be assigned unique labels or IDs within the
including document document, and their value should be the same regardless of
document format.
For enabling
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, shared within each country or
jurisdiction,
jurisdiction for any document type
(e.g., for type. For example, in legislation, the
paragraph 2 of the article 3 might have the value "art3;par2" as the
label or ID the value "art3;par2", similarly ID; similarly, for case-law, case law, paragraph 22 of the judgment in
Case 46/76 Bauhuis v Netherlands, Netherlands might have the value "par22" as the
label or ID the value "par22"). 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 purpose, it is necessary that the
partition identifier is be transmitted to the servers (resolution and application) and therefore
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]
(e.g., to refer
For example, referring to the paragraph 3 of the article 15 of the French Act
of 15 May 2004, n. 106, the reference can be
"urn:lex:fr:etat:loi:2004-05-15;106~art15;par3").
"urn:lex:fr:etat:loi:2004-05-15;106~art15;par3".
Using a different separator ("~") from the document name, the
partition ID is not withheld by the browser but it is transmitted to the
resolution process. This 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, if the
partition syntax is compatible with the media type used, otherwise to
return partition; otherwise, the whole act.
act is returned.
When resolving to HTTP, the resolver SHALL transform the partition ID
to an appropriate internal reference (#) in on the page, page or at the
beginning if that point cannot be found. The transformation in the
URI fragment is obtained by appending to the URL 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, ID by eliminating sub-partitions that
are not addressed. If In the previous example, if only the article was
identified in the act, in the previous example it could return <URL-document>#art15 only.
It is possible to use the general syntax (with "#"); in this case case,
only the URN document component of the reference is transmitted to
the resolver, therefore resolver; therefore, the whole document will always be retrieved.
6. Specific Syntax of the Identifier at "Work" Level
6.1. The authority Authority Element
6.1.1. Indication of the Authority
The authority element of a uniform name may indicate, indicate the following in
the various cases:
* the The actual authority issuing the legal provision. More
specifically, the authority adopting the provision or enacting it; it.
* the The institution where the provision is registered, known known, and
referenced to, even if produced by others (e.g., the bills
identified through the reference to the Chamber where they are
presented);
presented).
* the The institution regulated (and referred to in citations) by the
legal provision even when this is issued by another authority
(e.g., the statute of a Body); Body).
* the The entity that proposed the legal material not yet included in
the institutional process (e.g. (e.g., a proposed bill written by a
political party).
6.1.2. Multiple Issuers
Some sources of law are enacted by a number of issuing parties (e.g.,
inter-ministerial decrees, agreements, etc.). In this case, the
authority element contains all the issuing parties (properly
separated),
separated) as follows:
authority = issuer *("+" issuer)
(e.g., "ministry.justice+ministry.finances").
This is an example: "ministry.justice+ministry.finances".
6.1.3. Indication of the Issuer
Each issuing authority is essentially represented by either an
institutional office (e.g., Prime Minister) or an institution (e.g.,
Ministry); in the last case, the authority is indicated in accordance
with the institution's hierarchical structure, from the more general to
more specific (Council, Department, etc.), ending with the relative
office (President, Director, etc.). Therefore, the structure of the
issuer is as follows:
issuer = (institution *(";" body-function)) / office
(e.g., "ministry.finances;department.revenues;manager")
This is an example: "ministry.finances;department.revenues;manager".
6.1.4. Indication of the Body
Depending on the kind of measure, the body within the issuing
authority is unambiguously determined (e.g., the Council for Regional
Acts)
Acts), and normally it is not normally indicated in the references. Just like
in practice, the indication of the enacting authority is limited to
the minimum in relation to the type of measure (e.g.,
"region.tuscany:act" and not "region.tuscany;council:act").
6.1.5. Indication of the Function
Generally, the function is indicated, sometimes instead of the body
itself:
* in In the case of political, representative representative, or elective offices
(e.g., "university.oxford;rector:decree" instead of
"university.oxford;rectorship:decree");
"university.oxford;rectorship:decree").
* when it refers When referring to a top officer in the institution (e.g., general
manager, general secretary, etc.) etc.), which is not always possible to
associate a specific internal institutional structure to (e.g.,
"national.council.research;general.manager").
It is not indicated when it clearly corresponds to the person in
charge of an institution (typically, a general director); in this
case, only the structure and not the person in charge is indicated
(e.g., "ministry.justice;department.penitentiary.administration").
The function MUST be indicated when:
* it It is not the same of as the director or the person in charge of the
structure (for example, in case of an undersecretary, a deputy director, etc.);
etc.).
* the The type of measure may be both monocratic or collegial: collegial; the
indication of the office eliminates the ambiguity.
6.1.6. Conventions for the Authority
Acts and measures bearing the same relevance as an act, issued or
enacted since the foundation of the State, have conventionally
indicated "state" (expressed in each country country's official language) as
authority;
the authority. The same convention is used for constitutions, codes
(civil, criminal, civil procedure, criminal procedure, etc) etc.), and
international treaties.
6.2. The measure Measure Element
6.2.1. Criteria for the Indication of the Type of Measure
In uniform names names, the issuing authority of a document is mandatory.
This makes it unnecessary to indicate any further qualification of
the measure (e.g., ministerial decree, directorial ordinance, etc.),
even if it is widely used. When the authority-measure combination
clearly identifies a specific document, the type of measure is not
defined through attributes referring to the enacting authority (e.g.,
"region.tuscany:act" and not "region.tuscany:regional.act").
6.2.2. Further Specification to the Type of Measure
In the measure element, it is usually sufficient to indicate the type
of a measure. As usual, references to sources of law, rather than through the formal details (date
and number), references to sources of law may be made through some of
their characteristics characteristics, such as the subject-matter subject matter covered (e.g.,
accounting regulations), nicknames referring to the promoter (e.g.,
Bolkestein directive) directive), or to the topic of the act (e.g., Bankruptcy
Law), etc.. etc. In these cases, the type of measure MAY be followed by
further specifications that are useful in referencing referencing, even if the
details are lacking:
measure = measure-type *(";" specification)
(e.g.,
These are examples: "regulations;accounting" or "act;bankruptcy"). "act;bankruptcy".
6.2.3. Aliases for Sources of Law with Different Normative References
There are legislative measures that, although unique, are usually
cited in different ways, for example through the legislative act example, introducing them into the legal
order through a legislative act (President's decree, legislative
decree, etc.) or through their legislative category (regulations,
consolidation, etc.). In order to ensure, in all the
cases, ensure the validity of the references,
references in all cases, an alias (additional (an additional URN LEX
identifier), identifier)
that takes into account the measure category, category is added to what
represents the legislative form of the same act (e.g.,
"state:decree.legislative:1992-07-24;358" and
"state:consolidation;public.contracts:1992-07-24;358").
6.2.4. Relations between Between Measure and Authority in the Aliases
The sources of law including different normative references are
usually introduced in legislation through the adoption or the issuing
of an act, which they are either included or attached to. It is,
therefore, Therefore,
it is necessary to create an alias linking the two aspects of the
same document. Specifically, the different measures can be:
* adopted/issued Adopted/issued by an authority different from the one regulated by
the provision (e.g., the statute of a Body); in Body). In this case, the
correlation is established between two uniform names names, each
featuring a completely different authority element (e.g.,
"italian.society.authors.publishers:statute" and
"ministry.cultural.activities+ministry.finances.budget.economic.
planning:decree");
planning:decree").
* issued Issued by the institution itself either because it has issuing
authority or by virtue of a proxy (e.g., a provision that refers
to the functioning of the Body itself); in itself). In this case, the two
aliases share the first part of the authority (e.g.,
"municipality.firenze:statute" and
"municipality.firenze;council:deliberation");
"municipality.firenze;council:deliberation").
* issued Issued by the same Body to regulate a particular sector of its own
competence; in
competence. In this case case, the authority element is the same
(e.g., "ministry.justice:regulation;use.information.tools.
telematic.process" and "ministry.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 of the
enactment and the identification number (inclusion in the body of
laws, register, protocol, etc.).
Some measures can have multiple dates; there dates. There are also cases in which
the number of the measure does not exist (unnumbered measures) or a
measure has multiple numbers (e.g., unified cases). For these
reasons, the set up setup of both elements (date and number) includes
multiple values.
Some institutions (e.g., the Parliaments) usually identify documents
through their period of reference (e.g., the legislature number)
rather than through a date, which would be much less meaningful and
never used in references (e.g., Senate bill S.2544 of the XIV
legislature). In these cases, the component period is used in
substitution of substitued for
the component dates.
Usually
Usually, details of a measure are not reported according to a
specific
sequence; in sequence. In accordance with the global structure of the
uniform name, which goes from the general to the specific, the sequence date-
number has the following form:
details = (dates / period) ";" numbers
(e.g., "2000-12-06;126", "14.legislature;s.2544").
The following are examples: "2000-12-06;126" and
"14.legislature;s.2544".
6.3.2. Multiple Dates
Some sources of law, even if unique, are identified by more than one
date; in
date. In this case, in the field dates all the given dates are to be reported and
indicated as follows:
dates = date *("," date)
(e.g.,
For example, the measure of the Data Protection Authority of December
30, 1999-January 13, 2000, No. 1/P/2000 has the following uniform
name:
"personal.data.protection.authority:measure:1999-12-30,2000-01-13;
1-p-2000").
personal.data.protection.authority:measure:1999-12-30,2000-01-
13;1-p-2000
As specified in Section 3.6, all the dates can have, in addition to
the ISO format, also have the date typical
of the jurisdiction. jurisdiction in addition to the ISO format.
6.3.3. Unnumbered Measures
Measures not officially numbered in the publications may have a non-
unequivocal identifier, because several measures of the same type can
exist,
exist and can be issued on the same day by the same authority. To
ensure that the uniform name is unambiguous, the numbers field MUST,
in any case, contain a discriminating element, which can be any
identifier used
internally, internally and not published, published by the authority (e.g.,
protocol).
If the authority does not have its own identifier, one identifier
MUST be created for the name system. In order to easily
differentiate it, such number is preceded by the string "lex-":
number-lex = "lex-" 1*DIGIT
(e.g., "ministry.finances:decree:1999-12-20;lex-3").
The following is an example: "ministry.finances:decree:1999-12-
20;lex-3".
It is the responsibility of the authority issuing a document to
assign a discriminating specification to it; in case of it. When there are multiple
authorities, only one of them is responsible for the assignment of
the number to the document (e.g., the proponent).
The unnumbered measures published on an official publication (e.g.,
the Official Gazette), instead of by a progressive number are recognized by the univocal identifying
label printed on the paper. paper instead of by a progressive number. Such
an identifier, even if it is unofficial but assigned to a document in
an official publication, is to be preferred because it has the clear
advantage to be of being public and is therefore easier to be found. find.
6.3.4. Multiple Numbers
Some legal documents (e.g., bills), even if unique, are identified by
a set of numbers (e.g., the unification of cases or bills). In this
case, in the numbers field, all the identifiers are reported,
according to the following structure:
numbers = document-id *("," document-id)
(e.g., "2000-06-12;c-10-97,c-11-97,c-12-97").
The following is an example: "2000-06-12;c-10-97,c-11-97,c-12-97".
The characters which that are not allowed (e.g., "/") or reserved (e.g.,
":"), including the comma, cannot exist inside the document-id, document-id and
therefore MUST be turned into "-".
Where
When special characters contained in the number of the act are
distinctive of the act itself (e.g. (e.g., bill n. 123-bis (removal of 123)
and n. 123/bis (return of 123)) and would disappear with the
conversion to "-", a further ending must be added, allowing added to distinguish the
acts (e.g. (e.g., bill n.123-bis-removal and 123-bis-
return). 123-bis-return).
6.4. The annex Annex Element
6.4.1. Formal Annexes
Although annexes are an integral part of the a legal document, they may
be referred to and undergo amendments separately from the act to
which they are annexed. It is, therefore, Therefore, it is necessary that both the
main document as well as each formal individual annex is
unequivocally identified.
Formal annexes may be registered as separate parts or together with a
legal provision; they may also or may not be autonomous in nature or not. nature. In any
case, they MUST be given a uniform name, which name that includes the uniform
name of the source of law to which they are attached, attached and a suffix which
that identifies the annex itself.
The suffix of formal annexes includes the official heading of the
annex and, possibly, further specifications (e.g., the title) which that
will facilitate the retrieval of the annex in case the identifier is
missing:
annex = annex-id *(";" specification)
(e.g., "region.sicily;council:deliberation:1998-02-12;14:annex.a;
borders.park").
The following is an example:
region.sicily;council:deliberation:1998-02-12;14:annex.a;
borders.park
The characters which that are not allowed (e.g. (e.g., "/") or which that are reserved
(e.g.
(e.g., ":") must not be featured in the annex-id and therefore MUST
be turned into ".".
6.4.2. Annexes of Annexes
When there are annexes to an annex, their corresponding identifiers
are created by adding to the identifier of the original annex those
of the annexes that are connected with it (that is, attached to it)
(e.g., it).
For example, Table 1 attached to the Annex A of the preceding legal
act has the following uniform name:
"region.sicily;council:deliberation:1998-02-12;14:annex.a;
borders.park:table.1;municipality.territories").
region.sicily;council:deliberation:1998-02-12;14:annex.a;
borders.park:table.1;municipality.territories
7. Specific Syntax of the Version Element of the "Expression"
7.1. The version Version Element
7.1.1. Different Versions of a Legislative Document
The creation of an updated text of a document may have one of the
following forms:
*
"multi-version": when specific mark-ups which Specific markups that identify the modified parts
of a document (added, substituted substituted, or deleted parts) and their
related periods of effectiveness are indicated inside
one a single
object (e.g., an xml XML file). Such a document will be able, in a
dynamic way, to appear in different forms according to the
requested date of effectiveness. In this document type,
usually a set of
metadata usually contains the lifecycle 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;
* portion.
"single-version": when, on the contrary, a A new and distinct object is created for each
amendment to the text at a given time. Each object is, therefore,
characterized by its own period of validity. In any case case, 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 which that can be therefore 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] [RFC8288], the following
relations are useful:
*
current (or last or last-version): in-force version
*
self: this version
*
next: next version
*
previous: previous version
*
first: original version
It is RECOMMENDED that these relations are be inserted in the header of
each version (if "single-version") or associated to each entry
containing a single URN (if "multi-version").
7.1.2. Identification of the Version
In order to identify the different time versions of the same act, a
specific suffix has to be added to the uniform name of the original document has to be added a specific
suffix.
document.
Such a suffix identifies each version of a legal provision and
includes, first and foremost, one of the following elements:
* the The issuing date of the last amending measure taken into account; account.
* the The date in which that the communication of the rectification or of the errata corrige, is published;
corrige was published.
* a A specification which 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 is possible to add further specifications that will distinguish
each of the different versions of the text to guarantee identifier
unequivocalness. For example with regard to changes of the in-force
or effectiveness of any partition or portion of the text itself
(e.g., when the amendments introduced by an act are applied at
different times) or different events occurring on the same date.
version = (amendment-date / specification)
*(";" (event-date / event))
where:
* amendment-date contains
amendment-date: Contains the issuing date of the last considered
amendment or of the last communication of amendment. In case If the
original text introduces differentiated periods in which an act is
effective and the information system produces one version for each
of them, such element contains the string "original" expressed in
the language of the act or version;
* specification contains version.
specification: Contains any information that is useful to identify
the version unambiguously and univocally the version;
* event-date contains univocally.
event-date: Contains the date in which a version is put into force,
is effective effective, or is published;
* event is a published.
event: A name assigned to the event producing a further version
(e.g., amendment, decision, etc.).
The issuing date of an amending act was chosen as the identifier of a
version because it can be obtained from the heading (formal data)
(e.g., data).
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", 51" without any indication of its actual entry into force. The
same uniform name with the additional ending ";1999-01-01" indicates
the in-force or effective version starting in on a different date (from 1/1/99).
(1/1/99).
For a full compatibility, every updating update of a text or of the effectiveness
of a "multi-version" document implies the creation of a new uniform
name, even if the object remains only one, containing the identifier
of the virtually generated version, exactly as in the case of a
"single-version" document. A specific meta-data Specific metadata will associate every
uniform name with the period of time during which such a name name,
together with its corresponding text text, is to be considered valid
(e.g., the multi-version "multi-version" document containing the "R.D. of 01/30/1941,
no. 12", updated by the amendments introduced by the "D.Lgs. of
02/19/1998, no. 51", contains the name of the original version
"state:royal.decree:1941-01-30;12" as well as the name of the updated
version "state:royal.decree:1941-01-30;12@1998-02-19").
Please note
Note that in case of if there are attachments or annexes, the creation of a new
version (even in the case of only one component) would imply the
creation of a new uniform name for all the connected objects in order
to guarantee their alignment (i.e., the main document, the
attachments attachments,
and annexes).
As specified in Section 3.6, all the dates can have, in addition to
the ISO format, also have the date typical
of the jurisdiction. jurisdiction in addition to the date in ISO format.
8. Summary of the Syntax of the Uniform Names of the "lex" Namespace
;-------------------------------------------------------------------
; Structure of a Uniform Resource Name (URN) of the "lex" namespace
; - NID-lex = namespace
; - NSS-lex = specific name
;-------------------------------------------------------------------
URN-lex = "urn:" NID-lex ":" NSS-lex
NID-lex = "lex"
;-------------------------------------------------------------------
; Structure of a "lex" specific name
;-------------------------------------------------------------------
NSS-lex = jurisdiction ":" local-name
;-------------------------------------------------------------------
; Structure of the jurisdiction element
;-------------------------------------------------------------------
jurisdiction = jurisdiction-code *(";" jurisdiction-unit)
jurisdiction-code = 2*alf-dot
jurisdiction-unit = alf-dot
;-------------------------------------------------------------------
; Structure of the local-name element
;-------------------------------------------------------------------
local-name = work ["@" expression] ["$" manifestation]
;-------------------------------------------------------------------
; Structure of the work element
;-------------------------------------------------------------------
work = authority ":" measure ":" details *(":" annex)
;-------------------------------------------------------------------
; Structure of the authority element
;-------------------------------------------------------------------
authority = issuer *("+" issuer)
issuer = (institution *(";" body-function)) / office
institution = alf-dot
body-function = alf-dot
office = alf-dot
;-------------------------------------------------------------------
; Structure of the measure element
;-------------------------------------------------------------------
measure = measure-type *(";" specification)
measure-type = alf-dot
specification = alf-dot
;-------------------------------------------------------------------
; Structure of the details element
;-------------------------------------------------------------------
details = (dates / period) ";" numbers
dates = date *("," date)
period = alf-dot
numbers = (document-id *("," document-id)) / number-lex
document-id = alf-dot-oth
number-lex = "lex-" 1*DIGIT
;-------------------------------------------------------------------
; Structure of the annex element
;-------------------------------------------------------------------
annex = annex-id *(";" specification)
annex-id = alf-dot
;-------------------------------------------------------------------
; Structure of the expression element
;-------------------------------------------------------------------
expression = version [":" language]
;-------------------------------------------------------------------
; Structure of the version element
;-------------------------------------------------------------------
version = (amendment-date / specification)
*(";" (event-date / event))
amendment-date = date
event-date = date
event = alf-dot
;-------------------------------------------------------------------
; Structure of the language element
;-------------------------------------------------------------------
language = 2*3alfa *["-" extlang] / 4*8alfa
extlang = 3alfa *2("-" 3alfa)
;-------------------------------------------------------------------
; Structure of the manifestation element
;-------------------------------------------------------------------
manifestation = format ":" editor
[":" component [":" feature]]
format = mime *(";" specification)
mime = alf-dot-hyp
editor = publisher *(";" specification)
publisher = alf-dot-hyp
component = part *(";" specification)
part = alf-dot-hyp
feature = attribute *(";" specification)
attribute = alf-dot-hyp
;-------------------------------------------------------------------
; Structure of the date
;-------------------------------------------------------------------
date = date-iso ["|" date-loc]
date-iso = year "-" month "-" day
year = 4DIGIT
month = 2DIGIT
day = 2DIGIT
date-loc = *(alfadot / other)
;-------------------------------------------------------------------
; Allowed, reserved 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. The Procedure of Uniform Names Assignment
9.1. Specifying the jurisdiction Jurisdiction Element of the LEX Identifier
Under the "lex" namespace, each country or international organization
is assigned with a jurisdiction code, which characterizes the URNs of the
source of law of that country or jurisdiction. This code is assigned
according to ccTLD (as well as TLDN (Top Level (Top-Level Domain Name) or DN
(Domain Name) for the organizations) representation representation, and it is the value
of the jurisdiction-code element, which preserves cross-
country cross-country
uniqueness of the identifiers.
9.2. Jurisdictional Registrar for Names Assignment
Any country or jurisdiction, who jurisdiction that intends to adopt this schema, schema MUST
identify a Jurisdictional Registrar, an organization which 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
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
state, a jurisdiction-
unit jurisdiction-unit corresponding to the name of each member
state
(e.g. (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 country, the Jurisdictional Registrar shares and defines the
assignment of the primary elements (issuing authority and type of
legal measure) of the local names considering the characteristics of
its own state or institution organization.
Such a
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, to take make decisions upon
normalizations and finally to
about normalizations, solve and avoid possible name
collisions as well as to 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 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 the 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, and each 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, 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,
constructed and MUST update its registries and make accessible its registries. them accessible.
Any enacting authority is responsible to define for defining formal parameters
to guarantee local name uniqueness by attributing, if necessary, a
conventional internal number, which, which when combined with the other local-
name
local-name components (authority, measure 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, the CNR is responsible of for maintaining the uniqueness of
the jurisdiction element; given 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 associated code is expected to continue indefinitely, the URN
also persists indefinitely.
The rules for the construction of the name are conceived to delegate
the responsibility of their uniqueness to a set of authorities which that
is identified within each country or organization.
Therefore, each authority is responsible for assigning URNs which 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 the national scope down to the very local, local scope, MUST equally take
responsibility for the persistence of identifiers within their scope.
10. Recommendations for the Resolution Process
10.1. The General Architecture of the System
The task of the resolution service is that of associating to associate a LEX identifier
with a specific document address on the Internet. By 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 (Domain Name System) and a series of
resolution services from URNs to URLs, each competent within a
specific domain of the namespace.
The client retrieves the document associated with this URN using the
procedure described in [RFC3404], which starts with a DNS NAPTR
query.
A resolution service can delegate the resolution and management of
hierarchically-dependent
hierarchically dependent portions of the name. Delegation of this
responsibility will not be unreasonably withheld provided that the
processes for their resolution and management are robust and are
followed.
For the "lex" namespace, CNR will 1) maintain in the lex-
nameserver.nic.it (see Section 12) the root zone of the
chain
resolution (equivalent resolution, equivalent to "lex.urn.arpa", see [RFC3405]) and, "lex.urn.arpa" (see [RFC3405]), in
correspondence with
the adhesion lex-nameserver.nic.it (see Section 2.2) of a new country
(e.g., "br") or organization, will 12) and 2) update the DNS
information with a new record to delegate the relative resolution. 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 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 %-encoded 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 a
software to query the knowledge base itself. base.
10.2. Catalogues for Resolution
Incompleteness and inaccuracy are rather frequent in legal citations,
and citations;
thus, incomplete or inaccurate uniform names of the referred document
are thus likely to be built from textual references (this is even more
frequent if they are created automatically through a specific
parser). For this reason, the implementation of a catalogue, based
on a relational-database, relational database, is suggested, as it will lead to a higher
flexibility in the resolution process.
In addition addition, the catalogue must manage the aliases, the various
versions and languages of the same source of law as well as law, and the related
manifestations.
It is suggested that each enacting authority implements implement its own
catalogue, assigning a corresponding unambiguous uniform name to each
resource.
10.3. Suggested Resolver Behaviour Behavior
First, the resolver SHOULD separate the part corresponding to the
partition ID, through the "~" separator, ID from the document name. 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 function,
authorities and types of measure registers are useful.
The resolver SHOULD then query the catalogue searching for the URN
which
that corresponds exactly to the given one (normalized if necessary).
Since the names coming from the references may be inaccurate or
incomplete, an iterative, 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 to return partition;
otherwise, the entire document. document is returned.
Lacking more specific indications, the resolver SHOULD select the
best (most recent) version of the requested source of law, 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 and/
or manifestations components (e.g. (e.g., date, language, format, etc.).
Finally, the resolver SHOULD append to URLs the "#" character followed by the
partition ID, transforming it in a ID to URLs, to create URI fragment fragments for browser pointing.
11. Security Considerations
Security considerations are those normally associated with the use
and resolution URNs in general. Additional security considerations
concerning the authenticity of a document do not pertain to the LEX
specifications, but they pertain to security and trust issues which that
can be addressed with other means, like digital signature, signatures, data
encryption, etc.
12. IANA Considerations
IANA has already registered the "lex" namespace, according to the
template at section 2. Registration has been accomplished as namespace in the
Formal "Formal URN Namespace Namespaces"
registry described by [RFC8141].
In addition, to activate a distributed resolution system, the one-off
registration of IANA has
registered the following NAPTR record is requested in the URN.ARPA domain:
lex.urn.arpa.
IN NAPTR 100 10 "" "" "" lex-nameserver.nic.it.
where
Note that lex-nameserver.nic.it indicates the server of CNR server (see section
Section 2.2) that is responsible for the resolution of the "lex"
namespace at the time of this writing.
13. Acknowledgements
The authors of this document wish to thank all the supporters for
giving suggestions and comments.
They are also grateful to the Legislative XML community [SART] for
the interesting discussions on this topic References
13.1. Normative References
[ISO.8601.1988]
ISO, "Data elements and to the Working Group
"Identification of the legal resources through URNs" of Italian
NormeInRete project for the provided guidance [SPIN].
The authors owe a debt of gratitude to Tom Bruce, former director of
the Legal interchange formats - Information Institute of the Cornell University Law School,
for his contribution in revising this document and sharing fruitful
discussions which greatly improved the final draft. The authors wish
to specially thank Marc van Opijnen (Dutch Ministry of Security and
Justice) for his valuable comments on LEX specifications which
contributed to improve the final result, as well as for the common
work aimed to harmonize ECLI and LEX specifications. Thanks also to
Joao Alberto de Oliveira Lima, legislative system analyst of the
Brazilian Federal Senate, and to Attila Torcsvari, information
management consultant, for their detailed comments on the first
drafts of this document, which provided significant hints to the
final version of the standard, and to Robert Richards
interchange - Representation of the Legal
Information Institute (Cornell University Law School), promoter dates and
maintainer of the Legal Informatics Research social network, as well
as to the members of this network, for their valuable comments on
this proposal.
Finally, many thanks go to Loriana Serrotti who significantly
contributed to the first drafting of this document.
14. References
14.1. Normative References times",
ISO 8601:1988, June 1988.
[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>.
[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>.
[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>.
[ISO.8601.1988]
International Organization for Standardization, "Data
elements and interchange formats - Information interchange
- Representation of dates and times", ISO Standard 8601,
June 1988.
[W3C.HTML] "HTML", W3C REC html, HTML, W3C html, HTML,
<https://www.w3.org/TR/html/>.
14.2.
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", n.d., February 2009,
<https://www.ifla.org/files/assets/cataloguing/frbr/
frbr_2008.pdf>.
[HCPIL] The European Commission, "The Hague Conference on Private
International Law "Access to Foreign Law in Civil
and Commercial Matters. Conclusions and Recommendations"", Matters", The Hague Conference on Private
International Law, February 2012, <https://assets.hcch.net/docs/b093f152-a4b3-4530-
949e-65c1bfc9cda1.pdf>.
<https://assets.hcch.net/docs/b093f152-a4b3-4530-949e-
65c1bfc9cda1.pdf>.
[ISBD] The Standing Committee of the IFLA Cataloguing Section
Berlin/Munich\:
Berlin/Munich: De Gruyter Saur, "International "ISBD: International
Standard Bibliographic Description - – Consolidated Edition.",
Edition", ISBN 978-3-11-026379-4, 2011.
[ISO3166-1]
International Organization for Standardization,
[ISO.3166-1]
ISO, "Codes for the representation of names of countries
and their subdivisions -- - Part 1: Country codes".
[LVI] Peruginelli, G., Ed. and M. Ragona, Ed., "Law via the
Internet. Free Access, Quality of Information,
Effectiveness of Rights", ISBN 9788883980589, 2008. April 2009.
[SART] Sartor, G., Palmirani, M., Francesconi, E., and M.
Biasiotti, "Legislative XML for the Semantic Web. Web:
Principles, Models, Standards for Document Management,
Law, Governance and Technology Series", Management",
ISBN 978-94-007-1887-6, 2011.
[SPIN] Spinosa, P., "The Assignment of Uniform Names to Italian
Legal Documents, URN-NIR 1.4", ITTIG technical Report n.
8/2010.,
8/2010, June 2020.
[W3C.rdf-schema]
[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.com
Enrico Franceseconi
National Research Council of Italy (CNR)
Via de' Barucci, 20
50127 Firenze
Italy
Phone: +39 055 43995
Email: enrico.francesconi@cnr.it
Caterina Lupo
Via San Fabiano, 25
117 Roma
Italy
Phone: +39 3382632348
Email: caterina.lupo@gmail.com