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

Re: What is a WebID?

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Sun, 4 Nov 2012 19:18:41 +0100
Message-ID: <CAKaEYhJo2NGcK-d_SU5e7Xykc0MzjKi9_-pFnZFBPrpxFByA5g@mail.gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: public-xg-webid@w3.org
On 4 November 2012 19:06, Kingsley Idehen <kidehen@openlinksw.com> wrote:

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

Note: in the minutes I was the *only* person not to +1 this, but after some
thought I changed my mind and here's my analysis

The technology we use has not changed.  We still have complete, universal,
tolerant structures using URIs that obey the law of independent invention.
Our solutions are interoperable.  Universal does not mean unique!

On branding it's changed before and it can change again.  Is not a huge
deal to me personally.

Henry has worked on WebID for some time at his own expense (and has even
been to prison for it!).  He should certainly be able to suggest branding
that he feels he feels comfortable with, and that will be effective in
meeting his goals and expectations for the project.

One of the pros was that it was felt this narrow definition would expediate
getting to REC status, either with a WG or by LDP using this as the
definition for identity.  Another pro is that it simplifies test suites.
Another is that WebID has a beach head in facebook, making it potentially
one of the largest identity systems on the Web, though Henry didnt want to
play that aspect up until there is a deeper linked data integration.

I personally like general definitions for things such as the URIs, AWWW,
design issues etc. but I think the feeling was that sometimes to get things
done you need to focus.  We still have all the goodness of AWWW we just
will need to alter what we call things slightly.

> Kingsley
>> 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<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.
> --
> Regards,
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
Received on Sunday, 4 November 2012 18:19:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:31 UTC