13.2.3 Primitive Versus Derived Relations

Typically, you know more about a domain than a database of facts; you know general rules from which other facts can be derived. Which facts are explicitly given and which are derived is a choice to be made when designing and building a knowledge base.

Primitive knowledge is knowledge that is defined explicitly by facts. Derived knowledge is knowledge that can be inferred from other knowledge. Derived knowledge is usually specified in terms of rules.

The use of rules allows for a more compact representation of knowledge. Derived relations allow for conclusions to be drawn from observations of the domain. This is important because you do not directly observe everything about a domain. Much of what is known about a domain is inferred from the observations and more general knowledge.

A standard way to use derived knowledge is to put individuals into classes. We give general properties to classes so that individuals inherit the properties of classes. The reason we group individuals into classes is because the members of a class have attributes in common, or they have common properties that make sense for them (see the box).

A class is the set of those actual and potential individuals that would be members of the class. In logic, this is an intensional set, defined by a characteristic function that is true of members of the set and false of other individuals. The alternative is an extensional set, which is defined by listing its elements. For example, the class chair is the set of all things that would be chairs. We do not want the definition to be the set of things that are chairs, because chairs that have not yet been built also fall into the class of chairs. We do not want two classes to be equivalent just because they have the same members. For example, the class of green unicorns and the class of chairs that are exactly 124 meters high are different classes, even though they contain the same elements; they are both empty.

The definition of class allows any set that can be described to be a class. For example, the set consisting of the number 17, the Tower of London, and Julius Caesar's left foot may be a class, but it is not very useful. A natural kind is a class where describing objects using the class is more succinct than describing objects without the class. For example, "mammal" is a natural kind, because describing the common attributes of mammals makes a knowledge base that uses "mammal" more succinct than one that does not use "mammal" and repeats the attributes for every individual.

We use the property type to mean "is a member of class." Thus, in the language of definite clauses,


means that individual X is a member of class C.

The people who created RDF and RDF Schema used exactly the property we want to use here for membership in a class. In the language Turtle, we can define the abbreviation

@prefix   rdf: ⟨http://www.w3.org/1999/02/22-rdf-syntax-ns#⟩.
@prefix   rdfs: ⟨http://www.w3.org/2000/01/rdf-schema#⟩.

Given these declarations, rdf:type means the type property that relates an individual to a class of which it is a member. By referring to the definition of type at that URI, this becomes a standard definition that can be used by others and can be distinguished from other meanings of the word "type."

The property rdfs:subClassOf between classes specifies that one class is a subset of another. In Turtle,

rdfs:subClassOf C.

means that class S is a subclass of class C. In terms of sets, this means that S is a subset of C. That is, every individual of type S is of type C.

Example 13.10: Example 13.7 explicitly specified that the logo for computer comp_2347 was a lemon disc. You may, however, know that all Lemon-brand computers have this logo. An alternative representation is to associate the logo with lemon_computer and derive the logo of comp_2347. The advantage of this representation is that if you find another Lemon-brand computer, you can infer its logo.

In Turtle,

:lemon_computer rdfs:subClassOf :computer.
:lemon_laptop_10000 rdfs:subClassOf :lemon_computer.
:comp_2347 rdf:type :lemon_laptop_10000.

says that a lemon computer is a computer, a lemon laptop 10000 is a lemon computer, and that comp_2347 is a lemon laptop 10000. An extended example is shown in Figure 13.2, where the shaded rectangles are classes, and arcs from classes are not the properties of the class but properties of the members of the class.

Figure 13.2: A semantic network allowing inheritance

The relationship between types and subclasses can be written as a definite clause:

     prop(X,type,S) ∧

You can treat type and subClassOf as special properties that allow property inheritance. Property inheritance is when a value for a property is specified at the class level and inherited by the members of the class. If all members of class c have value v for property p, this can be written in Datalog as

prop(Ind,p,v) ←

which, together with the aforementioned rule that relates types and subclasses, can be used for property inheritance.

Example 13.11: All lemon computers have a lemon disc as a logo and have color yellow and color green (see the logo and color arcs in Figure 13.2). This can be represented by the following Datalog program:
prop(X,has_logo,lemon_disc) ←
prop(X,color,green) ←
prop(X,color,yellow) ←

The prop relations that can be derived from these clauses are essentially the same as that which can be derived from the flat semantic network of Figure 13.1. With the structured representation, to incorporate a new Lemon Laptop 10000, you only declare that it is a Lemon Laptop 10000 and the color and logo properties can be derived through inheritance.

RDF and Turtle do not have definite clauses. In these languages, instead of treating the membership in a class as a predicate, classes are sets. To say that all of the elements of a set S have value v for a predicate p, we say that S is a subset of the set of all things with value v for predicate p.

@prefix rdfs:  <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rdf:   <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix owl:   <http://www.w3.org/2002/07/owl#>.
@prefix :      <#>.

:computer    rdf:type  rdfs:Class.
:logo        rdf:type  rdfs:Class.
:lemon_disc  rdf:type  :logo.
      rdf:type    rdf:Property ;
      rdfs:domain :computer ;
      rdfs:range  :logo.
      rdf:type        rdfs:Class ;
      rdfs:subClassOf :computer ;
           owl:ObjectHasValue(:has_logo :lemon_disc).
Figure 13.3: Turtle representation of Example 13.12

Example 13.12: To state that all lemon computers have a lemon disc as a logo, we say that the set of lemon computers is a subset of the set of all things for which the property has_logo value lemon_ disc.

A representation of this is shown in Figure 13.3. :computer and :logo are both classes. :lemon_disc is member of the class :logo. :has_logo is a property, with domain :computer and range :logo. :lemon_computer is a subclass of :computer. It is also a subclass of the set of all individuals that have value :lemon_disc for the property :has_logo.

owl:ObjectHasValue is a class constructor for OWL (see below), such that owl:ObjectHasValue(:has_logo :lemon_disc) is the class of all individuals that have the value :lemon_disc for the property :has_logo.

Some general guidelines are useful for deciding what should be primitive and what should be derived:

  • When associating an attribute with an individual, select the most general class C, such that the individual is in C and all members of C have that attribute, and associate the attribute with class C. Inheritance can be used to derive the attribute for the individual and all members of class C. This representation methodology tends to make knowledge bases more concise, and it means that it is easier to incorporate new individuals because they automatically inherit the attribute if they are a member of class C.
  • Do not associate a contingent attribute of a class with the class. A contingent attribute is one whose value changes when circumstances change. For example, it may be true of the current computer environment that all of the computers come in brown boxes. However, it may not be a good idea to put that as an attribute of the computer class, because it would not be expected to be true as other computers are bought.
  • Axiomatize in the causal direction. If a choice exists between making the cause primitive or the effect primitive, make the cause primitive. The information is then more likely to be stable when the domain changes.