Antonin Benoît DIOUF Université Gaston Berger (Saint-Louis)

Présentation au sujet: "Antonin Benoît DIOUF Université Gaston Berger (Saint-Louis)"— Transcription de la présentation:

1 Normes et standards du traitement documentaire des ressources électroniques
Antonin Benoît DIOUF Université Gaston Berger (Saint-Louis) Bibliothèque centrale Service des acquisitions et du traitement Atelier COBESS du 30 juin 2007, Dakar, SENEGAL Mobile : Mail : Weblog :

2 PLAN TIMING INTRODUCTION APPROCHE CLASSIQUE APPROCHE MOINS CLASSIQUE
Considérations générales Norme & Standard (Définition) Traitement documentaire Notion de Métadonnées APPROCHE CLASSIQUE ISBD & ISBD (ER) Formats MARC APPROCHE MOINS CLASSIQUE Dublin Core Eléments Langages de balisage (HTML, XML) Dublin Core qualifié Raffinements d’éléments Schémas d’encodage Espace de noms Registre Profils d’application CONCLUSION LIENS TIMING Présentation : 1 h Cas pratiques & Discussions : 1 h Total : 2h

3 INTRODUCTION Considérations générales
Norme & Standard (Définition) Normes : caractère officiel, légal (« de jure »). Ensemble de règles de conformité, édictées et élaborés par des organismes officiels de normalisation (ISO, AFNOR…) Standards : caractère consensuel (« de facto »). Ensemble de recommandations émanant d'un groupe représentatif d'utilisateurs : sociétés ou consortia (XML : W3C,…) ; groupements de professionnels (Dublin Core : Dublin Core Metadata Initiative) ; institutions (MarcXML : Library of Congress) Parfois un standard s’officialise en norme (Dublin Core) Les normes et les standards sont les seuls moyens qui permettent l'interopérabilité et l'évolution des systèmes au cours du temps. Une norme ou un standard ne peut pas forcément répondre aux besoins de chacun, mais doit être extensible. C'est sur un socle de besoins communs que les normes et les standards doivent être bâtis. Prenons un exemple : pour une communication ou un cours, une présentation PowerPoint va être demandée (c’est le cas ici). Cela correspond à une position dominante de ce logiciel. Mais que deviennent les présentations PowerPoint si ce logiciel disparaît ? Si la version évolue ou si l'utilisateur change de machine, passe de Mac à PC ? Les documents peuvent ne plus être lisibles et se perdre. Si la source des données est gardée, avec une présentation en LaTeX par exemple, le contenu reste accessible même si l'affichage est perdu. De la même manière, pour que l'indexation survive au logiciel et au matériel, elle doit impérativement reposer sur des standards. Des transcriptions permettant le passage d'un environnement à un autre seront forcément écrites lorsque les normes ou standards évolueront. Normes et standards permettent donc de maintenir une pérennité des ressources. L'indexation garantit leur accessibilité, et, à travers des échanges, l'interopérabilité entre systèmes. Les ressources peuvent alors être réutilisées et adaptées. LaTex : (abréviation de Lamport tex ) (Prononcer : lè-tekh ou lah-tekh ), créé par Leslie Lamport, est un système logiciel de composition de documents, ou plus exactement : une collection de macro-commandes destinées à faciliter l'utilisation du « processeur de texte » TeX. Du fait de sa relative simplicité, il est devenu la méthode privilégiée d'écriture de documents scientifiques employant TeX ; la version actuelle est LaTex2. Il est particulièrement utilisé dans les domaines techniques et scientifiques pour la production de documents de taille moyenne ou importante (thèse ou livre). Néanmoins, il peut aussi être employé pour générer des documents de types variés (par exemple des lettres ou des transparents).

4 Considérations générales
Traitement documentaire Traditionnellement, il s’agit de : “décrire” (“cataloguer”, “inventorier”) les documents “contrôler” certains points d’accès à la description des documents “indexer” (“classifier”) le contenu sémantique des documents

5 Considérations générales
Traitement documentaire Dans le contexte de la présente intervention : isoler et articuler des éléments de description, dont certains peuvent servir de points d’accès aux documents mais pas forcément « décrire » soi-même « points d’accès aux documents » (numériques) et non à leur seule description

6 Considérations générales
Traitement documentaire Documents traditionnels séparation physique inévitable entre le document et sa description points “d’accès” (vedettes matières, auteurs, etc.) = accès à la description, non au document même ! Documents électroniques Apparition au milieu des années 90 de la notion de métadonnées

7 Considérations générales
Métadonnées Sens originel : données (numériques) fournissant des renseignements sur le paquet de données (numériques) auquel elles appartiennent Par extension et abus de langage : simplement “données sur des données” (même non numériques... ?). Donc données de fiches de catalogage sont aussi des métadonnées.  Même pour les ressources électroniques, les métadonnées peuvent être physiquement séparées des données sur lesquelles elles renseignent. Bibliographie générale succincte sur les métadonnées : FRÉON, Marie-Élise. Les métadonnées : accès aux ressources électroniques. Dans : La recherche d’information sur les réseaux : cours INRIA, 30 septembre-4 octobre 2002, Le Bono (Morbihan) / éd Jean-Claude Le Moal, Bernard Hidoine et Lisette Calderan. ADBS éd., ISBN P PECCATTE, Patrick. Métadonnées : une initiation : Dublin Core, IPTC, EXIF, RDF, XMP, etc. [en ligne]. [S. l.] : [s. n.], dernière mise à jour 10 mars 2004 [Consultée le 21 novembre 2006]. Disponible sur Internet : < NATIONAL INFORMATION STANDARDS ORGANIZATION (NISO). Understanding Metadata [en ligne]. Bethesda, MD : NISO, cop [Consultée le 21 novembre 2006]. Disponible sur Internet : < standards/resources/UnderstandingMetadata.pdf>. ISBN RICHY, Hélène. Métadonnées et documents numériques. Dans : Techniques de l’ingénieur. Traité Informatique P Également disponible en ligne : < H7155> [Consultée le 20 novembre 2006] (consultation payante).

8 Une définition parmi tant d’autres
Métadonnées « Les métadonnées sont des informations structurées qui décrivent, expliquent, localisent ou encore facilitent la découverte, l’utilisation ou la gestion d’une ressource informationnelle. » NISO (National Information Standards Organization), Understanding metadata, 2004, ISBN Texte original anglais : « Metadata is structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource. »

9 Considérations générales
Métadonnées Typologie des métadonnées : Métadonnées administratives (comprenant notamment : métadonnées de gestion des droits et des accès, et métadonnées de préservation) Métadonnées structurelles (explicitation des relations entre les composants de la ressource, liens entre ces composants). Facilitent la navigation et la présentation des ressources électroniques Métadonnées descriptives (but : découverte et identification des ressources ; seront les seules traitées dans la présente intervention) Ces catégories n’ont pas de frontières bien définies et se recouvrent souvent partiellement Un bon schéma synthétique sur les différents types de métadonnées est disponible en ligne à l’adresse : < Selon les auteurs, les métadonnées de gestion des droits et les métadonnées techniques de préservation sont regroupées sous la dénomination de « Métadonnées administratives » ou considérées comme deux groupes distincts. On trouve donc mention, au gré des articles, tantôt de 3 types de métadonnées, tantôt de 4.

10 Considérations générales
Métadonnées descriptives Elles servent a : La Localisation. Les métadonnées de description peuvent indiquer où est localisée une ressource d’information, que ce soit physiquement ou virtuellement. L’Identification. Les métadonnées de description peuvent distinguer une ressource d’information d’une autre sans décrire toute la collection de ressources. La Recherche d’information. Les métadonnées de description peuvent relier la requête d’un utilisateur sur un sujet donné à des ressources d’information accessibles sur le même sujet.

11 Métadonnées descriptives
Localisation (exemples) URL (Uniform Ressource Locator) est un exemple de métadonnée de description utilisée pour localiser des données. L’URL distingue les ressources web les unes des autres. Même si la plupart des URL semblent identifier, ou nommer, des ressources web, elles donnent en réalité le nom d’un fichier sur un serveur, ou d’un serveur lui-même sur lequel la ressource web est située. Information sur la classification, par exemple la classification décimale de Dewey. (Cotation)

12 Métadonnées descriptives
Identification (exemples) ISBN (Numéro International Normalisé du Livre). L’adresse PURL (Persistent Uniform Resource Locator). Une PURL identifie une ressource quelle que soit sa localisation sur le web et quel que soit l’endroit où cette ressource est déplacée sur le web. (

13 Métadonnées descriptives
La recherche d’information (exemples) Mots matières ou vedettes-matières (d’un OPAC par exemple) qui renvoient à des documents traitant du même sujet.

14 Considérations générales
Métadonnées Peuvent concerner : un ensemble de ressources une ressource individuelle une partie d’une ressource

15 Considérations générales
Métadonnées : Où se trouvent-elles ? Elles peuvent être : Encapsulées (ex. : Dublin Core). Balises META des codes sources des pages ou sites web Englobantes (ex. : EAD = Encoded Archives Description) Externes (ex. : MARC) (séparées de la ressource qu’elles décrivent, peuvent être stockées dans des catalogues ou BDD et reliées à la ressource par une métadonnée de localisation comme URL ou Cote. Zone 856 UNIMARC) Métadonnées encapsulées Ressource Métadonnées englobantes Ressource Ressource Métadonnées externes

16 Une autre façon d’illustrer les 3 types d’emplacement des métadonnées...
Sirop Ceci est une bouteille de sirop, dans une boîte en carton englobantes Données Ou Ressource externes SIROP De BISSAP encapsulées Métadonnées

17 Considérations générales
Métadonnées Remarque Pour les métadonnées, quelques-unes peuvent fournir des données sur le contenu ou sur le contexte d’une ressource. Métadonnées de contenu : Mots matières, titre,… Métadonnées de contexte : nom du créateur/auteur des données, la date et le lieu de création et les autres métadonnées administratives,…

18 APPROCHE CLASSIQUE ISBD & MARC

19 Approche classique ISBD 2006 ou 2007 ? : ISBD(ER) révisé
ISBD = International Standard Bibliographic Descriptions émanent de l’IFLA (Fédération internationale des associations de bibliothécaires et de bibliothèques) 1971 : ISBD(M) = le premier 1990 : ISBD(CF) CF = « Computer Files » 1997 : ISBD(ER) ER = « Electronic Resources », d’où découle la norme AFNOR Z (Catalogage des ressources électroniques) de décembre 1999 2006 ou 2007 ? : ISBD(ER) révisé La liste des ISBD en anglais est disponible à l’adresse : < La liste des traductions des ISBD est disponible à l’adresse : < Le texte de l’ISBD(ER) (dans sa version, bientôt « obsolète », de 1997), est disponible en ligne à l’adresse : < La révision était suspendue jusqu’en La proposition de texte révisé est disponible à l’adresse : <

20 Approche classique Alors que les catalogues de bibliothèque commençaient à être disponibles électroniquement, l’ISBD initialement utilisé pour créer des catalogues papiers de bibliothèque a continué d’être utilisé comme préconisation pour la description des ressources électroniques. Donc création de l’ISBD (ER)

21 Approche classique Couvre : ISBD (ER)
ressources électroniques sur support autonome (CD-ROMs…) ou en ligne (bases de données, sites Web…) interactives ou non interactives consistant en des données ou en des programmes (ou combinaison des deux)

22 Approche classique ISBD (ER)
Prévoit deux modes de traitement en fonction du type de ressource électronique (sur support / accès en ligne) toute ressource électronique en ligne est réputée « publiée » (Postulat) sont exclus : « jouets programmés, calculateurs et autres objets programmés » notion de bibliothèque numérique absente de l’ISBD(ER) : pas de distinction entre fonds numériques et reste des fonds, un seul catalogue.

23 Approche classique Particularités des ressources électroniques dans l’ISBD : Zone 3 : Type et taille de la ressource zone facultative Type : “Données textuelles”, “Données cartographiques”, “Données et programme” etc. Taille : nombre de fichiers et/ou d’enregistrements et/ou d’octets et/ou d’instructions Zone 4 : Adresse bibliographique Ressources électroniques en ligne : toutes réputées « publiées »  zone à remplir Zone 5 : Description matérielle Essentiellement pour les ressources sur support ; facultatif pour les ressources en ligne Zone 7 : Notes 1res notes = Configuration requise et Mode d’accès URL pas explicitement prévus !

24 Approche classique Formats MARC
Nés du besoin d’un schéma permettant à des bases de données bibliographiques de communiquer entre elles, ce que ne permet pas l’ISBD (ER) Reposent tous sur la norme ISO 2709 “Format pour l’échange d’information” norme adaptée à l’information bibliographique car elle permet de gérer des zones (et sous-zones) de longueur variable facultatives répétables définit la structure d’une notice Label (zone fixe de 24 caractères) Répertoire Structure générique des zones

25 Approche classique MARC 21
Le format MARC 21 (Machine-Readable Cataloging ou Normes de Catalogage Lisibles par Machine) a été développé dans cette optique ; il met en forme les règles préconisées par l’ISBD de telle manière que les ordinateurs puissent les interpréter. Il fournit des champs pour stocker le titre de la ressource, l’individu ou l’organisme auteur, etc. Certaines données MARC 21 ne correspondent pas à une description bibliographique. Ces données permettent à différents systèmes bibliographiques d’échanger l’enregistrement. (Idem UNIMARC) cam a 4500 003DLC s1993 caua j eng 010|a Bloc d’identification

26 Approche classique UNIMARC créé par l’IFLA
dans le cadre du programme du CBU (Contrôle bibliographique universel) pour sortir de la « babélisation » des formats nationaux (USMARC : format national aux USA, CAN/MARC : format national au Canada, MARC 21 : fusion d'USMARC et de CAN/MARC, reconnue par l'IFLA comme format d'échange, INTERMARC utilisé par la Bibliothèque nationale de France etc…) première édition : 1977 format « pivot » des échanges d’information bibliographique adopté ensuite comme format de saisie par des bibliothèques Le format UNIMARC est disponible en ligne à l’adresse : <

27 Approche classique UNIMARC
Spécificités pour les ressources électroniques : 215 : Description matérielle : champ omis pour les ressources en ligne, remplacé par 230 230 : Caractéristiques de la ressource électronique (obligatoire pour les ressources en ligne) 336 : Note sur le type de la ressource électronique 337 : Note sur la configuration requise 856 : Localisation électronique et accès (URL) Sur les spécificités de l’application d’UNIMARC aux ressources électro-niques : IFLA UNIVERSAL BIBLIOGRAPHIC CONTROL AND INTERNATIO-NAL MARC CORE PROGRAM (UBCIM). Electronic Resources [en ligne]. [S. l.] : IFLA, , latest rev. September 6, 2000 [Consultée le 21 novembre 2006]. (UNIMARC Guidelines ; 6). Disponible sur le Web : <

28 Approche classique Avantages : Inconvénients majeurs :
Pas de séparation entre catalogue des ressources électroniques et catalogue des autres fonds Richesse et précision de la description Inconvénients majeurs : Inapplicable à la totalité du Web !!! Pas en phase avec les autres développements en cours (TIC par exemple) Isolement des bibliothèques par rapport aux autres médiateurs de ressources (archives et musées entre autres)

29 Approche moins classique « moderne »
Dublin core (le seul traité dans cette intervention) MODS ; EAD ; MARCXML, etc.

30 Dublin Core Créé en 1995 à Dublin, Ohio (USA), par OCLC et NCSA
Maintenance assurée par Dublin Core Metadata Initiative (DCMI) et supervisée par OCLC – Office of Research & Special Projects Ancien standard devenu norme Z39.85 en 2001 par la National Information Standards Organization (NISO) Norme ISO depuis 2003 (DCMI = Agence de maintenance) NCSA = National Center for Supercomputing Applications OCLC = Online Computer Library Center

31 Dublin Core Le Dublin Core inclut des éléments bibliographiques types comme le titre, l’auteur, l’éditeur, etc., mais aussi des éléments qui concernent plus particulièrement les ressources en réseau, par exemple le type et le format de la ressource, les relations entre ressources, et les droits de propriété intellectuelle. (Voir chapitres suivants) Le Dublin Core de base, utilisé pour décrire une ressource en réseau quelle qu’elle soit, a été enrichi de qualificatifs et d’autres éléments pour décrire des types particuliers de ressources. (Diapo 33 ; 51 et suivants) En réalité 07 éléments ont été ajoutés depuis juin 2002 ; il s’agit de : accrualMethod accrualPeriodicity accrualPolicy Audience instructionalMethod provenance rightsHolder

32 Dublin Core But initial :
définir un ensemble de métadonnées communes à diverses communautés suffisamment simples pour que des non-spécialistes puissent les créer à n’importe quel point du cycle de vie de la ressource (créateur, propriétaire, gestionnaire, éditeur, utilisateur…) mais suffisamment structurées pour qu’elles puissent rendre les moteurs de recherche plus performants et donc faciliter la recherche et la récupération des ressources

33 Dublin Core Grands principes : 15 éléments tous optionnels
tous répétables peuvent recevoir depuis 2000 des qualificatifs (  « Dublin Core non qualifié » vs. « Dublin Core qualifié ») : raffinement d’éléments ou précision du schéma d’encodage Voir : (Diapo 51 et suivants) sont répartis en 3 groupes :

34 Dublin Core : Eléments Tableau des 15 éléments (Anglais=Français)
CONTENU VERSION PROPRIETE INTELLECTUELLE Title=Titre Subject=Sujet Description=Description Coverage=Couverture Source=Source Relation=Relation Type=Type Format=Format Date=Date Language=Langue Identifier=Identifiant Creator=Créateur/Auteur Contributor=Collaborateur Publisher=Editeur Rights=Droits Voir :

35 Dublin Core : Eléments Ces éléments sont optionnels, peuvent être répétés et peuvent apparaître dans n’importe quel ordre. Leur application dépendra des besoins spécifiques du professionnel de l’information et de la ressource informationnelle pour laquelle il crée les métadonnées. Les éléments peuvent être représentés (Codage) dans différentes syntaxes, par exemple HTML, XML, XHTML, RDF. REMARQUE Chaque élément du Dublin Core est défini par un ensemble de dix attributs provenant de la description standard ISO/IEC [ISO11179] pour des éléments de donnée. Ce sont les attributs suivants: Nom - L'étiquette attachée à l'élément de donnée Identifiant - L'identifiant unique de l'élément de donnée Version - La version de l'élément Autorité - L'autorité autorisée à enregistrer l'élément Langue - La langue dans lequel l'élément est défini Définition - Une phrase qui définit clairement quelle est la principale nature de l'élément et à quel concept il correspond Obligation - Indique si la présence de l'élément est obligatoire ou optionnelle (C'est à dire s'il contient toujours une valeur ou non) Type - Indique le type de données qui peut être représenté dans la valeur de l'elément Occurrence - Indique une limite éventuelle sur le nombre maximum de fois que l'élément peut être répété Commentaire - Une remarque sur l'utilisation de cet élément de donnée Par chance, six des dix attributs ci-dessus sont communs à tous les éléments du Dublin Core . Ce sont, avec leur valeur respective: Version: 1.1 Autorité: Dublin Core Metadata Initiative Langue: en (la définition formelle du DC est en anglais) Obligation: Optionnel Type: chaîne de caractère Occurrence: non limité

36 Titre du document : il s'agit a priori du titre principal du document
Dublin Core : Eléments Elément TITLE ou TITRE Titre du document : il s'agit a priori du titre principal du document Exemple de codage avec HTML : utilisation des balises META ; NAME (se réfère au nom de l'élément utilisé. La valeur de « NAME » sera l'un des éléments du Dublin Core, écrit sous la forme suivante : « DC.[element] » ; « CONTENT » se réfère à la valeur effective de l'élément. La valeur de « CONTENT » sera celle que l’on a assignée à l'élément. Exemple de création d’une métadonnée Titre pour le site web de l’EBAD. <META NAME="DC.Title" CONTENT=“Ecole de bibliothécaires, archivistes et documentalistes"> Autres exemples : <meta name="DC.Title" content="Hamlet"> <meta name="DC.Title" content= "L’aventure ambiguë"> En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Title a les attributs suivants : Nom: titre Identifiant: title Définition: Le nom donné à la ressource. Commentaire: Typiquement, un titre sera le nom par lequel la ressource est officiellement connue.

37 Dublin Core : Eléments Elément TITLE ou TITRE (Exemples de codage)
Avec XML <dc:title> Ecole de bibliothécaires, archivistes et documentalistes </dc:title>

38 Dublin Core : Eléments Elément SUBJECT
Sujet et mots-clefs : mots-clés ou mots matières généralement choisis dans un vocabulaire contrôlé, liste de termes conçue avant la création des enregistrements de métadonnées et utilisée de la même manière pour toutes les ressources de la collection (par exemple le thésaurus AGROVOC de la FAO ou le thésaurus de la United States National Agriculture Library, ou macrothésaurus de l’OCDE, Rameau, etc.). Indices de classification (Dewey, CDU, etc.) Exemple : <META NAME="DC.Subject" CONTENT="Agriculture"> <META NAME="DC.Subject" CONTENT="510"> En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Subject a les attributs suivants : Nom: sujet et mots-clefs Identifiant: subject Définition: Le sujet du contenu de la ressource. Commentaire: Typiquement, le sujet sera décrit par un ensemble de mots-clefs ou de phrases ou un code de classification qui précisent le sujet de la ressource. L'utilisation de vocabulaires contrôlés et de schémas formels de classification est encouragée.

39 Dublin Core : Eléments Exemple :
Elément DESCRIPTION Description du document : description en texte libre de la ressource, telle qu'un résumé, et ne s'appuie pas sur un vocabulaire contrôlé. La balise Description du DC peut même être utilisée pour fournir une table des matières de la ressource décrite. Exemple : <META NAME="DC.Description" CONTENT="Voici la page d'accueil du site de l’EBAD"> En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Description a les attributs suivants : Nom: description Identifiant: description Définition: Une description du contenu de la ressource. Commentaire: Une Description peut contenir, mais ce n'est pas limitatif: un résumé, une table des matières, une référence à une représentation graphique du contenu, ou un texte libre sur le contenu.

40 Dublin Core : Eléments Elément COVERAGE
Portée du document : peut-être un domaine géographique, un laps de temps, ou le nom d'une entité administrative). Il est recommandé d'utiliser des mots-clés ou des mots matières généralement issus d'un type spécifique de vocabulaire contrôlé (des représentations normalisées de ces types de données, par exemple un vocabulaire relatif à la couverture spatiale ou temporelle de la ressource). Exemple : <META NAME="DC.Coverage" CONTENT="Sénégal"> les éléments Subject (sujet), Description (description), et Coverage (couverture) sont utilisés pour accéder aux ressources. On peut considérer ces trois éléments comme étant indissociables. En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Coverage a les attributs suivants : Nom: couverture Identifiant: coverage Définition: La portée ou la couverture spatio-temporelle de la ressource. Commentaire: La couverture typiquement inclut une position géographique (le nom d'un lieu ou ses coordonnées), une période de temps (un nom de période, une date, ou un intervalle de temps) ou une juridiction (telle que le nom d'une entité administrative). Il est recommandé de choisir la valeur de Couverture dans un vocabulaire contrôlé (par exemple, un thésaurus de noms géographiques, comme[TGN]) et, quand cela est approprié, des noms de lieux ou de périodes plutôt que des identifiants numériques tels que des coordonnées ou des intervalles de dates. Il peut parfois être difficile de décrire les thèmes abordés par une ressource. En ce qui concerne les ressources web, on peut toujours regarder la source (code HTML) de la page web pour vérifier si des mots-clés ont été inclus et utiliser certains de ces mots-clés pour renseigner les éléments Subject et Description.

41 Eléments RELATION & SOURCE
Dublin Core : Eléments Eléments RELATION & SOURCE Les éléments Source et Relation du Dublin Core sont utilisés pour mettre en relation une ressource avec une autre. L'élément Source contient de l'information sur une deuxième ressource de laquelle dérive la ressource courante. L'élément Relation indique que la ressource est reliée d'une manière quelconque à une autre ressource. Par exemple, pour connecter le site principal de la FAO au site d'une division. Exemple : <META NAME="DC.Relation" CONTENT=" En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Relation a les attributs suivants : Nom: relation Identifiant: relation Définition: Une référence à une autre ressource qui a un rapport avec cette ressource. Commentaire: Il est recommandé de référencer cette ressource par une chaîne de caractères ou un numéro conforme à un système formel d'identification. En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Source a les attributs suivants : Nom: source Identifiant: source Définition: Une référence à une ressource à partir de laquelle la ressource actuelle a été dérivée. Commentaire: La ressource actuelle peut avoir été dérivée d'une autre ressource source, en totalité ou en partie. Il est recommandé de référencer cette source par une chaîne de caractère ou un nombre conforme à un système formel d'identification.

42 Dublin Core : Eléments Elément TYPE
Nature ou genre du contenu : L'élément Type décrit la nature de la ressource d'information. Il est recommandé de choisir les valeurs de Type au sein d'un vocabulaire contrôlé, par exemple la liste provisoire des types du Dublin Core (DCMItypes) :Collection, Dataset (données), Event (événement), Image, Service, Software (logiciel), Sound (son), Text (texte), Interactive Resource (ressource interactive) De nombreuses ressources web, comme les pages d'accueil, doivent être décrites avec plus d'un élément Type, selon le type d'informations qu'elles contiennent. La plupart des sites web contiennent du texte et des images : Exemples : <META NAME="DC.Type" CONTENT="Text"> <META NAME="DC.Type" CONTENT="Image"> En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Type a les attributs suivants : Nom: type de la ressource Identifiant: type Définition: La nature ou le genre du contenu de la ressource. Commentaire: Type inclut des termes décrivant des catégories, fonctions ou genres généraux pour le contenu, ou des niveaux d'agrégation. Il est recommandé de choisir la valeur du type dans une liste de vocabulaire contrôlé (par exemple, la liste provisoire de Types du Dublin Core[DCT1]). Pour décrire la matérialisation physique ou digitale de la ressource, il faut utiliser l'élément Format.

43 Dublin Core : Eléments Elément FORMAT
Format est le premier élément utilisé pour fournir de l'information sur la ressource elle-même. Format du document : Information sur le matériel ou l'équipement nécessaire pour utiliser ou accéder à la ressource. Choisir les valeurs de Format au sein d'un vocabulaire contrôlé, par exemple la liste des types de médias Internet (MIME) qui définit les formats de médias informatiques. Exemples : <META NAME="DC.Format" CONTENT="text/html"> <META NAME="DC.Format" CONTENT="image/gif"> <META NAME="DC.Format" CONTENT="video/quicktime"> La ressource contient, en partie, du texte codé en HTML et des images au format GIF. Il inclut aussi des vidéos au format Quicktime. Dans la description des métadonnées, on répètera ainsi plusieurs fois la balise Format du DC. En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Format a les attributs suivants : Nom: format Identifiant: format Définition: La matérialisation physique ou digitale de la ressource. Commentaire: Typiquement, Format peut inclure le media ou les dimensions de la ressource. Format peut être utilisé pour préciser le logiciel, le matériel ou autre équipement nécessaire pour afficher ou faire fonctionner la ressource. Exemples de dimensions incluent la taille et la durée. Il est recommandé de choisir la valeur du format dans une liste de vocabulaire contrôlé (par exemple, la liste des types de media définis sur Internet [MIME]).

44 Dublin Core : Eléments Elément DATE
La balise Date est utilisée pour indiquer les dates de publication, de création, de mise à disposition, ou de modification de la ressource. Il est recommandé de saisir la valeur de la date selon le format défini par l'ISO 8601, sous la forme YYYY-MM-DD (AAAA-MM-JJ). Pour un site donné, tout ce que l’on connaît est l'année de la dernière mise à jour du site : 30 juin 2007.). La balise Date du DC doit ressembler à ceci : <META NAME="DC.Date" CONTENT=" "> En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Date a les attributs suivants : Nom: date Identifiant: date Définition: Une date associée avec un événement dans le cycle de vie de la ressource. Commentaire: Typiquement, une date sera associée à la création ou à la publication d'une ressource. Il est fortement recommandé d'encoder la valeur de la date en utilisant le format défini par l'ISO 8601 [W3CDTF] sous la forme AAAA-MM-JJ.

45 Dublin Core : Eléments Elément LANGUAGE
La balise Language (langue) est utilisée pour décrire la langue dans laquelle la ressource a été créée. Il est recommandé d'utiliser comme valeurs de l'élément Language celles définies par la RFC 3066 (remplace RFC 1766) avec un code langue à deux caractères, éventuellement suivi d'un code pays à deux lettres. Par exemple, « en » pour l'anglais, « fr » pour le français, ou « en-uk » pour l'anglais utilisé au Royaume-Uni. Par exemple le site web à décrire est disponible en anglais, en français et en espagnol. On ajoutera donc trois balises Language dans l’enregistrement de métadonnées : <META NAME="DC.Language" CONTENT="en"> <META NAME="DC.Language" CONTENT="fr"> <META NAME="DC.Language" CONTENT="es"> En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Language a les attributs suivants : Nom: langue Identifiant: language Définition: La langue du contenu intellectuel de la ressource. Commentaire: Il est recommandé d'utiliser comme valeur de l'élément Langue celles définies par la RFC 1766 [RFC1766] qui comprend un code de langage à deux caractères(venant du standard ISO 639 [ISO639]), éventuellement suivi d'un code à deux lettres pour le pays (venant du standard ISO 3166 [ISO3166] ou en français [ISO3166]). Par exemple, 'en' pour l'anglais, 'fr' pour le français, ou 'en-uk' pour l'anglais utilisé au Royaume-Uni.

46 Dublin Core : Eléments Elément IDENTIFIER
L'élément Identifier (identifiant) est utilisé pour identifier de manière non ambiguë une ressource informationnelle dans un contexte donné. Il est recommandé d'utiliser comme identifiant une chaîne de caractères ou un nombre conforme à un système d'identification officiel. Voici des exemples de systèmes officiels d'identification : l'Identifiant de Ressource Uniforme (URI/URL), l'Identificateur d'Objet Numérique (DOI) et le Numéro International Normalisé du Livre (ISBN). L'URL du site web de l’EBAD est ; la balise Identifier du DC sera donc de la forme : <META NAME="DC.Identifier" CONTENT=" ebad.ucad.sn">

47 Eléments CREATOR, CONTRIBUTOR, PUBLISHER & RIGHTS
Dublin Core : Eléments Eléments CREATOR, CONTRIBUTOR, PUBLISHER & RIGHTS Le Dublin Core est aussi utilisé pour fournir de l'information sur les responsables de la ressource. Le creator (auteur), le contributor (collaborateur), et le publisher (éditeur) peuvent être soit des individus, soit des organisations ; habituellement, l'éditeur est une organisation. L'élément Rights (droits) fournit de l'information sur les droits de propriété intellectuelle, les autres droits patrimoniaux et le copyright. En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Creator a les attributs suivants : Nom: créateur Identifiant: Creator Définition: L'entité principalement responsable de la création du contenu de la ressource. Commentaire: Exemples de Créateur incluent une personne, une organisation, ou un service. Typiquement, un nom du Créateur devrait être utilisé pour désigner cette entité. En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Contributor a les attributs suivants : Nom: contributeur Identifiant: contributor Définition: Une entité qui a contribué à la création du contenu de la ressource. Commentaire: Exemples de Contributeur incluent une personne, une organisation, ou un service. Typiquement, le nom d'un contributeur devrait être utilisé ici pour désigner l'entité.

48 Eléments CREATOR, CONTRIBUTOR, PUBLISHER & RIGHTS
Dublin Core : Eléments Eléments CREATOR, CONTRIBUTOR, PUBLISHER & RIGHTS Creator : Créateur du document (auteur principal) : nom de la personne, de l'organisation ou du service à l'origine de la rédaction du document. Contributor : Contributeur au document (auteur secondaire) : nom d'une personne, d'une organisation ou d'un service qui contribue ou a contribué à l'élaboration du document. Publisher : Publicateur du document (Editeur) : nom de la personne, de l'organisation ou du service à l'origine de la publication du document. Rights : Droits relatifs à la ressource : permet de donner des informations sur le statut des droits du document, par exemple la présence d'un copyright, ou un lien vers le détenteur des droits. L'absence de cet élément ne présume pas que le document est libre de droits. En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Publisher a les attributs suivants : Nom: éditeur Identifiant: publisher Définition: L'entité responsable de la diffusion de la ressource, dans sa forme actuelle, tels, un département universitaire, une entreprise. Commentaire: Exemples d'Editeurs incluent une personne, une organisation, ou un service. Typiquement, le nom d'une maison d'édition devrait être utilisé ici. En plus des six attributs communs à tous les éléments (voir Notes de la Diapo 35) l’élément Rights a les attributs suivants : Nom: gestion des droits Identifiant: rights Définition: Information sur les droits sur et au sujet de la ressource. Commentaire: Typiquement, un élément Droits contiendra un état du droit à gérer une ressource, ou la reférence à un service fournissant cette information. Ces droits souvent couvrent les droits de propriété intellectuelle (IPR), Copyright, et divers droits de propriété. Si l'élément Droits est absent, aucune hypothèse ne peut être faite sur l'état de ces droits, ou de tout autre, par rapport à la ressource.

49 Pourquoi ces 4 éléments ensembles ?
L’élément Rights concerne la plupart du temps les 3 autres éléments, c’est-à-dire que ces derniers détiennent le plus souvent les droits relatifs à une ressource. Dans notre exemple, l’EBAD est l'auteur, l'éditeur et détient aussi les droits patrimoniaux. Par conséquent, il est important d'utiliser la même valeur que celle utilisée dans le titre : “Ecole de bibliothécaires, archivistes et documentalistes”. Les collaborateurs de la création du site web de l’EBAD n'apparaissent pas clairement. Il n'est donc pas nécessaire d'inclure une balise DC Contributor. On aura donc la description suivante : <META NAME="DC.Creator" CONTENT="Ecole de bibliothécaires, archivistes et documentalistes" > <META NAME="DC.Publisher" CONTENT="Ecole de bibliothécaires, archivistes et documentalistes" > <META NAME="DC.Rights" CONTENT="© Ecole de bibliothécaires, archivistes et documentalistes" >

50 Dublin Core & Langages de balisage
HTML / XML Les exemples que nous avons utilisé sont codés en HTML, mais la même description de métadonnées Dublin Core peut être codée en XML. Dans l’exemple qui suit, les mêmes éléments (Format, Date, Language et Identifier) sont codés en utilisant les deux syntaxes :

51 Dublin Core HTML XML <META NAME="DC.Format" CONTENT="text/html">
<META NAME="DC.Format" CONTENT="image/gif"> <META NAME="DC.Format" CONTENT="video/quicktime"> <META NAME="DC.Date" CONTENT=" "> <META NAME="DC.Language" CONTENT="en"> <META NAME="DC.Language" CONTENT="fr"> <META NAME="DC.Language" CONTENT="es"> <META NAME="DC.Identifier" CONTENT=" XML <dc:format>text/html</dc:format> <dc:format>image/gif</dc:format> <dc:format>video/quicktime</dc:format> <dc:date> </dc:date> <dc:language>en</dc:language> <dc:language>fr</dc:language> <dc:language>es</dc:language> <dc:identifier> Autres syntaxes de codage utilisables : RDF, XHTML

52 Quelques liens sur HTML et XML & XHTML
Beckett, David. An XML encoding of simple Dublin core metadata (Encodage en XML des métadonnées simples du Dublin core) (anglais) Encoding Dublin core metadata in HTML (Anglais) Mentions Meta concernant le contenu (Français, très bon site) Passer du HTML au XHTML Le XHTML

53 Dublin Core qualifié L'ensemble des éléments de métadonnées Dublin Core (DC) fournit l'information nécessaire à la description de ressources comme les ouvrages, les articles et les pages web. Toutefois, comme diverses communautés appliquaient le DC différemment, des groupes de travail furent mis en place pour examiner la manière dont les éléments sont qualifiés plus précisément pour chaque application locale. Parmi ces groupes, on trouve le DC-Education, le DC-Libraries, le DC-Government, qui étudient chacun les besoins de leur propre domaine.

54 Dublin Core qualifié Comment travaillent ces groupes ?
Les groupes de travail soumettent des listes d'éléments génériques ou spécifiques (Qualificatifs) d'une discipline au comité de validation de l'Initiative de Métadonnées du Dublin Core (IMDC ou DCMI) qui évalue ces propositions et prend la décision finale. Cette procédure permet une évolution concertée de la Série d'Eléments de Métadonnées du Dublin Core (DCMES).

55 Dublin Core qualifié Ces qualificatifs supplémentaires prennent la forme de : raffinements d'éléments, (voir liste) schémas d'encodage. (Voir liste) Ces deux sortes de qualificatifs permettent de décrire plus finement les éléments, comme le font les adjectifs dans notre langue naturelle.

56 Dublin Core : Raffinements déléments
Exemple de raffinement Imaginons qu’on veulle mettre à jour les métadonnées d'une ancienne version d'un article en ligne (A) avec des informations concernant la nouvelle version (B). On peut utiliser l'élément DC relation, défini comme « une référence à une ressource liée ». Le code HTML de la métadonnée de la ressource A serait : <META NAME="DC.Relation" CONTENT="B"> L'instruction ci-dessus indique que la ressource A est en relation avec une ressource B. Pour autant, cela ne donne pas d'information sur « comment » les deux ressources sont liées. A B

57 Dublin Core : Raffinements déléments
On souhaiterait informer l'utilisateur que la ressource A a été remplacée par la ressource B. Regarder la liste des qualificatifs pour Relation. (Diapo suivante) La paire de raffinements « Replaces/isReplacedby » (remplace/est remplacé par) semble la plus adéquate pour indiquer la relation « comment » ! Le code HTML de la métadonnée pour la ressource A serait alors le suivant : <META NAME="DC.Relation.isReplacedBy" CONTENT="B” > L'instruction ci-dessus indique deux choses : 1. A est reliée à B ; 2. A est remplacée par B Dans ce cas, le qualificatif « isReplacedby » précise la signification de l'élément « Relation » en spécifiant le type de relation. A B

58 Raffinements de l’élément RELATION
Is Version Of/ Has Version (est la version de/a pour version) Is Replaced By/Replaces (est remplacé par/remplace) Is Required By/Requires (est requise/requiert) Is Part Of/Has Part (fait partie de/a pour partie) Is Referenced By/References (est référencé par/référence) Is Format Of/Has Format (est une présentation de/a pour présentation)

59 Dublin Core : Raffinements d’éléments
En résumé, les raffinements d'éléments sont des qualificatifs permettant soit de restreindre, soit de préciser le sens d'un élément. Il est important de se souvenir qu'un élément raffiné a la même signification que l'élément non qualifié, mais avec une portée plus restreinte. Une application cliente ou un système qui ne pourrait interpréter le terme raffinant un élément devrait être capable d'ignorer le qualificatif et de traiter la valeur de la métadonnée comme s'il s'agissait d'un élément non qualifié. Voir : ou (francais)

60 Dublin Core : Schémas d’encodage
Autres types de qualificatifs qui identifient des schémas qui facilitent l'interprétation de la valeur de l'élément (ou de ses raffinements) Ils peuvent être soit des vocabulaires contrôlés, soit des notations formelles.

61 Dublin Core : Schémas d’encodage
EXEMPLE DE VOCABULAIRE CONTROLE L'instruction de métadonnée suivante permet d'interpréter la valeur « Video games and teenagers » comme une vedette matière du LCSH (Library of Congress Subject Headings ou Vedettes matières de la Bibliothèque du Congrès). <META NAME="DC.Subject" SCHEME="LCSH" CONTENT=" Video games and teenagers"> SCHEME="LCSH" Schéma d’encodage

62 Dublin Core : Schémas d’encodage
EXEMPLE DE NOTATION FORMELLE Cette date est écrite selon le format YYYY-MM-DD (AAAA-MM-JJ), connu sous le nom de ISO 8601 (W3CDTF ou W3 Consortium Date and Time Formats). Ainsi, si on utilise ce format, l'instruction de métadonnée devrait être écrite en indiquant le schéma « W3CDTF ». <META NAME="DC.Date" SCHEME="W3CDTF" CONTENT=" ">

63 Dublin Core : Schémas d’encodage
En résumé, les schémas d'encodage facilitent l'interprétation de la valeur d'un élément. Même si une application ne comprend pas le schéma d'encodage, la valeur peut toujours être utile à un lecteur. Il pourra ainsi voir, comme dans l'exemple précédent, que l'expression « Video games and teenagers » est extraite des vedettes matières de la Bibliothèque du Congrès. Tableau indiquant certains schémas agréés par le Dublin Core pour l'élément Subject.(Diapo suivante) Une liste complète des schémas d’encodage supportés pour les autres éléments, ainsi que leurs définitions sont disponibles à : (en anglais) ou (francais)

64 Dublin Core : Schémas d’encodage
Elément DCMES Schémas d'encodage Subject - LCSH [Library of Congress Subject Headings] (vedettes matières de la   Bibliothèque du Congrès) - MeSH [Medical Subject Headings] (vocabulaire médical MeSH) - DDC [Dewey Decimal Classification] (classification décimale de Dewey) - LCC [Library of Congress Classification] (classification de la   Bibliothèque du Congrès) - UDC [Universal Decimal Classification] (CDU : classification décimale   universelle)

65 Dublin Core : Espace de noms
Dans l'univers des métadonnées, les espaces de noms sont utilisés pour identifier les éléments « nouvellement définis » et leurs qualificatifs. Un espace de noms a une autorité d'enregistrement. Il s'agit de l'organisme autorisé à enregistrer les nouveaux éléments et qualificatifs dans un espace de noms donné. Toute organisation peut créer son propre espace de noms à partir du moment où elle s'engage à sa maintenance. L'IMDC est l'autorité d'enregistrement pour les éléments et qualificatifs du Dublin Core. Exemples Annuaire téléphonique : où les abonnés d’une même région peuvent être un espace de noms Répertoire ou dossiers des OS des Ordinateurs

66 Dublin Core : Espace de noms
Ces nouveaux éléments, raffinements et schémas d'encodage permettent de rendre la signification des éléments du Dublin Core plus claire et plus spécifique au domaine couvert.

67 Dublin Core : Espace de noms
Comment les reconnaître ? Les intitulés des espaces de noms sont indiqués par la chaîne de caractères située devant l’élément. Exemple <rdf:Description rdf:about=" <dc:title> EBAD : Ecole de Bibliothécaires, Archivistes et documentalistes, Université Cheikh Anta Diop, Dakar, Sénégal </dc:title> <dc:creator> EBAD </dc:creator> <dc:date> </dc:date> </rdf:Description> Cet exemple d’enregistrement de métadonnées est codé en XML et RDF et Dublin Core sont les espaces de noms Namespaces in XML 1.0 (Second Edition) : W3C Recommendation 16 August 2006 : Namespaces in XML 1.1’ (4 février 2004) en version française. [2006/11/24]. (RDF) Resource Description Framework est un modèle de graphe destiné à décrire de façon formelle les ressources Web et leurs métadonnées, de façon à permettre le traitement automatique de telles descriptions. Développé par le W3C, RDF est le langage de base du Web sémantique. Une des syntaxes (sérialisation) de ce langage est RDF/XML. En annotant des documents non structurés et en servant d'interface pour des applications et des documents structurés (par ex. bases de données, GED, etc. ) RDF permet une certaine interopérabilité entre des applications échangeant de l'information non formalisée et non structurée sur le Web. Voir : [Consultée le 21 juin 2007] Le Web sémantique désigne un ensemble de technologies visant à rendre le contenu des ressources du World Wide Web accessible et utilisable par les programmes et agents logiciels, grâce à un système de métadonnées formelles, utilisant notamment la famille de langages développés par le W3C. Le World Wide Web Consortium, abrégé W3C, est un consortium fondé en octobre 1994 pour promouvoir la compatibilité des technologies du World Wide Web telles que HTML, XHTML, XML, RDF, CSS, PNG, SVG et SOAP. Le W3C n'émet pas des normes au sens européen, mais des recommandations à valeur de standards industriels. Sa gestion est assurée conjointement par le Massachusetts Institute of Technology (MIT) aux États-Unis, le European Research Consortium for Informatics and Mathematics (ERCIM) en Europe (auparavant l'Institut national de recherche en informatique et en automatique français (INRIA)) et l'Université Keio au Japon. Un document W3C traverse plusieurs étapes avant de devenir une Recommendation : Working Draft (brouillon de travail), Last Call Working Draft (dernier appel), Candidate Recommendation (candidat à la recommandation), et Proposed Recommendation (recommandation proposée). Une recommandation peut être mise à jour par errata édité séparément, jusqu'à l'accumulation de suffisamment de modifications ; une nouvelle version de la recommandation est alors publiée (XML en est aujourd'hui à sa troisième version). Parfois, une recommandation recommence le processus, comme RDF. Le W3C publie aussi des remarques informatives qui ne sont pas destinées à être traitées en tant que norme. Le consortium laisse le soin aux fabricants de suivre les recommandations. Contrairement à l'Organisation internationale de normalisation ou d'autres corps internationaux de standardisation, le W3C ne possède pas de programme de certification. Cependant les spécifications techniques du W3C définissent la conformité de manière plus ou moins explicite et formelle. Le niveau d'implémentation des spécifications a été amélioré par la production d'un rapport d'implémentation pendant la phase de Candidate Recommendation.

68 Dublin Core : Registre DC Registry Créé par l’IMDC
contient tous les éléments et qualificatifs du Dublin Core. Un registre de métadonnées contient la définition des termes (éléments, raffinements d'éléments et schémas d'encodage), informe sur les nouveaux termes disponibles, contrôle les changements de version des termes, fait la promotion des termes en vue de leur réutilisation. Ces registres ont pour objectif de fournir une vue unique des éléments actuellement disponibles et de leurs définitions. (registre Dublin core en anglais) Définition (wikipedia) : Un registre de métadonnées est, selon la définition qu'en donne le Dublin Core, dans l'ébauche finale du 24 février 2001, un « Système de gestion des métadonnées, c'est-à-dire un système formel qui fournit l'information d'autorité sur la sémantique et la structure de chaque élément. Pour chaque élément, le registre en donne la définition, les qualificatifs qui lui sont associés, ainsi que les correspondances avec des équivalents dans d'autres langues ou d'autres schémas. » Voir :

69 Dublin Core : Profils d’application
Si on a besoin d'éléments de métadonnées du Dublin Core pour décrire correctement des ressources, on peut consulter le registre du Dublin Core (DC Registry) qui contient les éléments déjà déclarés et choisir les éléments qui répondent à ses besoins (ne pas oublier que tous les éléments sont optionnels). L'emprunt d'éléments issus de différents espaces de noms (dans le DC ou autre espace de noms) aboutit à la création d'un profil d'application. De cette façon, on économise le temps que l’on aura passé à créer son modèle de données Remarque : Les profils d'application ne permettent pas de déclarer de nouveaux éléments. Les éléments d'un profil d'application sont propres à l'application et issus d'espaces de noms existants. Espace de noms 1 Espace de noms 2 Espace de noms 3 Profil d’application + + = Métadonnées

70 Dublin Core : Profils d’application
Existe un profil d’application spécialement destiné aux bibliothèques, « DC-Libraries » Voir : < Ajout des éléments : Audience, Edition, Location Possibilité de qualifier les éléments Contributor et Publisher au moyen d’un rôle Possibilité de qualifier l’élément Date par son schéma d’encodage (ISO 8601 recommandée) Etc. DUBLIN CORE METADATA INITIATIVE (DCMI) - Libraries Working Group. Library Application Profile [en ligne]. [S. l.] : DCMI, [Consultée le 21 novembre 2006]. Disponible sur Internet : < documents/2004/09/10/library-application-profile/>.

71 CONCLUSION L'objectif du Dublin Core et des autres standards de métadonnées est de promouvoir l'interopérabilité par la réutilisation d'un ensemble de métadonnées communes. Cela facilite l'échange et le partage d'information dans un environnement en réseau. Pour se comprendre mutuellement, on doit utiliser les mêmes balises de métadonnées, ou au moins quelques métadonnées communes. Par conséquent : lorsque cela est possible, utiliser un standard de métadonnées existant et largement accepté comme le DC (méthode de codage le plus « populaire » utilisé sur le web). On peut sans peine inclure de telles métadonnées dans ses propres pages : il suffit de faire figurer les balises où elles sont encodées dans l'en-tête HTML de source d’une ressource. Grâce à ces informations, des systèmes automatiques peuvent réellement tirer parti des pages, car elles contiennent leur propre descriptif synthétique. Plus grand sera le nombre de communautés adoptant un standard unique, plus forte sera l'interopérabilité. Quelques rappels : Les raffinements d'éléments sont des qualificatifs qui permettent soit de restreindre, soit de préciser le sens d'un élément. Voir : (en anglais) Les schémas d'encodage sont des qualificatifs qui identifient des schémas facilitant l'interprétation de la valeur de l'élément et/ou de ses raffinements. Voir : (en anglais) Dans l'univers des métadonnées, les espaces de noms sont utilisés pour identifier des éléments « nouvellement définis » et leurs qualificatifs. Un profil d'application est créé en utilisant des éléments existants qui peuvent venir d'un ou de plusieurs espaces de noms enregistrés par une ou plusieurs autorités. Voir : FAO. Différence entre espace de nom et profil d’application. [2006/11/24]. Namespaces in XML 1.1’ (4 février 2004) en version française. [2006/11/24]. Plus grand est le nombre de communautés adoptant un standard unique, plus forte est l'interopérabilité ; par conséquent, lorsque cela est possible, réutiliser un standard de métadonnées bien accepté. Pour créer un nouvel élément : Commencer par : 1) utiliser ou adapter des éléments, 2) combiner des éléments et leurs qualificatifs provenant de différents espaces de noms, 3) qualifier des éléments existants en créant des raffinements ou des schémas, si tout ça n’est pas possible parce qu’éléments inexistants alors, 4) créer son propre élément et l’ajouter dans son propre espace de noms.

72 http://dublincore.org/tools/ (source) [Consultée le 20 juin 2007]
LIENS : (générateurs de métadonnées Dublin Core) (support des exercices) (source) [Consultée le 20 juin 2007] . (Cet outil fournit la possibilité de créer des AgMES/DC métadonnées pour encoder des pages web.) MKDoc (MKDoc Ltd., United Kingdom) Outil gratuit à télécharger et installer localement Mozilla Firefox Dublin Core Viewer Extension (Splintered, United Kingdom) Téléchergement gratuit et installation locale (Mozilla Firefox 1.5 – 3.0a1 uniquement) UKOLN. Dublin Core metadata editor. (Générateur de métadonnées en Dublin core) ou Editor-Converter Dublin Core metadata (outil en ligne gratuit, éd. Par Kirovohrad Regional Universal Research Library, Ukraine ) (Générateur de métadonnées DC et convertisseur vers UNIMARC) DescribeThis (eSand, Spain) Générateur automatique de métadonnées DC (Gratuit) Etc. AgMES = Agricultural Metadata Element Set (Série d'éléments de métadonnées agricoles) L'Initiative de normes de métadonnées agricoles (AgStandards) a pour but de promouvoir des normes communes dans le domaine de l'agriculture. FAO. AgMES. Série d’éléments de métadonnées agricoles. [2007/06/21].

73 LIENS Teasdale G. (trad.) Guide d’utilisation du Dublin Core. [Consultée le 16 juin 2007]. Jacquet, Christophe. Métadonnées et Dublin Core. [Consultée le 21 juin 2007] (Complet et précis sûrement l’un des meilleurs liens sur la question) (Liste de tous les éléments et de leurs qualificatifs (raffinements et schémas) en français) IMotep. Dublin Core. Métadonnées. [Consultée le 15 juin 2007]. Verscoustre A. M. (trad.) Eléments de métadonnées du Dublin Core.[Consultée le 16 juin 2007]. Cherhal, Élizabeth. Le Dublin Core (DC). Babel - edit -, L'indexation des ressources pédagogiques numériques. ENSSIB - janvier 2006 [en ligne] (*)

74 LIENS Principles and operation of the Dublin Core Metadata Initiative. [Consultée le 12 juin 2007] (en anglais). ISO (Organisation Internationale de Normalisation). [Consultée le 13 juin 2007]. BnF. Professionnels. [Consultée le 25 novembre 2006]. The Dublin Core Metadata Element Set. ANSI/NISO Z [Consultée le 15 juin 2007] (en anglais).

75 LIENS DCMI Education Working Group. [Consultée le 15 juin 2007] (en anglais). BnF (Bibliothèque nationale de France). [Normes, formats, modélisation]. [Consultée le 25 novembre 2006] (en anglais). Deschatelets J Dossier sur les métadonnées. [Consultée le 19 juin 2007]. Noy N. F. MCGuinness D. L. Angjeli A. (trad.). Développement d’une ontologie 101 : guide pour la création de votre première ontologie. [Consultée le 25 novembre 2006]. Site de traductions du W3C :

76 FIN Merci de votre aimable attention