--- a/spec/index-respec.html	Mon Dec 12 10:30:35 2011 -0500
+++ b/spec/index-respec.html	Mon Dec 12 10:57:12 2011 -0500
@@ -923,11 +923,11 @@
 </pre>
 <p>An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim is verified.</p>
 <p>In order to allow the class of queries defined by the template above to return true when asked of graphs where the hexBinary or the exponent contains whitespace characters in initial and final position, the query engine MUST support the D-entailment regime for <code>xsd:hexBinary</code> and <code>xsd:integer</code> as specified in <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">SPARQL 1.1 Entailment Regimes</a>.</p>
-<p>For verifiers that do not have access to a SPARQL query engine but that do have access programmatically to a triple store, it is relatively easy to emulate the above SPARQL query programmatically. There are a number of ways of doing this, some more efficient than others.<p>
+<p>For verifiers that do not have access to a SPARQL query engine but can query the RDF data programmatically, it is relatively easy to emulate the above SPARQL query programmatically. There are a number of ways of doing this, some more efficient than others.<p>
 </section>
 <section class="normative">
 <h2>Verifying the WebID claim without SPARQL</h2>
-<p>If the triple store does datatype normalisation of all literals before loading them, then the most efficient way to execute this would be to start by searching for all triples whose subjects have relation <code>cert:modulus</code> to the literal which in our example was <code>"cb24ed..."^^xsd:hexBinary</code>. One would then iterate through all the subjects of the relations that satisfied that condition, which would most likely never number more than one, and from there filter out all those that were the object of the <code>cert:modulus</code> relation of the <tref>WebID</tref> - in the example <code>bob:me</code>. Finally one would verify that one of the keys that had satisfied those relations also had the <code>cert:exponent</code> relation to the number which in the example above is <code>"65537"^^xsd:integer</code>.  
+<p>If the RDF library does datatype normalisation of all literals before loading them, then the most efficient way to execute this would be to start by searching for all triples whose subjects have relation <code>cert:modulus</code> to the literal which in our example was <code>"cb24ed..."^^xsd:hexBinary</code>. One would then iterate through all the subjects of the relations that satisfied that condition, which would most likely never number more than one, and from there filter out all those that were the object of the <code>cert:modulus</code> relation of the <tref>WebID</tref> - in the example <code>bob:me</code>. Finally one would verify that one of the keys that had satisfied those relations also had the <code>cert:exponent</code> relation to the number which in the example above is <code>"65537"^^xsd:integer</code>.  
 </p>
 <p>For triples stores that do not normalise literals on loading a graph, the normalization will need to be done after the query results and before matching those with the values from the <tref>Certificate</tref>. Because one could not rely on the modulus having been normalized, one would have to start with the <tref>WebID</tref> - <code>bob:me</code> and find all it's <code>cert:key</code> relations to objects - which we know to be keys - and then iterate through each of those keys' modulus and exponent, and verify if the normalised version of the value of those relation is equal to the numbers found in the certificate. If one such key is found then the answer is <code>true</code>, otherwise the answer will be <code>false</code>.</p>
 </section>