Re: Turtle and JSON-LD Matter

On 7/16/14 12:23 PM, Sandro Hawke wrote:
> On 07/16/2014 12:06 PM, Kingsley Idehen wrote:
>> On 7/16/14 10:23 AM, Ruben Verborgh wrote:
>>> Hi Kingsley,
>>>
>>>> >Is there any reason why Turtle and JSON-LD cannot be on equal 
>>>> footing in regards to the WebID spec?
>>>> >
>>>> >There's no reason why WebID-Profile documents MUST be comprised of 
>>>> RDF content in Turtle Notation.
>>> In general, several W3C specs demand the presence of a specific RDF 
>>> representation.
>>> (Linked Data Platform, R2RML, …)
>>>
>>> Seems indeed quite contradictory… why did we invent RDF in the first 
>>> place?:-)
>>
>> Exactly the question that hits me in the head every time I look at an 
>> RDF language (system of signs, syntax, and semantics) based spec that 
>> prefers a specific notation via MUST.
>>
>>
>>>
>>> On the other hand, I see some necessity for interoperability, but 
>>> still…
>>
>> Interoperability isn't lost via Turtle and JSON-LD support in WebID-* 
>> .  In fact, we increase interoperability via proper use of RDF and 
>> AWWW  :-)
>>
>>
>
> Imagine we have six different servers.  Each of them is publishing RDF 
> in a W3C Recommended way.
> Server 1 provides only Turtle.  Server 2 provides only RDF/XML. Server 
> 3 provides only n-quads.  Server 4 provides only JSON-LD. Server 5 
> provides only RDFa.    And just for good measure, server 6 provides 
> only a custom format, but includes a transformation to RDF/XML via GRDDL.

And server 7 simply uses "Link:" relations in HTTP for RDF triples, and 
server 8 that publishes HTML documents with Microdata based RDF 
tripoles, and server 9  that publishes HTML documents with RDFa based 
triples, and server 10 that publishes HTML documents with POSH (Plain 
Old Semantic HTML) based triples, etc..

>
> In this world, everyone is following W3C Recommendations, but now 
> every client has to implement 5 RDF parsers plus a GRDDL 
> transformation engine.

GRDDL (which also came from the W3C, all examples XML based etc..), plus 
the other servers in my comments above magnify the problem. Who is the 
source of these notations? The multiplicity of notations, and your 
characterization are all part of the problem, I must painfully assert.

>
> To me that seems like a huge blow to interoperability.

Quite the contrary. You are leaving out the fundamental fact that HTTP 
URIs is an integral part of AWWW and that content-negotiation is an HTTP 
feature. That said, I don't even see content-negotiation as the solution 
to the problem, its actually secondary.

>   How many clients are really going to do that, and do it properly?

Clients request text/html from servers, most of the time. None of them 
do what you characterize as "behaving properly" .

Bearing in mind the reality above, why would any RDF based spec use 
anything other than an HTML based notation as its mandatory notation? At 
the very least, all HTML browsers know how to fetch and process HTML.

> If instead, everyone just published in Turtle, then clients would only 
> need to know how to read Turtle. 

I have written more Turtle than most, by hand. I think Turtle is by far 
the best notation for RDF, but none of that would make me support the 
position above.

HTML user agents are not going to be implementing Turtle parsers for 
RDF. They are going to work with HTML based notations and JSON-LD (due 
to the ubiquity of Javascript and the dominance of programmers in this 
realm).

It took Google nano seconds (relatively speaking) and zero evangelism 
from JSON-LD supporters to adopt JSON-LD. Whether we like it or not, 
what Google does matters, they provide the most widely used search 
engine on the planet. The World Wide Web modulo Google Search is nearly 
as mercurial to appreciate (value proposition wise)  as RDF.

> That would make it so much easier to join the fun.

Sorry, it won't. It hasn't happened so far, and this isn't how this will 
come to fruition. Turtle's real power emerges when relationships, 
relations, and semantics are understood. That only happens when RDF is 
properly understood, and after 13+ years, it is clear that the current 
approach doesn't work i.e., stuffing Turtle (or RDF/XML in the past) 
into RDF based specs behind a MUST.

>
> Within LDP, the current compromise is every server MUST handle Turtle 
> (so clients can get by knowing only Turtle), and every server SHOULD 
> ALSO handle JSON-LD (so most clients can probably get by knowing only 
> JSON-LD).     Had JSON-LD been adopted slightly sooner, we probably 
> would have said MUST on both.

Yes, and when talking to implementers, we can effectively simulate a 
MUST for both, by giving both equal and balanced coverage in examples. 
Likewise, encouraging implementers to support both.

>
> But LDP assumes a fairly smart server which knows about RDF.

An RDF notation?
RDF the Language for structured data representation endowed with human 
and machine comprehensible relation semantics?
Which RDF?
>    To me that seems like rather a high burden for WebID publishers.

How many WebID publishers are there today, after all of these years?

How many WebID-TLS processors are there, after all of these years?


>   If you want MUST on both, then you're forcing everyone who's doing 
> this by hand to be able to do Con-Neg and to know both Turtle and 
> JSON-LD.

No, it simply means that two distinct profiles will build solutions, and 
in doing so they'll come to appreciate RDF and AWWW much more as they 
hit issues with interoperability. Basically, you will have far more 
implementations that exist today, and interoperability will be the focal 
point across implementations.

>   Seems kind of a burden to me.

Not to me, I really disagree with this worldview, profoundly :-)

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

>
>       -- Sandro
>
>
>
>


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