Overview
About the LiveBetter Standardised Common Data Model (CDM)
The LiveBetter Standardised Common Data Model (CDM) is a unified semantic framework developed under Task T2.1 – Landscape review and harmonisation of relevant data models, methodologies and standards (WP2 – Data Intelligence Framework for enhanced quality). It enables AI-driven renovation and energy efficiency services by harmonising heterogeneous building data sources into one interoperable structure aligned with the EU Building Stock Observatory (EU BSO).
Key Features:
- Common Data Model (CDM): Ten core entities covering static building data, dynamic performance metrics, financial/regulatory attributes, and renovation planning
- Semantic Ontological Framework: Built on SAREF4BLDG, Brick, QUDT, Time, and OWL/RDF, extended with LiveBetter-specific concepts (lbRenovationPassport, lbFlexibilityAsset)
- EU BSO Compliance: Dynamic EPC automation/enrichment and Renovation Passport support
- Semantic Mapping Mechanism: Lightweight JSON-LD semantic maps enabling interoperability without full RDF serialisation for every exchange
- Flexibility & Demand Response: Flexibility asset modelling and grid-responsive building data
- WP2 Foundation: Provides groundwork for T2.2 – Smart collection, structuring and integration of static and dynamic buildings data; T2.3 – Data quality assurance, data governance and compliance with ethical standards; T2.4 – Data space-compliant data management, storage and sharing; and WP3 services
Classes
All classes defined in the LiveBetter Ontology, organized by category.
Object Properties
Properties that relate instances of classes to other instances.
Datatype Properties
Properties that relate instances to literal data values.
Namespaces
Namespace prefixes used in the LiveBetter Ontology.
Usage Examples
Practical examples of using the LiveBetter Ontology for data modeling.
Example 1: Modeling a Building with Sensors
@prefix lb: <http://example.org/livebetter#> .
@prefix bot: <http://w3id.org/bot#> .
@prefix sosa: <http://www.w3.org/ns/sosa/> .
# Define a building
:Building1 a lb:Building ;
rdfs:label "Smart Office Building A" ;
bot:hasSpace :Floor1 .
# Define a space
:Floor1 a lb:BuildingSpace ;
rdfs:label "First Floor" ;
lb:hasDevice :TempSensor1 .
# Define a sensor
:TempSensor1 a lb:Sensor ;
rdfs:label "Temperature Sensor 1" ;
sosa:observes :Temperature .Example 2: Recording Energy Consumption
@prefix lb: <http://example.org/livebetter#> .
@prefix saref: <http://saref.etsi.org/core/> .
# Define energy consumption measurement
:EnergyMeasurement1 a lb:EnergyMeasurement ;
rdfs:label "Monthly Energy Consumption" ;
lb:hasValue 1250.5 ;
lb:hasUnit "kWh" ;
lb:measurementDate "2025-10-31"^^xsd:date ;
lb:relatedToBuilding :Building1 .Example 3: Device-Space Relationships
@prefix lb: <http://example.org/livebetter#> .
# Connect devices to spaces
:HVAC_System1 a lb:HVACDevice ;
rdfs:label "Central HVAC Unit" ;
lb:installedIn :Floor1 ;
lb:hasEnergyRating "A+" ;
lb:operationalStatus "active" .
:Floor1 lb:hasDevice :HVAC_System1 .Best Practices
- Keep standard prefixes consistent (sosa, saref, s4bldg, time, brick) for interoperability
- Model spaces and building elements with `s4bldg:BuildingSpace` subclasses (e.g., Apartment) and connect systems to buildings
- Describe devices as `saref:Device` subclasses (HVAC, SmartMeter, SolarPanel) and use `lb:hasDevice` to link systems
- Represent observations with SOSA and attach temporal context using `time:Instant` or `time:Interval`
- Use `skos:closeMatch` to align LiveBetter properties with Brick sensor concepts where available
- Capture flexibility lifecycle with `FlexOffer` subclasses (Initial, Offered, Assigned, Executed, Canceled, Rejected)
Ontology Visualization
Interactive graph visualization of the ontology structure. Nodes are classes and properties; edges show subclass hierarchy and domain/range relations.