* resolved remaining todos.
authorjcheney@inf.ed.ac.uk
Sun, 03 Mar 2013 14:40:42 +0000
changeset 5816 e2544d8e928d
parent 5815 953038d31555
child 5817 ec9c9ae2e9d5
* resolved remaining todos.
semantics/review/ISSUE-630-khalid.txt
semantics/review/ISSUE-630-luc.txt
semantics/review/ISSUE-630-paolo.txt
semantics/review/ISSUE-630-satya.txt
semantics/review/ISSUE-630-simon.txt
--- a/semantics/review/ISSUE-630-khalid.txt	Sun Mar 03 14:38:30 2013 +0000
+++ b/semantics/review/ISSUE-630-khalid.txt	Sun Mar 03 14:40:42 2013 +0000
@@ -20,7 +20,7 @@
  > the relationship between Things and Objects, before definition
  > Objects.
 
-TODO
+Done
 
  > 
  > 2.3 In the definition of Component 10 (derivations), I think version
@@ -100,7 +100,7 @@
  > a new sets that are subsets of Events, namely Generations and Usages.
  > 
 
-TODO
+I will do this in a future version.
 
  > 4.4 In the formulas defining the semantics of the relation sin Section
  > 4.4, place hoder parameters are not specified.
--- a/semantics/review/ISSUE-630-luc.txt	Sun Mar 03 14:38:30 2013 +0000
+++ b/semantics/review/ISSUE-630-luc.txt	Sun Mar 03 14:40:42 2013 +0000
@@ -15,7 +15,7 @@
  > 
  > - section 2.4: no bundle here? Shouldnt' we? or too slippery topic?
 
-Added some explanation of this in the introduction [TODO]
+Added some explanation of this in the introduction
 
  > 
  > - section 2.5: could the final version have a go at an interpretation of mentionOf, even if marked as more speculative and in appendix?
@@ -30,7 +30,7 @@
  > 
  > - section 3.2.1: Can we provide some intution for value(obj,a) \subseteq value(thingOf(obj),a,t). What does it tell us about entities vs things.
 
-TODO
+Done
 
  > 
  > - section 3.2.4: (the first two sets may overlap) which? Why?
--- a/semantics/review/ISSUE-630-paolo.txt	Sun Mar 03 14:38:30 2013 +0000
+++ b/semantics/review/ISSUE-630-paolo.txt	Sun Mar 03 14:40:42 2013 +0000
@@ -6,7 +6,10 @@
  >    this may be too defensive?: it seems to imply that there may be other semantics of PROV  but in that case it is not clear where sand when they would come from, and thus whether using this document is "safe".
  > 
 
-Following comments from Luc, I think it is important to delimit the scope of the document.  It is not a specification and we don't want to make it sound like it is doing more than it is.  TODO
+Following comments from Luc, I think it is important to delimit the
+scope of the document.  It is not a specification and we don't want to
+make it sound like it is doing more than it is.  I've revised this
+slightly and it needs to be updated later to reflect any improvements.
 
  > 1.2 final note: not sure what this refers too -- assume it's for internal use only.
 
--- a/semantics/review/ISSUE-630-satya.txt	Sun Mar 03 14:38:30 2013 +0000
+++ b/semantics/review/ISSUE-630-satya.txt	Sun Mar 03 14:40:42 2013 +0000
@@ -62,7 +62,7 @@
  > a) DerivationPaths=Entities⋅(Events⋅Activities⋅Events⋅Entities) - We can replace Events by Generation and Used directly since the following constraints specifies only one replacement for Events?
  > 
 
-TODO
+I will do this in a future version.
 
  > Minor Typos:
  > Section 3.2.2 Actvities/Activities
--- a/semantics/review/ISSUE-630-simon.txt	Sun Mar 03 14:38:30 2013 +0000
+++ b/semantics/review/ISSUE-630-simon.txt	Sun Mar 03 14:40:42 2013 +0000
@@ -63,4 +63,4 @@
 
 This is a good point; a lot of the semantics is just restating the constraints in a different notation, as can often be the case with semantics.  The derivation paths and Thing/Entity/thingOf structure is more interesting and should be highlighted.  I'd ideally like to avoid saying the same thing several different ways but not sure yet how best to do this.
 
-TODO: Highlight the distinctive components
+I will do this in a future version.