ontology aware software service agents: meeting ordinary user needs on the semantic web

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 ServiceAccess to the National Digital Forecast Database

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

Know how to use it

Communicate: keep the communication until the service responds

Coupling problem



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

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature

MaximumTemperaturePercentChanceOfPrecipitation

WeatherReport Formathas

is forstarts onis for

is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

Domain Ontology

8

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

Domain Ontology

Formal predicates: object sets, relationship sets, & constraints

WeatherReport(x) is for Latitude(y)

NumDays(x)

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

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

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

@create

initialize ready

@service-request-view complete

service-request-view, unsatisified-constraints = satisfy-contraints(service-request-view, service-request-constraints)

constraint satisfaction checked

service-request-view complete

missing information

service-request-view = get-from-system(service-request-view) if (still missing values) service-request-view = get-from-user(service-request-view)

no missing information

unique satisfaction found

schedule-appointment(...)report that the appointment is scheduled

unique satisfaction not found

report that the appointment cannot be scheduled negotiation complete

@negotiation required

service-request-view = negotiate(service-request-view, unsatisfied contraints)

no constraint satisfaction

negotiation required

multiple constraints satisfaction possibilities

unique constraint satisfaction

initial service-request-view ready

@process-ontology(domain-ontology)

service-request-view = create-service-request-view(domain-ontology)service-request-constraints = create-service-request-constraints(service-request-view)

@create

initialize ready

@service-request-view complete

service-request-view, unsatisified-constraints = satisfy-contraints(service-request-view, service-request-constraints)

constraint satisfaction checked

service-request-view complete

missing information

service-request-view = get-from-system(service-request-view) if (still missing values) service-request-view = get-from-user(service-request-view)

no missing information

unique satisfaction found

schedule-appointment(...)report that the appointment is scheduled

unique satisfaction not found

report that the appointment cannot be scheduled negotiation complete

@negotiation required

service-request-view = negotiate(service-request-view, unsatisfied contraints)

no constraint satisfaction

negotiation required

multiple constraints satisfaction possibilities

unique constraint satisfaction

initial service-request-view ready

@process-ontology(domain-ontology)

service-request-view = create-service-request-view(domain-ontology)service-request-constraints = create-service-request-constraints(service-request-view)

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

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in


13


City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in


WeatherReport … text representation: weather\s+forecast|…

14


City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in


Longitude ... getLongitude(x1:State, x2:City) returns (Longitude)

15


City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in


StartDate ... NrDaysBetween(x1:StartDate, x2:EndDate) returns (NumDays) context keywords/phrases: between the \s+{x1}\s+and\s+{x2} | ...

16


City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in


Format … Default value: “24 Hourly” …

17


City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in

City

State

EndDate

StartDate

NumDays

Place

Longitude

ZipCode

Latitude

ReportPeriod

MinimumTemperature




is for ->

produces

has has

has

identify

is for

identify

determine

is in


18

Generated Rel. Calculus Query

{ < 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) }

What’s the weather forecast for Springfield, Illinois, between the 21st and 24th?

19

Service Request Result

20

Weather Service Demo

http://www.deg.byu.edu/demos/SerFR.demo/TWebServiceJars/TWSMain.JNLP

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

Solution Make Model Price Year Mileage

S1 Dodge Stratus 9,451.00 2004 35,808

S2 Dodge Stratus 14,995.00 2005 1,694

S3 Dodge Stratus 14,999.00 2005 27,543

S4 Dodge Stratus 2,555.00 1997 115,424

S5 Dodge Stratus 6,900.00 2001 70,000

…

…

S168 Dodge Stratus 9,975.00 2003 34,060

www.cars.com, November 2005

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

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

• 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

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

• 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

Near Solution Make Mileage Price Year

S1 Dodge 100,000 $3,850 2000

S2 Dodge 78,000 $4,100 2000

Near Solution Make=dodge

exp.= 0.9

Mileage<80,000

exp.= 0.8

Price<=$4,000

exp.= 0.85

Year>=2000

exp.= 0.5

exp. plty.

S1 0.00 1.00 1.00 0.00 0.80

S2 0.00 0.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

Free-form Ontology-Based Web Service Demo

http://www.deg.byu.edu/

http://www.deg.byu.edu/demos/SerFR.demo/DEMOweaws/SerFR.JNLP

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 ArgumentsAppointment 10 126 34Car 15 315 98Apartment 6 107 38Totals 31 548 170

35

Results: Constraint Recognition

Recall PrecisionAppointment predicates 0.98 1.00

arguments 0.94 1.00Car predicates 0.99 0.99

arguments 0.98 0.99Apartment predicates 0.97 1.00

arguments 0.92 1.00All predicates 0.98 0.99

arguments 0.95 0.99

36






arguments 0.95 0.99

e.g. missed:

“any Monday of this month” “most days of the week”

“a nook” “extra storage”

37






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

• 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

(appointment domain)

0

0.20.4

0.60.8

11.2

1 3 5 7 9 11 13 15 17 19

The near solutions

% o

f su

bje

cts

wh

o c

ho

se a

nea

r

solu

tio

nsystem

human

Results: Constraint Resolution

Observer-agreement test: = 0. 74 (“substantial agreement”)

40

0

0.2

0.4

0.6

0.8

1

1.2

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31

The solutions

% o

f sub

ject

s w

ho c

hose

a s

olut

ion

System

Human

(car-purchase domain)

Results: Constraint Resolution

Observer-agreement test: = 0.67 (“substantial agreement”)

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

Agre

e

Stro

ngly

agr

ee

Stro

ngly

dis

agre

e

Disa

gree

Neu

tral

0

1

2

3

4

5

6

7

choi

ce fr

eque

ncy

Regular specification Advanced 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

Excell

ent

Satisfa

ctory

Not us

eful

Good

0

1

2

3

4

5

6

choi

ce fr

eque

ncy

Constraint elicitation suggestions Constraint relaxation suggestions

44

Results: Solution and Near Solution Ordering

Excell

ent

Good

Not us

eful

0

1

2

3

4

5

6

7

choi

ce fr

eque

ncy

Solution ordering Near solution ordering

45

Results: System Usefulness

The system usefulness

Not he

lpfu

lSomew

hat h

elpfu

l

Helpfu

l

Extrem

ely he

lpfu

l

0

1

2

3

4

5

choi

ce fr

eque

ncy

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

ontology aware software service agents: meeting ordinary user needs on the semantic web

Documents

s ands

service specificationwhats

requeststhe service

format default value

integer default value

dd default value

conceptits internal

web serviceswhat