ontology-driven automatic web service composition for geoscience automation

LAITS

Laboratory for Advanced Information Technology and Standards

Ontology-driven Automatic Web Service Composition for Geoscience Automation

Liping DiCenter for Spatial Information Science and Systems (CSISS)

George Mason University6301 Ivy Lane, Suite 620

Greenbelt, MD [email protected]

LAITS


Introduction

• Geospatial data is the major type of data that human beings has collected.

– more than 80% of the data are geospatial data.

• Image/gridded data is the dominant form of geospatial data in terms of volume.

– Most of those data are collected by the Earth Observing (EO) community.

• Geospatial data will grow to ~exabyte very soon.– NASA EOSDIS has more than two petabytes of data in archives and is

added more than 2 terabytes of new data per day.– Application data centers: 10’s of terabytes of geospatial data.– Tens of thousands of datasets on-line now.

• Geospatial data has to be converted to user-specific information and knowledge before they become useful.

• How to effectively, wisely, and easily use the geospatial data is the key geospatial technology issue that we have to solve.

LAITS


The Problems

• Currently, the conversion from Geospatial data to information and knowledge requires the users at their local site having:

– Significant amount of knowledge• Domain knowledge for information/knowledge extraction from raw data• Domain knowledge on the geospatial data processing/formats

– Significant amount of computer hardware and software resources.– As a result, the use of geospatial data is currently very expensive

• Most geo-imagery will never be directly analysed by humans– Human attention is the scarce resource, insufficient to analyze petabytes of

geospatial data.– Many datasets never have been analysed before they are archived.

• The fundamental problem is that current data and information systems at data providers’ site can only provide on-line ordering, and access at best, of data and standard products, not the user-specific information and knowledge.

– If a product that the user want does not exist, the system has no way to create it on demand.

– Rich in geospatial data but poor in up-to-date geospatial information and knowledge.

• Instead of only being used by experts, geospatial data should also be used easily by other people, from students to decision-makers, and be transformed easily into higher level information and knowledge.

LAITS


Ultimate Goal-Intelligent System for Geoscience Automation

• An intelligent geospatial knowledge system for automating the process from geospatial data to information to knowledge based on users’ requirements – choreographed intelligent web services for geospatial knowledge

discovery;

– the dissemination of personalized, on-demand geospatial data, information and knowledge.

• The system can answer many “what if” questions through– Automatic service composition: intelligently chaining individual

service modules to form a complex geospatial model;

– matching the input data with the model;

– executing the model to deliver the answer to the users.

LAITS


Geospatial Web Services and Service Composition

• Geospatial Web Service– A modular Web application that acts on geospatial data, information, or

knowledge.

• Composition of Geospatial Web Services– Assembling individual geospatial Web services to create high-level

geospatial processes.

• Geospatial web services are changing the way in which geospatial applications are designed, developed, deployed and executed.– From centralized to distributed, from isolated implementation to

large-scale sharing, and from private solution to standardized solution

LAITS


“Intelligent” Mechanism for Composition

• Facilitating information discovery and integration over the network in web service environment.

• Automating the assembly of service chains.– Involving Universal Description Discovery and

Integration (UDDI), Web Service Description Language (WSDL) and Simple Object Access Protocol (SOAP)

– Using AI Planning method– Driven by geospatial domain knowledge

expressed in ontology

LAITS


Solve complex geospatial problems by using distributed geospatial services:

The Geo-object and Geo-tree Concepts

Archived data (geo-object)

User (requested) geo-object

Intermediate geo-object

Without service With service Modeling and virtual data services

User request

User received

Data transformation services (format transformation, reprojection, regriding, etc)Data access services (spatial/temporal/parameter subsetting, mapping, etc)

High level services (classification, geophysical parameters, modeling, etc)

LAITS


“Geo-object” concepts

• Geo-Object– A granule of geospatial information.– Consisting of data itself, a set of data attributes (data metadata),

and optionally a set of description of methods that can act on it (service metadata).

• Archived Geo-Object– Physically exists in a data system or archive

• Virtual Geo-Object– A geo-object that doesn’t physically exist but an information system

knows how to create it on-demand.

• User Geo-Object– a geo-object that user wants.

LAITS


“Geo-Tree” Model

• “Geo-Tree”– A composition of chained services and geo-object to enable the process of creating

“User Geo-Object” from “Archived Geo-Objects” and “Virtual-Objects”.– The service chain represents a geospatial process model

• Geospatial service chain where, for each adjacent pair of services, the output of the first service is part of the inputs of the second service.

– It represents the geospatial process knowledge

• The intelligent geospatial web services are all about how to automatically create the geotree that can generate the user geo-object.– How to do that: through AI and semantic web technologies

LAITS


Relationship between Geo-tree and Service Chain

• Geo-tree is a conceptual geospatial process model representing the step-by-step how a geo-object (representing either GI or GK) is derived.– representing the domain knowledge needed for analyzing

geospatial data to derive user-specific GI or GK.– A library of Geo-trees represents the enterprise/community

knowledge since it is contributed by the members of them.

• The root of a geo-tree is a virtual product that the Geo-tree can derive, and all sub-trees are also virtual products.

• A service chain is the instantiation of the Geo-tree. If a Geo-tree can be instantiated, then all virtual products in the tree can be produced on demand.

LAITS


Automatic “Geo-Tree” Composition

• Composition-AI planning problem– Goal: “User Geo-Object”– Initial state: “Geo-Object” availability status– Planning operator: geospatial service– Dependence and constraints: precondition and effect of service– Searching: backward

• Composition Ingredients– Semantic description of Services and Data

• Supporting effective “Geo-Object” discovery, seamless resource integration and reuse.

– Domain knowledge• Ontology to describe the relationships among services, data, and the

association between service and data• Creating new “Geo-Object” and suggesting what should be done following

the new “Geo-Object” and which “Geo-Object” should be chosen next .

• “Geo-Tree” Representation– BPEL4WS– OWL-S

LAITS


Modeling “Geo-Object” with Semantics (1)

• Semantic “Geo-Object”– Geospatial Ontology

• Conceptualization of geospatial domain.• Including Service Ontology and Data Ontology

– OWL-S • A OWL-based Web service ontology

– “profile” describes what a geospatial web service does by specifying its input and output, preconditions, effects and other non-functional properties,

– “process” describes how the service works by specifying either atomic process or composition process,

– “grounding” describes how service is invoked by specifying the details of communication protocol.

LAITS


Modeling “Geo-Object” with Semantics (2)

• With semantics, we can– Reason about the functionalities that service performs– Reason about preconditions of using the service and effects after

using the service– Understand the relationships and rules of geospatial computing– Understand the meanings and order of exchanged messages– Compose “Geo-Objects” to create a new more complex “Geo-

Object”.

• The key components are discussed in the following slides

LAITS


Service Ontology

• Group service types into hierarchy based on scientific meaning of the services.– For example, Landuse classification service type has many

subtypes, include IGBP_classification, Olson_classification, etc,

• Define the relationship between the service types.

• Each service instance has to declare which service type it belongs.

• It is essential for model construction, accurate discovery of service instances, automatic/semi-automatic service chaining, and both model and service interoperability.

LAITS


Data Ontology

• Group data types into hierarchy based on scientific meaning of the data.

• Define the relationship between data types

• Each data instance has to declare which data type it belong to.

• It is essential for model construction, accurate discovery of data instances, automatic/semi-automatic service chaining, model interoperability and match of services with data.

LAITS


Ontology-enabled Catalog/Registry Service

• Catalog/Registry Service– Playing a ‘directory’ role

• “Geo-Objects” and associated services advertise the availabilities of their resources using metadata in the catalog

• users can query the metadata in the catalog to discover interesting resources.

– OGC Catalog Service for Web (CS/W)• ogcRIM (Registration Information Model)

– Based on ebRIM– Supporting the publish, discovery and access of geospatial information

LAITS


Ontology-enabled Catalog/Registry Service

• Add-on Ontology– Adding an ontology layer on top of the ogcRIM to

support semantic matching.– Assuming that the output of a geospatial service is a

Geo-Object Go and the request is R, the “flexible semantic matching” can be

• exact, if Go = R, then Go and R are exact equivalent; • plug in, if Go subsumes R than Go could be plugged in place of

R; • subsume, if R subsumes Go, then Go just completes part of R

and R needs other Go to implement the other part of R or whole R;

• fail, there is no relationship between Go and R.

LAITS


“Geo-Tree” Composition

• Composition Process① Finding a “Geo-Object” in the archive that matches the user Geo-Object R

through the catalog/registry service.

② If “yes”, let such one be R. If not, do step 3.

③ Find a service Si that can create such a “Geo-Object”. If not, the requested “Geo-Object” cannot be produced.

④ If “yes”, plug the service into the “Geo-Tree” and instantiate its inputs, outputs, preconditions and effects based on domain knowledge.

⑤ Lets assume the service Si requires n “Geo-Obejct” inputs, labeled as I1, I2, .. In. Check if all inputs of Si are available. If an input In is not already available, go to step 3.

⑥ Iterate the above process until all inputs are available.

LAITS


Steps for getting user’s query answered

① User queries the system using natural language.② The system converts the query into a formal description of

the user geo-object R.③ Find a “Geo-Object” in archives that matches the user Geo-

Object R through the catalog/registry service. ④ If “yes”, answer to users query is pre-exist. Return the

answer to the user. If not, do step 5. ⑤ Find a service Si that can create such a “Geo-Object”. If

not, the requested “ User Geo-Object” cannot be produced. ⑥ If “yes”, plug the service into the “Geo-Tree” and instantiate

its inputs, outputs, preconditions and effects based on domain knowledge.

⑦ Lets assume the service Si requires n “Geo-Obejct” inputs, labeled as I1, I2, .. In. Check if all inputs of Si are available. If an input In is not already available, go to step 5.

⑧ Iterate the above process until all inputs are available.⑨ Execute the Geo-tree to create the product for the user.

LAITS


Implementation Architecture

LAITS


Providing an overall knowledge about the system and answering relevant queries.

Implementation Architecture

Intelligent user interface that assists the user in formulating queries and results

Providing semantic “match-making”

Producing a “Geo-Tree” using AI planning Algorithm

Translating a abstract workflow into a concrete execution plan.

Wrapping the underlying atomic or composite geospatial services and advertises their capabilities

LAITS


Natural Language Query

Ask a Geosptial Question using the English Language

What is the possibility of landslide in the Dimond Canyon, California, United States on January 10, 2005?

LAITS


Parse the Question using Components from Snark *

Understanding the query

* Snark is developed by SRI, http://www.ai.sri.com/tutorial.html (Stickel, Waldinger, Chaudhri)

LAITS


Form the user geo-object described by XML

Derive standard XML Description from the Snark Parsing Results

LAITS


Construction of Geo-Tree/Service Chain

Construct Composite Service Model in OWL-S

LAITS


Execution of the Chain to Obtain Answer

Execute the Composite Model and Obtain the Answer

LAITS


Automatic Modeling Process (6)

The Resultant Landslide Susceptibility Map

LAITS


RedImage

LandslideSusceptibility

Slope Aspect NDVILandcover

(WICS)

NIRImageTrainingImage

ETMImageDEM

Training(WICS)

WCS

DEM DEM

Slope

SlopeAspect

Aspect

Landcover

Landcover

NDVI

NDVI

TrainingParameter

TrainingParameter ETMImage

NIRImage REDImage

LandslideSusceptibility

TrainingImage

ETMImage

The Data and Service Involved in this Example

LAITS


Data Type Definition Based on GCMD Science Theme

LAITS


Service Type Definition Based on GCMD Service Types

LAITS


The OWL-S Engine Architecture

Semantic Schema: ServiceType, DataType, Association OWL-S library: OWL-Ss for Available Services Registry: Catalog Service for Web Reasoning/Matching: ServiceType, DataType OWL-S Manager: OWLSPower

LAITS


The OWL-S Match Flow

Data type driven reasoning currently implemented Reasoning process facilitated by ServiceType/DataType associations Four types of matches implemented: exact, subsume, relaxed, and all

LAITS


Automatic Service Chaining

Resultant service chain managed in two approaches: OWL-S engine and BPEL engine

LAITS


Three major components in the XML:

1. Temporal information: Convert Snark temporal keywords to the UTC format as noted in http://www.w3.org/TR/NOTE-datatime.

2. Spatial information: Derive latitude and longitude bounding box from Alexandria Digital Library (ADL)* Gazetteer Protocol.

3. Object ontology: Combine Wordnet* with OWL GeoData description to generate ontology-represented GeoObject.

http://www.laits.gmu.edu:8099/QuestionProcess/nl/nl_index.jsp

Convert User Question to XML

* ADL is developed by a project team headquartered at University of California at Santa Barbara**WordNet is developed by the Cognitive Science Laboratory at the Princeton University

LAITS


Convert User Question to XML (Cont.)

Temporal Information

LAITS


Spatial Information


LAITS


Ontology Information


LAITS



The resultant XML description is ready to be submitted to the chaining process

LAITS


Automatic Process Composition

LAITS


Results to Answer User’s Query

The answer to the user question is a landslide susceptibility map of the area and time concerned.

LAITS


The OWL-S Manager

OWL-S file management: Set data/service ontology Set association DataType and ServiceType match Exact Subsume Relaxed All Composite service chain construction

LAITS


Register Data and Service OWL

OWL schema can be registered either using URLs or typing/pasting the files directly.

LAITS


OWL-S can be registered either using URLs or typing/pasting the files directly.

Deploy OWL-S

LAITS


Manipulate Deployed OWL-S

The deployed OWL-Ss can be viewed using the GetCapabilities function. OWL-Ss can be undeployed using the UnDeploy function

LAITS


Manipulate Deployed OWL-S (Cont.)

Add associations between service type and data type to facilitate the reasoning.

LAITS


OWL-S to BPEL Conversion

There are two ways to execute the composite service process, through the OWLSPower engine or the BPELPower engine. Both engines are developed in LAITS.

The following is the OWL-S to BPEL conversion page.

LAITS


Screen shot of OWL-S converted BPEL

OWL-S to BPEL Conversion (Cont.)

LAITS


Screen shot of WSDL

OWL-S to BPEL Conversion (Cont.)

LAITS


Manage BPEL in PBELPower

The BPEL converted from OWL-S can be deployed, managed, and executed in BPELPower

LAITS


The DEMtoSlope Service Process

The diagram shows the activities of the Slope service BPEL process, converted from OWL-S, deployed in BPELPower.

LAITS


The DEMtoSlope Service Process (Cont.)

The full diagram view the activities of the Slope service BPEL process, converted from OWL-S, deployed in BPELPower.

ontology-driven automatic web service composition for geoscience automation

Documents