Catalis y OpacMarc

Herramientas open source para gestionar catálogos basados en MARC 21 y AACR2

<note>Esta es una versión preliminar de la presentación. La versión final está siendo armada off-line, trabajando directamente sobre HTML con S5</note>

La reunión es: Quién es quién 2008, el jueves 4 de diciembre, en Córdoba.

Estará presente Marshall Breeding, de visita en Córdoba en el marco de un proyecto de ABUC auspiciado por la Comisión Fulbright.

El tiempo asignado es de 45 min, pero parte de ese tiempo será utilizado para traducirle la charla a M. Breeding, por lo que hay que planificarla para unos 30 min.

Hacer una versión en inglés para M. Breeding.

• OJO: no se puede tratar de contarlo todo. La limitación de tiempo, y un mínimo de sentido común, aconsejan que destaquemos los aspectos más importantes, y sacrifiquemos el resto. Podemos acompañar la presentación con un “folleto” donde aparezcan detalles que no pudieron ser incluidos en la presentación.

• No caer en una fría enumeración de datos; incoporar algún elemento emotivo, que comunique entusiasmo, etc.
  • seleccionar los ejemplos a mostrar de manera que despierten algún interés
  • ¿hacer algunas preguntas iniciales a la audiencia?
  • ¿alguna anécdota?

• Tips para buenas presentaciones: PowerPoint and Presentation Tips

• Podemos considerar que se trata de dos presentaciones —una por cada software— aunque haya elementos comunes. De esta manera, podremos reutilizar el material para futuras presentaciones de cada software por separado.

• El plugin s5 para Dokuwiki es muy cómodo para ir preparando la presentación y dejarla online, pero para llevarla a Córdoba sería mejor convertirla a S5 puro, para no depender de la conexión con el wiki. Para ver otros temas: Pre-configured Theme Gallery.

• Motivación y contexto
• INMABB, Conicet, Universidad Nacional del Sur (UNS)
• Open source, licencia MIT
• Gente

• comentar la motivación y el contexto que llevaron a desarrollar ambas aplicaciones
  • adopción de estándares internacionales: MARC 21, AACR2
  • falta de herramientas adecuadas a nuestras necesidades y posibilidades económicas
  • ganas de hacer las aplicaciones que me gustaría usar (como catalogador y como usuario de bibliotecas)
  • diseñar e implementar estos softwares debía ser un trabajo divertido!

• como resultado del uso de estándares (sólo por eso?), el impacto llegó mucho más allá del ambiente local

• contexto institucional: INMABB, Conicet; vinculación con la BC de la UNS

• gente que ha colaborado: Luis Herrera, el equipo de sistemas de la Bib Central de la UNS, Raúl Escandar (Buenos Aires), Claudia Boeris (La Plata), Rubén Mansilla (Tandil)

Mejor dejar esta imagen para mostrar específicamente la pantalla de edición. Aquí podemos hacer una composición de varias capturas en miniatura.

Comenzaba el siglo XXI y en la UNS queríamos un software que nos facilitara el trabajo con registros MARC, que pudiera usarse en la Web, …

Creo que no tengo nada interesante para contar aquí. A diferencia del OPAC, no hubo lecturas o modelos que sirvieran de inspiración. Una motivación importante fue: quiero hacer una herramienta con la que a mí me guste catalogar.

• 2000: proto-proto-prototipo
• 2002: primer prototipo (luego abandonado)
• 2003: comienza a utilizarse en la UNS
• 2004: sitio web, (con demo online); uso a escala nacional (formación de catalogadores)
• 2005: lanzamiento público (versión 2005.06.09); wiki, grupo de discusión
• 2007: rediseño (lado del cliente); control de versiones (Sourceforge); CaMPI
• 2008: rediseño (lado del servidor); hosting en Google Code

• CDS/ISIS: wxis (wwwisis), utilitarios cisis
• Lenguajes: JavaScript, IsisScript
• Document Object Model (DOM)
• Cliente: Internet Explorer

• Rediseño: wxis, Python, Ext JS; cross-browser

Catalis hace un uso intenso de JavaScript; para la comunicación con el servidor usa iframe ocultos —una versión primitiva de Ajax (término acuñado en 2005)—, para hacer que una aplicación web se comporte más como una aplicación de escritorio.

• Base de datos: registros bibliográficos + holdings
• Interfaz

¿Cuáles serían las principales decisiones de diseño?

• Arquitectura: aplicación web
• Estructura de bases de datos
• Interfaz de edición: visualmente agradable, “cercana” a AACR2
• …

• plantillas
• puntuación automática
• control sobre los indicadores
• acceso a documentación sobre MARC 21
• edición en “modo experto”
• anotaciones del catalogador
• display de un registro bibliográfico en varios estilos
• corrección automática de registros importados
• . . .

Más detalles en el sitio web de Catalis

Para cada característica mencionada, podemos mostrar una imagen que la ilustre, o bien mostrarla en acción en Catalis.

• instalación manual
• gestión de bases y usuarios
• mantenimiento

La instalación debe ser simplificada, siguiendo un esquema similar al que recientemente (2008) aplicamos a OpacMarc.

Para agregar una base, un usuario, y establecer los permisos con que los usuarios acceden a cada base, se requiere acceso a la consola de comandos. En la próxima versión estas tareas administrativas se podrán realizar desde el navegador.

Mantenimiento: principalmente, compactación periódica de las bases y regeneración de archivo invertido en caso de modificaciones en la FST.

• Wiki

• Catalis en Google Groups, ~200 miembros a fines de 2008.

El soporte “oficial” se realiza principalmente a través del grupo de discusión.

Alentamos permanentemente a que las consultas y discusiones se realicen públicamente a través de ese recurso, y no a través de emails personales.

Nuevas herramientas:

• Ext JS: framework de JavaScript orientado a objetos
• Django: framework de Python para desarrollo web

Nuevas funcionalidades:

• Acceso simultáneo a múltiples bases
• Historial de búsquedas
• I18n (interfaz multilingüe)
• Búsqueda por campos

Luego de realizado el lanzamiento en 2005, y a medida que pensábamos en cómo superar algunas limitaciones y añadir nueva funcionalidad, fue quedando claro que era necesario rediseñar Catalis, y un paso importante en esta dirección era la adopción de frameworks para desarrollo web populares. Esto —si bien vendría acompañado por una importante curva de aprendizaje inicial— debería dar sus frutos, entre ellos:

• programar “cosas complicadas” resultará más sencillo, pues otros ya han resuelto esos problemas antes
• Catalis podrá ser más fácilmente estudiado, comprendido y eventualmente modificado por otras personas

Si podemos instalar la nueva versión, la mostramos en acción. Si no, capturas de pantalla.

Catalis 2005.06.09 no incluye un mecanismo para control de autoridad.

Caminos a seguir:

• Trabajar sobre Catalis 2005.06.09 para desarrollar esa funcionalidad extra
• Desarrollar la funcionalidad para la segunda versión de Catalis

En la Biblioteca Central de la UNS se está desarrollando una adaptación de Catalis 2005.06.09 para gestionar registros de autoridad.

• Completar la implementación de las funcionalidades originales en la nueva versión (Django + Ext JS)
• Control de autoridades
• Validaciones

… ¿para qué era que queríamos crear|importar|editar|corregir tantos registros MARC?

Obvia necesidad de contar con mejores OPACs

• cumplimiento de los objetivos del catálogo
• integración con el entorno tecnológico
• mayor aprovechamiento de los registros AACR2/MARC 21
• el OPAC como herramienta didáctica

Los OPACs suelen —o solían, allá por 2003— estar lejos de ser lo que debieran ser, en varios sentidos.

• necesidad de mejorar la funcionalidad de los OPACs
  • que se acerque más a la meta (ideal?) de cumplir con los objetivos del catálogo (que son, al menos en principio, independientes de la tecnología)
  • que haga mejor uso de las posibilidades de la tecnología disponible; mejor integración con el entorno/ecosistema tecnológico (hoy en día, la Web)

Aquí podemos hacer una referencia a un artículo de Breeding, Web 2.0? Let's get to Web 1.0 first, y hacer una analogía con: ¿OPAC 2.0? Sí, pero también hagamos que sea realmente un Catálogo

• necesidad de un OPAC que permita aprovechar la riqueza existente en registros AACR2/MARC 21. El esfuerzo invertido por catalogadores en aprender el uso de estándares (reglas, formatos) y herramientas de software no se ve plenamente traducido en catálogos de alta calidad.

• un buen OPAC debe poder ser utilizado como herramienta didáctica que ayude a enseñar conceptos de catalogación; la motivación que subyace tras ciertas reglas o convenciones del formato MARC, se debería poder comunicar viendo los efectos de su uso (o su no uso) en un catálogo concreto.

[In this book] we make many recommendations for how OPACs could do a better job of passing on to the users the benefits of the expensive intellectual effort that goes into creating catalog records.

—Martha M. Yee, Sara Shatford Layne (1998), Improving online public access catalogs

Traducción aproximada:

En este libro presentamos numerosas recomendaciones sobre cómo los OPACs podrían transmitir mejor a los usuarios los beneficios del costoso esfuerzo intelectual que se invierte en crear registros catalográficos.

• Martha M. Yee (2002), Principles for the display of cataloger-created metadata

• Martha M. Yee (2005), FRBRization: A Method for Turning Online Public Finding Lists into Online Public Catalogs

There was a time when we as cataloguers were concerned with building catalogues. Now we seem primarily to be concerned with creating bibliographic records, leaving catalogue construction to others.

—J. McRee Elrod. Cataloguer's role in catalogue construction - A Modest Proposal

Traducción:

“Hubo un tiempo en el que nosotros como catalogadores nos ocupábamos de construir catálogos. Ahora parecemos ocuparnos principalmente de crear registros bibliográficos, dejando la construcción de catálogos a otros.”

Este texto de J. McRee Elrod —frecuente participante en listas de discusión de catalogadores, como AUTOCAT y RDA— fue uno de los primeros en hacerme notar que algo andaba seriamente mal. O los catalogadores estaban empezando a olvidar o dejar a un lado el impulso por producir catálogos de calidad, o bien estaba fallando mucho la comunicación entre catalogadores e informáticos.

• 2003: prototipo
• 2004-2005: exposición pública mediante bases de prueba
• 2006: inauguración del catálogo del INMABB; release 2006.11.13
• 2007: CaMPI
• 2008: inauguración del catálogo de la Biblioteca Rivadavia; control de versiones; hosting en Google Code

Tenemos una slide con browse source en Google Code.

• CDS/ISIS: wxis (wwwisis), utilitarios cisis
• Lenguajes: IsisScript, Python
• agrep (coincidencias aproximadas)
• servidor web (Apache)
• HTML & CSS válidos

Python está siendo usado (desde 2008) para los scripts de administración. Multiplataforma, facilita el mantenimiento de los scripts.

agrep: permite encontrar “coincidencias aproximadas”, es decir, obtener a partir de una lista aquellos términos “cercanos” a un término dado.

Apache: se podría usar otro servidor web, pero OpacMarc trae “gratis” una configuración para Apache.

HTML & CSS: está pendiente lograr una buena separación de capas, es decir, no incluir CSS dentro del código HTML.

Decisiones en tres áreas (Yee & Layne, 1998):

1. estructura de archivos e índices
2. indización
3. visualización (display)

Principales decisiones tomadas al diseñar el sistema. Siguiendo a Yee & Layne, las decisiones se pueden organizar en tres grupos:

• File and index structure decisions (estructura de archivos e índices): cómo particionamos la(s) base(s)de datos (explicar mejor esto).

• Indexing decisions (indización): qué hacemos para maximizar la posibilidad de que los términos ingresados por un usuario coincidan (match) con los utilizados en los registros. Esto incluye el tipo de búsqueda predeterminada, y la compensación de errores y variaciones.

• Display decisions (visualización): qué mostrar al usuario, y cómo mostrarlo. Esto incluye qué tipo de registros presentar (bibliográficos, encabezamientos), cómo organizar de manera efectiva el display de un conjunto de registros bibliográficos, y cómo presentar un registro bibliográfico individual.

Las decisiones sobre display están tan asociadas a lo que el usuario experimenta más directamente, que tal vez las ponemos en el ítem “Características”.

1. Estructura de archivos e índices

• biblio: base bibliográfica
• bases auxiliares (“índices”):
  • name: nombres (personas, entidades corporativas)
  • subj: temas (descriptores, encabezamientos de materia)
  • title: títulos (controlados y sin controlar)
• esquema de clasificación (opcional)

Ilustrar con un diagrama

2. Indización

• tipos de búsqueda
  • keyword match (“contiene las palabras…”)
    • en registros bibliográficos
    • en encabezamientos
  • index browse (“comienza con…”)
    • encabezamientos
    • títulos
  • heading match
    • en registros bibliográficos (implícitamente)

• estructura de índices (FST??)

Cada uno de los dos primeros tipos da lugar a un formulario (similar a NCSU).

El tercero se usa en forma implícita, cuando el usuario sigue un enlace desde un encabezamiento.

3. Display

• display de un conjunto de encabezamientos
• display de un conjunto de registros bibliográficos
• display de un registro bibliográfico individual
• display cuando no hay resultados

Comentar e ilustrar. Se requieren varias slides. Ver las usadas en la presentación de 2006.

Por qué es mejor presentar encabezamientos en lugar de registros bibliográficos.

Displays que nos gustaría lograr: obras asociadas a una persona, organizadas según función.

• AACR2/MARC
  • uso de encabezamientos para reunir registros
  • referencias
  • indicadores para ordenación de títulos

Búsquedas por tema

• uso de esquemas de clasificación (MSC 2000)
• navegación por signatura topográfica

• usabilidad (hagámosle las cosas fáciles al usuario; toleremos errores y variaciones; Ranganathan's 4th law: “Save the time of the Reader”)
  • limpieza de la consulta: puntuación (caso especial: apóstrofos), espacios sobrantes. “take a very liberal approach to normalization”–Yee & Layne
  • generación de sugerencias, corrección de errores (“did you mean…”)

• posibilidad de encontrar registros en base a condiciones “complejas” (el “usuario final” puede ser también un bibliotecario, o un docente/alumno de bibliotecología). ¿Mostrar cómo se indiza un registro específico? SI, buena idea — Claudia 2008/11/25 12:41

Mostrar información acerca del catálogo

• contenido del catálogo
• fecha de la última actualización

• permalinks
• reordenamiento
• truncamiento (explícito en search, implícito en browse)
• enlaces externos
• navegabilidad

Enlace externos: no sólo con campos 856, e.g. vista previa con Google Book Search

Navegabilidad: abundancia de links internos; registros relacionados; visibilidad en buscadores MOSTRAR EJEMPLO CON GOOGLE

• Cambio de tamaño del texto

• Acceso desde navegadores “limitados”. Ejemplo:

<html><div style=“height: 1em;”></div></html>

      links http://inmabb.criba.edu.ar/catalogo/

Para demostrar que el OPAC es accesible mediante un navegador de texto, usamos una secuencia de 4 slides:

1. comando: links http://inmabb.criba.edu.ar/catalogo/ (en una consola de 80 x 25)
2. pantalla inicial, con término de búsqueda (con error)
3. pantalla con sugerencias
4. pantalla con lista de resultados asociados al término sugerido

Otra alternativa —no para esta charla– es usar un emulador de browser de celular, p.ej. http://mtld.mobi/emulator.php o http://www.operamini.com/demo/ (requieren Java en el navegador). En estos casos, se trata de navegadores gráficos, pero con una limitación importante en el ancho de página; no sé cómo se comportan con respecto al uso de JavaScript. Ver también MobiLIB (NCSU).

• instalación: install.py
• la estructura de 3 niveles
  • conveniencia de separar los datos locales
  • una instalación, múltiples catálogos
• administración
  • add_db.py
  • update_db.py
• configuración
• “customización”: css, imágenes, html, etc.

install.py: explicar qué hace

estructura en 3 niveles: ilustrar con diagrama

update_db.py: explicar input y output

Destinatarios:

• desarrollador: wiki
• administrador/bibliotecario: wiki
• usuario final: IB

La documentación se encuentra atrasada. Varios documentos se encuentran en un área de acceso restringido dentro del wiki; hay que revisarlas y llevarlas al área pública.

• arreglo de bugs
• ampliar la documentación
• desarrollo de nuevas características: subcatálogos virtuales, mejor uso de registros de autoridad
• herramienta para análisis de logs
• control más fino de la configuración

• cambio de tecnología: Python/Django, Ajax
• i18n
• aprender de otros OPACs open source, e.g. VuFind, FacBackOPAC, Koha
• prepararse para lo que viene: RDA?

Para más información:

• http://catalis.uns.edu.ar
• http://opacmarc.googlecode.com/

Para la demostración, deberíamos usar una instalación de OpacMarc con al menos dos catálogos: el de INMABB y el del Museo Mitre. Quizás también el de la Biblioteca Rivadavia. ¿Y la base demo? (ATENCION: necesitamos una base demo mejorada, para poder mostrar las referencias).

Lo presentamos ya armado, pues el tiempo no dará para mostrar cómo se lleva a cabo el proceso.

Sería bueno que para el momento de la reunión tengamos un build en buenas condiciones, en la sección Downloads de Google Code.

También deberíamos llevar a la sección pública del wiki varios documentos que están en la sección Notas (de acceso restringido).

Leer lo que ha publicado recientemente Breeding sobre las nuevas interfaces de búsqueda para bibliotecas en su columna Systems Librarian:

• Mayo 2008: Beyond the current generation of next-generation library interfaces: deeper search
• Oct. 2007: The Birth of a New Generation of Library Interfaces
• Mayo 2007: We Need to Go Beyond Web 2.0
• Abril 2007: Thinking About Your Next OPAC

catalis opacmarc presentacion