- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Tue, 17 Jan 2012 11:42:44 +0000
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Cc: public-prov-wg@w3.org
I would suggest instead to rename wasGeneratedBy to just wasGenerated - with activity and time optional. (Stating only wasGenerated(e1) is of course useless, but you might still attach attributes to this). The generation time should not depend on how it was generated (but it does depend on the account) - and so I don't see the need for this shortcut. This already maps nicely to the Generation class in PROV-O - but unless we do an anonymous node for the (unknown) activity we might need an additional property to link an entity to its Generation node (at least if we want to preserve the following-links-backwards-in-time principle) On Tue, Jan 17, 2012 at 11:30, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote: > Here is a suggestion: > > For every imprecise derivation, we can associate the time at which e2 is > generated. > > Hence, > wasDerivedFrom(e2,e1,t,attrs) > > is a shortcut for: > > wasDerivedFrom(e2,e1,attrs) > wasGeneratedBy(e2,t) > > Note that this assumes that activity is not mentioned in generation record. > This is outstanding ISSUE-205. > > Cheers, > Luc > > > > On 01/17/2012 11:24 AM, Luc Moreau wrote: >> >> 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 > > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Tuesday, 17 January 2012 11:43:36 UTC