The Family Online Safety Institute

L’ICRA a pour mission d’aider les internautes à trouver ce qu’ils cherchent, à faire confiance à ce qu’ils trouvent et à éviter les contenus qu’ils considèrent inappropriés pour eux-mêmes ou leurs enfants. Un vocabulaire est mis à votre disposition. Il peut être utilisé pour décrire n’importe quel contenu numérique et reflète bon nombre des différentes préoccupations des parents dans le monde entier². Cependant, le système utilisé peut comporter n’importe quel type de métadonnées, quel que soit leur objectif.

Les descriptions sont comprises par l’ordinateur et peuvent être utilisées par divers agents comme les filtres, les moteurs de recherche et les applications d’aide qui affichent des informations supplémentaires à l’attention des utilisateurs.

Les étiquettes ICRA sont codées en RDF³, l’une des technologies clés à la base du Web sémantique⁴. Ce document ne détaille pas les nombreux avantages qu’offre le Web sémantique aux fournisseurs de contenus, à l’exception d’une seule remarque : certaines fonctions comme le RSS, les signets partagés, les blogues et les sites Wiki y contribuent.

L’espace de nommage du système RDF qui forme le cadre des étiquettes ICRA est http://www.w3.org/2004/12/q/contentlabel# et le nom qualifié recommandé est étiquette. Une documentation traitant de ce point est disponible sur http://www.w3.org/2004/12/q/doc/content-labels-schema.htm.

L’espace de nommage du vocabulaire de l’ICRA est http://www.icra.org/rdfs/vocabularyv03# et le nom qualifié recommandé est icra. Vous trouverez la version texte du vocabulaire de l’ICRA et ses définitions supplémentaires sur http://www.icra.org/vocabulary.

Une Etiquette de contenu est une description, c’est à dire un ensemble de métadonnées, qui peut être appliquée à plusieurs ressources. Une ou plusieurs étiquettes sont placées dans un fichier auquel les ressources sont reliées soit par une balise de lien (X)HTML soit par un en-tête de réponse HTTP.

Le fichier qui contient les étiquettes est un fichier RDF généralement appelé labels.rdf. Ceci est le nom du fichier créé par le générateur d’étiquettes de l’ICRA (voir paragraphe 2.3), mais celui-ci n’a pas d’importance et peut être modifié.

Les ressources peuvent être reliées soit à une étiquette précise soit à un ensemble de données permettant aux clients d’associer l’URI de la ressource à une série de règles qui attribuent l’étiquette adéquate.

Les fournisseurs de contenus peuvent donc décider si l’association entre la ressource et son étiquette se fait du côté client ou du côté serveur.

La Figure 2 illustre l’autre approche. Toutes les ressources sont reliées au fichier RDF, mais le lien n’identifie pas l’étiquette. En fait, le fichier RDF définit une étiquette par défaut et peut ensuite également définir une série de règles, basées sur les expressions rationnelles Perl 5, qui peuvent annuler l’étiquette par défaut. La première règle de la série qui sera remplie identifiera l’étiquette appropriée.

Figure 2 Association des ressources et des étiquettes côté client

Si le fichier RDF s’appelle labels.rdf et se trouve dans la racine du site Web, la balise de lien est illustrée dans l’Exemple 3 :

Exemple 3 Balise typique reliant une ressource à un fichier RDF qui contient des règles permettant d’identifier l’étiquette appropriée.

L’en-tête de réponse HTTP équivalent est :

Link: ; /=”/”; rel=”meta” type=”application/rdf+xml”; title=”ICRA labels”;

Exemple 4 En-tête de réponse HTTP équivalent à l’Exemple 3.

Comme pour l’Exemple 1, l’emplacement et le nom du fichier RDF n’ont aucune importance.

L’ICRA fournit, sur son site Web, un outil permettant de créer le fichier RDF et les balises nécessaires. C’est le générateur d’étiquettes⁵. Cet outil peut être utilisé par des personnes ayant peu ou pas de connaissances des techniques de conception Web comme par les utilisateurs expérimentés. Le générateur d’étiquettes crée le fichier RDF d’après le modèle de traitement côté client décrit ci-dessus (paragraphe 2.2), mais peut également être utilisé pour le modèle côté serveur.

Le fichier RDF doit définir une ou plusieurs étiquettes. Plus précisément, il doit définir au moins un exemple d’étiquette de contenu de type RDF comme défini par http://www.w3.org/2004/12/q/contentlabel#ContentLabel.

NB. Les étiquettes de contenu RDF peuvent contenir des instructions provenant de n’importe quel système RDF ; cependant, ce document ne traite que de la version de l’ICRA.

Le fichier RDF peut également définir aucun ou plusieurs des éléments suivants :

1. Le ou les hôte(s) pour le(s)quel(s) la ou les étiquette(s) s’applique(nt). Les sous-domaines entrent dans le champ d’application.
2. Une chaîne supplémentaire qui doit correspondre à l’URI de la ressource pour que les étiquettes du fichier RDF puissent être appliquées.
3. L’étiquette par défaut.
4. Une série de règles ordonnées qui devront être associées à l’URI d’une ressource. Si une règle est remplie, elle doit fournir une étiquette qui annule l’étiquette par défaut.
5. Une description du fichier RDF lui-même qui indique où se trouvent les informations supplémentaires concernant l’étiquette, y compris la façon dont sa véracité peut être évaluée.

Ces éléments sont détaillés dans l’Exemple 5. Comme tous les exemples de ce document et tous les autres fournis par l’ICRA, le RDF est sérialisé en XML. Cependant, ceci n’est pas obligatoire ; d’autres sérialisations, comme N3⁶, sont tout aussi valides.

  
    
    http://www.icra.org/rdfs/vocabularyv03#
    
   

  
    
      
        example.org
        example.com
      
    
    

    
      
        photography
        
      
  
     
       guestbook
        messages
        
      
    
  

  
    Label for all/most of website
    No nudity, no sexual content, no violence, no 
     potentially offensive language, no potentially harmful 
     activities, no user-generated content
    1
    1
    1
    1
    1
    1
  

  
    Label for photography section
    Exposed breasts, Bare buttocks, No sexual 
    content, no violence, no potentially offensive language, 
    no potentially harmful activities, no user-generated 
    content, This material appears in an artistic 
    context
    1
    1
    1
    1
    1
    1
    1
    
  

  
    Label for guestbook and message board
    
    No nudity, no sexual content, no violence, no 
    potentially offensive language, no potentially harmful 
    activities, user-generated content 
    (moderated)
    1
    1
    1
    1
    1
    1
  

Exemple 5 Exemple de fichier RDF contenant des étiquettes ICRA

Les espaces de nommage sont définis. Les noms qualifiés label et icra sont recommandés pour leurs espaces de nommage respectifs.

3.1.2 Section 2

Cette courte section indique que les étiquettes ont été créées par l’ICRA et que de plus amples informations sont disponibles sur www.icra.org. Etant donné qu’il est possible d’inclure des descriptions basées sur d’autres systèmes, cette section précise que www.icra.org possède uniquement des informations sur l’espace de nommage ICRA.

3.1.3 Section 3

Cette section indique les hôtes pour lesquels les données sont valides. Dans le cas présent, nous avons indiqué que les étiquettes peuvent être appliquées à example.org et à example.com. Les sous-domaines, comme par exemple www.example.org, sub.example.com, etc. sont couverts.

Cette section indique également que l’étiquette par défaut pour les contenus hébergés sur ces hôtes est l’ « étiquette_1 » (label_1) (voir 3.1.5).

Si les étiquettes devaient être restreintes à un emplacement spécifique des hôtes example.org et example.com, ceci serait indiqué comme ci-dessous :

foo

Les étiquettes de ce fichier RDF seraient alors seulement appliquées aux ressources dont les URI, sur les hôtes example.org ou example.com, contiennent également « foo ». Cette fonction s’adresse avant tout aux FAI qui offrent un espace Web personnel avec des URL de type www.exemple.org/nom d’utilisateur. Si plusieurs propriétés hasURI sont inclues, un URI se trouve dans le champ d’application si l’un d’entre eux correspond.

3.1.4 Section 4

Les règles qui déterminent les endroits où l’étiquette par défaut devrait être ignorée au profit d’une autre étiquette sont ensuite spécifiées. Dans cet exemple, tout ce qui se trouve dans la section « photography » de example.com et de example.org sera associé à l’étiquette_2 (« label_2 »), tout ce qui contient soit le mot guestbook soit messages dans l’URL sera associé à l’étiquette_3 (« label_3 »). Sinon, l’étiquette par défaut s’applique.

La correspondance s’effectue à l’aide des expressions rationnelles Perl 5⁷ de sorte que si une règle doit être appliquée à « toutes les URL finissant par .jpg », cela apparaisse sous la forme \.jpg$.

L’utilisation de rdf:parseType=”Collection” permet de s’assurer que les règles sont traitées dans l’ordre. La première règle qui doit être remplie est celle qui est utilisée, et le traitement s’arrête là.

3.1.5 Section 5

Enfin, les étiquettes elles-mêmes sont définies. Dans l’exemple, l’ « étiquette 2 » indique qu’il y a une poitrine dénudée, des fesses dénudées et que le contenu apparaît dans un contexte à vocation artistique. L’ « étiquette 3 » indique qu’il y a un contenu généré par l’utilisateur contrôlé et l’ « étiquette 1 » indique « aucun des éléments ci-dessus » dans toutes les catégories du vocabulaire de l’ICRA.

Le type MIME approprié pour les fichiers RDF est application/rdf+xml⁸. Votre serveur ne le prend peut-être pas en charge par défaut⁹. Si c’est le cas, vous devrez choisir l’une des deux options suivantes :

1. Dans l’idéal, ajouter le type MIME application/rdf+xml, généralement associé à l’extension de fichier .rdf.
2. Si vous n’y parvenez pas, essayez de changer le nom du fichier RDF en labels.xml. Le type MIME XML (application/xml) est une alternative acceptable et est plus souvent inclus dans la configuration par défaut des serveurs.
3. Certains serveurs peuvent proposer text/xml comme type MIME pour les fichiers ayant une extension .xml. Cela ne devrait pas poser de problème pour les clients cherchant des étiquettes ICRA, mais vous ne devriez pas l’utiliser si vous incluez des étiquettes ICRA dans un ensemble de données plus sophistiqué, comme une base de données, ou si le jeu de caractères n’est pas iso-8859-1 (Latin-1).

Si vous ne suivez aucune de ces options, votre serveur utilisera peut-être un type MIME par défaut comme text/plain. Dans ce cas, il se pourrait qu’un client ne reconnaisse pas les données comme RDF et ne les traite donc pas correctement.

Si vous gérez des serveurs IIS et que vous n’êtes pas sûr de la façon dont vous pouvez ajouter de nouveaux types MIME, consultez le Paragraphe 5.3 ci-dessous.

Si votre serveur est protégé par un pare-feu, vous devrez peut-être configurer celui-ci en fonction.

Après avoir créé le fichier RDF, il vous faut maintenant insérer les liens vers ce fichier. Pour qu’un site Web soit considéré comme entièrement étiqueté, les liens doivent être insérés sur chaque page (X)HTML et, dans l’idéal, dans toutes les ressources.

La possibilité de faire basculer le traitement des étiquettes côté client plutôt que côté serveur offre un avantage considérable : un lien identique peut être inséré sur toutes les ressources. Ceci est vrai, que les étiquettes couvrent un petit site Web ou un réseau mondial de domaines sur Internet.

La manière la plus efficace est de configurer le(s) serveur(s) pour inclure le lien dans les en-têtes de réponse HTTP. Par ailleurs, cela évite d’effacer accidentellement la balise (ou de l’oublier) lorsque les pages sont retravaillées. Le contrôle des étiquettes se trouve alors entre les mains de la personne (ou du service) responsable de la gestion du fichier RDF, qui peut être différente de la personne (ou du service) qui a créé le contenu. Sinon, il suffit simplement d’inclure une balise de lien (X)HTML (semblable à l’Exemple 1 ou à l’Exemple 3 selon le cas) dans un modèle de document ou dans toute autre méthode que vous utilisez pour inclure les mêmes données dans la section de chaque page.

Oui. Lorsqu’un internaute navigue sur votre site pour la première fois, son client ne détectera les étiquettes que si un lien a été inséré. Si le lien n’a été inclus, disons, que sur la page d’accueil, l’internaute qui se connecte sur votre site par une autre page n’en profitera pas.

Il existe plusieurs façons de contrôler les en-têtes de réponse HTTP de Apache. Si vous avez déjà paramétré des en-têtes pour d’autres raisons, continuez à utiliser la même méthode. Sinon, la méthode indiquée ci-dessous est efficace et fonctionnera.

5.2.1 Installer Mod_Headers

Mod_Headers n’est généralement pas inclus dans la configuration par défaut mais sera très certainement inclus dans votre installation Apache. Il suffit de le « mettre en marche » en supprimant le symbole de commentaire qui se trouve avant deux lignes dans le fichier httpd.conf.

Il existe de nombreuses « idées » sur Apache, mais ce qui suit devrait en principe se rapprocher de ce dont vous avez besoin.

Dans la section DSO du fichier httpd.conf, cherchez

LoadModule headers_module     modules/mod_headers.so

Parfois, cela suffit ; parfois, vous aurez également besoin de la commande ci-dessous :

AddModule mod_headers.c

Les commentaires dans votre fichier de configuration et la présence (ou l’absence) de commandes similaires pour d’autres modules vous aideront à trouver la meilleure solution.

5.2.2 Paramétrer le même en-tête de réponse pour toutes les ressources

En supposant que le fichier RDF s’appelle labels.rdf et se trouve dans la racine du serveur Web, la commande suivante, insérée dans le fichier httpd.conf, vous permettra d’obtenir le résultat escompté.

Header set Link ‘; /=”/”; rel=”meta” type=”application/rdf+xml”; title=”ICRA labels”;’

N.B. Cette commande apparaît normalement sur une seule ligne.

5.2.3 Créer un lien vers des étiquettes spécifiques avec les en-têtes de réponse HTTP

Comme pour les autres options de configuration de Apache, les en-têtes de réponse HTTP peuvent être paramétrés dans les instructions des blocs. L’Exemple 6 paramètre le lien vers l’étiquette_2 (« label_2 ») pour toutes les ressources qui se trouvent dans var/www/images/.

  Header add Link ‘; /=”/”;   rel=”meta” type=”application/rdf+xml”;   title=”ICRA labels”;’

Exemple 6 Une instruction de bloc simple paramétrant un en-tête pour toutes les ressources qui se trouvent dans le répertoire des images.

Comme ci-dessus, la commande Header add Link devrait apparaître sur une seule ligne.

Les instructions des blocs permettent également de bien contrôler les en-têtes de réponse HTTP lorsque nécessaire*. L’Exemple 7 paramètre un en-tête en direction de l’ « étiquette_1 » pour toutes les ressources qui se trouvent dans le répertoire var/www/ (et ses sous-répertoires), mais lorsque le nom de fichier se termine par .gif, .jpg, .jpeg ou .png, l’en-tête en direction de l’ « étiquette_2 » est évoqué.

  Header add Link ‘; /=”/”;   rel=”meta” type=”application/rdf+xml”;’       Header unset Link     Header add Link ‘; /=”/”;     rel=”meta” type=”application/rdf+xml”;’  

Exemple 7 Une instruction de bloc imbriquée paramétrant un en-tête pour les fichiers d’images différent de celui des autres fichiers dans le même bloc.

Notez que dans l’Exemple 7, le lien est isolé dans l’instruction du bloc fichier. C’est parce que lorsqu’une ressource est reliée à une étiquette spécifique, cette étiquette est prioritaire et ne peut pas être ignorée (voir paragraphe 7). Il ne faut donc pas inclure plus d’un lien vers des étiquettes spécifiques, et le comportement escompté des clients n’est pas défini dans ces circonstances¹⁰.

* Certaines versions de Apache n’autorisent peut-être pas à paramétrer les en-têtes dans une instruction de bloc Virtual Host.

Microsoft a facilité la configuration de ses serveurs pour inclure les balises de lien. Les informations sur l’en-tête sont paramétrées dans la boîte de dialogue des propriétés du site Web à l’aide de la fonction En-têtes HTTP personnalisés. IIS utilise une architecture hiérarchique, la page des propriétés des en-têtes HTTP pouvant être configurée aux niveaux suivants :

• Serveur Web
• Répertoire personnel / site Web (IIS 4 et les versions plus récentes prennent en charge les sites Web multiples)
• Répertoire virtuel
• Dossier
• Page

Pour paramétrer les propriétés des en-têtes HTTP, sélectionnez le niveau requis dans le Panneau de configuration IIS, cliquez avec le bouton droit de la souris et sélectionnez les propriétés, puis sélectionnez la page des propriétés des en-têtes HTTP. La copie d’écran ci-dessous illustre la page des propriétés des en-têtes HTTP pour le site Web par défaut.

Figure 3 Boîte de dialogue des propriétés de IIS

Cliquez sur le bouton Ajouter.

Comme l’illustre la Figure 4, tapez Link dans le champ Nom de l’en-tête personnalisé et entrez ce qui suit dans le champ Valeur de l’en-tête personnalisé :

; /=”/”; rel=”meta” type=”application/rdf+xml”; title=”ICRA labels”;

Figure 4 Champs de nom et de valeur de l’en-tête personnalisé dans IIS

Cliquez sur OK pour revenir à la boîte de dialogue des propriétés Web. Si vous ne l’avez pas déjà fait, ajoutez le type MIME RDF maintenant ! Dans la section Mappage MIME (voir Figure 3), cliquez sur Types de fichiers et saisissez les informations illustrées sur la Figure 5.

Figure 5 Ajouter le type MIME RDF dans IIS

N.B. Veuillez ignorer les options de classification des contenus (elles utilisent un système obsolète).

De nombreux fournisseurs de contenus n’auront besoin que d’une seule étiquette, ou du moins, que de quelques étiquettes pour leur site. L’ ensemble de règles offre cependant une grande flexibilité et permet de bien contrôler quelle étiquette est associée à quelles ressources. Trois types de règles de base sont disponibles :

Une règle simple qui indique une seule expression rationnelle dans un élément hasURI qui, s’il y a correspondance, identifie l’étiquette appropriée.

Une règle qui inclut deux expressions rationnelles ou plus dans des éléments hasURI qui, si l’un d’entre eux correspond, identifie une étiquette appropriée.

Une règle qui inclut deux expressions rationnelles ou plus dans des éléments hasURI qui, s’ils correspondent tous, identifie une étiquette appropriée.

Dans l’Exemple 5, deux règles sont indiquées :

  photography  

Toute ressource dont l’URI inclut « photography » (et se trouve sur l’un des hôtes déclarés) sera décrite par l’ « étiquette_2 ».

  guestbook   messages  

Si un URI ne correspond pas à la première règle, un client essaiera de le faire correspondre à « guestbook » et à « messages ». S’il trouve une correspondance (avec l’un ou l’autre), l’ « étiquette_3 » s’applique.

Il est possible d’imbriquer les règles comme l’illustre l’Exemple 8. L’ « étiquette_2 » serait appliquée si l’URL contenait « colour » et « image » ou « monochrome » et « image ». Notez que hasLabel est une propriété de la règle « extérieure ».

   colour image   monochrome image   
  
  
  

Exemple 9 Description d’un film utilisant des modificateurs de fréquences

Les modificateurs de fréquences ont un éventail de label:ContentLabel. C’est à dire qu’ils DOIVENT être reliés à une catégorie de ce type.

Etiquettes de contenus, restrictions d’hôtes, règles – ce ne sont que des fragments RDF. Elles ne doivent pas nécessairement toutes se trouver dans un fichier unique appelé labels.rdf. Si le RDF vous est familier, essayez simplement de considérer les étiquettes ICRA comme faisant partie de vos métadonnées.

Si vous créez de nombreux sites Web qui doivent posséder la même étiquette ICRA, créez un fichier contenant l’étiquette et intégrez la balise de lien qui le relie dans votre modèle habituel. N’oubliez pas que les étiquettes ne doivent pas obligatoirement être sur le même serveur, elles peuvent se trouver n’importe où.

Inutile d’inclure une restriction d’hôte – si une ressource est reliée à une étiquette et qu’il n’y a aucune restriction d’hôte inclue dans le fichier RDF, l’étiquette est valide. L’inconvénient, c’est que cela signifie que n’importe qui peut désigner votre étiquette, ce qui peut ajouter une charge supplémentaire sur votre serveur.

Si vous voulez quand même inclure une restriction d’hôte, celle-ci peut se trouver dans un fichier séparé, toute seule. L’Exemple 10 montre comment faire. Les deux fragments de RDF peuvent se trouver dans le même fichier (comme c’est le cas ici) ou dans des fichiers séparés, sur des serveurs différents. Dans ce cas-là, vous devrez inclure un URI complet (y compris l’identificateur de fragment) comme rdf:resource.

  
   ...



  gt;example.com
  gt;example.org

Exemple 10 Un ensemble de règles qui relie à une liste de restrictions d’hôtes « externe ».

Ceci vous permet de paramétrer un fichier stable pour les étiquettes puis de générer la liste de restrictions d’hôtes dynamiquement si vous le désirez.

Les étiquettes qui s’appliquent à une seule ressource peuvent être insérées dans un fichier à part. Vous pouvez configurer un fichier d’étiquettes par défaut (avec un ensemble de règles) et tout relier à celui-ci, puis créer un fichier d’étiquette tout à fait à part pour une page particulière avec un lien spécifique vers cette étiquette.

En résumé, déterminez ce qui est le mieux pour vous. Cela fonctionnera probablement en pratique.

Le site Web de l’ICRA inclut un outil en ligne capable d’identifier l’étiquette appropriée pour une URL donnée¹⁴.

Version 1.0.1 : Ajout du paragraphe sur la création d’un lien vers icra.org/sitelabel (paragraphe 9). Paragraphes suivants renumérotés.

Version 1.0.2 Modification de la documentation sur les hostRestriction pour inclure la propriété hasHostRestrictions et la catégorie Hosts.

Liens et références