EN 50090-6-2:2025

SLOVENSKI STANDARD
01-september-2025
Stanovanjski in stavbni elektronski sistemi (HBES) - 6-2. del: Semantični opis
ontološkega modela
Home and Building Electronic Systems (HBES) - Part 6-2: IoT Semantic Ontology model
description
Elektrische Systemtechnik für Heim und Gebäude (ESHG) - Teil 6-2: Beschreibung des
IoT semantischen Ontologiemodells
Systèmes électroniques pour les foyers domestiques et les bâtiments (HBES) - Partie 6-
2: Description du modèle ontologie sémantique loT
Ta slovenski standard je istoveten z: EN 50090-6-2:2025
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
97.120 Avtomatske krmilne naprave Automatic controls for
za dom household use
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD EN 50090-6-2

NORME EUROPÉENNE
EUROPÄISCHE NORM June 2025
ICS 97.120; 35.240.67 Supersedes EN 50090-6-2:2021
English Version
Home and Building Electronic Systems (HBES) - Part 6-2: IoT
Semantic Ontology model description
Systèmes électroniques pour les foyers domestiques et les Elektrische Systemtechnik für Heim und Gebäude (ESHG) -
bâtiments (HBES) - Partie 6-2: Description du modèle Teil 6-2: Beschreibung des IoT semantischen
ontologie sémantique loT Ontologiemodells
This European Standard was approved by CENELEC on 2025-05-12. CENELEC members are bound to comply with the CEN/CENELEC
Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.
Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC
Management Centre or to any CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the
same status as the official versions.
CENELEC members are the national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, the Czech Republic,
Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, the
Netherlands, Norway, Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Türkiye and the United Kingdom.

European Committee for Electrotechnical Standardization
Comité Européen de Normalisation Electrotechnique
Europäisches Komitee für Elektrotechnische Normung
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CENELEC All rights of exploitation in any form and by any means reserved worldwide for CENELEC Members.
Ref. No. EN 50090-6-2:2025 E
Contents Page
European foreword . 3
1 Scope. 4
2 Normative references . 4
3 Terms, definitions and abbreviations . 4
3.1 Terms and definitions . 4
3.2 Abbreviations . 10
4 HBES Information Model . 11
4.1 Introduction . 11
4.1.1 General . 11
4.1.2 Models . 11
4.1.3 Taxonomy . 13
4.1.4 Versioning . 16
4.1.5 Availability . 16
4.1.6 IRIs and Namespaces . 17
4.2 Semantic Dictionary . 18
4.2.1 General . 18
4.2.2 Content . 19
4.2.3 Semantic Dictionary Versioning . 21
4.3 Core Model . 21
4.3.1 Introduction . 21
4.3.2 Classes . 23
4.3.3 Relations . 37
4.3.4 Examples . 43
4.4 Location Model . 53
4.4.1 Introduction . 53
4.4.2 Classes . 55
4.4.3 Relations . 59
4.4.4 Examples . 61
4.5 Tag Model . 62
4.5.1 Introduction . 62
4.5.2 Cardinalities . 63
4.5.3 Classes . 66
4.5.4 Relations . 77
4.6 HBES Model . 81
4.6.1 Introduction . 81
4.6.2 IRI Scheme . 81
4.6.3 URN Scheme . 82
4.6.4 Classes . 83
4.6.5 Relations . 101
4.6.6 Examples . 107
5 Appendix . 113
5.1 Semantic Export . 113
5.2 Examples . 117
5.2.1 General . 117
5.2.2 Room Temperature Control . 118
5.2.3 Light Switch Control . 123
Bibliography . 128

European foreword
This document (EN 50090-6-2:2025) has been prepared by CLC/TC 205 “Home and Building
Electronic Systems (HBES)”.
The following dates are fixed:
• latest date by which this document has to be (dop) 2026-06-30
implemented at national level by publication of
an identical national standard or by
endorsement
• latest date by which the national standards (dow) 2028-06-30
conflicting with this document have to be
withdrawn
This document supersedes EN 50090-6-2:2021 and all of its amendments and corrigenda (if any).
2:2021:
— certain HBES concepts were split to have a better distinction between definitions and their types
(e.g. datapoints and their types);
— improved linking between different concepts such as devices and application functions;
— copies of external ontology parts were removed from the HBES ontology and replaced by
references.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CENELEC shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national committee. A
complete listing of these bodies can be found on the CENELEC website.
1 Scope
This document defines the HBES Information Model and a corresponding data exchange format for
the Home and Building HBES Open Communication System.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments)
applies.
EN 50090-1:2011, Home and Building Electronic Systems (HBES) - Part 1: Standardization structure
EN 50090–6-3:2023, Home and Building Electronic Systems (HBES) - Part 6-3: 3rd Party HBES IoT
API
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 50090-1:2011 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at https://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1.1
actuator
point performing an actuation (executed by a specific procedure, with an expected result) that
changes an Installation state during Runtime
Note 1 to entry:
— The term Actuator can be mapped to sosa:Actuator in the SSN Ontology.
— The subject actuation can be mapped to sosa:Actuation in the SSN Ontology.
— The subject procedure can be mapped to sosa:Procedure in the SSN Ontology.
— The subject result can be mapped to sosa:Result in the SSN Ontology.
3.1.2
Application Function
use of a set of Functions to achieve the desired behaviour of a technical system, typically using a
combination of devices exchanging information via their input and output Datapoints
Note 1 to entry: An Application Function may be split into several Functional Blocks with their input and output
Datapoints that are logically connected to each other. The Functional Blocks may be located in one or more
devices.
EXAMPLE Application Functions examples are “direct electrical heating”, “electrical heating with
accumulators”, “warm water heating”, “fan coil air-conditioning” …
Note 2 to entry: The Application Function and Application are meant to be the same. Reason to introduce an
alias term is to use a clear (understandable) reference from Application/ Application Function to the
corresponding KIM class:ApplicationFunction or to the Function in the Management Client.
3.1.3
aspect
specific perspective on a system that contains things with different properties, or referencing
mechanism to organize KIM elements in a specific perspective
EXAMPLE A Function Point is an ex officio Aspect with an important specific perspective. It is a referencing
mechanism to organize together all to a Function Point interoperating Points (all GOs linked to a GA).
3.1.4
BIM
Building Information Model
digital process to describe and document a building in all its life cycle phases, from its planning,
construction, operation up to its demolition
3.1.5
channel
collection of Datapoints of a device that are logically related to each other typically by association with
a hardware feature or a specific function of that device
Note 1 to entry: These Datapoints may be derived from one or more defined Functional Blocks or may be an
expansion above and beyond defined Functional Blocks or may be independent of a Functional Block if none is
defined for the function associated with the Channel. The concept of a Channel is well-understood by the market
participant, e.g. installers.
3.1.6
datapoint
logical input entity of a device acting as recipient of Installation state data, whereas a logical output of
a device acts as source of Installation state data
Note 1 to entry: In case of implementation as a Group Object, state data are communicated with the use of
Function Points.
Note 2 to entry: The term Datapoint is the common term; to specifically denote a Datapoint available on an IoT
3rd Party API, the term IoT Datapoint is used.
3.1.7
device
physical element that is part of the network
Note 1 to entry: It is a physical, concrete object that a customer can buy.
3.1.8
endpoint
entry point to a service, a process, or a queue or topic destination in service-oriented architecture
3.1.9
Feature of Interest
FOI
abstraction of a real-world thing (phenomenon, equipment, person, event…) defined by its observable
or actuatable properties
Note 1 to entry: In colloquial terms, a FOI is a property carrier.
Note 2 to entry: A Sensor operates on a FOI with observable properties, an Actuator with actuatable properties.
Note 3 to entry: A FOI is not a “classification/type” tag itself; the “classification/ type” is accomplished with the
help of tags. Examples are defined in 4.5.1.4.
3.1.10
function
part of the intended behaviour of a Functional Block in a building context
3.1.11
Functional Block
FB
one or more Functions that belong together and that cannot be separated across two devices but big
enough that a device with only one such Functional Block could be marketed
Note 1 to entry: A Functional Block has a well-defined black box behaviour.
3.1.12
Function Point
FP
runtime system state information of a specific Application Function
Note 1 to entry: Shared by at least two Datapoints.
Note 2 to entry: Has a unique identifier that addresses a group of controlled objects. This identifier is called a
Group Address.
EXAMPLE < Light Switch > in living room on/off, whereas the < … > is the Function Point name
3.1.13
Group Address
GA
numerical identifier of a Function Point
3.1.14
Group Communication
communication model in which one sender communicates information to one and typically more
receivers
Note 1 to entry: In IoT, this can be realized by simple UDP communication or by using a message broker
system or other.
3.1.15
Group Object
GO
object which is foreseen for Group Communication using Group Address(es), which may be accessed
via point-to-point communication without an assigned Group Address and becoming a member of that
Function Point represented by the Group Address when assigned Group Address
3.1.16
HBES Information Model
ontology based model of HBES System relevant parts, including additional semantic (dictionary)
information
Note 1 to entry: It is managed by the KNX Association, hence the abbreviation KIM.
3.1.17
Industry Foundation Classes
IFC
open standard to describe BIM data in a digital way
Note 1 to entry: IFC data and models are specified in ISO 16739-1.
3.1.18
installation
assembly of materials and components (devices) placed in position to provide a service
Note 1 to entry: An Installation is a deployed system (e.g. HVAC system or fire protection system) and consists
of equipment and Functions that are used for a particular purpose.
Note 2 to entry: In relation to this term created data correlates to the installation model, described in 4.2.
[SOURCE: ISO 6707-1:2020, modified – added “(devices)” and Notes to entry.]
3.1.19
IoT Datapoint
rd
Endpoint at an IoT 3 Party API that:
a) corresponds to one or more Function Points, such as a state data representation of a discrete
state in a building context; and
rd
b) is a fully qualified URL e.g. provided by an IoT 3 Party Server
EXAMPLE 1 brightness → discrete state “brightness” is represented by the value 65 (percent)
EXAMPLE 2 https://gateway.knx.local/knx/api/v1/datapoints/{Id}
3.1.20
IoT Function
rd
Function at an IoT 3 Party API that:
— is as a collection of IoT Datapoints that fulfils a – by the user – intended behaviour
EXAMPLE “living room – rear light dimming”, “kitchen – floor heating”
Note 1 to entry: In a Mac, an IoT Function is instantiated data of a MaC Function in an Installation respectively
MaC project. The MaC Function itself may base on an Application Function.
3.1.21
rd
IoT 3 Party API
set of requirements and regulations through which partial access to an Installation can be gained by
offering a collection of Endpoints
3.1.22
rd
IoT 3 Party Client
rd
device or service interacting with the Installation from outside using the IoT 3 Party API
rd rd
Note 1 to entry: The IoT 3 Party Client connects to a single device that provides the IoT 3 Party API and
can use this single device to fully interact with the Installation, possibly depending on a specified authorization
mechanism.
EXAMPLE 1 A mobile phone (from inside the network, or from an Internet connection) with typically short
period connections.
rd
EXAMPLE 2 A weather service permanently feeding in its weather information using the IoT 3 Party API.
3.1.23
rd
IoT 3 Party Server
rd
device that implements the IoT 3 Party API
Note 1 to entry: This can be a dedicated device; this can be a function of a device that supports other HBES
IoT and non HBES functionalities; it may be located within the local LAN of the IoT installation or outside.
3.1.24
MaC Catalog Entry
created management client data correlating to the product model, described in 4.2
3.1.25
MaC Function
Application Function created by the MaC and assigned to a building structure element, grouping
several Group Addresses
3.1.26
MaC Project
project created by a MaC documenting the Configuration of an Installation
3.1.27
Management Client
MaC
means to configure and commission Devices as well as to plan, design and diagnose an entire
Installation
Note 1 to entry: The MaC is used to configure and commission Devices, as well as to plan, design and
diagnose an entire Installation. As a final step the MaC writes specific configuration data such as Device
parameters to the Devices.
3.1.28
ontology
conceptual descriptions of things that have a real-world commonality sharing the knowledge of a
domain, mainly expressed with OWL
Note 1 to entry: Ontologies are a structured way to describe the meaning of data in ontology classes and
should not be mixed up with common data model structures.
3.1.29
Object Property
OP
built-in concept that connects pairs of individuals
Note 1 to entry: An object property expression represents the (entire) relationship between the pairs of
individuals.
3.1.30
OWL
OWL 2 Web Ontology Language, informally OWL 2, specified by the World Wide Web Consortium
(W3C), mainly serialized with XML syntax for RDF (RDF/XML)
Note 1 to entry: In this specification the abbreviation OWL is always an explicit reference to OWL 2.
3.1.31
point
interface to data in the system
Note 1 to entry: This document uses the term Point as an umbrella for data that can be accessed from outside
of the Device, for instance to interact with other Points from other Devices. Consequently, term Point is a generic
superset of the term Datapoint (which describes more precisely the technics how the “data” in the system are
structured and/or coded).
3.1.32
Point API
simple RESTful (CoAP or HTTP) application programming interface designed for, but not limited to,
constrained class 2 devices [RFC 7228] supporting device individualization, device linking and
accessing device runtime data
EXAMPLE Functional Block or Channel Datapoints.
3.1.33
Quality Kind
QK
certain combination of observable or actuatable properties, available as predefined parts of the
Semantic Dictionary or created individually during Configuration, it being the case when a Quality
Kind with the intended combination of properties respectively tags is not (yet) part of the dictionary
Note 1 to entry: A QK is not a “classification/type” tag itself; the “classification/ type” is accomplished with the
help of tags. Examples are defined in 4.5.1.4.
3.1.34
RDF
Resource Description Framework
standard model for data interchange on the Web
Note 1 to entry: RDF is specified by the https://www.w3.org/RDF/
Note 2 to entry: RDF is a framework to represent information in the web by using triples. The information can
be serialized and stored in many formats such as the TURTLE or JSON(-LD) format. The general RDF concept
description can be found under https://www.w3.org/TR/rdf11-concepts/
[SOURCE: https://www.w3.org/RDF/, Notes 1 and 2 to entry added.]
3.1.35
runtime
process-to-process communication of data between devices, opposing to Configuration
Note 1 to entry: This concerns mainly the communication of Datapoint values (control and status information).
3.1.36
Semantic Export
project exported by the MaC reflecting an Installation in a linked data format
Note 1 to entry: The exported data are:
—  structured according to the KIM, such as using Object Properties defined in KIM;
—  annotated with additional semantic information from the Semantic Dictionary;
—  referencing concepts of external Ontologies.
3.1.37
semantic dictionary
set of standardized terms allowing to annotate required parts of an Installation
Note 1 to entry: For details, see 4.2.9.
3.1.38
sensor
point performing an observation (executed by a specific procedure, triggered by a stimulus),
responding a result as an Installation state during Runtime
Note 1 to entry:
—  The term Sensor can be mapped to sosa:Sensor in the SSN Ontology.
—  The subject observation can be mapped to sosa:Observation in the SSN Ontology.
—  The subject stimulus can be mapped to ssn:Stimulus in the SSN Ontology.
—  The subject procedure can be mapped to sosa:Procedure in the SSN Ontology.
—  The subject result can be mapped to sosa:Result in the SSN Ontology.
3.1.39
tag
annotation term used to extend available data with (in most cases) well known standardized
information from a dictionary (in contrast to user defined, arbitrary term)
Note 1 to entry: A Tag is a concept-less term, without an integration in a broader concept such as the concept
of a Datapoint (used in an Application Function), it has a limited semantic meaning.
EXAMPLE Term “flow” has a weak meaning on its own, but if you relate it in a FOI with the other term
“water” this expresses at least that you observe/ actuate the water flow.
In this specification a Tag is almost exclusively a term from the Semantic Dictionary.
3.1.40
thing description
TD
semantic metadata model to describe (abstract or physical) things
Note 1 to entry: It is specified by the thing description https://www.w3.org/TR/wot-thing-description/ and thing
Ontology https://www.w3.org/2019/wot/td
Note 2 to entry: TD relevant relations are described in the clause of Semantic Export.
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
DHWC Domestic Hot Water Controller
FOI Function of Interest
BOC Boiler Controller
BUC Burner Controller
FTC Flow Temperature Controller
GA Group Address
GO Group Object
FB Functional Block
FP Function Point
HBES Home and Building Electronic Systems
HDTRT Heat Demand Transformer Room Temperature
HFDM Heat Flow Demand Manager
HIRC Heating Individual Room Controller
HPM Heat Producer Manager
HVA Heating Valve Actuator
HZC Heating Zone Controller
IFC Industry Foundation Classes
IOO Info On off
IO Input Output
IoT Internet of Things
KIM HBES Information Model managed by KNX Association
KNXA KNX Association
MaC Management Client
OP Object Property
QK Quality Kind
RSM Room Setpoint Manager
RTC Room Temperature Controller
RTS Room Temperature Sensor
SOO Switch on/off
TD Thing Description
4 HBES Information Model
4.1 Introduction
4.1.1 General
Facility management often uses heterogeneous visualization tools and applications to maintain a
building control system. For this, an Installation is created based on a MaC project that includes
instantiated devices and application functions assigned to specific locations. HBES IoT defines the
HBES Information Model (abbreviated as KIM) to describe a MaC project with semantic information.
A MaC can export project data with additional semantic information (so-called Semantic Export); other
clients or tools can import this project data. This is an easy and powerful way to integrate existing
project data into a third-party tool or any service of choice.
4.1.2 Models
The KIM consists of several models, extended with HBES related definitions, as shown in Figure 1.
Together they describe the different aspects of the building control domain.
Figure 1 — Main HBES Information Model sources
Each model uses an individual namespace prefix, defines a specific set of semantically standardized
entities and relationships amongst them.
1) Core model
Describes the common concepts of the building control domain for an Installation.
EXAMPLE A datapoint (I/O interface) of a device.
2) Location model
Describes the spatial location structure of an Installation.
EXAMPLE A location structure representing a building with rooms, floors, and others.
3) Tag model
Describes a set of entities used as indications for information classification. Each entity has a
standardized semantical meaning that is independent of an Installation.
EXAMPLE A device with datapoints, each assigned with specific entities, such as output or
temperature.
4) HBES model
Describes HBES System specific entities of an Installation.
EXAMPLE A device with datapoints (core model concepts), whereby a specific datapoint type is
assigned to each datapoint (an HBES model concept), such as a boolean type for the values on or off.
The HBES Model is derived from the Core, Tag and Location models in this standard. The entire
HBES Information Model (KIM) can be seen as an aggregation of the models.
HBES Information Model = Core/ Location/Tag/HBES model + Semantic Dictionary (see
Clause 4.2)
NOTE The separation between a model and its entities is needed to extend/ update them independently.
The resulting data after commissioning an Installation (MaC project data) is colloquially also called
instance data, opposite to the so-called catalogue data, which are predefined product descriptions
or content from the Semantic Dictionary. For devices, catalogue data represents all possible
configurations, whereas instance data are one specific configuration out of all possible ones.
NOTE For configuration workflow details and commonly used terminology, please refer to Clause 5.1,
section workflow.
4.1.3 Taxonomy
A taxonomy structures a domain of interest in the corresponding hierarchical sections and
subsections (but not more). An Ontology identifies and distinguishes concepts and their relationships
to a domain of interest by (re)using a taxonomy as follows:
— The taxonomy sections and subsections are represented by Ontology classes, also called
concepts.
— To represent relationships between Ontology classes, Ontology properties are added (so-called
class constraints).
Class/Concept/Individual
A taxonomy section (discrete domain of interest) corresponds to an Ontology classification or, rather,
an Ontology concept. The Ontology concept is represented by the corresponding Ontology class,
which can contain other Ontology subclasses, and this is depicted with subClassOf in this
specification.
Individuals are a concrete representation of a specific Ontology class; they are class members.
EXAMPLE The Ontology class loc:Room is part of a location taxonomy; it reflects the “available rooms in
an installation”. It is a subclass of loc:Space, which is a broader definition of a location (compared to a room).
Other classes of this location taxonomy are loc:Building or loc:Floor. The actual room myBathRoom as part of an
Installation is an individual; it is a member of loc:Room.
The main KIM Ontology class structure is shown underneath, and the parent and child subclass
relations are represented by the textual indentation of classes.
owl:Thing // the ontology root node for any taxonomy
•  core:Thing // to integrate subsequent core ontology classes (core model)

•  core:Aspect // a specific system view to grouped datapoints

•  core:ApplicationFunction // a set of functions to achieve a desired behavior
•  …
•  core:Asset // a container of installation objects such as devices, equipment,
software
•  core:Location // to integrate an individual location concept (in the core model)
•  loc:Location // a spatial location concept with rooms, floors, and others

• core:Point // an interface to interact with Points at Runtime

•  core:Datapoint
•  …
•  core:Product // a product concept

•  knx:DatapointType // to integrate standardized DPTs (HBES model)
•  knx:DatapointTypeField // to integrate standardized DPTs (HBES model)

•  tag:Tag // to integrate tag-oriented terms of the Semantic Dictionary (tag

model)
•  tag:TagSet // to integrate tag combinations of the Semantic Dictionary (tag

model)
•  qudt:Unit // to integrate QUDT (SI) units (external concept)

•  vcard:Address // to integrate a postal address (external concept)

NOTE The external concepts qudt/vcard are described where they are used and not as individual classes.
Because of size limitations and stability, the external concepts are not (OWL) imported by the KIM, as this is
usually done in OWL2. The needed individuals/classes are explicitly declared in the KIM, too.
Each Ontology class in the specific model stands for its discrete domain meaning. Hence the classes
(their meanings) are typically disjoint from each other. Where needed, the KIM expresses a required
disjoint statement.
EXAMPLE The Ontology class core:Product and core:Point are disjoint, each has its own meaning.
The Ontology class loc:Space and loc:Outside are not disjoint. A myGarden individual of member space can also
be of member outside. If disjoint, this would not be possible; in OWL, membership in one of two disjoint classes
implies no membership in the other (myGarden as a member of loc:Space cannot be a member of loc:Outside at
the same time).
Properties
Object Properties
Object properties (OP) define a relationship between individuals (members of Ontology classes).
The main KIM Ontology object property structure is depicted underneath. The parent and child object
property relations are represented by the textual indentation of properties.
• core:containsAsset // to relate between different installation assets (core model)
• core:groups // to relate an aspect to its datapoints included in it (core
model)
• core:hasPart // to relate between different tangible pieces of equipment
(core model)
• core:hasPoint // to relate between functionality and its points (core model)
• core:hasProduct
• core:hasProxy
• core:implements
• core:refersTo
• loc:hasLocation
• knx:hasFunctionPoint
• knx:hasTagSet
•  knx:hasOperationKind
•  knx:hasQualityKind
• qudt:unit
• tag:hasTag
•  knx:hasEquipmentType
•  knx:hasPhenomenonType
•  …
• vcard:has Address
The object property relations are explained in the corresponding clauses in more detail. The definition
also contains a second OP relationship predicate (in italics) that describes the corresponding inverse
relation. In general, the object property definition is structured as follows:
— OWL object property domain and range are described for the main OP relationship; domain and
range are usually interchanged for the inverse OP relationship. In case more than one class is
applicable for the domain or range (logically a union of classes), this is represented with an “/”.
— OWL object property axioms, such as symmetric or functional, are not described (see
Clause 4.1.4).
NOTE In OWL 2, an OP relationship refers to individuals.
Annotation Properties
Annotation Properties are used to define additional annotations for the Ontology; the audience for
these properties are mainly human readers of the ontology (using a tool) or software that is analysing
or preprocessing the Ontology as such.
EXAMPLE rdfs:label, rdfs:comment (Ontology class/property name/comment), rdfs:isDefinedBy (origin as
URI/URL), dct:identifier (Ontology class URN), dct:subject (Ontology class keywords, key phrases, classification
codes), knx:interfaceObjectTypeAnnotation (specific identifiers laid down by KNXA)
To also support translated content an annotation property may be present multiple times with an
additional language identifier; at least they are available in English with the related language identifier.
Annotation Properties do not affect the semantical meaning of an Ontology.
Data Properties
Data properties are used to define additional attributes for individuals; the audience for these
properties are mainly machines to classify data, compute results or transport machine-readable
instance data in an exported file.
To support translated content, a data property may be present multiple times with an additional
language identifier, mainly used for data presented to humans.
EXAMPLE dct:description or dct:title (both edited by a MaC user, may be present several times in different
languages), jsonSchema:maximum (upper value range for datapoints)
Summary
Figure 2 below depicts the basic KIM Ontology classes. The red dotted arrows show OP relationships
between entities (examples, see Figure 3). Each Ontology class may have additional annotation
properties and data properties, which are not shown in the figure.
Figure 2 — Main KIM Ontology classes and their relations
4.1.4 Versioning
The KIM and the Semantic Dictionary are versioned.
— The versioning of the KIM is realized with a dedicated Ontology Version IRI, according to the
W3C recommendations for OWL2 (clause 3.3).
The KIM is versioned as a whole; separate versioning for the used models is not foreseen. Any
incompatible model or externally used concept change leads to a new KIM version.
NOTE Across different KIM versions, the Ontology Version IRI shall be different; the corresponding
versioning identifier is described in Clause IRIs and Namespaces 4.1.6.
— The versioning of the Semantic Dictionary is described in Clause 4.2.3.
4.1.5 Availability
The KIM Ontology IRI underneath allows to retrieve the most recent Ontology as an electronic file by
using the IRI as an URL. To get a specific KIM Ontology version, the corresponding KIM Ontology
version IRI needs to be used instead as a URL.
— http://schema.knx.org/2020/ontology returns the most recent KIM Ontology version, including all
used models and the content from the Semantic Dictionary
— http://schema.knx.org/2020/ontology/v2 returns the version v2 of the KIM Ontology, using the
same Ontology IRI as specified above, extended with the required version (here “v2”)
NOTE Regardless of the IRI scheme http://, for security reasons all downloads will be performed with the
HTTPS scheme.
NOTE The electronic file is an integral part of this specification; the full extent of all Ontology classes, OPs,
and others can be retrieved from this.
The KIM is available in a linked data format.
NOTE Current formats are TURTLE or RDF/XML, but this is not limited to this. The default format for the
downloads from above is TURTLE, other formats can be obtained from https://schema.knx.org.
Data of the KIM is exchanged via Semantic Export; for details, see Clause 5.1.
4.1.6 IRIs and Namespaces
The KIM Ontology IRI is defined according to the following (simplified) principle.
{scheme} + “://” + {authority} + “/” + {path} + “/” + {version} +“#”
The KIM Ontology IRI is defined with “https://schema.knx.org/2020/ontology”.
NOTE With this the {scheme} and {authority} is defined as “http” and “schema.knx.org/2020/ontology”.
To express the IRIs for the different KIM models the {authority} and {path} shall be a string; for this,
see Table 1.
The {version} shall be a string to express the different KIM versions, together with the Ontology
Version IRI. It contains “v” concatenated with a non-zero leading decimal number, such as “v1” or
“v249”, similar to the major part in the case of semantic versioning (major.minor.patch, SemVer).
NOTE The {version} is only part of the Ontology Version IRI.
Table 1 lays down the used namespace prefixes in the KIM, their corresponding IRIs, and Ontology
references.
NOTE commonly used namespace prefixes in OWL such as rdfs: or rdf: are not listed.
Table 1 — KIM ontology names, namespaces prefixes and prefix IRIs
Ontology Namespace
a
Comment
Prefix IRI
Name Prefix Name
— data properties to
express (min/max)
JSON
jsonSchema: https://www.w3.org/2019/wot/json-schema#
limitations for datapoint
schema
values
— OPs and OWL classes to
https://qudt.org/schema/qudt/
qudt:
express units
— Semantic Dictionary
content from QUDT
https://qudt.org/vocab/unit/
unit: — individuals to express
(SI) units (defined by
QUDT
QUDT)
— Semantic Dictionary
content from QUDT
quantitykind: https://qudt.org/vocab/quantitykind/ — individuals to express
quantity tags (defined by
QUDT)
— OPs and OWL classes to
express geo addresses
VCARD vcard: https://www.w3.org/2006/vcard/ns#
for a location
Ontology Namespace
a
Comment
Prefix IRI
Name Prefix Name
— data and annotation
properties for
DCTERMS dct: https://purl.org/dc/terms/
description, title, and
other
— OPs for an URL authority
HTTP http: https://www.w3.org/2011/http#
part
— core model concepts
core: https://schema.knx.org/203/en52090-6-2/core# — {authority} as specified,
{path} = /core#
— location model concepts
loc: https://schema.knx.org/203/en52090-6-2/loc# — {authority} as specified,
{path} = /loc#
KIM
— tag model concepts
tag: https://schema.knx.org/203/en52090-6-20tag# — {authority} as specified,
{path} = /tag#
— HBES model concepts
— uses a different
knx: https://schema.knx.org/2020/ontology/knx#
{authority} as specified,
{path} = /knx#
— MaC related concepts
— uses a different
{authority} as specified,
mac: https://schema.knx.org/2020/ontology/mac#
{path} = /mac#
— how to integrate such
content see Clause 4.6
n/a
— manufacturer related
content
— uses an own {authority},
gira: http://gira.de/2022//functions/xyz#
{path} = /xyz#
— how to integrate such
content see Clause 4.6
a
The IRIs do not necessarily need to be dereferenced as an URL to access any content explanation on a
website. How to retrieve the KIM content, please refer to Clause 4.1.5).
4.2 Semantic Dictionary
4.2.1 General
The semantical understanding and meaning of an Ontology needs to be guaranteed across different
domains and especially across humans, who (pre/post-) process this information.
To support this, the KIM encompasses several KIM model Ontology classes, including assigned
terms, to describe a semantically clearly specified information of the building control domain. This is
called the Semantic Dictionary; its content is used to enrich the elements of an Installation with the
information from above.
EXAMPLE A room in an Installation needs to be tagged for its usage as a kitchen. A semantically
predefined dictionary term from the Tag model is used, the tag:kitchen with the l
...