le merge
authorStian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>
Mon, 16 Apr 2012 14:40:54 +0100
changeset 2322 663f227c4436
parent 2321 483dbeb1aa07 (current diff)
parent 2320 1a7d883e143e (diff)
child 2323 2f8394853124
child 2413 a260dac6c5d4
le merge
--- a/bestpractices/BestPractices.html	Mon Apr 16 14:40:37 2012 +0100
+++ b/bestpractices/BestPractices.html	Mon Apr 16 14:40:54 2012 +0100
@@ -1122,6 +1122,42 @@
         </section>
 	  </section>	    			
 	</section>
+
+   <section>
+      <h2>Using strings</h2>
+      Issues <a href="http://www.w3.org/2011/prov/track/issues/248">248</a> and <a href="http://www.w3.org/2011/prov/track/issues/222">222</a>.
+      prov:used is defined as an objectproperty. If the parameter to a program is a string, and we want to say that the invocation used the string, how do we model that?
+
+      This is only a concern if you want to be DL compliant. If you don't care about being DL compliant, then just do it.
+      Another concern is that tools will expect a resource instead of a string and will not handle it correctly.
+
+      <a href="http://www.w3.org/TR/Content-in-RDF10/">Content in RDF</a> can be used to model string values while maintaining the datatype/objectproperty distinction and complying with PROV-O.
+      Also,  resource can use the rdf:value property to store the string value. We recommend NOT using a blank node, but to derive the URI from the string itself (using a hash) or just a UUID.
+      Note that altough the "extra resource" may appear to be an undesirable level of indirection, it allows for the arbitrary contextualization that is central to PROV. When describing this strings provenance, we're not talking about that string as it appears anywhere, but as it appeared to the activty using it at the time we're describing.
+   
+   <pre>
+@prefix cnt: &lt;http://www.w3.org/2008/content#&gt; .
+
+:activity a prov:Activity;
+ prov:used [ # dont' use a blank node!
+ a prov:Entity, cnt:ContentAsText ;
+ cnt:chars "The magic string" ;
+]  .
+
+:activity a prov:Activity;
+ prov:used :theMagicString .
+
+:magicString
+ a prov:Entity, cnt:ContentAsText ;
+ cnt:chars "The magic string" .
+</pre>
+
+
+(there's also cnt:ContentAsBase64 and cnt:bytes for verbose binaries,
+and cnt:ContentAsXML for literal XMLs)
+
+   </section>
+
     <section class='appendix'>
       <h2>Acknowledgements</h2>
       <p>
--- a/model/comments/issue-331-Cheney.txt	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/comments/issue-331-Cheney.txt	Mon Apr 16 14:40:54 2012 +0100
@@ -186,8 +186,7 @@
   > multiple occurrences of attribute names, why stop with these two?
   > 
 
-TODO
-We could  allow this for prov:label and prov:location too.
+TODO: We could  allow prov:label and prov:location to have multiple occurrences?
 Does this make sense for prov:location?
 
   > 
--- a/model/comments/issue-331-Jun.txt	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/comments/issue-331-Jun.txt	Mon Apr 16 14:40:54 2012 +0100
@@ -121,8 +121,7 @@
   > rest of the document.
   > 
 
-TODO
-Delegation?
+TODO: Action on Jun to suggest alternatives
 
   > 
   > 
@@ -227,7 +226,7 @@
 Effect first, cause second. 
 That's the order that is followed consistently in the document.
 
-TODO: should we consider renaming?
+TODO: should we consider renaming memberOf to fit subject first, object second?
 
 
   > 
@@ -257,7 +256,7 @@
 Good point. Don't know how to address it. We can also drop this paragraph
 from the main DM and leave this to part 2. It would consistent with the rest.
 
-TODO
+TODO: mutability of collections
 
   > 
   > 
@@ -269,8 +268,8 @@
   > Entities seems to be the only relationship that is not specified in the 
   > components sections. Is this on purpose?
 
-I don't understand. Can you clarify?
-TODO
+TODO: Jun: I don't understand. Can you clarify?
+
 
   > 
   > 
@@ -302,7 +301,7 @@
   > as constraint that structurally well-formed descriptions are expected to 
   > satisfy." What does it trying to say?
 
-TODO
+TODO: To update once PROV-DM-CONSTRAINTS becomes more stable
 
   > 
   > "blundling up" -> bundling up?
--- a/model/comments/issue-331-Khalid.txt	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/comments/issue-331-Khalid.txt	Mon Apr 16 14:40:54 2012 +0100
@@ -55,7 +55,7 @@
   > whenever they are used in the text. - The figure given at the end of
   > Sectio 3.1 can be more helpful in guiding the reader if it placed
 
-TODO
+Examples was trimmed down, and reorganized.  Thoughts?
 
 
   > earlier in that section. - Talkiing about the figure the fact there
--- a/model/comments/issue-331-Satya.txt	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/comments/issue-331-Satya.txt	Mon Apr 16 14:40:54 2012 +0100
@@ -46,7 +46,11 @@
    > distinct entities or they can only be generated by a single activity
 (as I believe is stated in constraints).
 
-TODO: check the text. It's a single document/resource.
+Text was updated.
+
+In both cases, we are dealing with a document.  It's the same resource,
+but we describe it differently.  In the first case, it is edited by edit1,
+in the second, it is published by act2.
 
 
 Section4:
@@ -171,7 +175,7 @@
    > states that "subtypes of derivations Revision, Quotation, Original
    > Source, and Traceability" - so what is subtype of what?
 
-TODO: to check with new defintion of agent!!!
+TODO: to check what traceability becomes with new defintion of agent!!!
 
    > 
    > Section 4.4:
--- a/model/comments/issue-331-Tim.txt	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/comments/issue-331-Tim.txt	Mon Apr 16 14:40:54 2012 +0100
@@ -517,7 +517,7 @@
   > and the paragraph. Perhaps a simple diagram would help follow. (but then this would be inconsistent with other definitions…)
   > 
 
-TODO
+TODO: ??? add a picture?
 
   > 
   > 
@@ -806,8 +806,8 @@
   >     association, start, and end"
   > 
 
-??? 
-TODO. I don't understand: linking what to what?
+
+TODO. Tim: I don't understand: linking what to what?
   > 
   > 
   > 
--- a/model/comments/issue-331-curt.txt	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/comments/issue-331-curt.txt	Mon Apr 16 14:40:54 2012 +0100
@@ -219,7 +219,7 @@
   >    data structures such as a maps, dictionaries, or associative arrays."?
   > 
 
-TODO.
+TODO: need a sentence on generality of the collection structure.
 
   > 
   > 2.5 Simplified Overview Diagram
--- a/model/comments/issue-331-graham.txt	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/comments/issue-331-graham.txt	Mon Apr 16 14:40:54 2012 +0100
@@ -345,7 +345,7 @@
   > I think accounts should have a section of their own, since they underpin the key
   > feature of supporting provenance0-of-provenance.
 
-TODO: To be addressed later. 
+TODO: To be addressed later: account.
 
   > 
   > However, I have a problem with the description "An account is an entity that
@@ -378,7 +378,7 @@
   > sense of this, so it's hard for me to suggest alternatives.
   > 
 
-TODO
+TODO: last teleconference ask Graham to raise issue and make suggestions
 
 Does renaming the relation "Responsibility/actedOnBehalfOf" help?
 And also remove the word accountable?
@@ -543,8 +543,7 @@
   > "A derivation is a transformation of an entity into another, a construction of
   > an entity *from* another, or an update of an entity, resulting in a new one."
 
-TODO
-yes, to look into. It would be nice to keep the same directionality for all of them.
+TODO: yes, to look into. It would be nice to keep the same directionality for all of them.
 
 
   > 
@@ -624,9 +623,9 @@
   > I think this section is completely redundant and out-of-place, and could be
   > removed without any loss.
 
-I think there is some value in stating there is an other document to
+TODO: I think there is some value in stating there is an other document to
 look at, and outline what it tackles.
-TODO?
+
 
 
   > 
--- a/model/prov-dm.html	Mon Apr 16 14:40:37 2012 +0100
+++ b/model/prov-dm.html	Mon Apr 16 14:40:54 2012 +0100
@@ -769,7 +769,7 @@
 
 
 
-<p>We paraphrase some PROV-DM descriptions, and illustrate them with the PROV-N notation.
+<p>We paraphrase some PROV-DM descriptions, express them with the PROV-N notation, and then depict them with a graphical illustration (see <a href="#prov-a-document1">Figure 1</a>).
 Full details of the provenance record can be found <a href="examples/w3c-publication3.pn">here</a>.</p>
 
 <ul>
@@ -821,7 +821,7 @@
 <div style="text-align: center; ">
   <figure>
   <img src="images/w3-publication3.png" alt="Provenance of a Document (1)" style="max-width: 98%; "/>
-<figcaption id="prov-a-document">Figure 2: Provenance of a Document (1)</figcaption>
+<figcaption id="prov-a-document1">Figure 2: Provenance of a Document (1)</figcaption>
   </figure>
 </div>
 
@@ -859,7 +859,7 @@
 </ul>
 
 <p>
-We now paraphrase some PROV descriptions, and illustrate them with the PROV-N notation.  We then follow them with a graphical illustration. Full details of the provenance record can be found <a href="examples/w3c-publication1.pn">here</a>.
+We now paraphrase some PROV descriptions, and express them with the PROV-N notation, and then depict them with a graphical illustration (see <a href="#prov-a-document2">Figure 2</a>). Full details of the provenance record can be found <a href="examples/w3c-publication1.pn">here</a>.
 
 <ul>
 <li>There was a document, a working draft on the recommendation track (<a href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsWD">process:RecsWD</a>), which is an entity so that we can describe its provenance. Similar descriptions exist for all entities.
@@ -908,7 +908,7 @@
 <div style="text-align: center;">
   <figure>
   <img src="images/w3-publication1.png" alt="Provenance of a Document (2)" style="max-width: 90%; "/>
-<figcaption>Figure 3: Provenance of a Document (2)</figcaption>
+<figcaption id="prov-a-document2">Figure 3: Provenance of a Document (2)</figcaption>
   </figure>
 </div>