Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData...
Transcript of Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData...
![Page 1: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/1.jpg)
Linked Open Data for environment
protection in Smart Regions
Architecture of
SmartOpenData
infrastructure
Deliverable D2.3 :: Public
Keywords: RM-ODP, Architecture design, Linked Open
Data, SDI, Open Data
Architecture of
SmartOpenData
infrastructure
Deliverable D2.3 :: Public
Keywords: RM-ODP, Architecture design, Linked Open
Data, SDI, Open Data
![Page 2: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/2.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 2 of 77 © SmartOpenData Consortium 2014
![Page 3: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/3.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 3 of 77 © SmartOpenData Consortium 2014
Table of Contents
1 Executive Summary ............................................................................................................ 9
2 Introduction...................................................................................................................... 10
3 Technological outcomes for the project .......................................................................... 11
3.1 HABITATS Reference Laboratory.............................................................................. 11
Figure 1 HABITATS Reference Laboratory Architecture........................................................... 12
3.2 Plan4Business Open Data Repository ...................................................................... 12
The platform targets different user groups. ............................................................................ 13
Figure 2 Plan4business Open Data Repository Architecture ................................................... 14
3.3 LOD2 project............................................................................................................. 14
3.4 GeoKnow project...................................................................................................... 17
Figure 3 GeoKnow High-Level Architectural Overview............................................................ 18
3.5 SemaGrow project.................................................................................................... 18
Figure 4 SemaGrow Architecture............................................................................................. 19
3.6 DCAT application profile for data portals in Europe ................................................ 19
3.7 CKAN domain model ................................................................................................ 20
3.7.1 CKAN and GeoNetwork for an integrated Open Data Portal........................... 21
Figure 5 OpenDataNetwork System & Nodes Architecture..................................................... 21
3.8 INSPIRE metadata and DCAT-AP .............................................................................. 21
4 RM-ODP methodology ..................................................................................................... 24
4.1 RM – ODP methodology........................................................................................... 24
4.2 View point approach ................................................................................................ 24
4.3 Generic and pilot design .......................................................................................... 26
5 Enterprise viewpoint ........................................................................................................ 27
5.1 Basic pilots................................................................................................................ 27
5.2 Common search and indexing facilities.................................................................... 28
5.2.1 Spain (and Portugal) ......................................................................................... 29
5.2.2 Ireland .............................................................................................................. 30
5.2.3 Italy................................................................................................................... 33
5.2.4 Czech ................................................................................................................ 34
5.2.5 Slovakia............................................................................................................. 37
5.3 Cross-pilot functional requirements ........................................................................ 39
5.3.1 Plan4business................................................................................................... 39
5.3.2 Tourism............................................................................................................. 39
![Page 4: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/4.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 4 of 77 © SmartOpenData Consortium 2014
6 Information viewpoint ..................................................................................................... 41
6.1 Local data ................................................................................................................. 41
6.1.1 GIS Files ............................................................................................................ 41
6.1.2 General purpose files ....................................................................................... 42
6.2 Basic data types used in SmartOpenData ................................................................ 44
6.3 RDF Data integration................................................................................................ 47
6.4 Ontologies and vocabularies .................................................................................... 48
6.5 Registers and Registries ........................................................................................... 48
6.6 Information structure and content with a clear focus on the metadata and data
models; ................................................................................................................................. 50
6.7 Tasks related to SmartOpenData data..................................................................... 50
6.8 Data flows................................................................................................................. 50
7 Computational viewpoint................................................................................................. 51
7.1 Local data ................................................................................................................. 51
7.2 Server side ................................................................................................................ 51
7.3 Client side ................................................................................................................. 52
7.4 Non-functional requirements .................................................................................. 53
8 Engineering viewpoint...................................................................................................... 54
8.1 Generic architecture ................................................................................................ 54
8.2 Server side ................................................................................................................ 55
8.2.1 Relation database............................................................................................. 55
8.2.2 Data Integration ............................................................................................... 55
8.2.3 Structured and non-structured data extraction .............................................. 56
8.2.4 Converting data to RDF .................................................................................... 57
8.2.5 SPARQL EndPoint.............................................................................................. 57
8.2.6 Support for standard vocabularies................................................................... 58
9 Technology viewpoint ...................................................................................................... 59
9.1 Tools for technical implementations ....................................................................... 59
9.2 Spatial data serialization tools ................................................................................. 60
9.2.1 GeoKnow TripleGeo ......................................................................................... 60
9.3 Non-spatial data serialization tools.......................................................................... 61
9.3.1 D2RQ................................................................................................................. 61
9.3.2 db2triples ......................................................................................................... 61
9.3.3 TripleStores and SPARQL/GeoSPAQL endpoints.............................................. 61
9.3.4 Parliament ........................................................................................................ 61
9.3.5 Strabon ............................................................................................................. 62
![Page 5: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/5.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 5 of 77 © SmartOpenData Consortium 2014
9.3.6 OpenSahara uSeekM IndexingSail Sesame Sail plugin..................................... 62
9.3.7 Openlink Virtuoso Universal Server ................................................................. 62
9.3.8 Ontotext OWLIM .............................................................................................. 62
9.3.9 SPARQ ED ......................................................................................................... 62
9.4.10 SIRENDB........................................................................................................... 63
9.3.11 Sefarad-Faceted Search.................................................................................... 63
9.4 High-level technical specification – generic level .................................................... 63
9.5 Examples for architecture implementation of the pilots......................................... 65
9.5.1 Czech pilot ........................................................................................................ 66
9.5.2 Slovakian pilot ................................................................................................. 66
9.5.2 Irish pilot........................................................................................................... 67
9.5.3 Spanish pilot ..................................................................................................... 68
9.5.4 Italian pilot ....................................................................................................... 69
9.5.5 Tourist cross border pilot ................................................................................. 70
9.6 Relation with semantic indexing .............................................................................. 70
10 Conclusions and Recommendations ............................................................................ 72
10.1 Linkage with main technical components of SmartOpenData ................................ 72
Annex A: ................................................................................................................................... 75
![Page 6: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/6.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 6 of 77 © SmartOpenData Consortium 2014
List of Figures
Figure 1 HABITATS Reference Laboratory Architecture........................................................... 12
Figure 2 Plan4business Open Data Repository Architecture ................................................... 14
Figure 3 GeoKnow High-Level Architectural Overview............................................................ 18
Figure 4 SemaGrow Architecture............................................................................................. 19
Figure 5 OpenDataNetwork System & Nodes Architecture..................................................... 21
Figure 6 RM ODP viewpoints.................................................................................................... 25
Figure 7 SmartOpenData data flow.......................................................................................... 50
Figure 8 Generic architecture................................................................................................... 54
Figure 9 High-level technical specification – generic level...................................................... 64
Figure 10 Component diagram of SmartOpenData ................................................................. 65
Figure 11 Czech Pilot Architecture........................................................................................... 66
Figure 12 Slovaks pilot architecture......................................................................................... 67
Figure 13 Irish pilot................................................................................................................... 68
Figure 14 Spanish pilot: Agroforestry Management................................................................ 68
Figure 15 Portuguese-Spanish pilot: Water Management ...................................................... 69
Figure 16 Italian pilot ............................................................................................................... 69
Figure 14 WP4 implementation and linkage with pilots.......................................................... 71
![Page 7: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/7.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 7 of 77 © SmartOpenData Consortium 2014
List of Tables
Table 1 Pilot Data source.......................................................................................................... 46
Table 2 Available components for SmartOpenData ................................................................ 60
Table 3 SmartOpenData LOD functionalities ........................................................................... 72
![Page 8: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/8.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 8 of 77 © SmartOpenData Consortium 2014
Contractual Date of Delivery to the EC: April2014
Actual Date of Delivery to the EC:
Editor(s): Karel Charvat (HSRS)
Contributor(s): TRAGSA, UPM, MAC, Sindice, SDati, HSRS, IMCS,
SAZP, FMI
DOCUMENT HISTORY
Version Version date Responsible Description
1.0 28 March 2014 HSRS Initial draft, TOC, call for
contributions from others.
1.1 10. May 2014 HSRS with
contribution
for all pilot
partners
First version of report
1.2 27. May 2014 HSRS with
contribution
from SAZP,
FMI
Last version
2.0 30. June 2014 HSRS with
contribution
from
TRAGSA
Final version
The information and views set out in this publication are those of the author(s) and do not
necessarily reflect the official opinion of the European Communities. Neither the European
Union institutions and bodies nor any person acting on their behalf may be held responsible
for the use which may be made of the information contained therein.
Copyright © 2014, SmartOpenData Consortium.
![Page 9: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/9.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 9 of 77 © SmartOpenData Consortium 2014
1111 Executive Summary
This deliverable D2.3 is part of WP2, task T2.3. It is based on previous work of tasks T2.1 and
T2.2, deliverables D2.1 and D2.3 and their content was defined on Prague meeting of Pilot
partners organized on 22nd
and 23rd
of May. D2.3 defines a reference infrastructure model
and high-level technical specification for the project, including its main components and
connection points to other tools and systems. There is implemented methodology reference
model for open distributed processes (RM – ODP) The reference architecture aims at
meeting the technical and user requirements established throughout T2.1 and T2.2,
addressing interoperability and multilingualism aspects, metrics engine and interfaces. The
reference architecture will define both, platform neutral components and also provides
suggestion for concrete implementation. In addition to that document indicates linkages
between architecture (WP2), data model (WP3), SmartOpenData Semantic Front-end
Facilities (WP4) and demonstration pilots (WP5). This will ensure overall consistency in the
development of the main technical project components.
![Page 10: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/10.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 10 of 77 © SmartOpenData Consortium 2014
2222 Introduction
The objective of Task 2.3 is to define generic architecture (platform neutral), supporting at
the same time pilot solutions. This task defines a reference infrastructure model and high-
level technical specification for the project, including its main components and connection
points to other tools and systems. The methodology reference model for open distributed
processes (RM – ODP) was used. The reference architecture aims at meeting the technical
and user requirements established throughout T2.1 and T2.2, addressing technology and
user requirements. The reference architecture will define both, platform neutral
components and will provide suggestions for concrete implementation. The objective of this
task is not to design monolithic solution integrating whole life of Link Open Data, but to
define basic architecture components of Link Open Data chain and define potential solutions
for solving concrete challenges of the pilots.
Additional requirements came from analysis of cross links identified among single pilots and
also from project partners SMEs, potential users of Linked Open Data
![Page 11: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/11.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 11 of 77 © SmartOpenData Consortium 2014
3333 Technological outcomes for the project
The deliverables D2.2 Requirements of the SmartOpenData Infrastructure and D3.1 Review
of geographic resources metadata and related metadata standards analyzed existing
solutions, projects and platforms. For design of SmartOpenData architecture, we selected
solutions, allowing re–use of their outcomes to meet the SmartOpenData solution
requirements and expectations. First two solutions come from already finished projects,
representing traditional approach to SDI building. We also do expect re-use of the
repositories prepared by these two project (Habitats, Plan4business), making them available
as Linked Open Data. In case of both solutions, there is also plan to extend classical GI
modules with Linked Open Data (LOD) functionality.
Other solutions are oriented on LOD and SmartOpenData project expects re-use of their
components and experience for implementation for SmartOpenData platform.
3.1 HABITATS Reference Laboratory
HABITATS project predecessor of SmartOpenData with focus on better utilization of
environmental data. HABITATS (Social Validation of INSPIRE Annex III Data Structures in EU
Habitats) extended classical INSPIRE based SDI architecture and define new solution
supporting better usability of INSPIRE based services by people. Solution was defined in the
form of Habitats Reference Laboratory.
The Habitats RL networking architecture was as follows1:
1 HABITATS D4.3.2 Networking services and service toolkit, March 2013, www.habitats.cz/gallery
![Page 12: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/12.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 12 of 77 © SmartOpenData Consortium 2014
Figure 1 HABITATS Reference Laboratory Architecture
The important extension of classical INSPIRE architecture was Application layer and
Presentation layers, allowing building user focused Apps on the base of INSPIRE SDI. This
approach will be also important for future utilization of Linked Open Data as part of
SmartOpenData.
Two other important outcomes, which will be reused and extended in SmartOpenData is
SuperCatalog, which provide harvesting and validation of INSPIRE and GEOSS based services
in Europe and Worldwide and also concepts of integration of Linked Data with INSPIRE based
View client. The intention of SmartOPenData is to transform this catalogue to RDF.
3.2 Plan4Business Open Data Repository
Plan4Business (A service platform for aggregation, processing and analysis of urban and
regional planning data)2 is an FP7 project that has developed an aggregation platform
serving multiple providers and thus offering users a full catalogue of planning data such as
transport infrastructure, regional plans, urban plans and zoning plans. The platform offers
clients the data itself in integrated, harmonised and thus ready-to-use form, but also
provides rich analysis and visualization services. Such services are offered via different
interfaces, such as an API and an interactive web front-end (WebGIS).
The Plan4Business “WhatsthePlan” service3 is a public platform for harmonisation,
integration, storing and analysis of spatial and non-spatial data. The platform contains a
large data pool of planning data including pan-European datasets such as Urban Atlas,
Corine Land Cover and Natura 2000; statistical information from EUROSTAT and selected
2 www.plan4business.eu
3 www.whatstheplan.eu
![Page 13: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/13.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 13 of 77 © SmartOpenData Consortium 2014
countries, national datasets such as cadastral information and flood zones; and regional and
local urban planning data. The platform is open for everyone and encourages users to share
their data and expand the data coverage on horizontal and vertical levels.
Besides data harmonisation and integration, the platform enables various analyses based on
its integrated datasets. The more spatial information available, the better and more precise
analysis results that can be retrieved.
The platform targets different user groups.
• Tools for spatial data experts.
o The Integration Engine enables harmonisation of urban plans into the INSPIRE
Land Use schema and publish them in an interoperable way using the OGC
web services.
o The Map Creator enables users to prepare a map of their choice by making an
overlay of data from the database as well of remote data connected using the
OGC web services.
• Spatial apps for general users. These apps, which are easy to use and show the
capabilities of the platform, include:
o Location Evaluator – that generate a comprehensive report about a region, a
municipality or a point of interest
o Thematic Map Viewer – that navigates through thematic maps and
predefined analyses from local to European level
The Plan4business Open Data Repository uses the Micka catalogue4 developed by HSRS, also
a partner in SmartOpenData. The catalogue enables storage not only of metadata about
existing datasets, but also about analyses, map compositions and integration services that
can be performed. The Integration Engine accessing and harmonising data in the Storage
Engine is supported by the HUMBOLDT Alignment Editor (HALE)5. The Analysis Engine
processes the requests given by users through the plan4business portal. The query is
processed and the Analysis Engine accesses the data storage and retrieves query results that
are then provided to users in standardised form. Its architecture is as follows6:
4
http://geossregistries.info/geosspub/resource_details_ns.jsp?compId=urn:geoss:csr:resource:urn:uuid:921876
05-201e-4175-a0ba-a15714041c53 5 www.esdi-community.eu/projects/hale
6 From
http://www.google.ie/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=2&cad=rja&ved=0CDMQFjAB&url=
http%3A%2F%2Fwww.plan4business.eu%2Fcgi-
bin%2Fdownload.pl%3Ff%3D153.pdf&ei=1XuMUuG8JuiS7Qao64CgCg&usg=AFQjCNF3-
xcWC2QORCI99KuZcKVLNckdIg
![Page 14: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/14.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 14 of 77 © SmartOpenData Consortium 2014
Figure 2 Plan4business Open Data Repository Architecture
The Plan4business Open Data Repository builds on and extends the HABITATS Reference
Laboratory tools, with two major additions that will benefit SmartOpenData
1. It has additional tools that partly provide LOD functionality.
2. It is collecting large-scale heterogeneous data. It has a set of operational data from
Europe, basic data, statistical data, data that was in HABITATS, OpenStreetMap
transformed to INSPIRE models. Some country transport networks, for example
Norway. Spatial plans from some countries, for example the Irish Open Land Use
data, Czech cadastre maps, etc.7
As the project has common partners with SmartOpenData, the repository could be used
early in the project for fast prototyping with LOD tools for large-scale implementation in
WP3 (Data modeling and LOD alignment) by transforming it to Open Data.
3.3 LOD2 project
The Commission’s Open Data Support European initiative is using the DCAT Application
Profile common metadata vocabulary to describe datasets for data portals in Europe8. While
the metadata harvesting and publishing platform that EU Open Data Portals are using for
collecting metadata of datasets from government data portals, transforming it into RDF,
harmonizing it according to the DCAT-AP, and publishing it as Linked Open Government Data
7 Another source of transport geographic information is the portal http://geo.weastflows.eu/, from the
Weastflows (west and east freight flows) Interreg IVB North West Europe (NWE) project, www.weastflows.eu,
that aims to encourage a shift towards greener freight transport in NWE. MWRA is a partner in Weastflows. 8 https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/dcat-application-profile-data-
portals-europe-final#download-linksl
![Page 15: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/15.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 15 of 77 © SmartOpenData Consortium 2014
(LOGD) is based on the Linked Open Data Management Suite developed in the LOD2
project9.
The project is integrating and syndicating linked data with large-scale, existing applications
and showcasing the benefits in the three
application scenarios of media and
publishing, corporate data intranets and
eGovernment.
The LOD2 Stack suite of tools and
components include10
:
• D2R Server is a tool for publishing
the content of relational databases
on the Semantic Web, a global
information space consisting of
linked data.
• Spatial Semantic Browser allows
geographic visualization of RDF
data,
• CubeViz is a facetted browser for
statistical data utilizing the RDF
Data Cube vocabulary which is the state-of-the-art in representing statistical data in
RDF.
• R2R Framework enables Linked Data applications which discover data on the Web,
that is represented using unknown terms, to search the Web for mappings and apply
the discovered mappings to translate Web data to the application's target
vocabulary.
• OntoWiki is a tool providing support for agile, distributed knowledge engineering
scenarios. It facilitates the visual presentation of a knowledge base as an information
map, with different views on instance data. It enables intuitive authoring of semantic
content, with an inline editing mode for editing RDF content, similar to WYSIWIG for
text documents.11
• ORE (Ontology Repair and Enrichment) tool allows knowledge engineers to improve
OWL ontology by fixing inconsistencies and making suggestions for adding further
axioms to it.
• Sparqlify is a SPARQL-SQL rewriter that enables one to define RDF views on relational
databases and query them with SPARQL. It is currently in alpha state and powers the
Linked-Data Interface of the LinkedGeoData Server – i.e. it provides access to billions
of virtual triples from the OpenStreetMap database.
9 https://github.com/nvdk/lodms-core/tree/virtuoso
10 LOD2 Stack Components & their APIs are described at
wiki.lod2.eu/display/LOD2DOC/LOD2+Stack+Components 11
(http://lod2.eu/Project/OntoWiki
![Page 16: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/16.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 16 of 77 © SmartOpenData Consortium 2014
• LIMES is a link discovery framework for the Web of Data. It implements time-efficient
approaches for large-scale link discovery based on the characteristics of metric
spaces. It is easily configurable via a web interface. It can also be downloaded as
standalone tool for carrying out link discovery locally.
• SigmaEE is a tool to explore and leverage the Web of Data. At any time, information
in Sigma is likely to come from multiple, unrelated Web sites - potentially any web
site that embeds information in RDF, RDFa or Microformats (standards for the Web
of Data).
• SIREn - Semantic Information Retrieval Engine - is a Lucene plugin to efficiently index
and query RDF, as well as any textual document with an arbitrary amount of
metadata fields.
• Silk Link Discovery Framework supports data publishers in accomplishing the second
task12
.
• Sieve allows Web data to be filtered according to different data quality assessment
policies and provides for fusing Web data according to different conflict resolution
methods.
• LODrefine is OpenRefine with integrated extensions that enable you to reconcile and
extend data with DBpedia, extract named entities and upload your data on
CrowdFlower crowdsourcing service.
• Virtuoso is an innovative industry standards compliant platform for native data,
information, and knowledge management. It implements and supports a broad
spectrum of query languages, data access interfaces, protocols, and data
representation formats that includes: SQL, SPARQL, ODBC, JDBC, HTTP, WebDAV,
XML, RDF, RDFa, and many more13
.
• PoolParty is a thesaurus management system and a SKOS editor for the Semantic
Web including text mining and linked data capabilities. The system helps to build and
maintain multilingual thesauri providing an easy-to-use interface.
• CKAN is a powerful data management system that makes data accessible – by
providing tools to streamline publishing, sharing, finding and using data. CKAN is
aimed at data publishers (national and regional governments, companies and
organizations) wanting to make their data open and available.
• DBpedia Spotlight is a tool for automatically annotating mentions of DBpedia
resources in text, providing a solution for linking unstructured information sources to
the Linked Open Data cloud through DBpedia. DBpedia Spotlight performs named
entity extraction, including entity detection and Name Resolution (a.k.a.
disambiguation). It can also be used for building your solution for Named Entity
Recognition, amongst other information extraction tasks.
12
http://lod2.eu/Project/Silk 13
http://lod2.eu/Project/Virtuoso
![Page 17: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/17.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 17 of 77 © SmartOpenData Consortium 2014
3.4 GeoKnow project14
The GeoKnow vision is to make geospatial data accessible on the web of data and turn the
Web into a place where geospatial data can be published, queried, reasoned, and
interlinked, according to the Linked Data principles15
. This will move geospatial data beyond
syntactic interoperability to actual semantic interoperability, and to services that can
geospatially reason on the Web.
GeoKnow aims to repurpose SDI standards, enabling the existing vast body of geospatial
knowledge to be introduced in the Data Web. Further, it will apply the RDF model and the
GeoSPARQL standard as the basis for representing and querying geospatial data. In
particular, GeoKnow contributions will be in the following areas:
• Efficient geospatial RDF querying.
o Existing RDF stores lack performance and geospatial analysis capabilities
compared to geospatially-enabled relational DBMS. GeoKnow will focus on
introducing query optimisation techniques for accelerating geospatial querying at
least an order of magnitude.
• Fusion and aggregation of geospatial RDF data.
o Given a number of different RDF geospatial data for a given region containing
similar knowledge (e.g. OSM, PSI and closed data16
) and will devise automatic
fusion and aggregation techniques in order to consolidate them and provide a
data set of increased value and quantitative quality metrics of this new data
resource
• Visualization and authoring.
o GeoKnow will develop reusable mapping components, enabling the integration of
geospatial RDF data as an addition data resource in web map publishing. Further,
it will support expert and community-based authoring of RDF geospatial data
within interactive maps, fully embracing crowdsourcing.
• Public-private geospatial data.
o To support value added services on top of open geospatial data, GeoKnow will
develop enterprise RDF data synchronisation workflows that can integrate open
geospatial RDF with closed, proprietary data. It will focus on the supply chain and
e-commerce use cases.
• GeoKnow Generator.
o This will consist of a full suite of tools supporting the complete lifecycle of
geospatial linked open data. The GeoKnow Generator will enable publishers to
triplify geospatial data, interlink them with other geospatial and non-geospatial
Linked Data sources, fuse and aggregate linked geospatial data to provide new
data of increased quality, visualise and author linked geospatial data in the Web.
GeoKnow aims to contribute to the following areas concerned with geospatial data:
14
http://geoknow.eu and also see “GeoKnow: Leveraging Geospatial Data in the Web of Data”, Garcia-Rojas,
Athanasiou, Lehmann and Hladky, http://www.w3.org/2013/04/odw/odw13_submission_15.pdf 15
See for instance, Soren Auer and Jens Lehmann. Making the web a data washing machine – creating
knowledge out of interlinked data. Semantic Web Journal, 2010. 16
http://ec:europa:eu/informationsociety/policy/psi/indexen:htm
![Page 18: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/18.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 18 of 77 © SmartOpenData Consortium 2014
• Creation and maintenance of qualitative geospatial information from existing
unstructured data such as OpenStreetMap, Geonames and Wikipedia, anticipating
geospatial search and acquisition and aggregation of information resources.
• Reuse and exploitation of unforeseen discoveries found in geospatial data. GeoKnow
will provide methods to acquire, analyze and categories data that is rapidly evolving,
immense, incomplete and potentially conflicting with: Tools and methodologies for
mapping and exposing existing structured geospatial information on the web of data,
considering comprehensive and qualitative ontologies and efficient spatial indexing.
• Automatic fusing and aggregation of geospatial data by developing algorithms and
services based on machine learning, pattern recognition and heuristics.
• Tools for exploring, searching, authoring and curating the Spatial Data Web by using
Web 2.0 and machine learning techniques based on scalable spatial knowledge
stores.
All these contributions are integrated in the open source GeoKnow Generator framework
developed by the consortium.
Figure 3 GeoKnow High-Level Architectural Overview
The GeoKnow Generator will provide a comprehensive toolset of easy-to-use applications
covering a range of possible usage scenarios (e.g. mobility/traffic, energy/water, culture,
etc).
3.5 SemaGrow project
In order to achieve this ambitious vision and solve a difficult data management problem,
SemaGrow is addressing the following key challenges:
• Develop novel algorithms and methods for querying distributed triple stores that can
overcome the problems stemming from heterogeneity and from the fact that the
![Page 19: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/19.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 19 of 77 © SmartOpenData Consortium 2014
distribution of data over nodes is not determined by the needs of better load
balancing and more efficient resource discovery, but by data providers.
• Develop scalable and robust semantic indexing algorithms that can serve detailed
and accurate data summaries and other data source annotations about extremely
large datasets. Such annotations are crucial for distributed querying, as they support
the decomposition of queries and the selection of the data sources that each query
component will be directed to.
• Since it is, in the general case, not possible to align schemas and vocabularies so
perfectly that there is no loss of information, investigate how to minimize losses and
how to not accumulate them over successive schema translations.
The SemaGrow Large Scale Distributed Architecture Stack is as follows17
:
Figure 4 SemaGrow Architecture
3.6 DCAT application profile for data portals in Europe
The DCAT Application profile for data portals in Europe (DCAT-AP)18
is a very new
specification based on the Data Catalogue vocabulary (DCAT) 19
for describing public sector
17
From http://www.semagrow.eu/sites/default/files/SemaGrow_D2.3.1-
Large%20Scale%20Distributed%20Architecture.pdf 18
DCAT-AP: https://joinup.ec.europa.eu/asset/dcat_application_profile/description 19
DCAT: http://www.w3.org/TR/vocab-dcat/
![Page 20: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/20.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 20 of 77 © SmartOpenData Consortium 2014
datasets in Europe. Its basic use case is to enable cross-data portal searching for data sets
and making public sector data better searchable across borders and sectors. This can be
achieved by the exchange of descriptions of data sets among data portals.
Mandatory classes for the profile are:
• Agent (e.g. Organisation)
• Category (Subject of Dataset)
• Category scheme (Controlled vocabulary the theme comes from)
• Catalogue (Repository that hosts the dataset)
• Literal (Literal value)
• Resource (Anything described by RDF])
E.g. for all datasets mandatory properties are title and description, recommended contact
point, dataset distribution, keyword/tag, publisher theme/category
3.7 CKAN domain model
CKAN is an open source system for publishing data on the web. It provides tools to
streamline publishing, sharing, finding and using data.
The published metadata schemas are proprietary and provide some mapping to Dublin Core
elements. Also adding proprietary user defined elements is allowed. Harvesting of OGC CSW
2.0.2 + ISO 19139 spatial metadata standards are available with extensions.
CKAN metadata profile:
• id: unique id
• name (slug): unique name that is used in urls and for identification
• title (dc:title): short title for dataset
• url (home page): home page for this dataset
• author (dc:creator): original creator of the dataset
• author_email:
• maintainer: current maintainer or publisher of the dataset
• maintainer_email:
• license (dc:rights): license under which the dataset is made available
• version: dataset version
• notes (description) (dc:description): description and other information about the
dataset
• tags: arbitrary textual tags for the dataset
• state: state of dataset in CKAN system (active, deleted, pending)
• resources: list of resources
![Page 21: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/21.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 21 of 77 © SmartOpenData Consortium 2014
• groups: list of groups this dataset is a member of
• “extras” - arbitrary, unlimited additional key/value fields
3.7.1 CKAN and GeoNetwork for an integrated Open Data Portal
The OpenDataNetwork Project20
is a joint project promoted by a number of Public
Administrations located in the Italian Region of Tuscany, who developed a federated spatial
data infrastructure for the publication of their data (geospatial as well as alphanumeric) as
OpenData.
The OpenDataNetwork infrastructure is as follows:
Figure 5 OpenDataNetwork System & Nodes Architecture
The goal of the federation is to allow each partner administration to deploy the components
they would need to have a complete and ready-to-use infrastructure for the publication of
data as Open Data relying on Open Source products and accounting for the possibility to
reuse existing components (e.g. proprietary geospatial servers) in order to minimize the
impact. The Central Hub would then harvest the information from each Partner's
Deployment (with particular care to avoiding cyclic graph in the harvesting set up) in order
to act as the single entry point for the entire network. The possibility to have multiple
hierarchical levels is foreseen and allows implementation without further development (e.g.
a new County could join acting also as a Hub for its own cities which would not be harvested
by the Central Hub).
The node Architecture puts together in each instance all of the building blocks that a Partner
could need to ingest and disseminate geospatial and alphanumeric data with particular
emphasis on geospatial data. The system uses existing standards for the interconnections in
order to account for the possibility to swap some components with other similar ones. E.g. it
would be possible to swap the catalogue implementation from GeoNetwork to a different
catalogue providing it implemented the OGC CSW protocol.
3.8 INSPIRE metadata and DCAT-AP
A proposal for the alignment of INSPIRE metadata with the DCAT Application Profile is under
preparation by the Joint Research Centre of the European Commission, in the framework of
20 www.opendatanetwork.it
![Page 22: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/22.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 22 of 77 © SmartOpenData Consortium 2014
Action 1.17 of the EU ISA Programme. The document is still under the development status
and the working draft may dramatically change before final release. The profile uses INSPIRE
registr21
y together with DCAT defined classes for the mapping. This profile is very important
because it mediate the bridge between the INSPIRE and other European portals. It is
intended to implement this profile and test its usability and stability in the scope of
SmartOpenData project.
Example (part of the file):
… <rdf:Description rdf:about="http://someURI"> <foaf:primaryTopicOf rdf:resource="metadataURI"/> <!-- Resource language --> <dct:language rdf:resource="http://publications.europa.eu/resource/authority/language/DEU"/> <!-- Resource title --> <dct:title xml:lang="en">Forest / Non-Forest Map 2006</dct:title> <!-- Resource abstract --> <dct:description xml:lang="en">Pan-European Forest / Non Forest Map with target year 2006, Data Source: Landsat ETM+ and Corine Land Cover 2006, Classes: forest, non-forest, clouds/snow, no data; Method: automatic classification performed with an in-house algorithm; spatial resolution: 25m. In addition, the forest map 2006 is extended to FTYPE2006 to include forest types (broadleaf, coniferous forest) that are mapped using MODIS composites.</dct:description> <!-- Resource type --> <rdf:type rdf:resource="http://www.w3.org/ns/dcat#Dataset"/> <dct:type rdf:resource="http://inspire.ec.europa.eu/codelist/resource-type/series"/> <!-- Resource locator --> <dcat:landingPage rdf:resource="http://someurl.org"/> <!-- Unique resource identifier --> <dct:identifier rdf:datatype="http://www.w3.org/2001/XMLSchema#string">namespace/code</dct:identifier> <!-- Topic category --> <dct:subject rdf:resource="http://inspire.ec.europa.eu/codelist/topic-category/geoscientificInformation"/> <!-- Keywords corresponding to an INSPIRE spatial data theme --> <dcat:theme rdf:resource="http://inspire.ec.europa.eu/theme/landCover"/> <!-- Keyword from another controlled vocabulary --> <dcat:theme> <skos:Concept> <rdfs:label xml:lang="en">coniferous forest</rdfs:label> <skos:inScheme> <skos:ConceptScheme> <rdfs:label xml:lang="en">GEMET - Concepts, version 2.4</rdfs:label> <dct:issued rdf:datatype="http://www.w3.org/2001/XMLSchema-datatypes#date">2010-01-13</dct:issued> </skos:ConceptScheme> </skos:inScheme> </skos:Concept> </dcat:theme> <!-- Geographic bounding box --> <dct:spatial> <dct:Location> <locn:geometry rdf:datatype="http://www.opengis.net/rdf#GMLLiteral"> <gml:Envelope srsName="http://www.opengis.net/def/crs/OGC/1.3/CRS84"> <gml:lowerCorner>-10.58 34.56</gml:lowerCorner> <gml:upperCorner>34.59 70.09</gml:upperCorner> </gml:Envelope> </locn:geometry>
21 http://inspire.ec.europa.eu/registry/)
![Page 23: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/23.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 23 of 77 © SmartOpenData Consortium 2014
</dct:Location> </dct:spatial>
…
![Page 24: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/24.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 24 of 77 © SmartOpenData Consortium 2014
4444 RM-ODP methodology
4.1 RM – ODP methodology
D2.3, architecture design is realized on the base of a Reference Model of Open Distributed
Processing22
. This model is the architecture reference model used also within ISO/TC 211
“Geographic Information – Reference model”23
, and on Open Geospatial Consortium
Reference Model (ORM).
The use of RM-ODP will give us two opportunities:
• To define the basic design of the solution as platform neutral and to support different
local implementation. This is important, because the objective of this document is
not to describe one unique technology solution, but to give general models, which
could be used by different organization across Europe. These models are then
demonstrated on selected pilot cases that are part of the project, in order to
demonstrate the feasibility of such solution
• To build on positive experiences of previous European research projects, as this
methodology is used by most European (mainly research) projects and some
recommendations already exist, our objective is to extend these models to make
them more oriented towards actual user needs.
The architecture design provides an overall conceptual framework for building geo-
processing services for biodiversity, sea region protection and for effective management and
utilization of sensitive areas.
4.2 View point approach
The RM-ODP divides all process of architecture design into five generic and complementary
steps, which are called viewpoints on the system and its environment. These viewpoints are:
• The enterprise viewpoint, which focuses on the purpose, scope and policies for the
system. It describes the business requirements and how to meet them. It is based on
user scenarios and user cases.
• The information viewpoint focuses on the semantics of the information and the
information processing performed. It describes the information managed by the system
and the structure and content type of the supporting data. This viewpoint is related to
WP3, where data and metadata models are defined. The Information viewpoint extends
these models and analyses also necessary operation.
22
RM-ODP) (ISO/IEC 10746-1 23
ISO 19101:2002
![Page 25: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/25.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 25 of 77 © SmartOpenData Consortium 2014
• The computational viewpoint provides functional decomposition of the system into
objects that interact at interfaces. It describes the functionality provided by the system
and its functional decomposition.
• The engineering viewpoint focuses on the mechanisms and functions required to
support distributed interactions between objects in the system. It describes the
distribution of processing performed by the system to manage the information and
provide the functionality.
• The technology viewpoint focuses on the choice of technology of the system. It describes
the technologies chosen to provide the processing, functionality and presentation of
information. In principle only this viewpoint is platform dependent. In our architecture
design in this first document we will analyze potential components for implementation.
Figure 6 RM ODP viewpoints24
For the architecture design of SmartOpenData we adapted RM ODP methodology to
guarantee real adoption of user needs and to give real possibilities of end user involvement
into the design process. The design process will be done iteratively with this as the first
version, so all views will be modified on the basis of user validation and user experiences. It
is necessary to take into consideration, that in many cases users are not familiar with newest
technologies and also have no experience in the design of distributed systems. Another
important aspect is also, that we don’t design one concrete solution, but a number of
relatively independent services. In order to allow reuse of some components we have
defined among pilots what common generic functions are fulfilling the requirements of
24
http://en.wikipedia.org/wiki/RM-ODP
![Page 26: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/26.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 26 of 77 © SmartOpenData Consortium 2014
different scenarios and what specific solution dependent components are. In the first
version of the design, we will focus mainly on generic functionality, in the second version;
we will try to add more pilot specific functions.
The relation of all these five viewpoints could be described by the following scheme:
The Enterprise viewpoint of the architecture design is focused on the analysis of pilot
scenarios and the definition of a limited numbers of generic use cases, which are
implemented to support basis functionalities required by more scenarios, but also
supporting the process of data and metadata harmonization based on outputs from WP3.
The Information viewpoint is focused on basic data and metadata sets, which could be
shared among different scenarios and will be focused on data and metadata related to
SmartOpenData specification.
The Computational viewpoint is focused on generic components, which could be reused for
more scenarios and which will be some basic parts of the infrastructure.
The Engineering viewpoint defines a generic scheme, which can be reused for all pilot
implementations and which could be modified for different scenarios. Also this viewpoint is
platform independent.
The Technical viewpoint defines basic architecture modifications for single scenarios and
suggests potential technical implementation. This solution is really basic definition and will
give more option of implementation. Concrete implementation will be modified during the
implementation and validation process.
4.3 Generic and pilot design
An important part of the methodology is to divide design of generic architecture and pilot
dependent architecture. On the basis of user requirements, generic use cases will be defined
and generics services will be designed for these generic use cases, which will be reusable for
different pilot solutions. On the basis of these generic services pilot applications will be
defined, which will be composed from generic services. Generic services will be available for
developers so they can implement specific user applications using these generic services.
Important is, that these applications can reuse existing components.25
25
D-4.2.2 HABITATS INSPIRE Networking Architecture, CIP- ICT-PSP-2009-3-250455, Social Validation of INSPIRE
Annex III Data Structures in EU Habitats, 2010
![Page 27: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/27.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 27 of 77 © SmartOpenData Consortium 2014
5555 Enterprise viewpoint
According to the SmartOpenData user-driven approach to standardization, the full impact of
results will be sparked off by the pilot service scenarios and their ability to prove feasibility
of the architecture and attract new participants to the communities of adoption. Each pilot is
therefore built on
a) existing concrete services currently carried out by project partners,
b) potential for data access through Linked Open Data and
c) Enhancement through usage scenarios developed by user communities, in order to
meet the three criteria of relevance, openness and responsiveness.
5.1 Basic pilots
The five SmartOpenData pilots fall into the next forward-looking categories described above
as follows:
Pilot I Spain (Public sector) Agroforestry management TRAGSA
Portugal-Spain Pilot focuses on building a web based collaborative spatial data infrastructure
prototype with the main goal of promoting sustainable agro forestry management.
Pilot II Ireland (Research, Enterprises) Environmental research, Biodiversity MAC
Irish Pilot will focus on the use of the SmartOpenData to provide open data and open
INSPIRE-compliant geo-spatial sources for environmental researchers particularly
focused on biodiversity and habitats, building on the participative social validation and
pilots of the HABITATS project in particular.
Pilot III Italy (Citizens) Water monitoring A.R.P.A. Sicilia
The Italian pilot in Sicily will explore the role of aggregating information from different Open
Data sources in order to support ARPA’s institutional mission of providing up to date
monitoring of water quality in Sicily.
Pilot IV Czech (Enterprises & Public sector) Forest sustainability UHUL FMI
Czech Republic is focused on the forest site classification, sustainable management and
utilization of forest road network using the National Forest Inventory and the Regional
Plans for Development datasets.
Pilot V Slovak (Citizens) Environmental data reuse SAZP
Slovakian Pilot will include the proposal, development and deployment of two conceptually
different types of web applications in order to achieve reuse of environmental data and
information in line with European Open Data Strategy:
1. Spatial Web Crawler: Aiming to support search and discovery of available spatial
resources
![Page 28: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/28.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 28 of 77 © SmartOpenData Consortium 2014
2. Biodiversity MashUp Linked Open Data Extension: Providing the evidence of linking
biodiversity related resources and contribution into decision support process.
Due the fact, that most of pilots are oriented mainly on publishing data, we add two
additional scenarios, which will be focused mainly on utilization of LOD. These two scenarios
are:
• Territorial decision - with focus on linkage of from data coming from project
Plan4business with data from SmartOpenData pilots, mainly forestry related data,
water quality environmental data. The Plan4business project collected large amount
of data, which are now opening, but disadvantage is, that data available for analysis
has to be stored on one portal. Using principles of LOD will be possible linked
distributed resources
• Discovery and utilize tourist related information coming from different repositories
trough one access point. The problem of current information related to tourism is or
stored in large repositories or are distributed on many servers and they are not well
visible. Environmental information collected mainly in Italian Slovak and Irish pilots
are interesting source of information for tourists.
Adding these two additional cross pilot activities suggested by SME partners will support
better utilization of available LOD by developers and providers of commercial services.
5.2 Common search and indexing facilities
Additionally to Pilot requirements, SmartOpenData will offer for external users searching,
indexing and visualization facilities, which will
- Provide common facilities for exploiting environmental data.
- Improve environmental data search ability thanks to integration of big data
infrastructure for structured and
- Semi-structured search facilities.
- Provide a semantic front-end framework for environmental data visualization.
These tools are part of WP4 design. WP4 system is creating services that take advantage of
such data and provide valuable services for each community illustrating how the availability
of such services and the corresponding data can provide advantages for them.
Between the pilot data sources and the external data consumer the SmartOpenData System
is placed providing key functionalities. The most basic element is the harmonization of data
sources. This element will offer an open data source layer that exposes the external data
sources fully adapted to the open data standards supported by the project.
Over this open data source layer, three key functionalities are defined:
(i) distributed semantic indexing, which provides a service for searching and locating
data based on semantic information collected from all the available Data Sources;
(ii) distributed data access, which provides data collected from external data sources, as
an extra data source for easier and uniform data gathering from the users at the
identified scenarios;
![Page 29: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/29.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 29 of 77 © SmartOpenData Consortium 2014
(iii) Administration and notification, which provides administration facilities for managing
users, workflows and data to data providers.
These three functional components will be communicated and coordinated inside the
SmartOpenData System, creating a distributed service system which can be accesses
transparently from the scenarios. It is also important to note that it will be possible for
services created on the scenarios to access directly external data sources selected thought
the distributed semantic indexing functionality. Pilot functional requirements
5.2.1 Spain (and Portugal)
The pilot will be mainly focused on meeting the needs and requirements of the public sector
regarding forest management and land use planning normative requirements. Another facet
of the pilot will be related with water and drinking water management. In both countries,
public bodies from these areas involved in the pilot, have defined their requirements and
will provide data and assess project results as final users.
Spanish and Portuguese public bodies count on environmental and geospatial information
that can be very valuable for management purposes. This information has a huge potential,
but it is usually not widely accessible and not sufficiently exploited, and needs to be
reorganized accordingly.
The final goal of this pilot is to provide an easy access to this information and to develop
decision making tools and services available and helpful for public and private agroforestry
managers. Results and outcomes will be open, standardized and of public access including
web services and information management applications. The technological approach will be
based on Open Data (environmental monitoring data, cartographic services and remote
sensing products) linked through INSPIRE compliant semantic services. This strategy based
on Open Data is necessary in order to optimize the use of public information, improve
management issues and involve stakeholders in decision making processes.
The Spanish pilot defined next concrete use cases:
• Determination of the best forestry species - offer a list of the best species to plant in
a particular plot. It allows taking the best decisions for the actor needs. The actors
could know which species are usually planted but is useful offer a tool with the
species more recommended for each plot. The use case is to be able get best species
clicking in any plot. After that the user can combine available data about cadastre,
species and any other layer and variable that interests to query, filter to choose the
best option.
• Best origin of seeds determination on forestry - offer the best plots to harvest seeds
for the citizen’s choice and determinate if the plot has been visited. It allows taking
the best decisions, showing the offer and saving time for the actors. The use case is
to be able combine available data about species, admission units, and any other layer
and variable that interests to query, filter and display the candidate units. In this way,
the user can check the information about seeds from anywhere and assist to
decision-making. Finally, the updating of the visits to the different units prevents to
visit them without the expected result. The citizens who usually turn to search for
seeds are foresters and forest owners. Also they could obtain information from the
nurseries data about the availability of any seed and its quality. This point is relevant.
![Page 30: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/30.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 30 of 77 © SmartOpenData Consortium 2014
There are four classes of seeds by quality: Identified: known origin, Selected: chosen
seeds, Qualified: seed from best individuals, Controlled: certify that the seed will
grows fine. The public bodies are divided among the nurseries, in this case the
"Viveiro de Ourense", which are also units of admission, provincial officers who
manage the visits, and the owners of the data used, such as the Data Bank for
Nature.
The generic LOD functionalities required by Spanish pilots are:
• Transformation (Relational data -> RDF)
• Storage
• Search
• Federated querying
• Visualization of LOD
• Visualization of LOD using conventional GI tools
5.2.2 Ireland
Seamlessly The Irish pilot bridges the major gap between the “worlds” of open data and INSPIRE
geo-spatial sources, to validate a major value-add and impact on their work. Some of the main issues
to be addressed include (i) Discovery and seamless use, and mashing together of all available sources
to address immediate research issues; (ii) Overcoming the barriers (cultural, political, administrative)
to opening up the data; (iii) Overcoming technical incompatibilities of datasets in terms of technical
standards, semantic structuring etc. (iv) Validation of the SmartOpenData platform in the
aggregation, analysis, and visualization to support decision making of the various research and
stakeholders requirements. This will use and complement the Biodiversity MashUp Linked Open Data
Extension and Spatial Web Crawler of the Citizens pilot but will focus more on identifying and
seamlessly using various sources at International, European, National and local levels by researchers.
This will be complemented by various social networking and crowdsourcing mobile apps to engage
stakeholders at the local level in particular developed as part of Irish pilot.
The pilot will begin at European level by using and seamlessly integrating the SmartOpenData
platform into, collaborating with, and building on various open data and geo-spatial sources and
initiatives that will have a particular value for biodiversity researchers, including (i) The European
Biodiversity Observation Network, EUBON project26
(ii) European Environmental Agency (EEA)
Biodiversity data centre (BDC)27
; (iii) PESI28
; (iv) FP7 EUBrazilOpenBio29
; (v) LifeWatch European
research infrastructure30
; (vi) The Joinup Portal31
; (vii) The UK Environmental Agency’s Datashare32
;
(viii) The Global Biodiversity Information Facility (GBIF)33
. This pilot will also use SmartOpenData to
mash disparate open data sources such as those listed at FreeGISdata34
and the GeoStore, which
allows use subject to the terms and conditions of the Open Government Licence (OGL), and others, in
various data formats. The implications of these for researchers will be explored in the pilot and
supported using the platform.
26
www.earthobservations.org/geobon.shtml; 27
www.eea.europa.eu/themes/biodiversity/dc 28
www.eu-nomen.eu/portal 29
www.eubrazilopenbio.eu 30
www.lifewatch.eu 31
joinup.ec.europa.eu/catalogue 32
www.geostore.com/environment-agency/WebStore 33
www.gbif.org 34
freegisdata.rtwilson.com
![Page 31: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/31.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 31 of 77 © SmartOpenData Consortium 2014
At a national level this pilot will focus on Ireland. Mid-West Regional Au, with the technical support
of MAC, will work with Irish public agencies, Local Authorities and community groups in the
implementation and use of the SmartOpenData platform in validation trials. These will include the
use of sources such as (i) The Irish National Parks & Wildlife Services (NPWS) who have extensive
open online maps and datasets35
; (ii) The National Biodiversity Data Centre Ireland36
; (iii) The Irish
Opendata Portal37
; (iv) The Irish Spatial Data Exchange (ISDE38
) and (v) The Marine Institute Ireland,
who have extensive OGC/INSPIRE compliant geo-spatial data 39
, which are all searchable using the
ISDE Browser40
. In addition there are a number of interactive services available to the public, such as
the vessel tracking service and Survey Planning System 41
.
The Irish pilot defined next concrete use cases:
• SmartOpenData enabled ETIS Webservice for the Burren & European GeoParks
Network - The SmartOpenData enabled European Tourism Indicators System (ETIS)
webservice for sustainable management at destination level, will streamline and
enhance the current manual system by transforming the ETIS Excel dataset into
Linked Open Geospatial Data. The Burren Geopark’s solidity as a destination is
exemplified by its benchmarking and monitoring procedures. It has adopted the
recently launched European Tourism Indicator System for the Sustainable
Management of Destinations (ETIS) to monitor and measure performance and is
one of 100 destinations in Europe that are currently piloting this system. Further to
this, Failte Ireland, the national tourism development authority, has expressed
interest in using the Geopark’s work on the ETIS as a pilot for assessing for larger-
scale, national projects. .
• SmartOpenData enabled Farming for Conservation webservice - The SmartOpenData
platform will be used to make the BFCP data open and linked, with integrated spatial
content, while protecting its sensitive data. The Burren Farming for Conservation
Programme (BFCP) provides a template for the future management of the Burren
and other HNV areas. Appropriate management of the land ensures the maintenance
of and/or improvement in the conservation status of the Annex I habitats and lead to
an increase the area of sustainably managed high nature value farmland within the
Burren. This will in turn lead to an improvement in water quality in aquatic
ecosystems and ensure the maintenance of and/or improvement in the high quality
Burren landscape and its cultural heritage. A series of databases has been set up and
is being maintained to manage and store the wide variety of data and additional
information generated by the BFCP. This includes Microsoft Excel format
spreadsheets of successful applicants and appellants, advisors, workers (available to
assist participants with Measure 2 work), contacts, farm plan checks and site visits,
farmer training bookings and attendance, receipt of signed plans, Measure 2
declaration forms (Form D1 and Form D2) and receipts requested, farmer and advisor
feedback, summary data from farm plans (including areas (ha), REPS/AEOS
35
www.npws.ie/mapsanddata 36
www.biodiversityireland.ie 37
opendata.ie 38
www.isde.ie 39
www.marine.ie/home/publicationsdata 40
catalogue.isde.ie 41
www.marine.ie/home/services/researchvessels
![Page 32: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/32.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 32 of 77 © SmartOpenData Consortium 2014
participation, payments, length/area/number for Measure 2 tasks and M1 scores),
payment checks, detailed Measure 1 assessment records for monitoring purposes.
GIS databases have been set up and include spatial data such as DAFM land parcels,
Ordnance Survey Ireland maps and aerial photos (for which a third party license
request via NPWS was applied for in June 2010), farm boundaries, field boundaries,
SAC designated areas, and national monuments. The SmartOpenData platform will
be used to make this data open and linked, with integrated spatial content, while
protecting its sensitive data. All practical precautions will be put in place to protect
sensitive data, such as BFCP participants’ contact and payment information. As the
NPWS data is predominantly INSPIRE compliant, the SmartOpenData platform will
enable its seamless interoperability with the BFCP datasets. The SmartOpenData
enabled webservice will support the BFCP Team (including Programme Manager and
Programme Scientist) in the production and maintenance of a set of detailed,
comprehensive and regularly updated datasets on all aspects of the farm plans and
the monitoring programmes. It could provide access to the DAFM and NPWS Land
Parcel Identification System (LPIS) based on-line planning system, aerial photographs
and digital maps through a third party agreement with OSI. The system will provide a
template for future management of the Burren and other HNV areas. The Farming for
Conservation webservice will have an easy-to-use user interface, and its users will be
the BFCP Team, Advisors and relevant Department people. Farmers may have limited
access (to their own farm’s data for instance, or input/editing of their farm plan).
Being linked and open, the webservice will enable seamless access by the NPWS and
relevant Government Departments (such as the Department of Arts, Heritage and the
Gaeltacht (DAHG) and Department of Agriculture, Food and the Marine (DAFM)).
Also, because it is linked and open, it will allow its seamless operation with the
Department’s own ESRI, ArcGIS systems using the appropriate open data plugins
• App to Ground-Truth potential Protected Monument sites. - SmartOpenData enabled
App to Ground-Truth potential Protected Monument sites. The SmartOpenData
platform will enable the provision of an App service to mobilise a very motivated
community, by enabling visitors and people interested in their local heritage, to seek
out and ground truth potential Monument sites in the Burren and beyond. At the end
of the project, the Heritage Council and National Monuments Service will decide if
the crowd-sourced ground truthing observations (both positive and negative) should
be included as a permanent Voluntary Geographic Information (VGI) layer on the
National Monuments map on their Mapping Viewer. This process will also initiate a
process for the digital preservation of the VGI data concerning the features that were
investigated, both those that are validated to be national monument sites, and those
that are not, to avoid people wasting their time and resources in investigating them
again. While the main users of the app service will be experienced archaeological
users and visitors to the Burren who are motivated to record the local heritage, the
app and process will be very educational and will probably be used by teachers and
students to discover and contribute to their local heritage. For instance, it could
complement the courses and practical local environmental work carried out by
BurrenBeo Trust. The Burren is very well observed and recorded over many years, so
few new National Monument sites are likely to be found. However other sites, such
as Lough Derg and the Slieve Aughtry, which is also in the Mid-West Region of
Ireland, is likely to yield many new national monuments. So further sites, beyond the
![Page 33: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/33.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 33 of 77 © SmartOpenData Consortium 2014
Burren, are likely to be supported by this Application quite early during the WP5 pilot
trials. The SmartOpenData App may also help Burren farmers (as well as Irish farmers
generally) to determine if their farm might contain a potential National Monument
Site (especially field systems) on their land. The BFCP works closely with the National
Monuments Service and the existing legislation for National and Recorded
Monuments. In order to satisfy the legal requirement for farmers with regard to work
carried out at, or near, any recorded monument or place, a procedure has been
developed whereby the BFCP prepares and submits the notification to the
Monument Protection Officer for County Clare with the National Monument Service,
on behalf of the farmer. In addition, the BFCP arranges for the Field Monuments
Advisor, to visit farmers who are proposing work in the vicinity of monuments or in
archaeologically sensitive areas so that he can talk to them about their archaeological
features, provide advice and generally raise their awareness re the significance of
archaeology in the Burren.
• SmartOpenData Platform input to the Irish OGP process and W3C “CSV on the Web”
standard - SmartOpenData Platform input to the Irish OGP Open Data Portal process
and W3C “CSV on the Web” standard, with a CKAN CSV-to-RDF extension and
reference implementation. The SmartOpenData platform will complement the
ongoing work of the Government Reform Unit by providing best practice tools,
insights seamless access to data sources and validation (in the WP5 pilots) to address
objective 4 of the Irish Government’s OGP Initiative. The SmartOpenData platform
CSV-to-RDF tools, as developed and used in the other Irish use cases and
applications, will be adapted as a CKAN add in, for use on the Irish OGP alpha site and
reference implementation of the W3C “CSV on the web” WG standard. . The WG will
finalise and issue their standard most likely at the end of 2014, so will evolve in
parallel with the SmartOpenData WP5 trials. The CKAN extension will be trialed and
validated in the Irish Pilots and Irish OGP process implementation of the Irish Open
Data Portal alpha site.
The generic LOD functionalities required by Irish pilots are:
• Transformation (Relational data -> RDF)
• Storage
• Search
• Federated querying
• Visualization LOD
• Visualization of LOD using conventional GI tools
• Publishing data from existing CSV databases as RDF
• Upgrading data
5.2.3 Italy
The Italian pilot in Sicily will explore the role of aggregating information from different Open
Data sources in order to support ARPA’s institutional mission of providing up to date
monitoring of water quality in Sicily. Some of the main issues to address are (i) Overcoming
the barriers (cultural, political, administrative) to opening up the data; (ii) Identifying the
optimal role of the general public in crowdsourcing environmental information; (iii)
![Page 34: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/34.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 34 of 77 © SmartOpenData Consortium 2014
Identifying the technical means of publication; (iv) Overcoming incompatibilities of datasets
in terms of technical standards (eg JSON vs XML), semantic structuring, etc.; (v) Optimum
ways of aggregation, analysis, and visualization to support decision-making for the different
stakeholders including the general public.
The three main stakeholder groups involved are: (i) Different offices within A.R.P.A. Sicilia
itself, in particular the link between the central office in Palermo and the local offices
distributed throughout the region; (ii) Key external stakeholders with a role in environmental
monitoring, including The ASL (local health care divisions), Ex-ATO (water supply at sub-
regional level) and City administrations; (iii) The general public providing information
through e.g. Geoblogging.
The Italian pilot defined next concrete use cases:
• Quality of sub-surface water publishing a list of existing or available datasets held by
ARPA or other public actors potentially useful for different purposes (work, hobby,
tourism, general information, etc.) of different stakeholders as LOD
• Quality of surface water (rivers, lakes and transition) publishing a list of existing or
available datasets held by ARPA or other public actors potentially useful for different
purposes (work, hobby, tourism, general information, etc.) of different stakeholders
as LOD
• Presence of micro-algae in coastal waters - publishing a list of existing or available
datasets held by ARPA or other public actors potentially useful for different purposes
(work, hobby, tourism, general information, etc.) of different stakeholders
is(Ostreopsis ovata and other dinoflagellates potentially toxic) as LOD
• Quality of treated urban waste water - publishing a list of existing or available
datasets held by ARPA or other public actors potentially useful for different purposes
(work, hobby, tourism, general information, etc.) of different stakeholders as LOD
• Air quality - publishing a list of existing or available datasets held by ARPA or other
public actors potentially useful for different purposes (work, hobby, tourism, general
information, etc.) of different stakeholders as LOD
The generic LOD functionalities required by Italian pilots are:
• Transformation (Relational data -> RDF)
• Storage
• Search
• Federated querying
• Visualization of LOD
• Visualization of LOD using conventional GI tools
• Publishing data from existing SQL databases as RDF
5.2.4 Czech
Czech Republic is focused on the forest site classification, sustainable management and
utilization of forest road network using the National Forest Inventory and the Regional Plans
for Development datasets. Data products and statistical outcomes will be widely open,
![Page 35: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/35.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 35 of 77 © SmartOpenData Consortium 2014
standardized and accessible by foresters and public bodies through web services and
applications.
The Czech National Forest Inventory (NFI) Geoportal will present valuable information
derived from NFI database. Our data infrastructure can support SME’s decision-making
process via provision of reliable, up-to-date information about forests and its wood as well
as other types of resources. The geoportal will also enhance public awareness about the
NFI2 project funded by Czech Government, as well as the awareness about the UHUL FMI
institute itself. Data and metadata will be aggregated and standardized according to
commonly used standards and SmartOpenData recommendations, so they will be accessible
on a shared project platform. The geoportal will be a gate to results of the NFI1 and NFI2
projects, which are derived by statistical sound methods using a huge, high-quality database
fusing field survey, photogrammetric interpretation and remote sensing data. Data quantity,
its quality and a thematically broad scope of the UHUL FMI activities is an asset for testing
semantic search approaches among our data services and other environmental organization
sources across EU. UHUL FMI manages data covering the entire CZ territory, some of them
are freely available, however free access to the rest is limited to an aggregated level. It might
be useful to include also data with restricted access into semantic search tools and bring
them closer to SMEs -at least on the aggregated level.
The Czech pilot defined the next concrete use cases:
• Access to Czech NFI information - GENERIC USE CASE: Actors require up-to date
information on forests, forestry and land-use structure in the Czech Republic (CZ).
This information is needed for a variety of reasons that differs among actors. The
purposes and properties of NFIs are widely known. A full description is far beyond of
explanation possibilities here. In Czech, the current, regularly published informations
on forests are mostly significantly biased. These informations come either from
summarized forest management plans data (abbreviated as SFMP) or are based on
forest enterprise level statistics (questionnaire surveys). In Czech, high-quality,
regular update and statistical sound information on forests and landscape has not
been addressed yet. Czech NFI portal will address these issues in a generic way. It will
be based on NFI data and information, which will be transferred effectively to any
potential users. Users will be able to identify, search, filter and combine relevant
target parameters, the estimates of which would be delivered for specified domains
(geographic areas or attribute-based partitions e. g. land tenure, management
system, site index, potential and current soil degradation). The pilot aims to design
and implement ways how these informations can be found and presented to actors.
Detailed use-cases follow and extend this generic one.
• Access to Czech NFI information – general public - Actor requires information
confirming/or rejecting the practice of sustainable use of forests in particular area. To
be more concrete – possible indicators for the sustainable development in forests
might be: the species composition – estimators of species proportion on total forest
land in given area is asked, soil degradation - information on pH and nutrients
content changes from the previous inventory is required, change in forest cover
between actual and previous (inventory)
• Access to Czech NFI information – Ministry of Agriculture - Actor requires up-to date
information on available wood resources and balance of harvest and growth in: the
![Page 36: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/36.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 36 of 77 © SmartOpenData Consortium 2014
whole CZ territory and its NUTS subdivisions up to NUTS3 level, private forests,
forests managed by Czech state forest enterprise (cca. 1 200 000 ha), This
information is needed to address forest policy issues at the level of the whole sector
within CZ. Currently this information is based on severely biased data coming either
from summarized forest management plans data (abbreviated as SFMP, the amount
of wood resources underestimated by almost 40% when compared to Czech NFI1
inventory in 2001-2004) or from enterprise level surveys (amount of wood cut yearly)
- enterprises fill in a form, in which they themselves declare how much wood they
have harvested in particular year (existence of several sources of bias is well known).
When it comes to growth no direct observations are involved in the calculations at
the moment – SFMP data are used as inputs to yield tables (stand level growth
model). Czech NFI pilot would address this and similar issues in a generic way –
selecting and combining relevant target parameters, the estimates of which would be
delivered for specified domains (geographic areas or attribute-based subsets e.g.
land tenure, height above sea level etc.)
• Access to Czech NFI information – Ministry of Environment - Actor needs fresh
information on GHGs (green-house gasses) sinks and emissions from forest land to
include it into national-level calculations. These are used to compare emission limits
with the current state and possibly sell or buy emissions to/from other countries. At
this moment, this can be correctly done using the NFI data on soil GHGs content and
its changes as well as GHGs content in total biomass on forest land. These estimates
are obtained within NFI by means of relevant sampling scheme carried out straightly
in the field – assessing relevant variables, taking soil samples... Current practice
builds on data sources mentioned in previous example (SFMP, enterprise level
surveys, SFMP as input to growth model). The way of handling complex issues of soil
GHGs balance is not known to me at the moment. Currently we’re not aware of any
sampling based and periodic survey, collecting and processing soil data on forest land
over the whole country in a statistical sound manner. Czech NFI pilot would therefore
address this and similar issues in a generic way – selecting and combining relevant
target parameters, the estimates of which would be delivered for specified domains
(geographic areas or attribute-based subsets e.g. land tenure, height above sea level
etc.)
• Access to Czech NFI information – JRC of the EU - Actor needs information on total
growing stock and its changes to involve this into GHGs emissions scenarios
dedicated to forest land. This information is required in a standardized way –
following reference definitions elaborated by ENFIN (see
http://www.metla.fi/eu/cost/e43/) and for spatial unites defined by NUTS and
INSPIRE reference grids. Currently this can be achieved only via providing source data
from NFI2 to JRC or his partners. Using sophisticated estimation procedures
benefiting from proprietary auxiliary data is not possible – proprietary auxiliary data
can’t be provided to third parties (JRC or its partners). Czech NFI pilot would address
this and similar issues in a generic way – selecting and combining relevant target
parameters, the estimates of which would be delivered for specified domains
(geographic areas or attribute-based subsets e.g. land tenure, height above sea level
etc.
![Page 37: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/37.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 37 of 77 © SmartOpenData Consortium 2014
• Access to Czech NFI information – saw or pulp mill company - The actor needs
information on the current and future availability of wood fulfilling requirements for
a specific assortment class (e.g. saw-wood, or pulp-wood). Information on spatial
distribution of this resource is essential to allocate companies resources e.g. the mills
and logistic centers for the company’s products. Czech NFI portal would address this
and similar issues in a generic way – selecting and combining relevant target
parameters, the estimates of which would be delivered for specified domains
(geographic areas or attribute-based subsets e.g. land tenure, height above sea level
etc.).
• RPFD – Regional Plans of the Forest Development - RPFD contain global information
on forest state and on the role of the forest as a public interest subject including
strategic recommended management guidelines following the ecosystem
conception. They become an important background in decision process within the
regionally differentiated state forest policy and in promotion of the public interests.
The generic LOD functionalities required by Czech pilots are:
• Transformation (Relational data -> RDF)
• Publishing data from existing SQL databases as RDF
5.2.5 Slovakia
Slovakian pilot will include the proposal, development and deployment of two conceptually
different types of web applications in order to achieve reuse of environmental data and
information in line with European Open Data Strategy:
1. Spatial Web Crawler: Web-based application allowing a query definition for a
particular spatial and thematic domains related information resources available in
the deep web retrieved from indexing processes in the context of most used search
engines (eg.Google) and making this content available for SDI as well as linked data
world. Nowadays a geospatial user within an SDI searches for geospatial information
using discovery clients as components of applications of geoportal type (i.e. INSPIRE
Geoportal42
). If data producer wants to promote related resources and make them
available in SDI, they need to create metadata according to predefined rules (i.e.
INSPIRE metadata regulation) and publish them using CSW standard. Nevertheless
there is still a lot of data producers, making their resources available without
documenting and publishing the metadata through the CSW interface. The pilot
proposes solution, which aims at design and implementation of a framework allowing
to discover and provide an access to geospatial resources available in the deep web
which is not directly discoverable within existing SDIs (i.e. INSPIRE, GEOSS) as well as
by surface web search engines (i.e. Google). In addition a semantic extension based
on Linked Data principles will be taken into the consideration as the metadata
content collected by this pilot framework will be published using standard RDF
format. This step should close the circle by interconnection across different levels of
the geospatial web and at the same time should lead towards current open data
principles.
42
http://inspire-geoportal.ec.europa.eu
![Page 38: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/38.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 38 of 77 © SmartOpenData Consortium 2014
2. Biodiversity MashUp Linked Open Data Extension: Extension of existing Biodiversity MashUp
web 2.0 application43
with web 3.0 semantic linked open data dimension. Initial version of
this MashUp application was result of effort to show possibility to link various biodiversity
related information, where selected birds species were combined with their spatial
distribution and descriptive information from various sources (national spatial data providers
with information from Encyclopedia of Life). Main aim of the pilot is to make current
application content available in RDF encoding allowing linking available content with another
sources in a way to be read and queried by human readers as well as computers.
Geographical and content scope can be extended with the coverage of the countries
represented in the project consortium as well as relevant information resources (PESI (Pan-
European Species Directories Infrastructure)). In addition to this, pilot will contribute into
decision support process via helping citizens and decision makers to investigate, what kind of
biodiversity potential as well as environmental risks can be identified in the area of their
interest.
The Slovak pilot defined next concrete use cases:
• Creation of biodiversity and environmental risk related spatial linked data resources -
Use case is addressing the identification of essential procedural steps leading to
generation of spatial linked resources from the biodiversity and environmental risk
domain from different public sector bodies.
• Discovery of available spatial information resources on the Geospatial Web -
Objective is to collect data access service’s interface endpoints for spatial
information resources available within the layers of geospatial web as spatial data
infrastructures (available catalogues - CSW), the mainstream web (OGC WxS available
in the mainstream and not registered at any CSW – identification based on the OGC
WxS discovered URL = linkage/URL CSW ISO APP) represented by search engines
Basic metadata extracted will be provided to facilitate the discovery of available
resources through standardized human and machine-readable interfaces.
• View/Display of available spatial information resources aiming to support the
visualization of discovered and other available spatial data resources. Web based
application of geoportal type provides unique GUI to discover and view spatial
information from resources progressively predefined by users.
• Biodiversity & contamination in my neighborhood addressing possibilities to link
relevant biodiversity spatial and non-spatial linked data resources and their reuse via
mash up in the area of decision supporting for citizens as well as local governance
related activities.
The generic LOD functionalities required by Slovak pilots are:
• Transformation (GML -> RDF, relational data -> RDF, GMD44
-> RDF , or in another
words INSPIRE MD -> DCAT as described above)
• Storage
• Search
• Federated querying
• Visualization LOD
• Visualization of LOD using conventional GI tools
43
geop.sazp.sk:8080/geoserver-old/www/ps_mashup/index.html 44 http://www.isotc211.org/schemas/2005/gmd/
![Page 39: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/39.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 39 of 77 © SmartOpenData Consortium 2014
5.3 Cross-pilot functional requirements
5.3.1 Plan4business
The plan4business development team has designed and implemented the first operational
implementation of the plan4business service platform. There will be two main
implementations of the system. One is for non-expert users enabling browsing the content,
viewing the thematic compositions and predefined analysis and core pan-European datasets
such as Urban Atlas and Corine Land Cover. The other implementation is targeted at experts
users who are additionally able to create own map compositions, perform own analysis,
integrate spatial data into the common data model based on INSPIRE, download certain
datasets or use the developed Application Programming Interface (API). The prototypes are
used mainly for testing purposes and no charges will apply. The portal for non-expert users is
publicly available. Your feedback is appreciated.
The Plan4business defined next concrete use cases:
• Publishing of Plan4business Open Data as RDF - Types of data that the
plan4business.eu platform will allow to aggregate include: Urban and regional
planning data from different countries, Land use data including GMES Urban Atlas
data, Open Street Map data as representative of traffic and as a key reference
dataset, Natura 2000 data as information about potential restriction coming from
environment protection, Market information (number of properties, content, etc.
and transactions (sale, rental), their number, content, areas of distribution, price
levels), Social and economic data (CSP, Eurostat data), Individual property data (legal
status, current use, resources, construction data) and cadastral parcels data,
including property types. All data sets are stored n relational database together with
metadata. The objective is to making this data available as LOD
• Provide thematic reports combining Plan4business data with LOD - The Location
Evaluator is an app for user friendly access to data from various sources including
statistical, analytical and cadastral information. User can generate a comprehensive
report about a region, a municipality or a point of interest (currently limited to
buildings) in the Czech Republic through navigation in a map. Currently Location
Evaluator is working only with local data. The objective is to include LOD coming from
pilot as part of the reports.
The generic LOD functionalities required by Plan4business are:
• Publishing data from existing SQL databases as RDF
• Search
• Visualization LOD with other data
• Visualization of LOD using conventional GI tools
5.3.2 Tourism
Active tourism (as the contrary of passive tourism) is a special way to spend leisure
time. It is a new life philosophy that combines adventure, sports, experience, discovering,
events, and relations to nature, history, culture, habits or traditions. Active tourism is rapidly
growing in popularity due to unusual experience that is totally different from the typical in
sea resorts. Elements of active tourism (such as excursions or offer of sport activities) are
![Page 40: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/40.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 40 of 77 © SmartOpenData Consortium 2014
added to the traditional form of tourism. The new forms of tourism cover for example sport
activities (e.g. rafting), nature tourism (e.g. trekking or hiking), rural tourism, congress
tourism, adventure tourism (e.g. rock climbing) or experience tourism (e.g. mountaineering
expeditions). Data and information represents the keyword of current society as well as
contemporary tourism and tourist industry. Both main subjects of tourist industry
(participants and providers) deal with data and information and need them mainly for
communication in each group and also between both groups of tourism subjects. Data and
information mean a huge number of various items related to selection of destination or offer
of services of tourist industry. Data and information do not mean just spatial data sets,
maps, web cameras, handouts or catalogues, but also personal information such as
recommendations, comments on social media channels, published private photos or stories.
Existing solutions for tourist industry based on information technologies (IT) are focused
mainly on one component of information such as global information, local or regional data
or social media and crowd-sourcing
The Tourism defined next concrete use cases:
• Discovery relevant data sources in relation to user position – the goal is to build
catalogue of existing tourist related LOD, which will be possible to include into
analysis on the base of user preferences
• Provide federated spatial search and visualization of LOD – for example provide
search in buffer around planed road trough distributed local repositories and
visualize data in list and also inside of the map
The generic LOD functionalities required by Tourism are:
• Search
• Federated querying
• Visualization LOD with other data
• Visualization of LOD using conventional GI tools
![Page 41: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/41.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 41 of 77 © SmartOpenData Consortium 2014
6666 Information viewpoint
The Information Viewpoint describes the way that the SmartOpenData stores, collects,
updates, manipulates, manages, and distributes information. The major issues which are
analyzed and assessed are:
� Basic data types used in SmartOpenData
� Ontologies and vocabularies
� Registers and Registries
� Tasks related to SmartOpenData data
� Information structure and content with a clear focus on the metadata and data
models;
6.1 Local data
Local data is the data that is stored in End-user’s domain, in different formats. This data
must be converted a set of structured to be further processed by the tools present on the
client side and server data.
Within the local data types include:
6.1.1 GIS Files
A GIS file format is a standard of encoding geographical information into a file. They are
created mainly by government mapping agencies (such as the USGS or National Geospatial-
Intelligence Agency) or by GIS software developers.
Raster
A raster data type is, in essence, any type of digital image represented by reducible and
enlargeable grids. Anyone who is familiar with digital photography will recognize the Raster
graphics pixel as the smallest individual grid unit building block of an image, usually not
readily identified as an artifact shape until an image is produced on a very large scale.
Raster data is stored in various formats; from a standard file-based structure of TIF, JPEG,
etc. to binary large object (BLOB) data stored directly in a relational database management
system (RDBMS) similar to other vector-based feature classes. Database storage, when
properly indexed, typically allows for quicker retrieval of the raster data but can require
storage of millions of significantly sized records.
The most popular Raster file formats are:
Esri grid - proprietary binary and metadataless ASCII raster formats used by Esri
GeoTIFF - TIFF variant enriched with GIS relevant metadata
JPEG2000 - Open source raster format. A compressed format, allows both lossy and lossless
compression.
Vector
![Page 42: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/42.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 42 of 77 © SmartOpenData Consortium 2014
In a GIS, geographical features are often expressed as vectors, by considering those features
as geometrical shapes. Different geographical features are expressed by different types of
geometry: Points, Lines and Polygons.
Each of these geometries is linked to a row in a database that describes their attributes. For
example, a database that describes lakes may contain a lake's depth, water quality, pollution
level. This information can be used to make a map to describe a particular attribute of the
dataset. For example, lakes could be coloured depending on level of pollution.
The most popular Vector file formats are:
Geography Markup Language (GML) - XML based open standard (by OpenGIS) for GIS data
exchange
GeoJSON - a lightweight format based on JSON, used by many open source GIS packages
Keyhole Markup Language (KML) - XML based open standard (by OpenGIS) for GIS data
exchange
Shapefile - open, hybrid vector data format using SHP, SHX and DBF files (by ESRI)
6.1.2 General purpose files
Other formats that must be considered are the ones used to store general purpose
information. This information can be related to GIS or to other scenarios such as legislation,
tourism, finance, etc.
We divide this section between open formats and proprietary formats
6.1.2.1 Open Formats
The analysed open formats are: XML, JSON, YAML, and CSV
XML is primarily an extensible mark-up language. It can store general data structures as well.
Language support for IDs means that complex graphs can be created, although it's best used
for trees. A document can be tested for correctness against a specification in XML Schema.
The main problem with this format is its extreme verbosity.
JSON is primarily a way to store simple object trees. There is no support for general graphs.
JSON has no concept of type beyond primitives string, integer, float, boolean, null and the
collection types array and object.
YAML is an extension of JSON. Has a notion of aliases that allow object graphs of arbitrary
complexity to be created. Has a concept of metadata like tags that can be used for proper
typing.
CSV format stores tabular data (numbers and text) in plain-text form. Plain text means that
the file is a sequence of characters, with no data that has to be interpreted instead, as binary
numbers. A CSV file consists of any number of records, separated by line breaks of some
kind; each record consists of fields, separated by some other character or string, most
commonly a literal comma or tab. Usually, all records have an identical sequence of fields.
![Page 43: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/43.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 43 of 77 © SmartOpenData Consortium 2014
6.1.2.2 Proprietary formats
A proprietary format is a file format of a company, organization, or individual that contains
data that is ordered and stored according to a particular encoding-scheme, designed by the
company or organization to be secret, such that the decoding and interpretation of this
stored data is only easily accomplished with particular software or hardware that the
company itself has developed. The specification of the data encoding format is not released,
or underlies non-disclosure agreements.
The analysed proprietary formats are: PDF and MS-Office formats (DOC, XLS and PPT):
PDF – Adobe's Portable Document Format (open since 2008 - ISO 32000-1), but there are still
some technologies indispensable for the application of ISO 32000-1 that are defined only by
Adobe and remain proprietary
DOC – Microsoft Word Document. Microsoft released a .DOC format specification under the
Microsoft Open Specification Promise. However, this specification does not describe all of
the features used by DOC format and reverse engineered work remains necessary. Since
2008 the specification was changed several times, the last change was made in November
2013.
XLS – Microsoft Excel spreadsheet file format
PPT – Microsoft PowerPoint Presentation file format. In Microsoft Office 2007 the binary file
formats were replaced as the default format by the new XML based Office Open XML
formats, which are published as an open standard. Nevertheless, they are not complete as
there are binary blobs inside of the XML files, and several pieces of behavior are not
specified but refer to the observed behavior of specific versions of Microsoft product.
![Page 44: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/44.jpg)
6.2 Basic data types used in SmartOpenData
Data in SmartOpenData architecture are divided according to their origin and their usability. Basic types of data can be found in next table
Pilot Dataset(s) Format(s)
Ireland ETIS Dataset Excel / ESRI Shape
BFCP Operational Dataset CSV / ESRI Shape
National Monuments Service dataset CSV / ESRI Shape
ALL-ISLAND RESEARCH OBSERVATORY ESRI Shape
National biodiversity Data Centre ESRI Shape
Irish National Parks and Wildlife Services ESRI Shape
Spain SIOSE PostGIS
SIGPAC SQLite
REGA ESRI Shape
Silvadat Access
Admission units ESRI Shape
Nature DataBank (Species, soil characteristics, physical characteristics: humidity, temperature…) ESRI Shape
Czech NFI Results Various Format:XLS, pdf
Tabular Data Various Format
GIS Data INSPIRE Compliant
Near Infrared Ortophotos ECW
nDSM - The Normalised Digital Surface Model .tif
RPFD – Regional Plans of the Forest Development SQL Server Spatial / ERSI Shape
Forest and Other land classes .tif
Slovakia Protected sites GML
Sample dataset of habitats and biotopes GML
Sample dataset of species distribution GML
Environmental burdens in Slovakia WFS, REST API, SOAP API
![Page 45: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/45.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 45 of 77 © SmartOpenData Consortium 2014
External Sparql (GeoSparql) endpoints RDF
External OGC WxS services endpoints
Based on OGC WxS service type (e.g. GeoTIFF, PNG,
KML…)
GeoSpecies Knowledge Base Rdf, owl
Other available endpoints THREDDS Catalogs, Z39.50, ESRI GeoPortal REST interface
GeoNames XML JSON RDF CSV TXT RSS KML
PESI Pan-European Species directories Infrastructure SOAP/WSDL
Metadata and sample datasets from LTER CSW, SOS, RDF
Portugal CORINE Land Cover PostGIS
Ortophotos PostGIS
Kyoto Landuse PostGIS
Administrative Units CAOP PostGIS
Land Use Monitorin - LUM PostGIS
LUM_Place PostGIS
Watershed boundaries PostGIS
Digital Elevation Model PostGIS
Drainage Network PostGIS
Forest Fires PostGIS
Environmental Data PostGIS
Hydrological monitoring PostGIS
Water quality monitoring PostGIS
Italy Physic / Chemical parameters measures Excel / SQL (LIMS)
Plan4business CORINE Land Cover PostGIS
Spatial plans PostGIS
Urban Atlas PostGIS
Czech Cadaster PostGIS
RUIAN PostGIS
Nature 2000 PostGIS
![Page 46: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/46.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 46 of 77 © SmartOpenData Consortium 2014
Eurostat data PostGIS
Czech Statistic Office data PostGIS
German Statistical Office Data PostGIS
OSM PostGIS
Polish Statistical Office data PostGIS
Flood risk maps of Czech Republic PostGIS
Tourism OSM PostGIS
Table 1 Pilot Data source
![Page 47: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/47.jpg)
6.3 RDF Data integration
Data integration is one of the main problems in distributed data sources. The most used
approach is to provide an integrated mediated schema for various data sources.
There are two basic approaches to the data integration problem, called procedural and
declarative.
The procedural approach is used in the Local data subsystem. In this approach data are
integrated in an ad-hoc manner with respect to a set of predefined information needs. In
this case, the basic issue is to design suitable software convertors that access the sources in
order to fulfill the predefined information requirements.. They do not require an explicit
notion of integrated data schema, and rely on two kinds of software components: wrappers
that encapsulate sources, converting the underlying data objects to a common data model,
and mediators that obtain information from one or more wrappers or other mediators,
refine this information by integrating and resolving conflicts among the pieces of
information from the different sources, and provide the resulting information either to the
user or to other mediators. The basic idea is to have one mediator for every query pattern
required by the user, and generally there is no constraint on the consistency of the results of
different mediators.
The declarative approach is used in the server side top model the data at the local and
external sources by means of a suitable language, to construct a unified representation, to
refer to such a representation when querying the global information system, and to derive
the query answers by means of suitable mechanisms accessing the sources and/or the
materialized views. The declarative approach provides a crucial advantage over the
procedural one: although building a unified representation may be costly, it allows
maintaining a consistent global view of the information sources, which represents a reusable
component of the information integration systems.
The RDF data integration functionality can be implemented from a computational view by
using different technologies:
� RDF can be is used for integrated schema descriptions as well as providing a unified
view of data.
� Description Logic (DL)45
[ref] can be used to find any contradiction in the integrated
schema (satisfiability of concepts in DL terms). It has well-defined semantic and
decidable routines for basic services like satisfiability, which makes it suitable for
knowledge representation and reasoning in this domain.
� RDQL46
or SPARQL can be used for re-formulation of queries. It is a query language
for RDF in Jena47
and provides a data-oriented query model. Jena provides necessary
APIs to work on RDF data and execute queries.
45
Franz Baader, Werner Nutt, Basic Description Logics, Description Logic Handbook, pp. 47-100 46
RDQL - A Query Language for RDF: http://www.w3.org/Submission/2004/SUBM-RDQL-20040109/ 47
Apache Jena Homepage: https://jena.apache.org/
![Page 48: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/48.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 48 of 77 © SmartOpenData Consortium 2014
6.4 Ontologies and vocabularies
In addition to the references identified in the Deliverable D3.1 and due the complexity of
problem, project SmartOpenData has to recognized and defined set of vocabularies and
ontologies, which will be used for linkage of data. This ontologies and vocabularies have to
cover set of areas:
• Agriculture – Agriculture and Forestry Ontology (AFO), AGRIFOREST Thesaurus,
AGROVOC Multilingual agricultural thesaurus, Network of Fisheries Ontologies
• Nature or environment – AGRIFOREST Thesaurus, Agro forestry Database, AGROVOC
Multilingual agricultural thesaurus, GEMET, CSA-NBII Biocomplexity Thesaurus,
Environmental Dictionary (EnDic), International Standard Statistical Classification of
Aquatic Animals and Plants, TaxonMap Ontology, LTER-Europe EnvEurope
Thesaurus48
, Linked Science49
• Forestry – Agriculture and Forestry Ontology (AFO), AGRIFOREST Thesaurus, Agro
forestry Database, AGROVOC Multilingual agricultural thesaurus, Forestry Terms,
Global Forest Decimal Classification, Multilingual Glossary of Forest Genetic
Resources
• Water management – Environmental Dictionary (EnDic), International Standard
Statistical Classification of Aquatic Animals and Plants, Les Mots de l’ Eau, SEMIDE
thesaurus
• Planning – AGROVOC Multilingual agricultural thesaurus, GeoNames, Freebase,
Dbpedia, Land cover and land use Terminology for integrated resources planning and
management, The Statistical Core Vocabulary, The Places Ontology, Ordnance Survey
Topography Ontology, Ontologie démographique de l'INSEE
• Tourism – Ontología de Turismo para el Ayuntamiento de Zaragoza, CSA-NBII
Biocomplexity Thesaurus (for biotourism), Theatre Ontology, Wine Ontology, Whisky
Ontology
• Species - International Standard Statistical Classification of Aquatic Animals and
Plants, AGROVOC, A classification of the bird species of South America, Agroforestree
Database, Animal Diversity Web - Kingdom Animalia Classification, Catalogue of Life
Annual Check List, Encyclopedia of Life, Fishbase, Grassland Index, GRIN Taxonomy
for Plants, IUCN Red List of Threatened Species, Listing of Useful Plants of the World,
Species Fungorum
• Administrative division - FAO Geopolitical Ontology, Eurostat - Linked Data
6.5 Registers and Registries
Potential for easier access and exchange of digital spatial content and functionality is
significantly rising with making existing underlying models and ontologies available through
the standardised registers or registries50
. Register provides an environment for management
48
http://vocabs.lter-europe.net/EnvThes3.html 49
http://linkedscience.org/vocabularies/ 50
ISO 19135:2005 Geographic information – Procedures for item registration
![Page 49: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/49.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 49 of 77 © SmartOpenData Consortium 2014
of the items (containing at least persistent identifiers and their definition) often reused in
various applications and domains. Registries are representing information systems
maintaining one or more registers. Demand for availability of this type of registers is also
increasing in line with initiatives focused on standardization of spatial data and services
sharing with Registry services support (e.g. INSPIRE51
, UKGovLD Registry52
), ensuring high
level of interoperability53
.
SmartOpenData architecture will therefore reuse relevant registers and registry services in
order to provide the evidence about the feasibility and importance of these interoperability
components.
For geospatial data description and representation can be used several vocabularies (see
more in D3.1 Review of geographic resources metadata and related metadata standards):
• GeoSPARQL - GeoSPARQL is a standard for representation and querying of geospatial
linked data for the Semantic Web from the Open Geospatial Consortium. It attempts
to solve the problems with the heterogeneous and incompatible implementations for
representing and querying spatial data. It achieves this by defining an ontology that
follows the existing standards from the OGC with regard to spatial indexing in
relational databases. The GeoSPARQL specification consists of three components –
the definition of vocabulary to represent features, geometries and the relationships
between them; a set of spatial functions for use in SPARQL queries; and a set of
query transformation rules. ( )
• NeoGEO - The NeoGeo Vocabulary project make efforts to develop a common
vocabulary for the representation of geodata. The NeoGeo Vocabulary is based on
the GML Simple Features Profile54. Simple geometries are described explicitly in RDF.
By the aggregation of simple geometries arise more complex geometries. It allows
reasoning and querying on these geometries.
• W3C Basic Geo - The W3C Basic Geo Vocabulary is a RDF vocabulary for representing
latitude/longitude position of the data geographical location, using WGS84 as a
reference datum. It is used within RDF documents, as well as a namespace within
non-RDF XML documents, for instance RSS 2.0 or Atom. There are many publishers,
applications and services using the format, such as DBpedia.
• Location Core Vocabulary - The ISA Programme Location Core Vocabulary is a
simplified, reusable and extensible data model that offers a minimum set of classes
and properties for describing any place by its name, address or geometry. The
vocabulary is primarily designed to aid the publication of data that is interoperable
with the EU INSPIRE Directive. The vocabulary is integrated with the Business and
Person Core Vocabularies of the EU ISA Programme.
51
http://inspire.ec.europa.eu/registry/ 52
https://github.com/UKGovLD/ukl-registry-poc/wiki 53
http://www.w3.org/2014/03/lgd/papers/lgd14_submission_60
![Page 50: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/50.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 50 of 77 © SmartOpenData Consortium 2014
6.6 Information structure and content with a clear focus on the metadata and data models;
This part is task of future deliverables D3.2 Initial SmartOpenData data model and D3.3
Harmonisation of data to SmartOpenData model, where relevant ongoing projects and
initiatives will be taken into the consideration (e.g. Linking Geospatial Data Workshop
outcomes, or ARE3NA RDF and PIDs for Location framework
55)
6.7 Tasks related to SmartOpenData data
The tasks related to SmartOpendata were identified in previous chapter and it include;
• Transformation (GML -> RDF, relational data -> RDF, GMD -> RDF)
• Publishing data from existing SQL databases as RDF
• Storage
• Search
• Federated querying
• Visualization LOD
• Visualization of LOD using conventional GI tools
As additional task, related to SmartOpenData was the publishing data on the Web as they
are.
6.8 Data flows
Next graph demonstrate SmartOpenData data flow
Figure 7 SmartOpenData data flow
55 https://joinup.ec.europa.eu/community/are3na/event/rdf-and-pids-location-preliminary-results
![Page 51: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/51.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 51 of 77 © SmartOpenData Consortium 2014
7777 Computational viewpoint
The computational viewpoint is functional decomposition of the system into basic objects
that interact at interfaces. It describes the functionality provided by the system and its
functional decomposition. This viewpoint focuses on the components of the system, not
considering distribution aspects, which are managed within the Engineering and Technology
viewpoints.
The computational viewpoint must conform to the policies of the enterprise viewpoint.
Some roles, activities and behaviors identified in the enterprise viewpoint will be
computational objects, and are describe in this section. Some of these may have definitions
visible in the information viewpoint.
The basic components recognized in previous chapters are:
7.1 Local data
� Data in proprietary formats (XSL, shapefile…)
� Data in open format (csv, gml)
� Unstructured data (plain text, html pages, pdf, social networks
content) - Scraping
� Structured data (xml, geojson, georss)
� Metadata (xml, txt, RDF (DCAT, VoID?))
� Proprietary formats such as Office (doc, xls), OpenOffice etc
7.2 Server side
o Publishing data on the Web as they are.
� Generic convertor for translate local data in database Functional
requirements:
� Mapping from input to target schema/model
� ETL Transformation functionality
� Extraction of non structured data
� Support of existing registries
� Support for local and external meta&data
� Metadata editor
o Relational storage
� Relational database repository (if needed) for classic GIS / text
applications
� Structured data (xml, geojson, georss, sparql, geosparql)
� Harmonised metadata (SDI & LoD compliant)
![Page 52: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/52.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 52 of 77 © SmartOpenData Consortium 2014
o Transformation (GML -> RDF, relational data -> RDF, metadata (GMD -> RDF))
o Conversion to RDF (incl.support for SMoD Data model)
� RDFise & Linking
� Persistent URIs & Standard Vocabularies - INSPIRE Registry or MDR
� Some external data may be incorporated into process
� Creating links to other sources
� Functional requirements:
• Mapping from input to target schema/ontology
• Transformation functionality (data/metadata)
• Linkage with local and external meta/data
� Non-Functional requirements:
• Support for persistent identification
• Support of existing registries, ontologies
• Support for new ontologies development and publishing
o Publishing data from existing SQL databases as RDF
� Be able access SQL data as RDF
o RDF Storage
o Triple store repository with structured linked open metadata/(geo)data (xml,
geojson, georss, sparql, geosparql). RDF file to be directly used in next step
Triples can be serialized as RDF/XML, JSON-LD,N-Triples, Notation3, Turtle
� Support for features
� Support for coverages, rasters
� Harmonized metadata (SDI & LoD compliant)
� Cashed Triple store repository
� SPARQL endpoint
� GeoSPARQL endpoint
o Distributed semantic indexing infrastructure
o Administration and notification framework
7.3 Client side
o Supports read and write mode for repositories and (where possible) for
external data and metadata
o Support for Semantic Front-end Facilities
o Distributed Semantic Indexing infrastructure
o Visualization Framework
![Page 53: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/53.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 53 of 77 © SmartOpenData Consortium 2014
o Administration and Notification Service
o Allows creation of new links (triples)
o Metadata harvesting
o Process outputs of the processor
o Support for Semantic Front-end Facilities
o Visualization Framework
o Table Tree view
o Analytics UI
o GeoSpargl/Sparql Workbench
o Client displays the results
o GeoJSON / kml for geographic data
o HTML pages
o Linkage with reference/most used open source CMSs
7.4 Non-functional requirements
� Support for persistent identification
� Support of existing registries, ontologies
� Support for new ontologies development and publishing
![Page 54: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/54.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 54 of 77 © SmartOpenData Consortium 2014
8888 Engineering viewpoint
The engineering viewpoint focuses on the mechanisms and functions required to support
distributed interactions among objects in the system. It describes the distribution of
processing performed by the system to manage the information and provide the
functionalities. This section defines the SmartOpenData conceptual Architecture.
As we mentioned in introduction, that focus is not to define complex platform, we defined
basics relation of components.
8.1 Generic architecture
Short narrative description of element and groups of elements depicted in schema bellow
Figure 8 Generic architecture
![Page 55: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/55.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 55 of 77 © SmartOpenData Consortium 2014
8.2 Server side
The server side offers two functionalities: The Storage or relational data and SPARQL
EndPoint.
8.2.1 Relation database
Relational database will store spatial and non-spatial structured and non-structured data. It
will guarantee access using conventional SDI tools.
8.2.2 Data Integration
It involves practices, architectural techniques and tools for achieving consistent access to
and delivery of data across a wide range of subject areas and structure types in an
enterprise. Data integration capabilities are at the heart of the information-centric
infrastructure and will power the frictionless sharing of data across all organizational and
system boundaries.
Related to data integration, server-side processors provide ETL tools. This ETL tools can be
classified info four categories:
• Pure ETL tools: These tools are independent of the database and the Business
Intelligence tool with which it will be used. The companies do not rely on any other
product for the functionalities offered by them and they also allow migration to
different database without changing the integration process.
• Data base integrated: These tools are supplied as an option integrated into a
database software and some of the functionality is built into the database, not
available separately in the ETLtool itself.
• Business Intelligence Integrated: These are the tools from the same supplier as the BI
software. In many cases these are separate products and the supplier will claim that
they can be used independently of the BI tool.
• Niche Product: These are the tools that don’t fit well into any of the above
mentioned groups, but still have considerable ETL functionality in them.
Also, an extension of ETL tools can be used to manage spatial data. Spatial ETL tools provide
the data processing functionality of traditional Extract, Transform, Load (ETL) software, but
with a primary focus on the ability to manage spatial data (which may also be called
geographic, map or location data).
A Spatial ETL system may translate data directly from one format to another, or via an
intermediate format; the latter being more common when transformation of the data is to
be carried out.
Many existing GIS applications are now incorporating Spatial ETL tools within their products;
the ArcGIS Data Interoperability Extension being a good example of this.
![Page 56: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/56.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 56 of 77 © SmartOpenData Consortium 2014
8.2.3 Structured and non-structured data extraction
This functionality refers to the problem of automatically extracting the database values from
the web pages without any learning examples or other similar human input.
Data extraction tools often combine the notion of a template (a model that describes how
values are encoded into pages) and extraction algorithms (that uses sets of words that have
similar occurrence pattern in the input pages, to construct the template). The constructed
template is then used to extract values from the pages.
Most of the related work uses a “wrapper-based” system for extracting data. In a wrapper
based system, extraction is a two step process. In the first step, a wrapper for the given set
of pages is generated. In the second step, the wrapper is used to extract the data from the
web pages. A wrapper is just a program that extracts the data from the set of pages. Note
that a wrapper is specific to the set of pages — the wrapper for the pages of one web site
will be different from the wrapper for the pages of a second web site.
8.2.3.1 Schema matching and mapping
The terms schema matching and mapping are often used interchangeably. For this article,
we differentiate the two as follows: Schema matching is the process of identifying that two
objects are semantically related (scope of this article) while mapping refers to the
transformations between the objects.
Automating these two approaches has been one of the fundamental tasks of data
integration. In general it is not possible to determine fully automatically the different
correspondences between two schemas, primarily because of the differing and often not
explicated or documented semantics of the two schemas.
8.2.3.2 Metadata integration and edition
One of the main elements for the success in the development of SDI or any other type of
information infrastructure is the appropriate annotation of resources to be accessed and
distributed by means of metadata. Metadata constitute the mechanism to characterize data
and services (e.g., descriptions of the content, quality, condition, authorship and any other
features) in order to enable other users and applications to make use of such data and
services.
However, due to the heterogeneity of contents in information infrastructures, it is not
possible to consider a unique metadata model or schema.
The diversity of metadata standards has been a critical issue for the development of SDIs.
During the last fifteen years, standardization bodies have proposed different metadata
standards such as the Content Standard for Digital Geospatial Metadata (CSDGM) [2] or ISO
19115 Geographic Information – Metadata [3]. Additionally, apart from the standards, it is
also common to find application profiles and extensions of these standards.
There are a variety of free and commercial software tools available to support metadata
development. These tools offer a range of features and capabilities:
![Page 57: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/57.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 57 of 77 © SmartOpenData Consortium 2014
8.2.4 Converting data to RDF
This function converts application data from an application-specific format into RDF for use
with RDF tools and integration with other data. Converters may be part of a one-time
migration effort, or part of a running system which provides a semantic web view of a given
application.
The converting function is usually done by scrapers. Scraping is a computer software
technique of extracting information from unstructured data. It is a field with active
developments sharing a common goal with the semantic web vision, an ambitious initiative
that still requires breakthroughs in text processing, semantic understanding, artificial
intelligence and human-computer interactions. Scraping, instead, favors practical solutions
based on existing technologies that are often entirely ad hoc.
For example, OpenRefine56
is a convertor that permits loading data, cleaning it up,
reconciling it to master database, and augmenting it with data coming from other RDF or
Web sources.
The convertor modules are located in Figure XX between the Data subsystems and the
server subsystems, as can be used from these two sides.
8.2.5 SPARQL EndPoint
A SPARQL endpoint is a conformant SPARQL protocol service as defined in the SPROT
specification. A SPARQL endpoint enables users (human or other) to query a knowledge base
via the SPARQL language. Results are typically returned in one or more machine-processable
formats. Therefore, a SPARQL endpoint is mostly conceived as a machine-friendly interface
towards a knowledge base. Both the formulation of the queries and the human-readable
presentation of the results should typically be implemented by the calling software, and not
be done manually by human users.
8.2.5.1 RDF Storage
An RDF store allows storage of RDF data and schema information, and provides methods to
access that information. Thus, the two primary components of an RDF store are a repository
and a middleware that builds on top of that repository. The middleware can be further
divided into components as the access methods can be categorized into methods for adding,
deleting, querying and exporting data.
Different repositories are imaginable, e.g. main memory, files or databases, but the access
methods should remain the same. Thus, it is reasonable to encapsulate the access to the
repository in an own layer, which provides well defined interfaces to the upper layers and
can be exchanged if another repository is used. The inference support also resides in this
layer as close to the repository as possible. Sesame57
implements such a layer and calls it the
Storage and Inference Layer (SAIL)
56
OpenRefine Webpage: https://github.com/OpenRefine/OpenRefine
57
Sesame Webpage: http://www.openrdf.org/
![Page 58: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/58.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 58 of 77 © SmartOpenData Consortium 2014
For persistent storage the data can be serialized to files, but for large amounts of data the
use of a database management system is more reasonable. Examining currently existing RDF
stores we found that they are using relational and object-relational database management
systems (RDBMS and ORDBMS).
8.2.6 Support for standard vocabularies
In order to expose INSPIRE data and metadata as geospatial Linked Data server-side processors must
provide providing automatic and semi-automatic tools to repurpose/reuse geospatial information
from INSPIRE SDIs which consists of:
� Exposing catalogue services through SPARQL endpoints
� On-the-fly and custom transformations of INSPIRE metadata as VoiD (vocabulary of
Interlinked Documents) with support for standard vocabularies (e.g. GEMET)
� On-the-fly and custom transformations of geospatial data sets as geospatial RDF, based on
standard (e.g. INSPIRE Data Specifications), or custom data schemas.
![Page 59: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/59.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 59 of 77 © SmartOpenData Consortium 2014
9999 Technology viewpoint
The Technology Viewpoint describes the technological specifications for the physical
deployment of the system implementation. In particular, it focuses on:
• the choice of technology in the system;
• how specifications are implemented;
• specification of relevant technologies;
• Support for testing.
The Technology Viewpoint will be analyzed deeply in WP5. The current version provides
indication of foreseen implementation for main components of the architecture. This list is
not complete and will be updated during the second phase of design.
9.1 Tools for technical implementations
Low level tools or Libraries oriented to working with DF data. Data serialization formats and
processing available in a number of popular programming environments (source from D3.1).
C# JavaScript Java PHP Python Ruby
RDF/XML dotNetRDF
http://ww
w.dotnetr
df.org/,
SemWebht
tp://razor.
occams.inf
o/code/se
mweb/
rdflib.js
https://githu
b.com/linke
ddata/rdflib.
js
Apache Jena
https://jena.
apache.org/
documentati
on/rdf/
EasyRDF
http://www
.easyrdf.org
/
RDFLib
https://githu
b.com/RDFLi
b/rdflib
Rdf-rdfxml*
http://ruby-
rdf.github.io
/rdf-rdfxml/
N-Triples - Rdflib.js Apache Jena RDFLib rdf-turtle*
https://githu
b.com/ruby-
rdf/rdf-
turtle
TriG - - Apache Jena RDFLib -
RDFa - - Apache Jena RDFLib RDF-rdfa*
http://ruby-
rdf.github.io
/rdf-rdfa/
Notation3 SemWeb Rdflib.js Apache Jena RDFLib Rdf-n3*
http://ruby-
![Page 60: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/60.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 60 of 77 © SmartOpenData Consortium 2014
rdf.github.io
/
Turtle - Rdflib.js Apache Jena EasyRDF
RDFLib Rdf-turtle
JSON/JSON-LD json-ld.net
https://git
hub.com/
NuGet/jso
n-ld.net
https://githu
b.com/digita
lbazaar/jsonl
d.js
Apache Jena,
JSONLD-
JAVA
https://githu
b.com/jsonld
-java/jsonld-
java
EasyRDF
php-
json-ld
https://gith
ub.com/digi
talbazaar/p
hp-json-ld
and JsonLD
https://gith
ub.com/lant
haler/JsonL
D
PyLD
https://githu
b.com/digita
lbazaar/pyld
, Fiona
https://pypi.
python.org/
pypi/Fiona
able to add
JSON-LD
context to
GeoJSON
data
JSON-LD
reader/write
r*
https://githu
b.com/ruby-
rdf/json-ld/
rdf/JSON - - Apache Jena EasyRDF
RDFLib -
Microdata - - - - RDFLib rdf-
microdata*
https://githu
b.com/ruby-
rdf/rdf-
microdata
*project is a part of Ruby RDF/Linked Data for Ruby
Table 2 Available components for SmartOpenData
9.2 Spatial data serialization tools
Tools able to serialize data form commonly used GIS formats (e.g. ESRI ShapeFile,
PostgerSQL PostGIS RDBMS, and other)
9.2.1 GeoKnow TripleGeo
One example is Comandline (CLI) application for geospatial data transformation to triples.
The current version of TripleGeo utility can access geometries from:
• ESRI shapefiles, a widely used file-based format for storing geospatial features.
• Geographical data stored in GML (Geography Markup Language) and KML (Keyhole
Markup Language).
• INSPIRE-aligned datasets for seven Data Themes (Annex I) in GML format: Addresses,
Administrative Units, Cadastral Parcels, GeographicalNames, Hydrography, Protected
Sites, and Transport Networks (Roads).
![Page 61: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/61.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 61 of 77 © SmartOpenData Consortium 2014
• Spatially-enabled DBMSs: Oracle Spatial, PostGIS, MySQL, and IBM DB2 with Spatial
extender.
Output formats: RDF/XML (default), RDF/XML-ABBREV, N-TRIPLES, N3, and TURTLE (TTL)
Concerning geospatial representations, triples can be exported according to:
- the GeoSPARQL standard for several geometric types (including points, linestrings,
and polygons)
- the WGS84 RDF Geoposition vocabulary for point features
- the Virtuoso RDF vocabulary for point features.
- Resulting triples are written into a local file, so that they can be readily imported into
a triple store.
To run TripleGeo as WEB service for data transformation is available also WEB application
TripleGeo-Service.
9.3 Non-spatial data serialization tools
The complete list of available tools for RDBMS data transformation to RDF you can visit
http://www.w3.org/TR/rdb2rdf-implementations/-
9.3.1 D2RQ
The D2RQ Platform is a system for accessing relational databases as virtual, read-only RDF
graphs. It offers RDF-based access to the content of relational databases without having to
replicate it into an RDF store. Using D2RQ you can:
o query a non-RDF database using SPARQL
o access the content of the database as Linked Data over the Web
o create custom dumps of the database in RDF formats for loading into an RDF store
o access information in a non-RDF database using the Apache Jena API
9.3.2 db2triples
As an example, it could be mentioned Antidot as implementations of R2RML and Direct
Mapping specifications.
9.3.3 TripleStores and SPARQL/GeoSPAQL endpoints
There are (almost) no complete implementations of GeoSPARQL. There are few partial or
vendor implementations of GeoSPARQL. Currently there are the following implementations:
9.3.4 Parliament
Parliament has an almost complete implementation of GeoSPARQL by using JENA and a
modified ARQ query processor.
![Page 62: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/62.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 62 of 77 © SmartOpenData Consortium 2014
9.3.5 Strabon
Strabon is a semantic spatiotemporal RDF store. You can use it to store linked geospatial
data that changes over time and pose queries using two popular extensions of SPARQL.
Strabon supports spatial datatypes enabling the serialization of geometric objects in OGC
standards WKT and GML. It also offers spatial and temporal selections, spatial and temporal
joins, a rich set of spatial
functions similar to those offered by geospatial relational database systems and support for
multiple Coordinate Reference Systems. Strabon can be used to model temporal domains
and concepts such as events, facts that change over time etc. through its support for valid
time of triples, and a rich set of temporal functions. Strabon is built by extending the well-
known RDF store Sesame and extends Sesame’s components to manage thematic, spatial
and temporal data that is stored in the backend RDBMS.
Strabon also supports the querying of static geospatial data expressed in RDF using a subset
of the recent OGC standard GeoSPARQL which consists of the core, geometry extension and
geometry topology extension. The implementation of the other components of GeoSPARQL
is underway.
9.3.6 OpenSahara uSeekM IndexingSail Sesame Sail plugin
uSeekM IndexingSail uses a PostGIS installation in a backend to deliver GeoSPARQL. They
deliver an almost complete implementation of GeoSPARQL along with some of its own
vendor prefixes.
9.3.7 Openlink Virtuoso Universal Server
Since version 7.1 OpenLink Virtuoso also contains some geospatial functions and reasoning
based on vendor prefixes, although not compatible with GeoSPARQL it is usable for
geospatial.
9.3.8 Ontotext OWLIM
OWLIM has a partial geospatial implementation based on vendor prefixes, also not
compatible with GeoSPARQL, but is sufficiënt for basic usage. Ontotext states that OWLIM
will support GeoSPARQL in the near feature with version 5.7 (currently 5.4). But at the time
of writing it seems that they are currently two versions behind schedule.
9.3.9 SPARQ ED
SPARQL Editoris as an open source project. SparQLed also is one of the components of the
commercial Sindice Suite for helping large enterprises build private linked data clouds. It is
designed to give users all the help they need to write SPARQL queries to extract information
from interconnected datasets.
With SQL, the advantage lies in having a schema which users can look at and understand
how to write a query. RDF, on the other hand, has the advantage of providing great power
and freedom, because information in RDF can be interconnected freely. The comprehensive
SparQLed environment provides fully assisted SPARQL query editing that includes full
![Page 63: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/63.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 63 of 77 © SmartOpenData Consortium 2014
syntactic assistance with syntax highlighting, auto completion and data-driven assistance.
Analytics technology is behind the suggestions it provides on writing queries.
9.4.10 SIRENDB
SIREn is a schemaless structured document search system that combines free text search
with structured search over arbitrary json data. The system is a extension of Solr, the world’s
leading search engine technology. Imagine. SirenDB is SindiceTech Solr plugin for rich
structured data and arguably the most advanced structured data search engine available.
9.3.11 Sefarad-Faceted Search
Sefarad is a web application whose purpose is providing a semantic front end to Linked Open
Data (LOD) datasets. Sefarad allows to configure a dashboard to visualize different
perspectives of such datasets. Two predefined screens have been defined: (i) search, where
semantic faceted search can be carried out and the results are shown in the widgets and (ii)
control panel, where statistics such as Key Performance Indicator (KPI) about the dataset are
visualized.
9.4 High-level technical specification – generic level
High-level technical specification extended with concrete common tools to be used in all
pilots. This specification serves as underlying framework indicating common and specific
tools used across the pilots.
![Page 64: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/64.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 64 of 77 © SmartOpenData Consortium 2014
Figure 9 High-level technical specification – generic level
The set of evaluable components for every layer is on next image
![Page 65: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/65.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 65 of 77 © SmartOpenData Consortium 2014
Figure 10 Component diagram of SmartOpenData
9.5 Examples for architecture implementation of the pilots
On the base of generic models, pilot specifications are prepared. The work on this concrete
pilot specification will continue during WP5. Currently are ready specification for Czech,
Slovak, Ireland, Spain pilot and tourist pilot
![Page 66: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/66.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 66 of 77 © SmartOpenData Consortium 2014
9.5.1 Czech pilot
Figure 11 Czech Pilot Architecture
9.5.2 Slovakian pilot
![Page 67: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/67.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 67 of 77 © SmartOpenData Consortium 2014
Figure 12 Slovaks pilot architecture
9.5.2 Irish pilot
Irish pilot will be modification of generic scheme. The Irish Pilot will require from the
SmartOpenData platform (as described in D2.2, in alphabetical order) the following:
1. Scalable crowdsourced/VGI real-time data collection with an Open API.
2. Scalable Excel/CSV to RDF transformation tool(s), preferably as a CKAN plugin, in line
with W3C “CSV on the web” WG (See D2.1) 3. Scalable general GI to LOD
transformation, harmonisation and semantic indexing infrastructure service, with
persistent URIs, preferably using the INSPIRE Registry (see D2.1).
3. Scalable INSPIRE GI schema to LOD transformation and harmonisation service, with
persistent URIs, in particular INSPIRE Annex I theme “Protected Sites” (similar to
GeoKnow D2.7.1).
4. Scalable RDF Triple Storage service for the LOD (such as Virtuoso , see D2.1)
5. Visualisation framework (of GI and non-GI components)
![Page 68: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/68.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 68 of 77 © SmartOpenData Consortium 2014
Figure 13 Irish pilot
9.5.3 Spanish pilot
o Agroforestry Management
Figure 14 Spanish pilot: Agroforestry Management
![Page 69: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/69.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 69 of 77 © SmartOpenData Consortium 2014
o Water and Drinking water Management
Figure 15 Portuguese-Spanish pilot: Water Management
9.5.4 Italian pilot
Figure 16 Italian pilot
![Page 70: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/70.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 70 of 77 © SmartOpenData Consortium 2014
9.5.5 Tourist cross border pilot
Figure 17 Tourist Linked Open Data
9.6 Relation with semantic indexing
This part is developed in WP4 and will offer search trough all SmartOpenData pilots. It will
include.
• Distributed Semantic Indexing is composed by:
– ETL/Indexing Pipeline
– Entity Extraction Pipeline
– Semantic Server
– Siren DB
• Distributed Data Access is composed y:
– SPARQL-ED
– Sefarad-Faceted Search
• Administration and Notification is composed by:
– Notification
– Administration
The basic schemes and linkage with pilots implementation is on next scheme
![Page 71: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/71.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 71 of 77 © SmartOpenData Consortium 2014
Figure 17 WP4 implementation and linkage with pilots
![Page 72: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/72.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 72 of 77 © SmartOpenData Consortium 2014
10101010 Conclusions and Recommendations
This deliverable defines a reference infrastructure model and high-level technical
specification for SmartOpenData, including its main components and connection points to
other tools and systems. The RM-ODP (Reference Model for Open Distributed Processes)
methodology was used to define the SmartOpendData reference architecture that meets the
technical and user requirements established throughout T2.1 and T2.2. These address
interoperability and multilingualism aspects, metrics engine and interfaces. The reference
architecture defines both, platform neutral components and also provides suggestions for
concrete implementation. The aim was not to design a monolithic solution for all Link Open
Data, but to define basic architecture components of the Link Open Data chain and potential
solutions for solving the concrete problems of the 5 pilots in WP5.
10.1 Linkage with main technical components of SmartOpenData
Additional requirements came from analysis of cross links between the individual pilots and
also from project partners, SMEs and potential users of Linked Open Data.
The RM-ODP divides all processes of architecture design into five generic and
complementary “viewpoints” (Enterprise, Information, Computational, Engineering and
Technical) of the system and its environment. The conclusions of each viewpoint for
SmartOpenData were as follows:
1. Enterprise viewpoint - is focused on the analysis of pilot scenarios and the definition of a
limited numbers of generic use cases, which are implemented to support basis
functionalities required by more scenarios, but also supporting the process of data and
metadata harmonisation based on outputs from WP3. This Viewpoint concluded that the
SmartOpenData LOD functionalities required by the Pilots and cross functional themes
are as follows:
Pilots Cross functional Required generic LOD
functionalities ES IE IT CZ SK Business Tourism
Transformation (Relational -> RDF) X X X X X
Transformation (GML -> RDF) X
Transformation (GMD -> RDF) X
Storage X X X
Search X X X X X
Federated querying X X X X
Visualization of LOD with other data X X X X X
Visualization of LOD using
conventional GI tools X X X X X
Upgrading X
Publishing data from existing SQL
databases as RDF X X X
Publishing data from existing CSV
databases as RDF X
Table 3 SmartOpenData LOD functionalities
![Page 73: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/73.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 73 of 77 © SmartOpenData Consortium 2014
2. The Information viewpoint describes the way that SmartOpenData stores, collects,
updates, manipulates, manages, and distributes information. The major issues which
were analysed and assessed are:
� Basic data types used in SmartOpenData
� Ontologies and vocabularies
� Registers and Registries
� Tasks related to SmartOpenData data
� Information structure and content with a clear focus on the metadata and
data models.
Alignment of INSPIRE metadata with the DCAT-AP is under preparation by the Joint
Research Centre of the European Commission, in the framework of Action 1.17 of the EU
ISA Programme. The profile uses the INSPIRE registry58
together with DCAT defined
classes for the mapping. This profile is very important because it mediates the bridge
between the INSPIRE and other European portals. It is intended to implement this profile
and test its usability and stability in the scope of SmartOpenData project.
3. The Computational viewpoint is focused on generic components, which could be reused
for more scenarios and which will be some basic parts of the infrastructure. Various basic
components were identified in various areas of the SmartOpenData system, including:
• Local data
• Server side
o Publishing data on the Web as they are.
o Relational storage
o Transformation (GML -> RDF, relational data -> RDF, metadata (GMD -> RDF)))
o Conversion to RDF (incl.support for SMoD Data model)
o Publishing data from existing SQL databases as RDF
o RDF Storage
• Client side
4. The Engineering viewpoint focused on the mechanisms and functions required to
support distributed interactions among objects in the system. It defines the
SmartOpenData conceptual Architecture to address the distribution of processing
performed by the system to manage the information and provide the functionalities.
5. The TechnologyTechnical viewpoint describes the technological specifications for the
physical deployment of the system implementation, including:
• the choice of technology in the system;
• how specifications are implemented;
• specification of relevant technologies;
• support for testing.
Many potential tools and solutions to address the requirements of the SmartOpenData
infrastrucutres were identified for reuse from projects such as HABITATS, Plan4Business,
GeoKnow, LOD2 and SemGrow, along with use of the DCAT-AP and CKAN metadata profiles.
The HABITATS RL and Plan4Business solutions are from finished projects and represent a
58 http://inspire.ec.europa.eu/registry
![Page 74: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/74.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 74 of 77 © SmartOpenData Consortium 2014
traditional approach to GI information, but will be integrated with reuse of the LOD tools
from the other projects to provide implementation of the SmartOpenData system.
The Technology Viewpoint will be analyzed in more depth in WP3 and WP4. The current
version only gives initial ideas for implementation of some components of the architecture.
This list is not complete and will be updated during the second phase of design.
![Page 75: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/75.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 75 of 77 © SmartOpenData Consortium 2014
Annex A:
AJAX - Asynchronous JavaScript and XML
API - Application Programme Interface
CC - Creative Commons
CMS - Content Management System
Copernicus - the European Earth Observation Programme, used to be known as GMES
CRS - Coordinate Reference System
CSS - Cascading Style Sheets
CSW - Catalogue Service for the Web
DBMS - DataBase Management System
DCAT-AP - Data Catalogue vocabulary Application Profile
DOM - Document Object Model
DOW - SmartOpenData Description of Work, Annex I to the Grant Agreement.
EC – European Commission
ECMS - Enterprise Content Management System
EU – European Union
FI - Future Internet
FLOSS - Free/Libre and Open Source Software
GA - SmartOpenData Grant Agreement.
GeoJSON - Geographic JavaScript Object Notation
GEOSS - Global Earth Observation System of Systems
GI - Geospatial/Geographic Information
GIS - Geographic/Geospatial Information Systems
GLOD - Geospatial Linked Open Data.
GMES - Global Monitoring for Environment and Security – now known as Copernicus
GML – Geography Markup Language
GPS - Global Positioning System
HTML - Hypertext Markup Language
IDE - Integrated Development Environment
INSPIRE – INfrastructure for SPatial InfoRmation in Europe
IOT - Internet of Things
IPR - Intellectual Property Rights
![Page 76: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/76.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 76 of 77 © SmartOpenData Consortium 2014
ISO – International Organisation for Standardisation
ISO 19115 – ISO 19115:2003-Geographic Information Metadata
ISO 19118 – ISO 19118 Geographic Information-Encoding
ISO 19139 – ISO/TS 19139-Geographic Information-Metadata -XML schema implementation
JSON - JavaScript Object Notation
KML – Keyhole Markup Language
LBS - Location-based Services
LOD - Linked Open Data
LOGD – Linked Open Government Data
LR - Language Resources
MDA - Model Driven Architecture
MDR - Metadata Registry of the Publications Office of the EU.
MT - Machine Translation
MVC - Model View Controller
MVP - Model View Presenter
NGO - Non-Governmental Organisation
NLP – Natural Language Processing
ODC - Open Data Commons
OGC - Open Geospatial Consortium
OSM - OpenStreetMap
OWL - Web Ontology Language
PM - Person Month
PPP - Public-Private-Partnership
QoS - Quality of Service
RDBMS - Relational DataBase Management System
RDF - Resource Description Framework
RDFS - Resource Description Framework Schema
REST - Representational State Transfer
RL - Reference Laboratory
RM-ODP - Reference Model for Open Distributed Processes
ROI - Return on Investment
RSS - Rich Site Summary (originally RDF Site Summary)
SaaS - Software as a Service
SDI – Spatial Data Infrastructure
![Page 77: Architecture of SmartOpenData infrastructuresmartopendata.eu/sites/default/files/SmartOpenData D2.3...supporting better usability of INSPIRE based services by people. Solution was](https://reader034.fdocuments.in/reader034/viewer/2022050305/5f6dbdb97658447ead4304c9/html5/thumbnails/77.jpg)
D2.3 Architecture of SmartOpenData infrastructure SmartOpenData project (Grant no.: 603824)
Version 2.0 Page 77 of 77 © SmartOpenData Consortium 2014
SEIS – Shared Environmental Information System
SGML - Standard Generalized Markup Language
SKOS - W3C Simple Knowledge Organization System
SLA – Service Level Agreement
SME - Small to Medium Enterprise59
SmOD - SmartOpenData
SMT - Statistical MT
SOA – Service Oriented Architecture
SOAP - Simple Object Access Protocol
SPARQL - SPARQL Protocol and RDF Query Language
SQL - Structured Query Language
SQL/MM - SQL Multimedia and Application Packages (as defined by ISO 13249
SRID - Spatial Reference system IDentifier
SRS - Spatial Reference System
SSRI - Social Spaces for Research and Innovation
SVG - Scalable Vector Graphics
UI - User Interface
UML – Unified Modelling Language
URI – Uniform Resource Identifier
URL - Uniform Resource Locator
URM – Uniform Resource Management
W3C - World Wide Web Consortium
WCS – Web Coverage Map
WFS – Web Feature Map
WMC – Web Map Context
WMS – Web Service Map
WPS – Web Processing Services
WWW - World Wide Web
XHTML - eXtensible HyperText Markup Language
XML - eXtensible Markup Language
59
Defined by the European Commission at http://ec.europa.eu/enterprise/policies/sme/facts-figures-
analysis/sme-definition/