I. Inheritance in relational networks
We can get more utility out of our hierarchies if we add
important and distinguishing properties (or features or
attributes, all of which are indicated by the links that tend
to go horizontally rather than vertically), like we did in
the dictionary example:
vertebrate
^
| is-a
|
| has-part
| /------------- wings
| / reproduction
| /--------------- egg-laying
| / body-temp
| /----------------- warm-blooded
bird--<< no. of legs
^ ^ ^ \----------------- 2
/ | \ \ covering
is-a / | \ \--------------- feathers
/ | \ \ movement
color / | \ \------------- flight
yellow ------canary | \
size / | is-a \ is-a
small -----/ | \ movement
| ostrich---------- run
movement | \ size
swim ----------penguin \--------- big
If we then allow what is called "inheritance" of these
features or attributes, we get a big win. Inheritance means
that one type inherits or takes on the properties of its
supertypes, assuming that there's no information to the
contrary. So, for example, we know that a canary's primary
mode of movement is by flight, even though we don't see that
explicitly represented as a property of canaries, because we
can see that a bird (the supertype of canary) moves by
flight. The canary subtype inherits the property of flight
from the bird supertype. If we didn't allow inheritance in
networks like this, we'd have to attach the property of
movement by flight to every appropriate node in the network.
Not only that, but we'd have to repeat every specific
property everywhere that we wanted it in the network, and
that would cost us a humongous amount of storage space. So
inheritance buys us economy of representation, although any
program that takes advantage of inheritance is going to have
to do some extra work to search around the network and find
out which properties are supposed to be inherited.
We can also make exceptions, and say that a penguin moves
primarily by swimming, even though it's a bird. We add that
property explicitly at the "penguin" node, and it overrides
the default property of movement by flight at the "bird"
node. So, in an "inheritance hierarchy" such as this,
properties are only passed from supertype to subtype when
there's no explicit information to the contrary stored with
the subtype.
II. Slot-filler representations
Semantic networks are based on an object-attribute-value
relationship. An alternative to semantic nets, but based on
the same object-attribute-value idea, is the slot-filler
representation. Here we group all the attribute-value pairs
for a single entity or object into something called a frame.
Within a frame, the attributes are called slots and the
values are called fillers.
Semantic networks have been useful in language processing
for representing the things in the domain of interest...that
is, the nouns...but they've been less useful in representing
the meanings of sentences, which are typically thought to
revolve around the verbs in those sentences. The slot-filler
representation is a more frequent choice for representing
sentence meanings, combined with some sort of primitive set
of actions. For example, one way of representing the
sentence "John went to McDonald's" might be, in CILOG,
[[action, ptrans], [actor, john], [object, john], [from, X],
[to, McDonald's]]
where actor, action, object, from, and to are the slots, and
ptrans is defined as the act of physically transferring an
object from one location to another. So the meaning of a
sentence that describes movement from one place to another is
represented as a ptrans frame with appropriate slots to be
filled in by values drawn from the nouns of the sentence. We
use a non-CILOG variation on this theme in the examples in
the accompanying slides, but you shouldn't have any problem
making the transition.
III. The importance of the knowledge representation
Way back in the early days of computing, folks were
fascinated by the possibility that computers might be able to
exhibit intelligent behavior if given the right kinds of
knowledge. Problems like solving puzzles and playing games
were thought to be great domains of study in the world of
artificial intelligence, as only an entity as intelligent as
a human could solve a tile puzzle or play checkers. As time
went on, artificial intelligence researchers realized that
solving puzzles and playing games could be mastered with
relatively little intelligence, while more mundane tasks such
as reading a newspaper article or frying an egg without
setting the house on fire required much more intelligence
than they previously thought necessary. Along the way,
however, AI folks have devoted a lot of thought to how to
represent the various kinds of knowledge required to get a
computer to do something that at least looks like intelligent
behavior. The ideas that have resulted from those efforts,
some of which we've talked about in this class, while by no
means conclusive, are now a part of mainstream computer
science; you may never do any AI work once you leave UBC, but
you may find these ideas worth knowing, regardless of where
your personal voyage through computing takes you.
As you venture into the world of game playing, you're now
faced with questions about what kinds of knowledge are
necessary to play the game and how you're going to represent
that knowledge. As noted above, these are the same kinds of
questions that AI folks have been wrestling with for years.
Resorting to broad sweeping generalizations, we can use five
questions (repeated from the previous lecture) to drive the
analysis of a complex problem, most of which involve
knowledge:
1) What exactly is the activity that you want from the
system you're going to create to solve this complex
problem?
2) What does your system need to know in order to perform
that activity?
3) How are you going to encode or represent that knowledge
inside your system? (e.g., What will the language of
symbols be? What will the symbols map to? etc.)
4) How will the system know which piece(s) of knowledge to
use at a given time, and how will the system get at the
appropriate knowledge without looking at all the
knowledge?
5) Once the system finds the appropriate knowledge, how will
it use the knowledge?
You can think of item 1 as "defining the task or function of
the system", items 2 and 3 as "defining the knowledge
representation of the system", and items 4 and 5 as "defining
the process of the system":
Task: what the system does (i.e., what's the goal of the
system?)
Knowledge: what the system needs to know to perform the
task
Process: how the system performs the task
The good news (according to AI guru Elaine Rich, from whom
most of this knowledge representation stuff is borrowed) is
that once a problem is described using an appropriate
representation, the problem is almost solved. The bad news,
however, is that describing the knowledge correctly is pretty
darn hard. Why? First, the knowledge to perform some
complex task well is usually fairly huge. Second, that
knowledge is probably pretty difficult to characterize
accurately. Third, if the system using that knowledge is
going to be flexible, that knowledge is probably not going to
remain constant; it'll probably change constantly.
If we were to try to draw inspiration from how humans
represent knowledge, we might first think of how humans
traditionally represent knowledge externally, for posterity.
A quick look at the library tells us that humans use
languages common to their respective cultures as well as
pictures. But while those representations might be useful
for transferring knowledge between individuals or between
generations (within limits...a lot of languages have died
over the past few thousand years), they're probably not what
humans use to represent large amounts of knowledge inside
their heads. For example, while there is undoubtedly some
text in your head, it would be easy to demonstrate that you
don't record everything you hear or read as if you were a
tape recorder. Similarly, while there's certainly imagery in
your head, the images are by no means exact duplicates of
what you saw...just ask any criminal lawyer who depends on
eyewitness testimony to make or break a case.
Text and pictures aren't very good representations for
computers, either. Why? They tend to be open to
interpretation: they're ambiguous (the same expression can
mean many things), they're vague (sometimes it's hard to find
any meaning), and the "vocabulary" of representation tends to
be huge and open-ended. That's why AI people invent
representation schemes like rules and semantic networks and
slots with fillers...these representations are unambiguous
and manageable.
So what makes a good knowledge representation scheme for a
computer?
IV. The specifics of knowledge representation
Before we get into the attributes of a good knowledge
representation scheme, let's get a little bit more specific
about what a knowledge representation scheme actually is. A
knowledge representation scheme is a set of conventions about
how to describe a class of things in some domain of interest.
A single description within that representation scheme makes
use of the conventions of that representation scheme to
describe some particular thing within that class of things.
A given representation needs a set of symbols (i.e., a
vocabulary) with some understood mapping between the symbols
and primitives in the domain being represented (e.g.,
objects, attributes, relationships, etc.). The
representation also needs some rules or conventions for how
to order or combine symbols into more complex expressions
which then become descriptions; these rules can be thought of
as a syntax or grammar for the representation language.
Finally, a representation scheme needs a set of operators or
procedures which permit the creation and manipulation of
descriptions. Sound familiar? It should, because this is
just an informal description of what was formally stated
about representation systems in Chapter 2.
V. What makes a good knowledge representation scheme?
There are a number of desirable characteristics of a
knowledge scheme. It's never possible to maximize all the
attributes; some will be sacrificed for others. But it's
always good to know what the trade-offs are so that you can
make better informed decisions.
1. The representation should capture generalities that exist
in the world that's being modelled.
2. The representation should be easily modifiable to reflect
changes so that new knowledge can be derived from old
knowledge (inference) or so that entirely new information
can be added (acquisition or learning).
3. It should be understandable by the people who provide the
knowledge as well as those who may have to look at it
later (so that they don't have to convert the knowledge
to or from some weird form they don't understand). This
attribute is also known as "transparency".
4. It should be usable even if it is not entirely accurate
or complete.
5. The important objects and relationships should be
explicitly represented.
6. Any natural constraints on how one object or relation
influences another should be obvious.
7. Irrelevant detail should be suppressed (but it would be
nice if you could get at the details when necessary).
8. The representation should be complete---you should be
able to represent everything that needs to be
represented.
9. It should be concise, in that you can say what needs to
be said efficiently.
10. It should be fast, in that you can store and retrieve
information quickly.
11. It should be computable, of course.
So now you're knowledge representation experts. Well, no,
not really. But you know all the right kinds of questions to
ask, and you know how to tell if some possible answers to
those questions are better than others. And that makes you
smarter, so what more could you ask for?
Last revised: December 7, 2004