Mais au delà, je me pose la question de la limite des CMS dans le contexte de la recherche par projets (c’est à dire avec des ruptures de charges). Les bibliothèques scientifiques, universitaires et de recherche devraient développer des structures de conservation des corpus numériques incluant, outre l’archivage pérenne des données, la conservation de la structuration intellectuelle du corpus (structuration des bases de données, manuels de saisie, publications associé aux données, schéma de métadonnées, etc.). Encore une fois, c’est par l’association des métiers et le passage de responsabilité entre les acteurs du domaine que la pérennité deviendra réelle.

Isidore est une plateforme de recherche permettant la recherche d’information dans les données numériques des SHS, quelles soient sources pour faire de la recherche ou bien publications des résultats de la recherche. J’ai le plaisir de co-diriger ce projet avec Jean-Luc Minel dans le cadre de l’équipe du Adonis, le très grand équipement du Centre national de la recherche scientifique.

Je profite de ce petit billet « auto-promotionnel » pour remercier Gautier Poupeau (alias Got) sans qui ce projet n’aurait pas pu être conçu et réalisé ainsi que toute l’équipe du centre pour la communication scientifique directe (Laurent Capelli, Philippe Correia, Loic Comparet, Yannick Barborini et Daniel Charnay) qui participe à ce beau projet.

Isidore moissonne des métadonnées et des données selon les protocoles OAI-PMH, des signalements d’actualités via RSS et Atom, des données structurées selon RDFa et peut se connecter à des catalogues de bibliothèques SRU/SRW (z3950). Isidore enrichit ces données en les croisant, en les qualifiant avec des thésaurii, des référentiels, des listes d’auteurs et les ré-exposent selon les principes du linked data. Pour utiliser ces données, un site web a été créé : www.rechercheisidore.fr. Vous pouvez donc interroger les articles de Revues.org, Cairn, Persée, les ouvrages, textes, images de Gallica, HALSHS, MédiHAL avec un seul formulaire et avec des liens entre toutes ces données.

Dans isidore, les métadonnées sont transformées en RDF, ainsi les données des shs entrent dans le web de données.

Mais nous sommes en version béta, alors le travail continu.

Stéphane.

Comment dépasser cela ?

Comment rendre plus accessible encore, non pas simplement les documents (au sens des fichiers) mais les informations contenues dans ces derniers sans appauvrir les formats de structuration de l’information. Comment se donner l’opportunité de construire des outils d’aide à la recherche permettant de construire – par exemple – la notice encyclopédique de George Duby, en présentant, non pas simplement la compilation du signalement de ses articles, ouvrages, conférences, mais aussi les thèmes qu’il a abordé au cours de sa carrière et en les reliant à des notions, des définitions, des illustrations, des ouvrages d’autres auteurs ? C’est tout l’enjeu de la construction du web de données, cette extension du web dont je parlais dans mon dernier billet. Il nous faut tout d’abord libérer les données après l’avoir fait avec les bases de données elles-même.

Comment faire ?

Tout d’abord un peu d’histoire. Dans les années 1995-2000, tous les acteurs de la recherche et de la culture ont massivement édité leurs bases de données sur le web, c’était l’enjeu du moment : tout le monde voulait mettre sa base en ligne, c’était un nouveau cycle dans la diffusion des documents (après le minitel, les connexions client/serveurs). Nous sommes entrés, depuis quelques années, dans un nouveau cycle dont la première phase (la première « marche » je préfère dire) a été l’interopérabilité des bases de données. En parallèle de cette phase, qui se poursuit, nous devons « ouvrir les données ». Quel curieuse expression ! Simplement, il s’agit d’exposer les données, dans toutes leurs complexités, en utilisant le cadre de la modélisation en RDF. Pour cela, il nous faut apprendre et développer des modèles de données, faire des choix de vocabulaires documentaires afin de décrire l’information contenue dans une page web, un billet de blog, un article, un inventaire de fonds d’archive, un corpus, un thésaurus ou encore une notice de bibliothèque. Pour ouvrir ces données il faut être capable de dire : « tiens ça, c’est le titre et ça là, c’est l’auteur et je te prouve que c’est bien l’auteur car je suis capable de le relier, par un principe ouvert, normalisé et connu de tous, à un référentiel (les auteurs du sudoc par exemple) et à une forme de vocabulaire (du mods, du dublin core simple, etc.) » : les documentalistes savent très bien faire cela. Ainsi, ouvrir ses données – participer à la construction du web de données – cela revient donc à structurer de l’information avec des règles communes, valables pour tout le monde du web et où donc l’implicite n’est pas le bienvenu. Ouvrir ses données au monde c’est donc vouloir diffuser les données et par uniquement les documents et surtout dire quel choix j’ai fais pour structurer l’information. Les documentalistes font (devraient) s’y régaler.

Avec l’aide de Got, je vais présenter un exemple simple. Il est possible d’exprimer selon RDF des données structurées dans une page web écrite en HTML : il s’agit de la syntaxe RDFa (pour Resource Description Framework – in – attributes). RDFa permet donc d’utiliser la mécanique du RDF tout en utilisant comme support les balises HTML.

Je prends comme exemple, très simple, une photographie et sa notice venant de MédiHAL, l’archive ouverte de photographies scientifiques que j’ai co-créé et qui est développée par le CCSD et le CN2SV. Au travers de cet exemple, je souhaite montrer qu’il ne s’agit pas que de techniques documentaires, ou que de questions informatiques, ou encore que de questions d’édition : non, il s’agit de tous cela en même temps. Ainsi, construire le web de données c’est avant tout réunir plusieurs compétences et métiers pour envisager toutes les aspects.

La consultation avec un simple navigateur web de la notice exemple ne révèle pas la présence d’une structuration de l’information selon les principes RDF et pourtant, si l’on regarde le code source, il y a une structuration, des vocabulaires RDF et des étiquettes structurant l’information. Ainsi, dans un premier temps, il faut dire que cette page contiendra du RDFa : j’ai modifié le doctype XHTML. Il est remplaçé par un doctype XHTML+RDFa :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">

Notez ensuite la présence de plusieurs vocabulaires documentaires qui vont nous permettre de structurer l’information :

<html xml:lang="fr" version="XHTML+RDFa 1.0"
        xmlns="http://www.w3.org/1999/xhtml"
        xmlns:foaf="http://xmlns.com/foaf/0.1/"
        xmlns:dc="http://purl.org/dc/elements/1.1/"
        xmlns:cc="http://creativecommons.org/ns#"
        xmlns:dcterms="http://purl.org/dc/terms/"
        xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
        xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema#">

Pourquoi ? Puisque nous allons structurer les données contenues dans cette page web, il nous faut dire « ça, c’est le titre » : il s’agit de mettre une « étiquette » à une chaine de caractère du titre. Il nous faut construire des triplets RDF qui, par l’utilisation de prédicats (verbe), relient l’étiquette (l’objet) à la chaine de caractère du titre (sujet). Puisque nous devons dire à quel vocabulaire nous faisons référence pour dire « c’est le titre », nous les déclarons en entête. Vous reconnaitrez sans doute « dc » pour le dublin core simple (dublin core elements set ou dces), « dcterms » pour le dublin core terms, « cc » pour signaler la présence de données sous licence creative commons, « geo » pour la géolocalisation GPS, « foaf » pour décrire le document qui est ici une notice MédiHAL, etc. Ainsi je déclare là l’ensemble des vocabulaires documentaires que je vais utiliser ensuite et j’en donne la référence en ligne : http://purl.org/dc/elements/1.1/ pour le dublin core simple. Ces référentiels sont eux-même décrits et structurés en RDF : ils sont utilisés par tous et sont donc le point de référence, la norme.

Je trouve ensuite le début de ma notice, qui est matérialisée par une balise <div>  :

<div typeof="foaf:Image" about="http://medihal.archives-ouvertes.fr/medihal-00501617">

Dans cette balise (fermante à la fin de ma notice), j’y mentionne que ce qui sera dans la balise <div> est une notice d’une image et que l’URL présente dans l’attribut « about » sera l’objet auquel se rapporte les informations que je vais structurer (donc ici, un conteneur, une notice, d’une image). Les informations décrites par la suite se rapportent à cette notice (rôle du « about »), ce conteneur, accessible à cette URL. Ma données est complexe, elle est composés d’une image (qui a plusieurs représentations : plusieurs vignettes, l’image déposée, etc.) et des métadonnées, voir des commentaires (publics, privés). Pour décrire ce conteneur, j’utilise le vocabulaire foaf qui permet de décrire des ressources, des personnes ou des institutions et je vais utiliser l’élément foaf:Image. Pour la syntaxe, je vous invite à lire ce billet de Got qui présente très en détail et très clairement la syntaxe des CURIEs (ou Compact URIs) dans le monde RDF.

Dans ce <div>, je vais pouvoir structurer l’information contenue dans la données en utilisant, dans cet exemple, la balise <span> ainsi que quelques attributs : « property » pour caractériser l’information avec un vocabulaire, « rel » pour relier de l’information directement au conteneur. Ainsi pour le titre de l’image, je vais utiliser le dublin core simple (dces), nous aurons :

<span property="dc:title">Madagascar : Vallée de l'Onive aux environs de Tsinjoarivo</span>

Pour l’image en jpg présentée dans la notice (qui est l’une des représentations possibles de l’image) :

<span rel="foaf:thumbnail" about="http://medihal.archives-ouvertes.fr/medihal-00501617">
<img title="Madagascar..." id="thumb320" src="http://medihal.archives-ouvertes.fr/docs/00/50/16/17/archives/thumb320.jpg" border="0" /></span>

Là, nous caractérisons que le contenu de <img/>, c’est à dire une image en 320 pixels, est l’une des versions de l’image de la notice représentée par «  http://medihal.archives-ouvertes.fr/medihal-00501617 » : il s’agit d’une vignette de l’image d’ou « foaf:thumbnail ». Dans ce cas, il possible d’implémenter les attributs rel et about dans la balise <img>. Je l’ai mis dans un <span> pour plus de clarté. Notez que j’ai répéré dans ce <span> l’attribut « about », je n’y suis pas obligé, il est déjà signalé dans la balise <span> « mère ». Ce <span> structurant une version de l’image (une vignette de 320px de coté), j’ai préféré ré-indiquer ce « about » afin que vous compreniez bien que foaf:thumbnail (vignette) désigne une vignette de l’image déposée et dont l’URI est http://medihal.archives-ouvertes.fr/medihal-00501617.

Pour la légende, je vais utiliser le vocabulaire dublin core terms, le plus riche des dublin core avec l’étiquette dc:abstract (pour résumé) :

<span property="dcterms:abstract">Paysage rural de collines à proximité de Tsinjoarivo ; Au premier plan le bord de la terrasse de la vallée de l'Onive ; A l'arrière-plan, cultures en terrasse avec des rizières en escaliers, irriguées par un affluent du fleuve</span>

Je pourrais aussi, plus simplement mais en introduisant un peu d’implicite, utiliser dces avec l’étiquette dc:description :

<span property="dc:description">Paysage rural de collines à proximité de Tsinjoarivo ; Au premier plan le bord de la terrasse de la vallée de l'Onive ; A l'arrière-plan, cultures en terrasse avec des rizières en escaliers, irriguées par un affluent du fleuve</span>

Pour exprimer les mots clés, je vais utiliser une nouvelle fois le dces :

<span property="dc:subject"><a href="[lien vers mes mots-clés]">Madagascar</a></span>

Il est possibilité là aussi d’être plus riche, en reliant mon mot-clés à un référentiel (thésaurus par exemple) en utilisant les vocabulaires sioc et skos pour exprimer des concepts et les liaisons.

Pour la géolocalisation de mon image, je vais utiliser le dublin core terms avec l’étiquette « spacial », qui va me permettre de relier mon conteneur (foaf:Image) à des valeurs de latitude et de longitude. Ainsi, j’exprime dans dcterms:spatial une latitude et une longitude issues d’un GPS ou d’une géolocalisation en spécifiant que je fais référence au vocabulaire WGS validé par le W3C (geo:lat et geo:long).

<span rel="dcterms:spatial">
<span property="geo:lat" content="-19.644527589975"></span>
<span property="geo:long" content="47.709846500067"></span>
</span>

Je me limite ici à quelques éléments de cette image (en prenant du DC simple pour être pédagogique), il est possible d’aller plus loin dans la structuration (en utilisant du DC terms ou d’autres vocalulaires).

Conclusion

Le web de données est une méthode qui consiste à utiliser le web comme un espace ou les données sont structurées : c’est à dire que l’information d’un document (pdf, jpg, txt, etc.) est cartographiée, repérée, signalée et reliée à des vocabulaires, accessibles eux-même sur le web et dont la structuration est connue et explicitée. C’est un formidable enjeux pour les documentalistes, les bibliothèques et les ingénieurs et techniciens en digital humanities qui construisent des corpus scientifiques et les diffusent en ligne. Le RDFa est l’une des techniques, l’une des mécaniques possible et elle est relativement simple à comprendre car elle s’inscrit dans une évolution naturelle des choses : une sémantisation de la page web via le code HTML. Il s’agit d’une révolution mais qui s’appuie sur des éléments que tout les professionnels de l’IST peuvent maitriser. J’ai toujours pensé et dit que l’OAI-PMH était (est) la première marche vers le web de données, je pense qu’RDFa est la deuxième, du moins c’est un pont très simple pour mieux comprendre RDF et les techniques du web de données.

Stéphane.

Liens utiles pour aller plus loin :

• Exemple utilisé : http://www.stephanepouyllau.org/webdedonnees/medihal/rdfa/
• Code source : http://www.stephanepouyllau.org/webdedonnees/medihal/rdfa/medihal-rdfa.txt
• Une vue sur le contenu RDFa de cet exemple.
• Comprendre RDF : http://www.lespetitescases.net/comprendre-rdf-en-moins-de-5-minutes
• Mettre du RDFa dans son blog : http://www.lespetitescases.net/rdfaiser-votre-blog-1-la-theorie ; http://www.lespetitescases.net/rdfaiser-votre-blog-2-la-pratique ; http://www.lespetitescases.net/rdfaiser-votre-blog-3-exploitation
• Vidéo de l’ADBS : Le Web de données : perspectives pour les métiers de l’information documentation

Ces réservoirs existent aujourd’hui dans les laboratoires de SHS, mais les données qu’ils contiennent sont souvent encore perçues comme des données « privés », réservées aux chercheurs locaux. Il est vrai qu’ils les ont collectées ou générées et ce travail n’est pas réellement reconnu dans le parcours d’un chercheur alors qu’il est fondamental. Ces données « pour la recherche » ont donc souvent tendance à « mourir » au fond de nos disques durs faut d’une infrastructure double : archivage des données (pour l’histoire), diffusion des données « brutes » et pas forcement éditorialisées dans une publication électronique académique mais mise à disposition de la communauté scientifique comportant un minimum d’appareil éditorial basé sur le Dublin Core Terms par exemple.  D’autant que souvent, ces données ont été collectées ou générées sur fonds publics (ne serait ce que le salaire du chercheur).

Bien sur, il faut pondérer ici le fait que certaines données sont sensibles de part leur nature et que la mise à disposition ou la diffusion est complexe et nécessite des barrières mobiles parfois très longues.

En france, il existe des initiatives intéressantes, encore trop peu soutenues financièrement, mais cela avance, cela se structure et des formations, pour les chercheurs et enseignants-chercheurs, voient le jour tel que l’université d’été de l’édition scientifique ouverte, qui aura lieu en septembre 2009, ou bien l’école thématique des centres nationaux de ressources numériques du CNRS dont le wiki est en ligne avec toutes les communications, les bibliographies numériques, en ligne, etc.

Alors, en ce mois de juillet, j’ai envie de dire : « ouvrez vos données à vos collègues et au monde » et j’espère aussi, soyons fou, un donnees.gouv.fr ?

Il est temps, dirons certains, que je parte en vacances.

Stéphane.

J’ai donc un GPS pour mon D90 : il s’agit de l’unité GP-1, qui se place à la place du flash ou sur le coté. Pour info, dans le Nikon P.6000, un compact, le GPS est en standard.

Mes grands-parents, s’ils étaient en vie, diraient : « Mais que fait Stéphane, dans le jardin, avec un appareil photographique pointant vers le ciel ? » Au début, la première capture des satellites est un peu longue : plus de 5 s., c’est déjà embêtant si vous devez déclencher tout de suite… passons. En laissant l’appareil en veille, ça va mieux. Ensuite cela semble assez précis (même dans le jardin), l’altitude aussi (testé avec un bon vieil altimètre).

Clic-clac, les coordonnées et l’altitude sont bien capturées et incluses dans les méta-données EXIF de l’image. Avec Exiftool (et tous les outils qui tourne autour), par exemple, il est facile de voir et d’exporter ces valeurs de positionnement (extrait) dans ExiftoolGUI…

De les sortir sous la forme d’un tableau HTML (voir plus bas)…

…Et bien entendu, il est très facile d’exploiter cela avec un outil cartographique en local, tel que l’excellent GeoSetter dont une version en français est disponible :

ou bien via l’outil carte de Flickr (là, rien à faire de particulier, les photos sont positionnées par défaut lors du chargement).

Tout cela peut aussi ce faire via son Firefox avec IExif, Dans la monde Google avec Picasa et Google Earth, etc.

Si le format EXIF vous pose un problème, il est possible de stocker ces données dans du MIX. C’est évidement plus complexe pour l’exploitation, du moins pour le grand public.

Extraire ce type de méta-données avec du Perl est très facile : le programme perl exiftool de Phil Harvey est très bien pour cela : une petit ligne du type « Exiftool -exif:GPSAltitude -h  img > mes_exifs.html » et l’on récupère l’altitude d’une série d’images dans un tableau HTML.

Avec du PHP c’est possible aussi : il faut charger les extensions php_mbstring et exif (dans cet ordre) dans le php.ini ; ensuite il est possible d’utiliser la fonction exif_read_data.

Bref, bientôt TOUS les appareils géo-tagueront en automatique et l’on ne comprendra pas pourquoi les photos anciennes ne le sont pas (les documentalistes vont avoir du travail) : ainsi les interfaces d’intérogations vont évoluer : un fond de carte, des outils de sélection (ronds, carrés, etc.), des plots de couleurs, des requêtes externes, des réponses aux questions qui s’afficheront sous la forme d’un chapelet de marqueurs. Au CN2SV, nous avons commencé à le faire des cartes et des atlas anciens, j’imagine ce que nous allons faire dans quelques années !

Mais j’y pense… le temps d’écrire ce billet et tout cela doit déjà exister, j’en suis sûr (et en open-source ?). En attendant la suite, j’espère que les artistes vont trouver des applications moins « utiles » que celles décrites ici. Je m’en retourne à mon mash-up de noël.

Joyeuses fêtes,

Stéphane.

Bonjour,

La technologie Context Objects in Span (COinS) permet d’ajouter dans une page web (billets de blog, résultats d’une recherche documentaire, liste de références bibliographiques) des méta-informations encodées selon la norme OpenURL. Cette technologie est déjà là depuis un petit moment, le figoblog en parlait déjà en décembre 2006, mais sa démocratisation prendra du temps comme toujours : j’y consacre à mon tour un billet.

Cela fonctionne par l’ajout d’une balise <span> contenant une classe et un titre contenant des informations descriptives du contenu publié en ligne : des méta-données. Il est possible de préparer cette balise span un peu spéciale à l’aide d’outils en ligne à base de formulaires, mais il est plus judicieux, pour les blogs, d’utiliser des modules qui font cela automatiquement : c’est le cas pour le moteur WordPress. Mon blog en est d’ailleurs maintenant équipé. Cela permet, par exemple, pour ceux qui utilisent le gestionnaire de références bibliographiques Zotero de capturer les méta-données (titre, dates, auteurs, etc.) d’un billet de blog ou d’une page web. De nombreux catalogues de références bibliographique utilisent cela : le Sudoc, Amazon, ou encore les blogs du portail Hypotheses.org.

La définition du système COinS est claire :

« The goal is to embed citation metadata into html in such a way that processing agents can discover, process and make use of the metadata. Since an important use of this metadata will be to allow processing agents to make OpenURL hyperlinks for users in libraries (latent OpenURL), the method must allow the metadata to be placed any where in HTML that a link might appear. In the absence of some metadata-aware agent, the embedded metadata must be invisible to the user and innocuous with respect to HTML markup. To meet these requirements, the span element was selected. The NISO OpenURL ContextObject is selected as the specific metadata package. The resulting specification is named « ContextObject in SPAN » or COinS for short. » (source : http://ocoins.info).

Une fois encore, un peu comme avec l’IPTC Core pour les images, il s’agit d’embarquer (embed) des méta-données au sein même de la page web qui contient l’information dans un format ouvert et surtout contextuel : OpenURL.

Le span ressemble à cela : [span class="Z3988" title="ctx_ver=Z39.88-2004&
amp;rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Adc&r
fr_id=info%3Asid%2Focoins.info%3Agenerator&r
ft.title=La+d%C3%A9mocratisation+du+XML+documentaire&r
ft.aulast=POUYLLAU&rft.aufirst=St%C3%A9phane&r
ft.subject=IT&rft.source=sp.Blog&rft.date=2008-05-18&r
ft.type=blogPost&rft.format=text&r
ft.identifier=http://blog.stephanepouyllau.org/la-democratisation-du-xml-documentaire&rf
t.language=French"]

A voir comme cela c’est un peu complexe, mais il s’agit bien de méta-données, proche du DublinCore d’ailleurs, encapsulées dans une balise <span>.

COinS est une technologie qui permet une utilisation simple, pour l’internaute, des e-références : les méta-données. COinS, couplé avec un outil tel que Zotero, peut rendre plus simple la collecte de références bibliographiques disponibles sur le web. Mieux, utilisée dans les blogs, elle les transforme en réservoirs d’informations…

Bon dimanche,

Stéphane.

Photo sous licence CC par jen-the-librarian.

Encapsuler [ãkapsyle] v.tr. – 1889, Renan, au fig. ; de en-, et capsule. Techn. Enfermer dans un capsule [...].

Le fait « d’enfermer » doit attirer l’attention du fournisseur de ressources visuelles (photographiques dans notre exemple) sur la possibilité de « libérer » les méta-données ainsi encapsulés. C’est à dire de pouvoir dans le futur les lire, les exploiter en même temps que l’image, sans avoir de contraintes.
Il est important de ne s’appuyer que sur normes libres (si possible, attention XMP est fortement lié à Adobe Inc. alors que l’IPTC Core est développé par International Press and Telecommunications Council (1965) et succède à l’IPTC « classique »), internationnales et reconnues par les professionels de l’information (iconographes, documentalistes, etc).
Avec un outil simple, tel que PixVue (voir ci-dessus), il est facile à l’aide de la souris et du clavier d’ajouter des « méta » dans une image suivant la norme IPTC.

Bonne fin de semaine,

Stéphane.

Dans le développement du CN2SV, j’ai programmé un parser XMP, IPTC à partir de la librairie « PHP JPEG Metadata Toolkit » de E. Hunter. Le schéma XMP est prometteur même s’il est lié à Adobe. Mais la programmation d’un programme en php lisant les méta-données IPTC est facile et la technologie est mure aujourd’hui. L’IPTC a adopté XMP comme schéma de la toute dernière version de son standard de description des photographies : IPTC Core (http://www.iptc.org/IPTC4XMP/). Avec l’utilisation massive des appareils photos numériques, qui truffent leurs images de méta-données, il est temps d’offrir aux utilisateurs d’intergiciel (middlewares) en php, jsp, java, asp, la possibilité de lire ces données et de les enrichir.

Un simple parseur IPTC en PHP (PHP 3 >= 3.0.6, PHP 4, PHP 5) :

 function output_iptc_data( $image_path ) {
   $size = getimagesize ( $image_path, $info);
    if(is_array($info)) {
     $iptc = iptcparse($info["APP13"]);
     foreach (array_keys($iptc) as $s) {
     $c = count ($iptc[$s]);
      for ($i=0; $i <$c; $i++) {
       echo $s.' = '.$iptc[$s][$i].' - ';
      }
     }
    }
  }

(source : site www.php.net)

Nous allons intégrer un lecteur/editeur IPTC/XMP à Iceberg. Je tiens d’ailleurs à remercier Romain et Frédéric, les deux développeurs contractuels du CN2SV qui font un travail formidable.

A bientôt,
Stéphane.

« IPTC Core » est la propriété intellectuelle de IPTC. XMP, Photoshop and Creative Suite (CS) sont des marques commerciales de la société Adobe Systems Inc.