Issue 519: keep or deprecate P54 and P48?
In the 48th CIDOC CRM and 41st FRBR CRM sig meeting (virtual),the discussion regarding whether to keep existing properties with which Pxx has current permanent custodian (issue 473) would form a parallel construct to (P54, P48) should continue in a separate, new issue. The arguments made in favor and against, should be taken into consideration.
HW to RS to formulate the issue.
October 2020
Posted by Robert Sanderson on 03/03/2021
Dear all,
Thanks to Eleni for sending out the agenda and thereby reminding of our homework!
The proposal is to deprecate two properties, P48 has preferred identifier and P54 has current permanent location, following on from the conclusion of the discussion around the proposed property of 'has current permanent custodian' in issue 473.
As I recall it, the rationale for not adding 'has current permanent custodian' was not that the property did not make sense (it did) and not that it was not useful (it is), but that it was not necessary to add, as it is possible to add a classification to the activity that has the result of the transfer of custody, as to whether it is temporary or permanent.
The consequence of this was a (brief) examination of the specification for other properties where this pattern would be applicable, with the obvious deprecation candidates of P48 and P54.
The remediation pattern for P48 would be to add P2_has_type to the E41 Identifier to indicate preferred-ness, or the E13 attribute assignment / E15 Identifier Assignment of the identfier to the identified entity.
The remediation pattern for P54 would be to add a P2_has_type to the E9 Move to the location, in the same way that the resolution for 473 was to add P2_has_type to the Transfer of Custody.
The proposal should be considered separable -- not accepting the deprecation of P48 is not grounds for not accepting the deprecation of P54.
Posted by Dominic Oldman on 8/03/2021
Hi All,
This may well be the right approach, but I had a general point about these areas.
It would be useful to know the rationale behind them in the first instance. It occurred to me that perhaps the CIDOC-CRM needs to have some kind of associated knowledge base around it that points to the empirical work or evidence that led to the property in the first place so that we understand the origins of something. This is particular important as time goes by and different people join. So, it could be that items were, in hindsight, a mistake - that they are just vocabulary not ontology and not justified by practice, that they are borderline and there is a case for rationalisation, or that there has been a change of approach to these items.
It may be that we have some provenance here and I just need to look through the SIG forum etc. But I wonder whether this should be more formalised. This would strengthen the CIDOC CRM and provide more trust - but in any event the CIDOC CRM is not a top down ontology - it is a researched ontology and as an object of research it should be able to point to its underlying research, which is how the CRM should then be subsequently used - ontological commitments based on evidence.