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

Re: [JSON] A starting point...

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 06 Apr 2011 20:37:27 -0400
Message-ID: <4D9D0747.1090504@digitalbazaar.com>
To: RDF Working Group <public-rdf-wg@w3.org>
On 04/06/2011 05:12 AM, Ivan Herman wrote:
> I need a clarification on Nathan's original email. He writes:
> [[[ when terms from multiple vocabularies are needed it requires
> people to make their own custom vocab which includes aliases to terms
> in other vocabularies. (having a single cachable vocab is lighter for
> network though and easier to maintain) ]]]
> the way I read this is that, if I use, say, dc and foaf in the same
> data, and I decide to use foaf, then I will have to set up, somewhere
> on the Web, a separate vocabulary file that defines the dc terms and,
> I presume, would include a bunch of owl:samePropertyAs to the 'real'
> ones. While this is, theoretically, a working solution, this means
> that RDF/JSON environments will have to understand at least this owl
> term and work their way through it, which is an extra load that no
> other serializations have. I do not believe this is really a good
> idea.

I do not believe that is a good approach either. That is not to say that
it is not a neat idea, but one that requires people to create vocabulary
documents - which is asking too much of developers, imho. In other
words: Don't make me think!

This approach was left out of the latest proposal for that very reason.

> Besides: a major advantage of RDF over other formats is the
> possibility to mix terms from various vocabularies easily. This is
> the main advantage of, say, RDFa over microformats or even microdata;
> loosing this for RDF/JSON seems to go in a direction that makes RDF
> loose its advantage over other data formats...


> I see that Manu has added a @context below which may go into this
> direction.

Yes, that is the reason that @context was introduced.

> Another approach would be to allow predicates to be either simple
> terms or full URI-s.

I only proposed simple terms because that is what JSON developers are
familiar with these days. Having full URIs would be useful as well,
imho, but that's a discussion that we can have later - by logging an
issue against this proposal (support full IRIs as keys in addition to

The latest proposal is attempting to state:

This is what JSON developers are familiar with today:

 * simple terms as object keys
 * no microsyntaxes
 * URLs, text and numbers as values
 * nested data structures

The only addition is:

 * Add the minimum required to the above in order to extract RDF triples

As Andy has already queried about - this is for the non-API use case,
where it is not guaranteed that you have an RDF/JSON API to map a set of
triples into a JSON object. That is, all that is available to the
developer is JSON.parse().

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: The PaySwarm Vocabulary
Received on Thursday, 7 April 2011 00:37:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:58 UTC