Re: [Crm-sig] Issue 616: shortcuts in P50 has current keeper, P52 has current owner, P55 has current location
Dear All,
I would also suggest to deprecate them, if there is no community
actively using them. Alternatively, we may think of a general, efficient
mechanism to assert that a property is still valid? This may go into the
Situation discussion.
Best,
Martin
On 11/28/2022 2:58 PM, Detlev Balzer via Crm-sig wrote:
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 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
Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
--
Dr. Martin Doerr
Honorary Head of the
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
Vox:+30(2810)391625
Email: mar...@ics.forth.gr
Web-site: http://www.ics.forth.gr/isl
___
Crm-sig mailing list
Crm
Re: [Crm-sig] Issue 616: shortcuts in P50 has current keeper, P52 has current owner, P55 has current location
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 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
> Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
___
Crm-sig mailing list
Crm-sig@ics.forth.gr
http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] Issue 617: Is P7(x,y) ∧ P89(y,z) ⇒ P7(x,z) still regarded as true?
Dear all, The question is: If an instance x of E4 Period took place at an instance y of E53 place, can we conclude that x took place at all places containing y? This was explicitly stated in CRMbase before the September meeting. The decission in Rome was to reformulate this as Therefore, this property implies the more fully developed path from E4 Period through P161 has spatial projection, E53 Place, P89 falls within to E53 Place, where the intermediate place is also defined in the same geometric system. FOL: P7(x,y) ⇒ (∃z,u) [E53(z) ˄ P157(x,u) ˄ E18(u) ˄ P157(y,u) ˄ P157(z,u) ˄ P161(x,z) ˄ P89(z,y) ] or simplified P7(x,y) ⇒ P161(x,z) ˄ P89(z,y) ] The answer to the question is that P7(x,y) ∧ P89(y,z) ⇒ P7(x,z) is in general is not considered true. This axiom has to be reintroduced if this is the general understanding. It is not needed in practical database/KB implementations. Best, Christian-Emil ___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] Issue 616: shortcuts in P50 has current keeper, P52 has current owner, P55 has current location
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 P55 need 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 Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
[Crm-sig] 55th CIDOC CRM & 48th FRBR/LRMoo SIG meeting -registration form (reminder)
Kind reminder - ignore if you have already registered. If you plan to attend the 55th CIDOC CRM & 48th FRBR/LRMoo SIG meeting and you haven't filled out the registration forms below, please take a moment to do so. best, E + Dear all, See below for a digest of the forms that you should be filling out in view of the 55th CIDOC CRM & 48th FRBR/LRMoo SIG meeting. * 55th CIDOC CRM & 48th FRBR/LRMoo SIG meeting registration form [1] * Hands-on seminar on semantic modeling using spatiotemporal constructs registration form [2] * Conference session on comparing perspectives of standards used by Librarians and Cultural Heritage specialists registration form [3]. For more information (time slots etc.), please check the agenda [4]. The purpose of sending these forms is to help the local organizers best plan the meeting (to make sure that we can all fit in the meeting rooms, share the links to Webex in time for the meeting - if you're planning on attending online - or even help book you a room at the IBIS). So please take a moment to fill out the information requested. PS: Below you can find useful information regarding your accommodation, getting to C2DH, and lunch options. I have CCed Muriel in the email if you need the help of the local organizers. * Options for accommodation: Muriel has prebooked a number of rooms at the IBIS (at the Unilu rate -96 euros/night, includes breakfast). She can always book more but not at the last moment. * Getting to C2DH: For trips from the Luxembourg airport to Belval, as for all trips in Luxembourg, the easiest and cheapest way is to take public transport (they are all free in Luxembourg). From the airport you take a bus to the train station, and from there a train to Belval. You can plan your journey on Mobiliteit.lu (https://www.mobiliteit.lu/fr/ [5]). They also have a very good app. * Options for lunch: No meals will be offered by the organizer. However, there will be plenty of coffee :) Lunch will be served in a private room at Labfood. The prices are 15EUR for a dish of the day, 20EUR for a starter, main course or main course and dessert and 25EUR for the complete formula starter, main course and dessert. Payments only in cash. * There are ATMs on the campus See also: https://wwwen.uni.lu/contact/belval_campus [6] All the best, Eleni Links: -- [1] https://docs.google.com/forms/d/e/1FAIpQLSdwSJVQ2wlb_6oh-BeagqaoWAGwlBd2CWnrfb-NZbK8w69CMQ/viewform?usp=sf_link [2] https://docs.google.com/forms/d/e/1FAIpQLSeimaWxIIx2SI8NR9U2occHyjP27fNtYF3JwLRUmZfN-DrVrg/viewform?usp=sf_link [3] https://docs.google.com/forms/d/e/1FAIpQLSenaoVfxk06Ox1r4BHiheNC249UmSV6rMmAMDywMXxGOknbFA/viewform?usp=sf_link [4] https://cidoc-crm.org/Meeting/55th-cidoc-crm-and-48th-frbr-crm [5] https://www.mobiliteit.lu/fr/ [6] https://wwwen.uni.lu/contact/belval_campus___ Crm-sig mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
