search

telefonicaid / fiware-orion

Context Broker and CEF building block for context data management, providing NGSI interfaces.
https://github.com/telefonicaid/fiware-orion/blob/master/doc/manuals/orion-api.md
GNU Affero General Public License v3.0
212 stars 265 forks source link

Should be the CB more flexible with dates/geo types allowing nulls/""? #3533

Closed fgalan closed 3 years ago

fgalan commented 5 years ago

Allow "" and null in DateTimes/ISO8601 and geo:xxx. This would be easier the life for clients.

mrutid commented 5 years ago

There are (real) situations where you don't have a specific date or location for an attribute. Right now it is necessary to DELETE the attribute itself in order to manage this scenario (and it implies to develop non-trivial and special behaviours in GUI and FORMS for these two types) It would be nice to allow empty/null values for these types.

jmcanterafonseca commented 5 years ago

NGSI-LD does not allow nulls. You can always define a dummy location (empty object) or dummy date (1st Jan 1970) to flag an unknown value ...

fgalan commented 5 years ago

You may have wrong reports or analytics if you use dummy dates, locations (or dummy data in general) or you will need special processing to adapt reports to your "dummy data conveys". NULL has a clear, global, common semantic (and wide system/framework support) and IMHO is a good value to express "void/unknow".

So in NGSI_LD what would you plan to use as an "unknown" integer value? will it be 0? -99999?... it will be difficult to make analytics with that fake data.

Anyway we can discuss this NGSI-LD particularity, and the interoperability options with NGSIv2, when it start the merging process.

jmcanterafonseca commented 5 years ago

my point is that if something is not known why it should appear as an Attribute value of an Entity at a particular point in time?

for instance, if a device is not available or is out of service then in that case an IoT Agent should not be updating anything to the CB, and let the value as it was before (either non-present or with its previous value).

fgalan commented 4 years ago

my point is that if something is not known why it should appear as an Attribute value of an Entity at a particular point in time?

To make easier the life for clients, as my first entry in the issue tells :)

I mean, ideally, it can be as you said so if the client doesn't have the data, it doesn't send an attribute with it. But some clients (due to they have "fixed" the attributes they send and cannot omit them, I understand IOTAs are of that kind generally) cannot do that, and, in that case, null seems to be a good option from a semantical point of view.

jmcanterafonseca commented 4 years ago

maybe the IoT Agents should be fixed. It provides a more useful insight the old value of an Attribute than overwriting it with null ... due to a failing sensor ....

fgalan commented 4 years ago

Related question at SOF (to be edited once this issue gets addressed): https://stackoverflow.com/questions/59642299/orion-context-broker-geolocation-how-to-deal-with-location-not-known

fgalan commented 3 years ago

PR https://github.com/telefonicaid/fiware-orion/pull/3846