W3C home > Mailing lists > Public > public-linked-json@w3.org > August 2012

Re: an idea: @context in coercion rules ?

From: Ivan Herman <ivan@w3.org>
Date: Wed, 1 Aug 2012 10:45:53 +0200
Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "public-rdf-wg@w3.org" <public-rdf-wg@w3.org>, "public-linked-json@w3.org" <public-linked-json@w3.org>
Message-Id: <B599D5D1-0E44-46A0-A200-8FD0391C3C16@w3.org>
To: Gregg Kellogg <gregg@greggkellogg.net>

On Jul 31, 2012, at 20:13 , Gregg Kellogg wrote:

> On Jul 31, 2012, at 4:09 AM, Ivan Herman <ivan@w3.org> wrote:
> 
>> 
>> On Jul 31, 2012, at 12:53 , Markus Lanthaler wrote:
>> 
>>>> 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.
>>> 
>>> I couldn't agree more and raised the same concern in last week's telecon.
>>> This specific issue was
>>> 
>>> RESOLVED: Do not support embedding @contexts within a @context to re-define
>>> the IRI that a term maps to. [1]
>>> 
>>> 
>>>> 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.
>>> 
>>> I mostly agree with this as well. The only thing I think we should really
>>> consider is to make @container more powerful, see [2] and [3] for details
>>> but even there I'm not sure whether this really needs to go into JSON-LD
>>> 1.0.
>>> 
>>> 
>> 
>> Well...
>> 
>> I think one of the criteria we will have to use is that if I look at an example and it is not immediately clear what a feature really does, then this is a candidate for removal. I guess criteria, mainly in view of the audience of JSON-LD, is valid, though, I admit, fuzzy. 
>> 
>> Well, I looked at both [2] and [3] and none of these passed this test:-( Plus I do not see the real necessity to add features to generate those particular output. Ie, at this moment, I would not be in favour of adding any of those two things into JSON-LD. Feature freeze...:-)
> 
> Sorry, I have to disagree.

Good. The fact that we disagree means that there is no conspiracy between us two (we seem to agree to many times...)

> I don't think it's time for a feature-freeze yet: we're receiving too much input from the community. That said, we should, of course, carefully consider each potential change to determine it's relevance, importance and potential for disruption.
> 
> With regards to issue 133 @container: @language [2], we've seen two different, unrelated, interested parties come forward with basically the same requirement: to be able to avoid array notation in favor of object notation, specifically for the case when multiple languages are used.
> 
> What sets JSON-LD apart from other RDF formats is that it is intended to allow for idiomatic usage of JSON. Of necessity, this comes down to mapping different syntactic constructs into a common format (expanded form).
> 
> For wide adoption of JSON-LD, it's important that we listen to the community to deliver a standard that actually meets their needs. Personally, I don't think that issues 134 or 144 ([1] and [3]) rise to that level.


I understand all that. But too many syntactic sugars makes the whole thing... sour (sorry:-). This is, after all, the main issue around RDF/XML. The problem with it is not that it is XML but that there are so many different ways of expressing the same things that, at the end, nobody really understands it any more, writing a parsers becomes complex, checking a file is impossible with standard tools, etc. What I am afraid of is to engage into a similar road with JSON-LD, which may kill it; the JSON community may reject it as being way too confusing.

Bottom line: I am still in favour of a feature freeze, moving the current document into LC as soon as this is administratively possible, with the only technical change being possibly *removing* features and not adding any (beyond handling errors, of course). Even if we are forced to reject some feature requests...

Ivan

P.S. Maybe separating and freezing the current version on Rec track, and considering a 2.0 version with feedbacks from the community is a way to go.

> 

> 



> 
> Gregg
> 
>> Ivan
>> 
>>> [1] https://github.com/json-ld/json-ld.org/issues/144#issuecomment-7209951
>>> [2] https://github.com/json-ld/json-ld.org/issues/133
>>> [3] https://github.com/json-ld/json-ld.org/issues/134
>>> 
>>> 
>>> 
>>> P.S.: Sorry for my last fat-fingered mail.
>>> 
>>> 
>>> --
>>> 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
>> 
>> 
>> 
>> 
>> 
>> 
> 
> 


----
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 Wednesday, 1 August 2012 08:46:24 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:25:37 GMT