Gestion des références et identification des composants documentaires

By 24 July 2013

2.2. Concept clé numéro 2 : gestion des références et identification des composants documentaires
2.2.1. Gestion des références (internes et externes)

De ce qui vient d’être dit précédemment à propos des modèles d’informations (composition des documents, réutilisation) découle la nécessité de pouvoir lier les composants entre eux. Un document est toujours un assemblage de composants sous la forme d’un maillage et que l’on peut représenter comme un arbre. Chaque composant est relié aux autres par un lien dans cet assemblage : c’est la référence qui joue le rôle de lien. Une référence peut être aussi un pointeur explicite contenu dans le contenu lui-même. Le lien hypertexte en est la meilleure illustration.

La référence est interne quand il s’agit d’un lien d’un composant pointant vers un autre composant du même document. Elle est externe quand le document contient un lien qui pointe vers un composant d’un autre document.

Lorsqu’un document est modifié, déplacé ou détruit, les liens qui pointent vers lui doivent être mis à jour en conséquence. S’agissant d’une modification générant une nouvelle version du document, les pointeurs doivent permettre de résoudre si le lien pointe vers la nouvelle version ou s’il pointe définitivement vers la version ancienne.

L’alternative est d’affecter au composant documentaire et à sa version, un identifiant unique, invariable et persistant, indépendant de son emplacement.

Les systèmes de gestion de contenu doivent donc proposer des mécanismes pour gérer ces références et leur maintenance. Le système le plus courant est bien d’affecter un identifiant unique à chaque document et ses fragments. La gestion des liens internes et externes, mais concernant seulement des documents gérés par la même application de gestion de contenu, est possible. Cependant, lorsqu’il s’agit de lien vers des documents gérés dans des systèmes externes (typiquement des documents disponibles sur Internet mais édités par d’autres organisations), la persistance n’est plus garantie.

Le W3C (World Wide Web Consortium) et l’IETF (Internet Engineering Task Force) propose une solution à cette problématique avec la spécification des URI [34] [35] (Uniform Resource Identifier) et des espaces de noms (name spaces) dans la gestion des documents XML. De même, les propositions de normes XLink, XPath et XQuery du W3C donnent une idée de la manière dont les documents peuvent être pointés, atteints, trouvés et recomposés grâce à la structuration des documents et l’URI.

2.2.2. Uniform Resource Indicator (URI)

Un URI est en fait l’ensemble générique de tous les noms ou adresses que sont de courtes chaînes de caractères qui font référence à des ressources. Le concept d’URI englobe celui d’URN (Uniform Resource Name) et d’URL (Uniform Resource Locator).

Laconiquement, une URL est un terme informel associé aux URI populaires tels que « ftp, http, mailto,… » [36]. En fait, une URL est une forme d’URI qui exprime une adresse, qui, à travers un algorithme associé à un protocole de réseau informatique, permet d’accéder à une ressource. Les URI qui font référence à des objets accessibles avec des protocoles réseau existants sont connus comme des URL [37]. L’URL ne permet pas de garantir l’accès à la ressource si celle ci a été déplacée, renommée, voire modifiée et a fortiori détruite.

Un URN est un URI qui dispose d’un engagement institutionnel pour garantir sa persistance et sa validité. En d’autres termes, la ressource est enregistrée auprès d’une institution publique ou para- publique. Le numéro ISBN d’un livre en est une illustration. Une autre initiative permet de rendre une ressource persistante et valide à partir d’une URL : il s’agit de PURL (« Persistent Uniform Resource Locator ») [38]. Ce système associe à l’enregistrement d’une URL, une URL persistante : c’est à celle ci qu’un lien fait référence indépendamment de l’emplacement de la ressource sur Internet. Cette dernière peut donc être déplacée. C’est une sorte de système de résolution d’adresse ou encore un système d’annuaire des documents.

La syntaxe d’une URI est constituée en premier lieu par un domaine nominal (« naming scheme ») puis par une chaîne de caractères représentant l’adresse de la ressource. A l’intérieur de l’URI d’un objet, le premier élément est donc le nom du schéma, séparé du reste de l’objet par le caractère « : ». Le reste de l’URI suit les « deux points » dans un format dépendant du schéma. Le chemin (adresse) est interprété en fonction du protocole d’accès du réseau utilisé. Cependant, s’il contient des « / » (« slash »), cela implique une structure hiérarchique.

Un URN est un schéma, ou encore un système de nommage qui permet d’identifier des ressources de manière persistante et indépendante de l’emplacement. Il permet aussi, une fois la ressource identifiée, d’y accéder si le système informatique le permet.

Ce qu’il faut retenir de ces deux derniers chapitres est que toutes les références des documents doivent être uniques et invariables ; la charge revient au système de gestion de contenu de maintenir les liens en cas de modification et de déplacement des ressources. Dans des systèmes coopératifs plus ouverts et mettant en jeu plusieurs organisations (plusieurs CMS), un système commun d’annuaires de documents doit être mis en œuvre ou bien des règles de dénomination doivent être respectées par les opérateurs, éventuellement contrôlées par les systèmes de gestion de contenu en relation avec une institution qui en garantit la persistance et l’unicité en proposant un système d’enregistrement de la référence des documents. Les URI sont parties intégrante de la recommandation RDF (Resource Description Framework) du W3C, qui propose un cadre pour représenter les méta données, objet de la section suivante.

2.3. Concept clé numéro 3 : les méta données

Les méta données sont des données sur les données. A partir de cette définition, on peut imaginer tout type et toute nature de données pour mieux comprendre et utiliser les données, que cela soit pour un opérateur humain ou une machine.

Les méta données sont généralement d’abord utilisées pour décrire une ressource, documentaire ou non. Elles sont utilisées aussi par les applications qui utilisent ces ressources en tant que propriétés. Un des exemples importants qui concerne les systèmes de gestion de contenu sont les méta données d’application relatives à la gestion documentaires. Ce chapitre aborde aussi un autre exemple de méta données d’application pour la personnalisation du contenu et de la publication en fonction de l’utilisateur. Enfin, nous verrons un exemple de tentative d’harmonisation des méta données avec une proposition du groupe de Dublin Core qui récapitule les méta données présentées dans cette section. En fait, les méta données de Dublin Core ont largement influencé notre approche concernant les méta données. En effet, les travaux de ce groupe, réunissant à la fois des experts du monde la bibliothèque et des données (de l’Informatique), ont permis d’élaborer une synthèse des méta données les plus courantes et nécessaires à la gestion de contenu.

Comme pour toutes données, il n’y a pas de format de méta données particulier. Elles peuvent être modélisées de différentes manières. De même, elles peuvent être organisées logiquement selon la convenance des systèmes. Nous aborderons toutefois un modèle et une syntaxe de représentation des méta données avec Resource Description Framework (RDF) qui peut permettre une exploitation importante des méta données grâce à leur extensibilité, l’intégration des schémas de méta données et l’échange de méta données.

2.3.1. Méta données : définition et utilisation

Les méta données, information sur l’information, peuvent être regroupées dans deux ensembles principaux : les données descriptives, les données d’application. Dans les méta données d’application, deux sous-ensembles nous intéressent plus particulièrement du point de vue des systèmes de gestion de contenu : les données de gestion documentaires et les données de personnalisation. Ce sont ces différents groupes de méta données que nous allons aborder dans cette section.

2.3.1.1. Données descriptives

Les données descriptives classiques sont le titre, l’auteur et le sujet. Tout le monde est familier, d’une manière ou d’une autre, de ces méta données.

Cependant d’autres méta données descriptives peuvent être ajoutées. Il s’agit par exemple d’une description du composant, de la table des matières, d’un résumé, d’une ou plusieurs sources, du type du composant, de la couverture spatiale et temporelle, de la langue et de la date.

Approfondissons les notions relatives aux méta données descriptives. Si aucun commentaire n’est fait dans ce chapitre à propos d’une méta donnée, le lecteur pourra en trouver un dans le tableau 5 : « méta données de l’initiative de Dublin Core p 109 ». Par ailleurs, ce tableau développe aussi des informations sur les standards qui peuvent être associés à ces méta données.

1. Voyons tout d’abord l’auteur d’un composant documentaire. Si cette appellation convient bien pour des documents écrits classiques, elle convient moins bien à certains contenus : par exemple une œuvre musicale ou un film. On pourra donc lui préférer la dénomination de « créateur ». On rajoute à cette méta donnée celles concernant l’éditeur (dans ce contexte, l’organisme qui publie et diffuse) et le(s) contributeur(s).

2. Le contenu du sujet demande à être précisé. Car il recoupe une des informations les plus importantes que représentent les méta données : la classification. Là encore, le terme de classification demande à être développé. Certains lui préfèrent le terme de taxonomie. D’autres encore utilisent le terme de catégorisation et par-là, le sujet peut représenter une catégorie. Le sujet peut donc représenter un domaine défini dans une classification de domaines. Le sujet peut être aussi illustré par l’utilisation de mots clés. Là encore, la liste des mots clés doit être choisie minutieusement dans le sens où ce paramètre des méta données (e.g. le sujet) va servir pour rechercher logiquement et récupérer le composant documentaire concerné. Le mot clé doit donc préférablement appartenir à une liste prédéfinie. De même, le choix des mots clés doit être contrôlé à l’aide d’un dictionnaire. Il doit se faire à partir d’un vocabulaire contrôlé ou bien encore un thésaurus.

Une des illustrations les plus simples de ce besoin de vocabulaire contrôlé dans le contenu des méta données est le nom d’une ressource. Certains utiliseront un acronyme quand d’autres écriront le nom complet d’une organisation ou encore certains parleront d’une personne en ne citant que son nom alors que d’autres rechercheront des informations sur la même personne en donnant le nom mais aussi le prénom, empêchant de retrouver le document écrit pour informer sur cette personne.

3. La notion de table des matières ne soulève pas trop d’ambiguïté. Cependant, si elle est utile pour décrire des documents volumineux comme les documents de type rapport ou livre, elle ne l’est pas pour les composants du type des nouvelles (news) sur un site web informatif qui sont des documents courts. Les méta données ne s’appliquent donc pas uniformément à tous les types de documents. Certaines comme le titre s’appliquent à tous, d’autres comme nous l’avons vu sont spécifiques à certains documents.

4. Cela introduit la notion de type dans les méta données. Il ne s’agit pas, d’après le groupe du Dublin Core, de reprendre l’information sur le document qui est donné dans la référence à la DTD (Document Type Définition) dans les documents XML mais d’un type beaucoup plus général (voir type dans le tableau 5). Cependant, une autre « architecture » de CMS n’utilisant pas XML pourrait là nécessiter d’avoir une référence au modèle (e.g. template) auquel obéit le document. Par ailleurs, il est possible de suivre la notation de Dublin Core pour les méta données tout en les enrichissant notamment en utilisant l’héritage12. RDF par exemple permet de sous-classer des propriétés ou encore des types de ressources qui sont définies dans le modèle comme des classes12.

5. La couverture peut être spatiale et / ou temporelle. C’est à dire que la portée de l’œuvre concerne une époque (pour la couverture temporelle) et / ou une zone géographique. Il peut paraître évident de chercher un texte qui s’applique à un pays. Cependant si la base de documents contient un texte sur le même sujet mais qui est différent en fonction du pays auquel il se rapporte, il vaut mieux disposer de cette méta donnée. Là aussi, l’utilisation de vocabulaire contrôlé est indispensable. Ainsi, le groupe de Dublin qui s’intéresse aux méta données n’a pas son siège en Irlande mais dans l’Etat de l’Ohio aux Etats-Unis (d’Amérique…) où se trouve aussi le siège de l’OCLC13.

6. La date enfin est une donnée conventionnelle. Sa définition est la suivante : « une date associée avec un événement dans le cycle de vie de la ressource. Typiquement, une date sera associée à la création ou à la publication d’une ressource » (voir tableau 5). Toutefois, de multiples dates sont associées au méta données. Nous les étudierons dans le chapitre intitulé « Cycle de vie du document (dates, statuts et versions) » page 28.

Ces données descriptives sont donc des données qui permettent de présenter et sélectionner une ressource sans y accéder dans un premier temps. Elles sont notamment reprises dans des catalogues décrivant des composants documentaires ou encore comme éléments d’une liste des résultats à une requête sur un « moteur de recherche ». Les méta données, pour être efficaces, doivent être normalisées ainsi que leurs contenus. De même, elles doivent être extensibles pour répondre aux besoins spécifiques associés à chaque type de document en fonction des utilisateurs.

Ces informations s’adressent principalement à des opérateurs humains, contrairement aux données d’applications qui s’adressent principalement aux programmes informatiques et que nous allons maintenant aborder.

2.3.1.2. Données d’application

Les méta données utiles aux applications peuvent être multiples et dépendent de la nature et du domaine de l’application. Les données d’applications sont souvent appelées et assimilées à des propriétés. Certains parlent même d’attributs de fichier. Aussi, il vaut mieux introduire ce genre de méta données par un exemple.

Une application informatique qui permet de visualiser et d’éditer des images a besoin d’information sur le fichier et l’image. Le format du fichier est une information générale nécessaire à un système informatique pour déterminer quelle peut être l’application à associer à la lecture ou à l’édition du fichier. D’ailleurs, face à l’importance de cette information, même le groupe de Dublin Core propose une méta donnée. Il s’agit de la données intitulée « format » (voir tableau 5 page 109). La taille du fichier peut être une information générale utile.

Un fichier GIF (Graphic Interchange Format), un des formats d’image les mieux supportés, a les propriétés de base suivantes : largeur (en pixel), hauteur (pixel), nombre de bit (valeur exemple : ‘6’), représentation (valeur exemple : ‘Palette’) et enfin compression (valeur exemple : ‘Lempel-Ziv’) qui donne l’algorithme de compression utilisé pour compresser la taille du fichier. Un fichier JPEG (Joint Photographic Experts Group) lui propose les méta données d’application suivantes : largeur, hauteur, résolution verticale, résolution horizontale (en pixels par pouce), nombre de bits (valeur exemple : ‘24’), représentation des couleurs (valeur exemple : ‘Couleurs vraies RVB’), compression (valeur exemple : ‘non compressé’). Des attributs sont donc communs, d’autres spécifiques au type de fichier et aux applications capables de les traiter.

12 Concept associé à la programmation orientée objet.
13 OCLC : Online Computer Library Center.

Ces informations sont indispensables aux applications afin de permettre un certain nombre d’automatisations. Dans le cas des images, on peut les afficher directement sur un écran à la taille voulue (dont la taille et la résolution sont définies) sans à avoir à « scruter » le fichier afin de calculer ses propriétés.

Les méta données d’applications sont donc des données qui décrivent une ressource et qui sont couramment utilisées pour automatiser leur traitement.

Lors de l’édition de ressources informatiques ou numériques, un grand nombre de paramètres est utilisé par les applications d’édition et le système. Par exemple, les polices de caractère d’un texte peuvent être reprises dans les méta données. Si cette donnée d’application est nécessaire pour une intégration d’applications par exemple, l’application d’édition peut enregistrer automatiquement ces données en tant que méta données.

En fait, il s’agit d’une définition, les méta données d’applications peuvent et doivent être renseignées automatiquement. C’est un fait important sur lequel nous reviendrons dans le chapitre 3.1.2 intitulé « Edition des méta données » et qui s’étend à toutes les méta données, particulièrement les données de gestion documentaire que nous allons maintenant aborder ci-dessous.

2.3.1.3. Données de gestion documentaire

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 œuvre. 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 œuvre la gestion des liens explicites. La mise en œuvre 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é.

14 XML Linking Language (XLink) Version 1.0 : W 3C Recommendation 27 June 2001. http://www.w3.org/TR/xlink/

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 œuvre (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.

15 XML Path Language (XPath) Version 1.0 : W 3C Recommendation 16 November 1999. http://www.w3.org/TR/xpath
16 XQuery 1.0: An XML Query Language : W 3C W orking Draft 22 August 2003. http://www.w3.org/TR/xquery/
17 XSL Transformations (XSLT) Version 1.0 : W 3C Recommendation 16 November 1999.

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.

2.3.1.4. Données de personnalisation

D’autres méta données d’un genre particulier utiles pour les applications de personnalisation de la publication sont les données de personnalisation. A ce titre, ce sont encore des méta données d’application.

Le DCMI propose là encore des méta données. Mais ce ne sont que des termes concernant la notion de public d’un document. Ce sont les termes suivants : audience, mediator, educationLevel. Si ces méta données sont renseignées, le système de publication pourra distribuer ou non, en fonction des données de l’utilisateur, la ressource documentaire. Mais il faut que le système permette aussi d’identifier l’utilisateur et que ces données le concernant soient renseignées. Ceci en utilisant des valeurs pour ces propriétés aussi normalisées que possible. DCMI ne propose pas de classification normative pour ces sujets. Elles sont donc spécifiques pour le moment aux applications qui les utilisent.

Par contre, un élément normalisé pour gérer les droits d’accès est l’élément « Rights ». On peut y inclure les données ACL (Access Control List). Mais on peut y trouver aussi les éléments de droits d’auteur (copy rights) le cas échéant. Les fichiers ACL spécifient quel utilisateur ou quel groupe d’utilisateur a accès à la ressource et ce qu’il peut faire avec (lecture, écriture, exécution, destruction). Le droit sur et au sujet d’une ressource est très important puisque l’on a vu que pour toute donnée numérisée, la notion de prêt n’a plus cours (cf. 1.1 « Gestion des bibliothèques physiques »).

On parle ici de personnalisation du contenu et non pas de la mise en forme. Tous ces aspects seront abordés dans le chapitre 3.3.3 “Personnalisation ». Ainsi les données de personnalisation autorisent la révélation et la distribution d’une ressource en fonction de l’utilisateur. Les données retenues par le

DCMI montrent que c’est le domaine de la formation et de l’éducation qui est principalement intéressé.

Le champ des méta données a donc été présenté dans son ensemble. Nous allons donc pouvoir voir une initiative, celle du groupe de Dublin Core, qui les intègrent dans un ensemble à vocation normative.

2.3.2. Dublin Core Metadata Initiative (DCMI)

Lors d’une conférence tenue à Dublin, Ohio, à l’OCLC (Online Cataloging Library Center) un groupe de travail a commencé à se pencher sur la problématique des méta données. Un groupe de méta données ressenties comme communes à la majeure partie des types de documents y a été élaboré. C’est d’ailleurs pour cela que je les ai présentés au cours de cette section 2.3 traitant des méta données.

C’est l’ensemble des éléments de Dublin Core (Dublin Core Element Set –DCES) qui est aujourd’hui l’objet d’une tentative de normalisation18 à l’ISO (International Standard Organisation).

Cependant, le DCMI va plus loin en définissant une liste de termes qui peuvent être des méta données. Cette liste des termes (qualificatif, soit « qualifier » en anglais) est accessible pour la dernière version à l’adresse URL http://purl.org/dc/terms/ au format RDF / XML. De plus, il définit aussi des listes de valeurs standard pouvant être utilisées pour renseigner ces méta données (« encoding schemes »).

Le tableau en annexe 3 fait la synthèse des éléments, des termes et des domaines de valeurs normalisés préconisées pour ces méta données. Il est basé sur la version 1.1. du DCES du 24/03/2003 [39] [40]. Ce tableau reprend les méta données qui ont déjà été largement abordées dans les sections précédentes.

Lire le mémoire complet ==> (Les systèmes de gestion de contenu : description, classification et évaluation)
Mémoire présenté en vue d’obtenir le DIPLOME D’INGENIEUR C.N.A.M. en informatique
Conservatoire National Des Arts Et Métiers – Paris