The RITMARE Starter Kit

Bottom-up Capacity Building for Geospatial Data Providers

Cristiano Fugazza

, Stefano Menegon

, Monica Pepe

, Alessandro Oggioni

and Paola Carrara

IREA-CNR, via Bassini 15 - 20133 Milano, Italy

ISMAR-CNR, Arsenale - Tesa 104, Castello 2737/F, 30122 Venezia, Italy

Keywords:

Spatial Data Infrastructures, OGC Services, SWE, Marine Research.

Abstract:

Capacity building by data providers is a fundamental task in the creation of a decentralized Spatial Data In-

frastructure. This challenge has been tackled in the RITMARE Flagship Project by providing the Starter Kit,

a comprehensive set of domain-oriented software components that exposes standard services for the manage-

ment of geospatial information. We report on the characteristics of this toolkit, developed by the National

Research Council of Italy (CNR), particularly with regard to the underlying service-oriented architecture and

the novel semantics-aware methodology that is proposed for metadata editing.

1 INTRODUCTION

Spatial Data Infrastructures (SDIs) are frameworks

for the collection and provisioning of geospatial data,

metadata, networked services, and technologies. A

number of standard services, such as the Web Map

Service (WMS), allow for download and visualization

of the resources that are discovered through a Cata-

log Service for the Web (CSW)

interface. In fact,

differently from generalized search, where indexing

and retrieval is driven by crawling (hyper)textual data

on the Web, an SDI relies on speciﬁc metadata for-

mats and access protocols to enable “discovery” of

resources by users. It is essential for data providers

to comply with such metadata formats (actually, they

are often mandated to) and to expose appropriate ser-

vices in order to mesh with existing data collections

and to enable aggregation of their data by third-party

applications (Gil et al., 2012; De Longueville, 2010).

Unfortunately, implementing a full-ﬂedged infras-

tructure of this kind may feature a steep learning

curve preventing researchers from properly manag-

ing the required technicalities. As a consequence,

the exploitation of important datasets by the research

community may be indeﬁnitely conﬁned to word-of-

mouth. State-of-the-art SDI solutions may also make

it difﬁcult to seamlessly integrate novel categories

of data sources, such as sensor data (Na and Priest,

Catalog Service for the Web:

http://www.opengeospatial.org/standards/cat

2007). Moreover, the evolution of resource anno-

tation paradigms, such as the change in perspective

driven by Semantic Web technologies (Hitzler et al.,

2009), makes existing infrastructures for geospatial

data inadequate.

IREA-CNR tackled the challenge of providing an

infrastructure to RITMARE, the Flagship Project for

Italian marine research

. The variety of data formats

and practices enforced by the distinct data providers,

as well as the different degree of maturity of existing

solutions, rule out any kind of “integration by stan-

dardization” approach. We favor instead a bottom-up

methodology that may capitalize as possible on the

practices established by individual data providers.

Among these, we ﬁrst considered those with

no existing infrastructure in order to abstract from

protocol-level integration issues, focusing instead on

the heterogeneity of data formats. This also allowed

us to set a baseline for metadata which, in the Euro-

pean Union (EU), require standardization according

to the INSPIRE Directive (European Commission,

2007), enforced in Italy by the Repertorio Nazionale

dei Dati Territoriali (RNDT)

. The outcome is the

RITMARE Starter Kit (SK), a capacity-building col-

lection of software components packaged as a ready-

to-use virtual appliance. The SK exposes standard

data distribution services and establishes a CSW cat-

alog service by the data providers.

RITMARE Flagship Project: http://www.ritmare.it/

RNDT: http://www.rndt.gov.it

169

Fugazza C., Menegon S., Pepe M., Oggioni A. and Carrara P..

The RITMARE Starter Kit - Bottom-up Capacity Building for Geospatial Data Providers.

DOI: 10.5220/0004999801690176

In Proceedings of the 9th International Conference on Software Paradigm Trends (ICSOFT-PT-2014), pages 169-176

ISBN: 978-989-758-037-6

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

The catalog service that is exposed can either be

used in isolation, for the discovery of resources made

available by the speciﬁc data provider, or be exploited

by a centralized catalog service integrating the dis-

tinct contributions to the project. The infrastructure’s

central node also empowers the SK with metadata

editing capabilities that are based on a collection of

semantics-aware, RDF data structures

, as explained

in (Fugazza et al., 2014).

Section 2 outlines the RITMARE infrastructure

as a response to the project’s heterogeneous audience

and to the normative constraints for the management

of geospatial data in Italy as well as in the EU; it

also presents some related work that is relevant to

the project. Section 3 details the characteristics of

the SK with regard to the software provided and the

services that are exposed to either end users and the

centralized catalog. Section 4 describes the main con-

tributon of the SK to the state-of-the-art, that is, the

metadata editing service that allows for the creation

of semantically-annotated metadata. Section 5 pro-

vides a preliminary evaluation of the approach that is

presented. Finally, Section 6 draws conclusions and

outlines future work.

2 THE SK IN THE RITMARE

ARCHITECTURE

RITMARE is a Flagship Project by the Italian Min-

istero dell’Istruzione, dell’Universit

a e della Ricerca

which aims at fostering data sharing among the Italian

data providers in the ﬁeld of marine research. Sub-

project 7 is charged of building the SDI to be em-

ployed by the data providers themselves (public re-

search bodies and inter-university consortia) and also

by a variety of stakeholders (public administrations,

private companies, and citizens).

A coarse-grained categorization of SDIs distin-

guishes between centralized and decentralized infras-

tructures, according to whether data and metadata is

stored in a single repository or distributed among the

distinct data providers. The RITMARE infrastructure

will belong to the second kind, comprising:

• a set of peripheral nodes that expose standards-

compliant metadata and services;

• a node that provides a centralized catalog, single

point of access to the resources made available by

the project as a whole.

The rationale for adopting a decentralized strategy is

manifold. Firstly, by doing this, the implementation

Resource Description Framework:

http://www.w3.org/RDF/

strategies of existing infrastructures are not hampered

by inclusion in the RITMARE SDI. Also, this ap-

proach allows data providers to retain full control over

their data, metadata, and provisioning facilities. Fi-

nally, by federating the distinct data sources, no cen-

tralized management of sensitive data about users is

required.

Data providers in RITMARE are scientists be-

longing to different communities (e.g., oceanogra-

phy, ecosystems, biogeochemistry, geophysics, etc.).

As a consequence, they envisage a varied corpus of

heterogeneous data, metadata, workﬂows, and re-

quirements. They also feature different degrees of

maturity with regard to the solutions implemented

for the provisioning of resources. This heterogene-

ity has been addressed by structuring the develop-

ment activity in three incremental phases. The ﬁrst

one consists of empowering the data providers with

standards-compliant services for the collection, anno-

tation, and deployment of both geographic and sensor

data, which is the purpose of the SK described in this

work. The data sources that already expose standard

services will be integrated in the second phase. Fi-

nally, the third phase will be the building of the cen-

tralized portal accessing the distinct peripheral nodes

and exposing the metadata records as Linked Data.

A sketch of the interactions between end users,

SK instances, and the centralized catalog is depicted

in Figure 1 (directed arcs indicate which entity ac-

cesses which). In the picture, three distinct installa-

tions of the SK provide heterogeneous data (buoys

data, bathymetries, and radar data) by exposing the

services that are of interest to the speciﬁc category of

data. Three categories of end users can access each

of the peripheral nodes created by the SK both for

the discovery of resources and for the actual down-

load of data. These are data producers, stakehold-

ers, and third-party applications within and outside

the project. The centralized catalog of the RITMARE

infrastructure aggregates metadata records from the

distinct data sources so that the user can search for

datasets made available by any of the harvested SK

installations. Stored by this central node, RDF data

structures support metadata creation by the peripheral

nodes and enable advanced discovery functionalities.

2.1 Related framework

INSPIRE-compliant, XML-based metadata and

OGC-based services (European Commission, 2008;

IOC Task Force for Network Services, 2011a;

Initial Operating Capability Task Force, 2012; IOC

Task Force for Network Services, 2011b) set the

framework for interoperability of geospatial data

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

170

Figure 1: Instances of the Starter Kit in the RITMARE infrastructure.

among European countries. Whereas the framework

provides “stubs” for bridging between mere protocol-

level and real semantic interoperability (e.g., the

multilingual codelists employed in metadata), it is

unwieldy to accommodate these features in ISO

19115 format

, the XML schema mandated by the

Directive. This is the rationale for collecting, besides

INSPIRE-compliant metadata, additional information

that could ease implementation of more ﬁne-grained

search paradigms.

Another integration challenge is constituted by

sensor networks, which represent an application ﬁeld

that is mature enough for inclusion in our infrastruc-

ture. The integration of sensor observations within

SDIs is featuring many examples (Jiang et al., 2013;

Hale and Hollister, 2009; Voigt et al., 2009; Collins

et al., 2006). Also, many implementations are sup-

porting the requirements for Sensor Web Enable-

ment (SWE)

678

. However, the challenge of integrat-

ing sensor networks, particularly observations (the ac-

tual data produced by sensors), with traditional geo-

graphic data remains. In fact, Sensor Web develop-

ment relies on speciﬁc standards and practices that

ISO 19115: http://www.iso.org/iso/catalogue

detail.htm?csnumber=26020

◦

North: http://52north.org/communities/sensorweb/

index.html

OOSTethys: https://code.google.com/p/oostethys/wiki/

JavaServerMain

istSOS: http://istgeo.ist.supsi.ch/software/istsos/

make it difﬁcult to achieve this degree of integration.

3 THE RITMARE STARTER KIT

The main purpose of the SK is to enable researchers

and research organizations to contribute their data and

metadata to the RITMARE interoperable infrastruc-

ture. By means of the SK, data providers can upload

and manage their data (both maps and observations),

create the appropriate metadata for either datasets and

sensors, and ﬁnally provide discovery, visualization,

and access interfaces according to the standards. We

focused on three main strategies:

• to simplify as much as possible the installation of

the tools;

• to allow data providers to easily and directly man-

age, publish, and share their geospatial and obser-

vation datasets (without speciﬁc skills on SDIs);

• to foster reuse of the services provided by the SK

in projects and initiatives outside RITMARE.

The SK is distributed as a ready-to-use virtual appli-

ance which is packaged in the Open Virtualization

WMS Tiling Clients Recommendation:

http://wiki.osgeo.org/wiki/WMS Tiling Client Recommen-

dation

Tile Map Service: http://wiki.osgeo.org/wiki/Tile

Map Service Speciﬁcation

TheRITMAREStarterKit-Bottom-upCapacityBuildingforGeospatialDataProviders

171

Table 1: Services exposed by the Starter Kit.

SERVICE VERSION NOTES

OCG Web Map Service 1.1.1, 1.3.0 from GeoNode (GeoServer)

OGC Web Feature Service 1.0.0, 1.1.0, 2.0 from GeoNode (GeoServer)

OGC Web Coverage Service 1.0, 1.1 from GeoNode (GeoServer)

OGC Styled Layer Descriptor 1.0 from GeoNode (GeoServer)

OSGeo WMS Tiling Clients Recommendation

from GeoNode (GeoWebCache)

OGC Web Map Tiling Service from GeoNode (GeoWebCache)

OSGeo Tile Map Service

a predecessor to WMTS, from GeoNode (GeoWebCache)

OGC Catalogue Services for the Web 2.0.2 from GeoNode (pycsw)

INSPIRE Discovery Services 3.0 from GeoNode (pycsw)

Search/Retrieve via URL (SRU) search protocol from GeoNode (pycsw)

OGC SOS 1.0.0 from 52

◦

North SOS

OGC Sensor Model Language (SensorML) 1.0.1 from 52

◦

North SOS

OGC Observation and Measurement (O&M) 1.0.0 from 52

◦

North SOS

OGC Geography Markup Language (GML) 3.1.1 from 52

◦

North SOS

Format (OVF)

. The SK is based on the Ubuntu op-

erating system and contains open-source software. In

a nutshell, the SK is a web-based application and plat-

form kickstarting a node in the SDI which is capable

of managing geospatial and observation datasets and

resources.

Besides the software that has been speciﬁcally

created for the requirements of RITMARE, the SK

also features a number of services provided by GeoN-

ode and 52

◦

North SOS, see Table 1. The SK is

partly based on results of the CIGNo project (Berga-

masco et al., 2011), a collaborative, federated system

to share scientiﬁc and geographic data.

The software that has been customized or created

for the SK allows to keep the data, metadata, and ser-

vices tightly coupled. As an example, several meta-

data items are automatically extracted from datasets at

upload-time and passed down to the metadata editor

for insertion in the metadata record. The components

that have been developed expressively for the SK are

the following:

SOS Manager. Supports editing of SensorML for

registering a new sensor and allows upload of ob-

servations as tabular data in a text ﬁle.

SOS Client. The interface allows to easily interact

with an SOS service to retrieve, for each sensor,

position, parameter list, offerings, and values.

EDI Client. The client-side component of the cus-

tomizable, semantics-aware metadata editing ser-

vice described in Section 4.

The management of geographic information is pri-

marily mandated to GeoNode

(Benthall and Gill,

Open Virtualization Format:

http://www.dmtf.org/standards/ovf

GeoNode: http://geonode.org/

2010; Winslow, 2010), a widely acknowledged open-

source software that is capable of dealing with maps,

geographic layers, and also with geotagged docu-

ments. Besides geographic information, the SK is

also capable of uploading, storing, and publishing

sensor descriptions and the observations captured by

the former. The main component that is bundled is

the implementation by 52

◦

North

of the Sensor Ob-

servation Service (SOS) speciﬁcation and related fa-

cilities.

Since the services that are exposed by the two

aforementioned components are differing in many as-

pects, the workﬂows for inserting in the SK, respec-

tively, geographic and sensor data are kept separated.

By doing this, all the extra features provided by the

SOS implementation are retained. On the other hand,

the coupling of the two categories of data sources

emerges in the visualization features that are pro-

vided. In fact, integrated with the GeoNode Map

Composer, the SOS Client executes requests and re-

trieves the data from an SOS endpoint, so that users

can display on a GIS-like interface the position of sen-

sors. The sensors can then be queried for the time se-

ries that are made available for one or more observed

parameters: Data can either be displayed in classic

tabular mode or be applied data visualization criteria.

The SOS Client is a JavaScript library based on Open-

Layers

, ExtJS

, and Flot

◦

North: http://52north.org/

OpenLayers: http://openlayers.org/

ExtJS: http://www.sencha.com/products/extjs/

Flot: https://code.google.com/p/ﬂot/

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

172

Listing 1: Code fragment from the RNDT template.

1 < element >

2 < la bel lang =" it "> T ip o di r a p p r e s e n t a zi o n e spa zi al e </ label >

3 < la bel lang =" en "> S p a tia l re p r e s e n t a t i o n type </ label >

4 < is M and ato r y > forAl l </ isM and ato r y >

5 < is Mul tip le > true </ i sM u lt i ple >

6 < has Ro ot >

7 / gmd : MD _ M e t a d a t a / gmd : i d e n t i f i ca t i o n I n f o / gmd : MD _ D a t a I d e n t i fi c a t i o n

8 </ hasRoot >

9 < prod uc es >

10 < item >

11 < has In dex >1 </ ha sInde x >

12 < hasPath >/. . ./ g md : M D _ S p a t i a l R e p r e s e n t a t i o n T y p eC o d e </ hasPath >

13 < isFixed > false </ isFixed >

14 < h asD a tat y pe > code </ h asD ata t ype >

15 < has Va lue > http :/ / . ../ M D _ S p a t i al R e pr e s en t a ti o n Ty p e Co d e / items </ ha sV alu e >

16 </ item >

17 < item >

18 < has In dex >2 </ ha sInde x >

19 < hasPath >/. . ./ g md : M D _ S p at i a lR e p re s e nt a t io n T yp e C od e / @cod eL ist </ hasPath >

20 < isFixed > true </ is Fi xe d >

21 < h asD a tat y pe > stri ng </ ha s Dat a typ e >

22 < has Va lue >

23 http : //. . . / g m x C o d e l i sts . xml # M D _ S p at i a lR e p re s e nt a t io n T yp e C od e

24 </ h as Value >

25 </ item >

26 < item >

27 < has In dex >3 </ ha sInde x >

28 < hasPath >

29 /. ../ gmd : MD_ S p a t i a l Re p r es e n ta t i on T y pe C o de / @codeListValue

30 </ hasPath >

31 < isFixed > true </ is Fi xe d >

32 < h asD a tat y pe > ref </ has D ata typ e >

33 < has Va lue > /.. . / gmd : M D _ S p a t i a l R e p r e s e n t a t i o nT y p e C o d e </ ha sValu e >

34 </ item >

33 </ p ro duces >

34 ...

35 </ ele me nt >

4 METADATA CREATION IN THE

One of the most important components in the SK is

EDI, a customizable, template-driven metadata editor

that has been developed within RITMARE by lever-

aging a variety of complementary techniques. The ra-

tionale for this is to employ the more appropriate tech-

nology for each of the distinct phases in the workﬂow

for metadata creation. For the time being, we support

the editing of RNDT (i.e., INSPIRE) and SensorML

metadata. However, the data model underlying tem-

plate creation, encoded as an XML Schema

, should

be expressive enough to support most of the metadata

formats in the SDI domain. As an example, support

for sensor metadata in the alternative *FL (Starﬁsh

Fungus Language) format (Simonis and Malewski,

XML Schema: http://www.w3.org/XML/Schema

2011) is under testing.

The only input required by EDI to assist compo-

sition of metadata records in a given XML format is

an appropriate template. The template language in-

troduces the primitives that are necessary for the def-

inition of metadata elements, intended as high-level

abstraction of the information that can be either pro-

vided by the user or pre-computed by the application

itself (such as the geographic boundary, the so-called

“bounding box”, that can be automatically computed

at data upload-time). Each element deﬁnes one or

more items that correspond to the individual XML

nodes (elements and attributes) that are populated in

the metadata record. Listing 1 shows a fragment of

the RNDT template governing the creation of meta-

data in the ISO 19115 XML format, the standard un-

derlying INSPIRE metadata.

The essential information deﬁning an element is

the language-dependent textual representation to be

TheRITMAREStarterKit-Bottom-upCapacityBuildingforGeospatialDataProviders

173

Figure 2: Portion of the EDI metadata editing interface.

displayed in the interface (lines 2 and 3), the compul-

soriness of the metadata item (one of “forAll”, “for-

Data”, “forServices”, “forSensors”, and “NA” on line

4), its multiplicity (line 5), and the XPath deﬁning

the position where multiple instances of the metadata

ﬁeld shall be rooted (lines 6-8). Instead, the distinct

items associated with the element deﬁne the speciﬁc

XML nodes that shall be generated. In the HTML

form interface generated by EDI, the user is presented

the form ﬁelds that correspond to items whose param-

eter isFixed is set to “false” (as on line 13). For these,

parameter hasDatatype speciﬁes the data type of the

speciﬁc metadata element. In the listing, the ﬁrst item

deﬁning element “Spatial representation type” is of

type “code”, meaning that the possible values shall be

taken from a controlled vocabulary: In this case, pa-

rameter hasValue speciﬁes the unique identiﬁer (the

URI) that is necessary for retrieving the allowed val-

ues for the ﬁeld.

EDI processes the template through an XSLT

stylesheet, the most suitable means for processing

XML data, and generates the actual HTML form that

is displayed in the user’s browser. Still, this interface

is a dumb form that only distinguishes between input

ﬁelds, text areas, dropdown lists, etc. but whose input

ﬁelds and text areas have no predeﬁned values, whose

dropdown lists have no options (the values selectable

by the user), etc. In fact, it is up to the JavaScript com-

ponent of EDI to dynamically load these contents: For

doing this, the JavaScript code accesses codelists and

controlled vocabularies stored in the RDF triple store

on the server-side, as described in (Fugazza et al.,

2014). These categorizations of terms also provide

all the accessory information that is required for cre-

ating the items that are either ﬁxed or dependent on

the user’s choices (the items whose parameter isFixed

is set to “true”).

Let aside relieving the user from the burden of

providing these additional data, recourse to RDF data

structures allows the SK to annotate metadata with

unique identiﬁers (e.g., the URI corresponding to the

INSPIRE Theme the user may select) that will be used

later on, when metadata is harvested by the central

catalog collecting the contributions of the distinct pe-

ripheral nodes of the RITMARE infrastructure. This

information may not be exposed (or leveraged on in

discovery) by the individual catalogs of peripheral

nodes but constitutes the fundamental step for pro-

viding advanced query functionalities by the overall

infrastructure. Also, among the RDF data that EDI

accesses for initializing the form ﬁelds is information

related to the institution hosting the peripheral node of

the infrastructure. This allows the client application to

suggest values for a number of metadata ﬁelds.

Speciﬁcally, the semantics-aware characterization

of data items allows the interface to provide three dis-

tinct functionalities:

• the automatic provision of values for metadata

ﬁelds whose content depends on the choices that

have been made for other metadata ﬁelds;

• the generation of dropdown lists on the basis of

the mandated codelists, translated into the speciﬁc

language that is chosen for the metadata;

• the autocompletion of metadata ﬁelds whose val-

ues shall be taken from controlled vocabularies

that are too large for rendering as a dropdown list.

Figure 2 shows a portion of the HTML form that

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

174

is generated by EDI after the execution of both the

XSLT transformation and the JavaScript code men-

tioned above. In particular, the image focuses on

three distinct ﬁelds (the metadata point of contact, the

presentation format, and the observation parameter a

given dataset is related to) to exemplify the three dis-

tinct means we evisaged for the assisted editing of

metadata.

In box 1, the authentication information that has

been provided by the user allows the interface to sug-

gest the distinct metadata items that are required for

specifying a point of contact (the institution the per-

son is working by, the website associated with the for-

mer, and the person’s email address). Box 2 allows

for the speciﬁcation of the presentation format by se-

lecting among the codes that have been deﬁned by the

INSPIRE Directive. The list (as well as ﬁeld names,

interface menus, and buttons) is populated on the ba-

sis of the language that is chosen for metadata edit-

ing. Finally, box 3 shows the input ﬁeld that is used

for providing the observation parameter (a keyword in

the ISO metadata lexicon): Autocompletion capabil-

ities provide the user with the range of observation

parameters deﬁned by SeaDataNet

, an outstanding

European marine project.

Once ﬁelds have been ﬁlled in, the EDI Client

posts the metadata to the EDI service hosted by the

central node of the RITMARE infrastructure. This

metadata is used for accomplishing two distinct activ-

ities. On the one hand, to create a metadata record

that has all the expressiveness elicited by the inter-

face (essentially, an XML ﬁle very similar to the orig-

inal template, whose ﬁelds are ﬁlled in with the ac-

tual values entered by the user). Secondly, the actual

XML corresponding to the metadata format the tem-

plate was written for is produced (for the time being,

either RNDT or SensorML). Both these ﬁles are sent

back to the local SK installation.

5 DISCUSSION

In the current phase of the project, when the cen-

tralized geoportal is still work in progress, an overall

evaluation of the proposed solution is not easy. How-

ever, we are already collecting feedback on the ca-

pacity building of data providers envisaged in the ﬁrst

phase of the project (see Section 2), that is, we can

report on the efﬁcacy of our Starter Kit. In particular,

we can evaluate the features that we are providing for

the assisted editing of metadata.

With respect to these, recourse to the RDF data

SeaDataNet: http://www.seadatanet.org/

structures allows to dramatically reduce the number

of the data items to be actually provided by the user.

As an example, the RNDT speciﬁcation is featuring

34 mandatory metadata items, too high a number for

an accurate editing of metadata records. Moreover,

some of these, such as the 4 distinct contact points to

be provided, are composite items that require more

than one value to be entered by the user. Instead,

by combining i) the automatic assignment of meta-

data items, ii) the provision of default values extracted

from the dataset itself, and iii) the exploitation of the

RDF information described in (Fugazza et al., 2014),

the number of required values can be narrowed down

to 10.

Particularly, by referring to the project structure,

the editing interface is capable of providing data items

that are otherwise tedious to provide or error-prone.

Also, autocompleting keywords from the selected the-

sauri conﬁgures a win-win situation where the user is

relieved of the burden of writing keywords in their

entirety and the application is capable of associat-

ing unique identiﬁers with the keywords that are pro-

vided. These advanced editing capabilities can be ap-

plied to generic metadata schemata encoded as XML.

In fact, we currently support the editing of sensor

metadata in the SensorML format with the same au-

tocompletion facilities of RNDT metadata.

An important requirement that has been underesti-

mated in the analisys phase is the need for appropriate

updating and monitoring facilities. In fact, once indi-

vidual nodes are up and running, it is extremely difﬁ-

cult to update remote components without hampering

operativeness of the node. Another lesson learnt is

related to dependencies on third-party software that

require thorough testing before upgrading the version

provided in the SK. Speciﬁcally, when migrating from

version 3.2 to version 4.0 of the 52

◦

North SOS imple-

mentation, much work was required for updating the

interfaces between this software and the rest of the

SK.

6 CONCLUSIONS

This paper described the approach to capacity build-

ing for geospatial data providers that has been adopted

in project RITMARE. A variety of open-source soft-

ware has been bundled in the Starter Kit, a virtual

appliance capable of establishing a fully-functional

SDI node out-of-the-box. A comprehensive set of

standards-compliant services allows to easily manage

both geographic data and sensor observations; the SK

also provides a uniform mechanism for metadata cre-

ation. Set-up of the nodes in the RITMARE SDI that

TheRITMAREStarterKit-Bottom-upCapacityBuildingforGeospatialDataProviders

175

are based on the SK is ongoing.

The overall infrastructure contributes to the enact-

ment of the SK installations by providing services for

the management of metadata that annotate resources

semantically. These annotations are then employed

by the central node for a twofold purpose: i) to im-

plement novel techniques for the organization of wid-

gets in the geoportal’s main interface and ii) to en-

able inter-disciplinary discovery of the geospatial re-

sources that are aggregated.

Future steps will involve the integration into the

infrastructure of the data providers that already ex-

pose suitable services. Some existing tools, such as

the GI-cat brokering application

, already allows ac-

cess to heterogeneous data sources. This is interop-

erability at protocol-level while, in our scenario, the

challenge is to allow the research communities to in-

teroperate at a higher level. As an example, the ex-

pressiveness of individual metadata items should be

augmented through lookup in controlled vocabularies

or semantic indexing methodologies.

RITMARE will provide a uniform point of access

to all the data sources involved in the project (either

SK instances or not); the user interface will ﬂexibly

adapt to the interests, requirements, practices, and de-

vices of individual researchers in the project.

ACKNOWLEDGEMENTS

The activities described in this paper have been

funded by the Italian Flagship Project RITMARE.

REFERENCES

Benthall, B. and Gill, S. (2010). SDI Best Practices with

GeoNode. In Proceedings of Free and Open Source

Software for Geospatial Conference (FOSS4G 2010).

Bergamasco, A., Guerzoni, S., Masiero, E., Menegon, S.,

Morgantin, M., Rosina, A., Sarretta, A., and Vianello,

A. (2011). Collaborative Interoperable Geographic

Node in Venice Lagoon. In Data Flow from Space

to Earth: International Conference, Venice, Italy.

Collins, S. L., Bettencourt, L. M., Hagberg, A., Brown,

R. F., Moore, D. I., Bonito, G., Delin, K. a., Jack-

son, S. P., Johnson, D. W., Burleigh, S. C., Woodrow,

R. R., and McAuley, J. M. (2006). New opportunities

in ecological sensing using wireless sensor networks.

Frontiers in Ecology and the Environment, 4(8):402–

407.

De Longueville, B. (2010). Community-based geoportals:

The next generation? Concepts and methods for the

GI-cat: http://essi-lab.eu/do/view/GIcat

geospatial Web 2.0. Computers, Environment and Ur-

ban Systems, 34(4):299–308.

European Commission (2007). Establishing an Infrastruc-

ture for Spatial Information in the European Commu-

nity (INSPIRE) Directive 2007/2/EC.

European Commission (2008). Commission regulation

(EC) no 1205/2008 of 3 December 2008 implement-

ing Directive 2007/2/ec of the European Parliament

and of the Council as regards metadata.

Fugazza, C., Pepe, M., Oggioni, A., Pavesi, F., and Car-

rara, P. (2014). A holistic, semantics-aware approach

to Spatial Data Infrastructures. In 3rd International

Conference on Data Management Technologies and

Applications (DATA).

Gil, J., D

ıaz S

anchez, L., Granell, C., and Huerta Guijarro,

J. (2012). Open Source Based Deployment of En-

vironmental Data into Geospatial Information Infras-

tructures. International Journal of Applied Geospatial

Research (IJAGR), 3(2):6–23.

Hale, S. S. and Hollister, J. W. (2009). Beyond data man-

agement: how ecoinformatics can beneﬁt environ-

mental monitoring programs. Environmental Moni-

toring and Assessment, 150(1-4):227–235.

Hitzler, P., Krtzsch, M., and Rudolph, S. (2009). Founda-

tions of Semantic Web Technologies. Chapman & Hal-

l/CRC, 1st edition.

Initial Operating Capability Task Force (2012). Technical

Guidance for the Implementation of INSPIRE down-

load services.

IOC Task Force for Network Services (2011a). Technical

Guidance for the Implementation of INSPIRE discov-

ery services.

IOC Task Force for Network Services (2011b). Technical

Guidance for the Implementation of INSPIRE view

services.

Jiang, Y., Guo, Z., Hu, K., Shen, F., and Hong, F. (2013).

Using Sensor Web to Sharing Data of Ocean Observ-

ing Systems. In Wang, R. and Xiao, F., editors, Ad-

vances in Wireless Sensor Networks, pages 137–156.

Springer-Verlag, Berlin Heideberg.

Na, A. and Priest, M. (2007). OGC Sensor Observation

Service (OGC 06-009r6). OpenGIS Implementation

Standard.

Simonis, I. and Malewski, C. (2011). *FL Starﬁsh Fungus

Language for sensor description. OGC discussion pa-

per 11-058r1.

Voigt, T., Tsiftes, N., and He, Z. (2009). Remote Wa-

ter Monitoring With Sensor Networking Technology.

Ercim News, 2009(76):39–40.

Winslow, D. (2010). GeoNode Architecture: wrangling

$100 million worth of open source software to make

SDI building a walk in the park. In Proceedings of

Free and Open Source Software for Geospatial Con-

ference (FOSS4G 2010).

ICSOFT-PT2014-9thInternationalConferenceonSoftwareParadigmTrends

176