[Crm-sig] HW Issue 277

Martin Doerr martin at ics.forth.gr
Thu Nov 22 22:19:32 EET 2018


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: martin at ics.forth.gr
  Web-site: http://www.ics.forth.gr/isl

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20181122/cf37fb48/attachment-0001.html>


More information about the Crm-sig mailing list