Embed Size (px)
Citation preview
INSTITUTO TECNOLOGICO DE ESTUDIOS
SUPERIORES DE MONTERREY
CAMPUS MONTERREY
PROGRAMA DE GRADUADOS EN MECATRÓNICA Y
TECNOLOGÍAS DE INFORMACIÓN
METODOLOGÍA PARA LA INTEGRACIÓN Y
RECONCILIACIÓN DE INFORMACIÓN POR MEDIO DE
TECNOLOGÍA SEMÁNTICA
TESIS
PRESENTADO COMO REQUISITO PARCIAL PARA OBTENER EL GRADO
ACADÉMICO DE:
MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE INFORMACIÓN
Por:
ALEJANDRA CASAS BAYONA
MONTERREY, N. L. 11 DE DICIEMBRE 2013
II
INSTITUTO TECNOLÓGICO DE ESTUDIOS SUPERIORES DE MONTERREY
DIVISIÓN DE ESCUELA DE INGENIERÍA Y TECNOLOGÍAS INFORMACIÓN
PROGRAMA DE GRADUADOS EN MECATRÓNICA Y
TECNOLOGÍAS DE INFORMACIÓN
Los miembros del comité de tesis recomendamos que la presente tesis de la Licenciada en
Informática Alejandra Casas Bayona sea aceptada como requisito parcial para obtener el
grado académico de Maestro en Administración de Tecnologías de Información.
Comité de tesis:
___________________________________
Dr. Héctor Gibrán Ceballos Cancino
Asesor Principal
__________________________
Dra. Lorena Guadalupe Gómez Martínez
Sinodal
________________________________
Ing. Manuel Terán Malgarejo
Sinodal
_______________________________
Dra. Carmen Celina Torres Arcadia
Directora de la Maestría en Administración de Tecnologías de Información
III
Metodología para la Integración y
Reconciliación de Información por medio
de Tecnología Semántica
Por:
Alejandra Casas Bayona
TESIS
PRESENTADO COMO REQUISITO PARCIAL PARA OBTENER EL
GRADO ACADÉMICO DE:
MAESTRO EN ADMINISTRACIÓN DE TECNOLOGÍAS DE
INFORMACIÓN
INSTITUTO TECNOLÓGICO DE ESTUDIOS
SUPERIORES DE MONTERREY
CAMPUS MONTERREY
11 de Diciembre de 2013
IV
DEDICATORIA
A mi Mamá, mi gran ángel Olga Yolanda Bayona Santillán por sus enseñanzas en
este mundo y por ser luz del cielo que guía mis pasos.
A mi Papá, mi gran héroe Raúl Casas Arroyo por su incondicional y auténtico
apoyo.
A mis hermanos: Raúl, Guadalupe, Alma, Emmanuel y Yolanda, por ser mis
mejores compañeros y amigos en mi vida.
A mis sobrinos: Diego Alejandro, Mónica Yael, Sebastián, Dafne Guadalupe, Jesús
Daniel y Olga Alejandra.
V
AGRADECIMIENTOS
Agradezco a Dios mi fiel amigo.
Gracias a mis Padres, por ser mi mayor y gran fortaleza para seguir adelante, por los
consejos de Mamá y el cariño de Papá.
Gracias a mis hermanos por su gran apoyo, por su fidelidad y gran amor.
A mis sobrinos, por darme la chispa de cariño y amor en todo momento.
Gracias al Dr. Héctor por su apoyo, paciencia y grandes lecciones, no sólo de
conocimiento, sino de vida.
Gracias al Ing. Manuel T. y a la Dra. Lorena G, por su apoyo y dedicación en esta
investigación.
Gracias a mis compañeros y amigos, son una gran bendición.
VI
RESUMEN
La integración de datos es un problema generalizado presente en las aplicaciones y que
enfrentan usuarios que necesitan consultar en fuente de datos heterogéneas (Halevy &
Ordille, 2006) y semi-estructuradas. Existen muchas investigaciones tanto en el campo de
bases de datos como en la integración de la información las cuales han producido una gran
cantidad de desarrollos y aplicaciones para facilitar la interoperabilidad entre los diferentes
sistemas. La investigación de las ontologías se ocupan de la heterogeneidad semántica de
los datos estructurados (F. Noy, 2004).
Los principales problemas a los que se enfrentan las personas encargadas de administrar
información están enfocados con la identificación de información que esta semánticamente
relacionada; es decir, la información describe a un objeto en el mundo real de distinta forma
en varias fuentes las cuales son semánticamente heterogéneas (Bergamaschi, Castano,
Vincini, & Beneventano, 2001).
Existen metodologías que aportan gran valor en el proceso de integración de fuentes de
información heterogéneas y semi-estructuradas. Dichas metodologías hacen uso de
ontologías para darle un enfoque semántico a las fuentes de información resultante de la
integración. Esta investigación analiza metodologías existentes, como: MOMIS, SIMS,
Mirsoft, y se propone una nueva metodología llamada A&H. La Metodología A&H hace
uso de tecnología semántica para el proceso de integración; utiliza constructores del
lenguaje ontológico OWL y lenguaje de consultas SPARQL,; cuenta con la característica
de ser orientada a no-expertos en ontologías. Además, dicha Metodología ha sido validada
con un caso de estudio y comparada con otras Metodologías existentes.
VII
TABLA DE CONTENIDOS
DEDICATORIA ................................................................................................................................................. IV
AGRADECIMIENTOS ....................................................................................................................................... V
RESUMEN ......................................................................................................................................................... VI
TABLA DE CONTENIDOS ............................................................................................................................. VII
LISTA DE TABLAS ........................................................................................................................................... X
LISTA DE FIGURAS ......................................................................................................................................... XI
CAPÍTULO 1. INTRODUCCIÓN ..................................................................................................................... 13
1.1 ANTECEDENTES .................................................................................................................................. 14
1.2 MOTIVACIÓN ....................................................................................................................................... 15
1.3 OBJETIVOS ............................................................................................................................................ 16
1.4 PREGUNTA DE INVESTIGACIÓN ...................................................................................................... 17
1.5 JUSTIFICACIÓN .................................................................................................................................... 18
1.5.1 Contexto ............................................................................................................................................ 18
1.5.2 Forma en que se manifiesta el problema ........................................................................................... 19
1.6 ALCANCE DE LA INVESTIGACIÓN ................................................................................................. 21
1.7 ORGANIZACIÓN DE LA TESIS .......................................................................................................... 21
CAPÍTULO 2. MARCO TEÓRICO ................................................................................................................... 23
2.1 MODELACIÓN SEMÁNTICA .............................................................................................................. 23
2.2 WEB SEMÁNTICA ................................................................................................................................ 25
2.2.1 Ontologías................................................................................................................................. 30
2.2.2 Generación de Ontologías (Ontology Engineering) ................................................................. 31
2.2.3 Evolución ontológica (Ontology Evolution) ............................................................................. 32
2.3 INTEGRACIÓN DE DATOS ................................................................................................................. 33
2.4 EL PROCESO KDD ................................................................................................................................ 35
2.5 INTEGRACIÓN SEMÁNTICA DE DATOS ......................................................................................... 36
2.6 RECONCILIACIÓN ............................................................................................................................... 36
VIII
2.6.1 Reconciliación de Entidades ..................................................................................................... 37
2.6.2 Fusión de datos ......................................................................................................................... 38
2.7 LENGUAJES ONTOLÓGICOS ............................................................................................................. 39
2.7.1 RDF .......................................................................................................................................... 41
2.7.2 RDFS ........................................................................................................................................ 41
2.7.3 OWL ......................................................................................................................................... 41
2.8 RAZONADORES .................................................................................................................................... 44
2.9 LENGUAJE DE CONSULTAS – SPARQL ........................................................................................... 47
2.9.1 Funciones de Agregación .......................................................................................................... 48
2.10 METODOLOGÍAS DE INTEGRACIÓN DE INFORMACIÓN BASADA EN ONTOLOGÍAS .... 49
2.10.1 MOMIS ..................................................................................................................................... 49
2.10.2 SIMS ......................................................................................................................................... 55
2.10.3 MIRSOFT ................................................................................................................................. 57
CAPÍTULO 3. ANÁLISIS DE METODOLOGÍAS DE INTEGRACIÓN SEMÁNTICA DE INFORMACIÓN59
3.1 METODOLOGÍAS EXISTENTES ......................................................................................................... 59
3.1.1 MOMIS ..................................................................................................................................... 61
3.1.2 SIMS ......................................................................................................................................... 65
3.1.3 MIRSOFT ................................................................................................................................. 67
3.2 A&H PARA NO-ONTOLOGISTAS ...................................................................................................... 71
3.2.1 Etapa I – Requerimientos del usuario en un esquema global .................................................... 73
3.2.2 Etapa II – Selección de fuentes de información ........................................................................ 74
3.2.3 Etapa III – Preparación de datos ............................................................................................... 75
3.2.4 Etapa IV – Integración (Alineación de Ontologías) .................................................................. 75
3.2.5 Etapa V – Reconciliación (Mejores prácticas) .......................................................................... 78
3.2.6 Etapa VI – Consulta en términos de requerimientos ................................................................. 80
CAPÍTULO 4. CASO: INDICADORES DE PLANTA ACADÉMICA PARA EL RANKING QS. ................ 81
4.1 PRESENCIA DEL TECNOLÓGICO DE MONTERREY EN RANKINGS INTERNACIONALES .... 82
4.2 DEFINICIONES DE RANKINGS PARA PLANTA ACADÉMICA ..................................................... 84
4.3 METODOLOGÍA ACTUAL ................................................................................................................... 85
IX
4.4 APLICACIÓN DE METODOLOGÍA A&H .......................................................................................... 87
4.4.1 Requerimientos del usuario mediante un esquema global ........................................................ 89
4.4.2 Selección de fuentes de datos ................................................................................................... 93
4.4.3 Preparación de datos ................................................................................................................. 94
4.4.4 Construcción de ontologías locales .......................................................................................... 94
4.4.5 Integración (Alineación de las ontologías) ............................................................................... 96
4.4.6 Reconciliación ........................................................................................................................ 101
4.4.7 Consultas en términos de requerimiento ................................................................................. 103
4.5 GUIA DEL INSTRUMENTO ............................................................................................................... 106
4.6 RESULTADOS ..................................................................................................................................... 107
CAPÍTULO 5. DISCUSIÓN ............................................................................................................................ 115
5.1 COMPARACIÓN CON TRABAJOS RELEVANTES ......................................................................... 115
CAPÍTULO 6 - CONCLUSIONES .................................................................................................................. 118
6.1 TRABAJO FUTURO ............................................................................................................................ 120
ANEXO A – Ejemplos de consultas en lenguaje sparql ................................................................................... 122
ANEXO B – Ejemplos de funciones de agregación ......................................................................................... 124
ANEXO C – Importando una ontología global (swrc) a topbraid composer .................................................... 125
ANEXO D – Importando excel a topbraid composer ....................................................................................... 126
ANEXO E – Importando ontologia global en la ontologia local ...................................................................... 127
ANEXO F – Insercion de una nueva clase ....................................................................................................... 128
ANEXO G – Estructuras de tablas fuente ......................................................................................................... 129
ANEXO H – Instrumento para la aplicación de la metodologia a&h para no-ontologistas .............................. 131
REFERENCIAS ............................................................................................................................................... 145
VITA ................................................................................................................................................................. 150
X
LISTA DE TABLAS
Tabla 1.1 Descripción de las capas de la Arquitectura de la Web Semántica (Codina&
Rovira, 2006) ........................................................................................................................ 27
Tabla 1.2 Lenguajes Ontológicos ........................................................................................ 40
Tabla 1.3 Constructores OWL ............................................................................................. 42
Tabla 1.4 Razonadores ........................................................................................................ 46
Tabla 3.1 Etapas de la integración de las metodologías ...................................................... 59
Tabla 3.2 Constructores OWL para la Preparación de Datos ............................................. 76
Tabla 3.3 Constructores para la Integración ......................................................................... 77
Tabla 3.4 Constructores OWL para la Reconciliación ........................................................ 79
Tabla 4.1 Clasificación de la Planta Académica ................................................................. 91
Tabla 4.2 Clasificación de la planta académica del Tecnológico de Monterrey ................. 97
Tabla 4.3 Equivalencia de Clases ...................................................................................... 100
Tabla 4.4 Equivalencias entre propiedades ....................................................................... 102
Tabla 4.5 Tabla de Consultas sobre el modelo inferido .................................................... 104
Tabla 4.6 Comparación de resultados entre metodologías ................................................ 108
Tabla 4.7 Tiempos de consulta y razonamiento ................................................................ 111
Tabla 4.8 Características de los ordenadores .................................................................... 111
XI
LISTA DE FIGURAS
Figura 1.1 Arquitectura de la Web Semántica (Berners-Lee, 2008) .................................... 27
Figura 1.2 Temas principales de la ingeniería ontológica(Deved, 2002). ............................ 32
Figura 1.3 Clasificación de estrategias para el manejo de conflictos ................................... 38
Figura 1.4 Arquitectura de MOMIS ..................................................................................... 52
Figura 1.5 Arquitectura de SIMS (Pirrone et al., 2008). ...................................................... 56
Figura 3.1 Proceso de Integración MOMIS (Domenico Beneventano & Bergamaschi, 2004)
.............................................................................................................................................. 62
Figura 3.2 Coeficientes de Afinidad (Domenico Beneventano & Bergamaschi, 2004) ....... 64
Figura 3.3 Proceso de Integración SIMS (Arens et al., 1996) .............................................. 65
Figura 3.4 Representación de una ontología mediadora ....................................................... 68
Figura 3.5 Visión General de MIRSOFT ............................................................................. 70
Figura 3.6 Esquema General de A&H ................................................................................. 72
Figura 3.7 Proceso de Integración de A&H .......................................................................... 73
Figura 4.1 Proceso de integración y reconciliación de la metodología actual ...................... 86
Figura 4.2 Etapas de la metodología propuesta .................................................................... 88
Figura 4.3 Proceso de Integración y Reconciliación ........................................................... 89
Figura 4.4 Jerarquía de Clases en SWRC ............................................................................. 90
Figura 4.5 Clasificación Planta Académica .......................................................................... 91
XII
Figura 4.6 Adecuación de la Ontología Global (swrc) ......................................................... 91
Figura 4.7 Clase y Subclases creadas ................................................................................... 92
Figura 4.8 Definiciones (Mexican e International) .............................................................. 95
Figura 4.9 Definición FullTime ............................................................................................ 98
Figura 4.10 Definición PartTime ......................................................................................... 99
Figura 4.11 Definición International ................................................................................... 99
Figura 4.12 Definición PhD ............................................................................................... 100
13
1 CAPÍTULO 1. INTRODUCCIÓN
En 1970, el Modelo Relacional revolucionó el campo de las Bases de Datos, debido
al logro de la separación de la representación lógica del dato y de la implementación
física. Dicho logro, produjo posteriormente, el desarrollo de lenguajes de consultas
(Juárez Shiguihara, 2009). En el Modelo Semántico, lo adecuado sería que los sistemas
pudieran utilizar las características de su entorno de modo que pudiesen responder de
una manera un poco más inteligente a las interacciones del usuario y soportar interfaces
de usuarios más sofisticadas (Date, 2001).
Uno de los principales problemas que se enfrenta durante el proceso de integración,
en su mayoría, es el de combinar los datos que residen en fuentes diferentes, y
proporcionar al usuario una vista unificada de los datos (Lenzerini, Sapienza, Salaria, &
Roma, 2002). De esta forma, la reconciliación de datos permite conocer, por ejemplo,
cuando los datos sobre la representación de dos individuos diferentes, se atribuyen a un
mismo individuo.
Las ontologías son particularmente idóneas para la tarea de integración de datos. Su
trabajo consiste en cubrir los huecos semánticos y sintácticos existentes entre las
distintas fuentes de datos (Silvescu, Reinoso-castillo, & Honavar, 1997).
14
1.1 ANTECEDENTES
Debido a la tasa de crecimiento de información, se ha buscado resolver problemas
para su integración. Aunado con la evolución del Internet, nuevos desafíos han surgido
como: Gran escala: integración información de un gran número de fuentes participantes;
Dinamismo: integrar información cuando los datos están en un ambiente continuo;
Inconsistencia: detectar y resolver inconsistencias entre diferentes fuentes de
información; y automatización (Motro, Berlin, & Anokhin, 2004).
Para proveer una solución para este tipo de problemas, se ha recurrido al uso de
tecnología semántica. Existen metodologías para la integración de información, y
algunas otras, además, resuelven problemas de reconciliación de datos. La reconciliación
de datos consiste, principalmente, en decidir si dos identificadores se refieren a la
misma instancia o individuo (Bakhtouchi, Bellatreche, Jean, & Ameur, 2012).
Las ontologías comienzan a utilizarse a finales de los 80 en el campo de la
inteligencia artificial como medio para la compartición y reúso de conocimiento. En la
segunda mitad de los 90 se empiezan a aplicar a la web para la inclusión de
descripciones semánticas explícitas de recursos (contenidos y servicios). Hoy son un eje
fundamental en las nuevas tecnologías para la web semántica (Benito, Cárdenas, &
Chávez, 2005).
15
1.2 MOTIVACIÓN
La integración de fuentes heterogéneas es un problema muy conocido. Se tiene como
entradas un conjunto de fuentes distribuidas, heterogéneas, autónomas, donde cada una
tiene su propio esquema y población. Además, la integración de fuentes heterogéneas
produce como salida una descripción unificada a través de un esquema integrado que se
puede utilizar para acceder a fuentes de datos. Este problema plantea dos cuestiones
difíciles: la heterogeneidad de las fuentes y reconciliación de datos. La heterogeneidad
de las fuentes debe ser manejada para asegurar una integración automática de los datos
(Bakhtouchi, Bellatreche, Jean, & Ait-ameur, 2011). Por medio de la investigación de la
literatura actual y el diseño de una metodología se pretende atacar a estos dos problemas
principales que residen en el ámbito de la administración de la información.
La información se ha convertido en uno de los activos primordiales para la
continuidad de la operación en las empresas. Mantener esa información integrada desde
distintas fuentes se ha convertido en una de las tareas más importantes para los gestores
de la información. Aunado a esto, las fuentes de datos, en muchas ocasiones no
coinciden semánticamente, es decir, carecen de un entendimiento común o aún más
crítico, carecen de semántica cada una de las fuentes, estos problemas dificultan aún más
la integración, utilidad compartida e interoperabilidad semántica.
16
1.3 OBJETIVOS
El objetivo principal de esta investigación es implementar una metodología para la
integración y reconciliación de información mediante el uso de tecnología semántica.
Los objetivos específicos son:
Integrar información de fuentes de datos heterogéneas y semi-
estructuradas.
Analizar herramientas que apoyen a la integración de información.
Analizar metodologías actuales de integración de datos por medio de
ontologías.
Proponer una nueva metodología de integración que se sustenta en las
tecnologías disponibles actualmente.
Detectar las limitaciones de estas tecnologías para el propósito de
integración de información.
Validar la metodología para un usuario no-Ontologista.
17
1.4 PREGUNTA DE INVESTIGACIÓN
¿De qué manera la modelación semántica por medio de ontologías nos permite llevar
un control más ordenado y ágil de diversas peticiones de información?
18
1.5 JUSTIFICACIÓN
1.5.1 CONTEXTO
En tecnologías de información, las ontologías pueden definir los términos y
conceptos comunes (el significado) que se usan para describir y representar un área del
conocimiento. Esto consiste en un vocabulario específico utilizado para describir una
parte de la realidad (dominio) además de un conjunto de supuestos explícitos sobre un
concepto. Puede entenderse también como una estructura lógica de términos usados para
describir un dominio de conocimiento, incluyendo la definición y la relación entre los
términos.
Cuando una universidad, tal como el Tecnológico de Monterrey, participa en un
ranking de universidades debe proporcionar estadísticas de distinta índole. Para obtener
dichas estadísticas se debe recopilar e integrar información de distintos departamentos y
adecuarlos a las definiciones que manejan los organismos acreditadores o rankings.
Por tal motivo, es importante tomar contexto de la integración de información para
el Tecnológico de Monterrey en su participación en los rankings. Esto, debido a la
problemática que enfrenta y las necesidades presentadas en la integración de
información están completamente alineadas con los objetivos de la Metodología
resultante de la presente investigación.
19
1.5.2 FORMA EN QUE SE MANIFIESTA EL PROBLEMA
En el caso del Tecnológico de Monterrey, las peticiones de información para el
acceso a las fuentes de datos e información requieren un proceso largo, tedioso y
repetitivo. El proceso para obtener la información que responde a dichas peticiones es
manual y sujeto a fallas producto de:
La distribución de información se encuentra en varios departamentos y cada
uno de ellos lleva un control distinto sobre ella.
La consecuente descomposición en solicitudes a diferentes áreas y la posterior
integración de la información obtenida
El modelo de información que tiene cada departamento es distinto y las
solicitudes de información deben elaborarse en términos que ellos entiendan
Las preguntas y los criterios de las peticiones cambian con el tiempo. Por
ejemplo, rankings como THE (Times Higher Education) y QS Rankings,
cambian cada año el número de preguntas e incluso algunos criterios de cálculo
La recepción de nuevas peticiones cada año, las cuales puede ser respondidas o
no con la información que ya se cuenta. Sin embargo, para saber si son
equivalentes a las que ya se han respondido hay que revisar las definiciones de
todas las peticiones previas
El riesgo de errores durante la reorganización de la información debido a que
dicho procesamiento es realizado en Microsoft Excel con fórmulas que
dependen de la estructura de la información.
El cambio organizacional constante presente en el Tecnológico de Monterrey,
lo cual tiene como consecuencia que los criterios utilizados para generar la
20
información cambien de la misma manera. Por ejemplo, al reorganizar a los
profesores en Departamentos en lugar de Centros de Investigación se tuvo que
ajustar el criterio de Personal destinado a la investigación que se reporta a la
SEP.
Este tipo de problemas es enfrentado también por usuarios que requieran responder
peticiones de información diversas a partir de la integración de información de múltiples
fuentes.
21
1.6 ALCANCE DE LA INVESTIGACIÓN
En esta investigación se analizarán las metodologías de integración de datos basadas
en ontologías y se explorarán las capacidades de las herramientas semánticas actuales
para realizar dicho proceso.
Se tomará como caso de estudio la integración de información de profesores para
responder al ranking de universidades QS y se comparará con la metodología
actualmente implementada.
1.7 ORGANIZACIÓN DE LA TESIS
La presente investigación cuenta con siete capítulos y a continuación se describe de
manera breve el contenido de cada uno de estos.
En el capítulo uno, se da una introducción, se plantean los objetivos y los alcances
de la investigación, así como el problema y la motivación para llevarla a cabo.
En el capítulo dos, se desarrollan los conceptos y conocimientos de los temas que
sustentan esta investigación.
De acuerdo a la revisión de la literatura actual existen algunas metodologías para la
integración de información con un enfoque semántico, en el capítulo tres se muestran
algunas de esas metodologías. Además se desarrolla la metodología propuesta A&H, la
cual es el objetivo principal de la investigación de esta tesis, se detallan las etapas que la
conforman.
22
En el capítulo cuatro se analiza un caso de estudio, el cual tiene como objetivo
aplicar y validar la metodología A&H que se propone en el capítulo tres, así como
también se muestra los resultados y un análisis comparativo de la metodología actual
con la metodología propuesta A&H. De la misma manera se presenta el instrumento
diseñado para validar el uso de la metodología por un usuario no-Onotlogista, asi mismo
los resultados obtenidos de dicha validación.
En el capítulo cinco se describe un análisis comparativo con los trabajos más
relevantes en el campo de esta investigación.
Por último en el capítulo seis se muestran las conclusiones generales de esta
investigación, así como también se describe el trabajo futuro que puede surgir a partir de
la actual investigación.
23
1 CAPÍTULO 2. MARCO TEÓRICO
En este capítulo se abordarán los temas más relevantes con la finalidad de dar un
sustento al resultado de esta investigación. Primeramente, en la sección 2.1 se presentan
los conceptos básicos de la modelación semántica. En la sección 2.2 se describen tres
elementos importantes de la web semántica, que son: ontologías, generación ontológica
y evolución ontológica. En la sección 2.3 se presenta el tema de integración de datos, el
cual forma parte esencial de esta investigación. En la sección 2.4 se detallan los
elementos importantes del proceso KDD (Knowledge Descovery Databases). En la
sección 2.5 la integración semántica de datos, en la cual el uso de las ontologías tiene
una contribución significativa. En la sección 2.6 se describe lo que es la reconciliación
en los datos y los esquemas, así como el tratamiento de fusión en los datos. En la sección
2.7 se describen los lenguajes semánticos, así como tecnologías que la apoyan. En la
sección 2.8 se habla de algunas herramientas que apoyan al razonamiento de las
ontologías, así como una comparación entre estas. En la sección 2.9 se presenta una
breve descripción de lo que es el lenguaje de consultas SPARQL, así como algunas
funciones significativas de este. En la sección 2.10 se da una reseña de las metodologías
de integración de información mediante el uso de tecnología semántica.
2.1 MODELACIÓN SEMÁNTICA
El modelado semántico ha sido tema de investigación desde finales de los años
setenta. La razón principal de estudio es: por lo regular las bases de datos sólo tienen una
comprensión muy delimitada de lo que significa la información de dichas bases de datos.
24
Por lo general, las bases de datos solo deducen o razonan ciertos valores de datos, y
quizás ciertas restricciones simples que se aplican a dichos valores.
Captar el significado de los datos es una tarea que no termina nunca, y esperamos
ver desarrollos continuos en esta área conforme a nuestro entendimiento sigue
evolucionando. Por lo tanto, el término modelado semántico es conocido por muchos
nombres, incluyendo modelado de datos, modelado de entidad, modelado de entidades y
modelado de objetos (Date, 2001).
Algunos componentes principales de los modelos semánticos son: la representación
explicita de los objetos, sus atributos o propiedades y las relaciones entre ellos, tipos de
datos, relaciones IS-A y otros componentes derivados del esquema (Hull & King, 1987).
Los modelos semánticos ayudan a las personas que administran información en tres
formas fundamentales:
1. La comunicación entre la gente. Un modelo describe la situación de manera
concreta para que otras personas lo entiendan.
2. Para explicar y hacer predicciones. Un modelo relaciona los fenómenos
primitivos y a los fenómenos más complejos, proporcionando explicaciones y
predicciones acerca del mundo o a eventos en particular.
3. Para mediar entre múltiples puntos de vista. Pueden existir dos personas que
no estén de acuerdo completamente en lo que quieren saber acerca de un
fenómeno; los modelos pueden representar los puntos de vista en común que
les permitirá explorar algunas diferencias (Allemang & Hendler, 2008).
Uno de los aspectos más importantes en el diseño de un conjunto de datos en los
sistemas de integración, es la especificación de la correspondencia entre los datos de las
25
fuentes y los datos del esquema global. Esta correspondencia podrá ser modelada a
través de un mapeo. Es así como dicha correspondencia va a determinar cómo las
consultas al sistema serán contestadas (Lenzerini et al., 2002).
2.2 WEB SEMÁNTICA
La World Wide Web ha sido el resultado de una nueva y radical manera de
pensamiento acerca de compartir información. Estas ideas pueden parecer tan familiares
en la actualidad, así como la propia web se ha convertido en un fenómeno y cada vez
más se está fortaleciendo (Allemang & Hendler, 2008). La web ha tenido la capacidad
de construir una base de conocimiento gracias a sus usuarios y a través de una
comunicación entre su capacidad de conocimiento y la información que ha estado
disponible en internet es y será capaz de responder a las necesidades o demandas de
información por parte de los usuarios.
La web ha sido dotada de más significado, y gracias a la existencia de la semántica
se pueden obtener soluciones a problemas habituales en la búsqueda de información,
además a la utilización de una infraestructura común mediante la cual es posible
compartir, procesar y transferir información de manera sencilla.
Tim Berners-Lee sugiere que la Web Semántica no es un concepto totalmente
nuevo, pero sí una tecnología que expande la red existente para permitir a las máquinas
entender también su contenido hasta cierto punto. World Wide Web Committee (W3C)
define que la Web Semántica es "datos en la World Wide Web escritas en abstracto en
una forma estándar".
26
Como último objetivo de la investigación sobre la Web semántica ha sido
desarrollar un estándar o una tecnología que pueda apoyar a las computadoras en la
comprensión de la información en la web con la finalidad de alcanzar la automatización
de las operaciones, tales como la recolección de datos, la búsqueda semántica y
exploración. Para ser más precisos, la investigación sobre la web semántica pretende
cumplir con los siguientes objetivos:
Brindar a los usuarios resultados más precisos en sus búsquedas
Combinar y comparar información de varias fuentes
Estandarizar los diversos recursos con información sobre los significados
Publicar información precisa sobre la web para el servicio web automático
El primer intento de dar un plan de alto nivel de la arquitectura de la Web
Semántica fue realizado por Tim Berners-Lee (2008).
Según Berners-Lee, la Web Semántica será construida mediante la suma de más
capas en la parte superior de las que ya existen en la arquitectura actual y se considera
que puede tomar alrededor de 10 años en completarse (2008). Basado en el diagrama
"Layer Cake" presentado por Tim Berners-Lee en la Conferencia XML 2000, la mayoría
de las tecnologías actuales de Web Semántica pertenecen a la familia XML y casi podría
asegurarse que todos los cambios futuros serán basados en XML.
XML1 es un lenguaje markup que define un conjunto de reglas para la codificación
de documentos en un formato legible. XML es la base de la nueva generación de la
Web.
1 por sus siglas en inglés Extensible Markup Language
http://en.wikipedia.org/wiki/XML
27
La figura 2.1 muestra la arquitectura de la Web Semántica:
Figura 1.1 Arquitectura de la Web Semántica (Berners-Lee, 2008)
El artículo original de la revista Scientific American en el 2001 describe la
evolución de la Web Semántica, así como también define a la web Semántica como
―acciones concretas de información derivadas de los datos a través de una teoría
semántica para interpretar los símbolos‖. Esta teoría semántica se da cuenta de
―significados‖ en la que la conexión lógica de los términos se establece la
interoperabilidad entre los sistemas (Shadbolt & Hall 2006).
En la tabla 2.1 se muestra con más detalle el significado de las capas de la
Arquitectura Web Semántica.
Tabla 1.1 Descripción de las capas de la Arquitectura de la Web Semántica
(Codina& Rovira, 2006)
1 Unicode + URI Unicode es un sistema estándar que proporciona un
número único para cada caracter, sin importar la
28
plataforma ni el programa. Esto permite representar
caracteres de cualquier idioma con una codificación
unificada. Uniform Resource Identifier (URI) es un
sistema de direccionamiento e identificación de recursos.
El sistema que es usado actualmente para acceder a los
recursos de la Web (URL) es una parte de URI.
2 XML+NS+XML
SCHEMA
eXtended Markup Language (XML) es un sistema que
permite definir lenguajes de marcado para usos
específicos. Name Spaces (NS) permite combinar diversos
lenguajes de marcado creados con XML en un mismo
documento. XML Schema sirve para definir tipos de
documentos complejos en los que se pueden especificar
tipos de datos, listas de componentes y restricciones
similares a las del diccionario de datos típico de una base
de datos.
3 RDF + rdfschema Resource Description Framework (RDF) es un modelo de
representación de metadatos que, entre otras cosas,
permite representar recursos digitales tales como sitios o
páginas web. RDF está concebido para representar
cualquier clase de recursos (no solamente páginas
publicadas en la web).
RDF Schema, por su parte, es una extensión de RDF que
aporta un lenguaje con mayor capacidad para representar
relaciones semánticas complejas.
4 Ontology
vocabulary
Una ontología es una especificación formal de un dominio
del conocimiento que, en su expresión más simple, se
identifica con una taxonomía. Una taxonomía consiste en
una jerarquía de conceptos y sus relaciones del tipo clase-
subclase. Una ontología formaliza la relación de clase,
añade otras relaciones y especifica propiedades para
29
individuos y clases. Ontology-vocabulary se refiere a una
ontología concreta sobre un dominio concreto del
conocimiento.
5 Logic En este contexto, logic se refiere al estudio de las reglas
formales que permiten determinar si un razonamiento se
sigue de sus premisas. La lógica estudia, por tanto, la
estructura de los razonamientos válidos. Se espera que los
ordenadores del futuro puedan efectuar razonamientos
sobre los recursos y servicios de la Web combinando los
conocimientos expresados en las ontologías, los hechos
declarados en los metadatos y la aplicación de reglas
lógicas.
6 Proof En este contexto, Proof (prueba) significa demostración
[matemática]. Se considera que un ordenador alcanza la
máxima fiabilidad en sus razonamientos cuando es capaz
de realizar demostraciones o, lo que es lo mismo a efectos
prácticos, cuando es capaz de justificar el motivo por el
cual tomó (o aconsejó tomar) una decisión.
7 Trust (+ Digital
Signature)
La última capa, Trust (confianza) debe servir para otorgar
confianza a las transacciones en la Web a través que se
llevarán a cabo no solamente entre usuarios y sitios web
sino también entre programas de software; y todo ello
tanto en el plano C2B (consumer to business) como en el
B2B (business to business). La Digital Signature (firma
digital) proporcionará
soporte específico a esta capa.
En la web semántica es necesario que el conocimiento esté representado de
forma que sea legible por los ordenadores o computadoras, que estén en mutuo acuerdo,
30
y además que sea reutilizable. Las ontologías proporcionan la vía para representar este
conocimiento. El éxito de la Web semántica, según sus impulsores, se materializará en
parte por la disposición a compartir ontologías que muestren comunidades y grupos en la
web (Vel, Vel, Guzm, & Santander, 2011).
¿Cómo puede la infraestructura de la Web apoyar el desarrollo de este estado
caótico a uno caracterizado por el intercambio de información, la cooperación y la
colaboración? La respuesta a esta pregunta se encuentra en el modelado. Modelado es el
proceso de organizar la información para uso comunitario (Allemang & Hendler, 2008).
2.2.1 Ontologías
Una conceptualización es un cuerpo de conocimiento que puede ser representado
formalmente, los cuales se basan en: los objetos, conceptos y otras entidades que se
supone existe en algún área de interés y las relaciones que ellos tienen. Una
conceptualización, podría decirse también que es una vista simplificada y abstracta del
mundo que queremos representar con algún propósito.
Entonces, puede decirse que una ontología es una especificación explícita de una
conceptualización. El término está tomado de la filosofía, donde una ontología es una
explicación sistemática de la Existencia. Para los sistemas basados en el conocimiento,
lo que "existe" es exactamente lo que se puede representar (Gruber, 1993).
Originalmente, el término provenía de la Filosofía clásica. En ese contexto, la ontología
era una parte de la metafísica que se ocupaba de estudiar la naturaleza de la existencia
(Codina & Rovira, 2006).
En una ontología, la unidad fundamental para la especificación son los conceptos.
Cada concepto consta de tres componentes básicos, los cuales son:
31
Términos: nombre utilizado para referirse a un concepto
Atributos: características de un concepto y relaciones:
Enlaces: los cuales son los que representan correspondencias entre los distintos
conceptos, las relaciones son las que proveen una estructura general a la
ontología.
2.2.2 Generación de Ontologías (Ontology Engineering)
Las ontologías están siendo usadas en el ámbito de la ingeniería del conocimiento,
la inteligencia artificial y en las ciencias computacionales, en aplicaciones relacionadas
en la administración del conocimiento, procesamiento natural del lenguaje, comercio
electrónico, integración de información inteligente, recuperación de información, diseño
e integración de bases de datos, bioinformática, educación y nuevos campos que han
surgido como la Web Semántica (Gómez-Pérez, Fernández-López, & Corcho, 2004).
Así pues, la ingeniería ontológica representa un conjunto de actividades referentes
al proceso de la creación de una ontología, su ciclo de vida, así como también las
metodologías, herramientas y lenguajes necesarios para la construcción de dichas
ontologías.
Cada ontología es un sistema que está conformado de conceptos y las relaciones
entre ellos, en el que todos los conceptos están definidos e interpretados de una manera
declarativa o explicita. El sistema define el vocabulario de un dominio y un conjunto de
restricciones sobre cómo los términos se pueden combinar para modelar el dominio.
Entonces, la Ingeniería Ontológica engloba un conjunto de actividades llevadas a cabo
32
durante la conceptualización, el diseño, la implementación y el despliegue de las
ontologías. Algunos factores importantes en este dominio se muestran en la figura 2.2.
Figura 1.2 Temas principales de la ingeniería ontológica(Deved, 2002).
La finalidad de la ingeniería ontológica es proporcionar una base de la construcción
de modelos de todas las cosas en las que la informática está interesado (Mizoguchi &
Ikeda, n.d.).
2.2.3 Evolución ontológica (Ontology Evolution)
La evolución ontológica es la adaptación oportuna de una ontología a los cambios
planteados y de la propagación consistente de estos cambios en los artefactos
dependientes, ya que si existe un cambio en la ontología esto puede causar
incoherencias en otras partes de la misma ontología. La evolución ontológica tiene que
ser considerado como un proceso el cual comprende un conjunto de actividades, tanto
técnicos como de administración, para asegurar que la ontología siga cumpliendo los
33
objetivos de la organización y las necesidades de los usuarios de manera eficiente y
eficaz (Erlangung et al., 2004).
No es un proceso insignificante o trivial, debido a la existencia de diversas fuentes
y además considerando las consecuencias de los cambios, que por lo tanto no puede ser
formado manualmente por la engineering ontology ya que pueden llegar a convertirse en
la aplicación de esfuerzos muy costosos. De esta manera, el proceso debe ser apoyado
por un sistema de administración de ontologías. Un aspecto importante en el proceso de
la evolución, para garantizar la consistencia de la ontología cuando se producen
cambios, es tener en cuenta los cambios semánticos que va a sufrir la ontología. En la
formalización de la semántica, un cambio exige una definición del modelo de ontología
junto con sus operaciones de cambio, las condiciones de consistencia y reglas para hacer
cumplir estas condiciones (Haase & Stojanovic, n.d.).
2.3 INTEGRACIÓN DE DATOS
Lenzerini (2002) dice que la integración de datos es el problema de combinar los
datos que residen en fuentes diferentes, y proporcionar al usuario una vista unificada de
los datos. El problema del diseño de sistemas de integración de datos es importante en
las actuales aplicaciones del mundo real, y se caracteriza por una serie de cuestiones que
son interesantes desde un punto de vista teórico.
Para atacar a estos problemas durante la integración de datos una de las soluciones
propuestas es el uso de las ontologías. Silvescu y Wache mencionan que las ontologías
son particularmente idóneas para la tarea de integración, consistente en cubrir los huecos
semánticos y sintácticos existentes entre las distintas fuentes de datos (2001). Para tener
34
una versión unificada de información, es necesario hacer coincidir las fuentes de datos
(Kedad & Métais, 2002).
En una primera clasificación (Perez del Rey, 2007), se pueden diferenciar dos tipos
de integración:
Integración Vertical. Donde se unifica información semánticamente
similar y proveniente de distintas fuentes.
Integración Horizontal. En la que se agrega información adicional o
complementaria a una determinada fuente.
El mayor problema se debe a que la misma información puede ser representada de
diversas formas (Cespivova, Tomeckova, Rauch, & Kejkula, 2004). Existen conflictos
más complejos de resolver en lo referente a la representación de la información (Perez
del Rey, 2007), los cuales se pueden clasificar en:
Conflictos estructurales: Aquellos referentes al esquema o estructura de la
base de datos.
Conflictos de nombre: La utilización de distintos sinónimos para un
mismo concepto.
Conflictos semánticos: Este tipo de conflictos se dan cuando los valores
en la base de datos son similares pero no exactamente equivalentes.
Conflictos de contenido: Se producen cuando al integrar distintas fuentes,
parte de la información de alguna de ellas no está representada.
Antes de analizar los problemas de las bases de datos que se deseen integrar, se ha
de abordar la localización dispersa de las fuentes y su política de acceso y actualización
(Perez del Rey, 2007).
35
Los conflictos en los datos se pueden resolver de muchas maneras. En la sección
2.8.2 se muestran algunas estrategias para enfrentarlos (Park & Naumann, 2009).
Es por eso que debido a esta problemática se propone una metodología que permita
la integración de información y reconciliación mediante el uso de ontologías y
tecnología semántica.
2.4 EL PROCESO KDD
El proceso KDD (Knowledge Discovery in Database) se define como el proceso de
descubrimiento de conocimiento no trivial y potencialmente útil (Weiss e Indurkhya,
1998). Está compuesto de varias etapas y puede ser aplicado a la verificación de
hipótesis de usuario o al descubrimiento automático de patrones (Rodríguez Mancha,
2011). Una metodología KDD (Fayyad, Piatetsky-shapiro, & Smyth, 1996) contempla
los siguientes objetivos a lo largo del proceso:
1. Entendimiento del dominio y las metas,
2. creación del conjunto de datos,
3. pre procesamiento de los datos,
4. reducción y proyección de los datos,
5. minería de datos, e
6. interpretación de los resultados.
En resumen, el KDD está compuesto por los pasos: selección de datos (los datos
relevantes para el análisis se extraen de la base de datos), el pre procesamiento de los
datos (limpiar y preparar los datos), data mining (construir modelos descriptivos
/predictivos) y evaluación del modelo, es decir, conseguir los modelos
descriptivos/predictivos que mejor solucionen el problema (Balears & Pol, 2009).
36
Las ontologías pueden ser útiles en todas las fases del KDD (Cespivova et al.,
2004). Considerando las fases previas a la minería de datos, el objetivo de introducir
ontologías en este proceso es mejorar la calidad de los datos mediante la utilización de
un soporte formal de conocimiento. Según sea la tarea, distintos tipos de ontologías
pueden facilitar la comprensión y dar soporte para una resolución óptima de las mismas
(Perez del Rey, 2007).
2.5 INTEGRACIÓN SEMÁNTICA DE DATOS
El uso de las ontologías en el ámbito de la integración de datos podría tener una
contribución significativa (Silvescu et al., 1997).
Las ontologías han ganado popularidad en la comunidad de la Inteligencia Artificial
como un medio para establecer vocabulario formal/explícito para compartir entre varias
aplicaciones. Así pues, se puede decir que uno de los objetivos de la utilización de
ontologías es evitar problemas de heterogeneidad entre los datos y sus fuentes (F. Noy,
2004).
Uno de los estudios más importantes en los problemas de la integración semántica
es el establecimiento de correspondencias semánticas (también llamado mappings) entre
vocabularios de diferentes fuentes de datos (Noy, Doan, & Halevy, 2005).
2.6 RECONCILIACIÓN
La reconciliación de datos se produce en dos niveles: nivel de correspondencia
esquema e instancia. El nivel de esquema tiene como objetivo establecer correlaciones
semánticas entre los contenidos de las fuentes de información. Es decir, en este proceso
se identifican las tablas o entidades XML que representan el mismo mundo real de
37
entidad e identifica los atributos que describen la misma propiedad para el mismo tipo
de entidad. El objetivo del nivel instancia es establecer la reconciliación entre las
instancias que representan la misma entidad en el mundo real para producir el valor
correcto en dicha entidad. Existen dos métodos a nivel instancia: método de
reconciliación y métodos de fusión (Bakhtouchi, Jean, & Ait-ameur, 2011).
2.6.1 Reconciliación de Entidades
La reconciliación de entidades también es conocida como coincidencia en entidades,
identificación duplicado, vinculación de registros o la resolución de la entidad. La
reconciliación de datos, de igual manera, es una tarea crítica para la integración y la
limpieza de los datos, tiene como objetivo resolver la heterogeneidad a nivel de instancia
mediante la identificación de entidades (objetos o instancias) que se refieren a la misma
entidad del mundo real y estén representados de forma distinta. Por ejemplo, dados dos
conjuntos de entidades A ∈ SA y B ∈ SB de una entidad semántica particular donde el
tipo de fuentes de datos es SA y SB. El problema de la reconciliación de datos consiste
en identificar todas las correspondencias entre las entidades A x B que estén
representando el mismo objeto del mundo real. Esta definición incluye el caso especial
de encontrar pares de entidades equivalentes dentro de una única fuente A = B, SA = SB
(Bakhtouchi, Jean, et al., 2011). Los diversos enfoques de la reconciliación de entidad se
pueden clasificar en dos categorías: el enfoque basado en reglas y el enfoque basado en
aprendizaje (Zhao y Ram, 2008). En el enfoque basado en reglas, los especialistas en el
dominio deben proporcionar directamente las reglas de decisión para hacer coincidir
semánticamente los registros. En el enfoque basados en aprendizaje los especialistas en
el dominio están obligados a proporcionar igualdad (y no igualdad) de los registros,
38
basado en técnicas de clasificación que se utilizan para aprender las reglas de
reconciliación de datos (Bakhtouchi, Jean, et al., 2011).
2.6.2 Fusión de datos
El objetivo de la etapa de fusión de datos es combinar los registros que se refieren a
la misma entidad u objeto del mundo real para unirla en una sola representación y así
resolver los posibles conflictos que puedan existir en fuentes de datos distintas. Fusión
de datos tiene por objetivo resolver dichos conflictos en los datos y aumentar la
exactitud de los mismos. Existen algunas estrategias para resolver esos conflictos, los
cuales han sido adoptados por diferentes sistemas de integración (Bakhtouchi, Jean, et
al., 2011).
Algunas de esas estrategias se muestran en la figura 2.3.
Figura 1.3 Clasificación de estrategias para el manejo de conflictos
Las técnicas de la fusión de datos se pueden aplicar en dos fases distintas del ciclo
de vida de un sistema de integración de datos, es decir, en tiempo de diseño y en tiempo
de consulta (Batini & Scannapieca, 2006). En ambos casos, se decide cual será la
39
estrategia a seguir para la resolución de conflictos antes de que las consultas sean
procesadas (Bakhtouchi, Jean, et al., 2011).
2.7 LENGUAJES ONTOLÓGICOS
Las ontologías reúnen conocimiento de un modo general y más que nada formal, de
tal manera que pueda ser compartido y reutilizado por distintos grupos de personas y
aplicaciones de software. En este sentido, las ontologías conforman uno de los pilares
básicos de las aplicaciones actuales y de la Web Semántica y requieren de un lenguaje
lógico y formal para ser expresadas. En el área de la inteligencia artificial, se han
desarrollado numerosos lenguajes para este fin, algunos basados en la lógica de
predicados, otros basados en frames (taxonomías de clases y atributos) y otros
orientados al razonamiento. Con los lenguajes ontológicos se pretende alcanzar un alto
grado de expresividad y uso. Dentro de los principales lenguajes destacan: XML, XML
Schema, RDF, RDF Schema y OWL (Ramos, 2012). Para fines prácticos de esta
investigación se procederá a definir los lenguajes RDF, RDFS y OWL.
La tabla 2.2 muestra un resumen de los tres lenguajes ontológicos.
40
Tabla 1.2 Lenguajes Ontológicos
Lenguaje ¿Qué es? Principales Características
RDF
(Resource
Description
Framework)
Lenguaje de propósito
general para representar
información en la web.
o Provee un conjunto de declaraciones que
permiten describir clases y propiedades.
o No tiene capacidad para expresar la
semántica del vocabulario
RDFS Extensión semántica de
RDF
o Permite modelar metadatos con una
representación explícita de su semántica
o Permite especificar restricciones de tipos
de datos para los sujetos y objetos de las
tripletas de RDF, introduciendo unas
primitivas de modelado orientado a
objetos:
rdfs:Class, rdfs:Property,
rdfs:subClassOf
o Expresividad limitada. No soporta
conceptos ontológicos básicos como
equivalencia, disyunción, negación,
relaciones inversas y limitaciones de
cardinalidad.
OWL Lenguaje propuesto como
estándar por la W3C para
definir ontologías
o Especifica de manera precisa la semántica
formal de un ámbito determinado de la
realidad
o Hace posible el razonamiento con las
ontologías para inferir conocimiento
o Proporciona tres lenguajes (OWL Lite,
OWL DL y OWL Full)
41
2.7.1 RDF
RDF2 proporciona una manera sólida para representar los datos y así las múltiples
fuentes de datos puedan ser integradas y tratadas como si provinieran de únicamente una
fuente. Pero cuando queremos se quiere hacer uso de esos datos, las diferencias en las
fuentes de datos comienzan a surgir. El significado del lenguaje de modelado es
especificado por la inferencia. El significado está dado por el patrón de las inferencias
que se pueden extraer de ella. La integración de la información se logra mediante la
invocación de la inferencia antes o durante el proceso de consulta; una consulta devuelve
no sólo los datos afirmados, sino también la información que es inferida (Allemang &
Hendler, 2008).
2.7.2 RDFS
RDFS3 es el lenguaje de esquema RDF, describe las construcciones de tipos de
objetos (clases), en relación a otros tipos (subclases), propiedades que describen objetos
(propiedades), y las relaciones entre ellos (Subproperty). Los beneficios del lenguaje
RDFS es la naturaleza distribuida de RDF al ser expresados en RDF sí mismo. Toda la
información de esquema (clases, subclases, subpropiedades, dominio, rango, etc.) se
expresa en tripletas RDF (Allemang & Hendler, 2008).
2.7.3 OWL
Es el acrónimo del inglés Ontology Web Language, un lenguaje de marcas, utilizado
para publicar y compartir datos usando ontologías en la Web. OWL tiene como objetivo
2 por sus siglas en inglés Resource Description Framework
http://www.w3.org/RDF/ 3 por sus siglas en inglés Resource Description Framework Schema
http://www.w3.org/TR/rdf-schema/
42
facilitar un modelo construido sobre RDF y codificado en XML. Tiene como
antecedente a DAML+OIL, en el cual se inspiraron los diseñadores de OWL. Este
lenguaje, el entorno RDF y otros componentes, forman un conjunto de herramientas que
hacen posible el proyecto de la Web Semántica (Moreno Paredes, 2007).
OWL proporciona tres lenguajes, cada uno con nivel de expresividad mayor que el
anterior, diseñados para ser usados por comunidades específicas de desarrolladores y
usuarios. Los tres lenguajes OWL4 son: OWL Lite, OWL DL y OWL Full.
OWL Lite está diseñado para aquellos usuarios que necesitan principalmente una
clasificación jerárquica y restricciones simples suficientes para los usuarios que tan sólo
requieren de posibilidades para clasificar la jerarquía de conceptos (clases) de la
ontología y restricciones simples. Por ejemplo, a la vez que admite restricciones de
cardinalidad, sólo permite establecer valores cardinales de 0 ó 1.
OWL DL está diseñado para aquellos usuarios que quieren la máxima expresividad
conservando completitud computacional (se garantiza que todas las conclusiones sean
computables), y resolubilidad (todos los cálculos se resolverán en un tiempo finito).
OWL Full está dirigido a usuarios que quieren máxima expresividad y libertad
sintáctica de RDF sin garantías computacionales.
Los lenguajes ontológicos son interpretados por un razonador, el cual tiene como
objetivo clasificar o inferir información dado un esquema ontológico. A continuación se
muestra en la tabla 2.3 algunos constructores (o instrucciones) incluidos en cada uno de
los tipos de lenguajes.
Tabla 1.3 Constructores OWL
4 OWL Lite, OWL DL y OWL Full de la W3C Recommendation
43
VERSION OWL CARACTERISTICA CONSTRUCTOR
Class
rdfs:subClassOf
rdf:Property
rdfs:subPropertyOf
rdfs:domain
rdfs:range
individual
equivalentClass
equivalentProperty
sameAs
differentFrom
AllDifferent
distinctMembers
ObjectProperty
DatatypeProperty
inverseOf
TransitiveProperty
SymmetricProperty
FunctionalProperty
InverseFunctionalProperty
Restriction
onProperty
allValuesFrom
someValuesFrom
minCardinality (solo 0 or 1)
maxCardinality (solo 0 or 1)
cardinality (solo 0 or 1)
Intersección de clases intersectionOf
rdfs:label
rdfs:comment
rdfs:seeAlso
rdfs:isDefinedBy
AnnotationProperty
OntologyProperty
Tipos de datos xsd datatypes
oneOf, dataRange
disjointWith
equivalentClass
rdfs:subClassOf
unionOf
complementOf
intersectionOf
minCardinality
maxCardinality
cardinality
Asignacion de informaciónhasValue
Cardinalidad arbitraria
OWL Lite
OWL DL y OWL Full
Del esquema RDF
(Des)Igualdad
De propiedad
Restricciones de Propiedad
De cardinalidad restringida
Propiedades de Anotación
Axiomas de clase
Combinaciones booleanas
de expresiones de clase
44
2.8 RAZONADORES
Un razonador es un programa que infiere consecuencias lógicas de un conjunto de
hechos o axiomas afirmados explícitamente y por lo general proporciona soporte
automatizado para las tareas de razonamiento tales como la clasificación, depuración y
consulta (Cuenca, 2011).
Los razonadores funcionan en distintas herramientas o plataformas que permiten la
edición y/o creación de ontologías. Para fines de esta investigación se consideraron
algunos razonadores para seleccionar el más adecuado de acuerdo a las necesidades de
los beneficiarios. Algunos razonadores que trabajan bajo de plataforma Protege5 son:
Fact++ (Fast Classification of Terminologies) es de la nueva generación
de los razonadores hechos para OWL DL. Es compatible con un
subconjunto de OWL2 que es más expresivo. Está implantado en C++ y
está basado en algoritmos tableaux optimizados (Cuenca, 2011).
Hermit6, creado en la Universidad de Oxford, este razonador puede
determinar si una ontología es consistente e identifica relaciones de
subsunción entre conceptos. Hermit está basado en cálculos hipertableau.
Pellet7, fue el primer razonador que soportaba OWL DL y se ha extendido
a OWL2.
Para la plataforma de TopBraid Composer:
5 http://protege.stanford.edu/
6 http://hermit-reasoner.com/
7 http://clarkparsia.com/pellet/
45
SwiftOWLIM8, cubre varios formalismos de representación de
conocimiento, owl-max que contiene la mayor expresividad, owl-horst y
rdfs el cual soporta el estándar RDFS de la teoría de modelos semánticos.
Jena built-in Reasoner9, este conjunto podrían describirse como
razonadores basados en instancia, el cual provee tres configuraciones
iniciales: full (por defecto), mini y micro.
El comportamiento de varios razonadores pueden ser configurados. En la tabla 2.3
se puede ver la lista de constructores OWL y los razonadores antes mencionados
indicando con el símbolo si el razonador soporta el constructor al momento de su
inferencia o clasificación.
Una característica importante en los razonadores es el tipo de suposiciones que
hace, existen dos: suposiciones de mundo cerrado (cwa, close world assumption) y
suposiciones de mundo abierto (owa, open world assumption). El primero se refiere a la
suposición de que lo que no se sabe que es verdad debe ser falsa (Wang & Zhou, 2001).
La segunda es lo contrario, es decir, es la suposición de que lo que no se sabe que es
cierto es simplemente desconocida (Moreno Paredes, 2007).
El estado resultante de una ontología después de haber utilizado un razonador en
ella, es un modelo inferido, el cual en muchas ocasiones es utilizado para realizar las
consultas, para las cuales existe su propio lenguaje.
8 http://owlim.ontotext.com/display/OWLIMv35/SwiftOWLIM+Reasoner#SwiftOWLIMReasoner-
SwiftOWLIM%27sLogicalFormalism 9 http://jena.apache.org/documentation/inference/
46
Pellet Hermit Fact++ (3)
1 Limpieza de Datos (Consistencia) Constructor owl-max owl-horst (1) micro mini full
Li1¿Cómo determinar el dominio de una
clase?rdfs:domain
Li2¿Cómo determinar el rango de una
propiedad?rdfs:range
Li3Restricción - La propiedad de una clase
debe contener al menos un valorowl:minCardinality
Li4Restricción -La propiedad de una clase
debe contener exactamente x valorowl:cardinality
Li5Restricción -La propiedad de una clase
debe contener como máximo un valorowl:maxCardinality
Li6Todos los individuos, al menos un valor de
la propiedad P proviene de la clase C.owl:someValuesFrom
Li7 Instancias nulas
Pellet Hermit Fact++
2 Integración Constructor owl-max owl-horst micro mini full
In1Combinar información de dos fuentes de
datos organizadas de manera diferente
rdfs:subPropertyOf
owl:inverseOf
In2Combinar los individuos de múltiples
fuentes de datos en una sola claserdfs: subClassOf
In3Hacer equivalentes dos clases cuando
tienen los mismos miembros.owl:equivalentClass
In4Hacer equivalentes dos propiedades
cuando estas se refieren a lo mismoowl:equivalentProperty
In5Combinar dos propiedades que no
comparten el mismo rango y dominio
owl: inverseOf
In6Determinar relación reciproca de
dependenciaowl:SymmetricProperty
In7Describir que todos los individuos tienen
el valor A para la propiedad Powl:hasValue
In8Mantener la información de ascendencia
consistenteowl:TransitiveProperty
In9 Distinguir y diferenciar todos los individuosowl:AllDifferent;
owl:disctinctMembers ()
In10Combinar dos propiedades en una
propiedad más generalrdf:subPropertyOf
In11Separar los miembros de una clase de los
miembros de otra claseowl:complementOf
In12 Unir dos clases owl:unionOf
In13 Intersectar dos clases owl:intersectionOf
Pellet Hermit Fact++
3 Reconciliación Constructor owl-max owl-horst micro mini full
Re1
Afirmar que cualquier miembro de una
clase será automáticamente tratado como
un miembro de otra
rdfs: subClassOf
Re2Determinar cuándo dos individuos son lo
mismo.
owl:FunctionalProperty .
owl:InverseFunctionalProperty
Re3Indicar de manera "manual" que dos
individuos son el mismo.owl:sameAs
Re4 Asignar un identificador a cada elelmento owl:hasKey
Re5Indicar que dos individuos no tienen
elementos en comúnowl:disjointWith
Re6Clasificar mienbros diciendo que cada uno
es diferenteowl:differentFrom
Re7Enlistar individuos que son instancias de
una clase definidaowl:OneOff
OWLIM Jena built-in Reasoner
OWLIM Jena built-in Reasoner
Razonadores
TopBraid Composer Prótegé
Uso de constructores OWLIM Jena built-in Reasoner(2)
Tabla 1.4 Razonadores
(1) http://answers.semanticweb.com/questions/9125/what-is-owl-horst-reasoning
(2) http://jena.apache.org/documentation/inference/index.html#OWLcoverage
(3) http://reasonerbench.mash-it.net/
http://www.mindswap.org/2003/pellet/performance.shtml
http://en.wikipedia.org/wiki/Reasoner#Reasoner_comparison
47
http://answers.semanticweb.com/questions/12112/what-are-the-differences-among-
pellet-hermit-and-fact
http://ceur-ws.org/Vol-188/sub6.pdf
2.9 LENGUAJE DE CONSULTAS – SPARQL
RDF es un formato de datos para grafos dirigidos y etiquetados para representar la
información en la Web. Esta especificación define la sintaxis y la semántica del lenguaje
de consulta SPARQL para RDF. SPARQL se puede utilizar para expresar las consultas
que permiten interrogar diversas fuentes de datos, si los datos se almacenan de forma
nativa como RDF o son definidos mediante vistas RDF a través de algún sistema
middleware. SPARQL cuenta con las capacidades para la consulta de los patrones
obligatorios y opcionales de grafo, junto con sus conjunciones y disyunciones. Los
resultados de las consultas SPARQL pueden ser conjuntos de resultados o grafos RDF
(Pastor Sánchez & Díaz Ortuño, 2009).
SPARQL (Simple Protocol and RDF Query Language) es un lenguaje de
recuperación basado en RDF. Se trata de una recomendación para crear un lenguaje de
consulta dentro de la Web semántica que está ya implementada en muchos lenguajes y
bases de datos. Desde 2005 está en proceso de estandarización por el W3C. Las
consultas SPARQL cubren tres objetivos:
Extraer información en forma de URIs y literales.
Extraer sub-estructuras RDF.
Construir nuevas estructuras RDF partiendo de resultados de consultas.
48
Una limitación es que únicamente se permiten consultas de lectura. Así pues sólo se
pueden acceder a los datos para leerlo y compararlos. En resumen SPARQL es una vía
rápida para localizar información específica. Por último cabe señalar que existen varias
implementaciones (Python, PHP, Java), pero destaca Jena Semantic Web Toolkit para
plataforma Java sobre las demás (Carretero, 2007).
SPARQL es un lenguaje similar al lenguaje de consultas de bases de datos
relacionales SQL, cada consulta puede estar formada por las siguientes cláusulas:
PREFIX define los prefijos para los espacios de nombres
SELECT identifica las variables que se retornarán como resultados
FROM nombra los grafos que serán consultados
WHERE patrón para la consulta en la forma de una lista de triplas
Algunos ejemplos se describen en la sección Anexo A.
2.9.1 Funciones de Agregación
En SPARQL / Query 1,0 (original de SPARQL), los patrones de consulta producen
un conjunto de soluciones en la que ciertas columnas se proyectan y se devuelve como
resultado de la consulta. Las funciones de agregación proporcionan la capacidad de
particionar un conjunto de soluciones en uno o más grupos basándose en filas que
comparten valores específicos. Las funciones más comunes incluyen COUNT, SUM,
MIN y MAX.
Las funciones de agregación se requieren normalmente para realizar una serie de
tareas de la aplicación y análisis de datos, tales como:
49
La determinación del número de recursos distintos que satisfacen determinados
criterios.
El cálculo de la calificación del examen promedio de estudiantes agrupados por
el distrito escolar.
La suma de las contribuciones de campaña de los donantes, agrupados por
código postal y partido político.
En la sección de Anexos B se muestran algunos ejercicios como ejemplos de cómo
aplicar las funciones de agregación ms comunes.
2.10 METODOLOGÍAS DE INTEGRACIÓN DE
INFORMACIÓN BASADA EN ONTOLOGÍAS
Existen metodologías para la integración y reconciliación de información con
―enfoque semántico‖. Para fines prácticos de esta investigación se analizaron algunas de
estas metodologías, las cuales son: MOMIS, SIMS y MIRSOFT, la propuesta es el
propósito de esta tesis.
2.10.1 MOMIS
MOMIS es un framework para la extracción de datos y la integración de fuentes de
información heterogéneas, desarrollado por la DBGroup (www.dbgroup.unimo.it) de la
Universidad de Módena y Reggio Emilia. El sistema implementa una metodología
semiautomática para la integración de datos siguiendo el enfoque Global As View
(GAV) (Domenico Beneventano & Bergamaschi, 2004).
50
En la actualidad, existen dos enfoques principales básicos para la integración de
datos: Global-as-View (GAV) y Local-as-View (LAV). Sin embargo, tanto GAV y LAV
tienen sus limitaciones. En un enfoque GAV, los cambios en las fuentes de información
o la adición de una nueva fuente de información requiere de revisiones de un esquema
global y correlaciones entre el esquema global y esquemas de origen. En un enfoque de
LaV, automatizando la reformulación de consulta tiene complejidad exponencial con
respecto a las definiciones de esquema de consulta (Xu & Embley, n.d.).
El resultado del proceso de integración MOMIS es un esquema global, que ofrece
una vista reconciliada, integrada y una vista virtual de las fuentes subyacentes, GVV
(Vista Virtual Global) (Domenico Beneventano & Bergamaschi, 2004).
Objetivo
MOMIS (Mediator Enviroment Multiples Information System) tiene como objetivo
integrar datos de fuentes de datos estructurados y semiestructurados. MOMIS sigue un
―enfoque semántico‖ para la integración de información basada en el esquema
conceptual, o metadatos, de las fuentes de información.
La contribución original de MOMIS está relacionada con la disponibilidad de un
conjunto de técnicas para que el diseñador enfrente los problemas comunes que surgen
al integrar pre-existentes fuentes de información, que contiene datos tanto
semiestructurados como estructurados (D. Beneventano et al., 2000).
Elementos
El sistema está compuesto por los siguientes elementos funcionales:
51
1) Un modelo de datos común ODM, el cual es definido de acuerdo al lenguaje
ODL (Object Definition Language) para describir los esquemas de las fuentes
para el propósito de la integración.
2) Wrappers.
3) Mediador, el cual está compuesto por dos módulos: GSB (Global Schema
Builder) y QM (Query Manager).
Arquitectura
MOMIS soporta integración de la información en la creación de una visión
integrada de todas las fuentes GVV (por sus siglas en inglés, View Virtual Global) en
una forma automatizada y realiza la revisión y la validación de los distintos tipos de
conocimiento utilizados para la integración.
La arquitectura MOMIS se representa en la figura 2.3:
52
Figura 1.4 Arquitectura de MOMIS
El enfoque de integración MOMIS (D. Beneventano, Bergamaschi, Guerra, &
Vincini, 2001) se articula en las siguientes fases:
1. Generación de un thesaurus común.
2. Análisis de Afinidad de las clases.
3. Agrupación de Clases.
4. Generación del esquema mediador.
53
El primer paso en la construcción del esquema global es la creación de un thesaurus
común a partir de las distintas fuentes. Para ello se crea un envase (wrapper) para cada
fuente en lenguaje ODLI3 que tiene como fundamento al lenguaje (OLCD) de lógica
descriptiva, que hace posibles las inferencias sobre las clases expresadas en dicho
lenguaje. El thesaurus describe el conocimiento sobre las clases y los atributos de los
esquemas fuente (Moreno Paredes, 2007). Se construye en un proceso incremental en el
que se le añaden las relaciones entre clases basadas en:
La estructura de los esquemas fuente.
Las propiedades léxicas de las clases fuente y atributos. Por ejemplo,
Wordnet puede ser utilizado para identificar sinónimos.
Las relaciones agregadas por el diseñador.
Las relaciones inferidas por el motor de inferencia.
Una vez creado el thesaurus, se genera dentro de éste un árbol de clusters afines en
el cual se agrupan los conceptos según el grado de afinidad. La afinidad se calcula en
base a la relación terminológica de dos clases y también en base al nivel de coincidencia
de las relaciones de atributo en el thesaurus. Los componentes de MOMIS son:
El envase (wrapper)
Las fuentes a menudo nos proporcionan los datos en formatos que no se pueden
manipular directamente por los sistemas de integración. En los html, los datos (nombres,
teléfonos, emails, etc.) vienen intercalados en el texto en lenguaje natural. Los sistemas
de integración comunican con un wrapper, cuya tarea consiste en traducir los datos a
54
una forma que pueda ser procesada posteriormente por el sistema de integración, en este
caso aODLI3. Cada formato de datos requiere su propio wrapper.
El mediador (mediator) El mediador es un componente del sistema de
información que está situado entre las fuentes de datos, el usuario y las
aplicaciones.
Datos codificados→Mediador→Información
El mediador aprovecha el conocimiento de los datos para crear la información que se
integrará en una capa más alta de la aplicación. Su valor añadido es justo esa
transformación de los datos en información. El mediador tiene las siguientes tareas:
o Acceso y recuperación de datos relevantes desde fuentes múltiples y
heterogéneas.
o Abstracción y transformación de los datos recuperados en una
representación y semántica común.
o Integración de los datos homogeneizados conforme a claves de
coincidencia, y,
o Reducción de los datos integrados por abstracción para incrementar la
densidad de la información en los resultados a transmitir.
Herramienta ARTEMIS, que clasifica las clases.
Herramienta ODB que valida el esquema y las inferencias con el fin de generar el
thesaurus.
55
2.10.2 SIMS
SIMS es un mediador de información que provee acceso e integración de múltiples
fuentes de información. Las consultas son expresadas en un lenguaje uniforme,
independiente de la distribución de información sobre los recursos, varios leguajes de
consulta, etc. SIMS determina cual fuente de datos usar y como obtener la información
deseada, cómo y cuándo almacenar y manipular los datos y cómo recuperar la
información. La parte central de este mediador es la habilidad para recuperar y procesar
datos pudiendo optimizar las consultas mediante un plan y así minimizar los costos de
recuperación (Arens et al., 1996).
Objetivo y Elementos
SIMS proporciona a los usuarios una vista uniforme de los elementos de
información que pertenecen a los sistemas de información heterogéneos y por el uso de
las normas y tecnologías de la Web Semántica.
SIMS está diseñado para proveer las siguientes funcionalidades:
Integración de las fuentes de información heterogéneas a nivel
conceptual: Este enfoque permite un acceso uniforme y con base
semántica para recuperar los elementos de información correspondientes.
SIMS propone integrar las fuentes de información sólo a nivel
conceptual.
El enriquecimiento semántico de los elementos de información: SIMS
propone dos maneras diferentes pero complementarias para enriquecer los
elementos de información. El primero es de dominio independiente, y
asocia un subconjunto específico de Metadatos Dublin Core para cada
56
elemento de información. El segundo es de dominio dependiente y se
basa en la asociación entre los elementos de información y las ontologías
de dominio expresadas en un lenguaje formal, como OWL (Ontology
Web Language). Esta asociación se obtiene como resultado de un proceso
de anotación semántica.
Búsqueda y Publicación de información: A partir de peticiones de
usuario, SIMS es capaz de recuperar y presentar información
personalizada. Este proceso se basa en las consultas sobre las ontologías.
Las Ontologías y el proceso de anotación semántica permiten que SIMS
proporcione a los usuarios resultados más precisos. El SIMS ofrece
funcionalidades basadas en la similitud semántica entre conceptos para
mejorar esta interacción (Pirrone, Russo, Sangiorgi, Ingraffia, & Vicari,
2008).
Arquitectura
Figura 1.5 Arquitectura de SIMS (Pirrone et al., 2008).
57
En la Figura 5 se describe gráficamente la arquitectura SIMS, donde, la Capa de
Persistencia (Persistence Layer) representa los repositorios físicos de las fuentes de
información, cuyos elementos de información estén disponibles para los usuarios finales
SIMS por medio de los componentes de software específicos llamados Proxy-Wrapper.
En la capa de Aplicación SIMS (SIMS Application Layer) está compuesto por varios
módulos que permiten la vista unificada de las fuentes de información y la gestión de las
capas superiores. Permite la integración externa de información, el almacenamiento de
los metadatos para la recuperación de información (repositorios virtuales) las funciones
de indexación (indexer), la gestión de la ontología y la anotación semántica. En la capa
de Abstracción (SIMS Abstraction Layer) puede ser considerada como la base del
conocimiento para el framework. La información está estructurada y homogénea lista
para ser procesada a través de la capa de presentación. La capa de Presentación (SIMS
Presentation Layer) es la capa más alta de la arquitectura la cual gestiona la interacción
del usuario final por medio del navegador semántico (Pirrone et al., 2008).
2.10.3 MIRSOFT
Heterogeneidad de las fuentes y la reconciliación de datos son por lo general
tratados por separado por los sistemas de integración existentes. Esta metodología de
integración, llamada MIRSOFT, se encarga de estos asuntos en una arquitectura de
mediador. Está principalmente motivada por tres factores principales:
(1) la continuidad conceptual ofrecida por ontologías para generar modelos
conceptuales y facilitar la resolución de los datos heterogéneos,
58
(2) la reciente definición de dependencias funcionales (FD) en conceptos
ontológicos, que puede ser una solución interesante para el problema de la reconciliación
de datos y,
(3) el desarrollo de las fuentes de OBDB (por sus siglas en inglés Ontology-Based
DataBases) que pueden necesitar ser integrados a lo mejor de nuestro conocimiento.
OBDB es una base de datos en donde se almacenan las ontologías y sus instancias.
MIRSOFT es el único sistema que tiene en cuenta simultáneamente la
heterogeneidad y los problemas de reconciliación de datos mediante la integración de
datos a través de OBDB y reconciliación de FD, dependencias funcionales (Bakhtouchi,
Bellatreche, Jean, & Ait-ameur, 2011).
La construcción de un sistema de integración es una tarea difícil por las principales
razones:
El gran número de fuentes de datos candidatas para la integración,
La falta de semántica de las fuentes
La heterogeneidad de las fuentes
La autonomía de las fuentes
Para enfrentar los problemas semánticos y asegurar una integración de datos
automática, un gran número de investigadores proponen el uso de ontologías. Varios
sistemas de integración son propuestos bajo esta hipótesis: COIN, Observer, OntoDaWa,
etc.
Esta metodología es la primera en considerar simultáneamente la heterogeneidad y
la reconciliación, las cuales son tratados por separado.
59
3 CAPÍTULO 3. ANÁLISIS DE METODOLOGÍAS DE
INTEGRACIÓN SEMÁNTICA DE INFORMACIÓN
En esta sección se presentará un análisis de las metodologías existentes para la
integración de información, así como también la metodología propuesta, objetivo de esta
investigación.
En la sección 3.1 se presenta un análisis de las metodologías existentes que abarcan
la integración y/o reconciliación de información utilizando enfoques semánticos.
En la sección 3.2 se desarrollan las etapas de la metodología A&H propuesta
siguiendo el mismo enfoque. Y finalmente, se presenta un resumen de la metodología
actual que se lleva a cabo para la integración de información.
3.1 METODOLOGÍAS EXISTENTES
En la tabla 3.1 se muestran algunas de las metodologías existentes para dar solución
a la integración de información y reconciliación de datos, así como también la
metodología A&H propuesta en esta investigación y la metodología del proceso de
integración y reconciliación actual.
Tabla 3.1 Etapas de la integración de las metodologías
60
De acuerdo al análisis de cada metodología se hizo una separación mediante etapas,
representadas en las columnas (ver tabla 3.1). La etapa ―Pregunta‖ se refiere a las
preguntas del usuario que se pretenden responder en el resultado de la integración. Por lo
general las metodologías comienzan con esta etapa, lo requerimientos del usuario se
hacen en términos de un esquema global. La siguiente etapa se refiera a la forma en
cómo extraen la información que será integrada, a esta etapa se le llama ―Extracción de
Información‖, cada una de las metodologías lleva un proceso distinto, pero cada una
cumple con la finalidad de obtener la información que será integrada. La etapa 3 llamada
Metodología Pregunta
Extracción de
Información
Tratamiento de
DatosIntegración Reconciliación Consulta
MOMIS
(2004)
1
Mediante un
lenguaje común
ODLI3
2
Mediante la generación de
Thesaurus: SYN, BT, NT y RT
Anotación
Afinidad de términos
Mediante agrupación de
clases (Clustering)
Generación de un esquema
Virtual (GSV)
3
En términos del
esquema de
datos
SIMS
(1996)
1
Requerimientos del
usuario mediante
un esquema Global
2
Selección de las
fuentes de
información
3
Mapeo de conceptos en los
niveles:
Dominio y Fuente de
Información
4
En término de
requerimientos
MIRSOFT
(2011)
1
Requerimientos del
usuario mediante
un esquema Global
2
Selección de
clases y
propiedades
4
En término de
requerimientos
A&H
(2013)
1
Requerimientos del
usuario mediante
un esquema Global
2
Selección de
Fuentes de
Información
3
Preparación de
datos
4
Alineación de Ontologías
(Global-Locales)
Mejores prácticas (ver tabla
de integración)
5
Mejores prácticas
(Ver tabla de
reconciliación)
6
En término de
requerimientos
Metodología
Manual
1
Requerimientos del
usuario
2
Peticion de
información
3
* Formatos
similares en las
estructuras de las
tablas
*Selección de
infromación
4
Unificar las tablas
5
Uso de formula para
eliminar duplicados
6
En términos del
esquema de los
datos
3
Query engine
Wrapper
Reconciliator
61
―Preparación de Datos‖ existe solo en la metodología A&H ya que no se cuenta con
estructuras de bases de datos definidas, es decir, la información a integrar son tablas en
formato semiestructurado. En la cuarta etapa se lleva a cabo la integración de
información, Mirsoft es la única metodología que hace de manera semiautomática las
etapas: integración y reconciliación, a diferencia de SIMS y MOMIS que no cumplen
con la etapa de reconciliación. A&H hace uso de constructores OWL para llegar a la
etapa de reconciliación tanto a nivel esquema como a nivel instancia. La última etapa
que es la de ―Consultas‖ cada metodología lo hace de acuerdo al propósito de su
integración. MOMIS es la única que hace consultas en términos del esquema que fue
construido como resultado de su proceso de integración.
El proceso de integración de las metodologías antes mencionadas es descrito a lo
largo de este capítulo.
3.1.1 MOMIS
MOMIS es una metodología que para la integración de fuentes de datos
heterogéneas que implementa una metodología semiautomática para la integración y
sigue un enfoque GVA, con sus siglas en inglés Global As View. El resultado de este
proceso de integración es un esquema global el cual provee una vista integrada y virtual
de las fuentes subyacentes (GVV, por sus siglas en inglés Global Virtual View) el cual
está compuesto por un conjunto de clases que representa la información contenida en las
fuentes y este es el resultado de la integración (Domenico Beneventano & Bergamaschi,
2004).
Metodología de Integración
62
El proceso de esta metodología está dado por las siguientes fases, como se muestra
en la figura 3.1.
Figura 3.1 Proceso de Integración MOMIS (Domenico Beneventano &
Bergamaschi, 2004)
Las etapas del proceso de integración están divididas en tres: 1 la extracción de
información mediante un lenguaje común ODLI3, las etapas 2, 3, 4 y 5 son los procesos
correspondientes a la etapa de la integración, y por último la consulta en términos de
esquema.
Extracción de Información
En esta sección se describe el proceso en la etapa de la extracción de las fuentes de
datos.
1. Wrapping: Extracción de la estructura de datos para las fuentes.
1
2
3 4
5
63
Un wrapper convierte lógicamente la estructura de las fuentes de datos en el modelo
ODLI3, cuya tarea principal consiste en traducir los datos a una forma que pueda ser
procesada posteriormente por el sistema de integración, en este caso aODLI3. Cada
formato de datos requiere su propio envase (Moreno Paredes, 2007).
Integración
El proceso de integración conduce a una visión integrada de las fuentes subyacentes,
en un esquema global. Para ello se especifican reglas de correspondencia y restricciones
de integridad con el fin de manejar la heterogeneidad(Moreno Paredes, 2007).
Como siguientes pasos del proceso de la integración se tienen:
2. Anotación Manual de una fuente local en WordNet.
Por cada elemento del esquema local, la integración se hace manualmente eligiendo
los significados apropiados en el sistema léxico WordNet. Esta fase de anotación está
compuesta por dos grandes pasos:
a) Word Form choice
b) Meaning choice
La anotación es un paso en donde se eligen las palabras y su significado, ya sea el
significado original o el significado en el que se relaciona con otro término.
3. Generación de un Thesaurus común.
Describe en intra e inter esquema de conocimiento en la forma de relaciones SYN
(Sinónimo de), BT (Término más amplio), NT (Término más estrecho) and RT
64
(Termino Relacionado). El Thesaurus común está construido hacia un proceso
incremental en el cual las siguientes relaciones son añadidas:
a) Relaciones derivadas del esquema
b) Relaciones derivadas del Léxico
c) Relaciones remplazadas por el diseñador
d) Relaciones inferidas
4. Generación de la Vista Virtual (GVV).
La metodología MOMIS permite identificar clases similares ODLI3, es decir, las
clases que describen el mismo concepto o que están semánticamente relacionadas en
distintas fuentes, para lograr una afinidad en entre coeficientes, que al final será
evaluada por todos los pares de clases posibles en ODLI3, esta afinidad determina el
grado de relación entre dos clases por su nombre y su estructura. Esta afinidad esta
fusionada a un coeficiente de afinidad global calculado por la combinación de los dos
coeficientes anteriores.
Los coeficientes pueden estar representados como lo muestra la figura 3.2.
Figura 3.2 Coeficientes de Afinidad (Domenico Beneventano & Bergamaschi, 2004)
5. Anotación de la Vista Global Virtual
65
Esta anotación significa asignar un nombre y un conjunto de significados a cada
elemento global (clases o atributos) (Domenico Beneventano & Bergamaschi, 2004).
Consulta
Después de completar el proceso de integración se procede a realizar las consultas
en términos de esquema. MOMIS es, pues, un mediador que proporciona un esquema
global y una interfaz para el usuario (Moreno Paredes, 2007).
3.1.2 SIMS
Es un mediador de información que provee el acceso y la integración de múltiples
fuentes de información (Arens et al., 1996).
Proceso de Integración
En la figura 3.3 se muestra el proceso de integración que se lleva a cabo en la
metodología SIMS, el número representa la etapa clasificada en la tabla 3.1.
Figura 3.3 Proceso de Integración SIMS (Arens et al., 1996)
Las consultas para SIMS son expresadas en términos de un modelo de dominio
general, es decir, no es necesario conocer los términos o lenguajes usados en las fuentes
de información (Etapa 1, en relación a las etapas definidas para SIMS en l tabla 3.1). El
1 2
3
4
66
primer paso en responder una consulta expresada en términos del dominio del modelo es
seleccionar la fuente de información apropiada (Etapa 2), esto es para transformar la
consulta expresada en conceptos en el modelo del dominio en una consulta expresada en
términos de conceptos del modelo de la fuente de información.
Después se selecciona la fuente de información, se mapea un concepto en nivel de
dominio para un concepto a nivel de fuente de información (Etapa 3) para lograr una
integración de las fuentes. En término del modelo del dominio provee descripciones de
las clases, y las relaciones entre subclases y superclases, el rol de cada clase, así como
también otros dominios de información específicos (Arens et al., 1996). En general, la
elección se fuentes de información está hecha a fin de minimizar el coste global de la
recuperación.
Cada sistema ha reformulado la consulta para que sea usada únicamente en términos
del modelo de la fuente de información y el siguiente paso es generar un plan de
consultas para recuperar y procesar los datos. El plan de consultas especifica
operaciones precisas que necesitan ser desempeñadas, así como el orden en el cual van a
ser desarrolladas. Puede haber una deferencia significante en la eficiencia entre los
diferentes planes de consultas, sin embargo los diseñadores pueden implementarla lo
más eficiente posible. Las tres operaciones básicas que son usadas en el plan para
procesar consultas son:
Move-Data: Mover un conjunto de datos de una fuente de información a otra.
Join: Combinar dos conjuntos de datos en un conjunto combinado usando
relaciones de unión.
67
Retrieve-Data: Especifica el dato que va a ser recuperado de una fuente de datos
en particular.
La reformulación de consultas semánticas (Etapa 4), la meta de la reformulación es
buscar la consulta menos cara en el espacio de las consultas semánticamente
equivalentes. La reformulación de una consulta a otra es hacer inferencias lógicas
usando database abstractions (Arens et al., 1996).
3.1.3 MIRSOFT
De igual manera MIRSOFT es una de las metodologías para la integración de
información, que a diferencia de otras, esta no requiere de todas las fuentes para llevar a
cabo el proceso de integración, esta metodología integra en función de la llegada de las
fuentes de información y las elimina una vez que no se usan (Bakhtouchi, Bellatreche, et
al., 2011).
Antes de iniciar con el proceso de integración, los componentes de MIRSOFT se
inicializan de la siguiente manera:
El mediador es importado por la selección de clases y propiedades de la ontología
compartida, esta importación se realiza como sigue:
1) A partir de las necesidades del usuario, el administrador selecciona las
clases y propiedades relevantes de la ontología compartida
2) Las clases y propiedades seleccionadas se añaden a la ontología
mediadora
3) Si una clase importada tiene una súper clase, todas las clases de su
superclase a través de la jerarquía de clases también se importan
68
4) Mantener la semántica de las propiedades complejas (propiedades del
objeto), esto consiste en la importación de las clases y sus rangos
5) Del mismo modo, mantener FD, por lo tanto, la importación de una
propiedad aparece del lado derecho lo que implica la importación de
todas las propiedades que aparecen en la parte izquierda del FD
6) Comprobar la consistencia y clasificar la taxonomía del mediador
utilizando un razonador
7) Nuevas FD se pueden añadir a la ontología compartida
En la figura 3.4 se muestra una representación como ejemplo de la importación de
una ontología mediadora:
Figura 3.4 Representación de una ontología mediadora
Este esquema contiene seis clases, representadas en rectángulo morado (Persona,
Estudiante, etc.) y nueve propiedades, representadas por: p1, p2, p3.. etc. Bajo la
suposición de que el administrador del mediador selecciona solo tres clases (Persona,
Estudiante y Empleado) y cuatro propiedades (personID, name, age and telephone).
69
Después de la importación los componentes del mediador contiene: una ontología
mediadora y el esquema, el esquema fuente y el mapeo están vacíos.
Integración de nuevas fuentes
Bajo la suposición de que cada clase de la ontología local hace referencia
explícitamente(o implícitamente a través de su clase padre) su subsunción bajo la clase
en la ontología compartida y las propiedades únicas que no existen en la ontología
compartida pueden diferenciarse en una ontología local. Se distinguen diferentes
escenarios de integración, asociados a algoritmos de integración:
Escenario de fragmentación: Este escenario de integración asume que la ontología
compartida es suficiente para cubrir las necesidades de todas las fuentes. La autonomía
de las fuentes en este escenario son materializadas: cada fuente selecciona un
subconjunto relevante de la ontología compartida (clases y propiedades) y diseña su
esquema local.
Escenario de Ontología integrada: En varios casos, más autonomía es requerida por
varias fuentes. Esta autonomía es caracterizada por el hecho de que cada fuente local
puede tener sus propios conceptos y propiedades. Entonces, cada fuente de datos tiene su
propia ontología y las clases de cada ontología son específicas. Pero, todas las ontologías
hacen referencia a una ontología compartida. En este escenario la adición de una nueva
fuente de datos está dada por lo siguiente:
1) Se actualiza el mediador añadiendo la nuevas clases y propiedades
correspondientes para los requerimientos del usuario definidos en la ontología
global en la que no existe una ontología compartida
2) Se actualiza el nuevo esquema de la fuente añadiendo la nueva fuente
70
Visión general de MIRSOFT
Los diferentes módulos que componen a esta metodología se pueden ver en la
figura 3.5.
Figura 3.5 Visión General de MIRSOFT
(1) El repositorio OBDB: El mediador usa la misma estructura usada en el
proceso de integración de otros sistemas. Este sigue el modelo OntoDB
donde la parte del esquema meta es extendida por: un mediador y un modelo
esquema de la fuente, un modelo de mapeo entre el mediador ontológico y la
ontología de la fuente y un modelo FD.
(2) La interfaz del usuario: Permite al usuario expresar sus consultas y mostrar
los resultados. Después de procesar la salida de la consulta, la interfaz de
usuario envía al engine query el conjunto de consultas definidas por un
conjunto de clases y propiedades del mediador. La interfaz de usuario es
responsable también de desplegar las respuestas de la primera fuente visitada
71
y actualizar las respuestas cuando la respuesta de una o más fuentes vengan
del reconciliador estén disponibles.
(3) El query engine: Desempeña las siguientes tareas (i) encontrar el FD que se
mantienen en la consulta, (ii) identificar las fuentes pertenecientes y la
obtención de la clave de la reconciliación, (iii) reescribir la consulta definida
en el mediador en las consultas definidas en la ontología local, se envía
entonces la clave de reconciliación al reconciliador.
(4) El resultado de la reconciliación: El rol de este módulo es reconciliar los
resultados usando una clave de reconciliación, unir instancias que se refieren
a lo mismo en el mundo real siguiendo la selección de técnicas para enviar
progresivamente los resultados obtenidos en la interfaz del usuario de una
manera incremental.
3.2 A&H PARA NO-ONTOLOGISTAS
A&H es una metodología enfocada a la integración y reconciliación de información
de fuentes de datos heterogéneas y semi-estructuradas. Tiene como objetivo cumplir con
todo el proceso de la integración, desde las necesidades del usuario (Pregunta) hasta
responder una consulta en términos de requerimiento. Parte de la metodología A&H
hace uso de constructores OWL los cuales fueron clasificados de acuerdo a las
necesidades de cada etapa y fundamentados en mejores prácticas o desafíos
desarrollados por (Allemang & Hendler, 2008). La figura 3.6 muestra la estructura
general de A&H en la cual se pueden ver los elementos principales de la metodología.
72
Figura 3.6 Esquema General de A&H
El esquema general muestra un panorama del proceso y las etapas de la metodología
propuesta. En esta metodología la información a integrar se encuentra en archivos
tabulares (csv) y se desconoce la estructura y semántica de los datos de donde proviene.
Así como también cabe mencionar que el encargado de realizar la integración no debe
ser experto en ontologías, solo es necesario hacer uso de algunos constructores OWL y
de herramientas sin grado de dificultad en su uso.
73
Figura 3.7 Proceso de Integración de A&H
El proceso de la metodología propuesta está dado por las siguientes etapas, las
cuales se muestran en la figura 3.7, indicando la etapa con un número y un color. La
descripción de cada etapa se describe a lo largo de este capítulo.
3.2.1 Etapa I – Requerimientos del usuario en un esquema global
Como parte principal de esta metodología es necesario saber y entender los
requerimientos de los usuarios, es decir, qué se entiende por cada una de las peticiones
74
de información, ya que hay variedad de usuarios y pueden existir distintas
interpretaciones acerca de los datos o de definiciones dadas.
La elección de un dominio general forma parte de esta etapa, es decir, lograr
representar el entendimiento común, para ello es necesario seleccionar la ontología
adecuada en términos y definiciones similares a la del dominio en particular (ontología
global). Para la construcción de las definiciones en el esquema global deben ubicarse las
clases necesarias en la jerarquía propia de la ontología global seleccionada.
Una gran ventaja en seleccionar una ontología existente y ampliamente aceptada,
es que puede asegurar la posible interoperabilidad con otros sistemas.
3.2.2 Etapa II – Selección de fuentes de información
La elección de las fuentes de datos adecuadas puede minimizar tiempo de
recopilación de la información. Como se mencionó en la sección 2.3 existen dos formas
de hacer la integración de datos: la integración vertical y la integración horizontal, cada
una cumple con un objetivo; la primera integra información que proviene de distintas
fuentes y la segunda agrega información adicional o complementaria a una determinada
fuente. Esta metodología puede usar cualquier tipo de integración de datos, haciendo un
análisis para considerar lo que genere menos costo de recuperación de información y
procesamiento.
Se recomienda seleccionar la menor cantidad de fuentes con la mayor parte de datos
necesarios para responder a las preguntas del usuario.
75
3.2.3 Etapa III – Preparación de datos
Una vez obtenidos los datos, es necesario analizar la información brindada para
saber si son suficientes los datos y si cumplen con los requerimientos para el usuario, es
por ello importante la etapa II. En esta etapa es significativo contar con los datos
―limpios‖. Ninguna ontología local deberá contener datos nulos ya que los razonadores
sólo son capaces de clasificar con respecto a la información dada o inferida pero no a
partir de la información faltante. Si se dejan datos faltantes es necesario utilizar un
razonador que soporte la suposición de mundo cerrado para clasificar individuos a partir
de la negación de la existencia de alguna propiedad o atributo.
Existen algunos constructores OWL que permiten evitar la inconsistencia en los
datos cuando ya es creada la ontología, los constructores pueden verse en la tabla 3.2.
3.2.4 Etapa IV – Integración (Alineación de Ontologías)
Para la integración de información a través de un enfoque semántico es por medio
de una ontología. Por eso es necesario pasar del escenario de las fuentes de datos
semiestructuradas y heterogéneas a ontologías. En esta etapa se crean las ontologías
locales que son producto de las fuentes de datos que participarán en la integración. Por
lo tanto, en esta etapa se selecciona una ontología global con el propósito de tener un
entendimiento común entre las fuentes de datos. En Ontoware10
se pueden encontrar
ontologías que pueden ser explotadas y aplicadas en un dominio en particular según sean
las necesidades del modelador.
10 es un servidor que permite el hosting de ontologías http://ontoware.org/
76
SOLUCIÓN
Constructor Ejemplo
Li1¿Cómo determinar el dominio de
una clase?rdfs:domain hasnomina rdfs:domain Person
Li2¿Cómo determinar el rango de una
propiedad?rdfs:range hasnomina rdfs:range xsd:string
Li3
Restricción - La propiedad de una
clase debe contener al menos un
valor
owl:minCardinality hasname owl:minCardinality 1
Li4
Restricción -La propiedad de una
clase debe contener exactamente x
valor
owl:cardinality hasnomina owl:cardinality 1
Li5
Restricción -La propiedad de una
clase debe contener como máximo
un valor
owl:maxCardinality hasnomina owl:maxCadinality 1
Li6
Para todos los individuos, al menos
un valor de la propiedad P proviene
de la clase C.
owl:someValuesFrom[a owl:Restriction;
owl:onProperty :teach
owl:someValuesFrom :Alumno]
Li7
Para todos los individuos los cuales
todos los valores de la propiedad P
vienen de la clase C
owl:allValuesFrom[a owl:Restriction;
owl:onProperty :hasnomina
owl:AllValuesFrom :Employee]
Li9Dentro de los archivos a integrar
existen instancias nulas
Acondicionamiento
inicial de datos
Existen columnas en las cuales
los datos son nulos (estan vacios).
El acondicionamiento inicial es
no permitir que existan datos
nulos, por lo tanto deben ser
llenados con la palabra null
Tratamiento de Datos (Consistencia)CASO
En la etapa II se hizo una selección de fuentes de información las cuales, en el
formato dado, serán convertidas en una ontología, con formato RDF, las cuales serán
nombradas como ontologías locales. Estas ontologías deberán importar la ontología
global, para que al momento de la integración haya un entendimiento común entre las
fuentes. Existen herramientas que hacen la conversión del formato dado en las fuentes
de datos a un formato RDF y OWL, las cuales producen una clase OWL que representa
los datos del archivo tomando cada columna para definirla como propiedad de dicha
clase. El tipo de datos y la cardinalidad de las columnas se pueden definir mediante las
restricciones de la tabla 3.2.
Tabla 3.2 Constructores OWL para la Preparación de Datos
77
De igual manera, se clasificaron algunos constructores OWL que sirven para la
etapa de Integración, los cuales se pueden ver en la tabla 3.3.
Tabla 3.3 Constructores para la Integración
| CASO SOLUCIÓN
Constructor Ejemplo
In1
Combinar información de dos
fuentes de datos organizadas de
manera diferente
rdfs:subPropertyOf
owl:inverseOf
:statusJob rdfs:subPropertyOf :statusActividad
:bajaProf rdfs:subPropertyOf :statusProf
:statusActividad owl:inverseOf :statusProf
In2
Combinar los individuos de
múltiples fuentes de datos en
una sola clase
rdfs: subClassOflocalA:hasnacionalidad rdfs:subClassOf :nacionalidad.
localB:paisnacimiento rdfs:subClassOf :nacionalidad.
In3
Hacer equivalentes dos clases
cuando tienen los mismos
miembros.
owl:equivalentClass PLProfessor owl:equivalentClass FTProfessor
In4
Hacer equivalentes dos
propiedades cuando estas se
refieren a lo mismo
owl:equivalentPropertylocalA:hassexo owl:equivalenteProperty
localB:hasgenero
In5
Combinar dos propiedades que
no comparten el mismo rango y
dominio
owl: inverseOf:statusActividad owl:inverseOf :statusProf
In6Determinar relación reciproca de
dependenciaowl:SymmetricProperty
localA:coauthorOf rdf:type owl:SimmetricProperty
Luis García coauthorOf Juan Pérez
In7
Describir que todos los
individuos tienen el valor A para
la propiedad P
owl:hasValue :Employee owl:hasValue :hasnomina
In8Mantener la información de
ascendencia consistenteowl:TransitiveProperty
P rdf:type owl:TransitiveProperty
A P B
B P C
entonces,
A=C
In9Distinguir y diferenciar todos los
individuos
owl:AllDifferent
owl:disctinctMembers
[ a owl:AllDifferent;
owl:disctinctMembers (localA:PTProfessor
localA:FTProfessor
localA:ExTProfessor)].
In10Combinar dos propiedades en
una propiedad más general rdf:subPropertyOf LocalA:hasnomina rdf:subPropertyOf LocalB:nomina
In11
Separar los miembros de una
clase de los miembros de otra
clase
owl:complementOf :Mexicano owl:complementOf :Extranjero
In12 Unir dos clases owl:unionOf Professor a owl:Class;
owl:unionOf ( localA:PTProfessor localA:FTProfessor )
In13 Intersectar dos clases owl:intersectionOf
Professor a owl:Class;
owl:intersectionOf ( localA:PTProfessor
localA:FTProfessor )
Integración
P
78
3.2.5 Etapa V – Reconciliación (Mejores prácticas)
Conflictos semánticos y estructurales son dos retos prevalentes a causa de la
heterogeneidad de las fuentes de datos. Los conflictos semánticos surgen cuando
diferentes fuentes describen los mismos conceptos con diferentes nombres de elementos,
o se aplican significado entre los conceptos similares en diferentes fuentes (Nguyen,
Taniar, Rahayu, & Nguyen, 2011).
Dicho lo anterior, un nivel más de la integración es la reconciliación de datos. La
reconciliación de datos consiste en la ―corrección‖ de los resultados devueltos por un
sistema de integración. En efecto, cuando una consulta se ejecuta en un sistema de
integración, los resultados pueden ser redundante desde varias fuentes pueden tener la
misma respuesta (Bakhtouchi, Bellatreche, Jean, & Ait-Ameur, 2012). Estos problemas
ocurren en dos niveles: a nivel esquema y a nivel instancia. A nivel esquema,
corresponde a una tarea que intenta establecer mapeos semánticos entre los contenidos
de las distintas fuentes de datos; es decir, identificar entidades que representan la misma
entidad en el mundo real e identificar los atributos que describen la misma propiedad en
el mismo tipo de entidad. A nivel entidad se presenta el problema de identificar la
instancia que representa la misma entidad en el mundo real y además corregir el valor de
dicha entidad (Bakhtouchi, Jean, et al., 2011).
A partir de los esquemas locales se crean definiciones locales para los conceptos
globales, que son el objeto de la integración. Si la definición se puede realizar utilizando
sólo atributos de una fuente de datos se declara en la ontología local. Si la definición
requiere datos provenientes de diferentes fuentes, entonces la definición se hace en la
ontología integradora.
79
En esta etapa se hace uso de algunos de los constructores OWL que sirven para esta
etapa de reconciliación a nivel entidad (instancia), la reconciliación a nivel esquema se
hace en la etapa previa. La tabla 3.4 muestra los constructores que apoyan a esta etapa.
Tabla 3.4 Constructores OWL para la Reconciliación
CASO SOLUCIÓN
Constructor Ejemplo
Re1
Afirmar que cualquier
miembro de una clase será
automáticamente tratado
como un miembro de otra
FTProfessor rdfs:subClassOf FullProfessor
Re2Determinar cuándo dos
individuos son lo mismo.
P rdf:type owl:FunctionalProperty .
P rdf:type owl:InverseFunctionalProperty
CASO SOLUCIÓN
Definición Ejemplo
Re3
Indicar de manera "manual"
que dos individuos son el
mismo.
J. Pérez owl:sameAs Juan Pérez
CASO SOLUCIÓN
Definición Ejemplo
Re4Asignar un identificador a
cada elelmentohasnomina owl:hasKey
Re5Indicar que dos individuos no
tienen elementos en comúnJuan Pérez G owl:disjointWith Juan Pérez L
¿Cómo puede OWL llegar a una conclusion mediante el proceso de eliminación?
CASO SOLUCIÓN
Definición Ejemplo
Re6Clasificar mienbros diciendo
que cada uno es diferenteFullProfessor owl:differentFrom PTProfessor
Re7
Enlistar individuos que son
instancias de una clase
definida
:PTProfessor a owl:Class
owl:oneOf (:OQ :PC :PL)
¿Cómo decimos que no hay relación alguna entre dos individuos?
RECONCILIACIÓN
¿Cómo podemos tratar a dos conceptos como el mismo?
¿Cómo decimos que dos individuos son originalmente el mismo?
80
3.2.6 Etapa VI – Consulta en términos de requerimientos
Como producto de una integración de fuentes de datos, por medio de una ontología
global y n locales, se tiene un solo archivo integrador para responder a las preguntas en
términos de requerimientos. El usuario podrá consultar mediante un lenguaje de
consultas llamado SPARQL. SPARQL11
es un lenguaje de consulta RDF, es decir, un
lenguaje de consulta de bases de datos, capaz de recuperar y manipular los datos
almacenados en el formato Resource Description Framework.
En la ontología integradora a cada ontología local (fuente de datos) se le identifica
con un namespace y un prefijo diferente.
Las consultas se expresan utilizando los términos definidos en la ontología global.
11 SPARQL (pronounced "sparkle", a recursive acronym for SPARQL Protocol and RDF Query Language)
http://en.wikipedia.org/wiki/SPARQL
81
4 CAPÍTULO 4. CASO: INDICADORES DE PLANTA
ACADÉMICA PARA EL RANKING QS.
En esta sección se presentará un caso de estudio realizado en el Departamento de
Investigación y Emprendimiento dentro del Tecnológico de Monterrey, campus
Monterrey.
El Tecnológico de Monterrey, junto con más de 200 universidades a nivel
Latinoamérica y alrededor de 400 universidades a nivel mundial ha participado en
organismos de Ranking por medio de los cuales, el Tecnológico de Monterrey es
calificado para posicionarlo en un lugar académico a nivel mundial, así como también a
nivel Latinoamérica. Los principales Rankings en los que participa el Instituto son: QS
World University Rankings, y THE - Times Higher Education organizado por Thomson
Reuters.
Cada ranking considera ciertos criterios de desempeño para poder evaluar a las
universidades participantes, por mencionar algunos de estos criterios, son: cantidad de
publicaciones publicadas en revistas científicas, cantidad de profesores, cantidad de
alumnos, número de financiamientos otorgados en becas, infraestructura, entre otros.
Para este caso de estudio el criterio a considerar es el rubro de profesores
únicamente, ya que la información de los profesores cuenta con las características
indispensables para que al momento de ser ejemplificada satisfaga las necesidades de
integración de datos de cualquier índole. Además de que dio atributo, se encuentra
detallado a nivel personal, y otras fuentes de datos se encuentran sumarizados.
82
Es indispensable solicitar información al departamento encargado de administrar la
información de la planta académica. Es necesario integrar dicha información y
clasificarla para así establecer un índice de conteo de profesores. El objetivo de este caso
de estudio es probar la tecnología semántica existente para la integración de información
para responder a los requerimientos de información dados por el ranking QS World
University Rankings, así como también mejorar el proceso de integración de una
metodología actual para dicha integración y así determinar las ventajas y desventajas de
ambas metodologías.
Así pues, en la sección 4.1 se dará una introducción de la participación del
Tecnológico de Monterrey en rankings internacionales, además de una descripción breve
de los departamentos participantes en el proceso de integración de información para la
realización del reporte requerido para el ranking.
En la sección 4.2 se hace mención de las definiciones de cada concepto de la planta
académica según el Ranking QS.
En la sección 4.3 se describe el desarrollo de la aplicación de la metodología
propuesta para la integración y reconciliación de información por medio de tecnología
semántica, desarrollando cada etapa el proceso necesario para dicha metodología.
4.1 PRESENCIA DEL TECNOLÓGICO DE MONTERREY EN
RANKINGS INTERNACIONALES
Los dos organismos evaluadores mencionados en la sección 4, posicionan al
Instituto bajo dos procedimientos distintos: dándole un lugar dentro de la lista de las
83
universidades participantes, y asignándole una cantidad de estrellas, según los criterios
mencionados en la sección 4.
El departamento de Investigación y Emprendimiento es el encargado de reunir la
información necesaria para reportar a estos organismos, el cual hace una serie de
peticiones de información a otros departamentos, por ejemplo: información recuperada
del Roster (obteniéndose del sistema administrativo del departamento de Escolar),
Becas, Personal, Biblioteca, Programas Internacionales y Centro de Vida y Carrera o
del sistema de información SIIP, para determinar valores correspondientes para cada
criterio.
La información proporcionada cada año por cada uno de los departamentos
recientemente mencionados no está organizada de la misma manera. Dentro del dominio
de la Administración de Datos, se puede afirmar que dichas fuentes son semi-
estructuradas, ya que los datos no tienen una estructura definida y esto impide hacer un
proceso automático en la integración y reconciliación de información requerida para
calcular el número de profesores, alumnos y otros criterios de desempeño. De la misma
forma, debido a que la información es proveniente de muchas fuentes de datos, se
consideran como fuentes de datos heterogéneas.
La información requerida por los organismos acreditadores, en términos generales,
está relacionada con: infraestructura, finanzas, personal (profesores, empleados y
alumnos), becas, biblioteca, entre otros. Los criterios de evaluación cambian en base al
tiempo y a la organización ranking, por lo tanto esto hace que las peticiones de
información cambien a través del tiempo.
84
4.2 DEFINICIONES DE RANKINGS PARA PLANTA
ACADÉMICA
Este caso de estudio está delimitado en analizar el rubro de Profesores únicamente,
ya que con este podemos probar si la integración de información puede resolverse por
medio de tecnología semántica, y además partiendo del hecho de que estas fuentes de
datos son heterogéneas y semi-estructuradas. Este rubro está dividido en la siguiente
clasificación:
Full Time= personal de tiempo completo,
Part Time=personal de tiempo parcial,
Headcount = número de personas,
FT Equiv.= Es el resultado de calcular el equivalente a tener sólo personal de tiempo
completo.
El proceso que se siguió comienza definiendo una población que es delimitada por
las peticiones que hace QS, las definiciones son las siguientes:
Number of Faculty Staff
“Total number of academic faculty staff who are responsible for planning, directing
and undertaking teaching only, research only or both teaching and research. Please
include: vice-chancellors, deputy vice-chancellors, principals, professors, and heads of
school, associate professors, principal lecturers, tutors or postdoctoral researchers.
Please exclude research assistants*, PhD students who contribute to teaching, and
exchange scholars or visiting professors who are members of another university.
* The important distinction for us is that staff counted as „research only‟ should be
academically involved in that research and should be likely to publish research outputs.
85
A research assistant, in our understanding, is any individual who is not doing own
research and is therefore not likely to publish own research outputs. Said individual is
(only) involved in research in terms of operation execution, such as lab technician or
equipment operator.”
Number International Faculty Staff
Number of academic faculty staff who are of foreign nationality. The term
“international” is hereby determined by citizenship. For EU countries, this includes all
foreign nationals, even if from another EU state. In Hong Kong, this includes professors
from Mainland China. Inclusion and exclusion mirrors those for academic faculty staff.
In case of dual citizenship, the „deciding‟ criteria should be „citizenship obtained
through birth‟, basically first passport obtained.
Number Staff with PhD
Number of academic faculty staff who with a doctoral degree (PhD) in the most
recent annual period. The most recent annual period is the last calendar year or
academic. Please provide which is easier to obtain.
Después de delimitar la población, se clasifica y contabiliza en base a la categoría
laboral del profesor, dividida en: Full Time, Part Time, para calcular Headcount y FT
Equiv.
4.3 METODOLOGÍA ACTUAL
En términos generales el proceso de integración que se lleva a cabo actualmente
para poder responder a los requerimientos del Ranking QS, se puede ver representado en
la figura 4.1.
86
Figura 4.1 Proceso de integración y reconciliación de la metodología actual
4.1.1 Pregunta
La pregunta es interpretada en términos del usuario. Es importante tener claro que
información es requerida para así hacer las peticiones de información necesarias para
responder a los requerimientos del ranking.
4.1.2 Extracción de información
Una vez que los requerimientos son entendidos, se hace la petición de información a
las personas responsables, esta petición de igual manera se hace en términos del usuario.
Para fines prácticos, al momento de hacer la petición de información se adjunta el
archivo del año anterior para dar a entender que se requiere esa información indicando si
es necesario adicionar algún otro dato.
4.1.3 Tratamiento de datos
Se hace una preparación de información mediante un acondicionamiento de datos en
las tablas, por ejemplo: se estructuran de manera similar las columnas de las tablas,
87
A&H
1
Requerimientos del
usuario mediante
un esquema Global
2
Selección de Fuentes de
Información
3
Preparación de datos
4
Alineación de Ontologías
(Global-Locales)
Mejores prácticas (ver tabla
de integración)
5
Mejores prácticas
(Ver tabla de
reconciliación)
6
En término de
requerimientos
Metodología PreguntaExtracción de Información Tratamiento de Datos Integración Reconciliación Consulta
puesto que existe una dependencia en el orden dado a las fórmulas utilizadas, se
selecciona sólo información relevante que será útil para responder a los requerimientos
del ranking.
4.1.4 Integración
Con el uso de la formula VLOOKUP se unifican las tablas en un solo archivo para
poder identificar y descartar registros iguales. Cuando se usan muchas fórmulas sobre
tablas con grandes volúmenes de información, estas se eliminan para agilizar el proceso.
4.1.5 Reconciliación
Para la identificación de los registros duplicados es necesario considerar una ―clave‖
que permitirá la identidad de cada registro, en este caso se considera la columna
―nomina‖ para identificar a cada profesor. Se aplica la formula e =IF (C2<>C3,1,E3+1).
4.1.6 Consultas
Este proceso de consultas se hace en términos del usuario, de los datos como están
representados en las tablas. Se elaboran en el archivo resultante de la eliminación de
duplicados mediante la aplicación de filtros.
4.4 APLICACIÓN DE METODOLOGÍA A&H
En esta sección se explicará el proceso de desarrollo de la metodología propuesta,
mencionada en la sección 3. En la figura 4.2 se muestran las etapas de la metodología.
88
Figura 4.2 Etapas de la metodología propuesta
La aplicación de cada etapa se describe a partir de la sección 4.3.1.
La figura 4.2 muestra el proceso de la metodología, la cual indica con la numeración
la etapa correspondiente a dicha metodología. Así pues, la etapa 1 corresponde a la
pregunta en términos de requerimientos del usuario mediante un esquema global la etapa
2 la extracción de información por medio de la selección de fuentes de información, la
etapa 3 se da una preparación a los datos, la etapa 4 la integración por medio de la
alineación de ontologías (Global-Locales), la etapa 5 reconciliación e integración y por
último la etapa 6, consultas en términos de requerimiento.
89
Figura 4.3 Proceso de Integración y Reconciliación
Así pues se puede identificar el proceso que se sigue durante la integración,
reconciliación y consultas.
4.4.1 Requerimientos del usuario mediante un esquema global
Los requerimientos del usuario están dados por los criterios mencionados en la
sección 4.2, los cuales deberán estar en un dominio común, por lo cual es necesario
encontrar una ontología que permita el manejo de estas definiciones.
Selección de una ontología existente (ontología global)
Para este dominio se seleccionó SWRC12
(por sus siglas en inglés Semantic Web
for Research Communities) versión 0.7.1 la cual sirve para modelar entidades de
comunidades de investigación, como personas, organizaciones, publicaciones y sus
relaciones, útil para este campo de estudio.
El proceso de importación de una ontología global se describe en la sección de
Anexos A. La estructura inicial de la ontología SWRC se muestra en la figura 4.4.
12 Semantic Web for Research Communities v0.7.1.
http://ontoware.org/swrc/swrc/SWRCOWL/swrc_updated_v0.7.1.owl
90
Figura 4.4 Jerarquía de Clases en SWRC
En la figura 4.4 se pueden ver las clases principales de la ontología, las cuales serán
útiles para poder clasificar las clases apropiadas para las definiciones del ranking antes
mencionados. Por lo tanto seleccionaremos la clase Person. Dentro de la cual existen
subclases que apoyarán a la clasificación de la planta académica.
De acuerdo a las definiciones dadas por el ranking, es necesario hacer la
clasificación dentro de la ontología, la clasificación se muestra en la figura 4.5, dentro de
la cual se indica con un número la clase que será referenciada en la tabla 4.1. Esta
clasificación se adecuará a la ontología global con la finalidad de clasificar a la planta
académica, esta adecuación se muestra en la figura 4.6. Los nuevos conceptos se
identifican con un namespace y un prefijo que representa al ranking en cuestión.
91
Figura 4.5 Clasificación Planta
Académica
Figura 4.6 Adecuación de la Ontología
Global (swrc)
El procedimiento para insertar una nueva clase se describe en Anexo E.
Definiciones globales
Para construir las definiciones globales, es necesario tener en cuenta la clasificación
de la planta académica y para este caso de estudio la clasificación puede resumirse en la
tabla 4.1. El número indica la clase correspondiente a la clasificación dada en la figura
4.5.
Tabla 4.1 Clasificación de la Planta Académica
Headcount Full Time Part Time
Faculty Staff Clase 1 Clases 1 and 2 Clases 1 and 3
International
Staff
Clase 4 Clases 4 and 2 Clases 4 and 3
Staff with PhD Clase 5 Clases 5 and 2 Clases 5 and 3
92
Las definiciones globales fueron construidas con la finalidad de poder clasificar a
los profesores y así poder cuantificarlos de acuerdo a cada criterio requerido por el
ranking.
Por lo tanto, con estas combinaciones se podrá llegar al número resultante de profesores
para cada clasificación. En Faculty Staff se clasificará el total de profesores (headcount
– 1 ) de tiempo completo (Full Time – 1 and 2) y tiempo parcial (Part Time- 1 and 3).
International Staff (headcount – 4), profesores internacionales de tiempo completo (Full
Time – 4 and 2), de tiempo parcial (Part Time – 4 and 3). Staff with PhD (headcount –
5) de tiempo compelto (Full Time – 5 and 2) y de tiempo parcial (Part Time – 5 and 3).
Gráficamente la clase y las subclases creadas en la ontología global se pueden
visualizar en la figura 4.6, obteniendo el grafico de la herramienta TopBraid Composer,
en la sección Graph.
Figura 4.7 Clase y Subclases creadas
93
4.4.2 Selección de fuentes de datos
La finalidad de esta etapa de la metodología es la selección adecuada de fuentes de
datos para cumplir con el propósito de cada ranking. Esto podrá parecer una tarea trivial,
pero no es así, es una tarea que en ocasiones se vuelve lenta, ya que existe un nivel de
dependencia en cada departamento que brinda información al encargado de ranking, así
como también la falta de un entendimiento común.
La localización de los responsables de la información necesaria es un proceso que
en muchas ocasiones se extiende más tiempo de lo planeado. Identificar las fuentes de
datos es un proceso para el cual se requiere conocimiento de la institución y se hace
preguntando a los responsables de la información. Una vez localizado al responsable se
le pide la información en los términos de la acreditación y se hace con él un proceso de
entendimiento conjunto de la solicitud de manera que proporcionen la información
correspondiente. En este proceso se mapean (manualmente) las definiciones del ranking
y los términos usado por la organización. La información brindada por el responsable
puede contener datos que no sean útiles, pero fue necesario considerar para llegar a la
definición solicitada. Por ejemplo, si se solicita información sobre profesores vigentes,
el reporte que envían contiene el Term que indica el semestre/trimestre en que la clase
fue impartida por el profesor; si bien éste no es un dato que se vaya a reportar pero si es
la justificación para considerar al profesor como activo.
Identificación de fuentes de datos
Siguiendo el proceso descrito en la sección 3, en esta etapa de la metodología, se
seleccionaron las fuentes de datos necesarias para su integración y así llegar a los
resultados esperados, que son clasificar y contabilizar a la planta académica.
94
Tabla Personal
La tabla de información de Personal cuenta con 12 columnas y 80 registros. La
estructura de la tabla se puede ver en la sección de Anexo F.
La tabla RosterMty
La tabla RosterMty tiene 63 columnas y 1887 registros. La estructura de la tabla se
puede ver en la sección de Anexo G.
La problemática de los datos en el proceso de integración y reconciliación está
sintetizada en los siguientes puntos: el modelo de información es distinto (fuentes de
datos heterogéneas), los criterios de los rankings cambian con el tiempo, pueden existir
nuevos criterios en el futuro, hay transformaciones particulares para cada fuente de
información.
4.4.3 Preparación de datos
Es importante considerar que antes de importar la ontología local, los individuos
que tengan datos nulos deberán ser llenados con la palabra null. Esto es, porque los
razonadores analizados en este estudio no infieren datos vacíos en alguna clasificación
de profesores.
4.4.4 Construcción de ontologías locales
La herramienta utilizada para la edición e integración de ontologías es
TopBraidComposer13
edición Estándar. Esta herramienta ya cuenta con una conversión
semi-automática de archivos con extensión .xlsx a RDF, esto lo hace desde el momento
de la importación de archivos. El proceso de conversión que se siguió se describe en
Anexo B.
13 http://www.topquadrant.com/products/TB_Composer.html
95
Una
limitante
de este
método
es que
sólo se
puede
crear
una sola
clase por
documento, la cual es nombrada a petición del usuario y las propiedades son tomadas de
las columnas (atributos) de la hoja de cálculo, las cuales pueden ser editadas para
asignarle un tipo de dato a cada propiedad y la unión de algunas columnas en una sola
propiedad. Por lo tanto, a la única clase importada (Person) se le agregan dos subclases
(ver anexo E):
Figura 4.8 Definiciones (Mexican e International)
Mexican e International. La siguiente figura
muestra cómo quedan las subclases y su definición. Una restriccion importante a tomar
96
en cuenta es que cada persona o profesor debe tener exactamente una nacionalidad para
poder clasificarla ya sea como mexicano o internacional. Los razonadores analizados
que cumplian con suposiciones Close World Assumption (CWA), hace esta inferencia si
se asegura que haya sólo un valor para una propiedad. El no asegurar dicha restricción
podría tener como consecuencia suceder que el razonador no haga la inferencia o
clasificación. Por lo tanto se le agrega esta restriccion exactly 1 a la propiedad
hasnacionalidad. Las definiciones de las clases se muestran en la figura 4.8.
Todas estas adecuaciones no son replicables, es decir, cada vez que se requiera
realizar el proceso se tienen que rehacer. Por lo tanto, cuando se tiene un nuevo criterio
es necesario replicar este procedimiento añadiendo las clases necesarias.
Una vez que se ha importado la ontología local (archivo Excel), se importa la
ontología global dentro de la local, ver proceso en Anexo C. Con esta integración se
realizarán las definiciones y restricciones adecuadas para poder clasificar a los
profesores (ver sección 4.3.4.1).
4.4.5 Integración (Alineación de las ontologías)
Las definiciones son construidas en la ontología local, ya que esto facilitará la
integración de nuevas fuentes de datos. En seguida se describe la construcción de las
definiciones a nivel local, así como el proceso de integración y el uso de constructores
en esta etapa.
Construcción de definiciones locales
Para construir las definiciones de los esquemas locales se consideraron las preguntas
del Ranking QS. Cabe destacar que la universidad, en este caso el ITESM tiene la
97
facultad de clasificar su personal en tiempo completo o tiempo parcial, según sus
propios criterios.
Considerando los criterios del ITESM, la clasificación de la planta académica se
lleva a cabo de la siguiente manera, como se muestra en la tabla 4.2.
Tabla 4.2 Clasificación de la planta académica del Tecnológico de Monterrey
Las definiciones para el ranking se basan en esta clasificación antes mencionada.
Un profesor de tiempo completo es subclase de Faculty Staff, es la unión de la clase
Person con la propiedad que describa la categoría laboral de la persona, en la figura 4.9
se muestran las definiciones de cada fuente de datos elaboradas en TopBraid. En esta
definición podrán clasificarse los profesores de tiempo completo, es decir, Faculty Staff
en FullTime.
Info_Personal RosterMty
Fuente de Datos Info Personal Roster Mty
Criterio / Propiedad CveFormaContrat Categoria Laboral
Full Time PL Planta
MP Media Planta
Auxiliar Planta
Part Time OQ Catedra
RQ Cátedra (Auxiliar)
PC Obra Determinada de TC Auxilia
Obra Determinada de TC Enseñan
Obra Determinada Tiempo Parcia
Profesor Virtual
Headcount= Full Time +
Part Time Servicios Profesionales
FTE= Full Time + (Part
Time * 0.5) Nulos
98
Figura 4.9 Definición FullTime
Un profesor de tiempo parcial es subclase de Faculty Staff, es la unión de la
clase Person con la propiedad que describa la categoría laboral de la persona, la figura
4.10 se muestran las definiciones de cada fuente de datos elaboradas con TopBraid. En
esta clasificación podrán inferirse los profesores de tiempo parcial, es decir, Faculty
Staff en PartTime.
Info_Personal
99
Figura 4.10 Definición PartTime
Un profesor internacional es subclase de Faculty Staff, es la unión de la clase
Person con la negación de la clase mexicano, la figura 4.11 muestra la definición con la
interface de TopBraid. En esta definición podrán inferirse los profesores internacionales.
Info_Personal RosterMty
Figura 4.11 Definición International
Un profesor PhD es subclase de Faculty Staff, es la unión de la clase Person con
título de Dr. o Dra., la figura 4.12 muestra la definición con la interface de TopBraid
Composer. En esta definición podrán inferirse los profesores con grado PhD.
RosterMty
100
Personal_Info RosterMty
Figura 4.12 Definición PhD
Proceso de integración
La finalidad del proceso de integración es encontrar las equivalencias e igualdades
entre las fuentes de datos para unificar en un solo archivo y así poder realizar consultas
eliminando redundancia e inconsistencia en los datos.
Equivalencias entre clases: Se dice que una clase es equivalente a otra cuando tienen
miembros similares o iguales, por ejemplo, la clase ‗Person‟ de una fuente de datos es
equivalente a la clase ‗Persona‘ que está definida en otra fuente de datos.
Las equivalencias entre clases encontradas en este caso de estudio se muestran en la
tabla 4.3:
Tabla 4.3 Equivalencia de Clases
Personal-sn SWRC RosterMty-sn
Personal-sn:Person global:Person RosterMty-sn:Person
Personal-sn:Mexican RosterMty-sn:Mexican
Personal-sn:International global:INTProfessor RosterMty-sn:International
Clases Equivalentes
101
4.4.6 Reconciliación
El proceso de reconciliación consiste en identificar cuándo una persona es la misma
en diferentes fuentes de datos, por lo tanto esta identificación consiste en reconocer
literalmente a un mismo individuo. El uso de constructores OWL y un razonador puede
ayudar a evitar esta duplicidad. El razonador utilizado para este caso de estudio es
Hermit14
que es ejecutado bajo la plataforma de Protégé que de acuerdo al análisis de los
constructores OWL, el razonador fue el más favorable, ya que cumplía con las
necesidades de inferencias del modelo.
Restricciones y Mapeos
La necesidad de identificar a un individuo como único es cada vez más importante
en el manejo de la información, por eso es necesario que en este caso de estudio cada
individuo de la planta académica sea identificado como único. Para evitar redundancia o
duplicidad, se vio la necesidad de establecer una llave. Existe una propiedad común
entre todas las fuentes de datos que hacen único a un individuo, por lo tanto es necesario
localizar la propiedad y hacerla equivalente entre todas las fuentes de datos.
Equivalencias entre propiedades: Se refiere a aquellas cosas que describen una
propiedad de la misma manera, por ejemplo, en alguna fuente de datos una propiedad
que describa el género de una persona se llama ‗sexo‘ y en otra fuente de datos la
propiedad que describa lo mismo se llama ‗genero‘, por lo tanto se dice que esas dos
propiedades son equivalentes. La siguiente tabla 4.5 muestra las equivalencias entre las
propiedades que se encontraron en las dos fuentes de información.
14 http://www.hermit-reasoner.com/
102
Tabla 4.4 Equivalencias entre propiedades
La propiedad ‗hasnomina‟ existe en ambas fuentes de datos, las cuales cumplen con
la misma función que es identificar a un individuo.
Uso de constructores
Cada individuo deberá tratarse como único, es por eso que se tuvo la necesidad de
establecer, mediante el constructor owl:hasKey, la llave de cada individuo para
identificar cuándo un individuo es el mismo y simplificar el proceso de reconciliación.
La llave es definida en la ontología global para permitir identificar a los individuos
desde la perspectiva general de la información. El constructor utilizado para indicar
cuando un individuo es el mismo es owl:sameAs. La lista de constructores se ilustra en
la sección 3, tabla 3.5.
Selección de Razonador
Es de gran importancia seleccionar el razonador adecuado según las necesidades del
modelo con la finalidad de que el razonador haga las clasificaciones o inferencias de
manera correcta. Existen dos supuestos en los que se basa un razonador, el supuesto
mundo abierto OWA Open world assumption por sus siglas en inglés, es la suposición
indicando que la falta de conocimiento no implica falsedad. Por otra parte existe el
supuesto mundo cerrado CWA Close world assumption por sus siglas en inglés, es la
suposición de que lo que no se sabe actualmente que es verdad, es falso.
Se analizaron algunos razonadores con el propósito de establecer cuál de ellos
cumple con la mayoría de los requerimientos basados en las necesidades de integración.
Info_Personal RosterMty
Nomina owl:equivalentProperty Nomina
TituloTrato owl:equivalentProperty Clave Titulo Trato
Nombre
ApellidoPaterno
ApellidoMaterno
Sexo
Nacionalidadowl:equivalentProperty
Nacionalidad Pais
Nacimiento
CveFormaContrat owl:equivalentProperty Categoria Laboral
EstatusJobowl:equivalentProperty
Estatus Actividad
Profesor
DescPuesto
Cve U.O.
Nombre U.O. owl:equivalentProperty Departamento
Propiedades Equivalentes
Nombre
owl:equivalentProperty
103
Se analizaron razonadores en dos plataformas TopBraid Composer versión Estándar y en
Protege 4.2. La tabla se muestra en la sección 2, tabla 2.4. Por lo tanto, una vez
construidas e integradas las ontologías se procede a correr bajo un razonador dichas
ontologías, de acuerdo al análisis de los razonadores, el que se seleccionó es Hermit
instalado en Protege.
4.4.7 Consultas en términos de requerimiento
En esta etapa de la metodología se analiza tanto el proceso de clasificación de la
planta académica como el resultado de la consulta en términos de requerimientos. En
esta sección se describe el tipo inferencia necesaria para cumplir con los requerimientos
de las consultas, así como también el razonador que puede realizar dichas inferencias.
Inferencias
Posterior a la etapa de integración y reconciliación se genera un nuevo archivo con
las ontologías locales importadas y modeladas para indicar las equivalencias e
igualdades entre las fuentes de datos sometiendo este archivo bajo el razonador Hermit
el cual nos brindará un modelo inferido para poder realizar las consultas. El modelo
inferido contiene tanto las relaciones lógicas entre los elementos de la ontología, las
cuales no pueden ser definidas explícitamente y las relaciones explicitas. Por lo tanto, el
razonador clasifica a la planta académica en base a las definiciones de QS.
Consultas
En esta etapa las consultas se definen en base a los requerimientos dados, por lo
tanto es más fácil poder responder en términos más similares a los de los requerimientos
establecidos por el ranking. Una vez clasificada la planta académica es más simple poder
consultar, ya que los términos son similares a los de los requerimientos. SPARQL es el
104
lenguaje utilizado para realizar las consultas sobre ontologías, que de acuerdo a la tabla
4.1, fueron definidas de la siguiente manera:
Tabla 4.5 Tabla de Consultas sobre el modelo inferido
No. de clase Criterio Consulta SPARQL
1
FacultyStaff (headcount)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:FacultyStaff .
?prof swrc:nomina ?nomi
}
1 and 2
FacultyStaff (FullTime)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:FacultyStaff .
?prof a global:FTProfessor .
?prof swrc:nomina ?nomi
}
1 and 3
FacultyStaff (PartTime)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:FacultyStaff .
?prof a global:PTProfessor .
?prof swrc:nomina ?nomi
}
4
International Staff (headcount)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:INTProfessor .
?prof swrc:nomina ?nomi
105
4 and 2
International Staff (FullTime)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:FTProfessor .
?prof a global:INTProfessor .
?prof swrc:nomina ?nomi
4 and 3 International Staff (PartTime) SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:PTProfessor .
?prof a global:INTProfessor .
?prof swrc:nomina ?nomi
5
Staff with PhD (headcount)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:PhDProfessor .
?prof swrc:nomina ?nomi
5 and 2
Staff with PhD (FullTime)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:FTProfessor .
?prof a global:PhDProfessor .
?prof swrc:nomina ?nomi
5 and 3
Staff with PhD (PartTime)
SELECT COUNT ( DISTINCT
?nomi)
WHERE {
?prof a global:PTProfessor .
?prof a global:PhDProfessor .
?prof swrc:nomina ?nomi
Estas consultas fueron hechas en el archivo integrado e inferido.
106
4.5 GUIA DEL INSTRUMENTO
El instrumento desarrollado tiene como objetivo validar la metodología dirigida a un
usuario no-Ontologista, cuyas características se detallan en la siguiente lista:
Carecer de conocimientos de temas de tecnología semántica.
Contar con conocimientos básicos del uso de una computadora y paquetes de
software como Microsoft Office.
Conocer el dominio del tema para el cual se va a desarrollar la integración, en
este caso, rankings.
Conocer tareas básicas con archivos como importar y exportar.
Por otra parte, para poner en práctica este instrumento, se deberá asegurar que el
usuario cuente con las siguientes herramientas en su computadora:
TopBraid Composer Standard
Protégé
Microsoft Excel
Conexión a Internet
El instrumento se encuentra en la sección Anexo H. Su validación se hizo
aplicándolo a otro ranking distinto al del caso de estudio, con la finalidad de comprobar
la reutilización de definiciones ya construidas por un ranking y el uso de una persona no-
Ontologista.
El instrumento está dividido en las seis etapas de la metodología A&H, ver figura
3.7, las cuales están clasificadas por colores, mismos que son usados en el instrumento.
107
La tabla 4.6 indica en términos generales la relación entre los pasos del instrumento y
las etapas de la metodología A&H.
Tabla 4.6 Relación de pasos del instrumento con las etapas de la
metodología A&H.
Como resultado de este proceso se observó que el manejo de los conceptos técnicos
del dominio ontológico no es muy común por lo tanto se detalló en cada una de las
etapas del proceso de integración y reconciliación la descripción de cada uno de ellos, ya
que el usuario no-Ontologista debe adaptarse al uso de estos conceptos.
También se pudo observar que la clasificación de constructores de los lenguajes
OWL y RDF en las etapas del proceso de la metodología fue de gran utilidad ya que
facilitó el uso de los constructores para elaborar las definiciones, la cual es una de las
etapas más confusas de la metodología, por ello se ejemplificaron y se detallaron casos
de aplicación de cada uno de los constructores (ver tablas 3.2,3.3 y 3.4).
4.6 RESULTADOS
4.6.1 Resultado de la aplicación de la metodología
El proceso de integración, representado en la figura 4.2, donde SWRC es el archivo
OWL localizado en Internet es importado en TopBraid Composer con la finalidad de que
No. Paso del
instrumento
(Figura H1)
Etapa de la
metodología A&H
(Figura 3.7)
1,2,3 y 4 1
5 2
6 3
7 y 8 4
9,10 y 11 5
12 6
108
este sea el esquema global en el proceso de integración y reconciliación de información.
En esta ontología se pretende colocar la clasificación de los profesores según sea
conveniente, en este caso se clasificó a la planta académica como se muestra en la figura
4.4. En seguida se importan los archivos de Excel para formar las ontologías locales y
así poder importar la ontología global a cada una de las locales.
Una vez que han sido formadas las ontologías locales, se continúa con la
integración, que es generar un nuevo archivo importando las ontologías locales para su
integración. Durante el proceso de integración se hace uso de los constructores OWL
clasificados para esta etapa en el proceso.
Se corren las inferencias mediante un razonador, en este caso será con Hermit
versión 1.3.7 para poder dar paso a la etapa final de este proceso de integración y
reconciliación de información que es generar las consultas para llegar al resultado
esperado. La comparación de resultados de la metodología actual con la metodología
propuesta se puede ver en la tabla 4.6.
Tabla 4.6 Comparación de resultados entre metodologías
109
Info_Personal
Todos Full time Part Time Headcount
OQ 3 72 8 80
PC 2
PL 72
RQ 3
Extranjeros
PL 1 1 0 1
Doctorado
OQ 2 7 4 11
PL 7
RQ 2
RosterMty
Todos Full time Part time Headcount
Auxiliar Planta 17 87 113 200
Catedra 84 17 Aux
Cátedra (Auxiliar) 0 96 Otros
Media Planta 7
Obra Determinada de TC Auxilia0
Obra Determinada de TC Enseñan0
Obra Determinada Tiempo Parcia3
Planta 63
Profesor Virtual 3
Servicios Profesionales 3
Null 20
Extranjeros
Auxiliar Planta 0 1 2 3
Catedra 2
Cátedra (Auxiliar) 0
Media Planta 0
Obra Determinada Tiempo Parcia0
Planta 1
Profesor Virtual 0
Null 0
Doctorado
Auxiliar Planta 6 29 21 50
Catedra 17
Media Planta 0
Obra Determinada de TC Auxilia0
Obra Determinada Tiempo Parcia1
Planta 23
Profesor Virtual 2
Servicios Profesionales 1
Null 0
Metodología Actual Metodología Propuesta
Headcount Full Time Part Time
Faculty Staff 280 159 121
International Staff 4 2 2
Staff with PhD 61 36 25
110
Expuesto lo anterior, se obtuvo como resultado la construcción de 8 definiciones
con la finalidad de responder a nueve preguntas incluidas en tres conceptos definidos por
del Ranking QS. Una vez construidas las definiciones el proceso de integración es más
sencillo, el siguiente paso será importar ambas fuentes de datos (esquemas locales) en un
solo archivo y correr el razonador Hermit para hacer las consultas en el modelo inferido
que es dado como resultado del razonador.
La prueba inicial fue integrar los dos archivos completos, con sus estructuras
originales, con algunos razonadores para determinar cuál soportaba esa cantidad de
información y además hiciera la clasificación de la planta académica correctamente.
Los razonadores probados fueron los que están contenidos en la tabla 2.3. Se
seleccionaron los que hacían clasificaciones bajo suposiciones de mundo cerrado,
Hermit y StarDog, corridos bajo plataformas distintas, Protege y línea de comandos
UNIX, respectivamente.
La muestra para la prueba de este caso de estudio se redujo considerablemente,
tomando solo 200 registros del archivo Roster y los 80 registros del archivo Personal.
Esto debido al menor alcance de los razonadores analizados y la capacidad de memoria
de estos.
Los tiempos resultantes del razonamiento y de consulta de cada una de las fuentes
de datos convertidas a RDF se muestra en la tabla 4.7.
111
Memoria RAM 3 GB Memoria RAM 64 GB
Procesador Intel Core i3 Procesador 32 Procesadores Genuine Intel
Sistema Operativo Windows 7 Sistema Operativo Linux Enterprise Server 11
Características de la PC Características del Servidor
PC
Personal: 16.1 seg
Headcount Full Time Part Time
Faculty Staff .5 seg 3.4 seg 10.4 seg
International Staff .5 seg 9.2 seg 2.1 seg
Staff with PhD .7 seg 9.2 seg 2.3 seg
RosterMty: 11.77 min
Headcount Full Time Part Time
Faculty Staff .3 seg 5 min 9:50 min
International Staff .5 seg 5:10 min 3:30 min
Staff with PhD .5 seg 2:45 min 7:50 min
Integrated 79.82 min
Headcount Full Time Part Time
Faculty Staff 1.3 seg .9 seg .7 seg
International Staff .2 seg 24:02 min 22:00 min
Staff with PhD .5 seg 54:12 min 50:00 min
Servidor
Personal: 13.4 seg
Headcount Full Time Part Time
Faculty Staff .6 seg 3.9 seg 9.1 seg
International Staff .7 seg 7.9 seg 2.5 seg
Staff with PhD .7 seg 9.3 seg 2.7 seg
RosterMty: 8.56 min
Headcount Full Time Part Time
Faculty Staff .6 seg .5 seg .7 seg
International Staff 1.0 seg 2:20 min 3:15 min
Staff with PhD .8 seg 2:22 min 3:22 min
Integrated 71.41 min
Headcount Full Time Part Time
Faculty Staff .6 seg .3 seg .5 seg
International Staff .8 seg 22:15 min 18:00 min
Staff with PhD .8 seg 50:01 min 46:12 min
Tabla 4.7 Tiempos de consulta y razonamiento
Las consultas e inferencias fueron hechas en dos máquinas con capacidades
diferentes, las características se pueden ver en la tabla 4.8.
Tabla 4.8 Características de los ordenadores
112
Etapa
1 Pregunta
2 ¿Sabes que ontologia elegir como dominio global?
Resultados
Clasificacion de la planta academica
Nombre de la ontología seleccionada:
SWRC v0.7.1
4.6.2 Resultado del uso del Instrumento
Como resultado del uso del instrumento se elaboraron seis preguntas para conocer la
experiencia del usuario con uso de las ontologías y tecnología semántica para la
integración y reconciliación de información. Resumiendo, se tuvo como resultado lo
siguiente:
El proceso más complicado fue entender los conceptos en el dominio de
ontologías y lenguajes de consulta.
Dificultades para construir las definiciones, no por el uso de
constructores, sino entender la lógica de cómo construirlas.
Se deben tener nociones de teoría de conjuntos para entender la lógica de
la función de cada constructor.
Una función importante en las herramientas semánticas tecnológicas es la
usabilidad.
El tiempo de integración de información se reduce notablemente.
Por otra parte se presentan los resultados de cada uno de los pasos del instrumento
en la tabla 4.9.
Tabla 4.9 Resultados del uso del Instrumento
113
3 ¿Sabes cómo importarla?
4¿El esquema importado cumple con todos los
requerimientos para la clasificación de los datos?
5¿Cuentas con las fuentes de información suficientes para
responder a la pregunta inicial?
6 ¿Los datos tienen el formato adecuado?
7¿Los archivos están en formato RDF o en formato
OWL?
8 ¿Ya se construyeron las definiciones?
Clases definidas
Wprofessor
FTProfessor
PTProfessor
INTProfessor
PhDProfessor
Constructores utilizados
rdfs:subClassOf
owl:equivalentClass
owl:disjointWith
owl:complementOf
9¿Ya se integró la información?
10
¿Ya se definieron las restricciones?
Restricciones Definidas
clave:nomina
equivalencia de nomina
Cosntructores utilizados
owl:hasKey
owl:equivalentProperty
11 ¿Requieres hacer la clasificación?
Nombre de los campos críticos:
claveTituloTrato
categorialLaboral
nivelMaximoEstudios
nacionalidad
nacionalidadPaisdeNacimiento
nomina
tituloTrato
cveFormaContrat
Nombre de las ontologías locales:
Info_Personal.rdf
RosterMty.rdf
Nombre de la ontología Integradora:
Personal-Roster.rdf
Nombre de las fuentes de datos:
Info_Personal
RosterMty
Nombre de la ontología global:
swrc.rdf
Enliste las clases añadidas:
FacultyStaff
WProfessor
FTProfessor
PTProfessor
INTProfessor
PhDProfessor
Headcount Full Time Part Time
Faculty Staff 280 159 121
International Staff 4 2 2
Staff with PhD 61 36 25
Academic Staff Woman 107 66 41
Continúa en la página siguiente.
114
12 ¿Requieres realizar consultas?
Se aplicaron las mismas consultas descritas en la tabla 4.5,
añadiendo las siguientes:
SELECT COUNT ( DISTINCT ?nomi)
WHERE {
?prof a SWRC:WProfessor .
?prof swrc:nomina ?nomi
}
SELECT COUNT ( DISTINCT ?nomi)
WHERE {
?prof a SWRC:PTProfessor .
?prof a SWRC:WProfessor .
?prof swrc:nomina ?nomi
SELECT COUNT ( DISTINCT ?nomi)
WHERE {
?prof a SWRC:FTProfessor .
?prof a SWRC:WProfessor .
?prof swrc:nomina ?nomi
Continúa en la página siguiente.
115
5 CAPÍTULO 5. DISCUSIÓN
En este capítulo se muestran algunos trabajos relevantes que fueron sustento para el
diseño de la metodología, así como también el propósito de cada una de ellos. También
se presentan las lecciones aprendidas durante el proceso de esta investigación.
5.1 COMPARACIÓN CON TRABAJOS RELEVANTES
La metodología propuesta por Moreno Paredes (2007) para la integración de
información consiste en analizar primero los requerimientos del usuario para basar la
creación de una ontología según sus necesidades. Su proceso comienza en analizar los
requerimientos, después recolectar los datos para la creación de las ontologías necesarias
para la integración.
En la metodología A&H propuesta en esta investigación, las ontologías son creadas
en un proceso semiautomático y son elaboradas directamente de las tablas, con la
utilización del esquema global y los esquemas locales facilitan el proceso de integración,
ya que el propósito de contar con un esquema global es obtener un entendimiento común
entre las fuentes de datos (tablas).
Las metodologías MOMIS, SIMS y Mirsoft, mencionadas en los capítulos 2 y 3,
tiene la finalidad común que es la integración de información utilizando tecnología
semántica, el proceso de cada una es distinto, así como el resultado de la integración. En
MIRSOFT y A&H se reconoce que es necesario contar, además de la integración, con
una etapa de reconciliación. MOMIS comienza su proceso de integración con la
extracción de información para generar un esquema virtual de las fuentes de datos y así
116
permitir consultar la información en términos del esquema generado. En la metodología
propuesta A&H se comienza con los requerimientos de usuario, el resultado de la
integración es consultar información en términos de los requerimientos.
La metodología A&H lleva un proceso de integración similar al de la metodología
SIMS ya que ambas comienzan con los requerimientos del usuario. La ventaja de A&H
estriba en un paso no existente en SIMS el cual es la etapa de reconciliación de
información para evitar redundancia y consistencia en la información.
Aunque no se considere una metodología, es importante mencionar TSIMMIS el
cual se considera un proyecto, cuyo objetivo es proveer una serie de herramientas para
acceder e integrar a múltiples fuentes de datos. El proceso de integración está enfocado
en mediadores y traductores que apoyan al entendimiento común entre las fuentes de
datos y los usuarios o aplicaciones finales con la finalidad de reducir esfuerzos en el
acceso de las fuentes de datos (Chawathe et al., 1994).
El proyecto TSIMMIS coincide las metodologías SIMS y Mirsoft en uso de
mediadores, ya que el acceso a los datos se hace directamente a las fuentes originales.
Una diferencia de A&H comparado con los demás enfoques es que no hay una
conexión directa hacia las fuentes de datos originales que están estructuradas, por lo que
no hay necesidad de contar con mediadores de conexión, sino que inicia a partir de
fuentes de datos (tablas) resultantes de una consulta previa, y que además son semi-
estructuradas y carecen de semántica.
La tecnología semántica aún se encuentra en estado de desarrollo, existen huecos
funcionales los cuales pueden derivar en el incumplimiento de algunos requerimientos
de usuarios que necesitan integrar información en un escenario como el expuesto en el
117
capítulo 4. Algunas limitaciones encontradas en las herramientas de tecnología
semántica analizadas son:
Creación de una sola clase. Esto sucede cuando se convierte una tabla de datos a
una ontología con formato RDF (TopBraid Composer Standard Version).
Falta de soporte en los razonadores para cantidades de instancias mayores a
20000, por lo que si funcionaron con 280 en nuestro caso de estudio.
KARMA es una herramienta dedicada a la integración de información y permite a
los usuarios integrar rápida y fácilmente los datos de una variedad de fuentes de datos
incluyendo bases de datos, hojas de cálculo, archivos de texto delimitados, XML, JSON,
KML y APIs Web(Knoblock et al., 2011). Los usuarios integran la información
mediante un modelo de ontología de su elección mediante una interfaz gráfica que
automatiza gran parte del proceso.
Esta herramienta permite sólo el modelado de las fuentes de datos en esquemas
ontológicos, en comparación de la metodología propuesta se propone llegar a un nivel de
razonamiento sobre los datos para obtener datos implícitos como resultado de dicha
inferencia o clasificación.
118
6 CAPÍTULO 6 - CONCLUSIONES
El objetivo de esta investigación fue crear una metodología para la integración y
reconciliación de información por medio de tecnología semántica. La Metodología se
diseñó de acuerdo a las necesidades de un usuario en particular, pero este puede ser
replicable a otros usuarios en circunstancias similares. A&H, nombre de la metodología
propuesta, tiene un objetivo particular: fue diseñada para personas no expertas en las
áreas de las ontologías y semántica. Se obtuvo como resultado el diseño de la
metodología y su aplicación con caso de estudio, el cual valida el proceso de cada una de
las etapas que conforman dicha metodología.
Existen trabajos similares en la literatura, los cuales son tomados como sustento del
diseño de la metodología propuesta.
En la parte del análisis de las metodologías existentes, se observó que:
Para hacer uso de las metodologías es necesario contar con un experto o
alguien que tenga conocimientos sobre el tema de ontologías e
integración de datos.
Las preguntas de los usuarios son respondidas en términos de los
esquemas, y no de los requerimientos.
No todas las metodologías analizadas toman en cuenta un proceso de
reconciliación de información.
También se observaron algunas limitaciones en las herramientas de software:
119
Se puede construir una sola clase y varias propiedades de cada fuente de
datos (tabla), sin posibilidad de poder aumentar el número de clases.
Los razonadores como Hermit 1.3.7 presenta problemas al momento de
realizar la clasificación de 1900 instancias.
Las herramientas tecnologías están sujetas a un conjunto particular de
pruebas muy específicas, que en la mayoría de los casos no se tiene
acceso a la información.
A pesar de que se tienen como entrada fuentes de datos que carecen de semántica, el
resultado de la metodología enriquece semánticamente a los datos.
Una desventaja de la aplicación de la metodología propuesta en esta investigación
es que no se tiene acceso directo a las fuentes de datos, sino las fuentes de datos que
participan en el proceso de integración y reconciliación pasaron por un proceso de pre-
consulta, y existe la posibilidad de que haya pérdida de datos a pesar de que la consulta
haya sido bien estructurada. Además no hay un entendimiento común en el proceso de
petición de información, por lo tanto existen huecos semánticos.
120
6.1 TRABAJO FUTURO
El podado de ontologías (Pruning Ontology) se refiere al proceso de eliminación de
elementos de la ontología que no son muy relevantes para un dominio de aplicación
dado (Maedche, Volz, & Fzi, 2001). Añadir un proceso o etapa que considere el podado
de ontologías dentro de la metodología A&H podría reducir tiempos de procesamiento
de inferencias y consultas.
El consumo directo de los datos podría brindar más aproximación a los resultados
de las consultas creadas. Las fuentes de datos provienen de una consulta previa a la
integración de información podrán carecer de semántica. Un trabajo futuro de esta
investigación está enfocado en agregar a la metodología un proceso para la extracción de
información directa de las fuentes de datos.
La validación teórica de los constructores OWL de acuerdo a los algoritmos de
razonamiento para cada uno de los razonadores. Podría extenderse a la validación de los
constructores OWL2.
Extensión del uso de la ontología para el dominio institucional, no sólo el de la
planta académica.
Incluir en la primera etapa de la metodología un proceso adicional para analizar los
repositorios ontológicos para seleccionar el esquema global según para el dominio a
aplicarse.
121
La metodología A&H no aplica para datos sumarizados, solo para datos detallados,
por lo tanto se requerirían constructores que representen agregaciones para representar
semánticamente dichos valores que pueden extraerse de tablas resumen.
122
ANEXO A – EJEMPLOS DE CONSULTAS EN LENGUAJE
SPARQL
A continuación se muestran algunos ejemplos de consultas en leguaje SPARQL15
.
Listar todos los profesores
select ?prof where {
?prof rdf:type f:prof.
}
Listar todos los profesores en orden alfabético
select ?name where {
?prof rdf:type f:prof.
?prof foaf:surname ?name.
}
ORDER BY ?name
Listar el Top 5 de los profesores por número de horas trabajadas
select ?ename ?hrs where {
?prof rdf:type f:prof;
foaf:surname ?ename;
f:hrs ?hrs.
}
ORDER BY DESC(?hrs)
LIMIT 5
Listar todos los departamentos de todos los profesores
select ?dept ?prof where {
{?prof rdf:type f:prof }
UNION
{?prof rdf:type f:prof}
}
15 http://en.wikibooks.org/wiki/XQuery/SPARQL_Tutorial
123
Listar todos los profesores con alumnos inscritos mayor o igual a 20
select ?prof ?totalinsc where {
?prof rdf:type f:prof;
f:totalinsc ?totalinsc.
FILTER (?totalinsc >= 20)
}
Todos los profesores que no tengan nacionalidad
select ?ename where {
?prof rdf:type f:prof;
foaf:surname ?ename.
OPTIONAL {?prof f:Nal ?nal}
FILTER (!bound(?nal))
124
ANEXO B – EJEMPLOS DE FUNCIONES DE
AGREGACIÓN
Contar el número de departamentos
select (count(?dept) as ?count) where {
?dept rdf:type f:dept.
}
Contar el número de profesores en cada departamentos
select distinct ?dept (count(?prof) as ?count) where {
?dept a f:dept.
?prof f:Dept ?dept.
} group by ?dept
125
ANEXO C – IMPORTANDO UNA ONTOLOGÍA GLOBAL
(SWRC) A TOPBRAID COMPOSER
1. Abrir TopBraid Composer
2. File -> New -> RDF/OWL File
3. Asignar un nombre al archivo
4. En la ventana de propiedades, clic en la pestaña Import, aparecerá una nueva
ventana pidiendo la dirección url de donde se encuentra depositada la ontología,
que para este caso de estudio es denominada como ontología global. Como se
mencionó anteriormente se eligió la SWRC (Semantic Web for Research
Communities) versión 0.7.1, situada en
(http://ontoware.org/swrc/swrc/SWRCOWL/swrc_updated_v0.7.1.owl) por lo
tanto esta dirección es dada como parámetro.
5. Clic OK
6. La ontología es creada.
126
ANEXO D – IMPORTANDO EXCEL A TOPBRAID
COMPOSER
1. Abrir TopBraid Composer
2. File Import
3. Import Tab-Delimited Spreadsheet File -> Next
4. Seleccionar la ruta donde se encuentra el archivo .xlsx a importar
5. Seleccionar el prefijo para el nombre de las propiedades y la manera en la que se
importarán los caracteres especiales.
6. Se seleccionan las columnas que serán tomadas como las propiedades de la clase
que se creará al finalizar este proceso, así como también el tipo de dato para cada
propiedad de la clase.
7. Cuando exista la posibilidad de juntar tres columnas para una sola propiedad, en
Pattern for instance names, se indica con el símbolo % y el número de las columnas
a juntar,
Por ejemplo:
3- Apellido Paterno 4– Apellido Materno 5– Nombre se quiere crear una sola
propiedad que se llama nombre_completo, entonces se indica en el campo Pattern
for instance names lo siguiente: %3%4%5.
8. Finalmente se le da un nombre a la clase a crear.
9. Clic en el botón <Finish>
127
ANEXO E – IMPORTANDO ONTOLOGIA GLOBAL EN
LA ONTOLOGIA LOCAL
1. Abrir ontología local.
2. En la ventana de propiedades, clic en la pestaña Import, aparecerá una nueva ventana
pidiendo la ubicación donde se encuentra la ontología global.
3. Clic OK.
4. La ontología global fue importada en la local.
128
ANEXO F – INSERCION DE UNA NUEVA CLASE
1. Abrir la ontología en donde se desea insertar la nueva clase, en este caso se abre la
ontología global SWRC.
2. Ubicar el lugar en donde se va a clasificar la nueva clase a insertar.
3. En en área de clases hacer clic en crear una nueva subclase
4. Nombrar la nueva clase
5. Ok
129
EVALUA
TERMINAL
Clave
Ejercicio
Academico
CampusClave Escuela
AdministrativaEscuela Administrativa Division
Clave
Departamento
Materia
Departamento Disciplina Nomina Nombre
SI 201211 Campus Monterrey *No Aplica Escuela
Administrativa
Cadena de
caracteres
(String)
Cadena (1-4
caracteres)
Cadena de
caracteres
(String)
Cadena(1-2
caracteres)L+8 dígitos
Cadena de
caracteres
(String)
NO 201213 EAAD Escuela de Arquitectura, Arte y Diseño
201221 EBS Escuela de Biotecnología y Salud
201224 EITI Escuela de Ingenieria y Tecnologías de Informacion
201242 EMCS Escuela de Medicina y Ciencias de la Salud
201261 EN Escuela de Negocios, Ciencias Sociales y Humanidades
201264
Clave Titulo
Trato
Pais
Nacimiento
Nacionalidad
Pais
Nacimiento
Fecha
Nacimiento
Estatus
Actividad
Profesor
Imparte
Materia
Oficial
Doctorado
Itesm
Maestria
Itesm
Licenciatura
Itesm
Estudia Algun
Grado
Estudia
Grado Itesm
Nivel Grado
Estudia
Fecha
Examen Toefl
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
MexicanaFecha 00-
MES-0000A SI SI SI SI SI SI
Cadena de
caracteres
(String)
Fecha 00-
MES-0000
Alemana NO NO NO NO NO NO
Chilena
China
Nomina TituloTrato Nombre ApellidoPaterno ApellidoMaterno Sexo Nacionalidad CveFormaContrat EstatusJob DescPuesto Cve U.O.Nombre
U.O.
L+8 dígitos Arq.
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
Cadena de
caracteres (String)F Uruguayo OQ A
Cadena de
caracteres
(String)
02+4 dígitos
Cadena de
caracteres
(String)
C.P. M Mexicano RQ
Dr. PC
Dra. PL
Ing.
Lic.
Master
Med.
ANEXO G – ESTRUCTURAS DE TABLAS FUENTE
En este anexo se muestras las estructuras de las fuentes de datos que participaron
el proceso de integración, la cuales son el resultado de una consulta dado una petición de
información.
Tabla Personal
Tabla Personal
130
Puntaje
Examen Toefl
Periodos
Experiencia
Profesor
Categoria
LaboralClave Materia
Nombre
Materia
Nombre
Materia
Ingles
Numero
GrupoCrn
Clave Estatus
Grupo
Total Alum
InscritosNivel Materia
Nivel
Academico
Alumnos
Unidades
Entero EnteroAuxiliar
Planta
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
Entero Entero caracter Entero
Cadena de
caracteres
(String)
Entero Entero
Catedra
Cátedra (Auxiliar)
Media Planta
Obra Determinada de TC Auxilia
Obra Determinada de TC Enseñan
Obra Determinada Tiempo Parcia
Planta
Profesor Virtual
Servicios Profesionales
Null
Horas ClaseHoras
Laboratorio
Ind Materia
Oficial
Ind Grupo
Remedial
Ind Grupo
Terminal
Alumnos
Ind Grupo
Terminal
Ind Grupo
Virtual Idea
Programas
Permitidos
Alumnos
Programas
Actuales
Alumnos
Programas
Terminales
Alumnos
Atributos
Grupo
Leyendas
Grupo
Estatus
Actividad
Prof Grupo
Entero Entero SI SI SI SI SI
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
A
NO NO NO NO NO
Profesor
Titular
Porcentaje
Resp Prof
Grupo
Fecha Asig
Prof Grupo
Fecha Baja
Prof Grupo
Clave
Cumplimient
o Sacs
Cumplimient
o Sacs Ingles
Categoria
Cumplimient
o Sacs
Credencial
Sacs
Desc
Credencial
Sacs
Estatus
Credencial
Sacs
Fecha
Credencial
Sacs
Justificacion
Cumplimient
o Sacs
Nivel Maximo
Estudios
Profesor
SI EnteroFecha 00-
MES-0000Null
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
Cadena de
caracteres
(String)
OQE
Other
Qualification
s
Experential
AFecha 00-
MES-0000
Cadena de
caracteres
(String)
Doctorado
NO Null Null C Null Maestría
Null Profesional
Null
131
ANEXO H – INSTRUMENTO PARA LA APLICACIÓN DE
LA METODOLOGIA A&H PARA NO-ONTOLOGISTAS
En la figura H1 se describen los pasos de cada una de las etapas de la metodología A&H
para no ontologístas.
132
133
134
Figura H1– Diagrama A&H
135
Descripción del instrumento
1. Pregunta
Se refiere a la petición del usuario en términos de los requerimientos. Por ejemplo:
¿Cuántos profesores de tiempo completo hay en el campus Monterrey? La pregunta está
respaldada por una definición que es establecida por el ranking en el que participa la
institución.
2. ¿Sabes que ontología elegir como dominio global?
Seleccionar una ontología de dominio global se refiere a elegir una ontología ya existente
para establecer un dominio general. Dentro del diagrama representado en la figura H3 se
proponen algunas de las ontologías existentes con la finalidad de seleccionar la más
adecuada de acuerdo al dominio y a las necesidades del usuario.
Cada una de las ontologías cumple con un propósito. Para este caso de estudio la más
adecuada es la SWRC v0.7.116
la cual es la versión más actualizada y basada en la
ontología swrc, ya que contiene las clases necesarias para el dominio. También existe
COIN Ontology utilizada en el dominio de comunidades. SemIPort es una ontología
enfocada a la administración de documentos del personal.
3. ¿Sabes cómo importarla?
La actividad de importación se refiere a la adquisición de la ontología para poder
trabajar sobre ella, es decir, tener acceso a la ontología mediante una herramienta de
16 http://ontoware.org/swrc/.
C
136
software, dicha herramienta a manejar para la edición de las ontologías es TopBraid
Composer. Ver procedimiento en Anexo C.
4. ¿El esquema importado cumple con todos los requerimientos para la clasificación
de los datos?
Esta pregunta hace referencia a la ontología que se tomó como esquema global, si dicha
ontología contiene todas las clases y subclases necesarias para la clasificación de la planta
académica. De no ser así, se procede a crear las clases y/o subclases faltantes. El
procedimiento esta descrito en la figura H1 en el paso 4.
5. ¿Cuentas con las fuentes de información suficientes para responder a la pregunta
inicial?
Las fuentes de información son aquellos archivos que contengan los datos necesarios para
la clasificación de la planta académica. De no ser así se requiere solicitar la información a
las personas encargadas de los departamentos convenientes.
6. ¿Los datos tienen el formato adecuado?
Los archivos, también llamados fuentes de datos deberán contar con la información
completa, es decir, sin datos nulos en los campos clave. Los campos clave para este caso de
estudio son aquellos que son útiles para construir las definiciones que servirán para
clasificar la planta académica.
Los campos críticos se enlistan en la tabla H2.
Tabla H2 – Propiedades críticas
137
Fuente Nombre del campo Descripcion
Personal nacionalidad Campo que describe la nacionalidad de un profesor
cveFormaContrat Campo que describe el tipo de contrato de un profesor
tituloTrato Campo que describe el grado académico de un profesor
nomina Campo que describe la clave de un profesor mediante su nómina
RosterMty nacionalidadPaisNacimiento Campo que describe la nacionalidad de un profesor
categoria laboral Campo que describe el tipo de contrato de un profesor
clave Titulo Trato Campo que describe el grado académico de un profesor
nomina Campo que describe la clave de un profesor mediante su nómina
Por lo tanto pues, los archivos no deben contener datos nulos en las propiedades críticas
con las cuales están construidas las definiciones de la planta académica, el campo vacío
deberá ser llenado por la palabra ―Null‖.
7. ¿Los archivos están en formato RDF u OWL?
El formato estándar de una ontología es OWL o RDF, archivos que son leídos por
programas de software destinados a la creación y edición de ontologías, dichos archivos
cuenta con extensión .rdf y .owl.
Los archivos de Microsoft Excel, denominados fuentes de datos, serán convertidos en
formato de ontología (.rdf/.owl).
Los pasos para la conversión de las fuentes de datos a un formato RDF están enlistados en
Anexo E.
Nota: Otra forma más sencilla de importar las ontologías es tomar la ontología (archivo rdf)
y arrastrarla al área de Imports. La figura H3 muestra un ejemplo:
Figura H3 – Ejemplo de importación sencilla
clic
138
8. ¿Ya se construyeron las definiciones?
Para comenzar con este paso, es importante conocer un panorama general (ver figura H6)
de los controles con lo que cuenta TopBraid Composer. Dicha herramienta será utilizada
par a construir las definiciones.
Figura H4 Interfaz de Top Braid Composer version Estandar
Clases: Ventana que permite visualizar el árbol de clases y subclases, así como también
cuenta con controles para añadir, eliminar o editar clases.
Visualización de tareas: Área principal de trabajo en la cual se puede editar una ontología
(definir o modificar recursos) y se construyen definiciones de las clases de manera sencilla.
Esta ventana cuenta con varias pestañas en la parte inferior, mediante las cuales se pueden
hacer otras actividades según se requieran.
Clases
Visualización de
tareas
Propiedades
Instancias, Dominios, SPARQL,
Importaciones, Inferencias. Navegador
139
Propiedades: Ventana que permite visualizar las propiedades con las que cuenta una
ontología, cuenta con controles para añadir o eliminar propiedades.
Navegador: Ventana en la cual se puede navegar a través de todos los proyectos y
archivos.
Instancias, Dominios, SPARQL, Importaciones, Inferencias: Se pueden visualizar
las instancias y dominios, hacer consultas SPARWL, Importar archivos desde la web o
locales, visualizar las inferencias, etc.
Una definición es la descripción semántica de un concepto (clase), la cual es
construida mediante sentencias o constructores propios de los lenguajes RDF y OWL
mediante una herramienta de software. La herramienta utilizada para la edición de
definiciones y ontologías es TopBraid Composer.
Para fines prácticos, la terminología usada en ontologías comparada con la
representación de los datos en un archivo de Microsoft Excel, es la siguiente:
Una tabla equivale a una clase, por lo tanto cada archivo de Microsoft Excel a
integrar formará una clase, por ejemplo: La clase para el archivo Personal.xlsx puede ser
nombrada Person. Una columna equivale a la propiedad de una clase, por lo tanto la
combinación de cada atributo de la clase formarán la definición, por ejemplo:
En la figura H5 se pueden ver las propiedades en el listado de la columna derecha,
las cuales fueron tomadas de los nombre de las columnas del archivo de Excel. Dichas
propiedades pueden manipularse para construir la definición en el área Class Form.
La clase Mexican podrá estar representada gráficamente como se muestra en la
figura H6.
140
Figura H5- Ejemplo de la definición de la clase Mexican
Figura H6. Clase Mexican
La unión de las propiedades con la clase se hace mediante constructores que permiten ir
formando la definición, así como también la unión entre las clases para formar nuevas
definiciones. Algunos constructores utilizados son rdf:subClassOf, owl:equivalenteClass,
owl:intersectionOf. Se pueden ver más ejemplos del uso de los constructores en el capítulo
3.
9. ¿Ya se integró la información?
141
Una vez construidas las definiciones se procede a la etapa de integración. Se
recomienda que antes de la integración se haga la clasificación de cada uno de los archivos
(ontologías locales) para que se verifiquen los resultados correctos. El proceso para
importar las ontologías en una sola denominada ―integradora‖ se sigue el procedimiento
común de importación descritos en los Anexos C y E.
10. ¿Ya se definieron las restricciones?
Las restricciones nos permiten construir delimitaciones o condiciones en las
definiciones. Para este caso de estudio se deben establecer en cada definición un par de
restricciones que aunque parezcan lógicas deben definirse explícitamente.
Por ejemplo, una persona solo tiene una nómina, la cual hace identificar de manera única a
un individuo, por lo tanto existe la necesidad de establecerlo como llave (ver figura H7).
Figura H7 - Restricciones
11. ¿Requieres hacer la clasificación?
Los razonadores son herramientas que nos permiten realizar la clasificación de los
datos. Dichas herramientas trabajan en programas para crear y editar ontologías, (tales
como TopBraid Composer y Protégé) y están conformados por una serie de algoritmos
lógicos para realizar inferencias.
La clasificación o inferencia permite colocar a cada individuo (instancia) en su clase
correspondiente para poder responder a la pregunta inicial. Dicha clasificación es elaborada
142
mediante un programa de software llamado razonador, el cual puede estar adherido a
herramientas que trabajan en la elaboración y edición de ontologías.
De acuerdo al uso de constructores requeridos para construir las definiciones (ver
capítulo 2) se selecciona el razonador que cumpla con la mayoría de los constructores que
se muestran en la tabla 2.4.
Por ejemplo, existe un razonador que arroja resultados deseados y prácticos para este
caso de estudio que trabaja bajo Protegé, el razonador se llama Hermit versión 3.7.1.
Por lo tanto, una vez elaborada la integración se procede a realizar la clasificación la cual
dará como resultados explícitos e inferidos de la información.
Los pasos para elaborar la clasificación son los siguientes:
1.- Abrir el programa Protégé
2.- Importar la ontología integradora Direct import (+)
3. - Import an Ontology contained in a specific Continue
143
4.- Browse – Ubicar la ruta donde se encuentra la ontología integradora
5.- Una vez abierta la ontología integradora dirigirse al menú Run Runing Inference
Hermit
144
6.- Esperar a que haga la inferencia, los tiempos estimados pueden verse en el capítulo
4 sección 4.5.
12. ¿Deseas realizar consultas?
Las consultas son hechas en un lenguaje propio de ontologías llamado SPARQL,
similar al lenguaje de consultas de bases de datos relacionales SQL. Por ejemplo, para
contar el número de profesores internacionales eligiendo la nomina como clave:
SELECT COUNT ( DISTINCT ?nomi)
WHERE {
?prof a global:INTProfessor .
?prof swrc:nomina ?nomi
Donde,
SELECT COUNT: devuelve el resultado numérico de la consulta
DISTINCT ?nomi: cuenta las distintas nóminas
?prof a global:INTProfessor: un profesor es un INTProfessor
1. ¿La consulta responde a la pregunta inicial?
Si la respuesta es SI, el proceso de integración y reconciliación de la metodología
propuesta finaliza, de lo contrario se regresará al paso 5 para verificar que la información
que se está integrando es correcta y suficiente para responder a la pregunta inicial.
145
REFERENCIAS
Allemang, D., & Hendler, J. (2008). Semantic Web for the Working Ontologist.
(ELSEVIER, Ed.). Denise E. M. Penrose.
Arens, Y., Chee, C., Hsu, C., In, H., Knoblock, C. A., & Rey, M. (1996). Query Processing
in an Information Mediator 1 Introduction 2 Representing the Knowledge of a
Mediator, 1–12.
Bakhtouchi, A., Bellatreche, L., Jean, S., & Ait-ameur, Y. (2011). Ontologies as a Solution
for Simultaneously Integrating and Reconciliating Data Sources. IEEE.
Bakhtouchi, A., Bellatreche, L., Jean, S., & Ait-Ameur, Y. (2012, May). Ontologies as a
solution for simultaneously integrating and reconciliating data sources. 2012 Sixth
International Conference on Research Challenges in Information Science (RCIS).
Ieee. doi:10.1109/RCIS.2012.6240431
Bakhtouchi, A., Bellatreche, L., Jean, S., & Ameur, Y. A. (2012). MIRSOFT: mediator for
integrating and reconciling sources using ontological functional dependencies.
International Journal of Web and Grid Services. doi:10.1504/IJWGS.2012.046731
Bakhtouchi, A., Jean, S., & Ait-ameur, Y. (2011). MIRSOFT : Mediator for Integrating
and Reconciling Sources using Ontological FuncTional Dependencies Abdelghani
Bakhtouchi Ladjel Bellatreche St ´ ephane Jean Yamine Ait-Ameur, x(x), 1–38.
Balears, I., & Pol, A. P. (2009). La metodología del Data Mining, 21, 65–80.
Batini, C., & Scannapieca, M. (2006). Data-Centric Systems and Applications. Springer.
Beneventano, D., Bergamaschi, F., Guerra, M., & Vincini. (2001). The MOMIS approach
to Information Integration.
146
Beneventano, D., Bersgamaschi, S., Castano, S., Corni, A., Guidetti, R., & Malvezzi, G.
(2000). Information Integration : the MOMIS Project Demonstration 1 Overview 2
Demonstration, (1), 1–4.
Beneventano, Domenico, & Bergamaschi, S. (2004). THE MOMIS METHODOLOGY
FOR INTEGRATING HETEROGENEOUS DATA SOURCES *, (c).
Benito, O., Cárdenas, O., & Chávez, M. E. (2005). La web semántica, 2(3), 43–54.
Bergamaschi, S., Castano, S., Vincini, M., & Beneventano, D. (2001). Semantic integration
of heterogeneous information sources q, 36(July 1999).
Berners-Lee, T. (2008). Semantic. www.w3.org. Retrieved from
http://www.w3.org/DesignIssues/Semantic.html
Carretero, J. (2007). Introducción a SparQL. Arcoe – Tecnología Software. Retrieved from
http://www.arcoe.es/2007/06/23/introduccion-a-sparql/
Cespivova, H., Tomeckova, M., Rauch, J., & Kejkula, M. (2004). Roles of Medical
Ontology in Association Mining CRISP-DM Cycle.
Chawathe, S., Garcia-molina, H., Hammer, J., Ireland, K., Papakonstantinou, Y., Ullman,
J., & Widom, J. (1994). The TSIMMIS Project : Integration of Heterogeneous
Information Sources, 1–12.
Codina, L., & Rovira, C. (2006). La Web Semántica 1.
Cuenca, B. (2011). Comparison of Reasoners for large Ontologies in the OWL 2 EL
Profile, 1, 1–5.
Date, C. (2001). Introduccion a los Sistemas de Bases de Datos. (P. Hall, Ed.) (Septima
Ed.).
Deved, V. (2002). Understanding Ontological Engineering, 45(4), 136–144.
147
Erlangung, Z., Fridericiana, U., Studer, R., Karlsruhe, U., Weinhardt, C., & Gomez-perez,
A. (2004). Methods and Tools for Ontology Evolution, (August).
F. Noy, N. (2004). Semantic Integration : A Survey Of Ontology-Based Approaches,
33(4), 65–70.
Fayyad, U., Piatetsky-shapiro, G., & Smyth, P. (1996). From Data Mining to Knowledge
Discovery in Databases, 17(3), 37–54.
Gómez-Pérez, A., Fernández-López, M., & Corcho, O. (2004). Ontological Engineering
(pp. 1–45). Springer London.
Gruber, T. R. (1993). A Translation Approach to Portable Ontology Specifications by A
Translation Approach to Portable Ontology Specifications, 5(April), 199–220.
Haase, P., & Stojanovic, L. (n.d.). Consistent Evolution of OWL Ontologies.
Halevy, A., & Ordille, J. (2006). Data Integration : The Teenage Years.
Hull, R., & King, R. (1987). Semantic database modeling: survey, applications, and
research issues. ACM Computing Surveys, 19(3), 201–260. doi:10.1145/45072.45073
Juárez Shiguihara, P. (2009). Un breve panorama sobre las Bases de Datos Semánticas.
Perú.
Kedad, Z., & Métais, E. (2002). Ontology-Based Data Cleaning * Data Cleaning :
Problems and Existing Solutions, 137–149.
Knoblock, C. A., Szekely, P., Ambite, J. L., Gupta, S., Goel, A., Muslea, M., … Mallick, P.
(2011). Interactively Mapping Data Sources into the Semantic Web.
Lenzerini, M., Sapienza, L., Salaria, V., & Roma, I.-. (2002). Data Integration : A
Theoretical Perspective.
148
Maedche, A., Volz, R., & Fzi, F. I. (2001). The Ontology Extraction & Maintenance
Framework ƒ Text-to-Onto.
Mizoguchi, R., & Ikeda, M. (n.d.). Towards Ontology Engineering, 1–10.
Moreno Paredes, A. (2007). Técnicas de depuración e integración de ontologías en el
ámbito empresarial.
Motro, A., Berlin, J., & Anokhin, P. (2004). Multiplex, Fusionplex and Autoplex - Three
Generations of Information Integration. SIGMOD Record, 33(4), 51–57.
Nguyen, H.-Q., Taniar, D., Rahayu, J. W., & Nguyen, K. (2011). Double-layered schema
integration of heterogeneous XML sources. Journal of Systems and Software, 84(1),
63–76. doi:10.1016/j.jss.2010.07.055
Noy, N. F., Doan, A., & Halevy, A. Y. (2005). Integration, 26(1), 7–10.
Park, F., & Naumann, F. (2009). Data Fusion – Resolving Data Conflicts for Integration.
Pastor Sánchez, J. A., & Díaz Ortuño, P. M. (2009). SPARQL Lenguaje de consulta para
RDF. W3C Recomendation. Retrieved from http://skos.um.es/TR/rdf-sparql-
query/#introduction
Perez del Rey, D. (2007). Un modelo de integración y preprocesamiento de información
distribuida basado en ontologías.
Pirrone, R., Russo, G., Sangiorgi, P., Ingraffia, N., & Vicari, C. (2008). A Semantic
Similarity Measure for the SIMS Framework, 285–292.
Ramos, E. (2012). Ingeniería Ontológica.
Rodríguez Mancha, M. de J. (2011). Mapeo de Ontologías para la Sincronización de Bases
de Datos. ITESM,Monterrey.
149
Shadbolt, N., Hall, W., T. B.-L. (2006). No TitleWeb Ontology Language.
Silvescu, A., Reinoso-castillo, J., & Honavar, V. (1997). Ontology-Driven Information
Extraction and Knowledge Acquisition from Heterogeneous , Distributed ,
Autonomous Biological Data Sources Biological Ontologies.
Vel, T., Vel, M. P., Guzm, J. A., & Santander, P. (2011). Ontologias: una tecnica de
representacion de conocimiento Ontologies: a technical of knowledge representation,
8(2).
Wache, H., Vögele, U., Visser, U., Stuckenschmidt, H., Schuster, G., Neumann, H., & H, S.
(2001). Ontology-Based Integration of Information — A Survey of Existing
Approaches, 108–117.
Wang, K., & Zhou, L. (2001). Closed world assumption for disjunctive reasoning. Journal
of Computer Science and Technology, 16(4), 381–387. doi:10.1007/BF02948986
Xu, L., & Embley, D. W. (n.d.). Combining the Best of Global-as-View and Local-as-View
for Data Integration, 1–14.
150
VITA
Alejandra Casas Bayona nació el 25 de Agosto de 1985 en la ciudad de Durango,
Dgo. Es egresada del Instituto Tecnológico de Durango (ITD) en el año 2007 obteniendo su
titulo en la modalidad ―Titulación por Promedio‖. Cursó su educación básica en la misma
ciudad. En su educación media superior obtuvo el título Técnico en Computación por
promedio (2003).
En el 2007, como parte de la experiencia profesional, ingresa a realizar sus prácticas
profesionales en la Secretaria de Finanzas del Gobierno del Estado, en el departamento de
Informática (Soporte) donde fue parte del equipo de desarrollo del Sistema ―Apoyo en el
Desarrollo del Sistema de Gestión de Servicios de TI‖.
A principios del 2008, ingresa a trabajar a DAD (Desarrollo y Aplicaciones de
Durango) empresas dedicada al desarrollo de software, en el departamento de Desarrollo y
Soporte desempeñando el rol de programadora. Después de algunos meses se incorpora al
área Educativa en una institución privada, donde sus roles principales fueron: administrar la
red de la institución, mantenimiento al equipo de cómputo, diseñar papelería para eventos
específicos, impartir clase de computación a nivel Bachillerato y dar asistencia a las clases
de computación de los niveles Primaria y Secundaria .
Fue durante tres años la estancia en ese ámbito, donde también tuvo la oportunidad
de participar en un Diplomado llamado ―Competencias‖.
![[Curso CSS3 com Sass e Compass] Aula 07: Importando outros arquivos Sass](https://img.pdfslide.tips/doc/110x75/548da9e0b479591e1d8b465b/curso-css3-com-sass-e-compass-aula-07-importando-outros-arquivos-sass.jpg)
