Re: [T2TRG] [Asdf] [One Data Model Group] Representation issues and protocol bindings

[David Kemp <[e-mail]>]

For the 80% case (e.g. temperature), a non-solution is to use an attribute
called "temperature".  Every device that deals with temperature must
understand standard units of temperature, which should be communicated
using attribute names like "kelvins", "degrees_f", or "degrees_c".  The
data format could (should?) be standardized as float, which doesn't make a
difference in JSON but does in CBOR.  What if you want to design a device
that uses int8 between 0 and 100 to represent -40C to 200C?  Then you're
not in the 80% any more.

The other 20% should be addressed using the same principle: "brightness" is
a useless property name, "lumens" is better in that it specifies a
measurable value, but has the disadvantage that it is absolute, not
relative to the capacity of the device.  A relative attribute would at
least need to specify the gamma of the control function.

Time could be defined similarly, specifying units (e.g., nanoseconds,
milliseconds, seconds) of resolution for intervals and an epoch for
date-times.  Or for the simple 80% a cumbersome but generally-understood
RFC 3339 string could be used, hopefully using an "rfc3339-date-time"
attribute, not "date-time".

The general principle is that standard units need to be defined in the
first place, and then attribute names should refer to the standard, not a
unitless name of a feature.

Dave


On Mon, Aug 31, 2020 at 11:22 AM Milan Milenkovic <[e-mail]>
wrote:

> For your example, I was going to suggest the range fraction or % solution
> but Wouter beat me to it.
>
> More importantly, I think we should be pragmatic and aim for the 80%
> solution (which, according to the Pareto principle, may require definition
> of only 20% of use cases ;-).  IMO, luminosity ad brightness are examples
> of a relatively skewed minor use case in a specific domain that is
> consuming disproportionate amounts of time and effort to address and that
> complicates many a solution for what is at best a small benefit.  Such
> things can be tabled, and possibly revisited later, to allow progress on
> solutions for the most common use cases.
>
> -----Original Message-----
> From: ASDF <[e-mail]> On Behalf Of Carsten Bormann
>
> In today’s OneDM call, Bruce Nordman brought up the issue that, in the
> end, we’ll need concrete representations to talk to devices and use their
> data.
>
> So if we have one ecosystem that uses 0..100 for describing the brightness
> setting for a lamp, another one that uses 0..254 (where 255 means something
> complete different), and a third with 0..65535, what do we do?  (And these
> might also differ whether they describe a emitted light power level or a
> perceptive luminous flux level.)
>
> The underlying problem is that we are abusing data model level description
> techniques (in part borrowed from json-schema.org) to describe
> information models.
> That works reasonably well until we start taking these data model level
> descriptions at face value.  The fact that some converged model uses a
> scale based on the L component of Lu’v’ does not mean that everybody has to
> represent their ecosystem model the same way.
>