Ontology Mapping for Dynamic Service Invocation on the Semantic Web Mark H. Burstein BBN Technologies In collaboration with Drew McDermott, Yale University

2 Outline Motivation –Dynamic Invocation of Semantic Web Services that potentially using different ontologies than requester Review of DAML-S/OWL-S approach to process model descriptions for services Different roles of ontology mapping and translation in supporting interoperability Processes –Request Generation, Result Interpretation, Discovery Example: Translation during request planning Conclusions

3 Dynamic Semantic Web Services Problem: Current Web Service clients must still be programmed by people to interact with each new service –UDDI does not enable software clients to find services in terms of their inputs, outputs, preconditions, effects, other constraints –WSDL descriptions do not contain enough information about what are the semantics of service inputs, outputs In order to dynamically invoke and compose services, service clients must be able to automatically –Find services having the desired effects, given inputs the client can provide –Reason about which information the client possesses is required in messages to the service, and provide it in the appropriate forms. –Interpret translate responses from these previously unfamiliar services

4 Courtesy of Mike Uschold, Boeing, Michael Gruninger, NIST Community Ontologies and Mappings Ontology designers generate alignment mappings between existing community ontologies Agent designers compose ontologies using these mappings Agent-agent mappings generated automatically at agent interaction time Mediated via community ontologies

5 Reasons for Ontology Mapping and Translation Services developed by different people or organizations will use multiple different ontologies (some of their own making) Clients developed for their own general purposes will use still different ontologies, and be unaware of the ontologies of some potentially useful services. To the extent that mappings between ontologies are described and published along with the ontologies, they can be used to translate service advertisements, process descriptions and message contents so that services can be discovered and used automatically. –Mappings between ontologies used by whole communities will enable broad-based interaction. –Other ontologies can be widely shared through publication on the semantic web.

6 OWL-S Upper Ontology Semantics for UDDI search Relationship to WSDL Semantics for BPEL&WSDL

7 Basic Usage Model for OWL-S Requesting Agent A Service Provider B OWL-S Matchmaker 1. Advertise(ServiceProfile B ) 2. ProfileQuery (Profile pattern for Goal A ) 3. Returns Match Candidates (Profiles w. Service Model URIs) WorldWideWeb Publish ServiceModel B Get ServiceModel B 4. Send Request (Goal or Query) grounded as msg 5. Interpret Reply (Outcome or Answer) using grounding to map to OWL description ServiceModel B Ontology O B Ontology O A OWL-S Ontology O O uses Dynamic Discovery Process

8 Process Model based on AI Planning Operators Input: confirmation no.... Output: failure notification … flight available + valid credit card Y N ? Preconditions: customer name flight number credit card... BookFlight service knowledge of the input own credit card... ticket purchased credit card debited... Effect: Output: Effect:

9 Data Flow Relations among Process Parameters, Groundings If know (?self (has-pwd ?self ?server ?acctname ?pwd)) Then Send(?self ?server (RequestLogin ?acctname ?pwd)) Else Send (?self ?server (RequestLogin Anonymous)) Login Process Parameters: Requester Provider AcctName Pwd If (OK-pwd AcctName Pwd)) Then Send(Provider Requester (LoginOK AcctName)) Else (NOT –above-) Send (Provider Requester (LoginFailed AcctName)) input output RequestLogin WSDL Grounding LoginOK WSDL Grounding CLIENT Environment Receive (LoginOK AcctName) (OK-pwd …) (has-pwd self AMAZON-SVC mark abc123)) Bind Parameters Server Environment

10 Approach to Ontology Mappings O C1 O Shared O C2 O2O2 O S1 Client Merged Ontology M C2-S1 -Mappings defined as published first- order axioms -Translation by forward/backward chaining to find assertions in the target ontology (Dou, McDermott, Qi 2003, 2003)

11 When/Where to do Translation? In general, may be done by client, server or middle agent. Knowledge locality (privacy, ownership) and efficiency can play key roles in the architectural design decisions Key distinction between translation to supporet request formulation and statement translation (e.g. for responses) in terms of where the additional local knowledge required might come from.

12 Translation for Dynamic Service Invocation Translation during discovery –Ontologies used for advertising Translation during request formulation –Based on published process models of inputs, effects Translation during response interpretation –After mapping from grounding to semantic description of output (in servers ontology)

13 Translation Reasoning for a Book Buying Request Mystuff BooksSales Book ~>~ Item (qty 1) Book.name ==Item.title Book.by ==Item.author XML for Dummies Fat Parens 9999 Books4Sale.com

14 Whose job is request translation? Formulation of service requests based on published service descriptions is dependent on the clients knowledge and planning process. –Relationship between client goal and service effects –Relationship between service inputs and facts (known to client) that are not associated with client goal. Difference between translation of client goal and well- formed request – The latter cannot be formed without client first understanding what information is required. Using published mappings, most straightforward approach is for client to translate/formulate internal queries based on process model. Alternative: Mediator could translate (key pieces of) service process model, enabling client to formulate proper request, then translate that back to service ontology so that grounding can be applied.

15 Whose job is response translation? Commonly done by intermediaries (middle agents). –Translation of a well-formulated response to a known (set of) ontologies. –Could be done by client or server as well. But problems can arise when: –Target (client) ontology cannot express all of the content and client cannot import and reason with the ontology of the service provider

16 Whose job is Matchmaker Query Translation? Service advertisement repository may utilize unlimited number of ontologies –All ontologies referenced by services in advertisements published If client (or intermediary) did the translation, would have to do it for each potential match candidate (advert). Translation is part of the matching process. Client OWL-S Matchmaker Profile1 uses Ontology1 Profile2 uses Ontology2 Profile3 uses Ontology3 … Profile pattern - Goal - Input Constraints - QoS Constraints

17 Conclusions Translation locality is often dictated by the reasoning processes of agents. –Localized knowledge (in objects/agents) leads to need for co-located translation functionality. Ontology mappings need to be published on the semantic web along with ontologies. –Since translation cannot be done solely by middle agents that own the mappings.

18 Questions?

19 Semantic Web Services Initiative Joint US/EU effort. –Executive Committee (D.Fensel, K. Sycara, co-chairs) –Language Committee (D. Martin, M. Kiefer) SWSL website at –Architecture Committee (M. Burstein, C. Bussler) SWSA website at Wanted: Interesting SWS Use Cases –Subscribe and/or to:

20 OWL-S: An OWL Ontology for Describing the Use of SW Services Developed by the DAML-S Consortium (BBN, CMU, Nokia Research, Stanford U., SRI, Yale U.) –Papers and descriptions at Current version (1.0) now uses OWL, a W3C Candidate Recommendation based on DAML+OIL. Three major components: –Profile: a language for describing service advertisements and query patterns –Service Process Model: ontology for processes, inputs, outputs, preconditions, effects, data and process flow. –Grounding: describes mapping between atomic processes and transport (message) formats – primarily WSDL, but several others.