Agree on a common definition of "out-of-the-box-interoperability"

[mlagally]

Please propose your understanding / definition in this issue.

[benfrancis]

The definition I proposed on the WoT Architecture call today was:

"Any Consumer which conforms with a given profile can interact with any Thing which conforms with the same profile, without additional customization."

[mlagally]

@benfrancis, thanks for this proposed text. Can you please clarify which consumers you think about? Clients, Servers, Servients, Intermediaries, Humans?

[benfrancis]

@mlagally wrote:

Can you please clarify which consumers you think about? Clients, Servers, Servients, Intermediaries, Humans?

For profiles in general Consumers can theoretically be a client or server or both. Consumer-Producers can be intermediaries for other Consumers. Humans are a separate issue because they don't generally consume Thing Descriptions at the API layer, they consume a human-computer interface at the UI layer, which has lots of other considerations!

For the initial HTTP+JSON profile, I anticipate an assumption that Consumers are clients and Producers are servers.

[mlagally]

To facilitate the discussion and make sure we consider all interoperability aspects, I propose we use the terminology as defined in the "H2020 – CREATE-IoT Project - Recommendations for commonalities and
interoperability profiles of IoT platforms". (See also https://w3c.github.io/wot-usecases/#multi-vendor)

https://european-iot-pilots.eu/wp-content/uploads/2018/11/D06_02_WP06_H2020_CREATE-IoT_Final.pdf

• Technical Interoperability: usually associated with communication protocols and the
infrastructure needed for those protocols to operate;

• Syntactic Interoperability: usually associated with data formats and encodings along with
techniques for compressing them;

• Semantic Interoperability: associated with shared understanding of the meaning of the
exchanged content (information);

• Organisational Interoperability: associated with the ability of organisations to effectively
communicate and transfer information even across different information systems,
infrastructures or geographic regions and cultures.

[mlagally]

IMHO so far the recent discussions were focused on protocols, i.e. technical interoperability.
All of the 3 other interoperability aspects need to be carefully considered for OOTBI.

[relu91]

As I said during the editor's call I would support a definition based on the literature. Another good reference that I used in the past is Interoperability in Internet of Things: Taxonomies and Open Challenges. There the authors define a slightly different classification:

• Device interoperability: Mostly related to hardware interoperability and the availability of dedicated hardware for communication.
• Network interoperability: Protocol related
• Syntactic interoperability: interoperation of the format as well as the data structure used in any exchange
  information or service between heterogeneous IoT system entities
• Semantic interoperability: The document refers to an old definition of semantic integration by W3C, but in general it nails down to a shared understanding of the data model.
• Platform interoperability: the ability to interoperate between different IoT technology stacks.

If we try to map this classification with the one from H2020 Create-IoT

• Device interoperability and Network interoperability fall under Technical Interoperability
• Syntactic Interoperability and Semantic Interoperability have the same interpretation
• Platform interoperability: I would say that it doesn't belong to any of the categories above, I would prefer this definition to Organizational Interoperability that is vaguer.

[relu91]

My personal take on OOTBI is that we should restrict TD language to have a precise protocol achieving Device, Network, and Syntactic interoperability. Regarding semantics, I don't have a strong opinion to include it or not, but if we ever include it my preference is to select a set of standard well know ontologies, no ad hoc keywords or new fields in the TD. I would say that platform interop is out of the scope.

[benfrancis]

@mlagally Is your thinking that the WoT Profile specification would address all of those layers or are you just trying to define out-of-the-box interoperability more generally?

A simple way of looking at those layers of interoperability in the context of WoT is that:

• JSON provides the syntax
• A Thing Description provides the semantics
• A Profile provides the (sub-)protocol

In practice it's a bit more complicated than this because the current Core Profile does arguably define some additional semantics as part of the sub-protocol, like the ActionStatus object, which can't easily be described in a Thing Description (although I've attempted to show how that can be done in #91).

I think the big open question is to what extent a Profile should extend or constrain the semantics of the information model of a Thing Description.

My view is that ideally Thing Descriptions should be responsible for semantic interoperability and the Profile should focus on the protocol interoperability. If we decide that a Profile does constrain semantics (the information model) of a Thing Description then I suggest it should only do so when essential for interoperability (e.g. date formats and units) and only when those constraints can't be applied to all Thing Descriptions in the Thing Description specification.

[mlagally]

@benfrancis
For a system integrator all these four interoperability vectors are required to ensure OOTBI.

Technical Interoperability: OOTBI at protocol layer, use of HTTP(s), authentication mechanisms, self descriptive things (discovery)

Syntactic Interoperability: well defined JSON format, validation, max lengths, common field names, guaranteed fields. common error response format, event payload, error codes, unambiguous mapping of HTTP protocol verbs (e.g. PUT vs. POST).

Semantic Interoperability: consistent data model across things, e.g. unambiguous units, date + time representation, fields have the same "meaning", i.e. comon interpretation of values across devices and vendors.

Organisational Interoperability: things have the same behavior, if they are used in the same way. This is independent from the manufacturer, geographical location, and other situation context. Behavior is independent from the network topology or protocol stack.

[mlagally]

@relu91 ,
I think your reference is providing a very similar definition of the interoperability aspects. I would prefer to use the one from the H2020 project, given the fact that Dave Raggett is one of the authors (and W3C team contacts).

I think the semantic and behavioral aspects are critical for OOTBI (see also my response to @benfrancis). Consider the action "close valve" on an industrial tank. If it would behave the opposite (i.e. open a valve) on a specific thing implementation, you could cause serious problems.

The same is true for mismatching units, see the mars climate orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter for a prominent example.

[benfrancis]

@mlagally wrote:

For a system integrator all these four interoperability vectors are required to ensure OOTBI

I'm sure that's true, but that wasn't what I asked. My question is whether the WoT Profile specification needs to solve all of these problems?

I suggest that a profile should focus on a subset (ideally just technical/network interoperability according to the definitions above) and leave the other layers to other parts of the WoT stack.

[mlagally]

Profile call on Feb 16.2.:

• Technical Interoperability: usually associated with communication protocols and the
  infrastructure needed for those protocols to operate;
  e.g. HTTP / TCP/IP

• Syntactic Interoperability: usually associated with data formats and encodings along with
techniques for compressing them;
e.g. JSON-LD for TDs, JSON payloads

• Semantic Interoperability:
action semantics wrt sync, async - , events, how to set/get multiple properties, writable properties, error messages
out of scope: domain specific ontologies, e.g. semantic interop of automotive and medical devices

• Organisational Interoperability:
"Any Consumer which conforms with a given profile can interact with any Thing which conforms with the same profile, without additional customization."
Things from all engineers, vendors and SDOs that support requirements for the profile spec can be integrated without additional customization. This works across infrastructures, regions and cultures.

[benfrancis]

Closed by #176