Análisis textual automático: el proyecto BiblioTECA

Jaime Sarabia Alvarez-Ude.
Verba Logica.
Departamento de Lógica.Universidad Complutense de Madrid.

Indice

  1. Resumen
  2. Introducción
  3. Problemas a resolver
  4. Estructura e información
  5. BiblioTECA: Un sistema de análisis documental automático
  6. Dos ejemplos
  7. Análisis composicional automático (AFCA)

Abstract

The paper presents results obtained in the BiblioTECA (BIBLIOgraphic TExts Compositional Analysis) project, a European Union co-funded project of the Libraries Program (Telematics) (**). During the project -January '94 / December '95- a set of tools for automatic text analysis was developed having as intended main application the automatic analysis of library secondary information (bibliographic cards, catalogues, etc). It is clear now that the same techniques and tools are appropiate also to analyse information determined by the structural properties of other kind of documents. The paper deals mainly with the AFCA (Automatic Field Compositional Analisys) module in BiblioTECA. AFCA consists on a Windows interface taking care of document and analysis output management and a logic programming based parser generator which yields parsers for classes of documents from its description in a very high level dedicated language (LENDEX) also developed in the project. AFCA techniques have been used intensively in the actual analysis of some kinds of library documents

Introducción

Los objetivos del proyecto(**)

El objetivo central original de BiblioTECA es el desarrollo de instrumentos que permitieran analizar de manera sencilla la estructura de documentos de referencia existentes en bibliotecas y centros de documentación de forma que pudieran ser (re)utilizados en el ámbito de los centros informatizados. El resultado final es más general dato que las herramientas desarrolladas tienen una aplicación más amplia: el tipo de estructura subyacente en los documentos de referencia no es en modo alguno único, y por tanto métodos de análisis desarrollados usarse más allá de la aplicación inicial.

El proyecto ha sido desarrollado desde enero 1994 a diciembre 1995 por un consorcio formado por el grupo Verba Logica (Dto. de Lógica. UCM, socio principal), Matra Caps Systèmes (Paris) , Unidad de Coordinación del Bibliotecas -CSIC (Madrid), Instituto Cervantes (Alcalá de Henares), Biblioteca Nazionale Vittorio Emmanuele III (Nápoles).

El presente texto (1) está centrado en la presentación del módulo AFCA (Automatic Field Compositional Analysis) desarrollado por la Dra. Carmen López Rincón y el autor en el grupo Verba Logica. Se trata de presentar el núcleo central de un sistema de análisis textual automático que está siendo usado en la actualidad en condiciones de aplicación real.

Precedentes

El origen de AFCA fue el intento de generalizar el conjunto de instrumentos desarrollados en los años precedentes por Verba Logica, centrados en el análisis automático de fichas de biblioteca. Estos instrumentos están basados en la aplicación intensiva de técnicas de programación lógica, particularmente metaprogramación sobre gramáticas de cláusulas definidasy otros desarrollos. Los planteamientos previos han sido unificados, reformulados, generalizados e incorporados en un sistema unitario de análisis automático de textos (2).

Por otro lado la experiencia ha mostrado la necesidad de disponer de sistemas optimizados para lograr un lectura automática eficaz. Ese ha sido el motivo de incorporar en el proyecto un módulo de lectura automática de documentos, desarrollado por Matra Caps Systèmes.

El objeto: documentos estructurados

Valga como documento cualquier texto escrito. El concepto general de estructura (subyacente) que usamos en BiblioTECA sería el de una clase de árboles cuyos nodos son pares <atributo,valor> donde el atributo es una etiqueta y el valor es una secuencia de lexemas o un árbol. El origen del árbol tiene como atributo 'documento' y como valor el árbol. Las hojas del mismo tienen como valor secuencias de lexemas o el resultado de ciertas funcions sobre secuencias de lexemas. Ciertamente esto es extremadamente general, pero alude a lo que tiene en común cualquier proceso de análisis desarrollado mediante AFCA. Una definición más precisa, pero restringida a una clase de documentos, se obtiene a partir de la descripción de los mismos en términos de lo que llamamos gramática LENDEX para la clase de documentos. Para un documento en concreto su estructura viene dada por el árbol de análisis del mismo que la correspondiente gramática genera

Para centrar ideas podemos señalar clases de documentos en que hemos centrado nuestro trabajo. En general se trata de textos en que a la información del documento expresada en (hasta cierto punto) un lenguaje natural se superpone de manera más o menos explícita una superestructura de campos generada por el uso de un código propio. Casi cualquier texto responde a esta descripción, es cierto. Esta comunicación misma tiene una estructura de títulos y subtítulos que indica una estructura de campos en el sentido antedicho. Es un hecho que los textos presentan habitualmente una estructura del tipo aludido y por ello mismo son susceptibles del tipo de análisis que hemos desarrollado. Las diferencias en explicitación de la estructura, con ser de grado, no son menos importantes: como diremos luego, en las clases de documentos que nos interesan primordialmente la superestructura del texto determina de manera notable el contenido informativo de los segmentos en lenguaje natural que en ellos aparecen.

Ejemplos de las clases de documentos que primordialmente consideramos: fichas bibliográficas, catálogos, índices analíticos o de autores, bibliografías, índices de contenido, sumarios de revistas, facturas, horarios (de programas de televisión, por ejemplo), entradas de diccionarios y otras obras de referencia, anuncios por palabras, resoluciones en diarios oficiales, etc. Es sobre clases de documentos así, particulamente los que contienen información de segundo orden (información acerca de otros documentos) en las que se centra BiblioTECA y esta presentación.

Problemas a resolver

Las clases de documentos a que hemos aludido suelen ser resultado de una elaboración previa de la información y la finalidad primaria del proyecto BiblioTECA era hacer accesible este pre-procesamiento de la información, particularmente importante cuando se trata de traspasar la información desde el soporte papel a soporte magnético, con el fin de su uso ulterior en sistemas informáticos. Ello implica dos ámbitos de problemas, traspaso de soporte y análisis de la información. Sólo del segundo nos ocuparemos aquí in extenso.

Traducción de soporte

El problema se plantea cuando se quiere trabajar con documentos sobre papel. Es necesario entonces, en primer lugar, o bien realizar un proceso de lectura automática (O.C.R) o bien la grabación manual de los datos. El producto de esta transformación primaria es un texto en ASCII. Es de notar que la lectura automática es aplicable muy limitadamente en la situación actual y en cualquier caso introduce una notable cantidad de ruido que ha de ser eliminado en el análisis posterior de la información. Con el fin de minimizar estos problemas en BiblioTECA se ha intentado una integración de un sistema de lectura automática desarrollado por Matra Caps Systèmes.

Procesamiento (de la información) de los documentos

Subyace a lo que sigue la idea de que la traducción es quizá el objetivo más general del procesamiento de la información documental. Al menos, que un momento de traducción parece inevitable. Desde ese punto de vista BiblioTECA es un sistema de traducción automática, aunque no un sistema de traducción automática desde / hacia un lenguaje natural.

En los documentos que nos interesan existe, como hemos dicho, una superestructura documental que determina parcialmente la información del documento. Esta superestructura es producto de la aplicación de un cierto código. Reconocer la información del documento supone por tanto el conocimiento del código relevante y el modo de su aplicación al documento concreto. Pero el proceso de reconocimiento de la información, en la medida en que se lleva a efecto, implica una representación de esa información (no cabe una información pura sin algo que la soporte!). En nuestro planteamiento la información del documento es representable como un árbol con nodos etiquetados. Es esta (representación de la) información lo que hay que traducir. La fase final de la traducción puede entenderse como una función que proyecta ese árbol en otro que expresa la misma información de acuerdo con otro código diferente. Esta proyección puede considerarse en ciertos casos como la generación de un documento con una estructura diferente. Distinguimos así dos momentos en el procesamiento: análisis de la información y proyección.

El análisis del documento tiene como resultado un árbol de análisis, una representación de su información en la forma antedicha. En BiblioTECA, aunque no en las aplicaciones concretas en que se aplica la metodología desarrollada en el proyecto, el momento de proyección consiste simplemente en la representación del árbol en una interlingua apropiada. De esta forma el centro de interés es el análisis y es la fase que estudiaremos más de cerca en lo que sigue.

Análisis

El objetivo primordial del mismo es reconocer la superestructura de los documentos de una clase. En el caso que nos interesa aquí, el análisis automático, se precisan para ello operaciones que involucran al menos:

  1. Disponer de un modelo de sistema de análisis (parser) apropiado. Esto involucra
  2. Que la representación del código sea efectivamente utilizable como sistema analizador: los problemas de búsqueda de soluciones apropiadas, capacidad deductiva, gasto en tiempo / memoria, etc. son relevantes aquí.
  3. Particularmente importante es el uso de sistemas de representación y deducción gramatical que toleren las inevitables fluctuaciones en la aplicación del código (es totalmente necesario atender a la actuación y no sólo a la competencia) . Esto conlleva también contar con sistemas de análisis que atiendan a la posibilidad de subtextos no analizables por el sistema o de segmentos necesarios no existentes: se trata de violaciones del código que sin embargo son aceptables (y corregibles, con frecuencia) por un lector humano.
  4. La representación de conocimientos de sentido común (¿qué es un sangrado en textos escritos a máquina por diferentes personas?).
  5. La deducción de información implícita en el documento original, a menudo con utilización de conocimientos no contenidos en el código ( Si el libro se publicó en Paris, ¿el país en que se publicó es Texas (EEUU) o Francia?) ¿En qué idioma está escrito el libro?).

Proyección

El análisis de la información rinde un árbol de análisis. Como hemos dicho, la traducción proyecta este árbol en un documento en que es reconocible, potencialmente, un árbol de análisis distinto.Obviamente, en la proyección debe mantenerse algo constante: la información de los documentos de partida y llegada debe ser la misma. Pensamos que normalmente esta proyección ha de realizarse en dos fases: generación de un árbol de llegada consistente en una transformación del árbol de análisis y generación del documento final. Ninguno de los dos es, sin embargo, imprescindible. El interés de la transformación en dos pasos estriba en que los momentos intermedios suponen representaciones del contenido informativo de los documentos más apropiadas para su procesamiento automático, permitiendo a quien construye el sistema de traducción mayor flexibilidad, mientras que los documentos finales están pensados para usuarios (mecánicos o no) distintos.

Es claro que el árbol de análisis es ya una representación de la información de acuerdo, normalmente, con un código diferente al del documento original. Por tanto constituye ya, por sí misma, una traducción. Esto es algo general: si por ejemplo, aplicamos una gramática de cláusulas definidas sobre una cadena de forma que la gramática analice la oración, la salida de la gramática es una representación de la información de la cadena. Desde ese punto de vista el resultado del análisis es ya una traducción. Y por ello en ocasiones la función de proyección es la identidad. De manera similar, y por considerar los casos límite, la traducción puede consistir simplemente en la generación del documento original.

Respecto a los demás casos apuntaremos sólo, por el momento, que la proyección puede ser trivial (por ejemplo la que lleva desde una representación de un registro bibliográfico en formato UKMARC mediante hechos PROLOG a otra en que ese mismo árbol aparece de acuerdo con la norma ISO 2079 de transmisión de datos, o la que presenta BiblioTECA desde la representación en áreas hasta el formato SGML) o compleja: la que lleva desde un árbol de análisis que representa la información de una ficha en formato ISBD a la representación de su información en el formato UKMARC).

Entre los tipos de conocimiento involucrados en esta operación apuntaremos los siguiente:

  1. Obviamente el conocimiento del código de llegada y su representación.
  2. En general, la transformación de subárboles y/o la supresión de los mismos. Operaciones de este tipo pueden ser :

a) el movimiento de un subárbol del árbol de partida a un lugar distinto del árbol de llegada.

b) la supresión de un subárbol: caso de nodos etiquetados irrelevantes informativamente desde el punto de vista del código de llegada, por ejemplo el sistema de marcadores del código original o las cadenas vacías de contenido desde el punto de vista del código de llegada.

Estructura e información

Los documentos en que hemos centrado nuestra atención tienen peculiaridades lingüísticas interesantes: Quizá la más llamativa sea la determinación contextual (a través de lo que hemos llamado superestructura documental ) de la información de los textos en lenguaje natural que aparecen en ellos. Aludimos al hecho de que, por ejemplo, la cadena 41345345 queda determinada como precio o número de teléfono por el lugar que ocupa en la estructura del documento.

a) Existe un código (un conjunto de reglas), explícito (reglas de catalogación bibliográficas ISBD, por ejemplo) o implícito (organización de un horario de televisión) que define la clase de documentos y sus posibles estructuras. Habitualmente estas reglas están pensadas para su uso por agentes humanos. Ello implica que las reglas no hacen explícita una parte de los conocimientos involucrados, particularmente de sentido común y/o especializados. A la hora de emplear automáticamente estos códigos, el trasvase de los conocimientos implicados supone algunos de los problemas implicados en la representación del conocimiento de sentido común, algo a lo que hemos aludido arriba.

b) El código determina, generalmente de manera relativamente laxa (la inteligencia del lector se supone) una organización de marcadores a partir de los cuales se puede reconocer la superestructura del documento como árbol de análisis.

c) Los marcadores son de diferente naturaleza: tipográficos (sangrado, tamaño de letra, negrita, cursiva, etc.), léxicos (determinadas lexemas), estructura interna del segmento textual (por ejemplo +34 (1) 394.60.54 o 40 cm.), de orden e incluso marcas ad hoc (divisor .-- en las fichas bibliográficas o estructura <...>...</> en documentos SGML ), etc.

d) La organización de los marcadores en un documento determina en muchos casos el sentido de los sintagmas al margen de la gramática normal del castellano. Así en

Podenzana, M. (CAR)......3:54:52.
...
Baldato, F. (MG) ........... m.t
(4)

o también

Aravaca diplomáticos, 350 construidos,...(5)

'Aravaca diplomáticos' sólo tiene sentido en un contexto como el de los anuncios por palabras. ¿Qué decir del primer ejemplo?.

e) En ciertos casos, la estructura de los documentos queda marcada por gramáticas totalmente explícitas (documentos con codificación en la familia SGML como los escritos en HTML, por ejemplo). En otros muchos, más frecuentes, la estructura textual es muy poco explícita, apoyándose sobre todo en la capacidad y conocimientos del previsible lector. Esto puede tener consecuencias importantes en el tipo de sistema de análisis a emplear(6). Sin embargo no nos ocuparemos de ello aquí.

f) No es extraño que varias estructuras textuales aparezcan superpuestas en el mismo documento. Como ejemplo, señalemos la codificación WordPerfect de fichas bibliográficas. El sistema de marcadores interno de WP propio de los documentos WP se superpone al sistema de marcadores de las fichas bibliográficas.

g) No parece que exista una única estructura en cada texto, sino que son posibles diversos análisis todos ellos correctos pero divergentes en, al menos, su finura o precisión.

BiblioTECA: Un sistema de análisis documental automático

En lo que sigue presentaremos, un tanto al hilo de las ideas adelantadas más arriba, los aspectos fundamentales de BiblioTECA. El siguiente diagrama resume el flujo de datos en el sistema.

Diagrama de flujo

Diagrama 1: Flujo de datos en BiblioTECA

El proceso de análisis propiamente dicho comienza a partir de un documento o familia de documentos en texto ASCII. El módulo Intelligent Document Recognition (7) pretende hacer posible la lectura automática de documentos y la corrección de los mismos produciendo, entre otras cosas, archivos del tipo apropiado. Evidentemente, BiblioTECA puede operar sobre otros textos ASCII, independientemente de cual sea su origen. Estos documentos sirven de entrada a lo que hemos llamado arriba módulo AFCA. El resultado del mismo es un análisis de la información en forma de árbol cuyas hojas están formadas por segmentos del documento a analizar y/o transformaciones de los mismos (análisis). Es esta representación la que se proyecta en un formato SGML (proyección). Esta última representación no contiene otra cosa que la codificación en ese formato del mismo árbol de áreas, producto de la fase de análisis. Como hemos dicho, esto es ya una proyección. La razón de no ir más allá en el proceso de traducción es que se ha pretendido construir una herramienta general, de forma que el análisis de la información pudiera ser aprovechado ulteriormente de diversas e imprevistas maneras. A esto se alude en la zona punteada del Diagrama 1. Ello exigía un formato normalizado (SGML) que permitiera diversos tipos de análisis, es decir que fuera neutral respecto al contenido (finura del análisis, etiquetado de los nodos, etc) de los distintos análisis que se puedan hacer usando el sistema. Por tanto sólo podíamos recoger el concepto general de estructura del documento a que aludimos antes. Teniendo esto en cuenta, centraremos nuestra atención en el sistema de análisis automático.

Dos ejemplos

Con el fin de aclarar las consideraciones anteriores presentaremos dos ejemplos. El primero es una entrada del índice de intérpretes del Catálogo de discos de 78 r.p.m., publicado por la Biblioteca Nacional de España.

Uno de los documentos de partida podría ser el siguiente:

Imagen 1:Texto origen

y el análisis resultante sería, en una de sus versiones, el que sigue:

Imagen 2: Análisis de áreas

El segundo, un tanto más complejo, es una entrada de un catálogo de villancicos, también de la Biblioteca Nacional.

Villancicos: origen

Imagen 3: Texto origen

Un análisis posible realizado mediante BiblioTECa sería el que sigue:

Imagen 4: Análisis de áreas

Téngase en cuenta, en ambos ejemplos, que el análisis presentado es sólo un ejemplo: nada impediría un análisis diferente. Más pormenorizado, por ejemplo.

Lo que media en ambos casos entre las dos representaciones del mismo documento es el módulo de análisis (AFCA). Queremos destacar lo siguiente:

  1. En los documentos reales (no muestras selectas con fines experimentales) aparecen con frecuencia desviaciones respecto a la norma subyacente. Las causas son muy distintas: errores de quien escribe el documento, deficiencias de la norma (laguna, incoherencias, etc), etc. developed.
  2. Hablar de un código subyacente a una clase de documentos es una simplificación. En clases de documentos reales no existe habitualmente un código totalmente estable, ni siquiera cuando se trata de aplicar una norma ISO. La norma cambia y sobre todo su aplicación se adapta inevitablemente hasta cierto grado a las condiciones locales.
  3. Como consecuencia de lo anterior, el refinamiento en la representación del código subyacente (lo que vamos a llamar una gramática) tiene límites si se quiere realizar un analizador eficaz: En muchos casos la representación del código no puede mejorarse, en el sentido de que la mejora en el análisis de ciertos subclases de documentos empeora el de otras subclases.
  4. AFCA pretende ser de uso abierto. Es decir, puede aplicarse a muy distintas clases de documentos.
  5. El análisis de la estructura textual de un documento no es necesariamente único, como hemos dicho. En parte queda determinado por los intereses del procesamiento futuro con vistas al cual se hace el análisis.
  6. El código subyacente a cada clase de documentos no es previsible de antemano..

Las consecuencias de lo apuntado en 1.,2. y 3. son esencialmente, que el sistema debe estar preparado para llevar a cabo análisis parciales (reconocer y analizar sólo parcialmente), detectar errores y en la medida de lo posible corregirlos, automática o manualmente. La respuesta a los problemas del resto de los puntos se presentará en el apartado siguiente.

Análisis composicional automático (AFCA)

Como hemos visto antes, el análisis composicional automático es la parte central del módulo de análisis y traducción. Su diseño ha sido nuestra respuesta a lo planteado en los puntos 4.5. y 6. arriba. Es decir, responde a la necesidad de un sistema que permita representar, de la manera más simple posible, el código o códigos involucrados en cada clase de documentos y que las representaciones de estos códigos puedan ser interpretadas como analizadores.

El siguiente diagrama representa la estructura modular de AFCA. El núcleo de AFCA es el generador de analizadores. Del otro módulo, el interfaz de usuario, diremos sólo aquí que es el que se ocupa de la gestión de los distintos productos aludidos en el diagrama 1., ocupándose de funciones como la edición, borrado e incorporación de los distintos productos así como de la correción y validación de los árboles de análisis y la proyección en estructuras SGML(8).

Diagram 2: Recursos en AFCA

El generador de analizadores es una aplicación en PROLOG, invisible para el usuario y conectada por medio de archivos con el interfaz de usuario. Es aquí donde se realiza la generación de los analizadores para cada clase de documentos. Los recursos disponibles en él son esencialmente los indicados en el diagrama anterior.

AFCA permite, primero, realizar de forma relativamente sencilla una descripción de cada clase de documentos. Esto es, permite representar de forma simple el código subyacente a cada clase de documentos. Llamamos gramáticas LENDEX a estas representaciones de los códigos. En segundo lugar, las gramáticas son compiladas en analizadores concretos mediante lo que llamamos generador de analizadores. Cada analizador toma como input los documentos de una clase y devuelve su árbol de análisis. El siguiente presenta este proceso de manera gráfica:

Diagrama 3: Proceso de análisis documental

Analizamos en lo que sigue un poco más de cerca el proceso representado inmediatamente arriba.

Productos: Texto ASCII, documentos , árboles de áreas y gramáticas.

La entrada a AFCA es una secuencia de códigos ASCII. Esta secuencia se ha generado a partir de la lectura automática (I.D.R) o por otros medios. Al contrario que en el Diagrama 1, distinguimos arriba entre texto ASCII y documento. La razón es que AFCA supone que el texto ASCII está dividido por medio de marcadores explícitos de fin de documento. Los documentos son el producto de la subdivisión del texto ASCII producida por un procedimiento incorporado al interfaz que reconoce esos marcadores explícitos. Se trata del primer tipo de objetos que se gestionan en el interfaz. Siguen siendo secuencias ASCII (9), pero son las unidades de análisis para AFCA y requieren una gestión distinta a los textos ASCII.

En todo documento así construido estamos suponiendo una estructura del tipo siguiente:

<documento> ::= <areas>
<areas> ::= <area> {<area>}
<area> ::= <etiqueta> (<lexemas> | <lxs_con_rasgo>)
<area> ::= <etiqueta><areas>
<lexemas> ::= <lexema> { <lexema> }

El concepto de lexema que estamos usando responde aproximadamente al concepto intuitivo de palabra, con la diferencia de que suponemos una categorización de los mismos que contempla los casos de homogenidad y heterogeniedad de los caracteres, lexemas en/con mayúscula/minúscula, etc. A esta idea alude el no-terminal <lxs_con_rasgo>, arriba. Cada área, como vemos, es un par <etiqueta, valor>, donde valor es una secuencia de lexemas (el nodo es una hoja del árbol) o es un árbol de áreas.

Es esta estructura subyacente al documento la que se trata de poner de manifiesto en el proceso de análisis y la que aparece de forma explícita en el árbol de áreas para cada documento, como los que aparecen en los <Ejemplo 1> y 2 . Es así mismo esta estructura a lo que aludíamos antes bajo el membrete de superestructura del documento.

Los documentos SGML son el resultado del único y simple proceso de proyección previsto en BiblioTECA. Ya hemos visto por qué en BiblioTECA no hay procesos de proyección más allá de esta representación, neutral respecto al contenido de la estructura común de los documentos.

Las gramáticas en nuestro sentido son, como hemos dicho, descripciones de documentos acordes con la sintaxis de LENDEX. Son los objetos que representan el código asociado con los documentos y, compiladas como analizadores. Su sintaxis y diseño se tratan con mayor detalle en otro lugar (10) al que remitimos desde aquí.

El generador de analizadores

La entrada al generador (11) es una gramática LENDEX. La salida, un programa PROLOG que actúa como analizador de una clase de documentos. Las líneas generales del proceso se describen a continuación.

En primer lugar la gramática es sometida a un proceso de evaluación que pretende asegurar la integridad y consistencia de la misma. Se trata de establecer la existencia de los elementos necesarios para construir un analizador así como la corrección sintáctica de la gramática. Esta es la función del procesador de gramáticas.

Si la gramática es aceptada, el compilador de gramáticas la traduce a términos PROLOG. De esta forma la gramática LENDEX se convierte en una base de conocimientos. Una base de conocimientos así generada es parte de cada analizador. De hecho la parte diferencial de cada uno de ellos. Esta base incorpora el conocimiento específico acerca del código que define la estructura de las clase de documentos a tratar.

Hay, además, elementos comunes a todo analizador. Se trata de un conjunto de procedimientos que actúan sobre cada base de conocimientos. Quizá los más destacables de entre ellos sean, primero, el meta-intérprete que aplica datos de las base de conocimientos sobre un documento dirigiendo inmediatamente el proceso de análisis. En segundo lugar, el grupo de procedimientos que dirige el modo de actuar del meta-intérprete, controlando el proceso de prueba del mismo. Este proceso nuevo de prueba sustituye al modelo normal de las gramáticas de cláusulas definidas, el modelo de gramática más cercano al usado en AFCA, evitando algunos problemas centrales de las estas gramáticas. En concreto permite tanto marcar como no analizada un área de texto (área indeterminada) como señalar la no aparición de un área que debería existir desde el punto de vista de la gramática (área desconocida) como la violación de las condiciones débiles asociadas con ciertas áreas (área incorrecta).