--- a/model/comments/issue-274-gk.txt Fri Mar 23 08:28:51 2012 +0000
+++ b/model/comments/issue-274-gk.txt Fri Mar 23 09:53:33 2012 +0000
@@ -17,8 +17,7 @@
> runs the risk of confusing readers.
-Do you want to remove reference to "things" too?
-
+OK, no longer talk about "thing in the world" but "thing".
>
@@ -29,20 +28,24 @@
> *abstract* syntax notion; indeed, I think that very expression is an
> oxymoron.
-The WG needs to make a decision on this.
+We now call it PROV-N.
-My preference, at this stage, is to leave it in a separate document.
-1. Past experience has shown that readers confuse prov-dm and prov-n
-2. PROV-N definition is just a grammar, and the grammar is not useful
- to understand prov-dm
+Having gone through the process of writing productions fully, there
+are some grammatical syntactic details that have no place in the PROV-DM document.
+Also, PROV-N provides examples of instances to explain the grammar.
+This has no place in the PROV-DM document either.
+Furthermore, past experience has shown that readers confuse prov-dm and prov-n.
+So, the editor's recommendation is to keep the documents separate.
>
> Part 2 is *not* an upgrade path. Please don't say this. (It's a
> refinement of use that allows provenance information from different
> sources to be combined in meaningful ways.)
-We can, though, others were supportive of the statements ...
+
+Replaced 'upgrade path' by 'refinement'
+
>
> More text refinement in section 1.
@@ -53,9 +56,9 @@
> Saying "Activity is anything ..." is confusing. It suggests a
> continuant rather than an occurrent.
-Why not make this explicit:
+Rephrased as follows:
-An activity is something that occurs and acts upon or with entities.
+An activity is something that occurs and acts upon or with entities.
>
@@ -69,7 +72,7 @@
> instantaneous can come in Part 2)
It was agreed at F2F2 that we shouldn't introduce event in part 1.
-We followed this guidance.
+We followed this guidance. The term event is only defined in part 2.
>
@@ -79,7 +82,8 @@
> for usage, something like "starting to consume".
>
-We can write:
+Updated definitions as follows:
+
Generation is the completion of production of a new entity by an activity.
Usage is the beginning of consumption of a new entity by an activity.
@@ -93,7 +97,7 @@
> "AccountEntity" - why not just "Account". Also, I understood this was
> to *be* a bundle, not a container for a bundle.
-To be addressed, once other editing work for WD5 is completed.
+To be addressed, once other editing work for WD5 is completed.
The two notions (container vs bundle) are useful, for different purposes.
To be investigated.
@@ -105,6 +109,8 @@
> procenance, and that is why we have accounts. I think that should be
> stated clearly; e.g.
+This is made clearer, following definition and in example.
+
>
> "An account is a bundle of provenance statements treated as an entity
> which may itself have some associated provenance."
@@ -128,9 +134,10 @@
> just state that these are commonly encountered kinds of agent, and
> leave it at that.
+"accountable system" is definitely topical.
+We definitely want to stay away from causality.
+
I am not exactly sure what needs to be addressed here.
- "accountable system" is definitely topical.
-
>
>
@@ -142,10 +149,19 @@
>
> The use of responsibility in the description of association seems
> completely wrong to me.
+
+What would you suggest?
+
>
> The discussion of activity association is surreal. A plan is defined
> previously as an "Entity", but association relates an *agent* to an
> activity.
+
+It's a ternary relation.
+This was discussed at length in ISSUE-203, which is now closed.
+
+I am not proposing to reopen it, unless new information is brought forward.
+
>
> I think this section needs re-drafting.
>
@@ -157,6 +173,14 @@
> should appear as part of the introduction to section 2, not at the
> end.
>
+
+We are now generating a PNG, so hopefully its better.
+
+After careful consideration, we felt it was better to leave it in section 2.5, in part,
+because we need to map the concepts (expressed in natural language) to prov-dm types/relations.
+
+
+
>
> Generally in section 2, I think the examples are mostly well-chosen,
> but their presentation breaks up the flow of the overview; I woukd
@@ -167,33 +191,66 @@
> give a quick overview of how the various concepts are used together.
>
>
+
+Usual trade-off. Now that concepts seem clearer, than we don't need examples.
+
+I think that examples are clearly delimited and can be skipped if the reader wants.
+
+
+
> Section 3:
>
> I don't find this example at all helpful. It requires too much effort
> to understand, and I find the process view vs author view is
> confusing. What is this section actually trying to tell the reader?
> I can't tell.
+
+Publishing of documents and their provenance on the Web.
+It seems that it is a primary use case for this specification.
+
>
> I think a comprehensive example like this would be better sited as an
> appendix, rather than an interruption to the main flow of the
> document.
+
+We received positive feedback about the example, and in particular that
+it deals with attribution of provenance.
+
>
>
> Section 4.1:
>
> I find the sub-heading "Element" is confusing/unhelpful.
>
+
+Gone with the new component structure.
+
+
>
> Section 4.1.1 - verbatim repetition of text defining "Entity" already
> present in section - this is unhelpful.
+
+Section 4 contains the systematic presentation of all types and relations.
+Given that many had not been (and should not be) introduced in the
+"starting point section", it is better to have *all* terms defined in section 4.
+
+
>
> The description of the provenance notation expressions should use the
> same terms as are used in the template presented; i.e.. *not* "[
> attr=val1, ... ]" and "attributes".
>
+
+The template shows instances of arguments, where as the descriptions
+provide names for attributes.
+
> Don't need to say anything about disjointness of entities and
> activities in Part 1.
>
+
+This seems in conflict with the next comment. Or is it just about the
+English (avoiding disjoint term)?
+
>
> Secftion 4.1.2
>
@@ -208,16 +265,34 @@
> Similar comments to section 4.1.1
>
> Don't need to say why sub-categories of agent are introduced.
+
+why not? In particular, this was introduced in response to feedback
+from the working group.
+
>
> I would probably avoid making the mutual exclusivity claim (legally,
> it may be or become a debatable point).
>
+
+OK
+
>
> Section 4.1.4
>
> I don't see that notes are an essential part of the provenance
> structure. I'd prefer to drop them, as I don't see them adding any
> expressive capability.
+
+This is ISSUE-260, potentially related to account. We will tackle
+this once we have some bandwidth.
+
+To me, it's crucial to be able to annotate provenance, and to do so in
+an inter-operable way, whatever the serialization.
+
+The questioni is whether the mechanism presented here is the right
+one, or, as Tim suggests, Accounts take care of that.
+
+
>
>
> Section 4.2
@@ -225,23 +300,40 @@
> The table of different relation domain and range combinations is fair
> enough, but I'm not convinced the additional level of document
> structure reflecting this is useful.
+
+Table was kept as a form of index.
+Structure changed to components.
+
>
> Ideally, I think the relations would all appear at the same document
> level as the concepts, so they have a similar "visual signature" when
> scanning the document.
+
+All done.
+
>
> Most or all subsections have repetition of text from section 2 similar
> to that noted for section 4.1.1
+
+Some are repeat, some are new, as indicated above.
+
>
> Also, most sections seem to suffer from a similar mismatch between the
> provenance notation template given and the accompanying description of
> the constituent elements.
+
+The template shows instances of arguments, where as the descriptions
+provide names for attributes.
+
>
> I think generation and usage should be described as events (not
> necxessarily to introduce a formal notion of events, just make it
> clear that they are events corresponding to some change in the
> relationship between an entity and an activity)
>
+
+See comment above.
+
>
> Section 4.2.2.1
>
@@ -255,10 +347,18 @@
>
> At the very least, I think these aspects should be separated, not just
> lumped into an single overloaded element.
+
+This was discussed at length in ISSUE-203, which is now closed. see above.
+
>
> I'm not sure why some expression components are explicit and possibly
> optional parameters, while athewrs are attributes. What's the
> intended difference here?
+
+For rationale see:
+
+http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-n.html#positional-vs-named-attributes
+
>
>
> Section 4.2.3.1
@@ -281,6 +381,23 @@
> explaining how to use the component?
>
>
+
+PROV-DM allows you to express the relations.
+If I understood correctly, we have:
+
+wasGeneratedBy(component,purchase)
+actedOnBehalfOf(engineer,manager,purchase, [role="line management"])
+actedOnBehalfOf(manager,engineer,deployment, [role="technical guidance"])
+
+PROV-DM does not say how to reason about responsibility.
+What is the answer to your question?
+
+This said, did you mean
+ actedOnBehalfOf(manager,engineer,deployment, [role="technical guidance"])
+or did you mean:
+ wasInformedBy(manager,engineer)
+
+
> Section 4.2.3.2
>
> Skipped - I understand this is due to be replaced. (Despite my
@@ -292,11 +409,23 @@
>
> Do we still need Alternate and Specialization in the provenance
> notation?
+
+
+Do you mean in PROV-DM?
+
+Yes, I think these are relations of the data model. They need
+to be introduced in this document.
+
+
+
>
> ...
>
> I'm running out of time, so I'll stop here.
>
+
+
+Thanks,
>
>
>
--- a/model/glossary.html Fri Mar 23 08:28:51 2012 +0000
+++ b/model/glossary.html Fri Mar 23 09:53:33 2012 +0000
@@ -2,14 +2,15 @@
<html>
<div class="glossary" id="glossary-entity">
-<dfn id="concept-entity" title="entity">Entities</dfn> are things in the world one
+<dfn id="concept-entity" title="entity">Entities</dfn> are things one
wants to provide provenance for. For the purpose of this
specification, things can be physical, digital, conceptual, or
- otherwise; the world may be real or imaginary.
+ otherwise; things may be real or imaginary.
</div>
<span class="glossary" id="glossary-activity">
-An <dfn id="concept-activity">activity</dfn> is anything that acts upon or with entities.
+An <dfn id="concept-activity">activity</dfn>
+ is something that occurs and acts upon or with entities.
This action can take multiple forms: consuming, processing, transforming, modifying, relocating, using, generating, or being associated with entities.
</span>
@@ -18,12 +19,12 @@
</span>
<span class="glossary" id="glossary-generation">
-<dfn id="concept-generation">Generation</dfn> is the completed production of a new entity by an activity.
+<dfn id="concept-generation">Generation</dfn> is the completion of production of a new entity by an activity.
This entity become available for usage after this generation. This entity did not exist before generation.
</span>
<span class="glossary" id="glossary-usage">
-<dfn id="concept-usage">Usage</dfn> is the beginning of an entity being consumed by an activity.
+<dfn id="concept-usage">Usage</dfn> is the beginning of consumption of an entity by an activity.
Before usage, the activity had not begun to consume or use this entity and could not have been affected by the entity.
</span>
@@ -48,7 +49,7 @@
<span class="glossary" id="glossary-provenance">
<dfn>Provenance</dfn> is a record that describes the people,
institutions, entities, and activities, involved in producing,
-influencing, or delivering a piece of data or a thing in the world.
+influencing, or delivering a piece of data or a thing.
</span>
@@ -91,7 +92,7 @@
</span>
<span class="glossary" id="glossary-event">
-An <em>instantaneous event</em>, or <dfn id="concept-event">event</dfn> for short, happens in the world and marks a change in the world, in its
+oAn <em>instantaneous event</em>, or <dfn id="concept-event">event</dfn> for short, happens in the world and marks a change in the world, in its
activities and in its entities.
</span>
--- a/model/glossary.js Fri Mar 23 08:28:51 2012 +0000
+++ b/model/glossary.js Fri Mar 23 09:53:33 2012 +0000
@@ -9,14 +9,14 @@
'<html> ' +
' ' +
'<div class="glossary" id="glossary-entity"> ' +
-'<dfn id="concept-entity" title="entity">Entities</dfn> are things in the world one ' +
+'<dfn id="concept-entity" title="entity">Entities</dfn> are things one ' +
' wants to provide provenance for. For the purpose of this ' +
' specification, things can be physical, digital, conceptual, or ' +
-' otherwise; the world may be real or imaginary. ' +
+' otherwise; things may be real or imaginary. ' +
'</div> ' +
' ' +
'<span class="glossary" id="glossary-activity"> ' +
-'An <dfn id="concept-activity">activity</dfn> is anything that acts upon or with entities. ' +
+'An <dfn id="concept-activity">activity</dfn> is something that occurs and acts upon or with entities. ' +
'This action can take multiple forms: consuming, processing, transforming, modifying, relocating, using, generating, or being associated with entities. ' +
'</span> ' +
' ' +
@@ -25,12 +25,12 @@
'</span> ' +
' ' +
'<span class="glossary" id="glossary-generation"> ' +
-'<dfn id="concept-generation">Generation</dfn> is the completed production of a new entity by an activity. ' +
+'<dfn id="concept-generation">Generation</dfn> is the completion of production of a new entity by an activity. ' +
' This entity become available for usage after this generation. This entity did not exist before generation. ' +
'</span> ' +
' ' +
'<span class="glossary" id="glossary-usage"> ' +
-'<dfn id="concept-usage">Usage</dfn> is the beginning of an entity being consumed by an activity. ' +
+'<dfn id="concept-usage">Usage</dfn> is the beginning of consumption of an entity by an activity. ' +
'Before usage, the activity had not begun to consume or use this entity and could not have been affected by the entity. ' +
'</span> ' +
' ' +
@@ -55,7 +55,7 @@
'<span class="glossary" id="glossary-provenance"> ' +
'<dfn>Provenance</dfn> is a record that describes the people, ' +
'institutions, entities, and activities, involved in producing, ' +
-'influencing, or delivering a piece of data or a thing in the world. ' +
+'influencing, or delivering a piece of data or a thing. ' +
'</span> ' +
' ' +
' ' +
--- a/model/prov-dm.html Fri Mar 23 08:28:51 2012 +0000
+++ b/model/prov-dm.html Fri Mar 23 09:53:33 2012 +0000
@@ -286,7 +286,7 @@
<p>
For the purpose of this specification, <dfn>provenance</dfn> is defined as a record that describes the people,
institutions, entities, and activities, involved in producing,
-influencing, or delivering a piece of data or a thing in the world.
+influencing, or delivering a piece of data or a thing.
In particular, the provenance of information is crucial in deciding
whether information is to be trusted, how it should be integrated with
other diverse information sources, and how to give credit to its
@@ -331,7 +331,7 @@
<p>This specification intentionally presents the key concepts of the PROV Data Model, without drilling down into all its subtleties. Using these key concepts, it becomes possible to write useful provenance assertions very quickly, and publish or embed them along side the data they relate to. </p>
-<p>However, if data changes, then it is challenging to express its provenance precisely, like it would be for any other form of metadata. To address this challenge, an <em>upgrade path</em> is proposed to enrich simple provenance, with extra-descriptions that help qualify the specific subject of provenance and provenance itself, with attributes and interval, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [[PROV-DM-CONSTRAINTS]].
+<p>However, if data changes, then it is challenging to express its provenance precisely, like it would be for any other form of metadata. To address this challenge, a <em>refinement</em> is proposed to enrich simple provenance, with extra-descriptions that help qualify the specific subject of provenance and provenance itself, with attributes and interval, intended to satisfy a comprehensive set of constraints. These aspects are covered in the companion specification [[PROV-DM-CONSTRAINTS]].
</p>
@@ -394,7 +394,7 @@
<h2>Entity and Activity</h2>
-<p>PROV-DM is a data model for describing the provenance of <em>Entities</em>, that is, of things in the world. The term "Things" encompasses a broad diversity of concepts, including digital objects such as a file or web page,
+<p>Things we want to describe the provenance of are called <em>entities</em> in PROV. The term "things" encompasses a broad diversity of notions, including digital objects such as a file or web page,
physical things such as a building or a printed book, or a car as well as abstract concepts and ideas. One can regard any Web resource as an example of Entity in this context. </p>
<p>
@@ -404,7 +404,7 @@
<div class="anexample" id="entity-example">
-<p>An entity may be the document at URI <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a>, a file in a file system, a car or an idea.</p>
+<p>An entity may be the document at URI <a href="http://www.w3.org/TR/prov-dm/">http://www.w3.org/TR/prov-dm/</a>, a file in a file system, a car, or an idea.</p>
</div>
@@ -524,17 +524,17 @@
<!-- alternative names: provenance record, bundle -->
<p>
<span class="glossary-ref" ref="glossary-accountEntity" withspan="true">
-</span>
+</span>By making it an entity, PROV-DM allows for provenance of provenance to be expressed.
<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 want to analyze its provenance, but also determine
-who the 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.
+For users to decide whether they can place their trust in
+a resource, they may want to analyze the resource's provenance, but also determine
+who its provenance is attributed to, and when it was
+generated. In other words, users need to be able to determine the provenance of provenance.
+Hence, in the PROV data model, provenance is also
+regarded as an entity, an AccountEntity; using PROV-DM, provenance of provenance can then be
+expressed.
</p>
</div>
@@ -542,7 +542,7 @@
<p>Three types of agents are recognized by PROV-DM because they are commonly encountered in applications 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
+<p> Even software agents can be assigned some responsibility for the effects they have, 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). </p>
</div>
@@ -676,7 +676,7 @@
</p>
<p>However, it is important to provide instances of provenance for human consumption, as in this document or elsewhere.
-To this end, PROV-N is a notation that is designed to write instances of the PROV-DM data model in a compact textual form, without the syntactic bagage and constraints coming with a markup language such as XML or a description framework such as RDF. We outline here some of its key design principles. For full details, the reader is referred to the companion specification [[PROV-N]].</p>
+To this end, PROV-N is a notation that is designed to write instances of the PROV-DM data model in a compact textual form, without the syntactic baggage and constraints coming with a markup language such as XML or a description framework such as RDF. We outline here some of its key design principles. For full details, the reader is referred to the companion specification [[PROV-N]].</p>
<ul>
<li>PROV-N expressions adopt a <em>functional notation</em> consisting
@@ -807,8 +807,8 @@
<p>The graphical illustration takes the form of a graph. Entities, activities and agents are represented as nodes, with oval, rectangular, and octagonal shapes, respectively. Usage,
Generation, Derivation, and Activity Association are represented as directed edges.</p>
-<p>Entities are laid out according to the ordering of their generation event. We endeavor to show time progressing from top to bottom. This means that edges for Usage, Generation and
-Derivation typically point upwards.</p>
+<p>Entities are laid out according to the ordering of their generation. We endeavor to show time progressing from left to right. This means that edges for Usage, Generation,
+Derivation, Association typically point leftwards</p>
@@ -1063,7 +1063,7 @@
<p>Further considerations:</p>
<ul>
-<li>The sets of Activities and Entities are disjoint, as described below.</li>
+<li>The sets of activities and entities are disjoint, as described below.</li>
</ul>
@@ -1406,7 +1406,7 @@
<li><span class="name">Organization</span>: agents of type Organization are social institutions such as companies, societies etc.</li>
<li><span class="name">SoftwareAgent</span>: a software agent is a piece of software. </li>
</ul>
-<p>These types are mutually exclusive, though they do not cover all kinds of agent. </p>
+<p>These types do not cover all kinds of agent. </p>
@@ -1467,7 +1467,7 @@
<li><span class='attribute' id="association.attributes">attributes</span>: an OPTIONAL set of attribute-value pairs that describe the modalities of association of this activity with this agent.</li>
</ul></div>
-<div class="anexample id="anexample-wasAssociateWith">
+<div class="anexample" id="anexample-wasAssociateWith">
In the following example, a designer and an operator agents are associated with an activity. The designer's goals are achieved by a workflow <span class="name">ex:wf</span>.
<pre class="codeexample">
activity(ex:a,[prov:type="workflow execution"])
@@ -1829,7 +1829,7 @@
</div>
-<p>This component consists of relations between two entities that refer to the same thing in the world.
+<p>This component consists of relations between two entities that refer to the same thing
Consider for example three entities:
</p>
<ul>
--- a/model/prov-n.html Fri Mar 23 08:28:51 2012 +0000
+++ b/model/prov-n.html Fri Mar 23 09:53:33 2012 +0000
@@ -314,7 +314,7 @@
<p>A key goal of PROV-DM is the specification of a machine-processable data model for provenance so that application having obtained the provenance of the resource they manipulate can reason about such provenance. As such, representations of PROV-DM are available in RDF and XML.
</p>
-<p>However, communicating provenance between humans is also important when teaching, illustrating, formalizing, and discussing provenance-related issues. To this end, PROV-N is a notation that is designed to write instances of the PROV-DM data model in a compact textual form, without the syntactic bagage and constraints coming with a markup language such as XML or a description framework such as RDF. </p>
+<p>However, communicating provenance between humans is also important when teaching, illustrating, formalizing, and discussing provenance-related issues. To this end, PROV-N is a notation that is designed to write instances of the PROV-DM data model in a compact textual form, without the syntactic baggage and constraints coming with a markup language such as XML or a description framework such as RDF. </p>
<ul>
<li>PROV-N adopts a <em>functional notation</em> consisting a name and a series of arguments in bracket.</li>
@@ -384,7 +384,7 @@
activity(ex:a10, [ex:param="a", ex:param="b"])
</pre>
</div>
-<li> PROV-N exposes attributes that PROV-DM provides an interpretation for [[PROV-DM-CONSTRAINTS]] directly as positional arguments of expressions, whereas those for which PROV-DM provides no interpretation need to be expressed among the optional attribute-value pairs.
+<li id="positional-vs-named-attributes"> PROV-N exposes attributes that PROV-DM provides an interpretation for [[PROV-DM-CONSTRAINTS]] directly as positional arguments of expressions, whereas those for which PROV-DM provides no interpretation need to be expressed among the optional attribute-value pairs.
</li>
<div class="note">