sopac : connecting koha and drupal

SOPAC : connecting Drupal and Koha ELAG, April 2009 Nicolas Morin [email_address]

BibLibre

we provide support for OSS in libraries

we develop & provide support for the OSS ILS KOHA (since 2002)

we provide support for the OSS CMS DRUPAL (just started)

=> SOPAC is a set of tools that connects your ILS (Millenium initially) with a Drupal site

Small project : objectives

providing the SOPAC connector for Koha

on Koha : creating the set of WS required to make SOPAC work

SOPAC is the work of the ubiquitous John Blyberg. What is the Social OPAC (SOPAC)?

http://aadl.org

http://www.darienlibrary.org

http://thesocialopac.net

http://www.blyberg.net/

http://www.flickr.com/photos/trucolorsfly/

What does SOPAC try to achieve?

#1 perfect graphical integration between the catalog UI and the library's Drupal web site

#2 add « social » functionalities to the OPAC:

tags

reviews

ratings

rss

=> SOPAC replaces and enhances your OPAC

What it looks like at Darien

Patron creates account

What it looks like at Darien

How does it work?

SOPAC harvests the records from the ILS through a connector

reindexes them in a separate engine

provides a new UI in Drupal for searching & actions (tags, holds...)

requires real time connectors for :

Some informations such as item availability

Some actions such as placing a hold

SOPAC Architecture ILS ws ILS connector MySQL LOCUM sphinx SOPAC (php + add. Tables to Drupal's MySQL) Independent Social Repository Drupal UI INSURGE

The Koha Connector

we used the ILS Discovery Interfaces recommandation as a set of guidelines to develop KOHA WS

-> http://diglib.org/architectures/ilsdi/

It provides for :

harvesting of records : done through OAI-PMH server

The Koha Connector

It provides for :

real-time search : not used by Sopac

The Koha Connector

It provides for :

delivery (holds, availibility, etc) : done through new API in Koha

The Koha Connector

It provides for :

patron information : done through new API

Issues with the connector

Locum expects certain things, ILS-DI recommends something else

locum uses patron barcode

ils-di expects not a barcode, but a user_id

-> way around : translate barcode into user_id on the fly : performance issues.

-> way forward : sopac uses user_id

Issues with ils-di

ILS-DI often recommends SIP or NCIP as a way to provide WS. It doesn't work:

many of the stuff we want doesn't exist in SIP

SIP is not really extendable

if you're going to have to do new WS, why bother with SIP at all : you'd rather have a homogenous set of APIs.

Issues with ils-di

ILS-DI doesn't say much about the expected quality of the response.

-> adoption of ILS-DI will probably take time

-> compliance will mean different things

Issues with SOPAC

a lot of stuff is hardcoded : MARC21 in harvesting function (scrape_bib); item types, question to link accounts, locum configuration...

patron has 2 accounts : sopac / ils -> cries out for some sort of ldap solution...

Issues with SOPAC

if you replace your OPAC, you have to have at least the functionalities that your opac provides. For Koha, issues with :

patron's account editing (phone, etc.)

record level holds

zotero (COinS) integration

...

-> SOPAC needs time to mature

general questions raised Sopac hints at erasing the limit between local data and outside data (Insurge):

we need volumes of data for social functionalities

maybe we need volumes of data for searching too, even in small libraries (OCLC Grid Services; GBS...)

Independent Social Repository INSURGE

general questions raised

Sopac knows very little about the user :

can one do social stuff without informations about who the persons are?

Shouldn't a result be relevant to someone?

-> we have to know what the students want

-> we also have to know who they are :

- major in computer science

- minor in philosophy

- has courses in building A, next to library B on thursdays

general questions raised

Sopac separates backoffice from UI, but we could go one step further and better separate searching tools and visualization -> every single result is displayed the same, but should not :