In this paper, we present our system Kepler-aSI, for the Semantic Web Challenge on Tabular Data to Knowledge Graph Matching (SemTab 2022). This system is participating for the second time in this challege edition, bringing improvements and new technical aspects. Kepler-aSI analyzes tabular data to be able to detect correct matches in Wikidata and Dbpedia. It should be noted that each data resource, or each round of the challenge imposes a certain number of constraints, requiring advanced techniques. The aforementioned task turns out to be dificult for the machines, which requires an additional efort in order to deploy the congenitive capacity in the matching methods. Kepler-aSI [1, 2, 3, 4] still relies on the SPARQL query to semantically annotate tables in Knowledge Graphs (KG), in order to solve the critical problems of matching tasks. The results obtained during the evaluation phase are encouraging and show the strengths of the proposed system.
(Comma-Separated Values)). The main reason for the popularity of this format is its simplicity:
many common ofice tools are available to facilitate their generation and use. Tables on the
Web are a very valuable data source. Thus, injecting semantic information into arrays on the
web has the potential to boost a wide range of applications, such as web searching, answering
queries, and building Knowledge Bases (KB). Research reports that there are various issues
with tabular data available on the Web, such as learning with limited labeled data, defining
or updating ontologies, exploiting prior knowledge, and / or scaling up existing solutions.
Therefore, this task is often dificult in practice, due to missing, incomplete or ambiguous
metadata (e.g., table and column names). In recent years, we have identified several works that
can be mainly classified as supervised (in the form of annotated tables to carry out the learning
task) [
This year’s SemTab challenge difers from the last two sessions 1 2, in that it deals with Wikidata and Dbpedia. In this challenge, the input is a CSV file, but three diferent challenges had to be met : 1. CTA : A type of the Wikidata (or eventually Dbpedia) ontology had to be assigned a class KG to a column (Column-Type Annotation ). 2. CEA : A Wikidata or Dbpedia entity had to be matched to the diferent cells (Cell-Entity
Annotation). 3. CPA : A KG (Wikidata or Dbpedia) property had to be assigned to the relationship between two columns (Columns Property Annotation).
Data annotation is a fundamental process in tabular data analysis [
Our goal is to design a fast and eficient approach to annotate tabular data with entities from Wikidata or Dbpedia. Our approach combines a multitude of NLP and search and filter strategies, based on text preprocessing techniques. Experiments carried out in the context of SemTab 2022 for all tasks have shown encouraging results.
In this section, we will describe in detail the diferent stages of our system, while presenting some basic notions to highlight the technical issues identified. 2.1. Key notions • Tabular Data : is a two-dimensional tabular structure made up of an ordered set of N rows and M columns, as depicted by Figure ??. is a row of the table (i = 1 ... N), is a column of the table (j = 1 ... M). The intersection between a row and a column is , , which is a value of the cell , . The table contents can have diferent types (string, date, lfoat, number, etc.).
– Target Table (S): M × N. – Subject Cell: (,0) (i = 1, 2 ... N). – Object Cell: (,) (i = 1, 2 ... M),(j = 1, 2 ... N).
Col0 1 ⎛ 1,0
⎜⎜ ⋮⋮ ⎜ ,0 ⎜ ⋮ ⎜ ⋮ Row ⎝ ,0 … ⋱ ⋱ … ⋱ ⋱ …
Col … ⋱ ⋱ , ⋱ ⋱ … … ⋱ ⋱ … ⋱ ⋱ …
Col 1, ⎞
⋮⋮ ⎟⎟
, ⎟
⋮ ⎟
⋮ ⎟
, ⎠
• Knowledge Graph : Knowledge Graphs have been in the focus of research since 2012,
resulting in a wide variety of published descriptions and definitions. The lack of a common
core, a fact that is also indicated by Paulheim [
As shown in Figure 2 Preprocessing aims to prepare the data inside the considered table. While Annotation Context, seeks to create a list of terms denoting the same context.
It should be noted that the content of each table can be expressed according to diferent types and formats, namely: numeric, character strings, binary data, date/time, boolean, addresses, etc. Indeed, with the great diversity of data types, the pre-processing step is crucial. Therefore, the goal of preprocessing is to ensure that the processing of each table is triggered without errors. The efort is especially accentuated when the data contains spelling errors. In other words, these issues must be resolved before we apply our approach. In order to well carry out this step, we used several techniques and libraries such as (Textblob3, Pyspellchecker4, etc.) to rectify and correct all the noisy textual data in the considered tables. As an example, we detect punctuation, parentheses, hyphen and apostrophe, and also stop words by using the P a n d a s 5 library to remove them. Like a classic treatment in this register, we ended this phase by transforming all the upper case letters into lower case.
This phase allows to explicitly extract the candidates for the annotation process. The priming is carried out by a processing columns analysis, which aims to understand and delimit the set of regular expressions which contains a set of units: the area, the currency, the density, the electric current, the energy , flow rate, force, frequency, energy eficiency, unit of information, length, density, mass, numbers, population density, power, pressure, speed, temperature, time, torque, voltage and volume. This step allows to identify multiple Regextypes using regular expressions (e.g. numbers, geographic coordinates, address, code, color, URL). Since all values of type text are selected, preprocessing for natural languages was performed using the l a n g r i d 6 library to detect 26 languages in our data. By the way, it’s a novelty for this year’s SemTab challenge, i.e., which makes the task more dificult with the introduction of natural language barriers. The l a n g r i d library is a stand-alone language identification tool. It is preformed on a large number of languages (97 currently). Doing so, correction, data type and language detection is performed. This can considerably reduce the efort and the cost of executing our approach by avoiding the massive repetition of these treatments for all the table cells, and this in each subtask.
As depicted by Figure 3, the task is to annotate each entity column with elements from Wikidata (or possibly Dbpedia) as its type identified during the preprocessing phase.
Each item is marked with the tag in Wikidata or Dbpedia. This treatment allows semantics identification. The CTA task can be performed based on Wikidata or Dbpedia APIs which allows us to search for an item according to its description. The main information collected about a given entity and used in our approach are: a list of instances (expressed by the i n s t a n c e O f primitive and accessible by the P31 code), the subclass of (expressed by the s u b c l a s s O f primitive and accessible by code P279) and overlaps (expressed by the p a r t O f primitive and accessible by code P361). At this point, we are able to process the CTA task using a SPARQL query. The SPARQL query is our interrogation mean fed by the main information of the entity which governs the choice of each data type, since they are a list of instances (P31), of subclasses (P279) or a part of a class (P361). The result of the SPARQL query may return a single type but for some cases the result is more than one type, so in this case no annotation is produced for the CTA task.
The CEA task aims to annotate the cells of a given table to a specific entity listed on Wikidata or Dbpedia.
Figure 4 gathers the CEA task that can be performed based on the same principle of CTA task. Our approach reuses the results of the CTA task process by introducing the necessary modifications on the SPARQL query. If the operation returns more than one annotation and since we are conducting a fuzzy search [22, 23], we run a process based on examining the context of the considered column, relatively to what was obtained with the CTA task, to overcome the ambiguity problem.
After having annotated the cell values as well as the diferent types of each of the considered entities, we will identify the relationships between two cells appearing on the same row via a property using a SPARQL query, as flagged by Figure 5. Indeed, the CPA task look for annotating the relationship between two cells in a row via a property. Similarly, this latter task can be performed in an analogous manner to the CTA and CEA tasks. The only diference in the CPA task is that the SPARQL query must select both the entity and the corresponding attributes. The properties are fairly easy to match since we have already determined them during CEA and CTA task processing.
In this section we will present the results of Kepler-aSI for the diferent matching tasks in the 3 rounds of SemTab 2022. These results highlight the strengths of Kepler-aSI with its encouraging performance despite the multiplicity of issues. 3.1. Round 1 In this first round, and for this version of SemTab 2022, three tasks are presented: CTA-WD, CEA-WD and CPA-WD. The column type annotation (CTA -WD) assigns a Wikidata semantic type (a Wikidata entity) to a column. Cell Entity Annotation (CEA-WD) maps a cell to a KG entity. Annotation should be represented by its full IRI, where case is not sensitive. Each line should include a column identified by a table ID and a column ID, along with the column annotation (a Wikidata item). This means that a row must include three fields: ” Table ID”, ”Column ID”, and ”IRI Annotation”, where: • ”Table ID” is the filename of the table data, but does not include the extension. • ”Column ID” is the position of the column in the input, starting from 0, i.e., the ID of the ifrst column is 0. • ”IRI annotation”: the prefix of h t t p : / / w w w . w i k i d a t a . o r g / e n t i t y / instead of h t t p s : / / w w w . w i k i d a t a . o r g / w i k i / which is the URL prefix of the Wikidata page.
When it comes to associating a cell with an entity on the Knowledge Graph, the task is to annotate each target cell with an entity from Wikidata. Each annotation must contain the target cell annotation. A cell can be annotated by an entity with the prefix http://www.wikidata.org/entity/. Each CTA annotation must contain the annotation of a cell identified by a table identifier, a column identifier and a row identifier. Namely, an annotation must have four ifelds: ” Table ID”, ”Row ID”, ”Column ID” and ”Entity IRI ”, where: • ”Table ID”: does not include the filename extension; and removing the .csv extension from the filename. • ”Column ID”: is the position of the column in the table file, starting from 0, i.e. the ID of the first column is 0. • “Row ID”: is the row position in the table file, starting from 0, i.e. the first row ID is 0. • ”Entity IRI ”: the prefix of h t t p : / / w w w . w i k i d a t a . o r g / e n t i t y / instead of h t t p s : / / w w w . w i k i d a t a . o r g / w i k i / which is the URL prefix of the Wikidata page.
As for the annotation of column properties by Wikidata (CPA-WD), it consists in annotating the relations between the columns in a table with the properties of Wikidata. Each annotation must contain the two-column annotation which is itself identified by a table identifier, a first column identifier and a second column identifier. Namely, a row must have four fields: ” Table ID”, ”Column ID 1”, ”Column ID 2” and ”Property IRI ”. Each pair of columns must be annotated by at most one property, as follows: • ”Table ID” does not include filename extension • ”Column ID 1”, ”Column ID 2”, is the position of the column in the table file, starting from 0, i.e. the first column ID is 0. • ”Property IRI ”: prefix of h t t p : / / w w w . w i k i d a t a . o r g / p r o p / d i r e c t / instead h t t p s : / / w w w . w i k i d a t a . o r g / w i k i / which is the URL prefix of the Wikidata page. of
It should be noted that the CTA-WD, CEA-WD and CPA-WD task data contains 3691 tables. Results are summarized in Table 1: 3.2. Round 2 Round 2 includes 3 main families of tests, the results of which are summarized in Table 2: • HardTables (HT-WD): represented by 4649 tables; • ToughTablesR2-WD (2T-WD): represented by 114 tables; • ToughTablesR2-DBP (2T-DBP): represented by 114 tables.
APrecision 3.3. Round 3 Round 3 includes 3 main families of tests, metrics are in Table 3: • GitTables schema: represented by 45 tables; • GitTables DBP: represented by 6898 tables; • Bio-Div-Tables: represented by 45 tables.
Round 3
0.781 0.534 AF1 0.731 0.534 — —
3/7 4/7
In Round 3, we realized that there were significant amounts of entity duplication in our result. Thus, the pairing process has been improved by adding the following features. First, spell checking of misspelled sentences was used. However, approaches based on relishing content duplications can achieve results without column duplication. In order to overcome duplicate columns, We used Fuzzy matching in pandas to detect duplicate rows (eficiently). In fact, FuzzyWuzzy is an implementation of edit distance, which would be a good candidate for constructing a pairwise distance matrix in numpy or similar. To detect ”duplicates” or close matches, We have to compare each row to the other rows or We will never know if two are close to each other
To conclude, we have presented in this paper the second version of our Kepler-aSI approach. Our system is participating in the challenge for the third time, it is approaching maturity and achieving very encouraging performance. We have succeeded in combining several strategies and treatment techniques, which is also the strength of our system. We boosted the preprocessing and spellchecking steps that got the system up and running.
In addition, despite the data size, which is quite large, we managed to get around this problem by using a kind of local dictionary, which allows us to reuse already existing matches. Thus, we realized a considerable saving of time, which allowed us to adjust and rectify after each execution. We also participated in all the tasks without exception, which allowed us to test our system on all facets, i.e., to identify its strengths and weaknesses.
In this paper, we presented our contribution to the SemTab2022 challenge, Kepler-aSI. We tackled the several proposed tasks. Our solution is based on a generic SPARQL query using the cell contents as a description of a given item. In each round, despite the time allocated by the organizers running out, we continued the work and the improvements, having the conviction that each efort counts and brings us closer to the good control of the studied field.
Demos, SuCCESS) 48 (2016) 1–4. [21] M. Färber, F. Bartscherer, C. Menne, A. Rettinger, Linked data quality of dbpedia, freebase, opencyc, wikidata, and yago, Semantic Web 9 (2018) 77–129. [22] H. Akremi, S. Zghal, Dof: a generic approach of domain ontology fuzzification, Frontiers
Comput. Sci. 15 (2021) 153322. [23] H. Akremi, M. G. Ayadi, S. Zghal, To medical ontology fuzzification purpose: Covid-19 study case, Procedia Computer Science 207 (2022) 1027–1036.