<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Dear Nick,
<p>I enjoyed your note.&nbsp; I propose to turn it into a document about
Type use, either as integral part of the standard (a kind of
<br>extended scope note or introduction to the Type hierarchy), or as an
application guide. We could become a bit more formal
<br>on what a CRM-compatible thesaurus means. I have some minor comments
about notation and examples. I underlined in
<br>the attached document change proposals and comments. I tried to give
my view on your open questions. Once we agree,
<br>we could turn the dialogue into didactic pros and cons.
<p>You may also like to read:
<br>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.
<br>In this paper, which was targeted at the museums comunity we deal more
formally with properties from classes to metaclasses.
<p>In Martin Doerr, Dimitris Plexousakis &amp; 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.
<br>we present a full logical formalism for properties from classes to
<p>As promised, I propose a different solution to the gender problem...
<p>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
<br>Note is comprehensible for members that did not follow the disscussion
in Paris, as several participants expressed difficulties
<br>to understand the meaning of Type in the CRM.
<p>The full minutes of the Paris meeting will follow in a few days.
<p>Best wishes, and my thanks to all participants for the great meeting.
<p>Nicholas Crofts wrote:
<blockquote TYPE=CITE>&nbsp;
<p><b><font size=+1>Note concerning the type hierarchy</font></b>
<p><font size=+0>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.</font>
<p><font size=+0>The type hierarchy contains four sorts of types:</font>
<font size=+0>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.</font></li>

<font size=+0>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".</font></li>

<font size=+0>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.</font></li>

<font size=+0>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
<font size=+0>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
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.</font>
<p><font size=+0>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: "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.</font>
<p><b><i>When do we declare subtypes without a corresponding entity?</i></b>
<dir><font size=+0>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<i> are</i> required,
a sub-entity would have to be declared.</font>
<p><font size=+0>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.</font></dir>
<b><i>When to use the 'has type' property?</i></b>
<p><font size=+0>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.)</font>
<p><b><i>When to use other property links to the type hierarchy?</i></b>
<p><font size=+0>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).</font>
<p><font size=+0>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.</font>
<p><b><i>Open questions</i></b>
<p><font size=+0>How should types such as 'language' be declared, which
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?</font>
<p><font size=+0>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.</font>
<p><font size=+0>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?)</font>
<p><font size=+0>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...)</font>
<p><font size=+0>I hope some of the foregoing makes sense.</font>
<p><font size=+0>best wishes</font>
<p><font size=+0>Nick Crofts</font>
<p><font size=+0>References</font>
<p><font size=+0>[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>
<p><font size=+0>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></font>
<p>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
<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.</blockquote>
<br>&nbsp;Dr. Martin Doerr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Vox:+30(81)391625&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>&nbsp;Senior Researcher&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Fax:+30(81)391609&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>&nbsp;Project Leader SIS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp; Email: martin@ics.forth.gr |
Centre for Cultural Informatics&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Information Systems Laboratory&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Institute of Computer Science&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>&nbsp;&nbsp; Foundation for Research and Technology - Hellas (FORTH)&nbsp;&nbsp;
<br>&nbsp;Vassilika Vouton,P.O.Box1385,GR71110 Heraklion,Crete,Greece |
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Web-site: <A HREF="http://www.ics.forth.gr/proj/isst">http://www.ics.forth.gr/proj/isst</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;