remove archaic things new_cert_ont
authorDominik Tomaszuk <ddooss@wp.pl>
Sat, 23 Mar 2013 12:00:45 +0100
branchnew_cert_ont
changeset 354 3d93f052fea4
parent 353 53fdf21299ef
child 355 a9b71ecfe16b
remove archaic things
ontologies/cert.n3
--- a/ontologies/cert.n3	Fri Mar 22 23:47:11 2013 +0100
+++ b/ontologies/cert.n3	Sat Mar 23 12:00:45 2013 +0100
@@ -19,7 +19,6 @@
    rdfs:label "Ontology for Certificates and crypto stuff.";
    rdfs:seeAlso <http://lists.foaf-project.org/mailman/listinfo/foaf-protocols>;
    rdfs:seeAlso <X509Uml.svg>;
-   rdfs:seeAlso <rsa>;
    rdfs:comment """
    Ontology for Certificates and crypto stuff.
    This is in development. 
@@ -93,76 +92,15 @@
    rdfs:label "PrivateKey";
    rdfs:comment "Private Key"@en ;
    rdfs:isDefinedBy <cert#>;
-   rdfs:subClassOf :Key .
-
-# badly named, removing
-#:public_key a rdf:Property;
-#    vs:term_status "unstable";
-#    rdfs:comment """
-#    relates the private key to the public key component, in a public/private
-#    key pair.
-#    """;
-#    rdfs:domain :PrivateKey;
-#    rdfs:range :PublicKey .  
+   rdfs:subClassOf :Key . 
 
-:hex a rdfs:Datatype;
-   rdfs:label "hexadecimal"@en;  
-   rdfs:isDefinedBy <cert#>;
-   rdfs:seeAlso <http://en.wikipedia.org/wiki/Hexadecimal>;
-   owl:equivalentClass xsd:nonNegativeInteger;
-   skos:editorialNote """<span xmlns="http://www.w3.org/1999/xhtml"><p> 
-     This relation should slowly be transited to just being a datatype.</p>
-     <p>Being a datatype and a property is legal as explained here
-  <a href="http://lists.w3.org/Archives/Public/semantic-web/2010Mar/0037.html">on the semantic web mailing list in March 2010</a>. 
- But it may be somewhat confusing, especially if it goes against a pattern - still to be set - by the xsd datatypes as the follow up email makes clear. </p></span>
-   """@en;
-   rdfs:comment """<span xmlns="http://www.w3.org/1999/xhtml"><p>
-   An encoding of a positive integer (from 0 to infinity) as a hexadecimal string that makes it easy to read and/or fun to present on the web.</p>
-   <p>The purpose of this way of representing hexadecimals is to enable users to copy and paste hexadecimal notations as shown by most browsers, keychains or tools such as opensso, into their rdf representation of choice.  There are a wide variety of ways in which such strings can be presented. One finds the following:</p>
-<pre>
-  e1 dc d5 e1 00 8f 21 5e d5 cc 7c 7e c4 9c ad 86 
-  64 aa dc 29 f2 8d d9 56 7f 31 b6 bd 1b fd b8 ee 
-  51 0d 3c 84 59 a2 45 d2 13 59 2a 14 82 1a 0f 6e 
-  d3 d1 4a 2d a9 4c 7e db 90 07 fc f1 8d a3 8e 38 
-  25 21 0a 32 c1 95 31 3c ba 56 cc 17 45 87 e1 eb 
-  fd 9f 0f 82 16 67 9f 67 fa 91 e4 0d 55 4e 52 c0 
-  66 64 2f fe 98 8f ae f8 96 21 5e ea 38 9e 5c 4f 
-  27 e2 48 ca ca f2 90 23 ad 99 4b cc 38 32 6d bf  
-</pre>
-<p>
- Or the same as the above, with ':' instead of spaces. We can't guarantee that these are the only ways such tools will present hexadecimals, so we are very lax.</p>
- <p>The letters can be uppercase or lowercase, or mixed.  </p>
- <p>Some strings may start with initial 00's, and can be stripped in this notation as they often are. Doing this could, in complement of 2 notation turn a positive number into a negative one, if the first hexadecimal character happens to be one of  the set {'8', '9', 'a', 'A', 'b', 'B', 'c', 'C', 'd', 'D', 'e', 'E', 'f', 'F'} .  As we interpret this string as a hexadecimal number leading 00s are not important  (Complement of 2 notation and hexadecimal overlap for positive numbers)</p>
-<p> In order to make this fun, we allow any unicode characters in the string. A parser should </p>
-  <ol>
-<li>remove all non hexadecimal characters</li>
-<li>treat the resulting as a hexadecimal representation of a number</li>
-</ol>
-<p>
- This will allow people to make an ascii - better yet a UTF-8 - picture of their public key when publishing it on the web.
-</p>
-<p>
-  Cert hex is also a datatype property because we used to write it out like this
-</p>
- <pre>
-   [] a rsa:RSAPublicKey;
-     rsa:public_exponent [ cert:hex "e1 dc d5 ..."] 
- </pre> 
-<p> The above notation is now deprecated. Now we prefer the literal format below.</p>
- <pre>
-   [] a rsa:RSAPublicKey;
-     rsa:public_exponent "e1 dc d5 ..."^^cert:hex .
- </pre> 
-   </span>"""^^rdf:XMLLiteral;
-  vs:term_status "archaic" .
-
-:identity a rdf:Property, owl:ObjectProperty;
+:identity a owl:ObjectProperty;
     vs:term_status "archaic";
     rdfs:label "identity"@en;
     rdfs:isDefinedBy <cert#>;
     skos:editorialNote """
-         It turns out that this relation is unintuitive to write out and to name.
-         One should instead use cert:key
+    It turns out that this relation is unintuitive to write out and to name.
+    One should instead use cert:key
     """@en;
     rdfs:comment """
     the identity of the public key. This is the entity that knows the private key and 
@@ -172,10 +110,10 @@
     owl:inverseOf :key;
     rdfs:domain :PublicKey .
 
-:key a rdf:Property, owl:ObjectProperty, owl:InverseFunctionalProperty;
+:key a owl:InverseFunctionalProperty;
     vs:term_status "unstable";
     rdfs:label "key"@en; 
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     owl:inverseOf :identity;
     rdfs:comment """relates an agent to a key - most often the public key."""@en ;
     rdfs:domain foaf:Agent;
@@ -183,7 +121,7 @@
 
 :RSAKey a owl:Class;
     rdfs:label "RSA Key"@en;
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     rdfs:subClassOf :Key;
     vs:term_status "unstable";
     rdfs:comment """
@@ -193,7 +131,7 @@
 
 :DSAKey a owl:Class;
     rdfs:label "DSA Key"@en;
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     rdfs:subClassOf :Key;
     vs:term_status "unstable";
     rdfs:comment """
@@ -203,7 +141,7 @@
      
 :RSAPublicKey a owl:Class;
     rdfs:label "RSA Public Key"@en;
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     rdfs:subClassOf :PublicKey, :RSAKey;
     vs:term_status "unstable";
     rdfs:seeAlso <http://en.wikipedia.org/wiki/RSA_%28algorithm%29>;
@@ -214,7 +152,7 @@
 
 :RSAPrivateKey a owl:Class;
     rdfs:label "RSA Private Key"@en;
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     rdfs:subClassOf :PrivateKey, :RSAKey;
     vs:term_status "unstable";
     rdfs:seeAlso <http://en.wikipedia.org/wiki/RSA_%28algorithm%29>;
@@ -224,7 +162,7 @@
 
 :DSAPublicKey a owl:Class;
     rdfs:label "DSA Public Key"@en;
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     rdfs:subClassOf :PublicKey, :DSAKey;
     vs:term_status "unstable";
     rdfs:seeAlso <http://en.wikipedia.org/wiki/Digital_Signature_Algorithm>;
@@ -234,7 +172,7 @@
 
 :DSAPrivateKey a owl:Class;
     rdfs:label "DSA Private Key"@en;
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     rdfs:subClassOf :PrivateKey, :DSAKey;
     vs:term_status "unstable";
     rdfs:seeAlso <http://en.wikipedia.org/wiki/Digital_Signature_Algorithm>;
@@ -257,7 +195,7 @@
   </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>
-   """@en;
+   """^^rdf:HTML;
    rdfs:domain :RSAKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
 
@@ -266,21 +204,21 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-       The exponent used to encrypt the message. Number chosen between
-       1 and the totient(p*q). Often named 'e' .
+   The exponent used to encrypt the message. Number chosen between
+   1 and the totient(p*q). Often named 'e' .
     """@en;
    rdfs:domain :RSAPublicKey;
    rdfs:range xsd:nonNegativeInteger .
 
 :privateExponent a owl:DatatypeProperty ;
     rdfs:label "private"@en;
-	rdfs:isDefinedBy <cert#>;
+    rdfs:isDefinedBy <cert#>;
     vs:term_status "unstable";
     rdfs:comment """
-       The exponent used to decrypt the message
-       calculated as 
+    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'
+    The private exponent is often named 'd'
     """@en;
    rdfs:domain :RSAPrivateKey;
    rdfs:range xsd:nonNegativeInteger .
@@ -291,7 +229,7 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-a prime modulus meeting the Digital Signature Standard requirements
+   a prime modulus meeting the Digital Signature Standard requirements
     """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
@@ -301,7 +239,7 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-an integer in the range 2**159 < q < 2**160
+   an integer in the range 2**159 < q < 2**160
     """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
@@ -311,7 +249,7 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-an integer with certain properties with respect to P and Q
+   an integer with certain properties with respect to P and Q
     """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
@@ -321,7 +259,7 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-G**X mod P
+   G**X mod P
     """@en;
    rdfs:domain :DSAPublicKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .
@@ -331,7 +269,7 @@
    rdfs:isDefinedBy <cert#>;
    vs:term_status "unstable";
    rdfs:comment """
-part of the private key
+   part of the private key
     """@en;
    rdfs:domain :DSAPrivateKey;
    rdfs:range xsd:hexBinary, xsd:base64Binary .