mb/bots-as-digital-infrapunctures
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

added difference between platofrm and infrastructure

Browse Source
This commit is contained in:
ccl 2020-11-05 16:27:50 +01:00
parent 747f7ab2f8
commit fed840aee3
2 changed files with 8 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
content/Section 3 - Bots/1-introduction.md
View File

@ -3,6 +3,8 @@ Slug: 01-s3-introduction
Date: 2020-11-01 12:00
Summary: What type of bots are being made?
Until now we have been referring to digital infrastructures. However, bots they are mostly contextualised as being active on a platform. In many ways digital infrastructures and platforms overlap in their invisibility, broad public usage, or extensibility. According to Platin et al (2016), both ways of framing offer helpful elements to each other. We are witnessing a platformisation of infrastructure in tandem with an infrastructuralisation of platforms through information technologies, where on the one hand, infrastructures start to splinter into services taken over by private enterprises, and on the other hand, platforms start taking on more responsibilities which were previously managed by the government. [^platin]. For the purposes of this online module, we are interested in the programmability (the capacity to go beyond the original designers' intention) and affordances (what is allowed ) of platforms combined with the public interest and responsibility of infrastructures. However, in order to highlight the importance of tools made solely for the purpose of optimising for a public, and not for corporate profit, we will from now on refer to platforms as digital communication infrastructures. Doing so avoids the ambiguity of describing the continual reparation of systems and their ecology as health. We are interested in the potential of bots to repair in the benefit of one or multiple publics.
Having just unfolded what infrastructural harms could be, we now move to exploring bots. When we say bots, we refer to software agents which automatise certain actions and can run autonomously or semi-autonomously. Some of the most mentioned examples are voice assistants such as Alexa or Siri, but they can also be web crawlers indexing the web or bots maintaining Wikipedia.
The particular bots we are interested in for this online module are those that act as an interface between the digital platform and human users, or what Andreas Hepp calls communicative robots[^hepp], robots that "are defined as autonomously operating systems designed for the purpose of quasi-communication with human beings to enable further algorithmic-based functionalities – often but not always on the basis of artificial intelligence" [page numbers].
@ -11,3 +13,7 @@ In this section, we will introduce Andreas Hepp, professor of media and communic
[^hepp]: Hepp, Andreas. "Artificial companions, social bots and work bots: communicative robots as research objects of media and communication studies"
*Media, Culture & Society* Volume 42 (2020): 1410-1426. <https://journals.sagepub.com/doi/full/10.1177/0163443720916412>
# Footnotes
[^platin]: Infrastructure studies meet platform studies in the age of Google and Facebook.

2
content/Section 4 - Bot Logic/1-introduction.md
View File

@ -5,7 +5,7 @@ Summary: Bots as computational infrapunctures.
*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.
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 therefore 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 therefore required. The API (Application Programming Interface) 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 there 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, [<- 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.