Como indexar registros de una base MARC de ABCD para buscadores en Internet.

El propósito de una base bibliográfica gestionada mediante un catálogo, es poner a disposición su información para los usuarios y otros sistemas. En este contexto, mientras más visibilidad tengan nuestros registros entonces existe mayor posibilidad de que los usuarios encuentren lo que están buscando, y como sabemos, en la actualidad los motores de búsqueda como Google son muy frecuentados para estos fines; entonces, ¿Porque no poner nuestros registros MARC de nuestra base de datos en buscadores como este? después de todo, Google indexa todas las páginas HTML (u otras estructuras basadas en etiquetas) de Internet que cumplan con un estándar, caso similar de lo que ocurre con repositorios en los cuales sus metadatos están disponibles en una estructura estandarizada de etiquetas que permite que sean encontrados.

Para quienes conocemos un poco el sistema ABCD, sabemos que sus registros se encuentran administrados por un motor ISIS que gestiona la creación y edición de la información con la que puede estar alimentada una base de datos bibliográfica, dichos registros son almacenados en archivos de texto .mst y .xrf., pero estos no son visibles en Internet o por motores de búsqueda, y en realidad eso está bien, ya que esa es la función de una base de datos, almacenar los registros de una manera ordenada / lógica y tenerlos a disposición de programas intermedios que gestionan la visibilidad de los mismos hacia los usuarios y otros sistemas.

Para nuestro caso en particular, y como objeto de esta entrada, se trata de extraer los registros de una base de datos en estructura MARC de ABCD para que puedan ser indexados por motores de búsqueda usando una disposición de etiquetas HTML y estructuras del estándar Meta Tags de Dublin Core (http://www.metatags.org/dublin_core_metadata_element_set) con los datos de cada registro. Además, se presentarán bloques de código que indican en líneas generales como programar un módulo PHP que realice la tarea.

A continuación un esquema de lo que se pretende:

Estructura del proceso de extracción y conversión de los registros MARC a HTML

Como se visualiza en la esquema, se tiene el siguiente proceso:

1. Extracción con mx: se extraen los registros de la base MARC del sistema ABCD mediante el utilitario mx recorriendo todos los MFN existentes.
2. Formateado del registro: Cada registro extraído por mx es formateado para armar la estructura HTML con Meta Tags utilizando los datos de ese registro.
3. Conversión del registro: el resultado es manipulado por código php que permite la conversión previa de caracteres y el guardado del registro en un archivo con extensión .html.
4. Publicación: todos estos archivos generados son almacenados en una carpeta pública en Internet que puede ser visible por buscadores y usuarios.

Extracción con MX.

Los registros deben ser extraídos de la base MARC mediante una sentencia de comando que ejecuta el utilitario mx pidiendo la extracción de un registro de una base determinada con un formato específico, el comando mx es:

     [directorio mx]\mx [directorio data de base marc] marc from=1 to=1 pft=@[directorio del archivo PFT] -all now

Por lo general la sentencia en entornos windows resulta:

     C:\ABCD\www\cgi-bin\mx C\:ABCD\www\bases\marc\data marc from=1 to=1 pft=@C:\ABCD\www\bases\narc\pfts\es\conversor.pft -all now

Si hemos instalado ABCD es probable que el directorio de mx esté incluido en la variable de sistema Path, lo cual no hace necesario especificar el directorio al momento de ejecutar el comando. Por otro lado, las propiedades from= y to= especifican el rango de MFN a ser extraídos, para nuestro ejemplo, estos deben ser especificados de uno en uno de manera automática. Finalmente, el archivo conversor.pft contiene el formato HTML y de Meta Tags que serán aplicados a la información del registro.

Para poder extraer todos los registros de manera automática, usaremos un módulo de PHP que ejecutará el comando y recibirá el resultado en un array, al archivo lo llamaremos conversor.php:

• Primero, debemos saber el total de MFNs de la base. Estoy seguro que el proceso que presento a continuación puede ser mejorado por un experto en ABCD, el conversor.php debe contener:

<?php

//DECLARAMOS LAS RUTAS DE WXIS.EXE, MX Y DEL DIRECTORIO DE LAS BASES DE DATOS

$ruta_isis = "localhost:9090/cgi-bin/wxis.exe";

$path_mx = "C:/ABCD/www/cgi-bin";

$db_path="C:/ABCD/www/bases/";

//RECUPERO CANTIDAD DE MFN DE LA BASE, BUSCAR PROCESO MÁS SIMPLE

$url = $ruta_isis."/?IsisScript=conversor/mfn.xis";

get_file($url,"","mfn.txt");

$gestor = fopen("mfn.txt", "r");

$contenido = fread($gestor, 512);

fclose($gestor);

$posicion_mfn = strpos($contenido,"|");

$mfn = substr($contenido, 0, $posicion_mfn);

function get_file($file, $local_path, $newfilename) 

{

//función de prueba para extraer MFN

$out = fopen($local_path.$newfilename,"wb");

$ch = curl_init(); 

curl_setopt($ch, CURLOPT_FILE, $out); 

curl_setopt($ch, CURLOPT_HEADER, 0); 

curl_setopt($ch, CURLOPT_URL, $file);

curl_exec($ch); 

curl_close($ch);

}

?>

El código extrae la cantidad de MFNs de la base consultando un archivo mfn.xis que debe estar en el sistema ABCD (la ruta del archivo está especificada en el código) que contiene lo siguiente:

<IsisScript>

<section>

<display><pft>'Content-type: text/html'/#</pft></display>

<do task = mfnrange>

<field action=define tag=1010>Isis_Total</field>

<parm name=db>marc</parm>

<parm name=from>1</parm>

<parm name=to>1</parm>

<parm name=cipar>

<pft>

'marc.*=C:\ABCD\www\bases\marc\data\marc.*'/

</pft>

</parm>

<loop>

</loop>

<display><pft>

v1010,'|'

</pft></display>

</do>

</section>

</IsisScript>

Si corremos el archivo conversor.php en un explorador web, tendremos una variable $mfn que contiene la cantidad de registros de la base ABCD que deben ser procesados iterativamente.

• Segundo, adjuntamos al código de conversor.php el procesos que extraerá los MFNs:

//PROCESO DE CREACIÓN DEL HTML EN BASE A LA CANTIDAD DE $mfn

$contador = 1;

while ($contador <= $mfn)

{

//sacamos cada registro de la base marc usando un PFT con el formato en HTML y estructura meta tag de DublinCore

$mx = $path_mx."\mx ".$db_path."marc/data/marc from=$contador to=$contador pft=@C:\ABCD\www\bases\marc\pfts\es\conversor.pft -all now 2>&1";

exec($mx, &$outmx);

$nuevoarchivo = fopen($contador.".html", "w+");

$posiciones_array = count($outmx);

$contador_posiciones = 0;

while ($contador_posiciones <= $posiciones_array-1)

{

//Guardo cada salida del array convirtiendo la codificación

$outmx[$contador_posiciones] = mb_convert_encoding($outmx[$contador_posiciones], "UTF-8", "ascii");

fputs($nuevoarchivo,$outmx[$contador_posiciones]);

$contador_posiciones ++;

}

fclose($nuevoarchivo);

$outmx = NULL;

$contador ++;

}

Formateado del Registro.

El bloque de código recién adicionado, hace el llamado al comando mx que extrae los registros de manera interativa recorriendo el total de MFNs de la base usando un archivo conversor.pft que contiene el formato para el archivo HTML a ser generado.

Hay que tener en cuenta que lo que se pretende hacer es que conversor.pft arme la estructura de tags HTML y Meta Tags de Dublin Core usando la información de cada registro, para esto se llama a cada campo de la base MARC en cada etiqueta correspondiente de meta tag. En cada caso, y para cada base, se tendrán campos diferentes ya que se pretende que este método no solamente funcione para bases MARC si no para estructuras de cualquier tipo que se creen en ABCD.

Un ejemplo corto de lo que se extrae usando conversor.pft es:

'<html>'/
'<head>'/
'<title>'mfn(6)'</title>'/
'<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">'/
'<meta name="Generator" content="ABCD">'/
'<meta name="viewport" content="width=device-width, initial-scale=1.0">'/
'<link rel="schema.DCTERMS" href="http://purl.org/dc/terms/">'/
'<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">'/
if p(v100) then '<meta name="DC.creator" content="'v100^a'">' fi/
if p(v700) then '<meta name="DC.creator" content="'v700^a+|"><meta name="DC.creator" content="|'">' fi/
if p(v110) then '<meta name="DC.creator" content="'v110^a'">' fi/
if p(v710) then '<meta name="DC.creator" content="'v710^a+|"><meta name="DC.creator" content="|'">' fi/
'<meta name="DCTERMS.dateAccepted" content="'mid(v5,1,4)'-'mid(v5,5,2)'-'mid(v5,7,2)'T14:37:32Z">'/
if p(v260) then '<meta name="DCTERMS.issued" content="'v260^c'">' fi/
'<meta name="DC.identifier" content="http://localhost:9090/cgi-bin/wxis.exe/iah/scripts/?IsisScript=iah.xis&lang=es&base=MARC&nextAction=extsearch&exprSearch='v998^a'">'/
if p(v520) then '<meta name="DC.description" content="'v520^a'">' fi/
if p(v856^u) then '<meta name="DC.format" content="application/pdf">' fi/
if p(v653) then '<meta name="DC.subject" content="'v653^a+|"><meta name="DC.subject" content="|'">' fi/
if p(v245) then '<meta name="DC.title" content="'v245^a if p(v245^b) then ': 'v245^b fi '">' fi/
if p(v520) then '<meta name="DC.description" content="Cuenca">' fi/
'<meta name="citation_abstract_html_url" content="http://localhost:9090/cgi-bin/wxis.exe/iah/scripts/?IsisScript=iah.xis&lang=es&base=MARC&nextAction=extsearch&exprSearch='v998^a'">'/
if p(v100) then '<meta name="citation_authors" content="'v100^a'">' fi/
if p(v700) then '<meta name="citation_authors" content="'v700^a+|"><meta name="DC.creator" content="|'">' fi/
if p(v110) then '<meta name="citation_authors" content="'v110^a'">' fi/
if p(v710) then '<meta name="citation_authors" content="'v710^a+|"><meta name="DC.creator" content="|'">' fi/
if p(v856^u) then '<meta name="citation_pdf_url" content="'v586^u'">' fi/
if p(v653) then '<meta name="citation_keywords" content="'v653^a+|, |'">' fi/
'<meta name="citation_title" content="'v245^a'">'/
'<script language="Javascript">'/
'location.href="http://sibuc.ucuenca.edu.ec/cgi-bin/wxis.exe/iah/scripts/?IsisScript=iah.xis&lang=es&base=MARC&nextAction=extsearch&exprSearch='v998^a'"'/
'</script>'/
'</head>'/
'<body>'/
'</body>'/
'</html>'

El lector debe investigar un poco más a fondo sobre Meta Tags y como aplicarlos para exponer con más detalles mayor información de cada registro, no explicaré a fondo este particular debido a su amplitud y aplicación en el PFT.

La pequeña sección de código marcada en rojo es un Javascript que redirecciona la página a la visualización de ese registro en el catálogo del sistema ABCD, esto es debido a que lo principal es que los buscadores indexen los registros y cuando estos sean encontrados y accedidos por los usuarios, la página redireccione automáticamente al usuario al registro dentro del sistema ABCD mediante su catálogo usando expresión de búsqueda: exprSearch='v998^a'. En mi caso, tengo un identificador único para cada registro dentro del campo 998 y subcampo a indexado dentro de ABCD.

Por otro lado en este código debe cambiarse localhost:9090 por la dirección del servidor, ya que esta es parte de la dirección que será pública en Internet y localhost no funcionaría en el caso práctico.

Conversión del Registro.

$mx = $path_mx."\mx ".$db_path."marc/data/marc from=$contador to=$contador pft=@C:\ABCD\www\bases\marc\pfts\es\conversor.pft -all now 2>&1";

exec($mx, &$outmx);

$nuevoarchivo = fopen($contador.".html", "w+");

$posiciones_array = count($outmx);

$contador_posiciones = 0;

while ($contador_posiciones <= $posiciones_array-1)

{

//Guardo cada salida del array convirtiendo la codificación

$outmx[$contador_posiciones] = mb_convert_encoding($outmx[$contador_posiciones], "UTF-8", "ascii");

fputs($nuevoarchivo,$outmx[$contador_posiciones]);

$contador_posiciones ++;

}

Esta sección de código que ya fue presentada arriba e insertada en conversor.php, toma cada registro procesado por MX y convertido con el PFT para ser manipulado en la codificación de caracteres mediante $outmx[$contador_posiciones] = mb_convert_encoding($outmx[$contador_posiciones], "UTF-8", "ascii"); y para ser guardado en un archivo con extensión .html ya con la información final mediante: $nuevoarchivo = fopen($contador.".html", "w+")

Publicación

Finalmente, tendremos tantos archivos como MFNs de nuestra base, cada uno en formato html y con meta tags de los datos de nuestros registros, de manera que los buscadores puedan encontrarlos al momento de indexar nuestros sitios WEB, cabe recalcar que esta totalidad de registros debe estar almacenada en una carpeta que esté en el htdocs que es la que se publica al Internet. Al final, cuando un buscador presente una de estas páginas como resultado, el usuario será redireccionado al catálogo de ABCD que finalmente presentará el registro legible por un humano.

Las estructuras de los directorios quedaría de la siguiente manera:

• mfn.xis:

mfn.xis

• conversor.php
• mfn.txt

conversor.php - mfn.txt

• conversor.pft

conversor.pft

Como ejemplo, el código de un registro ya procesado:

Ejemplo de resultado de un registro en HTML con Meta Tags

Consideraciones y conclusiones:

• Para ejecutar el script, deberíamos escribir la siguiente URL en un navegador: http://localhost:9090/publicacionregistros/conversor.php
• La redirección funcionará siempre y cuando el registro tenga en un campo un identificador único al cual se pueda apuntar con la expresión de búsqueda, esto permitirá presentar el registro en el catálogo de ABCD.
• Este ejemplo se ha presentado para estructuras MARC, pero el PFT puede ser adaptado a los campos que se manejen en la base de datos que se desee dentro de ABCD, cada script debe ser editado apuntando a la base deseada.
• El objetivo es que los buscadores encuentren los registros detrás de una base isis en ABCD.
• Por favor estimado lector, si encuentra algo erróneo o que se deba corregir en la información puede ayudarnos a mejorarla comunicándonoslo y así ayudar a otras personas que necesiten esta información.

Fuentes de Información, Integración de búsquedas y Metabuscadores

La necesidad de obtener lo que se busca de la manera más rápida y precisa se ha convertido en uno de los principales objetivos de quienes administran la información y la ponen a disposición de sus usuarios, trabajo especial de nuestros amigos los bibliotecarios, y en ese contexto, la mayoría de las instituciones, en especial las académicas, tienen varias fuentes de información: bases bibliográficas, repositorios, bases digitales (aquellas que contienen los artículos de investigación de actualidad y relieve bajo tiempos de embargo), archivos y documentos históricos, etc. (si se hiciera un recuento, podríamos decir que en promedio, una institución académica de educación superior en latinoamérica puede tener a disposición del público alrededor de 7 buscadores en distintas fuentes de información con cientos o miles de registros en cada uno). Sin embargo las herramientas que permiten la eficiencia y rapidez de poder encontrar lo que se busca en el menor tiempo posible tiene su costo (tanto en herramientas libres como pagadas) y más si se puede encontrar lo que se busca en un solo click.

El propósito del presente artículo es brindar una óptica general de las ventajas y desventajas de las herramientas disponibles conocidas como metabuscadores, las cuales reúnen los registros de todas las fuentes de información de la institución en un solo portal de búsqueda.

Las herramientas y soluciones libres tienen desventajas al momento de ofrecer la información y esta se puede notar en dos frentes:

1. Búsqueda de información en tiempo real: este método permite encontrar material que ha sido modificado o adicionado a las fuentes de información de manera inmediata mediante la búsqueda.
2. Integración de fuentes de información heterogeneas para la búsqueda: esto implica recolectar los registros o información de cualquier tipo de fuente: bibliográfica, repositorios, bases digitales, etc. en una sola base de datos para ponerla a disposición mediante búsqueda.

Por otro lado las soluciones comerciales en metabuscadores han aprovechado muy bien el hecho de que las herramientas libres promueven el acceso abierto a la información de manera que pueden recolectar los registros de sistemas mediante sus protocolos abiertos para integrarlos a sus soluciones de metabúsqueda, pero lo que realmente le da el valor agregado (por el cual son soluciones comerciales) es ofrecer la información de las bases digitales, con sus artículos de investigación, integrados en una sola solución de búsqueda; solución por la cual las instituciones pagan sumas de dinero bastante altas (en latinoamérica un paquete de 5 bases digitales pueden sobrepasar los cien mil dólares, a esto se le debe sumar el metabuscador comercial). Realmente el costo puede llegar a ser la única desventaja que presenten estas soluciones y que por cierto son de suscripción anual.

Profundizando en el análisis, nos vamos a concentrar en 3 tipos de fuentes de información que pueden tener las instituciones:

• Base de datos bibliográfica: Aleph, ABCD, PMB, Koha, etc.
• Repositorio digital: Dspace, Evergreen, E-prints, etc.
• Bases digitales o también conocidas como bibliotecas virtuales: EBSCO, Springer, Taylor and Francis, IEEE, etc.

De estos 3 tipos, la gran mayoría de bases de datos bibliográficas y repositorios digitales han visto la necesidad de implementar protocolos que permitan compartir los registros, tal como lo hace el protocolo OAI (Open Archives Initiative) para promover el acceso abierto. Algunas de las soluciones comerciales para bases bibliográficas tienen el acceso al protocolo bajo clave lo cual impide que un metabuscador extraiga la información. Existen otros protocolos como z39 que también promueven el intercambio de registros entre bases. Por otro lado, los protocolos de acceso a bases digitales pagadas son restringidos y accesados solo por los sistemas a los que ellos permitan bajo comprobación de usuario, clave e incluso de IPs de acceso, con esto último quiero decir que la base digital reconoce la IP que intenta extraer la información y la compara con sus registros de IPs permitidas lo cual se conoce como acceso por IP. Hasta hace poco, una solución libre (de la cual no expongo el nombre ya que cortó su mantenimiento y continuidad) promovía el compartir los listados completos de los registros de las bases digitales a las cuales las instituciones se encontraban suscritas mediante un formato estructurado que exponía el título, el autor, la URL de acceso, entre otros. Esto permitía tener un sin número de archivos en un estándar que su sistema podía leer, estos archivos provenían de varias instituciones colaboradoras con contratos a bases digitales, ya podemos imaginarnos la enorme ayuda que esto suponía: poder tener cada uno de los registros, artículos, publicaciones, investigaciones, etc. de estas bases digitales pagadas en un solo sistema que los ofreciera en un solo buscador; por supuesto, el hecho de tener esta información disponible no garantizaba el acceso directo a texto completo de los artículos o publicaciones ya que, como mencioné anteriormente, estas empresas realizan comprobaciones previas de quienes acceden a su información y verifican si han pagado la debida suscripción o comprado la publicación. Aún así, para un investigador o un docente, supone una gran ayuda tener toda esta información integrada ya que no tendrá que hacer múltiples búsquedas en cada base digital, si no, mediante una sola obtener toda la información que necesita y comprar el artículo o publicación que le interese. En esa misma línea podemos imaginarnos el enorme ahorro que esto implicaría a las instituciones a no tener que comprar paquetes completos de información a las bases digitales.

Hoy, la integración de estas fuentes sigue siendo difícil de encontrar con soluciones libres, pero aún así son posibles, y de manera no tan técnica se puede notar el proceso que se puede seguir para obtener todos los registros (en la suma de la posibilidad de las herramientas existentes en su institución) en un solo metabuscador. Usando los 3 tipos de fuentes de información expuestas como ejemplo se puede ver rápidamente un esquema de integración genérico:

• Un buen metabuscador puede ser VuFind: http://vufind-org.github.io/vufind/ Esta herramienta permite importar los registros en formatos estandarizados usando el protocolo OAI. Si su institución consta con un sistema de administración para la biblioteca y un repositorio, ambos con protocolo OAI, entonces VuFind puede cosechar estos registros. Este término: cosechar, ha tomado auge y hace referencia a que un software puede recolectar registros mediante un protocolo en diferentes fuentes (registros que ciertas veces deben cumplir un estándar de meta-datos, tema que ampliaré en otra entrada de este blog) para ponerlas a disposición en metabúsqueda.

• Una vez que los registros de la base bibliográfica y el repositorio se encuentran cosechados, hacen falta las bases digitales comerciales. La gran mayoría de estas bases ofrecen a sus suscriptores los listados de artículos y publicaciones en un archivo formateado, este puede ser una hoja de cálculo o archivo separado por comas. Con esta información dispuesta en esta modalidad podemos realizar un proceso de re-estructuración de esta información en formato XML que VuFind pueda importar a su base de datos. Es un proceso técnico que puede consultar en la página oficial del sistema.

• Ampliando nuestro ejemplo, existen instituciones que administran sus fondos históricos y documentales con sistemas como ICA-AtoM (https://www.ica-atom.org/) y por otro lado sus publicaciones seriadas e investigaciones con OJS (https://pkp.sfu.ca/ojs/); estas herramientas también hacen posible la cosecha de sus registros con OAI.

Así se puede notar un esquema bastante general de integración mediante OAI e importación de registros en estructuras XML mediante sistemas que entiendan estas vías de compartir información, VuFind es solo un ejemplo, cualquier institución o persona puede desarrollar un sistema que siga el mismo proceso para integrar la información.

Como conclusión puedo señalar que las herramientas comerciales solucionan el proceso repetitivo y manual de importar registros en un cosechador para ofrecerlos en metabúsqueda, sin embargo su costo puede llegar a ser alto, comúnmente en función de la cantidad de usuarios, además de que su suscripción generalmente es anual, sin embargo los usuarios de esta herramienta podrán encontrar la información actualizada y en tiempo real. Por otro lado las herramientas libres podrían tomar un tiempo considerable en acoplar las diversas fuentes de información y ponerlas a disposición del usuario, más que nada por ser un proceso repetitivo pero que es susceptible de ser automatizado; hay que tomar en cuenta que las búsquedas bajo cosecha no se realizan en tiempo real. Aún así, y una vez lograda la automatización de las cosechas de las diferentes fuentes de información con un desarrollo propio o con herramientas libres, se obtiene un software automatizado para la cosecha evitando el pago por suscripción anual de una herramienta comercial.

Cada institución debe analizar que herramienta le conviene para cosechar sus datos y ponerlos a disposición de una manera más eficiente, este artículo ha presentado pocas herramientas de una variedad mucho más grande en el mercado.

Soluciones Informáticas para la Administración en Información

En la actualidad, las bibliotecas y centros de documentación necesitan soluciones ágiles que permitan administrar sus fondos bibliográficos con el fin de ponerlos a disposición de sus usuarios en los diferentes medios tecnológicos que usan.

Estas soluciones informáticas (o sistemas de administración de información) se ofrecen en el mercado bajo licencias comerciales y libres, sin embargo, no se puede negar que el licenciamiento abierto de estos sistemas ha tomado mucho auge en los últimos tiempos, esto ha fortalecido en gran manera el intercambio de la información mediante protocolos y políticas institucionales.

Este blog pretende ayudar a la comunidad bibliotecaria e informática con la experiencia que se adquiere a través de la instalación, administración y manejo de los diferentes tipos de sistemas para las bibliotecas y centros de documentación.

Espero que el usuario pueda beneficiarse en todas las maneras posibles de los diferentes artículos presentados...