Re: Summary of cert : key Domain discussion

On 31 March 2013 16:12, Henry Story <henry.story@bblfish.net> wrote:

>
> On 31 Mar 2013, at 14:13, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
>
> On 30 March 2013 14:59, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 30 Mar 2013, at 14:45, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>> Summarizing the thread.
>>
>> I proposed that the Domain of : key be more general than Agent, since a
>> public key is just a number, more than just an agent could have such a key.
>>
>>
>> The :key relation relates an agent to a public key of which he has the
>> private key.
>> This means that one can understand what it is to verify that an agent has
>> a key.
>>
>
> Yes, so I think this is a bug that goes back to the time when WebID was
> branded as FOAF + SSL.
>
>
> An old bug for which after years of use you are the first to "discover".
>

Yes, like the two I noticed last week and have been patched.  Indeed there
is a second buy in the : key relation the Range

See

http://www.w3.org/ns/auth/cert#key

*"key* - relates an agent to a key -* most often* the public key."

Yet it has
Range: cert:PublicKey <http://www.w3.org/ns/auth/cert#PublicKey> My feeling
is that you are in the slight minority here, but I'm very happy to hear
your arguments.

Let's raise this at the CG or WG level and come to a community consensus. I
appreciate things can take time to change/fix.  But in the longer term I'm
confident the community will get it right, and I think there's enough
clarity to enable progress.

Also I think you may change your mind when you see WebID powered payments
systems! :)



> In any case this is not a bug, it's a feature request. You need a new type
> of relation for a
> use case you still need to develop.
>
>
> So then a WebID becomes part of FOAF.  I think the community will have to
> decide whether it wants to closely couple the TLS spec to FOAF or not.  For
> example, facebook dont use FOAF in their profiles, though they did consider
> it.
>
> Actually I forgot to count Mo's opinion, so at present I think rdf :
> Resource is slightly ahead in the straw poll.
>
>
>>
>> An example I gave was that an account (e.g. belonging to an agent) could
>> have a key pair.
>>
>>
>> the whole question is what does it mean to "have a key pair" .
>>
>
> I think we can use the typical OO concepts of "has-a" and "is-a" for
> this.  So the subject "has a" key.
>
>
> There may be any other number of properties that you can use.
> If you want the has_a relation then you can use rdfs:member property
>
> http://www.w3.org/TR/2002/WD-rdf-schema-20021112/#ch_member
>
> "he rdfs:member property is a super-property of the container membership
> properties.
> (ie. each numbered container membership property has a rdfs:subPropertyOf relationship
> to the property rdfs:member)."
>
> <> a foaf:Account;
>     rdfs:member [ a cert:RSAPublicKey;
>                             cert:modulus ...;
>                             cert:exponent ...; ] .
>
> Or perhaps any other number of properties will do. It will all depend on
> your use case and ontology,
> how much you need to put into that relation.
>
>
>
>
>>
>>
>> Henry raised the point that you would then lose an inference that the
>> subject of a key was an Agent.  However you should really use rdfs : type
>> for this imho.
>>
>>
>> My point was that
>>   - changing the domain means that you have developed a completely
>> different relation which is not the same as cert:key.
>>   - that it does not make things simpler as you initially claimed it would
>>   - that it is ill defined
>>   - that your reasons for wanting to introduces it rely on handwaving
>> some ontology which has not been developed
>>   - that you can't tell us what it would mean for the relation to apply
>> to inanimate objects
>>   - that you don't distinguish nonsensical from sensical applications of
>> the term, when it is applied outside of the realm of agents.
>>
>
> I think you have something of a case here.  However I'd caution against
> using the "ambiguity" argument.
>
> This has come up on occasion in the TAG and Tim's response is that we
> should try and get things working rather than be "ambushed" by ambiguity.
>
> http://lists.w3.org/Archives/Public/www-tag/2012Oct/0086.html
>
>
>>
>>
>> Henry also raised the point that it would be possible to construct
>> triples such as the eiffel tower having a public key.  Unsure if this is a
>> big deal, or even a demerit :)
>>
>>
>> You could not tell us why you thought this was or was not nonsensical,
>> what it would mean, etc...
>>
>
> I did, perhaps you missed it, but ive repeated above, "has a"
>
> http://en.wikipedia.org/wiki/Has-a
>
>
> rdfs:member is the "has-a" relationship. It's well known and standard. Use
> that and see how
> far you get with your use case.
>
>
>
>>
>>
>> There was a small straw poll which was pretty evenly balanced, slightly
>> in favour of keeping the status quo.
>>
>> If there's further interest in this I'll raise an issue at some point.
>> But I think I have enough to model what I want to now.
>>
>>
>>    Social Web Architect
>> http://bblfish.net/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>