Re: Domain of :key

On 1 April 2013 22:06, Henry Story <henry.story@bblfish.net> wrote:

>
> On 1 Apr 2013, at 21:45, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
> > On 4/1/13 3:15 PM, Henry Story wrote:
> >> We can add new relations. Just let us know what you want. I am not sure
> why you want to merge two relations. You have not explained this yet, nor
> have you given a full use case.
> >>
> >> As far as X509 goes if you look at it it is relating a DN and its
> subject alternative names to a public key.
> >> If you think of that semantically that can be modelled as
> >>
> >> <> a X509Cert;
> >>    foaf:primaryTopic<ldap://DN=....>  ;
> >>  <ldap://DN=....>  owl:sameAs<https://my.domain.example/joe#me>;
> >>     cert:key [ a cert:RSAPublicKey;
> >>                cert:modulus "...";
> >>                cert:exponent "..." ] .
> >
> > Why not:
> >
> > <#dnReferentID>
> > <#hasKey> <#PublicKey> .
> > <#sanReferentID>
> > <#hasKey> <#PublicKey> .
> >
> > <#hasKey>
> > a owl:InverseFunctionalProperty, owl:ObjectProperty .
>
> If  <#hasKey> owl:sameAs cert:key, then what you wrote is equivalent
> to what I wrote above.
>
> Indeed the owl:InverseFunctionalProperty is essential, and it would not be
> true for a
> cert:signedWith relation that we should probably coin. Because hopefully
> you can sign
> more than one document with a key! The same would be true with a
> cert:encryptedWith relation,
> as one would like to encrypt any number of documents with the same key.
>
> Both something along the lines of a cert:signedWith and a
> cert:encryptedWith relatinon would
> be very useful to have in the cert ontology. But they are clearly not
> going to be equivalent
> to the cert:key relation ( or your <#hasKey> ).
>
> >
> > What's critical to WebID is the InverseFunctionalProperty relation
> semantics which help appreciate the optimal domain for <#hasKey> .
>
> yes. Agree.
>

There need be no IFP between the key of a certificate and the Agent that
uses/controls/uses that key.

I could think of a bunch of Agent robots sharing a high reputation
certificate.  Indeed, an server side SSL certificate can be used as auth
for many URLs at a given origin (ie domain) without those URLs being owl :
sameAs each other.

IFP *may* be related to webid, but it's not related to certs.  I think
there needs to be a round of looking at concepts modelled and coming up
with the right names at some point.

>
>
> >
> > Conclusion: we need to cater for the fact that public keys can (and
> will) be associated with all sorts of things (owl:Thing entity types) for a
> plethora of reasons. Thus, it's best veer away from generic terms (and
> resulting intuitions) when the usage purpose is very specific.
>
> yes. I am in favor of adding relations such as signedWith or encryptedWith
> to the ontology.
>
> Henry
>
> >
> >
> >
> > --
> >
> > Regards,
> >
> > Kingsley Idehen
> > Founder & CEO
> > OpenLink Software
> > Company Web: http://www.openlinksw.com
> > Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> > Twitter/Identi.ca handle: @kidehen
> > Google+ Profile: https://plus.google.com/112399767740508618350/about
> > LinkedIn Profile: http://www.linkedin.com/in/kidehen
> >
> >
> >
> >
> >
>
> Social Web Architect
> http://bblfish.net/
>
>