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

On 2/18/13 12:13 PM, Henry Story wrote:
> 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.


I am going to tell you this one last time, I will not stand for your 

OpenLink Software is a W3C member. Our membership isn't gratis.

I will soon withdraw OpenLink Software from participation in this effort 
if you remain the chair. Please don't push me any further.

> 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 < 
> <>> wrote:
>> On 2/18/13 11:13 AM, Michael Hackett wrote:
>>> On 17 February 2013 17:18, Stéphane Corlosquet 
>>> < <>> 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. 
>> -- TimBL presentation link (covers indirection via hash and hashless 
>> URIs; note that the hashless slide has a few typos that leads to 
>> confusion)
>> 2. 
>> -- 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
> 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:
> 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
> Henry
> [1]
>> 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:
>> Personal Weblog:
>> Twitter/  <>  handle: @kidehen
>> Google+ Profile:
>> LinkedIn Profile:
> Social Web Architect



Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web:
Personal Weblog:
Twitter/ handle: @kidehen
Google+ Profile:
LinkedIn Profile:

Received on Monday, 18 February 2013 17:34:04 UTC