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

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

Received on Friday, 11 November 2011 16:26:51 UTC