Informe Koha

Informe de evaluación del sistema
integrado de gestión de bibliotecas
Koha para las Bibliotecas de la
Administración General del Estado

Grupo de Trabajo de Catálogo Colectivo de las Bibliotecas de la
Administración General del Estado

Fecha: 27/09/2010

Coordinador del Grupo de Trabajo
Domingo Arroyo Fernández, Subdirección General de Coordinación Bibliotecaria, M. Cultura
Asesora
Alicia Sellés Carót, MasMedios

Miembros del Grupo de Trabajo
Biblioteca Nacional
José Ramón García Amo
Jefe de la Unidad de Coordinación Informática
Marina Jiménez
Jefa de Área de Automatización y Organización
Ministerio de Asuntos Exteriores y Cooperación
María Begoña Ibáñez Ortega
Jefa de Área de Documentación y Publicaciones
Ricardo Perera Manzanedo
Ministerio de Cultura
Elena García Bracamonte
Jefa de Servicio del Centro de Documentación Cultural
Begoña Ricote Ricote
Subdirección General de Coordinación Bibliotecaria
Ministerio de Defensa
Margarita García Moreno
Jefa de la Unidad de Coordinación Bibliotecaria
Ministerio de Economía y Hacienda
María Luisa Martínez Soro
Jefa del Servicio de Biblioteca Central
Agustín Torreblanca López
Consejero Técnico responsable de Archivo y Biblioteca
Ministerio de Educación
Ernesto Calbet Roselló
Jefe de Área de Documentación y Biblioteca
Ministerio de Fomento
María Concepción Sanz Bombín
Directora del Centro de Documentación del Transporte
Ministerio de Igualdad
Mª Teresa Escalada Buitrón Consejera Técnica de la Subdirección General de Cooperación y
Relaciones Institucionales
Ministerio de Interior
Juan Antonio Narváez Gómez
Jefe del Servicio de la Biblioteca Central del Ministerio
María Rosa Martín de Vega
Jefe de Área de Estudios, Documentación y Publicaciones
Ministerio de Justicia
Carmen Sañudo Sánchez-Garnica
Subdirectora General de Documentación y Publicaciones
Ministerio de Medio Ambiente y Medio Rural y Marino
Carmen Casal Fornos
Jefe de Área de Documentación
Ministerio de Política Territorial
Luis Ángel García Melero
Jefe de Servicio de Biblioteca

Ministerio de Presidencia
Juan José Álvarez Galán
Jefe de Área
Silvia Fuentes
Jefa de Servicio de Bibliotecas
Ministerio de Trabajo e Inmigración
María Luisa Martínez Lázaro
Consejera Técnica responsable de Bibliotecas del Departamento
María José Moreno de Frutos
Jefa de Servicio de la Subdirección General de Proceso de Datos
Ministerio de la Vivienda
Jaime Peón Pérez, Subdirector adjunto de la Subdirección General de Cooperación y
Relaciones Interadministrativas

1 Introducción .........................................................................................................8
1.1 Marco y aspectos previos ..............................................................................9
1.1.1 Punto de partida........................................................................................................... 9
1.1.2 Inicio del Proyecto...................................................................................................... 11
1.2 Objetivos........................................................................................................12
1.3 Metodología y desarrollo del proyecto........................................................12
1.3.1 Equipo ........................................................................................................................ 12
1.3.2 Metodología y fases ................................................................................................... 12
1.3.3 Estructura del informe y resultados............................................................................ 14

2 Koha: Sistema de Gestión Integrada de Bibliotecas en Fuentes
Abiertas…................................................................................................................16
2.1 Descripción y características generales .....................................................17
2.1.1 Descripción ................................................................................................................ 17
2.1.2 Características generales .......................................................................................... 17
Diseño Dual de Base de Datos ...................................................................................................... 18
Interfaces Web................................................................................................................................ 18
Fuentes Abiertas .............................................................................. ¡Error! Marcador no definido.
2.2 Comunidad Koha, desarrollo en Fuentes Abiertas ....................................18
2.3 Funcionalidades principales ........................................................................20
2.3.1 Administración............................................................................................................ 20
2.3.2 Catalogación y autoridades........................................................................................ 21
2.3.3 Circulación ................................................................................................................. 21
2.3.4 Publicaciones periódicas............................................................................................ 21
2.3.5 Adquisiciones ............................................................................................................. 22
2.3.6 Estadísticas................................................................................................................ 22
2.3.7 Catálogo (buscar)....................................................................................................... 23
2.3.8 Herramientas.............................................................................................................. 23
2.3.9 OPAC (Interfaz público) ............................................................................................. 24

3 Koha en las BAGE..........................................................................................25
3.1 Análisis detallado..........................................................................................26
3.1.1 Aspectos generales.................................................................................................... 28
A.G. 1 Entorno de trabajo............................................................................................................... 28

A.G.2 Traducción............................................................................................................................ 28
A.G.3 Creación de dominios, independencia de las bibliotecas .................................................... 29
A.G.4 Diseño Web.......................................................................................................................... 30
A.G.5 Multilingüismo....................................................................................................................... 31
A.G.6 Actualizaciones, versiones y desarrollo ............................................................................... 32
A.G.7 Migración .............................................................................................................................. 33
3.1.2 Aspectos informáticos ................................................................................................ 34
A.I.1 Conectividad, accesos, puertos ............................................................................................. 34
A.I.2 Navegadores.......................................................................................................................... 35
A.I.3 Arquitectura tecnológica......................................................................................................... 36
A.I.4 Seguridad informática ............................................................................................................ 36
A.I.5 Mejora del rendimiento en las búsquedas (modo perl).......................................................... 37
A.I.6 Contraseñas/ gestión de usuarios ......................................................................................... 39
3.1.3 Aspectos técnicos ...................................................................................................... 40
A.T.1 Familia MARC21.................................................................................................................. 40
A.T.2 Formatos MARC ................................................................................................................... 41
A.T.3 Búsquedas federadas ........................................................................................................... 41
A.T.4 Repositorio/gestión de objetos digitales ............................................................................... 42
A.T.5 Búsquedas Z.39.50............................................................................................................... 43
A.T.6 NCIP...................................................................................................................................... 45
A.T.7 OAI-PMH............................................................................................................................... 46
3.1.4 Administración............................................................................................................ 48
A.A.1 Configuración de la moneda................................................................................................. 48
A.A.2 Parametrización básica ........................................................................................................ 49
A.A.3 Informe.................................................................................................................................. 49
3.1.5 OPAC ..........................................................................¡Error! Marcador no definido.8
OP.1 Modificar Ficha ...................................................................................................................... 50
OP.2 Elementos de navegación ..................................................................................................... 51
OP.3 Navegación por materias ...................................................................................................... 52
OP.4 Formatos de exportación de registros................................................................................... 53
OP.5 Configuración de buscadores ............................................................................................... 54
OP.6 Funcionalidades en la Home en OPAC ................................................................................ 57
OP.7 Inclusión desarrollos Bibliotecas de Galicia .......................................................................... 58
3.1.6 Circulación ................................................................................................................. 59
CI.1 Reservas ................................................................................................................................. 59
CI.2 Historial de préstamo .............................................................................................................. 60
CI.3 Préstamo interbibliotecario ..................................................................................................... 61
3.1.7 Catalogación .............................................................................................................. 61

Cat.1 Mejoras en la edición de registros MARC ............................................................................ 61
3.1.8 Autoridades ................................................................................................................ 63
Aut.1 Gestión de tesauros .............................................................................................................. 63
Aut.2 Autoridades multilingües ....................................................................................................... 63
3.1.9 Adquisiciones ............................................................................................................. 64
Ad: 1 Gestión de Monedas ............................................................................................................. 64
Ad.: 2 integración con herramientas de gestión de compras ......................................................... 65
Ad.: 3 Historial de compras ............................................................................................................ 66
Ad.: 4 Integración Seriadas/Adquisiciones..................................................................................... 66
3.1.10 Publicaciones periódicas.......................................................................................... 67
P.P.1 Suscripciones: control de ejemplares................................................................................... 67
P.P.2 Descripción de suscripciones ............................................................................................... 68
P.P.3 Recepción en lote ................................................................................................................. 68
3.2 Resumen e identificación de requisitos......................................................69

4 Definición del desarrollo..................................................................................78
4.1 Características generales del proyecto.......................................................79
4.1.1 Marco general ............................................................................................................ 79
4.1.1.1 Objetivos ...................................................................................................................... 79
4.1.1.2 Características principales ........................................................................................... 80
4.1.2 Fases ......................................................................................................................... 81
4.1.3 Equipo de trabajo ....................................................................................................... 83
4.2 Definición y especificaciones ......................................................................84
4.2.1.1 Desarrollo Koha ........................................................................................................... 84
4.2.1.2 Desarrollo y personalización BAGE............................................................................. 86
4.2.1.3 Valor añadido .............................................................................................................. 87
4.2.2 Implantación (proyecto piloto) .................................................................................... 88
4.2.3 Evaluación y definición del servicio............................................................................ 88

5 Valoración.........................................................................................................90
5.1 Valoración......................................................................................................91
5.2 Ejecución .......................................................................................................92
5.2.1 FASE 1 Desarrollo inicial ........................................................................................... 93
5.2.2 FASE 2 Mejora........................................................................................................... 94
5.2.3 FASE 3 Valor Añadido y consolidación del servicio................................................... 94

Evaluación de Koha para las bibliotecas de la Administración General del Estado
Introducción

1.1 Marco y aspectos previos
El objetivo de este informe es presentar la propuesta del desarrollo de un Sistema
Integrado de Gestión de Bibliotecas (SIGB) a partir de alguna de las soluciones de
código abierto con el fin de ponerlo a disposición de las Bibliotecas de la Administración
General del Estado (BAGEs) que lo requieran. Este SIGB dispondrá, junto con todas las
utilidades para automatizar las distintas tareas de la biblioteca, de los requisitos
técnicos y normativos para alimentar con sus registros el Catálogo Colectivo de las
BAGEs o punto único de consulta único establecido en el Art. 1.2 b) del Real Decreto
1572/2007, por el que se regulan los órganos de coordinación de las bibliotecas de la
Administración General del Estado y de sus organismos públicos.

1.1.1 Punto de partida

El proyecto tiene como objetivo general la evaluación y el desarrollo de un Sistema Integrado
de Gestión de Bibliotecas (SIGB) y viene motivado por una serie de aspectos y trabajos
previos, entre los que destacamos:

o El artículo 1.2 b) del Real Decreto 1572/2007 por el que se regulan los órganos de
coordinación de las bibliotecas de la Administración General del Estado y de sus
organismos públicos, que establece como objetivo de los mismos “Promover el
establecimiento de un punto de consulta único que, mediante un catálogo colectivo o
sistema equivalente accesible electrónicamente, permita la consulta conjunta de las
colecciones de todas las bibliotecas de la Administración General del Estado y de sus
organismos públicos”.

o Encuesta sobre el Estado de la Automatización de las Bibliotecas de la Administración del
Estado, que ofrecen datos cuantitativos sobre la situación real.

Este SIGB, aparte de las utilidades comunes para automatizar las distintas tareas de la
biblioteca, dispondrá de aquellos requisitos técnicos y normativos necesarios para alimentar

Página 9

Introducción

con sus registros el Catálogo Colectivo de las BAGEs o punto único de consulta establecido en
el Art. 1.2 b) del Real Decreto 1572/2007.

Este proyecto se planteó siguiendo las normas europeas (European Interoperability Framework
for Pan-European Government Services) y nacionales (entre otros, la Ley 11/2007 de acceso
electrónico de los ciudadanos a los Servicios Públicos, R.D 4/2010 que regula el Esquema
Nacional de Interoperabilidad) que, entre otros objetivos, persiguen asegurar los niveles
apropiados de interoperabilidad entre sistemas. Conforme a estas normas el principal medio
para lograr este objetivo es el empleo de estándares abiertos, cuya implantación se consigue
en mayor grado mediante la utilización de software de fuentes abiertas.

Inicialmente se planteó que el desarrollo no fuera ad hoc, puesto que en la actualidad existen
SIGB de fuentes abiertas que han alcanzado un desarrollo comparable a los sistemas
comerciales, que se pueden utilizar -o al menos se pueden basar- en desarrollos concretos o
específicos pero que, ya per se, proporcionan soluciones a un porcentaje elevado de
necesidades de automatización.

Otros motivos para optar por una solución de fuentes abiertas para este proyecto son, entre
otros, que permite mantener el control del desarrollo del sistema, la capacidad que tiene este
método de desarrollo de software para favorecer la innovación colectiva y los beneficios que
aporta a la industria local de software.

Por tanto, el proyecto pasaba por la realización de un estudio comparativo de estos sistemas
para determinar cual se adecua a las necesidades de las BAGE en base a:

o La funcionalidad propia de la herramienta (soportada por la comunidad correspondiente);
o La posibilidad de utilizar otros desarrollos ya realizados por bibliotecas españolas;
o La complejidad e inversión a realizar en desarrollos propios para adecuar a las necesidades
concretas de las BAGE.
El objetivo final es que este software y el soporte necesario se proporcione a las BAGEs, que
bien por carecer de un SIGB operativo o por limitaciones del que tengan disponible, opten por
utilizarlo y conseguir el mayor grado de automatización posible para poder implantar, no sólo el
punto de consulta único y otros servicios avanzados al usuario, sino también posibilidades de
colaboración y racionalización de recursos.

Página 10

Introducción

1.1.2 Inicio del Proyecto

El Consejo General de Coordinación de las Bibliotecas de la AGE, cuya Secretaría
permanente es la Subdirección General de Coordinación Bibliotecaria del Ministerio de Cultura,
que lidera el proyecto, organizó el grupo de trabajo con representantes de todos los ministerios.
Para ello se puso en contacto con MASmedios con la intención de dotar al grupo de trabajo de
las herramientas y conocimientos para llevar a cabo la evaluación y revisión de soluciones
tecnológicas de código abierto, así como para estudiar la viabilidad y los esfuerzos necesarios
para adecuarlas a las necesidades que se vayan detectando durante el análisis.

Los estudios previos realizados sobre herramientas y aplicaciones de código abierto
han hecho que el grupo de trabajo centre los estudios en dos herramientas concretas:

 Koha (SIGB)

 eXtensible Catalog (punto de consulta único y objeto de otro informe y análisis)

El SIGB elegido para realizar el análisis detallado ha sido Koha, pues presenta ventajas
respecto a otras mencionadas y consideradas inicialmente, sobre todo en lo que se refiere a:

o Escalabilidad (numero de registro);
o Madurez del desarrollo (versiones, desarrolladores, funcionalidad…);
o Actividad en la comunidad;
o Implantación en España.

En este informe presentamos la metodología, características y resultados de este
análisis detallado.

Página 11

Introducción

1.2 Objetivos
Los objetivos planteados para el análisis de Koha y su implantación en las BAGE son:

 Disponer de una instalación de Koha para que el grupo de trabajo pueda evaluar las
herramientas y analizar las necesidades de las bibliotecas susceptibles de integrarse en
el proyecto;

 Contar con el asesoramiento técnico y ayuda al usuario en el uso de las herramientas
para determinar el grado de adaptación y cobertura de necesidades;

 Contar con el asesoramiento técnico de sistemas y desarrollo para conocer la viabilidad
de los desarrollos o evoluciones propuestas.

1.3 Metodología y desarrollo del proyecto

1.3.1 Equipo
 La Subdirección General de Coordinación Bibliotecaria del Ministerio de Cultura ha
coordinado el grupo de trabajo de evaluación de Koha, formado por técnicos y
representantes de Bibliotecas de la Administración General del Estado y técnicos de
MASmedios (bibliotecarios e informáticos).

1.3.2 Metodología y fases

El proyecto se concibió como un proyecto a medio plazo, puesto que una de las necesidades
era la evaluación por parte de los usuarios y miembros del grupo de trabajo. Las fases y tareas
realizadas para la revisión de Koha fueron:

FASE I - Preparación de la herramienta

Tarea 1. Instalación y configuración básica de Koha en servidores de MASmedios, con acceso
a los miembros del grupo de trabajo. Esta instalación básica contempla:
 Instalación y configuración

Página 12

Introducción

 Parametrización

 Publicación y puesta a punto

Tarea 2. Alojamiento y mantenimiento de sistemas. Durante un año, se proporcionará
alojamiento y mantenimiento de sistemas de los servidores en los que estarán alojadas las
aplicaciones.

FASE II - Análisis y revisión

Tarea 1. Presentación. Sesiones presencial de presentación y formación que posibilitaron a
los miembros del grupo la familiarización con las mismas para la ejecución de tareas y pruebas
sobre ellas. Se trató de iniciar en el manejo y características técnicas y de sistemas a los
miembros del grupo para que contaran con una visión más avanzada y se agilizaran los
trabajos de revisión y análisis.

En estas sesiones se establecieron módulos o tareas y los correspondientes responsables
(encargados) para su revisión detallada.

Tarea 2. Revisión: período de revisión. Los miembros del grupo de trabajo realizaron pruebas
y tareas sobre la herramienta. Se utilizaron las herramientas colaborativas del Ministerio para ir
compartiendo impresiones, dudas, necesidades, etc.

Tarea 3. Puesta en común y recopilación de datos. Sesiones presenciales de revisión en las
que los responsables de cada uno de los módulos expusieron sus dudas, sugerencias o
comentarios. El objetivo de estas sesiones fue compartir la información e intentar recoger el
mayor número de casos, situaciones, necesidades, etc.

Tarea 4. Soporte de usuarios. Ayuda y asesoramiento en la realización de las tareas que
necesite el grupo de trabajo.

FASE III. Revisión, propuestas y estudio de viabilidad

Tarea 1. Recopilación de datos y resumen de experiencias. Consiste en el análisis del
alcance y viabilidad de las necesidades y los requerimientos detectados por el grupo en el
periodo de revisión, así como de la identificación de requisitos tras las sesiones de evaluación.

Página 13

Introducción

Tarea 2. Propuestas e informe técnico. El grupo de trabajo tiene como objetivo realizar un
análisis del sistema para determinar cuál se adecua a las necesidades, y qué desarrollos son
necesarios.

1.3.3 Estructura del informe y resultados

El informe se presenta con la siguiente estructura:
1. Introducción: marco general e introductorio para la justificación y presentación del
trabajo realizado.
2. Koha: información general de la herramienta y las características más destacadas en
cuanto a requisitos técnicos, desarrollos, funcionalidades, comunidad, etc.
3. Análisis detallado, donde se recogen todas las cuestiones que se plantearon en las
sesiones de formación/presentación y las que el equipo de trabajo redactó y compartió
en la plataforma colaborativa SedesBAGE. Muchas de estas cuestiones no se
encuentran ni en la definición de requisitos ni en las estimaciones por ser necesidades
muy concretas, Bugs y/o problemas de uso con la herramienta que han ido surgiendo.
Todas estas cuestiones se estructuran en torno a los siguientes puntos:

 Aspectos generales AG

 Aspectos informáticos AI

 Aspectos técnicos AT

 Administración AA

 OPAC OP

 Circulación CI

 Catalogación CAT

 Autoridades AUT

 Adquisiciones AD

 Publicaciones periódicas PP

Página 14

Introducción

Cada cuestión es identificada con un código y un nombre, y es valorada en base a cuatro
conceptos que se han diferenciado como:

 Características Koha: se describe la funcionalidad y filosofía Koha;

 Situación BAGE: se detallan las cuestiones comentadas y definidas por los técnicos del
grupo de trabajo;

 Posibilidades y soluciones aportadas: posibilidades y diferentes soluciones aportadas por
el grupo de trabajo;

 Valoración: nivel de importancia/prioridad de la cuestión planteada y su necesidad en el
desarrollo para BAGE;

4. Identificación y definición de requisitos. Partiendo de todas las cuestiones identificadas
en el apartado anterior, se separan las que se consideran requisitos de desarrollo por
nivel de prioridad y se presentan con la valoración y estimaciones necesarias. Así
mismo, se definen las características del proyecto de desarrollo.

5. Proyecto piloto: propuesta de implantación de un proyecto piloto, así como el soporte y
mantenimiento que sería necesario para el sistema.

Página 15

2 Koha: Sistema de Gestión Integrada
de Bibliotecas de Fuentes Abiertas

Koha: Sistema Integrado de Gestión de Bibliotecas de
Fuentes Abiertas

2.1 Descripción y características generales

Koha es el Sistema Integrado de Gestión de Bibliotecas en Fuentes Abiertas más
extendido. De uso en todo el mundo, su desarrollo y evolución están dirigidos por una
importante comunidad de bibliotecarios que colaboran para alcanzar sus objetivos y
necesidades tecnológicas. Koha, además, es un desarrollo vivo y sigue evolucionando y
mejorando.

2.1.1 Descripción

Koha es un Sistema Integrado de Gestión de Bibliotecas que se está utilizando en bibliotecas
de todo el mundo con características muy diferentes. Sus funcionalidades se adaptan a
cuestiones muy sencillas y básicas, pero también tiene capacidad y prestaciones para
implementar soluciones muy avanzadas.

Koha incluye módulos de circulación, catalogación, adquisiciones, publicaciones periódicas,
reservas, gestión de usuarios, gestión de bibliotecas y otros.

2.1.2 Características generales

Koha es un Sistema Integrado de Gestión de Bibliotecas de fuentes abiertas que permite
realizar todos los procesos bibliotecarios y funciona con una arquitectura cliente – servidor.
Para ello utiliza:

 GNU/Linux, Apache, MySQL, Perl y OpenLDAP en el servidor
 Cualquier navegador Web en el cliente.

Página 17

Fuentes Abiertas

Diseño Dual de Base de Datos

Koha trabaja con un diseño de base de datos dual que utiliza los puntos fuertes de los dos tipos
principales de estándares en la industria de bases de datos (documental y relacional). Esta
característica asegura que el diseño de Koha es escalable y suficiente para cubrir las
necesidades de cualquier biblioteca, sin importar el tamaño.

Interfaces Web

Todas las interfaces de Koha están basadas en estándares compatibles con las tecnologías de
la World Wide Web - XHTML, CSS y Javascript – para convertir a Koha en una verdadera
solución de plataforma independiente.

Todo el funcionamiento se gestiona vía Web, para lo que Koha ofrece dos tipos de interfaces
totalmente independientes en su gestión:

 OPAC (portal de acceso público), e

 Interfaz de trabajo técnico bibliotecario (Intranet o Administración)

Fuentes abiertas

Se distribuye bajo licencia GPL, que garantiza lo derechos a los usuarios de aplicaciones de
fuentes abiertas recogidos en el Art. 16 de R.D. 4/2010, que regula el Esquema Nacional de
Interoperabilidad.

2.2 Comunidad Koha, desarrollo en fuentes abiertas

La colaboración en 1999 entre Katipo Communications y Horowhenua Library Trust, dio origen
a la primera versión de Koha. A partir de ahí, la comunidad de usuarios y desarrolladores de
Koha ha ido creciendo, se han lanzado varias versiones y se han hecho públicas muchas
implantaciones.

Página 18

Fuentes Abiertas

Koha responde al modelo de desarrollo distribuido entre proveedores y bibliotecas de todo el
mundo. Desde su origen en 1999, más de 80 desarrolladores han contribuido a Koha. Para
coordinar el trabajo entre todos los contribuyentes, se elije un equipo oficial de desarrollo.

Para cada versión, se crea un equipo de desarrollo. Actualmente, para la versión 3.2 el equipo
se compone de:

 Release Manager: Galen Charlton <gmc@liblime DOT com> from LibLime

 Release Maintainer: To be determined upon release

 Quality Assurance Manager: Position Open - email Koha-devel if you'd like to be
considered

 Documentation Manager: Nicole C. Engard <nengard@bywatersolutions.com>

 Interface Design Manager: Owen Leonard <zivot@zivotdesign.com> from Zivot Design
and Nelsonville Public Library

 Translation Manager: Chris Cormack <chris@bigballofwax.co.nz> from Catalyst

Liblime y Biblibre son las empresas que lideran la comunidad. Juntas suman más del 80 % de
los desarrolladores de Koha, pero la comunidad es abierta y existen numerosas formas de
colaboración. La comunidad las define.

 Unirse al equipo de desarrollo: Koha-devel.

 Instalar Koha

 Apadrinar un proyecto

 Ayuda con la documentación

 Feedback (Bugs)

 Sugerir mejoras

 Traducir Koha

 Procesos bibliotecarios

 Organizar eventos Koha

Página 19

Fuentes Abiertas

MASmedios es una de las empresas que proporcionan soporte y desarrollo en España.

2.3 Funcionalidades principales

2.3.1 Administración

Módulo para la definición y parametrización de las características del sistema donde se hace
referencia, entre otros aspectos, a:

 Preferencias del sistema en cuanto a catalogación, OPAC, búsquedas, usuarios, fechas,
etc...

 Parámetros básicos en el que se definen las bibliotecas, sucursales y/o grupos de
bibliotecas, las cuentas y presupuestos de las diferentes bibliotecas, las divisas y tipos
de cambio, los tipos de ítems, etc.

 Usuarios y préstamos en los que se definen las categorías de usuarios, los paises y
ciudades, las reglas y políticas de circulación de documentos o las sanciones.

 Catálogo, dónde se establecen parámetros para los valores autorizados en el registro
MARC, las plantillas de catalogación, el mapeo de MARC (vinculación del registro MARC
a la SQL de la herramienta, test de validación de plantillas MARC, plantillas de
autoridades, recursos y fuentes de Clasificación (CDU, DEWEY, etc.), congruencia de
registros (congruencia entre ISBN, ISSN de los registros)

 Parámetros adicionales como la lista de palabras vacías, las impresoras o los servidores
Z39.50

Página 20

Fuentes Abiertas

2.3.2 Catalogación y Autoridades

Módulo para catalogación de registros MARC:
o Bibliográficos
o Autoridades

Este módulo permite la selección de plantillas de catalogación para la inserción de nuevos
registros, así como la edición o modificación de registros ya existentes.

Además, permite la catalogación de autoridades y el control de uso de las mismas.

2.3.3 Circulación

Módulo que gestiona los préstamos, según los parámetros indicados en la configuración del
sistema, y todas las acciones relacionadas con ellos, es decir:
 Realizar préstamos y devoluciones (código de barras)
 Transferencias entre bibliotecas/sucursales o subbibliotecas

Además, permite obtener informes de:
 Libros reservados
 Libros pendientes de retirar por los usuarios
 Transferencias por hacer
 Libros atrasados en préstamo
 Multas / sanciones por retraso
 Diarios de préstamo

2.3.4 Publicaciones Periódicas

Gestión de publicaciones periódicas y suscripciones (alta y control de suscripciones,
periodicidad, reclamaciones de ejemplares, llegada de ejemplares, etc.)

Página 21

Fuentes Abiertas

2.3.5 Adquisiciones

Módulos que gestiona:
Los pedidos (se inician, reciben o modifican pedidos);
Las reclamaciones de pedidos atrasados;
Los datos de proveedores;
Las sugerencias de compra realizadas en el OPAC, etc.

Desde aquí se controla el estado de los presupuestos y se gestionan las sugerencias de
compra recibidas desde el OPAC.

Usuarios

Módulo de gestión de usuarios que permite crear, modificar y recuperar la información sobre
los usuarios.

2.3.6 Estadísticas

Existen dos posibilidades de obtener informes de la herramienta. Por un lado, los informes
predefinidos, que facilitan informes genéricos de uso (Adquisiciones, Usuarios, Catálogo,
Préstamos), informes de inactividad (usuarios que no realizan préstamos, libros no
prestados...), Top list (usuarios que más préstamos realizan, los libros más prestados) u otros
informes (libros perdidos, catálogo por tipo de documento, préstamos por tipo de usuario, etc.).

Por otro lado, la herramienta facilita la confección de informes más personalizados mediante un
asistente para informes, desde el que el usuario selecciona qué datos quiere, cómo quiere que
se visualicen, etc.

Página 22

Fuentes Abiertas

2.3.7 Catálogo (buscar)

Módulo que facilita la consulta al catálogo desde la Intranet sin necesidad de acceder a la parte
pública. Podemos utilizar la búsqueda simple y la avanzada.
Tiene también la posibilidad de generar LISTAS, eliminar o modificar documentos para que
puedan ser consultadas por los usuarios desde el OPAC. Se trata de personalizar búsquedas u
ofrecer recomendaciones a los usuarios.

2.3.8 Herramientas

En el módulo herramientas, encontramos otras funcionalidades como:

 Noticias: edición y gestión de noticias que aparecerán en el OPAC / portal
 Generador de etiquetas: tejuelos
 Calendarios: definir festivos, etc. para cálculo de préstamos
 Comentarios: moderar comentarios hechos por los usuarios en los registros
 Importar registros MARC (masivamente)
 Gestión de registros MARC
 Exportar datos bibliográficos
 Importar usuarios
 Borrado de usuarios e historial
 Incluir imágenes de usuarios
 Calendarios de tareas
 Avisos (del sistema)
 Alertas y avisos de atrasos
 Visualizador de Logs: que permite el control de las acciones realizadas en el sistema y
su exportación a otras herramientas (como EXCEL)
 Inventarios

Página 23

Fuentes Abiertas

2.3.9 OPAC (Interfaz público)

El OPAC es la herramienta desde la que el usuario interactúa con el centro de documentación /
biblioteca. El OPAC es un portal Web desde el que el usuario puede:

 Consultar el catálogo (localizar los libros / recursos del centro)
o Búsqueda simple
o Búsqueda avanzada (limitar y redefinir la búsqueda)
o Búsquedas relacionadas (mismo autor, misma materia, etc.)
o Búsquedas en otros catálogos (Worldcat, Google scholar..)
o Búsqueda por nube de tags (nube con las materias)
 Incorporar reseñas y recomendaciones de Amazon
 Realizar desideratas
 Incluir comentarios de los libros/documentos
 Consultar listas de recomendados
 Crear bibliografías e imprimirlas y/o enviarlas por correo electrónico
 Leer las noticias que se editen desde la biblioteca

Hay una parte privada, para la que se pide que el usuario se autentifique en la que cada uno de
los usuarios puede:

 Crear listas de documentos favoritos (listas privadas)
 Consultar su historial de préstamos, solicitudes, etc.
 Renovar sus préstamos
 Modificar sus datos

Página 24

Fuentes Abiertas

3 Koha en las BAGE

Página 25

Fuentes Abiertas

3.1 Análisis detallado

 Cuestiones que Koha no cumple y que, con mayor o menos grado de importancia, es
necesario desarrollar. Por ejemplo, incluir el trabajo con todos los tipos de registros
MARC21 o mejoras de accesibilidad del OPAC.

 Cuestiones no propias del SIGB, pero que requieren un desarrollo específico para el
proyecto BAGE y su implantación y puesta e marcha, como son las cuestiones
relacionadas con la instalación, documentación específica, etc.

 Dudas / comentarios: cuestiones que se han planteado y que se incluyen en Koha por
ser cuestiones avanzadas o por tener un enfoque distinto al de otros SIGB.

Este análisis detallado consiste en revisar cada una de estas cuestiones y valorar si deben
incluirse o no en la definición de requisitos y en las estimaciones para el desarrollo de la
distribución para las BAGE.
En el siguiente cuadro describimos los criterios de agrupación de todos estos comentarios y
apuntes:

Código Nombre Alcance
Hacen referencia a cuestiones generales que afectan a todos los
AG Aspectos generales módulos o funcionalidades de la herramienta o a la implantación
de la misma en cualquier centro
Cuestiones relacionadas con las necesidades de arquitectura
AI Aspectos informáticos
tecnológica y de implantación de la herramienta
Estándares, protocolos y demás cuestiones técnicas
AT Aspectos técnicos
NORMALIZADAS de gestión de bibliotecas
Módulos y posibilidades de parametrización de la herramienta para
AH Administración y herramientas
personalización y trabajo individual de las bibliotecas
OP OPAC Modificaciones y carencias detectadas en interfaces OPAC
Cuestiones relativas al módulo de circulación (reservas,
CI Circulación
préstamos, renovaciones, transferencias…)
Aspectos relacionados con la gestión del catálogo y su relación
CAT Catalogación
con autoridades
AUT Autoridades Aspectos relacionados con la gestión de las autoridades
Aspectos relacionados con la gestión de compras, sugerencias de
AD Adquisiciones
compra, gestión de presupuestos…
PP Publicaciones periódicas Gestión de suscripciones a publicaciones periódicas y colecciones

Página 26

Fuentes Abiertas

Cada cuestión es identificada con un código y un nombre, y es valorada en base a cuatro
conceptos, que son:
CÓDIGO: iniciales del grupo al que pertenece la observación más un número correlativo por
orden de aparición / agrupación.
NOMBRE: el nombre intenta ser lo más representativo posible.

 Características Koha: se describe la funcionalidad y filosofía Koha respecto a la
cuestión planteada por el grupo de trabajo.

 Situación BAGE: se detallan las cuestiones comentadas y definidas por los técnicos del
grupo de trabajo y las necesidades planteadas.

 Posibilidades y soluciones aportadas: posibilidades y diferentes soluciones aportadas
por el grupo de trabajo.

 Valoración: se han definido varios niveles de importancia o necesidad:

NIVEL ALCANCE
Cuando el comentario / observación tiene más que ver con la
INDEPENDIENTE formación y la habilidad del usuario que con el estudio y análisis
para el desarrollo de una distribución personalizada
Cuestiones que deben ser tenidas en cuenta para el desarrollo en
BÁSICO
BAGE identificadas como básicas y necesarias
Cuestiones que deben ser tenidas en cuenta para el desarrollo
BAGE teniendo en cuenta que es uno de los primeros pasos para
RELEVANTE el punto de consulta único. Es decir, aquellos elementos que se
deben contemplar porque influirán en el proyecto de creación
catálogo colectivo
Cuestiones que convendría contemplar en el desarrollo pero no
VALOR AÑADIDO
son básicas. Funcionalidades de valor añadido

Página 27

Fuentes Abiertas

3.1.1 Aspectos generales

A.G. 1 Entorno de trabajo
Características Koha
Koha trabaja 100% en entorno Web, necesitando dos URL distintas: una para la Intranet y
otra para el OPAC.
La navegación en ambos portales dependerán del navegador (sesiones, usuarios, barra de
herramientas del navegador…)
Situación BAGE
Se comentaron limitaciones respecto a otro tipo de aplicaciones de escritorio como mantener
varias pantallas abiertas de los diferentes módulos. Por ejemplo: catalogación y circulación
para localizar el código de barras y para realizar el préstamo.
Posibilidades y soluciones aportadas
Se pueden abrir varios navegadores. Koha permite el uso concurrente (trabajar con varias
instancias del navegador con el mismo usuario).
Valoración
INDEPENDIENTE DEL DESARROLLO. Es una cuestión inherente a Koha.

A.G.2 Traducción
Koha está desarrollado originalmente en inglés. Las plantillas (capa de visualización) para
cada idioma, se duplican en los directorios correspondientes según los idiomas disponibles a
partir del directorio “en”. Esta duplicidad de directorios no funciona correctamente, pero se
dispone de un Bug sobre la duplicidad de directorios y ficheros de idiomas.
En Koha existe una utilidad que facilita la copia de las plantillas y directorios para más
idiomas y la generación del fichero de traducción de las cadenas de texto (ficheros.po). En
algunos casos la traducción no es homogénea ni clara puesto que se traducen partes de las
cadenas de texto de forma aislada.
Los idiomas disponibles dependen de la versión de Koha y cuentan con diferentes grados de
traducción en cada una de ellas. Existe una página donde se monitoriza el grado y evolución
de las traducciones http://translate.Koha.org/ cualquiera puede registrarse para contribuir a la
traducción.

Página 28

Fuentes Abiertas

Situación BAGE
Es necesario mejorar la traducción a castellano (y revisar otros idiomas básicos para el
proyecto (catalán, gallego y euskera).
La traducción podría plantearse como una fase en sí misma en el proyecto de desarrollo y
estará muy relacionada con el nivel de personalización y de trabajo que se quiera invertir.
Es un tema complicado y puede resultar deficiente a nivel de desarrollo en la comunidad.
Este aspecto es considerado básico en el desarrollo para las BAGE; por ello, el grupo de
trabajo propone como solución:
1. Centrar esfuerzos en mejorar la aplicación anteriormente mencionada (de
generación de directorios y traducciones) con lo que se buscaría obtener una
herramienta que facilitara la traducción coherente y en contexto de cadenas de
texto de TODA la aplicación. Este desarrollo podría proponerse para que fuera
incorporado en la comunidad. Esta opción es sobre todo conveniente para
mejorar la herramienta en la comunidad y, en concreto, para las BAGE, para la
parte de INTRANET, por la cantidad de plantillas que la forman.
2. Realizar la traducción a los idiomas que actualmente no existen -como el euskera-
y mejorar las que están a un nivel muy bajo -como el catalán-, sobre todo para la
parte de OPAC.
3. Ya que se va a trabajar en la mejora de interfaces OPAC, se pueden centrar
esfuerzos en la integración y generación de las plantillas en los idiomas que se
requieren en el proyecto (castellano, inglés…)

Valoración
La mejora de la traducción es una cuestión básica en el desarrollo para BAGE, pero hay que
ser muy cuidadosos y tener en cuenta que es una cuestión que mejora la herramienta y su
difusión, con lo que habría que trabajar con la comunidad y los objetivos para esta cuestión.

A.G.3 Creación de dominios. Independencia de las bibliotecas
Una instancia Koha puede contar con varias bibliotecas y funcionar como los “scopes”, es
decir, limitar búsquedas, agrupar resultados, transferir libros entre ellas, etc. pero no las
gestiona como unidades administrativas de forma independiente y por tanto, no podemos
tener distintos OPACs, y gestión independiente de módulos (adquisiciones, catalogación…)

Página 29

Fuentes Abiertas

de forma que cada biblioteca pueda únicamente ver y trabajar con sus datos (registros,
usuarios…).
Existen limitaciones para la gestión de la biblioteca, por ejemplo, un libro de una biblioteca no
puede ser devuelto en otra biblioteca (esta acción se controla por el usuario del bibliotecario
que realiza la acción). El sistema avisa de que no puedes hacerlo. Pero otras, como por
ejemplo catalogación, no están aisladas.
Situación BAGE
Es interesante que Koha pueda dar soporte a una unidad administrativa con varias
bibliotecas y que se puedan realizar algunas gestiones independientemente.
Disponemos del Código desarrollado para la distribución de Koha de las bibliotecas públicas
gallegas para la creación de dominios.
Tal vez también sea interesante profundizar en el concepto GRUPO de bibliotecas que ya
contempla Koha, o bien, la instalación de una instancia Koha por biblioteca.
El desarrollo de la gestión de dominios debería analizar las necesidades de las bibliotecas de
las BAGE. La mayoría de las bibliotecas participantes son unidades independientes (no
ocurre lo mismo con las municipales de Galicia).
Valoración
El desarrollo de la gestión de dominios debería analizar las necesidades de las bibliotecas de
las BAGE y a priori se considera una cuestión de VALOR AÑADIDO.

A.G.4 Diseño Web
Koha responde al sistema de desarrollo en tres capas, con lo que la capa de visualización
(plantillas) pueden ser modificadas sin necesidad de modificar la lógica ni la programación de
la herramienta.
El backend de Koha y el OPAC se ha desarrollado con un sistema de plantillas que es fácil
de personalizar. Las plantillas son XHTML y CSS.
Situación BAGE
Se requiere:
 OPAC: cambio del diseño Web que refleje la imagen de cada una de las bibliotecas
donde se instale la distribución desarrollada para las BAGE: colores, CSS, logos (2
logos: izq: BAGE… derecha: biblioteca concreta).
 INTRANET: cambio mínimo con los dos logos.
Página 30

Fuentes Abiertas

Para facilitar la adecuación a la imagen corporativa de cada una de las bibliotecas, pero
también del proyecto común, el se propone:
o Nuevo diseño para todas las bibliotecas (que ya irá incluido en la
aplicación a descargar e instalar por las bibliotecas)
o Inserción de funcionalidades para la personificación (logos)
Cuando hablamos únicamente de CSS (colores, estilos,…) hacemos referencia a una
personalización gráfica básica que no incluye ni modificación en arquitectura de información
ni en funcionalidad.
Valoración
El cambio gráfico es de proyecto más que de funcionalidad Koha. Incluir funcionalidades de
personalización sería RELEVANTE y está íntimamente relacionado con las cuestiones
recogidas en el grupo OPAC

A.G.5 Multilingüismo
Aspecto relacionado con la traducción, aunque no se debe confundir la existencia de
plantillas en varios idiomas con que Koha sea una herramienta multilingüe. La única gestión
de idiomas que existe actualmente en Koha es para las noticias del portal (es decir, puedes
incluir una noticia e indicar en qué idioma quieres que aparezca.
Como ya hemos mencionado en AG 2 el OPAC y la Intranet están traducidas a nivel de
plantillas.
Todos los elementos de base de datos sólo trabajan en un solo idioma. Poe ejemplo:
o Preferencias del sistema
o Parámetros básicos (tipos de ítem, usuarios, plantillas MARC…)
o Catalogación (registros bibliográficos)
o Autoridades
Situación BAGE
Incluir la gestión de idiomas en Koha, no sólo que muestre las interfaces en varios
idiomas, sino que sea MULTILINGÜE.
Habría que analizar qué funcionalidades se desean implementar con multilingüismo para
cambiar el código y la base de datos.

Página 31

Fuentes Abiertas

Se podría incluir el multilingüismo en todo lo que afecta al OPAC y a los usuarios:
o Información que aparece en OPAC (estados, tipos de ítems, etc.)
o Autoridades multilingües y buscadores (usando los campos 7xx para almacenar
las autoridades en otros idiomas y los indicadores para diferenciar el idioma)
La parte de Intranet o que sólo afecte a usuarios profesionales (STAFF), puede continuar en
un único idioma (preferencias del sistema, estructuras MARC, etc.)
Valoración
Lo que ocurre en Koha ocurre en todas los SIGB comerciales. En el caso de los
desarrollados en España, están en castellano, pero lo extranjeros están desarrollados en
inglés, traducidos a nivel plantilla y no gestionan idiomas.
Sería una cuestión muy interesante incluir la gestión real multilingüe, pero supondría un
desarrollo muy extenso que significaría una revisión muy amplia de la herramienta, por ello,
podría considerarse que, inicialmente, la traducción es básica, pero el multilingüismo sería
RELEVANTE.
El tema de autoridades multilingües es tratado en AUT. 2

A.G.6 Actualizaciones, versiones y desarrollo
La versión de Koha en la que se ha estado trabajando es la versión 3.0.6. En febrero de
2010 se presentó la 3.2.0 Alpha, y se está trabajando ya en la 3.4.
Para cada versión hay un equipo responsable que coordina los desarrollos. Existe una lista
de funcionalidades para cada una las versiones, con lo que las posibilidades de incluir
funcionalidades en Koha pasa por la inclusión de las mismas en futuras versiones.

RESOLUCIÓN de BUGS: la resolución de Bugs es otro aspecto muy importante de las
comunidades en Fuentes Abiertas. Los usuarios pueden reportar Bugs y solucionarlos. En
cada una de las versiones “fixed” el número de Bugs solucionados es mayor.

De versión a versión ha habido muchos cambios, tanto en lógica como en base de datos,
con lo que las actualizaciones pueden ser un proyecto en sí mismo.
Situación BAGE
Lo que se propone en este proyecto es crear una distribución, un desarrollo sobre Koha que
se adecue a las necesidades de las BAGE.

Página 32

Fuentes Abiertas

Posibilidades y Soluciones aportadas
Cualquier desarrollo sobre Koha va a suponer una separación del desarrollo y, por
consiguiente, se ocasionan problemas o complicaciones para el paso y actualización de
versión o para la incorporación de nuevas funcionalidades.
Todo el proyecto de desarrollo debe tener en cuenta aspecto más estratégicos como:
o Desarrollo en Koha (guías para el desarrollo, git de Koha, buzilla,…)
o Aportaciones a la comunidad (desarrollar y proponer a la comunidad la inclusión
de los desarrollos en nuevas versiones de Koha)
o Desarrollo sobre Koha (trabajar con filosofía y estructura Koha para que futuras
actualizaciones y modificaciones sean lo menos problemáticas posible)

Valoración
Se trata de una cuestión independiente en cuanto a herramienta y funcionalidad se refiere,
pero es un aspecto BÁSICO en el proyecto. En la definición de requisitos, se contemplan
todos estos aspectos.

A.G.7 Migración
Koha cuenta con la funcionalidad para importar / exportar registros y puede trabajar en
MARC21 y UNIMARC.
Situación BAGE
No todas las bibliotecas trabajan de forma normalizada, y dentro de las que sí lo hacen, el
formato más extendido es IBERMARC.
Además, esta cuestión está relacionada con AT 1: incorporar MARC21 como formato de
catalogación para las BAGE.
La solución es siempre a título individual por biblioteca. Las cuestiones que necesitamos
concretar son las posibilidades de:
o Migración de autoridades
o Migración de bibliográficos
o Migración de ejemplares
Para utilizar la funcionalidad de importar es necesario utilizar ficheros .marc o ISO. Koha
también puede importar la información de ejemplares, pero no las de autoridad.
Para el resto, se podría hacer una extensión con:

Página 33

Fuentes Abiertas

1. Conversor/mapeo de IBERMARC a MARC (También se podría trabajar en un
conversor IBERMARC a MARC como una extensión o herramienta auxiliar para las
bibliotecas.)
2. Migración de autoridad
3. migración de bibliográficos
4. Relación bibliográfico-autoridad.
Si nos encontramos con datos no normalizados MARC, habría que hacer el análisis
individual en cada caso.
Valoración
Se trata de una cuestión INDEPENDIENTE en cuanto a herramienta y funcionalidad se
refiere, pero es un aspecto muy importante en el proyecto, puesto que muchas bibliotecas
necesitarán MIGRAR sus datos a Koha u a otro sistema automatizado para incorporarse al
proyecto.
También se podría trabajar en un conversor IBERMARC a MARC como una extensión o
herramienta auxiliar para las bibliotecas.

3.1.2 Aspectos informáticos

A.I. 1 Conectividad, accesos, puertos
El acceso los servidores z39.50 se realiza mediante unos puertos específicos. Es necesario
que estén abiertos.
Situación BAGE
Políticas de acceso y seguridad diferentes en cada ministerio.
El Departamento de Sistemas de cada ministerio debe abrir los puertos correspondientes
para permitir el uso del protocolo en Z 39.50 para la catalogación.
En Koha, en el módulo de administración, se gestionan los servidores con los que los
usuarios quieran conectar. Simplemente tendrán que tener los datos actualizados (puertos,
bases de datos, etc.) y protocolos para solicitar las autorizaciones en los departamentos de
comunicaciones y/o seguridad.

Página 34

Fuentes Abiertas

Valoración
Es una cuestión INDEPENDIENTE a Koha y a la funcionalidad. Es un aspecto de proyecto
y de instalaciones de la aplicación. Se deberá valorar la implicación que esto conlleva para la
integración con el Extensible Catalog y con el protocolo OAI-PMH y la instalación y accesos
a la herramienta en cada ministerio. Para el proyecto Koha es independiente de la
herramienta, aunque no de la implantación.

A.I. 2 Navegadores
Koha está optimizado para trabajar con navegadores que cumplan estándares (Firefox)
Situación BAGE
En muchos ministerios el navegador de Internet predeterminado es Internet Explorer. Los
problemas más habituales con Internet Explorer hacen referencia sobre todo a:
o Maquetación
o Errores de Java Script (Por Ej.: problemas con la librería Yui de Yahoo)

o Se puede plantear la optimización de Internet Explorer (7 ó superior);
o Incluir Firefox en el paquete de instalación no solucionaría el problema, ya que este
paquete se instala en el servidor, no en el cliente.
Como el navegador depende del cliente que se conecta a Koha y de las políticas de
seguridad de cada red local, lo único que se puede hacer desde Koha es mostrar un
mensaje cada vez que se entra para avisar de si el navegador y su versión son óptimos para
el normal funcionamiento del portal. Se pueden facilitar enlaces de descarga a los
navegadores que soportan mejor Koha: Firefox, Chrome, Opera aunque la instalación de los
navegadores depende de la política de cada institución.
Valoración
El navegador es una cuestión INDEPENDIENTE al desarrollo de Koha, con lo que la opción
más sencilla es incluir esta información como básica en la implementación de la herramienta,
puesto que la instalación de los navegadores depende de la política de cada institución.
Para evitar este tipo de cuestiones y teniendo en cuenta que se contemplan como básicas
algunas modificaciones en OPAC, podemos incluir como BÁSICO, la optimización para
Explorer 7 ó superior. Como valor añadido, y a falta de confirmar en qué ministerios no se

Página 35

Fuentes Abiertas

podría instalar el Firefox, se podría incluir lo que proponemos de detección del navegador.

A.I. 3 Arquitectura tecnológica
La arquitectura tecnológica de Koha recomendada por la comunidad y con la que más
instancias de Koha se ha probado es:
o Linux (distribución debian Lenny)
o Perl
o MySQL, Zebra
o Apache
Perl y las bases de datos son obligatorios, pero el sistema operativo y el servidor Web
pueden variar.
Situación BAGE
La arquitectura tecnológica que requiere Koha no coincide con la de muchos ministerios o
centros.

La tendencia para el ahorro de costes y el despliegue más rápido de sistemas es la
“virtualización”. En varios ministerios cuentan con plataformas virtualizadas, con lo que se
puede preparar una instalación base con la configuración de todos los componentes básicos
ya instalados con objeto de que se pueda clonar a otros ministerios, tal como se ha hecho en
MPR.
La institución que quiera clonar la aplicación, simplemente tendrá que tener preparada una
máquina virtual con el sistema base (vmware o similar)
Valoración
Desarrollar una instalación base que recoja otros aspectos mencionados en este informe
(parametrización, etc.) se considera BÁSICO en el desarrollo del proyecto.

A.I. 4 Seguridad Informática
Koha es una aplicación Web (cliente / servidor). El acceso al servidor donde esté instalado
Koha no depende de la aplicación, sino no de las políticas de seguridad y acceso al propio
servidor.

Página 36

Fuentes Abiertas

Cada uno de los sitios Web de Koha (OPAC e INTRANET) necesitan un puerto o un
subdominio donde redirigirlo. Una vez en la aplicación, los permisos de acceso y
funcionamiento se configuran para cada tipo de usuario y para cada usuario concreto.

Situación BAGE
La información que albergan los catálogos de las BAGEs es una información no sensible a
nivel de seguridad y debe ser difundida con la mayor amplitud a los ciudadanos. Así mismo
debe interoperar abiertamente con otros sistemas de información y servicios en Internet.
Las restricciones de seguridad informática son muy estrictas en los ministerios,
especialmente en Defensa e Interior.
o Abrir la posibilidad de alojar las instancias de Koha fuera de los sistemas de los
ministerios cuando sea necesario para garantizar el acceso del ciudadano.
o Incluir en la virtualización (AI 3) la configuración de puertos fijos
En cualquiera de las dos opciones se requiere la intervención para la implantación de un
administrador de sistemas (asignar IP, nateo)
Valoración
La posibilidad de alojamiento externo no la valoramos ya que no es desarrollo, sino
implantación.
Aunque es independiente del desarrollo, habría que tener en cuenta el tema de los puertos
fijos en la preparación y configuración de la virtualización.

A.I.5 Mejora del rendimiento en las búsquedas (modo perl)
La mejora del rendimiento en las búsquedas en una instancia Koha depende, entre otras
cosas, de la arquitectura de funcionamiento: la arquitectura de funcionamiento de Koha es
mediante CGI, no mediante MODPERL (que mejora el rendimiento). En una aplicación CGI,
el servidor Web pasa las solicitudes del cliente a un programa externo (en el caso de Koha,
PERL). La salida de dicho programa es enviada al cliente en lugar del archivo estático
tradicional.

Si en lugar de la instancia de Koha propia se quiere ampliar la búsqueda e incluir otros
servidores, Koha puede usar PAZPAR (herramienta de metabúsqueda).

Página 37

Fuentes Abiertas

Situación BAGE
En las bibliotecas públicas gallegas han detectado un problema de rendimiento en las
consultas FEDERADAS CONTRA VARIOS SERVIDORES.
El código de las bibliotecas públicas gallegas es para la versión 3.2. Las soluciones que
plantean ellos mismos son:
o Esperar a la versión 3.4, donde está previsto solventarlo (lanzar CGI mediante mod_perl).
o Corrección del código en la librería de búsqueda donde se produce el error.
o Uso de Pazpar 2 (Index Data), que supondría:
o Mejora de las facetas: el uso de Pazpar permite generar facetas de todos
los registros obtenidos en la respuesta a una búsqueda; en Koha 3.2 las
facetas se generan por pantalla de resultados. Esta solución es
equiparable a la que se obtendría en caso de usar VUFIND
o Inclusión de las metabúsquedas en Koha, adoptando soluciones tipo
PRIMO de GreenData (ejemplo, SOLO en Oxford Libraries).

Actualmente no existe en la Intranet una interfaz de configuración del Pazpar, con lo que
ésta debe realizarse de forma manual en sus ficheros de configuración.
Pazpar sólo admite consultas a servidor z39.50 o SRU/SRW y trabaja con diferentes
formatos, pero facilita la visualización en diversos formatos.
PAZPAR puede trabajar con CGI o con MOD perl.

Valoración
Inicialmente, el desarrollo sobre Koha para las BAGE, por ser el punto de partida para la
automatización, no debe contemplar servicios de búsqueda federada. El objetivo del
proyecto es la automatización de bibliotecas con el fin de crear un catálogo colectivo (sin
metabúsqueda).
En cualquier caso, la configuración del PAZPAR para la búsqueda en el OPAC, puede
incluirse como VALOR AÑADIDO por si una biblioteca concreta necesita incluir la búsqueda
en otros catálogos en su OPAC.

Página 38

Fuentes Abiertas

A.I. 6 Contraseñas/ Gestión de usuarios
El alta de usuarios y la generación de contraseñas en Koha es un proceso totalmente
manual.
Koha cuenta con unas tipologías y categorías de usuarios (que llevan asociados ciertos
permisos o características) pero el proceso de alta de usuarios (incluso los de Staff) es
manual.
La contraseña la inserta quien la genera, pero ya aparece con los caracteres ocultos. Es
usuario puede modificarla en cuanto accede al sistema.
Situación BAGE.
Se plantea la generación automática de contraseñas.
Existen varias opciones:
o Incluir en el alta del usuario -sin modificar nada la filosofía Koha-, una contraseña
generada automáticamente o un botón para generarla automáticamente.
o Otra opción es hacerlo como en DSpace y en otras aplicaciones: alta por parte de
anónimo en el OPAC, envío de correo, confirmación de alta en la Intranet sujeto a
revisión o no por parte de alguien.
Tampoco hay que perder de vista que tendremos muchas instituciones en las que todos los
miembros de la organización sean usuario y sea necesario lanzar procesos por lotes o
integrar con otras aplicaciones que ya realizan la gestión de usuarios, con lo que habrá que
desarrollar una capa para integrar el single sing on, integrar con un servidor LDAP, etc.
Valoración
Ésta es una cuestión muy especializada y muy concreta de cada institución, con lo que, se
podría incluir como BÁSICO la generación automática de contraseñas y el resto de opciones,
y se consideran VALOR AÑADIDO más relacionadas con la implantación que con el
desarrollo.

Página 39

Fuentes Abiertas

3.1.3 Aspectos técnicos

A.T.1. Familia MARC21
Koha puede trabajar con MARC 21 y UNIMARC en la creación de registros bibliográficos y
de autoridad. Para las existencias, se ha seguido el modelo francés y no se ha implementado
el registro de fondos. Se ha elegido un campo de uso local para la información de ejemplares
(información del mapeo y relación con MARC 21 Holdings en
http://www.Kohadocs.org/holdings.html, donde se explica cómo hacer un mapeo de los
campos del holding MARC21 a los 952 del ejemplar; se puede realizar desde la Intranet en
Administración-> Enlaces MARC->Items).

Situación BAGE
Muchas bibliotecas trabajan en IBERMARC o simplemente no utilizan el formato MARC.
En las que se utiliza el MARC 21 no se usa el MARC21 Holdings, ni comunidad, ni de
clasificación.
Se plantea la necesidad de incluir la gestión de cualquier tipo de registro MARC21 pero
como mínimo bibliográfico, autoridad y fondos.
Las bibliotecas que utilizan Absys, cuentan con el concepto colección y la catalogación
retrospectiva de la colección.

En primer lugar, habría que comprobar el nivel de implantación de toda la familia MARC21,
es decir, tendría que analizarse el uso de MARC 21 y las posibilidades de mapeo con los
registros existentes (relacionado con la migración de registros)
Siguiendo la filosofía Koha de utilizar las preferencias del sistema, podríamos realizar un
desarrollo específico para incluir TODOS los formatos.

Página 40

Fuentes Abiertas

Valoración

Esta cuestión se considera de carácter BÁSICO, sobre todo la posibilidad de gestionar
registros de fondos, con lo que se trabajaría con MARC bibliográfico, autoridades y fondos.
Utilizando la misma filosofía y como VALOR AÑADIDO, se podría incluir los registros de
comunidad y clasificación.

A.T.2 Formatos MARC
Koha soporta el formato MARC 21 y el Unimarc
Situación BAGE
El 60% de las bibliotecas utilizan el formato IBERMARC. Debería haber una pasarela entre
IBERMARC y MARC 21 para la conversión de los datos de forma previa a la inclusión en el
catálogo de Koha.
La migración del formato IBERMARC a MARC 21 se deberíaN hacer las “Equivalencias
Ibermarc –Marc21” de la Biblioteca Nacional.

Valoración
Es una cuestión INDEPENDIENTE al desarrollo y relacionada con la migración.

A.T.3 Búsquedas federadas
Koha permite realizar búsquedas a distintos servidores Z39.50 /SRU-SRW y mostrar los
resultados; para ello usa la aplicación Pazpar, que se tendría que configurar para decirle
cuáles son esos servidores. Actualmente la configuración se realiza a mano porque hay que
cambiar un fichero XML y reiniciar el Pazpar.
Situación BAGE
Permitir realizar la búsqueda en otros recursos online de forma simultánea, ya que
posibilitaría al usuario recuperar información de diferentes fuentes desde una misma
búsqueda.
Página 41

Fuentes Abiertas

Con la funcionalidad Koha, ya se permite la búsqueda federada pero con limitaciones porque
deben ser servidores Z39.50 y/o SRU-SRW
Lo realmente interesante, como en el caso de los Z39.50 en la Intranet, es crear en
Administración para el metabuscador Pazpar2 un mantenimiento en la Intranet que permita
una gestión fácil.
Además, se dispone de la experiencia y del código desarrollado para la distribución de Koha
de las bibliotecas públicas gallegas para este fin -como ya se ha indicado en A.I.5 -
Valoración
La metabúsqueda es una cuestión interesante, pero no es básica para la automatización de
las bibliotecas. Se trata de un desarrollo de VALOR AÑADIDO.

A.T.4 Repositorio / gestión de objetos digitales
Koha es un SIGB, no contempla la posibilidad de almacenar recursos digitales en un
repositorio, aunque sí contempla el protocolo OAI como servidor.
Situación BAGE
Necesidad de poder integrar recursos digitales, ya que no se puede limitar a tener una
descripción de los fondos y la localización, sino proporcionar el detalle de la estructura de
los documentos.

Además, existen instituciones que ya tienen digitalizadas las portadas y los sumarios de
ejemplares, pero no tienen espacio en un servidor interno para poder ofrecerlo al usuario

Esto permitiría reaprovechar el trabajo realizado que en este momento se encuentra
inactivo.

Hay que evaluar las posibilidades:

o Disponer de un servidor interno que contenga imágenes y ficheros
o Asociar imágenes y ficheros a registros (bibliográficos o de item)
o Tratamiento para publicaciones electrónicas

Página 42

Fuentes Abiertas

El alcance de los desarrollos a realizar para poder usar Koha como repositorio serían:
- Incluir en los directorios de Koha directorios de almacenamiento;
- Incluir desarrollos en la Intranet que permitan:
o Cargar y subir dichos ficheros;
o Relacionarlos con los registros bibliográficos o de ejemplar (módulo
catalogación);
o Gestión de las publicaciones periódicas y de las colecciones (módulo
publicaciones periódicas);
o Modificación en interfaces (OPAC e INTRANET) para la gestión y
visualización de los ficheros

Valoración
Es un desarrollo relacionado con distintos módulos existentes de Koha, pero por los
esfuerzos realizados en digitalización y, por el proyecto global de catálogo colectivo, es una
cuestión muy interesante y BÁSICA a desarrollar.
El desarrollo para la inclusión de registros de fondos (Holdings) también tendrá que tener en
cuenta esta funcionalidad.
Este desarrollo debe tener en cuenta funcionalidades que se harán necesarias en fases
posteriores del proyecto, como el intercambio de ficheros o descarga de los mismos (en
búsquedas z3950)
En el análisis se definirían los objetos digitales que se quieren subir y gestionarlos desde la
Intranet; o bien establecer la relación con la aplicación externa que tiene los objetos digitales
(existen proyectos de integración con greenstone y otras herramientas de gestión de
repositorios).

A.T.5 Búsquedas Z.39.50

Desde el módulo de catalogación, para insertar un registro nuevo, Koha permite realizar
consultas a servidores Z (previamente dados de alta en Administración).
Las consultas pueden hacerse contra uno o varios campos (título, ISBN/ISSN, signatura LC,
autor, encabezamientos de materia y Dewey) y contra uno o varios servidores.
Las búsquedas son asíncronas: se lanzan y se va recorriendo cada uno de los servidores

Página 43

Fuentes Abiertas

para ver si devuelven resultados. No finaliza hasta que se recuperan como máximo 20
resultados de cada uno de los servidores. Los resultados los agrupa por servidor, pero se
muestran ordenados alfabéticamente por título. El usuario puede establecer otros criterios de
ordenación desde la tabla de resultados.
Muestra el MARC y el ISBD, y ofrece la posibilidad de descargar cada uno de los resultados.
Situación BAGE
La búsqueda z39.50 es muy pobre en cuanto a funcionalidad con los resultados:
o No indica cuántos registros te trae de cada servidor y cuántos te muestra
o No se pueden traer varios registros a la vez

Existen muchas posibilidades de mejora de esta funcionalidad:
o Indicar el resumen de cada una de las búsquedas al principio
o Se puede hacer por ajax para que, a medida que va recogiendo
resultados, los muestre y no sea necesario esperar a que todos hayan
terminado
o Indicar el número máximo de registros que tiene que recuperar de los
servidores
o Ordenar resultados por servidor
o Seleccionar los campos que no se tienen que importar (sobre todo campos
como materias, autoridades, etc.)
La funcionalidad de importar registros está ligada a la funcionalidad de añadir registros, pero
esto sólo es posible de forma individualizada (registro por registro), con lo que no se pueden
descargar varios registros para crear sólo uno.

Valoración
Valoramos dos niveles en cuanto al trabajo a realizar:
Sería RELEVANTE mejorar la funcionalidad de búsqueda y recuperación a través del Z39.50
relacionado con la inserción de un registro (mejorando el formulario, la muestra de
resultados, etc.) porque no hay que modificar CORE en cuanto a catalogación e inserción de
registros, pero consideraríamos VALOR AÑADIDO el desarrollo para incluir o descargar
registros en lotes como nueva funcionalidad del módulo de catalogación en Koha.

Página 44

Fuentes Abiertas

A.T.6 NCIP

La norma NCIP (NISO Circulation Interchange protocol) o Z39.83, tiene por objeto abordar la
necesidad creciente de interoperabilidad entre diferentes aplicaciones de circulación,
préstamo interbibliotecario, autoservicio, etc. en el entorno bibliotecario.
Esta norma pretende normalizar las transacciones de circulación entre distintos sistemas
integrados de gestión bibliotecaria (SIGB), permitiendo el préstamo directo a usuarios no
pertenecientes a «nuestra» biblioteca (interacción entre distintos SIGB). NCIP Pretende
también la interoperabilidad entre las diferentes aplicaciones que intervienen en un ciclo
completo de préstamo interbibliotecario:
o Sistema de autopréstamo que gestiona la interacción del usuario.
o Sistema de circulación local que gestiona los privilegios del usuario y del registro
bibliográfico.
o Política de préstamo acordado entre el conjunto de las bibliotecas que aceptan este tipo
de modalidad de PI.
La progresiva implementación del NCIP permitirá transferir gran parte de las transacciones
de préstamo interbibliotecario a un modelo basado en la circulación sin que sea obligatorio
que las redes bibliotecarias y consorcios mantengan y amplíen catálogos colectivos y bases
de datos únicas de lectores.
Koha no implementa el protocolo NCIP, pero sí que se han hecho pruebas y desarrollos con
SIP, que es Standard Interchange Protocol (SIP2) y equipos de 3M 1
Situación BAGE
Con el objetivo inicial de automatizar las BAGE, NCIP (NISO Circulation Interchange
Protocol) no es una primera necesidad, puesto que el préstamo interbibliotecario y las redes
de bibliotecas son un paso más, tanto en la automatización como en el proyecto liderado por
Ministerio de Cultura de punto de consulta único, pero es necesario tener en cuenta que es
un primer paso y que se necesitará un protocolo de comunicación y colaboración en el
proyecto de catálogo colectivo.
Además, muchos de los SIGB que se están utilizando actualmente por algunas de las BAGE,
no cumplen con este protocolo (por ser versiones antiguas de algunos programas
comerciales o porque no lo implementan) ¿??????aunque las herramientas comerciales

1
http://www.osslabs.biz/Koha_library_management_system/installation_guides/sip-ncip-rfid.html
Página 45

Fuentes Abiertas

más potentes como, como por ejemplo Innovative Interfaces en su producto Inn-Reach, o
Voyager).

En próximas versiones de Koha puede estar incluido el desarrollo de integración. Es un
proyecto en sí mismo y puede proponerse a la comunidad como desarrollo. Es una
oportunidad, puesto que puede ser desarrollado y probado con bibliotecas con una
casuística muy amplia y variada.

Valoración
Inicialmente, y para el proyecto de automatización, NCIP es un tema RELEVANTE puesto
que el objetivo final del proyecto es estar preparado para la creación del catálogo colectivo o
la implantación de una herramienta que integre e interactúe con los catálogos de las BAGE;
lógicamente, tendrá que adaptarse a los protocolos y estándares de intercambio de
información tal y como se adaptan en catalogación e intercambio Z39.50.

A.T.7 OAI-PMH

OAI-PMH (Open Archives Initiative – Protocol for Metadata Harvesting) no es solamente un
proyecto centrado en publicaciones científicas, sino que se dedica a la comunicación de
metadatos sobre cualquier material almacenado en soporte electrónico. No hay nada en el
protocolo que impida a los desarrolladores transmitir el contenido propiamente dicho de esos
materiales.
Los metadatos a transmitir vía OAI-PMH deberán codificarse en Dublin Core sin calificar con
objeto de minimizar los problemas derivados de las conversiones entre múltiples formatos.
El marco diseñado por OAI es intencionadamente simple con el propósito de proporcionar
una mínima complicación para las instituciones que deseen implementarlo. Los protocolos
como el Z39.50 tienen una funcionalidad más completa; por ejemplo, tratan cuestiones como
el manejo de sesiones, gestión de conjuntos de resultados y además permiten la
especificación de predicados para filtrar los resultados obtenidos. Sin embargo, esta
funcionalidad acarrea un incremento en la complejidad de la implementación y, en
consecuencia, de los costes. Por lo tanto, no se trata de reemplazar otras iniciativas, sino

Página 46

Fuentes Abiertas

desarrollar una alternativa que sea fácil de implementar y de desarrollar para propósitos
diferentes de los que ya tratan los sistemas de interoperabilidad existentes.
OAI-PMH utiliza transacciones http (las peticiones se emiten utilizando los métodos GET o
POST) para emitir preguntas y obtener respuestas entre un servidor o archivo y un cliente o
servicio recolector de metadatos. El segundo puede pedir al primero que le envíe metadatos
según determinados criterios como, por ejemplo, la fecha de creación de los datos. En
respuesta el primero devuelve un conjunto de registros en formato XML, incluyendo
identificadores (URLs por ejemplo) de los objetos descritos en cada registro.
La base de Koha es MARC21, pero tiene una variable en la que podemos configurar para
que también sea servidor OAI, es decir, otros recolectores pueden lanzar consultas a Koha y
Koha les devuelve los registros MARC en OAI- DC. Koha no es OAI cliente o recolector, con
lo que no puede lanzar consultas a servidores OAI, pero puede servir sus datos.

Situación BAGE
Relacionado con las búsquedas federadas (Z39.50, SRU/SRW y Pazpar del AT 3), para
federar consultas.
Además como servidor, puede ofrecer los datos bibliográficos a otras bibliotecas / servicios
de consulta.

Como ya se ha explicado con anterioridad, Koha ya tiene desarrollado el servidor OAI, con lo
que es capaz de exportar (para proyectos externos o de catálogo colectivo); el desarrollo
para que Koha sea también cliente no está implementado en la herramienta y podría ser
interesante si se quisiera “federar” con otros recursos (complementar al Pazpar). Pero hay
que tener en cuenta que el protocolo OAI no admite consultas: como mucho puede recuperar
registros entre períodos o fechas concretas, pero no permite la búsqueda por campos
concretos (y para poder federar necesitaríamos almacenar los datos “harvesteados” en otra
Base de datos en Koha). Es decir, el desarrollo supondría:
o Desarrollo y programación de la automatización del recolector
o Mantenimiento para la gestión de los repositorios a “harvestear”
o Modificación de interfaces de búsqueda
Valoración
Es un desarrollo de VALOR AÑADIDO al proyecto porque puede ser utilizado para exportar /
importar registros en un catálogo o integrar distintas fuentes de información, mejorar la
federación de consultas y resultados obtenidos por el usuario.

Página 47

Fuentes Abiertas

Además, pensamos que si la idea es ofrecer un catálogo colectivo, se tiene que pensar,
como ya se ha hecho, en herramientas que sean capaces de gestionar los distintos tipos de
datos y facilitar la consulta.

3.1.4 Administración

A.A.1. Configuración de la moneda
Permite elegir el tipo de moneda en el que se van a realizar tanto las multas como las
adquisiciones con los diferentes proveedores.
En Inicio › Administración › Monedas y Tipo de cambio › Monedas, la moneda que está con el
valor 1.00000 es la que el sistema utiliza como propia aunque en las plantillas, cuando se
visualiza utilice el símbolo del dólar. El resto de monedas tendrá que tener la equivalencia
con la moneda que esté a 1 para que el sistema funcione correctamente.
Situación BAGE
En el módulo Reglas de Préstamo aparece por defecto el $ en la cantidad de la multa.
En este mismo módulo la moneda que se aplicará por defecto será la que tenga la tasa 1. Al
resto de monedas se le debe poner el tipo de cambio actual que tenga frente al €, con lo que
es un tema de visualización. Se pueden modificar las plantillas para que cargue el símbolo
de la moneda del sistema cada vez que se hace referencia a algo económico.
La gestión de monedas está relacionada con AD. 1
Valoración
Consideramos que es un cambio menor, que tiene un grado de desarrollo considerable para
su repercusión que no influye en el funcionamiento de la herramienta, con lo que sería
VALOR AÑADIDO.

Página 48

Fuentes Abiertas

A.A.2. Parametrización básica
Koha, en parámetros básicos, tiene una serie de valores por defecto (plantillas de
catalogación, valores autorizados, palabras vacías, tipos de usuario, etc.)
Situación BAGE
Los parámetros básicos y los valores no se adecuan a las necesidades de la BAGE.
La distribución puede contar con los valores adecuados (traducidos, personalizados…). La
virtualización A.I.3 facilita la existencia de la parametrización básica, puesto que la clonación
supone no tener que parametrizar tantas veces como instalaciones se realicen. Algunas
cuestiones se realizan directamente desde Administración; otras suponen pequeñas
modificaciones de visualización (Ej. Literales MARC21 en castellano, buscadores...)
Valoración
Es una cuestión BÁSICA que requiere, en primer lugar, un análisis y un trabajo de definición
del grupo de trabajo además de las modificaciones pertinentes a nivel base de datos o de
configuración.

A.A.3. Informe
Koha tiene un módulo que permite obtener datos y generar informes ya preconfigurados
sobre la ACTIVIDAD del SISTEMA. También cuenta con un asistente que facilita la
interrogación más detallada al sistema; es lo que se conoce como “informes guiados”.
En los primeros sólo se pueden obtener datos numéricos de acciones / contenido del sistema
(catálogo por tipo de ítem, usuarios por categoría…); en los segundos, se pueden obtener
datos de toda la base de datos MySQL, con un asistente. El asistente necesita que el usuario
confirme lo siguiente:
o El módulo del que quiere obtener la información (catálogo, usuarios…)
o El tipo de informe que desea (tabla..)
o Columnas y datos (entre las tablas del módulo que se ha seleccionado)
o Seleccionar límites (de campos fijos / parámetros básicos como bibliotecas, usuarios..)
o Seleccionar los totales (cálculos que se quieran realizar um, mix, max, avg, count)
o Criterios de ordenación

Página 49

Fuentes Abiertas

Koha no proporciona datos estadísticos del acceso ni uso del OPAC; son estadísticas de
automatización. NO confundir con estadísticas Web (acceso al OPAC, usuarios…)
Situación BAGE
No permite introducir valores variables en las consultas SQL.
En la selección de ‘límites’ se podrían incluir campos textuales.
Se puede proponer además, que permita combinar varios módulos, puesto que, por ejemplo,
en circulación tenemos los datos de los ítems (tabla ítem), pero no la que relaciona con
biblios en MySQL.
El desarrollo puede contemplar lo realizado en las bibliotecas públicas gallegas para esta
función (mencionado en su informe pero no revisado en código).
Valoración
Es un desarrollo que proporciona VALOR AÑADIDO a la herramienta, pero no es básico para
el objetivo de automatización.

3.1.5 OPAC

OP.1 Modificar ficha
Koha muestra distintos datos sobre un registro bibliográfico y los ítems que se le asocian en
la plantilla OPAC DETAIL.
Existen tres vistas para cada registro :
o Etiquetado: con etiquetas (autores, publicado por, año, temas...)
o MARC
o ISBD: Se puede personalizar con la variable ISBD; incluye la puntuación,
los literales, etc.,que se necesiten. Se requieren conocimientos básicos de
HTML.
Situación BAGE
Algunos campos, como el código de barras, no se visualizan en el OPAC.

Página 50

Fuentes Abiertas

En principio, la visualización del código de barras pertenece al trabajo técnico bibliotecario y
no suele ser mostrada en el OPAC. El problema que se plantea en esta cuestión es que
existan ciertos campos que no se visualizan en la ficha. Se trata de que cada biblioteca va a
necesitar visualizar unos campos u otros (ejemplo, el código de barras, la ubicación…).
Todos los aspectos del apartado OPAC hacen referencia a la modificación de plantillas y a
elementos de navegación.
Valoración
Se puede hablar de tres tipos de personalización:
o Básica o personalización gráfica básica: supone mantener la estructura básica que viene
con la herramienta por defecto y modificar los estilos.
o Avanzada: modificación de arquitectura de información básica de Koha y personalización
gráfica. Supone el análisis de las interfaces y la definición de los cambios en la
arquitectura de información.
o Personalización total: inclusión de nuevas funcionalidades y/o modificación de las
existentes.
Para este proyecto, ya se ha comentado la parte gráfica en A.G.4,; como Básico se podría
contemplar la personalización AVANZADA como BÁSICA.
Habrá que tener en cuenta los idiomas, como se ha especificado en A.G.2 por el tema de la
duplicación de directorios.

OP.2 Elementos de navegación
Algunas plantillas de Koha no incluyen elementos de navegación (botones de anterior y
siguiente, migas de pan...); otras incluyen paginados, etc.
Situación BAGE
No existe un enlace “volver”.
En el listado de resultados, no existe un botón de “Siguiente” o “Anterior”, para volver a los
resultados.
Modificar la arquitectura
Valoración
Igual que OP1

Página 51

Fuentes Abiertas

OP.3 Navegación por materias
Koha tiene un buscador de materias en el OPAC que ofrece el listado de resultados con los
siguiente datos:
o Encabezamiento (forma aceptada, referencias, etc., que es un enlace a la ficha MARC
de la autoridad)
o Tipo de encabezamiento (nombre de persona, corporativo, materia…)
o Registros relacionados (enlace a los bibliográficos que lo usan)
o Ver encabezamiento completo (ficha MARC)

Muestra las referencias entre autoridades, pero no tiene en cuenta, por ejemplo, la relación
entre términos aceptados y no aceptados, navegación por equivalencias, etc.)
La variable AuthDisplayHierarchy, dentro de Preferencias del Sistema, activa la utilización
con UNIMARC de la jerarquía en los campos 5XX.
Situación BAGE
Algunas bibliotecas han trabajado mucho la normalización de autoridades, y en el OPAC de
Koha no se “explotan” todas las posibilidades que ofrece.
Se propone:
o Que el buscador de autoridades incluya los términos no usados;
o Que los resultados de autoridad sean un listado de lo aceptado y no
aceptado (como entradas que remitan al término aceptado); lo mismo con
las equivalencias;
o Se podría mostrar el despliegue de encabezamientos utilizando el
subcampos de control y el código correspondiente al despliegue (como
con el caso de UNIMARC y la variable AuthDisplayHierarchy).
Valoración
El trabajo con autoridades y el desarrollo de un sistema de autoridades no se realiza en
muchas bibliotecas, y en las que se realiza, como se indica en AUT.1, se utilizan tesauros;
por esta razón, el desarrollo que supone debe considerarse VALOR AÑADIDO.

Página 52

Fuentes Abiertas

OP.4 Formatos de exportación de registros
Koha, desde la parte pública (OPAC), permite almacenar lotes de registros desde:
o El carrito (lotes por sesión)
o Listas (privada y públicas) creadas por los usuarios
Los formatos en los que se puede exportar son:
o Bibtex
o ISO 2709
o RIS

Desde el registro bibliográfico, en la plantilla OPAC retail,

Existen opciones de descarga de los datos bibliográficos en MODS, Dublin Core, MarcXML,
MARC
Situación BAGE
Se pretende guardar registros en formato ISBD y formato etiquetado.

Supone ampliar la funcionalidad de descarga en el OPAC y mejorarla con otros formatos:
ISBD etc., e incluso integrarlos con Zotero, gestores bibliográficos…
Es necesario implementar transformadores de esos formatos a ISO2709 para que éstos
puedan ser tratados.
Valoración
Consideramos que se trata de un desarrollo de VALOR AÑADIDO, puesto que no es básico
para automatización de centros, sino que es un servicio al usuario de valor agregado.
Además, se puede plantear en la mejora funcional del OPAC, puesto que no influye en el
core (Catalogación, circulación…)

Página 53

Fuentes Abiertas

OP.5. Configuración de buscadores
Koha tiene varias opciones de búsqueda en el OPACsearch.pl para buscar registros
bibliográficos:
o Búsqueda simple;
o Búsqueda por índice o campo concreto;
o Búsqueda avanzada;
Desde la parte de administración no es configurable cuando un campo apunta a un campo
concreto MARC. La relación entre campos de búsqueda y campos MARC en las plantilla
Koha de consulta son:
o CCL Comandos de interrogación utilizado en las plantillas Koha;
o PQF Comandos de interrogación CCl con equivalencia para zebra.
Búsqueda general:
CCL: kw,wrdl,rtrn=a
PQF (Bib-1): @attr 1=1016 @attr 4=6 @attr 5=1 a
Buscar en cualquier campo como lista de palabras con truncamiento a la derecha

Avanzada/índice:
o Palabra clave CCL: kw,wrdl,rtrn=a
Buscar en cualquier campo como lista de palabras con truncamiento a la derecha
o Título CCL: ti,wrdl,rtrn=a
Buscar en campos 240, 243, 245, 246, 247 como lista de palabras con
truncamiento a la derecha
o Tema CCL: su,wrdl,rtrn=a
Buscar en campos 650, 651, 653, 690 como lista de palabras con truncamiento a la derecha
o Autor CCL: au,wrdl,rtrn=a
Buscar en campos 100$a, 700$a como lista de palabras con truncamiento a la derecha
o Idioma CCL: ln,wrdl,rtrn=a
Buscar en campos 041 como lista de palabras con truncamiento a la derecha
o Editor CCL: pb,wrdl,rtrn=a

Página 54

Fuentes Abiertas

Buscar en campos 260$b como lista de palabras con truncamiento a la derecha
o lugar de edición
CCL: pl,wrdl,rtrn=a PQF (Bib-1): @attr 1=59 @attr 4=6 @attr 5=1 a
Buscar en campos 260$a como lista de palabras con truncamiento a la derecha
o ISBN CCL: nb,wrdl= a
PQF (Bib-1): @attr 1=7 @attr 4=6 a
Buscar en campos 020$a como lista de palabras

Más opciones

o Título CCL: ti,wrdl,rtrn=a
Buscar en campos 240, 243, 245, 246, 247 como lista de palabras con truncamiento a la derecha
o frase del título
CCL: (rk=( ti,phr="a"))
Buscar en campos 240, 243, 245, 246, 247 como frase con relevancia
o título de la serie CCL: se,wrdl,rtrn=a
Buscar en campos 440, 490$a como lista de palabras con truncamiento a la derecha
o signatura topográfica CCL: callnum,wrdl,rtrn=a
Buscar en campos 952$o como lista de palabras con truncamiento a la derecha
o tema CCL: su,wrdl,rtrn=a
Buscar en campos 650, 651, 653, 690 como lista de palabras con truncamiento a la derecha
o frase del tema CCL: (rk=( su,phr="a"))
Buscar en campos 650, 651, 653, 690 como frase con relevancia
o autor CCL: au,wrdl,rtrn=a
Buscar en campos 100$a, 700$a como lista de palabras con truncamiento a la derecha
o autor como frase CCL: (rk=( au,phr="a"))
Buscar en campos 100$a, 700$a como frase con relevancia
o nombre de la institución CCL: cpn,wrdl,rtrn=a
PQF (Bib-1): @attr 1=Corporate-name @attr 4=6 @attr 5=1 a

Página 55

Fuentes Abiertas

o nombre de conferencia CCL: cfn,wrdl,rtrn=a
PQF (Bib-1): @attr 1=Conference-name @attr 4=6 @attr 5=1 a
o frase de nombre de conferencia CCL: (rk=( cfn,phr="a"))
PQF (Bib-1): @attr 1=Conference-name @attr 4=1 @attr 2=102 a
o nombre personal CCL: pn,wrdl,rtrn=a
PQF (Bib-1): @attr 1=Personal-name @attr 4=6 @attr 5=1 a
o frase de nombre de personal CCL: (rk=( pn,phr="a"))
PQF (Bib-1): @attr 1=Personal-name @attr 4=1 @attr 2=102 a
o idioman CCL: ln,wrdl,rtrn=a
Buscar en campos 041 como lista de palabras con truncamiento a la derecha
o notas/comentarios CCL: nt,wrdl,rtrn=a
Buscar en campos 500, 505, 590, 952$z como lista de palabras con
truncamiento a la derecha
o editor CCL: pb,wrdl,rtrn=a
Buscar en campos 260$b como lista de palabras con truncamiento a la derecha
o lugar de edición CCL: pl,wrdl,rtrn=a
Buscar en campos 260$a como lista de palabras con truncamiento a la derecha
o número estándar CCL: sn,wrdl,rtrn=a
Buscar en campos 999$c como lista de palabras con truncamiento a la derecha
o ISBN CCL: nb,wrdl= a
o ISBN CCL: ns,wrdl= a
o Signatura topográfica CCL: (rk=( lcn,phr="a"))
Buscar en campos 952$o como frase con relevancia

Página 56

Fuentes Abiertas

En la Intranet el funcionamiento es el mismo, pero amplía la búsqueda al repositorio
(registros de lotes incluidos, pero no importados)
Situación BAGE
Se desconoce contra qué campos busca el autor, y podría ser interesante poder configurar
los campos de búsqueda por políticas de catalogación (por ejemplo, límite por fecha en el
008 o en el 260).
Se podría proponer una configuración de buscadores en preferencias del sistema.
Valoración
Es un desarrollo de VALOR AÑADIDO en el OPAC, y en la Intranet puede resultar
RELEVANTE, aunque habría que definir prioridades para la búsqueda y gestión por lotes de
los registros.

OP.6 Funcionalidades en la Home en OPAC
La Home por defecto es muy simple, pero muy configurable con textos (LibraryName,
OPACcredits, OPACheader, OPACMainUserBlock, OPACNav) o con funcionalidad
(OPACHighlightedWord, OPACCloud,OPACAuthorities, OPACbookbag...). Sin embargo, es
cierto que desde el punto de vista gráfico, sería acertado incluir recursos más visuales.
Además, la edición de los textos exige conocimientos mínimos de HTML para que
gráficamente la imagen no se perjudique al editar las variables.

Situación BAGE
Necesidad de personalización del OPAC (aunque se comparta imagen, poder incluir textos y
funcionalidades de forma independiente). Por ejemplo, una biblioteca puede querer nube de
Tags y otra no.
Manteniendo la misma filosofía de Koha incluir variables que permitan:

o Incluir Novedades en la Home
o Destacar las listas de recomendaciones (listas)
o Incluir fichas más visitadas
o Enlaces a las búsquedas más frecuentes
o Edición mejorada de noticias (imágenes, textos, enlaces)

Página 57

Fuentes Abiertas

Valoración
La necesidad de personalizar y adecuar a las necesidades y características de cada
biblioteca hace que podamos considerar como RELEVANTE este tipo de desarrollos que, sin
perder la visión de desarrollo global, permite personalización y apariencia muy distinta con la
funcionalidad que se adecue al servicio.
Será necesaria la definición de las cuestiones a incluir.

OP.7 Inclusión desarrollos bibliotecas de Galicia
Esta cuestión la incluimos como OPAC porque afecta a la funcionalidad OPAC y porque fue
incluida en un informe de las bibliotecas gallegas. Además, pueden estar relacionadas con
otros aspectos de ‘desarrollo’.
Situación BAGE
Enumeración de requisitos / desarrollos realizados por las bibliotecas gallegas:
o Enriquecimiento bibliográfico: captura y visualización de contenidos de
DILVE;
o Facetas:
 Posibilidad de generar facetas con todos los campos/subcampos
MARC21
 Enlace con “valores autorizados”: sustituye los códigos (de lengua, por
ejemplo) por el texto en la lengua de consulta (la que se elija para
visualizar OPAC... por ejemplo, gallego o castellano)
 Multilenguaje en valores autorizados: por ejemplo en las facetas AG
o Gestión de la exploración jerárquica: AUT1
 por lenguaje de clasificación: CDU+
 por centros de interés, previo mapeado entre el lenguaje de
clasificación utilizado y los centros de interés que creemos
 por cualquier 6XX
o Navegación en estantería por todos los subcampos de fondos, en el orden
que corresponde;
o Listas: creación de una nueva lista visible para todos y modificable
únicamente por todos los administradores de las distintas bibliotecas que
comparten base de datos;
o Búsqueda avanzada: sustitución del “framework” como limitador por “tipo

Página 58

Fuentes Abiertas

de material” OP5
Tras la revisión de lo desarrollado y de algunas de las peticiones que se han realizado y se
recogen en este informe, será necesario:
o Análisis (de código, versiones y funcionalidad)
o Revisar el desarrollo y adecuarlo a la versión sobre la que trabajemos
o Reutilizar código y desarrollar

Algunas de las cuestiones que se plantean son muy sencillas y otras son susceptibles de ser
solucionadas en futuras versiones Koha.

Valoración
Puesto que son desarrollos ya realizados, y muchos hacen referencia a las funcionalidades
de OPAC (que se ha contemplado modificar) consideramos como RELEVANTE su
desarrollo.

3.1.6 Circulación

CI.1 Reservas
Koha permite la reserva de ejemplares mediante la variable RequestOnOPAC, pero además
permite configurar:
o El número máximo de reservas
o El trabajo independiente de bibliotecas
o El tiempo máximo de duración de una reservas
o Si se permite la reserva de una copia específica o no
Independientemente, si no hay reglas de circulación definidas, no se podrán realizar
reservas.
En la versión 3. 06 se definen políticas de reservas.

Situación BAGE
El sistema indica que no hay copias disponibles para realizar una reserva.

Página 59

Fuentes Abiertas

Como Koha no permite hacer reservas si no hay una política de circulación definida para el
tipo de ítem, existen otras cuestiones que pueden mejorarse en las reservas, como definir
políticas de reserva por tipo de ítem, tipo de usuario y biblioteca; y también los parámetros de
circulación.
Valoración
Se trata de un desarrollo de VALOR AÑADIDO, puesto que puede llegar a ser muy
específico.

CI.2 Historial de préstamo
Koha permite guardar o no el historial de lectura mediante las variables
Intranetreadinghistory, OPACreadinghistory y ReadingHistory.
Situación BAGE
Almacenamiento de datos de histórico de préstamo.
Cada biblioteca tendrá unas necesidades y unos flujos de trabajo en lo que respecta al
cumplimiento con la legislación relacionada con la protección de datos de carácter personal.
Koha permite visualizarlo o no.
El uso de esta información no sólo está relacionada con que se pueda o no visualizar; donde
realmente gana valor es en el conocimiento del usuario que podemos tener para mejorar los
servicios (qué autores o temas le gustan, qué frecuencia de uso hace de los recursos…) y
personalizarlos cada vez más.
Valoración
Como se trata de una responsabilidad de cada institución y el desarrollo ya está realizado en
la herramienta, lo consideramos independiente del proyecto. De todos modos, podría
mejorarse y proporcionarle VALOR AÑADIDO si el usuario pudiera editar y borrar su historial.
La información sobre el uso de los datos del usuario es del momento del alta del usuario y
está relacionada con las políticas de creación de usuarios.

Página 60

Fuentes Abiertas

CI.3 Préstamo interbibliotecario
Koha no trabaja el préstamo interbibliotecario de una forma aislada al préstamo normal.
Existen dos formas de realizar préstamo interbibliotecario:
- Cuando la biblioteca a la que le presto es un usuario tipo institución: se guarda el historial
de préstamo como con cualquier usuario
- Cuando la biblioteca es una sucursal o biblioteca en la misma instancia Koha, se realizan
transferencias entre ellas; en este caso no se guarda el historial.
Situación BAGE
No existe historial para préstamo interbibliotecario.
Está muy relacionado con NCIP, ILL y se está trabajando en préstamo interbibliotecario en la
versión 3.4.
Valoración
Es RELEVANTE, aunque no sea un desarrollo inicial, pues al estar trabajando también en el
catálogo colectivo se ha de tener en cuenta.

3.1.7 Catalogación

CAT.1 Mejoras en la edición de registros MARC
Koha permite la edición de plantillas o “frameworks” con los campos y subcampos MARC21
que el usuario necesite, y en addbiblio.pl o en addauthority.pl se despliega todo el contenido
de la plantilla.

En algunos campos (los que están relacionados con plug in) no se pueden configurar ni
valores por defecto, ni modificarlos en función de las plantillas o tipos de material.
Situación BAGE
Respecto a la edición de registros MARC (autoridad y bibliográfico) las cuestiones que se
han ido mencionando, es decir:
1. Modificar el registro de autoridad desde el registro bibliográfico

Página 61

Fuentes Abiertas

2. La búsqueda por autoridades no devolvía ningún resultado (tanto en catalogación
como en OPAC)
3. Ayuda y texto para los indicadores del MARC
4. Algunos campos del MARC deben tener valores fijos (008, 040,…)
5. Reducción y personalización de plantillas
6. Duplicar campos y subcampos (han tenido problemas con el 260 y los subcampos)

Siempre teniendo en cuenta la filosofía y parametrización de Koha y sabiendo que las
políticas y necesidades para catalogación pueden ser muy variadas, (bibliotecas que dedican
gran esfuerzo a normalización de autoridades y a catalogación y otras que con importar
registros desde el Z39.50 es suficiente), se pueden mejorar las cuestiones que ya contempla
la aplicación:
o Koha permite crear la autoridad desde el registro bibliográfico, siempre que la
variable BiblioAddsAuthorities esté activada dentro de Preferencias del Sistema

o Solucionar Bug en la búsqueda de autoridades, ya que realiza la búsqueda contra
una etiqueta CCL que no existe. Se cambia en el módulo de búsqueda de
autoridades la etiqueta CCL inexistente por otra que sí existe. Además, se mejora
la búsqueda añadiendo que realice truncamiento por la izquierda (por defecto,
solamente lo hace por la derecha)
o Se podría incluir ayuda de indicadores en un plug-in
o Edición y creación de plugins por parte del usuario
o Facilitar la carga de plantillas de catalogación externas
Valoración
Se puede plantear como BÁSICO incluir la catalogación con opciones avanzadas como las
que plantean, pero no renunciar a la catalogación que ya ofrece Koha por defecto, e incluso,
hacer una más simplificada.

Página 62

Fuentes Abiertas

3.1.8 Autoridades

AUT.1 Gestión de tesauros
Koha, como SIGB, desarrolla funcionalidades para la gestión y control de autoridades, pero
no para la gestión de tesauros.
Como ya se ha comentado en otros apartados, se puede implementar la jerarquía que prevé
el formato MARC21.
Pero existen experiencias de integración mediante Web services de tesauros externos (David
Lubin Memorial Library2)
Situación BAGE
Existen bibliotecas que utilizan tesauros como vocabulario normalizado en aplicaciones
desarrolladas ad hoc o en las que utilizan Isis.
Podemos plantear dos soluciones:
o Integrarlo mediante Web services (ajeno a Koha)
o Integrar una herramienta o plug-in para que se gestionara desde Koha y mantener
autoridades y descriptores
Valoración
Es un desarrollo que se plantea como VALOR AÑADIDO, puesto que no todas las bibliotecas
lo utilizan y supone, inicialmente, una separación de la filosofía de la herramienta en la que
se debería implicar a la comunidad.

AUT. 2 Autoridades multilingües
MARC21 de registros de autoridad (7XX) permite la inserción de autoridades multilingües
(nombres equivalentes en tesauros en idiomas múltiples, por lo que este tipo de registros
puede incluirse en Koha. Por lo tanto, en la búsqueda de autoridad, como en el caso de las
jerarquías de AUT, podrían mostrarse los términos equivalentes. Sin embargo, hay que tener
en cuenta que, como se ha comentado a nivel de traducción, en Koha sólo están traducidas
las plantillas, a nivel de etiquetas, con lo que no hace una gestión de idiomas de autoridades.

2
http://www.librarytechnology.org/ltg-displaytext.pl?RC=14765
Página 63

Fuentes Abiertas

Situación BAGE
Se plantea la posibilidad de contar con autoridades multilingües.
En la línea de trabajo con MARC 21 (por normalización y por ser base de Koha) se podría
realizar un desarrollo en dos fases:
1. Búsqueda por autoridad: permitir la navegación con los trazados de véase, véase
además, términos equivalentes…, con lo que simplemente se modificarían las
interfaces de las autoridades (equivalente al desarrollo de la biblioteca virtual del
patrimonio)
2. Gestión global de las autoridades en el/los idiomas correspondientes, aunque sería
necesario:
o Establecer algún tipo de convención que permitiera identificar la fuente / idioma de
la autoridad (no hay en MARC 21 un subcampo ni un indicador para que Koha
pueda identificar el idioma del registro de autoridad para mostrarlo)
o Generar una variable que permitiera visualizar el término equivalente en el idioma
de la plantilla
o Modificar buscadores e indizar en los registros los términos equivalentes
Valoración

Es un desarrollo que debemos tener muy en cuenta y que está relacionado con la
navegación por materias que ya ha sido repasada. Se podría incluir como RELEVANTE la
parte de gestión de autoridades relacionada con la gestión de idiomas A.G. 5 y la traducción
A.G. 2

3.1.9 Adquisiciones

AD.1 Gestión de monedas
Koha permite definir el uso de varias monedas y de sus equivalencias. Desde Administración
> Parámetros básicos > Monedas y tipo de cambio, se indica como unidad la moneda con la
que queremos trabajar (la que tiene la conversión valor 1); el resto deben ser calculadas en
función de la moneda básica.

Página 64

Fuentes Abiertas

Situación BAGE
1. La configuración por defecto contempla los presupuestos en dólares.
2. La conversión de la moneda debería ir unido a una fecha de pedido.
El valor de las distintas monedas varía, con lo que podemos encontrarnos distintos valores
de un documento: desde el pedido hasta la recepción y/o pago del mismo.
Como no es objeto de un SIGB la contabilidad, realizar un desarrollo de actualización
automática de valores, etc. es una opción muy avanzada. Entendemos que con realizar
alguna modificación y poder insertar/actualizar el precio sería suficiente.
Valoración
Se trata de un desarrollo de valor añadido, puesto que:
- los casos en los que se utilicen varias monedas serán muy reducidos;
- para la gestión de las compras, muchas bibliotecas o instituciones necesitan
utilizar otras herramientas corporativas.

AD.2 Integración con herramientas de gestión de compras
Koha tiene un módulo de adquisiciones y carece de API para que se pueda conectar alguna
herramienta externa de gestión de compras.
Situación BAGE
Se plantea la conexión de Koha con softwares de gestión de compras que se usan en los
ministerios.
Se podría desarrollar de forma específica un XML-RPC para conectar Koha con otras
herramientas que fueran capaces de pasar los datos básicos que pide Koha para crear un
registro.
Valoración
Habría que valorar la forma de trabajo de cada biblioteca. Es un desarrollo de “valor
añadido”, en la que es necesario saber si el flujo de compras corresponde con el definido en
Koha (compras, sugerencias de compra…)

Página 65

Fuentes Abiertas

AD.3 Historial de compras
Koha no muestra un histórico de compras por proveedor, ni por biblioteca, ni por
presupuesto. Se hace la gestión de las compras una vez se reciben los ítems de un pedido;
no podemos recuperar la información en este sentido.
Situación BAGE
El historial de ‘comprar’ sería útil para poder realizar consultas y ver qué has
pedido/comprado para volver a hacer la compra, o para no hacer de nuevo el pedido.

Es posible comprar a través de un registro bibliográfico existente o hacer una búsqueda en el
catálogo. Contamos con la experiencia de las bibliotecas gallegas, en las que ya se han
desarrollado una búsqueda conjunta para el catálogo y los pedidos. También han conectado
con DILVE (para dar de alta a proveedores). Habría que hacer una evaluación y adaptación
a la versión correspondiente.
Valoración
Sería una parametrización de valor añadido, ya que no sería utilizado por todas las
bibliotecas. Supone la modificación de la gestión del proveedor y también de los pedidos
(porque sólo se contempla su gestión mientras el pedido no está recibido; una vez recibido
Koha no lo gestiona).

AD.4 Integración publicaciones seriadas / adquisiciones
Adquisiciones y publicaciones periódicas son módulos independientes en Koha. Su única
relación son los proveedores.
Situación BAGE
Las publicaciones periódicas y suscripciones deben estar reflejadas en el control
presupuestario y relacionadas con las adquisiciones.
Para no modificar el funcionamiento de seriadas (teniendo en cuenta que está relacionado
con MARC Holdings), simplemente sería cuestión de añadir a la gestión de la suscripción el
presupuesto y tenerlo en cuenta en renovaciones de suscripciones y en la administración de
presupuestos.

Página 66

Fuentes Abiertas

Valoración
Sería una parametrización de valor añadido, igual que el resto del módulo adquisiciones.

3.1.10 Publicaciones periódicas

P.P.1 Suscripciones: control de ejemplares
Una suscripción en Koha es la relación entre un proveedor y un registro bibliográfico en base
a un período de tiempo o un número de ejemplares, según periodicidad establecida.
Mientras una suscripción está abierta muestra el historial de la suscripción (números
recibidos, números pendientes de recibir, biblioteca que los recibe, etc. NO INCLUYE
COMO ÍTEMS LOS EJEMPLARES RECIBIDOS si no se lo indicas en la suscripción.
Cuando se elimina la suscripción, los datos de la suscripción se pierden y puede ser que,
bien no permanece ningún ítem (al haber seleccionado la opción de que no cree ítem cada
vez que se recibe uno); o bien se convierten en ítems independientes (al haber seleccionado
la opción de que cree ítem cada vez que se recibe uno), pero se pierden datos del ejemplar
como numeración de la revista.
Situación BAGE
Al cerrar la suscripción a una publicación periódica perdemos toda la información del historial
porque se convierten en ítems independientes.
Con el mapeo que ya existe entre la base de datos de Koha y MARC21 Holdings (AT1), se
podría incluir como parámetro en la gestión de periódicas que se utilice o no MARC21
Holdings para no perder nada de información y mejorar las funcionalidades.
Valoración
El desarrollo para MARC21 se ha considerado Básico y está totalmente relacionado con este
apartado, con lo que este desarrollo debería ser incluido como RELEVANTE, puesto que no
todas las bibliotecas harán uso del módulo de publicaciones periódicas.

Página 67

Fuentes Abiertas

P.P.2 Descripción de suscripciones
La traducción y el flujo de descripción y gestión de suscripciones no es claro.
Situación BAGE
En las prácticas realizadas ha habido confusión entre ciertos campos, sobre todo fechas,
inicio, fin de la suscripción… Se plantean dudas a la hora de parametrizar la suscripción a
una revista, se deben incluir conceptos de periodicidad y ampliar la flexibilidad de la gestión.
Se trata de revisar toda la interfaz de gestión e incluir el desarrollo con el P.P. 1
Valoración
Se incluye en el RELEVANTE del PP1.

P.P.3 Recepción en lote
Koha no permite recibir ejemplares en lote. Se debe recibir el anterior para poder recibir el
siguiente.
Situación BAGE
Se pretende recibir ejemplares en lote para gestionar colecciones como hace Absys.
La recepción de ejemplares en lote se asocia a la catalogación retrospectiva.
Se debe valorar si es necesario introducir los ejemplares directamente en la bbdd para no
introducir la historia de la suscripción a mano. Lo ideal sería recibirlos en lote para ahorrar
tiempo. La migración sería para el control de la colección, no para el control de la suscripción
con una extensión para gestionar colecciones.
Valoración
En primer lugar, se debe valorar el uso que se realiza del módulo porque tienen que realizar
catalogación retrospectiva de seriadas; por esta razón el desarrollo es de VALOR AÑADIDO.

Página 68

Evaluación de Koha para las bibliotecas de la Adminsitración General del Estado
Requisitos BAGE

3.2 Resumen e identificación de requisitos

En este documento pretendemos recoger e identificar los requisitos que debe cumplir Koha, así
como los desarrollos y la estimación pertinente para la distribución en la que trabajará el
Ministerio de Cultura y que se ofrecerá a las BAGE.

Ya se ha mencionado a lo largo de este documento pero cabe destacar que los aspectos más
importantes de los documentos y trabajos anteriores a este informe son:

o Bajo nivel de automatización de las BAGE
o Gran heterogeneidad de bibliotecas, técnicos, sistemas, formatos,
necesidades
o Análisis de SIGB de código abierto
o Creación del grupo de trabajo (de expertos bibliotecarios) para la evaluación
de Koha como SIBG base del desarrollo con el objetivo de identificar y
analizar carencias

Todo lo mencionado en el apartado anterior recoge el detalle de la actividad del grupo, pero
permite resumir por un lado, las necesidades a nivel global y los requisitos detallados. Este
documento no pretende ser el análisis del desarrollo, pero sí encauzar o ser el marco en el que
se trabajará en futuras fases de desarrollo y mejora o actualización.

A nivel global, y a falta de matices que puntualizamos en detalle de requisitos, las cuestiones
en las que Koha resulta un SIGB adecuado como base de desarrollo o mejora son:

o Escalabilidad: Koha utiliza dos bases de datos y es capaz de manejar un
gran número de registros para dar respuesta a cualquier necesidad o tamaño
de biblioteca
o Estándares bibliotecarios
o Flexibilidad y personalización
o Comunidad e implantación en España

A nivel detalle para cada uno de los módulos, hemos creado una tabla resumen, de la que se
desprende que las cuestiones básicas hacen referencia tanto a la aplicación en sí misma como
Página 69

Requisitos BAGE

a la preparación que ésta necesita para que la usen las bibliotecas de la AGE que lo
necesiten. Es decir, se hace también referencia al SERVICIO o al nivel de personalización que
las bibliotecas van a necesitar para empezar con la tarea de automatización de una forma más
o menos sencilla.

Como ya se ha mencionado en otros apartados de este informe, desde el punto de vista de la
necesidad o viabilidad de las funcionalidades y desarrollos, hemos establecido cuatro niveles
(INDEPENDIENTE, BÁSICO, RELEVANTE y VALOR AÑADIDO); pero a la hora de seleccionar
los requisitos y desde el punto de vista del alcance del proyecto, es necesario también añadir
otros tres niveles o clases de desarrollos, puesto que deberán ser analizados de forma distinta
en el desarrollo del proyecto. Éstos son:

o APLICACIÓN: desarrollo de aplicación, es decir, todo lo que Koha no cumple
y que, por ser básico, relevante o valor añadido debemos tener en cuenta en
el desarrollo de la distribución (Ej. desarrollo para todos los formatos
MARC21) para los que tendremos que tener muy en cuenta la filosofía
dinámica y evolución de Koha como herramienta y proyecto.
o PROYECTO GLOBAL: desarrollo o despliegue de proyecto, es decir, las
cuestiones a realizar para que el Ministerio de Cultura pueda ofrecer esa
aplicación a las bibliotecas que lo requieran de la forma más sencilla posible
(Ej. virtualización, parametrización básica…), para las que tendremos que
tener en cuenta el desarrollo, servicio o convenio que se instaurará entre las
bibliotecas participantes y los coordinadores del proyecto.
o PROYECTOS INDIVIDUALES: desarrollo para el despliegue en un entorno
concreto (integración LDAP, integración con un tesauro concreto que usa
una institución concreta, migración…), que, desde nuestro punto de vista, no
deberíamos tener en cuenta por ser muy específico y por resultar inviable
encontrar una solución global para todos.

Siguiendo estos tres niveles de alcance definidos, mostramos un resumen de todas las
cuestiones mencionadas en el apartado anterior para visualizarlo de la forma más sencilla:

Página 70

Requisitos BAGE

Aspectos independientes
Relación de cuestiones independientes al proyecto o inherentes a Koha a las que habrá que adaptar los entornos o las necesidades;
como se puede comprobar, la mayoría hacen también referencia a proyectos individuales y a casuística muy concreta.

Código Nombre Descripción Nivel Implicaciones/cuestiones destacadas Alcance
Entorno de
A.G. 1 Trabajo Aplicación 100 % Web Independiente Es inherente a Koha.
Implicación en la Se desconoce la naturaleza de los datos que deberán ser Proyecto
A.G. 7 Migraciones migración de registros Independiente migrados a Koha, con lo que la solución debe ser individual. individual
En Koha se definen los servidores (puertos, nombres de las
bases de datos, direcciones de los servidores…) pero no se
gestionan los permisos de salida. El departamento de
Conectividad y Puertos para el protocolo sistemas de cada institución tendrá que dar permiso a los Proyecto
A.I. 1 accesos Z39.50 Independiente puertos indicados. individual
La elección del navegador no es de Koha, sino que depende
de la política institucional. Como se va a trabajar en la
mejora de la navegación de las plantillas de OPAC, se puede
Koha optimizado para incluir como básico la optimización de las plantillas OPAC
A.I. 2 Navegadores Firefox Independiente para Firefox e IE 7 o superior. Proyecto BAGE
Es de implantación -no de desarrollo-. Se podrían incluir,
Seguridad como en el caso de la virtualización, los puertos fijos de Proyecto
A.I. 4 Informática Accesos desde el exterior Independiente conexión. individual
Individualmente tendrán que seleccionar la mejor forma de Proyecto
A.T. 2 Formatos MARC MARC21 y UNIMARC Independiente conversión individual
Interno de cada institución, puede mejorarse en información
Historiales de Incluido y parametrizable al usuario, firma de cesión, etc… capacidad del usuario para Proyecto
CI.2 Préstamo en Koha Independiente "editar"/mostrar sus datos individual

Aspectos de proyecto BAGE

Página 71

Requisitos BAGE

Relación de cuestiones que son independientes de Koha y suponen desarrollo y dedicación para poner en marcha el proyecto y facilitar
la automatización de las BAGE en la medida de lo posible. Como se puede comprobar, la mayoría hacen también referencia a cuestiones
básicas en cuanto a desarrollo. Son cuestiones que están vinculadas a la funcionalidad y necesidades del proyecto, pero no son
cuestiones relacionadas con Koha como SIGB.

No hace referencia ni a arquitectura de
información ni a funcionalidad, -únicamente a
cambio de imagen-. Se considera relevante
ampliar funcionalidad para que cada biblioteca
Diseño pueda personalizar (por ejemplo, actualizar
A.G. 4 Web/imagen CSS (personalización gráfica) Básico logos) Proyecto BAGE
No hace referencia a ningún módulo de la
herramienta en concreto, sino a la forma de
plantear el proyecto y desarrollar puesto que, en
muchas ocasiones al desviarnos del core de la
Versiones, herramienta, no podremos actualizar ni migrar
desarrollo, Estrategias de desarrollo y de versión sin tener muy claro qué es lo que
A.G. 6 actualizaciones migración Básico hemos incluido. Proyecto BAGE
La elección del navegador no es de Koha, sino
que depende de la política institucional. Como
se va a trabajar en la mejora de la navegación
de las plantillas de OPAC, se puede incluir como
básico, la optimización de las plantillas OPAC
A.I. 2 Navegadores Koha optimizado para Firefox Independiente para Firefox e IE 7 o superior. Proyecto BAGE
Arquitectura Componentes y necesidades Virtualización incluyendo otros conceptos
A.I. 3 tecnológica Koha Básico básicos (parametrización, desarrollos…) Proyecto BAGE
Inclusión de cuestiones básicas como MARC en
Parametrización castellano, preferencias del sistema en
A.A. 2 básica Parámetros y configuración Básico castellano, tipos de ítem, reglas de circulación… Proyecto BAGE
Modificación de arquitectura de información
Modificar OPAC básica de Koha y personalización gráfica.
OP. 1 DETAIL Modificación de plantillas Relevante Supone el análisis de las interfaces y la Proyecto BAGE
Página 72

Requisitos BAGE

definición de los cambios en la arquitectura de
información.

Relacionado con OP1. Modificación sencilla de
plantillas para mejorar la nevegación
Elementos de (paginados, botones anterior siguiente y
OP. 2 navegación Modificación de plantillas Básico breadcrums) Proyecto BAGE

La modificación de la arquitectura de información se considera relevante puesto que sería interesante mejorar no sólo la funcionalidad,
sino también la identidad de la aplicación; sin embargo y lógicamente no es un elemento básico para que el proyecto se ponga en
marcha. Sí que se incluyen como básicos algunos aspectos de navegación como paginados, botones, o migas de pan para ayudar al
usuario a navegar por el OPAC.)

Aspectos de Aplicación
Relación de cuestiones que Koha no contempla o contempla de una forma diferente a las necesidades detectadas. Lógicamente
suponen desarrollo para poner en marcha el proyecto, pero también suponen revisión y definición de la herramienta y la comunidad,
futuras versiones, incorporación de desarrollos realizados por otras instituciones, etc. Las incluimos en tres tablas diferentes según la
necesidad de desarrollo.
Básicos a desarrollar


Funcionamiento interno Koha y Bugs de duplicidad de
directorios. EN y ES son directorios ya muy trabajados. El
Mejora del sistema de resto de idiomas oficiales en España no lo están tanto. Se
traducción de plantillas (idiomas requerirán esfuerzos de traducción. Si se modifican plantillas
A.G. 2 Traducción Estado) Básico hay que revisar la traducción en todos los directorios. Aplicación

Página 73

Requisitos BAGE

Sobre todo Bibliográfico/autoridad/fondos. Relacionado con
A.T. 1 Familia MARC21 Gestión de formatos MARC Básico PP1 Aplicación
Ejemplares, registros bibliográficos, exportación/importación
A.T. 4 Repositorio gestion de objetos digitales Básico registros-objetos relacionados Aplicación
mejoras edición edición de registros MARC
de registros relacionados (biblios y
CAT. 1 MARC autoridades) Básico Catalogación y autoridades Aplicación

Relevantes

Código Nombre Descripción Nivel Implicaciones/cuestiones destacadas alcance
Parámetros básicos, preferencias del sistema. Los
desarrollos relacionados con autoridades
multilingües e indexación y buscadores (AUT2)
A.G. 5 Multilingüismo Gestión de idiomas Relevante serían valor añadido. Aplicación
Mejorar la funcionalidad de búsqueda y
recuperación a través del Z39.50 relacionado con la
inserción de un registro (mejorando el formulario, la
muestra de resultados, etc…) pero consideraríamos
VALOR AÑADIDO el desarrollo para incluir o
Búsquedas como cliente (Koha es descargar registros en lotes como nueva
A.T. 5 Z 39.50 cliente y servidor Z 39.50) Relevante funcionalidad del módulo de catalogación en Koha. Aplicación
Además de ser relevante para el proyecto de punto
Consorcio o redes /autenticación de consulta único y la Investigación en Koha
A.T. 6 NCIP /autopréstamo Relevante Community Aplicación
Funcionalidades en la Mejorar el atractivo y servicios de la
OP. 6 Home Home Relevante Seguir la filosofía de contenido mejorado en OPAC Aplicación
Inclusión desarrollos Bibliotecas de Hay que tener en cuenta versiones y formas de
OP. 7 Mejoras Xercode Galicia relativos a OPAC Relevante desarrollo; si no, contamos con su análisis. Aplicación
No es desarrollo inicialmente, pero es una apuesta
para futuras versiones en la comunidad y sobre
Préstamo (historial de préstamo, instituciones todo para el proyecto del catálogo colectivo con
CI.3 interbibliotecario como usuario) Relevante protocolos como el NCIP Aplicación

Página 74

Requisitos BAGE

Incluir la gestión de tesauros en Koha
(variable que active los tesauros) o Incluir tesauros y armonizar con el control y gestión
AUT.1 Tesauros integración con herramienta externa Relevante de autoridades Aplicación
Tratamiento, gestión y visualización Relacionado con OP3, la opción más avanzada
Autoridades de autoridades en distintos idiomas relacionada con la gestión multi-idioma (A.G.) sería
AUT.2 multilingües (según plantillas de OPAC…) Relevante considerada VALOR AÑADIDO Aplicación
gestión de fondos (ítems) en
P.P. 1 Suscripción- ítems suscripciones Relevante Relacionado con AT1 Aplicación
datos de descripción,
edición de campos
P.P. 2 descriptivos Fechas, personalizar periodicidades.. Relevante Relacionado con PP1 Aplicación
Hay que tener en cuenta que en proyectos
generación automática de concretos pueden necesitar integración LDAP o
A.I. 6 Contraseñas contraseñas Básico similar Aplicación

Valor añadido (cuestiones que se ofrecen valor añadido al proyecto; algunas no tienen un amplio alcance en cuanto a desarrollo y
pueden ser incluidas en la primera fase o desarrollo inicial del proyecto o pueden ir incorporándose a medida que vaya creciendo el
proyecto).

Gestión independiente Análisis de la situación e independencia real de las
de bibliotecas en ciertos bibliotecas de la AGE que realmente lo necesiten. Koha ya
aspectos (catalogación, contempla algunas cuestiones de trabajo independiente en
adquisiciones, bibliotecas con la misma instancia Koha; convendría
circulación, OPAC) con revisar el concepto Grupo de bibliotecas con el que trabaja
A.G. 3 Creación de dominios una única instancia Koha Valor añadido Koha. Aplicación
Mejora del rendimiento
en las búsquedas Pazpar o modoperl para
A.I. 5 (modoperl) consultas federadas Valor añadido Aplicación
Pazpar ya está incluido en Koha y se puede desarrollar el
Incluir otros servidores y mantenimiento para gestionarlo. Contamos con la
A.T. 3 Búsquedas federadas puntos de consulta Valor añadido experiencia de las bibliotecas gallegas. Aplicación

Página 75

Requisitos BAGE

Koha es servidor OAI no Desarrollar el cliente OAI Relacionado con Búsquedas
A.T. 7 OAI cliente Valor añadido federadas (AT3) como complemento a Pazpar. Aplicación

Si se tienen claro los valores de los cambios las etiquetas
en plantillas no afectan al funcionamiento de Koha. Incluir
funcionalidad para que actualice o no valores según
Configuración de la conversión en cada momento del flujo del pedido, es una
moneda y etiquetas de cuestión de valor añadido puesto que no todas las
A.A. 1 Moneda valores económicos Valor añadido bibliotecas lo van a utilizar. Relacionado con AD1. Aplicación
Desarrollo para mejorar la capacidad de interrogar al
Informes / datos sistema y obtener datos estadísticos. NO confundir con
A.A. 3 estadísticos Generación de informes Valor añadido estadísticas Web (acceso al OPAC, usuarios…) Aplicación
Navegación por Jerarquía entre Basando en las relaciones de jerarquía de MARC
OP. 3 materias autoridades Valor añadido visualizar y convertir en navegable el registro de autoridad. Aplicación
Formatos de Funcionalidad de
exportación de exportar registros en Se puede plantear en la mejora funcional del OPAC
OP. 4 registros OPAC Valor añadido (OP1) Aplicación
Configurar la indexación Reindexación de base de datos. Tal vez conviene reducir
Configuración de y campos para los la funcionalidad al contenido del campo que esté indexado
OP. 5 buscadores buscadores Valor añadido por defecto. Aplicación
Ampliar funcionalidad
para que se pueda
definir a un nivel muy
específico la política de (relacionado con tipos de usuarios, bibliotecas, tipos de
CI.1 Sistema de Reservas reservas Valor añadido ítem...) Aplicación

Todas las plantillas utilizan el símbolo del dólar para
Visualización del indicar que se trata de un campo cuyo valor es económico.
etiquetado $- Se podría modificar en función de la moneda. Cambios o
Actualización de valores modificaciones en los valores y la equivalencia de las
Gestión de distintas de monedas y aspectos monedas mientras un pedido está abierto. Relacionado en
AD. 1 monedas relacionados Valor añadido Administración en la configuración de la moneda. Aplicación

Página 76

Requisitos BAGE


Supone la modificación de la gestión del proveedor y
Almacenamiento y también de los pedidos (porque sólo se contempla su
gestión de los pedidos gestión mientras el pedido no está recibido, una vez
AD. 3 Historial de compra realizados Valor añadido recibido Koha no lo gestiona) Aplicación
Relación entre
publicaciones Incluir publicaciones
periódicas y las periódicas en la gestión Modificación de ambos módulos y de la administración del
AD. 4 adquisiciones. de las adquisiciones Valor añadido sistema en la configuración de presupuestos Aplicación
Recepción de Permitir la catalogación
P.P. 3 ejemplares en lote de retrospectiva Valor añadido No es control de suscripciones, sino control de colecciones Aplicación

Página 77

Requisitos BAGE

4 Definición del desarrollo

Página 78

Requisitos BAGE

4.1 Características generales del proyecto

Tomando como base para la definición del proyecto tanto los estudios y documentación previa
como la revisión y detalle de cuestiones a revisar en Koha que se ha incluido en el apartado
anterior, intentamos definir el próximo paso o fase en el proyecto, que es la definición del
desarrollo a realizar, así como valorarlo (tanto en tiempos como en recursos) y planificarlo.
Como en todo proyecto de desarrollo y sobre todo cuando la base es una herramienta compleja
y viva, esta definición no va a ser la definición final, sino el marco o eje vertebrador del
desarrollo.

4.1.1 Marco general

4.1.1.1 Objetivos

Para poder proporcionar a las Bibliotecas de la Administración General del Estado una
herramienta que permita su automatización e integración posterior en el punto de consulta
único partimos de una serie de premisas:

 FUENTES ABIERTAS: se realizará un desarrollo sobre Koha para intentar servir de
estímulo a la industria española de software para bibliotecas, que puede aprovechar la
gran oportunidad que proporciona el “código abierto”.

 NORMALIZACIÓN y ESTÁNDARES para potenciar el uso entre las BAGEs de los
estándares de metadatos y de interoperatividad entre sistemas de gestión el desarrollo
que se realice debe cumplirlos y adecuarse a ellos.

 IDENTIFICACIÓN Y VALORACIÓN DE REQUISITOS, descritos y detallados en el
apartado anterior.

Por todo ello el objetivo principal de este desarrollo que planteamos es DISPONER DE UNA
DISTRIBUCIÓN KOHA que cumpla los requisitos identificados y valorados como básicos por el
grupo de trabajo en cuanto a funcionalidad pero también “paquetizarlo” con la mayoría de
cuestiones de implantación inicial, de manera que se facilite el despliegue de la aplicación en
los entornos en los que se necesite.

Página 79

Requisitos BAGE

4.1.1.2 Características principales

Por todo lo mencionado anteriormente, el proyecto tiene tres características especiales que nos
interesa destacar:

 Desarrollo en Fuentes Abiertas: el desarrollo sobre una herramienta como es Koha, nos
obliga en todo el prceso de evolución del proyecto a tener una serie de cuestiones
claras, como son:

o Filosofía de desarrollo Koha: los desarrolladores deben estar totalmente
familiarizados con la filosofía y proceso de desarrollo Koha. Para intentar
minimizar riesgos y problemas a nivel de actualizaciones, integración de
desarrollos nuevos, migraciones…etc.

o Wish list: los desarrolladores y los analistas deben estar totalmente
familiarizados con el funcionamiento de la comunidad y, por tanto, evaluar las
diferentes versiones que están en desarrollo (y su roadmap) y las listas de
funcionalidades que se quieren incluir para reorientar su trabajo si fuera
necesario.

o Reutilización de código y versiones que han desarrollado para otros proyectos o
versiones.

o Contribución a la comunidad: el tipo de licencia y de compromiso de desarrollo
con la comunidad nos obliga a trabajar en código abierto. Además de tener en
cuenta que muchos de nuestros desarrollos y esfuerzos pueden ser incluidos en
futuras versiones y beneficiar a toda la comunidad Koha.

 Adecuación a BAGE: en la línea del punto anterior, en realidad, esta distribución es una
personalización y adecuación para BAGE, en la que es necesario incluir funcionalidades
que Koha inicialmente no contempla o contempla de una forma no satisfactoria. Por este
motivo tenemos que asumir que algunos desarrollos se alejan totalmente de la
trayectoria Koha y otros, por el contrario, la mejoran y pueden ser incluidos. El desarrollo
a realizar tendrá que ser capaz de integrar ambos desarrollos en Koha (comunidad y
evolución), de lo contrario, acabaremos teniendo un desarrollo a medida más, sin
soporte, sin actualizaciones, etc…
Página 80

Requisitos BAGE

 Personalización y servicio: el proyecto también tiene una parte de servicio a las BAGE,
con lo que paralelamente se han de realizar tareas de personalización y preparación del
servicio que se desvinculan de Koha y de la comunidad y deben adecuarse e intentar
solucionar los problemas y cuestiones que han surgido en el análisis.

 Beta Perpetua: hacemos referencia a la necesidad de flexibilidad y evolución del
proyecto. No podemos concebir éste como un proyecto cerrado puesto que irán
surgiendo necesidades, mejoras, cambios, etc. para los que el proyecto debe estar
preparado. Este documento y el desarrollo posterior son el inicio de un proyecto que
debe evolucionar (para incluir cuestiones que, como valor añadido, se han retirado de la
primera fase de desarrollo, como las que puedan surgir en el propio desarrollo o en la
implantación.)

4.1.2 Fases

Se trata de un proyecto amplio, con aspectos que pueden ser tratados y trabajados de forma
paralela; por tanto, las fases, más que a una evolución cronológica, hacen referencia a los
trabajos que han sido identificados.

Definimos a continuación las fases y tareas a realizar para conseguir el objetivo principal de
este proyecto, que es la distribución de Koha como herramienta a disposición de las BAGE
para su automatización. En este apartado hablamos de metodología de proyecto y, por tanto,
se mencionan las tareas de forma genérica; el alcance y especificaciones se recogen el
apartado 4.2

FASE I - Análisis

Partiendo de la identificación de requisitos y definición del proyecto que realizamos en este
documento, se realizará el análisis pertinente para el desarrollo, planificación y programación
de todas las tareas a desarrollar, así como la identificación de interlocutores y responsables del
desarrollo del proyecto.

Página 81

Requisitos BAGE

FASE II - Desarrollo
Es una fase extensa en la que se realizará todo el trabajo de preparación de la distribución
Koha para las BAGE. Dividimos el trabajo en varias tareas, que son más bien grupos de tareas
y que pueden realizarse en paralelo.

Tarea 1 - Desarrollo Koha. Incluye todo el desarrollo de todos los requisitos que hacen
referencia exclusiva a funcionalidad Koha.
Tarea 2 - Implementación Koha-BAGE. Incluye todas las tareas de “paquetización” y
preparación de la aplicación para las BAGE. Esto es:
 Arquitectura de información y rediseño OPAC

 Parametrización básica y valores por defecto

 Virtualización y optimización para la instalación y uso de Koha en
distintos entornos.

Tarea 3 - Testeo/pruebas

FASE III - Proyecto piloto.
Implantación en bibliotecas y despliegue en un número reducido de bibliotecas (2-5)
Tarea 1. Formación: sesiones de formación a las bibliotecas piloto
Tarea 2. Análisis: revisión de cuestiones iniciales y de características del desarrollo.
Adecuación inicial.
Tarea 3. Implantación. Despliegue y puesta en marcha.

FASE IV - Evaluación y definición del servicio a BAGE
Evaluación de los resultados y del servicio, no sólo para identificar cuestiones que deben ser
mejoradas, sino también para identificar puntos críticos y necesidades para la prestación del
servicio o la instalación futura de la distribución Koha en otras BAGE. Este grupo de tareas
debe estar liderada por los responsables del proyecto.

Tarea 1 - Evaluación: se trata de una tarea amplia en el tiempo, que debe, no sólo
medir el grado de éxito y satisfacción del usuario, sino también detectar las
necesidades, carencias o mejoras que el uso de la aplicación y las nuevas versiones o
desarrollos propongan.
Tarea 2 - Revisión: supondrá la definición
Tarea 3 - Definición del servicio

Página 82

Requisitos BAGE

4.1.3 Equipo de trabajo
Para que éste sea un proyecto abarcable a corto o medio plazo tendrá que contar con:

o La Coordinación de la Subdirección General de Coordinación Bibliotecaria
del Ministerio de Cultura;
o El grupo de trabajo creado ad hoc (Koha _BAGE)
o Empresas / servicios externos especializados en desarrollos y servicios
sobre Koha

Al tratarse de un proyecto tan amplio, el equipo que debe encargarse del desarrollo y ejecución
es un equipo multidisciplinar. Intentamos recoger aquí un resumen de diferentes perfiles, según
las tareas a desarrollar (no hacemos referencias a categorías profesionales ni nada por el
estilo; simplemente a perfiles relacionados con tareas). No es una lista de perfiles cerrada ni
definitiva.
PERFIL Área Tareas
Identificación de necesidades, definición de requisitos,
Informática/desarrollo
diseño funcional, validación de propuestas Koha
Analista
Identificación de necesidades, definición de requisitos,
Bibliotecas/documentación
diseño funcional, validación de propuestas Koha
Informática/desarrollo Programación e integración

Bibliotecas/documentación Parametrización y tareas avanzadas de gestión SIBG
Técnico senior
Diseño Diseño e integración con Koha

Maquetación Maquetación de plantillas e integración con Koha

Informática/desarrollo Inserción masiva de datos, testeos
Técnico junior
Bibliotecas/documentación Inserción de datos, testeos, pruebas de funcionalidad

También, se ha de tener en cuenta que el grupo de trabajo de las BAGE es sólo un apoyo al
proyecto y que, por tanto, no es personal fijo para el desarrollo de tareas; su aportación está
más relacionada con la de testeos y validación (sobre todo en las bibliotecas que sean proyecto
piloto).

Página 83

Requisitos BAGE

4.2 Definición y especificaciones

Para la definición y especificaciones del trabajo a desarrollar, nos basamos en lo mencionado
en el apartado 3.2 (resumen e identificación) teniendo en cuenta los niveles y el alcance de
cada uno de ello,s y definimos dos grandes grupos de tareas. El primer grupo de tareas es
aquel que supone el desarrollo sobre la herramienta, el trabajo en la línea de la comunidad (o
no), la reutilización de código, el análisis para su posterior inclusión en versiones de la
herramienta, etc. El segundo, en cambio, hace referencia únicamente al proyecto para las
BAGE y depende de otros criterios como el servicio que luego se quiera ofrecer o la relación de
trabajo que se establezca con ellas o simplemente, la colaboración entre ellas.

Todo lo que vamos a enumerar a continuación está dentro del marco general definido
anteriormente, con lo que no consideramos necesario repetir cuestiones relacionadas ni con los
perfiles, tareas / fases, características o premisas del proyecto.

Son cuestiones puramente de desarrollo, en las que el grupo de trabajo debe participar en la
definición y aprobación de requisitos, así como en los testeos y revisiones.

Además de los dos grandes grupos de tareas, incluimos un tercero que, por especificidad y por
responder a necesidades de muy pocas bibliotecas o por ser un amplio desarrollo, se ha
considerado VALOR AÑADIDO, y por lo tanto, para lo que el presente proyecto no tiene
alcance.

4.2.1.1 Desarrollo Koha

Bajo desarrollo Koha englobamos, como ya se ha mencionado, todo el desarrollo relacionado
con el CORE de Koha que por cuestiones específicas de las BAGE, por normativa o tradición
en España o por requisito de futuro, no están contempladas en Koha y que se han considerado
necesarias Básicas o Relevantes. También se incluyen algunas de valor añadido pero que no
suponen una gran inversión en cuanto desarrollo.

Todo lo que se realice, será “paquetizado” en la medida de lo posible para que no afecte a
futuras versiones de Koha, migraciones, etc. intentando reducir el impacto de este tipo de

Página 84

Requisitos BAGE

actuaciones. Enumeramos los desarrollos a realizar (el detalle de cada uno de ellos en 3.1 y
3.2)

 Aspectos generales

o Idiomas: se realizarán mejoras tanto en la traducción como en la duplicidad de
directorios, además de incluir la gestión de idiomas a nivel base de datos
(multilingüismo)

 Aspectos informáticos

o Modificaciones en la generación de contraseñas

o Mejora del rendimiento de las búsquedas (modoperl/Pazpar)

 Aspectos técnicos. Ampliación a registros MARC de fondos

o Gestión de objetos digitales. Inclusión del repositorio

o Mejora de las búsquedas Z39.50 y búsquedas federadas

o NCIP

o OAI cliente

 Catalogación

o Mejora de la edición de registros bibliográficos (integración con autoridades,
ayuda con indicadores, mejora de campos de longitud fija…)

 Autoridades

o Incluir la gestión de tesauros

o Autoridades multilingües: (visualización en idiomas y navegación jerárquica)

 Circulación

o Préstamo interbibliotecario (relación con otras bibliotecas y protocolo NCIP)

 Publicaciones periódicas

o Tratamiento de ejemplares (MARC 21 Holdings)

o Mejora en la definición y descripción de la suscripción

o Recepción de ejemplares en lote

Página 85

Requisitos BAGE

 Adquisiciones

o Gestión del historial de compra

 Administración:

o Ampliación de las posibilidades de interrogación y obtención de informes

 OPAC:

o Funcionalidades de la Home en preferencias del sistema

o Mejoras OPAC por xercode (facetas, redefinición de buscadores..)

o Navegación por materias / autoridades

o Configuración de buscadores

4.2.1.2 Desarrollo y personalización BAGE

Se trata de las tareas y desarrollos que son necesarios para ofrecer el servicio a las BAGE, es
decir, para que el desarrollo de Koha con las especificaciones indicadas en el aparatado
anterior tengan también identidad de proyecto y facilidad de implantación. Por ello, agrupamos
en cuatro bloques de cuestiones que el desarrollo debe cumplir:

 Identidad corporativa e imagen:

o Las interfaces Koha deberán tener identidad corporativa (Administración General
del Estado) (CSS);

o Siguiendo filosofía Koha, mediante las preferencias del sistema, se habilitarán
funcionalidades que faciliten la carga de logos y cabeceras individualizadas para
cada biblioteca;

o Las preferencias del sistema que permiten la personalización de textos y menús
y que utilizan etiquetas HTML, contarán con editores enriquecidos que permitan
imágenes, negritas, enlaces…sin necesidad de conocer HTML.

Página 86

Requisitos BAGE

 Arquitectura de información/ navegación

o Se modificará la visualización y la arquitectura de información para mejorar la
USABILIDAD de las interfaces (sin incluir cambio de funcionalidad) y la
información mostrada.

o Accesibilidad: optimización para mejorar la accesibilidad de las plantillas.

 Asistente para la instalación de la Virtualización

Sin perder de vista aspectos tan importantes como las versiones, los nuevos desarrollos y las
actualizaciones, la instalación y virtualización debe ser contemplada no sólo para facilitar la
instalación también debe orientarse a:

o Incluir la parametrización y personalización

o Detectar problemas con navegadores, puertos en la instalación

o Configuración de back-up local o remoto

 Parametrización: Hace referencia a la configuración de Koha en cuanto a preferencias
del sistema y parámetros básicos como los tipos de usuario, tipos de item, reglas de
circulación, plantillas de catalogación…

4.2.1.3 Valor añadido:

Por ser cuestiones avanzadas en las que trabajar, -no sólo con Koha, también con la práctica
bibliotecaria- el presente proyecto no tiene en cuenta cuestiones como:

o Gestión de dominios (se desconocen estructuras de bibliotecas con
sucursales o relaciones específicas como pueden ser las bibliotecas
municipales (concellos, mancomunidades, diputaciones, ayuntamientos..)
o Autoridades multilingües (gestión de idiomas). Se desconoce si realmente se
está trabajando con autoridades multilingües, con lo que modificar plantillas y
funcionalidades Koha (como buscadores, visualización, etc.) sin que luego
se utilice no nos parece de inicio procedente, aunque es una cuestión a tener
en cuenta para el futuro
Página 87

Requisitos BAGE

o Publicaciones periódicas y adquisiciones. Como en el caso de autoridades
multilingües, la gestión de compras y suscripciones se realiza en cada
institución de una forma particular, con lo que llegar a un consenso para
desarrollarlo es un gran esfuerzo que no se verá recompensado.
o Integración con sistemas propietarios

En la fase de revisión e implantación irán surgiendo aspectos sobre los que trabajar en el futuro
e incluir en Koha.

4.2.2 Implantación (proyecto piloto)
El proyecto de implantación se plantea para un grupo de 2-5 bibliotecas. Es necesario tener en
cuenta que la implantación y el desarrollo del piloto debe servir para evaluar el desarrollo
realizado y ayudar a definir el proyecto futuro.

Las cuestiones más críticas en esta parte del proyecto son:
 Elección de las bibliotecas participantes. Debemos realizar un análisis antes de la
implantación de las bibliotecas que van a formar parte del piloto. Es necesario
seleccionar bibliotecas que respondan a unas necesidades estándar e inicialmente
básicas. El motivo es que el desarrollo no contempla ningún trabajo para su integración;
precisamente se elabora para evaluar el desarrollo realizado para dar un servicio global.

 Formación: se proporcionará formación a los bibliotecarios y técnicos que estén
involucrados en el proyecto.

 Instalación y puesta en marcha.

 Soporte (un tiempo estipulado de adaptación).

Los responsables del proyecto pueden valorar lo que debe durar el proyecto piloto.

4.2.3 Evaluación y definición del servicio

Página 88

Requisitos BAGE

Tras el proyecto piloto, los responsables del proyecto podrán evaluar el desarrollo y las
necesidades, si existen, de mejora. Pero el proyecto piloto, sobre todo, debe servir para poder
definir, una vez se ha logrado la distribución de Koha, el objetivo de este proyecto, es decir, la
puesta en marcha del servicio a las BAGE. A pesar de que las características y condiciones del
servicio no dependen de este informe, la experiencia con el grupo de trabajo y la experiencia
con el piloto Koha ayudarán a definir mejor el servicio en cuanto a:

 Evolución y mejora de la distribución Koha: definir la responsabilidad de la distribución
Koha_BAGE en cuanto a nuevos desarrollos, actualizaciones, mantenimiento de
sistemas…

 Soporte: articular el servicio de soporte a las BAGE;

 Alojamiento: ofrecer o no servicios y facilidades para la instalación y alojamiento de la
aplicación en sistemas externos a las instituciones;

 Cuestiones relativas a implantaciones individuales como migraciones, conversiones de
registros, integración con sistemas propietarios (Intranets u otras aplicaciones).

Página 89

Informe Koha

Más contenido relacionado

La actualidad más candente (20)

Destacado (20)

Similar a Informe Koha (20)

Más de Katalogador (20)

Último (20)

Informe Koha