search

eclipse-archived / unide

Eclipse Public License 1.0
29 stars 17 forks source link

v3 - unit as string is insufficent #44

Closed alaendle closed 5 years ago

alaendle commented 5 years ago

I really like the idea to be more specific about the measuring units and also the reference to https://tools.ietf.org/html/draft-ietf-core-senml-14#section-12.1, but I fear that to really have some a general semantic on measurements a simple string representation of units isn't enough.

For example in some context millimetres could be a a useful unit for some measurement; and it wouldn't make sense to convert to meters just for unide (also it wouldn't make sense to display the translated values in systems like Nexeed PPM). So we will face different units (mm, cm, m, inch) for the same measured without any connection.

So I believe that the protocol should expand it's unit representation at least by two optional fields.

ameinhardt commented 5 years ago

This is very redundant to be transmitted in every payload. And how to specifiy non-trivial calculations, like cartesian to polar coordinates? We couldn't agree on a fixed unit norm, so context>unit would be the custom indicator. The sender / receiver of the telegram should have an understanding of how to process this. If in doubt, they can use context>namespace as an additional clarification.

alaendle commented 5 years ago

O.k. if unide assumes that sender/receiver shares a vision about the meaning of data the current draft allows a adequate representation of units. And thanks for noting the namespace - if needed this allows a reference to a semantic specification of the unit (e.g. http://data.nasa.gov/qudt/owl/unit#Centimeter) - however still sender/receiver need to agree on this (it's nothing the unide format supports natively; but I think it's also not the goal of unide to allow a complete semantic specification of its telegrams).