ISO 29481-3:2022
(Main)Building information models — Information delivery manual — Part 3: Data schema
Building information models — Information delivery manual — Part 3: Data schema
This document is the technical addition to the methodology set out in ISO 29481-1. It defines a specification to store, exchange and read information delivery manual (IDM) specifications in a standardized and machine-readable way.
Modèles des informations de la construction — Protocole d’échange d’informations — Partie 3: Schéma de données
Le présent document est le complément technique de la méthodologie exposée dans l’ISO 29481‑1. Il définit une spécification pour le stockage, l’échange et la lecture des spécifications du protocole d’échange d’informations (IDM) sous une forme normalisée et lisible par un ordinateur.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 29481-3
First edition
2022-09
Building information models —
Information delivery manual —
Part 3:
Data schema
Modèles des informations de la construction — Protocole d’échange
d’informations —
Partie 3: Schéma de données
Reference number
© ISO 2022
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 .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Overview of the IDM schema . 2
4.1 Naming convention . 2
4.2 Restriction notation . 2
4.3 Overall structure of the IDM schema. 3
5 Information delivery manual .5
6 Specification identifier (specId) . .6
7 Authoring . 7
7.1 General . 7
7.2 Change log . 9
7.3 Author . 9
7.4 Committee . 10
7.5 Publisher . 10
8 Use case .11
8.1 General . 11
8.2 Summary . 13
8.3 Aim and scope . 13
8.4 Use . 13
8.5 Standard project phase .13
8.6 Local project phase . 14
8.7 Region . 14
8.8 Construction entity . 15
8.9 Business rule . 15
8.10 Actor . 16
8.11 Benefits . 16
8.12 Limitations . 16
8.13 Required resources . 16
8.14 Required competencies . 17
8.15 Reference . 17
8.16 User-defined property . 17
8.17 Classification . 18
8.18 Outcomes . 18
8.19 Information requirements . 18
8.20 Description . 19
8.21 Image . 19
9 Business context map .19
9.1 General . 19
9.2 Process map . 21
9.2.1 General . 21
9.2.2 Data object and ER . 21
9.3 Interaction map . 21
9.3.1 General . 21
9.3.2 Transaction map . 21
9.4 Diagram . 22
10 Exchange requirement .22
10.1 General .22
iii
10.2 Information unit . 24
10.2.1 General . 24
10.2.2 Examples . 25
10.2.3 Corresponding external element . 25
10.3 Constraint . 25
10.4 Corresponding MVD .26
11 IDM code generation rules.26
Annex A (informative) The idmXML schema definition (idmXSD).28
Annex B (informative) IDM specification stages .29
Bibliography .30
iv
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).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
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 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).
A list of all parts in the ISO 29481 series can be found on the ISO website.
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.
v
Introduction
This document specifies a machine applicable, readable and transferable (SMART) data schema for the
efficient development, management and reuse of information delivery manual (IDM) specifications
based on ISO 29481-1. ISO 29481-1 sets out a methodology for describing the processes and information
requirements for a defined purpose within the development or management of an asset. In the absence
of a standard data schema for exchanging and sharing the contents of IDMs in an electronic format, IDM
specifications have historically been developed as either a static document file or as a data file specified
in a proprietary data format. Consequently, their contents cannot be efficiently exchanged, shared
and reused. The goal of this document is to define a standard data schema in order to expedite the
development and sharing of the IDM specifications to meet the rapidly increasing demand for various
building information modelling (BIM) use cases (UCs).
Using extensible markup language (XML), this document specifies a data schema for authoring,
exchanging and sharing an IDM specification defined by ISO 29481-1. The data schema is referred to as
the idmXML schema definition (idmXSD). idmXSD aims to allow users to electronically store, search,
share, exchange and reuse IDM specifications and their contents, including metadata such as authors,
dates, languages, revision history and supported project phases, as well as detailed descriptions of each
information requirement. In addition, this document specifies the IDM code generation rules based on
their key properties.
Use of this document will improve the interoperability of IDM specifications and their contents,
providing tight digital links between the components of an IDM specification and to external data
definitions such as ISO 16739-1 (industry foundation classes, IFC), ISO 12006-3, ISO 19650-1, ISO 23386,
ISO 23387, EN 17412-1 (level of information need) and ISO 21597-1 (information container for linked
document delivery), as well as model view definitions (MVDs) of standard data schemas.
vi
INTERNATIONAL STANDARD ISO 29481-3:2022(E)
Building information models — Information delivery
manual —
Part 3:
Data schema
1 Scope
This document is the technical addition to the methodology set out in ISO 29481-1. It defines a
specification to store, exchange and read information delivery manual (IDM) specifications in a
standardized and machine-readable way.
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 639-1, Codes for the representation of names of languages — Part 1: Alpha-2 code
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
code
ISO 8601-1, Date and time — Representations for information interchange — Part 1: Basic rules
ISO 22263, Organization of information about construction works — Framework for management of
project information
ISO 29481-1:2016, Building information models — Information delivery manual — Part 1: Methodology
and format
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 29481-1 and the following
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
attribute
XML construct that modifies or provides descriptive metadata about an element’s content
[SOURCE: ISO 20616-1:2021, 3.7, modified — The term “XML attribute” has been deleted. The phrase
“included within the start tag of an XML element” has been removed and “that element’s content” has
been replaced with “an element’s content”.]
3.2
information delivery manual code
IDM code
code for an IDM specification (3.3) created based on the key identifying features of an IDM specification
3.3
information delivery manual specification
IDM specification
instance of an IDM and its components
3.4
use case
UC
description of an information use for a specific purpose by one or more actors and/or systems
3.5
business context map
description of the information flow in a business context represented in the form of a process map or
interaction map
4 Overview of the IDM schema
4.1 Naming convention
The naming convention shown below is used for the IDM schema elements.
a) The camel case convention shall be used for the naming of IDM schema elements.
b) Except for the terms below, all the terms shall be spelled out:
1) idm: information delivery manual;
2) uc: use case;
3) er: exchange requirement;
4) pm: process map;
5) im: interaction map;
6) tm: transaction map;
7) id: identifier.
c) Elements that represent descriptions, a group or a set shall be specified using a plural form.
EXAMPLE benefits, limitations, requiredResources, requiredCompetencies.
4.2 Restriction notation
The following XSD restriction notation is used for the IDM data schema.
— PK: primary key.
— Required: mandatory.
— Optional: not mandatory.
— The 1:1 restriction depicts that both the minimum and maximum occurrence of an element is 1. This
means there shall be one element.
— The 0:1 restriction depicts that the minimum occurrence of an element is 0 and the maximum
occurrence is 1.
— The 0:* restriction depicts the zero to many relationship, which is represented as minOccurs = "0"
to maxOccurs = "unbounded" in the XML schema.
4.3 Overall structure of the IDM schema
The idmXSD consists of the idm element, its three core components (i.e. UC, business context map and
ER), and the relations and properties related to them.
— An IDM specification consists of a UC, business context maps and an ER.
— A UC shall include the header information specified in ISO 29481-1 and other metadata sufficient to
provide the context and the scope of an IDM.
— A business context map visually and formally represents the information delivery processes for a
UC. ISO 29481-1 requires the exchange method and process to be specified in one or more PM and/
or IM.
— An ER defines the information required by a specific UC at an individual information-unit level;
[19]
possibly with references to the elements of standard data schemas, such as CityGML , ISO 16739-1
[17]
(IFC), gbXML or ISO 12006-3.
Clauses 5 to 11 define the entities, relationships, attributes and restrictions of the IDM schema. Figure 1
illustrates a conceptual view of the IDM schema. A downloadable link to the full idmXSD is provided in
Annex A.
Figure 1 — Conceptual view of the IDM schema in the unified modelling language (UML)
class diagram
5 Information delivery manual
The idm element is a wrapper of core IDM components – namely UCs, business context maps and ERs
(see Figure 2). The constraints between them are as follows.
— The idm element shall be the single root element in the idmXSD.
— An idm element shall be associated with a single uc element and a single er element.
— An idm element may contain zero to many businessContextMap elements.
— The businessContextMap element and the er element may be left unspecified during the initial
development phase, to be detailed in a later version of the IDM specification as it is developed.
— An idm element may include zero to many subIdm elements. The other IDM components (i.e. the UC
element, the businessContextMap element and the er element) may also include zero to many sub-
elements.
This structure allows all the IDM components to be associated with multiple IDMs, UCs, business
context maps and ERs, which can be specified by external groups.
Figure 2 — XSD diagram of the IDM element
Table 1 lists the elements, types and restrictions of the IDM element.
Table 1 — IDM’s elements
Name Type Restriction Description
specId element 1:1 The specification identification information
(see Clause 6 for details).
authoring element 1:1 The author and change log information
(see Clause 7 for details).
subIdm element 0:* A subset of an IDM.
uc element 1:1 An associated UC.
businessContextMap element 0:* Associated business context maps.
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
TTabablele 1 1 ((ccoonnttiinnueuedd))
Name Type Restriction Description
er element 0:1 An associated ER.
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
6 Specification identifier (specId)
Each IDM component shall have a set of identifiers. An IDM specification and its sub-UC, business
context map and ER shall use four types of identifiers: a globally unique identifier (GUID), an IDM code,
and user-defined full and short titles (guid, idmCode, fullTitle and shortTitle, respectively). Since an
IDM specification can be specified in any language, the short title shall be provided in English. These
are referred to as the “specId attribute group”. The specId attribute group shall include the attributes
specified in Figure 3 and Table 2.
Figure 3 — XSD diagram of the specId
Table 2 — specId’s attributes
Name Type Restriction Description
guid string PK A globally unique identifier.
shortTitle string required A running title or byname for an IDM specification in
English.
localShortTitle string optional A running title or byname for an IDM specification in a local
language.
fullTitle string required A full name of an IDM specification.
subTitle string optional A supplementary title for an IDM specification.
idmCode string required A human- and machine-readable code, generated based
on the core metadata items of an IDM specification (see
Clause 11 for details).
localCode string optional A legacy identifier or a supplementary IDM identifier
generated according to a local code generation rule.
documentStatus string required The status of an IDM specification, from the initiation stage
to the official release stage.
The documentStatus shall be either one of NP (new
proposal), WD (working draft), PUB (publication) or
WDRL (withdrawal) (see Annex B for details).
localDocument- string optional The status of an IDM specification according to the local
Status document release status.
version string optional A combination of numbers and/or strings, which record the
development of an IDM specification.
7 Authoring
7.1 General
The authoring element stores the author information and the change history of IDM specifications,
including the changed contents, the principal or organization who created and changed the contents,
and the change date. An IDM specification shall be written by at least one author or one committee.
Authors can belong to one or more committees. The authoring element is composed of author,
committee, changeLog and publisher. The authoring’s attributes and elements are specified in Figure 4
and Table 3.
Figure 4 — XSD diagram of the authoring attributes
Table 3 — Authoring’s attributes and elements
Name Type Restriction Description
copyright string required A description about the copyright ownership and/or licence
information.
changeLog element 1:* The history of a specification: a chronological list of who
created and changed the specification, as well as when the
specification was created and changed (see 7.2 for details).
author element 0:* A person or organization that creates or modifies the IDM
specification (see 7.3 for details).
committee element 0:* The authoring group of the IDM specification (see 7.4 for
details).
publisher element 0:1 The publisher of the IDM specification (see 7.5 for details).
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
7.2 Change log
The changeLog consists of id, changeDateTime, changeSummary (content), changedBy (the author who
made a change) and changes. The IDM user or developer can track the changes in the IDM specifications
through the attributes in changeLog. The changeLog’s attributes and elements are specified in Tables 4
and 5.
Table 4 — changeLog’s attributes and elements
Name Type Restriction Description
id string PK A unique identifier assigned incrementally or
sequentially to an item to uniquely identify it.
changeDateTime dateTime required The date and time when the changes were made.
The format shall be “YYYY-MM-DD” as specified
by ISO 8601-1.
changeSummary string required A description of the change summary made in a
specification.
changedBy element 1:1 The author who created or made changes.
A reference to an id of the author element
(see 7.3 for details).
change element 0:* Each change instance in the changeLog.
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
Table 5 — Change’s attributes
Name Type Restriction Description
changedElement string required A metadata element that
was changed.
changedFrom string required A value before each
element has changed.
7.3 Author
The author element represents general information about the IDM creator and/or editor, such as
emailAddress, name (firstName, middleName and lastName), affiliation and id. An author can be a
person or an organization. The author’s attribute and elements are specified in Table 6. The person’s
attributes are specified in Table 7. The organization’s attributes are specified in Table 8.
Table 6 — Author’s attribute and elements
Name Type Restriction Description
id string PK The unique identifier for
representing each author.
person element 1:* A person who authors an
IDM specification.
organization element 1:* An organized body of
people who author an IDM
specification.
NOTE The XML elements are shaded in grey.
Table 7 — Person’s attributes
Name Type Restriction Description
firstName string required The first name of the author.
middleName string optional The middle name(s) of the author.
lastName string optional The last name of the author.
emailAddress string optional An email address of the author.
affiliation string optional The affiliations of the author.
Table 8 — Organization’s attribute
Name Type Restriction Description
name string required, unique The name of an organization.
7.4 Committee
The committee element shall be used when an IDM specification is developed by a named committee
of authors. The committee element includes name, leader, member, etc. The committee’s attribute and
elements are specified in Table 9.
Table 9 — Committee’s attributes and elements
Name Type Restriction Description
name string PK The name of an authoring group.
leader element 0.* The author who leads an IDM specification author team
(a reference to the identifier of an author who belongs
to a committee) (see 7.3 for details).
member element 0.* A reference to the identifier of an author who belongs to
a committee (see 7.3 for details).
NOTE The XML elements are shaded in grey.
7.5 Publisher
The publisher element represents the entity that published the IDM specification. It is composed of the
name and location. The publisher’s attributes are specified in Table 10.
Table 10 — Publisher’s attributes
Name Type Restriction Description
name string required The entity that published the IDM specification.
location string optional The region (a country or a city) where the IDM specification
was published.
8 Use case
8.1 General
The UC element in the IDM schema can be understood as a collection or an extension of the overview
information of a PM and an ER specified in ISO 29481-1. The UC attributes and elements are specified in
Figure 5 and Table 11 to Table 32.
Figure 5 — XSD diagram of the UC element
Table 11 — UC’s elements
Name Type Restriction Description
specId element 1:1 The IDM specification identification information
(see Clause 6 for details).
authoring element 1:1 The author and changeLog information (see
Clause 7 for details).
subUc element 0:* A subset of a UC.
summary element 1:1 A brief of the aim and scope, benefits, and other
aspects of an IDM specification (see 8.2 for de-
tails).
aimAndScope element 1:1 The purpose and coverage of an IDM specification
(see 8.3 for details).
language element 1:1 The language used to define an IDM specification,
which shall be in accordance with ISO 639-1.
use element 1:* A method of utilizing information in a project for a
specific purpose (see 8.4 for details).
standardProjectPhase element 1:* The phase or stage of a project that an IDM speci-
fication is targeting in accordance with ISO 22263
(see 8.5 for details).
localProjectPhase element 0:* The phase or stage of a project that an IDM spec-
ification is targeting, based on a project life cycle
classification system chosen by the authors (e.g.
Generic Process Protocol (GPP), the American In-
stitute of Architects (AIA) or the Royal Institute of
British Architects (RIBA)) (see 8.6 for details).
region element 1:* A geographical area where a specified document
will be used (see 8.7 for details).
constructionEntity element 0.* A type of construction product by function
(see 8.8 for details).
businessRule element 0:* Operation, definition or constraint that can be
applied to a set of data used within a particular
process or activity (see 8.9 for details).
actor element 0:* The role or discipline of the project participant
who is sending and receiving information
(see 8.10 for details).
benefits element 0:1 A description of the advantages that can be gained
from a UC (see 8.11 for details).
limitations element 0:1 A description of the weaknesses, scope or distinc-
tive characteristics of a UC (see 8.12 for details).
requiredResources element 0:1 A description of the resources that are prerequi-
sites to begin a UC (see 8.13 for details).
requiredCompetencies element 0:1 A description of the competencies required by a
team member to conduct the activities specified in
a UC (see 8.14 for details).
scopeKeyword element 0:* A keyword that describes the scope of a UC.
benefitKeyword element 0:* A keyword that describes the advantages that can
be gained from a specified UC.
reference element 0:* An external source, such as a standard, to which
an IDM specification refers (see 8.15 for details).
userDefinedProperty element 0:* An additional property to further describe a UC
(see 8.16 for details).
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
8.2 Summary
An overall summary of the purpose, scope, benefits and other aspects of an IDM specification shall be
specified using the summary element. A summary can be specified in multiple languages. However, the
first (default) summary shall be specified in English for international readers. The summary’s element
is specified in Table 12.
Table 12 — Summary’s element
Name Type Restriction Description
description element 1:* A textual or visual explanation.
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
8.3 Aim and scope
The purpose and coverage of an IDM specification shall be specified using the aim and scope element.
The aim and scope’s element is specified in Table 13.
Table 13 — Aim and scope’s element
Name Type Restriction Description
description element 1:* A textual or visual explanation.
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
8.4 Use
The use element is a high-level classification of information uses within an asset’s life cycle. If the
specified information use is based on any information-use classification system, the classification
system can be specified using the classification element. The name of a use shall be defined in the form
of a verb plus a noun, as specified in ISO 29481-1:2016, Table 1, Naming rule 3. The use’s attribute and
element are specified in Table 14.
EXAMPLE ModelWall, EstimateCost, CheckModelCompliance.
Table 14 — Use’s attribute and element
Name Type Restriction Description
name string required, unique The name of a use.
classification element 0:1 The classification system on which the
specified information use is based (see
8.17 for details).
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
8.5 Standard project phase
The standardProjectPhase’s attributes represent the targeting life cycle phases of the IDM specifications.
In particular, the standard project phase, which follows ISO 22263, shall be specified for the design
coordination or cooperation between international companies or institutions. ISO 22263 classifies
a project life cycle into six phases: inception, brief, design, production, maintenance and demolition.
An IDM can target one or more phases. Additionally, the outcomes and the information requirements
of each phase can be described. The standard project phase’s attribute and elements are specified in
Table 15.
Table 15 — standardProjectPhase’s attribute and elements
Name Type Restriction Description
name enumeration required, The name of the targeted life cycle phase
unique based on ISO 22263: an enumeration of
inception, brief, design, production,
maintenance and demolition.
outcomes element 0:1 The descriptions of the expected results
once the selected life cycle phase is
completed (see 8.18 for details).
informationRequirements element 0:1 The descriptions of the information re-
quired by the selected life cycle phase
(see 8.19 for details).
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
8.6 Local project phase
In addition to the standard project phase, the authors may specify a target life cycle phase(s) based on a
project-phase classification system of their choice. This is referred to as the “local project phase(s)”. To
specify a local project phase, the first step is to specify the project-phase classification system that the
authors elect to use, with the classification element. The second step is to specify the target phases of
an IDM. The local project phase’s elements are specified in Table 16.
EXAMPLE Project phases defined by the GPP, AIA or RIBA.
Table 16 — Local project phase’s elements
Name Type Restriction Description
A stage name for the project life cycle phases, based
name element 1:1 on the project phase classification system chosen by
the author.
The descriptions of the expected results once the
outcomes element 0:1 selected life cycle phase is completed (see 8.18 for
details).
The descriptions of the information required by the
informationRequirements element 0:1
selected life cycle phase (see 8.19 for details).
A classification system upon which the specified local
classification element 0:1
project phase is based (see 8.17 for details).
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
8.7 Region
The target regions of an IDM shall be specified using the region element. The region’s attributes are
specified in Table 17.
Table 17 — Region’s attributes
Name Type Restriction Description
type string required, unique A geographical area, either of a continent, a country or a user-de-
fined region, where an IDM specification will be used.
The default value of the user-defined region is the “USR”.
value string required A target region of an IDM specification.
The default value is “INT”, which stands for international (use).
For continents and countries, the continent and country codes
defined in ISO 3166-1 shall be used.
8.8 Construction entity
The facility type that an IDM specification aims to support shall be specified using the constructionEntity
element.
EXAMPLE A hospital facility, an airport, a railway, a data centre.
The classification element is the field to specify a standard classification system for construction
TM1)
entities (or facility type). An example of a standard classification system is OmniClass Table 11 -
[14]
Construction Entities by Function . The construction entity’s attribute and element are specified in
Table 18.
Table 18 — Construction entity’s attribute and element
Name Type Restriction Description
name string required, unique A construction entity of a project in which the targeted
specification is based on the chosen classification
element.
classification element 0:1 A classification system that the specified construction
entity is based on (see 8.17 for details).
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
8.9 Business rule
The businessRule element describes the operations, definitions and constraints that can be applied to
the set of data used within a particular process or activity. A business rule is composed of id, name,
proposition and references. The business rule’s attributes and elements are specified in Table 19. The
proposition’s element is specified in Table 20.
Table 19 — Business rule’s attributes and elements
Name Type Restriction Description
id string PK An identifier for a business rule, unique at least within a
specification.
name string required, unique An author-defined short title for a business rule, not
unique (e.g. aggregate electric elements to a distribution
point).
proposition element 1:1 A description of the rule (e.g. only occurrences of
particular types of electrical distribution elements can be
aggregated within a distribution point). The proposition
may include a graphical example.
reference element 0:* An external source, such as a standard, to which a business
rule refers. The reference element refers to the reference
element of the UC element (see 8.15 for details).
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
Table 20 — Proposition’s element
Name Type Restriction Description
description element 1:* A textual or visual explanation.
NOTE The XML elements are shaded in grey. XML elements with sub-elements are depicted separately.
TM
1) OmniClass is an example of a suitable product available commercially. This information is given for the
convenience of users of this document and does not constitute an endorsement by ISO of this product.
8.10 Actor
The actor element specifies the actors who send and receive the required information (i.e. ER). The actor
is a person, organization or organizational unit (such as a department or team) involved in a facility’s
life cycle process. More than one actor can send and receive an ER. Authors can choose a standard
classification system for the actor (role) type. The classification element allows the
...
NORME ISO
INTERNATIONALE 29481-3
Première édition
2022-09
Modèles des informations de la
construction — Protocole d’échange
d’informations —
Partie 3:
Schéma de données
Building information models — Information delivery manual —
Part 3: Data schema
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2022
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 .v
Introduction . vi
1 Domaine d’application . 1
2 Références normatives .1
3 Termes et définitions . 1
4 Vue d’ensemble du schéma de l’IDM .2
4.1 Convention de nommage . 2
4.2 Notation de restriction . 2
4.3 Structure globale du schéma de l’IDM . 3
5 Protocole d’échange d’informations . 5
6 Identifiant de spécification (specId). 6
7 Auteur (authoring) .7
7.1 Généralités . 7
7.2 Journal des changements (changeLog) . 9
7.3 Auteur (author) . 9
7.4 Comité (committee). 10
7.5 Éditeur (publisher) . 10
8 Cas d’usage (UC) .11
8.1 Généralités . 11
8.2 Résumé (summary) .13
8.3 Objectif et domaine d’application (aimAndScope) . 13
8.4 Utilisation (use) . 13
8.5 Phase de projet normalisée (standardProjectPhase). 13
8.6 Phase de projet locale (localProjectPhase) . 14
8.7 Région (region) . 14
8.8 Entité de construction (constructionEntity) . 15
8.9 Règle métier (businessRule). 15
8.10 Acteur (actor) . 16
8.11 Bénéfices (benefits) . 16
8.12 Limites (limitations) . 16
8.13 Ressources requises (requiredResources) . 16
8.14 Compétences requises (requiredCompetencies) . 17
8.15 Référence (reference). 17
8.16 Propriété définie par l’utilisateur (userDefinedProperty) . 18
8.17 Classification (classification) . 18
8.18 Résultats (outcomes) . . 18
8.19 Exigences d’information (informationRequirements) . 18
8.20 Description (description) . 19
8.21 Image (image) . 19
9 Carte de contexte métier (businessContextMap) .19
9.1 Généralités . 19
9.2 Carte de processus (PM) . 21
9.2.1 Généralités . 21
9.2.2 Objet de données et ER (dataObjectAndEr) . 21
9.3 Carte d’interaction (IM) . 21
9.3.1 Généralités . 21
9.3.2 Carte de transaction (TM) . 22
9.4 Diagramme (diagram) . 22
10 Exigence d’échange (ER) .22
10.1 Généralités .22
iii
10.2 Unité d’informations (informationUnit) . 24
10.2.1 Généralités . 24
10.2.2 Exemples (examples) . 24
10.2.3 Élément externe correspondant (correspondingExternalElement) .25
10.3 Contrainte (constraint) . 25
10.4 MVD correspondante (correspondingMvd) . 25
11 Règles de génération du code IDM .26
Annexe A (informative) idmXSD (idmXML Schema Definition) .28
Annexe B (informative) Stades des spécifications IDM .29
Bibliographie .30
iv
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’attention est attirée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
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 le lien suivant: www.iso.org/iso/fr/avant-propos.
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).
Une liste de toutes les parties de la série ISO 29481 se trouve sur le site web de l’ISO.
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.
v
Introduction
Le présent document spécifie un schéma de données applicable, lisible et transférable sur
machine (SMART) pour le développement, la gestion et la réutilisation efficace des spécifications
du protocole d’échange d’informations (IDM) basées sur l’ISO 29481‑1. L’ISO 29481‑1 définit une
méthodologie qui permet de décrire les processus et les exigences d’information pour un but défini
au cours du développement ou de la gestion d’un bien. En l’absence de schéma de données normalisé
pour l’échange et le partage de contenu des IDM dans un format électronique, les spécifications IDM
ont historiquement été développées sous forme de fichier de document statique ou de fichier de
données spécifié dans un format de données propriétaire. Par conséquent, tout échange, partage et
réutilisation de leur contenu est impossible. L’objectif du présent document est de définir un schéma
de données normalisé afin d’accélérer le développement et le partage des spécifications IDM afin de
répondre à l’augmentation rapide de la demande de différents cas d’usage (UC) de la modélisation des
informations de la construction (BIM).
En utilisant le format XML (eXtensible Markup Language), le présent document spécifie un schéma
de données qui permet de créer, d’échanger et de partager une spécification IDM définie par
l’ISO 29481‑1. Le schéma de données en question est appelé idmXSD (idmXML Schema Definition) et a
pour but de permettre aux utilisateurs de stocker, de rechercher, de partager, d’échanger et de réutiliser
des spécifications IDM et leur contenu sous forme électronique, y compris les métadonnées telles que
les auteurs, les dates, les langues, l’historique des révisions et les phases de projet prises en charge,
ainsi que les descriptions détaillées de chaque exigence d’information. De plus, le présent document
spécifie les règles de génération du code IDM basées sur leurs propriétés clés.
L’utilisation du présent document améliorera l’interopérabilité des spécifications IDM et de leur contenu,
en créant des liens numériques étroits entre les composants d’une spécification IDM et les définitions
de données externes telles que l’ISO 16739-1 (classes de fondation d’industrie, IFC), l’ISO 12006-3,
l’ISO 19650-1, l’ISO 23386, l’ISO 23387, l’EN 17412-1 (niveau du besoin d’information) et l’ISO 21597-1
(conteneur d’informations pour la livraison de documents liés), ainsi que les définitions de vue du
modèle (MVD) des schémas de données normalisés.
vi
NORME INTERNATIONALE ISO 29481-3:2022(F)
Modèles des informations de la construction — Protocole
d’échange d’informations —
Partie 3:
Schéma de données
1 Domaine d’application
Le présent document est le complément technique de la méthodologie exposée dans l’ISO 29481-1.
Il définit une spécification pour le stockage, l’échange et la lecture des spécifications du protocole
d’échange d’informations (IDM) sous une forme normalisée et lisible par un ordinateur.
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 639-1, Codes pour la représentation des noms de langue — Partie 1: Code alpha-2
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 1: Codes de
pays
ISO 8601-1, Date et heure — Représentations pour l'échange d'information — Partie 1: Règles de base
ISO 22263, Organisation de l'information des travaux de construction — Cadre général pour la gestion de
l'information des projets
ISO 29481-1:2016, Modèles des informations de la construction — Protocole d’échange d’informations —
Partie 1: Méthodologie et format
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions de l’ISO 29481‑1 ainsi que les 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
attribut
concept XML qui modifie ou fournit des métadonnées descriptives sur le contenu d’un élément
[SOURCE: ISO 20616‑1:2021, 3.7, modifié — Le terme «attribut XML» a été supprimé. Le texte «inclus
dans la balise de début d’un élément XML» a été supprimé et «le contenu de cet élément» a été remplacé
par «le contenu d’un élément»]
3.2
code du protocole d’échange d’informations
code IDM
code d’une spécification IDM (3.3), créé sur la base des caractéristiques d’identification par clé d’une
spécification IDM
3.3
spécification du protocole d’échange d’informations
spécification IDM
instance d’un IDM et de ses composants
3.4
cas d’usage
UC
description d’une utilisation d’informations dans un but spécifique par un ou plusieurs acteurs et/ou
systèmes
3.5
carte de contexte métier
description du flux d’informations dans un contexte métier représenté sous la forme d’une carte
de processus ou d’une carte d’interaction
4 Vue d’ensemble du schéma de l’IDM
4.1 Convention de nommage
La convention de nommage indiquée ci-dessous est utilisée pour les éléments du schéma de l’IDM.
a) La casse chameau doit être utilisée pour le nommage des éléments du schéma de l’IDM.
b) À l’exception des termes ci-dessous, tous les termes doivent être en toutes lettres:
1) idm: protocole d’échange d’informations;
2) uc: cas d’usage;
3) er: exigence d’échange;
4) pm: carte de processus;
5) im: carte d’interaction;
6) tm: carte de transaction;
7) id: identifiant.
c) Les éléments qui représentent des descriptions, un groupe ou un ensemble doivent être spécifiés en
utilisant le pluriel.
EXEMPLE benefits, limitations, requiredResources, requiredCompetencies.
4.2 Notation de restriction
La notation de restriction XSD suivante est utilisée pour le schéma de données d’IDM.
— «PK»: clé primaire.
— «Requis»: obligatoire.
— «Facultatif»: non obligatoire.
— La restriction 1:1 signifie que les occurrences minimale et maximale d’un élément sont égales à 1,
ce qui implique qu’il ne doit y avoir qu’un seul élément.
— La restriction 0:1 signifie que l’occurrence minimale d’un élément est égale à 0 et que l’occurrence
maximale est égale à 1.
— La restriction 0:* désigne la relation de type zéro à plusieurs, qui est représentée par minOccurs = «0»
jusqu’à maxOccurs = «unbounded» dans le schéma XML.
4.3 Structure globale du schéma de l’IDM
L’idmXSD se compose de l’élément idm, de ses trois composants de base (UC, carte de contexte métier et
ER) et des relations et propriétés associées.
— Une spécification IDM se compose d’un UC, de cartes de contexte métier et d’une ER.
— Un UC doit inclure les informations d’en‑tête spécifiées dans l’ISO 29481‑1 et suffisamment d’autres
métadonnées pour fournir le contexte et le domaine d’application d’un IDM.
— Une carte de contexte métier représente visuellement et formellement les processus de livraison
d’informations pour un UC. L’ISO 29481‑1 exige de spécifier la méthode et le processus d’échange
dans une ou plusieurs cartes de processus et/ou d’interaction.
— Une ER définit les informations requises par un UC spécifique au niveau d’une unité d’informations
individuelle, éventuellement avec des références aux éléments de schémas de données normalisés,
[19] [17]
tels que CityGML , l’ISO 16739-1 (IFC), gbXML ou l’ISO 12006-3.
Les Articles 5 à 11 définissent les entités, les relations, les attributs et les restrictions du schéma
de l’IDM. La Figure 1 représente une vue conceptuelle du schéma de l’IDM. Un lien permettant de
télécharger l’idmXSD complet est donné à l’Annexe A.
Figure 1 — Vue conceptuelle du schéma de l’IDM dans le diagramme de classes
en langage de modélisation unifié (UML)
5 Protocole d’échange d’informations
L’élément idm est une classe enveloppante de composants de base de l’IDM – à savoir les UC, les cartes
de contexte métier et les ER (voir Figure 2). Les contraintes réciproques sont les suivantes.
— L’élément d’IDM doit être le seul élément racine dans l’idmXSD.
— Un élément idm doit être associé à un seul élément uc et à un seul élément er.
— Un élément idm peut contenir de zéro à plusieurs éléments businessContextMap.
— L’élément businessContextMap et l’élément er peuvent être laissés non spécifiés au cours de la phase
initiale de développement et seront détaillés dans une version ultérieure de la spécification IDM dès
qu’elle sera développée.
— Un élément idm peut comprendre de zéro à plusieurs éléments subIdm. Les autres composants de
l’IDM (c’est-à-dire l’élément UC, l’élément businessContextMap et l’élément er) peuvent également
comprendre de zéro à plusieurs sous-éléments.
Cette structure permet d’associer tous les composants de l’IDM à de multiples IDM, UC, cartes de
contexte métier et ER, qui peuvent être spécifiés par des groupes externes.
Figure 2 — Diagramme XSD de l’élément d’IDM
Le Tableau 1 énumère les éléments, les types et les restrictions de l’élément d’IDM.
Tableau 1 — Éléments d’IDM
Nom Type Restriction Description
specId élément 1:1 Informations d’identification de la spécification
(voir l’Article 6 pour de plus amples détails).
authoring élément 1:1 Informations sur l’auteur et le journal des changements
(voir l’Article 7 pour de plus amples détails).
subIdm élément 0:* Sous-ensemble d’un IDM.
uc élément 1:1 UC associé.
businessContextMap élément 0:* Cartes de contexte métier associées.
er élément 0:1 ER associée.
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
6 Identifiant de spécification (specId)
Chaque composant d’IDM doit comporter un ensemble d’identifiants. Une spécification IDM et son sous‑
UC, sa carte de contexte métier et son ER doivent utiliser quatre types d’identifiants: un identifiant global
unique (GUID), un code d’IDM et des titres complets et courts définis par l’utilisateur (guid, idmCode,
fullTitle et shortTitle, respectivement). Comme une spécification IDM peut être spécifiée dans une
langue quelconque, le titre court doit être donné en anglais. Ils sont définis dans le groupe d’attributs
«specId» qui doit inclure les attributs spécifiés sur la Figure 3 et dans le Tableau 2.
Figure 3 — Diagramme XSD du groupe specId
Tableau 2 — Attributs du groupe specId
Restric-
Nom Type Description
tion
guid chaîne PK Identifiant global unique.
shortTitle chaîne requis Titre courant ou surnom d’une spécification IDM en anglais.
localShortTitle chaîne facultatif Titre courant ou surnom d’une spécification IDM dans une langue
locale.
fullTitle chaîne requis Nom complet d’une spécification IDM.
subTitle chaîne facultatif Titre complémentaire d’une spécification IDM.
idmCode chaîne requis Code lisible par l’homme et par un ordinateur, généré à partir des élé-
ments de métadonnées de base d’une spécification IDM
(voir l’Article 11 pour de plus amples détails).
localCode chaîne facultatif Identifiant hérité ou complémentaire de l’IDM, généré d’après une règle
locale de génération de code.
documentStatus chaîne requis Statut d’une spécification IDM, du stade de début jusqu’au stade de
publication officielle.
L’attribut documentStatus doit être un stade parmi NP (nouvelle pro-
position), WD (mise à l’étude du projet de travail), PUB (publication) ou
WDRL (annulation)
(voir l’Annexe B pour de plus amples détails).
localDocu- chaîne facultatif Statut d’une spécification IDM selon le statut local de diffusion des
mentStatus documents.
version chaîne facultatif Combinaison de nombres et/ou de chaînes qui enregistrent le dévelop-
pement d’une spécification IDM.
7 Auteur (authoring)
7.1 Généralités
L’élément authoring stocke les informations sur l’auteur et l’historique des changements apportés
aux spécifications IDM, y compris le contenu modifié, la personne ou l’organisation qui a créé et modifié
le contenu, ainsi que la date de modification. Une spécification IDM doit être rédigée par au moins un
auteur ou un comité. Les auteurs peuvent faire partie d’un ou plusieurs comités. L’élément authoring
se compose de: author, committee, changeLog et publisher. Les attributs et les éléments de l’élément
authoring sont spécifiés sur la Figure 4 et dans le Tableau 3.
Figure 4 — Diagramme XSD des attributs de l’élément authoring
Tableau 3 — Attributs et éléments de l’élément authoring
Restric-
Nom Type Description
tion
copyright chaîne requis Description concernant la propriété des droits d’auteur et/ou
les informations de licence.
changeLog élément 1:* Historique d’une spécification: liste chronologique de la personne
ou de l’organisation ayant créé et modifié la spécification, ainsi que
les dates de création et de modification de la spécification
(voir 7.2 pour de plus amples détails).
author élément 0:* Personne ou organisation qui crée ou modifie la spécification IDM
(voir 7.3 pour de plus amples détails).
committee élément 0:* Groupe d’auteurs de la spécification IDM
(voir 7.4 pour de plus amples détails).
publisher élément 0:1 Éditeur de la spécification IDM
(voir 7.5 pour de plus amples détails).
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
7.2 Journal des changements (changeLog)
L’élément changeLog se compose de: id, changeDateTime, changeSummary (contenu), changedBy
(l’auteur d’un changement) et change. L’utilisateur ou le développeur de l’IDM peut suivre les
changements apportés aux spécifications IDM via les attributs de changeLog. Les attributs et les
éléments de changeLog sont spécifiés dans les Tableaux 4 et 5.
Tableau 4 — Attributs et éléments de l’élément changelog
Restric-
Nom Type Description
tion
id chaîne PK Identifiant unique affecté de manière incrémentale ou séquentielle
à un élément afin de l’identifier de façon unique.
changeDateTime dateTime requis Date et heure auxquelles les changements ont été effectués.
Le format doit être "YYYY‑MM‑DD" tel que spécifié par l’ISO 8601‑
1.
changeSummary chaîne requis Description du résumé des changements apportés à une spécifica-
tion.
changedBy élément 1:1 Auteur à l’origine de la spécification ou ayant effectué les change-
ments. Cet attribut peut se référer à un id de l’élément author (voir
7.3 pour de plus amples détails).
change élément 0:* Chaque instance de changement dans l’élément changeLog.
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
Tableau 5 — Attributs de l’élément change
Restric-
Nom Type Description
tion
changedElement chaîne requis Élément de métadonnée qui a été changé.
changedFrom chaîne requis Valeur avant le changement de chaque élément.
7.3 Auteur (author)
L’élément author représente des informations générales sur le créateur et/ou l’éditeur de l’IDM,
telles que emailAddress, name (firstName, middleName et lastName), affiliation et id. Un auteur peut
être une personne ou une organisation. Les attributs et les éléments de l’élément author sont spécifiés
dans le Tableau 6. Les attributs de l’élément person sont spécifiés dans le Tableau 7. Les attributs de
l’élément organization sont spécifiés dans le Tableau 8.
Tableau 6 — Attributs et éléments de l’élément author
Nom Type Restriction Description
id chaîne PK Identifiant unique utilisé pour représenter chaque auteur.
person élément 1:* Personne qui est l’auteur d’une spécification IDM.
organization élément 1:* Groupe organisé de personnes qui sont les auteurs d’une spécifica-
tion IDM.
NOTE Les éléments XML apparaissent en grisé.
Tableau 7 — Attributs de l’élément person
Nom Type Restriction Description
firstName chaîne requis Prénom de l’auteur.
middleName chaîne facultatif Deuxième(s) prénom(s) de l’auteur.
lastName chaîne facultatif Nom de famille de l’auteur.
emailAddress chaîne facultatif Adresse de messagerie électronique de l’auteur.
affiliation chaîne facultatif Affiliations de l’auteur.
Tableau 8 — Attribut de l’élément organization
Nom Type Restriction Description
name chaîne requis, unique Nom d’une organisation.
7.4 Comité (committee)
L’élément committee doit être utilisé lorsqu’une spécification IDM est développée par un comité
d’auteurs désigné. L’élément committee inclut name, leader, member, etc. Les attributs et les éléments
de l’élément committee sont spécifiés dans le Tableau 9.
Tableau 9 — Attributs et éléments de l’élément committee
Nom Type Restriction Description
name chaîne PK Nom d’un groupe d’auteurs.
leader élément 0.* Auteur qui dirige une équipe d’auteurs de la spécification IDM (réfé-
rence à l’identifiant d’un auteur qui fait partie d’un comité) (voir 7.3
pour de plus amples détails).
member élément 0.* Référence à l’identifiant d’un auteur qui fait partie d’un comité
(voir 7.3 pour de plus amples détails).
NOTE Les éléments XML apparaissent en grisé.
7.5 Éditeur (publisher)
L’élément publisher représente l’entité qui a publié la spécification IDM. Il se compose de name et
location. Les attributs de l’élément publisher sont spécifiés dans le Tableau 10.
Tableau 10 — Attributs de l’élément Publisher
Nom Type Restriction Description
name chaîne requis Entité qui a publié la spécification IDM.
location chaîne facultatif Région (pays ou ville) où la spécification IDM a été publiée.
8 Cas d’usage (UC)
8.1 Généralités
L’élément UC dans le schéma de l’IDM peut être entendu comme une collection ou une extension des
informations de description d’une PM et d’une ER spécifiées dans l’ISO 29481‑1. Les attributs et les
éléments de l’élément UC sont spécifiés sur la Figure 5 et dans les Tableaux 11 à 32.
Figure 5 — Diagramme XSD de l’élément UC
Tableau 11 — Éléments de UC
Nom Type Restriction Description
specId élément 1:1 Informations d’identification de la spécification IDM (voir l’Ar-
ticle 6 pour de plus amples détails).
authoring élément 1:1 Informations author et changeLog
(voir l’Article 7 pour de plus amples détails).
subUc élément 0:* Sous-ensemble d’un UC.
summary élément 1:1 Résumé de l’objectif et du domaine d’application, des bénéfices
et d’autres aspects d’une spécification IDM
(voir 8.2 pour de plus amples détails).
aimAndScope élément 1:1 Objectif et domaine d’application d’une spécification IDM
(voir 8.3 pour de plus amples détails).
language élément 1:1 Langue utilisée pour définir une spécification IDM, qui doit
être conforme à l’ISO 639-1.
use élément 1:* Méthode d’utilisation de l’information au sein d’un projet dans
un but spécifique (voir 8.4 pour de plus amples détails).
standardProjectPhase élément 1:* Phase ou stade d’un projet ciblé par une spécification IDM
conformément à l’ISO 22263 (voir 8.5 pour de plus amples
détails).
localProjectPhase élément 0:* Phase ou stade d’un projet ciblé par une spécification, basé
sur le système de classification du cycle de vie des projets
choisi par les auteurs (par exemple le Processus de protocole
générique (GPP), l’Institut Américain des Architectes (AIA)
ou l’Institut Royal des Architectes Britanniques (RIBA))
(voir 8.6 pour de plus amples détails).
region élément 1:* Zone géographique où un document spécifié sera utilisé
(voir 8.7 pour de plus amples détails).
constructionEntity élément 0.* Type de produit de construction par fonction
(voir 8.8 pour de plus amples détails).
businessRule élément 0:* Opération, définition ou contrainte qui peut être appliquée
à un ensemble de données utilisé dans une activité ou un pro-
cessus particulier (voir 8.9 pour de plus amples détails).
actor élément 0:* Rôle ou discipline du participant au projet qui envoie et reçoit
des informations (voir 8.10 pour de plus amples détails).
benefits élément 0:1 Description des avantages qui peuvent être obtenus d’un UC
(voir 8.11 pour de plus amples détails).
limitations élément 0:1 Description des faiblesses du domaine d’application
ou de caractéristiques distinctives d’un UC
(voir 8.12 pour de plus amples détails).
requiredResources élément 0:1 Description des ressources qui sont préalablement requises
avant le début d’un UC (voir 8.13 pour de plus amples détails).
requiredCompetencies élément 0:1 Description des compétences requises de la part d’un membre
de l’équipe pour mener les activités spécifiées dans un UC
(voir 8.14 pour de plus amples détails).
scopeKeyword élément 0:* Mot-clé qui décrit le domaine d’application d’un UC.
benefitKeyword élément 0:* Mot-clé qui décrit les avantages qui peuvent découler d’un UC
spécifié.
reference élément 0:* Source externe, telle qu’une norme, à laquelle une spécifica-
tion IDM se réfère (voir 8.15 pour de plus amples détails).
userDefinedProperty élément 0:* Propriété supplémentaire complétant la description d’un UC
(voir 8.16 pour de plus amples détails).
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
8.2 Résumé (summary)
Un résumé global de l’objectif, du domaine d’application, des bénéfices et d’autres aspects
d’une spécification IDM doit être spécifié en utilisant l’élément summary. Un résumé peut être spécifié
en plusieurs langues. Cependant, le premier résumé (par défaut) doit être spécifié en anglais pour les
lecteurs internationaux. L’élément summary est spécifié dans le Tableau 12.
Tableau 12 — Élément summary
Nom Type Restriction Description
description élément 1:* Explication textuelle ou visuelle.
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
8.3 Objectif et domaine d’application (aimAndScope)
L’objectif et le domaine d’application d’une spécification IDM doivent être spécifiés en utilisant
l’élément aimAnd Scope. L’élément aimAndScope est spécifié dans le Tableau 13.
Tableau 13 — Élément aimAndScope
Nom Type Restriction Description
description élément 1:* Explication textuelle ou visuelle.
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
8.4 Utilisation (use)
L’élément use est une classification de haut niveau des utilisations d’informations au cours du cycle
de vie d’un bien. Si l’utilisation d’informations spécifiées repose sur un système de classification
des utilisations d’informations, ce système peut être spécifié en utilisant l’élément classification.
Le nom d’une utilisation doit être défini sous la forme d’un verbe plus un nom, comme spécifié dans
l’ISO 29481‑1:2016, Tableau 1, Règle de nommage 3. Les attributs et les éléments de use sont spécifiés
dans le Tableau 14.
EXEMPLE ModelWall, EstimateCost, CheckModelCompliance.
Tableau 14 — Attributs et éléments de use
Nom Type Restriction Description
name chaîne requis, Nom d’une utilisation.
unique
classification élément 0:1 Système de classification sur lequel l’utilisation d’informations spéci-
fiée est basée (voir 8.17 pour de plus amples détails).
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
8.5 Phase de projet normalisée (standardProjectPhase)
Les attributs de l’élément standardProjectPhase représentent les phases de cycle de vie ciblées
des spécifications IDM. En particulier, la phase de projet normalisée, qui suit l’ISO 22263, doit être
spécifiée pour la coordination de la conception ou la coopération entre les entreprises ou institutions
internationales. L’ISO 22263 classe un cycle de vie de projet en six phases: lancement, préparation,
conception, production, maintenance et déconstruction. Un IDM peut cibler une ou plusieurs phases.
De plus, les résultats et les exigences d’information de chaque phase peuvent être décrits. Les attributs
et les éléments de standardProjectPhase sont spécifiés dans le Tableau 15.
Tableau 15 — Attributs et éléments de standardProjectPhase
Nom Type Restriction Description
name énumération requis, unique Nom de la phase de cycle de vie ciblée, basé sur
l’ISO 22263: énumération de lancement, prépa-
ration, conception, production, maintenance et
déconstruction.
outcomes élément 0:1 Descriptions des résultats attendus après l’achève-
ment de la phase de cycle de vie sélectionnée (voir
8.18 pour de plus amples détails).
informationRequirements élément 0:1 Descriptions des informations requises par la phase
de cycle de vie sélectionnée
(voir 8.19 pour de plus amples détails).
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
8.6 Phase de projet locale (localProjectPhase)
En plus de la phase de projet normalisée, les auteurs peuvent spécifier une ou des phases de cycle de
vie cibles sur la base d’un système de classification des phases de projet de leur choix, appelée
«phase de projet locale». Pour spécifier une phase de projet locale, la première étape consiste à
spécifier le système de classification des phases de projet que les auteurs choisissent d’utiliser, avec
l’élément classification. La seconde étape consiste à spécifier les phases cibles d’un IDM. Les éléments
d’une phase de projet locale sont spécifiés dans le Tableau 16.
EXEMPLE Phases de projet définies par GPP, AIA ou RIBA.
Tableau 16 — Éléments d’une phase de projet locale
Nom Type Restriction Description
name élément 1:1 Nom du stade pour les phases de cycle de vie du pro-
jet, basé sur le système de classification des phases
de projet choisi par l’auteur.
outcomes élément 0:1 Descriptions des résultats attendus après l’achève-
ment de la phase de cycle de vie sélectionnée (voir
8.18 pour de plus amples détails).
informationRequirements élément 0:1 Descriptions des informations requises par la phase
de cycle de vie sélectionnée
(voir 8.19 pour de plus amples détails).
classification élément 0:1 Système de classification sur lequel la phase de projet
locale spécifiée est basée
(voir 8.17 pour de plus amples détails).
NOTE Les éléments XML apparaissent en grisé. Les éléments XML et leurs sous-éléments sont représentés séparément.
8.7 Région (region)
Les régions cibles d’un IDM doivent être spécifiées en utilisant l’élément region. Les attributs de
l’élément region sont spécifiés dans le Tableau 17.
Tableau 17 — Attributs de l’élément region
Nom Type Restriction Description
type chaîne requis, unique Zone géographique, c’est-à-dire un continent, un pays ou une région
définie par l’utilisateur, où une spécification IDM sera utilisée.
La valeur par défaut de la région définie par l’utilisateur est «USR».
TTabableleaauu 1 177 ((ssuuiitte)e)
Nom Type Restriction Description
value chaîne requis Région cible d’un IDM spécification.
La valeur par défaut est «INT», qui désigne une utilisation interna-
tionale. Pour les continents et les pays, les codes de continents et de
pays définis dans l’ISO 3166‑1 doivent être utilisés.
8.8 Entité de construction (constructionEntity)
Le type d’installation qu’une spécification IDM vise à soutenir doit être spécifié en utilisant l’élément
constructionEntity.
EXEMPLE Un établissement hospitalier, un aéroport, une voie ferroviaire ou un centre de données.
L’élément classification est le champ qui permet de spécifier un système de classification normalisé
pour les entités de construction (ou le
...
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...