Thank you for looping me in. It's probably worth mentioning that some proposed features for JSON-LD 1.1 may actually help us to keep JSON-LD *out* of the Web of Things specifications, or at least make it an optional mechanism for adding semantic annotations to an otherwise plain JSON serialisation [1] of the Thing Description format [2] (like adding semantic annotations to HTML).
The rigid representation of RDF triples in JSON-LD 1.0 imposes significant constraints on the design of a JSON-based format if consumers want to be able to optionally parse it as JSON-LD (which many members of the Web of Things Working Group feel strongly that they do). Features proposed for JSON-LD 1.1 would allow much more flexibility to create a simpler and more intuitive plain JSON serialisation (e.g. using JSON objects instead of arrays in various places), with an implied default context, which can still optionally have semantic annotations added if someone wants to do that. These proposed JSON-LD 1.1 features have enabled us to successfully argue for a plain JSON serialisation instead of the current JSON-LD serialisation, while not fragmenting the Web of Things effort. I understand there are arguments against resources which can be parsed both as plain JSON and as JSON-LD, but there are lots of use cases people have for adding semantic annotations to JSON. Supporting (or at least not objecting to) the charter for JSON-LD 1.1 may actually help keep JSON-LD out of the web platform by making it an optional extension, rather than a dependency, in specifications. Note that we've gone to great lengths to keep JSON-LD out of our Web of Things proposal [2] so far, but I think it's probably inevitable that we're eventually going to need some kind of lightweight extensible schema based system for describing things in the real world, in order to make ad-hoc interoperability possible. Hopefully something lightweight like Open Graph or Microformats rather than a heavyweight solution like full JSON-LD (I'd value input on that [3]). Currently a leading effort in that area is iotschema.org which, like schema.org, will probably support JSON-LD style annotations using @context and @type. I should also probably mention the Web of Things specifications don't require any implementation in web browsers, we're using it as an entirely server side technology, so this work has no impact on Firefox. By all means feel free to express your grumbles with JSON-LD, but note that JSON-LD 1.1. could actually be a positive step forward for some Mozilla efforts. Thanks Ben 1. Our proposed plain JSON serialisation of a Thing Description https://iot.mozilla.org/wot 2. Current W3C Thing Description specification with JSON-LD serialisation https://w3c.github.io/wot-thing-description/ 3. Discussion on a schema based "capabilities" system for the Web of Things https://github.com/mozilla-iot/wot/issues/57 On 30 April 2018 at 16:16, Peter Saint-Andre <stpe...@mozilla.com> wrote: > On 4/29/18 10:42 AM, Henri Sivonen wrote: > > On Sun, Apr 29, 2018, 19:35 L. David Baron <dba...@dbaron.org> wrote: > > > >> OK, here's a draft of an explicit abtension that I can submit later > >> today. Does this seem reasonable? > >> > > > > This looks good to me. Thank you. > > +1 > > We might want to also check in with folks who are involved with the > relevant WGs (e.g., Ben Francis, cc'd, w.r.t. Web of Things). I'll > forward to him Tantek's earlier message. > > Peter > > > > > > > > >> > >> One concern that we've had over the past few years about JSON-LD > >> is that some people have been advocating that formats adopt > >> JSON-LD semantics, but at the same time allow processing as > >> regular JSON, as a way to make the adoption of JSON-LD > >> lighter-weight for producers and consumers who (like us) don't > >> want to have to implement full JSON-LD semantics. This yields a > >> format with two classes of processors that will produce different > >> results on many inputs, which is bad for interoperability. And > >> full JSON-LD implementation is often more complexity than needed > >> for both producers and consumers of content. We don't want > >> people who produce Web sites or maintain Web browsers to have to > >> deal with this complexity. For more details on this issue, see > >> https://hsivonen.fi/no-json-ns/ . > >> > >> This leads us to be concerned about the Coordination section in > >> the charter, which suggests that some W3C Groups that we are > >> involved in or may end up implementing the work of (Web of > >> Things, Publishing) will use JSON-LD. We would prefer that the > >> work of these groups not use JSON-LD for the reasons described > >> above, but this charter seems to imply that they will. > >> > >> While in general we support doing maintenance (and thus aren't > >> objecting), we're also concerned that the charter is quite > >> open-ended about what new features will be included (e.g., > >> referring to "requests for new features" and "take into account > >> new features and desired simplifications that have become > >> apparent since its publication"). As the guidance in > >> https://www.w3.org/Guide/standards-track/ suggests, new features > >> should be limited to those already incubated in the CG. (If we > >> were planning to implement, we might be objecting on these > >> grounds.) > >> > >> > >> -David > >> > >> -- > >> ๐ L. David Baron http://dbaron.org/ ๐ > >> ๐ข Mozilla https://www.mozilla.org/ ๐ > >> Before I built a wall I'd ask to know > >> What I was walling in or walling out, > >> And to whom I was like to give offense. > >> - Robert Frost, Mending Wall (1914) > >> > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
