You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
The text was updated successfully, but these errors were encountered: