Developpez.com

Une très vaste base de connaissances en informatique avec
plus de 100 FAQ et 10 000 réponses à vos questions

Schema.org : une initiative pour que les moteurs de recherche comprennent les sites Web

Dans le Web tel qu'on le connaît actuellement, les moteurs de recherche sont à peu près incapables de comprendre le contenu des pages Web qu'ils indexent. Pour répondre à une requête, ils font une recherche sur base des mots-clés fournis par l'utilisateur sous certaines contraintes. Si on leur pose une question, ils vont chercher les mots-clés de la question, ils ne vont pas répondre directement à la question.

Cependant, cela évolue : depuis peu, Google est capable de répondre à certaines questions formulées en anglais, en prenant toutefois une précaution oratoire (« la réponse la plus probable est... »). Pour cela, il faut qu'il puisse comprendre le contenu des pages indexées. C'est une large partie du Web sémantique. Pour aider cela, Schema.org a été lancé par trois des plus grands moteurs de recherche actuels.

3 commentaires Donner une note à l'article (5)

Article lu   fois.

L'auteur

Liens sociaux

Viadeo Twitter Facebook Share on Google+   

I. L'initiative Schema.org

Conjointement, Google, Yahoo et Bing annoncent le lancement du site Schema.org, le 2 juin 2011. (1) L'objectif ? Fournir une série de vocabulaires communs pour structurer les données des pages Web. On doit les rapprocher au concept d'ontologie : ils permettent de représenter les connaissances sur un sujet. (2)

Pour une introduction plus approfondie au Web sémantique et à la notion d'ontologie, Introduction au Web sémantique.

Actuellement, un grand nombre de vocabulaires existent déjà : leur seul problème est de ne jamais être rassemblés. On peut citer Dublin Core Metadata Initiative, The FOAF Project, The DBpedia Ontology et bien d'autres encore, comme data-vocabulary.org, déjà une initiative Google, ou bien le protocole Open Graph de Facebook. Comment s'y retrouver ? La solution retenue a été de fournir un ensemble de vocabulaires génériques, à même de couvrir l'ensemble des besoins quotidiens (avec les vocabulaires Schema.org, on peut décrire aussi bien une attraction touristique qu'un film ou un concert). Pour ceux qui n'auraient pas assez de vocabulaire à leur disposition, il est toujours possible d'écrire des extensions. Le problème de ces extensions est qu'il n'est pas certain que toutes les applications puissent comprendre ces données supplémentaires.

On peut se demander quel est le lien entre toutes les technologies du Web sémantique (en ce compris SPARQL ou le RDF). C'est simple : des données structurées sur une page peuvent être transformées en triplets RDF, qui peuvent être exploités aisément.

Ce tutoriel se basera exclusivement sur les techniques de structuration des données disponibles dans le standard HTML5, soit les microdonnées (voir Web sémantique et HTML5 : les microdonnées et les éléments sémantiques pour une introduction). La raison en est simple : tous les exemples du site Schema.org ont été rédigés en ce sens. Il n'est pas cependant interdit d'utiliser RDFa pour exploiter ces vocabulaires (une introduction à RDFa est également disponible).

II. L'équivalence données structurées - triplets RDF

Ce point est spécifiquement discuté par le standard des microdonnées, on va étudier cette partie un peu plus en détail à l'aide d'un exemple simple. Le standard est disponible en tant que draft sur le site du consortium W3C. Une section est particulièrement dédiée à la conversion des microdonnées en RDF, en décrivant l'algorithme à suivre pour obtenir tous les triplets de la page. On ne décrira pas ici le contenu de cette section dans tous les détails, certains raccourcis seront pris.

II-A. <title>

La balise <title>, si elle est remplie, donne le triplet suivant :

Si ces triplets RDF ne vous semblent pas clairs, approfondissez Apprendre RDF par l'exemple avec FOAF.

II-B. <a>, <area> et <link>

Ensuite, pour toutes les balises <a>, <area> et <link> du document, on garde celles qui ont un attribut rel défini et href qui pointe vers une URL qui existe. Cela permet d'obtenir une liste de jetons pour chaque élément : on sépare le contenu de l'attribut rel d'un élément en une liste, prenant l'espace comme séparateur, cette liste est la liste de jetons de l'élément.

On distingue ensuite deux types de jetons : ceux qui contiennent un deux-points et ceux qui n'en ont pas. Pour ces seconds, on peut construire le triplet suivant :

Pour les premiers, par contre :

  • sujet : l'adresse du document ;
  • prédicat : le jeton ;
  • objet : l'attribut href.

On remarque que seule l'interprétation du jeton change, le prédicat aussi par voie de conséquence.

On génère donc un triplet par élément de l'attribut rel, une seule balise peut donc générer un nombre très grand de triplets.

II-C. <meta>

Pour autant que les attributs name et content soient définis, on reprend les mêmes triplets générés que précédemment, avec l'équivalence name-jeton et content-href, avec les différences suivantes :

  • une balise ne peut générer qu'un triplet ;
  • le contenu ne doit pas forcément être une URL.

II-D. <blockquote> et <q>

Il faut un attribut cite pour qu'on puisse générer un triplet.

  • sujet : l'adresse du document ;
  • prédicat : http://purl.org/dc/terms/source ;
  • objet : l'URL absolue qui résulte de la résolution de la valeur de l'attribut cite relativement au document.

II-E. Éléments avec microdonnées

On génère les triplets pour chacun des éléments avec microdonnées. Cette partie étant suffisamment complexe, on se limitera ici à un exemple ; les triplets RDF générés seront présentés sous le format Turtle (cela permet une correspondance simple entre le code HTML et les triplets, on pourrait le faire à l'aide d'expressions régulières si on désire rester simpliste).

Un bout de page HTML5 contenant des microdonnées
Sélectionnez
<section itemscope itemtype="http://data-vocabulary.org/Person">
  <h1 itemprop="name">Tartempion</h1>
  <p><img itemprop="photo" src="http://tarte.net/photo.jpg"></p>
  <p><a itemprop="url" href="http://tarte.net/">Mon site</a></p>
</section>
Sa retranscription en triplets (Turtle)
Sélectionnez
@prefix dv: <http://data-vocabulary.org/>

<http://tarte.net/moi/> a dv:Person ;
	dv:name "Tartempion" ;
	dv:photo "http://tarte.net/photo.jpg" ;
	dv:url "http://tarte.net/" .

III. En guise d'exemple

On va reprendre ici l'exemple officiel, c'est-à-dire le film Avatar de James Cameron. On part donc du balisage standard en HTML4, sans aucune notion sémantique :

 
Sélectionnez
<div>
 <h1>Avatar</h1>
 <p>Réalisateur : James Cameron (born August 16, 1954)</p>
 <p>Science fiction</p>
 <p><a href="../movies/avatar-theatrical-trailer.html">Trailer</a></p>
</div>

On commence à préparer le document pour les microdonnées quand...

 
Sélectionnez
<div itemscope itemtype="...">
  <h1>Avatar</h1>
  <p>Réalisateur : James Cameron (born August 16, 1954)</p>
  <p>Science fiction</p>
  <p><a href="../movies/avatar-theatrical-trailer.html">Trailer</a></p>
</div>

Mais quel vocabulaire va-t-on utiliser pour décrire un film ? L'objectif ici étant d'utiliser le contenu de Schema.org, on va donc l'exploiter.

Depuis la page d'accueil, on trouve un lien vers les schémas, puis un autre vers la liste complète des types. Avant de se perdre dans cette longue liste, on peut observer un peu plus et remarquer qu'il y a un vocabulaire Movie dès la page des schémas. Suivant ce dernier lien, on tombe sur le vocabulaire recherché et sa documentation. On peut donc l'exploiter :

 
Sélectionnez
<div itemscope itemtype="http://schema.org/Movie">
  <h1 itemprop="name"&g;Avatar</h1>
  <p itemprop="director" itemscope itemtype="http://schema.org/Person">
  	Réalisateur : <span itemprop="name">James Cameron</span> (born <span itemprop="birthDate">August 16, 1954)</span>
  </p>
  <p itemprop="genre">Science fiction</p>
  <p><a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a></p>
</div>

On a directement utilisé le vocabulaire Person, car c'est le type attendu pour la propriété director, selon la documentation de Movie. Sur cette même page, on peut aussi remarquer la présence d'autres exemples.

Ce n'est pas parce qu'un type est attendu qu'il est requis ! On peut créer une arborescence à l'aide de vocabulaires, mais on peut aussi se limiter à un seul niveau s'il n'y a pas beaucoup d'informations à définir pour un élément. Si on n'avait que le nom du réalisateur, on aurait pu écrire le code suivant :

 
Sélectionnez
<div itemscope itemtype="http://schema.org/Movie">
  <h1 itemprop="name"&g;Avatar</h1>
  <p>Réalisateur : <span itemprop="director">James Cameron</span></p>
  <p itemprop="genre">Science fiction</p>
  <p><a href="../movies/avatar-theatrical-trailer.html" itemprop="trailer">Trailer</a></p>
</div>

Si l'information n'est pas présente sur la page, il est inutile de la présenter sous forme cachée (que ce soit un <div> caché ou une balise <meta>). L'idéal est de ne marquer que l'information visible au visiteur. (3)

Une fois que l'on a intégré le principe des microdonnées, utiliser les vocabulaires Schema.org n'est donc pas compliqué.

IV. L'organisation des vocabulaires

Tous les vocabulaires héritent du même : Thing, le moins spécifique, celui qui propose le moins de propriétés, car elles sont partagées par tous les autres vocabulaires.

Ensuite, des types généraux en héritent : CreativeWork, Event, Intangible, Organization, Person, Place et Product. Chacune de ces « catégories » peut encore être plus spécifiée, à l'infini. On retrouve ici une belle application des principes de la programmation orientée objet.

Ce n'est pas parce qu'un type dérive d'un autre qu'il doit définir de nouveaux attributs : il permet d'être plus précis que son parent, c'est parfois la seule raison qui a poussé à créer un nouveau type, c'est d'ailleurs tout le principe des vocabulaires.

Il faut aussi remarquer que certains vocabulaires sont présentés avec un astérisque dans la liste : il s'agit de doublons, de vocabulaires qui peuvent être classés à deux endroits.

V. Présenter les données pour qu'elles soient compréhensibles par la machine

V-A. Dates et heures

Tous les types ne sont pas forcément facilement compréhensibles par la machine. L'exemple le plus courant est les dates, dont l'interprétation varie fortement entre les régions. Par exemple, 01/02/09 peut autant signifier le premier février de l'an 2009 que le neuf janvier 2001, en fonction du format utilisé. Il faut donc utiliser un format standardisé, pour que tout le monde comprenne la même chose des mêmes données.

Pour une date, on utilisera le format yyyy-mm-dd ; on peut aussi spécifier l'heure : yyyy-mm-ddThh:mm. On aura, par exemple, respectivement, pour l'origine de l'heure POSIX, 1970-01-01 et 1970-01-01T00:00.

V-B. Énumérations

Comme très souvent, certaines propriétés ne peuvent prendre que quelques valeurs prédéfinies : pour un produit, il n'y a que quelques disponibilités possibles (allant de en stock à en précommande), ces cas possibles sont présentés dans l'énumération ItemAvailability. Il est donc intéressant de préciser cela au moteur de recherche, étant donné qu'il ne peut pas deviner le contenu de la balise :

 
Sélectionnez
<div itemscope itemtype="http://schema.org/Offer">
  <span itemprop="name">Microdonnées</span>
  <span itemprop="price">0,00 €</span>
  <link itemprop="availability" href="http://schema.org/InStock"/> Disponible !
</div>

V-C. Métadonnées

Toutes les données ne peuvent pas être facilement déclarées, car il n'y a pas à proprement parler de texte pour ces données (par exemple, la durée d'une vidéo n'est pas toujours affichée). On utilise dans ce cas la balise <meta> :

 
Sélectionnez
<div itemscope itemtype="http://schema.org/Offer">
  <span itemprop="name">Microdonnées</span>
  <meta itemprop="price" content="0,00 " />
</div>

VI. L'extension des vocabulaires

Un seul site ne peut pas couvrir tous les besoins : rien n'est proposé pour le moment pour les données génomiques, par exemple. Il faut donc une manière élégante de parer à ce problème : l'extension des schémas. On peut ainsi étendre facilement les schémas existants, en créer de nouveaux au besoin. Les applications comprenant les microdonnées Schema.org seront donc à même de comprendre au moins une partie de ces nouvelles données. Si un schéma devient suffisamment populaire, les moteurs de recherche pourraient commencer à l'exploiter.

VI-A. Conventions de nommage

Les types et énumérations sont écrits en CamelCase.

Les propriétés sont écrites en camelCase. Les propriétés qui peuvent prendre plusieurs valeurs (comme les parents ou les critiques) sont au pluriel tandis que celles qui n'ont qu'une valeur restent au singulier (date de naissance ou de publication).

VI-B. Extension

Pour étendre quelque chose, il suffit de prendre l'objet de base (classe, propriété ou énumération), un slash et le nom du dérivé : Book/Novel, musicGroupMember/leadVocalist, etc. On peut continuer à l'infini de cette manière.

L'avantage est qu'on peut toujours comprendre au moins une partie du contenu : on n'a pas défini ce qu'était un Novel, on sait cependant que c'est un livre.

Pour reprendre l'exemple précédent en étendant tout ce qu'il est possible d'étendre :

 
Sélectionnez
<div itemscope itemtype="http://schema.org/Offer/Immaterial">
  <span itemprop="name">Microdonnées</span>
  <span itemprop="price/euros">0,00 €</span>
  <link itemprop="availability" href="http://schema.org/InStock/ReadyForSending"/> Disponible et prêt à l'envoi !
</div>

VII. Références

VIII. Remerciements

Merci à Julien Plu pour ses remarques ! Merci à Claude Leloup pour ses relectures orthographiques !


On parle d'ontologie dans un contexte purement Web sémantique, tandis qu'on parlera plus de vocabulaire quand il s'agit de structurer les données d'une page Web.

  

Copyright © 2011 Thibaut Cuvelier. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.