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"
<[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
_______________________________________________
Crm-sig mailing list
[email protected]
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
--------------------------------------------------------------
Dr. Martin Doerr | Vox:+30(2810)391625 |
Research Director | Fax:+30(2810)391638 |
| Email: [email protected] |
|
Center for Cultural Informatics |
Information Systems Laboratory |
Institute of Computer Science |
Foundation for Research and Technology - Hellas (FORTH) |
|
N.Plastira 100, Vassilika Vouton, |
GR70013 Heraklion,Crete,Greece |
|
Web-site: http://www.ics.forth.gr/isl |
--------------------------------------------------------------
