Projektidé: Bot för att hitta otillbörliga efterhandsredigeringar

Efter att ha funderat ett varv till på det där med DN:s osynliga artikelkorrigering (som numera blivit synligare) föddes tanken på en bot som kan hitta liknande beteende. Som med alla bra ideer är man sällan först, David hade föreslagit det redan i samband med jordbävningen i Skåne.

Om jag hade varit med på 24 hour business camp hade jag nog försökt implementera en sån tjänst — det skulle kunna gå på ett dygn om man har rätt flyt.

Det som behövs är:

  • en bra lista av URL:er till enskilda artiklar – här kan tidningarnas egna RSS-flöden förmodligen hjälpa till
  • En schedulerare som kollar enskilda URL:er med olika tidsintervall (under första publiceringsdygnet kanske var 5:e minut, för att sen sakta ner till kanske en gång i veckan för årsgamla artiklar)
  • Ett stabilt sätt att för varje mediasajt identifiera själva artikelinnehållet (kanske regexpar eller xpath-uttryck)
  • Jämförande av olika revisioner med wdiff eller liknande, publicering av artikel med diff.
  • (Nice-to-have): En komponent som genererar skärmdumpar, så man kan se exakt hur artikeln såg ut med layout och allt. Kan man använda gecko eller webkit för att rendrera en URL till en png på kommandoraden?

Upphovsrättsligt är tjänsten tveksam (om man ska kunna visa att en tidning ändrat en artikel måste man spara och visa de båda revisionerna av artikeln), men om man bara gör det för artiklar där ”otillbörlig efterhandsredigering” förekommit kanske man kan klara sig från stämningsansökningar iaf.

Förmodligen skulle man kunna börja med DN/SvD först och lägga till tidning för tidning allt eftersom. Man kanske tillochmed kan sätta upp ett github-repo, det är vad de coola kidsen gör nuförtiden har jag hört.

7 svar på “Projektidé: Bot för att hitta otillbörliga efterhandsredigeringar”

  1. Det där behöver man inget 24h business camp för!

    Man kan ju spegla artikeln i en wiki (som har inbyggt stöd för diffar) och lägga till revisioner eftersom. Skärmdumparna görs enklast med webkit2png (för oss som är på den ljusa sidan i OS-val).

    Någon skulle förmodligen kunna göra det hela i bash:-)

  2. Peter: Hmm, intressant idé. Det verkar som Mediawiki inte heller skapar en ny revision om man POSTar en sida som är identisk med den befintliga, så då slipper man hålla reda på om saker ändrats själv. Om man bara konfigurera MW till att bara visa sidor med 2 revisioner eller fler är man nästan hemma. På webservern kör jag dock Linux, så jag får jaga vidare efter skärmdumpverktyg.

  3. Punkt 1 och 3 i din lista är svårast, tror jag.

    När det gäller punkt 1 så finns t.ex. inte DNs artikel om den kvinnliga utrikesminstern med i någon av DNs RSS-feeds (bör ha funnits i någon av deras Ledare/Debatt-feeds, men icke). Det gör att det blir resurskrävande att få 100%-ig täckning, även för en enskild nyhetssajt.

    Att hitta ett 100%-igt sätt att extrahera artikeltext från nyhetsartiklar (bortse från bl.a. menyer och ”puffar”) är inte gjort i en handvändning, inte ens om man begränsar sig till en enskild nyhetssajt. Google har jobbat med metoder för detta för sitt nyhetssök (som funkar okej) och nu även för sitt bloggsök, där det fortfarande inte funkar tillräckligt bra, tydligen: http://groups.google.com/group/google-blog-search/browse_thread/thread/8244fc8731f47970?pli=1

  4. Clas: Nu har jag börjat med en prototyp och visst har du rätt i att det är svårt att extrahera bara själva artikeln från sidan – mina naiva första försök får både med för mycket skräp och missar delar av artiklar. Där hoppas jag dock att man kan få en good enough-lösning med lite trial and error.

    Att man inte kan lita på att få allt om man följer RSS-flödena är värre. Att indexera en hel tidningswebbplats vill man gärna slippa. Kanske kan man kombinera informationen från RSS-flödena med data från exv knuff.se?

    Det verkar dessutom som just dn.se har någon sorts throttling till skydd mot överentusiastiska robotar (som min) – då och då tar det tid och evighet att få ner en enstaka sida. Ska man få en bra genomströmning (vilket krävs om man vill kolla 100+ artiklar per site, och 10+ siter, var femte minut) måste man nog göra en smartare, flertrådad, eventuellt distrubierad sidhämtare.

  5. Jo, jag har försökt med liknande tekniker för min nyhetssöksajt. Men jag kan där nöja mig med att hämta artikeltexten en gång. Dessutom, precis som Google skriver i sitt inlägg, måste det inte vara absolut 100%-igt för att det ska fungera okej för ett sökindex.

    Att ”komplettera” sina URL-listor med nyheter som länkar i bloggar går bra (jag gör detta för nyheter som länkas ofta från de bloggar som jag indexerar), men jag tror inte att man har mycket hjälp av de i detta sammanhang. Bloggar hämtar inte upp nyheter ”supersanbbt”, utan det är ofta en fördröjning på en halvtimme eller så, innan det är någon som skriver något om en publicerad nyhet.

    Men jag kan se att t.ex. denna artikel http://www.sr.se/cgi-bin/stockholm/nyheter/artikel.asp?Artikel=2588579 i en tidigare version hade ordet ”politikerna” felstavat något de ändrat i efterhand. Google har också hittat den ”gamla” versionen: http://www.google.se/search?q=piolitikerna

Kommentarer kan inte lämnas på detta inlägg.