Glitre

4.08.2010

Hvordan sortere MARC-poster?

Filed under: NORMARC,Sortering — magnusenger @ 15:59

Som tidligere nevnt har Glitre konkludert med at sortering må implementeres i Glitre, det er ikke mulig å basere seg på sortering på tjenerne som søkeresultatene hentes fra. Basert på tidligere erfaringer fra Pode er det (minst) to måter å gjøre dette på:

  • I Podes reiseplanlegger ble sorteringen gjort ved help av <xsl:sort>, før XSLT ble benyttet til videre bearbeiding av postene i MARCXML-format.
  • I Podes musikkmashup ble sorteringen gjort ved hjelp av array i PHP. Elementene det skulle sorteres på (tittel, forfatter osv) ble plukket ut av postene og brukt som nøkler i array som så ble sortert, før videre bearbeiding av postene.

Glitre vil i første omgang satse på å sortere med XSLT, dels fordi det vil være det mest elegante, dels fordi rå MARC-data skal være et av mange mulige ut-formater fra Glitre, og XSLT vil forhåpentligvis gjøre dette mulig uten at man trenger å plukke postene fra hverandre og så sette dem sammen igjen.

Advertisements

Hvor mange poster skal sorteres?

Filed under: Diverse,Sortering — magnusenger @ 15:27

Glitre har nå undersøkt mulighetene for sortering i norske Z39.50– og SRU-tjenere, funnet ut at den er fraværende eller sterkt mangelfull i samtlige systemer og konkludert med at det må utvikles en hjemmesnekret løsning for sortering. Dette reiser et interessant spørsmål:

Hvor mange poster skal/kan/bør/må man laste ned fra tjeneren før man sorterer? Hvis søket har gitt 10 eller 20 treff er det ikke noe problem, da laster man ned alle sammen før man sorterer. Men hva om søket gir feks 5.000 treff? Da støter man på minst to problemer:

  • Belastning på tjeneren
  • Tiden det vil ta å første laste ned og så sortere

Så hva gjør man?

  • Forteller den som satte i gang søket at her ble det for mange treff, vennligst søk mer spesifikt?Hvor skal man i så fall sette grensa for antall treff før denne meldinga vises? 100? 1.000?
  • Laster ned et begrenset antall poster og presenterer dem? I så fall: hvor mange?

Eller er det sånn at de ulike søketjenerne (Z39.50/SRU) legger begrensninger på hvor mange poster man kan hente pr søk?

SRU og sortering

Filed under: Sortering,SRU — magnusenger @ 15:23

En rask undersøkelse av SRU-tjenere tilknyttet BIBSYS og Koha viser at ingen av dem støtter sortering slik det er spesifisert i versjon 1.2 av CQL. Dermed blir Glitre nødt til å ty til hjemmesnekret sortering over hele linja.

Sorteringen skal i versjon 1.2 av CQL spesifiseres som en del av søkebegrepet i URLen:

"dinosaur" sortBy dc.date/sort.descending dc.title/sort.ascending

Hverken BIBSYS eller Koha endrer sorteringen i tråd med de sorteringeskriteriene man oppgir.

3.08.2010

Sortering med Z39.50

Filed under: Sortering,Z39.50 — magnusenger @ 11:53

En ting man veldig ofte forbinder med søk er sortering, og det er rimelig klart at Glitre bør tilby sortering av trefflister.

Sorteringskriterier

Hvilke kriterier/felter er det aktuelt å sortere på? Disse er kanskje de mest nærliggende:

  • Tittel
  • Forfatter, sortert på etternavn
  • Publikasjonsår
  • Anskaffelsesdato, slik at de aller nyeste postene havner øverst på lista, uavhengig av når dokumentet de beskriver er publisert

Er det flere kriterier man burde kunne sortere på?

Stigende/synkende

Skal man sortere kan man velge mellom stigende og synkende sortering. For de ulike kriteriene ovenfor vil det være aktuelt med litt ulik standard sortering:

  • Tittel: Stigende («A» kommer først)
  • Forfatter: Stigende («A» kommer først)
  • Publikasjonsår: Synkende (nyeste kommer først)
  • Anskaffelsesdato: Synkende (nyeste kommer først)

I tillegg vil det være aktuelt å kunne velge «det motsatte» for alle kriteriene, slik at lista snus på hodet.

Standard sortering

Hvordan bør en treffliste sorteres, dersom den som utfører søket ikke eksplisitt har bedt om en bestemt sortering? Herom strides de lærde, antagelig vil man kunne finne noen som argumenterer for at hvert enkelt av kriteriene ovenfor bør være standard. Glitre bør antagelig ta konsekvensen av dette og la standard sortering være konfigurerbart for den enkelte installasjon og/eller det enkelte søkemål.

Teknisk

Glitre baserer søkefunksjonaliteten mot Z39.50 søkemål på den frie programvarekomponenten PHP/YAZ (se også BibLabs allmenning). Denne utvidelsen til PHP inneholder blant annet en funksjon som ser høyst relevant ut i forhold til sortering, nemlig yaz_sort().

void yaz_sort ( resource $id , string $criteria )

Som vi ser tar denne funksjonen to argumenter:

  • $id er en referanse til en allerede etablert Z39.50-sesjon
  • $criteria spesifiserer hva det skal sorteres på og hvordan det skal sorteres
    • Formatet er «field1 flags1 field2 flags2 …», der
      • «field» er Bib-1 attributter eller navngitte indekser
      • «flag» angir retning og bahndling av store og små bokstaver:
        • a = sorter stigende
        • d = sorter synkende
        • i = sorter avhengig av store og små bokstaver
        • s = ta hensyn til store og små bokstaver ved sortering

Eksempler på sorteringskriterier:

  • «1=4 di» = sorter stigende på tittel, uavhengig av store og små bokstaver
  • «title di» = samme som over, men med en navngitt indeks
  • «1=31 ai» = sorter synkende etter «Date of publication» (nyeste først)

Fra kriterier til Bib-1 attributter

Nå vet vi hvilke kriterier vi ønsker å sortere på og hvordan vi ønsker å gjøre det, men det gjenstår å «mappe» kriteriene våre til Bib-1 attributter. Vi kan bruke dokumentet ATTRIBUTE SET BIB-1 (Z39.50-1995): SEMANTICS, og finne følgende (1. kolonne er navnet på indeksen, 2. kolonne er tallet som brukes for å lage feks 1=4, 3. kolonne er en beskrivelse og 4. kolonne er de MARC-feltene som er anbefalt inkludert i indeksen):

Tittel: 1=4

Title                   4  A word, phrase, character,      130, 21X-24X, 440,
                           or group of characters,         490, 730, 740, 830,
                           normally appearing in an item,  840, subfield $t
                           that names the item or the      in the following:
                           work contained in it.           400, 410, 410, 600,
                                                           610, 611, 700, 710,
                                                           711, 800, 810, 811

Forfatter

Author-name          1003  A personal or corporate author, 100, 110, 111, 400
                           or a conference or meeting      410, 411, 700, 710,
                           name.  (No subject name         711, 800, 810, 811
                           headings are included.)

Publikasjonsår

Date-publication       31  The date (usually year) in      008/07-10, 260$c
                           which a document is published.  046, 533$d

Anskaffelsesdato

Date-acquisition       32  The date when a document was    541$d
                           acquired.

Empiri

Vi har nå en ide om hva vi ønsker å sortere på, og hvordan vi ønsker å gjøre det. Spørsmålet blir da om dette lar seg gjøre i praksis? Innledende tester har gitt følgende resultat:

Aleph Bibliofil BIBSYS Koha Mikromarc Reindex Tidemann
Default sortering Kronologisk, synkende Alfabetisk på tittel Tilfeldig? Alfabetisk på tittel Tilfeldig?
Støtter yaz_sort() Ja Nei Nei Ja Nei
Navngitte attributter Ja Ja
1=1 : Personal name Ja Nei (Feilmelding)
1=4 : Title Ja Ja
1=30 : Date Ja Ja
1=31 : Date-publication Nei Nei (Usikkert hva det faktisk sorteres på)
1=32 : Date-acquisition Nei Ja
1=1003 : Author Ja Nei (Ser ut til å sortere på tittel)

NB! En oppdatert versjon av denne tabellen vil bli vedlikeholdt i BibLab sin allemenning: Z39.50, SRU og sortering.

Reindex og Tidemann er ikke testet, siden vi i skrivende stund ikke vet om noen testbare Z39.50-tjenere for disse systemene. Leverandørene er kontaktet for å avklare dette.

Vi ser ellers at det bare er Aleph og Koha som støtter funksjonaliteten i yaz_sort(), og at disse i varierende grad støtter sortering på de kriteriene vi er interessert i.

Konklusjon

Siden støtten for yaz_sort() er så dårlig som den er blir Glitre nødt til selv å implementere sortering, på ett eller annet vis. I og med at støtten for de kriteteriene vi ønsker å sortere på er dårlig selv i systemene som støtter yaz_sort() vil antagelig det beste være å se helt bort fra denne funksjonen, og implementere all sortering selv.

Kommende bloggposter vil omhandle sortering i SRU og hvordan sortering kan implementeres…

2.08.2010

Glitre og «målsystemer»

Filed under: SRU,Z39.50 — magnusenger @ 16:43

Et av målene med Glitre er at løsningen som utvikles skal kunne brukes av norske bibliotek, uavhengig av biblioteksystem. Det innebærer at løsningen må testes mot de systemene som er aktuelle på det norske markedet. Foreløpig jobber vi ut fra følgende liste:

  • Aleph
  • Bibliofil
  • BIBSYS
  • Koha
  • Mikromarc
  • Reindex
  • Tidemann

Er det noen som mangler?

Testingen forutsetter at vi har tilgang til å søke mot en Z39.50- eller SRU-tjener for det aktuelle systemet. Foreløpig har vi ikke funnet slike for Reindex eller Tidemann. Vet du om tjenere vi kan bruke? Si i fra!

Include eller API? Ja takk, begge deler!

Filed under: API — magnusenger @ 11:04

Tanken med Glitre var i utgangspunktet at komponenten som utvikles skulle være en «include», dvs en PHP-fil som kan inkluderes i en annen PHP-fil og gjøre en del funksjoner tilgjengelige for koden i den inkluderende fila.

Allerede tidlig i arbeidet ble det imildertid klart at det ikke vil være mye vanskeligere å bygge et API på toppen av includen, slik at Glitre får muligheten til å «snakke» med kode som ikke nødvendigvis kjører på den samme maskinen som Glitre selv. Dette er dels nyttig for å teste Glitre – man kan kjøre søk gjennom Glitre og få ut trefflista som feks XML, dels kan det gjøre det enklere å ta i bruk Glitre. Dersom man ikke har tilgang til å installere de komponentene som er nødvendige for at Glitre skal fungere på den maskinen der man trenger funksjonaliteten vil man kunne installere den på et annet, egnet sted, og så benytte APIet for å hente de dataene man trenger.

Tanken er at APIet skal kunne returnere data i ulike MARC-format, XML, JSON osv. Denne Funksjonaliteten vil bli implementert i form av «plugins» – dvs at prosjektet kanskje ikke rekker å implementere all tenkelig funksjonalitet, men at det ihvertfall skal foreligge et rammeverk som skal gjøre det så enkelt som mulig å få den på plass etter hvert.

25.05.2010

Første kildekodeoppdatering

Filed under: Kildekode — magnusenger @ 15:02

Nå er Glitres første kildekodeoppdatering tilgjengelig på GitHub. Dette er et ekstremt tidlig stadium i utviklingen, men det er ihvertfall en start og noe å bygge videre på. Nye oppdateringer vil dukke opp i venstremargen her etter hvert som de blir sendt til GitHub. Beskrivelser av forutsetninger for å ta koden i bruk, og hvordan man praktisk går frem for å teste den, kommer etter hvert.

Takk til Pode – selve søkefunksjonaliteten her er lånt fra Podes reiseplanlegger (eller var det Musikkmashupen?), men planen er å raffinere den og gjøre den mer gjenbrukbar.

Hallo verden!

Filed under: Diverse — magnusenger @ 11:19

Velkommen til Glitre sin hjemmeside! Glitre er et prosjekt i regi av Buskerud fylkesbibliotek, med økonomisk støtte fra ABM-utvikling. Vi skal lage en CMS-uavhengig komponent som skal gjøre det enkelt å integrere følgende i bibliotekenes hjemmesider (eller andre tjenester, for den saks skyld):

  • trefflister og postvisninger fra bibliotekkatalogen
  • data fra en norsk implementasjon av Öppna bibliotek

Denne bloggen vil bli brukt til å informere om fremdriften i prosjektet, men du kan også laste ned kildekoden etter hvert som den blir gjort tilgjengelig på GitHub (og den kommer til å bli gjort tilgjengelig fortløpende!) eller følge oss på Twitter eller Facebook.

« Forrige side

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