Original | Traduction |
---|---|
|
|
Auteur : | Andy Powell Eduserv Foundation, UK |
---|---|
Auteur : | Mikael Nilsson KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden |
Auteur : | Ambjörn Naeve KMR Group, CID, NADA, KTH (Royal Institute of Technology), Sweden |
Auteur : | Pete Johnston Eduserv Foundation, UK |
Auteur : | Thomas Baker DCMI |
Date de publication : | 2007-06-04 |
Identificateur : | http://dublincore.org/documents/2007/06/04/abstract-model/ |
Remplace : | http://dublincore.org/documents/2005/03/07/abstract-model/ |
Remplace : | http://dublincore.org/documents/2007/04/02/abstract-model/ |
Est remplacé par : | Sans objet |
Dernière version : | http://dublincore.org/documents/abstract-model/ |
Statut du document : | Ceci est une recommandation du DCMI (N.d.T. Ce document-ci en est une traduction.) |
Description du document : | Ce document décrit un modèle abstrait des métadonnées Dublin Core. |
Ce document spécifie un modèle abstrait des métadonnées Dublin Core. Le but premier de ce document est de spécifier les composants et constructions utilisés dans les métadonnées Dublin Core. Il définit la nature des composants employés et décrit comment les combiner pour créer des structures d'information. Il fournit un modèle d'information qui est indépendant d'une syntaxe de codage particulière. Un tel modèle d'information permet d'avoir une meilleure compréhension des types des descriptions codées et facilite le développement de meilleures associations et traductions entre les syntaxes.
Ce document s'adresse principalement aux développeurs d'applications logicielles qui sont compatibles avec les métadonnées Dublin Core, aux personnes impliquées dans le développement de nouvelles directives de codage de syntaxe pour les métadonnées Dublin Core, et aux personnes développant des profils d'application fondés sur les vocabulaires DCMI ou d'autres vocabulaires compatibles.
Le modèle abstrait DCMI repose sur les travaux entrepris par le World Wide Web Consortium (W3C) sur le cadre de description de ressource RDF (Resource Description Framework) [RDF, RDFS]. L'utilisation des concepts issus de RDF est résumée ci-dessous à la section 5.
Le modèle abstrait DCMI est représenté ici à l'aide de diagrammes de classes UML [UML]. Les lecteurs non familiarisés avec les diagrammes de classes UML devraient noter que les traits finissant par une flèche fermée se lisent « est » ou « est un » (par exemple, « une valeur est une ressource »), et que les lignes commençant par un losange se lisent « contient » ou « a un » (par exemple, « une déclaration contient une adresse URI de propriété »). Les autres relations sont étiquetées de façon appropriée. Dans ce document, les mots et expressions en italiques sont définis à la section 7 — Terminologie.
Le modèle abstrait des ressources décrites par des descriptions est le suivant :
Chaque ressource décrite l'est par un ou plusieurs couples propriété-valeur.
Chaque couple propriété-valeur se compose d'une propriété et d'une valeur.
Chaque valeur est une ressource — l'entité physique, numérique ou conceptuelle ou le littéral associé(e) à une propriété lorsqu'un couple propriété-valeur est utilisé pour décrire une ressource. Par conséquent, chaque valeur est soit une valeur littérale, soit une valeur non littérale :
Une valeur littérale est une valeur qui est un littéral.
Une valeur non littérale est une valeur qui est une entité physique, numérique ou conceptuelle.
Un littéral est une entité qui utilise une chaîne Unicode comme forme lexicale, avec en option une étiquette de langue ou un type de données, pour indiquer une ressource (c'est-à-dire un « littéral » tel que défini par RDF [RDF]).
Figure 1 — Le modèle de ressource DCMI
Le modèle abstrait des ensembles de description de métadonnées DC (Dublin Core) est le suivant :
Un ensemble de description contient une ou plusieurs descriptions, chacune décrivant une seule ressource.
Une description se compose d'une ou plusieurs déclarations (à propos d'une seule ressource) et zéro ou une adresse URI de ressource décrite (une adresse URI qui identifie la ressource décrite).
Chaque déclaration instancie un couple propriété-valeur, et se compose d'une adresse URI de propriété (une adresse URI qui identifie une propriété) et d'un substitut de valeur.
Un substitut de valeur est soit un substitut de valeur littérale, soit un substitut de valeur non littérale :
Un substitut de valeur littérale est un substitut de valeur d'une valeur littérale, et se compose exactement d'une seule chaîne de valeur. La chaîne de valeur est un littéral qui code la valeur littérale.
Un substitut de valeur non littérale est un substitut de valeur d'une valeur non littérale, et se compose de zéro ou une adresse URI de valeur (une adresse URI qui identifie la valeur non littérale associée à la propriété), de zéro ou une adresse URI de schéma de codage de vocabulaire (une adresse URI qui identifie le schéma de codage de vocabulaire auquel appartient la valeur non littérale) et de zéro ou plus chaînes de valeur. Chaque chaîne de valeur est un littéral qui représente la valeur non littérale.
Une chaîne de valeur est soit une chaîne de valeur ordinaire, soit une chaîne de valeur typée :
Une chaîne de valeur ordinaire peut se voir associer une langue de chaîne de valeur qui est une étiquette de langue ISO (par exemple, en-GB). Les chaînes de valeur ordinaires sont destinée à être lues par des humains.
Une chaîne de valeur typée se voit associer une adresse URI de schéma de codage de syntaxe qui identifie un schéma de codage de syntaxe.
Figure 2 — Le modèle d'ensemble de description DCMI
Le modèle abstrait des vocabulaires utilisés dans les descriptions de métadonnées DC est le suivant :
Un vocabulaire est un jeu d'un ou plusieurs termes. Chaque terme est membre d'un ou plusieurs vocabulaires.
Un terme est une propriété (élément), une classe, un schéma de codage de vocabulaire ou un schéma de codage de syntaxe.
Chaque propriété peut être liée à une ou plusieurs classes par une relation a pour domaine (has domain). Là où une propriété est déclarée avoir une telle relation avec une classe et que la propriété fait partie d'un couple propriété-valeur, il s'ensuit que la ressource décrite est une instance de cette classe.
Chaque propriété peut être liée à une ou plusieurs classes par une relation a pour image (has range). Là où une propriété est déclarée avoir une telle relation avec une classe et que la propriété fait partie d'un couple propriété-valeur, il s'ensuit que la valeur est une instance de cette classe.
Chaque ressource peut être une instance d'une ou plusieurs classes.
Chaque ressource peut être un membre d'un ou plusieurs schémas de codage de vocabulaire.
Chaque classe peut être liée à une ou plusieurs autres classes par une relation sous-classe de (dans laquelle les deux classes sont définies de telle sorte que toutes les ressources qui sont des instances de la sous-classe sont aussi des instances de la classe liée).
Chaque propriété peut être liée à une ou plusieurs autres propriétés par une relation sous-propriété de. Là où une telle relation est déclarée exister, les deux propriétés sont définies de telle sorte que si la sous-propriété fait partie d'un couple propriété-valeur décrivant une ressource, il s'ensuit que la ressource est également décrite avec un deuxième couple propriété-valeur composé de la propriété et de la valeur.
Chaque schéma de codage de syntaxe est une classe (de littéraux).
Notez que le terme « vocabulaire » est employé ici pour désigner spécifiquement un ensemble de termes, un ensemble dans lequel les membres sont des propriétés (éléments), des classes, des schémas de codage de vocabulaire ou des schémas de codage de syntaxe.
Figure 3 — Le modèle de vocabulaire DCMI
Plusieurs choses sont remarquables à propos du modèle :
Chaque valeur non littérale peut être la ressource décrite dans une description séparée au sein du même ensemble de description — par exemple, une description séparée peut fournir des métadonnées à propos du créateur de la ressource décrite. Une valeur littérale ne peut pas être la ressource décrite dans une description séparée.
Le modèle d'ensemble de description DCMI n'offre pas de mécanisme explicite pour indiquer les classes de la ressource décrite. Les classes de la ressource décrite peuvent être soit indiquées explicitement à l'aide d'une ou plusieurs déclarations dans la description, soit être inférées des domaines des propriétés utilisées dans la description.
Le modèle d'ensemble de description DCMI indique la distinction entre les valeurs littérales et les valeurs non littérales par la présence dans une déclaration d'un substitut de valeur littérale ou d'un substitut de valeur non littérale. Pour une valeur non littérale, le modèle d'ensemble de description DCMI ne fournit pas de mécanisme explicite afin de préciser encore les classes de la valeur. Les classes d'une valeur non littérale donnée peuvent être soit indiquées explicitement à l'aide d'une ou plusieurs déclarations dans une description séparée à propos de cette valeur, soit être inférées de la range des propriété. Pour une valeur littérale, les classes de la valeur peuvent être soit indiquées explicitement en utilisant un schéma de codage de syntaxe de la chaîne de valeur, soit être inférées de l'image (range) de la propriété.
Le contenu XML dans une chaîne de valeur est indiqué en utilisant une chaîne de valeur typée avec une adresse URI de schéma de codage de syntaxe de http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral.
Le modèle abstrait présenté au-dessus indique que chaque description de métadonnée DC ne décrit qu'une seule ressource. C'est ce qu'on appelle couramment le principe un-pour-un (one-to-one principle).
Quoiqu'il en soit, les applications de métadonnées du monde réel tendent à se fonder sur des ensembles librement groupés de descriptions (où les ressources décrites sont typiquement liées d'une certaine manière), appelés ici ensembles de description. Par exemple, un ensemble de description pourrait comprendre à la fois les descriptions d'une peinture et de l'artiste. En outre, il arrive souvent qu'un ensemble de description contienne aussi une description à propos de l'ensemble de description lui-même (parfois appelée « métadonnées d'administration » ou « méta-métadonnées »).
Les ensembles de description sont instanciés, pour les besoins d'échange entre les applications logicielles, sous la forme
d'enregistrements de métadonnées, conformément à l'une des directives de codage DCMI (par exemple, balises meta
XHTML,
XML et RDF/XML), cf. [DCMI-ENCODINGS].
Une valeur de métadonnée DC est l'entité physique, numérique ou conceptuelle, ou le littéral, associé(e)
à une propriété lorsqu'un couple propriété-valeur est utilisé pour décrire une ressource. Par exemple,
une valeur associée à la propriété Dublin Core Creator
est une personne, une organisation ou un service
— une entité physique. Une valeur associée à la propriété Dublin Core Date
est un point (ou un intervalle)
dans le temps — une entité conceptuelle. Une valeur associée à la propriété Dublin Core Coverage
est une région géographique ou un pays — une entité physique. Une valeur associée à la propriété Dublin Core Subject
est un concept (une entité conceptuelle) ou un objet physique ou une personne (une entité physique). Une valeur associée à la
propriété FOAF name
est un littéral.
Chacune de ces entités est une ressource.
Notez que cette recommandation ne définit pas explicitement de sémantique formelle pour le modèle abstrait DCMI. La raison est que la sémantique formelle peut être décrite par référence aux sémantiques RDF et RDF Schema, comme défini dans [RDFMT]. Le tableau suivant donne l'équivalence entre quelques notions du modèle abstrait DCMI et les notions RDF correspondantes :
Modèle abstrait DCMI | RDF/RDFS |
---|---|
ressource | Classe : http://www.w3.org/2000/01/rdf-schema#Resource |
propriété ou élément | Classe : http://www.w3.org/1999/02/22-rdf-syntax-ns#Property |
classe | Classe : http://www.w3.org/2000/01/rdf-schema#Class |
schéma de codage de syntaxe | Classe : http://www.w3.org/2000/01/rdf-schema#Datatype |
relation a pour domaine (has domain) | Propriété : http://www.w3.org/2000/01/rdf-schema#domain |
relation a pour image (has range) | Propriété : http://www.w3.org/2000/01/rdf-schema#range |
relation sous-propriété de | Propriété : http://www.w3.org/2000/01/rdf-schema#subPropertyOf |
relation sous-classe de | Propriété : http://www.w3.org/2000/01/rdf-schema#subClassOf |
chaîne de valeur ordinaire | Littéral ordinaire. Cf. http://www.w3.org/TR/rdf-concepts/#dfn-plain-literal |
chaîne de valeur typée | Littéral typé. Cf. http://www.w3.org/TR/rdf-concepts/#dfn-typed-literal |
Conjointement à la recommandation du DCMI intitulée L'expression du Dublin Core avec le cadre de description de ressource (RDF) [DCRDF], ces équivalences forment la base de la sémantique formelle du modèle abstrait DCMI. Toutefois, le détail d'une telle sémantique n'est pas traité dans cette recommandation.
Les directives de codage particulières (balises meta
HTML, XML, RDF/XML, etc.)
[DCMI-ENCODINGS] n'ont pas besoin de coder tous les aspects du modèle abstrait
décrit au-dessus. Par contre, elles devraient citer le modèle abstrait DCMI et indiquer quelles parties du modèle
sont codées et lesquelles ne le sont pas.
Les directives de codage devraient indiquer comment une valeur non littérale peut être traitée comme une ressource décrite dans une description séparée dans les cas où un substitut de valeur non littérale n'inclut pas d'adresse URI de valeur.
Ce document emploie les termes suivants :
meta
XHTML, XML et RDF/XML).Le modèle sous-jacent des métadonnées Dublin Core a évolué depuis les premiers formalismes proposés à la fin des années 1990. Le tableau suivant présente les équivalences terminologiques approximatives entre les versions antérieures des principes grammaticaux DCMI [DCMI-GRAM-PRIN] et le modèle abstrait DCMI courant.
Principes grammaticaux DCMI | Modèle abstrait DCMI |
---|---|
terme de vocabulaire | ressource |
élément | propriété ou élément |
affinement d'élément | propriété avec relation sous-propriété de |
schéma de codage | schéma de codage de syntaxe ou schéma de codage de vocabulaire |
schéma de codage de syntaxe | schéma de codage de syntaxe |
qualificatif | propriété avec relation sous-propriété de, schéma de codage de syntaxe, ou schéma de codage de vocabulaire |
schéma de codage de vocabulaire | schéma de codage de vocabulaire |
Merci à Dan Brickley, Rachel Heery, Alistair Miles, Sarah Pulis, aux membres du Comité d'utilisation DC (DC Usage Board) et aux membres de la communauté d'architecture DCMI (DCMI Architecture Community) pour leurs commentaires sur les versions précécentes de ce document.
Errata 2007-09-24 : Corrigé une coquille — supprimé le « is » en trop dans deux apparitions de « which is is ».
Copyright © 1995-2008 DCMI. All Rights Reserved.