3.9 Métadonnées descriptives – Profils d'application, Dublin Core (DC)

3.9.1    Une grande partie des efforts consacrés aux métadonnées dans le domaine patrimonial ont mis l'accent sur les métadonnées descriptives en tant que ramification du catalogage traditionnel. Toutefois, il est clair qu'une attention excessive dans ce domaine (par exemple raffinement localisé des balises descriptives et vocabulaires contrôlés) aux dépens d'autres considérations décrites ci-dessus provoquera des défauts dans le système. La Fig. 4 met en évidence les diverses interdépendances qu'il convient de mettre en place, ainsi que les balises de métadonnées descriptives qui constituent en quelque sorte un sous-ensemble de tous les éléments en jeu.


Fig. 4 : Métadonnées descriptives simples (Avec l'autorisation de Dempsey, CLIR/DLF primer, 2005)

3.9.2    L'interopérabilité doit être une composante essentielle de toute stratégie concernant les métadonnées : pour un entrepôt d'archives, la conception par une équipe dédiée de systèmes élaborés et indépendants les uns des autres conduira  à une faible productivité, des coûts élevés et une portée minimum. Il en résultera une industrie artisanale de métadonnées incapable de se développer. Les métadonnées descriptives illustrent en effet le cas classique de la maxime de Richard Gabriel 'Worse is better' ('Moins bien, c'est mieux). Comparant deux programmes de langage, l'un élégant mais complexe, l'autre maladroit mais simple, Gabriel prédit avec raison que le langage le plus simple se développera plus rapidement, et qu'ainsi, davantage de personnes seraient amenées à améliorer le langage simple plutôt que le langage complexe. La démonstration d'un tel cas de figure est apportée par la manière dont s'est généralisé le succès de Dublin Core (DC), pourtant considéré initialement par les professionnels  comme une solution improbable du fait de sa très grande simplicité.    

3.9.3    La mission de DCMI (DC Metadata Initiative) a consisté à favoriser la détection des ressources sur internet. Ceci grâce au développement de standards de métadonnées permettant de repérer les ressources dans différents domaines, grâce à la définition de structures assurant l'interopérabilité de sets (regroupements) de métadonnées, et enfin grâce au développement de sets spécifiques d'une communauté ou d'une discipline qui soient en cohérence avec leurs objectifs. Un vocabulaire de quinze éléments seulement est utilisé pour la description des ressources, pour l'ensemble des trois catégories de métadonnées. Aucun élément n'est obligatoire : tous sont reproductibles, même si les intégrateurs peuvent spécifier d'autres profils d'application - voir paragraphe 3.9.8 ci-dessous. L'origine du nom "Dublin" provient de la ville de l'Ohio qui a accueilli en 1995 le groupe de travail ; "core" (cœur) provient du fait que les éléments, de portée générale, génériques, sont utilisables pour décrire un large éventail de ressources. L'utilisation de DC s'est répandue durant plus d'une décennie, les quinze éléments descriptifs ayant été officiellement adoptés dans les normes suivantes : ISO Standard 15836-2003 de février 2003 (février 2009) [ISO 15836 http://dublincore.org/documents/dces/#ISO15836 ] (2009) NISO standard Z39.2007 de Mai 2007 [NISOZ3985 http://dublincore.org/documents/dces/#NIZO3985 ] et IETF RFC 5014 d'Août 2007 [RFC5013 http://dublincore.org/documents/dces/#RFC5013 ].
 
Tableau 1 (ci-dessous) listes des quinze éléments DC avec leurs définitions officielles (abrégé) et suggestions d'interprétation dans un contexte audiovisuel.

Eléments DC Définition DC Interprétation audiovisuelle
Title (Titre) Nom donné à la ressource Titre principal associé à l'enregistrement
Subject (Sujet) Sujet de la ressource Principaux thèmes couverts
Description (Description) Présentation de la ressource Notes explicatives, résumés d'entretiens, descriptions du contexte environnemental ou culturel, liste des contenus
Creator (Créateur) Entité principalement responsable de la réalisation de la ressource Ni l'auteur, ni le compositeur des œuvres enregistrées mais le nom du service d'archivage
Publisher (Editeur) Entité responsable de la mise à disposition de la ressource N'est pas l'éditeur du document original numérisé. Typiquement l'éditeur et le créateur sont les mêmes
Contributor (Contributeur) Entité responsable des contributions au contenu de la ressource Toute personne ou source sonore citée. Nécessite des qualificatifs appropriés tels que le rôle joué (par ex. interprète, personne qui a effectué l'enregistrement)
Date (Date) Moment ou période associée à un événement du cycle de vie de la ressource N'est pas la date d'enregistrement ou de l'original (P) mais une date relative à la ressource elle-même
Type (Type) Nature ou genre du contenu de la ressource Domaine de la ressource, non le genre musical. Ainsi Son : oui, Jazz : non
Format (Format) Format de fichier, medium physique, ou dimensions de la ressource Format de fichier, non du support physique original
Identifier (Identifiant) Référence non ambigüe de la ressource dans un contexte donné Susceptible d'être l'URI du fichier audio
Source (Source) Ressource apparentée dont la ressource décrite est dérivée Référence à une ressource dont la ressource présente est dérivée
Language (Langue) Langue de la ressource Langue de la ressource
Relation (Relation) Ressource apparentée Référence aux objets apparentés
Coverage (Couverture) Périmètre spatio-temporel de la ressource, domaine spatial d'application de la ressource ou juridiction compétente en vertu de laquelle la ressource est pertinente. Ce qu'illustre l'enregistrement, par exemple des particularismes culturels tels que des chants traditionnels ou un dialecte
Rights (Gestion des droits) Information sur les droits associés à la ressource Information sur les titulaires de droits associés à la ressource

Tableau 1 : Les 15 éléments DC

3.9.4    Afin d'inclure des propriétés supplémentaires dans le processus, le nombre d'éléments de DC a été augmenté. Ainsi, un certain nombre d'éléments ajoutés ("termes") serviront à décrire les média basés sur le temps :

Termes DC Définition DC Interprétation audiovisuelle
Alternative (Alternatif) Toute forme de titre utilisée comme substitut ou alternative du titre formel de la ressource Titre alternatif, par ex. un titre traduit, un pseudonyme, un rangement alternatif d'éléments dans un titre générique
Extent (Etendue) Taille ou durée de la ressource Taille et durée d'un titre
Extent Original (Etendue d'origine) Manifestation physique ou numérique de la ressource Taille ou durée de l'enregistrement  de la source d'origine
Spatial (Spatial) Caractéristiques spatiales du contenu intellectuel de la ressource Localisation de l'enregistrement comprenant les coordonnées topographiques compatibles avec les interfaces cartographiques
Temporal (Temporel) Caractéristiques temporelles du contenu intellectuel de la ressource Circonstances dans lesquelles l'enregistrement a été effectué
Created (Créé) Date de création de la ressource Date d'enregistrement et toute autre date importante dans le cycle de vie de l'enregistrement

Tableau 2 Termes (sélection)

3.9.5    Les intégrateurs de DC peuvent faire le choix d'utiliser les quinze éléments soit dans leur ancien dc: variant (par exemple, http://purl.org/dc/elements/1.1/creator) ou dans le dcterms: variant (par exemple, http://purl.org/dc/terms/creator) en fonction des exigences d'applications. Toutefois, au fil du temps, en particulier si RDF fait partie de la stratégie des métadonnées, on s'attend (avec les encouragements de la DCMI) à ce que les intégrateurs utilisent la sémantique plus précise dcterms: properties, ils se conformeront strictement aux bonnes pratiques des métadonnées destinées aux machines de traitement.

3.9.6    Y compris sous cette forme étendue, la granularité de DC peut être insuffisante pour  répondre aux exigences d'archives audiovisuelles spécialisées. L'élément Contributor, par exemple, nécessitera la mention du rôle du contributeur dans l'enregistrement pour éviter, dans ce cas de figure, la confusion entre interprètes et compositeurs ou acteurs et auteurs. Une liste de rôles communs (ou 'relators') ('rapporteurs') a été élaborée pour des agents (MARC relators) par la Library of Congress. Voici deux exemples de la manière dont ils peuvent être implémentés.

<dcterms:contributor>
<marcrel:CMP>Beethoven,Ludwig van, 1770-1827</marcrel:CMP>
<marcrel:PRF>Quatuor Pascal</marcrel:PRF>
</dcterms:contributor>

<dcterms:contributor>
<marcrel:SPK>Greer,Germaine, 1939- (female)</marcrel:SPK>
<marcrel:SPK>McCulloch, Joseph, 1908-1990 (male)</marcrel:SPK>
</dcterms:contributor>

Le premier exemple place une balise 'Beethoven' en tant que compositeur (composer) (CMP) et 'Quatuor Pascal' en tant qu'interprète (performer) (PRF). La deuxième balise place les deux contributeurs, Greer et McCulloch en tant que locuteurs (speakers) (SPK) sans aller jusqu'à déterminer celui qui mène l'interview et celui qui répond aux questions. Cette information devrait être transmise à un autre endroit dans les métadonnées, par exemple dans Description ou Title.

3.9.7    A cet égard, un schéma différent peut-être préférable, ou pourrait être inséré en tant que schéma d'extension supplémentaire (illustration dans la Fig. 2). MODS (Metadata Object Description Schema http://www.loc.gov/standards/mods/) permet, par exemple, d'obtenir une granularité plus importante des noms et des liens avec les fichiers d'autorité, reflet de sa filiation avec la norme MARC :

name
    Subelements
        namePart
          Attribute: type (date, family, given, termsOfAddress)
        displayForm
        affiliation
        role
          roleTerm
            Attributes: type (code, text); authority
            (voir:www.loc.gov/marc/sourcecode/relator/relatorsource.html)
        description
       Attributes: ID; xlink; lang; xml:lang; script; transliteration
       type (enumerated: personal, corporate, conference)
          authority

(voir:www.loc.gov/marc/sourcecode/authorityfile/authorityfilesource.html)    

3.9.8    En utilisant METS, il serait possible d'inclure plus d'un lot (set) de métadonnées descriptives adaptées en vue d'objectifs différents, par exemple un lot Dublin Core (en conformité avec OAI-PMH (Open Archives Initiative Protocol for Metadata Harvesting)) et un lot MODS plus sophistiqué adapté  à d'autres initiatives, notamment l'échange de fiches codées avec des systèmes MARC. Cette possibilité d'inclure d'autres approches standards constitue l'un des avantages de METS.

3.9.9     DC, sous la gouvernance de la Dublin Core Metadata Initiative (DCMI) poursuit  son développement. D'une part, son efficacité pour la mise en réseau des ressources est renforcée par l'association accrue d'outils sémantiques du web tels que RDF (voir Nilsson et al, DCMI 2008) tandis que, d'autre part, il vise à accroître sa pertinence dans le domaine patrimonial en l'associant de manière formelle avec les recommandations RDA (Resource Description & Access http://www.collectionscanada.gc.ca/jsc/rda.html)  [nom de domaine remplacé par http://www.rda-jsc.org/rda.html en 2009]. Si RDA est considéré comme un successeur opportun des règles de catalogage anglo-américaines, ce développement particulier peut conduire à des implications dans les archives audiovisuelles qui font partie des bibliothèques nationales et universitaires. En ce qui concerne les archives de la radiodiffusion, d'autres développements basés sur DCMI ont atteint une certaine notoriété.  Au moment de rédiger ce document, l'EBU (European Broadcast Union) UER (Union Européenne de Radiodiffusion) complète le développement du jeu de métadonnées EBU Core Metadata Set, tiré de Dublin Core et compatible avec lui.

3.9.10 Le service d'archives peut souhaiter modifier (développer, adapter) l'ensemble des éléments de base (core). De tels ensembles modifiés s'appuyant sur un ou plusieurs schémas d'espace de nom (namespace) existant (MODS et/ou IEEE LOM aussi bien que DC par exemple) sont connus sous le nom de profils d'applications. Tous les éléments d'un profil d'application proviennent de l'extérieur, de schémas d'espaces de noms distincts. Si des programmeurs souhaitent créer de 'nouveaux' éléments non schématisés par ailleurs, par exemple lorsque des rôles de contributeurs d'instance ne sont pas disponibles dans le jeu MARC relators (agents non humains ou autres espèces, machines, environnements), ils doivent créer leur propres schémas d'espaces de noms, et prendre leur responsabilité en 'déclarant' et maintenant ce schéma.

3.9.11 Les profils d'application comprennent une liste d'espaces de noms qui assurent l'administration en même temps que les URL courants (de préférence PURL - URL permanents). Ceux-ci sont recopiés dans chaque instance de métadonnées. Il en résulte une liste de chacun des éléments de données comportant à la fois les valeurs permises et le style de contenu. Elles peuvent faire référence à des règles internes ou additionnelles et à des vocabulaires contrôlés, par exemple des thésaurus de noms et genres d'instruments, des fiches d'autorité de noms personnels et de sujets. Le profil spécifiera aussi les schémas obligatoires d'éléments particuliers telles les dates (AAAA-MM-JJ) et les coordonnées géographiques, de telles représentations standards de localisation et du temps pourront contribuer à l'affichage cartographique et temporel en tant que dispositif de récupération non-textuelle.

Nom ou Terme Titre
Term URI (Terme URI) http://purl.org/dc/elements/1.1/title
Label (Label) Titre
Defined by (Défini par) http://dublincore.org/documents/dcmi-terms/
Source Definition(Définition de la Source) Nom donné à une ressource
BLAPS-S Definition (Définition BLAPS-S) Titre de l'œuvre ou composante de l'œuvre
Source Comments (Commentaires sur la source) Typiquement, un titre est le nom par lequel la source est formellement connue
BLAPS-S Definition (Commentaires BLAPS-S) Si aucun titre n'est disponible il convient d'en donner un à partir de la ressource ou fourni [sans titre]. On suivra les pratiques de catalogage normales pour les titres d'enregistrement dans d'autres langues utilisant un raffinement 'Alternatif'. Pour les données issues du catalogue d'archives sonores, cela revient à donner l'un des domaines de titres suivants dans l'ordre hiérarchique tel que : Titre de l'œuvre (1), Titre de l'item (2), Titre de la collection (3), Titre de du produit (4), Espèces originales (5), Titre de radiodiffusion (6), Titre Séries éditées (7), séries non éditées (8)
Type of term (Type de terme) Elément
Refines (Raffinements)    
Refined by (Raffiné par) Alternative
Has encoding schemes (Schéma encodé par)  
Obligation (Obligation) Obligatoire
Occurrence (Occurence) Non répétable

Fig. 5 : Partie du profil d'application du DC de la British Library pour le son (BLAP-S) :

Espaces de noms utilisés dans ce profil d'application
Termes de métadonnées DCMI : http://dublincore.org/documents/dcmi-terms/
RDF http://www.w3.org/RDF/
Eléments MODS http://www.loc.gov/mods
Termes TEL http://www.theeuropeanlibrary.org/metadatahandbook/telterms.htm
Termes BL http://www.bl.uk/schemas/bibliographic/blterms
MARCREL http://www.loc.gov/loc.terms/relators/

3.9.12  En conséquence, le profil d'application s'incorpore ou s'appuie sur un dictionnaire de données (fichier définissant l'organisation élémentaire de la base de données jusqu'aux champs individuels et types de champs), ou bien sur plusieurs dictionnaires de données, ainsi la maintenance peut-elle être assurée par un seul centre d'archives ou de manière partagée avec une communauté d'archives. Le dictionnaire de données PREMIS (http://www.loc.gov/standards/premis/v3/premis-3-0-final.pdf, version 3 actuellement) se rapportant exclusivement à la conservation, est susceptible d'être utilisé de manière conséquente. Ses nombreux éléments sont dénommés 'Unités sémantiques'. Les métadonnées de conservation  fournissent des renseignements sur la provenance,  l'activité de conservation,  les caractéristiques techniques, et  facilitent la vérification de l'authenticité d'un objet numérique. Le PREMIS Working Group a publié son dictionnaire Data Dictionary for Preservation Metadata en Juin 2005, il recommande de l'utiliser dans tous les entrepôts de conservation quel que soit le type de matériau archivé et quelles que soient les stratégies de conservation employées.   

3.9.13  En définissant les profils d'application et, plus important, en les déclarant, les programmeurs peuvent partager l'information à propos de leurs schémas afin de collaborer, à grande échelle, à des tâches universelles telle que celle de la conservation à long terme.