W3C home > Mailing lists > Public > public-wot-ig@w3.org > May 2016

RE: application facing lifecycle, data and interaction model for things

From: Charpenay, Victor <victor.charpenay@siemens.com>
Date: Tue, 3 May 2016 12:50:55 +0000
To: "dsr@w3.org" <dsr@w3.org>, "Peintner, Daniel (ext)" <daniel.peintner.ext@siemens.com>
CC: "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <6E3FA85ED8C35E42B0F7DE1E44FD0C9FFC335B@DENBGAT9EL5MSX.ww902.siemens.net>
Hi all,

I have several remarks about Dave's type system and Carten's comment on that topic:

>So for data models that are using the general idea of JSON, we did CDDL as a synthesis of ABNF and Relax-NG (https://tools.ietf.org/html/draft-greevenbosch-appsawg-cbor-cddl). IETF also has YANG (RFC 6020 and https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-12), which is for data at rest, not for data in flight.  This still has a bit of XML cruft in it.  There are many people who want to use YANG models for IoT, so it is likely that this modeling language will stay relevant in this space.

What Taki, Daniel and I have been doing is less trying to define a JSON-like type system than actually reviewing existing formats to express data types and constraints. In that sense, CDDL and YANG are valuable input. Thanks for giving us pointers to them. However, I personally think we should strive to find/use a native RDF vocabulary for data modeling rather than using external models (or a minima something than could be expressed in JSON and embedded into a Thing Description). As someone put it in the last web-conference, OWL is actually a candidate. I would agree with this person if only OWL wasn't as unnecessarily complicated as it is.

>In Montreal, there seemed to be quite a bit of enthusiasm for using the schema.org data types, which could also help us with engaging the web developer community.

>From that, schema.org seemed to be a good candidate but it actually misses basic features as we explain in https://github.com/w3c/wot/tree/master/proposals/type-system, it focuses too much on data and not on data types at all.

> I cannot send a thing along in a message, so I don't know what that would mean.  (A reference to a thing can be, and we have URIs for that in the Web.)

I am also skeptical about the idea of including "Things" as data types...



From: Dave Raggett [mailto:dsr@w3.org]
Sent: Montag, 2. Mai 2016 19:08
To: Peintner, Daniel (ext) (CT RDA NEC EMB-DE)
Cc: Public Web of Things IG
Subject: Re: application facing lifecycle, data and interaction model for things

   On 2 May 2016, at 12:36, Peintner, Daniel (ext) <daniel.peintner.ext@siemens.com<mailto:daniel.peintner.ext@siemens.com>> wrote:

   Hi Dave,

   I currently have an informal and incomplete proposal for types,
   and am looking for help to formalise this. The starting point is
   the notion of a "value" as having a type.  This includes some core
   types like null, booleans (true or false), numbers and strings.
   This borrows directly from JSON.  Note that RDF has problems with
   null, which therefore needs further discussion.  JSON further suggests
   the need for arrays and name/value pairs. This allows for compound
   values with arbitrarily deep nesting. Values may be early or late
   bound or variant types, where there is some flexibility for what
   kinds of values are accepted.

   In Montreal, Victor, Taki and myself have been asked to look into how we could express datatypes in a thing description and so we did.


   Please have a look and feel free to comment on what has been done so far.
   I think we should try to find common agreement.

   In Montreal, there seemed to be quite a bit of enthusiasm for using the schema.org<http://schema.org> data types, which could also help us with engaging the web developer community.  Matthias argued nicely for using number + restrictions rather than having a large suite of number types. However, this should be subject to feedback from web developers. My guess is that web developers will prefer short names to longer ones, e.g. max rather than maxValue or maximum.

   OCF uses RAML + JSON schema, and I would like to note that this results in rather complex descriptions. We should aim to offer greater simplicity and greater flexibility! I believe that this is indeed practical, and plan to study this for the OCF definitions on the oneiota.org<http://oneiota.org> site.

   An area for future study is a extension of JSON to allow for expressions as a basis for expressing integrity constraints. This is analogous to using expressions in spreadsheets and forms, and something I've explored for an HTML forms library some years ago. Domain models can then be expressed as a mix of data model constrains and semantic constraints that determine what properties and types etc. are needed for given kinds of things.

   I think we should take an experimental approach that explores a range of choices and seek feedback from a broad range of stakeholders. It is all to easy to pick a choice that later turns out to be unpopular when engaging with people outside of one's immediate colleagues, and who don't share the same perspective.  XML namespaces and XHTML are a case in point.

   To get this broader feedback, we can focus on providing open source projects along with good documentation and examples, so that people can easily get a hands on feel for the different choices.

   Thanks for the pointer to [1]. The user defined properties are similar to the approach I've been exploring, although I also allow for a shortcut for common cases where you give the type name directly in place of the JSON object for a given property name.  One area where simplification is possible is for the mapping from the abstract data model to the resource model for devices using REST based protocols like HTTP or CoAP.  If this mapping can be expressed as a standard (named) recipe, then the platform can apply that recipe, and the thing description can avoid the need for all the complexity that we see with RAML+JSON schema.

   I am progressing with my C++ implementations for the Arduino and a Web of Things gateway for more powerful devices. The latter will support multiple protocols and provide a testbed for interoperation with OCF, M2M and other platforms. One of the considerations for thing descriptions is how easy they are to support on resource starved devices.

   [1] https://github.com/w3c/wot/tree/master/proposals/type-system


      Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>
Received on Tuesday, 3 May 2016 12:51:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:27:03 UTC