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

On July 20, 2014 2:42:17 AM EDT, "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.
>
>
>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

I'm confused by this last point, Henry.   I'd like a decentralized authentication system that works for all web apps, not just those built around linked data.  My critique of WebID is from that angle, but now I'm wondering if you share that goal.

(I am okay with requiring relying parties to run JavaScript in the browser; the system doesn't have to work for web apps that are entirely server-side.)

    - Sandro

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

Received on Sunday, 20 July 2014 11:26:42 UTC