En dépit de critiques récurrentes, on trouve des informations très utiles sur l’encyclopédie en ligne Wikipédia. Et, à condition de savoir les lire (i.e. de pratiquer la critique des sources), elle peut constituer une mine d’or pour les chercheurs. D’aileurs, vous pourriez y contribuer, ou contribuer.
Comment faire pour collecter automatiquement ces informations ? De la même manière qu’on l’a déjà fait, mais le site impose de respecter certaines règles. Examinon-les en repartant de l’exemple des édifices religieux à Paris, traité dans un précédent billet. Cette fois, on s’intéresse au culte musulman.
L’exemple des lieux de culte musulman à Paris
Parmi les différents sites qui répertorient lieux du culte musulman à Paris, Wikipédia semble bien renseigné. Une rapide consultation montre une liste d’environ 75 sites, qu’on va récupérer afin de pouvoir la traiter (statistiques, visualisation), ou la sauvegarder. Assurément, on n’est pas en mesure de dire si elles sont fréquentées, toujours actives, ou si la liste est complète (mais des gens ici ou là ont sûrement une idée – ainsi que l’administration française, comme le montrait la thèse de S. Jouanneau).
Et on peut remarquer au passage une distinction qu’on ne retrouve pas chez d’autres groupes religieux plus établis : plus de la moitié des endroits recensés sont des “simples” salles de prières, et pas des édifices spécifiquement religieux (ce qui a sûrement trait à la croissance différentielle des groupes religieux, comme à leur histoire).
Sur Wikipédia, les données sont souvent présentées sous forme de tableaux. Ceux-ci sont décrits par une balise <table> dans le code source. Dans ce cas, leur extraction est très simple, grâce à la fonction readHTMLTable (présentée ici également), que l’on va utiliser.

Le premier “tableau” de la page est la table des matières de l’article, donc on s’intéresse au deuxième (mosquées), et au troisième (salles de prière). La fonction readHTMLTable peut s’utiliser directement avec l’URL (l’adresse) de la page, dans ce cas on extrait les tableaux comme ceci :
# Modules
library(RCurl)
library(XML)
# Adresse de la page Wikipédia
lieux.islam.url <-
"http://fr.wikipedia.org/wiki/Liste_des_mosqu%C3%A9es_de_Paris"
# Récupération directe des tableaux
lieux.islam.tableaux <- readHTMLTable(lieux.islam.url)
mosquees <- lieux.islam.tableaux[[2]]
salles.priere <- lieux.islam.tableaux[[3]]
Si on vérifie le contenu de salles.priere, on peut vérifier que ça fonctionne. Reste un problème d’accents, qui se traduit par des choses comme \u0080 (Mac OS) ou des caractères bizarres (Windows) et des avertissements ésotériques comme “it is not known that wchar_t is Unicode on this platform”. Il s’agit d’un malentendu d’encodage, c’est-à-dire d’interprétation des caractères accentués – qu’on traitera en détail prochainement .
Pour y remédier, on va adopter une procédure légèrement plus longue. Cela va nous permettre également de se conformer aux conditions d’utilisation de Wikipédia, et plus généralement aux bonnes pratiques de collecte automatique de données.
Collecter, à quelles conditions ?
Collecter automatiquement des données peut être grisant, mais il ne faut pas oublier que l’opération peut être coûteuse pour l’hébergeur (en termes de bande passante, donc d’infrastructures matérielles), et que le droit protège la propriété des données : ce n’est pas parce que vous pouvez les consulter qu’elles sont à vous. Les sites peuvent, au-delà du droit, se protéger par divers outils techniques. Certains vous bloqueront l’accès en cas de non-respect des conditions d’utilisation ; il est donc vivement conseillé de lire celles-ci pour savoir ce que vous êtes autorisé à faire, et comment.
Chez Wikipédia, les données sont librement accessibles, aux conditions des licences Creative Commons et GNU Free Documentation License : en gros, citer vos sources, ne pas en faire un usage commercial, etc. (un peu comme pour ce blog). Concernant la collecte automatisée de données, la règle veut qu’on se présente, qu’on donne les moyens au webmaster de vous contacter par email, et qu’on évite de revenir trop régulièrement. À défaut, l’accès vous sera bloqué après quelques requêtes. On va donc utiliser des fonctions qui permettent de charger des pages web tout en envoyant nos coordonnées au serveur.
Pour cela, et toujours avec R, on prend un chemin découpé en plusieurs étapes. Les fonctions de très “haut niveau”, c’est-à-dire qui font beaucuop d’opérations complexes en une seule fois, ne permettent en effet pas toujours de contrôler assez finement la communication avec le serveur. Notre programme commence donc par la préparation d’une ligne, appellée User-Agent, qu’on envoie au serveur pour lui signaler notre identité (personnelle et logicielle) lorsqu’on lui demande une page .
Ici, cette ligne est de la forme “RCurl (mon.adresse@moi.net)”, RCurl étant le “navigateur” qu’on utilise. On la communique comme ceci :
# Modules utilisés ici
library(RCurl)
library(XML)
# Adresse (URL) de la page
lieux.islam.url <-
"http://fr.wikipedia.org/wiki/Liste_des_mosqu%C3%A9es_de_Paris"
# Identifiant que l'on envoie à Wikipedia pour se présenter
# À remplacer par votre email !
mon.adresse.mail <- "mon.adresse@moi.net"
# Assemblage du message qui va être envoyé
identifiant <- paste("RCurl", " (",
mon.adresse.mail, ")",
sep="")
# Requête
page.brute <- getURL(url = lieux.islam.url,
useragent = identifiant)
# On traite ensuite cet objet, pour en analyser la structure
page.lignes <- readLines(tc <- textConnection(page.brute))
close(tc)
page.parsed <- htmlTreeParse(page.lignes,
useInternalNodes=TRUE,
asText=TRUE)
La variable page.brute est le contenu de la page web chargée, en HTML. On la transforme en lignes (page.lignes), puis on analyse sa structure (parse). On pourra ensuite appliquer la fonction de lecture simplifiée des tableaux vue précédemment. Mais avant cela on va enlever les accents du texte.
Enlever les accents
L’intérêt de cette procédure est d’avoir un contrôle fin sur les opérations de téléchargement et de transformation de la page web. En particulier, on va pouvoir enlever les accents du texte, ce qui évitera toute confusion d’encodage .
On utilise ici une fonction que l’on a détaillée ailleurs, et que l’on appelle Unaccent().
Le moment le plus propice pour appliquer cette fonction, dans les opérations traitement de la page, est lorsqu’elle est sous forme de lignes, à l’étape page.lignes. Les accents (ou plutôt l’encodage) sont à ce moment correctement traités.
Le programme intégral
On reprend ainsi les morceaux présentés plus haut. Au passage, on englobe les opérations dont le résultat ne nous intéresse pas dans une fonction, ce qui évite de les garder en mémoire.
# Modules utiles
library(RCurl)
library(XML)
# Adresse (URL) de la page
lieux.islam.url <-
"http://fr.wikipedia.org/wiki/Liste_des_mosqu%C3%A9es_de_Paris"
# Identifiant que l'on enverra à Wikipedia pour se présenter
# À remplacer par votre email !
mon.adresse.email <- "mon.adresse@moi.net"
# Définition d'une fonction d'enlèvement des accents (et des '`^")
Unaccent <- function(text) {
text <- gsub("['`^\"]", " ", text)
text.unac <- iconv(text, to="ASCII//TRANSLIT")
text.unac <- gsub("['`^\"]", "", text.unac)
return(text.unac)
}
# Fonction de téléchargement, enlèvement des accents,
# et analyse (parsing) de la structure HTML
GetUnaccentURL <- function(url.page, email='') {
identifiant <- paste("RCurl", " (",
email, ")",
sep="")
page.brute <- getURL(url = url.page,
useragent = identifiant)
page.lignes <- readLines(tc <- textConnection(page.brute))
close(tc)
page.lignes.unac <- Unaccent(page.lignes)
page.parsed <- htmlTreeParse(page.lignes.unac,
useInternalNodes=TRUE,
asText=TRUE)
return(page.parsed)
}
# Téléchargement de la page sur les lieux de culte musulman
lieux.islam <- GetUnaccentURL(url.page = lieux.islam.url,
email = mon.adresse.email)
# Extraction des tableaux
mosquees <- readHTMLTable(lieux.islam, which=2)
salles.priere <- readHTMLTable(lieux.islam, which=3)
Et voilà !
On peut maintenant cartographier ces résultats : il suffit de géocoder les adresses obtenues.

La distribution géographique apparaît clairement localisée dans l’Est parisien, soit les quartiers les moins bourgeois de la capitale ; plus le quinzième arrondissement. Les salles de prière sont globalement situées dans les mêmes quartiers que les mosquées, mais avec de fortes variations.
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
11 commentaires »
Billet écrit par B. Coulmont, A. Hobeika et É. Ollion, et publié conjointement sur http://coulmont.com et http://data.hypotheses.org
Dans un récent article (PDF), West (un biologiste, pas la sociologue du genre) et ses collègues montraient à partir des articles de JSTOR que si le sex-ratio évolue sensiblement au cours des dernières décennies, l’égalité n’est pas encore de mise entre hommes et femmes dans les publications. Ils soulignaient en particulier que les hommes sont toujours sur-représentés dans des positions de prestige (premier et dernier auteur).
Qu’en est-il en France ? Partant d’une base des revues de sciences sociales françaises compilée par A. Hobeika et E. Ollion dans le cadre d’une recherche en cours sur l’histoire de la discipline par ses publications[1], on obtient une image de la sociologie dans le temps.
D’un point de vue global, au cours des années soixante aux années quatre-vingt-dix, la féminisation progresse, mais très lentement : 81% des auteurs sont des hommes dans les années 1960, ils ne sont plus que 71% dans les années 1990[2].


La féminisation est aussi très inégale suivant les revues. Certaines (Archives de sciences sociales des religions, Économie et statistique, Population) voient la part des auteures féminines augmenter substantiellement, alors que d’autres restent des bastions masculins (comme les Actes de la recherche en sciences sociales et la Revue française de sociologie)[3].

Déterminer le sexe des auteurs à partir de leurs prénoms ?
Pour établir le sexe des auteurs, nous nous sommes appuyés sur leur prénom, méthode utilisée par West (cité plus haut) ou par Carrasco pour retrouver le sexe des pacsés [Carrasco V., 2007. — « Le pacte civil de solidarité : une forme d’union qui se banalise ». Infostat justice, 97 pp. 1–4.]
Mais quand on cherche à inférer le sexe du prénom, plusieurs méthodes sont possibles.
La première consiste à faire ce codage manuellement : la familiarité avec la discipline permet de savoir que Claude Poliak n’a pas le même sexe que Claude Dargent, que Dominique Méda et Dominique Wolton non plus. Mais c’est très chronophage.
Parmi les techniques de codage automatique, deux autres sont possibles. On peut établir une liste de prénoms indiscutablement sexués (Baptiste, Yvette, Émile) à partir d’annuaires, et leur attribuer une valeur (M/F ou 0/1), laissant indéterminés les prénoms épicènes. Toutefois, si on dispose du fichier des prénoms (INSEE), une autre possibilité est d’associer à chaque prénom un score (de féminité, de masculinité) en fonction de son usage social : ainsi 99,95% des Catherine, au XXe siècle en France, ont été déclarées à la naissance comme étant du sexe féminin ; ce chiffre est de 0,08% pour les Simon. Les Dominique sont à 41% des filles, les Claude le sont à 12%, etc. Utiliser cette méthode revient donc à supposer que les prénoms des sociologues ont la même fréquence d’utilisation pour des hommes/femmes que dans la société française toute entière, ce qui semble raisonnable.
On a ici mené un test de ces méthodes, en recodant manuellement le sexe des auteurs pour une revue, la Revue Française de Sociologie. On compare les résultats à ceux des deux autres procédures. Pour la période 1960-1999, le nombre d’articles de cette revue dans notre base est de 1723. En excluant ceux pour lesquels aucun auteur n’est mentionné[4], on a in fine 1329 prénoms.
Les trois méthodes donnent sensiblement le même résultat, malgré des nombres de cas différents sur lesquels elles butent (« NA méthode » ci-dessous). Avec 17 prénoms non-détectés seulement (parfois répétés, d’où les 28 NA), le fichier des prénoms (INSEE) apparaît comme une solution à la fois commode et efficace pour un traitement automatisé tel que celui qu’on vient de faire[5].
|
Codage manuel |
Liste restreinte de prénoms |
Fichier des prénoms |
| Homme |
79.08 |
78.64 |
78.67 |
| Femme |
20.92 |
21.35 |
21.33 |
| Nb. individus |
1329/1723 |
1063/1723 |
1301/1723 |
| Infos manquantes |
394 |
394 |
394 |
| NA méthode |
0 |
266 |
28 |
Des chiffres sur la situation dans la sociologie étasunienne, calculés avec des méthodes similaires, sont disponibles chez Neal Caren et chez Philip Cohen.
Et ci-dessous le graphique avec l’ensemble des revues de sociologies prises en compte dans l’analyse (cliquer pour agrandir).

[1] Elle recense les publications dans les revues de sociologie française depuis les années 1960 (articles et symposiums, mais pas compte-rendus). La base est organisée par signatures : chaque ligne désigne un auteur et un article (par exemple, Bourdieu P. & Wacquant L. 1999 donne lieu à deux lignes dans la base : une pour chaque auteur).
[2] La base recense plus de 20 000 articles et comptes-rendus dans une vingtaine de journaux : Agora, Actes de la Recherche en Sciences Sociales, Archives de Sciences Sociales des Religions, Critique internationale, Déviance et société, Espace population et sociétés, économie et statistiques, Genèses, Pôle Sud, Politix, Population, Réseaux, la Revue Française de Sociologie, Sociétés contemporaines, Sociologie et santé, Tiers-Monde. Elle s’appuie largement sur les données du site Persée, complétées ponctuellement pour les revues qui en sont absentes.
[3] Dont B. Lahire disait récemment qu’elles étaient « les deux revues françaises de sociologie les plus académiques »).
[4] Soit il n’y en avait pas, soit on n’a pas réussi à le dissocier du nom dans les rares cas où les deux n’étaient pas clairement séparés. C’est une limite de ce traitement complètement automatisé, même si on a de bonnes raisons de penser que cela ne change rien aux résultats présentés ici.
[5] Si les prénoms sont à l’avenir plus épicènes, alors cette méthode pourrait s’avérer problématique. Elle l’est parfois entre pays, Jean Leca n’étant pas du même sexe que Jean Comaroff.
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
3 commentaires »
En travaillant dans un langue autre que l’anglais, on est souvent amené à fréquenter des caractères exotiques: lettres munies d’accents (é), tildes (ñ), ronds (Å) et autres barres (ø) – sans compter les formes non-latines (de ∆ à भैं, en passant par ش). Mais comme l’informatique moderne a été développée avec des claviers étasuniens, leur traitement ne va pas sans difficultés.
Des procédures standardisées, dites d’encodage, permettent d’utiliser ces caractères dans des textes ou des bases de données. Toutefois, dans le cas du français, le plus simple est bien souvent d’enlever les accents, si bien sûr on ne perd pas d’information cruciale au passage.
R permet d’effectuer cette opération, grâce à la fonction iconv munie d’une option de translittération : é est ainsi transformé en ´e, par exemple. On enlève ensuite les apostrophes (et équivalents) pour compléter la procédure de désaccentuation. Pour le faire de manière systématique, on définit la fonction suivante:
Unaccent <- function(text) {
text <- gsub("['`^~\"]", " ", text)
text.unac <- iconv(text, to="ASCII//TRANSLIT")
text.unac <- gsub("['`^~\"]", "", text.unac)
return(text.unac)
}
Il suffit d’exécuter ces quelques lignes au début d’un script R et cette fonction Unaccent devient disponible pour toute la suite de votre programme. Trois remarques:
- Elle ne fonctionne que pour les caractères latins.
- Les apostrophes et guillemets anglais sont également évacués, et remplacés par des espaces.
- Vous venez de créer une fonction en R, un outil très utile qui permet d’empaqueter un ensemble d’instructions (éventuellement long) plutôt que de les réécrire à chaque fois.
Son utilisation donne ainsi :
> Unaccent("à é î ø ü ç ß ñ ƒ")
[1] "a e i o u c ss n f"
> Unaccent("∆")
[1] NA
> Unaccent("J'ai dévoré les Grundriße")
[1] J ai devore les Grundrisse
Il est possible de travailler en gardant les caractères accentués et/ou non-latins, mais cela nécessite d’être soigneux dans la manipulation des encodages, voire des expressions régulières. Ces sujets, assez techniques, seront abordés prochainement. Mais si vous pouvez y échapper, profitez-en !
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
3 commentaires »
10 février 2013 |
étienne
Après une période période pionnière, les sciences sociales de l’”internet” connaissent une croissance rapide. Ce mois-ci, plusieurs publications ou événements montrent la structuration rapide de ce sous-champ émergent.
Conférence
La conférence Penser l’écosystème des données, sur les enjeux de la libération des données, aura lieu toute la journée du 14 février à Paris. Elle réunira de nombreux chercheurs de SHS intéressés à la production et aux usages multiple des informations numériques. Interdiscipinaire, la conférence est aussi internationale et promet d’être riche. À ne pas rater (attention, il faut s’inscrire).
Manuel
Ce Manuel d’analyse du web, ouvrage collectif dirigé par C. Barats (Paris-V), propose une série d’analyses sur le web pour les chercheurs en sciences sociales. Les différentes contributions, rédigées par des spécialistes français du domaine, montrent bien le double objectif de l’ouvrage. Il s’agit en effet de présenter des outils et des méthodes d’analyse du web, mais tout autant de prendre internet et ses usages comme objets.
Une première partie présente certains enjeux théoriques, mais aussi méthodologiques. Une section méthode est elle consacrée à différentes techniques d’analyses du web (textométrie, sémiologie, et ethnographie). Les contributions de la dernière partie présentent elles des méthodes d’approche plus quantitatives des usages du web. Les contributions, courtes, rendent la lecture facile et permettent de naviguer facilement dans l’ouvrage. Par ailleurs, des encadrés complètent les textes en informant, au-delà de la réflexion méthodologique, sur les outils concrets disponibles.
Revue
Enfin, on peut mentionner la naissance de la revue en ligne RESET, explicitement consacrée aux Recherches en Sciences Sociales sur l’Internet. Les appels à contributions pour les numéros à venir montrent le spectre large couvert par la revue : famille, troubles mentaux et jeux en ligne, etc. Le premier numéro traite d’internet et classes sociales, avec là aussi une grande variété : pratiques numériques des adolescents, ségrégation spatiale, et même un texte sur Bourdieu et les rencontres en ligne (plutôt La distinction 2.0 que l’e-Bal des célibataires).
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
Pas de commentaire »
22 janvier 2013 |
étienne
Comment faire pour représenter des données dont on connaît l’adresse ? Si on veut les cartographier, il faut géocoder ces adresses, c’est-à-dire en obtenir les latitude et longitude. De nombreux sites existent pour cela, comme GetLatLon, simple et efficace pour une utilisation ponctuelle. D’autres outils permettent d’automatiser le processus et ainsi de traiter un grand nombre d’adresses.

Pour R, il existe la fonction geocode, du module dismo. Elle permet de facilement trouver ces informations, pour peu qu’on dispose d’une adresse précise. Par exemple, si on veut connaître les coordonnées du désormais trop célèbre village de Bugarach, il suffit de rentrer la requête suivante :
library(dismo)
bugarach.latlon <- geocode(“Bugarach, France”, oneRecord=TRUE)
L’option oneRecord permet de ne retenir que le premier résultat trouvé. Si on l’omet, on peut obtenir une pluralité de résultats, à trier ensuite manuellement.
Les deux services mentionnés ci-dessus utilisent les données de Google Maps. Ils ne sont donc qu’une manière rapide de chercher dans cette base de données – et s’ils sont gratuits et efficaces, c’est parce que l’accès à cette base de données l’est elle-même.
Plus précisément, le travail qu’ils effectuent en coulisses consiste à se connecter à l’API de Google Maps, et d’y adresser une requête en bonne et due forme, puis en traduire la réponse sous une forme simple. Une API (Application Programming Interface, interface de programmation) est, dans ce contexte, l’équivalent informatique d’un guichet : elle a ses conditions d’ouverture et d’accès (est-ce qu’il faut s’identifier, combien de requêtes sont autorisées sur une période de temps donnée, à quels tarifs, etc.), et ses “formulaires”, c’est-à-dire la forme que doivent prendre les requêtes, et celle selon laquelle sont renvoyées les réponses. Bref, c’est la manière de communiquer avec une boîte noire.
Il existe plusieurs autres bases de données cartographiques, et une multitude de services de géocodage associés ; voir ce blog pour un comparatif des différents services gratuits. On présente ici quelques lignes de code R qui permettent d’interroger directement l’API de Google Maps avec R, et d’en exploiter (un peu) plus complètement les possibilités.
Un exemple : les lieux de culte à Paris
Dans l’exemple qui suit, on cherche à cartographier les lieux de culte à Paris. Par souci de simplicité, on part de données disponibles sur Wikipédia : une page y recense environ 250 édifices religieux à Paris. Il y a certainement bien plus de lieux de culte ; cette liste n’est probablement pas exhaustive, ni particulièrement claire. Elle a cependant le mérite de comporter des informations sur les grandes religions monothéistes, et se prête bien à la cartographie, donc elle nous suffira pour aujourd’hui.
Concernant l’adresse, l’information y est relativement précise, mais pas parfaite : on a un nom, parfois une rue, mais pas l’adresse exacte. Quoi qu’il en soit, la première étape est de récupérer ces données par un petit programme, et d’en faire un fichier importable sous R. Ce fichier est disponible ici, mais pour plus de facilité, on l’importera directement avec R dans un instant.

C’est de ces données imparfaites qu’on part. Mais Google Maps a l’avantage d’être assez précis, même à partir de données approximatives.
Interroger Google Maps par son API
On va donc demander nos informations à l’API Geocode de Google Maps, qui est gratuite jusqu’à un certain seuil, et sur laquelle on peut facilement multiplier les requêtes : jusqu’à 2500 par jour, sur un même ordinateur – la fonction geocode du package dismo, utilisant le même service, est elle aussi limitée de cette façon. Pour travailler avec plus de données, il faudrait soit payer, soit utiliser un autre moteur de recherche (Yahoo permet 50.000 requêtes gratuites par jour, Bing 10.000 ; OpenStreetMap 86.400).
Une API, comme on l’a dit, est une sorte de guichet. Les informations échangées ont ainsi l’air barbare, mais se comprennent, comme les formulaires administratifs, en lisant patiemment les modes d’emploi. Ici, l’API s’utilise simplement en demandant l’ouverture d’une page web. “L’adresse” de cette page est en réalité le contenu de la requête, formulée selon une syntaxe spécifique. On lit dans la documentation que celle-ci est de la forme suivante :
http://maps.googleapis.com/maps/api/geocode/xml?address=LIEU&sensor=false
où on remplace LIEU par le lieu dont on veut déterminer les coordonnées (soit ce qui est dans la troisième colonne du tableau, dans l’image ci-dessus). Il n’y a pas besoin de beaucoup nettoyer ces noms de lieux, par exemple enlever les accents n’est pas nécessaire. Comme tout est à Paris, pour plus de précision on ajoutera également le nom de la ville à la fin de l’adresse, et celle du pays (et nous épargner ainsi le tri parmi les villes homonymes du Texas ou de l’Illinois).
# Lecture du fichier de données
lieux.culte <- read.csv("http://jourdan.ens.fr/~eollion/documents/culte.csv")
# On crée une variable vide, qui va contenir les requêtes
requetes <- NULL
# Traitement de chacune des adresses
for(i in 1:nrow(lieux.culte)) {
# Lit l'adresse, et remplace les espaces par "+" (syntaxe de l'API)
lieu <- lieux.culte[i, "ADRESSE"]
lieu <- gsub("\\s+", "+", lieu)
# Construction de la requête
requetes[i] <- paste("http://maps.googleapis.com/maps/api/geocode/xml?address=",
lieu,
",+Paris,+France",
"&sensor=false",
sep="")
}
En deux mots, cette partie du programme: crée une variable (requetes), copie grâce une boucle (for) la variable ADRESSE de chaque ligne du tableau lieux.culte tiré de Wikipédia, en la mettant en forme pour l’API, c’est à dire en remplaçant les espaces par des +. On peut le vérifier en examinant le vecteur requetes obtenu :
[1] "http://maps.googleapis.com/maps/api/geocode/xml?address=Pagode+de+Vincennes,+bois+de+Vincennes,+Paris,+France&sensor=false"
[2] "http://maps.googleapis.com/maps/api/geocode/xml?address=Temple+bouddhique,+dalle+des+Olympiades,+Paris,+France&sensor=false"
[3] "http://maps.googleapis.com/maps/api/geocode/xml?address=Temple+taoiste,+rue+du+Disque,+Paris,+France&sensor=false"
Collecter les données géographiques pour chaque adresse
Si on ouvre l’une de ces "adresses" dans un navigateur, le site nous renvoie une page (en réalité un fichier XML), qui contient plusieurs informations, dont les coordonnées lat/lon. Le but maintenant est de les extraire de chacune de ces pages. C’est encore une fois assez simple, puisque les données sont structurées clairement, et toujours de la même façon. C’est ce que fait le code suivant :
# Module nécessaire à l'exploration des résultats
library(XML)
# Variable dans laquelle on va stocker les résultats
lieux.culte.latlon <- NULL
# Traitement de chacune des requêtes
# - ATTENTION : prend environ 10 minutes ici
for(i in 1:length(requetes)) {
# Envoie la requête, reçoit la réponse, analyse sa structure
reponse.xml <- readLines(requetes[i])
reponse <- xmlTreeParse(reponse.xml, useInternalNodes=TRUE)
# Traitement des résultats ; on ne prend que
# la première réponse (result[1] dans ce qui suit)
# On initialise comme NA
latitude <- NA
# Si la valeur existe, remplace NA (sinon reste NA)
latitude <- xmlValue(reponse[["//result[1]//geometry/location/lat"]])
# Longitude : idem
longitude <- NA
longitude <- xmlValue(reponse[["//result[1]//geometry/location/lng"]])
# Champ adresse de la réponse : idem
adresse.recue <- NA
adresse.recue <- xmlValue(reponse[["//result[1]//formatted_address"]])
# Mise des résultats ensemble, sous forme de dataframe
latlon.etc <- cbind(lieux.culte[i,], requetes[i], latitude, longitude, adresse.recue)
lieux.culte.latlon <- rbind(lieux.culte.latlon, latlon.etc)
# Pause de 3 secondes - courtoisie envers le serveur
Sys.sleep(3)
}
Pas besoin de tout comprendre pour s’en servir, mais voici quelques explications tout de même. On crée tout d’abord un objet vide (lieux.culte.latlon), puis on traite une à une les requêtes préparées précédemment (boucle for). La réponse à chacune de ces requêtes est un fichier XML (proche cousin du HTML), dont on analyse la structure en arbre (xmlTreeParse), qui est alors stockée dans l’objet reponse.
On navigue ensuite, pour récupérer les informations qui nous intéressent, grâce à la syntaxe XPath (un billet bientôt sur ce sujet, mais de nombreux tutoriels sont disponibles, par exemple ici). Une petite précaution (initialiser à NA les variables de résultats) assure que, dans les cas où la donnée recherchée par le chemin XPath spécifié n’existe pas, la valeur indiquée soit NA (ce qui permet de repérer les erreurs facilement).
Enfin, on colle ces informations et d’autres dans une variable (latlon.etc) pour chaque ligne, qu’il ajoute à l’objet lieux.culte.latlon pour chaque nouvelle valeur de i. Pour terminer, Sys.sleep est une commande qui permet de faire prendre une pause au script (ici de 3 secondes). C’est très conseillé, afin de ne pas trop solliciter le serveur - par courtoisie, et parce que sinon ce dernier pourrait vous refuser l’accès.
Le résultat est visible dans l’objet lieux.culte.latlon : à côté de l’adresse, vous avez maintenant les coordonnées. La variable adresse permet ici de vérifier que les données correspondent bien spécifiquement au lieu demandé. En effet, dans le cas inverse, ce champ indique seulement Paris (il faut alors recoder à la main, ou préciser quelque chose dans l’adresse).
On a visualisé les données à l'aide d'une rapide carte. Le premier résultat (voir image en haut de cette page) est qu'il y a des églises un peu partout dans Paris, ce qui n'est pas révolutionnaire. Plus précisément, un zoom sur la zone de la Bastille montre l'alignement de synagogues, certaines dans le Marais, et d’autres à proximité. En revanche, le cas de l'Islam est très mal représenté ici, mais c’est dû à un effet de sources, à savoir qu'on est parti des édifices religieux, et pas des simples lieux de culte ; or la distinction est particulièrement importante dans le cas de cette religion, comme on le verra dans un prochain billet.

Pour aller plus loin
On vient, dans cet exemple d’utilisation de l’API de Google Maps, de réinventer la fonction geocode de dismo mentionnée plus haut, tout en contrôlant mieux les résultats obtenus.
On a ce faisant utilisé une API de type REST, qui est un standard très répandu. Or les autres services que Google, comme OpenStreetMap, MapQuest, Bing, Nokia, etc., disposent rarement d’une fonction directement disponible sous R, mais offrent tous des API, dont souvent l'une de ce type.
La syntaxe est alors extrêmement proche de celle qu'on a employée ici. Il est alors possible d'utiliser, par exemple, le projet Nominatim de la fondation Open Street Map, dont la limite d'utilisation est d'une requête par seconde (soit 86.400 par jour - ce dernier fait par ailleurs partie d'un projet plus général de mise à disposition gratuite de données géographiques. Les requêtes se font de la même manière, comme l'explique cette page de documentation, et l'extraction des données ne suppose qu'un léger ajustement. Essayez donc !
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
1 commentaire »
La collecte automatisée de données sur le web consiste à ordonner à un programme d’aller sélectionner des informations bien précises dans une série de pages. Ce billet est une brève introduction à la structure du langage HTML, dans lequel ces pages sont écrites. On aborde les pages simples (la grande majorité d’entre elles), et on abordera plus tard les les pages plus complexes, ainsi que les évolutions contemporaines du langage.
Quel rapport entre un navigateur et le HTML ?
Des visualisateurs de code HTML
Que se passe-t-il quand on utilise le web, par exemple quand vous venez visiter la page de ce billet ? Vous utilisez un navigateur, vous tapez l’adresse de la page, vous pressez entrée ; et après ?
L’adresse est celle d’un serveur, un ordinateur allumé tout le temps, et appuyer sur entrée revient à lui demander une page particulière. Le serveur nous renvoie alors la page demandée sous forme d’un fichier écrit en HTML : il s’agit d’un langage informatique simple, qu’on va préciser dans une seconde.
Votre navigateur reçoit ensuite ce fichier HTML, qu’on appelle le code source de la page et le transforme en une page mise sous une forme lisible et graphique, que vous avez sous les yeux.
Le langage HTML est donc une manière de décrire des instructions typographiques pour les pages du web. Il s’est imposé grâce à sa relative simplicité d’écriture et d’interprétation (pour les concepteurs de navigateurs).
Comme la collecte automatisée de données sur internet consiste souvent à demander à un programme de récupérer des informations dans une série de pages web, c’est-à-dire dans des pages écrites en HTML, il nous faut savoir comment désigner dans ce langage les informations qui nous intéressent.
Tout ce qui apparaît régulier dans le navigateur, doit être régulier dans le code source
Un principe fondamental de la collecte automatisée de données est ainsi le suivant : si on observe une certaine régularité formelle sur une page web affichée par un navigateur, alors celle-ci doit exister dans le code source de la page. Dans l’imprimerie de système Gutenberg, si on voit des lignes (de texte), c’est que l’imprimeur a utilisé des outils pour créer des lignes (des suites de caractères métalliques de même hauteur). Ici, si on voit à l’écran des blocs de texte similaires alors, comme le navigateur ne fait que traduire visuellement le code source, on doit très probablement trouver des instructions similaires qui correspondent à ces blocs de texte dans le code source.
La structure du langage
Les balises HTML
Le HTML est un langage assez facile d’accès. Son nom est explicite, HyperText Markup Language : HyperText signifie qu’il y a des liens cliquables, et Markup signifie « balises ». C’est donc un langage de balises (avec des liens cliquables). Le point principal est donc de comprendre la notion de balises et l’usage qu’il y en est fait.
Une structure en arbre
Les balises sont de la forme suivante :
<typeBalise>
Contenu
</typeBalise>
Trois éléments sont présents : un couple de balises ouvrante et fermante, leur type, et un contenu entre les deux. Ce contenu peut être du simple texte, mais aussi d’autres balises. Ainsi une page HTML a toujours une structure de la forme suivante :
<tronc>
<branche>
<sousBranche>
contenu_1.1
</sousBranche>
<sousBranche>
contenu_1.2
</sousBranche>
</branche>
<branche>
contenu_2
</branche>
</tronc>
C’est donc une structure en arbre, exactement comme un texte avec des parties et des sous-parties – à la différence que celles-ci peuvent être de plusieurs types : pour poursuivre l’analogie, comme dans les textes de philosophie analytique ou de mathématiques, texte principal, scolie, lemme, démonstration, figues, etc.
En HTML, les balises peuvent être d’un ensemble limité de types, qui correspondent à des instructions typographiques : div = bloc, a = lien, etc. ; <tronc>, <branche>, <sousBranche> et <typeBalise> n’existent pas en réalité.
Les espaces et sauts de ligne n’ont pas d’importance, on n’adopte cette présentation que pour le rendre plus lisible ; le code suivant a la même signification :
<tronc>
<branche>
<sousBranche>contenu_1.1</sousBranche>
<sousBranche>contenu_1.2</sousBranche>
</branche>
<branche>contenu_2</branche>
</tronc>
On pourrait même écrire tout à la suite, en enlevant tous les espaces et sauts de ligne ci-dessus, ce serait inintelligible mais techniquement correct.
Les attributs de balises
Remarquez que jusqu’ici, seuls les types des balises sont présents, elle n’ont pas d’identifiant particulier, et rien ne permet de différencier la première branche de la deuxième, si ce n’est qu’elle est placée avant dans le code – ce qui est un moyen réel de l’identifier, bien que pas très pratique. C’est l’intérêt des attributs de balises.
En effet, les balises peuvent s’écrire plus complètement de la façon suivante, par exemple pour une balise de type div :
<div class="titre_1">
Texte, sous-branches…
</div>
Dans la balise ouvrante, on peut ajouter des attributs, qui servent à enrichir leur description et à faciliter leur identification. Dans la page actuelle, vous pouvez vérifier que les titres de deuxième niveau sont repérés par des balises <div class="h2">. Un autre exemple est celui des liens hypertexte, qui sont décrits par des balises a, avec l’adresse indiquée comme attribut href (hypertext reference) ; voici comment on écrit ce lien renvoyant vers cette page :
<a href="http://data.hypotheses.org/243">
lien renvoyant vers cette page
</a>
Ce qui identifie une balise
On a ainsi les trois éléments pour identifier une balise, qui sont :
- Son type (
div, p, a, etc.),
- Ses attributs éventuels (
class, attr, href, etc.),
- Le contenu de texte et les sous-branches qui y naissent.
Pour des branches (ou sous-branches) formellement identiques, comme dans l’exemple vu précédemment, il nous reste l’ordre dans lequel celles-ci apparaissent dans le code HTML.
Avec ce système d’identification, on aura toujours au moins une manière, et souvent plusieurs, de repérer une ou plusieurs balises, celles dont on voudra collecter automatiquement les données.
Dans la pratique
La tête et le corps
La structure d’un fichier HTML est standardisée. Elle est de la forme :
<!DOCTYPE html (…)>
<html>
<head>
<meta> …
<meta> …
<link type="text/css" href="http://…">
</head>
<body>
<div>
<h1> Titre </h1>
<p>
Texte
</p>
</div>
…
</body>
</html>
La première ligne (DOCTYPE) désigne la version du langage HTML que la page utilise. On n’aura jamais à s’en servir. Ensuite le contenu de la page est situé entre les balises html. Ce tronc se divise en deux branches : head, puis body.
La branche head contient un ensemble d’informations sur la page (balises meta), des instructions de mise en page (chargées avec link), etc., mais aucun contenu affiché.
Toutes les informations affichées, comme le texte, les images, sont décrites dans la partie body.
Les balises réelles courantes
Celui-ci est construit avec les balises du langage. Il n’est pas indispensable de les connaître pour faire de la collecte automatisée de données. À titre indicatif voici le plus courantes :
<div> : un bloc rectangulaire de la page, contenant du texte ou des images ; souvent l’attribut class (ou parfois id) est présent ;
<a> : un lien hypertexte, renvoyant vers l’adresse indiquée par l’attribut href ;
<h1>, <h2>, <h3>, etc. : des titres, de niveaux décroissants ;
<p> : un paragraphe de texte ;
<ul>, <ol> : une liste, respectivement sans et avec numérotation ;
<img> : une image ;
<!-- … --> : un commentaire, c’est-à-dire du texte que le navigateur ignore.
Il existe d’autres balises, et chaque nouvelle version du langage en apporte pour simplifier l’écriture et étendre les fonctionnalités disponibles (voir l’histoire du HTML). De nombreux manuels existent en ligne. Le plus simple est de vous y référer si besoin, ou simplement de rechercher sur un moteur de recherche la signification d’une balise, comme le font tous les programmeurs.
Pour être complet, mentionnons, sans rentrer dans les détails, qu’il existe deux manières de préciser les instructions de mise en page – par exemple pour un bloc <div> : ses dimensions, sa couleur de fond, etc.
La première manière est de spécifier ces instructions comme attributs de la balise, directement dans le code HTML, par exemple : <div style="width:100px;border:1pxsolidblack">. Le HTML des années 1990 est écrit de cette manière lourde et pédestre, et on rencontre encore des pages sous cette forme.
La seconde consiste à utiliser une feuille de style, au format CSS. Dans ce cas, on précise dans le HTML un attribut du bloc, par exemple <div class="grand"> ; et dans un autre fichier, on précise les propriétés des blocs div possédant l’attribut class ayant la valeur grand, de manière générique. On peut ainsi en écrire plusieurs sans avoir à préciser à chaque fois les propriétés graphiques.
Dans ce dernier cas, la page web ne se résume donc pas au code HTML, mais est la résultante aussi de la feuille de style (CSS). De manière générale, une page web est décrite par un ensemble de fichiers, dont le HTML est le centre et contient quasiment toutes les informations affichées à l’écran.
Faire le lien entre le contenu affiché et le code source
Visualiser le code source
Une fois arrivé là, le code source d’une vraie page ne devrait plus rien avoir d’effrayant. Pour voir le code de cette page, demander à votre navigateur “Montrer le code source” ; le raccourci clavier est souvent Cmd-U (Mac) ou Ctrl-U (Windows), en ajoutant éventuellement Alt à cette combinaison (Safari ou Chrome, et ça dépend des versions) ; si vous ne trouvez pas, chercher “source” dans l’aide du logiciel.
Vous devriez obtenir une fenêtre un peu terne, mais qui permet quand même de vérifier ce qu’on vient de présenter.
Cela dit, ce n’est pas commode à lire. Pour disposer d’outils plus puissants et confortables, on vous encourage très vivement à installer Firebug pour Firefox, ou activer les outils de développeur, pour Safari (dans les préférences, menu “Avancées”, option “Afficher le menu Développement”) ; ou bien pour Chrome ouvrir les “Outils de développement”. Le raccourci clavier est souvent Cmd/Ctrl-(Alt)-I.
Ainsi, normalement, vous obtenez quelque chose de ce genre-là :

À quel morceau de code correspond un élément affiché ?
Plutôt que de chercher à l’aveuglette à quel morceau de code correspond un élément affiché, on peut utiliser l’inspecteur web. Cliquez sur l’icone en forme de main (
Safari), de rectangle avec une flèche (
Firebug) ou de loupe (
Chrome), puis promenez votre curseur sur les éléments de la page qu’il vous intéresse de connaître : des zones de la page doivent se colorer en bleu. Cliquez ensuite sur un élément, et l’inspecteur web vous indique où se trouve son équivalent dans le code HTML.
On peut alors observer ce qu’on annonçait au début de ce billet, à savoir que les éléments qui sont affichés de la même manière existent, dans le code source, de façon également similaire. Testez-le par exemple sur la colonne “liens”, dans la colonne de droite de cette page :

Une fois qu’on a repéré où sont, dans le code source, les informations que l’on veut récupérer, la moitié du chemin est fait. Il reste à savoir comment faire comprendre cette localisation à un programme ; pour cela, on utilisera la syntaxe XPath, qui fera l’objet d’un prochain billet.
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
1 commentaire »
Âges déclarés et sites de rencontres : une procédure de collecte automatisée de données
S’il est un fait sur lequel s’accordent toutes les études sur les sites de rencontre, c’est la tendance de leurs utilisateurs à sous-déclarer leur âge. Il est souvent démontré en comparant les profils en ligne à une source d’information plus fiable, le plus souvent un entretien. On propose de retrouver ce résultat à partir d’une analyse quantitative faite à distance, sans rencontrer d’usager de ces sites, et en quelques minutes. Disons le immédiatement, les résultats obtenus sont moins riches et plus incertains qu’une véritable enquête. Mais parce que l’objectif est d’illustrer les techniques de collecte automatique de données, on repart de ce fait bien établi pour proposer une méthode pas-à-pas.

Lire la suite sur Quanti
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
Pas de commentaire »
8 novembre 2012 |
étienne
La saison 2 de l’élection présidentielle s’est achevée hier avec les résultats que l’on sait, le temps de l’analyse à froid peut commencer. Du point de vue des données produites et publiées, on peut voir quelques tendances.
Du côté de la prédiction du vote, la vedette de l’élection, le blog FiveThirtyEight du New York Times, a finalement eu bon sur toute la ligne. Le journal a donc réussi à annoncer le résultat avec une faible marge d’erreur. Le matin de l’élection, il prévoyait 313 grands électeurs et 91% de chances de victoire à Obama.

Les prédictions de FiveThirtyEight, le matin de l’élection
Sa méthode ? Une compilation de sondages publiés état par État, et redressés « à la main », c’est-à-dire selon une méthode tenue secrète. D’autres faisaient cela depuis longtemps, mais ici son principal animateur, le statisticien Nate Silver qui officiait pour la deuxième fois après 2008, a gagné une visibilité internationale, notamment en devenant la cible des républicains qui l’accusaient de partialité (qu’il revendiquait d’ailleurs au plan personnel, mais pas pour ses statistiques).
C’est d’autant plus remarquable que sa méthode pouvait paraître fragile : compilation de résultats de sondages réalisés État par État, ses mesures était sensibles à tous les biais classiques qu’on impute aux sondages (sous-déclaration de certaines opinions, partialité des redressements). Et aux corrections « à la main » (au doigt mouillé, diraient leurs détracteurs) réalisées par les sondeurs, il a ajouté sa propre formule de redressement pour pondérer les biais éventuels des différents sondages.
Cette approche, qui ferait bondir un étudiant de statistiques de première année, a finalement été couronnée de succès. Probablement parce qu’en dépit des biais multiples et accumulés, la répétition dans le temps des mesures (par institut) comme la multiplicité des mesures (plusieurs instituts) lui donnait une bonne estimation des variations d’opinion des électeurs dans certains états. Peut-être aussi que les comportements de non-réponse, ou de sous-déclaration, sont moins difficiles à contrôler dans un système bipartisan ? Certains commentateurs soulignent par ailleurs son érudition d’électoraliste, y compris au niveau local. Finalement, en dépit de sa canonisation comme sorcier des chiffres, c’est peut-être avant tout en analyste politique minutieux qu’il devrait être regardé ?

Résultats 2012, par comté
Du côté de l’usage des données personnelles, la présidentielle 2012 a révélé un usage encore plus extensif de celles-ci. Les équipes de campagne des candidats ont cette fois-ci fait une orgie de données, parfois aux limites de l’intrusion dans la vie privée. En 2008, les équipes de McCain et d’Obama avaient largement eu recours aux réseaux sociaux pour faire campagne. Ils avaient aussi, plus discrètement, mis en place des bases de données pour faire inscrire puis faire voter (sur les campagnes et l’usage des bases de données en 2008, voir ici). Au porte-à-porte façon parti communiste des années 1950, ils avaient ajouté la mise en place de système de collecte et d’échange d’informations entre militants. Certains appellent, d’autres rendent visitent, et inscrivent sur les listes électorales. D’autre encore se conduisent au bureau de vote le jour de l’élection (ou durant le mois qui précède, si l’état permet le « vote early »).
Pas de changement cette fois-ci, mais les techniques étaient encore plus précises. Des cookies (des petits programmes qui suivent vos parcours sur internet) permettaient de proposer des publicités ciblées. Inutile en effet de proposer des messages du genre « Dieu veut que vous votiez Romney » si l’usager vient de passer une heure sur des sites à caractère pornographique (quoique…). Plus précis encore : les bases de données à partir desquelles les équipes de campagne appellent les électeurs potentiels étaient en permanence complétées par des données sur leurs habitudes personnelles, voire par des informations sur leurs connaissances. Une fois leurs listes de contact (Facebook, LinkedIn, etc) minutieusement épluchées par un programme informatique, les équipes de campagne tentaient de trouver un bénévole qui les connaitrait. La collecte de ces informations reste toutefois un tabou, et les accusations d’intrusion dans la vie privée n’ont pas manqué.
La campagne a donné lieu à de belles visualisations. Les donations ont eu droit à une carte animée très (trop ?) léchée, mais surtout les données, y compris individuelles, sont facilement accessibles sur le site de l’administration des finances de campagne. The Atlantic propose une rapide rétrospective des cartographies électorales du New York Times, dont celle de 1896, qui rappelle que les équilibres partisans étaient exactement inversés, avec un Sud démocrate – ce qui ne veut pas dire de gauche, et encore moins à l’époque.

L’élection présidentielle de 1896, par le NY Times
NPR a fait dans les extrêmes d’un point de vue technique. D’un côté, la radio publique a proposé un bon vieux tableau des scores digne des matches de baseball pour suivre les résultats en direct. À force de valoriser la prouesse graphiques, on oublie que ces représentations fournissent rapidement une somme d’information finalement bien plus importante. Le Big Board de NPR était un site particulièrement utile pour suivre les résultats au fur et à mesure de leur arrivée.

NPR Big Board
De l’autre, une série de cartes basées sur le principe d’un morphisme : la surface représentée est proportionnelle à une variable, comme le nombre de grands électeurs, ou ci-dessous l’argent dépensé. Cela permet de bien montrer qu’en dépit des déclarations des candidats prétendant parler au pays entier, certains États ont été au cœur de toutes les attentions.

Dépenses en publicité par Etat (NPR)
Ce genre de graphique laisse songeur. Sur le caractère démocratique de l’élection, avec une campagne qui se joue sur cinq États à coup de dépenses de campagnes inouïes. Au total, ce sont 2,6 milliards de dollars qui ont été dépensés à des fins partisanes pour cette campagne (à comparer aux quelques 60 millions d’euros pour l’élection présidentielle française de 2012, avec 10 candidats). Sur les résultats aussi, puisqu’on aboutit finalement à un statu quo ante remarquable : le Président est le même, le Sénat reste démocrate, et la Chambre des représentants est toujours entre les mains des républicains. Du point de vue républicain, le retour sur investissement est finalement assez mauvais.
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
5 commentaires »
16 octobre 2012 |
étienne
Pour la deuxième fois en moins de six mois, le débat sur les inégalités de santé fait la première page des journaux grâce… aux techniques de collecte automatique de données. En avril dernier, Le Monde avait fait sa première page sur les dépassements d’honoraires en France. Après avoir « aspiré » le site de l’Assurance Santé (www.ameli-direct.fr), les journalistes avaient publié une carte des dépassements d’honoraire à Paris. La procédure était expliquée ici par le data-journaliste du Monde, A. Léchenet.

Dépassements d’honoraires à Paris
Cette semaine, c’est l’UFC-Que Choisir qui recommence, en croisant cette fois dépassements d’honoraire et déserts médicaux. La technique comme la base de données sont les mêmes, les résultats encore plus complets. Véritables outils de communication politique, ils sont présentés avec un communiqué de presse, un rapport complet, une carte interactive, et une interface qui permet d’enregistrer les témoignages individuels (dans un but évident d’advocacy).

Carte des déserts médicaux à Paris – UFC Octobre 2012
Nul doute que ce travail a été évoqué lors des négociations entre assurance maladie, praticiens et mutuelles qui se terminent en ce moment. Depuis peu, mais de manière croissante, la collecte automatique de données s’invite donc dans certains débats politiques (pour un autre exemple récent : en période de discussion sur le cumul des mandats, l’association Regards Citoyens, avait proposé des informations sur l’activité des parlementaires).
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
Pas de commentaire »
10 octobre 2012 |
étienne
Pierre Mercklé vient de publier (sur Quanti) une présentation que nous avions faite en juin sur le thème des “big data” en sciences sociales. Elle propose un premier tour d’horizon des outils de collecte automatisée de données sur internet et évoque plusieurs enjeux dont il sera question ici
Ces vingt dernières années ont vu le développement de techniques et d’outils informatiques qui permettent d’automatiser la collecte et la mise en forme de données, en particulier celles provenant d’internet[1]. Plus puissantes et plus faciles d’accès, ils sont aussi de plus en plus utilisés dans de nombreuses professions. Leur diffusion intéresse donc les chercheurs en sciences sociales, à la fois parce qu’elles permettent de collecter rapidement des informations sur divers aspects du monde social, mais aussi parce qu’elle conteste un peu plus leur monopole dans la production de données quantitatives. On se propose ici de réaliser un rapide tour d’horizon sur cette question qui souligne le potentiel, et évoque certains enjeux, du recours croissant à ces méthodes pour nos disciplines…. Lire la suite sur Quanti
Voir aussi les remarques et compléments apportés sur Polit’bistro
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
Pas de commentaire »
10 octobre 2012 |
étienne
Cet exemple condense trois des éléments qui sont développés dans ce blog : la présentation d’une base de données publique et son utilisation; des éléments de programmation, et des résultats de visualisation des données.
Les émissions de télévision, un matériau sous-exploité
Beaucoup de chercheurs en sciences sociales sont amenés à s’intéresser au traitement médiatique d’un sujet donné. Pour les sources, si les dépêches d’agence étaient autrefois privilégiées du fait de leur brièveté, c’est aujourd’hui vers la presse écrite qu’ils se tournent majoritairement. Il s’agit en effet d’une source commode d’accès : bien archivée, disponible de façon exhaustive en bibliothèques et de plus en plus directement sur internet et interrogeables par mots-clés (Factiva, par exemple).

Cependant, on pourrait contester cet usage privilégié :
- le public touché est très restreint par rapport à celui de la télévision, et cet écart ne fait que s’accroître
- méthodologiquement, le contenu textuel brut est long et malaisé à traiter. En particulier, il ne peut — sauf à recoder intégralement — distinguer les usages propres et figurés d’un mot (et donc faire la différence entre deux occurrences aussi différentes que “le danger des sectes” et “François Bayrou, chef de secte”, la première seulement étant intéressante pour nous)
Les contenus télévisuels sont paradoxalement très peu représentés dans les études quantitatives qui prennent les médias pour objet. Pour paraphraser Solow, on pourrait presque dire que la télévision est partout, sauf dans les statistiques des chercheurs en sciences sociales. Le problème principal est d’ordre technique : comment coder et synthétiser rapidement l’information sur les programmes télévisuels ?
Une source commode et fiable : la base de l’INA
Complétude
En France, l’existence et l’accessibilité des archives de l’Institut national de l’audiovisuel (INA) permettent fournir de pallier cette difficulté. Au titre du dépôt légal de l’audiovisuel français, l’INA conserve l’ensemble des programmes diffusés par les différentes chaines de télévision ou de radio. Le recensement opéré est ainsi a priori complet, et chaque document est déjà codé de manière relativement fiable, précise et complète, par mots-clefs et selon diverses informations (chaine de diffusion, durée, type d’émission…).
Fiabilité
Le codage est réalisé par le personnel au moment du dépôt des fichiers. Certes imparfait (les fiches sont remplies par des personnes différentes, sur une période de plus de quinze ans), il est cependant relativement efficace. Les recoupements ponctuels effectués sur la base des recensions faites par d’autres moyens montrent que le codage n’est pas arbitraire, et que la chronologie que l’on peut en tirer correspond assez bien à celle obtenue par d’autres moyens. De fait, tout sujet relativement institué, même s’il a des frontières floues, a de bonnes chances d’être bien représenté. C’est par contre moins vrai des « nouveaux » sujets : il faut sûrement attendre qu’un « problème public » soit reconnu comme tel pour qu’on puisse trouver une notice qui le mentionne). De manière générale, il est de bonne politique de chercher à « étendre » les mots clés, c’est-à-dire de faire des requêtes pour des termes proches (par exemple, pour secte : gourou, manipulation mentale, etc.), et de compiler tous les résultats obtenus.
Accessibilité
Si l’INA est une institution accueillante, il se trouve que depuis peu, une partie de sa base de données est accessible directement et gratuitement par internet. La période couverte commence au 1er janvier 1995, et la base recense les différents médias hertziens et câblés ainsi que les radios, au fur et à mesure de leur création. La recherche par mots-clefs permet donc une étude rapide et exhaustive sur un terme donné.
Un petit obstacle technique
Comment télécharger les résultats correspondant à une requête particulière, pour les traiter finement (nettoyages, tris croisés, représentations graphiques) ? Ceux-ci sont présentés sous la forme d’un tableau de texte, qui devrait être simple à utiliser, par un copier-coller dans un tableur par exemple.
Malheureusement, cela se révèle impossible, pour des raisons liées au fonctionnement du site. Cependant, comme le navigateur affiche une forme régulière (tableau), il doit bien y avoir un moyen de récupérer les données affichées en gardant la régularité de cette forme.
On se propose de présenter ici une procédure simple qui permet de résoudre ce problème. Elle passe par le recours à quelques lignes de programmation, ici en R. On présente ici rapidement le code, qui est réutilisable tel quel. L’explication détaillée de tous les élélemnts de la syntaxe fera l’objet de prochains billets.
Une procédure de collecte automatisée des données
Faire une recherche sur le catalogue en ligne
Dans le cadre d’une recherche sur la question des sectes en France, on a tenté de trouver une manière de faire une étude exhaustive des émissions télévisuelles sur le sujet. Une fois connecté au catalogue en ligne, on saisit alors la requête que l’on souhaite effectuer dans un formulaire simple. Ici, on veut obtenir toutes les occurrences du terme « secte » ou « sectaire » (au singulier et au pluriel), du 1er janvier 1995 au 31 décembre 2010, sur les chaines hertziennes.

Formulaire de requête sur la base de l’Inathèque
On obtient environ 2500 résultats, qu’on veut conserver afin de les consulter ; on clique alors sur « Afficher tous les résultats ». Le navigateur affiche lentement l’ensemble de la page (plusieurs minutes parfois), et c’est cette page que l’on va manipuler pour ensuite pouvoir l’ouvrir avec un tableur classique ou un logiciel de statistiques. Notons pour l’instant l’adresse (URL) de cette page, qui est de la forme http://inatheque.ina.fr/Ina/ws/dltv/dlweb/general avec de nombreux signes cabalistiques après (si vous regardez bien, vous verrez les mots que vous avez demandé entre deux signes %).
On va ensuite travailler avec R, à partir de cette URL, pour la traduire en un fichier lisible par un tableur (au format .csv : simple fichier texte où les données sont séparées par des points-virgules).
Installer R
Pour l’installation et les premiers usages de R, on se permet de renvoyer au site du programme. On suppose aussi que vous disposez d’un tableur (de type Excel ou, mieux, Libre Office). Pour faire fonctionner le programme, il faut en plus installer deux modules spécifiques de R : RCurl et XML, qui permettent de télécharger la page web et d’en extraire les informations qui nous intéressent.
Un petit programme permettant de télécharger et traiter la page dont on a noté l’URL :
library(RCurl)
library(XML)
webpage <- getURL("http://inatheque.ina.fr/Ina/ws/dltv/dlweb/general/ResultSet?rpp=-50&upp=0&w=NATIVE%28%27ITOUSTEXT+ph+like+%27%27secte%27%27%2C%27%27sectes%27%27%2C%27%27sectaire%27%27%2C%27%27sectaires%27%27%27%29&r=1", .encoding="LATIN1")
page <- readLines(tc <- textConnection(webpage)); close(tc)
arbre.page <- htmlTreeParse(page, useInternalNodes = TRUE)
emissions <- xpathSApply(arbre.page,
"//div[contains(@class, 'result_line')]",
xmlValue)
emissions.clean <- gsub("\\t|\\n", "", emissions)
emissions.final <- gsub(" {20,180} ", ";", emissions.clean)
write.csv(emissions.final,
file="/Users/eollion/SectesTV/INA-sectes.csv",
fileEncoding='latin1')
Les deux premières lignes chargent les modules. L’opération de téléchargement de la page s’effectue ensuite (getURL), puis on analyse la structure de la page web chargée (on parse du HTML).
Le bloc suivant (xpathSapply) sélectionne ce qui correspond aux lignes du tableau affichées dans le navigateur. Elles sont identifiées d’une certaine manière dans le code HTML pour être affichées sous forme de lignes, et c’est ainsi qu’on peut les repérer ; ça paraît obscur, mais il y a des outils pour se repérer et écrire ce genre de commandes assez facilement. Voir chez François Guillem pour des bonnes premières explications sur ce point.
Ce qu’on a récupéré dans emissions ressemble presque à ce qu’un navigateur afficherait, sauf qu’ici les écarts de position sur la page sont représentés par des espaces. Il suffit de les remplacer par des points-virgules, et après un peu de nettoyage d’espaces, on a le notre tableau sous format .csv. Il ne reste plus qu’à l’écrire dans un fichier en sortie.
Voilà, normalement on peut ouvrir le fichier produit dans un tableur, et en principe tout va bien, y compris les accents (il se peut qu’Excel soit capricieux, on verra plus tard comment contourner ça). On peut alors faire un peu de nettoyage si nécessaire, et de recodage, par exemple les chaînes (rechercher « La Cinquième » et remplacer par « France 5 », etc.), ou pour mettre ensemble des « types » d’émissions proches.
Après constitution de la base, nettoyage et recodage de celle-ci, on en a conservé 1834 entre le 1er janvier 1995 et le 31 décembre 2010. La table est donc prête, on peut procéder à des représentations graphiques, ou des statistiques, et commencer les analyses sociologiques.
Les graphiques ci-dessous sont un exemple de visualisations possibles et rapides grâce à ggplot, moyennant quelques manipulations, que l’on abordera prochainement.

Représentation par chaine
Histogrammes

Représentation par type de programme et par chaine
Polygones de fréquence

Représentation par chaine

Nombre de programmes par jour
(période de 2 mois)
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
1 commentaire »
5 octobre 2012 |
étienne
Ces dernières années ont vu la prolifération tant des « données » accessibles que des outils pour les analyser. Le développement d’internet offre une masse d’informations potentiellement infinie ; la disponibilité croissante de bases de données importantes (directement ou après un travail de compilation) ; et les différentes transformations technologique (accessibilité, capacité de traitement) font que des masses d’informations sont désormais à portée de clic.
Combinée avec la multiplication des activités en ligne, cette profusion de données modifie non seulement les pratiques quotidiennes de tout un chacun ; elle transforme aussi en profondeur de nombreuses professions. À l’instar du journalisme — qui a récemment vu se développer une sous-branche spécialement consacrée (le « data journalisme ») — et du marketing, les sciences sociales sont elles aussi interrogées par ces transformations.
La « révolution des données » est en effet à la fois riche de potentiels pour nos disciplines, d’abord par le matériau qu’elle met à disposition des chercheurs. Elle est également un nouvel outillage, d’intérêt général, que tous les chercheurs en sciences sociales gagnent à connaître a minima, sinon à ajouter complètement à leur panoplie. Elle est enfin lourde d’enjeux, à la fois en interne quand il s’agira de définir ce qui fait la qualité de ces données, et en externe puisque ces techniques font que d’autres peuvent remplacer les sociologues dans la production de représentations quantifiées du monde social.
Data Sciences Sociales se propose de mettre en avant les potentialités et l’actualité des recherches sur le maniement informatisé de données en sciences sociales, et de permettre leur appropriation par le plus grand nombre. Plus précisément, on se donne un triple objectif :
- Comme tout phénomène en pleine expansion, l’intérêt pour les « big data » se développe à travers les espaces disciplinaires divers, et selon des modalités qui ne font pas forcément écho à celles de la communauté des chercheurs. L’objectif premier du blog est donc d’assurer un suivi de l’actualité de cette thématique à la lumière des questionnements qui sont propres à nos objets. Il s’agit de faire état des débats, des recherches, et des outils disponibles d’une manière qui soit à la fois compréhensible et utilisables par une majorité.
- Le second objectif est de transmettre des savoir-faire qui permettent à ceux qui le souhaitent de commencer à compiler des données. Il s’agit donc de proposer un repérage des outils et techniques disponibles mais aussi des morceaux de code commentés de manière pédagogique et réutilisables, afin de permettre aux lecteurs de se former par eux-mêmes à ces outils, en se concentrant sur l’essentiel, dans un objectif de résolution de problèmes de recherche concrets dans leur ensemble. On sera attentif à l’ensemble des opérations à effectuer. Le format blog permettra, grâce aux commentaires, de créer une page interactive où les utilisateurs pourront enrichir le support, par le partage de leurs difficultés d’apprentissage ou d’opérationnalisation, et par le soulèvement des problèmes nouveaux qu’ils seront amenés à rencontrer. Cette partie pourra interagir avec les supports créés à l’occasion d’un cours d’introduction au traitement des données que les coordinateurs du blog dispensent cette année au niveau Master.
- Enfin, le blog propose une réflexion sur les enjeux professionnels, intellectuels et politiques, que soulèvent ces techniques comme sur leurs pratiques pour les sciences sociales. De la qualité des données produites, à l’éthique et la protection des enquêtés, en passant par le problème de la représentativité ou des dynamiques (internes et externes) propres à la discipline, et la manière de les enseigner, leur développement pose en effet de nombreuses questions dont chercheurs et enseignants ne peuvent faire l’économie. Les potentialités offertes par le maniement informatisé de données ne seront bien maîtrisées qu’accompagnées d’une réflexivité quant aux limites de ces outils.
echo __('Posted in','cleaker') . ' '; the_category(', '); echo ' ' . __("by", "cleaker") . ' '; the_author_posts_link(); ?>
Pas de commentaire »