OS2/ai-heatcontrol

Fork 0

ADR-001: Ontologi og datamodel #37

New issue

Closed

opened 2026-05-29 10:03:01 +00:00 by JakobNoerby · 2 comments

JakobNoerby commented

2026-05-29 10:03:01 +00:00

(Migrated from github.com)

Beslutningslog: Ontologi og datamodel

📆 sidst opdateret: {{ site.time | date: '%B %d, %Y' }}

Issue metadata (Github standard)

name: Beslutningslog
about: Struktureret beskrivelse af en væsentlig beslutning i produktet
title: "Ontologi og datamodel for OS2 AI Heat Control"
labels: `adr'
assignees: JN
Issue reference:

ADR Beslutning

Dato: 2026-04-21
Status: Forslag
Beslutningstagere: Projektgruppen for OS2 AI Heat Control
Beslutningstype: Arkitekturbeslutning

Beskrivelse af Beslutningen

Det besluttes, at projektets datamodel og ontologiske grundlag som udgangspunkt baseres på:

RealEstateCore
BrickSchema

Hvor RealEstateCore og BrickSchema ikke dækker projektets behov, kan der etableres afgrænsede OS2-specifikke udvidelser, fx til setpunkter, fallback-strategier og driftsplaner.

Kontekst & årsag

OS2 AI Heat Control har behov for et fælles datamodelmæssigt udgangspunkt, så data kan forstås, sammenlignes og anvendes på tværs af kommuner, bygninger, tekniske installationer, CTS-anlæg, IoT-systemer og leverandører.

I dialog med projektets parter er RealEstateCore og BrickSchema vurderet som relevante og hensigtsmæssige ontologier for bygninger, rum, tekniske installationer, sensorer og målepunkter.

Beslutningen træffes for at skabe et tydeligt grundlag for:

Datamodelarbejde
Kvalitetstjek af datamodel
Kravspecifikation
Markedsdialog
Arkitekturarbejde
Dialog med udviklingspartner
Videre dokumentation i GitHub

Beslutning

Det besluttes, at OS2 AI Heat Control som udgangspunkt anvender RealEstateCore og BrickSchema som ontologisk grundlag for projektets datamodel.

RealEstateCore

RealEstateCore anvendes til beskrivelse af:

Bygninger
Ejendomsstruktur
Rum
Relationer mellem bygningsdele
Relevante organisatoriske eller fysiske strukturer i bygningsmassen

RealEstateCore skal især understøtte den del af datamodellen, der handler om bygninger, placeringer, rum og strukturelle relationer.

BrickSchema

BrickSchema anvendes til beskrivelse af:

Tekniske installationer
HVAC-zoner
Sensorer
Målepunkter
Styringspunkter
Relationer i bygningsautomatik
Relevante datapunkter fra CTS- og IoT-systemer

BrickSchema skal især understøtte den del af datamodellen, der handler om tekniske anlæg, styring, sensorer og bygningsautomatik.

OS2-specifikke udvidelser

Hvor RealEstateCore og BrickSchema ikke dækker projektets behov tilstrækkeligt, kan der etableres afgrænsede OS2-specifikke udvidelser.

Foreløbige OS2-specifikke udvidelser kan eksempelvis omfatte:

os2:Setpoint
os2:FallbackStrategy
os2:Schedule

OS2-udvidelser skal holdes så få og enkle som muligt og kun anvendes, hvor eksisterende åbne ontologier ikke er tilstrækkelige.

Principper for datamodellen

Datamodellen skal være:

Enkel
Modulær
Baseret på åbne standarder og ontologier
Leverandøruafhængig
Praktisk implementerbar i kommunal kontekst
Egnet til kvalitetstjek og videreudvikling
Tydeligt dokumenteret i GitHub

Datamodellen skal understøtte de fire grundelementer, der er fastlagt i #36

Fravalgte eller udskudte alternativer

Egen OS2-ontologi fra bunden

Det fravælges at udvikle en fuld OS2-specifik ontologi fra bunden, da det vil øge kompleksitet, vedligeholdelsesbyrde og risiko for leverandørafhængighed.

Kun én eksisterende ontologi

Det fravælges på nuværende tidspunkt alene at basere datamodellen på én eksisterende ontologi, da RealEstateCore og BrickSchema dækker forskellige, men komplementære dele af projektets behov

Endelig datamodel fastlagt før kvalitetstjek

Det udskydes at fastlægge den endelige datamodel i detaljer, indtil datamodelskitsen er kvalitetstjekket og vurderet i dialog med relevante faglige parter og en kommende udviklingspartner.

Konsekvenser

Positive konsekvenser

Brug af RealEstateCore og BrickSchema reducerer behovet for at opfinde egne datamodeller fra bunden.
Åbne ontologier understøtter leverandøruafhængighed og interoperabilitet.
Datamodel og arkitektur kan kvalitetstjekkes mere systematisk.
Kommuner og leverandører får et fælles sprog for bygninger, rum, tekniske installationer og datapunkter.
Datamodellen kan kobles tydeligere til connector-lag, reguleringsmotor og kravspecifikation.

Negative konsekvenser

RealEstateCore og BrickSchema kræver viden og kompetencer, som ikke nødvendigvis findes bredt i alle deltagerkommuner.
Det kan blive nødvendigt at lave OS2-specifikke udvidelser, hvilket kan skabe vedligeholdelsesansvar.
Der kan være kompleksitet i at kombinere flere ontologier.
Datamodellen kan blive for omfattende, hvis den ikke holdes enkel og modulær.
Der er risiko for, at den valgte model skal justeres efter kvalitetstjek eller dialog med udviklingspartner.

Neutrale konsekvenser

GitHub-dokumentation skal opdateres, så datamodel, ontologier og eventuelle OS2-udvidelser hænger sammen.
Kravspecifikation, beslutningslog og eventuelle Strategic Decision Records skal referere til denne beslutning.
Fremtidige ændringer i datamodel eller ontologi bør dokumenteres som nye beslutninger eller issues.

Effektuering

Beslutningen effektueres ved, at RealEstateCore og BrickSchema anvendes som det foreløbige ontologiske udgangspunkt for projektets videre arbejde med datamodel, kravspecifikation, markedsdialog og dialog med kommende udviklingspartner.

Det betyder konkret, at:

Projektets datamodelskitse opdateres og dokumenteres med afsæt i RealEstateCore og BrickSchema.
Det tydeliggøres, hvilke dele af datamodellen der dækkes af henholdsvis RealEstateCore og BrickSchema.
Eventuelle behov for OS2-specifikke udvidelser beskrives særskilt og holdes så få og enkle som muligt.
Datamodellen kvalitetstjekkes med relevant faglig ekspertise, herunder eventuelt SDU eller andre parter med erfaring inden for semantiske datamodeller, bygningsdata og ontologier.
Datamodellen anvendes som grundlag for det videre arbejde med kravspecifikation, connector-lag og markedsdialog.
Principper for “Source of Truth”, dataejerskab og datastrømme afklares i det videre arkitekturarbejde.
Kommende udviklingspartner inddrages i at verificere, om den valgte datamodel og ontologiske tilgang er praktisk implementerbar.
Eventuelle ændringer, præciseringer eller fravigelser fra denne beslutning dokumenteres som nye issues eller supplerende arkitekturbeslutninger.

Ansvarlig: JN / projektgruppen

Risici

Der er risiko for, at RealEstateCore og BrickSchema ikke dækker alle nødvendige use cases uden OS2-specifikke udvidelser.
Der er risiko for, at datamodellen bliver for kompleks til praktisk implementering.
Der er risiko for, at forskellige kommuner har forskellige datakilder, datakvalitet og systemlandskaber, som gør standardisering vanskelig.
Der er risiko for, at “Source of Truth” bliver uklart, hvis der ikke defineres tydelige principper for dataejerskab og datastrømme.
Der er risiko for, at kommende leverandører fortolker datamodellen forskelligt.
Der er risiko for, at der mangler kompetencer i projektgruppen til at vurdere ontologier og semantiske datamodeller.
Der er risiko for, at fokus på datamodel og ontologi forsinker arbejdet med praktisk test og implementering.

Yderligere information

RealEstateCore
BrickSchema
[PM3] - Workshop om kerneprodukt og SKAL/VIGTIGT/EKSTRA-krav
[PM4] - Oplæg til definition af kerneprodukt
[PM5] - Fastlæggelse af grundelementer, GitHub og open source
OS2sandbox/gps-connector
OS2sandbox/ai-heatcontrol

Specifikke metadata

Beslutnings-ID: ADR-001
Beslutningsområde: Datamodel og ontologi
Påvirker:
- Datamodel
- Kravspecifikation
- Connector-lag
- Markedsdialog
- Udviklingspartner
- Dokumentation
Relaterede issues:
- #33
- #35
Relaterede beslutninger:
- #36

# Beslutningslog: Ontologi og datamodel 📆 _sidst opdateret: {{ site.time | date: '%B %d, %Y' }}_ ## Issue metadata (Github standard) - name: Beslutningslog - about: Struktureret beskrivelse af en væsentlig beslutning i produktet - title: "Ontologi og datamodel for OS2 AI Heat Control" - labels: `adr' - assignees: `JN` - Issue reference: _______________________ # ADR Beslutning - Dato: 2026-04-21 - Status: Forslag - Beslutningstagere: Projektgruppen for OS2 AI Heat Control - Beslutningstype: Arkitekturbeslutning ## Beskrivelse af Beslutningen Det besluttes, at projektets datamodel og ontologiske grundlag som udgangspunkt baseres på: - RealEstateCore - BrickSchema Hvor RealEstateCore og BrickSchema ikke dækker projektets behov, kan der etableres afgrænsede OS2-specifikke udvidelser, fx til setpunkter, fallback-strategier og driftsplaner. ## Kontekst & årsag OS2 AI Heat Control har behov for et fælles datamodelmæssigt udgangspunkt, så data kan forstås, sammenlignes og anvendes på tværs af kommuner, bygninger, tekniske installationer, CTS-anlæg, IoT-systemer og leverandører. I dialog med projektets parter er RealEstateCore og BrickSchema vurderet som relevante og hensigtsmæssige ontologier for bygninger, rum, tekniske installationer, sensorer og målepunkter. Beslutningen træffes for at skabe et tydeligt grundlag for: - Datamodelarbejde - Kvalitetstjek af datamodel - Kravspecifikation - Markedsdialog - Arkitekturarbejde - Dialog med udviklingspartner - Videre dokumentation i GitHub ## Beslutning Det besluttes, at OS2 AI Heat Control som udgangspunkt anvender RealEstateCore og BrickSchema som ontologisk grundlag for projektets datamodel. ### RealEstateCore RealEstateCore anvendes til beskrivelse af: - Bygninger - Ejendomsstruktur - Rum - Relationer mellem bygningsdele - Relevante organisatoriske eller fysiske strukturer i bygningsmassen RealEstateCore skal især understøtte den del af datamodellen, der handler om bygninger, placeringer, rum og strukturelle relationer. ### BrickSchema BrickSchema anvendes til beskrivelse af: - Tekniske installationer - HVAC-zoner - Sensorer - Målepunkter - Styringspunkter - Relationer i bygningsautomatik - Relevante datapunkter fra CTS- og IoT-systemer BrickSchema skal især understøtte den del af datamodellen, der handler om tekniske anlæg, styring, sensorer og bygningsautomatik. ### OS2-specifikke udvidelser Hvor RealEstateCore og BrickSchema ikke dækker projektets behov tilstrækkeligt, kan der etableres afgrænsede OS2-specifikke udvidelser. Foreløbige OS2-specifikke udvidelser kan eksempelvis omfatte: - `os2:Setpoint` - `os2:FallbackStrategy` - `os2:Schedule` OS2-udvidelser skal holdes så få og enkle som muligt og kun anvendes, hvor eksisterende åbne ontologier ikke er tilstrækkelige. ### Principper for datamodellen Datamodellen skal være: - Enkel - Modulær - Baseret på åbne standarder og ontologier - Leverandøruafhængig - Praktisk implementerbar i kommunal kontekst - Egnet til kvalitetstjek og videreudvikling - Tydeligt dokumenteret i GitHub Datamodellen skal understøtte de fire grundelementer, der er fastlagt i #36 ## Fravalgte eller udskudte alternativer ### Egen OS2-ontologi fra bunden Det fravælges at udvikle en fuld OS2-specifik ontologi fra bunden, da det vil øge kompleksitet, vedligeholdelsesbyrde og risiko for leverandørafhængighed. ### Kun én eksisterende ontologi Det fravælges på nuværende tidspunkt alene at basere datamodellen på én eksisterende ontologi, da RealEstateCore og BrickSchema dækker forskellige, men komplementære dele af projektets behov ### Endelig datamodel fastlagt før kvalitetstjek Det udskydes at fastlægge den endelige datamodel i detaljer, indtil datamodelskitsen er kvalitetstjekket og vurderet i dialog med relevante faglige parter og en kommende udviklingspartner. ## Konsekvenser ### Positive konsekvenser - Brug af RealEstateCore og BrickSchema reducerer behovet for at opfinde egne datamodeller fra bunden. - Åbne ontologier understøtter leverandøruafhængighed og interoperabilitet. - Datamodel og arkitektur kan kvalitetstjekkes mere systematisk. - Kommuner og leverandører får et fælles sprog for bygninger, rum, tekniske installationer og datapunkter. - Datamodellen kan kobles tydeligere til connector-lag, reguleringsmotor og kravspecifikation. ### Negative konsekvenser - RealEstateCore og BrickSchema kræver viden og kompetencer, som ikke nødvendigvis findes bredt i alle deltagerkommuner. - Det kan blive nødvendigt at lave OS2-specifikke udvidelser, hvilket kan skabe vedligeholdelsesansvar. - Der kan være kompleksitet i at kombinere flere ontologier. - Datamodellen kan blive for omfattende, hvis den ikke holdes enkel og modulær. - Der er risiko for, at den valgte model skal justeres efter kvalitetstjek eller dialog med udviklingspartner. ### Neutrale konsekvenser - GitHub-dokumentation skal opdateres, så datamodel, ontologier og eventuelle OS2-udvidelser hænger sammen. - Kravspecifikation, beslutningslog og eventuelle Strategic Decision Records skal referere til denne beslutning. - Fremtidige ændringer i datamodel eller ontologi bør dokumenteres som nye beslutninger eller issues. ## Effektuering Beslutningen effektueres ved, at RealEstateCore og BrickSchema anvendes som det foreløbige ontologiske udgangspunkt for projektets videre arbejde med datamodel, kravspecifikation, markedsdialog og dialog med kommende udviklingspartner. Det betyder konkret, at: - Projektets datamodelskitse opdateres og dokumenteres med afsæt i RealEstateCore og BrickSchema. - Det tydeliggøres, hvilke dele af datamodellen der dækkes af henholdsvis RealEstateCore og BrickSchema. - Eventuelle behov for OS2-specifikke udvidelser beskrives særskilt og holdes så få og enkle som muligt. - Datamodellen kvalitetstjekkes med relevant faglig ekspertise, herunder eventuelt SDU eller andre parter med erfaring inden for semantiske datamodeller, bygningsdata og ontologier. - Datamodellen anvendes som grundlag for det videre arbejde med kravspecifikation, connector-lag og markedsdialog. - Principper for “Source of Truth”, dataejerskab og datastrømme afklares i det videre arkitekturarbejde. - Kommende udviklingspartner inddrages i at verificere, om den valgte datamodel og ontologiske tilgang er praktisk implementerbar. - Eventuelle ændringer, præciseringer eller fravigelser fra denne beslutning dokumenteres som nye issues eller supplerende arkitekturbeslutninger. Ansvarlig: JN / projektgruppen ## Risici - Der er risiko for, at RealEstateCore og BrickSchema ikke dækker alle nødvendige use cases uden OS2-specifikke udvidelser. - Der er risiko for, at datamodellen bliver for kompleks til praktisk implementering. - Der er risiko for, at forskellige kommuner har forskellige datakilder, datakvalitet og systemlandskaber, som gør standardisering vanskelig. - Der er risiko for, at “Source of Truth” bliver uklart, hvis der ikke defineres tydelige principper for dataejerskab og datastrømme. - Der er risiko for, at kommende leverandører fortolker datamodellen forskelligt. - Der er risiko for, at der mangler kompetencer i projektgruppen til at vurdere ontologier og semantiske datamodeller. - Der er risiko for, at fokus på datamodel og ontologi forsinker arbejdet med praktisk test og implementering. ## Yderligere information - [RealEstateCore](https://www.realestatecore.io/) - [BrickSchema](https://brickschema.org/) - [[PM3]](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm3.md) - Workshop om kerneprodukt og SKAL/VIGTIGT/EKSTRA-krav - [[PM4]](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm4.md) - Oplæg til definition af kerneprodukt - [[PM5]](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm5.md) - Fastlæggelse af grundelementer, GitHub og open source - [OS2sandbox/gps-connector](https://github.com/OS2sandbox/gps-connector) - [OS2sandbox/ai-heatcontrol](https://github.com/OS2sandbox/ai-heatcontrol) ## Specifikke metadata - Beslutnings-ID: ADR-001 - Beslutningsområde: Datamodel og ontologi - Påvirker: - Datamodel - Kravspecifikation - Connector-lag - Markedsdialog - Udviklingspartner - Dokumentation - Relaterede issues: - #33 - #35 - Relaterede beslutninger: - #36

mikkelgrootandersen commented

2026-06-03 08:28:31 +00:00

(Migrated from github.com)

Kan du add mig...

JakobNoerby commented

2026-06-19 08:33:50 +00:00

(Migrated from github.com)

ADR godkendt på pm7

ADR godkendt på [pm7](https://github.com/OS2sandbox/ai-heatcontrol/blob/main/projektadministration/m%C3%B8der/pm7.md)

This discussion has been locked. Commenting is limited to contributors.