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