Re: What is a WebID?

Kingsley Idehen wrote:
> 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.

The constraints of "hash HTTP URI which denotes an agent" as opposed to 
"URI which denotes an agent", and "TURTLE" as opposed to "LINKED DATA", 
serve to simplify the implementation of WebID dependant components, and 
encourage what we both often consider to be "best practice".

They are constraints, so they do constrain what we can class as a WebID.

Ultimately, I have personally weighed up the pros and cons, having 
similar insight on the broader topics as you, and came to the conclusion 
that the benefits of the constraints (and the interoperability they 
enable simply) outweigh the benefits of the more generic "URI" and 
"Linked Data" when it comes to efficiently creating interoperable RWW/LD 
components.

The definition of WebID to me, as stated, is an achievable goal which 
I'd love to see adopted broadly. Thus +1 to the definition as it was 
suggested.

Of course in my own applications I'll be supporting the more generic 
"web friendly agent identifier" (a URI which denotes an Agent), as will 
most of us, and it's something I'd encourage. Likewise WebAccessControl 
will need to use this more generic agent-identifier. But when it comes 
to publishing I'll be conforming to that higher bar of WebID, and hoping 
everybody else will.

Be strict in what you send, but generous in what you receive.

Best,

Nathan

Received on Wednesday, 31 October 2012 14:27:30 UTC