Representing relationships with nodesJuly 9, 2008
To allow us to attach properties to instances of relationships, relationships must themselves have a node.
In the above diagram, the white circle in between (person) and (eye) is itself a node, and so we're back to being able to represent a relationship with a simple directed graph.
We can represent this notationally like this:
Complex relationshipsHow could we model "has zero or more"? One possibility:
This could be represented textually as:
Challanges with has_aJuly 9, 2008
The difficulty with the
has_a relationship becomes apparent when you try to represent the fact that a person has two eyes. The following doesn't do the trick, and raises the question: Does "has_a" imply that an entity has just
one of the specified thing?
In this instance, we can be clever and say:
(left_eye) (is_a) (eye)
(right_eye) (is_a) (eye)
(person) (has_a) (left_eye)
(person) (has_a) (right_eye)
|
|
But this approach doesn't work in the general case.
The
has_a relationship actually represents a couple related ideas:
1. | | has(n), where n is a number from 0 to infinity |
|
|
| has(0) means "has none of"
has(1) means "has one of"
has(2) means "has two of"
etc. |
| 2. | | has(n+), where n is a number from 0 to infinity |
|
|
| has(0+) means "has zero or more of"
has(1+) means "has one or more of"
has(2+) means "has two or more of"
etc. |
This gives us a lot more flexibility. For example:
| (person) (has(0+)) (sister) |
|
If you're uncomfortable with the fact that "eye" and "sister" aren't plural here, you need not worry: That is a carry over from the English language which isn't necessary to encode the bare meaning.
Although the use of
has(n) and
has(n+) does the trick in these cases, they represent a strict departure from one of our primary goals, which is to be able to represent knowledge with little more than a directed graph. This example underscores how tempting it is, even early on in the design process of an AI's knowledge representation, to abandon a directed graph representation.
A problem highlighted here is how we deal with relationships that are parameterized. Is there a way to represent parameterized relationships using a graph? In a sense, we already have, since every ternary relationship has one parameter: The relationship itself. (Remember that the fundamental relationship is the binary relationship which simply says that there is a relationship between two things but doesn't specify what that relationship is)
What is emerging here is that a relationship probably isn't best represented using just an edge of a graph. Instead, each instance of a relationship needs to be represented by its own node in the graph. This allows us to attach properties to the relationship itself.
Watered down has_aAnother strategy is to water down the
has_a relationship to mean "has zero or more of". The problem with this is that it doesn't tell us a whole lot. The advantage is that it maintains the goal of using a directed graph.
Specific but limited has_aA third strategy is to allow more precision but in a limited way by using specific relationships rather than generalized ones:
 | has_1 |
| has_2 |
| has_3 |
| has_4 |
| ... |
| has_0+ |
This is probably the weakest long term solution, but there is perhaps some merit in adopting its simplicity for the sake not abandoning our directed graph mandate while allowing for forward progress.
Complex "has"What is being hinted at here is that we need to represent the
has relationship with its own node and then attach properties to it.
The has_a relationshipJuly 9, 2008
The
is_a relationship allows us to encode a lot of information about the world, but it only gets us so far. The next logic step is to introduce the
has_a relationship which allows us to describe what something consists of. Some examples:
older >>
