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

On 20 July 2014 08:42, henry.story@bblfish.net <henry.story@bblfish.net>
wrote:

> On the Turtle discussion: I completely agree with Sandro's explanation
> for why one should restrict the syntaxes to a MUST for Turtle. Anyone
> is free to add more syntaxes to their servers, including JSON-LD. Later
> we can revise this. Not having mandatory syntax lead to client complexity
> that would create barriers for adoption. ( I will add a JSON-LD Parser
> as soon as I find one to rww-play )
>
> As to Sandro's points about WebID+TLS's lack of adoption, this has more to
> do in my view with lack of good applications being build. myprofile.eu
> currently WebID-Auth does not work for example. WebID Auth really comes
> into its own with systems like LDP and Web Access control, and these are
> just being finalised. So instead of wasting time discussing lack of
> adoption,
> I'd say just take LDP + WebID + WAC and write some cool decentralised apps.
>
> The rest of Sandro's arguments about hash uri's are just waste of time
> arguments.
> - I never had problems explaining this to developers, and getting
> very good understanding. If you explain it correctly as in the
> diagram its easy.
> - The WebID URIs are not meant to be viewed or written by end-user.
>   They go into certificates ( TLS or JSON LD ones when they come ) and
>   are linked to by other profiles. Users just click buttons. WebID Uris
>   are efficient _and_ user friendly because no user needs to handle the
> URIs.
>

Nothing wrong with exposing the URI to the end user, or to a developer,
imho.  This is analogous to having a URL in the browser address bar.  I
would argue that you could remove the address bar in the browser, for a
simpler user experience, but that it would probably be a mistake.


>
>
> The problem is that developing good LinkedData client apps is difficult. It
> requires some excellent client side JS libraries to be developed that deal
> with asynchronous processing, requires quad storage on the client, partial
> downloads
> of graphs, and many other things, as I discovered working with my
> ex-startup
> in Paris. This can be made easy by developing good client side libraries.
> Which
> is why we are working on this now
>
>   So the reason WebID has lack of adoption is that it requires one to build
> LinkedData apps, and few people know how to do this, in a way that is
> appealing,
> useful, beautiful and sexy.
>
>         Henry
>
>
> On 17 Jul 2014, at 21:19, Sandro Hawke <sandro@w3.org> wrote:
>
> > On 07/17/2014 02:01 PM, Kingsley Idehen wrote:
> >> On 7/17/14 9:53 AM, Sandro Hawke 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.
> >>
> >> As per usual, my response is fundamentally driven by my belief in the
> absolute necessity of decentralized identity management that scales to the
> World Wide Web.
> >>
> >>>
> >>> 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.
> >>
> >> I have provided examples [1] of how the client TLS CCA issue is
> alleviated i.e., showing how one can address most of the problem in a
> manner that's easier to explain to end-users. At this point in time, the
> following browsers are the only vectors of the TLS CCA UX issue:
> >>
> >> 1. Google Chrome
> >> 2. Opera.
> >>
> >> The following browsers do not have the TLS CCA UX issue (i.e., you
> don't have to restart your browser to switch identity):
> >>
> >> 1. IE
> >> 2. Safari
> >> 3. Firefox.
> >>
> >> As for the Certificate selection aspect of the overal TLS CCA issue,
> that's where x.509 certificate generators are critical parts of the
> solution. In our case, we developed YouID for iOS and Android to make the
> point. We are even on the verge of releasing an Web Service variant of
> YouID with an HTML UI.
> >>>
> >>> The lack of clarity over what WebID actually is and WebID-TLS actually
> is, those form a huge barrier.
> >>
> >> Yes, and a lot of the time, notation specificity reinforces old
> stereotypes that make dialog impossible with RDF skeptics.
> >>
> >>>
> >>> 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.
> >>
> >> Isn't that very attitude why I am trying to address by requesting equal
> footing for JSON-LD and Turtle?
> >>
> >>>
> >>> httpRange-14 (and the resulting HashURIs) is a huge, huge barrier.
> >>
> >> httpRange-14 like many things that linger around RDF has more to do
> with mangled narratives.
> >>
> >> Words and Terms are old concepts. Name->Address indirection is an old
> concept.
> >>
> >> Denotation and Connotation are old concepts.
> >>
> >
> > But they never occur in normal, mainstream programming.   When does a
> Java programmer, maybe working with SQL, ever think "here are my customer
> identifiers" and "here are my customer record identifiers"?    Never.  They
> have identifiers which they sometimes treat as identifying the customers
> and sometimes treat as identifying the customer records.
> >
> > If I read the WebID spec, it all goes pear shaped when we hit the
> diagram at the beginning of section 4.
> >
> > Instead of requiring a big diagram full of terms from philosophy, the
> relationship between a WebID and a person should be just this: a WebID is a
> URL of a person's profile document, where the profile document includes
> certain machine-readable information.
> >
> >> httpRange-14 is a horrible distraction. Much to really do about zilch.
> IMO.
> >>
> >
> > I see your advertized WebID is "
> http://kingsley.idehen.net/dataspace/person/kidehen#this"
> >
> > To my eye, that's much too long and complicated.
> >
> > I think we'd have much more success with WebIDs like:
> kingsley.idehen.net.
> >
> > (Or maybe kingsley.webid.idehen.net for branding purposes, but I lean
> against that.)
> >
> > That would be understood to be short for https://kingsley.idehen.net/
> >
> > If we really, really have to have the identifier denote the agent
> instead of the agent's profile document, then we should just always append
> "#".    Appending an arbitrary string like "#this" or "#me" or "#i" is
> mindbogglingly bizarre to most coders, in my experience.
> >
> >
> >>>
> >>> The reliance on RDF details and FOAF details is a huge barrier.
> >>
> >> Yes, but we don't really need FOAF.
> >>
> >> We don't need RDF notation specificity.
> >>
> >> We need to bring life to the concept combined with the abstract
> language that is RDF.  Then we have an audience, because the distracting
> notation (so called "concrete syntaxes" ) specificity issues of yore get
> tossed aside.
> >>
> >>> JSON-LD and a new vocabulary (not foaf) could address this.
> >>
> >> Yes, we don't need FOAF specificity at all. There is nothing about a
> profile document that's unique to FOAF bar the fact that its existence
> provides read-to-use terms.
> >>
> >>>
> >>> 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.
> >>
> >> Yes!
> >>
> >> That's achieved by reaching out style gestures. Simple example, give
> JSON-LD and Turtle equal billing. Demonstrate via examples how RDF
> statements can be constructed using a variety of notations:
> >>
> >> 1. POSH -- for the Microformats folks
> >> 2. "Link:" in HTTP -- for the HTTP folks
> >> 3. JSON-LD -- for Javascript Application Developers
> >> 4. HTML+Microdata -- for Web Publishers who are driven by Search Engine
> Vendor initiatives
> >> 5. Turtle -- for Linked Open Data Developers and Users.
> >>
> >
> > As long as we're willing to accept that implementing a Relying-Party is
> now much more complicated, I can live with this.
> >
> >>
> >>> That will probably require bending on all of the above.
> >>
> >> Bend we must!
> >>
> >>>  If that can be achieved, then there might be a chance for WebID.
> >>
> >> Yes for WebID-* or specifically:
> >>
> >> 1. WebID-Profile
> >> 2. WebID-TLS
> >> 3. WebID -- HTTP URI that denotes an Agent.
> >>
> >>
> >>>
> >>>> 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.
> >>
> >> But it doesn't work, as history has demonstrated. That quest is rife
> with bumps that ultimately generate adoption-inertia.
> >>
> >>>  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 see this as document content constructed using a variety of
> notations. Anyway, Turtle and JSON-LD is always better than one or the
> other, at this point in time.
> >>
> >>>
> >>> 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.)
> >>
> >> Okay.
> >>
> >> We agree.
> >>
> >>>
> >>>>
> >>>> 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.
> >>
> >> Hopefully my responses above bring clarity in regard to the statement
> above.
> >>
> >
> > Not entirely, but probably enough for the current purposes.
> >
> >>>
> >>> 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.
> >>
> >> Yes, we agree.
> >>
> >>
> >>>
> >>> 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.
> >>
> >> I wouldn't go over board re. hiding IRIs. They just need to be
> understood.
> >>
> >
> > More than understood, they need to be properly motivated.   Yes, people
> are fine with IRIs, as long as they actually provide some real, observable
> utility.   For example, an IRI for a JSON profile should be fine as long is
> it dereferences to some good documentation.
> >
> >>>
> >>> We need to also be clear about how simple and small relying-party code
> can be.
> >>
> >> Yes.
> >>
> >>>  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.
> >>
> >> Yes!
> >>
> >>>
> >>>> 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)
> >>>
> >>
> >> Amen!
> >>
> >> Others: I am on a vacation, so my responses might lag a little.
> >>
> >> As per usual, there's more than likely a raft of typos in this mail. It
> was too important to ignore :-)
> >>
> >
> > Thanks.    Not quite sure what the next steps are.   Maybe a telecon....
> >
> >        - s
> >
> >
> >>> Yours in service to a more decentralized Web,
> >>>
> >>>       -- Sandro
>
> Social Web Architect
> http://bblfish.net/
>
>
>