1 EcoInformatics meeting, 17/01/06 Ispra INSPIRE - Infrastructure for Spatial Information in Europe...

1EcoInformatics meeting, 17/01/06 Ispra

INSPIREINSPIRE - - Infrastructure for Spatial Information in EuropeInfrastructure for Spatial Information in Europe

Examples of research in support of SDIExamples of research in support of SDI

Paul Smits, Alessandro Annoni, Lars Bernard, Anders Friis-Christensen

European CommissionJoint Research Centre

Institute for Environment and Sustainability


OutlineOutline

• Introduction

• Infrastructure for Spatial Information in Europe

• Example of institutional research

• ORCHESTRA Experiments


IntroductionIntroduction

European Commission

DG Joint Research Centre

Institute for Environment and Sustainability

Spatial Data Infrastructure Unit

INSPIRE

JRC SDI

Institutional activities Competitive actions

SDI Research


OutlineOutline

• Introduction





• INSPIRE lays down general rules for the establishment of an infrastructure for spatial information in Europe to support:– environmental policies and – policies that affect the environment

• This infrastructure shall be based on infrastructures for spatial information established and operated by the Member States.

Proposal INSPIRE Directive Proposal INSPIRE Directive COM(2004) 516COM(2004) 516 General Provisions General Provisions

According to the INSPIRE proposal the infrastructure includes:metadata, spatial data sets and services; network services; agreements on sharing, access and use; coordination and

monitoring mechanisms, processes and procedures.


INSPIRE Information FlowINSPIRE Information Flow

Harmonised Data policy

Collaborativeagreements

CEN / ISO / OGCNational and Sub-

national SDI

Commercial & Professional Users

Citizens

Utility & PublicServices

NGOs and not-for-profit orgs

Government & Administrations

ResearchEuropean Data

National and Sub-national SDI

National and Sub-national SDI

Local data

Local data

European Data

Discovery Service

Technical Integration/harmonisation

Data resourcesData resources

INSPIRE specificationsINSPIRE specifications

UsersUsers

request for information services

delivery of information services

SDI – Spatial Data Infrastructure


Overview of requirementsOverview of requirements• metadata*• spatial data sets and spatial data

services*• network services*

– EU geo-portal

• access and rights of use for Community institutions and bodies**

• monitoring and reporting mechanisms**

• process and procedures

* technical: under JRC responsibility** legal/procedural: under Eurostat responsibility


INSPIRE metadata requirementsINSPIRE metadata requirements

• To create metadata that are complete and of high quality for:– spatial data– spatial data services

• To keep metadata up to date


INSPIRE metadata requirementsINSPIRE metadata requirements

• Metadata shall include information on the following:a. the conformity of spatial data sets with the implementing

rules referred to in Article 11(1);b. rights of use of spatial data sets and services;c. the quality and validity of spatial data;d. the public authorities responsible for the establishment,

management, maintenance and distribution of spatial data sets and spatial data services;

e. the spatial data sets to which public access is limited in accordance with Article 19 and the reasons for such limitation.

EcoInformatics meeting, 17/01/06 Ispra

INSPIRE Requirements on Discovery

General Assumptions (TBC by the DT)– Network Services are Web Services

– User Interface and Backend of the Services are not in the scope of the IR

– When metadata is involved in a service, it is exclusively INSPIRE metadata.

– A unique way to identify datasets and spatial services is available

– Metadata contains a cross reference to the data or spatial service

– Spatial Data Services are wide range not only “on-line” (could include services like consultancy services)



Issues on Multilingualism – only mentioned in the context of the interoperability of

spatial data sets and services for key attributes and corresponding multilingual thesauri

– Granularity: should the list of available languages be a service feature or at the data set or even at the feature attribute level ?

– Metadata/Data: should only metadata be multilingual or datasets as well ?

– Attributes label versus Attribute value: Should only attributes label be multilingual or should the attribute’ values be as well multilingual?



Discovery– The MS shall establish and operate discovery services

• to search for spatial data sets and spatial data services on the basis of the content of the corresponding metadata

• to display the content of the metadata.

– As a minimum the following combination of search criteria shall be implemented:

a) keywords; b) classification of spatial data and

services; c) spatial data quality and accuracy; d) degree of conformity with the

harmonised specifications provided for in Article 11;

e) geographical location;

f) conditions applying to the access to and use of spatial data sets and services;

g) the public authorities responsible for the establishment, management, maintenance and distribution of spatial data sets and services.



Discovery – Specific Assumptions– The handling of the catalogues distribution is out of the

scope of the Implementing Rules.

– Search criteria are available in the metadata(even the ones not explicitly listed for INSPIRE metadata, Keywords, classification of spatial data and services, geographical location)


INSPIRE Requirements on Discovery Possible Issues

Link with INSPIRE Metadata Specifications – Discovery and Metadata technical Spec’s

really independent ?

– Independence from Metadata Catalogue Schema ?

Query Language– Complexity ?

– Query Language Spec coupled or decoupled from Discovery Spec ?

– Based on which Standards (ISO/IEC 9075S (SQL)) ?

– As above: Independence from Metadata Catalogue Schema ?



Link between Data and Service Metadata – Links between metadata of spatial data and spatial

services (no-, uni- or bidirectional) ?

– Common metadata elements for spatial data and services (e.g. spatial accuracy: spatial data versus spatial data services e.g. coordinate transformation services) ?

Ranking of Results – Should be addressed if decided to be required

Single Access to Data and Services – An unique technical discovery specification for both ?

– How to deal with technical Service Metadata (e.g. Capabilities)?



Link to View Services “display of any relevant content of Metadata”:– Kind of Metadata:

Of the view (e.g. map) or of the original representation of the data (e.g. electronic version) ?

– Availability of Metadata:Assuming discovery & view service are independent and a metadata URL is a response to a view request requires:

• A unique dataset ID, available to the view service. • Discovery service URL known to the view service• Discovery service does not request preliminary transaction

before accepting a metadata request. • Discovery service supports the dataset ID as a query

parameter…


OutlineOutline

• Introduction





Example of institutional researchExample of institutional research

• Research question:– Is a common ontology desirable and feasible for multi-

lingual resource discovery in a European Spatial Data Infrastructure?

• Approach– Review of relevant literature – Prototype of experimental system for resource discovery

• Integrating a gazetteer• The EuroVoc multi-lingual vocabulary• GEMET thesaurus• Automatic concept space generator and graph matching

On the role of ontologies for resource discovery in a European Spatial Data Infrastructure, P. Smits and A. Friis-Christensen (sub. IEEE Trans. Knowledge and Data Engineering)

TermsOrdinary glossaries

Data dictionaries

Ad-hoc hierarchies

Thesauri Structured glossaries

XML DTDsXML

schema

Formal taxonomies

Description logics (OWL, DAML+OIL)

Data models (UML, STEP)

DB schema

Principled, informal hierarchy

Frames (OKBC)

General logic

Formal ontologies and inference

Metadata, XML schemas, data models

Thesauri and taxonomies

Glossaries and data dictionaries


«view»

Information community 3

«view»


«view»

Central

«view»


«view»


«view»

Information community 1.1

«view»

Information community 1.2

Metadata creation

Collections of metadata (e.g., portal, search engine)

Define query and consult metadata

harvest /distributedsearch

harvest /distributedsearch

searchsearch




• Two-step approach– Creation of multi-

lingual concept space

– Associative retrieval based on a neural network

Start

End

3. Cluster analysis

«database»

Ontology«database»

Resource descriptors

«database»

Concept Space

«database»

Index

«database»

Vocabulary 1. Collect resourcedescriptors

2. Filter and indexconcepts

«database»

Unidentified Concepts

H. Chen, B. Schatz, T. Ng, J. Martinez, A. Kirchhoff, C. Lin, A parallel computing approach to creating engineering concept spaces for semantic retrieval: the Illinois digital library initiative project. IEEE Trans. Pattern Analysis and Machine Intelligence, Vol. 18, No. 8, August 1996, pp. 771-782.


«database»

Metadata repository

Ontologies

Harv ester WS-Cat

WMS

HTML

RDF

Wrapper

Concept Space Generator

Query expansion and graph matching

XML

SQL

Concept Space

Ontology editor

OWL

Reasoner

Collection of web addresses

XSLT file library

Ontology importer

XML

DIG


• Conclusions of study– Impractical to rely only on one common ontology for

resource discovery– Using human-created ontologies in combination with

automatic concept space generation and associative retrieval is a powerful means to the discovery of geospatial resources

– In the absence of a consistent use of semantic web technologies, a centralized approach to indexing of metadata is required, which has consequences for architectural and organizational choices.



OutlineOutline

• Introduction




ORCHESTRA

Orchestra Goals

• To design and implement an open service-oriented architecture for risk management.

• To develop services that are useful for various risk management applications

• To validate the ORCHESTRA results (i.e. architecture and services) in a multi-risk scenario.

• To provide software specifications for risk management applications, and to provide additional information about these standards in the form of a book (the ORCHESTRA book).

–In particular, the de facto standard of OGC and the de jure standards of ISO and CEN are envisaged to be influenced

–To provide input to GMES and INSPIRE

Orchestra factsheet

• For more information:

http://www.eu-orchestra.org

• Project Reference: 511678

• Start Date: Sept. 1, 2004

• Duration: 36 months

• Project Cost: 13.748.984,00

• Contract Type: Integrated Project

• End Date: August 31, 2007

• Project Funding: 8.199.978,00

http://www.eu-orchestra.org/

Cooperation with related 6 FP IPs

• Agreement on common architectural principles of the info-structure between the IPs Orchestra, WIN & OASIS

– Service Oriented Architecture– Distributed services based on (existing) Standards– Generic services as main building blocks for many risk

management applications• These principles should serve as a basis for a common

INSPIRE/GMES Architecture

• Agreed link to INSPIRE– any architecture development should contribute to the definition of

INSPIRE implementation rules. – close cooperation with the INSPIRE drafting team (sharing

technical expertise, trying to match pilots with interests of INSPIRE).

Pan-European Assessment of natural HazardsPEUNHA

1. Objectives & Scope of the Pilot

2. Scope & addressed ORCHESTRA issues

3. Use case(s)

– Draft planning – Some aspects – Schematic Architecture

1. Objectives of the pilot (1)

• Test the ORCHESTRA architecture for pan-European hazard assessing

• Focus on risks related to natural hazards (flooding, droughts, forest fires).

• Support decision makers in the EC to more efficiently integrate European information:

1. to assess the risk of forest fires in the Member States of European Union and to support forest fire prevention.

2. to assess the vulnerability towards floods and droughts within the Member States of European Union according to different considerations and scenarios

3. to assess the vulnerability to various hazards (floods, droughts, forest fires) within the Member States of European Union

2. Objectives of the pilot (2)

• Pilot should enable stakeholders to access assessments in an interoperable and also “interactive” manner (more than static maps)

• Experts, Stakeholders and Users

– Experts that conduct policy support towards various EC DG’s in the context of forest fires, droughts and flooding (JRC Actions INFOREST and WDNH)

– Decision makers within the supported EC DG’s (ENV, REGIO)

– later possibly also national decision makers/stakeholders

Use case(s) – some aspects

• PEUNHA-1: Interoperable pan-European forest fire probability map

– Integrated access to harmonized (historical) fire data records (data on individual past fire events) coming from different EU Member States with different data formats, semantics etc. for pan-EU analysis

– Fire data aggregation with different temporal and spatial resolution (grids, NUTS)

– Data aggregation with simple fire frequency calculations (record count), or with other descriptive statistics on the data items (e.g. burned areas by land cover types, fire causes, time of intervention).

– Access to other geospatial data (e.g. administrative regions, land cover, Natura2000 sites, and bioclimatic regions) may be jointly processed with fire data to derive key fire risk related indicators

– Combine fire trends with meteorologically derived indices– Link burnt area maps e.g. for validation

Schematic Architecture PEUNHA-1 – first experiences


Test bed I - Test bed I - Lessons LearnedLessons Learned

• High degree of re-use: – Easier application development

• Service oriented (distributed processing) – less inconsistency (no uncontrolled data duplication and algorithm redundancy) – increased quality

• A more open and visible environment:– Developed services can be published, e.g., via ESA’s service support

environment

• Some types of web services (e.g WFS) are only feasible for limited types of applications: – Performance issues with large amounts of data

• Current status of interoperability in supposedly standardized software and tools may be sometimes disappointing:– Even following existing standards, interoperability, has proven to be challenging

This emphasizes the need for INSPIRE and the focus on interoperability research


Thank you for your attention !

INSPIRE:INSPIRE:

http://inspire.jrc.ithttp://inspire.jrc.it

1 EcoInformatics meeting, 17/01/06 Ispra INSPIRE - Infrastructure for Spatial Information in Europe...

Documents

Transcript of 1 EcoInformatics meeting, 17/01/06 Ispra INSPIRE - Infrastructure for Spatial Information in Europe...