IAH UN POCO AVANZADO PARA USUARIOS AVEZADOS

lo mejor es enemigo de lo bueno

Exposición de Ernesto Spinak

Notas tomadas por Mónica Ugobono y Alberto Rosenbeg

14-15 octubre 2010

 

 

Primer día

 

o        IAH relacionado con ABCD

 

El tema a desarrollar es el IAH relacionado con ABCD. Si bien el paquete de ABCD incluye el Secs-Web y el editor ABCD Site (una particularidad del ABCD Site es el metabuscador), estos podrían no utilizarse. Lo que sí es imprescindible para habilitar un OPAC es conectar con iAH al módulo central de ABCD.

 

Se recomienda verificar estas notas con el manual oficial de iAH version 3.1, disponible en http://bvsmodelo.bvsalud.org/php/level.php?lang=es&component=27&item=13 , bajo el ítem “Manuales”.

 

o        Herramientas web de bireme

 

Las aplicaciones FOSS de Bireme se encuentran bajo la página de la Red de Desarrolladores: http://reddes.bvsaude.org/php/index.php. Allí están los wikis y los tickets en svn para todas las aplicaciones (IAH, Secs-Web, ABCD...

 

Hay además un Wiki técnico para los aplicativos de Bireme:

http://wiki.reddes.bvsalud.org/index.php/Especial:Allpages

 

 

o        Comenzando con ABCD

 

Para manejar la interface IAH tenemos dos archivos:

1) iah.def.php          ambiente de trabajo para todas las bases

2) <base>.def         cada base de datos tiene su propia configuración

 

La configuración general está debajo del directorio /abcd/www/htdocs/iah/scripts

1) El archivo iah.def.php da la configuración general a todas las bases, es posible tener más de una configuración.

Puntos críticos:

Al instalarlo en el servidor:

• ·         se tiene que configurar path_cgi-bin y path_database
• ·         luego hay una serie de configuraciones del HEADER e IAH que no son obligatorias

 

Ejemplos:

IDIOMA: Si se quiere utilizar solo un idioma, se pueden borrar los otros subcampos de idioma dejando únicamente el subcampo que se desea.

La posición de los códigos de idioma en AVAILABLE LANGUAGE corresponde a cada subcampo del HEADER.

AVAILABLE, es, en, fr

Por eso español es el ^2.

ICONOGRAFIA: iah/scripts/es/images todos los gráficos correspondientes al idioma

 

2) El segundo archivo estructural es el de cada base de datos base.def

/abcd/www/bases/par

Cada base de datos creada tiene un archivo .par, ejemplo: pepe.par

Las bases que son consultadas con iah tienen un segundo archivo PEPE.def creado por el iah. Este archivo tiene los parámetros de cómo va a ser tratada la base con el iah.

De modo que para cada base de datos se encontrarán dos archivos con el nombre de la base, uno con extensión .par y el otro con extensión .def, este último debe escribirse su nombre con letras mayúsculas.

 

 

o         Versatilidades del IAH

 

Existen distintas arquitecturas dentro de la familia Isis, que dependen de la dimensión del MST, y los tamaños de registros, y la longitud de las claves en los archivos invertidos:

Cisis1030	Mst 512mb – 4 GB	Claves 10/30 (se mantiene por compatibilidad con winisis)
Cisis1660 ABCD	Mst 512 a 4Gb	Claves 16/60 (indización incremental, se actualiza en línea) Y otra tecnología que se llama LIND: más robusta, más estable pero no es incremental. Bireme produce con cisis1660 y muestra con Lind
Cisisffi	4lgb mst de 256 gb para plataforma Linux	Indización LIND

 

El metabuscador de IAH acepta todas las tecnologías de MST y de archivos invertidos automáticamente. Se puede configurar para leer las bases propias y las externas. Es un protocolo común de bases Isis.

 

El IAH puede trabajar con solamente un archivo invertido o con múltiples archivos invertidos, esto para reducir los requerimientos del servidor. Puede haber un archivo invertido por cada prefijo usado en la FST. Estos diccionarios, uno por cada índice, se generan utilizando el MX en línea de comando o en un script que corra bajo Cron (Linux) o en tareas programadas (Windows).

 

 

o        Procedimiento de configuración de IAH usando ABCD

 

Se accede al menú de la actualización de la definición de la base.

Permite configurar el archivo BASES.def de cada base de datos de ABCD.

Se puede trabajar sólo con el subcampo del idioma elegido, por ejemplo el ^2 (español)

 

FILE LOCATION configura las rutas de los archivos de la base de datos.

Es posible generar una línea INDEX para cada prefijos de la FST. Si se tienen muchos archivos invertidos se puede configurar cada prefijo apuntando a su archivo invertido.

 

IAH viene con hasta 3 interfaces de consulta: consulta simple (tipo Google) y 2 formularios avanzados.

AVAILABLE FORMS=A, B, F

Se puede tener un formulario, dos o tres y se coloca la letra identificatoria en el orden que se quiere que aparezca. La primera es la que se muestra por defecto.

 

AYUDAS

Es posible colocar varias ayudas dentro de los índices y en cada formulario.

Es posible tener ayuda de tres formas:

 

Help.htm       ayuda general del sistema

Nota F, nota A, nota B para cada interfaz

Y también una nota para cada índice.

 

Se registran en la parte que se llama HELP_FORM

 

HELP FORM=help...htm

NOTE FORM F=

NOTE FORM A=

NOTE FORM B=

NOTE INDEX TW= del subcampo x

 

Se guarda en /abcd/www/htdocs/iah/%lang%/help

Cada base tiene su paquete de ayudas. Son archivos html por lo tanto se puede poner un manual, enlaces a archivos, o videos de youtube, etc.

 

o         INDEX DEFINITION

 

Se puede no querer que todos los índices aparezcan en el mismo nivel de consulta.

En el subcampo f se configura cuáles índices se utilizan en el básico y en el avanzado.

Si el subcampo f contiene a significa que los índices están activos solamente en el formulario avanzado pero no en el básico.

 

Se puede tener una base con más de un archivo <BASE>.def: en uno se habilitan unos campos para el formulario avanzado y en el otro, se habilitan campos diferentes.

Se le da un nombre a cada def apuntando a carpetas diferentes para los archivos invertidos, con un mismo MST.

En FILE_LOCATION

FILE INVERTED= el camino del invertido y sus archivos

 

o        Estilos:

 

../Iah/css

Hay cuatro archivos de definición de estilos en cascada

 

General: da la estructura básica del archivo con elementos básicos de la definición.

Layout: dimensiones de los componentes y algunos elementos de espacio y gráficos.

Style: tamaño de letras y colores.

 

Son varias hojas, la última es la que vale porque se van superponiendo.

 

Ejemplos simples:

 

CSS

 

general.css

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

color de fondo

BODY  {  background-color :  #e0e0e0;

}

 

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

texto principal

BODY  {  background-color :  #e0e0e0;

          margin: 0px;

          color: magenta;

}

 

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

Links a páginas HTML

A { color: green;

}

A:visited{  color:  red; }

 

A: hover  {

         color: cyan; font-stye: bold;

}

 

 

layout.css

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

div.barNav {

      clear: both;

      background: red;

}

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

div.barNavTop {

      clear: both;

      background: green;

}

 

styles.css

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

.middle .formHead {

         background: black;

}

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

.defaultButton {

        color: #036;

        text-decoration: none;

        border: 4px solid #1e5991;

        background: white;

        font-weight: bold;

}

 

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

o        Uso de javascripts como parte de un formato

 

Por ejemplo poner un link que permita ver los mapas de estantes de la biblioteca.

Ver ubicación en el mapa de estante.

 

Cómo se consultan los mapas desde el registro:

 

En el formato del registro hay una llamada a una función javascript La definición de la función se coloca una vez y no en cada registro. Hay que colocar la llamada a la función y no la función misma. La función se declara en la definición de la página web, en el modulo /htdocs/iah/scripts/%lang%/ahhead.pft y después se puede llamar desde todos los formatos.

Hay tres lugares posibles donde colocar funciones, la preferencia es en el archivo ahhedad.pft

<head>   </head>

acá es correcto colocar las funciones de javascript

 

Los objetos que son llamados por el javascript (en este caso son mapas, pero podrían ser cualquier tipo de archivos) deberían estar en un directorio separado de la instalación. En ABCD Site se usa la carpeta /htdocs/local, y en el caso de Linux puede darse permisos 777.

 

o        Exportación en xml

 

Para exportar en xml hay que disponer un formato de salida predefinido. Hay una demo en la base dblil. Ver libxml.pft

 

Para que quede habilitado, hay que definirlo en <BASE>.def PREFERENCES FEATURES=XML

 

Para quitar la opción xml de la interfaz:

 

En /htdocs/iah/scripts/es/ahsend.htm

buscar v5018¨f  : ‘XML’ comentar estar opción y no aparece el exportar a xml.

 

 

 

Segundo día

 

o        Lateral Search

 

La búsqueda lateral es un procedimiento para realizar búsquedas dentro de la base desde los resultados de una búsqueda anterior, usando hipertexto desde términos claves (descriptores, autores, etc.) Es similar a las antiguas referencias de “véase también, o véase además”.

 

Se hace utilizando un formato que está en la distribución como modelo para la base DBLIL usando un formato llamado descritores.pft. El modelo usa el campo v87 que corresponde a descriptores en LILACS, por lo cual deberá ser adaptado a cada caso.

El formato usa un campo virtual: V5003 que transfiere el nombre de la base activa, además de una serie de parámetros para construir la URL de consulta

&expSearch= campo con los términos a buscar.

IndexSearch= índice para recuperar los términos datos expSearch.

Parámetros de metabúsqueda definidos en ABCD site.

 

o        Problemas tecnológicos, mezcla de tecnologías:

 

La estructura Isis es una estructura ISAM (Indexed Sequential Access Method). Esto significa que tenemos un archivo de datos (MST), registros de largo variable y punteros que nos dan la dirección de los registros (XRF), más lenguaje de extracción de datos (PFT).

 

La arquitectura de archivos invertidos (Salton) se implementa en el MicroIsis como dos bloques Btree* de rango 10 formados por un archivo CNT y los L01 y N01 y L02, N02 con el IFP.

 

¿Cómo funciona el Isis?

Puede encontrar información más completa en el documento: Conceptos Básicos de Bases de Datos CDS/ISIS: Iniciando el Uso del CISIS

http://bvsmodelo.bvsalud.org/download/cisis/CISIS-ConceitosBasicos-es.pdf

 

Está formado por los archivos MST y XRF que contiene los datos, y éstos son totalmente independientes del archivo invertido.  Cuando se crea un registros se crea al final del MST. Ahora al editar un registro, éste se copia al final y el anterior queda eliminado pero el puntero XRF actualiza los datos en el MST.

 

Periódicamente, dependiendo de la edición, hay que comprimir el MST para limpiar el “garbage” que deja la edición.

 

¿Cómo funciona el archivo invertido?

 

mx cds fst=@   fullinv=cds

 

Ejemplo pasos:

 

Registro nuevo:

-          al grabar y actualizar extrae todos los postings definidos por la FST.

-          Para cada expresión diferente que es una clave se abre un nodo

-          y para cada uno, una lista encadenada de posting.

 

Para una actualización de registro,

• coloca una versión nueva del registro al final del MST con un puntero hacia atrás ala versión antigua.
• Va a la FST, extrae todas las claves del registro viejo,y borra las que estaban;
• después va al nuevo registro y genera todas las claves nuevamente.
• Actualiza la lista de posting
• Borra el semáforo del XRF

 

Por cada término de una clave se tiene una lista ordenada con los postings que se ensambla en el archivo IFP.

 

Si el término está creado a nivel de los nodos, agrega el posting en su orden de la lista, si no lo debe agregar recorriendo el árbol e insertando el término agregando el posting. Esto por cada una de las claves.

 

El IFP se bloquea y se libera al terminar la operación. Si en el XRF está el flag en 1, espera a que se actualice.

 

Todo este proceso en Windows es peor que en Linux. Por eso en el caso de bases con FST grandes, multiusuario, bajo sistema Windows: no conviene actualizar en línea, sino usar una FST sucedánea muy breve.

 

Estrategia: separar los procesos internos de los externos

 

En la carpeta /bases/par tener dos DBN.def (DBN.def y DBN1.def) para que el OPAC esté separado de la catalogación. Conviene utilizar una FST corta para procesos internos y una FST bien detallada para el público. Se puede compartir el MST y el archivo invertido o separar los archivos invertidos totalmente. En este último caso la actualización para el OPAC deberá programarse como proceso automático con la frecuencia necesaria.

 

A futuro lo que va a permanecer de la estructura actual son los datos y los formatos (MST/XRF/PFT) , en cambio la estructura de postings usada va a ser sustituída por la tecnología de Lucene.

 

Si la biblioteca es de tamaño considerable, digamos más de 10 o 15 mil registros, no es conveniente utilizar el método de las autoridades virtuales que permite ABCD (la misma base de datos como fuente del pick-list), es mejor utilizar bases de datos de autoridades reales, es decir usando una base de datos aparte de la de carga.

 

 

o        Archivos invertidos (IF) tecnologías

 

1030 y 1660: usan el mismo modelo: hojas, nodos y postings.

 

LIND es un tecnología diferente, sustituye los postings por un string (cadena) de bits, esta cadena tiene tanto largo en bits como registros la base de datos.: 10000 registros, 10000 bits.

 

El concepto de ocurrencias y distancia entre palabras no existe. Sólo tiene MFN con prefijo asociado a un string bit. Esto le permite actuar mucho más rápido y ocupar menos espacio. Tiene el bit posicional marcado o encendido (1), el reg en donde aparece el término y las consultas de AND y OR se producen por intersección de bits.

 

 

o         Comparación de Archivos Invertidos en CISIS 1660 y LIND

 

Base de ejemplo: 46.516 registros

Tecnica	I/F	Short keys	Long keys	Total postings	Nro. terminos	File size
1660 un I/F	wbaeu	6.151.229	569.958	6.721.187	270.259	71.377.004
1660 múltiples I/F	words	4.100.985	478.704	6.993.167	66.187	37.278.168
	main	1.946.248	478.704		122.019	29.174.372
	adicional	390.082	1		62.909	6.185.552
	total	6.437.315	555.852		251.115	72.638.092
LIND un I/F	wbaeu	6.151.229	569.958	4.655.071	270.259	22.754.224
LIND múltiples I/F	words	4.100.985	478.704	2.449.229	66.187	7.410.088
	main	1.946.248	478.704	1.983.294	122.019	12.120.008
	adicional	390.082	1	379.705	62.909	2.697.664
	total	6.437.315	555.852	4.812.228	251.115	22.227.760

 

Si además separo los archivos invertidos, tengo archivos pequeños con un invertido simple y muy rápido.

 

Por cada base se abren 8 archivos (6 archivos por cada invertido, más el .MST y el .XRF) al realizar una consulta se recomienda utilizar la aplicación MKIY0 que comprime los 6 archivos del archivo invertido en solamente uno. Dejando sólo 3 archivos, pero esto sólo sirve para consultar.

 

 

o        Formatos inteligentes

 

ABCD tiene un utilitario para generar formatos estándares sin complicaciones. Pero si se quiere utilizar el formato estándar con modificaciones adicionales, en la carpeta con los formatos de la base /bases/<base>/pft/%lang%/<base>.pft, el archivo tiene las instrucciones html incrustadas entre los comandos del formato.

 

Por facilidad de mantenimiento se recomienda separar los datos del estilo. Para hacerlo hay que utilizar una instrucción de CISIS: proc(  ), que también funciona como formato. Todo lo que ocurre en un proc es un registro virtual.

 

Es un comando que también funciona como formato.

 

proc ( <9001>         etiqueta        </9001> <9002>         dato             </9002> ),              tabla //@tabla.pft

Label dato virtual, puedo manipular los datos y crear campos virtuales     datos expresados en una tabla, y en tabla.pft está armado el estilo.

 

Ejemplo

proc ('d*', mpl if p(v18) then '<9001> Título </9001>', '<9002>', v18 </9002>', fi ) @LABELGREEN.PFT

No hay que preocuparse de los estilos. Así se evita colocar códigos de HTML en los formatos.

 

Usando el formato externo

 

'<table width="100%" border="0">'/,

   ( if p(v9001) then

   '<tr >',

      '<td align="left" width="17%" valign="top" >',

          '<font color="green" size=2 ><b>',  v9001,    '</b>',  '</font>',

      '</td>',

 

      '<td valign="top" width="83%"  >',

       '<font face="arial" size=2>', '<div style="text-align: justify">',  v9002, '</div>'  '</font>',

      '</td></tr>',

   fi/ ),

'</table>'/,

'<p>'/,

 

Este formato debe documentarse en el archivo BASES.def

 

 

Fin de las notas