On the surface JSON and RDF might seem interchangeable (no pun intended ;). Both are formats for exchanging (or “packaging”) data to provide feeds or the response to a say a website or services’ API. Working with RDF now for a while, I’m struck by how seemingly subtle differences between these two “interchange” formats are so significant, and how these differences relate to a larger drift of the web from an inherently decentralized nature to one increasingly centralized.
In JSON, text and URLs are uniformly handled as “strings”
URLs are the basis of RDF’s “graph” oriented structure. In RDF data is represented as “flavored links” between things. These links are often called “triples” as they connect three things in the form (S–P–O) where, in linguists-soaked terms a “subject” is linked by virtue of a “predicate” to an “object”. Predicates are always URLs. Subjects are either URLs or else “temporary” nodes (a provision to allow for some degree of ad hoc structuring), and objects are either URLs or “literal” values (like numbers and strings). Additionally literal values may be qualified with a language code, and have an explicit data type (itself represented by, you guessed it, a URL). Typically data types are those for say dates to be explicitly marked.
While JSON’s beauty lies in it’s simplicity and direct relationship to code, the cost of that generality is that it extends the same limitations of data in code (its detached context of execution, the lack of sharable semantics beyond basic data types) to a networked context. Said another way, JSON is an excellent solution to a relatively easy problem, the cost of which is a shifting of difficult problems elsewhere. As a programmer I admire how JSON cuts through the nonsense of an approach that might claim an inherent superiority to say an XML representation. (If you’ve got a list of numbers, well then a JSON list of numbers is hard to beat). The cost of that “directness” however is that in a networked context, JSON’s generality reinforces practices of distributing data with “inward looking” structures thus making code written to receive and work with this data (from the “outside”) inherently dependent on those particularities. As a consequence, the code is both fragile (it “breaks” when the structure changes) and difficult to combine with other sources (as it’s up to the programmer to bridge any differences in structure).
The differences between JSON and RDF are linked to a larger trend of APIs of web services to drift away from standards-oriented formats (like RSS & Atom) to increasingly “programmer-friendly” JSON (giving you “just what you need”). Significantly, these APIs are also embracing stronger means of “authorizing” developer access (such as via mechanisms like OAUTH) whereby the use of these APIs require entering into a legal agreement between the programmer and the website, where typically the kinds of uses of the data are limited. This, in contrast to the typically open nature of an RSS feed (that tend to be publically accesible as in other web resources) and make no conditions on their use, reflect an increasingly centralizing and normalizing web.