Re: [crm-sig] Type hierarchy

martin Tue, 23 Oct 2001 10:08:41 +0300 (EET DST)

Dear Nick,

I enjoyed your note. I propose to turn it into a document about Type use, either as integral part of the standard (a kind of
extended scope note or introduction to the Type hierarchy), or as an application guide. We could become a bit more formal
on what a CRM-compatible thesaurus means. I have some minor comments about notation and examples. I underlined in
the attached document change proposals and comments. I tried to give my view on your open questions. Once we agree,
we could turn the dialogue into didactic pros and cons.

You may also like to read:
Ch. Bekiari and Martin Doerr "Documentation and Reasoning on Parts and Potential Wholes", Computer Applications in Archaeology, Conference 1999, Dublin Ireland, 14-18 April 1999.
In this paper, which was targeted at the museums comunity we deal more formally with properties from classes to metaclasses.

In Martin Doerr, Dimitris Plexousakis & Chryssoula Bekiari, A Metamodel for Part-Whole Relationships for Reasoning on Missing Parts and Reconstruction, To appear in Proc. of ER-2001, Yokohama, Japan, 2001.
we present a full logical formalism for properties from classes to metaclasses.

As promised, I propose a different solution to the gender problem...

Please other partners of the SIG to continue and take position in the issues Nick raised. I am particularly interested to learn, if Nick's
Note is comprehensible for members that did not follow the disscussion in Paris, as several participants expressed difficulties
to understand the meaning of Type in the CRM.

The full minutes of the Paris meeting will follow in a few days.

Best wishes, and my thanks to all participants for the great meeting.

Martin.

Nicholas Crofts wrote:

Note concerning the type hierarchy
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.
The type hierarchy contains four sorts of types:

As already noted elsewhere [Doerr & 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.

The type hierarchy may also contain additional 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".

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.

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.

The distinction between the 'E' hierarchy and the 'T' hierarchy is essentially technical. The Entity hierarchy consists of classes and can be considered as a structural hierarchy. In a relational database it would naturally be implemented as a set of tables. The Type hierarchy consists of instances and can be considered as a set of data values. It would naturally be implemented as a single table containing values. Despite these differences, the two representations are intended to be logically equivalent. 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.
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 isA(n) 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 isA(n) type Y", where Y is a super-type of X. Following my previous example: "a Coin (T24.1) is a Man-Made Object (T24)". It follows from this that we should also be able to make assertions of the form "subtype X isA(n) entity Y" where X is a subtype of type Y', corresponding to entity Y. e.g. "A coin (T24.1) is a 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.
When do we declare subtypes without a corresponding entity?
A subtype should be declared for a en existing implicit type (i.e. one which corresponds to an existing entity) iff it is needed to register a domain specific notion which would otherwise not be recorded and if it does not require properties in addition to those it inherits from the existing entity. If additional properties are required, a sub-entity would have to be declared.
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.
When to use the 'has type' property?
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 types. 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.)
When to use other property links to the type hierarchy?
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 not 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).
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.
Open questions
How should types such as 'language' be declared, which could 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, all floating types could be placed in the entity hierarchy?
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.
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?)
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...)
I hope some of the foregoing makes sense.
best wishes
Nick Crofts
References
[Doerr & Crofts 1999] Electronic Esperanto: The Role of the Object Oriented CIDOC Reference Model , Proc. of the ICHIM'99, Washington, DC, September 22-26, 1999
URL : http://cidoc.ics.forth.gr/docs/doerr_crofts_ichim99_new.doc

Nicholas Crofts
DAEL / DSI
rue David-Dufour 5
Case postale 22
CH - 1211 Genθve 8
tιl +41 22 327 5271
fax +41 22 328 4382

Nokia Game is on again.
Click here to join the new all media adventure before November 3rd.

Mon, 22 Oct 2001 14:47:59
by: Nicholas Crofts
Subject: [crm-sig] Type hierarchy To: CRM-SIG

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.

The type hierarchy contains four sorts of types:

As already noted elsewhere [Doerr & 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.
The type hierarchy may also contain additional 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".
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.
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.

The distinction between the 'E' hierarchy and the 'T' hierarchy is essentially technical. The Entity hierarchy consists of classes and can be considered as a structural hierarchy. In a relational database it would naturally be implemented as a set of tables. The Type hierarchy consists of instances and can be considered as a set of data values. It would naturally be implemented as a single table containing values. Despite these differences, the two representations are intended to be logically equivalent. 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.

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 isA(n) 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 isA(n) type Y", where Y is a super-type of X. Following my previous example: "T24.1 Coin is a T24 Man-Made Object ". It follows from this that we should also be able to make assertions of the form "X is a subtype of type Y corresponding to entity Y", "x.has type: X" implies "x instance of entity Y" , . e.g. "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.

When do we declare subtypes without a corresponding entity?

A subtype should be declared for an existing implicit type (i.e. one which corresponds to an existing entity) iff it is needed as the range of a property to register a domain specific notion which would otherwise not be recorded and if the subtype does not require properties in addition to those it inherits from the existing entity. If additional properties are required, a sub-entity would have to be declared. The terms "needed" and "require" are understood with respect to the functional scope of the CRM, and not with respect to an indepndent ontological principle.

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.

(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 "directly under" and " "for an existing type" vanishes.)

When to use the 'has type' property?

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

When to use other property links to the type hierarchy?

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 not 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).

(Martin: I fully agree with the above argument, but nevertheless I begin to doubt the justification for "language". 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 "has type" 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 "has type" property. Of course, a "language" is not a "linguistic object", but I argue that the use of the "has language" 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 "complementary polysemy" [Pustejovsky]. In other words, I do not argue that "French Language" isA Linguistic Object, but that "French text" isA Linguistic Object, and that "has language: French" is ambiguous to what French is meant, an adjective by the way. One could intuitively say about a linguistic object "This is French!"

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 "integral information", 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 "has material" property is well-justified. Other property links to the type hierarchy are all the "general" properties, "used general technique" etc. They refer to an unknown amount of instances of that type.)

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.

(Martin: I have the feeling, that two arguments are confused here: The position of the "gender property" and the nature of it. The wrong position of the gender property should not be an argument to maintain it. 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 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 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: "give me all males, human or not, described in this database", may be posed however.

Let us now assume, that "female" is well defined in Biological objects. From such a property, as from any other like "red" 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 "female" by the class (or Type) of "females", or the concept of a "Female". 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.

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 "Father". This does not hold for gender. Gender is only about the nature of the domain object. Another argument is to reserve classes for "rigid" properpties, tightly coupled with identity. This does not hold for "hot", 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 "painter" 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.

So, do we loose anything with deleting the "has gender" property? Yes: the hint where to document gender. This is however the job of the scope note. Particularly the "has type" 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 "has type: Olive Farmer, Researcher, Male, White, German, Hobby Photographer, Karateka, Go Player", the gender can be as clearly identified as any other of those concepts, e.g. by its "hierarchy" 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 "has language" as well, I would not object. Each link less is a sales argument, and causes less conflicts in future extensions.)

Open questions

How should types such as 'language' be declared, which could 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, all floating types could be placed in the entity hierarchy?

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: "we don't know how to classify them correctly". 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.

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.

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 "floating types" as Nick poses it, and the types "equivalent" 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. "T24 Man-Made Object" or better "T24 Man-Made Object Type", 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.

"Coin" 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 "AAT:coins" instance of "T24 Man-Made Object" (or "in class" in our DTD). This implies the existence of a "compatible" Type instance for each Type subclass, e.g. a "T24i Man-Made Object", which may or may not be part of a thesaurus "compatible" with the CRM. The semantics of "isA" in type hierarchies are normally given by the BT (broader term) relationship. Therefore I have proposed to introduce the property "BT(NT)" 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.

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?)

Martin: Types do have Appellations, as I demonstrated with the Clayton data. I have argued against the "has value" 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.

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

Martin: Currently, the "brought into existence" 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 "creations"?

I hope some of the foregoing makes sense.

best wishes

Nick Crofts

References

[Doerr & Crofts 1999] Electronic Esperanto: The Role of the Object Oriented CIDOC Reference Model , Proc. of the ICHIM'99, Washington, DC, September 22-26, 1999
URL : http://cidoc.ics.forth.gr/docs/doerr_crofts_ichim99_new.doc

[Pustejowsky] J. Pustejovsky (1995) The Generative Lexicon, MIT Press, 1995, ISBN 0-262-16158-3

Nicholas Crofts
DAEL / DSI
rue David-Dufour 5
Case postale 22
CH - 1211 Genθve 8
tιl +41 22 327 5271
fax +41 22 328 4382

Nokia Game is on again.
Click here to join the new all media adventure before November 3rd.
--0-1156642510-1003751245=:45283--

Re: [crm-sig] Type hierarchy

Reply via email to