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

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

Received on Thursday, 17 July 2014 19:19:40 UTC