Subject: [core] core-interfaces: SenML unit in link format response

From: chrysn <[email-masked]>
Date: Fri, 2 Aug 2013 19:04:38 +0200

hello people who are interested in core-interfaces and SenML,

as of implementing a data logger that heavily relies on SenML and
core-interfaces in describing its resources, it occurred to me that most
of SenML can be viewed as a way to collect many resources that reside
under a resource (or, when used as core.[l]b, resources that are
scattered on a server).

for example, the queries

> GET /s/light
< OK text/plain
< 123

> GET /s/temp
< OK text/plain
< 27.2

etc.

can be collected to the single query

> GET /s
< OK text/plain
< {"e":[
<       {"n":"/s/light", "v":123, "u": "lx"},
<       {"n":"/s/temp", "v":27.2, "u": "degC"}
< ]}

. several details of the SenML response (eg. name, value, update time) can be
mapped to HTTP or CoAP resource data (eg. url, resource representation,
max-age, respectively).

apart from time stamps (which are often 0, and if not, the response
might contain more than a single representation), an important piece
SenML information that can't be easily mapped to CoAP or HTTP are the
units.

i'd like to publish the units in /.well-known/core, so that the
information can be used even by clients that only support plain text
requests, or to get the information to clients that will always observe
(and to keep packages small will choose the smallest representation,
text/plain). three approaches come to my mind, in order of decreasing
preference:

* </s/light>;if="core.s";rt="core.unit.lx" -- register in the rt=
  subregistry of core-parameters

* </s/light>;if="core.s";unit="lx" -- register at link-relations

* use mime-type parameters -- would work for http, but would need an
  individual content-format codepoint in coap

which approach do you consider most promising?

best regards
chrysn

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

---

From: chrysn <[email-masked]>
Date: Fri, 2 Aug 2013 19:15:41 +0200

hello core-interfaces authors,

when researching for the "SenML unit in link format response" post, i
discovered that core-interfaces, in several places, uses the "n"
parameter of SenML in a way that looks reasonable, but contradicts
draft-jennings-senml-10.

particular examples (some lines removed):

>    Req: GET /s
>    Res: 2.05 Content (application/senml+json)
>    {"e":[
>        { "n": "humidity", "v": 80, "u": "%RH" }],
>    }

>    Req: GET /s/humidity (Accept: application/senml+json)
>    Res: 2.05 Content (application/senml+json)
>    {"e":[
>        { "n": "humidity", "v": 80, "u": "%RH" }],
>    }

>    Req: GET /l
>    Res: 2.05 Content (application/senml+json)
>    {"e":[
>       { "n": "/s/humidity", "v": 80, "u": "%RH" }],
>    }

while it is clear from the context that the values "80" are
representations of the /s/humidity resource, the senml spec says:

>    The Name value is concatenated to the Base Name value to get the name
>    of the sensor.  The resulting name needs to uniquely identify and
>    differentiate the sensor from all others.  If the object is a
>    representation resulting from the request of a URI [RFC3986], then in
>    the absence of the Base Name attribute, this URI is used as the
>    default value of Base Name.  Thus in this case the Name field needs
>    to be unique for that URI, for example an index or subresource name
>    of sensors handled by the URI.

concatenation would, in these cases, give the values

> scheme://host/shumidity
> scheme://host/s/humidityhumidity
> scheme://host/l/s/humidity

respectively. even if it was assumed that the concatenation followed the
rules of relative url concatenation (like in hyperlinks, i don't know
where that is defined), the resulting urls would be

> scheme://host/humidity
> scheme://host/s/humidity
> scheme://host/s/humidity

, which is better but still not there yet. (what makes it even more
difficult, we'd have to distinguish between "GET /s/" and "GET /s", of
which i'm not sure how it is mapped to CoAP -- would the former contain
an empty Uri-Path option?)

i kindly ask for clarification.

best regards
chrysn