W3C home > Mailing lists > Public > public-prov-wg@w3.org > January 2012

Re: PROV-ISSUE-43 (derivation-time): Deriviation should have associated time [Conceptual Model]

From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
Date: Tue, 17 Jan 2012 11:24:23 +0000
Message-ID: <EMEW3|5ee94e82ef6b2133f199907321a433eco0GBOY08L.Moreau|ecs.soton.ac.uk|4F155A67.4040002@ecs.soton.ac.uk>
To: public-prov-wg@w3.org
Hi Paul,

Still trying to tackle this outstanding issue.  what are your views on 
this last message?

Thanks,
Luc

On 11/30/2011 02:39 PM, Luc Moreau wrote:
> Hi Paul,
>
> Trying to come back to this issue, now that we have revised the notion 
> of derivation.
>
> While  I am sympathetic to the idea of "short-cuts" to facilitate life 
> of asserters,
> I am also keen to stick to some (unwritten) design principles.
>
> 1. There should be one and only one place where a given piece of 
> information can
>    be placed in the data model. Failing to do so, then, asserters 
> won't know where to
>    assert information. Furthermore, the data model will have to 
> specify what it means
>    when places for a given piece of information contain different values.
>
>    In this case, derivation time(=generation time) could be placed in 
> a derivation and in
>    a generation record.
>
> 2.  Uniformity. If we make this time optional in derivation, we should 
> also make it on
>     "specializations" of derivation such as wasSummaryOf etc.
>     We don't do it.
>
> Ultimately, writing a derivation time (=generation time) requires 
> precision.
> We shouldn't do it with an imprecise record. In the new terminology, 
> were you suggesting
> to do have this option in imprecise-1 records? imprecise-n?
>
> Luc
>
> On 11/11/2011 04:26 PM, Luc Moreau wrote:
>> Hi Paul,
>> Remember that the activity may have been a long running service, 
>> which started well before the entity was used,
>> and vice-versa, it could have ended well after the other entity was 
>> generated.
>>
>> Let us know what event you choose, and we'll encode this.
>> Luc
>>
>> On 11/11/2011 15:52, Paul Groth wrote:
>>> Hi Luc,
>>>
>>> Ok, I see what your asking. I think we can reuse the events. My 
>>> general thought is that (at 10 am) applies to the activity (e.g. the 
>>> anonymous activity that used the report). So that would map to 
>>> either the start or end of the activity or both?
>>>
>>> I'm not sure what's nicest.
>>>
>>> Thanks,
>>> Paul
>>>
>>> Luc Moreau wrote:
>>>> Hi Paul,
>>>>
>>>> Comments interleaved.
>>>>
>>>> On 11/09/2011 08:53 AM, Paul Groth wrote:
>>>>> Hi Luc,
>>>>>
>>>>> For me this is about, saying the following:
>>>>>
>>>>> blogpost wasDerivedFrom Report at 10am Thursday
>>>>
>>>> What do you mean by this: blogpost was generated at 10am?
>>>>
>>>>> Sure there is some process there, there may be an interval. But I 
>>>>> just
>>>>> don't want to assert all that information.
>>>>
>>>> I understand, but ultimately, I am trying to determine whether 
>>>> there is
>>>> a new special event 'derivation' to which
>>>> time is associated with, or whether we can reuse generation/use events
>>>> or start/end events.
>>>>
>>>>> Again, my fundamental thing is that I want to assert derivation 
>>>>> chains
>>>>> without (knowingly) asserting anything about process.
>>>>>
>>>>> Maybe the point is I'm looking for a shortcut such that if I assert a
>>>>> time it automagically infers that the e2, and e1 are on the same time
>>>>> line using the same clock and are the same time?
>>>>
>>>> Inferring time line and same clock would be no good.
>>>>
>>>>> Does that make sense?
>>>>>
>>>>
>>>> I still need you to clarify the intended semantics, specifically, what
>>>> notion of time you refer to.
>>>> Then, when it's decided, we can express the short cut.
>>>>
>>>> My take on it, in the above example, you refer to the blogpost
>>>> generation time.
>>>>
>>>>> Paul
>>>>
>>>> Luc
>>>>> Luc Moreau wrote:
>>>>>> Hi Paul,
>>>>>>
>>>>>> I'd like to come back to this issue, and see how we can solve it.
>>>>>>
>>>>>> The fully expanded notion of derivation, written
>>>>>> wasDerivedFrom(e2,e1,pe,q2,q1),
>>>>>> refers to the generation event for e2, and the use event for e1.
>>>>>> So, they form an "interval".  If we have time information for
>>>>>> each of these events (and assuming a same clock), we can compute the
>>>>>> duration
>>>>>> of this interval.
>>>>>>
>>>>>> So, the question is, do you really have a use case, where you 
>>>>>> don't want
>>>>>> to assert the use/generation events (qualified usage/generation) but
>>>>>> want
>>>>>> to express time?  Can you explain it?
>>>>>>
>>>>>> My concern is that we are at risk of introducing two placeholders 
>>>>>> for
>>>>>> the same time information
>>>>>> (in derivation or use/generation events). Two placeholders for 
>>>>>> time may
>>>>>> result in inconsistent
>>>>>> information.
>>>>>>
>>>>>> Luc
>>>>>>
>>>>>>
>>>>>> On 07/23/2011 04:46 PM, Provenance Working Group Issue Tracker 
>>>>>> wrote:
>>>>>>> PROV-ISSUE-43 (derivation-time): Deriviation should have  
>>>>>>> associated
>>>>>>> time [Conceptual Model]
>>>>>>>
>>>>>>> http://www.w3.org/2011/prov/track/issues/43
>>>>>>>
>>>>>>> Raised by: Paul Groth
>>>>>>> On product: Conceptual Model
>>>>>>>
>>>>>>> Other relationships have time associated with them (e.g. use,
>>>>>>> generation, control)
>>>>>>>
>>>>>>> There is no optional time associated with derivation.
>>>>>>>
>>>>>>> Suggested resolution is to add the following to the definition of
>>>>>>> isDerivedFrom:
>>>>>>>
>>>>>>> -  May contain a "derived from time" t, the time or time intervals
>>>>>>> when b1 was derived from b2
>>>>>>>
>>>>>>> Example:
>>>>>>> isDerivedFrom(b1,b2, t)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>
>

-- 
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, 17 January 2012 11:24:59 UTC

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