Ressource du World Wide Web

Dans les premiers documents de spécification du Web (1990-1994), le terme resource n'est guère utilisé. Le Web est défini comme un réseau d'objets adressables plus ou moins statiques, des fichiers ou documents électroniques, reliés par des liens hypertexte et manipulés par des protocoles spécifiques comme HTTP ou FTP.

Le premier usage systématique du mot resource apparait en juin 1993 dans le document RFC 1630[3]. Ce document définit la notion générale Universal Resource Identifier (URI), et ses deux variantes Universal Resource Locator (URL) et Universal Resource Name (URN). Une ressource est implicitement définie comme "quelque chose qui peut être identifié", l'identification ayant deux aspects, le nommage et l'adressage. Il est remarquable que RFC 1630 ne contienne aucune définition de la notion de ressource elle-même. En fait le terme n'est guère employé en dehors de ses occurrences dans les acronymes URI, URL et URN, le document continuant comme ses prédécesseurs, de parler des "Objets du Réseau".

En décembre 1994, RFC 1738[4] spécifie davantage la définition des URL, le terme "Universal" étant modifié en "Uniform". Ce document utilise plus systématiquement le mot resource pour désigner les objets "disponibles" (available), ou qui peuvent être "localisés et atteints" à travers le réseau. Là encore, le mot lui-même n'est pas explicitement défini.

La première définition explicite du terme resource dans son sens le plus général est donnée par RFC 2396[5], en août 1998 :

Une ressource peut être toute chose qui possède une identité. Des exemples familiers incluent un document électronique, une image, un service (par exemple "le bulletin météo d'aujourd'hui pour Los Angeles"), ou un ensemble d'autres ressources. Certaines ressources ne peuvent pas être "ramenées par le réseau" (network retrievable), par exemple les êtres humains, les entreprises, les livres d'une bibliothèque peuvent être aussi considérés comme des ressources.

Si les exemples donnés sont encore limités à des entités physiques, la définition ouvre la porte à la possibilité de ressources plus abstraites. Dans la mesure où un concept est identifié, et que cette identité est exprimée par une URI syntactiquement correcte, alors ce concept peut être considéré comme une ressource.

En janvier 2005, RFC 3986 entérine explicitement cette extension de la définition :

... les concepts abstraits peuvent être des ressources, par exemple les opérateurs et opérandes d'une égalité mathématique, le type d'une relation (par exemple "parent" ou "employé"), ou des valeurs numériques (par exemple zéro, un, et l'infini).

L'utilisation des URL, et en particulier d'URI HTTP, pour l'identification de ressources abstraites telles que classes, propriétés, ou toute autre espèce de concept, est une pratique courante en RDF et même implicitement recommandée en RDFS et OWL. Tous les exemples présentés dans la spécification de ces standards utilisent en effet des URI HTTP. Les espaces de noms des standards RDF eux-mêmes utilisent des URI HTTP.

Au-delà de l'usage de l'URI comme identifiant du concept, des questions se sont posées quant aux bonnes pratiques attendues par le Web sémantique en ce qui concerne la relation entre de tels identifiants et le protocole HTTP lui-même. Quel type de réponse ce protocole doit-il renvoyer à une requête utilisant l'URI d'une ressource abstraite ? Cette réponse doit-elle être définie de façon unique côté serveur, ou dépendre du dialogue client-serveur, par une négociation de contenu, distinguant une réponse "pour les humains" (description informelle du concept en texte ou HTML), et une réponse "pour les machines" (description formelle en RDF du concept) ? La syntaxe elle-même des URI devrait-elle permettre de distinguer celles qui identifient des ressources "abstraites" de celles qui identifient des ressources "adressables" (documents électroniques ou pages web) ? Les spécifications des URI telles que RFC 3986 renvoient au protocole la spécification des actions associées aux ressources et ne fournissent donc aucune réponse à ces questions difficiles.

Différentes solutions ont été proposées. La première, soutenue par Tim Berners-Lee lui-même [6], suggérait que les URI HTTP identifiant des ressources adressables soient toutes de type "slash URI", c'est-à-dire ne contiennent aucun identificateur de fragment, utilisant le séparateur #, l'emploi de ce dernier dans les "hash URI" étant réservé à l'identification des ressources abstraites. Une illustration de ce principe est que l'URI http://www.sillywidgets.org/catalogue/widgets.html identifie et permet d'accéder au catalogue de produits de la société Silly Widgets, alors que http://www.widgets.org/ontology#Widget identifie le concept ou la classe "Widget" dans l'ontologie de cette société, et ne devrait pas nécessairement être associée à une ressource physique précise dans le protocole HTTP. Mais une telle distinction est difficile à imposer dans la pratique, et des contre-exemples notables utilisent des "slash URI" pour désigner des concepts, par exemple les éléments du Dublin Core définissant des types de métadonnées documentaires telles que "titre", "éditeur", "auteur", etc., sont identifiés par des "slash" URIs du genre http://purl.org/dc/elements/1.1/title. De plus, l'usage du séparateur # pour désigner en HTML des ancres dans les documents ajoute à la confusion. Par exemple ''http://www.sillywidgets.org/catalogue/widgets.html#Widget'' n'est pas interprété par les navigateurs comme une ressource abstraite, mais comme un pointeur vers un point précis d'une ressource.

Ce problème général a été longtemps connu sous le nom de "Question httpRange-14", selon l'appellation attribuée par le Groupe Architecture Technique en:Technical Architecture Group (TAG) du W3C. Ce groupe a publié en 2005 une réponse "finale" à cette question. Dans la proposition du TAG, la distinction entre ressource de type "information" (information resource) et ressource abstraite dépend du type de la réponse renvoyée par le serveur à une requête http "GET" request. Cette solution met un terme au débat "hash vs slash", en autorisant les deux types d'URI à identifier des ressources abstraites, moyennant une configuration ad hoc côté serveur. Elle semble avoir rencontré l'approbation de la majorité de la communauté du Web sémantique, même si quelques voix se sont élevées pour critiquer sa faisabilité technique ou même son fondement conceptuel. Ainsi Patrick Hayes, un des auteurs du modèle formel de RDF, défend un point de vue selon lequel la distinction même entre ressource de type information et ressource abstraite est impossible à fonder, et ne devrait pas être spécifiée, parce que l'ambiguïté du référent est inhérente à tout système de nommage ou d'identification, et que les URI ne peuvent échapper à cette règle[7] .