In recent years we have observed an increasing interest by the scienti c community, from social sciences to biomedicine, in the generation and publication of RDF-based knowledge graphs. One possibility for creating knowledge graphs consists in using declarative mappings together with their associated parsers. These mappings describe the relationship between the source data and a reference ontology. However, the learning curve to create these mapping les is steep, hindering its use by a wider community. In this paper we present a user-friendly mappinglanguage-independent tool, Mapeathor, to declare transformation rules based on spreadsheets and translate them into two di erent mapping languages with the purpose of easing the mappings creation process.
In the last few decades, we have seen a signi cant increase in the publication of data in a machine understandable manner following Linked Data principles1 (e.g., DBpedia2, Wikidata3). Knowledge Graph construction requires integrating di erent data sources in a structured way, usually following the schema of an ontology or group of ontologies. This facilitates the posterior task of mining the knowledge graph with several applications, such as searching recommendations and learning implicit data patterns.
Knowledge graphs can be built in diverse ways. One option is creating ad-hoc
scripts to transform data, which requires the user to repeat the process of script
Copyright c 2020 for this paper by its authors. Use permitted under Creative
Commons License Attribution 4.0 International (CC BY 4.0).
1 https://5stardata.info/en/
2 https://wiki.dbpedia.org/
3 https://www.wikidata.org/
writing in every speci c use case. Another option is using tools like
OpenRene4 to perform data transformation through the creation of an RDF skeleton,
which includes proprietary transformation rules and a functionality for
knowledge graph construction. Lastly, there is an option to keep the transformation
rules in speci c les that can be later processed by engines that either transform
the data to RDF or create a virtual knowledge graph that can be queried
without transforming the source data. These rules can be written in a wide variety of
languages (e.g., R2RML [
Since mapping languages started to be used by the community, there have
been multiple approaches for the development of editors to ease their speci
cation. Most of them enable editing through graphical visualization [
Our work focuses on providing a straightforward way to create these
mappings, specifying the transformation rules in spreadsheets, so they are later
translated into one of the implemented mapping languages. The purpose of this
proposal is to increase the interoperability between these languages [
This paper is structured as follows: Section 2 describes the design of the spreadsheet. Section 3 explains the functionalities of the tool and a real-world use case. Finally, section 4 presents the main conclusions and future work. 2
The rules required to generate a knowledge graph can be speci ed in multiple languages. The language is chosen by the user depending on the speci c use case. However, the rules themselves are equivalent across languages, so they can be written in a language-independent way, in this case, we chose a spreadsheet for
(a) Prefix sheet Prefix URI noise http://vc.coiundt-aadceussaticbaie#rtas.es/ noise- http://v.ciudadesabiertas.es/res/ res cont-acustica# sosa http://www.w3.org/ns/sosa/ (c) Source sheet
Station query SEFLREOCMT Sidt,antiaomne Observation source data/station.json
(d) Predicate_Object sheet
Station dcterms:identifier Station schema:name
Station geGoespoamreqtl:rhyas Observation sosa:resultTime Observation sosa:madeBySensor Observation sosa:observedProperty <Fun1> (b) Subject sheet
ID
Observation noise:Observacion
noise:EstacionMedida noise-res:estacionmedida/{id} noise-res:observa cion/{idx} (e) Function sheet
<Fun1> fno:executes <Fun1> ex:param1 <Fun1> ex:param2 <Fun1> ex:param3
grel:replace {obsProperty} “ ” “-”
{id} string {name} string npouinsteo-/r{eids}: iri {resTime} Time
Station {madeBySensor} {id} 3 rule speci cation. The spreadsheet template is devised to contain the rules in a compact and understandable way, in a format widely used by the scienti c community. The design is aimed to be language-independent and to ease the writing process so the user does not have to learn a mapping language. In addition, the functionalities of a spreadsheet editor can be used to speed up the writing process. Reusing mappings for similar use cases is also easier in this speci cation format. The spreadsheet contains the mapping essential elements structured in ve di erent sheets: Pre x, Source, Subject, Predicate Object and Function.
Pre x sheet: This sheet contains the namespaces and corresponding prexes used when declaring the transformation rules (Figure 1a). It is composed of two columns: Prefix for the pre x and URI for the corresponding namespace.
Subject sheet: This sheet de nes the subjects to be generated and the key ID that links the information in the sheets (Figure 1b). It is organized in three columns: ID, Class and URI. URI de nes the template URI for the subject, its class is speci ed in Class. ID contains a unique identi er for each subject's set of rules in order to relate to information on these rules in the remaining sheets.
Source sheet: Here we specify where the data is retrieved from (Figure 1c). The information is organized in three columns: ID, Feature and Value. Feature declares the type of information provided in Value. In Value it can be speci ed the path to the source data (with the feature source), the format (format ), the iterator (iterator, loop used to map the data from JSON and XML les), database table (table), SQL query (query) and SQL version (SQLVersion). Any language option may be included. Finally, ID indicates the rule it refers to.
Predicate Object sheet: This sheet de nes the triples through the predicates and its correspondent objects (Figure 1d). The columns Predicate and Object specify the predicate and object in a rule. The XSD datatype of Object @@@ppprrreeefffiiixxx rrxrms: dl<::h<<ththpttt:tp/p/:w:////swwewwm.www.3we.bo3.r.mgo/rmngs/l2a/r0b20.rbm1e/lX/#nM>s./LrmScl#h>e.ma#>. [<P#rOefbixseesr]vation> @@@@pppprrrreeeeffffiiiixxxx snqnoloo:sii<ssaeeh::-t<rt<pehh:st/tt:/ptsp<e:/:h//mw/tvtwp.wc:ew/iu/bv.d.w.mca3idum.eodlsraagadb/be.nbisseea/rs/tbnaoisses/.arqet/als>#s/.>c.e.osn/tr-easc/ucsotnict-aa#c>u.stica#>. ]r;mrrrmmml:llllo:::irstgeeoifcrueaarrtceloSenroc""ude$raF"c;toear/m[stualtaiotino.njsqoln:J";SONPath; <]]]]]rrrrr#;;;;;rrrrr.rrrrrrrrrrS:::::rrrrrrrrrrlspppo::::::::::tutcssoppooprrrageeeelqqbrrrbbbtaimeeedddiclljjjjoseVQeeedddiiiapcccscnccceiiiulaaalcccSttttra>neMMMMaaatttsoteeeoreitttayaaaoueeeOOOisppppnr"MMM"bbbecn"[rjjje:aaa"oeee[[[rESppp:icccrrr[sSsErmmttte:tMMMQ[[[taL-lle::rrrrcELaaarrmrrreeei:::2pppCoscccffp0nee:oooT[[[el0Mrrannnseei8tdsssetennattt,daaaccc"nieennnndiaotttoa""mnsgdiin;sd-cceeame"htom;e-FeesrrreeRrmdpm:s"idaOd;as:arpar:M:qntriu/da:l{a:dneitShdmyatnaot}ptate"sa/ei;{tfGtiii]oydex;epn}rs"oe"d];";m:"rxsr;es:ttrdteirn:yrsgm]t;r]Tinygpe] rr:IRI] ]]]]rrrr;;;;rrrr.]rrrrrrrrra::::;rrrrrrrrrsppprr:::::::::rrruttcopopoprrrr::eeeeelbjp:rrrbbbaorSmeeedddjajjjmseieeedddiiiunrpcccscccceTiiibCaaalcccttttaynnjMMMMaaatttoeteeeptoetttcnTaaaaeeeOOOeitsdrpppp"MMM;ibbberniptr[jjj:aaaiol:eee[[<oOeIpppiRcccr#nssbmttteFMIMMMs[[[;-l[ue:rrraraaarrnrrrerepr:::pppv1s:cccfcae:>ooo[[[ohcrnnnbieilsssodsntttneaaac";rennnmv<ttta"#sssarceSooodisosssteaTnaaaBti/:::imy{romoieSdbneasxse>"du}e;n;"letrrs;TrvBo:eidymrd"aS;ePtearrrn]to;:yspppoaeerrre]tx;yns]td;":iTdi"m;]e;] (a) Triple map for Station (b) Triple map for Observation [Prefixes] <#Fun1> a rr:TriplesMap; fanfmnlm:ful:nFcutniocntiVoanlTueerm[Map; rml:logicalSource [ rml:source "data/station.json"; ];rrrm:pl:rreedfeicraetnecOebFjoercmtMulaaptio[n ql:JSONPath rr:predicate fno:executes ; ];rr:objectMap [ rr:constant grel:replace ] rr:predicateObjectMap [ rr:predicate ex:param1 ; ];rr:objectMap [ rml:reference "obsProperty"] rr:predicateObjectMap [ rrrr::oprbejedcictMataepe[xr:pr:acroanmst2an;t " " ] ]; rr:predicateObjectMap [ rr:predicate ex:param3 ; ].];rr:objectMap [ rr:constant "-" ] (c) Triple map for Fun1 is de ned in DataType. When the object refers to a subject de ned in another rule, the rule is written di erently. There are three elds that allow the speci cation of the linking condition between the object of the triple and the referenced subject. They specify which is the ID of the target subject (ReferenceID), and the "join" elds in the source data (InnerRef for the eld of the object of the current triple, and OuterRef for the eld of the referred subject). Lastly, the column ID indicates the rule it belongs to.
Function sheet: Some languages are able to process transformation functions over the data (e.g. FnO+RML), which can be detailed in this sheet (Figure 1e). Some well known options are the SQL and GREL functions, but any option can be used. The functions are referred in the Predicate Object sheet or in other function rows with the identi er speci ed in FunctionID. The column Feature is used to specify the type of information provided in Value, where the name of the function and the value of the parameters are written. 3
The spreadsheet containing the transformation rules is processed by the tool
Mapeathor to create a mapping le. For example, Figure 2 depicts the mapping
le written in the RML language that results when translating the rules in
Figure 1. Currently, this tool translates Google spreadsheets and XLSX les to
the following languages: the W3C recommendation R2RML [
Currently, Mapeathor is being used to generate mappings for city open data publication related to tra c, public bus transport, budget and noise pollution in the context of the Ciudades Abiertas project. Six spreadsheets have been completed, containing 31 subjects and 104 predicate-objects rules. The process of spreadsheet completion and mapping creation for the languages implemented will be shown in the demo with data from this real-world use case. 4
This paper presents Mapeathor, a tool able to translate transformation rules speci ed in spreadsheets to three di erent mapping languages. The key part of the work are the spreadsheets containing the mapping rules, since they are designed to facilitate the speci cation process for the user. Currently, the tool is being tested in several use cases from the Ciudades Abiertas project.
The purpose of this work is to create a framework to declare in a user-friendly manner the transformation rules in a language-independent way and to be able to generate these rules in any mapping language. Future work includes a user study to test the usefulness of this tool and nd guidelines for improvement, extend the tool to cover more languages, and implement changes that make rule speci cation more user-friendly.
Acknowledgements. The work presented in this paper is supported by the Spanish Ministerio de Econom a, Industria y Competitividad and EU FEDER funds under the DATOS 4.0: RETOS Y SOLUCIONES - UPM Spanish national project (TIN2016-78011-C4-4-R).