Nowadays, Knowledge Graphs (KG) are among the most powerful mechanisms to represent knowledge and integrate data from multiple domains. However, most of the available data sources are still described in heterogeneous data structures, schemes, and formats. The conversion of these sources into the desirable KG requires manual and time-consuming tasks, such as programming translation scripts, defining declarative mapping rules, etc. In this vision paper, we analyze the trends regarding the automation of KG construction but also the use of mapping languages for the same process, and align the two by analyzing their tasks and a few exemplary tools. Our aim is not to have a complete study but to investigate if there is potential in this direction and, if so, to discuss what challenges we need to address to guarantee the maintainability, explainability, and reproducibility of the KG construction.
A lot of works on knowledge graph (KG) construction are focused on defining mapping languages
to declaratively describe the transformation process, and on optimizing the execution of such
declarative rules. The mapping languages rely on either dedicated syntaxes, such as the family
of languages around the W3C recommended R2RML1 (e.g., RML [
Despite the plethora of mapping languages and the increasing number of optimizations
for the execution of the declarative rules, these rules are still defined through a manual and
time-consuming process, afecting negatively their adoption. Diferent solutions were proposed
to automate the definition of mapping rules that describe how a KG should be constructed.
CEUR
Workshop
Proceedings
On the one hand, MIRROR [
Beyond relational databases, the recent SemTab challenge4 presents a set of tabular datasets [
In this vision paper, we align tasks followed by solutions for the automation of the semantic
table annotation with concepts of existing declarative solutions. We indicatively select and
analyze a few tools for the automation of KG construction and identify common steps. We
discuss whether they can be declaratively described relying on existing mapping languages, and
what the challenges are to proceed in this direction. We consider the RDF Mapping Language
(RML) [
Our objective is not to present a complete study but to investigate if there is potential in this direction. By describing the steps followed by diferent solutions in a more fine-grained and standard manner, we make the steps comparable, and we can better discuss what challenges we need to address to guarantee the maintainability, explainability, and reproducibility of the KG construction, as well as to ensure the provenance of each performed task.
We analyze the diferent steps of the SemTab challenge, inspect the relationship between the SemTab challenge tasks, and align them with concepts from the declarative construction of RDF graphs (Figure 1). To achieve this, we include the relationship between each of the tasks and their potential declarations within a mapping language. We consider the RML mapping language because it is commonly used and the authors are more familiar with it, but we are confident that the other mapping languages could express the same concepts. Before we proceed with the alignment, we give a small introduction on the SemTab challenge and RML: SemTab challenge The SemTab challenge consists of three tasks: (i) cell to KG entity matching (CEA), which matches cells to individuals; (ii) column to KG class matching (CTA), which matches cells to classes; and (iii) column pair to KG property matching (CPA), which captures the relationships between pairs of columns.
CEA
Col0
Col1
Col2 Union Depot
Spier & Rohns
RML The RDF mapping language (RML), a superset of the W3C recommended R2RML,
expresses schema transformations from heterogeneous data to RDF. An RML mapping contains
one or more Triple Maps which on their own turn contain a Subject Map to generate the subjects
of the RDF triples, and zero or more Predicate Object Maps with pairs of Predicate and Object
Maps to generate the predicates and the objects respectively for each incoming data record. RML
was aligned with the Function Ontology (FnO) [
We analyze how the diferent tasks of the challenge contribute in constructing a part of an RDF triple, and we align these tasks with the corresponding concepts of the RML mapping language that construct the same part of an RDF triple.
Cell-Entity Annotation (CEA): This task identifies the URI of an entity from a cell. In the target RDF graph, this is the subject or the object of the RDF triple. In Fig. 1, the Col0 values are used to obtain the subjects of the triples while the Col3 values generate the objects (both green colored in the RDF extract of Fig. 1). If a declarative approach is considered to generate these triples, for example in RML, the rr:subjectMap property is used (line 5 of RML doc in Fig. 1), which declares how the subjects of the triples are generated and the rr:objectMap (line 8 of RML doc in Fig. 1), when the expected objects are in the form of URIs.
Column-Type Annotation (CTA): This task predicts the common class of a set of items given a column from the table. SemTab assumes that a table only generates one kind of entity (i.e. the first column is used for CTA). In Figure 1, we can observe that the URIs retrieved using Col0 are considered for obtaining the corresponding shared concept (i.e., restaurant) (red colored in the RDF extract of Fig. 1). Declaring the class in RML can be done through the shortcut rr:class property within the rr:SubjectMap or using a rr:predicateObjectMap with a rdf:type fixed predicate (line 7 of RML doc in Fig. 1).
Columns-Property Annotation (CPA): This task aims to predict the property that relates the CTA column (subjects) to the rest of the columns. Fig. 1 shows a CPA task that relates Col0 with Col3 through the property architectural style (wdt:P149, yellow colored in the RDF extract). In RML, the predicates of the triples are declared using the rr:predicateMap property (line 8 of RML doc in Fig. 1), and unlike typical mapping rules, where it is usually assumed that predicates are constants (as they are declared in the input ontology), the predicates depend on the data, hence they are dynamically defined.
Based on the aforementioned analysis, we conclude that the tasks performed to automate the KG construction can be aligned with concepts from declarative mapping languages. The CEA task is aligned with the RDF term construction for the subject or the object of the RDF triple, the CTA task assigns the class and the CPA task aligns with the Predicate and Object Map.
In this section, we analyze in detail the steps performed by some of the tools proposed for solving the SemTab challenge. The comparative analysis among the three selected engines (summarized in Table 1), is not meant to be exhaustive. We aim to identify if there are common steps and functions that the engines perform to accomplish the challenge’s tasks and ultimately if it is possible and desired to declaratively describe them with mapping languages.
We indicatively selected the systems that: (i) obtained good results in the SemTab 2021
challenge5; and (ii) have the source code openly available. Therefore, we included in this comparison
JenTab [
JenTab6 participated in SemTab 2020 and 2021, and it was always positioned among the top ifve solutions for most rounds. It follows a heuristic-based approach proposing the CFS (Create, Filter, Select) approach for all tasks and with diferent configurations and workflows.
MTab7 participated in all SemTab editions, winning the first prize in 2019 and 2020. Apart from the support of multilingual datasets, MTab implements several approaches for performing the entity search (i.e. CEA): keyword search, fuzzy search, and aggregation search8.
MantisTable V9 is an extended and improved version of MantisTable [
The systems we inspected follow the same steps: they perform a preprocessing step, and setup lookup and datatype prediction services. Then the CEA task is performed followed by the CTA and CPA tasks which depend on the CEA task. Given that the systems follow the same steps, we could map the three main tasks (CEA, CPA, CTA) to the Create-Filter-Select (CFS) procedure proposed by JenTab (see Table 1).
We observe similarities in most tasks among the engines. The subtasks performed in the preprocessing step, are very similar in the three engines. Preprocessing tasks include several functions, such as fixing encoding issues, removing HTML tags or special characters, and detecting missing white spaces (see Table 1), and they usually delegate them to third-party libraries (e.g., ftfy 10). We observe similar tasks are performed when declarative solutions are used for cleaning and preparing the data. These preprocessing tasks are described with FnO in the case of RML and executed either together with the schema transformations or as a preprocessing task too.
The same occurs for the datatype prediction, where regular expressions are often used to detect if cell values are entities or literals, and what type of literals (string, date, or numbers). In the case of declarative solutions, this datatype inspection task is performed manually. However, adjusting the datatype is possible by relying on functions for data transformations.
Most of them also incorporate a lookup step to retrieve the necessary data from the KGs (e.g.,
using SPARQL queries), including similarity functions or fuzzy search. The search engine for
the KG lookups in JenTab and Mantis V is ElasticSearch, although the former implements the
Jaro Winkler distance [
As far as the actual tasks are concerned, each engine performs its own approach for the CEA,
CTA, and CPA tasks, although we also find some similarities. The most important ones that
are implemented in the three engines are: (i) the Levenshtein distance [21] to filter candidates
and (ii) the majority vote (called frequency in Mantis V) to select the final annotations. We
believe that the use of declarative approaches, such as the Function Ontology [
Fix encoding Special characters Preprocessing Restore missing spaces Remove HTML tags Remove non-cell-values Datatype
We identify a set of challenges to be addressed to declaratively describe solutions for automatic KG construction. These challenges can be divided into two categories: technical and conceptual.
On the technical side, there is a major diference between the solutions for the automation of
KG construction and the execution of declarative KG construction solutions: The solutions for
automatic KG construction rely on iterative processes that continuously refine and improves a
task, while the diferent tasks influence each other. To the contrary, the declarative KG
construction is a linear process that is executed only once. Not all declarative rules are executed linearly,
solutions that restructure [
Besides the overall execution process, the iteration patterns are diferent. The solutions for automatic KG construction are applied to all directions, both per column and per row, and even combined. To the contrary, the declarative solutions are applied only per row, and the mapping languages are designed under this assumption. Should the mapping languages be extended to support more iteration patterns? If so, would the rml:iteration for RML and the relevant constructs in the other mapping languages be suficient or more adjustments are required?
The solutions for automatic KG construction rely on interrelated tasks which may produce intermediate representations, e.g., probabilistic methods, and their results impact the rest tasks. The declarative KG construction solutions then need to deal with dynamic and recursive steps (e.g., intermediate representation of the input data sources and mapping rules, multiple function execution, etc.) that can negatively impact the generation process. Hence, declaratively describing is a challenge. Should the mapping languages be further extended then?
On the conceptual side, there are two major diferences with respect to the training data and target KGs. In most real projects, the input data and sometimes the target ontology are only provided, but there is neither similar data to train the solutions nor existing KGs to target that can be used to find entities or to predict the relationships. In the past, alternative approaches for KG construction were discussed depending on what is available where the process starts (e.g., data, ontologies, target KGs), but it is not investigates neither how these editing approaches afect the KG generation nor its automation. How are the automated solutions proposed for the SemTab but not only afected by the lack of training data and target ontologies and KGs. How does this afect their declarative representation?
While relying on ontology matching techniques between existing KGs (e.g., DBPedia, Wikidata) and the target ontology or exploiting NLP approaches between ontology and input sources documentation could be a solution for the latter, would it be realistic given that most ontologies are not aligned and not all of them provide documentation?
In this paper, we analyze the KG construction solutions and compare the automatic with the declarative. While the tasks can be aligned with respect to what they achieve, their execution is fundamentally diferent and a direct alignment is not feasible.
Automatic solutions for KG construction are required to facilitate the adoption of KGs, but there are also merits when the automation tasks are declaratively described, with respect to maintenability, sustainability, and reproducibility. However, directly aligning the automatic solutions with the declarative solutions might be technically and conceptually challenging considering their diferent execution and iteration patterns. Extending the existing mapping languages would be a solution, but it would also require to address the identified challenges and not only. Would such extensions be feasible and desired or would they lead them beyond their purpose? Although, mapping languages are not the only approach to have declarative descriptions. Declarative descriptions of workflows emerge as well. Would that be a more viable solution? If so, would the automatic and declarative solutions keep on growing in diferent directions? These are questions that would be nice to reflect and discuss during the workshop.
David Chaves-Fraga is supported by the Spanish Minister of Universities (Ministerio de Universidades) and by the NextGenerationEU funds through the Margarita Salas postdoctoral fellowship. Both authors are supported by Flanders Make. [20] S. Jozashoori, A. Sakor, E. Iglesias, M.-E. Vidal, EABlock: A Declarative Entity Alignment Block for Knowledge Graph Creation Pipelines, in: Proceedings of the 37th ACM/SIGAPP Symposium On Applied Computing, 2022. [21] V. I. Levenshtein, et al., Binary codes capable of correcting deletions, insertions, and reversals, in: Soviet physics doklady, volume 10, Soviet Union, 1966, pp. 707–710. [22] G. Haesendonck, W. Maroy, P. Heyvaert, R. Verborgh, A. Dimou, Parallel RDF generation from heterogeneous big data, in: Proceedings of the International Workshop on Semantic Big Data, 2019, pp. 1–6. [23] J. Arenas-Guerrero, D. Chaves-Fraga, J. Toledo, M. S. Pérez, O. Corcho, Morph-kgc: Scalable knowledge graph materialization with mapping partitions, Semantic Web (2022).