- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sun, 04 Nov 2012 13:06:22 -0500
- To: public-xg-webid@w3.org
- Message-ID: <5096AE9E.90102@openlinksw.com>
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 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. 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>> >> 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 Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Sunday, 4 November 2012 18:06:45 UTC