draggett
commented
7 years ago I very much agree with the need for compelling use case stories that clearly show the benefits of the standards we're trying to develop. We need to show how semantic technologies can be used in a simple and obvious way to address challenges.
I see several broad areas for use cases:
-
Smart applications can use semantic descriptions to figure out how to adapt to variations in the object model for home appliances across vendors and IoT standards suites. OCF, oneM2M and ECHOnet all define interfaces for home appliances, but they all differ in the details.
-
Creating a virtual device that supports a given set of semantics as a composition of real or virtual devices and services.
-
Verifying that a given device supports the domain constraints for the semantics it claims to support. This is important when you want to ensure that the consumer and provider of a service agree on the meaning. You need to check at the both the semantic level and the syntactic level that defines the object model exposed to applications.
Can you please check the updated charter and see if there are any changes you would like to see.
egekorkan
The charter for the TF-LD can be informed by some simple use case stories. Here is a suggested set of use case stories.
Assumptions for the background:
WoT Thing Description exists, and is able to inform servers how to construct instances and clients how to mechanically consume instances of connected things like thermostats and lighting controls. TD functions correctly as a generalized hypermedia control for connected things.
There exist standardized publicly readable resources which host machine readable definitions for common terms used in applications involving connected things, for example thermostats and lighting controls. These resources describe both the intrinsic capabilities of connected things, such as temperature sensing, heat control, light dimming, and so on, and also describe the physical affordances these things are associated with, for example doors, windows, rooms in a building, architectural features, an so on. One example is iot.schema.org
As a developer of exposed-thing-side applications, consisting of connected things and connected spaces, I use [the TF-LD deliverable] to enable me to easily construct, annotate, and deploy instances of services that expose thing descriptions for the connected things I deploy. I can choose design patterns (recipes) and items (ingredients) and compose them into Thing Descriptions to meet my particular use case requirements for exposed things. Thing Description, along with a common framework for embedded semantic information, enables me to offer my connected products and spaces to a broad set of customers across many application domains.
As a developer of consumed-thing applications, I use [the TF-LD deliverable] to easily create client-side applications that focus on the value-added part of the equation, enhancing my customer's experience. I don't have to think about how application semantics are handled in the application; I can focus on the purpose of the application. I have access to tools that allow me to re-use semantic identifiers from many vertical domains with familiar web design techniques.
WoT Thing Description with a common semantic framework enables me to create new innovative applications that can use information from different vertical domains. I can create a common application framework that enables broad repurposing of my application through semantic re-mapping. For example, I can create a general purpose scheduling application which can be used by an irrigation company to control sprinklers and can be re-used by a smart building contractor to control lights when the building is unoccupied. I can discover instances of things in the system by using terms common obtained from the public resource.
The gap is in how to create a TD where the event, action, and property sub-classes and types are defined using terms from the shared (public) resource, in a way that facilitates: