--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/model/working-copy/notes-for-WD5-PM.txt Sat Feb 25 20:54:12 2012 +0000
@@ -0,0 +1,115 @@
+PM notes to WD4 --> for WD5
+
+>
+> 2.1
+>
+> " consuming them, processing them, transforming them, modifying them, relocating them, using them, generating them, being associated with them" ->
+> consuming, processing, transforming, modifying, relocating, using, generating, or being associated with entities
+
+I am fine. I think it was already modified once by yolanda, we may revert to what it was. I can't recall.
+
+> " The key purpose of agents is to assign responsibility for activities. " surely not? that is the purpose of introducing agents in the model, right? i.e. to be able to indicate (name, denote) the entities that are responsible for activities
+
+I agree with your reading.
+Still, it's flawed.
+
+An agent itself does not carry any responsibility, it's the fact that we have wasAssociatedWith and actedOnBehalfOf.
+They represent the assignment of responsibility ... not the agent.
+But that's for wd5.
+
+
+> 2.2
+>
+> " Generation is the completed production of a new entity by an activity": worth pointing out that both generation and usage span a time interval, hence the need to refer specifically to the end of generation, and the start of consumption
+>
+> For provenance purpose -> for the purpose of provenance
+>
+> " Derivation is something by which some entity is transformed from, created from, or affected by another entity in the world." "something which" sounds really weak.
+> I had proposed:
+> " Derivation is the fact that some entity is transformed from, created from, or affected by another entity in the world."
+> which is no better, but an indication that something is needed here.
+> Why not just call derivation a /relation between two entities/, which is what it is?
+
+I don't think that a derivation is a fact. Like we say an activity is something that ... happens, derivation is also something ... that derives.
+
+Through a derivation, you can establish a link/relation between two entities, but also an activity, etc.
+I am finding word relation problematic here.
+Thoughts?
+
+>
+> 2.4
+> " It is important to reflect that there is a degree in the responsibility of agents, and that is a major reason for distinguishing among all the agents that have some association with an activity and determine which ones are really the originators of the entity. "
+> can we simplify?
+> "Agents are defined in sec. 2.1 as having some kind of responsibility for activities. However, one may want to be more specific regarding the degrees of an agent's responsibility. For example, ..."
+>
+
+I would like to revisit this as part of wd5. See above.
+
+> " Provenance reflects activities that have occurred. In some cases, those activities reflect the execution of a plan that was designed in advance to guide the execution. PROV-DM allows attaching a plan to an activity, which represents what was intended to happen. Representing the plan explicitly in the provenance can be useful for various tasks: for example, to validate the execution as represented in the provenance record, to manage expectation failures, or to provide explanations."
+>
+> doesn't this belong in 2.3? when plans are introduced
+>
+
+But, we need to mention what plan do in the context of associatedWith, whose definition just follows.
+> - " the agent had an active role in the activity." this suggests that there are other roles (less "active"?) but none is mentioned later.
+>
+> I see all of the above activity/agents/plan as best collected in one short paragraph: the "activity association" relation provides a way to indicate that an agent is responsible for an activity, possibly with an associated plan.
+>
+
+again, relation as above. I feel that it's something that happens too.
+> - " A responsibility chain is a relation between two agents," it seems to me that the relation is "acting on behalf of" (aka "delegation" or " contractual relation" as mentioned), and a chain comes about when delegation is used transitively.
+>
+
+Have you got a suggestion?
+> (sec 3 -- looks fine, we have talked about it)
+>
+> 4.1.3
+>
+> " for the activity taking" see above
+>
+> 4.1.4
+>
+> " id: an identifier identifying the note;" I know this is ok but a first reader will be confused by this. I think it is best to introduce the note element and the hasAnnotation relation together.
+
+You mean having a glossary definition for note, like for the other concepts. Yes, we need to add a few for the concept
+not introduced in appendix.
+>
+> 4.2 maybe worth pointing out at the beginning of section that optional IDs are needed (only) for annotation purposes?
+>
+
+No, they identify something that happens, like an activity identifier. We may want to assert this id, so that events
+in different accounts can be related (with a vocabulary outside prov)
+
+> 4.2.3.3 then than e3. -> then e3
+>
+> 4.3.3 " fixed set of attributes" -> pre-defined? fixed seems to indicate they can't be extended
+>
+
+yes to both. Nobody can extend them. But fine, with pre-defined.
+
+> 4.3.3.3 prov:steps -> I assume this still needs editing?
+
+Depends what we do with derivaiton.
+>
+> 5.4 your note: " I propose to delete the following, given that this document does not mention inferences." this is fine, however " Traceability is more general than Derivation. " i.e., the relationship between the two should be stated somehow.
+>
+
+Nowhere in the document we mention infernce, and hopefully, occurrences of assertion have disappeared.
+So, ok for something vague.
+
+In fact, looking at the definition, there is something wrong. It's not true that e2 was neceaary for e1 (in the transitive case) and
+that e1 bears responsibility.
+
+I was toying with the idea of moving Traceability to part II only.
+
+> 7 " Data Model Constraints" you seem to be going a long way to avoid the term "consistency" but it would seem very appropriate to me here.
+>
+
+I guess with your DB background you like this term ;-)
+
+
+> also here: " One needs to be cautious about provenance descriptions for the latter document, to ensure that they remain valid as denoted resources change." cautious how? either we give rules for consistency, or we don't... I know the notion of partial states hides the whole issue of characterization, but here there is a risk of not getting the point across by trying to simplify too much. As a "taster" may not do the job? why not use our simple example of the light that turns red and blue, with the colour being the partial state etc.
+>
+Agreed about the word cautious. I don't think it's a place for a new example. That's really only a forwarding pointer to part II.
+>
+>