- From: Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
- Date: Wed, 8 Aug 2012 15:48:35 +0100
- To: James Cheney <jcheney@inf.ed.ac.uk>
- Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, public-prov-wg@w3.org
I did check that, it's good. On Wed, Aug 8, 2012 at 3:39 PM, James Cheney <jcheney@inf.ed.ac.uk> wrote: > Done. By the way, I forgot to say that there is also text in the compliance section that reinforces the point that we give *one* implementable way to check validity/equivalence, but do not specify that it is *the* way implementation should do it - any other equivalent way is OK. You may want to check that too; I'm closing this now. > > --James > > On Aug 8, 2012, at 1:40 PM, Stian Soiland-Reyes wrote: > >> Looks very good. Tiny tweak: >> >>> and event ordering, typing, and impossibility constraints are checked on the normal form to determine validity >> >> --> >> >> "are" -> "can be" >> >> >>> validity checking based on noramlization. >> -> normalization >> >> >> Given these tweaks, you may close this issue. >> >> >> On Wed, Aug 8, 2012 at 12:22 PM, James Cheney <jcheney@inf.ed.ac.uk> wrote: >>> Hi, >>> >>> I believe the original issue has been addressed in [1] and am marking this as pending review. >>> >>> Stian, please, check you are happy with how it has been addressed. >>> >>> We plan to add further explanation / picture to sec. 2, but this is beyond the scope of the original issue (and editorial). >>> >>> [1] http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#purpose >>> >>> --James >>> >>> On Aug 6, 2012, at 5:00 PM, Luc Moreau wrote: >>> >>>> >>>> On 06/08/12 16:44, James Cheney wrote: >>>>> I am happy to adopt the first changes, as they better reflect what we were trying to say. Any objections? >>>> >>>> +1 >>>>> >>>>> For the second change, I still think it is important for the introduction to summarize what an application does to be (nontrivially) compliant with the constraints. I will try to revise it to avoid confusing specification with implementation. >>>> >>>> Agree it's important to explain the bigger picture. There was a comment to that effect from Tim/Paul, and a suggested >>>> picture. >>>> >>>> Luc >>>> >>>>> --James >>>>> >>>>> On Aug 6, 2012, at 4:21 PM, Provenance Working Group Issue Tracker wrote: >>>>> >>>>>> PROV-ISSUE-464 (dont-need-normalize): Applications do *not* need to normalize PROV [prov-dm-constraints] >>>>>> >>>>>> http://www.w3.org/2011/prov/track/issues/464 >>>>>> >>>>>> Raised by: Stian Soiland-Reyes >>>>>> On product: prov-dm-constraints >>>>>> >>>>>>> From Stian's review of PROV-Constraint >>>>>> http://lists.w3.org/Archives/Public/public-prov-wg/2012Aug/0021.html >>>>>> >>>>>> >>>>>>> Applications should also use definitions, inferences and constraints to normalize PROV instances in order to determine whether two such instances convey the same information. >>>>>> No, they should not! It is not a requirement for applications to >>>>>> determine equivalence. >>>>>> >>>>>> >>>>>> Reword to something like: >>>>>> >>>>>>> Applications which are determining whether PROV instances convey the same information SHOULD use definitions, inferences and constraints to normalize the instances. >>>>>> >>>>>> Similarly this: >>>>>> >>>>>>> Applications should produce valid provenance and may reject provenance that is not valid >>>>>> should be: >>>>>> >>>>>> "Applications producing provenance SHOULD ensure it is _valid_, and >>>>>> similarly applications consuming provenance MAY reject provenance that >>>>>> is not _valid_." >>>>>> >>>>>> >>>>>>> To summarize: compliant applications use definitions, inferences, and uniqueness constraints to normalize PROV instances, and then apply event ordering constraints to determine whether the instance has a consistent event ordering. If so, the instance is valid, and the normal form is considered equivalent to the original instance. Also, any two PROV instances that yield the same normal form are considered equivalent. >>>>>> Delete this whole paragraph (except for PROv-SEM reference) - it is >>>>>> also assuming applications of PROV-Constraint only want to do >>>>>> normalization. It is saying you can't be compliant without doing all >>>>>> of the above! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> 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. > -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester
Received on Wednesday, 8 August 2012 14:49:28 UTC