W3C home > Mailing lists > Public > public-rdf-wg@w3.org > July 2012

Re: an idea: @context in coercion rules ?

From: Ivan Herman <ivan@w3.org>
Date: Tue, 31 Jul 2012 11:48:09 +0200
Cc: <public-rdf-wg@w3.org>
Message-Id: <A6F214CA-6A3E-4883-A1D2-B243CC514001@w3.org>
To: Markus Lanthaler <markus.lanthaler@gmx.net>
I am worried about this. Of course, there may be situation where this might be handy. But... I am, in general, afraid of building an RDF/XML in JSON. What I mean is that having too much choices to express the same things may lead to user confusion and, ultimately, rejection.

My personal feeling is that we should have a feature freeze in JSON-LD and, rather, look at every feature and variations with eagle eyes to see if they are needed and, in case of doubt, remove them.


On Jul 11, 2012, at 17:26 , Markus Lanthaler wrote:

> On Wednesday, July 11, 2012 4:17 PM, Stéphane Corlosquet wrote:
>> Interestingly I was thinking along the same line last night.
>> My use case was a nested object where the same key happens to
>> appear at different levels of nesting, much like Pierre-Antoine's
>> example. In other words, this would allow overriding the context
>> inside a nested element of a JSON object. A good example is for
>> the example a key 'item' which might appear at several levels of
>> nesting, and that might qualify for a different mapping depending
>> on what level it's at.
> The way we address this as the moment is by adding a @context to the nested
> object to redefine properties (terms). The advantage of the solution
> proposed by Pierre-Antoine is that it could also be used for legacy JSON
> where it is impossible to inject @context definitions into the data.
> I created ISSUE-144 for this [1]. Lets continue the discussion there.
> [1] https://github.com/json-ld/json-ld.org/issues/144
> --
> Markus Lanthaler
> @markuslanthaler

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Tuesday, 31 July 2012 09:48:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:05 UTC