Une ressource du World Wide Web est un élément constitutif de base de l'architecture du World Wide Web. C'est la traduction littérale du mot anglais resource, dont le sens est à peu près aussi général que celui du mot français. Le terme a désigné d'abord le référent d'une URL, typiquement une page web. Cette définition a par la suite été généralisée à tous les référents des URI (RFC 3986[1]), et plus récemment des IRI (RFC 3987[2]). Dans le cadre du Web sémantique, les ressources et leurs propriétés sémantiques sont décrites par la famille de langages basée sur RDF (Resource Description Framework). Dans tous ces sigles, URI, URL, IRI, RDF, la lettre "R" signifie "ressource" au sens défini ici.
Cet article est une ébauche concernant le Web sémantique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) — pour plus d’indications, visitez le projet Web Sémantique.
Consultez la liste des tâches à accomplir en page de discussion.
Évolution du concept
Le concept de ressource a évolué durant l'histoire du Web, depuis la notion primitive de document ou fichier informatique statique et adressable, vers une définition plus générale et abstraite, recouvrant maintenant toute chose ou entité susceptible d'être identifiée, nommée , manipulée à travers ses représentations, pour quelque moyen que ce soit, sur le Web en général ou dans n'importe quel système d'information utilisant les technologies du Web.
Les aspects déclaratifs de la définition d'une ressource informatique (identification et nommage), et ses aspects fonctionnels (adressage et organisation du traitement) n'étaient pas clairement distincts dans les premières spécifications du Web, et la définition même de ce qu'est une ressource a longtemps été, et reste l'objet de nombreux débats touchant à des questions difficiles, de nature technique, linguistique, sociale ou philosophique.
Des documents et fichiers aux ressources informatiques
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.
Des ressources web aux ressources « abstraites »
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).
Ressources RDF et web sémantique
Publié dans sa première version en 1999, le Resource Description Framework RDF a pour but, comme son nom l'indique, de "décrire les ressources", en d'autres termes il définit un langage standard pour l'expression des métadonnées des ressources. Une description RDF d'une ressource est un ensemble de triplets (sujet, prédicat, objet), où le sujet est la ressource à décrire, le prédicat un type de propriété applicable au sujet, et l' objet une donnée ou une autre ressource. Le prédicat lui-même est considéré comme une ressource, et identifié par une URI. Donc des types de propriétés comme "titre", "auteur" sont considérés en RDF comme des ressources, et peuvent donc, selon un principe récursif, devenir le sujet ou l'objet d'autres triplets.
C'est sur cette récursivité que s'appuieront les vocabulaires RDF, comme RDFS, OWL, et SKOS pour définir comme des ressources les classes, propriétés et concepts.
RDF autorise aussi la définition de ressources anonymes qui ne sont pas universellement identifiées par une URI, mais définies par des éléments de description à l'intérieur d'un graphe RDF.
Usage des URI HTTP pour identifier des ressources abstraites
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.
Résolution du "problème httpRange-14"
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] .
Références
Articles connexes
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
