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. Rob On 4/9/17, 7:26 AM, "Crm-sig on behalf of Athanasios Velios" <[email protected] on behalf of [email protected]> wrote: 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 -- Dr. Athanasios Velios Reader in Documentation - Ligatus Chair of the CCW Research Degrees Sub-committee University of the Arts London www.ligatus.org.uk +44(0)2075146432 _______________________________________________ Crm-sig mailing list [email protected] http://lists.ics.forth.gr/mailman/listinfo/crm-sig
