Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NGSI-LD TemporalProperty support #395

Closed
chicco785 opened this issue Nov 18, 2020 · 2 comments
Closed

NGSI-LD TemporalProperty support #395

chicco785 opened this issue Nov 18, 2020 · 2 comments

Comments

@chicco785
Copy link
Contributor

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:

  • 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.

For example:

{
  "T1": {
    "type": "Property",
    "value": {
      "@type": "DateTime",
      "@value": "2020-..."
    }
}

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:

"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)

@github-actions
Copy link
Contributor

Stale issue message

@chicco785
Copy link
Contributor Author

chicco785 commented Sep 1, 2021

temporal property support should be fixed by #496

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant