[Device] value attribute

[dherykw]

Hello all,

We are working closely with this data model and it is very difficult for us to deal with the value attribute, maybe it is a good moment to split the data model into more specific structures.

Allow me to make a brief description of my proposal.

Current data model representation example:

Device Datamodel:
{
"id": "device-9845A",
"type": "Device",
"category": ["sensor"],
"controlledProperty": ["humidity","temperature"],
"controlledAsset": ["wastecontainer-Osuna-100"],
"ipAddress": ["192.14.56.78"],
"mcc": "214",
"mnc": "07",
"batteryLevel": 0.75,
"serialNumber": "9845A",
"refDeviceModel": "myDevice-wastecontainer-sensor-345",
"value": "h=65;t=21.2",
"deviceState": "ok",
"dateFirstUsed": "2014-09-11T11:00:00Z",
"owner": ["http://person.org/leon"]
}

Proposed data model representation example:

Device Datamodel
{
"id": "device-9845A",
"type": "Device",
"controlledAsset": ["wastecontainer-Osuna-100"],
"ipAddress": ["192.14.56.78"],
"mcc": "214",
"mnc": "07",
"batteryLevel": 0.75,
"serialNumber": "9845A",
"refDeviceModel": "myDevice-wastecontainer-sensor-345",
"deviceState": "ok",
"dateFirstUsed": "2014-09-11T11:00:00Z",
"owner": ["http://person.org/leon"]
}

Sensor Datamodel
{
"id": "temperature-9845A",
"refDevice": "device-9845A",
"characteristic": ["readable"],
"target": "temperature",
"type": "Sensor",
"metric": "ºC",
"value": "28.5"
}

{
"id": "humidity-9845A",
"refDevice": "device-9845A",
"characteristic": ["readable"],
"target": "humidity",
"type": "Sensor",
"metric": "%",
"value": "68"
}

Going a little further it would interesting even extract the communication protocol, leaving to the device data model the only responsibility of representing a device itself.

Best regards and thanks for your contributions. 👍

[fgalan]

What about just using the current model but with an structured values, as the following:

"value": {
  "type": "StructuredValue",
  "value":   {
    "temperature": 28.5
    "humidity": 68
  },
  "metadata": {
    "units": {
      "type": "StructuredValue",
      "value": {
        "temperature": "ºC",
        "humidity": "%"
      }
    }
  }
}

It is important to keep all the attributes together in the same entity. Otherwise, you would need to do several queries to get all the information (e.g. first to device-9845A and get which entities-sensor to retrieve, then a second query to temperature-9845A, then a third query to humidity-9845A and so on.

[dherykw]

Hi @fgalan

Thanks so much for your quick response.

One big request or many small ones. Be or not to be, that is... :)

Yes, I agree with you that one query better than two but once that you know the device_id you car retrieve all the sensors with one query. on the other hand, if you wanted all the temperature values of all the devices with the current data model the computational cost for the Orion would be considerably higher. So I think that it depends on the use case.

But I am not going to beat around the bush, nowadays it is impossible for us to represent the FIWARE data models using the current idas iot agents, we think that it is very tricky to define a config file that represents the current data models due to its heterogeneity. We know that it is very important to think about efficiency but we have to find a balance between efficiency and usability.

For that reason, we think that meet the data models and IoTAgents is a good idea.

[chicco785]

@fgalan i am not expert, but is the model you propose possible in IoT Agent?

[dherykw]

Hello @chicco785 this model is not possible because of this issue. issue549 :-(.

But even fixing it we have the feeling that we could have a problem with the lazy attributes, for that reason we have proposed the data model representation review.

[chicco785]

we could look into supporting that, i have to check if we have spare resources to invest. i think it is an important feature. the important point is that this is also supported then in context broker properly, but i suppose it is the case.

@dherykw what would be the issue with lazy values? I think we can think of a way to "populate" only specific values in the structured data model, no?

what about metadata, is that also something not supported in the agents?

[fgalan]

@fgalan i am not expert, but is the model you propose possible in IoT Agent?

Not sure. But in the case it is not possible now nothing precludes IoT Agent to support it if needed. As I it has been mentioned above, it seems to be a matter of implementing a pending issue.

[fgalan]

So I think that it depends on the use case.

Is not the current model flexible enough to cope with both use cases? If not, it should, from my point of view.

[chicco785]

I think we proposed in SmartSDK to allow a device to be a collection of other devices.
This would support the scenario IMHO

[dherykw]

@chicco785 we think that we could have problem at the moment of extract the resource to do the real operation (read/write/execute) to the device, we are still studying the code but like Perl, JavaScript is that kind of write-only languages that are quite difficult to collaborate. Indeed we are a little bit sad for the new keyrock implementation in nodejs :(.

@fgalan of course that this data model support all the use cases indeed we think that are too much open and it qwill difficult the interoperability between applications, cross vertical and between different deployments.

[fgalan]

@fgalan of course that this data model support all the use cases indeed we think that are too much open and it qwill difficult the interoperability between applications, cross vertical and between different deployments.

Maybe the solution is to define clearly the two variants (a kind of sub-models) so each vertical/application can state clearly if it support one, the other or both. That way interoperability will not suffer.

Just thinking aloud... :)

[dherykw]

I think that this could solve some problems but it will introduce others.

May be we could have a nice talk in the FIWARE submit about it. :-)

Best

[dherykw]

Hi guys,

The lazy attribute problem could be overcome, we have our LwM2M IotAgent representing multi-entity and the structured value like @fgalan proposed, even so, we think that current data model definitions will difficult the cross-vertical solutions, but we comply with the FIWARE standard. :-)

Regards

[jmcanterafonseca]

Future-wise I prefer to evolve towards what is going to be defined by iot.schema.org (W3C is creating a new CG on that) rather than changing existing Data Models.

https://github.com/iot-schema-collab

[dherykw]

Hello @jmcanterafonseca

We understand the benefits and importance of adopting standards, and more if they are deffined by W3C, but we have to have in mind that the current IDAS will not be able to represent these data models, the should be almost fully rewritten. I can observe that the models defined by W3C are very heterogeneous which is going to add a lot of complexity to the IDAS development (even the current data models have difficulties to be represented by the current IDAS implementation).

But let suppose that we overcome these technical problems and we are able to represent multy enitty devices inside the OCB adopting the iot-schema like a charm, the data model's heterogeneity is so hight that same entities could be represented using different fields, Big Data engineers spend more than the 90% of their time normalizing data retrieved from different fonts, it would be a pity that this problem could be found inside FIWARE because this will break with all the interoperability and cross-vertical principles of FIWARE.

We see schema like a good reference point, but at the end of the day, when you start a collaborative development, you take the schema and agree with the other partners which field are you going to use in order to do the solution work, we see FIWARE like this agreement.

Best Regards.