W3C home > Mailing lists > Public > public-rww@w3.org > November 2012

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

From: Alexandre Bertails <bertails@w3.org>
Date: Thu, 15 Nov 2012 16:31:27 -0500
Message-ID: <50A55F2F.5080707@w3.org>
To: Kingsley Idehen <kidehen@openlinksw.com>
CC: Andrei SAMBRA <andrei.sambra@gmail.com>, "public-webid@w3.org" <public-webid@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
On 11/15/2012 12:39 PM, Kingsley Idehen wrote:
> On 11/15/12 12:14 PM, Andrei SAMBRA wrote:
>> On Thu, Nov 15, 2012 at 12:02 PM, Kingsley Idehen
>> <kidehen@openlinksw.com <mailto:kidehen@openlinksw.com>> wrote:
>>     On 11/15/12 11:40 AM, Andrei SAMBRA wrote:
>>>         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.
>>>     +1
>>>     We should remember that WebID is a _W3C_ group, not an IETF one.
>>     So you infer that URIs belong to IETF and URLs to the W3C? At the
>>     same time you assume this is architecture with real
>>     interoperability in mind.
>>     You are making an important point here, quite profound. I really
>>     need to know if this is the view shared by others.
>>     The most powerful virtue of the Web is its interoperability. That
>>     virtue is inextricably linked to URI abstraction.
>> No, my point is that WebID URIs use HTTP(S) schemes. The point is to
>> avoid ftp:// WebIDs (or any other scheme) in order to simplify the spec.
>> Andrei
> Abstraction != Difficult.  Please understand that the principle in play
> re. AWWW is "deceptively simple" which is a function of good
> abstraction. URI abstraction is a fine example of said principle. This
> is what makes the Web work.

You're confusing "difficult" and "complex".

By being too abstract and general, you artificially increase the
complexity of WebID by implicitly asking support for many different

By narrowing-down the definition to very precise concepts, you define
the minimal set of expectations that the system must support.

Also, examples are not acceptable as definitions, because they don't
say anything about expectations. You need to define the invariants of
the system.

That was the concern of the people who set the definition for WebID at
TPAC. I don't understand why people are loosing time with changing the


> For WebID based authentication to work it doesn't need to compromise the
> virtues of URIs. Just use simple examples to make matters clearer.
> The solution to the problem is that you don't introduce technology via a
> technical spec. It's conventionally achieved as follows:
> 1. conceptual guide and overview
> 2. technical specs
> 3. implementation guides and examples -- this is where you can be
> specific about URLs, Turtle docs etc.. by using them in all the examples.
> When you start from #2 you are vulnerable to:
> 1. political distractions -- e.g., format (as opposed to semantics)
> oriented warfare
> 2. FUD -- when the abstract nature isn't obvious those threatened will
> come at you with FUD.
> We don't need to compromise the essence of the Web for all of this to work.
> Remember, HTML wasn't prescribed to the world en route to WWW bootstrap,
> the "view source" pattern from early browsers enabled folks to cut and
> paste what was behind the page (which could have been anything) into new
> spaces en route to understanding the implications of fusing Hypertext
> and TCP/IP.
> Standards are retrsopective things, they are the result of coalescing
> around what works, so the sequence is always:
> 1. de facto standard -- common practice
> 3. industry standard -- accepted best practice.
> 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
Received on Thursday, 15 November 2012 21:32:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:04 UTC