- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Sat, 30 Mar 2013 00:48:19 +0100
- To: Henry Story <henry.story@bblfish.net>
- Cc: public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYhKeTqiLE2fAdFjQ3H1r0g6FP0Gwj+jH4-+csKHH-h_EZQ@mail.gmail.com>
On 29 March 2013 18:35, Henry Story <henry.story@bblfish.net> wrote: > > On 29 Mar 2013, at 18:32, Melvin Carvalho <melvincarvalho@gmail.com> > wrote: > > > > 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? > > > We are not trying to develop ontologies here to write poetry. That sounds > like a fun exercise, > but for another list. > Read tim's 'working without being hijacked by ambiguity' ... you brought in the eiffel tower having a private key. Why? People are trying to work, not consider esoteric ambiguous edge cases. > > > 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? > > > So why do you say it is nonsense for the Eiffel Tower to have a key? How > would I know that > it is rather than not? > I'm just unsure what point you are trying to prove by trying to contruct sentences which dont, on the surface make much sense. If you're trying to raise a point, please explain if there's an objection. I've introduced a non breaking change, which in my view is a bug, if something breaks, please do say so. Else we can just reach a consensus and move forward. > > > > >>>>> 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/ >> >> > > Social Web Architect > http://bblfish.net/ > >
Received on Friday, 29 March 2013 23:48:50 UTC