Modeling domain knowledge as Linked Data is not straightforward for data publishers, because they are domain experts and not Semantic Web specialists. Most approaches that map data to its semantic representation still require users to have knowledge of the underlying implementations, as the mapping definitions remained, so far, tight to their execution. Defining mapping languages enables to decouple the mapping definitions from the implementation that executes them. However, user interfaces that enable domain experts to model knowledge and, thus, intuitively define such mapping definitions, based on available input sources, were not thoroughly investigated yet. This paper introduces a non-exhaustive list of desired features to be supported by such a mapping editor, independently of the underlying mapping language; and presents the rmleditor as prototype interface that implements these features with rml as its underlying mapping language.
In recent years, the Web is evolving from the Web of Documents, to the Web
of Data, where data can be interlinked (Linked Data [
Since data publishers are not developers or Semantic Web experts, the
mapping definitions authoring should be decoupled from their execution. To this end,
research has been conducted to define mapping languages, e.g., r2rml [
Nevertheless, besides knowledge of the underlying mapping language,
manually editing and curating definitions requires a substantial amount of human
effort [
Most existing tools with a gui follow a step-by-step workflow [
In this paper we introduce a non-exhaustive list of desired features, independent of any underlying mapping language. They are addressed by a uniform mapping editor which aims to support data publishers to model domain-level knowledge. We implement such an editor, the rmleditor, to offer these features to data publishers. Currently, the rmleditor supports specifying mapping definitions for tabular-structured data, e.g., databases or data in csv format. The underlying mapping language is the rdf mapping language (rml).
The remainder of the paper is structured as follows. We elaborate on related work in Section 2. Next, the desired features are listed in Section 3. In Section 4, we describe the rmleditor and we end with conclusions and future work in Section 5. 2
Editing mapping definitions independently of their execution requires
abstracting them from their execution. Different mapping languages were defined in the
past for this purpose. However, in most cases they are tightly coupled to a single
format. For relational databases, besides the w3c-recommended r2rml [
While guis are being built on top of mapping languages, such as the
fluidOps editor [
Earlier efforts to provide a gui for mapping definitions editing lead to tools
which allow users to include semantic annotations with the input data. An
example is OpenRefine2, which was originally focused on cleansing and transforming
data. It allows to interlink data with other data by using web services and to
upload the cleaned data to a central database. The rdf Refine3 [
Next to visualizing the editing of mapping definitions, a number of tools
impose restrictions on the workflow followed by the user. Sengupta et al. [
Pinkel et al. [
approaches. In another work of ours, we generalized these approaches to
schemadriven and data-driven, and introduced the model-driven and result-driven
approaches [
Another tool that uses a step-by-step workflow to set up the mapping process is TopBraid Composer5. It is a Semantic Web modeling tool that facilitates the automated conversion of spreadsheets or Unified Modeling Language (uml) files into rdf. Similarly, a wizard application6 to create mapping definitions for rml, uses a step-by-step workflow. However, in both cases, knowledge of the underlying mapping language is required, just like with the fluidOps editor. In both case, the workflow follows steps similar to directly editing a mapping document.
Last, Scharffe et al. [
An rdf mapping editor aims to support data publishers to model domain-level knowledge as Linked Data using the, prevalent for this scope, rdf data model. To achieve this, an editor should support publishers in creating and editing mapping definitions to acquire the desired rdf representation, independently of the original state of the data. Below, we introduce a list of desired features to be supported by such a mapping editor.
Independence of mapping language Domain experts acting as data publishers are not Semantic Web experts. To model domain-level knowledge via mapping definitions, an editor should allow to edit them without confronting publishers with the syntax of the mapping editor’s underlying language. For instance, a visualization for the definitions can be provided for modeling domain knowledge. The editor will interpret the visualization as statements in the language’s syntax. 5 http:// www.topquadrant.com/ tools/ modeling-topbraid-composer-standard-edition/ 6 http:// pebbie.org/ mashup/ rml 7 http:// datalift.org/ Multiple data sources Data that is required to model domain-level knowledge might be derived from multiple data sources. Hence, mapping editors should support data publishers in defining mapping definitions referring to multiple data sources at the same time. For instance, two csv files contain information about employees and projects. Connecting employees to their corresponding projects is only possible when definitions can be specified across the two files. Heterogeneous data formats Mapping editors should not restrict data publishers from accurately modeling domain-level knowledge because of the original data format. They should rather enable editing mapping definitions independently of the source data format. For instance, information about the different teams in a company might be available via an xml file. Connecting the aforementioned employees to their corresponding team is only possible when definitions can be specified across the xml and csv files.
Multiple ontologies and vocabularies Different ontologies and/or vocabularies, which model complementary or overlapping aspects of domain-level knowledge, are available. Hence, mapping editors should support data publishers in defining mapping definitions that annotate data with multiple ontologies and/or vocabularies at the same time. For instance, publishers should be able to provide information about people using the FOAF8 ontology, and add their corresponding bibliographic information using the Bibliographic Ontology9. The desired result could be 1 <www.example.com/person/jd> a foaf:Person; 2 foaf:firstName "John"; 3 foaf:lastName "Doe". 4 <www.example.com/journal/1> a bibo:Journal; 5 bibo:editor <www.example.com/person/jd>.
Multiple alternative modeling approaches Mapping editors should enable
and support multiple alternative modeling approaches [
Non-linear workflows Modeling domain-level knowledge involves multiple factors – data, schema(s) and mapping definitions – that have an influence on each other. A linear workflow separates these factors and obscures their relationships, by using ordered steps that need to be followed by the data publishers. Nonlinear editing allows publishers to keep an overview of the mapping model and its relationships. For instance, when adding the semantic annotations to the model, publishers might find that the data of certain column of a csv file is missing in the model. The non-linear workflow allows to integrate that data into the model without the need to redo (parts of) the mapping process. Independence of execution Editing mapping definitions lies beyond the scope of their execution. Thus, mapping editors should be able to export the set of mapping definitions, specified by the data publishers, through the user interface. As a result, further processing or execution, outside the mapping editor, improves the definitions’ interoperability and reusability. For instance, when the definitions are created locally using an editor, they can be executed on a server without further need of the editor. 4
In this section, we introduce our rmleditor. First, we discuss its underlying language rml. It is used because it is a mapping language that can express uniform mapping definitions on top of heterogeneous data. Thus, rml can express what data publishers define via the editor interface (see Section 4.1). Then, we elaborate on the Graphical User Interface of the rmleditor (in Section 4.2), based on the desired features. Next, we describe how data publishers interact with the rmleditor (in Section 4.3), followed by how the mapping definitions are interpreted as rml statements (in Section 4.4). Last, we elaborate on how each desired feature is supported by the rmleditor (in Section 4.5). A screencast demonstrating the rmleditor can be found at http:// rml.io/ RMLeditor . 4.1
RDF Mapping Language (RML)
rml [
The location of the file is specified by rml:source. Because it is a CSV file, we use the correct reference formulation using rml:referenceFormulation. Next, the subject of the rdf triples is determined by the Subject Map, where rr:template explains how the iri is constructed. In the example the value of the ‘Identification’ column is used. The class of subject is determined by rr:class. In the example, the class is set to foaf:Person. 1 <#PersonMapping> 2 rr:subjectMap [ 3 rr:template "http://www.example.com/person/{Identification}"; 4 rr:class foaf:Person ].
Using the column ‘Name’ (via rrmlreference in an Object Map), the family name of a person (foaf:familyName) can be added via rr:predicate to a Predicate Object Map. This results in 1 <#PersonMapping> 2 rr:predicateObjectMap [ 3 rr:predicate foaf:familyName; 4 rr:objectMap [ 5 rml:reference "Name" ]].
The rmlprocessor10 can be used to apply the mapping definitions on the source data. It is integrated in the rmleditor to support the execution of definitions.
rml was chosen because it can implement all desired features that are related to the underlying mapping language. Currently, it is the only language that offers uniform mapping definitions and natively supports multiple and/or heterogeneous data sources. Using the interface with a mapping language that does not support multiple and/or heterogeneous data sources would restrict data publishers from using all their available data. 4.2
There are four aspects that contribute when modeling knowledge: (i) the input data, (ii) the schemas, (iii) the mapping definitions and (iv) the resulting semantic representation. This is translated in the gui of the rmleditor to three different panels: (i) the Input Panel, (ii) the Modeling Panel and (iii) the Results Panel. The first panel shows a sample of each input data source, the second panel allows data publishers to edit the mapping definitions, including the used schemas, and the third panel displays the resulting dataset. These three panels are aligned next to each other as shown in Figure 1. Additionally, (re)loading the sources and editing the definitions can occur independently and interchangeably. 10 https:// github.com/ RMLio/ RML-Processor
When creating a gui to provide a visualization for ontologies, a common
approach is the use of graphs [
In the Modeling Panel, the references to the data (i.e., the column names in the case of databases, or header names in the case of csv files), are entwined together with information about their class or datatype, represented by the nodes. The edges represent the properties that connect two types of data. By doing so, we adhere as much as possible to the vowl specification. For instance, as shown in Figure 2, people (visualized as a node; represented by the column ‘Identification’; Figure 2a) of the class foaf:Person are connected to their family name (visualized as a node; represented by the column ‘Name’; Figure 2b) by the property foaf:familyName (visualized as an edge; Figure 2c). Similarly, people are connected to their given name (using the property foaf:givenName; represented by the column ‘Given Name’) and gender (using the property foaf:gender; represented by the column ‘Gender’).
Having different panels in the rmleditor allows data publishers to follow different approaches when generating mapping definitions. For instance, data publishers can first use the Input Panel to begin the modeling. Nodes (Figures 2a and 2b) can be added by right-clicking on a column and selecting New Resource for adding a resource or a blank node, or New Literal for adding a literal, with an optional datatype and language annotation. The result of this action is a new
List. 1. RML statements node in the Modeling Panel on which further mapping actions can be performed, e.g., add its class if it is a resource or its datatype if it is a literal. The Node contains a reference to the corresponding data fraction. As data publishers are not restricted to a single source, nodes might be generated from any of the input sources.
Alternatively, data publishers can use the Modeling Panel directly to edit the mapping definitions. Right-clicking on an empty location on that panel allows to create a new Resource Node (Figure 2a), Literal Node (Figure 2b) or Edge (Figure 2c), by clicking on New Resource, New Literal or New Edge, respectively. As soon as a Node is created, data publishers can associate it with the source data and further edit its semantic annotations, namely, edit its class, datatype, language and base iri. If an edge is created, publishers can set the predicate used to define the relationship between two nodes. As most entities in the resulting dataset have the same base iri, the rmleditor allows publishers to define the base iri and, optionally, the corresponding prefix, in the Modeling Panel.
The rmleditor allows data publishers to execute the mapping on either the sample or the complete input data. For the sample input, this is done by clicking on the Run Mapping button in the toolbar. The resulting rdf dataset is visible in the Results Panel. A part of the mapping definitions is sufficient to have a first idea of the resulting dataset. This allows to easily detect errors early in the mapping process. Thanks to the fact that the panels are aligned next to each other, errors can be directly addressed using the Model Panel. When data publishers want to use their complete screen estate to work on the modeling, they can easily hide the other panels thanks to the Hide Input Panel and Hide Results Panel buttons in the toolbar. When the mapping definitions are complete, data publishers are able to export the mapping definitions.
The fact that the rmleditor provides the possibility to simultaneously present all panels, allows to visualize the relationships between the different elements of the panels. To be more precise, when a node on the Modeling Panel is associated to a data fraction, that fraction is highlighted in the Input Panel. 4.4 Interpreting Graphical Mapping Definitions as RML Statements The mapping definitions modeled in the Modeling Panel are translated into rml statements, which can then be further processed or executed using the rmlprocessor. Below, we explain how the definitions in Figure 2 are interpreted as the rml statements in Listing 1 (a detailed explanation of the statements can be found in Section 4.1).
First, the Resource Node (Figure 2a) is interpreted as a Subject Map (Listing 1a) and based on this, a Triples Map (<#PersonMapping> in Listing 1) is formed. The Subject Map will generate the subject of the triple. The class foaf:Person is interpreted as a class statement, using rr:class. The iri of the resource is created based on the value of the ‘Identification’ column of each person, as defined by rr:template of the Subject Map.
Next, the Literal Node representing the (family) name of the person (Figure 2b) is translated to an Object Map (Listing 1b), which specifies how the object of a triple is generated. Subsequently, the Edge that states that the person and its name are connected with foaf:familyName (Figure 2c) is translated to a Predicate Map. A Predicate Object Map (Listing 1c) associates each Object Map to its Predicate Map. When a Resource Node is connected to another Resource Node, a Referencing Object Map is formed for the current Triples Map and another Triples Map is formed having the latter Resource Node as its Subject Map. An independent Literal Node is not possible.
Finally, as seen in Listing 1d, a Logical Source defines the source of the data (via rml:source) and how the source is referenced (via rml:referenceFormulation) based on the data format, which in the example’s case is csv. This information is derived from the Input Panel.
The GUI of the rmleditor implements the desired features of Section 3. Below, we will elaborate on each feature how it is facilitated. A summery of which features are supported by which panels can be found in Table 1. Independence of mapping language The challenge is to abstract the mapping definitions from the syntax, namely the underlying mapping language. The Modeling Panel achieves this by visualizing the definitions using graphs (Section 4.2). When the definitions need to be executed on the input data, the graphs are interpreted as rml statements (Section 4.4). Additionally, when implementing the rmleditor, we used modular programming. Thus, a new module can be added to use another mapping language to interpret the model. Multiple data sources Multiple data sources are visualized in the Input Panel, using a tab to represent each data source. A tab will contain a sample of the data. When data publishers add an new source, a tab will be added to the panel. Heterogeneous data formats Each tab of the Input Panel will visualize the data source in a way that is best suited for the format of the data. Currently, only tabular data, e.g., data in databases or in csv format is supported by the rmleditor. However, new modules can be added to offer new or other visualizations for different formats.
Multiple ontologies and vocabularies Using the Modeling Panel, publishers can set the class of a resource node or the datatype of a literal node. They are not restricted to which ontologies or vocabularies can be used, and they can be changed at any time during the mapping process. The rmleditor aids publishers in finding appropriate classes, datatypes and properties. In order to achieve that we integrated the use of Linked Open Vocabularies (lov)11. Prefix.cc12 is used to help publishers in looking up namespaces of the used schema(s). Multiple alternative modeling approaches By using three panels, data publishers can decide, based on their current need, which approach they prefer to follow. By first creating nodes based on the data in the Input Panel, publishers are able to apply the data-driven approach. By first defining a model, described by an ontology, in the Modeling Panel, publishers can subsequently associate the input data with the different elements of the model, as described by the schema-driven approach.
Non-linear workflows By showing the three panels simultaneously, data publishers have an overview of the mapping process. Thus, editing different elements of the process can be done in the corresponding panel without the need for tracing back previously completed steps. 11 http:// lov.okfn.org/ dataset/ lov 12 http:// prefix.cc/
Independence of execution At any point during the mapping progress data publishers are able to export the mapping definitions as rml statements, as facilitated by the Modeling Panel. Subsequently, the definitions can be edited and/or executed without the need of the rmleditor. 5
In this paper, we present a set of desired features to be considered during design and implementation of a uniform mapping editor. By doing so, data publishers, who are domain experts, are able to model knowledge derived from heterogeneous data. The proposed editor, the rmleditor, offers these features, using rml as its underlying mapping language. The rmleditor’s interface is implemented based on separate panels, which are aligned next to each other.
Modeling domain-level knowledge with Linked Data is a task that should be performed by data publishers, who are domain experts, rather than Semantic Web specialists. There are four aspects that contribute to this modeling: (i) the input data, (ii) the schemas, (iii) the mapping definitions and (iv) the resulting semantic representation. Mapping editors and their guis should enable data publishers to build their model on top of any of them, while incorporating nonlinear workflows and multiple approaches. These workflows and approaches give publishers the freedom to use the editor as it best fits the problem at hand. In order to achieve that, designing an interface with multiple panels, as the one proposed and implemented in the rmleditor, seems to be an adequate solution.
Moreover, the modeling should be detached from the syntax of the underlying mapping language and/or the format and number of input sources. In the rmleditor, the Modeling Panel, which uses a graph visualization for the mapping definitions, allows this detachment.
In the future, we will add support for non-tabular-structured data to the rmleditor. We will conduct an analysis to determine which mapping definitions generation approaches need to be supported by the rmleditor. Last, evaluation based on user study, is planned to validate the rmleditor.
Acknowledgements The described research activities were funded by Ghent University, iMinds, the Institute for the Promotion of Innovation by Science and Technology in Flanders (IWT), the Fund for Scientific Research Flanders (FWO Flanders), and the European Union.