Re: PROV-ISSUE-213 (prov-sem-events): Alignment of events in PROV-DM vs PROV-SEM [Formal Semantics]

Luc and James,

Is there anything left on this issue?

Thanks,
Tim

On Jan 31, 2012, at 10:47 AM, Luc Moreau wrote:

> Hi James,
> 
> Response interleaved.
> 
> On 01/31/2012 03:32 PM, James Cheney wrote:
>>>     
>>>> 
>>>>       
>>>>> An Interval is a pair of evetns: Event x Event
>>>>> 
>>>>> 
>>>>>         
>>>> I'm not sure of the reason for this.  (I'm also not sure my notion of interval as a pair of times is the right one though.)  Remember that times are only partially ordered, so any interval that we can describe with a pair of events, we can also describe with a pair of times.
>>>> 
>>>> 
>>>> Is the idea that the lifetime interval of an object should "bake in" its creation and destruction events?  What about objects that have been created but not (yet) destroyed?  (I guess this isn't handled carefully in the current version either.)
>>>> 
>>>> 
>>>>       
>>> Yes, that's ISSUE-204.
>>> My view is that we should define an activity interval as delimited by its start/end events.
>>> Likewise, an entity interval as delimited by its generation/destruction events.
>>> We still have to define destruction event. Stian suggested a form of usage event, which cannot be followed by any
>>> other usage event.
>>> 
>>>     
>> That seems fine; I am happy to add this.  Will we distinguish between "destruction" events and "change" events?
>>   
> 
> There is none in the data model. If there is a change, then you can express this as a new entity generation.
>>   
>>> 
>>>     
>>>> We should be careful to distinguish between an interval (a set of time points or events) vs. a pair of events or time points that forms the "boundary" of the interval.
>>>> 
>>>> For example, suppose we have two objects e1 and e2, both created at evt1 and destroyed at evt3.  Also, e1 experiences an event evt2 between evt1 and evt3 and e2 experiences evt2' between evt1 and evt3.  But we don't know evt2 precedes evt2' or vice versa.
>>>> 
>>>> Then I would claim that the lifetime of e1 is an interval {evt1,evt2,evt3} and that of e2 is an interval {evt1,evt2',evt3}.  But neither of these two sets can be described by the pair (evt1,evt3) if we interpret such a pair as the set of all events evt such that evt1<= evt<= evt3.  Nor can they be described by any other single such pair.
>>>> 
>>>>   So this makes me realize that PROV-SEM needs to be more careful about "intervals", but I'm not sure defining them to be pairs of events rather than pairs (or sets) of times is the solution.  (It may be that "interval" is the wrong word for what I'm trying to describe.)
>>>> 
>>>> Would defining lifetimes to be sets of events work?  (maybe subject to some closure constraint, such as if evt1<= evt2<= evt3  and evt1, evt3 in I then evt2 also in I)?
>>>> 
>>>> 
>>>> 
>>>>       
>>> But it's still the case that any evt2 is such that evt1<= evt2  and evt2<= evt3.
>>> 
>>> In the general case, for a given object, for two events evt2 and evt2', there may be no order between these events.
>>>     
>> I don't understand how this addresses my question, but it seems to be a separate issue from the earlier question of whether to change intervals from pairs of times to pairs of events.  I'm nto sure if it's a problem, so let's backtrack.
>> 
>> As long as an activity is linked to its creating and ending events in some other way, and likewise for entities and their creating/destroying events, I don't see why we can't use pairs of times instead of pairs of events for intervals.
>>   
> 
> I think I was trying to make the whole model independent of time, so that we just talk about ordering of events.
>> 
>>   
>>>>> Functions that take time as input should take event, e.g.:
>>>>>  value: Objects x Attributes x Events ->   Values
>>>>> 
>>>>> 
>>>>>         
>>>> I also am not sure I understand the rationale for this.  At an informal level, I think of "events" as marking transitions between states, not as surrogates for all of the time points.
>>>> 
>>>> There could be more times than events, for example:
>>>> 
>>>> object E created at time 1, destroyed at time 5; its initial "color" value is red; its color changes to blue at time 3.
>>>> 
>>>> There are three events (or at least I don't see why I would want to say there are more:
>>>> 
>>>> creation at time 1
>>>> change color red ->   blue at time 3
>>>> destruction at time 5
>>>> 
>>>> If we make value a function of Events and not Times then we need to introduce additional "nothing happened" events for time points 2 and 4 so that we can say that the object's color is still red at time 2 and still blue at time 4.
>>>> 
>>>> 
>>>>       
>>> I don't understand: if color is part of the characterization of this entity, it cannot change during this interval.
>>> 
>>> In fact, I notice you wrote "An Object ... has attributes with (potentially changing) values".
>>> 
>>> - A thing may have several attributes, potentially changing.
>>> - An entity has a given set of attributes with fixed values for an interval.
>>> - There may be other attributes of that thing that vary over this interval, but they are not attributes of the entity.
>>> 
>>> So, to me, you have describe two entities about that thing:
>>> 
>>> entity 1: color red [evt1,evt3[
>>> entity 2: color blue [evt3', evt 5[
>>> 
>>> evt3 corresponds to destruction of entity 1
>>> evt3' corresponds to the creation of entity 2
>>> 
>>> evt3 and evt3' "happen at the same time"/"are a same event" (depending on how we define destruction)
>>>     
>> You're right, I forgot to be careful about entities having fixed attribute values.
>> 
>> There's a lot to argue with here.  This example seems to motivate having a single event that "changes" red to blue, rather than two events that simultaneously create entity 2 and destroy entity 1 which we then have to relate somehow.  There is no way to say two events are the same in PROV-DM right now AFAIK.  There is also no way to say two events happen at the same time.  These are (a priori) different statements: just because I stub my toe at the same time as the stock market crashes, does not mean that stubbing my toe and the stock market crashing are the same event.  I think these are all separate issues from the main one under discussion, however.
>>   
> 
> Currently, I would express the "change" as a derivation between two entities (red entity and blue entity).
> 
> I also had been thinking that we need a mechanism to say that the generation of the new entity destroys the previous one.
> I have not seen a use case for generic event equality.
> 
> I think we should fold this in the discussion for entity destruction.
> 
>> 
>> In any case I plan to align the semantics with recent discussion so that objects' attributes do not vary with time.  Then, value will be a pure function of type Object * Attribute ->  Value, and not depend on events (or times) at all.
>> 
>> Will that address your concern?
>>   
> This will address the problem of attributes with fixed values, I believe.
> Thanks,
> Luc
>> --James
>>   
> 
> -- 
> Professor Luc Moreau
> Electronics and Computer Science   tel:   +44 23 8059 4487
> University of Southampton          fax:   +44 23 8059 2865
> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm
> 
> 
>

Received on Tuesday, 15 May 2012 20:39:06 UTC