rfc9676.original | rfc9676.txt | |||
---|---|---|---|---|
Network Working Group P. Spinosa | Independent Submission P. Spinosa | |||
Internet-Draft | Request for Comments: 9676 | |||
Intended status: Informational E. Francesconi | Category: Informational E. Francesconi | |||
Expires: 18 February 2025 National Research Council of Italy (CNR) | ISSN: 2070-1721 National Research Council of Italy (CNR) | |||
C. Lupo | C. Lupo | |||
17 August 2024 | November 2024 | |||
A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) | A Uniform Resource Name (URN) Namespace for Sources of Law (LEX) | |||
draft-spinosa-urn-lex-24 | ||||
Abstract | Abstract | |||
This document describes a Uniform Resource Name (URN) Namespace | This document describes a Uniform Resource Name (URN) namespace | |||
Identifier for identifying, naming, assigning, and managing | identifier for identifying, naming, assigning, and managing | |||
persistent resources in the legal domain. This specification is | persistent resources in the legal domain. This specification allows | |||
published to allow adoption of a common convention by multiple | adoption of a common convention by multiple jurisdictions to | |||
jurisdictions to facilitate ease of reference and access to resources | facilitate ease of reference and access to resources in the legal | |||
in the legal domain. | domain. | |||
This specification is an independent submission to the RFC series. | ||||
It is not a standard, and does not have the consensus of the IETF. | ||||
Status of This Memo | This specification is an Independent Submission to the RFC Series. | |||
It is not a standard and does not have the consensus of the IETF. | ||||
This Internet-Draft is submitted in full conformance with the | Status of This Memo | |||
provisions of BCP 78 and BCP 79. | ||||
Internet-Drafts are working documents of the Internet Engineering | This document is not an Internet Standards Track specification; it is | |||
Task Force (IETF). Note that other groups may also distribute | published for informational purposes. | |||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This is a contribution to the RFC Series, independently of any other | |||
and may be updated, replaced, or obsoleted by other documents at any | RFC stream. The RFC Editor has chosen to publish this document at | |||
time. It is inappropriate to use Internet-Drafts as reference | its discretion and makes no statement about its value for | |||
material or to cite them other than as "work in progress." | implementation or deployment. Documents approved for publication by | |||
the RFC Editor are not candidates for any level of Internet Standard; | ||||
see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 18 February 2025. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9676. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2024 IETF Trust and the persons identified as the | Copyright (c) 2024 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. | carefully, as they describe your rights and restrictions with respect | |||
to this document. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction | |||
1.1. The Purpose of Namespace "lex" . . . . . . . . . . . . . 4 | 1.1. Purpose of the "lex" Namespace | |||
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Background | |||
1.3. General Characteristics of the System . . . . . . . . . . 6 | 1.3. General Characteristics of the System | |||
1.4. Linking a LEX Name to a Document . . . . . . . . . . . . 8 | 1.4. Linking a LEX Name to a Document | |||
1.5. Use of LEX Names in References . . . . . . . . . . . . . 8 | 1.5. Use of LEX Names in References | |||
1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 | 1.6. Definitions | |||
1.7. Terminology . . . . . . . . . . . . . . . . . . . . . . . 9 | 1.7. Terminology | |||
1.8. Syntax Used in this Document . . . . . . . . . . . . . . 9 | 1.8. Syntax Used in This Document | |||
1.9. Namespace Registration . . . . . . . . . . . . . . . . . 9 | 1.9. Namespace Registration | |||
2. Registration of LEX . . . . . . . . . . . . . . . . . . . . . 9 | 2. Registration of LEX | |||
2.1. Identifier Structure . . . . . . . . . . . . . . . . . . 9 | 2.1. Identifier Structure | |||
2.2. Jurisdiction-code Register . . . . . . . . . . . . . . . 11 | 2.2. Jurisdiction-Code Register | |||
2.3. Conformance with URN Syntax . . . . . . . . . . . . . . . 13 | 2.3. Conformance with URN Syntax | |||
2.4. Validation Mechanism . . . . . . . . . . . . . . . . . . 13 | 2.4. Validation Mechanism | |||
2.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 2.5. Scope | |||
3. General Syntax and Features of the LEX Identifier . . . . . . 13 | 3. General Syntax and Features of the LEX Identifier | |||
3.1. Allowed and Not Allowed Characters . . . . . . . . . . . 13 | 3.1. Allowed and Not Allowed Characters | |||
3.2. Reserved Characters . . . . . . . . . . . . . . . . . . . 14 | 3.2. Reserved Characters | |||
3.3. Case Sensitivity . . . . . . . . . . . . . . . . . . . . 14 | 3.3. Case Sensitivity | |||
3.4. Unicode Characters outside the ASCII Range . . . . . . . 14 | 3.4. Unicode Characters Outside the ASCII Range | |||
3.5. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 16 | 3.5. Abbreviations | |||
3.6. Date Format . . . . . . . . . . . . . . . . . . . . . . . 17 | 3.6. Date Format | |||
4. Specific Syntax and Features of the LEX Identifier . . . . . 17 | 4. Specific Syntax and Features of the LEX Identifier | |||
4.1. Spaces, Connectives and Punctuation Marks . . . . . . . . 18 | 4.1. Spaces, Connectives, and Punctuation Marks | |||
4.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 18 | 4.2. Acronyms | |||
4.3. Ordinal Numbers . . . . . . . . . . . . . . . . . . . . . 18 | 4.3. Ordinal Numbers | |||
5. Creation of the Source of Law LEX Identifier - Baseline | 5. Creation of the Source of Law LEX Identifier: Baseline | |||
structure . . . . . . . . . . . . . . . . . . . . . . . . 18 | Structure | |||
5.1. Basic Principles . . . . . . . . . . . . . . . . . . . . 18 | 5.1. Basic Principles | |||
5.2. Model of Sources of Law Representation . . . . . . . . . 19 | 5.2. Model of Sources of Law Representation | |||
5.3. The Structure of the Local Name . . . . . . . . . . . . . 20 | 5.3. Structure of the Local Name | |||
5.4. Structure of the Document Identifier at "Work" Level . . 21 | 5.4. Structure of the Document Identifier at "Work" Level | |||
5.5. Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 5.5. Aliases | |||
5.6. Structure of the Document Identifier at "Expression" | 5.6. Structure of the Document Identifier at "Expression" Level | |||
Level . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
5.7. Structure of the Document Identifier at "Manifestation" | 5.7. Structure of the Document Identifier at "Manifestation" | |||
Level . . . . . . . . . . . . . . . . . . . . . . . . . . 24 | Level | |||
5.8. Sources of Law References . . . . . . . . . . . . . . . . 25 | 5.8. Sources of Law References | |||
6. Specific Syntax of the Identifier at "Work" Level . . . . . . 27 | 6. Specific Syntax of the Identifier at "Work" Level | |||
6.1. The authority Element . . . . . . . . . . . . . . . . . . 27 | 6.1. The Authority Element | |||
6.1.1. Indication of the Authority . . . . . . . . . . . . . 27 | 6.1.1. Indication of the Authority | |||
6.1.2. Multiple Issuers . . . . . . . . . . . . . . . . . . 28 | 6.1.2. Multiple Issuers | |||
6.1.3. Indication of the Issuer . . . . . . . . . . . . . . 28 | 6.1.3. Indication of the Issuer | |||
6.1.4. Indication of the Body . . . . . . . . . . . . . . . 28 | 6.1.4. Indication of the Body | |||
6.1.5. Indication of the Function . . . . . . . . . . . . . 28 | 6.1.5. Indication of the Function | |||
6.1.6. Conventions for the Authority . . . . . . . . . . . . 29 | 6.1.6. Conventions for the Authority | |||
6.2. The measure Element . . . . . . . . . . . . . . . . . . . 29 | 6.2. The Measure Element | |||
6.2.1. Criteria for the Indication of the Type of Measure . 29 | 6.2.1. Criteria for the Indication of the Type of Measure | |||
6.2.2. Further Specification to the Type of Measure . . . . 29 | 6.2.2. Further Specification to the Type of Measure | |||
6.2.3. Aliases for Sources of Law with Different Normative | 6.2.3. Aliases for Sources of Law with Different Normative | |||
References . . . . . . . . . . . . . . . . . . . . . 30 | References | |||
6.2.4. Relations between Measure and Authority in the | 6.2.4. Relations Between Measure and Authority in the Aliases | |||
Aliases . . . . . . . . . . . . . . . . . . . . . . . 30 | 6.3. The Details Element | |||
6.3. The Details Element . . . . . . . . . . . . . . . . . . . 30 | 6.3.1. Indication of the Details | |||
6.3.1. Indication of the Details . . . . . . . . . . . . . . 31 | 6.3.2. Multiple Dates | |||
6.3.2. Multiple Dates . . . . . . . . . . . . . . . . . . . 31 | 6.3.3. Unnumbered Measures | |||
6.3.3. Unnumbered Measures . . . . . . . . . . . . . . . . . 32 | 6.3.4. Multiple Numbers | |||
6.3.4. Multiple Numbers . . . . . . . . . . . . . . . . . . 32 | 6.4. The Annex Element | |||
6.4. The annex Element . . . . . . . . . . . . . . . . . . . . 33 | 6.4.1. Formal Annexes | |||
6.4.1. Formal Annexes . . . . . . . . . . . . . . . . . . . 33 | 6.4.2. Annexes of Annexes | |||
6.4.2. Annexes of Annexes . . . . . . . . . . . . . . . . . 33 | 7. Specific Syntax of the Version Element of the "Expression" | |||
7. Specific Syntax of the Version Element of the "Expression" . 34 | 7.1. The Version Element | |||
7.1. The version Element . . . . . . . . . . . . . . . . . . . 34 | 7.1.1. Different Versions of a Legislative Document | |||
7.1.1. Different Versions of a Legislative Document . . . . 34 | 7.1.2. Identification of the Version | |||
7.1.2. Identification of the Version . . . . . . . . . . . . 35 | ||||
8. Summary of the Syntax of the Uniform Names of the "lex" | 8. Summary of the Syntax of the Uniform Names of the "lex" | |||
Namespace . . . . . . . . . . . . . . . . . . . . . . . . 36 | Namespace | |||
9. The Procedure of Uniform Names Assignment . . . . . . . . . . 40 | 9. Procedure of Uniform Names Assignment | |||
9.1. Specifying the jurisdiction Element of the LEX | 9.1. Specifying the Jurisdiction Element of the LEX Identifier | |||
Identifier . . . . . . . . . . . . . . . . . . . . . . . 40 | 9.2. Jurisdictional Registrar for Names Assignment | |||
9.2. Jurisdictional Registrar for Names Assignment . . . . . . 40 | 9.3. Identifier Uniqueness | |||
9.3. Identifier Uniqueness . . . . . . . . . . . . . . . . . . 41 | 9.4. Identifier Persistence Considerations | |||
9.4. Identifier Persistence Considerations . . . . . . . . . . 42 | 10. Recommendations for the Resolution Process | |||
10. Recommendations for the Resolution Process . . . . . . . . . 42 | 10.1. General Architecture of the System | |||
10.1. The General Architecture of the System . . . . . . . . . 43 | 10.2. Catalogues for Resolution | |||
10.2. Catalogues for Resolution . . . . . . . . . . . . . . . 44 | 10.3. Suggested Resolver Behavior | |||
10.3. Suggested Resolver Behaviour . . . . . . . . . . . . . . 44 | 11. Security Considerations | |||
11. Security Considerations . . . . . . . . . . . . . . . . . . . 45 | 12. IANA Considerations | |||
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 | 13. References | |||
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 | 13.1. Normative References | |||
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 | 13.2. Informative References | |||
14.1. Normative References . . . . . . . . . . . . . . . . . . 46 | Acknowledgements | |||
14.2. Informative References . . . . . . . . . . . . . . . . . 48 | Authors' Addresses | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||
1. Introduction | 1. Introduction | |||
1.1. The Purpose of Namespace "lex" | ||||
1.1. Purpose of the "lex" Namespace | ||||
The purpose of the "lex" namespace is to assign a unique identifier | 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 | in a well-defined format to documents that are sources of law. In | |||
this context, "sources of law" include any legal document within the | this context, "sources of law" include any legal document within the | |||
domain of legislation, case law and administrative acts or | domain of legislation, case law, administrative acts, or regulations. | |||
regulations. Potential sources of law (acts under the process of law | Potential sources of law (acts under the process of law formation, | |||
formation, as bills) are included as well. "Legal doctrine", that is | such as bills) are included as well. "Legal doctrine", that is, the | |||
the body of knowledge and theoretical speculation typical of legal | body of knowledge and theoretical speculation typical of legal | |||
scholars (e.g. commentary on judgment, | scholars (e.g., commentary on judgment, jurisprudence review, | |||
jurisprudence review, commentary on legislation, encyclopedic | commentary on legislation, encyclopedic entries, monographs, articles | |||
entries, monographs, articles in magazines, manuals, etc.) is | in magazines, manuals, etc.) is explicitly not covered. | |||
explicitly not covered. | ||||
The identifier is conceived so that its construction depends only on | The identifier is conceived so that its construction depends only on | |||
the content of the document itself and not its on-line availability, | the content of the document itself and not its online availability, | |||
its physical location, and access mode. The identifier itself is | physical location, and access mode. The identifier itself is | |||
assigned by the jurisdiction of the identified document. Even a | assigned by the jurisdiction of the identified document. A document | |||
document that is not available online may, nevertheless, have a LEX | that is not available online may, nevertheless, have a LEX URN | |||
URN identifier. | identifier. | |||
The lex URN may be used as a way to represent references (and more | 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 | generally, any type of relation) among various sources of law. In an | |||
on-line environment with resources distributed among different web | online environment with resources distributed among different web | |||
publishers, lex URNs allow a simplified global interconnection of | publishers, lex URNs allow a simplified global interconnection of | |||
legal documents by means of automated resoluton. LEX URNs consist of | legal documents by means of automated resolution. LEX URNs consist | |||
persistent and location-independent identifiers and are particularly | of persistent and location-independent identifiers and are | |||
useful when they can be mapped into or associated with locators such | particularly useful when they can be mapped into or associated with | |||
as HTTP URLs. Moreover, LEX URNs details can be used as a reference | locators such as HTTP URLs. Moreover, LEX URN details can be used as | |||
to create HTTP-based persistent and location-independent identifiers | a reference to create persistent and location-independent identifiers | |||
[RFC3986]. | that are HTTP-based [RFC3986]. | |||
1.2. Background | 1.2. Background | |||
This specification of a unique identifier for legal documents follows | This specification of a unique identifier for legal documents follows | |||
a number of initiatives in the field of legal document management. | a number of initiatives in the field of legal document management. | |||
Since 2001 the Italian Government, through the National Center for | Since 2001, the Italian Government promoted the NormeInRete project | |||
Information Technology in the Public Administration, the Ministry of | through the National Center for Information Technology in the Public | |||
Justice and CNR (the National Research Council of Italy) promoted the | Administration, the Ministry of Justice, and the National Research | |||
NormeInRete project. It was aimed at introducing standards for | Council of Italy (CNR). The NormeInRete project was aimed at | |||
sources of law description and identification using XML and URN | introducing standards for describing and identifying sources of law | |||
techniques. | using XML and URN techniques. | |||
Other national initiatives in Europe introduced standards for the | Other national initiatives in Europe introduced standards for the | |||
description of legal sources [FRAN]. Collaborations between | description of legal sources [FRAN]. Collaborations between | |||
government, national research institutes, and universities, have | government, national research institutes, and universities have | |||
defined national XML standards for legal document management, as well | defined national XML standards for legal document management, as well | |||
as schemes for legal document identification. Outside of Europe, | as schemes for legal document identification. Outside of Europe, | |||
similar initiatives have addressed similar problems [FRAN]. Several | similar initiatives have addressed similar problems [FRAN]. Several | |||
of these identifiers are based on a URN schema. | of these identifiers are based on a URN schema. | |||
In today's information society the processes of political, social and | In today's information society, the processes of political, social, | |||
economic integration of European Union member states as well as the | and economic integration of European Union (EU) member states, as | |||
increasing integration of the world-wide legal and economic processes | well as the increasing integration of the worldwide legal and | |||
are causing a growing interest in exchanging legal information | economic processes, are causing a growing interest in the exchange of | |||
knowledge at national and trans-national levels. The growing desire | legal information knowledge at national and transnational levels. | |||
for improved quality and accessibility of legal information amplifies | The growing desire for improved quality and accessibility of legal | |||
the need for interoperability among legal information systems across | information amplifies the need for interoperability among legal | |||
national boundaries. A common well-defined schema used to identify | information systems across national boundaries. A common, well- | |||
sources of law at international level is an essential prerequisite | defined schema used to identify sources of law at an international | |||
for interoperability. | level is an essential prerequisite for interoperability. | |||
Interest groups within several countries have already expressed their | Interest groups within several countries have already expressed their | |||
intention to adopt a shared solution based on a URN technique. | intention to adopt a shared solution based on a URN technique. In | |||
The need for a unique identifier of sources of law in different EU | several conferences (such as [LVI]), representatives of the | |||
Member States, based on open standards and able to provide advanced | Publications Office of the European Union (OP) have expressed the | |||
modalities of document hyper-linking, has been expressed in several | need for a unique identifier for sources of law, based on open | |||
conferences (as [LVI]) by representatives of the Publications Office | standards and able to provide advanced modalities of document | |||
of the European Union (OP), with the aim of promoting | hyperlinking, with the aim of promoting interoperability among | |||
interoperability among national and European institution information | national and European institution information systems. Similar | |||
systems. Similar concerns have been raised by international groups | concerns have been raised by international groups concerned with free | |||
concerned with free access to legal information, and the Permanent | access to legal information, and the Permanent Bureau of the Hague | |||
Bureau of the Hague Conference on Private International Law [HCPIL] | Conference on Private International Law [HCPIL] encourages State | |||
that encourage State Parties to "adopt neutral methods of citation of | Parties to "adopt neutral methods of citation of their legal | |||
their legal materials, including methods that are medium-neutral, | materials, including methods that are medium-neutral, provider- | |||
provider-neutral and internationally consistent.". In a similar | neutral and internationally consistent". In a similar direction, the | |||
direction the CEN Metalex initiative is moving, at European level, | CEN Metalex initiative is moving, at the European level, towards the | |||
towards the definition of a standard interchange format for sources | definition of a standard interchange format for sources of law, | |||
of law, including recommendations for defining naming conventions to | including recommendations for defining naming conventions for them. | |||
them. | ||||
The need of unique identifiers for sources of law is of particular | Additionally, the need for unique identifiers for sources of law is | |||
interest also in the domain of case law. This is acutely felt within | of particular interest in the domain of case law. This is acutely | |||
both common law systems, where cases are the main law sources, and | felt within both common law systems, where cases are the main law | |||
civil law systems, in order to provide an integrated access to cases | sources, and civil law systems, in order to provide an integrated | |||
and legislation, as well as to track the relationships between them. | access to cases and legislation, as well as to track the | |||
This domain is characterized by a high degree of fragmentation in | relationships between them. This domain is characterized by a high | |||
case law information systems, which usually lack interoperability. | degree of fragmentation in case law information systems, which | |||
usually lack interoperability. | ||||
In the European Union, the community institutions have stressed the | In the European Union, the community institutions have stressed the | |||
need for citizens, businesses, lawyers, prosecutors and judges to | need for citizens, businesses, lawyers, prosecutors, and judges to | |||
become more aware not only of (directly applicable) EU law, but also | become more aware of (directly applicable) EU laws and also the | |||
of the various national legal systems. The growing importance of | various national legal systems. The growing importance of national | |||
national judiciaries for the application of Community law was | judiciaries for the application of community law was stressed in the | |||
stressed in the resolution of the European Parliament of 9 July 2008 | resolution of the European Parliament of 9 July 2008 on the role of | |||
on the role of the national judge in the European judicial system. | the national judge in the European judicial system. Similarly, the | |||
Similarly the Council of the European Union has underlined the | Council of the European Union has underlined the importance of cross- | |||
importance of cross-border access to national case law, as well as | border access to national case law, as well as the need for its | |||
the need for its standardisation, in view of an integrated access in | standardization, in view of an integrated access in a decentralized | |||
a decentralized architecture. In this view the Working Party on | architecture. In this view, the Working Party on Legal Data | |||
Legal Data Processing (e-Law) of the Council of the European Union | Processing (e-Law) of the Council of the European Union formed a task | |||
formed a task group to study the possibilities for improving cross- | group to study the possibilities for improving cross-border access to | |||
border access to national case law. Taking notice of the report of | national case law. Taking notice of the report of the Working | |||
the Working Party's task group, the Council of the EU decided in 2009 | Party's task group, in 2009, the Council of the European Union | |||
to elaborate on a uniform, European system for the identification of | decided to elaborate on a uniform European system for the | |||
case law (ECLI: European Case-Law Identifier) and uniform Dublin | identification of case law (i.e., the European Case-Law Identifier | |||
Core-based set of metadata. | (ECLI)) and a uniform set of metadata based on the Dublin Core. | |||
The Council of the European Union invited the Member States to | The Council of the European Union invited the Member States to | |||
introduce in the legal information systems the European Legislation | introduce the European Legislation Identifier (ELI) in the legal | |||
Identifier (ELI), an http-based Semantic Web oriented identification | information systems, which is an http-based, Semantic Web-oriented | |||
system for European Union and Member States legislation. | identification system for legislation of the European Union and | |||
Member States. | ||||
The LEX identifier (also referred in this text as "LEX name") is | 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 | conceived to be general enough to provide guidance at the core of the | |||
of the standard and sufficient flexibility to cover a wide variety of | standard and offer sufficient flexibility to cover a wide variety of | |||
needs for identifying all the legal documents of different nature, | needs for identifying legal documents of different types, namely, | |||
namely legislative, case-law and administrative acts. Moreover, it | legislative, case law, and administrative acts. Moreover, it can be | |||
can be effectively used within a federative environment where | effectively used within a federative environment where different | |||
different publishers (public and private) can provide their own items | publishers (public and private) can provide their own items of a | |||
of a legal document (that is there is more than one manifestation of | legal document (that is, there is more than one manifestation of the | |||
the same legal document). | same legal document). | |||
Specifications and syntax rules of LEX identifier can be used also | Specifications and syntax rules for the LEX identifier can also be | |||
for http-based naming convention to cope with different requirements | used for http-based naming conventions to cope with different | |||
in legal information management, for example the need of having an | requirements in legal information management, for example, the need | |||
identifier compliant with the Linked Open Data principles. | to have an identifier that is compliant with the Linked Open Data | |||
principles. | ||||
This document supplements the required name syntax with a naming | This document supplements the required name syntax with a naming | |||
convention that interprets all these recommendations into an original | convention that interprets all these recommendations into an original | |||
solution for sources of law identification. | solution for sources of law identification. | |||
1.3. General Characteristics of the System | 1.3. General Characteristics of the System | |||
The specifications in this document promote interoperability among | The specifications in this document promote interoperability among | |||
legal information systems by defining a namespace convention and | legal information systems by defining a namespace convention and | |||
structure that will create and manage identifiers for legal | structure that will create and manage identifiers for legal | |||
documents. The identifiers are intended to be: | documents. The identifiers are intended to have the following | |||
qualities: | ||||
* globally unique | * globally unique | |||
* transparent | * transparent | |||
* reversible | * reversible | |||
* persistent | * persistent | |||
* location-independent, and | * location-independent | |||
* language-neutral. | * language-neutral | |||
These qualities facilitate legal document management and a mechanism | These qualities facilitate management of legal documents and a | |||
of stable cross-collections and cross-country references. | mechanism for stable cross-collection and cross-country references. | |||
Transparency means that given an act and its relevant metadata | Transparency means that, for a given act and its relevant metadata | |||
(issuing authority, type of measure, etc.), it is possible to create | (issuing authority, type of measure, etc.), it is possible to create | |||
the related URN able to uniquely identify the act in a way that is | a related URN that is able to uniquely identify the act in a way that | |||
reversible (from an act to its URN and from a URN to the act). | is reversible (from an act to its URN and from a URN to the act). | |||
Language-neutrality, in particular, is an important feature that | Language neutrality, in particular, is an important feature that | |||
promotes adoption of the standard by organizations that must adhere | promotes adoption of the standard by organizations that must adhere | |||
to official-language requirements. This specification provides | to official language requirements. This specification provides | |||
guidance to both public and private groups that create, promulgate, | guidance to both public and private groups that create, promulgate, | |||
and publish legal documents. Registrants wish to minimize the | and publish legal documents. Registrants wish to minimize the | |||
potential for creating conflicting proprietary schemes, while | potential for creating conflicting proprietary schemes, while | |||
preserving sufficient flexibility to allow for diverse document types | preserving sufficient flexibility to allow for diverse document types | |||
and to respect the need for local control of collections by an | and to respect the need for local control of collections by an | |||
equally diverse assortment of administrative entities. | equally diverse assortment of administrative entities. | |||
The challenge is to provide the right amount guidance at the core of | The challenge is to provide the right amount guidance at the core of | |||
the specification while providing sufficient flexibility to cover a | the specification while providing sufficient flexibility to cover a | |||
wide variety of needs. LEX does this by splitting the identifier | wide variety of needs. LEX does this by splitting the identifier | |||
into parts. The first part uses a pre-existing standard | into parts. The first part uses a preexisting standard specification | |||
specification ("country/jurisdiction name standard") to indicate the | ("country/jurisdiction name standard") to indicate the country (or | |||
country (or more generally the jurisdiction) of origin for the legal | more generally, the jurisdiction) of origin for the legal document | |||
document being identified; the remainder ("local name") is intended | being identified; the remainder ("local name") is intended for local | |||
for local use in identifying documents issued in that country or | use in identifying documents issued in that country or jurisdiction. | |||
jurisdiction. | ||||
The second part depends only on the sources of law identification | The second part depends only on the identification system for sources | |||
system operating in that nation and it is mainly composed by | of law operating in that nation, and it is mainly composed by | |||
formalized information related to the enacting authority, the type of | formalized information related to the enacting authority, the type of | |||
measure, the details and possibly the annex. | measure, the details, and possibly the annex. | |||
The identification system based on uniform names includes: | The identification system based on uniform names includes: | |||
* a schema for assigning names capable of representing unambiguously | * A schema for assigning names capable of unambiguously representing | |||
any addressed source of law (namely legislation, case law and | any addressed source of law (namely legislation, case law, and | |||
administrative acts), issued by any authority (intergovernmental, | administrative acts) issued by any authority (intergovernmental, | |||
supranational, national, regional and local) at any time (past, | supranational, national, regional, and local) at any time (past, | |||
present and future); | present, and future). | |||
* a resolution mechanism - in a distributed environment - that ties | * A resolution mechanism -- in a distributed environment -- that | |||
a uniform name to the on-line location of the corresponding | ties a uniform name to the online location of the corresponding | |||
resource(s). | resource(s). | |||
This document considers the first of these requirements. It also | This document considers the first of these requirements. It also | |||
contains a few references to the architecture of the resolution | contains a few references to the architecture of the resolution | |||
service and to the corresponding software. | service and to the corresponding software. | |||
1.4. Linking a LEX Name to a Document | 1.4. Linking a LEX Name to a Document | |||
The LEX name is linked to the document through meta-information which | The LEX name is linked to the document through meta-information, | |||
may be specified as follows: | which may be specified as follows: | |||
* within the document itself through a specific element within an | * Within the document itself through a specific element within an | |||
XML schema or by an [W3C.HTML] META tag; | XML schema or by a meta tag [W3C.HTML]. | |||
* externally by means of a Resource Description Framework | * Externally by means of a Resource Description Framework | |||
[W3C.rdf-schema] triple, a specific attribute in a database, etc. | [W3C.RDF-SCHEMA] triple, a specific attribute in a database, etc. | |||
At least one of these references is necessary to enable automated | At least one of these references is necessary to enable automated | |||
construction and update of catalogues (distributed and centralized) | construction, an update of catalogues (distributed and centralized), | |||
and the implementation of resolvers that associate the uniform name | and the implementation of resolvers that associate the uniform name | |||
of a document with its physical location(s). LEX assumes no | of a document with its physical location. LEX assumes no particular | |||
particular relationship between the originator of the document, its | relationship between the originator of the document, its publisher, | |||
publisher, and the implementer of catalogues or resolution services. | the implementer of catalogues, or resolution services. | |||
1.5. Use of LEX Names in References | 1.5. Use of LEX Names in References | |||
LEX names can be used in references as an HREF attribute value of the | 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 | hypertext link to the referred document. This link can be created in | |||
two ways: | two ways: | |||
* by manually inserting in the referring document the link with the | * Manually inserting the link with the uniform name in the referring | |||
uniform name: this is a burdensome procedure, especially for | document. This is a burdensome procedure, especially for | |||
documents that are already on-line; | documents that are already online. | |||
* by automatically constructing (either permanently or temporarily) | * Automatically constructing (either permanently or temporarily) the | |||
the link with the uniform name, through reference parsers of a | link with the uniform name through reference parsers of a text. | |||
text: this is a more time-saving procedure even if subject to a | This procedure offers more time savings, even if it is subject to | |||
certain percentage of errors, since references are not always | a certain percentage of errors, since references are not always | |||
accurate or complete. This solution could nevertheless be | accurate or complete. Nevertheless, this solution could be | |||
acceptable for already published documents. | acceptable for already-published documents. | |||
Whatever method is adopted, new documents produced in whatever format | No matter which method is adopted, new documents produced in a | |||
(for example XML, XHTML, etc) should express references through the | certain format (for example, XML, XHTML, etc.) should express | |||
uniform name of the document referred to. | references through the uniform name of the document referred to. | |||
1.6. Definitions | 1.6. Definitions | |||
The following terms are used in these specifications: | The following terms are used in this document: | |||
* Source of Law: a general concept to refer to legislation, case | Source of Law: A general concept that refers to legislation, case | |||
law, regulations and administrative acts. In its broadest sense, | law, regulations, and administrative acts. In its broadest sense, | |||
the source of law is anything that can be conceived as the | the source of law is anything that can be conceived as the | |||
originator of 'erga omnes' legal rules. In this document "Source | originator of 'erga omnes' legal rules. In this document, "source | |||
of Law" refers also to acts during their making such as bills that | of law" also refers to acts during their creation, such as bills, | |||
might or might not become laws; | that might or might not become laws. | |||
* Jurisdictional Registrar: an organization that shares and defines | Jurisdictional Registrar: An organization in any jurisdiction that | |||
in any jurisdiction the assignment of the main components of the | shares and defines the assignment of the main components of the | |||
resource identifier through which the identifier uniqueness is | resource identifier through which the identifier uniqueness is | |||
guaranteed. | guaranteed. | |||
1.7. Terminology | 1.7. Terminology | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
1.8. Syntax Used in this Document | 1.8. Syntax Used in This Document | |||
This document uses the syntax common to many Internet RFCs, which is | This document uses a syntax that is based on the Augmented Backus- | |||
based on the ABNF (Augmented Backus-Naur Form) [RFC5234] meta- | Naur Form (ABNF) [RFC5234] meta-language, which is used in many RFCs. | |||
language. | ||||
1.9. Namespace Registration | 1.9. Namespace Registration | |||
The "lex" namespace has already been registered in the "Formal URN | The "lex" namespace has been registered in the "Formal URN | |||
Namespaces" registry. | Namespaces" registry. See Section 12. | |||
2. Registration of LEX | 2. Registration of LEX | |||
2.1. Identifier Structure | 2.1. Identifier Structure | |||
The identifier has a hierarchical structure as follows: | The identifier has the following hierarchical structure: | |||
"urn:lex:" NSS | "urn:lex:" NSS | |||
where NSS is the Namespace Specific String composed as follows: | where NSS is the Namespace Specific String composed as follows: | |||
NSS = jurisdiction ":" local-name | NSS = jurisdiction ":" local-name | |||
where: | where: | |||
* jurisdiction identifies the scope (state, regional, municipal, | jurisdiction: Identifies the scope (state, regional, municipal, | |||
supranational or of an organization) where a set of sources of law | supranational, or organizational) where a set of sources of law | |||
have validity. It is also possible to represent international | have validity. It is also possible to represent international | |||
organizations (either states or public administrations or private | organizations (either states, public administrations, or private | |||
entities); | entities). | |||
* local-name is the uniform name of the source of law in the country | local-name: The uniform name of the source of law in the country or | |||
or jurisdiction where it is issued; its internal structure is | jurisdiction where it is issued; its internal structure is common | |||
common to the already adopted schemas. It represents all aspects | to the already-adopted schemas. It represents all aspects of an | |||
of an intellectual production, from its initial idea, through its | intellectual production, from its initial idea, through its | |||
evolution during the time, to its realisation by different means | evolution during the time, to its realization by different means | |||
(paper, digital, etc.). | (paper, digital, etc.). | |||
The jurisdiction element is composed of two specific fields: | The jurisdiction element is composed of two specific fields: | |||
jurisdiction = jurisdiction-code *(";" jurisdiction-unit) | jurisdiction = jurisdiction-code *(";" jurisdiction-unit) | |||
where: | where: | |||
* jurisdiction-code is usually the identification code of the | jurisdiction-code: Usually the identification code of the country | |||
country where the source of law is issued. | where the source of law is issued. To facilitate the transparency | |||
To facilitate the transparency of the name, the jurisdiction-code | of the name, the jurisdiction-code usually follows the rules of | |||
follows usually the rules of identification of other Internet | identification of other Internet applications, based on domain | |||
applications, based on domain name (for details and special cases | name (for details and special cases, see Section 2.2). | |||
see Section 2.2). | ||||
Due to the differences in representation in the various languages | Due to the differences in representation in the various languages | |||
of a country, for an easier identification of the country the use | of a country, the use of the standard [ISO.3166-1] is strongly | |||
the standard [ISO3166-1] is strongly RECOMMENDED. | RECOMMENDED for easier identification of the country. Therefore, | |||
Therefore a urn-lex ID always begins with a sequence of ASCII | a urn-lex ID always begins with a sequence of ASCII characters: | |||
characters: "urn:lex:ccTLD". For all the other components that | "urn:lex:ccTLD". For all the other components that follow the | |||
follow the jurisdiction-code, the Jurisdictional Registrar decides | jurisdiction-code, the Jurisdictional Registrar decides the mode | |||
the mode of representation (ASCII or UTF-8 %-encoding) (see | of representation (ASCII or UTF-8 percent-encoding; see | |||
Section 3.4). | Section 3.4). | |||
Where applicable, the domain name of the country or multinational | Where applicable, the domain name of the country or multinational | |||
or international organisation is used. | or international organization is used. If such information is not | |||
If such information is not available for a particular institution, | available for a particular institution, a specific code will be | |||
a specific code will be defined (see Section 2.2). Examples | defined (see Section 2.2). Examples reported in this document are | |||
reported in this document are hypothetical and assume that the | hypothetical and assume that the corresponding domain name is used | |||
corresponding domain name is used for the jurisdiction-code. | for the jurisdiction-code. | |||
* jurisdiction-unit are the possible administrative hierarchical | jurisdiction-unit The possible administrative hierarchical sub- | |||
sub-structures defined by each country or organisation within | structures defined by each country or organization within their | |||
their specific legal system. This additional information can be | specific legal system. This additional information can be used | |||
used in case two or more levels of legislative or judicial | when two or more levels of legislative or judicial production | |||
production exist (e.g., federal, state and municipality level) and | exist (e.g., federal, state, and municipality level) and the same | |||
the same bodies may be present in each jurisdiction. Therefore | bodies may be present in each jurisdiction. Therefore, acts of | |||
acts of the same type issued by similar authorities in different | the same type issued by similar authorities in different areas | |||
areas differ for the jurisdiction-unit specification. | differ for the jurisdiction-unit specification. | |||
An example can be the following: | The following is an example: | |||
"br:governo:decreto" (decree of federal government), | ||||
"br:governo:decreto" (decree of federal government) | ||||
"br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state) | "br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state) | |||
"br;sao.paulo;campinas:governo:decreto" (decree of Campinas | "br;sao.paulo;campinas:governo:decreto" (decree of Campinas | |||
municipality). | municipality) | |||
Fictitious examples of sources of law identifiers are: | The following are fictitious examples of sources of law identifiers: | |||
urn:lex:it:stato:legge:2003-09-21;456 | urn:lex:it:stato:legge:2003-09-21;456 | |||
(Italian act) | (Italian act) | |||
urn:lex:fr:etat:loi:2004-12-06;321 | urn:lex:fr:etat:loi:2004-12-06;321 | |||
(French act) | (French act) | |||
urn:lex:es:estado:ley:2002-07-12;123 | urn:lex:es:estado:ley:2002-07-12;123 | |||
(Spanish act) | (Spanish act) | |||
urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 | urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 | |||
(Glarus Swiss Canton decree) | (Glarus Swiss Canton decree) | |||
urn:lex:eu:commission:directive:2010-03-09;2010-19-EU | urn:lex:eu:commission:directive:2010-03-09;2010-19-EU | |||
(EU Commission Directive) | (EU Commission Directive) | |||
urn:lex:us:supreme.court:decision:1978-04-28;77-5953 | urn:lex:us:supreme.court:decision:1978-04-28;77-5953 | |||
(US SC decision: Riley vs Illinois) | (US SC decision: Riley vs Illinois) | |||
urn:lex:be:conseil.etat:decision:2008-07-09;185.273 | urn:lex:be:conseil.etat:decision:2008-07-09;185.273 | |||
(Decision of the Belgian Council of State) | (Decision of the Belgian Council of State) | |||
2.2. Jurisdiction-code Register | 2.2. Jurisdiction-Code Register | |||
A new jurisdiction-code registry has been created. Each entry | A new jurisdiction-code registry has been created. Note that this is | |||
contains the following elements: | a CNR registry and *not* an IANA registry. | |||
* jurisdiction-code: the identifier of jurisdiction, assigned to the | Each entry contains the following elements: | |||
country or organisation; | ||||
* jurisdiction: the official name of the jurisdiction, country or | jurisdiction-code: The identifier of jurisdiction assigned to the | |||
organisation; | country or organization. | |||
* registrant: essential information to identify the organization | jurisdiction: The official name of the jurisdiction, country or | |||
organization. | ||||
registrant: Essential information that identifies the organization | ||||
that requested the registration of the code. The registrant will | that requested the registration of the code. The registrant will | |||
be responsible for its DNS zone and for the attribution of sub- | be responsible for its DNS zone, the attribution of sub-zone | |||
zone delegations, and so on. It is RECOMMENDED that each | delegations, and so on. It is RECOMMENDED that each jurisdiction | |||
jurisdiction create a registry of all delegated levels so that the | create a registry of all delegated levels so that the organization | |||
organization responsible of each sub-zone can easily be | responsible for each sub-zone can easily be identified. | |||
identified; | ||||
* reference: a reference to the defining document (if any). | reference: A reference to the defining document (if any). | |||
The table is initially empty. Possible example entries are: | The registry is initially empty. The following are possible example | |||
entries: | ||||
"br"; "Brazil"; "Prodasen, Federal Senate, address, contact"; | "br"; "Brazil"; "Prodasen, Federal Senate, address, contact"; | |||
\[reference\] | \[reference\] | |||
"eu"; "European Union"; "DG Digit, European Commission, address, | "eu"; "European Union"; "DG Digit, European Commission, address, | |||
contact"; \[reference\] | contact"; \[reference\] | |||
"un.org"; "United Nations"; "DPI, United Nations, address, | "un.org"; "United Nations"; "DPI, United Nations, address, | |||
contact"; \[reference\] | 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- | CNR is responsible for the jurisdiction-code and the root lex- | |||
nameserver.nic.it registries of the resolution routing. | nameserver.nic.it registries of the resolution routing. | |||
A new Jurisdictional Registrar will contact CNR or the Designated | A new Jurisdictional Registrar will contact CNR or the designated | |||
Expert(s) according to the established rules of governance (published | expert(s) according to the established rules of governance (published | |||
in the CNR website dedicated to the LEX governance). The application | on the CNR website dedicated to LEX governance). The application | |||
will be evaluated according to the Jurisdictional Registrar | will be evaluated according to the Jurisdictional Registrar | |||
authoritativeness and the offered guarantees. The Designated | authoritativeness and the offered guarantees. The designated | |||
Expert(s) will evaluate such applications, with a similar approach as | expert(s) will evaluate such applications with a similar approach as | |||
of the DNS. Typically such applications should come from public | evaluations of the DNS. Typically, such applications should come | |||
administrations, as authorities enacting sources of law. | from public administrations, as authorities enacting sources of law. | |||
The adopted registration policy is similar to that of the "Expert | The adopted registration policy is similar to that of the "Expert | |||
Review" as specified in [RFC8126]. Designated Experts will assign | Review" policy specified in [RFC8126]. The designated expert(s) will | |||
jurisdiction codes based on the following principles: | assign jurisdiction codes based on the following principles: | |||
* If a request comes from a jurisdiction that corresponds to a | * If a request comes from a jurisdiction that corresponds to a | |||
country and the jurisdiction code is the same as a top level | country and the jurisdiction code is the same as a top-level | |||
ccTLD, then the top level ccTLD should be used as the jurisdiction | Country Code Top-Level Domain (ccTLD), then the top-level ccTLD | |||
code; | should be used as the jurisdiction code. | |||
* If a request comes from a jurisdiction that corresponds to a | * If a request comes from a jurisdiction that corresponds to a | |||
multi-national (e.g., European Union) or international (e.g., | multi-national organization (e.g., European Union) or | |||
United Nations, World Trade Organization) organizations the Top | international organization (e.g., United Nations and World Trade | |||
Level Domain Name (e.g., "eu") or the Domain Name (e.g., "un.org", | Organization), the Top-Level Domain Name (e.g., "eu") or the | |||
"wto.org") of the organization should be used as the jurisdiction | Domain Name (e.g., "un.org" and "wto.org") of the organization | |||
code; | should be used as the jurisdiction code. | |||
* in case when such multi-national or international organization | * If a multi-national or international organization does not have a | |||
does not have a registered domain, Designated Expert(s) should | registered domain, the designated expert(s) should assign | |||
assign something like name.lex.arpa, where name will be the | something like "name.lex.arpa", where the name will be the acronym | |||
acronym of the organization name, in the language chosen by the | of the organization name in the language chosen by the | |||
organization itself. For example, the jurisdiction code of the | organization itself. For example, the jurisdiction code of the | |||
European Economic Community could be "eec.lex.arpa". Anyway the | European Economic Community could be "eec.lex.arpa". The alias | |||
alias mechanism allows to have acronyms in different languages. | mechanism allows for acronyms in different languages. | |||
Jurisdiction codes MUST NOT be renamed, because that would violate | Jurisdiction codes MUST NOT be renamed, because that would violate | |||
rules that URN assignments are persistent. | the rule that URN assignments be persistent. | |||
Jurisdiction codes MUST NOT ever be deleted. They can only be marked | Jurisdiction codes MUST NOT ever be deleted. They can only be marked | |||
as "obsolete", i.e. closed for new assignments within the | as "obsolete", i.e., closed for new assignments within the | |||
jurisdiction. Requests to obsolete a jurisdiction code are also | jurisdiction. Requests to obsolete a jurisdiction code are also | |||
processed by Designated Expert(s). | processed by the designated expert(s). | |||
Designated Expert(s) can unilaterally initiate allocation or | Designated expert(s) can unilaterally initiate allocation or | |||
obsolescence of a jurisdiction code. | obsolescence of a jurisdiction code. | |||
Request for new jurisdiction code assignment must include the | Requests for new jurisdiction code assignments must include the | |||
organization or country requesting it and Contact information (email) | organization or country requesting it and contact information (email) | |||
of who requested the assignment. | of who requested the assignment. | |||
2.3. Conformance with URN Syntax | 2.3. Conformance with URN Syntax | |||
The "lex" namespace identifier (NID) syntax conforms to [RFC8141]. | The "lex" namespace identifier (NID) syntax conforms to [RFC8141]. | |||
However, a series of characters are reserved to identify elements or | However, a series of characters are reserved for identifying elements | |||
sub-elements, or for future extensions of the LEX naming convention | or sub-elements, or for future extensions of the LEX naming | |||
(see Section 3.2). | convention (see Section 3.2). | |||
2.4. Validation Mechanism | 2.4. Validation Mechanism | |||
The Jurisdictional Registrar (or those it delegates) of each adhering | The Jurisdictional Registrar (or those it delegates) of each adhering | |||
country or organization is responsible for the definition or | country or organization is responsible for the definition or | |||
acceptance of the uniform name's primary elements (issuing authority | acceptance of the uniform name's primary elements (issuing authority | |||
and type of legal measure). | and type of legal measure). | |||
2.5. Scope | 2.5. Scope | |||
Global interest. In fact each body that enacts sources of law can | Global interest. In fact, each body that enacts sources of law can | |||
identify them by this scheme. Furthermore, other bodies (even not | identify them by this scheme. Furthermore, other bodies (even non- | |||
enacting sources of law, such as newspaper or magazine publishers, | enacting sources of law, such as newspapers, magazine publishers, | |||
etc.) aiming to refer legal documents, can unequivocally identify | etc.) that aim to reference legal documents can unequivocally | |||
them by this scheme. | identify them by this scheme. | |||
3. General Syntax and Features of the LEX Identifier | 3. General Syntax and Features of the LEX Identifier | |||
This section lists the general features applicable to all | This section lists the general features applicable to all | |||
jurisdictions. | jurisdictions. | |||
3.1. Allowed and Not Allowed Characters | 3.1. Allowed and Not Allowed Characters | |||
These characters are defined in accordance with the [RFC8141] | The characters are defined in accordance with [RFC8141]. For various | |||
"Uniform Resource Names (URNs)". For various reasons, later | reasons that are explained later, only a subset of characters is | |||
explained, in the "lex" NSS only a subset of characters is allowed. | allowed in the "lex" NSS. All other characters are either eliminated | |||
All other characters are either eliminated or converted. | or converted. | |||
For the full syntax of the uniform names in the "lex" space, please | For the full syntax of the uniform names in the "lex" space, please | |||
see Section 8. | see Section 8. | |||
3.2. Reserved Characters | 3.2. Reserved Characters | |||
The following characters are reserved in the specific "lex" | The following characters are reserved in the specific "lex" | |||
namespace: | namespace: | |||
"@" separator of the expression, that contains information on | "@" Separator of the expression that contains information on | |||
version and language; | version and language. | |||
"$" separator of the manifestation, that contains information on | ||||
format, editor, etc.; | "$" Separator of the manifestation that contains information on | |||
":" separator of the main elements of the name at any entity; | format, editor, etc. | |||
";" separator of level. It identifies the introduction of an element | ||||
at a hierarchically lower level, or the introduction of a | ":" Separator of the main elements of the name at any entity. | |||
specification; | ||||
"+" separator of the repetitions of an entire main element (e.g., | ";" Separator of the level. It identifies the introduction of an | |||
multiple authorities); | element at a hierarchically lower level or the introduction of | |||
"|" separator between different formats of the same element (e.g., | a specification. | |||
date); | ||||
"," separator of the repetitions of individual components in the main | "+" Separator of the repetitions of an entire main element (e.g., | |||
elements, each bearing the same level of specificity (e.g., | multiple authorities). | |||
multiple numbers); | ||||
"~" separator of the partition identifier in references (e.g., | "|" Separator between different formats of the same element (e.g., | |||
paragraph of an article); | date). | |||
"*" and "!" are reserved for future expansions. | ||||
"," Separator of the repetitions of individual components in the | ||||
main elements, each bearing the same level of specificity | ||||
(e.g., multiple numbers). | ||||
"~" Separator of the partition identifier in references (e.g., | ||||
paragraph of an article). | ||||
"*" Reserved for future expansions. | ||||
"!" Reserved for future expansions. | ||||
To keep backward compatibility with existing applications in some | To keep backward compatibility with existing applications in some | |||
jurisdictions, the "lex" NID syntax does not include the use of the | jurisdictions, the "lex" NID syntax does not include the use of the | |||
character "/" in this version. | character "/" in this version. This character is always converted | |||
This character is always converted into "-", except in the formal | into "-", except in the formal annexes (see Section 6.4.1). | |||
annexes (see Section 6.4.1). | ||||
3.3. Case Sensitivity | 3.3. Case Sensitivity | |||
For all the languages where different cases (upper or lower cases) or | For all the languages where different cases (uppercase or lowercase) | |||
different spelling of the same word are possible, names belonging to | or different spellings of the same word are possible, names belonging | |||
"lex" namespace are case-insensitive. It is RECOMMENDED that, in | to "lex" namespace are case-insensitive. For the Latin alphabet, it | |||
latin alphabet, they be created in lower case, but names that differ | is RECOMMENDED that names be created in lower case, but names that | |||
only in case, or in the spelling, of the same word MUST be considered | differ only in case or in the spelling of the same word MUST be | |||
to be equivalent | considered equivalent (e.g., "Ministry" will be recorded as | |||
(e.g., "Ministry" will be recorded as "ministry"). | "ministry"). | |||
3.4. Unicode Characters outside the ASCII Range | 3.4. Unicode Characters Outside the ASCII Range | |||
In order to exploit DNS as a routing tool towards the proper | In order to exploit the DNS as a routing tool towards the proper | |||
resolution system, to keep editing and communication more simple and | resolution system, keep editing and communication more simple, and | |||
to avoid character percent-encoding, it is RECOMMENDED that the | avoid character percent-encoding, it is RECOMMENDED that characters | |||
characters outside the ASCII range (e.g. national characters, | outside the ASCII range (e.g., national characters, diacritic signs, | |||
diacritic signs, ...) are turned into base ASCII characters (e.g., | etc.) be replaced by base ASCII characters. For example, the Italian | |||
the Italian term "sanitU+00E0" replaced into "sanita", the French | term "sanitU+00E0" can be replaced by "sanita", the French term | |||
term "ministU+00E8re" replaced into "ministere"), in case by | "ministU+00E8re" can be replaced by "ministere", and "MU+00FCnchen" | |||
transliteration (e.g. "MU+00FCnchen" replaced into "muenchen"). | can be replaced by "muenchen" (transliteration). | |||
This mapping consists of: | This mapping consists of: | |||
* transcription from non-Latin alphabets; | * Transcription from non-Latin alphabets | |||
* transliteration of some signs (diaeresis, eszett, ...); | * Transliteration of some signs (e.g., diaeresis and eszett) | |||
* preservation of the only basic characters, eliminating the signs | * Preservation of only the basic characters, eliminating the signs | |||
placed above (accents, tilde, ...), below (cedilla, little tail, | placed above (e.g., accents and tilde), below (e.g., cedilla and | |||
...) or on (oblique cut, ...). | little tail), or on (e.g., oblique cut) | |||
The most suitable, well-known and widespread mapping system for a | The most suitable, well-known, and widespread mapping system for a | |||
given language MUST be chosen by the jurisdiction, or, in agreement | given language MUST be chosen by the jurisdiction, or in agreement | |||
with this one, by the jurisdiction-unit in case of different | with this one, by the jurisdiction-unit in case of different | |||
languages in the various regions, also taking into account the | languages in various regions, also taking into account the choices | |||
choices made for the same language by other jurisdictions. | made for the same language by other jurisdictions. This mapping is | |||
Certainly this mapping is simpler and more feasible for languages | simpler and more feasible for languages that use the Latin alphabet | |||
that use the Latin alphabet and gradually becomes more complex both | and gradually becomes more complex for other alphabets and for | |||
for other alphabets and for writing systems with opposite orientation | writing systems that use opposite orientation (from right to left) or | |||
(from right to left) or based on ideographic symbols. | are based on ideographic symbols. | |||
If this conversion is not acceptable by a specific jurisdiction or it | If this conversion is not acceptable by a specific jurisdiction or it | |||
is not available in a given language, UNICODE MUST be used and, for | is not available in a given language, Unicode MUST be used, and for | |||
accessing network protocols, any UNICODE code points outside the | accessing network protocols, any Unicode code points outside the | |||
ASCII range MUST be converted in UTF-8 %-encoding according to | ASCII range MUST be converted to UTF-8 percent-encoding according to | |||
[RFC3986] and [RFC3629]. | [RFC3986] and [RFC3629] . | |||
In this case it should be noted that the generated URN (as some of | ||||
its parts) cannot be used directly for routing through DNS, and | In this case, it should be noted that the generated URN (as some of | |||
therefore the jurisdiction must adopt one of the following | its parts) cannot be used directly for routing through the DNS. | |||
Therefore, the jurisdiction must adopt one of the following | ||||
strategies: | strategies: | |||
* to convert non-ASCII characters within the DNS into the IDN | * Convert non-ASCII characters within the DNS into IDN encoding | |||
encoding, using the [RFC5894] punycode translation (e.g. | using Punycode translation [RFC5894] (e.g., mU+00FCnchen in xn-- | |||
mU+00FCnchen in xn--mnchen-3ya), and to develop a software | mnchen-3ya) and develop a software interface that converts the URN | |||
interface that converts the URN before the navigation in DNS, or | before the navigation in the DNS. | |||
* to create a routing service relying on a software, out of DNS, | * Create a routing service relying on a software, outside of the | |||
addressing a proper resolution service. | DNS, that addresses a proper resolution service. | |||
Note that the urn:lex ID, could contain groups of characters (UTF-8 | Note that the urn:lex ID could contain groups of characters (UTF-8 | |||
%-encoded) of some languages with different orientations: in this | percent-encoded) of some languages with different orientations. In | |||
case the BiDi rules apply [RFC5893]. | this case, the BiDi rules apply [RFC5893]. | |||
Summarizing, the preference order is the following: | The preferred order is summarized as follows: | |||
* Conversion into basic ASCII, RECOMMENDED solution (for not having | * Conversion into basic ASCII is the RECOMMENDED solution (for not | |||
to make conversions for network protocols and DNS); | having to make conversions for network protocols and the DNS). | |||
* Using UNICODE, and convert into UTF-8 %-encoding [RFC3629], for | * Using Unicode and converting to UTF-8 percent-encoding [RFC3629] | |||
accessing network protocols, and to punycode [RFC5894], only for | for accessing network protocols and to Punycode [RFC5894] only for | |||
navigation in DNS, via software interface; | navigation in DNS via software interface. | |||
* Creation of a routing service relying on a software, out of DNS, | * Creation of a routing service relying on a software outside of DNS | |||
addressing a proper resolution service. | and addressing a proper resolution service. | |||
The first solution allows native DNS routing, while the other two | The first solution allows native DNS routing while the other two | |||
require software development for the interface or the routing. | solutions require software development for the interface or the | |||
However it is up to the specific jurisdiction to choose the preferred | routing. However, it is up to the specific jurisdiction to choose | |||
solution. | the preferred solution. | |||
Two examples (Latin and Cyrillic alphabet) relating to the different | The following are two examples (Latin and Cyrillic alphabets) | |||
solutions adopted are here reported: | relating to the different solutions adopted: | |||
a circular adopted by the Municipality of Munich (Rundschreiben der | * A circular adopted by the Municipality of Munich (Rundschreiben | |||
Stadt MU+00FCnchen): | der Stadt MU+00FCnchen): | |||
- ascii = urn:lex:de:stadt.munchen:rundschreiben:... | ||||
- unicode = urn:lex:de:stadt.mU+00FCnchen:rundschreiben:... | ||||
- utf-8 = urn:lex:de:stadt.m%xC3%xBCnchen:rundschreiben:... | ||||
- punycode = urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben:... | ||||
a state law of the Russian Federation (latin: gosudarstvo zakon; | - ASCII: | |||
cyrillic: U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435 | ||||
U+0437U+0430U+043AU+043EU+043D): | ||||
- ascii = urn:lex:ru:gosudarstvo:zakon:... | ||||
- unicode = urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D | ||||
U+0438U+0435:U+0437U+0430U+043AU+043EU+043D:... | ||||
- utf-8 = urn:lex:ru:%xD1%x81%xD0%xBE%xD1%x81%xD1%x82%xD0%xBE%xD1 | ||||
%x8F%xD0%xBD%xD0%xB8%xD0%xB5:%xD0%xB7%xD0%xB0%xD0%xBA | ||||
%xD0%xBE%xD0%xBD:... | ||||
- punycode = urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme:... | ||||
assuming that the Russia jurisdiction-code is expressed | urn:lex:de:stadt.munchen:rundschreiben: ... | |||
in ASCII ("ru"), | ||||
while the Cyrillic version ("U+0440U+0444") has the | - Unicode: | |||
puny-code "xn--p1ai". | ||||
urn:lex:de:stadt.mU+00FCnchen:rundschreiben: ... | ||||
- UTF-8: | ||||
urn:lex:de:stadt.m%xC3%xBCnchen:rundschreiben: ... | ||||
- Punycode: | ||||
urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben: ... | ||||
* A state law of the Russian Federation (Latin: gosudarstvo zakon; | ||||
Cyrillic: U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435 | ||||
U+0437U+0430U+043AU+043EU+043D): | ||||
- ASCII: | ||||
urn:lex:ru:gosudarstvo:zakon: ... | ||||
- Unicode: | ||||
urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D | ||||
U+0438U+0435:U+0437U+0430U+043AU+043EU+043D: ... | ||||
- UTF-8: | ||||
urn:lex:ru:%xD1%x81%xD0%xBE%xD1%x81%xD1%x82%xD0%xBE%xD1 | ||||
%x8F%xD0%xBD%xD0%xB8%xD0%xB5:%xD0%xB7%xD0%xB0%xD0%xBA | ||||
%xD0%xBE%xD0%xBD: ... | ||||
- Punycode: | ||||
urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme: ... | ||||
| Note: The above assumes that the Russia jurisdiction-code is | ||||
| expressed in ASCII ("ru"), while the Cyrillic version | ||||
| ("U+0440U+0444") has the Punycode "xn--p1ai". | ||||
3.5. Abbreviations | 3.5. Abbreviations | |||
Abbreviations are often used in law for indicating institutions (e.g. | Abbreviations are often used in law for indicating institutions | |||
Min.), structures (e.g. Dept.), or legal measures (e.g. Reg.) but | (e.g., Min.), structures (e.g., Dept.), or legal measures (e.g., | |||
not in a uniform way, therefore their expansion is highly RECOMMENDED | Reg.), but they are not used in a uniform way. Therefore, their | |||
(e.g., "Min." is reported as "ministry"). | expansion is highly RECOMMENDED (e.g., "Min." is expanded as | |||
"ministry"). | ||||
3.6. Date Format | 3.6. Date Format | |||
The [ISO.8601.1988] is the international format for representing | [ISO.8601.1988] describes the international format for representing | |||
dates: therefore dates MUST always be represented in this format (4 | dates. Dates MUST always be represented in this format (4 digits for | |||
digits for the year, 2 digits for the month, 2 digits for the day): | the year, 2 digits for the month, and 2 digits for the day): | |||
date-iso = yyyy-mm-dd | date-iso = yyyy-mm-dd | |||
(e.g., "September 2, 99" will be written as "1999-09-02"). | For example, "September 2, 99" will be written as "1999-09-02". | |||
This format ensures interoperability between different representation | This format ensures interoperability between different representation | |||
systems and there are several programs for mapping other formats to | systems, and there are several programs for mapping other formats to | |||
this one. | this one. | |||
However, to make reading and understanding such other formats (e.g. | ||||
Jewish calendar), the urn:lex scheme provides that the date can be | ||||
added in the jurisdiction's own format | ||||
(e.g. the date in the previous example would be 21.Elul,5759, that | ||||
is: | ||||
- in Hebrew characters: | However, to facilitate reading and understanding other formats (e.g., | |||
"U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.U+05EA | Jewish calendar), the urn:lex scheme allows for the date to be added | |||
U+05E9U+05E0U+05F4U+05D8"; | in the jurisdiction's own format. For example, the date in the | |||
- in UTF-8 code: | previous example would be 21.Elul,5759, that is: | |||
"%x5c%x75%x30%x35%x44%x42%x5c%x75%x30%x35%x46%x34%x5c%x75%x30%x35 | ||||
%x44%x30%x2e%x5c%x75%x30%x35%x44%x30%x5c%x75%x30%x35%x42%x31%x5c | ||||
%x75%x30%x35%x44%x43%x5c%x75%x30%x35%x44%x35%x5c%x75%x30%x35%x42 | ||||
%x43%x5c%x75%x30%x35%x44%x43%x2e%x5c%x75%x30%x35%x45%x41%x5c%x75 | ||||
%x30%x35%x45%x39%x5c%x75%x30%x35%x45%x30%x5c%x75%x30%x35%x46%x34 | ||||
%x5c%x75%x30%x35%x44%x38"). | ||||
Therefore, for all the dates in the urn:lex identifier (see | * In Hebrew characters: | |||
Section 6.3 and Section 7.1.2), it is also possible to indicate the | ||||
one in the local format: | U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC.U+05EA | |||
U+05E9U+05E0U+05F4U+05D8 | ||||
* In UTF-8: | ||||
%x5c%x75%x30%x35%x44%x42%x5c%x75%x30%x35%x46%x34%x5c%x75%x30%x35 | ||||
%x44%x30%x2e%x5c%x75%x30%x35%x44%x30%x5c%x75%x30%x35%x42%x31%x5c | ||||
%x75%x30%x35%x44%x43%x5c%x75%x30%x35%x44%x35%x5c%x75%x30%x35%x42 | ||||
%x43%x5c%x75%x30%x35%x44%x43%x2e%x5c%x75%x30%x35%x45%x41%x5c%x75 | ||||
%x30%x35%x45%x39%x5c%x75%x30%x35%x45%x30%x5c%x75%x30%x35%x46%x34 | ||||
%x5c%x75%x30%x35%x44%x38 | ||||
Therefore, for all the dates in the urn:lex identifier (see Sections | ||||
6.3 and 7.1.2), it is possible to indicate the date in the local | ||||
format: | ||||
date = date-iso [ "|" date-loc ] | date = date-iso [ "|" date-loc ] | |||
(e.g., "September 2, 99" will be written in ISO plus Hebrew format as | For example, "September 2, 99" will be written in ISO format and | |||
"1999-09-02|U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC. | Hebrew format as follows: | |||
U+05EAU+05E9U+05E0U+05F4U+05D8"). | ||||
The characters which are not allowed (e.g. "/") or which are reserved | 1999-09-02|U+05DBU+05F4U+05D0.U+05D0U+05B1U+05DCU+05D5U+05BCU+05DC. | |||
(e.g. ",") cannot exist inside the date-loc and therefore MUST be | U+05EAU+05E9U+05E0U+05F4U+05D8 | |||
turned into ".". | ||||
The characters that are not allowed (e.g., "/") or reserved (e.g., | ||||
",") cannot exist inside the date-loc and therefore MUST be turned | ||||
into ".". | ||||
4. Specific Syntax and Features of the LEX Identifier | 4. Specific Syntax and Features of the LEX Identifier | |||
In this section there are other features related to specific | This section discusses features related to specific jurisdictions. | |||
jurisdictions and the implementation of which is RECOMMENDED. | The implementation of these features is RECOMMENDED. | |||
4.1. Spaces, Connectives and Punctuation Marks | 4.1. Spaces, Connectives, and Punctuation Marks | |||
All the language connectives (e.g., articles, prepositions, etc.), | When explicitly present, all language connectives (e.g., articles, | |||
the punctuation marks and all the special characters (as apostrophes, | prepositions, etc.), punctuation marks, and special characters (e.g., | |||
dashes, etc.), when explicitly present, are eliminated (no | apostrophes, dashes, etc.) are eliminated (no transformation occurs | |||
transformation occurs in cases of languages with declensions or | in cases of languages with declensions or agglutinating languages). | |||
agglutinating languages). The words left are connected to each other | The words that are left are connected to each other by a dot ("."), | |||
by a dot (".") which substitutes the "space". | which substitutes for the space (e.g., "Ministry of Finances, Budget, | |||
(e.g., "Ministry of Finances, Budget and of Economic Planning" | and Economic Planning" becomes | |||
becomes "ministry.finances.budget.economic.planning"; | "ministry.finances.budget.economic.planning" and "Ministerstvo | |||
"Ministerstvo Finansov" becomes "ministerstvo.finansov") | Finansov" becomes "ministerstvo.finansov"). | |||
4.2. Acronyms | 4.2. Acronyms | |||
The use of acronyms might be confusing and encourage ambiguity in | The use of acronyms might be confusing and encourage ambiguity in | |||
uniform names (the same acronym may indicate two different | uniform names (the same acronym may indicate two different | |||
institutions or structures), therefore their expansion is highly | institutions or structures); therefore, their expansion is highly | |||
RECOMMENDED | RECOMMENDED (e.g., "FAO" is expanded as | |||
(e.g., "FAO" is expanded as "food.agriculture.organization"). | "food.agriculture.organization"). | |||
4.3. Ordinal Numbers | 4.3. Ordinal Numbers | |||
To even the representation, it is highly RECOMMENDED that any ordinal | To even the representation, it is highly RECOMMENDED that any ordinal | |||
number included in a component of a document name (e.g., in the | number included in a component of a document name (e.g., in the | |||
description of an institution body) is indicated in Western Arabic | description of an institution body) is indicated in Western Arabic | |||
numerals, regardless to the original expression: whether in Roman | numerals, regardless to the original expression, whether Roman | |||
numerals, or with an adjective, or in Arabic numeral with apex, etc. | numerals, an adjective, Arabic numerals with an apex, etc. (such as | |||
(IV, third, 1U+00B0, 2^, etc.) | IV, third, 1U+00B0, and 2^). For example, "Department IV" becomes | |||
(e.g., "Department IV" becomes "department.4"). | "department.4". | |||
5. Creation of the Source of Law LEX Identifier - Baseline structure | 5. Creation of the Source of Law LEX Identifier: Baseline Structure | |||
5.1. Basic Principles | 5.1. Basic Principles | |||
The uniform name must identify one and only one document (more | The uniform name must identify one and only one document (more | |||
precisely a "bibliographic resource" [ISBD], see also Section 5.2) | precisely a "bibliographic resource" [ISBD]; see also Section 5.2) | |||
and is created in such a way that it is: | and is created in such a way that it is: | |||
* self-explanatory; | * self-explanatory, | |||
* identifiable through simple and clear rules; | * identifiable through simple and clear rules, | |||
* compatible with the practice commonly used for references; | * compatible with the practice commonly used for references, | |||
* able to be created from references in the text, automatically (by | * able to be created from references in the text, automatically (by | |||
parser) or manually; | parser) or manually, and | |||
* representative of both the formal and the substantive aspects of | * representative of both the formal and the substantive aspects of | |||
the document. | the document. | |||
5.2. Model of Sources of Law Representation | 5.2. Model of Sources of Law Representation | |||
According to the [FRBR] (Functional Requirements for Bibliographic | According to the Functional Requirements for Bibliographic Records | |||
Records) model developed by IFLA (International Federation of Library | (FRBR) [FRBR] model developed by IFLA (International Federation of | |||
Associations and Institutions), in a source of law, as in any | Library Associations and Institutions), four fundamental entities (or | |||
intellectual production, four fundamental entities (or aspects) can | aspects) can be specified in a source of law, as in any intellectual | |||
be specified. | production. | |||
The first two entities reflect its contents: | The first two entities reflect its contents: | |||
* work: identifies a distinct intellectual creation; in our case, it | work: Identifies a distinct intellectual creation; in our case, it | |||
identifies a source of law both in its original form as amended | identifies a source of law both in its original form as amended | |||
over time; | over time. | |||
* expression: identifies a specific intellectual realisation of a | expression: Identifies a specific intellectual realization of a | |||
work; in our case it identifies every different (original or up- | work; in our case, it identifies every different (original or up- | |||
to-date) version of the source of law over time and/or language in | to-date) version of the source of law over time and/or language in | |||
which the text is expressed. | which the text is expressed. | |||
The other two entities relate to its form: | The other two entities relate to its form: | |||
* manifestation: identifies a physical embodiment of an expression | manifestation: Identifies a physical embodiment of an expression of | |||
of a work; in our case it identifies embodiments in different | a work; in our case, it identifies embodiments in different media | |||
media (printing, digital, etc.), encoding formats (XML, PDF, | (printing, digital, etc.), encoding formats (XML, PDF, etc.), or | |||
etc.), or other publishing characteristics; | other publishing characteristics. | |||
* item: identifies a specific copy of a manifestation; in our case | item: Identifies a specific copy of a manifestation; in our case, it | |||
it identifies individual physical copies as they are found in | identifies individual physical copies as they are found in | |||
particular physical locations. | particular physical locations. | |||
In this document the [FRBR] model has been interpreted for the | In this document, the [FRBR] model has been interpreted for the | |||
specific characteristics of the legal domain. In particular, apart | specific characteristics of the legal domain. In particular, apart | |||
from the language that does produce a specific expression, the | from the language that does produce a specific expression, the | |||
discriminative criterion between expression and manifestation is | discriminative criterion between expression and manifestation is | |||
based on the difference of the juridical effects that a variation can | based on the difference of the juridical effects that a variation can | |||
provide with respect to the involved actors (citizens, parties, | provide with respect to the involved actors (citizens, parties, and | |||
institutions). In this scenario the main characteristic of the | institutions). In this scenario, the main characteristic of the | |||
expression of an act is represented by its validity over the time, | expression of an act is represented by its validity over the time | |||
during which it provides the same juridical effects. These effects | during which it provides the same juridical effects. These effects | |||
may change as a result of amendments or annulments of other | may change as a result of amendments or annulments of other | |||
legislative or jurisprudential acts. Therefore notes, | legislative or jurisprudential acts. Therefore, notes, summaries, | |||
summarizations, comments, anonymizations and other editorial | comments, anonymizations, and other editorial activities over the | |||
activities over the same text do not produce different expressions, | same text do not produce different expressions. Instead, they | |||
but different manifestations. | produce different manifestations. | |||
5.3. The Structure of the Local Name | 5.3. Structure of the Local Name | |||
The local-name within the "lex" namespace MUST contain all the | The local-name within the "lex" namespace MUST contain all the | |||
necessary pieces of information enabling the unequivocal | necessary pieces of information enabling the unequivocal | |||
identification of a legal document. If the local-name violates this | identification of a legal document. If the local-name violates this | |||
requirement, the related URN is not a valid one within the "lex" | requirement, the related URN is not a valid one within the "lex" | |||
namespace. | namespace. | |||
In the legal domain, at "work" level, three components are always | In the legal domain, three components are always present at the | |||
present: the enacting authority, the type of provision and the | "work" level: the enacting authority, the type of provision, and the | |||
details. A fourth component, the annex, can be added if any. It is | details. A fourth component, the annex, can also be added. It is | |||
often necessary to differentiate various expressions, that is: | often necessary to differentiate various expressions, that is: | |||
* the original version and all the amended versions of the same | * the original version and all the amended versions of the same | |||
document; | document, and | |||
* the versions of the text expressed in the different official | * the versions of the text expressed in the different official | |||
languages of the state or organization. | languages of the state or organization. | |||
Finally the uniform name allows a distinction among diverse | Finally, the uniform name allows a distinction among diverse | |||
manifestations, which may be produced by multiple publishers using | manifestations that may be produced by multiple publishers using | |||
different means and formats. | different means and formats. | |||
In every case, the basic identifier of the source of law (work) | In every case, the basic identifier of the source of law (work) | |||
remains the same, but information is added regarding the specific | remains the same, but information is added regarding the specific | |||
version under consideration (expression); similarly a suffix is added | version under consideration (expression). Similarly, a suffix is | |||
to the expression for representing the characteristics of the | added to the expression for representing the characteristics of the | |||
publication (manifestation). | publication (manifestation). | |||
Information that forms a source of law uniform name at each level | Information that forms a uniform name for a source of law at each | |||
(work, expression, manifestation) is expressed in the official | level (work, expression, and manifestation) is expressed in the | |||
language of the relevant jurisdiction; in case of multiple official | official language of the relevant jurisdiction. More language- | |||
languages (as in Switzerland) or more involved jurisdictions (as in | dependent names (aliases) are created in cases where there are | |||
international treaties), more language-dependent names (aliases) are | multiple official languages (as in Switzerland) or more involved | |||
created. | jurisdictions (as in international treaties). | |||
Therefore, the more general structure of the local name appears as | Therefore, the more general structure of the local name appears as | |||
follows: | follows: | |||
local-name = work ["@" expression] ["$" manifestation] | local-name = work ["@" expression] ["$" manifestation] | |||
However, consistent with legislative practice, the uniform name of | However, consistent with legislative practice, the uniform name of | |||
the main original provision (work) becomes the identifier of an | the main original provision (work) becomes the identifier of an | |||
entire class of documents which includes: the original main document, | entire class of documents that includes the following: the original | |||
the annexes, and all their versions, languages and formats | main document, the annexes, and all the versions, languages, and | |||
subsequently generated. | formats that are subsequently generated. | |||
5.4. Structure of the Document Identifier at "Work" Level | 5.4. Structure of the Document Identifier at "Work" Level | |||
The structure of the document identifier is comprised of the four | The structure of the document identifier is comprised of the four | |||
fundamental elements mentioned above, distinguished one from the | fundamental elements mentioned above, distinguished one from the | |||
other, ordered by increasingly narrow domains and competencies: | other and ordered by increasingly narrow domains and competencies: | |||
work = authority ":" measure ":" details *(":" annex) | work = authority ":" measure ":" details *(":" annex) | |||
where: | where: | |||
* authority is the issuing or proposing authority of the measure | authority: The issuing or proposing authority of the measure (e.g., | |||
(e.g., State, Ministry, Municipality, Court, etc.); | state, ministry, municipality, court, etc.). | |||
* measure is the type of the measure, both public nature (e.g., | measure: The type of the measure, both public (e.g., constitution, | |||
constitution, act, treaty, regulation, decree, decision, etc.) as | act, treaty, regulation, decree, decision, etc.) and private | |||
well as private one (e.g., license, agreement, etc); | (e.g., license, agreement, etc.). | |||
* details are the terms associated to the measure, typically the | details: The terms associated with the measure, typically the date | |||
date (usually the signature date) and the number included in the | (usually the signature date) and the number included in the | |||
heading of the act; | heading of the act. | |||
* annex is the identifier of the annex, if any (e.g., Annex 1). | annex: The identifier of the annex, if any (e.g., Annex 1). | |||
In case of annexes, both the main document and its annexes have their | Both the main document and its annexes have their own uniform names | |||
own uniform name so that they can individually be referenced; the | so that they can be referenced individually; the identifier of the | |||
identifier of the annex adds a suffix to that of the main document. | annex adds a suffix to that of the main document. In a similar way, | |||
In similar way the identifier of an annex of an annex adds an ending | the identifier of an annex of an annex adds an ending to that of the | |||
to that of the annex which it is attached to. | annex that it is attached to. | |||
The main elements of the work name are generally divided into several | The main elements of the work name are generally divided into several | |||
elementary components, and for each component, specific rules of | elementary components, and for each component, specific rules of | |||
representation are established (criteria, modalities, syntax and | representation are established (criteria, modalities, syntax, and | |||
order). For the details regarding each element, please see the | order). For the details regarding each element, see Section 6. The | |||
Section 6. Examples (hypothetical) of work identifiers are: | following are hypothetical examples of work identifiers: | |||
urn:lex:it:stato:legge:2006-05-14;22 | urn:lex:it:stato:legge:2006-05-14;22 | |||
urn:lex:uk:ministry.justice:decree:1999-10-07;45 | urn:lex:uk:ministry.justice:decree:1999-10-07;45 | |||
urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 | urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 | |||
urn:lex:es:tribunal.supremo:decision:2001-09-28;68 | urn:lex:es:tribunal.supremo:decision:2001-09-28;68 | |||
urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762 | urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762 | |||
urn:lex:br:estado:constituicao:1988-10-05;lex-1 | urn:lex:br:estado:constituicao:1988-10-05;lex-1 | |||
urn:lex:un.org:united.nations;general.assembly:resolution: | urn:lex:un.org:united.nations;general.assembly:resolution: | |||
1961-11-28;a-res-1661 | 1961-11-28;a-res-1661 | |||
urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581 | urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581 | |||
The type of measure is important to identify case law, as well as | The type of measure is important to identify case law and | |||
legislation, especially within the legal systems where cases are | legislation, especially within legal systems where cases are | |||
identified traditionally only through the year of release and a | traditionally identified only through the year of release and a | |||
number. Since the aim of the lex schema is to identify specific | number. Since the aim of the lex schema is to identify specific | |||
materials, the type of measure or the full date are able to | materials, the type of measure or the full date are able to | |||
differentiate between materials belonging to a specific case. | differentiate between materials belonging to a specific case. | |||
Here below is an example where the type of measure or the full date | The following is an example where the type of measure or the full | |||
are essential for identify specific materials of a case: | date are essential for identify specific materials of a case: | |||
- 4/59 Judgment of the EEC Court of Justice 04/04/1960, Mannesmann | * 4/59 Judgment of the EEC Court of Justice 04/04/1960, Mannesmann | |||
AG and others / ECSC High Authority | 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 | urn:lex:eec.lex.arpa:court.justice:judgement:1960-04-04;4-59 | |||
and others / ECSC High Authority | ||||
urn:lex:eec.lex.arpa:court.justice:order:1960-05-18;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 | 5.5. Aliases | |||
International treaties involve multiple signatory jurisdictions, and | International treaties involve multiple signatory jurisdictions and | |||
are therefore represented through multiple identifiers, each of them | are therefore represented through multiple identifiers, each of them | |||
related to a signatory. For example, a bilateral France and Germany | related to a signatory. For example, a bilateral France and Germany | |||
treaty is identified through two URNs (aliases) belonging to either | treaty is identified through two URNs (aliases) belonging to either | |||
"fr" or "de" jurisdiction | the "fr" or "de" jurisdiction (e.g., "urn:lex:fr:etat:traite:..." and | |||
(e.g., "urn:lex:fr:etat:traite:..." and | ||||
"urn:lex:de:staat:vertrag:..." since it pertains to both the French | "urn:lex:de:staat:vertrag:..." since it pertains to both the French | |||
and the German jurisdiction). | and German jurisdictions). | |||
In the states or organisations that have multiple official languages, | In the states or organizations that have multiple official languages, | |||
a document has multiple identifiers, each of them expressed in a | a document has multiple identifiers. Each identifier is expressed in | |||
different official language, basically a set of equivalent aliases. | a different official language and is basically a set of equivalent | |||
This system permits manual or automated construction of the uniform | aliases. This system permits manual or automated construction of the | |||
name of the referred source of law in the same language used in the | uniform name of the referred source of law in the same language used | |||
document itself | in the document itself (e.g., | |||
(e.g., "urn:lex:eu:council:directive:2004-12-07;31", | "urn:lex:eu:council:directive:2004-12-07;31" and | |||
"urn:lex:eu:consiglio:direttiva:2004-12-07;31", etc.). | "urn:lex:eu:consiglio:direttiva:2004-12-07;31"). | |||
Moreover, a document can be assigned more than one uniform name in | Moreover, a document can be assigned more than one uniform name in | |||
order to facilitate its linking from other documents. This option | order to facilitate its linking from other documents. This option | |||
can be used for documents that, although unique, are commonly | can be used for documents that, although unique, are commonly | |||
referenced from different perspectives. For example, the form of a | referenced from different perspectives, for example, the form of a | |||
document's promulgation and its specific content (e.g., a Regulation | document's promulgation and its specific content (e.g., a Regulation | |||
promulgated through a Decree of the President of the Republic). | promulgated through a Decree of the President of the Republic). | |||
5.6. Structure of the Document Identifier at "Expression" Level | 5.6. Structure of the Document Identifier at "Expression" Level | |||
There may be several expressions of a legal text, connected to | There may be several expressions of a legal text connected to | |||
specific versions or languages. | specific versions or languages. | |||
Each version is characterized by the period of time during which that | 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 | 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 | of a version ends with the issuing of the subsequent version. New | |||
versions of a text may be brought into existence by: | versions of a text may be brought into existence by: | |||
* amendments due to the issuing of other legal acts and to the | * amendments due to the issuing of other legal acts and to the | |||
subsequent production of updated or consolidated texts; | subsequent production of updated or consolidated texts, | |||
* correction of publication errors (rectification or errata | * correction of publication errors (rectification or errata | |||
corrige); | corrige), and | |||
* entry into or departure from a particular time span, depending on | * entry into or departure from a particular time span, depending on | |||
the specific date in which different partitions of a text come | the specific date in which different partitions of a text come | |||
into force. | into force. | |||
Each such version may be expressed in more than one language, with | Each version may be expressed in more than one language, with each | |||
each language-version having its own specific identifier. The | language version having its own specific identifier. The identifier | |||
identifier of a source of law expression adds such information to the | of a source of law expression adds such information to the work | |||
work identifier, using the following main structure: | identifier using the following main structure: | |||
expression = version [":" language] | expression = version [":" language] | |||
where: | where: | |||
* version is the identifier of the version of the original or | version: The identifier of the version of the original or amended | |||
amended source of law. In general it is expressed by the | source of law. In general, it is expressed by the promulgation | |||
promulgation date of the amending act; other specific information | date of the amending act; other specific information can be used | |||
can be used for particular documents. If necessary, the original | for particular documents. If necessary, the original version is | |||
version is specified by the string "original", expressed in the | specified by the string "original" and is expressed in the | |||
language of the act or version (for the details regarding this | language of the act or version (for the details regarding this | |||
element, please see the Section 7); | element, please see Section 7). | |||
* language is the identification code of the language in which the | language: The identification code of the language in which the | |||
document is expressed, according to [RFC5646] (it=Italian, | document is expressed, according to [RFC5646] (it=Italian, | |||
fr=French, de=German, etc.). The granularity level of the | fr=French, de=German, etc.). The granularity level of the | |||
language (for example the specification of the German language as | language (for example, the specification of the German language as | |||
used in Switzerland rather than the standard German) is left to | used in Switzerland rather than standard German) is left to each | |||
each specific jurisdiction. The information is not necessary when | specific jurisdiction. The information is not necessary when the | |||
the text is expressed in the sole official language of the country | text is expressed in the sole official language of the country or | |||
or jurisdiction. | jurisdiction. | |||
Hypothetical examples of document identifiers for expressions are: | The following are hypothetical examples of document identifiers for | |||
expressions: | ||||
urn:lex:ch:etat:loi:2006-05-14;22@originel:fr | urn:lex:ch:etat:loi:2006-05-14;22@originel:fr | |||
(original version in French) | (original version in French) | |||
urn:lex:ch:staat:gesetz:2006-05-14;22@original:de | urn:lex:ch:staat:gesetz:2006-05-14;22@original:de | |||
(original version in German) | (original version in German) | |||
urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr | urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr | |||
(amended version in French) | (amended version in French) | |||
urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de | urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de | |||
(amended version in German) | (amended version in German) | |||
urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr | urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr | |||
(original version in French of a Belgian decision) | (original version in French of a Belgian decision) | |||
5.7. Structure of the Document Identifier at "Manifestation" Level | 5.7. Structure of the Document Identifier at "Manifestation" Level | |||
To identify a specific manifestation, the uniform name of the | To identify a specific manifestation, the uniform name of the | |||
expression is followed by a suitable suffix containing the following | expression is followed by a suitable suffix containing the following | |||
main elements: | main elements: | |||
* editor: editorial staff who produced it, expressed according to | editor: Editorial staff who produced it, expressed according to the | |||
its Internet domain name. Since publishers' domain names may vary | publisher's Internet domain name. Since publishers' domain names | |||
over time, manifestations already assigned by a publisher remain | may vary over time, manifestations already assigned by a publisher | |||
unchanged even if the identified object is no longer accessible. | remain unchanged, even if the identified object is no longer | |||
In this case, in order to make its materials accessible, the | accessible. In this case, in order to make its materials | |||
publisher will have to create for each of them a new manifestation | accessible, the publisher will have to create a new manifestation | |||
with the new domain name; | with a new domain name for each of them. | |||
* format: the digital format (e.g., XML, HTML, PDF, etc.) expressed | format: The digital format (e.g., XML, HTML, PDF, etc.) expressed | |||
according to the MIME Content-Type standard [RFC2045], where the | according to the MIME Content-Type standard [RFC2045], where the | |||
"/" character is to be substituted by the "-" sign; | "/" character is to be substituted with the "-" sign. | |||
* component: possible components of the expressions contained in the | component: Possible components of the expressions contained in the | |||
manifestation. Such components are expressed by language- | manifestation. Such components are expressed by language- | |||
dependent labels representing the whole document (in English | dependent labels representing the whole document (in English | |||
"all") or the main part of the document (in English "body") or the | "all"), the main part of the document (in English "body"), or the | |||
caption label of the component itself (e.g. Table 1, Figure 2, | caption label of the component itself (e.g., Table 1, Figure 2, | |||
etc.); | etc.). | |||
* feature: other features of the document (e.g., anonymized decision | feature: Other features of the document (e.g., anonymized decision | |||
text). | text). | |||
The manifestation suffix thus reads: | Thus, the manifestation suffix reads: | |||
manifestation = editor ":" format | manifestation = editor ":" format | |||
[":" component [":" feature]] | [":" component [":" feature]] | |||
To indicate possible features or peculiarities, each main element of | To indicate possible features or peculiarities, each main element of | |||
the manifestation MAY be followed by further specifications | the manifestation MAY be followed by further specifications | |||
(separated by ";"), for example as regards editor the archive name | (separated by ";"), for example as regards editor the archive name | |||
and the electronic publisher, for format the version, etc. Therefore | and the electronic publisher, for format the version, etc. | |||
the main elements of the manifestation will assume the forms: | Therefore, the main elements of the manifestation will assume the | |||
following forms: | ||||
editor = publisher *(";" specification) | editor = publisher *(";" specification) | |||
format = mime *(";" specification) | format = mime *(";" specification) | |||
component = part *(";" specification) | component = part *(";" specification) | |||
feature = attribute *(";" specification) | feature = attribute *(";" specification) | |||
The syntax details of the manifestation element is shown in | The syntax details of the manifestation element are shown in | |||
Section 8, in the related part. | Section 8 in the related part. | |||
(examples (hypothetical): | The following are hypothetical examples: | |||
the original version of the Italian act 3 April 2000, n. 56 might | * The original version of the Italian act 3 April 2000, n. 56 might | |||
have the following manifestations with their relative uniform names: | have the following manifestations with their relative uniform | |||
names: | ||||
- PDF format (vers. 1.7) of the whole act edited by the Italian | - PDF format (vers. 1.7) of the whole act edited by the Italian | |||
Parliament: | Parliament: | |||
"urn:lex:it:stato:legge:2000-04-03;56$application-pdf; | ||||
1.7:parlamento.it" | ||||
- XML format (version 2.2 DTD NIR) of the text of the act and PDF | ||||
format (version 1.7) of the "Figura 1" (figure 1) contained in the | ||||
body, edited by the Italian Senate: | ||||
"urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir-2.2: | ||||
senato.it:testo" | ||||
"urn:lex:it:stato:legge:2000-04-03;56$application-pdf;1.7: | ||||
senato.it:figura.1" | ||||
the Spanish URN of the html format of the whole Judgment of the | urn:lex:it:stato:legge:2000-04-03;56$application-pdf; | |||
European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, | 1.7:parlamento.it | |||
published in the Jurifast database in anonymized form: | ||||
"urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08 | - XML format (version 2.2 DTD NIR) of the text of the act and PDF | |||
@original:es$text-html:juradmin.eu;jurifast:todo:anonimo") | format (version 1.7) of the "Figura 1" (figure 1) contained in | |||
the body, edited by the Italian Senate: | ||||
urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir-2.2: | ||||
senato.it:testo | ||||
urn:lex:it:stato:legge:2000-04-03;56$application-pdf;1.7: | ||||
senato.it:figura.1 | ||||
* The Spanish URN of the HTML format of the whole Judgment of the | ||||
European Court of Justice n. 33/08 of 11/06/2009, in Spanish | ||||
version, published in the Jurifast database in anonymized form: | ||||
urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33-08 | ||||
@original:es$text-html:juradmin.eu;jurifast:todo:anonimo | ||||
It is useful to be able to assign a uniform name to a manifestation | 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 | (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 | may be multimedia objects that are non-textual in their own right | |||
(e.g. geographic maps, photographs, etc.), or texts recorded in non- | (e.g., geographic maps, photographs, etc.) or texts recorded in non- | |||
textual formats, such as image scans of documents. | textual formats (e.g., image scans of documents). | |||
5.8. Sources of Law References | 5.8. Sources of Law References | |||
References to sources of law often refer to specific partitions of | References to sources of law often refer to specific partitions of | |||
the act (article, paragraph, etc.) and not to the entire document. | the act (article, paragraph, etc.) and not to the entire document. | |||
From a legal point of view, a partition is always a text block, that | From a legal point of view, a partition is always a text block that | |||
represents a logical subdivision of an act. | represents a logical subdivision of an act. | |||
As regards the digital representation, a partition is represented by | In the digital representation, a partition is represented by an | |||
an element (a block of text) with its own ID; this ID aims to | element (a block of text) with its own ID; this ID aims to identify | |||
identify the related element and to locate it. In this case, | the related element and locate it. Therefore, it is possible to | |||
therefore, it is possible either to extract or to point to a | either extract or point to a partition. | |||
partition. | ||||
In a mark-up not fitting the logical structure of the text (as HTML), | For markup that does not fit the logical structure of the text (like | |||
generally only the starting point of the partition, rather than the | HTML), generally only the starting point of the partition, rather | |||
whole block of text or element, is identified through a label (a <a | than the whole block of text or element, is identified through a | |||
id=partitionID></a> tag in Html Markup Language [W3C.HTML]). In this | label (e.g., <a id=partitionID></a> tag in the HTML markup language | |||
case therefore it is not possible to extract a partition but only to | [W3C.HTML]). In this case, it is only possible to point to a | |||
point to it. | partition but not extract it. | |||
Partitions should be assigned unique labels or IDs within the | Partitions should be assigned unique labels or IDs within the | |||
including document and their value should be the same regardless of | including document, and their value should be the same regardless of | |||
document format. | document format. | |||
For enabling the construction of the partition identifier between | To enable the construction of the partition identifier between | |||
different collections of documents, specific construction rules for | different collections of documents, specific construction rules for | |||
IDs or labels will be defined and shared, within each country or | IDs or labels will be defined and shared within each country or | |||
jurisdiction, for any document type | jurisdiction for any document type. For example, in legislation, | |||
(e.g., for legislation, the paragraph 2 of the article 3 might have | paragraph 2 of article 3 might have the value "art3;par2" as the | |||
as label or ID the value "art3;par2", similarly for case-law, | label or ID; similarly, for case law, paragraph 22 of the judgment in | |||
paragraph 22 of the judgment in Case 46/76 Bauhuis v Netherlands, | Case 46/76 Bauhuis v Netherlands might have the value "par22" as the | |||
might have as label or ID the value "par22"). | label or ID. | |||
Furthermore, it is useful to foresee the compatibility with | Furthermore, it is useful to foresee the compatibility with | |||
applications able to manage this information (e.g., returning the | applications that are able to manage this information (e.g., | |||
proper element); these procedures are particularly useful in the case | returning the proper element); these procedures are particularly | |||
of rather long acts, such as codes, constitutions, regulations, etc. | useful in the case of rather long acts, such as codes, constitutions, | |||
For this purpose it is necessary that the partition identifier is | regulations, etc. For this purpose, it is necessary that the | |||
transmitted to the servers (resolution and application) and therefore | partition identifier be transmitted to the servers (resolution and | |||
it cannot be separated by the typical "#" character of URI fragment, | application). Therefore, it cannot be separated by the typical "#" | |||
which is not transmitted to the server. | character of URI fragment, which is not transmitted to the server. | |||
According to these requirements, the syntax of a reference is: | According to these requirements, the syntax of a reference is: | |||
URN-reference = URN-document ["~" partition-id] | URN-reference = URN-document ["~" partition-id] | |||
(e.g., to refer to the paragraph 3 of the article 15 of the French | For example, referring to paragraph 3 of article 15 of the French Act | |||
Act of 15 May 2004, n. 106, the reference can be | 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 | Using a different separator ("~") from the document name, the | |||
partition ID is not withheld by the browser but it is transmitted to | partition ID is not withheld by the browser but is transmitted to the | |||
the resolution process. This enables the resolver to retrieve (for | resolution process. If the partition syntax is compatible with the | |||
example, out of a database) only the referred partition, if the | media type used, this enables the resolver to retrieve (for example, | |||
partition syntax is compatible with the media type used, otherwise to | out of a database) only the referred partition; otherwise, the whole | |||
return the whole act. | act is returned. | |||
When resolving to HTTP, the resolver SHALL transform the partition ID | When resolving to HTTP, the resolver SHALL transform the partition ID | |||
to an appropriate internal reference (#) in the page, or at the | to an appropriate internal reference (#) on the page or at the | |||
beginning if that point cannot be found. The transformation in URI | beginning if that point cannot be found. The transformation in the | |||
fragment is obtained appending to the URL the "#" character followed | URI fragment is obtained by appending the "#" character followed by | |||
by the partition ID (in the example above, the returned URL will be | the partition ID to the URL (in the example above, the returned URL | |||
<URL-document>#art15;par3). Doing this, knowing the granularity of | will be <URL-document>#art15;par3). Doing this, knowing the | |||
the act markup, the resolver could exploit the hierarchical structure | granularity of the act markup, the resolver could exploit the | |||
of the ID, eliminating sub-partitions not addressed. If only the | hierarchical structure of the ID by eliminating sub-partitions that | |||
article was identified in the act, in the previous example it could | are not addressed. In the previous example, if only the article was | |||
return <URL-document>#art15 only. | identified in the act, it could return <URL-document>#art15 only. | |||
It is possible to use the general syntax (with "#"); in this case | It is possible to use the general syntax (with "#"); in this case, | |||
only the URN document component of the reference is transmitted to | only the URN document component of the reference is transmitted to | |||
the resolver, therefore the whole document will always be retrieved. | the resolver; therefore, the whole document will always be retrieved. | |||
6. Specific Syntax of the Identifier at "Work" Level | 6. Specific Syntax of the Identifier at "Work" Level | |||
6.1. The authority Element | 6.1. The Authority Element | |||
6.1.1. Indication of the Authority | 6.1.1. Indication of the Authority | |||
The authority element of a uniform name may indicate, in the various | The authority element of a uniform name may indicate the following in | |||
cases: | the various cases: | |||
* the actual authority issuing the legal provision. More | * The actual authority issuing the legal provision. More | |||
specifically, the authority adopting the provision or enacting it; | specifically, the authority adopting the provision or enacting it. | |||
* the institution where the provision is registered, known and | * The institution where the provision is registered, known, and | |||
referenced to, even if produced by others (e.g., the bills | referenced to, even if produced by others (e.g., the bills | |||
identified through the reference to the Chamber where they are | identified through the reference to the Chamber where they are | |||
presented); | presented). | |||
* the institution regulated (and referred to in citations) by the | * The institution regulated (and referred to in citations) by the | |||
legal provision even when this is issued by another authority | legal provision even when this is issued by another authority | |||
(e.g., the statute of a Body); | (e.g., the statute of a Body). | |||
* the entity that proposed the legal material not yet included in | * The entity that proposed the legal material not yet included in | |||
the institutional process (e.g. a proposed bill written by a | the institutional process (e.g., a proposed bill written by a | |||
political party). | political party). | |||
6.1.2. Multiple Issuers | 6.1.2. Multiple Issuers | |||
Some sources of law are enacted by a number of issuing parties (e.g., | Some sources of law are enacted by a number of issuing parties (e.g., | |||
inter-ministerial decrees, agreements, etc.). In this case, the | inter-ministerial decrees, agreements, etc.). In this case, the | |||
authority element contains all the issuing parties (properly | authority element contains all the issuing parties (properly | |||
separated), as follows: | separated) as follows: | |||
authority = issuer *("+" issuer) | authority = issuer *("+" issuer) | |||
(e.g., "ministry.justice+ministry.finances"). | This is an example: "ministry.justice+ministry.finances". | |||
6.1.3. Indication of the Issuer | 6.1.3. Indication of the Issuer | |||
Each issuing authority is essentially represented by either an | Each issuing authority is essentially represented by either an | |||
institutional office (e.g., Prime Minister) or an institution (e.g., | institutional office (e.g., Prime Minister) or an institution (e.g., | |||
Ministry); in the last case, the authority is indicated in accordance | Ministry); in the last case, the authority is indicated in accordance | |||
with the institution's hierarchical structure, from the more general | with the institution's hierarchical structure, from more general to | |||
to more specific (Council, Department, etc.), ending with the | more specific (Council, Department, etc.), ending with the relative | |||
relative office (President, Director, etc.). Therefore, the | office (President, Director, etc.). Therefore, the structure of the | |||
structure of the issuer is as follows: | issuer is as follows: | |||
issuer = (institution *(";" body-function)) / office | 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 | 6.1.4. Indication of the Body | |||
Depending on the kind of measure, the body within the issuing | Depending on the kind of measure, the body within the issuing | |||
authority is unambiguously determined (e.g., the Council for Regional | authority is unambiguously determined (e.g., the Council for Regional | |||
Acts) and normally it is not indicated in the references. Just like | Acts), and it is not normally indicated in the references. Just like | |||
in practice, the indication of the enacting authority is limited to | in practice, the indication of the enacting authority is limited to | |||
the minimum in relation to the type of measure | the minimum in relation to the type of measure (e.g., | |||
(e.g., "region.tuscany:act" and not "region.tuscany;council:act"). | "region.tuscany:act" and not "region.tuscany;council:act"). | |||
6.1.5. Indication of the Function | 6.1.5. Indication of the Function | |||
Generally, the function is indicated, sometimes instead of the body | Generally, the function is indicated, sometimes instead of the body | |||
itself: | itself: | |||
* in case of political, representative or elective offices | * In the case of political, representative, or elective offices | |||
(e.g., "university.oxford;rector:decree" instead of | (e.g., "university.oxford;rector:decree" instead of | |||
"university.oxford;rectorship:decree"); | "university.oxford;rectorship:decree"). | |||
* when it refers to a top officer in the institution (e.g., general | * When referring to a top officer in the institution (e.g., general | |||
manager, general secretary, etc.) which is not always possible to | manager, general secretary, etc.), which is not always possible to | |||
associate a specific internal institutional structure to | associate a specific internal institutional structure to (e.g., | |||
(e.g., "national.council.research;general.manager"). | "national.council.research;general.manager"). | |||
It is not indicated when it clearly corresponds to the person in | It is not indicated when it clearly corresponds to the person in | |||
charge of an institution (typically, a general director); in this | charge of an institution (typically, a general director); in this | |||
case, only the structure and not the person in charge is indicated | case, only the structure and not the person in charge is indicated | |||
(e.g., "ministry.justice;department.penitentiary.administration"). | (e.g., "ministry.justice;department.penitentiary.administration"). | |||
The function MUST be indicated when: | The function MUST be indicated when: | |||
* it is not the same of the director or the person in charge of the | * It is not the same as the director or the person in charge of the | |||
structure (for example, in case of an undersecretary, a deputy | structure (for example, an undersecretary, a deputy director, | |||
director, etc.); | etc.). | |||
* the type of measure may be both monocratic or collegial: the | * The type of measure may be both monocratic or collegial; the | |||
indication of the office eliminates the ambiguity. | indication of the office eliminates the ambiguity. | |||
6.1.6. Conventions for the Authority | 6.1.6. Conventions for the Authority | |||
Acts and measures bearing the same relevance as an act, issued or | Acts and measures bearing the same relevance as an act, issued or | |||
enacted since the foundation of the State, have conventionally | enacted since the foundation of the State, have conventionally | |||
indicated "state" (expressed in each country official language) as | indicated "state" (expressed in each country's official language) as | |||
authority; the same convention is used for constitutions, codes | the authority. The same convention is used for constitutions, codes | |||
(civil, criminal, civil procedure, criminal procedure, etc) and | (civil, criminal, civil procedure, criminal procedure, etc.), and | |||
international treaties. | international treaties. | |||
6.2. The measure Element | 6.2. The Measure Element | |||
6.2.1. Criteria for the Indication of the Type of Measure | 6.2.1. Criteria for the Indication of the Type of Measure | |||
In uniform names the issuing authority of a document is mandatory. | In uniform names, the issuing authority of a document is mandatory. | |||
This makes unnecessary to indicate any further qualification of the | This makes it unnecessary to indicate any further qualification of | |||
measure (e.g., ministerial decree, directorial ordinance, etc.), even | the measure (e.g., ministerial decree, directorial ordinance, etc.), | |||
if it is widely used. When the authority-measure combination clearly | even if it is widely used. When the authority-measure combination | |||
identifies a specific document, the type of measure is not defined | clearly identifies a specific document, the type of measure is not | |||
through attributes referring to the enacting authority | defined through attributes referring to the enacting authority (e.g., | |||
(e.g., "region.tuscany:act" and not "region.tuscany:regional.act"). | "region.tuscany:act" and not "region.tuscany:regional.act"). | |||
6.2.2. Further Specification to the Type of Measure | 6.2.2. Further Specification to the Type of Measure | |||
In the measure element, it is usually sufficient to indicate the type | In the measure element, it is usually sufficient to indicate the type | |||
of a measure. As usual, references to sources of law, rather than | of a measure. As usual, rather than through the formal details (date | |||
through the formal details (date and number), may be made through | and number), references to sources of law may be made through some of | |||
some of their characteristics such as the subject-matter covered | their characteristics, such as the subject matter covered (e.g., | |||
(e.g., accounting regulations), nicknames referring to the promoter | accounting regulations), nicknames referring to the promoter (e.g., | |||
(e.g., Bolkestein directive) or to the topic of the act (e.g., | Bolkestein directive), or the topic of the act (e.g., Bankruptcy | |||
Bankruptcy Law), etc.. In these cases, the type of measure MAY be | Law), etc. In these cases, the type of measure MAY be followed by | |||
followed by further specifications useful in referencing even if the | further specifications that are useful in referencing, even if the | |||
details are lacking: | details are lacking: | |||
measure = measure-type *(";" specification) | measure = measure-type *(";" specification) | |||
(e.g., "regulations;accounting" or "act;bankruptcy"). | These are examples: "regulations;accounting" or "act;bankruptcy". | |||
6.2.3. Aliases for Sources of Law with Different Normative References | 6.2.3. Aliases for Sources of Law with Different Normative References | |||
There are legislative measures that, although unique, are usually | There are legislative measures that, although unique, are usually | |||
cited in different ways, for example through the legislative act | cited in different ways, for example, introducing them into the legal | |||
introducing them into the legal order (President's decree, | order through a legislative act (President's decree, legislative | |||
legislative decree, etc.) or through their legislative category | decree, etc.) or through their legislative category (regulations, | |||
(regulations, consolidation, etc.). In order to ensure, in all the | consolidation, etc.). In order to ensure the validity of the | |||
cases, the validity of the references, an alias (additional URN LEX | references in all cases, an alias (an additional URN LEX identifier) | |||
identifier), that takes into account the measure category, is added | that takes into account the measure category is added to what | |||
to what represents the legislative form of the same act | represents the legislative form of the same act (e.g., | |||
(e.g., "state:decree.legislative:1992-07-24;358" and | "state:decree.legislative:1992-07-24;358" and | |||
"state:consolidation;public.contracts:1992-07-24;358"). | "state:consolidation;public.contracts:1992-07-24;358"). | |||
6.2.4. Relations between Measure and Authority in the Aliases | 6.2.4. Relations Between Measure and Authority in the Aliases | |||
The sources of law including different normative references are | The sources of law including different normative references are | |||
usually introduced in legislation through the adoption or the issuing | usually introduced in legislation through the adoption or the issuing | |||
of an act, which they are either included or attached to. It is, | of an act, which they are either included or attached to. Therefore, | |||
therefore, necessary to create an alias linking the two aspects of | it is necessary to create an alias linking the two aspects of the | |||
the same document. Specifically, the different measures can be: | same document. Specifically, the different measures can be: | |||
* adopted/issued by an authority different from the one regulated by | * Adopted/issued by an authority different from the one regulated by | |||
the provision (e.g., the statute of a Body); in this case, the | the provision (e.g., the statute of a Body). In this case, the | |||
correlation is established between two uniform names each | correlation is established between two uniform names, each | |||
featuring a completely different authority element | featuring a completely different authority element (e.g., | |||
(e.g., "italian.society.authors.publishers:statute" and | "italian.society.authors.publishers:statute" and | |||
"ministry.cultural.activities+ministry.finances.budget.economic. | "ministry.cultural.activities+ministry.finances.budget.economic. | |||
planning:decree"); | planning:decree"). | |||
* issued by the institution itself either because it has issuing | * Issued by the institution itself either because it has issuing | |||
authority or by virtue of a proxy (e.g., a provision that refers | authority or by virtue of a proxy (e.g., a provision that refers | |||
to the functioning of the Body itself); in this case, the two | to the functioning of the Body itself). In this case, the two | |||
aliases share the first part of the authority | aliases share the first part of the authority (e.g., | |||
(e.g., "municipality.firenze:statute" and | "municipality.firenze:statute" and | |||
"municipality.firenze;council:deliberation"); | "municipality.firenze;council:deliberation"). | |||
* issued by the same Body to regulate a particular sector of its own | * Issued by the same Body to regulate a particular sector of its own | |||
competence; in this case the authority element is the same | competence. In this case, the authority element is the same | |||
(e.g., "ministry.justice:regulation;use.information.tools. | (e.g., "ministry.justice:regulation;use.information.tools. | |||
telematic.process" and "ministry.justice:decree"). | telematic.process" and "ministry.justice:decree"). | |||
6.3. The Details Element | 6.3. The Details Element | |||
6.3.1. Indication of the Details | 6.3.1. Indication of the Details | |||
The details of a source of law usually include the date of the | The details of a source of law usually include the date of the | |||
enactment and the identification number (inclusion in the body of | enactment and the identification number (inclusion in the body of | |||
laws, register, protocol, etc.). | laws, register, protocol, etc.). | |||
Some measures can have multiple dates; there are also cases in which | Some measures can have multiple dates. There are also cases in which | |||
the number of the measure does not exist (unnumbered measures) or a | the number of the measure does not exist (unnumbered measures) or a | |||
measure has multiple numbers (e.g., unified cases). For these | measure has multiple numbers (e.g., unified cases). For these | |||
reasons, the set up of both elements (date and number) includes | reasons, the setup of both elements (date and number) includes | |||
multiple values. | multiple values. | |||
Some institutions (e.g., the Parliaments) usually identify documents | Some institutions (e.g., the Parliaments) usually identify documents | |||
through their period of reference (e.g., the legislature number) | through their period of reference (e.g., the legislature number) | |||
rather than through a date, which would be much less meaningful and | 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 | never used in references (e.g., Senate bill S.2544 of the XIV | |||
legislature). In these cases, the component period is used in | legislature). In these cases, the component period is substitued for | |||
substitution of the component dates. | the component dates. | |||
Usually details of a measure are not reported according to a specific | Usually, details of a measure are not reported according to a | |||
sequence; in accordance with the global structure of the uniform | specific sequence. In accordance with the global structure of the | |||
name, which goes from the general to the specific, the sequence date- | uniform name, which goes from general to specific, the sequence date- | |||
number has the following form: | number has the following form: | |||
details = (dates / period) ";" numbers | 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 | 6.3.2. Multiple Dates | |||
Some sources of law, even if unique, are identified by more than one | Some sources of law, even if unique, are identified by more than one | |||
date; in this case, in the field dates all the given dates are to be | date. In this case, all the given dates are to be reported and | |||
reported and indicated as follows: | indicated as follows: | |||
dates = date *("," date) | dates = date *("," date) | |||
(e.g., the measure of the Data Protection Authority of December 30, | For example, the measure of the Data Protection Authority of December | |||
1999-January 13, 2000, No. 1/P/2000 has the following uniform name: | 30, 1999-January 13, 2000, No. 1/P/2000 has the following uniform | |||
"personal.data.protection.authority:measure:1999-12-30,2000-01-13; | name: | |||
1-p-2000"). | ||||
As specified in Section 3.6, all the dates can have, in addition to | personal.data.protection.authority:measure:1999-12-30,2000-01- | |||
the ISO format, also the date typical of the jurisdiction. | 13;1-p-2000 | |||
As specified in Section 3.6, all the dates can have the date typical | ||||
of the jurisdiction in addition to the ISO format. | ||||
6.3.3. Unnumbered Measures | 6.3.3. Unnumbered Measures | |||
Measures not officially numbered in the publications may have a non- | Measures not officially numbered in the publications may have a non- | |||
unequivocal identifier, because several measures of the same type can | unequivocal identifier, because several measures of the same type can | |||
exist, issued on the same day by the same authority. To ensure that | exist and can be issued on the same day by the same authority. To | |||
the uniform name is unambiguous, the numbers field MUST, in any case, | ensure that the uniform name is unambiguous, the numbers field MUST, | |||
contain a discriminating element, which can be any identifier used | in any case, contain a discriminating element, which can be any | |||
internally, and not published, by the authority (e.g., protocol). | identifier used internally and not published by the authority (e.g., | |||
protocol). | ||||
If the authority does not have its own identifier, one identifier | If the authority does not have its own identifier, one identifier | |||
MUST be created for the name system. In order to easily | MUST be created for the name system. In order to easily | |||
differentiate it, such number is preceded by the string "lex-": | differentiate it, such number is preceded by the string "lex-": | |||
number-lex = "lex-" 1*DIGIT | 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 responsibility of the authority issuing a document to assign a | It is the responsibility of the authority issuing a document to | |||
discriminating specification to it; in case of multiple authorities, | assign a discriminating specification to it. When there are multiple | |||
only one of them is responsible for the assignment of the number to | authorities, only one of them is responsible for the assignment of | |||
the document (e.g., the proponent). | the number to the document (e.g., the proponent). | |||
The unnumbered measures published on an official publication (e.g., | The unnumbered measures published on an official publication (e.g., | |||
the Official Gazette), instead of by a progressive number are | the Official Gazette), are recognized by the univocal identifying | |||
recognized by the univocal identifying label printed on the paper. | label printed on the paper instead of by a progressive number. Such | |||
Such an identifier, even if unofficial but assigned to a document in | 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 | an official publication, is preferred because it has the clear | |||
advantage to be public and therefore easier to be found. | advantage of being public and is therefore easier to find. | |||
6.3.4. Multiple Numbers | 6.3.4. Multiple Numbers | |||
Some legal documents (e.g., bills), even if unique, are identified by | 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 | a set of numbers (e.g., the unification of cases or bills). In this | |||
case, in the numbers field, all the identifiers are reported, | case, in the numbers field, all the identifiers are reported, | |||
according to the following structure: | according to the following structure: | |||
numbers = document-id *("," document-id) | 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 are not allowed (e.g., "/") or reserved (e.g., | The characters that are not allowed (e.g., "/") or reserved (e.g., | |||
":"), including the comma, cannot exist inside the document-id, and | ":"), including the comma, cannot exist inside the document-id and | |||
therefore MUST be turned into "-". | therefore MUST be turned into "-". | |||
Where special characters contained in the number of the act are | When special characters contained in the number of the act are | |||
distinctive of the act itself (e.g. bill n. 123-bis (removal of 123) | distinctive of the act itself (e.g., bill n. 123-bis (removal of 123) | |||
and n. 123/bis (return of 123)) and would disappear with the | and n. 123/bis (return of 123)) and would disappear with the | |||
conversion to "-", a further ending must be added, allowing to | conversion to "-", a further ending must be added to distinguish the | |||
distinguish the acts (e.g. bill n.123-bis-removal and 123-bis- | acts (e.g., bill n.123-bis-removal and 123-bis-return). | |||
return). | ||||
6.4. The annex Element | 6.4. The Annex Element | |||
6.4.1. Formal Annexes | 6.4.1. Formal Annexes | |||
Although annexes are an integral part of the legal document, they may | Although annexes are an integral part of a legal document, they may | |||
be referred to and undergo amendments separately from the act to | be referred to and undergo amendments separately from the act to | |||
which they are annexed. It is, therefore, necessary that both the | which they are annexed. Therefore, it is necessary that both the | |||
main document as well as each formal individual annex is | main document as well as each formal individual annex is | |||
unequivocally identified. | unequivocally identified. | |||
Formal annexes may be registered as separate parts or together with a | Formal annexes may be registered as separate parts or together with a | |||
legal provision; they may also be autonomous in nature or not. In | legal provision; they may or may not be autonomous in nature. In any | |||
any case, they MUST be given a uniform name, which includes the | case, they MUST be given a uniform name that includes the uniform | |||
uniform name of the source of law to which they are attached, and a | name of the source of law to which they are attached and a suffix | |||
suffix which identifies the annex itself. | that identifies the annex itself. | |||
The suffix of formal annexes includes the official heading of the | The suffix of formal annexes includes the official heading of the | |||
annex and, possibly, further specifications (e.g., the title) which | annex and, possibly, further specifications (e.g., the title) that | |||
will facilitate the retrieval of the annex in case the identifier is | will facilitate the retrieval of the annex in case the identifier is | |||
missing: | missing: | |||
annex = annex-id *(";" specification) | annex = annex-id *(";" specification) | |||
(e.g., "region.sicily;council:deliberation:1998-02-12;14:annex.a; | The following is an example: | |||
borders.park"). | ||||
The characters which are not allowed (e.g. "/") or which are reserved | region.sicily;council:deliberation:1998-02-12;14:annex.a; | |||
(e.g. ":") must not be featured in the annex-id and therefore MUST be | borders.park | |||
turned into ".". | ||||
The characters that are not allowed (e.g., "/") or that are reserved | ||||
(e.g., ":") must not be featured in the annex-id and therefore MUST | ||||
be turned into ".". | ||||
6.4.2. Annexes of Annexes | 6.4.2. Annexes of Annexes | |||
When there are annexes to an annex, their corresponding identifiers | When there are annexes to an annex, their corresponding identifiers | |||
are created by adding to the identifier of the original annex those | 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) | of the annexes that are connected with it (that is, attached to it). | |||
(e.g., Table 1 attached to the Annex A of the preceding legal act has | For example, Table 1 attached to the Annex A of the preceding legal | |||
the following uniform name: | 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. Specific Syntax of the Version Element of the "Expression" | |||
7.1. The version Element | 7.1. The Version Element | |||
7.1.1. Different Versions of a Legislative Document | 7.1.1. Different Versions of a Legislative Document | |||
The creation of an updated text of a document may have one of the | The creation of an updated text of a document may have one of the | |||
following forms: | following forms: | |||
* "multi-version": when specific mark-ups which identify the | "multi-version": Specific markups that identify the modified parts | |||
modified parts of a document (added, substituted or deleted parts) | of a document (added, substituted, or deleted parts) and their | |||
and their related periods of effectiveness are indicated inside | related periods of effectiveness are indicated inside a single | |||
one single object (e.g., an xml file). Such a document will be | object (e.g., an XML file). Such a document will be able, in a | |||
able, in a dynamic way, to appear in different forms according to | dynamic way, to appear in different forms according to the | |||
the requested date of effectiveness. In this document type, | requested date of effectiveness. In this document type, a set of | |||
usually a set of metadata contains the lifecycle of the document | metadata usually contains the life cycle of the document (from the | |||
(from the original to the last modification), including the | original to the last modification), including the validity time | |||
validity time interval of each version and of each related text | interval of each version and of each related text portion. | |||
portion; | ||||
* "single-version": when, on the contrary, a new and distinct object | "single-version": A new and distinct object is created for each | |||
is created for each amendment to the text at a given time. Each | amendment to the text at a given time. Each object is, therefore, | |||
object is, therefore, characterized by its own period of validity. | characterized by its own period of validity. In any case, all the | |||
In any case all the versions SHOULD be linked one another and | versions SHOULD be linked to one another and immediately | |||
immediately navigable. | navigable. | |||
In a "multi-version" document, each time interval should have a link | In a "multi-version" document, each time interval should have a link | |||
to the related in-force document version which can be therefore | to the related in-force document version that can be displayed. In a | |||
displayed. In a "single-version" document, the metadata should | "single-version" document, the metadata should contain links to all | |||
contain links to all the previous modifications and a link only to | the previous modifications and a link only to the following version, | |||
the following version, if any. | if any. | |||
[RFC8288] can be used as reference to establish links between | [RFC8288] can be used as a reference to establish links between | |||
different document versions, either in the "multi-version" or in the | different document versions, either in the "multi-version" or in the | |||
"single-version" document. According to [RFC8288] the following | "single-version" document. According to [RFC8288], the following | |||
relations are useful: | relations are useful: | |||
* current (or last or last-version): in-force version | current (or last or last-version): in-force version | |||
* self: this version | self: this version | |||
* next: next version | next: next version | |||
* previous: previous version | previous: previous version | |||
* first: original version | first: original version | |||
It is RECOMMENDED that these relations are inserted in the header of | ||||
It is RECOMMENDED that these relations be inserted in the header of | ||||
each version (if "single-version") or associated to each entry | each version (if "single-version") or associated to each entry | |||
containing a single URN (if "multi-version"). | containing a single URN (if "multi-version"). | |||
7.1.2. Identification of the Version | 7.1.2. Identification of the Version | |||
In order to identify the different time versions of the same act, to | In order to identify the different time versions of the same act, a | |||
the uniform name of the original document has to be added a specific | specific suffix has to be added to the uniform name of the original | |||
suffix. | document. | |||
Such a suffix identifies each version of a legal provision and | Such a suffix identifies each version of a legal provision and | |||
includes, first and foremost, one of the following elements: | includes, first and foremost, one of the following elements: | |||
* the issuing date of the last amending measure taken into account; | * The issuing date of the last amending measure taken into account. | |||
* the date in which the communication of the rectification or of the | * The date that the communication of the rectification or errata | |||
errata corrige, is published; | corrige was published. | |||
* a specification which must identify the reason concerning the | * A specification that must identify the reason concerning the | |||
amendment (e.g., the specific phase of the legislative process), | amendment (e.g., the specific phase of the legislative process), | |||
for the cases in which the date is not usually used (e.g., bills). | for the cases in which the date is not usually used (e.g., bills). | |||
It is possible to add further specifications that will distinguish | It is possible to add further specifications that will distinguish | |||
each of the different versions of the text to guarantee identifier | each of the different versions of the text to guarantee identifier | |||
unequivocalness. For example with regard to changes of the in-force | unequivocalness. For example with regard to changes of the in-force | |||
or effectiveness of any partition or portion of the text itself | or effectiveness of any partition or portion of the text itself | |||
(e.g., when the amendments introduced by an act are applied at | (e.g., when the amendments introduced by an act are applied at | |||
different times) or different events occurring on the same date. | different times) or different events occurring on the same date. | |||
version = (amendment-date / specification) | version = (amendment-date / specification) | |||
*(";" (event-date / event)) | *(";" (event-date / event)) | |||
where: | where: | |||
* amendment-date contains the issuing date of the last considered | amendment-date: Contains the issuing date of the last considered | |||
amendment or of the last communication of amendment. In case the | amendment or of the last communication of amendment. If the | |||
original text introduces differentiated periods in which an act is | original text introduces differentiated periods in which an act is | |||
effective and the information system produces one version for each | effective and the information system produces one version for each | |||
of them, such element contains the string "original" expressed in | of them, such element contains the string "original" expressed in | |||
the language of the act or version; | the language of the act or version. | |||
* specification contains any information useful to identify | specification: Contains any information that is useful to identify | |||
unambiguously and univocally the version; | the version unambiguously and univocally. | |||
* event-date contains the date in which a version is put into force, | event-date: Contains the date in which a version is put into force, | |||
is effective or is published; | is effective, or is published. | |||
* event is a name assigned to the event producing a further version | event: A name assigned to the event producing a further version | |||
(e.g., amendment, decision, etc.). | (e.g., amendment, decision, etc.). | |||
The issuing date of an amending act was chosen as identifier of a | 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) | version because it can be obtained from the heading (formal data). | |||
(e.g., the name "state:royal.decree:1941-01-30;12@1998-02-19" | 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. | 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, | 12" with the amendments introduced by the "Law Decree of 19/2/1998, | |||
No. 51", without any indication of its actual entry into force. | No. 51" without any indication of its actual entry into force. The | |||
The same uniform name with the additional ending ";1999-01-01" | same uniform name with the additional ending ";1999-01-01" indicates | |||
indicates the in-force or effective version starting in a different | the in-force or effective version starting on a different date | |||
date (from 1/1/99). | (1/1/99). | |||
For a full compatibility, every updating of a text or of the | For full compatibility, every update of text or of the effectiveness | |||
effectiveness of a "multi-version" document implies the creation of a | of a "multi-version" document implies the creation of a new uniform | |||
new uniform name, even if the object remains only one, containing the | name, even if the object remains only one, containing the identifier | |||
identifier of the virtually generated version, exactly as in the case | of the virtually generated version, exactly as in the case of a | |||
of a "single-version" document. A specific meta-data will associate | "single-version" document. Specific metadata will associate every | |||
every uniform name with the period of time during which such a name | uniform name with the period of time during which such a name, | |||
together with its corresponding text is to be considered valid | together with its corresponding text, is to be considered valid | |||
(e.g., the multi-version document containing the "R.D. of 01/30/1941, | (e.g., the "multi-version" document containing "R.D. of 01/30/1941, | |||
no. 12", updated by the amendments introduced by the "D.Lgs. of | no. 12", updated by the amendments introduced by the "D.Lgs. of | |||
02/19/1998, no. 51", contains the name of the original | 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 | "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"). | version "state:royal.decree:1941-01-30;12@1998-02-19"). | |||
Please note that in case of attachments or annexes, the creation of a | Note that if there are attachments or annexes, the creation of a new | |||
new version (even in the case of only one component) would imply the | 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 | creation of a new uniform name for all the connected objects in order | |||
to guarantee their alignment (i.e., the main document, the | to guarantee their alignment (i.e., the main document, attachments, | |||
attachments and annexes). | and annexes). | |||
As specified in Section 3.6, all the dates can have, in addition to | As specified in Section 3.6, all the dates can have the date typical | |||
the ISO format, also the date typical of the jurisdiction. | of the jurisdiction in addition to the date in ISO format. | |||
8. Summary of the Syntax of the Uniform Names of the "lex" Namespace | 8. Summary of the Syntax of the Uniform Names of the "lex" Namespace | |||
;------------------------------------------------------------------- | ;------------------------------------------------------------------- | |||
; Structure of a Uniform Resource Name (URN) of the "lex" namespace | ; Structure of a Uniform Resource Name (URN) of the "lex" namespace | |||
; - NID-lex = namespace | ; - NID-lex = namespace | |||
; - NSS-lex = specific name | ; - NSS-lex = specific name | |||
;------------------------------------------------------------------- | ;------------------------------------------------------------------- | |||
URN-lex = "urn:" NID-lex ":" NSS-lex | URN-lex = "urn:" NID-lex ":" NSS-lex | |||
skipping to change at page 39, line 50 ¶ | skipping to change at line 1889 ¶ | |||
date-iso = year "-" month "-" day | date-iso = year "-" month "-" day | |||
year = 4DIGIT | year = 4DIGIT | |||
month = 2DIGIT | month = 2DIGIT | |||
day = 2DIGIT | day = 2DIGIT | |||
date-loc = *(alfadot / other) | date-loc = *(alfadot / other) | |||
;------------------------------------------------------------------- | ;------------------------------------------------------------------- | |||
; Allowed, reserved and future characters | ; Allowed, reserved, and future characters | |||
;------------------------------------------------------------------- | ;------------------------------------------------------------------- | |||
; - allowed = alfadot / other / reserved | ; - allowed = alfadot / other / reserved | |||
; - reserved = ":" / "@" / "$" / "+" / "|" / ";" / "," / "~" | ; - reserved = ":" / "@" / "$" / "+" / "|" / ";" / "," / "~" | |||
; - future = "*" / "!" | ; - future = "*" / "!" | |||
alf-dot = alfanum *alfadot | alf-dot = alfanum *alfadot | |||
alf-dot-hyp = alfanum *(alfadot / "-") | alf-dot-hyp = alfanum *(alfadot / "-") | |||
alf-dot-oth = alfanum *(alfadot / other) | alf-dot-oth = alfanum *(alfadot / other) | |||
alfadot = alfanum / "." | alfadot = alfanum / "." | |||
alfa = lowercase / uppercase | alfa = lowercase / uppercase | |||
skipping to change at page 40, line 31 ¶ | skipping to change at line 1918 ¶ | |||
uppercase = %x41-5A ; upper-case ASCII letters (A-Z) | uppercase = %x41-5A ; upper-case ASCII letters (A-Z) | |||
DIGIT = %x30-39 ; decimal digits (0-9) | DIGIT = %x30-39 ; decimal digits (0-9) | |||
encoded = "%" 2HEXDIG | encoded = "%" 2HEXDIG | |||
HEXDIG = DIGIT / %x41-46 / %x61-66 ; hex digits (0-9,A-F,a-f) | HEXDIG = DIGIT / %x41-46 / %x61-66 ; hex digits (0-9,A-F,a-f) | |||
other = "-" / "_" / "'" / "=" / "(" / ")" | other = "-" / "_" / "'" / "=" / "(" / ")" | |||
9. The Procedure of Uniform Names Assignment | 9. Procedure of Uniform Names Assignment | |||
9.1. Specifying the jurisdiction Element of the LEX Identifier | 9.1. Specifying the Jurisdiction Element of the LEX Identifier | |||
Under the "lex" namespace, each country or international organization | Under the "lex" namespace, each country or international organization | |||
is assigned with a jurisdiction code, which characterizes the URNs of | is assigned a jurisdiction code, which characterizes the URNs of the | |||
the source of law of that country or jurisdiction. This code is | source of law of that country or jurisdiction. This code is assigned | |||
assigned according to ccTLD (as well as TLDN (Top Level Domain Name) | according to ccTLD (as well as TLDN (Top-Level Domain Name) or DN | |||
or DN (Domain Name) for the organizations) representation and it is | (Domain Name) for organizations) representation, and it is the value | |||
the value of the jurisdiction-code element, which preserves cross- | of the jurisdiction-code element, which preserves cross-country | |||
country uniqueness of the identifiers. | uniqueness of the identifiers. | |||
9.2. Jurisdictional Registrar for Names Assignment | 9.2. Jurisdictional Registrar for Names Assignment | |||
Any country or jurisdiction, who intends to adopt this schema, MUST | Any country or jurisdiction that intends to adopt this schema MUST | |||
identify a Jurisdictional Registrar, an organization which shares and | identify a Jurisdictional Registrar, an organization that shares and | |||
defines the structure of the optional part (jurisdiction-unit) of the | defines the structure of the optional part (jurisdiction-unit) of the | |||
name, according to the organization of the state or institution (for | name, according to the organization of the state or institution (for | |||
details see Section 2.2). It must appoint a Jurisdictional Registrar | details, see Section 2.2). It must appoint a Jurisdictional | |||
and inform the Designed Experts, together with the registration of a | Registrar and inform the Designed Experts, together with the | |||
jurisdiction code. For example, in a federal state a jurisdiction- | registration of a jurisdiction code. For example, in a federal | |||
unit corresponding to the name of each member state | state, a jurisdiction-unit corresponding to the name of each member | |||
(e.g. "br;sao.paulo", "br;minas.gerais", etc.) may be defined. | state (e.g., "br;sao.paulo", "br;minas.gerais", etc.) may be defined. | |||
The process of assigning the local-name is managed by each specific | The process of assigning the local-name is managed by each specific | |||
country or jurisdiction under the related jurisdiction element. | country or jurisdiction under the related jurisdiction element. | |||
In any country the Jurisdictional Registrar shares and defines the | In any country, the Jurisdictional Registrar shares and defines the | |||
assignment of the primary elements (issuing authority and type of | assignment of the primary elements (issuing authority and type of | |||
legal measure) of the local names considering the characteristics of | legal measure) of the local names considering the characteristics of | |||
its own state or institution organization. | its own state or institution organization. | |||
Such a Registrar MUST establish, according to the guidelines | The Jurisdictional Registrar MUST establish, according to the | |||
indicated in this document, a uniform procedure within the country or | guidelines indicated in this document, a uniform procedure within the | |||
organization to define local-name elements, to take decisions upon | country or organization to define local-name elements, make decisions | |||
normalizations and finally to solve and avoid possible name | about normalizations, solve and avoid possible name collisions, and | |||
collisions as well as to maintain authoritative registries of various | maintain authoritative registries of various kinds (e.g., for | |||
kinds (e.g., for authorities, types of measures, etc.). In | authorities, types of measures, etc.). In particular, accurate | |||
particular, accurate point-in-time representations of the structure | point-in-time representations of the structure and naming of | |||
and naming of government entities are important to semantically-aware | government entities are important to semantically aware applications | |||
applications in this domain. | in this domain. | |||
Moreover, the Registrar shares and defines the rules to construct | Moreover, the Jurisdictional Registrar shares and defines the rules | |||
partition IDs for each document type, possibly in accordance with | to construct partition IDs for each document type, possibly in | |||
those already defined in other jurisdictions. | accordance with those already defined in other jurisdictions. | |||
Finally, the Registrar will develop and publish the rules and the | Finally, the Jurisdictional Registrar will develop and publish the | |||
guidelines for the local-name construction as well as the predefined | rules and guidelines for the local-name construction as well as the | |||
values and codes. The Registrar should also promote the urn:lex | predefined values and codes. The Jurisdictional Registrar should | |||
identifier for the sources of law of its jurisdiction. | 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 | Such a set of rules will have to be followed by all institutional | |||
bodies adopting the URN LEX identification system in a country or | bodies adopting the URN LEX identification system in a country or | |||
jurisdiction, as well as by private publishers, and each of them will | jurisdiction, as well as by private publishers. Each of them will be | |||
be responsible for assigning names to their domains. | responsible for assigning names to their domains. | |||
9.3. Identifier Uniqueness | 9.3. Identifier Uniqueness | |||
Identifiers in the "lex" namespace are defined through a jurisdiction | Identifiers in the "lex" namespace are defined through a jurisdiction | |||
element assigned to the sources of law of a specific country or | element assigned to the sources of law of a specific country or | |||
organization, and a local-name assigned by the issuing authority, in | organization, and a local-name is assigned by the issuing authority | |||
conformance with the syntax defined in Section 5. The main elements | in conformance with the syntax defined in Section 5. The main | |||
(authority and type of measure) of the local-name are defined by the | elements (authority and type of measure) of the local-name are | |||
Jurisdictional Registrar, so that it is ensured that the constructed | defined by the Jurisdictional Registrar, so that it is ensured that | |||
URNs are unique. The Jurisdictional Registrar MUST provide clear | the constructed URNs are unique. The Jurisdictional Registrar MUST | |||
documentation of rules by which names are to be constructed, and MUST | provide clear documentation of rules by which names are to be | |||
update and make accessible its registries. | constructed and MUST update its registries and make them accessible. | |||
Any enacting authority is responsible to define formal parameters to | Any enacting authority is responsible for defining formal parameters | |||
guarantee local name uniqueness by attributing, if necessary, a | to guarantee local name uniqueness by attributing, if necessary, a | |||
conventional internal number, which, combined with the other local- | conventional internal number, which when combined with the other | |||
name components (authority, measure and date), builds a unique | local-name components (authority, measure, and date), builds a unique | |||
identifier. Uniqueness is achieved by checking against the catalogue | identifier. Uniqueness is achieved by checking against the catalogue | |||
of previously assigned names. | of previously assigned names. | |||
9.4. Identifier Persistence Considerations | 9.4. Identifier Persistence Considerations | |||
The persistence of identifiers depends on the durability of the | The persistence of identifiers depends on the durability of the | |||
institutions that assign and administer them. The goal of the LEX | institutions that assign and administer them. The goal of the LEX | |||
schema is to maintain uniqueness and persistence of all resources | schema is to maintain uniqueness and persistence of all resources | |||
identified by the assigned URNs. | identified by the assigned URNs. | |||
In particular, the CNR is responsible of maintaining the uniqueness | In particular, CNR is responsible for maintaining the uniqueness of | |||
of the jurisdiction element; given that the jurisdiction is assigned | the jurisdiction element. Given that the jurisdiction is assigned on | |||
on the basis of the long-held ccTLD representation of the country (or | the basis of the long-held ccTLD representation of the country (or | |||
the TLDN or DN of the organization) and that the country or | the TLDN or DN of the organization) and that the associated code for | |||
organization associated code is expected to continue indefinitely, | country or organization is expected to continue indefinitely, the URN | |||
the URN also persists indefinitely. | also persists indefinitely. | |||
The rules for the construction of the name are conceived to delegate | The rules for the construction of the name are conceived to delegate | |||
the responsibility of their uniqueness to a set of authorities which | the responsibility of their uniqueness to a set of authorities that | |||
is identified within each country or organization. | is identified within each country or organization. | |||
Therefore, each authority is responsible for assigning URNs which | Therefore, each authority is responsible for assigning URNs that have | |||
have a very long life expectancy and can be expected to remain unique | a very long life expectancy and can be expected to remain unique for | |||
for the foreseeable future. Practical and political considerations, | the foreseeable future. Practical and political considerations, as | |||
as well as diverse local forms of government organization, will | well as diverse local forms of government organization, will result | |||
result in different methods of assigning responsibility for different | in different methods of assigning responsibility for different levels | |||
levels of the name. | of the name. | |||
Where this cannot be accomplished by the implementation of an | Where this cannot be accomplished by the implementation of an | |||
authoritative hierarchy, it is highly desirable that it be done by | authoritative hierarchy, it is highly desirable that it be done by | |||
creating consensus around a series of published rules for the | creating consensus around a series of published rules for the | |||
creation and administration of names by institutions and bodies that | creation and administration of names by institutions and bodies that | |||
operate by means of collaboration rather than compulsion. | operate by means of collaboration rather than compulsion. | |||
Issuing authorities that operate in more localized scopes, ranging | Issuing authorities that operate in more localized scopes, ranging | |||
from the national down to the very local, MUST equally take | from national scope down to very local scope, MUST equally take | |||
responsibility for the persistence of identifiers within their scope. | responsibility for the persistence of identifiers within their scope. | |||
10. Recommendations for the Resolution Process | 10. Recommendations for the Resolution Process | |||
10.1. The General Architecture of the System | ||||
The task of the resolution service is that of associating a LEX | 10.1. General Architecture of the System | |||
identifier with a specific document address on the Internet. By | ||||
contrast with systems that can be constructed around rigorous and | The task of the resolution service is to associate a LEX identifier | |||
enforceable engineering premises, such as DNS, the "lex" namespace | with a specific document address on the Internet. In contrast with | |||
resolver will be expected to cope with a wide variety of inputs | systems that can be constructed around rigorous and enforceable | |||
incomplete or partially incorrect, particularly those created by the | engineering premises, such as DNS, the "lex" namespace resolver will | |||
automated extraction of references from texts. In this document, the | be expected to cope with a wide variety of inputs that are incomplete | |||
result is a particular emphasis on a flexible and robust resolver | or partially incorrect, particularly those created by the automated | |||
design. | 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 | The system has a distributed architecture based on two fundamental | |||
components: a chain of information in DNS (Domain Name System) and a | components: a chain of information in the DNS and a series of | |||
series of resolution services from URNs to URLs, each competent | resolution services from URNs to URLs, each competent within a | |||
within a specific domain of the namespace. | specific domain of the namespace. | |||
The client retrieves the document associated with this URN using the | The client retrieves the document associated with this URN using the | |||
procedure described in [RFC3404], which starts with a DNS NAPTR | procedure described in [RFC3404], which starts with a DNS NAPTR | |||
query. | query. | |||
A resolution service can delegate the resolution and management of | A resolution service can delegate the resolution and management of | |||
hierarchically-dependent portions of the name. Delegation of this | hierarchically dependent portions of the name. Delegation of this | |||
responsibility will not be unreasonably withheld provided that the | responsibility will not be unreasonably withheld provided that the | |||
processes for their resolution and management are robust and are | processes for their resolution and management are robust and | |||
followed. | followed. | |||
For the "lex" namespace, CNR will maintain in the lex- | For the "lex" namespace, CNR will 1) maintain the root zone of the | |||
nameserver.nic.it (see Section 12) the root zone of the chain | chain resolution, equivalent to "lex.urn.arpa" (see [RFC3405]), in | |||
resolution (equivalent to "lex.urn.arpa", see [RFC3405]) and, in | the lex-nameserver.nic.it (see Section 12) and 2) update the DNS | |||
information with a new record to delegate the relative resolution in | ||||
correspondence with the adhesion (see Section 2.2) of a new country | correspondence with the adhesion (see Section 2.2) of a new country | |||
(e.g., "br") or organization, will update the DNS information with a | (e.g., "br") or organization. This may be obtained by a regular | |||
new record to delegate the relative resolution. This may be obtained | expression that matches the initial part of the URN (e.g., | |||
by a regular expression that matches the initial part of the URN | "urn:lex:br") and redirects towards the proper zone (e.g., | |||
(e.g., "urn:lex:br") and redirects towards the proper zone (e.g., | ||||
"lex.senado.gov.br"). | "lex.senado.gov.br"). | |||
Likewise, the institution responsible for the jurisdiction uniform | Likewise, the institution responsible for the jurisdiction uniform | |||
names (e.g., "urn:lex:br") has the task of managing the relative root | 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 | 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 | resolution towards its resolvers on the basis of parts of the uniform | |||
names. In similar way it can delegate the resolution of country/ | names. In a similar way, it can delegate the resolution of country/ | |||
organization sub-levels (e.g., "urn:lex:br;sao.paolo") towards the | organization sub-levels (e.g., "urn:lex:br;sao.paolo") towards the | |||
relative zone (e.g., "lex.sao-paolo.gov.br"). | relative zone (e.g., "lex.sao-paolo.gov.br"). | |||
Such DNS routing chain does not work for all the URN components | Such a DNS routing chain does not work for all the URN components | |||
containing %-encoded characters. Therefore, when converting a "lex" | containing percent-encoded characters. Therefore, when converting a | |||
URN in UTF-8 code to a DNS query, clients MUST perform any necessary | "lex" URN in UTF-8 code to a DNS query, clients MUST perform any | |||
punycode conversion [RFC5891] before sending the query. | necessary punycode conversion [RFC5891] before sending the query. | |||
The resolution service is made up of two elements: a knowledge base | The resolution service is made up of two elements: a knowledge base | |||
(consisting in a catalogue or a set of transformation rules) and a | (consisting in a catalogue or a set of transformation rules) and | |||
software to query the knowledge base itself. | software to query the knowledge base. | |||
10.2. Catalogues for Resolution | 10.2. Catalogues for Resolution | |||
Incompleteness and inaccuracy are rather frequent in legal citations, | Incompleteness and inaccuracy are rather frequent in legal citations; | |||
and incomplete or inaccurate uniform names of the referred document | thus, incomplete or inaccurate uniform names of the referred document | |||
are thus likely to be built from textual references (this is even | are likely to be built from textual references (this is even more | |||
more frequent if they are created automatically through a specific | frequent if they are created automatically through a specific | |||
parser). For this reason, the implementation of a catalogue, based | parser). For this reason, the implementation of a catalogue, based | |||
on a relational-database, is suggested, as it will lead to a higher | on a relational database, is suggested, as it will lead to higher | |||
flexibility in the resolution process. | flexibility in the resolution process. | |||
In addition the catalogue must manage the aliases, the various | In addition, the catalogue must manage the aliases, the various | |||
versions and languages of the same source of law as well as the | versions and languages of the same source of law, and the related | |||
related manifestations. | manifestations. | |||
It is suggested that each enacting authority implements its own | It is suggested that each enacting authority implement its own | |||
catalogue, assigning a corresponding unambiguous uniform name to each | catalogue, assigning a corresponding unambiguous uniform name to each | |||
resource. | resource. | |||
10.3. Suggested Resolver Behaviour | 10.3. Suggested Resolver Behavior | |||
First, the resolver SHOULD separate the part corresponding to the | First, the resolver SHOULD separate the part corresponding to the | |||
partition ID, through the "~" separator, from the document name. | partition ID from the document name, with the "~" separator. | |||
The resolution process SHOULD implement a normalization of the | The resolution process SHOULD implement a normalization of the | |||
uniform name to be resolved. This may involve transforming some | uniform name to be resolved. This may involve transforming some | |||
components to the canonical form (e.g., filling out the acronyms, | components to the canonical form (e.g., filling out the acronyms, | |||
expanding the abbreviations, unifying the institution names, | expanding the abbreviations, unifying the institution names, | |||
standardizing the type of measures, etc.). For this function | standardizing the type of measures, etc.). For this function, | |||
authorities and types of measure registers are useful. | authorities and types of measure registers are useful. | |||
The resolver SHOULD then query the catalogue searching for the URN | The resolver SHOULD then query the catalogue searching for the URN | |||
which corresponds exactly to the given one (normalized if necessary). | that corresponds exactly to the given one (normalized if necessary). | |||
Since the names coming from the references may be inaccurate or | Since the names coming from the references may be inaccurate or | |||
incomplete, an iterative, heuristic approach (based on partial | incomplete, an iterative and heuristic approach (based on partial | |||
matches) is indicated. Incomplete references (not including all the | matches) is indicated. Incomplete references (not including all the | |||
elements to create the canonical uniform name) are normal and | elements to create the canonical uniform name) are normal and | |||
natural; for a human reader, the reference would be "completed" by | natural; for a human reader, the reference would be "completed" by | |||
contextual understanding of the reference in the document in which it | contextual understanding of the reference in the document in which it | |||
occurs. | occurs. | |||
In this phase, the resolver should use the partition ID information | In this phase, the resolver should use the partition ID information | |||
to retrieve, if it is possible, only the referred partition, | to retrieve, if it is possible, only the referred partition; | |||
otherwise to return the entire document. | otherwise, the entire document is returned. | |||
Lacking more specific indications, the resolver SHOULD select the | Lacking more specific indications, the resolver SHOULD select the | |||
best (most recent) version of the requested source of law, and | best (most recent) version of the requested source of law and provide | |||
provide all the manifestations with their related items. A more | all the manifestations with their related items. A more specific | |||
specific indication in the uniform name to be resolved will, of | indication in the uniform name to be resolved will, of course, result | |||
course, result in a more selective retrieval, based on any suggested | in a more selective retrieval, based on any suggested expression and/ | |||
expression and/or manifestations components (e.g. date, language, | or manifestations components (e.g., date, language, format, etc.). | |||
format, etc.). | ||||
Finally, the resolver SHOULD append to URLs the "#" character | Finally, the resolver SHOULD append the "#" character followed by the | |||
followed by partition ID, transforming it in a URI fragment for | partition ID to URLs, to create URI fragments for browser pointing. | |||
browser pointing. | ||||
11. Security Considerations | 11. Security Considerations | |||
Security considerations are those normally associated with the use | Security considerations are those normally associated with the use | |||
and resolution URNs in general. Additional security considerations | and resolution URNs in general. Additional security considerations | |||
concerning the authenticity of a document do not pertain to the LEX | concerning the authenticity of a document do not pertain to the LEX | |||
specifications, but they pertain security and trust issues which can | specifications, but they pertain to security and trust issues that | |||
be addressed with other means, like digital signature, data | can be addressed with other means, like digital signatures, data | |||
encryption, etc. | encryption, etc. | |||
12. IANA Considerations | 12. IANA Considerations | |||
IANA has already registered the "lex" namespace, according to the | IANA has registered "lex" namespace in the "Formal URN Namespaces" | |||
template at section 2. Registration has been accomplished as the | registry [RFC8141]. | |||
Formal URN Namespace registry described by [RFC8141]. | ||||
In addition, to activate a distributed resolution system, the one-off | In addition, to activate a distributed resolution system, IANA has | |||
registration of the following NAPTR record is requested in the | registered the following NAPTR record in the URN.ARPA domain: | |||
URN.ARPA domain: | ||||
lex.urn.arpa. | lex.urn.arpa. | |||
IN NAPTR 100 10 "" "" "" lex-nameserver.nic.it. | IN NAPTR 100 10 "" "" "" lex-nameserver.nic.it. | |||
where lex-nameserver.nic.it indicates the server of CNR (see section | Note that lex-nameserver.nic.it indicates the CNR server (see | |||
2.2) that is responsible for the resolution of the "lex" namespace at | Section 2.2) that is responsible for the resolution of the "lex" | |||
the time of this writing. | 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 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 Information Institute of the Cornell University Law School, | ||||
for his contribution in revising this document and sharing fruitful | ||||
discussions which greatly improved the final draft. The authors wish | ||||
to specially thank Marc van Opijnen (Dutch Ministry of Security and | ||||
Justice) for his valuable comments on LEX specifications which | ||||
contributed to improve the final result, as well as for the common | ||||
work aimed to harmonize ECLI and LEX specifications. Thanks also to | ||||
Joao Alberto de Oliveira Lima, legislative system analyst of the | ||||
Brazilian Federal Senate, and to Attila Torcsvari, information | ||||
management consultant, for their detailed comments on the first | ||||
drafts of this document, which provided significant hints to the | ||||
final version of the standard, and to Robert Richards of the Legal | ||||
Information Institute (Cornell University Law School), promoter and | ||||
maintainer of the Legal Informatics Research social network, as well | ||||
as to the members of this network, for their valuable comments on | ||||
this proposal. | ||||
Finally, many thanks go to Loriana Serrotti who significantly | 13. References | |||
contributed to the first drafting of this document. | ||||
14. References | 13.1. Normative References | |||
14.1. Normative References | [ISO.8601.1988] | |||
ISO, "Data elements and interchange formats - Information | ||||
interchange - Representation of dates and times", | ||||
ISO 8601:1988, June 1988. | ||||
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message | Extensions (MIME) Part One: Format of Internet Message | |||
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, | |||
<https://www.rfc-editor.org/info/rfc2045>. | <https://www.rfc-editor.org/info/rfc2045>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <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) | [RFC3404] Mealling, M., "Dynamic Delegation Discovery System (DDDS) | |||
Part Four: The Uniform Resource Identifiers (URI)", | Part Four: The Uniform Resource Identifiers (URI)", | |||
RFC 3404, DOI 10.17487/RFC3404, October 2002, | RFC 3404, DOI 10.17487/RFC3404, October 2002, | |||
<https://www.rfc-editor.org/info/rfc3404>. | <https://www.rfc-editor.org/info/rfc3404>. | |||
[RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) | [RFC3405] Mealling, M., "Dynamic Delegation Discovery System (DDDS) | |||
Part Five: URI.ARPA Assignment Procedures", BCP 65, | Part Five: URI.ARPA Assignment Procedures", BCP 65, | |||
RFC 3405, DOI 10.17487/RFC3405, October 2002, | RFC 3405, DOI 10.17487/RFC3405, October 2002, | |||
<https://www.rfc-editor.org/info/rfc3405>. | <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 | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<https://www.rfc-editor.org/info/rfc3986>. | <https://www.rfc-editor.org/info/rfc3986>. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, | Specifications: ABNF", STD 68, RFC 5234, | |||
DOI 10.17487/RFC5234, January 2008, | DOI 10.17487/RFC5234, January 2008, | |||
<https://www.rfc-editor.org/info/rfc5234>. | <https://www.rfc-editor.org/info/rfc5234>. | |||
skipping to change at page 48, line 9 ¶ | skipping to change at line 2241 ¶ | |||
<https://www.rfc-editor.org/info/rfc8141>. | <https://www.rfc-editor.org/info/rfc8141>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, | [RFC8288] Nottingham, M., "Web Linking", RFC 8288, | |||
DOI 10.17487/RFC8288, October 2017, | DOI 10.17487/RFC8288, October 2017, | |||
<https://www.rfc-editor.org/info/rfc8288>. | <https://www.rfc-editor.org/info/rfc8288>. | |||
[ISO.8601.1988] | [W3C.HTML] "HTML", W3C REC HTML, W3C HTML, | |||
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, W3C html, | ||||
<https://www.w3.org/TR/html/>. | <https://www.w3.org/TR/html/>. | |||
14.2. Informative References | 13.2. Informative References | |||
[FRAN] Francesconi, E., "Technologies for European Integration. | [FRAN] Francesconi, E., "Technologies for European Integration. | |||
Standards-based Interoperability of Legal Information | Standards-based Interoperability of Legal Information | |||
Systems", ISBN 978-88-8398-050-3, 2007. | Systems", ISBN 978-88-8398-050-3, 2007. | |||
[FRBR] "Functional Requirements for Bibliographic Records", n.d., | [FRBR] International Federation of Library Associations and | |||
Institutions, "Functional Requirements for Bibliographic | ||||
Records", February 2009, | ||||
<https://www.ifla.org/files/assets/cataloguing/frbr/ | <https://www.ifla.org/files/assets/cataloguing/frbr/ | |||
frbr_2008.pdf>. | frbr_2008.pdf>. | |||
[HCPIL] The European Commission, "The Hague Conference on Private | [HCPIL] The European Commission, "Access to Foreign Law in Civil | |||
International Law "Access to Foreign Law in Civil and | and Commercial Matters", The Hague Conference on Private | |||
Commercial Matters. Conclusions and Recommendations"", | International Law, February 2012, | |||
2012, <https://assets.hcch.net/docs/b093f152-a4b3-4530- | <https://assets.hcch.net/docs/b093f152-a4b3-4530-949e- | |||
949e-65c1bfc9cda1.pdf>. | 65c1bfc9cda1.pdf>. | |||
[ISBD] The Standing Committee of the IFLA Cataloguing Section | [ISBD] The Standing Committee of the IFLA Cataloguing Section | |||
Berlin/Munich\: De Gruyter Saur, "International Standard | Berlin/Munich: De Gruyter Saur, "ISBD: International | |||
Bibliographic Description - Consolidated Edition.", | Standard Bibliographic Description – Consolidated | |||
ISBN 978-3-11-026379-4, 2011. | Edition", ISBN 978-3-11-026379-4, 2011. | |||
[ISO3166-1] | [ISO.3166-1] | |||
International Organization for Standardization, "Codes for | ISO, "Codes for the representation of names of countries | |||
the representation of names of countries and their | and their subdivisions - Part 1: Country codes". | |||
subdivisions -- Part 1: Country codes". | ||||
[LVI] Peruginelli, G., Ed. and M. Ragona, Ed., "Law via the | [LVI] Peruginelli, G., Ed. and M. Ragona, Ed., "Law via the | |||
Internet. Free Access, Quality of Information, | Internet. Free Access, Quality of Information, | |||
Effectiveness of Rights", ISBN 9788883980589, 2008. | Effectiveness of Rights", ISBN 9788883980589, April 2009. | |||
[SART] Sartor, G., Palmirani, M., Francesconi, E., and M. | [SART] Sartor, G., Palmirani, M., Francesconi, E., and M. | |||
Biasiotti, "Legislative XML for the Semantic Web. | Biasiotti, "Legislative XML for the Semantic Web: | |||
Principles, Models, Standards for Document Management, | Principles, Models, Standards for Document Management", | |||
Law, Governance and Technology Series", | ||||
ISBN 978-94-007-1887-6, 2011. | ISBN 978-94-007-1887-6, 2011. | |||
[SPIN] Spinosa, P., "The Assignment of Uniform Names to Italian | [SPIN] Spinosa, P., "The Assignment of Uniform Names to Italian | |||
Legal Documents, URN-NIR 1.4", ITTIG technical Report n. | Legal Documents, URN-NIR 1.4", ITTIG technical Report n. | |||
8/2010., June 2020. | 8/2010, June 2020. | |||
[W3C.rdf-schema] | [W3C.RDF-SCHEMA] | |||
"RDF Schema 1.1", W3C REC 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/>. | <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 | Authors' Addresses | |||
PierLuigi Spinosa | PierLuigi Spinosa | |||
Via Zanardelli, 15 | Via Zanardelli, 15 | |||
50136 Firenze | 50136 Firenze | |||
Italy | Italy | |||
Phone: +39 339 5614056 | Phone: +39 339 5614056 | |||
Email: pierluigi.spinosa@gmail.com | Email: pierluigi.spinosa@gmail.com | |||
Enrico Franceseconi | Enrico Franceseconi | |||
End of changes. 348 change blocks. | ||||
1101 lines changed or deleted | 1153 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |