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

2. 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

3. Overview • METALex Exchange vs. METALex Store • Design requirements • METALex Store • Versions and Identity • Legislation lifecycle • Summary

4. 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.

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

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

7. 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

8. XSL XSL XSL

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

10. 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

11. Requirements Store Functional requirements: • Presentation in XHTML, definition in RDF/OWL, (de)serialization in METALex 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

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

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

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

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

16. 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)

17. 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 </Reference>

18. 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

19. Time and Versions

20. 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

21. Time and Versions

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

23. 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

24. 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

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

26. 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)

27. 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

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

29. 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

30. 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

31. 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

32. Where to get it: www.metalex.nl