- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Wed, 1 Aug 2012 12:26:26 -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 Aug 1, 2012, at 1:45 AM, Ivan Herman <ivan@w3.org> wrote: > > On Jul 31, 2012, at 20:13 , Gregg Kellogg wrote: > >> On Jul 31, 2012, at 4:09 AM, Ivan Herman <ivan@w3.org> wrote: >> >> ... >> 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. Don't really see this as a similar issue. Most every syntax has multiple ways of saying things. Take Turtle: _:a :p :o1, :o2 . _:a :p :o1; :p o2 . _:a :p :o1 . _:a :p :o2 . [ :p :o1, :o2 ] . [ :p :o1] :p :o2 . [] :p :o1, :o2 . ... Not to mention variations on IRIs, relative IRIs, the use of @prefix and @base. Even N-Triples has multiple ways of saying the same thing, if you take into account escaping UTF-8 characters. RDFa provides even more variations. Saying that a language is flawed because it allows too many ways of asserting the same graph is something of a canard. The issue is can an expression of the language be understood by developers? JSON-LD provides a playground for just this purpose, at the time, I don't think this was true of RDF/XML. Moreover, JSON-LD actually improves this situation by providing a consistent expanded notation. For those documents that don't expand identically (e.g., multiple subject definitions using the same identifier), the API provides a flattening method to get to a consistent representation, or you can go through RDF, which will always give essentially the same (expanded) representation back. Whenever RDF is expressed through some serialization format or host language, best practice is to check that processing the document results in the triples expected. This is really necessary for RDFa (and RDF/XML), but JSON-LD improves on this by giving an author an API to work with the JSON directly. If we were looking for the most straightforward way to represent RDF in JSON, then the WG should have probably stuck with RDF/JSON. However, this yielded a format which was really unusable by actual JSON developers; JSON-LD attempts to allow JSON developers to work within their idiom, and this I think the language needs to support different constructs. > 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. As you know, waiting for a 2.0 (or even 1.1) release to address features the community is demanding is no help at all. There is probably a two to three year period before releases. This is the time to make sure the format addresses the needs of developers, before reaching a Last Call document. 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 16:27:55 UTC