Aller au contenu

TP : Linked Open Data & SPARQL

SPARQL DBpedia Outil

Auteurs

Organisation de la séance (4 h)

Durée Activité
~1 h Cours préparatoire : Linked Open Data & SPARQL
~2 h Partie 1 — 14 requêtes guidées sur DBpedia
~45 min Partie 2 — Requête originale sur une base LOD de votre choix
~15 min Rédaction et dépôt du compte-rendu sur Pedagogie3

⚠️ Compte-rendu : le rendu est individuel et doit être déposé sur Pedagogie3 avant la fin de la séance.

⚠️ IA générative : le TP se fait sans IA générative (ChatGPT, Gemini, Copilot…). Une requête trouvée sur Internet, reprise d’un autre rendu ou produite par une IA vaut 0/20.

Point d’étape : au bout de 2 h de TP, passez à la Partie 2 même si le Bloc 5 n’est pas fini ; les requêtes marquées ★ sont facultatives.

Objectifs

À la fin du TP, vous savez :

  • écrire un motif de graphe à un ou deux sauts ;
  • filtrer (dates, langues, chaînes) ;
  • compter et classer (GROUP BY, ORDER BY) ;
  • trouver la propriété qui vous manque ;
  • lire un résultat d’un œil critique (trous, doublons, erreurs des données) ;
  • concevoir une requête originale sur une autre base.

Références utiles :

Table des matières

Démarrage avec Yasgui

Pour toutes les requêtes de ce TP, vous utiliserez le client en ligne Yasgui — aucune installation requise.

Prise en main rapide :

  1. Ouvrez yasgui.triply.cc dans votre navigateur.
  2. L’endpoint par défaut est DBpedia (https://dbpedia.org/sparql) — parfait pour la Partie 1.
  3. Pour changer d’endpoint (Partie 2), cliquez sur l’URL en haut de l’interface et remplacez-la : voir Utiliser Yasgui sur ces bases.
  4. Tapez votre requête dans la zone de texte, puis cliquez sur ▶ (ou Ctrl+Entrée).
  5. Les résultats s’affichent sous forme de tableau dans l’onglet Table ; les autres onglets (Chart, Geo…) et le lien de partage sont décrits dans la Partie 2.

💡 Bonne pratique : ajoutez toujours un LIMIT 100 à vos requêtes exploratoires pour éviter les timeouts et les résultats excessifs. Retirez-le seulement quand vous êtes sûr de votre requête.

Travaux pratiques sur DBpedia

Quelques IRI utiles

IRI Type Description
foaf:Person Classe Classe des personnes
dbo:Country Classe Classe des pays
dbo:City Classe Classe des villes
dbo:University Classe Classe des universités
foaf:name Propriété Nom d’une personne (entre autres)
dbo:birthDate Propriété Date de naissance d’une personne
dbo:birthPlace Propriété Lieu de naissance d’une personne
dbo:deathDate Propriété Date de décès d’une personne
dbo:deathPlace Propriété Lieu de décès d’une personne
dbo:city Propriété Ville
dbo:country Propriété Pays auquel un lieu appartient
dbo:almaMater Propriété Université où une personne a étudié
dbr:Lyon Instance La ville de Lyon
dbr:France Instance La France

Pour trouver une propriété

  • Cliquez sur une IRI dans le tableau de résultats de Yasgui : elle ouvre sa fiche DBpedia (https://dbpedia.org/page/…), qui liste toutes ses propriétés.
  • Préférez dbo: à dbp: : dbo: est l’ontologie de DBpedia, aux noms stables ; dbp: reprend telles quelles les infobox de Wikipédia. Par exemple, dbo:birthPlace dbr:Lyon donne 766 personnes, dbp:birthPlace dbr:Lyon seulement 306 (septembre 2026).
  • Demandez à la base quelles propriétés décrivent une ressource, les plus fréquentes d’abord :
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?p (COUNT(*) AS ?n) WHERE { dbr:Lyon ?p ?o } GROUP BY ?p ORDER BY DESC(?n)

Remplacez dbr:Lyon ?p ?o par ?s ?p dbr:Lyon pour obtenir les propriétés qui pointent vers Lyon : dbo:birthPlace y figure.

Préfixes utilisés pour accéder aux vocabulaires

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX dbo:  <http://dbpedia.org/ontology/>
PREFIX dbr:  <http://dbpedia.org/resource/>
PREFIX dbp:  <http://dbpedia.org/property/>
PREFIX xsd:  <http://www.w3.org/2001/XMLSchema#>

DBpedia connaît ces préfixes même sans déclaration ; beaucoup d’autres bases (Prix Nobel, OpenStreetMap/QLever…) ne les connaissent pas, et la requête échoue. Déclarez toujours vos PREFIX, en tête de requête. Pour trouver un préfixe inconnu, consultez prefix.cc.

14 requêtes à programmer

TIP : Yasgui signale les erreurs de syntaxe au fil de la frappe (icône d’erreur dans la marge de gauche : survolez-la pour lire le message) et reformate une requête avec Ctrl+Maj+F (touche Ctrl aussi sur Mac ; pas de bouton dédié).

Ma requête ne renvoie rien (ou trop peu) : 7 réflexes

  1. Retirez les motifs un par un (mettez une ligne en commentaire avec #) : quand les lignes reviennent, vous tenez le motif fautif.
  2. Vérifiez la casse et l’orthographe des IRI : dbr:Lyon, pas dbr:lyon. Une IRI inconnue ne provoque aucune erreur, juste 0 ligne.
  3. dbo: (ontologie) ou dbp: (infobox brute) : si l’un ne donne rien, essayez l’autre.
  4. Une marque rouge dans la marge de Yasgui signale une erreur de syntaxe, souvent un PREFIX non déclaré (survolez-la : Prefix 'dbo' is not defined). DBpedia pardonne cet oubli ; d’autres bases échouent sans nommer le préfixe (Prix Nobel : « Internal Server Error »).
  5. Libellés (rdfs:label) : il en existe un par langue. Filtrez la langue (FILTER(LANG(?label) = "fr")), sinon chaque ligne se répète ; une ressource sans libellé dans cette langue disparaît alors.
  6. Exactement 10 000 lignes : DBpedia a tronqué le résultat, sans prévenir. Paginez avec ORDER BY … LIMIT 10000 OFFSET 10000, ou comptez d’abord avec COUNT.
  7. Trop long (délai dépassé) : ajoutez un LIMIT, restreignez le motif (une classe, une ville, une période).

Bloc 1 — Sélection simple (requêtes 1 à 3)

  1. Afficher les IRI des Lyonnais (i.e. personnes nées à Lyon). Voici la réponse attendue pour vous aider à démarrer avec Yasgui :
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?p 
WHERE {
  ?p         a      foaf:Person;
    dbo:birthPlace dbr:Lyon.
}

Vérifiez que, pour Lyon, préciser ou non que ?p est une personne (a foaf:Person) ne change pas le résultat. Ce n’est pas une règle générale : dans DBpedia, dbo:birthPlace est presque toujours porté par des ressources typées foaf:Person, mais environ 230 autres le portent aussi (surtout des musiciens typés par erreur comme groupes, dbo:Band) ; aucune ne concerne Lyon. Dans le doute, gardez le type.

Auto-évaluation — Q1

Vous devez obtenir quelques centaines d’IRI (l’effectif fluctue avec les mises à jour de DBpedia : 766 en septembre 2026, avec ou sans a foaf:Person), une seule colonne ?p, par exemple :

http://dbpedia.org/resource/Antoine_de_Saint-Exupéry
http://dbpedia.org/resource/Bertrand_Tavernier
http://dbpedia.org/resource/Bernard_Pivot
…

  1. Afficher les IRI et les noms (foaf:name) des Lyonnais, dans l’ordre alphabétique. Comparez le nombre de lignes avec Q1 : pourquoi certains Lyonnais disparaissent-ils, et pourquoi d’autres apparaissent-ils deux fois ? (TIP : cliquez sur l’IRI d’une personne pour ouvrir sa fiche DBpedia, par exemple dbr:Eliot_Berthon, présent en Q1, ou dbr:David_Bedok.) Il ne vous est pas demandé de résoudre ce problème.
Vérifier mon résultat — Q2

Deux colonnes (?p, ?name), environ 750 lignes (752 lignes pour 706 personnes en septembre 2026). Aucun nom n’est vide. La première ligne commence par « ( » : le tri compare les caractères un à un, dans l’ordre Unicode ; la ponctuation passe avant les lettres, les autres alphabets (hébreu, arabe…) après.

Pour la question posée, comparez avec les 766 IRI de Q1 et ouvrez les deux fiches suggérées : que leur manque-t-il, ou qu’ont-elles en trop ?

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
SELECT * 
WHERE {
  ?p dbo:birthPlace dbr:Lyon ; foaf:name ?name .
}
ORDER BY ASC(?name)

Le ; ajoute un second motif sur le même sujet ?p : la personne doit être née à Lyon et avoir un nom. ORDER BY ASC(?name) trie par nom.

Pourquoi des Lyonnais disparaissent-ils ou apparaissent-ils deux fois ? 60 des 766 Lyonnais de Q1 n’ont pas de foaf:name (ex. dbr:Eliot_Berthon) : un triplet absent ne correspond à aucun motif, la personne disparaît du résultat — un trou de données dans la source. À l’inverse, 46 personnes ont deux noms (ex. dbr:David_Bedok) et occupent deux lignes.

  1. Afficher les noms des Lyonnais ne contenant pas de virgule (fonction contains).
Vérifier mon résultat — Q3

Très peu de noms contiennent une virgule (2 en septembre 2026, ex. « Bernard of Vienne, Bernard of Romans ») : vous passez de 752 à 750 lignes.

Pièges fréquents :

  • vous obtenez 2 lignes seulement : votre filtre garde les noms à virgule au lieu de les écarter ;
  • DBpedia s’arrête sur une erreur « CONTAINS() needs a string value as first argument » : la variable testée contient des IRI, pas seulement du texte (voir la solution).
Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT DISTINCT ?p ?name ?strname
WHERE {
  ?p dbo:birthPlace dbr:Lyon;
     foaf:name ?name.
  BIND(str(?name) AS ?strname)
  FILTER(!contains(?strname, ','))
}
ORDER BY ASC(?name)

BIND(str(?name) AS ?strname) sert à afficher le nom sans son étiquette de langue (@en). contains() accepte aussi directement un littéral étiqueté : c’est ce que font les solutions de Q4 à Q8. str() devient indispensable quand la colonne peut contenir des IRI : sans lui, DBpedia s’arrête sur une erreur (« CONTAINS() needs a string value as first argument »).

Bloc 2 — Filtres et dates (requêtes 4 à 6)

  1. Afficher les noms (sans virgule) et dates de naissance des Lyonnais.
Vérifier mon résultat — Q4

Trois colonnes (IRI, nom, date de naissance), environ 700 lignes (691 en septembre 2026), par exemple dbr:Abbé_Pierre, « Abbé Pierre », 1912-08-05. Vous perdez des résultats par rapport à Q3, car certaines fiches n’ont pas de dbo:birthDate.

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT DISTINCT ?p ?strname ?bdate
WHERE {
  ?p dbo:birthPlace dbr:Lyon;
     foaf:name ?name;
     dbo:birthDate ?bdate.
  BIND(str(?name) AS ?strname)
  FILTER(strlen(?name) != 0)
  FILTER(!contains(?name, ","))
}
ORDER BY ASC(?strname)

Même structure que Q3, avec un troisième motif dbo:birthDate ?bdate sur la même personne : une fiche sans ce triplet ne correspond plus au motif et disparaît. Les deux FILTER écartent les noms vides et ceux qui contiennent une virgule.

  1. Afficher les noms et dates de naissance des Lyonnais nés après 1900 (FILTER(year(?bdate) > 1900)).

  2. Afficher les noms et dates de naissance des Lyonnais nés après 1900 avec, le cas échéant, leur date de décès (OPTIONAL).

Vérifier mon résultat — Q5 et Q6

Environ 500 personnes (540 lignes pour 497 personnes en septembre 2026). La première naissance retenue est le 16/09/1901 (Albert Thévenon, en tête si vous triez par date de naissance).

En Q6, la colonne de la date de décès est vide pour les Lyonnais encore vivants (seules 124 lignes ont une date de décès) — c’est exactement le rôle de OPTIONAL. Si toutes vos lignes ont une date de décès, votre OPTIONAL est mal placé (probablement combiné avec un FILTER à l’extérieur).

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?p ?strname ?bdate ?ddate
WHERE {
  ?p dbo:birthPlace dbr:Lyon;
     foaf:name ?name;
     dbo:birthDate ?bdate.
  BIND(str(?name) AS ?strname)
  FILTER(strlen(?name) != 0)
  FILTER(!contains(?name, ","))
  FILTER(year(?bdate) > 1900)
  OPTIONAL { ?p dbo:deathDate ?ddate }    # retirer cette ligne pour Q5
}
ORDER BY ASC(?bdate)

Q5 et Q6 partagent la même structure ; Q6 ajoute simplement le bloc OPTIONAL { ?p dbo:deathDate ?ddate }.

Bloc 3 — Relations spatiales (requêtes 7 et 8)

  1. Afficher les noms de tous les Lyonnais morts à Lyon.
Vérifier mon résultat — Q7

Quelques dizaines de résultats (33 en septembre 2026). La date de décès la plus récente est le 11/04/2022 (René Mornex) : la version en ligne de DBpedia s’arrête vers septembre 2025 et ne suit pas l’actualité. Même parmi tous les Lyonnais, où qu’ils soient morts, le décès le plus récent date de juin 2025.

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?p ?strname ?ddate
WHERE {
  ?p dbo:birthPlace dbr:Lyon;
     foaf:name ?name;
     dbo:deathPlace dbr:Lyon.
  BIND(str(?name) AS ?strname)
  FILTER(strlen(?name) != 0)
  FILTER(!contains(?name, ","))
  OPTIONAL { ?p dbo:deathDate ?ddate }
}
ORDER BY DESC(?ddate)

Il suffit d’un troisième motif sur la même personne, dbo:deathPlace dbr:Lyon. La date de décès, placée en OPTIONAL, sert à trier du décès le plus récent au plus ancien sans écarter les personnes qui n’en ont pas.

  1. ★ (facultative) Afficher les noms de tous les Lyonnais morts hors de France.

On est obligé de distinguer le cas où le lieu de décès est un pays ou une ville : si c’est un pays, il suffit de vérifier que ce n’est pas la France ; si c’est une ville, il faut vérifier que cette ville n’est pas en France.

Piste si vous bloquez 
?deathPlace a ?deathPlaceType.
FILTER ((?deathPlaceType = dbo:Country && ?deathPlace != dbr:France) || 
    (?deathPlaceType = dbo:City && NOT EXISTS { ?deathPlace dbo:country dbr:France }))
Vérifier mon résultat — Q8

Le résultat dépend de la méthode choisie.

En suivant la piste, vous trouvez 55 personnes ; chaque ligne y est répétée jusqu’à trois fois, car DBpedia stocke certains triplets en plusieurs exemplaires : ajoutez DISTINCT. La piste traite le cas des pays, mais elle a ses propres défauts. DBpedia désigne souvent la France par un régime historique (dbr:French_Third_Republic, dbr:Kingdom_of_France, dbr:July_Monarchy, dbr:Vichy_France…), typé dbo:Country et différent de dbr:France : la piste le compte comme étranger. Sur les 55 personnes qu’elle trouve, 28 sont ainsi mortes… en France (René Mornex, mort à Lyon, en fait partie).

Avec la solution de référence simplifiée (encadré ci-dessous), environ 30 lignes (33 lignes pour 26 personnes en septembre 2026). Regardez la colonne des pays : dbr:Essex ou une équipe nationale de football y figurent comme « pays ».

Aucune des deux requêtes n’est parfaite : à discuter en groupe.

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?p ?strname ?dcountry ?ddate
WHERE {
  ?p dbo:birthPlace dbr:Lyon;
     foaf:name ?name;
     dbo:deathPlace ?dplace.
  ?dplace dbo:country ?dcountry.
  FILTER(?dcountry != dbr:France)
  BIND(str(?name) AS ?strname)
  FILTER(strlen(?name) != 0)
  FILTER(!contains(?name, ","))
  OPTIONAL { ?p dbo:deathDate ?ddate }
}
ORDER BY DESC(?ddate)

Solution de référence simplifiée, une formulation plus simple que la piste : on impose que le lieu de décès soit lié à un pays différent de la France via dbo:country. Cette version rate les cas où ?dplace est directement un pays (et n’a donc pas de dbo:country lui-même).

Bloc 4 — Relations entre entités (requêtes 9 à 11)

Ces trois requêtes relient des personnes à leur université (dbo:almaMater) et aux lieux (ville, pays). Deux IRI utiles : dbo:University (classe des universités) et dbo:almaMater (université où une personne a étudié).

  1. Afficher les personnes diplômées d’une université française nées dans la ville même de cette université, avec le nom de l’université (libellé rdfs:label en français).
Vérifier mon résultat — Q9

Deux colonnes (nom de la personne, nom de l’université en français), environ 150 lignes attendues (142 en septembre 2026), par exemple « Jean-Jack Queyranne », « Institut d’études politiques de Lyon ».

Plus de 2 000 lignes ? Chaque personne apparaît alors plusieurs fois : une université a un libellé par langue.

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT DISTINCT ?strname ?uniname
WHERE {
  ?uni a dbo:University;
       dbo:country dbr:France;
       dbo:city ?city;
       rdfs:label ?uniname.
  ?p dbo:almaMater ?uni;
     dbo:birthPlace ?city;
     foaf:name ?name.
  BIND(str(?name) AS ?strname)
  FILTER(strlen(?name) != 0)
  FILTER(LANG(?uniname) = "fr")
}
ORDER BY ?uniname

Le truc clé est de réutiliser la variable ?city dans dbo:birthPlace ?city — c’est ce qui force l’égalité (ville de naissance = ville de l’université). Sans le filtre sur LANG(?uniname), qui ne garde que le libellé français, chaque personne apparaît plusieurs fois (plus de 2 000 lignes).

  1. Afficher les diplômés d’une université française nés hors de France, avec leur pays de naissance.
Vérifier mon résultat — Q10

Deux colonnes (nom, pays de naissance), environ 500 lignes (497 en septembre 2026). Vérifiez qu’aucune ligne ne contient France dans la colonne des pays.

À discuter : une IRI malformée. La colonne des pays contient http://dbpedia.org/resource/http://dbpedia.org/resource/Germany sur 15 lignes (17 diplômés en tout, dont 2 sans foaf:name, en septembre 2026). Ce n’est pas votre requête qui se trompe : c’est une erreur d’extraction de DBpedia, qui touche 11 362 ressources de DBpedia, dont Heidelberg, Leipzig et Wiesbaden. L’Allemagne figure donc sous deux IRI (6 lignes pour dbr:Germany, 15 pour l’IRI malformée) : que donnerait un comptage par pays ?

À discuter : l’Algérie en tête. Le pays de naissance le plus fréquent est l’Algérie (36 lignes en septembre 2026, devant le Maroc, 31). Parmi les 36 diplômés nés en Algérie, 29 sont nés avant l’indépendance (juillet 1962), quand l’Algérie était française ; 2 sont nés après et 5 n’ont pas de date de naissance. La requête ne le sait pas : pour DBpedia, Oran ou Annaba sont en Algérie, quelle que soit la date de naissance. Ces 29 personnes sont-elles « nées hors de France » ?

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT DISTINCT ?strname ?country
WHERE {
  ?uni a dbo:University;
       dbo:country dbr:France.
  ?p dbo:almaMater ?uni;
     foaf:name ?name;
     dbo:birthPlace ?bplace.
  ?bplace dbo:country ?country.
  FILTER(?country != dbr:France)
  BIND(str(?name) AS ?strname)
}

Le lieu de naissance est ici une ville, dont on remonte au pays par dbo:country : une personne dont dbo:birthPlace est directement un pays n’apparaît pas (à discuter).

  1. ★ (facultative) Généraliser : afficher les personnes nées hors du pays de leur université, toutes nationalités confondues. Ajoutez LIMIT 100.
Vérifier mon résultat — Q11

Une ligne par personne et par couple de pays : nom, université, pays de l’université, pays de naissance. Sans LIMIT, la requête produit environ 13 800 lignes (13 771 en septembre 2026). L’endpoint public de DBpedia n’en renvoie que 10 000, sans message d’erreur : un résultat d’exactement 10 000 lignes est tronqué (pour tout récupérer, paginez avec ORDER BY … LIMIT 10000 OFFSET 10000). C’est aussi pour cela qu’on borne les requêtes exploratoires.

Vérifiez que le pays de l’université et le pays de naissance diffèrent sur chaque ligne, puis repérez les faux positifs : Scotland, England ou Wales n’est pas United_Kingdom, et certains « pays » n’en sont pas (Wales_national_rugby_union_team…). Sur l’ensemble, environ une ligne sur cinq est ainsi interne au Royaume-Uni (2 668 sur 13 771 en septembre 2026) ; sans ORDER BY, les 100 lignes affichées peuvent en contenir bien davantage. Bonne occasion de discuter de la qualité des données.

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX dbo: <http://dbpedia.org/ontology/>
SELECT DISTINCT ?strname ?uni ?ucountry ?bcountry
WHERE {
  ?uni a dbo:University;
       dbo:country ?ucountry.
  ?p dbo:almaMater ?uni;
     dbo:birthPlace ?bplace;
     foaf:name ?name.
  ?bplace dbo:country ?bcountry.
  FILTER(?ucountry != ?bcountry)
  BIND(str(?name) AS ?strname)
}
LIMIT 100

Q10 généralisé : on remplace dbr:France par une variable ?ucountry côté université. Les colonnes ?ucountry et ?bcountry sont le pays de l’université et le pays de naissance ; le FILTER impose qu’ils diffèrent.

Bloc 5 — Agrégation (requêtes 12 à 14)

  1. Afficher le nombre de diplômés d’universités françaises nés hors de France (COUNT).
Vérifier mon résultat — Q12

Une seule ligne, une seule colonne : de l’ordre de 500 (513 en septembre 2026). Ce nombre compte des personnes. Q10 affiche un peu moins de lignes (497) : 38 de ces diplômés n’ont pas de foaf:name et disparaissent de Q10 ; à l’inverse, une personne qui a deux noms ou dont la ville de naissance a deux pays y occupe plusieurs lignes.

Pièges fréquents :

  • de l’ordre de 900 (889 en septembre 2026) : votre filtre est inversé (= au lieu de !=) ; environ 3 000 si, en plus, vous comptez des lignes (voir le piège suivant) ;
  • de l’ordre de 1 700 (1 720 en septembre 2026) : vous comptez des lignes, pas des personnes. Une personne compte autant de fois qu’elle a de combinaisons (université, lieu de naissance, pays), et DBpedia stocke le type de la plupart des universités en deux ou trois exemplaires (voir Q8).

À discuter : ce total compte comme « nés hors de France » les 29 diplômés nés en Algérie avant l’indépendance (voir Q10).

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT (COUNT(DISTINCT ?p) AS ?nb_diplomes)
WHERE {
  ?uni a dbo:University;
       dbo:country dbr:France.
  ?p dbo:almaMater ?uni;
     dbo:birthPlace ?bplace.
  ?bplace dbo:country ?country.
  FILTER(?country != dbr:France)
}

COUNT(DISTINCT ?p) compte les personnes : une personne liée à plusieurs universités, lieux ou pays n’est comptée qu’une fois, et un triplet stocké en plusieurs exemplaires ne la compte pas plusieurs fois.

  1. Afficher pour 10 villes françaises le nombre de natifs présents dans DBpedia (GROUP BY, LIMIT).
Vérifier mon résultat — Q13

Vous devez voir 2 colonnes : ?ville (IRI) et ?nb_natifs (entier), sur 10 lignes. Sans ORDER BY, les 10 villes affichées sont arbitraires — c’est l’objectif de cet exercice (préparer Q14).

À discuter : vos « villes » en sont-elles toutes ? Des régions et des départements, y compris d’outre-mer, passent aussi : en prolongeant le classement de Q14 au-delà des 10 premiers, on trouve entre la 20e et la 50e place dbr:Martinique, dbr:Normandy, dbr:Île-de-France, dbr:Hauts-de-Seine, dbr:Brittany… « Ville » est notre mot, pas celui de DBpedia.

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?ville (COUNT(?p) AS ?nb_natifs)
WHERE {
  ?ville dbo:country dbr:France.
  ?p dbo:birthPlace ?ville.
}
GROUP BY ?ville
LIMIT 10

Attention : ?ville dbo:country dbr:France ne sélectionne pas que des villes, mais tout ce que DBpedia situe en France (voir ci-dessus).

  1. Afficher les 10 villes françaises ayant le plus de natifs dans DBpedia, triées dans l’ordre décroissant du nombre de natifs (GROUP BY, ORDER BY DESC, LIMIT).
Vérifier mon résultat — Q14

Paris arrive très largement en tête (5 292 natifs en septembre 2026), suivie de Marseille (834), Lyon (766, comme en Q1), Bordeaux, Toulouse… (l’ordre exact et les effectifs varient avec les mises à jour de DBpedia). Si Paris n’est pas n°1, vérifiez votre ORDER BY (manque le DESC ?).

Solution — à n’ouvrir qu’après avoir essayé 
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>
SELECT ?ville (COUNT(?p) AS ?nb_natifs)
WHERE {
  ?ville dbo:country dbr:France.
  ?p dbo:birthPlace ?ville.
}
GROUP BY ?ville
ORDER BY DESC(?nb_natifs)
LIMIT 10

C’est la requête de Q13, triée : ORDER BY DESC(?nb_natifs) classe par nombre de natifs décroissant, puis LIMIT 10 garde les 10 premières lignes.

Requête originale sur une base Linked Data

Consignes pour le compte-rendu

Énoncé : choisissez une base de données Linked Open Data dans la liste ci-dessous (autre que DBpedia) et inventez une (1) requête originale sur cette base. Pour les étudiants les moins à l’aise, il est conseillé d’utiliser la base des Prix Nobel. Vous pouvez partir d’un exemple de cette page, à condition de changer la question et de le signaler.

Le compte-rendu porte uniquement sur cette partie du TP. C’est un travail personnel et le rendu est donc individuel. Déposez votre CR sur Pedagogie3 en respectant les consignes suivantes :

  • Rédigez un rapport court (1 à 1,5 page) comprenant :

    1. La question à laquelle répond votre requête, en une phrase.
    2. Le SPARQL endpoint utilisé, c’est-à-dire l’URL collée dans Yasgui (ex. https://data.nobelprize.org/store/nobelprize/sparql), le producteur de la base et sa licence (indiquée dans la fiche de la base ci-dessous quand elle est connue ; sinon, cherchez-la sur son site).
    3. Le dessin RDF de la requête, avec la convention du cours (variables, IRI, littéraux ; les FILTER en note) — à la main (photo) ou avec diagrams.net.
    4. Le code SPARQL de la requête et son lien de partage Yasgui (voir plus bas), pour que nous puissions la rejouer.
    5. Les 3 ou 4 premiers résultats (capture d’écran où l’endpoint est visible), avec la date et l’heure d’exécution notées sous la capture : si la base devient inaccessible avant la correction, votre capture et cette date font foi.
    6. Ce que montrent les résultats, et une limite des données (trou, doublon, biais…), en deux ou trois phrases.

  • Si votre CR est au format PDF, copiez également votre requête dans un fichier texte séparé (les copier-coller depuis un PDF sont souvent problématiques).

  • Nommez votre archive VotreNom_LoD.zip (ou .rar, .tgz) et déposez un seul fichier sur l’espace Pedagogie3 de votre groupe de TP, avant la fin de la séance.

  • La note prend en compte l’originalité de la question, la qualité du code et la lecture critique des résultats. Attention à la triche : une requête trouvée sur Internet (y compris parmi les exemples de rendus publiés sur ce site), reprise d’un autre rendu ou produite par une IA vaut 0/20.

  • Partez du gabarit de compte-rendu (Word, LibreOffice ou Google Docs) : il reprend les six rubriques dans l’ordre. Un autre format convient s’il les garde toutes.

  • Téléchargez avec ce lien un exemple de rendu complet (compte-rendu PDF et fichier texte de la requête), qui suit les six rubriques. Il porte sur DBpedia, exclue de la partie notée.

Choisir une base qui répond

Beaucoup de bases référencées sur les moteurs de recherche ou sur le LOD Cloud ne répondent plus (projets arrêtés, serveurs coupés). Choisissez votre base dans la liste ci-dessous : chacune a été testée dans Yasgui le 27 septembre 2026, et l’est de nouveau la veille de chaque séance.

  • Niveau 1 — bases conseillées (1 à 6) : servies par des infrastructures robustes.
  • Niveau 2 — autres bases testées (7 à 10) : serveurs d’institutions, plus fragiles. Faites le test de vie avant d’y consacrer du temps.
  • Une autre base ? Elle n’est acceptée que si elle passe le test de vie dans Yasgui et si l’enseignante la valide avant que vous commenciez.
  • Plan B : si votre base tombe pendant la séance (délai dépassé, erreur du serveur, « 429 Too Many Requests »), passez à une base de niveau 1. Ne restez pas bloqué plus de dix minutes.

Test de vie (30 secondes). Dans un onglet Yasgui réglé sur la base, lancez :

SELECT * WHERE { ?s ?p ?o } LIMIT 5

Si des lignes s’affichent, la base répond.

Explorer la base. Partez de l’exemple fourni pour la base : copiez l’une des IRI de ses résultats (clic droit sur le lien, « copier l’adresse du lien ») et listez tout ce que la base dit de cette ressource :

SELECT ?p ?o WHERE { <collez-ici-une-IRI> ?p ?o } LIMIT 50

Chaque ligne donne une propriété (?p) que vous pouvez réutiliser dans votre requête. Cette exploration répond en moins d’une seconde sur toutes les bases de la liste. La documentation de la base (lien sous son nom) complète le tableau.

Lister ou compter les classes (petites bases seulement) 
SELECT DISTINCT ?classe WHERE { ?s a ?classe } LIMIT 50

SELECT ?classe (COUNT(?s) AS ?n)
WHERE { ?s a ?classe . }
GROUP BY ?classe
ORDER BY DESC(?n)
LIMIT 20

Sur les grosses bases (OpenStreetMap, brevets), ces deux requêtes peuvent dépasser le délai : la base n’est pas en panne pour autant.

Utiliser Yasgui sur ces bases

  1. Un onglet par base : cliquez sur + en haut de Yasgui, et gardez DBpedia dans le premier onglet.
  2. Collez l’URL de l’endpoint (ligne « Endpoint pour Yasgui » de chaque base) dans le champ en haut de l’onglet. N’y mettez pas l’adresse de l’interface web de la base : c’est une page HTML, et Yasgui affiche une erreur.
  3. Plus simple encore : sous chaque exemple, le lien « ▶ Ouvrir dans Yasgui » ouvre un onglet déjà réglé (endpoint et requête). Il ne reste qu’à cliquer sur ▶ (ou Ctrl+Entrée).
  4. Déclarez vos préfixes : ces bases ne connaissent pas les préfixes de DBpedia (dbo:, dbr:…). Chaque requête commence par ses lignes PREFIX ; prefix.cc aide à les retrouver.
  5. Laissez la méthode sur POST (icône ⚙ à gauche de l’URL) : c’est le réglage par défaut, et la base des Prix Nobel ne fonctionne qu’ainsi.
  6. Exploiter les résultats, sous l’éditeur :
    • Table (tableau) et Response (réponse brute du serveur) ;
    • Chart : un graphique (barres, courbes) à partir d’une colonne de libellés et d’une colonne de nombres ; l’onglet affiche d’abord un tableau, cliquez sur Configure pour choisir le type de graphique — une piste pour la figure du dossier ;
    • Geo : une carte, quand une colonne contient des géométries (exemple B d’OpenStreetMap) ;
    • l’icône ⬇ télécharge les résultats (CSV) ;
    • l’icône « partager », en haut à droite de l’éditeur, donne un lien qui rejoue votre requête : mettez-le dans votre compte-rendu.
  7. Messages d’erreur fréquents :
Ce que vous voyez Cause Que faire
« Request has been terminated … Access-Control-Allow-Origin » la base refuse les requêtes venant de Yasgui changer de base
« … HTTP endpoint … from an HTTPS website » l’URL commence par http:// écrire https://
erreur 400, « Parse error » faute de syntaxe ou préfixe non déclaré relire la ligne indiquée, ajouter le PREFIX
0 ligne, sans message le motif ne correspond à rien (casse, préfixe, propriété inexistante) retirer les motifs un par un
« 429 Too Many Requests » (Wikidata) trop de requêtes depuis l’école attendre une minute, ou plan B
délai dépassé (504, « timeout ») requête trop lourde restreindre le motif, ajouter LIMIT

De la requête à la figure du dossier

Le dossier de synthèse exige une figure originale, produite avec SPARQL ou QGIS. Dans Yasgui, l’onglet Chart affiche d’abord un tableau : cliquez sur Configure, choisissez un type de graphique (barres, courbes…) puis OK. Entraînez-vous sur la requête 14, mais la figure du dossier doit répondre à une question de votre groupe. L’onglet Geo trace une carte ; l’export CSV permet aussi de tracer la figure avec pandas, en complément. Citez la base comme au cours 2 : producteur, titre, URL, date de mise à jour, date de téléchargement, licence.

Bases disponibles

Niveau 1 — bases conseillées

1. Prix Nobel

  • Endpoint pour Yasgui : https://data.nobelprize.org/store/nobelprize/sparql
  • Interface web : data.nobelprize.org/sparql · structure des données : spécification — bien faite et relativement simple
  • Données sous licence CC0 (Nobel Prize Outreach). Base conseillée si vous débutez.
Exemple — les lauréats les plus récents 
PREFIX nobel: <http://data.nobelprize.org/terms/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT DISTINCT ?name ?year WHERE {
    ?person a nobel:Laureate;
        rdfs:label ?name;
        nobel:laureateAward ?award.
    ?award nobel:year ?year.
} ORDER BY DESC(?year) LIMIT 20

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

2. Wikidata

  • Endpoint pour Yasgui : https://query.wikidata.org/sparql
  • Interface web : query.wikidata.org — autocomplétion, centaines d’exemples prêts à l’emploi ; à préférer pour les faits contemporains absents de DBpedia
  • Données sous licence CC0. Propriétés et classes sont codées (wdt:P31 = « nature de l’élément », wd:Q6256 = « pays ») : cherchez les codes sur wikidata.org.
  • Les articles scientifiques ne sont plus dans cet endpoint : ils sont sur https://query-scholarly.wikidata.org/sparql (ou utilisez DBLP, base 6).
  • Si Wikidata répond « 429 Too Many Requests », attendez une minute ou passez au plan B : toute l’école partage la même adresse IP, et Wikidata limite le temps de calcul par minute.
Exemple — les 27 pays membres de l'Union européenne 
PREFIX bd: <http://www.bigdata.com/rdf#>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX pq: <http://www.wikidata.org/prop/qualifier/>

SELECT ?pays ?paysLabel WHERE {
  ?pays wdt:P31 wd:Q6256 ;
        p:P463 ?adhesion .
  ?adhesion ps:P463 wd:Q458 .
  FILTER NOT EXISTS { ?adhesion pq:P582 ?fin . }
  SERVICE wikibase:label { bd:serviceParam wikibase:language "fr,en". }
}
ORDER BY ?paysLabel

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

wdt:P463 wd:Q458 (« membre de l’UE ») ne regarde pas les dates : il compterait encore le Royaume-Uni (28 pays). On passe donc par la déclaration complète (p:, ps:) pour écarter les adhésions qui ont une date de fin (qualificatif pq:P582).

3. OpenStreetMap (QLever)

  • Endpoint pour Yasgui : https://qlever.dev/api/osm-planet
  • Interface web : qlever.dev/osm-planet — exemples intégrés et autocomplétion
  • Données © contributeurs OpenStreetMap, licence ODbL, converties en RDF par l’université de Fribourg-en-Brisgau (outil osm2rdf, moteur QLever). Les objets (rues, bâtiments, lieux) sont décrits par leurs tags OSM (osmkey:amenity, osmkey:name…) et leur géométrie (geo:hasGeometry).
  • Requêtes spatiales : osm2rdf précalcule les relations ogc:sfContains, ogc:sfIntersects (préfixe ogc: <http://www.opengis.net/rdf#>), nommées d’après GeoSPARQL. Le préfixe GeoSPARQL standard (geo:sfContains) ne donne rien ici.
Exemple A — des hôpitaux (requête simple par tag) 
PREFIX osmkey: <https://www.openstreetmap.org/wiki/Key:>

SELECT ?hopital ?nom WHERE {
  ?hopital osmkey:amenity "hospital" ;
           osmkey:name ?nom .
}
LIMIT 20

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

Exemple B — les cafés de Lyon, sur une carte 
PREFIX osmkey: <https://www.openstreetmap.org/wiki/Key:>
PREFIX osmrel: <https://www.openstreetmap.org/relation/>
PREFIX ogc:    <http://www.opengis.net/rdf#>
PREFIX geo:    <http://www.opengis.net/ont/geosparql#>

SELECT ?cafe ?nom ?geometrie WHERE {
  osmrel:120965 ogc:sfContains ?cafe .
  ?cafe osmkey:amenity "cafe" ;
        osmkey:name ?nom .
  OPTIONAL { ?cafe geo:hasGeometry/geo:asWKT ?geometrie . }
}
LIMIT 30

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

La commune de Lyon est la relation OSM 120965. Vérifiez toujours un identifiant avant une requête spatiale (osmrel:120965 osmkey:name ?n doit renvoyer « Lyon »). Dans Yasgui, l’onglet Geo place la colonne ?geometrie sur une carte.

4. IMDb — films et séries (QLever)

  • Endpoint pour Yasgui : https://qlever.dev/api/imdb
  • Interface web : qlever.dev/imdb
  • Données IMDb pour un usage personnel et non commercial. Chaque titre a un imdb:type ("movie", "tvSeries", "tvEpisode"…), une note imdb:averageRating, un nombre de votes imdb:numVotes, une année imdb:startYear, des genres imdb:genre, des réalisateurs imdb:director ; les acteurs s’obtiennent avec l’IRI complète <https://www.imdb.com/principal/actor> (la barre oblique interdit la forme imdb:principal/actor).
Exemple — les films les mieux notés (au moins 500 000 votes) 
PREFIX imdb: <https://www.imdb.com/>

SELECT ?titre ?annee ?note ?votes WHERE {
  ?film imdb:type "movie" ;
        imdb:primaryTitle ?titre ;
        imdb:startYear ?annee ;
        imdb:averageRating ?note ;
        imdb:numVotes ?votes .
  FILTER(?votes >= 500000)
}
ORDER BY DESC(?note)
LIMIT 20

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

Sans le filtre imdb:type "movie", les séries (Breaking Bad, Game of Thrones…) arrivent en tête.

5. YAGO 4 (QLever)

  • Endpoint pour Yasgui : https://qlever.dev/api/yago-4
  • Interface web : qlever.dev/yago-4
  • Base de connaissances dérivée de Wikidata, mais avec un vocabulaire lisible (celui de schema.org : schema:birthPlace, schema:birthDate…) et des noms de ressources en clair (yago:Lyon). Le serveur officiel de YAGO ne répond plus : utilisez cette copie.
Exemple — des personnes nées à Lyon 
PREFIX yago: <http://yago-knowledge.org/resource/>
PREFIX schema: <http://schema.org/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?nom ?naissance WHERE {
  ?personne schema:birthPlace yago:Lyon ;
            schema:birthDate ?naissance ;
            rdfs:label ?nom .
  FILTER(lang(?nom) = "fr")
}
ORDER BY ?naissance
LIMIT 20

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

6. DBLP — publications en informatique

  • Endpoint pour Yasgui : https://sparql.dblp.org/sparql
  • Interface web : sparql.dblp.org · site : dblp.org
  • Base de référence en informatique : articles, conférences, thèses, auteurs. Données sous licence CC0.
Exemple — les universités qui délivrent le plus de thèses 
PREFIX dblp: <https://dblp.org/rdf/schema#>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?school (COUNT(DISTINCT ?thesis) AS ?count) WHERE {
  ?thesis rdf:type dblp:Book ;
          dblp:thesisAcceptedBySchool ?school .
}
GROUP BY ?school
ORDER BY DESC(?count)
LIMIT 20

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

Niveau 2 — autres bases testées

7. War Sampo — la Finlande dans la Seconde Guerre mondiale

  • Endpoint pour Yasgui : https://ldf.fi/warsa/sparql
  • Couvre la guerre d’Hiver (1939-1940), la guerre de Continuation (1941-1944) et la guerre de Laponie (1944-1945). N’ouvrez pas l’adresse de l’endpoint dans le navigateur : elle vous renvoie vers Yasgui en http://, que le navigateur bloque. Collez-la dans Yasgui ou utilisez le lien de l’exemple.
  • Les libellés des entités sont surtout en finnois, souvent doublés en anglais (FILTER(lang(?l) = "en")). Certaines valeurs restent du texte libre en finnois, comme les causes de décès de l’exemple : gardez un traducteur sous la main.
Exemple — causes de décès des prisonniers de guerre 
PREFIX prisoners: <http://ldf.fi/schema/warsa/prisoners/>

SELECT ?causeDeath (COUNT(?causeDeath) AS ?count)
WHERE {
  ?p prisoners:cause_of_death ?causeDeath;
}
GROUP BY ?causeDeath
ORDER BY DESC(?count)
LIMIT 50

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

8. Brevets européens (European Patent Office)

  • Endpoint pour Yasgui : https://data.epo.org/linked-data/query
  • Interface web : data.epo.org/linked-data/sparql-query · structure : documentation
  • Grosse base : les requêtes qui parcourent tout (tri sur toutes les demandes, comptage de toutes les classes) dépassent le délai. Partez d’un motif précis et gardez LIMIT.
Exemple — quelques demandes de brevet (ordre non garanti) 
PREFIX patent: <http://data.epo.org/linked-data/def/patent/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?application ?appNum ?filingDate ?authority {
  ?application rdf:type patent:Application ;
      patent:applicationNumber ?appNum ;
      patent:filingDate        ?filingDate ;
      patent:applicationAuthority ?authority.
} LIMIT 10

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

9. Bibliothèque nationale de France

  • Endpoint pour Yasgui : https://data.bnf.fr/sparql
  • Interface web : data.bnf.fr/sparql (pour Yasgui, l’endpoint s’écrit sans « / » final)
  • Métadonnées sous Licence Ouverte (citer « data.bnf.fr »).
Exemple — auteurs avec dates de naissance et de décès 
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX bio: <http://vocab.org/bio/0.1/>

SELECT ?auteur ?jour ?date1 ?date2 ?nom
WHERE {
  ?auteur foaf:birthday ?jour;
          bio:birth ?date1;
          bio:death ?date2.
  OPTIONAL { ?auteur foaf:name ?nom. }
  FILTER(regex(?jour, "^[0-9]{2}-[0-9]{2}$"))
}
ORDER BY (?jour)
LIMIT 100

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

Le FILTER écarte les dates incomplètes (« 18.. », « -1-8. ») : les données réelles sont rarement propres, c’est à vous de les filtrer.

10. Muziekweb — musique (Pays-Bas)

  • Endpoint pour Yasgui : https://api.data.muziekweb.nl/datasets/MuziekwebOrganization/Muziekweb/services/Muziekweb/sparql
  • Interface web : data.muziekweb.nl
  • Base musicale néerlandaise : artistes, albums, enregistrements.
Exemple 1 — une liste d'artistes 
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX vocab: <https://data.muziekweb.nl/vocab/>

SELECT *
WHERE {
  ?artist a vocab:Performer;
          rdfs:label ?artistlabel.
}
LIMIT 10

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

Exemple 2 — les propriétés disponibles pour un artiste 
PREFIX vocab: <https://data.muziekweb.nl/vocab/>

SELECT DISTINCT ?prop
WHERE {
  ?artist a vocab:Performer;
          ?prop ?val.
}

▶ Ouvrir dans Yasgui — l’onglet s’ouvre déjà réglé ; cliquez sur ▶.

Pour aller plus loin

  • LOD Cloud — un répertoire de bases Linked Open Data (1 360 dans le diagramme de juin 2026) ; beaucoup ne répondent plus : voir « Une autre base ? » ci-dessus.