Comment décrire les données du Web ?
Depuis les premières heures du web il y a eu plusieurs tentatives successives pour ajouter de la sémantique aux pages HTML.
1. Le problème initial : HTML décrit une présentation
Prenons :
<p>
Cube Reaction Hybrid Pro 750
</p>
<p>
Prix : 2999,99 €
</p>
Un humain comprend :
C'est un produit qui s'appelle Cube Reaction Hybrid Pro 750 et qui coûte 2999,99 €.
Mais pour une machine, ce n'est pas évident.
Elle voit essentiellement :
Cube Reaction Hybrid Pro 750
Prix : 2999,99 €
Comment savoir que le premier texte est un nom de produit et le second un prix ?
C'est le problème de la sémantique des données du Web.
2. Microformats : utiliser les classes HTML
Une première approche a été celle des microformats.
On réutilise les éléments HTML existants et surtout leurs attributs class.
Par exemple :
<div class="hproduct">
<span class="fn">
Cube Reaction Hybrid Pro 750
</span>
<span class="price">
2999.99
</span>
</div>
Les classes :
hproduct
fn
price
ont alors une signification particulière.
Le HTML reste du HTML, mais certaines classes deviennent un vocabulaire conventionnel.
C'est assez élégant, mais il y a un problème :
les classes HTML sont normalement destinées à la présentation et à la structuration du document, notamment CSS/JavaScript.
On détourne donc quelque peu HTML pour y encoder un vocabulaire.
3. Microdata : ajouter des attributs au HTML
HTML5 a ensuite apporté les Microdata.
On peut écrire :
<div itemscope itemtype="https://schema.org/Product">
<span itemprop="name">
Cube Reaction Hybrid Pro 750
</span>
<span itemprop="description">
VTT électrique
</span>
<span itemprop="brand">
Cube
</span>
</div>
Là, la distinction est beaucoup plus claire.
itemscope
« Ici commence un objet. »
itemtype
« Cet objet est un
Product. »
itemprop
« Cette donnée est la propriété
name,description,brand... »
On obtient donc quelque chose comme :
Product
├── name
├── description
└── brand
4. Schema.org
Schema.org n'est pas un format de sérialisation, c'est un vocabulaire partagé.
Il définit des types :
Product
Person
Organization
Place
Event
Book
Movie
Recipe
...
et leurs propriétés.
"@type": "Product"
signifie donc :
Cet objet est décrit comme un
Productselon le vocabulaire Schema.org.
De même :
"manufacturer": {
"@type": "Organization",
"name": "Cube"
}
décrit le fabricant comme une Organization.
5. RDF : l'idée derrière tout cela
L'idée fondamentale est de représenter les connaissances sous forme de triplets :
sujet → prédicat → objet
Par exemple :
<Victor_Hugo> → <a_pour_auteur> → <Les_Misérables>
Les trois éléments sont
| Élément | Exemple | Rôle |
|---|---|---|
| Sujet | Victor_Hugo | la ressource décrite |
| Prédicat | a_pour_auteur | la relation |
| Objet | Les_Misérables | une autre ressource ou une valeur |
On obtient alors un graphe de connaissance:
┌──────────────┐
│ Victor Hugo │
└──────┬───────┘
│
auteur
│
▼
┌────────────────┐
│ Les Misérables │
└────────────────┘
│
genre
│
▼
"Roman"
RDF est notamment conçu autour de l'idée de données liées (Linked Data), avec des identifiants globaux et des vocabulaires partagés.
RDF est un modèle de données. On peut représenter les mêmes triplets avec plusieurs syntaxes
Les données RDF sont généralement interrogées avec SPARQL.
6. RDF/XML : la première génération est assez lourde
RDF a notamment été sérialisé en RDF/XML.
On peut avoir quelque chose ressemblant à :
<rdf:Description rdf:about="...">
<rdf:type rdf:resource="...Product"/>
<schema:name>
Cube Reaction Hybrid Pro 750
</schema:name>
</rdf:Description>
Cela fonctionne.
Mais pour un développeur Web, c'est assez lourd.
Et surtout, ce n'est pas particulièrement agréable à manipuler.
7. JSON-LD : même idée, mais en JSON
JSON-LD signifie : JSON for Linked Data
On conserve la représentation JSON, mais on lui ajoute une sémantique permettant de représenter des données liées.
Voici un document JSON-LD
{
"@context": "https://schema.org",
"@type": "Product",
...
}
Le rôle de :
"@context": "https://schema.org"
est fondamental.
Il indique le contexte / vocabulaire utilisé.
Et :
"@type": "Product"
indique le type de l'objet.
Les propriétés classiques du JSON restent ensuite très naturelles :
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Cube Reaction Hybrid Pro...",
"manufacturer": {
"@type": "Organization",
"name": "Cube"
}
}
C'est beaucoup plus facile à lire pour un développeur habitué à JSON.
8. Les différentes approches en une seule vue
| Technologie | Où est la sémantique ? | Exemple |
|---|---|---|
| Microformats | class HTML | class="fn" |
| Microdata | attributs HTML spécifiques | itemscope, itemtype, itemprop |
| RDFa | attributs HTML permettant d'exprimer RDF | property, typeof, vocab |
| RDF/XML | document XML | <rdf:Description> |
| JSON-LD | document JSON + contexte | @context, @type |
| Schema.org | vocabulaire utilisé par ces formats | Product, Person, Organization |
9. Et pourquoi Google s'intéresse à tout cela ?
Une page contenant :
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Cube Reaction Hybrid Pro",
"offers": {
"@type": "Offer",
"price": 2999.99,
"priceCurrency": "EUR"
}
}
donne aux moteurs de recherche des informations structurées sur le produit.
Le moteur n'a donc plus uniquement à essayer de comprendre le texte de la page.
Il peut comprendre :
Product
│
┌────┴─────┐
▼ ▼
name Offer
│
┌───┴────┐
▼ ▼
price currency
JSON Lines
JSON Lines, souvent abrégé JSONL ou NDJSON (Newline Delimited JSON), est un format où chaque ligne du fichier contient un objet JSON indépendant.
{"id": 1, "nom": "Vélo de route", "prix": 1299}
{"id": 2, "nom": "VTT", "prix": 899}
{"id": 3, "nom": "Vélo électrique", "prix": 2499}
Chaque ligne est un JSON valide à elle seule.
Ce format est utilise