In this paper, we describe Semantic Table Interpretation using LOD4ALL. LOD4ALL is an LOD search engine developed by Fujitsu laboratories. This engine crawls Linked Open Data from the Web and provides a high-speed search service. There are many tabular data on the Web, and these data are important sources of Knowledge Graphs. Therefore, we have enhanced a crawler that is a component of LOD4ALL for taking in these tabular data. This crawler is able to construct Knowledge Graphs to a tabular data. To evaluate of the function of this crawler, we have participated in the challenge \Semantic Web Challenge on Tabular Data to Knowledge Graph Matching".
1.1
Presentation of the system
1.2
In this section, we describe the overview of our proposed approach in the
following ve steps:
Step 1 Extract candidate entities
Step 2 Resolve an entity type
Step 3 Determine a column type
Step 4 Determine an entity for each cell
Step 5 Extract a relationship of entities for each row
Our proposed approach is similar to that of Efthymiou et al.[
Step 1 Extract candidate entities
Step 2 Resolve an entity type
Step 3 Determine a column type
Step 4
Determine an entity for each cell
Step 5 Extract a relationship of entities for each row
RDF store Score DB Keyword store
Step 0 Build Score DB
Step 0 Build Keyword store
Input/output Output Result
Reference Step 0: Build Databases Step 0 builds some databases for a predict on. Our proposed approach can only build these from a target Knowledge Graph. Therefore, our approach does not build predicted databases using annotated tables like T2Dv21. Our approach has two databases. One is the Score DB to resolve CTA task in the challenge. Another is the Keyword Store for Step 1.
In DBpedia, an entity has some classes. For example, dbr:Barack_Obama
has dbo:Person, dbo:Politician, and dbo:President. For recognizing a more
detailed class, we have adopted Okapi BM25[
Step 1-2 Keyword search: We have enhanced the literal search function of
LOD4ALL that can retrieve subjects that have rdfs:label, foaf:
name, foaf:surname and foaf:givenName in the triple. Further more,
we have added keywords for a person that combines a rst
character, the object value corresponding to foaf:givenName, \." and the
object value corresponding to foaf:surname. Through this
enhancement, we can retrieve dbr:Barack_Obama from the cell value of \B.
Obama". In addition, a similar string search step has been added. We
have adopted SimString[
Step 1-3 Output candidate entities: To Output in order of highest TOP-K score. We have set 100.0 for the score of an entity found by Direct search, and set a value multiplying the Elasticsearch's score and the SimString's score for the score of an entity that have found by Keyword search.
The ow of this step is Fig. 2 Step 2: Resolve an entity type In this step, classes for each entity are obtained from the Score DB. This process is similar to those in to previous studies.
Step 3: Determine a column type In this step, estimating a column type (CTA result) using candidate entities extracted in Step 2 and the Score DB. This step consists of the three following steps: Step 3-1 Calculate a cover ratio
RDF store Keyword store
Step 1-1
Step 1-2 SimString
DB
Input a cell value
Direct search
Not found
Not found partial match partial match extended keywords
using SimString DB
Hit Hit Hit
Candidate entities
Step 1-3
Filter TOP-k
Candidate entities result Step 3-2 Search a class score from the score DB Step 3-3 Calculate a predict score using both a score ratio and a class score
We illustrate the running example of Step 2 and Step 3 using a part of the \List of residences of Presidents of the United States#Summer White House#0.csv" in Round2 in Fig. 3. We have set Step 1's K as 1 in this gure to explain easily. In this gure, our approach outputs dbo:President as the result of this step. Step 4: Determine an entity for each cell In this step, we determine an entity for each cell that has the class (the column type) determined in Step 3 from candidate entities that extract by Step 1. The output of this step is the result of the CEA task.
Step 5: Extract a relationship of entities for each row In this step, we rst collect candidate predicates using entities determined in Step 4 by executing SPARQL (Listing 1.1) to RDF store. %URI1% and %URI2% in SPARQL are replaced entities determined in Step 4. Next, by calculating a frequency, we obtain the predicate of the greatest frequency. The output of this step is the result of the CPA task.
We illustrate the running example of the Step 5 in Fig. 4.
Listing 1.1. SPARQL query used the Step 5 PREFIX dbr :
<http :// dbpedia . org / resource /> select distinct ? predicate where {
% URI1 % ? predicate % URI2 % } Class
Cover ratio dbo:Person dbo:Politician dbo:President dbo:OfficeHolder 1.0 0.8 0.8 0.2 average score per a class (STEP3-2) 0.23 1.31 5.17 1.95
Predict score 0.23 1.05 4.14 0.39
Get TOP-1 class
dbo:President %URI2% We designed predict score functions for Step 3 through trial and error. The best result in our trial is Equation 1. Here, the normalizedClassScore is the class score that has scaled between 0 and 1. and are hyperparameters.
P redictScore = normalizedClassScore + ratioScore (1) In our experiment, by setting =1.2 and =2.5, the system has output the best of results. In Step 1, the top k number is K=10, and the similarity parameter for SimString is 0.7. 1.4
Link to the system and parameters le We plan to publish our modules in the GitHub2 . 2
2 https://github.com/lod4all/semanticTableInterpretation Round1 Round2 Round3 Round4
CTA CEA CPA CTA CEA CPA CTA CEA CPA CTA CEA
CPA
Round4 (After closing) CTA
CEA
CPA 3
General comments In these challenge datasets, there were several cases where it was difficult to determine the column type in the CTA task. One of them is shown in Fig. 5. This table is the ranking of Forbes Korea Power Celebrity in 20123. We found this in the Round2 dataset. The Name column in this table may be assigned dbo:Person and dbo:Group. It is difficult to determine a unique column type for CTA task. To deal with this case, we believe it is necessary to ues an evaluation method that allows multiple perfect annotations for a column. 4
In this paper, we described Semantic Table Interpretation using LOD4ALL. Our
proposed approach is still in the early stages, so there are a lot of problems to
be resolved. In the future, we will improve the accuracy of collecting candidate
entities in Step 1 and the prediction process in Step 3 in these problems in
particular. Further more, we will improve our system by developing an ensemble
approach between our approach and others. For CTA task, we believe it is
necessary to improve DBpedia. For example, we will assign a class to an entity that
has not been assigned a class by adopting Fang's method[
Beast* 10
Park Tae-Hwan