Smart Data Models

Smart Data Models sind standardisierte Datenmodelle für typische fachliche Objekte, zum Beispiel Parkflächen, Luftqualitätsmessungen, Gebäude, Ladepunkte oder Wetterdaten. Sie helfen dabei, Daten nicht für jedes Projekt neu zu modellieren, sondern auf bestehende Strukturen zurückzugreifen.

Für die Plattform ist das vor allem dann wichtig, wenn Daten über den Kontextbroker bereitgestellt werden. Dort sollen ähnliche Objekte auch ähnlich beschrieben sein, damit Anwendungen, Dashboards und weitere Integrationen besser zusammenarbeiten.

Direktes Beispiel

Ein Projekt möchte Belegungsdaten für Parkflächen in den Kontextbroker schreiben. Ohne gemeinsames Modell würden schnell eigene Felder wie status, belegt, freiePlaetze, parkplatzName oder zone entstehen. Genau das führt in der Praxis oft dazu, dass ähnliche Daten in jedem Projekt anders aussehen.

Der bessere Weg ist:

1. Zuerst nach einem passenden Smart Data Model suchen, zum Beispiel im Themenfeld Parken.
2. Danach prüfen, welcher konkrete Typ fachlich passt, zum Beispiel OffStreetParking oder ParkingSpot.
3. Anschließend die vorgesehenen Attribute des Modells übernehmen.
4. Nur wenn wirklich etwas fehlt, zusätzliche projektbezogene Felder ergänzen.

Der eigentliche Mehrwert entsteht also nicht dadurch, dass es irgendein Modell gibt, sondern dadurch, dass ein passender Typ gewählt und mit den vorgesehenen Attributen befüllt wird.

Was gehört zu einem Smart Data Model?

Ein Smart Data Model umfasst in der Regel mehr als nur eine Liste von Feldnamen. Typischerweise gehören dazu:

• ein fachlicher Themenbereich, zum Beispiel Parken oder Luftqualität
• ein oder mehrere Entitätstypen
• die Beschreibung der Attribute
• Beispiele für gültige Datenstrukturen
• Hinweise zur semantischen Bedeutung der Begriffe

Dadurch kann man nicht nur sehen, wie ein Modell heißt, sondern auch, was genau mit einzelnen Properties gemeint ist und wie sie verwendet werden sollen.

Unterschied zwischen Smart Data Model und Entitätstyp

Die beiden Begriffe werden oft vermischt, meinen aber nicht ganz dasselbe.

Ein Smart Data Model ist der fachliche Rahmen. Es beschreibt, wie ein bestimmter Gegenstandsbereich typischerweise modelliert wird, also zum Beispiel Parken, Wetter oder Luftqualität.

Der Entitätstyp oder Entity Type ist der konkrete Typ, der später in den Daten verwendet wird, zum Beispiel OffStreetParking, ParkingSpot oder AirQualityObserved.

Für die Praxis heißt das:

• Das Smart Data Model ist die fachliche Vorlage.
• Der Entitätstyp ist das konkrete Objekt in den Daten.
• Zu einem Smart Data Model können mehrere Entitätstypen gehören.

Wie werden Smart Data Models in der Plattform genutzt?

In der Plattform werden Smart Data Models besonders dann relevant, wenn Daten in NGSI-LD-Strukturen überführt und über den Kontextbroker bereitgestellt werden.

Typischer Ablauf:

1. Daten kommen aus einer Quelle, zum Beispiel API, Datei, MQTT oder Datenbank.
2. Die Daten werden in Node-RED oder in einer anderen Integrationslogik gelesen und aufbereitet.
3. Ein passender Entitätstyp und die dazugehörigen Attribute werden ausgewählt.
4. Die Quelldaten werden auf diese Zielstruktur gemappt.
5. Das Ergebnis wird als NGSI-LD-Entität in den Kontextbroker geschrieben.

Smart Data Models entstehen also oft nicht direkt in der Quelle, sondern erst im Mapping.

Rolle des @context

Damit Smart Data Models in NGSI-LD sauber funktionieren, reicht der Entitätstyp allein nicht aus. Es braucht auch einen passenden @context. Der @context legt fest, was Typen und Attribute semantisch bedeuten.

Für die Praxis heißt das:

• Der Entitätstyp und die Attribute orientieren sich am Smart Data Model.
• Der @context liefert die Bedeutung dieser Begriffe.
• Stellio erwartet diesen Kontext bei NGSI-LD-Daten.

Technisch können auch neue Typen und neue Attribute verwendet werden. Wenn ein passender @context oder ein @vocab vorhanden ist, kann Stellio solche Begriffe in der Regel trotzdem verarbeiten. Für eine einheitliche Plattform ist es aber sinnvoll, diese Begriffe möglichst zentral und konsistent zu pflegen.

Beispiel:

{
  "@context": {
    "@vocab": "https://context.datenportal.lkgi.de/ngsi-ld-core-context.jsonld#default-context/",
    "AirQualityObserved": "https://uri.fiware.org/ns/data-models#AirQualityObserved",
    "BikeHireDockingStation": "https://uri.fiware.org/ns/data-models#BikeHireDockingStation",
    "Building": "https://uri.fiware.org/ns/data-models#Building",
    "CrowdFlowObserved": "https://uri.fiware.org/ns/data-models#CrowdFlowObserved"
  }
}

Typisch ist dabei eine URL-Struktur wie context.<domain>.de/main-context.jsonld.

Wenn kein eigener zentraler Kontext bereitsteht, können grundsätzlich auch öffentliche Kontexte verwendet werden, zum Beispiel allgemeine NGSI-LD-Basiskontexte oder öffentlich verfügbare Kontexte aus dem Umfeld der Smart Data Models.

Warum sind Smart Data Models hilfreich?

Smart Data Models bringen vor allem dann Vorteile, wenn Daten nicht nur einmalig verarbeitet, sondern später auch wiederverwendet, verglichen oder in mehreren Anwendungen genutzt werden sollen.

Typische Vorteile sind:

• einheitlichere Datenstrukturen
• bessere Wiederverwendbarkeit
• weniger Abstimmungsaufwand zwischen Projekten
• verständlichere Mapping-Logik
• bessere Vergleichbarkeit ähnlicher Datentypen

Wo findet man passende Smart Data Models?

Für die praktische Arbeit sind vor allem diese Einstiegspunkte hilfreich:

• Smart Data Models Startseite
• Liste der verfügbaren Smart Data Models
• Hinweise zur Nutzung von Smart Data Models
• Smart Data Models auf GitHub
• Zentraler Plattform-Kontext

Was heißt das für Projekte?

Für Projekte reicht meist eine einfache Reihenfolge:

1. Zuerst prüfen, ob es bereits ein passendes Smart Data Model gibt.
2. Wenn es fast passt, das bestehende Modell als Grundlage nehmen und nur gezielt erweitern.
3. Nur wenn es wirklich kein sinnvolles passendes Modell gibt, über ein neues Modell nachdenken.

Wichtig ist dabei: Erst übernehmen, dann erweitern, und nur im Ausnahmefall neu bauen.

Wenn zusätzliche Typen oder Attribute nötig sind, sollten sie möglichst zentral dokumentiert werden. Der Idealfall ist ein gepflegter zentraler Kontext. Wenn das nicht möglich ist, sollte die Erweiterung wenigstens in einer verlässlichen Projektdokumentation festgehalten werden.