Jessica Parland-von Essen

Det finns många olika sätt att strukturera information. Renodlade traditionella relationsdatabaser är ett. I dem ordnas informationen i tabeller, där varje värde får ett eget id, som man sedan hänvisar till i andra tabeller. Gemensamt för dem är att man försöker ordna informationen på ett sådant sätt att den kan hanteras rationellt och effektivt, så att samma uppgift inte upprepas flera gånger utan att man bara kan hänvisa till rätt ställe vid behov. På det sättet förhindrar man till exempel att man måste göra mångdubbelt arbete. Man kommer alltså i ett tidigt skede in på frågor om begrepp och klassificering , som mycket snabbt får konsekvenser för både forskningsprocessen och resultaten. Det är därför viktigt att man undviker tunneltänkande och använder sig av olika ”etiketter” för saker utan att reflektera och analysera varje begrepp. En viktig princip är att hellre sönderdela informationen i för många typer än för få. Det är nämligen alltid enklare att slå ihop information än att i efterhand börja dela och sortera i klasser. Sådant kräver ofta mycket manuellt arbete.

Exempel på hur en enkel relationsdatabas kan se ut. Källa: Webdesignskolan, ”MySQL och databaser”, http://ramp.hostingsiteforfree.com/Webdesignskolan/mysql/mysql.htm (2013-09-26).

Om en person till exempel byter namn, kan man då göra ändringen bara på ett ställe, så att det nya namnet sedan syns både i det som ser ut som ”Telefonbok” och ”Adressbok”. Information kan alltså sammanställas till olika typer av ”fönster”, som plockas ihop av uppgifter från vitt skilda ställen i datasystemet, men visas i en specifik ”vy”. Ett system med till exempel en sökvy och en resultatvy och visning av enskilda ”poster” kan tillsammans utgöra vad man kallar användargränssnitt. Det är ett ställe där ett datasystem möter en människa. Ett vanligt och konkret exempel är en bibliotekskatalog på webben (ofta kallade OPAC, Online Public Access Catalogue), men i praktiken är ju allt man ser på sin skärm strängt taget användargränssnitt. Gränssnitt finns också ofta mellan olika datasystem, där information kan röra sig mellan de olika systemen.

Användargränssnitt kallas det verktyg som ger användaren tillgång till databasens innehåll. Innehållet i databasen kan presenteras i olika “vyer” där information presenteras enligt på förhand programmerade anvisningar och de sökfrågor användaren via verktyget skickar till databasen. Skärmdump från Databasen Henrik, http://dbgw.finlit.fi/henrik/henrik_svenska.php (2013-09-26).

Många moderna användargränsnitt använder sig ofta av webbkod för att formulera grafiken, men också andra möjligheter finns. För att informationen skall löpa från gränssnittet till det underliggande datasystemet behövs kommandon, sökfrågor eller olika andra skript som berättar för datasystemet vad det ska göra. Ett vanligt språk är SQL, Structured query language, som används i relationsdatabaser. Då man kommunicerar via ett gränssnitt i en webbläsare måste man förpacka SQL-koden i en annan kod; är det andra typer av gränssnitt eller databaser behövs andra språk. Då man använder databaser och datasystem vid forskning är det mycket relevant hur dessa kommandon ser ut. Om man endast sparar rådata räcker det inte för att belägga forskningsresultaten, eftersom exempelvis sökfrågorna (”ta alla enheter som innehåller värdet x och y där värdet för y är mindre än 1790 och räkna dem och visa summan”) de facto är en del av forskningsmetoden, om man går ut med siffran man fått som ett forskningsresultat. Om det i denna kod finns felaktigheter eller brister i logiken kan svaren vara helt felaktiga. Eller snarare är frågorna felaktiga och forskaren får svar på andra frågor än han tror sig få besvarade. Det betyder att de informationssystem man använt måste dokumenteras noga antingen de bevaras som helhet eller inte.

För att sökningar skall fungera måste man ofta använda sig av normalisering eller tolkning av källorna. Normalisering betyder att man till exempel ändrar i stavningen, så att ord eller namn alltid stavas på samma sätt. Sådant kan ibland vara försvarbart, men man måste komma ihåg att man samtidigt korrumperar informationen i källan. Alltså måste man vara mycket tydlig med att man gjort detta. Det kan vara bra att göra sådant ändå ibland. Tidsuppgifter är en sådan typ av information, att det kan vara försvarbart att av ekonomiska skäl helt kallt normalisera datumangivelser. Då gör man en tolkning redan vid skapandet av den digitala resursen som inte kan kontrolleras annat än mot originalet.

Ett bättre men mer resurskrävande sätt är att ange både den ordalydelse och formulering som finns i originalet och den tolkning som behövs för att uppnå god sökbarhet och funktionalitet. Detta kan lösas genom att ge varje värde ett eget id-nummer som man sedan hänvisar till i samband med uppgiften. Problemet är att det ofta finns en hel del osäkerhet vid identifieringen. Till exempel i Helsingfors fanns under slutet av 1700-talet två handelsman Lampa, varför det ofta är helt omöjligt att koppla ihop ett viss omnämnande av ”handelsman Lampa” i en källa till en viss person. Ofta kan det vara Clas Lampa lika väl som Carl Lampa. Att hantera denna typ av osäkerhet är svårt i digitala sammanhang. Egentligen bör man hålla de ”verkliga fysiska personerna” skilda från förekomsten av ett namn i en källa, och båda borde ha egna id:n. Dessutom har man ofta ett stort antal namnvarianter att hantera.

Om man lyckas länka sina egna resurser till någon annan resurs på webben, till exempel en ontologi är det särskilt bra, eller om man själv lyckas strukturera sin information på ett sådant sätt. Länkning sker genom att man anger ett id eller helst en bestående webbadress till en särkilt uppgift i en annan resurs. En ontologi är en resurs där man organiserat begrepp så att relationerna mellan begreppen finns sparade på ett sådant sätt att en maskin kan använda strukturen till exempel vid sökningar. Ett enkelt exempel är geografiska namn. Ta stadsdelen Hagnäs i Helsingfors, säg att den förekommer i relation till en viss uppgift i ditt material. Säg att du sedan har liknande geografisk information om tusentals andra enskilda uppgifter. Du vill kanske i framtiden jämföra uppgifter från Helsingfors och Ekenäs. Nå väl, för att kunna göra det borde du förutom ”Hagnäs” i informationen också uppge ”Helsingfors” så att uppgiften kan hittas för en jämförelse. Men du vill kanske också jämföra alla uppgifter från Österbotten med alla uppgifter från Nyland. Alltså måste du också ange ”Nyland”. Det betyder att man är tvungen att upprepa samma textsträngar tusentals gånger.

Det säger sig självt att det inte är särskilt effektivt eller rationellt. I stället kunde man ha en annan resurs, en ontologi, där man räknat upp alla ortnamn och hur de förhåller sig till varandra: ”Nyland” = ”Helsingfors” + ”Esbo” + ”Lovisa” etc. Vidare kan man ange att ”Helsingfors” = ”Hagnäs” + ”Sörnäs” + ”Kronohagen” etc. Då räcker det att från varje enskild uppgift i ditt material peka på en enda geografisk information. Datasystemet kan själv räkna ut att om du vill ha alla uppgifter från ”Nyland” hör också uppgiften från ”Hagnäs” dit. Dylika resurser finns och är i många fall tillgängliga på webben. Sådana finns över mängder av olika typer av begrepp på olika språk, vilket ger möjligheter till mycket effektiva sökningar också över språkgränser i vissa fall. När man väljer begreppsontologier måste man analysera dem noga, så att man är säker på att de motsvarar ens världsbild och begreppsapparat. Man bör komma ihåg att ontologierna är tolkningar och modeller av hur världen är konstruerad, inga absoluta sanningar. Det finns kulturella och disciplinära skillnader som kan vara mycket stora. Väljer man en ontologi som ur ens eget perspektiv sett innehåller tankefel, blir kvaliteten av forskningsresultaten lidande!

Att konstruera databaser för forskningsändamål är ingen enkel konst. Det kräver vana att skapa modeller av information som är logiskt hållbara och rationella. Sådant utvecklingsarbete kräver nära samarbete mellan forskaren och it-programmerare och helst också en informationsspecialist. Men ansvaret för att se till att det finns tillräcklig teknisk dokumentation är i slutändan forskarens, forskaren själv måste kunna fråga efter den och informationsspecialisten kan möjligen hjälpa till med att definiera vilken dokumentation som är mest relevant.

Ofta finns det kommunikationsproblem mellan it-experter och forskare. I synnerhet humanister är ofta omedvetna om vad som ens i teorin är tekniskt möjligt och de kan därför inte ens be om det. Å andra sidan vet it-experterna inte alltid vad humanisterna egentligen vill göra eller är ute efter, varför de inte alltid kommer sig för att erbjuda olika lösningar. Dessutom är informationsteknologin ett mycket vitt område med otaliga olika typer av kompetenser gällande olika system och typer av programmering. Ingen it-kunnig kan allt. En grundregel är ändå för humanisten i svårare förhandlingssituationer att vad som helst är möjligt att göra i teorin, åtminstone med existerande information. Frågan är bara vad man är beredd att betala för olika lösningar. Oftast har man begränsade resurser och då är det mycket viktigt att kunna samarbeta nära och i god anda med it-experter, trots att det kan vara svårt att hitta ett gemensamt språk ibland. Det lönar sig att alltid be om konkreta exempel och om man själv har förebilder eller goda exempel att visa, ska man göra det! Man måste förklara vart man vill komma och vad man behöver göra.

Då man hanterar mycket stora mängder data finns det alltid en större risk för enstaka fel. Om databaser dessutom lever och fylls på gör man också ofta korrigeringar då man hittar felaktigheter. Databaser är alltså ofta genuina digitala texter i det att de inte kan återges meningsfullt på papper och att de ofta lever och förändras. Text som tagits fram ur sådana system är i ovanligt hög grad konstruktioner, resultat av komplicerade tekniska processer som är helt osynliga för den som bara tittar på skärmen. Bakom den bilden finns många lager av tolkningar som går tillbaka ända till hur man skapat modellen och hur informationen motsvarar den verklighet den avbildar. En viktig fråga är om man skilt på namn och objekt och hur systemet hanterar olika varianter av språkliga begrepp och varianter. Finns dessa också representerade i systemet, eller måste den som använder systemet hantera dessa manuellt?

För att vara trovärdig måste information vara kopplad till annan information som berättar om proveniens och kontext. Detta är mycket viktigt då det gäller digital information. Vad, när, vem och framförallt hur är frågor som måste få svar i resursen. Detta måste gälla all information i ett system eller projekt, man måste försäkra sig om att data inte seglar fritt någonstans i systemet utan kontext och historia. Detta kräver i normala fall metadata. Många saker kan också förklaras i vidhängande dokumentation, såsom fältbeskrivingar eller kodningsmanualer, som också måste finnas tillgängliga. Man måste också kunna redogöra för principer vid tolkningar av oklara fall. Det är av största betydelse att sådant dokumenteras under arbetets gång så att man uppnår konsekvens i informationen och ger möjlighet till källkritiska bedömningar.

Ofta händer det dessutom att man använder assistenter vid inmatning eller bearbetning av data. Detta kan ibland vara förrädiskt om man inte följer upp arbetet mycket noga, eftersom det i själva verket många gånger kan vara helt avgörande för forskningens slutresultat hur en enskild assistent resonerat i tolkningsfrågor. Om man sedan dessutom använt sig av flera olika personer för arbetet utan mycket noggrann kollationering eller dokumentation, kan man plötsligt ha ett forskningsmaterial av sämre kvalitet än man tänkt sig. Utgångspunkten måste därför alltid vara att man framskrider iterativt, det vill säga stegvis, och i synnerhet i början måste man vara färdig att också ta några steg tillbaka emellanåt och göra om eller komplettera något. Även ett rutinarbete som kodning kan bli mer intressant och givande för den som gör det, vilket ju måste anses som ett plus för alla parter.

Det behövs oändligt mycket kommunikation mellan alla involverade parter och många gånger också teknisk personal. Det är å andra sidan ett minus: räkna med oändliga möten och diskussioner om olika små detaljer – kom då ihåg att varje detalj kan vara av mycket stor principiell betydelse och att det är viktigt att eftersträva konsekvens. Det är i synnerhet detta som avses med att man måste vara kreativ och flexibel vid genomförandet av arbetet. Trots att man satt mycket tid på planering, måste man vara inställd på att planerings- och utvecklingsarbetet fortsätter under hela projektet. Man måste ständigt ta ställning till nya frågor och kanske till och med revidera sina planer. Kill your darlings kan vara den enda lösningen ibland, om något visare sig för dyrt eller ta för lång tid. Då gäller det att vara kreativ.

< Föregående avsnitt   |   Nästa avsnitt >