> > > Hello PROV-Constraints authors, > > Please find my review below (answers to your questions first, then detailed points). > > 1. Is PROV-CONSTRAINTS ready to be released as a last call working > draft (modulo editorial issues and resolution to the below issues)? > > Yes, though I think my points C and D below are important to try to > resolve before release as they directly concern the intended meaning > of the constraints. > > 2. Regarding ISSUE-346: Is the role, meaning, and intended use of > each type of inference or constraint clear? > (http://www.w3.org/2011/prov/track/issues/346) > > Yes. In fact, all the points in my review concern the explanatory > text, not the inferences/constraints themselves. > > 3. Regarding ISSUE-451: Are there any objections to the > revision-is-alternate inference? > (http://www.w3.org/2011/prov/track/issues/451) > > No objection. I think it is an important and potentially useful > inference, and I could object to its removal. > > 4. Regarding ISSUE-454: Are the rules for disjointness clear and > appropriate? (http://www.w3.org/2011/prov/track/issues/454) > > Seemed clear to me. > > 5. Regarding ISSUE-458: Should influence (and therefore all > subrelations, including communication) be irreflexive, or can it be > reflexive (i.e., can wasInfluencedBy(x,x) be valid)? > (http://www.w3.org/2011/prov/track/issues/458) > > I think it should be allowed to be reflexive, for the reasons given in > the issue. Influence is effectively between events, I believe, and the > lifetime of activities and entities involve multiple events, so it > makes sense that one event in something's lifetime could be influenced > by another event in the same thing's lifetime. ISSUE-458 describes > this for an activity, so here's an example for an entity: I define > entity my:book for a book I'm writing. It changes content as I write > it, but has a consistent identity. At some point, I finish a complete > draft and it is only 5 pages long, so I entitle it "The short > book". One mutable attribute (title) of the entity has influenced > another mutable attribute (length) of the same entity, so the entity > has influenced itself. > The WG voted for dropping irreflexiblity constraint of wasInfluencedBy. The strict ordering constraint for wasDerivedFrom remains though. > 6. Are there any objections to closing other open issues on PROV-CONSTRAINTS? They are: > > http://www.w3.org/2011/prov/track/issues/387 > I have no problem with the mandatory constraint generation-uniqueness > as long as it means that, for any entity, the generation event is > unique and not that the generating activity is unique. It appears fine > as currently stated. See point C below for more detailed comment on > this issue. > > http://www.w3.org/2011/prov/track/issues/394 > This issue seems to be closed. Alternate should be reflexive. > > http://www.w3.org/2011/prov/track/issues/452 > The relation inferred should be "wasAssociatedWith(_id2;a, ag2, -, > _attrs2)". As the document currently says, this does not necessarily > mean that a plan does not exist, just that in that statement we have > chosen not to identify it if it does exist. This does not preclude > other statements on the assocation that do identify the plan. See > related point B below. This seems to reflect misunderstanding of the resolution of issue 331. I've added text clarifying this and asked Simon for review. --jrc. Resolved. > > http://www.w3.org/2011/prov/track/issues/453 > I think the document is fine as it is. The identifier is the same in > the original and inferred statements because they are both > descriptions of the same event, just as if we had two wasGeneratedBy > (for example) statements with the same ID. > > 7. Are there any new issues concerning definitions, constraints, or > inferences? If so, please raise as new issues to be addressed before > LC vote, ideally with a suggested change that would address the > issue. > > The inferences and constraints themselves are fine, I think. See my detailed review below for more. > > Optional identifiers > ---------- > A. Section 4.1: It was unclear whether this section purely about > PROV-N and how the same statement can take different forms in it, or > is there something syntax-independent being stated? If the former, > maybe the section title could include 'PROV-N' to clarify this. If the > latter, it would be helpful to indicate what the 'optional > identifiers' etc. correspond to in the DM independent of PROV-N. Definition 3 (definition-short-forms) is PROV-N specific. The rest of the section is PROV. Introductory text updated. > > B. Remark under Definition 4: "In an association... the absence of a > plan means: either no plan exists, or a plan exists but is not > identified... Similarly, a wasDerivedFrom... that specifies an > activity is not equivalent to wasDerivedFrom(id;e2,e1,-...)" > I was not clear what you were implying here. That wasDerivedFrom with > - for the activity parameter can mean that no activity existed? If so, > how did the derivation occur? Or that it can mean the activity existed > but is not identified? But isn't that what - means in every other > relation? Why would activity in wasDerivedFrom be a special case? The text was updated and now states "In the latter form, it is not specified if one or more activities are involved in the derivation." > > Unique generations > ----------- > C. Immediately following Inference 12, the text says "the entity > denoted by e2 is generated by at most one activity (see Constraint > 27". The Remark below repeats this, "at most one activity could > generate the entity e2." > > This seems wrong. Constraint 27 says that e2 is generated by only one > generation event, not by only one activity. The distinction between > these is important. In the primer's example, there is an activity > ex:compile which is decomposed into steps ex:compose and > ex:illustrate. While there is only one (implicit) generation event for > entity ex:chart1, both ex:compile and ex:illustrate can be asserted to > have generated the entity. Constraint 27 indeed says that there is a single generation event and constraint 26 says that the id is a key for a wasGeneratedBy which implies that there is a single activity. In the primer, you assert: wasGeneratedBy(ex:chart1, ex:compile, 2012-03-02T10:30:00) wasGeneratedBy(ex:chart1, ex:illustrate, 2012-03-02T10:30:00) This is invalid. One way to address this is to maintain two levels of abstraction for both activities and entities. wasGeneratedBy(ex:chart1_abstract, ex:illustrate, 2012-03-02T10:30:00) specializationOf(ex:chart1,ex:chart1_abstract) // or similar. > > Note I see nothing in the constraints (Inference 12, Constraints 27 > and 28) that the primer example contradicts, and nothing intuitively > invalid about the primer example. The text referred to above, however, > states something more than the constraints do. > > Failed merges > --------- > D. Section 5.1: I did not find clear what the consequences of a failed > merge are. If merging fails (step 3, first algorithm in section), does > this mean the instance containing the hypotheses is invalid? Or does > it mean that the output instance of the merge is the same as the input > instance? Or both? > Step 3 states: - If merging fails, then the constraint is unsatisfiable, so application of the key constraint to I fails. Step 3 of normal form (section 6) states: - Apply all uniqueness constraints to I2 by merging terms or statements and applying the resulting substitution to the instance, yielding an instance I3. If some uniqueness constraint cannot be applied, then normalization fails. Step 1 of validity (section 6) states: - Normalize the instance, obtaining normalized instance I'. If normalization fails, then I is not valid. > E. Section 6 says "A normal form of a PROV instance may not exist when > a uniqueness constraint fails due to merging failure." This doesn't > clarify things, as it says "may not" and I'm unclear under what > circumstances failed merge means a PROV instance does not exist and > when it does not. Text was ambiguous, rephrased as: A normal form of a PROV instance does not exist when a uniqueness constraint fails due to merging failure. > > Bundles > ------- > F. Section 6.1 seems a bit out of the blue. "The definitions > [etc.]... assume a PROV instance with exactly one bundle", and then > multiple bundles are handled as exactly the same number of > instances. Why? Why is there a connection between number of instances > and number of bundles? Why would a bundle be considered to be only one > instance? I thought a bundle was an identified set of statements, > allowing for provenance of provenance, which seems a distinct matter > from whether a set of statements are valid. It seems fine for a user > to treat one bundle as one instance if they want to, but there's no > reason given why this is the general case. I am not sure I understand this comment. However, I have rewritten slightly the intro of section 6.1. "The definitions, inferences, and constraints, and the resulting notions of normalization, validity and equivalence, assume a PROV instance that consists of exactly one bundle, the toplevel bundle, containing all PROV statements in the top level of the bundle (that is, not enclosed in a named bundle). In this section, we describe how to deal with PROV instances consisting of multiple named bundles. Briefly, each bundle is handled independently; there is no interaction between bundles from the perspective of applying definitions, inferences, or constraints, computing normal forms, or checking validity or equivalence." I have also added: "Names b1...bn are assumed to be distinct." > > Misc > ------ > G. Section 2.2, paragraph 2: Is this definition of an entity (as > something to provide provenance of) consistent with the current DM, > PAQ etc? I thought we changed the definition because an entity is not > just something with provenance but also part of other things' > provenance, and that an activity can have provenance too? I removed the "bold" font, since we are not defining the term here. prov-dm says: "In PROV, things we want to describe the provenance of are called entities and have some fixed aspects." So, I think the text is ok. > > H. Inference 11: Can we also infer that _t1 precedes _t2? I'm not sure > whether the event ordering constraints cover this, as they are > inferred times. We don't infer time ordering, but event ordering, as discussed in section 2.2 An application, with knowledge that both time t1 and t2 were measured with the same clock could reasonably infer what you suggest. > > I. Inference 12: I agree this appears redundant Now that generation and usage are no longer expandable, inference 12 is no longer redundant. > > J. Inference 18: Shouldn't the antecedent be expressed in PROV-N, > "entity(e)", to be consistent with other rules? Repharsed as follows: IF entity(e) THEN alternateOf(e,e). > > K. Section 5.1, paragraph 1: In the example merge, I wasn't clear why > variables "t1" and "t2" disappeared in the merged version but "a" did > not. Are the three terms existential variables or constants? If "t1" > and "t2" are of a different kind to "a", can this be indicated, > e.g. "_t1" instead of "t1"? Updated text as follows: For example, suppose we have two activity statements activity(a,2011-11-16T16:00:00,_t1,[a=1]) and activity(a,_t2,2011-11-16T18:00:00,[b=2]), with existential variables _t1 and _t2. The merge of these two statements (describing the same activity a) is activity(a,2011-11-16T16:00:00,2011-11-16T18:00:00,[a=1,b=2]) > > L. Section 5.1, paragraph 2: What is an "unordered list"? Do you mean > a list for which the order has no meaning? If so, why would you not > say "set"? What is the relevant difference? prov-dm defines attributes as "set of attribute-value pairs " We replaced "unordered list" by "set" here. > > Typos > ----- > Section 1.1, paragraph 2: "Some of these ariables" > Remark under Definition 3: What does the "also" refer to in > "There are also no..."? > Sentence above Inference 8: "activity statemen,t" > Sentence above Constraint 45: "specalizes" > Sentence above Constraint 46: "specalizes" done. > > Thanks, > Simon > > Dr Simon Miles > Senior Lecturer, Department of Informatics > Kings College London, WC2R 2LS, UK > +44 (0)20 7848 1166 > > Automatically Adapting Source Code to Document Provenance: > http://eprints.dcs.kcl.ac.uk/1397/ > ________________________________________ > From: Luc Moreau [L.Moreau@ecs.soton.ac.uk] > Sent: 23 July 2012 15:09 > To: public-prov-wg@w3.org > Subject: Re: PROV-ISSUE-459 (prov-constraints-lc-review): PROV-CONSTRAINTS review [prov-dm-constraints] > > ... As some noted I shouldn't apologise for getting the document ready ... > for the delay in doing so! > > Luc > > On 23/07/12 15:04, Luc Moreau wrote: > > Dear all, > > > > Apologies in getting the prov-constraints document ready. > > It is now available for review at > > > > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-constraints-20120723/prov-constraints.html > > > > > > It would be great if we can still follow the timetable we agreed on > > the call last week. > > > > Regards, > > The prov-c-team > > > > On 20/07/12 12:02, Provenance Working Group Issue Tracker wrote: > >> PROV-ISSUE-459 (prov-constraints-lc-review): PROV-CONSTRAINTS review > >> [prov-dm-constraints] > >> > >> http://www.w3.org/2011/prov/track/issues/459 > >> > >> Raised by: James Cheney > >> On product: prov-dm-constraints > >> > >> Hi, > >> > >> This issue is to capture review comments for the next draft of > >> PROV-CONSTRAINTS, which will be released soon. > >> > >> Please answer the following review questions: > >> > >> 1. Is PROV-CONSTRAINTS ready to be released as a last call working > >> draft (modulo editorial issues and resolution to the below issues)? > >> > >> 2. Regarding ISSUE-346: Is the role, meaning, and intended use of > >> each type of inference or constraint clear? > >> (http://www.w3.org/2011/prov/track/issues/346) > >> > >> 3. Regarding ISSUE-451: Are there any objections to the > >> revision-is-alternate inference? > >> (http://www.w3.org/2011/prov/track/issues/451) > >> > >> 4. Regarding ISSUE-454: Are the rules for disjointness clear and > >> appropriate? (http://www.w3.org/2011/prov/track/issues/454) > >> > >> 5. Regarding ISSUE-458: Should influence (and therefore all > >> subrelations, including communication) be irreflexive, or can it be > >> reflexive (i.e., can wasInfluencedBy(x,x) be valid)? > >> (http://www.w3.org/2011/prov/track/issues/458) > >> > >> 5. Are there any objections to closing other open issues on > >> PROV-CONSTRAINTS? They are: > >> > >> http://www.w3.org/2011/prov/track/issues/387 > >> http://www.w3.org/2011/prov/track/issues/394 > >> http://www.w3.org/2011/prov/track/issues/452 > >> http://www.w3.org/2011/prov/track/issues/453 > >> > >> 6. Are there any new issues concerning definitions, constraints, or > >> inferences? If so, please raise as new issues to be addressed before > >> LC vote, ideally with a suggested change that would address the issue. > >> > >> > >> --James > >> > >> > >> >