3. OKAPI

3.1. Introducción

El sistema OKAPI es uno de los primeros modelos probabilísticos de recuperación de documentos. Robertson y Sparck Jones lo propuso a finales de los noventa, por lo que se trata de un programa sencillo, pero que se ha convertido en un modelo standard para la investigación empírica.

En este modelo, la distribución sobre los documentos son estimadas desde dos clases: "relevant" y "non-relevant". Los documentos se descomponen en atributos, el caso más simple es el de indicar si hay ocurrencia o no ocurrencia de las palabras individuales, y los atributos son modelados de manera independiente (como en el modelo Bayes para clasificación). En comparación con la clasificación de los documentos, sin embargo, la recuperación es muy simple para la formación de los datos, y la única demostración disponible para estimar los modelos es la pregunta en sí misma.

El sistema OKAPI primero era de la City University y ahora pertenece a Microsoft. La implementación completa de este es el "Okapi-Pack" (http://www.soi.city.ac.uk/~andym/OKAPI-PACK), que está disponible desde el Centro para la Búsqueda de sistemas interactivos de búsqueda (Centre Pro Interactive Systems Research CISR) desde una simbólica cuota. Los compradores se comprometen a usar el Okapi solo para tareas de investigación, en ningún caso se podrá usar como parte de cualquier producto comercial.

3.2. Características técnicas del programa para la instalación del "Okapi-Pack"

El sistema de distribución requiere alrededor de 100 Mbytes de disco. Hay dos versiones disponibles del Okapi-Pack: para Solaris y para Linux. La versión para Solaris está diseñada para trabajar sobre una estación Sun Sparc con un mínimo de 16 Mbytes de memiria en un Solaris 2.5/2.6. Y la versión para Linux trabaja sobre una Red Hat Linux 6.0/6.1.

El paquete de Okapi consta de tres partes:
3.2.1. El software de indexación.
3.2.2. El Sistema Básico de Búsqueda (Basi Search System: BSS).
3.2.3. La Interface Interactiva de Okapi.

3.2.1. SOFTWARE DE INDEXACIÓN

Es el software que permite a los usuarios crear e indexar modelos de bases de datos de Okapi. Incluye un interface gráfico para el usuario (indexer) como introducción básica del proceso de indexación. Esta interface sólo puede trabajar con bases de datos que ocupen un solo disco.

Permite la creación e indexación de dos tipos de bases de datos:

Texto - Tienen un máximo de cuatro campos.- Las líneas de los documentos estarán delimitadas por caracteres.Un ejemplo de esta base de datos es la colección Medlars, que provee el paquete Okapi.
Abstracción e indexación - Tiene un máximo de 31 campos.- Los campos de los documentos fuente están delimitados por < linefeed > caracteres; normalmente no hay caracteres entre los campos.Un ejemplo de esta base de datos es de la colección CACM, que también integra Okapi.


El sistema Okapi incluye estos dos ejemplos de bases de datos con alrededor de 1000 grabaciones en cada una de ellas:
- med.sample: una pequeña base de datos de texto generada por la colección Medlars.
- Cacm.sample: una pequeña base de datos generada por la colección CACM.


3.2.1.1. Localización de archivos

Todos los archivos se encuentran en el directorio o subdirectorio de <OKAPI_ROOT>. Cuando el usuario se familiariza con el sistema tiene la posibilidad de reorganizar los archivos. La localización de archivos es diferente de acuerdo con los distintos tipos de bases de datos de archivos:

a) Bases de datos de parámetros de archivos: están guardadas en <OKAPI_ROOT>/databases y cada base de datos requiere tres archivos:
- <db_name>
- <db_name>.field_tupes
- <db_name>.search_groups
b) Okapi de intercambio de formato de archivos: los archivos de datos están almacenados en <OKAPI_ROOT>/datafiles.
c) Transformación de bases de datos: después de un proceso de conversión de la base de datos, los archivos se almacenan en <OKAPI_ROOT>/bibfiles.
d) Índices: Después de un proceso de transformación de los archivos, los datos se guardan en <OKAPI_ROOT>/bibfiles.

3.2.1.2. Final de campo y grabación de caracteres

En el formato de cambio de un documento, cada campo se termina con un carácter final de campo (field mark). Y cada grabación termina con un carácter de grabación (record mark).

3.2.1.3. Variables del entorno

Es necesario establecer unas variables del entorno antes de trabajar con el sistema. El archivo .indexirc_rc en el directorio <GUI_CONFIG_FILES> es leído por la aplicación cuando ésta está en funcionamiento. Esto establece los valores de ciertos parámetros requeridos.

3.2.1.4. Recorriendo la aplicación de indexación, "indexer"

Hay seis pantallas para definir completamente la base de datos y los parámetros index. No es necesario completar las seis pantallas de una vez. Para ello el usuario debe guardar los archivos recientes en cualquier pantalla y abandonar la aplicación. Cuando la aplicación se reinicia los parámetros de los archivos que habíamos guardado pueden ser recuperados y se puede seguir el proceso de indexación.

Es necesario introducir los siguientes cuatro directorios en la primera pantalla:

1. Directorio raíz de la aplicación.
2. Directorio de parámetros de archivos del Sistema Básico de Búsqueda (BSS_PARMPATH).
3. Directorio de conversión de bases de datos y de índices.
4. Directorio de intercambio del formato de archivos.

El proceso puede abandonarse en cualquier momento y reestablecerse en el futuro. Cada pantalla tiene tres botones en la parte inferior:

- Next: pasar a la siguiente pantalla.
- Previous: volver a la pantalla anterior.
- Options: Se desplega una pantalla de menú con las siguientes opciones:
Set logging level > se puede elegir entre Full logs para guardar todos los comandos tcl de la interface; o Indexing commands para guardar sólo los comandos que son llamados por el proceso de indexación.
Read Current Parameter File(s)
Save Current Parameter File(s)
Load Nex Parameter File(s)
Exit

Set logging level >
Full logs Indexing commands
Read Current Parameter File(s)
Save Current Parameter File(s)
Load New Parameter File(s)
Exit


3.2.2. EL SISTEMA BÁSICO DE BÚSQUEDA (BSS)

Consiste en un grupo de comandos de bajo nivel que permite a los usuarios construir sus propias interfaces. Todos los comandos, argumentos, cualificadores, etc, excepto los términos que son buscados o parseados son casi independientes. Prácticamente todos los argumentos y cualificadores serán dados en el formulario <argument name>=value. Hay pocos casos donde el nombre es innecesario o inválido.

El sistema de búsqueda tiene tres funciones:

1. iinit(): esta función debe ser llamada antes de que algún comando funcione.
2. iexit(): esta función borra temporalmente al final del programa. No se puede modificar.
3. i0(): esta función es llamada con dos caracteres arrays, por ejemplo: return_code = i0(command, response).

3.2.2.1. Funcionamiento del sistema de búsqueda

<command> contiene un comando válido. En el caso de ser un sistema feedback de relevancia, este debe ser bastante amplio si se van a solicitar el parseo de grandes cadenas de texto.
<response> contiene el resultado devuelto por <command>.
Y <return_code> debe ser un entero:
- cero: cuando el <command> ejecutado es OK
- Positivo: se ha producido un error en el proceso.
- Negativo: se ha detectado un error definitivo.

El sistema incluye opciones especiales, operadores quasi-booleanos, operaciones con los pesos y otras operaciones especiales.

La pertinencia o no de los documentos se define mediante la asignación de pesos. Finalmente los resultados se muestran ordenados por varios factores.


3.2.3. LA INTERFAZ INTERACTIVA DE OKAPI

Okapi es una interfaz configurable que utiliza los comandos del sistema básico de búsqueda (BSS). Permite a los usuarios mantener un feedback en ambas bases de datos. El sistema permite a los usuarios:
- Construir una pregunta inicial introduciendo términos simples o preguntas.
- Conducir una búsqueda formulando una pregunta.
- Ver los documentos completos y hacer juicios de relevancia.
- Aumentar incrementalmente la consulta cuando se hacen juicios de relevancia.
- Modificar el estado actual de la pregunta añadiendo o borrando términos y aclarando la información relevante en el feedback.
- Cambio de algunos parámetros de la interfaz interactivamente.

La interfaz de Okapi está compuesta por:

1. Una ventana principal dividida en seis áreas:
- Entrada de preguntas: Un texto de entrada para que el usuario introduzca términos de la pregunta.
- Procesamiento de la pregunta: lista de ranking de los términos en la pregunta procesada actual.
- Modificación de térninos: es una lista que muestra los términos eliminados por el usuario en el transcurso del proceso de la consulta.
- Hitlist: Lista de los términos más repetidos.
- Juicios positivos de relevancia: ranking de los juicios relevantes realizados por el usuario.
- Funciones: Al final de la ventana hay tres botones:
- Búsqueda
- Opciones de preguntas
- Salida

1. Term Entry Box
2. Working query
3. Hitlist
4. Removed Terms
5. Rels Pool
6a. Search
6b. Options
6c. Exit


2. Una ventana de texto que aparece con los documentos completos seleccionados por la lista producida internamente. Al final de la pantalla hay dos botones para que el usuario pueda realizar juicios de relevancia al documento.

Full Document Display
Relevant
Not Relevant

 

Volver arriba

PÁGINA DE INICIO