Issue 340: Classes without properties

Starting Date: 
2017-04-09
Working Group: 
3
Status: 
Open
Background: 

Posted by Velios  on 9/4/2017

Dear all,

During the last SIG meeting Martin took a couple of chances to emphasise that CRM classes should always have properties. This is a bit inconsistent with one of the principles from the "Minimality" section of the CRM introductory text (version 6.2.2) which says:

"A class is not declared unless it is required as the domain or range of a property not appropriate to its superclass, or *it is a key concept in the practical scope.*"

It seems to me that it is difficult to define what a *key* concept is and why it qualifies as a CRM class instead of a E55 Type. I checked which CRM entities do not have any properties at all (again version 6.2.2) - some of them are already being discussed in open issues. I have produced a list alongside some relevant issues where I could find them:

E20_Biological_Object
  http://cidoc-crm.org/Issue/ID-76-contemporary-naming-procedure (property for E20 proposed but rejected)

E22_Man-Made_Object

E25_Man-Made_Feature

E27_Site
  http://cidoc-crm.org/Issue/ID-225-how-to-model-subfeatures (E27 Site is a E26 Physical Feature)

E34_Inscription

E37_Mark

E38_Image

E40_Legal_Body
  http://cidoc-crm.org/Issue/ID-328-rights-model - also discussed at the last SIG meeting

E45_Address
  http://cidoc-crm.org/Issue/ID-305-actor-appellation (E45 to remain - justification unclear)

E47_Spatial_Coordinates

E48_Place_Name
  http://cidoc-crm.org/Issue/ID-305-actor-appellation (keep with justification: "don't destruct gazetteers")

E50_Date
  http://cidoc-crm.org/Issue/ID-305-actor-appellation (proposal to delete - to be updated)

http://cidoc-crm.org/Issue/ID-260-review-specializations-of-appellation (to merge with E49 Time Appellation)

E84_Information_Carrier

If I understand this correctly, for each class we should check if we are missing important properties and a) if not, remove the class or, b) if yes, add the missing properties. If none of these two happens then we need define better what a *key* concept is.

I believe Franco and Martin had a similar discussion about Appellations last summer (http://cidoc-crm.org/Issue/ID-305-actor-appellation).

All the best,

Thanasis 

Posted by Robert Sanderson on 10/4/2017

I would add to that, that a class that only has relationships that are sub-properties of the parent class’s relationships does not count as “key”.

For example, the subclasses of E13 Attribute Assignment seem to simply be using class as a means of expressing the predicate of the reified relationship.  This could more cleanly be done with a P2 on E13 that refers to a Type … which is what we have to do for anything other than Condition, Identifier, Measurement, or Type assignments.  For example, Attribution and Dating are key assertions that museums make … yet they do not have assignment classes.

Of the classes below, my opinions:

E20:  In the core CRM, it seems like a pointless node between E19 and E21. For herbaria and natural history museums, on the other hand, it seems a crucial distinction.
E22:  It doesn’t have its own properties, but is important as the merging point in the hierarchy for E19,E24.
E25:  No opinion. As a join of E24 and E26 it makes mapping easier.
E27:  Delete as unnecessary leaf node.
E34, E37:  Delete as unnecessary leaf nodes
E38: I started off trying to justify … but the distinction with E36 is meaningless. Delete.
E40: Delete, unnecessary leaf node
E44, E45, E46, E47, E48, E49, E50, E51:  Delete. Just use Appellation.

 

Posted by Martin on 10/4/2017

Dear All,

This is a concrete proposal to be discussed as issue. 

Posted by Thanasis on  14/12/2017

Dear all,

In preparation for the next meeting, some homework from me. Happy to rework this after receiving comments. During the last meeting we decided to alter the text under Minimality to explain why some classes do not have properties.

## Current text
### Minimality
Although the scope of the CRM is very broad, the model itself is constructed as economically as possible.
* A class is not declared unless it is required as the domain or range of a property not appropriate to its superclass, or it is a
key concept in the practical scope.
* CRM classes and properties that share a superclass are non-exclusive by default. For example, an object may be both an instance of E20 Biological Object and E22 Man-made Object.
* CRM classes and properties are either primitive, or they are key concepts in the practical scope.
* Complements of CRM classes are not declared.

## Proposed text
### Minimality
Although the scope of the CRM is very broad, the model itself is constructed as economically as possible.
* A CRM class is declared when:
    * it is required as the domain or range of a property not appropriate to its superclass, *(this contradicts point 5 from Phase B of the [Principles for Modelling Ontologies document](https://docs.google.com/document/d/1RKJaD71idCcKKaTEdjw_dpPU5m1i13H3tb91hbs5iGU) which says "**not** 'anything that has this property'", I think it needs to be deleted)*
    * an identity property can be defined for it (i.e. a property which describes the intension of the class),
    * it serves as a merging point of two CRM class branches (e.g. E25 Man-Made Feature), *(I am not sure why this is useful, also this contradicts the point further down about multiple instantiation, i.e. there should be no practical need for CRM classes merging CRM branches if we use multiple instantiation, what am I missing?)*
    * it can be useful as a leaf class (i.e. at the end of a CRM branch) to domain communities building CRM extensions or matching key domain classes from other models to the CRM (e.g. E34 Inscription).
* CRM classes and properties that share a superclass are non-exclusive by default. For example, an object may be both an instance of E20 Biological Object and E22 Man-made Object.
* CRM classes and properties are either primitive, or they are key concepts in the practical scope.
* Complements of CRM classes are not declared.

As part of the same issue, Steve offered to share a reference for a standard to create application profiles for the SIG to consider if it would be useful for producing CRM profiles. The reference is here:

http://www.ukoln.ac.uk/projects/iemsr/wp2/lomap/index.html#sec5

Current Proposal: 

In 39th CRM-SIG meeting,  Thecrm-sig considering that CRM is not a suggestion of what to document but It tries to cover what people do document, discussed about classes without properties and how to decide about which of them are  useful and which of them are useless . 

Martin proposes: Reasons for Classes to Be:
A. has a property in or out
B. structural to IsA hierarchy
C. if a leaf is important matching point to some community that would map to and extend where properties would be added
 
Decision:The crm-sig accepted MD's proposal and decided to make the statement described this proposal and a justification to be written for each of existing classes that we will keep. 
HW is assigned to 
- Thanasis to write a  text on key concepts (can also go in principles document and in introduction), 
- Steve –to  write text about profiles
Heraklion, October 2017
 

Posted by Thanasis on 14/12/2017

<HW>

In preparation for the next meeting, some homework from me. Happy to rework this after receiving comments. During the last meeting we decided to alter the text under Minimality to explain why some classes do not have properties.

## Current text
### Minimality
Although the scope of the CRM is very broad, the model itself is constructed as economically as possible.
* A class is not declared unless it is required as the domain or range of a property not appropriate to its superclass, or it is a
key concept in the practical scope.
* CRM classes and properties that share a superclass are non-exclusive by default. For example, an object may be both an instance of E20 Biological Object and E22 Man-made Object.
* CRM classes and properties are either primitive, or they are key concepts in the practical scope.
* Complements of CRM classes are not declared.

## Proposed text
### Minimality
Although the scope of the CRM is very broad, the model itself is constructed as economically as possible.
* A CRM class is declared when:
    * it is required as the domain or range of a property not appropriate to its superclass, *(this contradicts point 5 from Phase B of the [Principles for Modelling Ontologies document](https://docs.google.com/document/d/1RKJaD71idCcKKaTEdjw_dpPU5m1i13H3tb91hbs5iGU) which says "**not** 'anything that has this property'", I think it needs to be deleted)*
    * an identity property can be defined for it (i.e. a property which describes the intension of the class),
    * it serves as a merging point of two CRM class branches (e.g. E25 Man-Made Feature), *(I am not sure why this is useful, also this contradicts the point further down about multiple instantiation, i.e. there should be no practical need for CRM classes merging CRM branches if we use multiple instantiation, what am I missing?)*
    * it can be useful as a leaf class (i.e. at the end of a CRM branch) to domain communities building CRM extensions or matching key domain classes from other models to the CRM (e.g. E34 Inscription).
* CRM classes and properties that share a superclass are non-exclusive by default. For example, an object may be both an instance of E20 Biological Object and E22 Man-made Object.
* CRM classes and properties are either primitive, or they are key concepts in the practical scope.
* Complements of CRM classes are not declared.

As part of the same issue, Steve offered to share a reference for a standard to create application profiles for the SIG to consider if it would be useful for producing CRM profiles. The reference is here:

http://www.ukoln.ac.uk/projects/iemsr/wp2/lomap/index.html#sec5

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 we agreed that having a class solely for merging branches is not a good enough reason as we can simply do multiple instantiation. The point is that the resulting class of the merged branches is narrower in scope from the what would result from multiple instantiation and therefore the   minimallity statement should be  rewritten in order to include the above decision. The sig asked Thanasis to rewrite the statement .

 

Lyon, May 2018

Posted  by Thanasis on 19/11/2018
Dear all,

Following discussion with Martin this is the new proposal for the Minimality section of the CRM introduction.

----------------------------
Although the scope of the CRM is very broad, the model itself is
constructed as economically as possible.

* CRM classes and properties are either primitive, or they are key
concepts in the practical scope.
* Complements of CRM classes are not declared because considering the
Open World Assumption, there are no properties for complements of a
class (see Terminology).
* A CRM class is declared when:

     * It is required as the domain or range of a property not
appropriate to its superclass.
     * It serves as a merging point of two CRM class branches (e.g. E25
Man-Made Feature). Instances of the resulting class are narrower in
scope than those declared through multiple instantiation of the two
branch superclasses.
     * It is useful as a leaf class (i.e. at the end of a CRM branch) to
domain communities building CRM extensions or matching key domain
classes from other models to the CRM (e.g. E34 Inscription).