Information container for linked document delivery — Exchange specification — Part 1: Container

This document defines an open and stable container format to exchange files of a heterogeneous nature to deliver, store and archive documents that describe an asset throughout its entire lifecycle. It is suitable for all parties dealing with information concerning the built environment, where there is a need to exchange multiple documents and their interrelationships, either as part of the process or as contracted deliverables. The format is intended to use resources either included in the container (such as documents) or referenced remotely (such as web resources). A key feature is that the container can include information about the relationships between the documents. Relevant use-cases reflect the need for information exchange during the entire life cycle of any built asset and can include, but are not limited to, the handover of - a published bidding package, - required project deliverables at a specific project stage (e.g. when proposing different design scenarios), - shared information as background or for further development, - published approval packages, or - information about versions between partners to provide a means to reference particular states of the information and track changes.

Conteneur d'informations pour la livraison de documents liés — Spécification d'échange — Partie 1: Conteneur

Le présent document définit un format de conteneur ouvert et fiable permettant d'échanger des fichiers de nature hétérogène afin de livrer, de stocker et d'archiver des documents qui décrivent un bien tout au long de son cycle de vie. Il est adapté à toutes les parties traitant d'informations relatives à l'environnement bâti, lorsqu'il est nécessaire d'échanger plusieurs documents et leurs relations mutuelles, soit dans le cadre d'un processus, soit en tant que livrables sous contrat. Le format est destiné à utiliser des ressources soit intégrées dans le conteneur (telles que des documents), soit référencées à distance (telles que des ressources Web). La possibilité d'inclure dans le conteneur des informations sur les relations entre les documents le composant, constitue une caractéristique majeure. Les cas d'utilisations pertinents témoignent de la nécessité d'échanger des informations tout au long du cycle de vie des biens bâtis et peuvent inclure, de manière non exhaustive, le transfert: - d'un dossier d'appel d'offres publié; - de livrables exigés à une étape spécifique d'un projet (p. ex. lors de la proposition de différents scénarios de conception); - d'informations à caractère général partagées ou destinées à un développement futur; - de dossiers d'approbation publiés; ou - d'informations sur les versions entre les partenaires pour fournir un moyen de référencer des états particuliers de l'information et le suivi des modifications.

General Information

Status
Published
Publication Date
13-Apr-2020
Current Stage
9093 - International Standard confirmed
Start Date
18-Sep-2025
Completion Date
07-Dec-2025
Ref Project

Relations

Standard
ISO 21597-1:2020 - Information container for linked document delivery — Exchange specification — Part 1: Container Released:4/14/2020
English language
41 pages
sale 15% off
Preview
sale 15% off
Preview
Standard
ISO 21597-1:2020 - Conteneur d'informations pour la livraison de documents liés — Spécification d'échange — Partie 1: Conteneur Released:4/14/2020
French language
42 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


INTERNATIONAL ISO
STANDARD 21597-1
First edition
2020-04
Information container for linked
document delivery — Exchange
specification —
Part 1:
Container
Conteneur d'informations pour la livraison de documents liés —
Spécification d'échange —
Partie 1: Conteneur
Reference number
©
ISO 2020
© ISO 2020
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3  Terms, definitions and abbreviated terms . 2
3.1 Terms and definitions . 2
3.2 Abbreviated Terms . 5
4  Specifications . 5
4.1 Use of RDF, RDFS and OWL constructs. 5
4.2 Symbols and notations . 7
4.3 Container structure .10
4.3.1 Overview .10
4.3.2 “Ontology resources” folder .11
4.3.3 “Payload documents” folder .11
4.3.4 “Payload triples” folder .11
4.4 Ontologies and datasets .12
4.4.1 Overview .12
4.4.2 Container ontology .12
4.4.3 Linkset ontology .16
4.4.4 Index dataset .20
4.4.5 Link dataset .20
4.5 Versioning.20
4.6 Additional properties in datasets .22
5 Conformance requirements .22
Annex A (informative) Use cases.24
Annex B (informative) Dublin Core interoperability .35
Annex C (informative) Bidirectional conversion of the ICDD container representation from
RDF(S)/OWL to XSD/XML .36
Annex D (informative) How to validate with SHACL .37
Annex E (normative) Ontologies .40
Bibliography .41
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 21597 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.
iv © ISO 2020 – All rights reserved

Introduction
The ISO 21597 series has been developed in response to a recognized need within the construction
industry to be able to handle multiple documents as one information delivery.
Information deliveries are often a combination of drawings, information models (representing built
or natural assets in the physical world), text documents, spreadsheets, photos, videos, audiofiles, etc.
Increasingly, this may also include datasets based on any ontology. An ability to specify relationships
using links between information elements in those separate documents can contribute significantly
to the value of an information delivery. The composition of such a package arises both from the
requirements of the process, e.g. delivery of as-built information, and from the specific functional
purpose e.g. performing a quantity take-off or communication about issues in 3D models.
In this document a specification is given for a container that stores documents, along with a means of
linking otherwise disconnected data within those documents.
The container format includes a header file and optional link files that define relationships by including
references to the documents, or to elements within them. The header file uniquely identifies the
container and its contractual or collaborative intention. This information is defined using the RDF,
RDFS and OWL semantic web standards.
The header file, along with any additional RDF(S)/OWL files or resources, forms a suite that may be
directly queried by software. The link references may be interpreted by the recipient applications or
reviewed interactively by the recipient. Where it includes link references into the content of documents
that don’t support standardized querying mechanisms, their resolution may depend on third party
interpreters.
The format can also be used to deliver multiple versions of the same document.
INTERNATIONAL STANDARD ISO 21597-1:2020(E)
Information container for linked document delivery —
Exchange specification —
Part 1:
Container
IMPORTANT — The electronic file of this document contains colours which are considered to be
useful for the correct understanding of the document. Users should therefore consider printing
this document using a colour printer.
1 Scope
This document defines an open and stable container format to exchange files of a heterogeneous nature
to deliver, store and archive documents that describe an asset throughout its entire lifecycle.
It is suitable for all parties dealing with information concerning the built environment, where there is
a need to exchange multiple documents and their interrelationships, either as part of the process or
as contracted deliverables. The format is intended to use resources either included in the container
(such as documents) or referenced remotely (such as web resources). A key feature is that the container
can include information about the relationships between the documents. Relevant use-cases reflect the
need for information exchange during the entire life cycle of any built asset and can include, but are not
limited to, the handover of
1. a published bidding package,
2. required project deliverables at a specific project stage (e.g. when proposing different design
scenarios),
3. shared information as background or for further development,
4. published approval packages, or
5. information about versions between partners to provide a means to reference particular states of
the information and track changes.
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/IEC 21320-1, Information technology — Document Container File — Part 1: Core.
IANA. Internet Assigned Numbers Authority Media Types. [viewed 6 May 2019]. Available from:
https:// www .iana .org/ assignments/ media -types/ media -types .xhtml
W3C-OWL2-SPEC. Motik B., Patel-Schneider P.F., Parsia B. eds. OWL 2 Web Ontology Language:
Structural Specification and Functional-Style Syntax (Second Edition). W3C Recommendation, 11
December 2012 [viewed July 22nd 2019]. Latest version available at http:// www .w3 .org/ TR/ owl2
-syntax/
W3C-RDF11-CONCEPTS. Cyganiak R., Wood D., Lanthaler M. RDF 1.1 Concepts and Abstract Syntax.
W3C Recommendation, 25 February 2014 [viewed July 22nd 2019]. Latest version available at http://
www .w3 .org/ TR/ rdf11 -concepts/
W3C-RDF11-SCHEMA. Brickley D., Guha R.V. RDF Schema 1.1. W3C Recommendation, 25 February
2014 [viewed July 22nd 2019]. Latest version available at http:// www .w3 .org/ TR/ rdf -schema/
W3C-RDF11-XML. Gandon F., Schreiber G. RDF 1.1 XML Syntax. W3C Recommendation, 25 February
2014 [viewed July 22nd 2019]. Latest version available at http:// www .w3 .org/ TR/ rdf -syntax -grammar/
W3C-XML-DATATYPES. Peterson D., Gao S., Malhotra A., Sperberg-McQueen C.M., Thompson
H.S. eds. (Version 1.1) and Biron P.V., Malhotra A. eds. (Version 1.0). W3C XML Schema Definition
Language (XSD) 1.1 Part 2: Datatypes. W3C Recommendation, 5 April 2012 [viewed July 22nd 2019].
Latest version available at http:// www .w3 .org/ TR/ xmlschema11 -2/
3  Terms, definitions and abbreviated terms
3.1  Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1.1
container
file that conforms to the ISO 21597 series
3.1.2
payload
primary information in the form of documents (3.1.3) that is included within the container (3.1.1)
Note 1 to entry: This does not include the header file (Index.rdf) or the ontology (3.1.7) resource (3.1.14) files.
3.1.3
document
fixed and structured amount of information that can be managed and interchanged as a unit between
users and systems
Note 1 to entry: This unit may not necessarily be human perceptible. Information is usually stored on a data medium.
Note 2 to entry: Used in the ISO 21597 series to refer to any document that forms part of the payload (3.1.2) in the
container, including any 2D or 3D models that represent built or natural assets in the physical world; these may
be held in any standard or proprietary format.
3.1.4
internal document
document (3.1.3) located within the container (3.1.1)
3.1.5
external document
document (3.1.3) located outside the container (3.1.1)
3.1.6
link
relation between documents (3.1.3), including between elements in documents
2 © ISO 2020 – All rights reserved

3.1.7
ontology
specification of concrete or abstract things, and the relationships among them, in a prescribed domain
of knowledge
Note 1 to entry: The specification should be computer processable.
Note 2 to entry: The definition is adapted from W3C-OWL2-SPEC.
3.1.8
container ontology
RDF(S)/OWL file providing the object (3.1.23) classes (3.1.15) and properties that shall be used to
specify the contents of a container (3.1.1)
3.1.9
linkset ontology
RDF(S)/OWL file providing the object (3.1.23) classes (3.1.15) and properties that shall be used to
specify links (3.1.6) between documents (3.1.3) in a container (3.1.1)
3.1.10
dataset
RDF(S)/OWL file that contains individuals (3.1.16) that comply with the classes (3.1.15) as specified by
ontologies (3.1.7)
3.1.11
index dataset
RDF(S)/OWL file containing an index of the contents of the container (3.1.1)
3.1.12
link dataset
RDF(S)/OWL file containing links (3.1.6) as defined in the ISO 21597 series
3.1.13
serialisation
encoding of an ontology (3.1.7) or dataset (3.1.10) into a format that can be stored, typically in a file
Note 1 to entry: The definition is adapted from W3C-RDF11-XML.
3.1.14
resource
something in the world (the "universe of discourse") denoted by an IRI or literal
Note 1 to entry: Anything can be a resource, including physical things, documents (3.1.3), abstract concepts,
numbers and strings; the term is synonymous with "entity" as it is used in the RDF Semantics specification.
Note 2 to entry: The definition is adapted from W3C-RDF11-CONCEPTS.
3.1.15
class
set of individuals (3.1.16) having the same characteristics
Note 1 to entry: The definition is adapted from W3C-RDF11-SCHEMA, 2.2.
3.1.16
individual
resource (3.1.14) that has been placed into any RDFS class (3.1.15) as an instance of that class
Note 1 to entry: Like RDF classes, every OWL class is associated with a set of individuals, called the class
extension; the individuals in the class extension are the instances of the class.
Note 2 to entry: There are two types of individuals in the syntax of OWL 2. Named individuals are given an
explicit name that can be used in any ontology (3.1.7) to refer to the same object (3.1.23). Anonymous individuals
do not have a global name and are thus local to the ontology in which they are contained.
Note 3 to entry: The definition is adapted from W3C-OWL2-SPEC, 5.6.
3.1.17
object property
OWL property that links individuals (3.1.16) to other individuals
Note 1 to entry: The definition is adapted from W3C-OWL2-SPEC, 5.3.
3.1.18
datatype property
OWL property that can relate individuals (3.1.16) to literals
Note 1 to entry: Literals can be strings, numbers, date types, etc.
Note 2 to entry: The definition is adapted from W3C-OWL2-SPEC, 5.4.
3.1.19
namespace
group of identifiers for elements and attributes that are collectively bound to a URI such that their use
will not cause naming conflicts
Note 1 to entry: The definition is adapted from W3C-RDF11-CONCEPTS, 1.
3.1.20
triple
statement in the form subject-predicate-object (3.1.21, 3.1.22, 3.1.23) that expresses a relationship
between two resources (3.1.14)
Note 1 to entry: The definition is adapted from W3C-RDF11-CONCEPTS, 3.1.
3.1.21
subject
resource (3.1.14) (an IRI) about which a statement is made in the form of an RDF triple (3.1.20)
Note 1 to entry: This term, as used in the ISO 21597 series, is part of the RDF(S)/OWL vocabulary, where each
triple consists of a subject, a predicate (3.1.22) and an object (3.1.23); a set of such triples is called an RDF graph.
Note 2 to entry: The definition is adapted from W3C-RDF11-SCHEMA, 5.3.2.
3.1.22
predicate
the relationship between a subject (3.1.21) and an object (3.1.23) in an RDF triple (3.1.20), also called a
property
Note 1 to entry: The definition is adapted from W3C-RDF11-SCHEMA, 5.3.3.
3.1.23
object
resource (3.1.14) (either an IRI or a literal) assigned as the specified property of the subject (3.1.21) in a
triple (3.1.20)
Note 1 to entry: This term, as used in the ISO 21597 series, is part of the RDF(S)/OWL vocabulary, where each
triple consists of a subject, a predicate (3.1.22) and an object; a set of such triples is called an RDF graph.
Note 2 to entry: The definition is adapted from W3C-RDF11-SCHEMA, 5.3.4.
4 © ISO 2020 – All rights reserved

3.2  Abbreviated Terms
DBF DataBase File
GIS Geographic Information System
GML Geography Markup Language
GUID Globally Unique Identifier
ICDD Information Container for linked Document delivery
IFC Industry Foundation Classes
IRI Internationalized Resource Identifier
OWL Web Ontology Language
RDF Resource Description Framework
RDFS Resource Description Framework Schema
SHACL Shapes Constraint Language
SPARQL Simple Protocol And RDF Query Language
SQL Structured Query Language
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
W3C World Wide Web Consortium
XML eXtensible Markup Language
XSD XML Schema Definition
XSLT Extensible Stylesheet Language Transformations
NOTE IRI is an update of the URI released in 2005; while URIs are limited to a subset of the ASCII character set,
IRIs can contain characters from the Universal Character Set (Unicode/ISO/IEC 10646). In the ISO 21597 series
URIs and IRIs are used interchangeably.
4  Specifications
4.1 Use of RDF, RDFS and OWL constructs
All ontologies held in containers that conform to the ISO 21597 series shall be based on the languages
RDF [W3C-RDF11-CONCEPTS], RDFS [W3C-RDF11-SCHEMA] and OWL [W3C-OWL2-SPEC] (referred to
collectively in the ISO 21597 series as RDF(S)/OWL) and shall be serialized in RDF/XML [W3C-RDF11-
XML] or any other equivalent RDF serialisation recommended by W3C.
It is expected that RDF(S)/OWL will be an important technology and a general platform for ontologies
for the coming decades. Proprietary systems will increasingly adopt RDF(S)/OWL. However, to make
the threshold for adoption of this document as low as possible, Annex C provides specifications to
support the conversion of a container from RDF(S)/OWL to XSD/XML and vice versa.
In general, when used in the context of the world wide web, these languages use the following principles
to support reasoning:
— Open world assumption - the truth of a statement is independent of whether it is known. In other
words, not knowing that a statement is explicitly true does not imply that the statement is false.
— No unique names assumption - unless explicitly stated otherwise, it cannot be assumed that
resources that are identified by different URIs are different.
The datasets that comply with the ontologies specified in the ISO 21597 series shall use the following
interpretation of RDF(S)/OWL:
— Closed world assumption - a statement that is true is also known to be true; therefore, conversely,
what is not formally specified in a container to be true, is false.
— Unique naming assumption - resources in a container that are identified with different URIs are
considered to be different, unless explicitly declared as the same (using the owl: sameAs predicate).
Table 1 lists the RDF(S)/OWL constructs that are used in the ISO 21597 series and the interpretation to
be used when validating the contents of a container. It is noted that, once the contents of the container
has been validated, the data can be used in an open world context.
Table 1 — Listing of constructs used in the ISO 21597 series and their interpretation
Construct Interpretation
owl: Class In a dataset within a container, class membership
for every individual shall be explicitly asserted,
unless implicitly inferred using predicates such
as rdfs:s ubClassOf [W3C-RDF11-SCHEMA, 3.4]
or owl: equivalentClass [W3C-OWL2-SPEC, 9.1.2].
rdfs: subClassOf The ISO 21597 series does not deviate from the W3C
definitions [W3C-RDF11-SCHEMA]. Statements that
rdfs: subPropertyOf
may be inferred due to
rdfs: subClassOf or rdfs: subPropertyOf statements shall
be regarded as true even if not explicitly asserted.
NOTE  Statements where a class is mentioned are also
true for any of its subclasses. Similarly, statements
where a property is mentioned are also true for any of
its sub properties.
owl: FunctionalProperty The ISO 21597 series interprets
owl: FunctionalProperty as a property with a
maximum cardinality of 1.
[W3C-OWL2-SPEC, 9.2.4]
owl: InverseFunctionalProperty The ISO 21597 series interprets
owl: InverseFunctionalProperty as an inverse
property with a maximum cardinality of 1.
[W3C-OWL2-SPEC, 9.2.7]
owl: equivalentClass The ISO 21597 series does not deviate from the W3C
definitions [W3C-OWL2-SPEC, 9.1.2]. Statements that
may be inferred due to owl: equivalentClass
statements shall be regarded as true even if not
explicitly asserted.
rdfs: range These statements shall be interpreted as restrictions.
It is invalid to have a subject or object of a statement
r df s: domain
(triple) in a dataset where that individual is a member
of a class that does not comply with the rdfs: range or
r df s: domain declarations of the corresponding
owl: ObjectProperty [W3C-OWL2-SPEC, 5.3] or
owl: DatatypeProperty [W3C-OWL2-SPEC, 5.4]
6 © ISO 2020 – All rights reserved

Table 1 (continued)
Construct Interpretation
owl: restriction These statements shall be interpreted as restrictions.
Any deviation from the specified restriction within a
owl: onProperty
single container is considered invalid.
owl: allValuesFrom
NOTE  As an example, if owl: cardinality is defined as 2,
owl: someValuesFrom then a dataset that does not contain exactly 2
occurrences is not valid.
owl: hasValue
owl: cardinality
owl: minCardinality
owl: maxCardinality
owl: inverseOf The ISO 21597 series does not deviate from the W3C
definitions [W3C-OWL2-SPEC, 9.2.4]. It is
recommended that inverse properties are not
asserted for individuals in a dataset. If they are
asserted, they shall not contradict the assertions
made in the opposite direction.
owl: disjointUnionOf The expression shall be interpreted as a constraint
where the subject is considered to be an abstract class
in the sense that any individual member of the subject
class shall also be a member of one (and only one) of
the disjoint classes enumerated in the object part of the
owl: disjointUnionOf statement. [W3C-OWL2-SPEC, 9.1.4]
4.2  Symbols and notations
Throughout the ISO 21597 series, the structure of the ontologies is illustrated using a UML notation.
The purpose of this subclause is to describe that notation and the meaning of the terms and symbols
that are used.
Tables 2 and 3 list the namespaces and corresponding prefixes used in the ISO 21597 series.
Table 2 — Namespaces and prefixes used in ontologies defined in the ISO 21597 series
Ontology Prefix Namespace
Container ontology ct https:// standards .iso .org/ iso/ 21597/ -1/ ed -1/ en/ Container
Linkset ontology ls https:// standards .iso .org/ iso/ 21597/ -1/ ed -1/ en/ Linkset
Table 3 — Namespaces and prefixes used in ontologies referenced in the ISO 21597 series
Ontology Prefix Namespace
XML Schema xsd https:// www .w3 .org/ 2001/ XMLSchema
Resource Description rdf
https:// www .w3 .org/ 1999/ 02/ 22 -rdf -syntax -ns
Framework
RDF Schema rdfs https:// www .w3 .org/ 2000/ 01/ rdf -schema
Web Ontology owl https:// www .w3 .org/ 2002/ 07/ owl
Language
Figure 1 illustrates the UML notations used in the ISO 21597 series to render classes and properties.
Figure 1 — UML notation for classes and properties
A class (owl: Class) is illustrated by a rectangular box with two compartments as shown in Figure 1. In
the upper compartment, the class name (“ex: Class” in Figure 1) is displayed. Note that the class name
is shown following the pattern “prefix: ClassName”, where the prefix (“ex” in the example) denotes
namespace of the ontology and “ClassName” is the name of the class. The prefixes actually used in the
ISO 21597 series are defined in Tables 2 and 3.
The lower compartment shows the specified properties for that class. There are two general types of
properties:
— Datatype properties are those for which the value is a data literal, as illustrated for ex: AnotherClass
in Figure 1; and
— Object properties, for which the value is an individual; e.g. ex: Class in Figure 1, where the property
ex: ObjectProperty _1 references an individual of class ex: AnotherClass.
The property definitions are shown according to the pattern “prefix: propertyName: range[cardinality]”.
The range of a datatype property shall be based on one of the predefined data types in XML schema
[W3C-XML-DATATYPES]. The range of an object property is usually one of the classes occurring in the
ontology but may also refer to a class in another ontology.
If classes on both sides (domain and range) of an object property are visible in a diagram, the object
property may also be illustrated with an (blue) arrow between the classes pointing from the domain
class towards the range class (as shown in Figure 1). The name of the object property is displayed along
the arrow as well as in the property compartment of the class box as explained above.
Any cardinality restrictions are displayed within square brackets using the following notation:
[minCardinality.maxCardinality], where minCardinality specifies the minimum allowed occurrences and
maxCardinality specifies the maximum allowed number of occurrences
The cardinality restrictions shall be interpreted in the following fashion:
— omitted - no cardinality restriction exists, i.e. any number of occurrences from zero to many are
allowed;
— maxCardinality omitted (e.g. [0.], [1.] etc) - maximum cardinality is unrestricted.
If two classes are related using an rdfs:s ubClassOf predicate, this is rendered using an arrow as shown
in Figure 2. This diagram illustrates that ex: SubClass and ex: Class are related using an rdfs:s ubClassOf
predicate.
8 © ISO 2020 – All rights reserved

Figure 2 — Depiction of a sub-class relationship
Disjoint classes are illustrated in Figure 3.
Figure 3 — Depiction of disjoint classes
The red arrow pointing from ex: Class1 to ex: Class2 declares that they are disjoint, meaning that an
instance is not allowed to be a member of both ex: Class1 and ex:C lass2. This is declared with an owl:
disjointUnionOf statement (ex: Class1 owl: disjointUnionOf ex: Class2). The owl: disjointUnionOf property is
symmetric, meaning that if Class1 is disjoint with Class2, then Class2 is also disjoint with Class1.
Two classes which are declared as equivalent by the use of owl: equivalentClass (e.g. ex: Class3 owl:
equivalentClass ex: Class4) are depicted as shown in Figure 4.
Figure 4 — Depiction of equivalent classes
Finally, a class may be both the Domain and Range for a certain ObjectProperty. Such a relationship is
rendered as shown in Figure 5, i.e. with the little arrow aligned to the bottom of the class box without
any label attached to the arrow.
Figure 5 — Depiction of an ObjectProperty defined by an individual of the same class
4.3 Container structure
4.3.1 Overview
A container is a file that shall have an extension “.icdd” and shall comply with ISO/IEC 21320-1 also
known as ZIP64.
A container includes a header file in the top-level folder; this file shall comply with the RDF(S)/
OWL standards and shall be serialized in RDF/XML [W3C-RDF11-XML] or any other equivalent RDF
serialisation recommended by W3C. The name of this header file is Index.rdf.
As a minimum, a container shall have at least three folders as illustrated in Figure 6. The purpose of
these top-level folders is explained in the following subclauses. The “Payload documents” folder and
“Payload triples” folder may contain nested folders to allow groups of associated digital resources to be
held together and referenced as a group (e.g. a building information model with its associated reference
files or a set of linked spreadsheets).
Figure 6 — Minimum structure of the root of a container
Figure 7 shows the hierarchy of folders and files within a container.
10 © ISO 2020 – All rights reserved

Figure 7 — Hierarchy of folders and files in a container
4.3.2 “Ontology resources” folder
The “Ontology resources” folder can be used to store the Linkset.rdf and Container.rdf ontologies that
together provide the object classes and properties that shall be used to specify the contents of and
links between the documents within the container. These ontologies shall be serialized in the RDF/
XML format [W3C-RDF11-XML] or any other equivalent RDF serialisation recommended by W3C. Since
they are both available as downloadable files (and therefore can be referenced as resources held locally
but external to the container), it is not mandatory to include them here, but if included, the files in this
folder shall take precedence.
4.3.3 “Payload documents” folder
The “Payload documents” folder shall be used for storing all the documents that are included in the
container (referred to as the payload). Sub-folders are allowed.
4.3.4 “Payload triples” folder
The “Payload triples” folder shall be used for storing Linkset files and may include sub-folders.
4.4 Ontologies and datasets
4.4.1 Overview
Using RDF(S)/OWL technology, the object classes and properties that are used to specify the contents
of and links between the documents within the container is specified within the container using two
ontologies:
— Container ontology, available online via https:// standards. iso .org/ iso/ 21597/ -1/ ed -1/ en/
Container .rdf.
— Linkset ontology, available online via https:// standards .iso .org/ iso/ 21597/ -1/ ed -1/ en/ Linkset .rdf.
As noted previously, these ontologies can be included in the container in the “Ontology resources” folder
to create a self-contained container that may be used off-line or for archiving purposes. Since these
ontologies conform to the ISO 21597 series, they shall not be modified in any way.
In addition, the container shall include RDF(S)/OWL datasets that describe the contents of the container
and the links between those documents. We distinguish two types of datasets. First, the container shall
include one Index dataset, called Index.rdf and held in the root of the container; it is used to describe the
container and to specify the documents that make up its contents. Second, the container may include
zero or more Link datasets, used to specify the link relationships among documents. All such datasets
shall reference the Container and Linkset ontologies in Annex E.
The Container and Linkset ontologies are described in 4.4.2 and 4.4.3. The two types of dataset
described in the previous paragraph are then described in 4.4.4 and 4.4.5 respectively.
4.4.2 Container ontology
The Container ontology is an RDF(S)/OWL file containing definitions of the classes and properties used
in an Index dataset, providing metadata about the container.
The Index dataset enables the specification of:
— version of ICDD standard via the import of the reference ontology;
— list of external documents with metadata:
— mandatory file name (including a URI or IRI);
— optional format;
— optional description;
— list of internal documents with metadata:
— mandatory file name (including its path in the container folder structure);
— optional format;
— optional description;
— reference to Link datasets.
Tables 4, 5 and 6 list the objects, datatype properties and object properties respectively that are used in
the Container ontology, providing brief descriptions of each.
12 © ISO 2020 – All rights reserved

Table 4 — Classes defined in the Container ontology
Object name Description
ct: ContainerDescription A description for a container where all documents are listed and where Link
datasets can be found. There shall be exactly one ct: ContainerDescription
instance in any container.
ct:E ncryptedDocument A reference to an encrypted document.
ct:E xternalDocument A reference to a document outside a container.
ct:I nternalDocument A reference to a document inside a container.
ct: Linkset A reference to an RDF(S)/OWL file containing links.
ct:D ocument An abstract class for references to a document; an individual shall be a member of
ct:E xternalDocument or ct: InternalDocument; and optionally, individuals may also
be a member of other subtypes of ct: Document such as ct: SecuredDocument and/or
ct:E ncryptedDocument.
ct: SecuredDocument A document secured by a checksum algorithm (see also properties ct: checksum and
ct: checksumAlgorithm).
ct: FolderDocument A document comprising multiple files located in one folder, such as a GIS
dataset consisting SHP files with associated DBF files.
ct: Party An abstract class that represents the generalization of a ct: Organisation or a
ct: Pe r s on; entities can refer to an individual of a subclass of ct: Party via the
ct: c r e at or, ct: modifier or ct: publisher object properties.
ct: Pe r s on A class representing a person for provenance purposes.
ct: Organisation A class representing an organization for provenance purposes.
Table 5 — Datatype properties used in the Container ontology
Datatype name Description
ct: checksum A checksum hash for the document reference; the checksum algorithm
is specified by the property ct: checksumAlgorithm.
ct: checksumAlgorithm The algorithm used to generate the checksum hash.
ct: conformanceIndicator A string-based indicator for ct: ContainerDescription to show to which
part of the ISO 21597 series this container conforms: for a
Part 1 container, the value should be set to "ICDD-Part1-Container"; the
range is not restricted to allow other indicator values.
ct: creationDate The creation date as xsd: dateTime.
c t : de s c r ipt ion A general description.
ct: encryptionAlgorithm Optional string describing the encryption.
ct: filename The file name of a ct: Linkset or ct: InternalDocument; the root corresponds with
the “Payload documents” folder of the ICDD container; the forward slash char-
acter ("/") shall be used as a folder separator.
NOTE  An example of a ct: filename is “IFC Models/MyFile_1.ifc” which
refers to the file MyFile_1.ifc inside the folder IFC Models inside the
“Payload documents” folder in the container.
c t : f olde r name A folder name for specifying a folder where a multi file document can be
found; the root corresponds with the “Payload documents” folder of the
ICDD container; the forward slash character ("/") shall be used as a
folder separator.
NOTE An example of a c t : f olde r name is “GIS Datasets/Terrain” which
refers to the folder Terrain inside folder GIS Datasets inside the “Payload docu-
ments” folder in the container.
ct: filetype A string that specifies the file type such as "GML", "IFC", "shp", "xlsx",
"pdf","rvt"; the string may be a compound string to indicate version and
data format (e.g. “ifc-4-xml-zip”).
Table 5 (continued)
Datatype name Description
ct: f or mat The media-type of a document shall follow the specification by the
Internet Assigned Numbers Authority [IANA]; examples are
“application/pdf” and “audio/mpeg”.
ct: modificationDate The modification date as xsd: dateTime.
c t : name A name for a document.
NOTE  An example of a c t : name is “D101”.
ct: requested A boolean to indicate whether a document is required or not; when this
property is not set the value can be interpreted as “false”.
c t : url The URL where the external document can be found.
ct: userID The user defined identifier.
ct: versionDescription An optional character string that may be used to provide a description for a
version of the corresponding resource.
ct: versionID An optional character string that may be used to identify a version of the
corresponding resource.
Table 6 — Object properties used in the Container ontology
Object property Description
name
ct: createdBy A reference to a creator of this instance which can only be a subclass of
ct: Party.
Inverse property: c t : c r e at ed.
ct: modifiedBy A reference to the modifier of this instance which can only be a subclass of
ct: Party.
Inverse property: ct: modified.
ct: publishedBy The party responsible for making the container available.
Inverse property: ct: published.
ct: alternativeDocument A property to link a document to an alternative version of that document.
Inverse property: ct: alternativeTo.
ct: belongsToContainer An owl property defining the relation between a document reference and a
container.
ct: containsLinkset A relation from a ct: ContainerDescription to a ct: Linkset reference. Multiple
linkset references are allowed.
Inverse property: ct: containedInContainer.
ct: containsDocument A relation from ct: ContainerDescription to a document reference. Relations
to multiple document references are allowed.
ct: priorVersion An optional reference to the prior version of this resource.
Inverse property: ct: nextVersion.
Figure 8 illustrates the context of the Container ontology, showing the structure of a container and
the meta-information associated with it. The ct: ContainerDescription class is a subclass of the owl:
Ontology class (more information on owl: Ontology can be found in section 3 of the OWL 2 Web Ontology
Language Structural Specification and Functional-Style Syntax [W3C-OWL2-SPEC]). Each ontology is
an individual that is a member of the owl: Ontology.
The Index dataset of a container declares an individual that is a type of ct: ContainerDescription and thus
also a member of the class owl: Ontology. The IRI or URI of this individual is used as the identifier for the
Index dataset and consequently can be used to identify the container. The Index dataset imports the
Container ontology via owl: imports property, so that the individual inherits a c t : de s c r ipt ion property
and mandatory ct: publisher object property referring to a ct: Party. It also refers to individuals of
14 © ISO 2020 – All rights reserved

classes ct: Linkset and ct: Document via the object properties ct: containsLinkset and ct: containsDocument
respectively, in that way defining the structure of the container.
Figure 8 — c t : C ont aine rD e s c r ipt ion context
Figure 9 illustrates the properties and sub-classes of documents supported in a container that conforms
to the ISO 21597 series. All documents shall have a ct: name and optionally ct: filetype, ct: for mat and ct:
requested properties (the latter being a boolean to indicate that the document is requested from the
recipient of the container). Individuals of class ct: Document shall be typed as either a ct:I nternalDocument
or ct:E xternalDocument (enforced by an owl: disjointUnionOf statement interpreted as a restriction). The
figure shows additional subclasses of ct:D ocu
...


NORME ISO
INTERNATIONALE 21597-1
Première édition
2020-04
Conteneur d'informations pour
la livraison de documents liés —
Spécification d'échange —
Partie 1:
Conteneur
Information container for linked document delivery — Exchange
specification —
Part 1: Container
Numéro de référence
©
ISO 2020
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
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
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2020 – Tous droits réservés

Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes, définitions et abréviations . 2
3.1 Termes et définitions . 2
3.2 Abréviations . 5
4 Spécifications . 6
4.1 Utilisation des concepts RDF, RDFS et OWL . 6
4.2 Symboles et notations . 7
4.3 Structure du conteneur.10
4.3.1 Vue d’ensemble .10
4.3.2 Dossier «Ontology resources» .11
4.3.3 Dossier «Payload documents» .11
4.3.4 Dossier «Payload triples» .11
4.4 Ontologies et ensembles de données .12
4.4.1 Vue d’ensemble .12
4.4.2 Ontologie conteneur .12
4.4.3 Ontologie liens .16
4.4.4 Ensemble de données d’index .20
4.4.5 Ensemble de données de lien.20
4.5 Contrôle de version .20
4.6 Propriétés supplémentaires des ensembles de données .22
5 Exigences de conformité.22
Annexe A (informative) Cas d’utilisation .24
Annexe B (informative) Interopérabilité avec le Dublin Core .36
Annexe C (informative) Conversion bidirectionnelle de la représentation du conteneur
ICDD entre RDF(S)/OWL et XSD/XML . .37
Annexe D (informative) Comment valider avec SHACL .38
Annexe E (normative) Ontologies .41
Bibliographie .42
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 www .iso .org/ avant -propos.
Le comité chargé de l’élaboration du présent document est l’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é européen de normalisation (CEN) Comité technique CEN/TC 442, Modélisation des
informations de la construction (BIM), 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 21597 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.
iv © ISO 2020 – Tous droits réservés

Introduction
La série ISO 21597 a été développée en réponse au besoin de l’industrie de la construction de délivrer
plusieurs documents sous la forme d’une seule livraison d’informations.
Les livraisons d’informations sont souvent constituées d’une combinaison de plans, de modèles
d’information (représentant des éléments bâtis ou naturels de l’environnement physique), de documents
textes, de feuilles de calcul, etc. Cela peut également inclure de plus en plus souvent des ensembles
de données basés sur une ontologie ou une autre. La possibilité de spécifier des relations entre des
éléments d’information présents dans ces documents différents peut contribuer à accroître la valeur
d’une livraison d’informations. La composition d’un tel paquet (ou conteneur) découle à la fois des
exigences du processus (par exemple la livraison d’informations conformes à l’exécution) et de l’objectif
fonctionnel spécifique (par exemple l’exécution d’un devis quantitatif ou la communication d’aspects
relatifs aux modèles 3D).
Le présent document fournit la spécification d’un conteneur qui permet de regrouper des documents,
ainsi que des méthodes permettant de relier des données par ailleurs disjointes au sein de ces
documents.
Le format de conteneur comprend un fichier d’en-tête et des fichiers de liens facultatifs qui définissent
les relations en incluant des références aux documents ou à des éléments qu’ils contiennent. Le
fichier d’en-tête définit de manière unique le conteneur et son objet contractuel ou collaboratif. Ces
informations sont définies au moyen des normes du Web sémantique RDF, RDFS et OWL.
Le fichier d’en-tête, ainsi que tout fichier RDF(S)/OWL ou ressource supplémentaire, forme un ensemble
qui peut être directement interrogé par un logiciel au moyen de requêtes. Les références de liens
peuvent être interprétées par les applications destinataires ou examinées de façon interactive par
le destinataire. Lorsqu’il inclut des références de liens vers le contenu de documents qui ne prennent
pas en charge les mécanismes de requête normalisés, la résolution de ces requêtes peut dépendre
d’interprétations de la part de tierces parties.
Le format peut également être utilisé pour livrer plusieurs versions du même document.
NORME INTERNATIONALE ISO 21597-1:2020(F)
Conteneur d'informations pour la livraison de documents
liés — Spécification d'échange —
Partie 1:
Conteneur
IMPORTANT — Le fichier électronique du présent document contient des couleurs qui sont
jugées utiles pour la bonne compréhension du document. Il convient donc aux utilisateurs de
considérer l'emploi d'une imprimante couleur pour l'impression du présent document.
1 Domaine d’application
Le présent document définit un format de conteneur ouvert et fiable permettant d’échanger des fichiers
de nature hétérogène afin de livrer, de stocker et d’archiver des documents qui décrivent un bien tout
au long de son cycle de vie.
Il est adapté à toutes les parties traitant d’informations relatives à l’environnement bâti, lorsqu’il
est nécessaire d’échanger plusieurs documents et leurs relations mutuelles, soit dans le cadre d’un
processus, soit en tant que livrables sous contrat. Le format est destiné à utiliser des ressources soit
intégrées dans le conteneur (telles que des documents), soit référencées à distance (telles que des
ressources Web). La possibilité d’inclure dans le conteneur des informations sur les relations entre
les documents le composant, constitue une caractéristique majeure. Les cas d’utilisations pertinents
témoignent de la nécessité d’échanger des informations tout au long du cycle de vie des biens bâtis et
peuvent inclure, de manière non exhaustive, le transfert:
1. d’un dossier d’appel d’offres publié;
2. de livrables exigés à une étape spécifique d’un projet (p. ex. lors de la proposition de différents
scénarios de conception);
3. d’informations à caractère général partagées ou destinées à un développement futur;
4. de dossiers d’approbation publiés; ou
5. d’informations sur les versions entre les partenaires pour fournir un moyen de référencer des états
particuliers de l’information et le suivi des modifications.
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/IEC 21320-1, Technologies de l'information — Fichier conteneur de document — Partie 1: Données de
base
IANA. Internet Assigned Numbers Authority. Media Types. [vu le 6 mai 2019]. Disponible à l’adresse:
https:// www .iana .org/ assignments/ media -types/ media -types .xhtml.
W3C-OWL2-SPEC. Motik B., Patel-Schneider P.F., Parsia B., eds. OWL 2 Web Ontology Language:
Structural Specification and Functional-Style Syntax (Seconde Édition). Recommandation du W3C,
11 décembre 2012 [vu le 22 juillet 2019]. Dernière version disponible sur http:// www .w3 .org/ TR/ owl2
-syntax/ .
W3C-RDF11-CONCEPTS. Cyganiak R., Wood D., Lanthaler M. RDF 1.1 Concepts and Abstract Syntax.
Recommandation du W3C, 25 février 2014 [vu le 22 juillet 2019]. Dernière version disponible sur http://
www .w3 .org/ TR/ rdf11 -concepts/ .
W3C-RDF11-SCHEMA. Brickley D., Guha R.V. RDF Schema 1.1. Recommandation du W3C, 25 février 2014
[vu le 22 juillet 2019]. Dernière version disponible sur http:// www .w3 .org/ TR/ rdf -schema/ .
W3C-RDF11-XML. Gandon F., Schreiber G. RDF 1.1 XML Syntax. Recommandation du W3C,
25 février 2014 [vu le 22 juillet 2019]. Dernière version disponible sur http:// www .w3 .org/ TR/ rdf
-syntax -grammar/ .
W3C-XML-DATATYPES. Peterson D. Gao S., Malhotra A., Sperberg-McQueen C.M., and Thompson
H.S., eds. (Version 1.1) and Biron P.V., and Malhotra A., eds. (Version 1.0). W3C XML Schema Definition
Language (XSD) 1.1 Part 2: Datatypes. Recommandation du W3C, 5 avril 2012 [vu le 22 juillet 2019].
Dernière version disponible sur http:// www .w3 .org/ TR/ xmlschema11 -2/ .
3 Termes, définitions et abréviations
3.1 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 http:// www .electropedia .org/
3.1.1
conteneur
fichier conforme à la série ISO 21597
3.1.2
données utiles
informations principales sous forme de documents (3.1.3) incluses dans le conteneur (3.1.1)
Note 1 à l'article: Cette définition exclut le fichier d’en-tête (Index.rdf) ou les fichiers ontologie (3.1.7) et ressource
(3.1.14).
3.1.3
document
quantité d’informations fixe et structurée qui peut être gérée et échangée d’un seul bloc entre des
utilisateurs et des systèmes
Note 1 à l'article: Ce bloc n’est pas nécessairement perceptible par l’homme. Les informations sont généralement
stockées sur un support de données.
Note 2 à l'article: Ce terme est utilisé dans la série ISO 21597 pour désigner tout document faisant partie des
données utiles (3.1.2) du conteneur, y compris tout modèle 2D ou 3D représentant des éléments bâtis ou naturels
dans l’environnement physique; ceux-ci peuvent être fournis sous tout format, normalisé ou propriétaire.
3.1.4
document interne
document (3.1.3) situé à l’intérieur du conteneur (3.1.1)
3.1.5
document externe
document (3.1.3) situé à l’extérieur du conteneur (3.1.1)
2 © ISO 2020 – Tous droits réservés

3.1.6
lien
relation entre des documents (3.1.3), y compris entre des éléments contenus dans les documents
3.1.7
ontologie
spécification de choses concrètes ou abstraites, et des relations entre elles, dans un domaine de
connaissances donné
Note 1 à l'article: Il convient que la spécification puisse être traitée par ordinateur.
Note 2 à l'article: La définition est adaptée de la Recommandation W3C-OWL2-SPEC.
3.1.8
ontologie conteneur
fichier RDF(S)/OWL fournissant les classes (3.1.15) d’objet (3.1.23) et les propriétés qui doivent être
utilisées pour spécifier le contenu d’un conteneur (3.1.1)
3.1.9
ontologie liens
fichier RDF(S)/OWL fournissant les classes (3.1.15) d’objet (3.1.23) et les propriétés qui doivent être
utilisées pour spécifier les liens (3.1.6) entre les documents (3.1.3) contenus dans un conteneur (3.1.1)
3.1.10
ensemble de données
fichier RDF(S)/OWL qui contient les individus (3.1.16) conformes aux classes (3.1.15) comme spécifié
par les ontologies (3.1.7)
3.1.11
ensemble de données d’index
fichier RDF(S)/OWL contenant un index du contenu du conteneur (3.1.1)
3.1.12
ensemble de données de lien
fichier RDF(S)/OWL contenant des liens (3.1.6) tels que définis dans la série ISO 21597
3.1.13
sérialisation
codage d’une ontologie (3.1.7) ou d’un ensemble de données (3.1.10) en un format qui peut être stocké,
généralement dans un fichier
Note 1 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-XML.
3.1.14
ressource
chose dans le monde (l’«univers des échanges») indiquée par un IRI ou une valeur littérale
Note 1 à l'article: Tout peut être une ressource, y compris les objets physiques, les documents (3.1.3), les concepts
abstraits, les nombres et les chaînes de caractères; le terme est synonyme du terme «entité» tel qu’il est utilisé
dans la spécification sémantique RDF.
Note 2 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-CONCEPTS.
3.1.15
classe
ensemble d’individus (3.1.16) présentant les mêmes caractéristiques
Note 1 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-SCHEMA, 2.2 .
3.1.16
individu
ressource (3.1.14) qui a été placée dans une quelconque classe (3.1.15) RDFS en tant qu’instance de
cette classe
Note 1 à l'article: Comme pour les classes RDF, chaque classe OWL est associée à un ensemble d’individus appelé
«extension de classe». Les individus dans l’extension de classe sont appelés des instances de la classe.
Note 2 à l'article: Il existe deux types d’individus dans la syntaxe de OWL 2. Les individus nommés se voient
donner un nom explicite qui peut être utilisé dans toute ontologie (3.1.7) pour se référer au même objet (3.1.23).
Les individus anonymes n’ont pas de nom général et sont donc locaux à l’ontologie qui les contient.
Note 3 à l'article: La définition est adaptée de la Recommandation W3C-OWL2-SPEC, 5.6 .
3.1.17
propriété d’objet
propriété OWL qui lie des individus (3.1.16) à d’autres individus
Note 1 à l'article: La définition est adaptée de la Recommandation W3C-OWL2-SPEC, 5.3 .
3.1.18
propriété de types de données
propriété OWL qui peut associer des individus (3.1.16) à des valeurs littérales
Note 1 à l'article: Les valeurs littérales peuvent être des chaînes de caractères, des nombres, des types de
données, etc.
Note 2 à l'article: La définition est adaptée de la Recommandation W3C-OWL2-SPEC, 5.4 .
3.1.19
espace de noms
groupe d’identifiants pour des éléments et des attributs qui sont collectivement liés à un URI de sorte
que leur utilisation n’entraîne aucun conflit de nommage
Note 1 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-CONCEPTS, 1.
3.1.20
triple
énoncé sous la forme sujet-prédicat-objet (3.1.21, 3.1.22, 3.1.23) qui exprime une relation entre deux
ressources (3.1.14)
Note 1 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-CONCEPTS, 3.1.
3.1.21
sujet
ressource (3.1.14) (un IRI) à propos de laquelle un énoncé est formulé sous la forme d’un triple (3.1.20) RDF
Note 1 à l'article: Ce terme, tel qu’utilisé dans la série ISO 21597, fait partie du vocabulaire RDF(S)/OWL, chaque
triple étant constitué d’un sujet, d’un prédicat (3.1.22) et d’un objet (3.1.23). Un ensemble de triples constitue un
graphe RDF.
Note 2 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-SCHEMA, 5.3.2 .
3.1.22
prédicat
indique la relation entre un sujet (3.1.21) et un objet (3.1.23) dans un triple (3.1.20) RDF, également
appelé «propriété»
Note 1 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-SCHEMA, 5.3.3 .
4 © ISO 2020 – Tous droits réservés

3.1.23
objet
ressource (3.1.14) (un IRI ou une valeur littérale) allouée en tant que valeur de propriété du sujet (3.1.21)
dans un triple (3.1.20)
Note 1 à l'article: Ce terme, tel qu’utilisé dans la série ISO 21597, fait partie du vocabulaire RDF(S)/OWL, chaque
triple étant constitué d’un sujet, d’un prédicat (3.1.22) et d’un objet. Un ensemble de triples constitue un graphe RDF.
Note 2 à l'article: La définition est adaptée de la Recommandation W3C-RDF11-SCHEMA, 5.3.4 .
3.2 Abréviations
DBF Fichier de base de données (DataBase File)
SIG Système d’Informations Géographiques
GML Langage de balisage géographique (Geography Markup Language)
GUID Identifiant globalement unique (Globally Unique Identifier)
ICDD Conteneur d’information pour la livraison de documents liés (Information Container for
linked Document delivery)
IFC Classes de fondation d’industrie (Industry Foundation Classes)
IRI Identifiant de ressource au format international (Internationalized Resource Identifier)
OWL Langage d’ontologie du Web (Web Ontology Language)
RDF Cadre de description de ressource (Resource Description Framework)
RDFS Schéma de cadre de description de ressource (Resource Description Framework Schema)
SHACL Langage SHACL (Shapes Constraint Language)
SPARQL Protocole et langage de requêtes RDF SPARQL (SPARQL Protocol Et RDF Query Language)
SQL Langage SQL (Structured Query Language)
UML Langage UML (Unified Modeling Language)
URI Identifiant de ressource uniforme (Uniform Resource Identifier)
URL Localisateur uniforme de ressource (Uniform Resource Locator)
W3C Consortium du World Wide Web
XML Langage de balisage extensible (eXtensible Markup Language)
XSD Définition du schéma XML (XML Schema Definition)
XSLT Langage XSLT (Extensible Stylesheet Language Transformations)
NOTE L’IRI est une mise à jour de l’URI publiée en 2005. Les URI sont limités à un sous-ensemble de caractères
ASCII. Les IRI peuvent contenir des caractères du jeu de caractères universel (Unicode/ISO/IEC 10646). Dans la
série ISO 21597, les URI et les IRI sont utilisés de façon interchangeable.
4 Spécifications
4.1 Utilisation des concepts RDF, RDFS et OWL
Toutes les ontologies contenues dans des conteneurs conformes à la série ISO 21597 doivent être basées
sur les langages RDF [W3C-RDF11-CONCEPTS], RDFS [W3C-RDF11-SCHEMA] et OWL [W3C-OWL2-
SPEC] (appelés collectivement RDF(S)/OWL dans la série ISO 21597) et doivent être sérialisées en RDF/
XML [W3C-RDF11-XML] ou toute autre sérialisation RDF équivalente recommandée par le W3C.
Il est attendu que RDF(S)/OWL devienne une technologie importante et une approche générique pour
la manipulation des ontologies dans les décennies à venir. Les systèmes propriétaires vont de plus en
plus adopter RDF(S)/OWL. Toutefois, afin de rendre le seuil d’adoption du présent document aussi bas
que possible, l’Annexe C inclut des spécifications permettant de prendre en charge la conversion d’un
conteneur de RDF(S)/OWL à XSD/XML et vice versa.
De manière générale, lorsqu’ils sont utilisés dans le contexte du web, ces langages utilisent les principes
suivants pour étayer leur raisonnement:
— Hypothèse de monde ouvert - la vérité d’un énoncé est indépendante du fait qu’il soit ou non connu.
En d’autres termes, ne pas savoir qu’un énoncé est explicitement vrai n’implique pas qu’il soit faux;
— Hypothèse d’absence de noms uniques - sauf mention contraire explicite, il est impossible de
supposer que des ressources identifiées par des URI différents sont différentes.
Les ensembles de données conformes aux ontologies spécifiées dans la série ISO 21597 doivent utiliser
l’interprétation suivante des langages RDF(S) et OWL:
— Hypothèse de monde fermé - un énoncé qui est vrai est également connu comme étant vrai. Par
conséquent, à l’inverse, dans un conteneur, ce qui n’est pas formellement spécifié comme étant vrai
est considéré faux;
— Hypothèse de nom unique - dans un conteneur, les ressources identifiées par des URI différents
sont considérées comme différentes, sauf si elles sont explicitement déclarées comme identiques (au
moyen du prédicat owl: s ame A s).
Le Tableau 1 énumère les concepts RDF(S)/OWL utilisés dans la série ISO 21597 et l’interprétation
à utiliser pour valider le contenu d’un conteneur. Il est à noter que, une fois le contenu du conteneur
validé, les données peuvent être utilisées dans le contexte d’un monde ouvert.
Tableau 1 — Liste des concepts utilisés dans la série ISO 21597 et leur interprétation
Concept Interprétation
owl: C la s s Dans un ensemble de données à l’intérieur d’un conteneur,
l’appartenance d’un individu à une classe doit se faire par le
biais d’une assertion explicite, sauf si elle est implicitement
déduite au moyen de prédicats tels que r df s: s ub C la s s O f
[W3C-RDF11-SCHEMA, 3.4] ou owl: e qui vale nt C la s s [W3C-
OWL2-SPEC, 9.1.2].
r df s: s ub C la s s O f La série ISO 21597 ne s’écarte pas des définitions du W3C
[W3C-RDF11-SCHEMA]. Les énoncés qui peuvent être
r df s: s ubP r op e r t y O f
déduits des énoncés r df s: s ub C la s s O f ou r df s: s ubP r op e r t y O f
doivent être considérés comme vrais même s’ils ne font pas
l’objet d’une assertion explicite.
NOTE:  Les énoncés dans lesquels une classe est mention-
née sont également vrais pour toutes ses sous-classes. De
même, les énoncés dans lesquels une propriété est mention-
née sont également vrais pour toutes ses sous-propriétés.
6 © ISO 2020 – Tous droits réservés

Tableau 1 (suite)
Concept Interprétation
owl: F unc t ional P r op e r t y La série ISO 21597 interprète
owl: F unc t ional P r op e r t y en tant que propriété ayant une car-
dinalité maximale de 1.
[W3C-OWL2-SPEC, 9.2.4]
owl: Inve r s e F unc t ional P r op e r t y La série ISO 21597 interprète
owl: Inve r s e F unc t ional P r op e r t y en tant que propriété inverse
ayant une cardinalité maximale de 1.
[W3C-OWL2-SPEC, 9.2.7]
owl: e qui vale nt C la s s La série ISO 21597 ne s’écarte pas des définitions du
W3C [W3C-OWL2-SPEC, 9.1.2]. Les énoncés qui peuvent
être déduits des énoncés owl: e qui vale nt C la s s doivent être
considérés comme vrais même s’ils ne font pas l’objet d’une
assertion explicite.
r df s: r ange Ces énoncés doivent être interprétés comme des restric-
tions. Un sujet ou un objet d’un énoncé (triple) dans un
r df s: domain
ensemble de données où cet individu appartient à une
classe non conforme avec les déclarations r df s: r ange ou
r df s: domain des prédicats owl: O bje c t P r op e r t y [W3C-OWL2-
SPEC, 5.3] ou owl: D at at y p e P r op e r t y [W3C-OWL2-SPEC, 5.4]
est invalide.
owl: r e s t r ic t ion Ces énoncés doivent être interprétés comme des restric-
tions. Tout écart de la restriction spécifiée dans un conte-
owl: onP r op er t y
neur unique est considéré comme invalide.
owl: all Value sF r om
NOTE:  À titre d’exemple, si owl: c ar dinalit y est défini sur 2,
owl: s omeValue sF r om alors un ensemble de données qui ne contient pas exacte-
ment 2 occurrences n’est pas valide.
owl: ha sValue
owl: c ar dinalit y
owl: min Car dinalit y
owl: ma x Car dinalit y
owl: inve r s e O f La série ISO 21597 ne s’écarte pas des définitions du W3C
[W3C-OWL2-SPEC, 9.2.4]. Il est recommandé que les pro-
priétés inverses ne fassent pas l’objet d’une assertion pour
les individus dans un ensemble de données. Si tel est tou-
tefois le cas, elles ne doivent pas contredire les assertions
effectuées dans le sens inverse.
owl: di s jointUnion O f L’expression doit être interprétée comme une contrainte
où le sujet est considéré comme une classe abstraite au
sens où tout membre individuel de la classe de sujet doit
également être membre de l’une (et d’une seule) des classes
disjointes énumérées dans la partie d’objet de l’énoncé owl:
disjointUnionOf. [W3C-OWL2-SPEC, 9.1.4]
4.2 Symboles et notations
Tout au long de la série ISO 21597, la structure des ontologies est illustrée au moyen d’une notation UML.
Le présent paragraphe a pour but de décrire cette notation et de donner la signification des termes et
symboles utilisés.
Les Tableaux 2 et 3 énumèrent les espaces de noms et les préfixes correspondants utilisés dans la série
ISO 21597.
Tableau 2 — Espaces de noms et préfixes utilisés dans les ontologies définies dans la série
ISO 21597
Ontologie Préfixe Espace de noms
Ontologie conteneur ct https:// standards .iso .org/ iso/ 21597/ -1/ ed-1/ en/ Container
Ontologie liens ls https:// standards .iso .org/ iso/ 21597/ -1/ ed-1/ en/ Linkset
Tableau 3 — Espaces de noms et préfixes utilisés dans les ontologies référencées dans la série
ISO 21597
Ontologie Préfixe Espace de noms
XML Schema xsd https:// www .w3 .org/ 2001/ XMLSchema
Resource Description rdf
https:// www .w3 .org/ 1999/ 02/ 22 -rdf -syntax -ns
Framework
RDF Schema rdfs https:// www .w3 .org/ 2000/ 01/ rdf -schema
Web Ontology Language owl https:// www .w3 .org/ 2002/ 07/ owl
La Figure 1 illustre les notations UML utilisées dans la série ISO 21597 pour restituer les classes et les
propriétés.
Figure 1 — Notation UML pour les classes et les propriétés
Une classe (owl: C la s s) est illustrée par un encadré rectangulaire divisé en deux compartiments, comme
représenté à la Figure 1. Le nom de la classe (« e x: C la s s» à la Figure 1) est affiché dans le compartiment
supérieur. À noter que le nom de la classe est indiqué suivant le modèle «prefix: ClassName», où le
préfixe («ex» dans l’exemple) indique l’espace de noms de l’ontologie et «ClassName» est le nom de la
classe. Les préfixes effectivement utilisés dans la série ISO 21597 sont définis dans les Tableaux 2 et 3.
Le compartiment inférieur indique les propriétés spécifiées pour cette classe. Il existe deux types
généraux de propriétés:
— les propriétés de types de données sont celles qui admettent une valeur littérale, comme illustré
pour e x : Anot her C la s s à la Figure 1; et
— les propriétés d’objet sont celles qui admettent un individu, par exemple e x: C la s s à la Figure 1, où la
propriété e x : Obje c t P r op er t y _1 référence un individu de la classe e x : Anot her C la s s.
Les définitions de propriétés sont indiquées suivant le modèle «prefix: propertyName: range[cardinality]».
La portée d’une propriété de types de données doit être basée sur l’un des types de données prédéfinis
dans le schéma XML [W3C-XML-DATATYPES]. La portée d’une propriété d’objet est généralement l’une
des classes apparaissant dans l’ontologie, mais elle peut se référer également à une classe dans une
autre ontologie.
Si les classes des deux côtés d’une propriété d’objet (domaine et portée) sont visibles sur un diagramme,
la propriété d’objet peut également être illustrée avec une flèche (bleue) entre les classes pointant de
la classe de domaine vers la classe de portée (comme représenté à la Figure 1). Le nom de la propriété
d’objet est affiché le long de la flèche ainsi que dans le compartiment de propriété de l’encadré de classe,
comme expliqué ci-dessus.
8 © ISO 2020 – Tous droits réservés

Toutes les restrictions de cardinalité sont présentées entre crochets en utilisant la notation suivante:
[minCardinality.maxCardinality], où minCardinality spécifie les occurrences minimales autorisées et
maxCardinality spécifie le nombre d’occurrences maximal autorisé.
Les restrictions de cardinalité doivent être interprétées de la manière suivante:
— omis - il n’existe aucune restriction de cardinalité, c’est-à-dire que tout nombre d’occurrences de
zéro à plusieurs est autorisé;
— maxCardinality omis (par exemple [0.], [1.] etc.) - la cardinalité maximale n’est pas restreinte.
Si deux classes sont associées au moyen d’un prédicat r df s: s ub C la s s O f, ceci est illustré au moyen d’une
flèche, comme représenté à la Figure 2. Ce diagramme stipule que e x: Sub C la s s et e x: C la s s sont associées
au moyen d’un prédicat r df s: s ub C la s s O f.
Figure 2 — Illustration d’une relation de sous-classe
Les classes disjointes sont illustrées à la Figure 3.
Figure 3 — Illustration de classes disjointes
La flèche rouge pointant de e x: C la s s1 à e x : C la s s2 déclare qu’elles sont disjointes, ce qui signifie qu’une
instance n’est pas autorisée à appartenir à la fois à e x: C la s s1 et à e x : C la s s2. Cela est déclaré avec un
énoncé owl: di s jointUnionO f (e x : C la s s1 owl: di s jointUnionO f e x : C la s s2). La propriété owl: di s jointUnionO f est
symétrique, ce qui signifie que si la classe Class1 est disjointe de Class2, alors la classe Class2 est aussi
disjointe de Class1.
Deux classes déclarées équivalentes à travers l’utilisation de owl: e qui valent C la s s (par exemple e x: C la s s 3
owl: equi valent C la s s e x: C la s s 4) sont illustrées comme à la Figure 4.
Figure 4 — Illustration de classes équivalentes
Enfin, une classe peut être à la fois le domaine (Domain) et la portée (Range) pour une certaine propriété
d’objet (ObjectProperty). Cette relation est restituée tel que représenté à la Figure 5, c’est-à-dire avec la
petite flèche alignée en bas de l’encadré class sans aucune étiquette fixée à la flèche.
Figure 5 — Illustration d’une propriété d’objet définie par un individu de la même classe
4.3 Structure du conteneur
4.3.1 Vue d’ensemble
Un conteneur est un fichier qui doit avoir l’extension «.icdd» et être conforme à l’ISO/IEC 21320-1,
également appelée ZIP64.
Un conteneur inclut un fichier d’en-tête dans le dossier de niveau supérieur; ce fichier doit être conforme
aux normes RDF(S)/OWL et est sérialisé en RDF/XML [W3C-RDF11-XML] ou toute autre sérialisation
RDF équivalente recommandée par le W3C. Le nom de ce fichier d’en-tête est Index.rdf.
Un conteneur doit posséder au moins trois dossiers, comme illustré à la Figure 6. Le but de ces dossiers
de niveau supérieur est expliqué dans les paragraphes suivants. Les dossiers «Payload documents» et
«Payload triples» peuvent contenir des dossiers intégrés pour permettre de rassembler des groupes
de ressources numériques associées et de les référencer en tant que groupe (par exemple un modèle
d’informations de la construction avec ses fichiers de référence associés ou un ensemble de feuilles de
calcul liées).
Figure 6 — Structure minimale de la racine d’un conteneur
10 © ISO 2020 – Tous droits réservés

La Figure 7 indique la hiérarchie des dossiers et des fichiers dans un conteneur.
Figure 7 — Hiérarchie des dossiers et des fichiers dans un conteneur
4.3.2 Dossier «Ontology resources»
Le dossier «Ontology resources» peut être utilisé pour stocker les ontologies Linkset.rdf et Container.
rdf qui fournissent conjointement les classes d’objet et les propriétés qui doivent être utilisées pour
spécifier le contenu des documents et les liens entre ceux-ci dans le conteneur. Ces ontologies doivent
être sérialisées au format RDF/XML [W3C-RDF11-XML] ou toute autre sérialisation RDF équivalente
recommandée par le W3C. Elles sont toutes deux disponibles en fichiers téléchargeables (et peuvent
par conséquent être référencées en tant que ressources maintenues localement mais extérieures au
conteneur): il n’est donc pas nécessaire de les inclure ici, mais si elles le sont, les fichiers de ce dossier
doivent être prioritaires par rapport aux versions en ligne.
4.3.3 Dossier «Payload documents»
Le dossier «Payload documents» doit être utilisé pour stocker tous les documents qui sont inclus dans
le conteneur (appelés les données utiles). Les sous-dossiers sont autorisés.
4.3.4 Dossier «Payload triples»
Le dossier «Payload triples» doit être utilisé pour stocker les fichiers de liens et peut inclure des sous-
dossiers.
4.4 Ontologies et ensembles de données
4.4.1 Vue d’ensemble
Au moyen de la technologie RDF(S)/OWL, les classes et les propriétés utilisées pour spécifier le contenu
des documents et les liens entre eux dans le conteneur sont spécifiées dans le conteneur au travers de
deux ontologies:
— l’ontologie conteneur, disponible en ligne à https:// standards .iso .org/ iso/ 21597/ -1/ ed -1/ en/
Container .rdf;
— l’ontologie liens, disponible en ligne à https:// standards .iso .org/ iso/ 21597/ -1/ ed -1/ en/ Linkset .rdf.
Comme indiqué précédemment, ces ontologies peuvent être incluses dans le conteneur, dans le dossier
«Ontology resources», afin de créer un conteneur autonome qui peut être utilisé hors ligne ou à des
fins d’archivage. Ces ontologies étant conformes à la série ISO 21597 , elles ne doivent en aucun cas être
modifiées.
De plus, le conteneur doit inclure les ensembles de données RDF(S)/OWL qui décrivent le contenu du
conteneur et les liens entre les documents le constituant. Il existe deux types d’ensembles de données.
Tout d’abord, le conteneur doit inclure un ensemble de données d’index, appelé Index.rdf situé à la racine
du conteneur et servant à décrire le conteneur et à spécifier le contenu des documents qui constituent
son contenu. Le conteneur peut ensuite inclure zéro ou plusieurs ensembles de données de lien afin de
spécifier les liens entre les documents. Tous ces ensembles de données doivent référencer les ontologies
de conteneur et de liens de l’Annexe E.
Les ontologies conteneur et liens sont décrites en 4.4.2 et 4.4.3. Les deux types d’ensembles de données
décrites à l’alinéa précédent sont ensuite décrits respectivement en 4.4.4 et 4.4.5.
4.4.2 Ontologie conteneur
L’ontologie conteneur est un fichier RDF(S)/OWL contenant les définitions des classes et des propriétés
utilisées dans un ensemble de données d’index et fournissant des métadonnées sur le conteneur.
L’ensemble de données d’index permet de spécifier les éléments suivants:
— version de la norme ICDD à travers l’import de l’ontologie de référence;
— liste des documents externes avec leurs métadonnées:
— nom de fichier obligatoire (comprenant un URI ou un IRI);
— format de fichier (facultatif);
— description (facultative);
— liste des documents internes avec leurs métadonnées:
— nom de fichier obligatoire (incluant le chemin dans la structure de dossiers du conteneur);
— format de fichier (facultatif);
— description (facultative);
— référence aux ensembles de données de lien.
Les Tableaux 4, 5 et 6 énumèrent respectivement les objets, les propriétés de types de données et les
propriétés d’objet qui sont utilisés dans l’ontologie conteneur, et en donnent une brève description.
12 © ISO 2020 – Tous droits réservés

Tableau 4 — Classes définies dans l’ontologie conteneur
Nom d’objet Description
c t : Cont aine rD e s c r ipt ion Description d’un conteneur dans lequel tous les documents sont énumérés et où se
trouvent des ensembles de données de lien. Tout conteneur doit contenir exacte-
ment une instance de c t : Cont aine rD e s c r ipt ion.
c t : Enc r y pt e d D o c ume nt Référence à un document chiffré.
c t : E x t e r nal D o c ume nt Référence à un document externe.
c t : Int e r nal D o c ume nt Référence à un document interne.
ct: Link s e t Référence à un fichier RDF(S)/OWL contenant des liens.
c t : D o c ume nt Classe abstraite référençant un document; un individu doit appartenir à ct:
ExternalDocument ou c t : Int e r nal D o c ume nt; et en option, les individus peuvent éga-
lement appartenir aux sous-classes de c t : D o c ume nt telles que c t : S e c ur e d D o c ume nt
et/ou c t : Enc r y pt e d D o c ume nt.
c t : S e c ur e d D o c ume nt Document sécurisé par un algorithme de somme de contrôle (voir également les
propriétés c t : che ck s um et c t : c he c k s um A lgor it hm).
c t : Folde rD o c ume nt Document comprenant plusieurs fichiers situés dans un seul dossier, à la manière
d’un ensemble de données SIG constitué de fichiers SHP associés à des fichiers DBF.
ct: Par t y Classe abstraite représentant la généralisation de c t : O r g ani s at ion ou de
ct: Pe r s on; les entités peuvent se référer à un individu d’une sous-classe de ct: Par t y
par le biais des propriétés d’objet ct: c r e at or, ct: modifier ou c t : publi s he r.
ct: Pe r s on Classe représentant une personne à des fins de provenance.
c t : O r g ani s at ion Classe représentant une organisation à des fins de provenance.
Tableau 5 — Propriétés de types de données utilisées dans l’ontologie conteneur
Nom de type de données Description
c t : che ck s um Somme de contrôle pour la référence du document; l’algorithme de somme de
contrôle est spécifié par la propriété c t : c he c k s um A lgor it hm.
c t : c he c k s um A lgor it hm Algorithme utilisé pour générer la somme de contrôle.
c t : c onf or manc e Indic at or Indicateur sous forme de chaîne de caractères pour c t : Cont aine rD e s c r ipt ion indi-
quant la partie de la série ISO 21597 à laquelle le conteneur est conforme: pour un
conteneur conforme à la Partie 1, il convient que la valeur de cette propriété soit
«ICDD-Part1-Container»; la portée de la propriété n’est pas restreinte pour autori-
ser d’autres valeurs.
c t : c r e at ion D at e Date de création au format x s d: dat eT ime.
c t : de s c r ipt ion Description générale.
c t : e nc r y pt ion A lgor it h
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.