--- a/model/comments/wd6-Graham.txt Tue May 29 19:58:27 2012 -0400
+++ b/model/comments/wd6-Graham.txt Wed May 30 09:35:51 2012 +0100
@@ -20,9 +20,9 @@
> 2. So my proposals focus more on explaining how the concepts work
> together and not repeating the actual definitions.
-I am in favour of keeping definitions in section 2, to make it self-contained.
-Paul, Paolo, what do you think?
-Do we seek a WG resolution?
+I am in favour of keeping definitions in section 2 to make it self-contained.
+Also, as I mention below, there is a danger of paraphrasing definitions and
+conveying a different meaning.
>
> As I reflect on what I've read, I think it might be worth linking each
@@ -32,6 +32,7 @@
This can be done.
Suggestion: at the end of each definition, add a link to the corresponding subsection in section 5.
+I did it for activty/entiy in 2.1.1. Thoughts?
>
> Detailed comments follow.
@@ -77,6 +78,9 @@
> "core structures form the essence of provenance descriptions, and
> are commonly found in various domain-specific vocabularies that deal
> with provenance or similar kinds of information".
+
+Done.
+
>
> (Examples, or informational references, could be added to back up this
> statement - precursor provenance models and CIDOC-CRM are examples I
@@ -91,9 +95,8 @@
> follow on from entities and activities (or folded in with those).
> More detail later in discussion of core structures.
-We have reorganized components as follows,
-addressing your concern that derivation follows entities and activities,
-generation and usage.
+We have reorganized components as follows, addressing your concern
+that derivation follows entities and activities, generation and usage.
component 2: derivation
component 3: agent/responsibility.
@@ -172,21 +175,8 @@
> column of the table, but types use values from the "Concepts" column.
>
-I am aware of this. It shows at a couple of other places.
-
-How do we write
- wasDerivedFrom(e2,e1,[prov:type='prov:WasRevisionOf'])
-
-Is it prov:WasRevisionOf or prov:wasRevisionOf?
-
-Should relation names be capitalized, e.g. WasDerivedFrom
-while their writing in prov-n is not, e.g. wasDerivedFrom(e2,e1)?
-
-Proposal: In all diagrams, capitalize relations.
- In table 2, capitalize all entries in column 'Name'
-
-
-Paolo?
+The inconsistency was addressed.
+Relations are now capitalized. Instances, in prov-n, are lower case.
> I think it's a little confusing that there are named "concepts" and
> (sometimes) different names for the types and relations. This is
@@ -203,7 +193,7 @@
The latter is the concept, the former the relation.
I would be reluctant to replace 'wasGeneratedBy' by 'Generation' in
-Figure. Likewise, I would be reluctant to say "WasGeneratedBy is the
+figures. Likewise, I would be reluctant to say "WasGeneratedBy is the
completion of production of a new entity ..."
So, the solution above, with capitalization of relations would address
@@ -242,6 +232,7 @@
> entities; they are the mechanisms by which entities are created and
I don't feel like we should paraphrase definitions of terms.
+Choice of term 'consume' is too restrictive, that's why I also use alternatives.
> used in the creation of further entities. Just as entities cover a
@@ -278,7 +269,7 @@
> <example 4 here>
The above suggested text says 'Usage is relationship' .... 'Usage is considered to occur'
-So, it mixes 'data model construct' and 'concept'
+So, it mixes 'data model construct' and 'concept'.
I tried to stay with definitions of concepts here.
>
@@ -302,14 +293,14 @@
Good!
-Can I check that you meant "in this case a car in Boston may be a
- different ENTITY from a car in Cambridge" ... and not ARTIFACT?
+I summed that you meant "in this case a car in Boston may be a
+different ENTITY from a car in Cambridge" ... and not ARTIFACT?
>
> <I added a fair amount of explanatory text here, because I think that
> the whole issue of breadth of interpretation begs some explanation.>
-Yes, good idea.
+Yes, it is good idea. I included it.
>
> Communication is the generation of an entity by an activity and its
@@ -337,10 +328,6 @@
-<!-- The activity of purchasing a
- car in Boston can be informed by the the activity of its being
- designed in Japan.-->
-
>
> == After section 2.1.1 ==
@@ -354,7 +341,7 @@
> Y and Z; my Ford car was derived from a VW design).
>
-I would propose to swap 2.1.2 and 2.1.3
+I have swapped 2.1.2 and 2.1.3.
> Thus, following on from the proposed revised 2.1.1:
>
@@ -395,8 +382,6 @@
I like it, I have added it after a few tweaks.
-
-
>
> == Section 2.1.2 ==
>
@@ -435,6 +420,7 @@
> initiate, control or otherwise bear responsibility for an activity.
Again, I want to avoid paraphrasing the definition.
+We moved away from "control" a long time ago.
>
> <example 6 here>
@@ -443,10 +429,6 @@
> had some role in the activity.
>
-An entity used by an activity also has some roles.
-The WG agreed that agent association means implies responsibility.
-
-
> <example 8 here>
>
> An /attribution/ of an entity to an agent means that the entity was
@@ -462,7 +444,8 @@
> any such decisions should be made. ]]
>
-There is too much instance on this in your suggestions. I am dropping this.
+There is too much instance on this in your suggestions.
+I am not including this.
> .........
@@ -474,6 +457,8 @@
> Section 2.2 structure feels a bit contrived to me ... it deals with
> extension mechanisms (2.2.1) and some new concepts (2.2.2 and 2.2.3)
>
+
+... but the new concepts belong to the extended structures.
> My inclination would be to present:
> 2.2 Additional structures
> 2.2.1 Bundle
@@ -482,6 +467,9 @@
> 2.3.1 Subtyping
> 2.3.2 Multi-way relations
> 2.3.3 Optional identification and new relations
+
+What is 'additional structures' here? are they extended structures?
+
>
> My further comments use the current section numbering...
>
@@ -533,6 +521,10 @@
>
> The section title doesn't make any sense to me. The "New relations"
> bit is particularly confusing.
+
+I made it a separate header. This now identifies four ways by which we
+have created extended structures.
+
>
> From the description, it looks to me like reification of a relation so
> that arbitrary further information can be added to an instance.
@@ -565,7 +557,7 @@
> A /provenance description/ is a set of assertions based on the core and extended provenance structures described below.
> ]]
-I added "provenance description is an instance of a core and extended
+I added "a provenance description is an instance of a core and extended
provenance structure described below."
>
@@ -624,6 +616,8 @@
>
> Figure 5: uses UML, but at one point I was looking for cardinality indicators (1:1, 1:N, N:M, etc.)
+
+TO DO.
Paolo, can you tell me what to add? where? What's the UML default?
@@ -649,7 +643,7 @@
> "An activity is not an entity" - I think you said otherwise further up (see previous email).
>
-Not to my knowledge. It was about agent.
+Not to my knowledge.
> == Section 5.1.3 ==
>
@@ -684,12 +678,18 @@
> (what bureaucratic process could be so simple?).
+Yes, it was the intent.
+
+
>
> == Section 5.1.6 ==
>
> The phrase "that initiated the activity" suggests to me that the
> trigger is an agent (i.e. capable of action). Maybe "that set of..."
> ?
+
+Good suggestion.
+
>
>
> == Section 5.2.1 ==
@@ -700,6 +700,12 @@
> unsupervised action; that they can directly initiate an activity
> without the direct involvement of any other agent at the time.
>
+
+That's exactly the path we didn't want to follow: some communities
+don't see autonomy as a key feature of an agent (e.g. mail agent).
+
+
+
> == Section 5.2.3 ==
>
> As above.
@@ -708,6 +714,13 @@
> agent can be associated with an activity. The example makes it clear
> that this is allowed, but the phrasing "assignment of responsibility"
> suggests otherwise to me.
+
+Sorry, I don't understand the issue about the phrasing.
+
+Yes, we can have multiple agents associated with an activity, each with
+a different association.
+
+
>
> == Section 5.2.4 ==
>
@@ -715,6 +728,10 @@
> The use of responsibility here is rather more in line with my
> expectation, and not, I think, fully consistent with the preceding
> uses.
+
+
+In what way is this inconsistent?
+
>
> == Section 5.3.1 ==
>
@@ -737,6 +754,15 @@
> information obtained directly or indirectly from another pre-existing
> entity. ]]
>
+
+It seems to restrictive: why information?
+
+New definition:
+
+
+A derivation is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-exisiting entity.
+
+
>
> == Section 5.3.2 ==
>
@@ -747,6 +773,9 @@
> revised version of some original. The implication here is that
> the resulting entity contains substantial content from the
> original."
+
+Good.
+
>
>
> == Section 5.3.3 ==
@@ -757,6 +786,11 @@
>
> "A quotation is a form of derivation in which the new entity contains
> a verbatim copy of some or all of the original entity's content."
+
+
+This was agreed a while back. If you feel like changing it, I suggest
+you raise an issue about it.
+
>
>
> == Section 5.3.4 ==
@@ -765,9 +799,14 @@
> == Section 5.3.5 ==
>
> What's a "responsibility" relation - I don't see that defined anywhere.
+
+It was Delegation.
+
>
> I'm completely unclear what is meant by this relation that isn't already covered by derivation.
>
+
+Delegation. + the fact that it is transitive.
>
> I might /guess/ that it's meant to allow the "entity" concerned to be
> an agent in the overall process, but I find that confusing given that
@@ -775,6 +814,8 @@
>
> What's the requirement for this relation? Do we really need it?
>
+http://www.w3.org/2011/prov/track/issues/370
+
>
> == Section 5.4.1 ==
>
@@ -785,6 +826,9 @@
> the lifetime of the more general entity contains that of any
> specialization."
>
+
+This was voted recently. You need to raise a new ISSUE for this.
+
>
> I know this is formally a topic for CONSTRAINTS, but I think it would
> help to give an indication of whether a thing can be considered a
@@ -797,6 +841,9 @@
> In example 41, you claim "They are both specialization of an
> (unspecified) entity." If this is true, shouldn't it be part of the
> definition of alternate?
+
+I dropped it.
+
>
>
> == section 5.5 ==
@@ -810,6 +857,8 @@
> element in a definition. (See previous comment - maybe in other
> email)
>
+
+was added as suggested.
>
> == Section 5.5.2 ==
>
@@ -830,6 +879,19 @@
> provides no new information. If the bundle constructor is not
> present, WHY does it matter that the entity described is provenance?
>
+
+Note that the Bundle constructor may not be present (when considering
+incremental navigation, because it has not been retrieved yet).
+
+In fact there is a good reason why you may want to analyse provenance-of-provenance
+before you retrieve the provenance of something. I will retrieve an account that
+is generated by xyz, or an account that provides details.
+
+
+prov:Collection, prov:Plan, prov:Bundle, prov:Dictionary all fall in the same category.
+This type information can be inferred. (We discussed this by email on a separate thread.)
+
+
>
> == Section 5.5.3 ==
>
@@ -851,6 +913,9 @@
>
> I've raised this as a separate issue, as I think it needs discussion.
>
+
+Discussion in progress.
+
>
> == Section 5.6 ==
>
@@ -867,6 +932,11 @@
> provenance data model, rather than part of the PROV-N specification?
> It seems to me that most of this is syntactic artifact.
>
+
+prov-n is just a serialization for what prov-dm defines.
+If identifiers have not been specified as qualified names in prov-dm,
+how can we create a serialization prov-n?
+
>
> == Section 5.7.4 ==
>
@@ -875,9 +945,16 @@
> would be more appropriately presented as an immediate subsection of
> section 5 (e.g. 5.7, with the rest of section 5.7 becoming 5.8)
>
+
+
> == Section 5.7.5 ==
>
> Similar comments to above.
+
+
+I moved namespace declaration and qualified name after identifier/attribute/value.
+
+
>
>
> == Section 6 ==
@@ -892,6 +969,9 @@
> The second bullet point already does this for prov:type. I think
> this should come first, followed by a similar entry for prov:role.
+
+OK, I will have a go at this.
+
>
>
> == Section 7 ==
@@ -902,4 +982,11 @@
> the PROV-CONSTRAINTS document settles (especially its introduction and
> abstract). I think they should be conveying the same message.
>
- >
+
+
+I think it's useful to have a 'taster' for prov-constraints.
+Otherwise, readers won't remember we mentioned it in introduction.
+
+Agreed it should be aligned with prov-constraints.
+
+Luc
--- a/model/glossary.html Tue May 29 19:58:27 2012 -0400
+++ b/model/glossary.html Wed May 30 09:35:51 2012 +0100
@@ -26,7 +26,7 @@
</span>
<span class="glossary" id="glossary-derivation">
-A <dfn id="concept-derivation">derivation</dfn> is a transformation of an entity into another, an update of an entity, resulting in a new one, or based on an entity, the construction of another.</span>
+A <dfn id="concept-derivation">derivation</dfn> is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-exisiting entity.</span>
@@ -133,13 +133,15 @@
</span>
<span class="glossary" id="glossary-revision">
-A <dfn id="concept-revision">revision</dfn> is a derivation that revises an entity into a revised version.
+A <dfn id="concept-revision">revision</dfn>
+ is a derivation for which the resulting entity is a
+revised version of some original.
</span>
<span class="glossary" id="glossary-start">
<dfn id="concept-start">Start</dfn> is when an activity is deemed to have started.
The activity did not exist before its start. Any usage or generation involving an activity follows the activity's start.
-A start may refer to an entity, known as <dfn id="concept-start-trigger">trigger</dfn>, that initiated the activity, or to an activity, known as <dfn id="concept-start-starter">starter</dfn>, that generated the trigger.
+A start may refer to an entity, known as <dfn id="concept-start-trigger">trigger</dfn>, that set off the activity, or to an activity, known as <dfn id="concept-start-starter">starter</dfn>, that generated the trigger.
</span>
--- a/model/glossary.js Tue May 29 19:58:27 2012 -0400
+++ b/model/glossary.js Wed May 30 09:35:51 2012 +0100
@@ -3,7 +3,7 @@
// with <script src="glossary.js" class="remove"></script>
//Insert glossary definitions with the following
// <div class="glossary-ref" ref="glossary-generation"></div>
-glossary_hg='http://dvcs.w3.org/hg/prov/file/51c1fe338db9/model/glossary.html';
+glossary_hg='http://dvcs.w3.org/hg/prov/file/b107f73c23f4/model/glossary.html';
glossary_string=
' ' +
'<html> ' +
@@ -33,7 +33,7 @@
'</span> ' +
' ' +
'<span class="glossary" id="glossary-derivation"> ' +
-'A <dfn id="concept-derivation">derivation</dfn> is a transformation of an entity into another, an update of an entity, resulting in a new one, or based on an entity, the construction of another.</span> ' +
+'A <dfn id="concept-derivation">derivation</dfn> is a transformation of an entity into another, an update of an entity resulting in a new one, or the construction of a new entity based on a pre-exisiting entity.</span> ' +
' ' +
' ' +
' ' +
@@ -140,13 +140,15 @@
'</span> ' +
' ' +
'<span class="glossary" id="glossary-revision"> ' +
-'A <dfn id="concept-revision">revision</dfn> is a derivation that revises an entity into a revised version. ' +
+'A <dfn id="concept-revision">revision</dfn> ' +
+' is a derivation for which the resulting entity is a ' +
+'revised version of some original. ' +
'</span> ' +
' ' +
'<span class="glossary" id="glossary-start"> ' +
'<dfn id="concept-start">Start</dfn> is when an activity is deemed to have started. ' +
' The activity did not exist before its start. Any usage or generation involving an activity follows the activity\'s start. ' +
-'A start may refer to an entity, known as <dfn id="concept-start-trigger">trigger</dfn>, that initiated the activity, or to an activity, known as <dfn id="concept-start-starter">starter</dfn>, that generated the trigger. ' +
+'A start may refer to an entity, known as <dfn id="concept-start-trigger">trigger</dfn>, that set off the activity, or to an activity, known as <dfn id="concept-start-starter">starter</dfn>, that generated the trigger. ' +
'</span> ' +
' ' +
' ' +
--- a/model/prov-dm.html Tue May 29 19:58:27 2012 -0400
+++ b/model/prov-dm.html Wed May 30 09:35:51 2012 +0100
@@ -604,8 +604,8 @@
</p>
<p>
-<div class="glossary-ref" data-ref="glossary-entity" data-withspan="true">
-</div>
+<span class="glossary-ref" data-ref="glossary-entity" data-withspan="true">
+</span> [<a href="#term-entity">Detailed specification</a>]</p>
@@ -616,7 +616,7 @@
<p>
-<span class="glossary-ref" data-ref="glossary-activity" data-withspan="true"></span>
+<span class="glossary-ref" data-ref="glossary-activity" data-withspan="true"></span> [<a href="#term-activity">Detailed specification</a>]
Just as entities cover a broad range of notions,
activities can cover a broad range of
notions:
@@ -912,8 +912,8 @@
</section>
-<section id="section-prov-extended-approach-optional-identification-new-relation">
-<h2>Optional Identification and New Relations</h2>
+<section id="section-prov-extended-approach-optional-identification">
+<h2>Optional Identification</h2>
<p>Some concepts exhibit both a core use, expressed as
binary relation, and an extended use, expressed as n-ary relation. In
@@ -929,15 +929,18 @@
<p>A service may read a same configuration file on two different occasions. Each usage can be identifed by its own identifier, allowing them to be distinguished.
</div>
+
+</section>
+
+
+
+<section id="section-prov-extended-approach-further-relations">
+<h2>Further Relations</h2>
+
<p>Finally, PROV-DM supports further relations that are not subtypes or expanded versions of existing relations.</p>
-
-
</section>
-
-
-
</section>
@@ -1394,7 +1397,7 @@
<tr><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td></tr>
<tr class="component5-color"><td><a title="bundle">Bundle constructor</a></td><td><a title="dfn-bundle">bundle id description_1 ... description_n endBundle</a></td><td rowspan="3"><a href="#component5">Component 5: Bundles</a></td></tr>
-<tr class="component5-color"><td class="provType"><a title="bundle">Bundle description</a></td><td><a>... prov:type='prov:Bundle' ...</a></td></tr>
+<tr class="component5-color"><td class="provType"><a title="bundle">Bundle type</a></td><td><a>... prov:type='prov:Bundle' ...</a></td></tr>
<tr class="component5-color"><td><a>Provenance Locator</a></td><td><a title="hasProvenanceIn">hasProvenanceIn(id, subject, bundle, target, service, prov, attrs)</a></td></tr>
<tr><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td><td style="border-width: 0px; "></td></tr>
@@ -1935,7 +1938,11 @@
<p><span class="glossary-ref" data-ref="glossary-revision"></span></p>
-<p>Revision is a particular case of <a>derivation</a> of an entity into its revised version.</p>
+<p>
+ The implication here is that
+ the resulting entity contains substantial content from the
+ original.
+Revision is a particular case of <a>derivation</a> of an entity into its revised version.</p>
<!-- <p> A <dfn title="wasRevisionOf">revision</dfn> relation<span class="withPn">, written <span class="pnExpression">wasRevisionOf(id; e2, e1, a, g2, u1, attrs)</span> in PROV-N,</span> has:</p>
<ul>
@@ -2419,7 +2426,6 @@
entity(bbc:news/mobile/science-environment-17526723, [ prov:type="a news item for mobile devices"])
alternateOf(bbc:news/science-environment-17526723, bbc:news/mobile/science-environment-17526723)
</pre>
-<p>They are both specialization of an (unspecified) entity. </p>
</div>
@@ -2443,7 +2449,7 @@
<p>The fifth component of PROV-DM is concerned with bundles, a mechanism to support provenance of provenance.
-<a href="#figure-component5">Figure 9</a> depict a UML class diagram for the fifth component. It comprises a <a>Bundle</a> class, a subclass of <a>Entity</a> and a novel n-ary relation, <a>Provenance Locator</a>.
+<a href="#figure-component5">Figure 9</a> depicts a UML class diagram for the fifth component. It comprises a <a>Bundle</a> class, a subclass of <a>Entity</a> and a novel n-ary relation, <a>Provenance Locator</a>.
</p>
<div style="text-align: center;">
@@ -2488,7 +2494,7 @@
<section id="term-bundle-entity">
-<h3>Bundle Description</h3>
+<h3>Bundle Type</h3>
<p>A bundle is a named set of descriptions, but it is also an entity so that its provenance can be described. </p>
@@ -3020,36 +3026,6 @@
This section introduces further elements of PROV-DM.
-<section id="term-NamespaceDeclaration">
-<h3>Namespace Declaration</h3>
-
-<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI [[!IRI]]. In PROV-DM, attributes, identifiers, and values with <a title="qualified name">qualified names</a> as data type can be placed in a namespace using the mechanisms described in this specification. </p>
-
-
-<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
-declaration refers to this namespace. </p>
-
-<p>A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every un-prefixed qualified name
-refers to default namespace declaration.</p>
-
-<p>The <dfn title="prov-namespace">PROV namespace</dfn> is identified by the URI <a href="http://www.w3.org/ns/prov#">http://www.w3.org/ns/prov#</a>.</p>
-
-</section>
-
-<section id="term-qualified-name">
-<h4>Qualified Name</h4>
-
-
-<span class="glossary-ref" data-ref="glossary-qualifiedName"></span>
-
-<p>PROV-DM stipulates that a qualified name can be mapped into an IRI
- by concatenating the IRI associated with the prefix and the local part.</p>
-
-<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
- qualified name, it refers to a <a>namespace</a> declared in a namespace declaration. In the absence of prefix, the qualified name
- refers to the <a title="default namespace declaration">default namespace</a>.</p>
-
-</section>
@@ -3353,6 +3329,38 @@
We need to check that we are including all xsd types that are the latest versions of XML Schema/RDF.
</div>
</section>
+
+<section id="term-NamespaceDeclaration">
+<h3>Namespace Declaration</h3>
+
+<p>A PROV-DM <dfn id="dfn-namespace">namespace</dfn> is identified by an IRI [[!IRI]]. In PROV-DM, attributes, identifiers, and values with <a title="qualified name">qualified names</a> as data type can be placed in a namespace using the mechanisms described in this specification. </p>
+
+
+<p>A <dfn id="dfn-namespaceDeclaration">namespace declaration</dfn> consists of a binding between a prefix and a namespace. Every qualified name with this prefix in the scope of this
+declaration refers to this namespace. </p>
+
+<p>A <dfn id="dfn-defaultNamespaceDeclaration">default namespace declaration</dfn> consists of a namespace. Every un-prefixed qualified name
+refers to default namespace declaration.</p>
+
+<p>The <dfn title="prov-namespace">PROV namespace</dfn> is identified by the URI <a href="http://www.w3.org/ns/prov#">http://www.w3.org/ns/prov#</a>.</p>
+
+</section>
+
+<section id="term-qualified-name">
+<h4>Qualified Name</h4>
+
+
+<span class="glossary-ref" data-ref="glossary-qualifiedName"></span>
+
+<p>PROV-DM stipulates that a qualified name can be mapped into an IRI
+ by concatenating the IRI associated with the prefix and the local part.</p>
+
+<p>A qualified name's prefix is OPTIONAL. If a prefix occurs in a
+ qualified name, it refers to a <a>namespace</a> declared in a namespace declaration. In the absence of prefix, the qualified name
+ refers to the <a title="default namespace declaration">default namespace</a>.</p>
+
+</section>
+
</section>