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

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

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