W3C home > Mailing lists > Public > public-rdf-wg@w3.org > March 2011

[JSON] the simple pivotal choice

From: Nathan <nathan@webr3.org>
Date: Wed, 09 Mar 2011 22:45:31 +0000
Message-ID: <4D78030B.5020604@webr3.org>
To: RDF WG <public-rdf-wg@w3.org>
Hi All,

[In some ways this is a reword of an earlier post]

RDF can be seen as having three core factors:
- Triple/Node/Graph based Data Model
- Shared Vocabularies
- URIs as Identifiers

and there are two principal ways of exposing "RDF" over the wire:
- Use an RDF data format (universal data bus)
- Use a non-RDF data model / format, and offer a way to view it as RDF 
(bootstrapped data transformation)

JSON is heavily used to provide "plain old data objects" over the wire, 
for example:


Many developers have become accustomed to this, and almost expect this 
to be the norm when dealing with JSON. The ability to work with the data 
without any custom tooling, for example:

   obj = get(uri)
   print( obj.status.text );

At this point in the process, we have a core decision to make:

1: Is our approach going to be offer a way to bootstrap and transform 
these plain old data objects in to RDF?
  + will allow developers to work with data without RDF tooling, but it 
won't be RDF unless the developer puts their RDF goggles on.
  + will allow bootstrapping of many existing APIs and data sources, 
without them breaking bc.
  - not RDF on the wire

2: Or, is our approach going to be to provide a JSON serialization of RDF?
  + it's RDF.
  + builds on a lightweight open standard which is very well supported 
with native parsing.
  - typically requires RDF tooling to work with.
  - may not be as human readable as typical JSON data in the wild.

I believe that making this choice early on, or determining that we need 
both, will serve us well moving forwards. For example if we choose one, 
then with the territory comes some core constraints on what we do, 
basically we can't change the way people use JSON and must work on 
providing a standardized way of transforming JSON to RDF. If we choose 
two, then we're conceding that people will typically require tooling to 
use the data and thus will need to focus on making trade-offs between 
bytesize, processing complexity, and the level of human readability.

Personally, I'm happy to work on and use either or both, and can see use 
cases for both.

The only concern I do have is us trying to do something in the middle 
and getting another RDF/XML, to me it's a no-grey area, either focus on 
providing a way to map plain old data objects to RDF, or focus on a 
lightweight RDF in JSON data interchange format. You either need RDF 
tooling to use it, or not (and if you do need tooling, why not the same 
tooling you use for turtle and rdf/xml).

Ideally, I'd love to see a clear vote on this choice happen early on, so 
that we can focus early and produce something great.


Received on Wednesday, 9 March 2011 22:46:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:04 UTC