idnits 2.17.1 draft-spinosa-urn-lex-15.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 22, 2022) is 765 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 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: September 18, 2022 E. Francesconi 5 CNR 6 C. Lupo 7 (ICT consultant) 8 March 22, 2022 10 A Uniform Resource Name (URN) Namespace 11 for Sources of Law (LEX) 12 draft-spinosa-urn-lex-15.txt 14 Abstract 16 This document describes a Uniform Resource Name (URN) Namespace 17 Identification (NID) convention for identifying, naming, assigning, 18 and managing persistent resources in the legal domain. This 19 specification is published to allow adoption of a common convention 20 by multiple jurisdictions to facilitate ease of reference and access 21 to resources in the legal domain. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on September 18, 2022. 46 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 1.1 The Purpose of Namespace "lex" . . . . . . . . . . . . . . 5 61 1.2 Entities Supporting this Standard . . . . . . . . . . . . . 5 62 1.3 The Context . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.4 General Characteristics of the System . . . . . . . . . . . 8 64 1.5 Linking a LEX Name to a Document . . . . . . . . . . . . . 9 65 1.6 Use of LEX Names in References . . . . . . . . . . . . . 10 66 1.7 Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 67 1.8 Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 68 1.9 Syntax Used in this Document . . . . . . . . . . . . . . 11 69 2 Registration Template . . . . . . . . . . . . . . . . . . . . 11 70 3 Specifications of Registration Template . . . . . . . . . . . 15 71 3.1 Identifier structure . . . . . . . . . . . . . . . . . . 15 72 3.2 Conformance with URN Syntax . . . . . . . . . . . . . . . 16 73 3.3 Validation Mechanism . . . . . . . . . . . . . . . . . . 16 74 3.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 4 General Syntax and Features of the LEX Identifier . . . . . . 16 76 4.1 Allowed and Not Allowed Characters . . . . . . . . . . . 16 77 4.2 Reserved Characters . . . . . . . . . . . . . . . . . . . 17 78 4.3 Case Sensitivity . . . . . . . . . . . . . . . . . . . . 17 79 4.4 National Characters and Diacritic Signs . . . . . . . . . 17 80 4.5 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 18 81 4.6 Date Format . . . . . . . . . . . . . . . . . . . . . . . 18 82 5 Specific Syntax and Features of the LEX Identifier . . . . . . 18 83 5.1 Spaces, Connectives and Punctuation Marks . . . . . . . . 19 84 5.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 19 85 5.3 Ordinal Numbers . . . . . . . . . . . . . . . . . . . . . 19 86 6 Creation of the Source of Law LEX Identifier . . . . . . . . . 19 87 6.1 Basic Principles . . . . . . . . . . . . . . . . . . . . 19 88 6.2 Model of Sources of Law Representation . . . . . . . . . 20 89 6.3 The Structure of the Local Name . . . . . . . . . . . . . 20 90 6.4 Structure of the Document Identifier at Work Level . . . 21 91 6.5 Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 6.6 Structure of the Document Identifier at Expression Level 23 93 6.7 Structure of the Document Identifier at Manifestation 94 Level . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 6.8 Sources of Law References . . . . . . . . . . . . . . . . 26 96 7 The Procedure of Uniform Names Assignment . . . . . . . . . . 27 97 7.1 Specifying the Element of the LEX 98 Identifier . . . . . . . . . . . . . . . . . . . . . . . 27 99 7.2 Jurisdictional Registrar for Names Assignment . . . . . . 27 100 7.3 Identifier Uniqueness . . . . . . . . . . . . . . . . . . 28 101 7.4 Identifier Persistence Considerations . . . . . . . . . . 28 102 8 Principles of the Resolution Service . . . . . . . . . . . . . 29 103 8.1 The General Architecture of the System . . . . . . . . . 29 104 8.2 Catalogues for Resolution . . . . . . . . . . . . . . . . 30 105 8.3 Suggested Resolver Behaviour . . . . . . . . . . . . . . 31 106 9 Namespace Considerations . . . . . . . . . . . . . . . . . . . 31 107 10 Community Considerations . . . . . . . . . . . . . . . . . . 32 108 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 109 11.1 NID Registration . . . . . . . . . . . . . . . . . . . . 32 110 11.2 Jurisdiction-code Registration . . . . . . . . . . . . . 33 111 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 34 112 12.1 Normative References . . . . . . . . . . . . . . . . . . 34 113 12.2 Informative References . . . . . . . . . . . . . . . . . 35 114 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 115 14 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 36 116 Attachment A -- Summary of the Syntax of the Uniform Names of 117 the "lex" Namespace . . . . . . . . . . . . . . . . . 37 118 Attachment B -- Specific Syntax of the Identifier at Work Level . 41 119 B1 The Element . . . . . . . . . . . . . . . . . . . 41 120 B1.1 Indication of the Authority . . . . . . . . . . . . . . 41 121 B1.2 Multiple Issuers . . . . . . . . . . . . . . . . . . . . 41 122 B1.3 Indication of the Issuer . . . . . . . . . . . . . . . . 41 123 B1.4 Indication of the Body . . . . . . . . . . . . . . . . . 41 124 B1.5 Indication of the Function . . . . . . . . . . . . . . . 42 125 B1.6 Conventions for the Authority . . . . . . . . . . . . . 42 126 B2 The Element . . . . . . . . . . . . . . . . . . . . 42 127 B2.1 Criteria for the Indication of the Type of Measure . . . 42 128 B2.2 Further Specification to the Type of Measure . . . . . . 43 129 B2.3 Aliases for Sources of Law with Different Normative 130 References . . . . . . . . . . . . . . . . . . . . . . . 43 131 B2.4 Relations between Measure and Authority in the Aliases . 43 132 B3 The
Element . . . . . . . . . . . . . . . . . . . . 44 133 B3.1 Indication of the Details . . . . . . . . . . . . . . . 44 134 B3.2 Multiple Dates . . . . . . . . . . . . . . . . . . . . . 44 135 B3.3 Unnumbered Measures . . . . . . . . . . . . . . . . . . 45 136 B3.4 Multiple Numbers . . . . . . . . . . . . . . . . . . . . 45 137 B4 The Element . . . . . . . . . . . . . . . . . . . . . 46 138 B4.1 Formal Annexes . . . . . . . . . . . . . . . . . . . . . 46 139 B4.2 Annexes of Annexes . . . . . . . . . . . . . . . . . . . 46 140 Attachment C -- Specific Syntax of the Element of the 141 Expression . . . . . . . . . . . . . . . . . . . . . 47 142 C1 The Element . . . . . . . . . . . . . . . . . . . . 47 143 C1.1 Different Versions of a Legislative Document . . . . . . 47 144 C1.2 Identification of the Version . . . . . . . . . . . . . 47 145 Attachment D -- Http LEX Identifier . . . . . . . . . . . . . . . 50 146 D1 Http URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 147 D2 The Http LEX Identifier Structure . . . . . . . . . . . . . . 51 148 D3 The Http LEX Identifier at Work Level . . . . . . . . . . . . 52 149 D4 The Http LEX Identifier at Expression Level . . . . . . . . . 52 150 D5 The Http LEX Identifier at Manifestation Level . . . . . . . . 53 152 1 Introduction 154 1.1 The Purpose of Namespace "lex" 156 The purpose of the "lex" namespace is to assign an unequivocal 157 identifier, in well-defined format, to documents that are sources of 158 law. To the extent of this namespace, "sources of law" include any 159 legal document within the domain of legislation, case law and 160 administrative acts or regulations; moreover potential "sources of 161 law" (acts under the process of law formation, as bills) are included 162 as well. Therefore "legal doctrine" is explicitly not covered. 164 The identifier is conceived so that its designed construction depends 165 only on the characteristics (details) of the document itself and is, 166 therefore, independent from the document's on-line availability, its 167 physical location, and access mode. The identifier itself is assigned 168 by the jurisdiction that owns the identified document. Even a 169 document that is not available online at all may still have a LEX URN 170 that identifies it. 172 This identifier can be used as a way to represent the references (and 173 more generally, any type of relation) among the various sources of 174 law. In an on-line environment with resources distributed among 175 different Web publishers, uniform resource names allow simplified 176 global interconnection of legal documents by means of automated 177 hypertext linking. LEX URNs are therefore particularly useful when 178 they can be mapped into or associated with locators such as HTTP 179 URLs. 181 1.2 Entities Supporting this Specification 183 The following entities support the publication of this proposal: 185 - CNR (National Research Council of Italy) - Italy; 186 - Agency for Digital Italy (AgID) - Presidency of the Council of 187 Ministers - Italy; 188 - PRODASEN - IT Department of the Federal Senate - Brazil; 189 - LII (Legal Information Institute), Cornell Law School - USA. 191 1.3 The Context 193 This specification of an unequivocal identifier for legal documents 194 follows a number of initiatives in the field of legal document 195 management. These specifications for an an unequivocal identifier of 196 legal documents follows a number of initiatives in the field of legal 197 document management. 199 Since 2001 the Italian Government, through the National Center for 200 Information Technology in the Public Administration, the Ministry of 201 Justice and CNR (the National Research Council of Italy) promoted 202 the NormeInRete project. It was aimed at introducing standards for 203 sources of law description and identification using XML and URN 204 techniques. 206 Other national initiatives in Europe introduced standards for the 207 description of legal sources [FRAN]. Such initiatives, based in 208 synergies between government, national research institutes, and 209 universities, have defined national XML standards for legal document 210 management, as well as schemes for legal document identification. 211 Outside Europe, similar initiatives have addressed similar problems 212 [FRAN]. Several of these identifiers are based on a URN schema. 214 In today's information society the processes of political, social and 215 economic integration of European Union member states as well as the 216 increasing integration of the world-wide legal and economic processes 217 are causing a growing interest in exchanging legal information 218 knowledge at national and trans-national levels. 219 The growing desire for improved quality and accessibility of legal 220 information amplifies the need for interoperability among legal 221 information systems across national boundaries. A common well-defined 222 schema used to identify sources of law at international level is an 223 essential prerequisite for interoperability. 225 Interest groups within several countries have already expressed their 226 intention to adopt a shared solution based on a URN technique. 227 The need for an unequivocal identifier of sources of law in different 228 EU Member States, based on open standards and able to provide 229 advanced modalities of document hyper-linking, has been expressed in 230 several conferences (as [LVI]) by representatives of the Publications 231 Office of the European Union (OP), with the aim of promoting 232 interoperability among national and European institution information 233 systems. Similar concerns have been raised by international groups 234 concerned with free access to legal information, and the Permanent 235 Bureau of the Hague Conference on Private International Law [HCPIL] 236 that encourage State Parties to "adopt neutral methods of citation of 237 their legal materials, including methods that are medium-neutral, 238 provider-neutral and internationally consistent.". In a similar 239 direction the CEN Metalex initiative is moving, at European level, 240 towards the definition of a standard interchange format for sources 241 of law, including recommendations for defining naming conventions to 242 them. 244 The need of unequivocal identifiers for sources of law is of 245 particular interest also in the domain of case law. Such need is 246 extremely felt within both common law systems, where cases are the 247 main law sources, and civil law systems, for the importance of 248 providing an integrated access to cases and legislation, as well as 249 to track the relationships between them. This domain is characterized 250 by a high degree of fragmentation in case law information systems, 251 which usually lack interoperability. 252 In the European Union, the community institutions have stressed the 253 need for citizens, businesses, lawyers, prosecutors and judges to 254 become more aware not only of (directly applicable) EU law, but also 255 of the various national legal systems. The growing importance of 256 national judiciaries for the application of Community law was 257 stressed in the resolution of the European Parliament of 9 July 2008 258 on the role of the national judge in the European judicial system. 259 Similarly the the Council of the European Union has underlined the 260 importance of cross-border access to national case law, as well as 261 the need for its standardisation, in view of an integrated access in 262 a decentralized architecture. In this view the Working Party on Legal 263 Data Processing (e-Law) of the Council of the European Union formed a 264 task group to study the possibilities for improving cross-border 265 access to national case law. Taking notice of the report of the 266 Working Party's task group the Council of the EU decided in 2009 to 267 elaborate on a uniform, European system for the identification of 268 case law (ECLI: European Case-Law Identifier) and uniform Dublin 269 Core-based set of metadata. 270 The Council of the European Union invited the Member States to 271 introduce in the legal information systems the European Legislation 272 Identifier (ELI), an http-based Semantic Web oriented identification 273 system for European Union and Member States legislation. 275 The LEX identifier (also referred in this text as "LEX name") is 276 conceived to be general enough so as to provide guidance at the core 277 of the standard and sufficient flexibility to cover a wide variety of 278 needs for identifying all the legal documents of different nature, 279 namely legislative, case-law and administrative acts. Moreover, it 280 can be effectively used within a federative environment where 281 different publishers (public and private) can provide their own items 282 of a legal document (that is there is more than one manifestation of 283 the same legal document). 284 However specifications and syntax rules of LEX identifier can be used 285 also for http-based naming convention (Appendix D) to cope with 286 different requirements in legal information management, for example 287 the need of having an identifier compliant with the Linked Open Data 288 principles. 290 This document supplements the required name syntax with a naming 291 convention that interprets all these recommendations into an original 292 solution for sources of law identification. 294 1.4 General Characteristics of the System 295 The specification contained in this document promote interoperability 296 among legal information systems by the definition of a namespace 297 convention and structure that will create and manage identifiers for 298 legal documents. The identifiers will be: 299 - globally unique 300 - transparent 301 - reversible 302 - persistent 303 - location-independent, and 304 - language-neutral. 305 These qualities will facilitate legal document management as well as 306 providing a mechanism of stable cross-collections and cross-country 307 references. 309 Transparency means that given an act and its relevant metadata 310 (issuing authority, type of measure, etc.) it is possible to create 311 the related urn identifier. Moreover this identifier is able to 312 unequivocally identify the related act. These two properties make the 313 identification system reversible (from an act to its URN and from a 314 URN to the related act). 316 Language-neutrality is an especially important feature that will 317 promote adoption of the standard by organizations that must adhere to 318 official-language requirements. This specification provides useful 319 guidance to both public and private groups that create, promulgate, 320 and publish legal documents. Registrants wish to minimize the 321 potential for creating conflicting proprietary schemes, while 322 preserving sufficient flexibility to allow for diverse document types 323 and to respect the need for local control of collections by an 324 equally diverse assortment of administrative entities. 326 As usual, the problem is to provide the right amount guidance at the 327 core of the specification while providing sufficient flexibility to 328 cover a wide variety of needs. This LEX specification does this by 329 splitting the identifier into parts. The first part uses a pre- 330 existing standard specification ("country/jurisdiction name 331 standard") to indicate the country (or more generally the 332 jurisdiction) of origin for the legal document being identified; the 333 remainder ("local name") is intended for local use in identifying 334 documents issued in that country or jurisdiction. This second part 335 depends only on the system of sources of law identification operating 336 in that nation and it is mainly composed by formalized information 337 related to the enacting authority, the type of measure, the details 338 and possibly the annex. 340 The identification system based on uniform names includes: 341 - a schema for assigning names capable of representing unambiguously 342 any addressed source of law (namely legislation, case law and 343 administrative acts), issued by any authority (intergovernmental, 344 supranational, national, regional and local) at any time (past, 345 present and future); 346 - a resolution mechanism - in a distributed environment - that ties a 347 uniform name to the on-line location of the corresponding 348 resource(s). 349 This document considers the first of these requirements. It also 350 contains a few references to the architecture of the resolution 351 service and to the corresponding software. 353 1.5 Linking a LEX Name to a Document 355 The LEX name is linked to the document through meta-information which 356 may be specified: 357 - internally to the document itself through a specific element within 358 an XML schema or by an [HTML] META tag; 359 - externally by means of a Resource Description Framework [RDF] 360 triple, a specific attribute in a database, etc. 361 At least one of these modalities is necessary for enabling automated 362 construction and updating of catalogues (distributed and centralized) 363 and the implementation of resolvers that associate the uniform name 364 of a document with its physical location(s). LEX assumes no 365 particular relationship between the originator of the document, its 366 publisher, and the implementer of catalogues or resolution services. 367 They may be the same entity, or not. 369 1.6 Use of LEX Names in References 371 LEX names can be used in references as a HREF attribute value of the 372 hypertext link to the referred document. 373 This link can be created in two ways: 374 - by manually inserting, in the referring document, the link with the 375 uniform name: this is a burdensome procedure especially for 376 documents that are already on-line; 377 - by automatically constructing (either permanently or temporarily) 378 the link with the uniform name, through reference parsers of a 379 text: this is a more time-saving procedure even if subject to a 380 certain percentage of errors, since references are not always 381 accurate or complete. This solution could nevertheless be 382 acceptable for already published documents. 383 In any case, whatever the method adopted is, new documents produced 384 in XML format (compliant with the DTD/XMLSchema defined in the 385 related country) should express references through the uniform name 386 of the document referred to. 388 1.7 Definitions 390 According to this document, the following terms are used in the 391 following meaning: 392 - Source of Law: 393 is a general concept, and is used to refer to legislation, case 394 law, regulations and administrative acts. In its broadest sense, 395 the source of law is anything that can be conceived of as the 396 originator of 'erga omnes' legal rules. In this document "source of 397 law" refers also to acts during their formation cycle as bills that 398 might or might not become sources of law; 399 - Jurisdictional Registrar: 400 is an organization which shares and defines in any country or 401 jurisdiction the assignment of the main components of the resource 402 identifier through which the identifier uniqueness is guaranteed. 403 This task includes the definition of allowed jurisdiction names and 404 units, as well as the primary elements (issuing authorities and 405 type of legal measures) of LEX URNs according to the 406 characteristics of the jurisdiction or institutions organization. 408 1.8 Terminology 410 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 411 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 412 "OPTIONAL" in this document are to be interpreted as described in BCP 413 14 [RFC2119] [RFC8174] when, and only when, they appear in all 414 capitals, as shown here. 415 1.9 Syntax Used in this Document 417 This document uses the syntax common to many Internet RFCs, which is 418 based on the ABNF (Augmented Backus-Naur Form) [RFC5234] meta- 419 language. 421 2 Registration Template 423 This section provides the details of the URN registration using the 424 template and guidance found in [RFC8141]. 426 Namespace Identifier: 428 "lex" requested according to [RFC8141]. 430 Version: 432 1.0 434 Date: 436 2021-04-26 438 Registrant: 440 National Research Council of Italy (CNR) 441 Via de' Barucci, 20 442 50127 Florence 443 Italy 444 e-mail: lex@ittig.cnr.it 445 phone: +39 055 43995 447 contact: Enrico Francesconi 448 e-mail: enrico.francesconi@cnr.it 450 Purpose: 452 The purpose of the "lex" namespace is to assign an unequivocal 453 identifier, in well-defined format, to documents that are 454 sources of law. 456 This specification of an unequivocal identifier for legal 457 documents follows a number of initiatives in the field of legal 458 document management. Those initiatives were aimed at 459 introducing standards for sources of law identification and 460 mark-up using URI and XML techniques, respectively (for more 461 details see Section 1.3). The LEX identifier is conceived to 462 be general enough, so as to provide guidance at the core of the 463 specification and sufficient flexibility to cover a wide 464 variety of needs for identifying all the legal documents of 465 different nature, namely legislative, case-law and 466 administrative acts. Moreover, it can be effectively used 467 within a federative environment where different publishers 468 (public and private) can provide their own items of an act 469 (that is there is more than one manifestation of the same act). 471 The LEX identifier is conceived to be: globally unique, 472 transparent, reversible, persistent, location-independent, and 473 language-neutral. It is organized into parts. The first part 474 uses a predetermined standard to specify the country (or more 475 generally the jurisdiction) of origin for the legal document 476 being identified; the remainder is intended for local use in 477 identifying documents issued in that country or jurisdiction. 478 This second part depends only on the system of sources of law 479 identification operating in that nation and it is mainly 480 composed by formalized information related to the enacting 481 authority, the type of measure, the details and possibly the 482 annex. For more details on the nature of the LEX 483 characteristics and the general internal organization, see 484 Section 1.4. 486 The LEX name is linked to the document through specific meta- 487 information, internally (with a tag) or externally (with a 488 attribute) (for details on this see Section 1.5) 490 LEX names can be used in references either in (X)HTML document 491 or, more generally, in XML documents format (compliant with the 492 DTD/XMLSchema defined in the related country) (see Section 1.6 493 for more information). 495 Syntax: 497 The identifier has a hierarchical structure as follows: 499 "urn:lex:" NSS 501 where is the Namespace Specific String composed as 502 follows: 504 NSS = jurisdiction ":" local-name 506 where: 508 is the part providing the identification of the 509 jurisdiction, identifying the scope (state, regional, 510 municipal, supranational or of an organization) where a set of 511 sources of law have validity. It is also possible to represent 512 international organizations (either states or public 513 administrations or private entities); 515 is the uniform name of the source of law in the 516 country or jurisdiction where it is issued; its internal 517 structure is common to the already adopted schemas. It is able 518 to represent all the aspects of an intellectual production, as 519 it is a legal document, from its initial idea, through its 520 evolution during the time, to its realisation by different 521 means (paper, digital, etc.). 523 LEX specifications give information on the internal structure 524 of both and , including 525 specifications about case sensitivity, the use of national 526 characters and diacritics, as well as spaces, connectives, 527 punctuation marks, abbreviations, acronyms, date formats and 528 ordinal numbers. For more details on the internal structure and 529 syntax of the LEX identifier, see Section 3, 4 and 5. 531 The use of r- and q- components, introduced by [RFC8141], with 532 LEX URNs is not defined in this document. However a LEX URNs 533 resolution system can be developed to deal with such components 534 according to the semantics specified in [RFC8141]. 536 Assignment: 538 The Jurisdictional Registrar (or those it delegates) of each 539 adhering country or organization is responsible for the 540 definition or acceptance of the uniform name's primary elements 541 (issuing authority and type of legal measure). 543 Any country or jurisdiction, aiming to adopt this schema, 544 identifies a Jurisdictional Registrar, an organization which 545 shares and defines the structure of the optional part of the 546 name, according to the organization of the state or 547 institution. The process of assigning the will be 548 managed by each specific country or jurisdiction under the 549 related element (details on this can be found in 550 Section 7.2). 552 Identifiers in the "lex" namespace are defined through a 553 field assigned to the sources of law of a 554 specific country or organization, and a assigned 555 by the issuing authority. The goal of the LEX schema is to 556 maintain uniqueness and persistence of all resources identified 557 by the assigned URNs. The values of the elements for the LEX 558 identifier within a jurisdiction are defined by the 559 Jurisdictional Registrar. This ensures that the constructed 560 URNs are unique (see Section 7.3 for details on uniqueness). 562 The persistence of identifiers depends on the durability of the 563 institutions that assign and administer them (see Section 7.3 564 for details on persistence). 566 Security and Privacy: 568 This document introduces no additional security considerations 569 beyond those associated with the use and resolution of URNs in 570 general. 572 Interoperability: 574 As an openly specified naming convention to identify sources of 575 law at international level, LEX is meant to guarantee 576 interoperability among legal information systems across 577 national boundaries. 579 The characteristics of the LEX naming convention facilitate 580 legal document management as well as providing a mechanism of 581 stable cross-collections and cross-country references, thus 582 allowing the distribution of the legal information towards a 583 federated architecture. 585 Resolution: 587 The resolution service associates a LEX identifier with a 588 specific document address on the internet. The architecture of 589 the resolution service will be organized in two fundamental 590 components: a chain of information in DNS (Domain Name System) 591 and a series of resolution services from URNs to URLs, each 592 competent within a specific domain of the namespace (see 593 Section 8.1 for more details). 595 To cope with possible incomplete or inaccurate uniform names, 596 the implementation of a catalogue, based on a relational- 597 database, able to associate a URN to related URLs, is 598 suggested, as it will lead to a higher flexibility in the 599 resolution process. A resolver can provide names normalization, 600 completion of inaccurate or incomplete names, and finally their 601 resolution in network locations (see Section 8.2 and 8.3 for 602 characteristics and behaviour of a catalogue for resolution). 604 Documentation: 606 The syntax, semantics and usage details of LEX URNs are given 607 in [this RFC]. 609 Additional Information: 611 See [FRAN] and [SPIN]. 613 Revision Information: 615 None 617 3 Specifications of Registration 619 3.1 Identifier Structure 621 The element is composed of two specific fields: 623 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 625 where: 627 is usually the identification code of the country 628 where the source of law is issued. 630 To facilitate the transparency of the name, the 631 follows usually the rules of identification of other Internet 632 applications, based on Domain Name (for details or special cases see 633 Section 11.2). 634 Where applicable, the ccTLD, or the TLD, or the Domain Name of the 635 country or multinational or international organisation is used. If 636 such information is not available for a particular institution, a 637 specific code will be defined (see Section 11.2). 638 Examples reported in this document are hypothetical and assumed that 639 the corresponding Domain Name is used for the . 641 However, a special register for the is required, 642 the rules of which are defined in section 11.2. 644 are the possible administrative hierarchical sub- 645 structures defined by each country or organisation within their 646 specific legal system. This additional information can be used in 647 case two or more levels of legislative or judicial production exist 648 (e.g., federal, state and municipality level) and the same bodies may 649 be present in each jurisdiction. Therefore acts of the same type 650 issued by similar authorities in different areas differ for the 651 jurisdiction-unit specification. An example can be the following: 652 "br:governo:decreto" (decree of federal government), 653 "br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state) and 654 "br;sao.paulo;campinas:governo:decreto" (decree of Campinas 655 municipality). 657 Examples (hypothetical) of sources of law identifiers are: 659 urn:lex:it:stato:legge:2003-09-21;456 (Italian act) 660 urn:lex:fr:etat:loi:2004-12-06;321 (French act) 661 urn:lex:es:estado:ley:2002-07-12;123 (Spanish act) 662 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 (Glarus Swiss Canton 663 decree) 664 urn:lex:eu:commission:directive:2010-03-09;2010-19-EU (EU Commission 665 Directive) 666 urn:lex:us:supreme.court:decision:1963-03-18;372.us.335 (US SC 667 decision) 668 urn:lex:be:conseil.etat:decision:2008-07-09;185.273 (Decision of the 669 Belgian Council of State) 671 3.2 Conformance with URN Syntax 673 The "lex" NID syntax conforms to [RFC8141]. However, a series of 674 characters are reserved to identify elements or sub-elements, or for 675 future extensions of the LEX naming convention (see Section 4.2). 677 3.3 Validation Mechanism 679 The Jurisdictional Registrar (or those it delegates) of each adhering 680 country or organization is responsible for the definition or 681 acceptance of the uniform name's primary elements (issuing authority 682 and type of legal measure). 684 3.4 Scope 686 Global interest. In fact each body that enacts sources of law can 687 identify them by this scheme. Furthermore, other bodies (even not 688 enacting sources of law, such as newspaper or magazine publishers, 689 etc.) aiming to refer legal documents, can unequivocally identify 690 them by this scheme. 692 4 General Syntax and Features of the LEX Identifier 694 This section lists the general features applicable to all 695 jurisdictions. 697 4.1 Allowed and Not Allowed Characters 699 These characters are defined in accordance with the [RFC8141] 700 "Uniform Resource Names (URNs)". For various reasons, later 701 explained, in the "lex" only a sub-set of characters is 702 allowed. All other characters are either eliminated or converted. 704 For the full syntax of the uniform names in the "lex" space, please 705 see Attachment A. 707 4.2 Reserved Characters 709 These characters MUST always and uniquely be used for the purpose 710 assigned below. 711 The first category includes those characters bearing a specific 712 meaning in the general creation of the URI (Uniform Resource 713 Identifier)(see Section 2 of [RFC3986]) such as "%", "?", "#" , etc. 715 The following characters instead are reserved in the specific "lex" 716 namespace: However, the following reserved characters are given 717 special meaning in the specific "lex" namespace: 719 - "@" separator of the expression, that contains information on 720 version and language; 721 - "$" separator of the manifestation, that contains information on 722 format, editor, etc.; 723 - ":" separator of the main elements of the name at any entity; 724 - ";" separator of level. It identifies the introduction of an 725 element at a hierarchically lower level, or the introduction of a 726 specification; 727 - "+" separator of the repetitions of an entire main element (e.g., 728 multiple authorities); 730 - "," separator of the repetitions of individual components in the 731 main elements, each bearing the same level of specificity (e.g., 732 multiple numbers); 733 - "~" separator of the partition identifier in references (e.g., 734 paragraph of an article); 735 - "*" and "!" are reserved for future expansions. 737 To keep backward compatibility with existing applications in some 738 jurisdictions, the "lex" NID syntax does not include the use of the 739 character "/" in this version. This character will be converted into 740 "-" (see Sections 6.7 and B3.4) or into "." (see Section B4.2). 742 4.3 Case Sensitivity 744 Names belonging to the "lex" namespace are case-insensitive. It is 745 RECOMMENDED that they be created in lower case, but names that differ 746 only in case MUST be considered to be equivalent. 747 (e.g., "Ministry" will be recorded as "ministry"). 749 4.4 National Characters and Diacritic Signs 751 In order to exploit DNS as a routing tool towards the proper 752 resolution system, to keep editing and communication more simple and 753 to avoid character percent-encoding, it is strongly RECOMMENDED that 754 national characters and diacritic signs are turned into base ASCII 755 characters (e.g., the Italian term "sanitU+00E0" converted into 756 "sanita", the French term "ministU+00E8re" converted into 757 "ministere"), in case by transliteration (e.g. "MU+00FCnchen" 758 converted into "muenchen"). 759 This conversion consists of: 760 - transcription from non-Latin alphabets; 761 - transliteration of some signs (diaeresis, eszett, ...); 762 - preservation of the only basic characters, eliminating the signs 763 placed above (accents, tilde, ...), below (cedilla, little tail, 764 ...) or on (oblique cut, ...). 766 If this conversion is not acceptable by a specific jurisdiction or is 767 not available in a given language, UTF-8 %-encoding [STD63] MUST be 768 used. In this case it should be noted that the generated URN (as some 769 of its parts) can not be used directly for routing through DNS, and 770 therefore the jurisdiction must adopt one of the following 771 strategies: 772 - to convert non-ASCII characters within the DNS into the IDN 773 encoding, using the [RFC5894] punycode translation (ex: 774 mU+00FCnchen in xn--mnchen-3ya), and to develop an interface 775 software that converts the URN before the navigation in DNS, or 776 - to create a routing service relying to a software, out of DNS, 777 addressing a proper resolution service. 779 Summarizing, the preference order is the following: 780 - Conversion into base ASCII (RECOMMENDED solution); 781 - Conversion to punycode only for navigation in DNS, via software 782 interface; 783 - Creation of a routing service relying on a software, out of DNS, 784 addressing a proper resolution service. 785 The first solution allows native DNS routing, while the other two 786 require a software development for the interface or the routing. 787 However it is up to the specific jurisdiction to choose the preferred 788 solution. 790 Two examples (Latin and Cyrillic alphabet) relating to the different 791 solutions adopted are here reported: 793 a. a circular adopted by the Municipality of Munich (Rundschreiben 794 der Stadt MU+00FCnchen): 795 - ascii = urn:lex:de:stadt.munchen:rundschreiben:... 796 - utf-8 = urn:lex:de:stadt.mU+00FCnchen:rundschreiben:... 797 - punycode = urn:lex:de:stadt.xn--mnchen-3ya:rundschreiben:... 799 b. a state law of the Russian Federation (latin: gosudarstvo zakon; 800 cyrillic: U+0441U+043EU+0441U+0442U+043EU+044FU+043DU+0438U+0435 801 U+0437U+0430U+043AU+043EU+043D): 802 - ascii = urn:lex:ru:gosudarstvo:zakon:... 803 - utf-8 = urn:lex:ru:U+0441U+043EU+0441U+0442U+043EU+044FU+043D 804 U+0438U+0435:U+0437U+0430U+043AU+043EU+043D:... 805 - punycode = urn:lex:ru:xn--80aebe3cdmfdkg:xn--80ankme:... 807 assuming that the Russia jurisdiction-code is expressed in ASCII 808 ("ru"), while the Cyrillic version ("U+0440U+0444") has the puny- 809 code "xn--p1ai". 811 4.5 Abbreviations 813 Abbreviations are often used in law for indicating institutions (e.g. 814 Min.), structures (e.g. Dept.), or legal measures (e.g. Reg.) but not 815 in a uniform way, therefore their expansion is highly RECOMMENDED. 816 (e.g., "Min." is reported as "ministry") 818 4.6 Date Format 820 Dates are expressed by numbers in the [ISO8601] format: 822 yyyy-mm-dd 824 (e.g., "September 2, 99" will be written as "1999-09-02") 826 5 Specific Syntax and Features of the LEX Identifier 827 In this section there are other features related to specific 828 jurisdictions and the implementation of which is RECOMMENDED. 830 5.1 Spaces, Connectives and Punctuation Marks 832 All the language connectives (e.g., articles, prepositions, etc.), 833 the punctuation marks and all the special characters (as apostrophes, 834 dashes, etc.), when explicitly present, are eliminated (no 835 transformation occurs in cases of languages with declensions or 836 agglutinating languages). The words left are connected to each other 837 by a dot (".") which substitutes the "space". 838 (e.g., "Ministry of Finances, Budget and of Economic Planning" 839 becomes "ministry.finances.budget.economic.planning"; 840 "Ministerstvo Finansov" becomes "ministerstvo.finansov") 842 5.2 Acronyms 844 The use of acronyms might be confusing and encourage ambiguity in 845 uniform names (the same acronym may indicate two different 846 institutions or structures), therefore their expansion is highly 847 RECOMMENDED. 848 (e.g., "FAO" is expanded as "food.agriculture.organization") 850 5.3 Ordinal Numbers 852 To even the representation, it is highly RECOMMENDED that any ordinal 853 number included in a component of a document name (e.g., in the 854 description of an institution body) is indicated in Western Arabic 855 numerals, regardless to the original expression: whether in Roman 856 numerals, or with an adjective, or in Arabic numeral with apex, etc. 857 (IV, third, 1U+00B0, 2^, etc.). 858 (e.g., "Department IV" becomes "department.4") 860 6 Creation of the Source of Law LEX Identifier - Baseline structure 862 6.1 Basic Principles 864 The uniform name must identify one and only one document (more 865 precisely a "bibliographic resource" [ISBD], see also Section 6.2) 866 and is created in such a way that it is: 867 - self-explanatory ; 868 - identifiable through simple and clear rules; 869 - compatible with the practice commonly used for references; 870 - able to be created from references in the text, automatically (by 871 parser) or manually; 872 - representative of both the formal and the substantive aspects of 873 the document. 875 6.2 Model of Sources of Law Representation 877 According to [FRBR] (Functional Requirements for Bibliographic 878 Records) model developed by IFLA (International Federation of Library 879 Associations and Institutions), in a source of law, as in any 880 intellectual production, 4 fundamental entities (or aspects) can be 881 specified. 883 The first 2 entities reflect its contents: 884 - work: identifies a distinct intellectual creation; in our case, it 885 identifies a source of law both in its being (as it has been issued 886 or proposed) and in its becoming (as it is modified over time); 887 - expression: identifies a specific intellectual realisation of a 888 work; in our case it identifies every different (original or up-to- 889 date) version of the source of law over time and/or language in 890 which the text is expressed; 891 while the other 2 entities relate to its form: 892 - manifestation: identifies a concrete realisation of an expression; 893 in our case it identifies realizations in different media 894 (printing, digital, etc.), encoding formats (XML, PDF, etc.), or 895 other publishing characteristics; 896 - item: identifies a specific copy of a manifestation; in our case it 897 identifies individual physical copies as they are found in 898 particular physical locations. 900 In this document the [FRBR] model has been interpreted for the 901 specific characteristics of the legal domain. In particular, apart 902 from the language which does produce a specific expression, the 903 discriminative criterion between expression and manifestation is 904 based on the difference of the juridical effects that a variation can 905 provide with respect to the involved actors (citizens, parties, 906 institutions). In this scenario the main characteristic of the 907 expression of an act is represented by its validity over the time, 908 during which it provides the same juridical effects. These effects 909 change for amendments or annulments of other legislative or 910 jurisprudential acts. Therefore notes, summarizations, comments, 911 anonymizations and other editorial activities over the same text do 912 not produce different expressions, but different manifestations. 914 6.3 The Structure of the Local Name 916 The within the "lex" namespace MUST contain all the 917 necessary pieces of information enabling the unequivocal 918 identification of a legal document. If the violates 919 this requirement, the related URN is not a valid one within the "lex" 920 namespace. 921 In the legal domain, at the "work" level, three components are always 922 present: the enacting authority, the type of provision and the 923 details. A fourth component, the annex, can be added if any. 924 It is often necessary to differentiate various expressions, that is: 925 - the original version and all the amended versions of the same 926 document; 927 - the versions of the text expressed in the different official 928 languages of the state or organization. 929 Finally the uniform name allows a distinction among diverse 930 manifestations, which may be produced by multiple publishers using 931 different means and formats. 932 In every case, the basic identifier of the source of law (work) 933 remains the same, but information is added regarding the specific 934 version under consideration (expression); similarly a suffix is added 935 to the expression for representing the characteristics of the 936 publication (manifestation). 937 Information which forms a source of law uniform name at each level 938 (work, expression, manifestation) is expressed in the official 939 language of the related jurisdiction; in case of multiple official 940 languages (as in Switzerland) or more involved jurisdictions (as in 941 international treaties), more language-dependent names (aliases) are 942 created. 944 Therefore, the more general structure of the local name appears as 945 follows: 947 local-name = work ["@" expression] ["$" manifestation] 949 However, consistent with legislative practice, the uniform name of 950 the main original provision (work) becomes the identifier of an 951 entire class of documents which includes: the original main document, 952 the annexes, and all their versions, languages and formats 953 subsequently generated. 955 6.4 Structure of the Document Identifier at Work Level 957 The structure of the document identifier is made of the four 958 fundamental elements mentioned above, clearly distinguished one from 959 the other in accordance with an order identifying increasingly narrow 960 domains and competences: 962 work = authority ":" measure ":" details *(":" annex) 964 where: 966 is the issuing or proposing authority of the measure 967 (e.g., State, Ministry, Municipality, Court, etc.); 969 is the type of the measure, both public nature (e.g., 970 constitution, act, treaty, regulation, decree, decision, etc.) as 971 well as private one (e.g., license, agreement, etc); 973
are the terms associated to the measure, typically the date 974 (usually the signature date) and the number included in the heading 975 of the act; 977 is the identifier of the annex, if any (e.g., Annex 1). 979 In case of annexes, both the main document and its annexes have their 980 own uniform name so that they can individually be referenced; the 981 identifier of the annex adds a suffix to that of the main document. 982 In similar way the identifier of an annex of an annex adds an ending 983 to that of the annex which it is attached to. 985 The main elements of the work name are generally divided into several 986 elementary components, and, for each, specific rules of 987 representation are established (criteria, modalities, syntax and 988 order). 989 For the details regarding each element, please see the Attachment B. 991 Examples (hypothetical) of identifiers are: 993 urn:lex:it:stato:legge:2006-05-14;22 994 urn:lex:uk:ministry.justice:decree:1999-10-07;45 995 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 996 urn:lex:es:tribunal.supremo:decision:2001-09-28;68 997 urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762 998 urn:lex:br:estado:constituicao:1988-10-05;lex-1 999 urn:lex:un.org:united.nations;general.assembly:resolution: 1000 1961-11-28;a-res-1661 1001 urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581 1003 It is worth to note that the type of measure is important to identify 1004 case law, as well as legislation, especially within the legal systems 1005 where cases, by tradition, are identified only through the year of 1006 release and a number. Since the aim of the "urn:lex" schema is to 1007 identify specific materials, the type of measure or the full date are 1008 able to provide discrimination between materials belonging to a 1009 specific case. 1011 Here below is an example where the type of measure or the full date 1012 are essential for identify specific materials of a case: 1013 - 4/59 Judgement of the EEC Court of Justice 04/04/1960, Mannesmann 1014 AG and others / ECSC High Authority 1015 urn:lex:eec.lex.arpa:court.justice:judgement:1960-04-04;4-59 1016 - 4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG 1017 and others / ECSC High Authority 1018 urn:lex:eec.lex.arpa:court.justice:order:1960-05-18;4-59 1020 6.5 Aliases 1022 International treaties involve more jurisdictions (the signing ones) 1023 so they are represented through more identifiers, each of them 1024 related to an involved jurisdiction. For example, a bilateral France 1025 and Germany treaty is identified through two URNs (aliases) belonging 1026 to either "fr" or "de" jurisdiction 1027 (e.g., "urn:lex:fr:etat:traite:..." and 1028 "urn:lex:de:staat:vertrag:...") 1029 since it pertains to both the French and the German jurisdiction. 1031 In the states or organisations that have more than one official 1032 language, a document has more identifiers, each of them expressed in 1033 a different official language, basically a set of equivalent aliases. 1034 This system permits manual or automated construction of the uniform 1035 name of the referred source of law in the same language used in the 1036 document itself. 1037 (e.g., "urn:lex:eu:council:directive:2004-12-07;31", 1038 "urn:lex:eu:consiglio:direttiva:2004-12-07;31", etc.) 1040 Moreover, a document can be assigned more than one uniform name in 1041 order to facilitate its linking from other documents. This option can 1042 be used for documents that, although unique, are commonly referenced 1043 from different perspectives. For example, the form of a document's 1044 promulgation and its specific content (e.g., a Regulation promulgated 1045 through a Decree of the President of the Republic). 1047 6.6 Structure of the Document Identifier at Expression Level 1049 There may be several expressions of a legal text, connected to 1050 specific versions or languages. 1051 Each version is characterized by the period of time during which that 1052 text is to be considered as the valid text (in force or effective). 1053 The lifetime of a version ends with the issuing of the subsequent 1054 version. 1055 New versions of a text may be brought into existence by: 1056 - changes in the text (amendments) due to the issuing of other legal 1057 acts and to the subsequent production of updated or consolidated 1058 texts; 1059 - correction of publication errors (rectification or errata corrige); 1060 - entry into or departure from a particular time span, depending on 1061 the specific date in which different partitions of a text come into 1062 force. 1063 Each of such versions may be expressed in more than one language, 1064 with each language-version having its own specific identifier. 1065 The identifier of a source of law expression adds such information to 1066 the work identifier, using the following main structure: 1068 expression = version [":" language] 1070 where: 1072 is the identifier of the version of the (original or 1073 amended) source of law. In general it is expressed by the 1074 promulgation date of the amending act; anyway other specific 1075 information can be used for particular documents. If necessary, the 1076 original version is specified by the string "original", expressed in 1077 the language of the act or version (for the details regarding this 1078 element, please see the Attachment C); 1080 is the identification code of the language in which the 1081 document is expressed, according to [BCP47] (it=Italian, fr=French, 1082 de=German, etc.). The granularity level of the language (for example 1083 the specification of the German language as used in Switzerland 1084 rather than the standard German) is left to each specific 1085 jurisdiction. The information is not necessary when the text is 1086 expressed in the unique official language of the country or 1087 jurisdiction. 1089 Examples (hypothetical) of document identifiers for expressions are: 1091 urn:lex:ch:etat:loi:2006-05-14;22@originel:fr 1092 (original version in French) 1093 urn:lex:ch:staat:gesetz:2006-05-14;22@original:de 1094 (original version in German) 1095 urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr 1096 (amended version in French) 1097 urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de 1098 (amended version in German) 1099 urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr 1100 (original version in French of a Belgian decision) 1102 6.7 Structure of the Document Identifier at Manifestation Level 1104 To identify a specific manifestation, the uniform name of the 1105 expression is followed by a suitable suffix containing the following 1106 main elements: 1107 - : the digital format (e.g., XML, HTML, PDF, etc.) expressed 1108 according to the MIME Content-Type standard [RFC2045], where the 1109 "/" character is to be substituted by the "-" sign; 1110 - : editorial staff who produced it, expressed according to 1111 its Internet domain name. Since publishers' domain names may vary 1112 over time, manifestations already assigned by a publisher remain 1113 unchanged even if the identified object is no longer accessible. In 1114 this case, in order to make its materials accessible, the publisher 1115 will have to create for each of them a new manifestation with the 1116 new domain name; 1117 - : possible components of the expressions contained in 1118 the manifestation. Such components are expressed by language- 1119 dependent labels representing the whole document (in English "all") 1120 or the main part of the document (in English "body") or the caption 1121 label of the component itself (e.g. Table 1, Figure 2, etc.); 1122 - : other features of the document (e.g., anonymized 1123 decision text). 1125 The suffix will thus read: 1127 manifestation = editor ":" format 1128 [":" component [":" feature]] 1130 To indicate possible features or peculiarities, each main element of 1131 the manifestation MAY be followed by further specifications 1132 (separated by ";"), for example as regards the archive name 1133 and the electronic publisher, for the version, etc. 1134 Therefore the main elements of the manifestation will assume the 1135 forms: 1137 editor = publisher *(";" specification) 1138 format = mime *(";" specification) 1139 component = part *(";" specification) 1140 feature = attribute *(";" specification) 1142 The syntax details of the element is shown in 1143 attachment A, in the related section. 1145 (examples (hypothetical): 1146 the original version the Italian act 3 April 2000, n. 56 might have 1147 the following manifestations with their relative uniform names: 1148 - PDF format (vers. 1.7) of the whole act edited by the Italian 1149 Parliament: 1150 "urn:lex:it:stato:legge:2000-04-03;56$application- 1151 pdf;1.7:parlamento.it" 1152 - XML format (version 2.2 DTD NIR) of the text of the act and PDF 1153 format (version 1.7) of the "Figura 1" (figure 1) contained in the 1154 body, edited by the Italian Senate: 1155 "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd- 1156 nir-2.2:senato.it:testo" 1157 "urn:lex:it:stato:legge:2000-04-03;56$application- 1158 pdf;1.7:senato.it:figura.1" 1160 the Spanish URN of the html format of the whole Judgement of the 1161 European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, 1162 published in the Jurifast data base in anonymized form: 1163 "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33- 1164 08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo") 1166 Furthermore, it is useful to be able to assign a uniform name to a 1167 manifestation (or to a part of it) in case non-textual objects are 1168 involved. These may be multimedia objects that are non-textual in 1169 their own right (e.g. geographic maps, photographs, etc.), or texts 1170 recorded in non-textual formats, such as image scans of documents. 1172 In these ways, a LEX name permits: 1173 - exploitation of all the advantages of an unequivocal identifier 1174 that is independent of physical location; 1175 - a means to provide choice among different existing manifestations 1176 (e.g. XML or PDF formats, resolution degree of an image etc.) of 1177 the same expression. 1179 6.8 Sources of Law References 1181 References to sources of law often refer to specific partitions of 1182 the act (article, paragraph, etc.) and not to the entire document. 1184 From a legal point of view, a partition is always a text block, that 1185 represents a logical subdivision of an act. 1186 As regards the digital representation, in a structured format (as 1187 XML) perfectly fitting the document logical structure, a partition is 1188 represented by an element (a block of text) with its own ID; this ID 1189 aims to identify the related element and to locate it. In this case, 1190 therefore, it is possible either to extract or to point to a 1191 partition. 1192 In a mark-up not fitting the logical structure of the text (as HTML), 1193 generally only the starting point of the partition, rather than the 1194 whole block of text or element, is identified through a label (a tag in Html Markup Language [HTML]). In this case 1196 therefore it is not possible to extract a partition but only to point 1197 to it. 1198 In both cases, having a partition identifier is useful; therefore, 1199 for allowing browsers to point to a specific partition, it is 1200 necessary that such partition is endowed with an unequivocal label or 1201 ID within the including document and its value is the same 1202 independently from the document format. 1204 For enabling the construction of the partition identifier between 1205 different collections of documents, specific construction rules for 1206 IDs or labels will be defined and shared, within each country or 1207 jurisdiction, for any document type (e.g., for legislation, the 1208 paragraph 2 of the article 3 might have as label or ID the value 1209 "art3;par2", similarly for case-law, paragraph 22 of the judgement in 1210 Case 46/76 Bauhuis v Netherlands, might have as label or ID the value 1211 "par22"). 1213 Furthermore, it is useful to foresee the compatibility with 1214 applications able to manage this information (e.g., returning the 1215 proper element); these procedures are particularly useful in the case 1216 of rather long acts, such as codes, constitutions, regulations, etc. 1217 For this purpose it is necessary that the partition identifier is 1218 transmitted to the servers (resolution and application) and therefore 1219 it cannot be separated by the typical "#" character of URI fragment, 1220 which is not transmitted to the server. 1222 According to these requirements, the syntax of a reference is: 1224 URN-reference = URN-document ["~" partition-id] 1226 (e.g., to refer to the paragraph 3 of the article 15 of the French 1227 Act of 15 may 2004, n. 106, the reference can be 1228 "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3"). 1230 Using a different separator ("~") from the document name, the 1231 partition ID is not withheld by the browser but it is transmitted to 1232 the resolution process. This enables the resolver to retrieve (for 1233 example, out of a database) only the referred partition, if the 1234 partition syntax is compatible with the media type used, otherwise to 1235 return the whole act. 1236 Anyway, to make it effective in a browser pointing to the indicated 1237 partition, the resolver SHOULD transform the partition ID of each 1238 returned URL in a URI fragment. If this operation cannot be 1239 accomplished, the browser is positioned at the beginning of the 1240 document. The transformation in URI fragment is obtained appending to 1241 the URL the "#" character followed by the partition ID (in the 1242 example above, the returned URL will be #art15;par3). 1243 Doing this, knowing the granularity of the act markup, the resolver 1244 could exploit the hierarchical structure of the ID, eliminating sub- 1245 partitions not addressed. If only the article was identified in the 1246 act, in the previous example it could return #art15 1247 only. 1249 Anyway it is possible to use the general syntax (with "#"); in this 1250 case only the URN document component of the reference is transmitted 1251 to the resolver, therefore the whole document will be always 1252 retrieved. 1254 7 The Procedure of Uniform Names Assignment 1256 7.1 Specifying the Element of the LEX Identifier 1258 Under the "lex" namespace, each country or international organization 1259 is assigned with a jurisdiction code, which characterizes the URNs of 1260 the source of law of that country or jurisdiction. This code is 1261 assigned according to ccTLD (as well as TLDN (Top Level Domain Name) 1262 or DN (Domain Name) for the organizations) representation and it is 1263 the value of the element, which preserves cross- 1264 country uniqueness of the identifiers. 1266 7.2 Jurisdictional Registrar for Names Assignment 1268 Any country or jurisdiction, who intends to adopt this schema, MUST 1269 identify a Jurisdictional Registrar, an organization which shares and 1270 defines the structure of the optional part () of 1271 the name, according to the organization of the state or institution 1272 (for details see Section 11.2). It must appoint a Jurisdictional 1273 Registrar and inform the Designed Experts, together with the 1274 registration of a jurisdiction code. For example, in a federal state 1275 a corresponding to the name of each member state 1276 (e.g. "br;sao.paolo", "br;minas.gerais", etc.) may be defined. 1278 The process of assigning the will be managed by each 1279 specific country or jurisdiction under the related 1280 element. 1281 In any country the Jurisdictional Registrar shares and defines the 1282 assignment of the primary elements (issuing authority and type of 1283 legal measure) of the local names considering the characteristics of 1284 its own state or institution organization. 1285 Such a Registrar MUST establish, according to the guidelines 1286 indicated in the current document, a uniform procedure within the 1287 country or organization to define elements, to take 1288 decisions upon normalizations and finally to solve and avoid possible 1289 name collisions as well as to maintain authoritative registries of 1290 various kinds (e.g., for authorities, types of measures, etc.). In 1291 particular, accurate point-in-time representations of the structure 1292 and naming of government entities are important to semantically-aware 1293 applications in this domain. 1294 Moreover, the Registrar shares and defines the rules to construct 1295 partition IDs for each document type. 1296 Finally, the Registrar will develop and publish the rules and the 1297 guidelines for the construction as well as the 1298 predefined values and codes. The Registrar should also promote the 1299 urn:lex identifier for the sources of law of its jurisdiction. 1301 Such a set of rules will have to be followed by all institutional 1302 bodies adopting the URN LEX identification system in a country or 1303 jurisdiction, as well as by private publishers, and each of them will 1304 be responsible for assigning names to their domains. 1306 7.3 Identifier Uniqueness 1308 Identifiers in the "lex" namespace are defined through a 1309 element assigned to the sources of law of a specific 1310 country or organization, and a assigned by the issuing 1311 authority, in conformance with the syntax defined in Section 6. The 1312 main elements (authority and type of measure) of the are 1313 defined by the Jurisdictional Registrar, so that it is ensured that 1314 the constructed URNs are unique. The Jurisdictional Registrar MUST 1315 provide clear documentation of rules by which names are to be 1316 constructed, and MUST update and make accessible its registries. 1318 Any issuing authority is responsible to define formal parameters to 1319 guarantee local name uniqueness by attributing, if necessary, a 1320 conventional internal number, which, combined with the other components (authority, measure and date), builds an unequivocal 1322 identifier. Uniqueness is achieved by checking against the catalogue 1323 of previously assigned names. 1325 7.4 Identifier Persistence Considerations 1327 The persistence of identifiers depends on the durability of the 1328 institutions that assign and administer them. The goal of the LEX 1329 schema is to maintain uniqueness and persistence of all resources 1330 identified by the assigned URNs. 1332 In particular, the CNR, as proposer, is responsible of maintaining 1333 the uniqueness of the element; given that the 1334 is assigned on the basis of the long-held ccTLD 1335 representation of the country (or the TLDN or DN of the organization) 1336 and that the country or organization associated code is expected to 1337 continue indefinitely, the URN also persists indefinitely. 1339 The rules for the construction of the name are conceived to delegate 1340 the responsibility of their uniqueness to a set of authorities which 1341 is identified within each country or organization. 1343 Therefore, each authority is responsible for assigning URNs which 1344 have a very long life expectancy and can be expected to remain unique 1345 for the foreseeable future. Practical and political considerations, 1346 as well as diverse local forms of government organization, will 1347 result in different methods of assigning responsibility for different 1348 levels of the name. 1349 Where this cannot be accomplished by the implementation of an 1350 authoritative hierarchy, it is highly desirable that it be done by 1351 creating consensus around a series of published rules for the 1352 creation and administration of names by institutions and bodies that 1353 operate by means of collaboration rather than compulsion. 1355 Issuing authorities that operate in more localized scopes, ranging 1356 from the national down to the very local, MUST equally take 1357 responsibility for the persistence of identifiers within their scope. 1359 8 Recommendations for the Resolution Process 1361 8.1 The General Architecture of the System 1363 The task of the resolution service is that of associating a LEX 1364 identifier with a specific document address on the network. By 1365 contrast with systems that can be constructed around rigorous and 1366 enforceable engineering premises, such as DNS, the "lex" namespace 1367 resolver will be expected to cope with a wide variety of "dirty" 1368 inputs, particularly those created by the automated extraction of 1369 references from incomplete or inaccurate texts. In this document, 1370 the result is a particular emphasis on a flexible and robust resolver 1371 design. 1373 The system has a distributed architecture based on two fundamental 1374 components: a chain of information in DNS (Domain Name System) and a 1375 series of resolution services from URNs to URLs, each competent 1376 within a specific domain of the namespace. 1377 The client retrieves the document associated with this URN using the 1378 procedure described in [RFC3404], which starts with a DNS NAPTR 1379 query. 1381 A resolution service can delegate the resolution and management of 1382 hierarchically-dependent portions of the name. 1383 Delegation of this responsibility will not be unreasonably withheld 1384 provided that the processes for their resolution and management are 1385 robust and are followed. 1387 For the "lex" namespace, CNR will maintain in the 1388 (see Section 11.1) the root zone of the chain resolution (equivalent 1389 to "lex.urn.arpa" (see [RFC3405]) and, in correspondence with the 1390 adhesion (see Section 11.2) of a new country (e.g., "br") or 1391 organization, will update the DNS information with a new record to 1392 delegate the relative resolution. This may be obtained by a regular 1393 expression that matches the initial part of the URN (e.g., 1394 "urn:lex:br") and redirects towards the proper zone (e.g., 1395 "lex.senado.gov.br"). 1397 Likewise the institution responsible for the jurisdiction uniform 1398 names (e.g., "urn:lex:br") has the task of managing the relative root 1399 in the DNS system (e.g., "lex.senado.gov.br" zone) and routing the 1400 resolution towards its resolvers on the basis of parts of the uniform 1401 names. In similar way it can delegate the resolution of 1402 country/organization sub-levels (e.g., "urn:lex:br;sao.paolo") 1403 towards the relative zone (e.g., "lex.sao-paolo.gov.br"). 1405 Such DNS routing chain does not work for all the URN components 1406 containing %-encoded characters. Therefore, when converting a lex:URN 1407 in UTF-8 code to a DNS query, clients MUST perform punycode 1408 conversion [RFC5891] before sending the query. 1410 The resolution service is made up of two elements: a knowledge base 1411 (consisting in a catalogue or a set of transformation rules) and a 1412 software to query the knowledge base itself. 1414 8.2 Catalogues for Resolution 1416 Incompleteness and inaccuracy are rather frequent in legal citations, 1417 and incomplete or inaccurate uniform names of the referred document 1418 are thus likely to be built from textual references (this is even 1419 more frequent if they are created automatically through a specific 1420 parser). For this reason, the implementation of a catalogue, based on 1421 a relational-database, is suggested, as it will lead to a higher 1422 flexibility in the resolution process. 1423 In addition the catalogue must manage the aliases, the various 1424 versions and languages of the same source of law as well as the 1425 related manifestations. 1427 It is suggested that each enacting authority implements its own 1428 catalogue, assigning a corresponding unambiguous uniform name to each 1429 resource. 1431 8.3 Suggested Resolver Behaviour 1433 First of all the resolver should separate the part corresponding to 1434 the partition ID, through the "~" separator, from the document name. 1436 So, the resolution process SHOULD implement a normalization of the 1437 uniform name to be resolved. This may involve transforming some 1438 components to the canonical form (e.g., filling out the acronyms, 1439 expanding the abbreviations, unifying the institution names, 1440 standardizing the type of measures, etc.). For this function 1441 authorities and types of measure registers are useful. 1443 The resolver SHOULD then query the catalogue searching for the URN 1444 which corresponds exactly to the given one (normalized if necessary). 1445 Since the names coming from the references may be inaccurate or 1446 incomplete, an iterative, heuristic approach (based on partial 1447 matches) is indicated. It is worth remarking that incomplete 1448 references (not including all the elements to create the canonical 1449 uniform name) are normal and natural; for a human reader, the 1450 reference would be "completed" by contextual understanding of the 1451 reference in the document in which it occurs. 1453 In this phase, the resolver should use the partition ID information 1454 to retrieve, if it is possible, only the referred partition, 1455 otherwise to return of the entire document. 1457 Lacking more specific indications, the resolver SHOULD select the 1458 best (most recent) version of the requested source of law, and 1459 provide all the manifestations with their related items. 1460 A more specific indication in the uniform name to be resolved will, 1461 of course, result in a more selective retrieval, based on any 1462 suggested expression and/or manifestations components (e.g. date, 1463 language, format, etc.). 1465 Finally, the resolver SHOULD append to URLs the "#" character 1466 followed by partition ID, transforming it in a URI fragment for 1467 browser pointing. 1469 9 Namespace Considerations 1471 In collaboration with the legislative XML community, registrants 1472 carried out a preliminary study [SART] of the URI alternatives to 1473 satisfy the key requirements. 1474 The options analysed were: a private URI scheme, URL, PURL and URN. 1475 URN was considered the most appropriate URI given the requirements 1476 analysis. 1477 Advantages we would emphasize are: 1478 - greater flexibility in building the identifier; 1479 - the capacity to represent name components that are not strictly 1480 hierarchical; 1481 - the potential for clear division of the identifier into macro 1482 parts, main elements and components, using different separators; 1483 - ease of managing optional parts of a name. 1485 10 Community Considerations 1487 The use of the "lex" namespace facilitates the interoperability of 1488 information systems used in the Public Administration at the national 1489 and international level. Moreover it allows the distribution of the 1490 legal information towards a federated architecture. In such an 1491 architecture, documents are directly managed by the issuing 1492 authorities, with resulting benefits in information authenticity, 1493 quality and currency. A shared identification mechanism of resources 1494 guarantees that a distributed system will be as efficient and 1495 effective as a comparable centralized system. 1497 Creators of Internet content that references legal materials - 1498 including publishers operating well outside the traditional arenas of 1499 legal publishing - benefit by the registration of the namespace 1500 because it facilitates the linking of legal documents, whether by 1501 manual or automated means, and reduces the cost of maintaining 1502 documents that contain such references. 1504 Any citizen or organisation with Internet web browser capability will 1505 have the possibility to use the namespace and its associated 1506 application, registers, and resolution services, to facilitate 1507 document access (if available). 1509 11 IANA Considerations 1511 11.1 NID Registration 1513 IANA is requested to make an assignment from the "Uniform Resource 1514 Names (URN)" registry described by [RFC8141] to register "lex" 1515 according to the registration request set out in Section 2. The 1516 assignment should be made from the "Formal URN Namespaces" registry. 1518 In addition, to activate a distributed resolution system, the one-off 1519 registration of the following NAPTR records is required: 1521 in the URN.ARPA domain: 1522 IN NAPTR 1 0 "" "" "!^urn:lex:!_lex!i" . 1523 _lex IN NAPTR 10 10 "" "" "" . 1525 in the URN.URI.ARPA domain: 1526 IN NAPTR 1 0 "" "" "!^urn:lex:!_lex!i" . 1527 _lex IN NAPTR 10 10 "" "" "" . 1529 where indicates the server of the organization that 1530 is responsible for the resolution of the "lex" namespace and will be 1531 communicated by the applicant when the application is approved. 1533 11.2 Jurisdiction-code Registration 1535 It is requested to create a new registry for , 1536 with the following format: 1537 - : the identifier code of jurisdiction, assigned 1538 to the country or organisation; 1539 - : the official denomination of the jurisdiction, 1540 country or organisation; 1541 - : essential information to identify the organization 1542 that requested the registration of the code. Such organization will 1543 be responsible for its DNS zone and for the attribution of sub-zone 1544 delegations, and so on. It is desirable that each jurisdiction 1545 creates a register of all delegated levels so that the organization 1546 responsible of each sub-zone can easily be identified; 1547 - : a reference to the defining document (if any). 1549 The table is initially empty. Possible example entries are: 1550 "br"; "Brazil"; "Prodasen, Federal Senate,
, "; 1551 [reference] 1552 "eu"; "European Union"; "DG Digit, European Commission,
, 1553 "; [reference] 1554 "un.org"; "United Nations"; "DPI, United Nations,
, 1555 "; [reference] 1557 CNR will take care to create and maintain the registry for 1558 and the root of the resolution 1559 routing. 1561 A new Jurisdictional Registrar will contact CNR or the Designated 1562 Expert(s) according to the established rules of governance (published 1563 in the CNR website dedicated to the LEX governance). The application 1564 will be evaluated according to the Jurisdictional Registrar 1565 authoritativeness and the offered guarantees. The Designated 1566 Expert(s) will evaluate such applications, with a similar approach as 1567 of the DNS. Typically such applications should come from public 1568 administrations, as authorities enacting sources of law. 1570 The adopted registration policy is compliant with the "Expert Review" 1571 as specified in [RFC8126]. Designated Expert(s) will assign 1572 jurisdiction codes based on the following principles: 1573 - if a request comes from a jurisdiction that corresponds to a 1574 country and the jurisdiction code is the same as a top level ccTLD, 1575 which is not yet registered, then the top level ccTLD should be 1576 used as the jurisdiction code; 1577 - if a request comes from a jurisdiction that corresponds to a multi- 1578 national (e.g., European Union) or international (e.g., United 1579 Nations, World Trade Organization) organizations the Top Level 1580 Domain Name (e.g., "eu") or the Domain Name (e.g., "un.org", 1581 "wto.org") of the organization should be used as the jurisdiction 1582 code; 1583 - in case when such multi-national or international organization does 1584 not have a registered domain, Designated Expert(s) should assign 1585 something like .lex.arpa, where will be the English 1586 acronym of the organization name. For example, the jurisdiction 1587 code of the European Economic Community could be "eec.lex.arpa". 1589 Jurisdiction codes can't be renamed, because allowing for renames 1590 would violate rules that URN assignments are persistent. 1592 Jurisdiction codes can never be deleted. They can only be marked as 1593 "obsolete", i.e. closed for new assignments within the jurisdiction. 1594 Requests to obsolete a jurisdiction code are also processed by 1595 Designated Expert. 1597 Designated Expert(s) can unilaterally initiate allocation or 1598 obsolescence of a jurisdiction code. 1600 Request for new jurisdiction code assignment must include 1601 Organization or Country requesting it and Contact information (email) 1602 of who requested the assignment. 1604 12 References 1606 12.1 Normative References 1608 [BCP47] A. Phillips, M. Davis, "Tags for Identifying Languages", 1609 BCP 47, RFC 5646, September 2009 1611 [STD63] F. Yergeau, "UTF-8, a transformation format of ISO 1612 10646", STD 63, RFC 3629, November 2003. 1614 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1615 Extensions (MIME) Part One: Format of Internet Message 1616 Bodies", RFC 2045, November 1996. 1618 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate 1619 Requirement Levels, BCP 14, RFC 2119, March 1997. 1621 [RFC3404] M. Mealling, Dynamic Delegation Discovery System (DDDS), 1622 Part Four: The Uniform Resource Identifiers (URI) 1623 Resolution Application, RFC 3404, October 2002. 1625 [RFC3405] M. Mealling, Dynamic Delegation Discovery System (DDDS), 1626 Part Five: URI.ARPA Assignment Procedures, RFC 3405, 1627 October 2002. 1629 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1630 Resource Identifiers (URI): Generic Syntax", STD 66, RFC 1631 3986, January 2005. 1633 [RFC5234] D. Crocker Ed., P. Overell, "Augmented BNF for Syntax 1634 Specifications: ABNF", STD 68, RFC 5234, January 2008 1636 [RFC5891] J. Klensin, Internationalized Domain Names in 1637 Applications (IDNA): Protocol, RFC 5891, August 2010. 1639 [RFC5894] J. Klensin, "Internationalized Domain Names for 1640 Applications (IDNA): Background, Explanation, and 1641 Rationale", RFC 5894, August 2010 1643 [RFC7231] R. Fielding, J. Reschke, "Hypertext Transfer Protocol 1644 (HTTP/1.1): Semantics and Content", RFC 7231, June 2014 1646 [RFC8126] M. Cotton, B. Leiba, T. Narten, "Guidelines for Writing 1647 an IANA Considerations Section in RFCs", RFC 8126, June 1648 2017 1650 [RFC8141] P. Saint-Andre, J.C. Klensin, "Uniform Resource Names 1651 (URNs)", RFC 8141, April 2017 1653 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 1654 2119 Key Words", BCP 14, RFC 8174, May 2017. 1656 [RFC8288] M. Nottingham, "Web Linking", RFC 8288, October 2017 1658 [ISO8601] ISO 8601, "Data elements and interchange formats", ISO 1659 8601:2004 1661 [HTML] W3C, HyperText Markup Language, https://www.w3.org/html/ 1663 12.2 Informative References 1665 [FRAN] E. Francesconi, "Technologies for European Integration. 1666 Standards-based Interoperability of Legal Information 1667 Systems", ISBN 978-88-8398-050-3, European Press Academic 1668 Publishing, 2007. 1670 [FRBR] Functional Requirements for Bibliographic Records, 1671 https://www.ifla.org/files/assets/cataloguing/frbr/ 1672 frbr_2008.pdf 1674 [HCPIL] The Hague Conference on Private International Law "Access 1675 to Foreign Law in Civil and Commercial Matters. 1676 Conclusions and Recommendations" 1677 (https://assets.hcch.net/docs/ 1678 b093f152-a4b3-4530-949e-65c1bfc9cda1.pdf) 1680 [ISBD] ISBD: International Standard Bibliographic Description - 1681 Consolidated Edition. Edited by the Standing Committee of 1682 the IFLA Cataloguing Section Berlin/Munich: De Gruyter 1683 Saur, 2011 ISBN 978-3-11-026379-4 (IFLA Series on 1684 Bibliographic Control; Nr 44) 1686 [LVI] Ginevra Peruginelli, Mario Ragona (eds.), "Law via the 1687 Internet. Free Access, Quality of Information, 1688 Effectiveness of Rights", European Press Academic 1689 Publishing, 2008, ISBN 9788883980589. 1691 [RDF] W3C, RDF Schema 1.1, February 2014, 1692 https://www.w3.org/TR/rdf-schema/ 1694 [SART] G. Sartor, M. Palmirani, E. Francesconi, M. Biasiotti 1695 (Eds.), Legislative XML for the Semantic Web. Principles, 1696 Models, Standards for Document Management, Law, 1697 Governance and Technology Series, Springer, 2011, ISBN 1698 978-94-007-1886-9. 1700 [SPIN] P.L. Spinosa, "The Assignment of Uniform Names to Italian 1701 Legal Documents", URN-NIR 1.4, June, 2010, ITTIG 1702 Technical Report n. 8/2010. 1704 13 Acknowledgements 1706 The authors of this document wish to thank all the supporters for 1707 giving suggestions and comments. 1708 They are also grateful to the Legislative XML community for the 1709 interesting discussions on this topic and to the Working Group 1710 "Identification of the legal resources through URNs" of Italian 1711 NormeInRete project for the provided guidance [SPIN]. 1712 The authors owe a debt of gratitude to Tom Bruce, director of the 1713 Legal Information Institute of the Cornell University Law School, for 1714 his contribution in revising this document and sharing fruitful 1715 discussions which greatly improved the final draft. The authors wish 1716 to specially thank Marc van Opijnen (Dutch Ministry of Security and 1717 Justice) for his valuable comments on LEX specifications which 1718 contributed to improve the final result, as well as for the common 1719 work aimed to harmonize ECLI and LEX specifications. Thanks also to 1720 Joao Alberto de Oliveira Lima, legislative system analyst of the 1721 Brazilian Federal Senate, and to Attila Torcsvari, information 1722 management consultant, for their detailed comments on the first 1723 drafts of this document, which provided significant hints to the 1724 final version of the standard, and to Robert Richards of the Legal 1725 Information Institute (Cornell University Law School), promoter and 1726 maintainer of the Legal Informatics Research social network, as well 1727 as to the members of this network, for their valuable comments on 1728 this proposal. 1729 Finally, many thanks go to Loriana Serrotti who significantly 1730 contributed to the first drafting of this document. 1732 14 Author's Addresses 1734 PierLuigi Spinosa 1735 (ICT consultant) 1736 Via Zanardelli, 15 1737 50136 Firenze 1738 Italy 1739 Telephone: +39 339 5614056 1740 e-mail: pierluigi.spinosa@gmail.com 1741 Enrico Francesconi 1742 Consiglio Nazionale delle Ricerche (CNR) 1743 Via de' Barucci, 20 1744 50127 Firenze 1745 Italy 1746 Telephone: +39 055 43995 1747 e-mail: enrico.francesconi@cnr.it 1749 Caterina Lupo 1750 (ICT consultant) 1751 Via San Fabiano, 25 1752 00165 Roma 1753 Italy 1754 Telephone: +39 3382632348 1755 e-mail: caterina.lupo@gmail.com 1757 Attachment A -- Summary of the Syntax of the Uniform Names of the "lex" 1758 Namespace 1760 ;------------------------------------------------------------------- 1761 ; Structure of a Uniform Resource Name (URN) of the "lex" namespace 1762 ; NID-lex = namespace 1763 ; NSS-lex = specific name 1764 ;------------------------------------------------------------------- 1765 URN-lex = "urn:" NID-lex ":" NSS-lex 1767 NID-lex = "lex" 1769 ;------------------------------------------------------------------- 1770 ; Structure of a "lex" specific name 1771 ;------------------------------------------------------------------- 1772 NSS-lex = jurisdiction ":" local-name 1774 ;------------------------------------------------------------------- 1775 ; Structure of the element 1776 ;------------------------------------------------------------------- 1777 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 1779 jurisdiction-code = 2*alf-dot 1781 jurisdiction-unit = alf-dot 1783 ;------------------------------------------------------------------- 1784 ; Structure of the element 1785 ;------------------------------------------------------------------- 1786 local-name = work ["@" expression] ["$" manifestation] 1788 ;------------------------------------------------------------------- 1789 ; Structure of the element 1790 ;------------------------------------------------------------------- 1791 work = authority ":" measure ":" details *(":" annex) 1793 ;------------------------------------------------------------------- 1794 ; Structure of the element 1795 ;------------------------------------------------------------------- 1796 authority = issuer *("+" issuer) 1798 issuer = (institution *(";" body-function)) / office 1800 institution = alf-dot 1802 body-function = alf-dot 1803 office = alf-dot 1805 ;------------------------------------------------------------------- 1806 ; Structure of the element 1807 ;------------------------------------------------------------------- 1808 measure = measure-type *(";" specification) 1810 measure-type = alf-dot 1812 specification = alf-dot 1814 ;------------------------------------------------------------------- 1815 ; Structure of the
element 1816 ;------------------------------------------------------------------- 1817 details = (dates / period) ";" numbers 1819 dates = date *("," date) 1821 period = alf-dot 1823 numbers = (document-id *("," document-id)) / number-lex 1825 document-id = alf-dot-oth 1827 number-lex = "lex-" 1*DIGIT 1829 ;------------------------------------------------------------------- 1830 ; Structure of the element 1831 ;------------------------------------------------------------------- 1832 annex = annex-id *(";" specification) 1834 annex-id = alf-dot 1836 ;------------------------------------------------------------------- 1837 ; Structure of the element 1838 ;------------------------------------------------------------------- 1839 expression = version [":" language] 1841 ;------------------------------------------------------------------- 1842 ; Structure of the element 1843 ;------------------------------------------------------------------- 1844 version = (amendment-date / specification) 1845 *(";" (event-date / event)) 1847 amendment-date = date 1849 event-date = date 1850 event = alf-dot 1852 ;------------------------------------------------------------------- 1853 ; Structure of the element 1854 ;------------------------------------------------------------------- 1855 language = 2*3alfa *["-" extlang] / 4*8alfa 1857 extlang = 3alfa *2("-" 3alfa) 1859 ;------------------------------------------------------------------- 1860 ; Structure of the element 1861 ;------------------------------------------------------------------- 1862 manifestation = format ":" editor 1863 [":" component [":" feature]] 1865 format = mime *(";" specification) 1867 mime = alf-dot-hyp 1869 editor = publisher *(";" specification) 1871 publisher = alf-dot-hyp 1873 component = part *(";" specification) 1875 part = alf-dot-hyp 1877 feature = attribute *(";" specification) 1879 attribute = alf-dot-hyp 1881 ;------------------------------------------------------------------- 1882 ; Structure of the date 1883 ;------------------------------------------------------------------- 1884 date = year "-" month "-" day 1886 year = 4DIGIT 1887 month = 2DIGIT 1888 day = 2DIGIT 1890 ;------------------------------------------------------------------- 1891 ; Allowed, reserved and future characters 1892 ;------------------------------------------------------------------- 1893 ; allowed = alfadot / other / reserved 1894 ; reserved = ":" / "@" / "$" / "+" / ";" / "," / "~" 1895 ; future = "*" / "!" 1897 alf-dot = alfanum *alfadot 1898 alf-dot-hyp = alfanum *(alfadot / "-") 1900 alf-dot-oth = alfanum *(alfadot / other) 1902 alfadot = alfanum / "." 1904 alfa = lowercase / uppercase 1906 alfanum = alfa / DIGIT / encoded 1908 lowercase = %x61-7A ; lower-case ASCII letters (a-z) 1910 uppercase = %x41-5A ; upper-case ASCII letters (A-Z) 1912 DIGIT = %x30-39 ; decimal digits (0-9) 1914 encoded = "%" 2HEXDIG 1916 HEXDIG = DIGIT / %x41-46 / %x61-66 ; hex digits (0-9,A-F,a-f) 1918 other = "-" / "_" / "'" / "=" / "(" / ")" 1919 Attachment B -- Specific Syntax of the Identifier at Work Level 1921 B1 The Element 1923 B1.1 Indication of the Authority 1925 The element of a uniform name may indicate, in the 1926 various cases: 1927 - the actual authority issuing the legal provision. More 1928 specifically, the authority adopting the provision or enacting it; 1929 - the institution where the provision is registered, known and 1930 referenced to, even if produced by others (e.g., the bills 1931 identified through the reference to the Chamber where they are 1932 presented); 1933 - the institution regulated (and referred to in citations) by the 1934 legal provision even when this is issued by another authority 1935 (e.g., the statute of a Body); 1936 - the entity that proposed the legal material not yet included in the 1937 institutional process (e.g. a proposed bill written by a a 1938 political party). 1940 B1.2 Multiple Issuers 1942 Some sources of law are enacted by a number of issuing parties (e.g., 1943 inter-ministerial decrees, agreements, etc.). In this case, the 1944 element contains all the issuing parties (properly 1945 separated), as follows: 1947 authority = issuer *("+" issuer) 1949 (e.g., "ministry.justice+ministry.finances") 1951 B1.3 Indication of the Issuer 1953 Each issuing authority is essentially represented by either an 1954 institutional office (e.g., Prime Minister) or an institution (e.g., 1955 Ministry); in the last case, the authority is indicated in accordance 1956 with the institution's hierarchical structure, from the more general 1957 to more specific (Council, Department, etc.), ending with the 1958 relative office (President, Director, etc.). 1959 Therefore, the structure of the issuer is as follows: 1961 issuer = (institution *(";" body-function)) / office 1963 (e.g., "ministry.finances;department.revenues;manager") 1965 B1.4 Indication of the Body 1966 Depending on the kind of measure, the body within the issuing 1967 authority is unambiguously determined (e.g., the Council for Regional 1968 Acts) and normally it is not indicated in the references. 1969 Just like in practice, the indication of the enacting authority is 1970 limited to the minimum in relation to the type of measure. 1971 (e.g., "region.tuscany:act" and not "region.tuscany;council:act") 1973 B1.5 Indication of the Function 1975 Generally, the function is indicated, sometimes instead of the body 1976 itself: 1977 - in case of political, representative or elective offices 1978 (e.g., "university.oxford;rector:decree" instead of 1979 "university.oxford;rectorship:decree"); 1980 - when it refers to a top officer in the institution (e.g., general 1981 manager, general secretary, etc.) which is not always possible to 1982 associate a specific internal institutional structure to 1983 (e.g., "national.council.research;general.manager"). 1985 It is not indicated when it clearly corresponds to the person in 1986 charge of an institution (typically, a general director); in this 1987 case, only the structure and not the person in charge is indicated 1988 (e.g., "ministry.justice;department.penitentiary.administration"). 1990 The function MUST be indicated when: 1991 - it is not the same of the director or the person in charge of the 1992 structure (for example, in case of an undersecretary, a deputy 1993 director, etc.); 1994 - the type of measure may be both monocratic or collegial: the 1995 indication of the office eliminates the ambiguity. 1997 B1.6 Conventions for the Authority 1999 Acts and measures bearing the same relevance as an act, issued or 2000 enacted since the foundation of the State, have conventionally 2001 indicated "state" (expressed in each country official language) as 2002 authority; the same convention is used for constitutions, codes 2003 (civil, criminal, civil procedure, criminal procedure, etc) and 2004 international treaties. 2006 B2 The Element 2008 B2.1 Criteria for the Indication of the Type of Measure 2010 In uniform names the issuing authority of a document is mandatory. 2011 This makes unnecessary to indicate any further qualification of the 2012 measure (e.g., ministerial decree, directorial ordinance, etc.), even 2013 if it is widely used. 2015 When the authority-measure combination clearly identifies a specific 2016 document, the type of measure is not defined through attributes 2017 referring to the enacting authority. 2018 (e.g., "region.tuscany:act" and not "region.tuscany:regional.act") 2020 B2.2 Further Specification to the Type of Measure 2022 In the element, it is usually sufficient to indicate the 2023 type of a measure. As usual, references to sources of law, rather 2024 than through the formal details (date and number), may be made 2025 through some of their characteristics such as the subject-matter 2026 covered (e.g., accounting regulations), nicknames referring to the 2027 promoter (e.g., Bassanini Act) or to the topic of the act (e.g., 2028 Bankruptcy Law), etc.. 2029 In these cases, the type of measure MAY be followed by further 2030 specifications useful in referencing even if the details are lacking: 2032 measure = measure-type *(";" specification) 2034 (e.g., "regulations;accounting" or "act;bankruptcy") 2036 B2.3 Aliases for Sources of Law with Different Normative References 2038 There are legislative measures that, although unique, are usually 2039 cited in different ways, for example through the legislative act 2040 introducing them into the legal order (President's decree, 2041 legislative decree, etc.) or through their legislative category 2042 (regulations, consolidation, etc.). 2043 In order to ensure, in all the cases, the validity of the references, 2044 an alias (additional URN LEX identifier), that takes into account the 2045 measure category, is added to what represents the legislative form of 2046 the same act. 2047 (e.g., "state:decree.legislative:1992-07-24;358" and 2048 "state:consolidation;public.contracts:1992-07-24;358"). 2050 B2.4 Relations between Measure and Authority in the Aliases 2052 The sources of law including different normative references are 2053 usually introduced in legislation through the adoption or the issuing 2054 of an act, which they are either included or attached to. It is, 2055 therefore, necessary to create an alias linking the two aspects of 2056 the same document. Specifically, the different measures can be: 2057 - adopted/issued by an authority different from the one regulated by 2058 the provision (e.g., the statute of a Body); in this case, the 2059 correlation is established between two uniform names each featuring 2060 a completely different element 2061 (e.g., "italian.society.authors.publishers:statute" and 2062 "ministry.cultural.activities+ministry.finances.budget.economic. 2064 planning:decree"); 2065 - issued by the institution itself either because it has issuing 2066 authority or by virtue of a proxy (e.g., a provision that refers to 2067 the functioning of the Body itself); in this case, the two aliases 2068 share the first part of the authority; 2069 (e.g., "municipality.firenze:statute" and 2070 "municipality.firenze;council:deliberation"); 2071 - issued by the same Body to regulate a particular sector of its own 2072 competence; in this case the element is the same 2073 (e.g., "ministry.justice:regulation;use.information.tools. 2074 telematic.process" and "ministry.justice:decree"). 2076 B3 The
Element 2078 B3.1 Indication of the Details 2080 The details of a source of law usually include the date of the 2081 enactment and the identification number (inclusion in the body of 2082 laws, register, protocol, etc.). 2083 Some measures can have multiple dates; there are also cases in which 2084 the number of the measure does not exist (unnumbered measures) or a 2085 measure has multiple numbers (e.g., unified cases). For these 2086 reasons, the set up of both elements (date and number) includes 2087 multiple values. 2089 Some institutions (e.g., the Parliaments) usually identify documents 2090 through their period of reference (e.g., the legislature number) 2091 rather than through a date, which would be much less meaningful and 2092 never used in references (e.g., Senate bill S.2544 of the XIV 2093 legislature). In these cases, the component is used in 2094 substitution of the component . 2096 Usually details of a measure are not reported according to a specific 2097 sequence; in accordance with the global structure of the uniform 2098 name, which goes from the general to the specific, the sequence date- 2099 number has the following form: 2101 details = (dates / period) ";" numbers 2103 (e.g., "2000-12-06;126", "14.legislature;s.2544") 2105 B3.2 Multiple Dates 2107 Some sources of law, even if unique, are identified by more than one 2108 date; in this case, in the field all the given dates are to 2109 be reported and indicated as follows: 2111 dates = date *("," date) 2113 (e.g., the measure of the Data Protection Authority of December 30, 2114 1999- January 13, 2000, No. 1/P/2000 has the following uniform name: 2115 "personal.data.protection.authority:measure:1999-12-30,2000-01-13; 2116 1-p-2000"). 2118 B3.3 Unnumbered Measures 2120 Measures not officially numbered in the publications may have a non- 2121 unequivolcal identifier, because several measures of the same type 2122 can exist, issued on the same day by the same authority. 2123 To ensure that the uniform name is unambiguous, the field 2124 MUST, in any case, contain a discriminating element, which can be any 2125 identifier used internally, and not published, by the authority 2126 (e.g., protocol). 2127 If the authority does not have its own identifier, one identifier 2128 MUST be created for the name system. In order to easily differentiate 2129 it, such number is preceded by the string "lex-": 2131 number-lex = "lex-" 1*DIGIT 2133 (e.g., "ministry.finances:decree:1999-12-20;lex-3") 2135 It is responsibility of the authority issuing a document to assign a 2136 discriminating specification to it; in case of multiple authorities, 2137 only one of them is responsible for the assignment of the number to 2138 the document (e.g., the proponent). 2139 The unnumbered measures published on an official publication (e.g., 2140 the Official Gazette), instead of by a progressive number are 2141 recognized by the univocal identifying label printed on the paper. 2142 Such an identifier, even if unofficial but assigned to a document in 2143 an official publication, is to be preferred because it has the clear 2144 advantage to be public and therefore easier to be found. 2146 B3.4 Multiple Numbers 2148 Some legal documents (e.g., bills), even if unique, are identified by 2149 a set of numbers (e.g., the unification of cases or bills). 2150 In this case, in the field, all the identifiers are 2151 reported, according to the following structure: 2153 numbers = document-id *("," document-id) 2155 (e.g., "2000-06-12;c-10-97,c-11-97,c-12-97") 2156 The characters which are not allowed (e.g., "/") or reserved (e.g., 2157 ":"), including the comma, cannot exist inside the , and 2158 therefore MUST be turned into "-". 2159 Where special characters contained in the number of the act are 2160 distinctive of the act itself (e.g. bill n. 123-bis (removal of 123) 2161 and n. 123/bis (return of 123)) and would disappear with the 2162 conversion to "-", a further ending must be added, allowing to 2163 distinguish the acts (e.g. bill n.123-bis-removal and 123-bis- 2164 return). 2166 B4 The Element 2168 B4.1 Formal Annexes 2170 Although annexes are an integral part of the legal document, they may 2171 be referred to and undergo amendments separately from the act to 2172 which they are annexed. It is, therefore, necessary that both the 2173 main document as well as each formal individual annex is 2174 unequivocally identified. 2176 Formal annexes may be registered as separate parts or together with a 2177 legal provision; they may also be autonomous in nature or not. In any 2178 case, they MUST be given a uniform name, which includes the uniform 2179 name of the source of law to which they are attached, and a suffix 2180 which identifies the annex itself. 2182 The suffix of formal annexes includes the official heading of the 2183 annex and, possibly, further specifications (e.g., the title) which 2184 will facilitate the retrieval of the annex in case the identifier is 2185 missing: 2187 annex = annex-id *(";" specification) 2189 (e.g., "region.sicily;council:deliberation:1998-02-12;14:annex.a; 2190 borders.park") 2192 The characters which are not allowed (e.g. "/") or which are reserved 2193 (e.g. ":") must not be featured in the and therefore MUST 2194 be turned into ".". 2196 B4.2 Annexes of Annexes 2198 When there are annexes to an annex, their corresponding identifiers 2199 are created by adding to the identifier of the original annex those 2200 of the annexes that are connected with it (that is, attached to it). 2202 (e.g., Table 1 attached to Attachment A of the preceding legal act 2203 has the following uniform name: 2204 "region.sicily;council:deliberation:1998-02-12;14:annex.a; 2205 borders.park:table.1;municipality.territories"). 2207 Attachment C -- Specific Syntax of the Element of the 2208 Expression 2210 C1 The Element 2212 C1.1 Different Versions of a Legislative Document 2214 The creation of an updated text of a document may have one of the 2215 following forms: 2216 - "multi-version": when specific mark-ups which identify the modified 2217 parts of a document (added, substituted or deleted parts) and their 2218 related periods of effectiveness are indicated inside one single 2219 object (e.g., an xml file). Such a document will be able, in a 2220 dynamic way, to appear in different forms according to the 2221 requested date of effectiveness. 2222 In this document type, usually a set of metadata contains the 2223 lifecycle of the document (from the original to the last 2224 modification), including the validity time interval of each version 2225 and of each related text portion; 2226 - "single-version": when, on the contrary, a new and distinct object 2227 is created for each amendment to the text at a given time. Each 2228 object is, therefore, characterized by its own period of validity. 2229 In any case all the versions SHOULD be linked one another and 2230 immediately navigable. 2232 In a "multi-version" document each time interval should have a link 2233 to the related in-force document version which can be therefore 2234 displayed. 2235 In a "single-version" document, the metadata should contain links to 2236 the all the previous modifications and a link only to the following 2237 version, if any. 2239 [RFC8288] can be used as reference to establish links between 2240 different document versions, either in the "multi-version" or in the 2241 "single-version" document. According to [RFC8288] the following 2242 relations are useful: 2243 - current (or last or last-version): in-force version 2244 - self: this version 2245 - next: next version 2246 - previous: previous version 2247 - first: original version 2248 It is RECOMMENDED that these relations are inserted in the header of 2249 each version (if "single-version") or associated to each entry 2250 containing a single URN (if "multi-version"). 2252 C1.2 Identification of the Version 2253 In order to identify the different time versions of the same act, to 2254 the uniform name of the original document has to be added a specific 2255 suffix. 2256 Such a suffix identifies each version of a legal provision and 2257 includes, first and foremost, one of the following elements: 2258 - the issuing date of the last amending measure taken into account; 2259 - the date in which the communication of the rectification or of the 2260 errata corrige, is published; 2261 - a specification which must identify the reason concerning the 2262 amendment (e.g., the specific phase of the legislative process), 2263 for the cases in which the date is not usually used (e.g., bills). 2265 Anyway it is possible to add further specifications that will 2266 distinguish each of the different versions of the text to guarantee 2267 identifier unequivocalness. For example with regard to changes of the 2268 in-force or effectiveness of any partition or portion of the text 2269 itself (e.g., when the amendments introduced by an act are applied at 2270 different times) or different events occurring in the same date. 2272 version = (amendment-date / specification) 2273 *(";" (event-date / event)) 2275 where: 2276 - contains the issuing date of the last considered 2277 amendment or of the last communication of amendment. In case the 2278 original text introduces differentiated periods in which an act is 2279 effective and the information system produces one version for each 2280 of them, such element contains the string "original" expressed in 2281 the language of the act or version; 2282 - any information useful to identify unambiguously 2283 and univocally the version; 2284 - contains the date in which a version is put into 2285 force, is effective or is published; 2286 - is a name assigned to the event producing a further version 2287 (e.g., amendment, decision, etc.). 2289 The issuing date of an amending act was chosen as identifier of a 2290 version because it can be obtained from the heading (formal data). 2292 (e.g., the name "state:royal.decree:1941-01-30;12@1998-02-19" 2293 identifies the updated text of the "Royal Decree of 30/1/1941, No. 2294 12" with the amendments introduced by the "Law Decree of 19/2/1998, 2295 No. 51", without any indication of its actual entry into force. The 2296 same uniform name with the additional ending ";1999-01-01" indicates 2297 the in-force or effective version starting in a different date (from 2298 1/1/99). 2300 For a full compatibility, every updating of a text or of the 2301 effectiveness of a "multi-version" document implies the creation of a 2302 new uniform name, even if the object remains only one, containing the 2303 identifier of the virtually generated version, exactly as in the case 2304 of a "single-version" document. A specific meta-data will associate 2305 every uniform name with the period of time during which such a name 2306 together with its corresponding text is to be considered valid. 2308 (e.g., the multi-version document containing the "R.D. of 01/30/1941, 2309 no. 12", updated by the amendments introduced by the "D.Lgs. of 2310 02/19/1998, no. 51", contains the name of the original 2311 "state:royal.decree:1941-01-30;12" as well as the name of the updated 2312 version "state:royal.decree:1941-01-30;12@1998-02-19"). 2314 Please note that in case of attachments or annexes, the creation of a 2315 new version (even in the case of only one component) would imply the 2316 creation of a new uniform name for all the connected objects in order 2317 to guarantee their alignment (i.e., the main document, the 2318 attachments and annexes). 2320 Attachment D -- Http LEX Identifier 2322 D1 Http URI 2324 Http URIs have been promoted [RFC3986] as stable and location- 2325 independent identifiers. According to this syntax, at all levels, 2326 resource IDs belong to the http scheme and are normally resolved 2327 using mechanisms widely available in browsers and web servers. 2329 Such kind of identifiers have been suggested also within the set of 2330 principles and technologies, known as "Linked Data" as a basic 2331 infrastructure of the semantic web to enable data sharing and reuse 2332 on a massive scale. 2334 Such principles, introduced by Tim Berners-Lee in his Web 2335 architecture note "Linked Data" 2336 (http://www.w3.org/DesignIssues/LinkedData.html), are synthetically: 2338 - Use URIs as names for things; 2339 - Use HTTP URIs, so that people can look up those names; 2340 - When someone looks up a URI, provide useful information, using the 2341 standards (RDF, SPARQL); 2342 - Include links to other URIs, so that they can discover more things. 2344 The second principle is the one more affecting a discussion about the 2345 scheme to be used for legal resources identification; in particular 2346 to the aim of guaranteeing the access to the resources, http 2347 identifiers are suggested. This property is addressed as 2348 "dereferenceability", meaning a resource retrieval mechanism using 2349 any of the Internet protocols, e.g. HTTP, so that HTTP clients, for 2350 instance, can look up the URI using the HTTP protocol and retrieve a 2351 description of the resource that is identified by the URI. 2352 Such property is available for http identifiers either with or 2353 without a resolver allowing a 1-to-1 association with the "best copy" 2354 of the resource; in the legal domain it is related to the unique act 2355 manifestation of a specific publisher and format. 2357 The same property holds for URN identifiers, as long as a resolver is 2358 properly set-up, allowing 1-to-N association with more manifestations 2359 of a resource (act). 2361 Therefore an http identifier, stable and independent from the 2362 resource location, can be effectively used when a single publisher 2363 provides a specific item of this resource (1-to-1 mapping between an 2364 identifier and manifestation of an act). The independence from the 2365 resource location is managed by a "303 See Other" status code (see 2366 [RFC7231]) which may require a resolver able to access the physical 2367 location of the resource (e.g., through submitting a query to a 2368 database). A URN identifier, stable and independent form the resource 2369 location, can be effectively used within a federative environment 2370 where different publishers can provide different items of the same 2371 act (1-to-N mapping between an identifier and different 2372 manifestations of an act). 2374 In order to comply with the Linked Data principles and to build http 2375 identifiers using the LEX namespace specifications, the LEX schema 2376 and metadata set can be serialized according to an http URI syntax. 2377 It is worthwhile to mention that URN focuses on acts identification, 2378 while Linked Data principles focus on identifying a resource on the 2379 Web. 2381 In the following sections the http serialization of the urn LEX 2382 schema is reported. 2384 D2 The Http LEX Identifier Structure 2386 The http hierarchical structure of the LEX identifier is the 2387 following: 2389 "http://" host-name "/lex/" jurisdiction "/" local-name 2391 where: 2392 - represents the name of the organization server 2393 publishing the resource; 2394 - "lex" is the equivalent of the URN namespace ID and provides the 2395 reference to the naming convention adopted; 2396 - and share meaning and syntax of the 2397 corresponding components in the LEX specifications. 2399 The element follows the syntax rules of the 2400 corresponding element in the URN specification, therefore it has the 2401 following structure: 2403 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 2405 The character ";" still separates the identification code of the 2406 country or jurisdiction where the source of law is issued 2407 () from any possible administrative hierarchical 2408 sub-structures defined by each country or organisation according to 2409 its own legal system. 2411 The follows the [FRBR] model as implemented by the LEX 2412 specifications, therefore its http structure is the following: 2414 local-name = work "/@/" expression "/$/" manifestation 2416 The content of URN:LEX identifier elements is directly transferred to 2417 the corresponding elements of its http version, except for characters 2418 outside the ASCII set: such characters have to be converted into a 2419 valid ASCII format using the typical URL percent encoding rules. 2421 D3 The Http LEX Identifier at Work Level 2423 According to the corresponding level of the URN version, the http LEX 2424 identifier structure at work level is the following: 2426 work = authority "/" measure "/" details *("/" annex) 2428 The elements , and follow the same 2429 syntax rules of the corresponding elements in the URN specification. 2431 Examples of http identifiers at level, corresponding to the 2432 urn examples in Section 6.4, are the following: 2434 http:///lex/it/stato/legge/2006-05-14;22 2435 http:///lex/uk/ministry.justice/decree/1999-10-07;45 2436 http:///lex/ch;glarus/regiere/erlass/2007-10-15;963 2437 http:///lex/es/tribunal.supremo/decision/2001-09-28;68 2438 http:///lex/fr/assemblee.nationale/proposition.loi/ 2439 13.legislature;1762 2440 http:///lex/br/estado/constituicao/1988-10-05;lex-1 2441 http:///lex/nl/hoge.raad/besluit/2008-04-01;bc8581 ,br 2442 http:///lex/un.org/united.nations;general.assembly/ 2443 resolution/1961-11-28;a-res-1661 2445 D4 The Http LEX Identifier at Expression Level 2447 According to the corresponding level of the URN version, the http LEX 2448 structure at expression level is the following: 2450 expression = version ["/" language] 2452 The elements and follow the same syntax rules of 2453 the corresponding elements in the URN specification. 2455 Examples of http identifiers at expression level, corresponding to 2456 the urn examples in Section 6.6, are the following: 2458 http:///lex/ch/etat/loi/2006-05-14;22/@/originel/fr 2459 (original version in French) 2460 http:///lex/ch/staat/gesetz/2006-05-14;22/@/original/de 2461 (original version in German) 2462 http:///lex/ch/etat/loi/2006-05-14;22/@/2008-03-12/fr 2463 (amended version in French) 2465 http:///lex/ch/staat/gesetz/2006-05-14;22/@/2008-03-12/de 2466 (amended version in German) 2467 http:///lex/be/conseil.etat/decision/2008-07-09;185.273 2468 /@/originel/fr 2469 (original version in French of a Belgian decision) 2471 D5 The Http LEX Identifier at Manifestation Level 2473 Information provided in the URN version at manifestation level is 2474 differently accommodated in the corresponding level of the http LEX 2475 identifier. 2477 The element, reported at manifestation level in the urn LEX 2478 version, is an information already contained in the of 2479 the http LEX identifier, therefore it is omitted in the 2480 elements. 2481 Similarly the element is omitted since it loses its meaning 2482 which would derived from the comparison between different 2483 manifestations. 2485 The element is reported as unique extension of the data 2486 format in which the manifestation is drafted. The value is compliant 2487 with the registered file extensions, thus it can be "pdf" for PDF, 2488 "doc" for MS Word, "xml" for XML documents, "tif" for tiff image 2489 format, etc. 2491 Therefore the http LEX structure at manifestation level is the 2492 following: 2494 manifestation = [ component *(";" specification)] "." format 2496 The element follows the same syntax rules of the 2497 corresponding element in the URN specification. 2499 Examples of http identifiers at manifestation level, corresponding to 2500 the urn examples in Section 6.7 are the following: 2502 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/testo.xml 2503 (body of the Italian law 3 April 2000, n. 56, published by the 2504 Italian Senate in xml format) 2505 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/figura.1.pdf 2506 (Figure 1 in PDF format of the Italian law 3 April 2000, n. 56, 2507 published by the Italian Senate) 2508 http://www.juradmin.eu/jurifast/lex/eu/tibunal.justicia/sentencia/ 2509 2009-06-11;33-08/@/original/es/$/todo.html 2510 (the Spanish http LEX identifier of the html format of the whole 2511 Judgement of the European Court of Justice n. 33/08 of 11/06/2009, 2512 in Spanish version, published by the Juriadmin site in the 2513 Jurifast data base) 2514 http://eur-lex.europa.eu/lex/eu/commission/directive/ 2515 2010-03-09;2010-19-EU/$/body.xml 2516 (body of the EU Directive n. 2010-19-EU, dated 2010-03-09, in its 2517 XML format published by Eur-Lex)