--- a/rdf-spaces/index.html	Mon May 14 19:26:19 2012 +0100
+++ b/rdf-spaces/index.html	Mon May 14 17:30:40 2012 -0400
@@ -121,6 +121,9 @@
     .separated tbody tr td.r { text-align: right; padding: .5em; }
     .grammar td { font-family: monospace;}
     .grammar-literal { color: gray;}
+    
+    .example-def { border:1px solid black; padding: 1em; }
+
     </style> 
 	
   </head>
@@ -375,8 +378,8 @@
     difference between <em>Transaction Time</em> and <em>Valid
     Time</em> in bitemporal databases.  After Division 5's move, the
     "old" phone numbers are not just the old state of the database;
-    they are the old state of the world.  It is possible that some time
-    after the move an error in some of the pre-move data might be
+    they reflect the old state of the world.  It is possible that some
+    time after the move an error in the pre-move data might 
     need to be corrected, giving it a new transaction time, even
     though its valid time range has already ended.</p>
 
@@ -385,6 +388,8 @@
     for RDF Triples</a>, Jeni Tennison's report of attempting to solve
     this problem in UK Government data.</p>
 
+    <p>Use case sighting: <a href="http://lists.w3.org/Archives/Public/public-rdf-wg/2012May/0099.html">Vocab terms for owner, validFrom and validUntil</a>, Manu Sporny's reports PaySwarm wants to record ownership information for particular time ranges.</p>
+
     <p>For a discussion of how this use case could be addressed, see
     <a href="#example-validtime" class="sectionRef"></a></p>
 
@@ -1048,13 +1053,8 @@
   case having an example here.</p>
 
   <div class="alert">
-    <p>@@@ Most of this "Detailed Example" section is
-  older and needs re-writing to be synchronized with changes made in
-  the Use Cases.</p>
-  
-  <p>
-  See the <a
-  href="http://dvcs.w3.org/hg/rdf/raw-file/ee60c6dc8ad4/rdf-spaces/index.html#">May 10 Version</a> for a now-obsolete run-through of the example.
+    <p>@@@ An obsolete but complete version was in the <a
+  href="http://dvcs.w3.org/hg/rdf/raw-file/ee60c6dc8ad4/rdf-spaces/index.html#">May 10 Version</a>.
   </p>
   </div>
 
@@ -1121,7 +1121,70 @@
   <section id="example-validtime">
     <h2>Showing Past and Future States (v7)</h2>
 
-    <p>@@@ Shows how to address <a href="#uc-validtime" class="sectionRef"></a></p>
+
+    <p>The challenge expressed in <a href="#uc-validtime"
+    class="sectionRef"></a> is to segregate some of the triples,
+    marking them as being in-effect only at certain times.  The study
+    of how to do this is part of the field of temporal databases.</p>
+
+    <p>In this example, we handle this by defining the following vocabulary:</p>
+
+    <div class="example-def">
+      
+      <p>This "valid-time" vocabulary allows a data publisher to
+      express a time range during which the triples in some space are
+      considered valid.  This acts like a time-dependent version of
+      owl:import, where the import is only made during the given time
+      range.</p>
+
+      <dl>
+	<dt>(rdf:space Sp) vt:starts (xs:dateTime T1)</dt>
+	<dd>Claims that all the triples in Sp are valid starting at T1, ending at some unspecified period of time.</dd>
+	<dt>(rdf:space Sp) vt:end (xs:dateTime T2)</dt>
+	<dd>Claims that all the triples in Sp are valid until just before T2, starting at some unspecified time.</dd>
+      </dl>
+
+      <p>In general, these two predicates should be used together,
+      providing both vt:starts and vt:ends values for a space.  In
+      this case, { ?sp vt:starts ?t1; vt:ends ?t2 } claims that all
+      the triples in ?sp are in effect for all points in time t such
+      that t1 &lt;= t &lt; t2.  A consumer who only knows one of the
+      two times is unable to make use of data; there are no
+      default values.</p>
+
+      <p>These predicates say nothing about the validity (or "truth") of
+      the triples in Sp outside of the valid-time range.  Each of the
+      triples might or might not hold outside of the range &mdash;
+      these vt triples simply make no claim about them.</p>
+
+    </div>
+
+    <p>Given this definition, it is almost trivial for Division 5 to share their "before" and "after phonebooks:</p>
+
+    <pre class="example">@prefix vt: &lt;http://example.org/ns/valid-time>.
+@prefix hq: &lt;http://example.org/ns/phonebook>.
+@prefix : &lt;>.
+
+:pre-move {  
+    # all the pre-move data  
+    ...
+}
+:post-move {
+    # all the post-move data  
+    ...
+}
+
+:pre-move  vt:starts "2010-01-01T00:00:00"^^xs:dateTime;
+           vt:ends   "2012-07-12T00:00:00"^^xs:dateTime.
+:post-move vt:starts "2012-07-12T00:00:00"^^xs:dateTime;
+           vt:ends   "2020-01-01T00:00:00"^^xs:dateTime.
+
+</pre>
+
+     <p>This design requires every client to be modified to understand
+     and use the valid-time vocabulary.  There may be designs that do
+     not require this.</p>
+
 
   </section>