michael lutz – ontology-based gi service discovery & composition tu wien, 26.04.2006...

•

Michael Lutz – Ontology-based GI Service Discovery & CompositionTU Wien, 26.04.2006

Ontology-based Discovery and Composition of Geographic Information Services

Michael Lutz

TU Wien, Research Group Geoinformation

April 26th, 2006

•

TU Wien, 26.04.2006 Michael Lutz – Ontology-based GI Service Discovery & Composition

Overview

• JRC – Spatial Data Infrastructures Unit

• Ontology-based service discovery Data access services Geoprocessing services Integration in SDI

• An SDI experiment for disaster management

•


Joint Research Centre

• Mission: provide customer-driven scientific and technical support for the conception, development, implementation and monitoring of EU policies

• Service of the European Commission (EC) Coordinates numerous EU-wide networks Carries out studies and experiments in our own

laboratories on behalf of customer institutions Participates in projects Liaises with a variety of non-EU and global

scientific and standard-setting bodies

•


Spatial Data Infrastructures (SDI) Unit

• Mission: coordinate the scientific and technical development and implementation of INSPIRE

• INSPIRE: Infrastructure for Spatial Information in Europe provide integrated GI services that should allow

users to identify and access GI (from local to global level), in an interoperable way for a variety of uses.

target users include policy-makers at European, national and local level and the citizen.

•


Where is the closest place to

eat which isstill open?


eat which is still open?

CurrentLocation

“Restaurants”“Hotels”

GI Service Discovery in SDIs – Use Case

•


Where is the closest place to eat which is

still open?0,9 km

1,0 km

0,5 km

1,9 km

CurrentLocation

GI Service Discovery in SDIs – Use Case

•


Spatial Data Infrastructures

• Goal: efficient provision & access to distributed, heterogeneous geographic

information in a loosely coupled manner

• Standardised service interfaces for discovering data & services – Catalogue Services accessing data – WFS, WCS (data access

services) viewing data – WMS processing – WPS (geoprocessing services)

•


Service Composition

• Creating value-added (complex) service chains from simple component services e.g. data access + geoprocessing services

• Service discovery is an important part of service composition goal: find appropriate and matching services

•


x1: double

x2: double

y1: double

y2: double

doubledistance_1

GetCurrentLocation

point: (lat: double, long: double)

e.g. <32.5, -23.5>

inputs & outputs

functionality

WFS 1

„Restaurant“features:- location (lat/lon)- opening hours- meals

extractLocation

point: (lat: double, long: double)

e.g. <51.2, -115.56>

meaning of feature type

Service Discovery & Composition

•


Service Discovery & Composition

Service Requester

required

overallfunctionality

ServiceDescriptions

inputsoutputs

functionality

GI Services

has already discovered

ServiceDescriptions

inputsoutputs

functionality

GI Services

impose constraints on

Query

inputsoutputs

functionality

Matchmaking

•


Problem – Searching in SDIs Today

• Mainly based on matching keywordsand other search terms with metadata entries different terminology

low recall low expressivity

low precision

• Difficult to express functionality

•


Problem – Accessing Data Today

• Syntactic descriptions of the schema often not sufficient for interpreting the attributes

• difficult to create meaningful query expressions or extract data for further processing

•


Ontologies for Discovering GI Services

• An ontology is an explicit formal specification of a shared conceptualization

• Ontologies can enrich GI metadata semantics become machine-interpretable concise and expressive queries

• Logical reasoning on ontology concepts implicit relationships flexible classification of information

• Languages: Description Logics (DL) First-Order Logic (FOL)

•


DL subsumption reasoning


eat which is still open?

based on

based on

Domain Ontology

DL description of the query concept “place to eat”(with location & opening hours)

Query concept

DL description of the application concept “Restaurant”

Application Ontology Concept

WFS 1

„Restaurant“features:- location (GK)- opening hours- meals

Discovering Data Access Services

•


Discovering Data Access Services

• User Interface built dynamically from selected ontologies

• Automatically derivesDL query concept

• Queries Semantic Catalogue Service

• Can also be used for retrieving discovered data

•


Catalogue

ISO 19115Metadata

Ontology-Based

Reasoner

Ontologies

QueryClient

2. define query using shared vocabulary (resembling SQL select statement)

Architecture

1. request for shared vocabulary

6. catalogue request

3. derive DL queryconcepts for feature type

5. build catalogue query

4. request for matching concepts

•


Geo-Data

WFSCatalogue

ISO 19115Metadata

Ontology-Based

Reasoner

Ontologies

QueryClient

2. define query using shared vocabulary (resembling SQL select statement)

Architecture

1. request for shared vocabulary

3. derive DL queryconcepts for feature type

5. build catalogue query

4. request for matching concepts

6. catalogue request9. GetFeature

8. derive WFS query

•


Discovering Geoprocessing Services

• Shared vocabularies (domain ontologies) do not contain information on operations

• Matching only inputs & outputs often without shared vocabularies low recall not expressive enough low precision

• Matching also pre- & postconditions requires FOL theorem provers expensive

•


Operation description of the provided operation

two-step matchmaking

Where is the closest place to eat which is

still open?

based on

based on

Domain-level Operation Description

Operation description of the required operation

Semantic Query

Semantic Advertisement

x1: double

x2: double

y1: double

y2: double

doubledistance_1

Discovering Geoprocessing Services

•


• For each service advertisement and request, define a semantic signature (inputs & outputs) with

references to DL concepts pre- & postconditions in FOL

DLOntology

FOL Ontology

Operation Description

SemanticSignature

Pre- & Post-conditions

refers torefer to

Operation Descriptions

•


Matchmaking

• Based on function subtypes if a is a subtype of q, a can be used instead of q

a is a match for q

1. Match inputs & outputs DL subsumption reasoning efficiently filter out potential matches

2. Match pre- & postconditions FOL theorem prover select most appropriate service(s)

•


Integration within SDI

• Components: Semantic Catalogue

Service Semantic Catalogue

Client Ontology

Management Service DL Reasoner and

FOL Theorem Prover Integrate ontology-based descriptions into existing

metadata

•


Conclusion

• GI service composition requires expressive and strict discovery

• Keyword-based methods have low recall & precision

• Matchmaking with ontology-based service descriptions can enhance catalogue search

• Successful integration in SDI workflows

•


Open Issues

• Ontologies do not solve the “metadata trap”

• Usability of ontology-based user interfaces especially for FOL

• “Soft” matchmaking methods (similarity) different use cases

• Granularity of GI service discovery task ontologies

•


A Pilot for Disaster Management

• 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: to assess the risk of forest fires in the EU

Member States and to support forest fire prevention.

to assess the vulnerability to various hazards (floods, droughts, etc.) in the EU Member States

•


A Pilot for Disaster Management

• 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

Decision makers within the DGs ENV & REGIO

later possibly also national decision makers/stakeholders

•


Addressed Technical Aspects

• Schema mapping from heterogeneous national data sources (spatial & non spatial data) into a common pan-European model

• Distributed geo-processing to support ad-hoc analysis focussing on combination of GI and spatial decision support

• Support interactive web-based assessment of hazards/vulnerabilities

• Use ontologies for derive schema mappings and to describe hazard/vulnerability analysis tasks.

•


Architecture

The Basic Service Chain

MS forest fireregistration



FAS FAS FAS

accesses accesses accesses

Schema Mapping Service

Mapping Rules toCommon Schema

Forest fire features

uses

Coordinate Operation Service uses

Coordinate Operation Service

uses


Spatial Aggregation

Service

Administrative boundaries

FAS

Classification Service

Rendering Service

PEUNHA Client

These are both implementations of a Geospatial Calculation

Service

accesses

accesses in order toallow the user to choose

a feature type for aggregation

•


FASFAS


FAS



FAS FAS

Spatial Aggregation

Service


Rendering Service

PEUNHA Client


Architecture

Integrating user-defined data sets

Metainformation

(Semantic) Catalogue

Service

accesses

RiskOntologies

Ontology Access Service

accesses

Inferencing Service

accesses

accesses

accesses for finding otherFASs providing appropriateforest fire registration data

PEUNHA Client


FAS

accesses

(Semantic) Catalogue

Service



specifies

•


FASFAS

Chain Execution Service




FAS FAS FAS


Spatial Aggregation

Service


FAS


Rendering Service

PEUNHA Client

uses

Pre-defineddescriptionof service

chaintemplatePEUNHA

Client

Meta-information

Catalogue Service

Risk(Process) Ontologies

Ontology Access Service

Inferencing Service

access for finding appropriateservices for “instatiating” the

service chain

Chain Execution Service


PEUNHA Client

“Instatiated”descriptionof service

chain

uses

creates


specifies

Architecture

Semantic Service Orchestration

•


Thanks for your attention!

http://ifgi.uni-muenster.de/~lutzm

•

Michael Lutz – Ontology-based GI Service Discovery & CompositionTU Wien, 26.04.2006

Ontology-based Discovery and Composition of Geographic Information Services

Additional Slides

TU Wien, Research Group Geoinformation

April 26th, 2006

•


Building Domain Ontologies

• Define ranges (and domains) of roles

• Define concepts using existing roles cardinality constraints and value restrictions for

further constraining the range of a role

• Map ranges of roles to XML schema datatypes (e.g. string or decimal) or simple GML geometry types (e.g. point or polygon) value comparisons can be used in query

statements

•


Domain Ontologies – Example

MEASUREMENTS

HYDROLOGY

observable

Measurement QuantityquantityResult

1Phenomenon

1

gml_Point

1..n

xsd_DateTime

timeStamp

1

xsd_DateOR

Unit

value

unitOfMeasure1

Centimeter

Depth

WaterLevel

observable

xsd_Decimal

1

taxonomic relationship

observable non-taxonomic relationship

Lake concept

1 cardinality constraint

GML geometry typegml_Point

xsd_String XML datatype

location

HydrologicalPhenomonon

WaterBody

observedWaterBody

1

River Lake

HydrologicalQuantity 1

Discharge

•


(define-concept Measurement (and (at-least 1 quantityResult) (exactly 1 location) (exactly 1 timeStamp)))

(define-concept Quantity (and (exactly 1 observable) (exactly 1 value) (exactly 1 unitOfMeasure)))

(implies Depth Phenomenon)

(implies Centimeter Unit)

(define-primitive-role quantityResult :domain Measurement :range Quantity)

(define-primitive-role location :range gml_Point)

(define-primitive-role timeStamp :range (or xsd_Date xsd_DateTime))

(define-primitive-role value :domain Quantity :range xsd_Decimal)

(define-primitive-role unitOfMeasure :domain Quantity :range Unit)

(define-primitive-role observable :domain Quantity :range Phenomenon)

MEASUREMENTS

Concept Definitions Ranges and Domains of Roles

(define-concept HydrologicalQuantity (and Quantity (all observable HydrologicaPhenomenon) (exactly 1 observedWaterBody)))

(implies HydrologicaPhenomenon Phenomenon)

(implies WaterLevel (and Depth HydrologicaPhenomenon))

(implies Discharge HydrologicaPhenomenon)

(implies Lake WaterBody)

(implies River WaterBody)

(define-primitive-role observedWaterBody :domain HydrologicalQuantity :range WaterBody)

HYDROLOGY

Concept Definitions Ranges and Domains of Roles

Domain Ontologies – Example

•


Building Application Ontologies

• Same guidelines as for domain ontologies

• One concept representing a feature type derive from existing concept in domain ontology (all-quantified) value restrictions cardinality constraints additional roles

• Query Concepts defined using domain roles

•


Application Ontologies – Examples

CHMI

(define-concept chmi_Measurement (and Measurement (exactly 1 chmi_qRWaterLevel) (exactly 1 chmi_qRDischarge) (all timeStamp xsd_DateTime) (exactly 1 name) ))

(define-primitive-role chmi_qRWaterLevel :parent quantityResult :range (and (all unitOfMeasure Centimeter) (all observable WaterLevel) (all observedWaterBody (and River (some chmi_riverName))))

(define-primitive-role chmi_qRDischarge :parent quantityResult :range (and (all unitOfMeasure CubicMeter) (all observable Discharge) (all observedWaterBody River (and River (some chmi_riverName))))

(define-primitive-role chmi_riverName :parent name :domain River)

(define-concept Query_1 (and (some quantityResult (all observable WaterLevel)) (some location *top*) (some timeStamp *top*) (some name *top*) ))

(define-concept Query_2 (and (some quantityResult (and (all unitOfMeasure Centimeter) (all observable WaterLevel))) (some location *top*) (some timeStamp *top*) (some name *top*) ))

(define-concept Query_3 (and (some quantityResult (and (all unitOfMeasure Centimeter) (all observable WaterLevel))) (some quantityResult (and (all unitOfMeasure CubicMeter) (all observable Discharge))) (some timeStamp *top*) (some name *top*) ))

•


CHMI

(define-concept chmi_Measurement (and Measurement (exactly 1 chmi_qRWaterLevel) (exactly 1 chmi_qRDischarge) (all timeStamp xsd_DateTime) (exactly 1 name) ))

(define-primitive-role chmi_qRWaterLevel :parent quantityResult :range (and (all unitOfMeasure Centimeter) (all observable WaterLevel) (all observedWaterBody (and River (some chmi_riverName))))

(define-primitive-role chmi_qRDischarge :parent quantityResult :range (and (all unitOfMeasure CubicMeter) (all observable Discharge) (all observedWaterBody River (and River (some chmi_riverName))))

(define-primitive-role chmi_riverName :parent name :domain River)

(define-concept Query_1 (and (some quantityResult (all observable WaterLevel)) (some location *top*) (some timeStamp *top*) (some name *top*) ))

(define-concept Query_2 (and (some quantityResult (and (all unitOfMeasure Centimeter) (all observable WaterLevel))) (some location *top*) (some timeStamp *top*) (some name *top*) ))

(define-concept Query_3 (and (some quantityResult (and (all unitOfMeasure Centimeter) (all observable WaterLevel))) (some quantityResult (and (all unitOfMeasure CubicMeter) (all observable Discharge))) (some timeStamp *top*) (some name *top*) ))

Application Ontologies & Query Concepts – Subsumption Hierarchy

•


User Query → DL Query Concept

• User query:SELECT x.quantityResult.value, x.timeStamp FROM

Measurement x WHERE(x.quantityResult.observable hasType WaterLevel) AND(x.quantityResult.unit hasType Centimeter) AND(x.quantityResult.value >= 300) AND(x.timeStamp isBefore 12:00:00) AND(x.location isWithinBoundingBox (12,23,45,25))

• DL query concept for feature type:(define-concept query (and

Measurement(some quantityResult

(all observable WaterLevel) (all unitOfMeasure Centimeter))))

Result: e.g. chmi_Measurement

•


Registration Mapping for GI Retrieval

• Mapping between XML and ontology structures

• For deriving WFS query and filter expression

/StavVody chmi_Measurement

/StavVody/gml:position/gml:Point chmi_Measurement.location

/StavVody/tok/text() chmi_Measurement.chmi_qRWaterLevel.observedWaterBody.name

/StavVody/stanice/text() chmi_Measurement.name

/StavVody/stav chmi_Measurement.chmi_qRWaterLevel

/StavVody/stav/text() chmi_Measurement.chmi_qRWaterLevel.value

/StavVody/prutok chmi_Measurement.chmi_qRDischarge

/StavVody/prutok/text() chmi_Measurement.chmi_qRDischarge.value

/StavVody/datum/text() chmi_Measurement.timeStamp

/StavVody chmi_Measurement

/StavVody/gml:position/gml:Point chmi_Measurement.location

/StavVody/tok/text() chmi_Measurement.chmi_qRWaterLevel.observedWaterBody.name

/StavVody/stanice/text() chmi_Measurement.name

/StavVody/stav chmi_Measurement.chmi_qRWaterLevel

/StavVody/stav/text() chmi_Measurement.chmi_qRWaterLevel.value

/StavVody/prutok chmi_Measurement.chmi_qRDischarge

/StavVody/prutok/text() chmi_Measurement.chmi_qRDischarge.value

/StavVody/datum/text() chmi_Measurement.timeStamp

•


select select

OperationOntology

John(Service Provider)

Susan(Service Requester)

FOL Pre-and Post-conditionsDL

SemanticTypes

Semantic Query

DLApplicationConcepts

RefinedFOL Pre-and Post-conditions

add constraints(imposed by adjacentservices in the chain)

add constraints(based on required functionality)




add constraints(based on provided functionality)

addconstraints


OperationOntology

Semantic Advertisements and Queries

•


Semantic Query



Semantic AnnotationSemantic Annotation


Semantic AnnotationSemantic Advertisement



All services in the registry

Methodology – Matchmaking Procedure





Services with matchingsemantic signature

Matching Pre- and Postconditions(FOL Theorem Prover)

Services with matchingpre- and postconditions

•


Matchmaking – Function Subtypes

• Matchmaking based on function subtypes

• safe substitution if f1 is a subtype of f2, it can be used instead of f2

f1 is a match for query f2

f2: D2 C2

D2 C2

f1: D1 C1

D1 C1

•


Matchmaking

• Matchmaking based on function subtypes

1. Matching Inputs & Outputs using DL subsumption reasoning

2. Matching pre- & postconditions using a FOL theorem prover

•


Ontology-based Descriptions & Metadata

SemanticAdvertisement/

Query

SemanticSignature

Metadata/CatalogueRequest

refers to

refers to

refers to

DL ApplicationOntology

FOL ApplicationOntology

operationDescription

...

...Pre- & Post-conditions

•


OntologyManagement

Service

John(Provider)

SemanticCatalog Client

SemanticCatalog

Workflow for Registering Services

2. get domainoperations

1. select domains

4. select operation

6. add constraints

7. add constraints onother metadata fields

3. get domainvocabularies

5. get operationspecification

8. register servicemetadata

9. store semanticadvertisement

10. store metadata (incl. referenceto semantic advertisement

11. storeapplicationontology

•


10. get superconcepts of requested inputsand subconcepts of requested outputs

FOLTheoremProver

DLReasoner

SemanticCatalog

SemanticCatalog Client

OntologyManagement

Service

Susan(Requester)

Workflow for Service Discovery

1-7. same as service registration

8. send request(incl. semantic query)

9. get DLapplication ontologies

12. get FOL domain ontologies

14. test proofobligations

11. retrieve matchingadvertisements

13. for each matching

advertisement: generate proof obligations for predicate and

plug-in post match

•


Distances – Conceptualisation

• Based on R3 (incl. metric) as a reference space

• Primitives include curve. Curve between two points in R3 (ternary

predicate) length. Function returning the length of a curve plane, sphere, network etc. Unary predicates that

represent particular subspaces of R3

shortestCurve. Shortest curve between two points in a particular subspace of R3 (quaternary predicate)

•


Domain-level Operation Description

• distance operation between the points p1 and p2

• pre: p1 and p2 are in the same subspace of R3

• post: length of the shortest (existing) curve in a particular subspace of R3 between p1 and p2

•


Rule-based Approach to GI Discovery

DAFIF_Airport(a), icao_code(a,i), … => Airport(a), icao(a,i), ...

Airport(a), Runway(r), hasPart(a,r), length(r,l), l>5000 =>C5CapableAirport(a)

Airport(ap), icao(a,icao), Runway(rw), icao(rw,icao) =>hasPart(ap,rw)

• “reproduce” GML schema in OWL

• mapping rules (horn clauses) from OWL “application schema” to domain ontology possible to create OWL instances from data and run inferences (forward/backward chaining) on

them

• requires sophisticated discovery procedure

•


Rule-based Approach to Discovering Data Access Services

michael lutz – ontology-based gi service discovery & composition tu wien, 26.04.2006...

Documents