Revision history [back]

Be careful the semantics of timestamp and dateModified are different.

timestamp captures as an ISO8601 timestamp when the associated measurement (represented as attribute value) was observed.

dateModified captures the last modification date and time of an attribute.

Typically dateModified will be >= than timestamp particularly on IoT networks such as SIGfox or Lora that only transmit data at certain time slots.

literally from the guidelines:

Use a metadata attribute named timestamp for capturing the last update timestamp of a dynamic attribute. Please note that this is the actual date at which the measured value was obtained (from a sensor, by visual observation, > etc.), and that date might be different than the date (metadata attribute named dateModified as per NGSIv2) at which the attribute of the digital entity was updated, as typically there might be delay, specially on IoT networks which deliver data only at specific timeslots."

With regards to the particular example of this question, batteryLevel is an observed value, so a timestamp makes sense, even though the attribute may have a dateModified metadata as well.

On the other hand it has been considered that configuration is a kind of semi-static attribute which, informatively, conveys the device's current configuration. As it is not bounded to any measurement, it is only used the dateModified attribute. If it happens that you want to capture the date and time on which such configuration was made effective on the device, (provided there is some kind of automatic configuration procedure) then it would make sense to add another metadata representing such instant of time. But, we have assumed that in this case this distinction might not very relevant, and as a result we only propose to use the dateModified attribute.

I hope this clarifies.

Be careful the semantics of timestamp and dateModified are different.

timestamp captures as an ISO8601 timestamp when the associated measurement (represented as attribute value) was observed.

dateModified captures the last modification date and time of an attribute.

Typically dateModified will be >= than timestamp particularly on IoT networks such as SIGfox or Lora that only transmit data at certain time slots.

literally from the guidelines:

Use a metadata attribute named timestamp for capturing the last update timestamp of a dynamic attribute. Please note that this is the actual date at which the measured value was obtained (from a sensor, by visual observation, > etc.), and that date might be different than the date (metadata attribute named dateModified as per NGSIv2) at which the attribute of the digital entity was updated, as typically there might be delay, specially on IoT networks which deliver data only at specific timeslots." timeslots.

With regards to the particular example of this question, batteryLevel is an observed value, so a timestamp makes sense, even though the attribute may have a dateModified metadata as well.

On the other hand it has been considered that configuration is a kind of semi-static attribute which, informatively, conveys the device's current configuration. As it is not bounded to any measurement, it is only used the dateModified attribute. If it happens that you want to capture the date and time on which such configuration was made effective on the device, (provided there is some kind of automatic configuration procedure) then it would make sense to add another metadata representing such instant of time. But, we have assumed that in this case this distinction might not very relevant, and as a result we only propose to use the dateModified attribute.

I hope this clarifies.