Ontology-driven Automatic Web Service Composition for Geoscience Automation

1. Ontology-driven Automatic Web Service Composition for Geoscience Automation Liping Di Center for Spatial Information Science and Systems (CSISS) George Mason University 6301 Ivy Lane, Suite 620 Greenbelt, MD 20770 ldi@gmu.edu 301-982-0795

2. 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.

3. 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 beused easily by other people, from students to decision-makers,and be transformed easily into higher level information and knowledge.

4. 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.

5. 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

6. “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

7. Solve complex geospatial problems by using distributed geospatial services: The Geo-object and Geo-tree Concepts Without service With service Modeling and virtual data services User request User received Archived data (geo-object) User (requested) geo-object Intermediate geo-object High level services (classification, geophysical parameters, modeling, etc) Data transformation services (format transformation, reprojection, regriding, etc) Data access services (spatial/temporal/parameter subsetting, mapping, etc)

8. “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.

9. “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 chainwhere, 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

10. 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.

11. 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

12. 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.

13. 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

14. 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.

15. 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.

16. 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

17. 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.

18. “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.

19. 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.

20. Implementation Architecture

21. Implementation Architecture Wrapping the underlying atomic or composite geospatial services and advertises their capabilities Providing an overall knowledge about the system and answering relevant queries. Providing semantic “match-making” Intelligent user interface that assists the user in formulating queries and results Producing a “Geo-Tree” using AI planning Algorithm Translating a abstract workflow into a concrete execution plan.

22. 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?

23. Understanding the query Parse the Question using Components from Snark * * Snark is developed by SRI, http://www.ai.sri.com/tutorial.html (Stickel, Waldinger, Chaudhri)

24. Form the user geo-object described by XML Derive standard XML Description from the Snark Parsing Results

25. Construction of Geo-Tree/Service Chain Construct Composite Service Model in OWL-S

26. Execution of the Chain to Obtain Answer Execute the Composite Model and Obtain the Answer

27. Automatic Modeling Process (6) The Resultant Landslide Susceptibility Map

28. LandslideSusceptibility LandslideSusceptibility Slope Landcover NDVI Aspect Landcover Slope NDVI Aspect Landcover (WICS) Slope Aspect NDVI NIRImage REDImage Training Parameter DEM DEM ETMImage Training Parameter Training (WICS) Training Image ETMImage WCS Training Image DEM RedImage ETMImage NIRImage The Data and Service Involved in this Example

29. Data Type Definition Based on GCMD Science Theme

30. Service Type Definition Based on GCMD Service Types

31. 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

32. 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

33. Automatic Service Chaining Resultant service chain managed in two approaches: OWL-S engine and BPEL engine

34. Convert User Question to XML http://www.laits.gmu.edu:8099/QuestionProcess/nl/nl_index.jsp Three major components in the XML: Temporal information: Convert Snark temporal keywords to the UTC format as noted in http://www.w3.org/TR/NOTE-datatime. Spatial information: Derive latitude and longitude bounding box from Alexandria Digital Library (ADL)* Gazetteer Protocol. Object ontology: Combine Wordnet* with OWL GeoData description to generate ontology-represented GeoObject. * 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

35. Convert User Question to XML (Cont.) Temporal Information

36. Convert User Question to XML (Cont.) Spatial Information

37. Convert User Question to XML (Cont.) Ontology Information

38. Convert User Question to XML (Cont.) The resultant XML description is ready to be submitted to the chaining process

39. Automatic Process Composition

40. Results to Answer User’s Query The answer to the user question is a landslide susceptibility map of the area and time concerned.

41. 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

42. Register Data and Service OWL OWL schema can be registered either using URLs or typing/pasting the files directly.

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

44. Manipulate Deployed OWL-S The deployed OWL-Ss can be viewed using the GetCapabilities function. OWL-Ss can be undeployed using the UnDeploy function

45. Manipulate Deployed OWL-S (Cont.) Add associations between service type and data type to facilitate the reasoning.

46. 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.

47. OWL-S to BPEL Conversion (Cont.) Screen shot of OWL-S converted BPEL

48. OWL-S to BPEL Conversion (Cont.) Screen shot of WSDL

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

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