Implantación del sistema cliente-servidorwebdiis.unizar.es/asignaturas/ISBC/isbc/PLN/memoria.doc · Web viewProblemas encontrados en el ... 14.4 Pasos a seguir para la ejecución

Realizado por:

Moisés Gil Soldevilla

Bajo la dirección de:

José Ángel Bañares Bañares

2002

Departamento de Informática e Ingeniería de SistemasCentro Politécnico SuperiorUniversidad de Zaragoza

María de Luna 350015, Zaragoza

http://iaaa.cps.unizar.es

Interfaz en lenguaje natural a través de Web para el acceso a los servicios de búsqueda de un catálogo de información geográfica acorde con el estándar OpenGIS

http://iaaa.cps.unizar.es/

Procesamiento del lenguaje natural

AGRADECIMIENTOS

A los amigos y compañeros que con su apoyo han hecho más llevadero la realización de este proyecto.

A mis padres por su confianza, tesón y sacrificio.

“Si uno no puede explicar lo que ha estado haciendo, su trabajo carecerá de valor”Erwin Schödinger

“Me lo contaron y lo olvidé, lo vi y lo entendí, lo hice y lo aprendí”Confucio

“El que no quiere zarpar hasta que hayan desaparecido todos los peligros nunca se hará a la mar”Thomas Fuller

b


Índice1 Organización de la memoria----------------------------------------------------------------------1

2 El presente proyecto final de carrera------------------------------------------------------------2

2.1 Tema--------------------------------------------------------------------------------------------2

2.2 Motivación personal-------------------------------------------------------------------------2

2.3 Contexto del proyecto-----------------------------------------------------------------------22.3.1 Objetivos del proyecto ISIGIS---------------------------------------------------------4

2.4 Objetivos del proyecto-----------------------------------------------------------------------5

2.5 Tareas realizadas-----------------------------------------------------------------------------5

2.6 Herramientas y tecnologías utilizadas----------------------------------------------------62.6.1 Java----------------------------------------------------------------------------------------6

2.6.1.1 Applet----------------------------------------------------------------------------------72.6.1.2 JDK-------------------------------------------------------------------------------------72.6.1.3 JBuilder--------------------------------------------------------------------------------7

2.6.2 Lisp----------------------------------------------------------------------------------------72.6.2.1 CLOS-----------------------------------------------------------------------------------8

2.6.3 Visual Basic------------------------------------------------------------------------------82.6.4 Sockets y CORBA-----------------------------------------------------------------------82.6.5 DYPAR-----------------------------------------------------------------------------------82.6.6 RMI----------------------------------------------------------------------------------------82.6.7 AODBC-----------------------------------------------------------------------------------82.6.8 HTTP--------------------------------------------------------------------------------------92.6.9 XML, parser XML-----------------------------------------------------------------------92.6.10 Wordnet-----------------------------------------------------------------------------------92.6.11 Rational Rose-----------------------------------------------------------------------------92.6.12 Edge diagrammer------------------------------------------------------------------------9

2.7 Justificación de las tecnologías y herramientas utilizadas---------------------------9

2.8 Problemas encontrados en el desarrollo del proyecto-------------------------------10

3 Introducción al procesamiento del lenguaje natural----------------------------------------11

3.1 Lenguaje--------------------------------------------------------------------------------------11

3.2 Lenguaje natural----------------------------------------------------------------------------11

3.3 Procesamiento computacional del lenguaje natural (PLN)-------------------------123.3.1 Introducción-----------------------------------------------------------------------------123.3.2 Un poco de historia---------------------------------------------------------------------123.3.3 Clasificación----------------------------------------------------------------------------133.3.4 Aplicaciones del procesamiento del lenguaje natural-----------------------------133.3.5 Problemas-------------------------------------------------------------------------------14

3.3.5.1 El problema de la Ambigüedad----------------------------------------------------143.3.5.2 Posibilidades-------------------------------------------------------------------------14

3.3.6 Ventajas e inconvenientes-------------------------------------------------------------14

3.4 Interfaces de lenguaje natural------------------------------------------------------------15

4 Gramáticas------------------------------------------------------------------------------------------16

i


4.1 Tipos de gramáticas------------------------------------------------------------------------164.1.1 Sistemas de comparación de patrones.----------------------------------------------164.1.2 Sistemas basados en la sintaxis-------------------------------------------------------164.1.3 Gramáticas semánticas-----------------------------------------------------------------174.1.4 Integración del discurso---------------------------------------------------------------184.1.5 Análisis de la pragmática--------------------------------------------------------------18

4.2 Gramáticas y analizadores----------------------------------------------------------------18

4.3 Elementos de una gramática--------------------------------------------------------------194.3.1 Terminales y no terminales-----------------------------------------------------------194.3.2 Patrones----------------------------------------------------------------------------------194.3.3 Operadores utilizados en DYPAR---------------------------------------------------19

4.3.3.1 Operadores para indicar opcionalidad--------------------------------------------194.3.3.2 Operadores para equiparación de diferentes patrones--------------------------204.3.3.3 Asignación y referencia a variables-----------------------------------------------204.3.3.4 Comodines---------------------------------------------------------------------------214.3.3.5 Invocación de funciones------------------------------------------------------------21

4.3.4 Reglas------------------------------------------------------------------------------------21

4.4 Estrategias o normas de construcción de gramáticas--------------------------------234.4.1 Análisis previo--------------------------------------------------------------------------234.4.2 Distribución-----------------------------------------------------------------------------234.4.3 Complejidad vs. rapidez vs. potencia------------------------------------------------234.4.4 Pérdida y confusión del flujo de control--------------------------------------------234.4.5 Recursividad----------------------------------------------------------------------------234.4.6 Depuración------------------------------------------------------------------------------24

4.5 Extensibilidad--------------------------------------------------------------------------------24

4.6 Optimización---------------------------------------------------------------------------------24

4.7 Obtención de resultados intermedios---------------------------------------------------254.7.1 Asignación de variables---------------------------------------------------------------264.7.2 Devolución de valores-----------------------------------------------------------------264.7.3 Invocación de funciones---------------------------------------------------------------26

4.8 Diagrama de clases origen de la gramática--------------------------------------------26

4.9 Estructura gramatical utilizada----------------------------------------------------------314.9.1 Gramática base del lenguaje----------------------------------------------------------314.9.2 Gramática para el dominio de los metadatos de mapas---------------------------32

4.10 Historia del proceso de construcción de la gramática-------------------------------34

4.11 Esquema básico de la estructura gramatical desarrollada para el dominio de los metadatos de mapas-----------------------------------------------------------------------------37

4.12 Estrategias de procesamiento-------------------------------------------------------------394.12.1 Considerando palabras atípicas-------------------------------------------------------394.12.2 Considerando sinónimos--------------------------------------------------------------394.12.3 Considerando sinónimos para lanzar las reglas sensibilizadas-------------------394.12.4 Consideración combinada-------------------------------------------------------------39

5 Estudio previo--------------------------------------------------------------------------------------40

6 Análisis----------------------------------------------------------------------------------------------41

ii


6.1 Idea--------------------------------------------------------------------------------------------41

6.2 Conceptos previos---------------------------------------------------------------------------42

6.3 Notación de un dfd--------------------------------------------------------------------------42

6.4 Consulta de catálogo-----------------------------------------------------------------------436.4.1 DFD del nivel de contexto------------------------------------------------------------436.4.2 DFD de nivel 1--------------------------------------------------------------------------446.4.3 Diagrama de secuencia----------------------------------------------------------------456.4.4 Miniespecificaciones-------------------------------------------------------------------45

6.5 Procesamiento de frases-------------------------------------------------------------------466.5.1 DFD del nivel de contexto------------------------------------------------------------466.5.2 DFD del nivel 1-------------------------------------------------------------------------466.5.3 Diagrama de secuencia----------------------------------------------------------------466.5.4 Miniespecificaciones-------------------------------------------------------------------50

6.6 Servidor de ficheros IOR------------------------------------------------------------------506.6.1 DFD del nivel de contexto------------------------------------------------------------506.6.2 DFD del nivel 1-------------------------------------------------------------------------516.6.3 Diagrama de secuencia----------------------------------------------------------------526.6.4 Miniespecificaciones-------------------------------------------------------------------53

7 Diseño-----------------------------------------------------------------------------------------------54

7.1 Módulos desarrollados para el procesamiento de las frases------------------------54

7.2 Diagrama de clases en la consulta del catálogo---------------------------------------58

7.3 Diagrama de clases en el servidor de ficheros IOR----------------------------------58

7.4 Diagrama de clases del servidor de thesaurus----------------------------------------60

7.5 Diagramas de clase de utilidades comunes---------------------------------------------60

8 Características soportadas------------------------------------------------------------------------61

8.1 Concurrencia--------------------------------------------------------------------------------61

8.2 Multiusuario---------------------------------------------------------------------------------61

8.3 Multiproceso---------------------------------------------------------------------------------61

8.4 Escalabilidad---------------------------------------------------------------------------------61

8.5 Tolerancia a fallos--------------------------------------------------------------------------61

9 Implementación------------------------------------------------------------------------------------639.1.1 Depuración------------------------------------------------------------------------------639.1.2 Modificaciones introducidas en DYPAR-------------------------------------------63

9.1.2.1 Thesaurus-----------------------------------------------------------------------------639.1.2.2 Lugares-------------------------------------------------------------------------------649.1.2.3 Personas, organizaciones, editores------------------------------------------------64

9.2 Implantación del sistema cliente-servidor entre DYPAR y el Applet del usuario65

9.3 Optimizaciones------------------------------------------------------------------------------65

9.4 Descripción básica de funcionamiento--------------------------------------------------669.4.1 Esquemas de funcionamiento---------------------------------------------------------66

iii


9.4.1.1 Concurrencia-------------------------------------------------------------------------66

9.5 Descripción detallada del funcionamiento---------------------------------------------679.5.1 Servidor DYPAR-----------------------------------------------------------------------679.5.2 Servidor de ficheros IOR--------------------------------------------------------------689.5.3 Applet------------------------------------------------------------------------------------689.5.4 DYPAR----------------------------------------------------------------------------------69

10 Tratamientos realizados por el intérprete de lenguaje natural DYPAR---------------70

10.1 Corrección ortográfica---------------------------------------------------------------------70

10.2 Eliminación de signos ortográficos------------------------------------------------------70

10.3 Supérfluos------------------------------------------------------------------------------------70

10.4 Semántica-------------------------------------------------------------------------------------70

10.5 Negaciones------------------------------------------------------------------------------------71

10.6 Contexto--------------------------------------------------------------------------------------71

10.7 Sinónimos-------------------------------------------------------------------------------------71

10.8 Atípicas----------------------------------------------------------------------------------------72

10.9 Elipsis y anáfora-----------------------------------------------------------------------------72

10.10 Aprendizaje-------------------------------------------------------------------------------73

10.11 Plurales-------------------------------------------------------------------------------------73

10.12 Ambigüedades----------------------------------------------------------------------------73

11 Test------------------------------------------------------------------------------------------------75

11.1 Ejemplos de frases reconocidas y su procesamiento---------------------------------75

11.2 Otras frases reconocidas-------------------------------------------------------------------77

12 Instalación---------------------------------------------------------------------------------------80

12.1 Conexión mediante ODBC----------------------------------------------------------------8012.1.1 Configuración en Windows-----------------------------------------------------------8012.1.2 Configuración en Oracle--------------------------------------------------------------8012.1.3 ODBC desde Lisp----------------------------------------------------------------------80

12.2 Habilitar concurrencia de CORBA en Lisp-------------------------------------------80

12.3 Instalación de wordnet---------------------------------------------------------------------80

13 Manual de usuario-----------------------------------------------------------------------------81

13.1 Requisitos-------------------------------------------------------------------------------------8113.1.1 Requisitos software--------------------------------------------------------------------8113.1.2 Requisitos hardware--------------------------------------------------------------------81

13.2 Interfaz con el usuario---------------------------------------------------------------------82

14 Manual del programador----------------------------------------------------------------------83

14.1 Relación de ficheros asociados al proyecto--------------------------------------------8314.1.1 Ficheros propios de DYPAR----------------------------------------------------------8314.1.2 Ficheros nuevos incorporados en DYPAR------------------------------------------8314.1.3 Ficheros de la consulta de catálogo--------------------------------------------------85

iv


14.1.4 Ficheros del servidor de ficheros IOR-----------------------------------------------8514.1.5 Ficheros del servidor de Thesaurus--------------------------------------------------8614.1.6 Ficheros del servidor de DYPAR----------------------------------------------------8614.1.7 Ficheros de gramática------------------------------------------------------------------8614.1.8 Ficheros de la b.d. asociada a la gramática-----------------------------------------8714.1.9 Memoria---------------------------------------------------------------------------------8714.1.10 Aserve---------------------------------------------------------------------------------8714.1.11 Parser XML--------------------------------------------------------------------------8714.1.12 Utilización de CPU------------------------------------------------------------------8814.1.13 Servidor de catálogo----------------------------------------------------------------88

14.2 Compilación----------------------------------------------------------------------------------8814.2.1 Compilación de DYPAR--------------------------------------------------------------8814.2.2 Compilación del interfaz lisp-wordnet----------------------------------------------88

14.3 El servidor de catálogo “catServer”-----------------------------------------------------8914.3.1 Cómo lanzar el servidor de catálogo localmente-----------------------------------89

14.4 Pasos a seguir para la ejecución manual de la aplicación completa--------------89

14.5 Librerías necesarias------------------------------------------------------------------------90

14.6 Cómo incorporar un operador nuevo en DYPAR------------------------------------91

14.7 Nuevos operadores incorporados a DYPAR------------------------------------------92

14.8 Modificación de operadores en DYPAR-----------------------------------------------93

14.9 Otras modificaciones realizadas en DYPAR------------------------------------------94

14.10 Operadores que no funcionan correctamente en DYPAR-----------------------94

14.11 Parametrización – configuración-----------------------------------------------------9514.11.1 Parámetros DYPAR-----------------------------------------------------------------9514.11.2 Propiedades Java--------------------------------------------------------------------97

15 Esfuerzos-----------------------------------------------------------------------------------------99

15.1 Esfuerzos totales-----------------------------------------------------------------------------99

15.2 Esfuerzos clasificados---------------------------------------------------------------------100

15.3 Esfuerzos detallados----------------------------------------------------------------------101

16 Posibilidades de futuro-----------------------------------------------------------------------103

17 Conclusiones-----------------------------------------------------------------------------------104

17.1 Desarrollo del proyecto-------------------------------------------------------------------104

17.2 Procesamiento computacional del lenguaje natural--------------------------------104

18 Definiciones------------------------------------------------------------------------------------105

18.1 AODBC--------------------------------------------------------------------------------------105

18.2 Applet----------------------------------------------------------------------------------------105

18.3 CLOS----------------------------------------------------------------------------------------105

18.4 CORBA--------------------------------------------------------------------------------------10518.4.1 CORBA--------------------------------------------------------------------------------10518.4.2 IOR-------------------------------------------------------------------------------------106

v


18.4.3 ORB------------------------------------------------------------------------------------10618.4.4 IDL--------------------------------------------------------------------------------------106

18.5 DYPAR--------------------------------------------------------------------------------------107

18.6 HILO (THREAD)-------------------------------------------------------------------------107

18.7 HTTP----------------------------------------------------------------------------------------108

18.8 PLN o NLP----------------------------------------------------------------------------------108

18.9 RMI------------------------------------------------------------------------------------------108

18.10 SIG (GIS)---------------------------------------------------------------------------------109

18.11 Sockets------------------------------------------------------------------------------------109

18.12 SQL----------------------------------------------------------------------------------------109

18.13 Wordnet----------------------------------------------------------------------------------109

18.14 XML---------------------------------------------------------------------------------------109

19 Información de contacto---------------------------------------------------------------------111

20 Bibliografía-------------------------------------------------------------------------------------112

20.1 Bibliografía informativa acerca del procesamiento del lenguaje natural------112

20.2 Bibliografía para el procesamiento computacional del lenguaje natural------112

20.3 Bibliografía técnica para la implementación----------------------------------------113

20.4 Bibliografía complementaria--------------------------------------------------------------113

vi


Índice de figuras

Fig. 1 Árbol de reconocimiento sintáctico...........................................................................16Fig. 2 Árbol de reconocimiento de una frase.......................................................................25Fig. 3 Paquetes que componen Isigis...................................................................................27Fig. 4 Diagrama de clases para el paquete “distribution”....................................................28Fig. 5 Diagrama de clases para el paquete “metadata”........................................................28Fig. 6 Diagrama de clases para el paquete “dataQuality”...................................................29Fig. 7 Diagrama de clases para el paquete “identification”.................................................30Fig. 8 Esquema de la distribución de la gramática base......................................................31Fig. 9 Esquema de la distribución de la gramática particular del dominio..........................32Fig. 10 Esquema seguido por la gramática desarrollada para el reconocimiento de una frase

37Fig. 11 Idea de funcionamiento de la aplicación a desarrollar.............................................41Fig. 12 DFD nivel de contexto de la consulta del catálogo...................................................43Fig. 13 DFD de nivel 1 de la consulta del catálogo...............................................................44Fig. 14 Diagrama de secuencia de la consulta del catálogo..................................................45Fig. 15 DFD del nivel de contexto del procesamiento de frases...............................................46Fig. 16 DFD de nivel 1 del procesamiento de frases.................................................................46Fig. 17 DFD de nivel 1 del procesamiento de frases.................................................................46Fig. 18 DFD del nivel de contexto del servidor de ficheros IOR..............................................50Fig. 19 DFD de nivel 1 del servidor de ficheros IOR...............................................................51Fig. 20 Diagrama de secuencia del servidor de ficherios IOR..................................................52Fig. 21 Diagrama de clases de la memoria................................................................................57Fig. 22 Esquema reflejando la comunicación y concurrencia...................................................66Fig. 23 Interfaz con el usuario...................................................................................................82Fig. 24 Evolución en la dedicación de esfuerzos a lo largo del tiempo....................................99Fig. 25 Distribución de esfuerzos por categorías....................................................................100Fig. 26 Errores en el software con respecto a las modificaciones...........................................102Fig. 27 Esquema del funcionamiento de CORBA..................................................................107Fig. 27 Esquema del funcionamiento de RMI.........................................................................108

vii


1 Organización de la memoria La primera parte consta más bien de descripciones:

Descripción de este proyecto final de carrera, sus objetivos, herramientas utilizadas, etc.

Introducción al lenguaje natural y su procesamiento computacional. Gramática: conceptos básicos.

En la segunda parte se explica las fases de desarrollo del proyectos:

Estudio previo Análisis Diseño Implementación Tratamientos realizado por DYPAR Test

La tercera parte corresponde a los manuales del usuario y del programador.

En la cuarta se realiza un análisis de los esfuerzos, junto con unas conclusiones sobre el proyecto.

La parte final está dedicada a definir de forma concisa los principales conceptos que se pueden hallar a lo largo de la memoria.

1


2 El presente proyecto final de carrera

2.1 TemaEl presente proyecto final de carrera está encaminado a proporcionar a un usuario, a través de una interfaz web, los mecanismos para que, mediante una sintaxis propia del lenguaje natural, acceda a los servicios ofertados por un catálogo de información geográfica acorde con el estándar de OpenGIS.

2.2 Motivación personalLas motivaciones de elección del procesamiento del lenguaje natural para el presente proyecto vienen originadas por el interés personal por la inteligencia artificial, y en especial, la parte relacionada con la interacción entre las máquinas y los seres humanos. Considero que dentro de la informática, la inteligencia artificial es un campo apasionante del que queda mucho por investigar. Esa posibilidad de investigación, fue una de las principales motivaciones para la elección de este proyecto.

2.3 Contexto del proyectoEl presente proyecto sirve de complemento al proyecto Isigis que está siendo desarrollado por el departamento IAAA del Centro Politécnico Superior de Zaragoza. En concreto permite recuperar metadatos de mapas mediante el uso del lenguaje natural. A continuación se describe un poco más en detalle qué abarca el proyecto Isigis.

La información geográfica, o “geodatos”, es información que describe fenómenos asociados directa o indirectamente con una localización (y posiblemente un tiempo y una orientación) relativa a la superficie de la Tierra. Esta clase de datos digitales está siendo recogida desde hace más de 35 años. La velocidad de esta recolección de geodatos se incrementa rápidamente con avances en tecnologías tales como los sistemas de imágenes de satélite de alta resolución, los sistemas de posicionamiento global (GPS, Glonass), los sistemas de bases de datos, las nuevas tecnologías de software aplicables al geoprocesamiento y con el creciente número de personas y organizaciones que están recogiendo y utilizando geodatos. Estos geodatos son descritos mediante un conjunto de informaciones denominadas metadatos geoespaciales.

El OpenGIS Consortium (ver http://www.opengis.org) es una organización sin ánimo de lucro, fundada en 1994 y dedicada a la promoción de nuevas aproximaciones técnicas y comerciales para geoprocesamiento abierto e interoperable, fundada por las más importantes entidades industriales, gubernamentales y académicas. Los miembros del OpenGIS Consortium comparten una visión positiva de una infraestructura nacional y global de información. En la que los geodatos y los recursos de geoprocesamiento se mueven libremente, completamente integrados con las últimas tecnologías de computación distribuidas, accesibles a cualquiera. Y así "geo-habilitar" una gran variedad de actividades, que se encuentran actualmente fuera del dominio del geoprocesamiento, abriendo de esta forma nuevos mercados. Su objetivo es conseguir acuerdos sobre interfaces de software estándar abiertos que posibiliten la interoperación entre sistemas de geoprocesamiento de vendedores diferentes y de diferentes tipos (GIS/SIG, teledetección, cartografía automática, gestión de instalaciones, etc.). La comunicación por medio de interfaces derivadas-de-consenso, sistemas diferentes accederán a datos y funciones de procesamiento de cada uno a través de redes. Según el propio OpenGIS Consortium apunta [SMB 96]:

2

http://www.opengis.org/


“Los desarrolladores que se adhieran a los estándares de interfaces definidos por OpenGIS crearán fácilmente aplicaciones que puedan manejar un completo rango de tipos de geodatos y funciones de geoprocesamiento. Los usuarios de geodatos podrán compartir un enorme espacio de datos puestos en red en el cual los datos espaciales serán conformes a un modelo genérico, incluso aunque los datos puedan haberse producido en diferentes momentos por grupos no relacionados utilizando diferentes sistemas de producción para diferentes propósitos. El OGIS y la tecnología de objetos que está subyacente, proporcionarán también los medios para crear un “browser” de recursos extraordinariamente capaz, que los usuarios emplearán a través de la red para adquirir datos y recursos de geoprocesamiento”.

OpenGIS define un estándar de servicios del catálogo (Catalog Services, ver [OGC 99]). En este estándar se define la interfaz que debe tener un catálogo que permita la domiciliación de metadatos de proveedores, así como la ejecución de búsquedas, basándose en un lenguaje estándar de consulta, y presentación de resultados mediante perfiles especiales de XML.

El catálogo de datos geoespaciales proporciona los servicios necesarios para que los proveedores de información geográfica puedan publicar informaciones descriptivas de sus productos, y los consumidores de información geográfica puedan efectuar búsquedas en estos metadatos publicados tratando de encontrar el/los productos que mejor se acomoden a sus necesidades. Dado el actual auge de Internet, el modo más lógico para llevar a cabo la construcción de un servicio de catálogo es apoyarse en sus recursos. Esto va a permitir un mayor nivel de accesibilidad (tanto de proveedores como de consumidores), además de proporcionar la plataforma perfecta para extender el catálogo convirtiéndolo en una biblioteca distribuida.

En 1992 el Comité Européen de Normalisation (CEN) creó el comité técnico 287 asignándole la responsabilidad de la estandarización de la información geográfica. Una familia de pre-estándares están siendo adoptados, incluyendo el ‘ENV (Euro-Norme Voluntaire) 12657 Geographic Information – Data description Metadata’. Muchos servicios de metadatos existentes en Europa están basados en el trabajo del CEN/TC 287. Esto ha llevado a proyectos Europeos como por ejemplo GDDD, Le Clef y el European Spatial Metadata Infraestructure (ESMI) a adoptar el uso de este estándar.

También en 1992, la Organización Internacional de Estándares (ISO) crea el comité 211 (ISO/TC 211) con responsabilidades en la “geomática”. En estos momentos se encuentran preparando una familia de estándares. Este proceso involucra un grupo de trabajo, un comité de borrador, un borrador del estándar internacional, y finalmente el propio estándar. En estos momentos, ISO ha lanzado el comité del borrador del estándar ‘ISO 15046-15 – GI – Metadata’. CEN/TC 287 mantiene el estado de enlace con ISO/TC 211, lo que significa que los resultados del trabajo en Europa serán tenidos en cuenta cuando se desarrolle en estándar global. En los Estados Unidos, el Comité Federal de Datos Geográficos (FGDC), ver [FDGC 00], aprobó su ‘Content Standard for Digital Geospatial Metadata’ en 1994. Este es un estándar nacional para metadatos espaciales desarrollado para dar soporte a la construcción de la Infraestructura Nacional de Datos Espaciales de los Estados Unidos. Este estándar ha sido adoptado en otros países como por ejemplo Sudáfrica o Canadá.

Algunos elementos de metadatos, como la sección de Keywords del CSDGM ó secciones similares en otros estándares, consiguen sus valores de listas predefinidas de controlled keyword. Estas listas definen un conjunto de términos representando conceptos y categorías dentro de uno o varios dominios temáticos que permiten clasificar y caracterizar datos provenientes de diferentes fuentes con términos relacionados. El uso de estas palabras clave controladas facilita el mapping entre un vocabulario seleccionado y una gran colección de datos geográficos. Esta capacidad de indexación, característica común de cualquier motor de búsqueda, aumenta el rendimiento de las consultas al catálogo basadas en estas secciones controladas. La implementación de estas controlled keywords está basada en un concepto más amplio denominado tesauro, que permite la definición de relaciones entre términos como jerarquías, equivalencia (sinónimos) y asociaciones. De esta manera

3


los metadatos se encuentran clasificados seguiendo determinadas organizaciones jerárquicas, lo cual facilita la búsqueda de los metadatos.

Estos procesos de clasificación están asistidos por autoridades y organizaciones reconocidas que proponen índices y listas. Algunos ejemplos de estas listas son: Las listas controladas “Discipline” y “Paramenter Type” proporcionadas por CEO [CEO 99]; el “NASA Master Directory” [NASA MD] propuesto por el FDGC como un tesauro estándar temático; el “GEMET GEneral Multilingual Environmental Thesaurus” propuesto por el European Topic Centre on Catalogue of Data Source de la Agencia Europea de Medioambiente; ó el “ADL Feature type Thesaurus” [Alexandria DL] para indicar la naturaleza de una localización geográfica. De todas formas, es posible también crear una lista controlada para un dominio específico que no haya sido considerado en listas más generales. Un ejemplo de esto podría ser la clasificación de datos geoespaciales que se ha generado para llevar a cabo la clasificación de los datos que la confederación Hidrográfica del Ebro tiene publicados en su página Web http://oph.chebro.es

Para aclarar el concepto de clasificación supongamos que un metadato se encuentra clasificado por los términos tipos climáticos del tesauro GEMET y España del tesauro CEOLOCATION, el metadato evidentemente trata de los tipos climáticos en España. Esta clasificación permite que si alguien busca información sobre los tipos climáticos españoles, la encuentre con facilidad y rápidamente ya que un vocabulario limitado clasifica una gran cantidad de información.

2.3.1 Objetivos del proyecto ISIGISSe trata de un proyecto atípico ya que no consiste en el desarrollo de una aplicación sin más y la oferta de un servicio de mantenimiento que es a lo que estamos acostumbrados. En este proyecto se trata de ofertar un servicio para lo que es necesario llevar a cabo distintos desarrollos software, establecer unos procesos, y crear unos contenidos en páginas Web.

Los objetivos de la primera versión son:

Construir un servidor de metadatos de datos geográficos a través de Internet.

Dar soporte a metadatos ajustados al estándar FGDC (en posteriores versiones ampliaremos al soporte de otros estándares: ISO, CEN).

Dos tipos de funcionalidad:

Almacenar metadatos

Gestión de proveedores

Altas/bajas/modificaciones de proveedores en base de datos

Proporcionar a los proveedores herramientas, ayudas y recomendaciones para la construcción de sus metadatos

Catalogación de metadatos

Creación de metadatos

Verificación de calidad de los metadatos

Gestión de su almacenamiento

Recuperar metadatos.

Servicios de búsqueda

Búsqueda simple

Búsqueda avanzada

4

http://oph.chebro.es/


Servicios de presentación

Presentación de resultados en página Web

Resultados en fichero XML

2.4 Objetivos del proyectoConseguir que no sea necesario que un usuario que precise acceder a los servicios de un catálogo de información geográfica tenga que conocer algún lenguaje específico de acceso (por ejemplo, OCQL proporcionado por OpenGIS), o completar algún tipo especial de formulario. En este proyecto se pretende desarrollar un sistema capaz de interaccionar con un usuario que emplea su propio lenguaje de comunicación con sus semejantes para formular preguntas dentro de un cierto dominio. En este caso, ese dominio es el acceso a los servicios ofertados por un catálogo de información geográfica.

En este proyecto se ha intentado realizar una interpretación del lenguaje natural escrito dentro del dominio de una base de datos con información relacionada sobre mapas (editores, personas de contacto, coordenadas, tipos de mapas, lugares, temas, etc).

Como objetivos globales caben destacar los siguientes:

Conocer las distintas estrategias que ayuden al procesamiento necesario para la interpretación del lenguaje natural.

Diseñar una gramática restringida al dominio de los metadatos sobre mapas.

Desarrollar y utilizar el software necesario para llevar a cabo la interpretación de las frases del usuario.

Aprender y profundizar en el manejo de herramientas y lenguajes, tales como CORBA, Java, Lisp, Sockets, VB, etc.

Conocer y poner en práctica las distintas formas de integrar una aplicación que hace uso de diferentes lenguajes.

Experiencia en el desarrollo completo de un proyecto.

2.5 Tareas realizadas Investigación del estado del arte del procesamiento del lenguaje natural en lo que

respecta a la recuperación de información.

Depuración del intérprete de gramáticas que se ha usado (DYPAR).

Construcción de una gramática base del lenguaje inglés.

Construcción de una gramática específica para el dominio de los metadatos de mapas.

Incrementar la potencia de procesamiento de DYPAR mediante:

o Uso de wordnet como diccionario para la búsqueda de sinónimos.

o Aprendizaje y adaptación del interfaz de comunicación entre wornet y Lisp.

o Acceso a bases de datos externas (en internet) para la comprobación de datos.

o Acceso a un servidor de lugares a través de internet.

o Acceso a un servidor de thesaurus también utilizando internet.

5


o Creación de una memoria que vaya asimilando conocimiento sobre estructuras ES-UN.

o Realizar un desarrollo para permitir multiusuario.

Permitir el uso de varios DYPAR ejecutándose en distintas máquinas. De esta forma se evita la saturación, permitiendo distribuir el trabajo. Con esto se consigue que la aplicación sea escalable conforme el número de usuarios aumenta.

Creación de un servidor que centralice la información sobre la situación de los servidores DYPAR activos. Este servidor dará la localización del servidor DYPAR menos saturado y que siga en activo.

Creación de un servidor del lado de DYPAR para atender las solicitudes de procesamiento de frases.

Creación de un programa que calcule la carga de trabajo de la CPU

Creación del interfaz con el usuario accesible por web para permitir al usuario realizar consultas del catálogo empleando el lenguaje natural.

Averiguar cuál es el servidor DYPAR óptimo (cuya máquina tiene menos sobrecarga de trabajo).

Invocar los servicios apropiados para recuperar la información del catálogo.

Búsqueda, utilización y adaptación de una aplicación (aserve) que implementa el protocolo HTTP. Utilizada para recuperar información sobre lugares.

Instalación y uso de Apache para hacer pruebas sin necesidad de estar conectado a internet.

Recoger y procesar la respuesta que en formato XML es enviada por el servidor de lugares. Para ello se utiliza un parser de XML.

Implementar un servidor de thesaurus que recoja las solicitudes de información recibidas e informe al solicitante si se trata de un tema.

2.6 Herramientas y tecnologías utilizadas2.6.1 JavaJava es un lenguaje de programación relativamente reciente que surge en 1994 diseñado por Sun Microsystems. Java se anunció originalmente como una forma de agregar “contenido dinámico” a las páginas de la World Wide Web. Sin embargo, debido a sus características, se ha convertido en uno de los lenguajes de programación de aplicación general más importantes del mundo.

Características de Java:

Simple: Java ofrece toda la funcionalidad de un lenguaje potente, pero sin las características menos usadas y más confusas de éstos.

Orientado a objetos

Facilita la distribución: Java se ha construido con extensas capacidades de interconexión TCP/IP.

6


Robusto: Java realiza verificaciones en busca de problemas tanto en tiempo de compilación como en tiempo de ejecución. Comprobación de tipos, límites de arrays, etc.

Arquitectura neutral, es decir, multiplataforma. Lo que permite tener independencia de las máquinas que se usen, tanto para alojar el servidor como el cliente.

Seguro: la seguridad en Java tiene dos facetas. En el lenguaje, características como los punteros o el casting implícito que hacen los compiladores de C y C++ se eliminan para prevenir el acceso ilegal a la memoria. Cuando se usa Java para crear un navegador, se combinan las características del lenguaje con protecciones de sentido común aplicadas al propio navegador.

Multithreaded: Java permite muchas actividades concurrentes en un programa.

El uso de Java en este proyecto ha sido debida a la necesidad de utilizar servicios que ya estaban desarrollados en este lenguaje. La posibilidad de profundizar en la programación orientada a objetos, así como la potencia del mismo han sido también un aliciente para su utilización.

2.6.1.1 Applet

Programa de Java que se ejecutará en un navegador de páginas web. Se utiliza un applet para implementar el interfaz con el usuario para que cualquier usuario conectado a internet tenga la posibilidad de acceder desde su navegador al catálogo, empleando el lenguaje natural.

2.6.1.2 JDK

El jdk (Java Development Kit) es un conjunto de herramientas que permiten realizar programas en java. Este kit permite hacer cualquiera de las aplicaciones Java posibles, no tiene limitaciones en este sentido, sin embargo, no es lo más adecuado para desarrollar, ya que carece de un editor propio de código fuente, de un gestor de proyectos, de una herramienta de diseño visual de interfaces, etc.

2.6.1.3 JBuilder

JBuilder es un entorno de desarrollo integrado (IDE) de programas basados en tecnología Java. Ha sido desarrollado por Borland, empresa con una larga historia en el desarrollo de herramientas de programación.

JBuilder está basado en el JDK y en algunas librerías que incluye de serie que no incluye el JDK estándar. Esto implica que JBuilder en sí mismo, no sea más que un editor con accesos cómodos a la ayuda de Java, as su compilador, a su depurador, etc. Además permite diseñar interfaces gráficos de usuario, visualmente, lo cual es bastante cómodo, fácil y rápido.

JBuilder ha sido utilizado en el proyecto como entorno de trabajo en el desarrollo de los programas Java.

2.6.2 Lisp El LISP es, como se sabe, uno de los lenguajes de programación en uso más antiguos. A finales de los años 50, John McCarthy, a quien se considera como el padre de la Inteligencia Artificial, diseñó este lenguaje para servir como herramienta de programación en esta disciplina.

El desarrollo de Lisp fue posible, en gran medida, por el entusiasmo y apoyo activos de la Agencia de Proyectos de Investigación Avanzados de la Defensa (DARPA).

7


En la actualidad, hay un creciente desarrollo de programas que presentan lo que la mayoría considera un comportamiento inteligente. Casi todos esto programas inteligentes, o que aparentan serlo, están escritos en Lisp.

Una gran ventaja de usar LISP es que suele citarse frente a las demás alternativas de los lenguajes usados para la Inteligencia Articial es su gran flexibilidad y uniformidad. Los procedimientos y datos en Lisp tienen la misma forma. Un programa en Lisp puede usar otro programa como dato, incluso puede crear otro programa y usarlo.

Lo que le hace ser apropiado para el procesamiento del lenguaje natural es su facilidad para el manejo de símbolos.

El uso de Lisp en el proyecto ha venido motivado porque el código fuente de DYPAR está escrito con este lenguaje. Además Lisp es un lenguaje muy apropiado para el procesamiento de palabras, frases, etc.

2.6.2.1 CLOS

CLOS: extensión de Lisp para abarcar la programación orientada a objetos.

CLOS ha sido utilizado para el desarrollo de distintas partes que aumentan la potencia de DYPAR-

2.6.3 Visual Basic Lenguaje de programación visual muy potente para definir interfaces gráficos con facilidad y rapidez.

Utilizado un poquito en este proyecto por disponer de potentes librerías. Con las cuales se averigua la carga de la CPU.

2.6.4 Sockets y CORBANecesarios para la comunicación de información entre distintos lenguajes de programación.

Para más información acerca de Sockets y CORBA ver el apartado de Definiciones.

2.6.5 DYPAR Analizador de frases. Interpreta las frases de lenguaje natural apoyándose en las gramáticas definidas.

Para más información acerca de DYPAR ver el apartado de Definiciones.

2.6.6 RMIVer información complementaria de RMI en el anexo.

Se hace un uso indirecto de RMI a la hora de acceder al servidor de catálogo.

2.6.7 AODBC El interfaz ODBC (Open DataBase Conectivity) para Allegro permite acceder a las bases de datos usando el lenguaje de consultas SQL (Structured Query Languaje). Con ODBC se puede trabajar con cualquier base de datos que utilice SQL sin la necesidad de cambiar código en la aplicación al cambiar de gestor de la B.D.

8


En este proyecto se utiliza para acceder desde Lisp directamente a una B.D. de una máquina remota y realizar determinadas consultas.

Para más información acerca de AODBC ver el anexo de definiciones.

2.6.8 HTTP Este protocolo se utiliza en el proyecto para comunicarse con el servidor de lugares.

Para más información acerca de DYPAR ver el apartado de Definiciones.

2.6.9 XML, parser XML XML, es el estandar de Extensible Markup Language. XML no es más que un conjunto de reglas para definir etiquetas semánticas que organizan un documento en diferentes partes. XML es un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas estructurados.

Para más información acerca de XML ver el apartado de Definiciones.

La información sobre los lugares se reciben en formato XML, es necesario realizar un análisis del mismo (parser XML) para procesar la respuesta.

2.6.10 WordnetDiccionario inglés con sus términos relacionados.

Utilizado en este proyecto para averiguar los sinónimos de una palabra.

Para más información acerca de Wordnet ver el apartado de Definiciones.

2.6.11 Rational RoseHerramienta CASE que facilita el análisis y diseño de aplicaciones siguiendo metodologías orientadas a objeto.

La realización de los diagramas de clase y de secuencia fueron realizados con esta herramienta.

2.6.12 Edge diagrammerHerramienta empleada para la realización de los diagramas de flujo de datos (DFD).

2.7 Justificación de las tecnologías y herramientas utilizadasSe puede observar el uso de distintos lenguajes de programación para la realización de este proyecto. Esto es debido a que se debía hacer uso del software existente: DYPAR, que estaba programado en Lisp, y los distintos servicios de acceso al catálogo que estaban programados en Java.

Al tratar con distintas fuentes de información externas, cada una tiene que ser accedida de una determinada manera. De ahí el uso de HTTP, XML-parser, RMI, sockets, corba, ODBC, etc.

9


2.8 Problemas encontrados en el desarrollo del proyecto La excesiva duración del proyecto ha provocado perder un poco el hilo cada vez que se

intentaba retomar el trabajo realizado hasta ese momento. Esta duración ha sido debida a intentar compaginar el trabajo en una empresa y la realización del proyecto final de carrera.

La discontinuidad en el desarrollo del proyecto hacían que un seguimiento del mismo fuera difícil.

Se han encontrado problemas en cuanto a versiones incompatibles de cliente-servidor, ya que conforme pasaba el tiempo el software ajeno utilizado iba siendo actualizado y la invocación de servicios desde el software desarrollado en el proyecto quedaba obsoleto.

El uso de distintos compiladores java y distantas versiones de Lisp también ha sido motivo de numerosos conflictos.

La dependencia debida al uso de software ajeno también ha provocado varios inconvenientes: actualización de versiones de librerías, servidores sin lanzar, cambio de las estrategias de invocación a los servicios desarrrollados externamente, etc.

Problemas en la depuración de DYPAR debido a que el código del mismo no es claro y ha sido retocato por numerosas personas. Esto solía llevar en ocasiones a que al intentar arreglar algo provocaba fallos en otras partes.

Falta de experiencia en ingeniería del software. Lo cual ha llevado a caer en algunos errores, como son, dedicar escaso tiempo al análisis-diseño, desconocimiento exacto de cómo representar cosas en diagramas (UML, DFD, etc).

También JBuilder ha sido motivo de algún que otro quebradero de cabeza, puesto que no siempre enlaza correctamente las librerías que se le indica. Esto provoca excepciones a la hora de ejecutar la aplicación, porque no encuentra determinadas clases.

10


3 Introducción al procesamiento del lenguaje natural

En los últimos diez o quince años se ha vuelto a despertar el interés por el desarrollo de las tecnologías del lenguaje, que muchos de los nuevos profetas no han dudado en calificar como los cimientos de la sociedad de la información del futuro (véase, por ejemplo, Dertouzos 1997).

A medida que las interacciones entre los humanos y las máquinas se hacen más frecuentes, cualquier pequeño paso hacia adelante en la tarea de hacerlas más fluidas será también un paso adelante en la construcción de ese nuevo mundo de la sociedad de la información. Evidentemente, la mejor manera de ganar fluidez y eficacia en estas interacciones es conseguir que éstas sean lo más naturales posibles, y ¿ qué sistema de comunicación resulta más natural para los seres humanos que el lenguaje ? El argumento es de lo más razonable. Si olvidamos por el momento toda una serie de cuestiones directamente relacionadas con la actividad comunicativa de los humanos, así como el papel que juegan ciertos elementos extralingüísticos en la regulación de estas conductas, no cabe duda de que la única manera de acercarnos, aunque sea un poco, al mundo que nos describen algunos autores de ciencia ficción (piénsese en HAL 9000 de Arthur Clarke o en el Pez de Babel de Douglas Adams, por ejemplo) es ser capaces de comunicarnos con entidades artificiales utilizando medios naturales.

3.1 LenguajeUn lenguaje se considera como un conjunto de oraciones, que usualmente es infinito, y se forma con combinaciones de palabras del diccionario. Es necesario que esas combinaciones sean correctas (con respecto a sintaxis) y tengan sentido (con respecto a la semántica).

Podemos distinguir entre dos clases de lenguajes: los lenguajes naturales (inglés, alemán, español, etc.) y lenguajes formales (matemático, lógico, etc.).

3.2 Lenguaje naturalEl Lenguaje Natural (LN) es el medio que utilizamos de manera cotidiana para establecer nuestra comunicación con las demás personas. Este tipo de lenguaje es el que nos permite designar las cosas actuales y razonar acerca de ellas. Fue desarrollado y organizado a partir de la experiencia humana y puede ser utilizado para analizar situaciones altamente complejas y razonar muy sutilmente. La riqueza de sus componentes semánticos da a los lenguajes naturales su gran poder expresivo y su valor como una herramienta para razonamiento sutil. Por otro lado, la sintaxis de un LN puede ser modelada fácilmente por un lenguaje formal, similar a los utilizados en las matemáticas y la lógica. Otra propiedad de los lenguajes naturales es la polisemántica, es decir, la posibilidad de que una palabra en una oración tenga diversos significados.

En un primer resumen, los lenguajes naturales se caracterizan por las siguientes propiedades:

Desarrollados por enriquecimiento progresivo antes de cualquier intento de formación de una teoría.

La importancia de su carácter expresivo debido grandemente a la riqueza del componente semántico (polisemantica).

Dificultad o imposibilidad de una formalización completa.

11


3.3 Procesamiento computacional del lenguaje natural (PLN)3.3.1 IntroducciónÉsta constituye una de las disciplinas de la Inteligencia Artificial (IA) que más intereses y frustruaciones ha traído a lo largo de la historia.

Una meta fundamental de la Inteligencia Artificial, es la manipulación de lenguajes naturales usando herramientas de computación. Los lenguajes de programación juegan un papel importante, ya que forman el enlace necesario entre los lenguajes naturales y su manipulación por una máquina.

El PLN es la utilización de un lenguaje natural para comunicarnos con la computadora, debiendo ésta entender las oraciones que le sean proporcionadas. El uso de estos lenguajes naturales facilita el desarrollo de programas que realicen tareas relacionadas con el lenguaje, o bien, desarrollar modelos que ayuden a comprender los mecanismos humanos asociados con el lenguaje.

El uso del lenguaje natural (LN) en la comunicación hombre-máquina es a la vez una ventaja y un obstáculo con respecto a otros medios de comunicación. Por un lado, es una ventaja, en la medida en que el locutor no tiene que esforzarse para aprender el medio de comunicación, a diferencia de otros medios de interacción, como lo son los lenguajes de comando o las interfaces gráficas (4° Generación). Su uso también es a la vez un obstáculo porque el ordenador tiene una limitada comprensión del lenguaje. Por ejemplo, el usuario no puede hablar sobreentendidos, ni introducir nuevas palabras, ni construir sentidos derivados, tareas que se realizan espontáneamente cuando se utiliza el lenguaje natural.

Son numerosos los problemas a los que se enfrentan los investigadores del procesamiento del lenguaje natural. Por una parte se hace necesario un análisis sintáctico, es decir, de la estructura o forma de las oraciones y de los diferentes elementos que la forman; y por otra parte, se hace necesario un análisis semántico (extraordinariamente mucho más complejo que el sintáctico) o análisis del sentido y significado de las frases o palabras. A veces ni siquiera ambos análisis son suficientes, incluso cuando es una persona quien los realiza, debido al hecho de la existencia de frases o construcciones gramaticalmente correctas que pueden ser interpretadas de varias maneras, con lo que se hace necesario un tercer análisis, el análisis del contexto en el que la frase tiene lugar para poder realizar la interpretación correcta.

3.3.2 Un poco de historiaLos traductores de lenguajes se pueden considerar el comienzo del procesamiento del lenguaje natural (PLN). La primera aplicación consistió en un buscador en un diccionario. Fue desarrollada en el Birkbeck College, Londres, en 1948. La segunda guerra mundial dio un importante impulso a la investigación en este campo de los traductores, ya que se pretendía traducir de forma automática del alemán al inglés. Pero pronto se dieron cuenta de que esta tarea era extremadamente dificil. El lenguaje era mucho más complejo que lo que se había imaginado. Es más, aunque hubiese personas que dominaran el lenguaje nativo, el codificar su conocimiento del lenguaje en un programa de ordenador se observó que era extremadamente dificil.

Fue entonces cuando intervino la lingüistica. No existían teorías lingüísticas apropiadas para afrontar el problema de la traducción. Esto cambió en 1957, con la publicación de “Estructuras sintácticas” por el lingüista estadounidense Noam Chomsky. Chomsky revolucionó la lingüística al introducir la idea de la gramática generativa: las estructuras

12


sintácticas se describen utilizando reglas. Casi todo el trabajo en PLN desde 1957 fue marcado por las ideas de Chomsky.

Bar-Hillel revisó el campo de la traducción automática y concluyó que era imposible sin conocimiento.

El dinero destinado por Estados Unidos a la traducción automática se acabó a mediados de los 60, cuando el comité de la ALPAC (Automatic Language Processing Advisory Committee) produjo un informe en el que se concluía que no había sido posible crear el traductor automático de texto científico, y que tampoco se conseguiría prosperar de forma inmediata. Esto también tuvo un cierto efecto de parada en la mayoría de trabajos relacionados con el PLN.

Pese al frenazo producido debido al informe de la ALPAC, entre 1966 y 1980 hubo algunos desarrollos significativos en el campo de la PLN:

Red de transición aumentada. Que era un potente procesador sintáctico que proveía formas para expresar conocimiento acerca del dominio de una aplicación.

Primeros trabajos que tenían en cuenta la semántica. Por ejemplo, “case grammar” fijó su interés en la información proporcionada por las preposiciones en relación con los verbos y nombres.

Hubo significativos desarrollos con respecto al procesamiento de la semántica. Se introdujo la idea de la red semántica para poder representar el conocimiento.

Desde mediados de la década de los 80, hay una tendencia a poner más información el el diccionario y menos en la gramática. Por ejemplo, en vez de asignar a una regla gramatical la transformación de oraciones activas a pasivas, son muchos los gramáticos modernos que apoyan todo el peso de los pasivos en el diccionario.

En Birnbaum y Selfridge (1981) se presenta una implantación de un sistema basado en gramáticas semánticas.

Los primeros analizadores del lenguaje natural que se crearon realizaban dos estudios claramente diferenciados, el primero de éstos era sintáctico y el segundo semántico. Actualmente se ha establecido una solución más sencilla que combina ambas fases.

3.3.3 ClasificaciónLas investigaciones realizadas se dividieron en: métodos para hacer computables los modelos cognitivos utilizados por los humanos, denominado PLN General; y procedimientos efectivos para entablar procesos de comunicación entre el hombre y la máquina -sin considerar su plausibilidad psicológica-, denominado PLN Aplicado.

3.3.4 Aplicaciones del procesamiento del lenguaje naturalTraducción automática, recuperación de la información, extracción de información y resúmenes, resolución cooperativa de problemas, tutores inteligentes, reconocimiento de voz, etc.

En este proyecto final de carrera trata de afrontar la aplicación con respecto a la recuperación de la información. Un claro ejemplo de esta aplicación sería el siguiente: una persona llega a la computadora y le dice (en LN) qué es lo que busca, ésta lo busca y le devuelve al usuario qué es lo que tiene referente al tema.

13


3.3.5 ProblemasUna de las principales barreras para el empleo generalizado del procesamiento del lenguaje natural es lo difícil que resulta lograr que un sistema PLN tenga un buen desempeño en un nuevo dominio, así como la dosis de capacitación especializada necesaria para lograr los ajustes necesarios.

3.3.5.1 El problema de la Ambigüedad

Uno de los grandes problemas del PLN se produce cuando una expresión en LN posee más de una interpretación, es decir, cuando en el lenguaje de destino se le pueden asignar dos o más expresiones distintas. Este problema de la ambigüedad se presenta en todos los niveles del lenguaje, sin excepción. Ejemplo:

"Juan vio a María, con el telescopio"

"Juan vio a María con el telescopio"

En apariencia este problema es demasiado sencillo, pero en realidad, es uno de los más complicados y que más dificultades ha dado para que el PLN pueda desarrollarse por completo, ya que al presentarse en todos los niveles del lenguaje, se tienen que desarrollar programas (en lenguaje formal) para solucionarlos en cada caso.

El proceso de comprension del lenguaje humano es extremadamente complejo. Supongamos, por ejemplo, que alguien preguntase: “¿ Dónde está Ramón y Cajal ?”. Si esta cuestión la plantease un transeunte escayolado, posiblemente se referirá a dónde está el hospital cuyo nombre es el citado. Si la misma pregunta la hiciera un estudiante en una biblioteca podría referirse a dónde están las publicaciones relacionadas con este personaje. Si por el contrario fuera una persona que coge el taxi la que lo preguntara, se supondría que se refiere a la calle que tiene dicho nombre.

Este ejemplo tan sencillo muestra cómo una frase puede estar sujeta a múltiples interpretaciones dependiendo de la persona y del contexto en el que se lleve a cabo

El empleo de técnicas probabilísticas en la desambiguación ha prevalecido durante años recientes.

3.3.5.2 Posibilidades

A pesar de las dificultades de computar el lenguaje natural, no ha sido óbice para afrontar problemas limitándolos a dominios concretos. Esto permite disminuir drásticamente el número de interpretaciones posibles, haciendo mucho más abordable el desarrollo de las diferentes aproximaciones a la solución del problema.

3.3.6 Ventajas e inconvenientesLas ventajas son obvias. Acercar el modo de comunicación de las máquinas al del ser humano, para que a éste no le sea necesario poseer conocimiento alguno sobre el funcionamiento de dichas máquinas.

Una desventaja importante a considerar es que el usuario nunca podrá saber si la interpretación de una frase ha sido realmente correcta.

14


El lenguaje natural no siempre es la forma más natural de comunicación: hay veces que es más fácil apuntar y hacer “clic” con el ratón para expresar una idea (por ejmplo, “suma esa columna de la hoja de cálculo”).

3.4 Interfaces de lenguaje naturalUn interfaz de lenguaje natural permite al usuario acceder a información, distribuida por determinadas fuentes de información, simplemente expresando las preguntas haciendo uso de su lenguaje natural. Se trata de que la interacción entre el ser humano y el ordenador sea cada vez lo más parecida posible a la interacción entre los seres humanos.

Los interfaces de lenguaje natural tratan de solucionar las diferencias que existen entre la forma de expresarse entre los seres humanos y los ordenadores.

Hoy en día la forma de interactuar con los ordenadores sigue siendo poco flexible y demasiado alejada de la forma en que se comunican los seres humanos, es por ello importante tratar de que dicho alejamiento sea cada vez menor, para que el usuario no tenga que disponer de conocimiento previo alguno, de forma que la comunicación con el ordenador sea lo más natural posible.

Para el procesamiento del lenguaje escrito se usa conocimiento léxico, sintáctico y semántico sobre el lenguaje, además de la información que se necesita sobre el mundo real.Pcesamiento del lenguaje escrito, usando conocimiento léxico, sintáctico y semánti

A finales de los años ochenta se divulgó el uso de los interfaces de lenguaje natural, fundamentalmente para el acceso a grandes bases de datos, aunque también se han utilizado como intérprete de comandos, y en la consulta y ejecución de sistemas expertos sencillos. Estos sistemas tratan de solventar las diferencias que existen entre los dos tipos de lenguajes -el lenguaje natural y el propio de la base de datos (p.ej., SQL)- y de esta manera ofrecer al usuario una herramienta mucho más sencilla y flexible. Se trata de un tipo de interfaz que pretende que el lenguaje de comunicación con la máquina no sea ni tan estricto como los lenguajes artificiales, ni tan ambiguo como los lenguajes naturales. Estas aplicaciones son factibles porque no se trata de crear un intérprete universal del lenguaje humano, sino uno restringido a las expresiones más frecuentes en un dominio concreto; por lo tanto, cada uno de estos interfaces depende de la información contenida en la base de datos que corresponda. Uno de los más conocidos, DYPAR, se divide funcionalmente en dos partes: la primera se encarga de leer y compilar las gramáticas y la segunda utiliza esa gramática para entender las frases de los usuarios y ejecutar las acciones asociadas con cada una de estas frases. DYPAR permite construir gramáticas semánticas, en las que la sintaxis del lenguaje está implícita en los patrones semánticos. El fundamento de su funcionamiento es la equiparación de patrones, en concreto, la comparación de la frase de entrada con los patrones contenidos en las reglas de la gramática.

15


4 Gramáticas

4.1 Tipos de gramáticas4.1.1 Sistemas de comparación de patrones.Algunos de los primeros interfaces de lenguaje natural a bases de datos, utilizaban la técnica de la comparación de patrones para responder a las preguntas que el usuario formulaba. Esta técnica consiste en la definición de una acción muy concreta que se llevará a cabo según se haya reconocido un determinado patrón en la consulta formulada por el usuario.

Su mayor ventaja es la simplicidad. No se necesitan módulos de análisis sintáctico elaborado ni de interpretación, y son fáciles de implementar. También suelen dar respuestas razonables, incluso cuando la pregunta no está dentro del rango de las declaradas como posibles mediante las reglas.

De todos modos, la superficialidad de este método, puede llevar en ocasiones a resultados incorrectos y no deseados.

4.1.2 Sistemas basados en la sintaxisEstos sistemas asignan cada palabra de una frase a una o más categorías sintácticas (nombres, verbos, etc), realizando una descripción estructural de la frase de entrada y su transformación en otra estructura estandarizada para su proceso posterior.

Se transforman las secuencias lineales de palabras en ciertas estructuras que muestran la forma en que las palabras se relacionan entre sí. Se pueden rechazar algunas secuencias de palabras si infringen las reglas del lenguaje sobre la forma en que las palabras pueden combinarse Por ejemplo, un analizador sintáctico de castellano rechazaría la frase " almacén al va chico el."

Este tipo de análisis lo realizan las gramáticas libres del contexto. No contienen información sobre la acción de cada una de las palabras para diferenciarlas dentro de cada categoría sintáctica. De una frase sólo se obtiene su grafo sintáctico.

Fig. 1 Árbol de reconocimiento sintáctico

Será necesario recorrer este grafo otra vez para poder comprender el significado de la frase.

frase

sujeto

verbo

predicado

complementos

16


4.1.3 Gramáticas semánticasCombinan conocimiento sintáctico, semántico y pragmático en un único conjunto de reglas en forma de gramática. El resultado del análisis en una gramática de este tipo es una descripción semántica de la oración, en lugar de una representación sintáctica.

Este tipo de gramáticas consisten en deshacerse de la terminología y metodología especializadas de la lingüística y basar la gramática del sistema directamente en el dominio del problema. Para lograr esto, se sustituyen las categorías sintácticas abstractas por categorías semánticas específicas del dominio. Por ejemplo, la interfaz con un sistema de reservas aéreas contaría con categorías como Ubicación y Volar-a en vez de FN (frase nominal) y FV (frase verbal).

En las gramáticas semánticas, además se incluyen las relaciones entre las palabras y las limitaciones sobre las partes de la frase.

Puede limitarse los sujetos a determinados verbos y los verbos a determinados sujetos. Por ejemplo, las siguientes frases serían desechadas por ser semánticamente anómalas:

“ciento trescientas mil”

“el árbol dice buenos días”

"las ideas verdes incoloras duermen furiosamente”

DYPAR permite construir gramáticas semánticas. La sintáxis del lenguaje está implícita en los patrones semánticos. Se puede construir la gramática de forma que entienda las frases aunque estén mal construidas (falta un artículo, una conectiva, etc), siempre que tengan sentido; por ejemplo: “treinta seis”.

Ventajas de este tipo de gramáticas:

Al completar el análisis, el resultado se puede usar inmediatamente sin el paso adicional de procesamiento que se necesitaba si no se hubiera realizado una interpretación semántica durante el análisis.

Pueden evitarse muchas ambigüedades que surgirían durante un análisis estrictamente sintáctico ya que algunas de estas interpretaciones no tendrían sentido semánticamente y, por lo tanto, no podrían generarse con la gramática semántica. Considerar, por ejemplo, la oración I want to print stuff.x on printer 3" (Quiero imprimir stuff.txt en la impresora 3). Durante el análisis sintáctico, no sería posible decidir si el sintagma proposicional ~~on printer 3" modifica '~want" o "print". Pero al usar una gramática semántica, no existe una noción general de lo que es un sintagma preposicional y no se le asocia ambigüedad alguna.

Pueden ignorarse los aspectos sintácticos que no afecten a la semántica. Por ejemplo, al usar la gramática mostrada anteriormente, la oración, "What is the extension of .Lisp file?" (¿Cuál es la extensión del archivo .Lisp?) se analizaría y se aceptaría como correcta.

Existen, sin embargo, algunas desventajas al usar las gramáticas semánticas:

El número de reglas necesarias puede ser muy grande al perder muchas generalizaciones sintácticas.

Como el número de reglas de la gramática puede ser muy elevado, el proceso de análisis puede ser muy costoso.

17


Son dos las principales desventajas de este tipo de gramáticas. La primera es que son específicas de un dominio en particular. Muy poco del trabajo invertido en la construcción de un sistema puede transferirse a otro dominio que sea distinto.

La segunda es que no se prestan a la adición de generalizaciónes sintácticas. El manejo de construcciones tales como las oraciones pasivas implica incorporar no sólo una nueva regla, sino una regla por cada categoría que se asemeje a un verbo. Lograr lo anterior de manera correcta requiere de mucho tiempo y da lugar a errores. Las gramáticas semánticas pueden servir para lograr que una pequeña aplicación funcione rápidamente en un dominio limitado, no obstante hay que tener presente que su capacidad de generalización no es buena.

En este enfoque de las gramáticas semánticas las categorías gramaticales son sintácticas y semánticas. Existe también la posibilidad de combinar las ventajas de las gramáticas semánticas, las transformaciones sintácticas, y la equiparación de patrones en un mismo sistema. Este esquema, denominado multiestratégico, se ha implementado en el sistema DYPAR.

4.1.4 Integración del discursoEl significado de una frase individual puede depender de las frases precedentes y puede influenciar el significado de las frases posteriores. Por ejemplo, la palabra "it" en "John wanted it" (John lo quiso) depende del contexto del discurso, mientras que la palabra "John" puede influenciar el significado de frases posteriores (como "He always had." [Él siempre tuvo]).

4.1.5 Análisis de la pragmáticaLa estructura que representa qué se ha dicho se reinterpreta para determinar su significado actual. Por ejemplo, la frase "Do you know what time is it?" (¿sabe usted qué hora es?) debería interpretarse como una petición de la hora.

Los límites entre estas cinco fases con frecuencia son muy difusos.

4.2 Gramáticas y analizadoresLa forma más usual de representar las gramáticas es mediante un conjunto de reglas de producción.

El proceso de análisis sintáctico toma reglas de la gramática y las compara con la oración de entrada. Cada regla que se empareje añade algo a la estructura de la oración que se está construyendo

Para analizar una frase es necesario encontrar una forma de generar a partir del símbolo inicial. Esto puede hacerse de dos formas:

Análisis descendente: Se comienza por el simbolo inicial y se aplican las reglas de la gramática hacia delante hasta que los simbolos terminales del árbol se correspondan con los componentes de la frase analizada.

18


Análisis ascendente: Se comienza con la frase a analizar y se aplican las reglas de la gramática hacia atrás hasta producir un único árbol cuyos terminales sean las palabras de la oración y cuyo nodo raíz sea el símbolo inicial.

4.3 Elementos de una gramáticaLas gramáticas de DYPAR son una combinación de reglas, patrones y operadores sobre los patrones.

4.3.1 Terminales y no terminalesUn terminal es aquél que se puede equiparar directamente con la entrada del usuario, se puede considerar como un elemento atómico.

Un no terminal no es un elemento atómico, y por lo tanto se puede descomponer en un nivel inferior. Un no terminal es una llamada a una regla de reescritura. Por convenio, los no terminales se escriben entre < >.

Por ejemplo, <preposicion> es un no terminal que contiene los terminales (a, ante, bajo, cabe, con, contra....)

4.3.2 PatronesEs una lista de terminales y/o no terminales.

Por ejemplo, <articulo> coche es de color <color>

Donde los no terminales <articulo> y <color> estarán definidos en alguna otra parte como (el, la, los, las) (azul, rojo, amarillo, verde...).

4.3.3 Operadores utilizados en DYPARDYPAR permite el uso de multitud de operadores para controlar el comportamiento del equiparador (matcher), de forma que no sea una comparación rígida, sino que se pueda contemplar un conjunto más amplio de expresiones.

Sólo se explicarán los operadores más importantes e interesantes utilizados en las gramáticas desarrrolladas. Para una información más completa acudir a los manuales existentes.

4.3.3.1 Operadores para indicar opcionalidad

DYPAR contempla operadores para indicar opcionalidad. Por ejemplo, puede utilizarse un único patrón para reconocer las frases “No me gusta” y “me gusta”:

<mi_frase> -> ?no me gusta

? Al encontrarse DYPAR con este operador, tiene en cuenta dos casos. En el primero considera que el patrón anexo indicado se equipara con lo introducido por el usuario, es decir, se consume parte de la entrada del usuario. Y en la segunda posibilidad es como si se omitiera el patrón indicado y se intentara seguir la equiparación con la frase del usuario, es decir, no se consume nada de la entrada del usuario. Este comportamiento puede verse como una ramificación considerando ambos casos, lo cual hace que aumente el tiempo necesario para el procesamiento.

19


&o Si su argumento existe, continúa la equiparación. Fuerza el consumo del elemento opcional indicado, siempre que sea posible. A diferencia del operador ? con este operador no existe ramificación, disminuyendo el tiempo de procesamiento. Pero el uso de este operador puede ser peligroso si no se utiliza con cuidado, ya que puede darse un consumo prematuro de parte de la entrada del usuario y esto haría irreconocible dicha frase.

4.3.3.2 Operadores para equiparación de diferentes patrones

DYPAR también tiene operadores con los que manejar diferentes patrones en una misma regla. Por ejemplo,

<mayor> -> ( mayor !! %rabrack !! ; > no menor ni igual)

(Nota: el ; indica que todo lo que viene a continuación es un comentario)

La anterior regla reconoce de la entrada del usuario 3 casos:

“mayor”, “>” y “no menor ni igual”.

El uso de los siguientes operadores tiene cierta analogía con los anteriores (? y &o)

! ó |

Prueba con todos los argumentos. Es como si hubiese una ramificación múltiple. Una por cada argumento. Evidentemente esta forma de actuar hace que el procesamiento lleve mucho más tiempo.

!!

Si una rama tiene éxito, no trata de equiparar por otras. Es decir, el uso de este operador hace que DYPAR pare tras conseguir equiparar uno de sus argumentos. Pero existe el peligro de esar escogiendo una rama que aparentemente es la correcta pero que posteriormente se observará que no era la acertada. En este caso ya no hay remedio y la frase introducida por el usuario no será reconocida.

4.3.3.3 Asignación y referencia a variables

:=

Asigna el valor de una equiparación con éxito a una variable que después se vaya a utilizar. Las variables, por convenio, son símbolos precedidos por el símbolo de admiración !

Por ejemplo: (? (un !! una) (!elemento := $))

En la propia regla podrá accederse al valor del elemento mediante !elemento. Por lo tanto, si el usuario escribe algo del estilo “una bicicleta” !elemento valdrá “bicicleta”

&i

Sintaxis: (&i <valor> <patrón>)

(&i <invocación de una función> <patrón>)

Si se reconoce <patrón> se devuelve el valor indicado en <valor> o se invoca a la función de <invocación de una función>

20


4.3.3.4 Comodines

Existen varios comodines. Los más utilizados son los siguientes:

$

Equipara cualquier palabra, número, etc.

$n

Equipara cualquier número.

$w

Equipara cualquier palabra.

$r

Equipara cualquier cosa hasta el final de la entrada.

4.3.3.5 Invocación de funciones

%f

Sintaxis: (%f <nombre_función> <arg1> ... <argn>)

Éste podría considerarse como uno de los operadores más importantes, puesto que permite invocar a una función o método lisp desde dentro de un patrón. Es utilizada para realizar determinadas acciones al detectar patrones concretos en la entrada del usuario.

Ha de usarse conjuntamente con el operador &i.

Ejemplo:

(&i (%f anafora_elipsis) one !! ones !! any)

Con el anterior ejemplo se invocará a la función “anafora_elipsis” si se detecta alguno de los terminales indicados.

4.3.4 ReglasExisten cuatro tipos de reglas que pueden ser utilizadas en las gramáticas desarrolladas con DYPAR:

reglas de reescritura (->)

Asocia no terminales entre sí, o no terminales con terminales.

La parte izquierda de la regla debe ser siempre un no terminal.

Por ejemplo,

La siguiente regla de reescritura sólo contiene terminales:

<articulo> -> ( the !! a !! an )

La siguiente regla utiliza terminales y <no terminales>:

<hay> -> ( there ?will <be> !! ?will <be> there

21


)

Una regla de reescritura más compleja que hace uso de terminales, no terminales y diversos operadores de DYPAR:

<frase> -> ( (!tmp := (&i (%f query !query !op_bool) (!query := <subfrase>) (!op_bool := (&i and)) ; por defecto el operador "and" (&o (!op_bool := <conjuncion>)) <frase>)) !! (!tmp := (&i (%f query1 !query1 !op_bool) (!op_bool := (&i and)) ; por defecto el operador "and" (&o (!op_bool := <conjuncion>)) ; por si anafora-elipsis (!query1 := <subfrase>))) )

regla de alto nivel (=>)

Contienen una secuencia de patrones y las instrucciones para realizar una acción cuando la equiparación de dichos patrones ha resultado con éxito.

La parte izquierda de la regla es el patrón y la parte derecha la acción.

El siguiente ejemplo ejecutará la función “con_solucion” si se ha reconocido que la entrada del usuario se corresponde con la definición dada en el patrón “mi <frase>”

(mi <frase>) => (progn (con_solucion))

regla de tranformación (::>)

Tranforma ciertas frases en otras con el fin de simplificar la construcción de las gramáticas.

La parte izquierda de la regla es un patrón y la parte derecha es una expresión lisp que reconstruye la frase (cons, append, etc). La frase reconstruida será entrada de una regla de alto nivel o de reescritura.

DYPAR intentará transformar una frase en otra después de haber probado las reglas de alto nivel y todas han fallado.

Ejemplo para el tratamiento del genitivo sajón:

Yes, John’s car is big Yes, car of John is big((!principio := (&u ($) <apostrofe_s>)) (!poseedor := ($)) <apostrofe_s> (!cosa_poseida := ($)) (!final := $r)) ::> (progn (append !principio (append !cosa_poseida (append '(of) (append !poseedor !final)))))

regla de recuperación (+>)

Se utilizan para devolver información aclaratoria al usuario, en el caso de que no se haya encontrado un análisis correcto para toda la frase de entrada, pero sí se ha entendido parte de la frase.

Se prueban en el orden en que han sido escritas.

22


4.4 Estrategias o normas de construcción de gramáticas4.4.1 Análisis previoSe ha intentado realizar un análisis descendente (top-down) a la hora de diseñar el código de las gramáticas. Esta estrategia es análoga a la utilizada normalmente en programación, es decir, pensar primero en alto nivel cómo se estructuran las frases, y poco a poco ir bajando a un nivel más detallado, especificando cómo se compone cada parte de la frase.

4.4.2 DistribuciónLa adecuada distribución del conjunto de gramáticas en ficheros es también un punto importante a tener en cuenta. De la misma forma que a la hora de programar, conviene separar cada gramática de forma lógica.

En el proyectos se ha creído conveniente realizar una separación entre las gramáticas necesarias para interpretar el dominio concreto (en este caso metadatos de mapas) y las gramáticas propias del lenguaje (inglés, español, etc.). De esta forma el conjunto de gramáticas desarrolladas para el lenguaje son reutilizables para otros dominios.

4.4.3 Complejidad vs. rapidez vs. potenciaComo suele suceder amenudo en informática, hay una serie de características incompatibles entre sí.

Una gramática excesivamente compleja acarreará menor rapidez a la hora de interpretar frases, ya que el número de combinaciones posibles dentro de la gramática aumenta, y por lo tanto el intérprete ha de observar más casos.

Sin embargo, una gramática demasiado simple hará que el reconocimiento sea pobre, es decir, tendremos una gramática poco potente pero muy rápida.

En el medio, como siempre, está la virtud.

4.4.4 Pérdida y confusión del flujo de controlEn el momento en que las gramáticas desarrolladas se unen para realizar una interpretación conjunta, suelen producirse interpretaciones incorrectas. Además, la depuración para solucionar estos conflictos se convierte en más larga y tediosa conforme la gramática se va ampliando. Por ello, es muy importante que la gramática esté lo mejor estructurada posible.

4.4.5 RecursividadSólo se permite recursividad por la derecha en las reglas de reescritura.

La siguiente regla sería incorrecta:

<frase> -> ( <frase> <subfrase> !! <subfrase>)

Debería ser de las siguiente forma:

23


<frase> -> ( <subfrase> <frase> !! <subfrase>)

4.4.6 DepuraciónNo cabe duda de la importancia de poseer una buena herramienta para depurar una gramática. En el proceso de reconocimiento se observará que determinadas frases no son reconocidas apropiadamente. Será entonces necesario seguir la pista de las reglas disparadas, es decir, depurar la gramática.

4.5 ExtensibilidadOtro aspecto importante que se ha tenido en consideración a la hora de codificar las gramáticas, es la de ofrecer un mecanismo sencillo para incorporar gramáticas que añadan información sobre otro dominio. Esto posibilitaría un enriquecimiento paulativo del conocimiento de DYPAR. Para ello, como se ha mencionado previamente, es importante la separación ya llevada a cabo entre la gramática que define la base del lenguaje y la gramática para cada uno de los dominios.

4.6 OptimizaciónDYPAR permite introducir elementos de optimización dentro de la gramática con el fin de reducir el número de combinaciones posibles a la hora de intentar interpretar la entrada del usuario. Estos elementos de optimización consisten en el uso de determinados operadores más eficientes. En la gramática desarrollada básicamente se han empleado dos operadores para tal fin.

Sin embargo, la optimización ha de hacerse con sumo cuidado, puesto que un empleo inadecuado de un operador podrá incapacitar el reconocimiento de determinadas frases.

&o es más eficiente que ?

El patrón (?very very much) reconocerá apropiadamente las entradas “very very much” y “very much”.

En cambio, el patrón ((&o very) very much) sí reconocería “very very much” pero no “very much”. Esto es así porque con el operador &o se está indicando que si se encuentra en la entrada con “very”, que lo consuma y siga procesando el resto de la frase.

!! es más eficiente que |

El patrón (a (b !! (* $)) d) fallará con la entrada “a b c d” porque “b” se encuentra primero y por lo tanto se olvida de (* $). Es decir, al poder realizar la correspondencia con la “b”, la consume, y sigue con el resto de la frase, sin tener en cuenta (* $)

En cambio, con (a (b | (* $)) d) sí reconocerá “a b c d” porque intentará las 2 posibilidades.

DYPAR posee un módulo optimizador capaz de hacer una conversión a los operadores eficientes, siempre que sea plausible. Sin embargo, este módulo no es aplicable si se hace uso de sinónimos, como es el caso de la nueva versión modificada de DYPAR.

24


Otro aspecto importante a la hora de optimizar una gramática es reduciendo, en la medida de lo posible, el número de niveles. Esto puede intuirse observando el siguiente árbol, que da una idea del número máximo de combinaciones que podría tener el reconocimiento de una frase para una gramática dada:

Fig. 2 Árbol de reconocimiento de una frase

Los nodos del final correspondería a terminales, mientras que los nodos intermedios corresponderían a no terminales.

DYPAR realiza una poda del árbol conforme va equiparando la gramática con la entrada del usuario. Realmente efectúa una búsqueda en profundidad.

El orden de los patrones dentro de una regla también ayuda a encontrar una solución con mayor o menor celeridad. Si se posee algún tipo de información sobre la probabilidad de que aparezca un patrón sobre otro, entonces el de mayor probabilidad debería situarse antes al escribir la regla. De este modo, DYPAR, en término medio, encontrará las solución en menor tiempo.

4.7 Obtención de resultados intermediosUn aspecto fundamental en el reconocimiento de las frases es ir recogiendo la información que se va reconociendo, es decir, conforme se comprende la frase del usuario se obtiene los datos para constuir la sentencia SQL. Para ello, DYPAR permite la invocación de funciones y la asignación de variables desde la propia gramática

4.7.1 Asignación de variablesCon la asignación de variables se consigue recuperar determinadas palabras de la frase introducida por un usuario. En este caso se irá recogiendo la información del SELECT y del

25


WHERE conforme vayan detectándose los patrones de interés. Dichas variables servirán de argumentos en la invocación que se hará de la función que se hará en el propio patrón.

4.7.2 Devolución de valoresSi lo que se desea es simplemente devolver un valor determinado tras reconocer un patrón, esto se consigue utilizando el operador &i.

Por defecto DYPAR devuelve los mismos terminales encontrados en cada regla de reescritura. Por ejemplo, en:

<uno> -> (one !! a !! an)

cuando se reconozca, devolverá simplemente el terminal reconocido.

4.7.3 Invocación de funcionesLa invocación a funciones se consigue mediante el operador %f.

Por ejemplo, en la gramática desarrollada se encuentra la siguiente regla:

<frase> -> ( (!tmp := (&i (%f query !query !op_bool) (!query := <subfrase>) (!op_bool := (&i and)) ; por defecto el operador "and" (&o (!op_bool := <conjuncion>)) <frase>)) )

Observar que se recoge en la variable !query la subconsulta que se ha reconocido, y en !op_bool el operador booleano correspondiente. Esta información forman los argumentos de la función “query”. Esta función irá almacenando en el lugar apropiado la información que recibe.

El imprescindible que la invocación de las funciones encargadas de ir recogiendo la información, estén en el nivel superior. Esto es así porque sólo interesa ir almacenando información si se está lo suficientemente seguro a lo que corresponde. Y esta seguridad se obtiene al inicio del árbol, en el nivel superior, cuando se haya confirmado haber encontrado una solución. En este caso ese nivel superior coincide con <subfrase>, es decir, se ha reconocido una subfrase.

Fijarse, que el uso de la variable !tmp sólo tiene un fin, que es recoger lo devuelto por &i, ya que si no, se produce un error.

4.8 Diagrama de clases origen de la gramáticaComo se observará en este apartado, la gramática específica para el dominio de los metadatos ha sido elaborada en base a los siguientes diagramas de clase. Estos diagramas de clase no han sido desarrollados en este proyecto, simplemente se hace uso de ellos. Sólo se han escogido aquellos atributos considerados útiles según el tipo de frases que se quiere reconocer.

Los nombre de los atributos de la sentencia SQL obtenida en la gramática se corresponde con los nombres de los atributos dentro de las clases.

26


Fig. 3 Paquetes que componen Isigis

metadataidentification

dataset

distribution

entityAttribute

dataQuality

spatial

referenceSystem

aggregations

Dataset(from dataset)

Contact(from dataset)

DistributionInformationresourceDescription : Stringliability : Stringfees : StringturnAround : StringtechnicalPrerrequisites : String

1

+distributor

1Sourcesource_idfileType : Stringremark : StringURL : StringaccessInstructions : StringoffLineMedia : StringrecordingFormat : StringrecordingUnits : StringrecordingDensity

1

0..*

1

0..*

27


Fig. 4 Diagrama de clases para el paquete “distribution”

Fig. 5 Diagrama de clases para el paquete “metadata”

MetaDataExtensiononlineLinkage : StringprofileName : String

Contact

person : Stringorganisation : Stringposition : StringaddressType : Stringaddress : Stringcity : Stringstate : Stringpostal : Stringcontry : StringvoicePhone : StringTDDPhone : Stringfax : Stringemail : Stringhours : Stringinstructions : StringURL : String

(from dataset)

MetadataSecurityInformationsecurityClassificationSystemsecurityClassificationsecurityHandlingDescription

MetadataReferencecreation : DatelastReview : DatefutureReview : DatestandardName : StringstandardVersion : StringtimeConvention : TimeConventionTypelanguage : StringaccessConstraintsuseConstraintsfileIdentifier : StringparentIdentifier : Stringstatus : CharacterdropDate : DatehierarchyLevelCode : String

0..*

+extension

0..*

1

+contact

1

0..10..1

Dataset

Leftoverstandard : Stringtext : StringtextType : Stringmetadata : String

DataQualityInformation

logicalConsistencyReportcompletenessReporthorizontalAccuracyReportverticalAccuracyReportattributeAccuracyReportcloudCover : Short

(from dataQuality)

PrivateMetadatasource : Stringprovider : StringobtainDate : StringobtainProcess : StringupdateProcess : StringpublishLevel : Stringcost : Stringremark : String

IdentificationInformation(from identi fication)

EntityAndAttributeInformation(from enti tyAttribute)

DistributionInformation

resourceDescription : Stringliability : Stringfees : StringturnAround : StringtechnicalPrerrequisites : String

(from distribution)

SpatialDomain

scale : String(from spatial)

MetadataReference(from metadata)

0..*

+leftover

0..*+theDataSet

0..10..1

1

1

1 +private metadata

1

1..1+identificationInformation

1..1

0..1

+entityAndAttributeInformation

0..1

0..*0..*

1..11..1

+spatialCoverage

atributo metadata para guardar los metadatos generados en la BD

28


Fig. 6 Diagrama de clases para el paquete “dataQuality”

La siguiente figura es el diagrama de clases del más información se ha obtenido.

29


Fig. 7 Diagrama de clases para el paquete “identification”

Dataset(from dataset)

en ISO hay un topicCategory aparte de los key words

Themethesaurus : Stringkey word : StringStratum

thesauruskey word

Temporalthesaurus : Stringkey word : String

Placethesauruskey word

Statusprogress : ProgressEnummaintenanceAndUpdateFrequency : String

Descriptionabstract : Textpurpose : TextadditionalInf ormation : Text

Citation

title : StringpublicationDate : Dateedition : StringseriesName : StringissueIdentif ication : StringpublicationPlace : Stringpublisher : StringotherCitationDetails : StringgeospatialDataPresentationForm : StringonlineLinkage : Stringoriginator : Stringidentif ieridentif ierTy peISBNISSN

(from dataset)

0..1

+largeWorkCitation

0..1

+subSetOf

Key wordstopicCategory

1

1..*

1

1..*

0..*0..*

0..*0..*

0..*0..*

Languagethesaurus : Stringkey word : String

TimePeriodOf ContentstartDate : DateendDate : DatecurrentnessRef erence

Security Inf ormationclassif icationSy stemclassif icationhandlingDescription

Identif icationInf ormationaccessConstraint : TextuseConstraint : TextdatasetCredit : Stringenv ironment : String

1..11..1

+status

1..11..1

+description

1..11..1+citation

1

0..*

1

0..*

11

0..10..1

codecBase64

encode(by te[]) : Stringdecode(String) : by te []

BrowseGraphicf ileName : Stringf ileDescription : Stringf ileTy pe : Stringgraphic

0..*

1

0..*

1

30


4.9 Estructura gramatical utilizadaLa gramática se ha dividido básicamente en dos partes: una compuesta por los elementos básicos del lenguaje, e independiente del dominio específico del resto de la gramática. La otra parte de la gramática es particular del dominio que se desea implementar, y que hará uso de la gramática base.

El propósito de esta división es debido para reaprovechar la gramática base en otras gramáticas definidas para otros dominios.

4.9.1 Gramática base del lenguaje

Fig. 8 Esquema de la distribución de la gramática base

base.gra contiene la base de un lenguaje. Contiene reglas para reconocer conjunciones, preposiciones, pronombres, fechas, horas, verbos, anáfora y elipsis, etc.

frase.gra es la parte de la gramática base que define cómo debe ser la estructura de una frase. Se ha considerado que una frase está compuesta por la combinación de 5 partes repetidas un número indeterminado de veces:

1. inicio : recoge la parte de una frase que se suele utilizar como introducción y, en general, en el inicio de una frase.

Ejemplos: do you know, can you show me, where can I find, etc.

2. preguntas : esta parte es dependiente del dominio. Reconoce subfrases en las que se solicita información sobre algo. Coincidirá con el SELECT de una sentencia SQL.

Ejemplos: who published the maps, how current are the maps, which supplier, if there are any theme, how many titles, etc.

3. información: detecta los elementos de información que un usuario introduce en su pregunta. Correspondería con el WHERE de una sentencia SQL.

Ejemplos: which publication date is 1/2/02, with the publisher equal to Edelvives, different of Economy, which title is "mi titulo1" or "tu titulo2, of politica from 1/2/03 to 4/5/06, etc.

4. supérfluo: existen elementos de una frase que no aportan nada nuevo y que empleados en el lenguaje por educación, cordialidad, etc.

Ejemplos: please, thank you

base.gra ney.grafrase.gra

isa.gratipo.graordinales.gra cardinales.gra fecha.gra

31


5. anáfora/elipsis: en ocasiones el usuario puede hacer referencia a la pregunta anterior. Los elementos propios de esa referencia se intentan detectar.

Ejemplos: of them, of previous results, ones, of this output, etc.

ney.gra es un poco la personalidad para interactuar con el usuario (al estilo de HAL-9000 ;-)). Por ejemplo, se intenta dar una contestación cuando el usuario saluda, insulta, pide ayuda, etc. Esta gramática es muy simple, se definió por curiosidad, puesto que realmente constituye la parte más compleja y conllevaría la realización de otro proyecto.

ordinales.gra reconoce los números ordinales del inglés desde 1 a 999.999.999.999.

cardinales.gra esta gramática interpreta los números ordinales escritos con letra, o dictados que estén entre 1 y 999.999.999.999. Por ejemplo, sabría interpretar “three million four hundred fifty-six thousand and seven”.

fecha.gra es la gramática encargada de reconocer una fecha en los distintos formatos. Ejemplos: 10/28/93, the 11th of February 1998, February the eleventh nineteen ninety-eight, etc.

4.9.2 Gramática para el dominio de los metadatos de mapas

Fig. 9 Esquema de la distribución de la gramática particular del dominio

Existe un fichero de gramática por cada clase del diagrama de clases (ver diagramas de clase en el apartado anterior). En cada uno de estos ficheros se especifica qué atributos contiene la clase y con qué nombres pueden ser designados por el usuario. Asímismo, también se incorpora el tipo de dato que posee cada atributo.

La incorporación del tipo de dato del atributo tiene como fin el reconocimiento, en la frase introducida por el usuario, del valor del mismo en el caso en el que se conozca de antemano el tipo. Dependiendo del tipo, el no terminal a aplicar es distinto. Esto se hace así para evitar ambigüedades entre tipos con elementos comunes entre sí, por ejemplo "2001" se puede interpretar como "fecha" y como "número". En cierto modo hace de informador contextual.

dataset.gra

contact.gra description.gra distributionInformation.gra

geographicalCoordinates.gra identificationInformation.gra metadataReference.gra

status.gra timePeriodOfContent.gra varios.gra

citation.gra

keywords.gra

32


Hay tantos tipos porque ha de detectarse el valor introducido por el usuario, por ejemplo, un número de teléfono se puede introducir de muchas formas: 976-321-666 ó 976 321 666...

Otra causa para introducir el tipo es el no perder tiempo intentando equiparar el valor introducido con todo lo posible (fecha, número, cadena, lugar, tema....). Si se conoce de antemano el tipo simplemente hay que reconocer un valor perteneciente al dominio de ese tipo.

Los fichero que componen esta parte de la gramática son los siguientes:

dataset.gra esta gramática hace de raíz del resto de clases. Define cómo se constituye una pregunta o información en el dominio de los metadatos de mapas. Por ejemplo, se explicita que una pregunta puede referirse a una pregunta respecto a las clases citation, contact, description o varios.

Las siguientes gramáticas definen las formas de expresión que un usuario puede utilizar para referirse a los atributos propios de cada clase.

citation.gra

Ejemplos: para referirse al atributo “originator” un usuario podría expresarlo de distintas formas: originator, name of the originator, supplier, organization that developed, etc

contact.gra

Ejemplos: para hacer referencia a información de contacto: from whom can I obtain. Para referirse el código postal (atributo “postal”): postal code, zip code, postcode

description.gra

Ejemplos: para hacer referencia al propósito de los metadatos (atributo “purpose”): purpose, why have been created, why were the maps created, etc

distributionInformation.gra

Ejemplos: para hacer referencia a información sobre responsabilidad (atributo liability): liability, legal disclamers, must supossed to read, etc

geographicalCoordinates.gra

Ejemplos: para hacer referencia a información de coordenadas geográficas: bounding coordinates, geographical coordinates, geographic area, limits of coverage, etc.

identificationInformation.gra

Ejemplos: para hacer referencia a información de contacto: from whom can I obtain. Para referirse el código postal (atributo “postal”): postal code, zip code, postcode

metadataReference.gra

Ejemplos: para hacer referencia a información sobre la persona de contacto: contact, contact person, etc

status.gra

Ejemplos: para hacer referencia a información sobre la frecuencia de actualización de los datos: update frecuency, maintenance and update frequency, updated and maintened.

timePeriodOfContent.gra

33


Ejemplos: para hacer referencia al periodo de tiempo: with the time period from 1/02/98 to 3/03/99, with the range of dates varying from 20/03/1972 to 29/04/1984, etc.

keywords.gra

Ejemplos: para hacer referencia al lugar (atributo “place”): place, geographic area covered,geographic area does map cover, etc.

varios.gra

Éste fichero define una gramática especial que recoge la estructura general en que se formulan preguntan o se ofrece información, sobre los atributos de todas las clases. Esto es así, porque la forma de construir una frase, con casi todos los atributos, es práticamente idéntica.

4.10 Historia del proceso de construcción de la gramáticaAntes de pensar en cómo tendría que ser la gramática, se redactaron y consiguieron todos los ejemplos posibles de frases tipo que podría formular un usuario, y, por lo tanto, a las que tendría que enfrentarse la gramática. Lo ideal hubiese sido haber conseguido un corpus amplio, es decir, un conjunto de muchos ejemplos reales de las preguntas que un usuario con interés en el dominio de los metadatos suele formular. Se pudo obtener un pequeño corpus que sirvió como base para hacerse una idea de las preguntas tipo.

La estructura final de la gramática se consiguió gracias al refinamiento de un prototipo de gramática inicial, el cual se fue incrementando en complejidad hasta obtener la estructura final. Básicamente existían dos posibilidades para desarrollar la gramática:

una basada en las estructuras lingüísticas definidas por el lenguaje, es decir, habría que definir sintácticamente las frases. Por lo tanto una frase estaría formada por un sujeto y un predicado, éstos se dividirían en otros elementos lingüísticos, y así sucesivamente. Esta es la forma que se les enseña a los niños en el colegio, y se correspondería con una forma teórica de afrontar la gramática.

la otra posibilidad es más propia de DYPAR, consiste en intentar deducir diversos patrones de la frase, sin tener en cuenta formalmente la estructura sintáctica de la misma. En cierto modo, esta forma de interpretar una frase es, salvando las distancias, la manera en que aprende un niño. Éste desconoce la sintaxis formal de una frase, pero sabe reconocer la información que contiene y si está más o menos bien construida desde el punto de vista sintáctico. Ésta es una forma empírica de afrontar la gramática. Se trata de una gramática semántica.

En este proyecto se optó por esta última posibilidad, puesto que parecía factible conseguir un buen intérprete de frases sin necesidad de utilizar la otra posibilidad, que parecía más compleja de implementar y de manejar. Además, para el problema al que se debía afrontar, la segunda forma de construir la gramática parecía suficiente.

Tras esta decisión, se pasó a observar el corpus disponible y a intentar detectar patrones dentro de las frases. Básicamente, siempre se podía distinguir 3 partes principales:

1. una parte de la frase solía consistir en un cierto formalismo para solicitar información. Ésta parte normalmente iba al inicio de la frase.

Ejemplos de esto serían los siguientes:

34


“could you give me…” “show me…”

“I want…” “select…”etc

2. en otra parte se podía distinguir qué es lo que el usuario solicitaba, es decir, qué le interesaba de toda la información disponible. Esta parte se correspondía muy claramente con el contenido del SELECT de una consulta SQL.

Ejemplos de esto podrían ser:

“…the electronic mail, the address and the fax of contact…” “…the originator, the publisher and the title of all maps…”

3. la tercera parte importante que se observaba en una frase era cuando el usuario daba información para filtrar (seleccionar) los datos que realmente le interesaba. Esto se adecuaba claramente al WHERE de una consulta SQL. En esta ocasión era habitual que esta parte de la frase se situara al final de la misma.

Unos cuantos ejemplos posibles serían:

“...which title is "hola coco" or "adios coco"" “…of Aragon which supplier is DGA” “…about economy of Aragon with coordinates north = 3 and south = 4 and east = 5 and west = 6”etc.

También se utilizaba a veces algunas partes de las frases que no aportaban nada, y que son consideradas en la gramática como supérfluas. Ejemplo de este tipo serían “please”, “thank you”, etc.

Debido al tratamiento de anáfora y elipsis también se tuvo que detectar este recurso lingüístico. Ejemplos de esto son “of them”, “of previous results”, etc.

Tal y como se definían las gramáticas en DYPAR, se observaba una carencia muy importante de dinanismo. Es decir, la ampliación de la gramática pasaba por la modificación directa de los ficheros de gramática implicados, lo cual conllevaba a disponer una gramática estática. El gran inconveniente de definir de este modo la gramática es que, además de definir la estructura gramatical, había que indicar los sinónimos y palabras derivadas. Esto llevaba a que la gramática se convertía prácticamente en un diccionario, además de indicar la estructura gramatical. Un ejemplo claro de esto se puede observar en la gramátcia definida por el proyecto del Centro Nacional de Inteligencia Artificial (CNIA) de Rank Xerox Espala S.A. y el Banco Español de Crédito (BANESTO). Dentro de su gramática se apreciaban reglas del estilo:

<da> -> (dime ! da ! dame ! haz ! hazme ! construye ! contruyeme ! confecciona ! confeccioname ! elabora ! elaborame ! visualiza ! visualizame ! pon ! ponme ! saca ! sacame)

Este uso engrandecía innecesariamente la gramática y hacía el proceso de construcción de la misma muy tedioso. La solución parecía obvia, se precisaba de la introducción de un diccionario.

Wordnet era el diccionario apropiado para tal fin. Éste era de libre distribución (sólo la versión en inglés. La versión en otros idiomas como el español es de pago y todavía no está completada) y bastante completo (cerca de 95.600 palabras). Además de contener palabras,

35


posee relaciones entre las mismas: sinónimos, antónimos, hipónimos, hiperónimos y merónimos (MERONIMIA es la relación semántica entre una unidad léxica que denota una parte y lo que denota el correspondiente todo, por ejemplo, la relación pedal-bicicleta).

El siguiente paso consistía en utilizar dicho diccionario. George A. Miller desarrolló unas funciones en Lisp que servían de interfaz para el uso de wordnet desde lisp. Con estas funciones es posible recuperar los sinónimos de una palabra dada, y esto es precisamente lo que se buscaba. Si bien, se tuvo que adaptar para algún tratamiento específico.

La siguiente tarea consistía en habilitar DYPAR para el uso de sinónimos. Para ello fue necesario modificar apropiadamente el código fuente de DYPAR. Sin embargo, el tratamiento de sinónimos por DYPAR hacía extremadamente lento el procesamiento de una frase, por lo que se introdujo el concepto de palabras atípicas. La idea consistía en buscar los sinónimos sólo para aquellas palabras que DYPAR no había conseguido reconocer en un procesamiento previo. De esta forma se evitaba tener que considerar los sinónimos para todas las palabras de la frase (o de la gramática, según la estrategia). Esta idea llevó a su vez al uso de iteraciones a la hora de procesar una frase.

En cada iteración se comenzaba a procesar de nuevo la frase, pero teniendo en cuenta las palabras no reconocidas en la iteración anterior. Si la palabra en cuestión era la primera vez que no se reconocía en el procesamiento, entonces se apuntaba para que se tuvieran en cuenta sus sinónimos en la siguiente iteración. Si en la nueva iteración, aun considerando sus sinónimos, sigue sin reconocerse, entonces se elimina de la frase del usuario y se intenta una nueva iteración. Este proceso concluirá cuando la frase se reconozca, no se reconozca o se sobrepase el límite máximo de iteraciones.

Se puede observar en el gráfico simplificado de la estructura gramatical cómo se es capaz de reconocer palabras cuyo atributo ha sido omitido por el usuario. Esto fue posible con la introducción de las asociaciones ISA (IS-A, es decir, ES-UN, en español). Con ello se intentaba reflejar qué eran determinados nombres propios. Por ejemplo, Aragón ES-UN lugar, Economía ES-UN tema, etc. Como era de esperar, esta información era muy pobre en wordnet, por lo que se optó por la consulta de otras fuentes de información más completas. Dependiendo del tipo de nombre propio se consultan distintas fuentes:

Para lugares

Se hace uso de un servidor en internet que es capaz de localizar geográficamente lugares. Utilizando un protocolo adecuado se realizan consultas con dicho servidor para averiguar si una palabra o conjunto de palabras forman el nombre de un lugar.

Para temas

En este caso se utiliza un servidor de thesaurus desarrollado en otro proyecto final de carrera para poder averiguar si una palabra o conjunto de ellas forman un tema.

Huvo que construir un servidor de temas que se comunicara con el servidor de dypar y que consultara el servidor de thesaurus ya construido en otro proyecto.

Para nombres propios de personas

Se consulta una base de datos remota.

Para nombres propios de organizaciones


Para nombres propios de editores

36



Evidentemente, estas comprobaciones extras consumen tiempo, por lo que se utiliza la misma estrategia que en sinónimos. Es decir, sólo se observarán aquellas palabras no comprendidas en iteraciones anteriores. Aun con todo, la búsqueda de una simple palabra en algunos servidores, en especial el de temas, suele llevar unos segundos. Por esta razón, y por el hecho de que el ordenador de DYPAR puede no tener acceso a internet, se habilitó DYPAR con una memoria para que pudiese reconocer rápidamente si una palabra es un tema, lugar, persona, organización, etc, es decir, una memoria que contiene las relaciones ISA. Además, esta memoria se va actualizando de forma automática, incorporando aquellas palabras que tras consultarse en los servidores se averiguó qué eran. Éste es un aspecto interesante que también se quería introducir, ya que permite un cierto aprendizaje y se va acercando más a lo que se espera de un programa inteligente. La idea es seguir explotando la potencialidad de dicha memoria, pero esto no se contempla en este proyecto final de carrera.

4.11 Esquema básico de la estructura gramatical desarrollada para el dominio de los metadatos de mapas

Fig. 10Esquema seguido por la gramática desarrollada para el reconocimiento de una frase

37


38

frase subfrase

Do you knowI wantCan you show me…..

the emailthe electronic mailorganizationsthe publisher of mapsgeographic area do they cover…..

of Aragonof Economyof Edelvivesof DGA…..

inicio frase

pregunta frase

información frase

citation

contact

description

varios

timePeriodOfContent

varios

atributo omitido

atributo no omitidowhich title is“FBI spy"with the publication date 2001with north = 3 ……

from 11/02/03 to 14/05/03with begin date 20/03/72 and end date 21/3/72…..

why have the dataset created …..

from whom can I obtain the maps …..

where does the maps come from …..

supérfluo

elipsis-anáfora

please, thank you, …with the publication date 2001with north = 3 ……of them, of previous resutls, …with the publication date 2001with north = 3 ……

De aquí se obtendrá el SELECT

De aquí se obtendrá el WHERE


4.12 Estrategias de procesamientoExisten varias posibilidades a la hora de que DYPAR procese la entrada del usuario:

4.12.1 Considerando palabras atípicasEn este caso, cada vez que DYPAR detecta una palabra de la frase del usuario que no comprende, simplemente la elimina y reintenta el procesamiento.

4.12.2 Considerando sinónimosDado que se dispone del diccionario Wordnet, se puede habilitar el uso de sinónimos a la hora de interpretar la entrada del usuario. De este modo la gramática es mucho más rica y completa de lo que aparenta a simple vista, puesto que DYPAR buscará los sinónimos de aquellas palabras que no comprenda. El hecho de considerar sinónimos a la hora de procesar una frase conlleva un incremento significativo en el tiempo necesario en la búsqueda de la solución. Tal incremento en el tiempo se redujo en gran medida al evitar la búsqueda de elementos básicos, como pueden ser artículos, preposiciones, signos de puntuación, pronombres, etc.

4.12.3 Considerando sinónimos para lanzar las reglas sensibilizadas

Existen algunos casos, poco probables, en los que se precisa habilitar el tratamiento de sinónimos para localizar las reglas potenciales que pueden ser lanzadas. En este caso se contempla el uso de sinónimos para todas las palabras y no sólo de las desconocidas, lo cual acarrea un tiempo de procesamiento bastante alto.

Esto es así porque DYPAR se basa en el primer y último terminal de los patrones para averiguar qué reglas están sensibilizadas. En el caso de que el sinónimo introducido por el usuario coincida con la primera o última palabra de un patrón, DYPAR no se dará cuenta de que la regla asociada a ese patrón está sensibilizada, ya que tiene que considerar los sinónimos.

4.12.4 Consideración combinadaLa estrategia utilizada por defecto es una combinación de las tres anteriores, de modo que:

se realiza un procesamiento inicial normal

si ese procesamiento no ha tenido éxito, se localiza la palabra desconocida para tener en cuenta sus sinónimos. Se realiza un nuevo procesamiento de la frase.

si tras considerar los sinónimos de la palabra desconocida el procesamiento tampoco ha tenido éxito, se designa dicha palabra como atípica y es eliminada de la frase antes de reintentar un nuevo procesamiento

si llegado a este punto no se ha conseguido reconocer la entrada del usuario, se pasa a habilitar el uso de sinónimos para lanzar todas las potenciales reglas sensibilizadas.

39


5 Estudio previo

Antes del comienzo de este proyecto se contrastaron las distintas herramientas a utilizar.

Básicamente se consideraron 3 posibilidades: el uso de DYPAR, utilizar un intérprete muy básico del libro Orvig y la construcción Ad-hoc.

Orvig de desechó por considerarlo un tanto pobre y no demasiado flexible para lo que se pretendía.

La construcción Ad-hoc implicaba la dedicación de excesivo tiempo para el desarrollo de todo el proyecto, por lo que también se desestimó esta posibilidad.

DYPAR tenía la ventaja de que ya había sido utilizado en otros proyectos comerciales y de investigación. El éxito y utilización de DYPAR en dichos proyectos contribuyó a la decisión de su uso. Si bien, también DYPAR poseía varios inconvenientes importantes. El código de DYPAR disponible no funcionaba al 100% debido a las numerosas contribuciones de al menos 10 personas, lo que provocaba el mal funcionamiento de diversas partes. Esto obligó a una etapa previa de depuración que no fue fácil porque la documentación del funcionamiento de DYPAR no existía, salvo algunos comentarios en el código, y el código no era excesivamente legible. Otro aspecto negativo de DYPAR es que se trata de un código desarrollado en los años ochenta, por lo que no se implementó utilizando las técnicas modernas de programación, como podría ser la orientación a objetos. Esto hacía que el código fuera más bien enrevesado y difícil de seguir.

También, de forma previa, se consuló la existencia de sistemas similares para el procesamiento de frases destinados a la recuperación de información de una base de datos. Con ello se intentaba averigual algo de información sobre cómo trabajaban dichos sistemas. De este estudio cabe destacar el sistema START (SynTactic Analysis using Reversible Transformation) que es un sistema de respuesta a preguntas, haciendo uso del lenguaje natural. Dada una frase, START lo primero que hace es partirla en unidades más pequeñas. Después analiza por separado cada unidad partida generando con ella una base de conocimiento. Esa idea de separar una frase en distintas partes contribuyó en cierta medida a la estrategia utilizada para el reconocimiento de frases con la gramática desarrollada en este proyecto final de carrera.

40


6 Análisis

6.1 Idea

Fig. 11 Idea de funcionamiento de la aplicación a desarrollar

Grosso modo, la idea conjunta se puede observar en el anterior dibujo. Se trata de ser capaz de interpretar las preguntas que introduce un usuario apoyándose en una gramática, un diccionario y un intérprete de frases. Esporádicamente también puede buscarse información en fuentes externas.

Para responder a las preguntas formuladas por el usuario se cuenta con ayuda de un intérprete de frases (DYPAR), junto con una gramática que dicta qué frases se reconocen, un diccionario (wodnet) donde buscar sinónimos y una memoria en la que ir almacenando determinada información. También existe la posibilidad de acudir a fuentes de información externa (servidores, bases de datos, etc.) cuando dentro de la frase del usuario existe algo que no se comprende. La información obtenida de dichas fuentes de información externas se puede ir almacenando en la memoria para su rápida consulta si llegara a ser necesario, sin tener que acudir nuevamente a fuentes de información externa.

41


6.2 Conceptos previosEn este apartado del análisis se van a representar una serie de esquemas denotando los diagramas de flujo de datos (DFD). Un diagrama de flujo de datos simplemente indica qué transferencia de información existe entre los distintos elementos que intervienen en el sistema que se está desarrollando.

En un DFD se observará distintos niveles. Se parte del nivel superior o de contexto y se va explotando en sucesivos niveles inferiores hasta que queda suficientemente detallado y claro.

En algunas ocasiones se han introducido elementos o relaciones no propias de un DFD por considerarlas útiles.

También se introducirán unas miniespecificaciones de los DFD de nivel inferior para observar la funcionalidad propia de cada proceso.

6.3 Notación de un dfd

Entidad externa ajena al sistema en estudio. De esa entidad sólo se conoce la transferencia de información, no cómo la procesa.

Proceso que realiza algún tipo de transformación de los datos que le llegan, produciendo datos de salida.

Almacén de datos. Originalmente se debe representar con 2 líneas paralelas, pero se ha elegido esta notación para facilitar la lectura.

Indican una transferencia de la información en el sentido indicad por la flecha.

Aunque no pertenece a un DFD, también se incorpora información sobre la tecnología empleada en la comunicación y el lenguaje en el que está implementado cada módulo. También se detallan en ocasiones las relaciones entre entidades externas.

Las entidades externas con color de fondo indican que no han sido desarrolladas en este proyecto, pero que se hace uso de las mismas.

42


6.4 Consulta de catálogo6.4.1 DFD del nivel de contexto

Fig. 12DFD nivel de contexto de la consulta del catálogo

La consulta de catálogo se encarga principalmente de interactuar con el usuario, de comunicarse con la entidad encargada de procesar las frases (servidor de DYPAR en este caso) y de averiguar previamente a dicha comunicación qué entidad es la óptima (con menor sobrecarga) en ese momento para dicho procesamiento.

A continuación se desglosa este esquema en un nivel inferior para observar las funcionalidades con mayor detalle.

43


6.4.2 DFD de nivel 1

Fig. 13DFD de nivel 1 de la consulta del catálogo

44


6.4.3 Diagrama de secuencia

Interfaz con el usuario

Acceso al catálogo

Acceso al servidor de ficheros IOR

Acceso al procesamiento de la frase

Servidor de catálogo

Usuario Procesamiento de las frases

frase

frase

frase

query SQL + contexto

query SQL

Construcción del árbol

query SQL

árbol de consulta

árbol de consulta

vector dataset_id

petición atributo

vector atributos

resultados de la consulta

resultados de la consulta

Fig. 14Diagrama de secuencia de la consulta del catálogo

6.4.4 Miniespecificaciones Acceso al catálogo = *Proceso encargado de comunicarse con el catálogo enviando y

recibiendo información de éste*

Construcción del árbol = *Analiza la consulta SQL (query SQL) y construye el árbol que refleja dicha consulta*

Acceso al procesamiento de las frases = *Enviar apropiadamente la frase y el contexto de ésta a la entidad encargada del procesamiento. Recoger también la respuesta*

Accesos a servidor de ficheros IOR = *Se encarga de la comunicación con el servidor de ficheros IOR para conseguir la localización de la entidad “procesamiento de frases” con menor sobrecarga de trabajo*

Interfaz con el usuario = *Módulo que interacciona con el usuario, permitiéndole introducir frases y mostrándole los resultados*

45


6.5 Procesamiento de frases6.5.1 DFD del nivel de contexto

Fig. 15 DFD del nivel de contexto del procesamiento de frases

Este sistema se encarga de procesar las frases recibidas para deducir la consulta SQL de las mismas.

En el siguiente diagrama con un nivel más en el dfd, se observa las funcionalidades con más detalle. Básicamente existen 7 módulos principales para llevar a cabo el procesamiento de la frase. El más importante de ellos es DYPAR, el cual se apoyará de módulos como son “acceso memoria”

6.5.2 DFD del nivel 1Fig. 16 DFD de nivel 1 del procesamiento de frases

6.5.3 Diagrama de secuenciaFig. 17 DFD de nivel 1 del procesamiento de frases

46


47


DYPARservidor de ficheros IOR

consulta del catálogo

servidor de thesaurus

cliente págs. web

parser XML Acceso catálogo

% sobrecarga CPU

Enviar IOR Servidor DYPAR

IOR óptimo

¿ tema ?

si / no

¿ lugar ?

respuesta (XML)

respuesta (XML)

respuesta XML procesada

¿ persona, organización, editor, ?

sí / no

IOR

¿ % uso CPU ?calcular

% uso CPU% uso CPU

frase + contexto

frase + contexto



49


6.5.4 Miniespecificaciones

DYPAR = *Interpreta las frases basándose en las gramáticas definidas*

Acceso wordnet = *Abstrae el diccionario wordnet, permitiendo recuperar sinónimos*

Acceso memoria = *Controlador que permite acceder a la memoria para buscar o introducir términos*

Cliente págs. Web = *Permite comunicarse con un servidor de páginas web utilizando el protocolo HTTP*

Servidor DYPAR = *Escucha indefinidamente solicitudes de procesamiento de frases, encargándose de invocar apropiadamente al módulo DYPAR, recoger el resultado y devolverlo correctamente al que realizó la solicitud. También acepta solicitudes de cálculo de la sobrecarga de la CPU del ordenador en cuestión. Invoca al módulo encargado de tal tarea y recoge los resultados, enviándolos de regreso al solicitante de la información.*

% carga CPU = *Encargado de calcular la sobrecarga del computador. Esta sobrecarga se devuelve en forma de porcentaje*

6.6 Servidor de ficheros IOR6.6.1 DFD del nivel de contexto

Fig. 18 DFD del nivel de contexto del servidor de ficheros IOR

50


Con este servidor se pretende centralizar la información de la localización de todos los DYPAR activos en el momento actual. Por ello, cuando un usuario inicia la aplicación para la consulta del catálogo consulta primero con este servidor para averiguar la localización de un DYPAR óptimo, es decir, cuya máquina esté menos sobrecargada en cuanto a CPU.

6.6.2 DFD del nivel 1

Fig. 19 DFD de nivel 1 del servidor de ficheros IOR

51


6.6.3 Diagrama de secuencia

Consulta de catálogo

Servidor de ficheros IOR

Gestión IORóptimo

Recepción IORProcesamiento de las frases

IOR

solicitud IOR

averiguar el óptimo

¿ DYPAR está vivo ? ¿ % uso CPU ?

% uso CPU

IOR óptimo

IOR óptimo

Fig. 20 Diagrama de secuencia del servidor de ficherios IOR

52


6.6.4 Miniespecificaciones Servidor de ficheros IOR = * Proceso que queda a la espera de solicitudes encargado

de la recepción de dichas solicitudes y el envío del IOR (localización) óptimo (de menor sobrecarga).*

Gestión IOR óptimo = *Se dedica a consultar a todos las entidades de “Procesamiento de las frases” si están activados (vivos) y les pregunta qué % de uso de CPU están utilizando actualmente. Si reconoce alguna entidad no activa elimina su referencia del almacén. Una vez que conoce todos los porcentajes de uso, averigua el óptimo sin más que eligiendo el de menor valor.*

Recepción IOR = * Parte dedicada a recibir los datos de localización de las entidades “procesamiento de las frases”. Almacena convenientemente dicho dato. De este modo se tiene un registro de todos las entidades de procesamiento de frases activas hasta ese momento.*

En el anterior diagrama se puede observar los flujos de datos entre la parte correspondiente al procesamiento de las frases (DYPAR y módulos de apoyo) con las entidades externas.

53


7 Diseño

7.1 Módulos desarrollados para el procesamiento de las frases

sinonimos

tratar_sinonimos_fi rst()tratar_sinonimos_last()sinonimo()eliminar_eltos_base()sinonimos()singular()

Este módulo se encarga de todo lo referente al tratamiento de sinónimos. Básicamente busca en wordnet los sinónimos especificados, normaliza las palabras para que wordnet las entienda, trata sinónimos que se componen de varias palabras, averigua cuántas palabras de la entrada del usuario forman el sinónimo, etc.

anafora_elipsis

tratar_anafora_el ipsis()anafora_elipsis()

Este módulo permite el tratamiento de la anáfora y elipsis.

isa

isa()memorizar?()consulta_bd()isa_tema()isa_lugar()include()encontrado_en_fichero()include_en_fichero()

ISA (IS-A) es un módulo utilizado para averiguar qué es una palabra determinada o un conjunto de ellas. Busca en distintas fuentes de información, como son la memoria, bases de datos, ficheros, preguntando a un servidor en internet, etc.

Hasta ahora es capaz de reconocer palabras de lugares, temas, nombres propios de personas, nombres propios de organizaciones, nombres propios de editores, y palabras desconocidas (no reconocidas hasta ahora).

sql

union_where()where()string_sql()query()query1()select()mostrar_query()encuentra_clave()eliminar_duplicados_query()

Este módulo realiza los tratamientos necesarios para construir una sentencia SQL partiendo de la información que la gramática ha ido identificando, y que estará recogida en el contexto propio del hilo.

Debido a la anáfora y la elipsis existe el método “union_where” que permite fusionar dos partes where de sentencias SQL.

54


list_string

string-substitute()stringNumber()list2string()string2list()restString()lista_palabras()simbolo_palabras()cadena_palabras()getStringSymbol()delList()eliminar_palabra()nthcdrString()sin_parentesis()val()lappend()lista()encontrado_en_lista()coinciden()nbutlast1()elimina_duplicados()

Dado que es necesario procesar multitud de cadenas, símbolos y listas se diseñó esta clase. Es capaz de realizar diversas comprobaciones, selecciones, transformaciones y conversiones que han sido necesarios para el procesamiento de la entrada del usuario.

55


contextopalabras_reconocidasesinonimasatipicasiteracionexiste_solucionselectwhereselect_anteriorwhere_anterioroperador_anterioratributo_anteriorultimo_include_reconocidotipopilainputinput_originalflag_sinonimos_first_lastanafora_elipsis

reset_iteracion()copiar_en_query_anterior()

Debido a la posibilidad de multiusuarios por cada proceso DYPAR, se hizo necesaria esta clase. A cada usuario que se conecta con DYPAR se le instancia un objeto de esta clase. De este modo, se mantiene un contexto propio de cada hilo de ejecución, en el cual se irá almacenando la información necesaria.

ney

mostrar()sin_solucio()sin_solucion1()sin_solucion2()sin_solucion3()ini_contexto_hilo()con_solucion()

NEY es el módulo encargado de tomar decisiones una vez que DYPAR ha procesado la entrada del usuario.

Permite realizar varias iteraciones de búsqueda de la solución considerando diversas estrategias, como son el tratamiento de sinónimos, de palabras atípicas, y la de sensibilización de reglas utilizando sinónimos.

NEY posee una memoria de rápido acceso en el que va almacenando conocimiento acerca de qué son las palabras. Almacena información sobre lugares, temas, nombres propios y palabras desconocidas. Esta memoria se recupera al iniciar DYPAR y se vuelve a almacenar al final, sirviendo de aprendizaje y rápido acceso. De esta forma DYPAR es más autosuficiente y no necesita consultar constantemente las fuentes de información externas (en internet) que suelen ser lentas e incluso inaccesibles.

Esta memoria es común y única para cada DYPAR. Esto tiene ventajas e inconvenientes. Como ventaja está que cada DYPAR poseerá una memoria particular, que dependerá de las consultas que haya tenido que realizar a las fuentes de información externas, es decir,

56


dependerá de las frases introducidas por el usuario. Por ejemplo, si un DYPAR es utilizado constantemente en búsqueda de mapas del territorio de España, éste acabará aprendiéndose de memoria muchos lugares. El inconveniente es que la información que cada DYPAR va almacenando en memoria no es accesible por el resto.

El diseño de esta memoria está compuesto de las siguientes tres clases:

memoriasubmemoriasnum_submemoriasmax_submemorias

añadir_submemoria()submemoria?()recordar()recordar()borrar_submemoria()save()load()get_submemorias()get_num_submemorias()get_max_submemorias()

recuerdopalabrasfrecuencia_uso

incrementar_frecuencia()get_frecuencia_uso()get_palabras()

submemoriarecuerdosnum_recuerdostipomax_recuerdos_memoriamax_palabras_recuerdo

memorizar()recordar()recuerdo?()borrar_recuerdo()load()save()get_recuerdos()get_num_recuerdos()get_tipo()get_max_recuerdos_memoria()get_max_palabras_recuerdo()

0..*0..*

0..*0..*

Fig. 21 Diagrama de clases de la memoria

57


La memoria como tal está formada por submemorias, las cuales contienen recuerdos y éstos tienen palabras. Cada submemoria se encarga de almacenar el conocimiento de un determinado tipo. Por ejemplo, existe una submemoria encargada de almacenar información sobre los lugares.

7.2 Diagrama de clases en la consulta del catálogo

Acceso_catalogocatalogo : NS_Catalog

conexion_servidor_catalogo()construir_arbol()getDatasetVector()getValues()

Esta clase se encarga de todo lo referente a la comunicación con el servidor del catálogo.

Acceso_dyparcontexto : Contextoserver : ChatServerIlistener : ChatListenerIrecibido : Booleanapplet_chat : Applet_chat

conexion_dypar()enviar()getSelect()getWhere()

Su responsabilidad es comunicarse con el servidor de DYPAR, enviando la información a DYPAR en el formato apropiado y quedando a la espera de los resultados.

Applet_chat

messageReceived()

Applet que visualiza y controla el interfaz con el usuario; y establece comunicación con el servidor DYPAR y el servidor de ficheros IOR, haciendo uso de las dos clase previas.

7.3 Diagrama de clases en el servidor de ficheros IOR

Servidor

ejecutar_servidor()cargar_propiedades()

Esta clase implementa un demonio (proceso que siempre estará a la escucha) que estará esperando en un determinado puerto a que un cliente le solicite algo. Cuando el cliente realice su solicitud, este servidor crea un hilo servidor_secundario para que sea éste el que se comunique con el cliente y efectúe todo el trabajo necesario. De este modo el servidor quedará disponible casi al instante para recibir

58


nuevas peticiones.

Servidor_secundario

run()grabar_ior()enviar_ior()ior_optimo()cargar_propiedades()conexion_dypar()

Esta clase implementa el hilo que realizará la comunicación con el cliente. En un instante dado podrán existir varios hilos que estén ejecutándose concurrentemente. De este modo se descarga el trabajo del servidor principal, que simplemente espera solicitudes y delega el trabajo en un hilo.

El cliente puede realizar dos solicitudes. Del lado de DYPAR se recibirá un envío del contenido del fichero IOR, el cual se almacenará convenientemente (grabar_ior). Por parte del applet del usuario se recibirá una solicitud de un IOR óptimo, es decir, aquél que pertenezca al DYPAR cuya máquina está con menos carga de trabajo. Esta información es provista convenientemente por este hilo.

Listener_thread

getCPU_usage()run()

Clase independiente. Es utilizada para solicitar al servidor DYPAR el porcentaje de uso de CPU, así como esperar y recoger la respuesta de éste. Esta comunicación se realiza vía CORBA.

Listener

messageReceivedString()

Recoge el uso de CPU transmitido desde el servidor DYPAR. Esta clase es necesaria debido a CORBA.

Clienteporthostippath

enviar_ior()pedir_ior()cargar_propiedades()

Cliente utilizado para enviar el contenido IOR al servidor de IOR o para realizar una petición de un IOR de DYPAR óptimo.

Iorio

publish()getLine()resolve()

Obtiene el IOR de un fichero local o del servidor de ficheros IOR. También crea el objeto corba que se utilizará para comunicarse con el objeto designado por el IOR.

59


Registroiortipo

getIOR()getTipo()

Clase cuyo objeto contendrá el IOR para ser transferido a través de la red.

7.4 Diagrama de clases del servidor de thesaurus

Acceso_thesaurus

thesaurus_prohibidos()acceso_thesaurus()es_tema()addThesaurus_prohibido()

Esta clase permite comunicarse con el servidor de thesaurus para consultar si determinadas palabras son o no un tema.

Servidor

main()ejecutar()

El objeto de esta clase hará que al ejecutarse se quede a la espera de una solicitud. Es un demonio. Al recibir una petición crea un objeto de tipo “Servidor_secundario” para que éste realice la consulta.

Servidor_secundario

run()

Encargado de consultar al servidor de thesaurus si determinadas palabras forman o no un tema.

7.5 Diagramas de clase de utilidades comunes

Gestionar_socketsinputStreamoutputStreamsocket

enviar_objeto()enviar_bytes()recibir_objeto()cerrar_socket()

Clase utilizada para abstraer del envío y recepción de objetos por un socket. También se permite enviar bytes.

60


8 Características soportadas

8.1 ConcurrenciaLa concurrencia se refiere a la posibilidad de que DYPAR pueda manejar concurrentemente el procesamiento de frases de varios clientes. Para lograr esto el ORB lanza un hilo (thread) de Lisp separado. De esta manera cada cliente es tratado por un hilo, posibilitando su ejecución concurrente.

8.2 MultiusuarioDYPAR acepta y maneja a múltiples usuarios de distintas máquinas. Para ello se ha tenido que guardar de forma separada un contexto de ejecución. Es el propio CORBA quien permite multiusuarios al crear un thread cada vez que se conecta un cliente.

8.3 MultiprocesoEn DYPAR, CORBA crea un thread por cada solicitud de un cliente en el servidor. Éstos hilos se ejecutan concurrentemente, es decir, se trata de multiproceso.

8.4 EscalabilidadSe pueden crear multitud de servidores de DYPAR y el propio DYPAR para evitar un cuello de botella debido a la saturación de un único DYPAR. Tras una larga experiencia utilizando DYPAR, se ha observado que su consumo de CPU es muy alto debido a la gran cantidad de trabajo que tiene que realizar cada vez que procesa una frase. Además, el hecho de tener varias réplicas de los servidores DYPAR funcionando, posibilita la tolerancia ante el fallo de alguno de ellos.

8.5 Tolerancia a fallosDesde el punto de vista del sistema de procesamiento de frases (servidores DYPAR), al existir la posibilidad de múltiples sistemas de éstos ejecutándose en computadores distintos, se hacía necesario tratar el caso en que uno de estos sistemas dejaran de funcionar por algún motivo. El servidor de ficheros IOR cuando consulta a todos los sistemas de procesamiento de frases para averiguar su carga de CPU, también observa si está o no activo. Si se hubiese caído, entonces borra la referencia (IOR) de la localización de dicho sistema. De este modo el sistema de consulta de catálogo obtendrá un procesador de frases válido hasta ese preciso instante.

Otro problema de fallos al que se ha hecho frente viene motivado por una espera indefinida de respuesta tras haber realizado una determinada consulta de DYPAR a una fuente de información externa. Para evitar esos casos se han habilitado timers, de forma que si no se obtiene una respuesta dentro del periodo fijado por el timer, entonces se da por concluida dicha comunicación, y si es posible, se continúa.

La elección de un servidor sin estado en DYPAR se ha debido a que este tipo de servidor tiene la gran ventaja de ser tolerante a fallos. En un servidor sin estado no se mantiene ningún tipo de información sobre el cliente una vez que le ha sido devuelta su respuesta, es

61


decir, el servidor sólo posee información acerca del cliente en el intervalo dado entre la solicitud del mismo y la devolución de respuesta. Por ejemplo, si el servidor falla, el cliente simplemente tendría que realizar nuevamente su petición, ya que las solicitudes tienen la propiedad de ser idempotentes (se pueden ejecutar tantas veces como se desee sin causar efecto alguno). Sin embargo haría falta que el cliente detectara esta situación y pidiera nuevamente la localización de un DYPAR al servidor de ficheros IOR. Esta posibilidad no está implementada en el proyecto, aunque no sería complicado hacerlo.

Y si es el cliente el que falla, el servidor no se ve afectado de ninguna forma, ya que no dispone de ningún tipo de información de sus clientes. Esto evita la proliferación de basura en el servidor a la muerte inesperada de los clientes (clientes huérfanos). De este modo el servidor no ha de estar pendiente de los clientes.

Al lanzar DYPAR, si no se detecta el servidor de thesaurus, éste se desactiva de forma automática para evitar realizar búsquedas en el mismo.

62


9 Implementación

9.1.1 DepuraciónHa sido necesaria la modificación del código lisp de DYPAR debido al mal funcionamiento de varios operadores. El código DYPAR ha sido modificando por distintas personas durante varios años, lo cual ha producido un incremento en el número de errores ocasionados por cada modificación. Además, la documentación del código de dypar brilla por su ausencia. Todo lo cual ha hecho complicado el seguimiento de dicho código y ha resultado difícil la modificación o depuración del mismo. Como anécdota sólo hay que leer uno de los comentarios escritos por uno de los programadores que intervino en la modificación de DYPAR:

“;;; Don't look at me, I didn't write it. -wmb”

La intención en este proyecto final de carrera no era la de depurar o intentar interpretar el enrevesado código de DYPAR, por lo que el estudio de dicho código se ha reducido al mínimo. Suficiente para depurar algunos fallos y para incorporar nuevas funcionalidades, como el tratamiento de sinónimos o la introducción de varios operadores.

Dado que un ordenador es dificil, si no imposible, que disponga de todo el conocimiento necesario, se ha intentado recoger dicho conocimiento desde distintos lugares. Esto hace posible la descentralización y distribución del conocimiento, pero tiene como pega cierta dependencia de esas partes externas para un adecuado funcionamiento. De ahí la incorporación de las siguientes modificaciones en DYPAR.

9.1.2 Modificaciones introducidas en DYPAR9.1.2.1 Thesaurus

Para averiguar si una palabra es un tema se recurre a dos fuentes de información. Por una parte se creó un servidor de thesaurus que se comunica con DYPAR a través de sockets. Podría haberse utilizado nuevamente CORBA, pero dada la simplifidad de la información intercambiada se optó por usar sockets. Además, esto evita la sobrecarga introducida por CORBA, haciendo que la comunicación sea muy rápida. El uso de sockets también ha sido debido a la curiosidad por intentar comunicar a más bajo nivel dos aplicaciones que están programadas en distintos lenguajes (lisp y java en este caso).

El hecho de haber realizado el servidor de thesaurus en java se debió a la necesidad de reutilizar un proyecto final de carrera de otro alumno (Jonás Ansó Castranado). Este proyecto engloba todo lo referente a thesaurus, el propio autor lo resume diciendo “La idea que origina este proyecto es usar la información de los tesauros, y la base de conocimiento léxico WordNet, no sólo para clasificar manualmente los metadatos, sino también para aumentar tanto en número como en calidad los resultados de las búsquedas avanzadas y permitir el acceso a los metadatos desde distintas organizaciones jerárquicas.”.

La parte que interesaba para el actual proyecto era la búsqueda de los mismos, ya que en dicho proyecto se conecta a la base de datos apropiada y consulta todos los thesaurus.

La otra fuente de información la constituye un simple fichero que continene todos aquellos temas específicos que no existen como tales en la base de datos consultada por el servidor de thesaurus. Esto hace posible que el administrador pueda introducir dichos términos

63


específicos para que sean reconocidos como temas. O simplemente por el interés de poseer localmente dicha información para tener un acceso rápido e independientemente de estar o no conectado a internet.

Los datos almacenados en los ficheros ha de estar ordenada alfabéticamente en orden ascendente.

Con el fin de evitar reconsultas en el servidor de thesaurus, es decir, repetir más de una vez consultas sobre temas, se va registrando esos datos en una memoria especialmente diseñada para DYPAR. En esta memoira se introducen aquellas palabras que tras consultarse con el servidor éste ha respondido afirmativamente. También se puede aprovechar si dicho servidor responde negativamente, introduciendo las palabras que no se han reconocido como temas también en memoria. El uso de esta memoria se pensó para incrementar la velocidad de respuesta, puesto que DYPARr, cuando da marcha atrás mientras procesa una frase, vuelve a procesar las mismas palabras, lo cual implica volver a consultar si éstas se tratan de temas o no.

9.1.2.2 Lugares

Dado que sería absurdo intentar agrupar en una base de datos todos los nombres propios de lugares, se optó por utilizar una página web que a partir de un nombre informa, entre otras cosas, de si se trata de un lugar. La respuesta se obtiene en formato XML. La necesidad de acceder a una página web y recuperar esa información hizo necesaria la búsqueda y adaptación de código lisp que ya implementase la parte cliente, es decir, el navegador web. Para ello se ha utilizado parte de la aplicación “aserve” que implementa en lisp tanto el cliente como el servidor del protocolo HTTP. Esta vez el cliente recibe la página con el contenido XML y en vez de visualizarlo captura dicha información y se procesa con un parser XML (utilsXML). Dicho parser también se encontró buscando por internet.

Al igual que con el tratamiento de los temas, con los nombres propios de lugares también es posible introducir nombres especificos en un fichero de texto y/o en memoria

9.1.2.3 Personas, organizaciones, editores

La consulta de esta información es otra de las tareas realizadas. En la base de datos del catálogo existe ya un campo de una tabla que contiene todos los nombres propios utilizados. Mediante ODBC se consulta si una determinada palabra es o no un nombre. De nuevo se dispone de un fichero para contener nombres propios específicos, así como la posibilidad de ir registrando en memoria la información que se va averiguando.

En todos los anteriores casos se tiene en cuenta que el nombre propio esté formado por más de una palabra. Esto hace que la comprobación de si un conjunto de palabras forman un nombre propio determinado se alargue en el tiempo, ya que se deben ir haciendo sucesivas comprobaciones considerando cada vez más palabras, hasta un límite máximo fijado en los parámetros de configuración. Por ejemplo, en una frase del usuario del estilo“...air quality of Aragón of economy” nos encontramos el tema “air quality”. En este caso se realizarán las siguientes búsquedas en el servidor de temas (thesaurus):

1. búsqueda si “air” es un tema -> sí

2. búsqueda si “air quality” es un tema -> sí

3. búsqueda si “air quality of” es un tema -> no

4. búsquea si “air quality of Aragon” es un tema -> no

5. finaliza la búsqueda porque se ha llegado al límite de palabras a buscar en el caso de temas (4 en este caso).

64


De lo anterior se deduce que “air quality” es un tema, ya que es la búsqueda con éxito con más palabras.

9.2 Implantación del sistema cliente-servidor entre DYPAR y el Applet del usuario

Se ha optado por un servidor sin estado o sin memoria, es decir, el servidor no tiene que mantener un seguimiento de las peticiones de los clientes. Esto implica que cada solicitud enviada por un cliente ha de ser autocontenida, esto es, debe contener toda la información necesaria para que el servidor realice con éxito la consulta. En este caso es necesario que el cliente envíe, además de la correspondiente consulta, la información del contexto relativo a las últimas consultas realizadas. Esto es necesario para el tratamiento de la elipsis y la anáfora.

La elección de un servidor sin estado se ha debido a que este tipo de servidor tiene la gran ventaja de ser tolerante a fallos. Por ejemplo, si el servidor falla, el cliente simplemente tendría que realizar nuevamente su petición, ya que las solicitudes tienen la propiedad de ser idempotentes (se pueden ejecutar tantas veces como se desee sin causar daño alguno). Y si es el cliente el que falla, el servidor no se ve afectado de ninguna forma, ya que no dispone de ningún tipo de información de sus clientes. Esto evita la proliferación de basura en el servidor a la muerte inesperada de los clientes (clientes huérfanos). De este modo el servidor no ha de estar pendiente de los clientes.

9.3 OptimizacionesCon el fin de que el procesamiento de una frase sea más eficiente, en la gramática se ha utilizado evaluación cortocircuitada (operador !!) en aquellos lugares en que ha sido posible. La evaluación cortocircuitada consite en que cuando DYPAR encuentre una correspondencia entre una subfrase del usuario y un patrón de una regla de reescritura entonces parará y no intentará seguir con otros patrones.

Otro operador utilizado en la gramática con el que se consigue mayor eficiencia en el procesamiento es (&o). Este operador sirve para introducir elementos opcionales en la gramática, pero forzando a consumir el elemento opcional siempre que sea posible. Otro operador análogo pero con el que no se fuerza ese consumo es (?) con el cual DYPAR crea dos ramas de ejecución: una en el que el patrón sí se corresponde con la entrada del usuario y otra en la que no. Al existir 2 ramas de ejecución en este último caso provoca un mayor tiempo de procesamiento.

También se introdujo optimización en cuanto a los tipos. En el caso en que se conozca de antemano el tipo de cierto terminal (nombre propio) introducido por el usuario entonces no es necesario perder tiempo observando el resto de tipos. Por ejemplo, si en la frase del usuario se encuentra algo como “... with the date 2001 ...”. En este caso antes de procesar el dato se sabe de qué tipo va a ser (una fecha).

En la propia gramática también se ha intentado introducir determinados elementos que eviten perder tiempo observando casos improbables. Por ejemplo, a la hora de detectar si algo es un nombre propio de lugar, tema, persona, etc. el patrón de la gramática está escrito de modo que no considerará como tales los elementos base (preposiciones, pronombres, artículos, etc). Esto quizás podría evitar, en algún caso particular, reconocer nombres propios que comiencen con un elemento base (un artículo, por ejemplo), pero no es habitual.

65


Otro elemento optimizador introducido en la gramática es el operador ==. El comportamiento de éste es análogo a un case o switch de programación. De forma que si determinada variable (asignada dentro de la gramática con el operador <-) posee un valor concreto, sólo se tendrá el cuenta el patrón asociado. Por ejemplo,

(tipo == name) <persona> !! (tipo == place) <lugar> !! (tipo == theme) <tema>

Con esto, si la variable tipo tiene el valor “theme” sólo se intentará equiparar con el último patrón, <tema> en este caso.

9.4 Descripción básica de funcionamiento 9.4.1 Esquemas de funcionamiento9.4.1.1 Concurrencia

Fig. 22 Esquema reflejando la comunicación y concurrencia

66

hilo

Usuario

Servidor DYPAR

Usuario Usuario UsuarioUsuario

Servidor DYPAR

Servidor de ficheros IOR

hilo

hiloo

hilo

hilo hilo

hilo

Servidor DYPAR


Como puede observarse en la anterior figura, DYPAR puede estar ejecutándose en distintos ordenadores, lo cual posibilita un fácil escalado conforme aumenta el número de usuarios. El servidor de DYPAR es el responsable de atender las solicitudes de procesamiento de los usuarios. Es el propio CORBA el que crea un hilo de ejecución por cada solicitud, de modo que es factible una ejecución concurrente de DYPAR en la misma máquina.

También existe concurrencia en el lado del servidor de ficheros IOR. Este servidor recoge solicitudes tanto de lado del usuario como desde DYPAR.La organización de hilos en este servidor se ajusta al modelo del servidor / trabajador, es decir, cuando el servidor recibe una solicitud crea un hilo para delegarle el trabajo.

Antes de nada el servidor de ficheros IOR debe haberse lanzado.

También debería estar lanzado al menos un servidor DYPAR. Al lanzarlo también se provoca de forma automática la transferencia al servidor de ficheros IOR del IOR del DYPAR recién lanzado.

Todo el proceso comienza cuando el usuario desea consultar información utilizando el intérprete de lenguaje natural. Para ello accederá a la correspondiente web mediante un navegador. El applet desarrollado que sirve de interfaz gráfico se descargará en el navegador del usuario.

Una vez descargado dicho applet, se precisa conocer con qué servidor DYPAR se van a realizar las consultas. Esto lo realiza el propio applet solicitando al servidor de ficheros IOR la dirección IP y el puerto (IOR) de aquel servidor DYPAR que considere oportuno.

El servidor de fichero IOR observa todos los ficheros IOR que ha recibido hasta entonces y por cada uno de ellos mira si el servidor DYPAR asociado está todavía activo y al mismo tiempo le formula una consulta sobre cómo de saturado está el ordenador en el que se está lanzado.

DYPAR invoca a un pequeño programita para obtener el porcentaje de uso de la CPU, una vez obtenido se lo envía al servidor de ficheros IOR para que pueda realizar la selección.

Cuando el applet dispone ya del IOR sólo tiene que enviar las frases de usuario al servidor DYPAR asociado para que éste las vaya procesando.

9.5 Descripción detallada del funcionamientoFuncionalidad de cada una de las partes.

9.5.1 Servidor DYPARPueden existir varios servidores de DYPAR, lo cual implica que cada usuario esté usando uno cualquiera de ellos o que varios usuarios estén usando concurrentemente uno (multiusuario). El hecho de que existan varios servidores dypar se realizó principalmente para evitar la congestión de la máquina que posea DYPAR, ya que, se ha observado, que la utilización de la CPU es muy alta cuando se está procesando una simple frase. Además así también se logra tolerancia a fallos en los servidores DYPAR, puesto que aunque alguno de los servidores DYPAR se caiga aún se dispone del resto para seguir atendiendo a los usuarios.

67


9.5.2 Servidor de ficheros IOREl servidor de ficheros IOR es un demonio que está escuchando en un determinado puerto en un ordenador cualquiera, cuya misión es encargarse de todo lo relacionado con los ficheros IOR, es decir, recibirlos, guardarlos, seleccionarlos y enviarlos. También se encargará de cerciorarse de que los servidores DYPAR asociados a los ficheros IOR están activos. La comunicación con este servidor se realiza utilizando los sockets de java y corba.

Cada vez que un servidor DYPAR se pone en funcionamiento en algún ordenador, se ha de enviar al servidor de ficheros IOR la información sobre dónde se encuentra dicho servidor DYPAR (puerto, dirección IP...). Esta información está contenida en el fichero IOR creado por DYPAR cuando se inicializó. Dicho fichero es enviado al servidor de ficheros IOR, mediante sockets, por un pequeño programa anexo escrito en Java. No se quiso hacer esa comunicación utilizando CORBA porque hacer esto sería complicar algo que es muy sencillo hacerlo desde java.

A la recepción de un fichero IOR, el servidor de ficheros IOR lo guarda en un directorio predefinido.Cuando un usuario se introduce en la página web donde está el applet que recoge las consultas del usuario, el código del applet se conecta con el servidor de ficheros IOR solicitando el IOR de un servidor dypar con el que poder conectarse. El servidor de fichero IOR consulta el directorio predifinido donde están todos los ficheros IOR y empieza a comprobar si cada servidor DYPAR correspondiente a cada fichero IOR está vivo y a solicitar del mismo el cálculo de sobrecarga de la máquina en la que está ejecutándose. Si no está vivo, se elimina dicho fichero y se intenta con otros. Esto hace que el fichero IOR enviado al applet tenga una alta probabilidad de ser “bueno”.

9.5.3 AppletTras recibir el applet el fichero IOR, intenta conectarse con el servidor DYPAR asociado a dicho fichero. Si lo consigue, permite al usuario empezar a introducir sus consultas. Para cada consulta introducida el applet realiza una llamada remota al método correspondiente de DYPAR, enviándole el contexto (frase del usuario e información histórica de las anteriores consultas).

A la recepción de esa invocación, DYPAR comienza a procesar la frase con el fin de intentar interpretarla. Una vez que ha terminado, le devuelve al cliente solicitante la sentencia SQL que ha deducido de la frase del usuario, así como la información de contexto para que en una futura conexión del cliente disponga de toda la información necesaria.

El applet, cuando recibe la sentencia SQL, realiza un análisis léxico-sintáctico con el fin de crear el árbol que sirva para consultar esa información al servidor del catálogo. Una vez creado el árbol, se llama al servicio apropiado para que, utilizando el árbol, se comunique con el servidor del catálogo. Éste construirá apropiadadmente la sentencia SQL y consultará la base de datos del catálogo, seleccionando únicamente los identificadores de los datasets que han cumplido las condiciones reflejadas en el árbol-consulta. Esta información es devuelta al applet, el cual, haciendo uso nuevamente del servidor del catálogo, irá pidiendo, según el “select” de la sentencia SQL recibida de DYPAR, los datos asociados a cada dataset_id. Al recibir esa información, se le mostrará al usuario.

68


9.5.4 DYPAREsquema del tratamiento realizado por DYPAR en el reconocimiento de una frase:

lista_sinónimos = ();input = frase introducida por el usuario;éxito = falso;sinonimos_reglas_sensibilizadas = falsodesde i = 1 hasta *MAX_iteraciones* hacer

Intentar reconocer input calculando los sinónimos de lista_sinónimos. Llevar el recuento del número de veces que se reconocen las palabras de input si se ha conseguido reconocer input entonces

éxito = verdad;si_no

palabra_desconocida = primera palabra no reconocida en inputsi palabra_desconocida pertenece a lista_sinonimos entonces

eliminar esa palabra de input iterar de nuevo si_no // es la primera vez => intentar calcular sinónimos

lista_sinónimos = lista_sinónimos + palabra_desconocidaiterar de nuevo

finsi éxito entonces

observa si el usuario ha hecho uso de la elipsis o anáfora para poder completar información según las frases anteriores.

si_nosi sinonimos_reglas_sensibilizadas = falso entonces intentar un nuevo conjunto de iteraciones teniendo en cuenta los sinónimos a la hora

de de calcular las reglas sensibilizadassi_no informa al usuario del no reconocimiento de la frase

69


10 Tratamientos realizados por el intérprete de lenguaje natural DYPAR

10.1 Corrección ortográficaAunque en un principio DYPAR tiene la posibilidad de corregir ortográficamente algunas palabras, esta opción se ha deshabilitado en este proyecto porque con el uso de una gramática grande acababan liándose más las cosas e interpretaba frases de forma incorrecta.

10.2 Eliminación de signos ortográficosDYPAR elimina aquellos signos ortográficos definidos previamente, como son (, . ; ¿ ? ¡ !, etc). Fijarse que al hacer esto se pierde parte de información que podría resultar importante, puesto que una simple coma es capaz de modificar el significado de la frase. Sin embargo, se ha optado por eliminarlos todos para no hacer más complicado todavía el procesamiento de las frases.

10.3 SupérfluosExisten una serie de palabras que no aportan significado a la frase y que se pueden omitir. La gramática detecta dichos supérfluos y no los tiene en cuenta. Por ejemplo, palabras como please, beautiful, thanks, etc.

10.4 SemánticaEn el reconocimiento de una frase se tiene en cuenta expresiones implícitas o incompletas que un ser humano reconoce gracias a su conocimiento. Un ejemplo muy claro de ésto se encuentra cuando un usuario no define explíticamente el nombre de un atributo. Por ejemplo, en la frase “show me the title of all maps of Aragón” el usuario sabe que “Aragón” es un lugar geográfico por lo que no escribe explícitamente este hecho en algo como “show me the title af all maps wich place is Aragón”. Este reconocimiento implícito se realiza gracias a la utilización de fuentes externas de información (servidores de internet y bases de datos), la memoria o ficheros que contienen cada uno un conjunto de palabras que definen un “conocimiento”. Así, por ejemplo, para el caso del lugar geográfico, existe un fichero “lugar.txt” que contiene multitud de palabras designando lugares geográficos, entre ellos “Aragón”, también se dispone de un servidor de lugares y de una submemoria específica para almacenar nombres propios de lugares. Estas fuentes de información posibilitan una actualización continua, incrementando el “conocimiento” de la gramática. Sirven para obtener una gramática dinámica que pueda crecer con el tiempo en vez de ser estática y quedarse desfasada.

70


10.5 NegacionesTambién se tiene en cuenta la utilización de negaciones o doble negaciones por parte del usuario.

Por ejemplo, en el caso de una única negación, en la frase “display me all themes of all maps aren’t of Aragón” se interpretará correctamente (place <> “Aragón”).

En el caso de las dobles negaciones, si un usuario introduce una frase del estilo “give me the themes of all maps aren’t different of Aragon”. La gramática desarrollada interpreta correctamente que lo que el usuario está pidiendo es todos los mapas de Aragón (place = “Aragon”).

10.6 ContextoOtra característica de la gramática es que es sensible al contexto en determinados casos. En la frase “Who published the maps with the title “hola” or “adios””), la constante “adiós” se refiere a un título, cuyo atributo está definido implítitamente.

10.7 SinónimosEl hecho de calcular los sinónimos hace que la riqueza de la gramática sea mucho mayor de lo que parece, puesto que no sólo se reconocerán las frases contenidas en la gramática, si no muchas más, debido a la posibilidad de calcular los sinónimos de cada palabra especificada en la gramática. Se ha tenido en cuenta la posibilidad de que un sinónimo esté formado por varias palabras (por ejemplo, “electronic mail = mail”). La búsqueda de estos sinónimos se realiza en Wordnet, un diccionario en inglés que contiene sinónimos, antónimos, homónimos, etc.

Es importante destacar la forma de funcionamiento para reconocer un sinónimo formado por varias palabras. Para considerar los sinónimos hay 2 estrategias:

Calcular los sinónimos de las palabras introducidas por el usuario

En este caso existe una pega importante. ¿ Cuántas palabras considerar para calcular el sinónimo ? Por ejemplo, si el usuario introduce entre la frase “... electronic mail...” habría que intentar equiparar “electronic mail” con lo que se encuentra en la gramática, es decir, calcular los sinónimos de 2 palabras. Como no se puede prever de antemano cuántas palabras recoger para calcular el sinónimo, se optó por la segunda estrategia.

Calcular los sinónimos de las palabras de la gramática

Aunque estra estrategia es bastante más costosa en tiempo, permite que el usuario utilice sinónimos formados por varias palabras. Esto es así debido a que se van calculando los sinónimos de las palabras de la gramática y se intenta equiparar con lo introducido por el usuario.

Considerando el ejemplo anterior se observa su correcto funcionamiento: en la gramática estará dentro de alguna regla el terminal “email” que tiene varios sinónimos, entre ellos “electronic mail”. En este caso se calcularía los sinónimos de “email” y al hacerlo se observaría que uno de ellos es precisamente “electronic mail”, que se corresponde con 2 palabras de la frase del usuario. De este modo se detecta correctamente los sinónimos de varias palabras.

71


Observar que no se calculan sinónimos de modo indiscriminado, si no de aquellas palabras que en iteraciones anteriores se han detectado como no conocidas. En cierto modo esta actitud es análoga a lo que haría un ser humano, es decir, buscar en un diccionario aquellas palabras que desconoce de lo que está leyendo.

Además, no se pierde tiempo buscando sinónimos de elementos básicos del lenguaje, como son los artículos, preposiciones, pronombres, etc.

Todo esto hace que la rapidez en el procesamiento de una frase sea mucho mayor. El procesamiento de sinónimos es opcional y se puede habilitar o deshabilitar modificando el parámetro adecuado en la configuración.

10.8 AtípicasAl eliminar las palabras que no se han reconocido ni siquiera tratando sinónimos (o si la consideración de sinónimos ha sido deshabilitada), se intenta deshacerse de palabras atípicas o basura que en principio no aportan nada. Por ejemplo, si el usuario introduce “idiot” en alguna parte de la frase, ésta acabará siendo eliminada, puesto que no ha sido considerada en la gramática. De nuevo se observa la analogía con un ser humano, el cual, quizás por pereza, no considera las palabras desconocidas en vez de ir a buscarlas al diccionario, sin que ello merme demasiado su capacidad de entender la frase.

10.9 Elipsis y anáforaEl principal desafío de los sistemas actuales es el seguimiento del contexto de una interacción. El usuario deberá ser capaz de plantear una serie de preguntas, algunas de las cuales implícitamente se refieren a preguntas o respuestas previas:

¿ Qué países están al norte del Ecuador ?

¿ Cuál es su área total ?

Algunos sistemas como TEAM (1987) son capaces de manejar este tipo de problemas de manera limitada.

Con la anáfora nos podemos encontrar frases que hacen referencia a otras previas. Por ello, es necesario utilizar la información obtenida de la frase previa para poder interpretar correctamente la frase con anáfora.

El permitir al usuario la utilización de la elipsis o la anáfora ha hecho necesario la introducción de cierta memoria, ya que se ha de tener en cuenta los resultados de lo anteriormente escrito por el usuario. Esto se lleva a cabo guardando el “select” y el “where” calculado según las anteriores frases (select_anterior y where_anterior). Una vez que se ha procesado satisfactoriamente la frase, se observa:

si select = vacío entonces select <- select_anterior where <- Unión(where, where_anterior)

si where = vacío entonces where <- where_anterior

72


10.10 AprendizajeEs importante que la gramática sea lo más dinámica posible. Una de las características que se ha querido introducir en la gramática ha sido su capacidad para aprender. Un caso de esto se puede observar cuando dentro de una frase se encuentran palabras supérfluas que no aportan nada a la hora de entender el significado de la frase. Por ejemplo, las palabras “please” “thanks” y en general los adjetivos calificativos (“beautiful”, “fine”....). La forma de incorporar el aprendizaje en este caso es registrar en algún sitio (fichero o memoria) las palabras atípicas o no comprendidas. Pero no siempre es conveniente añadir las palabras no comprendidas porque pudiera darse que en otra frase esas palabras sí sean entendidas de acuerdo a la gramática desarrollada. El hecho de incorporar en la gramática este aprendizaje es para aumentar la velocidad de reconocimiento la próxima vez que se encuentren esas palabras. Actualmente se produce aprendizaje con las relaciones IS-A: lugares, temas, nombres propios de personas, organizaciones y editores.

10.11 PluralesSe realiza un tratamiento de los plurales para que éstos también sean reconocidos por wordnet a la hora de calcular los sinónimos. Ya que el interfaz entre lisp y wordnet sólo reconoce sinónimos de palabras en singular.

10.12 AmbigüedadesExiste un problema ante la ambigüedad que se crea en lo que respecta a la prioridad de los operadores booleanos. La siguiente frase se puede interpretar de dos formas distintas:

“Could you show me all maps of Zaragoza or of Teruel and different of economy ?”

1ª interpretación:

Select = title

Where = ((place = Zaragoza) or ((place = Teruel) and (theme <> economy)))

O bien,

2ª interpretación:

Select = title

Where = (((place = Zaragoza) or (place = Teruel)) and (theme <> economy))

Sin el uso de paréntesis en la frase escrita por el usuario, siempre pueden darse este tipo de ambigüedades. La gramática desarrollada no contempla la utilización de paréntesis para cambiar las prioridades de los operadores booleanos. Esta decisión se tomó porque en el lenguaje oral tampoco se hacen uso de paréntesis, y la interpretación del lenguaje natural que se pretende hacer debe ser análoga a la del lenguaje oral.

La segunda interpretación de la frase nos parece a todos la más adecuada. Intuitivamente, si se hace referencia a un mismo atributo, tendemos mentalmente a agruparlos como si tuviesen un paréntesis.

73


En el desarrollo realizado siempre se realiza la primera interpretación, es decir, la interpretación será de la forma ((((a operador b) operador c)) operador d). Por lo tanto se mayor prioridad a los operadores situados a la izquierda.

11 Test

74


Con el fin de realizar tests de la forma más cómoda posible, se puede utilizar “test.lsp” que contiene multitud de frases con las que comprobar si se reconocen por la gramática desarrollada. Para poder realizar este tratamiento individualizado de frases, se implementó una nueva función en DYPAR (parser_string) que no precisara de la intervención directa del usuario. Las frases reconocidas y no reconocidas serán almacenadas en sendos ficheros para su posterior supervisión, siempre y cuando esté activo el flag para que dicho almacenamiento tenga lugar. También se cronometra cuánto cuesta en procesarse cada frase.

11.1 Ejemplos de frases reconocidas y su procesamiento "I, want maps, which place !! is Aragon. ? !"

Antecedentes:

Procesamiento:

Elimina los caracteres extraños. Sólo precisa de una iteración para su comprensión

Resultado:

select = (TITLE PLACE)

where = ((PLACE = "'ARAGON'"))

Tiempo de procesamiento:

3,986” sin compilar

0,681” con el código compilado

"Do you know who is the COMPANY supplier of the maps of Aragon"

Antecedentes:

COMPANY es una palabra no contemplada en la gramática.

Procesamiento:

“Aragón” lo reconoce correctamente como un lugar, a pesar de que no se explicita el atributo “place”. En la primera iteración detecta “COMPANY” como atípica. En la segunda iteración intenta reconocer la frase considerando los sinónimos de “COMPANY” pero tampoco lo consigue. En la tercera iteración elimina la palabra desconocida “COMPANY” y entonces sí reconoce correctamente la frase.

Resultado:

select = (ORIGINATOR)

where = ((PLACE = "'ARAGON'"))



6,279“ con el código compilado

"please could you show me all maps of Zaragoza or of Teruel and different of economy"

75


Antecedentes:

Please se considerada supérflua en la gramática. No se especifica qué son las palabras “Zaragoza”, “Teruel” ni “Economy”. Estas tres palabras las tiene memorizadas NEY. Fijarse en el matiz introducido por “different”.

Procesamiento:

Sólo es necesaria una iteración. “Zaragoza” y “Teruel” se reconocen correctamente como lugares al consultar la memoria. También reconoce “Economy” como un tema.

Resultado:

select = (TITLE)

where = (((PLACE = "'ZARAGOZA'") OR

((PLACE = "'TERUEL'") AND (THEME <> "'ECONOMY'"))))




"Who published the maps which title isn't different of \"hola coco\" or the title is equal to \"adios coco\""

Antecedentes:

Procesamiento:

En este ejemplo puede observarse cómo la gramática es capaz de manejar correctamente las dobles negaciones.

Resultado:

select = (TITLE PUBLISHER)where = (((TITLE = "'HOLA COCO'") OR (TITLE = "'ADIOS COCO'")))



"Of the maps with the title \"a b c\" I want the ELECTRONIC MAIL, the address and the FACSIMILE of contact"

Antecedentes:

La gramática reconoce “email”, pero no “ELECTRONIC MAIL”. Lo mismo sucede con “FACSIMILE” porque la gramática sólo reconocd “fax”

Procesamiento:

Serán necesarias 3 iteraciones hasta conseguir comprender la frase.

En la primera iteración no reconoce “ELECTRONIC” por lo que tiene en cuenta sus sinónimos en la segunda iteración. En esa segunda iteración reconoce “ELECTRONIC MAIL” como sinónimo de “email” pero no se sabe qué es “FACSIMILE”. En la tercera iteración ya tiene en cuenta los sinónimos de “ELECTRONIC MAIL” y “FACSIMILE”, por lo que reconoce la frase entera.

Resultado:

76


select = (EMAIL ADDRESS FAX TITLE)

where = ((TITLE = "'A B C'"))




11.2 Otras frases reconocidasA continuación se ofrece una muestra de frases correctamente reconocidas.

1. I, want maps, which place !! is Aragon. ? ! (con signos sintácticos estúpidos)

2. all maps which place is Arabia Saudi ( place = Arabia Saudi (> 1 palabra))

3. Do you know who is the COMPANY supplier of the maps of Aragon (COMPANY es una palabra no reconocida por la gramática)

4. all maps of economy 5. all maps which theme is economy 6. all maps which place is Aragon and which theme is economy 7. all maps with place = Aragon and theme = economy 8. HEY BABY give me all maps which theme is economy

(HEY BABY son palabras basura: no reconocidas por la gramática)9. give me all maps which theme is economy 10. please could you show me all maps of Zaragoza or of Teruel and different of

economy (atributos omitidos: no se dice que Zaragoza y Teruel son lugares “place” ni que “economy” es un tema)

11. all maps <> Aragon and <> economy (nuevamente sin nombres de atributos y utilizando signos)

12. all maps of Aragon 13. all maps different of Aragon 14. can you show me of Aragon the theme

(varias posiciones sintácticas: primero la parte inicial de la frase y luego la información)15. of Aragon can you show me the theme

(varias posiciones sintácticas: primero información, luego la parte inicial de la frase y luego más información)16. the theme of aragon17. of aragon the theme18. do you know how many maps are there of economy about Aragon19. PLEASE do you know how many beautiful maps are there of economy about Aragon20. I want maps which place is Aragon which theme is economy from 1/2/3 to 4/5/6 21. PLEASE I want maps of Aragon of economy from 1/2/3 to 4/5/6 22. I want maps of politica from 1/2/3 to 4/5/623. I want all maps of politica of Aragon from 1/2/3 to 4/5/6 with the title "un titulo

cualquiera" 24. What are the title of maps of Aragon25. I would like to get all titles of maps of Aragon26. The titles of maps of Aragon

77


27. the title of Aragon28. Can you show me any titles of maps of Aragon29. Can you DISPLAY all BASURA maps with N equal 3 of Aragon 30. Do you know from whom can I obtain maps of Aragon 31. Can you say me where can I find maps of China 32. The publication date of all the maps of India33. The maps about economy of Aragon with coordinates north = 3 and south = 4 and

east = 5 and west = 6 34. The maps of Aragon with coordinate N = 3

(N no está en la gramática. Se detectará que N es un sinónimo de NORTH) 35. The maps of Aragon with coordinates north = 3

(N no está en la gramática. Se detectará que N es un sinónimo de NORTH) 36. Where can I find maps of Aragon which supplier is DGA 37. I look for if there are any maps of Aragon which supplier is DGA and with the

publisher Edelvives 38. I want all maps which PROVIDER is dga

(En la gramática se reconoce “supplier” no “provider” pero con la ayuda de los sinónimos procesa la frase correctamente) 39. Do you know who is the supplier of the maps of Aragon 40. Who is the publisher of maps with coordinates north=441. Who published the maps with the title \"hola coco\"42. Who published the maps with the title \"hola\" or \"adios\" ; atributo implícito:43. Who published the maps with the title different of \"hola coco\" 44. Who published the maps without the title \"hola coco\"45. Who published the maps with the title different of \"hola coco\"46. Who published the maps which title is \"hola coco\" or which title is different

of \"adios coco\"47. Who published the maps which title is \"hola coco\" or \"adios coco\"48. Who published the maps which title isn't different of \"hola coco\" or the title is equal

to \"adios coco\"49. Who published the maps which title isn't different of \"hola coco\" or is equal

to \"adios coco\"50. Who is the publisher of maps which title isn't \"adios coco\"51. The titles of maps, the originator and the publisher of Aragon52. What is the theme, the time period and the bounding coordinates of the maps of

Aragon 53. Show me the originator, the publisher and the title of all maps of Aragon which

publication date is 1/2/354. Who is the contact person and the organization of all maps of India 55. I want the email, the address and the fax of contact of the maps with the title \"xyz\"56. I want the ELECTRONIC MAIL, the address and the FACSIMILE of contact of the

maps with the title \"xyz\"57. Of the maps with the title \"a b c\" I want the ELECTRONIC MAIL, the address and

the FACSIMILE of contact 58. Of the maps with the title \"a b c\" I want the ELECTRONIC MAIL59. What are the bounding coordinates, the theme and who is the publisher of the maps

of Aragon60. Who is the name of the organization that developed the maps of Canada 61. Who organizations developed the maps of Canada 62. Who organizations have developed the maps of Canada 63. and the publication date (reconocimiento de anáfora-elipsis)

78


64. What's the time period of all maps of Arabia Saudi 65. Can you say me what are the titles of maps of Aragon AND what geographic area

do they cover (reconocimiento de anáfora-elipsis)

66. of them how many maps are there of Zaragoza (reconocimiento de anáfora-elipsis)

67. what's the last review date of this metadata (reconocimiento de anáfora-elipsis)68. Do you know how many maps are there about Aragon ? 69. of them how many maps are there about economy ? (reconocimiento de anáfora-elipsis)70. Give me INFORMATION THE ATTRIBUTES place and theme

(INFORMATION THE ATTRIBUTES son palabras no reconocidas por la gramática, es decir, atípicas)

71. Of Aragon, Can you show me all maps ?

12 Instalación

79


12.1 Conexión mediante ODBC

12.1.1 Configuración en WindowsEn el panel de control de Windows, dentro de la utilidad “ODBC Data Sources” hay que añadir un nuevo DSN dentro de la pestaña “User DSN”. Pulsar el botón de añadir y elegir el controlador ODBC de Oracle. Data Source Name = “iaaadb” Service name = “iaaadb”, UserID = “metadata”

12.1.2 Configuración en OracleSi se tiene instalado Oracle, en el submenú “Network Administration” existe un asistente de Net8. Al ejecutarlo añadir el servicio “iaaadb” con las siguientes características:

protocolo de red = “TCP/IP (Protocolo Internet)”

nombre del Host = “iaaa.cps.unizar.es”

número de puerto = 1521

Nombre del Servicio (Oracle8i) = iaaadb

SID de base de datos = iaaadb

12.1.3 ODBC desde Lisp(require :aodbc)

(use-package :dbi)

(setq db (connect :data-source-name "iaaadb" :user "metadata" :password "metadata"))

Ha de salir un mensaje parecido al siguiente, si devuelve Nil es que no ha podido conectarse.

#<DBI::ODBC-DB "iaaadb" @ #x20542562>

(setq *default-database* db) ; evita tener que estar poniendo constantemente la bd en cada función

(pprint (execute-sql "select max(cntper) from contact where cntper like '%Losada%'"))

(disconnect db)

12.2 Habilitar concurrencia de CORBA en LispCuando el ORB maneja una petición de entrada, él lanza un hilo Lisp separado, una instancia de mp:process, si el valor del atributo thread_policy de corba:orb es:thread_per_request.

12.3 Instalación de wordnetEl diccionario wordnet ha de ser instalado. Se puede encontrar el instalador en:

http://www.cogsci.princeton.edu/~wn/

80



13 Manual de usuario

13.1 Requisitos13.1.1 Requisitos softwareEl desarrollo de software Java ha sido realizado con ayuda del entorno de desarrollo JBuilder-3.0 que utiliza la verisón java jdk 1.2

Se ha utilizado Windows-NT como plataforma de desarrollo

13.1.2 Requisitos hardwareSi se lanza todo lo necesario, incluyendo el servidor de catálogo, es conveniente disponer al menos de 128 MB de memoria RAM.

En cuanto a la velocidad del procesador, se han obtenido buenos resultados con un procesador AMD K7-650 Mhz

81


13.2 Interfaz con el usuario

Fig. 23 Interfaz con el usuario

Una vez que la aplicación ha obtenido todo lo necesario mostrará el mensaje “preparado para procesar consultas”, si por algún motivo ha habido algún fallo el usuario será informado en la propia ventana.

El usuario debe escribir su consulta en lenguaje natural en la parte inferior de la ventana. Al pulsar return comenzará el procesamiento de la misma. Una vez obtenida la respuesta, se muestra la sentencia SQL que se ha deducido y automáticamente se realiza la consulta de dicha sentencia. Se le informa al usuario del número de datos que cumplen la consulta realizada y se le va mostrando uno a uno los mismos.

82


14 Manual del programador

14.1 Relación de ficheros asociados al proyecto14.1.1 Ficheros propios de DYPARRuta: .\PFC\dypar\

DYPAR se componía previamente de los siguientes ficheros:

Para una breve descripción de cada uno se puede acudir al manual de DYPAR.

macros.lsp struc.lsp general.lsp var.lsp babel.lsp xload.lsp xref.lsp" xmatch6.lsp extend.lsp dyread.lsp xpar.lsp decl.lsp runtime.lsp dytest.lsp optimize.lsp elipsis.lsp orto.lsp dypartra.lsp conexion.lsp grafic.lsp

14.1.2 Ficheros nuevos incorporados en DYPARRuta: .\PFC\dypar\

Para la realización de los nuevos tratamientos y mejoras de DYPAR (sinónimos, nuevos operadores, etc.) se crearon varios ficheros de funciones-métodos Lisp:

anafora_elipsis.lsp

Contiene los métodos necesarios para el tratamiento de la anáfora-elipsis.

contexto.lsp

Contiene los métodos relacionados con el contexto propio de cada hilo, así como la declaración de la clase asociada a dicho contexto.

sinonimos.lsp

Aquí se puede encontrar un conjunto de métodos necesarios para el tratamiento de sinónimos.

83


memoria.lsp

Clase que contiene los métodos apropiados para interactuar con la memoria. Una memoria se compone de submemorias.

submemoria.lsp

Clase que contiene los métodos apropiados para interactuar con la submemoria.

Una submemoria se compone de recuerdos.

recuerdo.lsp

Clase que contiene los métodos apropiados para interactuar con los recuerdos. Un recuerdo se compone de una lista de símbolos.

isa.lsp

Realiza la consulta de fuentes externas y de la memoria para observar de qué tipo es lo que se le solitita.

atipicas.lsp

Todo lo que respecta al manejo de palabras atípicas puede encontrarse en los métodos incluidos en este fichero.

sql.lsp

La formación, registro, tratamiento, etc. de las sentencias SQL son realizadas por los métodos de este fichero.

funciones.lsp

Contiene un conjunto de funciones independientes que realizan alguna tarea concreta.

expresion.lsp

Tratamiento de todo lo referente a las expresiones: tratamiento de negaciones, formación de expresiones con atributos omitidos, etc.

ney.lsp

Se encarga de tomar una decisión cada vez que no ha podido reconocerse la actual frase del usuario.

También efectúa las operaciones necesarias cuando la frase del usuario ha sido reconocida correctamente.

list_string.lsp

Contiene un amplio conjunto de métodos capaces de realizar multitud de tratamientos con listas o cadenas.

parametros.lsp

En este fichero se podrá encontrar un conjunto de parámetros que pueden configurarse para variar el comportamiento de DYPAR y para la instalación.

84


14.1.3 Ficheros de la consulta de catálogoRuta: .\PFC\ney\

Ney.jpr

Proyecto de JBuilder donde se indican los ficheros que forman el proyecto y que son los que se detallan a continuación.

Acceso_catalogo.java

Clase encargada de todo lo referente al acceso al catálogo para realizar consultas.

Acceso_dypar.java

Clase que realiza las tareas necesarias para comunicarse con el servidor de DYPAR.

Applet_chat.java

Applet en sí que contiene el interfaz con el usuario y que estará disponible en alguna página web.

chat_dypar_applet.idl

Interfaz que contiene las estructuras que se van a utilizar para intercambiar información utilizando CORBA.

Este fichero ha de ser compilado para generar un conjunto de clases necesarias por CORBA.

Applet_chat.html

Formato de la página web en sí que lanzará el applet con el interfaz del usuario. Se puede ejecutar desde JBuilder, lo que hará uso de appletviewer.

14.1.4 Ficheros del servidor de ficheros IORRuta: .\PFC\servidor_ior\

servidor_IOR.jpr


Aplicacion.java

Programa principal ejecutable que envía al servidor de ficheros IOR el contenido del fichero IOR.

Cliente.java

Clase encargada de enviar y pedir el contenido de IOR.

IorIo.java

Clase útil para recuperar IORs.

Listener_thread.java

Hilo encargado de pedir el uso de CPU y esperar la recepción de la respuesta asíncrona.

Registro.java

85


Clase que contendrá el IOR en sí, así como información sobre el tipo de petición que se está realizando al servidor de ficheros IOR.

Servidor.java

Servidor propiamente dicho que se queda esperando indefinidamente las solicitudes de los distintos clientes.

Servidor_secundario.java

Servidor secundario o hijo que realiza las tareas de comunicarse con un determinado cliente para dejar al padre (Servidor.java) esperando nuevamente.

servidor_ior.properties

Contiene las propiedades de configuración del puerto y directorios donde se recogeráy y dejarán los ficheros IOR.

14.1.5 Ficheros del servidor de ThesaurusRuta: .\PFC\thesaurus\

thesaurus_moi.jpr


Acceso_thesaurus.java

Encargado de invocar los servicios necesarios para averiguar si algo es un tema.

Servidor.java

Servidor propiamente dicho, que una vez lanzado, se quedará indefinidamente a la escucha de solicitudes.

14.1.6 Ficheros del servidor de DYPARRuta: .\PFC\dypar\chatdemo

chatServer.cl

14.1.7 Ficheros de gramáticaRuta: .\PFC\dypar\gramatica\ingles

base.gra cardinales.gra citation.gra contact.gra dataset.gra description.gra distributionInformation.gra fecha.gra frase.gra geographicalCoordinates.gra identificationInformation.gra isa.gra keywords.gra

86


metadataReference.gra ney.gra ordinales.gra status.gra timePeriodOfContent.gra tipo.gra varios.gra

14.1.8 Ficheros de la b.d. asociada a la gramáticaRuta: .\PFC\dypar\gramatica\ingles\bd

editor.txt insultos.txt lugar.txt organizacion.txt persona.txt saludos.txt superfluo.txt tema.txt

Todos estos ficheros contienen en orden alfabético ascendente una serie de palabras referentes al tipo de valor que designan. Se puede añadir de forma manual más información para que DYPAR la reconozca como tal. Por ejemplo, nos puede interesar considerar “Galaxia M81” como un lugar, por lo que deberemos añadir (Galaxia M81) en el lugar correspondiente según el orden alfabético, dentro de ”lugar.txt“.

Observar que si se trata de varias palabras es obligatorio meterlas dentro de un paréntesis.

14.1.9 MemoriaRuta: .\PFC\dypar

memoria.txt

Este fichero se construye de forma automática cada vez que DYPAR finaliza, incorporando los nuevos conocimientos adquiridos.

Si se realiza con cuidado, pueden introducirse nuevos términos. Fijarse en la estructura.

14.1.10 AserveRuta: .\PFC\aserve-1.2.8

En este directorio se pueden encontrar todos los ficheros necesarios para la ejecución de la aplicación restringida de aserve.

Para información sobre los cambios realizados ver leeme_moises.txt

14.1.11 Parser XMLRuta: .\PFC\XMLUtils

Este directorio contiene todos los ficheros necesarios para utilizar el parser de XML.

Para información sobre los cambios realizados ver leeme_moises.txt

87


14.1.12 Utilización de CPURuta: .\PFC\cpu_usage

CPUMonitor.exe

Programita de VB encargado de calcular el % de uso de la CPU en el momento en que es ejecutado.

Pueden encontrarse dentro del subdirectorio cpumon los fuentes.

14.1.13 Servidor de catálogoRuta: .\PFC\catServer

En este subdirectorio se encuentran las librerías y ficheros por lote necesarios para lanzar el servidor de catálogo localmente.

14.2 Compilación

14.2.1 Compilación de DYPARGracias a compilar el código de DYPAR la velocidad de procesamiento se incrementa sustancialmente.

La compilación de todos los ficheros que componen DYPAR se puede realizar utilizando make.lsp. Para ello simplemente cargar lisp y ejecutar:

:ld make.lsp

Tras lo cual aparecerán los ficheros compilados (extensión .fasl).

A partir de entoces se pueden usar los ficheros compilados sin más que cargando el fichero bootc.lsp en vez de boot.lsp:

:ld bootc.lsp

14.2.2 Compilación del interfaz lisp-wordnetLa compilación del interfaz entre lisp y wordnet desarrollado por Miller se realizará del siguiente modo:

Primero hay que asignar valor a los dos parámetros de wornet definidos en parametros.lsp:

(setq *path_wordnet_db* "e:/WN16/dict/")

(setq *dir_instalacion* "e:/pfc")

A continuación cargar wordnet.lisp:

:ld wordnet.lisp

Compilación de wordnet:

(compile-wordnet)

Para obligar después a utilizar esos ficheros compilados, cambiar, si hicera falta, la última línea del fichero wordnet.lisp para que cargue los compilados y no los fuentes:

(load-files *wordnet-files* *wordnet-path* "fasl")

88


Con esto, al cargar a partir de entonces wordnet.lisp se estarán utilizando los ficheros compilados, lo que aumentará la velocidad.

14.3 El servidor de catálogo “catServer”El servidor de catálogo es necesario para poder enviarle el árbol de consulta y recoger la respuesta a dicha consulta una vez que el servidor ha conseguido la información solicitada. En estos momentos dicho servidor se lanza a mano, ya que no existe ninguno al que se pueda acceder directamente.

A fecha de hoy sí puede accederse a un catálogo con gestión de sesiones, pero no se utiliza porque implica una dependencia de versiones de librerías, modos de acceso al mismo, que esté o no lanzado, etc.

Dicho servidor está implementado en el paquete NSCatalog, que es la versión básica del catálogo. Éste se utiliza como un servidor RMI, por lo que se hace necesario definir una serie de propiedades (ver el subapartado “Parámetros-configuración -> Propiedades Java” para más información).

14.3.1 Cómo lanzar el servidor de catálogo localmente Modificar, si fuera necesario, las propiedades de CatServer.properties (para más

información acudir al apartado “Parámetros-configuración -> Propiedades Java”).

Ejecutar ./PFC/catServer/startRMIRegistry.bat para lanzar el RMIRegistry

Ejecutar ./PFC/catServer/startCatServer.bat para lanzar el servidor de catálogo propiamente dicho.

14.4 Pasos a seguir para la ejecución manual de la aplicación completa

1. Lanzar el servidor de catálogo como se indica en el apartado anterior.

2. Lanzar JBuilder.

3. Abrir los proyectos:

PFC\servidor_ior\Servidor_IOR.jpr

Este proyecto tiene tanto el cliente como el servidor de ficheros IOR.

El servidor cuando se lanza se queda a la espera de solicitudes.

El cliente se encarga de enviar solicitudes al servidor.

Lanzar Servidor.java para que quede ya a la escucha.

PFC\thesaurus\thesaurus_moi.jpr

Este proyecto contiene todo lo necesario para lanzar el servidor de thesaurus que se quedará a la espera de recibir las solicitudes desde el servidor DYPAR para corroborar si algo es un tema o no.

Lanzar Servidor.java para que quede ya a la escucha.

89


Previamente, será necesario tener definidos los parámetros de conexión con la B.D. en el cliente de oracle Utilizar los pasos indicados en el apartado “Configuración de oracle” dentro de “Instalación”.

PFC\ney\ney.jpr

Interfaz propiamente dicho.

Existe un applet que permite acceder mediante un navegador al interfaz.

4. lanzar Lisp. Para no complicarse la vida cambiando al directorio de DYPAR para cargar boot.lsp, se puede crear un acceso directo a lisp.exe. En las propiedades de este acceso directo, en la pestaña “Acceso directo”, se encuentra una casilla “Iniciar en:” donde debería indicarse el directorio donde está boot.lsp, que será .\PFC\dypar.

5. modificar si fuera necesario los parámetros de .\PFC\dypar\parametros.lsp

6. cargar .\PFC\dypar\boot.lsp mediante:

USER(1): :ld boot.lsp

o bien:

USER(1): (load "boot.lsp")

Al hacer esto se cargará tanto DYPAR como la gramática de reconocimiento. Además lanza el servidor DYPAR que se queda a la espera de las solicitudes. Al lanzarse ese servidor, se genera un fichero IOR que es almacenado en PFC\ficheros_ior_cliente

7. Para transferir el contenido del fichero IOR anteriormente almacenado en PFC\ficheros_ior_cliente hay que ejecutar desde JBuilder dentro del proyecto PFC\servidor_ior\Servidor_IOR.jpr a PFC\servidor_ior\servidor_ior\Aplicacion.java.

El servidor de fichreros IOR anteriormente lanzado recogerá el contenido IOR recibido y almacenará su contenido en un fichero situado por defecto en PFC\ficheros_ior_servidor. De esta forma el servidor ya posee información sobre dónde está situado el servidor DYPAR.

8. Ya sólo queda lanzar el interfaz

Para ejecutarlo desde JBuilder simplemente lanzar ney_Applet_chat.html que está dentro del proyecto PFC\ney\ney.jpr. El applet será entonces lanzado por la utilidad appletviewer.

14.5 Librerías necesarias PFC\servidor_ior\Servidor_IOR.jpr

Librerías de CORBA: VisiBroker 3.4 agrupa las siguientes librerías:

orbutil3.0.jar vbjapp.jar vbjcosev.jar vbjcosnm.jar vbjgk.jar vbjorb.jar vbjtools.jar

90


Que pueden encontrarse en JBuilder3\lib

PFC\thesaurus\thesaurus_moi.jpr

o thesaurus.jaro iaaa.jar o aplicacion.jar

PFC\ney\ney.jpr

o Librerías de CORBA: VisiBroker 3.4o datasetMetadata_1_3_2.jar

o NSCatalog_1_2_2

o iaaa.jar

o sdoapi.jar

PFC\servidor_ior\servidor_IOR.jpr

o Librerías de CORBA: VisiBroker 3.4

Nota: para poder usar CORBA en JBuilder se suele exigir poseer una licencia Enterprise. Por lo tanto JBuilder-4 foundation no sirve ya que es imposible compilar el fichero IDL.

14.6 Cómo incorporar un operador nuevo en DYPARSon 3 los ficheros que deberán modificarse para el nuevo operador <nombre_operador>:

1. xload.lsp

Deberá añadirse a la función altprop algo del siguiente estilo:

((eql (car pat) '<nombre_operador>)

(list (cons '<nombre_operador> (rest pat))))

Con esto se hace una pequeña transformación del orden con el que se ha escrito en la gramática el operador y sus argumentos. El nuevo orden es que se tendrá en cuenta en xmatch6.lsp a la hora de ir equiparando patrones y entrada.

2. xref.lsp

Aquí hay que indicar a DYPAR cuáles son los terminales con los que se disparará el patrón. Se indica el terminal inicial y el final.

Dentro de la función x-pat debe añadirse lo siguiente para indicar que el operador en cuestión (nombre_operador) se quiere realizar equiparación con la entrada del usuario:

(<nombre_operador> ; con (list '$) obligo a que la regla correspondiente se dispare siempre. De ; este modo se obliga a comprobar en xmatch a disparar la regla

91


(values (list '$) t (list '$) t nil t nil))

A este tipo de operador correspondería el operador &isa, el cual debe realizar una equiparación entre la entrada del usuario y lo indicado como argumento en el operador.

Otra posibilidad es añadir dentro de la función x-pat lo siguiente para indicar que con el operador en cuestión (nombre_operador) no se quiere realizar ninguna equiparación con la entrada del usuario:

(<nombre_operador> ; con nil sólo(list '$) obligo a que la regla correspondiente se dispare siempre. De ; este modo se obliga a comprobar en xmatch a disparar la regla

(values nil t nil t nil t nil)))

A este tipo de operador correspondería el operador ==, el cual no debe realizar una equiparación entre la entrada del usuario, sino que sirve de información y es utilizado internamente.

3. xmatch6.lsp

Dentro de la función smatch1 se añadirá en el “cond” algo similar a:

(&include ; la variable inp contiene lo que queda por procesar

; de la frase del usuario.....

<tratamiento a realizar para observar si existe equiparación con la entrada del usuario>

..... (list (cons (+ m n) old-bindings)) ; patrón válido (aplicable).

; Pasar m palabras )

Se deberá utilizar la variable inp. Ésta indica lo que queda por procesar de la frase del usuario.

Fijarse en la última línea. En ella se le indica a DYPAR que se han reconocido las m siguientes palabras de inp. Si sólo se ha reconocido una palabra entonces m = 1.

14.7 Nuevos operadores incorporados a DYPAR &include

Sintaxis: (&include <nombre_fichero>)

Este operador ha sido introducido ante la necesidad de hacer que la gramática fuera más dinámica y también más legible. Con él se consigue que la gramática sea ampliable. Al incluirlo dentro de algún patrón se obliga a que DYPAR observe la equiparación entre la correspondiente parte de la frase del usuario y el contenido de dicho fichero. El usar

92


&include equivale a escribir dentro de la propia gramática todo el contenido del fichero separado por el operador !! (or).

La información asociada a dicho fichero puede ser incorporada en tiempo de ejecución, lo cual es otra ventaja. De este modo, no es necesario parar DYPAR y lanzarlo de nuevo, porque el contenido del fichero se puede ir modificando. Esto implica un enriquecimiento progresivo de lo reconocido por DYPAR, de forma que la gramática es ampliable sin más que modificar los ficheros asociados a &include.

Un ejemplo de esto podría ser el fichero “saludos.txt” que contendría todos los saludos que se quiere detectar (hello, hi, good morning, how do you do, etc). En la propia gramática se incluirá en algún patrón algo del estilo (&include “saludos.txt”) para obligar a DYPAR a revisar ese fichero e intentar la equiparación con su contenido.

&isa

Sintaxis: (&isa <tipo>)

Al incluirlo dentro de algún patrón hace que DYPAR ejecute un método encargado de discernir si algo de lo que queda de la frase del usuario ES-UN <tipo>. Por ejemplo (&isa “lugar”) haría que se observara si en la parte correspondiente de la entrada del usuario hay un nombre propio de lugar. Si así fuera, la equiparación tendría éxito.

==

Sintaxis: (<variable> == <valor>)

Este operador sirve como un "switch" o un "case". Se utiliza para que el patrón se considere o no válido dependiendo de si se cumple la condición (variable == valor). Anteriormente se ha tenido que asignar esa variable a algún valor con el operador <-

En la gramática desarrollada, se usa para comparar los tipos, por ejemplo con (tipo == date) se obliga a que el valor introducido por el usuario sea una fecha, porque anteriormente se habrá detectado que el atributo al que ha hecho referencia el usuario va a compañado de una fecha, por ejemplo “start date”.

<-

Sintaxis: (<variable> <- <valor>)

Operador para asignación de variables. Se suele usar junto con el operador ==. Sirve para dar un cierto valor a una determinada variable, la cual será usada posteriormente por el operador ==. En la gramática se utiliza para los tipos. Por ejemplo, con (tipo <- date) se está indicando que se ha detectado un atributo cuyo valor posterior requiere una fecha, como puede ser “start date”.

14.8 Modificación de operadores en DYPAR &morph

Este operador no realizaba bien su misión y se modificó código para su correcto funcionamiento en xmatch6.lsp

&n

Este operador tampoco funcionaba correctamente. Se realizó una pequeña modificación en xmatch6.lsp

93


14.9 Otras modificaciones realizadas en DYPAR La variable !!allpunct no estaba definida en ningún sitio, a pesar de que tendría que

estarlo en sxreadl.lsp pero este fichero ni siquiera existía. Por lo tanto dicha variable se definió en el fichero extend.lsp”:

(defvar !!allpunct '(%dash %slash %apost %hash %lparen %rparen %star %bquote %rsbrack %lsbrack %bslash %vbar %dquote %lcbrack %rcbrack %labrack %rabrack %amper %percent %dollar %plus %equal %underbar %upcaret %atsign %tilde %cr %lf %qmark %emark %period %comma %colon %semicolon))

En el fichero xref.lsp

En este fichero se encontraban redefinidas las siguientes variables, con lo que las comentamos ya que se encotraban ya definidas en "xload.lsp":

!!not-defined

!!patrules

!!pattrans

La introducción del tratamiento de sinónimos en DYPAR obligó a multitud de modificaciones en distintas partes.

1. Se modificaron las funciones find-applicable-first , find-applicable-last , find-applicable-general, apply-top-level-rules dentro de xpar.lsp

2. Modificaciones varias en la función smatch1 dentro de xmatch6.lsp

3. Modificación de intersectp en general.lsp

14.10 Operadores que no funcionan correctamente en DYPARSe ha detectado que los siguientes operadores o no funcionan o lo hacen incorrectamente en algún caso:

&apply

&funcall

$w

Este operador debe ir siempre al final de un patrón, o bien ser asignado a una variable, en otro caso no funcionaba. La solución a este problema es poner $w entre paréntesis.

$d

$r

&i

Este último operador funciona mal si se utiliza dentro del mismo los operadores !! o ||, es decir, algo similar a (&i <a> !! <b> !! <c>) funciona incorrectamente. Esto tendría que convertirse en:

(&i <a>) !!

94


(&i <b>) !!

(&i <c>)

14.11 Parametrización – configuración14.11.1 Parámetros DYPARPara facilitar el proceso de configuración de una instalación y parametrizar el comportamiento de DYPAR se ha creado un fichero con un conjunto de parámetros configurables:

El fichero PFC\dypar\parametros.lsp se pueden actualizar una serie de parámetros:

T equivale a true (verdad)

Nil equivale a false (falso)

(setq !success-flag T)

Indica si se desea escribir en el fichero "success.dat" las frases que se van reconociendo.

(setq !failure-flag T)

Indica si se desea escribir en el fichero "failed.dat" las frases que no se van reconociendo.

(setq *debug* nil)

Si se desea o no mostrar mensajes que ayudan a la depuración.

(setq *flag_sinonimos* T)

Si es T (true) DYPAR hará un tratamiento de sinónimos, por lo que usará wordnet. Esto provocará un ralentecimiento del procesamietno de la frase, pero la potencia de reconocimiento de DYPAR aumentará considerablente.

(setq *MAX_iteraciones* 8)

Número máximo de iteraciones. En cada iteración ser realizará un tratamiento distinto de la frase (considerar sinónimos, eliminar palabra atípica o considerando los sinónimos a la hora de ver si una regla está o no sensibilizada).

(setq *log* nil)

Señala si se desea crear fichero un fichero de log que servirá para depurar.

o (setq *log-file* "log.txt")

Nombre del fichero donde se mantendrá un registro de las operaciones (diario)

(setq *path_gramatica_ingles* "./gramatica/ingles/")

Directorio relativo a partir de *dir_instalacion*\dypar donde pueden hallarse los ficheros de la gramática inglesa.

(setq *path_gramatica_español* "./gramatica/español/")

Directorio relativo a partir de *dir_instalacion*\dypar donde pueden hallarse los ficheros de la gramática española. No implementada todavía.

(setq *path_wordnet_db* "e:/WN16/dict/")

Directorio donde está la bd donde se instaló wordnet

95


(setq *traza_reglas_disparadas* t)

Muestra las reglas disparadas. Mejor que esta traza es la proporcionada por el propio DYPAR. Para hacer uso de esta última poner a T (true) la siguiente variable (defvar !show-expanded T) que se encontrará en PFC\dypar\xmatch6.lsp.

(setq *fichero_memoria* "memoria.txt")

Fichero donde está almacenando el contenido de la memoria de DYPAR.

Al salir de dypar se almacenará la información "aprendida" en ese mismo fichero.

Datos de conexión con la B.D. donde se buscarán nombres propios de personas, organizaciones y editores.

(setq *database* "iaaadb")

(setq *password_db* "metadata")

(setq *user_db* "metadata")

(setq *dir_instalacion* "e:/pfc")

Directorio raíz a partir del cual se encontrará todo lo necesario para el proyecto. (setq *uri* "http://artieda.cps.unizar.es/wfsGazetteerGns/servlets/GNS?VERSION=0.0.14")

; "*un_lugar" es donde estará el nombre del lugar(setq *uri_query* '(("REQUEST" . "GETFEATURE") ("TYPENAME" . "gns") ("FILTER" ."<Filter> <PropertyIsLike> <PropertyName> name </PropertyName> <Literal> *un_lugar* </Literal> </PropertyIsLike> </Filter>") ("OUTPUTFORMAT" . "GML2") ("MAXFEATURES" . 50) ("INITIALFEATURE" . 1)))

gazetteer = índice geográfico

Dirección de internet donde existe un servidor tal que dada una consulta de este estilo responde con información sobre el lugar solicitado. La url con la que se solicita el lugar <lugar> estará compuesta de:

(setq *MAX_PALABRAS_TEMA* 2)

Número máximo de palabras que se tendrán en cuenta para observar si constituyen un tema.

Por ej. si el usuario escribe ... air quality of Aragon ... y esta constante es 1, nunca se conseguirá reconocer "air quality" como tema. Sí lo logrará si al menos la constante vale 2. A mayor valor más lento, pero reconocerá los temas compuestos de varias palabras.

(setq *MAX_PALABRAS_LUGAR* 2)

Número máximo de palabras que podrán componer el nombre de un lugar:

(setq *MAX_PALABRAS_RECUERDO* 3)

Número máximo de palabras que se considerarán como recuerdo. Esto tiene que ver con la capacidad de reconocer, dentro de la frase del usuario, recuerdos de cosas (temas, lugares, etc) formados por varias palabras. Por ejemplo, en la frase "Give me all maps of Sos del Rey Católico of economy" cuando llegue el turno de analizar "Sos del Rey Católico of economy" mirará consecutivamente si posee un recuerdo en memoria de las 4, 3, 2, 1 primeras palabras. Evidentemente cuanto mayor sea más potencia de reconocimiento pero más lento

96


(setq *SERVIDOR_TEMAS* nil)

¿ Se va a utilizar el servidor de thesaurus (temas) ? Si el servidor está caído se desactivará su uso, independientemente del valor de esta constante.

(setq *MEMORIZAR_TEMAS* T)

¿ Introducir en memoria los tema que se van preguntando al servidor ? No hace falta si el servidor es suficientemente rápido y se dispone de conexión permanente con el mismo.

(setq *SERVIDOR_LUGARES* nil)

¿ Se va a utilizar el servidor de lugares ? Si el servidor está caído no se utilizará, independientemente del valor de esta constante.

(setq *MEMORIZAR_LUGARES* T)

¿ Introducir en memoria los lugares que se van preguntando al servidor ? No hace falta si el servidor es suficientemente rápido y se dispone de conexión permanente con el mismo.

(setq *SERVIDOR_BD* nil)

¿ Se va a utilizar el servidor de b.d. ?

14.11.2 Propiedades JavaSerá necesario cambiar las rutas de las propiedades en cada nueva instalación.

PFC\catServer\ CatServer.properties

Aquí están definidas las propiedades necesarias para el servidor de catálogo, que es el servidor que accederá al catálogo para recuperar información.

o rmi_port=1099 puerto en el que se lanzará el servidor de catálogo.

o rmi_host=localhost indica dónde está lanzado el servidor de catálogo.

o rmi_name=CatServer nombre del servicio RMI con el que será conocido desde el exterior el servidor de catálogo.

Después se encontrará una serie de propiedades que le sirven al propio servidor de catálogo para localizar la base de datos donde se encuentra el catálogo:

o db_catalog_port=1521

o db_catalog_password=MOISES

o db_catalog_user=MOISES

o db_catalog_sid=siguedb

o db_catalog_host=sigues.cps.unizar.es

PFC\ney\IAAACatalog.properties

Este fichero contiene propiedades con las que localizar al servidor de catálogo.

o Si dicho servidor se ha lanzado localmente, entonces la propiedad rmi_host = localhost.

o Fijarse que la propiedad rmi_name ha de coincidir con la correspondiente de PFC\catServer\ CatServer.properties, si dicho servidor de catálogo ha sido lanzado manualmente.

97


o La propiedad rmi_port también ha de coincidir con la propiedad homóloga de PFC\catServer\ CatServer.properties.

PFC\servidor_ior\servidor_ior.properties

o Con la propiedad primary_socket_port se indica el puerto en el que será lanzado el servidor.

o La propiedad primary_socket_host indica la localización del servidor de ficheros IOR, su nombre o dirección IP. En el caso de que el servidor de ficheros IOR se haya lanzado localmente, entonces el valor de esta propiedad será localhost

o path_ior_servidor señala la ruta donde se alojarán los ficheros IOR cuyo contenido va siendo recibido por el servidor.

o path_ior_cliente es una propiedad que contiene la ruta del fichero IOR que utilizará el cliente para recoger el fichero en cuestión y enviarlo al servidor de ficheros IOR.

15 Esfuerzos 15.1 Esfuerzos totales

98


Fig. 24 Evolución en la dedicación de esfuerzos a lo largo del tiempo

El número total de horas para la realización de este proyecto ha sido cercana a 1000.

Se puede apreciar en la gráfica anterior una distribución no uniforme en las horas dedicadas en el transcurso del proyecto. Esto ha sido motivado porque el autor ha compaginado la realización del proyecto con el trabajo. De ahí que la duración del mismo sea también excesiva: en torno a 2 años. Esta larga duración conlleva problemas de seguimiento, concentración y algo de desmotivación.

15.2 Esfuerzos clasificados

99


Fig. 25 Distribución de esfuerzos por categorías

15.3 Esfuerzos detallados

100


Form

ació

n

Bús

qued

a in

form

ació

n

Estu

dio

prev

io

Aná

lisis

-dis

eño

Impl

emen

taci

ón

Con

stru

cció

n gr

amát

ica

Dep

urac

ión

Test

Doc

umen

taci

ón

Reu

nion

es

Otr

os

oct-00 4.15 0.00 13.55 0.00 0.00 0.00 6.00 0.00 0.00 0.00 0.00 24.10nov-00 8.30 0.00 0.00 0.00 0.00 0.00 6.50 0.00 0.00 1.00 0.00 16.20dic-00 2.10 1.30 0.00 0.00 0.00 15.50 0.00 1.40 0.45 0.00 0.00 21.55ene-01 2.00 1.00 0.00 1.00 0.00 30.10 2.00 1.00 0.00 2.00 1.00 40.10feb-01 0.00 0.00 0.00 0.00 0.00 8.30 17.25 0.00 0.00 4.30 1.00 31.25

101


mar-01 9.55 0.30 0.00 1.40 0.00 6.40 3.00 1.00 4.20 2.15 0.00 29.20abr-01 11.50 0.30 0.00 0.00 11.10 6.55 0.35 0.00 0.00 0.00 0.00 31.00may-01 2.30 0.00 0.00 0.00 8.00 34.15 2.40 1.00 4.05 2.00 2.00 56.30jun-01 0.00 0.00 0.00 5.00 0.00 30.30 3.10 1.00 0.00 0.00 0.00 39.40jul-01 2.10 0.00 0.00 4.00 33.00 8.30 7.30 4.50 0.00 0.00 2.00 62.00

ago-01 2.50 0.00 0.00 0.00 11.10 1.10 4.25 3.30 0.00 0.00 0.00 23.05sep-01 10.25 1.45 0.00 5.15 13.40 7.15 18.40 5.00 2.00 0.00 0.00 64.00oct-01 2.50 0.00 0.00 2.20 38.20 24.25 6.55 12.50 4.50 0.00 3.15 95.45nov-01 0.00 0.00 0.00 0.00 6.45 3.30 1.00 4.15 1.25 2.00 22.55 41.50dic-01 4.10 6.30 0.00 0.00 3.30 0.00 10.45 0.00 0.00 4.00 0.00 28.55ene-02 2.30 0.00 0.00 0.00 2.40 0.00 0.00 0.00 0.00 3.00 0.00 8.10feb-02 2.30 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2.30mar-02 3.20 0.00 0.00 1.35 4.50 0.00 0.00 0.00 1.30 0.00 1.10 12.25abr-02 7.25 3.45 0.00 0.00 22.10 2.50 7.25 2.40 2.20 0.45 5.25 54.45may-02 9.15 1.40 0.00 3.50 53.05 5.05 8.30 7.50 0.00 0.15 0.00 89.30jun-02 0.00 0.00 0.00 0.00 1.15 0.00 0.00 1.00 0.00 0.00 0.00 2.15jul-02 4.00 0.00 0.00 0.00 11.15 0.00 2.30 10.25 7.55 0.00 0.20 36.25

ago-02 0.00 7.00 0.00 0.00 27.30 8.10 2.40 12.05 79.30 0.00 23.05 160.00sep-02 0.00 0.00 0.00 0.00 0.15 0.00 0.00 3.40 78.40 0.30 6.15 89.20

92.35 17.10 13.55 24.40 220.50 185.35 109.20 58.00 29.10 21.45 39.05 1061.25

Es de destacar los mayores esfuerzos dedicados en implementación, construcción de la gramática y depuración.

Dentro del esfuerzo “depuración” también está metido el testeo del mismo, así como la incorporación de alguna funcionalidad necesaria.

La mayor parte del esfuerzo de depuración ha sido dedicada a DYPAR, aunque también hay que destacar la depuración de Aserve y XMLutils con el fin de adaptar el código a la versión de Lisp que se ha utilizado. Hay que reconocer que ese esfuerzo de depuración de DYPAR ha sido pesado y no deseable. El hecho de depurar un código viejo, mal documentado y en el que han intervenido numerosas personas hacía esta tarea un tanto ardua. Además personalmente, dedicar demasiado tiempo a depurar en un proyecto final de carrera no es lo más apetecible. El inconveniente de ir modificando DYPAR consistía en que en ocasiones se provocaban nuevos errores en partes que funcionaban previamente de forma correcta. Ésto es bien conocido en la ingeniería del software. Observar la siguiente gráfica, que refleja los fallos del software con el transcurso del tiempo conforme se van realizando cambios en el mismo:

102


Fig. 26 Errores en el software con respecto a las modificaciones

También es cierto, que alguno problemas eran atribuídos a un mal funcionamiento de DYPAR pero en realidad era la gramática la que estaba incorrecta. Este es otro problema añadido al trabajar con un software no suficientemente verificado.

El esfuerzo “otros” engloba conceptos tales como configuración de aplicaciones, instalación de software, compilaciones, etc.

El esfuerzo “reuniones” recoge las reuniones con el director de proyecto y con otras personas que han contribuido con su ayuda al desarrollo del mismo.

103


16 Posibilidades de futuro

Permitir al usuario la utilización del lenguaje oral para la realización de consultas. Esto sería posible partiendo de las herramientas ya existentes e intentando integrarlas en el interfaz del usuario. Reconocedores de voz comoVia Voice o Dragon Naturally Speaking podrían suponer el punto de partida, sin necesidad de un desarrollo comenzando desde cero.

Posibilitar generar automáticamente una gramática basada en un dominio y aprovecharse de la base gramatical desarrollada manualmente en este proyecto. En este sentido ya ha sido realizado con éxito un proyecto final de carrera por Nuria Ripoll Lerín que va encaminado en este sentido. El siguiente paso sería combinar ambos proyectos.

Aumentar las posibilidades de autoaprendizaje. Quizás sea este el aspecto más importante, porque permitiría enriquecerse de conocimiento sin más ayuda que la experiencia, tal y como todos hemos aprendido desde niños.

Gramática en español.

Aumentar la flexibilidad y complejidad de la gramática base.

Hacer un uso extensivo de las fuentes de información proporcionadas por internet. Internet supone, en mi opinión, una gran oportunidad a la hora de conseguir gran cantidad de información de forma rápida y fiable. Este proyecto ha explotado sólo una pequeñísima parte de la potencialidad de internet (búsqueda de lugares, temas y nombres propios). Además tendría la gran ventaja de poseer un conocimiento distribuido que va actualizándose con asiduidad.

DYPAR podría mejorarse, no sólo en la organización del código, sino en determinados comportamientos. Por ejemplo, podría habilitarse el procesamiento concurrente por varias ramas, en vez de secuencialmente como hasta ahora. El uso de probabilidades podría ser también un factor a considerar a la hora de seleccionar la rama.

Búsqueda en anchura, además de la búsqueda en profundidad.

Conseguir su funcionamiento en un navegador de páginas web.

Habría que decidir cuándo reintentar comunicarse con una fuente externa que ha sido deshabilitada debido a un fallo en la comunicación.

17 Conclusiones

104


17.1 Desarrollo del proyectoLas conclusiones de desarrollo extraídas tras la realización del presente proyecto final de carrera son la siguientes:

El estudio previo es importante con el fin de elegir las herramientas apropiadas al problema que se intenta resolver.

En esa fase previa también es importante hacer un estudio del software existente para evitar reinventar la rueda.

Debe hacerse un control de versiones sistemático y bien definido desde el principio. Así como definir la estructura de directorios que se va a seguir.

Es fundamental dedicar el tiempo suficiente a las fases de análisis y diseño para no tener que echar marcha atrás una vez que se está implementando.

La continuidad en el desarrollo evita perder el hilo, y por lo tanto, no se hace necesario un tiempo de adaptación para retomar el trabajo realizado hasta ese momento.

Es interesante contrastar opiniones con otra persona para darse cuenta de si las ideas son o no buenas, si se pueden mejorar, etc.

Llevar al día la documentación que se va generando del proyecto facilita su revisión posterior por el propio desarrollador así como por terceras partes. Esto también es útil para no olvidar puntos o decisiones importantes tomadas.

La utilización de distintos lenguajes para el desarrollo de un proyecto hace posible usar cada uno de ellos para la parte que mejor se adapte. Sin embargo, se complica el proceso de comunicación entre los mismos. Pese a ello, las ventajas obtenidas del uso de varios lenguajes para el desarrollo de una aplicación compensan.

17.2 Procesamiento computacional del lenguaje naturalTras la realización de este proyecto se advierte la gran dificultad que entraña el procesamiento de lenguaje natural. Éste es demasiado flexible y rico como para conseguir con una gramática entender todas las consultas posibles.

La estructuración de la gramática tampoco es tarea fácil, es necesario conseguir un compromiso entre el tiempo de proceso, complejidad, versatilidad, etc.

Quizás estemos siendo víctimas de la TNR (“trampa de los números romanos”) e intentamos construir algo que con los métodos y herramientas actuales apenas sea factible avanzar en este campo. Como siempre el tiempo nos descubrirá si estábamos en el camino correcto.

18 Definiciones

18.1 AODBCEl interfaz ODBC (Open DataBase Conectivity) para Allegro permite a los usuarios acceder a las bases de datos. AODBC usa el SQL (Structured Query Languaje) para implementar dicho

105


interfaz, que debería trabajar por lo tanto con cualquier base de datos que utilice SQL, pero sólo ha sido probada para los siguientes sistemas gestores de bases de datos relacionales (RDBMS): Oracle, Sybase, Informix, Ingres, Microsoft Access, Microsoft SQL Server.

El interfaz está diseñado para satisfacer a los clientes en dos niveles distintos:

Bajo nivel: consultas SQL escritas como cadenas Lisp.

Para aquellos usuarios familiarizados con el lenguaje SQL, el interfaz provee funciones para ejecutar comandos como se harían directamente desde el más alto nivel de un sistema gestor de bases de datos. Así, existe una función execute-sql que recibirá como argumento la cadena SQL que queremos lanzar contra la base de datos.

Nivel medio: expresiones SQL simbólicas escritas en Lisp.

También se ofrece un interfaz a nivel medio, SQL simbólico, que permite a los programadores emplear un estilo Lisp más intuitivo para realizar las operaciones sobre la base de datos. Permite utilizar tanto las funciones básicas del SQL DDL (Data Definition Languaje) como las de DML (Data Manipulation Languaje), así como funciones de control de transacciones, iteración y soporte de errores y mensajes.

18.2 AppletEs un programa de Java que se ejecuta en el contexto de un navegador, y se lanza desde un documento web, donde se encuentra incrustado. Cuando el usuario de un navegador accede a una página web con un applet, éste se descarga desde el servidor de páginas web hacia el navegador del usuario, que es donde se ejecutará.

Se ha desarrollado un applet en este proyecto que sirve de interfaz gráfico y funcional entre el usuario y el resto del sitema.

18.3 CLOS(Common Lisp Object System). Es una extensión del estándar Common Lisp que incluye aspectos del paradigma de POO (Programación Orientada a Obejtos).

CLOS no fuerza la utilización de un estilo orientado a objeto.

Integración de la programación funcional y la programación orientada a objeto.

18.4 CORBA18.4.1 CORBACommon Object Request Broker Architecture es una arquitectura estándar. Permite que un conjunto heterogéneo de objetos distribuidos operen entre ellos. En este proyecto CORBA posibilita la invocación remota entre Lisp y Java.

Corba es independiente de la plataforma y del lenguaje de desarrollo, lo que facilita el desarrollo en entornos heterogéneos. Gestiona las comunicaciones, informando a clientes y servidores de caídas de los canales de comunicación.

106


18.4.2 IOREl IOR (Interoperable Object Reference) posee la información necesaria sobre dónde está el servidor y cómo contactar con él. Un IOR es una simple cadena codificada que contine cosas como la dirección IP, el número de puerto, y cualquier otra información necesaria para conectar con el servidor. Dicha cadena ocupa 238 Bytes.

El servidor ha de publicar cuál es su IOR para que los cliente sepan dónde está y pueden comunicarse con él.

Ejemplo del contenido de un IOR:IOR:005858580000002649444C3A636861745F64797061725F6170706C65742F43686174536572766572493A312E3000585800000001000000000000003900010058000000074D4154524958005804895858000000214F52424C696E6B3A3A4D41545249583A313136313A3A736B656C65746F6E202330

Para que un cliente pueda realizar una invocación sobre un objeto, debe tener una referencia del objeto

18.4.3 ORBEl ORB (Object Request Broker), que es el encargado de gestionar las peticiones entre clientes y servidores. Localiza los objetos implicados, transmite la petición y devuelve los resultados correspondientes. Todo ello usando el IIOP (Internet Inter-ORB Protocol), capa superior del TCP/IP, mediante el cual distribuye su información a través de la red.

El ORB implementa la transparencia de ubicación. El cliente y el objeto CORBA utilizan exactamente el mismo mecanismo de petición sin importar en dónde está ubicado el objeto. El cliente no notará la diferencia.

El ORB hace las traducciones que sean necesarias entre los lenguajes de programación. Para casi todos los lenguajes de programación populares de han definido enlaces entre el lenguaje y CORBA (Language bindings).

18.4.4 IDLEl IDL (Interface Description Language) de CORBA se utiliza para especificar los interfaces de los componentes.

Los IDL son puramente declarativos. No ofrecen detalles de la implementación:

Los métodos especificados en un IDL pueden estar escritos en cualquier lenguaje (Java, Lisp, C++, Ada, Cobol, Smalltalk, etc).

Los programadores tratan con los objetos CORBA utilizando su lenguaje nativo.

Los objetos clientes y servidores pueden interoperar aunque esté escritos en diferentes lenguajes.

Fig. 27 Esquema del funcionamiento de CORBA

107


18.5 DYPARDYPAR es un intérprete de lenguaje natural basado en reglas.

El objetivo primordial de DYPAR es servir como herramienta de programación de alto nivel haciendo posible la realización sencilla de gramáticas orientadas a una aplicación específica.

El funcionamiento de DYPAR se divide en dos partes:

1. Una primera parte que se encarga de leer y compilar las gramáticas escritas.

2. Otra parte utiliza las gramáticas para entender las frases de los usuarios y ejecutar las acciones asociadas con cada una de esas frases.

DYPAR utiliza estrategias de recursividad en la correspondencia de patrones, interpretación de gramática semántica y transformación de cadenas. Esta combinación produce un potente mecanismo que otros métodos no proveen por separado.

DYPAR toma los patrones provistos en la gramática e intenta hacerlos corresponder con la entrada del usuario.

No se permite usar recursividad a izquierda en los patrones.

DYPAR fue desarrollado inicialmente por la universidad de Carnegie-Mellon. Sin embargo, a lo largo del tiempo ha ido siendo modificado y ampliado por diversas personas u organismos. Cabe destacar la aportación del Centro Nacional de Inteligencia Artificial (CNIA) de Rank Xerox España S.A. y el Banco Español de Crédito (BANESTO), así como la colaboración desde el ámbito universitario.

18.6 HILO (THREAD)También se le denomina proceso ligero. Hilo es a proceso como proceso es a máquina.

Un hilo se puede ver como un miniproceso que comparte el mismo espacio de direcciones, el mismo conjunto de archivos abiertos, procesos hijos, cronómetros, señales, etc. que el resto de hilos creados del proceso. Al compartir el mismo espacio de direcciones comparten las mismas variables globales. Los hilos se inventaron para permitir la combinación del paralelismo con la ejecución secuencial y el bloqueo de las llamadas al sistema.

18.7 HTTPHyperText Transfer Protocol es el protocolo que constituye la base de la World Wide Web.

108

JAVA LISP C C++ JAVA LISP C C++

IDL (Interface Description Language)

CLIENTE SERVIDOR

O R B (Object Request Broker)


18.8 PLN o NLPProcesamiento del Lenguaje Natural

18.9 RMILas aplicaciones RMI normalmente comprenden dos programas separados: un servidor y un cliente. Una aplicación servidor típica crea un montón de objetos remotos, hace accesibles unas referencias a dichos objetos remotos, y espera a que los clientes llamen a estos métodos u objetos remotos. Una aplicación cliente típica obtiene una referencia remota de uno o más objetos remotos en el servidor y llama a sus métodos. RMI proporciona el mecanismo por el que se comunican y se pasan información del cliente al servidor y viceversa. Cuando es una aplicación algunas veces nos referimos a ella como Aplicación de Objetos Distribuidos.

Las aplicaciones de objetos distribuidos necesitan.

Localizar Objetos Remotos

Las aplicaciones pueden utilizar uno de los dos mecanismos para obtener referencias a objetos remotos. Puede registrar sus objetos remotos con la facilidad de nombrado de RMI rmiregistry. O puede pasar y devolver referencias de objetos remotos como parte de su operación normal.

Comunicar con Objetos Remotos

Los detalles de la comunicación entre objetos remotos son manejados por el RMI; para el programador, la comunicación remota se parecerá a una llámada estándard a un método Java.

Cargar Bytecodes para objetos que son enviados.

Como RMI permite al llamador pasar objetos Java a objetos remotos, RMI proporciona el mecanismo necesario para cargar el código del objeto, así como la transmisión de sus datos.

La siguiente ilustración muestra una aplicación RMI distribuida que utiliza el registro para obtener referencias a objetos remotos. El servidor llama al registro para asociar un nombre con un objeto remoto. El cliente busca el objeto remoto por su nombre en el registro del servidor y luego llama a un método. Esta ilustración también muestra que el sistema RMI utiliza una servidor Web existente para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor, para los objetos que necesita.

Fig. 27 Esquema del funcionamiento de RMI

El sistema RMI utiliza un servidor Web para cargar los bytecodes de la clase Java, desde el servidor al cliente y desde el cliente al servidor.

109


18.10 SIG (GIS)Sisteme de Información Geográfica

18.11 SocketsPermiten a las aplicaciones manejar el trabajo en redes como si fuera E/S de archivos: un programa puede leer de un socket o escribir en un socket tan fácilmente como lee o escribe de un archivo. De este modo se oculta gran parte de la complejidad de la programación de red de la vista del programador.

18.12 SQLStructured Query Language

18.13 WordnetWordNet es una base de datos que contiene una red semántica del inglés y ha sido desarrollada por George Miller y su grupo de investigación en la Universidad de Princeton (Miller et al. 1993). Está diseñada utilizando un modelo semántico relacional y una base de datos también relacional y ha sido elaborada desde el punto de vista de la Psicolingüística. Está considerada como la red semántica del inglés (o de cualquier otra lengua) más completa que existe.

Wordnet básicamente es un diccionario inglés cuyos términos están relacionados mediante referencias. Los términos de este diccionario están organizados en conjuntos de sinónimos, antónimos, hipónimos y merónimos.

En este proyecto wordnet se utiliza para identificar los sinónimos de las palabras.

18.14 XMLXML, es el estandar de Extensible Markup Language. XML no es más que un conjunto de reglas para definir etiquetas semánticas que organizan un documento en diferentes partes. XML es un metalenguaje que define la sintaxis utilizada para definir otros lenguajes de etiquetas estructurados.

En primer lugar para entenderlo bien hay que olvidarse un poco, sólo un poco de HTML. En teoría HTML es un subconjunto de XML especializado en presentación de documentos para la Web, mientras que XML es un subconjunto de SGML especializado en la gestión de información para la Web. En la práctica XML contiene a HTML aunque no en su totalidad. La definición de HTML contenido totalmente dentro de XML y por lo tanto que cumple a rajatabla la especificación SGML es XHTML (Extensible, Hypertext Markup Language).

XML fue creado al amparo del Word Wide Web Consortium (W3C) organismo que vela por el desarrollo de WWW partiendo de las amplias especificaciones de SGML.

Su desarrollo se comenzó en 1996 y la primera versión salió a la luz el 10 de febrero de 1998.

Respecto a sus objetivos son:

XML debe ser directamente utilizable sobre Internet.

110


XML debe soportar una amplia variedad de aplicaciones.

XML debe ser compatible con SGML.

Debe ser fácil la escritura de programas que procesen documentos XML.

El número de características opcionales en XML debe ser absolutamente mínima, idealmente cero.

Los documentos XML deben ser legibles por humanos y razonablemente claros.

El diseño de XML debe ser preparado rápidamente.

El diseño de XML debe ser formal y conciso.

Los documentos XML deben ser fácilmente creables.

La concisión en las marcas XML es de mínima importancia

19 Información de contacto

Autor del proyecto final de carrera:

Moisés Gil Soldevilla

[email protected]

111

mailto:[email protected]


Director del proyecto final de carrera:

José Ángel Bañares Bañares

Departamento de Informática e Ingeniería de Sistemas [email protected]

Proyecto final de carrera relacionado:

Nuria Ripoll Lerín

[email protected]

20 Bibliografía

112




20.1 Bibliografía informativa acerca del procesamiento del lenguaje natural

1. Artículo de Sergio Balari Ravera (Profesor titular de Lingüística general en la Universitat Autònoma de Barcelona) resumiendo «Report de recerca del Grup de Gramàtica Teòrica de la UAB Nº GGT-00-11» en http://ggt.uab.es/.

2. www.monografias.com

3. START: http://www.ai.mit.edu/projects/infolab

4. http://delta.cs.cinvestav.mx/~schapa/red/intro_lm/node58.html

5. http://www.ia.uned.es/~jgb/docencia/intro-ia/libros/materia.html

20.2 Bibliografía para el procesamiento computacional del lenguaje natural

1. Interpretación de lenguaje natural para la comunicación con una base de datos DB2 utilizando el analizador DYPAR-PC.

Proyecto de colaboración entre el Centro Nacional de Inteligencia Artificial (CNIA) de Rank Xerox España S.A. y el Banco Español de Crédito (BANESTO).

2. DYPAR-I: Tutorial and Reference Manual. Department of Compter Science Canegie-Mellon University.

3. Introduction to WordNet: An on-line Lexical Database.

George A. Miller, Richard Beckwith, Christiane Fellbaum, derek Gross and

Katherine Miller

4. Natural language understanding

James Allen, 2nd ed.

The Benjamin/Cummings Publishing Company, Inc.

5. Inteligencia Artificial. Un enfoque moderno.

Stuart Russell & Peter Norvig

Prentice Hall

20.3 Bibliografía técnica para la implementación1. Lisp

113

http://www.ia.uned.es/~jgb/docencia/intro-ia/libros/materia.html

http://delta.cs.cinvestav.mx/~schapa/red/intro_lm/node58.html

http://www.ai.mit.edu/projects/infolab

http://www.monografias.com/

http://ggt.uab.es/


Patrick Henry Winston & Berthold Klaus Paul Horn

3ª edición. Addison-Wesley Iberoamericana

2. Cómo programar en Java

Deitel y Deitel

Prentice Hall

3. Compiladores. Principios, técnicas y herramientas.

Alfred V. Aho & Ravi Sethi & Jeffrey D. Ullman

Addison-Wesley Iberoamericana

4. Sistemas operativos distribuidos

Andrew S. Tanembaum

Prentice Hall

5. http://programacion.com/java/tutorial.rmi.2.html

20.4 Bibliografía complementaria

1. Información sobre Wordnet:

http://elies.rediris.es/elies2/cap332.htm

2. Descarga de Wordnet:


3. XMLutils

Fuentes: http://opensource.franz.com/xmlutils/index.html

4. aserve

Información sobre aserve: http://opensource.franz.com/aserve/

Fuentes: ftp://ftp.franz.com/pub/aserve/

5. Un chatbot (Alice)

Alice fue creada por Richard Wallace en 1995 bajo licencia pública GNU y actualmente hay más de 350 personas de todo el mundo colaborando en su desarrollo. Ganó el premio Loebner (un test de Turing en el que robots de charla compiten por "engañar" a un jurado haciéndose pasar por humanos) en sus dos últimas ediciones, 2000 y 2001.

http://alice.sunlitsurf.com/

6. Información sobre frases y atributos posibles a los que un usuario podría hacer referencia. Sirve un poco de mini corpus para hacerse una idea de frases tipo.

http://geology.usgs.gov/tools/metadata/standard/01.html

http://geology.usgs.gov/tools/metadata/tools/doc/plain.faq.html

114

http://geology.usgs.gov/tools/metadata/tools/doc/plain.faq.html

http://geology.usgs.gov/tools/metadata/standard/01.html

http://alice.sunlitsurf.com/

ftp://ftp.franz.com/pub/aserve/

http://opensource.franz.com/aserve/

http://opensource.franz.com/xmlutils/index.html


http://elies.rediris.es/elies2/cap332.htm

http://programacion.com/java/tutorial.rmi.2.html


115

Documents

Implantación del sistema cliente-servidorwebdiis.unizar.es/asignaturas/ISBC/isbc/PLN/memoria.doc · Web viewProblemas encontrados en el ... 14.4 Pasos a seguir para la ejecución