##
INTRODUCTION

An ontology is essentially a systematic model for how we break up the world around us into things. This clearly plays a role in perception, as it is the ontology that lets us construct mappings that say that to such and such a collection of qualia I will assign such and such a thing, hence allowing me to build a model of the world I inhabit. Ontology also plays a major role in language, in that language is itself an abstract formal means of communicating information, but that information more often than not consists of statements referring to objects, and it is an ontology that lets me translate these referring statements into things. So if you ask me to get you some strawberries, I use my ontology to translate the term ‘strawberry’ into something that I can recognise (red, small pips on surface, etc). Thus when one individual communicates to another, it is by using an ontology that they both connect referring terms in statements to referents in the world.

What this means is that if communication is to be unambiguous, the parties involved in the communication must share an ontology. Now, for the parties to completely share an ontology is in principle impossible, as demonstrated in our essay *Against Standard Ontologies*, but we can, by deliberately limiting the scope of our communication, limiting the complexity of our language and formalising the ways in which we refer to things, do something to minimise the risk of systemic confusion. Therefore this paper attempts to understand what formal structures are required to provide a sufficiently rich world-picture to enable useful communication, while keeping the level of formality sufficiently high that we can avoid systemic misunderstanding, and also while acknowledging that the robot’s world-view will be radically different to ours. This last point is crucial, in that it means that our ontology must exist at a sufficiently high level that none of the referring terms we wish to use in communication actually refer to sensory percepts. Rather there must be several levels of abstraction between any referring term and the qualia we expect to perceive when we recognise the referred thing.

## THE LANGUAGE

Before we get on to types, it is worth saying a little about what we expect of languages, because that will inevitably influence the way that we express a type system, and maybe even the kind of type system we use. I keep the discussion at the level of syntax and structural semantics rather than content.

### Basic structures

So, a language is a formal system with a vocabulary of symbols which can be combined in various ways to produce sentences. We posit the basic rules:

- Symbols in the language are functional or non-functional.
- Functional symbols can belong to two classes, that of referring terms and that of properties

So we have the beginnings of an ontology. Here non-functional symbols are connectives, such as ‘and’, ‘or’, etc. Symbols that are functional can refer to objects, or they can describe objects, and hence be properties. Note the crucial fact that I have not said that the division into referring terms and properties is exclusive: a symbol can be both a reference to a thing and a way of describing something else (e.g. ‘red’ is both a noun and an adjective).

In terms of an ontology, we have here defined two top-level and potentially overlapping kinds (that is to say concepts at a higher level than type): Referring and Property, so there are two top-level properties with these names that provide a basic classification. The next key step is the following:

- Given any referring symbol
*x* and description *P* then I can ascribe the property *P* to *x*, so I can form the sentence ‘*x* is *P*’.

And now I finally need:

- All sentences have a truth value.

### Truth values

Even the statement that sentences have a truth value is mired in controversy, because what do we mean by a truth value? Do we mean standard Boolean True and False, or do we include intermediate values like Unknown and Undefined, or do we go even further any allow a continuous-valued logic where the truth value is a probability? All of these choices are possible and have persuasive arguments in their favour: intermediate truth values are useful when knowledge is incomplete and probabilities are useful when it is uncertain. But suppose I am using probabilistic truth-values and I have a property *P* and I say ‘*x* is *P*’; do I mean by this that *x* is *P* with probability 0.3? It might mean that I am uncertain about what properties *x* has, and I am certain with probability 0.3 that it is has *P*, or it might mean that *x* is some mixture, a proportion of which, given by 0.3, is *P*. The first of these applications of probabilistic logic is uncontroversial; the second is problematic, for not all types can be mixed. Therefore we conclude that there are two kinds of probabilistic thinking:

- Truth values dealing with probability arising from uncertainty. A typical sentence is ‘
*x* is *P*’ which is true with probability *p*. This means that we are uncertain of the truth of sentence but believe that it is true with probability *p*.
- Truth values dealing with mixing. A typical sentence is ‘
*q*% of *x* is P*’* which, if it is true, means that we believe that *x* is a mixture, *q*% of which is *P*.

Note that the two kinds of probability may be combined, e.g. ‘*q*% of *x* is *P*’ with probability *q*.

### Properties and referring symbols

We can now consider a quite important question, which is whether types are always properties or whether it is possible to have a type that is not a property. Saul Kripke (in *Naming and Necessity*) argues that proper names are such types. That is to say, that ‘Julius Caesar’ is not a property, or even shorthand for a property, but is an unanalysed label picking out that one individual. This is, to say the least problematic. First, each of us may know what ‘Julian Caesar’ means to us, and we may be able to communicate about him, but it would be a very brave person to say that my idea of Caesar is the same as yours. Second, how does this picking out work in the absence of a property-based description? Surely ‘Julius Caesar’ is just a meaningless jingle to which we have assigned meaning by associating it with a number of properties. Now let us look at things the other way: is it possible to have a property that does not refer? The answer to this depends largely on whether or not we ascribe only extensional properties to a property. That is to say, if a property is defined only in terms of the set of objects of which it is true, then there is no need for it to refer. However, such an approach is extremely limiting because unless we have all properties of all objects pre-programmed into us, then we cannot use properties to describe an object we have not previously encountered. We do not have such pre-programming and neither will a useful robot; we have to be able to generalise. Therefore properties require a means of connecting them to the world of things, that is to say a way of referring to them.

If we take this thought to its furthest extent, it seems that the only real distinction between properties and referring symbols is that properties will in general refer to more than one thing. But even here the distinction is minimal, in that any collective symbol, e.g. ‘robot’ turns out on inspection to be nothing more than a description in disguise. It seems then that, if we follow Kripke:

**Property** *x* implies **Referring** *x*.
- There is a kind
**ProperName** such that **ProperName** *x *implies **Referring** *x*.
**Referring** *x* and not **Property** *x* implies **ProperName** *x*.

It is worth making a quick observation about free variables, that is to say symbols like ‘it’ or ‘the thing’ that allow one to substitute an desired entity in place of the symbol. These symbols are at first sight neither referring nor properties, and yet they can be either, e.g. ‘It is my head’ or ‘it is my favourite colour’, where in the latter ‘colour’ is object to the property ‘my favourite’ and yet is itself a class of property.

### Analysed and unanalysed symbols

Kripke also insisted that his proper names be unanalysed. There is considerable value in the concept of unanalysed symbols. At least one unanalysed proper name exists, that is to say ‘me’ (whether the ‘me’ be a human or a robot). Others exist in the form of objects that are self-evident, manifest facts in the universe of the speaker. So a robot may have a number of sensors which are, to it, things whose nature is fixed, whose identity is self-evident, and which have no properties other than existence. However, there are

two points here. First, the information produced by those sensors need not be unanalysed or undescribed. Second, to a human observing the robot, each sensor on the robot will belong to a particular type, which may itself be defined in terms of another type, and so on. Thus we see that ontologies are indeed relative.

So:

- There is a kind
**Unanalysed** which consists of symbols that are atomic, and are not defined in terms of other terms.
**ProperName** *x* implies **Unanalysed** *x.*
- There are a number of unanalysed properties.

Unanalysed symbols refer to the things that we do not need to have defined because they are manifest and obvious (and hence they are very slippery, e.g. I know that ‘me’ is well-defined, but ‘you’ is hugely uncertain). There are also descriptions that are unanalysed, so a robot does not need to analyse ‘sensor’ any further. We can build a hierarchy of symbols using the relation ‘is defined in terms of’, so when trying to define a symbol we analyse the way we describe it and then we define those descriptions by seeing how they are described, and so on until we reach unanalysed terms. Sufficient unanalysed terms must exist

that this hierarchy is finite. Therefore:

- The property symbols of the language form a finite hierarchy with relationships based on ‘is defined in terms of’. There are no
*a priori* constraints on the structure of the resulting directed graph save that it must contain no cycles.
- The resulting directed graph is rooted in symbols
*x* such that ‘**Unanalysed** *x*’ is true.

Note that this hierarchy is not a hierarchy in the usual ontological sense, because it is not based on the property that a description expresses. The hierarchy tell us how symbols are defined, not what they mean.

## THE TYPE SYSTEM

Now we have the basics and the top-level kinds settled, we can begin to consider what kind of model we should use for types. To start, let us see what we need to do with types.

### Ascription

First, given any entity we need to be able to ascribe a type to it. As noted above, this applies equally to things and properties: a thing can be of one or many types, and a property can also be of one or many types. Therefore:

- There should be a way to ascribe a type to a symbol in a language.

Before we go any further with this we need to ask is a type part of our language or not? All of the kinds I introduced above were metalinguistic and it may seem reasonable for types to follow that model, and so to inhabit a metalanguage rather than the language proper. This view therefore assumes that types cannot be reified, or at least cannot be described within the language, for they exist without it. But now consider a type like ‘mammal’; that this is a type might be disputed, but it is certainly treated as one in common usage. This type is clearly not metalinguistic as it can be defined in terms of other properties within the language, and so it seems that types must themselves be symbols within the language unless we want to limit quite severely the expressiveness of the type system. This proves to be quite a constraint, as most formal type systems rely on metalinguistic type labels. Once types become symbols within the language then one can have types of types and so on and so forth, as well as interaction between types and unanalysed terms. In particular, it means that the type system can evolve with the language, which is clearly a good thing. Therefore it is clear that considerable restraint is needed to ensure that whatever type system is used does not become over-complex. The constraint, to make up for this profusion of riches, is that we are now severely limited as to how the types are expressed and ascribed. Mechanisms such as the type-labels of the typed lambda calculus, though usable, become extremely limiting because now we have symbols acting in two roles depending on whether they are a referring symbol or an ascribed type. A much simpler, and more natural, approach is to treat types as predicates or properties within the language, so a referring symbol *x* is of type *T* if ‘*x* is a *T*’ evaluates to True.

- There is a kind
**Type** such that **Type** *x* implies **Description** *x* and all types have kind **Type**.
- Type ascription is effected by predication, so ‘
*x* is a *T*’ is a model sentence.

One may think that as a corollary of this, no unanalysed symbol may belong to any type within the language. But consider, ‘me’ is an unanalysed symbol, being a proper name, and yet it carries the description of ‘person’ or ‘robot’ or whatever. Therefore in fact any referring symbol can be ascribed a type.

### B. The type system

So we are now at the position that a type is a description of kind **Type** and we assert that a thing *x* has type *T* by saying ‘*x* is a *T*’. Now we need to discuss relations between types. A common model for ontologies is to use types that are formed into a hierarchy, so each object lies in a particular place on a tree of types, and so is a member of one type, which is itself a member of another and so on up to the root. We saw in *Against Standard Ontologies* that this model is untenable so something more complex is required. In order to clarify a possible confusion, note that types, being descriptions, are indeed hierarchical, but the hierarchy involves their definition and not their membership, that is to say type *T1* being defined in terms of type *T2* does not imply that everything that is a *T1* is also a *T2*. Therefore there is no inconsistency in our model.

So how are types organised? It makes immediate sense to introduce a relation along the lines of ‘is a’, on types which in fact generalises the predication relation that ascribes a type to an entity in a way consistent with our contention that types are referring symbols. Thus I can say ‘*T1* is a *T2*’ which implies

that if any *x* obeys ‘*x* is a *T1*’ then in addition ‘*x* is a *T2*’. Therefore:

- The relation ‘
*x* is a *T*’, where *x* is any referring object and *T* is a type or kind, is transitive, so ‘*x* is a *T1*’ and‘*T1* is a *T2*’ imply ‘*x* is a *T2*’.

Note that this means that the relation ‘is a’ is not that between class and superclass or between object and class, but is rather a more complex relation that comprises both of these. However it can be useful to think of a type as a class and a referring term as an object (recalling that classes themselves are objects), and I shall refer to this analogy with object-orientation repeatedly below.

So we can model types as a graph. There is no obvious a priori structure to this graph, in particular, any one entity may belong to more than one type, for example ‘sonar sensor’ is a ‘distance sensor’ and an ‘imaging sensor’, and though ‘sonar sensor’ and ‘imaging sensor’ both have type ‘sensor’ they are themselves distinct types. Therefore, in object oriented terms, we are dealing with a type system that allows multiple inheritance.

More intriguingly, we have noted above that even unanalysable descriptions may themselves have types. Therefore the unanalysable symbols are not themselves the roots of the directed graph constructed by the relation ‘is a’. We must, however, ensure that the graph of types is finite by avoiding cycles. There is a subtle point here. Consider the recursively defined binary tree type:

- If
**Type** *A* then a* Tree A* is either:
- A
*Leaf* , which is a value of type *A*
- A
*Node*, which is two *Tree A* one for each of the left-hand and right-hand sub-trees

Here, though the definition is infinite, the recursion is functional rather than one based on typology; that is to say, the type itself creates no recursion within the graph of types.

- Types form a directed graph based on ‘is a’ which is finite and contains no cycles.

However there is another point here, which argues against a purely graph-theoretic view of types, which is that a recursive type such as Tree is not well-described within such a hierarchy. In particular it is an example of the critical concept of a parameterised type, which leads us into the next section.

### Predication

Say I have a predicate *P* in my language, so I can apply it to any term *x* to create a new term *Px*. Say *x* has type *T1* and *P* has type *T2*, what type does *Px* have? Clearly it can depend only on *T2* or only on *T1*, and in some complex cases it can depend on the precise values of *P* and *x*. The obvious way of handling this is with generalised arrow types. Recall that a basic arrow type is a type

*T* = *T1* > *T2*

such that if *P* has type *T* and *x* has type *T1* then *Px* must have type *T2*. I want to generalise this a little. What we need of a predication type is first a guard expression which states that I can only compose *P* with *x *if the type of *x* obeys some condition, and second a rule which states that there is some function such that the type of *Px* is the result of applying this function to *x*.

- The most general form of type we need takes the form ‘
*Px* is a *Tx* provided *Gx*’, where *G* is a Boolean predicate and *T* is a predicate that maps referring objects to types.

Using this model I can describe the binary tree type above by saying that it takes any type *A* and returns, based on it, a type *Tree A* as defined above. This kind of parameterisation is absolutely crucial, for example, in data analysis and artificial intelligence, where I want to take streams of data from any number of sources, which might therefore have different types, but to apply standardised processing to them regardless of the underlying type. And, more to the point, this is something I cannot necessarily do with a standard object oriented inheritance paradigm, because the range of types I want to work with might be so disparate that in fact they share no meaningful common ancestor.

### Conclusion

In conclusion our need is for something quite subtle that involves a number of different structures, some based on object orientation, some closer to functional programming. We have to effect a difficult balancing act so as to keep them all in play and not allow any of the different paradigms to take over or become too complex.

### Like this:

Like Loading...

*Related*