Challanges with has_a

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?

(person) (has_a) (eye)

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(2)) (eye)

(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_a

Another 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_a

A 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.