W3C home > Mailing lists > Public > public-socialweb@w3.org > October 2014

RE: JSON-LD vs. JSON: pro vs. con?

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 1 Oct 2014 19:47:30 +0200
To: <public-socialweb@w3.org>
Message-ID: <0aaa01cfdd9f$d298edd0$77cac970$@gmx.net>
Since I don't like top-posting, you have to scroll to the bottom :-)

On 24 Sep 2014 at 18:05, henry.story@bblfish.net wrote:
> On 24 Sep 2014, at 17:40, Harry Halpin <hhalpin@w3.org> wrote:
>> The last meeting with had a quite vigorous discussion of JSON
>> and JSON-LD.
>> 
>> I'd like to see folks who want JSON-LD as a requirement justify their
>> position, and folks who would like to see it as an option but not
>> required justify their position.
>> 
>> Let the fun begin :)
> 
> Ok. Hope this is the last time we do this:
> 
> +1 for JSON-LD as a requirement
>  with the priviso: where it makes sense.
> For example it is possible to put RDF in an HTTP Link header
> using https://tools.ietf.org/html/rfc5988
> 
> Or if someone publishes the data in HTML there
> are a number of solutions there that integrate better with those.
> 
> But given that the WG has as agreed to a JSON based syntax and in
> the circumstances where that makes sense here is the reasons to
> go for that as a MUST.
> 
> . two syntaxes are a lot more work to do than 0 - because JSON-LD
>  would essentially remove the need to do anything more on syntax.
>  This will save the Working Group a lot of time - a lot more than
>  for example a healthy debate on use cases would have.
>   Even one syntax is a lot of work. The Atom working group lasted well
>  over two years because of debates about what things would be attributes
>  or elements, etc, etc... ie a load of syntactic issues that we can skip
>  over quickly leaving us with the already difficult logical issues.
> . it makes implementations easier: they no longer have to implement two
>  parsers: one JSON-LD and a JSON one.
> . we get Linked Data principles out of the box with JSON-LD, which means
>  it will work well with other frameworks such as html data annotations
etc,
>  and we are distributed from the ground up
> . we can make sure the data modelling is good by using tools and
experience
> which have been developed over 15 years in Universities, Governments,
Companies
> etc. around the world.
> 
> . we tie in with the Linked Data Platform that just recently made JSON-LD
a
> must support
> 
> . support for JSON-LD is growing fast

+1 to that Henry said above but..


> All of this does not stop people in a seperate group having a JSON pure
syntax
> and writing an mapper for that to the JSON-LD using a tool such as Antonio
> Garrotes https://github.com/antoniogarrote/json-ld-macros . But the group
here
> does not need to spend time on solving a problem that does not need
solving -
> ie that has already been solved for us by JSON-LD. There are a lot of
highly
> paid engineers here and we can't afford to waste their time.

If done right, I don't think there will be any need for that. The only
difference between a JSON-LD and a JSON-only serialization should be a
single @context property which JSON-only consumers can simply ignore.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler



 
Received on Wednesday, 1 October 2014 17:48:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:26:13 UTC