search

w3c / wot-profile

Web of Things (WoT) Profile
http://w3c.github.io/wot-profile/
Other
16 stars 8 forks source link

Collect Use Cases and Scenarios for Profiles #71

Closed mmccool closed 2 years ago

mmccool commented 3 years ago

To better understand when and where a profile is applicable, and when constraints (e.g. on TD size) or other requirements beyond the core specs (e.g TD) are needed, we need realistic use cases (ideally tied to actual products, or at least what is expected on the markets, what protocols and price points are likely to be, and so forth).

Please add use cases etc. here; please limit it to use cases for profiles since general use cases should of course go into the use cases document.

The ultimate outcome should be a clearer understanding and consensus on the purpose of profiles and where and when they are useful.

benfrancis commented 3 years ago

I'd like to share the use cases and requirements collected by the Web Thing Protocol Community Group which I think are relevant here.

The current draft report lists use cases for WoT Clients, WoT Devices and WoT Gateways & Directories.

Of particular relevance is the list of requirements for an HTTP sub-protocol which I suggest could form the basis of a WoT Core Profile that:

  1. Requires that all conformant WoT consumers and WoT producers support HTTP & JSON
  2. Provides a concrete protocol binding/sub-protocol which defines how to communicate with devices including requests and responses expected for any given operation and their methods, headers, payloads and expected response codes

In terms of products which have these requirements, from my own experience I can point to:

sebastiankb commented 3 years ago

I think to identify the use cases, it makes sense what typical roles we have in the IoT. So far, I miss a clear separation between a consumer and a producer in the discussions.

Sensors and actuators typically act as producers and a profile should have the power to describe any type of such device, even if it only offers 2 data points or 200 different data points / functions as well as being a device with a few kB RAM or GB RAM. I already shared an example of an automation device here. Device manufacturers will always implement the desired device capabilities and not care if there is a device description that would potential affect the capability due to a generic size limitations.

My impression is that the discussion is mainly about a consumer who should be able to consume any kind of profile-based TD. What for classical consumer do we have in our PlugFest? Mainly, I see generic approaches such as W-ADE, node-red and node-wot. How about consumers for resource constrained devices? Is there also an expectation that any kind of profile-based TD should be understood? I don't think so. The consumers there are implemented in such a way that they expect TDs with certain characteristics, e.g. that a certain semantics and information model is used, otherwise it is not able to do anything with its content. E.g., consumers that follow LwM2M will expect TDs that reflects LwM2M. The implementation of such consumer will follow more the expected capability of LwM2M which may also in a conflict with a generic size limitation of a TD.

I think there are reasons why approaches like Vorto and DTDL do not have such a generic constraint. My suggestion is that a profile that mainly uses HTTP(S)/JSON should not have TD size constraints. It would be strange if more powerful systems like Edge / Hub / Cloud had to split TDs of an IoT system due to a generic size limitation. This would complicate everything once again.

egekorkan commented 3 years ago

I second the comment above. Unless we start seeing some resource-constrained Consumers in our Plugfests, I don't think that we have the knowledge to define such restrictions. Maybe @Citrullin can provide such Consumers but he was concentrating on a CoAP stack already and thus not applicable to an HTTP profile.

mlagally commented 3 years ago

Arch call on 11.3. We should think about the 3 different entities in our architecture, but can start with thing and consumer for now.

What would happen if we don't have a size limit:

Some devices would be too small to consume some TDs that are huge, e.g. exceeding the RAM on that device. -> The device would not be interoperable with the producer of the large TD

Sensor data can be still processed in a stream, however a TD needs to be read and validated before usage.

A client will always make some assumptions about a TD, will discover it in a repository and know the semantics - will only receive TDs that satisfy the query.

Ikea devices all understand LwM2M and have expectations about maximum TD sizes.

What about P2P? Do we always assume a gateway? How to discover a TD? Do we always mandate a gateway? No thing to thing interaction? This implies that we don't have things as consumers.

Assumption is to have multiple classes of devices, some devices are helpers for others.

Consumers that receive too large devices need to handle that gracefully, i.e. not blow up. Can partial TDs be a way out of the problem that only describe the area of interest? This could be also provided by the producer, i.e. we don't need a directory.

Entities: device, consumer, intermediary, directory, ...

A consumer on a constrained device can check if he can process the TD, or get a partial TD when otherwise the size would be too large. -> every compliant producer device needs to be able to provide partial TDs

Kaz already brought the topic to the scripting and discovery call, should be discussed further during the F2F week.

mlagally commented 2 years ago

A set of use cases has been published in the WoT Use Cases and Requirements document (https://www.w3.org/TR/wot-usecases/). New requirements for Profile 2.0 should be discussed in the use cases TF first, before they are passed on to the Profile TF.