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

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

Date post:15-Dec-2015
Category:
View:214 times
Download:1 times
Share this document with a friend
Transcript:
  • Slide 1

Slide 2 A. Boer TIME and VERSIONS Alexander Boer Leibniz Center for Law University of Amsterdam Slide 3 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 Slide 4 Overview META Lex Exchange vs. META Lex Store Design requirements META Lex Store Versions and Identity Legislation lifecycle Summary Slide 5 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. Slide 6 Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input at type Enact Slide 7 Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input @ type Enact Metadata: Date- repealed= 2004/12/12 about 12 december 2004 ???? substring Slide 8 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 Slide 9 XSL Slide 10 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 Slide 11 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 Slide 12 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 Slide 13 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 Slide 14 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 Slide 15 Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input at type Enact Slide 16 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 Slide 17 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) Slide 18 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!textual reference object Slide 19 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 Slide 20 Time and Versions Slide 21 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 Slide 22 Time and Versions Slide 23 Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input @ type Enact Metadata: Date- repealed= 2004/12/12 about 12 december 2004 ???? substring Slide 24 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 Slide 25 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 Slide 26 Example: date-repealed Repealing Legislation Repeal Repealed Legislation Attributing Competence to repeal 2004/12/12 input output input at type Enact Slide 27 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) Slide 28 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 Slide 29 Stacking changes Tiebreaking rule Netherlands: date of enactment date of signing serial number of publication This one always terminates Slide 30 Summary Future documents may be ambiguous now URN vs URL not yet solved Authority/competence for URN schemes Internally (DTCA) URLs work fine 6+1 dates are really relevant Fix/Sign-date is candidate 7 Slide 31 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 Slide 32 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 Slide 33 Where to get it: www.metalex.nl

Click here to load reader

Reader Image
Embed Size (px)
Recommended