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

Carsten Bormann <cabo@tzi.org> Mon, 31 August 2020 20:19 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: t2trg@ietfa.amsl.com
Delivered-To: t2trg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4D83A1946 for <t2trg@ietfa.amsl.com>; Mon, 31 Aug 2020 13:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1V0EZ75wpaY for <t2trg@ietfa.amsl.com>; Mon, 31 Aug 2020 13:18:58 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528E93A1943 for <t2trg@irtf.org>; Mon, 31 Aug 2020 13:18:58 -0700 (PDT)
Received: from [192.168.217.102] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4BgM3h1V10zyVj; Mon, 31 Aug 2020 22:18:56 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <CAE5tNmoYSNPjndwo12O+RE+BdYG2bpadM1L6fAb+KKgairxkcw@mail.gmail.com>
Date: Mon, 31 Aug 2020 22:18:55 +0200
Cc: "asdf@ietf.org" <asdf@ietf.org>, "t2trg@irtf.org" <t2trg@irtf.org>
X-Mao-Original-Outgoing-Id: 620597935.6619591-ef8a1006a92bdfe8319c444c2ec2670e
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4218763-14BE-44DF-BB13-C248911CE84C@tzi.org>
References: <2ED86F4F-2926-4FBB-91A7-39F32FE7A970@tzi.org> <MWHPR11MB1838A7BB2F9D868DBF59B962D2510@MWHPR11MB1838.namprd11.prod.outlook.com> <BYAPR18MB2536E401A07C0F5DFF3376B6CE510@BYAPR18MB2536.namprd18.prod.outlook.com> <CAE5tNmoYSNPjndwo12O+RE+BdYG2bpadM1L6fAb+KKgairxkcw@mail.gmail.com>
To: One Data Model Group <onedm@iotliaison.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/t2trg/Q3Oq02zH_9wqB4V6FsDc8UaqeF0>
Subject: Re: [T2TRG] [One Data Model Group] [Asdf] Representation issues and protocol bindings
X-BeenThere: t2trg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IRTF Thing-to-Thing Research Group <t2trg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/t2trg>, <mailto:t2trg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/t2trg/>
List-Post: <mailto:t2trg@irtf.org>
List-Help: <mailto:t2trg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/t2trg>, <mailto:t2trg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Aug 2020 20:19:02 -0000

I think it is already relatively easy to find the right level of abstraction for information that can be expressed in SI units.  
(Units can be specified in SDF 1.0.)

SenML (RFC 8428) got that right, so I think we can follow that example in SDF.
We did have to make a little bit of a compromise (adding scaling prefixes in RFC 8798) in areas where the natural units are habitually scaled (there aren’t many electricity meters indicating J — it’s always kWh), but even here it should be easy to agree on a natural unit between domain experts.

But the problem remains how the ecosystem specifications can relate to the converged model if that had to abstract some more.  And that’s where the binding comes in.  To make ecosystem experts feel at home, we probably need to make this rather accessible.

For information that is a ratio to a reference value (e.g., a lamp an undefined metric of which can be set to a value between 0 to 100 %), SenML has “/”  (the dimensionless unit).  So we would normally not use percentages (or permille, or ppm, …), but a number that is typically clamped between 0 and 1.  Of course, most ecosystems will scale this to get an integer representation, and that is probably the largest source of variation (*).

Also, RFC 8798 is limited to linear scales (scale/offset).  For sound and RF power levels we can cheat with dB.  For lighting, the models are more complicated (which led to gamma and all that).  If different ecosystems use different models here, there may be no straightforward way to do the conversions.  So we have to be prepared to express these anyway.

Grüße, Carsten

(*) And that when it should have been plainly obvious that all IoT devices should express temperatures as an integer value in centikelvin (cK), so a 16-bit unsigned value from 0 to 65535 can express most real-life sensor values (between absolute zero and 382.2 °C), and simply subtracting 27315 and dividing by 100 gives you the value in °C :-)