- From: James Cheney <jcheney@inf.ed.ac.uk>
- Date: Thu, 9 Aug 2012 10:36:36 +0100
- To: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
Done; closed. --James On Aug 9, 2012, at 10:28 AM, Stian Soiland-Reyes wrote: > Just one tiny thing, the remark after this now says: > > "This constraint, similar to constraint 38, requires the derived > entity to be generated strictly" > > Remove "similar to constraint 38, ". > > On Wed, Aug 8, 2012 at 12:30 PM, James Cheney <jcheney@inf.ed.ac.uk> wrote: >> Hi, >> >> The word "strictly" in this constraint has been deleted. I have closed it since this is the change requested in the original issue and there has been no support for keeping it. >> >> Stian, to further answer your question, we already say (at the beginning of the event ordering constraint section, and in sec. 2) that time ordering does not imply event ordering (or vice versa), but applications are free to take this into account and issue warnings if the time order is fishy. >> >> --James >> >> On Aug 8, 2012, at 9:59 AM, Luc Moreau wrote: >> >>> Hi Stian, >>> >>> The constraints are about event ordering and not time ordering. The specification is silent about how >>> time information should be ordered. A given application, with knowledge that a same clock is used for >>> all time information, could check further constraints. E.g. time ordering is compatible with event ordering. >>> >>> However, we now have a framework to provide further constraints for extensions to PROV. >>> If someone was defining ex:hadSubactivity(a,a1), >>> we could imagine >>> If >>> ex:hadSubactivity(a,a1) >>> wasStarted(start; a, -,-,-) >>> wasStarted(start1; a1, -,-,-) >>> Then >>> a strictly precedes a1 >>> >>> and symmetrically for end. >>> >>> Luc >>> >>> On 08/08/12 09:36, Stian Soiland-Reyes wrote: >>>> On Mon, Aug 6, 2012 at 4:54 PM, James Cheney <jcheney@inf.ed.ac.uk> wrote: >>>>> In internal discussion, we basically decided to make all of the constraints non-strict except the two involving derivation. (The entity-generation-use one slipped through accidentally.) >>>>> I see no reason to insist on the generation-use in derivation to be strictly-precedes, so I propose to weaken it to "precedes" unless anyone wants to make a case for it. >>>> Sounds good. I just have one note (which should not affect this issue >>>> unless you object) then about checking for time order constraints, as >>>> the specification asks us to check for any loops with strictly >>>> precedes. So if there are no derivations, you can't detect time order >>>> violations, although all such such loops would then collapse to be >>>> single instants. (Which timestamps might then informally suggest is >>>> not the case). >>>> >>>> Would there be any other way to detect the time order violations if >>>> there are no derivations? >>>> >>>> I suspect not, as there is no way in PROV alone to specifically state >>>> time relations or durations - but there might be application specific >>>> knowledge, for instance that ex:photocopying takes usually a second, >>>> and ex:faxing takes usually at least 30 seconds, and thus a received >>>> fax could not be photocopied at the same time as the fax was sent. >>>> >>>> >>> >>> -- >>> 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 >>> >>> >>> >> >> >> -- >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> > > > > -- > Stian Soiland-Reyes, myGrid team > School of Computer Science > The University of Manchester > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Received on Thursday, 9 August 2012 09:37:26 UTC