Thanks for this! Some small comments and questions below.
> Am 22.11.2018 um 21:19 schrieb Martin Doerr <mar...@ics.forth.gr>: > > 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. > Would ”category of things” be better English? > 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, > Uncelar to me. Besides others what? Other interfaces? Or other CRM classes? > 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 > Please change to ”by the producers themselves” > for each new product or product variant. > Øyvind > > -- > ------------------------------------ > 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 <mailto:mar...@ics.forth.gr> > Web-site: http://www.ics.forth.gr/isl <http://www.ics.forth.gr/isl> > _______________________________________________ > Crm-sig mailing list > Crm-sig@ics.forth.gr > http://lists.ics.forth.gr/mailman/listinfo/crm-sig
