RDF vs XML : illustration avec SKOS vs MarcXML
Comme prévu, je continue d’exploiter IdRef pour illustrer un peu les problématiques liées au RDF, et ce qu’il apporte en comparaison d’autres solutions.
Comme quelqu’un (pas ici, rassurez-vous !) m’a demandé si RDF était censé à terme remplacer les bases de données relationnelles, ou le XML « classique » en général, j’en profite pour le rappeler ici : le RDF est fait pour préserver la restitution de la structure des données une fois publiées sur le web. Cela n’aurait pas grand sens de stocker des données en RDF afin de les exploiter pour soi-même. Le RDF est conçu comme une alternative structurée aux pages web qui affichent joliment vos données sur une requête dans un formulaire renseigné par l’internaute. Mais ce n’est pas un format de stockage.
C’est une réponse un peu sommaire, mais je l’espère claire tout de même.
Romain Gary en MarcXML
Revenons donc à la notice d’autorité Romain Gary en MarcXML. J’espère que même si vous êtes plus habitué à une grille de catalogage tabulée qu’à un affichage Marc sous forme XML, vous y retrouverez la logique :
Ainsi le noeud
<datafield tag="901" ind1=" " ind2=" "><subfield code="a">Kacew, Roman</subfield></datafield>
Correspond dans une grille Marc à un affichage
901 $aKacew, Roman
Le format XML, structuré, permet de cette notice des récupérations et retraitements par une machine qui passerait par là. A condition qu’elle sache où chercher !
Spontanément ou presque, vous êtes capable de comprendre que ce nœud <datafield tag= »901″> désigne une forme rejetée. Mais la machine qui ouvrirait ce fichier
- ne le sait pas a priori
- n’a aucun moyen de le savoir : aucun renvoi n’est fait au format Marc auquel se réfère le fichier
Il faut ainsi avoir conscience que les développeurs Zotero essaient en ce moment-même (à l’heure où je vous parle !) de trouver de meilleures manières de distinguer un format Unimarc d’un format Marc21 : en effet les deux coexistent sur le web, dans les opac, et les notices ne se déclarent jamais comme étant l’une ou l’autre. Dans un cas le titre est en 200$a, dans l’autre il est en 245$a.
Et ici, pour une notice d’autorité, le sens de chacun des champs est encore différent. - Même si la machine « savait » que le champ 901$a contient une forme rejetée, rien ne lui permet de remonter aisément à la forme retenue, non plus qu’à l’identifiant unique de cette forme retenue. Dans le cas présent, la forme retenue est : Gary, Romain (1914-1980), et l’identifiant unique est : 026882949, ou mieux : http://www.idref.fr/026882949.
J’en profite pour vous signaler que le 2 décembre, il faudra penser à commémorer les trente ans de sa mort. Paix à son âme torturée !
Conclusion sur le MarcXML
Le MarcXML, c’est très bien, mais l’information qui y est contenue
- n’est pas autodocumentée (il faut que le programmeur indique d’emblée à la machine quelles informations récupérées — donc il a besoin de savoir ce qu’elle va trouver)
- est contextuelle au nœud XML rencontré
Ici, en trouvant un champ 901 (ou plutôt : un nœud <datafield> dont l’attribut tag a pour valeur 901), pour savoir à quoi il se rapporte le robot qui a ouvert le fichier doit remonter dans l’arborescence pour retrouver un noeud <datafield> de même niveau dont l’attribut tag a pour valeur 001 : il aura ainsi l’identifiant, et le <datafield> dont l’attribut tag a pour valeur 900 : il aura ainsi la forme retenue.
L’information n’est donc valable et exploitable qu’au sein du fichier XML qui l’abrite.
Sur la manière dont je viens de décrire la navigation dans le fichier XML, je vous renvoie aux billets sur XSL concernant la notion d’arborescence de ces fichiers.
Voici le fichier (simplifié à l’extrême : ne restent que les champs 001, 900 et 901) tel que le voit le parseur XML
Et voici ce que le parseur doit faire pour compléter l’information trouvée dans le champ 901 afin de lui donner un sens
Le cheminement n’est pas complexe en soi : il nécessite surtout une bonne connaissance du format de la notice, format qui n’est pas pas documenté au sein de la notice elle-même.
La même, mais en RDF
Suivons le même chemin que décrit précédemment (après avoir installé l’extension Semantic Radar) : à partir de la notice d’autorité, je rebondis vers le browser SIOC qui m’affiche la notice RDF avec une indentation permettant d’en comprendre mieux la structure. De là je suis le lien « Validate RDF » pour afficher les triplets exprimés par ce fichier RDF.
J’y apprends que la ressource http://www.idref.fr/026882949/id est liée à la chaîne de caractère « Kacew, Roman » par la relation http://www.w3.org/2004/02/skos/core#altLabel
Et je peux suivre le premier lien, pour y retrouver une description sur sa nature : c’est une notice d’autorité pour une personne physique. Et cette notice d’autorité une relation de type « prefLabel » avec la chaîne de caractères « Gary, Romain (1914-1980) »
Et si le moteur a besoin de savoir ce que sont un prefLabel ou un altLabel, il peut suivre les liens : il tombera sur leur description au sein de l’ontologie SKOS, qui sert à décrire le type de relations qu’on trouve dans des thésaurus.
Conclusion
L’objectif n’est pas de déterminer si MarcXML est mieux ou moins bien que RDF. Ce genre de problématique n’a pas de sens : les usages en sont simplement différents.
Mais il est évident que RDF est bien meilleur pour exposer ses données, puisque elles restent ainsi structurées d’une part (mais en MarcXML aussi) et autodocumentées.
En outre tout triplet est en quelque sorte autosuffisant : transporté dans n’importe quel fichier, indépendamment de celui où on l’a trouvé, il reste toujours vrai. Alors que le noeud
<datafield tag="901" ind1=" " ind2=" "><subfield code="a">Kacew, Roman</subfield></datafield>
n’est vrai qu’au sein du fichier XML initial.
Trackbacks
- Tweets that mention RDF vs XML : illustration avec SKOS vs MarcXML « Bibliothèques [reloaded] -- Topsy.com
- Toi aussi, joue avec une ontologie « Bibliothèques [reloaded]
Commentaires fermés
Bibliothèques [reloaded] 
Lecteur assidu, je perpétue la jeune tradition de commenter tes billets récents.
Les connaisseurs d’UNIMARC s’étonneront à raison de ces zones 9XX qu’on trouve à la fin des notices UNIMARC proposées par http://www.idref. Par exemple dans http://www.idref.fr/026882949.xml .
Ces zones ne font ni partie de l’UNIMARC standard, ni du dialecte UNIMARC utilisé dans le réseau Sudoc.
Nous avons ajouté ces zones 9XX pour aider ceux qui souhaitent exploiter nos notices. Par exemple, la 900 contient la forme retenue construite, avec toute la ponctuation avec tout ce qu’il faut là où il faut (« Gary, Romain (1914-1980) »), ce qui dispense les utilisateurs de reconstituer eux-mêmes cette expression à partir des différentes sous-zones du 200.
Pour un mortel ordinaire, la forme retenue n’est pas bien compliquée à reconstituer, pour les rois, les saints, les collectivités, cela peut être fastidieux.
Ouvrir des données, c’est un service, pas un produit brut. Le service peut être plus ou moins étoffé et adapté aux besoins des « consommateurs ». Mais, dans le contexte du Web, on ne sait pas qui sont ces « consommateurs », ni a fortiori quels sont leurs besoins. Il faut donc essayer de multiplier les approches.
@071625348 : Effectivement je ne me suis même pas attardé sur la raison d’être de champs 9XX. Merci de le signaler, car sans aller jusqu’à écrire que ces champs 900 et 901 sont conformes à l’Unimarc pour les notices d’autorité, je ne relève nulle part la bizarrerie de la chose.
Tu auras remarqué aussi que pour avoir accès au XML, j’ai dû passer par une requête sur le PPN (donc une liste de résultats à un seul résultat), car dans l’affichage de la notice détaillée elle-même, aucun lien n’est fourni vers le format XML : je découvre grâce à toi la structure de l’URL du type http://www.idref.fr/026882949.xml. Voilà qui va me simplifier la vie !
Ce doc t’avait peut-être échappé : http://www.slideshare.net/abesweb/idref-services-autou
Ce doc est à destination des applications susceptibles d’utiliser IdRef, moins des particuliers.
Mais, à terme, elle rejoindra la doc générale d’IdRef, comme la doc sur les Web services.
@071625348 : Indeed !
Tout d’abord, un petit mot pour te remercier et te féliciter pour cette série de billets très utile pour s’approprier les difficiles principes sous-jacents aux technologies du Web sémantique et t’encourager à la poursuivre.
Comme promis sur Twitter, passons maintenant aux points de désaccord, en particulier ce deuxième paragraphe qui, s’il était juste, me ferait pointer au chômage demain matin 😉
A force de parler de Web de données, on en oublierai presque les principes de base des technologies du Web sémantique et ses objectifs. Elles offrent un cadre d’interopérabilité pour traiter, échanger, interroger, exploiter, stocker des données structurées dans le contexte décentralisé du réseau. L’exposition auquelle tu fais allusion est effectivement un des objectifs (mais pas le seul), certes pas le moindre en termes stratégiques, mais pas le plus intéressant du point de vue technologique.
A la base de toutes ces technologies, on trouve le RDF, qui n’est pas un format mais un modèle basé sur les principes des graphes et des triplets. Le RDF/XML que tu présentes n’en est qu’une syntaxe, une représentation. Or, ce graphe présente justement de très nombreux avantages sur les bases de données relationnelles (cf ma présentation : Limites du modèle relationnel et Web sémantique ) et sur le XML en tant que modèle, c’est-à-dire l’arbre (cf Retour sur un des articles de Roger T. Pédauque ; Les carcans de la pensée hiérarchique et documentaire et XML vs RDF : logique structurelle contre logique des données dans l’ordre du plus ancien au plus récent). Il ne s’agit évidemment pas de jeter une technologie dans son ensemble au profit d’une autre, mais chacune présente des forces et des limites et il faut les connaître pour les utiliser à bon escient. En l’occurrence, le RDF présente de nombreux avantages pour exprimer, traiter et interroger des métadonnées (qui ne sont que des données structurées) et tu en montres très bien certains dans ton billet. Donc, oui, dans ce cas, cela a un sens de déterminer que MarcXML est moins bien que RDF (en l’occurence déterminer si XML est un bon modèle pour exprimer des métadonnées, donc exprimer une logique et un sens sur des données), je ne vois pas en quoi les usages seraient différents, ce n’est qu’une question d’habitude et d’implémentation.
Sur la question du stockage de RDF, au contraire de XML dont le stockage et l’interrogation s’est révélé très complexe (Xquery est une horreur tant sur la syntaxe, sur son intérêt que sur la problématique des performances), il existe beaucoup d’avantages à stocker du RDF (sa souplesse et le modèle de graphe en lui-même), tout d’abord pour pouvoir l’interroger en SPARQL, le langage de requêtes de RDF, ce n’est pas par hasard que la problématique des triple/quad store fait partie de la stratégie de nombreux fournisseurs de SGBD (Oracle en tête, mais pas uniquement, cf le groupe de travail RDB2RDF au W3C), mais aussi pouvoir exploiter pleinement les graphes RDF, il faut bien un moment ou un autre les rassembler. Ainsi, je n’aurais pu mettre au point les mashups que je propose sur mon site si le stockage de RDF n’avait pas d’intérêt. Si ton propos était de penser qu’il n’avait pas d’intérêt de le stocker nativement, là aussi, je pense que tu te trompes, tu ne profites pleinement d’une technologie comme RDF que si tes données sont nativement pensées en RDF. Si tu n’es toujours pas convaincu, je t’invite à lire cet article de deux tes confrères, Sébastien Peyrard et Louise Fauduet, qui explique comment sont utilisés les technologies du Web sémantique (RDF et SPARQL) dans SPAR, le système OAIS de la BnF, tu t’apercevras que les avantages principaux sont justement les possibilités d’interrogation et le stockage natif et en aucun cas l’exposition (qui n’a pas de sens dans ce projet).
@Got : Merci d’avoir pris le temps de commenter aussi longuement.
Je serai forcément moins disert, du moins pour l’instant, étant donné que pour te répondre il me faudra passer par les lectures que tu cites. C’est promis, j’y passerai 🙂
En outre, j’ai l’impression qu’il me faudra passer par un apprentissage (ou au moins une « observation ») de SPARQL et de ses possibilités.
Avant cela, il est clair (au regard de ce que tu dis) que ma phrase : « Cela n’aurait pas grand sens de stocker des données en RDF afin de les exploiter pour soi-même » est extrêmement risquée puisque je n’ai pas essayé moi-même de stocker de telles données pour voir ce que j’arrivais à en faire dans ce cas.
Néanmoins, voici les raisons de mon raisonnement :
1. Le modèle RDF (au passage, je n’ai pas parlé de « format RDF » dans mon billet ! mais je reconnais que j’ai des difficultés récurrentes à trouver les expressions correctes) a été conçu pour « libérer des données » préexistantes, stockées selon des formats spécifiques.
L’idée était de dire : peu importe la manière dont vous les stockez, il faut les rendre visibles de cette manière-là pour qu’on puisse les réexploiter nous aussi.
Donc c’est bien la mission première du RDF que d’être un modèle pour proposer un format d’exposition/publication.
2. Ensuite je reste illuminé par une phrase entendue à l’Enssib dans la bouche du regretté Pierre-Yves Duchemin, expliquant : « Le format Marc est un format de saisie, l’iso2709 est un format d’échange » (il avait ajouté quelque chose comme : « la manière réelle dont les données sont effectivement stockées dans la base d’un SIGB, on s’en fout un peu, tant qu’il permet de cataloguer en Marc et d’importer/exporter en iso2709″).
Phrases dont je n’avais rien compris sur le coup et qui me semble évidentes aujourd’hui.
Depuis je suis resté extrêmement sensible à cette distinction nécessaire entre certains formats qui sont faits pour certains usages, et d’autres… pour d’autres.
Ainsi, le format EAD me semble bien plus un format d’échange qu’un format de saisie et d’encodage. Rédiger des inventaires d’archives directement en EAD… Bref #pauvresarchivistes
3. Enfin mon expérience du XML et du pitoyable XQuery (en passant par eXist, base nativement en XML) m’a appris à me méfier, pour causes de performances, des langages verbeux.
Et le RDF/XML, je trouve, est très verbeux. C’est pourquoi tu m’étonnes beaucoup en opposant une base XML et une base de triplets : je m’étais persuadé (tout seul) que c’était forcément contre-performant (pour les performances, càd essentiellement les temps de réponses).
Mais bon, je reconnais qu’il y a beaucoup de choses que je m’efforce de comprendre tout seul. Et pour certaines je tombe à côté. N’empêche, ça marche pour pas mal de trucs aussi, alors je crois que je vais continuer — quitte à mériter d’autres commentaires du même genre, de ta part ou d’autrui 🙂
Tiens, finalement j’ai été très long !
« Et le RDF/XML, je trouve, est très verbeux. »
Ah oui, ça c’est vrai alors. A ma connaissance y a que Got qui trouve que RDF/XML est la syntaxe de RDF la plus agréable à lire 😉
Mais comme dit, RDF/XML n’est qu’une des syntaxes possibles de RDF. Les syntaxes de type N3 ou Turtle sont quand même plus faciles à lire (pour les humains).
Excuse j’avais pas fini mon commentaire.
Donc et pour les machines, elles ont aussi des moyens de manipuler les données sous forme de triplets, dans des bases ad hoc (triple store) et pas en XML.
XML reste en général pratique comme format d’échange (y compris RDF/XML).
Donc quand Got parle de stocker le RDF, il ne s’agit pas de stocker du RDF/XML mais de stocker des triplets dans une architecture appropriée qui pose *moins* de problèmes de performance (je voudrais bien écrire pas du tout, mais mon honnêteté intellectuelle me l’interdit pour l’instant…)
j’ai bien aimé ce beau travail de présentation et de comparaison des divers formats, franchement c’est bien!