Métadonnées:
une initiation
Dublin Core, IPTC, Exif, RDF, XMP, etc.
première version: août 2002
dernière mise à jour: 13 décembre 2007
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.)
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 (anthologie, 1933 à 1950) traduit de l’anglais par Didier Kohn, Mireille de Moura & Jean-Claude Dernis Éditions de
l'Éclat, 1998, p. 64
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, Geocodage, DIG35, JPX) et à la presse (PRISM, NewsML, NITF).
la présentation
au format PDF réalisée pour la seconde
journée "Compatibilité et
réutilisation des contenus - 9 octobre 2002"
organisée par l'ex-ADAE
(Agence pour le Développement de l'Administration
Électronique - anciennement ATICA).
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:
la description et la recherche de ressources
la gestion de collections de ressources
la
préservation des ressources
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.).
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 ou pour une ressource sur Internet (une page Web par exemple). Les
métadonnées attribuées inconsidérément 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:
MARC
(Machine-readable cataloging), pour la description des
ouvrages
ISBD(S)
(International Standard Bibliographic Description for Serials), pour
la description des publications en série
Dewey
Decimal Classification system, pour la classification
décimale des ouvrages
EAD
(Encoded Archival Description), pour la description des
archives
CIMI
consortium (Computer Interchange of Museum Information), pour
la description des ressources muséographiques
RKMS
(Recordkeeping Metadata Schema), pour la description des
ressources audio
LOM
(IEEE - Learning Object Metadata), pour la description des
ressources liées à l'éducation
Les
métadonnées informatiques
Les objets
informatiques courants contiennent de nombreuses
métadonnées implicites ou
explicites. En voici quelques exemples:
Cette ressource
contient
plusieurs métadonnées: protocole http,
top level domain com, page Web statique en HTML (on
suppose qu'elle traite des métadonnées....)
Plus
généralement: chemin d'accès, nom,
extension, taille, attributs, date de création, date de
modification, propriétaire, droits d'accès, etc. sont
des métadonnées
Les champs <title> et
<meta>
des pages HTML
Les
propriétés des documents MS
Office (Word, Excel, etc.)
Titre,
Auteur, Sujet,
Mots-clés, Commentaires, Responsable,
Société, Catégorie, etc. [25
éléments + possibilité de
propriétés personnalisées]
Les
propriétés des documents
StarOffice et OpenOffice.org
Titre,
Sujet,
Mots-clés, Description, Internet + possibilité de
4 propriétés personnalisées
Les informations sur les documents
PDF
Titre, Auteur,
Sujet,
Mots-clés, Créateur, Producteur, etc. [9
éléments]
Titre,
Compositeur, Auteur
du texte, Durée, Copyright, etc. [74
éléments organisés en frames]
Les
métadonnées
spécifiques à chaque plate-forme
sur Macintosh OS 9: Famille
(Essentiel, Important, En cours, Personnel, etc.) et Commentaires
sur Windows 2000/XP:
Propriétés associées à un
fichier quelconque (Titre, Sujet, Catégorie,
Mots-clés, etc.)
L'estampillage électronique [Watermarks]
qui permet d'authentifier un document et de prouver l'appartenance
d'une œuvre à son propriétaire au moyen
de tatouages (insertion d'informations numériques dans les
fichiers binaires que sont les images, sons, vidéo).
La stéganographie
par contre (c'est-à-dire les techniques qui consistent
à cacher des informations dans une ressource quelconque de
façon à ce que seul un utilisateur connaissant la
technique utilisée puisse retrouver ces informations) ne
doit pas à notre avis être
considérée comme relevant du domaine des
métadonnées, puisque les données
cachées au sein de la ressource ne sont pas liées
sémantiquement à la ressource.
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 IPTCCaption/Abstract,
un champ ExifImageDescription,
un ou plusieurs
champs XMPDescription
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:
au Contenu: Title,
Description,
Subject, Source, Coverage, Type, Relation
à
la Propriété
intellectuelle: Creator, Contributor, Publisher, Rights
à la Version: Date, Format,
Identifier, Language
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
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:
Pour faire référence
à un
élément du Dublin Core,
l'OCLC
préconise d'utiliser un (une ?) PURL
(Persistent
Uniform Resource Locator)
défini pour le Dublin Core.
Une PURL est en fait une URL réputée persistante et
redirigée 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 une 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 des formes diverses (des fiches dans
une boîte à chaussure aux données
informatiques).
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 et avec la souplesse nécessaire (recherches sur plusieurs
critères,
troncatures, vocabulaires contrôlés, 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, 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, compacté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:
Il ne peut se substituer à la
description
à l'aide de métadonnées
stockées dans une base de données. Seules les
bases de données permettent de gérer
d'importantes quantités d'images et de rechercher
efficacement dans un vaste ensemble.
Tous les
programmes de manipulations d'images ne sont pas
capables de lire ou même de préserver les
métadonnées incluses. On peut
considérer que le fait de ne pas être capable
d'afficher les métadonnées incluses dans une
image est supportable. Par contre, supprimer ces
métadonnées lors d'une manipulation comme une
rotation ou un cropping est inadmissible. C'est
pourtant ainsi que procèdent plusieurs programmes de
traitement ou de catalogage d'images.
Les
métadonnées IPTC/IIM
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 en 1994 à 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 ou headers)IPTC. Le modèle IPTC/IIM est à présent
considéré par l'IPTC
comme un "standard obsolète" [legacy standard]
qui sera
progressivement remplacé par le nouveau schéma de
métadonnées IPTC
Core basé sur XMP
. Ce standard reste néanmoins très largement utilisé par les professionnels, surtout dans la presse.
Les 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
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:
Les noms et structures des champs IPTC/IIM dans
les
programmes d'édition ne sont pas identiques.
Headline (n° 105) correspond par exemple au Titre
dans le domaine de l'écrit. Or, à la suite des
choix réalisés par Adobe dans Photoshop, Object
Name (n° 5) est appelé Titre
(Title) par la majorité des
éditeurs...
Voir le document IPTC
- IIMv4 Fields mapped to Imaging Programs qui compare la
nomenclature des champs IPTC dans les logiciels suivants: Image Info
Toolkit, Photoshop 7.01, Photoshop 6 et IrfanView.
Voir aussi le tableau de Correspondance
entre les informations IPTC/IIM et les champs disponibles de certains
éditeurs IPTC
Date
& TimeCreated
(n° 55 et 60), c'est-à-dire la Date et l'Heure de
création de l'image ne correspondent pas aux besoins des
agences magazines qui travaillent par reportages souvent
étalés sur plusieurs jours.
Release
Date & Time (n°
30 et 35), c'est-à-dire la Date et l'Heure de
disponibilité de l'image, n'ont guère
d'intérêt que dans un contexte "presse
quotidienne" où une image peut être sous embargo
de publication avant une certaine date. Par contre, d'autres
professions auraient besoin d'autres informations concernant l'image
mais non prévues dans la nomenclature IPTC-NAA.
By-line (n° 80) correspond
à Auteur, terme adopté
majoritairement dans le domaine de l'écrit ou par d'autres
professions de l'image.
Rappelons que le Dublin Core a retenu Creator
(v. ci-dessus ).
Certains
champs sont absents dans certains
éditeurs: Edit
Status (n° 7), Contact (n°
118)
Caption/Abstract
(n° 120)
correspond à Description, Résumé,
Commentaire, etc.
Category
(n° 15) et Supplemental
Category (n° 20) sont
considérés comme obsolètes dans l'IIMV4
et sont pourtant encore largement utilisés.
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 de FotoWare 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. Plusieurs éditeurs utilisent ainsi un champ non standard n° 92 Location permettant de préciser une localisation, une adresse; il est vrai qu'à l'heure du GPS le seul champ n° 90 City n'est plus suffisant...
Le
modèle IPTC/IIM permet théoriquement 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 6.0 par exemple, ces informations ne sont pas correctement
affichées sur
une autre plate-forme. Jusqu'en 2004, Adobe préconisait 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 informations
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/IIM des fichiers JPEG ou TIFF
entre les
plate-formes Windows et Macintosh.
PixVue
, par Eamonn Coleman, Win (sauf Vista !), extension de l'Explorateur;
le logiciel n'est plus maintenu par l'auteur mais on encore le
télécharger sur notre site, traduit en
français par Soft
Experience, gratuit
Rodeo
Info , Mac OSX, affiche les informations IPTC, gratuit
Signalons enfin le logiciel BabelPix, capable de traduire des mots-clé IPTC de l'anglais vers l'espagnol (et inversement)
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, la révision 2.1 de juin 1998 et la révison 2.2 d'avril 2002.
Pour en savoir plus,
consultez également le site Exif.org
maintenu
par John Hawkins.
Le
format Exif n'est pas soutenu par une organisation internationale de
standardisation, mais il est utilisé par pratiquement tous les
constructeurs d'appareils photographiques numériques (APN); en
ce sens, c'est un standard de fait.
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) et sur le site Exif.org. 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 (voir ci-dessous Géocodage).
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:
Titre de l'image (Exif ImageDescription
= IPTC Headline)
Personne
ayant créé l'image (Exif Artist
= IPTC By-line)
Titulaire du
Copyright (Exif Copyright
= IPTC Copyright Notice)
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:
IPTC:
métadonnées
ayant trait à la sémantiquede l'image et nécessitant l'intervention d'un
opérateur humain pour être renseignées:
Créateur, Description, Mots-clés, Copyright, etc.
Exif:
métadonnées
techniques relatives à la prise
de vue et fournies automatiquement par un appareil
numérique. Selon cette acception, un éditeur de
métadonnées Exif constitue un non-sens et l'on
prohibera donc l'usage des champs Exif ImageDescription,
Artist et Copyright.
À l'inverse, puisque la date de prise de vue est fournie
automatiquement par l'appareil, on est en droit de
privilégier la date Exif par rapport à la date
IPTC.
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...) :
PixVue, par Eamonn Coleman, Win (sauf Vista !), extension de l'Explorateur;
le logiciel n'est plus maintenu par l'auteur mais on encore le
télécharger sur notre site, traduit en
français par Soft
Experience, gratuit
Exifer
, par Friedemann Schmidt, Win, gratuit
- permet la sauvegarde et la restauration des
métadonnées Exif. Il permet aussi
d'éditer les champs suivants : Description,
Artist, Photographer, Editor,
Comment, Dates - tous les
autres autres champs Exif sont considérés comme
non modifiables.
Le géocodage (ou géotaggage; en anglais: geocoding, geotagging)
consiste à associer des métadonnées
géographiques à des ressources diverses telles que des
sites webs, des flux RSS ou des images. Pour les images, il s'agit
essentiellement d'associer les coordonnées GPS de la prise de
vue (longitude, latitude, altitude, direction) dans les données
Exif de l'image numérique. La version 2.2. de la
spécification Exif, apparue en 2002, permet en effet de stocker
un grand nombre d'informations géographiques dans une image;
cependant, la plupart des applications du géocodage se contente
de stocker la latitude et la longitude du leiu de prise de vue,
bien plus rarement l'altitude et encore plus rarement la direction. Attention:
il s'agit la plupart du temps de la localisation du photographe lors de
la prise de vue, pas de la localisation du sujet photographié -
cela peut-être très différent (par exmple dans le
cas d'une photo aérienne, de l'utilisation de
téléobjectif, d'une photo de montagne, etc.) Il faut en tenir compte lors de la recherche selon les coordonnées GPS stockées dans les images.
Méthodes de géocodage les plus répandues
Utiliser un APN pourvu d'un GPS intégré – encore rare (Ricoh 500SE par exemple)
Exploiter
par interpolation les tracks d'un GPS actif lors des prise de vues en
fonction des timestamps des images fournis par l'APN; les horloges de
l'APN et du GPS doivent être aussi synchrones que possible. voir les programmes: Geotag (licence GPL), RoboGeo, etc.
Associer une image à une localisation sur une carte telle que Google Earth voir les programmes: Geotag (licence GPL), RoboGeo, Picasa avec Google Earth, Panorado Flyer (extension de l'explorateur Windows) avec Google Earth, etc.
Nous avons développé le programme GeoIPTCpermettant d'ajouter une identification géographique à vos images grâce aux métadonnées IPTC et IPTC Core qu'elles contiennent.
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
(Resource Description Framework) est un moyen d'encoder,
échanger et réutiliser des
métadonnées structurées. C'est un
idiome XML
développé par le W3C et ayant
fait l'objet d'une Recommandation en 1999.
RDF ne précise pas la
sémantique des ressources décrites par les
différentes communautés d'utilisateurs de
métadonnées. À l'instar d'XML, RDF
est un langage extensible, un métalangage; c'est un cadre [framework]
de description des ressources applicable à n'importe quel
domaine d'application.
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
Ces triplets sont modélisés
à l'aide de graphes orientés
étiquetés
Les ressources sont identifiées par
des URI
(Unified Ressource Identifier).
Les URI peuvent être
considérés comme un "stock de noms"
utilisés pour désigner des choses ou des concepts.
Les URL habituelles sont des URI.
Ainsi, dans notre exemple, le document RadioTV-NewsML in Japan
peut être identifié naturellement par l'URI http://xml.coverpages.org/RadioTV-NewsML-en-20020224.pdf Les prédicats
(propriétés) sont également
représentés par des URI
L'URI
du prédicat "a
pour auteur" est l'élément Creator
du schéma Dublin Core:
http://purl.org/dc/elements/1.1/creator
Un sujet (ressource) peut posséder
plusieurs
prédicats (propriétés)
Ce qui se traduit
en syntaxe RDF:
Les ressources
décrites
peuvent être imbriquées:
Notion de schéma RDF
Un schéma RDF permet de
décrire un vocabulaire et une sémantique des
types de propriétés utilisées par une
communauté d'utilisateurs.
Un schéma RDF précise les
propriétés valides pour une description RDF
particulière, ainsi que les caractéristiques et
contraintes du vocabulaire descriptif. Exemple
: le
schéma RDF du Dublin Core, version 1.1
Il faut bien distinguer entre:
Schéma
XML (dont le
rôle est plus ou moins analogue aux DTD) qui exprime des
contraintes sur la structure et la syntaxe XML
Schéma
RDF qui exprime
des contraintes sur la sémantique des expressions d'un
modèle RDF
RDFPic
est un programme développé par le W3C pour
permettre d'incorporer des métadonnées au format
RDF (simplifié) au sein d'une image. Il n'a jamais
dépassé le stade expérimental.
PRISM
( Publishing Requirements for Industry
Standard Metadata) est un
idiome RDF extensible permettant de
décrire les métadonnées
utilisées dans la presse pour la syndication et
l'agrégation de données. PRISM
a été
initié par un groupe de travail IDEAlliance
(International Digital Enterprise Alliance) fondé en 1999 et
comprenant des sociétés comme Adobe,
Artesia, Condé Nast, Netscape,
Quark, Reuters, Time,
Vignette, etc.
PRISM
utilise une version
simplifiée du langage RDF. C'est un
"vocabulaire commun" destiné à décrire
les contenus, l'origine de ces contenus, les droits
associés, etc.
Les
métadonnées définies
à l'aide de PRISM doivent pouvoir
être traitées par les processeurs RDF
(mais l'inverse n'est pas vrai).
PRISM
utilise le Dublin Core
comme fondation et recommande l'utilisation du vocabulaire DC. PRISM étend le vocabulaire du Dublin
Core. Par exemple, les éléments
suivants du Dublin Core: dc:coverage
et dc:subject sont complétés
par prism:event, prism:industry,
prism:location, prism:person, prism:organization,
prism:section.
PRISM
recommande d'utiliser des
vocabulaires contrôlés, par exemple un
Thésaurus de noms géographiques au lieu de
spécifier en toutes lettres un nom de lieu.
Cliquez ici
pour afficher un exemple de codification PRISM
NewsML
NewsML
est une spécification de l' IPTC (International
Press and Telecommunications Council) pour la transmission et
l'échange des informations d'actualités.
La version 1.0 a été ratifiée en
Octobre 2000, la version 1.1 en Octobre 2002, et la version 1.2
actuelle en Octobre 2003. L'IPTC est actuellement en train de travailler sur la prochaine version "NewsML-G2". NewsML est
d'ores et déjà
utilisé (et le sera de plus en plus) par les agences de
presse ( AFP , Reuters ) pour la
transmission des dépêches et l'automatisation des
fils d'agences. NewsML est conçu pour
l'échange des textes, graphiques, photos,
séquences audio, video et animations.
Bien
qu'il existe certains chevauchements entre PRISM
et la partie de NewsML qui traite des
métadonnées, les deux spécifications
sont largement indépendantes et complémentaires.
Ainsi, à la différence de PRISM, la
partie de NewsML concernant les
métadonnées ne s'appuie pas sur RDF.
Le vocabulaire PRISM a été
défini de telle façon qu'il puisse être
utilisé dans la partie de NewsML
traitant des métadonnées qui comprend trois
catégories majeures:
AdministrativeMetadata
RightsMetadata
DescriptiveMetadata
NewsML permet
d'étendre le
jeu des métadonnées
prédéfinies ainsi que l'utilisation de
vocabulaires contrôlés pour spécifier
certaines métadonnées.
À cette fin, NewsML préconise
l'utilisation des taxonomies de métadonnées IPTC NewsCodes pour décrire les
informations échangées.
ProgramGuideML
, pour l'échange des programmes de
télévision et radio
Pour en savoir plus: NewsML
for dummies par Laurent Le Meur (AFP - actuel chairman du groupe
NewsML)
NITF
NITF
( News Industry Text
Format, actuellement en version 3.2) est
également une spécification de l' IPTC . Elle concerne
la description des articles de presse. NITF
possède quelques
éléments permettant de décrire les
métadonnées associées à un
article ou à ses composants; comme pour NewsML,
ces éléments ne s'appuient pas sur RDF.
NewsML utilise un sous-ensemble de NITF
pour décrire la composition des articles transmis
(structuration de l'article en Titre, Sous-titre,
etc.; organisation des paragraphes; places des illustrations).
NITF est utilisé par l'AFP
dans NewsML pour décrire le corps des
dépêches (à la différence de
Reuters qui utilise XHTML).
DIG35
est une initiative du groupe I3A
(International Imaging Industry Association) créé
par la fusion du PIMA (Photographic and Imaging Manufacturers
Association) et du DIG (Digital Imaging Group). Elle concerne la
définition de standards de métadonnées
pour les images digitales.
DIG35
spécifie un langage XML (mais non RDF)
permettant de décrire un jeu complet de
métadonnées. La version 1.0 date d'août
2000 et la version 1.1 de Juin 2001.
Les
métadonnées DIG35 sont
regroupées en 5 blocs complétés par un
bloc commun définissant les types de données
utilisés:
Basic Image
Parameter
Image Creation
Content Description
History
Intellectual Property Rights
Fundamental
Metadata Types and Fields:
bloc de définitions communes aux autres blocs
DIG35 définit également
une technique
d'encapsulation dans les fichiers JPEG et TIFF
À
l'heure actuelle, il n'existe pratiquement
aucun produit supportant DIG35 et l'intérêt
essentiel de cette initiative est d'avoir largement inspiré
le format de métadonnées de JPEG2000 ( JPX ).
Cliquez ici
pour afficher un exemple de codification DIG35
JPEG2000
est un nouveau format d'image défini par le
comité JPEG
. C'est une norme ISO pour la compression d'images utilisant la
technique de tranformée en ondelette discrète. Le format JPEG2000 (extension JP2) doit très
progressivement remplacer le format JPEG.
JPX est
un format de fichier optionnel conçu
comme une extension du format JP2 (JPEG2000); JPX permet entre autres
de définir un conteneur pour l'image JP2 et pour les
métadonnées associées.
À
l'instar de DIG35
dont il s'inspire largement, JPX spécifie un langage XML
(mais non RDF) permettant d'exprimer un jeu complet de
métadonnées liées à l'image.
Les métadonnées JPX sont
regroupées en 4 blocs complétés par un
bloc commun définissant les types de données
utilisés:
Image Creation
metadata
Content Description
metadata
History metadata
Intellectual Property Rights metadata
Fundamental Metadata Types and Elements:
bloc de définitions communes aux autres blocs
Il existe des propositions pour
réencoder en JPX
les métadonnées Dublin
Core , Exif et IPTC .
D'autres
spécifications s'appuyant pour certaines sur RDF comportent
également
des développements concernant les
métadonnées.
Parmi celles-ci,
on peut citer:
XMLNews-Story
- sous-ensemble de NITF pour la
description des articles
XMLNews-Meta - format
RDF simplifié pour la
description des métadonnées
RSS (Rich Site Summary / RDF Site Summary / Really Simple Syndication), qui existe en plusieurs
versions:
0.91
, 0.92
et 2.0
– proposé initialement par Netscape et largement
utilisé pour la syndication de données, ce format
est inspiré de RDF mais n'est pas conforme à la
syntaxe RDF.
1.0
– plus complexe et conforme à RDF, il permet la
description de métadonnées arbitraires.
XrML
(eXtensible Rigths Markup Language), spécialisé
pour la définition et la gestion des droits
associés aux contenus digitaux.
XrML a été développé par ContentGuard ,
société issue de Xerox.
Microsoft considère XrML comme un composant essentiel de sa
stratégie DRM (Digital Rights Management) et l'utilise dans
sa technologie eBooks.
ODRL
(Open Data Rights Language), le concurrent de XrML,
developpé par Renato Iannella ( IPR Systems -
Australie).
ODRL est un langage Open Source et soumis au W3C. Cliquez-ici
pour afficher un exemple de codification utilisant conjointement les
espaces de noms Dublin Core, RDF,
PRISMet ODRL.
XMP [eXtensible Metadata Platform]
XMP
(e Xtensible Metadata Platform)
est un format créé par la
société Adobe en septembre
2001. XMP repose sur une
version
simplifiée de RDF
.
XMP utilise le
schéma de
métadonnées du Dublin
Corecomme fondation.
Le schéma du Dublin Core est
étendu en XMP par d'autres
schémas proposés par Adobe:
Core Schema
Media Management Schema
Support Schema
Basic Job Tickets Schema
Rights Management Schema
XMP est extensible - l'utilisateur peut
définir ses propres schémas de
métadonnées.
XMP
définit un
mécanisme appelé XMP Packet
permettant d'encapsuler les métadonnées XMP
dans les fichiers des applications. À l'instar des champs IPTC et Exif
pour les images, les
métadonnées XMP
définies à l'aide d'XMP Packet
sont donc internes; toutefois, la comparaison
s'arrête là car les caractéristiques
évoluées de XMP en font une
technique beaucoup plus souple.
Le
mécanisme XMP Packet est
supporté par toutes les applications Adobe
récentes.
Ces applications utilisent 3 schémas de
métadonnées:
Dublin Core
(espace de noms dc:)
PDF (espace de noms pdf:)
Photoshop (espace de noms photoshop:)
XMP Packet permet
d'accéder
aux métadonnées en lecture et écriture
même en l'absence d'applications capables de comprendre le
format de fichier.
Lorsque ce n'est pas possible d'implémenter XMP
Packet dans un format de fichier propriétaire, les
métadonnées XMP peuvent bien sûr
être stockées dans un fichier
séparé habituellement suffixé .xmp (sidecar
file).
La technique XMP
Packet est
définie par Adobe pour les formats
suivants:
JPEG, TIFF, GIF, PNG, HTML, PDF, XML/SVG, PDF, AI, EPS.
Un fichier JPEG - par exemple - contenant un XMP Packet doit
pouvoir être traité sans changement par les
applications ne supportant pas XMP.
Les
caractéristiques de XMP
[langage XML, possibilité d'étendre les
schémas de métadonnées, encapsulation
dans les fichiers à l'aide d'XMP Packet,
possibilité d'exploiter les
métadonnées en l'absence des applications
d'origine] en font le successeur des champs IPTC
dans le domaine de l'image (tout au moins tant que les formats JPEG2000 et JPX ne seront pas
plus répandus), cf. IPTC
Core .
XMP
est moins orienté vers le
Web que la plupart des applications RDF. XMP
est destiné à
gérer et préserver les
métadonnées tout au long de la chaîne
éditoriale. Il gère les versions de documents,
les changements de formats (renditions), les
documents composites (dont les constituants doivent conserver leurs
propres métadonnées).
XMP
n'est pas une
spécification normalisée (W3C ou autre).
Cependant Adobe propose ce format ainsi qu'un SDK
sous licence open-source de façon
à étendre sa diffusion. XMP
est supporté actuellement par la plupart des CMS [Content
Management Systems]:
Nos logiciels Catalogue
et Kalimages PRO permettent d'extraire les informations XMP des images.
Signalons
également que l'excellent PixVue, une extension de l'Explorateur Windows (sauf Vista !) écrite par Eamonn Coleman, permet d'exploiter et d'extraire les
métadonnées IPTC, Exif et XMP des images;
le logiciel n'est plus maintenu par l'auteur mais on encore le
télécharger sur notre site, traduit en
français par Soft
Experience.
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, Location, etc.
Documentation
IPTC Core
Trois documentations au format PDF sont fournies:
"IPTC
Core"
Schema for XMP version 1.0 / Specification Document (document revision
8): définit le vocabulaire de
métadonnées IPTC Core exprimé sous la
forme d'un schéma XMP
IPTC Core
Schema for XMP version 1.0 / Supplemental Documentation: Implementation
Guidelines (document revision 3): précise la
façon d'implémenter le schéma XMP IPTC
Core, les algorithmes de synchronisation entre l'IPTC Core et les
informations IPTC "classiques", donne des recommandations pour
l'interface utilisateur (en particulier le regroupement des
informations)
"IPTC
Core"
Schema for XMP version 1.0 / Supplemental Documentation: Custom Panels
User Guides (document revision 13): décrit les
panneaux personnalisés Photoshop CS livrés avec
le package IPTC Core
(v. ci-dessous).
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; cependant, l'IPTC fournit ici une liste des termes français recommandés pour l'IPTC Core. 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)
Nous proposons
également sur ce site une traduction en
français (non officielle) des panneaux
personnalisés Photoshop CS pour le
modèle IPTC Core.
IPTC
Contact
Panel - informations concernant le contact du photographe
Plusieurs champs de ce panneau n'existaient pas dans la version
précédente.
IPTC
Content
Panel - contenu visuel de l'image
IPTC Subject Code
remplace les anciens champs Category
et Supplemental
Categories
IPTC
Status
panel - informations de copyright et concernant la
circulation de la photo
Les
propriétés des images selon Microsoft
Windows 2000
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)
.
Les propriétés Titre,
Objet, Auteur, Mots-clés,
Commentaires, Révision utilisent un alternate
stream nommé ?SummaryInformation
(où ? représente le caractère
hexadécimal x05)
La
propriété Catégorie
utilise un alternate stream nommé ?DocumentSummaryInformation (?
= x05)
La
propriété Source
utilise un alternate stream nommé ?SebiesnrMkudrfcoIaamtykdDa (?
= x05)
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:
le fichier est copié sur une autre
plate-forme
le fichier est transmis par courrier
électronique
le fichier est
copié sur un volume non NTFS
le
fichier est compressé (à
l'exception de WinRAR qui permet optionellement de compresser les alternate
streams)
Windows XP
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].
Titre est dans un segment Exif
9C9B
Commentaires est
dans un segment Exif
9C9C
Auteur est dans un
segment Exif 9C9D
Mots-clés
est dans un segment Exif 9C9E
Objet est dans un segment Exif 9C9F
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...
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.
Sur un volume NTFS, Windows 2000 utilise un alternate
stream associé à chaque image et
nommé ?Q30lsldxJoudresxAaaqpcawXc
(?= x05)
Windows XP (ainsi que Windows
ME et Windows 2000 sur un
volume FAT) utilise un fichier cache (et caché!)
nommé Thumbs.DB par
répertoire contenant des images
Windows Vista
La
technique retenue dans Windows Vista est un peu plus proche des
standards puisqu'elle repose sur XMP, tout en reprenant, pour des
raisons de compatibilité, la "méthode Exif"
décrite ci-dessus et utilisée par XP. Sur Windows Vista,
on peut éditer directement les champs suivants:
Titre : stocké à la fois en XMP dans dc:title et dans un segment Exif
9C9B
Commentaires : stocké à la fois en XMP dans exif:UserComment (Microsoft) et
dans un segment Exif
9C9C
Auteur : stocké à la fois en XMP dans dc:creator et dans un
segment Exif 9C9D
Mots-clés : stocké uniquement en XMP dans dc:subject (il n'est pas dans un segment Exif 9C9E !)
Objet : stocké à la fois en XMP dans dc:description et
dans un segment Exif 9C9F
Copyright est stocké en XMP dans dc:rights
en outre, Vista utilise un schéma XMP Microsoft pour stocker les champs MicrosoftPhoto:DateAcquired (date de prise de vue), MicrosoftPhoto:LastKeywordXMP (historique des mots-clé), MicrosoftPhoto:Rating
(notation des images à l'aide d'étoiles). Un certains
nombres d'autres champs d'autres espaces de noms sont aussi
utilisés, essentiellement pour répliquer des informations.
On remarque donc des choix pour le moins étranges:
Les
informations ne sont pas présentes dans l'en-tête IPTC/IIM
ce qui interdit de les afficher et exploiter avec les nombreux
éditeurs uniquement IPTC (non XMP) du marché
Seuls Titre, Auteur, Mots-clés, Objet, Copyright peuvent être considérés comme compatibles avec Photoshop CS. Le champ Commentaires n'est pas affichable en standard dans Photoshop CS.
Mots-clés n'est même pas affichable sous XP
Enfin, les champs Exif Fabricant de l'appareil (EquipMake) et Modèle de l'appareil (EquipModel) sont éditables, ce qui nous semble une aberration totale.
L'extension Photo Info
Microsoft propose l'extension gratuite Photo Info
permettant d'éditer les métadonnées d'images
depuis l'Explorateur Windows. Ce programme
écrit à la fois les informations en IPTC/IIM et
leurs correspondants XMP, mais avec des particularités et
même des erreurs un peu gênantes:
Lorsque les informations IPTC/IIM et XMP ne sont pas concordantes (ce qui arrive quand on utilise un éditeur uniquement capable de gérer IPTC/IIM après avoir utilisé un éditeur XMP), alors Photo Info affiche prioritairement les données XMP, comme le fait Photoshop CS, excepté pour les champs Category et Supplemental Category
(obsolètes d'après l'IPTC mais encore utilisés)
où les informations IPTC/IIM sont toujours affichées.
L'édition du champ Category modifie uniquement les données IPTC/IIM et non son correspondant XMP photoshop:Category.
Photo Info propose deux champs qui ressemblent à de l'IPTC Core mais ne sont pas de l'IPTC Core; il s'agit des champ URL et Sublocation qui correspondent respectivement à CreatorContactInfo/CiUrlWork et à Location, mais selon un espace de nom erroné ('iptcCore' au lieu de
'http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/');
ces deux champs ne sont dons jamais affichés et éditables
de manière standard avec les éditeurs compatibles IPTC
Core.
En résumé
Les
errements de Microsoft concernant les techniques d'association des
métadonnées aux images conduisent à une situation
inextricable, incompatible avec les standards, et incohérente
entre les différentes plate-formes Windows. Pour associer des métadonnées aux images
JPEG/TIFF, nous recommandons
d'utiliser un véritable éditeur IPTC ou IPTC
Coreet rien
d'autre...
Vers
le Web sémantique [Semantic Web]
Note: Nous avons
ajouté cette courte section pour préciser le
contexte actuel des métadonnées sur le Web
Le Web sémantique
[Semantic Web]
est la vision d'un Web structuré de telle façon
que l'on puisse automatiser, intégrer et
réutiliser les données au travers d'applications
variées.
Pour une introduction aux concepts et techniques du Web
sémantique, lire l'article de Tim Berners-Lee, James Hendler
et Ora Lassila dans Scientific American (May 2001): The
Semantic Web .
Le site SemanticWeb.org
est également un bon point de départ.
Deux
technologies principales sont utilisées
dans les projets et les recherches liés au Web
sémantique:
RDF
(Ressource
Description Framework), technique générale de
description de ressources à l'aide de
métadonnées (que l'on peut comparer aux
mots-clés d'une fiche de catalogage)
Topic
Maps - une technique initialement SGML (ISO 1999) puis porté en
XML ( XTM
).
Les Topic Maps utilisent des réseaux sémantiques
(on peut les comparer grosso modo aux index,
glossaires, thesaurus d'un livre).
Il existe quelques applications basées sur Topic Maps: Mondeca
par exemple.
Comparaison
HTML/RDF/Topic Maps
- HTML relie des données de pages Web entre elles
- RDF relie des ressources quelconques entre elles, qu'elles soient des
données, des concepts ou des objets, basés ou non
sur le Web
- Topic Maps structure et organise des connaissances, associe des
sujets et des occurrences d'objets ou de concepts
Autres
techniques appartenant au champ du Semantic
Web - Ajouter un contenu sémantique à un site Web
à l'aide d'une technique d' Annotation
et d'"ontologies" - DAML+OIL
(DARPA Agent Markup Language + Ontology Inference Layer)
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
Experiencequi 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. RarissimoCompression, décompression automatique
de fichiers préservant les streams
et la structure spécifique des fichiers Macintosh
Quelques livres en anglais sur les
métadonnées:
Universal
Meta Data Models de David Marco et Michael Jennings Wiley (mars 2004) 478 pages Bk&CD-Rom
édition