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

On Jan 31, 2012, at 9:57 AM, Luc Moreau wrote:

> Hi James,
>
> DM assumes a mapping from events to some form of time. Here
> we could say:
>
> TMap = Event -> Time
>

OK.  There is already such a function from events to times in PROV-SEM, it's called "time".

> 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.)

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)?

> 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.

--James

> Luc
>
> On 01/12/2012 06:27 PM, Provenance Working Group Issue Tracker wrote:
>> PROV-ISSUE-213 (prov-sem-events): Alignment of events in PROV-DM vs PROV-SEM [Formal Semantics]
>>
>> http://www.w3.org/2011/prov/track/issues/213
>>
>> Raised by: James Cheney
>> On product: Formal Semantics
>>
>> Quoting from Luc's email that raised the issue:
>>
>>
>>> PROV-DM tends to talk about events, whereas your semantics focuses on time.
>>>  PROV-DM assumes the existence of a mapping from events to time.  Is it possible
>>>  to align both?
>>>
>> I believe they are already aligned, and if others disagree then I solicit suggestions on how to change PROV-SEM to improve this.
>>
>>
>>
>>
>
> --
> 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
>
>
>

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

Received on Tuesday, 31 January 2012 11:04:28 UTC