Issue 378: Adding notes for most specific interpretation of properties

ID: 
378
Starting Date: 
2018-05-22
Working Group: 
4
Status: 
Done
Closing Date: 
2019-06-13
Background: 

In the 41st CRM-SIG meeting  the sig resolving the issue 275 discussed about the examples provided by Oyvind.  MD proposes new issue in the guidelines using CRM, where we may put notes. E.g.: someone involved in architectural project and we want to denote more info about this involvement… the note should not go on the person but on the event note (it should be assigned to the most characteristic node.). MD will do the HW.

Lyon, May 2018

Current Proposal: 

Posted by Martin on 6/6/2019

Dear All,

Here my trial guideline:

Frequently scholars and scientists would like to express more detail about a particular relation (property) between two entities than the type of the property itself expresses. These may be more details about the respective role or attitudes or arguments about the reliability of the information. In order to formally attach notes to properties in the currently dominant knowledge representation languages, one needs to replace the property by an equivalent path with an intermediate, auxiliary entity. Even though this mechanism has been provided for the CRM as "property classes", it considerably increases the complexity of the model and the user interface and decreases the performance of respective databases. The details given are in most cases not relevant in order to filter a large set of data by it. In that case they are relevant for the receiving user, but not for querying, and hence can be better expressed in a textual note.

The question that arises, is where to put the note, if not to an intermediate entity: to the domain instance or the range instance of the respective property. This is often intuitively done in the opposite way it should be done.

For instance: "Building house X"(E12) - P4 was carried out by - "John Smith"(E21)- P3 has note: "in the role of designer" sound perfectly logical, but is wrong!

This is the effect of context-free propositions in KR. The user sees the local context, but the note is attached to the person, not to the building activity. The role however does not hold for the person at all times, but only for this person in this activity. If "John Smith" will have another role in another activity, the context of this role becomes ambiguous. Therefore, if a note is meant to describe a property, but is instead attached to either domain or range instance, it must contain, in textual form, the path to the other entity instance.
This leaves two choices for the above example:
A)
"Building house X"(E12) - P4 was carried out by - "John Smith"(E21).
"Building house X"(E12) - P3 has note: "was carried out by John Smith in the role of designer"
B)
"Building house X"(E12) - P4 was carried out by - "John Smith"(E21) P3 has note: "performed Building house X in the role of designer"

Since the instance "Building house X"(E12) is actually the context for this role, or, in other terms, more specific to the property instance than the actor, the rule is to attach a note about a property to the more specific domain or range instance, as shown in choice A) in the above example, if the property is not going to be expanded by an intermediate entity. Then one has to repeat the missing path in the note as shown above.

Outcome: 

In the 44th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 37th FRBR - CIDOC CRM Harmonization meeting, τhe sig reviewed the text by MD on guidelines concerning the alternatives to using .1 properties. 
The text was accepted (post-editing) and was given the title: “Implementing properties of properties (.1) by using has note (P3). Given the disagreement with alternative (B), it was decided that it should be marked as a non-preferred option. Furthermore, it was decided that links should be made to the property class implementation presentation, to make sure that people using the crm are aware of that option. Last, the sig decided that the following document should go under CRM/The Model/Best Practices. 

The issue is closed.

Paris, June 2019
 

Reference to Issues: