Análisis del procesador de lenguaje natural

Se analizará en este apartado las estructuras de memoria y cómo se almacenan y se cargan, quedando el funcionamiento de interpretación y generación fuera de las competencias de este proyecto. Este componente utiliza las mismas estructuras de conocimiento tanto para interpretar como para generar, esto agiliza las necesidades en cuanto a carga de información se requiere.

Esta estructura en memoria se basa en una colección de patrones, cada uno de los cuales tiene asociado un conjunto de actos comunicativos en el formato en el cual se almacenan en la base de datos. Este formato (ver apartado 4.3.3) podría no ser el más adecuado, ya que con una correcta gestión se podría evitar el uso de las categorías ya que el orden de éstas para un determinado acto comunicativo identifica cada una de ellas. En un futuro se podrá realizar una integración completa.

En primer lugar, la clase más importante en cuanto a integración se refiere es TextNLP la cual contiene los “templates” que identifica cada patrón junto con su

conjunto de actos comunicativos. Esta clase pues contiene el siguiente método que se utiliza constantemente por cada patrón que se carga:

Un template está compuesto por objetos de tipo ExpressionPattern y de CAPattern y un template corresponde a un patrón editado para una expresión. La clase ExpressionPattern es una interfaz para abstraer todos los elementos de los que puede constar un patrón. A continuación se presentará la correspondencia entre los elementos en el procesador de lenguaje natural que implementan la interfaz ExpressionPattern y los elementos de la base de datos:

 LeafPattern: Referencia a los terminales de las gramáticas, es decir, las palabras. Contiene un String que representa dichas palabras.

 JokerPattern: Corresponde a los comodines de la gramática. Se ha modificado esta clase para que acepte comodines (en forma de expresiones regulares) infinitos o definidos, por tanto se dispondrá de comodines sin determinar (“.*”) y de comodines determinados ("([\\w]+  +){"+  min  + "," + max+"}").

 NodePattern: Guarda relación con un patrón o sub-patrón. Contiene a su vez una colección de ExpressionPattern. Para este elemento han de encajar todos sus elementos, no existe variabilidad en ellos.

 AdvanceNodePattern: Se corresponde con un token. Contiene un array de dos dimensiones de objetos ExpressionPattern. La primera dimensión corresponde con los elementos que han de encajar como si de un objeto NodePattern se tratase. La segunda dimensión especifica las posibilidades que pueda tomar la primera. Por tanto serían las diferentes descripciones de un token.

 VariablePattern: Identifica los elementos variables editados. Contiene los mismos datos que un objeto de tipo LeafPattern pero el tratamiento de cara a la interpretación y generación es muy distinta ya que ha de encajar con las variables de la expresión o las variables de los actos comunicativos.

Una vez cargada la información anterior, se obtendrá el intérprete (o el generador según lo que se requiera) y se invocará al método expression2Ca de la clase intérprete que devolverá una lista de objetos CommunicativeAct que es la representación del motor de los actos comunicativos.

Por tanto el trabajo de este proyecto consiste en insertar en la estructura comentada anteriormente el conocimiento que se encuentre en la base de datos y hacer que el motor infiera sobre este. Por otro lado, el motor devuelve el CommunicativeAct en el cual están presentes pares categoría-valor. Existen valores modificados (si hay variables, serán sustituidas por el valor de esa variable en la expresión), y por tanto, es necesario cotejar el acto comunicativo obtenido con la base de datos.

5.2.3.2 NLPDriver y CAIntermediateRepresentation. 

Estas son las clases implementadas para permitir la integración del motor de inferencia en el sistema. NLPDriver contiene una instancia de TextNLP y contiene tres métodos públicos: loadPatterns(), interpret() y cleanData(). El primero realiza la carga de información en las estructuras comentadas en el apartado anterior, se compone de dos métodos: loadPattern() y loadToken(). Si un elemento dentro de una edición es sub- patrón, será necesaria realizar llamadas recursivas a estos dos métodos. El segundo realiza la interpretación e intenta localizar el acto comunicativo y el tercero crea una nueva instancia de TextNLP realizando una llamada posterior al recolector de basura (System.gc()).

Es necesario incluir una gestión de actos comunicativos intermedia, ya que no existe asociación entre las variables editadas y las DPInstances del patrón. Por tanto, a medida que se cargan los patrones, se va modificando esta representación intermedia que contiene además del tipo una colección de parámetros variables (_variables) y una colección de parámetros constantes (_constants).

Al inicio de la carga se crea tantas instancias de CAIntermediateRepresentation como instancias de actos comunicativos tenga el patrón y todos sus parámetros constan en la lista de constantes (_constants). A medida que se va cargando los patrones y se van encontrando elementos de tipo variable, la categoría que contenga dicha variable será copiada en la colección de variables (_variables).

Una vez realizada la carga del patrón en las estructuras del NLP, este acto comunicativo intermedio contiene la estructura que necesita la clase CAPattern para crear un template, como se vio en el apartado anterior.

5.2.4 Modelo 

El paquete modelo contiene la conexión a la base de datos y los mecanismos para acceder y almacenar todos los elementos de los que se compone el sistema. Para ello contiene cuatro componentes básicos: el componente de conexión, indispensable, y los tres componentes de datos agrupados según la parte de la base de datos utilizan para así permitir utilizarlos de manera independiente en diferentes herramientas.