Glitre

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.

Advertisements

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!

Blogg på WordPress.com.