Spatio-temporal Wikidata. Exploration de données ouvertes et liées du web 3.0
Histoire de cadre : élaboration d’une trajectoire spatio-temporelle
Cette fiche est le fruit d’un dialogue interdisciplinaire entre membres du GT Notebook initié dans le cadre d’un atelier proposé à la Journée d’études normande sur les données de la recherche qui s’est déroulée en décembre 2021. L’association de plusieurs compétences et disciplines a abouti à ce notebook. Il présente une analyse exploratoire reproductible de données ouvertes et liées d’un fragment de graphe Wikidata, interrogeables sous la forme de triplets RDF. Les enjeux d’un tel processus inter-disciplinaire sont esquissés en conclusion. Une ébauche des requêtes SPARQL élaborées a fait l’objet d’une présentation et d’échanges au sein des Ateliers du Web Sémantique au printemps 2021.
Introduction
Cette fiche présente une exploration du graphe Wikidata (cf. parties 1.2 et 3) et le traitement des données extraites (cf. parties 2 et 4).
Du requêtage en langage SPARQL (cf. partie 1.3) au traitement et à la représentation des données issues du graphe Wikidata, ce document présente, étape par étape, l’ensemble de la chaîne de traitement réalisée. Le processus exploratoire, parfois itératif, a été conservé afin de mieux comprendre l’approche réflexive des auteurs et autrice. Le notebook retranscrit les démarches scientifique et méthodologique adoptées.
Le schéma organisant ces données est esquissé dans la partie 1. Afin de permettre une reproduction des traitements et des résultats présentés, les données automatiquement collectées au 31 janvier 2024 et utilisées dans ce document sont mises à disposition (cf. partie 2.2). L’idée de départ conduit à la démarche suivante en 3 étapes :
- requêter les données (ou suivre des chemins) du graphe
Wikidata,
- identifier certaines des modalités du graphe pouvant comporter une
dimension spatiale et temporelle et ainsi,
- reconstruire et représenter une ou des trajectoires dans le temps et l’espace.
Compte-tenu du formalisme et de l’hétérogénéïté des données non
supervisées de Wikidata, deux images d’objet sont choisies pour l’étude
: un artiste-peintre et une de ses peintures, exposée au sein de musées
ou d’institutions culturelles dans le monde. Pour reproduire
partiellement l’expérimentation, un exemple d’exploration du graphe
Wikidata pour diverses images d’artistes-peintres est proposée dans la
partie 7.
NB : le terme “image” utilisé dans ce document correspond à une
sémantique de l’individu présent dans l’espace numérique sous la forme
de données et de métadonnées en relation avec d’autres images d’objet,
selon Hui (2015). En ce sens, les œuvres
elles-mêmes, photographiées ou scannées etc. sous les formes de fichiers
d’extension .jpg .png etc. sont désignées par le terme d’“illustration”
ou de fichiers. Pour simplifier le discours, l’image d’individu est
désignée par l’individu lui-même : par exemple, l’image du peintre
Johannes Vermeer, l’entité Wikidata de valeur Q41264
définie par ses relations dans
l’espace numérique, est désignée par Johannes Vermeer ou Vermeer. Le
fichier .jpg Wikidmédia de son auto-portrait supposé, fragment de
l’oeuvre intitulée «l’Entremetteuse», est une illustration représentant
le peintre.
1 Wikimédia, Wikidata & W3C
1.1 Données ouvertes et liées du graphe Wikidata
Wikidata est une base de connaissances libre, éditée de manière collaborative et hébergée par la fondation Wikimedia. Son contenu étant placé sous licence CC0 (« Transfert dans le Domaine Public »), elle permet de centraliser l’accès aux données utilisées par différents projets Wikimedia (Wikipédia (2021)).
Les informations saisies dans Wikidata sont des données ouvertes “brutes” multilingues non-supervisées qui sont liées, notamment aux articles de l’encyclopédie contributive Wikipedia. Wikidata est à différencier de l’ontologie DBpedia1 (figure 1) au sens où l’ontologie sous-jacente de Wikidata n’est pas formalisée à priori - ce qui est le cas de DBpedia, mais elle émerge des usages et pratiques de la communauté Wikidata. En effet, les deux dispositifs à vocation encyclopédique diffèrent dans leurs finalités initiales. DBpedia est un effort de la communauté scientifique pour extraire des informations structurées du projet encyclopédique Wikipedia et les lier à d’autres formalismes de données du web sémantique. Wikidata est un dispositif de curation2 ou d’annotation de données par les contributeurs et contributrices de Wikipedia ou Wikidata.
Source : Wikidata-Basics | Wikidata Hackathon event for the Festival of Creative Learning, 2018
La base Wikidata fournit un support à de nombreux autres sites
et services au-delà des seuls projets de Wikimedia. Son contenu est
exporté dans des formats standards et peut être lié ou aligné à d’autres
ensembles de données ouvertes sur le Web des données3. Wikidata offre ainsi
un large domaine d’informations générales sur notre univers ou ses
représentations et des liens vers d’autres graphes ou bases de données.
Il contient à ce jour plus de 100 millions d’items.
La dynamique
de création collective de ce projet encyclopédique peut être saisie à
l’oreille grâce à l’application développée par Hatnote, Stephen
LaPorte and Mahmoud Hashemi.
1.2 Standard RDF du W3C
Le RDF (Resource Data Framework) est un cadre général de modélisation utilisé pour décrire formellement les ressources du Web via leurs métadonnées afin de permettre le traitement par inférence de telles descriptions. Développé par le W3C4, le RDF est le formalisme de base du Web sémantique.
Au sein de ce paradigme, un document ou une ressource consiste en un
ensemble de triplets5, chacun associant un sujet, un prédicat et
un objet :
- le «sujet» du prédicat représente la ressource à décrire,
- le «prédicat» représente un type de propriété applicable à cette
ressource,
- l’«objet» représente une donnée, une autre ressource ou une valeur
associée à la propriété (ou prédicat).
Le sujet et l’objet, dans le cas où ce sont des ressources, peuvent être identifiés par un identifiant unique de la ressource (URI6), une valeur ou être des nœuds anonymes. Le prédicat est nécessairement identifié par un URI. Par exemple, la déclaration “Bob s’intéresse à Mona Lisa” est formalisée de la manière suivante :
Un dépôt de triplets RDF ainsi formé correspond à un multigraphe orienté étiqueté : chaque triplet correspond alors à une arête orientée dont l’étiquette est le prédicat, le sujet est le nœud source et l’objet est le nœud cible (figure 3).
1.3 Le langage SPARQL
SPARQL7 (prononcé sparkle, en anglais : « étincelle ») est à la fois un langage de requête et un protocole qui permettent de rechercher, d’ajouter, de modifier ou de supprimer des triplets RDF disponibles à travers le Web. Aujourd’hui, le Web de données (représenté par le nuage du Linked Open Data ou ses domaines) est interrogeable via des centaines de services SPARQL qui mettent à disposition de plus en plus de graphes de données ouvertes et liées comme c’est le cas du projet plurilingue Wikidata (Wikipédia (2022)).
Vocabulaire ou espace de noms
Dans Wikidata les entités et leurs coordonnées spatiales et temporelles sont modélisées selon les fragments de graphes lisibles par l’humain et la machine dans divers formats : XML, json, turtle etc. Ceux-ci comprennent des classes instanciées et liées entre elles par des prédicats (ou relations). Pour Wikidata comme pour d’autre modèles de données, il existe un vocabulaire spécifique. En général, les ontologies du web sémantique disposent d’un vocabulaire décrit au sein d’espaces de noms associés au micro-monde décrit.
Par exemple, pour modéliser les données des réseaux sociaux, il
existe un vocabulaire dédié “Friend of a friend (FOAF)” ; pour les ressources
bibliographies, la BnF mobilise notamment le vocabulaire “Functional Requirements for Bibliographic Records”
(FRBR) élaboré par la Fédération internationale des associations et
institutions de bibliothèques (IFLA) etc. Un autre exemple est
l’ontologie du domaine associée à la diffusion de la musique fondée en
2002 avec l’initiative MusicBrainz (Swartz 2002), “corne d’abondance des
communs” musicaux, déployée avec l’émergence du web.
L’espace de nom de l’ontologie de Wikipedia, DBpedia est accessible à
cette URL : https://dbpedia.org/ontology/.
Préfixes et requêtes
À chaque vocabulaire utilisé pour construire la requête sont associés différents préfixes8. Dans le cas présenté, la déclaration du vocabulaire mobilisé (celui de Wikidata notamment) est intégrée aux packages utilisés. Toutefois, en général, il est nécessaire de le préciser dans l’entête de la requête SPARQL, sous une certaine forme :
PREFIX préfixe: <espace de nom>
Les éléments d’un triplet prennent alors la forme suivante :
prédicat = préfixe:propriété
domaine/co-domaine = préfixe:entité
Par exemple, pour utiliser la syntaxe d’un ensemble de deux triplets
associant une entité recherchée de type ville
à son
pays
:
?city rdf:type dbo:City .
?city dbo:country ?country .
il est nécessaire de déclarer les vocabulaires DBpedia et RDF :
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
permettant de définir l’entité recherchée, dans le vocabulaire de Wikipédia et de la norme RDF :
- par une relation de type ville,
- et une propriété de localisation dans un pays.
Avec la déclaration des espaces de noms et la simplification de la syntaxe utilisant des préfixes, il est possible d’interroger des graphes (NoSQL) au moyen d’un protocole Sparql sur un Point de Présence (SPARQLEndPoint) au sein d’un réseau HTTP.
Dans la suite, plusieurs préfixes Wikidata spécifiques aux entités et aux types de propriétés sont utilisés. Dans le cadre de notre étude, le tableau suivant récapitule les classes et propriétés utilisées, ainsi que quelques préfixes du schéma Wikidata utilisés pour former les triplets :
classe ou propriété | préfixe | exemple(s) de chemin | label wikidata |
---|---|---|---|
P31 | wdt |
?identifiant wdt:P31 wd:Q5 | nature de l’élément |
Q5 | wd |
?identifiant wdt:P31 wd:Q5 | être humain |
P373 | wdt |
?identifiant wdt:P373 ‘Johannes Vermeer’ | a pour catégorie |
P18 | wdt |
?identifiant wdt:P18 ?image | a pour image |
P170 | wdt , p |
?oeuvre wdt:P170 wd:Q41264 ?oeuvre* p:P170 wd:Q41264 | créé par (Q41264 identifie le peintre Johannes Vermeer) |
P276 | wdt , p |
?oeuvre wdt:P276 ?lieu OU ?oeuvre p:P276 ?lieu* |
lieu |
P625 | wdt |
?musee wdt:P625 ?coord | coordonnées |
P580 | pq |
?lieu* pq:P580 ?dated | date de début |
P582 | pq |
?lieu* pq:P582 ?datef | date de fin |
label, language | wikibase |
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE], fr,en ".} |
syntaxe du service de langue wikidata |
- dans le cas où la propriété est directe, c’est à dire que le
préfixe
p
est utilisé au lieu du préfixewdt
, le résultat ou la donnée est une assertion. Cette spécificité du graphe wikidata est abordée dans la partie 3.
2 Packages et données
2.1 Packages utilisés
Les packages utilisés pour réaliser l’ensemble de la chaîne de traitement présenté dans ce document sont les suivants :
wikidataR
9 (et son extensionWikidataQueryServiceR
) : permet d’écrire une requête pour interroger le graphe de données Wikidata au moyen d’une Interface de Programmation d’Application (API) pour le service de requêtes Wikidata en langage SPARQL10 ;
glitter
: permet l’écriture de requêtes SPARQL sans maîtriser la syntaxe de ce langage, pour sonder divers graphes (dont Wikidata) avec ses dépendancesggraph
ettidygraph
;
rnaturalearth
: met à disposition les données géographiques de Natural Earth ;
sf
: permet la gestion et la manipulation de données géographiques vectorielles ;
dplyr
: pour la manipulation des données ;
mapview
: pour l’affichage interactif de données géographiques (repose sur la librairie JavaScript Leaflet) ;
tmap
: pour la création de cartes thématiques ;
ggplot2
: permet la production de graphiques basés sur la grammaire graphique ;
av
: génère des vidéos à partir d’images ou de graphiques R ;
patchwork
: permet de combiner plusieurs graphiquesggplot2
dans la fenêtre graphique ;
jpeg
: permet l’import, l’enregistrement et l’affichage des images matricielles (format bitmap) ;
DT
: pour la mise en forme dynamique (HTML) de tableau de données (bibliothèque javascript DataTables).
Vous pouvez utiliser les lignes de code suivantes pour installer ces packages :
# Liste des packages du CRAN nécessaires
liste_packages <- c("WikidataR",
"WikidataQueryServiceR",
"remotes",
"rnaturalearth",
"sf",
"dplyr",
"mapview",
"tmap",
"ggplot2",
"av",
"patchwork",
"jpeg",
"DT",
"ggraph",
"tidygraph")
# Packages à installer
liste_packages_a_installer <- liste_packages[!(liste_packages %in% installed.packages()[,"Package"])]
# Installation des packages manquants
install.packages(liste_packages_a_installer)
L’installation du package glitter
, qui n’est pas encore
disponible sur le CRAN, se fait de la manière suivante :
# Installation du package glitter à partir de R-universe
install.packages("glitter", repos = "https://lvaudor.r-universe.dev")
L’ensemble des informations du système d”exploitation et des versions
de packages utilisés pour générer ce notebook est
disponible en fin de document.
2.2 Données collectées
Plusieurs sources de données sont utilisées pour ce travail exploratoire :
- des données issues du graphe Wikidata ;
- une couche géographique Natural Earth ;
- et des fonds de carte accessibles via Leaflet.
3 Exploration du graphe Wikidata
Voici quelques éléments basiques du langage SPARQL permettant d’interroger la base de données Wikidata :
- la clause
SELECT
des données interrogées renvoit les variables spécifiques (avecCOUNT
, renvoit le nombre des ces données ou avecGROUP_CONCAT
, les concatène au sein d’une collection, regroupées parGROUP BY
et triées parORDER BY
),
- qui, accompagnée de la clause
WHERE { }
, les lie à l’interrogation de propriétés et données associées, suivant les chemins du graphe,
- avec un service WikiLabel spécifique au point d’accès Wikidata
Query Service, du fait du caractère plurilingue de certaines
données du graphe Wikidata, permettant de limiter le résultat à la
langue choisie (
wikibase:language
) du label (wikibase:label
) associé à l’entité ou la propriété recherchée,
- ou encore avec la fonctionnalité
OPTIONAL
de la clauseWHERE
qui permet de renvoyer les variables même si les données liées aux propriétés ne sont pas instanciées (noeuds vides),
- et les différents préfixes associés aux spécificités des propriétés
simples, directes et indirectes etc. des fragments de graphe de Wikidata
(+d’info).
Afin de permettre une bonne compréhension des requêtes réalisées pour la collecte de données sans entrer dans le détail de la syntaxe propre à SPARQL, celles-ci sont formulées de la manière suivante :
SELECT données interrogées, comptage ou concatenage WHERE
{
chemins principaux du graphe
chemins optionnels du graphe
service Wikilabel
}
groupe et ordonne
3.1 Modèle des données : artistes-peintres et trajectoires de leurs œuvres
Le fragment de graphe de l’image Wikidata d’une peinture, objet du processus exploratoire, est illustré sous la forme d’un tableau dans la figure 4 ci-dessous.
Source : Wikidata
Pour plus d’informations, vous pouvez consulter l’introduction à Wikidata ou la page Wikibase dédiée au formalisme du dépôt de données Wikidata.
Après plusieurs explorations, nous avons décidé de nous intéresser, dans une première étape, au peintre néerlandais du 17e siècle, Johannes Vermeer.
Les fonctions find_item
et find_property
du
package WikidataR
permet d’interroger le graphe à partir
d’une chaîne de caractère.
Entités liées à “Johannes Vermeer”
Par exemple, il est possible de collecter les entités (item) correspondant à la chaîne de caractère “Johannes Vermeer” :
# Package API pour interroger le dépôt Wikidata : WikidataR
library(WikidataR)
## Chercher les entités du graphe Wikidata correspondant à "Johannes Vermeer"
resultat_item <- find_item("Johannes Vermeer")
resultat_item
Wikidata item search
Number of results: 10
Results:
1 Johannes Vermeer (Q41264) - Dutch painter (1632–1675)
2 Jan Vermeer van Haarlem the Elder (Q3159680) - painter from the Northern Netherlands and father of Barend, Isaac, and Jan Vermeer or van der Meer II (1628-1691)
3 Johannes Vermeer (Q15283995) - art exhibition
4 Johannes Vermeer (Q102229722) - Ph.D. Vrije Universiteit Amsterdam 1983
5 Johannes Vermeer (Q2164464) - international train between Amsterdam and Cologne
6 Johannes Vermeer (Q124100835) - civil servant in the Dutch East Indies
7 Johannes Vermeer (Q19280548) - street in Ouderkerk aan de Amstel, the Netherlands
8 Johannes Vermeer catalog raisonné, 1908 (Q26235177) - catalog raisonné of Vermeer works by Cornelis Hofstede de Groot
9 Johannes Vermeer Award (Q2141982) - Dutch art award
10 Johannes Vermeerstraat (Q1951387) - street in Amsterdam, the Netherlands
Une seule entité de valeur Q41264
parmi les dix
collectées semble correspondre à l’image au sens de (Hui 2015)
de l’objet Johannes Vermeer, le peintre recherché. Le résultat de la
requête find_item
est composé d’un ensemble d’informations
($id
, $repository
, etc.).
$id
[1] "Q41264"
$title
[1] "Q41264"
$pageid
[1] 43555
$display
$display$label
$display$label$value
[1] "Johannes Vermeer"
$display$label$language
[1] "en"
$display$description
$display$description$value
[1] "Dutch painter (1632–1675)"
$display$description$language
[1] "en"
$repository
[1] "wikidata"
$url
[1] "//www.wikidata.org/wiki/Q41264"
$concepturi
[1] "http://www.wikidata.org/entity/Q41264"
$label
[1] "Johannes Vermeer"
$description
[1] "Dutch painter (1632–1675)"
$match
$match$type
[1] "label"
$match$language
[1] "en"
$match$text
[1] "Johannes Vermeer"
Le champ match
correspond à la chaîne de caractère
recherchée : il est de $type
label,
en$language
en, sous forme de $text
Johannes Vermeer.
Propriétés liées à artiste
Pour connaître les propriétés (properties) associées à celle
des termes “artiste” ou “peintre” par exemple, on utilise
find_property
.
## Chercher les propriétés du graphes correspondant à "artiste"
resultat_property0 <- find_property("artiste")
resultat_property0
Wikidata property search
Number of results: 5
Results:
1 creator (P170) - maker of this creative work or other object (where no more specific property exists)
2 Joconde author ID (P7711) - identifier for a person in the Service des Musées de France Joconde authority file
3 Artists in Canada record number (P5239) - authority control maintained by National Gallery of Canada Library listing biographical data for artists who were born in Canada or worked in Canada
4 make-up artist (P4805) - person in charge of make-up
5 game artist (P3080) - game artist(s) that produced art assets for a role-playing games, collectible card games, video game, etc.
Propriétés liées à peintre
## Chercher les propriétés du graphes correspondant à "peintre"
resultat_property <- find_property("peintre")
resultat_property
Wikidata property search
Number of results: 1
Results:
1 creator (P170) - maker of this creative work or other object (where no more specific property exists)
La propriété associée au terme choisi “peintre” (P170
)
semble être celle liant un créateur à son œuvre ou autre objet. On
comprend comment ce terme est lié à cette propriété dans le modèle de
Wikidata en explicitant le champ $match
:
$type
[1] "alias"
$language
[1] "fr"
$text
[1] "peintre"
La chaîne de caractère “peintre” est une forme textuelle
$text
de $type
“alias” de la propriété
P170
, dans la langue française.
3.2 Déterminer l’identifiant Wikidata d’un peintre
Ces premières investigations du graphe permettent de comprendre que pour collecter de manière précise des données spatio-temporelles associées aux œuvres créées par Johannes Vermeer, les modalités d’interrogation nécessitent d’identifier de manière suffisamment explicite l’entité recherchée telle qu’elle est modélisée au sein du fragment de graphe (figure 5).
SELECT
s’applique aux éléments figurés en données en sortie. Les propriétés et
objets associés (en entrée ou sortie), c’est-à-dire les chemins du
graphe, sont insérés dans l’accollade de WHERE
.
A l’aide de la fonction query_wikidata
du package
WikidataR
, nous commençons dans un premier temps par
obtenir l’identifiant wikidata du peintre et l’illustration qui lui est
associée grâce à l’usage de la propriété P18.
Il est possible de réaliser la requête équivalente de manière plus
concise avec les fonctions du package glitter
qui utilisent
le pipe comme dans tidyverse
et ne nécessitent pas de
connaître la syntaxe du langage SPARQL.
WikidataR
## Construire la requête
# Sélectionner les données identifiant et image telles que
# {
# identifiant est de type humain; # chemin principal
# entre dans la catégorie "Johannes Vermeer"; # chemin principal (suite)
# a pour représentation un fichier # chemin principal (fin)
# }
query <- "SELECT ?identifiant ?image WHERE \
{ \
?identifiant wdt:P31 wd:Q5; \
wdt:P373 'Johannes Vermeer'; \
wdt:P18 ?image \
}"
## Exécuter la requête
data1_WR <- WikidataR::query_wikidata(query)
## Affichage
library(DT)
datatable(data1_WR)
glitter
# Package API en développement pour interroger un dépôt RDF sans connaître la syntaxe SPARQL : glitter
library(glitter)
## Initier la requête et stocker le résultat dans data1_Glitter
data1_Glitter <- spq_init() |>
## Ajouter les chemins du graphe
spq_add("?identifiant wdt:P31 wd:Q5") |>
spq_add(". wdt:P373 'Johannes Vermeer'") |> # le . reprend le sujet ?identifiant du premier chemin
spq_add(". wdt:P18 ?image") |>
## Executer la requête
spq_perform()
## Affichage
DT::datatable(data1_Glitter)
Le résultat renvoyé par cette requête nous permet de vérifier que l’image de l’objet Johannes Vermeer et sa représentation sont bien identifiées dans Wikidata :
- par la valeur “Q41264” et le nom du fichier Wikimedia d’extension
jpg, résultat de la requête réalisée avec le package
WikidataR
;
- et les URIs https://www.wikidata.org/wiki/Q41264 et http://commons.wikimedia.org/wiki/Special:FilePath/Cropped%20version%20of%20Jan%20Vermeer%20van%20Delft%20002.jpg
pour
glitter
.
A partir de ce dernier, nous téléchargeons le fichier ou l’illustration associée au peintre en deux étapes.
- Création d’un répertoire
- Téléchargement et enregistrement
# Téléchargement et sauvegarde du fichier de l'image numérisée
download.file(url = data1_Glitter$image,
destfile = 'data/images/portrait_artiste.jpg',
mode = 'wb')
3.3 Lister les œuvres du peintre et trouver leurs localisations géographiques
Dans cette seconde étape, on se propose de lister les œuvres de
Johannes Vermeer avec leurs localisations. Au sein du graphe Wikidata,
on fait l’hypothèse que les coordonnées de la localisation d’une œuvre,
c’est à dire la valeur point(x,y)
, sont celles du musée ou
de l’institution au sein de laquelle l’œuvre est actuellement exposée ou
située. Afin d’obtenir cette localisation à partir de l’identifiant du
peintre, on trace un premier chemin du graphe tel qu’illustré dans la
figure 7.
point(x,y)
donne les coordonnées géographiques dans
le système de référence World Geodetic System (WGS84).
Le nom des œuvres et des musées (suffixe “Label”) est obtenu par le
service wikibase:label
du package
WikidataQueryServiceR
, dans la langue
wikibase:language
choisie ou la fonction
sqp_label
du package glitter
.
3.3.1 Construction des requêtes
WikidataR
## Construire la requête
# Sélectionner les données oeuvre, musée et coordonnées telles que
# {
# l'oeuvre a pour peintre Johannes Vermeer; # chemin principal
# en option
# {
# l'oeuvre est localisée dans un musee . # chemin optionnel
# ce musée a pour localisation les coordonnées # chemin optionnel
# }
# }
query <- "SELECT ?oeuvre ?musee ?coord WHERE \
{ \
?oeuvre wdt:P170 wd:Q41264 . \
OPTIONAL \
{ \
?oeuvre wdt:P276 ?musee .
?musee wdt:P625 ?coord \
} \
}"
## Exécuter la requête
data2_WR <- WikidataR::query_wikidata(query)
## Affichage des résultats
DT::datatable(data2_WR)
WikidataQueryServiceR
library(WikidataQueryServiceR)
## Construire la requête avec le service de langue
# Sélectionne les noms des données oeuvre, musée et les coordonnées telles que
# {
# l'oeuvre a pour peintre Johannes Vermeer; # chemin principal
# en option
# {
# l'oeuvre est localisée dans un musee . # chemin optionnel
# ce musée a pour localisation les coordonnées # chemin optionnel
# }
# en langue anglaise (en) # service Wikilabel
# }
query_label <- "SELECT ?oeuvreLabel ?museeLabel ?coord WHERE \
{ \
?oeuvre wdt:P170 wd:Q41264 . \
OPTIONAL \
{ \
?oeuvre wdt:P276 ?musee .
?musee wdt:P625 ?coord \
} \
SERVICE wikibase:label \
{ \
bd:serviceParam wikibase:language \"[AUTO_LANGUAGE], en \". \
} \
}"
## Exécuter la requête
data2_WOSR <- query_wikidata(query_label)
## Affichage des résultats
DT::datatable(data2_WOSR)
glitter
## Initier la requête et stocker le résultat dans data_Glitter
data2_Glitter <- spq_init() |>
## Sélectionner les données interrogées
spq_select(oeuvre,musee,coord) |>
## Ajouter les chemins du graphe
#- chemin principal
spq_add("?oeuvre wdt:P170 wd:Q41264") |>
#- chemins optionnels
spq_add("?oeuvre wdt:P276 ?musee", .required=FALSE) |>
spq_add("?musee wdt:P625 ?coord", .required=FALSE) |>
#- service de langue de wikidata en anglais
spq_label(musee,oeuvre,.languages = c("en"),.overwrite = TRUE) |>
## Exécuter la requête
spq_perform()
## Affichage des résultats
DT::datatable(data2_Glitter[,c("oeuvre","musee", "coord")])
3.4 Premiers éléments d’analyse exploratoire
3.4.1 Quelques constats sur le graphe et les données
On constate que les données (non supervisées) du graphe Wikidata concernant les lieux d’exposition des œuvres de Vermeer et leurs coordonnées géographiques sont hétérogènes* :
certaines œuvres semblent n’avoir aucune localisation, l’information n’étant pas disponible dans le graphe Wikidata tel qu’interrogé (voir ci-dessous),
d’autres semblent être liées à des lieux correspondant à des données d’une autre nature qu’un musée ou institution (par exemple, “Leiden Collection” pour l’œuvre “A Young Woman Seated at the Virginals” ou encore “Room 837” (une salle du musée du Louvre) pour “The Lacemaker” etc.), sans coordonnées géographiques associées,
enfin, parmi les œuvres localisées, certaines présentent plusieurs localisations de nature différente (par exemple, les œuvres “The Astronomer”), et dans certains cas, plusieurs fois le même musée avec éventuellement des coordonnées très légèrement distinctes (par exemple, “The Geographer” au Städel Museum) etc.
NB: Il est possible de réaliser ces observations avec la fonctionnalité
Search
des tableaux ci-dessous.
Pourquoi ? Plusieurs hypothèses peuvent être esquissées, outre la question des différentes langues qui peuvent générer des doublons :
un même musée peut avoir plusieurs coordonnées géographiques renseignées (plusieurs couples du
Point(x,y)
très proches, par exemple pour le Städel Museum),la localisation d’une œuvre peut conduire à une entité qui n’est ni un musée ni une institution culturelle mais le nom d’une collection (par exemple “The Leiden Collection”) ou d’une salle (par exemple “Room 837” qui est une salle du musée du Louvre) etc.,
une même œuvre peut être située dans plusieurs musées (ou plusieurs fois dans un même musée), peut-être à des périodes différentes.
Ces constats sont liés non seulement au caractère non supervisé et collectif (hétérogène, voire lacunaire) de la production des données, mais aussi à la complexité de la saisie des données dans le graphe Wikidata. En effet, les modalités d’interrogation du graphe Wikidata sont multiples, en fonction notamment de la profondeur du graphe qui est sondée et de la qualité de l’affectation de valeurs à ses instances.
La série de requêtes présentées jusqu’à présent interroge les entités
Wikidata renseignées au moyen des valeurs simples du prédicat de
localisation, c’est à dire avec le préfixe wdt
. Pour aller
plus en profondeur dans le graphe, vérifier la qualité de l’information
de localisation et déterminer sa composante temporelle, il est
nécessaire d’entrer plus en détail dans une autre forme d’instanciation
du graphe, spécifique à Wikidata, à savoir les valeurs complexes ou
déclarations (voir notamment la figure 8).
wdt
) et les relations au sein des déclarations au moyen des
propriétés directes spécifiques (préfixes p
,
ps
ou pq
) utilisées infra. Source : Wikibase
3.4.2 Le
corpus des œuvres de (P170
) Johannes Vermeer selon
Wikidata
Pour bien comprendre la différence entre l’interrogation “en surface”
du graphe et celle “en profondeur”, on sonde deux modalités de la
propriété P170 créé par
dont le peintre Vermeer est l’objet
pour identifier le corpus de ses œuvres.
Valeurs complexes ou déclarations
## Construire la requête
# Sélectionne les données oeuvre et leur nom telles que
# {
# l'oeuvre est liée à une assertion de création au peintre Johannes Vermeer; # chemin principal
#
# en langue anglaise (en) # service Wikilabel
# }
# par ordre décroissant # ordonne
query_declaration <- "SELECT ?oeuvre ?oeuvreLabel WHERE \
{ \
?oeuvre p:P170/ps:P170 wd:Q41264
SERVICE wikibase:label \
{ \
bd:serviceParam wikibase:language \"[AUTO_LANGUAGE], en \". \
} \
} \
ORDER BY DESC( ?oeuvre )"
## Stocker le résultat de l'exécution des requêtes
resultats_oeuvres_exhaustif <- WikidataQueryServiceR::query_wikidata(query_declaration)
## Nombre d'oeuvres associées avec une assertion exhaustive
nombre_oeuvres_exhaustif=nrow(resultats_oeuvres_exhaustif)
print(nombre_oeuvres_exhaustif)
[1] 44
Valeurs simples ou “quasi-vérités”
## Construire la requête
# Sélectionne les données oeuvre et leur nom telles que
# {
# l'oeuvre a pour créateur le peintre Johannes Vermeer; # chemin principal
#
# en langue anglaise (en) # service Wikilabel
# }
# par ordre décroissant
query_valeur_simple <- "SELECT ?oeuvre ?oeuvreLabel WHERE \
{ \
?oeuvre wdt:P170 wd:Q41264 \
SERVICE wikibase:label \
{ \
bd:serviceParam wikibase:language \"[AUTO_LANGUAGE], en \". \
} \
} \
ORDER BY DESC( ?oeuvre )"
## Stocker le résultat de l'exécution des requêtes
resultats_oeuvres_valeur_simple <- WikidataQueryServiceR::query_wikidata(query_valeur_simple)
## Nombre d'oeuvres associées avec une assertion exhaustive
nombre_oeuvres_valeur_simple=nrow(resultats_oeuvres_valeur_simple)
print(nombre_oeuvres_valeur_simple)
[1] 38
La requête effectuée sur le graphe renvoit 2 résultats différents :
- dans le premier cas
prop/statement/P170
correspondant aux valeurs complexes (ou déclarations), c’est à dire avec le préfixep
, le graphe compte 44 œuvres ; - dans le second cas
prop/direct/P170
correspondant aux valeurs simples (ou “quasi-vérités”), c’est à dire avec le préfixewdt
, on compte 38 œuvres ;
soit un écart de 6 œuvres.
En différenciant les modalités d’interrogation associées aux différents types de prédicats d’attribution des œuvres à Vermeer, il est possible de connaître la liste de ces œuvres objets d’une valeur complexe (ou déclaration) au sein du fragment de graphe Wikidata, qui ne sont pas des “quasi-vérités” (ou valeur simple, voir figure 8) :
library(dplyr)
## Comparaison et affichage des œuvres présentes seulement dans les déclarations exhaustives associées à la propriété
oeuvres_declarees=resultats_oeuvres_exhaustif %>%
filter(!oeuvre %in% resultats_oeuvres_valeur_simple$oeuvre)
DT::datatable(oeuvres_declarees)
Cette différence de résultat peut conduire à poursuivre l’investigation du corpus tel que modélisé et instancié dans le graphe wikidata. Par exemple, pour connaître la nature de la relation de ces œuvres au peintre Johannes Vermeer (sont-elles réellement de Vermeer ?), il est possible de sonder le fragment de graphe sur d’autres valeurs, notamment au moyen :
- de prédicats qualifiant l’attribution de l’œuvre (dits
qualifiers avec le préfixe
pq:
) comme par exemple :P1777 à la manière de
,P1778 faux imitant
,P1778 d'après une œuvre de
,P1774 atelier de
etP1775 suiveur de
Johannes Vermeer, qui ne sont pas ses œuvres, - mais aussi d’autres chemins du graphe Wikidata qui permettent de
préciser la qualité de l’information, comme par exemple le rang
(
wikibase:rank
) associé à la valeur de l’attribution (ps:
) de l’œuvre ou à la qualification (pq:
) de cette attribution.
Ces autres chemins du graphe Wikidata concernant “la main” du peintre ou plus généralement la qualité des informations collectées, ne sont pas développés ici.
La pertinence de l’usage des prédicats de qualification sera
démontrée dans la suite avec l’exemple de la localisation au sein d’une
valeur complexe spatio-temporelle de l’œuvre choisie pour notre cas
d’étude, mobilisant la propriété P276
de lieu.
3.4.3 Choisir l’œuvre de Vermeer qui a le plus voyagé
La qualité de l’information de localisation est déterminante dans notre démarche. Celle-ci peut avoir plusieurs valeurs dans le graphe wikidata, comme nous l’avons montré dans le tableau au paragraphe précédent. Elle peut avoir des formes différentes, dont celle d’une assertion, c’est à dire une localisation complexe dans l’espace et le temps, selon le modèle de Wikidata.
Pour choisir l’œuvre de Vermeer qui a le plus voyagé, nous allons
voir ici que des modalités d’interrogation avec deux prédicats de lieu,
c’est à dire ceux construits à partir de la propriété P276
,
donnent des résultats très différents.
dans la partie “immergée” du graphe
## Construire la requête
# Sélectionne le nom des données oeuvre et compte leur nombre de coordonnées distinctes telles que
# {
# l'oeuvre est liée à une assertion de création au peintre Johannes Vermeer; # chemin principal
# de localisation au musée. # chemin principal (suite)
# ce musée a pour localisation les coordonnées # chemin principal (fin)
# en langue anglaise (en) # service Wikilabel
# }
# pour chaque nom d'oeuvre # groupe
# par ordre décroissant # ordonne
query <- "SELECT ?oeuvreLabel \
(COUNT(DISTINCT?coord) AS ?count) WHERE \
{ \
?oeuvre p:P170/ps:P170 wd:Q41264; p:P276/ps:P276 ?musee . \
?musee wdt:P625 ?coord \
SERVICE wikibase:label \
{ \
bd:serviceParam wikibase:language \"[AUTO_LANGUAGE], en \". \
} \
} \
GROUP BY ?oeuvreLabel \
ORDER BY DESC(?count)"
## Exécuter la requête
metadonnees_localisation_oeuvres <- WikidataQueryServiceR::query_wikidata(query)
## Affiche le résultat
DT::datatable(metadonnees_localisation_oeuvres)
“à la surface” du graphe
## Construire la requête
# Sélectionne le nom des données oeuvre et compte leur nombre de coordonnées distinctes telles que
# {
# l'oeuvre a pour créateur le peintre Johannes Vermeer; # chemin principal
# localisation un musée. # chemin principal (suite)
# ce musée a pour localisation les coordonnées # chemin principal (fin)
# en langue anglaise (en) # service Wikilabel
# }
# pour chaque nom d'oeuvre # groupe
# par ordre décroissant # ordonne
query <- "SELECT ?oeuvreLabel \
(COUNT(DISTINCT?coord) AS ?count) WHERE \
{ \
?oeuvre p:P170/ps:P170 wd:Q41264 ; wdt:P276 ?musee . \
?musee wdt:P625 ?coord \
SERVICE wikibase:label \
{ \
bd:serviceParam wikibase:language \"[AUTO_LANGUAGE], en \".\
} \
} \
GROUP BY ?oeuvreLabel \
ORDER BY DESC(?count)"
## Exécuter la requête
metadonnees_localisation_oeuvres_valeur_simple <- WikidataQueryServiceR::query_wikidata(query)
## Affiche le résultat
DT::datatable(metadonnees_localisation_oeuvres_valeur_simple)
On le comprend ici, dans le cas d’une requête limitée aux “quasi-vérités” (ou valeurs simples), il n’est pas possible d’identifier les localisations réelles successives des œuvres. Les valeurs associées sont d’une autre nature.
Par contre, en mobilisant l’information de localisation complexe
“réelle”, c’est à dire fondée sur des chemins adaptés du graphe, l’œuvre
intitulée “Dame assise au virginal” (entité Q4660880) est, selon Wikidata, l’œuvre de Johannes
Vermeer qui a le plus voyagé pour être exposée. Cela signifie que cette
instance de la classe œuvres possède le plus grand nombre de valeurs
associées au prédicat direct de “lieu” p:P276 dans les déclarations exhaustives de
localisation (valeurs du prédicat ps:P276
) désignant des
musées ou institutions. Leurs coordonnées sont des valeurs simples liées
par le prédicat simple wdt:P625.
Ce constat ouvre une nouvelle perspective en matière d’analyse
exploratoire. Nous allons donc nous intéresser à la trajectoire
spatio-temporelle de cette œuvre.
3.5 Troisième requête SPARQL : déclaration spatiale et temporelle
Comme illustré dans la figure 9, la localisation spatio-temporelle d’une entité est déclarée au moyen d’un prédicat direct (p:P276), qui permet l’accès à une forme complexe de localisation de l’œuvre choisie :
- dont les valeurs du prédicat
ps:P276
sont des lieux (géographiques et institutionnels) caractérisés par l’ensemble des déclarations de localisations spatialespoint(x,y)
, valeurs du prédicat simplewdt:P625
;
- dont les valeurs des prédicats de type qualifiers de la déclaration
?lieu
donnent des périodes temporelles (date de début :pq:P580
, date de fin:pq:P582
) ou date/point dans le temps de l’événement associépq:P585
.
3.5.1 Construction des requêtes
WikidataQueryServiceR
## Construire la requête
# Sélectionne le nom des données musée, dates et coordonnées telles que
# {
# l'oeuvre choisie est localisée directement au lieu. # chemin principal
# ce lieu est lié dans une assertion de localisation à un musée; # chemin principal (suite)
# est lié dans une assertion de temporalité à une date de début; # chemin principal (suite)
# est lié dans une assertion de temporalité à une date de fin. # chemin principal (suite)
# ce musée a pour localisation les coordonnées . # chemin principal (suite)
# en langue anglaise (en) # service Wikilabel
# }
query <- "SELECT ?museeLabel ?dated ?datef ?coord WHERE \
{ \
wd:Q4660880 p:P276 ?lieu . \
?lieu ps:P276 ?musee ;
pq:P580 ?dated ;
pq:P582 ?datef . \
?musee wdt:P625 ?coord . \
SERVICE wikibase:label \
{ \
bd:serviceParam wikibase:language \"[AUTO_LANGUAGE], en \". \
} \
}"
## Construire la requête
# Sélectionne la donnée image telle que
# {
# l'oeuvre choisie a pour image une représentation numérique . # chemin principal
# }
query_image <- "SELECT ?image WHERE \
{ \
wd:Q4660880 wdt:P18 ?image \
}"
## Exécuter les requêtes
metadonnees_lieu_temps_oeuvre <- WikidataQueryServiceR::query_wikidata(query)
## Afficher le résultat
DT::datatable(metadonnees_lieu_temps_oeuvre)
glitter
data <- spq_init() |>
spq_select(musee,dated,datef,coord) |>
spq_add("wd:Q4660880 p:P276 ?location") |>
spq_add("?location ps:P276 ?musee") |>
spq_add("?location pq:P580 ?dated") |>
spq_add("?location pq:P582 ?datef") |>
spq_add("?musee wdt:P625 ?coord") |>
spq_label(musee, .languages = c("en"), .overwrite = TRUE) |>
spq_perform()
data_image <- spq_init() |>
spq_select(image) |>
spq_add("wd:Q4660880 wdt:P18 ?image") |>
spq_perform()
3.5.2 Affichage et enregistrement des résultats
Affichage d’une partie des données récupérées :
Enregistrement et (ré)import des données :
# Enregistrement des données en format csv
write.csv(x = data, file = "data/data.csv", row.names = FALSE)
# Import du fichier de données enregistrées
data <- read.csv("data/data.csv", row.names = NULL)
Enregistrement de l’image de l’œuvre :
Les trois requêtes SPARQL ont ainsi permis de collecter respectivement :
- l’illustration et l’identifiant associés à Johannes Vermeer dans Wikidata (data_WR) ;
- les œuvres du peintre Johannes Vermeer et leur localisation complexe (musée + coordonnées) (data2) ;
- les informations de localisation (nom du musée, coordonnées et dates) des lieux où a été exposée l’œuvre intitulée “A Young Woman Seated at the Virginals” de Johannes Vermeer (data).
4 Exploration spatiale
Les données non-supervisées collectées nécessitent toujours d’être contrôlées et nettoyées avant d’être exploitées. De plus, les données obtenues comportent des coordonnées géographiques qui permettent de les convertir en véritable couche géographique afin de les cartographier et ainsi d’exploiter leur dimension spatiale.
4.1 Les œuvres de Johannes Vermeer
Les données issues de la seconde requête SPARQL (data2) listent l’ensemble des œuvres de Vermeer et leurs localisations respectives (nom du musée et coordonnées géographiques quand elles existent) selon Wikidata. Avant de les cartographier, quelques traitements sont nécessaires :
- Suppression des doublons et des œuvres sans aucune localisation renseignée ;
- Calcul du nombre d’œuvres par musée (localisation) ;
- Géoréférencement11 des musées abritant des œuvres de Vermeer.
4.1.1 Nettoyage des données
Dans cette partie, nous allons uniquement nous intéresser à la dimension spatiale des données collectées, sans prendre en compte la dimension temporelle. Si aucune coordonnée géographique n’est renseignée (cf. partie 3.3), nous ne prendrons pas en compte le musée recensé. En revanche, nous considérons l’ensemble des localisations comportant des coordonnées géographiques, peu importe la temporalité qui leur est associée.
Commençons par supprimer les localisations (musée ou institution) qui ne sont pas associées à des coordonnées géographiques dans Wikidata :
Nous pouvons ensuite supprimer les doublons, que l’on peut expliquer par le fait qu’une œuvre ait pu être exposée à plusieurs reprises dans un même musée, ou qu’un même lieu ait pu être renseigné par plusieurs couples de coordonnées géographiques dans Wikidata.
Pour cela, nous utilisons la fonction duplicated
,
appliquée au couple “nom de l’œuvre + lieu d’exposition”
Affichage des données filtrées :
4.1.2 Regroupement par musée
Plusieurs œuvres semblent avoir été exposées dans les mêmes lieux. Afin de cartographier les musées ayant exposé différentes œuvres de Johannes Vermeer, nous réalisons un regroupement des œuvres par intitulé des musées (musee), tout en calculant le nombre d’œuvres que chacune de ces institutions a exposées au cours du temps.
# Regroupement et calcul du nombre d'œuvres par musée
nb_oeuvres_musee <- data2_Glitter |>
dplyr::group_by(musees = musee, coords = coord) |>
dplyr::summarise(nb_oeuvres = n())
# Histogramme de répartition des musées en fonction du nombre d'œuvres de J.V. exposées
library(ggplot2)
ggplot(nb_oeuvres_musee, aes(x = nb_oeuvres)) +
geom_histogram(breaks = 0:max(nb_oeuvres_musee$nb_oeuvres), col = "white") +
xlab("Nombre d'œuvres exposées") +
ylab("Nombre de musées")
4.1.3 Géoréférencement
La variable ‘coords’ stocke les coordonnées géographiques des musées
dans le format WKT12 (Well-known text). A l’aide du package
sf
, il est simple de construire des données géographiques
vectorielles permettant l’analyse spatiale avec R (Simple Features object
) à partir de ce
format de stockage. Pour cela, nous utilisons les fonctions
st_as_sfc
et st_as_sf
.
# Chargement du package sf, pour la gestion de données géographiques vectorielles
library(sf)
# Création d'objets géographiques ponctuels à partir des coordonnées stockées en WKT
geometry <- st_as_sfc(nb_oeuvres_musee$coords, crs = 4326)
# Création d'une couche géographique vectorielle (attributs des musées + géométries)
musee_geo <- st_as_sf(nb_oeuvres_musee, geometry)
La table de données a été transformée en couche géographique
manipulable avec R (objet sf
), où chaque musée comporte une
géométrie (point localisé dans l’espace, dans le système
géographique de référence WGS84).
Il est maintenant très simple de cartographier les points créés
(musées) sur une carte interactive, en utilisant le package
mapview
. Cela permet, entre autres, de vérifier la qualité
des données et du géoréférencement effectué.
# Package pour la cartographie interactive (repose sur la librairie Leaflet)
library(mapview)
# Affichage interactif des musées, sur un fond de carte OpenStreetMap
mapview(musee_geo)
4.1.4 Cartographie thématique
À partir des données collectées et pré-traitées, il est possible de construire une carte interactive en symboles proportionnels représentant le nombre d’œuvres de Johannes Vermeer exposées par musée au cours du temps.
# Package de cartographie thématique
library(tmap)
# Activation du mode de cartographie interactive
tmap_mode(mode = "view")
# Carte en symboles proportionnels
tm_basemap() +
tm_shape(musee_geo) +
tm_symbols(size="nb_oeuvres",
scale = 4,
col="red3",
border.col="white",
alpha =0.5,
border.lwd=0.1,
border.alpha=0.5,
id = "musees",
popup.vars=c("Nombre d'œuvres :"="nb_oeuvres" ))
4.1.5 Enrichissement des données
Au vue de la carte précédente, il semble intéressant d’explorer la répartition des œuvres de Johannes Vermeer à l’échelle des pays. Pour cela, il est nécessaire d’enrichir les données. Plusieurs étapes sont nécessaires :
Téléchargement d’un fond de carte pays mis à disposition par
le package rnaturalearth
:
# Package permettant d'utiliser l'API de Natural Earth
library(rnaturalearth)
# Téléchargement et enregistrement d'un fond de carte "pays"
monde <- ne_download(scale = "medium",
type = "countries",
category = "cultural",
destdir = "data/world",
load = TRUE,
returnclass = "sf")
Le fond de carte récupéré est également mis à disposition dans les données
téléchargeables. Vous pouvez le charger dans R à l’aide du package
sf
et de sa fonction st_read()
de la façon
suivante :
Affichage de la couche géographique :
Les attributs des entités (pays) de la couche géographique récupérée sont :
La couche géographique des musées (‘musee_geo’) et le fond de carte
du monde (‘monde’) sont géoréférencés dans le même système de
coordonnées13 (le WGS84).
Nous pouvons donc réaliser une jointure spatiale qui permet de récupérer pour
chaque musée, le code ISO3 du pays dans lequel il se situe. Pour
cela, nous utilisons la fonction st_intersection
du package
sf
.
Jointure spatiale entre les musées (points) et les pays (polygones) :
Le code ISO3 du pays de localisation (“ADM0_A3”) a été ajouté à la couche géographique des musées :
4.1.6 Répartition par pays
Le pays de localisation de chaque musée ayant été obtenu, nous pouvons réaliser une représentation graphique de cette distibution spatiale.
Commençons par calculer le nombre total d’œuvres exposées par pays :
Nous pouvons ensuite construire un graphique en utilisant le package
de référence ggplot2
.
# Graphique en barre - Nombre d'œuvres par pays
ggplot2::ggplot(data = nb_oeuvres_pays,
aes(x = reorder(ADM0_A3, -nb_oeuvres),
y = nb_oeuvres, fill = ADM0_A3)) +
geom_bar(stat = "identity") +
ggtitle("Nombre d'œuvres de Johannes Vermeer exposées, par pays") +
xlab("") +
ylab("") +
scale_fill_manual(values = c("#FC8D62", "#80B1D3" ,"#E78AC3",
"#A6D854","#FFD92F","#E5C494",
"#FB8072","#BEBADA","#66C2A5",
"#FFFFB3","#8DA0CB")) +
annotate(geom="text",
x = 9, y = 13,
label = "Une œuvre peut\navoir été exposée\ndans plusieurs pays" ) +
theme(legend.position = "none")
4.2 La ‘Dame assise au virginal’
Les données issues de la troisième requête SPARQL (‘data’) contiennent l’ensemble des localisations renseignées pour l’œuvre de Johannes Vermeer A Young Woman Seated at the Virginals (ou Dame assise au virginal en français). Nous allons donc réaliser un processus de nettoyage et de géoréférencement très semblable à celui de la partie précédente.
4.2.2 Géoréférencement
Géoréférencement des musées à partir de la variable ‘coord’ :
# Création d'objets géographiques ponctuels à partir des coordonnées stockées en WKT
geometry <- st_as_sfc(data$coord, crs = 4326)
# Création d'une couche géographique vectorielle (attributs des musées + géométries)
data_geo <- st_as_sf(data, geometry)
# Affichage des données
DT::datatable(data_geo)
Plusieurs musées, comme le Ashmolean Museum, apparaissent plusieurs fois dans la table car l’œuvre y a fait plusieurs séjours. Nous effectuons un regroupement des expositions par musée.
# Regroupement par musée - Calcul du nombre total d'expositions
nb_expos_musee_geo <- data_geo |>
group_by(musee) |>
summarise(nb_expos=n())
Il est facile d’afficher ces données géographiques ponctuelles sur un fond de carte dynamique, en améliorant cette fois-ci la mise en page des pop-ups contenant les attributs de chaque musée.
# Popup content
content <- paste0( "<img src='",
"http://commons.wikimedia.org/wiki/Special:FilePath/Vermeer%20-%20A%20young%20Woman%20seated%20at%20the%20Virginals.jpg",
"' width='180'><br /><b>",
nb_expos_musee_geo$musee,
"</b><br />Nombre d'expositions de l'œuvre : <b>",
nb_expos_musee_geo$nb_expos,
"</b>")
# Carte
mapview(nb_expos_musee_geo,
zcol = "musee",
col.regions = "red",
legend = FALSE,
popup = content,
map.types = "Esri.WorldImagery")
4.2.3 Enrichissement des données
De la même manière que dans la partie 4.1.5, nous enrichissons
ces données en obtenant le pays de localisation de chaque musée. Pour
cela, nous réalisons une jointure spatiale en utilisant la fonction
st_intersection
du package sf
.
On vérifie que le code ISO3 du pays a bien été collecté pour chaque point (musée).
5 Trajectoire spatio-temporelle
Nous allons mainenant prendre en compte la dimension temporelle des données collectées, c’est à dire la période d’exposition du tableau A Young Woman Seated at the Virginals dans chaque musée, comme renseigné dans Wikidata.
5.1 Période d’exposition du tableau
Pour manipuler facilement le temps, nous commençons par convertir les
dates d’arrivée et de départ de l’œuvre dans chaque musée en format de
type date
.
Il est ensuite simple de calculer le nombre de jours de présence dans un musée avec une soustraction. Nous sauvegardons ces valeurs (nombre de jours) dans une nouvelle colonne (‘duree’).
Le tableau a été exposé à deux reprises dans plusieurs musées. Nous calculons donc le nombre de jour total d’exposition du tableau par musée.
Plusieurs informations collectées peuvent être cartographiées. Voici
un exemple de carte interactive réalisée avec le package
tmap
, qui représente le nombre de jours d’exposition du
tableau au cours du temps, à l’échelle des musées.
# Activation du mode de cartographie interactive
tmap_mode(mode = "view")
# Construction d'une carte en symbole proportionnel
tm_basemap() +
tm_shape(data_musee) +
tm_bubbles("duree",
col = "ADM0_A3",
scale = 9,
border.col="white",
alpha = 0.7,
border.lwd=0.1,
border.alpha=0.5,
title.col="Pays d'exposition",
id = "musee",
popup.vars=c("Nombre total de jours :"="duree",
"Nombre total de séjours :"="nb_expos"))
5.2 Carte temporelle animée
La carte précédente ne permet pas de rendre compte de la trajectoire spatio-temporelle de l’œuvre. Une carte animée représentant la localisation de l’œuvre au cours du temps permettrait de formaliser son déplacement dans l’espace et dans le temps.
Pour cela, nous devons dans un premier temps choisir un pas de temps. La période de temps analysée est de presque 20 ans et le tableau peut avoir été exposé dans deux musées différents au cours d’un même mois. Nous choisissons donc de construire une carte animée réglée sur un pas de temps hebdomadaire, ce qui laissera le temps aux lecteur·rice·s de lire les informations affichées.
Un partir de ce pas de temps, nous créons un data.frame
où chaque ligne représente une semaine calendaire située entre le 8 mars
2001 et le 13 Janvier 2019 à l’aide de la fonction seq
.
Nous créons également des colonnes vides qui permettront de stocker
l’ensemble des informations de localisation de l’œuvre pour chaque
semaine.
data_semaine<- data.frame(semaine = seq(min(data_geo$dated), max(data_geo$datef), "week"),
musee = as.character(NA),
duree = as.integer(NA),
pays = as.character(NA),
geometry = NA)
Une boucle for
permet de parcourir le tableau et
d’obtenir les informations de localisation de l’œuvre si la date du
premier jour d’une semaine ciblée data_semaine$week[i]
est
située entre une date d’arrivée et de départ dans le tableau
data_geo
. Si c’est le cas, on inscrit les informations du
tableau data_geo
dans le tableau
data_semaine
.
for (i in 1:nrow(data_semaine)){
# Sélection des lignes où : Date d'arrivée <= week[i] <= Date de départ
temp <- data_geo[data_geo$dated <= data_semaine$semaine[i] & data_geo$datef >= data_semaine$semaine[i], c("musee", "duree", "ADM0_A3", "geometry")]
# Si une ligne est sélectionnée, on l'ajoute dans l'objet 'data_semaine'
if (nrow(temp)==1){data_semaine[i,2:5] <- temp}
}
Nous modifions ensuite les valeurs restées manquantes, pour les semaines où la peinture n’a pas été exposée.
data_semaine <- data_semaine |>
mutate(
# si musee non renseigné, remplace par "Emplacement inconnu"
musee=case_when(is.na(musee)~"Emplacement inconnu", TRUE~musee),
# si pays non renseigné, remplace par "pays ?"
pays=case_when(is.na(pays)~"pays ?", TRUE~pays),
# si duree non renseignée, remplace par 0
duree=case_when(is.na(duree)~0, TRUE~duree)
)
# Affichage du tableau
DT::datatable(data_semaine)
Bien que ce tableau possède une colonne geometry
, il
s’agit en fait d’un data.frame
. Nous le convertissons en
objet sf
(couche géographique).
Les données sont prêtes pour créer une carte animée qui représente la
localisation de l’œuvre pour chaque semaine calendaire de 2001 à 2019.
Pour cela, nous utilisons le package tmap
, son mode
plot
(cartographique statique), sa fonction
tm_facet
(génère plusieurs cartes en fonction d’une
variable) et sa fonction tmap_animation
pour créer une
carte animée en format vidéo.
# Cartographie en mode statique
tmap_mode(mode = "plot")
# Création d'une carte stockée dans l'objet CARTE
CARTE <- tm_shape(monde) + # Ajout fond de carte monde
tm_polygons(col = "grey70",
border.col = "grey60",
border.lwd = 0.2) +
tm_shape(data_semaine) + # Ajout des musées, mais...
tm_symbols(col = "red") +
tm_facets(along = "semaine", # Une carte / semaine grâce à tm_facet
free.coords= FALSE,
drop.units=FALSE) +
tm_layout(main.title ="", # Gestion du titre
panel.label.fontface = 2,
panel.labels = paste0("Semaine du ", format(x = data_semaine$semaine, format = "%d %b %Y" )),
bg.color="lightblue") +
tm_credits(bg.color = 'red', # Affichage Nom des musées et Nombre de jours d'exposition
width = 0.5,
position = c('center', 'bottom'),
text = paste0(data_semaine$musees," (",data_semaine$pays,")\n",data_semaine$duree, " jours d'exposition"),
size = 1.2,
fontface = "bold",
col = 'white',
align = 'center')
Avec la fonction tm_facet
, ce bout de code crée autant
de cartes qu’il y a de lignes dans le tableau
data_semaine
.
Il est ensuite très facile de convertir cet objet list
qui contient l’ensemble des cartes produites en fichier mp4 avec la
fonction tmap_animation
. Attention, la création
d’un GIF ou d’une vidéo peut prendre plusieurs minutes.
tmap::tmap_animation(tm = CARTE,
filename = "figures/peinture_en_voyage.mp4",
width=800,
height = 400,
fps = 10, # images par seconde
outer.margins = 0)
av
est nécessaire pour créer
des vidéos avec la fonction tmap_animation
. Cette fonction
permet également de créer des GIFs animés, mais il vous sera également
nécessaire d’installer le package gifski
pour profiter de
cette fonctionnalité .
Voilà le résultat !
6 Frise chronologique
Bien que la carte animée soit une représentation techniquement aboutie, elle ne transmet pas efficacement les informations sur la trajectoire spatio-temporelle du tableau de Johannes Vermeer au monde des musées. Une représentation statique et axée sur la dimension temporelle, comme une frise chronologique, nous semblerait plus appropriée.
Il existe des packages spécialisés dans la construction de frise
chronologique, comme par exemple vistime
. Cependant, afin de s’assurer
d’une certaine liberté pour la mise en forme de la frise, nous utilisons
le package ggplot2
pour concevoir et construire cette
représentation graphique.
6.1 Préparation des données
Une mise en forme des données est nécessaire pour construire ce type
de frise chronologique avec ggplot2
. Par exemple, le tri
des données est important pour gérer l’ordre d’apparition des individus
et des modalités sur le graphique.
Tri du tableau en fonction de la date (‘dated’) d’arrivée dans chaque musée.
Tri d’ordre d’apparition des modalités (levels) pour
les variables ‘nomLabel’ (= ‘musee’) et ‘ADM0_A3’ (= ‘pays’) que l’on
transforme en factor
.
# Tri des "levels" des musées en fonction de l'ordre d'apparition dans la table 'data_geo'
data_geo$musee <- ordered(as.factor(data_geo$musee), levels = unique(data_geo$musee))
# Tri des "levels" des pays en fonction de l'ordre d'apparition dans la table 'data_geo'
data_geo$pays <- ordered(as.factor(data_geo$ADM0_A3), levels = unique(data_geo$ADM0_A3))
Nous créons une nouvelle colonne qui sera utilisée comme étiquette dans le graphique. Dans cette colonne, les noms des musées n’apparaissent qu’une fois, uniquement pour la première exposition.
# Sélection des premières dates d'arrivée (si il en existe plusieurs) pour chaque musée
fisrt_expo <- data_geo[!duplicated(data_geo$musee), c("musee", "dated")]
# Suppression de la colonne géométrie pour réaliser une jointure
fisrt_expo <- st_drop_geometry(fisrt_expo)
# Jointure par la date d'arrivée - ajout de la colonne label (nomLabel.y)
data_geo <- merge(data_geo, fisrt_expo, by="dated", all.x=TRUE)
Tableau de données après traitement (extrait) :
6.2 Construction graphique
6.2.1 Utilisation des
fonctions ggplot()
et geom_segement()
Les variables utilisées pour l’axe des abscisses (x) et des ordonnées
(y) sont définies comme suit dans la fonction ggplot
:
- X = ‘dated’ : date d’arrivée dans le musée ;
- y = ‘musee.x’ : nom du musée (label unique).
La bibliothèque ggplot2
fonctionne avec une syntaxe
particulière (basée sur la grammaire graphique). Il est possible d’ajouter des
éléments de mise en forme du graphique au fur et à mesure.
Nous commençons par préciser le type de géometrie (ici
geom_segment
) et les variables à représenter :
- color = ‘ADM0_A3’ (code ISO3) : pays de localisation ;
- xend = ‘datef’ (date de fin) : limite du segment en x ;
- yend = ‘nomLabel.x’ (nom du musée) : limite du segment en y.
# Construction de 'segments' entre la date d'arrivée (dated) et de départ (datef)
ggplot2::ggplot(data_geo, aes(x = dated, y = musee.x, color = pays)) +
geom_segment(aes(xend = datef, yend = musee.x, color = pays), size = 6)
Nous assignons le résultat dans un objet :
6.2.2 Couleurs, étiquettes et thème
Maintenant que la base du graphique a été réalisée, nous pouvons procéder à l’amélioration de sa mise en forme en plusieurs étapes :
- ajout des labels avec la fonction
geom_text
; - modification de la palette de couleurs avec la fonction
scale_color_manual
;
Mon_graph <- Mon_graph +
# Ajout d'une étiquette pour chaque segment représenté
geom_text(aes(label = musee.y, hjust =1.05), size = 3.5, show.legend = FALSE) +
# Modification de la palette de couleurs (ADM0_A3)
scale_color_manual(values = c("#7570b3", "#e7298a", "#66a61e", "#e6ab02", "#a6761d","#1b9e77", "#d95f02"))
# Affichage du résultat
Mon_graph
Puis, à l’aide des fonctions scale_x_date
labs
et theme
:
- modification de l’axe des abscisses (intervalle des valeurs et étiquettes à afficher) ;
- ajout d’un titre et d’un sous-titre ;
- paramétrage de plusieurs éléments du ‘thème’ (repère, légende, axes, couleur de fond…).
Mon_graph <- Mon_graph +
# Modification de l'axe des abscisses
scale_x_date(date_labels = "%Y", date_breaks = "2 year", minor_breaks = "1 year",
limits = c(as.Date("1994-01-01"),as.Date("2019-01-13")) ) +
# Ajout d'un titre et d'un sous-titre
labs(title = "Le voyage d'un tableau de Johannes Vermeer",
subtitle = "Aux pays des musées, de 2001 à 2019") +
# Paramétrage du 'thème'
theme(panel.grid.major.y = element_blank(),
panel.grid.major.x = element_line(size = 0.2, colour = "#707073"),
panel.grid.minor.x = element_line(size = 0.2, linetype = 3, colour = "#707073"),
panel.border = element_blank(),
panel.background = element_blank(),
axis.text.y = element_blank(),
axis.text.x = element_text(size=8.5, colour = "#FFFFFF"),
axis.title = element_blank(),
rect = element_rect(fill = "#2a2a2b"),
legend.position = c(.93, .25),
legend.key = element_rect(fill = "#2a2a2b"),
legend.key.height = unit(0.4, 'cm'),
legend.background = element_rect(fill = "#2a2a2b"),
legend.margin = margin(0.5,1,1,1),
legend.title = element_blank(),
legend.text = element_text(colour = "#FFFFFF", size = 7),
title = element_text(colour = "#FFFFFF", hjust = 1, vjust = 0),
plot.margin=unit(c(1,1,0.5,1),"cm"))
Mon_graph
6.2.3 Finalisation de la mise en page
Pour terminer la mise en forme de cette frise chronologique,
l’illustration du tableau et son intitulé sont superposés au graphique.
Les bibliothèques jpeg
et patchwork
nous
permettent d’importer, puis d’insérer une image sur la représentation
graphique.
Import de l’image du tableau dans R
Superposition de l’image et de la représentation graphique
library(patchwork)
Mon_graph +
# Titre de l'image
annotate("text",
x = as.Date("1997-03-01"),
y = 7,
colour = "#FFFFFF",
size = 3.4,
label = "Young Woman Seated\nat a Virginal (1670)") +
# Insertion de l'image
inset_element(p = img,
clip = TRUE,
left = 0.04,
right = 0.27,
top = 0.95,
bottom = 0.46)
7 À vous d’explorer !
Nous vous proposons d’explorer vous-mêmes le contenu des données
Wikidata. Le bout de code ci-dessous peut être adapté à n’importe
quel·le artiste peintre renseigné·e dans Wikidata. Il suffit de
modifier l’identiant de l’artiste assigné·e dans l’objet
ID
et son nom dans l’objet NOM
.
Vous pouvez retrouver l’identifiant Wikidata d’un·e artiste peintre sur la page Wikidata. Indiquez le nom de l’artiste peintre dont vous souhaitez localiser les œuvres dans le champ de recherche. Veillez à bien récupérer l’identifiant correspondant à l’entité ‘artiste’.
7.1 Code reproductible
Voici quelques exmples d’artistes peintres que vous pouvez requêter :
- Salvador Dalí Q5577 ;
- Nandalal Bose Q3348980 ;
- Kalervo Palsa Q320590 ;
- Katsushika Hokusai Q5586 ;
- Edvard Munch Q41406 ;
- Pablo Picasso Q5593.
#-------------------------------------------------------------------------------------------------#
# #
# Exploration spatio-temporelle #
# de l'exposition des œuvres de ??? #
# Selon Wikidata #
# #
#-------------------------------------------------------------------------------------------------#
#--------------------------------------- PACKAGES NECESSAIRES ------------------------------------#
# install.packages("WikidataQueryServiceR")
# install.packages("sf")
# install.packages("rnaturalearth")
# install.packages("ggplot2")
# install.packages("tmap")
######################################### CHOIX DE L'ARTISTE ######################################
ID <- "Q5593"
NOM <- "Pablo Picasso"
#---------------------------------------------- REQUETE ------------------------------------------#
# Construction de la requête SPARQL avec l'identifiant (ID) indiqué
library(WikidataQueryServiceR)
# Sélectionner les noms des oeuvres et musées et leurs coordonnées telles que
# {
# l'oeuvre a pour peintre l'entité peintre ; # chemin principal
# en option
# {
# l'oeuvre est localisée dans un musee . # chemin optionnel
# ce musée a pour localisation les coordonnées # chemin optionnel
# }
# en langue française et anglaise
# }
entite_peintre <- paste0("wd:",ID)
query <- "SELECT ?oeuvreLabel ?museeLabel ?coord WHERE \
{\
?oeuvre wdt:P170",entite_peintre," . \
OPTIONAL \
{\
?oeuvre wdt:P276 ?musee . \
?musee wdt:P625 ?coord \
}\
SERVICE wikibase:label \
{\
bd:serviceParam wikibase:language \"[AUTO_LANGUAGE], fr,en \".\
}\
}"
my_data <- query_wikidata(query)
#----------------------------------------- NETTOYAGE DONNEES -------------------------------------#
# Suppression des doublons
my_data <- my_data[!duplicated(my_data$oeuvreLabel), ]
# Suppression entités (musées et institutions) sans coordonnées renseignées
my_data <- my_data[!is.na(my_data$coord), ]
DT::datatable(my_data)
#-------------------------------------- REGROUPEMENT PAR MUSEE -----------------------------------#
nb_oeuvre <- aggregate(oeuvreLabel ~ coord + museeLabel, data = my_data, FUN = length)
colnames(nb_oeuvre)[3] <- "nb_oeuvre"
#----------------------------------------- GEOREFERENCEMENT --------------------------------------#
# Chargement de la librairie sf
library(sf)
# Création d'objets géographiques ponctuels à partir des coordonnées stockées en WKT
geometry <- st_as_sfc(nb_oeuvre$coord, crs = 4326)
# Création d'une couche géographique vectorielle (attributs des musées + géométries)
nb_oeuvre_by_museum <- st_as_sf(nb_oeuvre, geometry)
#------------------------------- ENRICHISSEMENT - JOINTURE SPATIALE -----------------------------#
#### Import de la couche géographique des pays
library(rnaturalearth)
monde <- ne_download(scale = "medium",
type = "countries",
category = "cultural",
destdir = "data/world",
load = TRUE,
returnclass = "sf")
#### Jointure spatiale
nb_oeuvre_by_museum <-st_intersection(nb_oeuvre_by_museum , monde[,"ADM0_A3"])
#---------------------------------- GRAPHIQUE NOMBRE ŒUVRES PAR PAYS ----------------------------#
#### Regroupement par pays
by_country <- aggregate(nb_oeuvre ~ ADM0_A3 , data = nb_oeuvre_by_museum, FUN = sum)
#### Graphique
library(ggplot2)
ggplot(data = by_country, aes(x = ADM0_A3, y = nb_oeuvre) ) +
geom_bar(stat="identity") +
ggtitle(paste0("Nombre d'œuvres de ", NOM ,", par pays")) +
xlab("") +
ylab("") +
theme(legend.position = "none",
axis.text.x = element_text(size=8),
axis.text.y = element_text(size=11))
#----------------------------- CARTOGRAPHIE - NOMBRE ŒUVRES PAR MUSEE ---------------------------#
library(tmap)
tmap_mode(mode = "view")
tm_shape(nb_oeuvre_by_museum) +
tm_symbols(size="nb_oeuvre",
scale = 2,
col="red3",
border.col="white",
alpha =0.5,
border.lwd=0.1,
border.alpha=0.5,
title.size = "Nb d'œuvres",
id = "museeLabel",
popup.vars=c("Nombre d'œuvres"="nb_oeuvre"))
7.2 Données et graphiques produits
Voici un exemple des données et graphiques produits avec l’artiste peintre et graveur norvégien Edvard Munch, ayant pour identifiant Wikidata : Q41406.
Dans un premier temps, le code permet de collecter l’ensemble des œuvres créees par l’artiste, ainsi que leurs localisations associées via une requête SPARQL. Voici par exemple les données collectées pour Edvard Munch :
Les données sont ensuite nettoyées des doublons et des œuvres qui ne sont jamais associées à des coordonnées géographiques précises, puis regroupées par musée :
Les musées sont alors géoréférencés, ce qui permet de réaliser une jointure spatiale avec une couche géographique des pays, et ainsi d’obtenir leur pays de localisation. Le code produit également une représentation graphique de la répartition des expositions des œuvres par pays :
Enfin, le code construit une carte interactive représentant le nombre d’œuvres exposées par musée :
8 Conclusion - Enjeux interdisciplinaires
L’exemple de visualisations (distant reading) d’une trajectoire spatio-temporelle en histoire à partir de données collectées sur Wikidata propose ainsi de questionner les données utilisées (non supervisées).
Notamment la circulation de l’œuvre choisie fait apparaître des espaces spatio-temporels où celle-ci n’est pas localisée dans un lieu d’exposition. Ce constat engage à ré-interroger les données et le modèle associé.
Par exemple, l’étude de la relation de la donnée
Q4660880
avec la “Leiden Collection” conduit à identifier 2
relations différentes. La requête ci-dessous précise celles-ci, qui sont
les propriétés P276
et P195
, cette dernière
correspondant à “collection”. L’instance “Leiden Collection” se trouve
donc au sein de deux classes de Wikidata, lieu et collection.
relations <- spq_init() |>
spq_add("wd:Q4660880 ?p ?o .") |>
spq_add("?o rdfs:label ?olabel") |>
spq_filter(str_detect(str_to_lower(olabel),"leiden")) |>
spq_filter(lang(olabel) == "en") |>
spq_perform()
DT::datatable(relations)
En interrogeant alors la provenance de l’information collectée de Wikidata, c’est à dire la source fournie (ou non) par le ou la contributrice, les résultats peuvent étonner par leur degré de précision.
query <- "SELECT ?url ?dated ?datef WHERE \
{ \
wd:Q4660880 p:P195 ?declaration . \
OPTIONAL { \
?declaration pq:P580 ?dated . \
?declaration pq:P582 ?datef . \
} \
?declaration prov:wasDerivedFrom ?ref . \
?ref pr:P854 ?url \
} "
ref_coll <- WikidataQueryServiceR::query_wikidata(query)
ref_coll
# A tibble: 1 × 3
url dated datef
<chr> <lgl> <lgl>
1 https://rkd.nl/explore/images/62857 NA NA
query <- "SELECT ?url ?dated ?datef WHERE \
{ \
wd:Q4660880 p:P276 ?declaration . \
?declaration pq:P580 ?dated . \
?declaration pq:P582 ?datef . \
?declaration prov:wasDerivedFrom ?ref . \
?ref pr:P854 ?url \
} \
ORDER BY (?dated)"
ref_loc <- WikidataQueryServiceR::query_wikidata(query)
DT::datatable(ref_loc)
En effet, la référence Wikidata associée à la collection est le lien hypertexte de l’institut néerlandais d’histoire de l’art, faisant état des transferts de propriété de l’œuvre étudiée. La référence Wikidata associée à la valeur de la propriété de localisation indique un jeu de données temporelles où l’œuvre serait localisée au sein de la collection elle-même (à New-York). Reste à vérifier la cohérence de ces laps de temps (souvent courts) du retour de l’œuvre à New-York avec ses voyages dans les musées du monde entier…
Il est aussi possible ainsi de poursuivre la naviguation dans le corpus de Vermeer ou d’autres, au sein d’un web de données alimenté par de nombreuses communautés.
Le notebook sert de support du dialogue entre plusieurs
disciplines, ici, l’histoire, la géographie et l’ingénierie des
connaissances. Le notebook est aussi le lieu d’un processus
collaboratif productif de connaissances (synchrone ou asynchrone),
devient un outil pédagogique - par la formation par la recherche grâce à
sa transformation en fiche rzine
et est susceptible de
servir de méthodologie (ou “fil directeur”) reproductible d’un processus
similaire pour d’autres problématiques.
Bibliographie
Annexes
Info session
setting | value |
---|---|
version | R version 4.3.2 (2023-10-31) |
os | Debian GNU/Linux 12 (bookworm) |
system | x86_64, linux-gnu |
ui | X11 |
language | (EN) |
collate | fr_FR.UTF-8 |
ctype | fr_FR.UTF-8 |
tz | Europe/Paris |
date | 2024-01-31 |
pandoc | 3.1.1 @ /usr/lib/rstudio/resources/app/bin/quarto/bin/tools/ (via rmarkdown) |
package | ondiskversion | source |
---|---|---|
dplyr | 1.1.4 | CRAN (R 4.3.2) |
DT | 0.31 | CRAN (R 4.3.2) |
ggplot2 | 3.4.4 | CRAN (R 4.3.2) |
glitter | 0.2.999 | https://lvaudor.r-universe.dev (R 4.3.2) |
jpeg | 0.1.10 | CRAN (R 4.3.2) |
mapview | 2.11.2 | CRAN (R 4.3.2) |
patchwork | 1.2.0 | CRAN (R 4.3.2) |
sf | 1.0.15 | CRAN (R 4.3.2) |
tmap | 3.3.4 | CRAN (R 4.3.2) |
WikidataQueryServiceR | 1.0.0 | CRAN (R 4.3.2) |
WikidataR | 2.3.3 | CRAN (R 4.3.2) |
Citation
KRUMMEICH R, PECOUT H, REY-COYREHOURCQ S (2022). “Spatio-temporal, Wikidata, exploration de données collaboratives du web 3.0.”, doi:10.48645/xxxxxx https://doi.org/10.48645/xxxxxx,, https://rzine.fr/publication_rzine/xxxxxxx/.
BibTex :
@Misc{,
title = {Spatio-temporal Wikidata, exploration de données collaboratives du web 3.0},
subtitle = {Histoire de cadre : élaboration d’une trajectoire spatio-temporelle},
author = {Raphaëlle KRUMMEICH and Hugues PECOUT and Sébastien REY-COYREHOURCQ},
doi = {10.48645/xxxxxx},
url = {https://rzine.fr/publication_rzine/xxxxxxx/},
keywords = {FOS: Other social sciences},
language = {fr},
publisher = {FR2007 CIST},
year = {2022},
copyright = {Creative Commons Attribution Share Alike 4.0 International},
}
Glossaire
DBpedia est une ontologie permettant de traduire Wikipedia en dépôts de données définis dans le cadre de description des ressources du standard Ressources Description Framework (RDF) du World Wide Web Consortium1 (W3C)↩︎
Le terme de curation est un anglicisme désignant une activité de type archivistique ou de conservation muséale ou patrimoniale qui a pour objectif de décrire et de classer des objets pour les conserver et les rendre accessibles, le cas échéant. Le terme est issu du domaine médical au sens de prendre soin en opérant une stratégie curative. La curation de données peut-être décrite comme une activité de description d’une donnée ou plus précisément d’une ressource du web au moyen de métadonnées, c’est à dire de produire des données sur des données. Cette activité s’appuie en général sur des normes ou des règles de l’art des divers métiers. Dans le champ du catalogage informatique, une des plus anciennes normes est le Dublin Core.↩︎
Le Web de données (linked data, en anglais) est une initiative du World Wide Web Consortium3 visant à favoriser la publication de données structurées sur le Web, non pas sous la forme de silos de données isolés les uns des autres, mais en les reliant entre elles pour constituer un réseau global d’informations.↩︎
Le World Wide Web Consortium (W3C) est un organisme de standardisation à but non lucratif fondé en 1994 et chargé de promouvoir la compatibilité des technologies du Web↩︎
Un triplet est un groupe formé par trois éléments dont chacun appartient à un ensemble distinct.↩︎
Un URI (Uniform Resource Identifier, en français Identifiant unique de ressource) est une chaîne qui fait référence à une ressource. Les plus courantes sont les URL, qui identifient une ressource en donnant son emplacement sur le Web. Au contraire, les URN font référence à une ressource grâce à son nom, dans un environnement donné, par exemple le code ISBN d’un livre.↩︎
SPARQL est acronyme récursif qui signifie SPARQL Protocol And RDF Query Language (Wikipédia (2022)). Plusieurs langages de requête destinés à interroger les graphes RDF ont été développés, mais le langage SPARQL est développé par le W3C de sorte à devenir un standard.↩︎
Un préfixe est une modalité de simplification d’écriture faisant référence à un espace de noms (qui est une page HTML ou un fichier Turtle par exemple), voir notamment https://www.w3.org/wiki/TheUsualPrefixes↩︎
WikidataR
est développé par Thomas Shafee, Os Keyes, Serena Signorelli, Alex Lum, Christian Graul et Mikhail Popov (développeur deWikidataQueryServiceR
), membre de la Fondation Wikimédia. Il est maintenu par Thomas Shafee de l’université australienne La Trobe de l’état Victoria.↩︎Le service de collecte des données de Wikidata en langage SPARQL offre une solution très complète en première approche (exemples, assistant de requêtes, diversité des représentations etc.). Toutefois, dans une dynamique d’exploration du graphe Wikidata, l’utilisation de R facilite la compréhension, l’archivage et la reproductibilité des différentes requêtes spécifiques réalisées. Pour cette raison, nous utilisons le package
WikidataR
ou alternativementWikidataQueryServiceR
qui est un package ayant des fonctionnalités plus développées.↩︎Le géoréférencement est l’un des principes fondamentaux des systèmes d’information géographiques (SIG) et de la cartographie assistée par ordinateur (CAO). Un objet géographiques est référencé lorsque l’on lui attribut une localisation (coordonnées géographiques) et une forme (géométrie : point, ligne ou surface).↩︎
Le format Well-known text, abrégé en WKT, peut se traduire par « texte bien lisible ». C’est un format standard en mode texte utilisé pour représenter des objets géométriques vectoriels issus des systèmes d’informations géographiques (SIG), mais aussi des informations s’y rattachant, tels les références de systèmes de coordonnées.↩︎
Un système de coordonnées est un référentiel dans lequel on peut représenter des éléments dans l’espace. Ce système permet de se situer sur l’ensemble du globe terrestre grâce à un couple de coordonnées géographiques.↩︎