Présentation préliminaire du schéma VITAM conçu pour le versement d’archives : 2/3 - Les Métadonnées

Présentation préliminaire du schéma VITAM conçu pour le versement d’archives : 2/3

Les Métadonnées

Dans le cadre du programme VITAM, nous devons définir les interfaces externes de la solution logicielle que nous allons développer. Parmi ces interfaces, le schéma de données accompagnant un versement d’archives est un enjeu important.

Ce second billet porte sur une classification des métadonnées ainsi que leur placement respectif dans un schéma XML de versement. Nous n’abordons pas le schéma de « stockage » de ces métadonnées au sein du logiciel VITAM, tel que nous l’envisageons, car il ne s’agit plus des interfaces d’un système implémentant VITAM mais de son implémentation.

Toujours à titre personnel, ceci ne constitue pas une publication officielle mais un moyen de recueillir des avis avant la mouture finale, toujours avec appel à commentaires.

Pour rappel, nous nous plaçons dans le cadre des normes et règlements français, nous nous inspirons de la norme MEDONA de l’AFNOR (Z 44-022) qui permet de définir le sur-ensemble des échanges entre partenaires autour d’un Système d’Archivage Électronique (SAE). Nous nous inspirons également de MoReq2010 pour le modèle de données.

Comme pour le précédent billet, vous êtes bien sûr, vous lecteurs, plus que les bienvenus à apporter vos commentaires.

Les différents types de métadonnées

À l’appui des archives, différentes métadonnées existent et ont des rôles différents. Celles-ci, de par leur objet, ont des positionnements différents dans un modèle de données et pour un même objet d’archive, peuvent être multiples ou au contraire unique.

Il y a quatre types de métadonnées, comme illustré ci-dessous dans le schéma VITAM :

Illustration 1: Schéma VITAM

Dans Medona, le bloc ArchiveTransfer est un message comportant des informations liées aux éléments contractuels du transfert, ainsi qu’un objet DataObjectPackage qui permet de présenter la liste des DataObject transmis.

Nous avons modifié à la marge les définitions des BinaryDataObject et des PhysicalDataObject, mais la logique globale est la même, à savoir la possibilité de transférer des archives numériques et des archives papiers à l’aide d’un même formalisme XML.

Nous avons coupé en deux le bloc DescriptiveMetadata en DescriptiveMetadataPackage pour la partie métadonnées descriptives et de gestion, et le bloc TechnicalMetadataPackage pour la partie métadonnées techniques.

La présentation qui suit se veut succincte, le format d’un blog rendant difficile la publication in extenso d’une documentation d’un schéma XML. Cependant j’essaierais de proposer des schémas le plus explicites possibles pour rendre la compréhension la plus aisée possible.

Métadonnées de Transport (DataObject)

Les métadonnées de transport ont pour objet d’encadrer le transport de l’archive depuis le service versant jusqu’au service d’archives. En archives physiques, ces métadonnées sont en générales représentées par la demande de transfert et le bordereau de livraison par exemple. En numérique, ces métadonnées sont les éléments permettant de s’assurer de la bonne livraison (empreinte des fichiers, inventaires des objets transmis, l’identité de l’émetteur et du récepteur, le contrat applicable aux objets transférés, …).

Ces métadonnées constituent un bloc à part entière sous une forme de liste, pour tous les éléments concernés par le transport. Éventuellement, ces métadonnées peuvent être découpées en sous-ensembles, par lots, par exemple par carton, par container, par fichier ZIP. Elles sont uniques par objet d’archives ou par lot d’archives.

Exemple :

• Contrat de versement

<ArchivalAgreement>ArchivalAgreement0</ArchivalAgreement>

• Identité du service versant

<TransferringAgency>
  <Identifier>Identifier1</Identifier>
  <OrganizationDescriptiveMetadata>OrgDescrMd1</OrganizationDescriptiveMetadata>
</TransferringAgency>

• Liste des objets d’archive : un objet binaire suivi d’un objet physique

<DataObjectPackage>
  <BinaryDataObject>
    <Id>ID000</Id>
    <Uri>file://chemin/fichier</Uri>
    <Digest>
      <Value>ZGVmYXVsdA==</Value>
      <Algorithm>MD5-BASE64</Algorithm>
    </Digest>
    <Size>1600017170</Size>
  </BinaryDataObject>
  <PhysicalDataObject>
    <Id>ID001</Id>
    <PhysicalID>IdentifiantPhysique</PhysicalID>
  </PhysicalDataObject>

</DataObjectPackage>

Le schéma ci-dessous montre que les Binary/Physical DataObject sont sous forme de liste (entourés d’orange). L’objectif de cette partie est de pouvoir lister, recenser et contrôler la livraison d’un ensemble d’archives.

Illustration 2: Schéma VITAM - Transport

Ci-dessous est présenté la vision XSD avec la racine ArchiveTransfer contenant les blocs d’identification et le bloc DataObjectPackage. Celui-ci constitue le cœur du bloc transport.

Illustration 3: ArchiveTransfer

Le bloc BusinessRequestMessageType n’est pas détaillé car il est directement repris de la norme MEDONA.

Métadonnées Techniques (TechnicalMetadata)

Les métadonnées techniques décrivent les objets transférés quant à leur forme  : dimensions physiques, poids, matériaux pour les objets physiques ; taille en octets, MimeType du fichier, propriétés techniques du fichier selon son format, … pour les objets électroniques.

Ces métadonnées sont associées à chaque objet transféré, un par un. Comme il n’y a aucune relation entre eux sur ce niveau de description, les blocs de métadonnées techniques sont stockés sous la forme d’une liste. Elles sont uniques par objet d’archives.

Exemple :

• Format du fichier décrit : l’identifiant fmt/40 (au format Pronom) indique une référence à un format particulier (Word, PDF, …) pour le fichier décrit

<Identification>
  <FormatId>fmt/40</FormatId>
</Identification>

• Information sur le fichier

<FileInfo>
  <Size>50</Size>
  <Filename>OriginalFilename0</Filename>
  <Created>2006-05-04T18:13:51.0</Created>
</FileInfo>

Le modèle graphique du Schéma VITAM ci-dessous illustre la liste (cerclage orange) des nœuds TechnicalMetadataObject.

Illustration 4: Schéma VITAM - Technique

Ci-dessous est présenté la vision XSD avec la racine TechnicalMetadataPackage contenant des informations de contrôle et de contexte. Le bloc TechnicalPackage donne la possibilité de stocker les informations techniques dans un fichier XML à part, sa racine étant alors un objet du type TechnicalMetadata. Le bloc TechnicalMetadata lui-même contient le bloc TechnicalMetadataObject, qui constitue le cœur du bloc technique.

Dans le cas où les métadonnées techniques sont dans un fichier à part, les 3 premiers champs (Date, MessageIdentifier, ArchiveTransferMessageIdentifier) servent à identifier ce fichier :

• Date : sa date de création ;
• MessageIdentifier : identifiant unique de ce fichier XML ;
• ArchiveTransferMessageIdentifier : identifiant unique du fichier de transport auquel il se rapporte.

Illustration 5: TechnicalMetadataPackage

Illustration 6: TechnicalMetadata

Dans le bloc TechnicalMetadataObject, on retrouve la description technique de l’objet transféré, à savoir :

• Pour le numérique, son identification (son format), les informations liées à la genèse du fichier (date de création, outils et système d’exploitation utilisés pour sa création, …), et des informations techniques plus détaillées en fonction de son format (selon que c’est un fichier texte, un document, une image, une vidéo, un fichier audio, …) ;
• Pour le physique, ses dimensions physiques.

Illustration 7: TechnicalMetadataObject

Métadonnées de Gestion (LevelManagementMetadataContent)

Les métadonnées de gestion ont pour objet de rassembler l'ensemble des informations utiles à la gestion dans le temps de l'objet archivée : durée de conservation, règles d'accès, etc. Elles concernent donc très majoritairement des informations liées au métier des archives, et en particulier aux informations utiles pour le système d’archivage électronique.

Ces métadonnées peuvent être communes à tous les objets transférés ou spécifiques à chacun d'entre eux. Dès lors que les métadonnées associées à ces objets sont représentées sous forme de graphe, elles doivent se retrouver à chaque niveau de celui-ci. Par ailleurs, en raison des multiples héritages, elles peuvent être multiple pour un même objet transféré.

Exemple :

• Règle associée à la durée de conservation

<AppraisalRule>
  <Rule>
    <StartDate>2006-05-04</StartDate>
    <RefRuleId>RefRuleId2</RefRuleId>
  </Rule>
  <RefFinalActionRule>Conservation</RefFinalActionRule>
</AppraisalRule>

• Règle de restriction d’accès

<AccessRestrictionRule>
  <Rule>
    <StartDate>2006-05-04</StartDate>
    <RefRuleId>RefRuleId4</RefRuleId>
  </Rule>
</AccessRestrictionRule>

Illustration 8: Schéma VITAM - Gestion

Le bloc LevelManagementMetadataContent est porté par le bloc LevelDescriptiveMetadata (voir ci-après dans le chapitre Métadonnées Descriptives (DescriptiveMetadata)) et contient donc ces informations de gestion des archives.

Le bloc LevelCreationControl est un bloc spécifique à VITAM qui permet de spécifier un emplacement arbre de métadonnées préexistant dans le SAE auquel il faudra raccrocher les archives correspondantes via des requêtes embarquées dans l’XML pour la gestion des nœuds du plan de classement. Il s’agira de permettre de relier un sous-arbre à un plan de classement pré-existant (par exemple le rajout d’un nouveau dossier à un Sous-fond existant).

Illustration 9: LevelManagementMetadataContent

• Différentes règles de gestion peuvent être appliquées. Globalement, les règles s’expriment toutes selon un format similaire :
  • l’usage d’une date de démarrage et d’une règle qui permet de référencer une raison et une durée pendant laquelle cette règle à partir de la date précisée ;
  • le moyen de gérer l’héritage de règles précédemment positionnées dans l’arbre dans des niveaux parents ;
  • l’action déclenchée en fin de validité de l’ensemble des règles si une telle action existe ;
  • ainsi que l’indication si une autorisation est néanmoins nécessaire même si les règles indiquées sont obsolètes ou non applicables (pour forcer le contrôle d’accès par exemple)
• On retrouve les règles suivantes (toutes optionnelles) qui suivent ce format :
  • StorageRule : règles de conservation métier (au sein de l’application métier d’origine), afin de gérer les contraintes liées à la mise en œuvre de la loi Informatique et libertés (selon ce qui est parfois appelé durée d'utilité courante)
  • AppraisalRule : règles de conservation en archivage intermédiaire (selon la durée d’utilité administrative) et le sort final associé
  • AccessRestrictionRule : règles de restrictions d’accès (selon les règles définies par le code du patrimoine pour les archives publiques)
  • DisseminationRestrictionRule : règles de restriction de diffusion, en fonction des contraintes associées à la loi Informatiques et liberté s et au au code de la propriété intellectuelle
  • ReuseRestrictionRule : règles de restriction de réutilisation, en fonction des contraintes imposées par la loi CADA
  • ClassificationRule : règles de confidentialité, notamment en lien avec la protection du secret de la défense nationale, avec un format spécifique pour définir la classification d’un niveau (ou d’un objet d’archives) en précisant :
    • une règle applicable, le niveau de classification, la mention associée, le propriétaire de la classification,
    • la date de réévaluation de cette classification et s’il y a nécessité de disposer explicitement d’une autorisation pour l’évaluation de la reclassification.

Métadonnées Descriptives (DescriptiveMetadata)

Les métadonnées descriptives regroupent a priori les métadonnées qui ne sont pas contenues dans les groupes précédemment définis. Elles constituent les informations intellectuelles accompagnant les objets transférés afin de permettre leur description, leur classement ou leur recherche.

Ces métadonnées sont à associer au plan de classement d’un objet transféré. En effet, les descriptions d’un objet peuvent dépendre du plan de classement où se trouvent celui-ci. Ces métadonnées devront donc se retrouver dans le plan de classement et pourront donc être multiples pour chaque objet d’archive.

Exemple :

• Titre
  <Title>Title0</Title>
• Signataire
  <Signer>
    <BirthName>BirthName0</BirthName>
    <GivenName>GivenName0</GivenName>
    <FirstName>FirstName0</FirstName>
  </Signer>

Le schéma graphique ci-dessous illustre le package DescriptiveMetadataPackage qui contient un DescriptionMetadata lui-même contenant de 1 à n (une liste) de LevelDescriptiveMetadata. Ce bloc LevelDescriptiveMetadata est lui-même récursif (encerclé de rouge) et constitue le bloc principal des métadonnées descriptives. Il contient différents groupes et présente une définition récursive (il contient lui-même un LevelDescriptionMetadata – voir la présentation du modèle arborescent dans le précédent article - ).

Illustration 10: Schéma VITAM - Descriptif

Les schémas XML ci-dessous illustrent les différents blocs pour la description et en particulier le bloc LevelDescriptiveMetadata qui en est le cœur.

Dans le cas où les métadonnées descriptives sont dans un fichier à part, les 3 premiers champs (Date, MessageIdentifier, ArchiveTransferMessageIdentifier) servent à identifier ce fichier :

• Date : sa date de création ;
• MessageIdentifier : identifiant unique de ce fichier XML ;
• ArchiveTransferMessageIdentifier : identifiant unique du fichier de transport auquel il se rapporte.

Illustration 11: DescriptiveMetadataPackage

Illustration 12: DescriptiveMetadata

Zoom sur LevelDescriptiveMetadata

Le schéma qui suit illustre les blocs particulièrement importants du bloc LevelDescriptiveMetadata.

Illustration 13: LevelDescriptiveMetadataType

LevelDescriptiveMetadata (1) est défini :

• soit par référence à un bloc précédemment défini dont la référence est stockée en (2), permettant le multiple héritage ou le multi-classement (voir l’article précédent sur les multiples classements),
• soit par un autre fichier en (3),
• soit enfin par le bloc d’information qui suit (commençant par le champ Id).

La récursivité (la définition d’un arbre : à partir d’un nœud, définir le ou les sous-nœuds) sur ce type est réalisée :

• par un niveau suivant déclaré en (7),
• par référence depuis un bloc pré-existant dans le SAE lui-même via une requête en (8).

La récursivité est arrêtée (fin d’un plan de classement, positionnement éventuel d’objets d’archives) :

• soit via un NullObject en (9) permettant la définition d’un plan de classement sans réel versement d’objets (il s’agit de ne verser donc que le plan de classement en avance de phase, avant que les archives ne viennent réellement remplir ce dernier),
• soit via la présence de 1 ou plusieurs DataObjectReference en (10) pouvant être :
  • soit de type simple DataObjectId en (11),
  • soit de type groupe DataObjectGroupId en (12). Un DataObjectGroupId constitue un ensemble de fichiers d’archives représentant le même objet intellectuel mais sous des formes différentes (versions de conservation, de diffusion, plein texte, vignette, …).

LevelManagementMetadataContent (4) contient la partie des métadonnées de gestion qui ont été décrites dans la partie précédente.

Les métadonnées de description pour ce niveau (fond, sous-fond, … pour chacun des niveaux) sont placés :

• dans le bloc LevelDescriptiveMetadataContent en (5) pour la partie en accès libre,
• et le bloc LevelRestrictedDescriptiveMetadataContent en (6) pour la partie en accès restreint.

La notion d’accès libre et restreint dépend de l’application de frontale de consultation.