Initiation aux métadonnées - informations fournies par Soft Experience : www.softexperience.com - Présentation de techniques fondamentales relatives aux métadonnées (Dublin Core, RDF, XMP), plus particulièrement celles qui sont appliquées aux images (IPTC, EXIF) et à la presse (PRISM, NewsML, NITF) : http://peccatte.karefil.com/software/Metadata.htm

Métadonnées: une initiation
Dublin Core, IPTC, EXIF, RDF, XMP, etc.
 
dernière mise à jour: 20 mars 2005
 

1. Une carte n'est pas le territoire. (Les mots ne sont pas les choses qu'ils représentent.)
2. Une carte ne couvre pas tout le territoire. (Les mots ne peuvent pas couvrir tout ce qu'ils représentent.)
3. Une carte est auto-réflexive. (Dans le langage, nous pouvons parler à propos du langage.)

De Bouche à Oreille : Signalez cet article sur les meta données à vos collègues et amis

Alfred Korzybski
Une carte n'est pas le territoire
Prolégomènes aux systèmes non-aristotéliciens et à la sémantique générale
1933 à 1950. Trad. fr. Éditions de l'Éclat, 1998, p. 64

par Patrick Peccatte
Soft Experience

Cette page a pour but d'orienter le lecteur abordant le domaine des métadonnées dans le dédale des concepts, des recommandations et des initiatives qui ont trait à ce sujet. Nous y présentons plusieurs techniques fondamentales relatives aux métadonnées (Dublin Core, RDF, XMP), en développant plus particulièrement celles qui sont appliquées aux images (IPTC et IPTC Core, EXIF, DIG35, JPX) et à la presse (PRISM, NewsML, NITF).

Contactez Soft Experience pour vos formations:

Consultez aussi

  • Le logiciel Kalimages qui permet d'annoter des photos jpeg et d'insérer ces informations dans une base de données intégrée pour effectuer rapidement des recherches par mots clés, descriptions, titre, auteur ou tout autre champ IPTC standard ou personnalisé.
   Building and Managing the Meta Data Repository: A Full Lifecycle GuideBuilding and Managing the Meta Data Repository: A Full Lifecycle Guide de Wiley et David Marco

Logiciel CrossIPTC

Sommaire

Les lecteurs exclusivement intéressés par les métadonnées relatives aux images peuvent lire uniquement les sections suivantes:
Métadonnées , Métadonnées informatiques , Où sont les métadonnées ? , IPTC , EXIF , Les propriétés des images selon Microsoft , JPEG2000 et JPX, IPTC Core

Une connaissance minimale de XML est requise pour les sections concernant RDF , PRISM , NewsML , NITF , DIG35 , JPEG2000 et JPX , XMP et IPTC Core
[lire par exemple l'excellente introduction à XML sur Comment ça marche ? ]

 

À lire également

Sur le site de Soft Experience :

Sur d'autres sites, traduits par Soft Experience :

Les métadonnées

Une métadonnée est littéralement une donnée sur une donnée. Plus précisément, c'est un ensemble structuré d'informations décrivant une ressource quelconque.
Les ressources décrites par des métadonnées ne sont pas nécessairement sous forme digitale: un catalogue de bibliothèque ou de musée contient aussi des métadonnées décrivant les ressources que sont les ouvrages de la bibliothèque ou les objets du musée.
Une métadonnée peut être utilisée à des fins diverses:

Les métadonnées sont en général constituées de mots-clés ou de texte libre. Ces informations peuvent être évidentes (l'auteur, la date de publication, l'éditeur d'un livre), ou plus complexes et moins aisément définies: les avis d'un collectif de lecture d'un article, par exemple, nécessitent une structure de métadonnées évoluée capable d'annoter des portions de l'article, et cela, de façon multiple.

Les métadonnées sont particulièrement importantes pour les ressources visuelles qui, sans elles, peuvent demeurer pratiquement inexploitables et impossibles à retrouver. Les utilisateurs dépendent en effet des informations ajoutées aux images ou vidéos pour effectuer des recherches pertinentes et précises. Les métadonnées aident alors les utilisateurs à découvrir l'existence de ressources et la nature de ce qu'ils recherchent. Les informations ajoutées à une ressource servent aussi à évaluer la ressource, à porter un jugement sur celle-ci, et à la comparer à d'autres ressources.

Les métadonnées ne sont pas seulement importantes pour l'utilisateur final. Des métadonnées d'ordre technique et administrative (comme l'appartenance à une collection, les informations de copyright, les informations sur l'acquisition, le format de fichier, la résolution, etc.) permettent de gérer, maintenir et préserver des collections digitales.

Les métadonnées sont utilisées dans les systèmes de gestion de contenu [CMS: Content Management Systems] pour éditer, gérer, rechercher, réutiliser, diffuser, publier de multiples contenus (textes, images, vidéo, etc.).

Pour en savoir plus

Les métadonnées "métiers" et la nécessité de standards

Les ressources sont en général partagées par différentes institutions et collectivités. Ainsi, les bibliothèques pratiquent depuis longtemps le prêt interbibliothèque et le catalogage partagé des ouvrages. Or, dans une grande bibliothèque, un ouvrage mal catalogué peut être considéré comme un ouvrage perdu. C'est encore plus vrai pour un réseau de bibliothèques. Les métadonnées attribuées sauvagement aux ressources, sans règles établies et sans principes directeurs, ne seront pas interopérables entre différentes collectivités. Ces métadonnées - et donc les ressources qu'elles décrivent - resteront sous-exploitées ou même totalement inexploitées. Il est donc absolument nécessaire d'adopter des standards de description des ressources à l'aide des métadonnées.

Par ailleurs, de nombreuses communautés s'intéressent aux métadonnées: bibliothécaires, documentalistes, archivistes, conservateurs de musées, etc. Les ressources décrites sont très variées: monographies, publications en série, articles, archives, pièces de musée, images, séquences audio ou vidéo, etc. On ne décrit pas toutes ces ressources de la même façon. Les standards concernant les métadonnées sont donc très nombreux et orientés "métiers". À titre d'exemple, on peut citer:

Les métadonnées informatiques

Les objets informatiques courants contiennent de nombreuses métadonnées implicites ou explicites. En voici quelques exemples:

On le voit, les métadonnées informatiques sont organisées par centres d'intérêts distincts ou par éditeurs de logiciels et de systèmes. Il n'existe hélas aucune interopérabilité entre ces types de métadonnées. Ainsi, un fichier image évoluant dans un environnement mixte Macintosh/Windows pourra être doté de six "Descriptions" totalement différentes: un champ IPTC Caption/Abstract, un champ EXIF ImageDescription, un ou plusieurs champs XMP Description ou Subject, un champ Commentaires Windows 2000, un champ Commentaires Windows XP (v. infra ), et un Commentaire Macintosh (qui peuvent tous être attribués depuis ces plate-formes respectives) !

Dublin Core Metadata Initiative [DCMI]

La prolifération de besoins "métiers" variés ainsi que la diversité des structures et des nomenclatures de métadonnées informatiques ont conduit à la recherche d'un standard minimal.

Le NCSA (National Center for Supercomputing Applications) et l' OCLC (Online Computer Library Center) - réunis en 1995 au siège de l'OCLC à Dublin, Ohio - ont défini un ensemble de métadonnées communes à diverses communautés: le Dublin Core Metadata Initiative (DCMI), abrégé souvent en Dublin Core ou en DC.

Le Dublin Core est un ensemble de 15 éléments de métadonnées ayant trait:

Nom de l'élément Identifiant Définition
titre Title Le nom donné à la ressource
créateur Creator L'entité principalement responsable de la création du contenu de la ressource
sujet et mots-clefs Subject Le sujet du contenu de la ressource
description Description Une description du contenu de la ressource
éditeur Publisher L'entité responsable de la diffusion de la ressource, dans sa forme actuelle, tels, un département universitaire, une entreprise.
contributeur Contributor Une entité qui a contribué à la création du contenu de la ressource
date Date Une date associée avec un événement dans le cycle de vie de la ressource
type Type La nature ou le genre du contenu de la ressource
format Format La matérialisation physique ou digitale de la ressource
identifiant Identifier Une référence non ambiguë à la ressource dans un contexte donné
source Source Une référence à une ressource à partir de laquelle la ressource actuelle a été dérivée
langue Language La langue du contenu intellectuel de la ressource
relation Relation Une référence à une autre ressource qui a un rapport avec cette ressource
couverture Coverage La portée ou la couverture spatio-temporelle de la ressource
droits Rights Information sur les droits sur et au sujet de la ressource

 cf. Éléments de métadonnées du Dublin Core , Version 1.1: Description de Référence, trad. fr. par Anne-Marie Vercoustre de l'original en anglais.

Le Dublin Core ayant été conçu comme un référentiel commun à diverses communautés intéressées par les métadonnées, sa terminologie peut apparaître un peu déroutante dans certains contextes. Le Dublin Core parle ainsi de Créateur (Creator) d'une ressource et non pas d'Auteur, plus habituel dans le domaine de l'écrit; Author n'existe pas en Dublin Core.

Une version plus évoluée du Dublin Core autorise l'usage de qualificateurs; par exemple, l'élément Description peut être raffiné à l'aide des qualificateurs tableOfContents et abstract.

Les éléments du Dublin Core peuvent être encodés dans des balises HTML <meta>.
Exemple: la page que vous êtes en train de lire est ainsi codée:

<meta name="DC.Language" content="fr">
<meta name="DC.Title" content="Métadonnées: une initiation">
<meta name="DC.Title.Subtitle" content="Dublin Core, IPTC, EXIF, RDF, XMP">
<meta name="DC.Subject.Keywords" content="Métadonnées; Metadata; Dublin Core; DCMI; IPTC; EXIF; RDF; PRISM; NewsML; NITF; XMP">
<meta name="DC.Creator" content="Patrick Peccatte - Soft Experience">

Pour faire référence à un élément du Dublin Core, l'OCLC préconise d'utiliser le PURL (Persistent Uniform Resource Locator) défini pour le Dublin Core. Un PURL est en fait un URL réputé persistant et redirigé vers un service de résolution de noms. Ce système garantit une meilleure stabilité référentielle que les URL classiques. Ainsi, l'élément Creator du Dublin Core selon la version 1.1, fait référence univoquement à http://purl.org/dc/elements/1.1/creator , redirigé par le système PURL vers http://dublincore.org/2003/03/24/dces#creator (il pourrait être redirigé vers un autre URL dans le futur).

Il est important de se souvenir que le Dublin Core (ainsi que d'autres schémas de métadonnées non mentionnés ici) a été proposé pour faciliter la recherche de ressources peu complexes. Le Dublic Core ne prétend pas répondre aux besoins et à la complexité de tous les métiers. C'est pourquoi, dans le domaine de l'image par exemple, des champs additionnels ou des schémas complémentaires sont nécessaires pour décrire correctement des structures spécifiques telles que: la gestion administrative, le workflow, les droits associés, etc. Le Dublin Core est un point de départ, mais il n'est pas suffisant. Dans la plupart des besoins professionnels, il doit être complété par d'autres schémas de métadonnées. Nous examinerons cela plus en détail à propos des formats XMP et IPTC Core.

Où sont les métadonnées ?

Métadonnées externes aux ressources - Bases de données

Pour les ressources non digitales (livres, objets de musées), les métadonnées sont évidemment externes aux ressources (sous la forme de données informatiques, de fiches dans une boîte à chaussure, etc.).
Dans la plupart des systèmes informatisés, les métadonnées sont stockées dans une base de données spécifique. C'est la technologie utilisée habituellement dans les systèmes documentaires pour retrouver les ressources recherchées au sein d'un vaste ensemble de ressources et avec la souplesse nécessaire (recherches sur plusieurs critères, troncatures, speller, etc.).

Cependant, si la ressource est elle-même sous forme digitale (une image JPEG par exemple) et que vous utilisiez cette ressource en dehors de la base de données qui la référence, vous perdez les métadonnées qui lui sont associées. Les métadonnées demeurent dans la base et vous devez les exporter séparément et les associer à nouveau avec la ressource.

Métadonnées internes aux ressources digitales - Balisage des ressources - le cas des images

Nous avons déjà cité plusieurs exemples de métadonnées de type interne à propos des métadonnées informatiques .

Le balisage (tagging) d'une ressource informatique consiste à inclure un ou plusieurs jeux de métadonnées dans le fichier de la ressource. Les métadonnées sont alors "embarquées" dans les données. Cette technique est utilisée notamment pour les images ( IPTC , EXIF ), les fichiers sons MP3 (champs ID3 ), les objets multimédias ( MPEG-7 ), etc.

L'image ainsi balisée transporte avec elle ses propres métadonnées lorsqu'elle est téléchargée, copiée, répliquée, etc.
En fait, comme nous l'avons vu, toute image numérique possède au moins une métadonnée incorporée de type informatique: son nom de fichier. Mais le balisage permet bien entendu d'inclure dans l'image une variété plus grande et mieux structurée de métadonnées: le titre, les mots-clés, les informations de copyright, l'auteur, etc.

Le balisage des images présente toutefois deux limitations majeures:

Les métadonnées IPTC

L' IPTC (International Press and Telecommunications Council) est une organisation internationale créée en 1965 pour développer et promouvoir des standards d'échange de données à destination de la presse. L'IPTC a défini par exemple le format de transmission des documents (textes, images, sons, multimédia) émis par les agences de presse. Ce format est en cours de renouvellement (cf. NewsML ).

En association avec la NAA (Newspaper Association of America), l'IPTC a défini un modèle global de données appelé IPTC-NAA Information Interchange Model (la version 4 date d'octobre 1997; elle est connue sous le nom IIMV4. La révision 4.1 date de Juillet 1999).
Voir aussi l'article IPTC sur le site Controlled Vocabulary .

Le sous-ensemble de ce modèle appelé Application record N° 2 a servi de base à la société Adobe pour définir dans son logiciel Photoshop les informations associées à une image. C'est ce sous-ensemble qui est communément appelé métadonnées (ou champs ou informations ou en-têtes [headers]) IPTC.
Les informations IPTC/IIM sont à présent considérées par l'IPTC comme un legacy standard qui sera progressivement remplacé par le nouveau schéma de métadonnées IPTC Core basé sur XMP.

Ces informations IPTC/IIM sont constituées de 33 métadonnées de type interne, c'est-à-dire stockées à l'intérieur des fichiers images JPEG, TIFF ou PSD [Photoshop] (cf. Où sont les métadonnées ? )

DataSet (numéro du champ) Nom du champ Description Traduction et Commentaire
5 Object Name non répétable, 64 caractères maximum Nom de l'objet
7 Edit Status non répétable, 64 caractères maximum Statut éditorial
10 Urgency non répétable, un seul caractère Priorité
15 Category non répétable, 3 caractères maximum Catégorie - ce champ est obsolète dans IIMV4
20 Supplemental Category répétable, 32 caractères maximum Catégorie supplémentaire - ce champ est obsolète dans IIMV4
22 Fixture Identifier non répétable, 32 caractères maximum Identificateur
25 Keywords répétable, 64 caractères maximum Mots-clés
30 Release Date non répétable, 8 caractères, forme AAAAMMJJ Date de disponibilité
35 Release Time non répétable, 11 caractères, forme HHMMSS±HHMM Heure de disponibilité, suit la norme ISO8601.
Ex. 090000-0500 = disponible à 9h00, temps de New York (5 heures avant TU)
40 Special Instructions non répétable, 256 caractères maximum Instructions spéciales
45 Reference service répétable, 10 caractères maximum. Optionnel Service de référence (doit être suivi des champs 47 et 50)
47 Reference Date obligatoire si le champ 45 est présent, 8 caractères, forme AAAAMMJJ Date de référence
50 Reference Number obligatoire si le champ 45 est présent, 10 caractères maximum Numéro de référence
55 Date Created non répétable, 8 caractères, forme AAAAMMJJ Date de création de l'objet
60 Time Created non répétable, 11 caractères, forme HHMMSS±HHMM Heure de création de l'objet, suit la norme ISO8601.
65 Originating Program non répétable, 32 caractères maximum Programme ayant créé l'objet
70 Program version non répétable, 10 caractères maximum Version du programme ayant créé l'objet
75 Object cycle non répétable, un seul caractère Cycle de l'objet
'a' = le matin, 'b' = l'après-midi, 'c' = matin et après-midi
80 By-line répétable, 32 caractères maximum Créateur de l'objet (auteur): nom du rédacteur, du photographe, etc.
85 By-line Title répétable, 32 caractères maximum Titre du créateur ou des créateurs.
Ex. "Staff Photographer", "Envoyé spécial"
90 City non répétable, 32 caractères maximum Ville
95 Province/State non répétable, 32 caractères maximum Province/État
100 Country/Primary Location Code non répétable, 3 caractères Code du pays, suit la norme ISO3166 (codes pays sur 3 caractères)
101 Country/Primary Location Name non répétable, 64 caractères maximum Libellé du pays
103 Original Transmission Reference non répétable, 32 caractères maximum Référence de la transmission (code)
105 Headline non répétable, 256 caractères maximum Titre
110 Credit non répétable, 32 caractères maximum Crédit (fournisseur de l'objet)
115 Source non répétable, 32 caractères maximum Source (propriétaire intellectuel de l'objet)
116 Copyright Notice non répétable, 128 caractères maximum Copyright
118 Contact répétable, 128 caractères maximum Contact
120 Caption/Abstract non répétable, 2000 caractères maximum Description, Résumé, Commentaire
122 Writer/Editor répétable, 32 caractères maximum Auteur de la Description (du champ 120)
130 Image Type non répétable, 2 caractères Type de l'image (cf. le document IPTC-NAA IIMV4)

La nomenclature des champs IPTC-NAA illustre bien l'une des difficultés inhérentes au domaine des métadonnées: la terminologie adoptée et la sémantique des éléments sont adaptées à la presse quotidienne, mais peuvent apparaître inadéquates pour d'autres secteurs traitant de l'image (y compris pour la presse magazine). Par exemple:

On comprend mieux l'intérêt du Dublin Core qui est de proposer une structure de métadonnées certes simple, mais appuyée sur un consensus terminologique et sémantique minimal.

Il est possible de définir des champs personnalisés de type IPTC. Le logiciel FotoStation par exemple permet de définir vingt Custom Fields numérotés de 200 à 219. L'utilisation de ces champs personnalisés peut constituer une solution propriétaire dans le cas où la nomenclature IPTC est insuffisante ou inadaptée.

Le modèle IPTC-NAA permet de coder les champs selon divers jeux de caractères étendus. Les logiciels actuels devraient donc être capables de gérer correctement les accents, les signes diacritiques, etc. Il n'en est rien - si l'on utilise des caractères étendus lors de la saisie des informations dans Photoshop par exemple, ces informations ne sont pas correctement affichées sur une autre plate-forme. Adobe préconise de n'utiliser que l'ASCII 7 bits [ce qui est inacceptable pour beaucoup de langues!] parce que le standard IPTC n'autorise que ce jeu de caractères [ce qui est faux!] cf. Extended Characters in File Info Fields Don't Appear Correctly in Photoshop 6.0 or Later .
Bien entendu, de nombreux utilisateurs utilisent des caractères accentués pour rédiger leurs légendes IPTC et peuvent se trouver ensuite confrontés à la nécessité de convertir ces légendes selon un autre codage. Nous avons donc développé CrossIPTC , un utilitaire de conversion rapide des métadonnées des images, permettant de rendre compatibles les textes de champs IPTC-NAA des fichiers JPEG ou TIFF entre les plate-formes Windows et  Macintosh.

Voir aussi les Propositions pour la rédaction des champs IPTC (document PDF) que nous avons rédigé pour le portail d'agences photos PixPalace.

Pour terminer cette section, voici une liste non exhaustive de programmes capables d'exploiter les champs IPTC des images JPEG ou TIFF:

Les métadonnées EXIF

EXIF est une abréviation de EXchangeable Image File. Ce format définit les informations d'ordre technique contenues dans les fichiers image. Comme les champs IPTC, ce sont donc des métadonnées de type interne (cf. Où sont les métadonnées ? ). Ces informations concernent les paramètres de prise de vue et les réglages de l'appareil au moment de la capture numérique.

Le format EXIF a été développé en octobre 1995 par le JEIDA ( Japan Electronic Industry Development Association ). La version 2.0 date de novembre 1997 et la révision 2.1 de Juin 1998.
Pour en savoir plus, consultez également le site Exif.org maintenu par John Hawkins.

Une description technique des métadonnées EXIF est disponible sur le site PIMA (Photographic and Imaging Manufacturers Association) devenu I3A (International Imaging Industry Association). On remarquera que cette description propose également un format pour les fichiers audio (en concurrence avec les métadonnées ID3 ) ainsi qu'un jeu spécifique d'informations GPS pour les appareils capables de fournir leur position géographique à l'aide d'un système GPS.
Nous renvoyons à ce document le lecteur intéressé par le détail des nombreux champs EXIF.

La plupart des métadonnées EXIF ont effectivement trait aux caractéristiques techniques des images telles qu'elles peuvent être fournies par l'appareil au moment de la prise de vue. Citons: fabricant et modèle de l'appareil, hauteur et largeur de l'image, date et heure de la prise de vue, orientation, résolution, temps d'exposition, ouverture, présence d'un flash, etc. Un logiciel permettant d'éditer ces informations n'a donc pas véritablement lieu d'exister. Cependant, plusieurs champs EXIF concernent également la description de l'image et sont manifestement concurrents de certains champs IPTC essentiels, notamment:

Cette situation est regrettable et illustre une fois de plus la confusion qui règne très souvent dans le domaine des métadonnées.
Nous proposons la "règle" distinctive suivante:

Pour terminer cette section, voici une liste non exhaustive de programmes capables de lire les champs EXIF des images JPEG (les champs EXIF sont en général non modifiables et c'est très bien ainsi...) :

Les propriétés des images selon Microsoft

Microsoft a introduit avec Windows 2000 la possibilité d'associer des propriétés Titre, Auteur, etc. à un fichier quelconque; il suffit de cliquer avec le bouton droit sur le nom du fichier, activer le menu contextuel Propriétés, onglet Résumé et de renseigner les champs disponibles. 
Cette possibilité constitue une généralisation des propriétés associées aux fichiers MS Office (Word, Excel, etc.), mais elle n'est possible avec Windows 2000 qu'à la condition que le fichier soit stocké sur un volume NTFS. Il n'est pas possible d'ajouter des propriétés à un fichier quelconque (non MS Office) stocké sur un volume FAT. En effet, la technique utilisée pour sauvegarder ces métadonnées utilise les alternate streams qui sont une spécificité du système de fichiers NTFS. Pour en savoir plus, vous pouvez consulter notre page Windows NT/2000 et les fichiers Macintosh, section Les streams NTFS .
Les noms des alternate streams utilisés peuvent être facilement affichés, par exemple à l'aide des utilitaires gratuits ShowStream et CmdStream proposés par Jean-Claude Bellamy sur son excellente page Les flux (méta-données dans les partitions NTFS) .

Ceci vaut aussi bien entendu pour les images JPEG/TIFF en Windows 2000.

Cette technique est évidemment complètement propriétaire et l'on perd les propriétés associées à un fichier lorsque:

Avec Windows XP, Microsoft a donc introduit une nouvelle technique de stockage des propriétés spécifique aux images JPEG/TIFF.
Toutes les propriétés sont de type 'chaîne' et stockées à l'intérieur de l'image selon un encodage de type EXIF , en Unicode [2 octets par glyphe].

Cette nouvelle technique propre aux images n'existe que sur Windows XP et n'est pas opérationnelle sur Windows 2000. Autrement dit, une même image évoluant dans un réseau équipé de postes Windows 2000 et Windows XP peut posséder deux jeux de métadonnées Windows totalement incompatibles!
Par ailleurs, sur Windows XP, les propriétés des fichiers autres que les documents Office et les images JPEG/TIFF sont toujours stockées dans les alternate streams ?SummaryInformation, etc., comme en Windows 2000.

L'histoire (officieuse mais plausible) raconte que Microsoft a développé cette technique pour rendre portables les informations associées aux images, mais s'est rendu compte, au cours du développement, que l'encodage EXIF ne supporte pas l'Unicode et ne possède pas de champ Catégorie. On se retrouve donc avec un encodage des métadonnées associées aux images toujours aussi propriétaire (mais portable de Windows XP à Windows XP), sans champ Catégorie, incompatible avec les spécifications EXIF et IPTC, et qui plus est, incompatible avec Windows 2000! Un comble...

En résumé, pour associer des métadonnées aux images JPEG/TIFF, nous recommandons d'utiliser les champs IPTC ou mieux IPTC Core et rien d'autre...

Une autre différence moins importante entre Windows 2000 et Windows XP concerne le stockage des vignettes (thumbs) associées aux images et permettant d'optimiser l'affichage.

RDF [Resource Description Framework]

Note: Cette section est une présentation succincte de RDF et ne prétend pas constituer un cours sur le sujet.

RDF est basé sur des triplets

Exemple

sujet  prédicat 

objet


ou


ressource 

propriété 

valeur

Le document RadioTV-NewsML in Japan

a pour auteur

M. Onishi

sujet

prédicat

objet




 

 

 

 

 

 

PRISM

NewsML

NITF

DIG35

JPEG2000 et JPX

Autres spécifications

D'autres spécifications s'appuyant pour certaines sur RDF comportent également des développements importants concernant les métadonnées.
Parmi celles-ci, on peut citer:

XMP

Le schéma XMP IPTC Core

IPTC Core version 1.0 est le standard qui succède à l'Information Interchange Model (IIM version 4.1) de l'IPTC. Il est donc destiné à remplacer la technologie des "informations IPTC classiques" (dérivées de l'IIM) et s'appuie sur le framework XMP défini par Adobe en 2001. Il a été annoncé officiellement en Mars 2005.
IPTC Core est issu du groupe de travail IPTC For XMP (IPTC4XMP) constitué par l'IPTC, IDEAllliance, et la société Adobe.
Les avantages de la technologie XMP sur les informations IPTC "classiques" sont nombreux: pas de limitation de taille des champs, pas de problèmes d'accents (codage Unicode), possibilité de légendes multilingues, extensibilité et personnalisation des métadonnées.
IPTC Core définit un ensemble de métadonnées exprimées en XMP et destiné à faciliter la transition des informations IPTC "classiques" vers le nouveau standard XMP.
IPTC Core reprend la plupart des informations de la version précédente (IIM v4.1) comme les champs Keywords, By-line, Headline, Caption, etc. Certains champs sont abandonnés: Urgency, Category, Supplemental Categories. Enfin, de nouveaux champs font leur apparition: Intellectual Genre, Rights Usage Terms, IPTC Scene, etc.

Documentation IPTC Core

Trois documentations au format PDF sont fournies:
Les panneaux personnalisés Photoshop CS (Custom Panels)

Quatre panneaux personnalisés pour Photoshop CS sont livrés à titre d'illustration d'une implémentation de l'IPTC Core. Ils sont en anglais. Un programme d'installation des panneaux est également fourni [pour Windows uniquement mais il est également facile de les installer "à la main" sur Macintosh]. Ces panneaux ont pour but d'organiser les informations de l'IPTC Core (voir le document Implementation Guidelines) et de faciliter la saisie.
À consulter: un "tutorial"au format Quicktime par David Riecks (en anglais)

Vers le Web sémantique [Semantic Web]

Note: Nous avons ajouté cette courte section pour préciser le contexte des recherches et projets actuels dans le domaine des métadonnées

 

MetaDataMiner Catalogue utilitaire permettant d'afficher et de modifier rapidement de nombreux types de métadonnées associées aux fichiers: propriétés Microsoft Office ou OpenOffice.org , propriétés associées à tous les fichiers Windows 2000, informations sur les documents PDF, champs IPTC des images JPEG, métadonnées XMP, etc. Il permet également d'explorer les métadonnées et de générer des rapports HTML ou XML à des fins de documentation ou d'exploitation dans une base de données.

Testez aussi les utilitaires suivants de Soft Experience qui facilitent l'intégration des plate-formes Windows et Macintosh:

Idem automatise la synchronisation et la réplication de dossiers . Il sauvegarde les fichiers Windows ou Macintosh résidant sur un poste ou un serveur NT/W2K. Disponible aussi en mode service.
MacNames : facilite l'échange de données entre Windows et Macintosh et l'intégration des 2 plate-formes connectées à un même serveur NT ou 2000. Il permet de renommer automatiquement les fichiers Macintosh stockés sur un serveur Windows NT ou 2000 en supprimant les caractères invalides et en ajoutant les extensions aux fichiers.
Delenda purge chaque jour le contenu d'une liste de dossiers en local ou sur un serveur en fonction de la date de création, modification ou de dernier accès aux fichiers.
Rarissimo Compression, décompression automatique de fichiers préservant les streams et la structure spécifique des fichiers Macintosh

Metadata Solutions: Using Metamodels, Repositories, XML, and Enterprise Portals to Generate Information on Demand Metadata Solutions: Using Metamodels, Repositories, XML, and Enterprise Portals to Generate Information on Demand

 

  ecrire Vous pouvez nous joindre ici

Signaler ce lien à un ami ou partenaire !

     XML Schéma (édition française) Quelques ouvrages en anglais sur le Data Mining et le Datawarehouse