Subject: [apps-discuss] Draft on representing values of sensors in JSON (draft-jennings-senml)

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Sep 2010 13:16:08 -0600

I'd love to get some feedback on 

http://www.ietf.org/id/draft-jennings-senml-03.txt

Abstract

   This specification defines media types for representing simple sensor
   measurements in JSON.  A simple sensor, such as a temperature sensor,
   could use this media type in protocols such as HTTP to transport the
   values of a sensor.

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 22 Sep 2010 07:34:09 +0800

> http://www.ietf.org/id/draft-jennings-senml-03.txt

Hi Cullen,

The Unified Code for Units of Measure might be of interest to you.  This is based on ISO 2599 and ANSA X3.50.  It might save you the need for a new registry.

  http://unitsofmeasure.org/

I have my own reservations about the grammar (too many special cases), but it seems a shame to waste all the good effort.

You also have a TODO on accuracy/confidence.  Additional optional attributes seem appropriate: in metrology, it's commonplace to describe a confidence interval.

Measurement quality attributes can be added:

  unc: the uncertainty in the measurement, that uses the same units as the base; if absent, the value is unknown (i.e., don't assume that this is zero)
  c: the confidence of the measurement, as a percentage; if absent, you can pick a default value

An alternative is to report RMS error, which is a common measure of quality where there are multiple samples taken, but only a mean value reported:

  rms: the RMS error in the measurements; if absent: unknown
  num: the number of samples taken; if absent: assume either a very large number such that RMS =~ standard deviation, or assume one (pick one)

In a lot of sensors, uncertainty and confidence are known, but discrete observations do not necessarily carry specific values for these.  Instead this is a known characteristic of the device.  Thus, it could make sense to carry a base value (a base uncertainty).  Within the format you describe, you will need to associate a base value with each sensor.

  { q: { [ n: "foo", unc: 0.43, c: 90 ] } }

I don't see any value in providing a valid time interval.  This is going to either be based on predictions that use measured values, or it's going to be virtually impossible to predict.  Any case where a measurand is time-varying is going to be known by the recipient for that recipient to do anything reasonable with the data.

Is the intent for the sensors to be labelled with a globally unique identifier?  If so, why?  I would have assumed that the identified source of data would provide some amount of disambiguation.

You have a lot of questions.  Is it really that much more of a burden for a constrained device to produce an RFC 3339 date+time?  Certainly, the size isn't going to be a significant burden.  Maybe you could have 'bt' include this value, and 't' can be left as a delta.  Certainly, I'd like to see a resolution of better than seconds.  Nanosecond resolution would be handy for something like location ;)

(Nit: Your examples have trailing commas.  The JSON syntax doesn't allow this.)

--Martin

p.s., I like this:

   ... The number of significant digits in any
   measurement is not relevant, so a reading of 1.1 has exactly the same
   semantic meaning as 1.10.  ...