collection/account
authorLuc Moreau <l.moreau@ecs.soton.ac.uk>
Wed, 08 Feb 2012 11:20:23 +0000
changeset 1498 f1d529256f0f
parent 1497 aed0a0382ae9
child 1499 240df509f7a0
collection/account
model/working-copy/towards-wd4.html
--- a/model/working-copy/towards-wd4.html	Wed Feb 08 10:49:35 2012 +0000
+++ b/model/working-copy/towards-wd4.html	Wed Feb 08 11:20:23 2012 +0000
@@ -388,18 +388,39 @@
 </p>
 </div>
 
-<p>A <dfn id="concept-collection">Collection</dfn> is an entity that has internal structure. PROV-DM defines provenance constructs for a very general type of collection, namely a set of key-value pairs (referred to as a <em>map</em> or, in some programming languages, a <em>dictionary</em> or <em>associative array</em>). This can be used to describe other collection types, including for example nested ordered lists. The definition of such more specific types is out of the scope of PROV-DM.
-</p>
+<p>A <dfn id="concept-collection">Collection</dfn> is an entity that has a logical internal structure consisting of key-value pairs, in which values are themselves entities. This concept allows for the provenance of the collection, but also of its constituents to be expressed.  Such a notion of collection corresponds to a wide variety of  concrete data structures, such as a <em>maps</em>, <em>dictionaries</em> or <em>associative arrays</em>.</p>
+
+<div class="anexample" id="collection-example">
+<p>
+An example of collection is an archive of documents. Each document has its own provenance, but the archive itself also has some provenance: who maintained it, which document it contained at which point in time, how it was assembled, etc. 
+</div>
 
 
-<p>A <dfn id="concept-accountEntity">AccountEntity</dfn> is an entity that is contains a bundle of provenance assertions. </p>
+<!-- alternative names: provenance record, bundle -->
+<p>An <dfn id="concept-accountEntity">AccountEntity</dfn> is an entity that contains a bundle of provenance assertions. </p>
+
+<div class="anexample" id="account-example">
+<p>
+Having found a resource, a user may want to retrieve its
+provenance. For users to decide whether they can place their trust in
+that resource, they may to analyse its provenance, but also determine
+who this provenance is attributed to, and when it was
+generated. Hence, from the PROV-DM data model, the provenance is
+regarded as an entity, an AccountEntity, for which provenance can be
+sought.
+</p>
+</div>
+
 
 <p>Three types of agents are recognized by PROV-DM because they are commonly encountered in application making data and documents available on the Web: persons, software agents, and organizations.</p>
 
+<div class="anexample" id="software-agents-example">
 <p> Even software agents can be assigned some responsibility for the effects they have in the world, so for example if one is using a Text Editor and one's laptop crashes, then one would say
 that the Text Editor was responsible for crashing the laptop.  If one invokes a service to buy a book, that service can be considered responsible for drawing funds from one's bank to make
-the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well).  So when
-someone models software as an agent for an activity in our model, they mean the agent has some responsibility for that activity.</p>
+the purchase (the company that runs the service and the web site would also be responsible, but the point here is that we assign some measure of responsibility to software as well). </p>
+</div>
+<p>So when
+someone models software as an agent for an activity in the PROV-DM model, they mean the agent has some responsibility for that activity.</p>
 </section>
 
     <section id="section-responsibility">