The Role of Semantics and Terminologies in a Service-Oriented Architecture Paul Smits, Michael Lutz European Commission – DG Joint Research Centre Ispra, Italy 20 June 2007

Overview Setting Composition Methodology Open Issues

Overview Setting Composition Methodology Open Issues

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)  Fire frequency An Example: Forest Fire Density

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

Forest Fire Density Service Chain How to compose such a service chain?

Overview Setting Composition Methodology Open Issues

Assumptions Only information generating services –no real world side effects (e.g. charge credit card) –data access services & geoprocessing services Functionality can be described by output type and its relation to the inputs  output-driven composition

Method – Overview

Service Discovery Based on rule-based descriptions of operations –what kind of output data can be generated given certain input data? –structured by domain model (entity, entityCollection, field, featureType, …) Can be augmented by domain knowledge –(taxonomic) relationships

Operation Descriptions Operation description rules are labelled and describe the relationship between inputs and outputs of an operation normalizeByArea: frequency(f,fc1,fc2)  density(d,fc1,fc2) ”The normalizeByArea operation can be used to produce a density d (of the feature collection fc1 based on the feature collection fc2) from the frequency f of fc1 in fc2)”

Domain Knowledge Operation description rules are based on domain rules that describe domain knowledge featureCollection(fc), featureType(fc,AdminUnit)  tessellation(fc) “admin. unit feature collections are tessellations”

Service Composition Start with goal definition (e.g. ”Density of forest fires”) density(f,fc1,fc2), featureType(fc1, ForestFire) Find (domain or operation description) rules that contain (part of the goal) in their head normalizeByArea: frequency(f,fc1,fc2)  density(d,fc1,fc2) Add operation label to the service chain Define new goal (replace head with body) frequency(f,fc1,fc2), featureType(fc1, ForestFire) Repeat until no more conditions

Service Chain

Overview Setting Composition Methodology Open Issues

Connection between catalogue/service metadata and composition engine/rules –for legacy metadata –for new metadata Ontology-based user interface Well-founded top-level ontology (entity, field, …) Using different taxonomies for feature types (e.g. based on user preference) SDI Architecture

Conclusion Setting –SOA –Service Composition Composition Methodology –Rule-based service descriptions –(Semi-)automatic Composition Open Issues

Thank you!

The Role of Semantics and Terminologies in a Service-Oriented Architecture Additional Slides

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

Service Composition Goal Domain Rule Operation Description Rule

Architecture – To be updated