PC & Mobile

Streams – Documenter DocNow

Streams - Documenter DocNow


Comment concevons-nous des systèmes de collecte de données et des interfaces pour mieux refléter l'incertitude?

Stream par Andrew Price

L’un des éléments qui distingue toujours Twitter en tant que plate-forme de médias sociaux est l’accès qu’il offre à ses utilisateurs. Courant. Stream est un ensemble de points de terminaison d’API permettant de collecter des tweets en temps réel: Filtrer le flux qui vous permet de collecter des tweets correspondant à un filtre de mots clés fourni; la Exemple de flux qui représente un échantillon de tous les tweets disponibles; et (si vous êtes capable de payer pour cela) le Firehose qui comprend tous les tweets (publics). Pour rendre les choses plus compliquées, les points de terminaison de flux Twitter existent dans plusieurs produits (Standard, Premium et Enterprise) qui vous fournissent généralement des niveaux d’accès croissants aux données. Voir Driscoll & Walker (2014) pour une analyse approfondie de la relation entre le flux de filtres gratuits et ces services payants dans le passé. Ce post vise à essayer de comprendre ce que nous voyons et ne voyons pas dans le Filtre flux, afin de le communiquer efficacement aux personnes qui l'utilisent pour collecter des données.

Flux sur le Web

Bien entendu, il existait des flux de contenu sur le Web avant Twitter. Je pense ici aux blogs et à leurs flux RSS associés. Bien qu'un flux RSS ou Atom soit une représentation d'un flux, ils sont généralement tiré à partir d'un serveur. Les flux sont complètement différents, car un client lance une demande de flux, maintient la connexion ouverte, puis le serveur pousse nouveau contenu tel qu'il est créé sur la plate-forme, jusqu'à ce que le client décide de fermer la connexion, ce qui peut prendre des heures, des jours ou même des mois plus tard.

Aujourd'hui, de nombreuses plates-formes telles que Slack, Wikipedia et WordPress proposent différents types de flux utilisant WebSockets et Server-Sent Events (SSE). D'autres, comme Facebook et Instagram (y a-t-il vraiment une différence?), Utilisent-ils une solution hybride appelée WebHooks pour transférer des morceaux de contenu nouveau ou mis à jour dans votre application en temps réel.

Cependant, la simplicité relative et l’utilité de l’API Filter Stream de Twitter sont toujours uniques sur le Web. Une partie de la raison en est la base d’utilisateurs de journalistes de Twitter qui a été une raison pour que certains assimilent Twitter à une sorte de service télégraphique du XXIe siècle. Il ne fait aucun doute que cela a quelque chose à voir avec la capacité de la salle de presse à utiliser le flux dans leurs propres applications d’arrière-guichet, un peu comme un ruban téléscripteur pour le Web.

Flux Twitter

Parfois dans 2007 Twitter travaillait avec la société d’infrastructure de blogs en place, Technorati, aujourd'hui disparue, pour développer un flux en temps réel de tout son contenu, à l’aide d’une norme appelée XMPP (Extensible Messaging and Presence Protocol). Mais mi-2009 Twitter a commencé à déployer son projet Hosebird (maladroitement nommé) qui a restructuré l’infrastructure de diffusion en continu afin de fournir en grande partie ce que nous voyons aujourd’hui: flux complets, d’échantillons et de filtres utilisant le vieux HTTP brut.

Il est difficile de dire quand, puisque la documentation a maintenant disparu et que la couverture dans Internet Archive n’a pas été modifiée, mais au moins dès le début. 18 avril 2012, La FAQ de Twitter contenait une brève description de la manière dont ils évaluaient leur API de diffusion en continu:

Si vous utilisez la fonctionnalité de filtrage de l’API de diffusion en continu, vous recevrez en continu Y tweets correspondant à vos critères, où les tweets Y ne peuvent jamais dépasser 1% des X tweets publics dans le firehose au cours de la même «diffusion». seconde. »Si plusieurs tweets correspondant à vos critères sont diffusés, un message de limitation de débit indiquant le nombre de tweets en dehors de 1% est diffusé en continu.

Lorsque des sujets particuliers évoluent, le volume du filtre peut devenir si important qu'il est difficile pour Twitter de l'envoyer via une seule connexion. Et la notion de streaming seconde est né, où un client de streaming ne pouvait jamais recevoir plus de 1% des tweets publics envoyés à ce moment-là. À ce jour, ce 1% circule encore sous forme de sagesse populaire parmi les utilisateurs de l'API Twitter. Certaines personnes spéciales que Twitter aimait même avaient même illimité comptes où cette limite a été désactivée. Mais cela s'applique-t-il encore aujourd'hui?

Probablement pas. Quelque part entre 28 juillet 2012 et 3 août 2012 cette description a laissé tomber la mention de 1% et simplement parlé d'un résumé chapeau de streaming:

Les flux filtrés renvoient tous les Tweets correspondants jusqu'à un volume égal à la limite de diffusion. Si plusieurs tweets correspondent à vos critères, un message indiquant la limite de débit indiquant le nombre de tweets n’a pas été diffusé apparaît en streaming.

La documentation de Twitter a ensuite été complètement repensée afin que cette page ne soit plus disponible en dehors d’Internet Archive. Aujourd'hui, il existe un langage similaire dans le Filtrer les tweets en temps réel Documentation:

Ces messages indiquent qu'un flux filtré a associé plus de Tweets que sa limite de débit actuelle ne permet de diffuser. Les avis de limitation contiennent un nombre total de tweets non livrés depuis l'ouverture de la connexion, ce qui les rend utiles pour le suivi du nombre de termes de suivi, par exemple. Notez que les décomptes ne spécifient pas quels filtres prédisent les messages non livrés correspondants.

Une expérience

Le projet Documenting the Now développe des outils permettant aux archivistes et aux chercheurs de travailler avec Twitter. J'ai pensé qu'il serait utile d'essayer une expérience pour essayer de mesurer la précision des tweets supprimés rapportés. L'idée est que nous pourrions concevoir un concept pour informer nos utilisateurs en cas d'incertitude quant à ce qui est collecté.

Voici l'expérience:

  1. J'ai collecté des tweets du flux de filtrage pendant 15 minutes en utilisant un ensemble de mots clés qui déclencherait certainement les notifications de limite de taux. J'ai choisi de filtrer par fuck, merde, putain, atout parce que, bien, c'est Twitter.
  2. Immédiatement après les 15 minutes de collecte, j’ai recherché les tweets en utilisant une requête équivalente de l’API de recherche de Twitter, ainsi que des identificateurs de tweet minimum et maximum basés sur les données collectées à partir du flux de filtrage.
  3. Après la recherche terminée je immédiatement réhydraté les tweets d'origine collectés à partir de l'API de filtre pour avoir une idée du nombre de tweets supprimés et par conséquent non disponibles pour la recherche.

Voici les résultats dans un tableau, que je vais expliquer ci-dessous.

Recueilli (flux) ……… .43,448
Tarif limité ……………… 12,262
Hydraté ………………… .42,162
Supprimé …………………… ..1,286
Recueilli (Recherche) ……… .35,861

twarc a été utilisé pour la collecte des données. La connexion au flux de filtrage pendant 15 minutes a généré 43 448 tweets. Au cours de cette période, 838 avis de limitation ont été livrés, le dernier rapport signalant que 12 262 n’avaient pas été envoyés. Cela implique la taille attendue de l'ensemble de données complet.

Recueilli (flux) + tarif limité = taille attendue 
43 448 + 12 262 = 55 710

La collecte de données à partir de l'API de recherche a généré 35 861 tweets. Ceci est nettement inférieur aux 55 710 attendus. Qu'est-ce qui pourrait expliquer cet écart? La réhydratation du jeu de données initial obtenu à partir de l'API de filtre a généré 42 558 tweets. Ce qui signifie que 890 tweets (2%) ont été supprimés presque immédiatement et ne seraient pas disponibles pour la recherche. Pourquoi ces 42 558 tweets ne sont-ils pas disponibles à partir de l'API de recherche au lieu de 35 861?

Il existe clairement une différence entre le nombre de tweets que nous avons pu extraire de l'API de filtre, le rapport de tweets à débit limité et les résultats que nous pouvons obtenir à partir de l'API de recherche. C’est peut-être le résultat de ma requête et du fonctionnement interne de l’API de recherche par rapport au flux de filtrage? Ou peut-être que la fenêtre de 15 minutes était une période d’observation si courte que le max_id et depuis_id les paramètres que j'ai utilisés pour limiter ma requête de recherche ont été mal interprétés? C’est très difficile de dire de l’extérieur.

Les chercheurs en sciences humaines et sociales ne sont pas habitués à penser leur travail en termes de science de laboratoire - nous ne sommes pas des techniciens en blouse blanche, en solution de pipetage et en microscopie, après tout! Mais l'observation à grande échelle n'est possible qu'avec l'aide de technologies spécialisées. En tant que telle, la sociologie des sciences est revenue à la maison de manière surprenante. Les infrastructures que nous construisons pour regrouper et stocker les tweets (serveurs, scripts et bases de données) reflètent les architectures internes de systèmes commerciaux tels que Twitter. (Driscoll & Walker, 2014).

Comme Driscoll et Walker le soulignent, il faut aussi se demander comment cette expérience a été menée. Est-il possible que le fonctionnement interne de twarc, ou mon utilisation particulière dans cette expérience, puisse mieux expliquer le résultat? Oui, certainement. Il est également possible que mon stockage, mes interrogations et la comptabilisation des données soient en quelque sorte responsables. Donc, le défi pour nous alors que nous développons des outils et interfaces pour la collecte de données est qu'ils reflètent correctement cette incertitude retour à l’utilisateur, et évitez de faire des affirmations positivistes sur ces jeux de données.

Ce n'est pas parce que ces flux de données ont été générés par la logique, incrustés dans du code, que nous pouvons les décrire parfaitement, même avec des taux d'erreur et d'autres outils statistiques. Ces flux de données constituent un système algorithmique extrêmement complexe et historiquement situé, qui résiste aux affirmations commodes quant à leur comportement. Un peu comme un vrai ruisseau. Que demandons-nous vraiment lorsque nous demandons de la transparence dans ces systèmes (Ananny & Crawford, 2016)? Comment les limites techniques et conceptuelles de la transparence peuvent-elles être utilisées comme éléments de conception dans des outils de collecte de données? Si vous avez des idées ou des pistes de travail intéressantes dans ce domaine, contactez-nous!

Références

Ananny, M., et Crawford, K. (2016). Voir sans savoir: les limites de l'idéal de transparence et son application à la responsabilité algorithmique. Nouveaux médias et société. Récupérée de https://journals.sagepub.com/doi/abs/10.1177/1461444816676645

Driscoll, K. et Walker, S. (2014). Travailler dans une boîte noire: transparence dans la collecte et la production de grandes données Twitter. Journal international de la communication, 8, 1745-1764. Extrait de http://ijoc.org/index.php/ijoc/article/view/2171

Show More

SupportIvy

SupportIvy.com : Un lieu pour partager le savoir et mieux comprendre le monde. Meilleure plate-forme de support gratuit pour vous, Documentation &Tutoriels par les experts.

Related Articles

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Close
Close