Re: Domain of :key

On 4/1/13 4:06 PM, Henry Story 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.

That's true, but I wasn't trying to refute owl:sameAs per se. I was 
trying to show how an alternative relation can be used to bring clarity 
to the semantics in play.

>
> 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> ).

The real issue here is the intuition generated by cert:key sorta cloaks 
the semantics of the relation.

>
>> What's critical to WebID is the InverseFunctionalProperty relation semantics which help appreciate the optimal domain for <#hasKey> .
> yes. Agree.
>
>> 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.

Yes, so maybe the solution would be to add relations to the ontology 
that reflect other associations, without compromising intended semantics.

Kingsley
>
> 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/
>


-- 

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