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

On 17 July 2014 17:00, Seth Russell <russell.seth@gmail.com> wrote:

> How does "facebook serve WebID" ?   How does G+ not serve WebID ?
>

graph.facebook.com complies with the webid spec, and servers turtle/rdf

we actually had a promise from google that they would serve FOAF, but we're
still looking forward to seeing that implemented :)


>
> seth
>
> the #toothlessfoodie <https://plus.google.com/s/%23toothlessfoodie>
> Facebook: facebook.com/russell.seth
> Blog: fastblogit.com/seth/
> Talking products: www.speaktomecatalog.com
>
>
> On Thu, Jul 17, 2014 at 7:40 AM, Melvin Carvalho <melvincarvalho@gmail.com
> > wrote:
>
>>
>>
>>
>> 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
>>>
>>>
>>>
>>
>