Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Ontology Aware Software Service Agents: Meeting Ordinary User Needs on the Semantic Web Muhammed J. Al-Muhammed Brigham Young University Supported by:"— Presentation transcript:

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 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 3 Weather Forecasting Service Access to the National Digital Forecast Database

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

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

6 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 7 Domain Ontology

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

9 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 10 Data Frames 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} |... NumDays internal representation: integer default value: (1) …

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

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

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

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

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

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

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

18 18 Generated Rel. Calculus Query { | WeatherReport(x 0 ) is for Latitude(getLatitude(“Illinois”, “Springfield”))  WeatherReport(x 0 ) is for Longitude(getLongitude(“Illinois”, “Springfield”))  WeatherReport(x 0 ) starts on StartDate(NextDate(“24th”))  WeatherReport(x 0 ) is for NumDays(NrDaysBetween(NextDate(“24th”), NextDate(“27th”)))  WeatherReport(x 0 ) has Format(“24 Hourly”)  WeatherReport(x 0 ) produces ReportPeriod(x 1 )  ReportPeriod(x 1 ) has MaximumTemperature(x 2 )  ReportPeriod(x 1 ) has MinimumTemperature(x 3 )  ReportPeriod(x 1 ) has PercentChanceOfPrecipitation(x 4 ) } What’s the weather forecast for Springfield, Illinois, between the 21st and 24th?

19 19 Service Request Result

20 20 Weather Service Demo

21 21 Too Many Cars “I want a dodge, a 2000 or newer. The Mileage should be less than 80,000 and the price should not exceed $15,000.” SolutionMakeModelPriceYearMileage S1DodgeStratus9,451.002004 35,808 S2DodgeStratus14,995.002005 1,694 S3DodgeStratus14,999.002005 27,543 S4DodgeStratus2,555.001997115,424 S5DodgeStratus6,900.002001 70,000 … … S168DodgeStratus9,975.00200334,060 www.cars.com, November 2005

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

23 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 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 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 26 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 Fundamental Concepts: Pareto Optimality

27 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 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 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 30 Associate expectations with constraints Order constraints based on their expectation, lowest expectation first Trade-off: amount of violation vs. expectation No Solution: Expectation-Based Constraint Relaxation

31 31 Near SolutionMakeMileagePriceYear S1Dodge100,000$3,8502000 S2Dodge78,000$4,1002000 Near SolutionMake=dodge exp.= 0.9 Mileage<80,000 exp.= 0.8 Price<=$4,000 exp.= 0.85 Year>=2000 exp.= 0.5  exp.  plty. S10.00  1.00 1.000.00  0.80 S20.000.10  0.66 0.00  0.56 “I want a dodge, a 2000 or newer. The Mileage should be less than 80,000 and the price should not exceed $4,000.” No Solution: Expectation-Based Constraint Relaxation Can this constraint “should not exceed $4,000” be relaxed to “$4,100”?

32 32 Free-form Ontology-Based Web Service Demo

33 33 Experiments Constraint recognition Constraint resolution –Solution ordering –Near solution ordering System usability

34 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 35 Results: Constraint Recognition RecallPrecision Appointmentpredicates 0.98 1.00 arguments 0.94 1.00 Carpredicates 0.99 0.99 arguments 0.98 0.99 Apartmentpredicates 0.97 1.00 arguments 0.92 1.00 Allpredicates 0.98 0.99 arguments 0.95 0.99

36 36 Results: Constraint Recognition RecallPrecision Appointmentpredicates 0.98 1.00 arguments 0.94 1.00 Carpredicates 0.99 0.99 arguments 0.98 0.99 Apartmentpredicates 0.97 1.00 arguments 0.92 1.00 Allpredicates 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 37 Results: Constraint Recognition RecallPrecision Appointmentpredicates 0.98 1.00 arguments 0.94 1.00 Carpredicates 0.99 0.99 arguments 0.98 0.99 Apartmentpredicates 0.97 1.00 arguments 0.92 1.00 Allpredicates 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 38 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 Experiment: Constraint Resolution

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

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

41 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 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 43 Results: Constraint Elicitation and Relaxation

44 44 Results: Solution and Near Solution Ordering

45 45 Results: System Usefulness

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


Download ppt "Ontology Aware Software Service Agents: Meeting Ordinary User Needs on the Semantic Web Muhammed J. Al-Muhammed Brigham Young University Supported by:"

Similar presentations


Ads by Google