From f1472dbd121e63f61b55d292c339a0b357f07f92 Mon Sep 17 00:00:00 2001 From: Karin van Es Date: Fri, 23 Oct 2020 11:18:13 +0200 Subject: [PATCH] 'content/Section 4 - Bot Logic/1-introduction.md' updaten --- content/Section 4 - Bot Logic/1-introduction.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/Section 4 - Bot Logic/1-introduction.md b/content/Section 4 - Bot Logic/1-introduction.md index ce1b27f..71a00d7 100644 --- a/content/Section 4 - Bot Logic/1-introduction.md +++ b/content/Section 4 - Bot Logic/1-introduction.md @@ -3,13 +3,13 @@ Slug: 01-s4-introduction Date: 2020-11-01 12:00 Summary: Bots as computational infrapunctures. -*Infrapuncture* is a helpful term at a time when there is a lot of discussion around the political roles of automated agents in communication platforms. Making a bot can be a way to probe and understand potential forms of interventions, create new imaginaries or deflate existing hegemonic structures. +*Infrapuncture* is a helpful term at a time when there is a lot of discussion around the political roles [perhaps be more specific, e.g. their undue influence in elections] of automated agents [maybe just call it bots?] in communication platforms. Making a bot can be a way to probe and understand potential forms of interventions, create new imaginaries or deflate existing hegemonic structures. -A bot is however always relying on the technical restrictions and possibilities of interaction defined by the infrastructure. In order to run a bot, a technical understanding of this infrastructure is therfor required. The API (Application Programming Inferface) is an important entry point here. This technical framework provides a programming interface to communicate with a system. The API can be understood as a *door protocol* that is designed by the owner of an infrastructure, which eventually defines the technical imaginary of a platform. (*We dive a bit deeper into API's in Section 6, [click here](/02-s6-step-2.html#APIs) to go their directly.*) +However, a bot always relies on the technical restrictions and possibilities of interaction defined by the infrastructure. In order to run a bot, a technical understanding of this infrastructure is therefor required. The API (Application Programming Inferface) is an important entry point here. This technical framework provides a programming interface to communicate with a system. The API can be understood as a *door protocol* that is designed by the owner of an infrastructure, which eventually defines the technical imaginary of a platform. (*We dive a bit deeper into API's in Section 6, [click here](/02-s6-step-2.html#APIs) to go their directly.*) -Before launching a bot into a digital environment, the bot maker does not only need to find a technical entry point, but also a social one. Writing a bot does not only imply technical knowledge about an API of a platform, it also implies a thorough understanding of what determines the possibilities of interaction and the social norms established within a social environment. +Before launching a bot into a digital environment, the bot maker does not only need to find a technical entry point, but also a social one. Writing a bot does not only imply technical knowledge about an API of a platform, [<- this part of teh sentence can be delted because repetivive] it also implies a thorough understanding of what determines the possibilities of interaction and the social norms established within a social environment. -By introducing *bot logic*, the aim of this section is to highlight the sociality that shapes (or is shaped by) bots. +By introducing [what we call - claim your term!] *bot logic*, the aim of this section is to highlight the sociality that shapes (or is shaped by) bots.