Posted by Vladimir Alexiev 11/6/2013
Proposal: add subclass of Activity called Discovery (or Finding).
Justification: for archaeological objects, quite often we don't have Production data, but we have data about the Discovery of the object (who, when, where).
Examples from the wild:
1. BM data has associations such as Excavated by, Found/Acquired by, Excavated/Findspot, etc.
In ResearchSpace we map this to a subclass as described above:
bmo:EX_Discovery rdfs:subClassOf crm:E7_Activity;
rdfs:label "Discovery"; rdfs:comment "The activity of finding, excavating or collecting an object".
See here:
https://confluence.ontotext.com/display/ResearchSpace/BM+Association+Mapping+v2#BMAssociationMappingv2-FoundBy
https://confluence.ontotext.com/display/ResearchSpace/BM+Association+Mapping+v2#BMAssociationMappingv2-Findspot
2. The Fundamental Relations TR (Doerr, Tzompanaki)
www.cidoc-crm.org/docs/TechnicalReport429_April2012.pdf
uses a made up (non-standardized) class C2.Finding (or C2.Finding_Event) for this purpose.
The TR gives a similar justification:
"Especially in the archaeological field of study, one is interested in Things found in a certain Place. This place could be a from (history) for this thing especially when the creation place is unknown."
3. CLAROS also singles out the Finding event,
but instead of rdf:type (i.e. an RDF class) uses P2_has_type with a blank node:
http://data.clarosnet.org/doc:jameel/object/EA1956.1145.ttl
crm:P2_has_type _38:Event_FindObject;
Here "_38:" indicates the blank node, and its use makes no sense (esp. because it's not present in the data)
Best regards! Vladimir
Posted by Stephen Stead on 11/6/2013
Vladimir
As you know we do/try not to add classes to the model unless it forms an
anchor for some properties or is structurally necessary. So what are the new
properties that justify the proposed new sub-class? The alternative is just
to type an instance of E7 Activity.
REgds
SdS
Just to add re the act of 'finding' objects, this is how the CRM-EH model which focusses on archaeological fieldwork works:
An Object is made through some (potentially unknown) Production event, eventually ends up in some archaeological deposit through some (potentially unknown) Deposition event and is subsequently excavated and recorded in context by an archaeologist before being accessioned (ie moved, catalogued, etc - more events) into some archival repository / museum.
Atb & hth,
Paul.
Posted by Vladimir 13/6/2013
As you know we do/try not to add classes to the model unless it forms an
anchor for some properties or is structurally necessary.
So what are the new properties that justify the proposed new sub-class?
Pxx_has_found:
domain: Exx Discovery
range: E77 Persistent Item
subprop of: P12i_was_present_at
Pyy_found:
domain: Exx Discovery
range: E39 Actor
subprop of: P14_carried_out_by
In case you object that one could simply use P12i and P14,
please note that exactly the same pattern is used e.g. for the four class-specific subprops of P1: P78, P87, P102, P131
The alternative is just to type an instance of E7 Activity.
CRM does not (and I guess never will) standardize P2_has_type values.
I think it's appropriate to standardize this concept that is important in the domain addressed by CRM (archaeology) and for FR search.
Best regards! V
Posted by Stephen Stead on 13/6/2013
I am warming to the idea.
However a few comments/suggestions
Pxx
The range should be E18 Physical Thing not E77 Persistent Item. In this sense you cannot discover an immaterial thing.
It should be a sub-property of P12 not P12i
The name should be Pxx has found (was found by)
Pyy
Name: Pyy performed by (conducted)
Needs Pyy.1 in the role of E55 Type or is there only one role for discovering?
I am not sure that this is needed as P14 and P14.1 covers this neatly already.
Perhaps you could formulate some scope notes for the Exx Discovery and Pxx plus something more compelling for the special nature of the role of the actor to justify Pyy?
Rgds
SdS
Encounter event sufficiently covers this issue. It is decided the issue to be closed and a new issue to be introduce to become the Encounter Event part of the CIDOC CRM
30th CRMSIG meeting, Hague April 2014