Re: Turtle and JSON-LD Matter

On July 16, 2014 7:41:02 PM EDT, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>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 :-)
>

Indeed.    Not much point in replying to the above.    I agree with some bits and disagree with some bits.   Not very relevant to WebID.

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

>>
>>       -- Sandro
>>
>>
>>
>>

Received on Thursday, 17 July 2014 00:01:18 UTC