- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Mon, 18 Feb 2013 11:41:11 -0500
- To: public-webid@w3.org
- Message-ID: <512259A7.4020204@openlinksw.com>
On 2/18/13 11:13 AM, Michael Hackett wrote: > On 17 February 2013 17:18, Stéphane Corlosquet <scorlosquet@gmail.com > <mailto: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. 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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Monday, 18 February 2013 16:41:41 UTC