In this report, we mainly present an overview of ObjectCoref, which follows a self-training framework to resolve object coreference on the Semantic Web. Besides, we show preliminary results of Falcon-AO (2010) for this year's OAEI campaign, including the benchmark and conference tracks.
1.1
The Semantic Web is an ongoing effort by the W3C Semantic Web Activity to actualize
data integration and sharing across different applications and organizations. To date,
a number of prominent ontologies have emerged to publish data for specific domains,
such as the Friend of a Friend (FOAF). These specifications recommend common
identifiers for classes and properties in the form of URIs [
On the instance level, however, it is far from achieving agreement among sources
on the use of common URIs to identify specific objects on the Semantic Web. In fact,
due to the decentralized and dynamic nature of the Semantic Web, it frequently happens
that different URIs from various sources, more likely originating from different RDF
documents, are used to identify the same real-world object, i.e., refer to an identical
thing (as known as URI aliases [
Object coreference resolution, also called consolidation or identification [
We introduce a new approach, ObjectCoref, for bootstrapping object coreference
resolution on the Semantic Web. The architecture of the proposed approach follows a
common self-training framework (see Fig. 1). Self-training [
Falcon-AO [
The semantics of owl:sameAs dictates that all the URIs linked with this property have the same identity; if a property is declared to be inverse functional (IFP), then the object of each property statement uniquely determines the subject (some individual); a functional property (FP) is a property that can have only one unique value for each object; while cardinality (or max-cardinality) allows the specification of exactly (or at most) the number of elements in a relation, in the context of a particular class description, and when the number equals 1, it is somehow similar to the FP, but only applied to this particular class.
Next, ObjectCoref learns the discriminability of pairs of properties based on the coreferent URIs, in order to find more coreferent URIs for extending the training set. The discriminability reflects how well each pair of properties can be used to determine whether two URIs are coreferent or not. As an extreme example, IFPs (e.g. foaf:mbox) have a very good discriminability.
In RDF graphs, each URI is involved in a number of RDF triples whose subject is the URI, and the predicates and objects in these RDF triples form some <property, value> pairs, which can be considered as features for describing such URI. ObjectCoref compares the values between the <property, value> pairs from coreferent URIs, and finds which two properties have similar values and how frequent. The significance is the percentage of the number of coreferent URIs that can found by the discriminant properties in all the coreferent URIs in the training set. If the significance is greater than a given threshold, such the property pair is chosen for further resolution. Please note that for different domains, same property pairs may have different discriminability. For example, a pair of rdfs:labels is discriminant for the biomedical domain but not for people.
If new coreferent URIs are found, ObjectCoref selects highly accurate ones and adds them into the training set. The whole process iterates several times and terminates when the property discriminability is not significant enough or cannot find more discriminant property pairs. 1.3
For ObjectCoref, there is no explicit equivalence semantics in the DI and PR tracks. In order to establish the initial training set of coreferent URIs, we randomly extract 20 mappings from the reference alignment for each test case. All the mappings generated by ObjectCoref are based on the same parameters.
For Falcon-AO, we do not make any specific adaptation in the OAEI 2010 campaign. All the mappings for the benchmark and conference tracks outputted by FalconAO are uniformly based on the same parameters. 1.4
We implement an online service for ObjectCoref, and run it over a large-scale dataset
collected by the Falcons [
Besides, we follow the SEALS platform to publish Falcon-AO (2010) as a service. Please access it from http://219.219.116.154:8083/falconWS?wsdl. The offline version can be downloaded from our website: http://ws.nju.edu.cn/ falcon-ao. 1.5
The alignments for this year’s OAEI campaign should be available at the official website: http://oaei.ontologymatching.org/2010/. 2
2.1
DI In this section, we will present the results of ObjectCoref and Falcon-AO (2010) on the tracks provided by the OAEI 2010 campaign.
In this track, we use ObjectCoref to resolve object coreference between three pairs of datasets, namely diseasome vs. sider, dailymed vs. sider and drugbank vs. sider. Table 1 shows the discriminant property pairs that ObjectCoref learns by self-training. For example, diseasome:name and sider:siderEffectName are a pair of discriminant properties, and if some URI in the diseasome dataset has a value w.r.t. diseasome:name that is similar to some URI in the sider dataset w.r.t. sider:siderEffectName, these two URIs can be considered as coreferent. In this track, the training process converges at two iterations, respectively.
With these discriminant property pairs, ObjectCoref finds a number of coreferent URIs for each pair of datasets. As shown in Table 2, the precision and recall is moderate. Without considering the type of each object, the precision is not very good, so further inference-based debugging on coreferent URIs is needed for future work. In this track, ObjectCoref uses the same self-training process to recognize coreferent URIs for each pair of datasets, two of which are related to persons and the other is about restaurants. The discriminant property pairs are listed in Table 3. Based on these discriminant properties, ObjectCoref finds a set of coreferent URIs, where the precision and recall are pretty good (see Table 4). In particular, the good recall reflects that our learning approach identifies the key properties for resolving object coreference in this track. But we also notice that some combination of properties may be also helpful. For example, first name + last name can be used for identifying same people. We use Falcon-AO (2010) to participate in the benchmark and conference tracks. The average precision and recall are depicted in Table 5. As compared to OAEI 2007, the benchmark track adds some new cases. Falcon-AO failed in several cases due to the Jena parsing errors. For the detailed results, please see Appendix. In this section, we will firstly discuss several possible ways to improve ObjectCoref, and then give comments on the OAEI 2010 test cases.
The preliminary results of ObjectCoref demonstrate that using property discriminability is feasible to find coreferent URIs on the Semantic Web. However, we also see several shortcomings of the proposed approach, which will be considered in the next version. 1. How to divide objects into different domains? For the tasks in this year’s OAEI, we may not see the importance of recognizing domains, but on the whole Semantic Web, different domains may have different discriminant properties, and a single property pair may have different discriminability in different domains. So, a uniform measurement is ineffective. 2. How to avoid error accumulation? In self-training, an important issue is to prevent error accumulation, since a wrong labeled example would lead to misclassification in further propagation. In our evaluation, because the training process converges in a few iterations, so this situation is not so significant. But in real world, it is imperative to consider that. 3. How to find discriminant property combinations? A single property may be not good enough for resolving object coreference, while the combination of several properties would be more discriminant. However, we need to avoid overfitting. So, we plan to mine frequent patterns in the RDF data for describing objects and refine these frequent patterns to form property combinations. 3.2
The proposed matching tasks cover a large portion of real world domains, and the discrepancies between them are significant. Doing experiments on these tasks are helpful to improve algorithms and systems. In order to enhance applicability, we list some problems in our experiment procedure, which might aid organizers to improve in the future. 1. In the DI track, the organizers provide 4 downloadable datasets for the biomedical domain, however, the interlinking track also involves a number of others, e.g., linkedct, lifescience, bio2rdf. The datasets are not only very large, but also difficult to find the latest versions, most of which are even not allowed to download. Furthermore, using SPARQL endpoints in the experiment is very time-consuming, especially for such a large scale. So, we would expect that all the datasets can be (perhaps temporarily) offline in the next year. 2. Falcon-AO (2010) uses Jena 2.6.3 as the RDF parser. In the benchmark track, some ontologies may have problems and cause the Jena exception “Unqualified typed nodes are not allowed. Type treated as a relative URI”. So, we would expect the organizers to fix this in the next year.
Object coreference resolution is an important way for establishing interoperability among (Semantic) Web applications that use heterogenous data. We implement an online system for resolving object coreference called ObjectCoref, which follows a self-training framework focusing on learning property discriminability. From the experiments in this year’s DI and PR tracks, we find some positive and negative experience for improving our system. In the near future, we look forward to making a stable progress towards building a comprehensive object coreference resolution system for the Semantic Web.
This work is in part supported by the NSFC under Grant 61003018 and 60773106. We would like to thank Ming Li for his valuable comments on self-training.
In this appendix, we will show the complete results of Falcon-AO (2010) on the benchmark and conference tracks. Tests were carried out on two Intel Xeon Quad 2.40GHz CPUs, 8GB memory with Redhat Linux Enterprize Server 5.4 (x64), Java 6 compiler and MySQL 5.0.
In the following tables, the results are shown by precision (Prec.) and recall (Rec.).