Semantics in Web Service Composition for Risk Management Michael Lutz European Commission – DG Joint Research Centre Ispra, Italy EcoTerm IV, Vienna, April 2007

Overview Setting Composition Methodology Requirements

Overview Setting Composition Methodology Requirements

ORCHESTRA Duration: 9/2004 – 2/2008 = 42 months Integrated Project Project Cost: 13.7 M€ Project Funding: 8.2 M€ For more information:

ORCHESTRA – Goals Develop and test interoperable software architecture for risk management applications –specify interoperable risk management services –input to standardisation (OGC, ISO, CEN…) Role JRC–IES: –Technical supervisor –Pilot development within two application areas (forest fires and flooding)

Service Oriented Architecture Distributed capabilities (possibly under different ownership) SOA enables matching needs of service consumers with capabilities provided Standardised service interfaces, e.g. (in the geospatial world): –Data access services (WFS, WCS) –Geoprocessing services (WPS) –Rendering services (WMS) –Catalogue services

Service Composition If existing services do not directly match service consumer needs  Compose new and more complex services out of simpler ones –Service chain description: explicit description of a concrete service chain in some workflow language (e.g. WS-BPEL) –Service chain instance: service instance provided by a workflow engine executing a service chain description Composition currently done manually

Number of Forest Fires per km 2 –aggregated by administrative unit (e.g. NUTS3) An Example: Forest Fire Density

Access –Fire records from Member States An Example: Forest Fire Density

Access –Fire records from Member States Spatial and temporal aggregation –Based on Administrative Units (or European Grid) An Example: Forest Fire Density

Access –Fire records from Member States Spatial and temporal aggregation –Based on Administrative Units (or European Grid) Analysis –Fire density –Fire frequency –Burnt areas by land cover types An Example: Forest Fire Density

Forest Fire Density Service Chain

Overview Setting Composition Methodology Requirements

Scenario Goal: Create service chain that provides “Forest Fire Density in Europe for ” Actor: Application developer

Ontology-based User Interface Create GUI dynamically based on ontology concepts

Service Discovery Normal match –service can directly provide data Conditional match –service can potentially provide data –requires additional searches Query expansion (based on subsumption)

Conditional Match – Example Query Q: service that provides “forest fire density” Available service S provides “density of feature type X” –where a collection of X is one of the inputs S is a match for Q under the condition that X is a (kind of) forest fire –requires additional searches for collection of X (to be used as input for S)

Architecture – Composition

Forest Fire Density Example Query: Forest Fire Density Match: Normalisation Service –Condition: input = Forest Fire Frequency

Forest Fire Density Example Query: Forest Fire Frequency Match: Spatial Aggregation Service –Conditions:input 1 = Forest Fire Collection input 2 = Tesselation

Forest Fire Density Example Query: Forest Fire Collection; Tesselation Matches:WFS (forest fire registration) WFS (administrative units)

Overview Setting Composition Methodology Requirements

How to describe services? How to describe functionality (e.g. forest fire density)? How to describe inputs and outputs? How to describe relationships between them? –e.g. “if the input is a collection of X, then the output is a density of X”

How to represent this information? What to represent in “normal” metadata, what in the ontology? How to link vocabularies used in metadata and in the ontology? –for legacy metadata –for new metadata Which ontology languages are appropriate? What types of inferences are required?

Conclusion Setting –SOA –Service Composition Composition Methodology –(Semi-)automatic Composition Requirements –Describing services –Metadata representation

Thank you!

Ontology