Características deseables en un módulo para generación de listados en Catalis

6 views
Skip to first unread message

Fernando Gómez

unread,
May 7, 2008, 11:53:16 AM5/7/08
to Catalis
A raíz de esta discusión sobre "Catalis, Winisis y tildes",

http://groups.google.com.ar/group/catalis/browse_thread/thread/c70ce6778481a0f2

surgió una vez más la inquietud acerca de generar listados o informes
diversos a partir de las bases de Catalis. La idea es poder hacerlo
desde la misma interfaz de Catalis, sin tener que recurrir a
herramientas externas (como p.ej. Winisis o mx).

Invito entonces a todos aquellos interesados en sugerir
características para un futuro módulo que se ocupe de la generación de
listados. Vayan enviando sus sugerencias aquí, tomando como base lo
charlado en esos mensajes.

Posteriormente podremos pasar las cosas en limpio y publicarlas en el wiki.

Saludos.

--
Fernando

Ariel Otero Estrada

unread,
May 9, 2008, 3:40:25 PM5/9/08
to cat...@googlegroups.com
Dijo alguna vez el líder:
 
> Invito entonces a todos aquellos interesados en sugerir 
> características para un futuro módulo que se ocupe de la
> generación de listados. Vayan enviando sus sugerencias aquí...
 
 
Composición tema:
"Cómo me gustaría que fuera el Módulo para Listados de Catalis"
 
Esto me hace acordar a los viejos buenos tiempos en que me colgaba de la manga del saco de mi viejo y le "mangueaba" alguna golosina. Pasados algunos años uno tiene pocas oportunidades de hacer lo mismo, pero ya que Fernando nos invita... pediremos golosinas, aunque vengan con bytes en lugar de hidratos de carbono...
 
Bien. Delirios vespertinos aparte, empezaría con un par de obviedades y alguna otra cosa más.
 
Sostengo que...
1) El módulo tendría que tener un formulario de búsqueda.
 
2) Tendría que poder ordenar los registros por al menos un par de criterios.
 
3) Debería poder imprimir:
- un rango de registros ( 200-500,704,815,912-2027,3000- )
- los resultados de una búsqueda
- registros seleccionados dentro de la búsqueda.
 
4) Tendría que poder guardar las búsquedas. Tanto la estrategia de búsqueda (para repetirla en otra ocasión), como el resultado (los MFNs de los registros hayados).
Este resultado debe poder servir como elemento de búsqueda futuro. 
Esto es importante que sea así porque de esa manera se puede rehacer luego de un lapso (digamos de un mes) la búsqueda y mediante el simple expediente "resultado nuevo" NOT "resultado anterior" se determina el acrecentamiento de registros para una estrategia de búsqueda determinada.
 
5) Debería poder admitir el uso de un pft "externo" escrito por el usuario.
 
6) Tendría que aceptar REF-LookUp a otras bases.
 
7) Debería tener un asistente para que los "no iniciados" puedan crear formatos. El asistente para formatos de Genisis es un ejemplo bastante satisfactorio. Quizá podría servir de modelo...
 
8) El asistente debería incorporar el uso de comandos de presentación (negrita, cursiva, colores, tipografías, etc.).
 
9) Debería permitir guardar los listados no sólo como HTML, sino también en otros formatos marcados (RTF, XML, TeX... )  a partir del mismo formato... je, je, je...   (entónese como una risita sarcástica y sobradora ;-)
 
Lo que quiero decir es que sería fácil que los comandos de presentación fueran simplemente marcas html entre apóstrofos:  '<b>' '<i>' ...  '</b>' '</i>'.
Pero lo correcto (lo que me gustaría, lo que quisiera) sería que fueran comandos traducibles en el documento final a otras marcas según el uso que surja en el momento, por ejemplo:  {\b\i ...}   o  {\b{\i ...} }
Podría aquí incluirse el caso de XML. No es un lenguaje de presentación, pero podría aprovecharse el mismo módulo para la exportación en este formato de marcas.
 
 
¿Había dicho: "delirios aparte"?
En fin, si hay que pedir, se pide...
 
Dejo la pelota en vuestro campo y escucho réplicas.
 
Saludos
 
Ariel
 

Fernando Gómez

unread,
May 9, 2008, 3:47:27 PM5/9/08
to cat...@googlegroups.com
2008/5/9 Ariel Otero Estrada <ariel.ote...@gmail.com>:

> Composición tema:
> "Cómo me gustaría que fuera el Módulo para Listados de Catalis"

Caray...!

Ya es viernes, querido Ariel. Descansemos un poco :-)

--
Fernando

Ariel Otero Estrada

unread,
May 9, 2008, 3:53:35 PM5/9/08
to cat...@googlegroups.com
> Ya es viernes, querido Ariel. Descansemos un poco :-)
 
Efectivamente, yo ya estoy con el mate y los bizcochitos y en tren de pre-fin-de-semana.
 
Buen descanso
 
Ariel


Ariel Otero Estrada

unread,
May 12, 2008, 10:01:36 AM5/12/08
to cat...@googlegroups.com
Hola Fernando, hola gente
 
Debo decir que en el fin de semana pensé un poco y llegué a la conclusión de que hice mal el planteo de un par de cosas. En lugar de explicar el problema o la necesidad, para que a alguien se le ocurriera una solución, traté de pedir la misma solución que se usa en otro contexto. No sé si me explico.
 
La cosa es la siguiente, en el punto cuatro decía:
> 4) Tendría que poder guardar las búsquedas. Tanto la estrategia de búsqueda
> (para repetirla en otra ocasión), como el resultado (los MFNs de los registros
> hayados).
> Este resultado debe poder servir como elemento de búsqueda futuro.
> Esto es importante que sea así porque de esa manera se puede rehacer luego
> de un lapso (digamos de un mes) la búsqueda y mediante el simple expediente
> "resultado nuevo" NOT "resultado anterior" se determina el acrecentamiento de
> registros para una estrategia de búsqueda determinada.
Bien. Sigo pensando que es necesario poder guardar las búsquedas, pero todo el resto (lo de guardar los MFNs) es sólo un procedimiento para obtener el acrecentamiento y quizá no el mejor. Sólo es cómodo en otro contexto, ajeno a Catalis y lo transferí así nomás. La verdad es que lo que me interesa es hacer DSI, (difusión selectiva de información). La solución puede venir por otro método (comparación de fechas u otro que mi mente no imagina).
 
----
 
La otra cuestión es sobre el punto 9, que ya me parecía un poco esotérico, un poco loco, mientras lo iba escribiendo. La verdad es que lo que se necesita es guardar en formatos diversos y el HTML no debe ser la prioridad. Cómo se resuelve es otro tema.
Eso de los comandos traducibles, en principio está demás. Podría servir o no. Quizá con una conversión del archivo final sea suficiente.
Lo que sí pienso es que la prioridad es RTF y no HTML. Si bien Catalis trabaja en ambiente web, el usuario trabaja en un ambiente de escritorio y allí priman las aplicaciones de oficina que no usan HTML.
 
 
Saludos y buena semana
 
 
Ariel
 
 

Fernando Gómez

unread,
May 13, 2008, 9:44:50 AM5/13/08
to cat...@googlegroups.com
Ante todo, quiero agradecer a Ariel su valiosa colaboración. Tengo que
acordarme más seguido de consultarlo para que me acerque sugerencias!
:-)


1) Formulario de búsqueda: no creo que debe ser considerado parte de
este módulo; más bien creo que un formulario de búsqueda
suficientemente poderoso para las necesidades de administración de un
catálogo debe venir ya incorporado en Catalis desde el vamos,
posiblemente como una opción "búsqueda avanzada", dejando el
formulario simple para búsquedas... bueno, simples. A modo de muestra,
véase esta versión (en desarrollo) del formulario avanzado para el
OPAC del Museo Mitre:

http://www.museomitre.gov.ar/cgi-bin/opacmarc/wxis?IsisScript=opac/xis/opac.xis&db=mitre&showForm=advanced

(Aún no funcionan correctamente todas las búsquedas, pero me interesa
que vean el diseño del form.)

2) Criterios para ordenar los registros: también debe ser parte de la
funcionalidad básica para Catalis, y como muestra nuevamente tenemos
el OPAC:

http://catalis.uns.edu.ar/cgi-bin/catalis_pack_demo_devel/wxis?IsisScript=opac%2Fxis%2Fopac.xis&db=bibima&searchType=TITLE&query=control+theory

("Mostrando 1-20 de xx resultados, ordenados por...")

3) Impresión de un rango, de todos los resultados, de una selección de
los resultados: estamos de acuerdo, sólo que hay un par de detalles
que añaden una complicación. El primero es la presentación de los
resultados en forma paginada; siempre me pareció que eso puede
complicar la selección cuando a uno le interesan registros de más de
una página. En todo caso, tal vez habría que añadir la opción de
imprimir todos los registros de una determinada página de resultados.
Otro posible inconveniente: la definición de "rango". En Catalis hemos
tratado de no depender del MFN e identificar a los registros por el
campo 001 (número de control); con el tiempo inevitablemente ambos
identificadores tienden a desfasarse, y el MFN deja de ser útil como
criterio para recuperación de registros (salvo tal vez por el hecho de
que "MFN grande" es algo así como "registro nuevo", y "MFN chico" es
como "registro viejo"). Entonces al hablar de "rango" deberíamos
pensar en el número de control, ¿verdad?

5) Uso de PFT externo: entiendo que la idea es que el usuario pueda
especificar, a su gusto, el formato de impresión, en caso de que los
formatos ofrecidos no cubrieran sus necesidades. Veo algunas
cuestiones a resolver y conversar para llegar a implementar esto. Será
objeto de una futura discusión.

6) REF-LookUp a otras bases: acá pido que me ayudes a ver un caso
práctico. Entiendo el concepto en el contexto Winisis, pero necesito
verlo aplicado en Catalis.

7) Asistente para crear formatos: me gusta la idea, y habrá que
analizarla junto con el punto 5. Gracias por el pointer a Genisis,
tendré que mirar ese asistente.

8) Comandos de presentación: de acuerdo (pero con baja prioridad).


Dejé para el final los dos puntos sobre los que recapacitó Ariel. :-)

4) Almacenamiento de búsquedas, DSI: interesante tópico, da como para
abrir también una nueva discusión. Tiro lo primero que se me ocurre
ahora: al mostrar los resultados de una búsqueda, se activaría (p.ej.
en un menú) la opción "Guardar esta búsqueda". Cuando el usuario
selecciona esa opción, el servidor almacena en una base ad hoc (que
podremos llamar "busquedas") los siguientes datos: expresión de
búsqueda, nombre de la base, id del usuario, fecha y hora, cantidad de
resultados. Además, se le ofrece la posibilidad de marcar la opción
"Generar DSI", lo que agregaría la marca "DSI" para esta búsqueda en
particular. Más tarde, el usuario puede recorrer la lista de búsquedas
almacenadas, filtrar aquellas que tienen la marca "DSI", eliminar las
que no necesita, ... Y no digo qué tendrían de especial las búsquedas
marcadas con "DSI", porque aún no se me ocurre de qué manera descubrir
los "nuevos resultados". De la misma manera que en nuestro OPAC
necesitamos una definición adecuada de "nuevo material" para poder
generar esto en forma dinámica:

http://catalis.uns.edu.ar/cgi-bin/catalis_pack_demo_devel/wxis?IsisScript=opac/xis/opac.xis&db=bibima&task=SHOW_NEW_MATERIAL

en Catalis necesitaríamos decidir si llamamos "nuevo" a un registro
creado recientemente, o bien a un registro que describe un recurso
adquirido recientemente, etc.


9) HTML, RTF, etc: tendría que ponerme a pensar con más detenimiento
sobre la conveniencia de uno u otro formato, pero creo que
técnicamente no hay inconvenientes en generar cualquiera de ellos,
incluyendo PDF. Y gracias por mencionar TeX! ¿Tenés en mente algún
motivo específico para requerir TeX? Yo siempre pensé que si alguna
vez tuviéramos que generar un catálogo impreso (o listados parciales,
a modo de sub-catálogos), habría que hacerlo con (La)TeX, que nos
asegura una calidad tipográfica notable, aunque me doy cuenta de que
eso sólo es "natural" para alguien que viene del campo de la
matemática y afines. De todos modos, BibTeX existe y se usa, así que
las bibliotecas --al menos las dedicadas a esas ciencias-- deberían
llevarse bien con ese formato. Me gustaría conocer tus opiniones,
Ariel.


Finalmente, dejo unos comentarios acerca de la superposición de
funcionalidad entre Catalis, el sistema de administración del
catálogo, y el OPAC, la cara pública del catálogo. Varias de las
cuestiones que estamos charlando acá, serían igualmente deseables para
un OPAC, dejando en manos del usuario final de la biblioteca la
generación de listados e incluso la suscripción a un servicio de DSI
basado en email o RSS. De hecho, creo que las posibilidades de
explorar las bases de datos, y extraer información de ellas en
diversos formatos, deberían ser en gran medida equivalentes entre
ambas aplicaciones. La principal diferencia, en cuanto a
funcionalidad, es que el sistema de catalogación permite crear,
modificar y eliminar datos, así como acceder a otros datos que son
sólo para uso interno de la biblioteca. Así que aquí dejo otro tema
abierto para la discusión...


Saludos.


--
Fernando

Ariel Otero Estrada

unread,
May 14, 2008, 6:04:39 PM5/14/08
to cat...@googlegroups.com
Hola Fernando

> Tengo que acordarme...
Sí, a veces me entusiasmo y escribo demasiado... ;-)

> 1) Formulario de búsqueda: no creo que debe ser considerado
> parte de este módulo; [...] debe venir ya incorporado en Catalis
> desde el vamos ...

> 2) Criterios para ordenar los registros: también debe ser parte de
> la funcionalidad básica para Catalis, y como muestra nuevamente
> tenemos el OPAC...

Quizá tenga (yo) un problema con la definición de módulo.
Digo: Catalis puede tener varios módulos ("Módulo de Registro del Material Bibliográfico", OPAC, "Módulo para Listados", "Módulo para DSI" (je, ahora lo separé...), "Módulo para el Control y Seguimiento de las Adquisiciones y de la Enajenación de Duplicados y Descartes"... ). Cada uno de esos módulos puede compartir uno o varios scripts, funciones, rutinas o como se guste llamar a esos conjuntos de instrucciones.
¿Estoy equivocado?

Bien, pero eso no significa que esos módulos estén también conectados en el ámbito de la interfase a los usuarios. ¿Estoy equivocado bis?

Para poder imprimir un listado, tengo que poder hacer una búsqueda y tengo que poder ordenarla. En esto creo no equivocarme y parece que aceptás lo mismo.

Pero no me queda claro algo de tu texto. ¿Pensás que el módulo de listados debe ser un agregado al OPAC? Por las dudas, levanto la mano, paso al frente y digo que no me gustaría que un usuario del OPAC pudiera saltar así nomás a la posibilidad de meterse en este módulo... Obviamente tiene que poder imprimir un listado desde el OPAC. Está bueno que el OPAC le dé la opción de mostrarlo ordenado por algunos criterios básicos.
Pero yo veo al "Módulo de Listados" como otra cosa,. Como una herramienta administrativa. Para la cocina, vio.

Muchas veces hay que hacer listados con datos de la base y que nada tienen que ver con lo que se ve en el OPAC.

------------------

> siempre me pareció que [ se ]  puede complicar la selección cuando a uno le
> interesan registros de más de una página.

¿Un carrito, tal vez? O una página con muchos registros. Si se van a seleccionar, uno a uno, registros de una búsqueda con centenares de resultados es que no se supo hacer la búsqueda.
Podría darse la opción de selección sólo si el número de registros retornados es, por ejemplo, menor a 100.

------------------


> Entonces al hablar de "rango" deberíamos
> pensar en el número de control, ¿verdad?

Claramente

------------------

> Uso de PFT externo [...] en caso de que los formatos ofrecidos no cubrieran
> sus necesidades.

No las van a cubrir. Surgen problemas y hay que encontrarle soluciones en el momento. Imposible pensar de antemano en todas las posibilidades.

------------------


> 6) REF-LookUp a otras bases: acá pido que me ayudes a ver un caso
> práctico. Entiendo el concepto en el contexto Winisis, pero necesito
> verlo aplicado en Catalis.

Puedo necesitar bases auxiliares para otras tareas que Catalis aún no haga. Como ves ya no limito su campo de acción futuro. Pero el futuro perfecto es lejano y hay un mientras tanto imperfecto que quizá requiera otras cosas. Imaginá que querés llevar un control de a qué instituciones le estás enviando los duplicados y descartes de tus libros. Querés tener también un control de qué recibiste de cada quién a cambio de tus libros.
Puede parecer una vanalidad, pero por experiencia digo que un control adecuado de este tipo hace que sea más sencillo que las autoridades de tu institución acepten dar de baja obras inventariadas. Siempre es una responsabilidad y nadie quiere poner la firma. Pero si mostrás en forma transparente todo el proceso (incluso en la web), podés reformar la situación del descarte y liberar los depósitos de lastre. Pasa en muchas instituciones.

Ahora, para eso creo una base de instituciones, con sus datos administrativos (nombre, campo de acción, domicilio, teléfonos, mail, contactos, horarios...) y los números de inventario de los volúmenes físicos intercambiados (pueden ser muchos ejemplares por cada título) y algunas notas para cada uno. En la base de instituciones podré ver los datos bibliográficos mediante un Ref-LookUp a la base bibliográfica. Cuando imprimo listados de los libros intercambiados... ¿Uso MX o Winisis?  ¿Uso el "Módulo de Listados de Catalis"?  La idea sería usar Catalis. Para eso necesito hacer un Ref-LookUp a la base de instituciones. Probablemente necesite además incluir estas instrucciones en ambas FST de inversión para poder hacer búsquedas de los libros canjeados y de las instituciones receptoras/proveedoras.

Es un ejemplo real de cosas que se hacen en bibliotecas. No en todas, es cierto...

La base de instituciones "cooperantes" bien podría ser parte de otro módulo de Catalis (en su camino hacia ser un sistema integral), pero las relaciones entre bases son imprescindibles.  Aclaro que cargar todo en el registro bibliográfico es una chanchada o dicho más cortésmente: carece de elegancia y afecta a mi gusto refinado. Especialmente si hay muchos ejemplares y/o volúmenes de descarte para una misma edición de un título.

Escribo demasiado... y los otros callan... los aburrí...

------------------


> 8) Comandos de presentación: de acuerdo (pero con baja prioridad).
Media...? Lo bueno, si lindo, es más mejor...


-------------------


> 4) Almacenamiento de búsquedas, DSI: interesante tópico,
> da como para abrir también una nueva discusión.

Más allá del almacenamiento de búsquedas, que es útil por si mismo. El DSI da para otro módulo...
Podría incluir la salida por mail de los listados sin intervención del bibliotecario. Los define y listo. Todos los días 1 del mes, incluido mayo, recibe el mail con las novedades... 

Ojo, en prioridades, creo que el DSI es más útil para disciplinas humanísticas y sociales (que usan más libros) que para las ciencias "duras" donde las novedades llegan por otra vía. Para mi pesar no he trabajado mucho con bibliotecas de ciencias duras, así que otros dirán...

------


> DSI: [..] Cuando el usuario selecciona esa opción, el servidor almacena
> en una base ad hoc (que podremos llamar "busquedas") los siguientes
> datos: expresión de búsqueda, nombre de la base, id del usuario,
> fecha y hora, cantidad de resultados.
 
Los datos que se necesitan, se me ocurre que son:
id de la esta definición de búsqueda para DSI, expresión de búsqueda, nombre de la base, id del usuario (? no sé..), "fecha juliana" de la última búsqueda (inicialmente cero), cantidad de resultados, id del destinatario del DSI.
 
.. y una base de usuarios con sus datos, incluida la dirección de correo a la que enviaremos el resultado
 
--------------
 
> ...aún no se me ocurre de qué manera descubrir los "nuevos resultados".
 
Yo guardaría en un campo del registro bibliográfico la fecha juliana del día de la última modificación importante. Inicialmente sería la fecha de creación del registro. Luego participan de la DSI los registros que tienen una fecha juliana posterior a la de la última DSI.
  
----------------

> Y gracias por mencionar TeX! ¿Tenés en mente algún motivo
> específico para requerir TeX?
Sólo lo mencioné para agradar al líder   ;-)
 
------------
 
> Yo siempre pensé que si alguna vez tuviéramos que generar un
> catálogo impreso (o listados parciales, a modo de sub-catálogos),
> habría que hacerlo con (La)TeX, que nos asegura una calidad
> tipográfica notable, aunque me doy cuenta de que
> eso sólo es "natural" para alguien que viene del campo de la
> matemática y afines.
 
Alguna vez hice una obra de referencia en una base isis. Un diccionario biográfico, para más datos. Una biografía (texto completo) por registro.
Luego se imprimió en formato libro y para eso saqué un RTF. Como el RTF llevaba todas las marcas de presentación (negritas, itálicas,...) El diccionario casi quedó listo. Pero tuve que pasarlo a PageMaker para componerlo, que quedara a dos columnas, que controlara viudas y huérfanos... Usando TeX / LaTex pienso que hubiera podido sacar el documento final directamente desde la salida de Winisis.
 
Muy lindo, pero en el ambiente MARC no creo que tenga una utilidad grande.
 
 
> De todos modos, BibTeX existe y se usa, así
> que las bibliotecas --al menos las dedicadas a esas ciencias--
> deberían llevarse bien con ese formato.
 
Nunca lo usé pero parece una salida típica de un formato etiquetado. No parece nada complicado. Sería un formato de impresión más que podría entregarse con la distribución de Catalis.
 
 
------
Bien, no molesto más... Más que nada porque se lavó el mate y tengo que ir a cambiar la yerba...
 
 
Saludos
 
 
Ariel
 
 
 


 
Reply all
Reply to author
Forward
0 new messages