Dear all,
I fully agree with Christian-Emil's observation that
> The current properties P50, P52 and P55 need external curation and
> also break the basic assumption that a CIDOC-CRM KB/database
> store accumulate history.
This is a point I had to raise over and over again in discussions about
database design: there is no notion of "now" if we are dealing with persistent
data.
> Maybe it is time to get rid of them?
Definitely. The reason why the idea of a "current" state of affairs is so
deeply rooted in the database world seems to come from the fact that almost any
textbook on the subject has silly examples such as "student: { name: Carla
Jones, age: 23 }".
Best,
Detlev
> Christian-Emil Smith Ore via Crm-sig <[email protected]> hat am 28.11.2022
> 12:31 CET geschrieben:
>
>
> Dear all,
> Wolfgang points to the fact that the 'current' properties is not defined in a
> consistent way, which of course they should have been. The textual scope
> notes says 'if and only if' which should be expressed as bidirectional
> implication, ⇔ (equivalence). Below I quite from an email exchange between
> Carlo and me. This may explain the issue:
>
> C-E:
> There are several axioms in CRM of the form lefthandside(x,y)⇒
> (∃z)[righthandside(x,y,z)], which is not a good thing, if I understand you
> right, due to efficient machine reasoning and the time it will take to find a
> needle z in the haystack.
>
> Carlo:
>
> Precisely. The computer enters into a combinatorial examination of cases and
> basically may never come back.
>
> and Carlo writes earlier in his reply, about claiming the existence of some
> individual on the right hand side of the implication:
> ' it's not outside of the model, it's that we do not know what to do with it,
> as you said, having a bunch of these "unknown" guys in the KB breaks
> efficiency. I understand that efficiency is an engineering issue, but in the
> end, we are engineers. '
>
> In my earlier days when I worked with formal logic and models, I didn't care
> very much about efficiency. However, I fully understand Carlo and also see
> the point that we formulate the FOL so that it can be efficiently computable.
> This is one reason to drop the bidirectional implication implication in the
> properties P50, P52 and P55.
>
> There is also another issue. The current properties P50, P52 and P55need
> external curation and also break the basic assumption that a CIDOC-CRM
> KB/database store accumulate history. It would have been better if the
> current properties are implemented as named and stored queries with the
> ting/person as argument. The original reason for introducing the current
> properties was they were used in some museum databases in the 1990ies,. Maybe
> it is time to get rid of them?
>
> Best,
> Christian-Emil
>
>
>
>
> P50 has current keeper
>
> This property is a shortcut for the more detailed path from E18 Physical
> Thing through, P30i custody transferred through, E10 Transfer of Custody, P29
> custody received by to E39 Actor, if and only if the custody has not been
> surrendered by the receiving actor at any later time.
> FOL:
>
>
> P50(x,y) ⇐ (∃z) [[E10(z) ⋀ P30i(x,z) ⋀ P29(z,y) ]
> ⋀ ¬ (∃w) [E10(w) ⋀ P30i(x,w) ⋀ P28(w,y)⋀ P182(z,w)]]
>
>
>
>
> P52 has current owner
>
> This property is a shortcut for the more detailed path from E18 Physical
> Thing through, P24i changed ownership through, E8 Acquisition, P22
> transferred title to to E39 Actor, if and only if this acquisition event is
> the most recent.
> FOL:
>
>
> P52(x,y) ⇐ (∃z) [[E8(z) ⋀ P24i(x,z) ⋀ P22(z,y) ]
> ⋀ ¬ (∃w) [E8(w) ⋀ P24i(x,w) ⋀ P23(w,y)⋀ P182(z,w)]]
>
>
>
>
> P55 has current location
>
> This property is a shortcut. A more detailed representation can make use of
> the fully developed (i.e., indirect) path from E19 Physical Object,through,
> P25i moved by,E9 Move, P26 moved to to E53 Place if and only if this Move is
> the most recent.
>
> P55(x,y) ⇐ (∃z) [ [E9(z) ⋀ P25i(x,z) ⋀ P26(z,y)]
> ⋀ ¬ (∃w) [E9(w) ⋀ P25i(x,w) ⋀ P27(w,y)⋀ P182(z,w)]]
>
>
>
>
>
>
> _______________________________________________ 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
