- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Tue, 05 Apr 2011 20:14:33 -0400
- To: RDFa WG <public-rdfa-wg@w3.org>
Hey folks, Nathan had asked this question on the telecon a few weeks ago and I wanted to make sure to flag it up to the group before it was lost in the shuffle. He asked whether or not JSON-LD was designed to be a kitchen-sink specification - that is, it seems to try to support everything - a full RDF serialization in/on/with JSON. I attempted to clarify by saying that the only reason it seems like it is trying to support everything is because we wanted to have a number of object-based solutions ready when this working group started. We thought that we could save some time in this WG by doing due diligence on a complete, object-based representation of RDF in/on/with JSON. The sections in JSON-LD are modular - they were designed with the thought that we'd be ripping pieces of JSON-LD out as we moved forward in this group. Or, we'd be taking chunks of the specification and moving it into the body of work that this group was doing. That is - the spec is flexible and malleable - almost nothing is set in stone and most everything is up for discussion. That is, JSON-LD should be viewed as a collection of potential solutions - not a complete kitchen-sink spec. To give an example of what I mean, JSON-LD could go the CURIE route: http://www.w3.org/2011/rdf-wg/wiki/JSON-Serialization-Examples#JSON-LD_.28CURIEs.29 or it could go the Terms route: http://www.w3.org/2011/rdf-wg/wiki/JSON-Serialization-Examples#JSON-LD_.28terms.29 It could support all of the Advanced Features and Advanced Concepts: http://json-ld.org/spec/ED/20110201/#advanced-features http://json-ld.org/spec/ED/20110201/#advanced-concepts ... or none of them. Each section was designed to be removed/added and keep the rest of the spec intact (for the most part). -- manu -- Manu Sporny (skype: msporny, twitter: manusporny) President/CEO - Digital Bazaar, Inc. blog: The PaySwarm Vocabulary http://digitalbazaar.com/2011/03/31/payswarm-vocab/
Received on Wednesday, 6 April 2011 00:14:59 UTC