idnits 2.17.1 draft-spinosa-urn-lex-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2018) is 2150 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT P. Spinosa 3 Intended Status: Informational (ICT consultant) 4 Expires: December 8, 2018 E. Francesconi 5 ITTIG/CNR 6 C. Lupo 7 (ICT consultant) 8 June 6, 2018 10 A Uniform Resource Name (URN) Namespace 11 for Sources of Law (LEX) 12 draft-spinosa-urn-lex-13.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 December 8, 2018. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Abstract 51 This document describes a Uniform Resource Name (URN) Namespace 52 Identification (NID) convention as prescribed by the Internet 53 Engineering Task Force (IETF) for identifying, naming, assigning, and 54 managing persistent resources in the legal domain. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1 The Purpose of Namespace "lex" . . . . . . . . . . . . . . 5 60 1.2 Entities Supporting this Standard . . . . . . . . . . . . . 5 61 1.3 The Context . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.4 General Characteristics of the System . . . . . . . . . . . 8 63 1.5 Linking a LEX Name to a Document . . . . . . . . . . . . . 9 64 1.6 Use of LEX Names in References . . . . . . . . . . . . . 10 65 1.7 Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 66 1.8 Terminology . . . . . . . . . . . . . . . . . . . . . . . 11 67 1.9 Syntax Used in this Document . . . . . . . . . . . . . . 11 68 2 Registration Template . . . . . . . . . . . . . . . . . . . . 11 69 3 Specifications of Registration Template . . . . . . . . . . . 15 70 3.1 Identifier structure . . . . . . . . . . . . . . . . . . 15 71 3.2 Conformance with URN Syntax . . . . . . . . . . . . . . . 16 72 3.3 Validation Mechanism . . . . . . . . . . . . . . . . . . 16 73 3.4 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 4 General Syntax and Features of the LEX Identifier . . . . . . 16 75 4.1 Allowed and Not Allowed Characters . . . . . . . . . . . 16 76 4.2 Reserved Characters . . . . . . . . . . . . . . . . . . . 17 77 4.3 Case Sensitivity . . . . . . . . . . . . . . . . . . . . 17 78 4.4 National Characters and Diacritic Signs . . . . . . . . . 17 79 4.5 Abbreviations . . . . . . . . . . . . . . . . . . . . . . 18 80 4.6 Date Format . . . . . . . . . . . . . . . . . . . . . . . 18 81 5 Specific Syntax and Features of the LEX Identifier . . . . . . 18 82 5.1 Spaces, Connectives and Punctuation Marks . . . . . . . . 19 83 5.2 Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 19 84 5.3 Ordinal Numbers . . . . . . . . . . . . . . . . . . . . . 19 85 6 Creation of the Source of Law LEX Identifier . . . . . . . . . 19 86 6.1 Basic Principles . . . . . . . . . . . . . . . . . . . . 19 87 6.2 Model of Sources of Law Representation . . . . . . . . . 20 88 6.3 The Structure of the Local Name . . . . . . . . . . . . . 20 89 6.4 Structure of the Document Identifier at Work Level . . . 21 90 6.5 Aliases . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 6.6 Structure of the Document Identifier at Expression Level 23 92 6.7 Structure of the Document Identifier at Manifestation 93 Level . . . . . . . . . . . . . . . . . . . . . . . . . . 24 94 6.8 Sources of Law References . . . . . . . . . . . . . . . . 26 95 7 The Procedure of Uniform Names Assignment . . . . . . . . . . 27 96 7.1 Specifying the Element of the LEX 97 Identifier . . . . . . . . . . . . . . . . . . . . . . . 27 98 7.2 Jurisdictional Registrar for Names Assignment . . . . . . 27 99 7.3 Identifier Uniqueness . . . . . . . . . . . . . . . . . . 28 100 7.4 Identifier Persistence Considerations . . . . . . . . . . 28 101 8 Principles of the Resolution Service . . . . . . . . . . . . . 29 102 8.1 The General Architecture of the System . . . . . . . . . 29 103 8.2 Catalogues for Resolution . . . . . . . . . . . . . . . . 30 104 8.3 Suggested Resolver Behaviour . . . . . . . . . . . . . . 31 105 9 Namespace Considerations . . . . . . . . . . . . . . . . . . . 31 106 10 Community Considerations . . . . . . . . . . . . . . . . . . 32 107 11 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 108 11.1 NID Registration . . . . . . . . . . . . . . . . . . . . 32 109 11.2 Jurisdiction-code Registration . . . . . . . . . . . . . 33 110 12 References . . . . . . . . . . . . . . . . . . . . . . . . . 34 111 12.1 Normative References . . . . . . . . . . . . . . . . . . 34 112 12.2 Informative References . . . . . . . . . . . . . . . . . 35 113 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 35 114 14 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 36 115 Attachment A -- Summary of the Syntax of the Uniform Names of 116 the "lex" Namespace . . . . . . . . . . . . . . . . . 37 117 Attachment B -- Specific Syntax of the Identifier at Work Level . 41 118 B1 The Element . . . . . . . . . . . . . . . . . . . 41 119 B1.1 Indication of the Authority . . . . . . . . . . . . . . 41 120 B1.2 Multiple Issuers . . . . . . . . . . . . . . . . . . . . 41 121 B1.3 Indication of the Issuer . . . . . . . . . . . . . . . . 41 122 B1.4 Indication of the Body . . . . . . . . . . . . . . . . . 41 123 B1.5 Indication of the Function . . . . . . . . . . . . . . . 42 124 B1.6 Conventions for the Authority . . . . . . . . . . . . . 42 125 B2 The Element . . . . . . . . . . . . . . . . . . . . 42 126 B2.1 Criteria for the Indication of the Type of Measure . . . 42 127 B2.2 Further Specification to the Type of Measure . . . . . . 43 128 B2.3 Aliases for Sources of Law with Different Normative 129 References . . . . . . . . . . . . . . . . . . . . . . . 43 130 B2.4 Relations between Measure and Authority in the Aliases . 43 131 B3 The
Element . . . . . . . . . . . . . . . . . . . . 44 132 B3.1 Indication of the Details . . . . . . . . . . . . . . . 44 133 B3.2 Multiple Dates . . . . . . . . . . . . . . . . . . . . . 44 134 B3.3 Unnumbered Measures . . . . . . . . . . . . . . . . . . 45 135 B3.4 Multiple Numbers . . . . . . . . . . . . . . . . . . . . 45 136 B4 The Element . . . . . . . . . . . . . . . . . . . . . 46 137 B4.1 Formal Annexes . . . . . . . . . . . . . . . . . . . . . 46 138 B4.2 Annexes of Annexes . . . . . . . . . . . . . . . . . . . 46 139 Attachment C -- Specific Syntax of the Element of the 140 Expression . . . . . . . . . . . . . . . . . . . . . 47 141 C1 The Element . . . . . . . . . . . . . . . . . . . . 47 142 C1.1 Different Versions of a Legislative Document . . . . . . 47 143 C1.2 Identification of the Version . . . . . . . . . . . . . 47 144 Attachment D -- Http LEX Identifier . . . . . . . . . . . . . . . 50 145 D1 Http URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 146 D2 The Http LEX Identifier Structure . . . . . . . . . . . . . . 51 147 D3 The Http LEX Identifier at Work Level . . . . . . . . . . . . 52 148 D4 The Http LEX Identifier at Expression Level . . . . . . . . . 52 149 D5 The Http LEX Identifier at Manifestation Level . . . . . . . . 53 151 1 Introduction 153 1.1 The Purpose of Namespace "lex" 155 The purpose of the "lex" namespace is to assign an unequivocal 156 identifier, in standard format, to documents that are sources of law. 157 To the extent of this namespace, "sources of law" include any legal 158 document within the domain of legislation, case law and 159 administrative acts or regulations; moreover potential "sources of 160 law" (acts under the process of law formation, as bills) are included 161 as well. Therefore "legal doctrine" is explicitly not covered. 163 The identifier is conceived so that its recommended construction 164 depends only on the characteristics (details) of the document itself 165 and is, therefore, independent from the document's on-line 166 availability, its physical location, and access mode. The identifier 167 itself is assigned by the jurisdiction that owns the identified 168 document. Even a document that is not available online at all may 169 still have a URN LEX that identifies it. 171 This identifier will be used as a way to represent the references 172 (and more generally, any type of relation) among the various sources 173 of law. In an on-line environment with resources distributed among 174 different Web publishers, uniform resource names allow simplified 175 global interconnection of legal documents by means of automated 176 hypertext linking. LEX URNs are therefore particularly useful when 177 they can be mapped into or associated with locators such as HTTP 178 URLs. 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 Publications Office of 262 the European Union (OP), with the aim of promoting interoperability 263 among national and European institution information systems. Similar 264 concerns have been raised by international groups concerned with free 265 access to legal information, and the Permanent Bureau of the Hague 266 Conference on Private International Law is considering a resolution 267 that would encourage member states to "adopt neutral methods of 268 citation of their legal materials, including methods that are medium- 269 neutral, provider-neutral and internationally consistent". In a 270 similar direction the CEN Metalex initiative is moving, at European 271 level, towards the definition of a standard interchange format for 272 sources of law, including recommendations for defining naming 273 conventions to them. 275 The need of unequivocal identifiers for sources of law is of 276 particular interest also in the domain of case law. Such need is 277 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 stressed in the resolution of the European Parliament of 9 289 July 2008 on the role of the national judge in the European judicial 290 system. 291 Similarly the European e-Justice action plans 2009-2013 and 2014-2018 292 of the Council of the European Union underlined the importance of 293 cross-border 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. 303 More recently the Council of the European Union invited the Member 304 States to introduce in the legal information systems the European 305 Legislation Identifier (ELI), an http-based Semantic Web oriented 306 identification system for European Union and Member States 307 legislation. 309 LEX identifier is conceived to be general enough, so to provide 310 guidance at the core of the standard and sufficient flexibility to 311 cover a wide variety of needs for identifying all the legal documents 312 of different nature, namely legislative, case-law and administrative 313 acts. Moreover, it can be effectively used within a federative 314 environment where different publishers (public and private) can 315 provide their own items of an act (that is there is more than one 316 manifestation of the same act). 317 However specifications and syntax rules of LEX identifier can be used 318 also for http-based naming convention (Appendix D) to cope with 319 different requirements in legal information management, for example 320 the need of having an identifier compliant with the Linked Open Data 321 principles. 323 This document supplements the required name syntax with a suggested 324 naming convention that interprets all these recommendations into an 325 original solution for sources of law identification. 327 1.4 General Characteristics of the System 329 Registrants wish now to promote interoperability among legal 330 information systems by the definition of a namespace convention and 331 structure that will create and manage identifiers for legal 332 documents. The identifiers will be: 333 - globally unique 334 - transparent 335 - bidirectional 336 - persistent 337 - location-independent, and 338 - language-neutral. 339 These qualities will facilitate legal document management as well as 340 provide a mechanism of stable cross-collections and cross-country 341 references. 343 Transparency means that given an act and its relevant metadata 344 (issuing authority, type of measure, etc.) it is possible to create 345 the related urn identifier. Moreover this identifier is able to 346 unequivocally identify the related act. These two properties makes 347 the identification system bidirectional (from an act to its URN and 348 from a URN to the related act). 350 Language-neutrality is an especially important feature that will 351 promote adoption of the standard by organizations that must adhere to 352 official-language requirements. The proposed standard will provide 353 useful guidance to both public and private groups that create, 354 promulgate, and publish legal documents. Registrants wish to minimize 355 the potential for creating conflicting proprietary schemes, while 356 preserving sufficient flexibility to allow for diverse document types 357 and to respect the need for local control of collections by an 358 equally diverse assortment of administrative entities. 360 As usual, the problem is to provide the right amount guidance at the 361 core of the standard while providing sufficient flexibility to cover 362 a wide variety of needs. The proposed LEX standard does this by 363 splitting the identifier into parts. The first part uses a 364 predetermined standard ("country/jurisdiction name standard") to 365 specify the country (or more generally the jurisdiction) of origin 366 for the legal document being identified; the remainder ("local name") 367 is intended for local use in identifying documents issued in that 368 country or jurisdiction. This second part depends only on sources of 369 law identification system operating in that nation and it is mainly 370 composed by a formalized information related to the enacting 371 authority, the type of measure, the details and possibly the annex. 373 The identification system based on uniform names SHOULD include: 374 - a schema for assigning names capable of representing unambiguously 375 any addressed source of law, namely legislation, case law and 376 administrative acts, issued by any authority (intergovernmental, 377 supranational, national, regional and local) at any time (past, 378 present and future); 379 - a resolution mechanism - in a distributed environment - that ties a 380 uniform name to the on-line location of the corresponding 381 resources. 382 This document only considers the first of these requirements. It also 383 contains a few references to the architecture of the resolution 384 service and to the corresponding software. 386 1.5 Linking a LEX Name to a Document 388 The LEX name is linked to the document through meta-information which 389 may be specified: 390 - internally to the document itself through a specific element within 391 an XML schema or by an HTML META tag; 392 - externally by means of an RDF triple, a specific attribute in a 393 database, etc. 394 One of these modalities is necessary for enabling automated 395 construction and updating of catalogues (distributed and centralized) 396 and the implementation of resolvers that associate the uniform name 397 of a document with its physical location(s). The standard assumes no 398 particular relationship between the originator of the document, its 399 publisher, and the implementer of catalogues or resolution services. 400 They may be the same entity, or not. 402 1.6 Use of LEX Names in References 404 LEX names will be used on a large scale in references as a HREF 405 attribute value of the hypertext link to the referred document. 406 This link can be created in two ways: 407 - by manually inserting, in the referring document, the link with the 408 uniform name: this is a burdensome procedure especially for 409 documents that are already on-line; 410 - by automatically constructing (either permanently or temporarily) 411 the link with the uniform name, through reference parsers of a 412 text: this is a more time-saving procedure even if subject to a 413 certain percentage of errors, since references are not always 414 accurate or complete. This solution could nevertheless be 415 acceptable for already published documents. 416 In any case, whatever the method adopted is, new documents produced 417 in XML format compliant with the relative DTD/XMLSchema, SHOULD 418 express references through the uniform name of the document referred 419 to. 421 1.7 Definitions 423 According to this document, the following terms are used in the 424 following meaning: 425 - Source of Law: 426 is a general concept, and is used to refer to legislation, case 427 law, regulations and administrative acts. In its broadest sense, 428 the source of law is anything that can be conceived of as the 429 originator of 'erga omnes' legal rules. In this document "source of 430 law" refers also to acts during their formation cycle as bills that 431 might or might not become sources of law; 432 - Jurisdictional Registrar: 433 is an organization which shares and defines in any country or 434 jurisdiction the assignment of the main components of the resource 435 identifier through which its uniqueness is guaranteed. This task 436 includes the definition of possible jurisdiction unit and the 437 primary elements (issuing authority and type of legal measure) of 438 uniform name, according to the characteristics of its own state or 439 institution organization. 441 1.8 Terminology 443 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 444 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 445 document are to be interpreted as described in [RFC2119]. 447 1.9 Syntax Used in this Document 449 This document uses the syntax common to many Internet RFCs, which is 450 based on the ABNF (Augmented Backus-Naur Form) [RFC5234] meta- 451 language. 453 2 Registration Template 455 Namespace Identifier: 457 "lex" requested according to [RFC8141]. 459 Version: 461 1.0 463 Date: 465 2018-06-06 467 Registrant: 469 Institute of Legal Information Theory and Techniques (ITTIG) 470 Italian National Research Council (CNR) 471 Via de' Barucci, 20 472 50127 Florence 473 Italy 474 e-mail: lex@ittig.cnr.it 475 phone: +39 055 43995 477 contact: Enrico Francesconi 478 e-mail: enrico.francesconi@ittig.cnr.it 480 Purpose: 482 The purpose of the "lex" namespace is to assign an unequivocal 483 identifier, in standard format, to documents that are sources 484 of law. 486 In the last few years a number of institutional initiatives 487 have arisen in the field of legal document management. They 488 were aimed at introducing standards for sources of law 489 description and identification using XML and URI techniques, 490 respectively (for more details see Section 1.3) LEX identifier 491 is conceived to be general enough, so to provide guidance at 492 the core of the standard and sufficient flexibility to cover a 493 wide variety of needs for identifying all the legal documents 494 of different nature, namely legislative, case-law and 495 administrative acts. Moreover, it can be effectively used 496 within a federative environment where different publishers 497 (public and private) can provide their own items of an act 498 (that is there is more than one manifestation of the same act). 500 The LEX identifier is conceived to be: globally unique, 501 transparent, bidirectional, persistent, location-independent, 502 and language-neutral. It is organized into parts. The first 503 part uses a predetermined standard to specify the country (or 504 more generally the jurisdiction) of origin for the legal 505 document being identified; the remainder is intended for local 506 use in identifying documents issued in that country or 507 jurisdiction. This second part depends only on sources of law 508 identification system operating in that nation. For more 509 details on the nature of the LEX characteristics and the 510 general internal organization, see Section 1.4. 512 The LEX name is linked to the document through specific meta- 513 information, internally (with a tag) or externally (with a 514 attribute) (for details on this see Section 1.5) 516 LEX names will be used on a large scale in references either in 517 (X)HTML document or, more generally, in XML documents format 518 compliant with the relative DTD/XMLSchema (see Section 1.6 for 519 more information). 521 Syntax: 523 The identifier has a hierarchical structure as follows: 525 "urn:lex:" NSS 527 where is the Namespace Specific String composed as 528 follows: 530 NSS = jurisdiction ":" local-name 532 where: 534 is the part providing the identification of the 535 jurisdiction, generally corresponding to the country, where the 536 source of law is issued. It is also possible to represent 537 international organizations (either states or public 538 administrations or private entities); 540 is the uniform name of the source of law in the 541 country or jurisdiction where it is issued; its internal 542 structure is common to the already adopted schemas. It is able 543 to represent all the aspects of an intellectual production, as 544 it is a legal document, from its initial idea, through its 545 evolution during the time, to its realisation by different 546 means (paper, digital, etc.). 548 LEX specifications gives information on the internal structure 549 of both and , including 550 specifications about case sensitivity, the use of national 551 characters and diacritics, as well as spaces, connectives, 552 punctuation marks, abbreviations, acronyms, date formats and 553 ordinal numbers. For more details on the internal structure and 554 syntax of the LEX identifier, see Section 3, 4 and 5. 556 The use of r- and q- components, recently introduced by 557 [RFC8141], with LEX URNs is not defined in this document. 558 However they provide new and interesting perspectives when 559 using URNs in a complex sector as sources of law, characterized 560 by different versions, languages, publishers, and so on. In 561 particular, by using the r-component at the resolver level, and 562 therefore at the whole NSS level, you can select from the same 563 work only expressions written in a given language, or 564 manifestations published by a particular institutional site, 565 etc. Using the q-component at the act metadata level, you can 566 select versions that are valid at a particular date, or 567 modified by a specific act, etc. 569 Assignment: 571 The Jurisdictional Registrar (or those it delegates) of each 572 adhering country or organization is responsible of the 573 definition or acceptance of the uniform name's primary elements 574 (issuing authority and type of legal measure). 576 Any country or jurisdiction, aiming to adopt this schema, 577 identifies a Jurisdictional Registrar, an organization which 578 shares and defines the structure of the optional part of the 579 name, according to the organization of the state or 580 institution. The process of assigning the will be 581 managed by each specific country or jurisdiction under the 582 related element (details on this can be found in 583 Section 7.2). 585 Identifiers in the "lex" namespace are defined through a 586 element assigned to the sources of law of a 587 specific country or organization, and a assigned 588 by the issuing authority. The goal of the LEX schema is to 589 maintain uniqueness and persistence of all resources identified 590 by the assigned URNs. The elements values for the LEX 591 identifier within a jurisdiction are defined by the 592 Jurisdictional Registrar, this ensures that the constructed 593 URNs are unique (see Section 7.3 for details on uniqueness). 595 The persistence of identifiers depends on the durability of the 596 institutions that assign and administer them (see Section 7.3 597 for details on persitence) 599 Security and Privacy: 601 This document introduces no additional security considerations 602 beyond those associated with the use and resolution of URNs in 603 general. 605 Interoperability: 607 As open standard naming convention to identify sources of law 608 at international level, LEX is meant to guarantee 609 interoperability among legal information systems across 610 national boundaries. 612 The characteristics of the LEX naming convention facilitate 613 legal document management as well as provide a mechanism of 614 stable cross-collections and cross-country references, thus 615 allowing the distribution of the legal information towards a 616 federated architecture. 618 Resolution: 620 The resolution service associates a LEX identifier with a 621 specific document address on the net. The related system will 622 have a distributed architecture based on two fundamental 623 components: a chain of information in DNS (Domain Name System) 624 and a series of resolution services from URNs to URLs, each 625 competent within a specific domain of the namespace (see 626 Section 8.1 for more details). 628 To cope with possible incomplete or inaccurate uniform names, 629 the implementation of a catalogue, based on a relational- 630 database, able to associate a URN to related URLs, is 631 suggested, as it will lead to a higher flexibility in the 632 resolution process. A resolver can provide names normalization, 633 completion of inaccurate or incomplete names, and finally their 634 resolution in network locations (see Section 8.2 and 8.3 for 635 characteristics and behaviour of a catalogue for resolution). 637 Documentation: 639 The syntax, semantics and usage details of LEX URNs are given 640 in [this RFC]. 642 Additional Information: 644 See [FRAN] and [SPIN]. 646 Revision Information: 648 None 650 3 Specifications of Registration Template 652 3.1 Identifier structure 654 The element is composed of two specific fields: 656 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 658 where: 660 is usually the identification code of the country 661 where the source of law is issued. 663 To facilitate the transparency of the name, the 664 follows usually the rules of identification of other Internet 665 applications, based on Domain Name. 666 Where applicable, the ccTLD, or the TLD, or the Domain Name of the 667 country or multinational or international organisation is used. 668 Examples reported in this document are hypothetical and assumed that 669 the corresponding Domain Name is used for the . 671 However, a special register for the is required, 672 the rules of which are defined in section 11.2. 674 are the possible administrative hierarchical sub- 675 structures defined by each country or organisation within their 676 specific legal system. This additional information can be used in 677 case two or more levels of legislative or judicial production exist 678 (e.g., federal, state and municipality level) and the same bodies may 679 be present in each jurisdiction. Therefore acts of the same type 680 issued by similar authorities in different areas differ for the 681 jurisdiction-unit specification. An example can be the following: 682 "br:governo:decreto" (decree of federal government), 683 "br;sao.paulo:governo:decreto" (decree of SU+000000E3o Paulo state) 684 and "br;sao.paulo;campinas:governo: decreto" (decree of Campinas 685 municipality). 687 Examples (hypothetical) of sources of law identifiers are: 689 urn:lex:it:stato:legge:2003-09-21;456 (Italian act) 690 urn:lex:fr:etat:loi:2004-12-06;321 (French act) 691 urn:lex:es:estado:ley:2002-07-12;123 (Spanish act) 692 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 (Glarus Swiss Canton 693 decree) 694 urn:lex:eu:commission:directive:2010-03-09;2010-19-EU (EU Commission 695 Directive) 696 urn:lex:us:federal.supreme.court:decision:1963-03-18;372.us.335 (US 697 FSC decision) 698 urn:lex:be:conseil.etat:decision:2008-07-09;185.273 (Decision of the 699 Belgian Council of State) 701 3.2 Conformance with URN Syntax 703 The "lex" NID syntax conforms to [RFC8141]. However, a series of 704 characters are reserved to identify elements or sub-elements, or for 705 future extensions of the identifier. 707 3.3 Validation Mechanism 709 The Jurisdictional Registrar (or those it delegates) of each adhering 710 country or organization is responsible of the definition or 711 acceptance of the uniform name's primary elements (issuing authority 712 and type of legal measure). 714 3.4 Scope 716 Global interest. 718 4 General Syntax and Features of the LEX Identifier 720 This section lists the general features applicable to all 721 jurisdictions. 723 4.1 Allowed and Not Allowed Characters 725 These characters are defined in accordance with the [RFC8141] 726 "Uniform Resource Names (URNs)". For various reasons, later 727 explained, in the "lex" only a sub-set of characters is 728 allowed. All other characters are either eliminated or converted. 730 For the full syntax of the uniform names in the "lex" space, please 731 see Attachment A. 733 4.2 Reserved Characters 735 These characters MUST always and uniquely be used for the assigned 736 purpose. 737 The first category includes those characters bearing a specific 738 meaning in the general creation of the URI (Uniform Resource 739 Identifier)[RFC3986] as "%", "?", "#" , etc. 741 The following characters instead are reserved in the specific "lex" 742 namespace: 744 - "@" separator of the expression, that contains information on 745 version and language; 746 - "$" separator of the manifestation, that contains information on 747 format, editor, etc.; 748 - ":" separator of the main elements of the name at any entity; 749 - ";" separator of level. It identifies the introduction of an 750 element at a hierarchically lower level, or the introduction of a 751 specification; 752 - "+" separator of the repetitions of an entire main element (e.g., 753 multiple authorities); 754 - "," separator of the repetitions of individual components in the 755 main elements, each bearing the same level of specificity (e.g., 756 multiple numbers); 757 - "~" separator of the partition identifier in references (e.g., 758 paragraph of an article); 759 - "*" and "!" are reserved for future expansions. 761 To keep backward compatibility with existing applications in some 762 jurisdictions, the "lex" NID syntax does not include the use of the 763 character "/" in this version. 765 4.3 Case Sensitivity 767 Names belonging to the "lex" namespace are case-insensitive. It is 768 RECOMMENDED that they be created in lower case, but names that differ 769 only in case MUST be considered to be equivalent. 770 (e.g., "Ministry" will be recorded as "ministry"). 772 4.4 National Characters and Diacritic Signs 774 In order to exploit DNS as a routing tool towards the proper 775 resolution system, to keep editing and communication more simple and 776 to avoid character percent-encoding, it is strongly RECOMMENDED that 777 national characters and diacritic signs are turned into base ASCII 778 characters (e.g., the Italian term "sanitU+000000E0" converted into 779 "sanita", the French term "ministU+000000E8re" converted into 780 "ministere"), in case by transliteration (e.g. "MU+000000FCnchen" 781 converted into "muenchen"). 783 If this conversion is not acceptable by a specific jurisdiction, UTF- 784 8 %-encoding [STD63] may be used. In this case it should be noted 785 that the generated URN (as some of its parts) can not be used 786 directly for routing through DNS, and therefore the jurisdiction must 787 adopt one of the following strategies: 788 - to convert non-ASCII characters within the DNS into the IDN 789 encoding, using the [RFC5894] punycode translation (ex: 790 mU+000000FCnchen in xn--mnchen-3ya), and to develop an interface 791 software that converts the URN before the navigation in DNS, or 792 - to create a routing service relying to a software, out of DNS, 793 addressing a proper resolution service. 795 Summarizing, the preference order is the following: 796 - Conversion into base ASCII (RECOMMENDED solution); 797 - Conversion to punycode only for navigation in DNS, via software 798 interface; 799 - Creation of a routing service relying on a software, out of DNS, 800 addressing a proper resolution service. 801 The first solution allows native DNS routing, while the other two 802 require a software development for the interface or the routing. 803 However it is up to the specific jurisdiction to choose the preferred 804 solution. 806 4.5 Abbreviations 808 Abbreviations are often used in law for indicating institutions (e.g. 809 Min.), structures (e.g. Dept.), or legal measures (e.g. Reg.) but not 810 in a uniform way, therefore their expansion is highly RECOMMENDED. 811 (e.g., "Min." is reported as "ministry") 813 4.6 Date Format 815 Dates are expressed by numbers in the [ISO8601] format: 817 yyyy-mm-dd 819 (e.g., "September 2, 99" will be written as "1999-09-02") 821 5 Specific Syntax and Features of the LEX Identifier 822 In this section there are other features related to a specific 823 jurisdiction and the implementation of which is recommended. 825 5.1 Spaces, Connectives and Punctuation Marks 827 All the language connectives (e.g., articles, prepositions, etc.), 828 the punctuation marks and all the special characters (as apostrophes, 829 dashes, etc.), when explicitly present, are eliminated (no 830 transformation occurs in cases of languages with declensions or 831 agglutinating languages). The words left are connected each other by 832 a dot (".") which substitutes the "space". 833 (e.g., "Ministry of Finances, Budget and of Economic Planning" 834 becomes "ministry.finances.budget.economic.planning"; 835 "Ministerstvo Finansov" becomes "ministerstvo.finansov") 837 5.2 Acronyms 839 The use of acronyms might be confusing and encourage ambiguity in 840 uniform names (the same acronym may indicate two different 841 institutions or structures), therefore their expansion is highly 842 RECOMMENDED. 843 (e.g., "FAO" is expanded as "food.agriculture.organization") 845 5.3 Ordinal Numbers 847 To even the representation, it is highly RECOMMENDED that any ordinal 848 number included in a component of a document name (e.g., in the 849 description of an institution body) is indicated in Western Arabic 850 numerals, regardless to the original expression: whether in Roman 851 numerals, or with an adjective, or in Arabic numeral with apex, etc. 852 (IV, third, 1U+000000B0, 2^, etc.). 853 (e.g., "Department IV" becomes "department.4") 855 6 Creation of the Source of Law LEX Identifier 857 6.1 Basic Principles 859 The uniform name must identify one and only one document (more 860 precisely a "bibliographic entity") and is created in such a way that 861 it is: 862 - self-explanatory ; 863 - identifiable through simple and clear rules; 864 - compatible with the practice commonly used for references; 865 - able to be created from references in the text, automatically (by 866 parser) or manually; 867 - representative of both the formal and the substantive aspects of 868 the document. 870 6.2 Model of Sources of Law Representation 872 According to FRBR (Functional Requirements for Bibliographic Records) 873 model developed by IFLA (International Federation of Library 874 Associations and Institutions), in a source of law, as in any 875 intellectual production, 4 fundamental entities (or aspects) can be 876 specified. 878 The first 2 entities reflect its contents: 879 - work: identifies a distinct intellectual creation; in our case, it 880 identifies a source of law both in its being (as it has been issued 881 or proposed) and in its becoming (as it is modified over time); 882 - expression: identifies a specific intellectual realisation of a 883 work; in our case it identifies every different (original or up-to- 884 date) version of the source of law over time and/or language in 885 which the text is expressed; 886 while the other 2 entities relate to its form: 887 - manifestation: identifies a concrete realisation of an expression; 888 in our case it identifies realizations in different media 889 (printing, digital, etc.), encoding formats (XML, PDF, etc.), or 890 other publishing characteristics; 891 - item: identifies a specific copy of a manifestation; in our case it 892 identifies individual physical copies as they are found in 893 particular physical locations. 895 In this document the FRBR model has been interpreted for the specific 896 characteristics of the legal domain. In particular, a part from the 897 language which does produce a specific expression, the discriminative 898 criterion between expression and manifestation is based on the 899 difference of the juridical effects that a variation can provide with 900 respect to the involved actors (citizens, parties, institutions). In 901 this scenario the main characteristic of the expression of an act is 902 represented by its validity over the time, during which it provides 903 the same juridical effects. These effects change for amendments or 904 annulments of other legislative or jurisprudential acts. Therefore 905 notes, summarizations, comments, anonymizations and other editorial 906 activities over the same text do not produce different expressions, 907 but different manifestations. 909 6.3 The Structure of the Local Name 911 The within the "lex" namespace MUST contain all the 912 necessary pieces of information enabling the unequivocal 913 identification of a legal document. 914 In the legal domain, at the "work" level, they are essentially four: 915 the enacting authority, the type of measure, the details and the 916 annex, if any. 917 It is often necessary to differentiate various expressions, that is: 919 - the original version and all the amended versions of the same 920 document; 921 - the versions of the text expressed in the different official 922 languages of the state or organization. 923 Finally the uniform name allows a distinction among diverse 924 manifestations, which may be produced in multiple locations using 925 different means and formats. 926 In every case, the basic identifier of the source of law (work) 927 remains the same, but information is added regarding the specific 928 version under consideration (expression); similarly a suffix is added 929 to the expression for representing the characteristics of the 930 publication (manifestation). 931 The information which forms a source of law uniform name at each 932 level (work, expression, manifestation) is expressed in the official 933 language of the related jurisdiction; in case of more official 934 languages (as in Switzerland) or more involved jurisdictions (as in 935 international treaties), more language-dependent names (aliases) are 936 created. 938 Therefore, the more general structure of the local name appears as 939 follows: 941 local-name = work ["@" expression] ["$" manifestation] 943 However, consistent with legislative practice, the uniform name of 944 the main original provision (work) becomes the identifier of an 945 entire class of documents which includes: the original main document, 946 the annexes, and all their versions, languages and formats 947 subsequently generated. 949 6.4 Structure of the Document Identifier at Work Level 951 The structure of the document identifier is made of the four 952 fundamental elements mentioned above, clearly distinguished one from 953 the other in accordance with an order identifying increasingly narrow 954 domains and competences: 956 work = authority ":" measure ":" details *(":" annex) 958 where: 960 is the issuing or proposing authority of the measure 961 (e.g., State, Ministry, Municipality, Court, etc.); 963 is the type of the measure, both public nature (e.g., 964 constitution, act, treaty, regulation, decree, decision, etc.) as 965 well as private one (e.g., license, agreement, etc); 966
are the terms associated to the measure, typically the date 967 (usually the signature date) and the number included in the heading 968 of the act; 970 is the identifier of the annex, if any (e.g., Annex 1). 972 In case of annexes, both the main document and its annexes have their 973 own uniform name so that they can individually be referenced; the 974 identifier of the annex adds a suffix to that of the main document. 975 In similar way the identifier of an annex of an annex adds an ending 976 to that of the annex which it is attached to. 978 The main elements of the work name are generally divided into several 979 elementary components, and, for each, specific rules of 980 representation are established (criteria, modalities, syntax and 981 order). 982 For the details regarding each element, please see the Attachment B. 984 Examples (hypothetical) of identifiers are: 986 urn:lex:it:stato:legge:2006-05-14;22 987 urn:lex:uk:ministry.justice:decree:1999-10-07;45 988 urn:lex:ch;glarus:regiere:erlass:2007-10-15;963 989 urn:lex:es:tribunal.supremo:decision:2001-09-28;68 990 urn:lex:fr:assemblee.nationale:proposition.loi:13.legislature;1762 991 urn:lex:br:estado:constituicao:1988-10-05;lex-1 992 urn:lex:fsf.org:free.software.foundation:general.public.license:2007- 993 06-29;lex-1 994 urn:lex:nl:hoge.raad:besluit:2008-04-01;bc8581 996 It is worth to note that the type of measure is important to identify 997 case law, as well as legislation, especially within the legal systems 998 where cases, by tradition, are identified only through the year of 999 release and a number. Since the aim of the "urn:lex" schema is to 1000 identify specific materials, the type of measure or the full date are 1001 able to provide discrimination between materials belonging to a 1002 specific case. 1004 Here below is an example where the type of measure or the full date 1005 are essential for identify specific materials of a case: 1006 - 4/59 Judgement of the EEC Court of Justice 04/04/1960, Mannesmann 1007 AG and others / ECSC High Authority 1008 urn:lex:eec.lex.arpa:court.justice:judgement:1960-04-04;4-59 1009 - 4/59 Order of the EEC Court of Justice 18/05/1960, Mannesmann AG 1010 and others / ECSC High Authority 1011 urn:lex:eec.lex.arpa:court.justice:order:1960-05-18;4-59 1013 6.5 Aliases 1014 International treaties involve more jurisdictions (the signing ones) 1015 so they are represented through more identifiers, each of them 1016 related to an involved jurisdiction. For example, a bilateral France 1017 and Germany treaty is identified through two URNs (aliases) belonging 1018 to either "fr" or "de" jurisdiction 1019 (e.g., "urn:lex:fr:etat:traite:..." and 1020 "urn:lex:de:staat:vertrag:...") 1021 since it pertains to both the French and the German jurisdiction. 1023 In the states or organisations that have more than one official 1024 language, a document has more identifiers, each of them expressed in 1025 a different official language, basically a set of equivalent aliases. 1026 This system permits manual or automated construction of the uniform 1027 name of the referred source of law in the same language used in the 1028 document itself. 1029 (e.g., "urn:lex:eu:council:directive:2004-12-07;31", 1030 "urn:lex:eu:consiglio:direttiva:2004-12-07;31", etc.) 1032 Moreover, a document can be assigned more than one uniform name in 1033 order to facilitate its linking to other documents. This option can 1034 be used for documents that, although unique, are commonly referenced 1035 from different perspectives. For example, the form of a document's 1036 promulgation and its specific content (e.g., a Regulation promulgated 1037 through a Decree of the President of the Republic). 1039 6.6 Structure of the Document Identifier at Expression Level 1041 There may be several expressions of a legal text, connected to 1042 specific versions or languages. 1043 Each version is characterized by the period of time during which that 1044 text is to be considered as the valid text (in force or effective). 1045 The lifetime of a version ends with the issuing of the subsequent 1046 version. 1047 New versions of a text may be brought into existence by: 1048 - changes in the text (amendments) due to the issuing of other legal 1049 acts and to the subsequent production of updated or consolidated 1050 texts; 1051 - correction of publication errors (rectification or errata corrige); 1052 - entry into or departure from a particular time span, depending on 1053 the specific date in which different partitions of a text come into 1054 force. 1055 Each of such versions may be expressed in more than one language, 1056 with each language-version having its own specific identifier. 1057 The identifier of a source of law expression adds such information to 1058 the work identifier, using the following main structure: 1060 expression = version [":" language] 1062 where: 1064 is the identifier of the version of the (original or 1065 amended) source of law. In general it is expressed by the 1066 promulgation date of the amending act; anyway other specific 1067 information can be used for particular documents. If necessary, the 1068 original version is specified by the string "original" (for the 1069 details regarding this element, please see the Attachment C); 1071 is the identification code of the language in which the 1072 document is expressed, according to [BCP47] (it=Italian, fr=French, 1073 de=German, etc.). The granularity level of the language (for example 1074 the specification of the German language as used in Switzerland 1075 rather than the standard German) is left to each specific 1076 jurisdiction. The information is not necessary when the text is 1077 expressed in the unique official language of the country or 1078 jurisdiction. 1080 Examples (hypothetical) of document identifiers for expressions are: 1082 urn:lex:ch:etat:loi:2006-05-14;22@originel:fr (original version in 1083 French) 1084 urn:lex:ch:staat:gesetz:2006-05-14;22@original:de (original version 1085 in German) 1086 urn:lex:ch:etat:loi:2006-05-14;22@2008-03-12:fr (amended version in 1087 French) 1088 urn:lex:ch:staat:gesetz:2006-05-14;22@2008-03-12:de (amended version 1089 in German) 1090 urn:lex:be:conseil.etat:decision:2008-07-09;185.273@originel:fr 1091 (original version in French of a Belgian decision) 1093 6.7 Structure of the Document Identifier at Manifestation Level 1095 To identify a specific manifestation, the uniform name of the 1096 expression is followed by a suitable suffix describing the: 1097 - digital format (e.g., XML, HTML, PDF, etc.) expressed according to 1098 the MIME Content-Type standard [RFC2045], where the "/" character 1099 is to be substituted by the "-" sign; 1100 - editorial staff who produced it, expressed according to its 1101 Internet domain name. Since publishers' domain names may vary over 1102 time, manifestations already assigned by a publisher remain 1103 unchanged even if the identified object is no longer accessible. In 1104 this case, in order to make its materials accessible, the publisher 1105 will have to create for each of them a new manifestation with the 1106 new domain name; 1107 - possible components of the expressions contained in the 1108 manifestation. Such components are expressed by language-dependent 1109 labels representing the whole document (in English "all") or the 1110 main part of the document (in English "body") or the caption label 1111 of the component itself (e.g. Table 1, Figure 2, etc.); 1112 - other features of the document (e.g., anonymized decision text). 1114 The suffix will thus read: 1116 manifestation = format ":" editor 1117 [(":" component [":" feature]) / 1118 (":" "all" ":" feature)] 1120 Note that the value "all" can be expressed by language-dependent 1121 equivalents. To indicate possible features or peculiarities, each 1122 main element of the manifestation MAY be followed by further 1123 specifications, for example as regards the version, for 1124 the archive name and the electronic publisher, etc. 1126 (examples (hypothetical): 1127 the original version the Italian act 3 April 2000, n. 56 might have 1128 the following manifestations with their relative uniform names: 1129 - PDF format (vers. 1.7) of the whole act edited by the Italian 1130 Parliament: 1131 "urn:lex:it:stato:legge:2000-04-03;56$application- 1132 pdf;1.7:parlamento.it" 1133 - XML format (version 2.2 DTD NIR) of the text of the act and PDF 1134 format (version 1.7) of the "Figura 1" (figure 1) contained in the 1135 body, edited by the Italian Senate: 1136 "urn:lex:it:stato:legge:2000-04-03;56$text-xml;dtd-nir- 1137 2.2:senato.it:testo" 1138 "urn:lex:it:stato:legge:2000-04-03;56$application- 1139 pdf;1.7:senato.it:figura.1" 1141 the Spanish URN of the html format of the whole Judgement of the 1142 European Court of Justice n. 33/08 of 11/06/2009, in Spanish version, 1143 published in the Jurifast data base in anonymized form: 1144 "urn:lex:eu:tribunal.justicia:sentencia:2009-06-11;33- 1145 08@original:es$text-html:juradmin.eu;jurifast:todo:anonimo") 1147 Furthermore, it is useful to be able to assign a uniform name to a 1148 manifestation (or to a part of it) in case non-textual objects are 1149 involved. These may be multimedia objects that are non-textual in 1150 their own right (e.g. geographic maps, photographs, etc.), or texts 1151 recorded in non-textual formats, such as image scans of documents. 1153 In these ways, a LEX name permits: 1154 - exploitation of all the advantages of an unequivocal identifier 1155 that is independent of physical location; 1156 - a means to provide choice among different existing manifestations 1157 (e.g. XML or PDF formats, resolution degree of an image etc.) of 1158 the same expression. 1160 6.8 Sources of Law References 1162 References to sources of law often refer to specific partitions of 1163 the act (article, paragraph, etc.) and not to the entire document. 1165 From a legal point of view, a partition is always a more or less wide 1166 text block, that represents a logical subdivision of an act. 1167 As regards the digital representation, in a structured format (as 1168 XML) perfectly fitting the document logical structure, a partition is 1169 represented by an element (a block of text) with its own ID; this ID 1170 aims to identify the related element and to locate it. In this case, 1171 therefore, it is possible either extracting or pointing to a 1172 partition. 1173 In a mark-up not fitting the logical structure of the text (as HTML), 1174 generally only the starting point of the partition, rather than the 1175 whole block of text or element, is identified through a label (a tag). In this case therefore it is not possible to extract a 1177 partition but only to point to it. 1178 In both cases, having a partition identifier is useful; therefore, 1179 for allowing browsers to point to a specific partition, it is 1180 necessary that such partition is endowed with an unequivocal label or 1181 ID within the including document and its value is the same 1182 independently from the document format. 1184 For enabling the construction of the partition identifier between 1185 different collections of documents, specific construction rules for 1186 IDs or labels SHOULD be defined and shared, within each country or 1187 jurisdiction, for any document type (e.g., for legislation, the 1188 paragraph 2 of the article 3 might have as label or ID the value 1189 "art3;par2", similarly for case-law, paragraph 22 of the judgement in 1190 Case 46/76 Bauhuis v Netherlands, might have as label or ID the value 1191 "par22"). 1192 Furthermore, it is useful to foresee the compatibility with 1193 applications able to manage this information (e.g., returning the 1194 proper element); these procedures are particularly useful in the case 1195 of rather long acts, such as codes, constitutions, regulations, etc. 1196 For this purpose it is necessary that the partition identifier is 1197 transmitted to the servers (resolution and application) and therefore 1198 it cannot be separated by the typical "#" character of URI fragment, 1199 which is not transmitted to the server. 1201 According to these requirements, the syntax of a reference is: 1203 URN-reference = URN-document ["~" partition-id] 1205 (e.g., to refer to the paragraph 3 of the article 15 of the French 1206 Act of 15 may 2004, n. 106, the reference is written 1207 "urn:lex:fr:etat:loi:2004-05-15;106~art15;par3"). 1209 Using a different separator ("~") from the document name, the 1210 partition ID is not withheld by the browser but it is transmitted to 1211 the resolution process. This enables the resolver to retrieve (for 1212 example, out of a database), if it is possible, only the referred 1213 partition, otherwise to return the whole act. 1214 Anyway, to make it effective in a browser pointing to the indicated 1215 partition, the resolver SHOULD transform the partition ID of each 1216 returned URL in a URI fragment; this is obtained appending to the URL 1217 the "#" character followed by the partition ID (in the example above, 1218 the returned URL will be #art15;par3). Doing this, 1219 knowing the granularity of the act markup, the resolver could exploit 1220 the hierarchical structure of the ID, eliminating sub-partitions not 1221 addressed. If only the article was identified in the act, in the 1222 previous example it could return #art15 only. 1224 Anyway it is possible to use the general syntax (with "#"); in this 1225 case only the URN document component of the reference is transmitted 1226 to the resolver, therefore the whole document will be always 1227 retrieved. 1229 7 The Procedure of Uniform Names Assignment 1231 7.1 Specifying the Element of the LEX Identifier 1233 Under the "lex" namespace, each country or international organization 1234 is assigned with a jurisdiction code, which characterizes the URNs of 1235 the source of law of that country or jurisdiction. This code is 1236 assigned according to ccTLD (as well as TLDN or DN for the 1237 organizations) representation and it is the value of the 1238 element, which preserves cross-country uniqueness 1239 of the identifiers. 1241 7.2 Jurisdictional Registrar for Names Assignment 1243 Any country or jurisdiction, who intends to adopt this schema, 1244 identifies a Jurisdictional Registrar, an organization which shares 1245 and defines the structure of the optional part () 1246 of the name, according to the organization of the state or 1247 institution. For example, in a federal state a 1248 corresponding to the name of each member state (e.g. "br;sao.paolo", 1249 "br;minas.gerais", etc.) may be defined. 1251 The process of assigning the will be managed by each 1252 specific country or jurisdiction under the related 1253 element. 1255 In any country the Jurisdictional Registrar shares and defines the 1256 assignment of the primary elements (issuing authority and type of 1257 legal measure) of the local names considering the characteristics of 1258 its own state or institution organization. 1259 Such a Registrar MUST establish, according to the guidelines 1260 indicated in the current document, a uniform procedure within the 1261 country or organization to define elements, to take 1262 decisions upon normalizations and finally to solve and avoid possible 1263 name collisions as well as to maintain authoritative registries of 1264 various kinds (e.g., for authorities, types of measures, etc.). In 1265 particular, accurate point-in-time representations of the structure 1266 and naming of government entities are important to semantically-aware 1267 applications in this domain. 1268 Moreover, the Registrar shares and defines the rules to construct 1269 partition IDs for each document type. 1270 Finally, the Registrar will develop and publish the rules and the 1271 guidelines for the construction as well as the 1272 predefined values and codes. The Registrar should also promote the 1273 urn:lex identifier for the sources of law of its jurisdiction. 1275 Such a set of rules will have to be followed by all institutional 1276 bodies adherent to the project as well as by private publishers and 1277 each of them will be responsible for assigning names to their 1278 domains. 1280 7.3 Identifier Uniqueness 1282 Identifiers in the "lex" namespace are defined through a 1283 element assigned to the sources of law of a specific 1284 country or organization, and a assigned by the issuing 1285 authority. The main elements (authority and type of measure) of the 1286 are defined by the Jurisdictional Registrar, so that it 1287 is ensured that the constructed URNs are unique. The Jurisdictional 1288 Registrar SHOULD provide clear documentation of rules by which names 1289 are to be constructed, and SHOULD update and make accessible its 1290 registries. 1292 Any issuing authority is responsible to define formal parameters to 1293 guarantee local name uniqueness by attributing, if necessary, a 1294 conventional internal number, which, combined with the other components (authority, measure and date), builds an unequivocal 1296 identifier. Uniqueness is achieved by checking against the catalogue 1297 of previously assigned names. 1299 7.4 Identifier Persistence Considerations 1301 The persistence of identifiers depends on the durability of the 1302 institutions that assign and administer them. The goal of the LEX 1303 schema is to maintain uniqueness and persistence of all resources 1304 identified by the assigned URNs. 1306 In particular, ITTIG-CNR, as proposer, is responsible of maintaining 1307 the uniqueness of the element; given that the 1308 is assigned on the basis of the long-held ccTLD 1309 representation of the country (or the TLDN or DN of the organization) 1310 and that the country or organization associated code is expected to 1311 continue indefinitely, the URN also persists indefinitely. 1313 The rules for the construction of the name are conceived to delegate 1314 the responsibility of their uniqueness to a set of authorities which 1315 is identified within each country or organization. 1317 Therefore, each authority is responsible for assigning URNs which 1318 have a very long life expectancy and can be expected to remain unique 1319 for the foreseeable future. Practical and political considerations, 1320 as well as diverse local forms of government organization, will 1321 result in different methods of assigning responsibility for different 1322 levels of the name. 1323 Where this cannot be accomplished by the implementation of an 1324 authoritative hierarchy, it can and SHOULD be done by creating 1325 consensus around a series of published rules for the creation and 1326 administration of names by institutions and bodies that operate by 1327 means of collaboration rather than compulsion. 1329 Issuing authorities that operate in more localized scopes, ranging 1330 from the national down to the very local, MUST equally take 1331 responsibility for the persistence of identifiers within their 1332 scope. 1334 8 Principles of the Resolution Service 1336 8.1 The General Architecture of the System 1338 The task of the resolution service is that of associating a LEX 1339 identifier with a specific document address on the network. By 1340 contrast with systems that can be constructed around rigorous and 1341 enforceable engineering premises, such as DNS, the "lex" namespace 1342 resolver will be expected to cope with a wide variety of "dirty" 1343 inputs, particularly those created by the automated extraction of 1344 references from incomplete or inaccurate texts. In this document, 1345 the result is a particular emphasis on a flexible and robust resolver 1346 design. 1348 The system has a distributed architecture based on two fundamental 1349 components: a chain of information in DNS (Domain Name System) and a 1350 series of resolution services from URNs to URLs, each competent 1351 within a specific domain of the namespace. 1352 Through the NAPTR records of the DNS (described in [RFC3403]), the 1353 client identifies the characteristics (protocol, port, site) of the 1354 service (e.g. according to [RFC2169]) capable of associating the 1355 relative URLs with the URN in question, thereby allowing access to 1356 the document. 1358 A resolution service can delegate the resolution and management of 1359 hierarchically-dependent portions of the name. 1360 Delegation of this responsibility will not be unreasonably withheld 1361 provided that the processes for their resolution and management are 1362 robust and are followed. 1364 For the "lex" namespace, ITTIG-CNR will maintain the root zone 1365 "lex.urn.arpa" (see [RFC3405]) and, in correspondence with the 1366 adhesion of a new country (e.g., "br") or organization, will update 1367 the DNS information with a new record to delegate the relative 1368 resolution. This may be obtained by a regular expression that matches 1369 the initial part of the URN (e.g., "urn:lex:br") and redirects 1370 towards the proper zone (e.g., "lex.senado.gov.br"). 1372 Likewise the institution responsible for the jurisdiction uniform 1373 names (e.g., "urn:lex:br") has the task of managing the relative root 1374 in the DNS system (e.g., "lex.senado.gov.br" zone) and routing the 1375 resolution towards its resolvers on the basis of parts of the uniform 1376 names. In similar way it can delegate the resolution of 1377 country/organization sub-levels (e.g., "urn:lex:br;sao.paolo") 1378 towards the relative zone (e.g., "lex.sao-paolo.gov.br"). 1380 Such DNS routing chain does not work for all the URN components 1381 containing %-encoded characters. Therefore in these cases a proper 1382 software implementing punycode conversion or routing service has to 1383 be developed. 1385 The resolution service is made up of two elements: a knowledge base 1386 (consisting in a catalogue or a set of transformation rules) and a 1387 software to query the knowledge base itself. 1389 8.2 Catalogues for Resolution 1391 Incompleteness and inaccuracy are rather frequent in legal citations, 1392 and incomplete or inaccurate uniform names of the referred document 1393 are thus likely to be built from textual references (this is even 1394 more frequent if they are created automatically through a specific 1395 parser). For this reason, the implementation of a catalogue, based on 1396 a relational-database, is suggested, as it will lead to a higher 1397 flexibility in the resolution process. 1398 In addition the catalogue must manage the aliases, the various 1399 versions and languages of the same source of law as well as the 1400 related manifestations. 1402 It is suggested that each enacting authority implements its own 1403 catalogue, assigning a corresponding unambiguous uniform name to each 1404 resource. 1406 8.3 Suggested Resolver Behaviour 1408 First of all the resolver should separate the part corresponding to 1409 the partition ID, through the "~" separator, from the document name. 1411 So, the resolution process SHOULD implement a normalization of the 1412 uniform name to be resolved. This may involve transforming some 1413 components to the canonical form (e.g., filling out the acronyms, 1414 expanding the abbreviations, unifying the institution names, 1415 standardizing the type of measures, etc.). For this function 1416 authorities and types of measure registers are useful. 1418 The resolver SHOULD then query the catalogue searching for the URN 1419 which corresponds exactly to the given one (normalized if necessary). 1420 Since the names coming from the references may be inaccurate or 1421 incomplete, an iterative, heuristic approach (based on partial 1422 matches) is indicated. It is worth remarking that incomplete 1423 references (not including all the elements to create the canonical 1424 uniform name) are normal and natural; for a human reader, the 1425 reference would be "completed" by contextual understanding of the 1426 reference in the document in which it occurs. 1428 In this phase, the resolver should use the partition ID information 1429 to retrieve, if it is possible, only the referred partition, 1430 otherwise to return of the entire document. 1432 Lacking more specific indications, the resolver SHOULD select the 1433 best (most recent) version of the requested source of law, and 1434 provide all the manifestations with their related items. 1435 A more specific indication in the uniform name to be resolved will, 1436 of course, result in a more selective retrieval, based on any 1437 suggested expression and/or manifestations components (e.g. date, 1438 language, format, etc.). 1440 Finally, the resolver SHOULD append to URLs the "#" character 1441 followed by partition ID, transforming it in a URI fragment for 1442 browser pointing. 1444 9 Namespace Considerations 1446 In collaboration with the legislative XML community, registrants 1447 carried out a preliminary study of the URI alternatives to satisfy 1448 the key requirements. 1449 The options analysed were: a private URI scheme, URL, PURL and URN. 1450 URN was considered the most appropriate URI given the requirements 1451 analysis. 1452 Advantages we would emphasize are: 1453 - greater flexibility in building the identifier; 1454 - the capacity to represent name components that are not strictly 1455 hierarchical; 1456 - the potential for clear division of the identifier into macro 1457 parts, main elements and components, using different separators; 1458 - ease of managing optional parts of a name. 1460 10 Community Considerations 1462 The use of the "lex" namespace facilitates the interoperability of 1463 information systems used in the Public Administration at the national 1464 and international level. Moreover it allows the distribution of the 1465 legal information towards a federated architecture. In such an 1466 architecture, documents are directly managed by the issuing 1467 authorities, with resulting benefits in information authenticity, 1468 quality and currency. A shared identification mechanism resources 1469 guarantees that a distributed system will be as efficient and 1470 effective as a comparable centralized system. 1472 Creators of Internet content that references legal materials - 1473 including publishers operating well outside the traditional arenas of 1474 legal publishing - benefit by the registration of the namespace 1475 because facilitates the linking of legal documents, whether by manual 1476 or automated means, and reduces the cost of maintaining documents 1477 that contain such references. 1479 Any citizen or organisation with Internet web browser capability will 1480 be entitled to access the namespace and its associated application, 1481 registers, and resolution services, to facilitate document access. 1483 It is envisaged to promote the urn:lex identification system for 1484 sources of law through all the various dissemination channels such as 1485 conferences, a project dedicated website, references from other 1486 projects, etc. 1488 11 IANA Considerations 1490 11.1 NID Registration 1492 This document includes a URN NID registration for "lex" for entry in 1493 the IANA registry of URN NIDs (see [RFC8141]), as well as the 1494 registration of the following NAPTRs record: 1496 in the URN.ARPA domain: 1497 lex IN NAPTR 100 10 "" "" "" . 1499 in the URN.URI.ARPA domain: 1500 lex IN NAPTR 100 10 "" "" "" . 1502 where indicates the server of the organization 1503 that is responsible for the "lex" area under urn.arpa and 1504 urn.uri.arpa, and will be specified at implementation time. 1506 11.2 Jurisdiction-code Registration 1508 It is requested to create a new registry for , 1509 with the following format: 1510 - : the identifier code of jurisdiction, assigned 1511 to the country or organisation; 1512 - : the official denomination of the jurisdiction, 1513 country or organisation; 1514 - : all information about the organization that requested 1515 the registration of the code. Such organization will be responsible 1516 for its DNS zone and for the attribution of sub-zone delegations, 1517 and so on. It is desirable that each jurisdiction creates a 1518 register of all delegated levels so that the organization 1519 responsible of each sub-zone can easily be identified; 1520 - : a reference to the defining document (if any). 1522 The table is initially empty. Possible example entries are: 1523 "br"; "Brazil"; "Prodasen, Federal Senate,
, "; 1524 [reference] 1525 "eu"; "European Union"; "DG Digit, European Commission,
, 1526 "; [reference] 1527 "un.org"; "United Nations"; "DPI, United Nations,
, 1528 "; [reference] 1530 In the current experimental LEX registration phase, ITTIG-CNR will 1531 take care to create and maintain the registry for . As the criteria of the LEX names assignment will be 1533 consolidated, after the experimental phase such registry will be 1534 maintained by IANA. 1535 The adopted registration policy is compliant with the "Expert Review" 1536 as specified in [RFC8126]. Designated Expert(s) will assign 1537 jurisdiction codes based on the following principles: 1538 - if a request comes from a jurisdiction that corresponds to a 1539 country and the jurisdiction code is the same as a top level ccTLD, 1540 which is not yet registered, then the top level ccTLD should be 1541 used as the jurisdiction code; 1542 - if a request comes from a jurisdiction that corresponds to a multi- 1543 national (e.g., European Union) or international (e.g., United 1544 Nations, Free Software Foundation) organizations the Top Level 1545 Domain Name (e.g., "eu") or the Domain Name (e.g., "un.org", 1546 "wto.int") of the organization should be used as the jurisdiction 1547 code; 1548 - in case when such multi-national or international organization does 1549 not have a registered domain, Designated Expert(s) should assign 1550 something like .lex.arpa, where is the English acronym 1551 of the organization name. For example, the jurisdiction code of the 1552 European Economic Community is "eec.lex.arpa". 1554 Jurisdiction codes can't be renamed, because allowing for renames 1555 would violate rules that URN assignments are persistent. 1557 Jurisdiction codes can never be deleted. They can only be marked as 1558 "obsolete", i.e. closed for new assignments within the jurisdiction. 1559 Requests to obsolete a jurisdiction code are also processed by 1560 Designated Expert. 1562 Designated Expert(s) can unilaterally initiate allocation or 1563 obsolescence of a jurisdiction code. 1565 Request for new jurisdiction code assignment must include 1566 Organization or Country requesting it and Contact information (email) 1567 of who requested the assignment. 1569 12 References 1571 12.1 Normative References 1573 [BCP47] A. Phillips, M. Davis, "Tags for Identifying Languages", 1574 BCP 47, RFC 5646, September 2009 1576 [STD63] F. Yergeau, "UTF-8, a transformation format of ISO 1577 10646", STD 63, RFC 3629, November 2003. 1579 [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail 1580 Extensions (MIME) Part One: Format of Internet Message 1581 Bodies", RFC 2045, November 1996. 1583 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1584 Requirement Levels", BCP 14, RFC 2119, March 1997. 1586 [RFC2169] R. Daniel, "A Trivial Convention for using HTTP in URN", 1587 RFC 2169, June 1997 1589 [RFC3403] M. Mealling, Dynamic Delegation Discovery System (DDDS), 1590 Part Three: The Domain Name System (DNS) Database, RFC 1591 3403, October 2002. 1593 [RFC3405] M. Mealling, Dynamic Delegation Discovery System (DDDS), 1594 Part Five: URI.ARPA Assignment Procedures, RFC 3405, 1595 October 2002. 1597 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1598 Resource Identifiers (URI): Generic Syntax", STD 66, RFC 1599 3986, January 2005. 1601 [RFC5234] D. Crocker Ed., P. Overell, "Augmented BNF for Syntax 1602 Specifications: ABNF", STD 68, RFC 5234, January 2008 1604 [RFC5894] J. Klensin, "Internationalized Domain Names for 1605 Applications (IDNA): Background, Explanation, and 1606 Rationale", RFC 5894, August 2010 1608 [RFC8126] M. Cotton, B. Leiba, T. Narten, "Guidelines for Writing 1609 an IANA Considerations Section in RFCs", RFC 8126, June 1610 2017 1612 [RFC8141] P. Saint-Andre, J.C. Klensin, "Uniform Resource Names 1613 (URNs)", RFC 8141, April 2017 1615 [RFC8288] M. Nottingham, "Web Linking", RFC 8288, October 2017 1617 [ISO8601] ISO 8601, "Data elements and interchange formats", ISO 1618 8601:2004 1620 12.2 Informative References 1622 [FRAN] E. Francesconi, "Technologies for European Integration. 1623 Standards-based Interoperability of Legal Information 1624 Systems", ISBN 978-88-8398-050-3, European Press Academic 1625 Publishing, 2007. 1627 [SPIN] P.L. Spinosa, "The Assignment of Uniform Names to Italian 1628 Legal Documents", URN-NIR 1.4, June, 2010, ITTIG 1629 Technical Report n. 8/2010. 1631 13 Acknowledgements 1633 The authors of this document wish to thank all the supporters for 1634 giving suggestions and comments. 1635 They are also grateful to the Legislative XML community for the 1636 interesting discussions on this topic and to the Working Group 1637 "Identification of the legal resources through URNs" of Italian 1638 NormeInRete project for the provided guidance [SPIN]. 1639 The authors owe a debt of gratitude to Tom Bruce, director of the 1640 Legal Information Institute of the Cornell University Law School, for 1641 his contribution in revising this document and sharing fruitful 1642 discussions which greatly improved the final draft. The authors wish 1643 to specially thank Marc van Opijnen (Dutch Ministry of Security and 1644 Justice) for his valuable comments on LEX specifications which 1645 contributed to improve the final result, as well as for the common 1646 work aimed to harmonize ECLI and LEX standards. Thanks also to Joao 1647 Alberto de Oliveira Lima, legislative system analyst of the Brazilian 1648 Federal Senate, and to Attila Torcsvari, information management 1649 consultant, for their detailed comments on the first drafts of this 1650 document, which provided significant hints to the final version of 1651 the standard, and to Robert Richards of the Legal Information 1652 Institute (Cornell University Law School), promoter and maintainer of 1653 the Legal Informatics Research social network, as well as to the 1654 members of this network, for their valuable comments on this 1655 proposal. 1656 Finally, many thanks go to Loriana Serrotti who significantly 1657 contributed to the first drafting of this document. 1659 14 Author's Addresses 1661 PierLuigi Spinosa 1662 (ICT consultant) 1663 Via Zanardelli, 15 1664 50136 Firenze 1665 Italy 1666 Telephone: +39 339 5614056 1667 e-mail: pierluigi.spinosa@gmail.com 1669 Enrico Francesconi 1670 Istituto di Teoria e Tecniche dell'Informazione Giuridica (ITTIG) 1671 Consiglio Nazionale delle Ricerche (CNR) 1672 Via de' Barucci, 20 1673 50127 Firenze 1674 Italy 1675 Telephone: +39 055 43995 1676 e-mail: enrico.francesconi@ittig.cnr.it 1678 Caterina Lupo 1679 (ICT consultant) 1680 Via San Fabiano, 25 1681 00165 Roma 1682 Italy 1683 Telephone: +39 3382632348 1684 e-mail: caterina.lupo@gmail.com 1686 Attachment A -- Summary of the Syntax of the Uniform Names of the "lex" 1687 Namespace 1689 ;------------------------------------------------------------------- 1690 ; Structure of a Uniform Resource Name (URN) of the "lex" namespace 1691 ; NID-lex = namespace 1692 ; NSS-lex = specific name 1693 ;------------------------------------------------------------------- 1694 URN-lex = "urn:" NID-lex ":" NSS-lex 1696 NID-lex = "lex" 1698 ;------------------------------------------------------------------- 1699 ; Structure of a "lex" specific name 1700 ;------------------------------------------------------------------- 1701 NSS-lex = jurisdiction ":" local-name 1703 ;------------------------------------------------------------------- 1704 ; Structure of the element 1705 ;------------------------------------------------------------------- 1706 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 1708 jurisdiction-code = 2*alf-dot 1710 jurisdiction-unit = alf-dot 1712 ;------------------------------------------------------------------- 1713 ; Structure of the element 1714 ;------------------------------------------------------------------- 1715 local-name = work ["@" expression] ["$" manifestation] 1717 ;------------------------------------------------------------------- 1718 ; Structure of the element 1719 ;------------------------------------------------------------------- 1720 work = authority ":" measure ":" details *(":" annex) 1722 ;------------------------------------------------------------------- 1723 ; Structure of the element 1724 ;------------------------------------------------------------------- 1725 authority = issuer *("+" issuer) 1727 issuer = (institution *(";" body-function)) / office 1729 institution = alf-dot 1731 body-function = alf-dot 1732 office = alf-dot 1734 ;------------------------------------------------------------------- 1735 ; Structure of the element 1736 ;------------------------------------------------------------------- 1737 measure = measure-type *(";" specification) 1739 measure-type = alf-dot 1741 specification = alf-dot 1743 ;------------------------------------------------------------------- 1744 ; Structure of the
element 1745 ;------------------------------------------------------------------- 1746 details = (dates / period) ";" numbers 1748 dates = date *("," date) 1750 period = alf-dot 1752 numbers = (document-id *("," document-id)) / number-lex 1754 document-id = alf-dot-oth 1756 number-lex = "lex-" 1*DIGIT 1758 ;------------------------------------------------------------------- 1759 ; Structure of the element 1760 ;------------------------------------------------------------------- 1761 annex = annex-id *(";" specification) 1763 annex-id = alf-dot 1765 ;------------------------------------------------------------------- 1766 ; Structure of the element 1767 ;------------------------------------------------------------------- 1768 expression = version [":" language] 1770 ;------------------------------------------------------------------- 1771 ; Structure of the element 1772 ;------------------------------------------------------------------- 1773 version = (amendment-date / specification) 1774 *(";" (event-date / event)) 1776 amendment-date = date 1778 event-date = date 1779 event = alf-dot 1781 ;------------------------------------------------------------------- 1782 ; Structure of the element 1783 ;------------------------------------------------------------------- 1784 language = 2*3alfa 1786 ;------------------------------------------------------------------- 1787 ; Structure of the element 1788 ;------------------------------------------------------------------- 1789 manifestation = format *(";" specification) 1790 ":" editor *(";" specification) 1791 [(":" component [":" feature]) / 1792 (":" "all" ":" feature)] 1794 component = part *(";" specification) 1796 feature = attribute *(";" specification) 1798 format = alf-dot-hyp 1800 editor = alf-dot-hyp 1802 part = alf-dot-hyp 1804 attribute = alf-dot-hyp 1806 ;------------------------------------------------------------------- 1807 ; Structure of the date 1808 ;------------------------------------------------------------------- 1809 date = year "-" month "-" day 1811 year = 4DIGIT 1812 month = 2DIGIT 1813 day = 2DIGIT 1815 ;------------------------------------------------------------------- 1816 ; Allowed, reserved and future characters 1817 ;------------------------------------------------------------------- 1818 ; allowed = alfadot / other / reserved 1819 ; reserved = ":" / "@" / "$" / "+" / ";" / "," / "~" 1820 ; future = "*" / "!" 1822 alf-dot = alfanum *alfadot 1824 alf-dot-hyp = alfanum *(alfadot / "-") 1826 alf-dot-oth = alfanum *(alfadot / other) 1827 alfadot = alfanum / "." 1829 alfa = lowercase / uppercase 1831 alfanum = alfa / DIGIT / encoded 1833 lowercase = %x61-7A ; lower-case ASCII letters (a-z) 1835 uppercase = %x41-5A ; upper-case ASCII letters (A-Z) 1837 DIGIT = %x30-39 ; decimal digits (0-9) 1839 encoded = "%" 2HEXDIG 1841 HEXDIG = DIGIT / %x41-46 / %x61-66 ; hex digits (0-9,A-F,a-f) 1843 other = "-" / "_" / "'" / "=" / "(" / ")" 1844 Attachment B -- Specific Syntax of the Identifier at Work Level 1846 B1 The Element 1848 B1.1 Indication of the Authority 1850 The element of a uniform name may indicate, in the 1851 various cases: 1852 - the actual authority issuing the legal provision. More 1853 specifically, the authority adopting the provision or enacting it; 1854 - the institution where the provision is registered, known and 1855 referenced to, even if produced by others (e.g., the bills 1856 identified through the reference to the Chamber where they are 1857 presented); 1858 - the institution regulated (and referred to in citations) by the 1859 legal provision even when this is issued by another authority 1860 (e.g., the statute of a Body); 1861 - the entity that proposed the legal material not yet included in the 1862 institutional process (e.g. a proposed bill written by a a 1863 political party). 1865 B1.2 Multiple Issuers 1867 Some sources of law are enacted by a number of issuing parties (e.g., 1868 inter-ministerial decrees, agreements, etc.). In this case, the 1869 element contains all the issuing parties (properly 1870 separated), as follows: 1872 authority = issuer *("+" issuer) 1874 (e.g., "ministry.justice+ministry.finances") 1876 B1.3 Indication of the Issuer 1878 Each issuing authority is essentially represented by either an 1879 institutional office (e.g., Prime Minister) or an institution (e.g., 1880 Ministry); in the last case, the authority is indicated in accordance 1881 with the institution's hierarchical structure, from the more general 1882 to more specific (Council, Department, etc.), ending with the 1883 relative office (President, Director, etc.). 1884 Therefore, the structure of the issuer is as follows: 1886 issuer = (institution *(";" body-function)) / office 1888 (e.g., "ministry.finances;department.revenues;manager") 1890 B1.4 Indication of the Body 1891 Depending on the kind of measure, the body within the issuing 1892 authority is unambiguously determined (e.g., the Council for Regional 1893 Acts) and normally it is not indicated in the references. 1894 Just like in practice, the indication of the enacting authority is 1895 limited to the minimum in relation to the type of measure. 1896 (e.g., "region.tuscany:act" and not "region.tuscany;council:act") 1898 B1.5 Indication of the Function 1900 Generally, the function is indicated, sometimes instead of the body 1901 itself: 1902 - in case of political, representative or elective offices 1903 (e.g., "university.oxford;rector:decree" instead of 1904 "university.oxford;rectorship:decree"); 1905 - when it refers to a top officer in the institution (e.g., general 1906 manager, general secretary, etc.) which is not always possible to 1907 associate a specific internal institutional structure to 1908 (e.g., "national.council.research;general.manager"). 1910 It is not indicated when it clearly corresponds to the person in 1911 charge of an institution (typically, a general director); in this 1912 case, only the structure and not the person in charge is indicated 1913 (e.g., "ministry.justice;department.penitentiary.administration"). 1915 The function MUST be indicated when: 1916 - it is not the same of the director or the person in charge of the 1917 structure (for example, in case of an undersecretary, a deputy 1918 director, etc.); 1919 - the type of measure may be both monocratic or collegial: the 1920 indication of the office eliminates the ambiguity. 1922 B1.6 Conventions for the Authority 1924 Acts and measures bearing the same relevance as an act, issued or 1925 enacted since the foundation of the State, have conventionally 1926 indicated "state" (expressed in each country official language) as 1927 authority; the same convention is used for constitutions, codes 1928 (civil, criminal, civil procedure, criminal procedure, etc) and 1929 international treaties. 1931 B2 The Element 1933 B2.1 Criteria for the Indication of the Type of Measure 1935 In uniform names the issuing authority of a document is mandatory. 1936 This makes unnecessary to indicate any further qualification of the 1937 measure (e.g., ministerial decree, directorial ordinance, etc.), even 1938 if it is widely used. 1940 When the authority-measure combination clearly identifies a specific 1941 document, the type of measure is not defined through attributes 1942 referring to the enacting authority. 1943 (e.g., "region.tuscany:act" and not "region.tuscany:regional.act") 1945 B2.2 Further Specification to the Type of Measure 1947 In the element, it is usually sufficient to indicate the 1948 type of a measure. As usual, references to sources of law, rather 1949 than through the formal details (date and number), may be made 1950 through some of their characteristics such as the subject-matter 1951 covered (e.g., accounting regulations), nicknames referring to the 1952 promoter (e.g., Bassanini Act) or to the topic of the act (e.g., 1953 Bankruptcy Law), etc.. 1954 In these cases, the type of measure MAY be followed by further 1955 specifications useful in referencing even if the details are lacking: 1957 measure = measure-type *(";" specification) 1959 (e.g., "regulations;accounting" or "act;bankruptcy") 1961 B2.3 Aliases for Sources of Law with Different Normative References 1963 There are legislative measures that, although unique, are usually 1964 cited in different ways, for example through the legislative act 1965 introducing them into the legal order (President's decree, 1966 legislative decree, etc.) or through their legislative category 1967 (regulations, consolidation, etc.). 1968 In order to ensure, in all the cases, the validity of the references, 1969 an alias that takes into account the measure category is associated 1970 to the uniform name, representing the legislative form. 1971 (e.g., "state:decree.legislative:1992-07-24;358" and 1972 "state:consolidation;public.contracts:1992-07-24;358"). 1974 B2.4 Relations between Measure and Authority in the Aliases 1976 The sources of law including different normative references are 1977 usually introduced in legislation through the adoption or the issuing 1978 of an act, which they are either included or attached to. It is, 1979 therefore, necessary to create an alias linking the two aspects of 1980 the same document. Specifically, the different measures can be: 1981 - adopted/issued by an authority different from the one regulated by 1982 the provision (e.g., the statute of a Body); in this case, the 1983 correlation is established between two uniform names each featuring 1984 a completely different element 1985 (e.g., "italian.society.authors.publishers:statute" and 1986 "ministry.cultural.activities+ministry.finances.budget.economic. 1987 planning:decree"); 1989 - issued by the institution itself either because it has issuing 1990 authority or by virtue of a proxy (e.g., a provision that refers to 1991 the functioning of the Body itself); in this case, the two aliases 1992 share the first part of the authority; 1993 (e.g., "municipality.firenze:statute" and 1994 "municipality.firenze;council:deliberation"); 1995 - issued by the same Body to regulate a particular sector of its own 1996 competence; in this case the element is the same 1997 (e.g., "ministry.justice:regulation;use.information.tools. 1998 telematic.process" and "ministry.justice:decree"). 2000 B3 The
Element 2002 B3.1 Indication of the Details 2004 The details of a source of law usually include the date of the 2005 enactment and the identification number (inclusion in the body of 2006 laws, register, protocol, etc.). 2007 Some measures can have multiple dates; there are also cases in which 2008 the number of the measure does not exist (unnumbered measures) or a 2009 measure has multiple numbers (e.g., unified cases). For these 2010 reasons, the set up of both elements (date and number) includes 2011 multiple values. 2013 Some institutions (e.g., the Parliaments) usually identify documents 2014 through their period of reference (e.g., the legislature number) 2015 rather than through a date, which would be much less meaningful and 2016 never used in references (e.g., Senate bill S.2544 of the XIV 2017 legislature). In these cases, the component is used in 2018 substitution of the component . 2020 Usually details of a measure are not reported according to a specific 2021 sequence; in accordance with the global structure of the uniform 2022 name, which goes from the general to the specific, the sequence date- 2023 number has the following form: 2025 details = (dates / period) ";" numbers 2027 (e.g., "2000-12-06;126", "14.legislature;s.2544") 2029 B3.2 Multiple Dates 2031 Some sources of law, even if unique, are identified by more than one 2032 date; in this case, in the field all the given dates are to 2033 be reported and indicated as follows: 2035 dates = date *("," date) 2037 (e.g., the measure of the Data Protection Authority of December 30, 2038 1999- January 13, 2000, No. 1/P/2000 has the following uniform name: 2039 "personal.data.protection.authority:measure:1999-12-30,2000-01-13; 2040 1-p-2000"). 2042 B3.3 Unnumbered Measures 2044 Measures not officially numbered in the publications may have a non- 2045 unequivolcal identifier, because several measures of the same type 2046 can exist, issued on the same day by the same authority. 2047 To ensure that the uniform name is unambiguous, the field 2048 MUST, in any case, contain a discriminating element, which can be any 2049 identifier used internally, and not published, by the authority 2050 (e.g., protocol). 2051 If the authority does not have its own identifier, one identifier 2052 MUST be created for the name system. In order to easily differentiate 2053 it, such number is preceded by the string "lex-": 2055 number-lex = "lex-" 1*DIGIT 2057 (e.g., "ministry.finances:decree:1999-12-20;lex-3") 2059 It is responsibility of the authority issuing a document to assign a 2060 discriminating specification to it; in case of multiple authorities, 2061 only one of them is responsible for the assignment of the number to 2062 the document (e.g., the proponent). 2063 The unnumbered measures published on an official publication (e.g., 2064 the Official Gazette), instead of by a progressive number are 2065 recognized by the univocal identifying label printed on the paper. 2066 Such an identifier, even if unofficial but assigned to a document in 2067 an official publication, is to be preferred because it has the clear 2068 advantage to be public and therefore easier to be found. 2070 B3.4 Multiple Numbers 2072 Some legal documents (e.g., bills), even if unique, are identified by 2073 a set of numbers (e.g., the unification of cases or bills). 2074 In this case, in the field, all the identifiers are 2075 reported, according to the following structure: 2077 numbers = document-id *("," document-id) 2079 (e.g., "2000-06-12;c-10-97,c-11-97,c-12-97") 2080 The characters which are not allowed (e.g., "/") or reserved (e.g., 2081 ":"), including the comma, cannot exist inside the , and 2082 therefore MUST be turned into "-". 2083 This conversion may imply that the uniform name of the document is no 2084 more unique (e.g., removal 123-BIS and return 123/BIS of the bill 123 2085 both are identified as "123-bis"); in this case, it is necessary to 2086 add a specific distinctive ending (e.g., "123-bis-removal" and "123- 2087 bis-return"). 2089 B4 The Element 2091 B4.1 Formal Annexes 2093 Although annexes are an integral part of the legal document, they may 2094 be referred to and undergo amendments separately from the act to 2095 which they are annexed. It is, therefore, necessary that both the 2096 main document as well as each formal individual annex is univocally 2097 identified. 2099 Formal annexes may be registered as separate parts or together with a 2100 legal provision; they may also be autonomous in nature or not. In any 2101 case, they MUST be given a uniform name, which includes the uniform 2102 name of the source of law to which they are attached, and a suffix 2103 which identifies the annex itself. 2105 The suffix of formal annexes includes the official heading of the 2106 annex and, possibly, further specifications (e.g., the title) which 2107 will facilitate the retrieval of the annex in case the identifier is 2108 missing: 2110 annex = annex-id *(";" specification) 2112 (e.g., "region.sicily;council:deliberation:1998-02-12;14:annex.a; 2113 borders.park") 2115 The characters which are not allowed (e.g. "/") or which are reserved 2116 (e.g. ":") must not be featured in the and therefore MUST 2117 be turned into ".". 2119 B4.2 Annexes of Annexes 2121 When there are annexes to an annex, their corresponding identifiers 2122 are created by adding to the identifier of the original annex those 2123 of the annexes that are connected with it (that is, attached to it). 2125 (e.g., Table 1 attached to Attachment A of the preceding legal act 2126 has the following uniform name: 2127 "region.sicily;council:deliberation:1998-02-12;14:annex.a; 2128 borders.park:table.1;municipality.territories"). 2130 Attachment C -- Specific Syntax of the Element of the 2131 Expression 2133 C1 The Element 2135 C1.1 Different Versions of a Legislative Document 2137 The creation of an updated text of a document may have one of the 2138 following forms: 2139 - "multi-version": when specific mark-ups which identify the modified 2140 parts of a document (added, substituted or deleted parts) and their 2141 related periods of effectiveness are indicated inside one single 2142 object (e.g., an xml file). Such a document will be able, in a 2143 dynamic way, to appear in different forms according to the 2144 requested date of effectiveness. 2145 In this document type, usually a set of metadata contains the 2146 lifecycle of the document (from the original to the last 2147 modification), including the validity time interval of each version 2148 and of each related text portion; 2149 - "single-version": when, on the contrary, a new and distinct object 2150 is created for each amendment to the text at a given time. Each 2151 object is, therefore, characterized by its own period of validity. 2152 In any case all the versions SHOULD be linked one another and 2153 immediately navigable. 2155 In a "multi-version" document each time interval should have a link 2156 to the related in-force document version obtained by displaying in a 2157 different way the very same document. 2158 In a "single-version" document, the metadata should contain links to 2159 the all the previous modifications and a link only to the following 2160 version, if any. 2162 [RFC8288] can be used as reference to establish links between 2163 different document versions, either in the "multi-version" or in the 2164 "single-version" document. According to [RFC8288] the following 2165 relations are useful: 2166 - current (or last or last-version): in-force version 2167 - self: this version 2168 - next: next version 2169 - previous: previous version 2170 - first: original version 2171 It is RECOMMENDED that these relations are inserted in the header of 2172 each version (if "single-version") or associated to each entry 2173 containing a single URN (if "multi-version"). 2175 C1.2 Identification of the Version 2176 In order to identify the different time versions of the same act, to 2177 the uniform name of the original document has to be added a specific 2178 suffix. 2179 Such a suffix identifies each version of a legal provision and 2180 includes, first and foremost, one of the following elements: 2181 - the issuing date of the last amending measure taken into account; 2182 - the date in which the communication of the rectification or of the 2183 errata corrige, is published; 2184 - a specification which must identify the reason concerning the 2185 amendment (e.g., the specific phase of the legislative process), 2186 for the cases in which the date is not usually used (e.g., bills). 2188 Anyway it is possible to add further specifications that will 2189 distinguish each of the different versions of the text to guarantee 2190 identifier unequivocalness. For example with regard to changes of the 2191 in-force or effectiveness of any partition or portion of the text 2192 itself (e.g., when the amendments introduced by an act are applied at 2193 different times) or different events occurring in the same date. 2195 version = (amendment-date / specification) 2196 *(";" (event-date / event)) 2198 where: 2199 - contains the issuing date of the last considered 2200 amendment or of the last communication of amendment. In case the 2201 original text introduces differentiated periods in which an act is 2202 effective and the information system produces one version for each 2203 of them, such element contains the string "original"; 2204 - any information useful to identify unambiguously 2205 and univocally the version; 2206 - contains the date in which a version is put into 2207 force, is effective or is published; 2208 - is a name assigned to the event producing a further version 2209 (e.g., amendment, decision, etc.). 2211 The issuing date of an amending act was chosen as identifier of a 2212 version because it can be obtained from the heading (formal data). 2214 (e.g., the name "state:royal.decree:1941-01-30;12@1998-02-19" 2215 identifies the updated text of the "Royal Decree of 30/1/1941, No. 2216 12" with the amendments introduced by the "Law Decree of 19/2/1998, 2217 No. 51", without any indication of its actual entry into force. The 2218 same uniform name with the additional ending ";1999-01-01" indicates 2219 the in-force or effective version starting in a different date (from 2220 1/1/99). 2222 For a full compatibility, every updating of a text or of the 2223 effectiveness of a "multi-version" document implies the creation of a 2224 new uniform name, even if the object remains only one, containing the 2225 identifier of the virtually generated version, exactly as in the case 2226 of a "single-version" document. A specific meta-data will associate 2227 every uniform name with the period of time during which such a name 2228 together with its corresponding text is to be considered valid. 2230 (e.g., the multi-version document containing the "R.D. of 01/30/1941, 2231 no. 12", updated by the amendments introduced by the "D.Lgs. of 2232 02/19/1998, no. 51", contains the name of the original 2233 "state:royal.decree:1941-01-30;12" as well as the name of the updated 2234 version "state:royal.decree:1941-01-30;12@1998-02-19"). 2236 Please note that in case of attachments or annexes, the creation of a 2237 new version (even in the case of only one component) would imply the 2238 creation of a new uniform name for all the connected objects in order 2239 to guarantee their alignment (i.e., the main document, the 2240 attachments and annexes). 2242 Attachment D -- Http LEX Identifier 2244 D1 Http URI 2246 Http URIs have been recently promoted as stable and location- 2247 independent identifiers [RFC3986]. According to this syntax, at all 2248 levels, resource IDs belong to the http scheme and are normally 2249 resolved using mechanisms widely available in browsers and web 2250 servers. 2252 Such kind of identifiers have been recently suggested also within the 2253 set of principles and technologies, known as "Linked Data" as a basic 2254 infrastructure of the semantic web to enable data sharing and reuse 2255 on a massive scale. 2257 Such principles, introduced by Tim Berners-Lee in his Web 2258 architecture note "Linked Data" 2259 (http://www.w3.org/DesignIssues/LinkedData.html), are synthetically: 2261 - Use URIs as names for things; 2262 - Use HTTP URIs, so that people can look up those names; 2263 - When someone looks up a URI, provide useful information, using the 2264 standards (RDF, SPARQL); 2265 - Include links to other URIs, so that they can discover more 2266 things. 2268 The second principle is the one more affecting a discussion about the 2269 scheme to be used for legal resources identification; in particular 2270 to the aim of guaranteeing the access to the resources, http 2271 identifiers are suggested. This property is addressed as 2272 "dereferenceability", meaning a resource retrieval mechanism using 2273 any of the Internet protocols, e.g. HTTP, so that HTTP clients, for 2274 instance, can look up the URI using the HTTP protocol and retrieve a 2275 description of the resource that is identified by the URI. 2276 Such property is available for http identifiers either with or 2277 without a resolver allowing a 1-to-1 association with the "best copy" 2278 of the resource; in the legal domain it is related to the unique act 2279 manifestation of a specific publisher and format. 2281 The same property holds for URN identifiers, as long as a resolver is 2282 properly set-up, allowing 1-to-N association with more manifestations 2283 of a resource (act). 2285 Therefore an http identifier, stable and independent from the 2286 resource location, can be effectively used when a single publisher 2287 provides a specific item of this resource (1-to-1 mapping between an 2288 identifier and manifestation of an act). The independence from the 2289 resource location is managed by a "303 Redirect" status code (see 2290 http://linkeddatabook.com/editions/1.0/#htoc11) which may require a 2291 resolver able to access the physical location of the resource (e.g., 2292 through submitting a query to a database). A URN identifier, stable 2293 and independent form the resource location, can be effectively used 2294 within a federative environment where different publishers can 2295 provide different items of the same act (1-to-N mapping between an 2296 identifier and different manifestations of an act). 2298 In order to comply with the Linked Data principles and to build http 2299 identifiers using the LEX namespace specifications, the LEX schema 2300 and metadata set can be serialized according to an http URI syntax. 2301 It is worthwhile to mention that URN focuses on acts identification, 2302 while Linked Data principles focus on identifying a resource on the 2303 Web. 2305 In the following sections the http serialization of the urn LEX 2306 schema is reported. 2308 D2 The Http LEX Identifier Structure 2310 The http hierarchical structure of the LEX identifier is the 2311 following: 2313 "http://" host-name "/lex/" jurisdiction "/" local-name 2315 where: 2316 - represents the name of the organization server 2317 publishing the resource; 2318 - "lex" is the equivalent of the URN namespace ID and provides the 2319 reference to the naming convention adopted; 2320 - and share meaning and syntax of the 2321 corresponding components in the LEX specifications. 2323 The element follows the syntax rules of the 2324 corresponding element in the URN specification, therefore it has the 2325 following structure: 2327 jurisdiction = jurisdiction-code *(";" jurisdiction-unit) 2329 The character ";" still separates the identification code of the 2330 country or jurisdiction where the source of law is issued 2331 () from any possible administrative hierarchical 2332 sub-structures defined by each country or organisation according to 2333 its own legal system. 2335 The follows the FRBR model as implemented by the LEX 2336 specifications, therefore its http structure is the following: 2338 local-name = work "/@/" expression "/$/" manifestation 2340 The content of URN:LEX identifier elements is directly transferred to 2341 the corresponding elements of its http version, except for characters 2342 outside the ASCII set: such characters have to be converted into a 2343 valid ASCII format using the typical URL percent encoding rules. 2345 D3 The Http LEX Identifier at Work Level 2347 According to the corresponding level of the URN version, the http LEX 2348 identifier structure at work level is the following: 2350 work = authority "/" measure "/" details *("/" annex) 2352 The elements , and follow the same 2353 syntax rules of the corresponding elements in the URN specification. 2355 Examples of http identifiers at level, corresponding to the 2356 urn examples in Section 6.4, are the following: 2358 http:///lex/it/stato/legge/2006-05-14;22 2359 http:///lex/uk/ministry.justice/decree/1999-10-07;45 2360 http:///lex/ch;glarus/regiere/erlass/2007-10-15;963 2361 http:///lex/es/tribunal.supremo/decision/2001-09-28;68 2362 http:///lex/fr/assemblee.nationale/proposition.loi/ 2363 13.legislature;1762 2364 http:///lex/br/estado/constituicao/1988-10-05;lex-1 2365 http:///lex/fsf.org/free.software.foundation/ 2366 general.public.license/2007-06-29;lex-1 2367 http:///lex/nl/hoge.raad/besluit/2008-04-01;bc8581 2369 D4 The Http LEX Identifier at Expression Level 2371 According to the corresponding level of the URN version, the http LEX 2372 structure at expression level is the following: 2374 expression = version ["/" language] 2376 The elements and follow the same syntax rules of 2377 the corresponding elements in the URN specification. 2379 Examples of http identifiers at expression level, corresponding to 2380 the urn examples in Section 6.6, are the following: 2382 http:///lex/ch/etat/loi/2006-05-14;22/@/originel/fr 2383 (original version in French) 2384 http:///lex/ch/staat/gesetz/2006-05-14;22/@/original/de 2385 (original version in German) 2387 http:///lex/ch/etat/loi/2006-05-14;22/@/2008-03-12/fr 2388 (amended version in French) 2389 http:///lex/ch/staat/gesetz/2006-05-14;22/@/2008-03-12/de 2390 (amended version in German) 2391 http:///lex/be/conseil.etat/decision/2008-07-09;185.273 2392 /@/originel/fr 2393 (original version in French of a Belgian decision) 2395 D5 The Http LEX Identifier at Manifestation Level 2397 Information provided in the URN version at manifestation level is 2398 differently accommodated in the corresponding level of the http LEX 2399 identifier. 2401 The element, reported at manifestation level in the urn LEX 2402 version, is an information already contained in the of 2403 the http LEX identifier, therefore it is omitted in the 2404 elements. 2405 Similarly the element is omitted since it loses its meaning 2406 which would derived from the comparison between different 2407 manifestations. 2409 The element is reported as unique extension of the data 2410 format in which the manifestation is drafted. The value is compliant 2411 with the registered file extensions, thus it can be "pdf" for PDF, 2412 "doc" for MS Word, "xml" for XML documents, "tif" for tiff image 2413 format, etc. 2415 Therefore the http LEX structure at manifestation level is the 2416 following: 2418 manifestation = [ component *(";" specification)] "." format 2420 The element follows the same syntax rules of the 2421 corresponding element in the URN specification. 2423 Examples of http identifiers at manifestation level, corresponding to 2424 the urn examples in Section 6.7 are the following: 2426 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/testo.xml 2427 (body of the Italian law 3 April 2000, n. 56, published by the 2428 Italian Senate in xml format) 2429 http://www.senato.it/lex/it/stato/legge/2000-04-03;56/$/figura.1.pdf 2430 (Figure 1 in PDF format of the Italian law 3 April 2000, n. 56, 2431 published by the Italian Senate) 2432 http://www.juradmin.eu/jurifast/lex/eu/tibunal.justicia/sentencia/ 2433 2009-06-11;33-08/@/original/es/$/todo.html 2434 (the Spanish http LEX identifier of the html format of the whole 2435 Judgement of the European Court of Justice n. 33/08 of 11/06/2009, 2436 in Spanish version, published by the Juriadmin site in the 2437 Jurifast data base) 2438 http://eur-lex.europa.eu/lex/eu/commission/directive/ 2439 2010-03-09;2010-19-EU/$/body.xml 2440 (body of the EU Directive n. 2010-19-EU, dated 2010-03-09, in its 2441 XML format published by Eur-Lex)