Schema.org – le profil d’application de Google, Bing et Yahoo!

Schema.org correspond à un profil d'application(#1) pour les moteurs de recherche sur le web, initié par Google en juin 2011 et auquel se sont joints Bing, Yahoo! et (ajout avril 2012) Yandex (portail russe). 

C'est un corpus d'éléments de (méta)données, sélectionnés, organisés en une structure particulière et encodé selon un formalisme propre. C'est un schema …  propriétaire, donc ;-).

Et tous vont s'y conformer, bien sûr. Mais qui dit se conformer, ne veut pas dire suivre sans réflexion ces propositions…. 

Quelques mots sur ce vocabulaire

Et d'abord, pour quoi faire ?

Avec ce schéma, il est ainsi possible d'améliorer les résultats de la recherche (l'ordonnancement) mais aussi (surtout?) la façon dont les sites apparaissent dans les résultats de recherche. Ce n'est donc pas tant la "recherche" (query&retrieval) effectuée par le moteur qui est améliorée, que la "recherche" (seeking,searching&… finding!) de l'information la plus pertinente par l'utilisateur : celui-ci sera moins souvent obligé d'aller consulter de multiples ressources pour vérifier la pertinence d'un résultat par rapport à son besoin… (vous remarquerez l'ambiguité du mot "recherche" en français – 1 terme pour 4 en anglais !).

Exemple de résultats enrichis grâce au principe des schémas structurés (une recherche : "galette des rois")

Exemple de recherche enrichie avec Schema.org
Remarque : Wikipédia sans balise semble perdre ici des places dans les résultats et de la visibilité ?

Comment est-ce possible ? 

En exploitant une structuration et une formalisation (balises) des contenus. Comme tout outil de représentation d'information aujourd'hui, Schema.org associe :

  • un (des) modèle(s) que j'appelle "métier". Sont proposés et articulés des (micro) schémas de représentation de quelques catégories générales (Personne, Evènement, …). Mais à la manière forte de Google, rien n'est en relation avec d'autres vocabulaires (schéma de données) préexistants. C'est donc à nous à déterminer les correspondances avec des vocabulaires existants, microformats ou Dublin Core;
  • une syntaxe de représentation (encodage) de ces éléments de données : HTML microdata, c'est-à-dire la syntaxe proposée par le W3C pour HTML5 (quand même !). Si vous utilisez une autre syntaxe ou vocabulaire, vous devrez modifier vos pratique (plus d'information sur Developpez.com).

Et si vous aviez déjà intégré des balises sémantiques, un travail de mise en correspondance reste à faire. Heureusement pour nous, les mondes du Web sémantique et du Dublin Core s'y sont mis (on les remercie !) :

Composition de Schema.org

Une arborescence de premier niveau partant de "Thing" avec 7 catégories principales  

  • Oeuvre (CreativeWork)
  • Evènement (Event)
  • Elément Immatériel (Intangible)
  • Organisme (Organization)
  • Personne (Person)
  • Lieu (Place)
  • Produit (Product)

– 4 propriétés pour chaque entité : une description (format texte), une URL pour une image, le nom de l'item (format texte) et l'URL de l'item.

Le schéma complet est présenté en une seule page ici - http://schema.org/docs/full.html

Quelques commentaires de ci de là (non exhaustif) :

  • Beaucoup de relations entre éléments (le schéma est maillé), par exemple :
    • Les entités sont liées entre elles : les Evènements à des Organisations, des Personnes, des Lieux, …
    • L'élément Review (Critique/Revue) est lié à tout type et possède des caractéristiques particulières; et les Critiques/Revues peuvent avoir des scores.
    • Les Evènements sont hiérarchisés : il y a une propriété subEvents et SuperEvent (au singulier donc monohiérarchique)
  • Le principe de la notation se retrouve partout : des scores (Rating), des agrégats de scores (AggregateRating) pour les Organisations, …
  • Par contre je ne vois pas par exemple de "date de fin" d'une Organisation qui a bien une date de création. Comment gérer les successions ? Doit-on passer par d'autres Evènements ?
  • L'entité "Produit" – ici pas de liste de type de produits, mais des propriétés spécifiques : notation agrégée, entreprise fabriquante, marque, modèle du produit, offre (détaillée), identifiant du produit (ISBN,…), compte-rendu.
  • C'est un schéma politiquement correct : les Personnes ne peuvent pas être notées (Rating) ni critiquées (Review) !   

Bref, il faut se plonger dans chacune des classes et sous-classes, leurs attributs et relations, et les aligner à vos besoins et aux vocabulaires existants. 

Un exemple

La Cité de la Musique veut valoriser ses évènements, ici un Hommage à Miles Davis.

Voici un petit exemple sans prétention (et certainement avec des erreurs)….
Et je n'ai probablement pas choisi l'exemple le plus simple, car pour la catégorie Participants ("attendee"), un hommage à Miles Davis ne permettra pas de trouver Miles Davis ! 

itemscope itemtype=« http://schema.org/Event »>

   itemprop=« url » href=« http://www.citedelamusique.fr/francais/evenement.aspx?id=11155« >Concert :
   itemprop=« name »>Hommage à Miles Davis
    

itemprop=« startDate » content=« 2011-02-14T14:30 »>    Lun, 14/03/2011   14:30 p.m. 
 

itemprop=« location itemscop itemtype=« http://schema.org/Place »> 
 
itemprop=« url href=« http://www.citedelamusique.fr/francais/cite/infos_pratiques/infos.aspx »>    

   

itemprop=« address » itemscop itemtype=« http://schema.org/PostalAddress« >
       itemprop=« streetAddress »>221, avenue Jean-Jaures
       itemprop=« addressLocality »>Paris
       itemprop=« postalCode »>75019
       itemprop=« addressCountry »>FR,
    

  </div>
</div>

Je vois qu'il existe déjà des balises sur ce site (utilisées par le moteur interne ??) : "chapo", "programmation", "oeuvre", "auteur", "distribution", "Dates de l'évènement",  "tarif",…. On voit de suite qu'il faudra utiliser plusieurs parties de Schema.org et faire un travail de mise en correspondance. Peut-être sera-t-il nécessaire de conserver des balises qui n'auront pas trouver d'équivalence. Désolée … Il va faloir reprendre tout et/ou construire des pages spécifiques pour les moteurs généralistes….

Petit historique de la prise en compte du contenu structuré sur le web

Revenons au principe de structurer les données pour la machine avec toujours le même principe : il n'est matériellement plus possible de traiter "manuellement" à chacune de nos recherchers, tous les résultats… Mais ce principe est en fait ancien et a démarrer avec SGML ….Mais restons à HTML…

A ses origines (1993), la description de HTML était assez informelle. Dès la version 2, les méta-informations apparaissent, et la structuration entête / corps de la ressource apparaît à la version 3.2 d'HTML en 1997. Ces méta-informations constituaient une première étape, primaire dirait certains. On peut faire l'analogie avec la classique "notice descriptive" d'un document.

Puis le principe des métadonnées, bien plus large que celui de la seule "notice",  a attaqué de façon plus concrète le  "contenu" même des ressources à partir de la version 4 (1998).

Puis RDF du W3C arrive en 1999, complexe son développement est lent. 

En 2005, Google lance l'initiative SitemapCette initiative proposait de s'appuyer sur un des éléments-clés des pages HTML – les adresses URL des sites – pour optimiser le traitement de son moteur. Toute personne produisant un site se met à travailler spécifiquement pour les moteurs 😉
Un premier exemple de sitemap en html;  un autre exemple intégrant des adresses correspondant à des documents uniques. On le voit : un "sitemap" est une page d'index et/ou une table des matières  … L'initiative Schema.org complète Sitemap sur les contenus.

Les microformats (et site officiel), proposés à la même éqpoque (2005), apportent une première solution "simple" pour structurer les contenus par rapport à des "types" sémantiques (calendrier, carte de visite, revues/critiques, …) tout en conservant la simplicité de production d'HTML – une approche minimaliste qui visait à faire bouger les choses côté sémantique… Ces choix techniques minimalistes deviennent aujourd'hui dans certains contextes une limite forte. L'évolution naturelle pour ces microformats pourrait être l'utilisation du format HTML microdata.

 

#1 Définition de Profil d'application 

modèle de données d'une application composé d'un assemblage cohérent et documenté d’éléments de métadonnées choisis parmi un ou plusieurs schémas de métadonnées.
Autre définition : "schémas composés d’éléments de données provenant d'un ou de plusieurs espaces de noms, combinés entre eux pour une application locale et optimisés pour une application particulière».(application profiles as schemas which consist of data elements drawn from one or more namespaces, combined together by implementors, and optimised for a particular local application.)  Source : http://www.ariadne.ac.uk/issue25/app-profiles/ 

Les profils d’application permettent de mettre en oeuvre les principes de modularité et d’extension. L’objectif d’un profil d’application est d'adapter ou de combiner des schémas existants afin d'obtenir un nouveau schéma conçu pour une application particulière tout en gardant l'interopérabilité avec le ou les schémas de base. Cette adaptation peut inclure la définition d’éléments de métadonnées locaux importants pour une communauté particulière mais qui ne le sont pas dans un contexte plus large. C'est une pratique qui se développe pour la conception de vocabulaires métiers spécifiques autour de schémas généraux comme l'ISO 15836 (Dublin Core) et l'ISO 19115 (SIG) par exemple.

Sources

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s