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

Re: JSON-LD Telecon Minutes for 2011-07-04

From: Olivier Grisel <olivier.grisel@ensta.org>
Date: Wed, 20 Jul 2011 12:16:44 +0200
Message-ID: <CAFvE7K79PZayeoPuje_Pm+52KTPwa_HHgd5n0_eUSvmZ-ZQPtg@mail.gmail.com>
To: "public-linked-json@w3.org" <public-linked-json@w3.org>
Hi all,

First email to this list. I would just like to emphasize that adoption
seems more important to me that whether this format is real Linked
Data. Adoption should be the number one priority focus for this
working group.

So I am fine if this format is called JSON-SD to preserve the purity
of the Linked Data brand and concept. Web and Mobile application
developers need a practical way to exchange *lightweight* JSON
payloads that is both readable and provides enough namespaces and
dereferenceable IRIs for resource that matter both for
interoperability across applications and discoverability in general.

This spec should not enforce them to put boilerplate IRIs on
"structured literal attributes" such as playlist items or digital
signatures or partially available information (e.g. person name or
email without complete knowledge of any linked data profile).
Enforcing the requirement of having an IRI on every single node of the
JSON payload would have a huge negative impact on adoption by:

 - rendering the JSON payload less human readable (this is very very
important for adoption)
 - making it overly complicated for the developers to instrument
existing JSON feed generators and web service APIs to make them output
valid JSON-(LD|SD|whatever the final name of this spec)
 - increasing the size of the payload without any concrete need for
that additional data (very important for mobile application

Also the Framing mechanism presented by Many sounds like a practical
solution to handle blank nodes when they are scoped by a IRI
identified resource that is part of the JSON payload.

http://twitter.com/ogrisel - http://github.com/ogrisel
Received on Saturday, 23 July 2011 15:01:47 UTC

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