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

by Christian on 2 novembre, 2008

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].

A quoi Tim Berners Lee répond en soulignant – non sans humour – le caractère très imagé de « retrieve » :

[…] ‘retrieve » indicates motion of something (as in a Labrador trotting back with a duck).

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.

Print Friendly
Signaler sur Twitter

{ 8 comments… read them below or add one }

Manue novembre 2, 2008 à 6:30

Merci 🙂 je ne suis pas sûre que ça aide beaucoup les pauvres bibliothécaires qui sont déjà perdus dans mon avalanche de billets, mais c’est très clair et très utile.

Répondre

Olivier Le Deuff novembre 3, 2008 à 11:42

Moi, je crois surtout qu’on a besoin de mettre en place des formations dans le domaine.
Mercredi, je fais une introduction au web sémantique avec quelques TP pour mes étudiants.

Répondre

David, biologeek novembre 4, 2008 à 1:12

J’ai appris plein de trucs, merci 🙂

Il y a un lien avec le header HTTP_ACCEPT qui permet d’évaluer la meilleure représentation à retourner ?

Répondre

Christian novembre 4, 2008 à 3:22

@David : En tout cas, si l’on se réfère au « HtttpRange-14 », la question était de savoir quelle est la *nature* de la ressource identifiée par l’URI sur laquelle on a fait un GET. La réponse du TAG a donc été la suivante :
a) If an « http » resource responds to a GET request with a
2xx response, then the resource identified by that URI
is an information resource;

b) If an « http » resource responds to a GET request with a
303 (See Other) response, then the resource identified
by that URI could be any resource;

c) If an « http » resource responds to a GET request with a
4xx (error) response, then the nature of the resource
is unknown.

Concernant le Header ACCEPT on est plutôt dans le cas d’une réponse 2xx qui sera donc une information de ressource, ACCEPT ne filtrant que le type de représentation et non la nature de la ressource (on est un niveau au dessus).

La où la question se corse, et d’où peut-être ta question sur ACCEPT, c’est quand par exemple dans ton ACCEPT tu demandes une représentation en Json qui n’existe qu’en HTML : quelle réponse va faire le server ? Là, du coup c’est la question de la nature de la ressource à un GET qui va se poser effectivement (HttpRange) et la question de savoir si c’est une réponse de type 2**, 3** ou 4** revient sur le devant de la scène.

En même temps, je ne sais pas si tu pensais vraiment à çà dans ton commentaire…

Répondre

David, biologeek novembre 4, 2008 à 7:51

Ok, c’est ce à quoi je pensais effectivement, à quel moment la limite entre les deux devient floue 🙂

Ton exemple est très bon car en effet lorsque c’est la négociation de contenu qui ne suit pas on va avoir du unknown sur une URI qui potentiellement pourrait quand même retourner de l’information…

Pour le coup le déréférencement (URI) pourrait être à l’origine d’une perte de référencement (SEO) selon la pratique, marrant.

Répondre

Christian novembre 4, 2008 à 8:38

CQFD : bien vu 😉

Répondre

jefaismonsite janvier 30, 2010 à 4:39

bonne info, cela va me plaire merci

Répondre

Thierry décembre 21, 2012 à 4:19

Je vous trouve tous bien prétentieux, bien sûr de votre supériorité sur les bibliothécaires de base, et en définitive bien contents de vous-mêmes…

Répondre

Leave a Comment

{ 2 trackbacks }

Previous post:

Next post: