Re: Domain of :key

On 29 March 2013 11:01, Henry Story <henry.story@bblfish.net> wrote:

>
> On 29 Mar 2013, at 10:50, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> On 29 March 2013 10:41, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 29 Mar 2013, at 10:25, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>>
>>
>> On 29 March 2013 09:52, Henry Story <henry.story@bblfish.net> wrote:
>>
>>>
>>> On 29 Mar 2013, at 09:21, Melvin Carvalho <melvincarvalho@gmail.com>
>>> wrote:
>>>
>>>
>>>
>>> On 29 March 2013 09:14, Henry Story <henry.story@bblfish.net> wrote:
>>>
>>>>
>>>> On 29 Mar 2013, at 08:53, Melvin Carvalho <melvincarvalho@gmail.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On 29 March 2013 08:37, Henry Story <henry.story@bblfish.net> wrote:
>>>>
>>>>>
>>>>> On 22 Mar 2013, at 10:42, Melvin Carvalho <melvincarvalho@gmail.com>
>>>>> wrote:
>>>>>
>>>>> Currently we have:
>>>>>
>>>>>     rdfs:domain foaf:Agent;
>>>>>
>>>>> This seems slightly restrictive.
>>>>>
>>>>> Many things can have a key, e.g. a certificate, an account, an app
>>>>> etc.  Agent perhaps does not cover every conceivable use case?
>>>>>
>>>>>
> We are not here to cover every conceivable use case. That would be
> absolutely impossible to do.
>
>
>>>>> You can create new relations to relate those things to keys if you
>>>>> need to.
>>>>>
>>>>>   foaf:primaryTopic can relate a document keys it is about for example.
>>>>>
>>>>> We need a relation to relate the agent that is the one that controls
>>>>> the private key
>>>>> of the public key to the public key, as that is what WebID
>>>>> authentication and most
>>>>> other protocols need to work.
>>>>>
>>>>
>>>> In bitcoin users have a pseudo anonymous account.  Each account has a
>>>> key pair.  It would be great to be able to model this.
>>>>
>>>>
>>>> Why could one not think of an account as an Agent? It can transfer
>>>> money, it can accept payments, etc... It is a micro agent related to you.
>>>>
>>>
>>> Ah OK, if an agent can also be an account, that works.
>>>
>>>
>>> It depends of course on what the bitcoint:Account thing is that you are
>>> speaking of.
>>> And one would need to  compare that to the definition of foaf:Agent.
>>>
>>> Say for sake of argument that you think of such an account more as a
>>> bucket, in which you
>>> can add money like you could add water to a bucket, and from which you
>>> can remove money
>>> as you could pour water out of a bucket into someone else's glass. Here
>>> thinking of the bucket as
>>> an Agent does not sound right.
>>>
>>
>> This is a great analogy.  Each bitcoin account is like a bucket that
>> contains 0 or more bitcoins.
>>
>> It makes no assumptions whatsoever about ownership.  Indeed, there need
>> be no concept of ownership.
>>
>>
>> There has to be a relation between an agent that knows the private key
>> and can prove its ownership
>> of that key, at least in so far as it signed the private key. That
>> requires the relation between an agent
>> and a key, which cert:key is about.
>>
>
> cert : key can be used for this.
>
>
>>
>>
>>
>>>
>>> Then you can think of the access to the bucket as being restricted to
>>> certain
>>> agents. In which case you can use the Web Access Control vocabulary.
>>>
>>>  http://www.w3.org/wiki/WebAccessControl
>>>
>>> The wac ontology relates an Agent(a), a resource, and actions that can
>>> be done on those
>>> resources.
>>>
>>> So there are a number of ways of relating different things. One does not
>>> need to use cert:key
>>> for each of these ways of relating them.
>>>
>>
>> It would be great if I could say
>>
>> <> a foaf : OnlineAccount
>>   cert : key [ ... ]
>>
>> Independent of any ownership details.
>>
>>
>> You can say that, but not with the cert:key relation. Changing the
>> cert:key relation means
>> we then have to change all the specs.
>>
>> I'd rather we now finish the specs as we have them, so that we can
>> propose this to the
>> W3C for a Working Group. BitCoin can then join that Working Group by
>> proposing a clear
>> use case, with an ontology that it is using, which can then be used to
>> extend the ontology.
>> This XG is past the end of its life time, and this is not the time to
>> make drastic revisions.
>>
>
> Yes totally agree we should move forward ASAP.
>
> I think this is a minor bug fix.  The cert ontology is not about WebID
> it's about certificates and security.  We can fix it in the hg like we
> quickly fixed some bugs earlier this week, and added DSA.
>
> Why do you think this is a drastic change, I dont think any
> implementations need change?
>
>
> Because we have defined a WebID as an identifier for an Agent, not an
> identifier for any
> resource. We have defined WebID auth over TLS as identifying an Agent,
> that can prove
> the private key of the public key. Here we now need to add new text in
> every spec in order
> to speak about accounts. We would then need to rework all these specs.
>

I'm trying to follow the logic here.

Let's consider Mo's proposal just to widen the range to something like rdfs
: Resource

A WebID can still be an agent, yes?

Why do you feel the webid spec would be forced to change.  Would leaving
the text the same introduce a bug or inaccuracy?  My suggestion is to leave
the webid specs the same.


>
> The WebAcessControl implementations and ontologies also need to be
> reworked sine
> they are working in terms of agents.
>

Why would WAC implementations need change?  Im unsure this is inaccurate.
Again I propose leaving implementations untouched.


>
> So you are asking us to revise something for a use case you call bitcoin
> for which we have
> no idea how they would write up their ontology, if they even need what you
> suggest they may
> need, etc... It's a lot of hypotheticals for something that is easy to add
> later with a new relation,
> or for which they may in fact be satisfied with what we have.
>

This is not use case driven.  I gave an example.

I repeat I think it's a bug in the cert ontology that would come up in an
XG or WG.

I may be wrong but I thought this was a simple fix.


>
> This is a lot of work, and until bitcoin is really sitting at the table,
> which they will only do
> as part of a WG then we are just speaking hypothetically.
>

It need not be a lot of work.  Bug fixes in specs should have a fast turn
around.


>
> So rather than do that, let's finish the specs, and get momentum for a
> Working Group.
>
> henry
>
>
>
>>
>> Henry
>>
>>
>>
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>> It's perhaps the most serious use of PKI on the web after ecommerce.
>>>>
>>>>
>>>>>
>>>>>
>>>>> Is the parent of Agent an owl : Thing?
>>>>>
>>>>>
>>>>>     Social Web Architect
>>>>> http://bblfish.net/
>>>>>
>>>>>
>>>>
>>>>     Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>>
>>>
>>>    Social Web Architect
>>> http://bblfish.net/
>>>
>>>
>>
>>     Social Web Architect
>> http://bblfish.net/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>