Re: Domain of :key

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

>
> On 29 Mar 2013, at 16:28, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> 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.
>
>
> I am developing the consequences of your proposal. mvn:key does what you
> want.
> But does it do what WE need it to do? My argument is that it does not make
> things simpler
> as you claimed it does. In fact it raises a whole bunch of issues, and
> puts work on our
> plate for a benefit that is completely hypothetical.
>


As I said, please reread your sentences, they dont make sense.  I suspect
you have typoed something somewhere.


>
>
>
>>
>>
>>
>>
>>>
>>> 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?
>
>
> I am developing YOUR example. You are the one in charge of the meaning of
> mlv:key .
> So it is up to you to tell me what it means. I don't know what it means
> for the eiffel tower
> to have a public key. Or I don't know what to make of that information. I
> don't know how
> I would decide if it were true or false for example. Ie: the meaning of
> that statement is not
> clear.
>


mlv : key and eiffel tower are your examples

you seem to have constructed a triple that is either non nonsensical or
ambiguous

unsure what this proves


>
>
>
>>> 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.
>
>
> Well perhaps someone developing an ontology for bitcoin, and developing
> the use cases where they
> would use the ontology, would be useful. Your brought bitcoin to the
> discussion as an important use case.
> Then you said that they NEED your relation. I don't know why they would
> need that relation rather than
> another one. For that you'd need a lot more work on developing the bitcoin
> use case.
>

Well this is the second time it's been attempted to use webid and payments
together.  Payswarm was the first and they gave up, now we have the cert
ontology and the sec ontology as a result:

http://payswarm.com/specs/source/vocabs/security#publicKey

Perhaps we will have a third public key definition if you want to tightly
bind the idea of a public key to WebID via the "key" predicate.  The terms
"key" and "agent" are need not be closely coupled, but I can see why you
may want to do that.

As usual I'll go with the consensus, and if that means building new instead
of reusing, we can just have (yet) another vocab.


>
> And this is without mentioning that I still don't know what it means for
> the Eiffel Tower to have a key.
>
>
>
>>
>>
>>
>>>
>>> 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/
>>>>>>>>
>>>>>>>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>