Re: [JSON] the simple pivotal choice

Nathan,

(On cell phone, sorry for the short reply.)

I see some issues if there are different flavors of RDF JSON
serializations (see different thread), but wanted to ask for
clarification first: how do you explain to someone who is happy to
have copied and pasted, say, the OpenGraph triples onto their
homepage, that a) there's something like "RDF goggles", and b) how
does the world look like if you put them on? Honest question.

Thanks,
Tom

Thank God not sent from a BlackBerry, but from my iPhone

On 09.03.2011, at 23:48, Nathan <nathan@webr3.org> wrote:

> 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:
>
>  http://dev.twitter.com/doc/get/users/lookup
>
> 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.
>
> Best,
>
> Nathan
>

Received on Wednesday, 9 March 2011 23:40:12 UTC