Det eksperimentelle designet er nyvinnende: Vi spurte først tre ulike, mindre grupper respondenter om deres holdninger henholdsvis til å ta i mot syriske flyktninger, til obligatorisk meslingvaksine for barn, og til akademisk boikott av Israel. Deres svar ble lagret og gjengitt til en ny gruppe respondenter i medborgerpanelet. Samtidig som de nye respondentene så et kakediagram med oversikt over hvor mange av de tidligere respondentene som var enig eller uenig, fikk de de samme spørsmålene selv. Når denne gruppen hadde gitt sine svar, fikk nok en ny gruppe respondenter se deres svar igjen, samtidig som de skulle svare på de samme spørsmålene selv. Slik fortsatte stadig nye grupper å få oppdatert informasjon om den forrige gruppen. For hver gruppe som så en meningsmåling var det en kontrollgruppe som bare fikk spørsmålene, uten å se hva andre før dem hadde svart.

Foto: Mikael P. Johannessoncb

Illustrasjon av den eksperimentelle prosedyren “Dynamic Response Feedback” og implementeringen i eksperimentet om syriske flyktninger og obligatorisk meslingvaksinering av barn.

Figur 1 viser det eksperimentelle designet gjennomført på spørsmålet om syriske flyktninger (a), og obligatorisk meslingvaksine (b). De første respondentene så en meningsmåling som viste at 40 prosent var enig i at Norge skulle ta i mot flere syriske flyktninger. Blant de som så denne fordelingen, var det 52 prosent som var enig i denne påstanden. Tilsvarende for kontrollgruppen som ikke så en måling var 59 prosent. I den neste gruppen – som så en meningsmåling som viste av 52 prosent var enig – var det 61 prosent som var enig i påstanden (mot 66 prosent i kontrollgruppen). Deretter var det liten bevegelse i fordelingene. For vaksinespørsmålet var hele ni av ti respondenter enig i at staten bør innføre obligatorisk vaksinering, og denne fordelingen var stabil over tid.

Resultatene fra eksperimentene viser enkelte tegn til en såkalt medvindseffekt (bandwagon effect) om meslingvaksine. Det var et sterkt flertall for obligatorisk barnevaksinering mot meslinger, og mye sterkere enn hva de fleste respondentene trodde. Enkelte av de som endret oppfatning om hvor sterkt flertallet var ble også selv sterkere tilhengere av en slik vaksine. Denne medvindseffekten var imidlertid svak, og kun påviselig for dette ene spørsmålet. Det generelle funnet fra studien er at meningsmålinger ikke er i stand til å påvirke opinionen i seg selv. Forskjellene i svarene mellom de som så en meningsmåling og de som ikke så en slik måling var ubetydelige.

Resultatene viser at opinionen er robust og ikke så lett lar seg påvirke som en kanskje skulle frykte. Resultatene er til en viss grad også relevante for politiske valgkamper: De antyder at når partier går oppover eller nedover på meningsmålingene, så er det av substansielle grunner, og ikke fordi velgerne ønsker å være på vinnerlaget. Enkelte velgere stemmer taktisk, og er villige til å «låne bort» sin stemme til et parti som vaker rundt sperregrensen. Men dette er en annen type påvirkning, hvor velgernes grunnleggende preferanser står fast, og måten de lar den komme til uttrykk påvirkes av den taktiske situasjonen i øyeblikket. Det er generelt liten grunn til å frykte at meningsmålinger påvirker folks politiske holdninger.

Artikkelen som presenterer eksperimentene blir publisert i Social Science Computer Review, fritt og gratis tilgjengelig for alle. Forfatterne er Sveinung Arnesen, Mikael Poul Johannesson, Jonas Linde og Stefan Dahlberg, alle fra Institutt for sammenliknende politikk, Universitetet i Bergen. En tidligere versjon av dette blogginnlegget har vært på trykk som kronikk i Bergens Tidende, og postet på den norske statstviterbloggen Saktuelt

Reinhart og Rogoff la i 2010 fram en studie av forholdet mellom statsgjeld og økonomisk vekst, “Growth in a Time of Debt”. De fant en sammenheng: Når et lands gjeld overskrider 90 prosent av BNP, stopper økonomien å vokse. Resultatet fikk mye mer oppmerksomhet enn vanlig er for forskningsarbeider. Politikerne som forsøkte å få grep på statsgjeldskrisen i Europa hadde endelig et autoritativt tall å klamre seg til. 90 prosent — en vanntett faglig begrunnelse for sparepolitikken, fra to av verdens fremste økonomer!

Sommeren og høsten 2012 strever Thomas Herndon med Reinhart og Rogoffs analyse. Han har lastet ned dataene, et regneark forfatterne fortjenstfullt nok har gjort tilgjengelig. Herndon vil skrive om artikkelen i en seminaroppgave, men klarer ikke å reprodusere 90 prosent-terskelen. I februar i år skriver han en e‑post til Reinhart og Rogoff og ber om å få se utregningene deres også. Han får materialet, og oppdager kjapt flere enkle feil. Han regner og regner. 90 prosent-terskelen forsvinner. Resten er, som det heter, historie.

Sherlock-skulptur i Meiringen, Sveits (foto: David Jones, CC:by)

Hva dette har med Sherlock Holmes å gjøre? Flere steder i Conan Doyles historier advarer mesterdetektiven mot å trekke slutninger før alle data er vurdert. I “A Study in Scarlet”, for eksempel. Dr. Watson, jeg-fortelleren, er misfornøyd med framdriften i etterforskningen. Holmes prater i vei om fioliner:

“You don’t seem to give much thought to the matter in hand,” I said at last, interrupting Holmes’ musical disquisition.
“No data yet,” he answered. “It is a capital mistake to theorize before you have all the evidence. It biases the judgment.”

Sannheten om Reinhart og Rogoffs regnefeil kom for en dag først da alle dataene var på plass i Herndons datamaskin. I mellomtiden hadde det foregått mye “teoretisering uten alt bevismateriale”. Det er all grunn til å tro at det er mange andre forskningsresultater som burde lidt samme skjebne som 90 prosent-tesen. Reinhart og Rogoff hadde jo til og med gjort data tilgjengelig, om enn ikke komplett. Hva så med data som man ikke en gang får tak i fordi de ligger på forskerens PC eller i en skuff?

Forskermiljøer strever ennå med data-åpning. Løsningen er snublende nær — publisering av data må gjøres til en betingelse for finansiering av et forskningsprosjekt. I tillegg trengs det fornuftige regler for håndtering og en god infrastruktur for oppbevaring av dataene. Tenk også på samfunnet utenfor forskerverdenen: Tilgang til data bak forskningen bør ikke være forbeholdt forskere (med de nødvendige forbehold for å sikre personvernet dersom dataene inneholder personopplysninger).

En oppmuntring til slutt: Den som offentliggjør data, får også større gjennomslag i forskersamfunnet, det vil si flere siteringer. Det viser en studie (på fagfeltet genetikk) som sammenligner forskningsartikler der data er gjort tilgjengelig med tilsvarende artikler uten åpent datamateriale.

“Bruksanvisningen” er basert på en glimrende guide fra ProPublica, ispedd egne erfaringer med alternative verktøy til de ProPublica har benyttet.

Webskraping: eksempel og verktøy

Webskraping er å lese en webside via en programvare for så å hente ut visse deler av (html-)koden websiden består av, for deretter å lagre disse delene etter eget ønske. Typisk skriver man et lite script som gjør denne jobben.

Eksempel: du jobber med økonomi/politikk i en redaksjon og ønsker å vite 1) hvor ofte din kommune er klaget inn for KOFA (Klagenemnda for offentlige anskaffelser) de seneste årene, 2) hvem som klager oftest/oftest blir innklaget i ditt område, og 3) hvor ofte kommunen får medhold i sakene de blir innklaget for. Videre ville det være greit å lage seg en liten tjeneste som automatisk informerer deg hvis det dukker opp nye saker som involverer din kommune/et spesielt firma i KOFA.

All denne informasjonen finnes på kofa.no, men ikke på en slik måte at denne enkelt kan leses av. Se på en vilkårlig detaljside fra kofa.no. Informasjonen her er allerede ganske godt strukturert, ved å samle dette inn i en database (eller Excel, hvis du foretrekker det) kan alle tre punktene over raskt besvares.

Propublica.org gir deg en fyldig guide for hvordan gjøre just dette i ruby med nokogiri. Du kan strengt tatt bruke et hvilket som helst språk, selv har jeg gode erfaringer med python og BeautifulSoup, og anbefaler det som et greit sted å starte.

Poenget er helt enkelt å lese inn en webside, selektere elementer som skal spares (det er dette nokogiri og BeautifulSoup benyttes til), for så å lagre disse utvalgte elementene på en måte du selv foretrekker. Det finnes masse guider på webben om detaljene i hvordan dette gjøres for utallige språk, her er et eksempelsøk.

Når du så har satt sammen et script som henter ut det du vil ha, kan det være greit å automatisere kjøringen av scriptet. Denne typen informasjon er det kanskje praktisk å få på starten av arbeidsdagen eller starten av uken. Å sette et script til å automatisk kjøre på visse tider kan f.eks. gjøres ved å sette opp en crontab (automatisert oppgave). På den måten kan du også sende e‑post automatisk til deg selv, det som du velger å skrive ut (print/put/echo/…) i scriptet blir innholdet i mailen. Sørg for å gi deg selv nyttig og meningsfull informasjon i disse mailene, før eller siden glemmer du detaljene i hvordan informasjonen hentes inn.

Vis hensyn

Hent bare ut den informasjonen du trenger, og hent data så sjeldent som mulig. Les denne for flere detaljer. Sørg f.eks. for at kallet mot webserveren du skraper ikke kjøres i en loop, men kun en gang i starten av scriptet. Å legge inn litt ventetid på strategiske steder i scriptet (funksjonen sleep i mange språk) er også en god idé. Du trenger sjeldent hurtighet i slike script, så å skåne webservere og databaseservere for en bombardering av kall har du lite å tape og mye å vinne på. Du vil ikke hisse på deg driftspersonalet/sikkerhetspersonalet til organisasjonen du jobber mot.

Fix broken windows

Fix broken windows er en teori om å motarbeide forfall i programvareutvikling. Det samme prinsippet gjelder i webskraping som et middel mot “dataråte” (eller kanskje bare “råtne data”, dataråte er et ord som også brukes på datasystemer som forfaller ved at gamle filformater ikke lenger er støttet i nyere versjoner). Så fort det er feil i dataene du samler inn begynner verdien av dem å synke, jo lenger du kan samle inn uten feil jo mer blir dataene verdt. Råtne data er smittsomt. Fiks eventuelle problemer så snart du oppdager dem.

Pdf, ocr, flash og annet gruff

Å lese .pdf på omtrent samme måte som html virker i teorien, det er bare veldig mye vanskeligere å få til på en effektiv og gjenbrukbar måte i praksis. Jeg har ikke selv fått dette til på en måte jeg mener er god nok for automatiserte jobber. Da Senter for statlig økonomistyring (Sfso) startet å publisere månedlig statsregnskap i desember i fjor, gjorde jeg et forsøk på .pdfene de publiserer. Dette er et muligens gjennomførbart prosjekt, men krever mye mer arbeid enn det er verdt uten en god plan videre. Jeg gav opp.

Hvis ditt prosjekt krever skraping av .pdfer kan guiden til ProPublica (ruby) eller Scraperwiki (python) være til nytte.

OCR er en forkortelse for optical character recognition, optisk tegngjenkjenning på norsk. Målet med denne teknikken er å tolke bilder av tekst om til tekst (noen luringer lagrer innhold i pdf eller html som pixel-baserte bilder). I teorien virker dette også, og det finnes bråtevis med digitaliseringsprosjekter som baserer seg på denne metoden. I praksis er dette også ofte en skuffelse, så ha moderate forhåpninger til effektivitet og presisjon her. Googles tesseract-ocr er et ofte sitert verktøy i denne sammenheng. For detaljer om framgangsmåte, se ProPublica eller Google code.

Et siste triks er skraping av flashsider. ProPublica viser deg hvordan du kan finne fram til dataene som en flashside benytter. Ved å bruke firebug kan du snappe opp slikt, og så hoppe over hele flash-biten. Flash lar seg ikke skrape slik html gjør, da flash på web vises som et html-element som innkapsler en flash-fil (.swf).

La analysen begynne!

Når du nå har samlet inn data med scriptet ditt, og lagret dataene slik du liker å ha dem, kan du begynne å analysere. I mange tilfeller vil den jobben du har gjort så langt være grunnlaget for en story, kanskje du kan ringe en ekspert eller konfrontere en part med funnene dine i et intervju? Uansett kan det være lurt å dobbeltsjekke dataene for feil eller mangler. En datavask i Google refine kan i mange tilfeller slå sammen disse to oppgavene, sjekk ut artikkelen om datavasking her på Vox Publica. ProPublica har også en artikkel om Google refine.

Veien videre

Webskraping er litt vanskelig første gang. Din andre skraper tar kun en brøkdel av tiden å skrive, og blir bedre enn den første. En skraper har typisk kun få kodelinjer, er lett å lese og forstå og kan enkelt modifiseres. Det er sannsynlig at webskraping blir en viktigere metode framover, da stadig mer data publiseres på nett. Webskraping er ikke den beste løsningen for noen av oss, det vi egentlig vil ha er et API, men å få data ut på web er et skritt i riktig retning.

Å scrape en webside rutinemessig og så selv legge dataene et sted hvor de kan nås via et API, er en god idé. Scraperwiki.org er en operasjonalisering av denne ideen, med et tillegg om at vi kollektivt kan gjenbruke hverandres datainnsamling. Å bruke Scraperwiki til å ta hånd om datalagring, automatisering og arkitektur for APIet kan være en løsning for team som jobber sammen i en redaksjon. Redaksjoner som er i direkte konkurranse med andre (riksmedier) vil nok foretrekke bedriftsinterne løsninger.

Når en webside endrer struktur går ofte skrapere “i stykker”, de finner ikke det de er på jakt etter lenger fordi dataene ikke er der i hierarkiet hvor de pleide å være. Dette er et av argumentene mot å bruke skraping som del av en arbeidsflyt. Det finnes et potensielt vedlikeholdsarbeid du selv ikke kan påvirke hyppigheten av. Min erfaring er at dette ikke er et stort problem da websider, kanskje særlig statlige/kommunale, sjeldent endres på andre måter enn at mer innhold fylles på. Jeg har flere skrapere som har kjørt siden jeg begynte med dette for et drøyt år siden, og ingen skrapere som har stoppet eller krasjet.

Webskraping er ikke den beste løsningen, men den virker.