Dear All,
Here my modifications:
About Types
Virtually all structured descriptions of museum objects begin with a
unique object identifier and information about the "type" of the object,
often in a set of fields with names like "Classification", "Category",
"Object Type", "Object Name", etc. All these fields are used for terms
that declare that the object belongs to a particular category of items.
In the CRM the class E55 Type comprises such terms from thesauri and
controlled vocabularies used to characterize and classify instances of
CRM classes.Instances of E55 Type represent concepts (universals) in
contrast to instances of E41 Appellation, which are used to name
instances of CRM classes.
For this purpose the CRM provides two basic properties that describe
classification with terminology, corresponding to what is the current
practice in the majority of information systems. The class E1 CRM Entity
is the domain of the property P2 has type (is type of), which has the
range E55 Type. Consequently, every class in the CRM, with the exception
of E59 Primitive Value, inherits the property P2 has type (is type
of).This provides a general mechanism for simulating a specialization of
the classification of CRM instances to any level of detail, by linking
to external vocabulary sources, thesauri, classification schema or
ontologies.
Analogous to the function of the P2 has type (is type of) property, some
properties in the CRM are associated with an additional property. These
are numbered in the CRM documentation with a ‘.1’ extension. The range
of these properties of properties always falls under E55 Type. Their
purpose is to simulate a specialization of their parent property through
the use of property subtypes declared as instances of E55 Type. They do
not appear in the property hierarchy list but are included as part of
the property declarations and referred to in the class declarations. For
example, P62.1 mode of depiction: E55 Type is associated with E24
Physical Man-made Thing. P62 depicts (is depicted by): E1 CRM Entity.
The class E55 Type also serves as the range of properties that relate
to categorical knowledge commonly found in cultural documentation. For
example, the property /P125 used object of type (was type of object used
in) /enables the CRM to express statements such as “this casting was
produced using a mould”, meaning that there has been an unknown or
unmentioned object, a mould, that was actually used. This enables the
specific instance of the casting to be associated with the entire type
of manufacturing devices known as moulds. Further, the objects of type
“mould” would be related via /P2 has type (is type of)/ to this term.
This indirect relationship may actually help in detecting the unknown
object in an integrated environment. On the other side, some casting may
refer directly to a known mould via /P16 used specific object (was used
for)/.So a statistical question to how many objects in a certain
collection are made with moulds could be answered correctly (following
both paths through /P16 used specific object (was used for) - P2 has
type (is type of)/ and /P125 used object of type (was type of object
used in/). This consistent treatment of categorical knowledge enhances
the CRM’s ability to integrate cultural knowledge.
Types, that is, instances of E55 Type and its subclasses, can be used
to characterize the instances of a CRM class and hence refine the
meaning of the class.A type ‘artist’ can be used to characterize persons
through /P2 has type (is type of). /On the other hand, in an art history
application of the CRM it can be adequate to extend the CRM class E21
Person with a subclass /E21.xx /Artist. What is the difference of the
type ‘artist’ and the class Artist? From an everyday conceptual point of
view there is no difference. Both denote the concept ‘artist’ and
identify the same set of persons. Thus in this setting a type could be
seen as a class and the class of types may be seen as a metaclass.Since
current systems do not provide an adequate control of user defined
metaclasses, the CRM prefers to model instances of E55 Type as if they
were particulars, with the relationships described in the previous
paragraphs.
Users may decide to implement a concept either as a subclass extending
the CRM class system or as an instance of E55 Type. A new subclass
should only be created in case the concept is sufficiently stable and
associated with additional explicitly modelled properties specific to
it. Otherwise, an instance of E55 Type provides more flexibility of use.
Users that may want to describe a discourse not only using a concept
extending the CRM but also describing the history of this concept
itself, may choose to model the same concept both as subclass and as an
instance of E55 Type with the same name. Similarly it should be regarded
as good practice to foresee for each term hierarchy refining a CRM class
a term equivalent of this class as top term. For instance, a term
hierarchy for instances of E21 Person may begin with “Person”.
E55 Type is, besides others, the CRM’s interface to domain specific
ontologies and thesauri or less formal terminological systems.. Such
sets of concepts can be represented in the CRM as subclasses of E55
Type, forming hierarchies of terms, i.e. instances of E55 Type linked
via P127 /has broader term (has narrower term)/. Such hierarchies may be
extended with additional properties. *Other, in particular richer,
standard models to describe terminological systems, can also be
interfaced with the CRM by declaring their respective concept class as
being identical with E55 Type, and their respective broader/narrower
relation as being identical with **P127 has broader term (has narrower
term), as long as they are semantically compatible.*
In addition to being an interface to external thesauri and
classification systems, E55 Type is an ordinary class in the CRM and a
subclass of E28 Conceptual Object. E55 Type and its subclasses inherit
all properties from this superclass.Thus together with the CRM class E83
Type Creation the rigorous scholarly or scientific process that ensures
a type is exhaustively described and appropriately named can be modelled
inside the CRM. In some cases, particularly in archaeology and the life
sciences, E83 Type Creation requires the identification of an exemplary
specimen and the publication of the type definition in an appropriate
scholarly forum. This is very central to research in the life sciences,
where a type would be referred to as a “taxon,” the type description as
a “protologue,” and the exemplary specimens as “original element” or
“holotype”.
Finally, instances of E55 Type or suitable subclasses can describe
universals from type systems not organized in thesauri or ontologies,
such as industrial product names and types, defined and published by the
producer himself for each new product or product variant.
--
------------------------------------
Dr. Martin Doerr
Honorary Head of the
Center for Cultural Informatics
Information Systems Laboratory
Institute of Computer Science
Foundation for Research and Technology - Hellas (FORTH)
N.Plastira 100, Vassilika Vouton,
GR70013 Heraklion,Crete,Greece
Vox:+30(2810)391625
Email: mar...@ics.forth.gr
Web-site: http://www.ics.forth.gr/isl
