BuBiBlog

Ce document reprend un travail de traduction émanant du groupe de travail Couperin sur les archives ouvertes GTAO.

Traduction, adapatation, d'après http://dublincore.org/documents/abstract-model/

Texte original sur fond sable.
Proposition de traduction et remarques  sur fond jaune, 9 juin

 

1. Introduction

Ce document présente un modèle abstrait pour les métadonnées Dublin Core. L'objectif premier de ce document est de spécifier les éléments et les artefacts utilisés par les métadonnées Dublin Core. Il décrit la nature des éléments utilisés et décrit la manière dont ces éléments sont combinés pour créer des structures d'information (de l'information structurée ?). Il fournit un modèle de données (d'information?) qui est indépendant de toute syntaxe d'encodage. Un tel modèle de données permet une meilleure compréhension des types de description que nous encodons et facilite la mise au point de meilleures traductions entre des syntaxes variées. Ce document vise premièrement les développeurs d'applications qui recourent aux métadonnées Dublin Core ; les personnes engagées dans la mise au point de nouvelles recommandations syntaxiques d'encodage pour les métadonnées Dublin Core ; et les personnes travaillant à la mise au point de profils d'application fondés sur les vocabulaires du DCMI ou sur d'autres vocabulaires qui sont compatibles. Le modèle abstrait du DCMI se fonde sur des travaux entrepris par le W3C au sujet de RDF.This document specifies an abstract model for Dublin Core metadata. The primary purpose of this document is to specify the components and constructs used in Dublin Core metadata. It defines the nature of the components used and describes how those components are combined to create information structures. It provides an information model which is independent of any particular encoding syntax. Such an information model allows us to gain a better understanding of the kinds of descriptions that we are encoding and facilitates the development of better mappings and cross-syntax translations.

This document is primarily aimed at the developers of software applications that support Dublin Core metadata, people involved in developing new syntax encoding guidelines for Dublin Core metadata and people developing metadata application profiles based on DCMI vocabularies or on other compatible vocabularies.

The DCMI Abstract Model builds on work undertaken by the World Wide Web Consortium (W3C) on the Resource Description Framework (RDF) [RDF, RDFS]. The use of concepts from RDF is summarized below in Section 5.

 

La plupart des relations entre entités et des attributs peuvent être assez aisément décrites en utilisant des intitulé de métadonnées déjà définis par le Dublin Core. Le Dublin Core peut même répondre au besoin de relations « horizontales » par le biais des intitulés dcterms:hasVersion et dcterms:hasFormat.

On considère souvent le schéma de métadonnées Dublin Core comme capable uniquement de décrire des objets peu complexes et isolés (une page web, un document, une image), mais le DCMI Abstract Model introduit la notion d’ensemble de description (description set), c’est à dire un groupe de descriptions liées entre elles. Ce modèle abstrait du Dublin Core permet de prendre en compte des métadonnées concernant des entités plus complexes. Il se veut indépendant de toute syntaxe.

Les éléments du DCAM, en version 2007/06/04 sont listés ci-dessous avec un essai de traduction en français, mais certains termes posent à l’évidence des difficultés de traduction.

Glossaire partiel :

• Instruction / déclaration (statement) : instanciation d’un couple propriété/valeur constitué d’une URI de propriété (une URI qui identifie une propriété, par exemple « dc:type ») ; de zéro ou un URI de valeur (URI qui identifie la valeur associée à la propriété, par exemple « http://purl.org/eprint/type/JounalArticle ») ; de zéro ou un URI de schéma d’encodage du vocabulaire (un URI qui identifie le schéma d’encodage du vocabulaire dont fait partie la valeur, par exemple « eprint:type ») ; de zéro ou plusieurs représentation de valeur d’une valeur.

L’instruction est l’élément-clé du DCAM. Elle est toujours constituée du couple propriété/valeur. Les exemples listés se lisent : pour décrire le type du document, on utilise l’élément Dublin Core Type. La valeur de ce champ sera formatée selon les régles édictées par l’EAP et baptisées eprint. La valeur de champ est renseignée par un URI.

En RDF, statement correspond à une phrase simple, ou déclaration, exprimées sous forme de triplets sujet - prédicat - objet :

 

- le sujet est une ressource,

- le prédicat est une propriété (càd un attribut ou une relation),

- l'objet est une donnée (literal) ou une autre ressource, physique, numérique ou conceptuelle (non literal).

• Propriété (property): aspect, caractéristique, attribut ou relation spécifique utilisé pour décrire des ressources. Synonyme du terme plus usité d’« élément » Dublin Core. Exemple : « dc:publisher » ou « eprint:version »

• Représentation enrichie : une séquence d’octets qui représentent la valeur. Par exemple : du texte à balises, une image, une vidéo ou une combinaison de ces éléments.

• Suite Chaîne de valeurs : chaîne de caractères, pouvant être associée à un URI de schéma d’encodage du vocabulaire ou une langue, représentant la valeur. Exemple : « Université Henri Poincaré ».

• URI : Uniform Resource Identifier.

• Valeur : entité physique ou conceptuelle associée à une propriété lorsqu’un couple propriété/valeur est requis pour décrire une ressource.

 

Le schéma ci-dessous est celui figurant sur la version révisée du DCAM en date du 06/04/2007.

Dans les versions précédentes, statement était relié directement à value URI, vocabulary encoding scheme URI et value representation.

Il s’agit d’un diagramme UML qui se lit de la manière suivante :

• une flèche se terminant par une flèche pleine se lit « est » ou « est un / une »

• les lignes commençant par un diamant se lisent « contient » ou « a un / une »

• le sens des autres flèches est explicité

2. DCMI Abstract Model

2.1 The DCMI Resource Model

The abstract model of the resources described by descriptions is as follows:

• Each described resource is described using one or more property-value pairs.

• Each property-value pair is made up of one property and one value.

• Each value is a resource - the physical, digital or conceptual entity or literal that is associated with a property when a property-value pair is used to describe a resource. Therefore, each value is either a literal value or a non-literal value:

  • A literal value is a value which is a literal.

  • A non-literal value is a value which is a physical, digital or conceptual entity.

• A literal is an entity which uses a Unicode string as a lexical form, together with an optional language tag or datatype, to denote a resource (i.e. "literal" as defined by RDF [RDF]).

Tentative de traduction (GH)
Le modèle abstrait des ressources décrites par ces descriptions, correspond à ce qui suit :
* Chaque ressource décrite est décrite en utilisant une ou plusieurs paires propriété-valeur.
* Chaque pair propriété-valeur est faite constituée d'une propriété et d'une valeur.
* Chaque valeur est une ressource, l'entité physique, numérique, conceptuelle ou littérale qui est associée avec une propriété quand une pair propriété-valeur est utilisée 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, autrement dit une chaîne de caractères.
* Une valeur non littérale est une valeur qui est une entité physique, numérique ou conceptuelle.
* Un littéral est une entité qui prend la forme d'une chaîne de caractères Unicode, liée de façon optionnelle à un langage d'indexation à une étiquette de langue ou à un type de données, pour caractériser une ressource.
Voir la définition de "literal" par RDF : http://www.w3.org/TR/rdf-primer/#typedliterals

 

NB : la "resource" est utilisée sur les autres schémas.


Notes GH : compléments sur RDF, d'après Gautier, voir http://lespetitescases.net/rdf-pour-les-nuls
"En RDF, ce sont les assertions, appelés aussi déclaration dans la norme du W3C, qui jouent le rôle des phrase et qui possèdent une grammaire très simple : Sujet Prédicat Objet. Ces déclarations peuvent être représentées sous la forme d'un graphe. Par conséquent, le RDF est un modèle de description de données sous forme de graphes. Donc premier élément important : des phrases simples dites déclarations (statement dans la langue de Shakespeare)."
Deux types d'objets en RDF utilisent les URIs :

1.     Une ressource qui correspond à toutes choses décrites par une expression RDF ;
2.     une propriété qui est un aspect, une caractéristique, un attribut, ou une relation spécifique utilisée pour décrire une ressource, en clair le prédicat

Exemple : « http://lespetitescases.net (ressource/sujet) http://purl.org/dc/elements/1.1/title (propriété/prédicat) 'Les petites cases'(objet) » est une déclaration RDF qui se traduit en langage naturel par : « le site Web dont l'adresse est http://lespetitescases.net a pour titre les Petites cases ».

Comme on le voit à travers cet exemple, il est possible d'indiquer l'objet d'une déclaration par une simple chaîne de caractère. On parle alors de litéral. Ce genre de propriété est appelé propriété de type de données. Mais, il est aussi possible de faire référence en objet à une ressource, on parle alors de propriété d'objet.

2.2 The DCMI Description Set Model

The abstract model of DC metadata description sets is as follows:

• A description set is a set of one or more descriptions, each of which describes a single resource.

• A description is made up of one or more statements (about one, and only one, resource) and zero or one described resource URI (a URI that identifies the described resource).

• Each statement instantiates a property-value pair, and is made up of a property URI (a URI that identifies a property) and a value surrogate.

• A value surrogate is either a literal value surrogate or a non-literal value surrogate:

  • A literal value surrogate is a value surrogate for a literal value, and is made up of exactly one value string. The value string is a literal which encodes the literal value.

  • A non-literal value surrogate is a value surrogate for a non-literal value, and is made up of zero or one value URI (a URI that identifies the non-literal value associated with the property), zero or one vocabulary encoding scheme URI (a URI that identifies the vocabulary encoding scheme of which the non-literal value is a member), and zero or more value strings. Each value string is a literal which represents the non-literal value.

• A value string is either a plain value string or a typed value string

  • A plain value string may have an associated value string language that is an ISO language tag (for example en-GB). Plain value strings are intended to be human-readable.

  • A typed value string has an associated syntax encoding scheme URI that identifies a syntax encoding scheme.

1. Vue d'ensemble du schéma

• Un ensemble de descriptions (description set) est constitué d’une ou de plusieurs descriptions

• Une description est constituée de :

• zéro ou un URI de ressource (resource URI) et

• une ou plusieurs instructions (statement)

• Une instruction (statement) est constitué de

• un seul URI de propriété (property URI)

• zéro ou une références à une valeur (value) sous la forme d’un URI de valeur (value URI)

• zéro ou plusieurs représentations d’une valeur, chacune sous la forme d’une représentation de valeur (value representation)

• zéro ou un URI de schéma d’encodage du vocabulaire (vocabulary encoding scheme URI)

• Une représentation de valeur est soit

• une suite de valeurs (value string)

• une représentation enrichie (rich representation)

• Une suite de valeurs peut être associée à une langue de suite de valeurs (value string language)

• Une suite de valeurs peut être associée à un URI de schéma d’encodage de la syntaxe (syntax encoding scheme URI)

• Une valeur peut être l’objet d’une description liée (related description)

2.3 The DCMI Vocabulary Model

The abstract model of the vocabularies used in DC metadata descriptions is as follows:

• A vocabulary is a set of one or more terms. Each term is a member of one or more vocabularies.

• A term is a property (element), class, vocabulary encoding scheme, or syntax encoding scheme.

• Each property may be related to one or more classes by a has domain relationship. Where it is stated that a property has such a relationship with a class and the property is part of a property/value pair, it follows that the described resource is an instance of that class.

• Each property may be related to one or more classes by a has range relationship. Where it is stated that a property has such a relationship with a class and the property is part of a property/value pair, it follows that the value is an instance of that class.

• Each resource may be an instance of one or more classes.

• Each resource may be a member of one or more vocabulary encoding schemes.

• Each class may be related to one or more other classes by a sub-class of relationship (where the two classes are defined such that all resources that are instances of the sub-class are also instances of the related class).

• Each property may be related to one or more other properties by a sub-property of relationship. Where it is stated that such a relationship exists, the two properties are defined such that whenever the sub-property is part of a property/value pair describing a resource, it follows that the resource is also described using a second property/value pair made up of the property and the value.

• Each syntax encoding scheme is a class (of literals).

Note that the word "vocabulary" is used here to refer specifically to a set of terms, a set in which the members are properties (elements), classes, vocabulary encoding schemes, and/or syntax encoding schemes.

 

 

Traduction littérale

Explicitations