TFG_VICENTE_SIXTO_CARDENAS_MONTALBAN

Vista previa del material en texto

Universidad Politécnica
de Madrid
Escuela Técnica Superior de
Ingenieros Informáticos
Grado en Matemáticas e Informática
Trabajo Fin de Grado
Extracción automática de relaciones
qualia para la ontología OntoETAP
Autor: Vicente Sixto Cárdenas Montalbán
Tutor(a): Igor Boguslavsky
Madrid, Junio - 2022
Este Trabajo Fin de Grado se ha depositado en la ETSI Informáticos de la
Universidad Politécnica de Madrid para su defensa.
Trabajo Fin de Grado
Grado en Matemáticas e Informática
Título: Extracción automática de relaciones qualia para la ontología Onto-
ETAP
Junio - 2022
Autor: Vicente Sixto Cárdenas Montalbán
Tutor: Igor Boguslavsky
Departamento de Inteligencia Artificial
ETSI Informáticos
Universidad Politécnica de Madrid
Resumen
Los sistemas modernos que tratan con lenguaje natural buscan igualar la ca-
pacidad de “comunicación” y “entendimiento” de un ser humano. Sin embargo,
el ser humano es capaz de entender los mensajes gracias al conocimiento del
entorno que los rodea.
El sistema de traducción ETAP-3 usa una ontología OntoETAP para guardar la
información sobre las palabras. Este trabajo consiste en la extracción automáti-
ca de información, en concreto, relaciones qualia, para su implementación sobre
OntoETAP.
La teoría del Lexicón Generativo define una estructura de qualia tal que cada
concepto tiene cuatro roles qualia: formal, constitutivo, télico y agentivo. Estos
definen la taxonomía del concepto, sus partes constituyentes, su papel u objetivo
como entidad y la razón que le dió origen.
Además, se analizan los distintos recursos ontológicos existentes y se escoge la
ontología SUMO para extraer información de esta. Se explica el lenguaje SUO-
KIF usado en SUMO y los distintos métodos que permiten hallar las relaciones
qualia a extraer.
Posteriormente, se diseña en Python la aplicación que, mediante web scraping,
extrae las relaciones objetivo haciendo uso de las librerías Scrapy y RegEx. La
aplicación también traduce la información extraída a reglas para la ontología
OntoETAP usando el lenguaje Etalog.
Por último, se analizan los resultados obtenidos y su precisión, concluyendo los
posibles beneficios y mejoras.
i
Abstract
Modern systems that process natural language seek to match human abilities
of “communicating” and “understanding”. However, the human being is able to
understand messages thanks to their knowledge over surrounding enviroment.
The ETAP-3 translation system uses the OntoETAP ontology in order to store
information related to the word. This project consists in automatically extracting
information, in particular, qualia relations, for the OntoETAP ontology.
The Generative Lexicon theory defines the qualia structure so every concept has
four roles: formal, constitutive, telic and agentive. These denote the concept’s
taxonomy , its constitutive parts, their role or objective as an entity and the
reason why it exists.
Furthermore, the many ontological resources are analyzed and SUMO ontology
is chosen as the ontology to extract information from. The SUO-KIF language
used in SUMO and its existing relations, from which qualia relations are extrac-
ted, are explained.
Afterwards, an application is designed in Python which, via web scraping methods,
it extracts the desired relations making use of the Scrapy and RegEx libraries.
The application also translates the extracted información into rules for the On-
toETAP ontology in Etalog language.
Finally, the results obtained and the precision of these results are analysed, to
conclude the possible benefits and improvements of the application.
iii
Tabla de contenidos
1. Introducción 1
2. Estructura de qualia 3
3. Ontología 7
3.1. Top-level ontology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. ETAP-3 y la ontología OntoETAP . . . . . . . . . . . . . . . . . . . . . 10
3.3. Estudio de ontologías existentes . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. DOLCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. BFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3. gist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.4. SUMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. SUO-KIF 15
5. Metodología 19
6. Desarrollo 29
6.1. Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2. Modelo de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3. Inicialización del web crawler . . . . . . . . . . . . . . . . . . . . . . 31
6.4. Extracción de las relaciones qualia apropiadas. . . . . . . . . . . . . 33
6.5. Traducción de las relaciones SUO-KIF a Etalog. . . . . . . . . . . . . 40
7. Análisis de resultados y conclusiones 53
7.1. Resultados de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 53
7.2. Análisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.3. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
8. Análisis de impacto 73
Bibliografía 75
Anexos 79
v
Capítulo 1
Introducción
Desde hace doscientos años, el mundo ha entrado en un proceso de globaliza-
ción constante, la información se transmite en abundancia y en muchos idio-
mas. A día de hoy gozamos de una básica traducción automática que permite
esclarecer con grandes dificultades el mensaje, pero este sueño de conseguir
una completa traducción automática se remonta a tiempos muy anteriores con
Descartes o Leibniz. La traducción es una actividad muy antigua y reconocida,
distintos lingüistas analizan los idiomas y los traductores permiten transforma
el lenguaje escrito en una lengua a otra, sin embargo, con la aparición del pri-
mer ordenador, se dió el primer paso para automatizar medianto un ordenador
este costoso proceso. Warren Weaver, un reconocido criptógrafo, dió uno de los
primeros pasos para introducir la traducción mecanizada.
Durante muchos años, se lograrían numerosos avances en la traducción au-
tomática mediante teorías lingüísticas, pero ninguna sería fructuosa, se desa-
rrollaron diccionarios computacionales y proyectos importantes como ELIZA o
SHRDLU, este último se caracterizaba por entender lenguaje sencillo y objetivo
como figuras cúbicas de colores pero resultaba bastante limitado al no poder en-
tender palabras fuera del entorno. Este movimiento resultó en lo que se conoce
a día de hoy como lingüística computacional.
La lingüística computacional no es fácil de definir, se puede decir que es una
disciplina de la lingüística aplicada o una disciplina informática con bases lin-
güísticas. Está claro que esta disciplina involucra a partes iguales las áreas de
la lingüística y la informática y, a pesar de su origen, involucra más campos
de estudio que la traducción automática. Uno de los objetivos más importan-
tes es lograr el procesamiento automático de lenguaje natural mediante teorías
lingüística de la representación de la información, en otras palabras, se desea
poder saber la información del mensaje procesandolo por un ordenador de forma
automatizada.
A pesar de los continuos avances en nuestra época como sistemas de traducción
online o la extracción de información de textos importantes que utilizan, inclu-
so, buscadores importantes como Google, estas herramientas están lejos de ser
perfectas, existen muchos problemas como la ambigüedad y la inexactitud.
1
A partir de un párrafo simple de 30 palabras, se pueden encontrar más de
30.000 combinaciones, cada una siendo frases distintas. Un ejemplo fácil de
ver es el siguiente:
(1.1) El coche de modelo clásico azul claro.
Es fácil comprender que dicho “coche” (1.1) es “azul claro” y “de modelo clási-
co”. Sin embargo, para un ordenador esto no es evidente, existiendo múltiples
posibles interpretaciones.
(1.2) a. Coche de modelo clásico, coche azul claro
b. Coche de modelo clásico, coche azul, coche claro
c. Coche de modelo, coche clásico, coche azul, coche claro
d. Coche de modelo azul, coche clásico claro
e. Cochede modelo claro, coche clásico azul
f. Coche de modelo azul, coche clásico, coche claro
[. . . ]
Siete palabras son suficientes para que un ordenador no sepa como interpretar
una frase como ocurre en (1.2), aunque sea evidente que algunas de estas posi-
bilidades son carentes de sentido, un ser humano no tiene dudas pero un orde-
nador sí. Existen diversas teorías del lenguaje y la psicolingüística que intentan
explicar como la mente humana consigue interpretar el mensaje sin ambigüeda-
des, utilizamos nuestras experiencias y conocimiento adquirido para establecer
relaciones y contexto en palabras. En (1.3), se pueden observar distintas oracio-
nes donde existe información implícita de cada oración entre paréntesis.
(1.3) a. Sergio terminó su bebida. (terminar de beber)
b. Escribió el novelista con presteza. (escribir “con presteza”)
c. Comimos pan reciente. (pan recien horneado)
Para recolectar toda la información contextual entre palabras y conceptos, se
usan ontologías que guardan relaciones Qualia entre palabras. Las ontologías
son numerosas, dedicadas a determinados ámbitos y muy extensas, existe tanta
información que es difícil detallar todas las palabras del mundo que nos rodea
de forma correcta y adecuada. La finalidad de este trabajo es aplicar técnicas
modernas de extracción de relaciones Qualia, a partir de recursos ontológicos
existentes, para la ontología ETAP, analizando las teorías lingüísticas, los recur-
sos disponibles y las distintas metodologías de extracción de datos.
2
Capítulo 2
Estructura de qualia
La lingüística computacional ha avanzado hasta tal punto que es capaz de ana-
lizar la lexicología con grandes bases de datos léxicas y numerosos estudios de
la semántica léxica, los cuales permiten entender el significado de las palabras.
Aun así, no es suficiente con tener esta información, algunas oraciones tienen
la misma estructura pero su significado es completamente diferente.
(2.1) a. Juan se fue a Barcelona.
b. Juan se fue a un restaurante.
En (2.1.a), recibimos la información de que Juan viajó a Barcelona, mientras
que en (2.1.b), podemos inferir que Juan comió en un restaurante. No solo el
mensaje es completamente distinto, en cada oración se puede extraer informa-
ción adicional mediante el conocimiento de la hipotética situación, en (2.1.a),
sabemos que se hizo la acción de viajar, en (2.1.b), entendemos que se hizo la
acción de comer. Esto se debe, en concreto, a la información que sabemos de las
palabras “Barcelona” y “restaurante” puesto que “Barcelona” es un lugar turís-
tico o residencial y “restaurante” es un lugar donde se pide comida para comer
in situ.
El texto contiene información oculta en su contexto, que hay que analizar para
poder realizar una correcta interpretación, además, hace falta una buena re-
presentación de este contexto. Para dar solución a este problema, Pustejovsky
(1991) propuso la teoría del Lexicón Generativo[1, 2] donde expone el término
“estructura de qualia”, el cual agrupa cuatro aspectos del significado de una
palabra.
Quale, o Qualia en plural, proviene del Latín y significa “las propiedades sub-
jetivas intrínsecas a un objeto”. En la filosofía, las qualia caracterizan nuestra
concepción subjetiva de los sentimientos o ideas que evocan los objeto. Inspira-
do por Aristóteles, Pustejovsky se sirve de cuatro roles o relaciones qualia para
completar la estructura de qualia de una palabra, por ejemplo, una relación
qualia de “perro” es “ladrar” puesto que interpretamos que los perros realizan
la acción de ladrar, en concreto, este rol o relación recibe el nombre de “Télico”.
Los cuatros roles de una estructura de qualia son los siguientes:
3
Constitutivo: define los elementos constituyentes o partes del objeto. Un
ejemplo obvio es “coche”, su rol qualia constitutivo sería motor, puerta,
chasis, etc, ya que el coche esta formado por estas piezas. Sin embargo, no
solo incluye los elementos constituyentes, para “planta”, su relacion qualia
constitutiva sería raiz, tallo, hoja, flor, fruto, puesto que cada planta esta
dividida en estas partes.
Formal: define la categoría intrínseca o información taxonómica de la pa-
labra que lo constituye dentro de un dominio superior heredando sus pro-
piedades físicas. Otra forma de visualizar este concepto es la relación x
es y, por ejemplo, primate es mamífero, de esta forma, podemos decir que
la relacion qualia formal de “primate” sería “mamífero”, además, “primate”
hereda todas las propiedades físicas de “mamífero”.
Télico: define el objetivo o función. Por ejemplo, relacionado con (2.b), “res-
taurante” tiene la función de ser el lugar donde se prepara y se come la
comida por lo que su relacion télica es “comer_en”.
Agentivo: define la información que dió origen al objeto. Entre sus posibles
valores pueden ser su creador, el evento que lo creó o incluso la razón de su
existencia, por ejemplo, el evento que originó una casa es la construcción
por lo que el rol qualia agentivo de “casa” sería “construir”.
Una representación de la estructura qualia de la palabra violinista sería la si-
guiente y unos ejemplos de oraciones:
(2.2) violinista
Formal: humano
Télico: tocar
Agentivo: habilidad
(2.3) a. “Ella era una gran violinista” (Agentivo(violinista) = habilidad)
b. “El violinista impresionó al público” (Télico(violinista) = tocar)
El agentivo de violinista permite entender que, en (2.3.a), se elogia la habilidad
de la violinista, por otro lado, en (2.3.b), el télico de violinista ofrece información
sobre la acción del violinista ante el público, el cual es tocar un instrumento.
Sin embargo, nosotros sabemos evidentemente que un violinista toca un violín
y no existe esta información en la estructura de qualia. Para solucionar este
problema, definimos las relaciones n-arias, en concreto,definimos tocar(x,y) el
cual significa "x toca el instrumento", el resultado de añadir relaciones n-arias
sería el siguiente:
(2.4) violinista
Formal: humano
Télico: tocar(humano,violin)
Agentivo: habilidad(tocar(humano,violin))
4
Estructura de qualia
De hecho, este no es el único caso en el cual hace falta hacer una incisión
para expandir la información que debe representar una estructura de qualia,
sin embargo, para el fin de este trabajo, es decir, la extracción de relaciones
qualia, solo se analizará el anterior caso en detalle.
A continuación, se expondrá dos ejemplos ilustrativos de estructuras de qualias:
(2.5) a. “Los bomberos han estado muy ocupados debido al último incendio”
(Télico(bombero) = extinguir(incendios))
b. “No dudes en llamar a los bomberos si te caes a un pozo” (Télico(bombero)
= rescatar(humano))
• bombero
Formal: humano
Télico: extinguir(incendios), rescatar(humano), etc
(2.6) a. “Estas tijeras escolares son muy malas” (Télico(tijeras escolares) = cor-
tar)
b. “Por favor, coger las tijeras escolares por los mangos” (Constitutivo(tijeras
escolares) = mango)
• tijeras escolares
Formal: herramienta escolar
Constitutivo: hojas, eje, mango, tope
Télico: cortar
Cabe destacar que el proceso seguido para definir las estructuras de qualias
anteriormente ha sido desde el punto de vista lingüístico, desde la filosofía, no
es tan fácil definir un concepto, el problema es muy debatible si se empieza a
cuestionar cómo se define el fin de un objeto o que partes sí constituyen a una
entidad. En general, es muy difícil definir qué relaciones son correctas debido a
que las personas pueden diferir en ciertos aspectos debido a su distinto conoci-
miento, cultura o ideas preconcebidas y subjetivas.
5
Capítulo 3
Ontología
El origen de la ontología, como muchas otras ramas de la ciencia, nace de la
Antigua Grecia. Así, una ontología en el sentido filosófico es la explicación siste-
mática de la existencia como es percibida por los humanos. Sin embargo, existe
una gran controversia en su definición, y, heredado de su carácter filosófico,
existe un amplio debate sobre la aplicación informática de la ontología.
Una definición desde el punto tecnológico podríaser el siguiente, una ontología
es la representación de toda información estructurada de un campo específico
en un modelo informático. Evidentemente, esta afirmación es vaga y simple,
pero es útil para concebir una primera sencilla definición del concepto.
A la hora de representar un concepto existen dos problemas, entidades depen-
dientes de la mente y “términos generales”. Las relaciones qualia definidas pre-
viamente en el capítulo 2, permiten delimitar las propiedades subjetivas de las
entidades físicas, sin embargo, ¿qué ocurre con las propiedades de entidades
subjetivas como el concepto de “Unicornio”?
La realidad es que no existe ni definición formal ni presencia física del concepto
“Unicornio”, es decir, se trata de un concepto donde cada persona puede tener
una definición distinta. Este efecto no solo ocurre para objetos no existentes en
nuestra realidad, de la misma forma, cualquier objeto está sujeto a la malinter-
pretación de su concepto por la persona que esté definiendola, dando lugar a
distintas representaciones de la misma idea.
Por otro lado, filósofos debaten constantemente si verdaderamente existe una
definición universal y objetiva del concepto de “términos generales”, llamado
universalismo, y, aún existiendo, no se sabe cómo ha de ser representada. Es-
te debate involucra al estudio de la metafísica, así, la tarea de representar el
conocimiento se vuelve ardua.
Una buena ontología busca representar información de un dominio de una for-
ma estructurada tal que esta sea capaz de alcanzar la cantidad y precisión ob-
jetivo de la información. Si tuvieramos la palabra “bolsa de plástico”, su imple-
mentación en la ontología tendría dos formas, un plástico que forma una bolsa,
o una bolsa que tiene plástico como material. Resultaría lógico pensar que se
7
trata de una bolsa que tiene plástico como material, puesto que el término es
“bolsa de plástico” y no “plástico bolsa”, entonces, esta definición representaría
la palabra “bolsa de plástico” en la ontología por decisión propia de la persona
que así lo haya decidido.
Nótese que la información de la ontología dependerá plenamente de la informa-
ción que se busque representar, generalmente esta información y estudio de la
metafísica la realiza un experto en el dominio.
Obviamente, las ontologías no son iguales entre si, ni en los objetivos ni en
el modelo informático de implementación. A continuación, se mostrará algunos
ejemplos de tipos ontología sin entrar en detalle puesto que cada ontología puede
ser muy diferente dependiendo de cómo busca representar la información.
En bastante común que, en el ámbito de las matemáticas, las afirmaciones sobre
el conocimiento se expresen mediante lógica predicativa de primer o superiores
órdenes, como ocurre con la siguiente afirmación “Todas las personas tienen un
amigo”.
∀x(Person(x) =⇒ ∃y(Person(y) ∧ isFriend(x, y))) (3.1)
Sin embargo, la misma afirmación, definiciones y relaciones se pueden imple-
mentar mediante lenguajes de programación lógica como es PROLOG o Lógica
Descriptiva.
Person � ∃isFriend.Person (3.2)
El experto en el dominio decide el lenguaje de implementación a usar, por ejem-
plo, si se toma la decisión de implementar un conocimiento verbalizado como en
(3.1), se opta por lógica predicativa de primer orden. Sin embargo, si se prefiere
un conocimiento más digerido y fácil de interpretar como en (3.2), se opta por
Lógica Descriptiva.
El lenguaje más usado actualmente en ontologías es Web Ontology Laguage
OWL, el cual requiere conocimiento de su implementación mediante el formato
RDF/XML que permite un rápido procesado de fichero tipo texto donde se guar-
da la información del término de la ontología. El siguiente código es un ejemplo
muy corto del lenguaje OWL.
<owl:Class rdf:ID="VintageYear/>
<owl:DatatypeProperty rdf:ID= 2earValue»
<rdfs:domain rdf:resource="#VintageYear/>
<rdfs:range rdf:resource="&xsd;positiveInteger/>
</owl:DatatypeProperty>
</owl:Class>
Para una visualización más sencilla, se utiliza la herramienta de entorno de
desarrollo ontológico (ODE) como Protégé, creado por la Universidad de Stanford,
para acceder, manejar y desarrollar ontologías sencillamente.
8
Ontología
Figura 3.1: Imagen de la aplicación Protégé con la ontología gist abierta
3.1. Top-level ontology
Una ontología superior (Upper Ontology), ontología de nivel superior (Top-level
ontology) u ontología básica (foundational ontology) es un diseño de ontología
que busca representar con amplitud toda la información existente en la realidad
incluyendo conceptos abstractos como “proceso” y “objeto físico”. Este tipo de
ontologías son muy útiles para extraer cualquier tipo de información genérica
pero también son ambiciosas y complicadas, por lo que no existen muchas.
Las ontologías de nivel superior tienen dos características principales: taxono-
mía de clases y relaciones.
La taxonomía de clases se define como la clasificación jerárquica de los concep-
tos en subclases de otros conceptos. Es evidente reconocer que una manzana
es una fruta, es decir, “manzana” es subclase de “fruta”, además, “fruta” es un
subclase de “objeto físico”. Esto son universalismos relacionados generando re-
laciones taxonómicas entre sí, sin embargo, es común distinguir entre un objeto
único y su universalismo. El lenguaje OWL hace diferencia entre clase e ins-
tancia, una instancia es un objeto único definido de dicha clase, por ende, no
es lo mismo la manzana que compras en un supermercado que el universalis-
mo “manzana” ya que la manzana de supermercado puede estar podrida pero
eso no significa que todas las manzanas estén podridas. Las ontologías de nivel
superior buscan poder jerarquizar desde objetos intangibles a incluso acciones
temporales de forma sistemática.
Como se ha podido observar, los objetos tienen relaciones taxonómicas, en con-
creto, las ontologías buscan representar todas las relaciones existentes entre
conceptos. En cualquier ontología existente, tenemos relaciones dependientes
del dominio, como puede ser “inversión” con “dinero” en el dominio de merca-
do de acciones, pero resulta que “inversión” está relacionado con “dinero” en
el dominio de empresas. Algunas relaciones son independientes del dominio y
9
3.2. ETAP-3 y la ontología OntoETAP
son representadas en ontologías de nivel superior, algunas de estas relaciones
son relaciones qualia como “x es una parte de y” la cual solo encontraríamos en
ontologías de nivel superior u ontologías muy específicas cuyo dominio puede
incluir esta relación.
Es importante mencionar que los objetos tienen atributos, por ejemplo, en ge-
neral, los plátanos son de color amarillo, es decir, plátano tiene un atributo tipo
color el cual es amarillo. Sin embargo, existen plátanos que son rojos u otros co-
lores, además, otras ontologías pueden decidir que los colores pueden ser texto
simple, números hexadecimales o más. Algunas ontologías como DOLCE defi-
nen “Color” como una clase que, a su vez, es subclase de “Cualidad física” y el
color amarillo se definiría como instancia de la clase “Color”.
El campo de desarrollo objetivo de este trabajo es la lingüística computacio-
nal y el análisis de todo lenguaje natural. En el lenguaje coloquial y formal, se
usan términos y conceptos de cualquier dominio en las oraciones, por ende, es
primordial poder extraer información de las relaciones entre conceptos indepen-
dientes del dominio, por lo que estas ontologías de nivel superior son de suma
importancia para extraer información.
3.2. ETAP-3 y la ontología OntoETAP
ETAP-3 es un sistema de traducción creado por una institución académica que
busca emular la capacidad lingüística de un ser humano para “entender” y “ha-
blar”. Además, se trata de un sistema multifuncional con funciones importantes
como las siguientes:
Traducción máquina
Comunicación multilengua mediante interlengua
Parafrasear manteniendo el significado original
Interfaz de lenguaje natural a bases de datos
Para lograr estas funciones, se sirve de diccionarios completosde cada idioma
y una gramática comprensible. El proceso de análisis de oraciones se divide en
etapas que transforman el texto en una estructura normalizada completo de
significado.
Una opción de ETAP-3 es SemETAP, la cual se encarga de analizar el carácter
semántico de la oración mediante la estructura sintáctica de una frase SyntS en
dos niveles, BSemS interpreta el texto mediante información la ontología Onto-
ETAP y EnSemS realiza una serie de inferencias sobre BSemS.
Otras implementaciones como Cimiano tienen dominios específicos que deben
inicializarse con anterioridad, SemETAP busca una implementación de inferen-
cias con recursos ontológicos muy expresivos e independientes de dominio.
La ontología de ETAP, OntoETAP, usa formato RDF y el lenguaje Etalog, suficien-
temente expresivo para realizar inferencias sobre este y poder realizar consultas
SPARQL. Además, más de 200 mil entidades proceden de DBpedia.
10
Ontología
3.3. Estudio de ontologías existentes
La lista de ontologías existentes es demasiado larga, existen ontologías de mu-
chos dominios diferentes y con numerosas implementaciones. Por ejemplo, se-
gún el repositorio web de ontologías de dominio biomédico BioPortal, existen
más de 950 ontologías totales con numerosos fines, más de 14 millones de obje-
tos de estudio y alrededor de 36 mil propiedades, obviamente contando posibles
redundancias. Además, cada uno puede tener una implementación distinta o un
estándar asociado.
Objetivamente, la mayor parte de los estudios sobre recursos ontológicos se re-
ducen a dominios concretos y búsquedas muy específicas, pues suelen ser ob-
jetivo de extracción de información para máquinas de inferencias o inteligencia
artificial en campos concretos, como puede ser el estudio de enfermades relacio-
nadas o recolección de información en la biomedicina. Para el objetivo de este
trabajo, siendo esta la extracción de relaciones qualia sin ninguna selección de
dominio en concreto, se va a reducir la búsqueda de ontologías a un dominio
muy reducido puesto que no es realista catalogar +10.000 ontologías con un
nivel de detalle elevado.
Principalmente, las ontologías de este estudio van a ser ontologías públicas de
nivel superior, estas ofrecen mucha información relevante y estructurada, ade-
más, suelen ser proyectos públicos, colaborativos y moderablemente estandari-
zados lo cual implica un reducido y adecuado número de recursos ontológicos
accesibles para la extracción automática de relaciones qualia.
A pesar de esta simple delimitación del conjunto total de ontologías a investigar,
la realidad es que el número de buenas ontologías existentes es muy reducido.
Como se ha podido apreciar en este capítulo, las ontologías de nivel superior
son proyectos costosos y únicos, generalmente, la investigación de los recursos
accesibles resulta en la selección de una sola ontología, debido a ontologías
privadas, ontologías muy pequeñas y ontologías no útiles para los fines este
trabajo.
A continuación, se procederá a detallar los aspectos más importantes de distin-
tas ontologías existentes y su grado de utilidad en la extracción de relaciones
qualia como resultado de la investigación realizada.
3.3.1. DOLCE
También conocido como Descriptive Ontology for Linguistic and Cognitive En-
gineering (DOLCE), se caracteriza por su sesgo cognitivo, es decir, busca repre-
sentar las categorías ontológicas bajo el lenguaje natural y el sentido común
humano. Además, no hace uso de universales únicamente, se utilizan particu-
lares, los cuales son entidades sin instancias. Esto reduce el gran problema de
metafísica inherente al diseñar ontologías.
Una característica especial asociada a DOLCE es la existencia de variabilidad
temporal. Un ejemplo es una jarrón de arcilla, con el paso del tiempo, el jarrón
puede sufrir cambios radicales en su forma, topología y aperiencia, mientras que
11
3.3. Estudio de ontologías existentes
la cantidad de arcilla es invariante con el tiempo. Por lo tanto, son propiedades
diferentes pero coexisten en el jarrón de arcilla.
DOLCE es un modelo único, permite la distinción entre objetos abstractos y
físicos, dependencias espaciales, endurants y perdurants, las cuales definen en-
tidades existentes en cualquier momento o solo en ciertos espacios de tiempo
respectivamente. También existe la diferencia entre cualidad y calidad, o en in-
glés, quality y quality. Si se habla del color de una rosa, esta es la cualidad
de dicha rosa, si se habla del estado del color dado de la rosa, pasa a ser una
calidad.
Figura 3.2: Imagen de la jerarquía taxonómica DOLCE-lite
A pesar de tener propiedades relacionadas con el término quale, no afecta al
ámbito de relaciones qualia, por lo que no tiene ningún beneficio en este aspecto.
Por otro lado, realiza distinciones en las entidades dependiendo de su estado
temporal, característica que la ontología OntoETAP no tiene y puede llegar a
dificultar la implementación.
Sin embargo, el problema más importante de DOLCE es su implementación ac-
tual, DOLCE tiene como objetivo ser un modelo aplicable para nuevas ontologías,
por esto, no se trata de una ontología grande ni útil en sus pocas implementa-
ciones en OWL como DOLCE-lite o DOLCE+DnS Ultralight.
3.3.2. BFO
Desarrollado en el instituto IFOMIS en Leipzig, Basic Formal Ontology (BFO) es
una ontología de nivel superior que busca dar solución al problema del punto de
vista de la realidad 3-dimensional y 4-dimensional mediante una ontología Snap
de elementos estáticos y Span de eventos temporales. En comparación a DOLCE,
BFO trabaja con particulares y englosa un número de universales reconocidos
por BFO y denominados nominales.
BFO distingue entre endurants y perdurants, la ontología Snap registra todos los
endurants, los cuales sirven para delimitar los aspectos estáticos temporalmente
en la realidad, y la ontología Span registra los perdurants, sucesos, eventos y
entidades que tienen partes temporales. La ventaja subyacente de tener las dos
ontologías separadas es la relación de distintos elementos estáticos en Snap tal
que todos estos corresponden a los distintos espacios temporales de un elemento
de Span.
En su versión 1, se trataba de una ontología compuesta únicamente de taxo-
nomías, por ello, se sirve de una ontología de relaciones y propiedades llamada
12
Ontología
Figura 3.3: Relaciones temporales entre SNAP y SPAN
Relation Ontology (RO). Existen distintas extensiones de RO donde se propo-
nen distintas mejoras y consideraciones. Una vez más, la implementación de la
ontología no la convierte en un buen candidato de extracción de información.
3.3.3. gist
gist es una ontología de nivel superior minimalista creada por Semantic Arts. gist
tiene como objetivo servir como base para sistemas de información en empresas
que cubren el mayor número de conceptos ontológicos típicos de negocios con
la menor cantidad de ambiguedades.
Figura 3.4: Ejemplo de la ontología gist
Entre sus muchas características, destaca la desambigüedad, su robusted y su
fácil comprensión. En cambio, gist es una ontología OWL-RDF bastante pequeña
(alrededor de 140 clases y 130 propiedades) con conceptos muy concretos que
cualquier persona puede coincidir.
A pesar de la utilidad de gist, sus relaciones qualia podrían extraerse manual-
mente uno por uno sin errores con un margen temporal de días. gist no es una
ontología útil para realizar extracción automática de relaciones qualia, todas
sus relaciones se podrían extraer manualmente sin ningúna desventaja a una
extracción automática.
13
3.3. Estudio de ontologías existentes
3.3.4. SUMO
Como se ha visto previamente en este capítulo, una ontología de nivel superior
requiere conocimientos de filosofía e informática, además, las interpretaciones
e implementaciones son varias. Sin embargo, ante la falta de consenso por ex-
pertos de distintos campos, se propuso un estándar público, colaborativo y li-
bre para ontologías grandes de nivel superior llamado Standard Upper Ontology
(SUO). SUO estandariza los “términosgenerales” y sus definiciones y sirve co-
mo base para nuevas ontologías permitiendo la interoperabilidad entre sistemas
ontológicos que sigan el estándar SUO.
La ontología de nivel superior Suggested Upper Merged Ontology (SUMO) fue
creada en Teknowledge Corporation derivada de SUO. SUMO se creó uniendo
distintas ontologias públicamente accesibles y todavía sigue siendo un proyecto
colaborativo y en progreso. La implementación del conocimiento de SUMO se
realiza mediante una versión de Knowledge Interchange Format (KIF) llamada
SUO-KIF, la cual busca la rapidez y simplificación del formato KIF.
A día de hoy, SUMO tiene más de 25 mil términos (mapeados de WordNet) y
80 axiomas, la ontología es accesible tanto de forma online por portales web
o su descarga como base de datos relacional por github. El portal web Sigma
(accesible desde https://sigma.ontologyportal.org:8443/sigma/KBs.jsp)
tiene un motor de búsqueda integrado mediante WordNet[3], donde se puede
esribir cualquier palabra del inglés, y el motor de búsqueda ofrece el resultado
buscado como página web de fácil acceso y visualización.
Figura 3.5: Entrada de “Table” en el portal web Sigma de la ontología SUMO
En contraposición a ontologías con un punto de vista 4-dimensional, SUMO
adopta una orientación 3-dimensional al diferenciar entre objetos (Object) y pro-
cesos (Process) como términos diferentes.
No solo SUMO no tiene desventajas, además, tiene una enorme cantidad de
beneficios para la extracción de información, como una fácil representación de
la información y concordancia en términos con la ontología OntoETAP.
14
Capítulo 4
SUO-KIF
Una vez elegido SUMO como ontología objetivo de extracción, es necesario en-
tender cómo se escriben las relaciones en su lenguaje SUO-KIF. Esta sección
tiene como objetivo enseñar la mínima información necesaria para extracción
relaciones qualia, es decir, no se busca la comprehensión de los beneficios de
este lenguaje o su funcionamiento detallado como lenguaje sino poder entender
las relaciones y afirmaciones descritas mediante SUO-KIF.
SUO-KIF no es lenguaje de programación lógica como Prolog o una simple base
de datos relacional, está diseñado para ser un lenguaje de primer orden el cual
permite alcanzar una buena representación expresiva de la información sin lle-
gar a la complejidad de mayores órdenes. Diferente a cualquier otro lenguaje,
hay cuatro categorías de constantes, la cuales solo se diferencian semántica-
mente.
Para los siguiente ejemplos de relaciones en SUO-KIF:
(4.1) “(instance Germany Country)”
“(GovernmentFn Germany)”
(4.2) Constantes de objetos =⇒ Germany o Country
Constantes de funciones =⇒ GovernmentFn
Constantes de relaciones =⇒ instance
Constantes lógicas =⇒ True ó False
Una constante de objeto define entidades y clases en SUO-KIF, en la primera
frase de (4.1), se está inicializando la clase “Country” (País) con el nombre “Ger-
many” (Alemania). Mientras tanto, en la segunda frase de (4.1), una función
define a cada valor un objeto asignado, de esta manera, si “Germany” es el ob-
jeto que denota “Alemania” y “GovernmentFn” es una función que devuelve el
gobierno de algo, “(GovernmentFn Germany)” devuelve una constante de objeto
la cual es la entidad del gobierno de Alemania.
15
De forma análoga a constantes de objetos y funciones, una constante lógica es
True ó False, es decir, verdadero o falso, y una relación denota a una serie de
constantes de objetos tal que devuelve otra constante lógica. A pesar de su ex-
traña definición, esta constante se usa para denotar relaciones entre términos,
sin embargo, dentro de operadores lógicos, estas devuelven True si se verifica
la relación. Las relaciones más básicas son instance y subclass, por ejemplo,
“(instance The82ndAirbone MilitaryUnit)” se traduce a “La 82ª División Aero-
transportada es una unidad militar” y “(subclass Person Animal)” se traduce a
“La persona es un tipo/subclase de animal”.
SUO-KIF implementa los distintos operadores lógicos de lógica primer orden
que trabajan con constantes lógicas y relaciones: not, or, and, =>, <=>, exists
y forall. Las siguientes tablas sirven de ilustración para ver el comportamiento
de los operadores.
A (not A)
T F
F T
A B (or A B) (and A B) (=> A B) (<=> A B)
T T T T T T
T F T F F F
F T T F T T
F F F F T F
Las variables de SUO-KIF comienzan con ? o @ precedido de cualquier letra y
dígito. Si empieza por @, se trata de una sequencia de variables, aunque no
se entrará en detalle cómo se maneja todas las variables de la sequencia. Las
variables pueden tomar cualquier valor de objeto pero, semejante a lenguajes
lógicos de primer orden, se puede limitar el conjunto de valores que abarca con
los operadores exists y forall.
El operador exists limita la existencia de al menos un valor de la variable por el
cual se cumplen las condiciones lógicas que la involucran, devolviendo True si
se cumple esto o False si no es el caso. El operador forall, en cambio, exige el
cumplimiento de todas las condiciones lógicas que la involucran para todo valor
de variable posible de su conjunto, devolviendo True si se cumple o False si no
es el caso.
Por último, una afirmación es un conjunto de constantes, variables y operado-
res tal que caracterizan una propiedad o valor de un elemento. Para marcar el
inicio de una relación, función u operador, se abre paréntesis y la última cons-
tante o variable cierra el paréntesis, permitiendo encadenación de afirmaciones
e incluso permitiendo alcanzar órdenes superiores.
Un ejemplo de afirmación:
“A todos los granjeros les gusta el tractor”
1 (forall (?F ?T)
2 (=>
3 (and
4 (instance ?F Farmer)
5 (instance ?T Tractor))
6 (likes ?F ?T)))
16
SUO-KIF
La definición formal de la anterior afirmación es la siguiente: “Para todo ?F y ?T,
si ?F es un granjero y ?T es un tractor, entonces ?F le gusta ?T”.
Sin embargo, si una variable no está cuantificada por alguno de los operadores
exists o forall, su cuantificación dependerá del uso de la variable, si ocurre en
una query, se supone la existencia de un operador exists sobre la variable, en
otro caso se supone la existencia de un operador forall que obliga a la variable a
cumplir la afirmación para todo posible valor.
En el siguiente caso se puede observar como se puede omitir el operador forall
debido a la cuantificación obligatoria mencionada previamente.
“Todo el mundo tiene un amigo”
1 (exists ?SOMEONE
2 (friends ?SOMEONE ?X))
Donde la afirmación completa equivalente es:
1 (forall ?X
2 (exists ?SOMEONE
3 (friends ?SOMEONE ?X)))
La definición formal de la afirmación es la siguiente: “(Para todo ?X,) existe ?SO-
MEONE tal que ?X es amigo de ?SOMEONE”.
Las afirmaciones de la ontología SUMO suelen tener dos formas, relaciones di-
rectas e implicaciones, a continuación, se va mostrar distintos ejemplos de afir-
maciones en SUO-KIF pertenecientes a SUMO:
“Los caninos ladran”
1 (=>
2 (instance ?B Barking)
3 (exists (?D)
4 (and
5 (instance ?D Canine)
6 (agent ?B ?D))))
“Si ocurre una sequía en cualquier lugar, entonces no ocurren lluvias mien-
tras haya sequía en la región de dicho lugar”
1 (=>
2 (and
3 (instance ?DRYSPELL Drought)
4 (eventLocated ?DRYSPELL ?AREA))
5 (not
6 (exists (?RAIN ?PLACE)
7 (and
8 (instance ?RAIN Raining)
9 (instance ?PLACE Region)
17
10 (eventLocated ?RAIN ?PLACE)
11 (overlapsSpatially ?PLACE ?AREA)
12 (overlapsTemporally ?RAIN ?DRYSPELL)))))
“Las organizaciones que proveen equipamiento y recursos para la gardine-
ría o construcción tienen un miembro que vende objetos los cuales son o
recursos de construcción o recursos de agricultutra”
1 (=>
2 (and
3 (instance ?ORG Organization)
4 (attribute ?ORG
BuildingMaterialAndGardenEquipmentAndSuppliesDealers))
5 (exists (?EV ?MEM)
6 (and
7 (member ?MEM ?ORG)
8 (agent ?MEM ?EV)
9 (exists (?THING)
10 (and
11 (instance ?EV Selling)
12 (instance ?THING Object)
13 (or
14 (capability Constructing resource ?THING)
15 (capability Agriculture resource ?THING))
16 (patient ?EV ?THING))))))
“El gato domético es un animal doméstico”1 (subclass DomesticCat DomesticAnimal)
“El cepillo o peine tiene la función de servir de instrumento para quitar algo
ó modificar la superficie de algo”
1 (=>
2 (instance ?B BrushOrComb)
3 (hasPurpose ?B
4 (exists (?S)
5 (and
6 (or
7 (instance ?S Removing)
8 (instance ?S SurfaceChange))
9 (instrument ?S ?B)))))
18
Capítulo 5
Metodología
Antes de empezar el desarrollo de la aplicación, hace falta evaluar la metodología
a aplicar para extraer la información de relaciones qualia. Como se ha podido
observar en el capítulo anterior, SUO-KIF es un lenguaje muy expresivo y sus
relaciones no son directas. Para extraer relaciones qualia a partir de la informa-
ción de SUMO, hace falta catalogar y decidir cuales relaciones deben ser extraí-
das y cuales no aportan información y hace falta ver cómo SUMO representa las
relaciones qualia.
Sea el término “Automóvil” (Automobile) perteneciente a SUMO, Automobile es
una entrada de SUMO muy completa respecto al número de relaciones por lo
que es un buen ejemplo para analizar.
La primera regla de Automobile es su documentación. La documentación de
cada término de SUMO nos ofrece un poco de información al respecto mediante
lenguaje natural. Cada documentación sigue la siguiente estructura.
1 (documentation Elemento Idioma "Texto de la documentacion")
Para el caso de Automobile, su documentación sería la siguiente.
1 (documentation Automobile EnglishLanguage "Automobile is a subclass of
SelfPoweredRoadVehicles including passenger cars, family vans,
light trucks, and sport utility vehicles. In general, this class
covers four-wheeled passenger road vehicles.")
Donde se obtiene un texto que define ligeramente Automobile, este texto men-
ciona algunas subclases de Automobile, pero lo más importante es “Automobile
is a subclass of SelfPoweredRoadVehicles[...]” donde se expone que Automobile
es subclase de SelfPoweredRoadVehicle, es decir,
(5.1) Automobile
Formal: SelfPoweredVehicle
19
De hecho, esto no solo ocurre con relaciones de subclase, a continuación se va
a mostrar una serie de ejemplos donde se puede obtener distintas relaciones
qualia a partir de la documentación.
(5.2) Documentación del término “Carta” (Letter):
1 (documentation Letter EnglishLanguage "A brief message which is
intended to be mailed to a person or Organization.")
Letter
Télico: be mailed to a Person or Organization
(5.3) Documentación del término “Bolsa/Bolso” (Bag):
1 (documentation Bag EnglishLanguage "A Pliable Container with the
purpose of Transfer of Object.")
Bag
Télico: Transfer of Object
(5.4) Documentación del término “Mesa” (Table):
1 (documentation Table EnglishLanguage "A piece of Furniture with
four legs and a flat top. It is used either for eating,
paperwork or meetings.")
Table
Constitutivo: four legs and a flat top
(5.5) Documentación del término “Artefacto” (Artifact):
1 (documentation Artifact EnglishLanguage "An Object that is the
product of a Making.")
Artifact
Agentivo: Making
Cada documentación denota propiedades qualia importantes mediante palabras
específicas como se puede observar en (5.1-5) con las palabras subclass, inten-
ded, purpose, with y product. Sin embargo, el análisis de lenguaje natural es
mucho más complicado, identificar las entidades relacionadas con el término re-
quiere un análisis sintáctico. A veces incluso, algunas palabras no existen como
términos en la ontología, en (5.4), aparece el término “flat top” pero no existe ni
flat top ni top en ninguna forma variante dentro de las ontologías, por esta
razón, la documentación se añadirá como texto plano pues su análisis es dema-
siado complejo debido a redundancias y lenguaje natural (esta decisión se debe
20
Metodología
a la interoperabilidad y la posibilidad de hacer un programa flexible que extraiga
relaciones qualia independientemente del lenguaje de la ontología final).
Avanzando en las entrada de Automobile, aparecen las relaciones externalImage,
termFormat, industryProductType y subclass. externalImage simplemen-
te es un link a una imagen de dicho término y termFormat es una traduc-
ción del término en distintos idiomas, por lo que ambos resultan irrelevantes.
industryProductType, en cambio, define el tipo de industrias de origen tal que
1 (industryProductType AutomobileManufacturing Automobile)
define al automóvil como un producto originario de industrias de fabricación
de automóviles. Existe un detalle importante de esta relación, el automóvil es
originario de una fabricación, es decir, el rol agentivo de Automobile debería
ser AutomobileManufacturing. Sin embargo, en SUMO, estas entidades son
atributos de organizaciones y no eventos, es decir, según SUMO, el rol agentivo
de automóvil no es el tipo de una industria AutomobileManufacturing, sino el
evento de fabricar objetos Manufacture. Por esta razón, esta relación no tendrá
ningún valor en la extracción de relaciones qualia.
La relación subclass es bastante directa, siempre define el rol formal de su
primer argumento.
1 (subclass Automobile PassengerVehicle)
2 (subclass Automobile PhysicalSystem)
3 (subclass Automobile SelfPoweredRoadVehicle)
(5.6) Automobile
Formal: SelfPoweredVehicle, PhysicalSystem, PassengerVehicle
Agentivo: Manufacturing
Como se puede observar en (5.1) y (5.6), SelfPoweredVehicle ya estaba descu-
bierto gracias a su documentación, en general, la documentación ofrece menos
información respecto a subclases en comparación con estas relaciones. El resto
de relaciones de subclases de Automobile no son relevantes para las qualia de
Automobile.
Al final de estas relaciones/afirmaciones básicas sin implicaciones lógicas, apa-
recen dos términos, typicalPart y typicallyContainsPart. En concreto,
typicalPart es una relación complicada por la siguiente razón:
1 (typicalPart AutoSuspensionSystem Automobile)
Esta relación implica que la suspensión es usualmente una parte del coche.
Aunque parezca contradictorio, typicalPart no siempre define un rol qualia de
un término. Si bien typicalPart nos dice que un automóvil tiene una suspen-
sión, rol constitutivo, realmente esta relación no tiene por qué ser válida para
todas las entidades. Sea el siguiente ejemplo inventado para un edificio.
21
1 (typicalPart Bedroom Building)
Esta relación nos dice que un dormitorio es usualmente una parte de un edificio,
lo cual es completamente cierto, pero un edificio no tiene por qué tener un dor-
mitorio, de hecho, una gran parte de edificios no tiene dormitorio. typicalPart
no debería definir generalmente un rol qualia bajo esta definición, sin embargo,
en SUMO, muchos términos tienen sus partes definidas de esta forma, como
es el caso del tracto gastrointestinal que está formado por el esófago, intestino,
boca, recto y estómago:
1 (typicalPart Esophagus GastroIntestinalTract)
2 (typicalPart Intestine GastroIntestinalTract)
3 (typicalPart Mouth GastroIntestinalTract)
4 (typicalPart Rectum GastroIntestinalTract)
5 (typicalPart Stomach GastroIntestinalTract)
La entrada del término relacionado a tracto gastrointestinal solo tiene estas re-
glas (y su documentación) que mencionan sus partes constituyentes. Por esta
razón, se ha obtado incluir a typicalPart como definición de rol constitutivo
a pesar de que esto no debería ser así. El caso de typicallyContainsPart es
trivial, sí forma rol constitutivo.
Un caso no mencionado en Automobile es la relación initialPart.
1 (initialPart Hair Animal)
Según la definición de initialPart, esta relación implica que para cada “pelo”
que exista, este pertenece a un animal, aunque este animal luego en otro tiempo
pueda perder este pelo. Esto define un rol constitutivo si no se tiene en cuenta
el factor temporal.
Avanzando en la entrada de Automobile una vez más, se puede ver todas las
afirmaciones de implicación donde Automobile pertenece como antecedente o
consecuente.
Estas implicaciones pueden llegar a ser complejas y variantes en muchos aspec-
tos fundamentales. Se ha observado como se comportan las distintas relaciones
qualia pertenecientes a estasafirmaciones de implicación. Frente al alto grado
de error al intentar localizar las relaciones qualia, se ha priorizado encontrar el
conjunto completo de relaciones qualia con falsos positivos a encontrar solo un
porcentaje de todas las relaciones qualia sin capacidad de error. Como resulta-
do, se ha optado por seguir un método sencillo para poder localizar todas las
relaciones qualia aunque esto implique extraer relaciones que no pertenezcan al
qualia del término.
De todas las afirmaciones existentes, podemos encontrar las siguientes relacio-
nes qualia de rol constitutivo.
22
Metodología
(5.7) Concepto = Automobile
1 (=>
2 (and
3 (instance ?C Clutch)
4 (instance ?A Automobile)
5 (instance ?E Engine)
6 (instance ?G Gearbox)
7 (instance ?GEAR Gear)
8 (part ?GEAR ?G)
9 (part ?G ?A)
10 (part ?C ?A)
11 (part ?E ?A)
12 (instance ?M Motion)
13 (patient ?M ?E)
14 (attribute ?C DeviceOff))
15 (exists (?M2)
16 (and
17 (instance ?M2 Motion)
18 (patient ?M2 ?G)
19 (causes ?M ?M2))))
(5.8)
1 (=>
2 (and
3 (instance ?ECS EngineCoolingSystem)
4 (instance ?E Engine)
5 (instance ?A Automobile)
6 (part ?ECS ?A)
7 (part ?E ?A))
8 (hasPurpose ?ECS
9 (exists (?C)
10 (and
11 (instance ?C Cooling)
12 (instrument ?C ?ECS)
13 (patient ?C ?E)))))
(5.9)
1 (=>
2 (instance ?A Automobile)
3 (equipmentCount ?A Axle 2))
(5.10)
1 (=>
2 (instance ?A Automobile)
3 (equipmentCount ?A VehicleWheel 4))
En (5.7) y (5.8), podemos encontrar las relaciones part la cual denota que un
objeto es parte de otro, aun así, en situaciones normales, esto no es suficiente
para denotar relación qualia de rol constitutivo pero, en general, si que ofrece
23
información sobre relaciones qualia posibles. En (5.7), se tiene que el motor
(Engine) es parte del automóvil (Automobile) y el motor verdaderamente toma
un rol constitutivo en la estructura de qualia de automóvil. Por otro lado, las
relaciones (5.9) y (5.10) dicen que un automóvil tiene 2 ejes y 4 ruedas, entonces,
equipmentCount es importante porque siempre son relación qualia.
Cabe destacar que estas relaciones ofrecen información sobre el funcionamiento
de las componentes, aunque pueda no ser relevante desde el punto de vista
de la estructura de qualia, Etalog es un lenguaje que puede usar parte de esta
información completa, este punto de vista se tratará en el capítulo de traducción
de las reglas.
Para finalizar la búsqueda de qualias con rol constitutivo, existe una relación
que no existe en la entrada de Automobile, para ello, se muestra la siguiente
afirmación de “Edificio” (Building) que define una habitación como parte de un
edificio.
Concepto = Building
1 (=>
2 (instance ?ROOM Room)
3 (exists (?BUILD)
4 (and
5 (instance ?BUILD Building)
6 (properPart ?ROOM ?BUILD))))
Anteriormente en (5.8), se ha podido ver la relación hasPurpose, aunque no
estaba relacionada con el término Automobile, esta relación define el rol télico
de un objeto. A continuación se va a ver unos cuantos ejemplos de hasPurpose.
(5.11) Concepto = Seat
1 (=>
2 (instance ?SEAT Seat)
3 (hasPurpose ?SEAT
4 (exists (?PERSON)
5 (and
6 (instance ?PERSON Human)
7 (located ?PERSON ?SEAT)
8 (attribute ?PERSON Sitting)))))
Seat
Télico: Human Sitting
Asiento sirve para que un Humano se coloque en el asiento y pase a estar
sentado.
(5.12) Concepto = Bag
1 (=>
2 (instance ?BAG Bag)
24
Metodología
3 (hasPurpose ?BAG
4 (exists (?T ?OBJ)
5 (and
6 (instance ?T Transfer)
7 (instance ?OBJ Object)
8 (contains ?BAG ?OBJ)
9 (instrument ?T ?BAG)
10 (patient ?T ?OBJ)))))
Bag
Télico: Transfer contained Object
Bolsa/Bolso sirve para transferir un objeto contenido.
(5.13) Concepto = Hammer
1 (=>
2 (instance ?H Hammer)
3 (hasPurpose ?H
4 (exists (?I ?N)
5 (and
6 (instance ?I Impelling)
7 (instrument ?I ?H)
8 (patient ?I ?N)
9 (instance ?N Nail)))))
Hammer
Télico: Impelling Nail
Martillo sirve para Impulsarse y el Clavo es afectado por el impulso.
“Martillo sirve para clavar Clavos”
(5.14) Concepto = Device
1 (=>
2 (instance ?DEVICE Device)
3 (exists (?PROC)
4 (hasPurpose ?DEVICE
5 (exists (?INST)
6 (and
7 (instance ?INST ?PROC)
8 (instrument ?INST ?DEVICE))))))
Device
Télico: Instrument
Dispositivo es instrumento para algo.
En (5.11-14), se puede observar que el rol télico de cada entidad no es tan inme-
diato, hasPurpose funciona de tal manera que define una serie de relaciones que
25
se deben cumplir. Esto se debe a que SUO-KIF, al fin y al cabo, es un lenguaje de
primer orden que permite definir funciones que no pertenecen directamente a la
ontología o permite expandir información al respecto. Esto es un problema para
definir una estructura qualia pero, para el lenguaje Etalog, se puede conseguir
reglas equivalentes.
En (5.12-14), se puede ver la existencia de la relación instrument, este denota
la entidad de servir para realizar un evento, sin embargo, es otro claro caso de
una relación que no aporta información fiable sobre el rol télico como se puede
ver en los siguientes dos ejemplos.
(5.15) Concepto = Mouth
1 (=>
2 (and
3 (instance ?BITE Biting)
4 (agent ?BITE ?ANIMAL))
5 (exists (?MOUTH)
6 (and
7 (instance ?MOUTH Mouth)
8 (part ?MOUTH ?ANIMAL)
9 (instrument ?BITE ?MOUTH))))
Mouth
Télico: Biting
(5.16) Concepto = Face
1 (=>
2 (and
3 (instance ?EXPRESS FacialExpression)
4 (agent ?EXPRESS ?AGENT))
5 (exists (?FACE)
6 (and
7 (part ?FACE ?AGENT)
8 (instance ?FACE Face)
9 (instrument ?EXPRESS ?FACE))))
Face
Télico: FacialExpression
En (5.15), el rol télico de la boca es morder, aunque esta afirmación pueda ser
debatible, no sería incorrecto en cierto grado. En cambio, en (5.16), el rol téli-
co de la cara es hacer expresiones faciales, sin embargo, la cara no tiene una
función definida, a pesar de ser nuestro medio para mostrar emociones, esta se
trata únicamente de una parte visual de la anatomía de un ser vivo pues forma
la apariencia. Aun así, se ha tomado en cuenta para la extracción de relaciones
qualia al igual que otras relaciones debatibles de este capítulo.
Para finalizar la extracción del rol télico, existen dos relaciones útiles las cuales
26
Metodología
son capability y hasSkill. Si bien sufren del mismo problema que instrument,
se ha podido hallar un factor clave que marca el verdadero rol télico de la enti-
dad. Véase con los siguientes ejemplos.
(5.17) Concepto = Intestine
1 (=>
2 (instance ?I Intestine)
3 (capability Digesting instrument ?I))
Intestine
Télico: Digesting
(5.18) Concepto = Writer
1 (=>
2 (attribute ?PERSON Writer)
3 (hasSkill Writing ?PERSON))
Writer
Télico: Writing
Ambas relaciones son muy directas, en (5.17), se define al intestino como el
instrumento para digestión, nótese la importancia de instrument para esta re-
lación puesto que si un objeto tiene la capacidad de hacer algo, en general, este
tiene el rol télico si es el instrumento por el cual se puede hacer dicha acción. En
(5.18), solo los seres vivos tienen habilidades y si un individuo tiene una habili-
dad, en general, esta es su función como individuo. Así, finalizando la extracción
de los roles télicos de una entidad.
Para finalizar, queda el rol agentivo, este es mucho más sencillo y directo. Des-
graciadamente, existen muy pocas entidades en SUMO que tienen definidas su
razón de nacimiento u origen, la única relación directa encontrada se puede ver
en los dos siguientes ejemplos.
(5.19) Concepto = Text o Document
1 (=>
2 (and
3 (attribute ?X Writer)
4 (or
5 (instance ?TEXT Text)
6 (instance ?TEXT Document))
7 (instance ?WRITE Writing)
8 (agent ?WRITE ?X)
9 (result ?WRITE ?TEXT))
10 (authors ?X ?TEXT))
Document
27
Agentivo: Writing
Text
Agentivo: Writing
(5.20) Concept = Text
1 (=>
2 (instance ?W WrittenCommunication)
3 (exists (?T ?C ?S)
4 (and
5 (result ?W ?T)
6 (instance ?T Text)
7 (part ?C ?T)
8 (instance ?C Character)
9 (instance ?S Script)
10 (member ?C ?S))))
Text
Télico: Writing, WrittenCommunication
Aquí se puede observar la existencia de la relación result donde un texto es
resultado de la escritura o la comunicación escrita. Esta relacióndice que un
objeto es resultado de un evento y, evidentemente, esto define el rol agentivo de
la entidad con un alto grado de confianza.
Nótese en (5.19) que aparece authors, esta relación define el creador de una
entidad, el cual forma parte del rol agentivo de una entidad. Solo existen dos
únicas entidades en SUMO que definen su autor gracias a esta relación, texto y
programa electoral.
La importancia de este capítulo ha sido delimitar cómo se va a realizar la extrac-
ción de relaciones qualia, pues esta no depende de la implementación escogida.
De igual forma, se puede argumentar que la traducción al lenguaje Etalog no
depende de la implementación, sin embargo, Etalog es un lenguaje que admite
ampliar la definición de ciertas reglas, expandiendolas más allá de la estructura
de qualia por lo que la traducción depende de cómo se diseña la aplicación y
cómo se guarda la información extraida.
28
Capítulo 6
Desarrollo
La varias implementaciones de la información en la ontología SUMO son ideales
para la extracción de datos. Sin embargo, SUMO es inusual respecto al resto
de ontologías, no está originalmente implementado en OWL y tiene un portal
web de acceso a la información contenida de SUMO mediante términos. Por esta
razón, existen dos métodos de extracción de datos sobre SUMO.
El primer método consiste en realizar queries sobre la ontología SUMO mediante
sus ficheros KIF, un fichero RDF o una traducción al formato OWL. Este método
no es tan directo como parece, existen varias formas de lograr realizar queries,
comúnmente mediante SPARQL, para encontrar nodos de la base de datos pero
SUMO no guarda una relación directa entre distintos nodos, haría falta, además,
localizar todas las relaciones donde estos nodos participan expresados en el
lenguaje SUO-KIF.
El segundo método es más inusual aunque igual de efectivo y más sencillo, web
scraping. El portal web de SUMO tiene implementado un buscador mediante
la ontología WordNet que ofrece directamente todas las relaciones asociadas al
término buscado. El programa consistiría en acceder a la página correspondien-
te mediante un web scraper, extraer las relaciones asociadas y realizar parsing
para hallar las relaciones qualia más adecuadas.
Respecto al primer método, existe un trabajo extenso de la universidad de Colo-
rado en Boulder de extracción automática de relaciones qualia sobre SUMO para
la ontología REO cuya aplicación implementa su propio método de extracción de
términos y relaciones asociadas[4]. Este trabajo, en cambio, se va a orientar so-
bre la extracción de relaciones qualia mediante web scraping sobre el portal web
de SUMO.
Web scraping es una técnica muy común para extraer información de sitios web
que consiste en establecer una conexión automática con la página para extraer
información automáticamente a partir de su HTML o para simular las acciones
de un usuario en la página web. El inconveniente que tiene es su aspecto ético,
los métodos de web scraping pueden saturar el servidor debido al aumento de
tráfico e, incluso, los servidores web pueden tener mecanismos para detectar
y bloquear el acceso de web scrapers. El portal web de SUMO no tiene una
29
6.1. Python
política en contra de web scraping, por lo que este método de extracción de
datos es perfectamente ético siempre y cuando la ejecución de la aplicación no
tenga efectos negativos sobre la página web.
6.1. Python
Python es un lenguaje de programación de alto nivel con gran legibilidad que
destaca por su gran comunidad de librerías y frameworks. Python destaca sobre
otros lenguajes gracias a estas librerias que permiten el uso de Python para
cualquier tipo de aplicación como la extracción de datos mediante web scraping
y será el lenguaje escogido para el desarrollo de la aplicación.
Existen varias librerías dedicadas únicamente para aplicaciones de web scra-
ping, existen librerías de web scraping via HTTP o navegador web como Sele-
nium, librerías de web scraping via web crawlers como Scrapy y librerías para
parsing de ficheros HTML y XML como Beautiful Soup.
Selenium es una librería principalmente usada para el testeo de aplicaciones
web, por esta razón, otros lenguajes de programación para tests como Java con
JUnit son más utilizados para Selenium, además, el tiempo de ejecución de un
navegador es demasiado alto e innecesario para este trabajo.
Scrapy, por otro lado, es la librería perfecta a usar en la extracción automática
de datos. Aunque no ofrece la capacidad de interacción con la página, Scrapy
permite obtener toda la información de la página como fichero HTML o como
objetos tipo response con cada elemento HTML. Posteriormente, la información
extraida pasaría por un parser.
Existen distintas librerías para parsing como Beautiful Soup que nos permite
trabajar sobre ficheros html, sin embargo, la extracción a extraer son solo ele-
mentos simples de la página, por lo que Scrapy es suficiente para extraer la
información deseada. Aun así, la información contenida ha de ser modificada y
analizada por lo que es necesario hacer uso de la librería RegEx que trabaja con
expresiones regulares para analizar con detalle la sintaxis de cada relación.
En conclusión, la aplicación de extracción automática se va a realizar con Python
y las librerías Scrapy y RegEx únicamente.
6.2. Modelo de la aplicación
El modelo de la aplicación toma un papel fundamental en la organización de la
aplicación. Desde el comienzo del desarrollo de la aplicación, se ha dividido el
proceso de extracción por web scraping en varias fases simples y secuenciales.
Paso 1. Inicialización del web crawler sobre un término dado.
Paso 2. Extracción de las relaciones qualia apropiadas.
Paso 3. Traducción de las relaciones SUO-KIF a Etalog.
30
Desarrollo
La decisión de fases secuenciales se debe a que Scrapy funciona mediante web
crawlers, lo cuales son procesos concurrentes que extraen la distinta informa-
ción deseada. Para evitar cualquier posible colapso de página web tras la eje-
cución de la aplicación, se va a seguir un proceso lineal, es decir, la aplicación
esperará a que finalize cada web crawler antes de ejecutar el siguiente.
Además, se ha considerado importante definir los objetivos o outputs de la apli-
cación los cuales son la extracción de relaciones qualia procedentes de un tér-
mino proporcionado por el usuario, guardarlas en fichero de texto y, posterior-
mente, traducirlas. Esta forma de operar permite hacer peticiones de extracción
de relaciones qualia sobre un término, lo cual es extremadamente útil para que
una aplicación externa pueda generar o actualizar las relaciones de un elemento
de la ontología. Aparte, se ha decidido no elegir un formato especial para guardar
las relaciones como puede ser bases de datos como MongoDB o formato RDF,
KIF u OWL. Las relaciones estarán escritas en Etalog, las cuales no necesitarán
de un formato dedicado para guardar la información.
6.3. Inicialización del web crawler
Un web crawler de Scrapy es especial, se trata de una clase Spider de Python
que genera peticiones sobre una url y ejecuta una función proporcionada, ade-
más, devuelven respuestas las cuales son objetos que proporcionan información
sobre la petición finalizada y nada más. Los web crawlers se ejecutan mediante
una función de línea de comandos y funcionan mediante un reactor que no es
reiniciable, es decir, para realizar una nueva extracción sobre una nueva página,
se ha de realizar fork del proceso o ejecutar nuevamente la aplicación.
Para sortear esta dificultad, se ha creado un fichero aparte main.py que ejecuta
el crawler de Scrapy mediante las siguientes líneas de código.
1 from scrapy.crawler import CrawlerProcess
2 import extrAuto.spiders.qualia_spider as qspider
3
4 process = CrawlerProcess()
5 process.crawl(qspider.QualiaSpider, start_url=str(sys.argv[1]))
6 process.start()
Primero se importa CrawlerProcess y luego el Spider qualia_spider de
qualia_spider.py que Scrapy va a usar para extraer información. Se inicializa
un proceso y se proporciona elSpider a usar junto al argumento del término a
proporcionar. Finalmente, process.start() espera a que finalizen los crawlers
antes de proseguir con el código, permitiendo controlar cuando han terminado
los crawlers. Cabe destacar que no soluciona del todo el problema del reactor
de Scrapy, para extraer de un nuevo término, se ha de ejecutar main.py nueva-
mente, de ahi la importancia se conocer cuando terminan los crawlers.
Mientras tanto, se crea una carpeta llamada “extrAuto”, todos los archivos de
configuración del web crawler los cuales no se han modificado y el fichero
qualia_spider.py define la clase de Python de la siguiente forma.
31
6.3. Inicialización del web crawler
1 class QualiaSpider(scrapy.Spider):
2 name = "qualia"
3
4 def __init__(self, *args, **kwargs):
5 super(QualiaSpider, self).__init__(*args, **kwargs)
6
7 self.start_urls = [’https://sigma.ontologyportal.org:8443/sigma
/Browse.jsp?flang=SUO-KIF&lang=EnglishLanguage&kb=SUMO&term
=’+kwargs.get(’start_url’)]
8
9 def start_requests(self):
10 yield scrapy.Request(url=self.start_urls[0], callback=self.
parse)
Todo Spider debe ser identificado con un name único y debe tener la función
start_requests(). El argumento proporcionado se registra en la función __init__
donde guarda la url de la página del término a extraer relaciones qualia. start_request()
inicia una petición con la url inicial tal que ejecuta la función dedicada al parsing
que se llama parse.
Sin embargo, surge un problema con el web crawler, como ya se ha explicado an-
tes, son procesos concurrentes que extraen información al mismo tiempo por lo
que si cada uno intentara modificar el mismo fichero, pueden destruir o desor-
ganizar el contenido dentro de este. Para combatir este problema, normalmente,
se dedica un proceso concurrente aparte que crea una cola de peticiones para
modificar el fichero y añade cada petición de forma secuencial, aun así, la pro-
babilidad de desorganización es bastante alta puesto que las peticiones pueden
modificar distintas partes del fichero a la vez.
La solución escogida es más simple, aunque consume un poco más de memoria,
se ha decidido usar un diccionario como variable global donde se guardan listas
con las reglas escogidas. Como se accede a un diccionario, y posteriormente se
modifica una lista, se ha usado una implementación mediante candados que
bloquean la variable global para un uso síncrono entre hilos.
Las primeras líneas de los imports y variables globales en el fichero qualia_spider.py,
son las siguientes:
1 import scrapy
2 import re
3 import threading
4
5 C = ’constitutive’
6 F = ’formal’
7 T = ’telic’
8 A = ’agentive’
9
10 qualias = {’term’ : "", ’constitutive’ : list(), ’formal’ : list(), ’
telic’ : list(), ’agentive’ : list()}
11
32
Desarrollo
12 lock = threading.Lock()
Se ha decidido utilizar acortamientos para cada rol de la estructura de qualia
para su facilitar la comprensión y reducir cualquier error al escribir por parte
del programador.
6.4. Extracción de las relaciones qualia apropiadas.
En esta sección, se detallará el funcionamiento de la función parse para extraer
relaciones qualia.
Cuando Scrapy establece conexión con el servidor remoto, genera un objeto lla-
mado response el cual es el encargado de extraer información de la página. Las
aplicaciones de web scraping hacen uso de dos selectores que permiten localizar
elementos HTML: XPath y CSS.
CSS es un lenguaje para aplicar estilos sobre HTML, la aplicación hace uso úni-
camente del selector CSS para saber cómo verdaderamente se escribe el término
de la entrada, el cual se encuentra en el texto procedente del título y, poste-
riormente, se guarda el término en el diccionario en caso de que no existiera
antes.
1 if not qualias[’term’]:
2 qualias[’term’] = response.css("title::text").get().split()
[0]
Por otro lado, para hallar el resto de elementos, se usa XPath por razones de
comodidad. XPath usa las etiquetas de los elementos HTML y sus atributos
para crear una “dirección”. Por ejemplo, el siguiente selector encuentra todos
los hiperenlaces.
1 $x(’//a’)
Si se desea coger el nodo padre del elemento cuando el padre tiene la etiqueta
“p”, se toma el siguiente XPath.
1 $x(’//p/a’)
En caso de no especificar la etiqueta de algún elemento, se utiliza un asterisco.
En el siguiente ejemplo, se coge cualquier nodo padre de un hiperenlace sin
importar su categoría.
1 $x(’//*/a’)
Sin embargo, XPath tiene una función clave para la extracción de información,
como bien se ha visto en el capítulo 5, se busca relaciones con un nombre en es-
pecífico, una sola palabra clave. Sea el caso donde se busca todas las relaciones
33
6.4. Extracción de las relaciones qualia apropiadas.
subclass, se utiliza la función “contains(text(),’keyword’)” donde keyword es la
palabra clave que se busca.
1 $x("//a[contains(text(),’subclass’)]")
Este XPath devuelve todas los hiperenlaces donde aparece subclass, es im-
portante buscar hiperenlaces porque el portal web de SUMO guarda todas las
entradas y relaciones referenciadas como hiperenlaces en vez de texto plano.
En la entrada del término Automobile, sea el siguiente código (implementación
del selector XPath mediante el objeto response en Python) y las entradas extraí-
das.
1 print(["".join(re.split(’<[^<>]*>’,incidences.get())) in incidences
from response.xpath("//a[contains(text(),’subclass’)]/..")])
Salida del print:
1 [’(subclass Automobile PassengerVehicle)’,
2 ’Automobile is a subclass of passenger vehicle’,
3 ’(subclass Automobile PhysicalSystem)’,
4 ’Automobile is a subclass of physical system’,
5 ’(subclass Automobile SelfPoweredRoadVehicle)’,
6 ’Automobile is a subclass of self powered road vehicle’,
7 ’(subclass ChevroletAutomobile Automobile)’,
8 ’ChevroletAutomobile is a subclass of automobile’,
9 ’(subclass CommodoreAutomobile Automobile)’,
10 ’CommodoreAutomobile is a subclass of automobile’,
11 ’(subclass Corvette Automobile)’,
12 ’Corvette is a subclass of automobile’,
13 ’(subclass FordAutomobile Automobile)’,
14 ’Ford car is a subclass of automobile’,
15 ’(subclass HoldenToranaAutomobile Automobile)’,
16 ’Holden Torana is a subclass of automobile’,
17 ’(subclass MiniCooper Automobile)’,
18 ’Mini cooper is a subclass of automobile’,
19 ’(subclass Taxicab Automobile)’,
20 ’Taxicab is a subclass of automobile’]
Como se puede observar, se obtiene la relación y su traducción en lenguaje
natural. Es irrelevante la traducción a lenguaje natural para este trabajo por que
solo se necesita coger las relaciones SUO-KIF, es decir, los elementos impares.
Además, las relaciones de subclases de automóvil tampoco son relevantes para
la estructura de qualia de Automobile.
Aquí participa la librería RegEx, las relaciones buscadas tienen una estructura
sintática a seguir, por lo que mediante expresiones regulares, se puede verificar
si una relación tiene la sintaxis buscada.
34
Desarrollo
1 for incidences in response.xpath("//a[contains(text(),’subclass’)]/..")
:
2 text = "".join(re.split(’<[^<>]*>’,incidences.get()))
3 var1 = re.search(’\(instance\ (\?\w+)\ ’+qualias[’term’]+’\)’,
text)
4 varTerm = qualias[’term’] if not var1 else ’(?:\\’+var1[1]+’|’+
qualias[’term’]+’)’
5 regPattern = ’\(subclass\ ’+varTerm+’\ [\w|\?]\w*\)’
6 var2 = re.search(regPattern, text)
7 if (var2) and not (text in qualias[F]):
8 with lock:
9 qualias[F] += [text]
Para cada resultado obtenido a partir de XPath, se verifica los siguiente: el tér-
mino de la entrada aparece de forma explícita o en forma de variable de SUMO
(las variables empiezan siempre por ’?’, por ejemplo, ?X es un nombre de varia-
ble), se verifica que la relación tiene la siguiente estructura,
1 (subclass Termino RolFormal)
en cuyo caso de ser así, se verifica que no está repetido y se introduce en el dic-
cionario qualias bajo un cerrojo para evitar problemas de memoria compartida.
Con este código, se puede obtener todas las relaciones qualia de rol formal ya
que son muy sencillas y directas.
La extracción del texto plano a partir dela documentación funciona de igual ma-
nera, se busca la palabra documentation y se extrae aquello que se encuentre
entre comillas. Si contiene alguna palabra clave que denote un rol de la estruc-
tura de qualia, se extrae el texto a su correspondiente rol.
1 for incidences in response.xpath("//td/a[contains(text(),’documentation
’)]/.."):
2 text = "".join(re.split(’<[^<>]*>’,incidences.get()))
3 desc = re.search(’\"([^\"]*)\"’, text)
4 if desc:
5 desc = desc[1]
6 if "subclass" in desc:
7 with lock:
8 qualias[F] += [desc]
9 elif ("purpose" in desc) or ("designed" in desc) or ("intended"
in desc):
10 with lock:
11 qualias[T] += [desc]
12 elif ("result" in desc) or ("product)" in desc):
13 with lock:
14 qualias[A] += [desc]
15 elif "with" in desc:
16 with lock:
17 qualias[C] += [desc]
35
6.4. Extracción de las relaciones qualia apropiadas.
Para extraer las relaciones qualia de rol constitutivo, existen muchas palabras
clave y, en concepto, funciona igual que en el caso del rol formal. En cambio, la
estructura sintáctica de las relaciones cambia para ciertas relaciones.
typicalPart
1 (typicalPart RolConst Termino)
typicallyContainsPart
1 (typicallyContainsPart RolConst Termino)
equipmentCount
1 (equipmentCount Termino RolConst Numero)
part
1 (part RolConst Termino)
properPart
1 (properPart RolConst Termino)
Como se puede observar, todas las relaciones tienen la misma estructura sintáti-
ca excepto equipmentCount, por lo que la nueva expresión regular regPattern
es la siguiente en el código.
1 for incidences in response.xpath("//td/a[contains(text(),’
typicallyContainsPart’) or contains(text(),’typicalPart’) or
contains(text(),’equipmentCount’) or contains(text(),’part’) or
contains(text(),’properPart’)]/.."):
2 text = "".join(re.split(’<[^<>]*>’,incidences.get()))
3 var1 = re.search(’\(instance\ (\?\w+)\ ’+qualias[’term’]+’\)’, text
)
4 varTerm = qualias[’term’] if not var1 else ’(?:\\’+var1[1]+’|’+
qualias[’term’]+’)’
5 regPattern = ’(?:\((?:typicallyContainsPart|part|properPart|
typicalPart)\ ([\w|\?]\w*)\ ’+varTerm+’\)|\(equipmentCount\ ’+
varTerm+’\ ([\w|\?]\w*)\ \d+\))’
6 var2 = re.search(regPattern, text)
7 if var2 and not (text in qualias[C]):
8 if str(var2[1]).startswith(’?’):
9 auxvar = re.search(’\(instance\ \\’+var2[1]+’\ \w+\)’, text
)
10 if auxvar:
11 with lock:
12 qualias[C] += [text]
36
Desarrollo
13 else:
14 with lock:
15 qualias[C] += [text]
Hay una pequeña diferencia extra en relación a los anteriores códigos, se ha
observado que las relaciones qualia la cuales no instanciaban el tipo del rol no
aportaban más información que “existe relación qualia”.
El mismo código se repite con el caso del rol agentivo con una nueva expresión
regular y las palabras clave result y authors.
1 for incidences in response.xpath("//td/a[contains(text(),’result’) or
contains(text(),’authors’)]/.."):
2 text = "".join(re.split(’<[^<>]*>’,incidences.get()))
3 var1 = re.search(’\(instance\ (\?\w+)\ ’+qualias[’term’]+’\)’, text
)
4 varTerm = qualias[’term’] if not var1 else ’(?:\\’+var1[1]+’|’+
qualias[’term’]+’)’
5 regPattern = ’\(?:(result|authors)\ ([\w|\?]\w*)\ ’+varTerm+’\)’
6 var2 = re.search(regPattern, text)
7 if var2 and not (text in qualias[A]):
8 if str(var2[1]).startswith(’?’):
9 auxvar = re.search(’\(instance\ \\’+var2[1]+’\ \w+\)’,
text)
10 if auxvar:
11 with lock:
12 qualias[A] += [text]
13 else:
14 with lock:
15 qualias[A] += [text]
Por último, en la extracción del rol télico, surge una distinción, para las palabras
clave hasPurpose, capability e instrument, las estructuras sintácticas son
las siguientes:
hasPurpose
1 (hasPurpose Termino
capability
1 (capability RolTelico instrument Termino)
instrument
1 (instrument RolTelico Termino)
Y su código de extracción de estas relaciones es el siguiente:
37
6.4. Extracción de las relaciones qualia apropiadas.
1 for incidences in response.xpath("//td/a[contains(text(),’hasPurpose’)
or contains(text(),’capability’) or contains(text(),’instrument’)
]/.."):
2 text = "".join(re.split(’<[^<>]*>’,incidences.get()))
3 var1 = re.search(’\(instance\ (\?\w+)\ ’+qualias[’term’]+’\)’, text
)
4 varTerm = qualias[’term’] if not var1 else ’(?:\\’+var1[1]+’|’+
qualias[’term’]+’)’
5 regPattern = ’(?:\(hasPurpose\ ’+varTerm+’\\n|\(capability\ ([\w
|\?]\w*)\ instrument\ ’+varTerm+’\)|\(instrument\ ([\w|\?]\w*)\
’+varTerm+’\))’
6 var2 = re.search(regPattern, text)
7 if var2 and not (text in qualias[T]):
8 if str(var2[1]).startswith(’?’):
9 auxvar = re.search(’\(instance\ \\’+var2[1]+’\ \w+\)’,
text)
10 if auxvar:
11 with lock:
12 qualias[T] += [text]
13 else:
14 with lock:
15 qualias[T] += [text]
Sin embargo, para hasSkill, a pesar de tener la misma estructura sintácti-
ca que instrument, su término no es instanciado, se proporciona un atributo
por medio de la relación attribute. Para no generar conflictos con el anterior
código, se ha separado en un bucle for distinto.
1 for incidences in response.xpath("//td/a[contains(text(),’hasSkill’)
]/.."):
2 text = "".join(re.split(’<[^<>]*>’,incidences.get()))
3 var1 = re.search(’\(attribute\ (\?\w+)\ ’+qualias[’term’]+’\)’,
text)
4 varTerm = qualias[’term’] if not var1 else ’(?:\\’+var1[1]+’|’+
qualias[’term’]+’)’
5 regPattern = ’\(hasSkill\ ([\w|\?]\w*)\ ’+varTerm+’\)’
6 var2 = re.search(regPattern, text)
7 if var2 and not (text in qualias[T]):
8 if str(var2[1]).startswith(’?’):
9 auxvar = re.search(’\(instance\ \\’+var2[1]+’\ \w+\)’, text
)
10 if auxvar:
11 with lock:
12 qualias[T] += [text]
13 else:
14 with lock:
15 qualias[T] += [text]
Con cada bloque de código, la función parse es capaz de extraer las relaciones
qualia de la página, pero las páginas a veces tienen un enlace a otra página que
38
Desarrollo
tiene más relaciones del término seleccionado. En el portal web, estos enlaces
aparecen repetidos uno debajo de otro por lo que solo es necesario acceder a
uno.
1 next_pages = response.xpath("//a[contains(text(),’Show next 25’)]/@href
").getall()
2 next_pages = [x for i,x in enumerate(next_pages) if i % 2 == 1]
3
4 if next_pages:
5 for page in next_pages:
6 next_url = response.urljoin(page)
7 yield scrapy.Request(next_url, callback=self.parse)
El código encuentra el elemento con el enlace y, aprovechando la concurrencia,
se generan nuevos procesos, cada uno accediendo a la nueva página con la
función parse para extraer el resto de relaciones qualia, si este a su vez tiene
enlaces a nuevas páginas, se repetirá en proceso.
El fichero main.py se encarga de leer el diccionario de qualia_spider.py y
guardarlo en un fichero de texto.
1 nrel = len(qspider.qualias[qspider.C]) + len(qspider.qualias[qspider.F
]) + len(qspider.qualias[qspider.T]) + len(qspider.qualias[qspider.
A])
2
3 if nrel > 0:
4 filename = f’relaciones/{qspider.qualias["term"]}-{str(nrel)}.txt’
5
6 with open(filename, ’w’) as f:
7
8 f.write("Term = "+qspider.qualias[’term’]+"\n\n")
9
10 f.write("Constitutive:\n"+",\n".join(qspider.qualias[qspider.C
])+"\n\n")
11 f.write("Formal:\n"+",\n".join(qspider.qualias[qspider.F])+"\n\
n")
12 f.write("Telic:\n"+",\n".join(qspider.qualias[qspider.T])+"\n\n
")
13 f.write("Agentive:\n"+",\n".join(qspider.qualias[qspider.A])+"\
n\n")
14
15 print(f’Saved file {filename}’)
16 else:
17 print("No file was created")
Si el diccionario extraído está vacío, no crea ningún fichero de texto. En caso de
generar fichero de texto, este se guarda en una carpeta llamada “relaciones” y
el nombre del fichero está compuesto por el término extraído, por ejemplo, de
Automobile, el nombre de su fichero es Automobile.txt.
39
6.5. Traducción de las relaciones SUO-KIF a Etalog.
6.5. Traducción de las relaciones SUO-KIF a Etalog.
Las reglas extraídas de SUMO contienen parte de información de relaciones qua-
lia, pero muchas veces añaden información no deseada. Para eliminar relaciones
no interesantes, la traducción tiene dos fases: traducir la afirmación entera a ser
posible y extraer solo las relaciones qualia directas e importantes.
Sea el resultado de traducción