Combining AI Planning and Description Logic Reasoning for Composition of Web Services

1
Combining AI Planning and Description Logic
Reasoning for Composition of Web Services

• Evren Sirin
• MINDSWAP Research Group
• University of Maryland, College Park

2
Web Services
AI Planning
This Talk
My Research
Ontologies Description Logics
3
Overview

• Motivation and background
• Composition of Web Services
• Interactive composition
• Semi-automated composition
• Automated composition
• Template-based composition HTN-DL formalism
• Combination of HTN planning with OWL-DL reasoning
• Optimizations of DL reasoning
• Pellet OWL-DL reasoner
• Information-gathering during planning
• ENQUIRER algorithm
• System implementation

4
Web Service Composition Examples

• Web Users
• Make the travel arrangements for a conference
• Buy all the DVDs in Star Wars series
• Arrange doctor and hospital appointments for my
  mother
• Pervasive computing
• E-mail my presentation to all the people in the
  conference room and project it on the screen
• B2B Applications
• Purchase the items from suppliers that satisfy
  and arrange the shipment so that delivery will
  be done in days without exceeding the cost
  limit
• Grid computing
• Retrieve the DNA data about apply the tests
  and create an output in format

5
Web Services

• Programs on the Web
• Published, located, invoked across the Web
• Self-contained and self-describing applications
• Platform and language independent
• Provide interoperability between diverse
  applications
• Loose coupling between components
• Dynamic and flexible applications
• Service Oriented Architecture (SOA)

6
Semantic Web Services

• Semantic annotations to automate
• Discovery, composition, execution,
• Several different languages
• OWL-S, WSDL-S, WSMO, FLOWS,
• Some common characteristics
• Describe service categorization
• Describe parameter types using ontologies
• Web Service causes a state transition
• Describe preconditions and effects on states

7
Interactive Composition

• Semi-automated and mixed-initiative
• Guide users to build compositions
• Present matching services
• Based on parameter types
• Ontology mapping services to improve matching
• Filter possibilities
• Service categorization
• Filtering forms based on ontologies
• Fujitsu Task Computing Environment
• Pervasive devices

8
Saving Compositions
Generating Compositions
9
Saved Compositions

• Compositions saved as an OWL-S process
• Composite process
• Works as any other service
• Can be discovered, composed, executed
• Shared between different parties
• Reuse previous compositions
• No need to rebuild
• But how flexible?
• What if one service is not available any more?
• What if my preferences change?

10
Template-based Composition

• Composite processes as templates
• Describe standard operating procedures
• Encode different execution paths
• Non-deterministic choice operator
• Standard operating procedures
• Encode domain knowledge
• Enforce policies and constraints
• Re-usable generic templates
• Configure and customize with respect to current
  requirements

11
HTN Planning

• Hierarchical Task Network (HTN) planning
• Planning with tasks
• Tasks Objectives that need to be achieved
• BuyPlaneTicket(DCA, NRT)
• Operators Methods Describe how to achieve
  tasks
• OrbitzFlight(From, To)
• Analogy with Web Services
• Operator ? Atomic Service
• Method ? Composite Service
• Methods decompose a task into subtasks
• Find an executable decomposition

12
Composition as HTN Planning
travel(UMD,Chiba)
buyTicket(DCA,NRT) travel(UMD,DCA) fly(DCA,NRT
) travel(NRT, Chiba)
buyTicket(DCA,NRT) travel(UMD,DCA) fly(DCA,NRT) tr
avel(NRT, Chiba)
travel(X,Y)
getTaxi(UMD) rideTaxi(UMD,DCA) payDriver
Methods
Travel by taxi
short-distance travel
Preconditions
buyTicket(NRT, Chiba) rideTrain(NRT, Chiba)
Travel by air
getTaxi(X)
rideTaxi(X,Y)
payDriver
long-distance travel
Subtasks
buyTicket(Ax,Ay)
travel(Ay,Y)
fly(Ax,Ay)
travel(X,Ax)
13
HTN for Web Service Composition

• Translate service-composition problems into HTN
  planning problems
• Translate OWL-S control constructs to HTN methods
• Sequence, Choice, If-Then-Else, Repeat, etc
• Correctness proven with respect to situation
  calculus semantics of OWL-S

14
Shortcomings of HTN

• Task matching based on names
• Not applicable in the Web context
• Matchmaking based on WS names is not desired
• Primitive and compound tasks are disjoint
• Same objective can be achieved by an atomic or
  composite service
• Limited expressivity for state of the world
• We would like to use ontologies to describe
  states

15
HTN-DL

• Combine HTN planning with OWL(-DL) ontologies
• Overcomes the previous shortcomings
• Liberalized task selection mechanism
• Matching done by an OWL reasoner
• Ranking based on preferences
• State as OWL knowledge base
• Precondition evaluation as query answering

16
From Web Services to HTN-DL
Describe in abstract without committing to any
specific service
17
Abstract Service Descriptions

• Two competing requirements
• Generic descriptions to enable flexible matching
  at run-time
• Specific descriptions to automatically integrate
  services without human intervention
• Functional description of the service
• Functional signature (input and output spec)
• Precondition and effect expression

18
Type-based Matching
parameterType
Abstract
subClassOf
Concrete
19
Type-based Matching
parameterType
Departure Location
Arrival Location
Book Flight
subClassOf
Flight Reservation
From
To
Buy Plane Ticket
Reservation Confirmation
20
Beyond Type Compatibility

• Matching based on semantics
• As defined by preconditions/effects
• Matching logical conditions reduced to query
  containment (subsumption)
• Q1 v Q2 if all the answers of Q1 are includes in
  Q2

service1( inputs (?x, ?y tAirport),
outputs (?z tFlightReservation), result (
(?z tflight ?f) (?f tdepartsFrom ?x)
(?f tarrivesAt ?y)) )
service2( inputs (?a, ?b gAirport),
outputs (?c gItinerary), locals (?f
tFlight), result ( (?c about ?f)
(?f from ?b) (?f to ?a)) )
21
Non-functional Requirements

• Requirements not related to inputs/outputs
• Hard Constraints
• Use only services that are certified by some
  authority
• Do not use any service that does not adhere to
  the required security and privacy policy
• Soft constraints
• Do not use a fee-based service unless there is no
  other choice
• Specify the constraints as preferences
• Rank the matching concrete services accordingly
• Qualitative description of preferences
• Pareto optimal solution

22
Reasoning about State

• Web Services causes state transition
• State is a KB represented in OWL-DL
• Deciding service executability
• Preconditions need to be satisfied
• Ask (SPARQL) queries against state KB
• Service effects described as KB updates
• Update KB and continue with next service
• Reason against highly dynamic KB

23
Challenges to DL Reasoning

• Reasoning with individuals
• Traditionally reasoning concentrated on concepts
• Typically large number of instances
• Service instances in a repository
• Enumerated classes (nominals)
• Most of the service descriptions make use of
  enumerated classes
• Supported languages are English, French,
• Conjunctive query answering
• Efficiently answering ABox queries
• Evaluating preconditions with local variables

24
Reasoning with Nominals

• Define concepts in terms of instances
• Break the separation between the terminology and
  the assertions
• Disjunctive information
• There was no implemented system
• No known optimizations
• General consensus
• Reasoning with nominals is not practical
• Accepted solution pseudo-nominals

25
Novel Optimizations

• Nominal Absorption
• Absorb axioms involving nominals
• Nominal-based model merging
• Exploit the existence of nominals
• Lazy forest generation
• Do not create a completion forest unless it is
  necessary
• Forest caching
• Reuse the previously created completion forest
• Learning-based disjunct selection
• Reuse information when there are many individuals
  with similar characteristics
• e.g. 1000s OWL-S services

26
Query Answering Techniques

• Exploit pseudo-models
• Avoid inference by checking
• Query simplification
• Get rid of redundant atoms
• Query reformulation
• Reorder execution to minimize number of
  consistency checks
• Cost model for query evaluation

27
Pellet OWL-DL reasoner

• Description Logic reasoner based on tableaux
  algorithms
• Specifically designed for OWL
• Primarily for OWL-DL ontologies
• Heuristics to repair OWL Full ontologies
• First reasoner to support all of OWL-DL
• Implements SHOIQ algorithm by Horrocks and
  Sattler
• Provides all the standard reasoning services
• KB consistency, concept satisfiability,
  classification, realization
• Plus

28
Pellet Features

• Query Answering
• Conjunctive ABox queries expressed in RDQL or
  SPARQL
• Datatype Reasoning
• Check if the intersection of XML Schema datatypes
  is satisfiable
• Support reasoning with user-defined derived
  datatypes
• Multi-Ontology Reasoning using E-Connections
• Defining and instantiating combinations of OWL-DL
  ontologies
• An alternative to owlimports
• Ontology Debugging
• Explaining the cause of unsatisfiable concepts
• Relations between unsatisfiable concepts
• Non-monotonic Reasoning with K-operator
• Closed-world queries using ALCK

29
HTN-DL Algorithm

• Start with a template that needs to be
  accomplished
• Recursively decompose templates into components
• For components described in abstract
• Match concrete services with the abstract
  description
• Rank the possibilities according to preferences
• Check applicability of the service
  (preconditions)
• If service is applicable
• Simulate the execution of a service (effects), OR
• Backtrack to a previous choice point

30
HTN-DL is nice, but

• We do not have complete information
• Plane schedules, hotel availability, etc.
• There are information sources available
• Interleave execution with composition
• Execute information-providing Web Services
• Get the relevant information when needed
• Information may not be retrieved quickly
• Accessing remote sources slow
• Look at hotels while waiting for plane schedules

31
ENQUIRER Algorithm

• Planning with incomplete information
• Match conditions with Web Services (information
  sources)
• Determine when information is needed
• Find and execute relevant services
• Multiple services returning information about
  same resources
• Incorporate gathered information to the search
  process
• Planner might have already committed to change
  the information
• Query strategies
• Issue-Wait-Continue Strategy
• Issue-Search-Other Strategy
• FIFO Strategy
• FILO Strategy
• Handle conflicting information
• Detect inconsistencies in the collected
  information
• Use trust and reliability metrics to solve
  conflicts

32
HTN-DL System

• Automated WS composition system
• Services described by OWL-S
• Processed by OWL-S API
• State information represented in OWL
• Handled by Pellet OWL-DL reasoner
• Input Set of OWL-S process models
• Output Executable OWL-S sequence

33
System Overview
Desired Functionality
Translator
Web Services
HTN-DL Planner
Composition Result
Query Manager
Pellet OWL-DL Reasoner
Local KB
34
Experimental Evaluation Pellet

• Results based on
• Commonly used OWL ontologies
• DL Benchmark suite
• Lehigh University Benchmark (LUBM)
• Comparison with
• RacerPro, FaCT, KAON2
• Conclusions
• Not as efficient as a TBox reasoner
• Still acceptable performance
• Very efficient as an ABox reasoner
• Better memory management
• Much better speed

35
Experimental Evaluation HTN-DL

• Initial results promising
• More detailed analysis underway
• Standard planning problems used for benchmarking
• Rover planning problem (from IPC 2002)
• State information encoded in an OWL-DL ontology
• Result Little overhead seen in small problems,
  performs better for large problems compared to
  classical planner
• Web Service composition problems
• Simple problems such as buying a set of books on
  the Web
• Large number of services with similar
  functionality
• Different availability conditions and constraints
• Result Acceptable planning time (ontologies are
  static, instances changing)

36
Conclusions

• Web Service Composition
• Interactive Composition
• Automated Composition with HTN-DL
• Combining HTN planning with DL reasoning
• Information gathering during planning
• Novel optimizations for DL reasoning
• Implemented composition system
• Components used in many different applications

37
Future Directions

• Distributing the matching/selection process
• Ranking results from multiple different
  registries
• Finding optimal compositions
• Based on user preferences
• Anytime algorithm for near-optimal solutions
• Generating more complex compositions
• Containing loops, conditionals, etc.
• Extensions to DL Reasoning
• Rule extensions, non-monotonic extensions,
  paraconsistency
• Incremental reasoning
• Process updates without throwing away old
  information
• Scalability to larger number of instances

38
References

• Evren Sirin, Bernardo Cuenca Grau, and Bijan
  Parsia. From wine to water Optimizing
  description logic reasoning for nominals. In
  International Conference on the Principles of
  Knowledge Representation and Reasoning (KR-2006),
  2006. To Appear.
• Evren Sirin, Bijan Parsia, Bernardo Cuenca Grau,
  Aditya Kalyanpur, and Yarden Katz. Pellet A
  Practical OWL-DL reasoner. Submitted for
  Publication to Journal of Web Semantics, 2006.
• Evren Sirin, Bijan Parsia, and James Hendler.
  Template-based composition of semantic web
  services. In AAAI Fall Symposium on Agents and
  the Semantic Web, Virginia, USA, 2005.
• Ugur Kuter, Evren Sirin, Bijan Parsia, Dana Nau,
  and James Hendler. Information gathering during
  planning for web service composition. Journal of
  Web Semantics, 3(2), 2005.
• Evren Sirin, Bijan Parsia, Dan Wu, James Hendler,
  and Dana Nau. HTN planning for web service
  composition using SHOP2. Journal of Web
  Semantics, 1(4)377-396, 2004.
• Evren Sirin and Bijan Parsia. The OWL-S Java API.
  Poster, In Third International Semantic Web
  Conference (ISWC2004), Hiroshima, Japan, November
  2004.
• Evren Sirin and Bijan Parsia. Planning for
  semantic web services. In Semantic Web Services
  Workshop at 3rd International Semantic Web
  Conference (ISWC2004),
• Evren Sirin, Bijan Parsia, and James Hendler.
  Filtering and Selecting Semantic Web Services
  with Interactive Composition Techniques. IEEE
  Intelligent Systems, 19(4)42-49, 2004.
• All software available through http//www.mindswap
  .org/downloads

39
Questions

• Thank you!

40
Backup Slides
41
Get a BN price (In Euros)
42
Of a particular book
43
In its German edition?
44
(No Transcript)
45
Web Service Composition

• Predefined vs. Dynamic Compositions
• Fixed workflow descriptions
• Follow these steps to place an order
• Combine existing services dynamically
• Compose services to make my travel arrangements
• My focus on the middle-ground
• Interactive composition
• Semi-automated process controlled by the user
• Template-based composition
• Configure and customize the components w.r.t.
  current requirements

46
Service Compatibility

• Matching based on functional signature
• Use subsumption to decide compatibility
• Improving matching
• Mapping axioms (OWL provides some)
• Mapping services (translate between ontologies)

47
More about System Components

• Main components
• Pellet OWL-DL Reasoner
• OWL-S API
• Used in various applications
• Fujitsu Task Computing Environment
• Interacting with devices and Web Services
• Ontology editing and management
• Pellet available as a Swoop plug-in
• DIG interface to be used with Protégé
• Reasoning about policies
• Policy consistency, policy containment, etc.
• Process WS-Policy descriptions

48
OWL
49
Semantic Web

• Knowledge Representation on the Web
• To do for KR what the Web did for hypertext
• Ontologies to define concepts and relations
• Based on Web architecture
• URIs for identifying resources
• Links to combine ontologies
• XML for syntax

50
SemWeb Languages

• Resource Description Framework (RDF)
• Triples Subject, predicate, object
• RDF Schema (RDF-S)
• Frame-like technique to build taxonomies
• Similar to semantic nets
• Web Ontology Language (OWL)
• Extends RDF RDF-S
• Expressive class constructors
• Additional class/property/individual axioms

51
OWL (Web Ontology Language)

• Three flavors of OWL
• OWL-Lite, OWL-DL, OWL-Full
• OWL-Lite and OWL-DL
• Based on Description Logic semantics
• Decidable fragments of First Order Logic
• Sound, complete and efficient reasoners
• OWL-Full
• More freedom in the language (Undecidable)
• Non-standard semantics (closer to HiLog)
• Generally sound and incomplete reasoners

52
OWL DL

• Based on Description Logic semantics
• A decidable subset of FOL (and of OWL Full)
• Classes are 1-place predicates
• Person rdftype owlClass Person(x)
• bob rdftype Person Person(bob)
• Properties are 2-place predicates
• bob hasBrother john hasBrother(bob, john)
• Axioms (typically) are implications
• C subClassOf D ?x.C(x) ? D(x)

53
OWL-S
54
OWL-S

• Provide a set of ontologies for describing Web
  services

Service
supports (how to access it)
describedBy (how it works)
Grounding
Process Model
presents (what is does)
Profile
55
Service Profile

• High-level description of a service
• Used for advertisements and requests
• A profile contains
• a human readable description of the service
• functional attributes
• Inputs, outputs, preconditions, effects
• non-functional attributes
• guarantees of response time or accuracy, cost of
  the service, etc.

56
Process Model

• Atomic processes
• directly invocable
• black box
• Composite processes
• consists of other processes
• defined by a control construct
• Simple processes
• abstract views, not executable
• atomic process without a grounding
• simplified representation of a composite process

57
Example OWL-S Process
Service name
Parameter type (OWL Class)
Input parameter

• (atomic-process register-course
• inputs (?student Student ?course - Course)
• precondition
• (and (?course hasPrerequisite ?anotherCourse)
• (?student passed ?anotherCourse))
• effect (?student registered ?course))

Precondition expression
RDF triple pattern
58
OWL-S View

• World is one big KB
• Represented in OWL
• Services change the world
• Effects described as KB updates
• Services cannot be used arbitrarily
• Preconditions need to be satisfied
• If KB entails the precondition formula

59
OWL-S API

• Lots of good RDF/OWL toolkits but...
• Working at RDF level is tedious
• Wrong level of abstraction
• Changing versions of OWL-S ontologies
• One consistent view
• Execution support
• WSDL grounding XSLT transformations

60
What do we need?

• Programmatic interface
• Minimally Read, write, execute
• Additionally Validate, reason, monitor,
• Extensibility
• Support custom OWL-S extensions
• Integration with RDF/OWL toolkits
• Jena, WonderWeb, Protégé

61
Overview of OWL-S API
Parsing
Serialization
Manipulation
OWL-S Model
OWL-S 0.9
OWL-S 1.0
RDF/OWL Model
OWL-S 1.0
OWL-S 1.1
Presentation
OWL-S 1.1
Execution
JSHOP
OWL-S Execution Engine
Execution Monitoring
WSDL Execution (Axis)
UPnP Execution (CyberLink)
Sample Applications
WSDL2OWL-S
Validator
Version Translator
62
Pellet OWL-DL reasoner

• Description Logic reasoner based on tableaux
  algorithms
• Specifically designed for OWL
• Primarily for OWL-DL ontologies
• Heuristics to repair OWL-Full ontologies
• Covers full expressivity of OWL-DL
• Incorporates SHOIQ algorithm by Horrocks and
  Sattler
• Reasoning with nominals

63
Planning
64
Composition as Planning

• State of the world
• Planning Operators
• Goal formula

Facts known about the world OWL Knowledge Base
Actions that change the state Web Services
Logical formula that needs to be true in the
final state OWL Expression
CG
Service1 Pre A Del B Add D
ACD
ABC
Service2 Pre A Æ D Del B Add E
Initial State
AB
Service3 Pre A Æ B Del C Add B
65
Why is it harder?

• Becomes undecidable easily
• Even though underlying logic is decidable
• Computationally hard
• Query KB while continuously simulating
  modifications
• Classical planning works on databases
• Asserted relations with no inference
• Existing optimizations mostly use caching

66
Example Service

• Schedule a Treatment
• A Person trying to schedule an appointment for a
  medical Treatment in a hospital with a good
  Rating
• Hospital should be supported by the health
  Insurance
• Person should be available at the appointment
  time Hospital offers

67
Example Description

• define composite process ScheduleTreatment(
• inputs (?Person ?Treatment ?Rating),
  precondition
• hasInsurance(?Person, ?Insurance)
• supports(?Insurance, ?Hospital)
• offers(?Hospital, ?Treatment)
• hasRating(?Hospital,?Rating))
• perform GetAvailableTimes(?Hospital)
• perform MakeTheAppointment(?Hospital,
  ?ApptTime)
• perform UpdatePersonalCalendar(?ApptTime)

68
Example Query

• PREFIX health FOR lthttp//.../health-ontgt
• SELECT ?Hospital
• WHERE
• ?Person healthhasInsurance ?Insurance .
• ?Insurance insurancesupports ?Hospital .
• ?Hospital medicaloffers ?Treatment .
• ?Hospital zagathasRating ?Rating .

69
Classical Planning
70
WS Composition Problems
71
Scientific American Scenario
72
Templates
73
Templates in OWL-S

• Composite Processes
• Control constructs Sequence, Any-Order, Choice,
  If-Then-Else, Repeat-While, Repeat-Until, Split,
  Split-Join
• Non-deterministic choice
• Encode different execution paths
• Do whichever such that composite process
• A restricted form of templates

74
Expressive Templates

• Not all steps are fixed a priori
• Services may not be known at design time
• Describe some steps in abstract
• Dynamic binding at run time
• Preferences to rank possible matches
• Hard vs. soft constraints
• Prioritization of preferences

75
Preferences

• Hard Constraints
• Use only services that are certified by some
  authority
• Do not use any service that does not adhere to
  the required security and privacy policy
• Soft constraints
• Do not use a fee-based service unless there is no
  other choice
• Prioritization of preferences
• Reliability is more important than cost

76
Describing preferences

• Modeling preferences quantitatively
• Using numerical scores
• Weighted combination functions
• Hard to maintain in a distributed setting
• Modeling preferences qualitatively
• Partial ordering to prioritize
• Used in multi-attribute decision problems
• Pareto optimality principle
• Preferences on different attributes are treated
  equally important

77
Pellet
78
Pellet Architecture
79
Pellet Performance

• Quite competitive
• Compared to commercial reasoners
• Includes lots of sophisticated optimizations
• Well-known in the literature
• Normalization, simplification, absorption,
  semantic branching, dependency directed
  backjumping, caching, model merging
• Dynamic strategy selection
• Based on the expressivity of the ontology
• Nominals (oneOf, hasValue), Inverse Properties
  (inverseOf), Individuals

80
Query Evaluation
81
Debugging Explanation

• Debug inconsistencies in ontologies
• Black-box vs. glass-box debugging
• Keep track of dependencies
• Finding set of assertions that cause the
  inconsistency
• Explaining how they cause it
• Explaining inferences
• Closely related to proofs
• Presenting to user is hard

82
e-connections

• Reasoning with multiple ontologies
• An alternative to owlimports
• Problems with owlimports
• Does not support information hiding or filtering
• None of the imported axioms retain their context
• It gives us either ALL or NOTHING

83
Partitioning ontologies

• Ontologies with core and many side lines
• National Cancer Institute Ontology
• Char-grilled and belief systems
• Wine ontology
• Wines, regions, colors, etc.
• Partition these
• Smaller, linked ontologies
• Each ontology is more focused
• Easier to understand, evolve, and reuse
• Possible performance gain

84
Performance (version 1.3)
All times in milliseconds
Class / Property / Individual
85
DL Benchmark Suite

• Set of ontologies traditionally used for testing
  and benchmarking DL reasoners
• Synthetic vs. real world ontologies
• Only classes vs. both classes and instances
• Comparison
• Pellet 1.3
• RacerPro 1.8.1
• FaCT 0.99.5

86
DL Benchmark Results
87
Lehigh University Benchmark

• A relatively simple (but not trivial) ontology
• Describe universities, departments, courses,
  professors, students, etc.
• Set of fixed queries
• Aimed to test different features
• Inferred type relations, subproperty inferences,
  transitive properties, etc.
• Varying data sets
• 1 University - 15 departments, 5 Universities
  100 departments, etc.

88
LUBM Results