Forslag til en social OPAC – reloaded

I september 2006 skrev jeg et indlæg på en udviklingsblog på Herning Bibliotekernes website, hvor jeg kom med et forslag til opbygning af den “sociale” OPAC (SOPAC). Indlægget er imidlertid blevet fjernet sammen med bloggen i forbindelse med Herning Bibliotekernes relancering af deres website for et par år siden. Jeg fik fundet det frem igen via Archive.org. Selvom teksten i disse “Ting“-tider måske er ved at være lidt forældet, synes jeg dog stadig, indlægget indeholder relevante emner, især omkring bibliotekspersonalets redaktionelle roller ift. en kommende social OPAC. So here goes …


Vi kan lancere nok så mange weblogs og wiki’s, men hvis vi for alvor vil opgradere biblioteket til version 2.0, kommer vi næppe uden om OPAC’en. Vores OPACs trænger til gentænkning og ombygning, så de bliver mere tidssvarende og fremtidssikrede.

Indbygning i CMS med sociale lag

Det mest oplagte er at få hele biblioteksdatabasen bygget ind i et Content Management System (CMS), således at bibliografiske data kan håndteres som indhold på lige fod med temaartikler, sider med åbningstider og arrangementer. Men sådan et CMS kan også med fordel indeholde en række sociale funktioner. Jeg har tegnet en lille model. Modellen er sikkert ikke teknisk korrekt, for jeg er ikke tekniker, så jeg gennemgår den lige.

Model af Morten Brunbjerg Bechs forslag til den sociale OPAC (SOPAC)

Biblioteksdatabasen (orange):

Biblioteksdatabasen er det centrale omdrejningspunkt i vores CMS. Det er biblioteksbasen, brugerne i overvejende grad kommer på bibliotekets website for at bruge. Biblioteksbasen indeholder metadata om bibliotekets samling samt personhenførbare data om brugere. Disse metadata skal kunne bruges og genbruges ligesåvel som alt andet indhold i CMS’et.

Social software (blå):

Rundt om biblioteksdatabasen kunne man forestille sig et lag socialt software. Det er især her, vi finder de såkaldte web 2.0 funktioner. Her ligger den del af brugernes personlige profiler, der giver den enkelte bruger en række mere eller mindre sociale funktioner. En brugerprofil kunne f.eks. give brugeren mulighed for:

  • Lånerhistorik: Oversigt over tidligere hjemlån. Giver mulighed for at publicere dele af lånerhistorikken, så andre kan se den. F.eks. i tre publikationsniveauer:
    • Privat, hvor kun brugeren selv kan se oplysningerne om et lån.
    • Til venner og bekendte, hvor brugeren kan invitere specifikke personer til at se oplysninger om et lån.
    • Offentlig, hvor brugeren kan dele oplysninger om et lån med hvem som helst.
  • Huskeliste: En personlig liste, hvor brugeren kan gemme oplysninger om bibliografiske poster, vedkommende f.eks. ønsker at låne senere. Huskelisten kan f.eks. deles i tre publikationsniveauer som lånerhistorikken.
  • Kommentarer: Mulighed for at knytte kommentarer/ anmeldelser/ blog-indlæg til bibliografiske poster hvorsomhelst i biblioteksbasen. Mulighed for at knytte kommentarer til:
    • Oplysninger om et lån i den personlige lånerhistorik.
    • Oplysninger om et lån i andres offentlige lånerhistorik.
    • Oplysninger om en bibliografisk post i den personlige huskeliste.
    • Oplysninger om en bibliografisk post i andres offentlige huskeliste.
  • Tagging: Tildeling af tags (ukontrollerede emneord) til bibliografiske poster:
    • I den personlige lånerhistorik.
    • I den personlige huskeliste.
    • I en given søgning i biblioteksbasen.
  • Rating: Tildeling af karakter/vurdering, f.eks. vha. stjerner, til bibliografiske poster hvorsomhelst i biblioteksbasen, inkl. egen lånerhistorik og huskeliste.

Bibliotekets lånere har jo i pricippet i forvejen en lånerprofil, som overvejende indeholder personhenførbare oplysninger.

Man kunne imidlertid forestille sig, at brugeren selv skal oprette en profil med et givent nick/ kaldenavn, og først bagefter vælge at knytte sine låneroplysninger til denne profil.

Content Management System (grøn):

Det hele pakkes ind i et mere eller mindre traditionelt CMS, som dog skal kunne hive indhold frem fra et hvilket som helst sted i systemet. Man kunne således forestille sig, at man på forsiden af bibliotekets website kunne vise:

  • Brugernes seneste kommentarer.
  • Samlet tag-cloud (oversigt over tags) over alle brugeres tags.
  • Nye brugere
  • De højest vurderede bibliografiske poster.
  • Etc.

Dvs. man vil på bibliotekets øvrige websider således kunne trække på brugergenereret indhold, såvel som bibliografisk indhold på lige linie med redaktionelt produceret indhold (vises på modellen med de hvide linier).

At dele med eksterne sites
Samtidig kunne man forestille sig at dele indholdet med brugerne selv. Måske vil brugeren gerne publicere sin huskeliste på sin personlige weblog. For hver funktion i brugerens profil, kunne man altså give brugeren en lille stump javascript eller html kode, som vedkommende kan copy/paste ind i HTML’en på sin egen blog/website. F.eks.:

  • Brugerens offentliggjorte lånerhistorik.
  • Brugerens offentliggjorte huskeliste.
  • Brugerens tag-cloud.
  • Brugerens senest/højest/lavest vurderede bibliografiske poster.

Bibliotek 2.0 – en bottom-up tilgang

Skal bibliotek 2.0 tankegangen praktiseres, må vi have bibliotekspersonalet til at deltage på lige fod med brugerne (angivet i modellens blå område med “bibliotekarprofil”). Man kunne forestille sig, at de ansatte har en brugerprofil, præcis ligesom brugerne. En stor del af indholdet på bibliotekets hjemmeside ville således være oplagt at trække ind fra indholdet i de ansattes profiler.

Dermed kunne stadsbibliotekaren/ udviklingschefen/ musikbibliotekaren have en fast klumme på forsiden, hvor indholdet trækkes direkte fra kommentarerne i vedkommendes profil.

Det redaktionelle koncept kunne således langt hen ad vejen bestå i at sørge for, at hver enkelt ansat deltager med kommentarer, vurderinger, anmeldelser, tags osv.

En kommentar til “Forslag til en social OPAC – reloaded”

Skriv en kommentar