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

On 17 July 2014 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.


They sure do!  Not just programmers, we use this all the time.

"What is the connotation of that metaphorical image? But when you
understand a metaphor—you know, just high school grammar language—when you
interpret the metaphor in terms of the denotation instead of the
connotation, you’ve lost the message. That’s like going into a restaurant
and reading the menu and deciding what you’re going to eat, and you eat
that part of the menu. The menu is a reference to something transcendent of
that piece of paper."

--Joseph Campbell

If you confuse connotation and denotation you're going to be in a whole
world of confusion.


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

Java does a good job of hiding pointers, but C does not.  Pointers are the
essence of all programming languages.


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

Vanity URIs are the dark side.  The web is predicated on separating the
medium from the content.  (Mis) Using vanity URIs which is the "cool kid"
trend you'll be able to tread water on the web, that's about it.  You'll
never be able to take the web to its full potential.  Look at train smash
after train smash in this area.  The axiom of opacity is one of the hardest.


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


Show me any coder that is comfortable with pointers.  It's hard stuff.
Timbl refers to URIs as pointers, it's no coincidence.  The biggest problem
with the web is that, unlike C, it doesnt crash when you misuse pointers. :)

I liked the # pattern for a while, but timbl pointed out that it breaks
qnames.

Remember when people didnt understand @ ?

http://www.youtube.com/watch?v=JUs7iG1mNjI


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