Lisez-moi S.V.P. 
W3C

Méthodes exemplaires pour la publication des vocabulaires RDF

Note de groupe de travail du W3C du 28 août 2008

Cette version :
http://www.w3.org/TR/2008/NOTE-swbp-vocab-pub-20080828/
Dernière version :
http://www.w3.org/TR/swbp-vocab-pub/
Version précédente :
http://www.w3.org/TR/2008/WD-swbp-vocab-pub-20080123/
Rédacteurs :
Diego Berrueta, Fundación CTIC
Jon Phipps, Cornell University Library
Rédacteurs précédents :
Alistair Miles, STFC Rutherford Appleton Laboratory
Thomas Baker, Goettingen State and University Library
Ralph Swick, W3C

Résumé

Ce document décrit des méthodes exemplaires pour la publication de vocabulaires ou d'ontologies sur le Web (en RDF Schema ou OWL). Les caractéristiques de chaque méthode sont décrites en détails, afin que les concepteurs de vocabulaires puissent choisir la méthode la mieux adaptée à leurs besoins. Chaque méthode introduit des principes généraux et un exemple de configuration à utiliser avec un serveur HTTP Apache (qui peuvent s'adapter à d'autres environnements). Les méthodes sont toutes conçues pour être cohérentes avec l'architecture du Web telle que spécifiée actuellement, même si les exemples de configuration associés ont été gardés volontairement simples.

Statut de ce document

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

Ce document a été préparé par le groupe de travail Semantic Web Deployment (SWD), d'après les travaux précédents du groupe de travail Semantic Web Best Practices and Deployment (SWBPD). Ce travail fait partie de l'activité Semantic Web du W3C.

Ce document est une note présentant quelques pratiques exemplaires. Au moment de la publication, le groupe de travail Semantic Web Deployment ne prévoit pas de poursuivre les travaux sur ce document. Cette version répond à plusieurs remarques faites à propos de la version précédente. En revanche, elle ne cherche pas à traiter le problème connu posé par les valeurs « q » dans la négociation de contenu ni à fournir de méthodes pour publier des vocabulaires utilisant les langages RDFa [RDFA] et GRDDL [GRDDL], tous deux reconnus comme des techniques utiles pour quelques vocabulaires.

Les commentaires sont les bienvenus et peuvent être envoyés à public-swd-wg@w3.org ; veuillez inclure le mot « comment » dans la ligne de sujet. Tous les messages reçus à cette adresse apparaissent dans une archive publique. Le groupe de travail répondra à ces commentaires selon le temps disponible. Nous encourageons la communauté à discuter des aspects de cette note dans la liste de diffusion du groupe d'intérêt Semantic Web à semantic-web@w3.org (archive publique).

Ce document a été produit par un groupe agissant sous couvert de la politique de brevet du W3C du 5 février 2004. Le W3C tient une liste publique des divulgations de brevet faites en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour la divulgation d'un brevet. Quiconque a connaissance réelle d'un brevet qu'il estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 e la politique de brevet du W3C.

La publication en tant que note de groupe de travail n'implique pas l'approbation des membres du W3C. Ce document est une ébauche qui peut être mise à jour, remplacée ou rendue obsolète par d'autres documents à tout instant. Il n'est pas approprié de citer ce document comme autre chose qu'un travail en cours.

Table des matières


Introduction

Ce document s'adresse aux développeurs et aux gestionnaires (maintainers) de vocabulaires en RDFS et OWL (dans cette spécification les mots vocabulaire et ontologie sont employés de manière interchangeable). Il fournit des instructions pas-à-pas pour publier des vocabulaires sur le Web, en donnant des exemples de configuration destinés à couvrir les cas les plus courants. Pour plus d'informations à propos de RDFS et OWL, cf. [RDFS, RDFPrimer, OWLGuide, OWLFeatures].

Ce « livre de cuisine » fournit des « recettes » décrivant les étapes nécessaires pour publier un vocabulaire sur un serveur web et pour configurer le serveur web afin de supporter les applications Semantic Web. La section Choisir une méthode fournit un guide pour choisir la méthode la plus appropriée selon la situation et les exigences. Une fois la méthode choisie, le lecteur peut suivre les étapes, en adaptant les exemples à un vocabulaire particulier.

Toutes les méthodes comportent des exemples de configuration pour le serveur HTTP Apache [APACHE20]. Pour ceux qui ne sont pas déjà familiarisés avec la configuration Apache, l'annexe Configuration Apache fournit une brève introduction aux mécanismes de configuration Apache utilisés dans les exemples, et une information de base pour la recherche des pannes (troubleshooting).

Bien que les exemples de configuration fournis soient spécifiques du serveur HTTP Apache, les principes généraux s'appliquent aussi bien à un autre environnement. Le groupe de travail invite le public à fournir des liaisons pour les autres serveurs. Le W3C propose une page wiki pour recueillir ces liaisons et recommandations non-Apache.

Ce document est destiné principalement aux créateurs de vocabulaires et aux gestionnaires de vocabulaires existants qui recherchent des conseils sur la façon de publier au mieux leurs vocabulaires sur le Web. Ce n'est pas un guide détaillé et exhaustif pour choisir une adresse URI d'espace de noms appropriée au nommage d'un nouveau vocabulaire et des termes qui le composent. Néanmoins, des informations techniques de base à propos des adresses URI d'espace de noms, y compris des considérations à propos du choix de l'adresse URI d'espace de noms d'un vocabulaire, sont données à la section Adresses URI des espaces de noms.

Les méthodes ont toutes été conçues en cohérence avec les principes architecturaux du Web tels que spécifiés actuellement dans le document Architecture du Web [AWWW04]. Afin de vérifier qu'elles le sont bien, nous décrivons un ensemble de conditions minimales à la fin de ce document. Ces conditions minimales servent à articuler les exigences fondamentales des applications Semantic Web. Toutes les méthodes, correctement mises en œuvre, devraient remplir les conditions minimales. Nous donnons également un ensemble de conditions étendues. Les conditions étendues servent à articuler les autres besoins pratiques des développeurs d'application Semantic Web, tels que fournir la documentation d'un vocabulaire sur des pages web en HTML. Les méthodes 3, 4, 5 et 6, correctement mises en œuvre, devraient satisfaire aux conditions étendues.

Pour satisfaire aux conditions étendues, les méthodes 3, 4, 5 et 6 configurent le serveur pour effectuer une négociation de contenu. On explique succintement ce processus à la section Négociation de contenu, en même temps que l'on décrit quelques options pour tenir compte du comportement variable des clients déployés.

L'Annexe A décrit comment adapter les six méthodes présentées dans le corps principal du document au cas particulier des vocabulaires identifiés par des adresses URL persistentes, ou adresses PURL, qui sont résolues en utilisant des services PURL tels que http://purl.org/ [PURL].

Pour la concision, les justifications qui sous-tendent chacune de ces méthodes ne sont pas décrites dans ce document. Les lecteurs qui veulent aller plus loin devraient consulter la section Relations entre les adresses URI et les ressources, dans la spécification « Architecture du Web » [AWWW04], les identificateurs de fragment dans les adresses URI HTTP [RFC3986] [RFC2616], la note de groupe d'intérêt du W3C Adresses URI sympas pour le Web sémantique [COOLURI] et la résolution du groupe d'architecture technique (TAG) du W3C à propos de la portée de la résolution HTTP (connue sous le nom « httpRange-14 ») [HTTPRANGE14].

Enfin, il faudrait noter que les recettes décrites dans ce livre de cuisine ne sont pas les seules façons de publier un vocabulaire ou une ontologie pour les applications Semantic Web. RDFa et son cousin GRDDL offriront peut-être dans un futur proche une méthode efficace pour publier des documents utilisables à la fois par les personnes et les machines. Quoi qu'il en soit, une discussion pratique sur RDFa et GRDDL déborderait de beaucoup le cadre de ce document.


Choisir une méthode

Le choix de la méthode dépend principalement des types de contenu que l'on souhaite fournir à partir de l'adresse URI du vocabulaire et des adresses URI des classes et propriétés que celui-ci définit. Les adresses URI des espaces de noms sont décrites plus en détails à l'Annexe B ; tout au long de ce document, on peut interpréter l'expression « adresse URI du vocabulaire » comme signifiant « adresse URI d'espace de noms du vocabulaire ».

Tableau de sélection rapide

Configuration Espace de noms à dièse Espace de noms à barre oblique
RDF interprétable par une machine méthode  1 méthode  2
RDF interprétable par une machine (avec des adresses PURL) méthode  1a méthode  2a
RDF et un seul document HTML méthode  3 méthode  4
RDF et un seul document HTML (avec des adresses PURL) méthode  3a méthode  4a
RDF et plusieurs documents HTML   méthode  5 ou méthode  6
RDF et plusieurs documents HTML (avec des adresses PURL)   méthode  5a

 

Configuration simple

Les méthodes les plus simples configurent le serveur pour ne fournir que du contenu (RDF) interprétable par une machine à partir de l'adresse URI du vocabulaire.

Si vous utilisez un espace de noms à dièse (hash namespace), voyez la méthode  1 ou la méthode  1a (avec des adresses PURL).

Si vous utilisez un espace de noms à barre oblique (slash namespace), voyez la méthode  2 ou la méthode  2a (avec des adresses PURL).

Configuration étendue

Les méthodes étendues configurent le serveur pour fournir à la fois du contenu (RDF) interprétable par une machine et du contenu (HTML) lisible par un humain (cf. également la section Négociation de contenu ci-dessous). Ces méthodes s'étendent aisément pour servir d'autres types de contenu.

Si vous utilisez un espace de noms à dièse et voulez fournir à la fois du contenu RDF et HTML, voyez la méthode  3 ou la méthode  3a (avec des adresses PURL).

Si vous utilisez un espace de noms à barre oblique et voulez fournir à la fois du contenu RDF et HTML, où le contenu HTML se trouve dans un seul document, voyez la méthode  4 ou la méthode  4a (avec des adresses PURL).

Si vous utilisez un espace de noms à barre oblique et voulez fournir à la fois du contenu RDF et HTML, où le contenu HTML est servi en documents hyperliés individuels pour chaque classe ou propriété, avec un aperçu (par exemple, une table des matières ou un index) à l'adresse URI du vocabulaire, voyez la méthode  5 ou la méthode  5a (avec des adresses PURL).

Si vous utilisez un espace de noms à barre oblique et voulez fournir à la fois du contenu RDF et HTML, où le contenu HTML est servi en documents hyperliés individuels pour chaque classe ou propriété et où le RDF est servi en descriptions liées (bounded) de chaque classe ou propriété, voyez la méthode  6.


Négociation de contenu

Lorsqu'un client HTTP essaye de résoudre une adresse URI, celui-ci peut spécifier quel type (ou types) de contenu il préférerait recevoir en réponse. Il le fait en incluant un champ « Accept » dans l'en-tête du message de requête, dont la valeur donne les types MIME correspondant aux types de contenu préférés. Par exemple, un client HTTP préférant du contenu RDF/XML incluerait le champ suivant dans l'en-tête de chaque requête :

Accept: application/rdf+xml

De même, un client HTTP préférant du contenu HTML, tel qu'un navigateur web, incluerait quelque chose comme le champ suivant dans l'en-tête de chaque requête :

Accept: application/xhtml+xml,text/html

En pratique exemplaire, les clients DEVRAIENT inclure un champ « Accept » dans l'en-tête de requête, en spécifiant explicitement les types de contenu manipulables.

Lorsque le serveur reçoit une requête, il peut utiliser la valeur (ou les valeurs) du champ « Accept » pour sélectionner la réponse la plus appropriée parmi celles disponibles, en essayant de satisfaire aux préférences du client aussi étroitement que possible. Ce processus est un exemple de négociation de contenu [AWWW04].

Les méthodes 1 et 2 ci-dessous ne configurent pas le serveur en vue d'effectuer une négociation de contenu. RDF/XML est le seul type de représentation disponible, qui sera servi indépendamment de la valeur du champ « Accept » envoyé par le client.

Les méthodes 3, 4, 5 et 6 ci-dessous configurent le serveur en vue d'effectuer une négociation de contenu fondée sur la valeur d'en-tête « Accept » envoyée par le client. Toutefois, les exemples de configuration proposés ne gèrent pas entièrement la spécification HTTP en ce qui concerne la négociation de contenu. En réalité, bien que les exemples prennent en compte l'ordre des préférences d'un client, ils ne gèrent pas les instructions « q ». Donc les clients HTTP qui utilisent des valeurs « q » dans le champ « Accept » obtiendront peut-être des résultats inattendus.

Note du rédacteur : Le groupe de travail examine des alternatives qui soient entièrement compatibles avec la spécification HTTP, tout en gardant les méthodes aussi simples que possibles. Ce problème est enregistré sous la référence ISSUE-58 dans le processus de résolution des problèmes du groupe de travail. Les commentaires sur ce sujet sont les bienvenus et devraient être envoyés par courrier électronique au groupe de travail SWD, son objet commençant par « Comment: ISSUE-58 ».

Comportement par défaut

Lorsque le serveur est configuré pour effectuer une négociation de contenu, on doit définir un « comportement par défaut » — le serveur doit être capable de déterminer quelle réponse envoyer au cas où :

  1. le client n'inclut pas de champ « Accept » dans l'en-tête du message de requête (c'est-à-dire que le client n'indique pas de préférence) ;
  2. les valeurs du champ « Accept » ne correspondent pas aux types de contenu disponibles (c'est-à-dire que le client demande autre chose que du RDF/XML ou du HTML).

Dans les méthodes 3, 4, 5 et 6 ci-dessous, la réponse par défaut configurée est RDF/XML. Ce choix minimise l'impact sur les applications Semantic Web existantes qui n'envoient pas les valeurs d'en-tête « Accept » appropriées pour le contenu RDF. Gardons à l'esprit que si HTML était la configuration par défaut, les applications Semantic Web qui attendent du contenu RDF recevraient du HTML à la place, et ne fonctionneraient plus.

Fournir une en-tête « Accept »

Les développeurs et les gestionnaires d'applications Semantic Web, qui attendent du contenu RDF à traiter et qui n'incluent pas encore d'en-tête « Accept » dans les requêtes HTTP, devraient prévoir de fournir une telle en-tête à l'avenir.

Une valeur propice du champ « Accept » est la suivante :

Accept: application/rdf+xml,application/xml;q=0.5

La valeur "q=0.5" dans l'exemple ci-dessus indique une valeur de qualité relative, comme spécifiée par la section 14 du protocole HTTP/1.1 [RFC2616]. La valeur par défaut de « q », si aucune n'est indiquée, est "1.0". Cet exemple signifierait : « Je préfère le type "application/rdf+xml", en lui donnant la valeur de qualité relative par défaut "1.0", toutefois j'accepte aussi "application/xml", mais j'évalue sa valeur relative à 50 % de celle de "application/rdf+xml" ».

Comportement par défaut spécial pour Internet Explorer

Contrairement à la plupart des autres navigateurs, Internet Explorer envoie des en-têtes « Accept » contenant le type fourre-tout */* sans valeur « q » de médiation. Par contraste, les navigateurs Firefox et Safari acceptent */*;q=0.5, et Opera */*;q=0.1. Établir un comportement par défaut qui en tient compte impose l'insertion d'une condition de récriture fondée sur la valeur de l'en-tête « User-agent » :

RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*

En outre, si on veut également retenir des adresses URI « cliquables » dans Internet Explorer, on doit établir HTML comme réponse par défaut (cf. les commentaires dans les exemples pour des instructions pour le faire).

Tester la configuration du serveur

Tester efficacement les résultats de la négociation de contenu peut se révéler très complexe pour certaines méthodes. Pour faciliter les tests des résultats de négociation de contenu sur une seule adresse URI, un service de test de la négociation de contenu a été créé.

Ce service demande une adresse URI auprès d'un serveur, lance une suite de tests conçus spécifiquement pour tester la réponse du serveur par rapport aux spécifications de la méthode, et affiche un rapport réussite/échec pour chaque ensemble de tests ainsi qu'une explication détaillée de ses trouvailles.

Le code source du service de test est également disponible.


Méthode  1 — Configuration minimale pour un « espace de noms à dièse »

Aller directement à : Exemple de configuration | Test de la configuration

Cette méthode donne un exemple de la plus simple configuration possible pour un vocabulaire utilisant un espace de noms à dièse. La méthode configure le serveur pour fournir un contenu interprétable par une machine (RDF) à partir de l'adresse URI du vocabulaire, en satisfaisant ainsi aux conditions minimales. Le diagramme suivant en est l'illustration :

Résoudre l'adresse URI du vocabulaire

Interaction client-serveur

(Sert la description RDF du vocabulaire, codée en RDF/XML).

Exemple de configuration

Pour le vocabulaire…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1

définissant les classes…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#ClassB

et les propriétés…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example1#propB

Étape  1

Créez un fichier nommé example1.rdf qui contient une sérialisation RDF/XML complète du vocabulaire. C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier.

Étape  2

Copiez le fichier example1.rdf dans le répertoire /apachedocumentroot/examples/ sur le serveur.

Étape  3

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ sur le serveur :

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans le fichier de configuration Apache principal
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour servir du RDF/XML à partir de l'adresse URI du vocabulaire
RewriteRule ^example1$ example1.rdf

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

Test de la configuration

Cette configuration fonctionne si elle gère les interactions suivantes :

Résoudre l'adresse URI du vocabulaire

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example1 HTTP/1.1
Host: example.com

L'en-tête de réponse devrait contenir les champs suivants :

HTTP/1.x 200 OK
Content-Type: application/rdf+xml

Méthode  2 — Configuration minimale pour un « espace de noms à barre oblique »

Aller directement à : Exemple de configuration | Test de la configuration

Cette méthode donne un exemple de la plus simple configuration possible pour un vocabulaire utilisant un espace de noms à barre oblique. La méthode configure le serveur pour fournir un contenu interprétable par une machine (RDF) à partir de l'adresse URI du vocabulaire, et rediriger le client vers l'adresse URI du vocabulaire à partir des adresses URI de classe et propriété, en satisfaisant ainsi aux conditions minimales. Les diagrammes suivants en sont l'illustration :

Résoudre l'adresse URI du vocabulaire

Exemple 2 : interaction client-serveur.

(Servir la description RDF du vocabulaire, codée en RDF/XML).

Résoudre l'adresse URI d'une classe ou d'une propriété

Exemple 2 : interaction client-serveur.

(Rediriger le client vers l'adresse URI du vocabulaire).

Exemple de configuration

Pour le vocabulaire…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/

définissant les classes…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/ClassB

et les propriétés…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example2/propB

Étape  1

Créez un fichier nommé example2.rdf qui contient une sérialisation RDF/XML complète du vocabulaire. C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier.

Étape  2

Copiez le fichier example2.rdf dans le répertoire /apachedocumentroot/examples/ sur le serveur.

Étape  3

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ sur le serveur :

# Désactiver MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour une redirection 303 à partir de l'adresse URI d'une classe ou d'une propriété
RewriteRule ^example2/.+ example2/ [R=303]

# Règle de récriture pour servir du RDF/XML à partir de l'adresse URI du vocabulaire
RewriteRule ^example2/$ example2.rdf

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

L'option de répertoire « MultiViews » doit être désactivée pour la bonne marche de cette configuration, et il ne doit pas en fait exister de répertoire nommé /apachedocumentroot/examples/example2/ dans le système de fichiers du serveur.

Test de la configuration

Cette configuration fonctionne si elle gère les interactions suivantes :

Résoudre l'adresse URI du vocabulaire

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example2/ HTTP/1.1
Host: example.com

L'en-tête de réponse devrait contenir les champs suivants :

HTTP/1.x 200 OK
Content-Type: application/rdf+xml

Résoudre l'adresse URI d'une classe ou d'une propriété

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre classe ou propriété) :

GET /examples/example2/ClassA HTTP/1.1
Host: example.com

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse URI de votre vocabulaire en valeur du champ « Location » :

HTTP/1.x 303 See Other*
Location: http://example.com/examples/example2/

* N.d.T. : « See Other » est localisé en « Voir autre » dans les diagrammes.


Méthode  3 — Configuration étendue pour un « espace de noms à dièse »

Aller directement à : Exemple de configuration | Test de la configuration | Notes

Cette méthode donne un exemple de configuration étendue pour un vocabulaire avec un espace de noms à dièse. La méthode configure le serveur pour fournir, à partir de l'adresse URI du vocabulaire, soit un contenu lisible par un humain (HTML), soit un contenu interprétable par une machine (RDF), selon ce qui est demandé, en satisfaisant ainsi aux conditions étendues. Les diagrammes suivants en donnent une illustration :

Résoudre l'adresse URI du vocabulaire, en demandant du contenu HTML

Interaction client-serveur

(Rediriger le client vers la documentation HTML courante du vocabulaire).

Résoudre l'adresse URI du vocabulaire, en demandant du contenu RDF

Interaction client-serveur

(Rediriger le client vers la description RDF courante du vocabulaire).

Exemple de configuration

Pour le vocabulaire…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3

définissant les classes…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#ClassB

et les propriétés…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example3#propB

Étape  1

Créez un fichier nommé 2005-10-31.rdf qui contient une sérialisation RDF/XML complète du vocabulaire, en date du 2005-10-31 (ou quelle que soit la date courante). C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier, lequel représente un « cliché » ou une « version » du vocabulaire.

Étape  2

Créez un fichier nommé 2005-10-31.html qui contient la documentation HTML de toutes les classes et propriétés définies par le vocabulaire en date du 2005-10-31 (ou quelle que soit la date courante). Ce document peut inclure des sections pour chaque classe ou propriété documentée, chaque section étant coiffée d'une ancre HTML dont le nom est identique à l'identificateur de fragment de la classe ou propriété documentée.

Étape  3

Copiez les fichiers 2005-10-31.rdf et 2005-10-31.html dans le répertoire /apachedocumentroot/examples/example3-content/ sur le serveur.

Étape  4

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ :

# Désactivation de MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour servir du HTML à partir de l'adresse URI du vocabulaire si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example3$ example3-content/2005-10-31.html [R=303]

# Règle de récriture pour servir du RDF/XML à partir de l'adresse URI du vocabulaire si demandé
RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example3$ example3-content/2005-10-31.rdf [R=303]

# Choisir la réponse par défaut
# -----------------------------

# Règle de récriture pour servir du RDF/XML à partir de l'adresse URI du vocabulaire par défaut
RewriteRule ^example3$ example3-content/2005-10-31.rdf [R=303]

# Règle de récriture pour servir du HTML à partir de l'adresse URI du vocabulaire par défaut (désactivée)
# (Pour activer cette option, décommentez la règle de récriture ci-dessous, et commentez
# la règle de récriture juste au-dessus)
# RewriteRule ^example3$ example3-content/2005-10-31.html [R=303]

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

Test de la configuration

Cette configuration fonctionne si elle gère les interactions suivantes :

Résoudre l'adresse URI du vocabulaire, en demandant du contenu HTML

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example3 HTTP/1.1
Host: example.com
Accept: text/html

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre contenu HTML en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example3-content/2005-10-31.html

Résoudre l'adresse URI du vocabulaire, en demandant du contenu RDF

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example3 HTTP/1.1
Host: example.com
Accept: application/rdf+xml

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse courante de votre contenu RDF en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example3-content/2005-10-31.rdf

Résoudre l'adresse URI du vocabulaire, cas par défaut

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example3 HTTP/1.1
Host: example.com

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse courante de votre contenu RDF en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example3-content/2005-10-31.rdf

Notes

Cet exemple utilise la date de modification de la version du vocabulaire pour créer les noms de fichier. On pourrait également utiliser des numéros de version (par exemple "1.01") au lieu de dates pour cela, ou en fait toute convention qui permettrait de différencier les versions du vocabulaire et aiderait au suivi de l'historique des versions.

Cf. également la section Négociation de contenu.


Méthode  4 — Configuration étendue pour un « espace de noms à barre oblique », utilisant un seul document HTML

Aller directement à : Exemple de configuration | Test de la configuration | Notes

Cette méthode donne un exemple de configuration étendue pour un vocabulaire avec un espace de noms à barre oblique. La méthode configure le serveur pour fournir, à partir de l'adresse URI du vocabulaire, soit un contenu lisible par un humain (HTML), soit un contenu interprétable par un machine (RDF), selon ce qui est demandé, et rediriger le client à partir des adresses URI de classe et de propriété vers les emplacements des contenus appropriés, encore selon ce qui est demandé, en satisfaisant ainsi aux conditions étendues. La documentation HTML est servie en un seul fichier. Ce comportement est illustré par les diagramme suivants :

Résoudre l'adresse URI du vocabulaire, en demandant du contenu HTML

Interaction client-serveur

(Comme pour la méthode  3, rediriger le client vers la documentation HTML courante du vocabulaire).

Résoudre l'adresse URI du vocabulaire, en demandant du contenu RDF

Interaction client-serveur

(Comme pour la méthode  3, rediriger le client vers la description RDF courante du vocabulaire).

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu HTML

Interaction client-serveur

(Rediriger le client vers le fragment de la documentation HTML courante du vocabulaire concernant la classe ou la propriété).

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu RDF

Interaction client-serveur

(Rediriger le client vers le fragment de la description RDF courante du vocabulaire).

Exemple de configuration

Pour le vocabulaire…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/

définissant les classes…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/ClassB

et les propriétés…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example4/propB

Étape  1

Créez un fichier nommé 2005-10-31.rdf qui contient une sérialisation RDF/XML complète du vocabulaire, en date du 2005-10-31 (ou quelle que soit la date courante). C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier, lequel représente un « cliché » ou une « version » du vocabulaire.

Étape  2

Créez un fichier nommé 2005-10-31.html qui contient la documentation HTML de toutes les classes et propriétés définies par le vocabulaire en date du 2005-10-31 (ou quelle que soit la date courante). Ce document peut inclure des sections pour chaque classe ou propriété documentée, chaque section étant coiffée d'une ancre HTML dont le nom est identique à l'identificateur de fragment de la classe ou propriété documentée.

Étape  3

Copiez les fichiers 2005-10-31.rdf et 2005-10-31.html dans le répertoire /apachedocumentroot/examples/example4-content/ sur le serveur.

Étape  4

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ :

# Désactivation de MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour servir du HTML à partir de l'adresse URI du vocabulaire si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4/$ example4-content/2005-10-31.html [R=303]

# Règle de récriture pour servir du HTML dirigé à partir des adresses URI de classe/propriété
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4/(.+) example4-content/2005-10-31.html#$1 [R=303,NE]

# Règle de récriture pour servir du RDF si demandé
RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example4/ example4-content/2005-10-31.rdf [R=303]

# Choisir la réponse par défaut
# -----------------------------

# Règle de récriture pour servir du RDF/XML par défaut
RewriteRule ^example4/ example4-content/2005-10-31.rdf [R=303]

# Règles de récriture pour servir du HTML par défaut (désactivées)
# (Pour activer cette option, décommentez les deux règles de récriture ci-dessous,
# et commentez la règle de récriture juste au-dessus).
# RewriteRule ^example4/$ example4-content/2005-10-31.html [R=303]
# RewriteRule ^example4/(.+) example4-content/2005-10-31.html#$1 [R=303,NE]
 

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

Pour que cette configuration fonctionne, l'option de répertoire « MultiViews » doit être désactivée, et il ne doit pas en fait exister de répertoire nommé /apachedocumentroot/examples/example4/ dans le système de fichiers du serveur.

Test de la configuration

Cette configuration fonctionne si elle gère les interactions suivantes :

Résoudre l'adresse URI du vocabulaire, en demandant du contenu HTML

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example4/ HTTP/1.1
Host: example.com
Accept: text/html

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre contenu HTML en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.html

Résoudre l'adresse URI du vocabulaire, en demandant du contenu RDF

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example4/ HTTP/1.1
Host: example.com
Accept: application/rdf+xml

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre contenu RDF en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

Résoudre l'adresse URI du vocabulaire, cas par défaut

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example4/ HTTP/1.1
Host: example.com

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre contenu RDF en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu HTML

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre classe ou propriété) :

GET /examples/example4/ClassA HTTP/1.1
Host: example.com
Accept: text/html

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre contenu HTML (plus l'identificateur de fragment approprié) en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.html#ClassA

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu RDF

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre classe ou propriété) :

GET /examples/example4/ClassA HTTP/1.1
Host: example.com
Accept: application/rdf+xml

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre contenu RDF en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

Résoudre l'adresse URI d'une classe ou propriété, cas par défaut

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre classe ou propriété) :

GET /examples/example4/ClassA HTTP/1.1
Host: example.com

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre contenu RDF en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example4-content/2005-10-31.rdf

Notes

Comme avec la méthode  3, cet exemple utilise la date de modification de la version du vocabulaire pour créer les noms de fichier. On pourrait également utiliser des numéros de version (par exemple "1.01") au lieu de dates pour cela, ou en fait toute convention qui permettrait de différencier les versions du vocabulaire et aiderait au suivi de l'historique des versions.

Cf. également la section Négociation de contenu.


Méthode  5 — Configuration étendue pour un « espace de noms à barre oblique », utilisant plusieurs documents HTML

Aller directement à : Exemple de configuration | Test de la configuration | Notes

Cette méthode donne un exemple de configuration étendue pour un vocabulaire avec un espace de noms à barre oblique. La méthode configure le serveur pour fournir à la fois du contenu interprétable par une machine (RDF) et du contenu lisible par un humain (HTML), selon ce qui est demandé, la documentation HTML étant donnée par plusieurs documents HTML hyperliés plus un document d'ensemble. Ce comportement est illustré par les diagrammes suivants :

Résoudre l'adresse URI du vocabulaire, en demandant du contenu HTML

Interaction client-serveur

(Rediriger le client vers la documentation HTML d'ensemble courante du vocabulaire).

Résoudre l'adresse URI du vocabulaire, en demandant du contenu RDF

Interaction client-serveur

(Comme pour la méthode  3 et la méthode  4, rediriger le client vers la description RDF courante du vocabulaire).

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu HTML

Interaction client-serveur

(Rediriger le client vers la documentation HTML courante de la classe ou propriété).

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu RDF

Interaction client-serveur

(Comme pour la méthode  4, rediriger le client vers la description RDF courante du vocabulaire).

Exemple de configuration

Pour le vocabulaire…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/

définissant les classes…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/ClassA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/ClassB

et les propriétés…

http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/propA
http://www.w3.org/2006/07/SWD/recipes/examples-20080421/example5/propB

Étape  1

Créez un fichier nommé 2005-10-31.rdf qui contient une sérialisation RDF/XML complète du vocabulaire, en date du 2005-10-31 (ou quelle que soit la date courante). C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier, lequel représente un « cliché » ou une « version » du vocabulaire.

Étape  2

Copiez le fichier 2005-10-31.rdf dans le répertoire /apachedocumentroot/examples/example5-content/ sur le serveur.

Étape  3

Créez les fichiers ClassA.html, ClassB.html, propA.html, propB.html, chacun contenant la documentation HTML pertinente de la classe ou propriété avec le nom local corresponant, en date du 2005-10-31 (ou quelle que soit la date courante). Créez un fichier index.html qui contient une documentation HTML à propos du vocabulaire même, avec des hyperliens vers toutes les documentations de classe ou propriété.

Étape  4

Copiez les fichiers ClassA.html, ClassB.html, propA.html, propB.html et index.html dans le répertoire /apachedocumentroot/examples/example5-content/2005-10-31-docs/ sur le serveur.

Étape  5

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ :

# Désactivation de MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture 1 : pour servir du HTML à partir de l'adresse URI d'espace de noms si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5/$ example5-content/2005-10-31-docs/index.html [R=303]

# Règle de récriture 2 : pour servir du HTML à partir des adresses URI de classe ou propriété si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5/(.+) example5-content/2005-10-31-docs/$1.html [R=303]

# Règle de récriture 3 : pour servir du RDF si demandé
RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example5/ example5-content/2005-10-31.rdf [R=303]

# Choisir la réponse par défaut
# -----------------------------

# Règle de récriture 4 : pour servir du RDF/XML par défaut
RewriteRule ^example5/ example5-content/2005-10-31.rdf [R=303]

# Règles de récriture pour servir du HTML par défaut (désactivées)
# (Pour activer cette option, décommentez les deux règles de récriture ci-dessous,
# et commentez la règle de récriture juste au-dessus).
# RewriteRule ^example5/$ example5-content/2005-10-31-docs/index.html [R=303]
# RewriteRule ^example5/(.+) example5-content/2005-10-31-docs/$1.html [R=303]

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

Test de la configuration

Cette configuration fonctionne si elle gère les interactions suivantes :

Résoudre l'adresse URI du vocabulaire, en demandant du contenu HTML

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre vocabulaire) :

GET /examples/example5/ HTTP/1.1
Host: example.com
Accept: text/html

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse de votre vue d'ensemble HTML en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example5-content/2005-10-31-docs/index.html

Résoudre l'adresse URI du vocabulaire, en demandant du contenu RDF

Pareil à la méthode  4.

Résoudre l'adresse URI du vocabulaire, cas par défaut

Pareil à la méthode  4.

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu HTML

Message de test (substituez les bons chemins et hôte de l'adresse URI de votre classe ou propriété) :

GET /examples/example5/ClassA HTTP/1.1
Host: example.com
Accept: text/html

L'en-tête de réponse devrait contenir les champs suivants, avec l'adresse du contenu HTML pour la classe ou propriété donnée en valeur du champ « Location » :

HTTP/1.x 303 See Other
Location: http://example.com/examples/example5-content/2005-10-31-docs/ClassA.html

Résoudre l'adresse URI d'une classe ou propriété, en demandant du contenu RDF

Pareil à la méthode  4.

Résoudre l'adresse URI d'une classe ou propriété, cas par défaut

Pareil à la méthode  4.

Notes

Comme avec la méthode  3, cet exemple utilise la date de modification de la version du vocabulaire pour créer les noms de fichier. On pourrait également utiliser des numéros de version (par exemple "1.01") au lieu de dates pour cela, ou en fait toute convention qui permettrait de différencier les versions du vocabulaire et aiderait au suivi de l'historique des versions.

Cf. également la section Négociation de contenu.

Si les options de répertoire Indexes et Multiviews sont activées pour le répertoire /apachedocumentroot/examples/example5-content/2005-10-31-docs/, alors vous pouvez remplacer les règles  1 et  2 par une seule règle de récriture :

RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5/(.*) example5-content/2005-10-31-docs/$1 [R=303]

Cette configuration est particulièrement indiquée pour l'utilisation d'une documentation générée par le module d'extension (plugin) OWLDoc de Protege.


Méthode  6 — Configuration étendue pour un « espace de noms à barre oblique », utilisant plusieurs documents HTML et un service d'interrogation

Cette méthode donne un exemple de configuration étendue pour un vocabulaire avec un espace de noms à barre oblique. La méthode configure le serveur pour fournir à la fois un contenu interprétable par une machine (RDF) et un contenu lisible par un humain (HTML), selon ce qui est demandé, la documentation HTML étant donnée en plusieurs documents HTML hyperliés plus un document d'ensemble, et le contenu RDF étant mis à disposition via un service d'interrogation (query service) de telle sorte que les clients puissent obtenir une description RDF partielle du vocabulaire comme approprié.

Hormis le fait que cette méthode partage presque toutes les caractéristiques de la méthode  5, on peut soutenir que l'utilisation d'un service d'interrogation ou d'un script pour récupérer le contenu RDF en fait la configuration étendue la plus complexe, et présente le plus grand défi à fournir une méthode directement utilisable. C'est pourquoi nous avons décidé de présenter cette méthode comme un ensemble de modèles de mise en œuvre suggérés plutôt que comme une méthode où « il n'y a qu'à suivre les étapes ». De plus, nous ne décrivons pas un modèle de mise en œuvre particulier avec le même niveau de détails employé dans les autres méthodes. Une certaine connaissance de la programmation web est donc nécessaire pour mettre en œuvre cette méthode.

Modèle  1 — Utilisation de la logique d'application

Ce modèle s'appuie sur une logique d'application déployée dans le serveur web. Cette logique peut être une couche mince (thin layer) qui redirige simplement les requêtes (où agit comme un serveur mandataire) vers un serveur web tiers (cf. l'exemple DBPedia ci-dessous), ou une couche épaisse (thick layer) qui charge une source de données RDF et traduit les requêtes HTTP en appels API (API calls) pour exécuter les interrogations.

Il y a deux options pour introduire une logique côté serveur :

  1. Script côté serveur.
    Les langages de script côté serveur communs (PHP, Python, Perl, Ruby) ont des interfaces API RDF et des liaisons avec des référentiels RDF (RDF stores), et on peut les utiliser pour écrire un script simple qui interroge un fichier RDF, ou un référentiel de triplets RDF, et en retourne la portion pertinente.
  2. Servlet Java (ou un équivalent).

Exemple de mise en œuvre (valide pour les deux options).

Dans l'exemple suivant, on utilise le serveur DBPedia comme fournisseur de contenu :

RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/page/$1 [R=303]

RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/data/$1 [R=303]

RewriteRule ^example6/(.+) http://dbpedia.org/data/$1 [R=303]

C'est un exemple de couche de mise en œuvre « mince » (thin implementation layer) et les règles de récriture sont simples :

  1. Les requêtes de données HTML sont renvoyées vers l'adresse URL de la version HTML exportée par le servlet DBPedia ;
  2. Les requêtes de données RDF (ou sans en-tête « Acccept » puisque le comportement par défaut est un retour RDF) sont renvoyées à l'adresse URL des données RDF.

La partie la plus délicate de la mise en œuvre de la méthode  6 utilisant une logique d'application est de réaliser correctement la négociation de contenu HTTP en partant de zéro. Alors que la plupart des langages de script (PHP, Python, etc.) et des infrastructures de développement (frameworks) permettent d'accéder aux valeurs des en-têtes HTTP et donc à l'en-tête « Accept », le choix du type de retour approprié est loin d'être évident. L'en-tête « Accept » peut contenir des jokers (wildcards) et des valeurs « q », et les expressions rationnelles ou les fonctions de comparaison simple des chaînes ne suffisent pas. Il existe une page wiki avec des pointeurs vers des bibliothèques de négociation de contenu pour divers langages de programmation. Le groupe de travail invite le public à fournir des bibliothèques et des infrastructures de développement supplémentaires gérant la négociation de contenu.

Modèle  2 — Redirection vers une extrémité SPARQL avec Apache

Ce modèle n'implique l'écriture d'aucune logique d'application. Au lieu de cela, les requêtes sont redirigées par HTTP en utilisant le module mod_rewrite Apache. Cette technique convient particulièrement bien pour envelopper une extrémité SPARQL (SPARQL endpoint) existante. Nous exploitons le fait que beaucoup d'extrémités SPARQL exportent des liaisons HTTP.

Exemple de mise en œuvre:

RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/$1 [R=303]

RewriteCond %{HTTP_ACCEPT} application/rdf\+xml
RewriteRule ^example6/(.+) http://dbpedia.org/sparql?query=DESCRIBE+<http://dbpedia.org/$1> [R=303]

RewriteRule ^example6/(.+) http://dbpedia.org/sparql?query=DESCRIBE+<http://dbpedia.org/$1> [R=303]

Dans cet exemple, lorsque le client demande du contenu HTML, la requête est renvoyée vers un serveur web externe. En revanche, les requêtes RDF sont manipulées différemment. Une requête pour une adresse URI telle que http://example.org/example6/property/birthplace est redirigée vers le résultat de l'exécution d'une phrase DESCRIBE <http://dbpedia.org/property/birthplace> auprès de l'extrémité SPARQL DBPedia. Le résultat est un graphe RDF qui décrit la ressource (ici la propriété qui lie une personne au lieu de sa naissance).

Études de cas


Exigences

Cette section essaye d'articuler les exigences et attentes quant aux applications et développeurs d'applications Semantic Web en ce qui concerne le comportement HTTP des vocabulaires, classes et propriétés dénotées par des adresses URI HTTP (c'est-à-dire les adresses URI de l'espace URI http:). Elle est conçue comme un banc d'essais auprès duquel peuvent être vérifiés les exemples de configuration donnés dans les méthodes ci-dessus.

Conditions minimales

M1. La description RDF « autoritaire » d'un vocabulaire, d'une classe ou d'une propriété, dénotés par une adresse URI HTTP, peut être obtenue en résolvant l'adresse URI de ce vocabulaire, cette classe ou cette propriété.

Un client HTTP peut obtenir la description RDF « autoritaire » d'un vocabulaire, d'une classe ou d'une propriété en effectuant une requête GET HTTP contre l'adresse URI de ce vocabulaire, cette classe ou cette propriété. La description RDF est retournée par une réponse HTTP dont le type de contenu est un type MIME enregistré pour un contenu RDF (pour l'instant uniquement "application/rdf+xml").

C'est le comportement par défaut au cas où une forme de négociation de contenu aurait été mise œuvre pour ces adresses URI. À savoir, une requête GET HTTP sans champ d'en-tête « Accept » produira une réponse avec le type de contenu "application/rdf+xml", laquelle est une sérialisation d'un ensemble de déclarations RDF, y compris les déclarations qui constituent la description RDF « autoritaire » de la ressource dénotée.

Nota bene : Il est raisonnable qu'une tentative de résoudre l'adresse URI d'une propriété ou classe RDF aboutisse à une description RDF plus grande que juste celle de cette propriété ou classe.

M2. Le comportement d'une adresse URI HTTP dénotant un vocabulaire, une classe ou une propriété RDFS/OWL ne conduit pas à une incohérence dans l'interprétation de la nature de la ressource dénotée.

Actuellement, l'architecture du Web permet aux applications de faire des inférences à propos de la nature d'une ressource dénotée par une adresse URI HTTP, d'après les informations suivantes :

  1. Le code de réponse HTTP obtenu lors de la résolution de l'adresse URI (cf. la résolution du problème TAG "httpRange-14" [HTTPRANGE14] ), et ;
  2. Si l'adresse URI contient un identificateur de fragment, le type de contenu (ou les types) des représentations disponibles [AWWW04].

Au vu de ces contrainte, pour chaque adresse URI dénotant un vocabulaire, une classe ou une propriété RDFS/OWL, la gamme des réponses possibles aux requêtes HTTP vers cette adresse URI ne conduira pas les applications à tirer de quelconques conclusions erronées (inconsistent).

Conditions étendues

Ces conditions augmentent les conditions minimales.

E1. Une documentation « lisible par un humain » à propos d'un vocabulaire, d'une classe ou d'une propriété RDF, dénotés par une adresse URI HTTP, peut être obtenue en résolvant l'adresse URI de ce vocabulaire, cette classe ou cette propriété.

Un client HTTP tel qu'un navigateur web peut obtenir une documentation « lisible par un humain » pertinente à un vocabulaire, une classe ou une propriété RDFS/OWL, en effectuant une requête GET HTTP contre l'adresse URI de ce vocabulaire, cette classe ou cette propriété, en spécifiant les en-têtes « Accept » appropriées pour le type de contenu souhaité dans la requête.

E2. Les applications sont capables de différencier les « versions » d'un vocabulaire.

Les vocabulaires changent avec le temps par l'ajout de propriétés ou de classes, ou la modification éditoriale de leurs descriptions. Les applications ont besoin d'un moyen de différencier les « clichés » successifs des vocabulaires dans le temps. Pour être précis, ce qui est « versionné » est la description d'une propriété, c'est-à-dire un ensemble de déclarations RDF à propos de la propriété, plutôt que la propriété en question, son adresse URI ne changeant pas.

Les conventions courantes pour distinguer les descriptions successives comprennent l'utilisation de chaînes de numéro de version ou de chaînes de date dans les noms de fichier (par exemple 1.01.rdf ou 2005-10-31.rdf), ou dans les chemins (par exemple http://dublincore.org/2008/01/14/dcelements.rdf#title). À noter qu'il n'existe pas actuellement de conventions généralement acceptées pour utiliser des chaînes de date ou de numéro de version de cette façon.


Remerciements

Les exemples essayent de distiller des éléments de bonne pratique à partir des vocabulaires Web Semantic couramment déployés, en particulier les termes de métadonnées Dublin Core, l'ontologie Friend of a Friend et le vocabulaire SKOS Core. Tous ceux ayant contribué au développement de ces pratiques sont vivement remerciés.


Références

Cette bibliographie au format : BibTex | BibTeXML | RDF

APACHE20
Documentation de la version 2.0 du serveur HTTP Apache, The Apache Software Foundation.
Disponible à http://httpd.apache.org/docs/2.0/
AWWW04
Architecture du Web, tome 1, Ian Jacobs et Norman Walsh, World Wide Web Consortium, recommandation du W3C, décembre 2004.
Disponible à http://www.w3.org/TR/2004/REC-webarch-20041215/
COOLURI
Adresses URI pour le Web sémantique, Leo Sauermann, DFKI GmbH; Richard Cyganiak, Freie Universität Berlin, note de groupe d'intérêt du W3C, mars 2008.
Disponible à http://www.w3.org/TR/cooluris/
FOAF
Spécification du vocabulaire FOAF, Dan Brickley et Libby Miller.
Disponible à http://xmlns.com/foaf/0.1/
GRDDL
Glâner les descriptions de ressource dans les dialectes des langues (GRDDL), Dan Connolly, World Wide Web Consortium, recommandation du W3C, septembre 2007
Disponible à http://www.w3.org/TR/grddl/
HTTPRANGE14
Résolution des adresses URI HTTP, Rhys Lewis, Volantis Systems Ltd.
Disponible à http://www.w3.org/2001/tag/doc/httpRange-14/2007-10-04/HttpRange-14.html
Résolution du groupe d'architecture technique (TAG) du W3C sur la portée de la résolution HTTP (appelée également « httpRange-14 »).
Disponible à http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
OWLFeatures
Vue d'ensemble du langage d'ontologie web OWL, Deborah L. McGuinness et Frank van Harmelen, World Wide Web Consortium, recommandation du W3C, février 2004.
Disponible à http://www.w3.org/TR/2004/REC-owl-features-20040210/
OWLGuide
Guide du langage d'ontologie web OWL, Michael K. Smith, Chris Welty et Deborah L. McGuinness, World Wide Web Consortium, recommandation du W3C, février 2004.
Disponible à http://www.w3.org/TR/2004/REC-owl-guide-20040210/
PURL
Introduction aux localisateurs de ressource uniformes persistents, Keith Shafer, Stuart Weibel, Erik Jul et Jon Fausey, 6565 Frantz Road, Dublin, Ohio 43017-3395: OCLC Online Computer Library Center, Inc., 1996.
Disponible à http://purl.oclc.org/docs/inet96.html
RDFa
RDFa dans XHTML — Syntaxe et traitement, B. Adida, M. Birbeck, S. McCarron, S. Pemberton, World Wide Web Consortium, recommandation candidate du W3C, juin 2008
Disponible à http://www.w3.org/TR/2008/CR-rdfa-syntax-20080620/
RDFPrimer
Introduction à RDF, Frank Manola et Eric Miller, World Wide Web Consortium, recommandation du W3C, février 2004.
Disponible à http://www.w3.org/TR/2004/REC-rdf-primer-20040210/
RDFS
Langage de description de vocabulaire RDF 1.0 : RDF Schema, Dan Brickley et R. V. Guha, World Wide Web Consortium, recommandation du W3C, février 2004.
Disponible à http://www.w3.org/TR/2004/REC-rdf-schema-20040210/
RFC2616
Protocole de transfert hypertexte — HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach et T. Berners-Lee, Internet Engineering Task Force, RFC (2616), juin 1999.
Disponible à http://www.ietf.org/rfc/rfc2616.txt
RFC3986
Identificateur de ressource uniforme (URI) — Syntaxe générique, T. Berners-Lee, R. Fielding et L. Masinter, Internet Engineering Task Force, RFC (3986), janvier 2005.
Disponible à http://www.ietf.org/rfc/rfc3986.txt
SKOS
Spécification du vocabulaire SKOS Core, Alistair Miles et Dan Brickley, World Wide Web Consortium, ébauche du W3C, novembre 2005.
Disponible à http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20051102/
XMLNames
Espaces de noms dans XML, Tim Bray, Dave Hollander et Andrew Layman, World Wide Web Consortium, recommandation du W3C, janvier 1999.
Disponible à http://www.w3.org/TR/1999/REC-xml-names-19990114/

Annexe A. Vocabulaires utilisant des adresses PURL pour le nommage

Les adresses PURL (Persistent URLs) sont des adresses URI de l'espace URI http://purl.org/. Les adresses PURL s'appuient sur un service de résolution PURL, qui permet aux propriétaires enregistrés d'un domaine PURL de rediriger les requêtes HTTP pour une adresse PURL vers l'adresse URL d'une ressource arbitraire. Les propriétaires enregistrés d'adresses PURL ne peuvent pas configurer le serveur PURL central sinon spécifier l'adresse URL de redirection de chaque adresse PURL.

Quand le serveur PURL central fut développé à l'origine dans les années 1990, la réponse standard d'un serveur HTTP à une requête pour une adresse PURL était de retourner un code de réponse 302 (« Déplacé temporairement »). L'architecture Web a évolué depuis lors, et le groupe d'architecture technique (TAG) du W3C a décidé, pour les besoins de telles redirections de noms de classe et de propriété RDF, que le code de réponse 303 (« Voir autre ») devrait être retourné (cf. la résolution du TAG de httpRange-14 [HTTPRANGE14]).

Puisque les serveurs PURL utilisent un code de réponse 302, et qu'il n'y a aucun moyen pour l'instant de les configurer pour utiliser des codes de réponse 303, les vocabulaires existants avec des serveurs d'espace de noms à barre oblique http://purl.org ne sont pas strictement conformes aux recommandations courantes du TAG. Ces cas sont traités dans les méthodes suivantes.

Note : À l'heure où nous rédigeons cette ébauche (janvier 2008), une mise à jour du service PURL est en cours. Nous espérons que cette mise à jour répondra au document du TAG sur httpRange-14 et les redirections 303 (cf. http://www.oclc.org/news/releases/200669.htm).

Méthodes PURL : méthode  1a. | méthode  2a. | méthode  3a. | méthode  4a. | méthode  5a.


Méthode  1a. Configuration minimale pour un « espace de noms à dièse » PURL

Cette méthode donne un exemple de configuration qui satisfait aux conditions minimales pour un vocabulaire avec un espace de noms à dièse au sein de l'espace URI http://purl.org/. Seul un contenu interprétable par une machine (RDF) est servi à l'adresse URI d'espace de noms.

Pour le vocabulaire…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a

définissant les classes…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#ClassB

et les propriétés…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example1a#propB

Étape  1

Créez un fichier nommé example1a.rdf qui contient une sérialisation RDF/XML complète du vocabulaire. C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier.

Étape  2

Copiez le fichier example1a.rdf dans le répertoire /apachedocumentroot/examples/ sur le serveur depuis lequel vous souhaitez servir le contenu (ici le serveur est www.w3.org).

Étape  3

Mettez en place l'adresse PURL suivante :

PURL: http://purl.org/NET/SWD/recipes/examples-A/example1a
URL:  http://www.w3.org/2006/07/SWD/recipes/examples/example1a.rdf

Notes

Si le serveur est déjà configuré pour servir des fichiers avec l'extension .rdf comme étant de type de contenu application/rdf+xml, alors vous n'avez rien d'autre à faire. Si ce n'est pas le cas, vous devrez ajouter la directive suivante :

AddType application/rdf+xml .rdf

soit aux fichiers de configuration principaux Apache, soit, si vous n'y avez pas accès, au fichier de configuration par répertoire (.htaccess) du répertoire /apachedocumentroot/examples/ sur le serveur.


Méthode  2a. Configuration minimale pour un « espace de noms à barre oblique » PURL

Cette méthode donne un exemple de configuration qui satisfait aux conditions minimales pour un vocabulaire avec un espace de noms à barre oblique au sein de l'espace URI http://purl.org/. Seul un contenu interprétable par une machine (RDF) est servi à l'adresse URI d'espace de noms.

Nota bene : En date de cette ébauche, cet exemple n'est pas strictement conforme à la résolution du TAG sur httpRange-14 [HTTPRANGE14] parce que les serveurs purl.org utilisent un code de redirection 302, et non un code 303.

Pour le vocabulaire…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/

définissant les classes…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/ClassB

et les propriétés…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/propB

Étape  1

Créez un fichier nommé example2a.rdf qui contient une sérialisation RDF/XML complète du vocabulaire. C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier.

Étape  2

Copiez le fichier example2a.rdf dans le répertoire /apachedocumentroot/examples/ sur le serveur depuis lequel vous souhaitez servir le contenu (ici le serveur est www.w3.org).

Étape  3

Mettez en place la redirection partielle PURL suivante :

RP PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example2a/
URL racine:  http://www.w3.org/2006/07/SWD/recipes/examples/example2a/

Étape  4

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ sur le serveur :

# Désactivation de MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour servir du RDF/XML à partir de toutes les adresses URI partiellement redirigées
RewriteRule ^example2a/ example2a.rdf

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

Notes

Dans la méthode ci-dessus, la seule règle de récriture est une redirection interne. Cela réduit le nombre des redirections externes (c'est-à-dire HTTP) impliquées dans l'action de résolution. Quoiqu'il en soit, vous pourriez aussi mettre en œuvre cette règle de récriture comme redirection externe en remplaçant la règle ci-dessus par la suivante :

# Règle de récriture pour servir du RDF/XML à partir de toutes les adresses URI partiellement redirigées
RewriteRule ^example2a/ example2a.rdf [R=303]

Cela crée une redirection HTTP supplémentaire dans l'action de résolution mais éclaire probablement le client sur le fait que les tentatives de résoudre les adresses URI de vocabulaire, de classe ou de propriété aboutissent toutes au même endroit, et rend effectivement la mise en œuvre PURL courante conforme à la résolution httpRange-14 du TAG [HTTPRANGE14].

Il est également possible d'éviter une configuration du serveur en créant des adresses PURL individuelles pour chaque classe et propriété du vocabulaire, toutes référençant la même adresse URL (plutôt qu'une redirection partielle PURL). Toutefois, si le contenu devait être déplacé par la suite, chaque adresse PURL devrait être mise à jour — une tâche lourde et peu pratique pour des ontologies de moyenne à grande taille.


Méthode  3a. Configuration étendue pour un « espace de noms à dièse » PURL

Cette méthode donne un exemple de configuration qui satisfait aux conditions étendues pour un vocabulaire avec un espace de noms à dièse au sein de l'espace URI http://purl.org/. Le contenu interprétable par une machine (RDF) et le contenu lisible par un humain (HTML) sont tous deux servis à l'adresse URI d'espace de noms.

Pour le vocabulaire…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a

définissant les classes…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#ClassB

et les propriétés…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a#propB

Étape  1

Créez un fichier nommé 2005-10-31.rdf qui contient une sérialisation RDF/XML complète du vocabulaire, en date du 2005-10-31 (ou quelle que soit la date courante). C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier, lequel représente un « cliché » ou une « version » du vocabulaire.

Étape  2

Créez un fichier nommé 2005-10-31.html qui contient la documentation HTML de toutes les classes et propriétés définies par le vocabulaire en date du 2005-10-31 (ou quelle que soit la date courante). Ce document peut inclure des sections pour chaque classe ou propriété documentée, chaque section étant coiffée d'une ancre HTML dont le nom est identique à l'identificateur de fragment de la classe ou propriété documentée.

Étape  3

Copiez les fichiers 2005-10-31.rdf et 2005-10-31.html dans le répertoire /apachedocumentroot/examples/example3a-content/ sur le serveur depuis lequel vous souhaitez servir le contenu (ici le serveur est www.w3.org).

Étape  4

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ :

# Désactivation de MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour s'assurer de servir du HTML à partir de l'espace URI d'espace de noms si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example3a$ example3a-content/2005-10-31.html [R=303]

# Règle de récriture pour s'assurer de servir du RDF/XML à partir de l'adresse URI d'espace de noms par défaut
RewriteRule ^example3a$ example3a-content/2005-10-31.rdf [R=303]

Étape  5

Mettez en place l'adresse PURL suivante :

PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example3a
URL:  http://www.w3.org/2006/07/SWD/recipes/examples/example3a

Notes

Puisque nous ne pouvons pas configurer le serveur PURL pour une négociation de contenu, cet exemple configure le serveur de contenu pour effectuer la négociation après la redirection 302 du serveur PURL.


Méthode  4a. Configuration étendue pour un « espace de noms à barre oblique PURL, utilisant un seul document HTML

Cette méthode donne un exemple de configuration qui satisfait aux conditions étendues pour un vocabulaire avec un espace de noms à barre oblique au sein de l'espace URI http://purl.org/. Le contenu interprétable par une machine (RDF) et le contenu lisible par un humain (HTML) sont tous deux servis à l'adresse URI d'espace de noms. La documentation HTML est servie en un seul fichier.

Nota bene : Cet exemple n'est pas strictement conforme à la résolution du TAG sur httpRange-14 [HTTPRANGE14] parce que les serveurs purl.org utilisent un code de redirection 302, et non un code 303.

Pour le vocabulaire…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/

définissant les classes…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/ClassB

et les propriétés…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/propB

Étape  1

Créez un fichier nommé 2005-10-31.rdf qui contient une sérialisation RDF/XML complète du vocabulaire, en date du 2005-10-31 (ou quelle que soit la date courante). C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier, lequel représente un « cliché » ou une « version » du vocabulaire.

Étape  2

Créez un fichier nommé 2005-10-31.html qui contient la documentation HTML de toutes les classes et propriétés définies par le vocabulaire en date du 2005-10-31 (ou quelle que soit la date courante). Ce document peut inclure des sections pour chaque classe ou propriété documentée, chaque section étant coiffée d'une ancre HTML dont le nom est identique à l'identificateur de fragment de la classe ou propriété documentée.

Étape  3

Copiez les fichiers 2005-10-31.rdf et 2005-10-31.html dans le répertoire /apachedocumentroot/examples/example4a-content/ sur le serveur depuis lequel vous souhaitez servir le contenu (ici le serveur est www.w3.org).

Étape  4

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ :

# Désactivation de MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour servir du HTML à partir de l'adresse URI d'espace de noms si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4a/$ example4a-content/2005-10-31.html [R=303]

# Règle de récriture pour servir du HTML dirigé à partir des adresses URI de classe/propriété
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example4a/(.+) example4a-content/2005-10-31.html#$1 [R=303,NE]

# Règle de récriture pour servir du RDF/XML à partir de l'adresse URI d'espace de noms par défaut
RewriteRule ^example4a/ example4a-content/2005-10-31.rdf [R=303]

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

Étape  5

Mettez en place la redirection partielle PURL suivante :

RP PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example4a/
URL racine:  http://www.w3.org/2006/07/SWD/recipes/examples/example4a/

Notes

Cette configuration serait la plus appropriée pour les termes de métadonnées Dublin Core.


Méthode  5a. Configuration étendue pour un « espace de noms à barre oblique », utilisant plusieurs documents HTML

Cette méthode donne un exemple de configuration qui satisfait aux conditions étendues pour un vocabulaire avec un espace de noms à barre oblique au sein de l'espace URI http://purl.org/ . Le contenu interprétable par une machine (RDF) et le contenu lisible par un humain (HTML) sont tous deux servis à l'adresse URI d'espace de noms, avec la documentation HTML donnée en plusieurs documents HTML hyperliés plus un document d'ensemble.

Nota bene : Cet exemple n'est pas strictement conforme à la résolution du TAG sur httpRange-14 [HTTPRANGE14] parce que les serveurs purl.org utilisent un code de redirection 302, et non un code 303.

Pour le vocabulaire…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/

définissant les classes…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/ClassA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/ClassB

et les propriétés…

http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/propA
http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/propB

Étape  1

Créez un fichier nommé 2005-10-31.rdf qui contient une sérialisation RDF/XML complète du vocabulaire, en date du 2005-10-31 (ou quelle que soit la date courante). C'est-à-dire que toutes les ressources définies par le vocabulaire sont décrites dans ce fichier, lequel représente un « cliché » ou une « version » du vocabulaire.

Étape  2

Copiez le fichier 2005-10-31.rdf dans le répertoire /apachedocumentroot/examples/example5a-content/ sur le serveur depuis lequel vous souhaitez servir le contenu (ici le serveur est www.w3.org).

Étape  3

Créez les fichiers ClassA.html, ClassB.html, propA.html, propB.html, chacun contenant la documentation HTML pertinente à la classe ou propriété avec le nom local correspondant, en date du 2005-10-31 (ou quelle que soit la date). Créez un fichier index.html qui contient la documentation HTML à propos du vocabulaire même, avec des hyperliens vers toutes les documentations de classe ou propriété.

Étape  4

Copiez les fichiers ClassA.html, ClassB.html, propA.html, propB.html et index.html dans le répertoire /apachedocumentroot/examples/example5a-content/2005-10-31-docs/ sur le serveur depuis lequel vous souhaitez servir le contenu (ici le serveur est www.w3.org).

Étape  5

Ajoutez les directives suivantes au fichier .htaccess dans le répertoire /apachedocumentroot/examples/ :

# Désactivation de MultiViews
Options -MultiViews

# Directive pour s'assurer que les fichiers *.rdf seront servis avec le bon type de contenu,
# si non présente dans la configuration principale Apache
AddType application/rdf+xml .rdf

# Réglage du moteur de récriture
RewriteEngine On
RewriteBase /examples

# Règle de récriture pour servir du HTML à partir de l'adresse URI d'espace de noms si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5a/$ example5a-content/2005-10-31-docs/index.html [R=303]

# Règle de récritre pour servir du HTML à partir des adresses URI de classe ou propriété si demandé
RewriteCond %{HTTP_ACCEPT} !application/rdf\+xml.*(text/html|application/xhtml\+xml)
RewriteCond %{HTTP_ACCEPT} text/html [OR]
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml [OR]
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/.*
RewriteRule ^example5a/(.+) example5a-content/2005-10-31-docs/$1.html [R=303]

# Règle de récriture pour servir du RDF/XML à partir de l'adresse URI d'espace de noms par défaut
RewriteRule ^example5a/ example5a-content/2005-10-31.rdf [R=303]

(Nota bene : S'il n'y a pas de fichier .htaccess, créez-en un).

Étape  6

Mettez en place la redirection partielle PURL suivante :

RP PURL: http://purl.oclc.org/NET/SWD/recipes/examples-A/example5a/
URL racine: http://www.w3.org/2006/07/SWD/recipes/examples/example5a/

Annexe B. Adresses URI des espaces de noms

L'adresse URI qui identifie un vocabulaire est appelée dans ce document adresse URI d'espace de noms de vocabulaire (vocabulary namespace URI) ou juste adresse URI de vocabulaire (ou adresse URI d'ontologie étant donné que l'on emploie ici vocabulaire et ontologie de manière interchangeable). Par exemple, l'adresse URI suivante identifie le vocabulaire SKOS Core :

http://www.w3.org/2004/02/skos/core

et l'adresse URI suivante identifie l'ontologie FOAF :

http://xmlns.com/foaf/0.1/

Vocabulaires utilisant un « espace de noms à dièse »

SKOS Core [SKOS] est un exemple de vocabulaire qui utilise un espace de noms à dièse (hash namespace). C'est une expression informelle qui se rapporte à la façon dont les adresses URI des classes et propriétés du vocabulaire sont construites. Dans ce cas, les adresses URI des classes et propriétés se construisent en ajoutant d'abord un caractère dièse « # » puis un « nom local » à l'adresse URI du vocabulaire. Le nom local est une chaîne de caractères qui identifie systématiquement cette classe ou propriété dans la portée du vocabulaire, appelée aussi « identificateur de fragment » [AWWW04] (le nom local doit être un atome NCName légal [XML-NS]).

Par exemple, les adresses URI suivantes identifient une classe et une propriété du vocabulaire SKOS Core :

http://www.w3.org/2004/02/skos/core#Concept
http://www.w3.org/2004/02/skos/core#prefLabel

Vocabulaires utilisant un « espace de noms à barre oblique »

FOAF [FOAF] est un exemple de vocabulaire qui utilise un espace de noms à barre oblique (slash namespace). Pareillement, c'est une expression informelle qui se rapporte à la façon dont les adresses URI des classes et propriétés définies par le vocabulaire sont construites. Dans ce cas, l'adresse URI du vocabulaire se termine par un caractère barre oblique « / », et les adresses URI des classes et propriétés se construisent en ajoutant directement à la fin de l'adresse URI du vocabulaire le « nom local » de la classe ou propriété. De même, le nom local est une chaîne de caractères qui identifie systématiquement cette classe ou propriété dans la portée du vocabulaire, et qui doit être un atome NCName légal [XML-NS].

Par exemple, les adresses URI suivantes identifient une classe et une propriété du vocabulaire FOAF :

http://xmlns.com/foaf/0.1/Person
http://xmlns.com/foaf/0.1/maker

Notez qu'un vocabulaire dont l'adresse URI se termine par un caractère barre oblique n'utilise pas forcément un espace de noms à barre oblique. Il pourrait utiliser un espace de noms à dièse ; par exemple, le vocabulaire http://example.org/myvocabulary/ pourrait définir les classes http://example.org/myvocabulary/#Foo et http://example.org/myvocabulary/#Bar.

Les espaces de noms à dièse comme les espaces de noms à barre oblique sont gérés dans l'architecture du Web. Toutefois, certains comportements imposés au serveur web diffèrent pour ces deux options. Puisque les requêtes reçues comme les réponses retournées par le serveur diffèrent dans chaque cas, les mécaniques de paramétrage d'un serveur HTTP afin de satisfaire en totalité ou en partie aux conditions indiquées plus haut diffèrent également, et ces deux cas sont donc traités séparément.

Vocabulaires utilisant d'autres types d'espace de noms

Les lecteurs doivent savoir qu'un troisième type d'adresse URI de vocabulaire est en discussion au moment de la rédaction : les adresses URI fondées sur un service de redirection 303 tel que http://thing-described-by.org. Bien que plus simple à mettre en œuvre que les approches décrites dans ce document, la redirection 303 n'est pas encore implémentée pour les vocabulaires RDF stables publiés, et n'est utilisée dans aucune des méthodes suivantes. L'Annexe C décrit cette approche plus en détails.

Quelques considérations pour le choix d'une adresse URI d'espace de noms

Ce document s'adresse aux créateurs de vocabulaires et aux gestionnaires de vocabulaires existants. Ce document n'a pas vocation à être un guide exact pour choisir la meilleure adresse URI d'espace de noms dans une situation donnée. Toutefois, les méthodes indiquées ici font des suppositions et impliquent des compromis en ce qui concerne la fonctionnalité, et nous décrivons donc ici quelques points pertinents pour le choix d'une adresse URI d'espace de noms. Si vous avez déjà choisi une adresse URI d'espace de noms, passez cette section et allez Choisir une méthode.

L'adresse URI d'espace de noms que vous choisirez pour votre vocabulaire devrait être une adresse web (une adresse URI) pour laquelle vous avez un accès en écriture (write access). Les utilisateurs de votre vocabulaire s'attendront à pouvoir résoudre l'adresse URI du vocabulaire même, ainsi que les adresses URI des propriétés et classes définies par le vocabulaire. Le choix d'une adresse URI d'espace de noms est une décision fondamentale prise tôt dans la conception de votre vocabulaire.

Bien que RDF permette qu'un nom d'espace de noms commence par n'importe quel schéma URI (URI scheme) valide, une pratique exemplaire pour le Web sémantique est d'utiliser un schéma URI qui soit résolvable par tout client sans nécessiter l'emploi de modules d'extension supplémentaires ou une autre configuration de mise en place du client. Le schéma URI http est le plus connu d'entre eux et est reconnu par tous les clients web. Ce document se concentre exclusivement sur les vocabulaires dont l'espace de noms commence par http:.

La pratique exemplaire dicte que tous les vocabulaires RDF emploient soit un espace de noms à dièse, soit un espace de noms à barre oblique (cf. ci-dessus). Lequel choisir dépend en partie de ce que vous prévoyez pour l'ampleur de votre vocabulaire, pour la fréquence d'ajout des nouveaux termes (c'est-à-dire des propriétés ou des classes) et pour la façon dont les utilisateurs accéderont aux informations à propos des termes individuels dans votre vocabulaire.

Pour des petits vocabulaires, il sera peut-être plus commode de servir le vocabulaire entier en un seul accès web. Un tel vocabulaire utilisera typiquement un espace de noms à dièse, et un accès web (c'est-à-dire une requête GET HTTP) pour un terme dans le vocabulaire retournera une seule ressource d'information (information resource) décrivant tous les termes dans le vocabulaire.

Un vocabulaire volumineux, pour lequel on prévoit des ajouts fréquents, ou qui définit plus de données auxquelles une application utilisatrice typique voudra bien accéder à un certain moment, devrait être organisé de telle façon que l'on puisse récupérer progressivement plus de détails à propos des termes dans le vocabulaire au travers de plusieurs accès web. La description complète de tous les termes peut être divisée en plusieurs ressources d'information, ou être gérée via un service d'interrogation (par exemple [SPARQL] — cf. la méthode  6). Un tel vocabulaire utiliserait typiquement un espace de noms à barre oblique, lequel offre une possibilité d'accès web à un terme du vocabulaire retournant essentiellement une information à propos de ce seul terme. (Une telle configuration n'est pas possible pour un vocabulaire utilisant un espace de noms à dièse, du fait de la mécanique du protocole HTTP).

On trouvera des discussions plus détaillées des problèmes liés à la conception des adresses URI pour le Web sémantique dans les documents suivants :


Annexe C. Adresses URI de vocabulaire fondées sur un service de redirection 303

Les adresses URI de ce type sont formées en ajoutant l'adresse URI d'une ressource descriptive comme une chaîne d'interrogation (query string) à la fin de l'adresse URI de base d'un service de redirection 303 tel que http://thing-described-by.org. Le domaine thing-described-by.org délègue l'autorité de la définition de la signification d'une telle adresse URI d'interrogation au domaine cité dans la chaîne d'interrogation (c'est-à-dire la partie qui suit le point d'interrogation).

En principe, on pourrait alors fabriquer l'adresse URI http://thing-described-by.org?http://example.org/foo pour être l'identificateur du vocabulaire Foo. Une requête GET HTTP pour l'adresse URI du vocabulaire Foo, ou pour une propriété ou classe dans le vocabulaire Foo, produirait un code de réponse 303, en conformité donc avec la deuxième des conditions minimales articulées dans ce document pour la publication de vocabulaires RDF. Si, en outre, l'adresse URI http://example.org/foo identifiait une description RDF autoritaire du vocabulaire et que le serveur fournissant cette description retournait un type MIME l'identifiant correctement comme telle, alors on pourrait dire que l'utilisation de http://thing-described-by.org?http://example.org/foo est également conforme à la première des conditions minimales.


Annexe D. Configuration Apache

Un serveur HTTP Apache [APACHE20] est configuré par des directives écrites soit dans les fichiers de configuration Apache principaux (habituellement "httpd.conf", etc.), soit dans des fichiers de configuration par répertoire (habituellement ".htaccess"). Les méthodes données ici supposent que vous n'ayez pas accès aux fichiers de configuration Apache principaux et que vous devez donc utiliser une configuration par répertoire utilisant des fichiers .htaccess pour fournir les directives de configuration. Vous trouverez des informations plus spécifiques à propos de l'utilisation des fichiers .htaccess dans le Tutoriel Apache — Fichiers .htaccess.

Si vous disposez d'un accès en écriture aux fichiers de configuration Apache principaux, vous considérerez d'y écrire directement les directives de configuration, puisque l'utilisation d'une configuration par répertoire peut affecter négativement les performances du serveur et nécessiter une configuration plus soignée de la sécurité au niveau du répertoire, cf. le Tutoriel Apache — Quand (ne pas) utiliser des fichiers .htaccess. Il est à noter que AllowOverride est une directive au niveau répertoire et que ses effets secondaires quant aux performances et à la sécurité ne s'étendent normalement pas au-delà des arbres de répertoire dans lesquels elle est activée.

Note : Les configurations données ici ont uniquement été testées sur un serveur HTTP Apache version 2.0.46.

Configuration du serveur

Pour supporter l'utilisation de fichiers de configuration par répertoire, le serveur doit être configuré afin d'autoriser certaines priorités (overrides) pour les répertoires que vous utilisez. Les priorités nécessaires sont les suivantes :

AllowOverride FileInfo Options

De plus, assurez-vous que votre version d'Apache a été compilée avec le module mod_rewrite, ou que l'objet DSO (Dynamic Shared Object) mod_rewrite a été installé, et que les lignes suivantes apparaissent dans le fichier de configuration Apache :

AddModule mod_rewrite.c
LoadModule rewrite_module modules/mod_rewrite.so

Si vous avez des difficultés à faire fonctionner les méthodes, il se peut que les directives prioritaires nécessaires ne soient pas spécifiées dans les fichiers de configuration Apache principaux, ou que mod_rewrite ne soit pas disponible.

Tester la lecture des fichiers .htaccess

Pour tester si votre serveur lit correctement le fichier .htaccess dans un répertoire donné, saisissez dans un navigateur une adresse URL qui mène à un fichier dans le répertoire que vous souhaitez tester puis vérifiez que le fichier est servi correctement. Ensuite créez (ou éditez) un fichier .htaccess dans ce répertoire contenant la ligne suivante :

InvalidDirective Here

Rechargez l'adresse URL dans votre navigateur. Si le serveur lit les fichiers .htaccess dans ce répertoire, il devrait retourner une page « Erreur interne du serveur » (Internal Server Error) générée par la directive erronée InvalidDirective. Si la page s'affiche à nouveau normalement, vous devrez alors demander à votre administrateur système d'autoriser les fichiers .htaccess dans les répertoires que vous utiliserez avec les méthodes. Une fois obtenue la confirmation que le serveur lit vos fichiers .htaccess, il ne faudra pas oublier de supprimer la ligne InvalidDirective du fichier .htaccess dans ce répertoire.

Tester si mod_rewrite est installé

Pour tester si mod_rewrite est installé, remplacez la ligne InvalidDirective du premier test par celle-ci :

RewriteEngine On

Rechargez l'adresse URL dans votre navigateur. Si mod_rewrite n'est pas installé, ou si vous avez des permissions prioritaires insuffisantes pour l'activer dans le fichier .htaccess de ce répertoire, le serveur devrait alors retourner une page « Erreur interne du serveur ». La directive AllowOverride doit être paramétrée avec FileInfo (ou All) pour vous permettre d'activer mod_rewrite dans un fichier .htaccess.

Paramétrer le type de contenu RDF/XML

Le type de contenu approprié pour servir du RDF/XML est "application/rdf+xml", comme défini dans le document RFC3870. On peut configurer le serveur Apache pour reconnaître les fichiers avec l'extension ".rdf" et les servir avec le type de contenu approprié, en ajoutant la directive suivante au fichier .htaccess :

AddType application/rdf+xml .rdf

Cette directive peut aussi s'appliquer globalement au niveau du serveur dans le fichier de configuration du serveur. Auquel cas, on peut l'omettre des méthodes en toute sécurité.

Alternatives aux règles de récriture

Les exemples de configuration décrits dans ce document mettent en œuvre une négociation de contenu au moyen de règles de récriture (mod_rewrite) afin de rediriger les requêtes vers la représentation qui convient le mieux. Ce mécanisme est simple et autorise une grande flexibilité en ce qui concerne la localisation des documents HTML et RDF/XML, lesquels peuvent même se trouver sur des serveurs différents.

Il y a quelques cas où l'exemple de configuration fourni ne gère pas correctement la négociation de contenu. En particulier, les requêtes avec une en-tête « Accept » contenant des valeurs « q » ne peuvent pas être interprétées par des règles de récriture, et le serveur peut répondre par une représentation différente de celle préférée. Bien qu'il soit certainement possible de configurer un serveur Apache pour gérer de telles requêtes, cette configuration ne peut pas être jouée dans les limites des fichiers .htaccess. Il n'est pas dans l'intention de ce document de fournir un exemple de configuration serveur complet pour gérer ces requêtes. Les lecteurs intéressés pourront étudier la négociation de contenu avec des cartes de types dans Apache.


Valid XHTML 1.0 Strict Valid CSS!