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

Watching it all - Sandro - nice email.  I equally agree with much of what you’ve said. 

I think also, the privacy vocab. is missing for data. I do think their is a difference between what is required for e-commerce, and what is required for ID in relation to user-names. 

http://www.verisigninc.com/en_US/innovation/verisign-labs/speakers-series/evolution-of-internet/index.xhtml 

at about 23 minutes identity comes up.

I’ve posted about a creative commons like privacy ontology (reuse, sovereignty, privacy, accessibility, security, perhaps also - storage: permission / cache / store / forget) which i think in the world of linked-data, is also an important session / auth related function...

TimH.

On 17 Jul 2014, at 11:53 pm, Sandro Hawke <sandro@w3.org> 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.
> 
> 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.
> 
> The lack of clarity over what WebID actually is and WebID-TLS actually is, those form a huge barrier.
> 
> 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.
> 
> httpRange-14 (and the resulting HashURIs) is a huge, huge barrier.
> 
> The reliance on RDF details and FOAF details is a huge barrier. JSON-LD and a new vocabulary (not foaf) could address this.
> 
> 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.  That will probably require bending on all of the above.   If that can be achieved, then there might be a chance for WebID.
> 
>> 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.    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'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.)
> 
>> 
>> 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.
> 
> 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.
> 
> 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.
> 
> We need to also be clear about how simple and small relying-party code can be.    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.
> 
>> 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)
> 
> Yours in service to a more decentralized Web,
> 
>       -- Sandro
> 
>