--- a/ontologies/cert.n3	Sat Mar 23 12:00:45 2013 +0100
+++ b/ontologies/cert.n3	Sat Mar 23 12:17:07 2013 +0100
@@ -16,7 +16,7 @@
    dc:created "2008-11-13"^^xsd:date;
    foaf:maker <http://bblfish.net/people/henry/card#me>;
    vs:term_status "unstable";
-   rdfs:label "Ontology for Certificates and crypto stuff.";
+   rdfs:label "Ontology for Certificates and crypto stuff."@en;
    rdfs:seeAlso <http://lists.foaf-project.org/mailman/listinfo/foaf-protocols>;
    rdfs:seeAlso <X509Uml.svg>;
    rdfs:comment """
@@ -35,7 +35,6 @@
           public key
      *
    Todo: 
-     - should this all be in one file? Or should this be cut up a little? Say one file for the general CERT ontology, and then files for RSA, DSA, PGP, etc... Or perhaps it does not really matter?
      - expand more on the certification side of things
      - verify this by security experts
      - owl2 has some constructs for combined inverse functional properties. 
@@ -188,13 +187,13 @@
    <p>The modulus of an RSA public and private key. 
    Or the modulus of a DSA Key.
    The modulus is encoded as a hex binary. The binary is the same as the one encoded in the 
-  <a href="http://www.w3.org/TR/xmldsig-core/#sec-CryptoBinary">XML DSIG CryptoBinary</a>
-  </p>
-  <blockquote>
+   <a href="http://www.w3.org/TR/xmldsig-core/#sec-CryptoBinary">XML DSIG CryptoBinary</a>
+   </p>
+   <blockquote>
    This specification defines the ds:CryptoBinary simple type for representing arbitrary-length integers (e.g. "bignums") in XML as octet strings. The integer value is first converted to a "big endian" bitstring. The bitstring is then padded with leading zero bits so that the total number of bits == 0 mod 8 (so that there are an integral number of octets). If the bitstring contains entire leading octets that are zero, these are removed (so the high-order octet is always non-zero).
-  </blockquote>
- <p>The only difference is that the octet string is then encoded using either xsd:base64Binary or xsd:hexBinary. Currently for all usages of this relation, the xsd:hexBinary datatype should be used until the SPARQL working group specifies specifies in its <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">D-Entailment</a> that those two types are equivalent.</p>
- <p>It would have been better had there been a hexInteger datatype that was standard and supported by all tools.</p>
+   </blockquote>
+   <p>The only difference is that the octet string is then encoded using either xsd:base64Binary or xsd:hexBinary. Currently for all usages of this relation, the xsd:hexBinary datatype should be used until the SPARQL working group specifies specifies in its <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">D-Entailment</a> that those two types are equivalent.</p>
+   <p>It would have been better had there been a hexInteger datatype that was standard and supported by all tools.</p>
    """^^rdf:HTML;
    rdfs:domain :RSAKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
@@ -206,20 +205,20 @@
    rdfs:comment """
    The exponent used to encrypt the message. Number chosen between
    1 and the totient(p*q). Often named 'e' .
-    """@en;
+   """@en;
    rdfs:domain :RSAPublicKey;
    rdfs:range xsd:nonNegativeInteger .
 
 :privateExponent a owl:DatatypeProperty ;
-    rdfs:label "private"@en;
-    rdfs:isDefinedBy <cert#>;
-    vs:term_status "unstable";
-    rdfs:comment """
-    The exponent used to decrypt the message
-    calculated as 
-          public_exponent*private_exponent = 1 modulo totient(p*q)
-    The private exponent is often named 'd'
-    """@en;
+   rdfs:label "private"@en;
+   rdfs:isDefinedBy <cert#>;
+   vs:term_status "unstable";
+   rdfs:comment """
+   The exponent used to decrypt the message
+   calculated as 
+     public_exponent*private_exponent = 1 modulo totient(p*q)
+   The private exponent is often named 'd'
+   """@en;
    rdfs:domain :RSAPrivateKey;
    rdfs:range xsd:nonNegativeInteger .
 
@@ -230,7 +229,7 @@
    vs:term_status "unstable";
    rdfs:comment """
    a prime modulus meeting the Digital Signature Standard requirements
-    """@en;
+   """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
 
@@ -240,7 +239,7 @@
    vs:term_status "unstable";
    rdfs:comment """
    an integer in the range 2**159 < q < 2**160
-    """@en;
+   """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
 
@@ -249,8 +248,8 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-   an integer with certain properties with respect to P and Q
-    """@en;
+   an integer with certain properties with respect to p and q
+   """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
 
@@ -259,8 +258,8 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-   G**X mod P
-    """@en;
+   g**x mod p
+   """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
 
@@ -270,7 +269,7 @@
    vs:term_status "unstable";
    rdfs:comment """
    part of the private key
-    """@en;
+   """@en;
    rdfs:domain :DSAPrivateKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .