GraphPlan - Spare Tire Example

Graph Plan algorithm working with spare tire problem

Notice the goal `At(Spare, Ax\l\e)` is not present in in `S_0` so we would call Expand-Graph adding into `A_0` the three actions whose preconditions exist at level `S_0`. Using these actions we get `S_1`.
Again, `At(Spare, Ax\l\e)` is still not present in `S_1`, so Expand-Graph is called again, adding `A_1` and `S_2`.
At this point we might be able to call Extract-Solution.
Before we continue, let's classify the kinds of mutexes which we have in our graph:
- Inconsistent effects: Remove(Spare, Trunk) is mutex with LeaveOvernight because one has the effect `At(Spare, Ground)` and the other its negation.
- Interference: `Remove(Flat, Ax\l\e)` is mutex with LeaveOvernight because one has the precondition `At(Flat, Ax\l\e)` and the other has its negation as an effect. i.e., if we imagine trying to write these operation in serial order, if we did `LeaveOvernight` first, we couldn't do `Remove(Flat, Ax\l\e)`, on the other hand, if we did `Remove(Flat, Ax\l\e)` first, then `LeaveOvernight` has no effect.
- Competing needs: `PutOn(Spare, Ax\l\e)` is mutex with `Remove(Flat, Ax\l\e)` because one has `At(Flat, Ax\l\e)` as a precondition and the other has its negation.
- Inconsistent support: `At(Spare, Ax\l\e)` is mutex with `At(Flat, Ax\l\e)` in `S_2` because the only way of achieving `At(Spare, Ax\l\e)` is by `PutOn(Spare, Ax\l\e)` and that is mutex with the persistence action that is only way of achieving `At(Flat, Ax\l\e)`. Thus, the mutex relations relations detect the immediate conflict that arises from trying to put two objects in the same space at the same time

Backward Search and Spare Tire Problem

If we used backward search to try to solve the spare tire problem, then we start at `S_2` with the goal `At(Spare, Ax\l\e)`.
The only choice for achieving this goal set is `PutOn(Spare, Ax\l\e)`. That brings us to a search state at `S_1` with goals `At(Spare, Ground)` and `neg At(Flat, Ax\l\e)`.
The former can be achieved only by `Remove(Spare, Trunk)`, and the latter by either `Remove(Flat, Ax\l\e)` or `LeaveOvernight`.
`LeaveOvernight` is mutex with `Remove(Spare, Trunk)`, so we choose `Remove(Spare, Trunk)` and `Remove(Flat, Ax\l\e)`
This brings us to a search of state `S_0` with the goals `At(Spare, Trunk)` and `At(Flat, Ax\l\e)`. As both of these are present in `S_0` we have found a solution: `Remove(Spare, Trunk)`, `Remove(Flat, Ax\l\e)`, and `PutOn(Spare, Ax\l\e)`.
In the case where Extract-Solution fails to find a solution for a set of goals at a given level, we record the pair (level, goals) pairs as a no-good. If Extract-Solution is called again with the same level and goals, we just immediately return failure.

GraphPlan Heuristics

We know planning is PSPACE-complete and making the planning graph is in polynomial time.
So the backward search can still be hard, so heuristics are still needed for choosing among actions.
People often use a greedy algorithm based on the level cost of literals.
For any set of goals, we proceed in the following order:
1. Pick first the literal with the highest level cost.
2. To achieve that literal, prefer actions whose sum of the level costs of its preconditions is smallest.
Although we won't show it in class, one can show that the GraphPlan Algorithm terminates.

Knowledge Representation

So far we have looked at the technology needed for knowledge-based agents: the syntax, semantics, proof theory, and the implementation of agents that use these logics.
We now turn to the question of what content to put into an agent's knowledge base -- how to represent facts about the world.
For "toy" domains like the Wumpus world, the choice of how to represent things is less important, many choices will work.
For complex domains such as shopping on the Internet, driving a car in traffic, it is important to have flexible enough representations.
The concepts that people commonly try to represent are: Events, Time, Physical Objects, and Beliefs.
How we choose to represent these abstract objects is sometimes called ontological engineering.

Coming up with Ontologies

One approach to coming up with an ontology is to take an OO-like approach
We describe general properties of things like a "Physical Object" or a computer "Window"
Then we allow people to subclass this to get more specific concepts like "SpreadSheetWindow"
From this we get a hierarchy like in the image above.
This kind of ontology is called an upper ontology.
We express these ontologies in first-order logic. However, one problem we will encounter is that generalizations have exceptions which are often hard to express in logic.
For example, although "tomatoes are red" is usually true one can have green tomatoes.
So we will want to look at systems that can handle this.

Famous Ontologies

Most ontologies that have been created and have been successful are for a particular domain.
For example, one might come up with an ontology that lets one describe circuits, people can write their circuits in this ontology, then theorem provers can be used to prove correctness facts about a given circuit (or else find a bug).
So the field of knowledge engineering has many different ontologies, one might ask if one can come up with a common language for describing everything?
There have been several famous attempts to do this and each of them has their uses:
1. Cyc which was developed by Lenat and described in Lenat and Guha (1990). A group of logicians by hand built this system.
2. DBPedia which was made by trying to extract categories, values, attributes in a semi-automated fashion for Wikipedia. (Bizer, et al 2007)
3. TextRunner, which has built by parsing text documents from the web and trying to extract information from them. (Banko and Etzioni 2008)
4. OpenMind, which was built by volunteers who propose facts in English (Singh, et al 2002; Chklovski and Gil 2005.)

Categories and Objects

In this approach, we try to group objects in the world into categories. For example, the category of objects which are Basketballs.
These are often represented in first-order logic as predicates. Any b that satisfies `Basketball(b)` would be deemed a basketball.
Another approach is to imagine that there is an object which collects together all objects which are basketballs (this approach is called reification). Call this object Basketballs. We can then ask for an object `b` whether `b in Basketballs`.
We write `Basketballs subset Balls` to indicate Basketballs is a subcategory/subclass/subset of Balls.
A subcategory inherits all the properties of its parent category. i.e., what is true of the parent class is true of the child.
Categories can be organized into taxonomies by using the subclass relation.
The kinds of facts that we can state in taxonomies are: (a) an object is a member of a category, (b) a category is a subclass of another, (c) all members of a category have some property (For example, `x in BasketBall => Spherical(x)` ), (d) Members of a category can be recognized by some property (For example, `Oran\g\e(x) ^^ Round(x) ^^ Diameter(x) =9.5'' ^^ x in Ball => x in BasketBall`), and a category as a whole has some properties (for example, `Dogs in DomesticatedSpecies`).
We will often decompose categories into subcategories. If every object in the original belongs to one of the subcategories we say we have an exhaustive decomposition. If, in addition, the subcategories are disjoint (share no objects), we call the decomposition a partition.

Physical Composition

We now consider how to represent knowledge about physical objects
One common way to group objects is to say that they are part of some other. We will use the PartOf relation for this purpose. For example, PartOf(Bucharest, Romania), PartOf(Romania, EasternEurope).
Composite Objects can be represented by asserting its parts exists and their relationships:
`Biped(a) <=> exists l_1, l_2, b Leg(l_1) ^^ Leg(l_2) ^^ Body(b) ^^`
`quad PartOf(l_1, a) ^^ PartOf(l_2, a) ^^ PartOf(b,a) ^^`
`quad A\t\ta\ched(l_1, b) ^^ A\t\ta\ched(l_2, b) ^^`
`quad l_1 ne l_2 ^^ (forall l_3 Leg(l_3) ^^ PartOf(l_3,a) => (l_3 = l_1 vv l_3 = l_2))`
A PartPartition of an object can be defined in a similar way: we assert the existence of various components to the object, we assert members of these components are disjoint and that the collection of all component members is the whole.
It is also sometimes useful to define composite objects with definite parts but no structure. We can use the BunchOf relation for this. For example, `BunchOf({Appl\e_1, Appl\e_2, Appl\e_3})`.
BunchOf can be defined in terms of PartOf using:
`forall x, x in s => PartOf(x, BunchOf(s))` and
`forall y, [forall x, x in s => PartOf(x,y)] => PartOf(BunchOf(s), y)`.
The second statement ensures BunchOf is the smallest relation satisfying the first property. This is what's called logical minimization.

Quiz

Which of the following is true?

States in PDDL are allowed to have negations of literals.
The ignore preconditions heuristic drops all the preconditions from actions.
There exists planning problems for which the the corresponding planning graph is exponential size.

Measurements

In both scientific and common sense theories of the world, objects have height, mass, cost, etc.
To model these, we imagine the world has abstract measure objects such as length.
Often the same length, has different values in different units. For example 1in = 2.54cm. We represent units using units functions such as `Inches(d)`.
Conversion between units can be done using conversion functions: `Inches(d) = Centimeters(2.54 times d)`.
We can now uses measures to describe objects with expressions like:
`Diameter(Basketball_3) = Inches(9.5)`.
`ListPrice(Basketball_2) = $(19)`.
`d in Days => Duration(d) = Hours(24)`.
Often what one uses to reason about measure is an ordering `>` rather than the specific values.

Events

We would like to be able to express things like the state of the world at a given time and also facts about things that were true during the time it took for an action to take place (unlike say in PDDL or things like the situation calculus which can't say anything except before and after events.)
To do this we will briefly describe an event calculus. This calculus has three types of objects: events, fluents, and time points.
Events for us will be instances of the events category.
As an example, the event `E_1` of Shankar flying from SF to Washington, D.C. might be described in this calculus as:
`E_1 in Fl\y\i\ngs ^^ Fl\y\e\r(E_1, Shankar) ^^ Orig\i\n(E_1, SF) ^^ Dest\i\nation (E_1, DC)`
Any `E_1` making the above formula hold would represent the Shankar flying from SF to Washington, D.C. We can hence tack on additional information about the event by adding predicates that must also hold of it, for example, `Bumpy(E_1)`.
Unlike in PDDL, fluents in the event calculus are terms which can be substituted into a fixed set of predicates useful for reasoning about event. For example, `T(At(Shankar, Berkel\ey), (t_1, t_1))` asserts the fluent `At(Shankar, Berkel\ey)` is true over the interval `(t_1, t_1)`.
A time interval has a start and end time `(t_1, t_2)`.
When framing an event calculus problem, the framer may choose particular predicates they are interested in such as `Bumpy(E)` and provide axioms for it.
A framer also typically makes use of common event calculus predicates such as those defined by Shanahan 1999:
`T(f,t)` Fluent `f` is true at time `t` or interval `t`
`H\a\ppens(e,i)` Event `e` happens over the interval `i`
`Initiates(e, f, t)` Event `e` causes fluent `f` to start to hold at time `t`.
`T\e\r\m\i\n\a\tes(e, f, t)` Event `e` causes fluent `f` to stop holding at time `t`.
`Clipped(f, i)` Fluent `f` ceases to be true at some point during the interval `i`.
`Res\t\o\r\ed(f, i)` Fluent `f` becomes true sometime during the interval `i`.
These common predicates in Shanahan also come with standard axioms they satisfy such as:
`T(f, (t_1, t_2)) iff [forall t (t_1 < t < t_2) => T(f,t)]`
In a event calculus knowledge base, we usual assume, we have a distinguish Start event that is described by some formula and indicates what is true at the start time.
We can describe what fluents are true at what point in time using pairs of "successor state" axioms `T` and `neg T` (book gives general format).
Once set up, a logical agent can reason from such a KB about what is true at a given time and act accordingly.

Reasoning Systems for Categories

We would now like describe techniques to integrate reasoning with knowledge systems based on categories
Two important approaches to this are semantic networks and description logics.
We describe the first of these two for the rest of this slide.
A typical Semantic Network is illustrated above. Objects and Categories are represented with ovals or boxes and connections between them are represented with labeled links. If the link is between objects within categories then it has a double box
Notice the labelled arcs in the above to nowhere... These are used to represent default values.
SemanticsNetworks are often used to perform inheritance reasoning based on graph algorithms to determine what properties an object has. Notice they don't easily support n-ary relations so are somewhat limited.

Description Logics

Description Logics are first-order logics geared towards making it easier to describe definitions and properties of categories.
They evolved from an attempt to formalize semantics networks more precisely.
They are geared toward three inferences tasks: subsumption - checking if one category is a subset of another, classification - checking whether an object belongs to a category, and consistency whether the membership criteria of a category is satisfiable or empty. Not all systems can handle support efficient consistency checks.
The image above is an example description logic called CLASSIC.
Using CLASSIC we could then represent facts about the world such as:
Bachelor = AND(Unmarried, Adult, Male).
A more complicated example might be:
`And(Man, AtLeast(3,Son), AtMost(2, Daughter),`
`quad All(Son, And(U\n\e\m\p\l\o\y\e\d, Mar\r\i\ed, All(Spouse, Doct\o\r))),`
`quad All(Daughter, And(Profes\s\o\r, Fills(Depa\r\t\m\e\nt, Physics, Math))))`
Subsumption testing in such a description logic is often p-time and typically involved using unification. i.e., the same techniques as first-order logic but we have weakened the system enough to get better algorithms for subsumption. (The drawback of doing this is it often means hard problems have very long descriptions.)
Notice DL, doesn't have a notion of negation, and only limited disjunction in Fills and OneOf, this is why it is weaker than usual first-order.

Circumscription

Circumscription is a more powerful version of the closed-world assumption.
We specify particular predicates that are assumed to be "as false as possible". That is, false for every object except those for which they are known to be true.
For example, if we want to say by default birds can fly, we introduce a circumscribed predicate `Abn\o\r\m\a\l_1(x)` and write:
`Bird(x) ^^ neg Ab\n\o\r\m\al_1(x) => Flies(x)`
A circumscriptive reasoner is entitled to assume `neg Abn\o\r\m\a\l_1(x)` unless `Ab\n\o\r\m\a\l_1(x)` is known to be true.
So we are allowed to conclude `Flies(Tweety)` from `Bird(Tweety)` if no other facts are known. However, if somewhere we are given the premise `Abn\o\r\m\al_1(Tweety)` then we can't derive this conclusion.
In circumscription, a sentence is entailed if it is true in all preferred models of the KB. Here a model is preferred relative to another if its abnormal objects are subset of the others.

Default Logic

Default Logic is another example of a non-monotonic reasoning system.
In default logic we have a sequence of default rules where a rule looks like:
`frac(P: J_1, ..., J_n)(C)` here `P` is a prerequisite, `C` is a conclusion and `J_i` are justifications.
For example,
`frac(Bird(x) : Flies(x))(Flies(x))`
We say `C` follows from `P` unless one of the justifications can be proven false.
We define the notion of an extension of a default theory to be a maximal set of consequences of a theory.
To determine a maximal set of consequences, we first guess a set of consequences containing the facts, and then see if it can derive back itself using only the facts, and the default rules.
One common example used in this area is the Nixon diamond which has two extensions:
`Republican(Nixon) ^^ Quaker(Nixon)`. (fact)
`frac(Republican(x): neg Pa\c\i\f\i\st(x))(neg Pa\c\i\f\i\s\t(x))` `frac(Quaker(x):Pa\c\i\f\i\s\t(x))(Pa\c\i\f\i\st(x))`
One extension is {Republican(Nixon), Quaker(Nixon), Pacifist(Nixon)} and {Republican(Nixon), Quaker(Nixon), not Pacifist(Nixon)}
If we guess the set {Republican(Nixon), Quaker(Nixon), Pacifist(Nixon)}, then we can derive the first two statements using the fact, and third using the rule on the right.

Knowledge Representation

Outline

GraphPlan - Spare Tire Example

Backward Search and Spare Tire Problem

GraphPlan Heuristics

Knowledge Representation

Coming up with Ontologies

Famous Ontologies

Categories and Objects

Physical Composition

Quiz

Measurements

Events

Reasoning Systems for Categories

Description Logics

Circumscription

Default Logic