Re: Domain of :key

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

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

Please reread what you wrote.  First you said you can not, now you say you
can.  This makes little sense.


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

Eiffel Tower   "has" key ... [ pubkey ]

just like <#hjs>  "has" name "Henry Story".

It's your example, you can decide what it means.

What is the purpose of your example, are you trying to raise a counter
example?


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

OK got it.

So you need to make the case that this inference is important.  I dont
think it is.


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

Branching on type is quite normal.  You would not treat a person the same
way as you would a building.  What you are suggesting is to infer the type
from the predicate, in the event that it is missing.  This seems like a) an
edge case b) bad practice so I dont think it's relevant unless you have
evidence otherwise


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

Who's "us" ... this is a community group.  You have a subjective view that
it's a lot of work, it's a two line change.  I can write the turtle or
this.  We just need a streamlined process for updating a vocab, in line
with consensus, so we can be agile.


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

As I have explained to you, bitcoin is not an organization.  It's a
decentralized accounting system and currency.  The whole point of bitcoin
is that there is no central point of control.  So your statement of binging
bitcoin to the table, doesnt make much sense.


>
>
>
>>
>> For reference currently we have:
>>
>>   119 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l119> :key a owl:InverseFunctionalProperty;
>>
>>    120 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l120>     vs:term_status "unstable";
>>
>>    121 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l121>     rdfs:label "key"@en;
>>
>>    122 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l122>     rdfs:isDefinedBy <cert#>;
>>
>>    123 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l123>     owl:inverseOf :identity;
>>
>>    124 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l124>     rdfs:comment """relates an agent to a key - most often the public key."""@en ;
>>
>>    125 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l125>     rdfs:domain foaf:Agent;
>>
>>    126 <https://dvcs.w3.org/hg/WebID/file/db5dae845920/ontologies/cert.n3#l126>     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.
>


Fair enough, but I think I have enough now to start working.  Once you see
agents making payments you may change your mind.

You seem to be resistant to even slight changes in the cert ontology (which
I had thought was a community effort).  This does indeed make me think that
using something else such as the sec ontology and/or making my own makes
more sense.

We can just raise the domain of cert : key ( foaf : Agent or rdfs :
Resource )  with the group and reach a consensus.


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