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

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
 

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 06:43:50 UTC