Re: Domain of :key

On 29 Mar 2013, at 13:35, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> On 29 March 2013 13:21, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 29 Mar 2013, at 11:11, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
> 
>> 
>> 
>> 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?
> 
> yes.
> 
> good
>  
> 
> The problem is that you need to define how for some object X you relate it to the private key. 
> In order to distinguish your definition from the current one, so that we don't have misunderstandings
> let us call your relation mlv:key .
> 
> mlv:key a rdf:Property;
>      rdfs:domain rdfs:Resource;
>      rdfs:range cert:Key .
> 
> fine
>  
> 
> Now that means I can relate any object to a key. For example why could I not take the Eiffel Tower,
> and write:
> 
>      dbpedia:EiffelTower mlv:key <http://bblfish.net/people/henry/card#key1> .
> 
> why could you not?  you just did

Indeed you can. So if you want you can publish the mlv:key ontology in your namespace.
Perhaps it will get traction.

The point of writing ontologies for reasoning is that you don't just stop at that point.
You can relate anything to anything by some relation.  The problem is distinguishing your
mlv:key relation from every other relation. What distinguishes it from 

mlv:loves 
mlv:saw
mlv:wantToOwn,

etc...  You need to do the work of defining it. And when you do that you'll start seeing that
your problems start building up, as shown below.  


>  
> 
> Good so now what kind of relation is that? What is the relation of the private key to the Eiffel
> tower that we need in order to prove cryptographically the identity of a user of the key? You
> want some kind of way of limiting what objects you can truthfully add the cert key relation to,
> otherwise it is meaningless.
> 
> eiffel tower has a public key ... not sure it's problematic

What does it mean for the eiffel tower to have a public key? Do you mean it's written on it? Do you
mean you would like it to have one? Do you mean it can sign documents with it ( in which case it's an
agent, and the problem does not arise )

>  
> 
> Perhaps I need a relationship of ownership to the EiffelTower to be able for the relation to the
> agent to work?  Perhaps
> 
> mlv:owns a owl:InverseFunctionalProperty;
>     rdfs:comment """
>        an agent that owns according to all legal system the object. 
>        (If we add relativity to a legal system things get more complicated)
>     ";
>     rdfs:domain foaf:Agent;
>     rdfs:range rdfs:Resource .
> 
> So then we would have the rule
> 
> { ?agent mlv:owns ?thing . ?thing mlv:key ?key } => { ?agent cert:key ?key } .
> 
> So your "simplification" in fact is going to create more complexity elswhere.
> You could argue that when the ?thing is an agent it owns itself perhaps, and 
> so that in that case it should fall out through reasoning. But now we have
> introduced an "if x is an Agent then do Y else do Z" into our code everywhere,
> and we need to specify everywhere that people have to write out for anything
> they put a mlv:key on that they need to specify that it is a foaf:Agent.
> 
> Are you saying that people are making inferences on the :key relation to assume the subject is an agent, and that, that is your objection?

Yes, that is the whole point of cert:key. It relates the agent who controls the key to the 
key. That is why this relation is useful to use in the WebID/TLS spec.


>  
> 
> ie: you can't put:
> 
> <#me> mlv:key key.
> 
>     you need to write 
> 
> <#me> a foaf:Agent;
>           mlv:key key .
> 
> surely this is good practice anyway, a subject should specify a type, we do think in JSON-LD with @type, for example
> 
> is this your objection?

I am just listing all the ways in which your "simplification" is increasing complexity.  This is one
of them.

The other that you ignored is that our code is now bifurcated, into
 "if x is an Agent then do Y else do Z ( find the mlv:owns relationship(s?) to x )" 

>  
> 
> And none of this yet prooves that your hypothetical bitcoin example would not be 
> better off with the cert:key relation. 
> 
> sure, but does not make the question invalid

It does. Because you are asking us to do a lot of work here, for some hypothetical
work you may want to do in the future, but which you have not bothered doing, 
and for which you have no clear support. 

If Bitcoin comes to the table and helps us form a Working Group then we can
look at this in detail. But without them here, it is a waste of time to guess what they
could be wanting.

>  
> 
> For reference currently we have:
> 
>   119 :key a owl:InverseFunctionalProperty;
>    120     vs:term_status "unstable";
>    121     rdfs:label "key"@en; 
>    122     rdfs:isDefinedBy <cert#>;
>    123     owl:inverseOf :identity;
>    124     rdfs:comment """relates an agent to a key - most often the public key."""@en ;
>    125     rdfs:domain foaf:Agent;
>    126     rdfs:range :Key, :PublicKey .
> 
> ( It should say something about the control the agent has over the corresponding private key . 
>   A previous version had that text in there. We seemed to have lost it.)
> 
> 
>> 
>> 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.  
> 
> You gave a use case yes. We don't know if the use case is best modelled the way
> you are thinking of modelling it. That would require people to work on the bitcoin model
> in detail, and they could end up being satisfied with the cert:key as it is now.
> 
> I think you need to prove that this cannot be the case. 
> 
>> 
>> 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.  
> 
> It looks simple, but it creates complexity elsewhere. 
> 
> I'm still trying to work out where (if at all) ... we're getting closer it seems.
>  
> 
>>  
>> 
>> 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.
> 
> It is a hypothetical bug. You have suggested a modelling need for bitcoin. But there has
> been no scrutiny of this. There cannot be: since the work has not been done. And the work
> of doing this is not something that can be done on the back of an envelope in 5 minutes.
> 
> If I can clarify the situation it will be possible to build a proof of concept.  Running code is always a help in achieving consensus.
> 
> In short, I'm unsure you've raised a compelling objection, base on any concrete cases.  
> 
> So far on this thread there's 
> 
> in favour of rdfs : Resource +2
> In favour of foaf : Agent +1
>  
> 
> Henry
> 
>>  
>> 
>> 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.


Yes, but it does not follow that your idea of how to model their problem is the right one.


>>>>>>  
>>>>>> 
>>>>>>> 
>>>>>>> Is the parent of Agent an owl : Thing?
>>>>>> 
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>>>> 

Received on Friday, 29 March 2013 13:08:59 UTC