Point of Order! - Re: WebID 1.0 -- Section 3 -- Removal of Note

I would really appreciate Kingsley if you started debating on the points,
without making up facts, and  stop your ad hominem attacks on whoever 
you disagreed with. Your personal attacks only harm you and your company's 
reputation, and do nothing to help us move forard.

Your attack on the editors, in the text below is just one case of unacceptable
behavior that has become more and more regular in recent months.

On 18 Feb 2013, at 17:41, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 2/18/13 11:13 AM, Michael Hackett wrote:
>> On 17 February 2013 17:18, Stéphane Corlosquet <scorlosquet@gmail.com> wrote:
>> We use hash URIs in all our examples, and people who are new to WebID and looking at implementing this will use hash URIs.
>> 
>> Just to echo what Mo said, people won't use them if they don't know what they are, or rather why they are used. To someone just looking at WebID as a distributed identity system, who might have lots of experience building web sites (or maybe not so much), but no experienced with Linked Data, the hashes don't stand out as significant. I think it would be very helpful if the spec included a brief explanation of their use and a link to more in-depth reading. (Don't just point to a long external document, as developers will not be compelled to read a long doc if they don't immediately see the value.)
>> 
> 
> Links from a prior posts in this thread:
> 
> 1. http://lists.w3.org/Archives/Public/public-webid/2013Feb/0029.html -- TimBL presentation link (covers indirection via hash and hashless URIs; note that the hashless slide has a few typos that leads to confusion)
> 
> 2. http://lists.w3.org/Archives/Public/public-webid/2013Feb/0060.html -- provided references to materials that address the tradeoffs associated with either style of HTTP URI in the context of Linked Data. 
> 
> All:
> 
> For those of you that don't understand my fundamental frustration with Henry (as Chair) and Andrei (as Editor) it boils down to this:
> They are selective and obstructive when dealing with responses that differ from theirs. For instance, they reacted to the vote on the definition of a WebID by inserting an unnecessary notice.

You are making things up Kingsley here as you have ben throughout this disussion about the properties of 303s. 

It is easy to proove this. Just go to the Mercurial repository where you will find the full history of the spec

  https://dvcs.w3.org/hg/WebID/log/tip/spec/identity-respec.html

Then if you take the spec from three weeks ago, before we did any of the updates
( but just after changing the https:// problems due to W3Cs switch over to Mercurial
 you will find the version of the spec here:

https://dvcs.w3.org/hg/WebID/raw-file/016d0bd59833/spec/identity-respec.html

You will see that it states

[[
HTTP 303 redirects should be avoided (needs further discussion). Since WebIDs contain a URI fragment identifier, it is not nessary to use HTTP 303 redirects in order to make the difference between the identifier and the document it points to; the relationship becomes obvious.
]]

You will see that this text was even in the December version. 

All we did since then is shorten this text and adapt it some way towards what we thought
would be acceptable given the vote we had to allow 303 redirects [1] But then you started 
this huge thread on this issue, bullying your way around with accusations on pretty 
much everyone who did not agree with you. 

I have stated a few times that I think we can improve the wording of what is there. But
we certainly did not ADD a notice. We adapted it as per requirement of previous vote.
We just did not go all the way to where you wanted it to go.

We furthermore have a process that we are following to get to the bottom of this
as I explained today

  http://lists.w3.org/Archives/Public/public-webid/2013Feb/0225.html



Henry

[1] https://www.w3.org/2002/09/wbs/51933/webid-hash/

> 
> How should this have been addressed, if this was genuinely about clarity as opposed to a backdoor mechanism for negating the vote? They could have done exactly what's outlined above, add links to relevant documents that cover the different types of HTTP URIs and their usage implications. Even better, they could have looked to the following document collection to really make things clear:
> 
> 1. WebID -- definition document.
> 2. WebID oriented Profile Document -- defines the fundamental characteristics of a WebID oriented profile document.
> 3. WebID oriented Profile Document publishing -- how to publish said document (a natural place to shed light on HTTP URI choices) .
> 4. WebID authentication protocol -- defines the WebID+TLS protocol that's used to verify a WebID based on its association with a WebID profile document. 
> 
> 1-4 would be cross referenced using their respective URLs from the relevant documents. 
> 
> Here are some important points about Linked Data:
> 
> 1. Linked Data is about Data Representation and Access that leverages RDF, HTTP, and core architecture of the Web.
> 2. HTTP URIs in this context have tradeoffs that affect consumers, publishers, and agents that oscillate between either role. 
> 3. Implementing a Linked Data solution is fundamental to understanding its many nuances.
> 4. Demonstrating Linked Data comprehension is best done via Links. 
> 
> Ironically, I've been through this loop with RDF/XML, and today RDF is finally (12+ years later) decoupled from that classic example of conflation gone wrong. The only thing you get from failure to separate powers is confusion that ultimately compromises the fundamental goal i.e., in this case: leveraging Linked Data en route to producing a spec for Web-scale verifiable identity. 
> 
> 
> To conclude, a W3C community effort isn't about the personal preferences a chair person or editors. It's about a communal effort to fashion a spec. 
> 
> -- 
> 
> 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
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/