1. MTA SZTAKI Department of Distributed Systems Two-phase Semantic Web Service Discovery Method for Finding Intersection Matches using Logic Programming László Kovács András Micsik Péter Pallinger

2. DSD Department of Distributed Systems MTA SZTAKI INFRAWEBS – General information Main project focus and objective development of an application-oriented software toolset for creating, maintaining and executing WSMO-based Semantic Web Services (SWS) within their whole life cycle Partners University of Applied Sciences, Bochum, Germany University of Innsbruck, Austria Bulgarian Academy of Science, Institute of Information Technology, Bulgaria MTA SZTAKI, Hungary National Technical University of Athens, Greece Profium SA, Finland Sirma SAI, Bulgaria FUTUREtec-GmbH, Germany Atos Origin, Spain Best-HP, Italy Aspasia Knowledge Systems, Germany big7.net GmbH, Germany

3. DSD Department of Distributed Systems MTA SZTAKI INFRAWEBS – Results INFRAWEBS Integrated Framework Graphical editors: Axiom editor (logical expressions) Semantic Web Service Editor Semantic Web Service Composer Semantic Web Service Registry Discovery engine Combines textual and logical matching Execution engine Executes the choreography state machine of the Semantic Web Service Quality of Service monitoring Security and Privacy as Artificial Immune System

4. DSD Department of Distributed Systems MTA SZTAKI Steps of discovery within INFRAWEBS Pre-filtering step Narrow list of candidates using text-processing (keyword matching) algorithms Logic-based step Perform logical matching based on precondition, assumptions, postconditions and effects Preparation of result Enhance list of matching services with QoS data based on past execution experience

5. DSD Department of Distributed Systems MTA SZTAKI Pre-filtering step Different from the WSMO idea published in D5.1, which indexes metadata and not the axioms Full text of WSML is indexed, and structural queries are supported Two options in the framework: Extract keywords and construct structural queries Use similarity search First option is considered safer for recall

6. DSD Department of Distributed Systems MTA SZTAKI Example: keyword extraction postcondition definedBy exists {?BookingIdentifier, ?FlightBookingTicket, ?FlightBookingPreferences, ?BuyerEmail, ?Class, ?NumMaxConnections} ( ?BookingIdentifier memberOf bo#bookingIdentifier and ?FlightBookingTicket memberOf fb#flightBookingTicket [ bookingTicketIdentifier hasValue ?BookingTicketIdentifier, airTripInfo hasValue ?AirTripInfo ] and ?BookingTicketIdentifier memberOf bo#bookingTicketIdentifier and ?AirTripInfo memberOf fb#airTripInfo [ start hasValue ?Start, end hasValue ?End, departure hasValue ?Departure, arrival hasValue ?Arrival ] and...

7. DSD Department of Distributed Systems MTA SZTAKI Ontologies of the use case Flight General ontologies Date & TimeLocationCustomer HotelCar rental Booking Domain ontologies Flight Bookin g Car Rental Booking Hotel Bookin g Application ontologies

8. DSD Department of Distributed Systems MTA SZTAKI Discovery models Logic-based definition of a match Set-based definitions of match types

9. DSD Department of Distributed Systems MTA SZTAKI Logic-based matching A typical goal and service capability: Goal: Ticket from Wien to Graz Ticket date 06.06.2006. Webservice: Ticket from X to Y where X and Y are in Austria Ticket issued by Austrian Air This is a trivial intersection match, but how can it be decided by a reasoner? Our approach is matching with unification: Find unifiable facts, Model the intersection, Check the goal and the webservice against the common model of intersection

10. DSD Department of Distributed Systems MTA SZTAKI Goal Web service Ticket from Wien to Graz Ticket from X to Y Ticket date 06/06/2006 X is in Austria Y is in Austria Matching, X,Y unified with Wien, Graz True for X=Wien True for Y=Graz Ticket issued by Austrian Air No contradiction

11. DSD Department of Distributed Systems MTA SZTAKI Matching algorithm Preparation Ontologies and webservices are converted from WSML to Prolog Webservices are first converted to Disjunctive Normal Form (DNF) Matching Goal is converted to DNF and then to Prolog Pair-wise unification of clauses Clauses are labeled as matched, failed, ignored Decision of match or failure

12. DSD Department of Distributed Systems MTA SZTAKI Example result of a matching Ignored clauses: Ticket issued by Austrian Air Ignored clauses: Ticket date 06/06/2006 Matched clauses: Ticket departs from Wien Ticket destination is Graz Wien is in Austria Graz is in Austria GOAL WEB SERVICE Failing clause would be: Ticket issued by Lufthansa

13. DSD Department of Distributed Systems MTA SZTAKI Evaluation of the discovery approach Benefits of the presented approach The clauses labeled as failed may give an explanation, why the match failed The clauses labeled matched and ignored provide ways to rank matched services to explain the difference between matched services It works also when various styles of capability descriptions are used together Added value of services and user preferences may be handled Drawback In some cases a heuristic decision is needed

14. DSD Department of Distributed Systems MTA SZTAKI Implementation Implemented in Java and Prolog WSML to Prolog conversion written in Java using wsmo4j Matching algorithm written in Prolog SWI-Prolog as Prolog engine Interprolog for Java to Prolog connection

15. DSD Department of Distributed Systems MTA SZTAKI Performance Estimation of algorithm cost O(k*m*N) where k and m are maximal number of clauses possible in a DNF of webservice or goal N is the number of services Response times The prolog matcher on a 1.6 GHz P4 desktop PC: 250: 1.82s (.00728s/ws) 1000: 7.47s (.00747s/ws) 4000: 32.94s (.00823s/ws) 8000: 65.63s (.00820s/ws) Overall performance perceived by the client for 250 services is between 3 and 25 seconds. There is still a bottleneck in Java-Prolog communication

16. DSD Department of Distributed Systems MTA SZTAKI Summary A two-phase approach for discovery has been presented The first phase is based on indexing the logical expressions of service capabilities The second phase is based on the unification facility of Prolog It offers new ways of support for service selection Performance is sufficient for project use case A simple user interface for experimenting and testing our discovery implementation is accessible from the project homepage: http://www.infrawebs.eu