SIST EN 17632-2:2025
(Main)Building Information Modelling (BIM) - Semantic Modelling and Linking (SML), Part 2: Domain-specific modelling patterns
Building Information Modelling (BIM) - Semantic Modelling and Linking (SML), Part 2: Domain-specific modelling patterns
This document (part 2) provides extended standard semantic modelling patterns for (at least) the following domain-specific asset aspects:
- support for distinction between two subtypes of physical objects: spatial regions and real ("tangible") objects; the latter being discrete or continuous ("bulk matter");
- support for the materialization of physical objects, adding generic chemistry aspects directly relevant for the built environment dealing with materials like concrete, steel, wood and asphalt;
- support for the interaction between objects including connections, interfaces and ports. Interactions being defined as activities where material, information, energy or forces are transferred;
- support for the definition of unstructured, human-interpretable, requirements, coming from appointing party needs, laws and regulations or sector recommendations;
- support for implicit groups having no explicit members (to model situations like "all main girders of some steel bridge");
- support for the explicit modelling of measurements reusing the existing W3C SOSA ontology (as a lightweight but self-contained SSN core ontology);
- support for spatial geometry (location/shape) reusing OGC GeoSPARQL (GML/WKT) and the WGS84_pos ontology (GPS).
Gebäudeinformationsmodellierung - Semantische Modellierung und Verknüpfungs, Teil 2: domänenspezifische Modellierungsmuster
Dieses Dokument (Teil 2) stellt erweiterte semantische Standard-Modellierungsmuster für (mindestens) die folgenden domänenspezifischen Asset-Aspekte bereit:
- Unterstützung der Unterscheidung zwischen zwei Subtypen von physischen Objekten: räumliche Regionen und reale („greifbare“) Objekte; letztere können diskret oder dauerhaft sein („Masse“);
- Unterstützung bei der Materialisierung von physischen Objekten durch Hinzufügen von generischen chemischen Aspekten, die für die gebaute Umwelt direkt relevant sind und Materialien wie Beton, Stahl, Holz und Asphalt betreffen;
- Unterstützung für die Interaktion zwischen Objekten, einschließlich Verbindungen, Schnittstellen und Anschlüssen. Interaktionen werden als Aktivitäten definiert, bei denen Material, Informationen, Energie oder Kräfte übertragen werden;
- Unterstützung bei der Definition unstrukturierter, von Menschen interpretierbarer Anforderungen, die sich aus den Bedürfnissen der Informationsbesteller, Gesetzen und Vorschriften oder Branchenempfehlungen ergeben;
- Unterstützung für implizite Gruppen, die keine expliziten Mitglieder haben (zur Modellierung von Situationen wie „alle Hauptträger einer Stahlbrücke“);
- Unterstützung für die explizite Modellierung von Messungen unter Wiederverwendung der bestehenden W3C-SOSA-Ontologie (als einfache, aber in sich geschlossene SSN-Kern-Ontologie);
- Unterstützung für räumliche Geometrie (Ort/Form) unter Wiederverwendung von OGC GeoSPARQL (GML/WKT) und der Ontologie WGS84_pos (GPS).
Modélisation des informations du bâtiment (BIM) - Modélisation sémantique et liaison (SML), Partie 2 : modèles de modélisation spécifiques à un domaine
Le présent document (la partie 2) fournit les patrons de modélisation sémantique de base étendus pour (au moins) les aspects suivants des actifs spécifiques à un domaine :
- prise en charge de la distinction entre deux sous-types d'objets physiques : régions spatiales et objets réels (« tangibles ») ; ces derniers étant discrets ou continus (« matière en vrac ») ;
- prise en charge de la matérialisation des objets physiques, en ajoutant des aspects génériques de chimie qui concernent directement l'environnement bâti et concernent des matériaux tels que le béton, l'acier, le bois et l'asphalte ;
- prise en charge de l'interaction entre les objets, notamment les connexions, les interfaces et les ports ; les interactions étant définies comme des activités au cours desquelles se produit un transfert de matière, d'information, d'énergie ou de forces ;
- prise en charge de la définition d'exigences non structurées interprétables par l'homme, provenant des besoins de la partie désignante, des lois et réglementations ou des recommandations du secteur ;
- prise en charge des groupes implicites n'ayant pas de membres explicites (afin de modéliser des situations telles que « toutes les poutres principales d'un pont d'acier ») ;
- prise en charge de la modélisation explicite des mesures en réutilisant l'ontologie W3C SOSA existante (en tant qu'ontologie allégée SSN mais de base et autonome) ;
- prise en charge de la géométrie spatiale (localisation/forme) en réutilisant le langage GeoSPARQL (GML/WKT) de l'OGC et l'ontologie WGS84_pos (GPS).
Informacijsko modeliranje gradenj (BIM) - Semantični standard za modeliranje in povezovanje (SML) - 2. del: Domensko specifični vzorci modeliranja
Ta dokument (2. del) zagotavlja razširjene standardne semantične vzorce modeliranja za (vsaj) naslednje vidike domensko specifičnih sredstev:
– podpora za razlikovanje med dvema podvrstama fizičnih objektov: prostorskimi regijami in resničnimi (»otipljivimi«) objekti, pri čemer so slednji diskretni ali kontinuirani (»v razsutem stanju«);
– podpora za materializacijo fizičnih objektov z dodajanjem splošnih kemijskih vidikov, ki so neposredno relevantni za grajeno okolje, v zvezi z materiali, kot so beton, jeklo, les in asfalt;
– podpora za interakcijo med objekti, vključno s povezavami, vmesniki in vrati.
Interakcije so opredeljene kot dejavnosti, pri katerih se prenaša material, informacije, energija ali sile;
– podpora za opredelitev nestrukturiranih, človeku razumljivih zahtev, ki izhajajo iz potreb imenovanja, zakonov in predpisov ali sektorskih priporočil;
– podpora za implicitne skupine brez eksplicitnih članov (za modeliranje situacij, kot je »vsi glavni nosilci nekega jeklenega mostu«);
– podpora za eksplicitno modeliranje meritev s ponovno uporabo obstoječe ontologije W3C SOSA (kot lahke, a samostojne jedrne ontologije SSN);
– podpora za prostorsko geometrijo (lokacija/oblika) s ponovno uporabo OGC GeoSPARQL (GML/WKT) in ontologije WGS84_pos (GPS).
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-januar-2025
Informacijsko modeliranje gradenj (BIM) - Semantični standard za modeliranje in
povezovanje (SML) - 2. del: Domensko specifični vzorci modeliranja
Building Information Modelling (BIM) - Semantic Modelling and Linking (SML), Part 2:
Domain-specific modelling patterns
Gebäudeinformationsmodellierung - Semantische Modellierung und Verknüpfungs, Teil
2: domänenspezifische Modellierungsmuster
Modélisation des informations du bâtiment (BIM) - Modélisation sémantique et liaison
(SML), Partie 2 : modèles de modélisation spécifiques à un domaine
Ta slovenski standard je istoveten z: EN 17632-2:2024
ICS:
35.240.67 Uporabniške rešitve IT v IT applications in building
gradbeništvu and construction industry
91.010.01 Gradbeništvo na splošno Construction industry in
general
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
EN 17632-2
EUROPEAN STANDARD
NORME EUROPÉENNE
November 2024
EUROPÄISCHE NORM
ICS 35.240.67; 91.010.01
English Version
Building information modelling (BIM) - Semantic
modelling and linking (SML) - Part 2: Domain-specific
modelling patterns
Modélisation d'informations de la construction (BIM) - Bauwerksinformationsmodellierung (BIM) -
Modélisation et liaisons sémantiques (SML) - Partie 2 : Semantische Modellierung und Verknüpfung (SML) -
Patrons de modélisation spécifiques à un domaine Teil 2: Domänenspezifische Modellierungsmuster
This European Standard was approved by CEN on 9 September 2024.
CEN 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 CEN
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 CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2024 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 17632-2:2024 E
worldwide for CEN national Members.
Contents Page
European foreword . 3
Introduction . 3
1 Scope . 6
2 Normative references . 6
3 Terms and definitions . 6
4 Abbreviated terms . 9
5 Semantic extensions for the built environment . 9
5.1 Spatial regions versus real objects . 9
5.2 Materialization of physical objects . 11
5.3 Interaction between objects . 12
5.4 Requirements (unstructured) . 19
5.5 Implicit groups . 20
5.6 Functions . 21
5.7 Extended QUDT reuse . 22
5.8 Observations (SOSA) . 22
5.9 Geospatial geometry (GeoSPARQL) . 23
5.10 Specializing objectifications . 25
5.11 Overview of extended modelling constructs . 25
5.11.1 Extended concepts . 25
5.11.2 Extended properties . 27
6 Implementing SML part 2 in code . 28
7 Conformance . 28
7.1 General. 28
7.2 Conformance on language level . 28
7.3 Conformance on semantic level . 29
Annex A (normative) SML part 2 implementation in ‘linked data’ . 30
A.1 General. 30
A.2 SKOS part . 31
A.3 RDFS part . 38
A.4 OWL part . 46
A.5 SHACL part . 51
Annex B (informative) SML part 2 example in SKOS/RDFS/OWL/SHACL (Turtle format) . 55
B.1 Example description . 55
B.2 OWL ontology and information set . 55
Annex C (informative) Extra SOSA information . 65
Annex D (informative) Extra SOSA example . 66
Bibliography . 69
European foreword
This document (EN 17632-2:2024) has been prepared by Technical Committee CEN/TC 422 “Building
information modelling (BIM)”, the secretariat of which is held by SN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by May 2025, and conflicting national standards shall be
withdrawn at the latest by May 2025.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN 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 standards body.
A complete listing of these bodies can be found on the CEN website.
According to the CEN-CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and the
United Kingdom.
Introduction
0.1 General
The abstract language and generic modelling patterns are already defined by the EN 17632-1.
Early practical industrial application showed that there is a ‘gap’ between these abstract/generic
patterns and the real-world modelling needs in the built environment sector.
This document defines domain-specific extensions of the generic top-level information model defined in
EN 17632-1. These extensions are especially relevant for the modelling of assets/products in the built
environment. These standard extensions will support to close this gap.
This way, stakeholders in the built environment like owners, contractors and suppliers do not have to
‘reinvent the wheel’ for themselves for these new/extended modelling patterns.
By prescribing these patterns, stakeholders-specific data models will become even more pre-integrated
easing future asset/product data exchange/sharing and data integration/innovation in findable,
accessible, interoperable and reusable (FAIR) ways.
The extended standardized modelling patterns introduced in this document may be applicable to other
industry sectors as well.
0.2 Extension with respect to part 1
The extended standard modelling patterns defined in this document (in bold below) can all be
positioned in the global modelling framework provided in the form of a taxonomy by part 1. These
concepts form the primary table of content of this part 2.
Figure 1 — extended standard modelling patterns defined in this document
NOTE 1 The reused SOSA and GeoSPARQL entities will be kept separate. That means that the actual supertypes
as indicated above will not be modelled. Further end-user modelled domain-specific concepts can have multiple
superclasses or their individuals can be multiply typed.
NOTE 2 Some of the information needs might be resolved by extending existing language level constructs (like
in the case of implicit groups just adding some attributes for existing classes or containers or the use of SHACL
rules to represent structured requirements coming from clients, building laws and regulations or from built
environment sector recommendations). Finally, there is a lot of ‘pattern potential’ under ‘DiscreteObject’ and
‘SpatialRegion’ in the built environment (road networks, tunnels, bridges, buildings, installations). Care is taken
not to cross existing standards boundaries.
1 Scope
This document (part 2) provides extended standard semantic modelling patterns for (at least) the
following domain-specific asset aspects:
— support for distinction between two subtypes of physical objects: spatial regions and real
(“tangible”) objects; the latter being discrete or continuous (“bulk matter”);
— support for the materialization of physical objects, adding generic chemistry aspects directly
relevant for the built environment dealing with materials like concrete, steel, wood and asphalt;
— support for the interaction between objects including connections, interfaces and ports.
Interactions being defined as activities where material, information, energy or forces are
transferred;
— support for the definition of unstructured, human-interpretable, requirements, coming from
appointing party needs, laws and regulations or sector recommendations;
— support for implicit groups having no explicit members (to model situations like “all main girders
of some steel bridge”);
— support for the explicit modelling of measurements reusing the existing W3C SOSA ontology (as a
lightweight but self-contained SSN core ontology);
— support for spatial geometry (location/shape) reusing OGC GeoSPARQL (GML/WKT) and the
WGS84_pos ontology (GPS).
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 for 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 17632-1, Building information modelling (BIM) — Semantic modelling and linking (SML) — Part 1:
Generic modelling patterns
ISO 6707-1, Buildings and civil engineering works — Vocabulary — Part 1: General terms
3 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 17632-1, ISO 6707-1 and the
following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• ISO Online browsing platform: available at https://www.iso.org/obp
• IEC Electropedia: available at http://www.electropedia.org/
3.1
amount of bulk matter
real object consisting of a continuous amount of matter, primarily held together by external forces
(gravity or confinement)-
3.2
chemical element
pure substance consisting of atoms with the same atomic number
Note 1 to entry: A chemical element cannot be decomposed by chemical reactions.
3.3
chemical compound
pure substance composed of two or more chemical elements chemically bonded in definite proportions
Note 1 to entry: In a chemical compound, the elements occur in a fixed ratio. A compound can be decomposed
into simpler substances through chemical reactions.
[SOURCE: ISO 817:2014, 3.1.11, modified - The word “substance” has been replaced with “pure
substance”. The word “atoms” has been replaced with “chemical elements”. The note to entry has been
added”. The word “chemical” has been added to the term.]
3.4
connection
physical object (real object or spatial region) that connects two other physical objects and over which
interaction takes place, namely the transfer of matter, energy, information or forces
3.5
discrete object
physical object consisting of a continuous amount of matter, held together by internal force
EXAMPLE Internal forces such as rigid bonds and van der Waals forces.
3.6
interaction
activity performed to transfer matter, information, energy or force, via a connection or interface
3.7
interface
spatial object, typically a thin 2D physical space (but also 0D or 1D) that connects two physical objects
or ports of physical objects through which a static or dynamic interaction or interaction between those
elements can take place
3.8
matter
chemical substance
pure substance, chemical compound or mixture from which real objects are made
3.9
mixture
combination of two or more chemical substances which are not bonded chemically
Note 1 to entry: A mixture is characterized by the molecules participating in it and the ratio of their amounts.
3.10
physical object
individual thing that has a physical nature with a limited lifespan and that may be materialized (and
then may be observable and touchable) or that may be imagined (having deemed aspects, as-if
observable)
Note 1 to entry: Physical objects (i.e. the concept ‘physical object’) is a core kind of object (or object type) with
which this standard is concerned (see 5.2). The guidelines that have been included in this standard are therefore
concerned mainly with knowledge libraries geared towards the description of physical matters. A physical object
is to be distinguished from the stuff, such as steel, that specifies the material of construction aspect of a physical
object. Physical objects may be solid or liquid or gaseous, but also electronic or electromagnetic, such as software
or radiation.
EXAMPLE Subtypes of physical object are concepts such as ones that have the following names: bridge,
switch, ventilator, pump, chair, ship, airplane, nut and bolt as well as liquid stream, application software, data file,
document and beam of light. Examples of (individual) physical objects (exemplars) are the Eiffel Tower, Paris, V-
6060 (a particular real vessel), D-101 (a particular copy of a document).
[SOURCE: ISO 16354:2013, 3.1.6]
3.11
port
physical or logical point of interaction as part of a physical object where, through a connection or
interface, an interaction can take place
Note 1 to entry: In the case of forces, it is mainly a matter of static force transfer such as constructive connections
where the ports of both sides of the connection or the interface can be linked to properties of the port, such as
occurring allowable force, fastening method, shape and standards.
EXAMPLE A cover layer is the port of the asphalt construction in the interaction with vehicles, vice versa in
the same interaction the contact surface of the tire is the port from the vehicle.
3.12
pure substance
chemical substance consisting entirely of a single chemical element or a single chemical compound
Note 1 to entry: Pure substances typically have a uniform molecular structure and isotropic properties.
3.13
real object
amount of matter
physical object (‘retaining shape’ or non-‘retaining shape’) that is (or can be) tangible and visible in
reality, man-made or naturally occurring
EXAMPLE 1 Man-made physical objects include bridges, tanks, and devices.
EXAMPLE 2 Physical object that have arisen naturally are terrains, banks, water bottoms and trees.
3.14
spatial region
physical object that encloses a particular area such as a room, roadway, and river, that is bounded by
real objects or other spatial areas (e.g. by usage or convention) and that contains primarily liquid or
gaseous amount of matter
Note 1 to entry: Typically, in a spatial region there is a gravitational field that differentiates between below, above
and lateral. As a result, the orientation of a spatial area is usually a relevant aspect.
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
0D/1D/2D/3D 0/1/2/3-dimensional
ALIM asset lifecycle information modelling
bSI building smart international
FAIR findadable, accessible, interoperable and reusable [go-fair.org]
GPS global positioning system
IFC industry foundation classes [bSI]
OGC open geospatial consortium
OWL web ontology language [W3C]
RDF(S) resource description framework (schema) [W3C]
SKOS simple knowledge organization schema [W3C]
SML semantic modelling and linking
SOSA sensor, observation, sample, and actuator ontology [W3C, OGC]
SSN semantic sensor network ontology [W3C, OGC]
W3C world wide web consortium
5 Semantic extensions for the built environment
5.1 Spatial regions versus real objects
Physical objects (functional or technical, planned or realized) shall be disjointly divided into spatial
areas that are not directly tangible and tangible real objects. (Figure 2, 'dashes' indicate relevant
properties (attributes or relations)).
Figure 2 — Division of physical objects into spatial and real
This devision can be regarded as an extra system engineering dimension orthogonal with
planned/realized and technical/functional introduced EN 17632-1. It enables the modelling of basic
“realized/technical/real” entities towards “planned/functional/spatial” entities. In short: from acreage
modelling towards fullscale Asset Lifecycle Information Modelling (ALIM) (Figure 3).
Figure 3 — Extra systems engineering dimension
DiscreteObject (‘shape retaining’) and AmountOfBulkMatter (non-‘shape retaining’) are further
specializations of RealObject.
NOTE 1 A physical object is therefore broader than just 'an embodiment of mass/energy'. Meaningful
('semantic') physical spaces/times (unlike abstract mathematical spaces/times) are also included here under
physical object.
NOTE 2 A (semantic) temporal region would also have been relevant (such as 'The Middle Ages') but is not
included here.
NOTE 3 The 'contains' relation for a spatial region can be used for real objects located in that region and for the
typically gaseous amount of bulk matter present in that region.
NOTE 4 The 'consistsOf' relation towards matter is only relevant for technical objects (not functional objects).
NOTE 5 OGC's GeoSPARQL [2] has a spatial object: 'geo:SpatialObject', defined as: “the class spatial object
represents everything that can have a spatial representation. It is a superclass of feature and geometry”. So, this is
a much broader definition than the spatial region. For example, the real object is also a spatial object in this
interpretation.
EXAMPLE 1 (real objects) Examples of real objects are bridge, bridge deck, pavement, wall, floor.
EXAMPLE 2 (spatial regions) IfcSpace is used in ISO 16739-1 [3] to model a spatial area in a building. Other
examples of spatial areas are roadway, lane, tank content, area, funnel, corridor and free space profile.
EXAMPLE 3 (amount of bulk matter) Examples of amounts of bulk matter are an amount of air in a spatial
region, an amount of liquid in a pipe or river, and an asphalt batch.
5.2 Materialization of physical objects
Matter is seen as a special case of a physical object (also called a 'pseudo-object') and shall be divided
according to Figure 4 (schematic) and Figure 5 (model-based).
Figure 4 — Devision of matter
Figure 5 — Matter taxonomy
NOTE 1 Exotic states of matter such as ‘Bose–Einstein condensates’ are not relevant for construction are left
out for simplicity.
A predefined subtype of RelationReference is MatterPortion. This is an objectification of the consistsOf
relation towards Matter. A predefined metadata attribute is ‘portion’ being a unitless ratio like a
percentage).
NOTE 2 A MatterPortion can indicate a fragment of a certain substance in a mixture or other matter portion.
EXAMPLE (matter) Examples of chemical elements are oxygen (O2) and hydrogen (H2). An example of a
chemical compound is water (H O). Examples of mixtures are cement, an asphalt mixture such as ZOAB-16, steel,
concrete, composite, sand and crushed stone.
NOTE 3 Matter can be transformed (creation, modification, deletion) by an activity. Specifically, matter
represents all the intensive (bulk) properties of a physical object (real object or mixture). This means that all
physical processes that have to do with heat, light, electrical conduction, sound, etc. also take place via (interaction
with) matter. And processes such as evaporation, freezing, melting, boiling also affect the state of matter (as a
result of which in some cases the object suddenly transforms from ‘shape retaining’ to non-‘shape retaining’, for
example the melting of an ice floe/glacier).
NOTE 4 A chemical formula is optional as it is only relevant for technical matter.
NOTE 5 The state of aggregation depends on the initial conditions with regard to atmospheric pressure and
temperature.
5.3 Interaction between objects
In integral design and demountability in sustainable recycling (material passports), the correct
modelling of interactions over connections and related transfers between physical objects is becoming
increasingly important.
NOTE 1 Especially true for electrical/hydraulic installations.
Static information of assets is increasingly moving towards dynamic (simulation) information in which
behavioural aspects are included.
EXAMPLE Ventilation, drain water, lighting, skid resistance.
Asset management tends to shift from factual state information to information about the behaviour in
time and requires therefore more information about the connections between parts of the assets.
Existing traditional connections such as energy transfer between rooms in buildings and forces transfer
in support systems of civil structures are then no longer sufficient.
Figure 6 describes the theoretical patterns to position these connections in general.
Figure 6 — Interactions over connections
The ‘connection 1-2' (between Object 1 and Object 2) is a derived 'shortcut' for the existing chain of
relations as numbered in Figure 6:
1. executes;
2. transforms;
3. isTransformedBy (the inverse of transforms);
4. isExecutedBy (the inverse of executes).
Or using a 'sub-shortcut':
1. executes;
2. 2.+3.: ‘has interaction with’;
3. isExecutedby.
From this theory there is a connection between objects if there are two activities, respectively executed
by these objects, which are related through a third passive object, being a flow (material, information or
energy) or force, which is transferred from the one to the other. These two activities are both part of an
Interaction, in itself also an activity, in which these two objects participate.
It is precisely this 'Interaction' and 'Connection' between physical objects that is explicitly standardized
in this document.
First an ‘Interaction’ concept as a specialization of an ‘Activity’ is introduced. Also, a ‘participatesIn’
relation is introduced to indicate that physical objects participate in such an interaction.
Interactions have a transfer type that shall be the same in an interaction. Options for this type are:
material flow, information flow, energy flow and force transfers from one physical object to another.
This activity modelling is optional. The connection between the objects is also optional, but is more
easily applied. This connection between physical objects can be established in several ways. Five
options are discussed below of which one shall be slected.
Option 1: Directly via a 'isConnectedTo' relation (Figure 7).
Figure 7 — Direct relation between objects
The direct isConnectedWith relation can also be between ports of physical objects or between ports and
objects. In the latter case, the port is not the port of that connected object.
Option 2: With an explicit ‘Interface’ concept (itself a specialization of ‘SpatialRegion’), which also
establishes a relation to the connected physical objects via the relation 'connectsObject'. An interface is
not a real object but 'just' a spatial area where two physical objects come together (Figure 8).
Figure 8 — Indirect relation via an interface
Option 3: With an explicit ‘Connection’ concept (itself a specialization of ‘PhysicalObject’), which
establishes a relation to the connected physical objects via the relation 'connectsObject' (Figure 9).
Figure 9 — Indirect relation via a connection
Option 4: As in option 2 but now with a ‘Port’ concept added, a specific part of one or both physical
objects involved, via the relation 'connectsPort' instead of 'connectsObject' (Figure 10).
Figure 10 — Indirect relation via an interface between ports
Option 5: As in option 3 but now with a ‘Port’ concept added, of one or both physical objects involved,
via the relation 'connectsPort' instead of 'connectsObject' (Figure 11).
Figure 11 — Indirect relation via a connection between ports
The following modelling constructions are included for this purpose (Figure 12).
Figure 12 — Modelling constructs for interaction
NOTE 2 Connections and ports are defined as specializations of physical objects. The divisions into spatial/real,
functional/technical and planned/realized are therefore also available.
EXAMPLE A functional connection between functional objects can be implemented by a technical connection
between technical objects that implement the connected functional objects.
NOTE 3 With forces, objects do not have to be stuck, for example there may be slip. So, it concerns forces on all
kinds of topological connectivity.
5.4 Requirements (unstructured)
For defining unstructured (human-interpreted) requirements, the following modelling constructs shall
be used (Figure 13):
Figure 13 — Modelling constructs for requirements
The underlying values for requirementSourceType, requirementSeverityType, and
requirementTopicType are sml:EnumerationType instances without predefined allowed values. Those
allowed values may vary by end user ontology.
NOTE 1 A Requirement can be relevant for any TopConcept (no domain restriction)
NOTE 2 Structured requirements are best modelled as constraints (as in a linked data language binding: as
OWL restrictions or SHACL shapes). Based on these constraints, requirements can then be analysed according to
the standard OWL 'entailment' and SHACL verification respectively.
EXAMPLE (use of SHACL with structured requirements, incl. SHACL-AF code for derivation)
:Toilet
rdf:type owl:Class ;
rdf:type sh:NodeShape ;
sh:rule [
rdf:type sh:SPARQLRule ;
sh:message "Calculation of toilet area" ;
sh:prefixes ;
sh:construct """CONSTRUCT {$this:area ?area . }
WHERE {$this:width ?width .
$this:depth ?depth .
BIND (?width * ?depth AS ?area) . }""" ;
] ;
sh:sparql [
rdf:type sh:SPARQLConstraint ;
sh:message "Minimal area toilet"@en ;
sh:prefixes ;
sh:select """SELECT $this ?area
WHERE {
$this:area ?area .
FILTER (?area < 1.08) . }""" ;
] .
5.5 Implicit groups
Sometimes there is a need to implicitly describe a collection of individuals. Typically this concerns
collections of parts. Not by an explicit enumeration of all described individuals, but by the specification
of an implicit group of parts.
For these special groups, rdfs:Container shall be used (again). In the fully implicit case, no members are
modelled. However, standard restrictions can indicate how many and of what type the members are.
For this, the standard OWL restrictions and SHACL shapes are used. These are now not used to define a
subtype but directly to type the group instance.
EXAMPLE A group of 300 hectometre posts (HMP’s) that are all yellow; of which four are explicitly identified.
:HMPgroup_1
a rdfs:Container ;
a [
a owl:Restriction ;
owl:allValuesFrom [
a owl:Class ;
rdfs:subClassOf:HectometerPost ;
rdfs:subClassOf [
a owl:Restriction ;
owl:hasValue "Yellow" ;
owl:onProperty:colour ;
] ;
] ;
owl:onProperty rdfs:member ;
] ;
a [
a owl:Restriction ;
owl:cardinality 300 ;
owl:onProperty rdfs:member ;
] ;
rdfs:member:HMP_1 ;
rdfs:member:HMP_2 ;
rdfs:member:HMP_3 ;
rdfs:member:HMP_4 .
This group can be attached to a GuidingConstruction by the predefined sml:hasPartsGroup relation:
:GC-NorthernRoadside
a:GuidingConstruction ;
sml:hasPartsGroup:HMPgroup_1 .
NOTE 1 Cardinality constraints for these implicit groups are not included in the SHACL variants. By definition,
the implicit instances are not present, so these shapes will never yield positive verification.
NOTE 2 Mixed situations can be modelled where the known members are explicitly modelled.
NOTE 3 It is also possible to attach properties and relations to groups (e.g. averages or totals over the values
for the members of the group).
NOTE 4 Grouping is independent of decomposition. Explicit group members can therefore occur in parallel in a
decomposition tree.
5.6 Functions
Practical application of part 1 revealed that there is often a need to classify something (an
instance/individual) as a FunctionalEntity and as an Activity. Therefore, a shortcut is provided in the
form of a Function (Figure 14):
Figure 14 — The Function shortcut
This Function can be directly instantiated or via subtyping.
EXAMPLE 1 (instantiation)
ex:Attaching_20 rdf:type sml:Function .
EXAMPLE 2 (subtyping)
ex:Attaching rdfs:subClassOf sml:Function .
ex:Attaching_20 rdf:type ex:Attaching .
5.7 Extended QUDT reuse
For even more reuse of existing QUDT modelling patterns the following alternatives for existing SML
Part 1 patterns are provided:
• sml:QuantityValue = = qudt:QuantityValue
• rdf:value = = qudt:numericValue for quantities and qudt:value for qualities/references
• sml:hasUnit = = qudt:unit
• sml:hasQuantityKind = = qudt:hasQuantityKind
(beyond SML-1 qudt:QuanityKind and qudt:Unit)
NOTE 1 These alternative QUDT-based patterns are often used in the modelling patterns defined by W3C SOSA
(see 5.8).
NOTE 2 qudt:unit not to be confused with qudt:hasUnit which related a unit to a system of units.
5.8 Observations (SOSA)
For observation modelling, the existing SOSA ontology [1] shall be used. The ‘Sensors, Observations,
Samples, and Actuators’ (SOSA) ontology was jointly prepared by the World Wide Web Consortium
(W3C) and the Open Geospatial Consortium (OGC). SOSA is a simplified, practical subset of the quite
large and complicated W3C Semantic Sensor Network (SSN) ontology.
EN 17632-1 defines ‘properties’ as attributes like qualities or quantities, or relations in a simple and a
complex way. Simple properties are directly modelled in the available language constructs, without
further objectification in between. Complex properties are modelled via an explicit ‘property value’
concept so that values become ‘property value’ instances.
This complex property modelling was originally inspired by part of the (SOSA) ontology approach that
is also reusing QUDT for quantity kinds and units.
The full SOSA approach not only objectifies the property value but also the property itself. So, it applies
a “double objectification” for maximum flexibility, making it possible to add all kind of metadata
without entering ‘OWL Full ’ territory. It can be seen as a futher extension of the standard complex
property modelling capability provided by SML part 1.
NOTE 1 SOSA can also be used for static (time-invariant) properties (unlike in SSN, the time-related properties
are optional).
NOTE 2 SOSA can also be used for qualitative (static or dynamic) properties. In that case qudt:numericValue
can be replaced by the more generic rdf:value also covering non-numeric values (QUDT is not providing a non-
numeric value variant since its scope is quantity-oriented). This can be relevant when only one complexity level
application is preferred knowing SOSA is a bit overdone for qualitative properties (since units are not relevant
etc.).
NOTE 3 One typically deals with asserted detailed (raw) data and inferred/derived more global/aggregated
data. Both are seen as observations.
NOTE 4 Extra SOSA information and a SOSA example can be found in the informative Annex C respectively D.
5.9 Geospatial geometry (GeoSPARQL)
Typically two kinds of geometry are distinguished related to physical objects (‘real objects’or ‘spatial
regions’):
• CAD/BIM-based detailed geometry (like bSI IFC geometry); and
• GIS-based global geometry.
OGC’s GeoSPARQL version 1.1 [2] should be used , for simple geometric representations for the second
kind:
• geo:SpatialObject
• geo:Feature
- geo:hasGeometry geo:Geometry
• geo:Geometry
• geo:hasGeometry, with various subproperties:
• geo:hasCentroid
• geo:hasBoundingBox
• geo:hasVolume
Any sml:PhysicalObject instance can also be classified as a geo:Feature obtaining the geo:hasGeometry
property. Any sml:GeometricRepresentation instance can also be classified as a geo:Geometry. When
used, the geo:hasGeometry takes over the existing (more semantic!) sml:hasBoundary and/or
sml:hasInterior properties.
An unconstraint variant of OWL having the full power of the underlying RDF (with known decidability issues).
One Turtle-error was fixed: a special dash was changed in a normal dash resulting in "OGC GeoSPARQL - A
Geographic Query Language for RDF Data OGC 11-052r5"@en.
GeoSPARQL provides several geo:Geometry subclasses via GML Simple Features (prefixed as ‘sf’):
• sf:Point
• sf:LineString
• sf:Polygon
which can be given a value in two ways:
• via geo:asWKT, or
• via geo:asGML.
In the first case a value can be assigned according to the datatype geo:wktLiteral. A so-called Reference
System Identifier (SRID) URI can be added.
EXAMPLE 1
“ Point(−83.38
33.95)”^^geo:wktLiteral
When the SRID is omitted the default CRS is assumed is:
http://www.opengis.net/def/crs/OGC/1.3/CRS84.
EXAMPLE 2
ex:NationalMall a ex:Park;
rdfs:label "National Mall";
geo:hasGeometry ex:NMPoly .
ex:NMPoly a sf:Polygon;
geo:asWKT "POLYGON((−77.050125 38.892086, −77.039482 38.892036,
−77.039482 38.895393, −77.033669 38.895508, −77.033585 38.892052,
−77.031906 38.892086, −77.031883 38.887474, - 77.050232 38.887142,
−77.050125 38.892086))"^^geo:wktLiteral .
EXAMPLE 3 (other simple feature geometries)
“POINT (33.95 −83.38)”^^geo:wktLiteral
“LINESTRING(long1 lat1, long2 lat2, …)“^^geo:wktLiteral
“POLYGON ((−77.2 38.8, −77 38.8, −77 39, −77.2 39.9, −77.2
38.8))"^^geo:wktLiteral
“POLYGON((long1 lat1, long2 lat2, …, long1 lat1), (longA latA, longB
latB, …, longA latA))“^^geo:wktLiteral (representing a polygon with a
hole)
In the second case the GML Simple Features code is used directly (again as strings). The datatype is
changed from geo:wktLiteral to geo:gmlLiteral.
EXAMPLE 4
geo:asGML "
srsName="EPSG:28992">
97372 487153 97372 580407 149636 580407
149636 487153 97372
487153"^^geos
parql:gmlLiteral .
In all cases, standard GeoSPARQL properties can be reused:
• geo:dimension
• geo:coordinateDimension
• geo:spatialDimension
• geo:isEmpty
• geo:isSimple
• geo:is3D
The WGS84_pos ontology for Global Positioning System (GPS) is reused only for latitude, longitude and
altitude:
• wgs84_pos:lat
• wgs84_pos:long
• wgs84_pos:alt
5.10 Specializing objectifications
In case of complex properties, one loses the (easy/direct) possibility to:
1. indicate the range of the property (now for rdf:value); and
2. indicate the domain of a sub or meta property for such a property
(since the sml:QuantityValue, sml:QualityValue or sml:RelationReference cannot/should not be
adapted).
NOTE 1 Sometimes a complex restriction/shape involving chaining of properties in OWL could be applied but
this is not recommended for simplicity. In SHACL this approach is easier (involving sh:path (p1 p2)).
This document extends the complex property modelling pattern by indicating that the objectified value
classes can be subclassed into user-defined complex value classes. This class can then be used as range
respectively domain where needed.
NOTE 2 In fact, it can be done already (the standard does not say it is NOT allowed) but here this possibility is
made more explicit.
NOTE 3 In case of RelationReference/enumeration, make sure there is a clear difference (also in naming) for
the enumeration type and the specific objectified reference having that enumeration type as the range of its
rdf:value.
5.11 Overview of extended modelling constructs
5.11.1 Extended concepts
• MatterPortion
• Interface
• DiscreteObject
• AmountOfBulkMatter
• Matter
• PureSubstance
• ChemicalElement
• ChemicalCompound
• Mixture
• HomogeneousMixture
• HeterogenousMixture
• Connection
• Port
• Requirement
• RequirementTopicType
• RequirementSeverityType
• RequirementSourceType
• Interaction
• sosa:Observation
• sosa:FeatureOfInterest
• sosa:Result
• sosa:ObservableProperty
• sosa:Procedure
• sosa:Sensor
• time:Instant
• geo:SpatialObject
• geo:Feature
• geo:Geometry
5.11.2 Extended properties
Table 1 — Specified top level properties
Domain Property Range
SpatialRegion isBoundBy PhysicalObject
SpatialRegion contains RealObject
RealObject or Mixture consistsOf Matter
Matter chemicalFormula String
Matter aggregationStateType AggregationStateType
Connection connectsObject PhysicalObject
Connection connectsPort Port
PhysicalObject participatesIn Interaction
PhysicalObject isConnectedTo PhysicalObject
Interaction overConnection Connection
Interaction overPort Port
Interaction transferType TransferType
TopConcept hasRequirement Requirement
Requirement hasValue String
Requirement requirementSourceType RequirementSourceType
Requirement requirementSeverityType RequirementSeverityType
Requirement requirementTopicType
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...