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

It seems to me that "serving" WebID is half of the problem.  How about
accepting setup and updates via WebID data ?   Me thinks that without the
total interaction, the process is kind of just academic.

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 8:09 AM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

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