{"id":1968,"date":"2011-10-25T08:50:15","date_gmt":"2011-10-25T13:50:15","guid":{"rendered":"http:\/\/blog.law.cornell.edu\/voxpop\/?p=1968"},"modified":"2011-11-01T08:34:31","modified_gmt":"2011-11-01T13:34:31","slug":"the-metalex-document-server","status":"publish","type":"post","link":"https:\/\/blog.law.cornell.edu\/voxpop\/2011\/10\/25\/the-metalex-document-server\/","title":{"rendered":"The MetaLex Document Server"},"content":{"rendered":"<p><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/Vox.DutchFlag.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2018\" style=\"margin: 6px\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/Vox.DutchFlag.jpg\" alt=\"Dutch flag\" width=\"274\" height=\"184\" \/><\/a>In this post I describe the process and requirements that eventually led to the\u00a0<a href=\"http:\/\/doc.metalex.eu\">MetaLex Document Server<\/a>, a server that hosts all versions of Dutch national statutes and regulations published since May 2011, both as\u00a0<a href=\"http:\/\/www.metalex.eu\">CEN MetaLex<\/a>, and as\u00a0<a href=\"http:\/\/www.w3.org\/standards\/semanticweb\/data\">Linked Data<\/a>. Before I set out to do so, however, I would like to emphasize that, although the development of the server and its contents was a one-man-job, the road to make it possible surely was not solitary. A couple of people I&#8217;d like to mention here are <a href=\"http:\/\/www.leibnizcenter.org\/people\/postdoctoral-researchers\/alexander-boer\">Alexander Boer<\/a>, <a href=\"http:\/\/www.leibnizcenter.org\/people\/researchers\/radboud-winkels\">Radboud Winkels<\/a>, and <a href=\"http:\/\/www.leibnizcenter.org\/people\/professors\/tom-van-engers\">Tom van Engers<\/a> of <a href=\"http:\/\/www.leibnizcenter.org\/\">the Leibniz Center for Law<\/a>, together with whom I have worked over the past ten years to develop, test, and publish the ideas that underlie CEN MetaLex. Also, the team around\u00a0<a href=\"http:\/\/legislation.gov.uk\">legislation.gov.uk<\/a> clearly has done a lot of great and inspiring\u00a0 work in this area.<\/p>\n<p>So, what happened? Over the course of last spring, I was involved in several small-scale projects that shared a specific need: version-aware identifiers for all parts of legislative texts. \u00a0The first of these was a report for the\u00a0<a href=\"http:\/\/www.bk.admin.ch\/index.html?lang=en\">Swiss Federal Chancellery<\/a> on possible technological solutions for a regulation drafting system to be used by the Swiss government. Second to arrive on my desk was a project for the\u00a0<a href=\"http:\/\/www.belastingdienst.nl\">Dutch Tax and Customs Administration (Belastingdienst),<\/a> in which we were asked to develop a concept-extraction toolkit that would allow them to make explicit where concepts are defined, where they are reused, and how they relate to other concepts (<em>e.g.<\/em>, from an external thesaurus). The purpose of this project was to investigate whether we could replace with technology what is currently a manual process of turning legislation into business processes that fuel citizen- and business-oriented services. The Belastingdienst needs this to better cope with the yearly changes to tax regulation issued by the\u00a0<a href=\"http:\/\/www.rijksoverheid.nl\/ministeries\/fin\">Ministry of Finance<\/a>. The\u00a0<a href=\"http:\/\/www.ind.nl\">Dutch Immigration and Naturalisation Service (IND)<\/a> faces exactly the same problem: of discovering what part of their business processes is affected by each legislative modification. Updates to legislation require continuous, significant investment in IT re-engineering.<\/p>\n<p><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/grounding.png\"><img loading=\"lazy\" decoding=\"async\" class=\"size-medium wp-image-2008 alignright\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/grounding-300x146.png\" alt=\"Model of content of legislation\" width=\"300\" height=\"146\" srcset=\"https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/grounding-300x146.png 300w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/grounding.png 677w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<h3><strong>The root of the problem<\/strong><\/h3>\n<p>But don&#8217;t modern European governments already have elaborate facilities for supporting this workflow? I&#8217;m afraid not.<\/p>\n<p>Currently, regulation drafting is a process of sending around Word documents, copy-and-pasting from older texts, &#8220;version hell,&#8221; signing by a Minister, and sending the enacted regulations off to a publisher, who will then turn it into some XML format to feed a publishing platform to generate HTML, PDF, and paper versions of the texts. This process is not designed with a content management perspective, and most if not all metadata is thrown away in the process.<\/p>\n<p>Part of the problem is one of\u00a0<em>organisational change<\/em>: convincing legislative drafters to use a more structured approach in their daily work. The\u00a0<a href=\"http:\/\/english.justitie.nl\/\">Dutch Ministry of Security and Justice<\/a> is currently developing a legislative editing environment (similar to the\u00a0<a href=\"http:\/\/www.mendeley.com\/research\/metavex-regulation-drafting-meets-semantic-web\/\">MetaVex<\/a> editor developed at the\u00a0<a href=\"http:\/\/www.leibnizcenter.org\">University of Amsterdam<\/a>), but it will take awhile before this is adopted in practice.<\/p>\n<h3><strong>Requirements<\/strong><\/h3>\n<p>To develop a chain of tools for managing legal information, both as text and as knowledge models, we need to address a number of key requirements:<\/p>\n<ul>\n<li>An integrated legislative drafting and editing environment that supports advanced version and provenance tracking (<em>e.g.<\/em>, version tracking of successive changes to draft texts). Provenance information is very important for eliciting the procedure that led to an official version (both pre- and post-publication), as well as its underlying\u00a0<em>motivation<\/em>.<\/li>\n<li>A format in which these texts are stored that is flexible enough to allow both editing and publication to various formats (such as PDF and HTML).<\/li>\n<li>The ability to persistently identify <strong>every<\/strong> element of a legal text. Versioning of texts, references, and metadata requires identifiers that reflect the different versions of these resources. The various parts of a text should be versioned independently, allowing for transitory regimes.<\/li>\n<\/ul>\n<p>A versioning mechanism should distinguish between a regulation text as it exists at a particular time, and the final regulation. The <a href=\"http:\/\/www.ifla.org\/publications\/functional-requirements-for-bibliographic-records\">IFLA Functional Requirements for Bibliographic Records (FRBR)<\/a> (Saur, &#8217;98) makes the following distinctions: the work as a &#8220;distinguishable intellectual or artistic creation&#8221; (<em>e.g.<\/em>, the constitution); the expression as the &#8220;intellectual or artistic form that a work takes each time it is realised&#8221; (<em>e.g.<\/em>, &#8220;The Constitution of July 15th, 2008&#8221;); the manifestation as the &#8220;physical embodiment of an expression of a work&#8221; (<em>e.g.,<\/em> a PDF version of &#8220;The Constitution of July 15th, 2008&#8221;); and the item as a &#8220;single exemplar of a manifestation&#8221; (<em>e.g.<\/em>, the PDF version of &#8220;The Constitution of July 15th, 2008&#8221; residing on my USB stick).<\/p>\n<ul>\n<li>These identifiers should be dereferenceable to the element they describe, or a description of the element&#8217;s metadata.<\/li>\n<li>Metadata and annotations should be traceable to the most detailed part of a text, as well as to its version, when needed. The same requirement holds for references between texts, allowing for fine-grained analysis of interdependencies between texts.<\/li>\n<li>It is furthermore a requirement that these identifiers be <strong>transparent<\/strong> and follow a prescribed naming convention. This allows third parties to construct valid identifiers without having to first query a name service.<\/li>\n<li>The metadata itself should be made accessible in a standard format as well.<\/li>\n<\/ul>\n<h3><strong>Making do with what we&#8217;ve got<\/strong><\/h3>\n<p>As we don&#8217;t have any time to waste, and have neither the organisational infrastructure, nor the funds, to use or develop any other (richer) information source, we need to make do with what&#8217;s currently available. How hard is it to build a chain of tools that meets at least part of these requirements? And, what information does the Dutch government already provide on which we can build the services that it itself so dearly needs?<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignleft\" style=\"margin: 3px\" src=\"http:\/\/wetten.overheid.nl\/images\/logos\/overheid-nl.png\" alt=\"Overheid.nl Logo\" width=\"185\" height=\"29\" \/><\/p>\n<p><a href=\"http:\/\/www.wetten.nl\">Wetten.overheid.nl<\/a> is the de facto source for legislative information in The Netherlands.\u00a0Users can perform a full text search through the titles and text of all statutes and regulations of the Kingdom of the Netherlands. They can search for a specific article, as well as for the version of a text as it stood at a specified date. Wetten.overheid.nl also provides an API for retrieving XML manifestations of statutes and regulations.<\/p>\n<h3><strong>Identifiers<\/strong><\/h3>\n<p>What about identifiers? Wetten.nl supports deeplinks to particular versions of statutes and regulations, but is not very consistent about it. For example:<\/p>\n<p><a href=\"http:\/\/wetten.overheid.nl\/cgi-bin\/deeplink\/law1\/bwbid=BWBR0005416\/article=6\/date=2005-01-14\">http:\/\/wetten.overheid.nl\/cgi-bin\/deeplink\/law1\/bwbid=BWBR0005416\/article=6\/date=2005-01-14<\/a><\/p>\n<p>and<\/p>\n<p><a href=\"http:\/\/wetten.overheid.nl\/BWBR0005416\/TitelII698946\/HoofdstukII\/Artikel16\/geldigheidsdatum_14-01-2005\">http:\/\/wetten.overheid.nl\/BWBR0005416\/TitelII698946\/HoofdstukII\/Artikel16\/geldigheidsdatum_14-01-2005<\/a><\/p>\n<p>both point to article 6 of the Municipal law, as it was in effect on January 14th, 2005. A third mechanism for identifying regulations is the\u00a0<a href=\"http:\/\/www.juriconnect.nl\">Juriconnect<\/a> standard for referring to parts of statutes and regulations. XML documents hosted by Wetten.nl use these identifiers to specify citations between statutes and regulations.\u00a0For instance, the Juriconnect identifier for article 6 of the Municipal law is:<\/p>\n<p><code>1.0:c:BWBR0005416&amp;artikel=16&amp;g=2005-01-14<\/code><\/p>\n<p>But&#8230; the standard does not prescribe a mechanism for dereferenecing an identifier to the actual text of (part of) a statute or regulation.<\/p>\n<h3><strong>The BWB XML service and format<\/strong><\/h3>\n<p>XML manifestations of statutes and regulations are retrievable through an API on top of the &#8220;Basiswettenbestand&#8221; (BWB) content management system. This <a href=\"https:\/\/www.ibm.com\/developerworks\/webservices\/library\/ws-restful\/\">REST<\/a> Web service only provides the latest version of an entire statute or regulation. The BWB XML document returned is stripped of all version history: it does not even contain the version date of the text itself.<\/p>\n<p><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/problem-xml.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-large wp-image-2009\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/problem-xml-1024x454.png\" alt=\"Example of BWB Identifier Index\" width=\"695\" height=\"308\" srcset=\"https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/problem-xml-1024x454.png 1024w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/problem-xml-300x133.png 300w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/problem-xml.png 1739w\" sizes=\"auto, (max-width: 695px) 100vw, 695px\" \/><\/a><\/p>\n<p>An index of all BWB identifiers, with basic attributes such as official and abbreviated titles, enactment and publication dates, retroactivity, etc. is available as a\u00a0<a href=\"http:\/\/www.overheid.nl\/help\/wr\/deeplinks\">zipped XML dump<\/a> or\u00a0a <a href=\"http:\/\/www.e-overheidvoorburgers.nl\/producten,wet-en-regelgeving\/Documentatie.html\">SOAP service<\/a>. Unfortunately, the XML file is\u00a0<strong>corrupt<\/strong>, and the date of the latest change to a statute or regulation reported in the index is\u00a0<em>not really the date of the latest modification<\/em>, but of the latest update of the statute or regulation in the CMS. \u00a0See the picture above.<\/p>\n<p>The BWB uses its own XML schema for storing statutes and regulations; this schema does not allow for intermixing with any third-party elements or attributes, ruling out obvious extensions for rich annotations such as\u00a0<a href=\"http:\/\/www.w3.org\/TR\/rdfa-syntax\/\">RDFa<\/a>.\u00a0And, BWB XML elements do not carry any identifiers.<\/p>\n<h3><strong>A more general XML format: CEN MetaLex<\/strong><\/h3>\n<p><a href=\"http:\/\/www.metalex.eu\">CEN MetaLex<\/a> is a jurisdiction-independent XML format for representing, publishing, and interchanging legal texts. It was developed to allow\u00a0<strong>traceability<\/strong> of legal knowledge representations to their original source.\u00a0MetaLex elements are purely structural. Syntactic elements (structure) are strictly distinct from the meaning of elements by specifying for each element a\u00a0<strong>name<\/strong> and its\u00a0<strong>content model<\/strong>. What this essentially does is to pave the way for a semantic description of the types of content of elements in an XML document. The standard prescribes the existence of a naming convention for minting URI-based identifiers for all structural elements of a legal document. MetaLex explicitly encourages the use of RDFa attributes on its elements, and provides special metadata-elements for serialising additional RDF triples that cannot be expressed on structural elements themselves. MetaLex includes an ontology, which defines an event model for legislative modifications. The\u00a0<a href=\"http:\/\/legislation.gov.uk\">legislation.gov.uk<\/a> portal has adopted the MetaLex event model for representing modifications.<\/p>\n<h3><strong>Getting from BWB to CEN MetaLex<\/strong><\/h3>\n<p>The MetaLex schema is designed to be independent of jurisdiction, which means that it should be possible to map each legacy XML element to a MetaLex element in an unambiguous fashion. Fortunately, we were able to define a straightforward 1:<em>n<\/em> mapping between BWB and MetaLex (see below) by a semi-automatic conversion of the BWB XML DTD.<\/p>\n<p>The transformation of legacy XML to MetaLex and RDF is implemented in the MetaLex converter, an open source\u00a0<a href=\"http:\/\/github.com\/RinkeHoekstra\/metalex-converter\">Python script available from GitHub<\/a>. Conversion occurs in four stages:<\/p>\n<ul>\n<li><strong>mapping<\/strong> legacy elements to MetaLex elements,<\/li>\n<li>minting\u00a0<strong>identifiers<\/strong> for newly created elements,<\/li>\n<li><strong>producing metadata<\/strong> for these elements, and<\/li>\n<li><strong>serialising<\/strong> to appropriate formats.<\/li>\n<\/ul>\n<h4><strong>Step 1: Mapping<\/strong><\/h4>\n<p>For the transformation of BWB XML files, the converter is sequentially fed with all BWB XML files and identifiers listed in the BWB ID index. Based on the mapping table, the converter traverses the\u00a0<a href=\"http:\/\/www.w3.org\/TR\/REC-DOM-Level-1\/\">DOM<\/a> tree of the source document, and synchronously builds a DOM tree for the target document. In cases where the MetaLex schema doesn&#8217;t quite &#8220;fit,&#8221; the converter has to make additional repairs.<\/p>\n<p><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/evaluation.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-medium wp-image-2011\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/evaluation-300x116.png\" alt=\"MetaLex conversion performance for 300 randomly selected regulations\" width=\"300\" height=\"116\" srcset=\"https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/evaluation-300x116.png 300w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/evaluation.png 623w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/a><\/p>\n<p>We evaluated the ability of MetaLex to map onto the BWB XML by running the converter on 300 randomly selected BWB identifiers. The\u00a0<code>artikel <\/code>element accounts for 72% of all corrections, and corresponds to 68% of all\u00a0<code>htitle<\/code> substitutions (5 % of total). This means that only a very small part of BWB XML does not directly fit onto the MetaLex schema. The main cause for incompatibility is the restriction in MetaLex that\u00a0<code>hcontainer <\/code>elements are not allowed to contain\u00a0<code>block<\/code> elements (and that&#8217;s perhaps something to consider for the MetaLex workshop).<\/p>\n<p>Because of the limitations of the API, version information, citation titles, and other metadata are retrieved through a custom-built scraper of the information pages on the wetten.nl Website.<\/p>\n<h4><strong>Step 2: Minting Identifiers<\/strong><\/h4>\n<p>For every element in the document we create transparent URL-like URIs for the\u00a0<strong>work<\/strong>,\u00a0<strong>expression<\/strong> and\u00a0<strong>manifestation<\/strong> levels, and two opaque URIs for the\u00a0<strong>expression<\/strong> and\u00a0<strong>item<\/strong> levels in the FRBR specification.<\/p>\n<p>For transparent URIs, we use a naming scheme that is based on the\u00a0<a href=\"http:\/\/www.legislation.gov.uk\/developer\/uris\">URIs used at legislation.gov.uk<\/a>, with slight adaptations to allow for the Dutch situation. In short, work level identifiers are based on the standard BWB identifier, followed by a hierarchical path to an element in the source, <em>e.g.<\/em>, &#8220;chapter\/1\/article\/1&#8221;. These URIs are extended to expression URIs by appending version and language information. Similarly, manifestation URIs are extensions of expression URIs that specify format information such as XML, RDF, etc.\u00a0 Juriconnect references in the source BWB XML are automatically translated to this naming scheme.<\/p>\n<p>The\u00a0<strong>opaque version URI<\/strong> is needed to distinguish different versions of a text. The current Webservice does not provide access to all versions of statutes and regulations (only to the latest), let alone at a level of granularity lower than entire statutes or regulations. We therefore need some way of constructing a version history by regularly checking for new versions, and comparing them to those we looked at before. By including in the opaque URI a unique <strong><a href=\"http:\/\/www.w3.org\/PICS\/DSig\/SHA1_1_0.html\">SHA1<\/a> hash<\/strong> of the textual content of an XML element, and simultaneously maintaining a link between the opaque URI and the transparent identifier, different expressions of a work can be automatically distinguished through time. This is needed to work around issues with identifiers based on numbers: the insertion of a new element can change the position (and therefore the identifier) of other elements without a change in the content of the elements.<\/p>\n<p>By this method, globally persistent URIs of every element in a legal text can be consistently generated for both current and future versions of the text. By simultaneously generating an opaque and a transparent expression level URI, identification of these text versions does not have to rely on numbering.<\/p>\n<h4 id=\"producing_metadata\">Step 3: Producing Metadata<\/h4>\n<p>The MetaLex converter produces three types of metadata. First,\u00a0<strong>legacy<\/strong> metadata from attributes in the source XML is directly translated to RDF triples. Second, metadata describing the\u00a0<strong>structural<\/strong> and\u00a0<strong>identity<\/strong> relations between elements is created. This includes typing resources according to the MetaLex ontology, <em>e.g.<\/em>, as\u00a0<code>ml:BibliographicExpression<\/code>; creating\u00a0<code>ml:realizes<\/code> relations between expressions and works;\u00a0and creating <code>owl:sameAs<\/code> relations between opaque and transparent expression URIs.\u00a0The official title, abbreviation, and publication date of statutes and regulations are represented using the\u00a0<code>dcterms:title<\/code>,\u00a0<code>dcterms:alternative<\/code> and\u00a0<code>dct:valid<\/code> properties.<\/p>\n<p><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/event-schema.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-large wp-image-2004\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/event-schema-1024x499.png\" alt=\"MetaLex Document Server Event Schema\" width=\"695\" height=\"338\" srcset=\"https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/event-schema-1024x499.png 1024w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/event-schema-300x146.png 300w\" sizes=\"auto, (max-width: 695px) 100vw, 695px\" \/><\/a><\/p>\n<h3><strong>Events and Processes<\/strong><\/h3>\n<p>Event information plays a central role in determining\u00a0<em>what<\/em> version of a regulation was valid\u00a0<em>when<\/em>. Making explicit which events and modifying processes contributed to an expression of a regulation provides for a flexible and extensible model.\u00a0The MDS uses the\u00a0<a href=\"http:\/\/svn.metalex.eu\/svn\/MetaLexWS\/branches\/latest\/metalex-cen.owl\">MetaLex ontology<\/a> for legislative modification events, the\u00a0<a href=\"http:\/\/www.cs.vu.nl\/~guus\/papers\/Hage11b.pdf\">Simple Event Model (SEM)<\/a> and the\u00a0<a href=\"http:\/\/www.w3.org\/TR\/owl-time\/\">W3C Time Ontology<\/a> for an abstract description of events and event types, and the\u00a0<a href=\"http:\/\/openprovenance.org\">Open Provenance Model Vocabulary (OPMV)<\/a> for describing processes and provenance information. These vocabularies can be combined in a compatible fashion, allowing for maximal reuse of event and process descriptions by third parties that may not necessarily commit to the MetaLex ontology.<\/p>\n<p><strong><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/example-scbd.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-large wp-image-2006\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/example-scbd-1024x729.png\" alt=\"Example of Symmetric Concise Bounded Description (SCBD) of a MetaLex Document Server RDF resource\" width=\"695\" height=\"494\" srcset=\"https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/example-scbd-1024x729.png 1024w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/example-scbd-300x213.png 300w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/example-scbd.png 1994w\" sizes=\"auto, (max-width: 695px) 100vw, 695px\" \/><\/a><\/strong><\/p>\n<h4><strong>Step 4: Serialization<\/strong><\/h4>\n<p>The MetaLex converter supports three formats for serialising a legal text to a manifestation: the MetaLex format itself, viewable in a browser by\u00a0<a href=\"http:\/\/doc.metalex.eu\/static\/css\/metalex.css\">linking a CSS stylesheet<\/a>; RDFa, Turtle and RDF\/XML serializations of the RDF metadata; and a citation graph.\u00a0The converter can automatically upload RDF to a triple store through either the\u00a0<a href=\"http:\/\/openrdf.org\">Sesame API<\/a>, or\u00a0<a href=\"http:\/\/www.w3.org\/TR\/sparql11-update\">SPARQL updates<\/a>. The citation graph is exported as\u00a0a &#8216;&#8221;net&#8221; network file, for further analysis in social network software tools such as\u00a0<a href=\"http:\/\/pajek.imfm.si\/doku.php\">Pajek<\/a> and\u00a0<a href=\"http:\/\/gephi.org\">Gephi<\/a>. We are exploring ways to use these networks for determining the importance of articles (in degree) and the dependency of legislation on certain articles (betweenness centrality), and for analysing the correlation between legislation and case law.<\/p>\n<h3><strong>Publication<\/strong><\/h3>\n<p>The results of this procedure are published through the\u00a0<a href=\"http:\/\/doc.metalex.eu\">MetaLex Document Server (MDS)<\/a>. The server follows the\u00a0<a href=\"http:\/\/www.w3.org\/TR\/cooluris\/\">Cool URIs<\/a> specification, and implements HTTP-based redirects for work- and expression-level URIs to corresponding manifestations based on the HTTP accept header.\u00a0Requests for an HTML mime-type are redirected to a\u00a0<a href=\"http:\/\/marbles.sourceforge.net\/\">Marbles<\/a> HTML rendering of a\u00a0<a href=\"http:\/\/www.w3.org\/Submission\/CBD\/\">Symmetric Concise Bounded Description (SCBD)<\/a> of the RDF resource. Similarly, requests for RDF content return the SCBD itself; supported formats are RDF\/XML and Turtle.\u00a0A request for XML will return a snippet of MetaLex for the specified part of a statute or regulation.<\/p>\n<p><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/cool-uris.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-large wp-image-2005\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/cool-uris-1024x513.png\" alt=\"Cool URIs\" width=\"695\" height=\"348\" srcset=\"https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/cool-uris-1024x513.png 1024w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/cool-uris-300x150.png 300w, https:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/cool-uris.png 1027w\" sizes=\"auto, (max-width: 695px) 100vw, 695px\" \/><\/a><\/p>\n<p>The MDS provides two convenient methods for retrieving manifestations of a statute or regulation. Appending &#8220;\/latest&#8221; to a work URI will redirect to the latest expression present in the triple store. Appending an arbitrary ISO date will return the last expression published before that date if no direct match is available. Lastly, the MDS offers a\u00a0<a href=\"http:\/\/doc.metalex.eu\/search\">simple search interface<\/a> for finding statutes and regulations based on the title and version date.<\/p>\n<h3><strong>Results and Take Up<\/strong><\/h3>\n<p><a href=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/mds.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft\" style=\"margin: 5px\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/mds-300x217.png\" alt=\"MetaLex Document Server Homepage\" width=\"300\" height=\"217\" \/><\/a>We have been running the converter on a daily basis, on all versions of statutes and regulations made available through the wetten.nl portal since May 2011. This has resulted in a current total of <strong>29,120<\/strong> document versions: 28 thousand versions in the first run, the rest accumulated through time. For these document versions, we now store <strong>119 million<\/strong> triples of RDF metadata in a <a href=\"http:\/\/4store.org\">4Store<\/a> triple store. Compared to the size of legislation.gov.uk (1.9 billion triples, since the 1200s), this is a modest number, but at the current growth rate we will soon need to look for alternative (more professional) solutions. Check the <a href=\"http:\/\/doc.metalex.eu\">http:\/\/doc.metalex.eu<\/a> Website for the latest numbers.<\/p>\n<p>I am happy to say, also, that this work has not gone unnoticed. The IND was particularly enthused by the versioning mechanism, and is in the process of adopting the MDS approach as their internal content management system. Similarly, the ability to link concept descriptions to reliably versioned parts of legislation has been an eye opener for the Belastingdienst. We are also in touch with several people at\u00a0<a href=\"http:\/\/www.ictu.nl\">ICTU<\/a>, the organisation behind Wetten.nl, to help them improve their services.<\/p>\n<p><a href=\"http:\/\/www.mendeley.com\/profiles\/rinke-hoekstra\/\"><img loading=\"lazy\" decoding=\"async\" src=\"http:\/\/blog.law.cornell.edu\/voxpop\/files\/2011\/10\/RinkeHoektraImage.png\" alt=\"Rinke Hoekstra\" title=\"Rinke_Hoektra\" width=\"176\" height=\"217\" class=\"alignleft size-full wp-image-2025\" \/><\/a><strong><a href=\"http:\/\/www.mendeley.com\/profiles\/rinke-hoekstra\/\">Dr. Rinke Hoekstra<\/a><\/strong> is a postdoctoral researcher at <a href=\"http:\/\/www.leibnizcenter.org\/\">the Leibniz Center for Law at the University of Amsterdam<\/a>.  He is the developer of <a href=\"http:\/\/doc.metalex.eu\/\">the MetaLex Document Server<\/a>, the principal author of <a href=\"http:\/\/www.estrellaproject.org\/lkif-core\/\">the LKIF Core ontology of basic legal concepts<\/a>, and one of the initial developers of <a href=\"http:\/\/www.metalex.eu\/\">the MetaLex XML format for legal sources<\/a>.<\/p>\n<p>VoxPopuLII is edited by <a href=\"http:\/\/www.judithpratt.com\/\">Judith Pratt.<\/a> Editor-in-Chief is <a href=\"http:\/\/legalinformatics.wordpress.com\/about\/\">Robert Richards<\/a>, to whom queries should be directed. The statements above are not legal advice or legal representation. If you require legal advice, consult a lawyer. <a href=\"http:\/\/lawyers.law.cornell.edu\/\">Find a lawyer<\/a> in <a href=\"http:\/\/lawyers.law.cornell.edu\/\">the Cornell LII Lawyer Directory<\/a>.<\/p>\n<!-- AddThis Advanced Settings generic via filter on the_content --><!-- AddThis Share Buttons generic via filter on the_content -->","protected":false},"excerpt":{"rendered":"<p>In this post I describe the process and requirements that eventually led to the\u00a0MetaLex Document Server, a server that hosts all versions of Dutch national statutes and regulations published since May 2011, both as\u00a0CEN MetaLex, and as\u00a0Linked Data. Before I set out to do so, however, I would like to emphasize that, although the development <a href='https:\/\/blog.law.cornell.edu\/voxpop\/2011\/10\/25\/the-metalex-document-server\/'>[&#8230;]<\/a><!-- AddThis Advanced Settings generic via filter on get_the_excerpt --><!-- AddThis Share Buttons generic via filter on get_the_excerpt --><\/p>\n","protected":false},"author":72,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[456,329,296,471,464,504,4845,293],"tags":[588,4853,4855,4851,584,4848,4849,4856,4986,4857,511,509,583,640,4846,4852,4854,4850,4847],"class_list":["post-1968","post","type-post","status-publish","format-standard","hentry","category-legal-identifiers","category-legal-metadata","category-legal-semantic-web","category-legal-text-processing","category-legal-xml","category-legislative-information-systems","category-regulatory-information-systems","category-semantic-web-and-law","tag-cen-metalex","tag-dublin-core-and-legal-documents","tag-dublin-core-and-legal-information","tag-dublin-core-and-legal-metadata","tag-frbr","tag-frbr-and-legal-information","tag-frbr-and-legal-metadata","tag-legal-citation-analysis","tag-legal-identifiers","tag-legal-network-analysis","tag-legal-uris","tag-legal-urls","tag-legislationgovuk","tag-leibniz-center-for-law","tag-metalex-document-server","tag-rdf-and-legal-documents","tag-rdf-and-legal-information","tag-rdf-and-legal-metadata","tag-rinke-hoekstra"],"_links":{"self":[{"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/posts\/1968","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/users\/72"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/comments?post=1968"}],"version-history":[{"count":81,"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/posts\/1968\/revisions"}],"predecessor-version":[{"id":2016,"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/posts\/1968\/revisions\/2016"}],"wp:attachment":[{"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/media?parent=1968"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/categories?post=1968"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.law.cornell.edu\/voxpop\/wp-json\/wp\/v2\/tags?post=1968"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}