Foto: Enångers Hembygdsförening
Att skörda från Sockenbilder var lite småklurigt då lokalnoden i K-samsök inte är byggd för att skörda den typen av system. Sockenbilder lagrar sin data i XML-filer och har en XML fil för varje hembygdsförening. För att överhuvud taget kunna skörda så bad vi Jan-Åke Malmkvist att slänga ihop en XML-fil där han för varje socken anger URL:en till varje XML-fil och sökvägen till vart bilderna ligger för varje hembygdsförening då detta inte anges i datat i XML-filerna.
För att göra det möjligt att skörda sockenbilder behövdes i stort 3 klasser. En adapter, som är den klass som står för mappningen av data och också är den klass som lokalnoden kommunicerar med när den vill ha data från Sockenbilder. Adaptern använder i sin tur sig av en sökklass för att hämta själva datan från Sockenbilder. Sen finns det i sin tur en böna som är byggd för att hålla den data som hämtas från sockenbilder.
När En skörd initieras så vill lokalnoden ha ett värde på antalet poster som finns att hämta. Eftersom det inte finns någon siffra på detta hos Sockenbilder som jag kommer åt lätt så löste jag detta genom att den vid första anropet läser in XML-filen med alla URL:er till Sockenbilders XML-filer med data. Därefter hämtar den i tur och ordning dessa XML-filer och låter en SAX parser tugga i sig dessa och räkna ihop hur många poster det finns totalt.
Nästa sak som måste fixas direkt i första anropet är att meddela hur många poster den får. Detta var den riktigt kluriga delen. I vanliga fall kan man ha ett fast värde på denna. Alltså att den exempelvis hämtar 500 poster åt gången. Men eftersom datat för Sockenbilder ligger i flera XML-filer så var tanken att hämta data från en fil i taget. Jag gjorde så att adaptern direkt i konstruktorn med hjälp av en metod i sökklassen hämtar en siffra på hur många poster nästa fil innehåller, alltså detta måste den kolla varje gång då varje ”batch” är olika stor. Detta tycktes till en början fungera mycket bra. Men som Murphys lag säger: ”If anything can go wrong, it will” och det var precis vad det gjorde! Vissa av de XML-filer som hämtades innehåller relativt stora mängder data. När denna klump med data kom till centralnoden så tyckte centralnoden att den hade för lite minne för att hantera den mängden data. Personligen tyckte jag att centralnoden var lite gnällig och borde skärpa till sig, men centralnoden var tydligen rätt bestämd på den punkten…
Så inte nog med att jag måste skörda från flera URL:er, vilket systemet inte är byggt för, jag måste även dela upp datamängder som inte har någon som helst möjlighet att läsa lite, skicka det, läsa lite till osv. Jag och Börje (Lewin) beslutade att vi kunde lösa detta genom att temporärt spara data som hämtades om det var så att den innehåll stora datamängder. Alltså om en XML-fil som hämtas från Sockenbilder innehåll fler än 1000 poster så skickar vi endast tillbaka 1000 poster. Resten sparar vi ner till en temp fil. När sen nästa bunt skall hämtas så kollar sök klassen först om det finns en temp-fil som innehåller sparat data. Om det gör detta så skiter den i att hämta data från nästa URL och läser istället in filen och tar 1000 nya poster från denna, om det finns 1000 det vill säga, annars tar den alla som återstår. Efter lite pill och fix så lyckades jag dock få denna metod att funka mycket bra dock.
Ett annat trevligt problem jag hade var att jag på något sätt måste veta vilken URL till sockenbilder som skall användas varje gång. Eftersom jag läser in resurs filen med URL:er till Sockenbilder i en bestämd ordning och lagrar dessa i en lista så tyckte jag att det borde funka att ha ett index som pekar på vilken som skall skördas och fixa så att detta index behåller sitt värde mellan sessioner. Detta är sån tur är inte ett stort problem i Java, vilket inte gjorde det till ett stort problem. Dock fick jag till en början en liten bugg som gjorde så att om en skörd av någon anledning avbröts så började skörden på fel ställe nästa gång. Detta löste jag dock genom att nollställa denna räknare om “offset“ var 0, vilket det endast är första gången.
Detta sammanfattar nog de relevanta problem jag hade vid implementerandet av detta. Låter inte så krångligt nu när jag skriver det men hjärnan jobbade på högvarv ett antal timmar för att lösa vissa av dessa problem.
Läs mer om Sockenbilder i K-blogg.
>> Henrik Hjalmarsson är systemutvecklare på Riksantikvarieämbetet och jobbar med K-samsök.
Intressant och spännande att det gick att skörda data från xml. Skulle xml kunna vara en lösning man kan rekommendera för t.ex. hembygdsföreningar, som inte har resurser för databasprogramvara? Kan man i så fall utforma det på ett annat sätt så att det blir enklare att skörda data?
Ja, kanske. Det är oklart vilka vägar hbf kommer att gå. Grundkriteriet är ju att de lägger ut bilder på webben. Egentligen kunde det räcka med att lägga upp dem under någon befintlig bildtjänst som Flickr eller ännu enklare som ladda-upp.com. Men man kan nog inte se det som en långsiktigt trygg lösning förstås.
Sen kan man tänka sig att någon (måste inte vara RAÄ) tillhandahåller ett webbformulär där man kan mata in alla möjliga uppgifter om bilden, inklusive adressen där man hittar den. Sen kan k-samsök skörda denna info.
Snyggare är om man kan ladda upp bilder i samma gränssnitt som man anger metadatat. För stora mängder kan man göra detta via xml-filer i stället för webbformulär, men buntuppladdning av bilder låter svårare, t ex hur man namnger bilderna i bunt.
Intressant om det finns andra idéer kring detta, dvs hur vi stödjer de allra minsta institutionerna som har små resurser.
Börjes idé låter utmärkt. Om en större aktör tillhandahåller en sådan tjänst kan man ju tänka sig att den lagrar bilder och metadata direkt i K-Samsök (med tillägg för lagring av högupplöst bild), så ingen separat skördning behövs. Med Kringla och andra söktjänster som front får ju den lilla institutionen då både säker lagring av sina bilder och ett trevligt gränssnitt för sökning och presentation. Någon som är kunnig på sådant borde rälna på vad ett självkostnadspris för en sådan tjänst skulle bli.
Toppen att Sockenbilder är med! Visar att K-samsök inte bara är för större museer.
Fråga:Går det att skörda Sockenbilder inkrementellt med den här metoden?
Fundering: Med vissa tillägg (som lagring av högupplöst bild) och vidareutvecklingar (semi automatisk mappning baserad på XML-schema?) kanske XML-import är ett alternativ för existerande off-line databaser och kanske även för mindre onlineinstanser baserade på t.ex. SOFIE?
Spännande xml-funderingar, tycker jag. Jag föreställer mig att xml kan vara en billig, bra och relativt enkel lösning för föreningar att registrera och publicera föremålssamlingar också?
Man skulle i så fall önska sig en ”cookbook” för hur det går till. Och, ännu hellre, nåt slags gratisverktyg som följer nån lämplig standard vid registreringen (Dublin Core, etc)…
Det går inte att skörda inkrementellt eftersom man helt sonika hämtar en XML-fil över Internet, så man hämtar all information. Sedan kan vi förstås titta på uppdateringsdatum internt i servern och bara uppdatera de objekt som ändrats, men det sparar bara millisekunder ändå.
Sofie-databaser skulle kunna skördas via XML, det är på gång med XML-exportfunktionalitet från Sofie.
SOCH-protokollet är idag utbrett i och med SOCHs (K-samsöks) utbredning. Jag tror att man ska undvika dublin core som är komplicerat och omständigt för såväl små som stora. Bättre att mappa direkt mot SOCH och undvika en möjlig kvalitetsförsvagning pga mappning i två steg tycker jag!
Hej! Nu har det gått ett år! Har ni hittat någon bra lösning för HBFs med bilder? Vi (Kungsörs hembygdsförening) har just fått en kvarts miljon bilder som spänner över ca 100år!
Ett antal personer har börjat identifiera och skanna och nu väntar de på att jag skall välja väg ut på nätet. Suck!
Vi vill både tillgodose ”sökarna” dvs. släckforskare och andra som letar efter något och de som bara vill ”blädra” för kul skull. Vi har redan lagt ca 2000 bilder på http://www.picasaweb.com/kungsudden .
Mycket kul för många ortsbor men picasa är väl ”stökigt” för de äldre. Vi har börjat med Bygdeband men jag gillar inte att vi matar en databas hos någon annan. Sockenbilder känns bättre med orginalen hos oss men deras interface är fortfarande för ”sökande”. Skulle man inte kunna få till en ”albumgenerator” typ ”http://www.ornj.net/webalbum/” som samsök kan skörda?
Dvs, varje hbf sköter sitt album och samsök gör ”sökarna” glada. Tacksam för kontakt!
Hej Stefan,
Vi vill gärna skörda mer från hembygdsföreningar, men ni måste lösa bildlagringen själva. Att skörda metadata om bilderna kan ske på olika sätt så det kan vi lösa tillsammans, men vi har som sagt inte möjlighet att hjälpa till med lagringslösningar.
mvh
Börje Lewin