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

Re: [JSON] PROPOSAL: Syntax structure should be object-based

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 16 Mar 2011 20:29:02 -0400
Message-ID: <4D8155CE.7070404@digitalbazaar.com>
To: RDF Working Group <public-rdf-wg@w3.org>
On 03/16/2011 06:25 PM, Andy Seaborne wrote:
>>> 1. It appears to me that the goal of the RDF-in-JSON approach as
>>> championed by Manu is not to serialize an RDF graph in a JSON
>>> syntax, 

That's not accurate - serializing an RDF graph in a JSON syntax is
specifically a goal for JSON-LD (and has been achieved).

>>> but to standardize a system of JSON conventions that allow
>>> parsing of the output of existing JSON APIs (perhaps with small
>>> modifications) as RDF.

Yes, this is also a goal.

> I agree.
> Sometimes it sounds more like "GRDDL for JSON".  The mapping isn't
> universal - the generation of IRIs from data that has sufficiently
> unique keys is application dependent, for example.

Yes, the mapping can't be universal. However, not because the unique
keys are application dependent (you can always specify a default
vocabulary to map each unknown unique key to... you could even say that
you could use bnodes as predicates here). In RDFa, these unique keys can
be given a prefix via @vocab... RDF in JSON could have the same
mechanism that basically states: "If you can't find a mapping for a key,
append it to this URI." For example:

   "#": { "@vocab": "http://example.org/foo#" },
   "sparqly": "Andy Seaborne",

The above would create the following triple:

_:bnode1 <http://example.org/foo#sparqly> "Andy Seaborne" .

There are some constructs that JSON supports that are not representable
in RDF, and those are the mappings that we cannot do. For example plain
literals as predicates, or plain literals as subjects, etc. Until RDF
supports those concepts, we can't represent everything that JSON can.

There are also issues when metadata is assumed for particular data
structures, such as lat/long. Here's how Twitter does coordinates, for

"coordinates": [

You can't map the /meaning/ of that to RDF without some sort of
programmatic munging - that is, you don't know which one is latitude and
which one is longitude without checking Twitter's documentation.

So, there is nuance here - we /cannot/ map everything in JSON to RDF,
but we /can/ map everything in RDF to JSON. The JSON-LD spec can
serialize every RDF concept, so we don't need to look at this as an all
or nothing endeavor.

That's why I asked Lee the following question:

Would your organization use something that looked like this?

   {"__subject": "<http://example.org>",
    "<http://vocabs.example.org/v1#predicate>": "Foo 1"},
   {"__subject": "<http://example.org>",
    "<http://vocabs.example.org/v1#predicate2>": "Foo 2"},

That's a slight variation on the triple-based model and it is supported
in JSON-LD. That is, we can express both the triple-based model and the
object-based model in JSON-LD, or RDFj, or JSN3.

> Then the phrase "RDF in JSON" seems the wrong way round.  It's "JSON as
> RDF".

I don't think that's accurate. There are several serializations on the
table that are capable of doing both "RDF in JSON" /and/ "JSON as RDF".
It doesn't have to be one or the other.

> PROPOSAL: The RDF Working Group JSON Task Force will work on way of
> mapping typical existing JSON data objects into a form that can be
> interpreted as RDF.

+1 to that

What about this one?

PROPOSAL: The RDF Working Group JSON Task Force will work on a way to
express all RDF concepts in JSON in a way that is compatible with the
PROPOSAL above. That is, it is compatible with the way of mapping
typical existing JSON data objects into a form that can be interpreted
as RDF.

I know that we can accomplish both proposals because those two design
goals were a part of JSON-LD from day one and they are supported by the
current specification.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
Received on Thursday, 17 March 2011 00:29:32 UTC

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