Outline
- Knowledge Representation
- Ontologies and How to Model With Them
- In-Class Exercise
- Reasoning with Ontologies
- Nonmonotonic Logics
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:
- Cyc which was developed by Lenat and described in Lenat and Guha (1990). A group of logicians by hand built this system.
- DBPedia which was made by trying to extract categories, values, attributes in a semi-automated fashion for Wikipedia. (Bizer, et al 2007)
- TextRunner, which has built by parsing text documents from the web and trying to extract information from them. (Banko and Etzioni 2008)
- 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.
In-Class Exercise
- A camel is any animal with one or two humps. Express Camel(c) using the techniques of the previous slide, making sure to make use of the PartOf relation.
- Post your answers to the Nov 15 In-class Exercise Thread
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.
- 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)`
- The predicate `Happens(E_1, i)` could then be used to say this happened during time interval `i`.
- A time interval has a start and end time `(t_1, t_2)`.
- Other predicates the event calculus has are:
`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`.
- The book then gives example axioms this calculus is supposed to satisfy. For example, we have the axiom:
`T(f, (t_1, t_2)) iff [forall t (t_1 < t < t_2) => T(f,t)]`
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.
