Subject: Re: [core] [SenML] Multiple values in a measurement

From: Michael Koster <[email-masked]>
Date: Wed, 7 Nov 2018 09:38:01 -0800

Here is one possibility:

[
  {
    "bn": "inertialmeasurement",
    "bu": "rad/s",
    "n": "xvalue",
    "v": 0.34,
  },
  {
    "n": "yvalue",
    "v": 1.43,
  },
  {
    "n": "zvalue",
    "v": 0.23,
  }
]

Or as an IPSO Smart Object representationfor the accelerometer object type (3313):

[
  {
    "bn": "3313/0/",
    "n": "5701",
    "vs": "rad/s",
  },
  {
    "n": "5702",
    "v": 0.34
 },
  {
    "n": "5703",
    "v": 0.34
 },

  {
    "n": "5704",
    "v": 0.34
 }
]

On Oct 18, 2018, at 1:35 AM, Shantanoo Desai <[email-masked]> wrote:
> 
> Hello all,
>  
> In a practical scenario there are sensors that provide more than one values, for e.g., an Inertial Measurement Unit (IMU) will provide Euler Angles as Yaw, Pitch, Roll indicating orientation of the sensor node or an Accelerometer which measures linear acceleration in X, Y, Z directions.
>  
> Is there any schematic in SenML that would support multiple values?
>  
> From my understanding there is none and most values are indicated by the field “v” as a single key:value pair in JSON.
>  
>  
> Even if I split the reading into three, there might not be clear distinction since “n” always remains the same (the sensor name is always “inertialmeasurement”)
>  
>  
>  
> Is there a way to inculcate such features into senML or is there a way around this that I have overlooked?
>  
>  
>  
> Mit freundlichen Grüßen
>  
> 
> i. A. M.Sc. Shantanoo Desai
> Wissenschaftlicher Mitarbeiter
>  
> BIBA - Bremer Institut für Produktion und Logistik GmbH
>  
> Informations- und kommunikationstechnische Anwendungen in der Produktion
> Prof. Dr.-Ing. Klaus-Dieter Thoben
>  
> Raum 1390
> Tel: +49 (0)421 218-50138
> Handy: +49 162 6536 107
> [email-masked] <mailto:[email-masked]>
>  
>  <https://www.linkedin.com/company/biba.uni-bremen.de>  <https://www.researchgate.net/institution/BIBA-Bremer_Institut_fuer_Produktion_und_Logistik>   <https://www.facebook.com/BIBA.Produktion.Logistik>   <http://www.youtube.com/channel/UCieF5Uq5Qix9XZAZuYhTQhg> 
>  
> BIBA – Bremer Institut für Produktion und Logistik GmbH
> Postanschrift: Postfach P.O.B. 33 05 60 · D-28335 Bremen / Germany
> Geschäftssitz: Hochschulring 20 · D-28359 Bremen / Germany
> USt-ID: DE814890109 Amtsgericht Bremen HRB 24505 HB
> Tel: +49 (0)421/218-02  Fax: +49 (0)421/218-50031
> E-Mail: [email-masked] <mailto:[email-masked]> · Internet: www.biba.uni-bremen.de <http://www.biba.uni-bremen.de/>
> Geschäftsführer: Prof. Dr.-Ing. K.-D. Thoben, O. Simon
>  
>  
> <oledata.mso>_______________________________________________
> core mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 8 Nov 2018 08:18:04 +0100

> Or as an IPSO Smart Object representationfor the accelerometer object type (3313):

careful here: bn+n needs to be globally unique and can't rely on its
retrieval URI to disambiguate.

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Ari Keränen <[email-masked]>
Date: Thu, 8 Nov 2018 08:31:00 +0000

Also probably worth noting that if you have more thank one set of 
triples in a single SenML Pack, you can link them together using the 
time field.

Cheers,
Ari

On 08/11/2018 0.38, Michael Koster wrote:
> On Oct 18, 2018, at 1:35 AM, Shantanoo Desai <[email-masked] 
> <mailto:[email-masked]>> wrote:
>>
>> Hello all,
>> In a practical scenario there are sensors that provide more than one 
>> values, for e.g., an Inertial Measurement Unit (IMU) will provide 
>> Euler Angles as Yaw, Pitch, Roll indicating orientation of the sensor 
>> node or an Accelerometer which measures linear acceleration in X, Y, Z 
>> directions.
>> From my understanding there is none and most values are indicated by 
>> the field “v” as a single key:value pair in JSON.
>> Even if I split the reading into three, there might not be clear 
>> distinction since “n” always remains the same (the sensor name is 
>> always “inertialmeasurement”)
>> __
>> *i. A. M.Sc. Shantanoo Desai***
>>
>> *BIBA**- Bremer Institut für Produktion und Logistik GmbH*
>> <https://www.linkedin.com/company/biba.uni-bremen.de> 
>> <https://www.researchgate.net/institution/BIBA-Bremer_Institut_fuer_Produktion_und_Logistik> 
>> <https://www.facebook.com/BIBA.Produktion.Logistik> 
>> <http://www.youtube.com/channel/UCieF5Uq5Qix9XZAZuYhTQhg>
>> E-Mail:[email-masked] 
>> <mailto:[email-masked]>· Internet:www.biba.uni-bremen.de 
>> <http://www.biba.uni-bremen.de/>
>> https://www.ietf.org/mailman/listinfo/core
>

---

From: Michael Koster <[email-masked]>
Date: Thu, 8 Nov 2018 10:17:41 -0800

Hi Christian,

I don't believe RFC8428 places any normative constraints on the scope of the identifiers that result from bn+n, either in section 4.5.1 names or 4.6 resolved records. 

It recommends URI or URN, which aren't required to resolve to exclusive identifiers in any particular scope. 

It seems like the word global is carefully avoided, and there is an example that uses a local and possibly short-lived identifier scheme:

   [
     {"bn":"2001:db8::2/","bt":1.320078429e+09,
      "n":"temperature","u":"Cel","v":25.2},
     {"n":"humidity","u":"%RH","v":30},
     {"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3},
     {"n":"humidity","u":"%RH","v":67}
   ]

I other words, I think the concept of uniqueness needs to be allowed to be defined in the context of use cases that may be outside the scope of RFC8428 to limit.

Specifically, I don't imagine there being a senML validator that would check for the uniqueness of bn+n resolved names. I don't even know how right offhand.

What do the authors say?

Best regards,

Michael

> On Nov 7, 2018, at 11:18 PM, Christian Amsüss <[email-masked]> wrote:
>

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 8 Nov 2018 19:37:16 +0100

Hi Michael,

On Thu, Nov 08, 2018 at 10:17:41AM -0800, Michael Koster wrote:
> I don't believe RFC8428 places any normative constraints on the scope
> of the identifiers that result from bn+n, either in section 4.5.1
> names or 4.6 resolved records. 

Quote:

| Name:  Name of the sensor or parameter.  When appended to the Base
|      Name field, this must result in a globally unique identifier for
|      the resource.

I'm not particularly fond of of that, but remember very clear reasoning
from the authors that having unique IDs in there is a stronger
requirement than playing nice with URI references.

> Specifically, I don't imagine there being a senML validator that would
> check for the uniqueness of bn+n resolved names. I don't even know how
> right offhand.

I figure "We funnel data from all our devices into our Enterprise
server whose database behaves like a concatenation of all SenML files"
was one application. That'd get confused quite fast if different devices
all reported their first accelerometer as "3313/0/".

> What do the authors say?

I'd be very happy to be told I'm wrong on this (it would allow more
elegant core-interfaces), and look forward to a response from them.

Christian

---

From: Ari Keränen <[email-masked]>
Date: Fri, 9 Nov 2018 11:58:26 +0000

> elegant core-interfaces), and look forward to a response from them.

Yes, one of the design principles was that SenML names need to be 
globally unique so that they can be used e.g., as data base keys without 
conflicts.

Cheers,
Ari

---

From: Michael Koster <[email-masked]>
Date: Fri, 9 Nov 2018 06:46:22 -0800

Oh, OK. 

I see the statement in 4.2
   Name:  Name of the sensor or parameter.  When appended to the Base
      Name field, this must result in a globally unique identifier for
      the resource.
I'm a little confused by what is a resource and what is a senml pack. I guess each senl pack needs to be bound to some globally unique resource?

How would I validate that?

Also, Is the example in the RFC wrong? This doesn't resolve to a globally unique identifier 

   [

To summarize, it seems overly restrictive to the general use of senml to require that each senml pack be identified with a globally unique resource. (please correct me if I mis-stated this)

Best regards,

MIchael

> On Nov 9, 2018, at 3:58 AM, Ari Keränen <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 10 Nov 2018 06:00:20 +0700

>      {"n":"humidity","u":"%RH","v":67}

In RFCs, 2001:db8::x is code for “an IP address".  That is “globally unique” (unless RFC 1918, which we don’t have in IPv6).  Obviously its ownership can change over time.  But that is then disambiguated by bt/t.

> To summarize, it seems overly restrictive to the general use of senml to require that each senml pack be identified with a globally unique resource. (please correct me if I mis-stated this)

This is a choice that we did debate a lot.  The RFC documents the outcome of that debate.  The other choice would have been valid as well.

(My personal view is that an RFC 6919 “MUST (BUT WE KNOW YOU WON’T)” would have been closer to what we’ll find in real world use of SenML.  But at least we gave an incentive to other SDOs to look for ways to obtain unique identifiers.)

Grüße, Carsten