Re: JSON Emergency Brake

Thomas,

Your point seems to be: We should stop working on RDF/JSON, because JavaScript developers who are already familiar with JSON will look at it and not like it.

The target audience of RDF/JSON is not JavaScript developers who are already familiar with JSON. It is RDF developers who work in JavaScript. Nothing more, nothing less. It's a format designed to fill a small but concrete niche. This has been said in our discussions over and over again, so it's nothing new.

You are saying that the wrong people might look at RDF/JSON and they might think it's meant for them. I think the correct response to that is *not* to stop working on RDF/JSON, but to make sure that the messaging around the format does not create the impression that it's targeted at them.

One step towards avoiding that impression would be to rename it, removing JSON from the name.

Best,
Richard



On 23 Aug 2011, at 16:25, Thomas Steiner wrote:

> Dear all,(*)
> 
> ===
> TL;DR: in my humble opinion, we should not continue with RDF/JSON, but
> fully focus on JSON-LD even if it might take longer, as JSON-LD feels
> like  JSON, whereas RDF/JSON feels like RDF in a JSON camouflage.
> ===
> 
> First and foremost, I want to apologize for whatever toes I step on
> with this email. This email is in no way meant as an offense to the
> individuals and companies involved, and I want to highlight that I'm
> in the comfortable - but also unthankful - position of the (hopefully)
> neutral observer, who enters the discussion when all the foundational
> work has already been done. By this foundational work I mean RDF/JSON
> [1] by Talis, and JSON-LD [2] by PaySwarm (forgive the simplification
> of not mentioning persons, but companies). Thanks! It's excellent! I
> could not have done it.
> 
> Now, in ISSUE-2 [3], we came to the conclusion to "(1) Incubate on
> something like JSON-LD, (2) make a REC on something like Talis
> RDF/JSON [...]". The more and more I look at both specs, the more and
> more I feel like the resolution we agreed on for ISSUE-2 was wrong.
> Following ACTION-38 [4] where Ivan had asked me to become a co-editor
> on the to-be-REC'ed Talis RDF/JSON that I accepted, the proposed
> workflow was Ian to commit a first draft of the document ([1]
> effectively), that could then be discussed.
> 
> I have fully re-read both specs, but all honestly, the actual
> eye-openers for me were a blog post [5] by Alexandre Passant and a
> tweet by Christopher Gutteridge [6]. JSON-LD is(**) about objects,
> simple default assumptions, elegancy, and developers in mind, whereas
> RDF/JSON seems to be created with the premise to carry all the
> expressiveness of RDF over to JSON, whatever the cost might be. Coming
> more from a JavaScript camp than from an RDF camp myself, this feels
> wrong. Of course I can see where RDF/JSON came from, and it completely
> makes sense from that perspective. In the next paragraph, I explain
> why.
> 
> Let me try to explain my main concerns with a bad metaphor (there's a
> long tradition of those...). Web developers, JavaScript people, those
> who speak JSON natively, are the cool kids. We are the detached youth
> workers [7] who put on an adidas hoodie, read up on street slang on
> the Internet, and try to behave just like the cool kids. We serve them
> RDF/JSON (yes, yes, yo, homie), but we will probably fail. They see
> through our plan, we risk to get laughed at. RDF/JSON just does not
> feel natural to them, and this now, at a critical point, where
> semantics are kind of back in the section "cool" of the news. Of
> course I'm referring to schema.org(***). If we get a syntax REC out
> now that does not feel native to the cool kids (even if we incubate on
> something better [3]), we risk on losing traction. I have asked some
> Google JavaScript people for advise, and they feel "at home" in
> JSON-LD. It is the language they speak. I feel at home in JSON-LD.
> Others do [8, 9], [10]. The Twitter feedback on the RDF/JSON draft
> release [1] is relatively critical [11].
> 
> Now, those are tough claims and vague feelings, but I considered them
> important enough to write this email. Apologies again to whomever toes
> I have stepped on. My concrete proposition is: we refrain from working
> further on the RDF/JSON REC, and fully focus on JSON-LD instead. I
> would also like to back out of being an editor of [1], as I have not
> done anything at all on that spec yet, and because I feel it is wrong
> at this point in time, as hopefully explained in this email. While I
> have done very, very limited amounts of work on JSON-LD (just
> following the discussion mainly), I am happy to serve as an editor
> thereof in fulfillment of what I agreed on in ACTION-38 [4], but it
> feels like adorning myself with borrowed plumes, as the German saying
> goes, and very much undeserved. Maybe we can discuss this during one
> of the next RDF WG meetings, maybe even in a joint RDF - RDFa WG
> meeting.
> 
> In the hope of not having hurt too many feelings, but rather started a
> productive discussion instead.
> 
> Best,
> Tom
> 
> [1] http://dvcs.w3.org/hg/rdf/raw-file/default/rdf-json/index.html
> [2] http://json-ld.org/spec/latest/
> [3] http://www.w3.org/2011/rdf-wg/track/issues/2
> [4] http://www.w3.org/2011/rdf-wg/track/actions/38
> [5] http://blog.seevl.net/2011/08/18/about-json-ld-and-content-negotiation/
> [6] http://twitter.com/cgutteridge/status/105894098023620608
> [7] http://en.wikipedia.org/wiki/Youth_work#Detached_youth_work
> [8] http://twitter.com/orlin/status/104926442843934721
> [9] http://twitter.com/orlin/status/104797459292753920 (note the
> hashtag #unsemanticweblike)
> [10] http://twitter.com/terraces/status/105066802740080640
> [11] https://twitter.com/#!/search/realtime/rdf%20json%20-RT
> (realtime, might have changed when you click the link)
> 
> (*) Full disclaimer: I have had this email be ACK'ed off-list by Ian
> Davis, Manu Sporny, Guus Schreiber, and Ivan Herman before sending it
> on-list now.
> 
> (**) When I write "is", "seems", etc., basically all verbs, all this
> reflects my impression that I personally got. You can add an "IMHO"
> suffix to each sentence. The spec authors will probably disagree with
> some assumptions.
> 
> (***) I was not at all involved in any of the schema.org discussions,
> plannings, the concept at all. All what I'm writing here on this
> topic, I do it with my Google hat off.
> 
> --
> Thomas Steiner, Research Scientist, Google Inc.
> http://blog.tomayac.com, http://twitter.com/tomayac
>

Received on Tuesday, 23 August 2011 15:44:49 UTC