Regular Expressions for Language Engineering - (RXRC) Karttunen, Chanod, Greffenstette, Schiller

Regular Expressions for
 Language Engineering

             Karttunen, Chanod,
            Greffenstette, Schiller
                   (RXRC)

Introducción


   Transductores finitos muy utilizados para análisis
    morfolófico
    –   Pero, ¿para qué otros aspectos del PLN pueden ser útiles?

   Expresiones regulares

   Tres operadores que facilitan las cosas
    –   Restriction
    –   Replacement
    –   Left to right, longest match replacement

   Ejemplos

Lenguaje y relaciones regulares


   Las expresiones regulares denotan
    conjuntos (de strings y de pares de strings)

   Lenguaje: conjunto de strings

   Relación: conjunto de pares de strings

   Lenguaje regular: lenguaje expresado por
    una expresión regular

   Relación regular: relación expresada por
    una expresión regular

Autómatas y transductores


   Cualquier expresión regular se puede
    implementar mediante redes finitas (finite-
    state networks)

   Autómatas para los lenguajes

   Transductores para las relaciones

Símbolos básicos


   Dos tipos de símbolos en las expresiones
    regulares
    –   Unarios (denotan lenguajes)
    –   Parejas de símbolos (denotan relaciones)

   El símbolo unario b representa a {“b”}

   a:b representa a {}

   Una relación regular es un mapeo de dos
    lenguajes

Lenguaje superior e inferior


   El lenguaje a la derecha del símbolo “:” es el
    lenguaje superior o upper language

   El de la izquierda es el lenguaje inferior o
    lower language

   Para simplificar, no se distingue entre a y a:a

Dirección de los transductores


   Un transductor que implementa una relación
    regular mapea el lenguaje superior con el
    inferior…

   …o el inferior con el superior

   No hay una dirección privilegiada
    –   En los ejemplos, se toma el superior como input y
        el inferior como output

Símbolos especiales


   A falta de epsilon, el símbolo 0 denota al string vacío

   ? denota a cualquier símbolo (ocurra en la expresión
    regular o no)

   Para considerar a 0, ? y otros caracteres especiales
    como lenguajes se los puede poner entre comillas o
    precedidos de %
    –   %?
    –   “0”
    –   % (espacio)

   Se permiten “\n”, “\t” y otros caracteres especiales
    como en C.

Concatenación y unión


   Los lenguajes y relaciones regulares son cerrados bajo
    –   Concatenación
    –   Unión

   A B representa la concatenación de A con B

   A | B la unión

   (A) la unión de A con 0 (opción)

   A+ la iteración (1 o más ocurrencias de A)

   A* la clausura de Kleene (0 o más ocurrencias de A)
    –   Equivale a (A+)

   [A] es equivalente a A

Complemento e intersección


   Los lenguajes regulares son cerrados bajo el
    complemento y la intersección

   Las relaciones regulares no lo son

   Siendo A y B lenguajes
    –   ~A denota el complemento de A
    –   A & B la intersección de A y B
    –   A – B el complemento relativo o diferencia
    –   A .x. B es el producto cartesiano de A y B
         
   Nótese que A .x. B denota una relación regular

Composición


   Las relaciones regulares son cerradas bajo
    composición

   Siendo A y B relaciones regulares
    –   A .o. B denota al conjunto de los , donde
         pertenece a A y  pertenece a B

   A .x. B (sobre lenguajes) y A .o. B (sobre
    relaciones) son los constructores básicos de
    relaciones

Containment


   El preguntar si un input contiene un
    elemento de un lenguaje es muy común

   Es tedioso escribir [?* A ?*]

   $A es equivalente

   $[A | B] denota el conjunto de todos los
    strings que contienen al menos a un
    elemento de A o al menos un elemento de B

   $ se llama contención (¿?) o containment

Restricción


   Pregunta: todos los strings que contengan
    un elemento A precedido de uno de B y
    seguido de uno de C

   Respuesta: [~[~[?* B] A ?*] | [?* A ~[?* C]]]

   Más fácil (agrego notación): A => B _ C

   Esta operación se llama restricción

   A, B y C tienen que ser lenguajes debido a ~

Reemplazo


   Problema: quiero reemplazar todas las
    ocurrencias de un cierto lenguaje por otro
    mediante una relación regular

   Solución: [~$[A – []] [A .x. B]]* [~$[A – []]]

   Esta operación se llama reemplazo

   A y B deben ser lenguajes

Variaciones


   A -> B || L _ R
    –   Reemplazar A por B en el contexto L _ R

   A1 -> B1, A2 -> B2
    –   Reemplazar en paralelo
    –   [~$[ [A1 | A2] – []] [[A1 .x. B1] | [A2 .x. B2]]]*
        [~$[[A1 | A2] – []]]

Ambigüedad del reemplazo


   [a b | b | b a | a b a] -> x produce ante la
    entrada “aba”
    –   “xa”
    –   “axa”
    –   “ax”
    –   “x”

   Se dice que el transductor es ambigüo

Left to rigth, longest match
replacement


   Queremos reemplazar el string más grande
    de la izquierda a la derecha

   A @-> B

   [a b | b | b a | a b a] @-> x produce ante la
    entrada “aba” solamente “x”

   El operador se llama left to rigth, longest
    match replacement

Left to rigth, longest markup


   A @-> B ... C
    –   Left to rigth longest markup
    –   Reemplaza cualquier ocurrencia de A por ella
        misma precedida por un string de B y seguida por
        uno de C

   A2 @-> B1 ... C1, A2 @-> B2 ... C2

   (d) a* n+ @-> %[ ... %]

   Input: “dannvaan”; Output: “[dann]v[aan]”

Simplificación del problema


   Consideraremos fechas como las siguientes:
    –   Sunday,
    –   August 11
    –   Sunday, August 11
    –   August 11, 1996
    –   Sunday, August 11, 1996

   Nótese que algunas ocurren dentro de otras

Ejemplo: Fechas


   Utilizaremos expresiones para reconocer
    fechas

   Primero reconoceremos cualquier cosa que
    se parezca a una fecha

   Luego depuraremos las fechas inválidas

Lenguaje de las fechas

Lenguaje de las fechas


   Genera un automata de 13 estados y 96
    arcos

   30 millones de palabras en dicho lenguaje

   Las fechas que van de January 1 a
    December 31, 9999

Parser


   DateExpression @-> %[ ... ]%

   23 estados, 332 arcos

   Una salida:

Fechas inválidas


   En 9999 años no hay 30 millones de días

   April 31, 1996 no es una fecha válida
    –   Abril tiene 30 días (Problema 1)

   ¿Podemos sacar las fechas inválidas del lenguaje?

   Otras fechas inválidas
    –   February 30
    –   February 29, 1994
         
   1994 no es año bisiesto (Problema 2)
    –   Tuesday, September 16, 1996
         
   Era lunes (Problema 3)

Solución a problemas 1 y 2

Problema 3: Clases de equivalencia
para los años


   “Afortunadamente”, el calendario Gregoriano
    repite la secuencia de días cada 400 años

   14 clases de equivalencia

Problema 3: Clases de equivalencia
para los días


   14 clases de equivalencia para los días

Problema 3: Solución

Fechas válidas: solución


   ValidDate = DateExpression &
    MaxDaysInMonth & LeapDays &
    WeekDayDates

   ValidDate @-> %[ ... %]

   1346 estados, 21006 arcos

   10 segundos en Sun Ultra 1

Parser discriminador


   [[DateExpression – ValidDate] @-> “[ID” ...
    %], ValidDate @-> “[VD” … %]]

   Una salida:

Conclusiones


   Parsers finitos pueden ser construidos directamente
    desde expresiones regulares para lenguajes no
    triviales

   Existen subconjuntos regulares del lenguaje natural
    que pueden ser descriptos con expresiones
    regulares feasiblemente

   Lenguajes y relaciones regulares pueden ser
    modificadas para obtener nuevos lenguajes y
    relaciones sin modificar las gramáticas que las
    describen

Alternativas


   Se podría haber usado una phase structure
    grammar

   Pero, ¿cómo podemos hacer algo similar a
    DateExpression – ValidDate?

Otro ejemplo: Tokenización


   La tokenización es uno de los primeros
    pasos del procesamiento de string input

   Diferentes tokenizaciones para diferentes
    fines
    –   Determinista (output único)
    –   No determinista

Tokenizador determinístico simple


   El tokenizador más simple
    –   Crea un sequencia de tokens sin usar información
        específica del lenguaje

Multiwords

Tokenizador con lexicon


   Ponemos todos las abreviaciones,
    expresiones de más de una palabra, palabras
    compuestas y otras expresiones que
    contengan caracteres especiales en el
    lenguaje TokenLexicon

   Reemplazamos

    por

Problemas del tokenizador con lexicon


   Si “in general” pertenece a TokenLexicon, no
    se distingue entre el “in general” de “in
    general, he” y “in general meetings”

   El lexicon puede ser muy grande

Tokenizador paso a paso


   Primero usamos el tokenizador simple

   Luego identificamos multiwords y las
    agrupamos

   El lenguaje de las multiwords es MWL

   Se asume para MWL que primero se pasó
    por el tokenizador simple

   Por ejemplo, MWL = [ a d “\n” h o c | a n d
    “\n” s o “\n” o n ]

Stapler


   Expresamos un transductor que recompone
    las multiwords

Tokenizador paso a paso: Ejemplo

Tokenizador no determinístico


   Algunas expresiones tienen diferente
    significado según el contexto

   El tokenizador no tiene la lógica suficiente
    como para tomar una decisión acertada

   Podría dar toda las opciones…

   Necesitamos que sea no determinístico para
    ello

Ambigüedad


   “De même les boîtes de même format sont
    classées ensemble” es ambigua debido a que
    “de même” también lo es


   ¿Quién se encarga de la ambigüedad?

   Restricciones sintácticas pueden eliminar
    tokenizaciones no aplicables (aunque no
    siempre la ambigüedad)

Restricciones sintácticas: Ejemplo

Markers y filters


   Un transductor finito que introduce símbolos
    adicionales a un input string se llama finite
    state marker

   Un transductor finito que devuelve partes de
    un input string se llama finite state filter

Último ejemplo: Light parser


   Reconocer patrones léxicos recurrentes es
    útil para la extracción de información

   ¿Se puede hacer con un transductor?

   Si se puede, muchas soluciones son más
    complicadas de lo que se necesita (estados
    infinitos)

Etapas del light parser


   Identificamos grupos nominales y verbales
    (phrasal mark-up)

   Indentificamos el cabezal de cada grupo
    (head-marking)

   Extraemos relaciones sintácticas (syntactic
    extraction)

Phrasal mark-up

Head marking

Syntactic function extraction

Performance


   Light parser aplicado a 1 Mbyte de texto
    (164.000 palabras) en SPARC-20

   Tagging: 15 segundos

   Phrasal mark-up: 2 minutos

   Head marking: 3 minutos

   Union de 17 filtros: 11 minutos

Conclusiones


   Los transductores finitos resuelven
    problemas del PLN eficientemente más allá
    de su uso clásico (a la fecha del artículo),
    pese a que el lenguaje natural no es regular

   Las expresiones regulares facilitan la
    producción de transductores

   Las extensiones de Xerox son buenas ☺