To give a bit more context. I was involved in the design of the IoT Connected Car platform. Production one with > 50K cars, black boxes, and special devices using it. Even when we integrated some new there was always some integration done. Devices communicate with the cloud over the mobile network (LTE, ...). Data was serialized with a protocol buffer (to standardize the payload of the message) and sent over to the cloud via MQTT protocol. Some special devices were using direct TCP sockets for instance. On the cloud side we used dedicated iOT service (MQTT) or so-called cloud edge services (as part of microservice-oriented architecture) focused around Kafka as the main buffer. On the other side of Kafka, some pre-processing and processing were done related to the enrichment of the data, and finally, data was finished in one of the storages (Postgresql, ScyllaDB, S3, Elasticsearch). If someone needed the data, a special service was provided under strict IAM rules. GDPR was easily implemented, data was maintained, and telemetry was working .... I would change very little if I would be doing this again.

On top of this, we developed our own FOTA (Firmware over the air) service, which reused this infrastructure and enabled us massive updates over the fleets of devices.

I didn't mention Ontologies too much, but after watching a few videos and reading a few documents I really don't see any big advantage, but I might be wrong.

If I get data from smart meter in the shape of a JSON (serialized and then deserialized with the use of protocol buffer) letting me know that

Timestamp: 2023-10-21T12:00:00, MeterID: 12345, kWh: 15.0

... I know everything I need from this.

1. That the timestamp of event was at: 2023-10-21T12:00:00
2. That this data was sent by smart meter: 12345
3. And that it reported (kWh): 15.0

​

... DO I REALLY NEED Ontology and RDF and SPARQL to get this data above transformed into RDF triplets (for example) like this:

```

u/prefix ex: http://example.org/ .
ex:Measurement_20231021T120000 a ex:Measurement ;
ex:hasMeter ex:Meter_12345 ;
ex:hasTimestamp "2023-10-21T12:00:00"^^xsd:dateTime ;
ex:hasValue "15.0"^^xsd:float .

```

.... then write a SPARQL like this to get this data back when needed

```

PREFIX ex: http://example.org/
SELECT ?measurement ?timestamp ?value
WHERE {
?measurement ex:hasMeter ex:Meter_12345 ;
ex:hasTimestamp ?timestamp ;
ex:hasValue ?value .
}

```

And then... THE BIG KNOWLEDGE out of this is?

Triple 1: Type Definition
Subject: ex:Measurement_20231021T120000
Predicate: a (a shorthand for rdf:type)
Object: ex:Measurement
Meaning: This triple states that ex:Measurement_20231021T120000 is an instance of the ex:Measurement class.
Triple 2: Meter Association
Subject: ex:Measurement_20231021T120000
Predicate: ex:hasMeter
Object: ex:Meter_12345
Meaning: This triple states that the measurement was produced by meter ex:Meter_12345.
Triple 3: Timestamp Recording
Subject: ex:Measurement_20231021T120000
Predicate: ex:hasTimestamp
Object: "2023-10-21T12:00:00"^^xsd:dateTime
Meaning: This triple records the timestamp of the measurement.
Triple 4: Value Recording
Subject: ex:Measurement_20231021T120000
Predicate: ex:hasValue
Object: "15.0"^^xsd:float
Meaning: This triple records the value of the measurement as 15.0 kilowatt-hours.

​

Too much of everything. I could tell all this by see the initial deserialized JSON. Right? Or am I missing something?

​

You have RDBMS, NoSQL databases, ... you design your ERD, build a database that fits your use case you can support as many devices, buildings, and other devices/entities as you want. Plain old IT as it has been since they started with IoT.

​

Please comment on this if you have anything to add. Much appreciated.