Incorporación de un buscador semántico en la plataforma ...
Transcript of Incorporación de un buscador semántico en la plataforma ...
Incorporación de un buscador semántico
en la plataforma LdShake para la
selección de patrones educativos
Camacho Rodríguez, María
Curs 2012-2013
Director: Davinia Hernández-Leo,
Jonathan Chacón Pérez
GRAU EN ENGINYERIA EN TELEMÀTICA
Treball de Fi de Grau
GRAU EN ENGINYERIA EN
xxxxxxxxxxxx
Incorporación de un buscador semántico en la
plataforma LdShake para la selección de patrones
educativos
María de la Palma Camacho Rodríguez
TRABAJO FIN DE GRADO
Ingeniería de Telemática
ESCUELA SUPERIOR POLITÉCNICA UPF
2013
DIRECTORES DEL TRABAJO
Davinia Hernández-Leo, Jonathan Chacón Pérez.
ii
iii
Te dedico el final de estos años
que tan bien me has hecho pasar. JK.
v
Agradecimientos
En primer lugar quiero agradecer a mi madre y hermanos por todo lo que han hecho
estos años para brindarme la oportunidad de llegar hasta aquí.
Gracias también a todos mis amigos, y mucho a K, que me han aguantado los días de
agobio, sin dejar de animarme ni un momento.
Y por último, pero no menos importante, agradecer a los directores del proyecto,
Davinia y Jon, y a Pablo por tener tanta paciencia y ayudarme en todo lo que podían.
vii
Resumen Actualmente las tecnologías web 2.0 apoyan al docente a complementar su docencia y/o
facilitarle recursos online para sus actividades. Para realizar estos recursos se les puede
apoyar con patrones de aprendizaje, éstos dan soluciones en forma de plantillas para la
resolución de problemas conocidos. Sin embargo, el docente se puede sentir abrumado
por la cantidad de patrones existentes y para ello es necesario algún tipo de mecanismo
que facilite la selección del patrón a utilizar.
En este trabajo se pretende realizar un modulo en la plataforma LdShake donde se
pondrá a disposición del usuario un mecanismo que facilite, mediante una consulta con
palabras, la selección de un patrón inicial. Apoyados en las herramientas de Web
Semántica, las consultas se realizan sobre una ontología, una representación
computacional de un lenguaje de patrones. Además estas consultas se complementaran
con sinónimos o hiperónimos utilizando recursos de la búsqueda semántica.
Abstract Nowadays web 2.0 technologies help teachers to complement their teaching and/or
facilitate online resources for their activities. Learning patterns can support practitioners
to achieve these resources since they provide solutions in a structured way for the
resolution of known problems. However, the teacher may feel overwhelmed due to the
vast quantity of existing patterns. For this reason there is need to have some kind of
mechanism to facilitate the election of the learning pattern to be used.
This work aims to provide a module in the LdShake platform where the selection of an
initial pattern will be provided through a query mechanism. Supported by Semantic
Web tools, queries are performed on ontology, a computer representation of a pattern
language. Moreover, these queries are complemented with synonyms or hyperonyms
using semantic search resources.
ix
Índice
Pàg.
Resumen......................................................................... vii
Lista de Figuras............................................................... xi
Lista de Tablas................................................................ xii
1. INTRODUCCIÓN .................................................................................................... 1 1.1 Contexto.................................................................................................................. 1
a) LdShake ................................................................................................................ 1
b) E-learning ............................................................................................................. 2 c) Learning Management System ............................................................................. 2 d) Web 2.0 ................................................................................................................. 4
e) Web Semántica ..................................................................................................... 5 1.2 Objetivos del proyecto ............................................................................................ 6 1.3 Metodología ............................................................................................................ 7 1.4 Planificación temporal ............................................................................................ 8
a) Planificación temporal inicial ............................................................................... 8
b) Planificación temporal ........................................................................................ 10 1.5 Estructura de la memoria ...................................................................................... 11
2. ESTADO DEL ARTE ............................................................................................ 13 2.1 Query .................................................................................................................... 13
a) Búsqueda por palabra clave ................................................................................ 13 b) Búsqueda semántica ........................................................................................... 14
2.2 Procesamiento del Lenguaje Natural .................................................................... 15
a) Herramienta adicional: WordNet........................................................................ 17
2.3 Visualización de la Información ........................................................................... 19 a) Grafos ................................................................................................................. 20
b) Tree-map ............................................................................................................. 20
c) Tag Cloud ........................................................................................................... 21
3. ANÁLISIS DEL SISTEMA ................................................................................... 23 3.1 Requisitos ............................................................................................................. 23
a) Requisitos funcionales ........................................................................................ 23 b) Requisitos no funcionales ................................................................................... 24 3.2 Caso de uso ........................................................................................................... 24
4. DISEÑO ................................................................................................................. 29 4.1 Diseño de la API ................................................................................................... 29 4.2 Diseño de la Visualización ................................................................................... 32
5. IMPLEMENTACIÓN ............................................................................................ 35 5.1 Implementación de la API .................................................................................... 35 a) Introducción de la consulta y procesado del texto .............................................. 35
b) Consulta de WordNet ......................................................................................... 35 c) Filtrado de palabra .............................................................................................. 39
d) Llamada a ontología ........................................................................................... 40
x
e) Búsqueda del patrón ........................................................................................... 42
5.2 Implementación de la Visualización ..................................................................... 43 5.3 Integración en LdShake ........................................................................................ 45
6. PRUEBAS .............................................................................................................. 47 6.1 Pruebas de validación de requisitos ...................................................................... 47
6.2 Pruebas con usuarios ............................................................................................ 47 6.3 Pruebas ejemplos .................................................................................................. 47
a) Consulta con resultados ...................................................................................... 48 b) Consulta sin resultados ....................................................................................... 49
7. CONCLUSIONES Y TRABAJOS FUTUROS ..................................................... 51 7.1 Conclusiones ......................................................................................................... 51
7.2 Trabajos futuros .................................................................................................... 51
8. BIBLIOGRAFÍA .................................................................................................... 53
9. ANEXOS ................................................................................................................ 55 9.1 Anexo A-Manual de Instalaciones ....................................................................... 55
a) WordNet-3.0 ....................................................................................................... 55 b) Apache Tomcat6 ................................................................................................. 55 c) PHP-Java Bridge ................................................................................................ 55
9.2 Anexo B-Código ................................................................................................... 57 a) Función searchWordNet ..................................................................................... 57
b) Función searchSyns ............................................................................................ 57
c) Función filterWords ............................................................................................ 58
d) Función callOntology ......................................................................................... 59 e) Función searchPatterns ...................................................................................... 59
f) Función Visualización ........................................................................................ 60 9.3 Anexo C-Glosario ................................................................................................. 62
xi
Lista de figuras
Figura 1: Esquema CMS en un entorno de Learning Desing 2
Figura 2: Esquema general de un LMS 3
Figura 3: Diferencias entre Web 1.0 y Web 2.0 4
Figura 4: Comparación red de datos y red semántica 5
Figura 5: Ejemplo de ontología 6
Figura 6: Planificación temporal inicial del proyecto 9
Figura 7:Planificación temporal final del proyecto 10
Figura 8: Resultado de la búsqueda en Google “arreglar gato” 13
Figura 9: Resultado de la búsqueda en Hakia “arreglar gato” 15
Figura 10: Ejemplo de Grafo, co-ocurrencias entre SO 20
Figura 11: NewsMap 21
Figura 12: Tag Cloud de la búsqueda “arreglar gato” 21
Figura 13: Casos de uso 25
Figura 14: Pruebas captcha por tráfico inusual de Google 30
Figura 15: Resultado de cat en WordNet 31
Figura 16: Diagrama de secuencias de una query 33
Figura 17: Ejemplo de visualización 33
Figura 18: Mensaje para la ausencia de resultados 34
Figura 19: Pantalla principal de la aplicación 35
Figura 20: Funciones a implementar por WordNet 3.0 36
Figura 21: Resultado de la función –synsn para “cat” 37
Figura 22: Resultado de la función –synsn para la query “cat dog” 37
Figura 23: Resultados vacios para una consulta en WordNet de las
palabras vacías “where” y “for”
40
Figura 24: Ontología del patrón Facilator 41
Figura 25: Consulta del patrón “pyramid” 45
Figura 26: Prueba de visualización 47
Figura 27: Introducción consulta prueba 48
Figura 28: Resultados consulta prueba 48
Figura 29: Visualización patrón “Brainstorming” consulta prueba 49
xii
Lista de tablas Tabla 1: Ejemplos de synsets y definiciones de la palabra “cat” 18
Tabla 2: Ejemplos de synsets hipónimos y sus definiciones sobre
el primer sentido de la palabra “cat”
19
Tabla 3: Requisitos funcionales del sistema 24
Tabla 4: Requisitos no funcionales del sistema 24
Tabla 5: Formato caso de uso 25
Tabla 6: Caso de uso: realizar query 26
Tabla 7: Caso de uso: leer documento resultado 27
1
1. INTRODUCCIÓN
Un patrón describe un problema que ocurre una y otra vez en nuestro entorno, y a
continuación describe el núcleo de la solución a dicho problema, de tal modo que pueda
utilizarse un millón de veces sin ejecutarse en dos ocasiones del mismo modo [1]. Es
decir, cuando, en un contexto determinado, bajo unas condiciones dadas podremos
utilizar un patrón determinado para llegar a la solución a algún problema.
En este proyecto trabajaremos sobre un entorno de apoyo al profesorado (e-Learning),
creando una aplicación, sobre el Framework ELGG, para la facilitación de patrones de
aprendizaje, a partir de una consulta del profesor involucrado.
A continuación estudiaremos el contexto donde se mueve nuestro proyecto así como los
objetivos marcados por el proyecto, la metodología seguida, la planificación temporal, y
una pequeña explicación sobre la estructura de la memoria.
1.1 Contexto
Actualmente los patrones de aprendizaje son modelos eficaces utilizados por el
profesorado, para la realización eficiente de una actividad concreta que quiera cumplir
con unos objetivos determinados. Estos, por su capacidad, se han convertido en una
herramienta util para la docencia.
El conjunto de patrones y sus relaciones, formarán lo que se llama lenguaje de patrones.
De esta forma, un lenguaje de patrones, nos permite describir buenas soluciones y las
relaciones entre los diferentes patrones en un entorno específico. El problema es que
este lenguaje no es computable por la máquina. Una aproximación para solucionar esto
es el uso de las ontologías, para así definir vocabularios que la máquina pueda entender.
La consulta de un usuario acerca de un patrón se podría realizar de varias formas. Una
de las opciones es la denominada búsqueda de la palabra clave, en la cual se realizará un
barrido entre la información más relevante de cada patrón, consultando si en ella se
contienen las palabras destacadas introducidas por el usuario. Este sería el caso de
buscadores como Google o Yahoo!.
Este procedimiento no resulta eficaz, pues la consulta nos puede dar como resultados
textos que, aunque contengan las palabras claves introducidas, no tiene porque ser
relevante para el usuario, es decir, resultados ruidosos. Por lo tanto, cuenta con escasa
precisión en los resultados, además de la importancia en el cuidado en la expresión
introducida por el usuario, ya que la búsqueda se llevará a cabo estrictamente en función
de los términos introducidos.
Como solución a esta búsqueda poco relevante, en este proyecto estudiaremos otra
forma de realizar la consulta, basándonos en la semántica. Es decir, profundizaremos en
los significados de las palabras introducidas. Por ejemplo, si un profesor realiza una
búsqueda sobre “agrupación”, también se tengan en cuenta patrones que contengan
información sobre “asociación”, “reunión”... etc. Con este recurso conseguiremos que
las búsquedas tengan más precisión con la consulta que quiere realizar el usuario.
Además se minimiza la interacción del usuario con el buscador, ya que este mediante
una sola consulta puede obtener el patrón, o patrones, requerido/s.
a) LdShake
LdShake es un Sistema Gestor de Contenidos (acrónimo en inglés, CMS), una
plataforma para apoyar a los profesores en la creación de contenidos educativos, creada
por el GTI de la UPF. Esta plataforma nació por la necesidad de una herramienta
2
mediante la cual los usuarios pudieran publicar y coeditar sus UoL (unit of learning)
para que otros usuarios puedan utilizar y a su vez proporcionar feedback. Esta
interaccion la podemos ver en el siguiente esquema de la Figura 1:
Figura 1: Esquema CMS en un entorno de Learning Desing [2].
LdShake se basa en el framework ELGG, descrito en el punto C de este apartado, lo que
le permite contar con las funcionalidades ya implementadas en este, como son la gestión
de usuarios y el modelo MVC (model-view-controller). Además as partir de esta base se
crean los plugin que controlarán todas las tareas relacionadas con LdShake, algunas de
las funcionalidades son la visualización de trabajos y la edición de estos. El mayor
interés de LdShake es promover una mayor colaboración entre los usuarios.
b) E-learning
Definiremos e-learning como una forma de aprendizaje o enseñanza, haciendo uso de
las nuevas tecnologías multimedia y de Internet. De esta manera se facilita el acceso a
recursos y servicios, independientemente de límites de horarios y espaciales, así como
los intercambios y colaboración.
Antiguamente, para la educación a distancia, hacía falta envíos de los diferentes tomos
en los que se dividía la materia, así como el intercambio de diferentes test o actividades
alumno-profesor. E-learning se considera pues como una solución ideal.
Hoy en día, gracias a la Web 2.0, podemos contar con un entorno de producción más
colaborativo, donde los usuarios son los responsables de la aportación de contenidos.
Además ahora se puede contar con itinerarios de aprendizaje personalizados, donde se
puedan realizar una motivación y un mejor seguimiento del alumno, por parte del
profesor. Una de las plataformas más populares, donde podemos encajar e-learning, son
las redes sociales, como LdShake, donde el alumno puede compartir e intercambiar
conocimientos y opiniones.
c) Learning Management System
Un Sistema de Gestión de Aprendizaje (LMS, Learning Management System) es una
aplicación de software, instalada en un servidor. Un LMS es un sistema para la
administración, distribución y el control de actividades e-learning o no presenciales de
una organización o institución [3]. Es decir, es el lugar donde alumnos, tutores o
3
profesores se conectan a través de Internet para descargar contenidos, debatir en foros,
realizar tutorías, etc.
Las funciones principales de un LMS son la administración de estudiantes y dar
seguimiento a su aprendizaje, participación y desempeño. Con esto se consigue la
planificación de cursos, característica importante de un LMS.
Otras de las características más destacadas de un LMS son: (i) La mayoría de los LMS
funcionan con tecnología web, (ii) utilizan una base de datos para organizar planificar y
gestionar el aprendizaje, (iii) carece de herramientas para la creación de contenidos, es
decir, no incluye posibilidades de autoría, sino que se centra en gestionar contenidos
creados por fuentes diferentes.
Un esquema general de un LMS será el mostrado en la Figura 2:
Figura 2: Esquema general de un LMS [4].
Existe una gran variedad de LMS de los cuales podemos destacar:
- Sistemas propietarios: iLearning by Oracle, Aulapp, eCollege, WebCT, e-
learning Manager, etc.
- Sistemas libres: ELGG, ATutor, Moodle, Claroline, SWAD, etc.
- ELGG
ELGG es un framework de red social, es decir, proporciona la funcionalidad básica para
ejecutar una red social, ya sea públicamente o internamente en una intranet. Además en
temas de desarrollo, ELGG es muy extensible, siendo fácil agregar la funcionalidad que
se desee a través de los plugnis.
La principal característica de ELGG, que la distingue de otras redes sociales
comerciales, es el grado de control que un usuario tiene sobre quien puede acceder a su
contenido, dándose la posibilidad de asignar restricciones de acceso propias, por
ejemplo, acceso a un solo individuo, acceso a un determinado grupo, pública o privada.
Otras de las características interesantes de ELGG para nuestro trabajo son:
- Gestión de usuarios, objetos, archivos y lugares.
- Funcionalidad gráfica social: relaciones entre los usuarios y relaciones tanto
entre usuarios y objetos como entre usuarios y lugares.
- Múltiples puntos de vista, lo que permite aplicaciones móviles y widgets
embebidos, así como la vista del navegador Web tradicional.
4
- El uso de conexiones de bases de datos múltiples para la escalabilidad.
- Todo el sistema, basado en etiquetas para la búsqueda a través de todos los
contenidos y los usuarios.
- Multilenguaje
- Plugin APIs…
Todo esto lo hace muy apropiado como base para LdShake, debido a su gestión de
usuarios, contenidos, tareas de administración, base de datos y demás plugins
adicionales.
d) Web 2.0
A diferencia de la Web 1.0, donde se encuentran sitios web no-interactivos en los cuales
los usuarios se limitan a la visualización pasiva de información que se les proporciona,
surge la Web 2.0, donde se permite a sus usuarios interactuar con otros usuarios o
cambiar contenido del sitio web, actuando como productores de contenidos. En la
siguiente imagen, Figura 3, podemos observar ilustradamente las diferencias
mencionadas, entre la Web 1.0 y la Web 2.0.
Figura 3: Diferencias entre Web 1.0 y Web 2.0 [5].
La Web 2.0 se trata por tanto, de una nueva manera de concebir la Web que conforma
nuevas tecnologías y la implicación del usuario en la generación de contenidos.
Algunas de las herramientas que se consideran profundamente asociadas con la Web 2.0
son los blogs, wikis, “podcasts”, sistemas de sindicación simple (RSS), etc. que facilitan
una Web socialmente más conectada en la que se estimula y se aprovecha la inteligencia
colectiva. Ldshake se entiende como una aplicación enmarcada dentro de la Web 2.0.
Las aportaciones de la Web 2.0 en el aprendizaje abre muchas posibilidades en
investigación educativa, como: la formación del profesorado, las estrategias y técnicas
de enseñanza, con nuevos roles de profesores y alumnos, cuestiones organizativas,
utilización de herramientas educativas 2.0, servicios virtuales, etc [6].
5
e) Web Semántica
La Web 3.0, se creó como una nueva etapa destinada a añadir significado a la web, y
por ello, Tim Berners-Lee, creador de la World Wide Web, acuñó el concepto de Web
semántica.
La Web semántica está pensada para interconectar eficazmente la gestión de la
información personal, la integración de las aplicaciones empresariales y compartir
globalmente datos comerciales, científicos y culturales. Los servicios para poner datos
comprensibles por la maquina se están convirtiendo rápidamente en una prioridad para
muchas organizaciones, individuos y comunidades. Se considera que la Web sólo puede
alcanzar todo su potencial si llega a ser un sitio donde se puedan compartir datos y sean
procesados por herramientas automáticas, así como personas. Para adaptar la Web, los
programas de mañana deben ser capaces de compartir y procesar datos incluso cuando
estos programas se hayan diseñados de forma completamente independientes. [7].
En definitiva, se trata de transformar la red desde un espacio de información a un
espacio de conocimiento. En la siguiente Figura 4 podemos observar una comparación
entre una red de datos y una red semántica:
Figura 4: Comparación red de datos y red semántica [8].
La Web semántica proporciona un salto sobre el potencial de la Web, donde la
información se da mediante un lenguaje muy definido, facilitando que máquina y
persona trabajen en cooperación.
6
- Ontologías
Las ontologías se definen como conceptualizaciones que determinan el significado de
un grupo de conceptos para un determinado dominio. Esta conceptualización debe ser
representaba de manera formal, legible y utilizable por los ordenadores [9].
Por tanto, la Web semántica utiliza las ontologías como soporte, pues se necesita que el
conocimiento de la Web se presente de forma que sea entendida por la máquina.
Las ontologías de compondrán de los siguientes elementos para representar el
conocimiento de algún dominio [10]:
- Conceptos: ideas básicas a formalizar. Pueden ser clases de objetos, métodos,
estrategias, etc.
- Relaciones: interacción y enlace entre los conceptos del dominio. Por ejemplo:
subclase-de, parte-de, conectado-a, etc.
- Funciones: se trata de un tipo concreto de relación, donde se identifica un
elemento mediante el empleo de una función que engloba varios elementos de la
ontología. Por ejemplo: categorizar-clase, asignar-fecha, etc.
- Instancias: representan objetos determinados de un concepto.
- Axiomas: teoremas sobre relaciones que deben cumplir los elementos de la
ontología. Por ejemplo: “Si A y B son de la clase C, entonces A no es subclase
de B”.
En conclusión, una ontología se trataría de la obtención de una representación formal de
los conceptos, y relaciones entre los mismos, que contiene un dominio. Es decir,
codifica el conocimiento de un dominio y el conocimiento que extiende de un dominio.
Se dice entonces que las ontologías hacen el conocimiento reutilizable.
Un ejemplo de ontología puede ser el expuesto a continuación en la Figura 5:
Figura 5: Ejemplo de ontología.
1.2 Objetivos del proyecto
En este apartado se establecerán las metas de este proyecto. A continuación
expondremos los objetivos de forma textual, y seguidamente de forma esquemática.
7
El objetivo fundamental del proyecto es poner a la disposición de los usuarios,
docentes, de la plataforma LdShake un mecanismo que facilite la selección de un patrón
inicial mediante una query.
La visualización de los resultados ha de presentarse de forma clara teniendo en cuenta
las intenciones del usuario.
Un objetivo secundario será proponer el aprovechamiento de las tecnologías existentes,
de forma que el sistema se desarrolle dentro de la aplicación LdShake como un conjunto
de módulos.
Además, resulta necesaria la creación de un sencillo sistema de enriquecimiento de la
búsqueda, de forma que los usuarios puedan definir términos a los que se aplican las
relaciones presentes en la ontología.
En resumen, los objetivos del proyecto son:
- Encontrar una herramienta que mediante una query devuelva un patrón.
- Realizar una visualización de los resultados clara y concisa.
- Aprovechar tecnologías de reciente inserción con fines educativos.
- Adaptar el mecanismo al funcionamiento y necesidades de LdShake.
- Poner a disposición del usuario un sencillo sistema de búsqueda dirigida.
1.3 Metodología
Para la realización del proyecto emplearemos conceptos de ingeniería de software.
Estos se aplicarán en la planificación del trabajo, asi como en el diseño de la solución y
el ciclo de vida.
Lo primero que haremos, para ayudarnos con la planificación del trabajo, será exponer a
continuación las distintas fases en las que se compondrá el proyecto, con sus tareas a
realizar.
Fase 0: Conocimiento del dominio
- Consulta de trabajos previos sobre LdShake.
- Adquirir conocimientos sobre Web 2.0 y e-learning.
- Estudio de la Web Semántica y algunas herramientas.
- Análisis de las técnicas de visualización de la información.
- Toma de contacto con los patrones.
- Obtención de requisitos.
Fase 1:
- Planificación temporal.
- Familiarizarse con las tecnologías a utilizar: ELGG, PHP, AJAX, JavaScrip y
Netbeans.
Fase 2:
- Requerimientos del proyecto.
- Análisis de caso de uso.
- Estudio del problema.
8
- Propuesta de solución.
Fase 3:
- Implementación
- Testeo
Fase 4:
- Realizar diferentes pruebas sobre la aplicación.
- Recogida de resultados, análisis y conclusión.
Fase 5: Escritura de la memoria
- Elaboración de la memoria.
1.4 Planificación temporal
En este apartado expondremos las planificaciones temporales iniciales y finales de
nuestro proyecto. Para ello se asigna a cada fase del proyecto un tiempo. En la
planificación inicial la asignación es aproximada, pues esta se realiza en la fase inicial
del proyecto. En cambio en la planificación final exponemos el tiempo real empleado en
cada fase, pues en este punto tenemos en cuenta fallos o problemas que han podido
surgir en el desarrollo del proyecto. En ambos casos, y para su comparación,
utilizaremos diagramas de Gantt.
a) Planificación temporal inicial
Al principio del proyecto, y siguiendo la metodología comentada anteriormente, se
realizó la planificación temporal expuesta en la Figura 6. La fecha a entregar estimada
estará dentro de la convocatoria de Junio.
9
Figura 6: Planificación temporal inicial del proyecto.
10
b) Planificación temporal
En la Figura 7 podemos observar como la planificación temporal ha cambiado, ya que a
medida que se fue realizando el proyecto se pudieron encontrar algunos contratiempos
que nos llevaron a tomar más tiempo del previsto en algunas actividades.
Figura 7: Planificación temporal final del proyecto.
11
1.5 Estructura de la memoria
Este documento se divide en seis grandes bloques. El primero de ellos será este
capítulo, la introducción, donde hemos realizado un estudio previo del contexto en el
que nos movemos, exponiendo los objetivos a alcanzar y la metodología a seguir. En
segundo lugar tenemos el capítulo del estado del arte, donde se describen las diferentes
tecnologías y herramientas implicadas en el desarrollo del proyecto. A continuación en
el tercer capítulo, análisis de los requisitos, expondremos los requisitos a conseguir así
como el análisis del caso de uso, estudiando ELGG. El cuarto capítulo, diseño e
implementación, es donde explicamos el diseño para la implementación de la aplicación
en LdShake. En quinto lugar tenemos el capítulo de pruebas, donde tendremos la
realización las pruebas oportunas para la validación de nuestros requisitos, explicando
los resultados obtenidos. Y por último, en el capítulo conclusión, se exponen los puntos
más fuertes, a modo de conclusión, del proyecto.
12
13
2. ESTADO DEL ARTE
Una vez explicados los dominios donde se centran las soluciones existentes a día de
hoy, E-learning, Web semántica y Web 2.0, se analiza el estado de la búsqueda por
palabra clave y semántica, el procesamiento del lenguaje natural, así como de algunas
de las diferentes técnicas de visualización de la información.
2.1 Query
Como hemos mencionado anteriormente, existen varias formas de realizar una
búsqueda. A continuación vamos a centrarnos en la explicación y comparación entre
búsqueda por palabra clave y búsqueda semántica.
a) Búsqueda por palabra clave
Los buscadores por palabra clave, como son los buscadores tradicionales Gloogle,
Yahoo!, ect; no analizan el significado de la expresión de búsqueda del usuario, sino
que, se limitan a comprobar si las palabras introducidas, descartando las palabras
vacías, aparecen o no en los contenidos, en código HTML. La aplicación devolverá por
tanto, todos los documentos que contienen esas palabras.
La búsqueda por palabra clave no considera entonces el sentido de las cosas, pues
realiza la búsqueda estrictamente conforme a la expresión introducida por el usuario.
Veamos un ejemplo para aclarar esa ineficacia. Por ejemplo, si queremos buscar
información sobre gatos hidráulicos e introducimos la palabra “gato” en el buscador,
encontraremos un gran número de páginas apuntándonos sobre documentos e
información sobre el gato animal. E incluso si buscamos “arreglar gato”, la mayoría de
los resultados planteados, como podemos ver en la Figura 8, siguen siendo sobre el
animal, mientras que obviamente la palabra arreglar está más ligada al gato hidráulico.
Se dice entonces que el buscador carece de “inteligencia”.
Figura 8. Resultado de la búsqueda en Google “arreglar gato”.
La única diferencia entre los diferentes buscadores tradicionales por palabra clave, se
encuentra en los rangos estadísticos que utilizan para posicionar mejor o peor un
resultado obtenido [12].
14
Google en concreto, utiliza que cuanto más hipervínculos apuntan a un documento, más
relevancia se le concede.
Este procedimiento de búsqueda presenta pequeños índices de eficacia, ya que el
usuario al realizar una consulta, o que realiza una pregunta, quiere una respuesta, no un
sin fin de documentos, algunos de los cuales no le interesa en absoluto. En el caso
anterior, por ejemplo, para poder encontrar como arreglar nuestro gato hidráulico,
debemos consultar al menos 4 o 5 enlaces hasta dar con lo que buscamos. Incluso a
veces, como sabemos, las consultas previas a encontrar nuestro resultado son de
decenas.
Podemos entonces resumir los inconvenientes de esta búsqueda, en los siguientes
puntos (8, 13):
- Dificultad del usuario para expresar la consulta que desea realizar.
- Poca precisión de los resultados.
- Sensibilidad de los resultados frente a los términos exactos introducidos; pues
muchos documentos de interés pueden no incluir las palabras claves, pero si
sinónimos, hipónimos o hiperónimos de ellas.
- Aparición de resultados ruidosos, es decir, se pueden dar por relevantes,
mediante algunas técnicas de optimización, algunos documentos que en realidad
no tienen relevancia para la búsqueda realizada.
- Uso de procedimientos estadísticos, dando como importantes los documentos
más visitados, perdiendo eficacia los minoritarios o específicos.
b) Búsqueda semántica
La búsqueda semántica pretende comprender las expresiones proporcionadas por el
usuario en su consulta. Ahora se trata de devolverle al usuario unos resultados
orientados a su búsqueda, más específicos, sin necesidad de una gran intervención por
parte del usuario haciendo uso del contexto y por ello, del significado.
Se trata de una búsqueda más expresiva, que comprende la consulta del usuario,
ofreciendo la posibilidad de emplear leguaje natural para expresar consultas e incluso
preguntas. Por ejemplo, respondiendo a preguntas como: “¿Quién es Urano?”; en un
buscado por palabra clave lo más seguro es que la mayoría de los resultados obtenidos
estarían relacionados con el séptimo planeta del Sistema Solar, Urano, mientras que
empleando una búsqueda semántica, el pronombre “Quién” denotaría que nos tratamos
de una persona, y nos daría resultados en relación al dios griego Urano, que es a lo que
nos referimos.
Se dice por tanto, que las búsquedas semánticas serían una vacuna para el contagioso
virus de relevancia en los resultados [13]. Así, estos buscadores pueden realizar
búsquedas de interés para el usuario aunque en los documentos pertinentes no se
encuentren las palabras o expresiones de búsqueda. De hecho, se pueden encontrar
documentos de utilidad que jamás se facilitarían usando búsqueda de palabra clave.
Para el ser humano comprender una palabra dentro de un contexto no es nada difícil, ya
que nuestro celebro al ver la palabra la asocia a alguna definición. Pero esto es distinto
para las máquinas. Pues para estas, las palabras no son más que manchas negras. Por
tanto, para las máquinas actuales “comprender” no debe de confundirse con la
compresión humana, sino con la “deducción” [8]. Así si programamos la máquina con
15
la siguiente frase “Los gatos respiran”, por un proceso lógico, si introducimos “Mi gato
se llama Sam”, deducirá que Sam respira.
Las búsquedas semánticas, comúnmente, utilizan la extracción de información mediante
la utilización de ontologías o metadatos. El uso de ontologías, permitiendo definir los
dominios de interés, hace que el motor de búsqueda entienda nuestras necesidades de
información, permitiendo una mayor expresividad en las consultas.
Utilicemos el mismo ejemplo aclaratorio anterior. Ahora haremos uso de un buscador
semántico, Hakia, y realizaremos la consulta “arreglar gato”. Los resultados obtenidos
son los expuestos en la Figura 9. Como podemos observar los resultados son más
acordes con nuestro propósito, siendo ya el primer resultado, adecuado al gato
hidráulico. Además podemos ver como el buscador, en la parte izquierda, emplea
técnicas de agrupamiento para construir categorizaciones de contenidos sobre los que
buscar. Existen también otros buscadores semánticos los cuales realizan agrupaciones
de términos claves para su visualización.
Figura 9. Resultado de la búsqueda en Hakia “arreglar gato”.
Ahora bien, no siempre los buscadores semánticos pueden acertar a la primera el
significado de una palabra polisémica. Por ello, se necesitan de un mecanismo de
desambiguación para conocer el significado de una palabra. Ahí es donde entra una de
las ramas de la Inteligencia Artificial: el Procesamiento del Lenguaje Natural (PLN) y
una de las tareas más difíciles dentro del área del PLN, la elección del sentido más
apropiado, Desambiguación del Sentido de la Palabra (Word Sense Disambiguation;
WSD). Estos puntos los trataremos de forma más extensa en apartados posteriores.
La falta de estructura y de anotaciones semánticas en los recursos de la web
(documentos Word, PDF, páginas HTML, etc) fuerza a que los buscadores semánticos
analicen mediante algoritmos cognitivos los recursos, palabra por palabra y oración por
oración, para asignar las palabras y oraciones a conceptos ontológicos. Estos algoritmos
son lentos y requieren supervisión humana. De ahí que los buscadores semánticos no
cubran por ahora tantos recursos como los convencionales [13].
2.2 Procesamiento del Lenguaje Natural
Para el ser humano el tesoro más valioso que posee es el conocimiento, por otro lado,
para las maquinas, aunque estas estén preparadas para procesar muchísima información,
16
un texto es sólo una cadena de letras sin ningún sentido, es decir, no lo entiende.
Actualmente la gran mayoría de los contenidos web se presenta como información en
forma de texto, naciendo así la necesidad de procesarla automáticamente para
simplificar muchas tareas. Algunas de las tareas que se podrían facilitar serían por
ejemplo la traducción de textos, la comparación entre distintas fuentes para obtener
conclusiones o resúmenes, o la búsqueda de información necesaria, punto en el cual nos
centraremos.
Se recurre entonces a una de las ramas de la Inteligencia Artificial: el Procesamiento del
Lenguaje Natural (PLN). El PLN es, de manera general, el conjunto de instrucciones
que una computadora recibe en un lenguaje de programación dado (formal), que le
permitirá comunicarse con el ser humano en su propio lenguaje [14]. Por tanto, las
actividades principales de este campo será la creación de métodos, técnicas y
herramientas computacionales para permitir un análisis de la información, escrita u oral,
que faciliten la organización y búsqueda de tal información.
La arquitectura de un sistema d PLN consistirá en un análisis léxico/sintáctico,
siguiendo cuatro pasos claves [14]:
- El usuario le expresa, de alguna manera, a la computadora que tipo de
procesamiento desea hacer;
- La computadora analiza las oraciones proporcionadas, en el sentido morfológico
y sintáctico;
- Se analizan las oraciones semánticamente, determinándose el significado de
cada oración;
- Se realiza un análisis pragmático del texto, obteniéndose una expresión final.
A continuación se ejecuta la expresión final y se entrega al usuario para su
consideración. En definitiva, lo que pretende hacer el PLN es lograr una comunicación
máquina-humano similar a la comunicación humano-humano.
Ahora bien, dado que el PLN trata de comprender el lenguaje natural, una de las tareas
más difíciles en el procesamiento automático de lenguaje humano es la resolución de la
ambigüedad de una palabra o expresión. Este problema surge cuando una expresión
hablada o escrita puede tener más de un significado. Por ejemplo, la palabra, utilizada
en ejemplos anteriores, “gato” es ambigua, pues puede significar el gato animal o el
gato como herramienta. Este fenómeno lingüístico se le conoce como polisemia. Para el
ser humano determinar el sentido correcto de una expresión o de una palabra polisémica
no suele presentarse como un problema, en cambio para una computadora se presenta
como una enorme dificultad. Por esta razón es necesario analizar a fondo cada una de
las palabras y obtener así la interpretación o sentido más apropiado. Se da por tanto la
necesidad de obtener métodos que determinen el sentido adecuado, con la ayuda del
conocimiento más allá del texto mismo.
El problema de la ambigüedad puede afectar a actividades como la recuperación de
información necesaria y de interés, o en la traducción automática. Centrándonos en la
recuperación de la información, uno de los problemas que se presenta en esta área es la
precisión de la búsqueda. Realizando una búsqueda por palabra clave, método que
hemos comentado anteriormente, si nuestra búsqueda contiene palabras polisémicas
podemos obtener documentos no deseados. Por esta razón la obtención del sentido de
una palabra mejorará los resultados en la búsqueda de documentos, al analizar y
verificar el sentido correcto de las palabras utilizadas en la consulta.
Se convierte por tanto, la obtención del sentido más apropiado para una palabra en una
de las tareas más importantes y difíciles dentro del área de PLN llamada
17
Desambiguación del Sentido de las Palabras, o Word Sense Disambiguation (en el
presente documento utilizaremos WDS). La tarea de desambiguación será una tarea
previa a la interpretación. En la actualidad la Web resulta ser un recurso muy atractivo
para la creación de métodos WDS, utilizando la información contenida en esta para
facilitar el proceso de elección del sentido más adecuado.
Dejando un lado la comprensión de texto, otra de las tareas para el PLN es la generación
de texto. Aunque podemos pensar que esta actividad es bastante sencilla sabiendo las
reglas gramaticales, no estamos para nada en lo cierto. Existe varios problemas como la
elección de las expresiones a usar en cada momento, para que el texto sea lo más
coherente posible. Existen varias técnicas para la creación correcta de textos, pero no
vamos a entrar en ellas ya que no son significativas para nuestro proyecto.
Volviendo al WDS, los recursos lingüísticos más utilizados en esta tarea serán: WordNet y
Senseval-3 ELS. En el presente trabajo utilizaremos el primero de ellos, WordNet, del cual
presentamos a continuación una breve descripción.
a) Herramienta adicional: WordNet
WordNet es un diccionario MRD (Machine Readable Dictionaries), una base de datos
léxica del idioma inglés, con extensión para el español. Creado en 1985 por George
Milles y el Laboratorio de Ciencias Cognitivas de la Universidad de Princeton, se trata
de uno de los recursos más valiosos para el PLN. Este recurso trata de agrupar las
palabras en conjuntos de sinónimos denominados synsets y facilita definiciones,
comentarios y ejemplos de usos de las palabras y sentidos de estas, combinando
elementos de diccionario (definiciones y ejemplos) y de tesauro (sinónimos). A través
de Wornet se recuperarán los sinónimos e hiperónimos de la palabra objetivo, utilizando
estas como fuente de información.
Desde Noviembre de 2012 la última versión de WordNet es WordNet 3.1 (de junio de
2011), pero la última versión liberada fue la 3.0 (diciembre 2006), cuya base de datos
contiene 155,287 palabras organizadas en 117,659 synsets formando un total de
206’941 pares de palabras [15]. WordNet opera con 5 categorías léxicas en sus synsets:
sustantivos, verbos, adjetivos, adverbios y elementos funcionales. En la siguiente tabla
1, mostramos un ejemplo donde se muestran los synsets de la palabra “cat”, sustantivos
y verbos:
Noun
S: (n) cat, true cat (feline mammal usually having thick soft fur and no
ability to roar: domestic cats; wildcats)
S: (n) guy, cat, hombre, bozo, sod (an informal term for a youth or man) "a
nice guy"; "the guy's only doing it for some doll"; "the poor sod couldn't
even buy a drink"
S: (n) cat (a spiteful woman gossip) "what a cat she is!"
S: (n) kat, khat, qat, quat, cat, Arabian tea, African tea (the leaves of the
shrub Catha edulis which are chewed like tobacco or used to make tea; has
the effect of a euphoric stimulant) "in Yemen kat is used daily by 85% of
adults"
S: (n) cat-o'-nine-tails, cat (a whip with nine knotted cords) "British sailors
feared the cat"
S: (n) Caterpillar, cat (a large tracked vehicle that is propelled by two
endless metal belts; frequently used for moving earth in construction and
farm work)
18
S: (n) big cat, cat (any of several large cats typically able to roar and living
in the wild)
S: (n) computerized tomography, computed tomography, CT, computerized
axial tomography, computed axial tomography, CAT (a method of
examining body organs by scanning them with X rays and using a computer
to construct a series of cross-sectional scans along a single axis)
Verb
S: (v) cat (beat with a cat-o'-nine-tails)
S: (v) vomit, vomit up, purge, cast, sick, cat, be
sick, disgorge, regorge, retch, puke,barf, spew, spue, chuck, upchuck, honk,
regurgitate, throw up (eject the contents of the stomach through the
mouth) "After drinking too much, the students vomited"; "He purged
continuously"; "The patient regurgitated the food we gave him last night"
Tabla 1: Ejemplos de synsets y definiciones de la palabra “cat”.
La mayor parte de los synsets están conectados a otros synsets bajo una red de
relaciones semánticas, entre las cuales se tienen [16]:
- Sinónimos. Palabras con significados idénticos o similares.
- Antónimos. Palabras con significados opuestos.
- Hiperónimos. Palabras que son más generales que otras en su significado. Por
ejemplo, “vehículo” es hiperónimo de “tren” y de “coche”.
- Hipónimos. Palabras que son más específicas que otras en su significado. Por
ejemplos “tulipán” y “margarita” son hipónimos de “flor”.
- Holónimos. Palabras que denotan ser una parte o miembro de un todo. Por
ejemplo “auto” es holónimo de “llantas” y “volante”.
- Merónimos. Palabras que denotan ser un todo de las palabras que denotan ser
una parte o miembro de ese todo. Por ejemplo “llantas” y “volante” son
merónimos de “auto”.
A continuación, en la tabla 2, visualizamos los hipónimos de la palabra “cat”,
correspondiente a la primera definición dada:
Noun
<noun.animal>S: (n) cat, true cat (feline mammal usually
having thick soft fur and no ability to roar: domestic cats;
wildcats)
o direct hyponym / full hyponym
<noun.animal>S: (n) domestic cat, house
cat, Felis domesticus, Felis catus(any
domesticated member of the genus Felis)
<noun.animal>S: (n) wildcat (any small or
medium-sized cat resembling the domestic cat and living in the
wild)
19
Tabla 2: Ejemplos de synsets hipónimos y sus definiciones sobre el primer sentido de la
palabra “cat”.
WordNet, pese a algunas limitaciones, se ha convertido en un recurso indispensable
para WSD, ya que cuenta con información sobre los sentidos de las palabras, aportando
precisión. La base de datos y las herramientas de WorNet se han liberado bajo
una licencia BSD y pueden ser descargadas y usadas libremente. Además la base de
datos puede consultarse online en http://wordnetweb.princeton.edu/perl/webwn.
2.3 Visualización de la Información
La Visualización de la Información es el método que se ocupa de la representación
visual de contenido. Este método pretende facilitar la comunicación, transformación e
interpretación de los contenidos a través del uso de diagramas, gráficas y esquemas
[17].
El proceso de desarrollo de una interfaz de visualización se ha de articular en 4 etapas:
adquirir, transformar, representar y añadir interactividad. Las dos primeras se etapas se
refieren a acciones sobre datos en soporte electrónico, la etapa de representar por su
parte alude a la materialización gráfica de la información anteriormente extraída
(traducción a gráficos), y por último la etapa de interactividad consiste en posibilitar al
usuario de manipular o explorar con el fin de modelar la interfaz para sus propios
intereses y necesidades. A continuación realizaremos una breve introducción a las tres
primeras etapas.
En primer lugar tenemos, como hemos mencionado, la etapa de adquisición de datos.
En esta, teniendo en cuenta que la visualización de la información toma como objetivo
reducir el volumen de datos con el fin de facilitar su acceso y transformación de
contenidos sobre un dominio concreto, se ha de tener mucho cuidado en el análisis y
selección de datos, con tal de no representar excesiva información o de poco interés.
La siguiente etapa con la que nos encontramos será la transformación de los datos.
Mediante esta etapa los datos fuente a visualizar, normalmente representados como
registros y campos, o en diversas formas, son transformados en datos computables para
que esta información sea visualizable.
En la etapa de representación grafica de la información lo que se hará será, a partir de
los datos de naturaleza numérica transformados en la etapa anterior, producir una
imagen de equivalente significado mediante lenguaje visual. Esta etapa se entiende
como un proceso de traducción o codificación, y se realiza con el fin de que el usuario
pueda percibir la mayor cantidad de información posible con el menor esfuerzo.
Una vez expuestas las diferentes etapas en las que se divide un proceso de visualización,
vamos a estudiar las Interfaces Visuales de Recuperación de la Información o VIRIs
(Visual Information Retrieval Interface). Los VIRIs tienen dos objetivos principales:
ayudar al usuario a navegar y obtener información y ofrecer una visión global de un
conjunto documental. A través de esto el usuario puede percibir que puede encontrar, e
incluso adquirir nuevos conocimientos mediante la interiorización de la visualización.
Un esquema de análisis y evaluación de las VIRIs muy utilizado es el RRRR, cuyas funciones
básicas esperadas de un VIRI son [18]: (i) Resumir la información, (ii) Resaltar la información
mñas relevante, (iii) Relacionar la información semejante o similar y (iv) Recuperar la
información. A continuación hablaremos sobre algunos de los VIRIs más populares, que siguen
el esquema RRRR, con numerosas implementaciones en la web.
20
a) Grafos
La representación mediante grafos es una forma sencilla de exponer las relaciones que
mantienen entre sí elementos de distinta índole. Además resulta muy eficaz para
representaciones de estructuras de datos en red y de forma jerárquica. Muchas veces la
reducción de la información se realiza mediante técnicas de poda. El objetivo de trabajo
consiste en encontrar algoritmos eficientes para lograr grafos que transmitan su
significado en forma clara y rápida. Un ejemplo de visualización en grafo es el expuesto
a continuación en la figura 10:
Figura 10: Ejemplo de Grafo, co-ocurrencias entre SO.
b) Tree-map
Los diagramas de árbol, o Tree-map, permiten mostrar información jerárquica en una
serie de rectángulos agrupados, que en conjunto representan un concepto amplio. El
tamaño de cada cuadro representa un número y casi siempre se suele utilizar colores
para añadir otra dimensión, es decir, jugamos con un espacio bi-dimensional, el tamaño
y el color.
Como ejemplo exponemos en la Figura 11 un NewsMap, un tree-map que trata las
noticias y prensa de cobertura. NewsMap permite visualizar las últimas noticias por
dominio geográfico, mostrando las noticias más populares.
Figura 11: NewsMap (http://newsmap.jp/)
21
c) Tag Cloud
Los Tag Cloud, o nubes de etiquetas, son un sencillo modelo de VIRI con forma de lista
ponderada de palabras claves, que se ha popularizado bastante últimamente. Se tratan de
unos VIRIs que muestran las palabras claves o tag más populares, según la frecuencia
con la que se hayan utilizado para describir los recursos a recuperar. Una vez el usuario
selecciona un tag, se muestra una lista de recursos descritos por ese tag, para así poder
continuar su búsqueda.
A continuación mostraremos un ejemplo de búsqueda de la palabra “arreglar gato”,
búsqueda utilizada anteriormente, en Google, haciendo uso de la aplicación “Tag Cloud
Search + Translate”. Esto lo mostraremos en la Figura 12:
Figura 12: Tag Cloud de la búsqueda “arreglar gato”.
Ya que este será el VIRI utilizado para nuestro trabajo profundicemos un poco más en
el. Si realizamos un análisis RRRR, podemos determinar los siguientes puntos:
- Resumir: Se pretende hacer un resumen global sobre los temas más populares,
basados en la frecuencia de uso. Una mejora se podría realizar teniendo en
cuenta no solo la popularidad del tag, sino también su valor de discriminación,
es decir, la capacidad del tag para describir aquellos recursos no descritos por
otros tags.
- Resaltar: el tamaño de cada fuente indica su relevancia, determinada por su
popularidad o capacidad representativa. Si, como hemos comentado, en tal
cálculo se tuviese en cuenta el valor de discriminación, el tamaño del tag
indicaría con más fiabilidad la relevancia de este.
- Relacionar: La mayoría de las veces los tags se distribuyen visualmente de
forma lineal, ordenado alfabéticamente o por ordene popularidad. Esto no
posibilita la percepción de relaciones entre tags, pues la vecindad visual no
proporciona información alguna al usuario. Para mejorar en este sentido las Tags
Clouds existen varias propuestas.
- Recuperar: Una vez el usuario selecciona un tag, se muestra una lista de recursos
descritos por ese tag.
Una vez expuestos estos puntos podemos hacer un estudio de por qué la popularidad de
este VIRI frente a Tree-Map o Grafos. Su éxito reside en que posee cierta ventaja frente
a estos dos, como por ejemplo, su facilidad de implementación: la selección de tags se
puede obtener simplemente consultando una base de datos, y su implementación gráfica
puede obtenerse mediante HTML. Además de que existen varias formas de optimizar
22
las Tags Cloud como interfaces visuales, sin necesidad de aumentar el procesamiento de
datos o utilizar otras tecnologías de implementación, como en el caso de los grafos.
Una de las medidas importantes para la evaluación de un VIRI es el compromiso
sencillez-flexibilidad. Se da que cuanto más sencilla la interfaz más fácil de utilizar. Por
otro lado, cuanto más flexible sea, más información aportará. Para nuestro trabajo, al
destinarse a un público general, debe primar la sencillez, justificando una vez más el
uso de Tags Cloud.
23
3. ANÁLISIS DEL SISTEMA
En este capítulo realizaremos un estudio y análisis sobre los requisitos del sistema,
definiendo así los datos de entrada para establecer que debe hacer el sistema. A
continuación se expondrán, mediante los casos de usos, los pasos o actividades a
realizar para llevar a cabo el sistema, así como los actores involucrados en estas. Estos
dos elementos, caso de usos y requisitos, se complementan en un proceso bidireccional,
como veremos a continuación.
3.1 Requisitos
Los requisitos son una parte importante a tener en cuenta para alcanzar un objetivo, ya
que cada uno de estos presentan una condición o capacidad que debe exhibir o poseer
un sistema para satisfacer un contrato, estándar, especificación, u otra documentación
formalmente impuesta [19].
Para la obtención de los requisitos se pueden emplear varias técnicas, como entrevistas
o mediante la comunicación con clientes o usuarios, a fin de conocer cuáles son sus
expectativas. En el caso de este proyecto, los requisitos han sido obtenidos a partir de
entrevistas con los tutores del proyecto, quienes notificaron las necesidades de los
usuarios de la plataforma LdShake.
Los requisitos pueden dividirse en funcionales o no funcionales:
- Los requisitos funcionales describen lo que un sistema debe hacer, algo que el
sistema entregado debe ser capaz de realizar. Además especifican todas las
entradas y salidas y la relación entre ambas.
- Los requisitos no funcionales especifican criterios que pueden usarse para
juzgar la operación de un sistema en lugar de su comportamiento específico. Se
refieren a todos los requisitos que ni describen información a guardar ni
funciones a realizar; sino que tienen que ver con la tecnología de rendimiento,
fiabilidad, seguridad, portabilidad, estándares, interfaces de usuario, etc [20].
A continuación detallamos los requisitos funcionales y no funcionales obtenidos
mediante el análisis de nuestro sistema. Estos se resumirán en tablas, y cada requisito
contará con un identificador, un nombre y una descripción del mismo.
a) Requisitos funcionales
En la siguiente tabla se exponen los requisitos funcionales para nuestro sistema.
ID Nombre Descripción
RF001 Registrarse El Usuario debe estar previamente registrado en el
sistema. La autenticación se hará mediante la
introducción de un Username y un Password.
RF002 Salir Se deberá poder salir de la sesión del Usuario.
RF003 Consulta El usuario podrá efectuar una búsqueda sobre un
lenguaje de patrones.
RF004 Búsqueda El usuario podrá realizar una query utilizando lenguaje
natural. El buscador deberá usar técnicas de web
semántica, una búsqueda más precisa y expresiva.
RF005 Recuperación Se deberá de recuperar y visualizar aquellos documentos
24
donde se encuentren las palabras claves y/o sus
sinónimos.
Tabla 3: Requisitos funcionales del sistema.
b) Requisitos no funcionales
A continuación se exponen, en forma de tabla, los requisitos no funcionales para
nuestro sistema.
ID Nombre Descripción
RNF001 Framework El sistema se desarrollará bajo el Framework de
redes sociales ELGG.
RNF002 Plataforma El sistema ha de ser compatible con la
plataforma LdShake. Presentándose como un
módulo dentro de esta.
RNF003 Idiomas El idioma que se podrá utilizar para realizar las
consultas será el inglés.
RNF004 Lenguaje de
programación
El sistema se desarrollará bajo PHP, Java,
JavaScript y AJAX.
RNF005 Servidor Web El sistema correrá bajo el servidor web Apache.
RNF006 Intuitivo El sistema debe ser intuitivo para el usuario, sin
presentar complicaciones para este.
RNF007 Modularidad El sistema desarrollado ha de ser fácilmente
modificable y ampliado, permitiendo así
mejoras.
RNF008 Tratamiento de errores El sistema ha de ser capaz de recuperarse de
fallos por sí mismo.
RNF009 Motor Se deberá apoyar en un motor semántico,
sosteniéndose sobre la ontología para dar
significado a las búsquedas.
RNF010 Algoritmo El algoritmo utilizado se deberá basar en PLN.
RNF011 Filtrado Se deberán filtrar las palabras vacías para una
búsqueda más eficiente.
RNF012 Recurso Se deberá utilizar un recurso lingüístico que nos
facilite los sinónimos de las palabras claves.
Tabla 4: Requisitos no funcionales del sistema.
3.2 Caso de uso
En este apartado se describen los distintos casos de uso del sistema. Cada caso de uso se
centra en describir cómo alcanzar una única meta o tarea. Los casos de uso no describen
ninguna funcionalidad interna (oculta al exterior) del sistema, ni explican cómo se
implementará. Simplemente especifican un uso del sistema y cómo este interactúa con
el usuario. Además, al ser parte del análisis del sistema, los casos de uso nos ayudan a
describir qué es lo que el sistema debe hacer.
25
Lo primero que haremos será definir a los actores que interactuarán con el sistema
dentro de los diferentes casos de uso. En nuestro caso tendremos un actor , el usuario
registrado, usuario con cuenta en LdShake el cual, tras una sesión de usuario iniciada,
podrá realizar búsquedas sobre lenguaje de patrones y consultar los documentos
resultados.
Una vez expuestos el actor principal de nuestro sistema expondremos el diagrama de
caso de uso, Figura 13, en el cual se muestra la relación entre el actor, usuario registrado
y los casos de uso del sistema.
Figura 13: Casos de uso.
A continuación estudiaremos los distintos casos de uso por separado. Para cada caso de
uso construiremos una tabla en la cual se especificarán sus precondiciones, flujo de
eventos y postcondiciones, en el formato que indica la Tabla 5.
Caso de Uso: Nombre del caso de uso
Descripción
Descripción del caso de uso.
Precondiciones
Lista de condiciones previas para poder realizar el caso de uso
Postcondiciones
Condiciones necesarias para considerar que el caso de uso se ha completado
exitosamente.
Flujo de Eventos
Flujos básicos
Actor(es)
Acciones del caso de uso
Flujos alternativo
Actor(es)
Acciones alternativas
Tabla 5: Formato caso de uso.
Con esto pasamos a describir nuestros tres diferentes casos de uso.
26
Caso de Uso: Realizar query
Descripción
Este caso de uso define como se realizará la acción por parte de un usuario de realizar
una consulta sobre lenguaje de patrones.
Precondiciones
Log In
Para poder realizar una consulta sobre lenguaje de patrones, el usuario debe haber
iniciado sesión con una cuenta de usuario.
Postcondiciones
Ninguna
Flujo de Eventos
Flujos básicos
(Actor: Usuario Registrado)
1. Actor: Selecciona en la barra de menú la opción Patterns.
2. Sistema: Muestra la página Web con la información para trabajar con la
consulta sobre lenguaje de patrones.
3. Actor: Se sitúa en la barra de búsqueda y escribe su consulta.
4. Actor: Pulsa intro o la imagen de la lupa.
5. Sistema: Desglosa la búsqueda y consulta en Wordnet sus sinónimos.
6. Sistema: Realiza un filtrado de la búsqueda y del resultado ofrecido por
Wordnet.
7. Sistema: Realiza una llamada a la ontología y obtener los campos requeridos de
cada patrón.
8. Sistema: Buscar en los textos resultados del punto 7, las palabras derivadas del
punto 6.
9. Sistema: Visualiza un listado con los documentos relacionados con los patrones
que obtengan mejores resultados en el punto 8, y un link para consultarlos.
Tabla 6: Caso de uso: realizar query.
Caso de Uso: Leer documento resultado
Descripción
Este caso de uso define como se consultarán los documentos relacionados con los
patrones de aprendizaje.
27
Precondiciones
Log In
Para poder realizar una consulta sobre lenguaje de patrones, el usuario debe haber
iniciado sesión con una cuenta de usuario.
Consulta
Para visualizar un documento relacionado con un patrón debe haberse realizado una
consulta, de la cual este documento sea resultado de ella.
Postcondiciones
Ninguna
Flujo de Eventos
Flujos básicos
(Actor: Usuario Registrado, Usuario Externo)
1. Actor: Introduce la URL pública en el navegador.
2. Sistema: Comprueba que el documento existe.
3. Sistema: Muestra la vista externa del documento.
4. Actor: Visualiza el documento.
Tabla 7: Caso de uso: leer documento resultado
Como podemos comprobar, y vimos en el diagrama de casos de uso, el caso de uso Leer
documento resultado incluye haber realizado el caso de uso Realizar query, ya que los
documentos a leer son las salidas del caso de uso Realizar query.
28
29
4. DISEÑO
Una vez realizado un análisis de los distintos requisitos del software y los casos de uso
relacionados, pasamos a la etapa de diseño de software. El diseño de software es el
primer paso de la fase de desarrollo de cualquier producto. En este apartado
estudiaremos la estructura de los procedimientos.
Nuestra aplicación podemos dividirla en dos partes: a) el procesamiento de la query en
sí y la búsqueda a partir de esta, y b) la visualización de los documentos resultados.
Comenzaremos por analizar primero el diseño de la API de control que recogerá la
query envida por el usuario y realizará la búsqueda oportuna, y a continuación
estudiaremos el diseño de visualización propuesto.
4.1 Diseño de la API
Recordando, nuestra aplicación consistirá en un buscador mediante el cual, utilizando
técnicas de web semántica y PLN, los usuarios de LdShake puedan realizar consultas
sobre los distintos patrones de aprendizaje. A continuación se estudiarán los diferentes
pasos a seguir en el diseño de nuestra aplicación.
Al estar ligados al concepto de búsqueda o web semántica, se perseguirá proporcionar
una compresión completa de las consultas del usuario y así unos resultados mucho más
adaptados a sus necesidades. En web semántica, como ya hemos visto, se utilizan
algoritmos los cuales simulen la comprensión o entendimiento de la búsqueda del
usuario, es decir, algoritmos que traten el PLN. Una de las tareas fundamentales en el
ámbito del PLN es la desambiguación semántica. El objetivo de este proceso es
identificar cual de los posibles sentidos o significados de una palabra ambigua es el
correcto en una determinada oración o fragmento de texto. Nos encontramos, por lo
tanto, ante la necesidad de disponer de criterios para identificar y representar sentidos
de palabras.
Uno de los algoritmos para la desambiguación de palabras que se pensó utilizar en
primer lugar fue el de la Distancia Normalizada de Google (NGD). Este algoritmo,
propuesto por Cilibrasi y Vitany en el artículo de investigación “Automatic Meaning
Discovery Using Google”, plantea una medida semántica calculada a partir de los
resultados del motor de búsqueda Google. El algoritmo de cálculo indica que si se desea
medir el NGD de dos términos, ejemplo gato y perro, se deberá consultar a Google
sobre la cantidad de documentos que contienen el primer término, el segundo y ambos.
Luego, utilizando una fórmula, Fórmula 1, se computa la distancia entre los términos a
evaluar.
Fórmula 1: Cálculo de NGD [21].
En nuestro caso el algoritmo realizado hubiera sido el siguiente. El usuario introduce la
consulta en el cuadro de búsqueda, el texto introducido se procesa y se obtienen los
sinónimos de cada palabra no vacía mediante una herramienta que más tarde
comentaremos. A continuación comprobaremos cada sinónimo de cada palabra con la
siguiente palabra en el texto de la consulta. El sinónimo que obtenga menos NGD con la
siguiente palabra de consulta, será el que rija el sentido de la palabra a la que pertenece.
30
Y así con todas las palabras introducidas por el usuario. Por tanto se necesita acceder a
Google numerosas veces para desambiguar toda una frase.
Aunque en un principio se pensó considerar únicamente los tres primeros significados,
más utilizados, de cada palabra, escogiendo solo los sinónimos correspondientes, el
retardo por los accesos a Google es significativo. Además, existe otro inconveniente,
pues el equipo Google al detectar un tráfico inusual desde un equipo, como vemos en la
Figura 14, realizará comprobaciones captcha, las cuales desde nuestro código no
podemos saltar.
Figura 14: Pruebas captcha por tráfico inusual de Google
Por otra parte otros algoritmos, como la asignación de palabras a conceptos ontológicos
o la catalogación, necesitan la interacción con una base de datos vinculada. En nuestro
caso la base de datos de la plataforma LdShake está descrita en metadatos, lo cual
supone una dificultad que no corresponde a nuestro proyecto.
Nos encontramos por tanto ante el problema de no poder desambiguar las palabras. El
objetivo será entonces hallar un algoritmo el cual incorpore soluciones de la web
semántica, sin desambiguar las palabras. La forma más sencilla y eficaz, a partir de
nuestras herramientas, será emplear la utilización de los sinónimos e hiperónimos de las
palabras introducidas, para que formen parte también de la lista de palabras claves
correspondientes a la consulta. Así con tal algoritmo obtenemos una cobertura máxima.
Ahora bien, como sabemos, una palabra puede tener varios significados, y para cada
uno de los significados significado se tendrán unos sinónimos e hiperónimos diferentes.
Por ejemplo la palabra “cat”cuenta con ocho significados distintos para el empleo de
“cat” como sustantivo, y dos para el verbo “cat”. Entonces ¿utilizamos todos los
significados correspondientes a cada palabra? ¿Cómo afecta esto al tiempo de la
búsqueda? Debemos por tanto encontrar una forma en la que únicamente se empleen los
significados más utilizados de cada palabra.
La herramienta se utilizará para la obtención de sinónimos e hiperónimos de las
palabras objetos será WordNet 3.1, que como ya comentamos, se trata de un recurso
indispensable para la búsqueda semántica, ya que cuenta con información sobre los
sentidos de las palabras, aportando precisión. De esta forma WordNet nos proporciona
un lista de los sinónimo e hiperónimos de una palabra ordenados por significados,
31
estructurados los significados a la vez según su uso. Si introducimos por ejemplo la
palabra “cat” en el portal de WordNet online,
http://wordnetweb.princeton.edu/perl/webwn, el resultado será el expuesto en la Figura
15. Podemos ver como los significados más usados están en las posiciones más altas, y
como ésta herramienta nos devuelve una lista de sinónimos e hiperónimos para cada
uno de los significados.
Figura 15: Resultado de cat en WordNet.
Como vemos tenemos los diez significados descritos anteriormente, ocho sustantivos y
dos verbos, cada uno de ellos con sus sinónimos.
Por otro lado se ha de incluir una fase de filtrado de palabras vacías y de otras palabras
que no son válidas, ya que no son de interés pues este tipo de palabras están presente en
la mayoría de los documentos, lo que provocará confusiones. Este filtrado se debe
realizar sobre la lista total, incluyendo los sinónimos e hiperónimos, de las palabras de
consulta. Además de eficiencia, este paso aportará menor costo computacional.
Llegados aquí, se tendrá una lista con todas las palabras objetos a consultar Nos queda
por tanto la realización de esta consulta a partir del catálogo de palabras que tenemos.
Como antes hemos mencionado no se puede acceder a los datos de la plataforma
LdShake de forma fácil por lo que esta consulta no se puede hacer directamente sobre
estos. La solución será preguntar a la ontología en referencia al lenguaje de patrones, y
consultar sobre las palabras claves devueltas por esta, para los distintos patrones de
aprendizaje, la presencia de la lista de palabras objetos.
32
Con todo esto, el diagrama de secuencias correspondiente a la realización de una query
por parte de un usuario registrado será el expuesto en la Figura 16. Se toma como punto
de partida que el usuario se encuentre en la página donde se encuentra la barra de
búsqueda, Patterns.
Para entender mejor este diagrama de secuencias explicamos a continuación las
funciones que aparecen:
- query(): el usuario completa la barra de búsqueda y pulsa enter o pulsa en la
imagen de búsqueda.
- searchWordNet(): el sistema conecta con WordNet para que este le devuelva los
siónimos e hiperónimos de las palabras de la consulta.
- removeStopWords(): se realiza el filtrado de palabras.
- call_ontology(): se conecta con la ontología para que esta devuelva los datos
necesarios.
- searchPatterns(): se consultan los campos proporcionados por la ontología.
- visualization(): se visualizan los resultados. Paso siguiente.
Como podemos ver, todas estas funciones están relacionadas con lo explicado durante
este capítulo.
Figura 16: Diagrama de secuencias de una query.
4.2 Diseño de la Visualización El siguiente a paso a realizar será la visualización de los resultados obtenidos para la
query introducida por el usuario. Esto será exponer de alguna forma el nombre de los
patrones cuyas palabras claves tengan más relación con la lista de la palabra objetos
procedentes de la query. La forma de exponer esta lista de nombre deberá hacerse de
manera que sea de fácil comprensión para el usuario y del modo más eficaz.
33
La idea será realizar una especie de nubes de etiquetas donde los nombres de cada
patrón, que harían el papel de tags, aparecerán como un texto con un tamaño de fuente
relacionado con el número de palabras que contiene su descripción, de acuerdo con la
lista de palabras de la query. Es decir, se expondrán textos con mayor tamaño para los
resultados más relevantes y al revés. Para ello deberemos de ordenar de forma de mayor
a menor los patrones por su orden de relevancia, y de esta forma ir extrayendo de esta
lista ordenada los nombres de los primeros patrones que aparezcan, exponiendo sus
títulos con la fuente correspondiente y la imagen relacionada con tal patrón. Esta
presentación dinámica y la animación, aumentan la capacidad de aprovechamiento del
usuario.
Por otro lado vamos a visualizar los resultados como grupos de tres en tres. Esto se debe
a la regla de los números impartes, una técnica utilizada en fotografía que pretende
determinar el centro de atención del usuario en una imagen. Quizás de la derivada de la
secuencia de fibonacci, los grupos de elementos cuando son impares, confieren a la
imagen una sensación de dinamismo y equilibrio. Con los impares siempre es más fácil
centrar la atención en uno de ellos, el del centro normalmente. A continuación nuestra
atención se centrará en el elemento de la izquierda, posición por la que se comienza a
leer cualquier documento, y por último el usuario se centrará en el elemento
posicionado a la derecha. Por tanto conforme extraigamos de la lista se posicionará el
texto en el siguiente párrafo al centro a la derecha o a la izquierda según corresponda y
siguiendo ese orden. Cuando acabemos con un grupo de tres patrones empezamos con
otro y así hasta representar todos los patrones que consideremos relevantes. Así la
importancia de un patrón con relación a la query se plasmará en el tamaño del texto y en
su posición.
Con todo esto, la visualización de los resultados se dará de forma similar al ejemplo
expuesto en la Figura 17.
Figura 17: Ejemplo de visualización.
En este ejemplo vemos como el patrón de aprendizaje Jigsaw es el resultado más
relevante según la query, y TPS el que menos.
Por su parte, en el caso de no obtener resultados en la búsqueda, la pantalla de
visualización será similar a la de la Figura 18, es decir aparecerá un mensaje “Oops, no
result here”, para expresar la ausencia de resultados.
34
Figura 18: Mensaje para la ausencia de resultados.
La utilización de esta técnica para la visualización la justificamos por su sencillez y
facilidad de implementación, aprovechándonos de las ventajas que presentan las nubes
de etiquetas, como vimos en el apartado 2. Por un lado los nombres de los patrones se
obtendrán simplemente consultando los resultados devueltos por la ontología, y su
implementación gráfica puede obtenerse mediante HTML.
35
5. IMPLEMENTACIÓN
En este apartado llevaremos a cabo la implementación del sistema diseñado en el
capítulo anterior. A continuación se estudiarán las funciones a realizar y como se
realizarán, en distintos apartados de nuestro sistema, para alcanzar su cometido. Aquí
solo expondremos un resumen del código de programación, en el Anexo B se describen
con detalle para las funciones más importantes.
5.1 Implementación de la API
Trataremos la implementación de la API anteriormente descrita. Recordemos que la
API consistirá en un sistema que, mediante una query por parte de un usuario, dará
salida a documentos relacionados con el lenguaje de patrones. Como hemos visto en el
diseño de la aplicación, este sistema se podrá dividir en 5 partes: 1) Introducir de la
consulta, 2) Consulta a WordNet, 3) Filtrado de palabras, 4) Llamada a la Ontología, y
5) Búsqueda del patrón o patrones de aprendizaje adecuados a la consulta. A
continuación se explicará la implementación de cada uno de estos puntos.
a) Introducción de la consulta y procesado del texto
En un primer momento, el usuario se encontrará en la página referida a nuestra
aplicación dentro de LdShake. En esta encontrará un cuadro de búsqueda, como
podemos observar en la Figura 19, donde el usuario puede introducir la descripción de
su consulta.
Figura 19: Pantalla principal de la aplicación.
El sistema recogerá el texto de la query cuando el usuario presione enter o la imagen
relacionada con la realización de búsqueda. Este gesto nos llevará a la siguiente página,
denominada dentro de LdShake como query. En query se realizará la llamada a la función
searchPatterns, que realizará todos los pasos que estudiaremos a continuación.
b) Consulta de WordNet
Lo primer que hará la función searchPatterns será la llamada a la herramienta WordNet
para que esta devuelva la lista de sinónimos e hiperónimos de las palabras
correspondientes a la query, y así formar una lista con todas las palabras a consultar en
la ontología. Esto se hará mediante la función searchWordnet.
La versión que utilizaremos de WordNet será la 3.0, en inglés, ya que la última versión
3.1 no está aun disponible para descargas. Para poder utilizar la herramienta ha de ser
instalada en el equipo donde tendremos el código LdShake. La descarga del archivo se
36
realizará a partir de la plataforma http://wordnet.princeton.edu. La instalación se
realizará siguiendo los pasos expuestos en el documento INSTALL, que se encuentra
dentro del archivo descargado. Los distintos pasos a realizar para su instalación se
especifican en el Anexo A.
Lo primero que hará la función searchWordnet será separar las distintas palabras de la
query. Para ello se ayudará de la función de php explode, de manera que, utilizando el
espacio como limitador, dividimos el texto introducido en las distintas palabras.
Además se ha de pasar el texto de la query a minúsculas para no tener problemas
posteriores con el filtrado de palabras, como veremos más adelante. Esto último se
realizará a partir de la función strtolower.
Por tanto, en queryWord tendremos un array con todas las palabras de la query, las
cuales trataremos una a una como explicamos a continuación. Como ya hemos dicho,
para obtener los sinónimos e hiperónimos de una palabra debemos de hacer una
consulta a WordNet, concretamente a su archivo wn, donde se encuentran todas las
funciones referente a la herramienta. Estas funciones incluidas en wn las podemos
observar en la Figura 20.
Figura 20: Funciones a implementar por WordNet 3.0.
Para utilizar estas funciones de WordNet en el código php debemos de emplear la
función Shell_exec() para poder leer la salida. Además deberemos de posicionarnos
dentro del directorio donde se encuentra el archivo wn y llamar a la función desde ahí.
La función utilizada en nuestro sistema será –syns{n|v|a|r}, esto es, -synsn para
sustantivos, -synsv para verbos, -synsa para adjetivos y –synsr para adverbios. Por tanto
para obtener desde php los resultados de los sinónimos e hiperónimos para el sustantivo
gato, la secuencia a ejecutar será:
Y el resultado obtenido, sobre la plataforma LdShake, será el expuesto en la Figura 21.
Como vemos para cada sentido tenemos una serie de sinónimos, y tras la flecha los
hiperónimos relacionados con este.
$resultN=shell_exec("/usr/local/WordNet-3.0/bin/wn cat -synsn");
37
Figura 21: Resultado de la función –synsn para “cat”
Así para obtener los sinónimos e hiperónimos de cada palabra de la query deberíamos
de realizar un barrido del array queryWord y realizar la llamada de la misma foca que
con “cat”. Por ejemplo para obtener los sinónimos e hiperónimos de sustantivos
tendremos el código:
Si introducimos la query “cat dog” el resultado será el contemplado en la Figura 22.
Figura 22: Resultado de la función –synsn para la query “cat dog”
Como sabemos una palabra puede ser un sustantivo, un verbo, un adjetivo o un
adverbio. Esto ocurría con el caso de la palabra “cat” que como vimos anteriormente
podría ser sustantivo o verbo. Por tanto para tener una búsqueda más completa hemos
de hallar los sinónimos e hiperónimos de las palabras como si se tratasen de los cuatro
tipos. Esto es, hallaremos los sinónimos e hiperónimos para cada palabra queryWord
como si fuera un sustantivo, un verbo, un adjetivo y un adverbio, juntando después
todos estos en una misma lista, relacionada con la queryWord. Lo fácil sería determinar
el tipo de palabra con la que trabajamos, pero eso necesitaría la desambiguación de la
palabra, cosa con la que no podemos contar. De esta forma hemos de llamar desde el
programa en php cuatro veces a WordNet para obtener los resultados para las distintas
categorías gramaticales de cada palabra, cada $queryWord[$i]:
for($i = 0; $i <= count($queryWord); ++$i){
$resultN[$i]=shell_exec("/usr/local/WordNet-3.0/bin/wn ". $queryWord[$i]. " -synsn");
}
38
Ahora entonces, se tendría una serie de resultados para cada palabra y cada categoría
gramatical que puede representar esta, lo que podría ser demasiada información. Como
vimos en el apartado de diseño solamente tendremos que emplear aquellos sinónimos e
hiperónimos correspondientes a los significados más usados de cada palabra. En nuestro
caso tenemos la ventaja de que WordNet ya nos ordena los significados de las palabras
por orden de uso, por lo que cogiendo los datos referidos a los primeros significados
conseguiremos lo perseguido. Tras realizar varios estudios se considerarán los tres
primeros significados de cada palabra, ya que con dos no se podría tener en cuenta las
intenciones del usuario y con cuatro ya se aumentaría en su medida la lista de sinónimos
e hiperónimos final.
Por otra parte, los resultados obtenidos a través de la función –syns{n|v|a|r} son del tipo
visto en la Figura 21 y Figura 22, es decir, bloques de textos donde los datos se
presentan en un formato diseñado para ser leído por un humano y no por un programa.
En este punto hay que hacer alguna codificación, pues tendremos que tomar esos
bloques de texto y analizarlo para obtener los datos que deseamos, es decir, para
guardar en un array únicamente los sinónimos e hiperónimos necesarios.
Toda esta codificación se realizará en la función llamada por searchWordnet,
searchSyns. Esta función será ordenada después de cada llamada a WordNet para cada
tipo gramatical, es decir, fijándonos en lo anterior visto, después de $resultN, $resultV,
$resultA y $resultR. Las salidas de estas cuatro llamadas se juntarán en un array final.
Dentro de searchSyns se procesará cada bloque de texto, que se le pasa como entrada,
eliminándose los caracteres y textos no deseados, obteniendo un array con los
sinónimos e hiperónimos de los tres primeros significados de la palabra. Finalmente
este array se filtrará para que no se devuelvan ni palabras repetidas ni posiciones vacías.
A continuación explicaremos por pasos como operará la función searchSyns.
El primer paso de la función searchSyns será dividir en un array el bloque de texto de
entrada, para ello se hace uso de la función preg_split, utilizando como delimitador los
caracteres de espacio “\s”, lo que incluye \r, \t, \n y \f. A continuación se recorrerá la
lista resultado del paso anterior en búsqueda de los sinónimos e hiperónimos del primer,
segundo y tercer sentido de la palabra. Para ello se hará un barrido de la lista, parando
en los casos donde la palabra de la lista corresponda con “Sense”, momento en el cual
empiezan a listarse los sinónimos e hiperónimos de cada sentido de la palabra. Así, si en
el barrido encontramos la palabra “Sense” y estamos en los tres primeros sentidos,
utilizando un contador para su control, se empezarán a almacenar en un array, $sysn, el
contenido de las siguientes posiciones, hasta que se detectase el comienzo de otro
sentido, es decir, hasta que se localizase de nuevo la palabra “Sense”. Una vez llegado y
procesado a los resultados correspondientes al tercer sentido de la palabra, se finalizará
el proceso de captación de sinónimos e hiperónimos y se pasará al filtrado del array
//Sinónimo del Sustantivo
$resultN[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsn");
//Sinónimo de Verbo
$resultV[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsv");
//Sinónimo del Adjetivo
$resultA[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsa");
//Sinónimo del Adverbio
$resultR[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsr");
39
resultado $sysn. En este filtrado se eliminarán los caracteres no deseados, como
números, comas, paréntesis y demás mediante la función preg_replace; y texto no
deseado, como términos vacíos, a través de la función array_filter, o palabras que
empiecen por mayúscula y otros términos, mediante la función str_replace. La
eliminación de las palabras que empiecen por mayúsculas se realiza ya que estas
aparecen en el bloque de texto de forma explicativa o como nombre propio, lo cual no
nos interesa. La filtración de estas se realizará mediante la función ctype_lower, que
detecta si todas los caracteres de un string pasado están en minúsculas o no.
Por tanto, cada bloque de texto será procesado por searchSyns, donde está devolverá
una lista con los sinónimos e hiperónimos correspondientes. Ahora searchWordnet
deberá unir cada lista, correspondiente a cada categoría gramatical, en una sola ligada a
la queryWord. Para cada queryWord se tendrá entonces la siguiente secuencia de
ejecución dentro de la función searchWordnet.
El código completo de las funciones searchWordnet y searchSyns se expondrán en el Anexo B.
c) Filtrado de palabra
El paso siguiente a la obtención de la lista de sinónimos e hiperónimos de las palabras
de la query será la filtración de esta lista para detectar palabras vacías o palabras
repetidas y eliminarla. La no realización de este proceso podría tener como
consecuencia la obtención de resultados erróneos en la búsqueda de los patrones de
aprendizaje. Este proceso lo llevará a cabo la función filterWords, llamada dentro de la
función searchPatterns, y se le proporcionará como entrada la lista de todas las palabras
de la query del usuario así como sus sinónimos e hiperónimos, calculados en el paso
anterior.
El filtrado de las palabras vacias o stop words es necesario realizarlo, ya que son
palabras que suelen aparecer mucho en cualquier documento y si la utilizamos como
palabras objetos en la búsqueda, el resultado será erróneo. Para detectar las palabras
//Sinónimo del Sustantivo
$resultN[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsn");
$synsN[$i]=lds_contTools::searchSyns($resultN[$i]);
//Sinónimo de Verbo
$resultV[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsv");
$synsV[$i]=lds_contTools::searchSyns($resultV[$i]);
//Sinónimo del Adjetivo
$resultA[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsa");
$synsA[$i]=lds_contTools::searchSyns($resultA[$i]);
//Sinónimo del Adverbio
$resultR[$i]=shell_exec($dirWordNet. $queryWord[$i]. " -synsr");
$synsR[$i]=lds_contTools::searchSyns($resultR[$i]);
//Unimos en una única lista
$synonims[$i]=array_merge($synsN[$i],$synsV[$i],$synsR[$i],$syn
sA[$i]);
40
vacías se llevará a cabo la comparación con una lista definida de palabras vacias. De
esta manera, si la palabra se encuentra en esta lista, la palabra será una stop word. No
hay una lista definitiva de palabras vacías que todas las herramientas de procesamiento
de lenguaje natural incorporen. En nuestro caso se utilizará la misma lista de palabras
vacías que incorpora Google en su buscador. Esta es:
El proceso a realizar será por tanto el siguiente, a partir de la lista de entrada se realizará
un barrido, palabra por palabra, comprobado si se trata o no de una stop word. En el
caso que esto sea cierto se eliminará la palabra del array de entrada. Esto se realizará a
partir de las funciones in_array, para determinar si la palabra se encuentra en la lista, y
la función unset, para eliminar la palabra del array si preocede. Hay que tener en cuenta
que la función in_array usa comparación flexible, distinguiendo entre mayúsculas y
minúsculas, pero como hemos visto antes todas las palabras de la lista de entrada
estarán en minúsculas, al igual que las de la lista $stopWord.
Además WordNet no devolverá resultados para una palabra vacía, como podemos
observar en la Figura 23 para el ejemplo de “where” y “for”, por lo que con el
procedimiento anterior solventaríamos totalmente la existencia de estas en nuestra lista
de palabras.
Figura 23: Resultados vacios para una consulta en WordNet de las palabras vacías
“where” y “for”
Por su parte, la repetición de palabras en la lista puede llevar a una confusión en el
recuento de las palabras existentes en los bloques de textos devueltos por la ontología.
Es decir, por ejemplo, si la lista de palabras objetos fuera {“gato”, “perro”, “gato”},
para el string “El gato está comiendo” se contabilizaría que existen dos palabras de la
lista, cuando en realidad es solo una. Este problema es muy fácil de tratar pues con solo
la función array_unique se eliminan los valores duplicados de un array.
La función completa filterWords se expondrá en el Anexo B.
d) Llamada a ontología
Llegados a este punto nos quedará realizar la comprobación de la existencia de las
palabras resultados de los pasos anteriores, referentes a la query, en los documentos
relacionados con los patrones de aprendizaje. Como ya sabemos no podemos tratar con
la base de datos directamente, por lo que tendremos que utilizar a la ontología como
intermediaria.
$stopWord=array("i", "a", "about", "an", "are", "as", "at", "be", "by", "com", "for", "from",
"in", "is", "it", 'of', "on", "or", "that", "the", "this", "to", "was", "what", "when", "where",
"who", "will", "with", "the", "www");
41
La ontología cuenta con una serie de campos explicativos para cada patrón de
aprendizaje, entre los que tenemos: nombre del patrón, problema, intención y keywords,
entre otros. Por ejemplo para el patrón Facilitator la ontología contaría con la siguiente
información:
Figura 24: Ontología del patrón Facilator
En nuestro caso, los parámetros claves son las keywords relacionadas con cada patrón.
En la lista de estas keywords relacionadas con cada patrón en donde posteriormente se
realizará la comprobación de la existencia de las palabras relacionadas con la query y
sus sinónimos e hiperónimos.
Tendremos que realizar por tanto una conexión con la ontología para que esta nos
devuelva una lista en la que para cada patrón se obtenga una lista de sus keywords. Esta
conexión con la ontología se realizará mediante una clase java, OwlPaser0513 dentro
del paquete parser. En esta clase se realizará una llamada a la ontología, pidiéndole los
nombres y keywords de cada patrón, para ello se tendrá que dar acceso al fichero donde
guardaremos la ontología, proporcionando en el código la ruta exacta donde se
encuentra este. En nuestro caso la ruta donde tendremos el fichero.owl es en directorio
/opt. Una vez realizado esto se creará un HashMap de java en el cual se almacenarán
cada patrón como key del mapa y los keywords como los valores del mapa. La función
que realiza esto dentro de OwlPaser0513 es damekeywords().
Esta clase necesitará la librería apache-jena, la cual hemos descargado de página oficial,
http://jena.apache.org/. Para ellos compilaremos el .java correspondiente, mediante la
línea de comandos, ejecutando javac y expecificando el classpath de donde se
encuentran las librerías de jena, todos los .jar. En nuestro caso se ha de ejecutar:
Esta clase realizará entonces toda la conexión con la ontología y la devolución del mapa
con los patrones y sus keywords, pero todo esto lo hará en java, y no en PHP, el
lenguaje en el que está nuestro sistema. Para hacer uso de esta clase java y sus funciones
desde PHP, así como de otras funciones y clases de java, utilizaremos lo que se conoce
como JavaBridge, un puente entre java y php que permite la llamada de una función de
java desde php. La instalación de JavaBridge se detalla en el Anexo A.
Una vez instalado el puente en el repositorio webapps de Tomcat y su enlace en el
servidor Apache, para que desde php se pueda tener acceso a la clase OwlPaser0513
debemos realizar un jar del paquete parser, parse.jar, e introducirlos en el
JavaBridge.war en el directorio lib de WEB-INF. En este directorio también debemos
de incluir nuestros .jar correspondientes a las librerías de apache-jena. Una vez
realizado esto desplegamos de nuevo en Tomcat.
javac –cp ‘/home/maria/Descktop/apache-jena-2.10.1/lib/*’ OwlPaser0513.java
42
Para poder realizar llamadas a java es necesario que en la primera línea de comandos de
donde se haga nuestra llamada se incluya, mediante la función require_once(), el
archivo de JavaBridge Java.inc, en nuestro caso se incluirá en start.php y esto quedará
como:
Por otro lado, nuestra función tendrá que crear entonces un objeto de la clase
OwlPaser0513 sobre el cual realizar la llamada a la función dameKeywords(). Esto se
realizará de la siguiente forma:
Como vemos será necesario la creación de un objeto de la clase HashMap para
recuperar la información devuelta por dameKeywords(). Lo que nos queda será realizar
la conversión del HashMap de java a un array key de php. Para ello haremos uso de un
iterador de java, mediante el cual recorreremos el HashMap, utilizando las funciones
entrySet() e iterator(). Para cada iteración crearemos un objeto java de la clase Map, en
el cual guardaremos cada mapa correspondiente a la iteración. Para cada mapa
obtendremos su key mediante setKey() y su valor mediante setValor(), obteniendo así
cada patrón, la key, y cada lista de keywords, el valor. Teniendo estos dos parámetros
podremos crear el array key de php, para ello rellenaremos el array en cada iteración de
la siguiente forma:
La función que realice tal acción será callOntology y será llamada dentro de searchPattern. El
resultado devuelto por la función será, como ya hemos dicho, un array donde se proporcionará
una lista de keywords y el nombre del patrón con el que se relacionan. El código completo de
esta función se detalla en el Anexo B.
e) Búsqueda del patrón
Llegados a este punto tendríamos por un lado un array que contendrá todos los posibles
patrones y la lista devuelta por la ontología, y por el otro lado una lista con todas las
palabras relacionadas con la query. En este paso lo que se tendrá que realizar es la
comprobación de la existencia de estas palabras en cada uno de los bloques de textos
proporcionados por la ontología. Se tendrá en cuenta el hecho de que exista la palabra
en el texto, no el número de veces que lo haga. Todo esto lo realizará la función
searchPattern, tras las llamadas a todas las funciones anteriores, y los pasos a seguir por
está serán los descritos en este punto.
Lo primero que debemos hacer es un recorrido en el array devuelto por la ontología, así,
ayudándonos de un bucle for, procesaremos cada bloque de texto por separado. Para
obtener cada string se hará de forma ordenada, utilizando la función array_shift, la cual
quita un elemento del principio del array pasado como entrada y lo devuelve. A
continuación se tendrá que consultar la existencia de cada palabra referente a la query
en cada bloque obtenido o en el titulo del patrón. Esto se realizará palabra por palabra,
comprobando la existencia de la palabra, un substring, en el texto, string. Esta
comprobación se podrá realizar a partir de funciones como preg_match, stristr o strpos.
$listOntology[$patron]=$keywords;
$java_obj=new Java("parser.OwlPaser0513");
$lista=java("java.util.HashMap");
$lista=$java_obj->dameKeywords();
require_once(“/var/www/JavaBridge/java/Java.inc”);
43
En nuestro caso utilizaremos stristr, ya que tiene menos coste computacional que
preg_match y es insensible a mayúsculas y minúsculas. Está nos devolverá la posición
donde ocurre el substring dentro del string, y en el caso de que no fuera encontrado el
substring devolverá FALSE. Por lo tanto en el caso contrario a FALSE debemos de
aumentar en uno el contador de palabras existentes, pasando a la comprobación de la
siguiente palabra de la lista. Deberá existir por tanto un contador relacionado con cada
patrón, el resultado será un array donde se almacenen cada patrón de aprendizaje y su
contador.
Ahora bien, hemos de tener mucho cuidado en este punto, ya que la función utilizada
stristr, así como sus semejantes, puede llevar a confusión. Por ejemplo si tenemos el
string “early” y comprobamos la existencia del substring “ear”, el resultado será
afirmativo. Esto no puede ocurrir en nuestro sistema, por lo que tendremos que llevar a
cabo una solución. Para ello a cada palabra objeto se le añadirá un espacio al final,
realizando la comprobación de este nuevo substring, es decir, en nuestro ejemplo se
realizará la comprobación con el substring “ear ”. Con esto se solucionará el problema,
pero conllevará a que se tendrá que introducir también un espacio al final de cada
bloque de texto, para tener en cuenta la palabra final.
El código a ejecutar en la función searchPattern se expone en el Anexo B.
Una vez obtenida la lista de los patrones de aprendizaje y sus contadores de palabras, se
ordenará de mayor a menor y el paso siguiente será la visualización de los resultados en
relación a esta lista.
5.2 Implementación de la Visualización
Como vimos en el diseño el siguiente paso será la visualización de los resultados, esta
seguirá un algoritmo mediante el cual se expondrán los títulos de los patrones, y su
imagen representativas, con tamaños y posiciones según la relevancia de cada uno de
los patrones. Esto se realizará utilizando codificación php y HTML dentro del archivo
querylist. Lo que se hará será exponer el título del patrón, en la fuente correspondiente,
junto a su imagen y además en la posición que le corresponda.
El código HTML permite indicar el tamaño de la fuente, su valor puede estar entre 1 y
7. Incrementándose de tamaño progresivamente desde 1, que es la fuente de menor
tamaño, hasta 7 que la fuente de mayor tamaño. Como tenemos, como resultado del
paso anterior, la lista de los patrones y sus contadores de palabras ordenados de mayor a
menor, podemos crear una lista de pesos, del 7 al 1, donde el patrón con peso 7 sea el
que tenga un contador mayor y el patrón con peso 1 el séptimo en el orden del contador.
Se visualizarán por tanto siete patrones, cuyos tamaños de fuentes estarán relacionados
con el peso que obtengan al realizar este paso. La exposición de los siete primeros
patrones será suficiente para representar las expectativas del usuario. Pero esto ocurriría
si cada contador fuera distinto, lo que no siempre ocurre. En el caso de que, por
ejemplo, dos patrones obtengan el mismo contador el peso asignado a ambos patrones
será el mismo, ya que ambos tienen la misma relevancia.
Para ello crearemos un nuevo array, en el cual guardaremos los pesos, siendo las claves
de este array los patrones. A continuación se explican los pasos para la realización de
este. A partir del array $contWord resultado se searchPattern, se obtendrá utilizando
array_shift el primer término del array, eliminándose además de este, el que tiene
contador mayor; se obtendrá el patrón al que corresponde, mediante la función
array_search, y se almacenará en el nuevo array con un peso igual a siete y como clave
el nombre del patrón correspondiente. A continuación comprobamos si existe otro
44
patrón con el mismo contador, mediante la función in_array, si fuera así el caso se
rescataría ese patrón y se guardaría de la misma forma que el anterior en el nuevo array
con el mismo peso, siete, y así hasta que se compruebe que no existe otro contador igual
en el array de contadores. Seguidamente se reducirá el peso a seis y se repetirá el mismo
proceso hasta llegar al peso cero. Es decir, tendremos un array donde se guardarán los
distintos patrones y sus pesos, del siete al uno, pudiendo haber pesos repetidos para
distintos patrones. A la hora de imprimir el texto en la pantalla, mediante HTML el peso
regirá su tamaño de fuente, size.
A continuación se llevará a cabo el posicionamiento de los textos e imágenes según lo
diseñado en el apartado anterior. Si recordamos el posicionamiento se realizará en base
a grupos de tres, distribuyendo los tres textos uno en el centro otro en la línea inferior a
la izquierda y otro en la línea inferior a este a la derecha, debido a lo que discutimos a la
hora del diseño. Esto se realizará con la ayuda de un contador y mediante un switch. El
contador tendrá un valor de uno para cada grupo de tres que vaya a empezar a
posicionar, aumentando en uno tras situar cada texto, hasta que llegue a tres que se
volverá a la posición inicial del contar. Mediante el switch se posicionará en el centro
para valores de contador uno, en el lado izquierdo para valores de contador 2 y en la
derecha para valores de contador tres. El posicionamiento en la página se llevará a
cambo mediante HTML y la opción aling para los textos.
El código HTML utilizado para la visualización de cada texto referente al nombre de
cada patrón será el siguiente:
Las variables $peso y $aling son las proporcionadas por los algoritmos descritos
anteriormente. El resultado obtenido será similar al expuesto en el ejemplo de la Figura
17. Por su parte la ausencia de resultados se expresará de la misma forma de la que
aparece en la Figura 18.
El código completo de la función que realiza todo esto estará definido en el Anexo B.
Por su parte, para acceder al documento de texto correspondiente a cada patrón solo
bastará con cliquear sobre su nombre. Esta acción nos llevará una página donde se
encontrará embebido el pdf correspondiente al patrón, mediante el código:
Como solo pueden ser visualizados por los usuarios registrados, no existe la opción de
descarga del pdf. La forma de la página con el patrón embebido será igual a la del
ejemplo del patrón “pyramid” de la Figura 25:
<embed src='//localhost/ldshake/mod/lds/vendors/pdf/<?php echo $vars['pattern'];
?>.pdf'width="1000" height="900"> </embed>
<div <p id id="pattern_result" align=<?php echo $aling ?> ><FONT SIZE=<?php echo
$peso?> color="#800000"><a href="<?php echo $vars['url'];?>pg/lds/pdf?q=<?php echo
$patterns ?>"><?php echo $patternsname?></FONT></p> </a></div>
45
Figura 25: Consulta del patrón “pyramid”
5.3 Integración en LdShake
La integración de nuestra aplicación en LdShake la realizaremos a través de la
modificación del módulo lds implementado ya en la plataforma. Las distintas funciones
se lanzarán a través del script start.php de este módulo.
Las funciones anteriormente descritas para la implementación de la API de control se
implementarán en la clase lds_coontTools del módulo lds. Las funciones completas se
detallan en el Anexo B.
Por su parte la visualización utilizada se encuentran en el directorio view del módulo
lds. La primera página de nuestra aplicación, Figura 19, se detalla en el script
patterns.php, y la visualización de los resultados, Figura 17 o 18, en query.php. Esta
última hace uso también del código querylist.php para la implementación de la
visualización siguiendo nuestro diseño, anteriormente descrita. Todos estos scripts
hacen unos de HTLM y de la paginación por elgg.
46
47
6. PRUEBAS
Una vez terminadas las etapas de diseño e implementación nos queda evaluar si el
sistema final cumple con los requisitos establecidos al comienzo del trabajo. A
continuación se explicarán algunas pruebas realizadas para la valoración de los
requisitos y sus resultados.
6.1 Pruebas de validación de requisitos
A continuación realizamos un análisis para comprobar si se cumplen los distintos casos
de uso del sistema. Para ello comprobaremos, como para un cumplimiento de las pre-
condiciones, se obtienen los resultados esperados que expusimos en el capítulo 2. Los
diferentes casos de uso y su evaluación serán:
- Realización de la query: el usuario registrado en la plataforma LdShake podrá
realizar una consulta sobre el lenguaje de patrones a través de la herramienta
Patterns de LdShake. El resultado de la consulta es una lista de los patrones,
devuelta por el sistema,
- Leer documento resultado: una vez realizada la consulta el usuario, como ya
sabemos, obtiene una lista con una serie patrones de aprendizaje. A partir de esta
lista, devuelta por el sistema, el usuario puede cliquear sobre el patrón que crea
oportuno y acceder al documento relacionado con este.
Vemos entonces como se cumplen los casos de usos planificados.
6.2 Pruebas con usuarios
Por falta de tiempo debido a algunos problemas surgidos durante la elaboración del
trabajo, no ha sido posible reunir un grupo de usuarios para evaluar el sistema y sus
experiencias.
En el caso de la visualización si realizamos varias pruebas para su correcta
implementación. Para ello seleccionamos un grupo de 6 personas y les proporcionamos
la siguiente Figura 25:
Figura 26: Prueba de visualización.
A continuación se les pidió que comentaran en qué orden habían visto las distintas
palabras. Como resultado 5 de las 6 personas dijeron el siguiente orden: Gato, Perro y
Tortuga.
Los resultados de esta prueba fueron cruciales para la elaboración de la visualización de
los resultados.
6.3 Pruebas ejemplos
Como no hemos podido realizar pruebas con usuarios por limitaciones temporales, vamos a
exponer una serie de ejemplos para verificar los casos de uso. Los pasos que seguiremos se
detallan a continuación.
48
- Lo primero que haremos será loguearnos en la plataforma, LdShake, con nuestro
usuario. En nuestro caso entramos como administrador, username=”admin”.
- A continuación nos dirigiremos a la pestaña “Patterns” de la barra superior de LdShake.
La página de bienvenida de Patterns será la expuesta en la Figura 19.
- Ahora en el cuadro de texto introduciremos nuestra consulta.
Este punto lo dividimos en dos casos: realizar una consulta con resultado y/o realizar
una consulta sin resultados; primero veremos el caso en el que sí tenemos resultados.
a) Consulta con resultados:
Introducimos la consulta: “make a group of students to generate a large number
of ideas”, como vemos en la Figura 27:
Figura 27: Introducción consulta prueba.
A continuación pulsamos Intro, momento en el cual el sistema capta nuestra
consulta. Los resultados expuestos por el sistema son los que podemos observar en la
Figura 28:
Figura 28: Resultados consulta prueba.
Vemos como nos exponen siete patrones resultados y podemos captar la
relevancia que tienen estos con respecto a nuestra consulta fácilmente, mediante los tamaños y
posicionamiento de los resultados.
A continuación, si por ejemplo clickeamos en el patrón “Brainstorming”, el
sistema nos direccionará a una página donde se encuentre embebido el pdf correspondiente al
patrón “Brainstorming”, sin opción a descarga de este, como podemos observar en la Figura 29:
49
Figura 29: Visualización patrón “Brainstorming” consulta prueba.
b) Consulta sin resultados
El caso contrario al expuesto anteriormente es la realización de una consulta la cual
no tenga ningún resultado, es decir, la consulta no se corresponde con ningún patrón. Este sería
el caso, por ejemplo, de realizar una consulta de la palabra “dog”. Esto es, en el cuadro de texto
expuesto en la Figura 19 introduciremos la palabra “dog”, pulsando Intro el sistema nos
devuelve la pantalla de la Figura 18, es decir, nos informa de la ausencia de resultados.
Vemos así como el sistema funciona correctamente.
50
51
7. CONCLUSIONES Y TRABAJOS FUTUROS
Tras la elaboración del sistema procedemos a analizar los resultados adquiriendo una
serie de conclusiones, y plantear algunos puntos a desarrollar en el futuro.
7.1 Conclusiones
Como conclusión principal podemos decir que el presente trabajo responde
adecuadamente a los problemas que se presentaban al principio. Estos problemas son:
- Inexistencia de una interfaz para la realización de consultas sobre patrones de
aprendizaje.
- Deficiencia en los sistemas de búsqueda por palabra clave.
Nuestro sistema ofrece una interfaz donde los usuarios registrados en la plataforma
LdShake puedan realizar una consulta sobre el lenguaje de patrones. La búsqueda de los
patrones en relación a la consulta se apoya en principios de la búsqueda semántica.
Si analizamos los resultados obtenidos de este trabajo podemos obtener los siguientes
datos:
- La búsqueda se efectúa no solo en base a las palabras introducidas por el usuario
en la consulta, sino también en base a sus sinónimos e hiperónimos. A causa de
esto el usuario puede expresar su consulta de forma natural, sin necesidad de que
las palabras utilizadas para ello coincidan con las palabras claves devueltas por
la ontología. Con esto se consigue mayor efectividad a la hora de obtener los
resultados esperados, ya que el usuario no tendrá que replantear la consulta hasta
que esta coincida con las palabras claves del patrón requerido.
- La búsqueda se realiza sobre los datos devueltos por la ontología del lenguaje de
patrones, la cual nos facilita las palabras claves de cada patrón. De esta forma se
mejora considerablemente los resultados obtenidos respecto a una simple
búsqueda por palabra clave. Además esto permite ganar velocidad en la
búsqueda ya que son listas de no más de 20 palabras.
- Como resultado a la consulta se obtendrá una lista de los patrones cuyas palabras
claves coinciden con el mayor número de palabras de la consulta. Esta lista se
presentará de una forma en la que el usuario perciba con gran facilidad la
relevancia de cada patrón en relación a su consulta.
Como punto negativo tenemos la falta de desambiguación de palabras. Lo ideal sería
que en relación con la consulta introducida por el usuario, se obtuviera el sentido más
adecuado para cada palabra y obtener los sinónimos e hiperónimos para tal sentido. En
este trabajo, debido a los problemas comentados en la etapa de diseño, se toman como
útiles los tres sentidos más utilizados de cada palabra para la obtención de sus
sinónimos e hiperónimos.
7.2 Trabajos futuros
Sobre este trabajo se pueden desarrollar varias mejoras y ampliaciones futuras. La
mayoría de estas cuestiones afectan a la usabilidad de la aplicación, tratando de mejorar
la experiencia del usuario. A continuación exponemos
- Desambiguación de palabras: Incorporar la desambiguación de las palabras
introducidas por el usuario para determinar el sentido correcto de la palabra. Una
de las formas en la que se podrá implementar será mediante la utilización de la
base de datos LdShake, como se expuso en el capítulo de diseño.
52
- Visualización de relaciones entre patrones: Visualizar para cada patrón
resultado una lista, y accesos, con los patrones del lenguaje de patrones que lo
completen y/o complementen, para así devolver unos resultados más completos
al usuario.
- Idiomas: permitir la posibilidad del empleo de otro idioma, distinto al inglés,
para la realización de las consultas.
- Comentarios: incluir una interfaz donde los usuarios puedan exponer sus
opiniones y comentarios sobre cada patrón de aprendizaje.
- Filtros de búsqueda: incluir filtro a la hora de realizar la consulta. Ahora
mismo solo disponemos de la lista de palabras claves para cada patrón, pero en
líneas futuras se podrían realizar consultas a la ontología sobre otros campos,
como por ejemplo intención o problema.
53
8. BIBLIOGRAFÍA
1. Alexander C. The timeless way of building. Oxford University Press, editor. New
York: Oxford University Press; 1979.
2. Abenia Polo P. Integración de editores en LdShake [dissertation]. Universidad
Pompeu Fabra; 2011.
3. Sistema de gestión de aprendizaje [Internet]; 2013 [updated 18/01. Available from:
http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_aprendizaje.
4. Aguilar A, Encarnación V, Medina L. Learning managment systems (lms) o sistemas
de gestión del aprendizaje. 2010:2010(09/05).
5. Le web 2.0 illustré en une seule image [Internet].; 2007 [updated 19/07. Available
from: http://blog.cozic.fr/le-web20-illustre-en-une-seule-image.
6. Castaño Garrido C. La educación a distancia en el marco web 2.0. VII congreso de
investigación y creación intelectual de la UNIMET; 26/05; ; 2010.
7. Berners-Lee T, Hendler J, Lassila O. The semantic web. Scientific American.
2001;284[5]:34-43.
8. Abián MA. El futuro de la web. 2011;2011(08/01).
9. Lozano Tello A. Ontología en la web semántica. Cuadernos de Investigación en
Ingeniería Informática. 2001;5(Ingeniería Web: Nuevos Retos Tecnológicos en la Era
de la Información):2-3.
10. Gruber T. A translation approach to portable ontology specifications. Knowledge
Acquisition. 1993;5[2]:199-220.
11. Desarrollo iterativo e incremental [Internet].; 2012 [updated 29/08/2012. Available
from: http://www.slideshare.net/noriver/desarrollo-iterativo-e-incremental.
12. Arrieta A. La nueva forntera: Buscadores semánticos. 2009;2009(06/08).
13. Abián MA. Buscadores semánticos: Comprender para encontrar (parte 1).
Buscadores semánticos: comprender para encontrar. 2012;3(1):1-10.
14. Procesamiento del lenguaje natural en inteligencia artificial [Internet].:
monografías.com; 2005 [updated 27/02/2005]. Available from:
http://www.monografias.com/trabajos17/lenguaje-natural/lenguaje-natural.shtml.
15. WordNet 3.0 database statistics [Internet].: Universidad de Pronceton; 2012
[updated 09/08/2012. Available from:
http://wordnet.princeton.edu/wordnet/man/wnstats.7WN.html#sect0.
16. Pancardo Rodríguez A. La web como recurso lingüistico para la desambiguación
semántica [dissertation]. Inade; 2006.
17. Visualización de la información [Internet].: Glossarium-BITri; 2009 [updated
18/11/2009. Available from: http://glossarium.bitrum.unileon.es/Home/visualizacion-
de-la-informacion.
18. Hassan Montero Y. Visualización y recuperación de información [dissertation].
Universidad de Granada; 2006.
19. IEEE [Internet]. 2013. Available from: http://www.ieee.org/
54
20. Ingenieria de software [Internet].; 2013 [updated 31/10/2000] Available from:
http://www.monografias.com/trabajos5/inso/inso.shtml.
21. Métrica NGD (distancia normalizada de google) [Internet].; 2007 [updated
10/06/2007. Available from: http://ferbor.blogspot.com.es/2007/06/mtrica-ngd-
distancia-nornamlizada-de.html.
55
9. ANEXOS
9.1 Anexo A-Manual de Instalaciones
a) WordNet-3.0
La descarga del paquete WordNet-3.0 la realizaremos a partir de la página oficial de
WordNet ya comentada. Para la instalación de WordNet-3.0 necesitaremos los paquetes
tcl y tk que actúan como debugadores. Estos los instalaremos desde la línea de
comandos, asegurándonos de que el servidor cuente con acceso a internet, de la
siguiente forma:
Los siguientes pasos a seguir son bastantes sencillos y se resumen en los siguientes
puntos:
- Realizamos un cd al directorio donde se encuentra el código fuente del paquete, en
nuestro caso WordNet-3.0/src, y lanzamos configure, ./configure.
- Compilamos el paquete mediante el comando ‘make’.
- Instalamos el paquete con el comando ‘make install’, y ya tenemos instalado nuestra
herramienta WordNet.
Siguiendo esta instalación el fichero donde se encontrará nuestra herramienta se
encontrará en /usr/local.
b) Apache Tomcat6
Para la instalación de paquete Apache Tomcat 6 se realizarán los siguientes pasos:
1. Desde la línea de comandos, asegurándonos de que el servidor cuente
con conexión a internet, instalaremos tomcat6 de la forma:
2. Para instalar la documentación de Tomcat6 ejecutamos:
3. Si queremos instalar la aplicación del administrador de Tomcat6, para
por ejemplo desplegar .war de forma manual, ejecutamos el siguiente
comando:
Bajo esta instalación los archivos de configuración se crean en el directorio /etc/tomcat6
y el directorio webapps de Tomcat se crea en /var/lib/tomcat6/webapps.
c) PHP-Java Bridge
Los pre-requisitos a cumplir antes de instalar nuestro Java Bridge son dos:
- Tener instalado Apache Tomcat5.5 o superior.
sudo apt-get install tomcat6-admin
sudo apt-get install tomcat6-docs
sudo apt-get install tomcat6
sudo apt-get install pkg –config tcl-dev
sudo apt-get install pkg –config tk-dev
56
- Contar con PHP y Apache instalados.
Cumpliendo ambos requisitos procedemos a la descarga del fichero y a su instalación en
Tomcat.
El paquete necesario nos lo podemos descargar de http://php-java-
bridge.sourceforge.net/pjb/download.php. Una vez en el sitio de download bajamos el
archivo php-java-bridge_x.x.x_documentation.zip, en nuestro caso el php-java-
bridge_6.2.1_documentation.zip.
Descomprimimos el archivo y dentro encontramos el archivo JavaBridge.war.
Copiamos este al directorio webapps de tomcat, el cual se localizará en nuestro caso en
la dirección /var/lib/tomcat6/webapps.
Tomcat desplegará automaticamente el archivo JavaBridge.war, aunque a veces en
linux esto no puede ocurrir. En este caso hechos mano del root user y descomprimimos
manualmente el war file, convirtiéndolo primero a zip y luego descomprimir con el
comando:
A continuación levantamos el Tomcat, con el comando start, para comprobar que todo
va bien nos vamos a la página http://localhost:8080/JavaBridge/test.php, Tomcat estará
escuchando desde el puerto 8080, y aparecerá la pagina de información de php que es
generado por el método phpinfo().
Por otro lado, para crear enlace con el servidor Apache, tendremos que ejecutar el
siguiente comando. El primer directorio indicado dependerá de donde tenemos el
directorio de Tomcat, en nuestro caso será:
Con esto creamos un link a la carpeta donde se encuentra el JavaBridge dentro de
Tomcat en la carpeta principal de Apache. Ahora vamos si vamos a la dirección
http://localhost/JavaBridge/test.php , si to va bien aparecerá de nuevo la pagina de
información de php.
ln -s /var/lib/tomcat6/webapps/JavaBridge /var/www/JavaBridge
unzip JavaBridge.zip -d JavaBridge
57
9.2 Anexo B-Código
a) Función searchWordNet
public static function searchWordnet($query) {
//Pasamos a minúsculas todo el string de la query, para evitar problemas
$query = strtolower($query);
$listWord = array(); //lista a devolver con todas las palabras de la query y sus sinónimos e
hiperónimos
//Directorio donde se encuentra la herramienta WordNet
$dirWordNet = "/usr/local/WordNet-3.0/bin/wn ";
//Procesamos la cadena introducida por el usuario
$queryWord = explode(" ", $query);
for ($i = 0; $i <= count($queryWord); ++$i) {
$synonims[$i] = array();
//Sinonimos de objeto
$resultN[$i] = shell_exec($dirWordNet . $queryWord[$i] . " -synsn");
$synsN[$i] = lds_contTools::searchSyns($resultN[$i]);
//Sinonimo de verbo
$resultV[$i] = shell_exec($dirWordNet . $queryWord[$i] . " -synsv");
$synsV[$i] = lds_contTools::searchSyns($resultV[$i]);
//Sinonimo del adverbio
$resultR[$i] = shell_exec($dirWordNet . $queryWord[$i] . " -synsr");
$synsR[$i] = lds_contTools::searchSyns($resultR[$i]);
//Sinonimo del adjetivo
$resultA[$i] = shell_exec($dirWordNet . $queryWord[$i] . " -synsa");
$synsA[$i] = lds_contTools::searchSyns($resultA[$i]);
//Unimos todos los sinónimos resultantes en un mismo array
$synonims[$i] = array_merge($synsN[$i], $synsV[$i], $synsR[$i], $synsA[$i]);
//Unir todos los sinónimos y las palabras query
$listWord[] = $queryWord[$i];
$listWord = array_merge($listWord, $synonims[$i]);
}
return $listWord;
}
b) Función searchSyns
public static function searchSyns($text) {
//Convertimos en array el bloque de texto, utilizando como delimitador los carácteres de
espacio
$list = preg_split('/[\s]+/', $text);
//Creamos el array a rellenar con los sinonimos e hiperonimos
$syns = array();
//Ponemos el contador que nos determinará en el sentido que estamos a uno, el sentido 1.
$cont = 1;
//Recorremos el array resultado de dividir el bloque de texto
for ($j = 0; $j <= count($list); ++$j) {
//Si encontramos un sentido de la plabra y es de los tres primeros
if (strcmp("Sense", $list[$j]) == 0 && $cont <= 3) {
//Puntero auxiliar que se podiciona en la primera palabra del sentido correspondiente de la
palabra
$k = $j + 1;
//Recorremos el resto de la lista
while ($k <= (count($list))) {
58
//Eliminamos los antónimos
if (strcmp('(vs.', $list[$k]) == 0) {
$k = 2 + $k;
}
//Si sigue perteneciendo al mismo sentido lo guardamos
if (strcmp("Sense", $list[$k]) != 0) {
//Guardamos el string en nuestro array
array_push($syns, $list[$k]);
//Se aumenta el puntero
++$k;
}
//Si cambiamos de sentido salimos del bucle while para buscar el siguiente sentido
else {
break 1;
}
}
//Aumentamos el contador
$cont = $cont + 1;
}
}
//Eliminamos numeros, comas y demás texto no deseado
$syns = preg_replace('/[0-9,;#=>()-]/', "", $syns);
$syns = str_replace('prenominal', "", $syns);
$syns = str_replace('predicate', "", $syns);
//Eliminamos las palabras que empiecen por mayúsculas.
for ($i = 0; $i <= count($syns); ++$i) {
//Comprobamos si la palabra tiene todos sus carácteres en minúscula
if (!(ctype_lower($syns[$i]))) {
//Si tienen carácteres en mayúscula eliminamos la palabra del array
unset($syns[$i]);
}
}
//Eliminamos los terminos vacios
$syns = array_filter($syns);
//Reposicionamos el array
$syns = array_values($syns);
return $syns;
}
c) Función filterWords
public static function filterWords($list){
//Lista de palabras vacÃas de Google
$stopWord=array("I", "a", "about", "an", "are", "as", "at", "be", "by", "com", "for", "from",
"in", "is", "it", 'of', "on", "or", "that", "the", "this", "to", "was", "what", "when", "where", "who",
"will", "with", "the", "www");
//comprobamos si la palabra esta en el array
for($i=0; $i<=count($list); ++$i){
if(in_array($list[$i], $stopWord)){
//En el caso de que exista se trata como palabra vacia y se elimina de la lista
unset($list[$i]);
}
}
//Eliminamos palabras repetidas y posiciones vacias
$listResult=array_values(array_unique($list));
59
$listResult=array_values(array_filter($listResult));
return $listResult;
}
d) Función callOntology
public static function callOntology(){
//Array key a rellenar con los patrones y sus keywords
$listOntology=array();
//Número de patrones en la ontología
$numPatterns=18;
//Objeto de la clase OwlPaser0513
$java_obj=new Java("parser.OwlPaser0513");
//Objeto de la clase HashMap, para guardar el resultado de la función dameKeywords()
$lista=java("java.util.HashMap");
//Llamada a la función dameKeyWords() de la clase OwlPaser0513
$lista=$java_obj->dameKeywords();
//Contador para el número de iteraciones
$cont=0;
//Objeto de la clase iterator
$it=java("java.util.Iterator");
//Recorrido del HashMap mediante iteración
$it=$lista->entrySet()->iterator();
//Barrido de todos los mapas
while($cont<$numPatterns){
$cont++;
//Objeto d ela clase Map
$e=java("java.util.Map");
//Obtenemos el mapa
$e=$it->next();
//Obtenemos su key, correspondiente al patrón
$patron=java_values($e->getKey());
//Codificamos el nombre devuelto
$patron=explode('_', $patron);
$patron=$patron[1];
//Obtenemos su valor, correspondiente las keywords
$keywords=java_values($e->getValue());
//Rellenamos el array con los datos
$listOntology[$patron]=$keywords;
}
return $listOntology;
}
e) Función searchPatterns
public static function searchPatterns($query) {
//Array en el cual guardaremos cada patrón con el contador correspondiente a la coincidencia
de sus keywords con la lista de palabras relacionadas con la consulta
$contWord = array();
$query = addslashes($query);
//Llamamos a WordNet para que nos devuelva la lista con las palabras de la query y sus
sinónimos e hièrónimos
$totalList = lds_contTools::searchWordnet($query);
//Filtramos tal lista para asegurarnos que no contenga ni palabras vacÃas ni repetidas
$listQueryWord = lds_contTools::filterWords($totalList);
//Llamamos a la ontologÃa
60
$listTextOntology= lds_contTools::callOntology();
//Codificamos el string donde se contienen las keywords para separar palabra por palabra
$listTextOntology=str_replace(",", " ", $listTextOntology);
$listTextOntology_aux = $listTextOntology;
//Hacemos un barrido del array devuelto por la ontología
for ($i = 0; $i < count($listTextOntology_aux); ++$i) {
$cont = 0;
//Extraemos el primer valor del array
$text = array_shift($listTextOntology);
//El patrón del que pertenece
$pattern = array_search($text, $listTextOntology_aux);
$text = $text . " ";
//Recorremos la lista de palabras de la consulta y sus sinónimos e hiperónimos
for ($j = 0; $j < count($listQueryWord); ++$j) {
//Si la palabra existe en la lista de keywords o en el titulo del patrón se suma uno al
contador
if (stristr($text, $listQueryWord[$j] . " ") != FALSE ||stristr($pattern, $listQueryWord[$j])
!= FALSE) {
++$cont;
}
}
//Almacenamos el patron y su contador
if($cont>0{
$contWord[$pattern] = $cont;
}
}
//ordenamos el array de mayor a menor
arsort($contWord);
return $contWord;
}
f) Función Visualización
<ul id="query_list">
<?php
//Obtenemos el array de contador de palabras devueltos por searchPattern
$contWord_aux = $vars['list'];
//El peso mayor será 7, porque imprimiremos los 7 primeros patrones
$peso = 7;
//Array donde guardaremos los patrones y sus pesos
$arrayPesos = array();
//Hacemos un barrido de los siete primeros del array
for ($i = 0; $i <= 7; ++$i) {
//Obtenemos su contador
$value = array_shift($vars['list']);
//Obtenemos el patrón al que pertenece
$patron = array_search($value, $contWord_aux);
//Lo introducimos en nuestro array donde guardarmemos los patrones y sus pesos
$arrayPesos[$patron] = $peso;
$contWord_aux = $vars['list'];
//Comprobamos si tenemos otro patrón con el mismo cantador
while (in_array($value, $vars['list'])) {
//obtenemos el contador
$valueA = array_shift($vars['list']);
61
//Obtenemos el patron
$patron = array_search($valueA, $contWord_aux);
$contWord_aux = $vars['list'];
//Lo incluimos en el array
$arrayPesos[$patron] = $peso;
}
//Disminuimos el peso
--$peso;
}
$cont=0;
for($i=0; $i<7; ++$i):
$listaux=$arrayPesos;
$aux=array_shift($arrayPesos);
$patterns=array_search($aux, $listaux);
$peso=(int)$aux;
//Codificamos el nombre del patrón devuelto para que se imprima de la manera
correcta
$patternsaux="";
$patternsname="";
for($j=0; $j<=strlen($patterns); ++$j){
if (ctype_upper($patterns[$j])){
$patternsaux[$j]=" ".$patterns[$j];
}
else{
$patternsaux[$j]=$patterns[$j];
}
$patternsname=$patternsname.$patternsaux[$j];
}
//Ponemos la primera letra en mayúsculas
$patternsname=ucwords($patternsname);
++$cont;
//Alineamos según vayan saliendo del array
switch($cont){
case 1:
$aling="center";
break;
case 2:
$aling="left";
break;
case 3:
$aling="right";
$cont=0;
break;
};
?>
<div <p id="pattern_result" align=<?php echo $aling ?> ><FONT SIZE=
<?php echo $peso?> color="#800000"><a href="<?php echo $vars['url'];
?>pg/lds/pdf?q=<?php echo $patterns ?>"><?php echo $patternsname
?></FONT>
</p> </a></div> <?php endfor;?>
</ul>
62
9.3 Anexo C-Glosario
Apache. Servidor Web HTTP.
CMS. Sistema de gestión de contenidos. Programa que permite crear una estructura de
soporte para la creación y administración de contenido.
ELGG. Framework en PHP para la creación de redes sociales.
HTML. Lenguaje de programación para la realización de páginas web.
Java Bridge. Puente que nos permite llamar desde un script PHP a una función de una
clase java.
JavaScript. Lenguaje de programación interpretado.
LMS. Learning Managment Agreement.
NetBeans. Editor de código multiplataforma.
NGD. Distancia normalizada de Google. Medida utilizada en algunos algoritmos para la
desambiguación de palabras.
PHP. Lenguaje orientado a la creación de páginas web dinámicas.
PLN. Procesamiento del lenguaje natural. Rama de la Inteligencia Artificial que permite
la conexión entre el lenguaje máquina y lenguaje humano.
Tag. Etiqueta.
Tomcat. Contenedor de servlets de Apache Software Foundation.
VIRI. Interfaz gráfica para la visualización de información.
WDS. Desambiguación del sentido de las palabras.
WordNet. Base de datos lexica.
63