Between the Sheets: a Library-wide Inventory with Google

De TallerDocumental on Wiki
Saltar a: navegación, buscar

Referencia bibliográfica

  • BOMAN, Craig y VOELKER, Ray. Beetween the Sheets: a Library-Wide Inventory with Google. En: Code4lib-JOURNAL [En línea]. Octubre 2017, n.28 [Consulta: 23 octubre de 2017]. ISBN 1940-5758. Disponible en: http://journal.code4lib.org/

Resumen original

When it comes to taking an inventory of physical items, libraries often rely on their traditional integrated library system’s (ILS) à la carte add ons; outside vendors; or other possibly outdated, complex, and often expensive methods. For libraries with shrinking budgets and other limited resources, high costs can put these methods out of reach. At the University of Dayton Libraries, we set out to develop an inexpensive and reasonably easy-to-use method for conducting a library-wide physical item inventory. In this article, we explain a custom built Google Sheets-based library inventory system, along with some code for the implementation of a RESTful API (written in PHP) that interacts with our ILS. We will also explain our use of Google Apps scripts in our Google Sheet, which are crucial to our systems.

Although this method used a specific ILS (Innovative Interfaces’ Sierra product) and custom-built RESTful APIs, it may be possible to use similar approaches with other ILS software. Additional notes include areas for improvement and recommendations for interoperability with other ILS systems.

Resumen

Tras preguntarse, en 2015 como se debe hacer un inventario en la biblioteca física y como no se debe hacer, surgió la alternativa, de usar hojas de cálculo para realizar dicha tarea, por lo que se estudió un inventario basado en hojas de cálculo de Google, para crear mejores datos de inventario. En cuanto a la Identificación de necesidades y requisitos del proyecto, se examinó las herramientas que estaban disponibles para el Sistema de Biblioteca Integrado (ILS) en uso en nuestra institución. Gracias al inventario de 2008, se pudo identificar varias áreas problemáticas con los métodos y herramientas utilizados para ese proceso, como que el método fue lento, laborioso y propenso a errores de escaneo y pérdida de datos.

Los escáneres de código de barras de Percon utilizados tenían que ser de un tipo muy específico, y tenían muchos inconvenientes, como por ejemplo, no tenían forma de decirle al usuario la última serie de códigos de barras escaneados. Además los datos tenían que “descargarse” del dispositivo con frecuencia debido a la pequeña cantidad de memoria incorporada para almacenar los códigos de barras escaneados.

La tarea de mover los datos del inventario desde el dispositivo al sistema ILS tuvo que ser realizada por un miembro del personal, en una estación de trabajo que tenía instalado el cliente del sistema ILS, por lo que dicho personal debía estar disponible en el momento en que se realizaba cualquier exploración. Además de estas limitaciones, los escáneres no eran confiables; en varias ocasiones, se tuvieron que repetir sesiones de escaneo completas.

Después de examinar los métodos anteriores, se resaltaron las siguientes tres necesidades: Precisión / Confiabilidad (para minimizar las pérdidas de datos y corrupción), Velocidad (se quería realizar este inventario lo más rápido posible) y Facilidad de uso.

Para actuar con éxito sobre los datos de inventario, se tenía que responder dos preguntas: primero, cómo se podría conectar con Sierra ILS para obtener datos síncronos durante nuestro proceso de escaneo, y en segundo lugar, ¿Qué debía capturarse del ILS para cada código de barras escaneado? A la primera pregunta, se sabía que Sierra ILS proporciona un método de conexión a la base de datos de back-end por medio de una función llamada "Sierra Direct SQL Access". Esta característica proporciona acceso de solo lectura a las tablas de la base de datos a través de "vistas" de la tabla, que exponen los datos del catálogo en vivo que se ejecutan en la base de datos PostgreSQL de Sierra. Estos datos, nos proporcionan una manera de extraer lo que necesitamos de los datos bibliográficos y de registros de artículos asociados con un código de barras en tiempo real. Había una gran flexibilidad al seleccionar un lenguaje de programación, por lo que e eligió el lenguaje PHP . El segundo paso, era obtener los datos en la hoja de cálculo de Google, que se pueden aumentar con las secuencias de comandos de Google Apps, lo que hace posible crear eventos "activados" que pueden invocar funciones personalizadas adicionales para realizar llamadas API que, cuando se invoca, consulta la base de datos y devuelve resultados formateados que pueden ser procesados por las secuencias de comandos de Google Apps. En cuanto a la segunda pregunta, se determinó que los siguientes datos sobre el elemento serían esenciales:

  • Artículo Código de Barras
  • Número de llamada normalizado: con el que podemos ordenar la hoja, para determinar el orden correcto de almacenamiento de los artículos escaneados y para extraer los artículos que no pertenecen al rango. Para hacer que los números de llamada de la Biblioteca del Congreso (LC) estén ordenados alfabéticamente, los números de llamada deben estar normalizados. Normalmente, Sierra realiza la normalización de estos números , pero hay ciertas circunstancias donde esto no puede ser posible. Una solución a este problema es incorporar una función que filtre los datos del número de llamada, lo normalice y luego devuelva el formulario normalizado a nuestra aplicación.
  • Código de ubicación del artículo: al marcar Código de ubicación del artículo, se identificaron libros que no pertenecían a la sección, o que tenían información incorrecta en el catálogo. Algunos de los datos del registro del artículo se corrigieron como resultado de este descubrimiento.
  • Código de estado del artículo: con el que se pudieron marcar artículos que tienen cualquier código de estado que no sea "-" (que en Sierra indica que hay algún otro estado que no sea Disponible).
  • Estado de salida (fecha de vencimiento).

Con esa información, podemos identificar y abordar varios problemas rápidamente.

Implementación y guiones:

En cuanto al servidor, se decidió escribir la secuencia de comandos para recuperar los datos de la base de datos utilizando PHP y, que la secuencia de comandos debería actuar como un punto final RESTful API. Dado que esta API es RESTful, se necesitaba un servidor web para alojar y ejecutar PHP, por lo que se eligió Linux, el servidor Apache HTTP y PHP, instalado como un Módulo de Servidor Apache. Se escogió una arquitectura RESTful para el método de desarrollo de la secuencia de comandos, en primer lugar, porque la arquitectura facilita la prueba y el uso del script, y en segundo lugar, ciertos componentes de la aplicación, están diseñados para interactuar fácilmente con puntos finales RESTful.

La mayoría del inventario se centró en Google Sheets, la institución había pasado recientemente a usar G Suite for Education, que incluía esta herramienta de hoja de cálculo fácil de usar. El uso de Hojas de cálculo de Google ofrece varios beneficios. Por último, Google Apps Scripts permitió construir una aplicación de inventario propia casi por completo desde la herramienta Hojas de cálculo de Google. Como una ventaja adicional, Google Sheets funciona bien en el modo "fuera de línea". Los datos colocados en la hoja de cálculo se sincronizan automáticamente con la nube cuando se restaura el acceso a la red, pero esto requiere un paso manual adicional que afortunadamente es relativamente simple. Google Apps Script, es el método que "activa" la importación de datos bibliográficos y de artículos en cada código de barras escaneado en Hojas de cálculo de Google.

Ampliación de Hojas de cálculo de Google y primeros pasos:

Con el servidor web configurado, los tipos de datos para tirar identificados y el guion de Google Apps listo, se estaba en camino para comenzar el inventario. Se pudo maximizar las funciones disponibles a través de Hojas de cálculo de Google para extender el uso de la aplicación para organizar todos los datos de inventario escaneados. Google Sheets tiene métodos interminables de transportar datos de hojas de cálculo de inventario entre diferentes hojas. Cada hoja de Google tiene una identificación de hoja en la cadena de URL. El uso de este Tablero de inventario tiene algunas limitaciones. Para permitir que una hoja de cálculo de Google importe datos, se necesita que los usuarios den permiso para acceder a los datos almacenados en otra hoja de cálculo de Google. Puede haber una forma de programar este otorgamiento de permisos usando el script de la aplicación de Google, pero en el momento del inventario se interactúa manualmente con una fila que contiene una fórmula para permitirle acceder a los datos de otra hoja de cálculo. Además, cuando se realiza el inventario, se crea manualmente cada hoja de cálculo de Google para el proyecto.

Progreso del inventario:

Ejecutar un inventario de toda la biblioteca es un proyecto importante. Los coordinadores de inventarios no deben subestimar la cantidad de trabajo que entrará en un inventario o la variabilidad de las velocidades de progreso del trabajador estudiante. La transparencia de las Hojas de cálculo de Google puede ayudar a mitigar esta variabilidad alentando a los estudiantes. Después de haber escaneado una variedad de libros, parte de la información de este ILS tuvo que actualizarse comenzando con los estados incorrectos de los registros de artículos. En algunos casos, no se encontraron registros en el ILS porque se había borrado el registro bibliográfico o de artículos muchos años antes, lo que requería una catalogación adicional. Otros problemas de estado incluyen libros del consorcio archivados incorrectamente que requieren volver a depositar en el orden correcto. Otra gran parte de los procesos posteriores incluyó la importación de los códigos de barras escaneados en el ILS y la aplicación de una nota de inventario. Esta nota incluía dónde se escaneaba el artículo por última vez. También se actualizó la fecha del inventario en los registros de artículos, para saber cuándo se realizó por última vez el inventario del libro. Se creó una herramienta web basada en PHP para convertir la lista de códigos de barras escaneados, rango por rango, en números de registro de artículos. La herramienta web consulta Sierra ILS y devuelve la lista de números de registro de elementos. En cuanto a la comunicación, el impacto del inventario no siempre se comunicaba bien a los empleados estudiantes que eran responsables de archivar libros. Además, un objetivo principal del inventario era comunicar el progreso y hallazgos a las partes interesadas antes, durante y después del inventario. En general, comunicar el progreso a la comunidad bibliotecaria ayudó a que el proyecto en general funcionara mejor.

Comentario personal

Todas la bibliotecas siempre han tenido un elemento en común, y es la falta de presupuesto, es por ello que la elaboración de un inventario de elementos físicos tradicional (ILS) no esta al alcance de muchas debido a los elevados costes, una solución aparentemente fácil es la que en este articulo de describe, un sistema de inventario de bibliotecas basado en Google Sheets, un método económico y relativamente fácil de usar.

Hay que tener en cuenta la importancia de realizar un inventario, ya que se trata de registros en los que se inscribe y se describen los fondos de una biblioteca, debido a la cantidad y diversidad de materiales, el inventario requiere una planificación.

En mi opinión este sistema es esencial y de gran utilidad para las bibliotecas, no solo por el ahorro que en el coste supondría sino también por las múltiples ventajas que presenta, como la flexibilidad al crear mejores datos de inventario, la reducción de perdida de datos y corrupción, la identificación rápida de problemas con el proceso de escaneo, sin mencionar la facilidad de uso

Bibliografía

  • ADIELSSON, Magnus; BARNES, Richard; KUPFER, Peter; ROBERTS, IAIN y WEBER, JEAN HOLLIS. Lista de funciones de Hojas de Cálculo de Google. En: Ayuda de Editores de Documentos. [En linea]. 2005 [Consulta: 26 de octubre de 2017]. Disponible en: https://support.google.com/docs/table/25273?hl=es
  • Los catálogos e inventarios en la historia del libro y de las bibliotecas. En: bid. Textos universitaris de biblioteconomía i documentació. [En linea]. Junio 2007 [Consulta: 27 de octubre de 2017]. ISSN 1575-5886. Disponible en: http://bid.ub.edu/18rodri4.htm
  • ROCCA VARELA, Adiana Beatriz. Sistema Integrado de Gestión Autorizada de Bibliotecas basado en soluciones de software de Open Access para la Biblioteca del Departamento de Física, Facultad de Ciencias Exactas, universidad Nacional de La Plata: Una actualización en la evolución de su aplicación. [En linea]. Octubre 2015 [Consulta: 27 de octubre de 2017]. Disponible en: http://eprints.rclis.org/15403/1/Rocca%20Varela%20Adriana%20Beatriz%20Koha-BDF.pdf


Categorías: software libre | PKP

Usuario:Clara (discusión)
https://tallerdocumental.unizar.es/wiki/index.php/Between_the_Sheets:_a_Library-wide_Inventory_with_Google
tallerdocumental.unizar.es
CC-MAIN-2023-23
34836
application/http; msgtype=response
sha1:J3UURYZU4Q5WHIZJKMCLEV7MLCJY7QYZ
<urn:uuid:0a0201f7-2fa4-426f-b996-4a506deee850>
2023-05-29T03:29:03Z
155.210.11.200
text/html
sha1:RC4SO4JFQLQIP2BG6KOT6NZZ5OGSZAAT
<urn:uuid:ce2b4939-8a1b-4853-b2ef-ddc776988742>
https://tallerdocumental.unizar.es/wiki/index.php/Between_the_Sheets:_a_Library-wide_Inventory_with_Google
response
<urn:uuid:94885bac-30ab-4422-ae5b-b08e6a72c258>
isPartOf: CC-MAIN-2023-23
publisher: Common Crawl
description: Wide crawl of the web for May/June 2023
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-208
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/