<B><font size="5">Note concerning the type hierarchy</font></B>
<p><font size="4"><i>Mon, 22 Oct 2001 14:47:59&nbsp;<br>
by: Nicholas Crofts<br>
Subject: [crm-sig] Type hierarchy
To: CRM-SIG <crm-sig@ics.forth.gr>
<p><FONT size=3>
At our recent meeting in Paris there was some discussion about the role of the type hierarchy, the numbering of types and the appropriate methodological principles to apply. These notes are intended to present my understanding of these issues.</p>
<P>The type hierarchy contains four sorts of types:</P>
<LI>As already noted elsewhere [Doerr &amp; Crofts 1999], the type hierarchy implicitly contains a 'redundant' declaration of all types corresponding to the entities (classes) present under "E1 CIDOC Entity". These implicit type declarations also duplicate the hierarchical structure of the existing entity hierarchy. In Paris, I put forward the proposal that implicit types should be prefixed with the letter 'T', and use the same numbering as their corresponding entity. "E5 Event", for example, would correspond to "T5 Event". This proposition has not yet been adopted, but I should use this form of notation in the remarks which follow.</LI>
<LI>The type hierarchy may also contain <I>additional </I>sub types of the implicit types, thereby providing a higher degree of granularity than is expressed by the basic entity hierarchy. For example, a subtype "Coins" could be declared for "T24 Man-Made Object". I am not sure what rules should be adopted for numbering these sub types since they are assumed to be domain-oriented and specific to local systems. For present purposes I shall use a decimal notation such as "T24.1 Coin". </LI>
<LI>The third sort of types present in the type hierarchy are descendants of type hierarchies which do not corresponding to any entity in the entity hierarchy, such as 'language' and 'material'. The head types of these type hierarchies are currently assigned an 'E' number. This effectively avoids any possible conflict with the numbering of the entity hierarchy. However, in order to highlight their nature as 'types' I propose to adopt the same 'T' prefix as for other types. (I would argue that this approach is consistent in that it suggests the existence of an 'implicit' entity in the entity hierarchy, one that could be declared explicitly at a later date if required.). I shall refer to these type hierarchies as 'floating types' since are not be assigned to any position in the entity hierarchy.</LI>
<LI>The head type of the type hierarchy is E55 Type. This exists in the main entity hierarchy so it can correctly be referred to using the 'E' prefix. However, since it also represents the highest type in the hierarchy of implicit types, it could also be considered as equivalent to "E1 CIDOC Entity", and might therefore be numbered 'T1 CIDOC Entity". Alternatively, T1 might be declared as a sub type of E55 Type. This point needs further clarification.</LI></OL>
<P>The distinction between the 'E' hierarchy and the 'T' hierarchy is essentially technical. The Entity hierarchy consists of <I>classes</I> and can be considered as a <I>structural</I> hierarchy. In a relational database it would naturally be implemented as a set of tables. The Type hierarchy consists of <I>instances</I> and can be considered as a set of <I>data values</I>. It would naturally be implemented as a single table containing values. Despite these differences, the two representations are intended to be <I>logically equivalent</I>. Each entity in the E hierarchy corresponds to a type in the T hierarchy. When no corresponding type exists for a given entity it is merely for reasons of economy; the undeclared type can be considered as implicit. Conversely, a type for which has no corresponding entity exists in the E hierarchy corresponds to an implicit entity, which could be declared at a later stage if needed.</P>
<P>A consequence of the logical equivalence of the entity hierarchy and the type hierarchy is that the methodological rules which apply to the declaration of entities and sub entities also apply to types and subtypes. The 'Isa' rule should be applicable to both, so it should be possible of any sub-entity to say that "sub-entity X <I>isA(n) </I>entity Y", where Y is a super-entity of X. Thus, a "Person (E21) is a Physical Entity (E18)". Similarly, it should be possible for any subtype to say that "subtype X <I>isA(n) type</I> Y", where Y is a super-type of X. Following my previous example:
<u>&quot;T24.1 Coin&nbsp; is a T24 Man-Made Object &quot;</u>. It follows from this that we should also be able to make assertions of the form
<u>&quot;X is a subtype of type Y corresponding to entity Y&quot;, &quot;x.has
type: X&quot; implies &quot;x instance of&nbsp; entity Y&quot;</u> , . e.g.
&quot;my coin (has type: T24.1) is instance of Man-Made Object (E24)". We should bear in mind that the isA rule is intended to be inclusive: it is true iff any and all members of a sub-category are also members of the super-category. Pasta, for example is not a good specialisation of 'Italian food', since some pastas are not Italian.</FONT> </P>
<P><B><I>When do we declare subtypes without a corresponding entity? </P>
<DIR></I></B><FONT size=3>
<P>A subtype should be declared for an existing implicit type (i.e. one which corresponds to an existing entity) iff it is needed
<u>as the range of a property</u> to register a domain specific notion which would otherwise not be recorded and if
<u>the subtype</u> does not require properties in addition to those it inherits from the existing entity. If additional properties<I> are</I> required, a sub-entity would have to be declared.
<u>The terms &quot;needed&quot; and &quot;require&quot; are understood with
respect to the functional scope of the CRM, and not with respect to an
indepndent ontological principle.</u> </P>
<P>A subtype should be declared either directly under E55 or as part of a type hierarchy so declared (i.e. there is no corresponding entity) iff it corresponds to an implicit entity for which no properties are required in the scope of the CRM. This is assumed to be the case for E56 (T56) language, for example. No entity is declared in the CRM to represent language since we have no properties to record about languages other than their identity: the CRM does not describe or talk about languages. If this situation changes in the future, we would need to declare a 'language' entity in the entity hierarchy, and attach the relevant properties. </P>
<P><u>(Martin: I cannot understand clearly the difference between the two
definitions. My understanding is, that E56 is an example of the first one, at
least if we assume that E55 corresponds to entity E1., so the difference of
&quot;directly under&quot; and &quot; &quot;for an existing type&quot;
vanishes.)</u> </P></DIR></FONT><B><I>
<P>When to use the 'has type' property?</P></B></I><FONT size=3>
<P>All entities declared in the CRM have a 'has type' property. This enables instances of entities to be declared as belonging to a given sub
type. The logical equivalence of the types and entities means that assigning a sub type to an entity instance is logically equivalent to declaring it as an instance of an implicit sub-entity (a specialisation). It follows that one should only assign sub types which follow the 'isA' rule, i.e. where subtype Y isA type X and X is the type corresponding to entity X'. (This constraint may be represented in the property declarations using the appropriate T number) Furthermore, we can say that types assigned to the has type property should not be 'floating types', since these are not yet declared in the entity hierarchy and consequently cannot follow the isA rule. No instance of an entity in the CRM should have type 'language', for example, for this would imply that language is a specialisation of the entity to which the instance belongs. (If it can be established, that "language" is indeed a specialisation of some existing entity, then it should be reclassified.) </P>
<P>&nbsp; </P>
<P></FONT><B><I>When to use other property links to the type hierarchy?</P></B></I><FONT size=3>
<P>Some entities have additional properties which link into the type hierarchy. "E33 Linguistic Object", for example, has a property "has language (is language of): T56 Language". Property links of this sort can be seen as logically equivalent to links to entities. The fact that language is currently declared as a type, and not as an entity, reflects the fact that, as it stands, the CRM has very little to say about languages. It follows that the type to which the property link refers should <I>not</I> be a subtype of the entity. If it is, then the "has type" property should be used instead. In the current example this rule holds, it is not the case that a language is a linguistic object (as defined in the CRM). </P>
<P><u>(Martin: I fully agree with the above argument, but nevertheless I begin
to doubt the justification for &quot;language&quot;. It could be concluded from
implication properties that language is a Type in the way we use it in the CRM.,
e.g. French implies Canadian French, German implies Bavarian implies Lower
Bavarian etc. Then, the only reasonable instances I can see are texts. In that
case, it falls under the &quot;has type&quot; case, and does not justify either
an explicit subtype nor an explicit property, but it should be expressed in a
scope note on the use of the inherited &quot;has type&quot; property. Of course,
a &quot;language&quot; is not a &quot;linguistic object&quot;, but I argue that
the use of the &quot;has language&quot; property does not refer to the language
in its proper sense, but to the form of the text expression. This reminds me of
Pustejovsky's &quot;complementary polysemy&quot; [Pustejovsky]. In other words,
I do not argue that &quot;French Language&quot; isA Linguistic Object, but that
&quot;French text&quot; isA Linguistic Object, and that &quot;has language:
French&quot; is ambiguous to what French is meant, an adjective by the way. One
could intuitively say about a linguistic object &quot;This is French!&quot;</u> </P>
<P><u>I see a different case with Material: Materials have all properties of
classes, but their instances are not well-distinguished. As instances I would
regard quantities of matter, which have no persistent identity and no identity
that can be marked on them (except for the container). Materials are referred as
an &quot;integral information&quot;, i.e. summed up for an object. Therefore I
would argue, that it is very unlikely the respective entity of Material to
appear in the CRM hierarchy, so Material and the &quot;has material&quot;
property is well-justified. Other property links to the type hierarchy are all
the &quot;general&quot; properties, &quot;used general technique&quot; etc.</u></FONT><u>
They refer to an unknown amount of instances of that type.</u><FONT size=3><u>)</u> </P>
<P>In the light of the foregoing remarks, I would argued that the 'has gender' property of "E21 Person" should be maintained and should not be handled using the inherited "has type" property. Gender is not a good specialisation of Person, since many male, female and somewhere-in-between objects are not persons, inversely, many men and women are not fish. The CRM does not currently have a specific class for animals, other than E20 Biological Object, (which could also be taken to include plants, bacteria and biological material). However, something like an 'animalia' subclass will need to be included at some stage to meet the needs of natural history collections. This would be a natural place for the 'has gender' property. </P>
<P>(<u>Martin: I have the feeling, that two arguments are confused here: The
position of the &quot;gender property&quot; and the nature of it. The wrong
position of the gender property should not be an argument to maintain it. </u></FONT><u>To
my best knowledge, all plants have gender as well. Most are bisexual, but some,
like Kiwi, are heterosexual. If we take the phenomenon causally, by the role of<FONT size=3>
gametes merging, virtually all biological objects in the scope of the CRM have
gender, even though many classes have just one. This is an argument to place the
gender property to E20 Biological Object. The separation of gender is not
clearly bound to any other biological&nbsp; properties. Following CRM
methodology, a property is assigned to the most specialized, culturally
reasonable concept, which comprises all potential applications of this property
within the scope of the CRM. I see that clearly in E20. The question, to which
degree comparison of gender of humans and gender of non-humans is relevant in a
cultural sense, like the query: &quot;give me all males, human or not, described
in this database&quot;, may be posed however.</FONT></u> </P>
<P><font size="3"><u>Let us now assume, that &quot;female&quot; is well defined
in Biological objects. From such a property, as from any other like
&quot;red&quot; etc., one can build the class of objects sharing this property.
So the property can be described either by building a class, or by attaching a
property link. Both render the same information. Building a class means, that we
replace the adjective &quot;female&quot; by the class (or Type) of
&quot;females&quot;, or the concept of a &quot;Female&quot;. So, clearly, Female
isA E20 Biological Object without any doubt. The intersection of Female and
Person is not empty, and equal to Woman. So Genders are good specializations of
E20 Biological Object. If, in turn, we regard the comparison of animal and plant
gender with human gender as irrelevant, we can form Woman and Man, which are
good specializations of E21 Person.&nbsp;</u></font> </P>
<P><font size="3"><u>So when to use the one or the other? One argument to use
property links is, if the property is based on the relation to another object,
like &quot;Father&quot;. This does not hold for gender. Gender is only about the
nature of the domain object. Another argument is to reserve classes for
&quot;rigid&quot; properpties, tightly coupled with identity. This does not hold
for &quot;hot&quot;, and usually not for colours. Practically (as we want to
make systems and not philosophy), a property assigned with a class should be
stable enough during the object's life cycle not to cause too much noise in
retrieval. Now, in the CRM, the coupling to identity is a cultural question. We
had decided to model properties like &quot;painter&quot; etc., substantially
attributed to a person independent from events, as Types. Gender is without
doubt even more rigid. Transexual people could even be regarded as a class by
themselves. The phenomenon is more tied with their nature than being a painter.</u></font> </P>
<P><font size="3"><u>So, do we loose anything with deleting the &quot;has
gender&quot; property? Yes: the hint where to document gender. This is however
the job of the scope note. Particularly the &quot;has type&quot; link needs
multiple scope notes. Clearly, the CRM is not a data entry prescription. So it
is a weak argument anyhow. Does the deletion cause any confusion? No: in an
instance x, with &quot;has type: Olive Farmer, Researcher, Male, White, German,
Hobby Photographer, Karateka, Go Player&quot;, the gender can be as clearly
identified as any other of those concepts, e.g. by its &quot;hierarchy&quot; in
a thesaurus. The CRM foresees therefore the Type Type (or T55 Type), to classify
Types. Do we gain anything? Yes: simplicity. No one really appreciates the CRM
to be big. It should do its job, and its use should be clear. Property links
should not replace scope notes. If we can through out &quot;has language&quot;
as well, I would not object. Each link less is a sales argument, and causes less
conflicts in future extensions.)</u></font> </P>
<P><B><I>Open questions</P></B></I><FONT size=3>
<P>How should types such as 'language' be declared, which <I>could</I> be positioned in the entity hierarchy? Leaving them as 'floating' types suggests that we don't know how to classify them correctly. Would it be true to say that, in principle, <I>all</I> floating types could be placed in the entity hierarchy?</P>
<P><u>Martin: To my opinion Materials cannot be placed in the hierachy, due to
mathematical problems. Measurement Units may be seen as Appellation Types, I am
not sure. I would leave the statement: &quot;we don't know how to classify them
correctly&quot;. There is nothing bad about it. We can standardize only what we
understand well. No one understands everything well. This is not demonstrating
how bright we are.</u></P>
<P>The entity hierarchy leads down to, but does not include, instances of entities. The type hierarchy leads down to, but also appears to include, instance level types. This asymmetry seems to be required, for example, for 'E56 Language' and 'E57 Material'. The type hierarchies fail to do their job if they don't include entries like 'French' and 'Wood'. Do we need to make this distinction clear at a theoretical level, and possibly by differentiating the instance level data in the type hierarchy in some way? Failure to make the distinction might lead to problems if property links are made to "class level" types rather than instances.</P>
<P><u>Martin: I see the situation as follows: The Type hierarchy can be seen as
a metaclass hierarchy (Classes of classes, like sets of sets, nothing mystical).
So subclasses of Type like Language group together true classes like French. The
subclassing of Type helps us in a formal way to control inheritance of links
pointing to Types. Therefore I propose only the sets of &quot;floating
types&quot; as Nick poses it, and the types &quot;equivalent&quot; to entities
to be modelled as subclasses of Type. This solves Stephen's problem of
misleading inheritance of properties pointing to types. So, T20 Biological
Object is subclass of T1 Entity etc. &quot;T24 Man-Made Object&quot; or better
&quot;T24 Man-Made Object Type&quot;, as I have always put it, is the set of all
types a Man-Made Object can have - equivalent to the set of all possible
subentities of entity E24 Man-Made Object.</u></P>
<P><u>&quot;Coin&quot; however is a true instance of the Type metaclass, a class
or entity. Therefore I do not like the notation T24.1 Coin. I prefer
&quot;AAT:coins&quot; instance of &quot;T24 Man-Made Object&quot; (or &quot;in
class&quot; in our DTD). This implies the existence of a &quot;compatible&quot;
Type instance for each Type subclass, e.g. a &quot;T24i Man-Made Object&quot;,
which may or may not be part of a thesaurus &quot;compatible&quot; with the CRM.
The semantics of &quot;isA&quot; in type hierarchies are normally given by the
BT (broader term) relationship. Therefore I have proposed to introduce the
property &quot;BT(NT)&quot; in the CRM. This may sound complicated, but if we
want to formalize both, transition between classes and data, and detailed
property inheritance to parts of the type hierarchy in the CRM, we cannot avoid
the dualism. Actually SIS could treat correctly Types as metaclasses, but most
other data models cannot.</u></P>
<P>Types can have many names. Common names, scientific names, original names, etc. Should we give types an 'is identified by' link to appellation? (Incidentally, should appellation have a 'has value' property link to string?)</P>
<P><u>Martin: Types do have Appellations, as I demonstrated with the Clayton
data. I have argued against the &quot;has value&quot; property of Appellation:
For me the identifier of an Appellation instance is the value itself, so it has
not any other value except from being what it is.</u></P>
<P>Types are created by human beings, who can often be named. This is notably the case with biological taxonomy. What is the relationship between the type hierarchy and E28 Conceptual Object ? (This could open up a whole can of biological objects...)</P>
<P><u>Martin: Currently, the &quot;brought into existence&quot; link applies to
Types, so they can be created by humans in the CRM. I had hesitated in the past
to bring Types into Conceptual Objects, due to their double nature. May need
rethinking. Any good arguments? They are man-made. What are they not, which
Conceptual Objects currently are? Are all types &quot;creations&quot;?</u></P>
<P>I hope some of the foregoing makes sense. </P>
<P>best wishes</P>
<P>Nick Crofts</P>
<P>[Doerr &amp; Crofts 1999] Electronic Esperanto: The Role of the Object Oriented CIDOC Reference Model , Proc. of the ICHIM'99, Washington, DC, September 22-26, 1999</FONT>&nbsp;<br>
<FONT size=3>
URL : <a href="http://cidoc.ics.forth.gr/docs/doerr_crofts_ichim99_new.doc"> http://cidoc.ics.forth.gr/docs/doerr_crofts_ichim99_new.doc</a></P>
<P>[Pustejowsky] J. Pustejovsky (1995) The Generative Lexicon, MIT Press, 1995, ISBN 0-262-16158-3</P></FONT><BR><BR>Nicholas Crofts<br>DAEL / DSI<br>rue David-Dufour 5<br>Case postale 22<br>CH - 1211 Genève 8<br>tél +41 22 327 5271<br>fax +41 22 328 4382<p><br><hr size=1><b>Nokia</b> Game is on again. <br> <a href="http://uk.yahoo.com/nokiagame">Click here</a>  to join the new all media adventure before November 3rd.