Guide d'implémentation des métadonnées gouvernementales

Quels objectifs doivent être visés par un profil de métadonnées normalisées pour l'ensemble du Gouvernement du Québec (nous utilisons « profil » au singulier, étant pleinement conscient qu'un tel profil serait composé de deux sous-profils, pour deux grandes classes de documents)? Voyons d'abord quelques possibilités d'objectifs et leurs faiblesses.

S'agit-il d'avoir un profil unique qui conviendrait à tous les documents gouvernementaux sans exception et qui suffirait à effectuer tous les traitements possibles sur ces documents? Non, puisqu'un tel profil serait fabuleusement complexe. En effet, les profils normalisés existants comme le MARC, les RDDA, le Dublin Core et les divers profils de type GILS sont tous justifiés pour certains types d'opération à effectuer sur les documents. Il faudrait donc forcément qu'un profil « universel » subsume tous les profils existants, d'où notre conclusion d'une trop grande complexité. Puisqu'une trop grande complexité implique la nécessité de recourir à des spécialistes pour la création et l'exploitation des métadonnées, cette approche n'a pas sa place dans le contexte du CRGGID. D'ailleurs, est-ce qu'une même personne pourrait être spécialiste d'un profil de métadonnées qui subsume le MARC et les RDDA, pour ne citer que ces deux profils?

S'agit-il d'avoir un profil universel, mais exclusivement axé vers la recherche d'information? Un tel profil ne serait en effet pas dénué d'intérêt puisqu'il permettrait la constitution d'un outil de recherche universel, une espèce de « super Google » gouvernemental permettant de repérer tout document gouvernemental, peu importe son type, sa localisation et son support. Mais la principale lacune de cette approche, en regard des objectifs du CRGGID, serait de n'offrir aucune aide (directe, en tout cas) pour satisfaire les exigences d'une gestion documentaire rigoureuse, laquelle est maintenant une obligation bien définie pour l'administration publique québécoise, en vertu de la Loi concernant le cadre juridique des technologies de l'information. En effet, de par l'universalité souhaitée d'un tel profil, il devrait forcément être très simple, par exemple, un sous-ensemble du Dublin Core (un peu comme le Gouvernement fédéral préconise pour les documents Web). Alors, les métadonnées nécessaires à une gestion documentaire conforme aux exigences de la loi précitée en serait nécessairement exclues.

Par ailleurs, une autre lacune de l'approche « profil universel pour la recherche » est que, encore une fois à cause de sa simplicité obligée, elle n'offre aucune aide pour la conservation à long terme des documents, ni pour la disposition des documents lorsqu'ils n'ont plus de valeur primaire. Or, c'est un des objectifs du CRGGID de tenir compte de ces problématiques.

Avant de poursuivre notre recherche d'objectifs réalistes pour un profil normalisé de métadonnées, nous devons rappeler que les métadonnées d'un même document peuvent avoir différents emplacements de stockage par rapport au document, de même que différentes personnes comme source, les deux phénomènes étant d'ailleurs reliés. Ces phénomènes résultent du fait que certaines métadonnées applicables à un document proviennent du (ou servent à renseigner sur le) contexte de création ou d'existence du document. Tant que le document demeure dans son contexte originel, il n'est pas nécessaire que les métadonnées correspondant au contexte soient intégrées dans le document lui-même. En effet, les éléments constitutifs du contexte étant accessibles tout autant que le document au moment où on le consulte, ces informations pourraient (en théorie, en tout cas) être récupérées directement du contexte plutôt que du document. Par contre, dès que l'on déplace le document hors de son contexte originel, toutes les métadonnées que l'on désire conserver doivent être extraites du contexte et placées ailleurs, par exemple dans le document lui-même ou dans une base de données (d'où il doit être possible de faire le lien avec le document, si on veut que ces métadonnées soient exploitables).

Le document papier (i.e., dont l'original légal à gérer est sur papier) a une situation particulière par rapport à l'emplacement de stockage des métadonnées. En effet, les métadonnées dont nous parlons ici sont des métadonnées ordinolingues et doivent donc forcément être stockées informatiquement, par exemple dans une fiche de base de données. Conséquemment, on pourrait dire qu'aucune métadonnée d'un document papier n'est stockée dans le document lui-même.

Puisque les métadonnées ne proviennent pas tous du même endroit, il est logique que ce ne soit pas forcément les mêmes personnes qui soient responsables de leur spécification (nous n'utilisons pas le mot « saisie » ici, puisqu'il est trop précisément lié à l'action d'entrer la spécification d'une valeur dans un ordinateur). Illustrons le phénomène avec un exemple: supposons qu'on est en présence d'un profil de métadonnées qui comporte une métadonnée « sujet » (obligatoire), et supposons qu'un système administratif produise des instances de formulaires d'un certain type; il y a fort à parier que pour la métadonnée « sujet », l'ensemble des instances doive avoir la même valeur. Il est assez clair que la meilleure personne pour spécifier la valeur de cette métadonnée n'est pas l'individu qui remplit une instance spécifique du formulaire, mais plutôt l'architecte du système d'information (ou même, du processus d'affaires sous-jacent), ou un spécialiste de l'information qui le conseille.

Pour résumer, certaines métadonnées dépendent du contexte de création ou d'existence du document; à ce titre, elles sont identiques pour tous les documents dans ce même contexte; il y a donc économie à réaliser dans la saisie de cette métadonnée en la spécifiant non pas au moment de la sauvegarde du document, mais au moment de la mise sur pied du système de création des documents; ce n'est donc pas la personne qui sauvegarde le document qui spécifie la valeur de cette métadonnée, mais bien le concepteur du système, ou un spécialiste de l'information agissant comme conseiller au moment de la conception du système. La valeur de métadonnée est donc associée au système qui crée l'instance de document, et non à l'instance spécifique; elle peut être incluse dans chaque instance, puisqu'elle est connue au moment où chaque instance est sauvegardée pour la première fois, mais ce n'est pas nécessaire; elle est connue implicitement de par le contexte de création de l'instance.

Notons que les phénomènes de diversité des sources et des emplacements de stockage des métadonnées peuvent être exploités d'au moins quatre façons pour diminuer la complexité apparente du profil au moment où monsieur tout-le-monde saisit des métadonnées:

Donc, que peut-on espérer et exiger d'un profil normalisé pan-gouvernemental de métadonnées? D'une part, nul doute que l'utilisabilité universelle du profil recherché pour la saisie des métadonnées est essentielle; en d'autres termes, il faut que n'importe quelle personne susceptible de produire un document institutionnel au gouvernement puisse fournir facilement les métadonnées requises d'elle, et ce sans aucune formation ou, au pire, avec une très légère formation, du genre tutoriel en ligne de quelques minutes. À notre avis, si ce principe d'utilisabilité universelle pour la saisie n'est pas respecté, l'adoption massive du profil retenu est impossible. La simplicité découlant de ce principe, d'ailleurs, a l'effet secondaire intéressant de permettre également la recherche d'information universelle. Par contre, une complexité minimale semble nécessaire pour permettre une gestion documentaire rigoureuse, exigée par la loi.

Nous avons donc, comme souvent, deux objectifs au moins en apparence contradictoires: d'une part, complexité suffisante; d'autre part, complexité minimale. Cela laisse penser qu'il faudra rechercher une solution de compromis; et également qu'il faudra probablement tabler sur de l'ingéniosité dans le déploiement du profil retenu. Concrètement, cela voudrait dire exploiter au maximum les phénomènes de diversité des sources et des emplacements de stockage des métadonnées, pour diminuer la complexité apparente du profil au moment de la saisie des métadonnées.

Notons que, comme genres d'opération devant être rendus possibles par le profil de métadonnées retenu, nous n'avons mentionné jusqu'ici spécifiquement que la gestion documentaire rigoureuse et la recherche d'information. Pourquoi ces opérations et pas certaines autres, comme la constitution automatique de catalogues dans les règles de l'art bibliothéconomiques, ou encore la constitution automatique d'instruments de recherche archivistiques? D'une part, tout document doit être géré, quel que soit son type; de plus, la gestion documentaire est la seule opération qui soit régie par la loi (pour les besoins du discours, nous nous permettons ici de voir l'ensemble de la gestion documentaire comme une seule opération, si complexe soit-elle). D'autre part, la recherche d'information occupe une place privilégiée, non seulement au sein de la gestion documentaire, mais dans tout type d'opérations relié aux documents. C'est la base même de l'exploitation et de la réutilisation de l'information, deux des finalités principales de la gestion de l'information en général.

Ces considérations nous amènent à formuler un premier objectif.

Notons tout de suite que l'exploitation préconisée des phénomènes de diversité des sources et des emplacements de stockage des métadonnées n'implique pas nécessairement que le profil retenu n'existe que virtuellement. Il est tout à fait possible d'exiger qu'à partir d'un document quelconque, on puisse, par un jeu de pointeurs, retrouver l'entièreté des métadonnées qui lui sont associés. C'est d'ailleurs ce que nous prévoyons préconiser dans la méthodologie du CRGGID.

Que faire avec les profils existants spécialisés évoqués ci-dessus, comme le MARC et les RDDA? Il est indéniable que ces profils sont très largement utilisés dans le monde et qu'ils sont pris en charge par de nombreux systèmes informatiques, commerciaux ou autres. Le profil normalisé retenu devrait offrir la plus grande interopérabilité possible avec ces profils existants. Puisque le profil retenu ne subsumera pas l'ensemble des profils existants, il est clair que l'interopérabilité ne pourra pas être complète. Il est cependant réaliste de se fixer l'interopérabilité à sens unique, en importation, comme objectif. Cela veut dire qu'à partir des fiches descriptives conformes à l'un des profils existants, on devrait pouvoir dériver automatiquement des fiches descriptives conformes au profil normalisé. Une telle dérivation pourrait bien évidemment tabler sur les phénomènes de diversité des sources et des emplacements de stockage des métadonnées; par exemple, lors de l'exportation d'un catalogue de bibliothèque en MARC vers le profil normalisé, une valeur fixe prédéterminée et adéquate pourrait être insérée automatiquement comme valeur de la métadonnée « règle de conservation » , en supposant qu'une telle métadonnée figure dans le profil normalisé.

Nous formulons donc notre second objectif.

Comment le CRGGID devrait-il se positionner par rapport à la gestion des archives définitives (ou historiques)? À notre avis, il devrait recommander des pratiques qui facilitent les versements aux ANQ prévus par la loi sur les archives, de même que les traitements qui y sont effectués. Comme on peut envisager qu'à plus ou moins long terme, les ANQ s'orienteront vers un service OAIS avec comme schème de description les RDDA (ou une variante internationale actuellement en développement, mais qui devrait vraisemblablement ressembler aux RDDA), il semble raisonnable que, dans la mesure du possible, le profil retenu soit compatible avec les RDDA, dans le sens qu'il facilite le plus possible la constitution de descriptions RDDA des fonds (ou composants de fonds) versés aux ANQ. Cependant, comme seulement 5% environ de tous les documents administratifs sont appelés à être conservés à titre d'archives définitives, une telle compatibilité ne devrait être qu'un souhait et ne devrait pas orienter très fortement les spécifications du profil retenu. Nous pouvons cependant formuler un troisième objectif.

Le DC est un profil de métadonnées très populaire. Il peut donc être intéressant, a priori, de viser la plus grande interopérabilité possible avec ce profil. Comment un profil normalisé devrait-il se situer par rapport au DC?

Il ne serait pas très réaliste de viser l'interopérabilité à sens unique en importation avec le Dublin Core, car le Dublin Core est un profil conçu pour la recherche universelle accessible. Il n'est pas assez riche (ne serait-ce que parce qu'aucun élément n'est obligatoire!). Pour ce qui est de l'interopérabilité à sens unique en exportation (produire des fiches Dublin Core à partir des fiches du profil retenu), il faudrait pratiquement faire exprès pour ne pas l'avoir, étant la pauvreté du DC.

Les métadonnées peuvent se situer à deux niveaux : internes et externes. Les métadonnées internes peuvent être générées automatiquement par une application ou saisies par l’utilisateur lui-même. Un document Word, par exemple, contient de nombreuses métadonnées générées automatiquement par l’application (le type de document, la taille du fichier, la date de création, etc.) et peut en contenir d'autres, ajoutées manuellement par l'utilisateur (à l'aide de la fonction Propriétés du menu Fichier). Quand aux métadonnées externes, on les nomme ainsi parce qu'elles sont gérées dans un système externe au contenu : par exemple, un catalogue de bibliothèque. On dit alors que les métadonnées sont externes aux ressources qu’elles décrivent.

Ce sont les deux principales façons d'utiliser les métadonnées : les inclure dans les ressources mêmes ou les enregistrer dans une fiche à part, liée d'une façon quelconque à la ressource. Il existe également une troisième façon plutôt utilisé pour la conservation ou la circulation des documents : l'encapsulation. Le document conserve son format original et est inséré dans une enveloppe XML. L'enveloppe conserve des métadonnées à propos du document, dont: des données descriptives du document (auteur, titre, date de création, etc.) le type MIME des données journalisées de l'administration de l'objet conservé (enveloppe et document) des données de conservation de l'objet.

De façon générale, le terme de métadonnée est associé à l'environnement numérique et plus particulièrement à la description des ressources du web. Si les métadonnées existaient bien avant Internet et le Web, ce n'est qu'avec l'augmentation grandissante des ressources en ligne (bibliothèques numériques, édition électronique, etc.) que s'est développé un intérêt mondial pour des normes descriptives et de nouvelles pratiques aptes à améliorer la recherche d'information. De même pour les organismes privés et publics pour qui la masse sans cesse croissante de documents numériques créés dans leurs activités quotidiennes cause de sérieux maux de tête! Surtout que, de plus en plus, ces documents sont conservés dans leur format original, certains d'entres eux ne se matérialisant même plus sur support papier durant tout leur cycle de vie!

Les documents numériques que l'on crée à l'aide d'application bureautiques ou autre contiennent de nombreuses métadonnées implicites ou explicites, comme nous l'avons vu précédemment avec notre document Word. Dans le cas des pages web, les métadonnées sont souvent internes et se situent dans le code source lui-même. Les métadonnées d'un document HTML, par exemple, se situent généralement entre les balises <head> dans l'en-tête du document, comme le montre l'exemple suivant :

On remarque dans cet exemple que les métadonnées se divisent en deux parties. La première partie, le nom, précise la caractéristique décrite : meta name="title" . La deuxième partie, le contenu, contient l'information au sujet de la caractéristique décrite : content="L'Énergie au Québec". L'ensemble de ces deux parties constituent l'unité de base des métadonnées. On appelle cette unité de base élément de métadonnées.

Un système informatique est interopérable lorsqu'il a la capacité de communiquer, ou de fonctionner, avec un autre système, que ses programmes peuvent partager des données et des ressources. Si l'on revient à nos métadonnées, cet efficacité d'échange est impossible à atteindre si, par exemple, la métadonnée « auteur » d'une ressource est appellée dans un ministère X Auteur, dans un ministère Y Créateur et dans un organisme Z Author. Ces trois entités ne pourront échanger leur information qu'après concertation et développement de passerelles de conversion. La chose est tout aussi vraie s'ils souhaitent échanger des données avec le monde extérieur. Ainsi, plus il y a d'entités qui partagent un langage commun, plus les échanges peuvent être fructueux. C'est de ce constat qu'est né le Dublin Core Metadata Initiative (DCMI) dont le modèle a inspiré les profils de métadonnées gouvernementales.

Le Dublin Core Metadata Initiative (DCMI) est le premier ensemble de métadonnées normalisé à avoir vu le jour. Il s'agit d'un jeu de 15 métadonnées destinées originellement à la description des pages Web. La liste de ces métadonnées fut définie en 1995 par des équipes (du monde des bibliothèques et de la publication) impliquées dans la sémantique du Web lors d'un atelier à Dublin (Ohio). Le Dublin Core (DC) n'est pas une norme mais une initiative internationale, basée sur un consensus et entièrement ouverte. Si le DC définit des métadonnées, il ne décrit pas la façon de les représenter en pratique et offre, de ce fait, une grande liberté d'utilisation..

Supporté par le W3 Consortium depuis 1998, le Dublin Core est devenu en 2003 une norme ISO (en voie de publication). Le standard DC est en outre le format minimum de l'Open Archives Initiatives (OAI) qui permet, via l'interopérabilité des serveurs, l'exposition et la récolte de métadonnées. Il a également été récemment approuvé par le National Information Standards Institute (NISO) comme standard numéro Z39.85 et par l'American National Standards Institute (ANSI) sous le numéro Z39.85-2001. Le modèle Dublin Core est à la base de plusieurs ensembles de métadonnées utilisés à travers le monde qui le reprennent intégralement ou s'en inspire.

Les 15 métadonnées Dublin Core peuvent être répartis en 3 groupes :

Que ce soit pour la description de leurs ressources en ligne ou de leurs documents numériques créés dans le cadre de leurs activités, un ensemble de plus en plus grand de gouvernements, (le Canada, l'Australie, le Royaume-Uni, les États-Unis, de la Finlande, etc.) utilisent les métadonnées dans une forme normalisée. Ainsi, pour mettre en place son programme de modernisation de l'État, le gouvernement brittanique publiait en mai 2003 une deuxième version du e-Government Metadata Standard en arguant du fait que la structuration et la conformité des métadonnées est nécessaire à travers l’ensemble des organismes du gouvernement. Les institutions d'archives nationales participent activement à la mise en place de métadonnées normalisées pour leur gouvernement. C'est le cas des Archives nationales du Canada et des Archives Nationales d'Australie qui ont développé chacun un ensemble de métadonnées normalisé basé sur le Dublin Core.

Les 27 métadonnées gouvernementales sont considérés comme suffisantes pour les besoins identifiés par le Comité de métadonnées. Toutefois, le modèle gouvernemental est extensible afin de rendre compte de besoins plus spécifiques. Son extensibilité prend deux sens : on peut développer une métadonnée existante ou en créer une nouvelle en suivant certaines règles. Une métadonnée peut avoir des Propriétés. Il existe deux sortes de propriétés : l'enrichissement et le schème d'encodage. L'enrichissement permet de préciser le sens d'une métadonnée, ou d'en restreindre la portée. Il correspond à l'aspect sémantique du mot. Le schème d'encodage sert à imposer une façon d'écrire la valeur de la métadonnée. Il impose une syntaxe.

Si le modèle gouvernemental devait être représenté graphiquement de façon abstraite, voici ce dont il aurait l'air :

Les éléments de métadonnées gouvernementales peuvent :

Le modèle gouvernemental proposé ici adhère à ce que Dublin Core appelle le Dumb-down Principle. Il s'agit d'une règle destinée à garantir que l'application des qualificatifs ne nuit pas à l'intéropérabilité. Elle stipule que les qualificatifs peuvent raffiner mais non prolonger la signification de l'élément auquel ils sont appliqués. Ainsi, on peut ignorer un qualificatif et la valeur qui en résulte, si elle perd un peu de précision, conserve son utilité pour une application informatique ou un utilisateur : « A rule for the application of Interoperability Qualifiers, which stipulates that qualifiers can refine but not extend the meaning of the element to which they are applied. Thus, ignoring a qualifier ("dumbing down" the qualifier) may cause a loss of precision, but the resulting value should still be of some use to an application or user. @@  ».

Pour en savoir plus sur les métadonnées gouvernementales, se référer au document Profils de métadonnées pour les documents gouvernementaux. Présentation revisée suite à la réunion du 15 mai 2003 du Comité

Avant de procéder au développement d'un élément de métadonnée, suivez ces quelques règles :

Rappelons que les enrichissements permettent de préciser le type de valeur que l'on souhaite obtenir en restreignant (ou en précisant) la signification d'un élément. Les enrichissements répondent à deux principes fondamentaux :

Les schèmes d'encodage imposent une façon d'écrire les valeurs associés aux champs. Lorsque l'on associe un schème d'encodage à un élément (ou un enrichissement), la valeur du champ sera interprétée en fonction du schème identifié. Un schème d'encodage peut-être un mot ou une expression sélectionnée à partir d'un vocabulaire contrôlé (thésaurus ou autre), une chaîne de caractères formatée selon une notation formelle (ISO, par exemple), un plan de classification, etc.

L'utilisation de schèmes d'encodage est fortement recommandé dans un but de normalisation.

Selon le type de ressources que vous avez à décrire, vous choisirez l'un ou l'autre des profils gouvernementaux. Ceux-ci sont personnalisables dans une certaine mesure. La première étape serait donc de passer les profils et de les tester avec quelques ressources. Vous pouvez, par exemple, pour une ressource donnée, saisir le contenu de chaque élément d'un profil de façon informelle (à la main sur une feuille de papier ou dans un fichier texte). L'exercice devrait être fait avec différents types de documents, afin de valider le profil avec vos besoins spécifiques. Cela vous permettra de mettre en lumière les éléments problématiques, inutiles, voire même absents du profil. À partir de ces informations, vous pourrez adopter le profil tel quel s'il vous convient ou choisir de le personnaliser.

Une autre option est de créer un tout nouveau profil spécifique à votre organisation. En ce cas, vous devez être en mesure de justifier ce choix et obtenir l'approbation d'un supérieur hiérarchique. Voici quelques règles de base à suivre pour vous permettre de faire un choix :

Dans la plupart des cas, les profils de métadonnées gouvernementales sont tout à fait pertinents et leur utilisation est fortement conseillée. Cependant, il peut arriver qu'un ministère ou un organisme ait des besoins spécifiques dont ne peuvent rendre compte les profils existants. Il est possible également qu'en certains lieux le volume d'information circulant soit réellement trop important pour que les employés aient le temps de remplir toutes les métadonnées de l'un ou l'autre des profils. Cependant, une petite mise en garde s'impose.

Pour plusieurs, l'idée de développer un profil très court, rapide et facile d'utilisation peut sembler alléchante. Un tel choix n'est pas gagnant à long terme. En effet, moins une ressource a de métadonnées et plus les risques liés à une mauvaise gestion, à la perte ou à l'erreur sont élevés. De même, la recherche sera beaucoup moins efficace, les résultats moins précis et probants, si une ressource, et plus particulièrement une ressource numérique, à peu de métadonnées. Enfin, l'authenticité et l'intégrité d'un document numérique peuvent difficilement être préservées si l'on ne possède pas certaines informations sur celui-ci, ce qui est particulièrement important pour les documents ayant une valeur probante.

Tout bien pesé, prendre 15 ou 20 minutes pour documenter une ressource que l'on a mis des mois à créer ou qui a une valeur particulièrement grande, ce n'est pas trop long! Malgré cela, nous croyons qu'il sera toujours préférable d'adopter un profil plus restreint, utilisé uniformément, que de remplir à moitié, au gré des utilisateurs, les métadonnées d'un profil plus long.

Un profil peut être personnalisé de deux façons : en y ajoutant des éléments ou en y retirant des éléments. On peut ainsi développer des éléments existant, ou en créer de nouveaux, et retirer des éléments existants. Il est impossible cependant de retirer des éléments qui ont pour statut la mention Obligatoire. Toutefois, ceux-ci peuvent être développés.

Lorsque l'on parle de développer un élément, cela signifie ajouter des propriétés. On peut ajouter des propriétés à une métadonnée ou à un enrichissement. Il y a deux types possible de propriétés : enrichissement et schème d'encodage.

Vous avez obtenu l'autorisation pour développer un nouveau profil adapté à votre organisme ou ministère. Les règles ci-dessous vous guideront dans votre démarche :