- From: James Cheney <jcheney@inf.ed.ac.uk>
- Date: Thu, 9 Aug 2012 15:03:58 +0100
- To: Jun Zhao <jun.zhao@zoo.ox.ac.uk>, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Cc: public-prov-wg@w3.org
Hi, To (begin to ) address the issue and hopefully also satisfy requests from reviewers for better intuition about how normalization/validity checking/equivalence checking work, I have added an outline of the validation process (complementing Tim's contributed figure). This is work in progress, but I hope it can give people confidence that this issue is addressed (and can be explained so that it is clear to other readers that it is addressed). I have marked this pending review, hopefully we can close it or identify further action to take to resolve it during the meeting. --James On Aug 9, 2012, at 11:25 AM, Jun Zhao wrote: > James and Stian, > > On 08/08/2012 11:33, James Cheney wrote: >> OK, I will revise to make this clearer. This can be done by adding explanation rather than by making technical changes, though, so we should focus on resolving the other issues now. >> > > +1 > > -- Jun > > >> --James >> >> On Aug 8, 2012, at 11:02 AM, Stian Soiland-Reyes wrote: >> >>> On Wed, Aug 8, 2012 at 10:47 AM, James Cheney <jcheney@inf.ed.ac.uk> wrote: >>>> I understand your concern. At a purely technical level, we avoid nontermination, but only by drawing a fine distinction between having an entity(e) statement in the instance, and "knowing e is an entity" (represented by entity' \in typeOf(e)). >>>> >>>> We (me, Luc, Paolo, Tom) discussed three ways of avoiding this problem, before finalizing the review copy: >>>> >>>> 1. Drop the entity-generation-invalidation and activity-start-end inferences altogether. >>>> 2. Add some limitation to inference (such as your suggestion of not triggering inferences on generated existential variables, or applying the ) that recovers finiteness. >>>> 3. [what we have done] demote the type inferences to only infer constraints like 'entity' in typeof(id) , not add new statements like entity(e) to the PROV instance. >>>> >>>> Of the three, the one with strongest consensus was (3). Some of us strongly felt that the e-g-i and a-s-e inferences are needed. Others, including me, strongly felt that (2) would be a bad idea, as it breaks the connection to logic (i.e., the e-g-i and a-s-e and may have more radical unforeseen consequences. >>> >>> OK, I see now that you have thought about this. It would be useful if >>> some of those considerations shone through to the document. I can >>> agree on argument 3 if we formulate it well, explicitly. >>> >>> I agree that the inferences are needed, or at least useful. >>> >>>> We believed that (3) was an acceptable compromise (if a bit hacky), but, I'm not sure how the group as a whole would feel. That is why I'm laying out the options we considered. >>>> So, my proposal would be to make this distinction clearer (and explain why) so that it does not surprise or bite people... >>> >>> I would think this is the best approach, rather than dropping the >>> inferences all together, as the rest of the constraints rely on them. >>> >>> -- >>> Stian Soiland-Reyes, myGrid team >>> School of Computer Science >>> The University of Manchester >>> >>> >> >> > > -- > Jun Zhao, PhD > EPSRC Postdoctoral Fellow > Department of Zoology > University of Oxford > Tinbergen Building, South Parks Road > Oxford, OX1 3PS, UK > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Received on Thursday, 9 August 2012 14:04:24 UTC