- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Tue, 31 Jul 2012 14:13:54 -0400
- To: Ivan Herman <ivan@w3.org>
- 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>
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. 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. 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 > > > > > >
Received on Tuesday, 31 July 2012 18:14:34 UTC