W3C home > Mailing lists > Public > public-linked-json@w3.org > June 2011

Re: Comments on the complexity of the JSON-LD spec

From: William Waites <ww@styx.org>
Date: Sun, 5 Jun 2011 13:06:45 +0200
To: Brian Peterson <publicayers@verizon.net>
Cc: 'Dave Longley' <dlongley@digitalbazaar.com>, public-linked-json@w3.org
Message-ID: <20110605110645.GE25707@styx.org>
* [2011-06-03 20:38:47 -0400] Brian Peterson <publicayers@verizon.net> écrit:

] I wish it were so, but I just can't agree. I might have agreed with you 2
] years ago, but not now. If a developer hasn't, it's because JSON is so
] simple they don't need to. The spec is so simple that intro articles tend to
] be longer than the spec! (http://www.json.org)

FWIW, I think it's not so much that JSON is simple - Turtle is pretty
simple too, but that it maps directly to the constructs that
developers are used to using in some common programming languages. You
can more or less just eval() JSON in Javascript or Python. So it's
incrementally simple in that it doesn't require developers to learn
something new.

What's "complex" about RDF is not the different serialisations but the
data model (where "complex" should really be understood as
"different"). My recent experience working with the developers of
BibJSON (basically BibTeX in JSON) and trying to align it with JSON-LD
suggests that apart from trivial superficial things ("@" and "Â#" are"
funny character") the main contention is in the modelling -- the
indirections that are used in RDF to make things unambiguous. So it
looks like flatter dictionaries are preferred over nesting even if it
makes it ambiguous what subject a key/predicate belongs to. This is
really independent of the complexity of the specs or ease of use of
any serialisation...


William Waites                <mailto:ww@styx.org>
http://river.styx.org/ww/        <sip:ww@styx.org>
F4B3 39BF E775 CF42 0BAB  3DF0 BE40 A6DF B06F FD45
Received on Sunday, 5 June 2011 11:07:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:29 UTC