--- a/model/prov-dm.html Fri Mar 09 16:29:43 2012 +0000
+++ b/model/prov-dm.html Fri Mar 09 16:38:49 2012 +0000
@@ -1943,10 +1943,10 @@
The following relations relate a collection <span class="name">c1</span> with a collection <span class="name">c2</span> obtained after adding or removing a new pair to (resp. from) <span class="name">c1</span>:
<ul>
- <li>Insertion relation <span class="name">CollectionAfterInsertion(c2, c1, k, v)</span> states that <span class="name">c2</span> is the state of the collection
+ <li>Derivation-by-Insertion relation <span class="name">derivedByInsertionFrom(c2, c1, k, v)</span> states that <span class="name">c2</span> is the state of the collection
following the insertion of pair <span class="name">(k,v)</span> into collection <span class="name">c1</span>;</li>
-<li> Removal relation <span class="name">CollectionAfterRemoval(c2,c1, k)</span> states that <span class="name">c2</span> is the state of the collection following the removal of the pair corresponding to key <span class="name">k</span> from <span class="name">c1</span>.</li>
+<li> Derivation-by-Removal relation <span class="name">derivedByRemovalFrom(c2,c1, k)</span> states that <span class="name">c2</span> is the state of the collection following the removal of the pair corresponding to key <span class="name">k</span> from <span class="name">c1</span>.</li>
</ul>
@@ -1958,44 +1958,58 @@
entity(c1, [prov:type="Collection"])
entity(c2, [prov:type="Collection"])
- CollectionAfterInsertion(c1, c, "k1", v1) // c1 = { ("k1",v1) }
- CollectionAfterInsertion(c2, c1, "k2", v2) // c2 = { ("k1",v1), ("k2", v2) }
- CollectionAfterRemoval(c3, c2, k1) // c3 = { ("k2",v2) }
+ derivedByInsertionFrom(c1, c, "k1", v1) // c1 = { ("k1",v1) }
+ derivedByInsertionFrom(c2, c1, "k2", v2) // c2 = { ("k1",v1), ("k2", v2) }
+ derivedByRemovalFrom(c3, c2, k1) // c3 = { ("k2",v2) }
</pre>
</div>
-<p> A relation CollectionAfterInsertion<span class="withPn">, written <span class="pnExpression"> CollectionAfterInsertion(collAfter, collBefore, key, value)</span>,</span> contains:</p>
+<p> A relation derivedByInsertionFrom<span class="withPn">, written <span class="pnExpression"> derivedByInsertionFrom(id, collAfter, collBefore, key, value, attrs)</span>,</span> contains:</p>
<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> insertion; </li>
<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> insertion;</li>
<li><span class='attribute'>key</span>: the key that has been inserted</li>
<li><span class='attribute'>value</span>: an identifier for the value that has been inserted with the key.</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
</ul>
-<p> A relation CollectionAfterDeletion, written <span class="pnExpression"> CollectionAfterDeletion(collAfter, collBefore, key)</span>, contains:</p>
+<p> A relation CollectionAfterDeletion, written <span class="pnExpression"> CollectionAfterDeletion(id, collAfter, collBefore, key, attrs)</span>, contains:</p>
<ul>
+<li><span class='attribute'>id</span>: an OPTIONAL identifier identifying the relation;</li>
<li><span class='attribute'>after</span>: an identifier for the collection <em>after</em> the deletion; </li>
<li><span class='attribute'>before</span>: an identifier for the collection <em>before</em> the deletion;</li>
<li><span class='attribute'>key</span>: the key corresponding to the (key, value) pair that has been deleted from the collection.</li>
+<li><span class='attribute'>attributes</span>: an OPTIONAL set of attribute-value pairs to further describe the properties of the relation.</li>
</ul>
+<!--
<div class='note'>
I propose to call them afterInsertion instead of CollectionAfterInsertion (likewise, for deletion).
What about attributes and optional Id?
</div>
-
+-->
<p>Further considerations:</p>
<ul>
<li>The <strong>map</strong> collection type provides a generic indexing structure that can be used to model commonly used data structures, including associative lists (also known as "dictionaries" in some programming languages), relational tables, ordered lists, and more (the specification of such specialized structures in terms of key-value pairs is out of the scope of this document).</li>
-<li>Keys are literals, and values are entities. This allows expressing nested collections, that is, collections whose values include entities of type collection.</li>
-
-<li>Insertion and removal relations are a particular case of <a href="#Derivation-Relation">derivation</a>.</li>
-
- <li>This representation of a collection's evolution makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. In fact, the state of a collection (i.e., the set of key-value pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
+<li>Values are entities. This allows expressing nested collections, that is, collections whose values include entities of type collection.</li>
+
+<li>As the relation names suggest, insertion and removal relations are a particular case of <a href="#Derivation-Relation">derivation</a>.</li>
+
+<li>This representation of a collection's evolution makes no assumption regarding the underlying data structure used to store and manage collections. In particular, no assumptions are needed regarding the mutability of a data structure that is subject to updates. Entities, however, are immutable and this applies to those entities that represent collections. This is reflected in the constraints listed in Part II. </li>
+
+<li>The state of a collection (i.e., the set of key-value pairs it contains) at a given point in a sequence of operations is never stated explicitly. Rather, it can be obtained by querying the chain of derivations involving insertions and removals. Entity type <span class="name">emptyCollection</span> can be used in this context as it marks the start of a sequence of collection operations.</li>
+
+<li>Collections with a content may be generated as a result of an activity. This can be modelled in PROV by asserting insertions to reflect the state of the collection after generation.
+
+<div class='note'>
+TBC with an example
+</div>
+
<!--
Binary file model/working-copy/PROV-modelSketch.zargo has changed
--- a/model/working-copy/notes-for-WD5-PM.txt Fri Mar 09 16:29:43 2012 +0000
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,115 +0,0 @@
-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.
->
->