Got lance une suite de billets sur RDFa, où il explique d’abord ce que c’est puis comment le mettre en pratique. À la fin de la première partie présentation, un paragraphe rejoint ma principale préoccupation sur le sujet :
Mais, je vous vois venir. Vous allez me répondre que c'est très joli, mais que la syntaxe est tout de même un poil complexe. Je ne peux pas vous donner tort. Mais, entre nous, n'est-ce-pas le but du Web dynamique et des CMS de générer le code HTML ? Toutes les données d'un CMS ne sont-elles pas parfaitement structurées dans une base de données ?
Je suis parfaitement d’accord avec lui. Allons même plus loin : le but de
RDFa est de permettre l'extraction de donnée d’un document HTML, pour
fournir normalement des données au format RDF. Très
bonne idée… Mais Got et moi sommes d'accord, c'est à un programme de rajouter
ces informations. Et s’il doit le faire, pourquoi ne pas le faire directement
au format RDF ? La réponse usuelle, c’est que justement, on ne peut pas
embarquer facilement le RDF dans du HTML. C’est vrai
mais il est également vrai qu'avec HTTP, le
client peut demander au serveur le format qu’il préfère (en précisant le format
désiré dans le champ Accept, d'une requête). Ainsi,
un serveur pourrait fournir pour une même page, soit les données au format
HTML, soit les données au format RDF, soit
dans tout autre format, y compris du HTML avec du RDFa dedans (beurk).
Quelle différence ? Peu et beaucoup à la fois. Tout d’abord, on évite d’alourdir le document de base. Certes, ce n’est que quelques données supplémentaires, mais ce raisonnement vaut pour plein de choses : javascript, feuilles de style, pour tout cela, la séparation est préférable, pourquoi les données sémantiques devraient elles avoir un traitement particulier ? Ensuite, on évite de se mordre la queue : RDF fournit des informations sémantique d’un document HTML qui contient des informations sémantiques au format RDFa. Cette phrase vous semble redondante et absurde ? C’est que vous devriez également trouver RDFa absurde.