A. Boer TIME and VERSIONS Alexander Boer Leibniz Center for Law University of Amsterdam

Summary Dies consulti, dies signum Not versioning, not always there in lower regulations Dies edicti: date-publication Dies coactu: date-enacted (inwerkingtreding) Dies valens: date-effective (.. werking) Date of modification = dies coactu of modifying provision

Overview META Lex Exchange vs. META Lex Store Design requirements META Lex Store Versions and Identity Legislation lifecycle Summary

Exchange vs. Store Limitations of Exchanging documents Aboutness = information about doc X is part of doc Y (e.g. date of repeal) Completeness = There is only incomplete information about Y Solution for exchange: Explicitly exclude information about a document that is not easily, or customarily maintained in a store. Include good references to a store with global identifiers.

Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input at type Enact

Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output type Enact Metadata: Date- repealed= “2004/12/12” about “12 december 2004” ???? substring

Requirements Independence of jurisdiction; When in doubt, leave it out No exotic options for jurisdictions Independence of user language Extensibility; Make the easy things easy, the hard things possible Use W3C standards for the purposes for which they are intended Integrate with common and free software

XSL

Use of W3C standards Equivalent XML schema and RDF schema XSL (eXtensible Stylesheet Language) for transformation between languages, META Lex and RDF, and META Lex and XHTML Namespaces and static URL and URN names for `global identity’ regulations, persons, and public bodies XML Linking and XPointer support for references

Requirements Exchange Functional requirements: Presentation in XHTML and definition in XML Translation to XML/SGML/HTML standards Translation to RDF/OWL for store Search and filtering on any meaningful level of granularity Global identity and references Description of temporal validity and change Embedding in XML technologies for storage, transfer, knowledge representation, code generation, rule generation, and verification

Requirements Store Functional requirements: Presentation in XHTML, definition in RDF/OWL, (de)serialization in META Lex XML Search and filtering on any meaningful level of granularity Global identity, HTTP access, references, and description of the semantic relations between regulations Management of temporal validity and change Incomplete versions for legislative drafting Embedding in XML technologies for storage, transfer, knowledge representation, code generation, rule generation, and verification

Example Store (DTCA) HTTP GET Cocoon: reply filtering, translation to HTML, input forms, URL sitemap, load balancing, etc. CMS: answering queries, updating, text search, parsing Jena: storage of RDF Racer: inference, consistency Content HTTP GET/POST HTTP POST (DIG XML) HTTP GET/POST

RDF example Constitution Article 81 Article 89 Article 134 Article 134, lid 1 Law, Delegation Competence Art. 134 Royal Decree, AMVB, Creation of SER Regulation (binding employees and employers) Government and States General Government Social- economic Council (SER) Attribution Subdelegation Delegation

Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input at type Enact

Advantages of RDF 1. Statement about something is the representational primitive: (subject, predicate, object) 2. URI `identity’ of Regulation and XML documents (files) are separated; A statement can be stored anywhere 3. Capable of storing incomplete models of a regulation 4. Uses global URI identity for non-retrievable objects; persons, acts, events, competences, decisions, etc. 5. RDF can be used to `encode’ UML, OWL and other software engineering languages

Versions and Identity A Regulation is One regulation, but different versions Publication, XML document, RDF model, signed paper? Not draft legislation or proposed legislation? Reference is to a version (of local part) of a Regulation on a date in a language? Reference to identity is an injective function, e.g. publication source, citation title, database key Also reference to identity of reference, e.g. intranet table that refers to XML documents of publisher) Citation (art. 1 Constitution) vs. reference (that Law, specific regulation, our Minister)

Versions and Identity Globally unique identity regulation: URI, URN, URL Locally unique identity regulation in (globally unique) namespace: ID for XML/RDF or XPath for XML How to obtain XML/RDF content for a reference is unspecified! <Reference xlink:href=“global#local” ref-date=“time point”> textual reference object

Versions and Identity XML/RDF model is not always complete representation of all versions wrt. language or time Representation of time versions was correct (not complete) on date-version Time intervals should therefore be closed in incomplete XML/RDF model

Time and Versions

Date-repealed, date-enacted, date- publication Date-version and “date-of-interest”! Date-ref on a reference  If missing by default the current version (date- version)! Date-effective  Semantics cannot be fixed in a standard which pretends to be jurisdiction-independent

Time and Versions

Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output type Enact Metadata: Date- repealed= “2004/12/12” about “12 december 2004” ???? substring

Legislation lifecycle Fix (sign) L at T by A with competence C attributed by L’ Publish L at T by A with competence C attributed by L’ Enact L at T in L’’ by A with competence C attributed by L’ Repeal L at T in L’’ by A with competence C attributed by L’ Change L at T in L’’ by A with competence C attributed by L’  L and L’’ are different objects, but versions of the same abstract object  L’’ was published at the date the change was made

Complications relative dates of change, enact, retract (two weeks after) The date may occur in no document as a string! the importance of date-version Future changes may not lead to an unambiguous (consolidated) version (yet) Date-enacted vs. effective/applicable

Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input at type Enact

Competence/Power Acting Attributing a competence to Y to do X Taking a competence to do X from Y Using a competence to do X Mandating Y to do X  Submandating Y to do X Delegating a competence to do X to Y  Subdelegating a competence to do X to Y  (Autodelegation/Allodelegation)

Change Dates when active, when is the change made? to what (which version) is the change therefore made? looking into the future... Temporary changes Stacking changes on one date minimizing number of consolidated versions Jurisdiction-specific tiebreaker needed

Stacking changes Tiebreaking rule Netherlands: date of enactment date of signing serial number of publication  This one always terminates

Summary Future documents may be ambiguous now URN vs URL not yet solved Authority/competence for URN schemes Internally (DTCA) URL’s work fine 6+1 dates are really relevant Fix/Sign-date is candidate 7

Summary Changes must to law be completely specified in law for version mangement Word change: Agreement in sentence + anaphoric reference Parsing/understanding enactment, repeal, change clauses presuppose understanding of competence and relative dates

Summary Dies consulti, dies signum Not versioning, not always there in lower regulations Dies edicti: date-publication Dies coactu: date-enacted (inwerkingtreding) Dies valens: date-effective (.. werking) Date of modification = dies coactu of modifying provision

Where to get it: