Re: Principal term choice - Was: Re: Identity interoperability

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?

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

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

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