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

On 7/17/14 3:19 PM, Sandro Hawke wrote:
>>>
>>> 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.

True, and that's one source of many problems. Basically, declarative vs 
imperative programming [1].

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

The aesthetics of a WebID shouldn't matter. The HTTP URI should simply 
resolve to something useful, in the relevant usage context. In an HTML 
document, you won't even see 
<http://kingsley.idehen.net/dataspace/person/kidehen#this> . Thus, 
existing patterns for context menu interaction with anchors apply i.e., 
when require, you click or copy and paste said HTTP URI.


>
> I think we'd have much more success with WebIDs like: 
> kingsley.idehen.net.

No.

The aesthetics don't matter.
<a 
href="http://kingsley.idehen.net/dataspace/person/kidehen#this">Kingsley 
Idehen</a> is what will exist in an HTML document (which can be 
generated by the server).

Web have 50 Billion+ triples in the LOD cloud cache we maintain, the 
default interaction UI never displays raw HTTP URIs by default. It makes 
use of annotation property based relations such as rdfs:label, 
skos:prefLabel, skos:altLabel etc..

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

As per my comments above, this is the kind of premature optimization 
that leads to problems. Aesthetics aren't the issue, raw URI visibility 
is handled at a different level, by default <a/> in HTML.

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

Yes, but again, that's all about aesthetics which isn't the big problem.

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

Perceived implementation complexity is a consequence of infrastructure 
components confusion. For instance, we now have Dropbox, Google Drive, 
OnDrives etc. offering storage services that offer at least 2GB of 
storage at $0.00. They all offer APIs too. Net effect, making Identity 
Cards today is much easier than it was a few years ago since storage and 
application level services are now loosely decoupled.

Folks can save HTML+POSH, HTML+Microdata, HTML+RDFa, HTML+Turtle, 
HTML+JSON-LD, Turtle, JSON-LD etc.. based content to documents are 
locations provides by the services mentioned above. Apache (or other 
HTTP server) configuration capability and costs are no longer part of 
the deal.

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

Yes.


Links:

[1] http://latentflip.com/imperative-vs-declarative/ -- Imperative vs 
Declarative programming

[2] http://youid.openlinksw.com -- generates Identity Cards hosted on 
the likes of Dropbox, OneDrive, Google Drive etc.. (making them Identity 
Providers where Identity management is controlled by the user, not the 
storage service provider).

-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this