Cette section fait l’objet d’un chapitre afin de bien marquer l’importance de la prise en compte de l’édition des méta données dans un système de collecte intégré à un système de gestion de contenu. Cependant, les méta données peuvent faire partie d’un document ou être à l’extérieur du document. Il s’agit en fait de définir comment intégrer le processus de création de contenu avec le processus de description de contenu. En effet, il peut s’agir d’une même tâche (avec un même opérateur) dans certains cas ou de tâches différenciées dans d’autres cas (avec éventuellement plusieurs opérateurs).
L’édition des méta données est fondamentale pour assurer la cohérence, la richesse et finalement la productivité d’un système de gestion de contenu.
Parmi les clés de la productivité du CMS, il y a l’automatisation de la « saisie » des méta données.
Revenons sur l’exemple de la saisie d’un nom de lieu dans un document (voir chapitre 3.1.1.2). Il n’y pas forcément lieu de considérer dans le texte le nom de lieu comme un composant documentaire, stocké et géré par le système. Contrôler le vocabulaire pour le récupérer et l’indexer efficacement est suffisant. Par contre, si un nom de lieu est cité dans un texte, il peut être utile de renseigner une propriété du document descriptive concernant la couverture spatiale (voir 2.3.1.1 « Données descriptives »). L’éditeur, réagissant à l’événement de saisie d’un nom de lieu, grâce à son thésaurus associé, provoque une action : par exemple, une liste déroulante à la suite du nom dans laquelle le rédacteur choisit la valeur adéquate. Suite à ce choix, la méta donnée couverture spatiale33 pour le document peut-être renseignée avec la valeur du thésaurus de nom de lieu. Le rédacteur, ou une autre personne désignée pour cette tâche dans une chaîne d’édition, validera cette valeur lors de l’édition des méta données. Il s’agit là d’aide à l’édition de méta données et non pas d’une automatisation complète. Mais dans 95 % des cas, cette aide sera exacte et n’aura pas à être
corrigée ou reprise.
Considérons maintenant l’auteur d’un document. Lorsqu’un utilisateur informatique accède à une ressource, c’est généralement parce qu’il en a le droit et qu’il s’est préalablement authentifié (logué) dans le système. Son identification (son nom notamment) dès lors peut être accessible par l’éditeur de document. Il faut dans ce cas automatiser la valeur de la saisie de la propriété « créateur », comme cela se fait d’ailleurs avec MS Word Edition Professionnelle. Le renseignement des dates est aussi du ressort de l’éditeur et du système de gestion de contenu. Quand un document est soumis pour approbation, la propriété dateSubmitted peut être renseignée automatiquement. Quand un utilisateur détermine les droits d’accès d’un document, le fichier ACL (Access Control List) correspondant peut être intégré à l’élément « Rights ».
Il y a le cas aussi des méta données inclues dans le document. Nous avons abordé cela déjà dans le chapitre intitulé « Gestion des références explicites » page 26 pour ce qui concerne les références explicites. Concernant les liens de composition, ils sont automatisables lors de la composition du document original. Par exemple, si une image est incluse dans un document html, on peut déduire la valeur de la propriété isPartOf (et celle de son inverse hasPart) pour l’image et le document html. On a aussi postulé (section 2.3.1.2 « Données d’application ») qu’a priori toutes les méta données d’applications peuvent être automatiquement saisies.
Mais il y en a d’autres que nous n’avons pas mentionnées : par exemple, le titre, la version34, l’auteur, etc.. L’éditeur doit proposer un moyen de ne pas avoir à ressaisir ces méta données. Il peut, par exemple, proposer un formulaire de propriétés accessible par un menu dans laquelle sont saisies ces informations et qui sont ensuite reprises automatiquement, via la programmation du modèle, dans le document.
Le renseignement de la plupart des méta données est automatisable. Dans certains cas, il peut faire l’objet d’une génération automatique (résumé automatique, catégorisation automatique) et être ensuite validée par un opérateur humain. On parle alors de saisie assistée par ordinateur ou d’aide à la saisie des méta données. Le sujet, le résumé, la couverture ; la langue peuvent en être l’objet. Ce sont là des fonctionnalités avancées de la gestion de contenu. Par contre, nombreux sont les traitements de texte qui propose une génération automatique de table des matières et autres listes des éléments d’un document (figures, tableaux, index). Il doit être possible ensuite d’inclure par exemple la table des matières dans la propriété « Table des matières ».
Si l’édition des documents est incluse dans un processus d’affaire (cf. BPM - Business Process Management ou encore cycle d’activité), la valeur des méta données et des composants documentaires liés peut être pré-remplie. Nous avons vu ci-dessus l’exemple du contrat et de la facturation. Nous avons aussi mentionné dans l’exemple de modèle d’information (voir section 2.1.2.1 « Modèle conceptuel et modèles logiques de données » p 19), le lien qu’il y a entre les spécifications d’un QCM, élément du contrat, et le QCM lui-même. Si la validation du contrat est le déclencheur (trigger), le titre du QCM et des sections du QCM peut être pré-rempli à partir des spécifications pour le créateur du QCM lié au contrat. La source du QCM est aussi connue : il s’agit du contrat et plus précisément des spécifications contenues dans le contrat.
En fin de compte, on peut, en sophistiquant le système de gestion de contenu et les éditeurs de documents, renseigner de manière automatique la plus grande partie des méta données. Cela est d’ailleurs indispensable en terme de productivité, la principale critique adressée aux CMS étant la lourdeur de la saisie et du renseignement des méta données. La saisie des méta données se fait de manière traditionnelle avec l’aide d’un formulaire, là encore. Si l’on admet qu’il faut renseigner des méta données au niveau de chaque composant documentaire, la granularité des composants étant déterminée par les objectifs assignés au système (cf. section 2.1.1 « Décomposition en composants documentaires » p 18), il est impératif de prévoir le maximum d’automatismes pour cette tâche. Dans ce contexte, le stockage et le versioning des documents prend une dimension importante.
33 S’il s’agit évidemment d’une méta donnée associée au type de document en cours de rédaction.
34 Attention ! La version peut être parfois générée automatiquement par le CMS. Dans ce cas, il s’agit d’une donnée d’application qui doit être renseignée automatiquement
