Comment fonctionnent les coulisses de Schema. org et pourquoi les développeurs devraient y jeter un œil

Vous êtes-vous déjà demandé pourquoi Google sait qu'une page contient une vraie recette de tarte aux pommes et pas simplement un texte avec des ingrédients ? Ou comment les clients email font apparaître un bouton « Confirmer la réservation » directement dans la liste des messages ? La réponse est toujours la même — Schema. org. Mais derrière les familières balises ItemProp et JSON-LD se cache un vaste dépôt GitHub qui fonctionne selon ses propres règles, parfois très étranges.

J'ai décidé d'explorer le code source de ce projet. Il s'avère que ce n'est pas seulement un ensemble de guides de référence, mais un environnement logiciel à part entière avec sa propre logique, ses tests et même une philosophie du « désordre utile ».

Ce que ce projet est réellement

D'habitude, nous percevons Schema. org comme de la documentation. Vous y allez, vous copiez le type de données dont vous avez besoin, vous le collez dans votre code. Mais le dépôt schemaorg/schemaorg est ce à partir de quoi le site lui-même est construit. Il contient toutes les définitions d'entités, des centaines d'exemples de balisage, et des logiciels Python qui transforment des fichiers dispersés en une structure que les moteurs de recherche et les navigateurs peuvent comprendre.

Le projet est supervisé par le W3C, avec des discussions impliquant des gens de Google, Microsoft, Yahoo et Pinterest. C'est l'un de ces cas rares où les géants de l'industrie se sont mis d'accord sur un langage commun pour ne pas avoir à réinventer la roue à chaque coin d'Internet.

Ce ne sont pas que des textes à l'intérieur

Si vous regardez dans le dossier data/, vous pouvez voir comment la norme « respire » réellement. Les schémas de base sont stockés au format Turtle (.ttl). C'est un sous-ensemble de RDF qui ressemble à un ensemble d'énoncés sur le monde.

Il est intéressant de noter que les développeurs ont délibérément rejeté une architecture « belle ». Dans le README, ils disent explicitement : nous ne cherchons pas la pureté ontologique ni l'élégance. Si le choix est entre une logique stricte et faciliter la tâche des webmasters pour implémenter le code, ils choisiront la simplicité. Par exemple, ils pourraient ajouter un type de données sans propriétés juste pour la commodité du balisage, même si pour les amateurs de modélisation formelle, cela ressemble à de l'hérésie.

Fonctionnalités principales du dépôt

1. Évolution pragmatique. L'équipe du projet est sceptique concernant les révisions majeures. Si vous suggérez de remanier la hiérarchie des événements parce que « c'est plus correct », ils écouteront probablement poliment et fermeront le ticket. Ils se soucient de savoir si les changements sont réellement utilisés par les principaux consommateurs de données (moteurs de recherche ou services cloud).
2. Tests locaux. Le dépôt contient des logiciels qui vous permettent de déployer une copie de Schema. org sur votre machine. C'est utile si vous voulez proposer un nouveau type de données et voir comment il s'intègre dans la structure globale.
3. Exemples dans des fichiers texte. Une grande partie de la valeur du projet réside dans les fichiers examples.txt. Des milliers de cas y sont collectés : de la façon de baliser des horaires de bus à la description de procédures médicales complexes.

L'aspect technique

Le projet fonctionne avec Python (version 3.6+ requise). Pour exécuter une version locale du site, vous aurez besoin de Linux ou de WSL2 si vous êtes sur Windows.

Le processus ressemble grossièrement à ceci :

• Installer les dépendances.
• Exécuter les scripts de build.
• Obtenir un serveur local sur le port 8080.

Tous les logiciels sont adaptés pour créer une copie statique du site. L'infrastructure semble un peu conservatrice (utilisant Google App Engine, des scripts Python spécifiques), mais elle fonctionne depuis des années et digère un volume colossal de modifications de la communauté.

Pourquoi un développeur devrait-il explorer cela

Cela peut sembler inutile de cloner le dépôt quand il y a un site web pratique. Il y a quelques scénarios où cela aide vraiment.

Premièrement, quand la documentation standard semble incomplète. Dans le code source dans le dossier data/, vous pouvez souvent trouver des commentaires et des brouillons (dans la section Pending) qui n'ont pas encore été déployés sur la page principale, mais qui sont déjà implémentés par les principaux acteurs.

Deuxièmement, si vous construisez votre propre outil pour l'analyse ou la validation de données. Utiliser schema.ttl comme source primaire est beaucoup plus fiable que d'essayer de récupérer les pages du site web. Ce sont des données propres, prêtes pour le traitement machine.

Troisièmement, c'est une excellente école pour apprendre à gérer un vaste projet open source où les intérêts des entreprises et des développeurs réguliers s'affrontent. Jetez un œil à l'Issue #1 — il y a des années de planification de versions qui s'y déroulent, et c'est un exemple de comment garder le chaos sous contrôle.

Qui devrait s'abonner aux mises à jour

Si vous travaillez dans le SEO, le développement de moteurs de recherche, ou si vous voulez simplement que vos données sur le web soient structurées, ce dépôt devrait être dans vos favoris.

Ne vous attendez pas à des frameworks élégants ni à du code parfait ici. Ce projet concerne le contenu, les accords et le pragmatisme. Parfois, c'est utile de voir que même les normes de classe mondiale ne sont pas construites sur des formules parfaites, mais sur des compromis et l'expérience réelle de millions de personnes.

Pour commencer, jetez simplement un œil au dossier data/examples.txt. Faites-moi confiance, il y a beaucoup de choses intéressantes là-dedans sur la façon dont un Internet structuré devrait réellement ressembler.