Issue 340: Classes without properties
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
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 .
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 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 .
The decission to deprecate classes E38, E40, E44, E45, E46, E47, E48, E49, E50, E51 can be found in issue 367 (under the results of the 41st joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 34th FRBR - CIDOC CRM Harmonization meeting section).
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).
In the 43rd joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 36th FRBR - CIDOC CRM Harmonization meeting, the sig reviewed the text on the Minimality section of the introductory chapter of crm (HW by TV) and did some editorial work. The new text can be found here
Heraklion, March 2019
In the 44th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 37th FRBR - CIDOC CRM Harmonization meeting, the sig reviewed the text on the Minimality section of the introductory chapter of the CRM and did some further editing. The current version of the text reads:
Minimality
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, following 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 via multiple IsA (e.g. E25 Human-Made Feature). This is in contrast to using multi instantiation of the two superclasses for an item, as this results in the union of the scopes. The class that results from multiple IsA should be narrower in scope than the intersection of the scopes of the 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).
This is not the final version of the text. There were objections to the resulting text (even post editing) and it was decided that more thought has to be put in this text and then be discussed over again during the current sig meeting. Objections had to do both with phrasing of things (i.e. appealing to *branch superclasses*, as there are none) and with the overall purport of contrasting multiple inheritance and multiple instantiation, where the requirements for declaring a CRM class are listed.
It was decided that the issue be closed and that the revision of the sections on multiple inheritance and multiple instantiation --their formal definitions too --be made in a different issue.
Paris, June 2019