[Crm-sig] Homework for Issue 340

[Athanasios Velios]

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

All the best,

Thanasis



On 10/04/17 19:52, martin wrote:
Dear All,

This is a concrete proposal to be discussed as issue.

Best,

Martin

On 10/4/2017 7:09 μμ, Robert Sanderson wrote:
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" 
<crm-sig-boun...@ics.forth.gr on behalf of a.vel...@gmail.com> 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
     Crm-sig@ics.forth.gr
     http://lists.ics.forth.gr/mailman/listinfo/crm-sig


_______________________________________________
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig