Datainsamlingen för Twittercensus 2014 går framåt i snabbt takt. Nytt för i år är att data samlas in för svenska, norska, danska och finska samtidigt – vilket också innebär att relationerna mellan konton över språkgränserna kommer att sparas. Detta innebär i sin tur att det kommer att vara möjligt att göra en karta över hur språkområdena hänger samman. Datamängden ökar förstås rejält, så vad som blir tekniskt möjligt att göra i slutändan är lite oklart.

Lite ironiskt går datainsamlingen betydligt snabbare i år än tidigare år. Genom att be om hjälp, och få fler än 1000 personer att bidra genom att logga in med sina Twitterkonton, kan vi nu ställa väldigt många fler frågor  till Twitters API än vad som var möjligt tidigare. Hastigheten ligger på cirka 100 000 för närvarande, och då används lång i från hela kapaciteten. För varje sammankopplat konto ger twitter oss möjlighet att göra 180 förfrågningar/15 minuter för tweets och 15 förfrågningar/15 minuter efter följare och vänner. I skrivande stund finns över 1 miljon twitterkonton, 200 miljoner relationer och 50 000 000 tweets i databasen, och den fylls på varje sekund…

Själva datainsamlingen går till så att ett kontrollskript på en server (tack @cloudroyal!)  startar upp till 150 parallella processer. Dessa processer får en uppgift från en kö. Uppgiften är antingen att hämta och analysera tweets, hämta ett kontos relationer, eller att uppdatera kontoinformation. Processen utför sitt uppdrag, sparar resultatet i databasen och stänger ner sig själv.

För att hålla koll på hur processerna går framåt finns en rad olika övervaknings och debug-funktioner. Den två enklaste, som övervakas frekvent, är en som visar antalet konton i de olika köerna samt en övervakning av antalet förfrågningar som görs till twitters API varje timme.

Antal anrop till Twitters api per timme
Övervakning av köer på Twittercensus

Twittercensus är Sveriges största mätning av Twitter och genomförs årligen av Intellecta Corporate. Vi vill också passa på att tacka Cloud Royale som tillhandahåller serverkapacitet för insamlingen.

Layout

Hur krafter verkar på noder

För layouten av grafen används ”Force Atlas 2″, en kraft-baserad algoritm. I grafen tilldelas varje nod (twitterkonto) en tilldragande och en bortskjutande kraft. Noden kommer att attrahera andra konton den har relation till (följer/följs av). Omvänt kommer noder utan relationer att stötas bort. Om två konton ömsesidigt följer varandra är den attraherande kraften dubbelt så stark som om bara en av dem följer varandra. Hur krafterna verkar kan ses i bilderna där twitterkontona som med relationer (A och B) dras till varandra, medan det andra kontot (C) skjuts bort. Krafterna är markerade med röda pilar. Därtill kommer en gravitation som drar noderna mot mitten.

Den stora grafen fungerar på precis samma sätt som illustrationen, men är förstås väldigt mycket mer komplicerad med miljontals relationer mellan de drygt 50 000 kontona. Men principen är den samma – konton som följer varandra dras till varandra, medan andra konton skjuts bort.

Kluster

För att identifiera  kluster använder vi ”Modularity” i GephiBeräkningen [pdf]  söker efter delnätverk (kluster) med hög modularitet – det vill säga med stor andel kopplingar (följer/följs) mellan twitterkontona inom klustret och låg andel kopplingar till twitterkonton i andra kluster. Den här beräkningen görs i flera steg. När de olika klustrena skapats tilldelas varje kluster en slumpmässig färg. Att två färger är snarlika (ljusgrön och mörkgrön) betyder ingenting. En del konton blir ensamma i sina kluster, medan andra kluster består av väldigt många konton, allt beroende på vilket som ger högst modularitet.

Det är viktigt att komma ihåg att de kluster vi har pratat om är tolkningar av resultaten av en beräkning. Det är inte jag, eller någon annan, som stoppat in konto x i kategori y. Det är en framräknad tillhörighet för det enskilda kontot baserat på, något förenklat, att relationerna till andra konton inom subnätverket större än till de utanför. Etiketterna på klustren (”bubblan”, ”sport”, etc) är etiketter jag (och andra) satt på de olika kluster efter att ha tittat på vilka som ingår och inte. Andra personer kan anse att ett kluster borde kallas för något annat.

Varför hamnar en del konton i andra kluster?

Som beskrivits ovan är det två olika metoder som används för att göra klusterindelningen och för att göra layouten av grafen. Layouten tar inte hänsyn till kluster på något sätt, utan använder sig bara av de ovan beskrivna krafterna. För den som tittar på grafen så är det dock tydligt att olika kluster (färger) i stor utsträckning hamnar tillsammans. En annan skillnad är att kluster är ”antingen eller” – antingen tillhör ett konto kluster X eller kluster Y. I layouten finns en hel skala däremellan. Om man tittar på det orangea klustret är det exempelvis tydlig skillnad mellan de högra delarna som innehåller många journalister och politiker, och de vänstra som är mer teknikorienterade. Ett konto som ligger mellan två kluster, alltså har många relationer i båda, ska också hamna i gränslandet.

Men alla konton måste hamna någonstans, och konton med få relationer kan finna att de blir bortskjutna till en position snarare än att de dras till den. Konton som inte har en relation till konto Z skjuter alltså bort kontot, och även om kontot följer ett annat konto så kommer det kontots ”grannar” att trycka bort noden. På så sätt kan konton hamna långt bort från andra det följer. Detta kan illustreras med den röda noden som i grafen nedan ”skjuts bort” av de båda lila. Trots att den röda bara har en relation (till den gröna noden) hamnar den inte granne med denna – utan hamnar istället närmre de båda lila, som den alltså inte har relationer till.