Les méta données de gestion documentaire sont d’un genre particulier car ce sont des données d’applications de manière générale mais qui sont relatives à la gestion de contenu et donc aux CMS en particulier. Ces méta données assurent la traçabilité entre les composants d’un système. Ces données sont les sous propriétés des éléments des méta données de Dublin Core « relations » et « date ».
Gestion des références explicites
Nous avons déjà abordé ce sujet dans le chapitre 2.2.1. Nous avons vu notamment que les références peuvent être explicites et mentionnées dans le contenu d’un composant ou implicites dans le cas des liens de composition que nous abordons ci-dessous. Ces liens explicites sont par exemples des liens hypertextes ou encore des renvois à d’autres éléments d’un document. Mais les liens peuvent être encore les références reprises dans la section concernant la bibliographie d’une oeuvre. Ces références sont parfois des sources du document contenant ces références. De même, dans certains documents de travail, ces méta données sont reprise dans des préambules. Par exemple, classiquement, le document des spécifications fonctionnelles d’un programme informatique fait références aux documents préalables que sont les cahiers des charges et l’offre de marché si elle existe. Et il peut en être ainsi de suite sur toute la chaîne des documents accompagnant le cycle d’une activité.
Il faut donc noter ici que des méta données peuvent en fait être les données mêmes de composants documentaires spécifiques comme ceux que nous venons de mentionner dans le paragraphe précédent.
Pour rester en phase avec XML, on peut citer ici la norme Xlink14 qui peut être utilisée pour mettre en oeuvre la gestion des liens explicites. La mise en oeuvre de Xlink permet en particulier une navigation intéressante dans les informations d’un système pour ceux qui sont en phase d’apprentissage et/ou de réflexion.
Les termes ou les éléments correspondants définis par l’agence DCMI sont les suivants : Source, hasVersion, isVersionOf, Replaces, isReplacedBy, hasFormat, isFormatOf, references, isReferencedBy et conformsTo (voir tableau 5 page 109). Rappelons ici que s’il s’agit de ressources externes au CMS, l’utilisation d’un URI (voir chapitre 2.2.2) sera judicieuse. On peut noter aussi que les propriétés possèdent chacune le cas échéant leur propriété inverse s’appliquant au document lié.
Relations implicites (liens de composition)
Restent donc les termes de l’élément « relation » suivants : hasPart, isPartOf, requires, isRequiredBy. Ils décrivent donc les liens de composition dans les documents composites (cf. section 1.2 « Edition de document composite »).
La première relation (i.e. hasPart/isPartOf) est définie ainsi : « la ressource décrite inclut la ressource référencée soit physiquement, soit logiquement ». Cette notion est fondamentale pour la gestion des composants. Si le composant n’est inclus que dans un seul document, il n’y pas de problème particulier lors d’un changement s’appliquant au document. Par contre, s’il est partagé, il faut à tout prix gérer les conflits éventuels relevant du partage. L’exemple typique est le logo d’une organisation qui est repris dans de multiples documents : lorsqu’un document est détruit, il s’agit de ne pas détruire le fichier image correspondant et qui continue d’avoir une « vie » dans les documents toujours valides. Inversement, lorsque le logo est changé, ce changement ne doit être répercuté que dans les documents faisant référence à la version la plus récente. Ainsi la gestion des composants documentaires ne peut se faire que si la relation « hasPart » est soigneusement renseignée.
La définition de la relation requires/isRequiredBY est la suivante : « la ressource décrite requiert la ressource référencée pour fonctionner, être utilisée ou pour sa cohérence de contenu ». Il y a ici une référence au logiciel éventuel nécessaire pour exploiter le composant mais surtout et c’est ce qui nous intéresse ici, les composants sont liés de telle sorte que l’un ne peut se comprendre sans l’accès éventuel à l’autre ou aux autres composants « requis ». On peut illustrer cela par un composant faisant partie d’une oeuvre (un rapport par exemple), qui traite d’un sujet particulier, mais qui ne saura être compris dans son intégralité sans une référence au document dont il fait partie et notamment l’introduction. Ainsi extrait de son contexte, le composant qui requiert un autre composant n’est pas forcément cohérent. Ce lien est aussi important pour le CMS afin de maintenir un statut « valide » à un composant qui serait réutilisé par un autre valide et dont le contexte « requis » pour sa compréhension serait invalidé et archivé ou détruit.
Ces données de gestion documentaires ne sont utiles que dans le cas de partage de composant. Autrement, ils imposent une lourdeur et une rigidité au système de gestion de contenu qui n’est pas souhaitable. Xlink14 peut être utilisé dans ce cas là car ils sont alors explicites. Avec XML et les DTD (ou les schémas XML), le lien de composition est défini dans la structure du modèle. Quand un document référençant le modèle est édité, des liens de compositions implicites sont établis. Ce sont ces liens qui sont l’objet de la norme Xpath15 et qui permettent de parcourir et d’établir des références entre des éléments d’un même document. De même, ces références internes aux composants d’un document permettent d’effectuer des requêtes sur des portions de documents et sont utilisées par le langage de requête XML (XQuery16 parfois nommé XQL16).
Il s’agit là juste de mentions qui sont toutefois intéressantes dans le sens où par la suite XQuery peut être utilisé par exemple comme technologie sous-jacente des moteurs de recherche (cf. 3.3.4. « Recherche et récupération de document ») et qu’il permet la recherche fédérée sur différents types de stockage de données (fichiers plats XML et bases de données). De même, Xlink peut être utilisé pour la navigation (cf. 3.3.5 « Navigation »). Enfin XSLT17 utilise aussi la norme Xpath pour sélectionner des composants documentaires (éléments XML) pour effectuer des transformations sur la structure d’un document afin de créer un nouveau document, notamment une publication. XSLT est dérivé du langage XSL (Extensible Stylesheet Language) qui, lui, permet d’associer une mise en forme aux éléments d’un document XML publié en tant que page web sur un navigateur (terminal du Web). Tous ces éléments sont abordés dans les chapitres de la section 3.3 « Système de publication ».
Ces normes et ces langages illustrent l’importance des applications qui découlent de l’utilisation des méta données, mais aussi des concepts de structuration de document et de séparation des données du contenu. Il existe bien sûr des alternatives à ces langages, mais rappelons le ici, XML permet d’avoir une vision complète de l’architecture nécessaire à la gestion de contenu.
L’analyse des liens de composition montre aussi qu’un composant documentaire n’a de raison d’être que par rapport à sa publication. Cependant, la gestion de contenu que nous envisageons dans ce rapport (intégrant la réutilisation, la publication sur de multiples supports, la personnalisation), révèle une nouvelle forme de considération du composant documentaire qui commence à prendre une « vie » qui lui est propre (voir 3.3.2 « Publication versus document »). D’où toute l’importance des méta données abordées dans cette section sur les données de gestion documentaire, qui, rappelons le, permettent d’assurer la traçabilité des informations.
Cycle de vie du document (dates, statuts et versions)
Nous avons vu (cf. section 1.3 « Gestion documentaire (référentiel d’entreprise) ») le caractère parfois officiel des documents. Il y a été aussi évoqué l’état d’un document dans une chaîne d’édition et de validation de document. Ainsi un document, de sa création (naissance) à sa destruction (mort) obéit à un cycle de vie. Ce cycle est marqué par des étapes auxquelles est associé un statut pour le document.
Ces étapes sont les suivantes : création, soumission (pour approbation), validation (approbation), publication, archivage et destruction. Le cycle peut être rejoué partiellement en cas de modification générant une nouvelle version du document. Ce cycle peut être affiné pour des processus d’édition plus complexes. Avant d’être approuvé, un document aura souvent le statut de brouillon (« draft » en anglais).
Les termes des dates associées aux méta données du DCMI sont les suivants : Created, Modified, DateSubmitted, DateAccepted, DateCopyrighted, Issued, Available, Valid (voir tableau 5 page 109).
La dernière méta donnée (« valid ») est importante puisqu’elle permet de savoir si la version du document accédée est toujours valable et si les informations qu’on y trouve s’appliquent toujours. Elle est impérative pour des documents présentant des textes réglementaires. Si une nouvelle version d’un document est approuvée et publiée, alors la version précédente voit sa validité terminée à moins qu’il ne faille continuer à soutenir les versions précédentes.
La gestion des versions est utile dans ce dernier cas. Par exemple, pour les logiciels, certains utilisateurs continuent d’utiliser des versions anciennes d’un programme. Il faut donc pouvoir continuer à accéder à la ressource et à la documentation associée malgré l’existence de versions ultérieures.
Ces données d’application de gestion de contenu sont tout aussi indispensables que celles présentées précédemment notamment pour pouvoir automatiser certains processus comme l’archivage et la destruction. En effet, sur la base de règles associées à certains types de documents, les CMS vont pouvoir, par exemple, retirer de la publication certains éléments de site web, transférer de fichiers de disques magnétiques vers des disques optiques afin de libérer le système d’exploitation primaire pour de nouvelles ressources.
14 XML Linking Language (XLink) Version 1.0 : W3C Recommendation 27 June 2001. http://www.w3.org/TR/xlink/
15 XML Path Language (XPath) Version 1.0 : W3C Recommendation 16 November 1999. http://www.w3.org/TR/xpath
16 XQuery 1.0: An XML Query Language : W3C Working Draft 22 August 2003. http://www.w3.org/TR/xquery/
17 XSL Transformations (XSLT) Version 1.0 : W3C Recommendation 16 November 1999.
