> > > Forgive me George for bringing up my original comment - it is entirely > possible that I have not understood the problem. >
V happy to discuss it. > > It seems to me that what is really missing is the connection between the > event and the outcome. It seems that you are saying that it is a causal > connection. Shortcutting that to the type of the outcome is exactly the > process of Typed Properties (TPs) and negating that is the process of > Negative Typed Properties (NTPs), both of which are still being baked. > Adding TPs to CRM base is a bad idea in my view, as it is a specific > solution for RDFS and it is not needed in other implementations. > > So maybe break down the problem to: > > 1) See if we need a new class for outcome > I argue that the outcome is an event (this being a possible sense of outcome). > 2) Define a causal property (which we have avoided so far) > o13 triggers basically does the trick > 3) Finish the TPs and NTPs, which I hope will be done soon > that would mean applying them to CRMSci I guess > > Maybe discussing live at the SIG is easier. > Probably! Cheers, G > > All the best, > > Thanasis > > On 07/01/2022 10:08, George Bruseker via Crm-sig wrote: > > Hi Rob / Francesco / Martin, > > > > These are all nice examples that maybe we could dig into further, maybe > > they display the 'senses of outcome' problem Martin is pointing to? > > > > An ontological problem that seems to come up in my mind as I try to > > conceptualize this is do we mean > > > > 1) outcome of type in the sense of a shortcut for a real particular > > event of a type (the particular event we do not know much about expect > > that it was caused by the first event and has some type) > > > > 2) outcome of a type in the sense of a shortcut for a real particular > > event that had particular properties (the particular event we do not > > know much about expect that it produced something, showed something, > > modified something and was caused by the first event) > > > > 3) outcome as an evaluation of achievement of an event (succeeds, fails) > > - we only talk about one event and evaluate whether it achieves its goal > > > > These can all cause trouble. > > > > So for example the JFK Assassination: > > > > (E7) Shooting at JFK, (E69) JFK dies > > > > So if we choose to model these as two separate events (legitimate), then > > Shooting of JFK had general purpose 'death' and we know in fact that the > > shooting triggers the death of JFK (no bullets in JFK, no dead JFK that > > day, the shooting caused the death). > > > > So the shortcut 'had outcome of type' could be 'death' just in case we > > didn't know anything about the particular death event of JFK and didn't > > want to instantiate it as a node. > > > > Shooting of JFK (E7) triggers Death of JFK (E69) has type "Death" (E55) > > > > So here it is that there is an event of type X that is shortcut. > > > > That would be sense 1. > > > > Sense 2 would be something like > > > > Shooting at JFK (E7) triggers Death of JFK (E69) kills JFK (E21) > > > > So here it would be the particular property of E69 to 'kill' an E21 that > > would be shortcuted > > > > We could also have sense 3, 'had outcome of type' 'success'. As in, the > > assassin had general purpose 'death' and the outcome was 'success'. > > > > How would this work in the other examples: > > > > An archeological expedition -- resulted in outcome of type "came > > home empty handed" / "found something" > > > > > > So we have an initial event > > > > Archeological Expedition (E7) has general purpose "Find Something" (E55) > > Archeological Expedition (E7) had outcome of type "Found Something" (E55) > > > > And then would the shortcut mean: > > > > a) Archeological Expedition (E7) triggered Dig Activity (A1) has type > > Found Something (E55) > > > > or > > > > b) Archeological Expedition (E7) triggered Dig Activity (A1) > > encountered Object (E22) > > > > (so here because E22 is 'something', the shortcut is true... that would > > seem more like a rule than a property) > > or > > > > c) Archeological Expedition (E7) had purpose Find Something (E55) > > Archeological Expedition (E7) had outcome of type Found Something (E55) > > > > So here it wouldn't imply a pass through to another event but would > > evaluate this event in itself. > > > > > > Commission of an artwork -- resulted in outcome of type "artist ran > > off with the money" / "artist produced something else" / "artist > > produced what was wanted" / ... > > > > > > Commission of Artwork (E7) had general purpose 'production of artwork' > > Commission of Artwork (E7) had outcome of type "artist ran off with the > > money" / "artist produced something else" / "artist produced what was > > wanted" > > > > And then would these shortcuts mean: > > > > a) Commission of Artwork (E7) triggered Production (E12) has > > type "artist produced something else" / "artist produced what was > > wanted" (E55) > > > > or > > > > Commission of Artwork (E7) triggered Activity (E7) has type "artist ran > > off with the money" (E55) > > > > So in the above cases it either shortcuts an E12 or an E7 which we don't > > have any details about but for which we would have classificatory terms > > like 'desired production', 'undesired production' OR 'theft/loss' or > > something like this. As per Martin's mail on types it falls to the > > vocabulary to tell us which CRM event type is implied... > > > > or > > > > b) Commission of Artwork (E7) triggered Production (E12) produced Some > > Object (E22) > > > > (so here because E22 is 'something', the shortcut is true... that would > > seem more like a rule than a property) > > But if we do this then we would have to put the 'desired production' or > > 'undesired production' categories on the E22 and the non production / > > non created thing would not be expressible. > > > > or > > > > c) Commission of Artwork (E7) had purpose "Build Something" (E55) > > Archaological Expedition (E7) had outcome of type "Built that Something" > > (E55) > > > > This above case however seems like it would be better covered by the > > Plans modelling since what makes something meet or not meet a criterion > > is complicated...? > > > > Exhibition planning -- resulted in outcome of type "exhibition" / > > "no exhibition" / "revised exhibition" / ... > > > > > > > > Exhibition Planning (E7) has general purpose "Run Exhibition" (E55) > > Exhibition Planning (E7) had outcome of type "exhibition" / "no > > exhibition" / "revised exhibition" (E55) > > > > And then would the shortcut mean: > > > > a) Exhibition Planning (E7) triggered Exhibition (E7) has type > > "Exhibition" / "Revised Exhibition" (E55) > > > > it seems here we have a problem with 'no exhibition' because we refer to > > a non existent > > > > We cannot say > > > > Exhibition Planning (E7) triggered Exhibition (E7) has type "No > > Exhibition" (E55) > > > > > > b) Exhibition Planning (E7) triggered Exhibition (E7) exhibited Object > > (E22) > > > > (so here because E22 is 'something', the shortcut for the positive > > exhibiting is true... that would seem more like a rule than a property) > > or > > > > c) Exhibition Planning (E7) had purpose "Exhibition" (E55) > > Exhibition Planning (E7) had outcome of type "Exhibition" (E55) > > > > If here we relate the outcome back to the domain activity, but we in > > reality separate the exhibition planning from the exhibition the > > statement is non sensical because exhibition planning is not the > exhibition. > > > > Conservation of object -- resulted in outcome of type "destroyed > > object by mistake" / "no change" / "repaired damage" / ... > > > > > > I won't tackle this one because I'm probably getting repetitive and I > > think the activity planning modelling is likely a more robust solution > > for this. > > > > So I agree that there are multiple senses that we would have to > > navigate. To my original thinking in putting this forward for > > discussion, the most sensible interpretation, if this is a good property > > at all, would be something like sense 1 where we meant that the shortcut > > shortcuts an event which we don't know much about except for its type > > and that it is caused by the first event. > > > > This would leave us with at least the problem of events that don't > > occur. Like 'no sale'. I think, however, maybe the example of the > > commissioning gives an idea of a way out of this. If the original > > intention of the commission is to trigger an E12 that is satisfactory, > > if the thing doesn't get made, but we classify the outcome as > > 'theft/artist ran away', it is not that the commission did not result in > > any other event, it just didn't result in an E12 of any sort. It > > resulted in an E7 of type theft. In the 'no sale', although we may not > > be privy to it, there may have been some furtive activities (E7) that > > tried to hawk the item. This anonymous E7 is a real event (attempting to > > hawk the item) and is legitimately classifiable as a 'no sale'. > > > > But maybe there are good arguments for sense 2 or 3 or yet another > > solution I haven't drawn out. > > > > Best, > > > > George > > > > > > > > _______________________________________________ > > 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 mailing list Crm-sig@ics.forth.gr http://lists.ics.forth.gr/mailman/listinfo/crm-sig
