A large portion of structured data does not yet reap the bene ts of the Semantic Web, or Web 2.0, as it is not semantically annotated. In this paper, we propose a system to generates semantic knowledge, available on DBPedia, from common CSV les. The \Tabular Data to Knowledge Graph Matching" competition, consisting of three di erent subchallenges, was used to evaluate the proposed methodology.
? Both authors contributed equally to this work of the les contained a corresponding ground truth of annotations, allowing only for unsupervised learning approaches to be applied.
1946 Roussillon Grand Prix Maserati 4CL
CPA 1946 Nice Grand Prix Alfa Romeo 308 1946 Marseille Grand Prix
Maserati 1937 San Remo Grand Prix Maserati in motorsport 1935 Italian Grand Prix
Alfa romeo in motorsport CEA
France France France Italy Italy
H. Louveau R. Sommer E. Platé P. Dusio R. Dreyfus
CTA We designed a system to solve these three challenges directly. Our system consists of six phases as visualised in Figure 2. First, crude annotations are made for each cell in the table by generating multiple candidates and disambiguating them by using string similarities on the cell values and the rdf:label of each candidate. Afterwards, the column types and properties between columns are inferred using these cell annotations. In a fourth step, the inferred column types and properties are used to create more accurate head cell annotations (the cells in the rst column of a table). Phase ve uses the new head cells to correct the other cells in the table, using the property annotations. Finally, in phase six, new column types were inferred using all the available corrected cells. The code for this system is written in Python and is made available online1. In the following section, detailed information of each phase is provided. The pipeline used to annotate single cells, during an initial phase, is depicted in Figure 3. For each of the cell values, we rst clean them by retaining only the part that comes before a `(' or `[' and by removing all `%', `"', and `n' characters 1 https://github.com/IBCNServices/CSV2KG (clean cell). Then, we check whether http://dbpedia.org/resource/<X> exists where <X> is simply the cleaned cell value with spaces replaced by underscores (try url). Parallel with this, the cell value is provided to the DBPedia lookup API to generate more candidates (DBPedia lookup). As no column type annotations are available yet during this initial phase, we do not provide this additional information. If both the DBPedia lookup and the try url step did not result in any candidates, the DBPedia Spotlight API is applied. In the end, a large pool of possible candidates remain. On this pool, we apply disambiguation by selecting the candidate of which its rdf:label has the lowest Levenshtein distance to the actual cell value. After annotating the di erent cells, we can query the di erent types for each of these annotations in the same column and count these. Based on these counts, the goal is to nd now the most speci c class that matches the entities in the cell. It is important to note that the entities on DBPedia are not guaranteed to be complete or are annotated correctly (e.g. Barack Obama, and not Donald Trump, is still the president of the U.S.A according to DBPedia at the time of writing in August 20192) and Shaquille O'Neal his musical endeavours, such as being a rapper and DJ, are not entirely in there3). This makes the inference step far from trivial. Merely taking the type with the highest count, where ties are 2 http://dbpedia.org/page/President_of_the_United_States 3 http://dbpedia.org/page/Shaquille_O'Neal broken by the type that has the highest depth in the hierarchy, would mostly result in a very generic annotation such as Thing.
Since the classes of the DBPedia ontology form a hierarchy, they can be represented in a tree. We can now traverse this tree and apply majority voting (i.e. taking the child with the highest count) on each level of this tree. We continue recursively until the entropy of the two highest counts of its children is lower than a speci ed threshold. The entropy is thus de ned as:
H(t) = H(sort(fcount(c) j c 2 children(t)g)[ 2 :])
(
As the maximum score that could be achieved per target column was not bounded by one, we boosted our score by adding all parents in the hierarchy to each column annotation, excluding Thing and Agent. Moreover, classes that were equivalent according to the DBPedia ontology (e.g. Location and Place) were added to the collection of annotations per target as well. Column type information can in uence the DBPedia cell lookup as visualised in Figure 3. Therefore, the initial cell lookup was executed again with newly available column information. 2.3
The cell annotations are used to annotate the properties or relations between pairs of columns. To do this, we iterate over cell pairs from two target columns between which we want to infer the relation. Then, for each of these cell pairs (s; o), we query for all predicates p from the DBPedia ontology that exists between these two entities: fp j (s; p; o) 2 DBP ediag. Finally, the predicate that can be found the most between the cell pairs is chosen. To break possible ties, the domain and range of all inferred column types were taken into account from the using a simple query: SELECT ?domain ?range WHERE { <pred> rdfs:domain ?domain .
<pred> rdfs:range ?range . with <pred> a possible predicate between the two target columns. So in the case of relationships with equal highest counts, we check the range and domain using the column types. When the range and domain of multiple relationships are valid possibilities, we take the relationships with the most speci c range and domain column type (using depth(domain) + depth(range)). 2.4
After obtaining the column type and property annotations, we can create more accurate cell annotations. All properties giving information about the head cells (the cell in the rst column of a table) are updated by using the following query:
with <pred> the predicates found in Section 2.3 between the head and nonhead columns and <value> the cell value of the non-head column as inferred in Section 2.1. For each row in our table, these queries will result in several possible head annotations, and the annotation with the highest count was returned. In the case of an ex aequo, the Levenshtein distance on the rdf:label was used. 2.5
With the corrected head cell annotations, a similar query can be used to correct all the other cells in the table row by row:
with <pred> the predicates found in Section 2.3 between the head and non-head columns and <head> the cell value of the head column as inferred in Section 2.4. Multiple answers are possible when more than one values are annotated with a corresponding property. Levenshtein distances between the rdf:label and raw cell value were used to disambiguate the results. 2.6
The method from section 2.2 was executed again, but with all new information of the cells. 3
Some additional elements were provided to boost both the execution and accuracy of our annotation system: { When names such as G. Vandewiele, B. Steenwinckel were detected, DBPedia lookup was performed given the Person class type, and only the last name was given to the API as a search key. Code was used to check the distance between the cell value and the candidate persons. { The CTA challenge score was not bounded to 1, so all the parent column annotations were added as well. { Reasoning was used to nd equivalent classes, and these were also added as possible results for the column types. { Some tales were very similar, and majority voting was used on possible similar tables to correct some of the column types. { Each phase of the pipeline in gure 2 was parallelized, making it possible to evaluate large amounts of CSV les in a limited amount of time. 4
In total, four di erent metrics were used to evaluate the system. On the one hand, we had the F1-score, which is a harmonic mean of the precision and recall of our system: precision = recall = During the second round, a new metric was introduced for the CTA challenge. An annotation was regarded as perfect if it was the most speci c class to which all the cells in the column complied to. An annotation was okay if it was an ancestor of the actual perfect annotations in the DBPedia hierarchy of classes. Based on these two concepts, the primary average hierarchical (AH) and secondary average perfect (AP ) score were de ned:
AH = AP = #perfect + 0:5 #okay
jtarget cellsj
#perfect
#annotations
#wrong
(
In this paper, a system to convert a CSV le of raw, structured data to semantic knowledge. The system consists of six phases: three initial annotation phases for all target cells, the types of columns and the properties between columns. A fourth and fth phase over the target cells utilises the newly inferred properties to create more accurate annotations and a sixth phase which uses all new cell information to improve the column types. The proposed system is rather straight-forward while already achieving promising results. As future work, we would like to improve the system by taking additional resources into account, such as other data sources or embedded values of the occurring triples. Moreover, machine learning systems could be interesting as well but would require a ground truth.