[greenstone_es] Re: [greenstone _es] Sqlite y otras yerbas. Me interesa la opinión de los expertos.
- From: "Mariana Pichinini" <mariana@xxxxxxxxxxxxxxxxx>
- To: greenstone_es@xxxxxxxxxxxxx
- Date: Thu, 9 Jun 2011 16:47:29 -0300 (ART)
Hola Marcelo
Cómo a muchos los que estamos trabajando con Greenstone desde hace un
tiempo, estas cuestiones se nos han presentado en más de una oportunidad.
Una cuestión que muchas veces ocurre es que ya habiendo desarrollado y
publicado una biblioteca digital (y haber aprendido a hacerlo sobre la
marcha) encontramos que el resultado está bien, pero que podría estar
mejor, y en este sentido, nos interesa reconstruirla para mejorar tanto la
interfaz y las búsquedas como la visualización de los recursos y sus
metadatos.
Y ahí nos chocamos con que la administración de los metadatos en archivos
de texto dificulta cualquier cambio masivo (por ejemplo, agregar un
metadato jerárquico con metadatos ya existentes en forma separada) que
requiere el uso de expresiones regulares y aplicaciones tipo msrp u otras,
que obviamente complican a los documentalistas, archivistas,
bibliotecarios, y requieren un apoyo informático de parseo fuerte.
Personalmente me parece que el requerimiento del "tiempo real" no es una
presión necesaria en una biblioteca digital (que no es un sistema
bancario, ni comercial, ni de control de procesos físicos), y que una
demora de un día o varias horas entre la inclusión y descripción de un
recurso y su publicación web no le cambia la vida a ningún proyecto.
En ese sentido, me parece que, en un proyecto afianzado con necesidades de
reconstrucción o rediseño grande, con grandes volúmenes de información
cambiante en sus metadatos, la mejor opción es manejar la gestión, edición
y modificación de metadatos con algún motor de bases de datos externo que
genere los archivos metadata.xml para los procesos de importación y
generación de la colección. Y en ese caso, las modificaciones de etiquetas
y contenidos se manejan a nivel de la BD y de su mecanismo de exportación
a texto.
Como bien decís, me parece que "las bondades de Greenstone en cuanto a
busqueda y visualización" son lo más importante de la herramienta. Creo
que trabajar por componentes es más efectivo en determinadas
circunstancias, y que son éstas particularidades de algunos proyectos las
que requieren repensar la administración de los metadatos.
Lo bueno de debatir estas cuestiones es que de alguna manera se aclara el
panorama para proyectos nuevos.
Saludos
Mariana
>
> Buenas a todos:
>
> Voy a aprovechar estos post de Tania para plantear algunos temas en los
> que he dado vueltas en estos 5 o 6 años de trabajo con GreenStone.
> Situaciones en las que uno se encuentra a veces en la necesidad de dar
> respuestas concretas a situaciones de uso de los documentos por parte de
> otros usuarios que no son informáticos, pero si son especialistas en el
> manejo de documentos. En mi caso investigadores y archivólogos en mi caso.
> Creo que la necesidad y la busqueda de usar otros motores de base de datos
> tiene que ver con poder modificar los metadatos, el contenido, e incluso
> la estructura, de los documentos en tiempo real, tal como estamos
> acostumbrados quienes trabajamos con bases de datos relacionales.
> Porque imagino que el escenario que buscás, Tania, es que los usuarios (al
> menos
> un tipo especial de usuarios) que naveguen la colección puedan
> modificar esos datos para enriquecer y corregir la colección utilizando
> las bondades de Greenstone en cuanto a busqueda y visualización.
>
>
> Vamos por parte.
>
> Para acceder a sqlite se necesita un driver propio de Sqlite. En google
> hay varias opciones
> yo utilizo este
> http://www.ch-werner.de/sqliteodbc/
> Y tambien es muy util el sqlite manager un completo para firefox que sirve
> para navegar bases de datos SQLITE (que greenstone les pone extensión .db
> pero en realidad pueden tener cualquier extension e incluso no tener
> ninguna) https://addons.mozilla.org/es-es/firefox/addon/sqlite-manager/
>
> Usar Mssql es algo que nunca probe, pero hay documentacion acá
> http://wiki.greenstone.org/wiki/index.php/Using_MSSQL_for_Collection_Database
>
> De todas formas es bastante... extraña la forma en que la base de datos
> que usa greenstone está realizada que es similar a como lo vuelca el
> comando db2txt, esto es cada registro tiene un campo que es un texto con
> todos los metadatos dentro organizados de la siguiente forma:
> <metadato1>valor
> <metadato2>valor
> <metadato3>valor
> <metadato4>valor
>
> Con lo cual es bastante complicado de manejar. Supongo que hay que hacer
> uso de Expresiones Regulares para poder ubicar el valor de un metadato
> concreto.
> Yo suspendi mi linea de investigación por esos lados porque cuanto mas
> conozco Greenstone más atónito me quedo.
> No obstante hay un proyecto que planteaba modificar esa base de datos
> Sqlite con scripts PHP que se llamaba EMERALD, habría que buscar creo que
> no prosperó.
> De todas formas modificar esos metadatos no implica modificar el valor
> real del metadato para las búsquedas sino solo para la visualización.
> Es decir esa base de datos no es la que se utiliza para las busquedas sino
> la que se utiliza cuando se muestra un valor en la página.
> Si lo que queres modificar es el valor real del metadato hay cambiarlo en
> los archivos originales, o en los doc.xml y realizar despues el proceso de
> BuildCol.
> Hay un script perl especifico que hace eso y que es accesible en el
> directorio cgi-bin: metadata-server.pl. Este script trabaja directamente
> con el directorio ARCHIVES.
> Su función es ubicar dentro de los archivos el valor del metadato de un
> documento, o de una seccion de documento, y reemplazarlo por otro.
> Luego de esto hay que realizar el proceso buildcol para que los cambios
> tengan efectos, osea uno cambia el valor en doc.xml del documento dado,
> pero ese cambio no se refleja en la visualizacion. Al reves de como
> sucedia modificando la base de datos Sqlite.
> Con lo que si uno escribe una pagina, o un script en perl o algo, se
> podria hacer que se modifiquen ambas cosas como para tener la sensación de
> trabajo en tiempo real.
>
> Hay que entender, a mi me costó, que greenstone no está pensado así. Si no
> al revés greenstone espera que tengas todos los metadatos relevados, el
> material corregido, es decir: todo depurado, ANTES de comenzar a construir
> la biblioteca.
> Esto a veces choca con la lógica de trabajo que uno pretende, pero es la
> que espera GreenStone.
>
> Yo lo que hacia antes era manejar todos los archivos desde otras
> aplicaciones que guardaban en base de datos y volcar todo en la carpeta
> archives con la estructura esperada, y escribir el doc.xml desde mi
> aplicación. Pero eso dejó de funcionar creo que desde 2.80, no investigue
> que cambió, pero son los archivos archiveinf-doc.gdb, archiveinf-src.gdb y
> OIDcount en la carpeta archives.
> Así que lo que hago ahora es volvar todo en la carpeta import y vuelco la
> info como .item, porque hago mis colecciones com PagedImage.
> Aun así es mucho trabajo. Tanto que uno llega a pensar, ¿y si dejo de usar
> greenstone y directamente desarrollo una aplicación?
>
> No sé. Estas complicaciones me abruman ultimamente.
> Si pudieran comentar y esclarecerme les estaré muy agradecido.
>
> Saludos
>
> Marcelo Yornet
>
Lic. Mariana Pichinini
Area Tecnologías
_______________________________________________
BIBHUMA - Biblioteca Profesor Guillermo Obiols
Facultad de Humanidades y Ciencias de la Educación
Universidad Nacional de La Plata
Calle 48 entre 6 y 7 - 1er subsuelo
B1900AMW LA PLATA, Argentina
Telefax: +54-221-4230125 interno 162 (líneas rotativas)
WEB: www.bibhuma.fahce.unlp.edu.ar
Other related posts:
- » [greenstone_es] Re: [greenstone _es] Sqlite y otras yerbas. Me interesa la opinión de los expertos. - Mariana Pichinini
