How To Dev - How to perform Data Modeling

 

How to proceed to the Entity Modeling / Data Modelling:

• Define a formal table for each Entity Model, eventual exploitation of available entity models from some library such as those of: Snap4City IoT Device Models, FIWARE Smart Data Models. Both of them can be specialized, or in alternative a new custom Entity Model has to be defined.
  
  • Snap4City is GDPR compliant, but a certain attention has to be applied in collecting and using private data. All the data saved into Snap4City are private, while to make them public is a click which the owner of the Entity Instance (Device) can perform!
  • on Snap4City platform all data models are coded as an Entity Models / IoT Device Models.
  • Entity Models / Device Model can be created, imported and exploited from Snap4City Entity Directory / IoT Directory
  • Experts of Snap4City may directly create the Entity Models / IoT Device Model on the Entity Directory / IoT Directory tool

​

• Create one or more Entity Instances / IoT Devices from a single Entity Model / IoT Device Model, by providing some information such as the Identification/name and other static variables (see example in the Figure above). In Snap4City, a large number of tools allow to
  
  • create Entity Instances / IoT Devices from scratch and from Entity Model / IoT Device Model
  • massively create huge number of Entity Instances / IoT Devices from an Entity Model / Device Model via process in Bulk from file, and from Processing Tool / IoT App
  • massively create huge number of Entity Instances / IoT Devices from Data Table tool which create also the Entity Model / Device Model learning from an excel file and from it the device and Entity Instance Messaged / data messages.
• Any Entity Instance / IoT Device may change status and value over time, thus it may receive a large number of Entity Messages attached to it (see example in the Figure above). Those messages can describe the Entity Instance evolution over time of a set of attributes including:
  
  • state or versioning. For example, modelling a user profile, could change over time:  driving, sleeping, vacation, etc. 
  • variables or attributes (float, integer, etc.). For example, for a device modelling a Car we could have at a certain time and date (so called dateObserved, with value type = timestamp): position (lat, lon), velocity, acceleration, engine status, number of cycles per minute, travelled km, etc.
  • references to other Entity Instances / IoT Devices (in Snap4City, they coded as ServiceURI). For example, a Driver will have references to its own connected entities such as: DriverEvent, DriverHealthiness, and DriverAnalysis where information about tickets taken, analysis performed, changes of the driver license will be stored. Similarly, a Vehicle will have references to a VehicleEvent, with records for the maintenance of the vehicles, etc.
• see: https://www.snap4city.org/download/video/course/iot/
• see also: https://www.snap4city.org/download/video/course/di/

Please note that, in all the Snap4City Entity Models (IoT Device Models): Nature and Subnature (classification), Lat/Lon (GPS positioning), and Device in Mobility (yes or not) attributes (variable) of Entities/Devices are not replicated in all the other models, since they are defined for default for all the Entity Models and for all the Smart Data Models as well. In the figure here below, the differences from Entity Model (IoT Device Model), one of its instances the registered Entity Instance (IoT device) “park45” and a specific message over time for the park45 device are put in evidence. Please note that for:

• Entity Model (IoT Device Model): black strings are reporting model definition, while in red the set parameters for the model. In some cases, the model may not impose the protocol and broker.
• Entity Instance (IoT Device): in instantiating the part45 device from its Model, a number of parameters in red has been imposed.
• Entity Message (A temporal instance): a message over time (dateObserved, with value type = timestamp) and at a given location (GPS position) has been sent to the Entity Instance park45, also providing a set of changed values for the attributes/variables: FeeSlots, Humidity, Temperature, etc.

Figure: Example of Entity Model (IoT Device Model), Entity Instance (IoT Device) and
an Entity Message as temporal instance

• create Data Model Diagrams which describes the relationships among Data/Entities, and in particular on Snap4City, among the Entities Instances and Entities Messages (see the last Figure, right).
  • Connecting different kind of Entities Instances/Messages via ServiceURI, SURI: in fact the actual connections can be among Entity Instances and/or Entities Messages. Thus, creating a sort of Interaction Diagram of UML. Connections among Entities can be:
    • from a Static Attribute of an Entity Instance to another Entity Instance, as highlighted in green in the figure here below.
    • from a Value/Variable of an Entity Message of an Entity Instance to another Entity Instance, as highlighted in green in the image here below.

Figure: Connections among Entities Instances and Message: the example reports
a static connection and dynamic connection to change the car at a given timestamp.
Please note also change of position and other parameters, if needed

• Different kinds of relationships are possible depending on the Data Type used into the Entity Model (IoT Device Model), for example,
  • Single ServiceURI
  • Vector of ServiceURI (used only when simultaneous events occur, for example, list of changes performed to an Engine)
• To each ServiceURI, it is possible to refer to any kind of Entity Instances (IoT Devices, Mobile Devices, POI, etc.), it is a sort of pointer/reference. Once obtained the reference it is possible to ask at the Entity to provide its last values (as well as the value at a given dateObserved, with value type = timestamp), and thus accessing to its definition, a sort of reflection model of high-level programming paradigms.
  • For example, this means that it is possible to have attributes as ServiceURI and attaching to it some Entity Instance and its Messages for describing the occurred event:
    • Analysis, Maintenance, Ticket, Illness, Vacation, etc.

• Optionally: if you like you can create Entity Relationships diagrams among Entities, see UML, as a plus.

Figure: Example of a Dashboard and its graphical representation of the relationships among widgets, devices, Entity Instances and Entity Messages, etc.
The tool on the right side is called LOG, Linked Open Graph and it is accessible from the dialog of Dashboard manager.

 

The Snap4City tools for supporting the activity of Data Modelling are:

• Semantic Reasoner (accessible as ServiceMap/KnowledgeBase and SuperServiceMap) supporting the modelling of city entities in multiple and federate knowledge base, their semantic relationships and search, for they discovery, Entity/IoT Discovery, dynamic and autonomous data analytics as machine learning, and for development of applications in multiple domains: mobility and transport, tourism, health, welfare, social, etc. Extending the Km4City multi-domain semantic model (https://www.km4city.org ); Federation of Smart Cities via smart city API for large horizontal scaling and world scale coverage without expensive solutions.
• Entity Directory (IoT Directory) and service simplifying the creation of applications abstracting complexity of data models, Entity Instances, IoT Devices, IoT Edge, Brokers, IoT Brokers, protocols and data formats, exploiting the Semantic Reasoner, addressing FIWARE Smart Data Models, Snap4City Entity models (IoT Device Models), and any custom data model you may have; attaching in a few minutes External Brokers and registering their corresponding Entity Instances / IoT Devices into the platform, and thus into the Knowledge Base.
• Open-Source code for implementing and connecting IoT Devices and IoT Edge on Android, Arduino, Raspberry PI, Linux, Windows, ESP32, Arm, AXIS cameras, etc., with mutual authentication and encrypted communication, and Processing Logic / IOT App control from web page.
• All the High-Level Types can be created and manipulated by Processing Logic / IoT App and may be rendered on Dashboards from their corresponding Data Managers of the Data Management.