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. • User’s 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 al’s 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 • Waldinger’s 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ämmermann’s 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 al’s 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 • Medjahedproposes 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?