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

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

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

2
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

3
Overview

• Short background on (Semantic) Web Services
• Composition of Web Services
• Interactive composition
• Semi-automated composition
• Automated composition
• AI planning techniques for composition
• Template-based composition HTN-DL formalism
• Implementation of the Composition System
• OWL-S API
• Pellet OWL-DL reasoner

4
Web Services

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

5
Semantic Web Services

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

6
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
• In the middle
• Interactive composition
• Declarative description of the workflow
• Template-based composition
• Configure and customize the components w.r.t.
  current requirements

7
Interactive Composition

• Semi-automated and mixed-initiative
• Guide users to build compositions
• Present matching services
• Based on parameter types
• Filter possibilities
• Profile hierarchies
• Execute compositions
• Save compositions

8
Service Compatibility

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

9
Get a BN price (In Euros)
10
Of a particular book
11
In its German edition?
12
(No Transcript)
13
Saving Compositions
14
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?

15
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

16
HTN Planning

• Hierarchical Task Network (HTN) planning
• Differs from classical planning
• Plan with tasks not goals
• Tasks Objectives that need to be achieved
• Operators Methods Descriptions of how to
  achieve tasks
• Analogy with Web Services
• Operator ? Atomic Service
• Method ? Composite Service
• Methods decompose a task into subtasks
• Find a decomposition that is executable starting
  from the initial state

17
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)
18
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

19
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

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

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

22
Type-based Matching
parameterType
subClassOf
23
Type-based Matching
parameterType
Departure Location
Arrival Location
Book Flight
subClassOf
Flight Reservation
From
To
Buy Plane Ticket
Reservation Confirmation
24
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)) )
25
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

26
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

27
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

28
Planning with Incomplete Information

• How to do information-gathering during planning
• ENQUIRER algorithm
• Different search strategies
• How to continue when queries are answered

29
Implementation

• 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

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

• Initial results promising
• More detailed analysis underway
• Test cases
• Classical planning problems from IPC
• Web Service composition problems

32
More about System Components

• Main components
• OWL-S API
• Pellet OWL-DL Reasoner
• Used in various applications
• Fujitsu Task Computing Environment
• Interacting with devices and Web Services
• Ontology editing and management
• 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

33
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

34
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é

35
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
36
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

37
Pellet Features

• Provides standard reasoning services
• Ontology consistency, concept satisfiability,
  classification, realization
• 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

38
Pellet Architecture
39
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

40
Novel Optimizations

• Nominal Absorption
• Absorb axioms involving nominals
• Learning-based disjunct selection
• Reuse information when there are many individuals
  with similar characteristics
• e.g. 1000s OWL-S services
• Partial backjumping
• Keep useful information during backtracking
• Nominal-based model merging
• Exploit the existence of nominals
• Lazy forest generation
• Forest caching

41
Conclusions

• Web Service Composition
• Interactive Composition
• Automated Composition
• Based on flexible templates HTN-DL formalism
• Dynamically matching services at run-time
• Using ontologies for matching
• Ranking based on preferences
• Balance between theory and practice
• System implementation
• Components used in many different applications

42
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.
• Reasoning with more expressive KR languages
• Rule extensions, non-monotonic extensions
• Scalability to larger number of instances

43
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

44
Questions

• Thank you!

45
Backup Slides
46
OWL
47
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

48
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

49
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

50
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)

51
OWL-S
52
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
53
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.

54
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

55
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
56
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

57
Planning
58
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
59
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

60
Classical Planning
61
WS Composition Problems
62
Templates
63
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

64
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

65
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

66
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

67
Pellet
68
Query Answering

• Based on roll-up technique
• Optimizations
• Exploit pseudo-models
• Avoid inference by checking
• Early candidate elimination
• Get rid of unrelated individuals upfront
• Query reformulation
• Sort the triples to minimize number of checks

69
Query Evaluation
70
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

71
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

72
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

73
Performance (version 1.3)
All times in milliseconds
Class / Property / Individual
74
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

75
DL Benchmark Results
76
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.

77
LUBM Results