|
||||||||||||||||||||
|
||||||||||||||||||||
Description du système d'étiquetage de l'ICRALecteurs ciblésCe document est la source de conseils de référence en ce qui concerne l'étiquetage des contenus à l'aide du système ICRA. Bien que nous ayons fait tout notre possible pour présenter les informations de façon claire, nous avons inclus beaucoup de détails, ainsi que des références à diverses technologies d'Internet. L'ICRA fournit des explications plus courtes et simplifiées pour les utilisateurs qui possèdent peu ou pas d'expérience dans la création de sites Web, ou pour ceux qui n'ont pas besoin de tous les détails fournis ici. Vous les trouverez dans la rubrique Assistance1. Version 1.0.2 Table des matières1 Introduction 1 IntroductionL'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 entier2. 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 RDF3, l'une des technologies clés à la base du Web sémantique4. 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. 1.1 Espaces de nommage et documentationL'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 https://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 https://icra.org/vocabulary. 2 Les concepts clésUne 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. 2.1 Création d'un lien vers des étiquettes spécifiques (traitement côté serveur) Figure 1 Association du contenu et des étiquettes côté serveur La Figure 1 illustre le cas où chaque ressource est reliée à une étiquette spécifique. Si le fichier RDF s'appelle labels.rdf et se trouve dans la racine du site Web, et si une ressource doit être reliée à une étiquette appelée « étiquette_1 » (label_1), la balise de lien est celle illustrée dans l'Exemple 1 : <link rel="meta" href="/labels.rdf#label_1" type="application/rdf+xml" title="ICRA labels" /> Exemple 1 Une balise de lien typique associant une étiquette spécifique à une ressource L'en-tête de réponse HTTP équivalent est : Link: </labels.rdf#label_1>; /="/"; rel="meta" type="application/rdf+xml"; title="ICRA labels"; Exemple 2 En-tête de réponse HTTP équivalent à l'Exemple 1 Notez que l'étiquette spécifique qui se trouve dans le fichier RDF est identifiée par le fragment URL fourni dans l'attribut href. L'attribut title est facultatif mais recommandé pour plus de clarté. Peu importe où se trouve le fichier labels.rdf. Il peut être n'importe où sur n'importe quel serveur, mais son emplacement doit, bien entendu, être indiqué dans l'attribut href. 2.2 Création d'un lien vers un ensemble de règles (traitement côté client)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 : <link rel="meta" href="/labels.rdf" type="application/rdf+xml" title="ICRA labels" /> 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: </labels.rdf>; /="/"; 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. 2.3 Création du fichier RDFL'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'étiquettes5. 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. 3 Contenu du fichier RDFLe 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 :
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 N36, sont tout aussi valides.
Exemple 5 Exemple de fichier RDF contenant des étiquettes ICRA 3.1.1 Section 1Les 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 2Cette courte section indique que les étiquettes ont été créées par l'ICRA et que de plus amples informations sont disponibles sur icra.org. Etant donné qu'il est possible d'inclure des descriptions basées sur d'autres systèmes, cette section précise que icra.org possède uniquement des informations sur l'espace de nommage ICRA. 3.1.3 Section 3Cette 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 : <label:hasURI>foo</label:hasURI> 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 4Les 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 57 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 5Enfin, 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. 4 Paramétrage du type MIMELe type MIME approprié pour les fichiers RDF est application/rdf+xml8. Votre serveur ne le prend peut-être pas en charge par défaut9. Si c'est le cas, vous devrez choisir l'une des deux options suivantes :
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. 5 Méthodes d'insertion des balisesAprè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 <head> de chaque page. 5.1 Est-il important d'inclure la balise sur 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. 5.2 Configuration du serveur ApacheIl 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_HeadersMod_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 ressourcesEn 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 '</labels.rdf>; /="/"; 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 HTTPComme 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/. <Directory /var/www/images/> 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é. <Directory /var/www/> 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 circonstances10. * Certaines versions de Apache n'autorisent peut-être pas à paramétrer les en-têtes dans une instruction de bloc Virtual Host. 5.3 Configuration du serveur Microsoft IISMicrosoft 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 :
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é : </labels.rdf>; /="/"; 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). 6 Informations détaillées sur les règlesDe 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 : <rdf:Description> <label:UnionOf> <label:IntersectionOf> Dans l'Exemple 5, deux règles sont indiquées : <rdf:Description> 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 ». <label:UnionOf> 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 ». <label:UnionOf>
<label:rules>
<label:IntersectionOf>
<label:hasURI>colour</label:hasURI>
<label:hasURI>image</label:hasURI>
</label:IntersectionOf>
<label:IntersectionOf>
<label:hasURI>monochrome</label:hasURI>
<label:hasURI>image</label:hasURI>
</label:IntersectionOf>
</label:rules>
<label:hasLabel rdf:resource="#label_2"" />
</label:UnionOf>
Exemple 8 Une règle imbriquée 7 Etiquettes par défaut, étiquettes ignoréesIl est possible de paramétrer une étiquette par défaut générale à l'aide d'un ensemble de règles, qui sera ensuite ignorée au profit d'une étiquette reliée directement à la ressource. En effet, si une ressource est reliée directement à une étiquette spécifique, comme décrit dans le paragraphe 2.1, celle-ci sera prioritaire sur les données de l'ensemble de règles. Prenons un exemple classique : un fournisseur de contenu peut configurer des serveurs de façon à inclure un en-tête de réponse HTTP relié à un fichier semblable à l'Exemple 5. Une ressource qui se trouve sur www.example.org/page.html sera décrite par l'étiquette par défaut (« étiquette_1») car aucune des règles ne correspond. Cependant, si page.html devait inclure un lien vers l' « étiquette_2 », à l'aide d'une balise comme : <link rel="meta" href="/labels.rdf#label_2" type="application/rdf+xml" title="ICRA label" /> ceci annulerait l'étiquette par défaut et l'associerait à l' « étiquette_2 ». Un point important 8 Traitement des étiquettes ICRAPour une ressource donnée (une page, une image, etc.), il existe trois sources d'étiquette possibles :
Comme détaillé ci-dessous, les filtres DEVRAIENT attribuer des priorités grandissantes à chacune de ces sources. 8.1 Avant de récupérer la ressource Figure 6 Traitement qui doit être effectué avant d'envoyer une demande sur Internet. Si le filtre possède déjà une étiquette pour l'URL requise dans sa mémoire cache, une étiquette de Type 1 est immédiatement disponible. Si cette étiquette a été au départ récupérée sur le même site que l'URL qui nous intéresse maintenant, l'étiquette DEVRAIT être considérée comme de Type 2. Si les données de l'étiquette dans la mémoire cache ont été récupérées à partir d'un site Web différent, elle reste de Type 1 ; la ressource doit être extraite et ses données doivent être contrôlées. En bref :
Ceci peut s'expliquer de plusieurs façons, mais en gros, l'idée est que les étiquettes reliées à partir d'une ressource sont « plus près » du fournisseur de contenu que les étiquettes qui auraient pu être publiées par une personne ayant un loin étroit ou aucun lien du tout avec le contenu décrit. Ce point est développé dans le paragraphe suivant, où une priorité encore plus importante est donnée aux étiquettes qui sont reliées à partir de la ressource elle-même. Il ne faut pas confondre les étiquettes de Type 1 avec l'étiquetage d'une tierce personne. Si un filtre est configuré pour demander des étiquettes à partir d'une source d'une tierce personne, comme une base de données en ligne ou un analyseur de contenu, le filtre traitera ces données séparément. Les étiquettes de Type 2 ont la priorité sur les étiquettes de Type 1, uniquement dans le contexte de l'auto-étiquetage. S'il n'y a aucune donnée dans la mémoire cache du filtre, la ressource qui se trouve à l'URL DOIT être extraite.  Figure 7 Règles de traitement une fois la ressource extraite. 8.2 Identification de l'étiquette appropriéeSi la ressource inclut des liens vers des données sur l'étiquette, il peut être nécessaire de l'extraire et de la traiter. (N'oubliez pas que les étiquettes sont toujours conservées séparément, et jamais dans la ressource elle-même.) Si la ressource inclut un lien vers une étiquette spécifique, celle-ci est classée comme Type 3. Puisqu'il s'agit de la plus haute priorité dans la hiérarchie, une fois qu'une étiquette de Type 3 est disponible, aucun autre traitement n'est nécessaire pour identifier l'étiquette appropriée à utiliser pour cette ressource. Cependant, les clients DEVRAIENT vérifier les restrictions d'hôtes. Il est évident qu'une étiquette ne devrait être reconnue comme valide que si la ressource qui y est reliée est sur le ou les hôte(s) déclaré(s). Si aucune restriction d'hôte n'est indiquée, un client PEUT accepter l'étiquette. La priorité donnée aux étiquettes de Type 3 est l'étape cruciale qui permet à un fournisseur de contenu de travailler avec la notion d'une étiquette par défaut pouvant être ignorée localement. Si la ressource contient un lien vers la même ressource qui avait déjà été traitée pour identifier une étiquette de Type 2, il est évident qu'aucun autre traitement n'est nécessaire ; l'étiquette appropriée a déjà été identifiée. Cependant, si un lien mène à une source de données différente de celle qui avait déjà été utilisée pour dériver une étiquette de Type 2, les nouvelles données DEVRAIENT être traitées, pour la simple raison qu'il est possible d'inclure n'importe quel nombre de fichiers de données sur un site, et on peut supposer que celui auquel est relié une ressource donnée est celui que le fournisseur de contenu avait l'intention d'utiliser. Si la ressource ne contient aucun lien, il est évident que les seules informations disponibles sont celles qui étaient disponibles avant que la ressource ne soit extraite. Si plusieurs étiquettes du même Type sont disponibles, le fournisseur de contenu a commis une erreur. Le filtre PEUT utiliser n'importe laquelle d'entre elles, mais, pour des raisons d'efficacité, il utilisera en principe simplement la première trouvée pour un type donné. 8.3 Ressources non étiquetéesL'ICRA recommande aux clients de filtrage de proposer deux options aux utilisateurs : bloquer/autoriser l'accès aux pages Web non étiquetées, c'est à dire (X)HTML, et bloquer/autoriser l'accès à toutes les ressources non étiquetées. Cette dernière option permet d'éviter que des sites Web soient bloqués parce qu'un fichier de macros ou une feuille de style est extraite du réseau avant qu'une étiquette appropriée ne soit récupérée. 9 Indiquer aux internautes qu'un site est étiqueté ICRALes sites étiquetés peuvent afficher une image ou un texte relié à https://icra.org/sitelabel. Les internautes qui suivront ce lien pourront voir une interprétation dynamique de votre étiquette et en savoir plus sur l'ICRA. Les liens textes doivent stipuler « Etiqueté ICRA ». Les expressions du type « Approuvé par l'ICRA » et « Certifié ICRA » sont strictement interdites. (L'ICRA n'approuve pas et ne certifie pas les sites - les fournisseurs de contenus étiquettent leur contenu à l’aide du système ICRA.) De nombreux sites possèdent des sortes de liens « en petits caractères » en bas de l'une ou plusieurs de leurs pages, qui mènent parfois à une déclaration de confidentialité ou à un contact. Tout comme eux, vous pourriez ajouter un lien texte « Etiqueté ICRA ». Vous pouvez également ajouter l'une des images disponibles sur icra.org11. Celles-ci sont disponibles en plusieurs langues, dont l'américain et l'anglais britannique. 10 Travailler avec d'autres systèmes RDFUne étiquette ICRA et l'ensemble de règles sont simplement des Catégories RDF dont les types sont définis par le système correspondant. Ces éléments peuvent tous être inclus dans n'importe quel fichier RDF et, inversement, toute autre métadonnée RDF peut être inclue dans « un fichier d'étiquettes ICRA ». En effet, nous encourageons les fournisseurs de contenus à utiliser d'autres systèmes. 10.1 Informations de gestionLe système de métadonnées le plus connu qui est régulièrement codé en RDF est peut-être Dublin Core12. Avec les licences Creative Commons13 et autres systèmes similaires, il peut être inclus directement dans les étiquettes de contenus mais peut également être placé dans une catégorie spéciale pour les informations de gestion. De la même manière que pour les Etiquettes de contenus, le système des étiquettes définit les propriétés hasDefaultManagementInfo et hasManagementInfo. Celles-ci sont reliées aux Etiquettes de contenus RDF qui peuvent inclure des données comme le titre, l'auteur et la date de publication. Les étiquettes Infos de gestion existent indépendamment des Etiquettes de contenus reliées par les étiquettes de propriétes hasDefaultLabel et hasLabel et il est donc possible d'avoir une règle qui annule l'étiquette des informations de gestion par défaut sans annuler l'étiquette ICRA. 10.2 ClassificationLes étiquettes de contenus, qu'elles possèdent les descripteurs ICRA ou d'autres métadonnées, ont été conçues pour inclure des descripteurs détaillés. Plus officiellement, ce sont des catégories possédant des propriétés qui décrivent la ressource. Un troisième type de description est également défini dans le système d'étiquettes : une classification. Une fois encore, certaines propriétés sont analogues, comme hasDefaultClassification et hasClassification, mais contrairement à une étiquette de contenu, une classification est conçue pour être une description en elle-même. Par exemple, la classification peut être une classification de films basée sur l'âge ou peut identifier un article comme traitant de « politique » et non de « mode ». Quelle que soit la classification, les clients ne sont pas obligés de traiter les propriétés d'une catégorie reliée par une propriété hasClassification ou hasDefaultClassification. Une fois encore, les classifications sont indépendantes, de sorte que le fait d'annuler une classification par défaut n'ait pas d'effet sur les informations de gestion ni sur l'étiquette. 11 Modificateurs de fréquencesLes films, programmes télé, jeux et autres contenus qui « ont une durée » peuvent nécessiter plus d'une étiquette. Il peut être approprié de fournir une étiquette décrivant une scène particulière d'un film ou un type de contenu qui revient occasionnellement dans un jeu. Pour cela, le système des Etiquettes de contenus prend en charge un ensemble de modificateurs de fréquences :
Une description RDF standard peut ressembler à celle illustrée dans l'Exemple 9. Elle peut être autonome, comme toute autre description RDF, ou faire partie d'une série de règles dans un label:Ruleset. <rdf:Description rdf:about="http://example.org/movie.mov> <label:hasLabel rdf:resource= "#label_1" /> <label:hasOccasionalScenes rdf:resource="#label_2" /> <label:hasSingleScene rdf:resource="#label_3" /> </rdf:Description> 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. 12 Astuces12.1 C'est juste du RDFEtiquettes 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. 12.2 Gestion des étiquettes pour plusieurs sites WebSi 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. <label:Ruleset> <label:hasHostRestrictions rdf:resource="#hosts" /> ... </label:Ruleset> <label:Hosts rdf:ID="hosts"> <label:hostRestriction>gt;example.com</label:hostRestriction> <label:hostRestriction>gt;example.org</label:hostRestriction> </label:Hosts> 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. 12.3 Une étiquette spécifique pour une page spécifiqueLes é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. 13 Tester les étiquettesLe site Web de l'ICRA inclut un outil en ligne capable d'identifier l'étiquette appropriée pour une URL donnée14. 14 Modification du journalVersion 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
|
||||||||||||||||||||
