Re: telconf 07-11-2012 : what is webid

On 11/15/12 12:28 PM, Henry Story wrote:
> On 15 Nov 2012, at 17:39, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> On 11/15/12 10:34 AM, Henry Story wrote:
>>>> On the other hand, URIs always designate a method to access the resource and designate the specific resource to be accessed (i.e. http://example.com/card#me). I think we should proceed to using URIs instead of URLs, especially since we're going to push WebID adoption over the HTTP scheme (afaik from TPAC).
>>> I think it is clear that the only thing WebID Auth makes sense is for the WebID to be a URL. Ie it really does not make much sense with URNs which have no clear way of being dereferenced.
>>>
>>> On the other hand URLs are still too general. mailto urls are still part of the URL spec. I think there is no need for us to be so general as to have all URL types because we can tie all the other authentication schemes together using Identity Interoperability
>>>
>>> http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability
>>>
>>> Restricting ourselves to http, https URLs does make for a clearer spec, without
>>> creating interoperability issues. I can see that ftp and ftps would also work, but
>>> we would certainly have a more testable system if we limited ourselves at first.
>>>
>>> I think .onion and .galic urls can be deal with as proxy routing schemes.
>> You are making a poor case for compromising URI abstraction. It's a poor case.
>>
>> URIs are the alpha and omega of the AWWW. End of story, everything else is a broken compromise.
> Every URL ( the subset of URIs that interests us ) comes with a protocol. We use this information
> for finding information about the URI. The schemes listed by the rfc1738 are
>     
> http://tools.ietf.org/html/rfc1738#section-5
>
> url            = httpurl | ftpurl | newsurl |
>                   nntpurl | telneturl | gopherurl |
>                   waisurl | mailtourl | fileurl |
>                   prosperourl | otherurl
>
> There are of course many more. If you look at the other identity mechanisms they
> all tend to work on one type of url, with a specific type of referent. At a very
> abstract level they all work in a similar way, as I think I showed in Identity
> Interoperability
>
>   http://www.w3.org/2005/Incubator/webid/wiki/Identity_Interoperability
>
> But that does not mean that we have to make WebID be the abstraction that covers
> them all.

I am not really implying that. But for whatever reasons that's what you 
discern from my preference for URI.

You want to push an Address/Locator as a Name. It does work, but it 
ultimately hits a problem with intuition and flexibility. You are also 
opting for *implicit* Name/Address indirection as opposed to catering 
for *implicit* or *explicit* Name/Address indirection.

A Linked Data URI exploits indirection such that it denotes an entity 
(anything) while also identifying a Web resource.

The owner of a URI is the one responsible for indirection handling 
choices. There's no one size fits all solution to this matter, hence the 
utility of the abstraction.

> That would feel to them like we were trying to take over their space -
> and people in this space are very defensive of this.

I disagree.

>   I think it is easier if we
> make WebID something that is pretty harmless - an http(s) URL - then we show how we
> can all work together. Later we can extend WebID to mean more.

Why extend when you already have abstraction on your side? All you need 
to do is add more examples in the future when there's a need to tap into 
the breadth of the abstraction as circumstances demand.

If we produce conceptual guides for WebID and its authentication 
protocol, these matters will simply vanish. If we start the game from 
step #2 we'll always be an interaction away from revisiting this issue.

Remember, I said, I'll reluctantly live with the use of URL in the WebID 
definition, even though I also know it won't end the matter.


>
>   This does 2 things for what then needs to be called "WebID Auth over TLS"
>
>    1. It makes our spec easier to write
>    2. we can test it more easily
>
>   This also leaves it open to do "WebID Auth over BrowserID" later when the BrowserId
> folks get over their fixation on e-mail identifiers.

And how does s/URL/URI/g stop that?

>
>   Finally you don't really loose anything because we can and should also develop the
> Identity Interoperability wiki/note/spec to show how one can link them all together.
> As you can  imagine that is going to be a huge job, that will never stop. So we can
> have some spec for WebID and keep progressing on other fronts.

You need a conceptual overview. No technology gets adopted without some 
conceptual overview accompanying the technical specs. This is the 
fundamental issue here.

>
>    As for representation I am still for Turtle and RDFa being together things that
> verifiers MUST understand.

I don't have a problem with Turtle. It just doesn't need to be in the 
definition of what a WebID is.

> Note in the WebID over TLS spec we are not saying what
> must be published, but what  verifiers MUST understand. So that is different from
> what LDP is doing.
>
>    In my view this is just a limitation we can put on the current spec. With careful
> wording its not far from what we currently have.

We need a conceptual guide. This has to accompany the technical specs 
and implementation examples.

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