Re: [JSON] A starting point...

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...

+1

> 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
terms).

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
http://digitalbazaar.com/2011/03/31/payswarm-vocab/

Received on Thursday, 7 April 2011 00:37:51 UTC