=Paper= {{Paper |id=None |storemode=property |title=Aligning Geospatial Ontologies on the Linked Data Web |pdfUrl=https://ceur-ws.org/Vol-691/paper1.pdf |volume=Vol-691 }} ==Aligning Geospatial Ontologies on the Linked Data Web== https://ceur-ws.org/Vol-691/paper1.pdf

Aligning Ontologies of Geospatial Linked Data

Rahul Parundekar, Craig A. Knoblock and José Luis Ambite

Information Sciences Institute and Computer Science Department
University of Southern California
4676 Admiralty Way, Marina del Rey, CA 90292
{parundek,knoblock,ambite}@isi.edu

Abstract. The Web of Linked Data is characterized by linking structured data
from different sources using equivalence statements, such as owl:sameAs, as well
as other types of linked properties. However, the ontologies behind these sources
are not linked. The work described in this paper aims at providing alignments
between these ontologies by using an extensional approach. We look at geospa-
tial data sources on the Web of Linked Data and provide equivalence and sub-
sumption relationships between the classes from these ontologies after building
hypotheses that are supported by owl:sameAs links. We are able to model one
geospatial source in terms of the other by aligning the two ontologies and thus
understand the semantic relationships between the two sources.

1 Introduction

The last few years have witnessed the beginnings of a paradigm shift from publishing
isolated data from various organizations and companies to publishing data that is linked
to related data from other sources, using the structured model of the Semantic Web.
As the data being published on the Web of Linked Data starts to grow, the availability
of related data can be used to supplement one’s own knowledge base. This provides
a huge potential in various domains, like the geospatial domain, where it is used in
the integration of data from different sources. Apart from generating structured data,
a necessary step to publish data in the Web of Linked Data is to provide links from
the generated instances to other data ‘out there,’ based on background knowledge (e.g.
linking DBpedia to Wikipedia), common identifiers (e.g. ISBN numbers), or pattern
matching (e.g. names, latitude, longitude and other information used to link Geonames
to DBpedia). These links are often expressed by using owl:sameAs. A common occur-
rence when such links between instances are asserted is the missing link between their
corresponding concepts. Such a link would ideally be able to help a consumer of the
information (agent/human) to model data from the other source in terms of their own
knowledge. This is widely known as ontology alignment, a special form of schema
alignment. Schema alignment has been extensively studied in domains like schema in-
tegration, data warehouses, E-commerce, semantic query processing, etc. [1]. There is
also a considerable amount of work in ontology matching which is summarized in Eu-
zenat et al. [2]. The advent of the Web of Linked Data warrants a renewed inspection of
these methods. Our approach provides alignments between classes from two ontologies
in the Web of Linked Data by looking at the instances which are linked as the same. We
believe that providing an alignment between the ontologies of the two sources on the
Web of Linked Data provides valuable knowledge in understanding and modeling the
semantic relationships among sources.
The paper is organized as follows. We first provide background on geospatial Linked
Data and describe the sources that are the subject of this paper. We then describe our ap-
proach to ontology alignment, where alignments are conjunctions of restriction classes.
We follow with an empirical evaluation on three large geospatial Linked Data sources,
namely G EONAMES, DB PEDIA, and L INKED G EO DATA. Finally, we briefly describe re-
lated and future work and discuss the contributions of this paper.

2 Background on Linked Geospatial Data
In this section, we provide a brief introduction to the popular use of Linked Data and
the data sources from the geospatial domain that we consider.
2.1 Nature of Linked Data
The Linked Data movement, as proposed by Berners-Lee [3], aims to provide machine-
readable connections between data in the Web. Bizer et al. [4] describes several ap-
proaches to publishing such Linked Data. Most of the Linked Data is generated auto-
matically by converting existing structured data sources (typically relational databases)
into RDF, using an ontology that closely matches the original data source. For example,
G EONAMES gathers its data from around 40 different sources and it primarily exposes its
data in the form of a flat-file structure,1 which is described with a simple ontology [5].
Such an ontology might have been different if designed at the same time as the collec-
tion of the actual data. For example, all instances of G EONAMES have the same rdf:type
of geonames:Feature, however they could have been more effectively typed based on
the featureClass & featureCode properties.
The links in the Linked Data on the Web make the Semantic Web browsable and,
moreover, increases the amount of knowledge by complementing data already presented
by a resource. A popular way of linking data on the Web is the use of owl:sameAs
links to represent identity links [6]. Instead of reusing existing URIs, new URIs are
automatically generated while publishing linked data and an owl:sameAs link is used to
say that two URI references refer to the same thing. Both Ding et al. [7] and Halpin et al.
[6] discuss the popular usage of the owl:sameAs property. Halpin et al. [6] summarizes
its usages as belonging to one of the four types i) same thing as but different context
ii) same thing as but referentially opaque iii) represents and iv) very similar to. We
however refrain ourselves from going into the specifics and use the term as asserting
same thing. For example, G EONAMES uses the owl:sameAs link to represent an alias or
a co-reference.
2.2 Linked geospatial Data Sources
We consider three linked data sources G EONAMES2 , DB PEDIA3 and L INKED G EO DATA4 .
1
http://download.geonames.org/export/dump/readme.txt
2
http://www.geonames.org/ontology/
3
http://wiki.dbpedia.org/About
4
http://linkedgeodata.org/About
G EONAMES is a geographical database that contains over 8 million geographical names
consisting of 7 million unique features including 2.6 million populated places and 2.8
million alternate names. This database is downloadable free of charge and accessible in
various forms like a flat table, web services, etc. We use the Linked Data representation
of the database available as an RDF dump containing 6,520,110 features and 93,896,732
triples. The structure behind the data is the Geonames ontology [5], which closely re-
sembles the flat-file structure. A typical individual in the database is an instance of type
Feature and has a Feature Class associated with it. These Feature Classes can be admin-
istrative divisions, populated places, structures, mountains, water bodies, etc. Though
the Feature Class is subcategorized into 645 different Feature Codes, the Feature Code
is associated with a Feature instance and not as a specialization of the property feature-
Class (this is probably due to automatically exporting of existing relational data into
RDF rather than building data conforming to an ontology). A Feature also has several
other properties, such latitude, longitude, and an owl:sameAs property linking it to an
instance from DB PEDIA.
DB PEDIA is a source of structured information extracted from W IKIPEDIA containing
about 1.5 million objects that are classified with a consistent ontology. Because of the
vastness and diversity of the data in DB PEDIA, it presents itself as a hub for links in
the Web of Linked Data from other sources [8]. The dataset includes individuals not
limited to geospatial data such as 312,000 persons, 94,000 music albums, etc. We are
interested in a subset of this data which G EONAMES links itself with (e.g. places, moun-
tains, etc.). As DB PEDIA contains a large variety of data (e.g. abstracts, links to other
articles, images, etc.) we limit our approach to RDF containing the rdf:type assertion
and info boxes, which provide factual information.
L INKED G EO DATA is a geospatial source with its data imported from the Open Street
Map (OSM) [9] project containing about 2 billion triples comprising approximately 350
million nodes and 30 million ways. In order to generate the RDF, the data extracted from
the OSM project was linked to DB PEDIA instances using the user created links on OSM
to W IKIPEDIA articles. These links were then used as the training set on which machine
learning algorithms were applied with a heuristic on a combination of the L INKED G EO -
DATA type information, spatial distance, and name similarity [10]. As a result the set of
owl:sameAs links was then expanded to include more instance matchings based on the
model learnt. This data is provided by L INKED G EO DATA as an RDF dump.
We loaded these three RDF datasets into a local database. In this paper we only
consider instances from DB PEDIA and G EONAMES that are linked using the owl:sameAs
property. Similarly, we focus on instances from L INKED G EO DATA linked by owl:sameAs
to DB PEDIA instances. In order to reduce the number of self joins required on a source
table in the database, the values related to each individual were converted into a single
row identified with its URI. This forms a table where the columns represent all of the
properties (predicates) that occur in the triples of that source. For example, the table for
G EONAMES subset contains 11 columns not including the identifier. The values for the
properties (object part of a triple) go into the value of the column for the row identi-
fied by URI of the individual (subject part of a triple). We call this a vector. In cases
of multivalued properties, the row is replicated in such a way that each cell contains a
single value but the number of rows equals the number of multiple values. Each new
row however, is still identified with the same URI, thus retaining the number of dis-
tinct individuals. In general, the total number of rows for each individual is the product
of cardinalities of the value sets for each of its properties. Throughout this paper we
describe our methodology using the G EONAMES -DB PEDIA dataset, but we include the
findings of the L INKED G EO DATA -DB PEDIA source in the results section.

3 Ontology Alignment Using Linked Data

3.1 Ontology Alignment

An Ontology Alignment is “a set of correspondences between two or more ontologies”
where a correspondence is “the relation holding, or supposed to hold according to a
particular matching algorithm or individual, between entities of different ontologies.”[2]
Entities here, can be classes, individuals, properties or formulas. Our algorithm relies on
data analysis and statistical techniques for matching the two ontologies, which Euzenat
et al. [2] classify as a common extension comparison approach for aligning the structure.
This approach considers two sets A and B of instances belonging to the two ontologies
out of which some instances are common. Set containment relationships between the
set of instances A and B suggest the alignment between the two as follows: A equals B
(A ∩ B = A = B), A contains B (A ∩ B = B), A is contained in B (A ∩ B = A), A is
disjoint from B (A ∩ B = ∅) and A overlaps with B (A ∩ B 6= ∅). Euzenat et al. [2] also
argues that using a Hamming distance is more robust than using simple set containment
as it tolerates misclassified individuals and still produces acceptable results. We iden-
tify common instances between the two ontologies required for this technique using the
owl:sameAs links, where the instance identifier in each ontology gets replaced with a
combination of the URIs from both ontologies. Instead of limiting ourselves to existing
classes, we extend the scope of our alignments by using restriction classes as explained
in the following section. In its stricter sense, an alignment between classes would also
consider structural conformity like cardinality constraints on properties, class hierar-
chies, domain and ranges of properties, etc. We however do not consider this in order to
provide simpler alignments as most of these ontologies are rudimentary and based on
pre-existing relational structures.

3.2 Restriction Classes

In the alignment process, instead of focusing only on classes defined by rdf:type, we
also consider classes defined by conjunctions of property value restrictions (i.e, has-
Value constraints in the Web Ontology Language), which we will call restriction classes
in the rest of the paper. For example, each instance from G EONAMES has its rdf:type as
Feature. Traditional alignments would then only be between the class Feature from
G EONAMES and another class from DB PEDIA, for example Place. As mentioned be-
fore, instances in G EONAMES are also categorized by the featureCode and featureClass
properties. A restriction on values of such properties gives us classes that we can ef-
fectively align with classes from DB PEDIA. For example, the restriction class formed
from the concept Feature with its value of featureCode property constrained to the in-
stance ‘geonames:A.PCLI’ (Independent political entity) aligns with the Country con-
cept from DB PEDIA. Our algorithm defines restriction classes from the source ontologies
and generates alignments between such restrictions clases using subset or equivalence
relationships.

Defining the Space of Restriction Classes for a Vector The space of restriction
classes to which an instace belongs is simply the powerset of the property-value pairs of
the vector representing the instance. For example assume that the G EONAMES source has
only three properties: rdf:type, featureCode and featureClass; and that the vector for the
instance Saudi Arabia is (geonames:Feature, geonames:A.PCLI, geonames:A). Then
this instance belongs to the restriction class defined by (rdf:type=geonames:Feature &
featureClass=geonames:A). The other sets from the powerset also form such restriction
classes as shown in Figure 1.

(rdf:type=geonames:Feature) (featureCode=geonames:A.PCLI) (featureClass=geonames:A)

(rdf:type=geonames:Feature & featureClass=geonames:A)

(rdf:type=geonames:Feature & featureCode=geonames:A.PCLI) (featureCode=geonames:A.PCLI & featureClass=geonames:A)

(rdf:type=geonames:Feature & featureCode=geonames:A.PCLI & featureClass=geonames:A)

Fig. 1. Hierarchy showing how restriction classes are built

We employ a bottom-up approach to determining the restriction classes to which an
instance belongs. For example, the instance vector for Saudi Arabia directly supports
the restriction class (rdf:type=geonames:Feature & featureCode=geonames:A.PCLI &
featureClass=geonames:A). This restriction in turn supports the three restrictions shown
in Figure 1. These subsequently support restrictions formed by eliminating a constraint
on one of the properties in it. In general, if for the n number of properties for the vector
at the current level we select m properties to constrain our restrictions, then that level
n
would contain m restrictions that represent elements from the combinatorial set C
n

(n,m) from the set S (see Section 3.2). These m restrictions would in turn support
restriction sets formed by choosing (m-1) properties from S (i.e. C (n,m-1)). For a re-
striction at level l we call all the restrictions at level (l-1) that it supports as its parent
restrictions. We can see that, if a restriction is supported by some individuals, then those
individuals also support any of its parent restrictions. Using this hierarchical approach
for any vector, we can build a set of restriction classes that it supports (denoted by R),
in a bottum-up fashion, starting with a restriction class corresponding to the vector. It
is evident that in order to consider all restriction classes, the algorithm would be ex-
ponential. We thus need some preprocessing that eliminates those columns that are not
useful.
3.3 Preprocessing of the data

In order to reduce the search space of alignment hypotheses, we identify properties that
do not contribute to the alignment. Inverse functional properties resemble secondary
keys in databases and identify an instance uniquely. Thus, if a restriction class is con-
strained on the value of an inverse functional property, it would only have a single
element in it. As an example, consider the wikipediaArticle property in G EONAMES.
An instance in G EONAMES has links to multiple pages in Wikipedia, each in a differ-
ent language. For example, the instance for the country Saudi Arabia5 has links to 237
different articles. Each of these in turn, however, could be used to identify only Saudi
Arabia. On the other hand, each of the seven million unique features is also classi-
fied into nine different Feature Classes. Thus, featureCode and featureClass properties
are not inverse functional properties and instances can be grouped by restrictions with
constraints on these properties. We remove a column from the table of vectors if its cor-
responding property is inverse functional. In some of the cases (like the alternateName
and wikipediaArticle) the multivalued properties get eliminated and thus the number of
rows in the flat table gets reduced.
From these individual vectors, we then perform a join on the owl:sameAs property
from G EONAMES such that we get a combination of properties from both ontologies. We
call this concatenation of two vectors an instance pair. In case of multiple vectors for
the same URI (as a result of multivalued properties), we get instance pairs whose count
is equal to the product of the number of vectors from each of the ontologies.

3.4 Forming Alignment Hypotheses

We build our alignment hypothesis in a bottom-up fashion by examining each instance
pair and the restriction classes that its corresponding vector supports. Each align-
ment hypothesis is a two part conjunction of a restriction class from the first ontology
(G EONAMES) and a restriction class from the second one (DB PEDIA). In order to come
up with these hypotheses we look at vectors that compose each of the instance pairs. If
we build a set of restrictions R1 from the first vector and R2 from the second vector,
then the set of hypotheses that this instance pair supports is the Cartesian product of
R1 and R2 . We then would aggregate such hypotheses over all instance pairs and elim-
inate the hypotheses that contain only a singleton set of instance pairs supporting it.
As a result we would be left with alignments supported by multiple instances between
the two sources. In practice however this brute force method is very inefficient in space
and time considerations. Hence we use an algorithm that capitalizes on the set contain-
ment property of the restrictions and thus finds alignments inspired from the bottum-up
method described in Section 3.2.
For building hypotheses of alignments, we begin with each instance pair. We assert
a seed hypothesis such that if vector1 is the first part (from G EONAMES) of this pair and
vector2 is the second part (from DB PEDIA), then the restriction class corresponding to
vector1 (built of constraints on each of its property-value pairs) has an alignment with
the restriction class corresponding to vector2 . Let r1 & r2 be the restriction classes
constituting this hypothesis. We compute P1 & P2 as the set of parent restrictions of
5
http://sws.geonames.org/102358/about.rdf
(featureCode=geonames:A.PCLI) (featureCode=geonames:A.PCLI)
(dbpedia:language=dbpedia:Arabic) (rdf:type=dbpedia:country)

(featureCode=geonames:A.PCLI) (rdf:type=geonames:Feature)
(dbpedia:language=dbpedia:Arabic) (dbpedia:language=dbpedia:Arabic)

(rdf:type=geonames:Feature & featureCode=geonames:A.PCLI)
(dbpedia:language=dbpedia:Arabic)

(featureCode=geonames:A.PCLI)
(rdf:type=dbpedia:country & dbpedia:language=dbpedia:Arabic)

(rdf:type=geonames:Feature & featureCode=geonames:A.PCLI)
(rdf:type=dbpedia:country)

(rdf:type=geonames:Feature)
(rdf:type=dbpedia:country & dbpedia:language=dbpedia:Arabic)

(rdf:type = geonames:Feature & featureCode = geonames:A.PCLI)
(rdf:type = dbpedia:country & dbpedia:language = dbpedia:Arabic)

Fig. 2. Hierarchy showing how hypotheses are built

r1 & r2 . We now build a set of parent hypotheses from the seed source that contains
an alignment from each restriction p1 from P1 to r2 and vice versa. We keep a track
of all our hypotheses and all the instances pairs that support them. If an instance pair
supports one hypothesis, then it also supports all of its parent hypotheses. We can say
this, because the restrictions constituting our hypothesis support their own parent re-
strictions, which in turn constitute our parent hypotheses. This process is illustrated in
Figure 2.

3.5 Evaluating Alignment Hypotheses

After building the hypotheses, we score each hypothesis to ascertain the degree of confi-
dence with which we hold this alignment to be true. For each hypothesis, we refer to the
restriction classes constituting it. We then find all instances belonging to the restriction
class r1 from the first source and r2 from the second source. Figure 3 shows the sets of
such instances. We then compute the image of r1 (denoted by I(r1 )), which is the set
of instances from the second source that form instance pairs with instances in r1 , by
following the owl:sameAs links. The dashed lines in the figure represent these instance
pairs. All the pairs that match both restrictions r1 and r2 also support our hypothesis
and thus is equivalent to the instance pairs corresponding to instances belonging to the
intersection of the sets r2 and I(r1 ). This set of instance pairs that support our hy-
pothesis is depicted as the shaded region. We can now capture subset and equivalence
relations between the restriction classes by set-containment relations from the figure.
For example, if the set of instance pairs identified by r2 are a subset of I(r1 ), then
the set r2 and the shaded region would be entirely contained in the I(r1 ). We use two
metrics P and R to quantify these set-containment relations. Figure 4 summarizes these
metrics and also the different cases of intersection. In order to allow a certain margin
of error induced by the dataset, we are lenient on the constraints and use the relaxed
versions P’ and R’ as part of our scoring mechanism.

r1 r2 Key:
Set of instance pairs where both r1 and r2 holds

Set of instances from O1 where r1 holds

Set of instances from O2 where r2 holds

Set of instances from O2 paired to instances from O1

Instance pairs where both r1 and r2 holds
I(r1) Instance pairs where r1 holds

Fig. 3. Scoring of a hypothesis

Set Relation |𝐼 𝑟1 ∩ 𝑟2| |𝐼 𝑟1 ∩ 𝑟2| P’ R’
P= R=
Representation |𝑟2| |𝑟1|

Disjoint =0 =0 ≤ 0.01 ≤ 0.01

r1 ⊂ r2 <1 =1 > 0.01 ≥ 0.90

r2 ⊂ r1 =1 <1 ≥ 0.90 > 0.01

r1 = r2 =1 =1 ≥ 0.90 ≥ 0.90

0.01 < 0.01 <
Not enough
0