contracts, registries and linked data

In today’s call we had a short discussion on the model for the contracts for the interfaces in the web of things. I see two kinds of contract. The first is between the application developer and the application platform developer. The second is between the application platform developer and an IoT platform developer. This second contract sets out the details for how to use the protocols to communicate with a particular platform. This level of detail should not be exposed to the application developer as it isn’t relevant to the interface used by applications to interact with the objects that represent things.

The application developer contract does need to identify the platform to platform contract so that the application platform can use the correct software drivers. There may be contract specific metadata that needs to be present in the thing description. Examples include the OCF resource types and resource identifiers. Note that I anticipate support for dynamic loading of platform drivers as application platforms may want an extensibility mechanism to avoid being stuck with some static set of drivers.

This gets us to a discussion about what kinds of contract identifiers are sufficient.  They need to be globally unique, and some of us prefer the idea of centralised repositories, and cite the IANA curation of media types as an example. Media types are strictly speaking about data formats, e.g. "text/css" rather than the more general concept of software contracts. Other people prefer a decentralised approach to identifiers. This is the idea behind W3C’s Linked Data, where the identifiers are expected to be dereferenceable, and there is a preference for using HTTP based identifiers, i.e. URLs. We’ve already opted for this approach in respect to the contract between the application developer and application platform developer with the use of URIs for thing descriptions, so I would recommend we do the same for the identifiers for the platform to platform contracts.

I am expecting that Michael Koster will have a different perspective, Michael where do we differ?

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