Qu’est-ce qu’une « URI déréférençable » ?

Manue vient de publier quelques bons billets suite à sa participation à la 7ième conférence internationale sur le web sémantique (ISWC 2008).

Dans un de ces billets, intitulé ISWC 2008 (3) – être visible sur le Web : linked data, elle rappelle une règle de base pour publier ses données en RDF sur Linked Data :

Une consigne de base : mettre le plus possible de liens (je veux dire, d’URIs déréférençables) dans les triples, pour faciliter la navigation dans le Web of data.

Je pense que l’expression « URI déréférençables » est loin d’être évidente pour tout le monde. Qui plus est, derrière ses faux airs, le verbe déréférencer fait immanquablement penser à autre chose : notamment à l’action de supprimer une référence, ou de ne plus référencer, ce qu’il ne signifie pas du tout dans ce contexte.

Alors, avant que nos bibliothécaires ne se méprennent et commencent à enlever les références de leur catalogue pour faire du web sémantique, une petite clarification s’impose.

Comme le suggère Manue, la façon la plus courante de comprendre une URI déréférençable c’est de l’assimiler à un lien hypertexte. Ce n’est pas faux ; mais alors, pourquoi tout çà pour dire çà ?

Le terrain est miné par de sourdes polémiques (notamment entre HTTP et RDF) que je tenterai de masquer en m’en tenant à une présentation consensuelle.

En effet, l’expression de « deferencing an URI » n’est pas simple, elle est même au coeur d’une vive discussion lors des travaux préparatoire du Technical Architecture Group (TAG) du W3C pour la recommandation sur l’archtitecture du world wide web. Cette discussion (issue en anglais) a perduré pendant cinq années, de 2002 à 2007. Elle est référencé sous l’appellation : httpRange-14: What is the range of the HTTP dereference function? Elle a été soulevé par Tim Berners Lee dans un message de la mailing-list du TAG le 19 Mars 2002.

Les URIs sont utilisées selon différents schèmes. Le schème d’URI étant la syntaxe associée à un protocole de la couche « application » du modèle OSI : le plus connu étant le schème des URIs HTTP. Initialement,  le « déréférencement d’URI » était assimilé à la fonction HTTP GET, c’est à dire à la fonction qui permet de demander la représentation d’une ressource :

To dereference a URI means to request a representation of the resource designated by the URI. The dereference mechanism varies according to URI scheme and must be defined by each scheme where dereferencing is a goal. See « Guidelines for new URL Schemes » [RFC2718]. The dereference mechanism for the HTTP URI scheme is GET [TAG issue whenToUseGet-7].

Le déréférencement est donc l’action qui s’enquiert de la représentation (jpg, xml, html, RDF, etc.) d’une ressource.

Si les URIs référencent des représentations, il n’est pas pour autant nécessaire qu’elles impliquent systématiquement le déréférencement de cette URI. C’est d’ailleurs un des principes de l’architecture du web, en vertu duquel il y a lieu de ne pas systématiquement déréférencer les URIs car cela a un coût en calcul, en utilisation de la bande passante et potentiellement en sécurité. Donc, si toutes les ressources ont des représentations, toutes ne font pas de déréférencement des URIs, c’est à dire d’accès aux représentations :

Principle : Reference does not imply dereference

An application developer or specification author SHOULD NOT require networked retrieval of representations each time they are referenced.

Par la suite, le document de référérence sur l’architecture du world wide web stabilise et étend la définition de l’expression « déréférencer une URI » de la manière suivante :

Accéder à la représentation d’une ressource identifiée par une URI

Cette dernière définition élargie donc les toutes premières qui assimilaient l’action de déréférencer une URI à celle d’un agent performant un HTTP GET pour récupérer une représentation. Il y avait donc initialement un primat aux action des agents qui était en mode « Safe » et « Indempotent » (les méthodes GET et HEAD en HTTP) dans la compréhension du déréférencement. Ce primat a disparu puisque, désormais, l’utilisation de toutes les méthodes HTTP (GET, HEAD, POST, PUT, DELETE) relèvent pleinement du déréférencement d’URI.

On trouve l’embrion de de cette généralisation dans un message de Stuart Williams sur la mailing list du W3C en juillet 2002 dans lequel il précise :

URI Resolution:
The process of determining the access mechanism and
appropriate parameters necessary to dereference a
URI. e.g. in the case of an HTTP URI, this process
resolves the URI into an IP address, a port number,
a host name (possibly optional) and a request URI.

Resolution may require several iterations.

URI Dereference:
The process of using the access mechanism and
parameters generated by URI resolution to create,
inspect or modify resource state.

URI Retrieval:
The use of URI dereference to retrieve
representations of resource state.
[On the Web Retrival is always safe].

Je termine en rappelant les quatres règles pour produire des Linked Data proposées par Tim Berners Lee :

1. Utiliser les URIs pour nommer les choses ;
2. Utiliser le schéma des URIs HTTP ;
3. Faites en sorte que les URIs délivrent des informations : c’est ici que l’on parle donc d’URI déréférençables ;
4. Faites des liens ailleurs, vers d’autres corpus de données ;

Vous pouvez aller plus loin en consultant le document du W3C qui indique comment publier des données liées (Linked Data) sur le Web.