Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Profile Use Case -> converging interoperability #303

Open
lu-zero opened this issue Sep 18, 2024 · 0 comments
Open

Profile Use Case -> converging interoperability #303

lu-zero opened this issue Sep 18, 2024 · 0 comments
Labels

Comments

@lu-zero
Copy link
Contributor

lu-zero commented Sep 18, 2024

Submitter Contact Information

@lu-zero

Domain or Industry

Profile TF experiment

Introduction

Profiles focus on giving out-of-box interoperability: a Consumer supporting a profile can use every and all the capabilities a Thing supporting the same profile exposes.
A Thing using a binding protocol cannot signal that a Consumer supporting the same binding protocol can use all the capabilities available through it.

This Use Case focuses on using profiles to have vendors converge on them, reduce the overall iot fragmentation and reduce the effort required to write generic consumers.

WoT Usage

Profiles restrict what is described in a TD by defining the scope of the extension points (e.g. only a set of bindings can be used and it MUST cover all the Things affordances)

Technical Environment

Profile-dependent

Problem

Thing Description main aim is to be able to faithfully describe pre-existing devices and foster interoperability by making possible to write less specialized consumer able to access at least some of the device capabilities depending on how many Bindings used in the TD are supported by the Consumer itself. By having a TD is possible to build dedicated consumers w/out additional knowledge.

This is a leap compared to the alternative of having to build clients accoding to documentation that might not be available anymore, but it is far from a scenario in which devices and clients just work out of box, pending some onboarding process.

Profiles can solve this problem.

Expectation

The profiles registry would contain greenfield profiles that should provide a blueprint to use in an efficient way a set of protocols described by their bindings and restrict them so it is easy to write consumer and things supporting it.

Ideally at most a profile per (sub)protocol should exist

Solution Proposal

The current Profiles 1.0 are close to the philosophy described above

Comments

This is an experiment to test the UC template and brainstorm regarding the scope of Profile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant