Glitre

13.03.2011

Öppna bibliotek, del 1

Filed under: Öppna bibliotek,Plugins — magnusenger @ 18:40

Glitre har nå støtte for å hente data ut av Öppna bibliotek, både på treffliste- og postnivå.

Disse eksemplene henter sine data fra BibLab sin demo-installasjon av Öppna bibliotek. Funksjonaliteten ligger i en «plugin» som heter oppnabib.php.

Neste trinn blir å implementere støtte for å legge inn data i Öppna bibliotek fra Glitre, en noe mer omfattende oppgave enn å hente dataene ut.

Som nevnt over er støtten for Öppna bibliotek forsøkt implementert som en «plugin», og tanken er at Glitre skal ha en infrastruktur som skal gjøre det så enkelt som mulig å gjøre interessante ting via plugins. Som et ledd i arbeidet med å gjøre plugin-strukturen så generell som mulig er det også implementert en enkel plugin som henter omslagsbilder fra Open Library, openlibrary_image.php. Se eksempel på visning av omslagsbilde.

Tanken er at plugins skal kunne slås av og på og gis argumenter/verdier fra fila config.php.

3.01.2011

Glitre 2011

Filed under: Diverse — magnusenger @ 22:01

Etter en ufrivillig pause er det nå rett før Glitre er i gang med videre utvikling igjen – dvs styrking av søkefunksjonaliteten og kommunikasjon med Öppna bibliotek. Følg med, følg med!

10.09.2010

Fase 2: Öppna bibliotek og brukerskapte data

Filed under: Öppna bibliotek — magnusenger @ 12:56

Glitres søke-kode har nå nådd det vi kan kalle «proof of concept»-stadiet, dvs at det stort sett funker, men at det gjenstår en del pussing på feilmeldinger, mindre ulikheter mellom Z39.50-tjenere osv. Dermed er tiden inne for fase 2 av prosjektet: integrering med Öppna bibliotek (ÖB).

Öppna bibliotek (se omtale i BibLab sin allmenning) er et svensk system som er utviklet for å samle og spre «brukerskapte data» (kommentarer, tagger, terningkast) knyttet til bibliografiske poster. Tanken er at man lettere skal kunne oppnå den kritiske massen av bidrag som trengs for å få interessante resultater ved å samle bidrag fra mange systemer.

Öppna bibliotek er p.t. ikke sluppet som fri programvare, men det finnes en ambisjon hos de som står bak om å gjøre dette en gang i fremtiden. Biblioteklaboratoriet har imidlertid fått tilgang til kildekoden og satt det opp på en server, og det er denne installasjonen Glitre i første omgang vil snakke med. BibLab har også fått tilgang til kildekoden til et svensk system som snakker med ÖB, men siden dette ikke er fri programvare vil Glitre implementere egne rutiner for kommunikasjon med ÖB, med den svenske programvare som rettesnor og inspirasjon under vegs.

BibLab vil en eller annen gang før jul arrangere en åpen workshop rundt Öppna bibliotek, der det vil bli invitert til å diskutere forhold knyttet til brukerskapte data. Aktuelle spørsmål kan være:

  • Er vi tilfreds med at systemleverandørene lager proprietære siloer for brukerskapte data?
  • bør vi ha en nasjonal, åpen infrastruktur for slike data, der alle biblioteksystemer kan bidra?
  • Hvem skal i så fall stå for drift og vedlikehold?

Har du synspunkter på dette? Luft dem gjerne i kommentarfeltet!

Fra «plugins» til «formats»

Filed under: API — magnusenger @ 12:30

Glitre har lidd litt under at kodesnuttene som formaterer bibliografiske poster både har vært omtalt som «formats» og «plugins». Dette skal det nå være ryddet opp i, slik at «format(s)» brukes over hele linja. Følgende endringer er gjort:

  • Mappa med snuttene er omdøpt fra «plugin» til formats»
  • «format» beholdes som argument i APIet, og «plugin.» fjernes fra verdiene, slik at man bruker format=simple, ikke format=plugin.simple

Samtidig er det lagt til en liste med tillatte formater i config.php, som en ekstra sikkerhetsforanstaltning og slik at det skal være mulig å slå formater av og på, uten å slette eller flytte filer:

$c['allowed_formats'] = array('simple', 'isbn-plain');

Denne navneendringen åpner også for at feks koden som knytter Glitre til Öppna bibliotek (neste fase i utviklingen) kan kalles en plugin, noe som faller mer naturlig enn den navnebruken som har forekommet til nå.

31.08.2010

Piggyback?!?

Filed under: Z39.50 — magnusenger @ 14:58

I Z39.50 er det noe som heter piggybacking. Dokumentasjonen for YAZ/PHP-funksjonen har følgende kortfattede beskrivelse:

Enabling piggyback is more efficient and usually saves a network-round-trip for first time fetches of records. However, a few Z39.50 servers do not support piggyback or they ignore element set names. For those, piggyback should be disabled.

En kjapp test viser at av de norske Z39.50-tjenerne har Aleph, Bibliofil, Koha og Mikromarc støtte for piggyback, mens BIBSYS ikke har det. Reindex og Tidemann har det fortsatt ikke vært mulig å teste.

Z39.50-koden i Glitre ble først testet mot BIBSYS og piggybacking var derfor slått av. Dette er nå endret, slik at det er slått på for de systemene som støtter det, noe som altså burde gi litt bedre ytelse ved søk.

Se også: Z39.50 og piggyback i BibLab sin allmenning.

19.08.2010

Visualisering av mellomlagringsstrategi

Filed under: Logging,Mellomlagring,Sortering — magnusenger @ 11:34

For å kartlegge suksessen til mellomlagringen av Z39.50/SRU søk er det innført et enkelt logg-system, som skriver følgende informasjon til en ren tekst-fil:

  • Dato og tid for forespørselen
  • Hvilken side i trefflisten som be etterspurt
  • Hvilket bibliotek det ble søkt mot
  • Hva det ble søkt etter
  • Og ikke minst hvordan mellomlageret fungerte. Her brukes følgende «koder» :
    • nocache = søket ble ikke funnet i mellomlageret og et nytt søk ble utført mot den valgte Z39.50/SRU tjeneren
    • raw = søket ble funnet i mellomlageret, men ikke sortert på den måten som ble etterspurt, den opprinnelige trefflista (i MARCXML-format) ble hentet fra mellomlageret og sortert på ønsket måte
    • sorted = søket ble funnet i mellomlageret, ferdig sortert

For å gjøre det enklere å følge med på hvordan mellomlagringen fungerer er det laget en liten visualisering (kildekode) som viser innholdet i loggen og en grafisk fremstilling av forholdet mellom de tre mulige utfallene som er skissert ovenfor. Dataene oppdateres hvert 10. sekund, slik at man kan følge utviklingen i tilnærmet sanntid. (NB! Loggen vil bli tømt med ujevne mellomrom.)

Tanken er at denne loggingen og visualiseringen bare er starten på et system som skal gjøre det enkelt å overvåke bruken av en Glitre-installasjon.

API-demo

Filed under: API — magnusenger @ 11:18

Så langt har denne bloggen sagt en del om utviklingen av Glitre, men den eneste måten å se endringene på har vært gjennom kildekoden. Nå kan vi endelig avduke en «live» demo:

http://oppdrag.libriotech.no/glitre/api/

Prøv for eksempel en forespørsel som denne:

http://oppdrag.libriotech.no/glitre/api/?library=deich&q=ibsen

For å gjøre det lettere å se hvilke parametere som er obligatoriske og valgfrie, hvilke valgmuligheter som finnes format osv er det laget en «guide» til APIet her:

http://oppdrag.libriotech.no/glitre/api/guide.php

NB! Denne installasjonen brukes til aktiv utvikling, så til tider vil det være ting som ikke fungerer som de skal, og det vil helt sikkert komme endringer i navn på parametere osv. En liste over kjente feil og mangler finnes på GitHub. Etter hvert vil det bli to tilgjengelige demoer: en som kjører relativt stabil kode og en der aktiv utvikling skjer. Vi kommer tilbake med detaljer om dette etter hvert.

12.08.2010

Mellomlagring

Filed under: Mellomlagring,Sortering — magnusenger @ 11:10

Det tar tid å hente poster fra Z39.50- og SRU-tjenere. Hvis det samme søket skal utføres to eller flere ganger med rimelig kort mellomrom er det liten vits i å hente trefflista fra tjeneren på nytt den andre (og tredje osv) gangen. Derfor har Glitre nå implementert mellomlagring (caching) av søkeresultater. Dette gjøres i to nivåer:

  1. De «rå» søkeresultatene lagres
  2. Søkeresultatene lagres etter at de har blitt sortert

Fordelen med dette er som følger: La oss si at to brukere utfører akkurat det samme søket med kort tids mellomrom, la oss kalle det Søk1 og Søk2. Søk1 medfører at postene hentes fra tjeneren og mellomlagres. Så sorteres de i tråd med brukerens ønske (eller standard sortering), og resultatet av dette mellomlagres. Når så Søk2 kommer, og ber om å få postene i samme rekkefølge som Søk1 er postene allerede sortert, og brukeren slipper å vente på at de skal bli sortert og systemet vårt slipper å bruke krefter på å gjenta sorteringen. La oss så si at den som utførte Søk2 utfører det samme søket en gang til, men ber om å få postene sortert på en annen måte. Nå er ikke mellomlageret med de sorterte postene til noen hjelp, men vi har fortsatt den opprinnelige trefflista mellomlagret og kan hente denne fra mellomlagret og sortere den etter brukerens ønske, uten at vedkommende trenger å vente på at postene skal hentes på nytt fra søketjeneren.

Hvor lang tid poster skal lagres i mellomlageret er et åpent spørsmål. Lagres de for lenge vil ikke endringer i de opprinnelige postene (nye, slettede og/eller endrede poster) reflekteres i søkeresultatene. Lagres de for kort vil ikke mellomlagringen ha noen effekt, fordi resultatene «går ut på dato» før det rekker å komme et nytt søk som kan dra nytte av det gamle. I utgangspunktet er levetiden til mellomlageret satt til et døgn, men dette kan endres gjennom konfigurasjonsvariabler. På sikt bør det antagelig implementeres et logg-system som viser hvilke søk som blir utført og i hvilken grad memmomlagringen faktisk kommer til nytte.

Mellomlagringen i Glitre bygger på PEAR-modulen Cache_Lite.

11.08.2010

Sorteringshelomvending

Filed under: Sortering — magnusenger @ 16:49

Som tidligere nevnt ble sortering først forsøkt implementert ved hjelp av XSLT. Etter å ha tenkt litt på neste trinn i prosessen, paginering av trefflista, viste det seg ganske fort at dette var en lite hensiktsmessig tilnerming, og sorteringen har derfor blitt re-implementert i PHP.

I samme runde har pagineringen av trefflista blitt implementert på en enkel måte. Problemet med måten det er gjort på er at koden som kaller opp søket ikke har noen måte å vite antallet treff på, og den må derfor prøve seg frem med page=1, page=2 osv til den får en feilmelding i retur. En løsning på den problemstillingen kommer etter hvert.

5.08.2010

Sortering med XSLT

Filed under: MARC,NORMARC,Sortering — magnusenger @ 14:41

Sortering med XSLT er nå implementert. Antagelig vil det trenges litt finpuss på fjerning av tegn fra årstall* osv, men den grunnleggende funksjonaliteten er på plass.

Kommentarer fra Twitter tyder på at andre mener det vil være raskere å implementere sorteringen i PHP (dvs plukke data fra postene og legge dem i array i PHP, sortere arrayene og så sette sammen postene i ny rekkefølge basert på denne sorteringen), men i første omgang nøyer vi oss med den nå værende løsningen. Dersom det blir tid til det senere i prosjektet kan vi komme tilbake til saken og prøve å implementere sorteringen på den foreslåtte måten. Da blir det både mulig å gjøre tester av hurtigheten til de to metodene, og tilby begge som konfigurerbare alternativer i Glitre.

* Årstall i MARC-poster er et glitrende eksempel på at de «maskinlesbare» dataene i MARC langt fra er så maskinlesbare som de burde ha vært:

I følge NORMARC inneholder 260$a «År. Dette er utgivelsesår, produksjonsår eller copyrightår.». Allerede her ser vi et problem. Vi har et årstall, men vi vet ikke egentlig hva årstallet representerer. Dette burde egentlig vært tre adskilte felt, eller det burde vært et ekstra felt/indikator som fortalte akkurat hva slags felt det egentlig er snakk om.

Et annet problem er at feltet ofte ikke inneholder rene årstall. Tilfeldige stikkprøver har avslørt følgende varianter:

  • [2003?]
  • [200-?]
  • pp1992
  • [2004]

Hvordan skal man kunne sortere disse på en fornuftig måte? Jo, man blir nødt til å skrelle bort de ekstra tegnene etter beste evne. Glitre har foreløpig løst dette på følgende vis:

<xsl:sort select="translate(datafield[@tag=260]/subfield[@code='c'], 'cop.[]', '')" data-type="text" order="{$sortOrder}"/>

Dette innebærer at alle forekomster av tegnene «cop.[]» i 260$c fjernes før sorteringen gjøres. Dersom MARC skulle vært virkelig maskinlesbart burde feltet inneholdt kun et rent årstall, og de opplysningene som de ekstra tegnene representerer burde vært kodet ved help av andre delfelt.

Neste side »

Opprett en gratis blogg eller et nettsted på WordPress.com.