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

On 17 July 2014 15:53, 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)
>

Agree with a lot of these points, but let me add:

There are more WebIDs out there than any other identity system, since
facebook serve WebID.

WebID + TLS is a nice experiment and useful as a proof of concept, and very
useful for testing, but I dont think anyone ever expected it to get a
billion users.

We need to do a lot more work on interoperabilty and demos before people
can really see the value added.


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