Re: The tone of the "JSON-LD vs. RDF" debate (was re: Sub-issue on the re-definition of Linked Data)

Manu, I won't be able to be on the call tomorrow, but I will add my 2c worth here.

On Jun 10, 2013, at 9:29 PM, Manu Sporny wrote:

> On 06/10/2013 06:09 PM, David Booth wrote:
>> There are only a few outliers, and most of them seem to be members of
>> the JSON-LD group who: (a) clearly have an ulterior motive in 
>> re-defining the term "Linked Data";
> 
> Let's step back from this particular discussion for a second. I hope
> that all of us can get some perspective by doing so.
> 
> I've noticed the tone of this thread go from helpful to personal in the
> last few responses. That's not going to help the various parties
> involved get to any sort of compromise.
> 
> I don't think it helps to start accusing others of having "ulterior
> motive"s for a few reasons:
> 
> 1. It erodes the environment of good faith that we strive to create
>   across all W3C groups.

IMO, that was already eroded by the JSON-LD's group's stance towards RDF. I have tried to refrain from ad hominem comments, but I have to say, it is very hard not to see some rather selfish motives in such a blatant exercise in confabulation and what would in academic circles be treated as plagiarism. 

> 2. There is a negative connotation attached with that phrase and it
>   puts people on the defensive.
> 3. We're not mind readers, so we shouldn't try to predict intent, and
> 4. We all want the RDF data model to succeed.
> 
> In general, we all want the same thing - for RDF to succeed in a much
> bigger way than it has to date.

> Let's review what we have so far:
> 
> 1. JSON-LD has just been integrated into products (GMail, Google
>   Search, and Google Now) that are being used by 425+ million people.
> 2. RDFa is being used on hundreds of thousands of domains.
> 3. The primary editors, authors, members, and implementors of those
>   technologies are involved in the RDF WG, RDFa WG, and JSON-LD CG.
> 
> Any argument that claims that the people working on these technologies
> are not also fighting for RDF are unconvincing. Additionally, I think
> that the people working on these technologies have a very keen insight
> into what works and what doesn't when it comes to getting adoption. They
> have a track record to back it up.
> 
> One of the biggest problems that we faced with RDFa adoption were the
> letters R, D, and F.

I see this stated many times, but I see very little actual *evidence* for it. I also see some evidence in the other direction, eg non-RDF/Semantic Web people asking why the JSON-LD data model is so very similar to the RDF model and being puzzled by why they have to keep them separate (but presuming that they must be distinct in some way because otherwise, surely, the specs would mention that they are virtually indistinguishable, and they don't.)

> It's not an issue in the RDF / Semantic Web groups.
> It is a big issue outside of those groups. It's a big issue because
> "RDF" has a horribly steep learning curve for Web developers that have
> to keep umpteen technologies in their head as they try to create their
> products. It's not the data model that's the problem, it's everything
> else that is lumped on top. It's hard for a web developer to sort out
> what the necessary parts of the stack are, so they tend to go all in and
> get overwhelmed as a result.

Fine, then keep the data model cleanly separated from the rest of the RDF stack. But that is not an argument for pretending that its not the same data model. If anything, I would guess that for the hypothetical Web developer to discover that RDF really is this easy might be something of a relief. Whereas if what he has learned is that JSON-LD is simple, but RDF, that other thing, is still a black hole of unfathomable complexity, he not only hasn't mastered RDF, he has been misinformed about an important insight. 

> 
> The litmus test for most Web technologies that have high adoption rates
> is "can I pick it up in an afternoon and do something cool with it?". If
> the answer is "no", then the chances of it succeeding are far worse than
> if you can answer the question above in the affirmative.

I see people doing amazing things with RDF in a couple of days at the SW meetings. Does that count?

> 
> JSON-LD takes these two general insights and attempts to organize the
> spec language around summarizing the good parts of what we're trying to
> achieve as a community without overloading the developer with
> unnecessary information.

You are describing a tutorial, not a specification document. Don't get them muddled with one another, they have different purposes. 

> 
> If we introduce RDF too early in that document, we have three potential
> negative outcomes:
> 
> 1. Readers will feel overwhelmed that they have to learn yet another
> technology to understand JSON-LD.
> 2. Readers will go off and read about RDF, which they shouldn't have to
> do to do something useful with the technology.
> 3. Readers will short-cut the decision to use the technology based on
> the LARGE body of mis-information out there about RDF.

If the third is a serious problem (which I doubt) then it is one that we are going to have to live with in the short term and which will go away by itself in time. The first two can be handled by deft editorial wording and quick reassurances, along the lines of "No knowledge of the RDF spec documents is necessary in order to use JSON-LD."

But my main concern is not about how early the RDF connection is spelled out, but that it does get stated clearly and unambiguously and normatively in the specification document *somewhere*. This is after all a *standards specification*, not a propaganda or advertising effort. (Or a "for dummies" tutorial.) It needs to state the facts clearly and unambiguously, and to clearly state the relationships to other standards. To re-define the RDF data model, calling it by another name, and not stating that it is a re-statement of the RDF abstract graph syntax, is just wrong. It is *deliberately* misleading; it is in fact a form of lying. (See http://en.wikipedia.org/wiki/Economy_with_the_truth.)  And that is just not acceptable in a W3C Recommendation, IMO, no matter how well-intentioned the motives are for doing it. 

> 
> Including RDF that early in the document only has one positive outcome:
> 
> 1. We will be aligned with TimBL's definition of Linked Data (which has
> been demonstrated to be controversial - case in point: this thread and
> the increasingly hostile tone of the debate).

It has others. It might tempt some ambitious developers to actually read the RDF specs (in their new, slimmed-down and easier-to-digest form :-) and do some more ambitious things with it, such as get involved with other semantic technologies, or even invent new ones. It also might reassure some other developers that RDF isn't so hard after all. And, chiefly, it will do what specifications are intended to do, which is to act as an objective and accurate reference for a number of years into the future, when all these damn silly petty reactions of "typical" developers are of no more interest than opinions over the merits of EBCDIC. 

> If there is an ulterior motive, it is to get RDF into the hands of as
> many people as possible... which is a common goal for all of us.

If people are using RDF without knowing that they are using RDF, I'm not so sure that is a desirable outcome. Its certainly not my goal.

Pat


> It would be good if we can get the tone of the conversation centered
> around that assumption and some solid proposals. Your last proposal was
> good. It was -1'ed for reasons given, but you should also keep in mind
> that we integrated some of your earlier feedback as well and have a very
> good track record of integrating feedback from the RDF WG when there is
> consensus around that feedback.
> 
> If any of you that feel strongly about this have the time to join the
> JSON-LD call tomorrow, please do. I think we could come to an
> understanding over the phone. Dial-in details are here:
> 
> http://json-ld.org/minutes/
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Meritora - Web payments commercial launch
> http://blog.meritora.com/launch/
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 11 June 2013 07:08:36 UTC