Las colecciones pueden personalizarse para que la información que contienen sea accesible de distintas maneras. En este capítulo se explica la manera en que Greenstone extrae la información de los documentos y la presenta al usuario: el tratamiento de los documentos (Sección plugins), las estructuras de clasificación (Sección classifiers) y las herramientas de la interfaz de usuario (Secciones formatting_greenstone_output y controlling_the_greenstone_user_interface).

Los conectores analizan los documentos importados y extraen los metadatos. El conector HTML, por ejemplo, convierte las páginas HTML en el Formato de Archivo Greenstone y extrae los metadatos que están explícitos en el formato del documento, como los títulos entre etiquetas <title> </title>.

Los conectores se escriben en lenguaje Perl. Todos proceden de un conector básico denominado BasPlug, que realiza todas las operaciones necesarias como crear un nuevo documento en el Formato de Archivo Greenstone con que trabajar, asignar un identificador de objeto (OID) y manejar las secciones de un documento. Los conectores se guardan en el directorio perllib/plugins.

Para saber más sobre un conector cualquiera, escriba pluginfo.pl nombre-de-conector en la línea de comandos. (Es preciso que active primero el guión de configuración – setup –adecuado, si aún no lo ha hecho, y en Windows ha de teclear perl  –S pluginfo.pl nombre de conector si su sistema no está configurado para reconocer los archivos que terminan en .pl como ejecutables de Perl). Aparece entonces en la pantalla la información sobre el conector: qué opciones específicas admite y qué opciones generales se autorizan.

Puede usted escribir fácilmente nuevos conectores para tratar formatos de documentos que los conectores existentes no manejan, formatear documentos de determinada manera o extraer un nuevo tipo de metadatos.

En el Cuadro <tblref table_options_applicable_to_all_plugins> se muestran las opciones que admite cualquier conector derivado de BasPlug.

<tblcaption table_options_applicable_to_all_plugins|Opciones válidas para todos los conectores></tblcaption>

<tblcaption table_table_conectores_de_greenstone|Conectores de Greenstone></tblcaption>

Los programas de creación de colección utilizan conectores de tratamiento de documentos para analizar los documentos de origen en función de su formato. En el archivo de configuración de colección se enumeran todos los conectores utilizados durante el proceso de creación. Durante la operación de importación, cada archivo o directorio pasa uno a uno por todos los conectores, siguiendo el orden establecido, hasta que encuentra uno que puede tratarlo; así pues, los primeros conectores de la lista tienen prioridad sobre los últimos. Si ningún conector puede tratar el archivo, aparece un aviso (en error estándar) y el tratamiento pasa al archivo siguiente. (En este caso la opción block_exp puede resultar útil a fin de evitar estos mensajes de error para los archivos que pueden estar presentes pero no necesitan tratamiento.) Durante la etapa de creación de la colección se aplica el mismo procedimiento, pero se trata el directorio archives en lugar del directorio import.

Los conectores estándar de Greenstone se enumeran en el Cuadro <tblref table_greenstone_plugins>. Es preciso utilizar un procedimiento recursivo para recorrer transversalmente jerarquías de directorios. Aunque los programas de importación y creación no efectúan una recursión explícita, algunos conectores provocan una recursión indirecta al introducir nombres de archivos o de directorios en la secuencia de los conectores. Por ejemplo, el modo estándar de recursión a través de una jerarquía de directorio consiste en especificar RecPlug, que realiza exactamente esta operación. Si está presente, debería ser el último elemento en la secuencia. Sólo los dos primeros conectores del Cuadro <tblref table_greenstone_plugins> provocan una recursión indirecta.

Algunos conectores están escritos para colecciones específicas que tienen un formato de documento que no se encuentra en ninguna otra parte, como el texto electrónico utilizado en la colección Gutenberg. Estos conectores específicos de una colección se encuentran en el directorio perllib/plugins de la colección. Los conectores específicos de colección pueden utilizarse para invalidar los conectores generales que llevan el mismo nombre.

Algunos conectores de tratamiento de documentos utilizan programas externos que analizan determinados formatos patentados, como por ejemplo Word de Microsoft, y los transforman en texto normal o en HTML. Un conector general denominado ConvertToPlug activa el programa de conversión correspondiente y pasa el resultado a TEXTPlug o a HTMLPlug. Más adelante se explicará más detalladamente esta operación.

Algunos conectores disponen de opciones específicas que permiten controlar sus operaciones de manera más precisa que las opciones generales. Véase al respecto el Cuadro <tblref table_plugin-specific_options>.

<tblcaption table_plugin-specific_options|Opciones específicas de los conectores></tblcaption>

Los formatos patentados plantean serias dificultades para cualquier sistema de biblioteca digital. Aunque se disponga de documentación sobre su funcionamiento, pueden ser modificados sin aviso y resulta difícil mantenerse al tanto de los cambios. Greenstone ha optado por utilizar las aplicaciones de conversión publicadas según los términos de la GPL (Licencia Pública General de GNU) y elaboradas por personas dedicadas a esta tarea. Los instrumentos para convertir formatos Word y PDF se encuentran en el directorio packages. Estos convierten los documentos en texto normal o en HTML. Se utilizan posteriormente HTMLPlug y TEXTPlug para convertirlos en el Formato de Archivo Greenstone. ConvertToPlug sirve para incluir los instrumentos de conversión y, al igual que BasPlug, nunca se activa directamente, sino que los conectores de tratamiento de formatos específicos derivan o heredan de él, como se ilustra en la Figura <imgref figure_plugin_inheritance_hierarchy>. ConvertToPlug emplea el sistema de herencia dinámico de Perl para heredar de TEXTPlug o de HTMLPlug, según el formato en el que se ha convertido el documento de origen.

<imgcaption figure_plugin_inheritance_hierarchy|%!– id:537 –%Jerarquía de herencia de los conectores ></imgcaption>

Cuando ConvertToPlug recibe un documento, acude a gsConvert.pl (que se encuentra en GSDLHOME/bin/script) para activar el instrumento de conversión adecuado. Una vez convertido, el documento es devuelto a ConvertToPlug, que aplica el conector texto o HTML, según convenga. Todo conector derivado de ConvertToPlug dispone de una opción convert_to (convertir en), cuyo argumento es text o html, para especificar el formato intermedio que se prefiere. El formato texto es más rápido, pero HTML suele tener una mejor presentación e incluye imágenes.

Existen a veces varios instrumentos de conversión para un formato particular y gsConvert puede probar varios de ellos en un documento. Por ejemplo, el instrumento de conversión más común de Word, wvWare, sólo funciona con Word 6, y para convertir los documentos Word 5 se utiliza un programa denominado AnyToHTML, cuya principal función es extraer todas las cadenas de texto que puede encontrar.

Las etapas necesarias para agregar un nuevo programa de conversión de documentos externos son las siguientes:

1. Instale el nuevo programa de conversión para que sea accesible por Greenstone (colóquelo en el directorio packages).
2. Modifique gsConvert.pl para utilizar el nuevo programa de conversión. Esto implica añadir una nueva cláusula a la instrucción if de la función main, y agregar una función que active el programa de conversión.
3. Escriba un conector de nivel superior que herede de ConvertToPlug para interceptar el formato y luego dejarlo “pasar adelante”.

El conector estándar RecPlug incorpora asimismo la posibilidad de asignar metadatos a los documentos a partir de archivos XML creados manual o automáticamente. Vamos a explicar detalladamente el proceso para que pueda usted crear archivos de metadatos en el formato adecuado. Si se especifica la opción use_metadata_files, RecPlug utiliza un archivo de metadatos auxiliar llamado metadata.xml. En la Figura <imgref figure_xml_format> se muestra la Definición de Tipo de Documento (DTD) XML para el formato de archivo de metadatos, mientras que la figura <imgref figure_xml_format_1> muestra un ejemplo de archivo metadata.xml.

<imgcaption figure_xml_format|%!– id:547 –%(a) %!– id:546 –%Formato XML: (a) Definición de Tipo de Documento (DTD); (b) Ejemplo de archivo de metadatos ></imgcaption>

<!DOCTYPE GreenstoneDirectoryMetadata   [
<!ELEMENT DirectoryMetadata (FileSet*)>
<!ELEMENT FileSet (FileName+,Description)>
<!ELEMENT FileName (#PCDATA)>
<!ELEMENT Description (Metadata*)>
<!ELEMENT Metadata (#PCDATA)>
<ATTLIST Metadata name CDATA #REQUIRED>
<ATTLIST Metadata mode (accumulate | override) “override”>
]>

<imgcaption figure_xml_format_1|%!– id:549 –%(b) %!– id:548 –% ></imgcaption>

<?xml version="1.0" ?>
<!DOCTYPE GreenstoneDirectoryMetadata SYSTEM
"http://greenstone.org/dtd/GreenstoneDirectoryMetadata/1.0/GreenstoneDirectoryMetadata.dtd”>
<DirectoryMetadata>
         <FileSet>
                   <FileName>nugget.*</FileName>
                   <Description>
                   <Metadata name=“Title”>Nugget Point Lighthouse</Metadata>
                   <Metadata name=“Place” mode=“accumulate”>Nugget Point</Metadata>
         </Description>
         </FileSet>
         <FileSet>
                   <FileName>nugget-point-1.jpg</FileName>
                   <Description>
                          <Metadata name=“Title”>Nugget Point Lighthouse, The Catlins</Metadata>
                          <Metadata name=“Subject”>Lighthouse</Metadata>
                   </Description>
         <FileSet>
</DirectoryMetadata>

El archivo de ejemplo contiene dos estructuras de metadatos. En cada una de ellas, el elemento filename describe los archivos a los que se aplican los metadatos en forma de expresión regular. Así pues, <FileName>nugget.*</FileName> <i/> indica que el primer registro de metadatos se aplica a todos los archivos cuyo nombre empieza por “ nugget ”¹⁾. Para estos archivos, el metadato Title se aplica a “Nugget Point Lighthouse”.

Los elementos de metadatos se tratan en el orden en que aparecen. La segunda estructura establece que el metadato Title para el archivo nugget-point-1.jpg se aplica a “Nugget Point Lighthouse, The Catlins” e invalida la especificación anterior. Añade asimismo un campo de metadatos Subject.

Algunas veces los metadatos poseen varios valores y los nuevos valores deben acumularse en vez de invalidar los anteriores. El atributo mode=accumulate activa esta opción. Se aplica al metadato Place en la primera especificación que, por consiguiente, podrá adoptar múltiples valores. Para volver a un metadato simple, teclee <Metadata name=“Place” mode=“override”>New Zealand</Metadata> . De hecho, se podría omitir esta especificación de modo porque todo elemento invalida el anterior, salvo si se indica lo contrario. Para acumular metadatos en un campo particular, se debe especificar mode=accumulate en cada aparición.

Cuando se activa la opción use_metadata_files, RecPlug comprueba en cada directorio de entrada la presencia de un archivo XML denominado metadata.xml y aplica su contenido a todos los archivos y subdirectorios del directorio.

El mecanismo metadata.xml incorporado a RecPlug es sólo un modo de especificar los metadatos para los documentos. Es fácil escribir diferentes conectores que aceptan especificaciones de metadatos con formatos completamente diferentes.

Los documentos de origen necesitan a menudo estructurarse en secciones y subsecciones, y es preciso comunicar esta información a Greenstone a fin de que pueda mantener la estructura jerárquica. Asimismo, se pueden asociar metadatos –en particular el título– con cada sección y subsección.

La manera más sencilla de efectuar esta operación suele ser modificando los archivos de origen. El conector HTML dispone de una opción description_tags que trata las etiquetas en el texto como sigue:

<!--
<Section>
<Description>
         <Metadata name=“Title”> Realizing human rights for poor people: Strategies for achieving the international development targets </Metadata>
</Description>
-->

(el texto de la sección va aquí)

<!--
</Section>
-->

Se utilizan los marcadores %!– … –% porque indican comentarios en formato HTML; en consecuencia, estas etiquetas de sección no afectarán al formateo del documento. En la parte Description se pueden especificar otros tipos de metadatos, pero esto no ocurre para el estilo de colección que mencionamos aquí. Asimismo, las etiquetas pueden subdividirse, de tal modo que la línea anterior señalada por marcadores el texto de la sección va aquí pueda incluir a su vez otras subsecciones, como por ejemplo:

(el texto de la primera parte de la sección va aquí)

<!--
<Section>
<Description>
         <Metadata name=“Title”> The international development targets </Metadata>
<Description>
-->

(el texto de la subsección va aquí)

<!--
</Section>
-->

(el texto de la última parte de la sección va aquí)

Cualquier conector que utilice HTMLPlug hereda esta función. El conector Word, en particular, convierte en formato HTML los datos que recibe y por ello se pueden especificar los metadatos exactamente de la misma manera en los archivos Word (y RTF). (Esto supone un poco de trabajo “entre bastidores”, porque cuando los documentos Word se convierten en HTML, el programa por lo general procura neutralizar la interpretación especial que suele hacer HTML de los signos sueltos “<” y “>”; nos las hemos arreglado para invalidar esto en el caso de las especificaciones antes mencionadas.) Obsérvese que se utiliza exactamente el mismo formato que antes, incluso en los archivos Word, así como los signos de comentarios “%!–” y “–%”. El tipo de letra y el espaciado no se tienen en cuenta.

Los clasificadores sirven para crear los índices de consulta de la colección. Valgan como ejemplos el índice títulos A-Z de la colección dlpeople, así como los índices tema, cómo…, organizaciones y títulos A-Z de la Biblioteca sobre Aspectos Humanitarios y de Desarrollo, de la que la colección de demostración es un subconjunto. La barra de desplazamiento que aparece en la parte superior de la pantalla en las Figuras 3 y 8a incluye la función búsqueda, que siempre está disponible, seguida de botones correspondientes a todos los clasificadores que se han definido. La información utilizada para facilitar la consulta se encuentra en la base de datos de informaciones de la colección, donde es colocada por los clasificadores activados durante la fase final del programa buildcol.pl.

<imgcaption figure_azlist_classifier|%!– id:566 –%Clasificador AZList ></imgcaption>

Los clasificadores, al igual que los conectores, se especifican en el archivo de configuración de la colección. Todos tienen una línea que empieza por la palabra clave classify seguida del nombre del clasificador y las opciones que admite. El archivo básico de configuración de la colección mencionado en la Sección import_and_build_processes comprende la línea classify AZList –metadata Title, que crea una lista alfabética de títulos reuniendo todos aquéllos que están provistos del campo de metadatos Title, y los clasifica y divide por orden alfabético. En la Figura <imgref figure_azlist_classifier> se muestra un ejemplo.

<imgcaption figure_list_classifier|%!– id:568 –%Clasificador List ></imgcaption>

Un clasificador más simple, llamado List, que se muestra en la Figura <imgref figure_list_classifier>, crea una lista clasificada de un elemento de metadato determinado y lo presenta sin ninguna subsección alfabética²⁾. Un ejemplo es el metadato cómo de la colección de demostración, que es generado por la línea classify List –metadata Howto en el archivo de configuración de la colección. Otro clasificador general es DateList, ilustrado en la Figura <imgref figure_datelist_classifier>, que genera una lista de selección de intervalos de fechas. (El clasificador DateList se utiliza también en la colección “Archivos de Greenstone”.)

<imgcaption figure_datelist_classifier|%!– id:570 –%Clasificador DateList ></imgcaption>

Otros clasificadores generan estructuras de consulta que son explícitamente jerárquicas. Las clasificaciones jerárquicas son útiles para las clasificaciones y subclasificaciones temáticas, así como para las jerarquías relativas a organizaciones. El archivo de configuración de la colección de demostración incluye la línea classify Hierarchy –hfile sub.txt –metadata Subject –sort Title, y en la Figura <imgref figure_hierarchy_classifier> se muestra la jerarquía de temas que esta línea produce. El estante que lleva un título en negrita es el que se está examinando en este momento; encima de él se puede ver la clasificación temática a la que pertenece. En este ejemplo la jerarquía de clasificación se guarda en un formato de texto sencillo que lleva el nombre de sub.txt.

<imgcaption figure_hierarchy_classifier|%!– id:572 –%Clasificador Hierarchy ></imgcaption>

Todos los clasificadores generan una estructura jerárquica que se utiliza para mostrar un índice de consulta. Normalmente, los niveles inferiores de la jerarquía (esto es, las hojas) son los documentos, pero en algunos clasificadores son las secciones. Los nodos internos de la jerarquía son Vlist, Hlist o Datelist. Una Vlist es una lista de elementos dispuestos verticalmente en la página, como el índice “ cómo… ” de la colección de demostración (véase la Figura <imgref figure_list_classifier>). Una Hlist tiene una presentación horizontal. Por ejemplo, la AZList de la Figura <imgref figure_azlist_classifier> es una jerarquía de nodos internos de dos niveles compuesta por una Hlist (que da el selector A-Z) cuyos elementos secundarios son nodos Vlists ; los documentos son a su vez elementos secundarios de esta última lista. Un nodo Datelist (Figura <imgref figure_datelist_classifier>) es un tipo especial del nodo Vlist que permite efectuar selecciones por año y por mes.

Las líneas que se utilizan para especificar los clasificadores en los archivos de configuración de colección contienen un argumento metadata que identifica los metadatos mediante los cuales se clasifican y seleccionan los documentos. El clasificador omitirá todo documento de la colección para el que no se haya definido este metadato (pero se lo indizará y, por consiguiente, la función búsqueda lo tendrá en cuenta). Si no se especifica un argumento metadata, todos los documentos se incluyen en el clasificador, en el orden en que aparecieron durante el proceso de creación. Esto es útil si desea obtener una lista de todos los documentos de su colección.

<tblcaption table_greenstone_classifiers|Clasificadores de Greenstone></tblcaption>

La lista de los clasificadores actualmente disponibles aparece en el Cuadro <tblref table_greenstone_classifiers>. Al igual que se puede utilizar el programa pluginfo.pl para obtener información sobre cualquier conector, el programa classinfo.pl le facilita información sobre cualquier clasificador y las opciones que ofrece.

Todos los clasificadores aceptan el argumento buttonname, que define el contenido del botón de consulta de Greenstone que activa el clasificador (el valor por defecto es el nombre del argumento metadata). Existen botones para cada tipo de metadato del sistema Dublin Core y para algunos otros tipos de metadatos.

Cada clasificador recibe un nombre implícito con arreglo a su posición en el archivo de configuración. Por ejemplo, el tercer clasificador especificado en el archivo se denomina CL3. Esos nombres se emplean para nombrar los campos de la base de datos de informaciones de la colección que definen la jerarquía de los clasificadores.

Se pueden escribir clasificadores específicos para una colección, que se almacenan en el directorio perllib/classify de la colección. La Biblioteca sobre Aspectos Humanitarios y de Desarrollo tiene un clasificador específico de colección que se llama HDLList, que es una variante menor de AZList.

A continuación figuran los diversos tipos de clasificadores de listas:

• SectionList : es como List pero las hojas son secciones y no documentos. Se incluyen todas las secciones del documento excepto las del nivel superior. Este clasificador sirve para crear listas de secciones (o de artículos, capítulos, etc.), como en la colección Computists’ Weekly (el semanario de los informáticos, disponible en el sitio Web  nzdl.org ), en la que cada número es un solo documento que comprende varios artículos independientes, cada uno en su propia sección.
• AZList : genera una jerarquía de dos niveles que comprende un nodo Hlist cuyos elementos secundarios son nodos Vlists, cuyos elementos secundarios, a su vez, son documentos. El nodo Hlist es un selector A-Z que divide los documentos en intervalos alfabéticos.
• AZSectionList : es como AZList pero las hojas son secciones y no documentos.
• DateList : es como AZList excepto que el nodo Hlist de nivel superior permite seleccionar por año y sus elementos secundarios son nodos de tipo DateList y no de tipo Vlist. El valor por defecto del argumento metadata es Date.

Todos los clasificadores son jerárquicos. Sin embargo, los clasificadores de listas antes mencionados disponen de un número fijo de niveles, mientras que los clasificadores “ hierarchy ” (jerárquicos) tratados en esta sección pueden crear una serie arbitraria de niveles y son más complejos de especificar que los clasificadores de listas.

<imgcaption figure_part_of_the_file_sub|%!– id:618 –%Parte del archivo sub.txt ></imgcaption>

1      1      "General reference"
1.2    1.2    "Dictionaries, glossaries, language courses, terminology
2      2      "Sustainable Development, International cooperation, Pro
2.1    2.1    "Development policy and theory, international cooperatio
2.2    2.2    "Development, national planning, national plans"
2.3    2.3    "Project planning and evaluation (incl. project managem
2.4    2.4    "Regional development and planning incl. regional profil
2.5    2.5    "Nongovernmental organisations (NGOs) in general, self-
2.6    2.6    "Organisations, institutions, United Nations (general, d
2.6.1  2.6.1  "United Nations"
2.6.2  2.6.2  "International organisations"
2.6.3  2.6.3  "Regional organisations"
2.6.5  2.6.5  "European Community - European Union"
2.7    2.7    "Sustainable Development, Development models and example
2.8    2.8    "Basic Human Needs"
2.9    2.9    "Hunger and Poverty Alleviation"

El argumento hfile da el nombre de un archivo, como el de la Figura <imgref figure_part_of_the_file_sub>, que define la jerarquía de metadatos. Cada línea describe una clasificación y las descripciones constan de tres partes:

• Un identificador, que hace corresponder el valor del metadato (proporcionado por el argumento metadata) con la clasificación.
• Un marcador de posición en la jerarquía, con forma numérica en varias partes, por ejemplo, 2, 2.12, 2.12.6.
• El nombre de la clasificación. (Si contiene espacios, deberá ponerse entre comillas)

La Figura <imgref figure_part_of_the_file_sub> forma parte del archivo sub.txt utilizado para crear la jerarquía temática en la Biblioteca sobre Aspectos Humanitarios y de Desarrollo (y en la colección de demostración). Este ejemplo es un poco confuso porque el número que representa la jerarquía aparece dos veces en cada línea. El tipo de metadato Hierarchy se representa en los documentos con valores que adoptan una forma numérica jerárquica, lo que corresponde a su primera aparición. La segunda aparición se utiliza para determinar la jerarquía que se aplica en el navegador.

El clasificador hierarchy tiene un argumento opcional, sort, que determina el modo en que se ordenan los documentos en las hojas. Se puede especificar cualquier metadato como criterio de ordenación. La lista se crea por defecto siguiendo el orden en que se encuentran los documentos durante el proceso de creación. El orden de los nodos internos viene determinado por el orden en que se especifican los elementos en el argumento hfile.

Los clasificadores son objetos Perl, derivados de BasClas.pm, y se almacenan en el directorio perllib/classify. Se utilizan durante la creación de la colección. Su ejecución se hace en cuatro etapas:

1. El método new crea el objeto Clasificador.
2. El método init inicializa el objeto con parámetros como el tipo de metadato, el nombre del botón y el criterio de clasificación.
3. El método classify interviene una vez para cada documento, y guarda la información sobre la clasificación efectuada dentro del objeto de clasificador.
4. El método get_classify_info transmite la información de la clasificación localmente almacenada hacia el proceso de creación, que entonces la incluye en la base de datos de informaciones de la colección para su uso cuando la colección se visualiza en el momento de la ejecución.

El método classify recupera el OID de cada documento, el valor de metadato con el que se va a clasificar el documento y, si es necesario, el valor de metadato con el que se van a ordenar los documentos. El método get_classify_info efectúa todas las funciones de ordenación y clasificación específicas del clasificador. Por ejemplo, en el caso del clasificador AZList divide la lista en intervalos alfabéticos.

El proceso de creación de la colección activa los clasificadores en cuanto se crea el objeto builder. Las clasificaciones se realizan durante la fase de creación, cuando se crea la base de datos de informaciones mediante classify.pm, que se encuentra en el directorio perllib de Greenstone.

<tblcaption table_items_appearing_in_format_strings|Elementos que aparecen en las cadenas de formato></tblcaption>

Las páginas Web que usted ve cuando utiliza Greenstone no han sido almacenadas previamente sino que son generadas “al instante” a medida que se las necesita. La apariencia de numerosos aspectos de las páginas se controla a través de las “cadenas de formato”. Las cadenas de formato se encuentran en el archivo de configuración de la colección y se introducen con la palabra clave format seguida del nombre del elemento al que se aplica el formato. Las cadenas de formato controlan dos tipos diferentes de elementos de página. El primero comprende los elementos de la página que muestran documentos o partes de documentos. El segundo incluye las listas generadas por los clasificadores y las búsquedas. Todas las cadenas de formato se interpretan en el momento en que se visualizan las páginas. Es rápido y sencillo experimentar con las cadenas de formato ya que surten efecto en cuanto se guarda cualquier modificación en el archivo collect.cfg.

En el Cuadro <tblref table_items_appearing_in_format_strings> se muestran las instrucciones de formato que afectan la apariencia de los documentos. La opción DocumentButtons controla los botones que aparecen en una página de documento. En este caso, cadena es una lista de botones (separados por |) y sus valores posibles son Detach (separar), Highlight (resaltar), Expand Text (texto completo) y Expand contents (expandir índice). La modificación del orden de la lista modifica en consecuencia el orden de los botones.

<tblcaption table_the_format_options|Las opciones de la palabra clave format></tblcaption>

Las cadenas de formato que controlan la apariencia de las listas pueden aplicarse a distintos niveles de la estructura de presentación. Pueden modificar todas las listas de determinado tipo dentro de una colección (por ejemplo, DateList) o todas las partes de una lista (por ejemplo, todas las entradas de la lista Search (búsqueda)) o determinadas partes de una lista particular (por ejemplo, la porción vertical de la lista de un clasificador AZList aplicado a títulos).

Después de la palabra clave format hay otra palabra clave en dos partes, de las que sólo una es obligatoria. La primera parte identifica la lista a la que se aplica el formato. La lista que se obtiene mediante una búsqueda se llama Search (búsqueda), mientras que las listas generadas por clasificadores se denominan CL1, CL2, CL3, etc., para el primer, segundo, tercer, etc., clasificador especificado en el archivo collect.cfg. La segunda parte de la palabra clave se refiere a la porción de la lista a la que se aplica el formateo, esto es, Hlist (para una lista horizontal, como el selector A-Z en un nodo AZList), Vlist (para una lista vertical, como la lista de títulos en un nodo AZList) o DateList. Por ejemplo:

format CL4Vlist … se aplica a todos los VLists de CL4

format CL2Hlist … se aplica a todos los HListsde CL2

format CL1DateList … se aplica a todos los DateListsde CL1

format SearchVList … se aplica a la lista de resultados de búsqueda

format CL3 … se aplica a todos los nodos de CL3, a menos que se especifique lo contrario

format Vlist … se aplica a todos los Vlistsde todos los clasificadores, a menos que se especifique lo contrario

En los ejemplos de la figura 16, las comillas (“…”) representan las especificaciones de formato HTML que controlan la información y su presentación, tal como aparecen en las páginas Web que muestran el clasificador. Al igual que las especificaciones HTML, cualquier metadato puede aparecer entre corchetes: su valor se interpola en el lugar indicado. Asimismo, cualquiera de los elementos del Cuadro <tblref table_the_format_options> puede aparecer en las cadenas de formato. La sintaxis de las cadenas incluye también una instrucción condicional que se ilustra en un ejemplo más adelante.

Recuerde que todos los clasificadores producen jerarquías. Cada nivel de la jerarquía se visualiza en una de cuatro formas posibles. Ya hemos visto Hlist, Vlist y DateList. Existe además Invisible, que es el modo en que se visualizan los niveles superiores de las jerarquías: en efecto, el nombre del clasificador aparece ya separadamente en la barra de desplazamiento de Greenstone.

<imgcaption figure_excerpt_from_the_demo_collection_collect|%!– id:674 –%Extracto del archivo collect.cfg de la colección de demostración %!– withLineNumber –%></imgcaption>

classify Hierarchy       –hfile sub.txt –metadata Subject –sort Title
classify AZList -metadata Title
classify Hierarchy       -hfile org.txt –metadata Organisation –sort Title
classify List            -metadata Howto
format SearchVList       “<td valign=top>     [link][icon][/link]</td><td>{If}
                            {[parent (All’: ’):Title], [parent (All’:’):Title]:}
                         [link][Title][/link]</td>”
format CL4Vlist “<br>[link][Howto][/link]”
format DocumentImages       true
format DocumentText         “<h3> [Title] </h3>\\n\\n<p>[Text]”
format DocumentButtons      “Expand Text|Expand contents|Detach|Highlight”

En la Figura <imgref figure_excerpt_from_the_demo_collection_collect> se muestra una parte del archivo de configuración de la colección de demostración. La utilizamos como ejemplo porque comprende varios clasificadores con un formato muy elaborado. Obsérvese que las instrucciones de los archivos de configuración no deben contener caracteres de nueva línea; en el Cuadro, hemos cortado las líneas más largas para facilitar su legibilidad.

La línea 4 especifica el clasificador How To (cómo…) de la colección de demostración. Es la cuarta en el archivo de configuración de la colección y, por consiguiente, se denomina CL4. La instrucción de formato correspondiente es la línea 7 de la Figura <imgref figure_excerpt_from_the_demo_collection_collect>. La información “cómo” se genera a partir del clasificador List y su estructura es la lista completa de títulos que aparecen en la Figura <imgref figure_list_classifier>. Los títulos tienen un enlace con los propios documentos: cuando se hace clic en un título se abre el documento correspondiente. Los elementos secundarios del primer nivel de la jerarquía se visualizan como Vlist (lista vertical), es decir, las secciones se muestran verticalmente. Como indica la instrucción format asociada, cada elemento de la lista está en una nueva línea (“<br>”) y contiene el texto del metadato Howto, vinculado por hipervínculo al documento en cuestión.

La línea 1 especifica la clasificación Subject (tema) de la colección de demostración, denominada CL1 (la primera en el archivo de configuración); la línea 3 especifica la clasificación Organisation y se denomina CL3. Ambas son generadas por el clasificador Hierarchy y, por consiguiente, comprenden una estructura jerárquica de objetos VList.

La línea 2 especifica el resto de la clasificación de la colección de demostración, Títulos A-Z (CL2). Obsérvese que no existen cadenas de formato asociadas a los clasificadores CL1 a CL3. Greenstone dispone de valores por defecto para cada tipo de cadena de formato y por lo tanto no es necesario configurar una cadena de formato a menos que se desee invalidar el valor por defecto.

<imgcaption figure_formatting_the_document|%!– id:679 –%Formateo del documento ></imgcaption>

Estas explicaciones corresponden a las cuatro líneas classify de la Figura <imgref figure_excerpt_from_the_demo_collection_collect>. Hay también cuatro líneas format. Ya hemos explicado la línea CL4Vlist. Las otras tres pertenecen al primer tipo de cadena de formato, ilustrado en el Cuadro <tblref table_items_appearing_in_format_strings>. La línea 8, por ejemplo, coloca la imagen de portada en la parte superior izquierda de cada página del documento. La línea 9 formatea el texto del documento propiamente dicho, y coloca el título del capítulo o sección correspondiente justo ante del texto. Todos estos efectos se ilustran en la Figura <imgref figure_formatting_the_document>.

<imgcaption figure_formatting_the_search_results|%!– id:681 –%Formateo de los resultados de la búsqueda ></imgcaption>

La línea 5 de la Figura <imgref figure_excerpt_from_the_demo_collection_collect> es una especificación algo complicada que formatea la lista de resultados generada por una búsqueda, cuyas porciones se muestran en la Figura <imgref figure_formatting_the_search_results>. Presentamos a continuación, una versión simplificada de la cadena de formato:

<td valign=top>[link][icon][/link]</td>
<td>[link][Title][/link]</td>

Está diseñada para aparecer como una línea en un cuadro, que es como se formatea la lista de resultados de una consulta. Va acompañada, como de costumbre, por un pequeño icono vinculado al texto, y por el título del documento que establece un hipervínculo con el documento en cuestión.

En esta colección, los documentos son jerárquicos. De hecho, el hipervínculo anterior remite al título de la sección obtenido por la consulta. Sin embargo, sería preferible que incluyese también el título de la sección que la contiene, del capítulo que contiene esta última y del libro en el que se encuentra. Existe un elemento de metadato especial, parent, que no se guarda en los documentos pero que está implícito en cualquier documento jerárquico y que genera este tipo de lista. Éste remite al documento principal, o si se utiliza con el calificador All, remite a la lista de documentos principales emparentados jerárquicamente, separada por una cadena de caracteres que se pueden precisar tras el calificador All. Así pues,

<td valign=top>[link][icon][/link]</td>
<td>{[parent(All´: ´):Title]: }[link][Title][/link]</td>

produce una lista que contiene el título del libro, el título del capítulo, etc. que encierra la sección buscada, separados por dos puntos, y más adelante por otro carácter de dos puntos seguido de un hipervínculo con el título de la sección buscada.

Lamentablemente, si el objetivo buscado es un libro, no hay documento emparentado y, por lo tanto, aparecerá una cadena vacía seguida de dos puntos. Para evitar tales problemas puede usted utilizar en una cadena de formato las instrucciones condicionales if y or … else :

{If} {[metadato],acción-si-no-vacio, acción-si-vacio}
{Or} {acción,else otra-acción, else otra-acción, etc}

En cualquiera de los casos, se utilizan las llaves para señalar que las instrucciones deben interpretarse y no sólo considerarse como texto. La instrucción if comprueba si el metadato está vacío y elige la primera opción si no es así; de lo contrario pasa a la segunda (si es que existe). Se puede utilizar cualquier elemento de metadato, incluso el metadato especial parent. La instrucción Or evalúa todas las acciones por turno hasta que encuentra una que no esté vacía. La envía entonces a la lista de resultados e ignora el resto de la línea.

Volviendo a la línea 5 de la Figura <imgref figure_excerpt_from_the_demo_collection_collect>, la cadena de formato completa es:

<td valign=top>[link][icon][/link]</td>
<td>{If}{[parent (All´: ´):Title],
         [parent (All´: ´):Title]:}
    [link][Title][/link]</td>

De este modo la especificación parent va precedida de un condicional que comprueba si el resultado está vacío y sólo muestra la cadena completa ( parent) cuando está presente. Algunas veces, parent puede ser calificado por Top en vez de All, lo cual da el nombre del documento de nivel superior que encierra una sección: en este caso, el nombre del libro. Con Top no es necesaria una cadena de separación.

Para concluir, presentamos algunos ejemplos que ilustran otras funciones. En la Figura <imgref figure_datelist_classifier>, DateList se utiliza en la clasificación Fechas de la colección Computists’ Weekly (el semanario de los informáticos) y resulta ser el segundo clasificador, esto es, CL2. El clasificador y las especificaciones de formato se muestran más adelante. El clasificador DateList difiere de AZList en que siempre clasifica por metadatos Date y en que las ramas inferiores de la jerarquía de consulta utilizan DateList en vez de Vlist, con lo que se agrega el año y el mes a la izquierda de las listas de documentos.

classify AZSectionList metadata=Creator
format CL2Vlist “<td>[link][icon][/link]</td>
                 <td>[Creator]</td>
                 <td>&nbsp;&nbsp;[Title]</td>
                 <td>[parent(Top):Date]</td>”

La especificación de formato muestra esos Vlists de manera apropiada.

El mecanismo de cadena de formato es flexible pero difícil de aprender. La mejor manera de proceder es estudiando los archivos de configuración de colecciones existentes.

El mecanismo [link] … [/link] en una cadena de formato, se crea un enlace con el formato HTML del documento, donde el hipervínculo es el título del documento: cuando se hace clic en el enlace se abre la versión HTML del documento. En algunas colecciones es útil poder visualizar otras versiones del documento. En una colección de documentos con formato Word de Microsoft, por ejemplo, es bueno poder abrir una versión Word de cada documento en lugar de la HTML que se ha extraído de ella; lo mismo ocurre con los documentos PDF.

Para poder mostrar diferentes versiones de un documento, la solución es incorporar la información necesaria (es decir, dónde se encuentran las demás versiones) al formato de archivo de Greenstone del documento. Esta información se representa en forma de metadatos. Recuerde que al colocar:

[link][Title][/link]

en una cadena de formato, se crea un enlace con el formato HTML del documento, donde el  hipervínculo es el título del documento. Tanto los conectores de Word como los de PDF generan metadatos srclink, de modo que si se introduce:

[srclink][Title][/srclink]

en una cadena de formato, se crea un enlace con la versión Word o PDF del documento, donde el hipervínculo es también en este caso el título del documento. A fin de que aparezcan los iconos correspondientes a los documentos Word y PDF, estos conectores generan también metadatos srcicon de tal forma que:

[srclink][srcicon][/srclink]

crea un enlace etiquetado por el icono estándar de Word o PDF (según el caso) y no por el título del documento.

El conjunto de la interfaz de usuario de Greenstone se controla mediante macros que se encuentran listados en el directorio GSDLHOME/macros . Estas macros están escritas en un lenguaje especialmente concebido para Greenstone y se utilizan en el momento de la ejecución para generar páginas Web. La traducción del lenguaje macro al formato HTML es la última etapa para mostrar una página. Así pues, las modificaciones de un archivo de macros afectan inmediatamente la presentación en pantalla y permiten experimentar rápida y fácilmente. Todos los archivos de macros que utiliza Greenstone se encuentran en GSDLHOME/etc/main.cfg y se cargan cada vez que se arranca el programa. La única excepción es cuando se utiliza la Biblioteca Local de Windows: en este caso es necesario reiniciar el proceso.

Las páginas Web se generan al instante por numerosas razones y el sistema de macros le permite a Greenstone funcionar con la flexibilidad necesaria. Las páginas pueden presentarse en diversos idiomas y existe un archivo de macros diferente para almacenar todo el texto de la interfaz en cada lengua. Cuando Greenstone presenta una página, el intérprete de macros comprueba la variable de idioma y carga la página en la lengua apropiada (aunque no llega a traducir el contenido del documento). Además, los valores de determinadas variables de visualización, como el número de documentos encontrados en una búsqueda, no se conocen de antemano, sino que se interpolan en el texto de la página mediante macros.

Los archivos de macros tienen la extensión .dm. Cada archivo define uno o más paquetes ( packages), cada uno de los cuales contiene una serie de macros utilizadas con un fin preciso y único. Al igual que los clasificadores y los conectores, hay una base a partir de la cual se elaboran las macros, que se llama base.dm ; este archivo define el contenido básico de una página.

Los nombres de las macros empiezan y terminan con una rayita de subrayado y su contenido se define mediante llaves. El contenido puede ser texto llano, HTML (incluidos los enlaces con pequeños programas ( applets) de Java y JavaScript), nombres de macros o cualquier combinación de estos elementos. La siguiente macro procedente de base.dm define el contenido de una página en ausencia de cualquier otra macro que la invalide:

_content_ {<p><h2>Oops</h2>_textdefaultcontent_}

En la parte superior de la página aparecerá el mensaje “Oops”, seguido de la macro _textdefaultcontent_, que en inglés equivale a  The requested page could not be found. Please use your browsers ‘back’ button or the above home button to return to the Greenstone Digital Library, y en otros idiomas aparecerá la correspondiente traducción de esta frase. En español, por ejemplo, se podrá leer: No se pudo encontrar la página solicitada. Pulse el botón “Atrás” o el botón de “Página principal” para volver a la Biblioteca Digital Greenstone.

Las macros _textdefaultcontent_ (contenido del texto por defecto) y _content_ (contenido) se encuentran en el paquete global porque son necesarias para todas las partes de la interfaz de usuario. Las macros pueden utilizar como contenido macros de otros paquetes, mas para ello deben anteponer sus nombres y el de su paquete. Por ejemplo, la macro:

_collectionextra_ {Esta colección contiene_about:numdocs_documentos. Se constituyó por última vez hace _about:builddate_ días.}

procede del archivo english.dm y se utiliza como descripción por defecto de una colección. Forma parte del paquete global, pero _numdocs_ y _ builddate _ pertenecen ambas al paquete about, por ello about: precede sus nombres.

Las macros suelen contener instrucciones condicionales que se parecen a las cadenas de formato condicionales antes mencionadas, aunque su apariencia difiere un poco. El formato básico es _ If _ (x,y,z), en que x es una condición, y es el contenido de la macro que se debe utilizar si esta condición se cumple, y z el contenido que se debe utilizar en caso contrario. Los operadores de comparación son los mismos que los operadores simples utilizados en Perl (menor que, mayor que, igual a, diferente de). El siguiente ejemplo procedente del archivo base.dm se utiliza para determinar cómo visualizar la parte superior de la página acerca de de una colección:

_imagecollection_ {
   _If_("_iconcollection_" ne "",
       <a href = "_httppageabout_">
           <img src = "_iconcollection_" border = 0>
       </a>,
       _imagecollectionv_)
}

Esto puede parecer un poco críptico. La macro _iconcollection _ desemboca en la cadena vacía si la colección carece de icono, o en el nombre del archivo de una imagen. Haciendo la paráfrasis del código antes mencionado: si existe una imagen de colección, presentar el encabezado de página acerca de esta colección (al que se remite mediante _httppageabout_) y luego esa imagen; de otro modo, utilizar la presentación alternativa _imagecollectionv_.

Las macros pueden incluir argumentos. Hay aquí una segunda definición de la macro _imagecollection_ que sigue inmediatamente la definición antes indicada en el archivo base.dm:

_imagecollection_[v=1]{_imagecollectionv_}

El argumento [v=1] especifica que la segunda definición se utiliza cuando Greenstone se ejecuta en modo “sólo texto”. Las macros de idiomas funcionan de la misma manera: todas especifican su lengua como argumento, salvo english.dm porque es el idioma por defecto. Por ejemplo:

_textimagehome_ {Home Page}

aparece en el archivo de macro de lengua inglesa, mientras que la versión alemana es:

_textimagehome_ [l=de] {Hauptaseite}

Las versiones inglesa y alemana se encuentran en el mismo paquete, aunque en archivos diferentes (las definiciones de paquetes pueden ocupar más de un archivo). Greenstone utiliza su argumento l en el momento de la ejecución para determinar qué idioma se debe visualizar.

<imgcaption figure_part_of_the_aboutdm_macro_file|%!– id:714 –%Parte del archivo de macros about.dm ></imgcaption>

package about
############################################
# about page content
############################################
_pagetitle_ {_collectionname_}
_content_ {
<center>
_navigationbar_
</center>
_query:queryform_ 
<p>_iconblankbar_
<p>_textabout_
_textsubcollections_
<h3>_help:textsimplehelpheading_</h3>
_help:simplehelp_
}
_textabout_ {
<h3>_textabcol_</h3>
_Global:collectionextra_
}

Por último, en la Figura <imgref figure_part_of_the_aboutdm_macro_file> se muestra un extracto del archivo de macros about.dm que se utiliza para configurar la página acerca de de cada colección. Este ejemplo muestra la definición de tres macros: _pagetitle_, _content_ y _textabout_.

Las macros son instrumentos de alta potencia que pueden parecer un poco complicados y crípticos. Sin embargo, con unos buenos conocimientos de HTML y un poco de práctica pueden convertirse en una manera rápida y fácil de personalizar su sitio Greenstone.

Supongamos, por ejemplo, que usted quería crear una página estática parecida a su sitio Greenstone actual. Puede usted crear un nuevo paquete, que se llamará static por ejemplo, en un nuevo archivo, e invalidar la macro _ content_. Agregue el nuevo nombre de archivo a la lista de macros situadas en GSDLHOME/etc/main.cfg que Greenstone carga cada vez que arranca. Por último, acceda a la nueva página utilizando su URL Greenstone normal y añada los argumentos ?a=p&p=static (por ejemplo: http://servidor/cgi-bin/library?a=p&p=static).

Para cambiar el “aspecto y estilo” de Greenstone puede modificar los paquetes base y style (estilo). Para cambiar la página principal de Greenstone, modifique el paquete home (como se explica en la Guía de Instalación de la Biblioteca Digital Greenstone). Para cambiar la página de búsqueda, modifique query.dm.

Experimente sin miedo con las macros. Las modificaciones aparecen instantáneamente porque las macros se interpretan a medida que se visualizan las páginas. El lenguaje de macros es un instrumento útil que puede servirle para personalizar a su gusto el sitio Greenstone.

<tblcaption table_the_packages_directory_1|El directorio packages (paquetes)></tblcaption>

El directorio packages (paquetes), cuyo contenido se muestra en el Cuadro <tblref table_the_packages_directory_1>, es donde se guardan todos los códigos utilizados por Greenstone pero elaborados por otros equipos de investigadores. Todos los programas informáticos distribuidos con Greenstone cumplen los requisitos de la Licencia Pública General de GNU. Los ejecutables producidos por esos paquetes se colocan en el directorio bin de Greenstone. Cada paquete se guarda en su propio directorio. Sus funciones varían considerablemente, desde indizar y comprimir hasta convertir documentos de Word de Microsoft en el formato HTML. Cada paquete tiene un archivo README (LÉAME) que proporciona informaciones complementarias sobre el mismo.