This paper presents our experience on building RDF knowledge graphs for an industrial use case in the legal domain. The information contained in legal information systems are often accessed through simple keyword interfaces and presented as a simple list of hits. In order to improve search accuracy one may avail of knowledge graphs, where the semantics of the data can be made explicit. Signi cant research e ort has been invested in the area of building knowledge graphs from semistructured text documents, such as XML, with the prevailing approach being the use of mapping languages. In this paper, we present a semantic model for representing legal documents together with an industrial use case. We also present a set of use case requirements based on the proposed semantic model, which are used to compare and discuss the use of state-of-the-art mapping languages for building knowledge graphs for legal data.
The body of law to which citizens and businesses have to adhere is constantly
increasing in volume and complexity [
This work presents ongoing e orts related to building RDF knowledge graphs
for representing legal documents. The key focus of building such knowledge
graphs is to improve search accuracy by understanding its intent and context.
The RDF (Resource Description Framework) [
In this paper, we present a semantic model for legal documents, which is then being used in a real-world use case. This use case comes from an ongoing project with Wolters Kluwer Germany, where legal documents must be transformed to RDF knowledge graphs. These documents are stored as XML les and follow a speci c schema. Considering the semantic model and the legal document's schema we have de ned a set of requirements, which are used to compare and discuss the use of di erent state-of-the-art mappings engines. Finally, we present an evaluation comparing the performance of a mapping approach and an ad hoc custom parser.
The remainder of this paper is organised as follows: Section 2 describes our use case and the XML document schema. Section 3 presents a semantic model for representing legal documents that has been developed. Section 4 describes the semantic uplift of legal documents to RDF knowledge graphs through the use of mapping languages. Section 5 presents a comparison evaluation between mapping engines. Section 6 discusses related work. Section 7 concludes the paper and discusses future work. 2
This section presents our industrial use case, which comes from an ongoing project with Wolters Kluwer Germany (WKD). WKD is a leading knowledge and information service provider in the domains of law, companies, and tax, which o ers high quality business information for professionals. Wolters Kluwer is based in more than 40 countries and serves customers in more than 180 countries worldwide.
WKD's use case contains millions of documents in the German language containing legal information together with links to taxonomy concepts. As mentioned, the documents are stored as XML les. Each document consists of the key parts: document keywords, document taxonomy concepts, and fragments. Each fragment has a type, such as main claim (tenor ), court facts (tatbestand ), amongst others, which are represented by di erent XML element tags. Just like documents, fragments may be annotated with taxonomy concepts. The use of taxonomy concepts de nes the speci c legal matters and processes contained in a document. In this sense, the shared use of such concepts across documents re ect the relations between the legal information contained in those documents. This characteristic, however, is not made explicit, since each document is represented by a single di erent XML le. One possible way of making such information explicit is through the use of knowledge graphs, as will be discussed in Section 3. An example of an XML document is shown in Figure 1.
The taxonomy concepts used to annotate documents and its fragments come from WKD's taxonomy ontology. This ontology contains information about legal concepts, which are supplemented by technical terms of neighboring areas such as economics, sociology or politics. The Simple Knowledge Organization System 4 (SKOS) vocabulary is used to describe concepts and their relations in this taxonomy. SKOS is a W3C Recommendation designed to support the use of knowledge organization systems. In WKD's use case, each legal concept is represented as a skos:Concept, with the main relationships being expressed through the properties skos:narrower and skos:broader. A major legal subdomain of WKD's taxonomy is available for download and accessible via a SPARQL endpoint5.
As stated in Section 2, our use case shares taxonomy concepts within and across legal documents, which are not made explicit through the XML data format. This section presents a semantic model designed for the representation of those legal documents, with the aim of making such relationships explicit.
The proposed semantic model draws inspiration and extends an existing one
presented in [
The vocabularies being used in the semantic model are the Platform Content Interface (PCI), which leverages the Functional Requirements for Bibliographic Records (FRBR), the Simple Knowledge Organization System (SKOS) and the Dublin Core (DC) terms ontologies. The PCI ontology is a proprietary vocabulary describing legal documents and metadata. The FRBR6 ontology provides a vocabulary for concepts and relations in bibliographic databases de ned by the International Federation of Library Associations7 initiative. Finally, the DC terms8 ontology provides a vocabulary describing all metadata terms maintained by the Dublin Core Metadata Initiative9. The PCI ontology was also extended in order to represent the content of fragments within a document with the datatype property pcicore:hasContent, and with the object property pcicore:isFragmentOf, which is also de ned as an inverse property
of pcicore:hasFragment. The latter two properties allow one to reference documents to its fragments, and vice-versa.
Each document is represented as a frbr:Manifestation. The keywords of the document are described with the datatype property pcicore:hasKeyword, and the related taxonomy concepts with the property dcterms:subject. Each fragment is represented as a pcicore:Fragment, and includes a reference to the document it belongs to through the property pcicore:isFragmentOf. The content of fragments are represented with pcicore:hasContent. Fragments have a type represented with the class pcicore:FragmentType. Each fragment may also have keywords (pcicore:hasKeyword), and be annotated with taxonomy concepts (dcterms:subject). The legal taxonomy concepts, which are described as instances of the class skos:Concept, provide linkable anchors both to entire documents and to smaller fragments. In this context, concepts are used to connect legal documents and textual pieces of supporting evidence within and across di erent documents.
As discussed in Section 1, the representation of legal information through knowledge graphs allows one to formulate complex questions. An example, which was stated in Section 1, is the question: "What are the documents in which a relation to a particular law concept, or a more speci c one, exists?". This question can be answered with the SPARQL query presented in Listing 1.1. Note that this query returns documents related to a speci c concept (in this case wkd-law:10046) at either the document or fragment level, and that the property skos:narrower is used to refer to more speci c concepts from the taxonomy ontology.
Listing 1.1. Example of SPARQL query PREFIX pcicore: <http://onto.wolterskluwer.com/pci/core/> PREFIX skos: <http://www.w3.org/2004/02/skos/core#> PREFIX wkd-law: <http://taxonomy.wolterskluwer.de/law/> PREFIX dcterms: <http://purl.org/dc/terms/> SELECT distinct ?document WHERE { BIND (wkd-law:10046 as ?concept) ?fragment a pcicore:Fragment; pcicore:isFragmentOf ?document. { ?fragment dcterms:subject ?concept . } UNION { ?fragment dcterms:subject ?narrower . ?concept skos:narrower ?narrower . } UNION { ?document dcterms:subject ?concept . }
UNION { ?document dcterms:subject ?narrower . ?concept skos:narrower ?narrower . } } 4
This section presents our use case requirements, which are de ned based on the XML documents schema and the proposed semantic model, together with a comparison between state-of-the-art semantic uplift engines applied to our use case.
Several approaches have been developed in the area of semantic uplift through
mapping languages. Mapping languages can be described as declarative
languages used to express customized mappings de ning how non-RDF data should
be represented in RDF [
In our case, the following requirements must be met by the semantic uplift engine in order to transform the XML les (Section 2) into the semantic data model (Section 3)10.
{ R1. Data format. This requirement is related to legal documents in our use case being stored as XML les, being also a common data format used in many applications. { R2. Data selection. This requirement is related to selecting speci c XML elements and attributes during the mapping process. We note that this includes the mapping of elements which contain other nested XML elements. { R3. Vocabulary independent. This requirement allows the mapping to be de ned using existing ontologies and vocabularies. { R4. Transformation functions. This requirement allows for values to be manipulated during the mapping process. For instance, in our use case, some elements in the XML documents contain string values that must be normalized in order to be represented in RDF. { R5. Multi-attribute mapping. This requirement is related to the XML les in our use case having a collection of value nodes that are mapped to one property in the RDF representation. { R6. Literal values to IRI. This requirement is related to IRIs being stored as literals in the XML documents, which are required to be transformed into valid IRIs in the RDF representation. 4.2
The following semantic uplift engines were compared when considering our use case. The rationale for selecting these being that, according to their speci cation, they would have support for our use case requirements.
XSPARQL. XSPARQL [
SPARQL-Generate. SPARQL-Generate [
RML-Mapper. R2RML11 is the W3C standardized mapping language for
de ning mappings of data in relational databases to the RDF data model. The
RML [
CARML. CARML12 is an engine which implements the RML mapping language, just like the described RML-Mapper. In this sense, CARML also supports the generation of RDF datasets from heterogeneous data formats. Transformation functions are also supported through the Function Ontology. 4.3
In order to compare these engines, a mapping expressing the transformations needed to convert the XML les, as described in Section 2, to the RDF semantic model described in Section 3 was created for each of these mapping engines. In order words, this comparison assesses if and how well such engines support the our use case requirements.
Table 1 shows the mapping engines being evaluated in our use case, their licenses, and the version used. A discussion on the support for each use case requirement is presented next.
R1. Data format. All the mapping engines presented have support for the conversion of XML les to RDF. XSPARQL uses XQuery, XPath and XSLT in order to access the information contained in XML les. The SPARQL-Generate, RML-Mapper and CARML engines rely on XPath expressions in order to access the data contained in XML les.
R2. Data selection. All of the mapping engines have support for selecting XML attributes. In order to select XML elements in XSPARQL one may use the XPath function text() or string(). The function text() returns a set of individual nodes contained in an XML element. For instance, if an XML element contains one nested XML element, then this function returns two nodes. The function string() returns the string value, or the string representation, of an XML element. In other words, an element with a nested element would return one string value containing the whole string within that XML element. The mapping engines SPARQL-Generate and RML-Mapper only allow for the selection of XML elements using the text() function, which means that instead of one string representation of an XML element the engine produces a set of literals for an ontology property. In our use case, this is problematic when mapping the content of fragments - represented in the XML les by an element, often containing nested elements { to the property pcicore:hasContent. CARML, on the other hand, allows for the selection of elements using both text() and 12 https://github.com/carml/carml string() functions. Thus, only XSPARQL and CARML fully support this requirement.
R3. Vocabulary independent. All the engines have support for this requirement, being expressive enough for the de nition of customized mappings. XSPARQL and SPARQL-Generate have a similar syntax based on SPARQL CONSTRUCT queries to de ne how the RDF triples are generated from XML les. The RML-Mapper and CARML engines rely on Triples Maps, which as stated previously, allows one to de ne how subjects, predicates and objects are generated from non-RDF source data.
R4. Transformation functions. XSPARQL partially supports data transformation functions, being limited to the expressiveness of SPARQL, XQuery, XPath and XSLT. SPARQL-Generate also partially supports data transformation functions, being limited to the ones supported in SPARQL 1.1. The RMLMapper and CARML approaches, as previously stated, fully support data transformation functions through the Function Ontology. In our use case, data transformation functions are required when mapping string values to literals where such values must be normalized and validated.
R5. Multi-attribute mapping. All of the engines support this requirement. The XSPARQL engine, however, has the word uri as part of its grammar. This word is also the name of an attribute in the XML les in our use case, which results in an error in the execution of the mapping.
R6. String values to IRI. All of the engines support this requirement. XSPARQL allows one to de ne an IRI from a string value by enclosing the variable representing the IRI with less (<) and greater (>) than symbols. SPARQLGenerate allows the same transformation through the SPARQL function URI. The RML-Mapper and CARML approaches allows such transformation by de ning an IRI term type to Term Maps.
Table 2 presents the support for each requirement by the mapping engines. CARML is the only engine with full support for all use case requirements (Section 2)13.
Mapping Engine R1 R2 R3 R4 R5 R6 XSPARQL ( ) ( ) SPARQL-Generate ( ) ( ) RML-Mapper ( ) CARML
Table 2. Mapping engines comparison. 5
This section presents an evaluation comparing the performance of two approaches applied to the semantic uplift of XML les. One approach utilizes RML mappings through the CARML engine, which, as discussed, is the only one with full means full support, while a (
) means partial support. support for our use case requirements. The second approach is an ad hoc custom parser developed to generate the same RDF representation from XML les.
The experiment was executed on a MacBook Pro 13" (3.1 GHz, i7, 16GB RAM), where both approaches would transform the same input into the same RDF representation. Each approach was executed 10 times considering 3 different datasets containing 1000 (1k), 10000 (10k) and 50000 (50k) documents. These datasets have been created by randomly selecting les from our use case which contains over 1 million documents. These were selected randomly in order to provide sets of documents with di erent characteristics (e.g. size). Table 3 presents the results of this experiment.
Performance 1k 10k 50k Comparison AVG STD AVG STD AVG STD Ad hoc custom parser 4.09 0.47 38.7 3.95 212.8 30.01 CARML 4.85 1.33 43.3 3.9 242.5 30.9
Table 3. Time performance results for 10 runs (in seconds).
These results show that the use of mappings, namely RML with the CARML engine, does impact performance. In order to assess whether these di erences are statistically signi cant we performed the Welch Two Sample T-Test with a signi cance level of 0.05. The results suggest no statistical signi cance between using an ad hoc custom parser and CARML for 1k documents (p-value of 0.12). However, for 10k and 50k documents the di erence in performance is statistically signi cant (p-values of 0.04 and 0.01, respectively). We do note that, even though the use of mapping languages impact performance, this is still the preferred approach for our use case. The reason being that mapping languages separate mapping de nitions from the implementations that execute them, allowing the process to be reused and shared. Furthermore, the maintenance of mappings is facilitated by the same reason when compared to an ad hoc parser. For instance, any changes in the semantic model or in the input data would require the mapping to be updated accordingly, without the need to change the engine responsible for the execution of the mapping. An ad hoc parser, on the other hand, would require the implementation, which is speci c to a certain use case, to be modi ed. Finally, implementations may be improved with optimizations and other choices of software libraries, which could be tailored to di erent use cases and thus positively impact performance. 6
The representation of legal information through ontologies have been the focus of several studies.
Ebenhoch [
Other studies have focused on investigating ontology design patterns in the
legal domain which are described together with examples [
In this paper, we have presented a semantic model for legal documents applied to an industrial use case. This use case comes from Wolters Kluwer Germany's company, where their legal information is stored as XML les. By taking into account the proposed semantic model and the XML's document schema we have de ned a set of requirements which should be met by the mapping engine in order for it to be able to produce the required RDF knowledge graph. We have also compared and discussed the use of four di erent state-of-the-art mapping engines based on our set of requirements. CARML, which implements the RML mapping language, was found to be the only one supporting all our use case requirements. Finally, we have also compared and discuss the use of CARML to developing ad hoc parsers for the process of transforming XML les to RDF.
In future work, we will further investigate the use of mapping languages in terms of its performance when considering large documents. Future work will also investigate the performance of the RDF knowledge graph based on queries, which may result in improvements on the semantic model, and in changes in the mapping.
This paper was supported by the Science Foundation Ireland (Grant 13/RC/2106) as part of the ADAPT Centre for Digital Content Technology (http://www. adaptcentre.ie/) at Trinity College Dublin.