- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 8 Aug 2012 11:02:10 +0100
- To: James Cheney <jcheney@inf.ed.ac.uk>
- Cc: Provenance Working Group <public-prov-wg@w3.org>
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
Received on Wednesday, 8 August 2012 10:03:02 UTC