Re: [core] SenML and its use in core-interfaces (follow-up on bn/n URI clarification)

[Cullen Jennings <[e-mail]>]

Might be good to have a short phone call about this. I don't think I understand what problem we are trying to solve.

Most the sensors I am dealing with do not have long term stable DNS names. In fact often IP addressed only and in a non unique address space. 

So the HTTP URL one might be doing a HTTP GET on might look like 

http://192.168.0.2/s/temperature" class="" rel="nofollow">http://192.168.0.2/s/temperature

And might return 

[

     {"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}

]

Note that one of the key principals of SenML is that the name "must result in a globally unique identifier for the resource." This is a key property and critical to applications that process SenML for analytics , ML etc. 

The above is what I mostly what I was thinking about but I can easily imagine that there might be some cases where the device has a long term stable DNS address. So perhaps we have a light bulb that has the long term stable DNS name http://light22.building3.example.com" class="" rel="nofollow">light22.building3.example.com and has a light and temperature resources 

I can imagine that an HTTP GET on 

http://light22.building3.example.com/s" class="" rel="nofollow">http://light22.building3.example.com/s/

returning 

[

{ "bn":"http://light22.building3.example.com_s" class="" rel="nofollow">light22.building3.example.com-s-" }

{"n": "light", "v": 123, "u": "lx"},

{"n:" "temp", "v": 27.2, "u": "degC"}

]

I do not think we should support turning a SenML document where you can only figure out the unique name of the sensor is by looking at information outside the SenML document. 

So with that context ... I thought we had fleshed out a way for the URI approach to work and it was the "bn" indicated effectively the HTTP ref. 

I do not think that 

[{"n": "/s/light", "v": 123, "u": "lx"}] 

is a valid SenML in because the name is not globally unique.  If we added an bh (or h) attribute that looked like 

 [{     "h": "http://light22.building3.example.com/s/" class="" rel="nofollow">http://light22.building3.example.com/s/"

"n": "light", "v": 123, "u": "lx"}] 

Where the h is the same as the URL in the GET, I can see how we could get that transform to something that might work but is seem more or or less the same as using "n" or "bn". 

So with all that said .... I don't think I am clearly understanding what the problems is we are trying to solve. 

Thanks, Cullen

On Mar 24, 2017, at 6:31 AM, Christian Amsüss <[e-mail]> wrote:

Hello SenML authors, and hello CoRE Interfaces authors,

I'd like to follow up on the IETF96 (Berlin) discussion on using URIs
with SenML after reviewing the mails on the topic and the discussion
footage. The point of the URI concatenation discussion back then was to
allow CoRE Interfaces to do what they are currently doing, being

GET /l/
[{"n": "/s/light", "v": 123, "u": "lx"},
{"n:" "/s/temp", "v": 27.2, "u": "degC"}]

which is supposed to mean the /s/light and /s/temp resources on the
origin server, and not /l//s/light etc. as it will by the SenML spec.


In the Berlin discussion, there was a rough agreement on taking a route
where URI users could use a different attribute to denote their
anchor/href; this would avoid the pitfalls of doing URI concatenation
wrong for people who don't use URIs there anyway.

This has not been fleshed out or at least explored since then AFAICT,
and I'd like to at least see that there is a route of extensions CoRE
interfaces can use if we publish SenML as it is now.

Two questions need answering IMO:

* Do we want to be able to share documents between "URI users" and
 "non-URI users"? In many cases this will be possible; for example,
 batches (as opposed to linked batches as above) would just work with
 the current name building, and thus be usable by non-URI-aware clients
 as well.

* If we want to keep them apart, how would we deal with the requirement
 of having mandatory uniquely identifying names? A linked batch would
 certainly not want to repeat names once in "n" and once in "h"
 notation.


For a strawman proposal, I'd assume the answers are "we want to allow
mixed usership", and "the unique name requirement stays". Then we could
construct an extension like this:

Resolved records have, in addition to their name, a URI name ("href"),
which is optional to use but can be mandated to use in certain
applications (eg. CoRE interfaces). The URI name is formed by doing
RFC3986 relative URI resolution of the "h" property relative to the "bh"
base attribute relative to the requested URI. If the "h" property is
absent on a record, its "n" property provides a default value. If the
"bh" property is absent on the first record, the "bn" property provides
a default value.

This scheme has the properties that

+ Batches (or generally, collections that worked so far) work equally
 well for non-URI and URI users.
+ Representations stay as compact as they are.
+ The CoRE interfaces can refer to the records' URI names and thus be
 sure that users must take the necessary steps to resolve relativities
 correctly, while simpler SenML users arrive at resolved names by
 concatenating.
~ Evaluating the name of, say, linked batch resources still gives a
 unique name. It might or might not be a valid URI, and might or might
 not be dereferncable, but since it's agreed on that a name is not
 necessarily a URI, that's OK. For example, the linked batch of the
 first example would give resolved "n":"coap://host/l//s/light" (or
 even, for other examples, "n":"coap://host/l/http://remote/resource"),
 but that would still be a unique name.
- It doesn't survive representation as Resolved Records. (But are they
 intended to be serialized again at all? How do other extensions cope
 with Resolved Records?)
- It defines properties that would, in actual use, barely (if at all)
 show up. In particular, the CoRE Interfaces examples could stay as
 they are and never use "h"/"bh". If we just dropped the arguments and
 only defined a URI property, we're even worse again in the next point:
- This has a smell of applications defining how to interpret the name,
 which is what Cullen has already argued against in the July thread.

If we can live with the above downsides or those of another form of URI
extension (which might have fewer or others), then I think we can
procede with SenML as it is, otherwise we should either come up with a
better URI story, or need SenML to accomodate such uses.

What do you think?

Best regards
Christian

--
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[e-mail]  | Arbeitergasse 15, A-4400 Steyr
tel:[phone]                | http://www.energyharvesting.at/" class="" rel="nofollow">http://www.energyharvesting.at/
                                     | ATU68476614
_______________________________________________
core mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/core