Kompositionsplanung von semantischen Webdiensten SHOP2

Präsentation zum Thema: "Kompositionsplanung von semantischen Webdiensten SHOP2"—  Präsentation transkript:

1 Kompositionsplanung von semantischen Webdiensten SHOP2
Ehsan Gholamsaghaee Betreuer: Andreas Gerber Department 6.2 – Computer Science Fakultät für Naturwissenschaft und Technologie I

2 Inhalt Einführung OWL-S KI-Planung HTN und SHOP2 SHOP2 für WSC
ENQUIRER Zusammenfassung

3 Einführung Webdienste: durch die Webprotokolle erreichbare Software-Anwendungen Problem: Webdienst bzw. Zusammensetzung von vorhandenen Webdiensten für eine Aufgabe/Ziel sehr kompliziert für Mensch schnelle Annahme der Anzahl von Webdiensten und ihre schnelle Erzeugung und Aktualisierung

4 Einführung Beispiel: eine Reise nach NY
Übernachten in einem 4 Sterne Hotel im Zentrum weitere Wünsche bezüglich Restaurants, des Fluges und …

5 Einführung Lösung: dynamische Kompositionsmethoden zur automatischen Planerzeugungen KI-Planungstechniken deduktive Theorembeweise dafür: Repräsentation von Webdiensten als Aktionen (Operatoren) Webdienstskompositionsproblemen als Planungsprobleme

6 OWL-S modelliert die Operatoren als Prozesse
atomic process composite process simple process Dekomposition von zusammengesetzten Prozessen durch Kontrollstrukturen

7 OWL-S Kontrollstrukturen
Sequence: Ausführung von Prozessen in gegebener Ordnung Split : gleichzeitige Ausführung der Prozesse Unorderd :nicht sequenzielle + gleichzeitige Ausführung Choice: eine von möglichen Prozessen ausführen If-Then-Else Iterate Repeat-Until

8 OWL-S Prozesseigenschaften (optionale) Inputs Preconditions
(konditionale) Outputs (konditionale) Effects (nicht alle Webdienste)

9 KI-Planung Estellung einer Struktur von Aktionen als Problemlösung
Aktion: move(x, y) B move (a,table) move (c,a) move (b,c) A C B C A klassisches Planungsproblem: ein Tuple <S,s0,G,A,Γ> mit S die Menge von Zustände s0 der Anfangszustand G Menge von Zielzustände A Menge der Aktionen Γ die Übergangsrelationen (S, A, S)

10 klassische Planer und Webdienste
Domäne nicht vollständig beobachtbar Die Anzahl von Webdienste is sehr groß… … und Resultate vielleicht unbekannt Komposition komplizierter Webdienste ist notwendig. Domäne vollständig beobachtbar atomare Aktionen mit deterministischen Effekten alle Informationen sind vollständig und korrekt nur sequenzielle Pläne

11 nicht klassische Planer
Conditional Planning: Erzeugung eines Planes für alle unterschiedliche Umweltzustände Conformant Planning: einen Plan finden, der in allen Anfangszuständen ausführbar ist. Planen als Model-Cheking Hierarchical Task Network Planning (HTN)

12 get-ticket(a(x), a(y))
HTN I Problem-Reduktion Tasks anstatt Goals Zerlegt Tasks in Subtasks (durch Methoden) Behandlung von Beschränkungen (z.B. Taxi ist nicht gut für lange Strecken) Backtracking möglich task travel(x,y) method taxi-travel(x,y) air-travel(x,y) pay-driver get-ticket(a(x), a(y)) travel(a(y),y) get-taxi ride-taxi(x,y) travel(x,a(x)) fly(a(x),a(y)) opeartor

13 HTN II Planen durch Task-Dekomposition Planungsdomäne enthält
Operatoren : primitive Tasks Methoden : Dekomposition von Tasks eine Zerlegung finden, die vom Anfangszustand ausführbar ist. Problembeschreibung (S, T, D) S: Anfangszustand T: Liste der Aufgaben D: Domäne-Beschreibung

14 Warum HTN? Task-Dekomposition ähnlich wie Dekomposition von composite processes sehr gut für große Anzahl von Methoden und Operatoren Interaktionsmöglichkeiten mit dem Planer während des Planens manche HTN Planer unterstützen Precondition reasoning … … Evaluation und Integration von information-supplying Webdiensten

15 SHOP2 HTN Planungssystem Domäne-unabhängig
plant in der gleichen Reihenfolge, die später ausgeführt wird Weltzustand ist an jedem Schritt des Planungsprozesses bekannt einfache Integration: der Aufruf von externen Informationsquellen Domänebeschreibung in PDDL Operatoren Methoden Axiome

16 SHOP2 (Operatoren) Operator: (h( v ) Pre Del Add)
h( v ) primitive Aufgabe + Liste von Eingabeparameter ( v ) Pre Preconditions Del Delete-List Add Add-List wie STRIPS-Operatoren führt eine primitive Aufgabe aus Preconditions und Effekte in PDDL result(S,h ) =(S-D ) U A u u u

17 SHOP2(Operatoren) Beispiel: (:operator (!fly ?a_x ?a_y) ;precondition
((at ?a_x)) ;delet-list ;add-list ((at ?a_y)))

18 SHOP2(Methode) Methode: (h( v ) Pre T Pre T ….)
h( v ) composite Task Pre ein Precondition-Ausdruck T eine Task-List Bedeutung: analog zu Konditionalausdrücke if Pre T else if Pre T … 1 1 2 2 i i 1 1 2 2

19 SHOP2(Methode) Beispiel: (:method (travel ?x ?y)
((long-distance (?x ?y))(airport ?x ?a_x) (airport ?y ?a_y)) ((!by_ticket ?a_x ?a_y)(!travel ?x ?a_x) (!fly ?a_x ?a_y)(travel ?a_y y)) () ((!get_taxi)(!ride_taxi ?x ?y)(!pay_driver)) )

20 SHOP2(Axiome) Axiom: (h( v ), C C … C ) generalisierte Horn-Regeln
h( v ) Regel + Liste von Eingabeparameter C Bedingungen Bedeutung: Der Regel gilt wenn C ist wahr Oder C falsch und C richtig ist usw. 1 2 n i 1 1 2

21 SHOP2 (Planungsproblem)
Ein Tripel <S, T, D> mit S: Anfangszustand T: Liste der Aufgaben D: Domänen-Beschreibung Ausgabe: ein Plan P = (p p …p ) Folge von instantiierten Operatoren erreicht T aus S in D 1 2 n

22 OWL-S SHOP2 I Sei K={K ,K ,….K } ein OWL-S Prozessmodell
atomic Processes in K haben entweder Effects oder Outputs kein Split und Split+Join in K (keine Parallelität in SHOP2) atomic Process mit Effects Operator, der die Effects simuliert atomic process mit Outputs Operator, der das passende WS in seiner Precondition aufruft simple/composite Process 1 2 3 eine oder mehrere Methoden

23 OWL-S SHOP2 II TRANSLATE-ATOMIC-PROCESS-EFFECT(Q)
Input: OWL-S Definition Q von atomic process A Output: SHOP2 Operatore O Prozedur: v = Liste der Eingabeparametern von A in Q Pre = Konjunktion allen Preconditions von A in Q Add =alle positive Effekte von A in Q Del = alle negative Effekte von A in Q Return O = (A( v ) Pre Del Add)

24 OWL-S SHOP2 III TRANSLATE-ATOMIC-PROCESS-OUTPUT(Q)
Input/Output wie Oben Prozedur: v = Liste der Eingabeparametern von A in Q Pre = Konjunktion aller Preconditions von A in Q neue Precondition der Form (assign y (call Monitor A v )) Add = y Del = {} Return O = (A( v ) Pre Del Add)

25 OWL-S SHOP2 IV TRANSLATE-SIMPLE-PROCESS(Q)
TRANSLATE-Sequence-PROCESS(Q) TRANSLATE-If-Then-Else-PROCESS(Q ) TRANSLATE-Repeate-While-PROCESS(Q ) TRANSLATE-Repeat-Until-PROCESS(Q ) TRANSLATE-Choice-PROCESS(Q ) TRANSLATE-Unordered-PROCESS(Q )

26 OWL-S SHOP2 IV TRANSLATE-Repeate-While-PROCESS(Q )
Input:OWL-S Definition Q von composite process C Output: eine Menge von SHOP2 Methoden Prozedur: v = Liste der Eingabeparametern von C in Q π = While-Bedingungen wie in Q Pre = Konjunktion allen Preconditions von C in Q b = Repeat-Prozess wie in Q M = (C(v ) Pre C (v )) M = (C (v ) π (b C (v )) {}{}) Return M = {M , M } While 1 1 1 2 1 While 1 1 1 2

27 OWL-S SHOP2 V TRANSLATE-PROCESS-MODEL(K )
Input: eine Mengen von OWL-S Prozessmodelle K Output: eine SHOP2 Domäne D D = {} D U {Transformation von atomic processes} D U {Transformation von simple processes} D U {Transformation von composite processes} Return D

28 Implementierung . SHOP2 OWL-S Plan Web Service 1 User Interface
OWL-S service Description Service Invocation Web Service 2 OWL-S to SHOP2 Translator . SHOP2 Domain SHOP2 Execution Monitoring System SHOP2 Plan Web Service N SHOP2 to OWL-S Plan Converter OWL-S Plan

29 Informationssammelung
Informationen im Anfangszustand nicht komplett Informationssammlung während des Plans Informationsrückgabe von Webdienste ENQUIRER

30 ENQUIRER I gleiche Notationen wie in SHOP2
Umgang mit unvollständigen Informationen des Anfangszustandes Aufbau askable list: verfügbare Informationen während des Planens (nicht nur am Anfang von Planen) Query: Ausdruck der Form (h p) h: Label p: logisch Atom Informationssammlung über p

31 ENQUIRER II Eingabe: Planungsproblem mit unvollständigen Informationen (J, A, T, D) J (möglicherweise unvollständiger) Anfangszustand A eine askable list T eine Liste von Aufgaben D HTN-Domäne Sammlung von relevanten Informationen während des Planens Generierung von neuen Plänen während auf die Antwort vom WS gewartet wird

32 ENQUIRER-Algorithm

33 ENQUIRER und SHOP2 Aufrufe von externen WS in SHOP2 als Spezielle Anwendung von ENQUIRER ENQUIRER überwindet folgende Beschränkungen keine explizite Spezifikation von Information-providing Services am Anfang des Planens. kein Abwarten auf neue Informationen für weitere Planung

34 Aber … keine Parallelität keine wirkliche Open-World Annahme
keine Weltzustandsänderungen durch andere Agenten während der Planausführung kein atomic process mit Effect und Outputs keine Informationssammlung während der Planausführung

35 Zusammenfassung Transformation von OWL-S Prozessmodelle nach SHOP2-Domäne Transformation von OWL-S Kompositionsproblem nach SHOP2 Planungsproblem Webdienstkompositionen durch SHOP2 Planer ENQUIRER als eine Erweiterung von SHOP2

36 Vielen Dank für Ihre Aufmerksamkeit