A Statistical and Schema Independent Approach to IdentifyEquivalent Properties on Linked Data

Kalpa GunaratnaKno.e.sis Center

Wright State UniversityDayton OH, USA

kalpa@knoesis.org

KrishnaprasadThirunarayanKno.e.sis Center

Wright State UniversityDayton OH, USA

tkprasad@knoesis.org

Prateek JainIBM T J Watson Research

CenterYorktown Heights NY, USA

jainpr@us.ibm.com

Amit ShethKno.e.sis Center

Wright State UniversityDayton OH, USA

amit@knoesis.org

Sanjaya WijeratneKno.e.sis Center

Wright State UniversityDayton OH, USA

sanjaya@knoesis.org

ABSTRACTLinked Open Data (LOD) cloud has gained significant at-tention in the Semantic Web community recently. Currentlyit consists of approximately 295 interlinked datasets withover 50 billion triples including 500 million links, and con-tinues to expand in size. This vast source of structured in-formation has the potential to have a significant impact onknowledge-based applications. However, a key impedimentto the use of LOD cloud is limited support for data inte-gration tasks over concepts, instances, and properties. Ef-forts to address this limitation over properties have focusedon matching data-type properties across datasets; however,matching of object-type properties has not received similarattention. We present an approach that can automaticallymatch object-type properties across linked datasets, primar-ily exploiting and bootstrapping from entity co-referencelinks such as owl:sameAs. Our evaluation, using sampleinstance sets taken from Freebase, DBpedia, LinkedMDB,and DBLP datasets covering multiple domains shows thatour approach matches properties with high precision andrecall (on average, F measure gain of 57% - 78%).

Categories and Subject DescriptorsI.2.6 [Artificial Intelligence]: Learning

KeywordsLinked Open Data, Property Alignment, Relationship Iden-tification, Statistical Equivalence

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.I-SEMANTICS 2013, 9th Int. Conf. on Semantic Systems, Sept. 4-6, 2013,Graz, AustriaCopyright 2013 ACM 978-1-4503-1972-0 ...$15.00.

1. INTRODUCTIONAbout 6 years ago, Sir Tim Berners-Lee introduced the

idea of openly publishing RDF based datasets. This ideawas based on four simple rules as described in [2]. The ulti-mate objective was to promote interlinking between datasetsand lay the foundation for “Web of Data”. He advocatedthe use of unique URIs to identify and distinguish things onthe Web. Use of different namespaces and URIs frees thedataset publishers from worrying about name conflicts withexisting resources of the same kind on the LOD. This stepwas significant from the point of view of encouraging RDFpublication as, in the span of 6 years, we have approximately295 datasets interlinked with each other on the LOD cloud1.These datasets cover numerous domains such as entertain-ment, life sciences, and governmental legislations. Further-more, this interlinked collection of diverse and structureddatasets has the potential to be used and exploited for nu-merous tasks such as enhanced browsing and search. Searchusing LOD datasets can be very significant in practice as itcan provide structured representation of entities and impor-tant information associated with them returned as results.Thus, a search for term “Tim Berners-Lee” will not only re-turn Web pages of him, but also aggregate information fromhis FOAF and DBpedia profiles.

Some of the existing LOD search engines such as Sig.ma[15] provide these capabilities by integrating data from dif-ferent data sources. These search engines utilize the owl:sameAs relationships created by tools like SILK [16] and LIMES[8]. Such search engines are an important step towards pre-senting and using information on LOD.

However, there are certain areas where these systems canbe improved. For example, a quick glance at the searchresults on Sig.ma points to redundant information aboutentities. For “Tim Berners-Lee”, the two properties namedbirth place and born in list similar values2. Here, the birthplace property comes from DBpedia and born in comes fromYago. These two property names can be aligned to presentan unified view under one property name or used to im-prove coverage and organization. Therefore, property align-

1http://linkeddata.org2As of 23-03-2013

ment is imperative for data integration and consuming tasksover LOD. Furthermore, properties capture the meaning ofRDF triples and understanding the interconnection betweenthem is considered to be important in the Semantic Webcontext[12].

In this work, we present an approach to align propertiesbetween two different linked datasets. Our approach relieson utilizing the entity co-reference relationships (ECR) suchas those formalized using owl:sameAs and skos:exactMatch.Our approach analyzes occurrences of equivalent subject andobject values across datasets to align properties. E.g., giventwo matching subject and object pairs that are connectedby ECR links, we check whether the associated propertynames have the potential to be equivalent. This is donein a robust manner by analyzing the aggregated statisticalresults related to matching subject-object pairs for a givenpair of properties. Using these results, we show how existingentity co-reference links between resources in LOD cloud canbe used to align properties. The main contributions of thepaper are as follows:

• It introduces an efficient approach that utilizes prop-erty extensions and resource inter-links for propertyalignment.

• It uses the notion of Statistical Equivalence to approx-imate owl:equivalentProperty.

The rest of the paper is organized as follows. In Section2, we discuss the state of the art techniques used in vari-ous property alignment tasks. Section 3 elaborates on theproblem and the proposed algorithm. Section 4 presentsthe results obtained and shows that Statistically Equivalentmatches (defined later) outnumber coincidental matches asthe algorithm is run on a large number of instances. Section5 discusses interesting matching patterns and facts relevantto the matching process, while Section 6 concludes with ourfindings and future work.

2. BACKGROUNDProperty alignment, which is crucial for data integration

tasks, has not been addressed adequately compared to con-cept and instance alignment. In contrast with instance andconcept alignment, properties exhibit complex structure andmeaning. Current techniques used for property alignment(including object-type) fall into three categories: (i) Syntac-tic/ dictionary-based, where predicate similarity is garneredvia string matching or using WordNet, (ii) Schema depen-dent, and (iii) Schema independent, where instance levelinformation is utilized. Some use a mix of these techniques.

There are a few efforts for matching data-type proper-ties in ontologies [10][14]. Nunes et al. [10] utilized mutualinformation present at the instance level using genetic al-gorithms. They discuss matching of one to many complexrelationships in different ontologies, but are limited to data-type properties. [14] discusses a cluster based similarity ag-gregation methodology for ontology matching where theyfocus on four different similarity measures to align proper-ties. They calculate string, WordNet, profile, and instancesimilarities based on the domains and ranges of the prop-erties. Even though [14] tries to match object-type prop-erties, they mention that the results are not strong enoughto distinguish matching and non-matching property names.

[13] incorporates a density estimation approach using Ker-nel Density Estimation (KDE) to map opaque properties(properties conveying the same meaning irrespective of theirnames) in ontologies. However, they transform values intonumeric form to be compatible with KDE. This transfor-mation is not easy in the LOD context where each instancecontains many triples.

Zhao et. al [17] presented a graph based ontology analy-sis complementing their previous work related to building amid-level ontology utilizing WordNet and string based sim-ilarity measures to group properties. The approach is notsuitable for identifying equivalent properties since it groupsany two related properties (using object value similarity)and does not take into account the effect of coincidentalmatches in initial grouping. SLINT [9] is an instance match-ing system that uses an IR based heuristic to calculate objectvalues overlap. Both these approaches are coarse grainedand hence not suitable for identifying equivalent propertiesas they aggregate properties on the overlap (not on the in-dividual subject pairs). E.g., they can confuse conceptu-ally different predicates “placeOfBirth” and “placeOfDeath”.These approaches are also different from ours in the sensethat they use only object values and their overlap whereaswe strictly try to match the property extensions minimiz-ing false positives. TripleRank’s effort [4] in faceted brows-ing computes latent predicate similarity (i.e., similar prop-erties within a dataset) indirectly as a byproduct of SVDand it is hard to verbalize the results in terms of exten-sions. Furthermore, it does not provide an evaluation onintra/inter dataset property alignment in terms of precisionand recall. The analysis of owl:sameAs networks and theirimplications for detecting schema-level inconsistencies andontology alignment are discussed in [3]. Some of the align-ment techniques and applications have used these networksshowing their effectiveness in practice [11][17]. We also usea similar link traversal network model in our approach tomatch property extensions.

3. APPROACHProperty alignment is a non-trivial research problem in

the Semantic Web domain whose accomplishment can leadto significant advancements in data integration tasks. Theobjective of property alignment is to identify equivalent orsub-property relationships between a property pair P1 andP2, which may be in the same or different datasets. Sinceproperty names in different datasets have independent ori-gin and relationships capture complex meaning in a triple[12], calculating string similarity or synonym based measure-ments on property names alone does not suffice. To solvethis problem, our “extensional” approach determines relatedproperties (P ) by finding similar triple patterns across datasetsby matching subject (S) and object (O) values in triples ofthe form (SP1O) and (SP2O).

3.1 Property alignment between datasetsOWL [1] defines the concept of equivalent property (owl:

equivalentProperty) as two properties having the same ex-tension. For example, if property P is defined by triples{ a P b, c P d, e P f } and property Q is defined by triples{ a Q b, c Q d, e Q f }, then they are equivalent propertiesbecause they have the same extension {{a, b}, {c, d}, {e, f}}.Since it is hard to expect exactly the same property ex-tensions in real datasets, we approximate it by a signifi-

cant overlap in matching subject-object pairs. For this pur-pose, we define statistical equivalence of properties on linkeddatasets. For example, if property P is defined by triples{ a P b, c P d, e P f } and property Q is defined by triples{ a Q b, c Q d, g Q h }, then property extensions are not thesame, but P and Q have matching subject and object val-ues two times out of three providing statistical evidence insupport of equivalence. When we utilize evidence for exten-sion matching, we need to overcome the potential problem ofincorrect matches in complex data representation contexts.

We first determine the ‘relatedness’ between a propertypair to decide a match, which also reduces the search space.Note that while SKOS[7] is a formal specification of conceptrelatedness in ontologies, there is no such specification forproperties. We now present some notions to help representproperty alignment on linked data. We first define the notionof candidate match between two properties.

The following statement is true for all the definitions in thepaper. Let S1P1O1 and S2P2O2 be two triples in two differ-ent datasets D1 and D2 respectively representing relationsP1(S1, O1) and P2(S2, O2). ECR are the entity co-referencelinks described in Section 1.

Definition 1: Candidate MatchThe two properties P1 and P2 are a candidate match iff S1ECR*←−−−→ S2 and O1

ECR*←−−−→ O2. We say two instances areconnected by an ECR∗ link if there is a link path betweenthe instances using ECR links (where, ∗ is the Kleene starnotation).

Candidate matches can provide supportive evidence forproperty alignment. But there can be coincidental (spu-rious) matching of properties. Consider the following twotriples in the datasets DBpedia(d) and Freebase(f):

d:Arthur Purdy Stout d:place of birth d:New York Cityf:Arthur Purdy Stout f:place of death f:New York City

Arthur Purdy Stout is a person (in fact, a surgeon andpathologist in real life) who lived in New York City. Giventhat d:Arthur Purdy Stout is the same as f:Arthur PurdyStout and d:New York City is the same as f:New York City,d:place of birth and f:place of death properties are a candi-date match according to the definition. But clearly thesetwo properties should not be treated as equivalent becausethey have different intentional semantics. Therefore, thiscoincidental match is not an equivalent match.

To minimize mis-identification of coincidental matches asequivalent (ideally eliminating them), our approach aggre-gates additional evidence in support of a statistical match,to approximate equivalent match (defined formally using ex-tensions). Therefore, we keep track of some statistical mea-sures along with the candidate matches to compute statis-tical equivalence. For a candidate matching property pair(P1,P2), Match Count µ(P1,P2) and Co-appearance Countλ(P1,P2) can be defined as follows.

Match Count µ(P1,P2) is the number of triple pairs for P1

and P2 that participate in candidate matches. That is,

µ(P1, P2) = |{S1P1O1 ∈ D1 | ∃ S2P2O2 ∈ D2

∧ S1ECR*←−−−→ S2 ∧ O1

ECR*←−−−→ O2}|(1)

I1 I2

I2

matching resources

owl:sameAs

P1=d1:doctoralStudent

P2=d2:education.

academic.advisees

Dataset 2 Dataset 1

property P1 and property P2 are a candidate match

d2:theodore_harold_maiman

I1=d1:Willis_Lamb I2 =d2:willis_lamb

I1

I1

d1:Theodore_Maiman

triple 1

triple 2

triple 3

triple 4

triple 5

Step 1

Ste

p 2

Step

2

Step 3

Figure 1: Process of Candidate Matching. Matchingresources are in the same color/pattern.

Co-appearance Count λ(P1,P2) is the number of triplepairs for P1 and P2 that have matching subjects. That is,

λ(P1, P2) = |{S1P1O1 ∈ D1 | ∃ S2P2O2 ∈ D2

∧ S1ECR*←−−−→ S2}|

(2)

Statistical equivalence in this work is measured by ana-lyzing candidate matches over co-appearances of a propertypair, which provides statistical evidence, i.e., it will havemany matching subject-object pairs over common subjects.Therefore, the number of matching subject-object pairs inthe property extensions and co-appearances of a propertypair directly influence the decision function F (defined be-low) for selection (captured using a confidence threshold α).Also, a property pair must co-appear enough times (sup-porting evidence) to be picked as a match, to overcome co-incidental matches, by achieving a sufficient match count µ.Therefore, this minimum number of match count µ shouldbe greater than a constant k. This constant k filters outmany incorrect random candidate matches. Now, statisti-cally equivalent property pairs can be defined as follows.

Definition 2: Statistically Equivalent PropertiesThe pair of properties P1 and P2 are statistically equivalentto degree (α, k) iff

F = µ(P1, P2)/λ(P1, P2) ≥ αwhere, µ(P1, P2) ≥ k, and 0 < α ≤ 1, k > 1

(3)

Note that, a list of statistically equivalent properties can,strictly speaking, consist of equivalent properties, sub-propertiesand incorrectly mapped coincidental matches.

3.2 Resource matching and generating prop-erty alignments

Our algorithm is based on exploiting entity co-referencelinks that exist between instances in linked data for can-didate matching of property pairs. This process is furtherillustrated in Figure 1 by matching an instance I1 (WillisLamb) with I2 using owl:sameAs as the co-reference (ECR)link. This is achieved in three steps. In step 1, the cor-responding instance for I1 is identified as I2 by following

P1 = doctoralStudent

P2 = education.

academic.advisees

owl:sameAs owl:sameAs

owl:sameAs

Dataset1 = DBpedia(d) Dataset2 = Freebase(f)

resources set S1

d:Theodore_Harold_Maiman

d:Theodore_H._Maiman

d:Theodore_Maiman

d:Ted_Maiman

d:Theodore_Maiman

d:Willis_Lamb f:Willis_Lamb

d:Theodore_Maiman f:theodore_harold_maiman

f:theodore_harold_maiman

resources set S2

Figure 2: Property matching with overlapping setsof resources

an owl:sameAs link from I1 to I2. In step 2, the subjectinstances are expanded using triples they consist of. I.e.,dataset 1 has three triples for I1 as the subject and dataset2 has two triples for I2 as the subject. In step 3, since all sub-ject values are matching for the triples of I1 and I2, findingtwo matching object values leads to a candidate match, i.e.,in triples 2 and 4, object values can be matched by followingan owl:sameAs link between them. Therefore both subjectand object values are matching for triples 2 and 4 (also anextension match) leading to a candidate match for doctor-alStudent and education.academic.advisees properties. Thisprocess is further outlined in Algorithm 1.

Algorithm 1 GenerateCandidateMatches(X, namespace)Input: X, namespaceOutput: λ, µ for each property pair

1: for i = 1 → Size(X) do2: subject S1 ← X[i]3: subject S2 ← GetCorsEntity(subjectS1, namespace)4: map l1 ← ExtractPO(S1)5: map l2 ← ExtractPO(S2)6: for each property p ∈ l1 do7: object o1 ← l1(p)8: Set o1 ecr ← GetECRLinks(o1)9: for each property q ∈ l2 do

10: if p exactmatch q then11: p matches q12: else13: update λ(p, q)14: object o2 ← l2(q)15: Set o2 ecr ← GetECRLinks(o2)16: isMatch ← Match(o1 ecr, o2 ecr)17: if isMatch then18: update µ(p, q)19: end if20: end if21: end for22: end for23: end for

Comparison of the object values of triples is computedby checking for an overlap of ECR links, which includeschecking for ECR∗. This is further illustrated in Figure 2with only direct linking between them (one level deep path)for clarity. Further, this overlap based computation allowsus to have link chains (ECR∗) to arrive (converge) at adecision. The process of candidate matching is presentedin Algorithm 1 where the input to the procedure is a setX of subject instances of the first dataset and namespaceidentifier of the second dataset. The GetCorsEntity pro-cedure returns the relevant corresponding entity in the sec-ond dataset for a given subject instance in the first dataset(by following an ECR link and namespace identifier). TheExtractPO procedure is for extracting all the property-object pairs for a given subject instance and returns a mapdata structure. The map data structure has object valuesstored for each property. The GetECRLinks procedure re-

D1:Dataset 1 D2:Dataset 2 Matching

Subject Pairs

Matching

Object Pairs

S1 doctoralStudent O1 S1

| academic.advisees O1

| ( S1 , S1

| ) ( O1 , O1

| )

S1 birth_place O2 S1

| place_of_birth O3 ( S1 , S1

| ) ---

S2 doctoralStudent O4 S2

| influenced O4

| ( S2 , S2

| ) ( O4 , O4

| )

S2 birth_place O5 S2

| place_of_birth O5

| ( S2 , S2

| ) ( O5 , O5

| )

S2

| place_of_death O5

| ( S2 , S2

| ) ( O5 , O5

| )

S3 doctoralStudent O6 S3

| academic.advisees O6

| ( S3 , S3

| ) ( O6 , O6

| )

S3

| influenced O7 ( S3 , S3

| ) ---

S3 birth_place O8 S3

| place_of_birth O8

| ( S3 , S3

| ) ( O8 , O8

| )

Generated Candidate Matching Property Lists – Matches selected are in Boldface

[D1:doctoralStudent] [ [D2:academic.advisees, 2:2] , [D2:influenced, 1:2] ] list1

[D1:birth_place] [ [D2:place_of_birth, 2:3] , [D2:place_of_death, 1:1] ] list2

Property Pair MatchCount Co-appearanceCount

[D1:doctoralStudent, D2:academic.advisees] 2 2

[D1:birth_place, D2:place_of_birth] 2 3

Figure 3: Calculating MatchCount and Co-appearanceCount values

turns all the available corresponding entities without con-sidering any namespaces. If two property names can bematched exactly (except namespaces), then they are con-sidered as matched, as outlined in line 11 of the algorithm.As the process outlined in Algorithm 1 is performed on asample instance set taken from dataset 1, candidate matchesare found with µ and λ counts. Then applying function Fwith α and k in equation 3 for aggregated µ and λ for eachproperty pair in the whole instance set will yield statisti-cally equivalent property pairs for the two datasets. Notethat GetCorsEntity and GetECRLinks procedures can beconfigured to use a specific ECR link or multiple types ofECR links (like owl:sameAs, skos:exactMatch, etc).

Figure 3 shows an example for calculating µ and λ. In thisexample, the algorithm used α=0.5 and k=2 to decide onmatches from each list of candidate matching pairs and elim-inate coincidental matches. Recall that α is the minimumfraction of matching triples over co-appearances and k is theminimum number of matching triples required to be consid-ered for equivalence. The need for k together with α canbe further explained using list1 & list2 in Figure 3, where“doctoralStudent” matched to “influenced” and “birth place”matched to “place of death” with satisfying α. Thus useof k avoids such coincidental (incorrect) matches. It alsoillustrates the nature of our bootstrapping algorithm thatdecides on a matching property pair after analyzing the evi-dence from all matching subject-object pairs of the propertyextensions.

3.2.1 Complexity AnalysisLet the average number of properties for an entity be x

and average number of objects for a property be j. Then,Algorithm 1 has to compare j ∗ j ∗ x ∗ x object value pairsfor an entity pair. For n number of subjects, it would ben ∗ j ∗ j ∗ x ∗ x. To extract property-object pairs, it requires2 ∗ n operations3. x and j are independent of n as numberof properties per instance and number of object values perproperty do not change on average for larger or smaller n.Since n > j and n > x, O(n ∗ j2 ∗ x2 + 2n) is n. Theinherent parallel nature of Algorithm 1 allows us to adapt it

3If comparisons are not restricted this way to each subject,a naive algorithm would need n2 ∗ j2 ∗ x2 + 2n comparisons.

to Map-Reduce paradigm to improve efficiency.

3.3 Implementation detailsThe algorithm is implemented using Java, Apache Hadoop

and Jena framework for processing RDF triples. Datasetsare replicated locally using Virtuoso triple store except forFreebase dataset for which we used their public APIs.

In this experiment, we mainly used owl:sameAs and skos:exactMatch links as ECR (owl:sameAs was the dominantlink of the two for the selected datasets). When searchingfor ECR links between entities, we investigated one leveldeep paths in this experiment (see Figure 2) since it wassufficient for the experimental datasets. But this can be ex-tended further by examining more than one level deep linkpaths (ECR∗) for enhanced coverage. We also used exactmatching of rdfs:labels of the two objects when comparingECR links for object equivalence. This is used as an approx-imation to ECR links for the comparison of object values(line 16 of Algorithm 1) to improve coverage in absence ofECR links. This is because, we are looking for exact match-ing of labels for objects that belong to the same entity intwo datasets. It is a good approximation as the subject (en-tity) is guaranteed to be the same, since only ECR links areused for subject matching. This approximation also tries tocompensate for sparseness of ECR links.

The process presented in Algorithm 1 requires a lot ofcomparisons and could grow for larger instance sets. But thealgorithm was easily adapted to Map-Reduce framework bydistributing subject instances among mappers. The specificimplementation is explained below:

• Map phase

– Let the number of subject instances in dataset 1(D1) be X and namespace of dataset 2 (D2) bens. For each subject i ∈ X, start a mapper andcall GenerateCandidateMatches(i, ns) outlined inAlgorithm 1.

– Each mapper outputs (key,value) pairs as (p:q,µ(p,q):λ(p,q)) to reducer, where property p∈D1and property q∈D2.

• Reducer phase

– Collects output from all mappers and aggregatesµ(p,q) and λ(p,q) values for each key p:q.

The process can be parallelized since computation of onesubject instance is independent of the others. We imple-mented the algorithm in Hadoop Map-Reduce 1.0.3 frame-work and achieved significant improvements in running timeon a 14 node cluster (speedup of 833% compared to the desk-top version on average). Moreover, we may achieve fastertimes when more resources are available to paralleize. Fur-ther detailed discussion on this is out of scope of this paper.

When the algorithm is run for a sample set of instancesstarting from datasetD1, we can generate candidate matchesof property pairs. One property may be matched to manyother properties because of similar extensions, as explainedin Section 3.1. After recording candidate matches, eachproperty in D1 has been mapped to a list of properties thatare in dataset D2 with match counts (see Figure 3). Themost probable matching properties will have higher matchcounts in the list and also have higher values for function F .

We sort each list in descending order based on match countsand then test the first property pair from each sorted list tosee whether it satisfies threshold α and k for a match4. Ap-plying these thresholds and sorting the lists remove manyof the coincidental matches and leave probable matches.The algorithm outputs these as statistically equivalent. Inthis experiment, we were able to remove 76%, 87%, 67%,83%, and 25% coincidental matches respectively from Ex-periments 1 to 5 5. These statistics also reveal that simpleobject value overlap or grouping mechanisms [9][17] are notadequate for finding equivalent properties in the LOD con-text.

4. RESULTS AND EVALUATIONThe objective of this evaluation is to show that statisti-

cal equivalence of properties can successfully approximateowl:equivalentProperty in the LOD context and the devel-oped algorithm performs considerably better than the ex-isting techniques used for property alignment, which in-cludes string similarity and external hierarchies (i.e., Word-Net) based approaches. To prove our claim, we chose DB-pedia6, Freebase7, LinkedMDB8, DBLP L3S9, and DBLPRKB Explorer10 datasets and extracted sample instance setsfor the following reasons. (1) They have more or less com-plete information for instances. (2) They are well inter-linked. (3) They have complex/opaque11 properties. (4)They cover several dimensions of our evaluation as multi-domain to multi-domain, specific-domain to multi-domainand specific-domain to specific-domain dataset property align-ment.

Our property alignment results are presented in Table 1.We randomly selected 5000 subject instances for each exper-iment, numbered 1 to 5 in Table 1. The experiments coverobject-type properties in person, film, and software domainsbetween DBpedia and Freebase, films between DBpedia andLinkedMDB, and articles between DBLP RKB explorer andDBLP L3S datasets. DBLP RKB explorer and DBLP L3Sare two separate datasets for DBLP that use two differentontologies. Furthermore, the DBLP RKB explorer projecthad different requirements, where it needed to achieve highprecision and recall on search services compared to DBLPL3S dataset. DBpedia and Freebase are both multi-domainhuge data hubs in LOD with overlapping information buthave non-trivial differences in their schema. Freebase usesmore blank nodes, increasing its complexity compared toDBpedia. LinkedMDB is a specialized dataset for moviesand has its own schema which is completely different fromDBpedia. Therefore, the datasets selected for the experi-ments from LOD are different from each other in both com-plexity and variety of data representation.

4Assuming both datasets do not have duplicate properties.In our experiments, DBpedia had duplicate properties.5From 732, 355, 221, 255 and 4 generated candidate prop-erty pairs respectively.6http://dbpedia.org/7http://freebase.com/8http://linkedmdb.org/9http://dblp.l3s.de/d2r/

10http://dblp.rkbexplorer.com11Complex or opaque properties are semantically the samebut have different word selections in describing the relation-ship.

MeasureType

DBpedia-Freebase(Person)1

DBpedia-Freebase(Film)2

DBpedia-Freebase(Software)3

DBpedia-LinkedMDB(Film)4

DBLP RKB-DBLP L3S(Article)5

Average

OurAlgorithm

Precision 0.8758 0.9737 0.6478 0.7560 1.0000 0.8427Recall 0.8089* 0.5138 0.4339 0.8157 1.0000 0.7145F measure 0.8410* 0.6727 0.5197 0.7848 1.0000 0.7656

DiceSimilarity

Precision 0.8064 0.9666 0.7659 1.0000 0.0000 0.7078Recall 0.4777* 0.4027 0.3396 0.3421 0.0000 0.3124F measure 0.6000* 0.5686 0.4705 0.5098 0.0000 0.4298

JaroSimilarity

Precision 0.6774 0.8809 0.7755 0.9411 0.0000 0.6550Recall 0.5350* 0.5138 0.3584 0.4210 0.0000 0.3656F measure 0.5978* 0.6491 0.4903 0.5818 0.0000 0.4638

WordNetSimilarity

Precision 0.5200 0.8620 0.7619 0.8823 1.0000 0.8052Recall 0.4140* 0.3472 0.3018 0.3947 0.3333 0.3582F measure 0.4609* 0.4950 0.4324 0.5454 0.5000 0.4867

Table 1: Alignment results of object-type properties. Experiments are numbered 1 to 5.

0

0.2

0.4

0.6

0.8

1

0.5 0.6 0.7 0.8 0.9

alpha

Experiment 1

Precision

Recall

F1

0

0.2

0.4

0.6

0.8

1

0.5 0.6 0.7 0.8 0.9

alpha

Experiment 2

Precision

Recall

F1

k=6

0

0.2

0.4

0.6

0.8

1

0.5 0.6 0.7 0.8 0.9

alpha

Experiment 3

Precision

Recall

F1

k=2 0

0.2

0.4

0.6

0.8

1

0.5 0.6 0.7 0.8 0.9

alpha

Experiment 4

Precision

Recall

F1

k=2

0

0.2

0.4

0.6

0.8

1

0.5 0.6 0.7 0.8 0.9

alpha

Experiment 5

Precision

Recall

F1

k=2

k=14

Figure 4: Precision, Recall and F measures for vary-ing α values

4.1 Deciding α and k valuesEstimating the values for α and k was done based on the

following facts. (1) Data in different datasets on LOD arenot complete and contain similar but not identical informa-tion. (2) Representation of these data is not uniform dueto multiple authors and naming preferences. (3) A resourceis not guaranteed to be linked to all matching resources.Because of these reasons, the same property in two differ-ent datasets cannot be expected to have close values for µand λ for a higher F value closer to 1. Therefore, basedon the above observations and our empirical evaluation, athreshold value closer to 0.5 for α seemed to be appropriateconsidering F measure. Figure 4 further clarifies this claimin our empirical evaluation showing precision, recall, and Fmeasure for varying α with the chosen k values. Results pre-sented in Table 1 are using 0.5 for α except for experiment2 where it is 0.7 for optimal F measure results.

The constant k is also affected by the above reasons andwe followed a data driven approach to approximate a suit-able value for k as follows. First the algorithm output isfiltered using α=0.5 and k=2 which means, the lowest possi-ble matching with a positive confidence level12. Then we getthe µ values for property pairs matched using exact stringmatching, which are not identified by the algorithm and getthe average of the counts as constant k. Our analysis overk suggests that most of the time, optimal performance forthe algorithm is achieved by a value closer to this approxi-mation of k (default set to 2). Following this approach, we

12α<0.5 is a negative confidence level since less than half ofsubject-object pairs got matched from common subjects.

used 14, 6, 2, 2, and 2 for k in the experiments numberedas 1, 2, 3, 4, and 5 respectively in Table 1. Increasing boththese thresholds α and k yields high confidence matches asthey demand a higher number of extension matching.

4.2 Experiment settingWe compared our bootstrapping based algorithm with

two string matching algorithms and WordNet13 similaritysuggested by [17]. We calculated WordNet similarity14 bysearching for at least one matching object value [17] andthen applying WordNet similarity on pre-processed termsof the properties. We tokenized and removed stop wordsfrom properties to calculate WordNet similarity and addedPorter’s stemming algorithm for string similarity. The re-sults shown for these similarities are the optimal ones consid-ering F measure metric. The threshold values used for stringsimilarity and WordNet similarity algorithms were 0.92 and0.80 respectively. For experiment 5, Dice and Jaro similar-ity didn’t show any matching properties even for a thresholdvalue of 0.5.

We used three independent reviewers to evaluate the match-ing of the properties and we chose the majority vote to deter-mine the correct matches. The evaluators were given somesample matches (2-3), and if the meaning of the proper-ties were hard to understand by their name (which is thecase for most properties), they were provided with queriesto execute and explore details about them, like instancesthey connect to and their domain and range. They were notasked specifically to distinguish between an exact match anda sub-property match in the alignment. For the experimentnumbered 1 in Table 1, we could not find all possible correctmatches because the total number of combinations is largefor a manual evaluation(∼ 39k pairs). Therefore, we gaveevaluators all the mappings found by the algorithm with-out any threshold applied (extracted from property lists asshown in Figure 3). Hence, recall and F measure are justapproximations and they are marked with an * in Table 1for experiment 1. Among the above mentioned comparabletechniques, in every case, our bootstrapping based approachshowed higher recall and F measures.

4.3 Types of properties identifiedOur algorithm identified different kinds of matching prop-

erty pairs. It can potentially subsume approaches that usetechniques such as string similarity and synonym checkingas shown in Table 2 using extensional matching. The sam-ple pairs listed in Table 2 are all correctly identified by ouralgorithm. To explain example matching pairs in Table 2,

13http://wordnet.princeton.edu/14http://www.sussex.ac.uk/Users/drh21/

MatchingCategory

Dataset 1 Dataset 2

StringSimilarity

db:nationality fb:nationalitydb:religion fb:religion

Synonymousdb:occupation fb:professiondb:battles fb:participated in conflicts

ComplexMatches

db:screenplay fb:written bydb:doctoralStudents fb:advisees

Table 2: Sample of matching properties under dif-ferent categories. namespaces: db for DBpedia andfb for Freebase.

consider the following observations.“String Similarity Matches” can be identified using string

similarity measures such as Dice’s Coefficient or simple char-acter comparison on property names. “Synonymous Matches”are mappings that can be identified by analyzing synonymsof the property names. For example, occupation and profes-sion can be mapped using a dictionary, but interestingly theWordNet approach failed to match this pair for the providedthreshold (showed very low similarity value of 0.5). In fact,both pairs were missed by the WordNet approach. “Com-plex Matches” are the last category shown in Table 2 and areharder to identify. All of the approaches outlined in the eval-uation missed this mapping except our algorithm. This isbecause our approach exploits property extensions in align-ing properties. There are also false positives in our result set.One such property pair is http://dbpedia.org/property/issueand http://rdf.freebase.com/ns/people.person.children, whichhappens to have similar extensions but has different inten-tions.

5. DISCUSSIONThe results show that our approach can effectively iden-

tify equivalent object properties by utilizing different sta-tistical parameters presented above. It performs well evenwhen complex properties exist, like in experiments 1 and 5in terms of F measure metric. Our algorithm also performswell in terms of precision when datasets contain more liter-ally similar property names as in experiments 2, 3, and 4,and discovers more interesting matches in every case, show-ing higher recall, e.g., experiment 5 is about aligning proper-ties in the same domain (publication) with high overlappinginformation, but represents data using two completely dif-ferent ontologies. These two ontologies do not have similarword selection or synonyms in their schema exemplifyingcomplex data representation typically found on LOD. Be-cause of this, string similarity based approaches do not per-form well and synonym based approaches also show poorcoverage over terms. Therefore, novel techniques such asours for discovering equivalent properties on Linked Data(i.e., Complex Matches in Table 2) are indispensable15.

We selected DBpedia, Freebase, LinkedMDB, and DBLPfor our evaluation because of the existence of many en-tity co-reference links between their entities, specifically,DBpedia and Freebase provide diverse and complex prop-erty sets. Alignment between DBpedia and Freebase eval-uates multi-domain property alignment whereas DBpediaand LinkedMDB covers multi-domain and specific-domaindataset alignment. The DBLP alignment evaluates our al-

15More details can be found at http://wiki.knoesis.org/index.php/Property_Alignment

gorithm between specific-domain datasets. Therefore, ourevaluation covers property alignment between different typesof datasets that can arise in the LOD domain. When analyz-ing results of matching frequency for property pairs, it wasobserved that some matching properties do not appear fre-quently enough. Consequently, the algorithm’s confidencein picking them as a match is low. This is mainly due tothe nature of properties, as discussed in Section 3. When arandom sample set is selected, it contains instances belong-ing to various types, e.g., a person type can have instancesbelonging to athlete, artist, etc., which have rare proper-ties. We can run the algorithm iteratively for more subjectinstances that have these less frequent property pairs to im-prove precision. Our algorithm assumes that there are noduplicate properties in both datasets being aligned. If bothdatasets have duplicate properties, it requires additional in-ferencing mechanism to identify missing pairs, since only onematching pair from each candidate list is selected.

We observed that certain properties that are mapped asequivalent properties are actually sub-properties. This hap-pens mainly because we do not distinguish between equiva-lent properties and sub-properties. For an example, http://dbpedia.org/property/mother and http://rdf.freebase.com/ns/people.person.parents are two such properties matched asequivalent, while, in fact, the first is a sub-property of thesecond. We would like to distinguish sub-properties in ourfuture experiments for more fine grained matches. Also,we believe ECR∗ links are useful in general, where manydatasets are linked to central hubs like DBpedia and the al-gorithm will be able to discover more connections betweenresources by finding link paths via these hubs.

We believe the uniqueness of our approach has resulted inhigh quality results compared to existing approaches becauseit, (1) does extension matching using entity co-referencelinks, (2) bootstraps from candidate matches and aggregatesthe results, and (3) makes final alignments using statisticalmeasures analyzing aggregated confidence of the matchingpairs. While, string similarity and synonymous matchinghave been shown to be effective in the past (primarily forliterals), they do not have sufficient coverage for resourcesas shown in our evaluation. We use owl:sameAs as an en-tity co-reference link but its use to link two semanticallyequivalent instances seems to be controversial in the LODcommunity [5][6]. In spite of well-known shortcomings, (likeequating “London” to “Greater London”), our algorithm isexpected to be sufficiently robust for property alignment,because it is based on aggregating information from a largenumber of entity equivalence assertions. In other words, webelieve that the effect of a few misused links will not affectthe final result much, because our algorithm does not de-cide on a property match by analyzing a single matchingtriple. Even though the interlinking (entity co-reference)relationships are small compared to the size of similar in-stances between datasets today, we expect that these linkswill become prevalent as the datasets evolve and are main-tained as part of the “linked data life cycle” (with projectssuch as http://latc-project.eu/ and http://stack.lod2.eu/).Moreover, we can see other recent successful efforts in usingowl:sameAs networks in the LOD context[11][17] in spite ofthese known issues.

We also identified some property pairs which are matchedbut have incorrect meaning in the property name. For exam-ple, http://dbpedia.org/property/issue and http://rdf.freebase

.com/ns/people.person.children property pair between DB-pedia and Freebase. This happened because of mixed valuespresent in the DBpedia property http://dbpedia.org/property/issue, that has both integer values and names of childrenas object values. In this case, we can regard this kind ofa property as ambiguous and having noise, which has anegative effect on the matching process. Another instancewhere the algorithm can go wrong is when it encountersspecial cases where the two datasets have enough facts forthe process to identify two properties as a match, but ac-tually they are not. For an example, for film domain, it mapshttp://dbpedia.org/ontology/distributor to http://rdf.freebase.com/ns/film.film.production companies. This mainly hap-pens because a number of production companies who pro-duce also distribute films. Thus, they have multiple rolesand the extensional equality may choose to match one ofthe many roles (extensions match but different intentions).

6. CONCLUSION AND FUTURE WORKWe have developed and evaluated an extension-based ap-

proach to match object-type properties on linked datasets.We have defined a computable concept of statistical equiv-alence of properties to approximate owl:equivalentPropertyby leveraging entity co-reference links. Our algorithm isunique and novel in how it computes extensional equiva-lence iteratively by building candidate matches in parallel.This approach ultimately determines statistically equivalentproperty pairs. The algorithm is easily parallelizable as ev-idenced by our straight forward Map-Reduce implementa-tion. The empirical evaluation shows that our approachis superior to the state of the art using F measure metric(on average, F measure gain is in the range 57% - 78%).This suggests that it is possible to align object-type prop-erties on LOD datasets effectively. Our approach subsumesconclusions arrived at by string-based and WordNet-basedsimilarity metrics and discovers more hidden and interest-ing matches well-suited for the LOD cloud. However, wecan use string-based or WordNet-based approaches to fur-ther improve confidence in our results to minimize coinci-dental matches. In fact, our data driven approach can alsobe adapted to align data-type properties by using similar-ity metrics for object values in triples. Another beneficialside effect of object-type property alignment is that it maybe used to generate or discover potential co-reference linksbetween instances. Furthermore, we expect to test the al-gorithm on different levels (strength) of entity co-referencelinks. In future, we will extend the coverage to more typesof data and discover domains in which properties exist forbetter alignment. The alignment problem can be furtherrefined to determine sub-properties in the future that willhelp with fine grained data integration tasks.

AcknowledgementsThis work was supported by the National Science Founda-tion under award 1143717 “III: EAGER Expressive ScalableQuerying over Linked Open Data”.

7. REFERENCES[1] S. Bechhofer, F. Van Harmelen, J. Hendler,

I. Horrocks, D. McGuinness, P. Patel-Schneider,L. Stein, et al. Owl web ontology language reference.W3C recommendation, 10:2006–01, 2004.

[2] T. Berners-Lee. Linked data-design issues. W3C,2009(09/20), 2006.

[3] L. Ding, J. Shinavier, Z. Shangguan, andD. McGuinness. Sameas networks and beyond:analyzing deployment status and implications of owl:sameas in linked data. The Semantic Web–ISWC2010, pages 145–160, 2010.

[4] T. Franz, A. Schultz, S. Sizov, and S. Staab.Triplerank: Ranking semantic web data by tensordecomposition. The Semantic Web-ISWC 2009, pages213–228, 2009.

[5] H. Halpin, P. J. Hayes, J. P. McCusker, D. L.McGuinness, and H. S. Thompson. When owl: sameasisnaAZt the same: An analysis of identity in linkeddata. In The Semantic Web–ISWC 2010, pages305–320. Springer, 2010.

[6] P. Jain, P. Hitzler, P. Yeh, K. Verma, and A. Sheth.Linked data is merely more data. Linked Data MeetsArtificial Intelligence, pages 82–86, 2010.

[7] A. Miles and S. Bechhofer. Skos simple knowledgeorganization system reference. W3C Recommendation,2008.

[8] A. Ngomo and S. Auer. Limes-a time-efficientapproach for large-scale link discovery on the web ofdata. In Proceedings of IJCAI, 2011.

[9] K. Nguyen, R. Ichise, and B. Le. Slint: Aschema-independent linked data interlinking system.Ontology Matching, page 1, 2012.

[10] B. Nunes, A. Mera, M. Casanova, K. Breitman, andL. Leme. Complex matching of rdf datatypeproperties. MCC12/11, Dept Informatics, PUC-Rio(September 2011).

[11] R. Parundekar, C. A. Knoblock, and J. L. Ambite.Discovering concept coverings in ontologies of linkeddata sources. In The Semantic Web–ISWC 2012,pages 427–443. Springer, 2012.

[12] A. Sheth, I. Arpinar, and V. Kashyap. Relationshipsat the heart of semantic web: Modeling, discovering,and exploiting complex semantic relationships. Studiesin Fuzziness and Soft Computing, 139:63–94, 2004.

[13] J. Sleeman, R. Alonso, H. Li, A. Pope, and A. Badia.Opaque attribute alignment. In Data EngineeringWorkshops (ICDEW), 2012 IEEE 28th InternationalConference on, pages 17–22. IEEE, 2012.

[14] Q. Tran, R. Ichise, and B. Ho. Cluster-based similarityaggregation for ontology matching. OntologyMatching, page 142, 2011.

[15] G. Tummarello, R. Cyganiak, M. Catasta,S. Danielczyk, R. Delbru, and S. Decker. Sig. ma: liveviews on the web of data. Web Semantics: Science,Services and Agents on the World Wide Web,8(4):355–364, 2010.

[16] J. Volz, C. Bizer, M. Gaedke, and G. Kobilarov. Silk–alink discovery framework for the web of data. InProceedings of the 2nd Linked Data on the WebWorkshop. Citeseer, 2009.

[17] L. Zhao and R. Ichise. Graph-based ontology analysisin the linked open data. In Proceedings of the 8thInternational Conference on Semantic Systems, pages56–63. ACM, 2012.