Re: What is a WebID?

On 10/31/12 10:26 AM, Nathan wrote:
> 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.

You are mixing up two a spec and implementation details. There's nothing 
wrong with an implementation guide charting the most cost-effective 
implementation route. Hypertext is a vast realm, but it didn't stop HTML 
mapping out a cost-effective implementation route for WWW boostrap. 
Colloquially, many WWW users would conflate HTML and the entire realm of 
Hypertext, that doesn't mean one redefines what Hypertext actually is. 
That's my concern.


>
> 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.
So +1 for all our work to be deemed non conforming. Okay, OpenLink 
doesn't have anything that's WebID compatible henceforth. We gain what? 
Bearing in mind everything we do not only showcases WebID in the most 
basic sense, it also showcases WebID compatibility with what exists.

>
> 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.

You are contradicting your +1 and here's why.

Folks are going to follow the new definition which tosses the URI 
opacity attribute in the bin. They are going to operate in lexical space 
and reject URIs based on lexical structure i.e., if it isn't hashless 
it's bad. Thus, you are going to implement URIs that are not WebID 
compliant albeit with the WebID authentication protocol in mind. As you 
said: you are going to implement a generic pattern and encourage it, but 
how isn't that a contradiction?

We've have already implemented and actively promote what you say you 
will be doing and now its all for nothing. Its no longer valid, just 
like that.

> Likewise WebAccessControl will need to use this more generic 
> agent-identifier.
Again, contradiction. The implementers of WebID based ACLs are going to 
have long rejected your non conforming URIs before testing them against 
any ACLs.

> 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.

Contradiction, there will be no such thing generous reception, following 
this redefinition. That's my point.

Kingsley
>
> Best,
>
> Nathan
>
>
>
>
>
>
>


-- 

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