Adjustment of the scope note of E55 Type

In the 41st joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 34th FRBR - CIDOC CRM Harmonization meeting, the sig reviewed the proposed scope note by CEO. They accepted the word  " "typically", but we need to be compatible with the text about types in the introduction of the CRM. The sig assigned to MD to re-write it.

Lyon, May 2018

Posted by Martin on 22/11/2018

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.
 

Posted by Øyvind on 23/11/2018

Thanks for this!

Some small comments and questions below.

> Am 22.11.2018 um 21:19 schrieb Martin Doerr <martin@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.

Posted by Christian Emil on 26/11/2018

The text is very good.  I have one comment, in my opinion one should not use the word "simulates"

P2:

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

could be changes to

"This provides a general mechanism to specialize the classification of CRM instances to any level of detail, by linking to external vocabulary sources, thesauri, classification schema or ontologies."

.1 property:

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

"

The idea of the .1 properties was to avoid numerous highly specialized properties,e.g. the way of producing objects found in the databases in British musuem. .1 properties were introduced before CRM became so closely connected with the simplistic RDF(S) formalism which introduced a lot of problems. 

Draft new text:

​"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 open for a specialization of  the property they are attached to through the use of property subtypes declared as instances of E55 Type."

In the 42nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 35th FRBR - CIDOC CRM Harmonization meeting, The crm-sig reviewed  MD’s text about types in the introduction of the CRM. The overall text has been accepted with minor modifications. It was proposed that the alternatives to the E21.xx Artist reference (in the types's text) be addressed in a separate issue –maybe it needs be dropped. However, it is mentioned in the context of unreferenced competing theories. MD has taken on to look for bibliography.  The old and the new text can be found here.

In the frame of the above discussion, the crm-sig assigned to  MD   the  HW of the issue 367 about  adding a subproperty to P2 such that it will allow pointing to the CRM property list exclusively (thus leaving P2 to do its work of typing the activity itself). 

Berlin, Novemebr 2018

Posted by Martin on 2/3/2019

Dear All,

For the test about types there was a question in which context a class "Artist" may have been defined. I found one in dbpedia:

http://dbpedia.org/ontology/Artist

I am not sure how to refer to this in our text. One may point to the utility of replacing classes with types for the mapping.

Reading the properties of this artist definition carefully, one may ask which of those are actually be restricted to artists, and which "make artists" out of a person: the awards. The latter is obviously common reasoning, but we would not populate the CRM with such secondary concepts for reasons of maintaining a core.

Posted by Robert Sanderson on 7/3/2019

One thing to note about the dbpedia ontology is that it is derived from the infobox sections of Wikipedia, mostly automatically.

So this could be a very artificial alignment, and I would not put too much emphasis on it as a precedent.

Posted by Martin on 8/3/2019

On 3/7/2019 11:02 PM, Robert Sanderson wrote:
>
> Martin, all,
>
> One thing to note about the dbpedia ontology is that it is derived from the infobox sections of Wikipedia, mostly automatically.
>
> So this could be a very artificial alignment, and I would not put too much emphasis on it as a precedent.
Yes, I see.

Nevertheless I like the "artist" example, because it is a vague attribution, but useful. Exactly the things we prefer to put in E55 Type.
I am intrigued by the different ways someone may be identified as artist. It reminds me the discourse about "my true mother" of George Lakoff in "Women, Fire and Dangerous Things". The question is of course, if we could find an ontology as example which makes some objective ontological distinctions, such as people having studied fine arts, or being organized in a community of artists, or make a living by producing art.
For reasoning with CRM classes, an interesting question is, if we can infer an artist from her products, or e.g., awards, without classifying the person.
 

Posted by Martin on 9/3/2019

On 3/9/2019 11:22 AM, Nicola Carboni wrote:
> Dear Martin,
>
>> Nevertheless I like the "artist" example, because it is a vague attribution, but useful. Exactly the things we prefer to put in E55 Type.
>> I am intrigued by the different ways someone may be identified as artist. It reminds me the discourse about "my true mother" of George Lakoff in "Women, Fire and Dangerous Things”. The question is of course, if we could find an ontology as example which makes some objective ontological distinctions, such as people having studied fine arts, or being organized in a community of artists, or make a living by producing art. For reasoning with CRM classes, an interesting question is, if we can infer an artist from her products, or e.g., awards, without classifying the person.
>
> That is indeed a tricky definition, and I agree that should not rely on an ontological commitment. In my opinion it should be dealt with a set of rules formalised by each institution depending on their view/culture reflect the conceptualisation of Artist.
>
> From a functional perspective, N3 is in my opinion the best way to go. A brief example would be:
>
> {?X crm:P14_performed ?Y . ?Y crm:p2_has_type "exhibition".}  => {?X a ex:Artist.} .
>
> it is pretty simple way to assign the class Artist to a person on the base of a set of rules. Could that work?

Yes. I believe non-IT experts could best handle a graphical tool, on which deduction paths could be highlighted.

Even the "?Y.?Y" above is distracting.

The only problem I see is that current automatic RDFS graphical visualizations are cluttered with meaninglessly huge URIs and bad layout, huge arcs circling around.

May be someone knows a good intuitive tool?

Posted by Christian Emil on 20/3/2019

Dear all,

A comment  to the artist discussion:

It has been a discussion in linguistics about mental types vs all information is in the text/utterance. My impression is that most scholars agree that agreed types are used by humans in language communication. This does not imply that all such types exist independently of the language(s) in question. 

It is well known form bilingual lexicography that the concepts (types) in two languages are not in a 1-1 correspondence. A simple example is the idea that a dictionary explaining language A for users of language B cannot be reversed to a dictionary for A users to understand language B, similarly for dictionaries design to support production.

AAT has the ambition to be universal in the sense that the concept identifiers in the English original is kept in the German, French, Dutch versions. This is not problematic for higher level concepts. However, it is my impression that as closer a term is to an everyday word in a language, the more problematic it is. Artist is an example. In Norwegian Art (kunst) and Artist (kunstner) are usually used about fine arts. In Russian художник (khudozhnik) has a much wider meaning, and also including craftsman and designer.

"Villa" is another example.

In AAT:

Hierarchical Position:

                Objects Facet

                .... Built Environment (hierarchy name) (G)

                …

                ............................................ rural houses (G)

                ............................................... country houses (G)

                .................................................... villas (G)

In the Swedish Rikstermbanken (term bank), we find the following definition  for villa

villa  sv

DEFINITION: friliggande småhus [free standing (small) dwelling house]

In Sweden the definintion of “free standing” in this case is «not less than 4 meter from any other house and a “småhus” will typically have two floors and 100-200 square meters and is found in suburbs and very fare from Villa di Medici.

All the concepts (including artist) mentioned above can be modelled as instances of E55 but in most cases different instances as the denotations/extensions are different