Canonicalizing Knowledge Base Literals
Table 3: Overall typing performance of our method and the baselines on S-Lite and R-Lite.
['Methods with Their Settings', 'Methods with Their Settings', 'S-Lite Precision', 'S-Lite Recall', 'S-Lite F1 Score', 'R-Lite Precision', 'R-Lite Recall', 'R-Lite F1 Score']
Results for two optimum settings are reported for each method. The baseline Entity-Lookup retrieves one or several entities using the whole phrase of the literal, and uses their classes and super classes as the types. It stops as soon as some classes or entities are matched. We extend its original “exact entity match” setting with “relaxed entity match” which means multiple entities are retrieved. Property Range Estimation gets the classes and super classes from the entity objects of the property, and calculates the score of each class as the ratio of entity objects that belong to that class. (H/ I, κ, ⋅)@top-P (F1) denotes the setting where the highest Precision (F1 Score) is achieved. String literals in ontological KBs such as DBpedia often represent poorly expressed knowledge, with semantic types and coreferent entities missed. As far as we known, canonicalization of such literals has been little studied. Gunaratna et al. Some ideas of entity classification can be borrowed for literal typing but will become ineffective as the context differs. As a literal is associated with only one property, such probabilistic estimation becomes inaccurate (cf.