Inzet van sociale media bij incidenten
Technische mogelijkheden voor detectie van incidenten en het verzamelen, opslaan en analyseren van sociale media data
Afstudeerscriptie | Rense Bakker | 13 januari 2013
Colofon
R. Bakker Studentnummer: 0783817 E-mail werk: r.bakker@hkv.nl E-mail thuis: b.rense@gmail.com Opleiding: MediaTechnologie
Afstudeeropdracht: Inzet van sociale media bij incidenten, Technische mogelijkheden voor detectie van incidenten en het verzamelen, opslaan en analyseren van sociale media data
Bedrijf: HKV Lijn in water Botter 1129 8232 JN Lelystad Afdeling: Crisisbeheersing Begeleider: Dr. ir. T. Terpstra E-mail: t.terpstra@hkv.nl
Opleidingsinstituut: Hogeschool Rotterdam
Communicatie, Media en Informatietechnologie Wijnhaven 99
3011 WN Rotterdam Begeleider: Ing. S.M. Hekkelman E-mail: s.m.hekkelman@hr.nl
Plaats, datum: Lelystad, 13 januari 2013 Status: Definitief v2.1 [gecorrigeerd]
Fotografie omslag: R. Bakker
Voorwoord | 3
Voorwoord
De keuze voor het onderwerp crisisbeheersing is vrij ongewoon voor een Media Technoloog. Daarom is het interessant om toe te lichten hoe ik tot deze keuze gekomen ben. Eigenlijk heb ik deze keuze in juli 2011 gemaakt. Ik koos toen voor het volgen van het innovation-lab Flood Control aan de Hogeschool Rotterdam. Dit project was opgezet binnen een speciaal traject voor excellente studenten die meer uit hun studie wilden halen. Ik wilde graag zien wat ik met mijn ICT achtergrond kon betekenen in de watersector. Tijdens het innovation-lab werd mijn interesse voor de toepassing van ICT in de watersector en vooral in de crisisbeheersing verder versterkt. Daarom wil ik ten eerste Leander Ernst (Docent watermanagement), Judith de Bruijne (Arcadis) en het voltallige innovation-lab team: Nikéh Booister, Carola Bouwens, José Kooi, Ingrid Stolk, Darja Tretjakova en Evelien van Weele bedanken voor de begeleiding en de fantastische samenwerking die uiteindelijk geleid heeft tot mijn keuze voor dit afstudeeronderwerp.
Ten tweede wil ik mijn beide afstudeerbegeleiders, Teun Terpstra (HKV) en Sandra Hekkelman (Hogeschool Rotterdam), bedanken voor de begeleiding bij het schrijven van de scriptie. De kritische blik van Teun Terpstra heeft mij enorm geholpen om richting te geven aan dit onderzoek.
Verder wil ik Richard Stronkman bedanken voor het beschikbaar stellen van de Twitter-data van het Hoogwater in Groningen in 2012. Zonder deze data was het onderzoek nooit van de grond gekomen.
Ook de kritische blikken, de steun en hulp van Eric van Kuijeren, en mijn beide ouders hebben mij enorm geholpen om de puntjes op de ï te zetten van deze afstudeerscriptie.
Inhoudsopgave | 5
Inhoudsopgave
Samenvatting 7
Verklarende woordenlijst 9
1. Inleiding 11
1.1. Probleemstelling 11
1.2. Doelstelling en
onderzoeksvragen 12
1.3. Onderzoeksopzet 12
1.4. Leeswijzer 12
2. Definities 13
2.1. Sociale media 13
2.2. Incidenten en rampen 14 2.3. Monitoring applicaties 15
3. Relevante bronnen bij
incidenten 16
3.1. Selectie criteria 16 3.2. Score en selectie van media
voor detectie 18
3.3. Score en selectie van media
voor data-enrichment 18
3.4. Conclusie 19
4. Methoden voor detectie van
incidenten 20
4.1. Keywords burst detection 20 4.2. Cluster classification 21
4.3. P2000 21
4.4. Conclusie 21
5. Verzamelen van sociale
media data 22
5.1. Authenticatie 22
5.2. Response-types 22
5.3. Metadata 23
5.4. Rate-limiting 23
5.5. Conclusie 24
6. Opslag van sociale media data 25
6.1. Keuze van database 25 6.2. Representatie vandocumenten in de database 26
6.3. Terug vinden van data 27
6.3.1. MapReduce 27
6.3.2. Zoeken en filteren met
ElasticSearch 27
6.4. Database performance 28 6.5. Voorwaarden en richtlijnen
voor opslag van sociale
media data 28
6.6. Conclusie 28
7. Filteren en analyseren van
sociale media data 29
7.1. Thema filters 29
7.1.1. Schade en slachtoffers 29 7.1.2. Informatiebehoefte 30
7.1.3. Aangeboden hulp 30
7.1.4. Gevraagde hulp 32
7.1.5. Emotionele uitingen 32 7.2. Natural Language Processing 33
7.3. Machine Learning 34
7.4. Betrouwbaarheidsanalyse en autoriteit van gebruikers 34
7.5. Conclusie 34
8. Conclusie 36
9. Aanbevelingen 38
Literatuurlijst 39
Bijlagen 41
Bijlage 1: Uitslagen beoordeling classificatie
thema filters 43
Bijlage 2: Bestaande
monitoring applicaties 45 Bijlage 3: Specificaties applicatie 47 Bijlage 4: Features applicatie 49 Bijlage 5: Technisch ontwerp
applicatie 51
Bijlage 6: Screenshots applicatie 53
Samenvatting | 7
Samenvatting
Tijdens incidenten kan in korte tijd een enorme hoeveelheid data gegenereerd worden door mensen over de hele wereld. Ook in Nederland werd veel getwitterd bij incidenten, bijvoorbeeld bij de Brand bij Chemiepack in Moerdijk, waar ruim 33.000 tweets verzonden werden met betrekking tot de ramp (Stronkman 2010). Alle cijfers van de afgelopen jaren vallen echter in het niet bij de 20 miljoen tweets die verstuurd werden over orkaan Sandy in de Verenigde Staten (AD.
nl 2012). Tijdens incidenten zijn sociale media voor burgers dus een belangrijk middel voor communicatie geworden. Voor hulpverleners en instanties die betrokken zijn bij crisisbeheersing schept dit nieuwe mogelijkheden. Sociale media stellen hen niet alleen in staat om informatie te delen, maar ook om informatie te ontvangen.
Om dit succesvol te kunnen doen moet de grote stroom van sociale media data gefilterd worden zodat waardevolle informatie beter gevonden kan worden. Een applicatie zou hierbij kunnen helpen.
Vijf aspecten worden onderzocht, namelijk: wat zijn relevante bronnen van informatie tijdens incidenten in Nederland, welke methodes zijn er voor het automatisch detecteren van incidenten, hoe kan de informatie uit de verschillende relevante bronnen efficiënt verzameld worden, hoe kan de gevonden informatie efficiënt worden opgeslagen en welke technieken zijn er om waardevolle informatie te filteren uit de grote hoeveelheid verzamelde sociale media data.
Om de relevante bronnen te vinden, wordt eerst onderscheid gemaakt tussen twee verschillende doelen waarvoor de bronnen gebruikt worden, namelijk: detectie van incidenten en data- enrichment (verrijking van informatie).
Vervolgens worden 25 bronnen getoetst aan de hand van 9 criteria. Twitter wordt geselecteerd als beste bron voor de detectie van incidenten.
Voor data-enrichment worden 11 bronnen geselecteerd, namelijk: Facebook, Twitter, Google+, Youtube, Flickr, Wikipedia, Blogger, Wordpress, Tumblr, NOS.nl en Nu.nl.
Voor de detectie van incidenten worden twee methoden onderzocht, namelijk: Keywords burst detection en Cluster Classification. De eerste methode wordt gekozen omdat deze methode het mogelijk maakt om incidenten te detecteren uit berichten die voldoen aan vooraf opgestelde zoektermen. Daardoor hoeft minder data verzameld te worden om incidenten te detecteren en is de hoeveelheid data, die na analyse niet relevant blijkt, minder groot. Door deze keuze voor Keywords burst detection is er een kans dat relatief kleine incidenten niet gedetecteerd kunnen worden; als oplossing hiervoor wordt voorgesteld om P2000 bronnen te volgen op Twitter.
Om de data uit verschillende bronnen efficiënt te verzamelen wordt gekeken naar vier obstakels:
authenticatie, response-types, verschil in metadata per bron en rate-limiting. De verschillen in authenticatie methodes en response-types per bron kunnen relatief eenvoudig worden opgelost door hier rekening mee te houden bij het ontwikkelen van een applicatie. Wat betreft de verschillen in metadata per bron wordt er voor gekozen om hier rekening mee te houden bij het opslaan van de berichten, de metadata wordt verder intact gelaten. Het grootste verschil tussen de verschillende bronnen zit in de limieten die zij stellen voor de hoeveelheid data die per tijdseenheid verkregen kan worden (rate-limiting). Vooral voor de detectie bron is het belangrijk dat continu een grote hoeveelheid data verzameld kan worden. De Twitter API hanteert een ruime limiet.
Bij de opslag van de data moet rekening worden gehouden met de verschillen in metadata van de berichten uit verschillende bronnen. Daarom wordt gekozen voor een zogenaamde “document- store” die toestaat om documenten op te slaan die qua structuur van elkaar verschillen. Uit de beschikbare document-stores wordt CouchDB gekozen omdat deze database een robuuste infrastructuur heeft die ook bij plotselinge toename van het aantal schrijf query’s stabiel blijft. Om data terug te vinden kan gebruik
8 | Samenvatting
gemaakt worden van de, op Apache Lucene gebaseerde, zoekmachine “ElasticSearch”. Met deze zoekmachine kan de data in een CouchDB database namelijk automatisch geïndexeerd worden.
Om waardevolle informatie te vinden in de verzamelde data worden vijf filterthema’s besproken, namelijk: “schade en slachtoffers”,
“informatiebehoefte”, “aangeboden hulp”,
“gevraagde hulp” en “emotionele uitingen”. Er wordt gekeken of de verzamelde berichten in deze thema’s ingedeeld kunnen worden door filters te ontwikkelen op basis van eenvoudige Nederlandse grammaticaregels. De resultaten van de uitgevoerde analyse laten zien dat vooral de sarcastische toon in berichten een probleem is bij de classificatie van berichten met deze grammaticaregels. Een andere optie is om een model te trainen, met Natural Language
Processing en Machine Learning, daarmee kunnen berichten automatisch ingedeeld worden in een van de vijf thema’s. Een nadeel hierbij is dat het model opnieuw getraind moet worden wanneer een nieuw thema wordt toegevoegd.
Door het onderzoeken van de vijf aspecten wordt stap voor stap een strategie uiteengezet voor het detecteren van incidenten en het verzamelen, opslaan en analyseren van grote hoeveelheden sociale media data. Deze strategie wordt toegepast in een applicatie die hulpverleners en instanties, die betrokken zijn bij crisisbeheersing, kan helpen om waardevolle informatie te ontdekken door de grote stroom van sociale media berichten te filteren en te analyseren.
Verklarende woordenlijst | 9
Verklarende woordenlijst
API Application Programming Interface, een interface die de toegang definiëert tot functionaliteiten in het doelsysteem en zo andere systemen in staat stelt te communiceren met het doelsysteem.
Artificial Intelligence Artificial intelligence of kunstmatige intelligentie is een verzamelnaam van software als expertsystems, neurale netwerken etc waarmee men de computer creatief wil leren denken
Cell broadcasting Een techniek om tekstberichten te versturen naar mobiele telefoons Cloud-based service Een service die wordt aangeboden via het web
Dataset Een verzameling van gegevens
Engagement Rate De mate waarin een merk of persoon in staat is om gebruikers van sociale media te binden
Entity Nederlands: Entiteit, Een beschrijving van een object in de werkelijkheid (personen, dingen, gebeurtenissen)
JSON JSON staat voor JavaScript Object Notation en is een deelverzameling van de programmeertaal JavaScript. Het wordt gebruikt voor het uitwisselen van datastructuren
Oauth OAuth (Open Authorization) is een open standaard voor autorisatie.
Opensource Software waarvan de broncode vrij toegankelijk is Parser Programma dat tekst ontleedt in syntactische delen
REST Representational State Transfer, is een stijl in de software architectuur voor het worldwide web. REST is het dominate ontwerp model geworden voor webservices
Return on Investment De verhouding tussen het rendement en de investering
RSS RSS is een afkorting die meestal staat voor Really Simple Syndication. Het is een formaat dat het mogelijk maakt om de meest recente berichten van een site op een gestandaardiseerde manier (in XML formaat) aan te bieden URL Uniform Resource Locator, een adres dat verwijst naar een pagina op het
internet
Webservice Bij een webservice wordt een API van een applicatie via het internet beschikbaar gesteld voor andere applicaties
XML eXtensible Markup Language, een standaard voor het uitwisselen van data tussen computers
Inleiding | 11
1. Inleiding
Tijdens het Pukkelpop festival in 2011 werden duizenden berichten geplaatst op Twitter waarin slaapplaatsen, vervoer of gratis Wi-Fi werd aangeboden aan de slachtoffers van het Pukkelpop incident (Terpstra, et. al. 2011).
Sociale media stellen burgers in staat om tijdens incidenten hulp aan te bieden en hun beleving te delen met anderen over wat zij zien gebeuren.
Het Pukkelpop incident is niet het enige voorbeeld waarbij sociale media een belangrijke rol speelden. Bij eerdere rampen in bijvoorbeeld de VS, Japan (Kessler 2011) en Haïti (Calderón 2010) werden verschillende sociale media gebruikt door burgers. Bijvoorbeeld om hulpacties te organiseren, informatie te delen of om te controleren of dierbaren ongeschonden waren. Sociale media zijn voor burgers een belangrijk communicatiemiddel geworden tijdens incidenten. In Nederland schept dit nieuwe mogelijkheden voor hulpverleners en instanties die betrokken zijn bij crisisbeheersing.
Sociale media stellen hen niet alleen in staat om informatie te delen, maar ook om informatie te ontvangen. Door de nieuwe mogelijkheden die sociale media bieden, kunnen misschien ook problemen uit het verleden opgelost worden.
Een voorbeeld hiervan zijn de problemen met de coördinatie van burgerhulp tijdens het hoogwater van 1995 (Groenewegen-ter Morsche 2010).
Tijdens incidenten kan in korte tijd een enorme hoeveelheid data gegenereerd worden door mensen over de hele wereld. Ook als alleen naar Nederland gekeken wordt is de hoeveelheid data die per minuut gegenereerd kan worden enorm. Nederlandse twitteraars zijn, volgens onderzoek van Semiocast, de meest actieve van de wereld (Semiocast 2012). Dit blijkt wel uit de hoeveelheid tweets die geplaatst werden tijdens drie recente rampen, zoals te zien in tabel 1.1.
Tijdens de brand bij Chemiepack in Moerdijk werden ruim 33.000 tweets verstuurd met betrekking tot de ramp (Stronkman 2010). Deze getallen vallen echter in het niet bij de 20 miljoen tweets die verstuurd werden tijdens orkaan Sandy die recentelijk grote schade aanrichtte aan de oostkust van de Verenigde Staten (AD.
nl). Door de grote hoeveelheid berichten bieden sociale media een schat aan informatie tijdens incidenten. Niet alle berichten zijn echter relevant. Het is lastig geworden om handmatig de berichten te vinden die waardevolle informatie bevatten (Corvey 2010).
Tabel 1.1. Aantal tweets met betrekking tot een drietal grote incidenten uit de afgelopen 2 jaar Incident Hoogwater Groningen
2012 Brand Chemiepack
Moerdijk 2011 Pukkelpop 2011
Totaal aantal tweets ~33000 ~117000 ~1560001
1 Getallen afkomstig uit onderzoek Terpstra et. al. (2011).
1.1. Probleemstelling
Burgers hebben sociale media omarmd tijdens incidenten en rampen om informatie met elkaar te delen. De interactiviteit van sociale media biedt nieuwe mogelijkheden voor hulpverleners en instanties die betrokken zijn bij crisisbeheersing. Om deze nieuwe mogelijkheden beter te benutten, is het wenselijk om de grote
hoeveelheid berichten die tijdens incidenten geplaatst worden op sociale media te filteren.
Daarbij kom ik tot de volgende probleemstelling:
“Zou een applicatie ontwikkeld kunnen worden die kan helpen bij het analyseren van de grote hoeveelheid sociale media berichten zodat, voor crisisbeheersing, waardevolle informatie gevonden kan worden?”
12 | Inleiding
1.2. Doelstelling en onderzoeksvragen
Om antwoord te geven op de probleemstelling zal onderzocht worden of technieken uit de ICT mogelijkheden bieden om een monitoring applicatie te ontwikkelen voor incidenten in Nederland.
Daarbij is van belang om te onderzoeken wat de technische mogelijkheden zijn voor het detecteren van incidenten en het verzamelen, opslaan en analyseren van grote hoeveelheden sociale media data. De volgende deelvragen worden daarom behandeld:
1. Bronnen: Wat zijn relevante bronnen van informatie tijdens incidenten in Nederland;
2. Detectie: Welke methodes zijn er voor het automatisch detecteren van incidenten;
3. Verzamelen: Hoe kan de informatie uit de verschillende relevante bronnen efficiënt verzameld worden;
4. Opslaan: Hoe kan de gevonden informatie efficiënt worden opgeslagen;
5. Analyseren en filteren: Welke technieken zijn er om waardevolle informatie te filteren uit de grote hoeveelheid verzamelde sociale media data.
1.3. Onderzoeksopzet
Dit onderzoek wordt uitgevoerd in de periode van 3 september 2012 tot 28 januari 2013. Er wordt voornamelijk een vergelijkend onderzoek gedaan naar verschillende methoden en technieken voor het detecteren van incidenten en het verzamelen, opslaan en analyseren van sociale media data behorende bij deze incidenten. Dit vergelijkende onderzoek zal deels bestaan uit een literatuuronderzoek naar de verschillende methoden en technieken.
Naast literatuuronderzoek wordt ook een analyse gemaakt van 302 tweets uit een dataset van 115904 berichten van het Hoogwater in Groningen in 2012 en de brand bij Chemiepack in Moerdijk in 2012. De 302 tweets worden door de applicatie geclassificeerd in vijf thema’s.
Daarna wordt per tweet een vraag gesteld aan twee beoordelaars. Deze beoordelaars geven antwoord op deze vraag zonder dat zij elkaar kunnen beïnvloeden. De beoordelingen van de beoordelaars worden daarna met elkaar en
de uitkomst van de applicatie vergeleken en daarna wordt de kappa coëfficiënt1 berekend.
Met de verkregen, voor kans gecorrigeerde, overeenkomst kan bepaald worden wat de accuraatheid is van de classificatie door de applicatie.
1.4. Leeswijzer
Voorafgaand aan de beantwoording van de deelvragen worden in hoofdstuk twee een aantal definities uiteengezet. Zo wordt onder andere vastgelegd wat in dit onderzoek bedoeld wordt met sociale media en incidenten. Dit onderzoek is ingedeeld in vijf opeenvolgende stappen die antwoord geven op de vijf deelvragen, namelijk:
selecteren van bronnen, detectie van incidenten, verzamelen van data, opslag van data en het filteren en analyseren van data. Deze vijf stappen worden behandeld in de hoofdstukken drie tot en met zeven en geven achtereenvolgens antwoord op de vijf deelvragen. Tot slot wordt in de conclusie antwoord gegeven op de probleemstelling.
1 Een maat voor de kansgecorrigeerde overeenkomst tussen beoordelingen
Definities | 13
2. Definities
Om het onderzoek af te bakenen wordt een definiëring gegeven van drie belangrijke onderwerpen. In paragraaf 2.1 wordt uiteengezet wat in dit onderzoek bedoeld wordt met sociale media. Daarnaast wordt een classificatie gegeven van verschillende typen sociale media.
In paragraaf 2.2 worden monitoring applicaties besproken en in paragraaf 2.3 wordt ingegaan op wat er in dit onderzoek bedoeld wordt met een incident.
2.1. Sociale media
In de loop der jaren is onduidelijkheid ontstaan over wat er allemaal onder de noemer sociale media valt. Vaak wordt bij sociale media vooral gedacht aan sites zoals MySpace en Facebook.
Deze sites vallen in de categorie Social Networking Sites. Onder de noemer sociale media vallen ook andere categorieën. De definitie voor sociale media die in dit onderzoek gehanteerd wordt is te vinden in het werk van Kaplan en Haenlein:
“Sociale media zijn een groep web- based applicaties die bouwen op de ideologische en technologische funderingen van web 2.0 en die het maken van User-generated content faciliteren.” (Kaplan en Haenlein.
2009).
Deze definitie geeft duidelijk de relatie aan tussen twee belangrijke termen, web 2.0 en user-generated content. Deze termen worden vaak door elkaar gehaald. Web 2.0 beschrijft geen nieuwe versie van het worldwide web (WWW) maar geeft een verandering aan in de manier waarop wij het worldwide web zijn gaan gebruiken. In web 2.0 staat interactie met de gebruiker centraal. Websites zijn geen statische pagina’s meer die gebruikt worden om informatie te delen, maar stellen de gebruiker in staat om ook informatie toe te voegen of aan te passen. De informatie die zo ontstaat wordt ook wel “user-generated content” genoemd.
Er zijn dus verschillende categorieën sociale media. Kaplan en Haenlein geven een goede classificatie voor deze verschillende categorieën.
Zij maken een verdeling in: Social Networking Sites (zoals Facebook en Twitter), Content Communities (zoals Youtube), Collaborative Projects ( zoals Wikipedia), blogs, Virtual Social Worlds (zoals Second Life) en Virtual Game Worlds (zoals World of Warcraft). Deze laatste twee categorieën worden in dit onderzoek buiten beschouwing gelaten omdat ze niet relevant zijn als bronnen tijdens incidenten. Wat wel opvalt aan de classificatie van Kaplan en Haenlein is dat een aantal categorieën, zoals online fora en chatrooms, niet genoemd worden. Als gekeken wordt naar de definitie dan behoren online fora zeker ook tot de sociale media. In dit onderzoek wordt naast deze sociale media categorieën ook gekeken naar nieuwssites. Hoewel nieuwssites niet als “sociale media” bestempeld kunnen worden zijn deze wel van belang voor de informatievoorziening tijdens incidenten en dus relevant voor dit onderzoek. Er worden dus vijf categorieën sociale media vastgelegd voor dit onderzoek, namelijk: Social Networking Sites, Content Communities, Collaborative Projects, blogs en online fora.
Social Networking Sites
Er zijn meerdere definities voor Social Networking Sites, zoals die van Boyd (2008) of Kaplan en Haenlein (2009). Het lijkt lastig om een eenduidige definitie te geven voor Social Networking Sites. Dit komt omdat veel Social Networking Sites ook facetten van andere sociale media categorieën, zoals blogs en Content Communities, in zich hebben. Via Facebook kunnen bijvoorbeeld ook foto’s gedeeld worden.
Toch is Facebook een Social Networking Site en geen Content Community. Voor dit onderzoek wordt daarom de volgende definitie gebruikt om een duidelijk onderscheid te maken tussen Social Networking Sites en andere sociale media categorieën:
14 | Definities
“De groep van sociale media waarbij het maken van vrienden (of andere verbindingen) het hoofddoel is van de gebruikers.”
Met deze definitie onderscheiden Social Networking Sites zich duidelijk van de Content Communities waar het delen van content het hoofddoel is. Bekende Social Networking Sites zijn: Twitter, Facebook, Google+ en LinkedIn.
Content Communities
Voor Content Communities wordt nagenoeg dezelfde definitie gehanteerd als voor Social Networking Sites. De enige uitzondering is dat het bij de Content Communities draait om de inhoud in plaats van het aantal vrienden. Content Communities zijn dus:
“De groep van sociale media waarbij het delen van inhoud, zoals foto’s en video’s, het hoofddoel is van de gebruikers.”
Bekende Content Communities zijn Youtube en Flickr, maar bijvoorbeeld ook Slideshare, Photobucket, Vimeo, Scribd en Imgur.
Collaborative Projects
“Collaborative projects maken het gezamenlijk en tegelijk creëren van content mogelijk door meerdere gebruikers” (Kaplan en Haenlein, 2009).
Onder deze definitie vallen vooral de verschillende wiki’s en Online Collaborative Drawing Tools. Veel Online Project Management en Collaboration Tools vallen niet onder de noemer sociale media omdat ze niet publiek toegankelijk zijn.
Blogs
“Blogs zijn een speciaal type
websites die doorgaans, met datum bestempelde, artikelen weergeven in omgekeerde chronologische volgorde.” (Kaplan en Haenlein, 2009).
Een blog is eigenlijk een soort online dagboek.
De meeste blogs zijn publiek toegankelijk, sommige blogs gaan alleen over een specifiek onderwerp en soms worden blogs ook gebruikt door organisaties als nieuwsbulletin. Populaire blogging-platformen zijn onder andere Wordpress, Blogger, TypePad, LiveJournal en Tumblr. Alle blogs kunnen gevolgd worden door te abonneren op de zogenaamde “RSS feed” van het blog.
Online fora
Voor dit onderzoek wordt de volgende definitie gehanteerd voor online fora:
“Een web-based platform waar gebruikers lid van kunnen worden om te discussiëren over verschillende onderwerpen door zelf een
onderwerp te starten of door te reageren op onderwerpen die gestart zijn door anderen.”
Er zijn vele miljoenen fora op het web. Helaas zijn er geen platformen beschikbaar die deze fora bundelen en het mogelijk maken om de verschillende fora te doorzoeken.
2.2. Incidenten en rampen
In dit onderzoek wordt het woord “incident”
veel gebruikt. Soms zou ook het woord “ramp”
gebruikt kunnen worden. Het woord incident is alles omvattend en wordt daarom gebruikt om verwarring te voorkomen over het moment waarop een gebeurtenis een ramp wordt. Een
“bijna” ramp of een dreigende ramp is ook een incident. De betekenis van het woord “incident”
is vastgelegd in de volgende definitie:
“Een storend voorval” (van Dale).
Definities | 15
2.3. Monitoring applicaties
Omdat het doel van dit onderzoek is om technieken aan te dragen die bruikbaar zijn bij het ontwikkelen van een applicatie, is het interessant om te kijken naar bestaande applicaties. In dit onderzoek wordt gekeken naar twee groepen van applicaties die relevant kunnen zijn tijdens incidenten. In de bijlagen is een overzicht te vinden van alle applicaties die voor dit onderzoek onderzocht zijn.
De eerste groep zijn de sociale media monitoring applicaties. De applicaties in deze groep stellen de gebruiker in staat om data te verzamelen van sociale media op basis van bepaalde zoekcriteria.
Veel van de applicaties in deze categorie zijn ontwikkeld vanuit een marketing perspectief en bieden opties voor het berekenen en tonen van de zogenaamde “Return on Investment” (ROI) en
“Engagement Rate” (ER). Deze applicaties worden door marketeers gebruikt om de effectiviteit van een reclamecampagne te bekijken of om te zien wat het imago is op sociale media ten aanzien van een bepaald merk of een organisatie. Sommige van deze applicaties bieden de gebruiker ook de mogelijkheid om webcare te bedrijven via sociale media. Dat wil zeggen dat de gebruiker opties heeft om te reageren op berichten of om
berichten toe te wijzen aan andere personen binnen de organisatie. Applicaties die gericht zijn op webcare geven vaak het sentiment van een bericht aan zodat een organisatie snel negatieve of positieve berichten kan vinden over het merk of de organisatie.
De tweede groep zijn de zogenaamde crisismapping applicaties. Hoewel dit onderzoek voornamelijk gericht is op het monitoren van sociale media tijdens incidenten, worden crisismapping applicaties ook vaak genoemd in relatie tot incidenten. Bij crisismapping wordt informatie over een crisis of incident weergegeven op een kaart. Deze informatie kan uit verschillende bronnen komen. Bij Ushahidi, een van de meest bekende crisismapping applicaties, komt de informatie vaak van burgers. Dit wordt ook wel crowdsourcing genoemd. Crowdsourcing kan een effectieve manier zijn om veel informatie te verwerken als deze informatie voor computers lastig te interpreteren is. Ushahidi wordt veel gebruikt in situaties waar sprake is van (valse) geruchten en veel onzekerheden (Okolloh 2009).
Ook Google houdt zich sinds enige tijd bezig met crisismapping. In figuur 2.1 is een screenshot te zien van de Google crisismap voor orkaan Sandy.
Figuur 2.1. Screenshot van Google crisismap voor orkaan Sandy
16 | Relevante bronnen bij incidenten
3. Relevante bronnen bij incidenten
In dit hoofdstuk wordt antwoord gegeven op deelvraag één “Wat zijn relevante bronnen van informatie tijdens incidenten in Nederland”. Er zijn vele verschillende sociale media. Niet alle sociale media zijn echter relevant om te volgen tijdens incidenten. Om een keuze te maken welke sociale media wel relevant zijn om te volgen en welke niet, worden in dit hoofdstuk een aantal criteria opgesteld waaraan de verschillende sociale media bronnen getoetst kunnen worden.
Daarna wordt aan de hand van deze criteria een score gegeven aan een groot aantal sociale media, waarna een selectie gemaakt wordt die in de REST van dit onderzoek gebruikt zal worden.
Omdat het onmogelijk is om alle bestaande sociale media mee te nemen in het selectieproces is eerst een voorselectie gemaakt. Deze voorselectie wordt gemaakt per sociale media categorie en is vooral gebaseerd op welke sociale media bij ons direct geassocieerd worden met de categorie in kwestie. In dit hoofdstuk wordt vaak het woord bron of medium gebruikt om te verwijzen naar een sociale media site. De Social Networking Site “Hyves” wordt in dit onderzoek buiten beschouwing gelaten omdat het aantal gebruikers van Hyves de afgelopen jaren sterk is afgenomen. Het voortbestaan van Hyves is daarmee onzeker geworden (Oosterveer 2012).
3.1. Selectie criteria
Er worden verschillende selectiecriteria gebruikt om relevante bronnen te vinden voor het detecteren van incidenten en voor het zogenaamde “data-enrichment” proces. Data- enrichment is een proces waarbij de data die gebruikt is om een incident te detecteren wordt verrijkt met informatie uit andere bronnen.
Per criterium wordt in de volgende paragrafen uitgelegd waarom het van belang is voor het detecteren van incidenten of het verrijken van data.
Specialisatie van het medium
Als een medium gespecialiseerd is op een bepaald gebied dan zal het medium alleen relevant zijn als het specialisme te maken heeft met het incident. Een voorbeeld hiervan is www.
hulpverlening.nl, een Nederlands forum voor hulpverleners. Hulpverlening is een relevant specialisme tijdens incidenten. Voor data- enrichment wordt bij voorkeur een medium gekozen dat geheel niet gespecialiseerd is.
Daarentegen kunnen voor detectie ook media gebruikt worden die juist wel een specialisme hebben dat gerelateerd is aan incidenten.
Tijdsaspect of actualiteit
Voor detectie is het belangrijk dat de informatie op een medium actueel is. Er zit bij voorkeur weinig tijd tussen het werkelijke begin van het incident en het verschijnen van het eerste bericht over het incident op het medium. Voor data- enrichment is de actualiteit minder belangrijk omdat data-enrichment pas plaats vindt na detectie van het incident.
Kwantiteit
Voor detectie van incidenten is het belangrijk om veel data te hebben. De hoeveelheid data die geproduceerd wordt door een medium, tijdens een incident, geeft namelijk een goede indicatie van de relevantie van het medium.
Kwaliteit
De kwaliteit van een bericht is vooral van belang voor data-enrichment. Hoewel het detecteren van incidenten ook gemakkelijker kan gaan als berichten een hoge kwaliteit hebben. Dit heeft voornamelijk te maken met de keuze voor een bepaalde detectiemethode. In het volgende hoofdstuk wordt hier verder op ingegaan.
Om de kwaliteit van een bericht te verhogen, kan gebruik gemaakt worden van een micro- syntax zoals “Tweak the Tweet” (Starbird, Stamberger 2010). Een micro-syntax zoals
“Tweak the Tweet” geeft meer structuur aan een bericht door bepaalde annotaties toe te voegen. Een voorbeeld hiervan is de toevoeging van de hashtag #city als een naam van een stad genoemd wordt. Daardoor is het voor een applicatie makkelijker om de berichten te interpreteren. Het probleem met micro-syntaxis is, dat de gebruikers van bijvoorbeeld Twitter overgehaald moeten worden om de syntax te
Relevante bronnen bij incidenten | 17 gaan gebruiken. Tijdens de aardbeving in Haïti
in 2010 is een poging gedaan de micro-syntax Tweak the Tweet te introduceren. Op Twitter werd de micro-syntax niet erg breed gebruikt (Starbird, Palen 2011).
Bereikbaarheid van het medium
De bereikbaarheid van een medium is van groot belang voor de getroffenen èn voor de detectie van een incident. Als een medium tijdens een incident onbereikbaar is, betekent
dit dat de getroffen mensen via het medium geen mogelijk waardevolle informatie kunnen delen. Telecommunicatienetwerken kunnen tijdens incidenten ernstige hinder ondervinden door bijvoorbeeld overbelasting van het netwerk of uitval van stroom. Dit heeft gevolgen voor verschillende elektrische apparaten. Apparaten op accu’s bieden bij stroomuitval maar beperkt uitkomst wanneer de telecommunicatienetwerken, door diezelfde stroomuitval, niet beschikbaar zijn.
“We’ve seen broadband and social media continue to play an important role in communication for people during this storm. Social media is a critical platform for sharing information with loved ones. And it’s been vital in keeping those other communications networks open for first responders.”
- Julius Genachowski, FCC (CNET.com 2012)Bereik van het medium
Het bereik van een medium (gemeten in het aantal unieke bezoeken), bepaalt deels of het tijdens incidenten een relevante bron is. Als het aantal gebruikers van een medium hoog is, dan bestaat er een grote kans dat één van deze gebruikers zich in het rampgebied bevindt.
Voor het bereik wordt in grote lijnen gekeken naar het aantal unieke bezoekers van een medium in Nederland. Er wordt voornamelijk gebruik gemaakt van cijfers uit onderzoeken van Semiocast. Een exacte vergelijking van het aantal unieke bezoekers van verschillende sociale media is niet te geven. Dit komt doordat de bijgehouden statistieken, van het aantal unieke bezoekers van sociale media, niet dezelfde periode omvatten.
Redactie
Voor dit onderzoek is het van belang om media te gebruiken waar iedereen, zonder tussenkomst van een redacteur, zijn of haar eigen verhaal
kan plaatsen. Dit kan nadelige effecten hebben op de betrouwbaarheid van de informatie in de berichten, maar het zorgt ook voor een beter totaal beeld van wat er werkelijk in de samenleving speelt tijdens een incident.
Type informatie
Voor detectie van incidenten is het van belang om tekstuele data te verzamelen. Deze data kan namelijk door een applicatie beter geïnterpreteerd worden. Foto’s en video’s bevatten ook tekstuele data in de vorm van metadata. Maar deze metadata is vaak onvolledig of ontbreekt geheel.
Mogelijkheden van de API
Voor detectie van incidenten is het belangrijk om een bron te hebben met een goede API. De meest ideale bron voor detectie zou een API zijn die een constante stroom aan berichten kan geven.
18 | Relevante bronnen bij incidenten
3.2. Score en selectie van media voor detectie
Voor het detecteren van incidenten wordt één medium geselecteerd (uit de sociale media) die geraadpleegd kan worden voor de detectie van verschillende typen incidenten. Het medium
dat het beste voldoet aan de selectiecriteria zal gekozen worden als detectiebron. In tabel 3.2 is een overzicht te zien van de scores van de verschillende sociale media. Er wordt een score gegeven van 0 tot 2 (0, 1, 2) voor respectievelijk
“slecht”, “gemiddeld” en “goed”. De maximale score is 16.
Tabel 3.2. Score per medium voor detectie op basis van selectie criteria
Social Netw. Content Communities Blogs Nieuwssites
Medium Twitter Facebook Google+ LinkedIn Youtube Flickr Imgur Photobucket Vimeo Slideshare Scribd Wikipedia Blogger Wordpress Tumblr TypePad LiveJournal Diverse fora NOS.nl Nu.nl Telegraaf.nl Geenstijl.nl AD.nl RTL.nl VK.nl
Specialisme 2 2 2 0 2 1 2 1 0 0 0 2 2 2 2 2 2 0 2 2 2 2 2 2 2
Actualiteit 2 2 2 0 2 1 1 1 1 0 0 1 0 0 0 0 0 0 1 1 1 1 1 1 1
Kwantiteit 2 2 1 0 2 2 1 1 1 1 1 0 1 1 1 1 1 0 0 0 0 0 0 0 0
Bereik-
baarheid 2 2 2 1 1 1 0 0 1 0 0 1 0 0 0 0 0 0 1 1 1 1 0 0 0
Bereik 2 2 1 2 2 2 1 1 1 1 1 2 0 0 0 0 0 0 2 2 2 2 2 2 2
Redactie 2 2 2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 1 0 0 0 0 0 0 0
Type
informatie 2 2 2 2 0 0 0 0 0 2 0 2 2 2 2 2 2 2 2 2 2 2 2 2 2
API 2 1 1 1 1 1 1 1 1 1 1 0 1 0 0 0 0 0 1 0 0 0 0 0 0
Score 16 15 13 8 12 10 8 7 7 7 5 8 8 7 7 7 7 3 8 7 7 7 6 6 6
Twitter en Facebook zijn de duidelijke winnaars als bron voor het detecteren van incidenten.
Beide scoren het maximaal aantal punten op bijna alle criteria. Er wordt gekozen voor Twitter omdat de Twitter Streaming API het mogelijk maakt om een real-time stroom van Twitter- berichten te verzamelen.
3.3. Score en selectie van media voor data-enrichment
Tweets zijn erg korte berichten, vaak is er geen plaats voor aanvullende informatie. Er kan gebruik worden gemaakt van data-enrichment om de aanvullende informatie te verkrijgen. Dit
kan gedaan worden door de URL’s uit een tweet te volgen. Deze URL’s verwijzen naar aanvullende informatie over het incident. Daarnaast kan ook direct gezocht worden in andere bronnen om zo aanvullende informatie over het incident te verwerven. In tabel 3.3 worden de verschillende sociale media beoordeeld op basis van de eerder opgestelde criteria voor data-enrichment. Er wordt een score gegeven van 0 tot 2 (0, 1, 2) voor respectievelijk “slecht”, “gemiddeld” en
“goed”. De maximale score is 8. Uit iedere sociale media categorie worden de media gekozen die het hoogste scoren, tenzij alle media 4 of lager scoren (de helft van de maximale score).
Relevante bronnen bij incidenten | 19 Tabel 3.3. Score per medium voor data-enrichment op basis van selectie crite
Social Netw. Content Communities Blogs Nieuwssites
Medium Twitter Facebook Google+ LinkedIn Youtube Flickr Imgur Photobucket Vimeo Slideshare Scribd Wikipedia Blogger Wordpress Tumblr TypePad LiveJournal Diverse fora NOS.nl Nu.nl Telegraaf.nl Geenstijl.nl AD.nl RTL.nl VK.nl
Specialisatie 2 2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 2 0 1 1 1 1 1 1 1
Kwaliteit 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 1 2 2 2 2 2 2 2
Bereik 2 2 2 1 2 2 1 1 1 1 1 2 1 1 1 0 0 0 2 2 1 1 1 1 1
Redactie 2 2 2 2 2 2 2 2 2 2 2 0 2 2 2 2 2 1 0 0 0 0 0 0 0
Score 7 7 7 6 7 7 6 6 6 6 4 6 7 7 7 6 6 2 5 5 4 4 4 4 4
Ook wat betreft data-enrichment blijken Twitter en Facebook hoog te scoren. Zoals verwacht scoren ook de twee grootste Content Communities en de drie grootste blogs goed op de selectiecriteria.
3.4. Conclusie
Om antwoord te geven op de vraag wat relevante bronnen van informatie zijn voor incidenten in Nederland is allereerst een verdeling gemaakt in twee verschillende categorieën van bronnen.
Deze categorieën zijn: relevante bronnen voor detectie en relevante bronnen voor data- enrichment. Daarna is gekeken naar een aantal selectiecriteria die kunnen helpen om een selectie te maken van relevante en niet relevante bronnen. Uit de selectie is gebleken dat Twitter en Facebook de meest relevante bronnen
zijn voor het detecteren van incidenten. Er is gekozen voor Twitter omdat de API van Twitter het mogelijk maakt om gemakkelijk een real- time beeld te krijgen van Twitter-berichten. Voor data-enrichment zijn 11 bronnen geselecteerd, namelijk: Facebook, Twitter, Google+, Youtube, Flickr, Wikipedia, Blogger, Wordpress, Tumblr, NOS.nl en Nu.nl. De keuze van de bron voor de detectie van incidenten komt terug in het volgende hoofdstuk. De data-enrichment bronnen komen terug in hoofdstuk 5.
20 | Methoden voor detectie van incidenten
4. Methoden voor detectie van incidenten
In dit hoofdstuk wordt gekeken naar een aantal verschillende methoden voor het detecteren van incidenten. Hiermee wordt antwoord gegeven op deelvraag twee: “Welke methodes zijn er voor het automatisch detecteren van incidenten”. De detectie van incidenten is eigenlijk een analyse stap. Voor de indeling van dit onderzoek is het echter zinvol om de detectie van incidenten toe te lichten, voordat gekeken wordt naar het verzamelen van data. Beide zijn nauw met elkaar verbonden. Om data over een incident te kunnen verzamelen moet het incident namelijk eerst gedetecteerd worden, maar om een incident te detecteren moet ook eerst informatie verzameld worden. De hoeveelheid data die gebruikt wordt
voor detectie van incidenten, heeft effect op het aantal en het type incidenten dat gedetecteerd kan worden; als bijvoorbeeld weinig data gebruikt wordt, zullen vooral incidenten met grote impact gedetecteerd worden.
Zoals te zien in tabel 4.4 wordt er onderscheid gemaakt tussen vier verschillende typen incidenten (Bos 2010). Per type kunnen de methoden voor detectie verschillen. Er wordt dan vooral gekeken naar de verschillen tussen incidenten met een korte en een lange aanloopfase. Naast deze typen is er ook verschil in de impact van een incident (klein of groot incident).
Tabel 4.4. De vier verschillende incident typen
Korte nasleep Lange nasleep Detectie methode
Korte aanloop Fast-burning (flitsramp) Long-shadow Cluster Classification, P2000 Lange aanloop Cathartic Slow-burning Keywords Burst Detection, Cluster
Classification
4.1. Keywords burst detection
Keywords burst detection kijkt naar het voorkomen van woorden in berichten. Als bepaalde woorden plotseling veel voorkomen dan wordt aangenomen dat zich een gebeurtenis heeft voorgedaan die door deze woorden getypeerd wordt (Mathioudakis, Koudas 2010). Keywords burst detection kan vooral goed worden toegepast voor het detecteren van incidenten met een lange aanloop fase, of incidenten die grote impact hebben. Voor keywords burst detection is het belangrijk om continu informatie te verzamelen van sociale media. Dit kan bijvoorbeeld gedaan worden door gebruik te maken van de Twitter Streaming API.
De Twitter Streaming API biedt mogelijkheden om alleen berichten waar bepaalde woorden in voorkomen op te halen. Dit kan gebruikt worden om te zoeken op woorden die men zou kunnen verwachten in berichten die gaan over bepaalde incidenten zoals wateroverlast of branden.
Daarnaast biedt de Twitter Streaming API ook
een optie om een willekeurige steekproef van Twitter berichten op te halen. Hiermee kunnen ook incidenten gedetecteerd worden die grote impact hebben, maar waar op voorhand geen zoektermen voor bedacht konden worden. Naast Twittermonitor, de applicatie van Mathioudakis, wordt een vorm van Keywords Burst Detection ook gebruikt in het ESA-AWTM platform (Cameron, et. al. 2012).
Een andere methode is om alle personen op Twitter te zien als sensoren die gebruikt kunnen worden om bepaalde incidenten te detecteren (Sakaki, et. al. 2010). Er zouden zelfs specifieke
“aardbeving sensoren” aangewezen kunnen worden. Dit zijn mensen die berichten plaatsen als zij een aardbeving voelen. De “sensor data”
word geanalyseerd op het voorkomen van woorden zoals “aardbeving”. De benadering om personen te zien als sensoren geeft een interessante nieuwe dimensie aan de keywords burst detection.
Methoden voor detectie van incidenten | 21
4.2. Cluster classification
Een andere optie voor het detecteren van gebeurtenissen is de Cluster Classification methode waarbij ieder bericht van sociale media wordt vergeleken met eerder verzamelde berichten die geclusterd zijn op onderwerpen (Becker, et. al. 2009). Pohl, et. al. (2012) beschrijven een clustering methode voor het detecteren van zogenaamde “sub-events”, kleinere gebeurtenissen binnen een grotere gebeurtenis.
Cluster Classification kan dus succesvol gebruikt worden om zeer uiteenlopende gebeurtenissen te detecteren. Cluster Classification maakt gebruik van Machine Learning om een model te trainen dat berichten in verschillende clusters kan indelen; dit model moet vooraf voor ieder incident type getraind worden. Voor deze methode is het van belang om zoveel mogelijk sociale media data te verzamelen; elk bericht dat niet verzameld wordt, kan namelijk niet geclassificeerd worden. Omdat de piek van berichten tijdens grootschalige incidenten erg groot kan zijn, wordt in dit onderzoek de voorkeur gegeven aan een methode waarbij specifiek gezocht kan worden naar berichten die een indicatie kunnen zijn voor een incident.
4.3. P2000
Om toch incidenten te kunnen detecteren die een korte aanloop fase hebben, zoals branden, plotselinge dijkdoorbraken, of zogenaamde
“flash floods”, kan in Nederland gebruik gemaakt worden van P2000 berichten die publiek toegankelijk zijn. Twitcident is een bestaande monitoring applicatie die ook gebruik maakt van P2000 berichten voor het opbouwen van een incident-profiel op basis waarvan sociale media berichten verzameld worden (Stronkman 2010).
Voor elke veiligheidsregio kunnen de P2000 berichten gevonden worden op Twitter. Deze berichten kunnen via de Twitter Streaming API efficiënt verzameld worden. Een voorbeeld van een P2000 bericht is te zien in figuur 4.2. Ook het NL-Alert systeem is interessant om te volgen.
NL-Alert is een systeem dat tijdens rampen gebruikt kan worden om via Cell broadcasting een waarschuwing te sturen naar de mobiele telefoon van burgers. Tot nu toe is er echter nog geen officiële bron die NL-Alert berichten ook op Twitter plaatst.
Figuur 4.2. Een P2000 bericht voor veiligheidsregio Brabant Zuidoost
4.4. Conclusie
Er zijn twee verschillende methoden besproken voor het automatisch detecteren van incidenten.
Er is gekozen voor Keywords Burst Detection omdat deze methode toestaat om gebruik te maken van zoekwoorden, zodat de totale hoeveelheid berichten die verzameld moeten worden voor de detectie van incidenten kleiner
wordt. Door het kiezen van deze methode bestaat er een kans dat relatief kleine incidenten, of incidenten met een korte aanloop fase niet gedetecteerd kunnen worden. Om dit op te lossen is gekozen om naast de berichten die voldoen aan vooraf opgestelde zoekwoorden, ook P2000 berichten te verzamelen van Twitter.
22 | Verzamelen van sociale media data
5. Verzamelen van sociale media data
In dit hoofdstuk wordt gekeken hoe de informatie uit de verschillende relevante bronnen efficiënt verzameld kan worden. Daarmee wordt antwoord gegeven op deelvraag drie. Informatie verzamelen uit verschillende bronnen levert een aantal obstakels op. Dit komt doordat de APIs van de verschillende bronnen allemaal verschillend zijn. De aspecten waarop deze APIs van elkaar verschillen worden in de volgende paragrafen één voor één behandeld.
5.1. Authenticatie
Om verbinding te maken met een API moet de applicatie meestal eerst geauthenticeerd worden. Dit gebeurt doorgaans volgens een
“Oauth 1.0” of “Oauth 2.0” protocol. In tabel 5.5 is een overzicht te zien van de authenticatie
methodes per medium. Oauth is een authenticatie methode waarbij zowel de applicatie, als de gebruiker, voor wie de applicatie informatie wil opvragen, een geheime en een publieke code hebben. De publieke codes worden gebruikt om de aanvraag naar de API te versleutelen, waarna de API de aanvraag kan valideren aan de hand van de geheime codes. Hoewel Oauth 1.0 een verouderde versie is van het Oauth protocol wordt het nog veel gebruikt, onder andere door Twitter. Oauth 2.0 is niet backward compatible met Oauth 1.0 maar gebruikt wel ongeveer dezelfde stappen, waardoor het mogelijk is om een applicatie te maken die zowel Oauth 1.0 als Oauth 2.0 aanvragen kan doen bij verschillende APIs.
Tabel 5.5. Authenticatie methode per medium
Twitter Facebook Google+ YouTube Flickr Wikipedia Blogger Wordpress Tumblr NOS.nl Nu.nl
Authenticatie Oauth 1.0 Ouath
2.0 Oauth 2.0Oauth 2.0Oauth 1.0 Geen Oauth 2.0 Geen Oauth
1,0 Eenvou- dig Geen
5.2. Response-types
Als de applicatie geauthenticeerd is kan deze gegevens opvragen bij de API. Bij de meeste sociale media APIs kan bijvoorbeeld gezocht worden naar berichten. De gevonden berichten worden daarna door de API teruggestuurd in een bepaald format. Dit format wordt ook wel de
“response-type” genoemd. Deze response-types verschillen per API. Bij sommige APIs kan de gebruiker tussen verschillende response-types kiezen. Veel APIs maken tegenwoordig gebruik van het JSON format als response-type. Nieuws-
feeds, van bijvoorbeeld blogs, maken echter veel gebruik van RSS/XML. Deze formats (JSON en RSS) zijn beide gestructureerd en kunnen daarom relatief eenvoudig worden gelezen door een applicatie. Sommige bronnen hebben geen API of feed en stellen de informatie alleen via een HTML pagina beschikbaar. Het is technisch mogelijk om ook deze bronnen te indexeren, maar in dit onderzoek worden deze bronnen buiten beschouwing gelaten. Tabel 5.6 geeft een overzicht van de verschillende response-types per medium.
Tabel 5.6. Response-types per medium
Twitter Facebook Google+ YouTube Flickr Wikipedia Blogger Wordpress Tumblr NOS.nl Nu.nl
Response-type JSON JSON JSON XML XML/
JSON HTML JSON RSS/XML JSON JSON/
XML RSS/XML
Verzamelen van sociale media data | 23
5.3. Metadata
Naast de response-types zit er ook verschil in de metadata die gekoppeld is aan de berichten van verschillende bronnen. Deze metadata bestaat uit verschillende velden, bijvoorbeeld een datum en een geo-locatie. De namen van deze velden verschillen sterk per API. Bovendien zijn er vaak verschillen tussen de notatie van datum en tijd. Hier kan op twee manieren mee worden omgegaan. Eén manier is om de metadata per bron te normaliseren. Bijvoorbeeld door bepaalde metadata-velden niet op te slaan, of door zelf velden toe te voegen of aan te passen. De andere mogelijkheid is om de metadata per bron intact te laten en te accepteren dat er verschillen zijn tussen berichten uit verschillende bronnen;
hiermee moet bij de opslag en de weergave van de data rekening gehouden worden. Meer hierover is te lezen in het hoofdstuk over de opslag.
5.4. Rate-limiting
Twitter, Facebook en veel andere sociale media APIs stellen limieten aan de hoeveelheid aanvragen die gemaakt kunnen worden binnen
een bepaalde tijd. Dit wordt ook wel “rate- limiting” genoemd. Rate-limiting kan een grote beperking zijn. Er zijn meestal rate-limits voor het aantal aanvragen dat gedaan kan worden in een bepaalde tijdsperiode en rate-limits voor het aantal berichten per aanvraag. Tijdens incidenten kan de hoeveelheid berichten zo sterk toenemen dat de rate-limits van de APIs het onmogelijk maken om alle berichten over een incident te verzamelen. Twitter heeft een streaming API die constant nieuwe berichten naar de applicatie stuurt. Voor deze API geldt geen beperking in het aantal aanvragen dat gedaan kan worden omdat deze API een constante stroom van berichten naar de applicatie stuurt. De hoeveelheid van de gestuurde berichten verschilt continu maar kan nooit groter zijn dan 10% van het totaal aantal tweets dat op dat moment geplaatst wordt op Twitter door gebruikers over de hele wereld.
Tabel 5.7 geeft een overzicht van limieten van de belangrijkste APIs waarmee Tweets gezocht kunnen worden.
Tabel 5.7. Limieten van de verschillende APIs waarmee Tweets gezocht kunnen worden
Bron Aanvragen/uur Berichten/
aanvraag Berichten/minuut Berichten/uur
Twitter REST API 720 100 1200 72000
Twitter Streaming API nvt nvt max 10% van totaal
op Twitter max 10% van totaal op Twitter
Topsy Otter API ~290 100 ~480 ~29000
APIs van andere sociale media zijn minder duidelijk over de limieten die zij stellen. Tabel 5.8 geeft een overzicht van de gevonden rate-limits per medium.
Tabel 5.8. Rate-limits per medium
Twitter Facebook Google+ YouTube Flickr Wikipedia Blogger Wordpress Tumblr NOS.nl Nu.nl
Rate-limits 1200
zoek res.
/ minuut onbe-
kend onbe- kend onbe-
kend 240000 zoek res.
/ minuut
nvt onbe-
kend nvt onbe-
kend ~170 zoek res.
/ minuut nvt
24 | Verzamelen van sociale media data
5.5. Conclusie
Er is gezocht naar een antwoord op de vraag hoe de data van verschillende sociale media efficiënt verzameld kan worden. Daarbij is gekeken naar vier verschillende obstakels bij het verzamelen van data uit verschillende bronnen. Er is geconstateerd dat het verschil in de manieren van authenticatie en het verschil in de response- types van de APIs gering zijn en gemakkelijk programmatisch opgelost kunnen worden.
Ook voor de afwijkingen in de metadata bij de berichten uit de verschillende bronnen zijn verschillende oplossingen. De grootste afwijking zit echter in de rate-limiting. Alleen Twitter is duidelijk over het aantal berichten dat via de API verzameld kan worden per minuut. Voor dit onderzoek is dit geen probleem omdat Twitter als detectiebron gekozen is juist omdat het bij de Twitter API mogelijk is om een groot aantal berichten per minuut te verzamelen.
Opslag van sociale media data | 25
6. Opslag van sociale media data
Voor de opslag van grote hoeveelheden sociale media data is het belangrijk om een goede opslag strategie te hebben. Hierbij moeten een aantal keuzes gemaakt worden. Dit hoofdstuk behandelt deze keuzes en een aantal technieken die van belang zijn bij de opslag van de data en geeft daarmee antwoord op deelvraag vier.
6.1. Keuze van database
Voor de te ontwikkelen applicatie is een database nodig waarin gemakkelijk enkele miljoenen tweets per dag opgeslagen kunnen worden. Dit is onder andere gebaseerd op de limieten van de Twitter API. Twee tot drie miljoen tweets per dag komt neer op ongeveer 16Gb aan data als wordt uitgegaan van ongeveer 8Kb per tweet1. Verder is het belangrijk dat de database ook bij een plotselinge explosieve toename van het aantal schrijfquery’s stabiel blijft werken.
Er is gekozen om te onderzoeken wat de mogelijkheden hierin zijn van de relatief nieuwe NoSQL-databases. Hoewel het ook mogelijk is om het opslag probleem op te lossen met een traditionele relationele database, bieden NoSQL- databases vaak goedkopere oplossingen voor het werken met grote hoeveelheden data. NoSQL- 1 Dit is gebaseerd op de document grootte van
tekstbestanden met tweets in Windows 7.
databases zijn meestal opensource (en dus gratis) en zijn niet afhankelijk van dure infrastructuur om hoge prestaties te behalen. Dit komt omdat veel NoSQL-databases “horizontaly scalable”
zijn. Dit wil zeggen dat, om de prestaties van de database te verhogen, gemakkelijk nieuwe (goedkope) servers geplaatst kunnen worden.
NoSQL-databases worden onder andere gebruikt door Google en Facebook voor de opslag van grote hoeveelheden data (Perdue 2012)
Onder NoSQL-databases zijn verschillende categorieën2. Twitter gebruikt de NoSQL- database “Cassandra” (King 2010), dit is een zogenaamde “wide-column-store”. In een wide- column-store bestaat elke record uit een rij die verwijst naar een soort boomstructuur.
Een andere categorie NoSQL-databases zijn de zogenaamde “document-stores”. In document- stores bestaat iedere record uit een sleutel die verwijst naar een document. Figuur 6.3 laat een voorbeeld zien van een record in een document- store en in een wide-column-store. Document- stores zijn ideaal voor het opslaan van data uit verschillende bronnen waarbij documenten vaak sterk van elkaar verschillen (een tweet is niet hetzelfde als een Facebook update).
2 Een overzicht kan gevonden worden op http://
nosql-database.org/
Figuur 6.3. voorbeeld record in document-store en wide-column-store Er zijn verschillende document-stores
beschikbaar, waaronder CouchDB en MongoDB.
Het verschil in deze databases wordt duidelijk aan de hand van de zogenaamde CAP theorie (Gilbert, Lynch 2002). CAP staat voor Consistency, Availability en Partition-tolerance.
Volgens de theorie moet een database (of ander software pakket) altijd kiezen voor twee van
deze drie begrippen. De focus van CouchDB ligt op Availability en Partition-tolerance. MongoDB kiest voor Consistency” en Availability. In figuur 6.4 wordt de positie van CouchDB en MongoDB weergegeven in deze theorie. Het komt er op neer dat, in tegenstelling tot MongoDB, CouchDB databases die verspreid zijn over verschillende servers altijd blijven werken, zolang een van de
26 | Opslag van sociale media data
servers online is. MongoDB database servers zijn afhankelijk van één master-server voor alle schrijf query’s (Anderson 2010). CouchDB heeft dus een groot voordeel omdat de infrastructuur soms onzeker kan zijn tijdens grootschalige rampen. Hierdoor kunnen servers offline gaan.
Als de master-server van MongoDB offline is kan geen sociale media data meer verzameld worden, zolang een van de CouchDB servers online is kan de data wel verzameld worden. Ook als door de plotselinge toename van het aantal schrijf- query’s tijdens een incident een van de CouchDB servers crasht, kan de verloren capaciteit gemakkelijk, en zonder onderbrekingen, door een andere server worden overgenomen.
CouchDB biedt ook een goed gedocumenteerde REST API waardoor deze database gemakkelijk geïmplementeerd kan worden.
Figuur 6.4. CAP theorie en de positie van CouchDB en MongoDB
CouchDB biedt alle voordelen van een NoSQL- database, waar onder MapReduce. CouchDB wordt onder andere gebruikt voor opslag van de data die gegenereerd wordt door de CMS module van de Large Hadron Collider. Dit gaat om ongeveer 10PB aan data per jaar (1PB is ongeveer 1 miljoen GB) (Finley 2010). Daarmee voldoet CouchDB dus ruimschoots aan de eis van maximaal 16Gb per dag. Bovendien kan, wanneer hogere eisen gesteld worden, de performance
van CouchDB gemakkelijk verhoogd worden door horizontal-scalability toe te passen, er kan simpelweg een extra server geplaatst worden.
6.2. Representatie van documenten in de database
Nu een database gekozen is, moet een keuze gemaakt worden hoe de sociale media data het beste in deze database opgeslagen kan worden. In CouchDB wordt data opgeslagen in documenten. Dit is een groot verschil met traditionele relationele databases waarin data als rijen in tabellen wordt opgeslagen. De tabellen definiëren een vaste structuur (kolommen) voor iedere rij. In CouchDB is dit niet het geval en kan ieder document verschillen. Bovendien kent CouchDB geen tabellen. Dit is een voordeel omdat daardoor gemakkelijk de verschillende metadata van bijvoorbeeld Twitter of Facebook updates kan worden opgeslagen. Om dergelijke data op te slaan in een tabel in een relationele database zou de data eerst “genormaliseerd” moeten worden, wat vooral nadelig wordt wanneer een nieuwe bron wordt toegevoegd aan de applicatie.
Het normalisatie-algoritme moet dan worden aangepast. Door CouchDB te gebruiken kunnen zonder problemen nieuwe bronnen en nieuwe typen documenten toegevoegd worden.
Voor de te ontwikkelen applicatie worden de volgende document-typen erkend: Updates (bijvoorbeeld Tweets of Facebook updates), Profiles (bijvoorbeeld Twitter of Facebook profielen) en Events (de gebeurtenis waar een update aan gekoppeld is). Omdat zogenaamde irrelevante updates verwijderd moeten worden, is het logisch om de profielen als een sub- document op te slaan in het Update document, zoals weergegeven in figuur 6.5. Wanneer de profielen als aparte documenten opgeslagen zouden worden dan is het lastig om uit te zoeken welke profielen, die bij een irrelevante update horen, verwijderd kunnen worden, omdat een dergelijk profiel misschien ook gekoppeld is aan een update die wel relevant is.
