- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Wed, 31 Oct 2012 09:38:09 -0400
- To: "public-rww@w3.org" <public-rww@w3.org>, "public-webid@w3.org" <public-webid@w3.org>
- Message-ID: <509129C1.2010901@openlinksw.com>
All, In the last 48 hours following TPAC, a definition of what a WebID has emerged. It reads as follows: "WebID" (hash HTTP URI which denotes an Agent. Where you can GET an RDF model as TURTLE.) . I believe this definition is unnecessary inflexible albeit well intended. Problem: A URI is an opaque identifier. A Linked Data URI is a de-referencable URI that denotes an entity in such a way that when de-referenced said URI resolves to a description document of its referent. Put differently, you have two routes to the same document content i.e., the first being the entity name (URI) and the other being the entity description document address (URI/URL). Ideally, the content of the document in question takes the form of RDF model based structured data represented (or expressed) using an entity relationship graph. A WebID supposed to be a Linked Data URI. HTTP, hash URIs, and even the RDF data model are specific implementation details. They are collectively cost-effective and useful, but none of that makes them mandatory items for specs relating to Linked Data, Web-scale identity verification, or Web-scale resource access control. The architecture of the Web is deliberately abstract thereby enabling powerful loose coupling of data access protocols, data representation formats, and semantics. Simple Example: At this point in time, should this definition hold, the hashless ProxyURIs that we use to watermark X.509 certificates for holders of LinkedIn, Twitter, Facebook, G+ etc.. accounts are all rendered non conforming, just like that. Conclusion: I am officially lodging my opposition to this definition of a URI that serves as a WebID. -- 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 Wednesday, 31 October 2012 13:38:38 UTC