LES MÉTADONNÉES COMME OUTIL DE GESTION DES ARCHIVES PHOTOGRAPHIQUES

par

Yvon Lemay

Cursus vol. 4 no 1 (automne 1998)

Cursus est le périodique électronique étudiant de l'École de bibliothéconomie et des sciences de l'information (EBSI) de l'Université de Montréal. Ce périodique diffuse des textes produits dans le cadre des cours de l'EBSI.

ISSN 1201-7302

C. élec. : cursus@ere.umontreal.ca
URL : http://www.fas.umontreal.ca/ebsi/cursus/

Droits d'auteur

Tout texte demeure la propriété de son auteur. La reproduction de ce texte est permise pour une utilisation individuelle. Tout usage commercial nécessite une permission écrite de l'auteur.

L'auteur

Yvon Lemay a terminé sa maîtrise en bibliothéconomie et en science de l'information (option archivistique), à l'École de bibliohéconomie et des sciences de l'information (EBSI) en avril 1998. Il est actuellement cinémathécaire aux Services documentaires Information de la Société Radio-Canada. Il fait partie d'une équipe qui travaille sur les films de nouvelles dans le cadre du projet des Archives des réseaux français.

Ce texte a été réalisé à l'hiver 1998 dans le cours Recherche individuelle (BLT-6850) sous la direction de James Turner. Nous aimerions remercier le professeur Turner pour l'aide qu'il nous a accordée ainsi que la direction de Parcs Canada, canal de Lachine pour nous avoir permis d'utiliser le Relevé photographique du canal de Lachine et de reproduire l'une des photographies dans notre texte. Nous aimerions également remercier les responsables du laboratoire d'informatique de l'EBSI, en particulier Rabah Djanati, pour leur précieux soutien technique.

Le texte suivant a été produit dans le cadre du cours BLT 6850, Recherche individuelle, sous la direction de M. James Turner.


Table des matières

INTRODUCTION


Tout en suivant de près le projet du Resource Description Framework (RDF) qui est présentement mené par le World Wide Web Consortium, l'objet de notre recherche consiste, à partir d'un ensemble restreint de documents photographiques, à intégrer aux 15 éléments de description prévus dans le Dublin Core (soit la zone <meta des documents HTML) les informations prescrites par les Règles pour la description des documents d'archives (RDDA).
Les objectifs que nous poursuivons, en effectuant ce projet pilote, sont de deux ordres. D'une part, il s'agit de vérifier les avantages que peuvent représenter les métadonnées dans la gestion des archives photographiques. En effet, dans la mesure où de plus en plus d'archives photographiques sont disponibles sur le web, les métadonnées ne deviendraient-elles pas un outil idéal de gestion de ces archives? Cet outil permettrait autant de décrire et de diffuser les documents d'archives que de les repérer ou de les gérer. D'autre part, il s'agit de mettre en évidence l'importance que prennent les normes de description des documents d'archives dans l'élaboration des métadonnées pour les documents HTML.
Pour mener à bien ce projet, nous avons suivi la démarche suivante. Après avoir intégré les données des RDDA au Dublin Core à l'aide du Dublin Core Metadata Template, nous avons mis en place un site web temporaire. Ce site a été indexé puis interrogé à l'aide de moteurs de recherche afin de vérifier les avantages ainsi que les inconvénients des métadonnées dans la gestion des archives photographiques.
Évidemment, la portée d'un tel projet pilote est forcément limitée. Il faudrait, entre autres, examiner plus en détail la manière d'intégrer les RDDA au éléments du Dublin Core. Toutefois, nous osons croire que, malgré ses limites, ce projet aura permis de montrer comment les archivistes peuvent et doivent aujourd'hui exercer leur rôle. D'ailleurs, comme le soulignait David Bearman, la discipline de l'archivistique a toujours été de caractère méta-informationnelle puisque, par définition, elle consiste à recueillir de l'information sur les systèmes d'information. Raison de plus de continuer à le faire.

LES MÉTADONNÉES ET L'ARCHIVISTIQUE
À partir de la fin des années 1980, et notamment avec la conférence sur les recherches en matière de documents électroniques organisée par la National Historical and Records Commission (NHRC) en 1991, la question des métadonnées est devenue un sujet de préoccupation de plus en plus important dans le domaine des archives. Et pour cause.
Face à l'environnement électronique, il est dorénavant nécessaire de faire une distinction entre la structure imposée par le logiciel et l'information contenue dans un document. Cette dernière constitue les données alors que les règles de structuration et de présentation des données, telles qu'imposées et déterminées au sein des logiciels constituent les métadonnées, c'est-à-dire l'information au sujet de l'information.
Ainsi, au plan archivistique, les métadonnées représentent de nombreux avantages. Comme le fait remarquer David Wallace, elles permettent: a) d'identifier et de préserver le contexte du document; b) de préserver la structure du document et du logiciel; c) de produire et de conserver toutes les informations relatives à l'évaluation et à l'arrangement des documents; d) d'effectuer la gestion du cycle de vie des documents; e) de préserver et/ou d'assurer la migration de la fonctionnalité des systèmes; f) de créer des inventaires des ressources disponibles dans les milieux (Wallace, 1993, 88). Bref, les métadonnées donnent la possibilité aux archivistes de jouer pleinement leur rôle et d'assumer la gestion des documents électroniques.
Il existe actuellement une très grande variété de métadonnées. Il suffit de consulter le site "Digital Libraries: Metadata Resources" que l'International Federation of Library Associations and Institutions (IFLA, 1998) consacre à la question des données sur les données pour s'en convaincre. Aussi la question qui se pose est: faut-il laisser laisser libre cours à l'initiative de tout un chacun en la matière ou, au contraire, faut-il chercher à développer et à imposer des normes qui seraient communes à tous? Il semble que, de plus en plus, les divers intervenants du domaine de l'information préoccupés par cette question soient convaincus du bien-fondé d'opter pour la deuxième option, notamment en ce qui concerne les documents HTML que l'on retrouve sur le Web.

LES MÉTADONNÉES ET LE DUBLIN CORE


"The World Wide Web has changed both the creation, distribution, storage and retrieval and presentation of information. The amount of information and networked resources produced are increasingly growing on the WWW. This means that there will be difficulties for the end-user to search, browse and navigate to the relevant information" (Preben, 1998 )
Entre mars 1995 et mars 1997 a eu lieu une série de quatre ateliers réunissant des experts internationaux de différentes disciplines dans le but de développer "a core element set that provides adequate data for Web resource discovery and is simple for authors and content managers to create and maintain" (Weibel et Lagoze, 1997, 176).
Le résultat de leurs travaux, connu sous le nom de "Dublin Core Metadata", soit le nom de la ville (Dublin, Ohio) où s'est tenu la première rencontre, comprend 15 éléments de description. Il est à noter que, suite au troisième atelier ("Image Metadata Workshop"), il a été convenu de développer un modèle permettant de tenir compte des ressources tant textuelles que visuelles.
Voici la liste des 15 éléments de description du Dublin Core ainsi qu'un aperçu du leur contenu. Ces informations proviennent du document "Dublin Core Metadata Element Set: Reference Description" disponible sur le Web (http://purl.oclc.org/metadata/dublin_core/) :
  1. Title
    Label: title
    The name given to the resource by the creator or publisher.
  2. Author or Creator
    Label: creator
    The person or organization primarily responsible for creating the intellectual content of the resource. For example, authors in the case of written documents, artists, photographers, or illustrators in the case of visual resources.
  3. Subject and Keywords
    Label: subject
    The topic of the resource. Typically, subject will be expressed as keywords or phrases that describe the subject or content of the resource. The use of controlled vocabularies and formal classification schemas is encouraged.
  4. Description
    Label: description
    A textual description of the content of the resource, including abstracts in the case of document-like objects or content descriptions in the case of visual resources.
  5. Publisher
    Label: publisher
    The entity responsible for making the resource available in its present form such as a publishing house, a university department, or a corporate entity.
  6. Other Contributor
    Label: contributor
    A person or organization not specified in a creator element who has made significant intellectual contributions to the resource but whose contribution is secondary to any person or organization specified in a creator element (for example, editor, transcriber, and illustrator).
  7. Date
    Label: date
    The date the resource was made available in its present form. Recommended best practice is an 8 digit number in the form YYYY-MM-DD as defined in http://www.w3.org/TR/NOTE-datetime, a profile of ISO 8601. In this scheme, the date element 1994-11-05 corresponds to November 5, 1994. Many other schema are possible, but if used, they should be identified in an unambiguous manner.
  8. Resource Type
    Label: type
    The category of the resource, such as home page, novel, poem, working paper, technical report, essay, dictionary. For the sake of interoperability, type should be selected from an enumerated list that is under development in the workshop series at the time of publication of this document. See http://sunsite.berkeley.edu/Metadata/types.html for current thinking on the application of this element
  9. Format
    Label: format
    The data format of the resource, used to identify the software and possibly hardware that might be needed to display or operate the resource. For the sake of interoperability, format should be selected from an enumerated list that is under development in the workshop series at the time of publication of this document.
  10. Resource Identifier
    Label: identifier
    String or number used to uniquely identify the resource. Examples for networked resources include URLs and URNs (when implemented). Other globally-unique identifiers,such as International Standard Book Numbers (ISBN) or other formal names would also be candidates for this element in the case of off-line resources.
  11. Source
    Label: source
    A string or number used to uniquely identify the work from which this resource was derived, if applicable. For example, a PDF version of a novel might have a source element containing an ISBN number for the physical book from which the PDF version was derived.
  12. Language
    Label: language
    Language(s) of the intellectual content of the resource. Where practical, the content of this field should coincide with RFC 1766. See: http://ds.internic.net/rfc/rfc1766.txt
  13. Relation
    Label: relation
    The relationship of this resource to other resources. The intent of this element is to provide a means to express relationships among resources that have formal relationships to others, but exist as discrete resources themselves. For example, images in a document, chapters in a book, or items in a collection. Formal specification of relation is currently under development. Users and developers should understand that use of this element is currently considered to be experimental.
  14. Coverage
    Label: coverage
    The spatial and/or temporal characteristics of the resource. Formal specification of coverage is currently under development. Users and developers should understand that use of this element is currently considered to be experimental.
  15. Rights Management
    Label: rights
    A link to a copyright notice, to a rights-management statement, or to a service that would provide information about terms of access to the resource. Formal specification of rights is currently under development. Users and developers should understand that use of this element is currently considered to be experimental.
Nous aurons l'occasion d'apporter des précisions quant au contenu de ces éléments lorsque nous aborderons la façon d'incorporer les métadonnées du Dublin Core au document HTML. Pour l'instant, nous aimerions souligner le fait que, mis à part certains éléments qui sont reliés à des listes en développement, le contenu de la plupart des 15 éléments de description du Dublin Core n'est pas à proprement parler contrôlé. Au mieux, suggère-t-on le recours à certains outils existant pour ce faire. D'où par conséquent l'intérêt d'utiliser les normes qui ont été développées au fil des ans afin de décrire les documents d'archives.

LES RÈGLES POUR LA DESCRIPTION DES DOCUMENTS D'ARCHIVES (RDDA)

Publié en 1990 par le Bureau canadien des archives, les Règles pour la description des documents d'archives (RDDA), comportent trois principaux volets: a) les zones de description, b) les niveaux de description et c) les vedettes.

Les zones de description

Au nombre de neuf, les zones de description sont les suivantes:
  1. Zone du titre et de la mention de responsabilité
  2. Zone de l'édition
  3. Zone des précisions relatives au support
  4. Zone des dates de création, de diffusion, de publication, etc.
  5. Zone de la collation
  6. Zone de la collection
  7. Zone de la description des documents d'archives
  8. Zone des notes
  9. Zone du numéro normalisé et des modalités d'acquisition
Il est à remarquer que le contenu de chacune de ces zones varie en fonction de la catégorie de documents à décrire. Par exemple, le chapitre 4 sur les documents iconographiques donne des indications concernant la description ''des documents d'archives prenant la forme de tableaux, de dessins, de gravures, de photographies ou d'images produites par divers procédés d'illustration visuelle'' (Règles, 4.0A1).

Les niveaux de description

Selon les Règles pour la description des documents d'archives, ''la description d'un fonds d'archives consiste en des descriptions qui représentent le fonds comme un ensemble organique et dynamique. Ce dernier est composé de séries qui peuvent elles-mêmes être constituées de dossiers qui, à leur tour, contiennent des pièces. Chacune de ces parties fait (ou peut faire) l'objet d'une description. Il en résulte plusieurs descriptions qui doivent être reliées hiérarchiquement entre elles afin de rendre compte de l'organisation du fonds'' (Règle 1.0A1).
Cette relation hiérarchique est particulièrement évidente dans la zone 7, la zone de la description des archives. Au niveau du fonds ou de la série, la description comprendra soit une histoire administrative concise de la personne morale, soit une notice biographique concise de la personne physique qui est responsable de la création de l'unité archivistique en question, un historique de la conservation ainsi que des informations sur les fonctions ou activités qui ont été à l'origine de la création soit du fonds, soit de la série (Portée et contenu).
Au niveau du dossier ou de la pièce, les règles demandent de faire un historique de la conservation correspondant à l'unité archivisitique à décrire (lorsque justifié) et de donner, dans la section ''Portée et contenu'', les informations sur les fonctions et les activités qui ont été à l'origine de la création du dossier ou de la pièce.

Les vedettes

Enfin, les Règles pour la description des documents d'archives prévoient trois types d'accès : accès de provenance, accès d'auteur et les autres accès indépendants du sujet. Par accès de provenance, il s'agit ''des accès aux noms du créateur du fonds et de ses séries si les noms du créateur de la série diffèrent de ceux du créateur du fonds'' (Règle 21.1). Par accès d'auteur, il s'agit au niveau de la série, du dossier et de la pièce ''des accès aux noms des auteurs identifiés dans la zone du titre et de la mention de responsabilité'' (Règle 21.5). Pour les autres accès indépendants du sujet, mentionnons seulement l'accès aux noms apparaissant dans la zone du titre et de la mention de responsabilité (Règle, 21.9).
Pour bien comprendre comment ces règles s'appliquent, prenons à titre d'exemple les trois niveaux de description que nous avons utilisés pour rendre compte du Relevé photographique du canal de Lachine, le document qui nous servira à mener ce projet pilote.

Exemple 1

Il s'agit de la description du Relevé photographique du canal de Lachine dans son ensemble. Il est à noter que, dans cette description, nous avons considéré le relevé comme étant une série d'un fonds d'archives. La présentation correspond à la forme la plus courante. Dans ce type de présentation, la première partie contient les informations des zones 1 à 6, la deuxième partie, les informations de la zone 7 et et la troisième partie celles des zones 8 et 9, là ou les vedettes n'apparaissent pas dans ce type de présentation.

RELEVÉ PHOTOGRAPHIQUE / Parcs Canada, Canal de Lachine. - 1997. - 523 photographies: coul.; 10x15 cm + plans.

HISTOIRE ADMINISTRATIVE:
Fermé à la navigation en 1970, le canal de Lachine a été transféré à Parcs Canada par le ministère des Travaux publics en 1978. Depuis cette date, il fait partie du réseau des sites historiques canadiens. D'une longueur de quatorze kilomètres, le canal de Lachine qui relie le Vieux-Montréal au lac Saint-Louis est un élément patrimonial majeur de la région montréalaise. Les cyclistes, piétons et skieurs qui empruntent la piste cyclable longeant le canal peuvent y admirer des bâtiments et des écluses qui ont été témoins de toute l'évolution industrielle de Montréal.

En prévision d'importants travaux de restauration devant débuter au printemps 1998, travaux qui mèneront à la réouverture du canal à la navigation de plaisance au tournant du XXIe siècle, le canal de Lachine a fait réaliser au cours de l'été 1997 un relevé photographique de ses installations ainsi que des bâtiments avoisinant. L'objectif de ce relevé était double : conserver un témoignage de l'état actuel du canal et constituer un outil de référence pour la réalisation des travaux.

PORTÉE ET CONTENU:
Les 523 photographies du relevé sont réunies dans trois cahiers selon six secteurs qui, à l'exception des secteurs 1 et 3, sont subdivisés en trois sections:

Chaque photographie est accompagnée d'une légende comprenant le nom (du lieu représenté), la localisation (c'est-à-dire l'endroit où a été prise la photographie) et, dans plusieurs cas, un numéro de référence qui correspond aux fiches techniques du document Inventaire et évaluation des ressources culturelles canal de Lachine produit par la firme Archémi en 1995. Un plan d'ensemble ainsi qu'un plan de chacun des six secteurs provenant du document de consultation publique L'avenir du lieu historique national du Canal-de-Lachine (1996) ont été incorporés aux cahiers.

NOTES:
Le titre est basé sur le contenu du document.
Les négatifs sont placés à la fin du troisième cahier.
Toute reproduction totale ou partielle des photographies est interdite sans le consentement préalable de Parcs Canada (lachine-mtl@pch.gc.ca).

Exemple 2

Le deuxième exemple nous situe au niveau suivant de description. Ce niveau correspond à un dossier plutôt qu'à une sous-série comme cela devrait être normalement le cas. Nous avons choisi d'éliminer ce niveau de description afin de permettre à l'utilisateur d'avoir accès plus rapidement aux photographies en format réduit qui sont situées au bas de la description.

SECTEUR 5 (POINTE SAINT-CHARLES/PETITE-BOURGOGNE) : PISTE CYCLABLE / Parcs Canada, Canal de Lachine. - 1997. - 52 photographies : coul.; 10 x 15 cm.

PORTÉE ET CONTENU:
Les 52 photographies de cette section du secteur 5 couvre la piste cyclable du canal de Lachine de la passerelle Atwater (à l'ouest) jusqu'au pont Wellington (à l'est).

NOTES:
Titre basé sur le contenu du document.
Les photographies sont accompagnées d'une légende.
Toute reproduction totale ou partielle des photographies est interdite sans le consentement préalable de Parcs Canada (lachine-mtl@pch.gc.ca).

PHOTOGRAPHIES:

Exemple 3

Le dernier niveau correspond à la description d'une pièce. Dans ce cas, la description est précédée de l'image photographique en grand format (comparativement au format réduit du niveau précédent).

PONT DES SEIGNEURS / Chantal Lavallée. - 1997. - 1 photographie : coul. ; 10 x 15 cm + légende.

PORTÉE ET CONTENU:
Cette photographie est la 29e du secteur 5 (Pointe Saint-Charles/Petite-Bourgogne) : piste cyclable du Relevé photographique du canal de Lachine.

NOTES:
Titre officiel propre.
Légende : Nom : Pont des Seigneurs, Localisation : Rue des Seigneurs, au-dessus de l'écluse 3, Numéro de référence: 5OC05C
Le numéro de référence correspond à une fiche technique du document Inventaire et évaluation des ressources culturelles canal de Lachine produit par la firme Archémi en 1995.
Ressources culturelles no 103 sur le plan du document de consultation publique L'avenir du lieu historique national du Canal-de-Lachine (1996).
Toute reproduction totale ou partielle des photographies est interdite sans le consentement préalable de Parcs Canada (lachine-mtl@pch.gc.ca).

LES RDDA et le Dublin Core

Sachant en quoi consistent les Règles pour la description des documents d'archives (RDDA) et comment elles s'appliquent, il reste maintenant à savoir de quelle façon elles peuvent s'intégrer aux 15 éléments de description du Dublin Core. Pour ce faire, dressons d'abord, à l'aide d'un tableau, un parallèle entre les 15 éléments du Dublin Core et les neuf zones des RDDA, puis, à partir d'un exemple, voyons pratiquement comment cette intégration peut s'effectuer .

Tableau
  1. Title
  2. Author or Creator
  3. Subject and Keywords
  4. Description
  5. Publisher (du document électronique)
  6. Other Contributor
  7. Date (de création du document électronique)
  8. Resource Type (liste en développement)
  9. Format (à partir d'une liste en développement)
  10. Resource Identifier (URL, ISBN)
  11. Source (du document)
  12. Language
  13. Relation (dans ou à d'autres documents)
  14. Coverage (liste en développement)
  15. Rights management
  • zone 1
  • zone 1
  • accès (vedettes)
  • zone 7; zone 5 ; zone 3
  • zone 2
  • zone 8
  • xxxxxxxxxxxxxxxxxx
  • xxxxxxxxxxxxxxxxxx
  • xxxxxxxxxxxxxxxxxx
  • zone 9
  • zone 8; zone 4; zone 2
  • zone 8 ( notes)
  • relations hiérarchiques; zone 8; zone 6
  • xxxxxxxxxxxxxxxxxx
  • zone 8
Comme l'indique ce tableau, mis à part ceux dont le contenu est déterminé soit par des listes en développement, soit par une norme ISO, les éléments de description prévus par les Règles pour la description des documents d'archives sont en mesure de s'intégrer aux 15 éléments du Dublin Core. Et l'on pourrait même ajouter que leur caractère normalisé en font des outils tout désigné pour cette tâche. À ce propos, dans le document de présentation des 15 éléments du Dublin Core, l'on tenait à signaler que ''to promote global interoperability, a number of the element descriptions may be associated with a controlled vocabularies for the respective element values'' (Dublin Core, 1997).
Bien sûr, ce n'est là qu'une première ébauche de correspondance qui devra être davantage élaborée. Néanmoins, malgré le caractère encore exploratoire de ce parallèle entre les éléments prescrits par les RDDA et ceux du Dublin Core, le degré de concordance que l'on constate à ce stade-ci est suffisamment élevé pour nous permettre de croire qu'il est légitime de procéder à un tel essai d'intégration.
D'ailleurs, il est à remarquer que cette mise en parallèle entre le Dublin Core et les Règles pour la description des documents d'archives indique que ces dernières devraient, dans l'avenir, tenir compte des éléments 7, 8, 9, 10 et 15 du Dublin Core dans leur politique de description. Espérons que ce sera le cas, notamment dans le chapitre sur les documents informatiques qui doit venir s'ajouter sous peu à ceux déjà disponibles.
Mais si le contenu des RDDA peut manifestement s'intégrer aux éléments du Dublin Core, quelle forme cela prendra-t-il concrètement? Pour le savoir, reprenons le dernier exemple concernant la description d'une pièce du Relevé photographique du canal de Lachine. À noter qu'en ce qui concerne l'élément 3 "Subject and Keywords", nous avons ajouté, comme le suggère le guide sur La Gestion des documents photographiques au gouvernement du Canada réalisé par les Archives nationales du Canada, les descripteurs du Library of Congress Thesaurus for Graphic Materials (LCTGM) aux vedettes prévues par les RDDA. Pour ce qui est des éléments 5, 6 et 10, nous avons pris en considération le contexte actuel du projet pilote.

Exemple

  1. Pont des Seigneurs
  2. Lavallée, Chantal
  3. RDDA= Parcs Canada, Canal de Lachine; Lavallée, Chantal
    LCTGM= Canals--Canada--Montréal--1997; Bridges--Canada--Montréal--1997
  4. Photographie : coul. ; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 29e du secteur 5 (Pointe Saint-Charles/Petite-Bourgogne) : piste cyclable du Relevé photographique du canal de Lachine. NOTES: Titre officiel propre. Légende : Nom : Pont des Seigneurs, Localisation : Rue des Seigneurs, au-dessus de l'écluse 3, Numéro de référence: 5OC05C .
  5. École de bibliothéconomie et des sciences de l'information, Université de Montréal
  6. Lemay, Yvon
  7. 1998-02-19
  8. Relevé photographique
  9. Image numérisée (35,2 Ko) en format JPEG
  10. URL: http://tormade.ere.umontreal.ca/~lemayyv/projet/
  11. Parcs Canada, Canal de Lachine. Relevé photographique. Montréal, 1997, 3 cahiers, 523 photographies
  12. français
  13. Le numéro de référence correspond à une fiche technique du document Inventaire et évaluation des ressources culturelles canal de Lachine produit par la firme Archémi en 1995. Ressources culturelles no 103 sur le plan du document de consultation publique L'avenir du lieu historique national du Canal-de-Lachine (1996).
  14. Canada, Québec (Province), Montréal, 1997
  15. Toute reproduction totale ou partielle des photographies est interdite sans le consentement préalable de Parcs Canada (lachine-mtl@pch.gc.ca).

MISE EN PLACE DES ÉLÉMENTS DU PROJET PILOTE

Générer et incorporer les métadonnées

 Comment trouver des façons simples d'intégrer les métadonnées aux documents HTML "without requiring additional tags or changes to browser software, and without unnecessarily compromising current practices for robot collection of data"? (Weibel, 1998). La solution sur laquelle les responsables du Dublin Core se sont entendus est la suivante : 1) encoder les métadonnées dans les étiquettes META des documents HTML à raison d'un élément par étiquette et utiliser autant d'étiquettes que nécessaire, 2) donner la référence URL des règles de description qui ont été utilisées pour décrire le document, en l'occurence celles du Dublin Core et 3) utiliser autant que possible des sources connues afin d'établir le contenu des éléments de description.
Dans le but d'aider les utilisateurs à créer des métadonnées selon le modèle du Dublin Core, le Nordic Metadata Project a développé et rendu accessible sur le Web un gabarit qui en gère automatiquement la syntaxe. Il suffit de saisir le contenu de 15 éléments de description du Dublin Core dans les espaces appropriés du Dublin Core Metadata Template et, une fois l'opération complétée, les métadonnées sont générées aussitôt en format HTML selon les normes prescrites. Tout ce qu'il reste à faire est d'en copier le résultat et de l'incorporer au document.

Exemple

 Voici le traitement opéré par le Dublin Core Metadata Template du Nordic Metadata Project à partir des métadonnées de la 29e photographie de la section de la piste cyclable du Secteur 5 du Relevé photographique du Canal de Lachine (exemple précédent). Nous avons ajouté les balises de début et de fin de la zone HEAD pour en signaler l'emplacement exact dans le document HTML. 
<HEAD>

<TITLE> Pont Des Seigneurs

<META NAME="DC.Date.X-MetadataLastModified" CONTENT="(SCHEME=ISO8601) 1998-02-19"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#date"



<META NAME="DC.Title" CONTENT="Pont des Seigneurs"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#title"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Creator.PersonalName" CONTENT="Lavall%E9e, Chantal"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#creator"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Subject" CONTENT="Parcs Canada, Canal de Lachine"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#subject"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Subject" CONTENT="Lavall%E9e, Chantal"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#subject"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Subject" CONTENT="(SCHEME=TGM1) Canals--Canada--Montr%E9al--1997"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#subject"

<META NAME="DC.Subject" CONTENT="(SCHEME=TGM1) Bridges--Canada--Montr%E9al--1997"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#subject"



<META NAME="DC.Description" CONTENT="Photographie : coul. %3B 10 x 15 cm + l%E9gende.

PORT%C9E ET CONTENU: Cette photographie est la 29e du secteur 5 

(Pointe Saint-Charles/Petite-Bourgogne): piste cyclable du Relev%E9 photographique 

du canal de Lachine. NOTES: Titre officiel propre. L%E9gende : Nom :  Pont des Seigneurs, 

Localisation : Rue des Seigneurs, au-dessus de l'%E9cluse 3, Num%E9ro de r%E9f%E9rence :

5OC05C"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#description"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Publisher" CONTENT="%C9cole de biblioth%E9conomie et des sciences 

de l'information, Universit%E9 de Montr%E9al"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#publisher"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Contributor.PersonalName" CONTENT="Lemay, Yvon"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#contributor"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Date" CONTENT="(SCHEME=ISO8601) 1998-02-19"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#date"



<META NAME="DC.Type" CONTENT="Image.Photograph"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#type"



<META NAME="DC.Format" CONTENT="(SCHEME=IMT) text/html"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#format"

< REL=SCHEMA.imt HREF="http://sunsite.auc.dk/RFC/rfc/rfc2046.html">

<META NAME="DC.Format" CONTENT="(SCHEME=IMT) image/jpeg"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#format"

<LINK REL=SCHEMA.imt HREF="http://sunsite.auc.dk/RFC/rfc/rfc2046.html"



<META NAME="DC.Identifier" CONTENT="http://tormade.ere.umontreal.ca/%7Elemayyv/projet/"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#identifier"



<META NAME="DC.Source" CONTENT="Parcs Canada, Canal de Lachine. Relev%E9 

photographique. Montr%E9al, 1997, 3 cahiers, 523 photographies"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#source"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Language" CONTENT="(SCHEME=ISO639-1) fr"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#language"



<META NAME="DC.Relation" CONTENT="Arch%E9mi,  Inventaire et %E9valuation des ressources 

culturelles canal de Lachine, 1995"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#relation"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Relation" CONTENT="Parcs Canada, L'avenir du lieu historique national 

du Canal-de-Lachine, 1996"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#relation"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"



<META NAME="DC.Coverage" CONTENT="Canada, Qu%E9bec (Province), Montr%E9al, 1997"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#coverage"



<META NAME="DC.Rights" CONTENT="Toute reproduction est interdite sans le consentement 

pr%E9alable de Parcs Canada (lachine-mtl@pch.gc.ca)"

<LINK REL=SCHEMA.dc HREF="http://purl.org/metadata/dublin_core_elements#rights"

<LINK REL=SCHEMA.rdda REFERENCE="ISBN: 0969079745"

</HEAD
Le Dublin Core Metadata Template s'ajuste aux besoins de l'utilisateur, c'est-à-dire que le gabarit est conçu de sorte qu'il est possible d'ajouter de nouvelles cases à celles qui sont données implicitement pour chacun des éléments. Règle générale, le nombre de caractères disponibles est suffisant bien que nous avons dû, dans le cas du 15e élément, ajuster le contenu à l'espace prévu par le gabarit. Mais, une fois les métadonnées générées, rien n'empêche l'utilisateur d'apporter les corrections qu'il juge nécessaire.
En plus de générer automatiquement les métadonnées en format HTML selon la convention établie par les membres du Dublin Core, le Dublin Core Metadata Template permet à l'utilisateur d'avoir accès au contenu des listes en développement (lorsqu'elles sont disponibles) ainsi qu'à diverses sources en ligne pour lui venir en aide dans l'indexation et la classification des documents. Comme l'indique les résultats générés par le gabarit, la référence est ensuite indiquée dans l'étiquette en question (ex.: TGM1 pour LC Thesaurus for Graphic Materials 1 : Subject Terms).
Il est à noter qu'en ce qui concerne les éléments 8 (Type) et 9 (Format), nous avons suivi les directives des listes en développement et que pour l'élément 14 (Coverage), comme ces directives n'étaient pas disponibles, nous avons dû opter pour une formule de notre choix. En plus de la référence URL au Dublin Core, nous avons ajouté, comme le suggère le Nordic Metadata Project, la référence aux RDDA (en l'occurence le numéro ISBN) chaque fois que cela nous semblait pertinent.

Mise en place, validation et inscription du site temporaire

Le site temporaire s'intitule "Rélevé photographique du canal de lachine: expérience sur les RDDA et le Dublin Core". Les 22 fichiers qu'il contient ont été transférés dans notre compte d'usager à l'adresse suivante: http://tornade.ere.umontreal.ca/~lemayyv/projet/. Le site comprend:

Une fois validé par le "HTML Validation Service Response" (http://valsvc.webtechs.com/) et les corrections nécessaires apportées, nous avons inscrit le site temporaire auprès de 9 moteurs ou répertoires de recherche en faisant appel au service gratuit offert par la firme Submit It (http://www.Submit-it.com). Ces moteurs ou répertoires sont : De plus, nous l'avons inscrit auprès du moteur de recherche HotMeta Search Engine. "HotMeta is a metadata search engine. It fetches web-accessible documents from the Internet, indexes the metadata extracted from them and provides the user interface to search on this metadata" (MetaWeb Project, 1998).
Après une semaine, et maintes vérifications auprès des différents moteurs ou répertoires de recherche, le site a été répertorié uniquement par Alta Vista, Infoseek et HotBot. En ce qui concerne HotMeta Search Engine, l'insuccès auprès de ce moteur de recherche semble s'expliquer par le fait que, pour l'instant, les seuls sites qu'il indexe sont des sites australiens. C'est dommage car ce moteur de recherche est parmi l'un des rares à être spécialement conçu en fonction des 15 éléments de description du Dublin Core. D'autres existent, comme le Nordic Web Index, mais ils permettent seulement d'interroger et non d'ajouter de nouveaux sites comprenant les éléments de description du Dublin Core.

LES MÉTADONNÉES À L'HEURE DE L'INTERROGATION

Sur le Web

 Quelle est la politique des moteurs de recherche en ce qui a trait aux métadonnées? Prenons l'exemple d'Alta Vista, le chef de file incontesté en ce domaine. "In the absence of any other information, Alta Vista will index all words in your document (except for comments), and will use the first few words of the document as a short abstract. It is however possible for you to control how your page is indexed by using the META tag to specify both additional keywords to index, and a short description. Let's suppose your page contains: AltaVista will then do two things: It will index both fields as words, so a search on either poodles or dog will match. It will return the description with the URL. In other words, instead of showing the first couple of lines of the page, a match will look like the following: Pink Poodles Inc. We specialize in grooming pink poodles. http://pink.poodle.org/ - size 3k - 29 Feb 96. AltaVista will index the description and keywords up to a limit of 1,024 characters" (Alta Vista, 1998). De prime abord, une telle politique semble des plus favorables à l'interrogation de pages Web à l'aide des métadonnées issues des 15 éléments de description du Dublin Core. Or malheureusement, dans la pratique, il n'en est rien comme nous avons pu le constater lors de l'interrogation de notre site temporaire par différents moteurs de recherche. Qu'il s'agisse d'Alta Vista, Infoseek ou HotBot, les résultats ont été les mêmes. En mode "Advanced Search", chacun de ces moteurs répertorie le site de façon très précise. En effet, la requête "Relevé photographique du canal de Lachine" donne comme résultat : 1 document.

Infoseek found 1 page containing at least one of these words: "relevé photographique du canal de Lachine"
Relevé photographique du canal de Lachine: expérience sur les RDDA et ...
RELEVÉ PHOTOGRAPHIQUE DU CANAL DE LACHINE: EXPÉRIENCE SUR LES RDDA ET LE DUBLIN CORE. Ce site est temporaire. Il vise à mener une expérience dans le cadre d'un cours ...
98% http://tornade.ere.umontreal.ca/~lemayyv/projet/ (Size 4.2K) Document date: 19 Mar 1998

Hot Bot
look for all the words
Relevé photographique du canal de Lachine
Returned: 1 match.
Breakdown: relevé: 11654, photographique: 5109, du: 2406933, canal: 248877, de: 14479400, lachine: 6235
1.Relevé photographique du canal de Lachine: expérience sur les RDDA et le Dublin Core
100% RELEVÉ PHOTOGRAPHIQUE DU CANAL DE LACHINE: EXPÉRIENCE SUR LES RDDA ET LE DUBLIN CORE Ce site est temporaire. Il vise à mener une expérience dans le cadre d'un cours (BLT-6850: Recherche individuelle) du programme de maîtrise de l'École de...
http://tornade.ere.umontreal.ca/~lemayyv/projet/, 4277 bytes, 20Mar98

Compte tenu de la multitude de sites que l'on retrouve sur le Web, le résultat est certes fort appréciable. Mais, par ailleurs, aucun des trois moteurs de recherche ne permet une interrogation plus détaillée. Autant Alta Vista qu'Infoseek ou Hot Bot ne semblent aller plus loin que la zone du titre qui apparaît dans le haut de l'écran du logiciel de navigation. Autrement dit, ils ignorent complètement les éléments de description du Dublin Core.

Hot Bot
look for all the words
+META +name=DC.Publisher +Content=École de bibliothéconomie et des sciences de l'information
Sorry-- your search yielded no results.
You might want to revise your search query and try again...

Infoseek found no results for:
"META NAME=DC.Contributor Content=Lemay, Yvon"

Dans le but de vérifier cet état de fait et de tenter, si possible, de contourner cet obstacle, nous avons ajouté des mots-clés (keywords) à toutes les pages de notre site déjà munies des métadonnées du Dublin Core. Peine perdue! Cet ajout n'a fait aucune différence lors de l'interrogation.

Infoseek found no results for: "keywords=Parcs Canada, Canal de Lachine"

Hot Bot
look for all the words
keywords=Parcs Canada, Canal de Lachine
Sorry-- your search yielded no results.

Est-ce que ce résultat négatif est dû à notre façon d'inscrire les métadonnées, soit <META NAME=Keywords Content=XXXau lieu de <Keywords=XXX? Si oui, cela viendrait corroborer notre hypothèse.

En mode local

Ce constat à propos des métadonnées et des moteurs de recherche n'aurait pas été complet sans une tentative d'interrogation en mode local. Pour ce faire, nous avons tétéchargé "AltaVista Personal 97", une version offerte gratuitement par la firme Alta Vista à partir de la page de recherche avancée du moteur de recherche. À la requête "Relevé photographique du canal de Lachine", ce n'est plus 1 mais bien 12 documents qui ont été répertoriés cette fois par Alta Vista, à savoir:
  1. PS5N14.HTM
    CARTONS RECYCLÉS DE MONTRÉAL INC. (ENTREPÔTS BLACKSMITH SHOP) / Chantal Lavallée. - 1997. - 1 photographie : coul.; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 14e du sec
    a:\PS5N14.HTM - 98-04-05
  2. PS5N15.HTM
    CARTONS RECYCLÉS DE MONTRÉAL INC. (ENTREPÔTS BLACKSMITH SHOP) / Chantal Lavallée. - 1997. - 1 photographie : coul.; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 15e du sec
    a:\PS5N15.HTM - 98-04-05
  3. PS5N13.HTM
    CARTONS RECYCLÉS DE MONTRÉAL INC. / Chantal Lavallée. - 1997. - 1 photographie : coul.; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 13e du secteur 5 (Pointe Saint-Charles
    a:\PS5N13.HTM - 98-04-05
  4. PS5S28.HTM
    REDPATH SUGAR REFINERY / Chantal Lavallée. - 1997. - 1 photographie : coul. ; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 28e du secteur 5 (Pointe Saint-Charles/Petite-Bo
    a:\PS5S28.HTM - 98-04-05
  5. PS5S27.HTM
    REDPATH SUGAR REFINERY / Chantal Lavallée. - 1997. - 1 photographie : coul. ; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 27e du secteur 5 (Pointe Saint-Charles/Petite-Bo
    a:\PS5S27.HTM - 98-04-05
  6. PS5S26.HTM
    REDPATH SUGAR REFINERY / Chantal Lavallée. - 1997. - 1 photographie : coul. ; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 26e du secteur 5 (Pointe Saint-Charles/Petite-Bo
  7. PS5S29.HTM
    REDPATH SUGAR REFINERY / Chantal Lavallée. - 1997. - 1 photographie : coul. ; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 29e du secteur 5 (Pointe Saint-Charles/Petite-Bo
    a:\PS5S29.HTM - 98-04-05
  8. PS5P25.HTM
    PONT DES SEIGNEURS / Chantal Lavallée. - 1997. - 1 photographie : coul. ; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 29e du secteur 5 (Pointe Saint-Charles/Petite-Bourgo
    a:\PS5P25.HTM - 98-04-05
  9. PS5P32.HTM
    ÉCLUSE 3 (NORD) / Chantal Lavallée. - 1997. - 1 photographie : coul.; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 32e du secteur 5 (Pointe Saint-Charles/Petite-Bourgogne)
    a:\PS5P32.HTM - 98-04-05
  10. PS5P47.HTM
    CANAL DE FUITE (NORD) / Chantal Lavallée. - 1997. - 1 photographie : coul.; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 47e du secteur 5 (Pointe Saint-Charles/Petite-Bour
    a:\PS5P47.HTM - 98-04-05
  11. PS5P43.HTM
    PISTE CYCLABLE / Chantal Lavallée. - 1997. - 1 photographie : coul.; 10 x 15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 43e du secteur 5 (Pointe Saint-Charles/Petite-Bourgogne)
    a:\PS5P43.HTM - 98-04-05
    12. >
  12. INDEX.HTM
    RELEVÉ PHOTOGRAPHIQUE DU CANAL DE LACHINE: EXPÉRIENCE SUR LES RDDA ET LE DUBLIN CORE Ce site est temporaire. Il vise à mener une expérience dans le cadre d'un cours (BLT-6850: Recherche individuelle
    a:\INDEX.HTM - 98-04-05
Une différence pour le moins notable mais qui n'est pas due cependant à la présence de métadonnées. En effet, pour vérifier si, en mode local, Alta Vista tenait compte des métadonnées, nous avons effectué deux requêtes à partir du nom de la photographe ayant pris les images du Relevé photographique du canal de Lachine. Dans un cas, nous avons inscrit son nom tel qu'il apparaît dans le texte, soit Chantal Lavallée. Dans l'autre, nous l'avons inscrit tel qu'il apparaît dans les métadonnées, soit Lavallée, Chantal. Les résultats ne laissent aucun doute: Bien sûr, nous réalisons que les expériences que nous avons menées dans le cadre de ce projet pilote sont très limitées et qu'il serait nécessaire d'effectuer une recherche plus poussée sur les métadonnées et les moteurs de recherche afin de mieux identifier la ou les sources de problèmes. Néanmoins, malgré la portée limitée de nos résultats, il est légitime de se poser la question suivante: est-ce que l'inclusion de métadonnées, selon le modèle du Dublin Core, dans un document HTML est une opération vraiment utile? Avant de répondre à cette question, examinons le projet du Resource Description Framework (RDF) mené par le World Wide Web Consortium.

LE DUBLIN CORE ET LE RDF

Le Resource Description Framework (RDF) est une spécification présentement (je rappelle au lecteur que nous sommes à l'hiver 1998) développée par le World Wide Web Consortium qui vise à établir une infrastructure pour le traitement des métadonnées. Parmi les nombreuses applications envisagées, le RDF pourra servir : "in resource discovery to provide better search engine capabilities; in cataloging for describing the content and content relationships available at a particular Web site, page, or digital library; by intelligent software agents to facilitate knowledge sharing and exchange; in content rating; in describing collections of pages that represent a single logical "document"; for describing intellectual property rights of Web pages, and in many others"(W3C, "Introduction to RDF Metadata").

L'objectif général du RDF "is to define a mechanism for describing resources that makes no assumptions about a particular application domain, nor defines the semantics of any application domain. The definition of the mechanism should be domain neutral, yet the mechanism should be suitable for describing information about any domain" (W3C, "RDF Model and Syntax"). À cette fin, le RDF utlise le XML (eXtensible Markup Language) comme langage. Issu du SGML (Standard Generalized Markup Language), la norme ISO de structuration des documents, le XML est un langage qui, en plus d'intégrer Unicode, la norme mondiale de conversion de tous les formats d'alphabet, permet de créer autant de balises que nécessaire (Lubkov, 1997). En effet, à la différence du HTML (Hypertext Markup Language), lui aussi un dérivé du SGML, le XML ne fait que décrire une syntaxe pour le balisage. Par conséquent, "the names of the tags are not set in concrete and authors can "invent" them as appropriate. Whereas HTML provides a fixed repertoire of named tags - P for 'paragraph', H1 for 'heading 1' and so on, XML simply spells out the rules for using angle brackets and other notation to specify a mark-up language of your own design. The tag names and what they actually mean are left for you to choose as appropriate for your application" (W3C, "XML Activity"). Le RDF comprend 3 éléments de base: 1) des noyaux (nodes) 2) des attributs (attributes) et 3) des valeurs (values). "Nodes can be any web resources (pages, servers, basically anything for which you can give a URI), even other instances of metadata. Attributes are named properties of the nodes, and their values are either atomic (text strings, numbers, etc.) or other resources or metadata instances. In short, this mechanism allows us to build labeled directed graphs" (W3C, "Introduction to RDF Metadata"). La réunion de ces éléments donne lieu à des assertions (assertions) contenues dans des "series" (serializations) qui sont précédées d'instructions (Processing Instructions) permettant d'identifier la source des abréviations utilisées dans les assertions. Par exemple, l'affirmation selon laquelle "John Smith is the Author of the document whose URL is http://www.bar.com/some.doc" s'exprimerait comme suit:

<?namespace href="http://docs.r.us.com/bibliography-info as="bib"?
<?namespace href="http://www.w3.org/schemas/rdf-schema" as="RDF"?
<RDF:serialization
<RDF:assertions href="http://www.bar.com/some.doc"
<bib:authorJohn Smith</bib:author
</RDF:assertions
</RDF:serialization

Du moins en octobre 1997, car depuis ce temps la syntaxe du RDF a grandement évolué. Dorénavant, c'est-à-dire d'après la version d'octobre 1998 (W3C, "Resource Description Framework (RDF) Schemas"), cette affirmation s'exprimerait plutôt ainsi:

<rdf:RDF
<xmlns:rdf="http://www.w3.org/schemas/rdf-schema"
<xmlns:bib="http://docs.r.us.com/bibliography-info" <rdf:Description about="http://www.bar.com/some.doc"
<bib:authorJohn Smith</bib:author
</rdf:Description
</rdf:RDF

Selon les derniers états de la syntaxe, l'exemple du Relevé photographique du canal de Lachine montrant les métadonnées du Dublin Core en format HTML prendrait donc la forme suivante (forme qui, il est important de le souligner, reste à être confirmée par les responsables du Dublin Core):

<rdf:RDF
<xmlns:rdf="http://www.w3.org/TR/WD-rdf-syntax/"
<xmlns:dc= "http://purl.oclc.org/metadata/dublin_core/" <rdf:Description about="http://tornade.ere.umontreal.ca/~lemayyv/projet/ps5p25.htm"
<dc:TitlePont des Seigneurs</dc:Title
<dc:Creator.PersonalNameLavallée, Chantal</dc:Creator.PersonalName
</RDF:assertions
<dc:Subject
<rdf:Bag
<rdf:liCanals--Canada--Montréal--1997</rdf:li
<rdf:liBridges--Canada--Montréal--1997</rdf:li
</rdf:BAG
<dc:schemeTGM1</dc:scheme
</dc:Subject
<dc:DescriptionPhotographie: coul.; 10x15 cm + légende. PORTÉE ET CONTENU: Cette photographie est la 29e du secteur 5 (Pointe Saint-Charles/Petite-Bourgogne): piste cyclable du Relevé photographique du canal de Lachine. NOTES: Titre officiel propre. Légende: Nom: Pont des Seigneurs, Localisation: Rue des Seigneurs, au-dessus de l'écluse 3, Numéro de référence: 5OC05C.</dc:Description
</rdf:Description
</rdf:RDF

Et ainsi de suite pour chacun des 15 éléments de description du Dublin Core. À noter que le RDF est conçu pour supporter des relations binaires. Par conséquent, pour exprimer plus de deux relations, il est nécessaire de les décomposer en autant de sous-ensembles, comme on peut déjà le constater avec l'élément "Subject" dans notre exemple. Le Dublin Core semble donc parfaitement adaptable au RDF et la chose n'est pas surprenante comme en fait foi cette déclaration tirée de l'un des documents de travail du World Wide Web Consortium: "One obvious application for RDF is in the description of web pages. This is one of the basic functions of the Dublin Core [DC] initiative. The Dublin Core is a set of 15 elements believed to be broadly applicable to describing web resources to enable their discovery. The Dublin Core has been a major influence on the development of RDF. An important consideration in the development of the Dublin Core was to allow simple descriptions, but also to provide the ability to qualify descriptions in order to provide both domain specific elaboration and descriptive precision" (W3C, "RDF Schemas").
Mais quelles sont les chances que cette nouvelle norme en matière de métadonnées et que le nouveau langage sur lequel elle s'appuie connaissent une large diffusion sur le World Wide Web? Très bonnes, semble-t-il, si l'on se fie à la stratégie de développement utilisée par le Consortium. "The RDF working group - the W3C vehicle for crafting new standards - includes representatives from key companies and organizations: Netscape, Microsoft, IBM, Nokia, OCLC, etc. The interest from the large web browser vendors gives us hope that large scale deployment of tools which understand about RDF will take place; this in turn should lead to the widespread adoption of RDF on the web"(W3C, "Introduction to RDF Metadata").

CONCLUSION:
LES MÉTADONNÉES COMME OUTIL DE GESTION

Quels avantages le Dublin Core représente-t-il dans la gestion des archives photographiques? Les normes de description des documents d'archives ont-elles un rôle important à jouer dans l'élaboration du contenu des métadonnées? Qu'en est-il de ces deux objectifs qui motivaient notre recherche?
De prime abord, l'on serait porté à dire que les métadonnées issues des 15 éléments de description du Dublin Core sont à toutes fins pratiques inutiles dans la gestion des archives photographiques et qu'il serait préférable d'investir son temps et ses énergies ailleurs. En effet, comme nous avons pu le constater, la présence des éléments du Dublin Core n'a changé en rien les résultats obtenus lors du repérage du site temporaire par les différents moteurs de recherche. Alors pourquoi s'embarrasser de données sur les données puisque, dans leur format actuel, elles sont ignorées par les moteurs de recherche?
Malgré les apparences, il serait prématuré de tout abandonner maintenant, particulièrement après ce que nous venons de voir à propos du RDF. Non seulement son développement a été influencé par le Dublin Core mais, compte tenu du rôle joué par le World Wide Web Consortium dans le milieu informatique et de l'implication des principales compagnies et organisations dans le dossier, il permettra au Dublin Core de disposer enfin de tous les moyens nécessaires pour s'imposer.
Ce geste serait d'autant plus prématuré, qu'entre temps, il est toujours possible de mettre en place des solutions permettant de tirer profit des métadonnées du Dublin Core. Par exemple, il suffit de jouer le jeu des moteurs de recherche et de les faire précéder par les trois types de métadonnées (title, keywords et description) qu'ils prennent en considération. Une autre solution et qui, croyons-nous, serait encore plus profitable, du moins dans la perspective d'une interrogation en mode local, consiste en ceci : il suffirait que la description qui accompagne un document photographique adopte non pas le format de présentation des RDDA mais celui du Dublin Core. De la sorte, comme le moteur de recherche indexe tous les mots contenus dans un document HTML, il serait possible de simuler, si l'on peut dire, une interrogation selon les 15 éléments du Dublin Core. Et rien n'empêche de combiner les deux solutions.
Bref, nous sommes persuadé que ceux qui persisteront à incorporer les métadonnées du Dublin Core à leurs documents HTML disposeront dans l'avenir d'outils de gestion des archives photographiques qui feront l'envie de tous. Description détaillée de l'image et de son environnement. Meilleur repérage tant sur le Web qu'en mode local. Production de listes permettant de gérer l'organisation des documents photographiques. Possibilité d'établir des liens entre les photographies provenant de différentes sources tout en préservant leur contexte d'origine. Sans compter que ces outils développés en fonction de normes seront mieux à même de s'adapter à l'évolution de l'environnement électronique.
Quant à la question des normes de description, la réponse est plus nette. À la suite de cette recherche, il est clair que les RDDA, par leur caractère normalisé, s'avèrent un élément essentiel dans l'élaboration du contenu des métadonnées. Bien sûr, il est nécessaire d'adapter le format de ces règles à celui du Dublin Core mais, comme nous avons pu le constater, cette transposition ne porte nullement atteinte à leur intégrité.
Mais pour faire en sorte que les RDDA deviennent la référence sur le Web en matière de métadonnées de documents d'archives, la communauté archivistique devra entreprendre diverses actions. Pour que ces règles puissent s'imposer, elle devra entre autres: 1) repenser les RDDA en fonction du contexte électronique, 2) donner accès à une version électronique en ligne des RDDA, 3) développer un gabarit du même genre que le Dublin Core Metadata Template permettant de générer et d'intégrer des métadonnées aux documents d'archives et 4) rendre disponible le chapitre des RDDA sur les documents électroniques.
Nul doute, l'archivistique est et doit, plus que jamais, être une discipline méta-informationnelle.

BIBLIOGRAPHIE