Re: Type System Design Thoughts: [T2TRG] Reminder: IRTF Thing-to-Thing Research Group meeting this weekend

> On 24 Sep 2016, at 19:23, Michael Koster <michael.koster@smartthings.com> wrote:
> 
> Here are some slides to explain my views on the design of the type system for IoT/WoT. 
> 
> <Data Typing.pptx>


Hi Michael,

Thanks for sending the slides.  I am intrigued by your positioning of the problem to be solved, but don’t fully understand everything you say. e.g. you say that the focus is on informing a client application about how to consume resources. That makes some assumptions that need to be made explicit if we’re to have a shared understanding.

Given that the web of things is intended to be an abstraction layer that scales across a very broad range of platforms and requirements, I believe we need to clearly distinguish requirements for application developers, and requirements for platform developers. The former are about how to describe the interfaces by which applications can interact with “things”.  The latter are about enabling platforms to interoperate even when they are using different standards.

More generally, we can exploit the huge success of software objects and event driven behaviour over more than three decades, and expose things to applications as software objects with properties, actions and events. These need to be independent of the underlying protocols and communication patterns. In Lisbon, we also talked about the need for application layer metadata for the communication characteristics, e.g. whether it is safe to drop some updates or whether a complete log of all changes is needed, e.g. for a black box recorder. The application needs to be able to check whether the requested characteristics can be met by the given platform.

I am not 100% sure of the meaning you intend when you say resources and would appreciate some clarification.  I am aware of the use of the term for hierarchies of resources exposed by RESTful services that are addressed using a URI path syntax, but that sense belongs to the metadata for platform developers, i.e. how other platforms can access a resource on a given server, and is distinct from the interaction model exposed to applications.

You say “should not use schemas to explain JSON structures as atomic resources, this may not scale well”.  This too makes some assumptions that need to be made explicit. I believe that we need to consider the formal model for the interfaces exposed to applications separately from the way that these models can be serialised. This will allow for different serialisation formats, and more importantly, for an evolution of these formats as the technologies and requirements change over time.

One requirement that is regularly stated is the need to simplify the processing and network requirements for processing thing descriptions on constrained devices. Another requirement is the ability to capture regularities across similar devices. One such case is where all the devices are the same kind, and the thing description varies in just a few details, e.g. IDs for each device, the location, IP address and so forth.

You say: "Explain structure through a combination of hypermedia controls and application semantics”. Hypermedia controls require explanation.  Are these at the application layer and exposed to application developers or are they a framework for use by platform developers? For application semantics, we need a scalable approach that is modular and extensible.  The joint white paper on semantic interoperability [1] provides some background on what is needed, but is only just a first step in the discussion around a shared vision and roadmap. In principle, semantic models can be defined as constraints on the properties, actions and events for things. Thing descriptions could then be stated  in terms where the details for the properties, actions and events are derived from these models. I see that as something for a service composition engine to deal with, and not for resource constrained devices, where it will be appropriate to precompile the thing description to minimise the processing requirements.

I am hoping that with clarifications and further explanations we can move to a shared understanding of the choices before us.

p.s. We missed you in Lisbon, and hope that you can make it to the next face to face.

[1] http://dx.doi.org/10.13140/RG.2.2.25758.13122

—
   Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>>