The use of knowledge graphs is spreading in the scientific community across diferent domains, from social sciences to biomedicine. The creation of knowledge graphs usually needs the integration of multiple heterogeneous data sources in diferent formats and schemas. One common way to achieve this process is using declarative mappings, which establish the relationships between the source data and the ontology, improving relevant aspects such as maintainability, readability and understandability. Learning how to use and create mappings is not an easy task, hindering the use of this technology to anyone outside the area. As a result, this task is usually carried out by experts. To ease the mapping creation, several mapping editors have been developed, but their success is limited. In this paper, we devise the use of a well-known tool commonly used in the scientific community, the spreadsheets, to specify the mapping rules in a language-independent way. Our aim is to ease the mapping creation and make it more accessible for the community. We also show a real use case, in which using spreadsheets helps in the mapping creation process and enables a handy way for editing and visualizing mapping rules.
• Computing methodologies → Artificial intelligence ; Knowledge representation and reasoning. Knowledge graph, spreadsheet, declarative mapping
The expansion of the Semantic Web technologies has reached users
across several domains, such as legal and biomedical. An increasing
number of knowledge graphs from these areas are being created,
restructuring knowledge in a machine-readable way [
There are multiple approaches to create knowledge graphs, from
using ad-hoc tools to declarative mappings. The later defines rules
to establish relationships between the global schema and the data
sources. Examples of mappings languages are the W3C
recommendation R2RML [
The use of declarative mappings for semantic web non-experts
is often complicated. That is one of the reasons why the mapping
creation is usually carried out by knowledge engineers. This poses
a barrier for potential users from other domains. To face this issue,
several mapping editors have been proposed. They aim at making
the mapping creation and editing easier and more intuitive [
Mapping languages consist of common elements to be created
(e.g. the source data, subjects, predicates and objects). In this
paper we propose the use of spreadsheets to specify these elements,
the mapping rules, in a language-independent way, so it can be
translated into the most convenient specification [
This paper is organized as follows: Section 2 presents the related work done on mapping creation. Section 3 shows the common mapping structure. Section 4 describes the spreadsheet template we propose for the creation of mapping rules. Section 5 shows a real case in which we use spreadsheets to create mappings. Finally, section 6 presents the conclusions and areas for future work. 2
A wide variety of mapping languages has been proposed over the
last decades [
There are not as many mapping editors as languages; in fact, the
majority of them support R2RML or RML. Some of the most used
<P<PEERRSSOONN>>
rmr ml:lo:lgoigciaclaSlSouorucrece[ [
rmr ml:sl:osuorucrece"/h"/ohmome/eu/suesre/dr/adtaat/ap/epoepolpel.ec.scvs"v;" ;
rmr ml:rle:rfeefreernecnecFeoFromrmulualtaiotinonqlq:Cl:CSSVV; ;
];];
rrr:sr:usbujbejcetcMtMapap[ [
rrr:cr:lcalsas sexe:xP:Peresrosno;n;
rrr:tre:tmemplpaltaete"h"thtptt:p//:e//xe.xc.ocmom/P/Peresrosno/n{n/{anmame}e"};";
];];
rrr:pr:rperdeidciactaetOeObjbejcetcMtMapap[ [
rrr:pr:rperdeidciactaetMeMapap [ r[rr:cr:ocnosntsatnatnetxe:xn:anmamee];];
rrr:or:bojbejcetcMtMapap [ r[mr ml:rle:rfeefreernecnece"n"anmame"e]";];
];];
rrr:pr:rperdeidciactaetOeObjbejcetcMtMapap[ [
rrr:pr:rperdeidciactaetMeMapap [ r[rr:cr:ocnosntsatnatnetxe:xs:psoprotr]t;];
rrr:or:bojbejcetcMtMapap [ r[rr:pr:apraernetnTtrTiprilpelseMsMapap<S<SPPOORRT>T;>;
rrr:jro:jioniCnConodnidtiiotinon[ r[rr:cr:hcihldild"s"psoprot_rti_di"d;"r;rr:pr:apraernetn"tid"i"d;"];;];
];];
];];
(a) Triples Map for PERSON
<S<SPPOORRT>T>
rmr ml:llo:lgoigciaclaSlSouorucrece[ [
rmr ml:sl:osuorucrece"/h"/ohmome/eu/suesre/dr/adtaat/as/psoprotsrt.sc.scvs"v;" ;
rmr ml:rle:rfeefreernecnecFeoFromrmulualtaiotinonqlq:Cl:CSSVV; ;
];];
rrr:sr:usbujbejcetcMtMapap[ [
rrr:cr:lcalsasssexe:xS:Spoprot;rt;
rrr:tre:tmemplpaltaete"h"thtptt:p//:e//xe.xc.ocmom/S/Spoprot/r{ts/{psoprot}r"t};";
];];
rrr:pr:rperdeidciactaetOeObjbejcetcMtMapap[ [
rrr:pr:rperdeidciactaetMeMapap [ r[rr:cr:ocnosntsatnatnetxe:xn:anmame e]; ];
rrr:or:bojbejcetcMtMapap [ r[mr ml:rle:rfeefreernecnece"s"psoprot"rt]"; ];
];];
rrr:pr:rperdeidciactaetOeObjbejcetcMtMapap[ [
rrr:pr:rperdeidciactaetMeMapap [ r[rr:cr:ocnosntsatnatnetxe:xc:ocdoede]; ];
rrr:or:bojbejcetcMtMapap [ r[mr ml:rle:rfeefreernecnece"id"i"d;"];; ];
];];
(b) Triples Map for SPORT
tools implement graphical visualization and editing of the mappings
as graphs, such as Karma [
The current mapping editors are language-oriented or create the mapping rules through graphical visualization. Thus, the user either knows the language, or creates the mapping building a visual graph. Using spreadsheets enables a language-independent declarative approach to write concisely the mapping rules taking advantage of the functionalities of a spreadsheet. In other words, the rules can be created specifying only the essential elements without knowing any mapping language, and the repetitive elements can be autocompleted. Moreover, its compact structure allows a quick visualization of all the rules.
There are other approaches that use spreadsheets to capture
knowledge of domain experts [
3
The mapping languages have usually a similar structure, as many
of them are based on the standard. The earliest (e.g. R2O [
We define more in detail the essential elements that declarative mapping rules contain, providing examples based on the RML mappings showed in Figure 1: • An element that specifies where the data sources are stored.
In the case of RML, these elements are defined using the property rml:logicalSource. • A set of rules that defines the subjects and classes of the triples. In RML, the rr:subjectMap property is used to specify these characteristics. • Pairs (rr:predicateObjectMap property in RML) that specify rules for generating predicate (rr:predicateMap) and object (rr:objectMap) of the triples. • Join condition to another triple map, where the subject of the referenced triples map is to be the object in the new triple.
This is defined in RML using rr:joinCondition property.
As we show in the example mapping, these rules usually contain multiple and repetitive elements to describe the rules. This characteristic makes it easy to commit mistakes when writing them manually. Using a spreadsheet template can ease this process to non-experts in mapping creation. It enables manual writing, while helping with the repetitive parts with autocompleting functions. Moreover, all the language’s syntax and formatting is later automatically written by the tool, not the user. 4
In this section we show the designed spreadsheet template3 that contains the essential elements to create a mapping. It consists of at least four sheets: prefixes, source data, subject and predicate-object maps; and optionally, a sheet with transformation functions.
Prefixes sheet. In this sheet the namespace prefixes for URLs are specified. They can be found at the beginning in most of mapping languages, as they make it easier and shorter to write the mappings. This sheet is composed of two columns, in the column Prefix the prefix is defined, and in the column URI the whole link is written (Table 1).
Source sheet. Here we specify where the data is taken from (Table 2). It consists of three columns, ID, Feature, Value. The column Value contains path to the source data, the format, and optionally the iterator (the loop used to map the data of JSON and XML files). In Feature we declare the type of information provided in Value. Finally, ID refers to its correspondent subject in the Subject Sheet.
Subject sheet. The subjects of the triples to generate and their correspondent classes are defined in three columns (Table 3). In ID is specified an identifier for each subject so it can be referred from other sheets; in Class, the class which the subject belongs to; and in URI, the template for the URI of the subjects that are to be created. In the latest field, there is a variable part between curly braces that refers to a field in the data (in the first line, name, and in the second, sport).
Predicate-Object Maps sheet. In this sheet, the triples are deifned through the predicates and its correspondent objects (Table 4). The columns Predicate and Object are responsible for their specification. The kind of data declared in Object is defined in Data type (e.g. string, float, etc.). When there is a referencing object map, the triple is defined otherwise. There are three fields that are able to specify the join between the object of the new triple and the referenced subject. They specify which is the ID correspondent to the subject to join (ReferenceID), and the fields of the source data they share (InnerRef for the field of the current triple, and OuterRef for the field of the referred subject). These fields are left blank until this case happens. When it does, the aforementioned fields referring to the object are not necessary (Object and Data type). The last item to specify is which subject each triple belongs to. For that purpose the column ID exists. It links each predicate-object to its correspondent subject.
Function sheet. Some languages support the use of transformation functions over the data (e.g. FnO+RML), so the template allow to include an additional sheet to detail these functions (Table 5). The most used are the SQL and GREL functions, but any can be used. The functions are referred from the Predicate Object map sheet or other function row with the identifier specified in FunctionID. The function to use is defined in Function, and the parameters in Params (if there are several, they are written separated by commas). 5
Bio2RDF [
In this use case, we create mappings for the datasets of the project that have their data published as CSVs and relational databases. With the information provided by the PHP sripts and the source data, the mapping rules are specified in the spreadsheets. Then, they are translated into the most suitable mapping language depending on the format of the data source, and which engine is used to build the knowledge graph. In this specific case, we translate them into R2RML for relational databases and RML for CSVs.
For most of the data sources more than one subject is created, or the database is distributed in several files, or there is a high number of triples (predicate-object maps) to generate. Moreover, there are joins between the subjects within the same and in others datasets. The need to represent so many mapping rules arises the necessity to visualize them quickly, and write the repetitive parts of the mappings easily, which can be done thanks to the structure and functions of the spreadsheets. Moreover, the fact that the spreadsheets are an intermediate step in the mapping creation process makes it possible to write the transformation rules only once, and translate it into one or more languages. The tool developed to perform the translation, Mapeathor, is still under development, and
(DataType), the references to other subjects (ReferenceID, InnerRef, OuterRef) and the subject that forms the triple (ID). ex:name ex:birthdate ex:sport ex:name ex:code ex:comment
Object {name} {birthdate} {sport}
{id} <Fun1> string date string integer
sport from the source data. <Fun1>
sql:upper
{sport} it is available in GitHub4, along with the spreadsheets mappings created for this use case. 6
This paper shows a first approach to design a template spreadsheet able to specify the mapping rules used to create knowledge graphs. The full design is described in detail to show all the essential elements contained in a mapping file that can be specified in a spreadsheet in a language-independent manner. Moreover, we present a real use case in which the use of spreadsheets has facilitated the mapping construction and editing.
Both the template spreadsheet and tool developed to translate the spreadsheets to diferent mapping languages are still under development. Our objective is to keep on improving the template’s structure in order to erase the existing influence of the current mapping languages, and make it language-independent. For that purpose, it’s necessary to make a design able to contain the essential information to express the mapping rules, and take for each language the necessary elements in the translation.
Moreover, an evaluation has to be carried out to test that using spreadsheets really helps in the mapping creation process, and give some guidelines on how the template can be improved. The tool has to be developed as well, as the template changes, with the aim of being able to translate the spreadsheets to any mapping language.