Hur ska vi göra K-samsök bättre?

[Ulf Bodin]

Om en vecka så träffas alla som levererar innehåll till K-samsök för ett första möte på en ganska lång tid. Mycket har hänt sedan sist (vi kan alla följa arbetet på: http://www.ksamsok.se/blogg/), bl a är utvecklingsprojektet avslutat och plattformen driftsatt. Några saker är aviserade att arbetas mer med  - som att kunna leverera metadata om ljud och rörlig bild, men det finns en hel del andra saker att ta tag i.

Vi på SHM har några saker som vi vill att RAÄ ska arbeta mer med:

• Det rör precisionen i sökresultaten som ibland är för vid för våra brukare. Det är bl a svårt att specifikt söka efter ordet "kappe" eftersom man träffar alla förekomster av "kappa", trots att det är två helt olika ord. Ibland är det smart med breda träfflistor; ibland är det dåligt. Hur löser man det?
• Sedan är det problem med elementet itemName (som för vår del innehåller sakord för föremål) och som används väldigt olika i olika leveranser. Vi uppfattar att det är viktigt att det finns ett element som entydigt och stringent talar om vad det är för entitet som beskrivs: byggnad, hög, stensättning, tavla, byggnadsritning, yxa, vante etc för institutioner (likt SHM) som inte har en distinkt klassifikation (i elementet itemClass/itemClassName)
• När det gäller leveransprotokollets utveckling kanske det är smart att kika lite på LIDO (Lightweight Information Describing Objects; http://cidoc.icom.museum/WG_Data_Harvesting%28en%29%28E1%29.xml) för att kanske homogenisera med om det är möjligt och kanske hämta inspiration från för att utveckla leveransprotokollet. LIDO fanns inte tillgängligt när K-samsöks protokoll togs fram och det är skapat för att lösa precis samma problem som K-samsöksprotokollet. De är ganska lika. Kanske finns det även andra som arbetat med format för att aggregera kulturarvsinformation som vi borde snegla på.
• Protokollet bör också utvidgas för att kunna hantera informationspaket som beskriver andra saker än museiföremål - berättelser och annan digital förmedlingsdata - inte bara rådata.
• Behovet finns även att kunna knyta användargenererade data (UGC) till entiteter i K-samsök på ett systematiskt och bra sätt så att informationen finns med och är sökbar men att det fortfarande finns en tydlig åtskillnad mellan "våra" data och användarnas egna data.

Vad tycker du att man ska fokusera på när det gäller K-samsöks innehåll, protokoll, metadata-standards mm? Vad ska vi ta med oss till mötet?

[Magnus Johansson]

Låter som bra och viktiga punkter. När det gäller precisionen i sökresultat, det är alltså inte möjligt att använda citattecken runt sökvärdet för att ange att det är just "kappe" man vill ha? Sen förstog jag inte problemet med itemName (vilket säkert beror på att vi inte använder det så stringent som det var tänkt). Kan du ange exempel?

 

Sen vill jag minnas att det har diskuterats att kunna leverera utställningar till k-samsök. Hur har det gått med det, det kanske redan är möjligt?

[Ulf Bodin]

Jag provade också med att sätta "kappe" inom citattecken men det ger samma resultat (åtminstone i Kringla).

Utställningsinfo i någon form av element (<exhibitedAt>?) kommer jag också ihåg att vi diskuterat. Jag ska försöka att hitta denna diskussion. På SHM skickar vi med denna information i form av ett tema som pekar på en resurs hos oss: http://mis.historiska.se/rdf/theme/theme.xml men det talar inte om var i utställningarna föremålen finns (t ex för att bygga utställningsappar).

itemName som börjar på "C" kan beskådas här: http://www.kulturarvsdata.se/ksamsok/api?method=statistic&style...

[Ulf Bodin]

Jag hittade ett blogginlägg om just information om föremålets placering i verkligheten (som t ex utställningar) som kanske kan vara en utgångspunkt för en diskussion: http://blogg.historiska.se/digitalamuseer/2010/02/08/var-kan-jag-se...

[Nils Weinander]

* Sökprecision: gissningsvis ett problem med ordstamning. Jag tror det finns ostammat index också, som man borde kunna nyttja för att söka på exakt ord.

* itemName: exemplen låter i mina öron som itemClassName, för mig är itemName entitetens beteckning: Storkyrkan, Stenbron, Östra Fågelvik 5:1 etc.

* LIDO är intressant att titta mer på, tyvärr har det ärvt pratigheten fråm museumdat.

* UGC skulle kunna bli första exemplet på data som lagras på entiteterna med eget namespace?

[Ulf Bodin]

* Skulle ord inom citationstecken "kappe" kunna sökas i det ostammade indexet med någon form av automatik?

* itemName: Det är förmodligen här problemet ligger. Tolkningen av vad itemName ska innehålla görs olika av olika leverantörer och det är därför det ser ut som det gör i indexet. Att lägga in sakord i itemClassName är möjligt men för många av oss innebär anspelningen på class att termmängden skulle vara relativt ändlig och kontrollerad, och det är den tyvärr inte på alla ställen (som t ex SHM där den är aningen mer sladdrig för våra sakord). Objektens vedertagna namn/beteckning ska i min tolkning av protokollet ligga i elementet itemTitle.

* Ja, K-samsöks protokoll är mer rakt på sak och lättanvänt än LIDO för en tillämpningsutvecklare, men LIDO är kanske bättre på att representera ett objekts fulla beskrivning.

* När det gäller UGC så borde dessa kunna lagras som egna element i entiteterna. Är det möjligt att skapa en gemensam skördetjänst på varje port som skördar upp användargenererat innehåll från en leverantör (som har sådana data) och lägger in i entiteterna - http://adelso.wordpress.com/2009/08/27/anvandargenererat-innehall-i... - och på så sätt så kan UGC tillföras på entiteter som inte ägs själv av institutionen?

[Börje Lewin]

Ja det finns ett strikt index också. Fritextsökning med stamning: använd indexet "text", fritextsökning utan stamning eller böjningar: använd indexet "strict".

 

[Johan Carlström]

Bra förslag som jag/vi tar till oss. Vi har en punkt om detta på tisdag.

 

ItemName beskrivas på ksamsok.se som "Objektets huvudsakliga benämning eller sakord. Specifik benämning av ett objekt, t ex itemName=”Yxa”", dvs det Ulf säger. För t ex FMIS och Bebyggelseregistret har vi valt att lägga byggnads- resp. fornlämningsidentitet i itemNumber. Det skulle behövas tydligare förklaringar av parametrar med exempel utifrån olika objektstyper (museiföremål, foton, kulturmiljöobjekt osv).

 

I o m att vi implementerat Solr så har vi möjlighet att leverera mer exakta söksvar. Vi håller på och testar just nu.

[Barbro Björnemalm]

Jag har än så länge endast ett par frågor;

Hur ofta uppdateras K-samsök? Nordiska museet, t ex, har endast 35 640 föremålsposter i Kringla, trots att det länge har funnits 279 219 webbpublicerade föremålsposter i DigitaltMuseum.

Jag undrar också lite över mappningen. I föremålsposterna som kommer från DigitaltMuseum är alla händelser under rubriken Händelser mappade som Deponerade. Vad beror det på - på DigitaltMuseum eller på felaktig mappning från början?

 

[Börje Lewin]

DigitaltMuseum visar objekt från ett flertal museer, varav fyra finns i K-samsök. De har jobbat en del med mappningen men jag vet inte om de är klara med det och vi kan skörda om. Jag ska kolla med dem.

Institutionerna kan välja själva hur ofta de vill att vi skördar genom att meddela oss. De som stödjer inkrementell skörd (dvs att man bara skördar sånt som är nytt eller ändrat) skördar vi gärna varje natt. Stora databaser som inte stödjer inkrementellt vill vi helst skörda en gång i månaden eller ännu mer sällan. Små databaser kan vi skörda om oftare förstås.

[Matts Ramberg]

Jag har inte förberett något till mötet men tycker det är viktigt att det finns en användargrupp som kan dryfta frågor av relevant karaktär.

Vi har för t ex avsikt att lägga till ett fält i databasen som skulle göra den mindre "rå" än vad vi angett när vi "portade" den. jag tror nog det "bara" är att ändra lite i "porten. Men skulle t ex vilja diskutera detta med någon som gjort något.

Vi har också påbörjat ett samarbete med andra teknikhistoriska museer med syftet att medverka i en ansökan om EU-medel från kommisionen. Där pratas en del om just LIDO. Behöver även där någon att prata med (utan att egentligen kunnat formulera konkreta frågor men det brukar ge sig i en dylik "användarkonstellation"

[Ulf Bodin]

Frågan om att lägga till egna fält/element (kanske under ett eget namespace) i en leverans till K-samsök är intressant. Det tycker jag att vi kan ta upp också på mötet.

Det finns dessutom inget som hindrar att vi inleder ett arbete med att mappa upp våra databaser mot LIDO oavsett om detta format kommer att påverka K-samsöks protokoll eller inte. Varje port kan potentiellt hantera fler olika format om det behövs. När vi började leverera data så uppfattade jag exempelvis det som politiskt viktigt att följa standarder och därför mappades SHM:s databaser upp mot Museumdat (som jag tror att ingen använt en enda gång) och jag tror att alla portar som standard även stöder Dublin Core. Om en mappning mot LIDO ger samverkansfördelar utåt så tycker jag att vi ska genomföra en sådan. Jag är helt på.

[Nils Weinander]

RAÄ:s Java-port har ingen DC-mappning i alla fall.