68 KAPITEL 3. ANWENDUNGSBEISPIELEder <strong>in</strong>tendierten Zustandsabfolge werden alle außer den folgenden Default-Ausprägungenangenommen:succ(1, 2) ∧ <strong>in</strong>(1, honig, wald) → <strong>in</strong>(2, honig, wald).succ(2, 3) ∧ <strong>in</strong>(2, spieler, wald) → <strong>in</strong>(3, spieler, wald).succ(3, 4) ∧ <strong>in</strong>(3, honig, tasche) → <strong>in</strong>(4, honig, tasche).succ(3, 4) ∧ hungrig(3, bär) → hungrig(4, bär).Es gibt aber auch die Möglichkeit, vorausschauend Änderungen durchzuführen, die bewirken,daß später die Vorbed<strong>in</strong>gungen nicht erfüllt s<strong>in</strong>d, so daß dann Änderungen e<strong>in</strong>gespartwerden. Der Spieler könnte etwa bei dem Fußmarsch vom Wald zur Höhle den Honig verlieren,dadurch kann er den Bären später nicht füttern:succ(1, 2) ∧ <strong>in</strong>(1, honig, wald) → <strong>in</strong>(2, honig, wald).succ(2, 3) ∧ <strong>in</strong>(2, spieler, wald) → <strong>in</strong>(3, spieler, wald).succ(2, 3) ∧ <strong>in</strong>(2, honig, tasche) → <strong>in</strong>(3, honig, tasche).Natürlich steht von dieser Möglichkeit nichts <strong>in</strong> der Spezifikation, aber es ist auch nichtexplizit ausgeschlossen.Das Problem ist hier, daß die Änderungen global m<strong>in</strong>imiert werden (über die ganzeZustandsfolge gesehen). Dadurch geht die Kausalität der Änderungen verloren. Manmöchte natürlich, daß die Änderungen bei jedem Zustandsübergang e<strong>in</strong>zeln m<strong>in</strong>imiertwerden, <strong>in</strong>sbesondere sollen nicht spätere Zustandsübergänge Rückwirkungen auf früherehaben. Es liegt daher nahe, den <strong>Defaults</strong> für frühere Zustandsübergänge höhere Prioritätzu geben, also notwendige Änderungen so spät wie möglich auszuführen.✷Dies ist e<strong>in</strong>e Variante des bekannten ”Yale Shoot<strong>in</strong>g“ Problems [HM87]. (Dort s<strong>in</strong>d die dreiAktionen ”laden“, ”warten“, ”schießen“. Beispiel 3.3.3 ist etwas tierfreundlicher, obwohlja auch beim orig<strong>in</strong>alen Beispiel das Ergebnis gerade ist, daß sich die Fl<strong>in</strong>te möglicherweisewährend des Wartens auf magische Art entladen hat.)Man beachte noch, daß die <strong>in</strong> Beispiel 3.3.2 aufgezeigten Probleme mit unvollständigerInformation natürlich auch hier auftreten, man muß also die entsprechenden <strong>Defaults</strong> nochh<strong>in</strong>zunehmen.Allerd<strong>in</strong>gs funktioniert das Pr<strong>in</strong>zip, Änderungen so spät wie möglich durchzuführen,nur bei Anfragen nach der Gültigkeit e<strong>in</strong>er Aussage <strong>in</strong> e<strong>in</strong>em bestimmten Zustand ( ”temporaleProjektion“).Angenommen, man gibt stattdessen den Zielzustand vor und fragt, welche Aktionendorth<strong>in</strong> geführt haben können (e<strong>in</strong>e Planungsaufgabe). Nach dem Pr<strong>in</strong>zip, Änderungen sospät wie möglich durchzuführen, geschieht die ganze Zeit gar nichts, nur bei dem letztenZustandsübergang wird der Zielzustand erreicht, ohne daß es e<strong>in</strong>e Erklärung dafür gebenwürde.Angesichts dieser Probleme muß man sich natürlich fragen, ob man es nicht ohne<strong>Defaults</strong> leichter hätte, <strong>in</strong>dem man also nur die Logik erster Stufe benutzt. E<strong>in</strong> solcherAnsatz wird von Raymond Reiter [Rei92] vertreten. Man müßte dann also Formelnder Art aufschreiben, daß sich der Ort e<strong>in</strong>es Gegenstandes nur dann ändern kann, wenn
3.3. FORMALISIERUNG VON ÄNDERUNGSOPERATIONEN 69e<strong>in</strong>e entsprechende Aktion ausgeführt wird und deren Vorbed<strong>in</strong>gungen erfüllt s<strong>in</strong>d. Diesist natürlich gerade bei e<strong>in</strong>er größeren Anzahl von Aktionen recht mühsam. Vor allemaber können auf diese Art nur Spezialfälle behandelt werden, denn im allgeme<strong>in</strong>en Fallkönnte man ja gerade <strong>Defaults</strong> simulieren, so daß dies e<strong>in</strong>fach nur e<strong>in</strong> spezieller Vervollständigungs-Mechanismuswäre.Beispiel 3.3.4: Da man mit e<strong>in</strong>fachen Zustandsübergängen unpriorisierte <strong>Defaults</strong>simulieren kann, liegt es nahe, daß man mit Zustandsfolgen gerade die Prioritäten erhält.Das ist aber nicht richtig: Hat man etwa die <strong>Defaults</strong> ¬p und ¬q, wobei der erste höherePriorität hat, und das Axiom p∨q, so würde man erst ¬q e<strong>in</strong>fügen, dann ¬p und schließlichdas Axiom. Bei priorisierten <strong>Defaults</strong> sollte sich natürlich ¬p durchsetzen. Änderungs-Semantiken s<strong>in</strong>d dagegen im allgeme<strong>in</strong>en geschichtslos: Wenn das Axiom e<strong>in</strong>gefügt wird,ist der vorliegende Zustand {¬p, ¬q}, die m<strong>in</strong>imale Änderung liefert dann {¬p∨¬q, p∨q}.(Beobachtung von Mark Ryan.)✷