Re: WebID lack of adoption, was Re: Turtle and JSON-LD Matter

On 7/17/14 9:53 AM, Sandro Hawke wrote:
> On 07/17/2014 08:14 AM, Kingsley Idehen wrote:
>> On 7/16/14 8:01 PM, Sandro Hawke wrote:
>>>>>    Maybe worthwhile, but there's a real cost.
>>>> >
>>>> >The cost is a perception. The real cost calculation should be 
>>>> based on
>>>> >the dearth of WebID-* implementations, since inception. Add that 
>>>> to all
>>>> >
>>>> >time spent explaining what WebID-* is about, after all of these 
>>>> years.
>>>> >
>>> I think there are several reasons WebID and WebID-TLS have seen only 
>>> meager adoption.    I don't think what the specs say about RDF 
>>> syntaxes are a big part of that.
>>>
>>>     - Sandro
>>>
>>
>> And what are these issues that are unrelated to RDF? The UI/UX 
>> misconceptions swirling around TLS CCA (Client Certificate 
>> Authentication) as implemented by browsers?
>>
>
> I didn't say unrelated to RDF....
>
> I'm not sure how to answer your question without being quite 
> negative.   Please understand I'm so critical because I think 
> decentralized identity is vital.

As per usual, my response is fundamentally driven by my belief in the 
absolute necessity of decentralized identity management that scales to 
the World Wide Web.

>
> Yes, the UI browsers provide for client certs is a huge barrier. Until 
> we all understand why that UI is so bad, or web-crypto provides a 
> workaround, WebID-TLS has no chance.

I have provided examples [1] of how the client TLS CCA issue is 
alleviated i.e., showing how one can address most of the problem in a 
manner that's easier to explain to end-users. At this point in time, the 
following browsers are the only vectors of the TLS CCA UX issue:

1. Google Chrome
2. Opera.

The following browsers do not have the TLS CCA UX issue (i.e., you don't 
have to restart your browser to switch identity):

1. IE
2. Safari
3. Firefox.

As for the Certificate selection aspect of the overal TLS CCA issue, 
that's where x.509 certificate generators are critical parts of the 
solution. In our case, we developed YouID for iOS and Android to make 
the point. We are even on the verge of releasing an Web Service variant 
of YouID with an HTML UI.
>
> The lack of clarity over what WebID actually is and WebID-TLS actually 
> is, those form a huge barrier.

Yes, and a lot of the time, notation specificity reinforces old 
stereotypes that make dialog impossible with RDF skeptics.

>
> The social style and modes of this group are a huge barrier.   I hope 
> I'm wrong, but my sense is this group has operated with an attitude of 
> "we've got the solution", instead of "here are some use cases and some 
> technologies which can address them," and making bridges to other 
> people working on related problems.

Isn't that very attitude why I am trying to address by requesting equal 
footing for JSON-LD and Turtle?

>
> httpRange-14 (and the resulting HashURIs) is a huge, huge barrier.

httpRange-14 like many things that linger around RDF has more to do with 
mangled narratives.

Words and Terms are old concepts. Name->Address indirection is an old 
concept.

Denotation and Connotation are old concepts.

httpRange-14 is a horrible distraction. Much to really do about zilch. IMO.

>
> The reliance on RDF details and FOAF details is a huge barrier. 

Yes, but we don't really need FOAF.

We don't need RDF notation specificity.

We need to bring life to the concept combined with the abstract language 
that is RDF.  Then we have an audience, because the distracting notation 
(so called "concrete syntaxes" ) specificity issues of yore get tossed 
aside.

> JSON-LD and a new vocabulary (not foaf) could address this.

Yes, we don't need FOAF specificity at all. There is nothing about a 
profile document that's unique to FOAF bar the fact that its existence 
provides read-to-use terms.

>
> I think to move forward will require forming a happy working 
> relationship with the kinds of folks who love h-card and maybe Mozilla 
> Persona. 

Yes!

That's achieved by reaching out style gestures. Simple example, give 
JSON-LD and Turtle equal billing. Demonstrate via examples how RDF 
statements can be constructed using a variety of notations:

1. POSH -- for the Microformats folks
2. "Link:" in HTTP -- for the HTTP folks
3. JSON-LD -- for Javascript Application Developers
4. HTML+Microdata -- for Web Publishers who are driven by Search Engine 
Vendor initiatives
5. Turtle -- for Linked Open Data Developers and Users.


> That will probably require bending on all of the above.

Bend we must!

>   If that can be achieved, then there might be a chance for WebID.

Yes for WebID-* or specifically:

1. WebID-Profile
2. WebID-TLS
3. WebID -- HTTP URI that denotes an Agent.


>
>> If LDP would have put JSON-LD and Turtle on equal standing, why can't 
>> this happen to WebID-* which hasn't even got anywhere close to the 
>> formal status of LDP?
>
> All I was arguing on that front was that there is value to getting 
> everyone to agree on one syntax or at least a very small number of 
> syntaxes.

But it doesn't work, as history has demonstrated. That quest is rife 
with bumps that ultimately generate adoption-inertia.

>   I was replying to people suggesting it's fine for WebID dereference 
> to return pretty much any syntax one wants, trying to point out 
> allowing such proliferation of syntaxes is actually a huge problem.

I see this as document content constructed using a variety of notations. 
Anyway, Turtle and JSON-LD is always better than one or the other, at 
this point in time.

>
> I'm certainly NOT saying that by W3C procedure it's too late to 
> change!   (WebID isn't even to the point in W3C process where there 
> are any procedures, I suspect.)

Okay.

We agree.

>
>>
>> I simply want adoption of these efforts. Thus, anything that leads to 
>> broader adoption is good. Basing any RDF based spec on a single 
>> notation via MUST always leads to the same adoption-inertia 
>> generating misconceptions.
>>
>
> I don't happen to agree.   Or perhaps I don't understand.

Hopefully my responses above bring clarity in regard to the statement 
above.

>
> Maybe you can explain this adoption-inertia idea in terms of the web's 
> initial common image formats, GIF and JPEG?    Things were very simple 
> in the days of only gif.   But gifs were too darn big, so we needed 
> jpeg.   Fortunately, browsers implemented support for both, so content 
> providers could pick which ever they wanted. There were certainly 
> other options (tiff? xbm? bmp?) but they were not widely implemented 
> in the browsers, so content providers didn't use them.    (I was 
> recently looking at a web page I made in about '93 where for each 
> image I provided links to the jpeg and the gif, because one still 
> couldn't assume everyone could see both.)
>
> Things worked out fairly smoothly and fairly quickly because there was 
> a small number of browser providers.
>
> If there had been 1000 equal size browser vendors, and some went with 
> tiff and some xbm and some bmp, etc, we would have had a real problem.
>
> I think with linked data clients, we're kind of still in that 
> territory.    Without some sense of which formats folks should 
> actually use, they could well become hopelessly fragmented, eg with 
> some people one reading and writing RDF/XML, some only reading/writing 
> Turtle, etc.
>
> Yes, eventually people will figure it out and coalesce around a couple 
> of the most common, but why not save that hassle when there's 
> consensus up front about which those are?
>
>> As per my response to Andrei, for now, adding JSON-LD examples to the 
>> relevant WebID-* documents is a useful tweak that will at the very 
>> least get more JSON oriented developers to look at WebID-*.
>>
>
> I completely agree.    Personally, I'd be fine with giving JSON-LD 
> equal status to Turtle.

Yes, we agree.


>
> Actually, I think probably the best option is mandating publication in 
> JSON-LD and RDFa, in both cases with a syntax that hides the IRIs as 
> much as possible.

I wouldn't go over board re. hiding IRIs. They just need to be understood.

>
> We need to also be clear about how simple and small relying-party code 
> can be.

Yes.

>   Maybe we can say it has to include both a JSON-LD and an RDFa 
> parser, in which case we could say that identity-providers only need 
> to provide one or the other.

Yes!

>
>> We can do better in regards to managing the non technical aspects of 
>> open standards adoption. First step boils down to be more 
>> accommodating of other notations for representing RDF statements. You 
>> can reduce the adoption-inertia generating effects of MUST via lots 
>> of examples that render it moot, so to speak.
>>
>
> (as above)
>

Amen!

Others: I am on a vacation, so my responses might lag a little.

As per usual, there's more than likely a raft of typos in this mail. It 
was too important to ignore :-)

> Yours in service to a more decentralized Web,
>
>        -- Sandro
>
>
>


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this