RDFAoût, votre feuilleton de l'été : pendant un mois, 2 billets par semaine sur le RDFa, à l'attention des lecteurs connaissant déjà le HTML
- Épisode 1 : Au commencement était l'URI
- Épisode 2 : Des triplets partout
- Épisode 3 : Soyez brefs
- Épisode 4 : De vieilles connaissances (1)
- Épisode 5 : De vieilles connaissances (2)
- Épisode 6 : Organiser la connaissance
- Épisode 7 : Contenants, contenus et auteurs
- Épisode 8 : Succès et limites
Notions abordées dans ce billet : URI/URL, ressource, représentation, HTML, déréférencement, HTTP GET...
Les URI : le système d'identification du Web
Vous connaissez les URI (ou les URL, considérons que c'est la même chose) et vous savez qu'il s'agit des adresses des pages Web que vous créez et que vous consultez. C'est juste... le plus souvent.
Les URI sont des noms. Et comme il a suffit à Yehudah-Leib de nommer le Golem avec un mot sacré pour le doter d'une existence dans notre Monde, vous pouvez nommer toute chose avec un URI pour lui donner une existence sur le Web.
Tout ce qui est sur le Web a un URI, tout ce qui a un URI est sur le Web. Ce "tout", ce sont les ressources.
En plus de l'identification d'une ressource, un URI peut aussi permettre d'obtenir un document (en HTML, le plus souvent) représentant cette ressource, en le saisissant dans un navigateur Web, par exemple.
Obtenir ainsi une représentation d'une ressource s'appelle le déréférencement, on dit alors que l'URI est déréférençable, ce qui n'est pas le cas de toutes.
Les URI dans le HTML
Si vous connaissez le XHTML, vous n'aurez aucun mal à lire cette portion de code :
<p><a href="http://twitter.com/carlomorelli/status/12185847600">Bon séjour à Milan, Carlo !</a></p>
Dans cet exemple très simple, on observe deux URI. Comme rien ne différencie une URI déréférençable d'une qui ne l'est pas, seul le contexte nous permet de faire des suppositions. Et seule une analyse du résultat d'une requête HTTP GET pourrait nous permettre de transformer ces suppositions en certitudes.
Observons le contexte :
- Le premier URI est contenu dans un attribut @xmlns, on sait donc qu'il identifie le XHTML comme étant le langage utilisé pour coder le document. C'est tout. Il n'invite pas consulter un document éventuellement accessible à cette adresse. On peut même supposer que ce document n'existe pas (en fait, il existe, mais chut !).
- Le deuxième URI est contenu dans un attribut @href et est l'identifiant d'un billet de microblog de Carlo. On se doute donc qu'il est possible d'obtenir le contenu de ce billet. D'ailleurs, le navigateur Web lui même s'en doute aussi et affichera le contenu de a@href comme un lien cliquable.
Il faut donc avoir une certaine connaissance du langage utilisant les URI pour faire de telles suppositions.
Un contexte décisif mais pas toujours évident
Tous les contextes ne sont pas aussi clairs. Prenons l'exemple d'une citation en HTML, codée à l'aide de l'élément Q et de l'attribut @cite :
<p><q cite="https://twitter.com/carlomorelli19/status/12185847600">Quiksilver Italy, here i come. Heading to Milano...</q></p>
Pouvons-nous affirmer que cette URI est déréférençable ou pas ? Non. Dans ce cas précis, nous pouvons faire une supposition, car nous connaissons Twitter, mais ce n'est pas systématique. D'ailleurs, les navigateurs ne proposent pas d'interaction par défaut avec les URI présentes dans les attributs @cite.
Et si on veut indiquer que l'on parle d'une ressource, sans la pointer et sans la citer, voici ce que l'on peut écrire :
<p about="https://twitter.com/carlomorelli19/12185847600">Carlo annonce son départ pour l'Italie.</p>
L'attribut @about n'existe pas en HTML. Il fait en effet partie des ajouts de RDFa.
Du RDFa ? Le mot est dit, nous y sommes... presque ! Car pour être face à du RDFa, cet attribut ne suffit pas, nous devons avoir un triplet.
Un triplet ? La suite au prochain épisode.