[foaf-protocols] The case for massive simplification and foaf:key
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
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