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

Re: What is a WebID?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sun, 04 Nov 2012 13:06:22 -0500
Message-ID: <5096AE9E.90102@openlinksw.com>
To: public-xg-webid@w3.org
On 11/4/12 7:46 AM, Andrei Sambra wrote:
> Hi all,
> I suggest to go back to the minutes from 30/10, and look at what 
> arguments were presented then. 
> http://www.w3.org/2012/10/30-webid-minutes.html
> The main reason why we decided that WebIDs must be hashed URIs, was to 
> differentiate between URIs referring to users/agents and URIs 
> referring to documents (hashless URIs). For more details, take a look 
> at httpRange-14 issue: http://www.w3.org/2001/tag/group/track/issues/14.
> The reason why we decided to make turtle mandatory was to try to align 
> ourselves to the LDP spec, since it's in both our interests to do so. 
> The main argument here (raised by TimBL) was that we should focus on 
> moving forward towards a WG, and trying to support as many formats as 
> possible (at this point) will hold us back.
> I know it's difficult for some of you to understand why these changes 
> are happening, but please everyone, just go and reread the minutes. 
> It's all in there.
> Andrei

Reading the minutes doesn't change anything at all.

The definition is utterly broken. This is a total disservice to this 

There were 16 +1's for this broken definition. Nathan asked the 16 
+1'ers to defend their positions. Thus, far nobody has made a cogent 
case for compromising the essence of AWWW and Linked Data.

If you believe in something, make a logical case for it. Thus far, there 
is no logical case for compromising the essence of AWWW and Linked Data 
en route to Web-scale verifiable identity.

Those of us that oppose this broken definition are ready to defend our 

> On 11/04/2012 07:29 AM, Melvin Carvalho wrote:
>> On 4 November 2012 12:47, Jürgen Jakobitsch
>> <j.jakobitsch@semantic-web.at <mailto:j.jakobitsch@semantic-web.at>> 
>> wrote:
>>     hi melvin,
>>     for me the problem is that we now have a political dimension of 
>> personal
>>     preferences which cut my personal freedom of choice.
>>     if we award other linked data groups the same behaviour (express
>>     preferences of uri or serialization) the argument about the 
>> advantages
>>     of having one kind of uri and one kind of serialization become void.
>>     linked data works with any kind of dereferenceable uri and any 
>> kind of
>>     serialization.
>>     if webID only works with hash-http-uris and turtle it is just 
>> another
>>     application in the spirit of web2.0 in the special disguise of using
>>     linked data techniques.
>> I really do sympathize with the points you made and I was initially
>> taken aback by this.  But having thought about it, I've warmed to the
>> idea.  LDP is on a REC track and is possibly the group most relevant to
>> our work.  If we can avoid duplication of effort that would be a plus,
>> imho.
>> I really dont think anything has changed.  Give yourself a
>> dereferencable URI and you're "on the web".
>> WebID itself is just a name, and it will hopefully have a URI soon of
>> the form urn:rfc pointing to a spec.
>> So the spec started mandating FOAF then it mandated an Agent, now it
>> mandates turtle.  Things change, and may change again before 2014 when
>> LDP becomes a REC.
>> Is there really a problem with hash URIs?  Redirects are a pain to
>> program.  Ontowiki did object to this but after some thought worked out
>> their architecture may even be better without the redirects.
>> In what way do you think this is in the spirit of web 2.0?  It is using
>> a complete generalized and universal platform to solve a specific case
>> in a way that will be interoperable and follow standards.



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 Sunday, 4 November 2012 18:06:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:56 UTC