Defining Composite Categories
Our model now has some elementary categories and an attribute which can be used to construct composite categories. To form composite categories, we use the which operator. For example, type the expression below, select it, and browse it by clicking Browse on the right mouse-button menu.
Car which hasOwner Person.
Note the Browse option evaluates (compiles) the selection before opening a browser, so there is no need to evaluate it first (though it doesnt matter if you do). The first thing to note here is that this expression, unlike all the others weve met so far, does not add any knowledge to the model. Instead, it is a query which asks the terminology engine to return the category corresponding to the expression.
In order for the expression to be valid, and the evaluation to succeed, the relation must have been sanctioned at the sensible level. Recall that this sanction could come from a parent - in fact in this case it does, being inherited from the RoadVehicle category. To illustrate this you could try asking for, say, a Train which has an owner.
Notice that the object we asked for has been put in the appropriate place within the hierarchy. Its a child of Car, which is itself a child of RoadVehicle.
Although the attribute hasDriver has an inverse isDriverOf, it is important to remember that the categories they allow us to construct are different. If we ask for the category:
Person which isOwnerOf Car.
this is very different from a Car which hasOwner Person. The first expression provides us with a kind of Car, the second provides us with a kind of Person. People and cars are very different kinds of things: people are not kinds of cars nor are cars kinds of people.