Knowledge Based Composition

1
Knowledge Based Composition

• An overview of existing approaches

2

• CAT (Compositional Analysis Tool)
• Uses knowledge bases (ontologies) that represent
  both model constraints and planning techniques to
  reason about the relationships among individual
  pathway components.
• Supports user by providing informed suggestions
  based on this knowledge of components and
  pathways.

3
CAT

• Ontologies used to represent components move
  beyond the existing, syntactic descriptions
  that web services - these lack information on
  what services need, do, produce etc. Extend with
  two types of knowledge
• Domain Term Ontology Input and output types
  described using data types defined in this
  ontology.
• Task Ontology Hierarchy of task types
  either high level abstract descriptions of
  components or executable components.

4
CAT

• Can reason using this knowledge i.e to suggest
  an output to connect to a missing input based on
  the information in the ontology.
• Uses planning approaches to reason about
  relationships among components in a pathway.
• Knowledge base of components keeps track of
  common features existent between components of
  different abstraction levels in the hierarchy

5
CAT

• Use of AI Planning
• Scan partial workflow for inconsistencies, gaps
  etc. Used to identify steps that can lead from an
  initial or current state toward a goal state.
• Components treated as steps in the plan - inputs
  are preconditions of that step, outputs are its
  effects.
• Data provided by the user forms the initial
  state, desired results are the goals for the
  planning problem. Handled as steps with no input
  and output respectively.
• Users Actions (add/remove component, specialize
  component, add/remove link) are refinement
  operators in plan generation.
• Makes use of existing Prodigy planner.

6
CAT

• Formalised the actions that can be taken by a
  user, see previous and formalised properties
  that a workflow needs to meet.
• Uses ErrorScan algorithm to check if a workflow
  meets necessary properties and can reason with
  the available actions to suggest fixes (fixes can
  be an ordered sequence of steps not just a
  single change).
• Suggestions are constructive and are assessed
  to see if they create more problems than they
  solve if so they are culled from the list of
  suggestions.

7
Other Approaches

• Eflow
• Incorporates static generation of workflows
• User defines abstract graph consisting of
  service, decision and event nodes and system uses
  a search recipe to bind concrete services to
  the abstract workflow.

8
Other Approaches

• Polymorphic Process Model (PPM)
• Features a static generation system similar to
  above
• Users compose processes that have a functionality
  description but lack any implementation and the
  system then binds these to services at runtime.
• Also has a dynamic generation aspect
• Services are modelled by a state machine which
  specifies the possible states of a service and
  its transitions (caused by either service
  activity or internal service transitions).
• Automated generation is performed based on
  reasoning with the state machine.

9
AI Planning Approach

• Rao et al. describe the common AI planning
  approach to automated composition as the
  five-tuple S,S0,G,A,T)
• S is all possible world states
• S0 is the start state
• G is the goal state to aim for
• A is the actions the planner can perform in
  attempting to change from one state to another
  (ie the available services)
• T is the translation relation which defines
  preconditions and effects for each action A (i.e
  what the services do).

10
AI Planning Approach

• Rao et al. discuss DAML-S (OWL-S), a language
  which allows services to be defined with
  properties that specifies
• Preconditions necessary before the service can be
  requested, and
• Effects that a successful execution of the
  service will have.
• Suggest these properties useful in solving the
  automated composition problem as can aid in the
  reasoning process.

11
AI-Planning

• SHOP2
• Automatic web service composition using DAML-S
  descriptions and Hierarchical Task Network (HTN)
  planning. Propose task decomposition in HTN
  similar to process decomposition in DAML-S,
  suggest HTN quicker than other AI planners.

12
AI-Planning

• Sirin et als approach
• Semi-automatic composition system
• Parameters of services described by OWL classes
• Presents choices of possible services to connect
  to the user
• Does the OWL description of the output for one
  match the OWL input of the other (or is a
  subclass of)
• Ordered for priority based on distance between
  types in ontology tree. Choices can be filtered
  further based on non-functional constraints
  provided by the user.

13
Theorem Proving

• Waldingers theorem proving approach
• User requirements and initial available services
  described in a first-order language (similar to
  classical logic)
• Constructive proofs generated with SNARK theorem
  prover
• Service composition descriptions extracted from
  proofs.

14
Theorem Proving

• Lämmermanns approach
• Utilises Structural Synthesis of Program (SSP
  deriving programs from specifications).
• Service specifications limited to inputs and
  outputs, approach uses proof-as-programs property
  of intuitionistic propositional logic to solve
  composition.
• Equates service composition problem to proof
  search problem.

15
Theorem Proving

• Rao et als approach
• Utilises Linear Logic theorem proving
• Introduces formal definitions of further
  attributes of services (beyond DAML-S)
  qualitative and quantitative, non-functional etc.

16
Rule-Based Planning

• Medjahed proposes a technique for service
  composition from a high level declarative
  description
• Uses composability rules to see if services are
  composable.
• High level specification given using CSSL
  (Composite Service Specification Language).
• Composability rules used to generate plan to meet
  specification.
• If several plans composed then selection made
  based on QoC (Quality of Composition) parameters
  (rank, cost etc.).
• Finally a complete plan is generated and
  returned.

17
Rule-Based Planning

• Composability rules based on two properties of
  web services
• Syntactic Rules for the operation modes of a
  service and the rules for binding protocols of
  interacting services
• Semantic broken down into
• Message Composability does the output message
  of one match the input of another
• Operation Composability defines compatibility
  based on domains, categories, and purposes of
  services
• Qualitative Composability defines users
  preferences for quality of services in the
  composition, Composition Soundness is a
  composition of services reasonable.
• Also introduce composition templates to define
  dependency between different kinds of services

18
Rule-Based Planning

• SWORD
• Uses Entity-Relation model, defining a service
  based on its pre- and postconditions.
• Defined in a world model consisting of entities
  and relationships between entities.
• Services represented by a Horn rule denoting
  (what) the postconditions achieve if the
  preconditions are met.
• Generation needs an initial and final state and
  then uses a rule-based expert system to compose a
  plan.
• Considers implications of uncertain results
  from rule based composition that arise when a
  precondition cannot uniquely determine a
  postcondition can be avoided if the
  preconditions are functionally dependant on the
  postconditions inside a service.

19
Planning Domain Definition Language

• PDDL
• Standardised input for planners, similar to
  DAML-S.
• Mapping DAML-S descriptions to PDDL enables use
  in existing planners.
• McDermott suggests a new type of knowledge For
  composing web services value of an action.
• Designed to give information on transformations
  and state changes caused by the execution of a
  service.
• Important as AI Planners usually assume a closed
  world situation whereby if a literal does not
  exist it is assumed to be false, which would not
  allow for the expression of new information
  acquired as a result of service execution.

20
Situation Calculus

• Extension to Golog language (logic programming
  language built on situation calculus a logical
  language for reasoning about action and change)
  addressing the problem through use of high level
  generic procedures and customisation
  constraints with Golog used to represent and
  reason about the problem. A users request
  (generic procedure) and constraints are
  represented by the first order language of
  situation calculus. Each service is an Action,
  either Primitive (those that perform actions to
  change the state of the world or gather
  information to change the state of knowledge) or
  Complex (compositions of individual actions). A
  knowledge base has situation calculus definitions
  of the preconditions and actions of the services.
  Uses programming constructs (if-else, while etc.)
  to compose services and constraints using
  deductive machinery.

21
Common Appearance

• PowerLoom?