> > > prov-c crew, > > This is my review of prov-c. Apologies for the delay. > > My previous concerns about organization and meta-discourse are largely resolved. > As I note below, there are a few hiccups on introducing and distinguishing definition/inference/constraint. > But overall, a much nicer document to read, and organized and > motivated well enough to justify digging into each > def/constraint/inference. > > After answering the 6 questions here, I have general comments below. > > I've tagged some of my general comments as BLOCKER for release to LC. > > I also created diagrams for almost all of the diagrams that I hope may > be considered for inclusion, or just to inspire a more intuitive > visual style. (this can obviously be done after LC release) > > I've attached a pdf and they are available in the repo: > > http://dvcs.w3.org/hg/prov/file/tip/model/images/constraints/prov-c.graffle > http://dvcs.w3.org/hg/prov/file/tip/model/images/constraints/prov-c.graffle.pdf > http://dvcs.w3.org/hg/prov/file/tip/model/images/constraints/prov-c.graffle.svg/ > > > Regards, > Tim > > > > On Jul 20, 2012, at 7:02 AM, Provenance Working Group Issue Tracker wrote: > > > PROV-ISSUE-459 (prov-constraints-lc-review): PROV-CONSTRAINTS review [prov-dm-constraints] > > > > 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)? > > Almost, but I have flagged a few of my comments below as > BLOCKER. Nothing critical, but these are too sharp to permit to go to > LC. > > > > 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) > > > > I find have no objections the inferences and constraints listed. I > cannot speak to the compound effects of their combination, though. > > > > > 3. Regarding ISSUE-451: Are there any objections to the > > revision-is-alternate inference? > > (http://www.w3.org/2011/prov/track/issues/451) > > > I think this inference should stay. > > > > > > 4. Regarding ISSUE-454: Are the rules for disjointness clear and > > appropriate? (http://www.w3.org/2011/prov/track/issues/454) > > I have no objections to the disjointnesses. > > > > > > > 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 to be proper, an influence should be irreflexive. Otherwise, a > critical distinction is being abstracted away (and that's what scruffy > provenance is for). The WG decided to drop this constraint. > > > > > 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 > > (I agreed to close this b/c it was an editorial issue - the second was deleted) > > > http://www.w3.org/2011/prov/track/issues/452 > > > The meaning of - is still confusing to me. > > > > http://www.w3.org/2011/prov/track/issues/453 > > I have no position on many of these issues. > > > > > > > 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. > > > Nothing beyond what I've discussed below. If any of my BLOCKER > comments are worthy of a full ISSUE, please add it or ask me to add > it. > > > > > > > general comments (WITH BLOCKERS): > > > > > > Abstract: > > 1) > The abstract seems to focus on DM too much, starting at: > > [[ > PROV-DM distinguishes core structures, forming the essence of > provenance information, from extended structures catering for more > specific uses of provenance. PROV-DM is organized in six components, > respectively dealing with: (1) entities and activities, and the time > at which they were created, used, or ended; (2) derivations of > entities from entities; (3) agents bearing responsibility for entities > that were generated and activities that happened; (4) a notion of > bundle, a mechanism to support provenance of provenance; (5) > properties to link entities that refer to the same thing; and, (6) > collections forming a logical structure for its members. > ]] > > I'd suggest removing these part, so we can get to "This document introduces" more quickly. > Done. > > 2) > My previous confusion among inference/definition/constraint is budding: > > "inferences and definitions that are allowed on provenance statements and constraints" > > "These inferences and constraints" (where did definitions go?) > Added missing "definitions" > The second paragraph of 1.2 disambiguates the notions, but the wording > in the abstract might be revisited for clarity. > Hopefully adopting consistent "definitions, inferences, and constraints" > 3) > > "PROV-SEM provides a mathematical semantics." is this still part of the family? It's not listed above. > I think we still plan to do it (time permitting). It's in the same ballpark as PROV-XML and company. If it slips, we can presumably remove the reference. For the moment, I've commented the sentence out, although we mention PROV-SEM later. > > > Introduction > > > 4) > "Provenance is a record that describes the people, institutions, > entities, and activities, involved in producing, influencing, or > delivering a piece of data or a thing." > > Have we converged on THE definition of provenance, according to PROV? > This one mentions institutions, but DM does not say it. > > Suggest that we converge on the definition and use it throughout. > I copied the definition from the LC of PROV-DM. > > 5) > > typo: "Some of these ariables" > > Fixed. > > 6) > > suggest to link "valid' in 1.2 to > http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-constraints-20120723/prov-constraints.html#dfn-valid > > Done > > > 7) > > "To summarize: compliant applications use definitions, inferences, and > uniqueness constraints to normalize PROV instances" > > where did "uniqueness" come from? Shouldn't it just be 'constraints'? > > It seems that there are two types of constraints (uniqueness and > ordering). Suggest to introduce this distinction before using it. > Introduced the three types of constraints earlier, so that we can explain how they are used in this summary. > > 8) > > "definitions, inferences" > > suggest to maintain narrative order "inferences, definitions, > constraints" when listing them (since definition is a type of > inference, and constraints are applied after the inferences). > > Or, choose your preferred order, but be consistent throughout. > > "definitions, inferences and constraints." > "presents inferences and definitions" > Done (definitions, inferences and constraints throughout) > > 9) > > typo "certain statments" > Fixed > > > 10) > > By the time we get to 1.3, the reader is surprised a second time that > "constraints" isn't just "constraints", but "uniqueness constraints" > and "ordering constraints", then we find out that there is a third > kind of constraint. Although this might be "easing into" the details, > I find it a bit unsettling to find these additions. > Hopefully, introducing the three kinds of constraints in the introduction signposts this better now. > "also defines a class of valid PROV instances by specifying > constraints that valid PROV instances must satisfy." is only partly > true and thus misleading, since only ordering and impossibility > constraints are used to determine validity. > Not true: the uniqueness constraints are implicitly checked while they are being applied. This checking can fail, if a uniqueness constraint forces us to merge two things that are incompatible: activity(a,0,1) activity(a,3,4) However, the uniqueness constraints behave more like inferences, and need to be applied during normalization (because they can trigger further inferences, which can trigger further uniqueness constraints, etc.). So this is somewhat intricate to explain, but what is written is technically true: valid PROV instances must satisfy the uniqueness constraints. > > 11) > > Why are "impossibility constraints" not mentioned in the "to summarize" in 1.2? > > They are now. > > 2. Rationale > > > > 12) > > I find this confusing: > > "To avoid over-reliance on assumptions that identifying > characteristics do not change, PROV allows for things to be described > in different ways, with different descriptions of their partial > state." > Simplified to "PROV allows for things to be described in different ways, with different descriptions of their state. " > > 13) > > "state during an entity's lifetime" > > -> ?? > > "state during the entity's lifetime" > Done > > 14) > > "Different entities that are aspects of the same thing" > > -> > > "Different entities that fix aspects of the same thing" > > Done > > 15) > > I disagree with: "and preserves the characteristics that make it identifiable" > > since we just said earlier that "Similarly, there is no assumption > that the attributes of an entity uniquely identify it." > > sugest to replace with "and preserves the characteristics provided" > Stale text; done. > > > 2.2 Events > > > > 16) > > > great discussion on global clocks! > > Thanks > > > 17) > > Is there a method to the ordering of events? > > I think this ordering is natural: > > start > end > generation > usage > invalidation > > > > since usage of an entity cannot occur until after its generation, and > nothing can happen after invalidation. > > suggest to reorder for clarity. > It's been this way for a long time; your suggestion is adopted. > > > > 18) > > great definitions on events. > Thanks > > 19) > > > Table 5's column says "Definitions, Constraints, Inferences" but I see no "Defintion X" in that column. > Removed "Definition". > > 20) > > Suggest to move Table 5's column 3 to column 1 > The format of the table is the same as that in PROV-DM table 5. So I would prefer to leave it as is. (Also, as it is the most important information is to the left-hand side of the page, which I think makes it easier to read if you print it out...) > > > Section 4 > > > > 21) > > Should "A definition is a rule that" be "A definition is an inference"? > No, because both definitions and inferences are rules (formulas). We are using "inference" in a somewhat different technical sense later (as an implication rather than an if and only if). Added clarifying text "a definition is a rule that can be applied to PROV instances to replace defined expressions with definitions. A definition states that a provenance statement is equivalent to some other statements, whereas an inference only states one direction of an implication; thus, defined provenance statements can be replaced by their definitions." > > > 22) > > The following is a bit choppy. It's hard to find the subject: > > > "With a few exceptions (discussed below), omitted optional parameters > to [PROV-N] statements, or explicit - markers, are placeholders for > existentially quantified variables; that is, they denote unknown > values." > > suggest to drop parens and to restructure sentence. > Done > > 23) > > BLOCKER > > Although I'm comfortable with the following for the purposes of > validation, I would like to see some mention of how validating would > happen when two distinct URIs are co-referent (i.e., this document > should "handle" an owl:sameAs). > > "In contrast, distinct URIs or literal values in PROV are assumed to > be distinct for the purpose of checking validity or inferences." > Implementations should decide up front what equational reasoning from sameAs assertions should be applied, and rewrite the instance (by substituting identifiers) to make this explicit, before doing validation. I don't think we want to explicitly deal with sameAs in the constraints, since this is a OWL/RDF specific phenomenon. A remark to this effect has been added to the beginning of section 6. --jrc > > 24) > > Should the following include PROV-O? It seems to imply that PROVO cannot omit the identifiers. > > Why call out the serialization at all? The DM allows them to be > optional, too. So perhaps we should keep it at the abstract level? > > "Identifiers can sometimes be omitted in [PROV-N] notation." > In PROV-O, you can't write "-" and have it be treated as a blank node/existential varaible, though there are other ways of accomplishing this. > > 25) > > Is "desugar" a technical term that should stay in a Recommendation? > No; revised to "Definitions 1, 2, and 3 explain how to expand the compact forms of PROV-N notation into a normal form." > > 26) > > > > Could R be replaced by O in "For each r in {entity, activity, agent}" > , to help make the distinction between an object and an influence > relation? > Done, sort of. (I prefer "p" to "o", since "p" is more tereotypical as a relation name.) > > > 27) > > "There are also no expansion rules for entity, agent, communiction, > attribution, influence, alternate, or specialization, because these > have no optional parameters aside from the identifier and attribute, > which are expanded by other rules above." > > -> > > "There are no expansion rules for entity, agent, communiction, > attribution, influence, alternate, or specialization, because these > have no optional parameters aside from the identifier and attributes, > which are expanded by the rules in Definition 2." > > Done. > > > 28) > > Is this described further somewhere: > > "The only exceptions, where - must be left in place, are the activity > parameter in wasDerivedFrom and the plan parameter in > wasAssociatedWith." > > (perhaps pull the Remark up to before the table?) > This comment is just meant to describe what is said more systematically in the table: only the plan and activity (and now, generation and use) parameters are non-expandable. Revised to say this. I think it is better for the remarks to go after the definition so that we explain what is going on first and then talk about it. > > 29) > > table after > "The following table characterizes the expandable parameters of" > > needs borders, a table #, and an anchor to it. > Done. > > > 30) > > The notion of "expandable parameters" is not described well enough. It > seems to be an emergent term from Definition 3, but it is not clearly > drawn. > What is an expandable parameter? A parameter that can be omitted, and > if so, must be given an existential identifier? > > Done, added explanation. > > > > 31) > > Definition 4: using "R" for entity, activity, agent is misleading from > the DM perspective. it is not an influence relation, it is an > (object?). > > > To address Stian's similar comment, since the only one of these thre relations (activity) can actually have "-" arguments anyway, we just say the two instances of the generic rule. This also addresses this comment. > > > 32) > > BLOCKER > > Why? > > "a wasDerivedFrom(id;e2,e1,a,gen,use,attrs) that specifies an activity > explicitly is not equivalent to > wasDerivedFrom(id;e2,e1,-,gen,use,attrs) with a missing activity." > > Are you saying that it is possible for the derivation to exist without > an activity that used e1 and generated e2? > Regardless of how granular activities are described to chain use of e1 > and generation of e2, I could always describe a new activity that > abstract those and uses e1 and generates e2. > > > More justification needs to be give for this absence of activity on a derivation. > > > The text of the remark about wasDerivedFrom was rewritten as follows: A derivation wasDerivedFrom(id; e2,e1,a,gen,use,attrs) that specifies an activity explicitly indicates that this activity achieved the derivation, with a usage use of entity e1, and a generation gen of entity e2. It differs from a derivation of the form wasDerivedFrom(id; e2,e1,-,-,-,attrs) with missing activity, generation, and usage. In the latter form, it is not specified if one or more activities are involved in the derivation. Let us consider a system, in which a derivation is underpinned by multiple activities. Conceptually, one could also model such a system with a new activity that encompasses the two original activities and underpins the derivation. The infererences defined in this specification do not allow the latter modelling to be inferred from the former. Hence, the two modellings of the same system are regarded as different in the context of this specification. > > 33) > > I would prefer a space after the semi colon in statements such as: > > "wasInformedBy(_id;a2,a1,_attrs)" > > since one is usually trying to "read past it". > > Done. (It wasn't fun!) > > 34) > > Thank you for flagging the irrelevant variables with underscores. > > You're welcome > > > 35) > > The note > > "A final check is required on this inference to ensure that it does > not lead to non-termination, when combined with Inference 5 > (communication-generation-use-inference)." > > is not situated well. > Fixed, by adding references to both inferences > > > 36) > > "A final check is required on this inference to ensure that it does > not lead to non-termination, when combined with Inference 5 > (communication-generation-use-inference)." > > "This inference" - the one above or below > > See above > > > 37) > > Figure 1 > I would think that the label numbering on the activities would be > reversed: a1 starts before a2 starts before a3. > > suggest changing labeling for more natural order. > > > @Luc: This requires changing the figure and the text in tandem... > > 38) > > > > > "From an entity, we can infer that existence of generation and invalidation events." > -> > "From an entity, we can infer the existence of generation and invalidation events." > > Fixed > > > 39) > > typo > > "From an activity statemen,t" > Fixed > > > 40) > > incomplete sentence? > > "From an activity statemen,t we can infer that start and end events > > having times matching the start and end times of the activity." > -> > "From an activity statement, we can infer start and end events having > > times matching the start and end times of the activity." > > also, "having times" seems odd. > > fixed > > 41) > > This doesn't seem narrative-y enough: > > "Start of a by trigger e1 and starter activity a1 implies that e1 was generated by a1." > > suggest making it more narrative-y > > "The start of an activity a by trigger e1 implies that e1 was generated by starting activity a1." > > Done > > same with: > > "Likewise, end of a by trigger e1 and ender activity a1 implies that e1 was generated by a1." > -> > "Likewise, end of activity a by trigger e1 and ender activity a1 implies that e1 was generated by a1." > > Fixed > > > 42) > > Inference 11 Why is "id2" in : > > "wasDerivedFrom(_id;e2,e1,a,id2,id1,_attrs)," > > what type is it? can we rename it to something more intuitive? > > > (very weak suggestion) rename "id2,id1" to "u, g" or something the > makes it easier to know what type it is. > > Done > > > 43) > > So, no abstraction of Activities? > > "the fact that the entity denoted by e2 is generated by at most one activity" > It follows from other constraints (unique-generation and the key constraint for generation) that there is at most one generating activity. We don't have a way to say that an activity is a sub-activity of another (and say that both participated in a generation event simultaneously). This may be a limitation of PROV, but this is outside the scope of PROV-CONSTRAINTS. Perhaps thisis an argument against imposing unique-generation. > > > 44) > > BLOCKER > > > Why is the converse not the case? (narrative needs to be added) Please > explicitly state the converse, as well. > > Why does this inference matter? (narrative needs to be added) > > "A derivation specifying activity, generation and use events is a > special case of a derivation that leaves these unspecified. (The > converse is not the case)." The text of the remark following inference 12 has been modified as follows: Inference 12 (derivation-use) allows "-" to be replaced by existential variables in a wasDerivedFrom, when an activity is explict, and a generation known. However, a derivation without explicit generation and usage cannot be normalized even when a generation and usage hold. IF wasDerivedFrom(id; e2,e1,a,-,-,attrs), wasGeneratedBy(gen; e2,a,_t2,_attrs2), and used(use; a,e1,_t1,[]), IT IS NOT NECESSARILY THE CASE THAT wasDerivedFrom(id; e2,e1,a,gen,use,attrs). Indeed, e1 may be used multiple times by a, usage use may not be involved in the derivation (for instance, it may well have taken place after the generation of e2). Derivation is not defined to be transitive either. Applications may define specializations of this relation that are transitive. > > > > 45) > > Inference 16 > > why > wasAssociatedWith(_id2;a, ag2, _pl2, []). (the plan is specified) > > and not > wasAssociatedWith(_id2;a, ag2, -, [])." > > This is ISSUE-452. The answer is that since _pl is a fresh existential variable, it can be instantiated with either an identifier or "-". That is, we treat "-" like a constant/literal standing for "no value". > > 46) > > BLOCKER > > "The relation alternateOf is an equivalence relation: ..." > > Why is this stated, and what are its consequences? Narrative is needed. > > This is because of ISSUE-29. That is, after a long discussion we decided that alternateOf is reflexive, symmetric, and transitive, that is, an equivalence relation. Is your concern that it wasn't clear how the concept of "equivalence relation" and "reflexive, symmetric, transitive" are related? If so I have added (minimal) additional text to explain this, and made "equivalence relation" a definition in the glossary. > > > 47) > > link explicitly to the constraint mentioned in: > > "Similarly, specialization is a strict partial order: it is > irreflexive and transitive. Irreflexivity is handled later as a > constraint." > Done > > 48) > > "If merging fails, then the constraint is unsatisfiable, so application of the constraint to I fails." > > What is the consequence of the constraint failing? Since this is in a > procedure prior to validation, it's not clear what state we are in > with instance I. > > I wanted to avoid forward references to section 6. There, it says that if application of a uniqueness constraint fails during normalization, then normalization fails (which implies invalidity.) Added "If this failure occurs during normalization prior to validation, then I is invalid, as explained in section 6." > > > 49) > > The end of this reads oddly: > > "Likewise, we assume that the identifiers of relationships in PROV > uniquely identify the corresponding statements a PROV instance" > > Revised to make this hopefully clearer. > > > 50) > > It seems odd to me that the uniqueness constraints are called > "uniqueness", isn't "identity constraints" a more appropriate > name? > > > suggest to rename uniqueness constraints to identity constraints. > > I'd rather not make this change, as these are essentially key constraints / functional dependenct constraints, that enforce "uniqueness" on information pertaining to each identifier. This is editorial so we can rename it later. > > > 51) > > typos in ID variables: > > IF wasStartedBy(id1;a,_e1,_a1,_t1,_attrs1) and wasStartedBy(id2;a,_e2,_a2,_t2,_attrs2), THEN id=id'. > IF wasEndedBy(id1;a,_e1,_a1,_t1,_attrs1) and wasEndedBy(id2;a,_e2,_a2,_t2,_attrs2), THEN id=id'. > > Fixed > > 52) > > The visual style in Figure 2(a), where the orange constraint triangle > > extends to touch the events that it orders, is not used in the > > remaining portions of the figure. > > suggest to carry this convention into the rest of the subfigures. > @Luc figure > > > 53) > > Figure 2 > > > "are represented by vertical dotted lines (…, or intersecting usage and generation edges)" > > > There seems to be visual ambiguity in the visual style convention. Is > the time of the usage/generation at the location the (Activity,Entity) > arrow crosses the vertical line? How does that intersection point > differ from the point that the line connects to the activity (for > generation) or entity (for usage)? If these two points were made one > in the same, would there be any loss of information? Eliminating any > visual distinctions that are not encoding the underlying model will > help avoid confusion and distraction while reading the figures. > > @Luc? Luc: given my time availability this week, I will leave all figure editing to later, possibly after LC publication > > 54) > > > Figure2 > > A note on my note: "Miscellanous suggestions about figures (originally from Tim Lebo):" > > The suggestion is to make the diagonal solid arrow be dotted, like the vertical "usage" line. > > > Further, I'd suggest to make the timeline a solid line, to distinguish from the event style. > > What is the purpose of the dotted horizontal line on the bottom of each subfigure? > > > > > Suggest to make the start and end vertical lines BLUE to match the activity. > > @Luc? Luc: given my time availability this week, I will leave all figure editing to later, possibly after LC publication > > 55) > > > > constraint 35 > > Could the second _t1 be changed to _t2 for clarity? > > • IF used(use;a,e,_t,_attrs) and wasStartedBy(start;a,_e1,_a1,_t1,_attrs1) THEN start precedes use. > • IF used(use;a,e,_t,_attrs) and wasEndedBy(end;a,_e1,_a1,_t1,_attrs1) THEN use precedes end. > > Done (I changed all the 1's to 2's) > > 56) > > Entities cannot be revised, since a new entity would result. > Why switching between can and may? > > "As with activities, entities have lifetimes: they are generated, then > can be used, revised, or other entities can be derived from them, and > finally they may be invalidated." > -> > "As with activities, entities have lifetimes: they are generated, then > can be used, other entities can be derived from them, and finally they > can be invalidated." > > Done > > 57) > > typos: > > "If an entity specalizes another," > > > "Similarly, if an entity specializes another" > > Done > > 58) > > constraint 45 > > The phrases seems to suggest the incorrect directionality: > > "If an entity specalizes another, then its generation must follow the specialized entity's generation." > > seems to say: > > "If an entity (e2) specializes another (e1), then its (e2) generation > must follow the specialized entity's (e1 or e2?) generation." > > I know we had some last minute tweaks on specializationOf at F2F3, which resulted in: > > "An entity that is a specialization ◊ of another shares all aspects of > the latter, and additionally presents more specific aspects of the > same thing as the latter. In particular, the lifetime of the entity > being specialized contains that of any specialization." > > I suggest constraint-45 be reviewed from this perspective to clarify the phrasing. > > The crux of the problem is that the phrase "specialized entity" can > suggest the more specialized OR more general entity. > > Fixed. > > 59) > > BLOCKER > > constraint 46 > > The phrasing: > > "Similarly, if an entity specalizes another, then its invalidation > must follow the specialized entity's invalidation." > > must change to be less ambiguous, since it is currently misleading. > > Fixed. > > 60) > > Suggest to switch the order in t_1 and t_2 in constraint 46: > > IF specializationOf(e2,e1) and > wasInvalidatedBy(inv1;e1,_a1,_t1,_attrs1) and > wasInvalidatedBy(inv2;e2,_a2,_t2,_attrs2) THEN inv2 precedes inv1. > > to align with the fact that the invalidation of the more specialized > entity must precede the invalidation of the more general entity (give > a natural ordering) > > I swapped 1's and 2's everywhere in the rule. > > 61) > > This is choppy and clearly just a stretch to fit it all in, but it's not naturally stated. > > "Like entities and activities, agents have lifetimes that follow a > familiar pattern: an agent is generated, can participate in > interactions such as starting, ending or association with an activity, > attribution, or delegation, and finally the agent is invalidated." > > Rewrote to: "Like entities and activities, agents have lifetimes that follow a familiar pattern. An agent that is also an entity can be generated and invalidated; an agent that is also an activity can be started or ended. During its lifetime, an agent can participate in interactions such as starting or ending other activities, association with an activity, attribution, or delegation." > > > 62) > > constraint 48 #2 > > suggest to rename _t1 to _t0 (to reconcile with the natural ordering when placed with #1) > > IF wasAttributedTo(_at;e,ag,_attrs) and > wasGeneratedBy(gen;ag,_a1,_t1,_attrs1) and > wasInvalidatedBy(inv;e,_a2,_t2,_attrs2) THEN gen precedes inv. > > Swapped 1 and 2, added subscripts to gen and inv > > make generation of agent _t0, generation of entity _t1 , invalidation > of entity _t2 and invalidation of agent _t3 > > Huh? gen is not a time, it's an event. Likewise, inv is an event. Please clarify. > > 63) > > constraint 52 > > do we know what "different relations" means? > I assume you mean impossible-property-overlap... This literally just means that r and s are different strings from the set given. Rephrased to "different relation names" > constraint 52 and 53: > > should more be said about a_1 and b_1 being different? > > > (regarding impossible-property-overlap and impossible-object-property-overlap). No, the values do not matter (they could be underscored variables.) The point is that it is an error to use the same id for two different relations (unless one of then is influence, as stated in the remark). In OWL terms, this amounts to saying that Usage, Generation, etc. are pairwise disjoint subclasses of Influence. (thogh PROV-O doesn't enforce this AFAIK, nor need it). I also renamed r to p and s to r. > > 64) > > The phrase "and check no impossibility results from rules" seems odd to me. Could it be clearer? > > Rephrased. > > > 65) > > > Putting constraint 54 much earlier in the document may help others > read all other prov-n assertions in this document. > > Suggest to put it much sooner in the document. > I assume you mean (typing)? This constraint is introduced in the appropriate place for where it happens in constraint checking, and it relies on notation not introduced until this point. Moreover, I believe these constraints are effectively stated informally in PROV-DM. I am happy to address it by putting a table or figure that summarizes the typing constraints early in PROV-CONSTRAINTS (in the non-normative section), if that helps. A new section 2.3 was introduced with the figure, giving an overview of the constraints. > > 66) > > Why is 'plan' not a type in constraint 54: > > IF wasAssociatedWith(id;a,ag,pl,attrs) THEN 'activity' ∈ typeOf(a) AND > 'agent' ∈ typeOf(ag) AND 'entity' ∈ typeOf(pl). > > I suppose it should be, but since there are no specific disjointness constraints about plans (aside from those inherited from entity), it doesn't seem to matter. > > Why is 'bundle' not a type in constraint 54: > > IF mentionOf(e2,e1,b) THEN 'entity' ∈ typeOf(e2) AND 'entity' ∈ typeOf(e1) AND 'entity' ∈ typeOf(b). > Same reason. > > > Why is c not a prov:Collection in constraint 54: > > > IF entity(c,[prov:type='prov:EmptyCollection']) THEN 'entity' ∈ > typeOf(c) AND 'prov:EmptyCollection' ∈ typeOf©. > > Same reason, I think... If this seems important, we can obviously add plan, bundle, and collection as base types. > > 67) > > Luc often makes an argument that agents can be viewed as activities, > which the Remark here does not address: > > "Note that there is no disjointness between entities and agents. This > is because one might want to make statements about the provenance of > an agent, by making it an entity. Therefore, users may assert both > entity(a1) and agent(a1) in a valid PROV instance." > > Suggest to balance out this remark to indicate that an agent can be viewed as either. Done.