Recomendaciones para enseñar OPACs

Hace unos días, en la lista CODE4LIB, un profesor de LIS (Library & Information Science) en la universidad de Illinois pedía opinión sobre el enfoque y contenido de una asignatura semestral, que orientaba a enseñar OPACs. Dividía la planificación en siete sesiones que cubrían desde la instalación de un servidor básico, hasta la instalación de un OPAC y varias tareas de personalización y ajuste.

En primer lugar, lo destacable es que no se entretenía en enseñar a usar un OPAC, algo normal para usuarios pardillos, pero completamente superado en titulaciones LIS. El enfoque era que los estudiantes implementasen un OPAC desde cero, para que conociesen los problemas y requerimientos técnicos, y que luego probasen diferentes aspectos de configuración y personalización. Desde luego, innecesario catalogar: para eso se importan directamente registros MARC o MARC/XML, y ya se tiene la base de prueba. De las diferentes aportaciones al debate, me voy a permitir extraer una serie de cuestiones que considero especialmente reseñables, algunas en notas y otras traducciones directas. El que quiera acudir a las fuentes originales, puede verlos en el archivo de la lista.

La primera cuestión clave es que todos los participantes coincidían en usar software libre. Para ello proponían el uso tanto sistemas completos, como Koha, como de herramientas de capa de OPAC avanzado, como son VuFind o Blacklight. También se planteó la posible utilización de herramientas como Omeka, aunque no resulta ser exactamente un OPAC, y se indicaba su interés como herramienta de aprendizaje de construcción de repositorios. La discusión derivaba, además, hacia otros aspectos técnicos, como la instalación de una instancia única de la aplicación, o la instalación de instancias individualizadas para cada estudiante. También se plateaba la utilización, en entornos menos flexibles, de las instancias o máquinas virtuales que ofrece Koha.

Copio una reflexión sobre lo que es/hace un OPAC (las negritas son mías):

«What makes the OPAC special isn’t the technologies it employs, but rather the workflows and data it supports because these come straight out of the physical world and tools used decades ago. Aside from that, library automation is still heavily influenced by technologies developed when memory was measured in kilobytes rather than gigabytes. Discovery gets the lion’s share of attention, but when you get right down to it, what people call an OPAC is only the public facing side of a specialized inventory control system that supports a wide range of functions. People need to learn the new stuff, but a huge part of grokking the OPAC is the old stuff — otherwise, people simply arrive at the conclusion that the data/methods are stupid or irrelevant and they miss the main point.» (Kyle Barnejee).

No me resisto a copiar esta otra  reflexión que podríamos usar igualmente en España:

«I used to run this Koha on server space that I had arranged with the university, they hosted a box that I had root access to. Recently a new director declared that this was a rogue server and threw it out. The obvious reply is that, in theory, as an LIS prof these days you have to be very adaptable to technology changes, and you got to have the capability to roll out such technology, as I do with Omeka, Drupal, Koha. In practice, not a lot of technology is taught/used in the LIS curriculum. But that’s a topic for another day.» (Thomas Krichel).

Algún participante señalaba jocosamente que ojalá le hubiesen enseñado algo así cuando estudió, en lugar de enseñarle DIALOG 😉