Lisez-moi S.V.P. 
W3C

Adresses URI sympas pour le Web sémantique

Note de groupe d'intérêt du W3C du 31 mars 2008

Cette version :
http://www.w3.org/TR/2008/NOTE-cooluris-20080331/
Dernière version :
http://www.w3.org/TR/cooluris/
Version précédente :
http://www.w3.org/TR/2008/WD-cooluris-20080321/
Rédacteurs :
Leo Sauermann (DFKI GmbH)
Richard Cyganiak (DERI, NUI Galway et Freie Universität Berlin)
Contributeurs :
Danny Ayers (Talis Information Ltd.)
Max Völkel (FZI Karlsruhe)

Veuillez consulter la page des errata de ce document, laquelle peut contenir des corrections.



Résumé

Le cadre de description de ressource (Resource Description Framework), ou RDF, permet aux utilisateurs de décrire des documents web ainsi que des concepts du monde réel — personnes, organisations, thèmes, choses — de façon automatique. La publication de telles descriptions sur le Web crée le Web sémantique (Semantic Web). Les adresses URI (Uniform Resource Identifiers) sont très importantes, en fournissant à la fois le cœur de l'environnement (framework) lui-même et le lien entre RDF et le Web. Ce document présente des directives pour les employer efficacement. Il explique deux stratégies dites d'adresses URI avec 303 (303 URIs) et d'adresses URI avec dièse (hash URIs). Il fournit des pointeurs vers plusieurs sites web qui utilisent ces solutions et explique brièvement pourquoi d'autres propositions recèlent des problèmes.

Statut de ce document

Cette section décrit le statut de ce document à sa publication. D'autres documents peuvent venir le remplacer. On peut trouver une liste des publications actuelles du W3C et la dernière version de ce rapport technique à l'index des rapports techniques du W3C à http://www.w3.org/TR/.

Ceci est une note de groupe d'intérêt du W3C fournissant un mode d'emploi expliquant les décisions du groupe Technical Architecture Group (TAG) aux nouveaux venus aux technologies du Web sémantique. Il s'est d'abord inspiré du mémoire DFKI Technical Memo TM-07-01: Cool URIs for the Semantic Web puis a été publié comme version de travail du W3C en décembre 2007 et à nouveau en mars 2008 par le groupe d'intérêt Semantic Web Education and Outreach (SWEO) du W3C, sous l'égide de l'activité Semantic Web du W3C. Les ébauches (drafts) ont été examinée publiquement, spécialement par le groupe Technical Architecture Group (TAG) et le groupe Semantic Web Deployment (SWD).

La charte du groupe d'intérêt Semantic Web Education and Outreach (SWEO) échoyait à fin mars 2008. Néanmoins, ce document peut être repris par d'autres groupes dans le futur pour d'autres développements. Les commentaires en retour à propos de ce document sont donc encouragés. Veuillez les envoyer à public-sweo-ig@w3.org (archives publiques). Une liste complète des changements est disponible.

La publication au titre de note de groupe d'intérêt n'implique pas l'approbation des adhérents du W3C. Ce document est une ébauche et il peut à tout instant être mis à jour, remplacé ou rendu obsolète par d'autres documents. Il ne doit pas être cité sinon comme un travail en cours.

Ce document a été produit par un groupe agissant sous couvert de la politique de brevets du W3C du 5 février 2004. Le groupe n'envisage pas que le document devienne une recommandation du W3C. Le W3C tient une liste publique des divulgations de brevets effectuées en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour divulguer un brevet. Quiconque a connaissance véritable d'un brevet qu'il estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique de brevets du W3C.

Les obligations de divulgation des membres de ce groupe sont décrites dans la charte.

Portée

Ce document est un guide pratique pour ceux qui mettent en œuvre la spécification RDF. Le titre est inspiré de l'article de Tim Berners-Lee intitulé Cool URIs don't change [Cool]. Le guide explique deux approches pour les données RDF hébergées sur des serveurs HTTP. Les publics concernés sont ceux des développeurs Web et des développeurs d'ontologies qui ont à décider de la façon de modéliser leurs adresses URI RDF pour une utilisation avec HTTP. Les applications utilisant des adresses URI non-HTTP ne sont pas couvertes. Ce document est un guide informatif couvrant des aspects sélectionnés de spécifications techniques détaillées déjà publiées. Les adresses URI avec 303 se fondent sur la résolution httpRange-14 [httpRange] du groupe Technical Architecture Group (TAG). Nous supposons de la part du lecteur une connaissance des fondamentaux du modèle de données RDF [RDFPrimer], ainsi que du protocole HTTP [RFC2616]. Pour une bonne introduction, voir cet article de Wikipedia [WP-HTTP].

Table des matières

1. Introduction

Le Web sémantique est visualisé comme un espace d'informations, mondial et décentralisé, pour le partage de données lisibles automatiquement (machine-readable data) avec des coûts d'intégration minimaux. Ses deux défis principaux sont la modélisation répartie du monde selon un modèle de données partagé et l'infrastructure où les données et schémas peuvent être publiés, trouvés et utilisés. Les utilisateurs bénéficient de l'obtention d'informations « brutes et immédiates » [Give] et dans des formats de données portables [DP]. Les fournisseurs publient couramment les données incorporées dans une interface d'utilisateur fixe, en HTML. Une question élémentaire est donc de savoir comment publier les informations à propos des ressources afin que les utilisateurs intéressés et les applications logicielles puissent les trouver et les interpréter.

Dans le Web sémantique, toutes les informations doivent être exprimées comme des déclarations (statements) à propos de ressources (resources), ainsi « les membres de la société Example.com sont Alice et Bob », ou « le numéro de téléphone de Bob est "+1 555 262" », ou « cette page web a été créée par Alice ». Les ressources sont identifiées par des identificateurs de ressource uniformes (des adresses URI) [RFC3986]. Cette approche de modélisation est au cœur du cadre de description de ressource (RDF) [RDFPrimer]. La présentation de N3 [N3Primer] constitue une bonne introduction.

En utilisant RDF, les déclarations peuvent être publiées sur le site web de l'entreprise. D'aucuns peuvent lire les données et publier leurs propres informations, reliant à des ressources existantes. Cela forme un modèle réparti du monde. Il permet à l'utilisateur de choisir une application quelconque pour lire et utiliser les mêmes données, par exemple pour avoir l'adresse publiée d'Alice dans son carnet d'adresses.

Parallèlement, les documents web ont toujours été traités avec des adresses URI — en langage courant, souvent appelées des adresses URL (Uniform Resource Locators). C'est utile parce que cela signifie que l'on peut aisément faire des déclarations RDF à propos de pages web, mais dangereux aussi car on peut facilement confondre les pages web et les choses, ou les ressources, décrites sur la page.

La question est donc celle-ci : « Quelles adresses URI devrait-on utiliser en RDF ? Comme exemple, pour identifier la page d'accueil du site web d'Example Inc., nous pouvons utiliser http://www.example.com/. Mais quelle adresse URI identifie la société en tant qu'organisation, et non comme un site web ? Doit-on servir un contenu — pages HTML, fichiers RDF — à ces adresses URI ? Dans ce document, nous répondrons à ces questions en tenant compte des spécifications pertinentes. Nous expliquons comment utiliser des adresses URI pour des choses qui ne sont pas des pages web, telles que des personnes, des produits, des lieux, ou des idées et des concepts, tels que des classes d'ontologies. Nous donnons des exemples détaillés sur la façon dont le Web sémantique peut (et devrait) être réalisé comme une partie du Web.

2. Adresses URI des documents web

Commençons par un exemple. Supposons une société fictive, nommée Example Inc., produisant des amplificateurs de guitare extrêmes (N.d.T. Extreme Guitar Amplifiers), laquelle a un site web à http://www.example.com/. Une partie du site est un annuaire (white-pages service) listant les noms et coordonnées des employés. Alice et Bob travaillent tous deux chez Example Inc. La structure du site web serait ainsi la suivante ::

http://www.example.com/
La page d'accueil d'Example Inc.
http://www.example.com/people/alice
La page d'accueil d'Alice
http://www.example.com/people/bob
La page d'accueil de Bob

Comme tout ce qui fait le Web traditionnel, chacune des pages mentionnées ci-dessus sont des documents web (Web documents). Chaque document web a sa propre adresse URI. Remarquez qu'un document web n'est pas la même chose qu'un fichier : un seul document web peut être disponible en plusieurs formats et langues différents et un seul fichier, par exemple un script PHP, peut être responsable de la génération d'un grand nombre de documents web avec des adresses URI différentes. Un document web est défini comme quelque chose qui a une adresse URI et peut retourner des représentations (des réponses dans un format tel que HTML, JPEG ou RDF) de la ressource identifiée en réponse à des requêtes HTTP. La littérature technique, telle que la spécification Architecture du Web, tome 1 [AWWW], emploie le terme ressource d'information (information resource) plutôt que document web.

Dans le Web traditionnel, les adresses URI étaient utilisées en premier lieu avec les documents web — pour y conduire et y accéder dans un navigateur. La notion d'identité de la ressource n'était pas si importante sur le Web traditionnel ; lorsque nous saisissions une adresse URL dans un navigateur, elle identifiait simplement ce qui s'y voyait.

2.1. HTTP et négociation de contenu

Les clients et serveurs web utilisent le protocole HTTP [RFC2616] pour demander des représentations de documents web et renvoyer les réponses. HTTP dispose d'un mécanisme puissant pour offrir des versions différentes de formats et langues du même document web, appelé négociation de contenu (content negotiation).

Lorsqu'un agent utilisateur (tel qu'un navigateur) effectue une requête HTTP, il envoie en même temps des en-têtes HTTP pour indiquer les formats de données et les langues qu'il préfère. Le serveur sélectionne alors la meilleure combinaison (best match) de son système de fichiers, ou génère le contenu souhaité à la volée, qu'il renvoie au client. Ainsi, un navigateur pourrait envoyer la requête HTTP suivante pour indiquer espérer une représentation HTML ou XHTML en anglais ou en allemand de http://www.example.com/people/alice :

GET /people/alice HTTP/1.1
Host: www.example.com
Accept: text/html, application/xhtml+xml
Accept-Language: en, de

Le serveur pourrait répondre :

HTTP/1.1 200 OK
Content-Type: text/html
Content-Language: en
Content-Location: http://www.example.com/people.en.html
Vary: accept, accept-language

suivi du contenu du document HTML en anglais.

Nous observons ici une négociation de contenu [TAG-Alt] en action. Le serveur interprète les en-têtes Accept-Language dans la requête et décide de retourner la représentation anglaise de la ressource en question. Notez que l'adresse URI de cette représentation est recopiée dans l'en-tête Content-Location ; quoique non obligatoire, c'est une pratique recommandée (cf. [CHIPS], section 7.2). Les clients voient que cette adresse URI est connectée à la représentation spécifique (ici anglaise), et les moteurs de recherche peuvent désigner les différentes représentations par des différentes adresses URI. Il est donc possible d'avoir plusieurs représentations de la même ressource.

L'en-tête Vary indique quelles en-têtes ont été utilisées par le serveur pour sélectionner une représentation. Dans l'exemple, la réponse du serveur dit au client que si celui-ci avait envoyé une en-tête Accept ou une en-tête Accept-Language différentes, cela aurait pu donner lieu à une réponse différente. Cette information est importante pour les caches qui se tiendraient entre le serveur et le client.

La négociation de contenu est souvent mise en œuvre par un détour : au lieu d'une réponse directe, le serveur redirige (redirect) vers une autre adresse URL où se trouve la représentation appropriée :

HTTP/1.1 302 Found
Location: http://www.example.com/people/alice.en.html
Vary: accept, accept-language

La redirection est signalée par un code d'état (status code) spécial, ici 302 Found. Le client envoie alors une autre requête HTTP à la nouvelle adresse URL. Cette approche, avec des adresses URL distinctes pour des représentations différentes, permet aux auteurs Web de relier directement à une représentation spécifique.

Le format de sérialisation normalisé de RDF (RDF/XML) dispose d'un type de contenu propre : application/rdf+xml. La négociation de contenu permet ainsi aux éditeurs de servir les représentations HTML d'un document web aux navigateurs du Web traditionnel, et les représentations RDF aux agents utilisateurs compatibles avec le Web sémantique. Cela permet également aux serveurs de fournir des formats de sérialisation RDF de remplacement tels que Notation3 [N3] ou TriX [TriX].

3. Adresses URI des objets du monde réel

Dans le Web sémantique, les adresses URI identifient non seulement des documents web mais aussi des objets du monde réel (real-world objects) tels que des personnes et des voitures, et même des idées abstraites et des choses inexistantes telles que la mythique licorne. Nous les appelons des objets du monde réel ou des choses.

Avec une telle adresse URI, comment découvrir ce qu'elle identifie ? Il nous faut répondre à cette question car sinon il serait difficile d'obtenir une interopérabilité entre des systèmes d'information indépendants. On peut imaginer un service, similaire aux moteurs de recherches actuels, où nous irions chercher une description de la ressource identifiée. Mais un tel maillon faible (single point of failure) va à l'encontre du Web, décentralisé par nature.

Nous pourrions à la place utiliser le Web lui-même — un système de publication d'informations robuste et adaptable — comme service de consultation des descriptions de ressources. Dès lors qu'une adresse URI apparaît, nous pouvons la consulter afin de récupérer une description contenant une information pertinente et des liens vers les données liées. C'est tellement important que nous en faisons la première exigence pour des adresses URI sympas :

1. Soyez sur le Web.
Avec seulement une adresse URI, les machines et les personnes devraient pouvoir récupérer auprès du Web une description de la ressource identifiée par l'adresse URI. Un tel mécanisme de consultation (look-up mechanism) est important pour établir une compréhension partagée de ce que l'adresse URI identifie. Les machines devraient obtenir des données RDF et les utilisateurs humains une représentation intelligible, telle que du HTML. Le protocole de transfert Web normalisé HTTP devrait être utilisé.

Supposons que la société Example Inc. veuille publier les coordonnées des employés sur le Web sémantique de façon à ce que les associés puissent les importer dans leurs carnets d'adresses. Ainsi, les données publiées contiendraient les déclarations suivantes à propos d'Alice, écrites ici dans la syntaxe N3 [N3] :

<URI-of-alice> a foaf:Person;
    foaf:name "Alice";
    foaf:mbox <mailto:alice@example.com>;
    foaf:homepage <http://www.example.com/people/alice> .

Quelle adresse URI utiliser à la place du paramètre fictif (placeholder) <URI-of-alice> ? Certainement pas http://www.example.com/people/alice, car on confondrait une personne et un document web, conduisant à un malentendu : « La page d'accueil d'Alice se nomme-t-elle aussi "Alice" ? La page d'accueil même peut-elle avoir une adresse électronique ? Et cela a-t-il un sens qu'une page d'accueil ait elle-même sa page d'accueil ? Il nous faut donc une autre adresse URI. (Pour une étude approfondie de ce problème, cf. les articles What HTTP URIs Identify? [HTTP-URI2] et Four Uses of a URL: Name, Concept, Web Location and Document Instance [Booth]).

D'où notre deuxième exigence :

2. Soyez clair.
Il ne devrait pas y avoir de confusion entre les identificateurs de documents web et les identificateurs d'autres ressources. Les adresses URI sont conçues pour n'identifier qu'un type unique ; une seule adresse URI ne peut donc pas représenter à la fois un document web et un objet du monde réel.

Notons que nos exigences semblent se contredire. Si nous ne pouvons pas utiliser d'adresse URI de document pour identifier un objet du monde réel, alors comment pouvons-nous récupérer une représentation d'un objet du monde réel en fonction de son adresse URI ? Le défi consiste à trouver les documents descriptifs avec juste l'adresse URI de la ressource, en utilisant des technologies Web normalisées.

L'image suivante montre les relations souhaitées entre une ressource et ses documents représentatifs :

Une ressource et les documents qui la décrivent

3.1. Distinguer les représentations et les descriptions

On doit comprendre qu'en utilisant des adresses URI il est possible d'identifier à la fois une chose (qui peut avoir une existence en dehors du Web) et un document web décrivant la chose. Ainsi, la personne Alice est décrite dans sa page d'accueil. Bob n'aime peut-être pas l'aspect de cette page d'accueil mais apprécie la personne Alice. Deux adresses URI sont donc nécessaires : une pour Alice et une pour la page d'accueil ou un document RDF décrivant Alice. La question est de tracer la limite entre le cas où l'un et l'autre sont possibles et le cas où seules des descriptions sont disponibles.

Selon les directives du W3C ([AWWW], section 2.2), nous avons un document web (appelé ressource d'information) si toutes ses caractéristiques essentielles peuvent être communiquées dans un message. Une page web, une image ou un catalogue de produits en sont des exemples.

Dans HTTP, un code de réponse 200 est envoyé lorsque l'on a eu accès à un document web ; mais une configuration différente est nécessaire lorsqu'on publie des adresses URI prévues pour identifier des entités qui ne sont pas des documents web.

Dans la section suivante, nous décrivons des solutions qui permettent de marquer les adresses URI de choses et qui permettent aussi aux clients d'obtenir une description de la chose en utilisant des technologies Web normalisées.

4. Deux bonnes solutions

Deux solutions satisfont à nos exigences pour l'identification d'objets du monde réel : les adresses avec 303 et les adresses avec dièse. Lesquelles utiliser dépend de la situation ; les deux types ont des avantages et des inconvénients.

Les solutions décrites à la suite s'appliquent à des scénarios de déploiement où les données RDF et les données HTML sont servies séparément, tels qu'un document RDF/XML autonome en même temps qu'un document HTML. Les métadonnées peuvent aussi être incorporées dans HTML, en utilisant des technologies telles que RDFa [RDFa Primer], les microformats et d'autres documents auxquels les mécanismes GRDDL [GRDDL] peuvent s'appliquer. Auquel cas, les données RDF sont extraites du document HTML retourné.

4.1. Adresses URI avec dièse

La première solution est d'utiliser des « adresses URI avec dièse » pour les ressources non documentaires (non-document resources). Les adresses URI peuvent contenir un fragment, une partie spéciale séparée du reste de l'adresse URI par un caractère SYMBOLE DIÈSE « # ».

Lorsqu'un client récupère (retrieve) une adresse URI avec dièse, le protocole HTTP impose la troncature de la partie fragment avant de requérir l'adresse URI auprès du serveur. Cela signifie qu'une adresse URI contenant un caractère dièse n'est pas récupérable directement et n'identifie donc pas nécessairement un document web. En revanche, on peut s'en servir pour identifier d'autres ressources non documentaires, sans créer d'ambiguïté.

Si la société Example Inc. adopte cette solution, elle pourrait alors utiliser les adresses URI suivantes pour représenter la société, Alice et Bob :

http://www.example.com/about#exampleinc
Example Inc., la société
http://www.example.com/about#alice
Alice, la personne
http://www.example.com/about#bob
Bob, la personne

Les clients enlèveront toujours la partie fragment avant de soumettre ces adresses URI, ce qui se traduit par une requête à cette adresse URI-ci :

http://www.example.com/about
Un document RDF décrivant Example Inc., Alice et Bob

À cette adresse URI, Example Inc. pourrait servir un document RDF contenant les descriptions des trois ressources, en utilisant l'adresse URI avec dièse initiale pour identifier les ressources.

L'image suivante montre l'approche utilisant une adresse URI avec dièse sans négociation de contenu :

La solution d'adresse URI avec dièse sans négociation de contenu

Autrement, on pourrait utiliser une négociation de contenu (cf. la section 2.1.) pour effectuer une redirection depuis l'adresse URI about soit vers une représentation HTML, soit RDF. La décision du retour est fondée sur les préférences du client et la configuration du serveur, comme expliqué ci-dessous à la section 4.7. L'en-tête Content-Location devrait être mis pour indiquer si l'adresse URI avec dièse se rapporte à une partie du document HTML ou du document RDF.

L'image suivante montre l'approche utilisant une adresse URI avec dièse et une négociation de contenu :

La solution d'adresse URI avec dièse avec négociation de contenu

4.2. Adresse URI avec 303 renvoyant à un seul document générique

La deuxième solution est d'utiliser un code d'état HTTP spécial, 303 See Other, pour indiquer que la ressource demandée n'est pas un document web ordinaire. L'architecture du Web nous dit que, pour une ressource de chose (adresse URI), il n'est pas correct de retourner un code d'état 200, parce que ces ressources n'ont en fait pas de représentations qui conviennent. En revanche, il est utile de fournir des informations à propos de ces ressources. Le groupe Technical Architecture Group du W3C nous propose en solution, dans sa résolution httpRange-14 [httpRange], d'aller à un document qui contient des informations à propos de la chose demandée. Ce faisant, nous évitons l'ambiguïté entre l'objet du monde réel original et la ressource qui le représente.

Puisque le code d'état 303 signale une redirection, le serveur peut donner l'emplacement d'un document qui représente la ressource. Si, au contraire, on répond à la requête par un code d'état habituel dans la gamme 2xx, tels que 200 OK, le client sait alors que l'adresse URI identifie un document web.

Si la société Example Inc. adopte cette solution, elle pourrait utiliser les adresses URI suivantes pour représenter la société, Alice et Bob :

http://www.example.com/id/exampleinc
Example Inc., la société
http://www.example.com/id/alice
Alice, la personne
http://www.example.com/id/bob
Bob, la personne

On configurerait le serveur Web pour répondre à toutes les requêtes de ces adresses URI par un code d'état 303 et un en-tête HTTP Location fournissant l'adresse URL d'un document représentant la ressource ; par exemple, pour rediriger de http://www.example.com/id/alice vers http://www.example.com/doc/alice.

Il y a donc une négociation de contenu pour la récupération d'une représentation à partir de l'adresse URI du document en utilisant une requête HTTP. Le serveur décide (cf. la section 4.7) de retourner soit du HTML, soit du RDF (ou d'autres formes de remplacement), et remplit l'en-tête Content-Location avec l'adresse URI où récupérer la représentation spécifique.

Cette configuration devrait être utilisée lorsque les fichiers RDF et HTML (et éventuellement d'autres représentations alternatives) communiquent la même information dans des formes différentes. Lorsque l'information dans les versions diffère considérablement, on devrait utiliser l'approche avec 303 décrite ci-dessous.

Cf. l'illustration suivante de la solution fournissant l'adresse URI du document générique :

Solution pour une adresse URI de document générique

Dans cette configuration, le serveur effectue un renvoi de l'adresse URI d'identification vers l'adresse URI du document générique. L'avantage pour les clients est de pouvoir mettre en favoris (bookmark) le document générique pour y travailler ultérieurement. Un utilisateur dont le client est compatible avec RDF pourrait ranger le document comme favori qu'il peut poster (mail) à un autre utilisateur (ou appareil), qui le résoud (dereference) pour obtenir le HTML ou la vue RDF. En outre, le serveur peut ajouter des représentations dans de nouveaux langages par la suite. Ce n'est pas parce que le client a commencé avec l'adresse URI d'une chose que cela signifie pour autant que le document concerné n'est pas un document de première classe sur le Web. Le contexte des ressources de documents génériques est décrit dans [GenRes].

4.3. Adresses URI avec 303 renvoyant à des documents différents

Lorsque les représentations RDF et HTML de la ressource diffèrent subtantiellement, on ne devrait pas utiliser la configuration précédente. Ce ne sont pas deux versions du même document mais des documents totalement différents. À nouveau, le serveur Web serait configuré pour répondre aux requêtes par un code d'état 303 et un en-tête HTTP Location qui fournit l'adresse URL représentant la ressource.

L'image suivante montre les redirections de la solution de l'adresse URI avec 303 sans l'adresse URI du document générique :

La solution d'adresse URI 303

Le serveur pourrait employer une négociation de contenu (cf. la section 2.1.) pour envoyer l'adresse URL soit d'une description HTML, soit RDF. Les requêtes HTTP pour un contenu HTML serait redirigées vers les adresses URL HTML que nous avons données à la section 2. Les requêtes pour des données RDF serait redirigées vers les documents RDF, ainsi :

http://www.example.com/data/exampleinc
Un document RDF décrivant Example Inc., la société
http://www.example.com/data/alice
Un document RDF décrivant Alice, la personne
http://www.example.com/data/bob
Un document RDF décrivant Bob, la personne

Chaque document RDF contiendrait des déclarations à propos de la ressource appropriée, en utilisant l'adresse URI originale, par exemple http://www.example.com/id/alice, pour identifier la ressource décrite.

4.4. Choisir entre la solution du 303 et la solution du dièse

Quelle est la meilleure approche ? Ça dépend. Les adresses URI avec dièse ont l'avantage de réduire le nombre d'allers-retours HTTP nécessaires, d'où une réduction du temps de latence des accès. Une famille d'adresses URI peut partager le même tronc hors partie dièse. Les descriptions de http://www.example.com/about#exampleinc, http://www.example.com/about#alice et http://www.example.com/about#bob sont récupérées en une seule requête à http://www.example.com/about. Toutefois, cette approche présente un inconvénient : un client seulement intéressé par #product123 chargera également sans nécessité les données de toutes les autres ressources car elles se trouvent dans le même fichier. En revanche, les adresses URI avec 303 sont très flexibles car la cible de redirection peut être configurée séparément pour chaque ressource. On peut avoir un document de description par ressource, ou un seul grand document pour toutes, ou une combinaison entre les deux. Et il est également possible de changer de politique par la suite.

Lorsqu'on utilise des adresses URI avec 303 pour une ontologie, telle que FOAF, les congestions du réseau peuvent grever considérablement le rendement d'un client. La multiplication des redirections peut entraîner une latence plus élevée. Un client consultant un ensemble de termes au travers d'une redirection 303 peut consommer beaucoup de requêtes, même si la première aura déjà chargé tout ce qu'il faut.

Lorsqu'on héberge des ensembles de données à grande échelle en utilisant la solution du 303, les clients seront peut-être tentés de télécharger toutes les données en faisant de nombreuses requêtes. Nous préconisons de fournir en suplément des extrémités SPARQL (SPARQL endpoints), ou des services comparables, pour répondre aux interrogations complexes directement sur le serveur, plutôt que de laisser le client télécharger un ensemble de données volumineux via HTTP.

Notez aussi que l'on peut combiner les approches 303 et dièse, ce qui permet de découper un ensemble de données volumineux en plusieurs parties et d'avoir un identificateur pour une ressource non documentaire. Voici un exemple de combinaison des approches 303 et dièse :

http://www.example.com/bob#this
Bob, la personne, avec une adresse URI combinée.

Tout identificateur de fragment est valide ; le fragment this dans l'adresse URI ci-dessus est une suggestion qui pourrait s'appliquer à vos mises en œuvre.

Conclusion.
Les adresses URI avec dièse devraient être préférées pour des ensembles de ressources plutôt stables et réduits qui évoluent ensemble. Le cas idéal est celui des vocabulaires RDF Schema et des ontologies OWL, où les termes sont souvent utilisés ensemble et où le nombre de termes restera vraisemblablement sous contrôle dans le futur.

On peut mettre en œuvre des adresses URI avec dièse sans négociation de contenu, en chargeant simplement des fichiers RDF statiques sur un serveur Web, sans effectuer de configuration spéciale du serveur ; ce qui les rend populaires pour une publication RDF à la va-vite.

Les adresses URI de la forme bob#this peuvent être utilisées pour des ensembles de données volumineux qui dépassent (ou sont susceptibles de dépasser) la limite pratique du service de toutes les ressources pertinentes en un seul document. Les adresses URI avec 303 peuvent également s'utiliser avec de tels ensembles de données, formant des adresses URI plus élégantes, mais avec un impact sur les performances d'exécution et sur la charge du serveur.

Dans le doute, suivez votre instinct.

4.5. Adresses URI sympas

Les meilleurs identificateurs de ressources ne fournissent pas uniquement des descriptions pour les personnes et les machines mais se conçoivent dans un esprit de simplicité, de stabilité et de maniabilité (manageability), comme expliqué par Tim Berners-Lee dans Cool URIs don't change et par l'Équipe du W3C dans Problèmes courants de la mise en œuvre HTTP, sections 1 et 3 :

Simplicité.
Les adresses URI courtes et mnémotechniques ne s'abimeront pas si facilement, envoyées dans les courriers électroniques, et en général on s'en souvient mieux, par exemple lors du débogage de son serveur Web sémantique.
Stabilité.
Une fois fixée l'adresse URI pour identifier une certaine ressource, elle devrait rester telle aussi longtemps que possible. Pensez aux dix voire vingt prochaines années. Gardez les accessoires spécifiques d'une mise en œuvre, tels que .php et .asp, hors de vos adresses URI ; il se peut que vous changiez de technologies par la suite.
Maniabilité.
Publiez vos adresses URI afin de pouvoir les gérer. Une bonne pratique consiste à inclure l'année courante dans le chemin URI (URI path), de façon à pouvoir changer tous les ans le schéma URI (URI-schema) sans casser les anciennes adresses URI. Garder toutes les adresses URI avec 303 dans un sous-domaine dédié, par exemple http://id.example.com/alice, facilitera une migration ultérieure du sous-système de gestion URI (URI-handling subsystem).

4.6. Liaison

Toutes les adresses URI liées à un seul objet du monde réel — identificateur de ressource, adresse URL de document RDF, adresse URL de document HTML — devraient également être explicitement reliées les unes aux autres pour aider les consommateurs d'information à en comprendre les relations. Ainsi, dans la solution d'adresse URI avec 303 pour Example Inc., il y a trois adresses URI reliées à Alice :

http://www.example.com/id/alice
L'identificateur d'Alice, la personne
http://www.example.com/people/alice
La page d'accueil d'Alice
http://www.example.com/data/alice
Un document RDF avec une description d'Alice

Deux d'entre elles sont des adresses URL de documents web. Le document RDF situé à http://www.example.com/data/alice pourrait contenir les déclarations suivantes (exprimées en N3) :

<http://www.example.com/id/alice>
    foaf:page <http://www.example.com/people/alice>;
    rdfs:isDefinedBy <http://www.example.com/data/alice>;

    a foaf:Person;
    foaf:name "Alice";
    foaf:mbox <mailto:alice@example.com>;
    ...

Le document contient des déclarations à propos d'Alice, la personne, utilisant l'identificateur de ressource. Les deux premières propriétés relient l'identificateur de ressource aux deux adresses URI de documents. La déclaration foaf:page le relie au document HTML. Cela permet aux clients compatibles avec RDF de trouver une ressource intelligible pour l'utilisateur (human-readable) et, en reliant la page à son sujet, de définir en même temps des métadonnées utiles à propos de ce document HTML. La déclaration rdfs:isDefinedBy relie la personne au document qui en contient la description RDF et elle permet aux navigateurs RDF de distinguer cette ressource principale d'autres ressources auxilliaires qui seraient mentionnées dans le document. Nous utilisons rdfs:isDefinedBy à la place de sa superpropriété rdfs:seeAlso plus pauvre, parce que le contenu trouvé à /data/alice fait autorité. Les déclarations qui suivent constituent les données concrètes de l'annuaire.

Le document HTML à http://www.example.com/people/alice devrait contenir dans son en-tête un élément <link> pointant vers le document RDF correspondant :

<html xmlns="http://www.w3.org/1999/xhtml" lang="en">
  <head>
    <title>Alice's Homepage</title>
    <link rel="alternate" type="application/rdf+xml"
          title="RDF Representation"
          href="http://www.example.com/data/alice" />
  </head> ...

Cela permet aux clients web compatibles avec RDF de découvrir l'information RDF. Cette approche est recommandée dans la spécification RDF/XML ([RDFXML], section 9). Si les données RDF sont à propos de la page web plutôt qu'elles ne sont une expression de l'information qui s'y trouve, nous recommandons alors d'utiliser rel="meta" au lieu de rel="alternate".

Le client peut également déduire une information de relation similaire directement des en-têtes HTTP ; à savoir, qu'une chose est décrite par un document web trouvé à la fin d'une redirection 303, que la ressource indiquée par Content-Location est une version du document générique avec un contenu spécifique, et plus. Les ontologies de ces relations ne sont pas traitées ici.

L'illustration suivante montre comment les documents RDF et HTML devraient relier les trois adresses URI les unes aux autres :

Les documents RDF et HTML devraient relier les adresses URI les unes aux autres

4.7. Mise en œuvre de la négociation de contenu

Le groupe de travail Semantic Web Best Practices and Deployment du W3C a publié un document qui décrit la mise en œuvre des solutions présentées ici sur le serveur Web Apache. Les Recettes de pratiques exemplaires pour publier des vocabulaires RDF [Recipes] traite essentiellement de la publication de vocabulaires RDF (RDF vocabularies), mais ces idées peuvent également s'appliquer à d'autres types d'ensemble de données RDF réduits, publiés à partir de fichiers statiques.

Par contre, spécialement en ce qui concerne la négociation de contenu, le document de recettes ne couvre pas quelques détails importants. La négociation de contenu est un peu plus difficile en pratique du fait des clients en mode mixte qui peuvent traiter à la fois du HTML et du RDF, tels que Firefox avec l'extension Tabulator.

Ces navigateurs annoncent leur aptitude à consommer à la fois du RDF et du HTML par le biais d'en-têtes Accept utilisant des coefficients q (qualité) :

Accept: application/rdf+xml;q=0.7, text/html

Ici le navigateur accepte du RDF avec un coefficient q de 0.7 et du HTML avec un coefficient q de 1.0 (la valeur par défaut). Le navigateur annonce ainsi une légère préférence pour le HTML par rapport au RDF.

Maintenant, la préférence d'un client pour le HTML ne signifie pas forcément que tous les serveurs devraient envoyer du HTML. Le serveur doit évaluer les préférences du client puis prendre une décision en fonction de la qualité des différentes versions qu'il est susceptible d'offrir. Par exemple :

Il existe des algorithmes pour choisir la meilleure correspondance en comparant les préférences du client aux qualités des variantes disponibles du serveur. Par exemple, le serveur Apache peut être configuré avec des coefficients qs côté-serveur qui indiquent les qualités relatives de ces variantes.

Des coefficients qs de 1.0 pour le type application/rdf+xml et de 0.5 pour le type text/html signifient que la variante HTML a approximativement la moitié de la qualité de la variante RDF, ce qui correspondrait au premier cas de la liste précédente. Si le HTML est un article d'actualité et que le RDF ne contient qu'une information partielle telle que les titre, date et auteur, alors des coefficients de 1.0 pour le HTML et de 0.1 pour le RDF seraient appropriés.

Pour déterminer la meilleure variante pour un client particulier, le serveur Apache multiplie les coefficients q du client pour le HTML aux coefficients qs configurés pour le HTML ; même chose pour le RDF. La variante qui obtient la plus grande valeur l'emporte. La documentation du serveur Apache contient une section décrivant en détails son algorithme de négociation de contenu [ApCN]. L'en-tête HTTP Accept est décrit en détails à la section 14.1 de la spécification HTTP [HTTP-SPEC].

La négociation de contenu, avec tous ses rouages, est assez complexe mais c'est un moyen puissant pour sélectionner la meilleure variante pour les clients en mode mixte compatibles avec HTML et RDF.

5. Exemples du Web

Les projets utilisant les technologies du Web sémantique ne publient pas tous leurs données sur le Web. Toujours est-il que beaucoup appliquent les pratiques décrites ici. Cette section donne quelques exemples.

ECS Southampton
L'école School of Electronics and Computer Science à l'université de Southampton a un site Web sémantique qui emploie la solution 303 et constitue un exemple remarquable. Celui-ci est documenté dans ECS URI System Specification [ECS]. Des sous-domaines séparés sont utilisés pour les documents HTML, les documents RDF et les identificateurs de ressources. Prenons ces exemples :

http://id.ecs.soton.ac.uk/person/1650
L'adresse URI de Wendy Hall, la personne
http://www.ecs.soton.ac.uk/people/wh
La page HTML à propos de Wendy Hall
http://rdf.ecs.soton.ac.uk/person/1650
Le RDF à propos de Wendy Hall

Entrer la première adresse URI dans un navigateur Web normal renvoie à une page HTML à propos de Wendy Hall. Celle-ci présente une vue Web de toutes les données disponibles la concernant. La page relie à son adresse URI et à son document RDF.

Serveur D2R
C'est une application que l'on peut utiliser pour publier des données issues de bases de données relationnelles sur le Web sémantique conformément à ces directives. Celui-ci emploie la solution 303 et une négociation de contenu. Par exemple, le serveur D2R publiant la base de données bibliographiques DBLP publie des milliers d'enregistrement bibliographiques et d'informations à propos de leurs auteurs. Voici des exemples d'adresses URI à nouveau reliées via des redirections 303:

http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759
L'adresse URI pour Chris Bizer, la personne
http://www4.wiwiss.fu-berlin.de/dblp/page/person/315759
La page HTML à propos de Chris Bizer

Le document RDF pour Chris Bizer est un résultat d'interrogation SPARQL provenant de l'extrémité SPARQL du serveur :

http://www4.wiwiss.fu-berlin.de/dblp/sparql?query=
DESCRIBE+\%3Chttp\%3A\%2F\%2Fwww4.wiwiss.fu-berlin.de
\%2Fdblp\%2Fresource\%2Fperson\%2F315759\%3E

Voici l'interrogation SPARQL codée dans cette adresse URI :

DESCRIBE <http://www4.wiwiss.fu-berlin.de/dblp/resource/person/315759>

Cela montre comment utiliser une extrémité SPARQL comme d'une méthode pratique pour servir des descriptions de ressources.

Semantic MediaWiki
C'est un moteur wiki sémantique en code source libre. Les auteurs peuvent utiliser une syntaxe wiki spéciale pour placer des attributs et relations sémantiques dans des articles wiki. Pour chaque article, le logiciel génère une adresse URI avec 303 qui identifie le sujet de l'article et sert des descriptions RDF générées en fonction des attributs et relations. Le moteur Semantic MediaWiki anime le wiki OntoWorld. Il contient un article sur la ville de Karlsruhe :

http://ontoworld.org/wiki/Karlsruhe
L'article, un document HTML
http://ontoworld.org/wiki/_Karlsruhe
La ville de Karlsruhe
http://ontoworld.org/wiki/Special:ExportRDF/Karlsruhe
La description RDF de Karlsruhe

L'adresse URI de la description RDF est loin d'être idéale car elle expose la mise en œuvre (PHP) et mentionne inutilement RDF dans le chemin dans l'interrogation. Ainsi, une adresse URI bien plus jolie serait http://ontoworld.org/data/Karlsruhe, car on pourrait utiliser une négociation de contenu pour servir les données en RDF, en RIF (Rule Interchange Format), ou en quoi que ce soit d'autre par la suite.

6. Autres propositions de nommage des ressources

Beaucoup d'autres approches ont été suggérées au cours des années. Bien que la plupart d'entre elles conviennent dans des situations particulières, nous estimons qu'elles ne satisfont pas aux critères de la section 3, à savoir « Soyez sur le Web » et « Soyez clair ». Elles ne sont donc pas appropriées comme solutions générales pour construire un Web sémantique fondé sur des standards, non fragmenté et décentralisé. Nous examinerons deux approches plus en détails.

6.1. Nouveaux schémas d'adresses URI

Les adresses URI HTTP identifient déjà des ressources web et des documents web, pas d'autres types de ressources. Ne devrions-nous pas créer un nouveau schéma d'adresses URI pour identifier d'autres ressources ? Nous pourrions alors aisément les distinguer de documents web juste en regardant les premiers caractères de l'adresse URI. Par exemple, on peut utiliser le schéma info pour identifier des livres d'après un numéro LCCN : info:lccn/2002022641.

Voici des exemples de tels schémas d'adresses URI. Thompson et Orchard en fournissent une liste étendue dans Adresses URN, espaces de noms et registres [TAG-URNs].

Pour être réellement utile, un nouveau schéma doit s'accompagner d'un protocole définissant comment accéder à des informations supplémentaires à propos de la ressource identifiée. Par exemple, le schéma d'adresses URI ftp:// identifie les ressources (des fichiers sur un serveur FTP) et s'accompage aussi d'un protocole pour y accéder (le protocole FTP).

Parmi les nouveaux schémas d'adresses URI, certains n'offrent pas de tels protocoles du tout. D'autres fournissent un service web permettant de récupérer des descriptions à l'aide du protocole HTTP. L'identificateur est passé au service qui cherche l'information dans une base de données centrale ou en fédération. Le problème ici est qu'une panne de ce service rend le système inutilisable.

Dépendre d'un organisme de normalisation (standardization body) peut aussi être un inconvénient. Il faut contacter un organisme de normalisation pour enregistrer de nouvelles parties de l'espace info:. Cette démarche, ou payer une redevance fixe (license fee) avant la création d'une nouvelle adresse URI, peut ralentir l'adoption. Un organisme de normalisation est souhaitable dans ces cas afin de s'assurer que toutes les adresses URI sont uniques (par exemple pour les numéros ISBN). Mais on ne peut le réaliser qu'en utilisant des adresses URI HTTP dans un espace de noms HTTP détenu et géré par l'organisme de normalisation.

Indépendamment de l'organisme de normalisation et de la facilité de consultation (retrievability), les brevets en vigueur et les questions juridiques peuvent influer sur l'adoption d'un nouveau schéma d'adresses URI. Lors de l'utilisation d'une technologie brevetée, les implémenteurs devraient vérifier l'existence d'une licence libre de droit.

Les problèmes concernant les nouveaux schémas d'adresses URI sont abordés en détails dans le document Adresses URN, espaces de noms et registres.

6.2. Référence par description

La « référence par description » résoud radicalement le problème de l'adressage URI en abolissant totalement les adresses URI : au lieu de nommer les ressources avec une adresse URI, on utilise des nœuds anonymes et on les décrit par des informations qui nous permettent de trouver le bon. Ainsi, une personne peut être décrite par un nom, une date de naissance et un numéro de sécurité sociale. Ces bribes d'information devrait suffire pour identifier une personne exclusivement.

Une pratique fréquente consiste à utiliser l'adresse électronique d'une personne comme élément d'information identifiant exclusif. La propriété foaf:mbox des profils Friend of a Friend (FOAF) sert à cet effet. Dans OWL, ce type de propriété est dite une propriété réciproque (inverse functional property). Lorsqu'un agent rencontre deux ressources avec la même adresse électronique, il peut inférer que les deux se rapportent à la même personne et les traiter comme étant une seule.

Mais comment « être sur le Web » avec cette approche ? Comment les agents peuvent-ils télécharger plus de données à propos des ressources que nous mentionnons ? Une pratique exemplaire permet de réaliser cet objectif : fournir non seulement la propriété réciproque de la ressource (par exemple l'adresse électronique de la personne) mais aussi une propriété rdfs:seeAlso qui pointe vers l'adresse Web d'un document RDF avec d'autres informations au sujet de la ressource. À constater que nous utilisons encore des adresses URI HTTP pour identifier le lieu où télécharger plus d'informations.

Toujours est-il que nous avons maintenant plusieurs éléments d'information pour désigner une ressource : la valeur de la propriété réciproque et l'emplacement du document RDF. Le simple fait de relier par une adresse URI est devenu un processus impliquant plusieurs pièces mobiles, ce qui augmente les risques de rupture des liens et rend les mises en œuvre plus encombrantes.

Concernant la pratique FOAF qui est d'éviter les adresses URI pour les personnes, nous sommes de l'avis de Tim Berners-Lee : « Allez-y et donnez-vous une adresse URI. Vous la méritez ! »

7. Conclusion

Les noms des ressources sur le Web sémantique devraient remplir deux conditions : premièrement, une description de la ressource identifiée devrait être récupérable avec des technologies Web normalisées ; deuxièmement, un schéma de nommage ne devrait pas confondre les choses et les documents qui les représentent.

Nous avons décrit deux approches qui répondent à ces exigences, toutes les deux fondées sur le schéma d'adresses URI et le protocole HTTP. L'une consiste à utiliser le code d'état HTTP 303 pour rediriger de l'identificateur de ressource au document de description. L'autre consiste à utiliser des « adresses URI avec dièse » pour identifier les ressources, en exploitant le fait que ces adresses URI avec dièse sont récupérées en écartant la partie après le dièse et récupérant l'autre partie.

L'exigence à distinguer les ressources de leurs descriptions augmente le besoin de coordination entre plusieurs adresses URI. Quelques techniques utiles : incorporer les liens vers les données RDF dans les documents HTML, en utilisant des déclarations RDF pour décrire les relations entre les adresses URI et en utilisant une négociation de contenu pour rediriger vers une description appropriée de la ressource.

8. Remerciements

Un grand merci à Tim Berners-Lee qui a consacré beaucoup de temps pour nous aider à comprendre la solution du TAG en répondant à nos demandes par messagerie instantannée et en envoyant de nombreux courriers avec des éclaircissements et examens minutieux de ce document. Remerciements distingués à Stuart Williams, Norman Walsh et tous les autres membres du TAG qui ont revu ce document et fait des remarques essentielles en juin 2007 et septembre 2007 à propos de plusieurs formulations qui étaient (involontairement) contraires au point de vue du TAG. Remerciements distingués également aux membres du groupe Semantic Web Deployment, à savoir Michael Hausenblas, Vit Novacek et Ed Summers, pour leurs analyses et leur rapport d'analyse envoyés en octobre 2007. Nous souhaitons remercier toutes les personnes qui ont examiné les brouillons de ce document, en particulier Chris Bizer, Gunnar AAstrand Grimnes, Harry Halpin, Xiaoshu Wang, Henry S. Thompson, Jonathan Rees et Christoph Päper. Susie Stephens a relu le document, dirigé le groupe SWEO et nous a aidé à tenir le cap. Ivan Herman a beaucoup fait pour vérifier la conformité aux exigences du W3C et il a soumis la note.

Ce travail a été soutenu par le ministère fédéral allemand de l'éducation, de la recherche et de la technologie (BMBF), (subventions 01 IW C01, Project EPOS: Evolving Personal to Organizational Memories et 01 AK 702B, Project InterVal: Internet and Value Chains) et par le fond IST de l'Union Européenne (subvention FP6-027705, Project Nepomuk).

9. Références

[AWWW]
Architecture du Web tome 1, Ian Jacobs, Norman Walsh, rédacteurs. World Wide Web Consortium, 15 décembre 2004. Cette version est celle à http://www.w3.org/TR/2004/REC-webarch-20041215/. La dernière version est disponible à http://www.w3.org/TR/webarch/.
[ApCN]
Documentation du serveur HTTP Apache version 2.0 — Négociation de contenu. Ce document est disponible à http://httpd.apache.org/docs/2.0/content-negotiation.html.
[Booth]
Four Uses of a URL: Name, Concept, Web Location and Document Instance, David Booth. 28 janvier 2003. Ce document est disponible à http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm.
[CHIPS]
Problèmes courants de la mise en œuvre HTTP, Olivier Théreaux, rédacteur. World Wide Web Consortium, 28 janvier 2003. Cette version est celle à http://www.w3.org/TR/2003/NOTE-chips-20030128/. La dernière version est disponible à http://www.w3.org/TR/chips/.
[Cool]
Cool URIs don't change, Tim Berners-Lee, 1998. Ce document est disponible à http://www.w3.org/Provider/Style/URI.
[DP]
The DataPortability Project. http://dataportability.org/
[ECS]
ECS URI System Specification, Colin Williams, Nick Gibbins. ECS Southampton, 2006. Ce document est disponible à http://id.ecs.soton.ac.uk/docs/.
[FOAF]
FOAF Vocabulary Specification 0.9, Dan Brickley, Libby Miller. 24 mai 2007. Cette version est celle à http://xmlns.com/foaf/spec/20070524.html. La dernière version est disponible à http://xmlns.com/foaf/spec/.
[Give]
Give Us the Data Raw, and Give it to Us Now, Rufus Pollock. 7 novembre 2007.
[GenRes]
Generic Resources, Tim Berners-Lee. Ce document est disponible à http://www.w3.org/DesignIssues/Generic.html.
[GRDDL]
Glâner les descriptions de ressources des dialectes de langages (GRDDL), Dan Connolly, rédacteur, recommandation du W3C, 11 septembre 2007. Cette version est celle à http://www.w3.org/TR/2007/REC-grddl-20070911/. La dernière version est disponible à http://www.w3.org/TR/grddl/.
[HTTP-URI2]
What HTTP URIs Identify, Tim Berners-Lee. 9 juin 2005. Ce document est disponible à http://www.w3.org/DesignIssues/HTTP-URI2.html.
[httpRange]
[httpRange-14] Resolved, Roy Fielding. 18 juin 2005. Ce message archivé de la liste www-tag est disponible à http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html.
[HTTP-SPEC]
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1, http://www.rfc.net/rfc2616.html#s14.1
[N3]
Notation 3, Tim Berners-Lee, Dan Connolly, 2008. Ce document est disponible à http://www.w3.org/TeamSubmission/n3/.
[N3Primer]
Primer: Getting into RDF & Semantic Web using N3, Tim Berners-Lee, 2005. Ce document est disponible à http://www.w3.org/2000/10/swap/Primer
[RDFa Primer]
RDFa Primer 1.0 - Embedding Structured Data in Web Pages, (cf.  http://www.w3.org/2006/07/SWD/RDFa/primer/).
[RDFPrimer]
Introduction à RDF, Frank Manola, Eric Miller, rédacteurs. World Wide Web Consortium, 10 février 2004. Cette version est celle à http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. La dernière version est disponible à http://www.w3.org/TR/rdf-primer/.
[RDFXML]
Spécification de la syntaxe RDF/XML (révisée), Dave Beckett, rédacteur. World Wide Web Consortium, 10 février 2004. Cette version est celle à http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. La dernière version est disponible à http://www.w3.org/TR/rdf-syntax-grammar/.
[Recipes]
Best Practice Recipes for Publishing RDF Vocabularies, Alistair Miles, Thomas Baker, Ralph Swick, rédacteurs. World Wide Web Consortium, 23 janvier 2008. Cette version est celle à http://www.w3.org/TR/2008/WD-swbp-vocab-pub-20080123/. C'est un travail en cours. La dernière version est disponible à http://www.w3.org/TR/swbp-vocab-pub/.
[RFC2616]
RFC 2616: Hypertext Transfer Protocol - HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. IETF, 1999. Ce document est disponible à http://www.ietf.org/rfc/rfc2616.txt.
[RFC3986]
RFC 3986 : Identificateur de ressource uniforme (URI) — Syntaxe générique, T. Berners-Lee, R. Fielding, L. Masinter. IETF, 2005. Ce document est disponible à http://www.ietf.org/rfc/rfc3986.txt.
[SMW]
Semantic Wikipedia, Max Völkel, Markus Krötzsch, Denny Vrandecic, Heiko Haller, Rudi Studer. University of Karlsruhe, 2006. Ce document est disponible à http://www.aifb.uni-karlsruhe.de/WBS/hha/papers/SemanticWikipedia.pdf.
[TAG-Alt]
On Linking Alternative Representations To Enable Discovery And Publishing, T.V. Raman. World Wide Web Consortium, 1 novembre 2006. Cette version est celle à http://www.w3.org/2001/tag/doc/alternatives-discovery-20061101.html. La dernière version est disponible à http://www.w3.org/2001/tag/doc/alternatives-discovery.html.
[TAG-URNs]
Adresses URN, espaces de noms et registres, Henry S. Thompson, David Orchard. World Wide Web Consortium, 17 août 2006. Cette version est celle à http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html. C'est un travail en cours. La dernière version est disponible à http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html.
[TriX]
RDF Triples in XML, Jeremy J. Carroll, Patrick Stickler, 2004. Ce document est disponible à http://www.mulberrytech.com/Extreme/Proceedings/html/2004/Stickler01/EML2004Stickler01.html.
[WP-HTTP]
Hypertext Transfer Protocol, contributeurs de Wikipedia. Wikipedia, 8 octobre 2007.

10. Journal des changements

29 novembre 2006
1.0 version initiale.
9 août 2007
1.1 version revue ; changements fondé sur l'passage en reuve du TAG.
28 novembre 2007
Leo Sauermann a inclus d'autres réactions à partir des examens effectués par le TAG, le groupe SWD et Tim Berners-Lee.
8 décembre 2007
Danny Ayers a effectué une relecture, des changements grammaticaux, idiomatiques ou rédactionnels mineurs (« j'ai essayé de ne faire aucun changement modifiant substantiellement le contenu, même si certains s'en rapprochent ») ; validé contre XHTML avec le mode nxml-mode emacs.
12 décembre 2007
Leo Sauermann a inclus un lien vers GRDDL, suggéré par Danny Ayers, changements mineurs des notes à faire. Document remanié pour le statut de version de travail ; toutes les remarques du SWD, du TAG et de Tim Berners-Lee ont été traitées ou listées dans ce document en tant que travaux à réaliser, en utilisant les symboles @@ et la classe CSS "todo".
17 décembre 2007
Document publié comme version de travail à http://www.w3.org/TR/2007/WD-cooluris-20071217/
23 février 2008
Toutes les remarques reçues à propos de la version de travail.
20 mars 2008
Toutes les remarques prises en compte, les propblèmes listés et couverts dans ce document.
21 mars 2008
Document publié en tant que version de travail en dernier appel à http://www.w3.org/TR/2008/WD-cooluris-20080321/
31 mars 2008
Document publié en tant que note de groupe d'intérêt. Les remarques à propos de la version précédet et les changements sont listés ici.