http://elies.rediris.es/elies9/5-2.

htm

5.2 Esquema conceptual de la base de datos

En este apartado mostraremos la implementacin que bajo el modelo relacional de datos hemos llevado a cabo para nuestro lexicn multilinge, mostrando los diagramas conceptuales y explicando las circunstancias que nos han llevado a adoptar determinadas decisiones. Pasaremos por alto la descripcin detallada de la base de datos (tipos de datos, restricciones, cdigo SQL de consultas, etc.). Lo realmente interesante de una base de datos y lo que determina en gran medida su funcionalidad es su esquema conceptual. El modelado que vamos a mostrar aqu es el resultado de la experimentacin con otros posibles esquemas que, por una razn un otra, fueron descartados en su momento. De todos los diseos probados, el que ahora presentamos es sin duda el ms compacto y el que mejor se adapta al tipo de aplicacin que le queremos dar, manteniendo al mismo tiempo una gran independencia de los datos y de la teora gramatical. Respecto a esta caracterstica, hemos de reconocer que la influencia del modelo para el que la base de datos se dise en principio, en 1992, bajo la direccin del profesor Martn Mingorance, es an patente. Lo que hemos pretendido es aprovechar los grandes beneficios que de esta circunstancia se derivan al mismo tiempo que hemos construido sobre ello. Un esquema alternativo considerado durante algn tiempo es descrito en (Moreno Ortiz 1995). Compararemos algunas de las caractersticas de este esquema con las del nuevo que proponemos en este trabajo. Comenzaremos revisando algunas premisas importantes que han determinado en gran medida una implementacin concreta. Como mencionamos en el Captulo 1, nuestro anlisis se ha centrado en las unidades verbales, bajo la suposicin de que son stas las que en buena medida determinan muchas caractersticas de una lengua, siendo consideradas en la mayora de los anlisis gramaticales el centro gravitacional de la oracin. Por lo que respecta a la FG, esto es as sin duda (Dik 1989), ya que el verbo es considerado como un predicado que toma una serie de argumentos (su valencia). Tambin los sustantivos y adjetivos son considerados como predicados, pero el predicado verbal es el que determina la estructura general de la oracin. En cualquier caso, esto no condiciona ningn diseo determinado para la expansin de la descripcin de sustantivos o adjetivos, que tambin han sido incluidos en la base de datos, pero sin aportar por el momento una 3 descripcin lxico-semntica u ontolgica de los mismos . En primer lugar, la base de datos ha de almacenar informacin lxica correspondiente a tres lenguas: ingls, espaol y alemn. Es de suponer que estas lenguas compartan algunas caractersticas bsicas y difieran en otros muchos aspectos. Nuestro objetivo es hallar todas las similitudes posibles en trminos de necesidades de representacin con el objeto de eliminar al mximo la redundancia y poder ofrecer un tratamiento lo ms homogneo posible. El modelo de representacin no aspira a ser universal en ningn sentido, sino tan slo a dar soporte a las necesidades representacionales de estos tres idiomas. Por ejemplo, la morfologa de los verbos de estas tres lenguas muestra grandes diferencias. En espaol no existe paralelo al verbo con partcula ingls, mientras que en alemn los verbos con partcula separable merecen un tratamiento especial. Por ello, cada lengua deber contar con descripciones distintas para su morfologa. Sin embargo, la descripcin de los patrones sintcticos (en trminos funcionales o de relaciones gramaticales) son las mismas para los tres (objeto directo, indirecto, etc.), por lo que esta informacin es susceptible de ser compartida en su mayor parte. sta es una diferencia clara con la mayora de las bases de datos lxicas que hemos expuesto en apartados anteriores, ya que en stas se suelen confeccionar los lexicones monolinges de forma aislada, de modo que es muy difcil recoger este tipo de generalizaciones que reducen considerablemente la redundancia de la base de datos y facilitan la tarea del administrador.

http://elies.rediris.es/elies9/5-2.htm
En este sentido hemos adoptado la convencin de prefijar los nombres de las distintas relaciones ya sea con ALL (para aqullas que contengan informacin compartida), ya sea con ENG, SPA o GER para las que contengan informacin especfica del ingls, espaol o alemn, respectivamente. Una ventaja importante sera mantener en lo posible la misma estructura general para las tres lenguas, porque esto facilitara enormemente las tareas de mantenimiento y modificacin de la base de datos. Esto no significa que las propiedades hayan de ser las mismas, pero s las entidades y relaciones. Por ejemplo, las tres lenguas tienen verbos, sustantivos, adjetivos, adverbios y un conjunto cerrado de unidades lxicas, aunque las propiedades de cada una de ellas puedan ser diferentes. En nuestro diseo hemos tratado de aprovechar estas caractersticas isomrficas de modo que la estructura bsica de entidades y relaciones es la misma para las tres lenguas. La Figura 5.3 muestra un diagrama E/R donde las "XXX" pueden ser sustituidas por las iniciales de cualquiera de las tres lenguas (ENG, SPA, GER). Este diseo implica que en la base de datos existe una tabla ENG_Lemma, una tabla SPA_Lemma y una tabla GER_Lemma, as como las tablas ENG_Verb, SPA_Verb, GER_Verb, etc., manteniendo una estructura isomrfica. Las "nubes" de este diagrama son otra convencin que indican que el esquema no acaba ah sino que continan las relaciones y entidades. Hemos marcado con lnea ms gruesa la seccin del diagrama que hemos desarrollado completamente, es decir, la informacin correspondiente a los predicados verbales, que describimos a continuacin.

http://elies.rediris.es/elies9/5-2.htm

Figura 5.3 Esquema general de cada lengua Como se puede observar, hemos adoptado el ingls como "lingua franca" para nombrar los elementos de nuestra base de datos. La nica razn para esto es que esta lengua fue la primera para la que se introdujo informacin. As las descripciones de entidades y sus propiedades compartidas estarn explicitadas en ingls. Como veremos, esto no condiciona absolutamente nada, ya que en realidad podramos omitir las descripciones sin problema, pues todas ellas funcionan mediante cdigos numricos aleatorios. En lo sucesivo nos concentraremos en el modelado de las unidades lxicas verbales. El resto de las categoras contienen en este momento nicamente la identificacin de lema y la cadena de caracteres que los representa. Por lo tanto, cualitativamente hablando, no existe mucha informacin respecto a estas categoras. Cuantitativamente, sin embargo, las listas son muy exhaustivas. La Tabla 5.1 muestra el nmero de entradas que las distintas tablas contienen actualmente junto con las fuentes de las que se ha extrado la informacin para cada una de las tres lenguas.

Idioma

N de Lemas

Fuentes

http://elies.rediris.es/elies9/5-2.htm

INGLS

62.418

American Heritage Dictionary Longman Dictionary of Contemporary English

ESPAOL ALEMN

77.569 111.260

Diccionario de la Real Academia de la Lengua (Ed. CD-ROM) Corpus de referencia Arbeitsbereich Linguistik (Universidad de Mnster)4

Tabla 5.1 Nmero de lemas contenidos en la base de datos Por supuesto estas cifras no incluyen nombre propios, que han sido separados en espera de conseguir un tratamiento adecuado en cuanto a modelado en un entorno multilinge. Trasladamos la discusin sobre el correcto tratamiento de los nombre propios al apartado 5.4. La utilizacin de las fuentes que sealamos en el cuadro se debe nicamente a que son las que hemos tenido a nuestro alcance. En especial, la eleccin del DRAE como fuente para la lista de lemas espaoles dista mucho de nuestras preferencias en cuanto a metodologa lexicogrfica. Idealmente, habramos optado por una populacin basada en fuentes textuales reales, es decir, crpora, tal y como ocurre con la lista de palabras para el alemn. En este sentido, el ms reducido nmero de lemas para el ingls (que incluye unos 18.000 nombres propios) se justifica porque las fuentes empleadas realizan una seleccin de las entradas mucho ms adecuada que la del DRAE. El alto nmero de lemas para el alemn tambin se debe a esta razn, al estar extrados a partir de un gran nmero de textos periodsticos. El trmino "lema" merece una aclaracin. Este trmino se ha venido utilizando en diversos campos para designar nociones no siempre idnticas. Lo que entendemos por "lema" viene a coincidir en trminos lexicogrficos, con el concepto de "entrada" en un diccionario tradicional. El trmino "entrada" (entry), sin embargo, tampoco es clarificador, ya que mientras que en algunos casos sta se entiende como la "forma cannica" mediante la cual las distintas unidades lxicas son identificadas (por ejemplo, la forma de infinitivo de un verbo) y en otras ocasiones tambin incluye cualquier otra palabra o frase explcita o implcitamente definida en el diccionario (cf. Landau 1984). La nocin de "forma cannica" es tal vez la ms acercada a lo que nosotros entendemos por el trmino "lema". La adopcin de este trmino se debe sin duda a la influencia de las tcnicas de lexicografa computacional y lingstica de corpus, donde un "lematizador" es un programa que refiere un "token" determinado (cadena de caracteres), por ejemplo, "acabara", a una forma cannica determinada, "acabar", que es denominada lema. Al centrar la descripcin de los distintos lexemas en torno a un lema determinado nos aseguramos de que todos los lexemas que han de ser definidos bajo una entrada determinada del diccionario queden correctamente enlazados. Ms adelante mostraremos el mecanismo relacional concreto que permite esto. En trminos de procesamiento automtico del lenguaje, el lema es el objeto lxico abstracto al que una cadena de caracteres determinada ha de ser asignada para recuperar la informacin (sintctica, semntica, etc.) necesaria para un tratamiento correcto. De este modo nuestra disposicin es vlida para los dos tipos de tareas a las que la base de datos pretende dar soporte. Adems, el lema est relacionado con los distintos lexemas (p. ej. verbos) con exigencia de integridad relacional, con actualizacin y eliminacin en cascada. Esta cualidad, impide, por ejemplo, que un verbo se asigne a un lema inexistente o fuerza la eliminacin de todos los lexemas asignados a un determinado lema si ste es eliminado.

http://elies.rediris.es/elies9/5-2.htm
Puesto que las tres lenguas mantienen la misma estructura bsica, un solo diagrama nos servir para mostrar la forma en que hemos modelado la informacin respectiva a los predicados verbales en la base de datos. La Figura 5.4 muestra el diseo.

Figura 5.4 Modelado bsico de predicados verbales Como se puede observar existe muy poca informacin asignada directamente al verbo, tan slo la definicin en lenguaje natural, el indicador de acepcin y el verbo, propiamente. En la mayora de los casos el verbo se corresponder con el lema, pero no siempre. Por ejemplo, los verbos "take on", "take over", "take up" etc. mostrarn esta forma en el campo Verb, mientras que todas ellas estarn referidas al mismo lema, "take". El tratamiento que hemos dado a la morfologa del ingls puede servirnos para mostrar de una forma sencilla la manera en que un buen diseo relacional puede suplir la deficiencia de la herencia de dicho modelo. La Figura 5.5 muestra las propiedades concretas de la relacin ENG_Morph.

http://elies.rediris.es/elies9/5-2.htm

Figura 5.5 Modelado de informacin morfolgica para el ingls Este diagrama muestra, en primer lugar, que una definicin morfolgica cualquiera puede ser asignada a un nmero indeterminado de verbos. Las propiedades mediante las que se describe un patrn morfolgico han sido escogidas para eliminar la redundancia en lo posible. Existe un cdigo arbitrario (Morph_ID) que es la clave primaria de la tabla ENG_Morph que, mediante una clave externa en la tabla ENG_Verb, servir para establecer la relacin. La propiedad PoS describe de forma sucinta el tipo de entidad morfolgica (por ejemplo, "phrasalprepositional verb"), mientras que el campo Abbreviation nos servir para el volcado lexicogrfico en diccionario impreso. Los cuatro campos restantes son utilizados para todas aquellas construcciones verbales multi-palabra que incorporen uno o dos elementos ms adems del lema. Adems de la multitud de verbos con partcula ingleses, esta disposicin da cabida a otros muchos lexemas verbales muti-palabra del tipo "take care of", "take place", "look like", "be born", "tear apart" y tantos otros. Finalmente, las dos propiedades Oblig son campos booleanos que marcan la obligatoriedad o no de la partcula a la que se refieren, informacin necesaria tanto para el diccionario impreso como para el procesamiento automtico. La representacin final consistir en el lema, al que se le asignarn las caractersticas morfolgicas propias segn su realizacin como lexema, la construccin global, determinada por el campo Verb en la tabla ENG_Verb, ms la descripcin de las posibles partculas acompaantes y la definicin concreta del tipo de objeto morfolgico en la tabla ENG_Morph. Como ya hemos mencionado, las necesidades de cada idioma respecto a la morfologa son distintas. La Figura 5.6 muestra la representacin necesaria para las caractersticas morfolgicas del alemn.

http://elies.rediris.es/elies9/5-2.htm

Figura 5.6 Modelado de informacin morfolgica para el alemn Adems de esta representacin morfolgica, el sistema tambin contiene dos mdulos morfolgicos, uno para el espaol y otro para el ingls, totalmente integrados en la base de datos que, tomando la informacin contenida en sta, son capaces de generar todas las formas verbales para cualquier verbo de estos idiomas. Mostramos algunas de sus caractersticas en el apartado 5.4. Este enfoque "personalizado" a la morfologa (es decir, la consideracin de distintos esquemas para distintas lenguas) se diferencia de las especificaciones de MLEXd, que considera un nico marco descriptivo para todas lenguas de la Comunidad Europea. Obviamente, esto implica redundancia, ya que muchos descriptores son slo aplicables a lenguas concretas. Por lo que respecta a la informacin fonolgica, la base de datos es capaz de almacenar informacin relativa a la transcripcin fontica de los distintos lexemas siguiendo el alfabeto fontico internacional. La fontica nos ha planteado algunas dudas de implementacin. En ingls est claro que es necesario asignar este tipo de informacin a nivel de lexema, no de lema, ya que, por ejemplo existen un buen nmero de alternancias verbo/sustantivo con cambio de acento. Sin embargo, en espaol esto no ocurre as, sino que el grafema determina totalmente la pronunciacin independientemente de su realizacin como lexema. Hemos querido mantener el mismo esquema para los dos idiomas por razones que se harn aparentes ms adelante y que tienen que ver con la facilidad que esto supone para la creacin de consultas, formularios e informes. Otra ventaja de este diseo es poder aprovechar las caractersticas homofnicas de muchos lexemas (p. ej. /ro:/ para "roar" y "raw"). La Figura 5.7 muestra el diseo de las propiedades morfolgicas para una lengua cualquiera. Este esquema es prcticamente el mismo que el utilizado en MLEXd con los cambios necesarios para la adaptacin a nuestro esquema general. El descriptor "Transcription" es la transcripcin fontica considerada como standard, mediante el juego de caracteres IPA. "Syllabification" contiene lo mismo que el anterior, pero con marcas separadoras de slabas. Finalmente, "Accent" contiene informacin sobre la slaba que lleva la carga prosdica principal. Esta informacin es utilizada, por ejemplo, por el mdulo morfolgico ingls para

http://elies.rediris.es/elies9/5-2.htm
determinar si un verbo ha de doblar la consonante final de la forma base para generar las formas "-ing" y "-ed".

Figura 5.7 Modelado de informacin fonolgica para un alengua Con esto hemos mostrado todas aquellas entidades que en la Figura 5.4 sealbamos como dependientes de la lengua, excepto la seccin que en esta figura marcbamos con lnea ms gruesa, la complementacin verbal, que, por su complejidad, ser descrita al final. Por lo que respecta al resto de los grupos de descripcin compartidos (ALL_Dim, ALL_Field y ALL_Frame), la Figura 5.8 muestra cmo se modela esta situacin. Este modelado es caracterstico de nuestra implementacin y refleja los supuestos metodolgicos que hemos adoptado en este trabajo. No debemos dejar de tener en cuenta que todos estos diagramas son parciales. Por ejemplo, en esta figura no se han incluido las respectivas entidades "Lema" o las que definen las propiedades fonolgicas o morfolgicas que acabamos de describir. En este sentido, las entidades ENG_Verb, SPA_Verb y GER_Verb siguen siendo dependientes (por lo que se marcan con un rectngulo doble) aunque en esta representacin parcial no aparezcan las entidades de las que dependen (XXX_Lema).

http://elies.rediris.es/elies9/5-2.htm

Figura 5.8 Modelado de las entidades compartidas Aunque el diagrama muestre una situacin en apariencia compleja, de hecho no hemos representado en l todas las relaciones que las entidades ALL- guardan en el esquema general de la base de datos. Cuando describamos el modelado que hemos realizado de la complementacin verbal, veremos cmo estas mismas entidades, junto con otras, son utilizadas para la descripcin de los argumentos que toman los predicados verbales, por lo que en realidad la situacin es algo ms complicada de lo que aqu se muestra. La entidad ALL_Dim contiene informacin sobre las dimensiones que sirven de "esqueleto" al eje paradigmtico, segn se especifica en el FLM. Las distintas dimensiones son almacenadas con un cdigo arbitrario (Dim_ID), la descripcin de la dimensin (Description) y dos propiedades adicionales que son las que en realidad aportan informacin relevante, ya que las localiza en una jerarqua. La relacin AD-AD seala una relacin especial que ya hemos comentado: la de tipo/subtipo, o en trminos relacionales una autocombinacin (self-joint). ste es el nico modo que una base de datos relacional ofrece para recrear jerarquas, aunque en ningn caso debemos entender stas en trminos de redes semnticas como las que mostraremos en el apartado 5.4 para la implementacin de la ontologa. El mecanismo es muy

http://elies.rediris.es/elies9/5-2.htm
fcil: a una entidad se le asigna una propiedad, por ejemplo Subtype_of, que hace referencia al identificador nico (en este caso, Dim_ID) de la entidad que es considerada como "madre". La "herencia" de propiedades se consigue mediante consultas anidadas que generan conjuntos dinmicos de datos (ver apartado 4.2.3.1), con una profundidad de niveles indeterminada (o en todo caso determinada por los niveles de anidacin de las consultas). Finalmente, la relacin con la entidad ALL_Field enmarca la dimensin en un campo lxico determinado. De este modo, la base de datos es capaz de mostrar, para un lexema verbal cualquiera, no slo la dimensin a la que pertenece, sino tambin todas las dimensiones "madre" hasta llegar a la ltima. Con la informacin que ha sido introducida hasta ahora en la base de datos no se ha necesitado una profundidad superior a nueve, con lo que ste es el nmero de consultas anidadas que han de realizarse para recuperar esta informacin. En el siguiente apartado mostraremos una captura de pantalla que de forma grfica muestra este tipo de jerarqua. La informacin referente a las dimensiones verbales es obviamente algo especfico de un modelo lexicolgico determinado, el FLM, para el que la base de datos se dise en primer lugar. Creemos que nuestras pretensiones respecto a la validez de la base de datos para otros modelos, la caracterstica mencionada de independencia de la teora, queda salvaguardada con el modelado de datos que proponemos, ya que esta informacin no condiciona la estructura general de la base de datos. La estructuracin de un campo en dimensiones y subdimensiones ofrece una forma adecuada y de probada fiabilidad para estructurar el eje paradigmtico de una lengua. Por lo que se refiere a la utilidad de esta informacin en el procesamiento del lenguaje natural, y ms concretamente en la Traduccin Automtica, pensamos que no es, en s misma, suficiente. La razn bsica es que estamos hablando de un mtodo de anlisis lexicolgico, no de un mtodo de descripcin formal, que adems no fue originalmente ideado para este tipo de tareas, no contando con una formalizacin adecuada y por tanto de dudosa aplicacin a las mismas. Nuestra aportacin en este sentido ha sido proponer una jerarqua de conceptos (la ontologa) que s puede ser utilizada como un soporte formal ms fiable, como de hecho se lleva a cabo en los proyectos de KBMT que hemos mencionado. Continuaremos esta discusin en el apartado 5.4. La conexin entre la base de datos y la base de conocimiento la hallamos ya aqu. Como se muestra en la Figura 5.8, cada uno de los predicados verbales de las tres lenguas mantienen una relacin con la entidad ALL_Frame. Esta tabla contiene todos los marcos (conceptos) contenidos en la ontologa (unos 4.800 hasta el momento), cuya organizacin jerrquica en red semntica localiza de forma muy concreta el contenido lxico-semntico de los lexemas verbales. En realidad, como veremos a continuacin, los distintos argumentos de los predicados verbales tambin son localizados de forma precisa mediante su adscripcin a un marco determinado. Mediante estos tres grupos de descripcin: dimensin, campo y marco, ms la descripcin del patrn de complementacin sintctico-semntico que mostramos a continuacin dotamos a las entradas lxicas de una descripcin semntica suficiente para individualizarlas, de forma que se obtiene una caracterizacin lo suficientemente precisa como para ofrecer un perfil semntico que nos permitir establecer correspondencias interlinges sin que stas se hallen sealadas de forma explcita. La dimensin determina las propiedades de sinonimia bsicas, ya que lexemas contenidos en una dimensin determinada mantienen un ndice sinonmico alto. La adscripcin a un marco determinado de la ontologa aporta su localizacin y caracterizacin formal, dentro de un submundo perfectamente estructurado y sobre el que se pueden efectuar operaciones concretas. Finalmente llegamos a la descripcin del patrn de complementacin sintcticosemntico. ste habr de incorporar informacin sobre la valencia cuantitativa y cualitativa de los predicados verbales. No cabe duda de que se trata de un conjunto de informacin complejo y muy susceptible de contener altos ndices de redundancia. Volvemos a tratar el problema de la subcategorizacin, para el que la mayora de los formalismos gramaticales modernos

http://elies.rediris.es/elies9/5-2.htm
ofrecen como solucin basada en herencia mltiple por defecto no monotnica (ver apartado 4.4). Como ya mencionamos en las conclusiones del captulo anterior, es posible que sta sea la mejor solucin, pero desde luego no la nica. En el resto de este apartado pretendemos demostrar cmo se puede modelar este tipo de informacin utilizando mtodos clsicos de representacin, ofreciendo unos niveles de redundancia aceptables. En contrapartida, nos estaremos beneficiando de un modelo de datos de probada efectividad y fiabilidad. Si volvemos a observar la Figura 5.4, el rea del esquema general que pretendemos desarrollar ahora es el que sealbamos con una lnea ms gruesa. Obviamente, lo mostrado en esta figura es una gran simplificacin del esquema real. La Figura 5.9 expande este esquema. En este diagrama hemos omitido de nuevo todas aquellas propiedades y relaciones que no tienen que ver con la complementacin verbal. Como vemos existe una caracterizacin para cada uno de los tres argumentos que se contemplan para el predicado verbal. Cada argumento queda definido segn un nmero de propiedades sintcticas y semnticas, as como la o las preposiciones que pueden precederles (esto ltimo no se aplica al argumento 1; dichas propiedades son las siguientes: ArgX: ALL_Syn Entry: Subject, Direct Object, Direct ObjectDirect Quote, Adverbial, etc. Abbreviation: S, Od, Od-DQ, A, etc.

http://elies.rediris.es/elies9/5-2.htm

Figura 5.9 Modelado de la complementacin verbal La Tabla 5.2 contiene todas las descripciones sintcticas consideradas por la base de datos en estos momentos, aunque es posible aadir nuevas.

Syn_ID 1 Subject 2 Object

Entry

Abbrevation Subtype of S O C A Ad Cs Co PO AM AdM Od-TC 3 3 2 4 5 14 14

3 Complement 4 Adverbial 5 Adjunct 6 Subject Complement 7 Object Complement 8 Prepositional Object 9 Adverbial of Manner 10 Adjunct of Manner 12 Direct Object-That Clause

11 Direct Object-Direct Quote Od-DQ

http://elies.rediris.es/elies9/5-2.htm

13 Direct Object-To Infinitive Od-TI 14 Direct Object 15 Indirect Object 16 Adverbial of Place 17 Adjunct of Place
Tabla 5.2

14 2 2 4 5

Od Oi AP AdP

ALL_Sem Selection Restrictions (2): +Hum, -Anim, +Percep, -Conc, etc State of Affairs: Direct Speech Act, Subjective Probable Fact, etc. Semantic Functions (2): Agent, Speaker, Goal, Beneficiary, etc. ALL_Frame Frame (conexin con la ontologa)

La Tabla 5.3 contiene todas las combinaciones que hasta el momento han sido necesarias incluir para describir los argumentos de los predicados verbales contenidos en la base de datos.

Sem_ID SR1 1 +Art 2 3 +Hum 4 -Conc 5 6 7 +Art 8 +Hum 9 10 +Hum 11 -Conc 12 -Conc 13 -Conc 14 15 16 -Conc 17 18 19 -Hum 20 -Anim

SR2

SoA Fo

SF1 Eval Ag Fo Man Eff Aff Rec Rea Ag Go

SF2

Sp Mess Man

Direct Speech Act Subjective Probable Fact Objective Certain Event

Go Go Rea Rea

Mess Mess

Objective Probable Action Go Ag +Shap Fo

Mess

http://elies.rediris.es/elies9/5-2.htm

21 +Conc 22 +Nfo 23 -Conc 24 +Animal 25 +Percep 26 +Percep 27 +Hum 28 +Conc 29 +/-Hum 30 +Percep 31 +Conc 32 -Conc 33 +Hum 34 35 +Hum 36 37 -Anim 38 +Animal 39 40 +Conc 41 42 +Conc 43 +Conc 44 +/-Conc 45 +Conc 46 +Conc 47 +/-Hum 48 49 -Conc 50 +/-Living 51 -Conc 52 53 +Conc 54 +Hum 55 -Conc 56 +/-Conc 57 -Conc 58 +Conc Objective Probable Fact -Anim -Anim Objective Probable Event Subjective Probable Fact Objective Probable Fact +/-Art -Anim

Direction Fo Go Ag Eff Mess Exp Aff Rec Go Processed Eff Rea Rea Aff Rea Aff Rec Cause Fo Aff Cause Rea Fo Eff Aff Phen Go Go Go Sp Mess Area Area Loc Eff Eff Mess Eff Area

http://elies.rediris.es/elies9/5-2.htm

59 -Conc 60 61 +Loc 62 +Percep 63 +Hum 64 +Conc 65 -Conc 66 67 +Conc 68 +Conc 69 +Anim 70 +Conc 71 72 +Living 73 +Living 74 +Concrete 75 -Conc
Tabla 5.3

Rec Exp Fo Man

Aff Direct Speech Act +Loc Go Source Aff Ag Means Mess Ads Instrum. Eval

La Figura 5.10 muestra el esquema conceptual de estas tres entidades.

Figura 5.10 Detalle de entidades (complementacin verbal)

http://elies.rediris.es/elies9/5-2.htm
De nuevo observamos cmo cierta informacin est enfocada a determinados tipos de tareas. El campo Ejemplo es de nula utilidad para el anlisis automtico, estando enfocado a la lexicografa. Lo mismo ocurre con el campo Abbreviation, que nicamente ser de utilidad en diccionarios impresos. La informacin referente a la sintaxis y a la semntica, sin embargo es susceptible de ser utilizada en ambos tipos de aplicaciones. Sera posible, por ejemplo, establecer una serie de reglas que convirtiesen los descriptores en cadenas de caracteres ms apropiados para la consulta por un usuario, mientras que esos mismos cdigos pueden ser utilizados directamente por una aplicacin externa (recordemos que la recuperacin de los datos est garantizada, puesto que cumple con el estndar ODBC). Como ya adelantbamos cuando mostrbamos el modelado de la informacin bsica de las unidades lxicas, la misma tabla ALL_Frame, utilizada para describir ontolgicamente las unidades verbales de los tres idiomas (siendo de hecho lo ms cercano a un enlace multilinge que contiene la base de datos), es utilizada de nuevo para describir los distintos argumentos de los predicados verbales (por supuesto para las tres lenguas, no olvidemos que el modelado es idntico). Los campos de estas tablas que muestran el sufijo _ID nos recuerdan que seguimos trabajando con claves subrogadas. De hecho, este es el nico tipo de claves primarias que hemos usado en la implementacin. Como muestra la Figura 5.9, la caracterizacin semntica de un argumento determinado se muestra nicamente mediante un cdigo, que es el que establece la relacin con la tabla ALL_Sem. Esto quiere decir que el lexicgrafo no se ve forzado a repetir una y otra vez las mismas cadenas de caracteres (+Human, Agent, Speaker, etc.). Puesto que slo se almacenan nmeros enteros, el sistema gana enormemente en velocidad, a la vez que se evitan errores tipogrficos, ya que, por ejemplo, una descripcin semntica determinada (+Hum, Agent, Speaker) slo se teclea una vez, utilizando el cdigo asignado a la descripcin desde ese momento. La entrada de cdigos arbitrarios es, de hecho, lo que ocurre con el resto de la informacin referente a la complementacin, as como con la mayor parte del resto de la informacin lxica. Se puede pensar que la utilizacin de cdigos puede entorpecer la labor lexicogrfica en lugar de facilitarla. Sin embargo, un interfaz grfico adecuadamente diseado evitar esta situacin. En el siguiente apartado describimos este interfaz. Al mismo tiempo, las reglas de integridad relacional se encargan de bloquear muchos de los errores normales en la tarea de introduccin de datos. Por ejemplo, estas reglas impiden que se asigne un cdigo inexistente o que se deje en blanco ciertos datos que necesariamente han de ser especificados. Adems, la introduccin de un cdigo errneo es fcilmente detectable, puesto que el resultado, una vez expandida la descripcin, ser totalmente diferente de lo deseado. En la versin anterior a este modelado (Moreno Ortiz 1995) se contemplaba un esquema conceptual distinto para la descripcin sintctico-semntica. En lugar de considerarse un entidad separada para la complementacin (XXX_Comp, ver Figura 5.9), se utilizaba una clave ajena dentro de la entidad XXX_Verb para describir cada uno de los argumentos en entidades separadas en una relacin uno-a-uno. Estas entidades, denominadas Arg1, Arg2, Arg3, estaban a su vez relacionadas con otra entidad, Arg_Desc, equivalente a la actual ALL_Sem y con otra, P_Axis, que describa sus propiedades paradigmticas. Las Figuras 5.11 y 5.12 muestran este modelado.

http://elies.rediris.es/elies9/5-2.htm

Figura 5.11 Modelado sintctico-semntico descartado (1)

Figura 5.12 Modelado sintctico-semntico descartado (2) Este modelado implica que debern existir tantas entidades ArgX (x3) como lenguas se consideren en la base de datos. De hecho, es un buen ejemplo de error conceptual, ya que fue diseado para almacenar informacin de una sola lengua, y no se tuvieron en cuenta las repercusiones que la inclusin de otras tendra sobre el esquema global de la base de datos. Por tanto el esquema fue descartado en vista de los grandes niveles de redundancia que se generaban y sobre todo porque resultaba innecesariamente complejo, entorpeciendo las labores de consulta y actualizacin. Finalmente hemos de mencionar que an no hemos acometido la tarea de modelar la 5 informacin pragmtica que una base de datos de estas caractersticas debera contener . La razn fundamental es que el modelo de representacin sintctico-semntica que proponemos an ha de ser perfeccionado. El desarrollo del componente pragmtico, es indispensable para un sistema de TA basado en el conocimiento como el que proponemos, ya que en tales sistemas se pretende conseguir una representacin neutral de los actos de habla (interlingua); esta representacin neutral deber incluir forzosamente una serie de rasgos pragmticos muy especficos que definan las caractersticas diafsicas, diastrticas y diatpicas de lexemas y

http://elies.rediris.es/elies9/5-2.htm
proposiciones, de tal modo que estos rasgos puedan ser recreados de forma fidedigna en el texto meta. El modelado de este tipo complejo de informacin es por tanto una tarea que posponemos para futuros desarrollos de nuestro esquema, dada su enorme complejidad y envergadura. El punto de partida para este desarrollo ser sin duda una formalizacin del trabajo de Jimnez Hurtado (1994a, 1994b), donde se sientan las bases para un tratamiento sistemtico de la informacin pragmtica desde una perspectiva del modelo lexemtico-funcional. En cualquier caso, y dando por supuesta la futura existencia de una descripcin de los rasgos pragmticos, pensamos que la caracterizacin semntica que acabamos de proponer no es en s misma una caracterizacin lo suficientemente precisa para servir de soporte a un sistema de traduccin automtica, que deber ser capaz de generar descripciones interlinges muy precisas y, sobre todo, independientes de la lengua. Por este motivo proponemos en este trabajo la inclusin de un recurso de informacin conceptual independiente de la lengua, siguiendo el ejemplo de proyectos de KBMT bien establecidos. Por tanto, la descripcin sintctico-semntica que acabamos de presentar ser complementada con la inclusin de una ontologa, representada mediante un sistema de redes semnticas, que describiremos en el apartado 5.4. Por lo que respecta a la base de datos lxica, hasta ahora nos hemos centrado en la descripcin formal, en trminos de modelado conceptual de la base de datos. En el siguiente apartado mostramos el interfaz de usuario, que probablemente ayudar a comprender el funcionamiento y las posibilidades del modelo abstracto que acabamos de presentar.