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

On 7/17/14 11:00 AM, Seth Russell wrote:
> How does "facebook serve WebID" ?   How does G+ not serve WebID ?

A WebID is an HTTP URI that denotes an Agent. Every Web hosted Social 
Media service or network denotes it members using a WebID.

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


-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this

Received on Thursday, 17 July 2014 18:03:33 UTC