--- a/rdf-spaces/index.html	Thu May 10 07:08:31 2012 -0400
+++ b/rdf-spaces/index.html	Thu May 10 08:05:37 2012 -0400
@@ -125,13 +125,13 @@
 
     <p>The <a href="http://www.w3.org/TR/rdf11-concepts/">Resource
     Description Framework (RDF)</a> provides a simple declarative way
-    to store and transmit information.  It provides a trivial but
+    to store and transmit information.  It alos provides a trivial but
     effective way to combine information from multiple sources, with
     graph merging.  This allows information from different people,
     different organizations, different units within an organization,
-    different servers, different algorithms, etc, to all combined and
-    used together, without any special processing or understanding of
-    the relationships among the providers.</p>
+    different servers, different algorithms, etc, to all be combined
+    and used together, without any special processing or understanding
+    of the relationships among the providers.</p>
 
     <p>The basic RDF merge operation may be overly simplistic, though,
     as extra processing and an understanding of the relationships
@@ -140,17 +140,132 @@
     by modeling each one as a separate <em>space</em>, and using RDF to
     express information about these spaces.  In addition to this
     important concept, we provide a pair of languages&mdash;extensions
-    to exsiting RDF syntaxes&mdash; which can be used to store or
+    to existing RDF syntaxes&mdash; which can be used to store or
     transmit in one document the contents of multiple spaces as well
     as information about them.
 
-    <p>This approach allows for a variety of <a href="#use-cases">use
-    cases</a> to be addressed in a straightforward manner, as shown
-    in <a href="deailed-example" class="sectionRef"></a>.</p>
+    <p>This approach allows for a variety of use cases (immediately
+    below) to be addressed in a straightforward manner, as shown in <a
+    href="#detailed-example" class="sectionRef"></a>.</p>
 
 </section>
 
 <section>
+  <h2>Use Cases</h2>
+
+  <p>Each of these use cases is initally described in terms of the
+  following scenario.  Details of how each use case is handled by the
+  <em>RDF spaces</em> design are in <a href="#detailed-example"
+  class="sectionRef"></a>.</p>
+
+  <blockquote style="font-style: italic">
+
+    <p>The Example Foundation is a large organization with more than
+    ten thousand employees and volunteers, spread out over five
+    continents.  It has branches in 25 different countries, and those
+    divisions have considerable autonomy; they are only loosely
+    controlled by the parent organization (called "headquarters" or
+    "HQ") in Geneva.</p>
+
+    <p>HQ wants to help the divisions work together better, and
+    decides a first step is to provide a simple but complete directory
+    of all the Example personnel.  Until now, each division has
+    maintained its own directory, using its own technology.  HQ would
+    like to be able to find someone's phone number, mailing address,
+    and job title, knowing only their name or email addresses.  Later,
+    they hope to extend the system to allow finding people based on
+    their areas of interest and expertise.</p>
+
+    <p>HQ decides to use RDF with the <a
+    href="http://www.w3.org/TR/vcard-rdf/">the vcard-rdf
+    vocabulary</a>.  They ask each division to put an up-to-date
+    directory somewhere on the Web, and mail carol@hq.example.org the
+    URL.  They say: "Just tell Carol the username/password if there is
+    one, or make it only available to the IP address of
+    dir.hq.example.org."  Carol maintains a file which lists the URLs
+    and any username/password combinations she is given.</p>
+
+  </blockquote>
+
+  <p>For the first iteration of the design of their directory, HQ
+  builds a "harvester" which uses Carol's file for input and fetches
+  all the listed data feeds.  It operates behind a caching Web proxy,
+  so that if the divisions set the right HTTP headers (eg Expires and
+  Last-Modified) the load on their servers is minimal, even if HQ runs
+  the harvester every few minutes.</p>
+
+  <p>The harvester parses the RDF from each data source and loads it
+  into an in-memory triplestore, merging each new graph.  Once it's
+  done with all the harvesting, the harvester writes out the merged
+  graph into a Turtle file.  The file is published (with access
+  control) where it can be used by several different clients providing
+  directory search services.</p>
+
+  <p>Although HQ provides a Web-based client, they makes the raw
+  merged data available, because the divisions have programmers and HQ
+  knows people will want mobile clients, SMS-based clients,
+  command-line clients on different operating systems, and possibly
+  even clients that do something more sophisticated than just looking
+  up a phone numer.  By making the raw data available, they empower
+  the divisions to supply all these other applications.</p>
+
+  <section>
+    <h2>Minimizing Reloads</h2>
+    
+    <p>@@@ just change the parts that changed, allowing for very cheap updates </p>
+  </section>
+
+  <section>
+    <h2>Showing Provenance</h2>
+
+    <p>@@@ the released db shows which dept supplies each part of the information </p>
+  </section>
+
+  <section>
+    <h2>Maintaining Derived Data</h2>
+
+    <p>@@@ namefill is needed, and its results need their own provenance</p>
+  </section>
+
+
+  <section>
+    <h2>Distributed Harvesting</h2>
+
+    <p>@@@ divisions gather from departments who might gather from
+    individuals </p>
+
+  </section>
+
+
+  <section>
+    <h2>Showing Revision History</h2>
+
+    <p>@@@ we want to be able to see all the changes, for auditing, to
+    see what the DB said about anyone at any point in time.
+    (transaction time)</p>
+  </section>
+
+
+  <section>
+    <h2>Expressing Past of Future States</h2>
+
+    <p>@@@ we want to be able to express when someone started and stopped having a particular role various ways, which might not be the time we put this into the db.
+ </p>
+  </section>
+
+
+  <section>
+    <h2>Vendor-Neutral SPARQL Backup</h2>
+
+    <p>@@@ we want to be able to dump the database and load it in a different system</p>
+  </section>
+
+
+</section>
+
+
+
+<section>
   <h2>Concepts</h2>
 
   <section>
@@ -349,14 +464,6 @@
 
 </section>
 
-<section>
-  <h2>Use Cases</h2>
-
-  <p>TBD.  See <a href="#detailed-example" class="sectionRef"></a> for now.</p>
-
-</section>
-
-
 <section id="syntax">
   <h2>Dataset Languages</h2>
 
@@ -468,6 +575,9 @@
 <section class="informative">
   <h2>Detailed Example</h2>
 
+  <p>@@@ this needs to be updated to just show the results of the
+  problems described in the Use Cases section.</p>
+
   <p>This section presents a design for using spaces in constructing a
   federated information system.  It is intended to help explain and
   motivate RDF <a>data space</a>s.</p>