idnits 2.17.1 draft-spinosa-urn-lex-09.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 20, 2014) is 3688 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT P. Spinosa 3 Intended Status: Informational ITTIG/CNR 4 Expires: May 20, 2014 E. Francesconi 5 ITTIG/CNR 6 C. Lupo 7 (ICT consultant) 8 March 20, 2014 10 A Uniform Resource Name (URN) Namespace 11 for Sources of Law (LEX) 12 draft-spinosa-urn-lex-09.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on May 20, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 This document describes a Uniform Resource Name (URN) Namespace 52 Identification (NID) convention as prescribed by the World Wide Web 53 Consortium (W3C) for identifying, naming, assigning, and managing 54 persistent resources in the legal domain. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1 The Purpose of Namespace "lex" . . . . . . . . . . . . . . 5 60 1.2 Entities Supporting this Standard . . . . . . . . . . . . . 5 61 1.3 The Context . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.4 General Characteristics of the System . . . . . . . . . . . 8 63 1.5 Linking a LEX Name to a Document . . . . . . . . . . . . . 9 64 1.6 Use of LEX Names in References . . . . . . . . . . . . . . 9 65 1.7 Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 66 1.8 Terminology . . . . . . . . . . . . . . . . . . . . . . . 10 67 2 Specification Template . . . . . . . . . . . . . . . . . . . . 10 68 2.1 Namespace ID . . . . . . . . . . . . . . . . . . . . . . 10 69 2.2 Registration Information . . . . . . . . . . . . . . . . 11 70 2.3 Syntax Used in this Document . . . . . . . . . . . . . . 11 71 2.4 Identifier structure . . . . . . . . . . . . . . . . . . 11 72 3 General Syntax of the LEX Identifier . . . . . . . . . . . . . 13 73 3.1 Allowed and Not Allowed Characters . . . . . . . . . . . 13 74 3.2 Reserved Characters . . . . . . . . . . . . . . . . . . . 13 75 3.3 Case sensitivity . . . . . . . . . . . . . . . . . . . . 14 76 3.4 National Characters and Diacritic Signs . . . . . . . . . 14 77 3.5 Replacement of Spaces, Connectives and Punctuation Marks 15 78 3.6 Abbreviation Expansion . . . . . . . . . . . . . . . . . 15 79 3.7 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 15 80 3.8 Date Format . . . . . . . . . . . . . . . . . . . . . . . 15 81 3.9 Ordinal Numbers . . . . . . . . . . . . . . . . . . . . . 15 82 4 Creation of the Source of Law LEX Identifier . . . . . . . . . 16 83 4.1 Basic Principles . . . . . . . . . . . . . . . . . . . . 16 84 4.2 Model of Sources of Law Representation . . . . . . . . . 16 85 4.3 The Structure of the Local Name . . . . . . . . . . . . . 17 86 4.4 Structure of the Document Identifier at Work Level . . . 17 87 4.5 Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 4.6 Structure of the Document Identifier at Expression Level 19 89 4.7 Structure of the Document Identifier at Manifestation 90 Level . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 4.8 Sources of Law References . . . . . . . . . . . . . . . . 22 92 5 The Procedure of Uniform Names Assignment . . . . . . . . . . 23 93 5.1 Specifying the element of the LEX 94 identifier . . . . . . . . . . . . . . . . . . . . . . . 23 95 5.2 Jurisdictional Registrar for Names Assignment . . . . . . 23 96 5.3 Identifier Uniqueness . . . . . . . . . . . . . . . . . . 24 97 5.4 Identifier persistence considerations . . . . . . . . . . 24 98 6 Principles of the Resolution Service . . . . . . . . . . . . . 25 99 6.1 The General Architecture of the System . . . . . . . . . 25 100 6.2 Catalogues for Resolution . . . . . . . . . . . . . . . . 26 101 6.3 Suggested resolver behaviour . . . . . . . . . . . . . . 26 102 7 Considerations . . . . . . . . . . . . . . . . . . . . . . . . 27 103 7.1 Conformance with URN Syntax . . . . . . . . . . . . . . . 27 104 7.2 Validation mechanism . . . . . . . . . . . . . . . . . . 27 105 7.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 28 106 7.4 Namespace Considerations . . . . . . . . . . . . . . . . 28 107 7.5 Community Considerations . . . . . . . . . . . . . . . . 28 108 7.6 IANA Considerations . . . . . . . . . . . . . . . . . . . 28 109 7.7 Security Considerations . . . . . . . . . . . . . . . . . 29 110 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 111 8.1 Normative References . . . . . . . . . . . . . . . . . . 29 112 8.2 Informative References . . . . . . . . . . . . . . . . . 30 113 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 114 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 31 115 Attachment A -- Summary of the syntax of the uniform names of 116 the "lex" namespace . . . . . . . . . . . . . . . . . 32 117 Attachment B -- Specific Syntax of the Identifier at Work Level . 36 118 B1 The element . . . . . . . . . . . . . . . . . . . 36 119 B1.1 Indication of the Authority . . . . . . . . . . . . . . 36 120 B1.2 Multiple Issuers . . . . . . . . . . . . . . . . . . . . 36 121 B1.3 Indication of the Issuer . . . . . . . . . . . . . . . . 36 122 B1.4 Indication of the Body . . . . . . . . . . . . . . . . . 36 123 B1.5 Indication of the Function . . . . . . . . . . . . . . . 37 124 B1.6 Conventions for the Authority . . . . . . . . . . . . . 37 125 B2 The element . . . . . . . . . . . . . . . . . . . . 37 126 B2.1 Criteria for the Indication of the Type of Measure . . . 37 127 B2.2 Further Specification to the Type of Measure . . . . . . 38 128 B2.3 Aliases for Sources of Law with Different Normative 129 References . . . . . . . . . . . . . . . . . . . . . . . 38 130 B2.4 Relations between Measure and Authority in the Aliases . 38 131 B3 The
element . . . . . . . . . . . . . . . . . . . . 39 132 B3.1 Indication of the Details . . . . . . . . . . . . . . . 39 133 B3.2 Multiple Dates . . . . . . . . . . . . . . . . . . . . . 39 134 B3.3 Unnumbered Measures . . . . . . . . . . . . . . . . . . 40 135 B3.4 Multiple Numbers . . . . . . . . . . . . . . . . . . . . 40 136 B4 The element . . . . . . . . . . . . . . . . . . . . . 41 137 B4.1 Formal Annexes . . . . . . . . . . . . . . . . . . . . . 41 138 B4.2 Annexes of Annexes . . . . . . . . . . . . . . . . . . . 41 139 Attachment C -- Specific Syntax of the Element of the 140 Expression . . . . . . . . . . . . . . . . . . . . . 42 141 C1 The element . . . . . . . . . . . . . . . . . . . . 42 142 C1.1 Different Versions of a Legislative Document . . . . . . 42 143 C1.2 Identification of the Version . . . . . . . . . . . . . 42 144 Attachment D -- Http-based LEX identifier . . . . . . . . . . . . 44 145 D1 Http-based URI . . . . . . . . . . . . . . . . . . . . . . . . 44 146 D2 The http-based LEX identifier structure . . . . . . . . . . . 45 147 D3 The http-based LEX identifier at Work Level . . . . . . . . . 46 148 D4 The http-based LEX identifier at Expression Level . . . . . . 46 149 D5 The http-based LEX identifier at Manifestation Level . . . . . 47 151 1 Introduction 153 1.1 The Purpose of Namespace "lex" 155 The purpose of the "lex" namespace is to assign an unequivocal 156 identifier, in standard format, to documents that are sources of law. 157 To the extent of this namespace, "sources of law" include any legal 158 document within the domain of legislation, case law and 159 administrative acts or regulations; moreover potential "sources of 160 law" (acts under the process of law formation, as bills) are included 161 as well. Therefore "legal doctrine" is explicitly not covered. 163 The identifier is conceived so that its construction depends only on 164 the characteristics of the document itself and is, therefore, 165 independent from the document's on-line availability, its physical 166 location, and access mode. 168 This identifier will be used as a way to represent the references 169 (and more generally, any type of relation) among the various sources 170 of law. In an on-line environment with resources distributed among 171 different Web publishers, uniform resource names allow simplified 172 global interconnection of legal documents by means of automated 173 hypertext linking. 175 1.2 Entities Supporting this Standard 177 The following entities support this proposal: 179 - ITTIG/CNR (Institute of Legal Information Theory and Techniques of 180 the Italian National Research Council) - Italy; 181 - National Centre for ICT in Public Administration - Italy; 182 - PRODASEN - IT Department of the Federal Senate - Brazil; 183 - LII (Legal Information Institute), Cornell Law School - USA 185 1.3 The Context 187 In the last few years a number of initiatives have arisen in the 188 field of legal document management. 190 Since 2001 the Italian Government, through the National Center for 191 Information Technology in the Public Administration, the Ministry of 192 Justice and ITTIG-CNR (the Institute of Legal Information Theory and 193 Techniques of the Italian National Research Council) promoted the 194 NormeInRete project. It was aimed at introducing standards for 195 sources of law description and identification using XML and URN 196 techniques. 198 Other national initiatives in Europe introduced standards for the 199 description of legal sources [FRAN]: for example the Metalex project, 200 promoted by the University of Amsterdam and adopted by the Dutch Tax 201 and Customs Administration, the Belgian Public Centers for Welfare 202 and others; LexDania project in Denmark supported by the Danish 203 Ministry of Justice; CHLexML in Switzerland developed by COPIUR, the 204 Coordination Office for the Electronic Publication of Legal Data 205 Federal Office of Justice; eLaw in Austria mainly coordinated by the 206 Austrian Parliament. 208 Such initiatives, based in synergies between government, national 209 research institutes, and universities, have defined national XML 210 standards for legal document management, as well as schemes for legal 211 document identification. 213 Outside Europe, similar initiatives have faced similar problems. For 214 example, the Brazilian Senate carried out a feasibility study to 215 provide unique and transparent identifiers to sources of law on the 216 basis of the IFLA-FRBR model. 217 Similarly, the Akoma Ntoso (Architecture for Knowledge-Oriented 218 Management of African Normative Texts using Open Standards and 219 Ontologies) project provides a set of guidelines for e-Parliament 220 services in a Pan-African context by proposing an XML document schema 221 providing sophisticated description possibilities for several 222 Parliamentary document types (including bills, acts and parliamentary 223 records, etc.). 224 Finally, the Tasmanian Government provided advanced legislative 225 information services through the EnAct project. It gave searchable 226 consolidated Tasmanian legislation by automating much of the 227 legislative drafting and consolidation process, as well as using SGML 228 document representation. Numerous less-visible efforts in the United 229 States and elsewhere have struggled with similar issues. 231 Several of these identifiers are based on a URN schema. The first 232 national standard was defined in Italy within the NormeInRete 233 project; to this the Brazilian Lexml standard followed. Denmark, 234 Hungary, Slovenia and Switzerland expressed their interest in URN 235 identifier for legislation as well. All these standards have a common 236 internal structure, regarding both the hierarchy and the elements 237 content. 239 In today's information society the processes of political, social and 240 economic integration of European Union member states as well as the 241 increasing integration of the world-wide legal and economic processes 242 are causing a growing interest in exchanging legal information 243 knowledge at national and trans-national levels. 244 The growing desire for improved quality and accessibility of legal 245 information amplifies the need for interoperability among legal 246 information systems across national boundaries. A common open 247 standard used to identify sources of law at international level is an 248 essential prerequisite for interoperability. 250 Interest groups within several countries have already expressed their 251 intention to adopt a shared solution based on a URN technique. 252 The need for a unequivocal identifier of sources of law in different 253 EU Member States, based on open standards and able to provide 254 advanced modalities of document hyper-linking, has been expressed in 255 several conferences by representatives of the Office for Official 256 Publications of the European Communities (OPOCE), with the aim of 257 promoting interoperability among national and European institution 258 information systems. Similar concerns have been raised by 259 international groups concerned with free access to legal information, 260 and the Permanent Bureau of the Hague Conference on Private 261 International Law is considering a resolution that would encourage 262 member states to "adopt neutral methods of citation of their legal 263 materials, including methods that are medium-neutral, provider- 264 neutral and internationally consistent". In a similar direction the 265 CEN Metalex initiative is moving, at European level, towards the 266 definition of a standard interchange format for sources of law, 267 including recommendations for defining naming conventions to them. 269 The need of semantic Web unequivocal identifiers for sources of law 270 is of particular interest also in the domain of case law. Such need 271 is extremely felt within both common law systems, where cases are the 272 main law sources, and civil law systems, for the importance of 273 providing an integrated access to cases and legislation, as well as 274 to track the relationships between them. This domain is characterized 275 by a high degree of fragmentation in case law information systems, 276 which usually lack interoperability. 277 Recently in the European Union, the community institutions have 278 stressed the need for citizens, businesses, lawyers, prosecutors and 279 judges to become more aware not only of (directly applicable) EU law, 280 but also of the various national legal systems. The growing 281 importance of national judiciaries for the application of Community 282 law was recently stressed in the resolution of the European 283 Parliament of 9 July 2008 on the role of the national judge in the 284 European judicial system. 285 Similarly the European e-Justice action plan 2009-2013 of the Council 286 of the European Union underlined the importance of cross-border 287 access to national case law, as well as the need for its 288 standardisation, in view of an integrated access in a decentralized 289 architecture. In this view the Working Party on Legal Data Processing 290 (e-Law) of the Council of the European Union formed a task group to 291 study the possibilities for improving cross-border access to national 292 case law. Taking notice of the report of the Working Party's task 293 group the Council of the EU decided in 2009 to elaborate on a 294 uniform, European system for the identification of case law (ECLI: 296 European Case-Law Identifier) and uniform Dublin Core-based set of 297 metadata. 299 LEX identifier is conceived to be general enough, so to provide 300 guidance at the core of the standard and sufficient flexibility to 301 cover a wide variety of needs for identifying all the legal documents 302 of different nature, namely legislative, case-law and administrative 303 acts. Moreover it can be effectively used within a federative 304 environment where different publishers (public and private) can 305 provide their own items of an act (that is there is more than one 306 manifestation of the same act). 307 However specifications and syntax rules of LEX identifier can be used 308 also for http-based naming convention (Appendix D) to cope with 309 different requirements in legal information management, for example 310 the need of having an identifier compliant with the Linked Open Data 311 principles. 313 The LEX naming convention has interpreted all these recommendations, 314 proposing an original solution for sources of law identification. 316 1.4 General Characteristics of the System 318 Registrants wish now to promote interoperability among legal 319 information systems by the definition of a namespace convention and 320 structure that will create and manage identifiers for legal 321 documents. The identifiers will be: 322 - globally unique 323 - transparent 324 - bidirectional 325 - persistent 326 - location-independent, and 327 - language-neutral. 328 These qualities will facilitate legal document management as well as 329 provide a mechanism of stable cross-collections and cross-country 330 references. 332 Transparency means that given an act and its relevant metadata 333 (issuing authority, type of measure, etc.) it is possible to create 334 the related urn identifier. Moreover this identifier is able to 335 unequivocally identify the related act. These two properties makes 336 the identification system bidirectional (from an act to its URN and 337 from a URN to the related act). 339 Language-neutrality is an especially important feature that will 340 promote adoption of the standard by organizations that must adhere to 341 official-language requirements. The proposed standard will provide 342 useful guidance to both public and private groups that create, 343 promulgate, and publish legal documents. Registrants wish to minimize 344 the potential for creating conflicting proprietary schemes, while 345 preserving sufficient flexibility to allow for diverse document types 346 and to respect the need for local control of collections by an 347 equally diverse assortment of administrative entities. 349 As usual, the problem is to provide the right amount guidance at the 350 core of the standard while providing sufficient flexibility to cover 351 a wide variety of needs. The proposed LEX standard does this by 352 splitting the identifier into parts. The first part uses a 353 predetermined standard ("country/jurisdiction name standard") to 354 specify the country (or more generally the jurisdiction) of origin 355 for the legal document being identified; the remainder ("local name") 356 is intended for local use in identifying documents issued in that 357 country or jurisdiction. This second part depends only on sources of 358 law identification system operating in that nation and it is mainly 359 composed by a formalized information related to the enacting 360 authority, the type of measure, the details and possibly the annex. 362 The identification system based on uniform names MUST include: 363 - a schema for assigning names capable of representing unambiguously 364 any addressed source of law, namely legislation, case law and 365 administrative acts, issued by any authority (intergovernmental, 366 supranational, national, regional and local) at any time (past, 367 present and future); 368 - a resolution mechanism - in a distributed environment - that ties a 369 uniform name to the on-line location of the corresponding 370 resources. 371 This document only considers the first of these requirements. It also 372 contains a few references to the architecture of the resolution 373 service and to the corresponding software. 375 1.5 Linking a LEX Name to a Document 377 The LEX name is linked to the document through meta-information which 378 may be specified: 379 - internally to the document itself through a specific element within 380 an XML schema or by an HTML META tag; 381 - externally by means of an RDF triple, a specific attribute in a 382 database, etc. 383 One of these modalities is necessary for enabling automated 384 construction and updating of catalogues (distributed and centralized) 385 and the implementation of resolvers that associate the uniform name 386 of a document with its physical location(s). The standard assumes no 387 particular relationship between the originator of the document, its 388 publisher, and the implementer of catalogues or resolution services. 389 They may be the same entity, or not. 391 1.6 Use of LEX Names in References 392 LEX names will be used on a large scale in references as a HREF 393 attribute value of the hypertext link to the referred document. 394 This link can be created in two ways: 395 - by manually inserting, in the referring document, the link with the 396 uniform name: this is a burdensome procedure especially for 397 documents that are already on-line; 398 - by automatically constructing (either permanently or temporarily) 399 the link with the uniform name, through reference parsers of a 400 text: this is a more time-saving procedure even if subject to a 401 certain percentage of errors, since references are not always 402 accurate or complete. This solution could nevertheless be 403 acceptable for already published documents. 404 In any case, whatever the method adopted is, new documents produced 405 in XML format compliant with the relative DTD/XMLSchema, SHOULD 406 express references through the uniform name of the document referred 407 to. 409 1.7 Definitions 411 According to this document, the following terms are used in the 412 following meaning: 413 - Source of Law: 414 is a general concept, and is used to refer to legislation, case 415 law, regulations and administrative acts. In its broadest sense, 416 the source of law is anything that can be conceived of as the 417 originator of 'erga omnes' legal rules. In this document "source of 418 law" refers also to acts during their formation cycle as bills that 419 might or might not become sources of law; 420 - Registrar: 421 is an organization which shares and defines in any country or 422 jurisdiction the assignment of the main components of the resource 423 identifier through which its uniqueness is guaranteed. This task 424 includes the definition of possible jurisdiction unit and the 425 primary elements (issuing authority and type of legal measure) of 426 uniform name, according to the characteristics of its own state or 427 institution organization. 429 1.8 Terminology 431 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 432 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 433 document are to be interpreted as described in [RFC2119]. 435 2 Specification Template 437 2.1 Namespace ID 439 "lex" requested according to [RFC3406]. 441 2.2 Registration Information 443 Version Number: 1.0 444 Date: 2014-03-20 446 Declared registrant of the namespace: 448 Institute of Legal Information Theory and Techniques (ITTIG) 449 Italian National Research Council (CNR) 450 Via de' Barucci, 20 451 50127 Florence 452 Italy 454 e-mail: lex@ittig.cnr.it 456 2.3 Syntax Used in this Document 458 This document uses the syntax common to many Internet RFCs, which is 459 based on the ABNF (Augmented Backus-Naur Form) meta-language. In 460 particular: 461 - definition elements are separated by white spaces; 462 - an element is separated from its specification by the character 463 "="; 464 - alternative elements are separated from each other by a slash 465 ("/"); 466 - character strings are enclosed in quotes (" and "); 467 - optional parts are enclosed by square brackets ("[" and "]"); 468 - a group of elements is enclosed by round brackets ("(" and ")"); 469 - a symbol or an expression preceding an element or a group of 470 elements indicates a factor of repetition, and takes the following 471 formats: 472 - *1 : 0 or 1 time; 473 - 1* : 1 or more times; 474 - * : 0 or more times; 475 - n : times; 476 - n*m : from to times. 478 2.4 Identifier structure 480 The identifier has a hierarchical structure as follows: 482 "urn:lex:" NSS 484 where is the Namespace Specific String composed as follows: 486 NSS = jurisdiction ":" local-name 488 where: 490 is the part providing the identification of the 491 jurisdiction, generally corresponding to the country, where the 492 source of law is issued. It is also possible to represent 493 international organizations (either states or public administrations 494 or private entities); 496 is the uniform name of the source of law in the country 497 or jurisdiction where it is issued; its internal structure is common 498 to the already adopted schemas. It is able to represent all the 499 aspects of an intellectual production, as it is a legal document, 500 from its initial idea, through its evolution during the time, to its 501 realisation by different means (paper, digital, etc.). 503 The element is composed of two specific fields: 505 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 507 where: 509 is usually the identification code of the country 510 where the source of law is issued; this code follows the standard 511 [ISO3166] Alpha-2 (it=Italy, fr=France, dk=Denmark, etc.) which 512 usually is identical to the country code Top-Level Domain (ccTLD). In 513 case such codes are not identical (as for United Kingdom, whose ISO 514 3166 code is .gb while its ccTLD is .uk), one of them is chosen as 515 . 516 In case of multi-national (e.g., European Union) or international 517 (e.g., United Nations, Free Software Foundation) organizations the 518 Top Level Domain Name (e.g., "eu") or the Domain Name (e.g., 519 "un.org", "wto.int") is used instead of ISO 3166 code. In case such 520 multi-national or international organization does not have a 521 registered domain, in order to avoid ambiguities or collisions with 522 actual domains, a domain name (according to the english acronym of 523 the organization name) under the virtual domain "lex" is used. For 524 example, the jurisdiction code of the European Economic Community is 525 "eec.lex". 526 In case of country code re-assignement (as "ai" given to Anguilla), 527 in any URN this country code will be associated to the new 528 jurisdiction, therefore the related documents will be identified by 529 such new jurisdiction country code. Therefore the previous 530 jurisdiction ("ai" as associated to French Afar and Issas), MUST use 531 another country code and, at the same time, MUST change the 532 jurisdiction code element of each legacy URN identifier. 533 A possible choice for jurisdiction renaming in legacy URNs can be one 534 of the following: 535 - keeping the old country code and appending a date interval 536 corresponding to the period of validity of the code for this 537 jurisdiction (ex: "ai-1974-1983")(recommended solution); 539 - changing the old country code with the new code assigned to the 540 same country/jurisdiction (ex: "ai" into "dj" (Djibouti)); 541 - changing the old 2-letters country code with the 3-letters one (ex: 542 "ai" into "afi"). 544 are the possible administrative hierarchical sub- 545 structures defined by each country or organisation according to its 546 own legal system. This additional information can be used where two 547 or more levels of legislative or judicial production exist (e.g., 548 federal, state and municipality level) and the same bodies may be 549 present in each jurisdiction. Then acts of the same type issued by 550 similar authorities in different areas differ for the jurisdiction- 551 unit specification. An example can be the following: 552 "br:governo:decreto" (decree of federal government), 553 "br;sao.paulo:governo:decreto" (decree of SU+00E3o Paulo state) and 554 "br;sao.paulo;campinas:governo: decreto" (decree of Campinas 555 municipality). 557 Examples of law sources identifiers are: 559 urn:lex:it:stato:legge:2003-09-21;456 (Italian act) 560 urn:lex:fr:etat:loi:2004-12-06;321 (French act) 561 urn:lex:es:estado:ley:2002-07-12;123 (Spanish act) 562 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 (Glarus Swiss Canton 563 decree) 564 urn:lex:eu:commission:directive:2010-03-09;2010-19-EU (EU Commission 565 Directive) 566 urn:lex:us:federal.supreme.court:decision:1963-03-18;372.us.335 (US 567 FSC decision) 568 urn:lex:be:conseil.etat:decision:2008-07-09;185.273 (Decision of the 569 Belgian Council of State) 571 3 General Syntax of the LEX Identifier 573 3.1 Allowed and Not Allowed Characters 575 These characters are defined in accordance with the [RFC2141] "URN 576 Syntax". For various reasons, later explained, in the "lex" 577 only a sub-set of characters is allowed. All other characters are 578 either eliminated or converted. 580 For the full syntax of the uniform names in the "lex" space, please 581 see Attachment A. 583 3.2 Reserved Characters 585 These characters MUST always and uniquely be used for the assigned 586 purpose. 588 The first category includes those characters bearing a specific 589 meaning in the general creation of the URI (Uniform Resource 590 Identifier)[RFC3986]: 592 "%" "/" "?" "#" 594 The following characters instead are reserved in the specific "lex" 595 namespace: 597 - "@" separator of the expression, that contains information on 598 version and language; 599 - "$" separator of the manifestation, that contains information on 600 format, editor, etc.; 601 - ":" separator of the main elements of the name at any entity; 602 - ";" separator of level. It identifies the introduction of an 603 element at a hierarchically lower level, or the introduction of a 604 specification; 605 - "+" separator of the repetitions of an entire main element (e.g., 606 multiple authorities); 607 - "," separator of the repetitions of individual components in the 608 main elements, each bearing the same level of specificity (e.g., 609 multiple numbers); 610 - "~" separator of the partition identifier in references (e.g., 611 paragraph of an article); 612 - "*" and "!" are reserved for future expansions. 614 3.3 Case sensitivity 616 Although the case does not change the logical identification of the 617 source of law and therefore the names belonging to the "lex" 618 namespace should be considered functionally equivalent independently 619 from the case, nevertheless to take advantage of memory caching and 620 simplify the resolution process the specific name MUST be always 621 created in lower case 622 (e.g., "Ministry" will be recorded as "ministry"). 624 3.4 National Characters and Diacritic Signs 626 In order to exploit DNS as a routing tool towards the proper 627 resolution system, to keep editing and communication more simple and 628 to avoid character percent-encoding, it is strongly recommended that 629 national characters and diacritic signs are turned into base ASCII 630 characters (e.g., the Italian term "sanitU+00E0" converted into 631 "sanita", the French term "ministU+00E8re" converted into 632 "ministere"), in case by transliteration (e.g. "MU+00FCnchen" 633 converted into "muenchen"). 634 If such conversion is not acceptable by a specific jurisdiction and 635 therefore it is used the UTF-8 %-encoding [STD63], it is necessary: 637 - to convert the non-ASCII characters to IDN encoding, using the 638 [RFC5894] punycode translation (ex: mU+00FCnchen into xn--mnchen- 639 3ya), or 640 - to create a routing service relying to a software, out of DNS, 641 addressing a proper resolution service. 642 However it is up to the specific jurisdiction to choose the preferred 643 solution. 645 3.5 Replacement of Spaces, Connectives and Punctuation Marks 647 All the language connectives (e.g., articles, prepositions, etc.), 648 the punctuation marks and all the special characters (as apostrophes, 649 dashes, etc.) are eliminated. The words left are connected each other 650 by a dot (".") which substitutes the "space". 651 (e.g., "Ministry of Finances, Budget and of Economic Planning" 652 becomes "ministry.finances.budget.economic.planning") 654 3.6 Abbreviation Expansion 656 All abbreviations indicating institutions (e.g., Min.), structures 657 (e.g., Dept.), or legal measures (e.g., reg.), MUST be expanded. 658 (e.g., "Min." must be reported as "ministry") 660 3.7 Acronyms 662 The use of acronyms might be confusing and encourage ambiguity in 663 uniform names (the same acronym may indicate two different 664 institutions or structures), therefore their expansion is strongly 665 recommended. 666 (e.g., "FAO" is to be expanded as "food.agriculture.organization") 668 3.8 Date Format 670 Dates are expressed by numbers in the [ISO8601] format: 672 yyyy-mm-dd 674 (e.g., "September 2, 99" will be written as "1999-09-02") 676 3.9 Ordinal Numbers 678 Any ordinal number included in a component of a document name (e.g., 679 in the description of an institution body) MUST be indicated in 680 Arabic numerals, regardless to the original expression: whether in 681 Roman numerals, or with an adjective, or in Arabic numeral with apex, 682 etc. (IV, third, 1U+00B0, 2^, etc.). 683 (e.g., "Department IV" becomes "department.4") 685 4 Creation of the Source of Law LEX Identifier 687 4.1 Basic Principles 689 The uniform name must identify one and only one document (more 690 precisely a "bibliographic entity") and is created in such a way that 691 it is: 692 - self-explanatory ; 693 - identifiable through simple and clear rules; 694 - compatible with the practice commonly used for references; 695 - able to be created by references in the text, automatically (by 696 parser) or manually; 697 - representative of both the formal and the substantive aspects of 698 the document. 700 4.2 Model of Sources of Law Representation 702 According to FRBR (Functional Requirements for Bibliographic Records) 703 model developed by IFLA (International Federation of Library 704 Associations and Institutions), in a source of law, as in any 705 intellectual production, 4 fundamental entities (or aspects) can be 706 specified. 708 The first 2 entities reflect its contents: 709 - work: identifies a distinct intellectual creation; in our case, it 710 identifies a source of law both in its being (as it has been issued 711 or proposed) and in its becoming (as it is modified over time); 712 - expression: identifies a specific intellectual realisation of a 713 work; in our case it identifies every different (original or up-to- 714 date) version of the source of law over time and/or language in 715 which the text is expressed; 716 while the other 2 entities relate to its form: 717 - manifestation: identifies a concrete realisation of an expression; 718 in our case it identifies realizations in different media 719 (printing, digital, etc.), encoding formats (XML, PDF, etc.), or 720 other publishing characteristics; 721 - item: identifies a specific copy of a manifestation; in our case it 722 identifies individual physical copies as they are found in 723 particular physical locations. 725 In this document the FRBR model has been interpreted for the specific 726 characteristics of the legal domain. In particular, a part from the 727 language which does produce a specific expression, the discriminative 728 criterion between expression and manifestation is based on the 729 difference of the juridical effects that a variation can provide with 730 respect to the involved actors (citizens, parties, institutions). In 731 this scenario the main characteristic of the expression of an act is 732 represented by its validity over the time, during which it provides 733 the same juridical effects. These effects change for amendments or 734 annulments of other legislative or jurisprudential acts. Therefore 735 notes, summarizations, comments, anonymizations and other editorial 736 activities over the same text do not produce different expressions, 737 but different manifestations. 739 4.3 The Structure of the Local Name 741 The within the "lex" namespace MUST contain all the 742 necessary pieces of information enabling the unequivocal 743 identification of a legal document. 744 In the legal domain, at the "work" level, they are essentially four: 745 the enacting authority, the type of measure, the details and the 746 annex, if any. 747 It is often necessary to differentiate various expressions, that is: 748 - the original version and all the amended versions of the same 749 document; 750 - the versions of the text expressed in the different official 751 languages of the state or organization. 752 Finally the uniform name allows a distinction among diverse 753 manifestations, which may be produced in multiple locations using 754 different means and formats. 755 In every case, the basic identifier of the source of law (work) 756 remains the same, but information is added regarding the specific 757 version under consideration (expression); similarly a suffix is added 758 to the expression for representing the characteristics of the 759 publication (manifestation). 760 The information which forms a source of law uniform name at each 761 level (work, expression, manifestation) is expressed in the official 762 language of the related jurisdiction; in case of more official 763 languages (as in Switzerland) or more involved jurisdictions (as in 764 international treaties), more language-dependent names (aliases) are 765 created. 767 Therefore, the more general structure of the national name appears as 768 follows: 770 local-name = work ["@" expression] ["$" manifestation] 772 However, consistent with legislative practice, the uniform name of 773 the main original provision (work) becomes the identifier of an 774 entire class of documents which includes: the original main document, 775 the annexes, and all their versions, languages and formats 776 subsequently generated. 778 4.4 Structure of the Document Identifier at Work Level 780 The structure of the document identifier is made of the four 781 fundamental elements mentioned above, clearly distinguished one from 782 the other in accordance with an order identifying increasingly narrow 783 domains and competences: 785 work = authority ":" measure ":" details *(":" annex) 787 where: 789 is the issuing or proposing authority of the measure 790 (e.g., State, Ministry, Municipality, Court, etc.); 792 is the type of the measure, both public nature (e.g., 793 constitution, act, treaty, regulation, decree, decision, etc.) as 794 well as private one (e.g., license, agreement, etc); 796
are the terms associated to the measure, typically the date 797 (usually the signature date) and the number included in the heading 798 of the act; 800 is the identifier of the annex, if any (e.g., Annex 1). 802 In case of annexes, both the main document and its annexes have their 803 own uniform name so that they can individually be referenced; the 804 identifier of the annex adds a suffix to that of the main document. 805 In similar way the identifier of an annex of an annex adds an ending 806 to that of the annex which it is attached to. 808 The main elements of the national name are generally divided into 809 several elementary components, and, for each, specific rules of 810 representation are established (criteria, modalities, syntax and 811 order). 812 For the details regarding each element, please see the Attachment B. 814 Examples of identifiers are: 816 urn:lex:it:stato:legge:2006-05-14;22 817 urn:lex:uk:ministry.justice:decree:1999-10-07;45 818 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 819 urn:lex:es:tribunal.supremo:decision:2001-09-28;68 820 urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762 821 urn:lex:br:estado:constituicao:1988-10-05;lex-1 822 urn:lex:fsf.org:free.software.foundation:general.public.license:2007- 823 06-29;lex-1 824 urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581 826 It is worth to note that the type of measure is important to identify 827 case law, as well as legislation, especially within the legal systems 828 where cases, by tradition, are identified only through the year of 829 release and a number. Since the aim of the "urn:lex" schema is to 830 identify specific materials, the type of measure or the full date are 831 able to provide discrimination between materials belonging to a 832 specific case. 834 Here below is an example where the type of measure or the full date 835 are essential for identify specific materials of a case: 836 - 4/59 Judgment of the EEC Court of Justice 04/04/1960, Mannesmann AG 837 and others / ECSC High Authority 838 urn:lex:eec.lex:court.justice:judgment:1960-04-04;4-59 839 - 4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG 840 and others / ECSC High Authority 841 urn:lex:eec.lex:court.justice:order:1960-05-18;4-59 843 4.5 Aliases 845 International treaties involve more jurisdictions (the signing ones) 846 so they are represented through more identifiers, each of them 847 related to an involved jurisdiction. For example, a bilateral France 848 and Germany treaty is identified through two URNs (aliases) belonging 849 to either "fr" or "de" jurisdiction 850 (e.g., "urn:lex:fr:etat:traite:..." and 851 "urn:lex:de:staat:vertrag:...") 852 since it pertains to both the French and the German jurisdiction. 854 In the states or organisations that have more than one official 855 language, a document has more identifiers, each of them expressed in 856 a different official language, basically a set of equivalent aliases. 857 This system permits manual or automated construction of the uniform 858 name of the referred source of law in the same language used in the 859 document itself. 860 (e.g., "urn:lex:eu:council:directive:2004-12-07;31", 861 "urn:lex:eu:consiglio:direttiva:2004-12-07;31", etc.) 863 Moreover, a document can be assigned more than one uniform name in 864 order to facilitate its linking to other documents. This option can 865 be used for documents that, although unique, are commonly referenced 866 from different perspectives. For example, the form of a document's 867 promulgation and its specific content (e.g., a Regulation promulgated 868 through a Decree of the President of the Republic). 870 4.6 Structure of the Document Identifier at Expression Level 872 There may be several expressions of a legal text, connected to 873 specific versions or languages. 874 Each version is characterized by the period of time during which that 875 text is to be considered as the valid text (in force or effective). 876 The lifetime of a version ends with the issuing of the subsequent 877 version. 878 New versions of a text may be brought into existence by: 879 - changes in the text (amendments) due to the issuing of other legal 880 acts and to the subsequent production of updated or consolidated 881 texts; 882 - correction of publication errors (rectification or errata corrige); 883 - entry into or departure from a particular time span, depending on 884 the specific date in which different partitions of a text come into 885 force. 886 Each of such versions may be expressed in more than one language, 887 with each language-version having its own specific identifier. 888 The identifier of a source of law expression adds such information to 889 the work identifier, using the following main structure: 891 expression = version [":" language] 893 where: 895 is the identifier of the version of the (original or 896 amended) source of law. In general it is expressed by the 897 promulgation date of the amending act; anyway other specific 898 information can be used for particular documents. If necessary, the 899 original version is specified by the string "original" (for the 900 details regarding this element, please see the Attachment C); 902 is the identification code of the language in which the 903 document is expressed, according to [BCP47] (it=Italian, fr=French, 904 de=German, etc.). The granularity level of the language (for example 905 the specification of the German language as used in Switzerland 906 rather than the standard German) is left to each specific 907 jurisdiction. The information is not necessary when the text is 908 expressed in the unique official language of the country or 909 jurisdiction. 911 Examples of document identifiers for expressions are: 913 urn:lex:ch:etat:loi:2006-05-14;22@originel:fr (original version in 914 French) 915 urn:lex:ch:staat:gesetz:2006-05-14;22@original:de (original version 916 in German) 917 urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr (amended version in 918 French) 919 urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de (amended version 920 in German) 921 urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr 922 (original version in French of a Belgian decision) 924 4.7 Structure of the Document Identifier at Manifestation Level 925 To identify a specific manifestation, the uniform name of the 926 expression is followed by a suitable suffix describing the: 927 - digital format (e.g., XML, HTML, PDF, etc.) expressed according to 928 the MIME Content-Type standard [RFC2045], where the "/" character 929 is to be substituted by the "-" sign; 930 - editorial staff who produced it, expressed according to its 931 Internet domain name; 932 - possible components of the expressions contained in the 933 manifestation. Such components are expressed by language-dependent 934 labels representing the whole document (in English "all") or the 935 main part of the document (in English "body") or the caption label 936 of the component itself (e.g. Table 1, Figure 2, etc.); 937 - other features of the document (e.g., anonymized decision text). 939 The suffix will thus read: 941 manifestation = format *(";" specification) 942 ":" editor *(";" specification) 943 [":" component *(";" specification)] 944 [":" feature *(";" specification)] 946 To indicate possible features or peculiarities, each main element of 947 the manifestation MAY be followed by further specifications, for 948 example as regards the version, for the archive 949 name and the electronic publisher, etc. 951 (examples: 952 the original version the Italian act 3 April 2000, n. 56 might have 953 the following manifestations with their relative uniform names: 954 - PDF format (vers. 1.7) of the whole act edited by the Italian 955 Parliament: 956 "urn:lex:it:stato:legge:2000-04-03;56$application- 957 pdf;1.7:parlamento.it" 958 - XML format (version 2.2 DTD NIR) of the text of the act and PDF 959 format (version 1.7) of the "Figura 1" (figure 1) contained in the 960 body, edited by the Italian Senate: 961 "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir- 962 2.2:senato.it:testo" 963 "urn:lex:it:stato:legge:2000-04-03;56$application- 964 pdf;1.7:senato.it:figura.1" 966 the Spanish URN of the html format of the whole Judgement of the 967 European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, 968 published in the Jurifast data base in anonymized form: 969 "urn:lex:eu:tibunal.justicia:sentencia:2009-06-11;33- 970 08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo") 972 Furthermore, it is useful to be able to assign a uniform name to a 973 manifestation (or to a part of it) in case non-textual objects are 974 involved. These may be multimedia objects that are non-textual in 975 their own right (e.g. geographic maps, photographs, etc.), or texts 976 recorded in non-textual formats, such as image scans of documents. 978 In these ways, a LEX name permits: 979 - exploitation of all the advantages of an unequivocal identifier 980 that is independent of physical location; 981 - a means to provide choice among different existing manifestations 982 (e.g. XML or PDF formats, resolution degree of an image etc.) of 983 the same expression. 985 4.8 Sources of Law References 987 References to sources of law often refer to specific partitions of 988 the act (article, paragraph, etc.) and not to the entire document. 989 An act partition is a logical subdivision of the text, that, in a 990 structured format (as XML) fitting the document logical structure, is 991 represented by an element with its own ID; this ID aims to identify 992 the element and to locate it. In a mark-up that does not fit the 993 logical structure of the text (as HTML), generally only the starting 994 point of the partition, and not the element, is identified through a 995 label (a tag). 996 Therefore, for allowing browsers to point to a specific partition, it 997 is necessary that such partition is endowed with an unequivocal label 998 or ID within the including document and its value is the same 999 independently from the document format. 1001 For enabling the construction of the partition identifier between 1002 different collections of documents, specific construction rules for 1003 IDs or labels SHOULD be defined and shared, within each country or 1004 jurisdiction, for any document type (e.g., for legislation, the 1005 paragraph 2 of the article 3 might have as label or ID the value 1006 "art3;par2", similarly for case-law, paragraph 22 of the judgment in 1007 Case 46/76 Bauhuis v Netherlands, might have as label or ID the value 1008 "par22"). 1009 Furthermore, it is useful to foresee the compatibility with 1010 applications able to manage this information (e.g., returning the 1011 proper element); these procedures are particularly useful in the case 1012 of rather long acts, such as codes, constitutions, regulations, etc. 1013 For this purpose it is necessary that the partition identifier is 1014 transmitted to the servers (resolution and application) and therefore 1015 it cannot be separated by the typical "#" character of URI fragment, 1016 which is not transmitted to the server. 1018 According to these requirements, the syntax of a reference is: 1020 URN-reference = URN-document ["~" partition-id] 1022 (e.g., to refer to the paragraph 3 of the article 15 of the French 1023 Act of 15 may 2004, n. 106, the reference is written 1024 "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3"). 1026 Using a different separator ("~") from the document name, the 1027 partition ID is not withheld by the browser but it is transmitted to 1028 the resolution process. This enables the resolver to retrieve (for 1029 example, out of a database), if it is possible, only the referred 1030 partition, otherwise to return the whole act. 1031 Anyway, to make it effective pointing to the indicated partition 1032 through a browser, the resolver SHOULD transform the partition ID of 1033 each returned URL in a URI fragment; this is obtained appending to 1034 URL the "#" character followed by the partition ID (in the example 1035 above, the returned URL will be #art15;par3). 1037 Anyway it is possible to use the general syntax (with "#"); in this 1038 case only the URN document component of the reference is transmitted 1039 to the resolver, therefore the whole document will be always 1040 retrieved. 1042 5 The Procedure of Uniform Names Assignment 1044 5.1 Specifying the element of the LEX identifier 1046 Under the "lex" namespace, each country or international organization 1047 is assigned with a jurisdiction code, which characterizes the URNs of 1048 the source of law of that country or jurisdiction. This code is 1049 assigned according to the ISO 3166 Alpha-2 (as well as TLDN or DN for 1050 the organizations) representation and it is the value of the 1051 element, which preserves cross-country uniqueness 1052 of the identifiers. 1054 5.2 Jurisdictional Registrar for Names Assignment 1056 Any country or jurisdiction, who intends to adopt this schema, 1057 identifies a Jurisdictional Registrar, an organization which shares 1058 and defines the structure of the optional part () 1059 of the name, according to the organization of the state or 1060 institution. For example, in a federal state a 1061 corresponding to the name of each member state (e.g. "br;sao.paolo", 1062 "br;minas.gerais", etc.) may be defined. 1064 The process of assigning the will be managed by each 1065 specific country or jurisdiction under the related 1066 element. 1067 In any country the Jurisdictional Registrar shares and defines the 1068 assignment of the primary elements (issuing authority and type of 1069 legal measure) of the local names considering the characteristics of 1070 its own state or institution organization. 1071 Such a Registrar MUST establish, according to the guidelines 1072 indicated in the current document, a uniform procedure within the 1073 country or organization to define elements, to take 1074 decisions upon normalizations and finally to solve and avoid possible 1075 name collisions as well as to maintain authoritative registries of 1076 various kinds (e.g., for authorities, types of measures, etc.). In 1077 particular, accurate point-in-time representations of the structure 1078 and naming of government entities are important to semantically-aware 1079 applications in this domain. 1080 Moreover, the Registrar shares and defines the rules to construct 1081 partition IDs for each document type. 1082 Finally, the Registrar will develop and publish the rules and the 1083 guidelines for the construction as well as the 1084 predefined values and codes. 1086 5.3 Identifier Uniqueness 1088 Identifiers in the "lex" namespace are defined through a 1089 element assigned to the sources of law of a specific 1090 country or organization, and a assigned by the issuing 1091 authority. The main elements (authority and type of measure) of the 1092 are defined by the Jurisdictional Registrar, so that it 1093 is ensured that the constructed URNs are unique. The Jurisdictional 1094 Registrar SHOULD provide clear documentation of rules by which names 1095 are to be constructed, and SHOULD update and make accessible its 1096 registries. 1098 Any issuing authority is responsible to define formal parameters to 1099 guarantee local name uniqueness by attributing, if necessary, a 1100 conventional internal number, which, combined with the other components (authority, measure and date), builds an unequivocal 1102 identifier. Uniqueness is achieved by checking against the catalogue 1103 of previously assigned names. 1105 5.4 Identifier persistence considerations 1107 The persistence of identifiers depends on the durability of the 1108 institutions that assign and administer them. The goal of the LEX 1109 schema is to maintain uniqueness and persistence of all resources 1110 identified by the assigned URNs. 1112 In particular, ITTIG-CNR, as proposer, is responsible of maintaining 1113 the uniqueness of the element; given that the 1114 is assigned on the basis of the long-held ISO 3166 1115 Alpha-2 representation of the country (or the TLD name of the 1116 organization) and that the country or organization associated code is 1117 expected to continue indefinitely, the URN also persists 1118 indefinitely. 1120 The rules for the construction of the name are conceived to delegate 1121 the responsibility of their uniqueness to a set of authorities which 1122 is identified within each country or organization. 1124 Therefore, each authority is responsible for assigning URNs which 1125 have a very long life expectancy and can be expected to remain unique 1126 for the foreseeable future. Practical and political considerations, 1127 as well as diverse local forms of government organization, will 1128 result in different methods of assigning responsibility for different 1129 levels of the name. 1130 Where this cannot be accomplished by the implementation of an 1131 authoritative hierarchy, it can and SHOULD be done by creating 1132 consensus around a series of published rules for the creation and 1133 administration of names by institutions and bodies that operate by 1134 means of collaboration rather than compulsion. 1136 Issuing authorities that operate in more localized scopes, ranging 1137 from the national down to the very local, MUST equally take 1138 responsibility for the persistence of identifiers within their 1139 scope. 1141 6 Principles of the Resolution Service 1143 6.1 The General Architecture of the System 1145 The task of the resolution service is that of associating a LEX 1146 identifier with a specific document address on the network. By 1147 contrast with systems that can be constructed around rigorous and 1148 enforceable engineering premises, such as DNS, the "lex" namespace 1149 resolver will be expected to cope with a wide variety of "dirty" 1150 inputs, particularly those created by the automated extraction of 1151 references from incomplete or inaccurate texts. In this document, 1152 the result is a particular emphasis on a flexible and robust resolver 1153 design. 1155 The system has a distributed architecture based on two fundamental 1156 components: a chain of information in DNS (Domain Name System) and a 1157 series of resolution services from URNs to URLs, each competent 1158 within a specific domain of the namespace. 1159 Through the NAPTR records of the DNS (described in [RFC3403]), the 1160 client identifies the characteristics (protocol, port, site) of the 1161 service (e.g. according to [RFC2169]) capable of associating the 1162 relative URLs with the URN in question, thereby allowing access to 1163 the document. 1165 A resolution service can delegate the resolution and management of 1166 hierarchically-dependent portions of the name. 1167 Delegation of this responsibility will not be unreasonably withheld 1168 provided that the processes for their resolution and management are 1169 robust and are followed. 1171 For the "lex" namespace, ITTIG-CNR will maintain the root zone 1172 "lex.urn.arpa" and, in correspondence with the adhesion of a new 1173 country (e.g., "br") or organization, will update the DNS information 1174 with a new record to delegate the relative resolution. This may be 1175 obtained by a regular expression that matches the initial part of the 1176 URN (e.g., "urn:lex:br") and redirects towards the proper zone (e.g., 1177 "lex.senado.gov.br"). 1179 Likewise the institution responsible for the jurisdiction uniform 1180 names (e.g., "urn:lex:br") has the task of managing the relative root 1181 in the DNS system (e.g., "lex.senado.gov.br" zone) and routing the 1182 resolution towards its resolvers on the basis of parts of the uniform 1183 names. In similar way it can delegate the resolution of 1184 country/organization sub-levels (e.g., "urn:lex:br;sao.paolo") 1185 towards the relative zone (e.g., "lex.sao-paolo.gov.br"). 1187 Such DNS routing chain does not work for all the URN components 1188 containing %-encoded characters. Therefore in these cases a proper 1189 software implementing routing service has to be developed. 1191 The resolution service is made up of two elements: a knowledge base 1192 (consisting in a catalogue or a set of transformation rules) and a 1193 software to query the knowledge base itself. 1195 6.2 Catalogues for Resolution 1197 Incompleteness and inaccuracy are rather frequent in legal citations, 1198 and incomplete or inaccurate uniform names of the referred document 1199 are thus likely to be built from textual references (this is even 1200 more frequent if they are created automatically through a specific 1201 parser). For this reason, the implementation of a catalogue, based on 1202 a relational-database, is suggested, as it will lead to a more higher 1203 flexibility in the resolution process. 1204 In addition the catalogue must manage the aliases, the various 1205 versions and languages of the same source of law as well as the 1206 related manifestations. 1208 It is suggested that each enacting authority implements its own 1209 catalogue, assigning a corresponding unambiguous uniform name to each 1210 resource. 1212 6.3 Suggested resolver behaviour 1213 First of all the resolver should separate the part corresponding to 1214 the partition ID, through the "~" separator, from the document name. 1216 So, the resolution process SHOULD implement a normalization of the 1217 uniform name to be resolved. This may involve transforming some 1218 components to the canonical form (e.g., filling out the acronyms, 1219 expanding the abbreviations, unifying the institution names, 1220 standardizing the type of measures, etc.). For this function 1221 authorities and types of measure registers are useful. 1223 The resolver SHOULD then query the catalogue searching for the URN 1224 which corresponds exactly to the given one (normalized if necessary). 1225 Since the names coming from the references may be inaccurate or 1226 incomplete, an iterative, heuristic approach (based on partial 1227 matches) is indicated. It is worth remarking that incomplete 1228 references (not including all the elements to create the canonical 1229 uniform name) are normal and natural; for a human reader, the 1230 reference would be "completed" by contextual understanding of the 1231 reference in the document in which it occurs. 1233 In this phase, the resolver should use the partition ID information 1234 to retrieve, if it is possible, only the referred partition, 1235 otherwise to return of the entire document. 1237 Lacking more specific indications, the resolver SHOULD select the 1238 best (most recent) version of the requested source of law, and 1239 provide all the manifestations with their related items. 1240 A more specific indication in the uniform name to be resolved will, 1241 of course, result in a more selective retrieval, based on any 1242 suggested expression and/or manifestations components (e.g. date, 1243 language, format, etc.). 1245 Finally, the resolver SHOULD append to URLs the "#" character 1246 followed by partition ID, transforming it in a URI fragment for 1247 browser pointing. 1249 7 Considerations 1251 7.1 Conformance with URN Syntax 1253 No special considerations. 1255 7.2 Validation mechanism 1257 The national Authority (or those it delegates) of each adhering 1258 country or organization is responsible of the definition or 1259 acceptance of the uniform name's primary elements (issuing authority 1260 and type of legal measure). 1262 7.3 Scope 1264 Global interest. 1266 7.4 Namespace Considerations 1268 In collaboration with the legislative XML community, registrants 1269 carried out a preliminary study of the URI alternatives to satisfy 1270 the key requirements. 1271 The options analysed were: a private URI scheme, URL, PURL and URN. 1272 URN was considered the most appropriate URI given the requirements 1273 analysis. 1274 Advantages we would emphasize are: 1275 - greater flexibility in building the identifier; 1276 - the capacity to represent name components that are not strictly 1277 hierarchical; 1278 - the potential for clear division of the identifier into macro 1279 parts, main elements and components, using different separators; 1280 - ease of managing optional parts of a name. 1282 7.5 Community Considerations 1284 The use of the "lex" namespace facilitates the interoperability of 1285 information systems used in the Public Administration at the national 1286 and international level. Moreover it allows the distribution of the 1287 legal information towards a federated architecture. In such an 1288 architecture, documents are directly managed by the issuing 1289 authorities, with resulting benefits in information authenticity, 1290 quality and currency. A shared identification mechanism resources 1291 guarantees that a distributed system will be as efficient and 1292 effective as a comparable centralized system. 1294 Creators of Internet content that references legal materials - 1295 including publishers operating well outside the traditional arenas of 1296 legal publishing - benefit by the registration of the namespace 1297 because facilitates the linking of legal documents, whether by manual 1298 or automated means, and reduces the cost of maintaining documents 1299 that contain such references. 1301 Any citizen or organisation with Internet web browser capability will 1302 be entitled to access the namespace and its associated application, 1303 registers, and resolution services, to facilitate document access. 1305 7.6 IANA Considerations 1307 This document includes a URN NID registration for "lex" for entry in 1308 the IANA registry of URN NIDs (see [RFC5226]), as well as the 1309 registration of the following NAPTRs record: 1311 in the URN.ARPA domain: 1312 lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it. 1314 in the URN.URI.ARPA domain: 1315 lex IN NAPTR 100 10 "" "" "" lex.ittig.cnr.it. 1317 7.7 Security Considerations 1319 This document introduces no additional security considerations beyond 1320 those associated with the use and resolution of URNs in general. 1322 8 References 1324 8.1 Normative References 1326 [BCP47] A. Phillips, M. Davis, "Tags for Identifying Languages", 1327 BCP 47, RFC 5646, September 2009 1329 [STD63] F. Yergeau, "UTF-8, a transformation format of ISO 1330 10646", STD 63, RFC 3629, November 2003. 1332 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1333 Extensions (MIME) Part One: Format of Internet Message 1334 Bodies", RFC 2045, November 1996. 1336 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1337 Requirement Levels", BCP 14, RFC 2119, March 1997. 1339 [RFC2141] R. Moats, K. R. Sollins, "URN Syntax", RFC 2141, May 1340 1997. 1342 [RFC2169] R. Daniel, "A Trivial Convention for using HTTP in URN", 1343 RFC 2169, June 1997 1345 [RFC3403] M. Mealling, Dynamic Delegation Discovery System (DDDS), 1346 Part Three: The Domain Name System (DNS) Database, RFC 1347 3403, October 2002. 1349 [RFC3406] D Daigle, L., van Gulik, D., Iannella, R., and P. 1350 Faltstrom, "Uniform Resource Names (URN) Namespace 1351 Definition Mechanisms", BCP 66, RFC 3406, October 2002. 1353 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1354 Resource Identifiers (URI): Generic Syntax", STD 66, RFC 1355 3986, January 2005. 1357 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1358 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1359 May 2008 1361 [RFC5894] J. Klensin, "Internationalized Domain Names for 1362 Applications (IDNA): Background, Explanation, and 1363 Rationale", RFC 5894, August 2010 1365 [ISO3166] ISO 3166, "Country name codes", ISO 3166-1:1997. 1367 [ISO8601] ISO 8601, "Data elements and interchange formats", ISO 1368 8601:2004 1370 8.2 Informative References 1372 [SPIN] P.L. Spinosa, "The Assignment of Uniform Names to Italian 1373 Legal Documents", May, 2006 1374 http://www.nir.it/sito_area3- 1375 ap_stan_assegnazione_nomi.htm 1377 [FRAN] E. Francesconi, "Technologies for European Integration. 1378 Standards-based Interoperability of Legal Information 1379 Systems", ISBN 978-88-8398-050-3, European Press Academic 1380 Publishing, 2007. 1382 9 Acknowledgments 1384 The authors of this document wish to thank all the supporters for 1385 giving suggestions and comments. 1386 They are also grateful to the Legislative XML community for the 1387 interesting discussions on this topic and to the Working Group 1388 "Identification of the legal resources through URNs" of Italian 1389 NormeInRete project for the provided guidance [SPIN]. 1390 The authors owe a debt of gratitude to Tom Bruce, director of the 1391 Legal Information Institute of the Cornell University Law School, for 1392 his contribution in revising this document and sharing fruitful 1393 discussions which greatly improved the final draft. The authors wish 1394 to specially thank Marc van Opijnen (Dutch Ministry of Security and 1395 Justice) for his valuable comments on LEX specifications which 1396 contributed to improve the final result, as well as for the common 1397 work aimed to harmonize ECLI and LEX standards. Thanks also to Joao 1398 Alberto de Oliveira Lima, legislative system analyst of the Brazilian 1399 Federal Senate, and to Attila Torcsvari, information management 1400 consultant, for their detailed comments on the first drafts of this 1401 document, which provided significant hints to the final version of 1402 the standard, and to Robert Richards of the Legal Information 1403 Institute (Cornell University Law School), promoter and maintainer of 1404 the Legal Informatics Research social network, as well as to the 1405 members of this network, for their valuable comments on this 1406 proposal. 1408 Finally, many thanks go to Loriana Serrotti who significantly 1409 contributed to the first drafting of this document. 1411 10 Author's Addresses 1413 PierLuigi Spinosa 1414 Istituto di Teoria e Tecniche dell'Informazione Giuridica (ITTIG) 1415 Consiglio Nazionale delle Ricerche (CNR) 1416 Via de' Barucci, 20 1417 50127 Firenze 1418 Italy 1419 Telephone: +39 055 43995 1420 e-mail: pierluigi.spinosa@ittig.cnr.it 1422 Enrico Francesconi 1423 Istituto di Teoria e Tecniche dell'Informazione Giuridica (ITTIG) 1424 Consiglio Nazionale delle Ricerche (CNR) 1425 Via de' Barucci, 20 1426 50127 Firenze 1427 Italy 1428 Telephone: +39 055 43995 1429 e-mail: enrico.francesconi@ittig.cnr.it 1431 Caterina Lupo 1432 (ICT consultant) 1433 Via San Fabiano, 25 1434 00165 Roma 1435 Telephone: +39 3382632348 1436 e-mail: caterina.lupo@gmail.com 1438 Attachment A -- Summary of the syntax of the uniform names of the "lex" 1439 namespace 1441 *------------------------------------------------------------------- 1442 * General Structure of a Uniform Resource Name (URN) 1443 * NID = namespace 1444 * NSS = specific name 1445 *------------------------------------------------------------------- 1446 URN = "urn:" NID ":" NSS 1448 *------------------------------------------------------------------- 1449 * Structure of a Uniform Resource Name (URN) of the "lex" namespace 1450 *------------------------------------------------------------------- 1451 NID = "lex" 1453 URN = "urn:lex:" NSS-lex 1455 *------------------------------------------------------------------- 1456 * Structure of a "lex" specific name 1457 *------------------------------------------------------------------- 1458 NSS-lex = jurisdiction ":" local-name 1460 *------------------------------------------------------------------- 1461 * Structure of the element 1462 *------------------------------------------------------------------- 1463 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 1465 jurisdiction-code = 2*4lowercase / (alfanum *normal) 1467 jurisdiction-unit = alfanum *normal 1469 *------------------------------------------------------------------- 1470 * Structure of the element 1471 *------------------------------------------------------------------- 1472 national-name = work ["@" expression] ["$" manifestation] 1474 *------------------------------------------------------------------- 1475 * Structure of the element 1476 *------------------------------------------------------------------- 1477 work = authority ":" measure ":" details *(":" annex) 1479 *------------------------------------------------------------------- 1480 * Structure of the element 1481 *------------------------------------------------------------------- 1482 authority = issuer *("+" issuer) 1484 issuer = (institution *(";" body) *(";" function)) / office 1485 institution = alfanum *normal 1487 body = alfanum *normal 1489 function = alfanum *normal 1491 office = alfanum *normal 1493 *------------------------------------------------------------------- 1494 * Structure of the element 1495 *------------------------------------------------------------------- 1496 measure = measure-type *(";" specification) 1498 measure-type = alfanum *normal 1500 specification = alfanum *normal 1502 *------------------------------------------------------------------- 1503 * Structure of the
element 1504 *------------------------------------------------------------------- 1505 details = (dates / period) ";" numbers 1507 dates = date *("," date) 1509 period = alfanum *normal 1511 numbers = (document-id *("," document-id)) / number-lex 1513 document-id = alfanum *(normal / other) 1515 number-lex = "lex-" 1*DIGIT 1517 *------------------------------------------------------------------- 1518 * Structure of the element 1519 *------------------------------------------------------------------- 1520 annex = annex-id *(";" specification) 1522 annex-id = alfanum *normal 1524 *------------------------------------------------------------------- 1525 * Structure of the element 1526 *------------------------------------------------------------------- 1527 expression = version [":" language] 1529 *------------------------------------------------------------------- 1530 * Structure of the element 1531 *------------------------------------------------------------------- 1532 version = (amendment-date / specification) 1533 *(";" (event-date / event)) 1535 amendment-date = date 1537 event-date = date 1539 event = alfanum *normal 1541 *------------------------------------------------------------------- 1542 * Structure of the element 1543 *------------------------------------------------------------------- 1544 language = 2*3lowercase 1546 *------------------------------------------------------------------- 1547 * Structure of the element 1548 *------------------------------------------------------------------- 1549 manifestation = format *(";" specification) 1550 ":" editor *(";" specification) 1551 [":" component *(";" specification)] 1552 [":" feature *(";" specification)] 1554 format = alfanum *(normal / "-") 1556 editor = alfanum *(normal / "-") 1558 component = alfanum *(normal / "-") 1560 feature = alfanum *(normal / "-") 1562 *------------------------------------------------------------------- 1563 * Structure of the date 1564 *------------------------------------------------------------------- 1565 date = year "-" month "-" day 1567 year = 4DIGIT 1568 month = 2DIGIT 1569 day = 2DIGIT 1571 *------------------------------------------------------------------- 1572 * Allowed characters 1573 *------------------------------------------------------------------- 1574 allowed-lex = normal / other / reserved / future 1576 normal = alfanum / "." 1578 alfanum = lowercase / DIGIT / encoded 1580 lowercase = %x61-7A ; lower-case ASCII letters (a-z) 1581 ; DIGIT %x30-39 decimal digits (0-9) 1583 encoded = "%" (1*6DIGIT / ("x" 1*6HEXDIG)) 1584 ; Hexadecimal digits (0-9, A-F) 1586 other = "-" / "_" / "'" / "=" / "(" / ")" 1588 reserved = ":" / "@" / "$" / "+" / ";" / "," / "~" 1590 future = "*" / "!" 1592 Attachment B -- Specific Syntax of the Identifier at Work Level 1594 B1 The element 1596 B1.1 Indication of the Authority 1598 The element of a uniform name may indicate, in the 1599 various cases: 1600 - the actual authority issuing the legal provision. More 1601 specifically, the authority adopting the provision or enacting it; 1602 - the institution where the provision is registered, known and 1603 referenced to, even if produced by others (e.g., the bills 1604 identified through the reference to the Chamber where they are 1605 presented); 1606 - the institution regulated (and referred to in citations) by the 1607 legal provision even when this is issued by another authority 1608 (e.g., the statute of a Body); 1609 - the entity that proposed the legal material not yet included in the 1610 institutional process (e.g. a proposed bill written by a a 1611 political party). 1613 B1.2 Multiple Issuers 1615 Some sources of law are enacted by a number of issuing parties (e.g., 1616 inter-ministerial decrees, agreements, etc.). In this case, the 1617 element contains all the issuing parties (properly 1618 separated), as follows: 1620 authority = issuer *("+" issuer) 1622 (e.g., "ministry.justice+ministry.finances") 1624 B1.3 Indication of the Issuer 1626 Each issuing authority is essentially represented by either an 1627 institutional office (e.g., Prime Minister) or an institution (e.g., 1628 Ministry); in the last case, the authority is indicated in accordance 1629 with the institution's hierarchical structure, from the more general 1630 to more specific (Council, Department, etc.), ending with the 1631 relative office (President, Director, etc.). 1632 Therefore, the structure of the issuer is as follows: 1634 issuer = (institution *(";" body) *(";" function)) / office 1636 (e.g., "ministry.finances;department.revenues;manager") 1638 B1.4 Indication of the Body 1639 Depending on the kind of measure, the body within the issuing 1640 authority is unambiguously determined (e.g., the Council for Regional 1641 Acts) and normally it is not indicated in the references. 1642 Just like in practice, the indication of the enacting authority is 1643 limited to the minimum in relation to the type of measure. 1644 (e.g., "region.tuscany:act" and not "region.tuscany;council:act") 1646 B1.5 Indication of the Function 1648 Generally, the component is indicated, sometimes instead 1649 of the body itself: 1650 - in case of political, representative or elective offices 1651 (e.g., "university.oxford;rector:decree" instead of 1652 "university.oxford;rectorship:decree"); 1653 - when it refers to a top officer in the institution (e.g., general 1654 manager, general secretary, etc.) which is not always possible to 1655 associate a specific internal institutional structure to 1656 (e.g., "national.council.research;general.manager"). 1658 It is not indicated when it clearly corresponds to the person in 1659 charge of an institution (typically, a general director); in this 1660 case, only the structure and not the person in charge is indicated 1661 (e.g., "ministry.justice;department.penitentiary.administration"). 1663 The function MUST be indicated when: 1664 - it is not the same of the director or the person in charge of the 1665 structure (for example, in case of an undersecretary, a deputy 1666 director, etc.); 1667 - the type of measure may be both monocratic or collegial: the 1668 indication of the office eliminates the ambiguity. 1670 B1.6 Conventions for the Authority 1672 Acts and measures bearing the same relevance as an act, issued or 1673 enacted since the foundation of the State, have conventionally 1674 indicated "state" (expressed in each country official language) as 1675 authority; the same convention is used for constitutions, codes 1676 (civil, criminal, civil procedure, criminal procedure, etc) and 1677 international treaties. 1679 B2 The element 1681 B2.1 Criteria for the Indication of the Type of Measure 1683 In uniform names the issuing authority of a document is mandatory. 1684 This makes unnecessary to indicate any further qualification of the 1685 measure (e.g., ministerial decree, directorial ordinance, etc.), even 1686 if it is widely used. 1688 When the authority-measure combination clearly identifies a specific 1689 document, the type of measure is not defined through attributes 1690 referring to the enacting authority. 1691 (e.g., "region.tuscany:act" and not "region.tuscany:regional.act") 1693 B2.2 Further Specification to the Type of Measure 1695 In the element, it is usually sufficient to indicate the 1696 type of a measure. As usual, references to sources of law, rather 1697 than through the formal details (date and number), may be made 1698 through some of their characteristics such as the subject-matter 1699 covered (e.g., accounting regulations), nicknames referring to the 1700 promoter (e.g., Bassanini Act) or to the topic of the act (e.g., 1701 Bankruptcy Law), etc.. 1702 In these cases, the type of measure MAY be followed by further 1703 specifications useful in referencing even if the details are lacking: 1705 measure = measure-type *(";" specification) 1707 (e.g., "regulations;accounting" or "act;bankruptcy") 1709 B2.3 Aliases for Sources of Law with Different Normative References 1711 There are legislative measures that, although unique, are usually 1712 cited in different ways, for example through the legislative act 1713 introducing them into the legal order (President's decree, 1714 legislative decree, etc.) or through their legislative category 1715 (regulations, consolidation, etc.). 1716 In order to ensure, in all the cases, the validity of the references, 1717 an alias that takes into account the measure category is associated 1718 to the uniform name, representing the legislative form. 1719 (e.g., "state:decree.legislative:1992-07-24;358" and 1720 "state:consolidation;public.contracts:1992-07-24;358"). 1722 B2.4 Relations between Measure and Authority in the Aliases 1724 The sources of law including different normative references are 1725 usually introduced in legislation through the adoption or the issuing 1726 of an act, which they are either included or attached to. It is, 1727 therefore, necessary to create an alias linking the two aspects of 1728 the same document. Specifically, the different measures can be: 1729 - adopted/issued by an authority different from the one regulated by 1730 the provision (e.g., the statute of a Body); in this case, the 1731 correlation is established between two uniform names each featuring 1732 a completely different element 1733 (e.g., "italian.society.authors.publishers:statute" and 1734 "ministry.cultural.activities+ministry.finances.budget.economic. 1735 planning:decree"); 1737 - issued by the institution itself either because it has issuing 1738 authority or by virtue of a proxy (e.g., a provision that refers to 1739 the functioning of the Body itself); in this case, the two aliases 1740 share the first part of the authority; 1741 (e.g., "municipality.firenze:statute" and 1742 "municipality.firenze;council:deliberation"); 1743 - issued by the same Body to regulate a particular sector of its own 1744 competence; in this case the element is the same 1745 (e.g., "ministry.justice:regulation;use.information.tools. 1746 telematic.process" and "ministry.justice:decree"). 1748 B3 The
element 1750 B3.1 Indication of the Details 1752 The details of a source of law usually include the date of the 1753 enactment and the identification number (inclusion in the body of 1754 laws, register, protocol, etc.). 1755 Some measures can have multiple dates; there are also cases in which 1756 the number of the measure does not exist (unnumbered measures) or a 1757 measure has multiple numbers (e.g., unified cases). For these 1758 reasons, the set up of both elements (date and number) includes 1759 multiple values. 1761 Some institutions (e.g., the Parliaments) usually identify documents 1762 through their period of reference (e.g., the legislature number) 1763 rather than through a date, which would be much less meaningful and 1764 never used in references (e.g., Senate bill S.2544 of the XIV 1765 legislature). In these cases, the component is used in 1766 substitution of the component . 1768 Usually details of a measure are not reported according to a specific 1769 sequence; in accordance with the global structure of the uniform 1770 name, which goes from the general to the specific, the sequence date- 1771 number has the following form: 1773 details = (dates / period) ";" numbers 1775 (e.g., "2000-12-06;126", "14.legislature;s.2544") 1777 B3.2 Multiple Dates 1779 Some sources of law, even if unique, are identified by more than one 1780 date; in this case, in the field all the given dates are to 1781 be reported and indicated as follows: 1783 dates = date *("," date) 1785 (e.g., the measure of the Data Protection Authority of December 30, 1786 1999- January 13, 2000, No. 1/P/2000 has the following uniform name: 1787 "personal.data.protection.authority:measure:1999-12-30,2000-01-13; 1788 1-p-2000"). 1790 B3.3 Unnumbered Measures 1792 Measures not officially numbered in the publications may have a non- 1793 unequivolcal identifier, because several measures of the same type 1794 can exist, issued on the same day by the same authority. 1795 To ensure that the uniform name is unambiguous, the field 1796 MUST, in any case, contain a discriminating element, which can be any 1797 identifier used internally, and not published, by the authority 1798 (e.g., protocol). 1799 If the authority does not have its own identifier, one identifier 1800 MUST be created for the name system. In order to easily differentiate 1801 it, such number is preceded by the string "lex-": 1803 number-lex = "lex-" 1*DIGIT 1805 (e.g., "ministry.finances:decree:1999-12-20;lex-3") 1807 It is responsibility of the authority issuing a document to assign a 1808 discriminating specification to it; in case of multiple authorities, 1809 only one of them is responsible for the assignment of the number to 1810 the document (e.g., the proponent). 1811 The unnumbered measures published on an official publication (e.g., 1812 the Official Gazette), instead of by a progressive number are 1813 recognized by the univocal identifying label printed on the paper. 1814 Such an identifier, even if unofficial but assigned to a document in 1815 an official publication, is to be preferred because it has the clear 1816 advantage to be public and therefore easier to be found. 1818 B3.4 Multiple Numbers 1820 Some legal documents (e.g., bills), even if unique, are identified by 1821 a set of numbers (e.g., the unification of cases or bills). 1822 In this case, in the field, all the identifiers are 1823 reported, according to the following structure: 1825 numbers = document-id *("," document-id) 1827 (e.g., "2000-06-12;c-10-97,c-11-97,c-12-97") 1828 The characters which are not allowed (e.g., "/") or reserved (e.g., 1829 ":"), including the comma, cannot exist inside the , and 1830 therefore MUST be turned into "-". 1831 This conversion may imply that the uniform name of the document is no 1832 more unique (e.g., removal 123-BIS and return 123/BIS of the bill 123 1833 both are identified as "123-bis"); in this case, it is necessary to 1834 add a specific distinctive ending (e.g., "123-bis-removal" and "123- 1835 bis-return"). 1837 B4 The element 1839 B4.1 Formal Annexes 1841 Although annexes are an integral part of the legal document, they may 1842 be referred to and undergo amendments separately from the act to 1843 which they are annexed. It is, therefore, necessary that both the 1844 main document as well as each formal individual annex is univocally 1845 identified. 1847 Formal annexes may be registered as separate parts or together with a 1848 legal provision; they may also be autonomous in nature or not. In any 1849 case, they MUST be given a uniform name, which includes the uniform 1850 name of the source of law to which they are attached, and a suffix 1851 which identifies the annex itself. 1853 The suffix of formal annexes includes the official heading of the 1854 annex and, possibly, further specifications (e.g., the title) which 1855 will facilitate the retrieval of the annex in case the identifier is 1856 missing: 1858 annex = annex-id *(";" specification) 1860 (e.g., "region.sicily;council:deliberation:1998-02-12;14:annex.a; 1861 borders.park") 1863 The characters which are not allowed (e.g. "/") or which are reserved 1864 (e.g. ":") must not be featured in the and therefore MUST 1865 be turned into ".". 1867 B4.2 Annexes of Annexes 1869 When there are annexes to an annex, their corresponding identifiers 1870 are created by adding to the identifier of the original annex those 1871 of the annexes that are connected with it (that is, attached to it). 1873 (e.g., Table 1 attached to Attachment A of the preceding legal act 1874 has the following uniform name: 1875 "region.sicily;council:deliberation:1998-02-12;14:annex.a; 1876 borders.park:table.1;municipality.territories"). 1878 Attachment C -- Specific Syntax of the Element of the 1879 Expression 1881 C1 The element 1883 C1.1 Different Versions of a Legislative Document 1885 The creation of an updated text of a document may have one of the 1886 following forms: 1887 - "multi-version": when specific mark-ups which identify the modified 1888 parts of a document (added, substituted or deleted parts) and their 1889 related periods of effectiveness are indicated inside one single 1890 object (e.g., an xml file). Such a document will be able, in a 1891 dynamic way, to appear in different forms according to the 1892 requested date of effectiveness; 1893 - "single-version": when, on the contrary, a new and distinct object 1894 is created for each amendment to the text at a given time. Each 1895 object is, therefore, characterized by its own period of validity. 1896 In any case all the versions SHOULD be linked one another and 1897 immediately navigable. 1899 C1.2 Identification of the Version 1901 In order to identify the different time versions of the same act, to 1902 the uniform name of the original document has to be added a specific 1903 suffix. 1904 Such a suffix identifies each version of a legal provision and 1905 includes, first and foremost, one of the following elements: 1906 - the issuing date of the last amending measure taken into account; 1907 - the date in which the communication of the rectification or of the 1908 errata corrige, is published; 1909 - a specification which must identify the reason concerning the 1910 amendment (e.g., the specific phase of the legislative process), 1911 for the cases in which the date is not usually used (e.g., bills). 1913 Anyway it is possible to add further specifications that will 1914 distinguish each of the different versions of the text to guarantee 1915 identifier unequivocalness. For example with regard to changes of the 1916 in-force or effectiveness of any partition or portion of the text 1917 itself (e.g., when the amendments introduced by an act are applied at 1918 different times) or different events occurring in the same date. 1920 version = (amendment-date / specification) 1921 *(";" (event-date / event)) 1923 where: 1924 - contains the issuing date of the last considered 1925 amendment or of the last communication of amendment. In case the 1926 original text introduces differentiated periods in which an act is 1927 effective and the information system produces one version for each 1928 of them, such element contains the string "original"; 1929 - any information useful to identify unambiguously 1930 and univocally the version; 1931 - contains the date in which a version is put into 1932 force, is effective or is published; 1933 - is a name assigned to the event producing a further version 1934 (e.g., amendment, decision, etc.). 1936 The issuing date of an amending act was chosen as identifier of a 1937 version because it can be obtained from the heading (formal data). 1939 (e.g., the name "state:royal.decree:1941-01-30;12@1998-02-19" 1940 identifies the updated text of the "Royal Decree of 30/1/1941, No. 1941 12" with the amendments introduced by the "Law Decree of 19/2/1998, 1942 No. 51", without any indication of its actual entry into force. The 1943 same uniform name with the additional ending ";1999-01-01" indicates 1944 the in-force or effective version starting in a different date (from 1945 1/1/99). 1947 For a full compatibility, every updating of a text or of the 1948 effectiveness of a "multi-version" document implies the creation of a 1949 new uniform name, even if the object remains only one, containing the 1950 identifier of the virtually generated version, exactly as in the case 1951 of a "single-version" document. A specific meta-data will associate 1952 every uniform name with the period of time during which such a name 1953 together with its corresponding text is to be considered valid. 1955 (e.g., the multi-version document containing the "R.D. of 01/30/1941, 1956 no. 12", updated by the amendments introduced by the "D.Lgs. of 1957 02/19/1998, no. 51", contains the name of the original 1958 "state:royal.decree:1941-01-30;12" as well as the name of the updated 1959 version "state:royal.decree:1941-01-30;12@1998-02-19"). 1961 Please note that in case of attachments or annexes, the creation of a 1962 new version (even in the case of only one component) would imply the 1963 creation of a new uniform name for all the connected objects in order 1964 to guarantee their alignment (i.e., the main document, the 1965 attachments and annexes). 1967 Attachment D -- Http-based LEX identifier 1969 D1 Http-based URI 1971 Http-based URIs have been recently promoted as stable and location- 1972 independent identifiers [RFC3986]. According to this syntax, at all 1973 levels, resource IDs belong to the http scheme and are normally 1974 resolved using mechanisms widely available in browsers and web 1975 servers. 1977 Such kind of identifiers have been recently suggested also within the 1978 set of principles and technologies, known as "Linked Data" as a basic 1979 infrastructure of the semantic web to enable data sharing and reuse 1980 on a massive scale. 1982 Such principles, introduced by Tim Berners-Lee in his Web 1983 architecture note "Linked Data" 1984 (http://www.w3.org/DesignIssues/LinkedData.html), are synthetically: 1986 - Use URIs as names for things; 1987 - Use HTTP URIs, so that people can look up those names; 1988 - When someone looks up a URI, provide useful information, using the 1989 standards (RDF, SPARQL); 1990 - Include links to other URIs, so that they can discover more 1991 things. 1993 The second principle is the one more affecting a discussion about the 1994 scheme to be used for legal resources identification; in particular 1995 to the aim of guaranteeing the access to the resources, http-based 1996 identifiers are suggested. This property is addressed as 1997 "dereferenceability", meaning a resource retrieval mechanism using 1998 any of the Internet protocols, e.g. HTTP, so that HTTP clients, for 1999 instance, can look up the URI using the HTTP protocol and retrieve a 2000 description of the resource that is identified by the URI. 2001 Such property is available for http-based identifiers either with or 2002 without a resolver allowing a 1-to-1 association with the "best copy" 2003 of the resource; in the legal domain it is related to the unique act 2004 manifestation of a specific publisher and format. 2006 The same property holds for URN identifiers, as long as a resolver is 2007 properly set-up, allowing 1-to-N association with more manifestations 2008 of a resource (act). 2010 Therefore an http-based identifier, stable and independent from the 2011 resource location, can be effectively used when a single publisher 2012 provides a specific item of this resource (1-to-1 mapping between an 2013 identifier and manifestation of an act). The independence from the 2014 resource location is managed by a "303 Redirect" status code (see 2015 http://linkeddatabook.com/editions/1.0/#htoc11) which may require a 2016 resolver able to access the physical location of the resource (e.g., 2017 through submitting a query to a database). A URN identifier, stable 2018 and independent form the resource location, can be effectively used 2019 within a federative environment where different publishers can 2020 provide different items of the same act (1-to-N mapping between an 2021 identifier and different manifestations of an act). 2023 In order to comply with the Linked Data principles and to build http- 2024 based identifiers using the LEX namespace specifications, the LEX 2025 schema and metadata set can be serialized according to an http URI 2026 syntax. It is worthwhile to mention that URN focuses on identifying 2027 an act, while Linked Data principles focus on identifying a resource 2028 on the Web. 2030 In the following sections the http-based serialization of the urn LEX 2031 schema is reported. 2033 D2 The http-based LEX identifier structure 2035 The http-based hierarchical structure of the LEX identifier is the 2036 following: 2038 "http://" host-name "/lex/" jurisdiction "/" local-name 2040 where: 2041 - represents the name of the organization server 2042 publishing the resource; 2043 - "lex" is the equivalent of the URN namespace ID and provides the 2044 reference to the naming convention adopted; 2045 - and share meaning and syntax of the 2046 corresponding components in the LEX specifications. 2048 The element follows the syntax rules of the 2049 corresponding element in the URN specification, therefore it has the 2050 following structure: 2052 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 2054 The character ";" still separates the identification code of the 2055 country or jurisdiction where the source of law is issued 2056 () from any possible administrative hierarchical 2057 sub-structures defined by each country or organisation according to 2058 its own legal system. 2060 The follows the FRBR model as implemented by the LEX 2061 specifications, therefore its http-based structure is the following: 2063 local-name = work "/@/" expression "/$/" manifestation 2065 D3 The http-based LEX identifier at Work Level 2067 According to the corresponding level of the URN version, the http- 2068 based LEX identifier structure at work level is the following: 2070 work = authority "/" measure "/" details *("/" annex) 2072 The elements , and follow the same 2073 syntax rules of the corresponding elements in the URN specification. 2075 Examples of http-based identifiers at level, corresponding to 2076 the urn-based examples in Section 4.4, are the following: 2078 http:///lex/it/stato/legge/2006-05-14;22 2079 http:///lex/uk/ministry.justice/decree/1999-10-07;45 2080 http:///lex/ch;glarus/regiere/erlass/2007-10-15;963 2081 http:///lex/es/tribunal.supremo/decision/2001-09-28;68 2082 http:///lex/fr/assemblee.nationale/proposition.loi/ 2083 13.legislature;1762 2084 http:///lex/br/estado/constituicao/1988-10-05;lex-1 2085 http:///lex/fsf.org/free.software.foundation/ 2086 general.public.license/2007-06-29;lex-1 2087 http:///lex/nl/hoge.raad/besluit/2008-04-01;bc8581 2089 D4 The http-based LEX identifier at Expression Level 2091 According to the corresponding level of the URN version, the http- 2092 based LEX structure at expression level is the following: 2094 expression = version ["/" language] 2096 The elements and follow the same syntax rules of 2097 the corresponding elements in the URN specification. 2099 Examples of http-based identifiers at expression level, corresponding 2100 to the urn-based examples in Section 4.6, are the following: 2102 http:///lex/ch/etat/loi/2006-05-14;22/@/originel/fr 2103 (original version in French) 2104 http:///lex/ch/staat/gesetz/2006-05-14;22/@/original/de 2105 (original version in German) 2106 http:///lex/ch/etat/loi/2006-05-14;22/@/2008-03-12/fr 2107 (amended version in French) 2108 http:///lex/ch/staat/gesetz/2006-05-14;22/@/2008-03-12/de 2109 (amended version in German) 2110 http:///lex/be/conseil.etat/decision/2008-07-09;185.273 2111 /@/originel/fr 2112 (original version in French of a Belgian decision) 2114 D5 The http-based LEX identifier at Manifestation Level 2116 Information provided in the URN version at manifestation level is 2117 differently accommodated in the corresponding level of the http-based 2118 LEX identifier. 2120 The element, reported at manifestation level in the urn- 2121 based LEX version, is an information already contained in the of the http-based LEX identifier, therefore it is omitted in 2123 the elements. 2124 Similarly the element is omitted since it loses its meaning 2125 which would derived from the comparison between different 2126 manifestations. 2128 The element is reported as unique extension of the data 2129 format in which the manifestation is drafted. The value is compliant 2130 with the registered file extensions, thus it can be "pdf" for PDF, 2131 "doc" for MS Word, "xml" for XML documents, "tif" for tiff image 2132 format, etc. 2134 Therefore the http-based LEX structure at manifestation level is the 2135 following: 2137 manifestation = [ component *(";" specification)] "." format 2139 The element follows the same syntax rules of the 2140 corresponding element in the URN specification. 2142 Examples of http-based identifiers at manifestation level, 2143 corresponding to the urn-based examples in Section 4.7 are the 2144 following: 2146 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/testo.xml 2147 (body of the Italian law 3 April 2000, n. 56, published by the 2148 Italian Senate in xml format) 2149 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/figura.1.pdf 2150 (Figure 1 in PDF format of the Italian law 3 April 2000, n. 56, 2151 published by the Italian Senate) 2152 http://www.juradmin.eu/jurifast/lex/eu/tibunal.justicia/sentencia/ 2153 2009-06-11;33-08/@/original/es/$/todo.html 2154 (the Spanish http-based LEX identifier of the html format of the 2155 whole Judgement of the European Court of Justice n. 33/08 of 2156 11/06/2009, in Spanish version, published by the Juriadmin site in 2157 the Jurifast data base) 2158 http://eur-lex.europa.eu/lex/eu/commission/directive/ 2159 2010-03-09;2010-19-EU/$/body.xml 2160 (body of the EU Directive n. 2010-19-EU, dated 2010-03-09, in its 2161 XML format published by Eur-Lex)