Métadonnées

De Maarch MoReq2.

Voir également le chapitre 12 sur les exigences liées aux métadonnées.

Sommaire 1 Plan de classement 2 Entité[1] 2.1 Agrégation 2.1.1 Série 2.1.2 Dossier 2.1.3 Sous-dossier 2.1.4 Volume 2.2 Document 3 Extrait de document 4 Métadonnée témoin 5 Type de document 6 Composant 7 Règle de conservation/destruction et gel 8 Acteur 9 Entité/Acteur 10 Vue générale 11 Observations 12 Notes

Plan de classement

Entité^[1]

Dans le cas présent, cet objet ne recouvre les objets suivants :

• série,
• dossier,
• sous-dossier,
• volume,
• document,

ce qui n'est qu'un sous-ensemble de la définition exacte d'entité. Le descriptif couvre donc ici les concepts suivants :

• agrégation,
• et document.

Schéma complet des métadonnées en question :

Schéma des métadonnées communes à tous les objets décrits :

Agrégation

Schéma de toutes les métadonnées apparaissant dans au moins une agrégation :

Schéma des métadonnées communes à toutes les agrégations :

Série

Dossier

Sous-dossier

Volume

Document

Extrait de document

.

Métadonnée témoin

Voir également l'exigence 5.3.20.

Type de document

.

Composant

.

Règle de conservation/destruction et gel

Attention : ce schéma concerne théoriquement autant les gels que les règles de conservation/destruction. Néanmoins, les auteurs conseillent fortement de s'appuyer sur les métadonnées des entités pour modéliser deux objets distincts.

Acteur

Cette définition recouvre les objets :

• Utilisateur
• Goupe (d'utilisateur)
• Profil (d'utilisateur)

.

Fichier VYM pour Acteur.

Entité/Acteur

.

Vue générale

Vue générale des .

Les couleurs observent le code suivant :

• Vert : Plan de classement
• Noir : Entité (série, dossier, sous-dossier, volume, document)
• Orange : Extrait de document
• Rose : Métadonnée témoin
• Mauve : Type de document
• Bleu : Composant
• Vert foncé : Règle de conservation/destruction
• Rouge : Acteur
• Marron : Entité/Acteur

Les icônes « i » indiquent des métadonnées dont la traduction a du être adaptée (précisions disponible sous peu).

Observations

Ce chapitre présente quelques observations sur les métadonnées, leur définition et leur emploi.

new/previous_fully_qualified_classification_code 

Ou la confusion entre le passé, le présent et le futur. Trois métadonnées recouvrent la même signification - le code de classement complet - mais observée par un temps différent :

• « M012 - Description.classification.fully_qualified_classification_code » indique l'état présent du code de classement complet. Celui-ci est identifiant au sein d'un plan de classement.
• « M091 - Relation.previous_fully_qualified_classification_code », qui indique l'ancienne valeur avant reclassement. Sous-entendu que M012 - fully_qualified_classification_code a pris la nouvelle valeur après classification. Noter que cette métadonnée a été classée dans la catégorie Relation, qui définit que la métadonnée « pointe » vers un objet tiers, ce qui suggère deux possibilités :
  1. le code de classement complet est un objet à part entière, mais outre le fait que cela n'a aucun sens d'un point de vue conceptuel (« faire des objets avec des nombres »), pourquoi les deux autres métadonnées concernant les codes de classement complets ne sont-elles pas dans cette catégorie ?
  2. la métadonnée pointe vers l'objet contenant le précédent code de classement complet, c'est-à-dire le document avant reclassement, c'est-à-dire… un objet qui n'existe plus !
• « M158 - Description.classification.new_fully_qualified_classification_code », qui indique la nouvelle valeur du code de classement complet après reclassement.

Dans cette histoire à trois, en cas de reclassement il y a une métadonnée de trop. L'équipe Maarch.MoReq2 décide d'écarter la M158.

disposal hold 

Ou des acteurs au mauvais rôle. Les métadonnées M035 - Event_history.disposal_hold.agent_applied et M134 - Event_history.disposal_hold.agent_lifted se retrouvent dans la catégorie Event_history, alors qu'il s'agit bien en fait de relations avec un agent. À l'instar des M162 - Relation.agent.relocated et autres M161 - Relation.agent.deleted, ils auraient donc pu être « reclassés » dans la catégorie Relation, d'autant les actions de gel peuvent avoir un lien avec [la non-réalisation d'] une action de destruction.

_reason 

Ou des raisons qui ne sont pas des excuses. Les « motifs », nécessaires pour quelques-unes des actions définies dans le MoReq2, sont classés dans deux catégories distinctes - sans autre distinction :

• M126 - Description.abstract.reason_for_rendition est donc classé dans la catégorie Description ;
• M021 - Event_history.abstract.reclassification_reason est, lui, classé dans la catégorie Traçabilité (comme ses compatriotes M135 - Event_history.disposal_hold.applied_reason et M136 - Event_history.disposal_hold.lifted_reason mais qui font l'objet d'un autre commentaire).

Outre que l'on se demande pourquoi il y a inversion de la forme (reason_for_rendition vs. reclassification_reason), on peut s'interroger légitimement sur ce qui a pu exiler la M126 dans la Description alors qu'en toute logique - puisqu'elle correspond à la réalisation d'une action - elle aurait dû être dans la catégorie Traçabilité.

Description.author.author_name/Relation.agent.author 

Ou l'auteur débaptisé. D'un point de vue conceptuel, il est raisonnable d'admettre que le nom de l'auteur (M069 - Description.author.name) et son adresse de messagerie (M184 - Description.author.email_address) dépendent de la valeur de la métadonnée « auteur » (M190 - Relation.agent.author). Or ce n'est pas le cas selon ce modèle de métadonnées. En effet, M190 « pointerait » donc vers un objet « Agent » dont les métadonnées seraient entre autres M163 - Identification.system_identifier (en toute logique, la valeur de M190), M167 - Description.title qui pourrait correspondre également à son nom (M069) et M189 - Description.email_address qui correspondrait à son adresse de messagerie (M184).

En clair, les métadonnées M069 et M184 sont inutiles si M190 est renseigné - ce qui n'est pas ce que disent les descriptions de ces métadonnées.

Il en va de même pour les expéditeurs, destinataires et destinataires en copie.

conversion_identifiant_système 

Ou le document qui a deux identifiants systèmes. Citons l'annexe 9 : « [La M125 - Identity.system_identifier_rendition] est l'identifiant unique de la conversion d'un document. » Ceci suppose que lorsqu'il s'agit d'une conversion, il ne s'agit pas d'un document. Car le document a déjà son identifiant unique (M020). Mais le document a aussi la métadonnée M149 - Relation.is_rendition_of. Donc le document peut être une conversion. Et dans ce cas le document doit avoir la métadonnée M125. Mais le document a déjà son identifiant unique - nous venons de le dire.

Le document qui est une conversion a donc deux identifiants uniques.

Un seul - M020 - devrait suffire à la plupart des SAE.

Notes

1. ↑ Ce terme est utilisé notamment dans la traduction des métadonnées M084, M056 ou M057.