Ontology Aware Software Service Agents: Meeting Ordinary User Needs on the Semantic Web

1. Ontology Aware Software Service Agents: Meeting Ordinary User Needs on the Semantic Web Muhammed J. Al-Muhammed Brigham Young University Supported by: July 23, 2007

2. A Challenge for Semantic Web Services • Help users find and use services • Reduce requirements for service specification What’s the weather forecast for Springfield, Illinois, between the 24th and 27th?

3. Weather Forecasting Service Access to the National Digital Forecast Database

4. Know how to use it 39.78 -89.66 2007-04-21 4 Problems with Web Services Access to the National Digital Forecast Database Discover the required service Coupling problem Communicate: keep the communication until the service responds What is the weather forecast for Springfield, Illinois, between the 24th and 27th? What is the weather forecast for Springfield, Illinois, between the 24th and 27th? What is the weather forecast for Springfield, Illinois, between the 24th and 27th? Data heterogeneity problem

5. Better: Invoke Services only by Specifying Requests The service recognizes constraints And services the request

6. Resolution: Ontology-Based Web Services • Domain ontology • Declares concepts, relationships, and constraints • Has a central concept of interest • Has extensional recognizers • Process ontology • Matches a request with a domain ontology • Obtains information (from DB and from user) • Satisfies constraints • Negotiates (if necessary)

7. Domain Ontology

8. Domain Ontology Formal predicates: object sets,relationship sets,& constraints NumDays(x) WeatherReport(x) is for Latitude(y) x(WeatherReport(x)  1y(WeatherReport(x) is for Latitude(y))

9. Extensional Semantics • Ontology augmented with data frames • A data frame specifies semantics for a concept • Its internal and external representation • Its contextual keywords or phrases • Operations along with contextual keywords or phrases

10. Data Frames NumDays internal representation: integer default value: (1) … Data frames: instance recognition; operation recognition StartDate internal representation: date -- format yyyy-mm-dd default value: (today) text representation: {monthName}\s+([0]?[1-9] | [12]\d|3[01])(\s*\,)?\s+\d{4} | (the\s+)?([0]?[1-9] | [12]\d|3[01])\s*(th|...)|... toInternalRepresentation(x:string) returns (StartDate) NrDaysBetween(x1:StartDate, x2:EndDate) returns (NumDays) context keywords/phrases: between the \s+{x1}\s+and\s+{x2} | ...

11. Process Ontology • Create service-request view • Generate constraints • Obtain information • From system • From user • Satisfy constraints • Negotiate • Finalize service request

12. Ontology-Based Constraint Recognition What’s the weather forecast for Springfield, Illinois, between the 24th and 27th?

13. Ontology-Based Constraint Recognition WeatherReport … text representation: weather\s+forecast|…  What’s the weather forecast for Springfield, Illinois, between the 24th and 27th?

14. Ontology-Based Constraint Recognition Longitude ... getLongitude(x1:State, x2:City) returns (Longitude)       What’s the weather forecast for Springfield, Illinois, between the 24th and 27th?

15. Ontology-Based Constraint Recognition StartDate ... NrDaysBetween(x1:StartDate, x2:EndDate) returns (NumDays) context keywords/phrases: between the \s+{x1}\s+and\s+{x2} | ...          What’s the weather forecast for Springfield, Illinois, between the 24th and 27th?

16. Ontology-Based Constraint Recognition      Format … Default value: “24 Hourly” …      What’s the weather forecast for Springfield, Illinois, between the 24th and 27th?

17. Ontology-Based Constraint Recognition               What’s the weather forecast for Springfield, Illinois, between the 24th and 27th?

18. Generated Rel. Calculus Query What’s the weather forecast for Springfield, Illinois, between the 21st and 24th? • { <x2, x3, x4> | • WeatherReport(x0) is for Latitude(getLatitude(“Illinois”, “Springfield”)) • WeatherReport(x0) is for Longitude(getLongitude(“Illinois”, “Springfield”)) • WeatherReport(x0) starts on StartDate(NextDate(“24th”)) • WeatherReport(x0) is for NumDays(NrDaysBetween(NextDate(“24th”), NextDate(“27th”))) • WeatherReport(x0) has Format(“24 Hourly”) • WeatherReport(x0) produces ReportPeriod(x1) • ReportPeriod(x1) has MaximumTemperature(x2) • ReportPeriod(x1) has MinimumTemperature(x3) • ReportPeriod(x1) has PercentChanceOfPrecipitation(x4) }

19. Service Request Result

20. Weather Service Demo Demo

21. Too Many Cars “I want a dodge, a 2000 or newer. The Mileage should be less than80,000 and the price shouldnotexceed$15,000.” www.cars.com, November 2005

22. No Car “I want a dodge, a2000 or newer. The Mileage should be less than 80,000 and the price should not exceed $4,000.” www.cars.com, November 2005

23. Constraint Satisfaction • Exactly one solution: return it as the result • A few solutions: return all and ask the user to select one • Too many solutions: resolve • No solution: resolve

24. Key Observations • Some (near) solutions are better than others • People specify constraints on some concepts in a domain more often than on other concepts

25. Fundamental Concepts:Reward, Penalty, and Expectation • Reward: non-negative real number denoting a degree of satisfaction • Penalty: negative real number denoting a degree of violation • Expectation: probability of specifying a constraint on a concept

26. Fundamental Concepts:Pareto Optimality • Based on dominance relations • The reward for S1 is as high as the reward for S2 • For at least one reward S1 has a higher reward • Dominating solutions are Pareto optimal

27. Too Many Solutions:Reward-Based Ordering • Calculate rewards and combine them • Order solutions, highest combined reward first • Select the top-m Pareto optimal solutions

28. Too Many Solutions: Expectation-Based Constraint Elicitation • Associate expectations with domain concepts • Order the concepts in a domain based on their expectations • Example: make > price > model > … • Elicit additional constraints over unconstrained concepts • Example: if no preferred make provided, ask for make; if no price, ask for price; …

29. No Solution: Penalty-Based Ordering • Calculate penalties and combine them • Order near solutions, lowest combined penalty first • Select the top-m Pareto optimal near solutions

30. No Solution: Expectation-Based Constraint Relaxation • Associate expectations with constraints • Order constraints based on their expectation, lowest expectation first • Trade-off: amount of violation vs. expectation

31. No Solution: Expectation-Based Constraint Relaxation “I want a dodge, a 2000 or newer. The Mileage should be less than 80,000 and the price should not exceed $4,000.” Can this constraint “shouldnotexceed$4,000” be relaxed to “$4,100”?

32. Free-form Ontology-Based Web Service Demo Demo Demo

33. Experiments • Constraint recognition • Constraint resolution • Solution ordering • Near solution ordering • System usability

34. Experiment: Constraint Recognition • Subjects: BYU students • Domains: • Appointment scheduling • Car purchase • Apartment rental • Requests: Requests Predicates Arguments Appointment 10 126 34 Car 15 315 98 Apartment 6 107 38 Totals 31 548 170

35. Results: Constraint Recognition Recall Precision Appointment predicates 0.98 1.00 arguments 0.94 1.00 Car predicates 0.99 0.99 arguments 0.98 0.99 Apartment predicates 0.97 1.00 arguments 0.92 1.00 All predicates 0.98 0.99 arguments 0.95 0.99

36. Results: Constraint Recognition Recall Precision Appointment predicates 0.98 1.00 arguments 0.94 1.00 Car predicates 0.99 0.99 arguments 0.98 0.99 Apartment predicates 0.97 1.00 arguments 0.92 1.00 All predicates 0.98 0.99 arguments 0.95 0.99 e.g. missed: “any Monday of this month” “most days of the week” “a nook” “extra storage”

37. Results: Constraint Recognition Recall Precision Appointment predicates 0.98 1.00 arguments 0.94 1.00 Car predicates 0.99 0.99 arguments 0.98 0.99 Apartment predicates 0.97 1.00 arguments 0.92 1.00 All predicates 0.98 0.99 arguments 0.95 0.99 e.g. missed: “I want a Toyota with a cheap price, 2000 would be great …” The system incorrectly concluded that “2000” was a price.

38. Experiment: Constraint Resolution • Tested appointment and car-purchase domains • 16 human subjects • The best-5 near solutions from 19 appointments • The best-5 solutions from 32 cars • Compared human selection with system selection

39. Results: Constraint Resolution (appointment domain)  = 0. 74 (“substantial agreement”) Observer-agreement test:

40. Results: Constraint Resolution (car-purchase domain)  = 0.67 (“substantial agreement”) Observer-agreement test:

41. Experiment: System Usability • 12 subjects: 8 in the senior-database class and 4 in the master’s program • Evaluated functionalities • Regular specification (only AND constraints) • Advanced specification (AND, OR, & Negation) • Constraint elicitation suggestions • Constraint relaxation suggestions • Best-k solutions • Best-k near solutions • Usefulness of the system

42. Results: Request Specification Regular specification is enough to specify all my requests. Without disjunctions and negations I was not able to specify my requests

43. Results:Constraint Elicitation and Relaxation

44. Results:Solution and Near Solution Ordering

45. Results:System Usefulness

46. Contributions • Free-form service specification • Effective constraint resolution • Knowledge-based service creation • Only static knowledge • No code required • Ontology-based web services • Service decoupling resolution • Data heterogeneity resolution • Fully working prototypes

47. Future Work • Conditional constraints Example: if the appointment can be scheduled this week, schedule with Dr. Carter; otherwise schedule with Dr. Adams • Composite service requests Example: coordinated multi-ontology instantiations (vacation planning) • Trust: predictability, transparency, etc. • Security: secure information exchange