You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's actually a fourth type of attribute/property - TemporalProperty, but that is kind of hidden.
Users aren't allowed to create a property of the type "TemporalProperty", but there is one "timestamp" that can be set by users.
NGSI-LD admits three different Temporal Properties:
modifiedAt
crateadAt
observedAt
The two first are builtins, set by the broker and only observedAt is user-defined.
Its format is on key-value basis:
"observedAt": "2020-11-15T10:00:00.000Z"
and, the broker will convert the timestamp into a floating point value, internally.
This to be able to easily compare the timestamp with other timestamps (I imagine QL does the same).
Note though that the timestamps are converted back to ISO8601 form in queries and notifications.
About compound property values with "@type" and "@value", Orion-LD doesn't modify the value but keeps it as is.
This is actually something I've been thinking of taking up with ETSI ISG CIM but I haven't had any time for that still.
T1 could be saved as a floating point for simpler and faster comparisons.
However, in the notifications that QL receives from the broker, T1 would always be converted back to its original form.
I believe this should be transparent to the subscriber (i.e. QL, Cygnus et al).
About compatibility questions, the easy answer is that:
if NGSI-LD, simply compact entity types and attr names according to the current @context
If NGSIv2, send the longnames without compaction.
The "not so easy" answer is that some features (datasetId) are simply not supported by NGSIv2 and there's probably no solution for this (well, if we really want to, there's always a way ...).
An attribute with datasetIds (or: multi-instances) are represented as an array in NGSI-LD, while that would provoke an error in NGSIv2:
My personal opinion is that this concept of notifying in NGSIv2 is a temporary thing that we may use with some constraints until we implement support for NGSI-LD.
BTW, the whole datasetId concept is quite complex and only partially implemented in Orion-LD as of today.
Right now I can't think of any other problems we may find.
As reported by @kzangeli:
There's actually a fourth type of attribute/property - TemporalProperty, but that is kind of hidden.
Users aren't allowed to create a property of the type "TemporalProperty", but there is one "timestamp" that can be set by users.
NGSI-LD admits three different Temporal Properties:
The two first are builtins, set by the broker and only observedAt is user-defined.
Its format is on key-value basis:
"observedAt": "2020-11-15T10:00:00.000Z"
and, the broker will convert the timestamp into a floating point value, internally.
This to be able to easily compare the timestamp with other timestamps (I imagine QL does the same).
Note though that the timestamps are converted back to ISO8601 form in queries and notifications.
About compound property values with "@type" and "@value", Orion-LD doesn't modify the value but keeps it as is.
This is actually something I've been thinking of taking up with ETSI ISG CIM but I haven't had any time for that still.
For example:
T1 could be saved as a floating point for simpler and faster comparisons.
However, in the notifications that QL receives from the broker, T1 would always be converted back to its original form.
I believe this should be transparent to the subscriber (i.e. QL, Cygnus et al).
About compatibility questions, the easy answer is that:
The "not so easy" answer is that some features (datasetId) are simply not supported by NGSIv2 and there's probably no solution for this (well, if we really want to, there's always a way ...).
An attribute with datasetIds (or: multi-instances) are represented as an array in NGSI-LD, while that would provoke an error in NGSIv2:
"P1": [
{
"type": "Property",
"value": 4,
"datasetId": "urn:ngsi-ld:xxx:north"
},
{
"type": "Property",
"value": 9,
"datasetId": "urn:ngsi-ld:xxx:south"
}
]
My personal opinion is that this concept of notifying in NGSIv2 is a temporary thing that we may use with some constraints until we implement support for NGSI-LD.
BTW, the whole datasetId concept is quite complex and only partially implemented in Orion-LD as of today.
Right now I can't think of any other problems we may find.
Originally posted by @kzangeli in #373 (comment)
The text was updated successfully, but these errors were encountered: