[foaf-protocols] The case for massive simplification and foaf:key

Nathan nathan at webr3.org
Tue Sep 21 17:45:40 CEST 2010

Henry Story wrote:
> Leaving aside the issue of the DER formatted public key for the moment,

Well this kind of leaves aside every issue discussed in this thread so 
far and changes the topic to adding and using a property which is the 
inverse of cert:identity.. however:

> as that still needs to be worked out in detail, I am in favour of
> adding that to the cert ontology
> cert:publicKey a rdf:Property;
>     rdfs:comment """
>        a relation from an agent to a public key for which he alone has 
>        the private key. This public key identifies that agent, allows him
>        to decrypt messages sent to him with that key, and is able to sign
>        messages with it too.
>     """;
>     rdfs:domain foaf:Agent;
>     rdfs:range cert:PublicKey .
> ( though I think the name can still be debated).

+1 for the cert ontology regardless, and is orthogonal to the previous 
discussion, any would be foaf:publicKey as discussed would have a range 
of xsd:base64Binary and the same domain.

Very much hope that an argument of "people may confuse foaf:publicKey 
with cert:publicKey" doesn't arise in the near future.

> I am also in favour of deprecating cert:identity, which to tell the truth
> I never that much liked. 

+1 although strictly doesn't need deprecated, all you're doing is naming 
the inverse.

Whilst this is quite different to everything discussed so far and 
hopefully we can continue on with that topic, it does make sense and 
seems a good move for the ontology.

Does a public and private key pair need a relation? could they have a 
KeyPair class which they are both linked to?



More information about the foaf-protocols mailing list