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

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Tue, 31 Jan 2012 11:52:28 +0000
To: James Cheney <jcheney@inf.ed.ac.uk>

```Hi James,

Response interleaved.

On 01/31/2012 11:03 AM, James Cheney wrote:
> 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".
>

Yes, i saw this later when reading. thanks.
>
>> 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.

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

> --James
>

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

--
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, 31 January 2012 11:53:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:11 UTC