- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Thu, 6 Sep 2012 11:36:52 +0100
- To: Luc Moreau <l.moreau@ecs.soton.ac.uk>
- Cc: public-prov-wg@w3.org
Looks good! :) On Tue, Sep 4, 2012 at 12:33 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote: > > Hi Stian, > > Figure 6b updated to reflect wasAttributed_ordering, with your stricter > ordering constraint. > > Luc > > > On 03/09/12 17:09, Stian Soiland-Reyes wrote: >> >> On Mon, Sep 3, 2012 at 2:53 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> >> wrote: >>> >>> >>> I suggest the constraints becomes as follows: >>> >>> IF wasAttributedTo(_at;e,ag,_attrs) and >>> wasInvalidatedBy(invE;e,_a1,_t1,_attrs1) and >>> wasGeneratedBy(genAg;ag,_a1,_t1,_attrs1) THEN genAg precedes invE >> >> Although this laxer constraint would still be 'true', I wonder then >> about the point of this: >> >>> Inference 13 (attribution-inference) >>> IF wasAttributedTo(_att; e,ag,_attrs) THEN there exist a, _t, _gen, >>> _assoc, _pl, such that wasGeneratedBy(_gen; e,a,_t,[]) and >>> wasAssociatedWith(_assoc; a,ag,_pl,[]). >> >> If I assume for the argument that wasAttributedTo also covers any kind >> of ownership (which as you know I don't approve of ;) ), then I >> struggle with the above inference, as this forces the agent to also be >> involved with the *generation* of that entity. If I buy a car, then >> yes, I might be involved in the "purchasing" activity, which you can >> say is what generated the StiansCar entity. (which lives for as long >> as it has the characteristic of being owned by me - note that this >> sounds more like attributes and entity characterisation) - but is this >> true for any kind of ownership? If I inherit a massive castle, or I >> have received in the mailbox (in a house I have just moved in to) a >> 2013 calendar from a local shop, am I then 'attributed to' the castle >> or the calendar, and required to be associated with the activity that >> made me the owner? >> >> >> Should it then not a requirement be for the agent to be involved with >> the activity before the entity was generated? Your proposed constraint >> (as quoted above) would allow the agent to come to life just before >> the invalidation of the entity, get a brief ownership (duration of >> which we don't know), and then let the entity invalidate. It is OK >> with the wasAssociatedWith-ordering rule as long as the activity that >> generated the entity is still running at this point, for instance that >> the factory is still making cars or the postman still doing his >> deliveries. >> >> This sounds a bit odd for me. It should be one way or the other. The >> time ordering constraints should cover, ideally, exactly what is >> required, not allow various scenarios we do not intend to be legal. >> >> If the ownership is true for the whole lifetime of the entity (which I >> would presume!), then that is an attribute that I would see in the >> entity, not as a separate statement. If it is still to be said as a >> statement, then we need boundary conditions on both sides, just like >> we say attributes are valid all the way from the generation till >> invalidation. >> >> >> My proposal is to keep the current definition: >> >>> Constraint 50 (wasAttributedTo-ordering) >>> IF wasAttributedTo(_at; e,ag,_attrs) and wasGeneratedBy(gen1; >>> ag,_a1,_t1,_attrs1) and wasGeneratedBy(gen2; e,_a2,_t2,_attrs2) THEN gen1 >>> precedes gen2. >>> IF wasAttributedTo(_at; e,ag,_attrs) and wasStartedBy(start; >>> ag,_e3,_a3,_t3,_attrs3) and wasGeneratedBy(gen; e,_a4,_t4,_attrs4) THEN >>> start precedes gen. >> >> (Note: There are two rules, depending on the agent being an entity or >> an activity. We can't time-order non-entity, non-activity agents). >> >> >> This says that the agent must be involved in the generation of the >> entity. We do not have time stamps on association, but the intention >> is that he was associated before entity generation. This must be true >> - from the above - also for the case of ownership. >> >> The agent is not required to be involved with its invalidation, but we >> know that the the invalidation must be after his generation, because >> of the combination of constraint generation-precedes-invalidation and >> wasAttributedTo-ordering. >> >> >> -- >> Stian Soiland-Reyes, myGrid team >> School of Computer Science >> The University of Manchester > > > -- > 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 Thursday, 6 September 2012 10:37:42 UTC