Issue 340: Classes without properties

Starting Date: 
Working Group: 

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 (property for E20 proposed but rejected)



E27_Site (E27 Site is a E26 Physical Feature)




E40_Legal_Body - also discussed at the last SIG meeting

E45_Address (E45 to remain - justification unclear)


E48_Place_Name (keep with justification: "don't destruct gazetteers")

E50_Date (proposal to delete - to be updated) (to merge with E49 Time Appellation)


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 (

All the best,


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. 

Meetings discussed: