Service de requête Wikidata/Manuel utilisateur

Suivi des problèmes : #WDQS
From mediawiki.org
This page is a translated version of the page Wikidata Query Service/User Manual and the translation is 100% complete.
Languages:
Tutoriel de 15 minutes sur le Service des requêtes Wikidata

WDQS, le service de requêtes Wikidata, est un progiciel et un service publiquement accessible conçus pour fournir un point d'accès SPARQL vous permettant d'interroger le jeu de données Wikidata.

Cette page et d'autres pages de documentation pertinentes seront mises à jour en conséquence ; il est recommandé de les suivre si vous utilisez ce service.

Vous pouvez consulter des exemples de requêtes SPARQL sur la page d'exemples SPARQL.

Jeu de données

Le service de requête Wikidata fonctionne sur un jeu de données de Wikidata.org, représenté en RDF comme décrit dans la documentation du format d'export RDF.

Le jeu de données du service ne correspond pas exactement au jeu de données produit par les exports RDF, principalement pour des raisons de performances ; la documentation décrit un petit nombre de ces différences.

Vous pouvez télécharger un export hebdomadaire des mêmes données à l'adresse :

https://dumps.wikimedia.org/wikidatawiki/entities/

Notions de base - Comprendre le triplet sémantique SPO : sujet, prédicat, objet

SPO pour « subject, predicate, object » est connu comme un triplet, ou communément appelé dans Wikidata, une déclaration sur les données.

La déclaration "La capitale des États-Unis est Washington DC" se compose du sujet "États-Unis" (Q30), du prédicat "La capitale est" (P36) , et d'un objet "Washington DC" (Q61). Cette déclaration peut être représentée par trois URIs: 

<http://www.wikidata.org/entity/Q30>  <http://www.wikidata.org/prop/direct/P36>  <http://www.wikidata.org/entity/Q61> .

Grâce aux préfixes (voir ci-dessous), la même déclaration peut être écrite sous une forme plus concise. Notez le point à la fin pour représenter la fin de la déclaration. 

wd:Q30  wdt:P36  wd:Q61 .

Le /entity/ (wd:) représente l'entité Wikidata (valeurs de l'identifiant-Q). Le /prop/direct/ (wdt:) est une propriété véridique, c'est-à-dire une valeur à laquelle on s'attend le plus souvent en regardant la déclaration. Les propriétés véridiques sont nécessaires parce que certaines déclarations pourraient être « plus-vraies » que d'autres. Par exemple, la déclaration « La capitale des États-Unis est New York » est vraie - mais seulement dans le contexte historique de l'année 1790. WDQS utilise des rangs pour déterminer quelles déclarations doivent être utilisées comme véridiques.

En plus des déclarations véridiques, WDQS stocke toutes les déclarations (véridiques et non véridiques), mais n'utilise pas le même préfixe wdt:. U.S. capital a trois valeurs: DC, Philadelphie et New York. Et chacune de ces valeurs a des "qualificatifs" - c'est à dire des informations supplémentaires, telles que les dates de début et de fin, qui affinent l'étendue de chaque déclaration. Pour stocker cette information dans la base de données RDF (triplestore), WDQS introduit un sujet "déclaration" auto-magique, qui est essentiellement un nombre aléatoire : 

wd:Q30  p:P36  <random_URI_1> .         # US "indirect capital" is <X>
<random_URI_1>  ps:P36  wd:Q61 .        # The X's "real capital value" is  Washington DC
<random_URI_1>  pq:P580  "1800-11-17" . # The X's start date is 1800-11-17

Voir Tutoriel SPARQL - qualificateurs pour plus d'informations.

Sujet, prédicat, objet (spo) est également utilisé comme une forme de structure syntaxique de base pour interroger les structures de données RDF ou toute base de données graphique ou de base de triplets (triplestore), comme le WDQS (Wikidata Query Service), géré par Blazegraph, une base de données graphique haute performance.

Utilisations avancées des triplets SPO pouvant inclure d'autres triplets comme objets, ou être les sujets d'autres triplets !

Notions de base - Comprendre les préfixes

Les sujets et les prédicats (première et seconde valeurs du triplet) doivent toujours être stockés sous la forme URI. Par exemple, si le sujet est Universe (Q1), il sera stocké sous <https://www.wikidata.org/wiki/Q1>. Les préfixes nous permettent d'écrire ce long URI sous une forme plus courte: wd:Q1. Contrairement aux sujets et aux prédicats, l'objet (la troisième valeur du triplet) peut être un URI ou un littéral, par exemple un nombre ou une chaîne.

WDQS comprend de nombreuses abréviations de raccourcis, connues sous le nom de préfixes. Certains sont internes à Wikidata, par ex. wd, wdt, p, ps, bd, et beaucoup d'autres sont des préfixes externes couramment utilisés, comme rdf, skos, owl, schema.

Dans la requête suivante, nous demandons des éléments où il y a une déclaration de "P279 = Q7725634" ou en termes plus complets, en sélectionnant les sujets qui ont un prédicat de "sous-classe de" avec un objet de = "travail littéraire".

Les variables sorties : 

PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wds: <http://www.wikidata.org/entity/statement/>
PREFIX wdv: <http://www.wikidata.org/value/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX p: <http://www.wikidata.org/prop/>
PREFIX ps: <http://www.wikidata.org/prop/statement/>
PREFIX pq: <http://www.wikidata.org/prop/qualifier/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX bd: <http://www.bigdata.com/rdf#>

# The below SELECT query does the following:
# Selects all the items(?s subjects) and their labels(?label)
# that have(WHERE) the statement(?s subject) has a direct property(wdt:) = P279 <subclasses of>
# with a value of entity(wd:) = Q7725634 <Literary Work>
# and optionally return the English labels

SELECT ?s ?label WHERE {
  ?s wdt:P279 wd:Q7725634 .
  OPTIONAL {
     ?s rdfs:label ?label filter (lang(?label) = "en").
   }
 }

Les extensions

Le service prend en charge les extensions suivantes aux fonctionnalités SPARQL standards :

Service d'étiquette

Vous pouvez récupérer l'étiquette, l'alias ou la description des entités que vous interrogez, avec la langue de repli, en utilisant le service spécialisé avec l'URI <http://wikiba.se/ontology#label>. Ce service est très utile lorsque vous souhaitez récupérer des étiquettes, car il réduit la complexité des requêtes SPARQL dont vous auriez autrement besoin pour obtenir le même résultat.

Le service peut être utilisé dans l'un des deux modes: manuel ou automatique.

En mode automatique, il vous suffit de spécifier le modèle de service, par exemple: 

PREFIX wikibase: <http://wikiba.se/ontology#>
SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en" .
}

et WDQS va automatiquement générer les libellés comme suit:

  • Si une variable non positionnée dans SELECT est nommée ?NAMELabel, WDQS produit le libellé (rdfs:label) pour l'entité de la variable ?NAME.
  • Si une variable non positionnée dans SELECT est nommée ?NAMEAltLabel, WDQS produit l'alias (skos:altLabel) pour l'entité de la variable ?NAME.
  • Si une variable non positionnée dans SELECT est nommée ?NAMEDescription, WDQS produit la description (schema:description) pour l'entité de la variable ?NAME.

Dans chaque cas, la variable de ?NAME doit être positionnée, sinon le service échoue.

Le mode automatique ne fait qu'inspecter la projection de la requête – par exemple, dans SELECT ?aLabel (GROUP_CONCAT(?bLabel) AS ?bLabels), seule la première étiquette est reconnue et dans ce mode, SELECT * n'est pas pris en charge du tout. Dans ces cas, vous devrez utiliser le mode manuel (voir ci-après).

Vous spécifiez votre/vos langue(s) préférée(s) pour l'étiquetage avec un ou plusieurs triplets de bd:serviceParam wikibase:language "language-code". Chaque chaîne peut contenir un ou plusieurs codes de langue, séparés par des virgules. WDQS envisage les langues dans l'ordre où vous les avez spécifiées. S'il n'existe pas de libellé dans aucune des langues mentionnées, l'identifiant-Q de l'entité (sans aucun préfixe) est utilisé pour le libellé.

Le site web du service de requête remplace auto-magiquement [AUTO_LANGUAGE] par le code de langue actuel de l'interface utilisateur. Par exemple, si l'interface utilisateur est en français, le code SPARQL bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" sera converti en bd:serviceParam wikibase:language "fr,en" avant d'être envoyé au service de requête.

Exemple, montrant la liste des présidents des États-Unis avec leurs épouses : 

SELECT ?p ?pLabel ?w ?wLabel WHERE {
   wd:Q30 p:P6/ps:P6 ?p .
   ?p wdt:P26 ?w .
   SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en" .
   }
 }

Essayez !

Dans cet exemple WDQS crée automatiquement les libellés ?pLabel et ?wLabel pour les propriétés.

En mode manuel, vous associez explicitement les variables des libellés à l'intérieur du code appelant le service, mais WDQS fournit encore la résolution de la langue ainsi que la langue de repli. Exemple : 

  SELECT *
   WHERE {
     SERVICE wikibase:label {
       bd:serviceParam wikibase:language "fr,de,en" .
       wd:Q123 rdfs:label ?q123Label .
       wd:Q123 skos:altLabel ?q123Alt .
       wd:Q123 schema:description ?q123Desc .
       wd:Q321 rdf:label ?q321Label .
    }
  }

Cette syntaxe entrainera la recherche des libellés et descriptions en français, en allemand et en anglais, puis si rien ne convient l'identifiant Q sera utilisé en guise de libellé.

Recherche géospatiale

Le service permet de rechercher des éléments avec des coordonnées situées dans un certain rayon à partir d'un centre et à l'intérieur d'un rectangle défini.

Recherche autour d'un point

Exemple: 

# Airports within 100km from Berlin
#defaultView:Map
SELECT ?place ?placeLabel ?location ?dist WHERE {
  # Berlin coordinates
  wd:Q64 wdt:P625 ?berlinLoc . 
  SERVICE wikibase:around { 
      ?place wdt:P625 ?location . 
      bd:serviceParam wikibase:center ?berlinLoc . 
      bd:serviceParam wikibase:radius "100" . 
      bd:serviceParam wikibase:distance ?dist.
  } 
  # Is an airport
  FILTER EXISTS { ?place wdt:P31/wdt:P279* wd:Q1248784 }
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en" . 
  }
} ORDER BY ASC(?dist)

Essayez !

La première ligne de l'appel du service around doit avoir le format ?item predicate ?location, où le résultat de recherche liera ?item aux éléments avec les endroits spécifiés et ?location à leur coordonnées. Les paramètres supportés sont :

Prédire Signification
wikibase:center Le point autour duquel la recherche est réalisée. Doit être borné pour que la recherche se fasse.
wikibase:radius La distance depuis le milieu. Actuellement la distance est toujours en kilomètres, les autres unités ne sont pas supportées pour le moment.
wikibase:globe Le globe sur lequel est faite la recherche. Optionnel, par défault est Terre (wd:Q2).
wikibase:distance Variable recevant l'information de distance.

Recherche à l'intérieur d'une région rectangulaire

Exemple de recherche dans une boîte géographique : 

# Schools between San Jose, CA and Sacramento, CA
#defaultView:Map
SELECT * WHERE {
  wd:Q16553 wdt:P625 ?SJloc .
  wd:Q18013 wdt:P625 ?SCloc .
  SERVICE wikibase:box {
      ?place wdt:P625 ?location .
      bd:serviceParam wikibase:cornerSouthWest ?SJloc .
      bd:serviceParam wikibase:cornerNorthEast ?SCloc .
  }
  FILTER EXISTS { ?place wdt:P31/wdt:P279* wd:Q3914 }
}

Essayez !

ou : 

#Schools between San Jose, CA and San Francisco, CA
#defaultView:Map
SELECT ?place ?location WHERE {
  wd:Q62 wdt:P625 ?SFloc .
  wd:Q16553 wdt:P625 ?SJloc .
  SERVICE wikibase:box {
    ?place wdt:P625 ?location .
    bd:serviceParam wikibase:cornerWest ?SFloc .
    bd:serviceParam wikibase:cornerEast ?SJloc .
  }
  FILTER EXISTS { ?place wdt:P31/wdt:P279* wd:Q3914 }
}

Essayez !

Les coordonnées peuvent être spécifiées directement : 

# Schools between San Jose, CA and Sacramento, CA
#same as previous
#defaultView:Map
SELECT * WHERE {
SERVICE wikibase:box {
    ?place wdt:P625 ?location .
    bd:serviceParam wikibase:cornerWest "Point(-121.872777777 37.304166666)"^^geo:wktLiteral .
    bd:serviceParam wikibase:cornerEast "Point(-121.486111111 38.575277777)"^^geo:wktLiteral .
  }
  FILTER EXISTS { ?place wdt:P31/wdt:P279* wd:Q3914 }
}

Essayez !

La première ligne de l'appel au service box doit avoir le format ?item predicate ?location, et le résultat de la recherche va affecter ?item aux éléments à l'intérieur de la zone spécifiée et ?location à leurs coordonnées. Les paramètres possibles sont :

Prédicat Définition
wikibase:cornerSouthWest Le coin sud-ouest de la boîte.
wikibase:cornerNorthEast Le coin nord-ouest de la boîte.
wikibase:cornerWest Le bord ouest de la boîte.
wikibase:cornerEast Le bord est de la boîte.
wikibase:globe Le globe sur lequel se fait la recherche. Optionnel, par défaut La Terre (wd:Q2)

wikibase:cornerSouthWest et wikibase:cornerNorthEast doivent être spécifiés ensemble, ainsi que wikibase:cornerWest et wikibase:cornerEast, et ne peuvent pas être mélangés. Si les prédicats wikibase:cornerWest et wikibase:cornerEast sont utilisés, les points sont supposés être les coordonnées de la diagonale de la boîte, les coins sont déduits en conséquence.

Fonctions étendues

Fonction de distance

La fonction geof:distance retourne la distance entre deux points sur la terre, en kilomètres. Exemple d'utilisation : 

# Airports within 100km from Berlin
SELECT ?place ?placeLabel ?location ?dist WHERE {

  # Berlin coordinates
  wd:Q64 wdt:P625 ?berlinLoc . 
  SERVICE wikibase:around { 
      ?place wdt:P625 ?location . 
      bd:serviceParam wikibase:center ?berlinLoc . 
      bd:serviceParam wikibase:radius "100" . 
  } 
  # Is an airport
  ?place wdt:P31/wdt:P279* wd:Q1248784 .
  SERVICE wikibase:label {
    bd:serviceParam wikibase:language "en" . 
  }
  BIND(geof:distance(?berlinLoc, ?location) as ?dist) 
} ORDER BY ?dist

Essayez ! 

# Places around 0°,0° 
SELECT *
{
  SERVICE wikibase:around { 
      ?place wdt:P625 ?location . 
      bd:serviceParam wikibase:center "Point(0 0)"^^geo:wktLiteral .
      bd:serviceParam wikibase:radius "250" . 
  } 
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" . ?place rdfs:label ?placeLabel }
  BIND(geof:distance("Point(0 0)"^^geo:wktLiteral, ?location) as ?dist) 
} 
ORDER BY ?dist

Essayez !

Fonctions éléments de coordonnées

Les fonctions geof:globe, geof:latitude et geof:longitude retournent des parties de coordonnées : respectivement l'URI du globe, la latitude et la longitude.

Fonctions de décodage d'URLs

Le fonction wikibase:decodeUri décodes une chaîne URI donnée (c'est à dire inverse l'encodage des pourcents). Cela peut être nécessaire lorsque vous convertissez des titres Wikipedia (qui sont encodés), vers des chaînes actuelles. Cette fonction est l'opposée de la fonction SPARQL encode_for_uri. 

# Example usage of wikibase:decodeUri function
SELECT DISTINCT * WHERE {
  ?el wdt:P31 wd:Q5.
  ?webRaw schema:about ?el;
    schema:inLanguage "ru";
    schema:isPartOf <https://ru.wikipedia.org/>.
  BIND(URI(wikibase:decodeUri(STR(?webRaw))) AS ?webHyperlink) .
  BIND(wikibase:decodeUri(STR(?webRaw)) AS ?webString) .
}
LIMIT 20

Préfixes automatiques

La plupart des préfixes utilisés dans les requêtes usuelles sont pris en charge par le moteur sans avoir besoin de les spécifier explicitement.

Dates étendues

Le service prend en charge les valeurs de dates du type xsd:dateTime dans un intervalle d'environ 290 billions d'années dans le passé et dans le futur, avec une résolution d'une seconde. WDQS enregistre les dates sous forme de nombres de secondes à 64 bits depuis l'époque Unix.

Extensions Blazegraph

Avertissement Avertissement : As Blazegraph is not actively developed, it is planned to migrate Wikidata Query Service to another triplestore. The following may be discontinued at some point.

La plateforme Blazegraph sur laquelle WDQS est implémenté possède son propre ensemble d'extensions SPARQL. Parmi elles, plusieurs algorithmes de graphes transverses sont documentés sur le wiki Blazegraph, comprenant BFS, le plus court chemin, ainsi que les implémentations de CC et de PageRank.

Consultez également la documentation sur les requêtes de Blazegraph pour les informations concernant la manière de contrôler l'exécution des requêtes et les différents aspects du moteur.

Il n'y a pas de documentation dans le wiki BlazeGraph à propos de l'extension bd:sample. Elle n'est documentée que dans un commentaire du code.

Fédération

Nous permettons que les requêtes fédérées SPARQL appellent un nombre choisi de bases de données externes. Voir la liste complète des points d'accès fédérés sur la page dédiée.

Exemple de requête fédérée : 


SELECT ?workLabel WHERE {
  wd:Q165257 wdt:P2799 ?id 
  BIND(uri(concat("https://data.cervantesvirtual.com/person/", ?id)) as ?bvmcID) 
  SERVICE <http://data.cervantesvirtual.com/openrdf-sesame/repositories/data> {
    ?bvmcID <http://rdaregistry.info/Elements/a/otherPFCManifestationOf> ?work .
    ?work rdfs:label ?workLabel        
  }
}

Essayez !

Veuillez noter que les bases de données servies par les points d'accès fédérés, utilisent des ontologies qui peuvent être très différentes de celles de Wikidata. Voir les liens vers la documentation du propriétaire pour en connaître plus sur les ontologies et l'accès aux données de ces bases.

API MediaWiki

Veuillez lire la description complète sur la page de documentation de l'API Service de MediaWiki.

L'API Service de MediaWiki autorise d'appeler l'API MediaWiki à partir de SPARQL, et de recevoir les résultats de l'intérieur de la reqête de SPARQL. Exemple (pour trouver les membres d'une catégorie) : 


SELECT * WHERE {
  wd:Q6501349 wdt:P910 ?category .
  ?link schema:about ?category; schema:isPartOf <https://en.wikipedia.org/>; schema:name ?title .
  SERVICE wikibase:mwapi {
	 bd:serviceParam wikibase:api "Generator" .
     bd:serviceParam wikibase:endpoint "en.wikipedia.org" .
     bd:serviceParam mwapi:gcmtitle ?title .
     bd:serviceParam mwapi:generator "categorymembers" .
     bd:serviceParam mwapi:gcmprop "ids|title|type" .
     bd:serviceParam mwapi:gcmlimit "max" .
    # out
    ?subcat wikibase:apiOutput mwapi:title  .
    ?ns wikibase:apiOutput "@ns" .
    ?item wikibase:apiOutputItem mwapi:item .
  }
}

Essayez !

Service Wikimedia

Wikimedia exécute l'instance de service public de WDQS, qui est disponible pour utilisation sur http://query.wikidata.org/.

Le temps d'exécution de la requête sur le point d'accès public est limité à 60 secondes. C'est vrai à la fois pour l'IHM et pour le point d'accès SPARQL public.

Interface graphique (IHM)

L’interface de la page d’accueil du service de requêtes http://query.wikidata.org/ vous permet de créer et de soumettre des requêtes SPARQL au moteur de requête. Les résultats sont affichés par défaut sous forme de tableau HTML. Notez que chaque requête dispose d’une URL unique qui peut-être ajoutée à vos marque-pages ou sauvegardée pour une réutilisation future. Aller à cette URL va afficher la requête dans la fenêtre d’édition, mais ne la lancera pas - vous devrez cliquer sur « Lancer la requête » pour cela.

Il est également possible d’obtenir une URL courte pour cette requête via un raccourcisseur d’URL en cliquant sur le lien « Générer une URL courte » à droite — cela produira une URL raccourcie pour la requête actuelle.

Le bouton Ajoutez les préfixes génère une entête contenant les préfixes de requête SPARQL standards. La liste complète des préfixes utilisables est listée dans la documentation du format RDF. Notez que les préfixes les plus courants n’ont pas besoin d’être précisés dans la requête, car WDQS les ajoute automatiquement lui-même.

L’interface fournit également un explorateur simple d’entités dans les résultats, qui peut être activé en cliquant sur le symbole « 🔍 » situé à côté du résultat de l’entité. Cliquer directement sur le numéro-Q de l’entité vous amènera sur la page de l'entité de wikidata.org .

Visualisations par défaut

Article principal: Visionner les résultats (sur Wikidata)

Si vous lancez la requête dans l’interface WDQS, vous pouvez choisir un type de visualisation pour vos résultats en ajoutant un commentaire #defaultView:nomDeLaVue au début de la requête.

Afficher un titre

Si vous exécutez la requête dans l'interface utilisateur WDQS, vous pourrez afficher un titre précédant les résultats en plaçant un commentaire : #title: texte à afficher au début de la requête.

Point d'accès SPARQL

Les requêtes SPARQL peuvent être soumises directement au point d'accès SPARQL avec par l'intermédiaire de GET ou de POST à https://query.wikidata.org/sparql.

Les requêtes GET comportent l'action spécifiée dans l'URL même, dans le format https://query.wikidata.org/sparql?query=(SPARQL_query), par exemple https://query.wikidata.org/sparql?query=SELECT%20?dob%20WHERE%20{wd:Q42%20wdt:P569%20?dob.}.

Les requêtes POST peuvent alternativement accepter la commande à l'intérieur de la requête, au lieu de l'URL, ce qui permet d'exécuter des commandes plus longues sans être limité par la longueur maximale de l'URL. (Notez que le corps du POST doit encore inclure le préfixe query= (c'est à dire, qu'il doit être query=(SPARQL_query) plutôt que simplement (SPARQL query)), et la commande SPARQL doit encore être échappée dans l'URL.)

Le résultat est retourné au format XML par défaut, ou alors en JSON dans le cas où soit le paramètre format=json est présent dans l’url, soit quand l’entête Accept: application/sparql-results+json est fournie avec la requête HTTP.

Le format JSON est standard SPARQL 1.1 Query Results JSON Format.

Il est recommandé d'utiliser GET pour les petites requêtes et POST pour les plus longues, parce que les requêtes POST ne sont pas mises dans le cache.

Formats supportés

Les formats de sortie suivants sont pris en charge à l’heure actuelle par le point d’accès SPARQL :

Format Entête HTTP Paramère du Query Description
XML Accept: application/sparql-results+xml format=xml Format XML du résultat, retourné par défaut. Conformément à la spécification https://www.w3.org/TR/rdf-sparql-XMLres/
JSON Accept: application/sparql-results+json format=json Format JSON du résultat, spécifié à l’adresse https://www.w3.org/TR/sparql11-results-json/
TSV Accept: text/tab-separated-values Comme spécifié dans https://www.w3.org/TR/sparql11-results-csv-tsv/
CSV Accept: text/csv Comme spécifié dans https://www.w3.org/TR/sparql11-results-csv-tsv/
Binaire RDF Accept: application/x-binary-rdf-results-table

Limites des requêtes

Il existe une limite maximale codée en dur pour le temps d’exécution d'une requête et configurée à 60 secondes. Les limites suivantes s'appliquent aussi :

  • Un client (agent utilisateur + IP) est autorisé à avoir 60 secondes de temps de traitement toutes les 60 secondes
  • Un client a droit à 30 requêtes en erreur par minute

Les clients qui dépassent les limites ci-dessus sont restreints avec le code retour HTTP 429. Utilisez l'en-têteRetry-After pour voir quand la requête peut être répétée. Si le client ignore les erreurs 429 et continue de produire des demandes au-delà des limites, il peut être temporairement banni du service. Les clients qui ne respectent pas la politique User-Agent pourraient être complètement bloqués - assurez-vous d'envoyer un bon en-tête User-Agent.

Toute requête va échouer si le temps nécessaire à son exécution dépasse cette limite configurée. Vous pouvez optimiser la requête ou rapporter une commande qui pose problème, ici.

Notez aussi que l'accès actuel au service est limité à 5 requêtes simultanées par IP. Les limites ci-dessus sont sensées changer en fonction des ressources et des modèles d'utilisation.

Explication du Query

Blazegraph permet d'afficher l'analyse de la commande qui explique comment la requête a été analysée syntaxiquement et quelles optimisations lui ont été appliquées. Pour voir cette information, ajoutez le paramètre explain=details à la chaîne de la requête, par exemple : https://query.wikidata.org/sparql?query=SELECT%20?dob%20WHERE%20{wd:Q42%20wdt:P569%20?dob.}&explain=details

Les espaces de noms

Les données du service de requêtes Wikidata contiennent l'espace de noms principal, wdq, vers lequel sont dirigées les requêtes à destination du point d'accès SPARQL principal, et d'autres espaces de noms auxiliaires listés ci-dessous. Pour interroger les données d'un espace de noms différent, utilisez l'URL du point d'accès https://query.wikidata.org/bigdata/namespace/NAMESPACENAME/sparql.

Les catégories 

Voir la description complète sur la page de documentation des catégories.

Le service de requête Wikidata fournit également l'accès au graphe des catégories des wikis sélectionnés. La liste des wikis couverts peut être consultée ici : https://noc.wikimedia.org/conf/dblists/categories-rdf.dblist

L'espace de noms des catégories est categories. Le point d'accès SPARQL pour y accéder est https://query.wikidata.org/bigdata/namespace/categories/sparql .

Veuillez consulter la page des catégories pour les informations détaillées.

DCAT-AP

Les données DCAT-AP pour Wikidata sont disponibles comme SPARQL sur le point d'entrée https://query.wikidata.org/bigdata/namespace/dcatap/sparql.

La source des données est: https://dumps.wikimedia.org/wikidatawiki/entities/dcatap.rdf

Exemple de requête pour récupérer des données : 

PREFIX dcat: <http://www.w3.org/ns/dcat#>
PREFIX dct: <http://purl.org/dc/terms/>

SELECT ?url ?date ?size WHERE {
  <https://www.wikidata.org/about#catalog> dcat:dataset ?dump .
  ?dump dcat:distribution [
    dct:format "application/json" ;
    dcat:downloadURL ?url ;
    dct:issued ?date ;
    dcat:byteSize ?size 
  ] .
}

Point d'accès Linked Data Fragments

Nous permettons aussi les requête à la base en utilisant une interface « Triple Pattern Fragments ». Cela permet de naviguer efficacement et économiquement dans des triplets de données lorsque qu’au moins un des composants du triplet est connu à l’avance et que vous devez récupérer tous les triplets qui correspondent à ce schéma. Plus d’information sur le site « Linked Data Fragments ».

L'interface peut être accédée par l'URL: https://query.wikidata.org/bigdata/ldf. Ce service est implémenté par dessus la base de données Blazegraph, il aura donc la même latence que le service de requête. Exemple de requêtes : 

$ curl \
  --get \
  -H 'Accept: application/rdf+xml' \
  --data-urlencode 'predicate=http://www.wikidata.org/prop/direct/P212' \
  --data-urlencode 'object="978-0-262-03293-3"' \
  'https://query.wikidata.org/bigdata/ldf'

Notez que seulement les URLs complètes sont actuellement prises en charge pour les paramètres subject, predicate et object .

Par défaut, l'interface HTML est affichée, néanmoins plusieurs formats de données sont disponibles, définis par l'entête HTTP Accept .

Formats de données disponibles
Accept Format
text/html Interface d'affichage HTML par défaut
text/turtle Format Turtle
application/ld+json Format JSON-LD
application/n-triples Format N-Triples
application/rdf+xml Format RDF/XML

Les données sont retournées par pages de 100 triplets. Les pages sont numérotées en commençant à 1, et le numéro de page est défini par le paramètre page .

Service autonome externe

Comme le service est du logiciel libre, il est également possible d'exécuter ce service sur n'importe quel serveur de l'utilisateur en utilisant les instructions fournies ci-dessous.

Les recommendations concernant le matériel peuvent être trouvées dans la documentation Blazegraph.

Si vous envisagez d'exécuter le service sur une instance Wikibase non-Wikidata, veuillez voir les instructions suivantes.

Installation

Pour installer le service, il est recommandé de télécharger le paquet du service complet en un fichier ZIP, par exemple de Maven Central, avec l'ID de groupe org.wikidata.query.rdf et l'ID d'artifact « service » , ou de copier la distribution des sources de https://github.com/wikimedia/wikidata-query-rdf/ et de la compiler avec « mvn package ». Le paquet ZIP sera dans le répertoire dist/target sous service-VERSION-dist.zip .

Le paquet contient le serveur Blazegraph en tant qu'application .war, avec les bibliothèques nécessaires à l'exécution du service de mise à jour pour récupérer les données récentes du site wikidata, ainsi que les scripts pour faciliter différentes tâches, et l'interface utilisateur dans le sous-répertoire gui . Si vous voulez utiliser l'IHM, vous devrez configurer votre serveur HTTP pour la mettre en ligne.

Par défaut, uniquement le point d'accès SPARQL sur http://localhost:9999/bigdata/namespace/wdq/sparql est configuré, et l'IHM par défaut de Blazegraph est disponible sur http://localhost:9999/bigdata/. Notez que dans la configuration par défaut, les deux sont accessibles uniquement à partir de localhost. Vous devrez fournir des points d'accès externes et un contrôle d'accès approprié si vous avez l'intention d'y accéder de l'extérieur.

Utiliser des versions instantanées

Si vous voulez installer une version encore en cours de développement (ce qui est habituellement nécessaire si la version diffusée contient des bogues corrigés dans la nouvelle version qui n'est pas encore disponible) et si vous ne voulez pas compiler vos propres binaires, vous pouvez utiliser soit :

Chargement des données

Avertissement Avertissement : À partir de 2020, sur les serveurs Wikimedia, il faudra environ 12 jours pour importer toutes les données du vidage, et encore 12 jours pour que le service de requête rattrape le retard.

La suite de la procédure d'installation est décrite en détails dans le document Getting Started qui fait partie de la distribution, et qui implique les étapes suivantes :

  1. Téléchargez la dernière sauvegarde RDF de https://dumps.wikimedia.org/wikidatawiki/entities/ (elle se termine par .ttl.gz).
  2. Prétraitez les données avec le script munge.sh script. Ceci crée un ensemble de fichiers TTL contenant les données prétraitées, avec des noms comme wikidump-000000001.ttl.gz, etc. Voir les options pour le script ci-dessous.
  3. Activez le service Blazegraph en exécutant le script runBlazegraph.sh .
  4. Chargez les données dans le service en utilisant loadData.sh. Notez que le fait de charger les données est habituellement légèrement plus lent que le prétraitement, donc vous pouvez commencer à charger dès que les premiers fichiers prétraités sont prêts. Le chargement peut être redémarré à partir de n'importe quel fichier en utilisant les options décrites ci-dessous.
  5. Après avoir chargé toutes les données, activez le service Updater en utilisant runUpdate.sh.

Chargement des catégories 

Si vous voulez aussi charger les données des catégories, veuillez suivre les étapes suivantes :

  1. Créez un espace de noms, par exemple : categories: createNamespace.sh categories
  2. Chargez-y des données : forAllCategoryWikis.sh loadCategoryDump.sh categories

Notez que ces scripts ne chargent que les données des wikis Wikimedia en fonction de la configuration de Wikimedia. Si vous devez travailler avec d'autres wikis, vous pouvez modifier certaines variables à l'intérieur des scripts.

Scripts

Les scripts utiles suivants font partie de la distribution :

munge.sh

Pré-traiter les données de sauvegarde RDF pour le chargement.

Option Nécessaire ? Explication
-f filename obligatoire Nom de fichier de sauvegarde RDF
-d directory optionnel Répertoire où les fichiers traités seront écrits, par défaut le répertoire courant
-l language optionnel Si spécifié, seules les étiquettes pour les langues données seront retenues. Utilisez cette option si vous n'utilisez qu'un seule langue, car cela peut améliorer les performances, réduire la taille de la base de données et simplifier les requêtes.
-s optionnel Si spécifié, les données concernant les liens de site, sont exclues. Utilisez cette option si vous n'avez pas besoin d'interroger les liens de site, car cela peut améliorer les performances et réduire la taille de la base de données.
-c size optionnel Utilisez cette option pour remplacer la taille de bloc par défaut. Des blocs trop gros peuvent expirer durant l'importation.

Exemple :

./munge.sh -c 50000 -f data/wikidata-20150427-all-BETA.ttl.gz -d data -l en -s

loadData.sh

Charger dans Blazegraph les données traitées. Nécessite d'avoir installé curl .

Option Nécessaire ? Explication
-n namespace obligatoire Spécifie l'espace de noms des graphes dans lequel les données sont chargées, doit être wdq pour les données WDQS.
-d directory optionnel Répertoire dans lequel les fichiers traités sont enregistrés ; par défaut, c'est le répertoire actuel
-h host optionnel Nom de l'hôte du point d'accès SPARQL, par défaut localhost
-c context optionnel L'URL de contexte du point d'accès SPARQL, par défaut bigdata - ne doit habituellement pas être changée pour WDQS
-s start optionnel Nombre avec lequel commencer la numérotation du fichier traité, par défaut 1
-e end optionnel Nombre auquel terminer la numérotation du fichier traité

Exemple:

./loadData.sh -n wdq -d `pwd`/data

runBlazegraph.sh

Activez le service Blazegraph.

Option Nécessaire ? Explication
-d directory optionnel Répertoire d'accueil de l'installation Blazegraph, par défaut le répertoire où le script se trouve
-c context optionnel L'URL de contexte du point d'accès SPARQL, par défaut bigdata - ne doit habituellement pas être changée pour WDQS
-p port optionnel Numéro de port du service SPARQL, par défaut 9999
-o options optionnel Ajoute des options à la ligne de commande

Exemple:

./runBlazegraph.sh

Dans le script, il y a deux variables que l'on peut vouloir modifier : 

# Q-id of the default globe
DEFAULT_GLOBE=2
# Blazegraph HTTP User Agent for federation
USER_AGENT="Wikidata Query Service; https://query.wikidata.org/";

Egalement, les variables d'environnement suivantes sont contrôlées par le script (toutes sont optionnelles) :

Variable Défaut Explication
HOST localhost Nom de l'hôte pour lier le service Blazegraph
PORT 9999 Port pour lier le service Blazegraph
DIR repertoire dans lequel se trouve le script Répertoire dans lequel sont enregistrés les fichiers de configuration
HEAP_SIZE 16g Taille de la pile Java pour Blazegraph
MEMORY -Xms${HEAP_SIZE} -Xmx${HEAP_SIZE} Paramètres complets Java de configuration mémoire pour Blazegraph
GC_LOGS voir la source Paramètres des jounaux GC
CONFIG_FILE RWStore.properties Eplacement du fichier de configuration Blazegraph
BLAZEGRAPH_OPTS vide Options additionnelles, passées telles quelles sur la ligne de commande Java

runUpdate.sh

Exécuter le service Updater.

Option Nécessaire ? Explication
-n namespace optionnel Spécifie l'espace de noms des graphes dans lequel les données sont chargées, doit être wdq pour les données WDQS. Valeur par défaut: wdq
-h host optionnel Nom de l'hôte du point d'accès SPARQL, par défaut localhost
-c context optionnel L'URL de contexte du point d'accès SPARQL, par défaut bigdata - ne doit habituellement pas être changée pour WDQS
-l language optionnel Si spécifié, seulement les étiquettes pour la langue donnée seront retenues. Utilisez cette option si vous n'utilisez qu'une langue, car cela peut améliorer les performances, réduire la taille de la base de données et simplifier les requêtes.
-s optionnel Si spécifié, les données concernant les liens de site, sont exclues. Utilisez cette option si vous n'avez pas besoin d'interroger les liens de site, car cela peut améliorer les performances et réduire la taille de la base de données.
-t secs optionnel Délai maximal d'attente pour les communications avec Blazegraph, en secondes.
-N optionnel Cette option force le script à ignorer les options qui peuvent causer problèmes lors de l'exécution d'un second Updater alors que le premier est encore en cours. Utilisez-la lors de l'exécution du second Updater par exemple pour détecter un élément spécifique avec --ids (voir ci-dessous).
-S optionnel Afficher les journaux sur la console plutôt que dans des fichiers. Utile lorsque vous exécutez le script à partir de la ligne de commande pour des tâches de maintenance.

Il est recommandé que les paramètres des options -l et -s (ou leur absence) soient les mêmes pour munge.sh et runUpdate.sh, sinon les données pourraient ne pas être mises à jour correctement.

Exemple :

./runUpdate.sh

Egalement, les variables d'environnement suivantes sont contrôlées par le script (toutes sont optionnelles) :

Variable Défaut Explication
UPDATER_OPTS vide Options additionnelles, passées telles quelles sur la ligne de commande Java

Options de Updater

Les options suivantes fonctionnent avec l'application Updater.

Elles doivent être passées au script runUpdate.sh comme des options supplémentaires après --, par exemple : runUpdate.sh -- -v.

Options du programme de mise à jour
Option Option longue Signification
-v --verbose Mode verbeux
-s TIMESTAMP --start TIMESTAMP Démarrer la collection de données à partir d’un certain moment spécifié au format 2015-02-11T17:11:08Z ou 20150211170100
--keepTypes Conserver toutes les déclarations de type
--ids ID1,ID2,... Mettre à jour certains identifiants et arrêter
--idrange ID1-ID2 Mettre à jour un intervalle d’identifiants et arrêter
-d SECONDS --pollDelay SECONDS Durée de la pause lorsqu'aucune nouvelle donnée n’est disponible
-t NUMBER --threadCount NUMBER Nombre de threads à utiliser lors de l'accès aux données Wikibase
-b NUMBER --batchSize NUMBER Nombre de modifications à récupérer par l'API RecentChanges
-V --verify Vérifier les données après chargement (à n'utiliser que pour le débogage seulement)
-T SECONDS --tailPollerOffset SECONDS Utiliser le second scrutateur avec un décalage donné derrière le principal
--entityNamespaces NUMBER,NUMBER,... Liste des espaces de noms Wikibase à vérifier pour les modifications
-W --wikibaseUrl URL URL à utiliser dans les dialogues avec Wikibase, par exemple https://www.wikidata.org. Doit être initialisé si les mises à jour ne viennent pas de Wikidata.
-U --conceptUri URL URL de base des URLs utilisées pour représenter les entités Wikibase en RDF, par exemple : http://www.wikidata.org , doit être déclarée si l'instance Wikibase n'utilise pas les préfixes basés de Wikidata.
--commonsUri URL URI de Commons pour la prise en charge de SDC. --conceptUri et --commonsUri doivent être initialisés en même temps pour que cela fonctionne.
--wikibaseScheme SCHEME URL du schéma (http, https) à utiliser dans les dialogues avec Wikibase. (obsolète) Utilisez à la place wikibaseUrl ci-dessus.
--wikibaseHost HOSTNAME Nom d'hôte à utiliser pour les dialogues avec Wikibase. (obsolète) Utilisez à la place wikibaseUrl ci-dessus.
-I --init Si spécifié en même temps que l'heure de début, cette heure est marquée dans la base de données comme l'heure de modification la plus récente, et les requêtes suivantes vont l'utiliser comme point de départ même s'il n'y a pas eu de nouvelles données.
--constraints Charge les violations des contraintes pour les éléments mis à jour via l'API constraintsrdf .
-K SERVERS --kafka SERVERS Si spécifié, Updater utilisera Kafka comme source de mise à jour et les serveurs spécifiés en tant que courtiers. Par exemple : kafka1001.eqiad.wmnet:9092,kafka1002.eqiad.wmnet:9092,kafka1003.eqiad.wmnet:9092
-C NAME --consumer NAME Nom du consommateur Kafka. Il est bon de l'initialiser avec le nom de l'hôte (host name) ou un nom qui le contient.
-c NAME1,NAME2 --cluster NAME1,NAME2 Noms des grappes (clusters) Kafka. Si spécifié, les noms des sujets Kafka seront préfixés par le nom des grappes, et donc au lieu de topic1 il y aura NAME1.topic1 et NAME2.topic2.
--resetKafka Réinitialisation des décalages Kafka
--apiPath chemin de l'API, par exemple /w/api.php (par défaut) ou /api.php. Introduit en I78c222fe8b.
--entityDataPath chemin vers les entités, par exemple /wiki/Special:EntityData/ (par défaut) ou /Special:EntityData/. Introduit en I78c222fe8b.

Propriétés configurables

Les propriétés suivantes sont configurables en les ajoutant dans l'exécution des scripts ci-dessus :

Nom Signification Par défaut
wikibaseServiceWhitelist Nom de fichier de la liste blanche du service distant. S'applique à Blazegraph. whitelist.txt
org.wikidata.query.rdf.blazegraph.mwapi.MWApiServiceFactory.config Fichier de configuration pour l'intégration MWAPI mwservices.json
com.bigdata.rdf.sail.sparql.PrefixDeclProcessor.additionalDeclsFile Nom de fichier contenant les définitions additionnelles de préfixes. La syntaxe est celle des requêtes SPARQL. Ces définitions seront chargées par Blazegraph et disponibles pour toutes les requêtes.
wikibaseConceptUri Préfixe d'URL pour les données Wikibase, utilisé dans la représentation RDF des entités. Doit être initialisé si l'ensemble de données n'utilise pas les préfixes Wikidata. http://www.wikidata.org
commonsConceptUri Préfixe d'URL pour le support Structured Data on Commons. wikibaseConceptUri et commonsConceptUri doivent être initialisés en même temps pour que cela fonctionne.
wikibaseHost Nom d'hôte de l'instance wikibase. S'applique à la fois à Blazegraph et Updater. (obsolète) Utiliser wikibaseConceptUri ci-dessus. www.wikidata.org
org.wikidata.query.rdf.blazegraph.inline.literal.WKTSerializer.noGlobe Valeur du globe par défaut pour les coordonnées qui n'ont pas de globe. « 2 » indique que l'entité Q2 est le globe par défaut. « 0 » indique qu'il n'y a pas de globe par défaut. S'applique à Blazegraph. 0
org.wikidata.query.rdf.tool.rdf.RdfRepository.timeout Temps d'attente maximal pour les communications avec le dépôt RDF, en secondes. S'applique à Updater. -1
org.wikidata.query.rdf.tool.wikibase.WikibaseRepository.timeout Temps d'attente maximal pour les communications avec le dépôt wikibase, en millisecondes. S'applique à Updater. 5000
http.userAgent Agent utilisateur que le service utilisera lors de l'appel aux autres services
http.proxyHost http.proxyPort

https.proxyHost https.proxyPort

Paramètres de proxy utilisés lors de l'appel aux autres services
wikibaseMaxDaysBack Combien de jours en arrière il est possible de remonter pour demander les modifications récentes des données de Updater. Si la base de données est plus ancienne que ce nombre de jours, elle doit être rechargée à partir de la sauvegarde la plus récente. 30

Fonctionnalités absentes

Les fonctionnalités ci-dessous ne sont actuellement pas prises en charge :

  • Les redirections ne sont uniquement représentées que par un triplet owl:sameAs, mais n'expriment pas d'autre équivalence dans les données et n'ont pas de prise en charge particulière.

Contacts

Si vous remarquez quelque chose d'anormal avec le service, vous pouvez contacter l'équipe Discovery par courriel sur la liste discovery@lists.wikimedia.org ou sur le canal IRC #wikimedia-discovery.

Les bogues peuvent aussi être rapportés dans Phabricator et suivis sur le tableau Discovery Phabricator.

Voir aussi

Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikidata_Query_Service/User_Manual/fr&oldid=6462043"