ISO 20614:2017

INTERNATIONAL ISO
STANDARD 20614
First edition
2017-11
Information and documentation —
Data exchange protocol for
interoperability and preservation
Information et documentation — Protocole d'échange de données
pour l'interopérabilité et la préservation
Reference number
©
ISO 2017
© ISO 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2017 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Context . 4
4.1 Roles played by individuals or organizations involved in transactions . 4
4.2 Types of transactions . 4
4.3 Exchanged objects . 4
4.3.1 General. 4
4.3.2 Exchanged Object packages (DataObjectPackageType) . 4
4.3.3 Administrative metadata of exchanged Data
Objects (AdministrativeMetadataType) . 5
4.3.4 Descriptive metadata of the exchanged Data Objects (DescriptiveMetadataType) 5
5 Modelling . 5
5.1 General . 5
5.2 Use case diagrams . 6
5.2.1 General. 6
5.2.2 Transfer . 6
5.2.3 Deliver . 7
5.2.4 Modify . 8
5.2.5 Dispose . 8
5.2.6 Restitute . 9
5.3 Sequence diagrams .10
5.3.1 General.10
5.3.2 Transfer .10
5.3.3 Deliver .11
5.3.4 Modify .12
5.3.5 Dispose .13
5.3.6 Restitute .13
5.3.7 Authorization requests .14
5.3.8 List of messages .16
5.4 Class diagrams .17
5.4.1 General.17
5.4.2 Organizations .17
5.4.3 Data Object packages .18
5.4.4 Specification of the version of the lists of codes used .20
5.4.5 Signature .22
5.4.6 Objects of non-specified types .22
5.4.7 Description of messages .22
6 Implementation model .29
6.1 General .29
6.2 Definition of types .29
6.3 Elements metadata .29
Annex A (informative) Information website .36
Annex B (informative) Rules for the use of code lists .37
Annex C (informative) XML schemas for DEPIP .39
Annex D (informative) Guidelines — Use cases — REST architecture .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 on 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 the following
URL: www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 46, Information and documentation,
Subcommittee SC 4, Technical interoperability.
iv © ISO 2017 – All rights reserved

Introduction
The Data Exchange Protocol for Interoperability and Preservation (DEPIP) aims at facilitating inter-
operability between a digital archive and information systems of its partners: producers who have
created the documents themselves (Originating Agency), intermediaries who are acting on behalf of
producers and are not responsible for the intellectual content per se (Transferring Agency), consumers
(Consumer) and control authorities (Control Authority). This document provides a framework for data
exchange between systems. It is based on the OAIS Reference model. It is generic and may be adapted to
all types of information, whether printed or in a born-digital format.
DEPIP is intended for:
— commercial software vendors, in order to complete and/or improve their applications;
— archives, in order to standardize ingest of data destined for preservation; to provide access to
archived data; and to facilitate the exchange of data between archives;
— application programmers, in order to enable interoperable data transactions between Archives and
the information systems they are developing;
— third parties responsible for transferring documents to Archives;
— data storage service suppliers.
The parties to data exchange may rely on this document to:
— define their archiving/preservation processes or harmonize their existing processes with the best
practices;
— organize the management of the archiving/preservation processes; and
— control the creation and management of metadata, whatever descriptive models are used.
Note that DEPIP may be implemented either in its entirety or only partially. However, it is impossible
to foresee what the implementations will be like in different domains such as libraries, archives or
museums. Domain-specific or generic International Standardized Profiles specifying different levels of
interoperability may be developed in the future to support the implementers of this document. The
minimum implementation, or level 0, is: Transfer and Delivery, including at least mandatory metadata.
Note that in level 0, existing metadata is not redefined and that the initial request and the final reply
are required.
Note that DEPIP is a conceptual standard to be considered as a data dictionary. The model defined
in DEPIP is independent of implementation issues. In different implementations, DEPIP can be
supplemented by relevant technical protocols (like HTTP) allowing implementers to handle technical
exchanges between systems.
INTERNATIONAL STANDARD ISO 20614:2017(E)
Information and documentation — Data exchange protocol
for interoperability and preservation
1 Scope
DEPIP specifies a standardized framework for the various data (including both data and related
metadata) exchange transactions between an archive and its producers and consumers. Interchanges
between archives (including archives integrated in organizations, public archives, storage service
suppliers) are also considered. This document defines five transactions (Transfer, Deliver, Dispose,
Modify and Restitute), which the partners can use to exchange Data Objects. It also specifies the syntax
and semantics of the messages that are exchanged during these transactions.
Internal organization of the information systems of the partners is excluded. Information received in
conformance with the data exchange model is intended to be handled by various software components.
These applications, however, are not the object of this document. The impacts of major risks (for
instance, disappearance or incapacitation of the producer of the data) are also excluded.
2 Normative references
There are no normative references in this document.
3 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 http://www.iso.org/obp
— IEC Electropedia: available at http://www.electropedia.org/
3.1
Access
transmission of information by an Archive (3.2) to a Consumer (3.5), with the authorization, if required,
of the Originating Agency (3.11) and of the relevant Control Authority (3.6)
3.2
Archive
organization that intends to preserve information for Access (3.1) and use by a designated community
in accordance with the current legal, regulatory or contractual conditions
Note 1 to entry: The DEPIP Archive is not fully equivalent to the OAIS Archive as the latter does not check the
compliance with the contractual conditions.
Note 2 to entry: The DEPIP Archive is not necessarily the same as an archive in a traditional sense in which legal
custody is permanently transferred. It may temporarily offer preservation services for content, in accordance
with a legal agreement that has a set time frame. At the end of that time frame, or in accordance with some other
stipulation of the legal agreement that would permit it, the Data Objects (3.7) that had been transferred to the
archive could be returned to the Originating Agency (3.11) or a third party appointed by it.
3.3
Binary Data Object
digital item which contains information, for instance, an electronic file, i.e. a named and ordered
sequence of bytes that the file system of an operating system may handle as a unit
3.4
Business Identifier
identifier used to identify the Archive (3.2) and its partners, messages, Submission Agreements (3.18), etc.
3.5
Consumer
individual or organization wishing to consult information kept by the Archive (3.2) in accordance with
the current legal, regulatory or contractual conditions
3.6
Control Authority
internal or external individual or organization that, if applicable, may authorize the delivery or the
disposal of information held by an Archive (3.2)
Note 1 to entry: Control Authority is partially equivalent to the OAIS management (like management, it may be
external to the archive), but it has narrower role than management in that Control Authority is only interested in
legal or regulatory compliance.
3.7
Data Object
either a digital (sequence of bits) or a physical object which is to be preserved, and technical metadata
(representation information, integrity information and identification information)
3.8
Disposal notification
notification by an Archive (3.2) to an Originating Agency (3.11) of information disposal
3.9
Disposition rule
information required to manage the data lifecycle to indicate a retention period, beyond which Data
Objects (3.7) shall be disposed or preserved
3.10
Modification notification
notification by an Archive (3.2) to an Originating Agency (3.11) of the modifications made to the
submitted and/or archived Data Objects (3.7)
Note 1 to entry: These modifications may be necessary during the ingest or later to ensure proper storage of
information (e.g. changing the file format, or adding, correcting or updating representation information or
preservation description information).
3.11
Originating Agency
individual or organization that made or received the information within the context of its activities
Note 1 to entry: It is often the producer in the OAIS model.
Note 2 to entry: The Originating Agency may act as a Transferring Agency (3.20) or may use a Transferring Agency
as an intermediary for sending data to the Archive (3.2).
3.12
Physical Data Object
physical item which contains information, for instance, a file, a box, a CD-ROM, etc.
3.13
Preservation
combination of policies, strategies and actions developed by the Archive (3.2) to ensure that digital
information of continuing value remains accessible and usable
3.14
Preservation profile
adjustment of the descriptive model based on the types of exchanged Data Objects (3.7)
2 © ISO 2017 – All rights reserved

3.15
Restitution
transfer of information by an Archive (3.2) to an Originating Agency (3.11) in order to shift back to the
Originating Agency the responsibility for data retention
Note 1 to entry: This transaction is partially equivalent to the OAIS functional entities archival storage and access.
3.16
Rights metadata
metadata concerned with the limitations and restrictions regarding the access to and use of data
commonly including elements such as copyright status, use restrictions and information about licensing
agreements
3.17
Service Level
quality of the services provided by the Archive (3.2) to its partners and planned by the Submission
Agreement (3.17), including secure preservation, guarantee of the integrity of the stored data,
availability rate, etc.
3.18
Submission Agreement
agreement or regulation used as a framework for the relationships between the Archive (3.2) and its
partners
Note 1 to entry: In order to facilitate DEPIP implementation, an agreement should describe at least the following:
— international standardized profile(s) supported (if any);
— the types of transactions (transfer, deliver, modify, dispose and restitute) supported, specifying, when
necessary, whether a preliminary authorization of the Control Authority is required;
— the list of individuals or organizations involved, their roles and responsibilities in these transactions;
— the selected code lists and models to be used during these transactions;
— Preservation profiles (i.e. rules for creating descriptive metadata according to the type of documents
or applications being preserved) including: Service Levels, access and Disposition rules and information
about how the terms in the original agreement may have evolved.
Note 2 to entry: Details concerning data transactions may be incorporated in the Submission Agreement. It is
also possible to create a separate agreement (complementing the Submission Agreement), which provides the
required technical information. In DEPIP, it is assumed that everything is included in a Submission Agreement.
3.19
Transfer
submission of submission information packages or SIPs by a Transferring Agency (3.20) to an Archive
(3.2) in order to hand over the responsibility for preservation
Note 1 to entry: This transaction is equivalent to the OAIS ingest functional entity.
3.20
Transferring Agency
individual or organization that submits submission information packages (SIPs) to an Archive (3.2) but
does not own the Data Objects submitted
Note 1 to entry: In the OAIS model, the term “producers” has a narrower meaning (people, or more likely, the
organizations, which provide the objects to be archived). From an OAIS point of view, a Transferring Agency is
a kind of producer, who is acting on behalf of third parties and is not responsible for the content per se, but may
have responsibility for creating the Submission Information Packages (SIPs).
Note 2 to entry: A Transferring Agency could sometimes also be the Originating Agency (3.11). In that scenario, it
is the owner of the Data Objects it is transferring, and it also has the responsibility for creating the submission
information packages (SIPs).
4 Context
4.1 Roles played by individuals or organizations involved in transactions
The following are the principal roles in the DEPIP context (defined in Clause 3): Archive, Transferring
Agency, Originating Agency, Control Authority and Consumer.
NOTE Three roles identified in DEPIP are not directly part of the basic OAIS model (Control Authority,
Transferring Agency and Originating Agency) but may be seen as aspects of OAIS Producer and Management.
4.2 Types of transactions
The transactions described in detail in Clause 5 are:
— Transfer: Transfer of information by a Transferring Agency to an Archive in order to hand over the
responsibility for preservation. The Transfer may be preceded by a Transfer Request for agreement;
— Deliver: Delivery of information by an Archive to a Consumer, with the authorization, if required, of
the Originating Agency and/or of a Control Authority;
— Modify: Notification by an Archive to an Originating Agency to inform it that the transferred
information has been modified. These modifications may be necessary in order to ensure proper
storage of information (e.g. changing the file format). Note that the entire activity of modification
as would be undertaken by an Archive would comprise many more steps than merely a notification
being sent, but the scope of “Modify” as focused here is merely the notification;
— Dispose: Notification by an Archive to an Originating Agency to inform it that the requested
information has been disposed of. The disposal may be preceded, if applicable, by a Disposal request
to the Control Authority and by an Authorization request to the Originating Agency. Note that the
entire activity of disposition as would be undertaken by an Archive would comprise many more
steps than merely a notification being sent, but the scope of “Dispose” as focused here is merely the
notification;
— Restitute: Transfer of information from an Archive to the Originating Agency for the purpose of
returning the responsibility for preservation to the Originating Agency. Restitution should not
be confused with data recovery, that is to say, the full Restitution of the relevant information in a
reusable way and as contracted.
4.3 Exchanged objects
4.3.1 General
The objects exchanged during DEPIP transactions are Data Objects (including technical metadata)
accompanied by descriptive and administrative metadata. Since DEPIP is based on OAIS, technical
metadata relates to structural metadata (representation information) and is considered as part of
the Data Object, while descriptive and administrative metadata is left open and is only accompanying
information. The types of these objects (indicated in brackets) and the cardinality of their components
are presented in class diagrams.
4.3.2 Exchanged Object packages (DataObjectPackageType)
4.3.2.1 General
A package of Data Objects (DataObjectPackageType) is composed of a set of Data Objects accompanied
by descriptive and administrative metadata.
4 © ISO 2017 – All rights reserved

4.3.2.2 Data Objects (BinaryDataObjectType and PhysicalDataObjectType)
A Data Object is either a digital (sequence of bits) or a physical object which is to be preserved, containing
technical metadata, i.e. representation information (for instance, format), integrity information (for
instance, hash code) and identification information (for instance, identifier).
This document makes a distinction between:
— Binary Data Objects (BinaryDataObjectType): for instance, an electronic file, i.e. a named and
ordered sequence of bytes that the file system of an operating system may handle as a unit;
— Physical Data Objects (PhysicalDataObjectType): for instance, a file, a box, a CD-ROM, etc.
A Binary Data Object may be characterized by its format (e.g. "PDF 1.4"), its encoding (e.g. "UTF-8" for a
text file) and its size (in bytes). The digital content may be physically included (encapsulated) within a
message, or it may be bound by a reference (e.g. a file name).
The decision to either encapsulate digital content in the information package or to leave it outside of
the package is implementation-specific. The decision may be based on criteria such as the size of the
Data Object.
A Data Object on a physical medium (e.g. paper document or analogue recording) is characterized by
specific technical metadata. The main related metadata elements are its size (number of folders, boxes,
linear meters, etc.) and its medium or container using its technical identifier and/or its storage location.
4.3.3 Administrative metadata of exchanged Data Objects (AdministrativeMetadataType)
Administrative metadata applies to all the Data Objects in a SIP package and includes the following
information:
— Submission Agreement;
— Preservation profile;
— Service Level;
— Rights metadata;
— Disposition rule.
NOTE Rights metadata is bound to the Data Object. It is controlled by the Control Authority, but it is not
held by it.
4.3.4 Descriptive metadata of the exchanged Data Objects (DescriptiveMetadataType)
Descriptive metadata includes information related to the Data Objects (data origin, description, date,
keywords, etc.). Descriptive metadata should apply to all Data Objects in a SIP. Descriptive metadata
may be based on different metadata formats, depending on the domain (e.g. MARC 21 in libraries, EAD
in archives, ONIX for book trade, and so on).
5 Modelling
5.1 General
The model used for description of transactions is Unified Modeling Language (UML). Three types of
diagrams are used.
— The use case diagrams provide an overview of the system by representing the individuals or
organizations involved and their actions on the system.
— The sequence diagrams include each use case and provide a temporal representation of the progress
of each transaction. These diagrams represent the scenarios involving the Archive and its partners.
— The class diagrams are used to define the set of elements and their properties used in different
transactions.
5.2 Use case diagrams
5.2.1 General
Five transactions may occur between the Archive and its partners: Transfer, Deliver, Modify, Dispose
and Restitute. These transactions are shown in Figure 1.
Figure 1 — General use case diagram
5.2.2 Transfer
During Transfer, the Transferring Agency should transmit to the Archive the following information:
— information concerning the transfer itself (identification of the Transferring Agency and of the
Archive, date of sending the message);
— management information (identification of the Submission Agreement between these two parties);
— information on the Data Objects to be preserved (administrative and descriptive metadata).
If they are digital, the Data Objects themselves may be joined to the message. After the transfer, in
case of an acceptance by the Archive, it is its responsibility to retain the transferred information. The
Submission Agreement shall specify whether there is also a transfer of responsibility.
The Transfer may be preceded by a Transfer request for agreement that allows the Transferring Agency
to check with the Archive that the planned transfer is acceptable by sending, for instance, only the
metadata for authorization. Figure 2 shows the Transfer preceded by a Transfer request.
6 © ISO 2017 – All rights reserved

Figure 2 — Use case diagram: Transfer
5.2.3 Deliver
A request to deliver a preserved Data Object may be sent by the Originating Agency or, more indirectly,
from any person with an interest in consulting the Data Object (i.e. a Consumer) for administrative,
legal, litigious or historical reasons. The Originating Agency may always access the Data Objects it has
submitted and which have been archived unless legal, regulatory or contractual exceptions requiring
authorization of the Control Authority exist.
NOTE 1 Authorization from the Control Authority shall be requested for the delivery of personal data. Once
the retention periods defined for the initial purpose of the processing have expired, they are no longer of use for
their initial purpose. The Authorization request also applies to the Originating Agency.
NOTE 2 If the Consumer is the Originating Agency, the authorization from the Originating Agency is
considered tacit.
Consumers may need an authorization from the Originating Agency, the Archive and/or from the
Control Authority because of legal, regulatory or contractual conditions.
Figure 3 shows the Delivery preceded by authorization requests sent to the Originating Agency or to
the Control Authority.
Figure 3 — Use case diagram: Deliver
5.2.4 Modify
The Archive shall maintain, in accordance with the Submission Agreement, a list of authorized
modification operations, such as:
— modification of metadata;
— migration of Data Objects (format conversion in case of obsolescence of the format in which the data
has been submitted);
— notification [this transaction allows the Archive to send a Dissemination Information Package (DIP)
containing the migrated Data Objects and modified metadata to the Originating Agency].
When the Archive has migrated the preserved Data Objects, or modified the associated metadata, the
Archive shall inform the Originating Agency about the changes. Figure 4 shows the notification of the
modification operations.
Figure 4 — Use case diagram: Modify
5.2.5 Dispose
The Disposal procedure applies when an Archive disposes of Data Objects whose retention period
has expired. Disposal is usually based either on the Submission Agreement or a separate transaction
process agreement. The Archive may still check if the Originating Agency wants the data to be deleted
1)
before proceeding with the disposal . An authorization from the Control Authority may also, according
to the current legal, regulatory or contractual framework, be required.
Figure 5 shows the Disposal notification, preceded by the Authorization request sent to the Originating
Agency and eventually to the Control Authority.
1) See ISO 14641-1 for instance.
8 © ISO 2017 – All rights reserved

Figure 5 — Use case diagram: Dispose
If the Originating Agency has a copy of the expired Data Object in its own information system, it is the
responsibility of the Originating Agency to dispose of it. The Archive is not able to request such an
operation since it may not know that a copy exists. However, the Originating Agency may need to obtain
the authorization of the Control Authority to dispose of the Data Object. Like the Disposal notification
sent from the Archive to the Originating Agency, the Authorization request to the Originating Agency
shall be considered tacit.
5.2.6 Restitute
Restitution is a request to return the archived Data Object to the Originating Agency or a third party
appointed by it. Restitution may also concern another case, namely, the reactivation, at the request of
an Originating Agency, of a preserved file. In this case, the Restitution may be partial and may not cover
all the information contained in the original transfer.
This Restitution may be done at the request of the Originating Agency or at the request of the Archive,
for example, at the end of the contract binding an Originating Agency and a storage service supplier.
The transaction is carried out in two steps: a request, followed (in case of agreement) by a transfer
from the Archive to an Originating Agency. These steps are shown in Figure 6.
If Restitution is supported, the Submission Agreement shall specify the characteristics of the
Dissemination Information Package to be created (Data Objects in their original format and/or in
different file formats after successive migrations, metadata including descriptions of migrations as
events, etc.). Once the Restitution is made, the Archive, according to the applicable legal, regulatory or
contractual provisions, shall eventually delete the Data Objects and other information concerned.
Figure 6 — Use case diagram: Restitute
5.3 Sequence diagrams
5.3.1 General
The sequence diagrams presented below describe the dialogue between the individuals and
organizations involved in the context of a transaction. These diagrams identify messages that are sent by
the Archive and its partners and describe the sequence of these messages. To facilitate interoperability
between information systems, compliance with the order in which exchanges shall be done within each
use case is particularly important.
The sequence diagrams link together four messages: a request, an acknowledgment of the request, a
reply to the request and an acknowledgement of the reply. It should be noted that the formalism of
acknowledgments is only given as a proposal and should be used only when needed, that is, when
acknowledgement is not supported by another protocol used. Identifying whether acknowledgments
must be included in exchanges, as well as their form or style, should be specified in a Submission
Agreement or other formal agreement between the parties.
5.3.2 Transfer
Figure 7 shows the sequence of the different messages that are sent by the Archive and the Transferring
Agency during Transfer.
The Transfer request is optional. It allows the Transferring Agency to check with the Archive that the
intended transfer meets the requirements of the Submission Agreement (regarding the content of the
Data Objects, their volume, the frequency or scheduling of transfers). The content of the request may be,
for example, just some information about the agreement.
The Transfer request should be followed by an acknowledgement (optional) and a reply (acceptance or
error message) sent by the Archive to the Transferring Agency which in turn acknowledges that it has
received the reply.
If the Transfer request is accepted, the Business Identifier of the reply to the Transfer request for
agreement should be used in the following Transfer message.
The Transfer message comprises the Data Objects to be transferred and their metadata. The Transfer
message is sent by the Transferring Agency to the Archive.
The Archive sends an acknowledgement to the Transferring Agency immediately after it receives the
Transfer message.
The Archive checks that the transferred information meets all the conditions specified in the
Submission Agreement or some other service contract previously accepted by both parties. Then, either
an acceptance notification or an error message is sent by the Archive to the Transferring Agency that
acknowledges its receipt.
The reply for the acceptance may include the metadata of the transferred information object, so that
the Transferring Agency may keep track of what it has sent.
At the end of the transaction, in the case of acceptance, the information object has been transferred
from the Transferring Agency to the Archive and the responsibility for information retention shall lie
with the Archive, if the ingest process is completed successfully.
10 © ISO 2017 – All rights reserved

Figure 7 — Sequence diagram: Transfer
5.3.3 Deliver
Figure 8 illustrates the sequence of the messages that are exchanged by the Archive and its partners
involved in the Delivery transaction.
The Delivery request is made by a Consumer (either the producer or a third party) that wishes to
consult the preserved information. A Dissemination Information Package (DIP) may contain both data
and related metadata or only the former or the latter, or the entire archived Data Object or just part of it.
The Archive should send an acknowledgement to the Consumer immediately after the Delivery request
has been received.
If delivery requires authorization, one or more Authorization requests shall be made following the
posting of acknowledgement message but prior to sending the corresponding Delivery request reply
message.
After the examination of the request, and if necessary after authorization has been received, a Delivery
request reply shall be sent by the Archive to the Consumer. This reply may be negative (for instance,
where the requested information does not exist, or where the Control Authority objects to the delivery)
or affirmative (in which case, the reply includes the requested information).
After reception of the reply, the Consumer sends back an acknowledgement message.
Figure 8 — Sequence diagram: Deliver
5.3.4 Modify
Figure 9 shows the exchange of messages between the Archive and the Originating Agency during the
Modification transaction.
The Submission Agreement should allow the Archive to maintain a list of authorized modifications that
may be made on the archived or disseminated data (especially file format migrations when the original
format of the archived data becomes obsolete).
The Modification notification message comprises the technical identifiers of the modified Data Objects,
and specifies the nature of the modification applied (e.g. format migration, metadata updates). Modified
Data Objects may also be included in the notification.
Upon receiving a Modification notification, the Originating Agency may respond with an
acknowledgement message.
Figure 9 — Sequence diagram: Modify
12 © ISO 2017 – All rights reserved

5.3.5 Dispose
Figure 10 shows the sequence of the messages that are exchanged during the Disposal transaction.
This exchange of messages may occur only after the Archive has obtained an authorization from the
Originating Authority to proceed with the disposal of a digital object. Authorizations are obtained
either by making Authorization requests to the Originating Agency or by specifying the disposal terms
in the Submission Agreement.
Once the authorization has been obtained, the Archive may proceed with the disposal in compliance
with the procedure laid down by the Submission Agreement. Once the process is complete, the
Archive notifies the Originating Agency of the disposal. The Originating Agency responds with an
acknowledgement. The notification may, if necessary, include a reference to the authorization of the
Control Authority or to the corresponding Submission Agreement.
When an Originating Agency requests disposal of an information object that it holds in its own
information system, an Authorization request to the Control Authority may be sent, if required by legal,
regulatory or contractual provisions.
Figure 10 — Sequence diagram: Dispose
5.3.6 Restitute
The Restitution transaction is divided into two sequences: a sequence of Restitution request followed
by a sequence of Transfer. These two sequences are shown in Figure 11.
The Restitution request may be initiated
— by the Archive that holds information to be returned. The Archive may routinely return information
objects to the Originating Agency when their preservation period has expired, or the Archive may
return all the information objects belonging to an Originating Agency at the end of the agreement
they had together, or
— by the Originating Agency, for instance, when an Originating Agency needs to reactivate a business
file which is no longer present in its production systems, or when an Originating Agency has used
a third-party service to preserve its digital information but has decided to take the responsibility
back to itself (or to pass it to another third party).
Figure 11 — Sequence diagram: Restitute
The request made includes a list of the technical identifiers of the Data Objects requested (potentially
accompanied by metadata about the objects). The agency receiving the request shall respond with an
acknowledgement, followed by a reply (either acceptance or refusal of the Restitution request) and the
initiator of the request sends back an acknowledgement.
If the Restitution request is accepted, the actual transfer of information objects between the Archive
and the Originating Agency follows the normal Transfer procedure. Note that in this case, the Archive
that holds information to be returned acts as a Transferring Agency, while the Originating Agency of
this information acts as an Archive. At the end of the transfer, information and the responsibility for its
retention have been transferred from an in
...

NORME ISO
INTERNATIONALE 20614
Première édition
2017-11
Information et documentation —
Protocole d'échange de données pour
l'interopérabilité et la préservation
Information and documentation — Data exchange protocol for
interoperability and preservation
Numéro de référence
©
ISO 2017
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2017, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, 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, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2017 – 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 et définitions . 1
4 Contexte . 4
4.1 Les rôles des personnes physiques et morales impliquées dans les transactions . 4
4.2 Les types de transactions . 4
4.3 Les objets échangés . 5
4.3.1 Généralités . 5
4.3.2 Les paquets d’objets échangés (DataObjectPackageType). 5
4.3.3 Les métadonnées de gestion des Objets-données
échangés (AdministrativeMetadataType) . 5
4.3.4 Les métadonnées descriptives des Objets-données
échangés (DescriptiveMetadataType) . 6
5 Modélisation . 6
5.1 Généralités . 6
5.2 Diagrammes de cas d’utilisation . 6
5.2.1 Généralités . 6
5.2.2 Transférer . 7
5.2.3 Communiquer . . . 8
5.2.4 Modifier . 9
5.2.5 Éliminer .10
5.2.6 Restituer .10
5.3 Diagrammes de séquence .11
5.3.1 Généralités .11
5.3.2 Transférer .11
5.3.3 Communiquer . . .13
5.3.4 Modifier .13
5.3.5 Éliminer .14
5.3.6 Restituer .15
5.3.7 Les Demandes d’autorisation .17
5.3.8 Liste des messages .18
5.4 Diagrammes de classes .19
5.4.1 Généralités .19
5.4.2 Les organisations (Organization) .19
5.4.3 Les paquets d’Objets-données (DataObjectPackage) .20
5.4.4 Déclaration des versions des référentiels utilisés . .22
5.4.5 La signature .24
5.4.6 Les objets de types non spécifiés par la norme .24
5.4.7 Description des messages .25
6 Modèle d’implémentation .31
6.1 Généralités .31
6.2 Définition des types .32
6.3 Éléments de métadonnées .32
Annexe A (informative) Site web d’information .40
Annexe B (informative) Conventions d’utilisation des référentiels .41
Annexe C (informative) Schémas XML pour DEPIP .43
Annexe D (informative) Recommandations — Cas d’utilisation — Architecture REST .44
Bibliographie .45
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 appelé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.html.
Le présent document a été élaboré par le comité technique ISO/TC 46, Information et documentation,
sous-comité SC 4, Interopérabilité technique.
iv © ISO 2017 – Tous droits réservés

Introduction
Le Protocole d’Échange de Données pour l’Interopérabilité et la Préservation (DEPIP) vise à faciliter
l’interopérabilité entre un service d’archives numérique et les systèmes d’information de ses
partenaires: les producteurs qui ont produit les documents eux-mêmes (Service producteur), les
intermédiaires qui agissent pour le compte des producteurs et ne sont pas eux-mêmes responsables du
contenu intellectuel (Service versant), les utilisateurs (Consumer) et les services de contrôle (Service de
contrôle). Ce document donne un cadre pour l’échange de données entre les systèmes. Il est fondé sur le
modèle de référence OAIS. Il est générique et peut être adapté à tous les types d’informations, qu’elles
soient imprimées ou nativement numériques.
DEPIP s’adresse:
— aux éditeurs de logiciels du marché, pour compléter et/ou améliorer leurs applications;
— aux Services d’archives, pour normaliser la réception des données à préserver et l’accès des données
archivées, et pour faciliter l’échange de données entre Services d’archives;
— aux programmeurs, pour permettre des transactions de données interopérables entre les Services
d’archives et les systèmes d’information qu’ils développent;
— aux tiers amenés à transférer des documents aux Services d’archives;
— aux prestataires proposant des services de tiers-archivage.
Les parties impliquées dans l’échange de données peuvent s’appuyer sur ce document pour
— définir leurs processus d’archivage/de préservation ou les aligner sur des bonnes pratiques,
— organiser les processus d’archivage/de préservation, et
— contrôler la création et la gestion des métadonnées, quels que soient les modèles de description
utilisés.
Il convient de noter que DEPIP peut être implémenté soit dans sa totalité soit partiellement. Toutefois,
il est impossible de prévoir comment la norme sera implémentée dans différents domaines comme les
bibliothèques, les archives ou les musées. Des profils normalisés internationaux propres à un domaine
ou génériques spécifiant différents niveaux d’interopérabilité pourront être développés à l’avenir en
soutien aux responsables de la mise en œuvre de ce document. La mise en œuvre minimale, ou niveau
0, correspond aux transactions Transférer et Communiquer, comprenant au moins les métadonnées
minimales. Il convient de noter que dans le niveau 0, les métadonnées existantes ne sont pas redéfinies
et que la demande initiale et la réponse finale sont nécessaires.
Il convient de noter que DEPIP est une norme conceptuelle à considérer comme un dictionnaire
de données. Le modèle défini dans DEPIP est indépendant des questions de sa mise en œuvre. Dans
différentes implémentations, DEPIP peut être complété par des protocoles techniques pertinents
(comme HTTP) permettant aux responsables de sa mise en œuvre de gérer les échanges techniques
entre les systèmes.
NORME INTERNATIONALE ISO 20614:2017(F)
Information et documentation — Protocole d'échange de
données pour l'interopérabilité et la préservation
1 Domaine d’application
DEPIP définit un cadre normalisé pour les différentes transactions d’échanges de données (comprenant
à la fois les données et les métadonnées associées) entre un service d’archives et ses producteurs et
utilisateurs. Les échanges entre plusieurs Services d’archives (services d’archives intégrés dans les
organisations, services publics d’archives, prestataires d’archivage) sont également concernés. Ce
document définit cinq transactions (Transférer, Communiquer, Éliminer, Modifier et Restituer) que
les partenaires peuvent utiliser pour échanger des Objets-données. Il définit aussi la syntaxe et la
sémantique des messages qui sont échangés pendant ces transactions.
Le présent document ne concerne pas l’organisation interne des systèmes d’information des partenaires.
Les informations reçues conformément au modèle d’échange de données sont destinées à être gérées
par différents composants logiciels. Ces applications ne font toutefois pas l’objet de ce document.
Les conséquences de la survenance de risques majeurs (par exemple la disparition ou l’incapacité du
producteur des données) sont elles aussi exclues du périmètre de ce document.
2 Références normatives
Le présent document ne contient aucune référence normative.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en
normalisation, consultables aux adresses suivantes:
— IEC Electropedia: disponible à l’adresse http://www.electropedia.org/
— ISO Online browsing platform: disponible à l’adresse https://www.iso.org/obp
3.1
communication
transmission d’informations par un Service d’archives (3.2) à un Utilisateur (3.5), avec l’autorisation, le
cas échéant, du Service producteur (3.11) et du Service de contrôle (3.6) compétent
3.2
Service d’archives
organisation chargée de conserver les informations pour en permettre la Communication (3.1) à une
communauté cible et pour permettre à cette communauté de les utiliser dans le respect des conditions
légales, réglementaires ou contractuelles en vigueur
Note 1 à l'article: Le Service d’archives dans DEPIP n’équivaut pas complètement à l’Archive de l’OAIS dans la
mesure où cette dernière ne vérifie pas la conformité avec les conditions contractuelles.
Note 2 à l'article: Le Service d’archives de DEPIP n'est pas nécessairement un Service d’archives auquel la
détention légale est transférée en permanence, dans une acception traditionnelle. Il peut offrir temporairement
des services de préservation des contenus, conformément à un accord juridique pendant une durée déterminée. À
la fin de cette durée, ou conformément à une autre stipulation de l'accord juridique qui le permettrait, les Objets-
données (3.7) qui avaient été transférés au Service d’archives pourraient être retournés au Service producteur
(3.11) ou à un tiers désigné par lui.
3.3
Objet-données binaire
objet numérique contenant des informations, par exemple un fichier électronique, c'est-à-dire une
séquence d'octets nommée et ordonnée que le système de fichiers d'un système d'exploitation peut
traiter unitairement
3.4
identifiant métier
identifiant utilisé pour identifier le Service d’archives (3.2) et ses partenaires, les messages, les Accords
de service (3.18), etc.
3.5
Utilisateur
toute personne physique ou morale qui souhaite consulter les informations conservées par le Service
d’archives (3.2) dans le respect des conditions légales, réglementaires ou contractuelles en vigueur
3.6
Service de contrôle
personne physique ou morale, interne ou externe, qui, le cas échéant, peut autoriser ou non la
communication ou l’élimination d’informations conservées par un Service d’archives (3.2)
Note 1 à l'article: Le Service de contrôle équivaut partiellement à l’entité fonctionnelle «Management» du modèle
OAIS (comme le management, il est externe au Service d’archives), mais il a un rôle plus restreint en ce qu’il
s’intéresse seulement à la conformité légale ou réglementaire.
3.7
Objet-données
objet numérique (séquence d’octets) ou physique à préserver, et ses métadonnées techniques
(information de représentation, information d’intégrité et information d’identification)
3.8
notification de l’élimination
notification par un Service d’archives (3.2) à un Service producteur (3.11) de la suppression d’informations
3.9
règle de sort final
informations nécessaires à la gestion du cycle de vie des données permettant d’indiquer une durée
d’utilité au-delà de laquelle un Objet-données (3.7) sera éliminé ou conservé
3.10
notification de la modification
notification par un Service d’archives (3.2) à un Service producteur (3.11) des modifications apportées
sur les objets-données transférés et/ou archivés
Note 1 à l'article: Ces modifications peuvent être nécessaires durant l’entrée ou plus tard afin d’assurer une
bonne conservation des informations (par exemple conversion de format, ou ajout, correction, mise à jour des
informations de représentation ou des informations de pérennisation).
3.11
Service producteur
toute personne physique ou morale qui a créé ou reçu les informations dans le contexte de ses activités
Note 1 à l'article: Souvent le producteur dans le modèle OAIS.
Note 2 à l'article: Le Service producteur peut agir comme un Service versant (3.20) ou utiliser un service versant
comme intermédiaire pour envoyer des données au Service d’archives (3.2).
3.12
objet-données physique
objet physique contenant des informations, par exemple un dossier, une boîte, un CD-ROM, etc.
2 © ISO 2017 – Tous droits réservés

3.13
pérennisation
combinaison de politiques, de stratégies et d’actions développées par le Service d’archives (3.2) pour
garantir que les informations numériques à valeur pérenne restent accessibles et utilisables
3.14
Profil d’archivage
déclinaison du modèle de description en fonction des types d’objets-données (3.7) échangés
3.15
Restitution
transmission d’informations par un Service d’archives (3.2) à un Service producteur (3.11) en vue de lui
restituer la responsabilité de la conservation des données
Note 1 à l'article: à l’article Cette transaction équivaut partiellement aux entités fonctionnelles du modèle OAIS
stockage et accès.
3.16
règle d’accessibilité
métadonnées relatives aux limitations et restrictions d’accès et d’utilisation des données. Les éléments
communs incluent le statut des droits d’auteur, les restrictions d’utilisation et les informations sur les
contrats de licence
3.17
niveau de service
qualité des services fournis par le Service d’archives (3.2) à ses partenaires et prévus par l’Accord de
service (3.18), dont: la pérennisation sécurisée, la garantie de l’intégrité des données conservées, le
taux de disponibilité, etc.
3.18
Accord de service
accord ou texte réglementaire servant de cadre aux relations entre le Service d’archives (3.2) et ses
partenaires
Note 1 à l'article: Afin de faciliter l’implémentation de la norme DEPIP, un Accord de service doit a minima décrire:
— le(s) profil(s) international(internationaux) normalisé(s) supporté(s) (éventuellement);
— les types de transactions supportées (transférer, communiquer, modifier, éliminer et restituer), en précisant
si nécessaire si elles requièrent une autorisation préalable du Service de contrôle;
— la liste des personnes physiques ou morales impliquées, leurs rôles et responsabilités dans ces transactions;
— les référentiels et les modèles à utiliser pendant ces transactions;
— les profils d’archivage (c’est-à-dire les règles de constitution des métadonnées descriptives en fonction des
types de documents ou d’application concernés) dont: les niveaux de service, les règles d’accessibilité, les
règles de sort final et les informations sur les modalités d’une évolution des termes de l’accord initial.
Note 2 à l'article: Les détails concernant les transactions de données peuvent être intégrés dans l’Accord
de service. Il est aussi possible de créer un accord distinct (complétant l’Accord de service) qui fournit les
informations techniques nécessaires. Dans DEPIP, il est supposé que tout est inclus dans l’Accord de service.
3.19
Transfert
transmission de paquets d’information à verser ou SIP par un service versant (3.20) à un Service
d’archives (3.2) en vue de lui confier la responsabilité de la conservation
Note 1 à l'article: Cette transaction équivaut à l’entité fonctionnelle OAIS entrées.
3.20
Service versant
personne physique ou morale qui transmet des paquets d’information à verser (SIP) à un Service
d’archives (3.2) mais n’est pas propriétaire des objets-données transmis
Note 1 à l'article: Dans le modèle OAIS, le terme «producteurs» a un sens plus restrictif (individus ou plus
vraisemblablement organisations qui fournissent les objets à archiver). Du point de vue du modèle OAIS, un
Service versant est une sorte de producteur, qui agit pour le compte de tiers et n’est pas responsable lui-même du
contenu mais peut avoir la responsabilité de constituer les paquets d’information à verser (SIP).
Note 2 à l'article: Un service versant peut parfois être le Service producteur (3.11). Dans ce scénario, il est le
propriétaire des objets-données qu’il transfère et il a donc la responsabilité de créer les paquets d’information à
verser (SIP).
4 Contexte
4.1 Les rôles des personnes physiques et morales impliquées dans les transactions
Voici les principaux rôles dans le contexte de DEPIP (définis dans l’Article 3): le Service d’archives, le
Service versant, le Service producteur, le Service de contrôle et l’Utilisateur.
NOTE Trois rôles identifiés dans DEPIP ne font pas directement partie du modèle de base OAIS (Service de
contrôle, Service versant et Service producteur) mais peuvent être considérés comme des aspects du Producteur
et du Management de l’OAIS.
4.2 Les types de transactions
Les échanges décrits de façon détaillée dans l’Article 5 de ce document sont:
— Transférer: Transmission d’informations par un Service versant à un Service d’archives en vue de
lui confier la responsabilité de la conservation. Le Transfert peut être précédé d’une Demande de
transfert pour accord;
— Communiquer: Transmission d’informations par un Service d’archives à un Utilisateur, avec
l’autorisation, le cas échéant, du Service producteur et/ou d’un Service de contrôle;
— Modifier: Notification par un Service d’archives à un Service producteur pour l’informer que les
informations transférées ont été modifiées. Ces modifications peuvent être nécessaires afin
d’assurer une bonne conservation des informations (par exemple conversion de format). Il convient
de noter que l’ensemble de l’activité de modification qui serait entreprise par un Service d’archives
comprendrait beaucoup plus d'étapes qu’une simple notification, mais le domaine d’application de
«Modifier» ciblé ici est seulement la notification;
— Éliminer: Notification par un Service d’archives à un Service producteur pour l’informer que les
informations demandées ont été supprimées. L’élimination peut être précédée, le cas échéant,
d’une Demande d’élimination au Service de contrôle et d’une Demande d’autorisation au Service
producteur. Il convient de noter que l’ensemble de l’activité d’élimination qui serait entreprise par
un Service d’archives comprendrait beaucoup plus d'étapes qu’une simple notification, mais le
domaine d’application de «Éliminer» ciblé ici est seulement la notification;
— Restituer: Transmission d’informations d’un Service d’archives à un Service producteur en vue de
lui restituer la responsabilité de la conservation. La Restitution ne doit pas être confondue avec la
réversibilité, c’est-à-dire la Restitution intégrale des informations pertinentes comme prévu.
4 © ISO 2017 – Tous droits réservés

4.3 Les objets échangés
4.3.1 Généralités
Les objets échangés lors des transactions de DEPIP sont les Objets-données (intégrant leurs
métadonnées techniques) accompagnés des métadonnées descriptives et des métadonnées de gestion.
DEPIP s’appuyant sur l’OAIS, les métadonnées techniques se rapportent aux métadonnées de structure
(informations de représentation) et sont considérées comme faisant partie de l’Objet-données, alors
que les métadonnées descriptives et les métadonnées de gestion restent ouvertes et sont seulement des
informations qui l’accompagnent. Les types correspondant à ces objets (indiqués entre parenthèses)
ainsi que les cardinalités de leurs composants, sont présentés dans les diagrammes de classes.
4.3.2 Les paquets d’objets échangés (DataObjectPackageType)
4.3.2.1 Généralités
Un Paquet d’Objets-données (DataObjectPackageType) est composé d’un ensemble d’Objets-données
accompagné de métadonnées descriptives et de métadonnées de gestion.
4.3.2.2 Les Objets-données (BinaryDataObjectType et PhysicalDataObjectType)
Un Objet-données est un objet numérique (une séquence de bits) ou physique à conserver, contenant
des métadonnées techniques, c’est-à-dire des informations de représentation (par exemple: format), des
informations d’intégrité (par exemple: empreinte) et des informations d’identification (par exemple:
identifiant).
Ce document distingue:
— les Objets-données numériques (BinaryDataObjectType): par exemple un fichier informatique, c’est-
à-dire une séquence de bits nommée et ordonnée manipulable comme une unité par le système de
fichiers d’un système d’exploitation;
— les Objets-données sur supports physiques (PhysicalDataObjectType): par exemple un dossier, un
CD-ROM, etc.
Un Objet-données numérique peut être caractérisé par son format (par exemple: «PDF 1.4»), par son
encodage (par exemple: «UTF-8» pour un fichier texte) et par sa taille (exprimée en octets). Le contenu
numérique peut être inclus physiquement (encapsulé) dans un message ou être lié par une référence
(par exemple un nom de fichier).
Le choix d’encapsuler un contenu numérique dans le paquet d’information ou de le maintenir à
l’extérieur du paquet est spécifique à chaque implémentation. Il peut se fonder sur des critères tels que
la taille de l’Objet-données.
Un Objet-données sur support physique (par exemple un document papier ou un enregistrement
analogique) est caractérisé par des métadonnées techniques spécifiques. Les principaux éléments de
métadonnées associés sont: sa taille (nombre de chemises, de boîtes, de mètres linéaires, etc.) et la
référence au support ou au contenant par le biais de son identifiant technique et/ou de son emplacement.
4.3.3 Les métadonnées de gestion des Objets-données échangés
(AdministrativeMetadataType)
Les métadonnées de gestion s’appliquent à tous les Objets-données d’un paquet SIP et comportent les
informations suivantes:
— Accord de service;
— Profil d’archivage;
— Niveau de service;
— Règle d’accessibilité;
— Règle de sort final.
NOTE La Règle d’accessibilité est liée à l’Objet-données. Elle est contrôlée par le Service de contrôle mais elle
n’est pas appliquée par lui.
4.3.4 Les métadonnées descriptives des Objets-données échangés (DescriptiveMetadataType)
Les métadonnées descriptives regroupent des informations sur les Objets-données (origine des données,
description, dates, mots-clés, etc.). Elles s’appliquent à tous les Objets-données d’un SIP. Ces métadonnées
descriptives peuvent suivre différents formats de métadonnées, en fonction du domaine (par exemple:
MARC 21 dans les bibliothèques, EAD dans les archives, ONIX pour l’industrie du livre, etc.).
5 Modélisation
5.1 Généralités
Le modèle utilisé pour la description des échanges est le langage unifié de modélisation (UML). Trois
types de diagrammes sont utilisés.
— Les diagrammes de cas d’utilisation donnent une vue synthétique du système en représentant les
personnes physiques ou morales impliquées dans les échanges et les actions de ces dernières sur le
système.
— Les diagrammes de séquences reprennent chaque cas d’utilisation et donnent une représentation
temporelle du déroulement de chaque transaction. Ces diagrammes représentent les scénarios
impliquant le Service d’archives et ses partenaires.
— Les diagrammes de classes sont utilisés pour définir l’ensemble des éléments et leurs propriétés
utilisés lors des différents échanges.
5.2 Diagrammes de cas d’utilisation
5.2.1 Généralités
Cinq cas d’utilisation interviennent entre le Service d’archives et ses partenaires: Transférer,
Communiquer, Modifier, Éliminer et Restituer.
Ces transactions sont représentées à la Figure 1.
6 © ISO 2017 – Tous droits réservés

Figure 1 — Diagramme général de cas d’utilisation
5.2.2 Transférer
Lors du Transfert, le Service versant doit transmettre au Service d’archives les informations suivantes:
— des informations concernant le Transfert lui-même (identification du Service versant et du Service
d’archives, date d’émission du message…);
— des informations de gestion (identification de l’Accord de service passé entre ces deux parties);
— des informations sur les Objets-données à conserver (métadonnées de gestion et métadonnées
descriptives).
S’ils sont numériques, les Objets-données eux-mêmes peuvent être joints au message. A l’issue du
Transfert, en cas d’acceptation par le Service d’archives, la responsabilité de la conservation des
informations transférées lui incombe. L’Accord de service devra spécifier s’il y a également un transfert
de responsabilité.
Le Transfert peut être précédé d’une Demande de transfert pour accord qui permet au Service versant
de vérifier auprès du Service d’archives que le Transfert prévu est recevable en envoyant par exemple
uniquement les métadonnées pour accord. La Figure 2 représente le Transfert précédé d’une Demande
de transfert.
Figure 2 — Diagramme de cas d’utilisation: Transférer
5.2.3 Communiquer
Une demande de Communication d’un Objet-données peut émaner du Service producteur ou, plus
indirectement, de toute personne ayant un intérêt à consulter cet Objet-données (par exemple un
Utilisateur) pour des raisons administratives, juridiques, contentieuses ou historiques. Le Service
producteur peut dans tous les cas avoir accès aux Objets-données qu’il a transmis et qui ont été archivés,
sauf restrictions légales, réglementaires ou contractuelles nécessitant l’autorisation du Service de
contrôle.
NOTE 1 La communication de données à caractère personnel, une fois que les durées de conservation définies
pour la finalité initiale du traitement sont expirées et qu’elles ne sont plus utilisées pour leur finalité initiale, doit
faire l’objet d’une demande d’autorisation du Service de contrôle, y compris pour le Service producteur.
NOTE 2 Si l’Utilisateur est le Service producteur, l’autorisation du Service producteur est considérée
comme tacite.
Les Utilisateurs peuvent avoir besoin d’une autorisation du Service producteur, du Service d’archives
et/ou du Service de contrôle si les dispositions légales, réglementaires ou contractuelles le demandent.
La Figure 3 représente la Communication précédée de demandes d’autorisation adressées au Service
producteur ou au Service de contrôle.
8 © ISO 2017 – Tous droits réservés

Figure 3 — Diagramme de cas d’utilisation: Communiquer
5.2.4 Modifier
Le Service d’archives doit tenir à jour, conformément à l’Accord de service, une liste des opérations de
modification autorisées, par exemple:
— modification de métadonnées;
— migration des Objets-données (conversion de formats en cas d’obsolescence du format dans lequel
les données ont été transférées);
— notification [cette transaction permet au Service d’archives d’adresser au Service producteur
un Paquet d’information diffusé (DIP) contenant les Objets-données migrés et les métadonnées
modifiées].
Quand le Service d’archives a opéré ces modifications sur les Objets-données archivés ou sur les
métadonnées qui y sont associées, il doit en informer le Service producteur. La Figure 4 représente la
notification des opérations de modification.
Figure 4 — Diagramme de cas d’utilisation: Modifier
5.2.5 Éliminer
La procédure d’Élimination concerne le cas où un Service d’archives supprime des Objets-données dont
la durée d’utilité est échue. L’Élimination repose habituellement sur l’Accord de service ou un accord
de transaction distinct. Le Service d’archives peut encore vérifier si le Service producteur veut que
1)
les données soient détruites avant de procéder à leur destruction . Une autorisation du Service de
contrôle peut aussi, suivant les dispositions légales, réglementaires ou contractuelles en vigueur, être
obligatoire.
La Figure 5 représente la notification de l’Élimination, précédée par la Demande d’autorisation adressée
au Service producteur et éventuellement au Service de contrôle.
Figure 5 — Diagramme de cas d’utilisation: Éliminer
Si le Service producteur détient dans son propre système d’information une copie de l’Objet-données
dont la durée de conservation est échue, la destruction de cet Objet-données relève de la responsabilité
du Service producteur. Le Service d’archives ne peut pas demander cette opération dans la mesure
où il peut ne pas savoir qu’une copie existe. Toutefois, le Service producteur peut avoir besoin de
l’autorisation du Service de contrôle pour supprimer cet Objet-données. La Demande d’autorisation au
Service producteur, tout comme la notification de l’Élimination adressée par le Service d’archives au
Service producteur, seront considérées comme tacites.
5.2.6 Restituer
La Restitution est une demande de retour des Objets-données archivés vers le Service producteur ou un
tiers mandaté par celui-ci. La Restitution peut également concerner un autre cas de figure, à savoir la
réactivation, à la demande du Service producteur, d’un dossier archivé. Dans ce cas, la Restitution peut
être partielle et ne pas porter sur l’ensemble des informations composant le Transfert d’origine.
La Restitution peut s’effectuer à l’initiative du Service producteur, comme à celle du Service d’archives,
par exemple lors de la fin du contrat qui lie un Service producteur et un tiers-archiveur. La transaction
s’effectue en deux temps: une demande, suivie (en cas d’accord) d’un Transfert du Service d’archives
vers le Service producteur. Ces étapes sont représentées à la Figure 6.
Si la Restitution est supportée, l’Accord de service doit préciser les caractéristiques du paquet
d’information diffusé à constituer (les Objets-données dans leur format d’origine et/ou dans les
différents formats des fichiers suite aux migrations successives, les métadonnées comprenant les
descriptions des migrations comme des événements, etc.). Une fois la Restitution effectuée, le Service
1) Voir l’ISO 14641-1 par exemple.
10 © ISO 2017 – Tous droits réservés

d’archives, suivant les dispositions légales, réglementaires ou contractuelles applicables, sera amené
éventuellement à effacer les Objets-données et les autres informations concernées.
Figure 6 — Diagramme de cas d’utilisation: Restituer
5.3 Diagrammes de séquence
5.3.1 Généralités
Les diagrammes de séquences présentés ci-dessous décrivent les dialogues entre les personnes
physiques ou morales impliqués dans le cadre d’une transaction. Ces diagrammes identifient les
messages que s’envoient le Service d’archives et ses partenaires et décrivent l’enchaînement de ces
messages. Pour faciliter l’interopérabilité entre les systèmes d’information, le respect de l’ordre dans
lequel doivent se faire les échanges au sein de chaque cas d’utilisation est particulièrement important.
Les diagrammes de séquences enchaînent généralement quatre messages: une demande, un accusé de
réception de cette demande, une réponse à la demande et un accusé de réception de cette réponse.
Il est à noter que le formalisme des accusés de réception n’est donné qu’à titre de proposition et doit
être utilisé quand c’est nécessaire, c’est à-dire quand les accusés de réception ne sont pas supportés
par un autre protocole utilisé. L’identification de la présence ou non des accusés de réception dans les
échanges et de leur formalisme doit être précisée dans un Accord de service ou dans tout autre accord
formel entre les parties.
5.3.2 Transférer
La Figure 7 représente la séquence des différents messages qui sont adressés par le Service d’archives
et le Service versant pendant le Transfert.
Optionnelle, la Demande de transfert permet au Service versant de vérifier auprès du Service d’archives
que le Transfert prévu est recevable conformément à l’Accord de service passé entre les deux parties
(quant au contenu des Objets-données, leur volume, la périodicité ou la planification des Transferts). Le
contenu de cette demande peut être, par exemple, l’envoi d’informations sur cet accord.
Cette Demande de transfert doit être suivie d’un accusé de réception (facultatif) et d’une réponse
(acceptation ou avis d’anomalie) envoyée par le Service d’archives au Service versant qui en retour en
accuse réception.
En cas d’acceptation, l’identifiant de la réponse à la Demande de transfert doit être utilisé dans le
message de transfert qui suit.
Le message de transfert comprend les Objets-données à transférer et leurs métadonnées. Il est adressé
au Service d’archives par le Service versant.
Le Service d’archives émet à réception du message un accusé de réception de transfert à destination du
Service versant.
Le Service d’archives, après avoir vérifié que les informations transférées respectent toutes les
conditions définies dans l’Accord de service ou dans tout autre contrat accepté au préalable par les deux
parties, envoie une réponse (acceptation ou avis d’anomalie) dont le Service versant accuse la réception.
La réponse, en cas d’acceptation, peut comprendre les métadonnées des objets d’information transférés
afin que le Service versant puisse garder une trace de ce qu’il a envoyé.
À la fin de la transaction, en cas d’acceptation, les objets d’information ont été transférés du Service
versant au Service d’archives et la responsabilité de leur conservation incombe au Service d’archives, si
le processus de réception a été exécuté avec succès.
Figure 7 — Diagramme de séquence: Transférer
12 © ISO 2017 – Tous droits réservés

5.3.3 Communiquer
La Figure 8 représente la succession des messages que s’échangent le Service d’archives et ses
partenaires impliqués dans la transaction Communiquer.
La Demande de communication est effectuée par un Utilisateur (le producteur de ces informations ou
un tiers) qui souhaite consulter les informations conservées. Un Paquet d’information diffusé (DIP)
peut contenir tant les données elles-mêmes que les métadonnées associées ou seulement les premières
ou les secondes, ou la totalité ou seulement une partie de l’Objet-données archivé.
A réception de la Demande de communication, le Service d’archives doit émettre un accusé de réception
à destination de l’Utilisateur.
Si la Communication nécessite une autorisation, une ou plusieurs Demandes d’autorisation doivent être
insérées entre le message d’accusé de réception de la Demande de communication et le message de
réponse correspondant.
Après instruction de la demande et, si nécessaire, après réception de l’autorisation, une réponse doit
être envoyée par le Service d’archives à l’Utilisateur. Cette réponse peut être négative (par exemple
dans le cas où les informations demandées n’existent pas ou si le Service de contrôle s’y oppose) ou être
positive (auquel cas elle comprend les informations demandées).
Une fois la réponse reçue, l’Utilisateur émet un message d’accusé de réception.
Figure 8 — Diagramme de séquence: communiquer
5.3.4 Modifier
La Figure 9 montre les échanges de messages entre le Service d’archives et le Service producteur
pendant la transaction Modifier.
L’Accord de service doit permettre au Service d’archives de tenir à jour une liste des modifications
autorisées qui peuvent être faites sur les données archivées ou diffusées (notammen
...