Representing Ecological Network Specifications
with Semantic Web Techniques
Gianluca Torta
, Liliana Ardissono
, Luigi La Riccia
, Adriano Savoca
and Angioletta Voghera
Dipartimento di Informatica, Università di Torino, Italy
Dipartimento Interateneo di Scienze, Progetto e Politiche del Territorio, Torino, Italy
Geographic Knowledge, Geographical Constraints, GeoSPARQL, Ecological Networks, Urban Planning.
Ecological Networks (ENs) are a way to describe the structures of existing real ecosystems and to plan their
expansion, conservation and improvement. In this work, we present a model to represent the specifications for
the local planning of ENs in a way that can support reasoning, e.g., to detect violations within new proposals
of expansion, or to reason about improvements of the networks. Moreover, we describe an OWL ontology
for the representation of ENs themselves. In the context of knowledge engineering, ENs provide a complex,
inherently geographic domain that demands for the expressive power of a language like OWL augmented with
the GeoSPARQL ontology to be conveniently represented. More importantly, the set of specification rules
that we consider (taken from the project for a local EN implementation) constitute a challenging problem for
representing constraints over complex geographic domains, and evaluating whether a given large knowledge
base satisfies or violates them.
New urbanizations, infrastructural networks and in-
tensive agriculture have increased the fragmentation
process of nature, with the consequent reduction of
natural environments and the loss of habitats able to
sustain the wild species and their migrations. The
concept and implementation of Ecological Networks
(ENs) represents a way to describe existing ecosys-
tems and to plan their expansion, conservation and
improvement with the aim of preserving biodiversity
by reducing the fragmentation of the natural environ-
ment (Jongman, 1995). During the past years, the
implementation of ENs at different scales (from Eu-
ropean down to municipality) has received a lot of
attention. Several documents containing guidelines
have been issued for their implementation (Council
of Europe, 2000; Bennett and Wit, 2001; Bennett
and Mulongoy, 2006), challenging the human user
with the dispersion of specifications in different tex-
tual sources. A formal approach to their representa-
tion, suitable for integrating heterogeneous informa-
tion sources, is thus needed.
This paper presents an ontology for the descrip-
tion of ENs, and a constraint specification language
aimed at supporting automatic reasoning with specifi-
cations regarding ENs. We currently focus on detect-
ing violations within new proposals of expansion or
improvement of the EN. However, our approach can
be seamlessly extended to offer other reasoning fea-
tures, such as the automatic proposal of changes and
additions to an existing EN. Our ontology is based on
the outcome of project “Experimental activity of par-
ticipatory elaboration of an ecological network” con-
ducted by the Metropolitan City of Turin (Italy) with
Polytechnic of Turin and ENEA (Città Metropolitana
di Torino, 2014). The project aimed at defining a pro-
posal for the Ecological Network implementation at
the local level in two pilot municipalities near Turin.
The proposed approach was aimed at guiding local
Public Administrations with measures to limit anthro-
pogenic land use and, when possible, orient and qual-
ify the conservation of ecosystem services.
In the context of knowledgeengineering, ENs pro-
vide a complex, inherently geographic domain that
demands an expressive language to be conveniently
represented. Moreover, the EN specifications con-
stitute a challenging problem for representing con-
straints over complex geographic domains, and evalu-
ating if a given (possibly large) knowledge base satis-
fies or violates them. We adopted OWL (W3C, 2012),
augmented by the GeoSPARQL ontology (Perry and
Herring, 2012), for representing the main concepts
characterizing the EN domain. However, regarding
Torta G., Ardissono L., La Riccia L., Savoca A. and Voghera A.
Representing Ecological Network Specifications with Semantic Web Techniques.
DOI: 10.5220/0006573500860097
In Proceedings of the 9th International Joint Conference on Knowledge Discovery, Knowledge Engineering and Knowledge Management (KEOD 2017), pages 86-97
ISBN: 978-989-758-272-1
2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
the representation of EN specifications, we developed
a new language guided by the following main goals:
1. The ability of expressing constraints on the EN
domain in a simple and compact way.
2. The possibility of exploiting the EN specifica-
tions expressed in the language for different auto-
matic tasks, which can’t be implemented by sim-
ply querying an existing KB. For instance, we
do not only consider the validation of a (possi-
bly large) Knowledge Base that represents an EN
by querying its contents, but also (i) checking
the consistency of (partially defined) proposals for
changes/additions to an existing EN, or (ii) auto-
matically suggesting optimized changes or addi-
tions to an existing Ecological Network.
In line with recent research on geometric con-
straint reasoning, e.g., (Ajit et al., 2008; Louwsma
et al., 2006), we have thus defined a high-level lan-
guage, that abstracts from the details of the reason-
ing tasks that it will support. Our language is named
GeCoLan after CoLan (Bassiliades and Gray, 1995),
a language originally devised for Object-Oriented
Databases on which it is strongly based, with restric-
tions and extensions. GeCoLan is aimed at simpli-
fying the definition of complex arithmetic and geo-
metric constraints, as well as supporting rich types of
reasoning in addition to constraint verification. The
proposed language is tailored to the needs of our do-
main, but it is not limited to be used for Ecological
We implemented the EN validation task by au-
tomatically mapping the GeCoLan specifications to
GeoSPARQL queries, in order to exploit existing
technologies for GeoSPARQL processing, rather than
developing a processing engine from scratch. In par-
ticular, we developed a prototype for the automatic
translation and check of EN specifications, using the
efficient validity checks offered by the GeoSPARQL
engine embedded within the Parliament Triple Store
(Battle and Kolas, 2012).
We tested our prototype on a large knowledgebase
derived from project (Città Metropolitana di Torino,
2014), obtaining positive results regarding the effi-
ciency of our approach.
The remainder of this paper is organized as fol-
lows: Section 2 provides some background on ENs
and positions our work in the related literature. Sec-
tion 3 describes our representation of ENs specifica-
tions and provides details about the GeCoLan lan-
guage. Section 4 presents our approach to the vali-
dation of ecological networks and the tool we devel-
oped for that purpose. Section 5 discusses the broader
context of our work, outlining our future research di-
rections. Section 6 concludes the paper.
Figure 1: Diagrammatic representation of the spatial config-
uration of an Ecological Network, from (Bennett and Mu-
longoy, 2006).
Ecological Networks consist of different kinds of ele-
ments: Structural Elements, or core areas (the nodes
of the network, i.e., areas with highest “naturality”);
their Adjoining Areas, or buffers (the areas neigh-
boring the Structural Elements); and Connection El-
ements, or corridors (links of the network, i.e., areas
with residual naturality that connect the Structural El-
ements). Figure 1 depicts the general design of an
Ecological Network.
Several mathematical models have been devel-
oped to analyze and predict the dynamics of ENs in
terms of interactions between organisms in an ecosys-
tem, starting from observational data; e.g., (Ulanow-
icz, 2004; Fath et al., 2007; Lurgi and Robertson,
2011; Gobluski et al., 2016; Pilosof et al., 2017).
These models are aimed at modeling and simulating
the dynamics of the relations among species. Differ-
ently, to our knowledge, no existing works focus on
land-usage constraints, and on how the transforma-
tions of ENs can be regulated in policy-making, tak-
ing such constraints into account.
With the aim of representing knowledge in a
formal way that supports the specification of the
semantics of concepts, we selected OWL (W3C,
2012) to represent the EN domain, augmented by
the GeoSPARQL ontology (Perry and Herring, 2012).
These languages are well known standards supported
by many tools, including highly scalable and efficient
RDF (W3C, 2014) data stores, such as Triple Stores
(Battle and Kolas, 2012). By being Semantic Web
languages, they also seamlessly allow publishing the
information on the Web for (open) access and pro-
cessing, thus favoring knowledge sharing.
A way to represent constraints in the Semantic
Web, is through rule languages, such as SWRL (Se-
mantic Web Rule Language) (Horrocks et al., 2004)
and RuleML (Boley et al., 2001). While the original
expressivity of those rule languages was not general
enough to support constructs such as logic quantifiers,
negation, disjunction, numeric and geometric expres-
sions (all of which typically occur in EN specifica-
tions, as we shall see), subsequent extensions empow-
ered them with the full expressiveness of First-Order
Logic (FOL) (Boley et al., 2004; W3C, 2005). More-
over, some work integrated SWRL with mathemati-
cal, geometrical, and other types of functions through
built-ins; e.g., (Kessler et al., 2009).
Our work introduces the new language GeCoLan
based on CoLan (Bassiliades and Gray, 1995), instead
of extending an existing rule-based language, mainly
because of several syntactic aspects that make it par-
ticularly succinct and convenient for our needs. We
don’t exclude that future evolutions of our research
may make us consider translating GeCoLan to a stan-
dard rule-based language to exploit existing inference
engines for those languages. See section 3.2 for more
Another relevant family of languages devised for
manipulating the data in the Semantic Web are query
languages, e.g. (W3C, 2013; Arenas et al., 2014).
Specifically, SPARQL is a powerful query language
which, beside allowing to access, insert, and update
the triples in a Triple Store, has been used for ex-
pressing and checking constraints over OWL-based
Triple Stores (Fürber and Hepp, 2010). However, the
direct adoption of SPARQL (or of other query lan-
guages) for the description of EN specifications fails
to support reasoning tasks that can’t be implemented
by simply querying an existing KB.
3.1 An OWL Ontology for Ecological
In order to represent the concepts related with Ecolog-
ical Networks and the associated specifications, we
Figure 2: A fragment of the GeoSPARQL ontology with
the Feature class and the Simple Features topological prop-
needed a rich language, able to deal both with the
complexity of individual concepts and with their re-
lations. The following are some key features required
by any candidate language:
ability to model taxonomies: e.g., hierarchies of
land use types, of planned interventions, etc.;
ability to model (and support calculations with)
geographic/geometricshapes of concepts: e.g., el-
ements of the Ecological Network and elements of
land use maps;
ability to specify restrictions on concepts and their
relations: e.g., “coppicing is a maintenance inter-
vention that only applies to wooden areas”.
We selected OWL2 (Grau et al., 2008) to rep-
resent the structure of the data relevant to Ecologi-
cal Networks because it satisfies all of the above re-
quirements, and it is a very well-understood and well-
supported standard for modeling data in the Semantic
The central concept of the EN ontology is the
Feature, a class defined in the GeoSPARQL ontol-
ogy (Battle and Kolas, 2012; OGC, 2012). A Fea-
ture is a SpatialObject that has a Geometry on the
2D plane, which can be either a Point, a Curve (and,
in particular, a piecewise linear curve), or a Poly-
gon. Most interestingly, GeoSPARQL defines a num-
ber of topologic geometric relations between Features
that correspond to the fundamentalrelations identified
in the literature about Geographic Information Sys-
tems: namely, the Simple Features relations (Open
Geospatial Consortium et al., 2011), and the equiv-
alent RCC8 (Cohn et al., 1997), and Egenhofer rela-
tions (Egenhofer, 1989).
Figure 2 shows the Simple Features topological
properties, which relate objects of the SpatialObject
class. By specializing the Feature concept, we define
the four hierarchies of concepts representing the core
of the Ecological Networks domain:
EcologicalNetworkElement represents an element
of the EN, i.e., either a Structural Element, or a
Priority Expansion Element, which is further spe-
cialized to a Connection Element or Adjoining
LandUseElement represents a Land Use Element
(LUE), i.e., a parcel of land defined in the Land
Cover Piemonte (LCP) cartography (Provincia di
Torino, 2014), characterized by a specific type of
land use, e.g., wetland, wooden land, and simi-
lar. The LCP defines 97 different types of land
use at the most detailed level (level 4) of a hi-
erarchy which includes 45 classes at level 3, 15
classes at level 2, and 5 general classes at the
most general level 1. We only model as distinct
classes the values of the first level, namely Water-
Body, WetLand, WoodenLand, AgriculturalLand,
and ArtificialLand. The values of levels 2, 3, and
4 are specified as properties of LandUseElement:
LCPlevel2, LCPlevel3, and LCPlevel4.
Intervention represents an intervention for build-
ing, improving or conserving the EN.
Operation represents a specific operation of elim-
ination, construction or maintenance that is part of
an intervention.
Figure 3 shows a portion of our EN ontology, with
the Feature class and the first levels of the four hi-
erarchies discussed above. Being members of Fea-
ture, any two individuals that belong to the ontol-
ogy classes can be related with each other through
the topological relations mentioned above. For ex-
ample, a ConnectionElement may touch a number of
LandUseElements, where, intuitively, the Simple Fea-
tures touches relation between 2D areas A, B holds
whenever the borders (but not the interiors) of A, B
have a non-empty intersection.
In order to characterize the classes and properties
used in our ontology, we exploit the powerful con-
structs of the OWL2 language (in particular,Class Ex-
pressions) in several places. For example:
the hasPlants property applies to LUEs of types
WoodenLand and AgriLand. The domain of has-
Plants is therefore the following OWL Class Ex-
pression (in functional syntax):
ObjectUnionOf(WoodenLand AgriLand)
the hasArea property applies to Features whose
geometry is a Surface. The domain of hasArea is
therefore the following OWL Class Expression:
AllValuesFrom(hasGeometry Surface)
the Coppicing class (subclass of the Maintenance
operation) should have a linear geometry. Class
Coppicing is therefore also a subclass of the fol-
lowing Class Expression:
AllValuesFrom(hasGeometry LineString)
the Eradication class (subclass of the Elimina-
tion operation) should only intersect LUEs of
type WoodenLands (first level of the LCP hierar-
chy); furthermore, such elements should have an
LCPlevel2 value of either “ShrubbyGrassyZone”
or “OpenZone”. Class Eradication is therefore
also a subclass of the following Class Expression:
It is worth noting that all of the above examples are
constraints on the classes and properties of the EN on-
tology. In particular, we regard them as integrity con-
straints on the vocabulary defined by the ontology:
for example, it would be meaningless to have an ele-
ment of the Coppicing class with a non-linear geom-
etry, or an Eradication operation over an urban area.
On the contrary, the EN specifications described in
the next section are meant to constrain the way we are
allowed to plan an Ecological Network, and may pos-
sibly be violated by existing ENs that have not been
correctly planned. This is an important reason to en-
code the two types of constraints differently, besides
the fact that OWL has limits on the logic constraints
that it can express (Krötzsch, 2010).
3.2 A Language for Representing EN
As previously stated, the EN specification language
we developed is aimed at supporting various types of
reasoning about constraints on ENs. For that purpose,
it must:
use the terms defined in the EN ontology (classes
and properties) as its main vocabulary;
be able to express constraints about the objects of
the world modeled by the ontology;
be able to mix logic, geometric, numeric, and time
requirements into the constraints.
We defined a language for the representation of EN
specifications that is strongly influenced by CoLan,
a language initially proposed for expressing integrity
constraints in Object-Oriented Databases (Bassiliades
Figure 3: A fragment of the EN ontology.
and Gray, 1995), and later used as the basis for
the Constraint Interchange Format (CIF), an RDF
schema for exchanging constraints on the Seman-
tic Web (Gray et al., 2001). We named our lan-
guage GeCoLan, given that it is intended to capture
geometric and geographic constraints, beside more
traditional types of constraints captured by CoLan.
GeCoLan inherits the expressivity and understand-
ability of CoLan, with some changes and additions
tailored to the requirements of our domain.
Compared to rule-based languages such as SWRL
and RuleML (evenin their extensions with First Order
Logic), GeCoLan has a number of syntactic features
that make it particularly convenient for our purposes:
it allows the use of nested functions that
correspond either to functions defined in
(Geo)SPARQL, or to functional properties of the
ontology classes. For example,
LCPlevel2(el )
indicates the value of the (functional) property
LCPlevel2 of variable el, while:
intersection(l3, l4))
indicates the distance between the intersection
area of variables l1 and l2, which are Well Known
Text (WKT) literals (i.e., serializations of geome-
tries), and the intersection area of variables l3 and
it allows the use of infix relational and arithmetic
operators in expressions over complex terms. For
{distance(l1, l2) >= 2 distance(l1,l3)}
means that the distance between the WKT literal
values of variables l1 and l2 is at least twice as the
distance between the values of l1, l3. Similarly,
{irreversibility(el) < 3 ||
extroversion(el) < 3)}
constrains the values of functional properties irre-
versibility and extroversion of variable el.
it allows the quantifiers forall and exists with
range restricted variables:
forall C(x)[s.t. ψ(x)]ϕ(x)
exists C(x)[s.t. ψ(x)]ϕ(x)
where C is the name of a class of the ontology,
x is a variable that represents an individual, and
ψ(x) is an optional formula that further restricts
the individuals of C we are interested in. For
example, for all NewP lanting(np) states that
the value of variable np can be any individual be-
longing to class NewPlanting. If we add a condi-
tion s.t. compens ates(np , el)”, only individu-
als np that compensate some given elimination el
will be considered.
These features can be viewed as syntactic sugar over
the constructs of rule based languages, and it is indeed
conceivable to automatically translate a GeCoLan ex-
pression into, e.g., a less concise SWRL FOL expres-
sion. In this vein, in section 4 we discuss a translation
of GeCoLan to GeoSPARQL in order to take advan-
tage of existing SPARQL engines (which are based
on closed-world semantics) for validating GeCoLan
specifications by querying existing KBs. Currently,
we haven’t yet found a compelling reason for translat-
ing GeCoLan to a rule language for exploiting exist-
ing inference engines for those languages (which are
based on open-world semantics), but this may change
in the future as we consider other reasoning tasks to
tackle with GeCoLan (section 3.4).
To complete the desctiption of GeCoLan, we have
to add that it allows the usual connectives an d, or,
not, and implies of First Order Logic (FOL), while
the atoms can be in one of the following forms:
property predicates p(t1, t2), where p is the
name of a property defined in the ontology, t
is a
term (see below) representing an individual in the
domain of p, and t
is a term representing an indi-
vidual in the range of p, e.g., sfTouches(g1, g2)
states that the value of variable g1 (which is a Ge-
ometry) touches the value of variable g2 (another
filter expressions {e}
; a filter expression e (en-
closed in braces {, }) can use the logic connec-
(or), and
(not) between condi-
tions built with relational operators
. The operands of such relational operators are
terms or numeric expressions obtained by com-
bining numeric operands with operators
As mentioned above, the terms appearing in the
property predicates and filter expressions are:
literal values (numbers, strings, etc.);
function calls whose argoments are themselves
Since we aim at expressing constraints that can be
either satisfied or violated by the knowledge base, we
are only interested in closed formulas, i.e. formulas
where all the variables are within the scope of a cor-
responding quantifier.
3.3 Example Specifications
In order to illustrate the efficacy of the language for
our purposes, let us consider the representation of two
specifications taken from the guidelines for the Lo-
cal EN implementation near Turin devised in project
(Città Metropolitana di Torino, 2014). The first one is
about Connection Elements and requires that:
Connection elements avoid areas with maxi-
mum irreversibility and areas with maximum
As we shall see in section 4.1, filter expressions corre-
spond to whole constraints to be evaluated in the FILTER
clause of SPARQL
Using the vocabulary of the EN ontology, this
constraint is satisfied if a ConnectionElement does
not overlap with any LandUseElements whose irre-
versibility or extroversion properties have the maxi-
mum value. It is worth briefly mentioning that each
LandUseElement is characterized by five evaluation
criteria: naturality (how close the element is to a nat-
ural environment), relevance (howrelevant it is for the
conservation of the habitat), fragility (how fragile it is
w.r.t. the anthropogenic pressure), extroversion (how
much pressure it can exert on the neighbouring areas),
and irreversibility (how difficult it would be to change
its use). The value for each criterion ranges from 1
to 5, with 1 representing the maximum value. One
possible encoding of the specification in GeCoLan is
therefore as follows:
forall ConnectionElement(ce)
forall LandUseElement(lue) such that
sfOverlaps(ce, lue)
{irreversibility(lue) > 1 &&
extroversion(lue) > 1}
The formula starts with two universal quantifiers. The
first one restricts the range of variable ce, that must be
a ConnectionElement. The second one restricts vari-
able lue, that must be a LandUseElement, and must
have a geometry G that overlaps with the geometry of
The body is a filter expression stating that both
the irreversibility and the extroversion of lue must
have a higher value than 1. Although this example is
rather simple, it already makes use of several features
of our ontology and language, in particular:
the ability to automatically find the LandUseEle-
ments that fall (at least partially) within a Con-
nectionElement - this is provided by the geometric
capabilities of GeoSPARQL;
the ability to perform numeric comparisons be-
tween the values of some (functional) properties
of LandUseElements and a numeric constant - this
is provided by the filter expressions.
Let us now consider a more complexexample, regard-
ing the creation of Buffer Zones to protect the ele-
ments of the EN:
The creation of protection buffers is done,
whenever possible, through interventions of
restoration in areas surrounding the struc-
tural elements of the net, with the goal of
enhancing and protecting them. In case a
structural element is surrounded by areas with
In GeoSPARQL, the topological relations such as
sfOverlaps are computed on the geometries associated with
the individuals in class Feature (lue and ce in our example)
through the defaultGeometry property.
maximum extroversion and/or maximum irre-
versibility, the buffers must be realized within
the structural element (due to the impossibility
of extending the element itself).
Using the vocabulary of the EN ontology,a Buffer-
Creation is an Intervention of Conservation that
touches a StructuralElement of the net, except when,
in such a way, it would overlap with one or more Lan-
dUseElements with maximum irreversibility or extro-
version. In that case, the BufferCreation should be
within the StructuralElement; see Figure 4, where the
two cases are denoted as (a) and (b). One possible en-
coding of the specification in GeCoLan is as follows:
forall BufferCreation(bc)
forall StructuralElement(sel )
forall LandUseElement(lue) such that (not sfWithin(lue, sel))
((sfTouches(bc, sel) and sfOverlaps(bc, lue))
{(irreversibil ity(lue) > 1) and (extroversion(lu e) > 1)})
((sfWithin(bc, sel) and s fTouches(bc, lue))
{(irreversibil ity(lue) = 1) or (extroversion(lue) = 1)})
The formula starts with universal quantifiers specify-
ing the classes of variables bc, sel, and lue. The quan-
tification of lue further restricts the attention to Lan-
dUseElements whose geometry is not within (i.e. part
of) the geometry of StructuralElement sel. The body
is the conjunction of two sub-specifications, corre-
sponding to the different cases (a) and (b) of Figure 4:
if (the geometry of) bc touches sel, then each lue that
(partially) overlaps with bc must have non-maximum
irreversibility and extroversion. Differently, if bc is
within sel, then each lue touched by bc must have
maximum irreversibility and/or extroversion.
3.4 Reasoning with Specifications
It is worth considering at this point some reasoning
tasks that may benefit from the specifications illus-
trated in our examples. As stated in the introduc-
tion, we currently focus on validation tasks aimed
at checking whether a given EN satisfies the speci-
fications or not. However, other interesting reason-
ing tasks can exploit GeCoLan specifications, and we
want to briefly discuss some of them before diving
into the details of our implementation of the valida-
tion task.
As an example, let us consider the task of check-
ing the Connection Elements specification of the
previous section. That means considering each Con-
nectionElement ce in the Triple Store, and verifying
that all of the LandUseElements overlapping with ce
satisfy the given restrictions on the extroversion and
irreversibility properties. This kind of check can be
done by looking at the contents of the Triple Store
and ensuring that they don’t conflict with the specifi-
cations. The underlying assumption is that all of the
relevant facts are present in the store (closed world
semantics), so that, e.g., if a required fact is missing
from the store, a violation is detected.
A natural extension of such a validation would
be to attempt suggesting how to fix the detected vi-
olations. For example, it is quite plausible that the
check of the Connection Elements specification may
return a list of pairs (ce, lue) indicating which Lan-
dUseElements lue that overlap with some Connec-
tionElements ce have invalid extroversion and/or ir-
One way to remove the inconsistency, would be to
remove the ConnectionElement ce from the KB.
However, this might cause an even worse incon-
sistency in the KB, because another specification
(not considered in our examples) states that any
two StructuralElements of the EN must be con-
nected through elements of the EN. Thus, remov-
ing ce may cause two or more StructuralElements
to become mutually unreachable.
Another way to remove the inconsistency of a pair
(ce, lue) w.r.t. the Connection Elements spec-
ification would be to reduce the geometry of ce
so that it no longer overlaps with the “bad” Lan-
dUseElement lue; however, this might cause the
disconnection of elements of the EN, including a
possible separation of ce itself into different parts.
An even more challenging task would be to ask an
automated reasoner to suggest how to connect a new
StructuralElement sel to the rest of the EN, by propos-
ing a path of new ConnectionElements that lead from
sel to an existing element of the net.
The Connection Elements specification is rele-
vant to all the tasks we have mentioned (and to many
others), but clearly not all of them can be solved
by simply querying the KB through a language like
SPARQL. Some tasks may require reasoning engines
such as, e.g., Prolog, Answer Set Programming, and
Constraint Programming, or even specialized reason-
ers for 2D geometric reasoning. For example, let us
assume that some EN specifications were translated
to a CSP (Constraint Satisfaction Problem) for an EN
containing a pair (ce, lue) which violates Connection
Elements. If the following facts were retracted from
the CSP:
ConnectionElement ce.
overlaps(ce, lue).
irreversibility(lue) = 1.
extroversion(lue) = 1.
Figure 4: Graphical representation of the two cases of the specification for Buffer Zones.
we may expect a CSP solver to be able to suggest a
change to the type of ce, and/or to its overlapping with
lue, and/or to the attributes of lue, that satisfies the
Connection Elements specification while preserving
the connection of the EN elements (if this latter con-
straint is encoded in the CSP).
Of course, this is just an illustrative example, and
a systemathic proposal for exploiting the EN specifi-
cations for the kinds of reasoning we mentioned will
require further research work. The point that we want
to stress here, is that by adopting a higher-level lan-
guage such as GeCoLan for encoding the specifica-
tions, we can then (re-)use such specifications as in-
puts to an appropriate combination of reasoners for
solving different and possibly more complex tasks.
4.1 Translating Specifications to
GeoSPARQL Queries
In order to check whether the specifications discussed
in the previous section are satisfied by an exist-
ing knowledge base, we translate them to equivalent
GeoSPARQL queries, that can be executed by any
engine that supports the GeoSPARQL standard; e.g.,
Parliament (Battle and Kolas, 2012).
Given a closed formula φ in the GeCoLan lan-
guage, we want to translate it to a GeoSPARQL query
KB |= φ
0 φ = exists C(x)ϕ(x)
0 φ = not exists C(x)ϕ(x)
where φ is in either one of the above forms (as we
shall shortly see all formulas of GeCoLan are con-
verted in one of these forms before translating them
to SPARQL), KB is the Triple Store against which we
want to evaluate φ, and [[q
denotes the result of
applying q
to KB.
Similarly to (Angles and Gutierrez, 2008;
Kostylev et al., 2015), we define the translation induc-
tively. First of all, we consider some rewritings of φ
into equivalent GeCoLan formulas in order to reduce
the number of cases we have to explicitly translate:
forall C(x) ϕ T (not exists C(x) (not ϕ))
exists C(x) s.t.ψ (ϕ) T (exists x
(C(x) and (ψ implies ϕ)))
ϕ implies ψ T (not ϕ or ψ)
After these rewritings, formula φ starts either with
not exists C(x)”, or “exists C(x)”. Before start-
ing the translation, we remove such a prefix from
φ so that the values returned by the query are not
completely projected out; see the example below.
Whether φ is satisfied or not by KB depends on the
result of the application of the translation of φ to KB,
according to equation (1).
Having got rid of the forall quantifier and the
implies connective, let us now consider the transla-
tion of the remaining quantifiers and connectives. For
finite domain classes C
, .. . ,C
, we define the cross
product of their domains as:
, . . . , x
) = {x
rdf : type C
rdf : type C
We then define the following translations:
exists x ϕ SELECT (free(ϕ) {x}) WHERE {T (ϕ)}
ϕ or ψ T (ϕ) UNION T (ψ)
ϕ and ψ {T (ϕ) T (ψ)}
¬ϕ {ADom(free(ϕ)) FILTER NOT EXISTS T (ϕ)}
The translation of exists involves the projection
of variable x through a subquery, since x should no
longer appear in outer formulas. The translations
of or and and connectors are mapped, respectively,
to the UNION clause of SPARQL and to a sequence
of graph patterns. Finally, negation of ϕ maps to a
FILTER NOT EXISTS clause between the domains of
the free variables and their assignments satisfying ϕ.
We still need to describe the translation of the
atoms of GeConLan:
C(x) {x rdf : type C.}
p(t1, t2) {T (t1) T (t2) x1 p x2.}
{e(t1, ..., tn)} T (t1) ...T (tn) FILTER e(x1, ..., xn)
The class C of a variable x is translated as a graph
pattern with predicate rdf : type. Let us consider the
translation of p(t
). First of all, we need to trans-
late the terms t
, t
themselves. For example, let the
property atom be:
member(hasPlants(lue), "Rudbekia")
where t
is hasPlants(lue), i.e., the application of a
functional property hasPlants to a LandUseElement
lue; the hasPlants property maps lue to a Collection
element col. We need to introduce a new variable x
for representing the value of such property, and add
the pattern {lue hasPlants x1} to the translation.
Then, to complete the translation, we add the pattern
{x1 member "Rudbekia"} to state that Rudbekia is
a member of the x1 collection. The translation of fil-
ter expressions requires a similar approachto generate
variables corresponding to applications of functional
Let us now illustrate the translation method de-
scribed above by applying it to the Connection El-
ements example introduced in section 3.3. First, the
GeCoLan formula is transformed in order to eliminate
the forall quantifiers:
not exists ConnectionElement(ce)
exists LandUseElement(lue)
not (sfOverlaps(ce,lue) implies
{irreversibility(lue) > 1 &&
extroversion(lue) > 1})
and then to eliminate the implies connective:
not exists ConnectionElement(ce)
exists LandUseElement(lue)
(sfOverlaps(ce, lue) and
not{irreversibility(lue) > 1 &&
extroversion(lue) > 1})
Let us consider the translation of the filter expression:
= {{lue irreversibility ir.}
{lue extroversion ex.}
FILTER ((ir > 1) && (ex > 1))}
Two new variables (that we have named ir and ex
for readability) have been automatically added to hold
the values of the irreversibility and extroversion prop-
erties of lue. Then, the filter expression (where the
property applications have been replaced with ir, ex)
becomes the argument of a FILTER clause.
As the range expression for ce, lue is:
= {ce rdf : type ConnectionElement.
lue rdf : type LandUseElement.}
the translation of the negation (not) of the filter ex-
pression is:
= {τ
By applying the translation rules for the property
predicates and conjunctions, we obtain the following
translation for the body of the formula:
= {{ce sfOverlaps lue.} τ
Finally, we translate the existential quantifier on lue
and class restrictions on lue, ce using the associated
= SELECT (ce) WHERE {τ
As already mentioned, we do not translate the first
existential quantifier on ce, because this would leave
no variables. According to equation 1, given that the
original formula started with not exists, it is satis-
fied if query τ
4.2 A Tool for Automated Translation
and Query Execution
We developed a parser to convert GeCoLan for-
mulas into GeoSPARQL queries with the ANTLR
parser generator (, which was
chosen due to its power and relative simplicity of use.
Based on the formal specification of the grammar of
the GeCoLan language, ANTLR generated a generic
parser based on the Visitor design pattern (Gamma
et al., 1994). We then extended this parser to pro-
duce the correct GeoSPARQL fragments according to
the grammar rules. After translating a formula, the
tool submits it to the Parliament Triple Store through
the Jena ( library for execu-
tion. The result returned by the Triple Store is then
interpreted in order to determine whether the data in
the Triple Store satisfies the EN specification or not.
The geospatial data we used was obtained from a
series of ESRI shapefiles produced in project (Città
Metropolitana di Torino, 2014), which we converted
to RDF using GeoTriples (Kyzirakos et al., 2014).
That tool allows the user to define an appropriate
mapping in order to associate shapefiles attributes to
RDF properties. Figure 5 shows part of the map we
used, where land use elements are colored according
Figure 5: A portion of the map of the area covered by the
Local EN proposal.
to their first level LCP type, e.g., artificial land is gray,
water bodies are light blue, and so forth.
We uploaded to Parliament all the project data
located within a circle of 10km diameter centered
at a given point on the map of municipalities near
Turin. Overall, the data consisted of 183,752 triples.
More specifically, within the considered circle there
are 5162 LandUseElements, over which lay the el-
ements of the EN: i.e., 579 StructuralElements and
1054 ConnectionElements.
We first tested the Connection Elements example
from section 3.3, whose translation has just been il-
lustrated. The query is challenging because it could
require to consider all the pairs formed by a Lan-
dUseElement and a ConnectionElement. Overall, our
Triple Store contains almost 5.5M such pairs, and
complex operations had to be performed on each pair,
such as checking whether the LandUseElement and
ConnectionElement geometries overlapped.
The execution of the query took about 5.5 minutes
on a medium-end laptop, pointing out that (according
to the data in our Triple Store), 595 ConnectionEle-
ments of the EN intersected at least a LandUseEle-
ment of maximum irreversibility or extroversion. This
means that, in the project data, more than 55% of
the ConnectionElements (595 out of 1054) violate the
specification. The evaluation of whether these are se-
vere violations of the considered specification, or ac-
ceptable small overlaps with forbidden areas, is left to
the human user.
We also tested the Buffer Zones example from
section 3.3. The translation of the specification is
complex and yields a GeoSPARQL query with four
(partially nested) SELECTs and 44 lines. However,
the execution took only a few seconds before answer-
ing that there are no violating Buffer Creations in our
data. The impressive efficiency of this query is ex-
plained by the fact that the number of pending Inter-
ventions of type Buffer Creation is usually small at a
given time; e.g., in the dataset we considered, there
was only one such a pending intervention. The num-
ber of LandUseElements and StructuralElements that
must be considered by the query is therefore strongly
limited by the fact that they must be “close” to the
Buffer Creations; i.e., they touch, or overlap with
The study and implementation of additional reasoning
tasks based on GeCoLan represents one of the most
important directions of our future work.
Whereas, at the current stage, we implemented the
validation as a stand-alone prototype, the main moti-
vation and application of our work lies in its possi-
ble integration within Participatory Geographical In-
formation Systems (PGIS), in order to support on-
line interaction with stakeholders in inclusive pro-
cesses aimed at collecting feedback and project pro-
posals from stakeholders. This would be a novel
feature of PGIS (e.g., see Ushahidi (,
PlanYourPlace ( OnToMap (on-, which only support feedback
collection, and fail to provide validation functions to
check the feasibility of the proposed actions. Specif-
ically, in order to facilitate the convergence towards
mutually agreed and feasible plans, it might be inter-
esting to know how far the constraints on land us-
age are satisfied in a certain area, or whether any
hypothetical actions, e.g., related to redevelopment
project plans, are compatible with them. The present
work is suitable for answering this kind of question by
proposing a model for verifying the compliance of a
set of geo-data with specifications concerning the re-
lated geographical area. Although in this paper we
focus on the preservation and reconstruction of the
Ecological Networks, this type of model can be ap-
plied in rather different contexts, including the man-
agement of city plans, in which detailed constraints
have to be satisfied when building new elements or
remodeling existing ones.
Another line of research we will pursue concerns
the improvement of the efficiency of validity checks.
While our prototype implementation has shown the
feasibility of the approach in a domain of realistic
size, we believe there are many different ways to im-
prove its scalability: firstly, we would like to con-
sider if and how the GeoSPARQL queries produced
by our translator can be automatically optimized in
order to better exploit the operational semantics of
GeoSPARQL and of its implementation(s); secondly,
it would be worth to explore whether there exist any
Triple Store that supports GeoSPARQL queries more
efficiently than Parliament; finally, pre-computing
and storing certain information (e.g., which elements
intersect with which) may turn out to be advantageous
for the subsequent check of specifications.
Ecological Networks (ENs) describe the structure of
existing real ecosystems and to plan their expansion,
conservation and improvement. In this paper we pro-
posed an OWL ontology for the representation of
ENs. Moreover, we presented the GeCoLan language
for expressing specifications about Ecological Net-
works planning, which allows for the automatic val-
idation of OWL-based representations of networks
against existing land-usage restrictions. GeCoLan can
be automatically translated to GeoSPARQL queries
for implementing the validation checks in an efficient
way. Moreover, the language can support not only
the verification of constraints in a geographical area,
but also other reasoning tasks, such as making con-
structive suggestions, possibly optimizing some de-
sired measure.
This work is partially funded by project MIMOSA
(MultIModal Ontology-driven query system for the
heterogeneous data of a SmArtcity, “Progetto di
Ateneo Torino_call2014_L2_157”, 2015-17) and by
“Ricerca Locale” of the University of Torino.
Ajit, S., Sleeman, D., Fowler, D. W., and Knott, D. (2008).
Constraint capture and maintenance in engineering
design. Artificial Intelligence for Engineering Design,
Analysis and Manufacturing, 22(04):325–343.
Angles, R. and Gutierrez, C. (2008). The expressive power
of sparql. In Proc. International Semantic Web Con-
ference, pages 114–129.
Arenas, M., Gottlob, G., and Pieris, A. (2014). Expressive
languages for querying the semantic web. In Proceed-
symposium on Principles of database systems, pages
14–26. ACM.
Bassiliades, N. and Gray, P. (1995). Colan: A functional
constraint language and its implementation. Data &
Knowledge Engineering, 14(3):203–249.
Battle, R. and Kolas, D. (2012). Enabling the geospatial
Semantic Web with Parliament and GeoSPARQL. Se-
mantic Web, 3(4):355–370.
Bennett, G. and Mulongoy, K. (2006). Review of expe-
rience with ecological networks, corridors and buffer
zones. Technical Series, 23.
Bennett, G. and Wit, P. (2001). The development and appli-
cation of ecological networks: a review of proposals,
plans and programmes. AIDEnvironment.
Boley, H., Dean, M., Grosof, B., Sintek, M., Spencer, B.,
Tabet, S., and Wagner, G. (2004). FOL RuleML: The
first-order logic web language. Document located on-
line at http://www. ruleml. org/fol.
Boley, H., Tabet, S., and Wagner, G. (2001). Design ratio-
nale of ruleml: A markup language for semantic web
rules. In Proceedings of the First International Con-
ference on Semantic Web Working, pages 381–401.
CEUR-WS. org.
Città Metropolitana di Torino (2014). Misura
323 del psr 2007-2013 (in italian). http://
Cohn, A., Bennett, B., Gooday, J., and N., G. (1997). Quali-
tative spatial representation and reasoning with the re-
gion connection calculus. GeoInformatica, 1(3):275–
Council of Europe (2000). General guidelines for the devel-
opment of the pan-european ecological network. Na-
ture and environment, 107.
Egenhofer, M. (1989). A formal definition of binary topo-
logical relationships. In Proc. Int. Conf. on Foun-
dations of Data Organization and Algorithms, pages
Fath, B., Sharler, U., Ulanowicz, R., and Hannon, B. (2007).
Ecological network analysis: network construction.
Trends in Ecology & Evolution, 208:49–55.
Fürber, C. and Hepp, M. (2010). Using sparql and spin
for data quality management on the semantic web. In
Proc. Business Information Systems, pages 35–46.
Gamma, E., Helm, R., Johnson, R., and Vlissides, J.
(1994). Design patterns: Elements of Reusable
Object-Oriented Software. Addison-Wesley.
Gobluski, A., Westlund, E., Vandermeer, J., and Pascual,
M. (2016). Ecological networks over the edge: Hyper-
graph trait-mediated indirect interaction (TMII) struc-
ture. Trends in Ecology & Evolution, 31(5):344–354.
Grau, B., Horrocks, I., Motik, B., Parsia, B., Patel-
Schneider, P., and Sattler, U. (2008). OWL 2: The
next step for OWL. Web Semantics: Science, Services
and Agents on the World Wide Web, 6(4):309–322.
Gray, P., Hui, K., and Preece, A. (2001). An expressive
constraint language for semantic web applications. In
E-Business and the Intelligent Web: Papers from the
IJCAI-01 Workshop, pages 46–53.
Horrocks, I., Patel-Schneider, P., Boley, H., Tabet, S.,
Grosof, B., and Dean, M. (2004). SWRL: A seman-
tic web rule language combining OWL and RuleML.
W3C Member submission, 21.
Jongman, R. (1995). Nature conservation planning in eu-
rope: developing ecological networks. Landscape and
urban planning, 32(3):169–183.
Kessler, C., Raubal, M., and Wosniok, C. (2009). Seman-
tic rules for context-aware geographical information
retrieval. In Proceedings of the 4th European Con-
ference on Smart Sensing and Context, EuroSSC’09,
pages 77–92. Springer-Verlag.
Kostylev, E., Reutter, J., and Ugarte, M. (2015). Construct
queries in sparql. LIPIcs-Leibniz International Pro-
ceedings in Informatics, 31.
Krötzsch, M. (2010). Description Logic Rules, volume 8 of
Studies on the Semantic Web. IOS Press.
Kyzirakos, K., Vlachopoulos, I., Savva, D., Manegold,
S., and Koubarakis, M. (2014). Geotriples: A tool
for publishing geospatial data as RDF graphs us-
ing R2RML mappings. In Proceedings of ISWC
2014 - Posters and Demonstrations Track - Volume
1272, ISWC-PD’14, pages 393–396, Aachen, Ger-
many, Germany.
Louwsma, J., Zlatanova, S., van Lammeren, R., and van
Oosterom, P. (2006). Specifying and implementing
constraints in GIS - with examples from a geo-virtual
reality system. GeoInformatica, 10(4):531–550.
Lurgi, M. and Robertson, D. (2011). Automated experimen-
tation in ecological networks. Automated Experimen-
tation, 3(1).
OGC (2012). Geosparql vocabulary. http://schemas.
Open Geospatial Consortium et al. (2011). OpenGIS Im-
plementation Standard for Geographic information-
Simple feature access-Part 1: Common architecture.
Perry, M. and Herring, J. (2012). GeoSPARQL - a geo-
graphic query language for RDF data. OGC Imple-
mentation Standard. Sept.
Pilosof, S., Porter, M., Pascual, M., and Kefi, S. (2017).
The mulutilayer nature of ecological networks. Nature
ecology&evolution, 1:article 101.
Provincia di Torino (2014). Linee guida per le reti
ecologiche (in italian). http://www.provincia.torino. terri-
toriale/rete_ecologica/ lgsv_lgre.pdf.
Ulanowicz, R. (2004). Quantitative methods for ecological
network analysis. Computational biology and chem-
istry, 28:321–339.
W3C (2005). A Proposal for a SWRL Extension towards
First-Order Logic.
W3C (2012). Web ontology language (OWL). https://
W3C (2013). SPARQL query language for RDF. https://
W3C (2014). Resource description framework (RDF).