- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Tue, 20 Nov 2012 16:22:39 -0500
- To: public-webid@w3.org
- Message-ID: <50ABF49F.9000802@openlinksw.com>
On 11/20/12 4:18 PM, Henry Story wrote: > I removed the "Principal" from the graph on the spec. > > http://dvcs.w3.org/hg/WebID/raw-file/tip/spec/identity-respec.html > > Kingsley, when you have something to comment about the WebID-spec, > please put it in a thread on the spec, not in a thread on the > Identity Interoperability spec. You can see here which thread this > mail belongs to > > http://lists.w3.org/Archives/Public/public-webid/2012Nov/thread.html > > It can save us a lot of time. I would have agreed with you right off the > bat that I don't think too much about the Principal being in the spec. Okay, but you know these conversations aren't so linear :-) Kingsley > > > On 20 Nov 2012, at 21:42, Kingsley Idehen <kidehen@openlinksw.com> wrote: > >> On 11/20/12 1:33 PM, Henry Story wrote: >>> I agree that using the word Principal in the WebID spec is something that I am >>> ambivalent about. It is useful in the Interoperation document, because that is >>> where the confusions about Principals need to be resolved. Given that... >>> >>> On 20 Nov 2012, at 17:45, Kingsley Idehen <kidehen@openlinksw.com> wrote: >>> >>>> On 11/20/12 10:50 AM, Henry Story wrote: >>>>> Notice that these definitions always speak of the "Principal resource". >>>>> Those are 2 words. You have the Principal which is the string, and the >>>>> principal resource which is the document which we call the WebID Profile >>>>> in the case of WebID. Java allows public keys to be principals, and it >>>>> is not clear there what the resource is on the web for it. >>>> If the principal is a string, >>> If you read my message a bit further you'll have noticed that I moved on >>> to say that a principal is something that is constructed from a string. >>> So I do agree that it is not a string. >>> >>>> and the "principal resource" a chunk of data >>>> then end product is simply this: >>>> a string that denotes the chunk of data. And by de-reference the string can used as a mechanism to get you to a representation of the data (its values). >>>> >>>> When the string is used in a specific system e.g., URI abstraction, >>> I know what a URI is, I don't know what a URI abstraction is. >> URI abstraction: how a string pattern incorporates naming and data access in a data access protocol agnostic manner. Schemes abstract naming and data access, for instance. >> >> >>> It is a good writing policy to remove words from your sentences >>> that don't contribute to the meaning of what you are saying. >>> It is only bad marketeers that do this. >>> >>>> you end up with a denotation mechanism that *automagically* resolves to data. >>> I don't know about magic. Is that a new OpenLink product? >> Is that called for? > Using terms clearly and less hand waving can save us a lot of time. > I'd like to be doing some coding, rather than answer misguided mails > on this mailing list. > >>> If so this >>> is not the forum for doing sales pitches. >> Indirection for the uninitiated. >> >> Indirection is old to computing, we looped over this before. Re. Linked Data a hash URI has implicit indirection. A hashless URI has explicit indirection via 303 redirection. >> >> You can ignore Name / Address ambiguity as much as you like, you can't wish it away. > I do not ignore indirection, nor naming issues. I give philosophy talks on these > issues. Please consider who you are speaking to before you write. > >>>> Example if the string is a URL and the system in question is the Web. >>>> >>>> At then end of all of this we are going to be left with the following: >>>> >>>> 1. Principal and Principal Resource -- a word and a phrase that will open up their own can of worms since most won't take the time to look at your interop document. >>> I do lean towards thinking that the word Principal does not have its place >>> in the WebID spec. >> Good! >> >> That's the fundamental reason for the push-back. You claim to seek simplicity and then you contradict the goals by your own actions. > This thread is about the Identity Interoperability. The confusion comes from not > being careful about where you post. See the thread: > > http://lists.w3.org/Archives/Public/public-webid/2012Nov/thread.html > > >>>> 2. Inference -- should reasoning be a MUST or SHOULD when implementing a WebID over TLS based verifier? >>> The WebID-TLS spec does not mention reasoning I think. >> I know it shouldn't, but we will eventually reach this matter, in appropriate context. I'll meet up with you then when we get there, inevitably. >> >>>> Object identity and its effects on equivalence by name or value is old subject matter that's easy to understand without any SPARQL examples when explaining the effects of owl:sameAs and inverseFunctionalProperty entity relationship semantics. >>> I was just using SPARQL in my mail as a way of linking functional and declarative thinking. >> Yes, an as I said above, we'll meet at the reasoning bus (or train) stop, at the right time. >> >>>> In an attempt to make things simple, for the inattentive, we are heading in the opposite direction, unfortunately. >>> My explanation was not intended to go into the spec. It was just me trying to develop >>> my ( our ) understanding of how the notion of Principal seems to work. >> Yes, but I don't see how it accelerates the goal of completing the definitions of WebID, the WebID profile Document, and the WebID or TLS protocol, without kicking off threads like this. >> >> I know what you are trying to achieve, much of which I don't have much disagreement (I did +1 the interop document since its really a vital endpoint illustration) but I also need you to be a little more flexible about how to get there. There are many problems to be averted with a modicum of flexibility. That's all I seek from you and others that are opting for "simply simple" as opposed to "deceptively simple". >> >> >> Kingsley >>>> Links: >>>> >>>> 1. http://www.cs.cmu.edu/~clamen/OODBMS/Manifesto/htManifesto/node4.html -- Object Identity . >>>> >>>> -- >>>> >>>> Regards, >>>> >>>> Kingsley Idehen >>>> Founder & CEO >>>> OpenLink Software >>>> Company Web: http://www.openlinksw.com >>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >>>> Twitter/Identi.ca handle: @kidehen >>>> Google+ Profile: https://plus.google.com/112399767740508618350/about >>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen >>>> >>>> >>>> >>>> >>>> >>> Social Web Architect >>> http://bblfish.net/ >>> >> >> -- >> >> Regards, >> >> Kingsley Idehen >> Founder & CEO >> OpenLink Software >> Company Web: http://www.openlinksw.com >> Personal Weblog: http://www.openlinksw.com/blog/~kidehen >> Twitter/Identi.ca handle: @kidehen >> Google+ Profile: https://plus.google.com/112399767740508618350/about >> LinkedIn Profile: http://www.linkedin.com/in/kidehen >> >> >> >> >> > Social Web Architect > http://bblfish.net/ > -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Tuesday, 20 November 2012 21:23:01 UTC