idnits 2.17.1 draft-spinosa-urn-lex-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 9, 2017) is 2450 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT P. Spinosa 3 Intended Status: Informational (ICT consultant) 4 Expires: February 10, 2018 E. Francesconi 5 ITTIG/CNR 6 C. Lupo 7 (ICT consultant) 8 August 9, 2017 10 A Uniform Resource Name (URN) Namespace 11 for Sources of Law (LEX) 12 draft-spinosa-urn-lex-11.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on February 10, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 This document describes a Uniform Resource Name (URN) Namespace 52 Identification (NID) convention as prescribed by the World Wide Web 53 Consortium (W3C) for identifying, naming, assigning, and managing 54 persistent resources in the legal domain. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1 The Purpose of Namespace "lex" . . . . . . . . . . . . . . 5 60 1.2 Entities Supporting this Standard . . . . . . . . . . . . . 5 61 1.3 The Context . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.4 General Characteristics of the System . . . . . . . . . . . 8 63 1.5 Linking a LEX Name to a Document . . . . . . . . . . . . . 9 64 1.6 Use of LEX Names in References . . . . . . . . . . . . . 10 65 1.7 Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 66 1.8 Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 67 1.9 Syntax Used in this Document . . . . . . . . . . . . . . 11 68 2 Registration Template . . . . . . . . . . . . . . . . . . . . 11 69 3 Specifications of Registration Template . . . . . . . . . . . 15 70 3.1 Identifier structure . . . . . . . . . . . . . . . . . . 15 71 3.2 Conformance with URN Syntax . . . . . . . . . . . . . . . 16 72 3.3 Validation mechanism . . . . . . . . . . . . . . . . . . 16 73 3.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 4 General Syntax and features of the LEX Identifier . . . . . . 16 75 4.1 Allowed and Not Allowed Characters . . . . . . . . . . . 16 76 4.2 Reserved Characters . . . . . . . . . . . . . . . . . . . 17 77 4.3 Case sensitivity . . . . . . . . . . . . . . . . . . . . 17 78 4.4 National Characters and Diacritic Signs . . . . . . . . . 17 79 4.5 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 18 80 4.6 Date Format . . . . . . . . . . . . . . . . . . . . . . . 18 81 5 Specific Syntax and features of the LEX Identifier . . . . . . 18 82 5.1 Spaces, Connectives and Punctuation Marks . . . . . . . . 18 83 5.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 19 84 5.3 Ordinal Numbers . . . . . . . . . . . . . . . . . . . . . 19 85 6 Creation of the Source of Law LEX Identifier . . . . . . . . . 19 86 6.1 Basic Principles . . . . . . . . . . . . . . . . . . . . 19 87 6.2 Model of Sources of Law Representation . . . . . . . . . 19 88 6.3 The Structure of the Local Name . . . . . . . . . . . . . 20 89 6.4 Structure of the Document Identifier at Work Level . . . 21 90 6.5 Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 6.6 Structure of the Document Identifier at Expression Level 23 92 6.7 Structure of the Document Identifier at Manifestation 93 Level . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 6.8 Sources of Law References . . . . . . . . . . . . . . . . 25 95 7 The Procedure of Uniform Names Assignment . . . . . . . . . . 26 96 7.1 Specifying the element of the LEX 97 identifier . . . . . . . . . . . . . . . . . . . . . . . 26 98 7.2 Jurisdictional Registrar for Names Assignment . . . . . . 27 99 7.3 Identifier Uniqueness . . . . . . . . . . . . . . . . . . 27 100 7.4 Identifier persistence considerations . . . . . . . . . . 28 101 8 Principles of the Resolution Service . . . . . . . . . . . . . 28 102 8.1 The General Architecture of the System . . . . . . . . . 28 103 8.2 Catalogues for Resolution . . . . . . . . . . . . . . . . 30 104 8.3 Suggested resolver behaviour . . . . . . . . . . . . . . 30 105 9 Namespace Considerations . . . . . . . . . . . . . . . . . . . 31 106 10 Community Considerations . . . . . . . . . . . . . . . . . . 31 107 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 108 11.1 NID Registration . . . . . . . . . . . . . . . . . . . . 32 109 11.2 Jurisdiction-code Registratio . . . . . . . . . . . . . . 32 110 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 33 111 12.1 Normative References . . . . . . . . . . . . . . . . . . 33 112 12.2 Informative References . . . . . . . . . . . . . . . . . 34 113 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 114 14 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 34 115 Attachment A -- Summary of the syntax of the uniform names of 116 the "lex" namespace . . . . . . . . . . . . . . . . . 36 117 Attachment B -- Specific Syntax of the Identifier at Work Level . 40 118 B1 The element . . . . . . . . . . . . . . . . . . . 40 119 B1.1 Indication of the Authority . . . . . . . . . . . . . . 40 120 B1.2 Multiple Issuers . . . . . . . . . . . . . . . . . . . . 40 121 B1.3 Indication of the Issuer . . . . . . . . . . . . . . . . 40 122 B1.4 Indication of the Body . . . . . . . . . . . . . . . . . 40 123 B1.5 Indication of the Function . . . . . . . . . . . . . . . 41 124 B1.6 Conventions for the Authority . . . . . . . . . . . . . 41 125 B2 The element . . . . . . . . . . . . . . . . . . . . 41 126 B2.1 Criteria for the Indication of the Type of Measure . . . 41 127 B2.2 Further Specification to the Type of Measure . . . . . . 42 128 B2.3 Aliases for Sources of Law with Different Normative 129 References . . . . . . . . . . . . . . . . . . . . . . . 42 130 B2.4 Relations between Measure and Authority in the Aliases . 42 131 B3 The
element . . . . . . . . . . . . . . . . . . . . 43 132 B3.1 Indication of the Details . . . . . . . . . . . . . . . 43 133 B3.2 Multiple Dates . . . . . . . . . . . . . . . . . . . . . 43 134 B3.3 Unnumbered Measures . . . . . . . . . . . . . . . . . . 44 135 B3.4 Multiple Numbers . . . . . . . . . . . . . . . . . . . . 44 136 B4 The element . . . . . . . . . . . . . . . . . . . . . 45 137 B4.1 Formal Annexes . . . . . . . . . . . . . . . . . . . . . 45 138 B4.2 Annexes of Annexes . . . . . . . . . . . . . . . . . . . 45 139 Attachment C -- Specific Syntax of the Element of the 140 Expression . . . . . . . . . . . . . . . . . . . . . 46 141 C1 The element . . . . . . . . . . . . . . . . . . . . 46 142 C1.1 Different Versions of a Legislative Document . . . . . . 46 143 C1.2 Identification of the Version . . . . . . . . . . . . . 46 144 Attachment D -- Http-based LEX identifier . . . . . . . . . . . . 49 145 D1 Http-based URI . . . . . . . . . . . . . . . . . . . . . . . . 49 146 D2 The http-based LEX identifier structure . . . . . . . . . . . 50 147 D3 The http-based LEX identifier at Work Level . . . . . . . . . 51 148 D4 The http-based LEX identifier at Expression Level . . . . . . 51 149 D5 The http-based LEX identifier at Manifestation Level . . . . . 52 151 1 Introduction 153 1.1 The Purpose of Namespace "lex" 155 The purpose of the "lex" namespace is to assign an unequivocal 156 identifier, in standard format, to documents that are sources of law. 157 To the extent of this namespace, "sources of law" include any legal 158 document within the domain of legislation, case law and 159 administrative acts or regulations; moreover potential "sources of 160 law" (acts under the process of law formation, as bills) are included 161 as well. Therefore "legal doctrine" is explicitly not covered. 163 The identifier is conceived so that its recommended construction 164 depends only on the characteristics (details) of the document itself 165 and is, therefore, independent from the document's on-line 166 availability, its physical location, and access mode. The identifier 167 itself is assigned by the jurisdiction that owns the identified 168 document. Even a document that is not available online at all may 169 still have a URN LEX that identifies it. 171 This identifier will be used as a way to represent the references 172 (and more generally, any type of relation) among the various sources 173 of law. In an on-line environment with resources distributed among 174 different Web publishers, uniform resource names allow simplified 175 global interconnection of legal documents by means of automated 176 hypertext linking. LEX URNs are therefore particularly useful when 177 they can be mapped into or associated with locators such as HTTP URIs 179 1.2 Entities Supporting this Standard 181 The following entities support this proposal at the time of 182 publication: 184 - ITTIG/CNR (Institute of Legal Information Theory and Techniques of 185 the Italian National Research Council) - Italy; 186 - National Centre for ICT in Public Administration - Italy; 187 - PRODASEN - IT Department of the Federal Senate - Brazil; 188 - LII (Legal Information Institute), Cornell Law School - USA 190 1.3 The Context 192 In the last few years a number of initiatives have arisen in the 193 field of legal document management. 195 Since 2001 the Italian Government, through the National Center for 196 Information Technology in the Public Administration, the Ministry of 197 Justice and ITTIG-CNR (the Institute of Legal Information Theory and 198 Techniques of the Italian National Research Council) promoted the 199 NormeInRete project. It was aimed at introducing standards for 200 sources of law description and identification using XML and URN 201 techniques. 203 Other national initiatives in Europe introduced standards for the 204 description of legal sources [FRAN]: for example the Metalex project, 205 promoted by the University of Amsterdam and adopted by the Dutch Tax 206 and Customs Administration, the Belgian Public Centers for Welfare 207 and others; LexDania project in Denmark supported by the Danish 208 Ministry of Justice; CHLexML in Switzerland developed by COPIUR, the 209 Coordination Office for the Electronic Publication of Legal Data 210 Federal Office of Justice; eLaw in Austria mainly coordinated by the 211 Austrian Parliament. 213 Such initiatives, based in synergies between government, national 214 research institutes, and universities, have defined national XML 215 standards for legal document management, as well as schemes for legal 216 document identification. 218 Outside Europe, similar initiatives have faced similar problems. For 219 example, the Brazilian Senate carried out a feasibility study to 220 provide unique and transparent identifiers to sources of law on the 221 basis of the IFLA-FRBR model. 222 Similarly, the Akoma Ntoso (Architecture for Knowledge-Oriented 223 Management of African Normative Texts using Open Standards and 224 Ontologies) project provides a set of guidelines for e-Parliament 225 services in a Pan-African context by proposing an XML document schema 226 providing sophisticated description possibilities for several 227 Parliamentary document types (including bills, acts and parliamentary 228 records, etc.). 229 Finally, the Tasmanian Government provided advanced legislative 230 information services through the EnAct project. It gave searchable 231 consolidated Tasmanian legislation by automating much of the 232 legislative drafting and consolidation process, as well as using SGML 233 document representation. Numerous less-visible efforts in the United 234 States and elsewhere have struggled with similar issues. 236 Several of these identifiers are based on a URN schema. The first 237 national standard was defined in Italy within the NormeInRete 238 project; to this the Brazilian Lexml standard followed. Denmark, 239 Hungary, Slovenia and Switzerland expressed their interest in URN 240 identifier for legislation as well. All these standards have a common 241 internal structure, regarding both the hierarchy and the elements 242 content. 244 In today's information society the processes of political, social and 245 economic integration of European Union member states as well as the 246 increasing integration of the world-wide legal and economic processes 247 are causing a growing interest in exchanging legal information 248 knowledge at national and trans-national levels. 249 The growing desire for improved quality and accessibility of legal 250 information amplifies the need for interoperability among legal 251 information systems across national boundaries. A common open 252 standard used to identify sources of law at international level is an 253 essential prerequisite for interoperability. 255 Interest groups within several countries have already expressed their 256 intention to adopt a shared solution based on a URN technique. 257 The need for a unequivocal identifier of sources of law in different 258 EU Member States, based on open standards and able to provide 259 advanced modalities of document hyper-linking, has been expressed in 260 several conferences by representatives of the Publications Office of 261 the European Union (OP), with the aim of promoting interoperability 262 among national and European institution information systems. Similar 263 concerns have been raised by international groups concerned with free 264 access to legal information, and the Permanent Bureau of the Hague 265 Conference on Private International Law is considering a resolution 266 that would encourage member states to "adopt neutral methods of 267 citation of their legal materials, including methods that are medium- 268 neutral, provider-neutral and internationally consistent". In a 269 similar direction the CEN Metalex initiative is moving, at European 270 level, towards the definition of a standard interchange format for 271 sources of law, including recommendations for defining naming 272 conventions to them. 274 The need of unequivocal identifiers for sources of law is of 275 particular interest also in the domain of case law. Such need is 276 extremely felt within both common law systems, where cases are the 277 main law sources, and civil law systems, for the importance of 278 providing an integrated access to cases and legislation, as well as 279 to track the relationships between them. This domain is characterized 280 by a high degree of fragmentation in case law information systems, 281 which usually lack interoperability. 282 Recently in the European Union, the community institutions have 283 stressed the need for citizens, businesses, lawyers, prosecutors and 284 judges to become more aware not only of (directly applicable) EU law, 285 but also of the various national legal systems. The growing 286 importance of national judiciaries for the application of Community 287 law was stressed in the resolution of the European Parliament of 9 288 July 2008 on the role of the national judge in the European judicial 289 system. 290 Similarly the European e-Justice action plans 2009-2013 and 2014-2018 291 of the Council of the European Union underlined the importance of 292 cross-border access to national case law, as well as the need for its 293 standardisation, in view of an integrated access in a decentralized 294 architecture. In this view the Working Party on Legal Data Processing 295 (e-Law) of the Council of the European Union formed a task group to 296 study the possibilities for improving cross-border access to national 297 case law. Taking notice of the report of the Working Party's task 298 group the Council of the EU decided in 2009 to elaborate on a 299 uniform, European system for the identification of case law (ECLI: 300 European Case-Law Identifier) and uniform Dublin Core-based set of 301 metadata. 302 More recently the Council of the European Union invited the Member 303 States to introduce in the legal information systems the European 304 Legislation Identifier (ELI), an http-based Semantic Web oriented 305 identification system for European Union and Member States 306 legislation. 308 LEX identifier is conceived to be general enough, so to provide 309 guidance at the core of the standard and sufficient flexibility to 310 cover a wide variety of needs for identifying all the legal documents 311 of different nature, namely legislative, case-law and administrative 312 acts. Moreover, it can be effectively used within a federative 313 environment where different publishers (public and private) can 314 provide their own items of an act (that is there is more than one 315 manifestation of the same act). 316 However specifications and syntax rules of LEX identifier can be used 317 also for http-based naming convention (Appendix D) to cope with 318 different requirements in legal information management, for example 319 the need of having an identifier compliant with the Linked Open Data 320 principles. 322 This document supplements the required name syntax with a suggested 323 naming convention that interprets all these recommendations into an 324 original solution for sources of law identification. 326 1.4 General Characteristics of the System 328 Registrants wish now to promote interoperability among legal 329 information systems by the definition of a namespace convention and 330 structure that will create and manage identifiers for legal 331 documents. The identifiers will be: 332 - globally unique 333 - transparent 334 - bidirectional 335 - persistent 336 - location-independent, and 337 - language-neutral. 338 These qualities will facilitate legal document management as well as 339 provide a mechanism of stable cross-collections and cross-country 340 references. 342 Transparency means that given an act and its relevant metadata 343 (issuing authority, type of measure, etc.) it is possible to create 344 the related urn identifier. Moreover this identifier is able to 345 unequivocally identify the related act. These two properties makes 346 the identification system bidirectional (from an act to its URN and 347 from a URN to the related act). 349 Language-neutrality is an especially important feature that will 350 promote adoption of the standard by organizations that must adhere to 351 official-language requirements. The proposed standard will provide 352 useful guidance to both public and private groups that create, 353 promulgate, and publish legal documents. Registrants wish to minimize 354 the potential for creating conflicting proprietary schemes, while 355 preserving sufficient flexibility to allow for diverse document types 356 and to respect the need for local control of collections by an 357 equally diverse assortment of administrative entities. 359 As usual, the problem is to provide the right amount guidance at the 360 core of the standard while providing sufficient flexibility to cover 361 a wide variety of needs. The proposed LEX standard does this by 362 splitting the identifier into parts. The first part uses a 363 predetermined standard ("country/jurisdiction name standard") to 364 specify the country (or more generally the jurisdiction) of origin 365 for the legal document being identified; the remainder ("local name") 366 is intended for local use in identifying documents issued in that 367 country or jurisdiction. This second part depends only on sources of 368 law identification system operating in that nation and it is mainly 369 composed by a formalized information related to the enacting 370 authority, the type of measure, the details and possibly the annex. 372 The identification system based on uniform names MUST include: 373 - a schema for assigning names capable of representing unambiguously 374 any addressed source of law, namely legislation, case law and 375 administrative acts, issued by any authority (intergovernmental, 376 supranational, national, regional and local) at any time (past, 377 present and future); 378 - a resolution mechanism - in a distributed environment - that ties a 379 uniform name to the on-line location of the corresponding 380 resources. 381 This document only considers the first of these requirements. It also 382 contains a few references to the architecture of the resolution 383 service and to the corresponding software. 385 1.5 Linking a LEX Name to a Document 387 The LEX name is linked to the document through meta-information which 388 may be specified: 389 - internally to the document itself through a specific element within 390 an XML schema or by an HTML META tag; 392 - externally by means of an RDF triple, a specific attribute in a 393 database, etc. 394 One of these modalities is necessary for enabling automated 395 construction and updating of catalogues (distributed and centralized) 396 and the implementation of resolvers that associate the uniform name 397 of a document with its physical location(s). The standard assumes no 398 particular relationship between the originator of the document, its 399 publisher, and the implementer of catalogues or resolution services. 400 They may be the same entity, or not. 402 1.6 Use of LEX Names in References 404 LEX names will be used on a large scale in references as a HREF 405 attribute value of the hypertext link to the referred document. 406 This link can be created in two ways: 407 - by manually inserting, in the referring document, the link with the 408 uniform name: this is a burdensome procedure especially for 409 documents that are already on-line; 410 - by automatically constructing (either permanently or temporarily) 411 the link with the uniform name, through reference parsers of a 412 text: this is a more time-saving procedure even if subject to a 413 certain percentage of errors, since references are not always 414 accurate or complete. This solution could nevertheless be 415 acceptable for already published documents. 416 In any case, whatever the method adopted is, new documents produced 417 in XML format compliant with the relative DTD/XMLSchema, SHOULD 418 express references through the uniform name of the document referred 419 to. 421 1.7 Definitions 423 According to this document, the following terms are used in the 424 following meaning: 425 - Source of Law: 426 is a general concept, and is used to refer to legislation, case 427 law, regulations and administrative acts. In its broadest sense, 428 the source of law is anything that can be conceived of as the 429 originator of 'erga omnes' legal rules. In this document "source of 430 law" refers also to acts during their formation cycle as bills that 431 might or might not become sources of law; 432 - Jurisdictional Registrar: 433 is an organization which shares and defines in any country or 434 jurisdiction the assignment of the main components of the resource 435 identifier through which its uniqueness is guaranteed. This task 436 includes the definition of possible jurisdiction unit and the 437 primary elements (issuing authority and type of legal measure) of 438 uniform name, according to the characteristics of its own state or 439 institution organization. 441 1.8 Terminology 443 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 444 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 445 document are to be interpreted as described in [RFC2119]. 447 1.9 Syntax Used in this Document 449 This document uses the syntax common to many Internet RFCs, which is 450 based on the ABNF (Augmented Backus-Naur Form) [RFC5234] meta- 451 language. 453 2 Registration Template 455 Namespace Identifier: 457 "lex" requested according to [RFC8141]. 459 Version: 461 1.0 463 Date: 465 2017-05-25 467 Registrant: 469 Institute of Legal Information Theory and Techniques (ITTIG) 470 Italian National Research Council (CNR) 471 Via de' Barucci, 20 472 50127 Florence 473 Italy 474 e-mail: lex@ittig.cnr.it 475 phone: +39 055 43995 477 contact: Enrico Francesconi 478 e-mail: enrico.francesconi@ittig.cnr.it 480 Purpose: 482 The purpose of the "lex" namespace is to assign an unequivocal 483 identifier, in standard format, to documents that are sources 484 of law. 486 In the last few years a number of institutional initiatives 487 have arisen in the field of legal document management. They 488 were aimed at introducing standards for sources of law 489 description and identification using XML and URI techniques, 490 respectively (for more details see Section 1.3) LEX identifier 491 is conceived to be general enough, so to provide guidance at 492 the core of the standard and sufficient flexibility to cover a 493 wide variety of needs for identifying all the legal documents 494 of different nature, namely legislative, case-law and 495 administrative acts. Moreover, it can be effectively used 496 within a federative environment where different publishers 497 (public and private) can provide their own items of an act 498 (that is there is more than one manifestation of the same act). 500 The LEX identifier is conceived to be: globally unique, 501 transparent, bidirectional, persistent, location-independent, 502 and language-neutral. It is organized into parts. The first 503 part uses a predetermined standard to specify the country (or 504 more generally the jurisdiction) of origin for the legal 505 document being identified; the remainder is intended for local 506 use in identifying documents issued in that country or 507 jurisdiction. This second part depends only on sources of law 508 identification system operating in that nation. For more 509 details on the nature of the LEX characteristics and the 510 general internal organization, see Section 1.4. 512 The LEX name is linked to the document through specific meta- 513 information, internally (with a tag) or externally (with a 514 attribute) (for details on this see Section 1.5) 516 LEX names will be used on a large scale in references either in 517 (X)HTML document or, more generally, in XML documents format 518 compliant with the relative DTD/XMLSchema (see Section 1.6 for 519 more information). 521 Syntax: 523 The identifier has a hierarchical structure as follows: 525 "urn:lex:" NSS 527 where is the Namespace Specific String composed as 528 follows: 530 NSS = jurisdiction ":" local-name 532 where: 534 is the part providing the identification of the 535 jurisdiction, generally corresponding to the country, where the 536 source of law is issued. It is also possible to represent 537 international organizations (either states or public 538 administrations or private entities); 540 is the uniform name of the source of law in the 541 country or jurisdiction where it is issued; its internal 542 structure is common to the already adopted schemas. It is able 543 to represent all the aspects of an intellectual production, as 544 it is a legal document, from its initial idea, through its 545 evolution during the time, to its realisation by different 546 means (paper, digital, etc.). 548 LEX specifications gives information on the internal structure 549 of both and , including 550 specifications about case sensitivity, the use of national 551 characters and diacritics, as well as spaces, connectives, 552 punctuation marks, abbreviations, acronyms, date formats and 553 ordinal numbers. For more details on the internal structure and 554 syntax of the LEX identifier, see Section 3, 4 and 5. 556 Recently the r- and q- components have been introduced by 557 [RFC8141]. They provide new and interesting perspectives when 558 using URNs in a complex sector as sources of law, characterized 559 by different versions, languages, publishers, and so on. In 560 particular, by using the r-component at the resolver level, and 561 therefore at the whole NSS level, you can select from the same 562 work only expressions written in a given language, or 563 manifestations published by a particular institutional site, 564 etc. Using the q-component at the act metadata level, you can 565 select versions that are valid at a particular date, or 566 modified by a specific act, etc. 568 Assignment: 570 The Jurisdictional Registrar (or those it delegates) of each 571 adhering country or organization is responsible of the 572 definition or acceptance of the uniform name's primary elements 573 (issuing authority and type of legal measure). 575 Any country or jurisdiction, aiming to adopt this schema, 576 identifies a Jurisdictional Registrar, an organization which 577 shares and defines the structure of the optional part of the 578 name, according to the organization of the state or 579 institution. The process of assigning the will be 580 managed by each specific country or jurisdiction under the 581 related element (details on this can be found in 582 Section 7.2). 584 Identifiers in the "lex" namespace are defined through a 585 element assigned to the sources of law of a 586 specific country or organization, and a assigned 587 by the issuing authority. The goal of the LEX schema is to 588 maintain uniqueness and persistence of all resources identified 589 by the assigned URNs. The elements values for the LEX 590 identifier within a jurisdiction are defined by the 591 Jurisdictional Registrar, this ensures that the constructed 592 URNs are unique (see Section 7.3 for details on uniqueness). 594 The persistence of identifiers depends on the durability of the 595 institutions that assign and administer them (see Section 7.3 596 for details on persitence) 598 Security and Privacy: 600 This document introduces no additional security considerations 601 beyond those associated with the use and resolution of URNs in 602 general. 604 Interoperability: 606 As open standard naming convention to identify sources of law 607 at international level, LEX is meant to guarantee 608 interoperability among legal information systems across 609 national boundaries. 611 The characteristics of the LEX naming convention facilitate 612 legal document management as well as provide a mechanism of 613 stable cross-collections and cross-country references, thus 614 allowing the distribution of the legal information towards a 615 federated architecture. 617 Resolution: 619 The resolution service associates a LEX identifier with a 620 specific document address on the net. The related system will 621 have a distributed architecture based on two fundamental 622 components: a chain of information in DNS (Domain Name System) 623 and a series of resolution services from URNs to URLs, each 624 competent within a specific domain of the namespace (see 625 Section 8.1 for more details). 627 To cope with possible incomplete or inaccurate uniform names, 628 the implementation of a catalogue, based on a relational- 629 database, able to associate a URN to related URLs, is 630 suggested, as it will lead to a higher flexibility in the 631 resolution process. A resolver can provide names normalization, 632 completion of inaccurate or incomplete names, and finally their 633 resolution in network locations (see Section 8.2 and 8.3 for 634 characteristics and behaviour of a catalogue for resolution). 636 Documentation: 638 None 640 Additional Information: 642 See [FRAN] and [SPIN]. 644 Revision Information: 646 None 648 3 Specifications of Registration Template 650 3.1 Identifier structure 652 The element is composed of two specific fields: 654 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 656 where: 658 is usually the identification code of the country 659 where the source of law is issued. 661 To facilitate the transparency of the name, the 662 follows usually the rules of identification of other Internet 663 applications, based on Domain Name. 664 Where applicable, the ccTLD, or the TLD, or the Domain Name of the 665 country or multinational or international organisation is used. 666 In all the examples in the document, it is assumed that the 667 corresponding Domain Name is used for the . 669 However, a special register for the , maintained 670 by IANA, is required, the rules of which are defined in section 11.2. 672 are the possible administrative hierarchical sub- 673 structures defined by each country or organisation according to its 674 own legal system. This additional information can be used where two 675 or more levels of legislative or judicial production exist (e.g., 676 federal, state and municipality level) and the same bodies may be 677 present in each jurisdiction. Then acts of the same type issued by 678 similar authorities in different areas differ for the jurisdiction- 679 unit specification. An example can be the following: 680 "br:governo:decreto" (decree of federal government), 681 "br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state) and 682 "br;sao.paulo;campinas:governo: decreto" (decree of Campinas 683 municipality). 685 Examples of law sources identifiers are: 687 urn:lex:it:stato:legge:2003-09-21;456 (Italian act) 688 urn:lex:fr:etat:loi:2004-12-06;321 (French act) 689 urn:lex:es:estado:ley:2002-07-12;123 (Spanish act) 690 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 (Glarus Swiss Canton 691 decree) 692 urn:lex:eu:commission:directive:2010-03-09;2010-19-EU (EU Commission 693 Directive) 694 urn:lex:us:federal.supreme.court:decision:1963-03-18;372.us.335 (US 695 FSC decision) 696 urn:lex:be:conseil.etat:decision:2008-07-09;185.273 (Decision of the 697 Belgian Council of State) 699 3.2 Conformance with URN Syntax 701 To keep backward compatibility with existing applications in some 702 jurisdictions, the "lex" NID syntax complies with the [RFC2141] 703 specifications. 705 3.3 Validation mechanism 707 The Jurisdictional Registrar (or those it delegates) of each adhering 708 country or organization is responsible of the definition or 709 acceptance of the uniform name's primary elements (issuing authority 710 and type of legal measure). 712 3.4 Scope 714 Global interest. 716 4 General Syntax and features of the LEX Identifier 718 This section lists the general features applicable to all 719 jurisdictions. 721 4.1 Allowed and Not Allowed Characters 723 These characters are defined in accordance with the [RFC2141] "URN 724 Syntax". For various reasons, later explained, in the "lex" 725 only a sub-set of characters is allowed. All other characters are 726 either eliminated or converted. 728 For the full syntax of the uniform names in the "lex" space, please 729 see Attachment A. 731 4.2 Reserved Characters 733 These characters MUST always and uniquely be used for the assigned 734 purpose. 735 The first category includes those characters bearing a specific 736 meaning in the general creation of the URI (Uniform Resource 737 Identifier)[RFC3986]: 739 "%" "/" "?" "#" 741 The following characters instead are reserved in the specific "lex" 742 namespace: 744 - "@" separator of the expression, that contains information on 745 version and language; 746 - "$" separator of the manifestation, that contains information on 747 format, editor, etc.; 748 - ":" separator of the main elements of the name at any entity; 749 - ";" separator of level. It identifies the introduction of an 750 element at a hierarchically lower level, or the introduction of a 751 specification; 752 - "+" separator of the repetitions of an entire main element (e.g., 753 multiple authorities); 754 - "," separator of the repetitions of individual components in the 755 main elements, each bearing the same level of specificity (e.g., 756 multiple numbers); 757 - "~" separator of the partition identifier in references (e.g., 758 paragraph of an article); 759 - "*" and "!" are reserved for future expansions. 761 4.3 Case sensitivity 763 Names belonging to the "lex" namespace are case-insensitive. It is 764 RECOMMENDED that they be created in lower case, but names that differ 765 only in case MUST be considered to be equivalent. 766 (e.g., "Ministry" will be recorded as "ministry"). 768 4.4 National Characters and Diacritic Signs 770 In order to exploit DNS as a routing tool towards the proper 771 resolution system, to keep editing and communication more simple and 772 to avoid character percent-encoding, it is strongly RECOMMENDED that 773 national characters and diacritic signs are turned into base ASCII 774 characters (e.g., the Italian term "sanitU+00E0" converted into 775 "sanita", the French term "ministU+00E8re" converted into 776 "ministere"), in case by transliteration (e.g. "MU+00FCnchen" 777 converted into "muenchen"). 778 If such conversion is not acceptable by a specific jurisdiction and 779 therefore it is used the UTF-8 %-encoding [STD63], it is necessary: 780 - to convert the non-ASCII characters to IDN encoding, using the 781 [RFC5894] punycode translation (ex: mU+00FCnchen into xn--mnchen- 782 3ya), or 783 - to create a routing service relying to a software, out of DNS, 784 addressing a proper resolution service. 785 Summarizing, the preference order is the following: 786 - Conversion into base ASCII (RECOMMENDED solution); 787 - Conversion with punycode translation; 788 - Creation of a routing service relying on a software, out of DNS, 789 addressing a proper resolution service. 790 The first two alternatives allow a DNS routing, the third option does 791 not. However it is up to the specific jurisdiction to choose the 792 preferred solution. 794 4.5 Abbreviations 796 Abbreviations are often used in law for indicating institutions (e.g. 797 Min.), structures (e.g. Dept.), or legal measures (e.g. Reg.) but not 798 in a uniform way, therefore their expansion is highly RECOMMENDED. 799 (e.g., "Min." is reported as "ministry") 801 4.6 Date Format 803 Dates are expressed by numbers in the [ISO8601] format: 805 yyyy-mm-dd 807 (e.g., "September 2, 99" will be written as "1999-09-02") 809 5 Specific Syntax and features of the LEX Identifier 811 In this section there are other features related to a specific 812 jurisdiction and the implementation of which is recommended. 814 5.1 Spaces, Connectives and Punctuation Marks 816 All the language connectives (e.g., articles, prepositions, etc.), 817 the punctuation marks and all the special characters (as apostrophes, 818 dashes, etc.), when explicitly present, are eliminated (no 819 transformation occurs in cases of languages with declensions or 820 agglutinating languages). The words left are connected each other by 821 a dot (".") which substitutes the "space". 822 (e.g., "Ministry of Finances, Budget and of Economic Planning" 823 becomes "ministry.finances.budget.economic.planning"; 824 "Ministerstvo Finansov" becomes "ministerstvo.finansov") 826 5.2 Acronyms 828 The use of acronyms might be confusing and encourage ambiguity in 829 uniform names (the same acronym may indicate two different 830 institutions or structures), therefore their expansion is highly 831 RECOMMENDED. 832 (e.g., "FAO" is expanded as "food.agriculture.organization") 834 5.3 Ordinal Numbers 836 To even the representation, it is highly RECOMMENDED that any ordinal 837 number included in a component of a document name (e.g., in the 838 description of an institution body) is indicated in Arabic numerals, 839 regardless to the original expression: whether in Roman numerals, or 840 with an adjective, or in Arabic numeral with apex, etc. (IV, third, 841 1U+00B0, 2^, etc.). 842 (e.g., "Department IV" becomes "department.4") 844 6 Creation of the Source of Law LEX Identifier 846 6.1 Basic Principles 848 The uniform name must identify one and only one document (more 849 precisely a "bibliographic entity") and is created in such a way that 850 it is: 851 - self-explanatory ; 852 - identifiable through simple and clear rules; 853 - compatible with the practice commonly used for references; 854 - able to be created by references in the text, automatically (by 855 parser) or manually; 856 - representative of both the formal and the substantive aspects of 857 the document. 859 6.2 Model of Sources of Law Representation 861 According to FRBR (Functional Requirements for Bibliographic Records) 862 model developed by IFLA (International Federation of Library 863 Associations and Institutions), in a source of law, as in any 864 intellectual production, 4 fundamental entities (or aspects) can be 865 specified. 867 The first 2 entities reflect its contents: 868 - work: identifies a distinct intellectual creation; in our case, it 869 identifies a source of law both in its being (as it has been issued 870 or proposed) and in its becoming (as it is modified over time); 871 - expression: identifies a specific intellectual realisation of a 872 work; in our case it identifies every different (original or up-to- 873 date) version of the source of law over time and/or language in 874 which the text is expressed; 875 while the other 2 entities relate to its form: 876 - manifestation: identifies a concrete realisation of an expression; 877 in our case it identifies realizations in different media 878 (printing, digital, etc.), encoding formats (XML, PDF, etc.), or 879 other publishing characteristics; 880 - item: identifies a specific copy of a manifestation; in our case it 881 identifies individual physical copies as they are found in 882 particular physical locations. 884 In this document the FRBR model has been interpreted for the specific 885 characteristics of the legal domain. In particular, a part from the 886 language which does produce a specific expression, the discriminative 887 criterion between expression and manifestation is based on the 888 difference of the juridical effects that a variation can provide with 889 respect to the involved actors (citizens, parties, institutions). In 890 this scenario the main characteristic of the expression of an act is 891 represented by its validity over the time, during which it provides 892 the same juridical effects. These effects change for amendments or 893 annulments of other legislative or jurisprudential acts. Therefore 894 notes, summarizations, comments, anonymizations and other editorial 895 activities over the same text do not produce different expressions, 896 but different manifestations. 898 6.3 The Structure of the Local Name 900 The within the "lex" namespace MUST contain all the 901 necessary pieces of information enabling the unequivocal 902 identification of a legal document. 903 In the legal domain, at the "work" level, they are essentially four: 904 the enacting authority, the type of measure, the details and the 905 annex, if any. 906 It is often necessary to differentiate various expressions, that is: 907 - the original version and all the amended versions of the same 908 document; 909 - the versions of the text expressed in the different official 910 languages of the state or organization. 911 Finally the uniform name allows a distinction among diverse 912 manifestations, which may be produced in multiple locations using 913 different means and formats. 914 In every case, the basic identifier of the source of law (work) 915 remains the same, but information is added regarding the specific 916 version under consideration (expression); similarly a suffix is added 917 to the expression for representing the characteristics of the 918 publication (manifestation). 919 The information which forms a source of law uniform name at each 920 level (work, expression, manifestation) is expressed in the official 921 language of the related jurisdiction; in case of more official 922 languages (as in Switzerland) or more involved jurisdictions (as in 923 international treaties), more language-dependent names (aliases) are 924 created. 926 Therefore, the more general structure of the local name appears as 927 follows: 929 local-name = work ["@" expression] ["$" manifestation] 931 However, consistent with legislative practice, the uniform name of 932 the main original provision (work) becomes the identifier of an 933 entire class of documents which includes: the original main document, 934 the annexes, and all their versions, languages and formats 935 subsequently generated. 937 6.4 Structure of the Document Identifier at Work Level 939 The structure of the document identifier is made of the four 940 fundamental elements mentioned above, clearly distinguished one from 941 the other in accordance with an order identifying increasingly narrow 942 domains and competences: 944 work = authority ":" measure ":" details *(":" annex) 946 where: 948 is the issuing or proposing authority of the measure 949 (e.g., State, Ministry, Municipality, Court, etc.); 951 is the type of the measure, both public nature (e.g., 952 constitution, act, treaty, regulation, decree, decision, etc.) as 953 well as private one (e.g., license, agreement, etc); 955
are the terms associated to the measure, typically the date 956 (usually the signature date) and the number included in the heading 957 of the act; 959 is the identifier of the annex, if any (e.g., Annex 1). 961 In case of annexes, both the main document and its annexes have their 962 own uniform name so that they can individually be referenced; the 963 identifier of the annex adds a suffix to that of the main document. 964 In similar way the identifier of an annex of an annex adds an ending 965 to that of the annex which it is attached to. 967 The main elements of the work name are generally divided into several 968 elementary components, and, for each, specific rules of 969 representation are established (criteria, modalities, syntax and 970 order). 971 For the details regarding each element, please see the Attachment B. 973 Examples of identifiers are: 975 urn:lex:it:stato:legge:2006-05-14;22 976 urn:lex:uk:ministry.justice:decree:1999-10-07;45 977 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 978 urn:lex:es:tribunal.supremo:decision:2001-09-28;68 979 urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762 980 urn:lex:br:estado:constituicao:1988-10-05;lex-1 981 urn:lex:fsf.org:free.software.foundation:general.public.license:2007- 982 06-29;lex-1 983 urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581 985 It is worth to note that the type of measure is important to identify 986 case law, as well as legislation, especially within the legal systems 987 where cases, by tradition, are identified only through the year of 988 release and a number. Since the aim of the "urn:lex" schema is to 989 identify specific materials, the type of measure or the full date are 990 able to provide discrimination between materials belonging to a 991 specific case. 993 Here below is an example where the type of measure or the full date 994 are essential for identify specific materials of a case: 995 - 4/59 Judgment of the EEC Court of Justice 04/04/1960, Mannesmann AG 996 and others / ECSC High Authority 997 urn:lex:eec.lex:court.justice:judgment:1960-04-04;4-59 998 - 4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG 999 and others / ECSC High Authority 1000 urn:lex:eec.lex:court.justice:order:1960-05-18;4-59 1002 6.5 Aliases 1004 International treaties involve more jurisdictions (the signing ones) 1005 so they are represented through more identifiers, each of them 1006 related to an involved jurisdiction. For example, a bilateral France 1007 and Germany treaty is identified through two URNs (aliases) belonging 1008 to either "fr" or "de" jurisdiction 1009 (e.g., "urn:lex:fr:etat:traite:..." and 1010 "urn:lex:de:staat:vertrag:...") 1011 since it pertains to both the French and the German jurisdiction. 1013 In the states or organisations that have more than one official 1014 language, a document has more identifiers, each of them expressed in 1015 a different official language, basically a set of equivalent aliases. 1016 This system permits manual or automated construction of the uniform 1017 name of the referred source of law in the same language used in the 1018 document itself. 1019 (e.g., "urn:lex:eu:council:directive:2004-12-07;31", 1020 "urn:lex:eu:consiglio:direttiva:2004-12-07;31", etc.) 1022 Moreover, a document can be assigned more than one uniform name in 1023 order to facilitate its linking to other documents. This option can 1024 be used for documents that, although unique, are commonly referenced 1025 from different perspectives. For example, the form of a document's 1026 promulgation and its specific content (e.g., a Regulation promulgated 1027 through a Decree of the President of the Republic). 1029 6.6 Structure of the Document Identifier at Expression Level 1031 There may be several expressions of a legal text, connected to 1032 specific versions or languages. 1033 Each version is characterized by the period of time during which that 1034 text is to be considered as the valid text (in force or effective). 1035 The lifetime of a version ends with the issuing of the subsequent 1036 version. 1037 New versions of a text may be brought into existence by: 1038 - changes in the text (amendments) due to the issuing of other legal 1039 acts and to the subsequent production of updated or consolidated 1040 texts; 1041 - correction of publication errors (rectification or errata corrige); 1042 - entry into or departure from a particular time span, depending on 1043 the specific date in which different partitions of a text come into 1044 force. 1045 Each of such versions may be expressed in more than one language, 1046 with each language-version having its own specific identifier. 1047 The identifier of a source of law expression adds such information to 1048 the work identifier, using the following main structure: 1050 expression = version [":" language] 1052 where: 1054 is the identifier of the version of the (original or 1055 amended) source of law. In general it is expressed by the 1056 promulgation date of the amending act; anyway other specific 1057 information can be used for particular documents. If necessary, the 1058 original version is specified by the string "original" (for the 1059 details regarding this element, please see the Attachment C); 1061 is the identification code of the language in which the 1062 document is expressed, according to [BCP47] (it=Italian, fr=French, 1063 de=German, etc.). The granularity level of the language (for example 1064 the specification of the German language as used in Switzerland 1065 rather than the standard German) is left to each specific 1066 jurisdiction. The information is not necessary when the text is 1067 expressed in the unique official language of the country or 1068 jurisdiction. 1070 Examples of document identifiers for expressions are: 1072 urn:lex:ch:etat:loi:2006-05-14;22@originel:fr (original version in 1073 French) 1074 urn:lex:ch:staat:gesetz:2006-05-14;22@original:de (original version 1075 in German) 1076 urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr (amended version in 1077 French) 1078 urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de (amended version 1079 in German) 1080 urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr 1081 (original version in French of a Belgian decision) 1083 6.7 Structure of the Document Identifier at Manifestation Level 1085 To identify a specific manifestation, the uniform name of the 1086 expression is followed by a suitable suffix describing the: 1087 - digital format (e.g., XML, HTML, PDF, etc.) expressed according to 1088 the MIME Content-Type standard [RFC2045], where the "/" character 1089 is to be substituted by the "-" sign; 1090 - editorial staff who produced it, expressed according to its 1091 Internet domain name; 1092 - possible components of the expressions contained in the 1093 manifestation. Such components are expressed by language-dependent 1094 labels representing the whole document (in English "all") or the 1095 main part of the document (in English "body") or the caption label 1096 of the component itself (e.g. Table 1, Figure 2, etc.); 1097 - other features of the document (e.g., anonymized decision text). 1099 The suffix will thus read: 1101 manifestation = format *(";" specification) 1102 ":" editor *(";" specification) 1103 [":" component *(";" specification)] 1104 [":" feature *(";" specification)] 1106 To indicate possible features or peculiarities, each main element of 1107 the manifestation MAY be followed by further specifications, for 1108 example as regards the version, for the archive 1109 name and the electronic publisher, etc. 1111 (examples: 1112 the original version the Italian act 3 April 2000, n. 56 might have 1113 the following manifestations with their relative uniform names: 1115 - PDF format (vers. 1.7) of the whole act edited by the Italian 1116 Parliament: 1117 "urn:lex:it:stato:legge:2000-04-03;56$application- 1118 pdf;1.7:parlamento.it" 1119 - XML format (version 2.2 DTD NIR) of the text of the act and PDF 1120 format (version 1.7) of the "Figura 1" (figure 1) contained in the 1121 body, edited by the Italian Senate: 1122 "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir- 1123 2.2:senato.it:testo" 1124 "urn:lex:it:stato:legge:2000-04-03;56$application- 1125 pdf;1.7:senato.it:figura.1" 1127 the Spanish URN of the html format of the whole Judgement of the 1128 European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, 1129 published in the Jurifast data base in anonymized form: 1130 "urn:lex:eu:tibunal.justicia:sentencia:2009-06-11;33- 1131 08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo") 1133 Furthermore, it is useful to be able to assign a uniform name to a 1134 manifestation (or to a part of it) in case non-textual objects are 1135 involved. These may be multimedia objects that are non-textual in 1136 their own right (e.g. geographic maps, photographs, etc.), or texts 1137 recorded in non-textual formats, such as image scans of documents. 1139 In these ways, a LEX name permits: 1140 - exploitation of all the advantages of an unequivocal identifier 1141 that is independent of physical location; 1142 - a means to provide choice among different existing manifestations 1143 (e.g. XML or PDF formats, resolution degree of an image etc.) of 1144 the same expression. 1146 6.8 Sources of Law References 1148 References to sources of law often refer to specific partitions of 1149 the act (article, paragraph, etc.) and not to the entire document. 1150 An act partition is a logical subdivision of the text, that, in a 1151 structured format (as XML) fitting the document logical structure, is 1152 represented by an element with its own ID; this ID aims to identify 1153 the element and to locate it. In a mark-up that does not fit the 1154 logical structure of the text (as HTML), generally only the starting 1155 point of the partition, and not the element, is identified through a 1156 label (a tag). 1157 Therefore, for allowing browsers to point to a specific partition, it 1158 is necessary that such partition is endowed with an unequivocal label 1159 or ID within the including document and its value is the same 1160 independently from the document format. 1162 For enabling the construction of the partition identifier between 1163 different collections of documents, specific construction rules for 1164 IDs or labels SHOULD be defined and shared, within each country or 1165 jurisdiction, for any document type (e.g., for legislation, the 1166 paragraph 2 of the article 3 might have as label or ID the value 1167 "art3;par2", similarly for case-law, paragraph 22 of the judgment in 1168 Case 46/76 Bauhuis v Netherlands, might have as label or ID the value 1169 "par22"). 1170 Furthermore, it is useful to foresee the compatibility with 1171 applications able to manage this information (e.g., returning the 1172 proper element); these procedures are particularly useful in the case 1173 of rather long acts, such as codes, constitutions, regulations, etc. 1174 For this purpose it is necessary that the partition identifier is 1175 transmitted to the servers (resolution and application) and therefore 1176 it cannot be separated by the typical "#" character of URI fragment, 1177 which is not transmitted to the server. 1179 According to these requirements, the syntax of a reference is: 1181 URN-reference = URN-document ["~" partition-id] 1183 (e.g., to refer to the paragraph 3 of the article 15 of the French 1184 Act of 15 may 2004, n. 106, the reference is written 1185 "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3"). 1187 Using a different separator ("~") from the document name, the 1188 partition ID is not withheld by the browser but it is transmitted to 1189 the resolution process. This enables the resolver to retrieve (for 1190 example, out of a database), if it is possible, only the referred 1191 partition, otherwise to return the whole act. 1192 Anyway, to make it effective pointing to the indicated partition 1193 through a browser, the resolver SHOULD transform the partition ID of 1194 each returned URL in a URI fragment; this is obtained appending to 1195 URL the "#" character followed by the partition ID (in the example 1196 above, the returned URL will be #art15;par3). 1198 Anyway it is possible to use the general syntax (with "#"); in this 1199 case only the URN document component of the reference is transmitted 1200 to the resolver, therefore the whole document will be always 1201 retrieved. 1203 7 The Procedure of Uniform Names Assignment 1205 7.1 Specifying the element of the LEX identifier 1207 Under the "lex" namespace, each country or international organization 1208 is assigned with a jurisdiction code, which characterizes the URNs of 1209 the source of law of that country or jurisdiction. This code is 1210 assigned according to ccTLD (as well as TLDN or DN for the 1211 organizations) representation and it is the value of the 1212 element, which preserves cross-country uniqueness 1213 of the identifiers. 1215 7.2 Jurisdictional Registrar for Names Assignment 1217 Any country or jurisdiction, who intends to adopt this schema, 1218 identifies a Jurisdictional Registrar, an organization which shares 1219 and defines the structure of the optional part () 1220 of the name, according to the organization of the state or 1221 institution. For example, in a federal state a 1222 corresponding to the name of each member state (e.g. "br;sao.paolo", 1223 "br;minas.gerais", etc.) may be defined. 1225 The process of assigning the will be managed by each 1226 specific country or jurisdiction under the related 1227 element. 1228 In any country the Jurisdictional Registrar shares and defines the 1229 assignment of the primary elements (issuing authority and type of 1230 legal measure) of the local names considering the characteristics of 1231 its own state or institution organization. 1232 Such a Registrar MUST establish, according to the guidelines 1233 indicated in the current document, a uniform procedure within the 1234 country or organization to define elements, to take 1235 decisions upon normalizations and finally to solve and avoid possible 1236 name collisions as well as to maintain authoritative registries of 1237 various kinds (e.g., for authorities, types of measures, etc.). In 1238 particular, accurate point-in-time representations of the structure 1239 and naming of government entities are important to semantically-aware 1240 applications in this domain. 1241 Moreover, the Registrar shares and defines the rules to construct 1242 partition IDs for each document type. 1243 Finally, the Registrar will develop and publish the rules and the 1244 guidelines for the construction as well as the 1245 predefined values and codes. 1247 7.3 Identifier Uniqueness 1249 Identifiers in the "lex" namespace are defined through a 1250 element assigned to the sources of law of a specific 1251 country or organization, and a assigned by the issuing 1252 authority. The main elements (authority and type of measure) of the 1253 are defined by the Jurisdictional Registrar, so that it 1254 is ensured that the constructed URNs are unique. The Jurisdictional 1255 Registrar SHOULD provide clear documentation of rules by which names 1256 are to be constructed, and SHOULD update and make accessible its 1257 registries. 1259 Any issuing authority is responsible to define formal parameters to 1260 guarantee local name uniqueness by attributing, if necessary, a 1261 conventional internal number, which, combined with the other components (authority, measure and date), builds an unequivocal 1263 identifier. Uniqueness is achieved by checking against the catalogue 1264 of previously assigned names. 1266 7.4 Identifier persistence considerations 1268 The persistence of identifiers depends on the durability of the 1269 institutions that assign and administer them. The goal of the LEX 1270 schema is to maintain uniqueness and persistence of all resources 1271 identified by the assigned URNs. 1273 In particular, ITTIG-CNR, as proposer, is responsible of maintaining 1274 the uniqueness of the element; given that the 1275 is assigned on the basis of the long-held ccTLD 1276 representation of the country (or the TLDN or DN of the organization) 1277 and that the country or organization associated code is expected to 1278 continue indefinitely, the URN also persists indefinitely. 1280 The rules for the construction of the name are conceived to delegate 1281 the responsibility of their uniqueness to a set of authorities which 1282 is identified within each country or organization. 1284 Therefore, each authority is responsible for assigning URNs which 1285 have a very long life expectancy and can be expected to remain unique 1286 for the foreseeable future. Practical and political considerations, 1287 as well as diverse local forms of government organization, will 1288 result in different methods of assigning responsibility for different 1289 levels of the name. 1290 Where this cannot be accomplished by the implementation of an 1291 authoritative hierarchy, it can and SHOULD be done by creating 1292 consensus around a series of published rules for the creation and 1293 administration of names by institutions and bodies that operate by 1294 means of collaboration rather than compulsion. 1296 Issuing authorities that operate in more localized scopes, ranging 1297 from the national down to the very local, MUST equally take 1298 responsibility for the persistence of identifiers within their 1299 scope. 1301 8 Principles of the Resolution Service 1303 8.1 The General Architecture of the System 1305 The task of the resolution service is that of associating a LEX 1306 identifier with a specific document address on the network. By 1307 contrast with systems that can be constructed around rigorous and 1308 enforceable engineering premises, such as DNS, the "lex" namespace 1309 resolver will be expected to cope with a wide variety of "dirty" 1310 inputs, particularly those created by the automated extraction of 1311 references from incomplete or inaccurate texts. In this document, 1312 the result is a particular emphasis on a flexible and robust resolver 1313 design. 1315 The system has a distributed architecture based on two fundamental 1316 components: a chain of information in DNS (Domain Name System) and a 1317 series of resolution services from URNs to URLs, each competent 1318 within a specific domain of the namespace. 1319 Through the NAPTR records of the DNS (described in [RFC3403]), the 1320 client identifies the characteristics (protocol, port, site) of the 1321 service (e.g. according to [RFC2169]) capable of associating the 1322 relative URLs with the URN in question, thereby allowing access to 1323 the document. 1325 A resolution service can delegate the resolution and management of 1326 hierarchically-dependent portions of the name. 1327 Delegation of this responsibility will not be unreasonably withheld 1328 provided that the processes for their resolution and management are 1329 robust and are followed. 1331 For the "lex" namespace, ITTIG-CNR will maintain the root zone 1332 "lex.urn.arpa" and, in correspondence with the adhesion of a new 1333 country (e.g., "br") or organization, will update the DNS information 1334 with a new record to delegate the relative resolution. This may be 1335 obtained by a regular expression that matches the initial part of the 1336 URN (e.g., "urn:lex:br") and redirects towards the proper zone (e.g., 1337 "lex.senado.gov.br"). 1339 Likewise the institution responsible for the jurisdiction uniform 1340 names (e.g., "urn:lex:br") has the task of managing the relative root 1341 in the DNS system (e.g., "lex.senado.gov.br" zone) and routing the 1342 resolution towards its resolvers on the basis of parts of the uniform 1343 names. In similar way it can delegate the resolution of 1344 country/organization sub-levels (e.g., "urn:lex:br;sao.paolo") 1345 towards the relative zone (e.g., "lex.sao-paolo.gov.br"). 1347 Such DNS routing chain does not work for all the URN components 1348 containing %-encoded characters. Therefore in these cases a proper 1349 software implementing routing service has to be developed. 1351 The resolution service is made up of two elements: a knowledge base 1352 (consisting in a catalogue or a set of transformation rules) and a 1353 software to query the knowledge base itself. 1355 8.2 Catalogues for Resolution 1357 Incompleteness and inaccuracy are rather frequent in legal citations, 1358 and incomplete or inaccurate uniform names of the referred document 1359 are thus likely to be built from textual references (this is even 1360 more frequent if they are created automatically through a specific 1361 parser). For this reason, the implementation of a catalogue, based on 1362 a relational-database, is suggested, as it will lead to a higher 1363 flexibility in the resolution process. 1364 In addition the catalogue must manage the aliases, the various 1365 versions and languages of the same source of law as well as the 1366 related manifestations. 1368 It is suggested that each enacting authority implements its own 1369 catalogue, assigning a corresponding unambiguous uniform name to each 1370 resource. 1372 8.3 Suggested resolver behaviour 1374 First of all the resolver should separate the part corresponding to 1375 the partition ID, through the "~" separator, from the document name. 1377 So, the resolution process SHOULD implement a normalization of the 1378 uniform name to be resolved. This may involve transforming some 1379 components to the canonical form (e.g., filling out the acronyms, 1380 expanding the abbreviations, unifying the institution names, 1381 standardizing the type of measures, etc.). For this function 1382 authorities and types of measure registers are useful. 1384 The resolver SHOULD then query the catalogue searching for the URN 1385 which corresponds exactly to the given one (normalized if necessary). 1386 Since the names coming from the references may be inaccurate or 1387 incomplete, an iterative, heuristic approach (based on partial 1388 matches) is indicated. It is worth remarking that incomplete 1389 references (not including all the elements to create the canonical 1390 uniform name) are normal and natural; for a human reader, the 1391 reference would be "completed" by contextual understanding of the 1392 reference in the document in which it occurs. 1394 In this phase, the resolver should use the partition ID information 1395 to retrieve, if it is possible, only the referred partition, 1396 otherwise to return of the entire document. 1398 Lacking more specific indications, the resolver SHOULD select the 1399 best (most recent) version of the requested source of law, and 1400 provide all the manifestations with their related items. 1401 A more specific indication in the uniform name to be resolved will, 1402 of course, result in a more selective retrieval, based on any 1403 suggested expression and/or manifestations components (e.g. date, 1404 language, format, etc.). 1406 Finally, the resolver SHOULD append to URLs the "#" character 1407 followed by partition ID, transforming it in a URI fragment for 1408 browser pointing. 1410 9 Namespace Considerations 1412 In collaboration with the legislative XML community, registrants 1413 carried out a preliminary study of the URI alternatives to satisfy 1414 the key requirements. 1415 The options analysed were: a private URI scheme, URL, PURL and URN. 1416 URN was considered the most appropriate URI given the requirements 1417 analysis. 1418 Advantages we would emphasize are: 1419 - greater flexibility in building the identifier; 1420 - the capacity to represent name components that are not strictly 1421 hierarchical; 1422 - the potential for clear division of the identifier into macro 1423 parts, main elements and components, using different separators; 1424 - ease of managing optional parts of a name. 1426 10 Community Considerations 1428 The use of the "lex" namespace facilitates the interoperability of 1429 information systems used in the Public Administration at the national 1430 and international level. Moreover it allows the distribution of the 1431 legal information towards a federated architecture. In such an 1432 architecture, documents are directly managed by the issuing 1433 authorities, with resulting benefits in information authenticity, 1434 quality and currency. A shared identification mechanism resources 1435 guarantees that a distributed system will be as efficient and 1436 effective as a comparable centralized system. 1438 Creators of Internet content that references legal materials - 1439 including publishers operating well outside the traditional arenas of 1440 legal publishing - benefit by the registration of the namespace 1441 because facilitates the linking of legal documents, whether by manual 1442 or automated means, and reduces the cost of maintaining documents 1443 that contain such references. 1445 Any citizen or organisation with Internet web browser capability will 1446 be entitled to access the namespace and its associated application, 1447 registers, and resolution services, to facilitate document access. 1449 11 IANA Considerations 1450 11.1 NID Registration 1452 This document includes a URN NID registration for "lex" for entry in 1453 the IANA registry of URN NIDs (see [RFC8141]), as well as the 1454 registration of the following NAPTRs record: 1456 in the URN.ARPA domain: 1457 lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it. 1459 in the URN.URI.ARPA domain: 1460 lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it. 1462 11.2 Jurisdiction-code Registratio 1464 IANA is requested to create a new registry for . 1465 The registration policy is "Expert Review" as specified in [RFC8126]. 1466 Designated Expert(s) will assign jurisdiction codes based on the 1467 following principles: 1468 - if a request comes from a jurisdiction that corresponds to a 1469 country and the jurisdiction code is the same as a top level ccTLD, 1470 which is not yet registered, then the top level ccTLD should be 1471 used as the jurisdiction code; 1472 - if a request comes from a jurisdiction that corresponds to a multi- 1473 national (e.g., European Union) or international (e.g., United 1474 Nations, Free Software Foundation) organizations the Top Level 1475 Domain Name (e.g., "eu") or the Domain Name (e.g., "un.org", 1476 "wto.int") of the organization should be used as the jurisdiction 1477 code; 1478 - in case when such multi-national or international organization does 1479 not have a registered domain, Designated Expert should assign 1480 something like .lex, where is the English acronym of 1481 the organization name. For example, the jurisdiction code of the 1482 European Economic Community is "eec.lex". 1484 Jurisdiction codes can't be renamed, because allowing for renames 1485 would violate rules that URN assignments are persistent. 1487 Jurisdiction codes can never be deleted. They can only be marked as 1488 "obsolete", i.e. closed for new assignments within the jurisdiction. 1489 Requests to obsolete a jurisdiction code are also processed by 1490 Designated Expert. 1492 Designated Expert can unilaterally initiate allocation or obsoletion 1493 of a jurisdiction code. 1495 Request for new jurisdiction code assignment must include 1496 Organization or Country requesting it and Contact information (email) 1497 of who requested the assignment. 1499 12 References 1501 12.1 Normative References 1503 [BCP47] A. Phillips, M. Davis, "Tags for Identifying Languages", 1504 BCP 47, RFC 5646, September 2009 1506 [STD63] F. Yergeau, "UTF-8, a transformation format of ISO 1507 10646", STD 63, RFC 3629, November 2003. 1509 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1510 Extensions (MIME) Part One: Format of Internet Message 1511 Bodies", RFC 2045, November 1996. 1513 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1514 Requirement Levels", BCP 14, RFC 2119, March 1997. 1516 [RFC2141] R. Moats, K. R. Sollins, "URN Syntax", RFC 2141, May 1517 1997. 1519 [RFC2169] R. Daniel, "A Trivial Convention for using HTTP in URN", 1520 RFC 2169, June 1997 1522 [RFC3403] M. Mealling, Dynamic Delegation Discovery System (DDDS), 1523 Part Three: The Domain Name System (DNS) Database, RFC 1524 3403, October 2002. 1526 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1527 Resource Identifiers (URI): Generic Syntax", STD 66, RFC 1528 3986, January 2005. 1530 [RFC5234] D. Crocker Ed., P. Overell, "Augmented BNF for Syntax 1531 Specifications: ABNF", STD 68, RFC 5234, January 2008 1533 [RFC5894] J. Klensin, "Internationalized Domain Names for 1534 Applications (IDNA): Background, Explanation, and 1535 Rationale", RFC 5894, August 2010 1537 [RFC5988] M. Nottingham, "Web Linking", RFC 5988, October 2010 1539 [RFC8126] M. Cotton, B. Leiba, T. Narten, "Guidelines for Writing 1540 an IANA Considerations Section in RFCs", RFC 8126, June 1541 2017 1543 [RFC8141] P. Saint-Andre, J.C. Klensin, "Uniform Resource Names 1544 (URNs)", RFC 8141, April 2017 1546 [ISO8601] ISO 8601, "Data elements and interchange formats", ISO 1547 8601:2004 1549 12.2 Informative References 1551 [FRAN] E. Francesconi, "Technologies for European Integration. 1552 Standards-based Interoperability of Legal Information 1553 Systems", ISBN 978-88-8398-050-3, European Press Academic 1554 Publishing, 2007. 1556 [SPIN] P.L. Spinosa, "The Assignment of Uniform Names to Italian 1557 Legal Documents", URN-NIR 1.4, June, 2010, ITTIG 1558 Technical Report n. 8/2010. 1560 13 Acknowledgments 1562 The authors of this document wish to thank all the supporters for 1563 giving suggestions and comments. 1564 They are also grateful to the Legislative XML community for the 1565 interesting discussions on this topic and to the Working Group 1566 "Identification of the legal resources through URNs" of Italian 1567 NormeInRete project for the provided guidance [SPIN]. 1568 The authors owe a debt of gratitude to Tom Bruce, director of the 1569 Legal Information Institute of the Cornell University Law School, for 1570 his contribution in revising this document and sharing fruitful 1571 discussions which greatly improved the final draft. The authors wish 1572 to specially thank Marc van Opijnen (Dutch Ministry of Security and 1573 Justice) for his valuable comments on LEX specifications which 1574 contributed to improve the final result, as well as for the common 1575 work aimed to harmonize ECLI and LEX standards. Thanks also to Joao 1576 Alberto de Oliveira Lima, legislative system analyst of the Brazilian 1577 Federal Senate, and to Attila Torcsvari, information management 1578 consultant, for their detailed comments on the first drafts of this 1579 document, which provided significant hints to the final version of 1580 the standard, and to Robert Richards of the Legal Information 1581 Institute (Cornell University Law School), promoter and maintainer of 1582 the Legal Informatics Research social network, as well as to the 1583 members of this network, for their valuable comments on this 1584 proposal. 1585 Finally, many thanks go to Loriana Serrotti who significantly 1586 contributed to the first drafting of this document. 1588 14 Author's Addresses 1590 PierLuigi Spinosa 1591 (ICT consultant) 1592 Via Zanardelli, 15 1593 50136 Firenze 1594 Italy 1595 Telephone: +39 339 5614056 1596 e-mail: pierluigi.spinosa@gmail.com 1598 Enrico Francesconi 1599 Istituto di Teoria e Tecniche dell'Informazione Giuridica (ITTIG) 1600 Consiglio Nazionale delle Ricerche (CNR) 1601 Via de' Barucci, 20 1602 50127 Firenze 1603 Italy 1604 Telephone: +39 055 43995 1605 e-mail: enrico.francesconi@ittig.cnr.it 1607 Caterina Lupo 1608 (ICT consultant) 1609 Via San Fabiano, 25 1610 00165 Roma 1611 Italy 1612 Telephone: +39 3382632348 1613 e-mail: caterina.lupo@gmail.com 1615 Attachment A -- Summary of the syntax of the uniform names of the "lex" 1616 namespace 1618 *------------------------------------------------------------------- 1619 * General Structure of a Uniform Resource Name (URN) 1620 * NID = namespace 1621 * NSS = specific name 1622 *------------------------------------------------------------------- 1623 URN = "urn:" NID ":" NSS 1625 *------------------------------------------------------------------- 1626 * Structure of a Uniform Resource Name (URN) of the "lex" namespace 1627 *------------------------------------------------------------------- 1628 NID = "lex" 1630 URN = "urn:lex:" NSS-lex 1632 *------------------------------------------------------------------- 1633 * Structure of a "lex" specific name 1634 *------------------------------------------------------------------- 1635 NSS-lex = jurisdiction ":" local-name 1637 *------------------------------------------------------------------- 1638 * Structure of the element 1639 *------------------------------------------------------------------- 1640 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 1642 jurisdiction-code = 2*4lowercase / (alfanum *normal) 1644 jurisdiction-unit = alfanum *normal 1646 *------------------------------------------------------------------- 1647 * Structure of the element 1648 *------------------------------------------------------------------- 1649 local-name = work ["@" expression] ["$" manifestation] 1651 *------------------------------------------------------------------- 1652 * Structure of the element 1653 *------------------------------------------------------------------- 1654 work = authority ":" measure ":" details *(":" annex) 1656 *------------------------------------------------------------------- 1657 * Structure of the element 1658 *------------------------------------------------------------------- 1659 authority = issuer *("+" issuer) 1661 issuer = (institution *(";" body) *(";" function)) / office 1662 institution = alfanum *normal 1664 body = alfanum *normal 1666 function = alfanum *normal 1668 office = alfanum *normal 1670 *------------------------------------------------------------------- 1671 * Structure of the element 1672 *------------------------------------------------------------------- 1673 measure = measure-type *(";" specification) 1675 measure-type = alfanum *normal 1677 specification = alfanum *normal 1679 *------------------------------------------------------------------- 1680 * Structure of the
element 1681 *------------------------------------------------------------------- 1682 details = (dates / period) ";" numbers 1684 dates = date *("," date) 1686 period = alfanum *normal 1688 numbers = (document-id *("," document-id)) / number-lex 1690 document-id = alfanum *(normal / other) 1692 number-lex = "lex-" 1*DIGIT 1694 *------------------------------------------------------------------- 1695 * Structure of the element 1696 *------------------------------------------------------------------- 1697 annex = annex-id *(";" specification) 1699 annex-id = alfanum *normal 1701 *------------------------------------------------------------------- 1702 * Structure of the element 1703 *------------------------------------------------------------------- 1704 expression = version [":" language] 1706 *------------------------------------------------------------------- 1707 * Structure of the element 1708 *------------------------------------------------------------------- 1709 version = (amendment-date / specification) 1710 *(";" (event-date / event)) 1712 amendment-date = date 1714 event-date = date 1716 event = alfanum *normal 1718 *------------------------------------------------------------------- 1719 * Structure of the element 1720 *------------------------------------------------------------------- 1721 language = 2*3lowercase 1723 *------------------------------------------------------------------- 1724 * Structure of the element 1725 *------------------------------------------------------------------- 1726 manifestation = format *(";" specification) 1727 ":" editor *(";" specification) 1728 [":" component *(";" specification)] 1729 [":" feature *(";" specification)] 1731 format = alfanum *(normal / "-") 1733 editor = alfanum *(normal / "-") 1735 component = alfanum *(normal / "-") 1737 feature = alfanum *(normal / "-") 1739 *------------------------------------------------------------------- 1740 * Structure of the date 1741 *------------------------------------------------------------------- 1742 date = year "-" month "-" day 1744 year = 4DIGIT 1745 month = 2DIGIT 1746 day = 2DIGIT 1748 *------------------------------------------------------------------- 1749 * Allowed characters 1750 *------------------------------------------------------------------- 1751 allowed-lex = normal / other / reserved / future 1753 normal = alfanum / "." 1755 alfanum = lowercase / uppercase / DIGIT / encoded 1757 lowercase = %x61-7A ; lower-case ASCII letters (a-z) 1758 uppercase = %x41-5A ; upper-case ASCII letters (A-Z) 1760 DIGIT = %x30-39 ; decimal digits (0-9) 1762 encoded = 1*4 ("%" 2HEXDIG ) 1764 HEXDIG = DIGIT / %x41-46 / %x61-66 ; hex digits (0-9,A-F,a-f) 1766 other = "-" / "_" / "'" / "=" / "(" / ")" 1768 reserved = ":" / "@" / "$" / "+" / ";" / "," / "~" 1770 future = "*" / "!" 1772 Attachment B -- Specific Syntax of the Identifier at Work Level 1774 B1 The element 1776 B1.1 Indication of the Authority 1778 The element of a uniform name may indicate, in the 1779 various cases: 1780 - the actual authority issuing the legal provision. More 1781 specifically, the authority adopting the provision or enacting it; 1782 - the institution where the provision is registered, known and 1783 referenced to, even if produced by others (e.g., the bills 1784 identified through the reference to the Chamber where they are 1785 presented); 1786 - the institution regulated (and referred to in citations) by the 1787 legal provision even when this is issued by another authority 1788 (e.g., the statute of a Body); 1789 - the entity that proposed the legal material not yet included in the 1790 institutional process (e.g. a proposed bill written by a a 1791 political party). 1793 B1.2 Multiple Issuers 1795 Some sources of law are enacted by a number of issuing parties (e.g., 1796 inter-ministerial decrees, agreements, etc.). In this case, the 1797 element contains all the issuing parties (properly 1798 separated), as follows: 1800 authority = issuer *("+" issuer) 1802 (e.g., "ministry.justice+ministry.finances") 1804 B1.3 Indication of the Issuer 1806 Each issuing authority is essentially represented by either an 1807 institutional office (e.g., Prime Minister) or an institution (e.g., 1808 Ministry); in the last case, the authority is indicated in accordance 1809 with the institution's hierarchical structure, from the more general 1810 to more specific (Council, Department, etc.), ending with the 1811 relative office (President, Director, etc.). 1812 Therefore, the structure of the issuer is as follows: 1814 issuer = (institution *(";" body) *(";" function)) / office 1816 (e.g., "ministry.finances;department.revenues;manager") 1818 B1.4 Indication of the Body 1819 Depending on the kind of measure, the body within the issuing 1820 authority is unambiguously determined (e.g., the Council for Regional 1821 Acts) and normally it is not indicated in the references. 1822 Just like in practice, the indication of the enacting authority is 1823 limited to the minimum in relation to the type of measure. 1824 (e.g., "region.tuscany:act" and not "region.tuscany;council:act") 1826 B1.5 Indication of the Function 1828 Generally, the component is indicated, sometimes instead 1829 of the body itself: 1830 - in case of political, representative or elective offices 1831 (e.g., "university.oxford;rector:decree" instead of 1832 "university.oxford;rectorship:decree"); 1833 - when it refers to a top officer in the institution (e.g., general 1834 manager, general secretary, etc.) which is not always possible to 1835 associate a specific internal institutional structure to 1836 (e.g., "national.council.research;general.manager"). 1838 It is not indicated when it clearly corresponds to the person in 1839 charge of an institution (typically, a general director); in this 1840 case, only the structure and not the person in charge is indicated 1841 (e.g., "ministry.justice;department.penitentiary.administration"). 1843 The function MUST be indicated when: 1844 - it is not the same of the director or the person in charge of the 1845 structure (for example, in case of an undersecretary, a deputy 1846 director, etc.); 1847 - the type of measure may be both monocratic or collegial: the 1848 indication of the office eliminates the ambiguity. 1850 B1.6 Conventions for the Authority 1852 Acts and measures bearing the same relevance as an act, issued or 1853 enacted since the foundation of the State, have conventionally 1854 indicated "state" (expressed in each country official language) as 1855 authority; the same convention is used for constitutions, codes 1856 (civil, criminal, civil procedure, criminal procedure, etc) and 1857 international treaties. 1859 B2 The element 1861 B2.1 Criteria for the Indication of the Type of Measure 1863 In uniform names the issuing authority of a document is mandatory. 1864 This makes unnecessary to indicate any further qualification of the 1865 measure (e.g., ministerial decree, directorial ordinance, etc.), even 1866 if it is widely used. 1868 When the authority-measure combination clearly identifies a specific 1869 document, the type of measure is not defined through attributes 1870 referring to the enacting authority. 1871 (e.g., "region.tuscany:act" and not "region.tuscany:regional.act") 1873 B2.2 Further Specification to the Type of Measure 1875 In the element, it is usually sufficient to indicate the 1876 type of a measure. As usual, references to sources of law, rather 1877 than through the formal details (date and number), may be made 1878 through some of their characteristics such as the subject-matter 1879 covered (e.g., accounting regulations), nicknames referring to the 1880 promoter (e.g., Bassanini Act) or to the topic of the act (e.g., 1881 Bankruptcy Law), etc.. 1882 In these cases, the type of measure MAY be followed by further 1883 specifications useful in referencing even if the details are lacking: 1885 measure = measure-type *(";" specification) 1887 (e.g., "regulations;accounting" or "act;bankruptcy") 1889 B2.3 Aliases for Sources of Law with Different Normative References 1891 There are legislative measures that, although unique, are usually 1892 cited in different ways, for example through the legislative act 1893 introducing them into the legal order (President's decree, 1894 legislative decree, etc.) or through their legislative category 1895 (regulations, consolidation, etc.). 1896 In order to ensure, in all the cases, the validity of the references, 1897 an alias that takes into account the measure category is associated 1898 to the uniform name, representing the legislative form. 1899 (e.g., "state:decree.legislative:1992-07-24;358" and 1900 "state:consolidation;public.contracts:1992-07-24;358"). 1902 B2.4 Relations between Measure and Authority in the Aliases 1904 The sources of law including different normative references are 1905 usually introduced in legislation through the adoption or the issuing 1906 of an act, which they are either included or attached to. It is, 1907 therefore, necessary to create an alias linking the two aspects of 1908 the same document. Specifically, the different measures can be: 1909 - adopted/issued by an authority different from the one regulated by 1910 the provision (e.g., the statute of a Body); in this case, the 1911 correlation is established between two uniform names each featuring 1912 a completely different element 1913 (e.g., "italian.society.authors.publishers:statute" and 1914 "ministry.cultural.activities+ministry.finances.budget.economic. 1915 planning:decree"); 1917 - issued by the institution itself either because it has issuing 1918 authority or by virtue of a proxy (e.g., a provision that refers to 1919 the functioning of the Body itself); in this case, the two aliases 1920 share the first part of the authority; 1921 (e.g., "municipality.firenze:statute" and 1922 "municipality.firenze;council:deliberation"); 1923 - issued by the same Body to regulate a particular sector of its own 1924 competence; in this case the element is the same 1925 (e.g., "ministry.justice:regulation;use.information.tools. 1926 telematic.process" and "ministry.justice:decree"). 1928 B3 The
element 1930 B3.1 Indication of the Details 1932 The details of a source of law usually include the date of the 1933 enactment and the identification number (inclusion in the body of 1934 laws, register, protocol, etc.). 1935 Some measures can have multiple dates; there are also cases in which 1936 the number of the measure does not exist (unnumbered measures) or a 1937 measure has multiple numbers (e.g., unified cases). For these 1938 reasons, the set up of both elements (date and number) includes 1939 multiple values. 1941 Some institutions (e.g., the Parliaments) usually identify documents 1942 through their period of reference (e.g., the legislature number) 1943 rather than through a date, which would be much less meaningful and 1944 never used in references (e.g., Senate bill S.2544 of the XIV 1945 legislature). In these cases, the component is used in 1946 substitution of the component . 1948 Usually details of a measure are not reported according to a specific 1949 sequence; in accordance with the global structure of the uniform 1950 name, which goes from the general to the specific, the sequence date- 1951 number has the following form: 1953 details = (dates / period) ";" numbers 1955 (e.g., "2000-12-06;126", "14.legislature;s.2544") 1957 B3.2 Multiple Dates 1959 Some sources of law, even if unique, are identified by more than one 1960 date; in this case, in the field all the given dates are to 1961 be reported and indicated as follows: 1963 dates = date *("," date) 1965 (e.g., the measure of the Data Protection Authority of December 30, 1966 1999- January 13, 2000, No. 1/P/2000 has the following uniform name: 1967 "personal.data.protection.authority:measure:1999-12-30,2000-01-13; 1968 1-p-2000"). 1970 B3.3 Unnumbered Measures 1972 Measures not officially numbered in the publications may have a non- 1973 unequivolcal identifier, because several measures of the same type 1974 can exist, issued on the same day by the same authority. 1975 To ensure that the uniform name is unambiguous, the field 1976 MUST, in any case, contain a discriminating element, which can be any 1977 identifier used internally, and not published, by the authority 1978 (e.g., protocol). 1979 If the authority does not have its own identifier, one identifier 1980 MUST be created for the name system. In order to easily differentiate 1981 it, such number is preceded by the string "lex-": 1983 number-lex = "lex-" 1*DIGIT 1985 (e.g., "ministry.finances:decree:1999-12-20;lex-3") 1987 It is responsibility of the authority issuing a document to assign a 1988 discriminating specification to it; in case of multiple authorities, 1989 only one of them is responsible for the assignment of the number to 1990 the document (e.g., the proponent). 1991 The unnumbered measures published on an official publication (e.g., 1992 the Official Gazette), instead of by a progressive number are 1993 recognized by the univocal identifying label printed on the paper. 1994 Such an identifier, even if unofficial but assigned to a document in 1995 an official publication, is to be preferred because it has the clear 1996 advantage to be public and therefore easier to be found. 1998 B3.4 Multiple Numbers 2000 Some legal documents (e.g., bills), even if unique, are identified by 2001 a set of numbers (e.g., the unification of cases or bills). 2002 In this case, in the field, all the identifiers are 2003 reported, according to the following structure: 2005 numbers = document-id *("," document-id) 2007 (e.g., "2000-06-12;c-10-97,c-11-97,c-12-97") 2008 The characters which are not allowed (e.g., "/") or reserved (e.g., 2009 ":"), including the comma, cannot exist inside the , and 2010 therefore MUST be turned into "-". 2011 This conversion may imply that the uniform name of the document is no 2012 more unique (e.g., removal 123-BIS and return 123/BIS of the bill 123 2013 both are identified as "123-bis"); in this case, it is necessary to 2014 add a specific distinctive ending (e.g., "123-bis-removal" and "123- 2015 bis-return"). 2017 B4 The element 2019 B4.1 Formal Annexes 2021 Although annexes are an integral part of the legal document, they may 2022 be referred to and undergo amendments separately from the act to 2023 which they are annexed. It is, therefore, necessary that both the 2024 main document as well as each formal individual annex is univocally 2025 identified. 2027 Formal annexes may be registered as separate parts or together with a 2028 legal provision; they may also be autonomous in nature or not. In any 2029 case, they MUST be given a uniform name, which includes the uniform 2030 name of the source of law to which they are attached, and a suffix 2031 which identifies the annex itself. 2033 The suffix of formal annexes includes the official heading of the 2034 annex and, possibly, further specifications (e.g., the title) which 2035 will facilitate the retrieval of the annex in case the identifier is 2036 missing: 2038 annex = annex-id *(";" specification) 2040 (e.g., "region.sicily;council:deliberation:1998-02-12;14:annex.a; 2041 borders.park") 2043 The characters which are not allowed (e.g. "/") or which are reserved 2044 (e.g. ":") must not be featured in the and therefore MUST 2045 be turned into ".". 2047 B4.2 Annexes of Annexes 2049 When there are annexes to an annex, their corresponding identifiers 2050 are created by adding to the identifier of the original annex those 2051 of the annexes that are connected with it (that is, attached to it). 2053 (e.g., Table 1 attached to Attachment A of the preceding legal act 2054 has the following uniform name: 2055 "region.sicily;council:deliberation:1998-02-12;14:annex.a; 2056 borders.park:table.1;municipality.territories"). 2058 Attachment C -- Specific Syntax of the Element of the 2059 Expression 2061 C1 The element 2063 C1.1 Different Versions of a Legislative Document 2065 The creation of an updated text of a document may have one of the 2066 following forms: 2067 - "multi-version": when specific mark-ups which identify the modified 2068 parts of a document (added, substituted or deleted parts) and their 2069 related periods of effectiveness are indicated inside one single 2070 object (e.g., an xml file). Such a document will be able, in a 2071 dynamic way, to appear in different forms according to the 2072 requested date of effectiveness. 2073 In this document type, usually a set of metadata contains the 2074 lifecycle of the document (from the original to the last 2075 modification), including the validity time interval of each version 2076 and of each related text portion; 2077 - "single-version": when, on the contrary, a new and distinct object 2078 is created for each amendment to the text at a given time. Each 2079 object is, therefore, characterized by its own period of validity. 2080 In any case all the versions SHOULD be linked one another and 2081 immediately navigable. 2083 In a "multi-version" document each time interval should have a link 2084 to the related in-force document version obtained by displaying in a 2085 different way the very same document. 2086 In a "single-version" document, the metadata should contain links to 2087 the all the previous modifications and a link only to the following 2088 version, if any. 2090 [RFC5988] can be used as reference to establish links between 2091 different document versions, either in the "multi-version" or in the 2092 "single-version" document. According to [RFC5988] the following 2093 relations are useful: 2094 - current (or last or last-version): in-force version 2095 - self: this version 2096 - next: next version 2097 - previous: previous version 2098 - first: original version 2099 It is RECOMMENDED that these relations are inserted in the header of 2100 each version (if "single-version") or associated to each entry 2101 containing a single URN (if "multi-version"). 2103 C1.2 Identification of the Version 2104 In order to identify the different time versions of the same act, to 2105 the uniform name of the original document has to be added a specific 2106 suffix. 2107 Such a suffix identifies each version of a legal provision and 2108 includes, first and foremost, one of the following elements: 2109 - the issuing date of the last amending measure taken into account; 2110 - the date in which the communication of the rectification or of the 2111 errata corrige, is published; 2112 - a specification which must identify the reason concerning the 2113 amendment (e.g., the specific phase of the legislative process), 2114 for the cases in which the date is not usually used (e.g., bills). 2116 Anyway it is possible to add further specifications that will 2117 distinguish each of the different versions of the text to guarantee 2118 identifier unequivocalness. For example with regard to changes of the 2119 in-force or effectiveness of any partition or portion of the text 2120 itself (e.g., when the amendments introduced by an act are applied at 2121 different times) or different events occurring in the same date. 2123 version = (amendment-date / specification) 2124 *(";" (event-date / event)) 2126 where: 2127 - contains the issuing date of the last considered 2128 amendment or of the last communication of amendment. In case the 2129 original text introduces differentiated periods in which an act is 2130 effective and the information system produces one version for each 2131 of them, such element contains the string "original"; 2132 - any information useful to identify unambiguously 2133 and univocally the version; 2134 - contains the date in which a version is put into 2135 force, is effective or is published; 2136 - is a name assigned to the event producing a further version 2137 (e.g., amendment, decision, etc.). 2139 The issuing date of an amending act was chosen as identifier of a 2140 version because it can be obtained from the heading (formal data). 2142 (e.g., the name "state:royal.decree:1941-01-30;12@1998-02-19" 2143 identifies the updated text of the "Royal Decree of 30/1/1941, No. 2144 12" with the amendments introduced by the "Law Decree of 19/2/1998, 2145 No. 51", without any indication of its actual entry into force. The 2146 same uniform name with the additional ending ";1999-01-01" indicates 2147 the in-force or effective version starting in a different date (from 2148 1/1/99). 2150 For a full compatibility, every updating of a text or of the 2151 effectiveness of a "multi-version" document implies the creation of a 2152 new uniform name, even if the object remains only one, containing the 2153 identifier of the virtually generated version, exactly as in the case 2154 of a "single-version" document. A specific meta-data will associate 2155 every uniform name with the period of time during which such a name 2156 together with its corresponding text is to be considered valid. 2158 (e.g., the multi-version document containing the "R.D. of 01/30/1941, 2159 no. 12", updated by the amendments introduced by the "D.Lgs. of 2160 02/19/1998, no. 51", contains the name of the original 2161 "state:royal.decree:1941-01-30;12" as well as the name of the updated 2162 version "state:royal.decree:1941-01-30;12@1998-02-19"). 2164 Please note that in case of attachments or annexes, the creation of a 2165 new version (even in the case of only one component) would imply the 2166 creation of a new uniform name for all the connected objects in order 2167 to guarantee their alignment (i.e., the main document, the 2168 attachments and annexes). 2170 Attachment D -- Http-based LEX identifier 2172 D1 Http-based URI 2174 Http-based URIs have been recently promoted as stable and location- 2175 independent identifiers [RFC3986]. According to this syntax, at all 2176 levels, resource IDs belong to the http scheme and are normally 2177 resolved using mechanisms widely available in browsers and web 2178 servers. 2180 Such kind of identifiers have been recently suggested also within the 2181 set of principles and technologies, known as "Linked Data" as a basic 2182 infrastructure of the semantic web to enable data sharing and reuse 2183 on a massive scale. 2185 Such principles, introduced by Tim Berners-Lee in his Web 2186 architecture note "Linked Data" 2187 (http://www.w3.org/DesignIssues/LinkedData.html), are synthetically: 2189 - Use URIs as names for things; 2190 - Use HTTP URIs, so that people can look up those names; 2191 - When someone looks up a URI, provide useful information, using the 2192 standards (RDF, SPARQL); 2193 - Include links to other URIs, so that they can discover more 2194 things. 2196 The second principle is the one more affecting a discussion about the 2197 scheme to be used for legal resources identification; in particular 2198 to the aim of guaranteeing the access to the resources, http-based 2199 identifiers are suggested. This property is addressed as 2200 "dereferenceability", meaning a resource retrieval mechanism using 2201 any of the Internet protocols, e.g. HTTP, so that HTTP clients, for 2202 instance, can look up the URI using the HTTP protocol and retrieve a 2203 description of the resource that is identified by the URI. 2204 Such property is available for http-based identifiers either with or 2205 without a resolver allowing a 1-to-1 association with the "best copy" 2206 of the resource; in the legal domain it is related to the unique act 2207 manifestation of a specific publisher and format. 2209 The same property holds for URN identifiers, as long as a resolver is 2210 properly set-up, allowing 1-to-N association with more manifestations 2211 of a resource (act). 2213 Therefore an http-based identifier, stable and independent from the 2214 resource location, can be effectively used when a single publisher 2215 provides a specific item of this resource (1-to-1 mapping between an 2216 identifier and manifestation of an act). The independence from the 2217 resource location is managed by a "303 Redirect" status code (see 2218 http://linkeddatabook.com/editions/1.0/#htoc11) which may require a 2219 resolver able to access the physical location of the resource (e.g., 2220 through submitting a query to a database). A URN identifier, stable 2221 and independent form the resource location, can be effectively used 2222 within a federative environment where different publishers can 2223 provide different items of the same act (1-to-N mapping between an 2224 identifier and different manifestations of an act). 2226 In order to comply with the Linked Data principles and to build http- 2227 based identifiers using the LEX namespace specifications, the LEX 2228 schema and metadata set can be serialized according to an http URI 2229 syntax. It is worthwhile to mention that URN focuses on identifying 2230 an act, while Linked Data principles focus on identifying a resource 2231 on the Web. 2233 In the following sections the http-based serialization of the urn LEX 2234 schema is reported. 2236 D2 The http-based LEX identifier structure 2238 The http-based hierarchical structure of the LEX identifier is the 2239 following: 2241 "http://" host-name "/lex/" jurisdiction "/" local-name 2243 where: 2244 - represents the name of the organization server 2245 publishing the resource; 2246 - "lex" is the equivalent of the URN namespace ID and provides the 2247 reference to the naming convention adopted; 2248 - and share meaning and syntax of the 2249 corresponding components in the LEX specifications. 2251 The element follows the syntax rules of the 2252 corresponding element in the URN specification, therefore it has the 2253 following structure: 2255 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 2257 The character ";" still separates the identification code of the 2258 country or jurisdiction where the source of law is issued 2259 () from any possible administrative hierarchical 2260 sub-structures defined by each country or organisation according to 2261 its own legal system. 2263 The follows the FRBR model as implemented by the LEX 2264 specifications, therefore its http-based structure is the following: 2266 local-name = work "/@/" expression "/$/" manifestation 2268 D3 The http-based LEX identifier at Work Level 2270 According to the corresponding level of the URN version, the http- 2271 based LEX identifier structure at work level is the following: 2273 work = authority "/" measure "/" details *("/" annex) 2275 The elements , and follow the same 2276 syntax rules of the corresponding elements in the URN specification. 2278 Examples of http-based identifiers at level, corresponding to 2279 the urn-based examples in Section 6.4, are the following: 2281 http:///lex/it/stato/legge/2006-05-14;22 2282 http:///lex/uk/ministry.justice/decree/1999-10-07;45 2283 http:///lex/ch;glarus/regiere/erlass/2007-10-15;963 2284 http:///lex/es/tribunal.supremo/decision/2001-09-28;68 2285 http:///lex/fr/assemblee.nationale/proposition.loi/ 2286 13.legislature;1762 2287 http:///lex/br/estado/constituicao/1988-10-05;lex-1 2288 http:///lex/fsf.org/free.software.foundation/ 2289 general.public.license/2007-06-29;lex-1 2290 http:///lex/nl/hoge.raad/besluit/2008-04-01;bc8581 2292 D4 The http-based LEX identifier at Expression Level 2294 According to the corresponding level of the URN version, the http- 2295 based LEX structure at expression level is the following: 2297 expression = version ["/" language] 2299 The elements and follow the same syntax rules of 2300 the corresponding elements in the URN specification. 2302 Examples of http-based identifiers at expression level, corresponding 2303 to the urn-based examples in Section 6.6, are the following: 2305 http:///lex/ch/etat/loi/2006-05-14;22/@/originel/fr 2306 (original version in French) 2307 http:///lex/ch/staat/gesetz/2006-05-14;22/@/original/de 2308 (original version in German) 2309 http:///lex/ch/etat/loi/2006-05-14;22/@/2008-03-12/fr 2310 (amended version in French) 2311 http:///lex/ch/staat/gesetz/2006-05-14;22/@/2008-03-12/de 2312 (amended version in German) 2313 http:///lex/be/conseil.etat/decision/2008-07-09;185.273 2314 /@/originel/fr 2315 (original version in French of a Belgian decision) 2317 D5 The http-based LEX identifier at Manifestation Level 2319 Information provided in the URN version at manifestation level is 2320 differently accommodated in the corresponding level of the http-based 2321 LEX identifier. 2323 The element, reported at manifestation level in the urn- 2324 based LEX version, is an information already contained in the of the http-based LEX identifier, therefore it is omitted in 2326 the elements. 2327 Similarly the element is omitted since it loses its meaning 2328 which would derived from the comparison between different 2329 manifestations. 2331 The element is reported as unique extension of the data 2332 format in which the manifestation is drafted. The value is compliant 2333 with the registered file extensions, thus it can be "pdf" for PDF, 2334 "doc" for MS Word, "xml" for XML documents, "tif" for tiff image 2335 format, etc. 2337 Therefore the http-based LEX structure at manifestation level is the 2338 following: 2340 manifestation = [ component *(";" specification)] "." format 2342 The element follows the same syntax rules of the 2343 corresponding element in the URN specification. 2345 Examples of http-based identifiers at manifestation level, 2346 corresponding to the urn-based examples in Section 6.7 are the 2347 following: 2349 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/testo.xml 2350 (body of the Italian law 3 April 2000, n. 56, published by the 2351 Italian Senate in xml format) 2352 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/figura.1.pdf 2353 (Figure 1 in PDF format of the Italian law 3 April 2000, n. 56, 2354 published by the Italian Senate) 2355 http://www.juradmin.eu/jurifast/lex/eu/tibunal.justicia/sentencia/ 2356 2009-06-11;33-08/@/original/es/$/todo.html 2357 (the Spanish http-based LEX identifier of the html format of the 2358 whole Judgement of the European Court of Justice n. 33/08 of 2359 11/06/2009, in Spanish version, published by the Juriadmin site in 2360 the Jurifast data base) 2361 http://eur-lex.europa.eu/lex/eu/commission/directive/ 2362 2010-03-09;2010-19-EU/$/body.xml 2363 (body of the EU Directive n. 2010-19-EU, dated 2010-03-09, in its 2364 XML format published by Eur-Lex)