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

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

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 15 Nov 2012 12:39:20 -0500
Message-ID: <50A528C8.2050502@openlinksw.com>
To: Andrei SAMBRA <andrei.sambra@gmail.com>
CC: "public-webid@w3.org" <public-webid@w3.org>, "public-rww@w3.org" <public-rww@w3.org>
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.

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 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 17:39:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:45 UTC