ISO 23387:2025
(Main)Building information modelling (BIM) — Data templates for objects used in the life cycle of assets
Building information modelling (BIM) — Data templates for objects used in the life cycle of assets
This document provides the concept of data templates developed to enable machine interpretability based on a standardized data structure, carrying the alphanumerical information for any object used in the life cycle of assets. This document provides a description of how data templates are implemented following ISO 12006-3. This document provides a methodology to create and maintain data templates in data dictionary. This document provides guidance for linking between data templates and classification systems within data dictionaries based on ISO 12006-3. This document provides an XML Schema Definition (XSD) representing an implementation of the ISO 23387 and ISO 12006-3 data models. It is not within the scope of this document to provide the content of any data templates.
Modélisation des informations de la construction (BIM) — Modèles de données pour les objets utilisés durant le cycle de vie des biens
Le présent document décrit le concept de modèles de données conçu pour permettre une interprétation par machine basée sur une structure de données normalisée, contenant les informations alphanumériques pour tout objet utilisé dans le cycle de vie des biens. Le présent document décrit la manière dont les modèles de données sont mis en œuvre conformément à l’ISO 12006-3. Le présent document fournit une méthodologie pour la création et la gestion de modèles de données dans des dictionnaires de données. Le présent document donne des recommandations pour la liaison entre les modèles de données et les systèmes de classification dans les dictionnaires de données, sur la base de l’ISO 12006-3. Le présent document fournit une définition de schéma XML (XSD) représentant une mise en œuvre des modèles de données de l’ISO 23387 et de l’ISO 12006-3. La fourniture du contenu des modèles de données ne relève pas du domaine d’application du présent document.
General Information
Relations
Standards Content (Sample)
International
Standard
ISO 23387
Second edition
Building information modelling
2025-09
(BIM) — Data templates for objects
used in the life cycle of assets
Modélisation des informations de la construction (BIM) —
Modèles de données pour les objets utilisés durant le cycle de vie
des biens
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Data template structure . 3
4.1 General .3
4.2 UML representation of a data template structure .4
4.3 URIs usage for ISO 23887 data model . .5
4.4 Data modelling .5
4.4.1 General .5
4.4.2 Reference document .5
4.4.3 Object type .5
4.4.4 Data template .6
4.4.5 Group of properties .6
4.4.6 Property .7
5 ISO 12006-3 representation . 9
5.1 General .9
5.2 Definition of subject kinds .9
5.3 Specialization of dictionary meta level subject kinds .10
5.4 Subject relationships .11
5.5 Property relationships . 12
5.6 Data template representation following ISO 12006-3 . 12
6 XML representations . 14
Annex A (informative) Examples, use cases and implementations .15
Annex B (informative) Creation of data templates .25
Annex C (informative) Data template concepts attributes with examples .27
Annex D (informative) Correct instantiation case of subtypeOf relationship .31
Annex E (informative) XSD representation .32
Annex F (informative) XML example .33
Bibliography .34
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade Organization
(WTO) principles in the Technical Barriers to Trade (TBT), see http://www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 59, Buildings and civil engineering works,
Subcommittee SC 13, Organization and digitization of information about buildings and civil engineering
works, including building information modelling (BIM), in collaboration with the European Committee
for Standardization (CEN) Technical Committee CEN/TC 442, Building Information Modelling (BIM), in
accordance with the Agreement on technical cooperation between ISO and CEN (Vienna Agreement).
This second edition cancels and replaces the first edition (ISO 23387:2020), which has been technically
revised.
The main changes are as follows:
— the data model has been harmonised with ISO 12006-3:2022;
— an XML Schema Definition has been provided.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
Building information modelling (BIM) provides a digital process for describing and displaying information
required in the planning, design, construction and operation of assets. This approach encompasses all
aspects of the built environment, including civil infrastructure, utilities and public space.
The ISO 19650 series sets out the concepts and principles for business processes across the built environment
sector in support of the management and production of information during the life cycle of assets when
using building information modelling (BIM). To support the management and production of information
in these business processes, standardization is of the highest importance. Machine-interpretable data are
essential to providing a reliable and sustainable exchange of information in an asset life cycle process.
Data templates provide a standardized data structure to describe the characteristics of objects enabling
seamless information exchanges of construction sector business semantics through the life cycle of assets.
This document enables data templates to be standardized and made available across the built environment
sector, and where applicable through data dictionaries based on ISO 12006-3.
Data templates can be used in conjunction with Industry Foundation Classes (IFC) in ISO 16739-1.
The target audience of this document is:
— software developers, for embedding the data structure in software, platform etc.;
— built environment sector domain experts appointed to create data templates based on sources describing
information needs;
— sector practitioners, as they provide the demand, use of data, and process etc.;
— authorities, as they review and check all relevant submissions;
— research and development personnel, as they support the innovation and continuous development of
data templates;
— educational institutions, as the concept of data templates, same as BIM, and digital information principles
should be merged into education and training programs;
— developers (asset owners), as they need a clearer vision on data template, hence to put this as part of the
tender documents.
v
International Standard ISO 23387:2025(en)
Building information modelling (BIM) — Data templates for
objects used in the life cycle of assets
1 Scope
This document provides the concept of data templates developed to enable machine interpretability based
on a standardized data structure, carrying the alphanumerical information for any object used in the life
cycle of assets.
This document provides a description of how data templates are implemented following ISO 12006-3.
This document provides a methodology to create and maintain data templates in data dictionary.
This document provides guidance for linking between data templates and classification systems within data
dictionaries based on ISO 12006-3.
This document provides an XML Schema Definition (XSD) representing an implementation of the ISO 23387
and ISO 12006-3 data models.
It is not within the scope of this document to provide the content of any data templates.
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.
ISO 23386, Building information modelling and other digital processes used in construction — Methodology to
describe, author and maintain properties in interconnected data dictionaries
ISO 12006-3, Building construction — Organization of information about construction works — Part 3:
Framework for object-oriented information
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
data dictionary
database that contains metadata
[SOURCE: ISO/IEC 2382:2015, 2121501, modified — The admitted term "information resource dictionary"
has been removed; notes to entry have been removed.]
3.2
data template
data structure used to describe the characteristics of objects (3.4)
EXAMPLE 1 A data template offers a view tailored to a specific information requirement. For example, a heating,
ventilation and air conditioning (HVAC) system (3.11) designer may require descriptions of HVAC products that can be
imported into the design system.
EXAMPLE 2 A data template provides manufacturers with a standardized data structure that can be applied to
any internal system or process, or both, of handling product data. For example, one or several product information
management systems can apply or map to this structure to enable machine interpretability, both internally and with
any requests from any software using the same data template structure. An HVAC product manufacturer can then
answer the request from any stakeholder including the HVAC system designer.
Note 1 to entry: The relevant scope of the data template can be used together with the term “data template”. For
example, a data template for a product (3.8) can be named “product data template”; a data template for a system can
be named “system data template”.
Note 2 to entry: A data template can be used in an information exchange for a specific purpose for an object type (3.5)
in the inception, brief, design, production, operation and demolition of assets.
3.3
data sheet
data input in accordance with a data template (3.2), that represents a real-world product (3.8), asset or
requirement
EXAMPLE 1 Product using property (3.9) "thermal transmittance" with unit W/(m ⋅K) is of value 0,9.
EXAMPLE 2 Requirement using property "height" with unit mm is of value 600.
3.4
object
any part of the perceivable or conceivable world
EXAMPLE Instance of a “calcium silicate masonry unit” object type (3.5).
Note 1 to entry: An object may represent a design object, intermediate product (3.8), finished product, finishing tool or
equipment, system (3.11), assembly, space, building, etc.
[SOURCE: ISO 12006-2:2015, 3.1.1, modified — The original note 1 to entry has been replaced by a new one,
EXAMPLE has been added.]
3.5
object type
representation of objects (3.4) that share common characteristics
Note 1 to entry: The role of the object type is to classify the data template (3.2).
3.6
group of properties
collection of properties (3.9) enabling them to be prearranged or organized
[SOURCE: ISO 23386:2020, 3.14, modified — The definition has been updated to clarify that the collection is
for properties; notes to entry have been removed.]
3.7
machine-interpretable data
data that is in a specific context and format and can be read and stored in a computer system (3.11) such that
action can be taken based on the content of the data
[SOURCE: ISO 10303-232:2002, 3.5.3, modified — The preferred term has been changed from "computer
interpretable data" to "machine-interpretable data"; "may" has been replaced by "can"; EXAMPLE has been
removed.]
3.8
product
item manufactured or processed for incorporation in construction works
[SOURCE: ISO 6707-1:2020, 3.4.1.2, modified — The preferred term "construction product" has been
removed; note 1 to entry has been removed.]
3.9
property
defined characteristic suitable for the description and differentiation of an object (3.4)
EXAMPLE Length according to EN 12058, sound reduction index according to ISO 10140-4.
Note 1 to entry: When a property is named together with reference to a technical specification, where the instructions
to assess the performance are available (usually standards), it is to be regarded as a specific property. The relationship
between the property and the specific property is modelled as a parent child relationship.
[SOURCE: ISO 22274:2013, 3.25, modified — The words "the objects in a class" have been replaced with "an
object"; EXAMPLE has been replaced; note 1 to entry has been added.]
3.10
reference document
publication that is consulted to find specific information, particularly in a technical or scientific domain
EXAMPLE EN 771-1:2011+A1:2015.
Note 1 to entry: A reference document can be associated with any data present in a data dictionary (3.1).
[SOURCE: ISO 23386:2020, 3.18, modified — EXAMPLE has been added.]
3.11
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
EXAMPLE The object “wall” which is composed of parts is a system.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46, modified — EXAMPLE has been added; notes 1 to 3 to entry have
been removed.]
4 Data template structure
4.1 General
The objective of data templates is a common way to exchange object data. Therefore, all data templates
follow the same general data structure (meta model). A data template is meant to provide a standardized
structure for a pre-defined information delivery – a data sheet – for an object type, for a specific use case or
any other purpose.
The data template structure consists of the concepts object type, data template, property, reference
document, and group of properties. Quantities, units and values are attributes of the properties, according
to ISO 12006-3, and therefore not modelled as separate concepts in the UML model in Figure 1.
Where relevant, the data template has a relationship to an object type. Depending on the purpose of the
information exchange, it is possible to create multiple data templates for one object type, having common or
disjoint properties.
Both data templates and groups of properties can be used for providing a pre-defined information delivery.
For example, the geometrical properties "width", "length" and "height" can be collected under the group of
properties "dimensions". Which of the concepts to use depends on the purpose of the information delivery
and the intended behaviour of the data sheet.
All the concepts of a data template may have a relationship to an external document such as a standard, a
technical specification, report, guideline or similar. The reference document provides the definition of the
concept element. A few more relationships exist which are illustrated in Figure 1.
Object types, data templates, properties, groups of properties, and reference documents are all concepts
that are created, managed and stored within a data dictionary. The data dictionary implementation shall
be based on ISO 12006-3. All concepts in this document shall be created following the management rules to
author and maintain properties and groups of properties as defined in ISO 23386. The governance of data
dictionaries prevents duplication, while providing clear definitions of all concepts in data templates.
As ISO 12006-3 supports interconnections of data dictionaries, a data template can use concepts accordingly.
Therefore, a data template can be composed by concepts from different data dictionaries. This is illustrated
in Clause A.1.
A data template applies to both single object types and systems or compositions of object types. For example,
a data template applies to a window as a single object type, but also to a window with its components. It also
applies to a system incorporating the window, like an external wall system. An example of a wall system
with components is given in Clause A.4.
A data template applies to object types representing any part(s) of the object life cycle, from early design,
through specification, and for physical objects (products or system of products). Where applicable,
definitions of object types and properties should be reused throughout the object life cycle.
4.2 UML representation of a data template structure
The data template representation in Figure 1 uses the Unified Modelling Language (UML). Figure 1 provides
modelling rules for concepts and their relationships. In addition to UML relationships, names are added to
them to provide relationship semantics, corresponding to ISO 12006-3, explained in Table 3.
Figure 1 — UML representation of a data template structure
4.3 URIs usage for ISO 23887 data model
This document introduces an additional attribute that is applicable to all concepts in a data template, the
URI, which can be used alongside the UUID which is mandatory in ISO 12006-3. UUIDs may be incorporated
into URIs where relevant, but this is not mandatory, particularly when URIs can include user-friendly
information.
UUIDs are primarily intended for internal references within a data dictionary, ensuring unique and
consistent identification. While UUIDs can serve as external references in scenarios where defining URIs is
impractical, this approach is not recommended. URIs are generally preferred for external references due to
their flexibility and ability to convey meaningful information. Consequently, URIs should be prioritized for
external referencing whenever feasible.
4.4 Data modelling
4.4.1 General
The data template structure consists of a data template that has an object type, properties, and groups of
properties, with reference documents providing the source of each of the concepts.
A data template is modelled within the context of one object type to provide a pre-defined information
delivery.
One object type may be assigned to several data templates. Each data template may contain one or more
properties, and within each data template the properties can be collected in different groups of properties.
The rules for modelling the data template structure with its concepts appy within the context of one data
template. The modelling rules in Figure 1 are described in 4.4.2 to 4.4.6.
Annex A provides examples of possible data modelling approaches, together with use cases and examples.
Annex B provides a possible workflow for creating data templates.
Annex C provides examples of data template concepts’ attributes.
4.4.2 Reference document
A reference document may be related to several object types, data templates, groups of properties, and
properties. Therefore, the modelling rules are zero to many (0.*) data templates, groups of properties, and
properties.
4.4.3 Object type
The object type:
a) should ideally be defined based on a standard (terminology standard, technical standard, etc.); however,
this is not mandatory as an object type may be defined in other sources than standards; the object
type can be defined in several reference documents; the modelling rule is zero to many (0.*) reference
documents;
b) needs a data template to relate properties to it; one object type can belong to multiple data templates;
the modelling rule is one to many (1.*) data templates;
EXAMPLE 1 An object type can belong to multiple data templates when it is part of a system. A more detailed
example is provided in Figure A.5.
c) can be composed of (has part relationship) other object types; the modelling rule is zero to many (0.*)
object types;
EXAMPLE 2 A wall is composed of layers of products.
d) can be part of the composition of another object type; within the context of one object type, this can be
maximum one object type; the modelling rule is zero to one (0.1) object type.
4.4.4 Data template
The data template:
a) defines a complete and unique information delivery within a context or with a specific purpose;
b) has a list of unique properties; the modelling rule is zero to many (0.*) properties;
EXAMPLE 1 A design specification is a data template.
EXAMPLE 2 A delivery ticket is a data template
c) may have groups of properties to allow for categorization of properties within the data template to
provide subsets of the template properties, fulfil part(s) of the data template overall purpose, or fulfil
any other specific information need, the modelling rule is zero to many (0.*) groups of properties;
d) can be related to an object type, the modelling rule is zero to one (0.1) object types;
e) can be based on one or more reference documents, the modelling rule is zero to many (0.*) reference
document;
EXAMPLE 3 A reference document for a template can be a design or product standard, or another technical
specification.
f) can be composed of (has part relationship) other data template concepts; the modelling rule is zero to
many (0.*) data template;
EXAMPLE 4 A data template can be composed of other data template e.g. when a wall is composed of layers of
materials or products. An example is provided in Figure A.5.
g) can be part of the composition of another data template concept, within the context of one data template,
this can be maximum one data template concept; the modelling rule is zero to one (0.1) data template
concepts.
4.4.5 Group of properties
The group of properties:
a) defines a common context or purpose for a collection of properties;
EXAMPLE 1 Properties within one data template relevant to different domains or recipients, such as technical,
financial and environmental properties, can be collected in different groups of properties based on the domain.
EXAMPLE 2 Within a data sheet, properties necessary at different times or stages during a construction
process may be collected in groups of properties if the property values remain constant over time or across stages.
b) shall at a minimum have one property, the modelling rule is one to many (1.*) properties;
c) shall be related to a data template and it can be related to multiple data templates; the modelling rule is
one to many (1.*) data templates;
d) can be based on one or more reference documents, e.g. a design or product standard, or another technical
specification; the modelling rule is zero to many (0.*) reference documents;
e) can be composed of (has part relationship) other groups of properties, the modelling rule is zero to
many (0.*) groups of properties;
f) can maximum be part of one group of properties, within the context of one group of properties; the
modelling rule is zero to one (0.1) groups of properties.
4.4.6 Property
A property:
a) may be based on a reference document; the modelling rule is zero to many (0.*) reference documents;
b) shall be related to a data template; the modelling rule is one to many (1.*) data templates;
c) may be grouped in a group of properties; the modelling rule is zero to many (0.*) groups of properties;
d) can be specialized; where a property is a specialization of another more generic property; the
specializing property’s value shall be a valid value of the target property; where a property is defined as
the specialization of another more generic property, the modelling rule is zero to one (0.1); inversely, a
property can be specialized by zero to many (0.*) more specific properties;
EXAMPLE 1 The property “length” can be used for generic use cases, and specialized later when the need to
refer to a specific reference standard applies.
e) may be dependent on other properties; the modelling rule is zero to many (.*) properties.
EXAMPLE 2 To calculate the U-value of a window, the thermal transmittance of the glass is needed.
There are three main kinds of dependencies where all three may be combined:
— context parameters;
— proxy properties;
— function dependencies.
Context parameters are connected properties where the value of the target properties describe the context
of the current property. Context parameters with multiple target properties can be additive or combinative.
Context parameters shall be used to provide context for properties with table values.
Proxy properties are connected properties where the value of one of the target properties shall be used
directly to represent the current property. The current property inherits the quantity kind and type of value
from the target property.
Function dependencies are connected properties where the values of the target properties serve as inputs
variables or parameters to a set of instructions where the value of the current property is the output.
The relationship may be defined as logical operations, algebraic functions or any other set of instructions
different from proxy properties. Function dependencies may be used to populate each table entry for a
property table value.
Table 1 provides definitions of different dependencies.
Table 1 — Definitions of property dependency relations
Dependency Definition
Additive context relationship to one or multiple target property(ies) where the current property value depends
parameters on the target property value(s), and where the current property value does not depend on com-
binations of any target property values
Combinative con- relationship to one or multiple target property(ies) where the current property value depends
text parameters on the target property value(s), and where the current property value depends on all possible
combinations of multiple target property values
Reference proxy relationship to one target property defined as the preferred proxy property in the presence of
property multiple proxy properties, and where the target property value is communicated as the current
property’s value
Alternative proxy relationship to multiple target properties where no single target property is preferred to the
properties other target properties of the relationship, and where one of the target property values is com-
municated as the current property’s value
Function depend- relationship to one or multiple target property(ies) where the current property value is found
ency following a set of instructions specified by the relationship and where the target property val-
ue(s) serve(s) as input variable(s) or parameter(s)
Where context parameters have own context parameters, parameters on the different levels shall be combined with a combinative
approach.
Where multiple context parameters are combined, the target properties of each relationship shall first be handled according to
the relationship definition, and then combined with a combinative approach.
EXAMPLE 3 Single additive or combinative context parameter: To declare the global warming potential (GWP) of a
product, it is necessary to also declare the life cycle stage (information module) to which the GWP belongs. See Table 2.
Table 2 — Single additive or combinative context parameter
Context parameter: Information module
Context parameter value: A1-A3 A4 A5 B1 … B7 C1 … C4 D
Current property: glob-
al warming potential
EXAMPLE 4 Additive context dependencies: The amount used of a given type of material in the maintenance, repair,
replacement and refurbishment stages for EPDs (B2–B5) is declared for each information module B2–B5, and modelled
as an additive context parameter where the target properties for each information module is independent on each
other. See Table 3.
Table 3 — Additive context parameters
Context parameters: Material type for Material type for Material type for Material type for
maintenance repair replacement refurbishment
Context parameter Paint Replacement window
values: unit (half unit)
Current property: mate- 0,55 kg 27,7 kg
rial amount (mass)
EXAMPLE 5 Combinative context dependencies: Compressive strength of cement can be modelled as being
dependent on the age of the test specimen combined with a dependency on a property specifying if the lower limit,
average or upper limit measurement is declared. See Table 4.
Table 4 — Combinative context parameters
Current property: Compres- Context parameter 1: age of test specimen
sive strength
Upper limit
Target value
Lower limit
EXAMPLE 6 Proxy properties: Thermal transmittance for insulating glazing units are calculated according to
EN 673 (reference proxy) and, if and only if calculation is not possible, according to measurements according to EN 674
or EN 675 (alternative proxies).
EXAMPLE 7 Function dependencies: Classification of compressive strength for concrete requires the tested
compressive strength of a test specimen with age 28 days exceeds a certain limit value.
EXAMPLE 8 Function dependencies: The volume of a quadrilateral object is calculated as the product of the length
of the three dimensions.
5 ISO 12006-3 representation
5.1 General
ISO 12006-3 specifies a language-independent object-oriented information model which can be used for the
development of data dictionaries and implementation of data dictionary systems. The model in ISO 12006-3
is referred to as the meta level.
The ISO 12006-3 model includes many of the concepts in this document and in ISO 23386, but it lacks
definitions for the concepts data template, object type and group of properties. These three concepts are
used in data dictionaries and shall be modelled as kinds of xtdSubject.
The ISO 12006-3 model does not provide attributes intended to differentiate between different kinds of
xtdSubject on the dictionary level.
5.2 Definition of subject kinds
To identify the different kinds of subjects used in this document, a dictionary meta level is introduced. In data
dictionary implementations, dictionary meta level xtdSubjects shall be instantiated using the standardized
instances defined in Table 5. The dictionary meta level xtdSubject instances shall refer to this document as
the reference document, as exemplified in 5.6.
Table 5 defines the dictionary meta level subjects used to identify the kind of xtdSubject in and across data
dictionaries and data dictionary implementations.
Table 5 — Identification, naming and definition of dictionary meta level subjects
UUID Name Definition
f72aefe1-cb39-4af3-8455-2fd- Data template Kind of subject that can be assigned to an object type,
fe891734c and can contain other data templates, groups of prop-
erties and/or properties
b7b1cd0b-b515- 4252-a083- bb5d- Object type Kind of subject that can be composed of other object
dee073c8 types, but shall not contain data templates, group of
properties or properties
7c9ffe6e-3c8b-4cd2- b57b- Group of properties Kind of subject that contains properties and/or other
4cd102325603 groups of properties, but shall not contain data tem-
plates and shall not be assigned to an object type
Context
parameter 2:
type of test
result
A data template is a kind of subject that may be assigned to an object type, and may have other data
templates, groups of properties or properties. On the dictionary meta level, different kinds or specializations
of data templates may be defined. On the dictionary level, a data template may be a subtype of another data
template.
An object type is a kind of subject that may be composed of other object types, but shall not contain
data templates, groups of properties or properties itself. On the dictionary meta level, different kinds or
specializations of object types may be defined. On the dictionary level, an object type may be a subtype of
another object type.
A group of properties is a kind of subject that shall contain properties or other groups of properties. Groups
of properties shall not contain data templates or be assigned to object types. A property may be included in
multiple groups of properties, also within the same data template or within another group of properties. On
the dictionary meta level, different kinds or specializations of groups of properties may be defined. On the
dictionary level, a group of properties may be modelled as a subtype of another group of properties.
Where properties are organized into groups of properties in a data dictionary implementation to simplify
management of data dictionaries and data templates, inclusion of different groups of properties can lead to
duplicates of properties or groups of properties within one template. In such cases, duplicates of properties
or groups of properties shall be collapsed into a list of unique properties and groups of properties for the
specific template.
EXAMPLE 1 The property global trade item number (GTIN) for a product can be included in several groups of
properties within one data template. In a data sheet for the template or a subset of the data sheet based on any of the
template’s groups of properties, the GTIN has the same value.
Where one property or group of properties is included in multiple data templates combined to form a system
or composed data template, duplicates of properties across different data templates shall not be collapsed
into a list of unique properties.
EXAMPLE 2 The property net weight can be used in both the top-level data template for a ventilator fan and in
data templates for any of the fan parts. In a data sheet for the fan and all its parts, the net weight value is different
depending on which data template it belongs to.
For systems or composed objects, the structure of the data template may be different from the structure of
the object type.
EXAMPLE 3 A system data template for a wall system containing data templates for the different parts of the wall
can be assigned to a single object type representing the wall system.
EXAMPLE 4 A single data template for a heating system can be assigned to a system object type representing the
system comprising object types for the different parts of the system.
5.3 Specialization of dictionary meta level subject kinds
Further specialization of dictionary meta level subject kinds may be defined in other documents. Such
specialization should use the same approach as employed in this document, as illustrated in Figure 5.
Standardized specializations should be defined and provided the following information:
— a UUID according to ISO 12006-3;
— a name;
— a definition;
— a subject relationship in accordance with 5.4 to the relevant dictionary meta level subject kind defined in 5.2;
— a reference to the document defining the subject kind.
EXAMPLE 1 Groups of properties can be specialized to fulfil a specific purpose according to ISO 7817-1, compose
properties for essential characteristics in a declaration of performance and conformity, or a block according to
ISO 16757-1.
EXAMPLE 2 Data templates can be specialized to a single purpose template, a design specification data template
and an as-built data template.
The dictionary meta level subject kinds defined in this document shall not be treated as abstract if they are
specialized by dictionary meta level subject kinds defined in other documents.
Specializations defined in other documents shall not become abstract if they are further specialized.
A specialization with further specializations may be explicitly defined as abstract.
5.4 Subject relationships
Relationships between subjects shall be modelled on the dictionary level using instances of
xtdRelationshipToSubject. Each relationship shall be defined using instances of xtdRelationshipType,
following Table 6.
Generic relationships are modelled as schema kind relationships.
Partitive or associative relationships are modelled as instance kind relationships.
EXAMPLE 1 Generic relationships are generalizations such as ‘is kind of’, ‘subtype of’, ‘is a’.
EXAMPLE 2 Partitive relationships are such as ‘has parts’, ‘is composed of’, ‘aggregates’, ‘contains’.
Table 6 defines subject relationships used to relate dictionary level subjects to the correct dictionary meta
level subject and to each other.
Table 6 — Identification, naming and definition of xtdRelationshipType
UUID Name Definition Kind
36060129- fd10-4cd5- Is kind of Generic relationship assigning a dictionary XTD_SCHEMA_LEVEL
af0a- 48169d2a5464 level subject to its dictionary meta level
subject kind
e39fc112 - c1c9- 44b6- 9c Is subkind of Generic relationship relating a special- XTD_SCHEMA_LEVEL
16- e7225995be45 ized subject kind to its generic subject kind
4f9caab0- 8204-4c37- Is subtype of Generic relationship between two subjects XTD_SCHEMA_LEVEL
820e- b43d3edf92a5 of the same kind on the dictionary level,
where instantiation of the current subject
implies that the properties, relationship(s)
to other subjects etc. of the target subject
is inherited, and the target subject is not
instantiated itself
096ac5ac- fad3-4cda- Has parts Partitive relationship between dictionary XTD_INSTANCE_LEVEL
9587- ba10e774a576 level subjects of the same kind
2b83a349- ec94- 4815- 8a Has object Relationship from a data template to an XTD_INSTANCE_LEVEL
24- 9a219e55ac5f type object type
00caf69b- 8e2e-422a- Has group of Partitive relationship from a data template XTD_INSTANCE_LEVEL
a250- 361061a80d4c properties to a group of properties
EXAMPLE 3 In dictionary implementations referring to this document, the data templates for 'ready-mix concrete',
'concrete aggregate' and 'cement' are all related to the dictionary meta level subject data template defined in Table 5
using an ‘Is kind of’ relationship.
EXAMPLE 4 Specializations of group of properties made in other documents relate the dictionary meta level
specialization instances to the relevan
...
Norme
internationale
ISO 23387
Deuxième édition
Modélisation des informations de
2025-09
la construction (BIM) — Modèles
de données pour les objets utilisés
durant le cycle de vie des biens
Building information modelling (BIM) — Data templates for
objects used in the life cycle of assets
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2025
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Structure du modèle de données . 3
4.1 Généralités .3
4.2 Représentation UML d’une structure de modèle de données .4
4.3 Utilisation des URI pour le modèle de données de l’ISO 23887 .5
4.4 Modélisation des données .5
4.4.1 Généralités .5
4.4.2 Document de référence .6
4.4.3 Type d’objet .6
4.4.4 Modèle de données .6
4.4.5 Groupe de propriétés .7
4.4.6 Propriété .7
5 Représentation selon l’ISO 12006-3 . 9
5.1 Généralités .9
5.2 Définition des types de sujets .10
5.3 Spécialisation des types de sujets du métaniveau du dictionnaire .11
5.4 Relations entre sujets .11
5.5 Relations entre propriétés . 13
5.6 Représentation des modèles de données conformément à l’ISO 12006-3 . 13
6 Représentations XML . 16
Annexe A (informative) Exemples, cas d’utilisation et implémentations . 17
Annexe B (informative) Création de modèles de données .27
Annexe C (informative) Attributs des concepts des modèles de données avec exemples .29
Annexe D (informative) Cas d’instanciation correcte de la relation subtypeOf (sous-type de) .33
Annexe E (informative) Représentation XSD .34
Annexe F (informative) Exemple XML .36
Bibliographie .37
iii
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes nationaux
de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est en général
confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude a le droit de faire
partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l’ISO participent également aux travaux. L’ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document
a été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2
(voir www.iso.org/directives).
L’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation
d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à l’applicabilité de
tout droit de brevet revendiqué à cet égard. À la date de publication du présent document, l’ISO n’avait pas reçu
notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois, il y a lieu
d’avertir les responsables de la mise en application du présent document que des informations plus récentes
sont susceptibles de figurer dans la base de données de brevets, disponible à l’adresse www.iso.org/brevets.
L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié de tels droits de brevet.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l’ISO liés à l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de
l’ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir http://www.iso.org/iso/foreword.html.
Le présent document a été élaboré par le comité technique ISO/TC 59, Bâtiments et ouvrages de génie civil,
sous-comité SC 13, Organisation et numérisation des informations relatives aux bâtiments et ouvrages de
génie civil, y compris modélisation des informations de la construction (BIM), en collaboration avec le comité
technique CEN/TC 442, Modélisation des informations de la construction (BIM) du Comité européen de
normalisation (CEN), conformément à l’Accord de coopération technique entre l’ISO et le CEN (Accord de
Vienne).
Cette deuxième édition annule et remplace la première édition (ISO 23387:2020), qui a fait l’objet d’une
révision technique.
Les principales modifications sont les suivantes:
— le modèle de données a été harmonisé avec l’ISO 12006-3:2022;
— une définition de schéma XML a été fournie.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/fr/members.html.
iv
Introduction
La modélisation des informations de la construction (BIM, Building Information Modelling) propose un
processus numérique permettant de décrire et de présenter les informations exigées lors de la planification,
la conception, la réalisation et l’exploitation de biens. Cette approche englobe tous les aspects de
l’environnement bâti, y compris les infrastructures civiles, les services publics et l’espace public.
La série ISO 19650 spécifie les concepts et les principes des processus métiers mis en œuvre dans le secteur
du cadre bâti en soutien de la gestion et de la production d’informations pendant le cycle de vie des biens,
en utilisant la modélisation des informations de la construction (BIM). Pour prendre en charge la gestion et
la production d’informations dans ces processus métier, la normalisation est de la plus haute importance.
Des données interprétables par machine sont essentielles pour fournir un échange d’informations fiable et
durable dans le processus de cycle de vie d’un bien.
Les modèles de données fournissent une structure de données normalisée pour décrire les caractéristiques
des objets, permettant des échanges d’informations transparents sur la sémantique métier du secteur de la
construction tout au long du cycle de vie des biens.
Le présent document permet de normaliser les modèles de données et de les mettre à la disposition du
secteur du cadre bâti, et le cas échéant, par le biais de dictionnaires de données basés sur l’ISO 12006-3.
Les modèles de données peuvent être utilisés conjointement avec les classes de fondation d’industrie (IFC)
dans l’ISO 16739-1.
Les publics cibles du présent document sont:
— les développeurs de logiciels, afin d’intégrer la structure des données dans un logiciel, une plateforme, etc.;
— les experts du domaine du secteur du cadre bâti nommés pour créer des modèles de données basés sur
des sources décrivant les besoins d’information;
— les professionnels du secteur, car ils fournissent la demande, l’utilisation des données et des processus, etc.;
— les autorités, au fur et à mesure qu’elles examinent et vérifient toutes les soumissions pertinentes;
— les membres de services de recherche et développement, car ils soutiennent l’innovation et le
développement continu des modèles de données;
— les établissements d’enseignement, car il convient de fusionner le concept de modèles de données, comme
le BIM, et les principes de l’information numérique dans les programmes d’éducation et de formation;
— les promoteurs immobiliers (propriétaires de biens), car ils ont besoin d’une vision plus claire du modèle
de données, c’est pourquoi ils l’incluent dans les documents d’appel d’offres.
v
Norme internationale ISO 23387:2025(fr)
Modélisation des informations de la construction (BIM) —
Modèles de données pour les objets utilisés durant le cycle de
vie des biens
1 Domaine d’application
Le présent document décrit le concept de modèles de données conçu pour permettre une interprétation par
machine basée sur une structure de données normalisée, contenant les informations alphanumériques pour
tout objet utilisé dans le cycle de vie des biens.
Le présent document décrit la manière dont les modèles de données sont mis en œuvre conformément à
l’ISO 12006-3.
Le présent document fournit une méthodologie pour la création et la gestion de modèles de données dans
des dictionnaires de données.
Le présent document donne des recommandations pour la liaison entre les modèles de données et les
systèmes de classification dans les dictionnaires de données, sur la base de l’ISO 12006-3.
Le présent document fournit une définition de schéma XML (XSD) représentant une mise en œuvre des
modèles de données de l’ISO 23387 et de l’ISO 12006-3.
La fourniture du contenu des modèles de données ne relève pas du domaine d’application du présent
document.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique. Pour
les références non datées, la dernière édition du document de référence s’applique (y compris les éventuels
amendements).
ISO 23386, Modélisation des informations de la construction et autres processus numériques utilisés en
construction — Méthodologie de description, de création et de gestion des propriétés dans les dictionnaires de
données interconnectés
ISO 12006-3, Construction immobilière — Organisation de l'information des travaux de construction — Partie
3: Schéma pour l'information basée sur l'objet
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1
dictionnaire de données
base de données contenant des métadonnées
[SOURCE: ISO/IEC 2382:2015, 2121501, modifié — Le terme admis «dictionnaire de ressources
d'information» a été supprimé; les notes à l’article ont été supprimées.]
3.2
modèle de données
structure de données utilisée pour décrire les caractéristiques des objets (3.4)
EXEMPLE 1 Un modèle de données offre une vue adaptée à un besoin d’information spécifique. Par exemple,
le concepteur d’un système (3.11) de chauffage, ventilation et climatisation (CVC) peut exiger les descriptions des
produits de CVC qui peuvent être importés dans un outil de conception.
EXEMPLE 2 Un modèle de données fournit aux fabricants une structure de données normalisée qui peut être
appliquée à tout système ou processus interne, ou les deux, de gestion des données de produit. Par exemple, un ou
plusieurs systèmes de gestion d’informations produit peuvent utiliser ou être mappés à cette structure pour permettre
une interprétation par machine, à la fois en interne et en cas de demande provenant d’un quelconque logiciel utilisant
la même structure de modèle de données. Un fabricant de produits de CVC peut alors répondre à la demande de toute
partie prenante y compris le concepteur du système centralisé.
Note 1 à l'article: Le domaine d’application concerné du modèle de données peut être utilisé conjointement avec le
terme «modèle de données». Par exemple, un modèle de données pour un produit (3.8) peut être nommé «modèle de
données de produit»; un modèle de données pour un système peut être nommé «modèle de données de système».
Note 2 à l'article: Un modèle de données peut être utilisé dans un échange d’informations dans un but spécifique pour
un type d’objet (3.5) lors du démarrage, de l’avant-projet, de la conception, de la production, de la mise en service et de
la démolition des biens.
3.3
feuille de données
saisie de données conformément à un modèle de données (3.2), qui représente un produit (3.8), un bien ou
une exigence du monde réel
EXEMPLE 1 Un produit utilisant la propriété (3.9) «transmission thermique» avec l’unité W/(m ⋅K) est de valeur 0,9.
EXEMPLE 2 Une exigence utilisant la propriété «hauteur» avec l’unité mm est de valeur 600.
3.4
objet
toute partie du monde qu’il est possible de percevoir ou de concevoir
EXEMPLE Instance d’un type d’objet (3.5) «élément de maçonnerie en silicate de calcium».
Note 1 à l'article: Un objet peut représenter un objet de conception, un produit (3.8) intermédiaire, un produit fini,
un outil ou un équipement de finition, un système (3.11), un ensemble, un espace, un bâtiment, etc.
[SOURCE: ISO 12006-2:2015, 3.1.1, modifié — La Note 1 à l’article d’origine a été remplacée par une nouvelle
note, l’EXEMPLE a été ajouté.]
3.5
type d’objet
représentation d’objets (3.4) qui partagent des caractéristiques communes
Note 1 à l'article: Le rôle du type d’objet est de classer le modèle de données (3.2).
3.6
groupe de propriétés
collection de propriétés (3.9) permettant de les pré-arranger ou de les organiser
[SOURCE: ISO 23386:2020, 3.14, modifié — La définition a été mise à jour pour préciser que la collection
concerne les propriétés; les notes à l’article ont été supprimées.]
3.7
données interprétables par machine
données disponibles dans un contexte et un format spécifiques qui peuvent être lues et stockées dans un
système (3.11) informatique de sorte à pouvoir prendre des mesures en fonction du contenu de ces données
[SOURCE: ISO 10303-232:2002, 3.5.3, modifié — Le terme privilégié «données interprétables par ordinateur»
a été remplacé par «données interprétables par machine». L’EXEMPLE a été supprimé.]
3.8
produit
tout article fabriqué ou conçu pour être incorporé dans des ouvrages de construction
[SOURCE: ISO 6707-1:2020, 3.4.1.2, modifié — Le terme privilégié «produit de construction» a été supprimé;
la Note 1 à l’article a été supprimée.]
3.9
propriété
caractéristique définie adaptée pour la description et la différentiation d’un objet (3.4)
EXEMPLE Longueur conformément à l’EN 12058, indice de réduction sonore conformément à l’ISO 10140-4.
Note 1 à l'article: Lorsqu’une propriété est nommée conjointement en référence à une spécification technique dans
laquelle les instructions permettant d’évaluer la performance (généralement des normes) sont disponibles, elle doit
être considérée comme une propriété spécifique. La relation entre la propriété et la propriété spécifique est modélisée
comme relation parent-enfant.
[SOURCE: ISO 22274:2013, 3.25, modifié — Les mots «des objets d’une classe» ont été remplacés par
«d’un objet»; l’EXEMPLE a été remplacé; la Note 1 à l’article a été ajoutée.]
3.10
document de référence
publication qui est consultée pour trouver une information précise, en particulier dans un domaine
technique ou scientifique
EXEMPLE EN 771-1:2011+A1:2015.
Note 1 à l'article: Un document de référence peut être associé à toute donnée présente dans un dictionnaire de données (3.1).
[SOURCE: ISO 23386:2020, 3.18, modifié — L’EXEMPLE a été ajouté.]
3.11
système
agencement de parties ou d’éléments qui, ensemble, présentent un comportement ou un sens déterminé que
les constituants individuels n’ont pas
EXEMPLE L’objet «mur» qui est composé de parties, est un système.
[SOURCE: ISO/IEC IEEE 15288:2023, 3.46, modifié — L’EXEMPLE a été ajouté; les Notes 1 à 3 à l’article ont
été supprimées.]
4 Structure du modèle de données
4.1 Généralités
L’objectif des modèles de données est de proposer un moyen courant d’échange de données d’objets.
Par conséquent, tous les modèles de données suivent la même structure générale de données (métamodèle).
Un modèle de données est destiné à fournir une structure normalisée pour une livraison d’informations
prédéfinie, une feuille de données, pour un type d’objet, pour un cas d’utilisation spécifique ou toute autre
finalité.
La structure du modèle de données comprend les concepts de type d’objet, de modèle de données,
de propriété, de document de référence et de groupe de propriétés. Les grandeurs, unités et valeurs sont des
attributs des propriétés, conformément à l’ISO 12006-3, et ne sont donc pas modélisées en tant que concepts
distincts dans le modèle UML de la Figure 1.
Le cas échéant, le modèle de données a une relation avec un type d’objet. Selon l’objectif de l’échange
d’informations, il est possible de créer plusieurs modèles de données pour un type d’objet, ayant des
propriétés communes ou distinctes.
Les modèles de données et les groupes de propriétés peuvent être utilisés pour fournir une livraison
d’informations prédéfinie. Par exemple, les propriétés géométriques «largeur», «longueur» et «hauteur»
peuvent être rassemblées sous le groupe de propriétés «dimensions». Le concept à utiliser dépend de
l’objectif de la livraison d’informations et du comportement prévu de la feuille de données.
Tous les concepts d’un modèle de données peuvent avoir une relation avec un document externe tel qu’une
norme, une spécification technique, un rapport, une ligne directrice ou similaire. Le document de référence
fournit la définition de l’élément conceptuel. Il existe quelques autres relations qui sont illustrées à la
Figure 1.
Les types d’objets, les modèles de données, les propriétés, les groupes de propriétés et les documents
de référence sont tous des concepts qui sont créés, gérés et stockés dans un dictionnaire de données.
L’implémentation des dictionnaires de données doit être basée sur l’ISO 12006-3. Tous les concepts du
présent document doivent être créés en suivant les règles de gestion pour créer et gérer des propriétés et
des groupes de propriétés tels que définis dans l’ISO 23386. La gouvernance des dictionnaires de données
évite les doubles emplois, tout en fournissant des définitions claires de tous les concepts dans les modèles de
données.
Comme l’ISO 12006-3 prend en charge les interconnexions entre des dictionnaires de données, un modèle de
données peut utiliser des concepts en conséquence. Par conséquent, un modèle de données peut être composé
de concepts provenant de différents dictionnaires de données. Cette situation est illustrée à l’Article A.1.
Un modèle de données s’applique à la fois aux types d’objets simples et aux systèmes ou compositions de types
d’objets. Par exemple, un modèle de données s’applique à une fenêtre en tant que type d’objet unique, mais
aussi à une fenêtre et ses composants. Il s’applique également à un système intégrant la fenêtre, comme un
système de mur extérieur. Un exemple de système de mur avec des composants est donné à l’Article A.4.
Un modèle de données s’applique aux types d’objets représentant n’importe quelle partie du cycle de vie
de l’objet, de la conception initiale à la spécification, et pour les objets physiques (produits ou système de
produits). Le cas échéant, il convient de réutiliser les définitions de types d’objets et de propriétés tout au
long du cycle de vie de l’objet.
4.2 Représentation UML d’une structure de modèle de données
La représentation du modèle de données à la Figure 1 utilise le langage de modélisation unifié (UML).
La Figure 1 fournit des règles de modélisation pour les concepts et leurs relations. En plus des relations
UML, des noms leur sont ajoutés pour fournir la sémantique des relations, correspondant à l’ISO 12006-3,
expliquée dans le Tableau 3.
Figure 1 — Représentation UML d’une structure de modèle de données
4.3 Utilisation des URI pour le modèle de données de l’ISO 23887
Le présent document introduit un attribut supplémentaire applicable à tous les concepts d’un modèle de
données, l’URI, qui peut être utilisé avec l’UUID qui est obligatoire dans l’ISO 12006-3. Les UUID peuvent
être intégrés aux URI le cas échéant, mais ce n’est pas obligatoire, en particulier lorsque les URI peuvent
inclure des informations conviviales.
Les UUID sont principalement destinés aux références internes dans un dictionnaire de données,
assurant une identification unique et cohérente. Bien que les UUID puissent servir de références externes
dans les scénarios où la définition d’URI n’est pas pratique, cette approche n’est pas recommandée. Les URI
sont généralement préférés pour les références externes en raison de leur flexibilité et de leur capacité à
transmettre des informations significatives. Par conséquent, il convient, dans la mesure du possible,
de prioriser les URI pour le référencement externe.
4.4 Modélisation des données
4.4.1 Généralités
La structure du modèle de données se compose d’un modèle de données qui a un type d’objet, des propriétés
et des groupes de propriétés, avec des documents de référence fournissant la source de chacun des concepts.
Un modèle de données est modélisé dans le contexte d’un type d’objet afin de fournir une livraison
d’informations prédéfinie.
Un type d’objet peut être affecté à plusieurs modèles de données. Chaque modèle de données peut contenir
une ou plusieurs propriétés, et dans chaque modèle de données, les propriétés peuvent être collectées dans
différents groupes de propriétés.
Les règles de modélisation de la structure du modèle de données avec ses concepts s’appliquent dans le
contexte d’un seul modèle de données. Les règles de modélisation de la Figure 1 sont décrites en 4.4.2 à 4.4.6.
L’Annexe A fournit des exemples d’approches possibles de modélisation des données, ainsi que des cas
d’utilisation et des exemples.
L’Annexe B fournit un flux de travail possible pour la création de modèles de données.
L’Annexe C fournit des exemples d’attributs de concepts de modèles de données.
4.4.2 Document de référence
Un document de référence peut être associé à plusieurs types d’objets, modèles de données, groupes de
propriétés et propriétés. Par conséquent, les règles de modélisation des modèles de données, groupes de
propriétés et propriétés sont de type zéro à plusieurs (0.*).
4.4.3 Type d’objet
Le type d’objet:
a) il convient idéalement de le définir sur la base d’une norme (norme terminologique, norme technique,
etc.); toutefois, cela n’est pas obligatoire car un type d’objet peut être défini dans d’autres sources que des
normes; le type d’objet peut être défini dans plusieurs documents de référence; la règle de modélisation
est de zéro à plusieurs (0.*) documents de référence;
b) a besoin d’un modèle de données pour lui associer des propriétés; un type d’objet peut appartenir à
plusieurs modèles de données; la règle de modélisation est d’un à plusieurs (1.*) modèles de données;
EXEMPLE 1 Un type d’objet peut appartenir à plusieurs modèles de données lorsqu’il fait partie d’un système.
Un exemple plus détaillé est fourni à la Figure A.5.
c) peut être composé (relation partitive) d’autres types d’objets; la règle de modélisation est de zéro à
plusieurs (0.*) types d’objets;
EXEMPLE 2 Un mur est composé de couches de produits.
d) peut faire partie de la composition d’un autre type d’objet; dans le contexte d’un type d’objet, il peut
s’agir au maximum d’un type d’objet; la règle de modélisation est de zéro à un (0.1) type d’objet.
4.4.4 Modèle de données
Le modèle de données:
a) définit une livraison d’informations complète et unique dans un contexte donné ou avec un objectif
spécifique;
b) possède une liste de propriétés uniques; la règle de modélisation est de zéro à plusieurs (0.*) propriétés;
EXEMPLE 1 Une spécification de conception est un modèle de données.
EXEMPLE 2 Un bon de livraison est un modèle de données.
c) peut avoir des groupes de propriétés pour permettre la catégorisation des propriétés dans le modèle de
données afin de fournir des sous-ensembles des propriétés du modèle, de satisfaire à une ou des parties
de l’objectif global du modèle de données ou de satisfaire tout autre besoin d’information spécifique,
la règle de modélisation étant de zéro à plusieurs (0.*) groupes de propriétés;
d) peut être associé à un type d’objet, la règle de modélisation étant de zéro à un (0.1) type d’objet;
e) peut être basé sur un ou plusieurs documents de référence, la règle de modélisation étant de zéro à
plusieurs (0.*) documents de référence;
EXEMPLE 3 Un document de référence pour un modèle peut être une norme de conception ou de produit, ou
une autre spécification technique.
f) peut être composé (relation partitive) d’autres concepts de modèle de données; la règle de modélisation
est de zéro à plusieurs (0.*) modèles de données;
EXEMPLE 4 Un modèle de données peut être composé d’autres modèles de données, par exemple lorsqu’un
mur est composé de couches de matériaux ou de produits. Un exemple est donné à la Figure A.5.
g) peut faire partie de la composition d’un autre concept de modèle de données; dans le contexte d’un modèle
de données, il peut s’agir au maximum d’un concept de modèle de données; la règle de modélisation est
de zéro à un (0.1) concept de modèle de données.
4.4.5 Groupe de propriétés
Le groupe de propriétés:
a) définit un contexte ou un objectif commun pour une collection de propriétés;
EXEMPLE 1 Les propriétés d’un même modèle de données pertinentes pour différents domaines ou
destinataires, telles que les propriétés techniques, financières et environnementales, peuvent être collectées
dans différents groupes de propriétés en fonction du domaine.
EXEMPLE 2 Dans une feuille de données, les propriétés nécessaires à différents moments ou étapes d’un
processus de construction peuvent être collectées par groupes de propriétés si les valeurs des propriétés restent
constantes dans le temps ou d’une étape à l’autre.
b) doit avoir au minimum une propriété, la règle de modélisation étant d’une à plusieurs (1.*) propriétés;
c) doit être associé à un modèle de données et peut être associé à plusieurs modèles de données; la règle de
modélisation est d’un à plusieurs (1.*) modèles de données;
d) peut être basée sur un ou plusieurs documents de référence, par exemple une norme de conception ou
de produit, ou une autre spécification technique; la règle de modélisation est de zéro à plusieurs (0.*)
documents de référence;
e) peut être composé (relation partitive) d’autres groupes de propriétés, la règle de modélisation étant de
zéro à plusieurs (0.*) groupes de propriétés;
f) peut au maximum faire partie d’un groupe de propriétés, dans le contexte d’un groupe de propriétés;
la règle de modélisation est de type zéro à un (0.1) groupe de propriétés.
4.4.6 Propriété
Une propriété:
a) peut être basée sur un document de référence; la règle de modélisation est de zéro à plusieurs (0.*)
documents de référence;
b) doit être associée à un modèle de données; la règle de modélisation est d’un à plusieurs (1.*) modèles de
données;
c) peut être regroupée en un groupe de propriétés; la règle de modélisation est de zéro à plusieurs (0.*)
groupes de propriétés;
d) peut être spécialisée; lorsqu’une propriété est une spécialisation d’une autre propriété plus générique,
la valeur de la propriété de spécialisation doit être une valeur valide de la propriété cible; lorsqu’une
propriété est définie comme la spécialisation d’une autre propriété plus générique, la règle de
modélisation est de zéro à un (0.1); inversement, une propriété peut être spécialisée par zéro à plusieurs
(0.*) propriétés plus spécifiques;
EXEMPLE 1 La propriété «longueur» peut être utilisée pour des cas d’utilisation génériques, et spécialisée
ensuite lorsque la nécessité de se référer à une norme de référence spécifique s’applique.
e) peut dépendre d’autres propriétés; la règle de modélisation est de zéro à plusieurs (0.*) propriétés;
EXEMPLE 2 Pour calculer le coefficient U d’une fenêtre, la transmission thermique du verre est nécessaire.
Il existe trois principaux types de dépendances, les trois pouvant être combinés:
— les paramètres de contexte;
— les propriétés de proxy;
— les dépendances de fonction.
Les paramètres de contexte sont des propriétés connectées où la valeur des propriétés cibles décrit le
contexte de la propriété actuelle. Les paramètres de contexte avec plusieurs propriétés cibles peuvent être
additifs ou combinatoires. Les paramètres de contexte doivent être utilisés pour fournir un contexte aux
propriétés ayant des valeurs de tableau.
Les propriétés de proxy sont des propriétés connectées où la valeur de l’une des propriétés cibles doit être
utilisée directement pour représenter la propriété actuelle. La propriété actuelle hérite du type de grandeur
et du type de valeur de la propriété cible.
Les dépendances de fonction sont des propriétés connectées où les valeurs des propriétés cibles servent de
variables ou de paramètres d’entrée à un ensemble d’instructions dont la sortie est la valeur de la propriété
actuelle. La relation peut être définie comme des opérations logiques, des fonctions algébriques ou tout
autre ensemble d’instructions différent des propriétés de proxy. Les dépendances de fonction peuvent être
utilisées pour remplir chaque entrée de tableau pour une propriété ayant des valeurs de tableau.
Le Tableau 1 donne les définitions des différentes dépendances.
Tableau 1 — Définitions des relations de dépendance des propriétés
Dépendance Définition
Paramètres de relation avec une ou plusieurs propriétés cibles, où la valeur de la propriété actuelle dépend de
contexte additifs la valeur de la ou des propriétés cibles, et où la valeur de la propriété actuelle ne dépend pas de
combinaisons de valeurs de propriétés cibles
Paramètres de relation avec une ou plusieurs propriétés cibles, où la valeur de la propriété actuelle dépend de la
contexte combi- valeur de la ou des propriétés cibles, et où la valeur de la propriété actuelle dépend de toutes les
natoires combinaisons possibles de plusieurs valeurs de propriétés cibles
Propriété de relation avec une propriété cible définie comme la propriété de proxy privilégiée en présence de
proxy de réfé- plusieurs propriétés de proxy, et où la valeur de la propriété cible est communiquée comme valeur
rence de la propriété actuelle
Propriétés de relation avec plusieurs propriétés cibles où aucune propriété cible unique n’est préférée aux
proxy alterna- autres propriétés cibles de la relation, et où une des valeurs des propriétés cibles est communi-
tives quée comme valeur de la propriété actuelle
Dépendance de relation avec une ou plusieurs propriétés cibles où la valeur de la propriété actuelle est détermi-
fonction née à la suite d’un ensemble d’instructions spécifiées par la relation et où la ou les valeurs de la ou
des propriétés cibles servent de variables ou de paramètres d’entrée
Lorsque les paramètres de contexte ont leurs propres paramètres contexte, les paramètres aux différents niveaux doivent être
combinés avec une approche combinatoire.
Lorsque plusieurs paramètres de contexte sont combinés, les propriétés cibles de chaque relation doivent d’abord être traitées
conformément à la définition de la relation, puis combinées avec une approche combinatoire.
EXEMPLE 3 Paramètre de contexte additif ou combinatoire unique: pour déclarer le potentiel de réchauffement
global (PRG) d’un produit, il est nécessaire de déclarer également l’étape du cycle de vie (module d’informations) à
laquelle le PRG appartient. Voir le Tableau 2.
Tableau 2 — Paramètre de contexte additif ou combinatoire unique
Paramètre de contexte: Module d’informations
Valeur du paramètre de contexte: A1-A3 A4 A5 B1 . B7 C1 . C4 D
Potentiel de réchauffement global
de la propriété actuelle
EXEMPLE 4 Dépendances de contexte additives: la quantité utilisée d’un type donné de matériau dans les phases de
maintenance, de réparation, de remplacement et de réhabilitation des DEP (B2–B5) est déclarée pour chaque module
d’informations B2–B5, et modélisée en tant que paramètre de contexte additif dans lequel les propriétés cibles de
chaque module d’informations sont indépendantes les unes des autres. Voir le Tableau 3.
Tableau 3 — Paramètres de contexte additifs
Paramètres de contexte: Type de matériau Type de matériau Type de matériau pour Type de matériau
pour la mainte- pour la réparation le remplacement pour la réhabili-
nance tation
Valeurs des paramètres de Peinture Remplacement du bloc
contexte: fenêtre (demi-bloc)
Propriété actuelle: quantité 0,55 kg 27,7 kg
de matériau (masse)
EXEMPLE 5 Dépendances de contexte combinatoires: la résistance à la compression du ciment peut être modélisée
comme étant dépendante de l’âge de l’éprouvette, combiné à une dépendance vis-à-vis d’une propriété spécifiant si la
mesure de la limite inférieure, de la limite moyenne ou de la limite supérieure est déclarée. Voir le Tableau 4.
Tableau 4 — Paramètres de contexte combinatoires
Propriété actuelle: Résis- Paramètre de contexte 1: Âge de l’éprouvette
tance à la compression
Limite supérieure
Valeur cible
Limite inférieure
EXEMPLE 6 Propriétés de proxy: la transmission thermique des vitrages isolants est calculée conformément à
l’EN 673 (proxy de référence) et, si et seulement si le calcul n’est pas possible, conformément aux mesurages selon
l’EN 674 ou l’EN 675 (proxys alternatifs).
EXEMPLE 7 Dépendances de fonction: la classification de la résistance à la compression du béton exige que la
résistance à la compression d’une éprouvette soumise à essai à l’âge de 28 jours dépasse une certaine valeur limite.
EXEMPLE 8 Dépendances de fonction: le volume d’un objet quadrilatéral est calculé comme le produit de la
longueur des trois dimensions.
5 Représentation selon l’ISO 12006-3
5.1 Généralités
L’ISO 12006-3 spécifie un modèle d’information indépendant de la langue et orienté sur l’objet qui peut être
utilisé pour la conception de dictionnaires de données et l’implémentation de systèmes de dictionnaires de
données. Le modèle de l’ISO 12006-3 est appelé le métaniveau.
Le modèle de l’ISO 12006-3 inclut de nombreux concepts du présent document et de l’ISO 23386, mais il
manque de définitions pour les concepts de modèle de données, de type d’objet et de groupe de propriétés.
Ces trois concepts sont utilisés dans les dictionnaires de données et doivent être modélisés sous forme de
types de sujets xtdSubject.
Paramètre
de contexte
2: type de
résultat
d’essai
Le modèle de l’ISO 12006-3 ne fournit pas d’attributs destinés à différencier les différents types de sujets
xtdSubject au niveau du dictionnaire.
5.2 Définition des types de sujets
Pour identifier les différents types de sujets utilisés dans le présent document, un métaniveau du
dictionnaire est introduit. Dans les implémentations de dictionnaires de données, les sujets xtdSubjects du
métaniveau du dictionnaire doivent être instanciés en utilisant les instances normalisées définies dans le
Tableau 5. Les instances xtdSubject du métaniveau du dictionnaire doivent renvoyer au présent document
comme document de référence, comme illustré en 5.6.
Le Tableau 5 définit les sujets du métaniveau du dictionnaire utilisés pour identifier le type de sujet
xtdSubject dans et entre les dictionnaires de données et les implémentations de dictionnaire de données.
Tableau 5 — Identification, dénomination et définition des sujets du métaniveau du dictionnaire
UUID Nom Définition
f72aefe1-cb39-4af3-8455-2fdfe891734c Modèle de Type de sujet pouvant être affecté à un type d’objet
données et pouvant contenir d’autres modèles de données,
groupes de propriétés et/ou propriétés
b7b1cd0b-b515- 4252-a083- bb5ddee073c8 Type d’objet Type de sujet qui peut être composé d’autres types
d’objets, mais qui ne doit pas contenir de modèles de
données, de groupes de propriétés ou de propriétés
7c9ffe6e-3c8b-4cd2- b57b-4cd102325603 Groupe de Type de sujet qui contient des propriétés et/ou d’autres
propriétés groupes de propriétés, mais ne doit pas contenir de
modèles de données et ne doit pas être affecté à un type
d’objet
Un modèle de données est un type de sujet qui peut être affecté à un type d’objet et peut avoir d’autres
modèles de données, groupes de propriétés ou propriétés. Au métaniveau du dictionnaire, différents types
ou spécialisations de modèles de données peuvent être définis. Au niveau du dictionnaire, un modèle de
données peut être un sous-type d’un autre modèle de données.
Un type d’objet est un type de sujet peut être composé d’autres types d’objets, mais qui ne doit pas contenir
de modèles de données, de groupes de propriétés ou de propriétés. Au métaniveau du dictionnaire, différents
types ou spécialisations de types d’objets peuvent être définis. Au niveau du dictionnaire, un type d’objet
peut être un sous-type d’un autre type d’objet.
Un groupe de propriétés est un type de sujet qui doit contenir des propriétés ou d’autres groupes de
propriétés. Les groupes de propriétés ne doivent pas contenir de modèles de données ni être affectés à des
types d’objets. Une propriété peut être incluse dans plusieurs groupes de propriétés, également dans le
même modèle de données ou dans un autre groupe de propriétés. Au métaniveau du dictionnaire, différents
types ou spécialisations de groupes de propriétés peuvent être définis. Au niveau du dictionnaire, un groupe
de propriétés peut être modélisé comme un sous-type d’un autre groupe de propriétés.
Lorsque les propriétés sont organisées en groupes de propriétés dans une implémentation de dictionnaires
de données afin de simplifier la gestion des dictionnaires de données et des modèles de données, l’inclusion
de différents groupes de propriétés peut conduire à des doublons de propriétés ou de groupes de propriétés
dans un même modèle. Dans ce cas, les doublons de propriétés ou de groupes de propriétés doivent être
regroupés dans une liste de propriétés et de groupes de propriétés uniques pour le modèle spécifique.
EXEMPLE 1 Le GTIN (Property Global Trade Item Number) d’un produit peut être inclus dans plusieur
...
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...