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

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

> It seems to me that "serving" WebID is half of the problem.  How about
> accepting setup and updates via WebID data ?
>

Yes, that would be even better!

Nevertheless is means you can friend someone in facebook, even if you can
*definitive* friend someone the other way, you can certainly make that
claim.  It also gives a permanent URL to tie key value pairs to.


> Me thinks that without the total interaction, the process is kind of just
> academic.
>

Need to show social media companies why that will be in their advantage.  I
would not have initially expected facebook to be the first people to adopt
this technology, but they've surprised us (in a positive way) with the work
they've done, so I would not rule out further integration.


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