Re: Domain of :key

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

>
> On 29 Mar 2013, at 18:24, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> 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.
>
>
> Please just define mvn:key put it up somwhere and then we can discuss.
>
>
>
>>>
>>>> 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
>
>
> dbPedia:EiffelTower mlv:key key .
>
> is a sentence that your ontology allows since the domain is anything. So
> what would it mean
> for a shoe, the eiffel tower, or an atom to have a key? How would I know
> it is true or if it is false?
>

there's probably an uncountable number of triples that are ambiguous or
nonsensical

what does it mean for a rainbow to have a smile?

isnt it an exercise for the reader?

you can use the sem web to write nonsense, that can never be forbidden,
what does it prove?


>
>
>
>
>>
>>
>>
>>>> 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/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>