aws-samples / aws-stf-core

Smart Territory Framework Core
14 stars 4 forks source link

Provide @context when interacting with the STF IoT module #4

Closed thanospan closed 1 year ago

thanospan commented 1 year ago

Hi, it is mentioned in the README file that there is no @context provided when interacting with the STF IoT module and that the Smart Data Models @context will be added before updating the Context Broker. The Smart Data Models @context is used in parameters.ts. However, it is stated here that this file is obsolete and is only there for historical reasons.

In fact, when creating a Device entity the URI https://uri.fiware.org/ns/data-models#Device is used instead of https://smartdatamodels.org/dataModel.Device/Device.

Would it be possible to provide @context when provisioning new things using the STF IoT module?

alifrugal commented 1 year ago

Hi, You don't need to provide the context when registering a new thing in the STF IoT module as no expansion (JSON-LD) is done before the context broker. So the context is only used in the context broker. If you want to change the context used in the context broker when storing a device you can change it in the parameters.ts file.

thanospan commented 1 year ago

Thanks @alifrugal for the prompt reply!

If I understand correctly, changing smart_data_model_url in parameters.ts would require having a single @context containing all terms defined by the Smart Data Models. While this file exists, most URIs seem outdated and many properties are missing.

An updated version of this file could be generated using this @context merger by providing all available Smart Data Models subjects as a config file. However, this would require resolving a large number of conflicts.

I was wondering if @context could be provided when interacting with the STF IoT module, forwarded to the lambda function and used when storing entities in the context broker. For example, when provisioning a new Device this @context could be used. Similarly, a data producer could use this @context when sending data about a ParkingSpot.

Do you think this approach could be considered or are there any drawbacks?

alifrugal commented 1 year ago

yes, it's a good practice to have a central context file (if possible hosted in your environment) with all the properties used. You can merge and create your own context and then upload it somewhere the context broker can fetch it to expand the NGSI-LD entity. You could pass the context through the STF IoT per Data Producers by just modifying the code to do so (get the "@context" property of the NGSI-LD entity in the Lambda function that updates the context broker and use it when sending the entity to the context broker). But note that the expansion is not done before the context broker so this property "@context" would be stored in the IoT shadows and in the IoT Data Lake be not used.