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

On 2014-07-17 17:09, Melvin Carvalho wrote:
>
>
>
> On 17 July 2014 17:00, Seth Russell <russell.seth@gmail.com <mailto:russell.seth@gmail.com>> wrote:
>
>     How does "facebook serve WebID" ?   How does G+ not serve WebID ?
>
>
> graph.facebook.com <http://graph.facebook.com> complies with the webid spec, and servers turtle/rdf

I don't see reuse/adoption of a particular ZYZ data-structure in a centralized service like Facebook as a sign of "XYZ won".

The core problem for WebID remains which is the authentication part which has very limited adoption and with U2F is likely to die completely.
Combing WebID with U2F is possible but creates a poor user-experience and is thus a dead-end.

The only way to save WebID is to fix the original concept but that requires a bit more than a bunch of guys (where are the girls BTW?) with strong opinions.  Since such an endevour wouldn't (initially at least) get any support from the browser-vendors it is clearly out of scope for W3C.

Anders


>
> 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 <http://facebook.com/russell.seth>
>     Blog: fastblogit.com/seth/ <http://fastblogit.com/seth/>
>     Talking products: www.speaktomecatalog.com <http://www.speaktomecatalog.com>
>
>
>     On Thu, Jul 17, 2014 at 7:40 AM, Melvin Carvalho <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>
>
>
>
>         On 17 July 2014 15:53, Sandro Hawke <sandro@w3.org <mailto: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
>
>
>
>
>