For utvikling av bibliotekdata og sosial teknologiTanker & nyheterAllmenningOm oss

Velkommen til laboratoriet! Tanker & nyheter:

FRBRisering av bibliotekkatalogene

Da jeg begynte som stipendiat på HiO i 1997 fikk jeg som "pliktarbeid" å undervise i faget Dokumentbeskrivelse og lagring 3. Et tema som jeg ble bedt om å ta opp var FRBR, Functional Requirement of Bibliographic Records - som IFLA var i ferd med å sluttføre en rapport om. Rapporten kom ut i 1998 og ble senere oversatt til norsk.

Formålet med dette arbeidet, slik jeg oppfattet det, var å lage en modell av elementene og funksjonaliteten som inngår i bibliografiske poster. Dersom man benytter FRBR-modellen skulle det blant annet gjøre det lettere å koble sammen dokumenter som hører sammen (representerer samme verk) i databasen og presentere dokumentene som en enhet for sluttbruker. På den måten vil det f.eks. være mulig å søke på Nabokov, så vil man få samlet alle bibliotekets/databasens utgaver av f.eks. Lolita i en post, uavhengig av språk og forlag (og forhåpentlig med relasjon til de to filmversjonene av Lolita, som må betraktes som selvstendige verk).

Det er nærmere ti år siden rapporten kom, men, med ett viktig unntak, har vi sett lite til norske biblioteksystemers implementering av modellen. Bibsys har blant annet utviklet en prototype og viser stor interesse for formatet, men hva med de andre? Bibliofil, MikroMarc, Tideman og Aleph - hva skjer?

Beslektede poster:
En åpen husholdning
Alternativ OPAC
Kommentarer (3)  Permalink

Kommentarer

Kjetil Hillestad @ 16.08.2007 14:46 CET
FRBR-tanken åpner for mange muligheter innen søk og gjenfinning, ikke minst til å samle ulike utgaver av et verk. I svært mange tilfeller er brukerne lite interessert i hvilke utgaver som finnes - de vil rett og slett ha én av dem.

Imidlertid er ikke FRBR helt uproblematisk å innføre, når man tar i betraktning begrensningene som ligger i MARC-formatet og ikke minst i variasjonen av data som ligger i katalogpostene. Skal man ha full FRBR-visning, forutsetter det at katalogdataene er tilrettelagt for det. Og en full konvertering av katalogen er en omfattende prosess.

I Mikromarc 3 har vi tenkt FRBR, og har forsøkt å se på hva vi kan få ut av eksisterende katalogposter. Når man søker i sin egen katalog/database vil alle poster som har samme tittel og samme forfatter bli samlet på én linje i trefflisten. Kombinasjonen "Ibsen" og "Peer Gynt" vil dermed bli presentert samlet (og "Nabokov" og "Lolita" også for den del :-)

Ulike materialtyper skal ikke spille inn her; lydbøker, papirutgaver og eletroniske dokumenter samles, så sant de har lik forfatter og tittel. Med et klikk kan linjen ekspanderes i trefflisten, slik at alle de ulike utgavene av tittelen blir vist på hver sin linje.

I første omgang har vi valgt å samle dokumenter med samme tittel - ikke originaltittel - slik at ulike språkversjoner ikke vil bli samlet. Vi tror at en treffliste med originaltitler på ulike språk vil virke forvirrende på lånere som bare vil ha bøker de kan lese (= f.eks. norske oversettelser).
Knut Hegna @ 01.10.2007 09:13 CET
Til dem som driver med FRBRisering:

Jeg vil henlede oppmerksomheten på en studie som overtegnete og Eeva Murtomaa (Helsinki universitetsbibliotek) utførte i 2001. Rapporten fra studien ble publisert i mars 2002 og presentert på IFLA-møte i Glasgow samme år. Studien er mye sitert og brukt internasjonalt, men i det norske miljøet er den lite kjent.

Hensikten med studien var å kartlegge hvilke problemer man støtte på når man forsøkte å finne FRBR-strukturer (begrenset til verk, uttrykk, manifestasjoner) i tradisjonelle MARC-data.

Dataene som ble studert var hentet fra tre kilder: Norsk og finsk nasjonalbibliografi og BIBSYS.

Jeg vil tro at de som skal FRBRisere kataloger vil ha nytte av de nokså detaljerte kommentarene og også hvilke krav som må oppfylles i dagens kataloger for at FRBRisering skal være mulig.

Rapporten ligger her:

http://folk.uio.no/knuthe/dok/frbr/datamining.pdf

Rapporten inneholder også et par skisser til brukergrensesnitt for FRBRiserte data (siden den gang har overtegnete dratt disse skissene noe videre i diverse FRBR-foredrag, sist i Krakow i juni).

Det er viktig når man holder på med dette at man ikke mister fokus på hvilke mål man har satt for katalogen. Det er så lett å glemme HVORFOR man katalogiserer.

Svaret på HVORFOR sier også noe om HVORDAN man skal presentere dataene (for å understøtte målene).

"Guidelines for OPAC display" (fra SC IFLA Cataloguing section) understreker dette med følgende formuleringer (innholds- og ordningsprinsipper) :

5. Display what is asked for and needed for further action;
6. Display records in an order meaningful to the user, rather than in random order, when several records are retrieved;
7. Support navigation from the displayed information to related information

Jeg har sett en del sofistikerte, dynamiske grensesnitt som presenterer søkeresultater som vektete grafer som beveger seg når man fører markør/mus over grafen og de er morsomme, men de er mer forvirrende enn klare for brukeren (ikke lett å se hva slags tenkning som ligger bak).

Dersom man knytter autoritetsregistre, tesauri, klassifikasjonstabeller og -registre, emneordslister opp mot en FRBR-tenkning, tror jeg bibliotekkatalogene kunne få et løft som var dataene verdig. Sånn er det dessverre ikke i dag.

Det hadde vært å ønske at bibliotekmiljøet på HiO grep fatt i slike grunnleggende problemstillinger i tillegg til å henge seg på ulike hype-fenomener (bibliotek 2.0) (Så fikk jeg sagt det også ;-))
Tor Arne Dahl @ 01.10.2007 15:42 CET
Knut: Vi griper også fatt i slike grunnleggende problemstillinger. På masterkurs tar vi opp utfordringer ved FRBR-isering av eksisterende bibliotekkataloger, og har brukt både den artikkelen du henviser til og OCLC-eksperimenter i undervisningen.

Don't believe the hype!

Kommentér

Denne bloggen støtter gravatare.
E-postadressen din vil ikke bli publisert.
Spam vil bli slettet!

Navn*
E-Post
For Spammers Only
URL
Kommentar*
Gjør meg oppmerksom per E-post når noen kommenterer denne posten
Husk meg (bruker Cookies)

2007-11-08 13.46

Powered by Flux CMS