Representing Ecological Network Speciﬁcations

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

Keywords:

Geographic Knowledge, Geographical Constraints, GeoSPARQL, Ecological Networks, Urban Planning.

Abstract:

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 speciﬁcations 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 speciﬁcation 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 satisﬁes or violates them.

1 INTRODUCTION

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 speciﬁcations 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 speciﬁcation language

aimed at supporting automatic reasoning with speciﬁ-

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 deﬁning 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 speciﬁcations con-

stitute a challenging problem for representing con-

straints over complex geographic domains, and evalu-

ating if a given (possibly large) knowledge base satis-

ﬁes 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 Speciﬁcations 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

the representation of EN speciﬁcations, 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 speciﬁca-

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 deﬁned) 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 deﬁned 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 deﬁnition of complex arithmetic and geo-

metric constraints, as well as supporting rich types of

reasoning in addition to constraint veriﬁcation. The

proposed language is tailored to the needs of our do-

main, but it is not limited to be used for Ecological

Networks.

We implemented the EN validation task by au-

tomatically mapping the GeCoLan speciﬁcations 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 speciﬁcations, using the

efﬁcient 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 efﬁ-

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 speciﬁca-

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 conﬁg-

uration of an Ecological Network, from (Bennett and Mu-

longoy, 2006).

2 BACKGROUND AND RELATED

WORK

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 speciﬁcation 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 efﬁcient

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 quantiﬁers,

negation, disjunction, numeric and geometric expres-

sions (all of which typically occur in EN speciﬁca-

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

details.

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).

Speciﬁcally, 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 speciﬁcations fails

to support reasoning tasks that can’t be implemented

by simply querying an existing KB.

3 REPRESENTATION OF

ECOLOGICAL NETWORKS

3.1 An OWL Ontology for Ecological

Networks

In order to represent the concepts related with Ecolog-

ical Networks and the associated speciﬁcations, we

Figure 2: A fragment of the GeoSPARQL ontology with

the Feature class and the Simple Features topological prop-

erties.

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 satisﬁes all of the above re-

quirements, and it is a very well-understood and well-

supported standard for modeling data in the Semantic

Web.

The central concept of the EN ontology is the

Feature, a class deﬁned 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 deﬁnes a num-

ber of topologic geometric relations between Features

that correspond to the fundamentalrelations identiﬁed

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 deﬁne

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

Area.

• LandUseElement represents a Land Use Element

(LUE), i.e., a parcel of land deﬁned in the Land

Cover Piemonte (LCP) cartography (Provincia di

Torino, 2014), characterized by a speciﬁc type of

land use, e.g., wetland, wooden land, and simi-

lar. The LCP deﬁnes 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 ﬁrst level, namely Water-

Body, WetLand, WoodenLand, AgriculturalLand,

and ArtiﬁcialLand. The values of levels 2, 3, and

4 are speciﬁed as properties of LandUseElement:

LCPlevel2, LCPlevel3, and LCPlevel4.

• Intervention represents an intervention for build-

ing, improving or conserving the EN.

• Operation represents a speciﬁc 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 ﬁrst 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 (ﬁrst 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:

AllValuesFrom(sfIntersects

(ObjectIntersectionOf(WoodenLand

(DataAllValuesFrom(LCPlevel2

DataOneOf("ShrubbyGrassyZone"

"OpenZone")))))

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 deﬁned 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 speciﬁcations 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

Speciﬁcations

As previously stated, the EN speciﬁcation language

we developed is aimed at supporting various types of

reasoning about constraints on ENs. For that purpose,

it must:

• use the terms deﬁned 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 deﬁned a language for the representation of EN

speciﬁcations that is strongly inﬂuenced by CoLan,

a language initially proposed for expressing integrity

constraints in Object-Oriented Databases (Bassiliades

Feature

ENElement

LandUseEl

Intervention

Operation

comprises

StructuralEl

PrioExpEl

ConnectionEl

AdjoiningArea

NewPlanting

Maintenance

Elimination

compensates

WaterBody

AgriLand

Artificial

WoodenLand

WetLand

string

LCPlvl2

LCPlvl1

LCPlvl3

LCPlvl4

Building

Improvement

Conservation

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 deﬁned 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:

distance(intersection(l1,l2),

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

l4.

• it allows the use of inﬁx relational and arithmetic

operators in expressions over complex terms. For

example:

{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 quantiﬁers 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

speciﬁcations 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 deﬁned 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

Geometry);

• ﬁlter expressions {e}

; a ﬁlter expression e (en-

closed in braces {, }) can use the logic connec-

tives

(and),

(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 ﬁlter expressions are:

• literal values (numbers, strings, etc.);

• variables;

• function calls whose argoments are themselves

terms.

Since we aim at expressing constraints that can be

either satisﬁed 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 quantiﬁer.

3.3 Example Speciﬁcations

In order to illustrate the efﬁcacy of the language for

our purposes, let us consider the representation of two

speciﬁcations taken from the guidelines for the Lo-

cal EN implementation near Turin devised in project

(Città Metropolitana di Torino, 2014). The ﬁrst one is

about Connection Elements and requires that:

Connection elements avoid areas with maxi-

mum irreversibility and areas with maximum

extroversion.

As we shall see in section 4.1, ﬁlter 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 satisﬁed if a ConnectionElement does

not overlap with any LandUseElements whose irre-

versibility or extroversion properties have the maxi-

mum value. It is worth brieﬂy mentioning that each

LandUseElement is characterized by ﬁve 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 difﬁcult 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 speciﬁcation 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 quantiﬁers. The

ﬁrst 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

ce.

The body is a ﬁlter 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 ﬁnd 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 ﬁlter 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 speciﬁcation 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))

implies

{(irreversibil ity(lue) > 1) and (extroversion(lu e) > 1)})

and

((sfWithin(bc, sel) and s fTouches(bc, lue))

implies

{(irreversibil ity(lue) = 1) or (extroversion(lue) = 1)})

The formula starts with universal quantiﬁers specify-

ing the classes of variables bc, sel, and lue. The quan-

tiﬁcation 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-speciﬁcations, 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 Speciﬁcations

It is worth considering at this point some reasoning

tasks that may beneﬁt from the speciﬁcations illus-

trated in our examples. As stated in the introduc-

tion, we currently focus on validation tasks aimed

at checking whether a given EN satisﬁes the speci-

ﬁcations or not. However, other interesting reason-

ing tasks can exploit GeCoLan speciﬁcations, and we

want to brieﬂy 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 speciﬁcation 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 conﬂict with the speciﬁ-

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 ﬁx the detected vi-

olations. For example, it is quite plausible that the

check of the Connection Elements speciﬁcation 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-

reversibility.

• 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 speciﬁcation

(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-

iﬁcation 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 speciﬁcation 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 speciﬁcations 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 speciﬁcation 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 satisﬁes the

Connection Elements speciﬁcation 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 speciﬁ-

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 speciﬁca-

tions, we can then (re-)use such speciﬁcations as in-

puts to an appropriate combination of reasoners for

solving different and possibly more complex tasks.

4 VALIDATION OF

ECOLOGICAL NETWORKS

4.1 Translating Speciﬁcations to

GeoSPARQL Queries

In order to check whether the speciﬁcations discussed

in the previous section are satisﬁed 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

s.t.:

KB |= φ ↔



[[q

]]

0 φ = exists C(x)ϕ(x)

[[q

]]

0 φ = not exists C(x)ϕ(x)

(1)

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 deﬁne 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 preﬁx from

φ so that the values returned by the query are not

completely projected out; see the example below.

Whether φ is satisﬁed 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 quantiﬁer and the

implies connective, let us now consider the transla-

tion of the remaining quantiﬁers and connectives. For

ﬁnite domain classes C

, .. . ,C

, we deﬁne the cross

product of their domains as:

ADom(x

, . . . , x

) = {x

rdf : type C

...

rdf : type C

We then deﬁne 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 ﬁl-

ter expressions requires a similar approachto generate

variables corresponding to applications of functional

properties.

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 quantiﬁers:

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 ﬁlter 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 ﬁlter 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 ﬁlter ex-

pression is:

= {τ

FILTER NOT EXISTS τ

}

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 quantiﬁer on lue

and class restrictions on lue, ce using the associated

rules:

= SELECT (ce) WHERE {τ

}

As already mentioned, we do not translate the ﬁrst

existential quantiﬁer on ce, because this would leave

no variables. According to equation 1, given that the

original formula started with not exists, it is satis-

ﬁed if query τ

returns

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 (http://www.antlr.org/), which was

chosen due to its power and relative simplicity of use.

Based on the formal speciﬁcation 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 (https://jena.apache.org/) 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 satisﬁes the EN speciﬁcation or not.

The geospatial data we used was obtained from a

series of ESRI shapeﬁles 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 deﬁne an appropriate

mapping in order to associate shapeﬁles 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 ﬁrst level LCP type, e.g., artiﬁcial 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 speciﬁcally, 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 ﬁrst 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

speciﬁcation. The evaluation of whether these are se-

vere violations of the considered speciﬁcation, 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 speciﬁcation 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 efﬁciency 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

them.

5 FUTURE WORK

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 (ushahidi.com),

PlanYourPlace (planyourplace.ca)and OnToMap (on-

tomap.ontomap.eu)), 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 satisﬁed 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 speciﬁcations 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 satisﬁed when building new elements or

remodeling existing ones.

Another line of research we will pursue concerns

the improvement of the efﬁciency 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: ﬁrstly, 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

efﬁciently than Parliament; ﬁnally, pre-computing

and storing certain information (e.g., which elements

intersect with which) may turn out to be advantageous

for the subsequent check of speciﬁcations.

6 CONCLUSIONS

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 speciﬁcations 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 efﬁcient

way. Moreover, the language can support not only

the veriﬁcation of constraints in a geographical area,

but also other reasoning tasks, such as making con-

structive suggestions, possibly optimizing some de-

sired measure.

ACKNOWLEDGEMENTS

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.

REFERENCES

Ajit, S., Sleeman, D., Fowler, D. W., and Knott, D. (2008).

Constraint capture and maintenance in engineering

design. Artiﬁcial 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-

ings of the 33rd ACM SIGMOD-SIGACT-SIGART

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

ﬁrst-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://

www.cittametropolitana.torino.it/cms/territorio-

urbanistica/misura-323/misura-323-sperimentale.

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–

316.

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 deﬁnition of binary topo-

logical relationships. In Proc. Int. Conf. on Foun-

dations of Data Organization and Algorithms, pages

457–472.

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. CEUR-WS.org.

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.

opengis.net/geosparql/1.0/geosparql_vocab_all.rdf.

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 Keﬁ, 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.

gov.it/territorio/ﬁle-storage/download/pdf/pian_ 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. https://www.w3.org/Submission/

SWRL-FOL/.

W3C (2012). Web ontology language (OWL). https://

www.w3.org/TR/owl2-overview/.

W3C (2013). SPARQL query language for RDF. https://

www.w3.org/TR/rdf-sparql-query/.

W3C (2014). Resource description framework (RDF).

https://www.w3.org/RDF/.