desarrollo de un prototipo de una ontologÍa para la...
TRANSCRIPT
PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO FACULTAD DE INGENIERÍA
ESCUELA DE INGENIERÍA INFORMÁTICA
DESARROLLO DE UN PROTOTIPO DE UNA ONTOLOGÍA PARA LA ESCUELA DE INGENIERÍA INFORMÁTICA DE
LA PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO
CLAUDIO ANDRES CASTILLO CISTERNAS
Abril, 2010
TESIS DE GRADO MAGÍSTER EN INGENIERÍA INFORMÁTICA
Pontificia Universidad Católica de Valparaíso Facultad de Ingeniería
Escuela de Ingeniería Informática
DESARROLLO DE UN PROTOTIPO DE UNA ONTOLOGÍA PARA LA ESCUELA DE INGENIERÍA INFORMÁTICA DE
LA PONTIFICIA UNIVERSIDAD CATÓLICA DE VALPARAÍSO
CLAUDIO ANDRES CASTILLO CISTERNAS
Profesor Guía: CLAUDIO CUBILLOS
Programa: Magíster en Ingeniería Informática
Abril, 2010
Resumen
La aplicación de ontologías unifica la terminología de cada concepto y las relaciones entre los conceptos; y
las ontologías de información unifican las estructuras de almacenamiento, de forma que pueden ser
reutilizadas por varias aplicaciones informáticas con la misma fuente de información. Ahora la utilización de
distintas ontologías para diferentes fines, es la clave para poder facilitar las problemáticas que existen hoy en
día con la información y en particular el problema que existe en la Escuela de Ingeniería Informática con los
sistemas desarrollados por los alumnos para ayudar las labores de Docencia y que muy pocas veces son
utilizados, una de las causas que se logran identificar es la falta de un modelo común que permita la
integración e interoperabilidad a nivel semántico.
La creación de una ontología en el dominio de la Escuela de Informática se fundamentado en la
necesidad de establecer un lenguaje común para compartir y recuperar los datos a partir de la descripción de
los conceptos y términos que intervienen en los procesos de gestión de la Escuela. Su finalidad es que estos
conceptos y términos puedan ser entendidos por los distintos usuarios de la información.
La ontología se implemento en el lenguaje OWL con la utilización de la herramienta Protégé para
facilitar la reutilización en el futuro y se utilizó el modelado de procesos de la Escuela para validar la
ontología.
PALABRAS CLAVES: Ontologías, Escuela Ingeniería Informática PUCV, Modelado de Procesos.
Summary
The application of ontologies unites the terminology out of every concept and the relations between the
concepts; And the ontologies of information unite the storage structures, so that they can be used again by
several information-technology applications with the same source of information. Now the utilization of
different ontologies for different intentions, the key is for could have made easy the problems that exists
nowadays with the information and in particular the problem that exists at the School of Information
Engineering with the systems developed by the pupils stops to help the lack of a common model that enable
the integration and interoperability to semantic level is Docencia's works and that very few times are utilized,
you join of the causes that they manage to provide evidence of identity.
The creation of an ontology in the domain of the School of Computing is based on the need to
establish a common language to share and retrieve data from the description of the concepts and terms
involved in the management processes of the school. It is intended that these concepts and terms can be
understood by the various users of information.
The ontology was implemented in the OWL language with the use of the Protégé tool to facilitate
reuse in the future and was used process modeling school to validate the ontology.
KEY WORDS: Ontologies, School Information Engineering PUCV, Modeling of Processes.
CONTENIDOS
1. INTRODUCCION……….………………………………………...………………………...….....1
1.1. DESCRIPCION DEL PROYECTO.…………………….………..………….…........................2
1.2 Definición de Objetivos………………………………………...…….………….....................3
1.3 Planificación del Proyecto……………………………………………….…………..………...3
2. ESTADO DEL ARTE………………………………………………………………......................5
2.1 ¿Qué es una Ontología?.............................................................................................................5
2.2 Los Métodos y Metodologías Para Construir Ontologías…….……………………….………….....7
2.3 Herramientas de Desarrollo de Ontologías…………………….……………………………..…11
2.4 Los Lenguajes de Ontologías…………………………………………….…………………...14
2.5 Aplicaciones de las Ontologías………………………………………….…………….............18
2.6 El Rol de las Ontologías en los SI……………………………………………………..............20
2.6.1 Las Ontologías como Soporte al Análisis Conceptual………………...................21
2.6.2 Las Ontologías como Soporte de los SI…………………………...…………..23
2.6.2.1 Desde la visión del Desarrollador…………………………..............23
2.6.2.2 Desde la Visión del Usuario……………………………….............28
2.7 Integración con Ontologías................................................................................................29
2.7.1 Utilizando una única Ontología.......................................................................30
2.7.2 Utilizando Múltiples Ontologías.....................................................................31
2.7.3 Utilización de Ontologías Hibridas..................................................................32
2.8 Ejemplos de Uso de Ontologías..........................................................................................33
2.8.1 Ontología de Mikrokosmos............................................................................33
2.8.2 KAICO (Kit de ACCESO A Invidentes Con Ontologías).....................................35
2.8.3 Ejemplos de Ontología en el Dominio de la Universidad: “University-Ont”.............36
2.8.3.1 Taxonomia....................................................................................36
2.8.3.2 Relaciones...................................................................................38
3. ESCUELA DE INGENIERIA INFORMATICA .....................................................................39
3.1 Introducción…………………………………………………………………………..39
3.2 Descentralización Administrativa (DA) de Unidades Académicas……………………………39
3.3 Misión y Visión de la Escuela…………………………………………………….……..40
3.4 Estructura y Funciones……………………...…………………………………………..40
3.5 Panorama de la Escuela……………………………………………...…………….........42
3.5.1 Procesos no Automatizados…………………………………………………43
3.5.2 Procesos Automatizados………………………………………………...….43
3.5.2.1 Sistema de Administración de Salas UCV………………………......44
3.5.2.2 Sistema de Consulta de Alumnos Titulados………………………....45
3.5.2.3 Sistema de Apoyo Al Control Académico de una Jefatura de Docencia….46
3.5.2.4 Sistema de Asignación de Horarios de Clases……………………......47
3.5.2.5 Algunas Diferencias entre los Sistemas. …………………………….48
4. MODELADO DE PROCESOS…………………………………...………………………........51
4.1 Importancia del Modelado de Procesos………………………………...……….51
4.2 Metodología para el estudio de Procesos …........……………………………….52
4.3 Modelado con Técnicas Diagramáticos………………………...……………….53
4.4 Uso de los Diagramas para el Modelado de Procesos del Negocio……………….....54
4.4.1 Elementos de los Diagramas de Actividad………………………...…..55
5. DESARROLLO DE LA ONTOLOGIA PARA LA ESCUELA DE IN FORMATICA DE LA
PUCV “ONTO INFO-PUCV” …………………………………………..………………………...58
5.1 Consideraciones y Elecciones de Implementación…………………..……………59
5.1.1 Utilización de Protègè……………………………………………...59
5.1.2 Utilización de Pellet……………………………………………….61
5.1.3 Lenguaje OWL……………………………………………...…….61
5.2 Glosario de Términos………………………………………..……………….62
5.3 Métricas del Modelo OWL Obtenido…………………..……………………....70
5.4 Detalle de parte del código OWL……………………………………………...71
5.5 Taxonomia Conceptual………………………………………...……………..73
5.6 Otras Vistas de la Ontología…………………………………………………..74
6. VALIDACION DE LA ONTOLOGIA MEDIANTE LA DIAGRAMAC ION DE PROCESO
DE LA
ESCUELA…………………………………...……………………………………………………..78
7.- CONCLUSIONES Y TRABAJO FUTURO …………………………………………….....…91
BIBLIOGRAFIA ..............................................................................................................................93
1
1. INTRODUCCION
En la actualidad la Escuela cuenta con una cantidad no menor de sistemas informáticos que han sido
desarrollados para automatizar procesos de Docencia, estos sistemas fueron construidos por alumnos proyectistas
tanto de las carreras de Ingeniería Civil y de Ejecución en Informática.
Muchos de estos sistemas sólo quedan en simples proyectos de titulación y nunca llegan a ser utilizados
para el propósito que fueron desarrollados.
La causa principal por la cual estos sistemas no son utilizados es por la falta de la capacidad de integración
con los sistemas que actualmente son utilizados por Docencia. Una de las causas por las cuales esta integración no se
logra es por la falta de una terminología común y una buena documentación a la cual los futuros desarrolladores
puedan acudir al momento de desarrollar sus sistemas.
Una de las soluciones que se proponen en este documento es el desarrollo de una Ontología, con el fin de
ayudar a los potenciales desarrolladores.
La aplicación de ontologías unifica la terminología de cada concepto y las relaciones entre ellos; y las
ontologías de información unifican las estructuras de almacenamiento de forma que pueden ser reutilizadas por
varias aplicaciones informáticas que utilizan la misma fuente de información.
Una ontología es una taxonomía de conceptos con atributos y relaciones que proporciona un vocabulario
consensuado para definir redes semánticas de unidades de información interrelacionadas. Concretamente, estará
formada por una taxonomía relacional de conceptos y por un conjunto de axiomas o reglas de inferencia mediante los
cuales se podrá inferir nuevo conocimiento. En los últimos años se han desarrollado diversos lenguajes y estándares
para su definición.
La construcción de ontologías lleva implícito que cada término y cada relación entre términos se define
formalmente. Los conceptos se describen explícitamente para entender su significado, mediante acuerdos
ontológicos. Con ello un usuario que desee reutilizar una ontología desarrollada por otros, puede conseguir la
información de todos los conceptos que soporta, su taxonomía y los axiomas.
El objetivo último del desarrollo de ontologías es el de mejorar la representación de la información y los
sistemas de recuperación de información.
En el contexto de la reutilización de la información, una ontología es una descripción de los conceptos
comparable con la especificación formal de un programa informático y de sus asociaciones. Lo que significa que una
ontología proporciona una estructura y unos contenidos que son independientes del fin y del dominio de la aplicación
en la que se reutilizarán sus definiciones.
Para la construcción de una ontología es necesario definir clases, relaciones entre las clases, propiedades y
restricciones sobre las propiedades, para este proceso existen metodologías que imitan el ciclo de vida del SW y
herramientas como Protégé que ayudan a que este proceso resulte más fácil y rápido.
Existen muchos lenguajes para la representación de una ontología y por este motivo en el presente
documento se muestran cuales son estas alternativas y cuales deberían ser los puntos a tener en cuenta al momento de
2
optar por uno de estos, algunos de estos lenguajes son: Ontolingua, CycL, LOOM, Flogic, OCML, OKC, XOL,
OML, SHOE, OIL, DAML+OIL, OWL.
1.1 DESCRIPCION DEL PROYECTO
Durante muchos años en la Escuela de Ingeniería Informática de la Pontificia Universidad Católica de
Valparaíso (PUCV) alumnos han desarrollado sistemas informáticos relacionados con las tareas de Docencia como
Proyectos de Titulo o como trabajos para ciertas asignaturas, pero la realidad muestra que muchos de estos sistemas
no son usados por diversos problemas.
Tratando de encontrar las causas del porque estos sistemas quedan abandonados se han podido identificar
ciertos factores en común:
• Falta de una terminología común, esto hace que los sistemas no puedan ser integrados con los diferentes
sistemas que son usados hoy en día por Docencia de la Escuela. En cambio si esta terminología existiera
cuando se utiliza un término todos los sistemas sabrían qué es lo que representa este término.
• Los sistemas no son capaces de trabajar de manera cooperativa con otros sistemas.
• La documentación existente sobre los sistemas no es lo suficientemente buena, si la documentación fuera lo
suficientemente buena los alumnos que desarrollaran estos sistemas tendrían mas posibilidades de
reutilización y así podrían gozar de todas las ventajas de la reutilización.
Resumiendo los puntos anteriores podríamos decir que el gran problema por lo cual los sistemas quedan
inoperables es porque cada sistema habla su propio lenguaje.
En la Escuela existen muchos procesos que podrían ser automatizados y lo más probable es que estos sean
vistos como posibles proyectos. Ejemplo de esto es que sólo este semestre un par de alumnos se encuentran
desarrollando sistemas para la Escuela. Uno de ellos lo que busca es automatizar el proceso de gestión de las
prácticas profesionales de los alumnos. La idea es que a los futuros sistemas que puedan surgir de proyectos de los
alumnos no queden en sólo un proyecto para aprobar una asignatura sino que sean realmente un apoyo a la docencia
y para esto es fundamental la reutilización.
El ahorro en costes y tiempo que se obtiene en la reutilización del software se logra en mayor medida en la
reutilización de conocimientos, debido al enorme esfuerzo que conllevan los procesos de adquisición de
conocimientos de un dominio, la construcción de su modelo conceptual, y la formalización e implementación de
tales conocimientos.
En 1991, Neches [3] propuso como solución a estos problemas la construcción de sistemas basados en
conocimientos (SS.BB.CC.) uniendo componentes reutilizables, de manera que los desarrolladores de nuevos
sistemas sólo tuvieran que preocuparse de la creación de conocimientos especializados y de desarrollar nuevos
razonadores para la tarea específica de su sistema. Los nuevos sistemas interoperarían con los sistemas existentes,
3
compartiendo así sus conocimientos y métodos de razonamiento. El conocimiento declarativo incluido en ontologías,
las técnicas de resolución de problemas y los métodos de razonamiento podrían estar en los sistemas compartidos,
proporcionando sistemas mejores y más baratos de construir. El objetivo es construir sistemas utilizando
conocimientos y métodos de razonamiento, en vez de desarrollarlos desde la nada. De esta propuesta nace la idea de
desarrollar una Ontología para la Escuela.
La Ontología de la Escuela Ingeniería en Informática tendrá como propósito lograr la interoperabilidad de
los sistemas de información, además de la ya mencionada reutilización del conocimiento. La ontología considerará
los elementos necesarios para ayudar a potenciales desarrolladores.
La creación de la ontología busca permitir crear un entendimiento compartido al unificar los diferentes
puntos de vista y servir para:
• Facilitar la comunicación entre los actores implicados en la construcción de los SI.
• Permitir el reutilización del conocimiento de un dominio.
• Facilitar la recuperación, integración e interoperatividad entre fuentes de conocimiento heterogéneas.
• Proveer una base para la representación del conocimiento del dominio y ayudar a identificar las categorías
semánticas del dominio.
Lo que se busca con el desarrollo es disponibilidad del conocimiento almacenado en ontologías para
proveer los mecanismos necesarios para organizar, almacenar y acceder a la información de ítems que incluyen
esquemas de BD, objetos de interfaz de usuario, y programas de aplicación.
1.2. Definición de Objetivos
El objetivo general del proyecto consiste en “Desarrollar un Prototipo de una Ontología para el Dominio de la
Escuela de Ingeniería Informática”.
Los siguientes objetivos son de carácter específico, necesarios para la realización del objetivo general.
• Investigar el estado del arte, realizando estudios de metodologías para el desarrollo de la ontología.
• Establecer la(s) herramienta(s) de desarrollo adecuada para el diseño e implementación de la ontología.
• Construir el Prototipo de la Ontología.
• Validar y Evaluar el desempeño de la ontología a través del diseño de representaciones de los procesos
involucrados en el funcionamiento de la Escuela.
1.3. Planificación del Proyecto
Se pretenderá realizar el proyecto mediante la utilización de la metodología “Methontology” [1]. Methontology imita
el ciclo de vida del software propuesto en el estándar IEEE 1074 [2], estableciendo las etapas principales siguientes:
1. Planificación.
2. Especificación (de los requisitos) de la ontología.
4
3. Conceptualización, es decir, la ontología propiamente dicha (equivalente al diseño en un sistema
software).
4. Implementación, es decir, representación y almacenamiento de la Conceptualización anterior mediante el
uso de alguna herramienta informática.
5
2. ESTADO DEL ARTE
2.1. ¿Qué es una ontología?
La palabra ontología fue tomada de la Filosofía, donde quiere decir una explicación sistemática de ser. En la última
década, la palabra ontología se convirtió en una palabra significativa para la comunidad Knowledge Engineering. He
leído muchas definiciones acerca de lo que es una ontología y en esta sección, revisaremos las definiciones y
explicaremos las relaciones entre ellas.
Una de las primeras definiciones fueron dadas por Neches [3], quien definió una ontología como sigue:
“Una ontología define los términos y relaciones básicas que comprenden el vocabulario de un área temática, así
como también las reglas para combinar los términos y las relaciones para definir extensiones del vocabulario”. Esta
definición descriptiva dice que hacer para fortalecer una ontología, y nos da algunas ideas directivas vagas: La
definición identifica términos básicos y relaciones entre los términos, identifica reglas para combinar términos, y
provee las definiciones de tales términos y relaciones. Note que, según la definición de Neches, una ontología
incluye no solo los términos que están explícitamente definidas en ella, sino que también el conocimiento que puede
ser inferido de eso.
Unos pocos años más tarde, Gruber [4] definió una ontología como “una especificación explicita de una
conceptualización”. Esta definición se volvió la citada en la mayor parte de la literatura y por la comunidad
ontológica. Basadas en la definición de Gruber, muchas definiciones de ontologías han sido propuestas. Borst [5]
modifico ligeramente la definición de Gruber: “Las ontologías son definidas como una especificación formal de una
conceptualización compartida”. Las definiciones de Gruber y Borst han sido mancomunadas y clarificadas por
Studer[6] como sigue: “La conceptualización se refiere a un modelo abstracto de algún fenómeno en el mundo,
habiendo identificado los conceptos pertinentes de ese fenómeno. Se explicita que tipos de conceptos son usados, y
las restricciones en su uso están explícitamente definidas. Formal se refiere al hecho de que la ontología debería ser
legible por una maquina”. En 1995, Guarino y colegas [7] recolectaron y analizaron siete definiciones de ontologías
y proveyeron sus correspondientes interpretaciones sintácticas y semánticas. En ese escrito, los autores propusieron
considerar una ontología como “una teoría lógica que da una rendición de cuentas parcial explicita, de una
conceptualización”, donde la conceptualización es básicamente una idea del mundo que una persona o unos grupos
de personas pueden tener. Aunque en la noción de conceptualización es realmente similar a la de Studer, podemos
decir que Guarino dio un paso más adelante porque estableció cómo construir la ontología haciendo una teoría
lógica. Por lo tanto, en rigor, esta definición sería sólo aplicable a las ontologías desarrolladas en la lógica.
También existe otro grupo de definiciones basadas en el proceso seguido para construir la ontología. Estas
definiciones también incluyen algunos puntos de interés acerca de la relación entre las ontologías y las bases del
conocimiento. Por ejemplo, la definición dada por Bernaras [8] en el marco de trabajo del proyecto KACTUS [9]:
"Una ontología provee la manera de describir explícitamente la conceptualización detrás de la representación del
conocimiento en una base de conocimiento". Note que esta definición propone “extraer” la ontología de una base de
conocimiento (KB), lo cual refleja el acercamiento con que los autores suelen construir las ontologías. En este
6
acercamiento, la ontología se construye, con una estrategia bottom-up, con base en un KB aplicativo, por medio de
un proceso de abstracción.
Otra estrategia para la construcción de ontologías sería reusar las ontologías, SENSUS [10] (la metodología
Sensus con más que 70,000 conceptos es un enfoque top-down para derivar ontologías específicas del dominio a
partir de grandes ontologías) para dominios específicos de KBs y ontologías: “Una ontología es un conjunto
jerárquico estructurado de condiciones para describir un dominio que puede ser usado como un esqueleto para una
base de conocimiento”. Según esta definición, la misma ontología puede servir para construir varios KBs, que
comparten el mismo esqueleto. Las extensiones del esqueleto deberían ser posibles a un nivel más bajo añadiendo
subconceptos de un dominio específicos, o a un nivel más alto añadiendo conceptos intermedios o superiores que
cubren áreas nuevas. Si los sistemas se construyen con la misma ontología, entonces comparten una estructura
subyacente, por consiguiente, podrán anexar y compartir sus KBs y los mecanismos de inferencia se volverán más
fáciles.
Las ontologías sirven ampliamente para diferentes propósitos (procesamiento del lenguaje natural,
administración del conocimiento, comercio electrónico, integración inteligente de la información, Web semántica,
etc.) en diferentes comunidades (por ejemplo, La ingeniería del conocimiento, las bases de datos y el diseño de
software), Uschold y Jasper [11] dieron una definición nueva de la palabra ontología para popularizarla en otras
disciplinas. Uschold y Jasper definieron una ontología como sigue: “Una ontología puede tomar una variedad de
formas, pero necesariamente incluir un vocabulario de condiciones y alguna especificación de su significado. Esto
incluye definiciones y una indicación de como están relacionados los conceptos los cuales colectivamente impone
una estructura al dominio y restringen las posibles interpretaciones”.
En esta sección se han coleccionado la mayor cantidad de definiciones pertinentes, aunque hay otras
definiciones de la palabra “ontología” en la literatura. Sin embargo, podemos decir que hay consenso entre la
comunidad ontológica y no hay confusión acerca de su uso. Las definiciones dan diferentes puntos de vista y
complementarios de la misma realidad. Algunos autores dan definiciones que son independientes de los procesos de
construcción de la ontología y también independiente de su uso en aplicaciones, mientras otras definiciones son
influenciadas por el proceso de desarrollo de construcción de las ontologías. Como conclusión principal para esta
sección, podemos decir que las ontologías apuntan hacia la captura del conocimiento consensual en una forma
genérica y formal, y que pueden ser reusadas y compartidas a través de aplicaciones (el software) y por grupos de
gente. Las ontologías se forjan usualmente cooperativamente por un grupo de gente.
Ahora como elementos que constituyen una ontología, se pueden distinguir:
• Conceptos: son las ideas a formalizar. Pueden ser clases de objetos, métodos, planes, estrategias, procesos
de razonamiento, etc.
• Relaciones: van a representar las interacciones entre los conceptos. Suelen formar la taxonomía del
dominio.
• Funciones: son relaciones donde se identifican elementos mediante el cálculo de una función que considera
varios elementos de la ontología (Promedio).
• Instancias: se utilizan para representar objetos determinados de un concepto.
7
• Axiomas: van a ser teoremas declarados sobre relaciones que deben cumplir los elementos de una
ontología. Los axiomas, junto con la herencia de conceptos, permiten inferir conocimiento que no esté
indicado explícitamente en la taxonomía de conceptos.
Figura 1: Ejemplo de Ontología (Animal).
2.2. Los métodos y Metodologías Para Construir Ontologías
Una serie de avances han sido reportados para desarrollar ontologías. En 1990, Lenat y Guha publicaron los pasos
generales [12] y algunas proposiciones interesantes acerca del C&C. Algunos años más tarde, en 1995, con base en
la experiencia desarrollaron el Enterprise Ontology [13] y la ontología del proyecto TOVE (Toronto Virtual
Enterprise) [14] (ambos en el dominio del modelado de empresa), las primeras líneas directivas fueron propuestas y
más tarde refinadas. En la 12º Conferencia Europea para la Inteligencia Artificial (ECAI’96), Bernaras presento un
método usado para construir una ontología en el dominio de redes eléctricas como parte del proyecto Esprit
KACTUS. La metodología METHONTOLOGY [15] apareció en el mismo tiempo y fue extendido más tarde. En
1997, un nuevo método fue propuesto para la construcción de ontologías basadas en la ontología SENSUS. Algunos
años más tarde, apareció la metodología On-To-Knowledge como resultado del proyecto con el mismo nombre [16].
Sin embargo, todos estos métodos y estas metodologías no consideran la construcción colaborativa y distribuida de
ontologías. El único método que incluye una propuesta para la construcción colaborativa es CO4 [17]. Este método
incluye un protocolo para que nuevas partes de conocimiento concuerden con el resto de la arquitectura de
conocimiento, lo cual se ha acordado previamente. Un estudio comparativo y detallado de estos métodos y las
metodologías puede ser encontrado en [18].
8
Todos los métodos previos y las metodologías fueron propuestos para construir ontologías. Sin embargo,
muchos otros métodos y metodologías han sido propuestos para otras tareas, algo semejante como la reingeniería de
ontologías, el aprendizaje de ontologías, evaluación de ontologías, evolución de ontologías, la unión de ontologías,
etc. En esta sección, sÓlo nos enfocaremos en metodologías para la construcción de ontologías.
El método usado para construir el Cyc KB consta de tres fases. La primera fase consta de la codificación
manual de artículos y partes de conocimiento, el conocimiento de sentido común esta implícito en diferentes fuentes
el cual es extraído a mano. La segunda y la tercera fase constan de una adquisición de conocimiento nuevo de sentido
común usando herramientas de lenguaje natural o de aprendizaje de maquina. La diferencia entre ellos es que en la
segunda fase ésta adquisición de conocimiento de sentido común es auxiliada por herramientas, pero principalmente
por humanos, mientras en la tercera fase la adquisición es principalmente realizada por herramientas.
En los métodos Uschold y el de King’s [13] se declaran cuatro actividades: (1) identificar el propósito de la
ontología, (2) construirla, (3) evaluarla, y (4) documentarla. Durante la actividad de la construcción, los autores
proponen captar conocimiento, codificarlo e integrar otras ontologías dentro de la actual. Los autores también
proponen tres estrategias para identificar los conceptos principales en la ontologías: Una estrategia descendente, en la
cual la mayor parte de los conceptos abstractos son identificados primero, y luego, especializarse en los conceptos
más específicos; Un enfoque ascendente, en el cual la mayor parte de conceptos específicos son identificados
primero y luego se generalizan en conceptos más abstractos; Y un acercamiento middle-out , en el cual la mayor
parte de los conceptos importantes son identificados primero y luego se generaliza y se especializa en otros
conceptos.
Grüninger y Fox [14] proponen una metodología que se inspira en el desarrollo de sistemas basados en
conocimientos usando lógica de primer orden. Ellos proponen primero identificar intuitivamente los principales
escenarios (posibles aplicaciones en donde la ontología puede ser usada). Luego, un conjunto de preguntas naturales
de lenguaje, llamadas preguntas de aptitud, se usan para determinar el alcance de la ontología. Estas preguntas y sus
respuestas son usadas para extraer los conceptos principales, sus propiedades, relaciones y axiomas de la ontología.
Tales componentes de la ontología están formalmente expresados en la lógica de primer orden. Por consiguiente, éste
es un método muy formal que toma las ventajas de la robustez de la lógica clásica. Puede ser usado como una guía
para transformar escenarios informales en los modelos computacionales.
En el método propuesto en el proyecto KACTUS, la ontología se construye en base a una aplicación KB,
por medio de un proceso de abstracción (después de una estrategia bottom-up). Mientras más aplicaciones se
construyen, más general la ontología se convierte; por lo tanto, la ontología se aleja de un KB. En otras palabras, se
propone empezar a construir un KB para una aplicación específica. Más tarde, cuando un nuevo KB es necesario en
un dominio similar, se propone generalizar el primer KB en una ontología y adaptarlo para ambas aplicaciones.
Aplicando este método recursivamente, la ontología representara el conocimiento consensual necesitado en todas las
aplicaciones.
El método basado en Sensus es una estrategia descendente para derivar el dominio de ontologías específicas
de ontologías enormes. Los autores proponen identificar un conjunto de términos “semillas” que son pertinentes para
un dominio particular. Estos términos son conectadas manualmente a una ontología de amplia cobertura (en este
9
caso, la ontología Sensus, contiene más de 70,000 conceptos). Luego, todos los conceptos en el camino de los
términos de la semilla a la raíz de SENSUS son incluidos. Si un término que podría tener importancia en el dominio
aún no ha aparecido, entonces se agrega manualmente, y el paso previo es realizado otra vez, hasta que ningún
término falte. Finalmente, para esos nodos que tienen un número grande de caminos a través de ellos, el subárbol
entero bajo el nodo es añadido, basado en la idea que si muchos de los nodos en un subárbol son encontrados estos
tienen importancia, luego, los otros nodos en el subárbol probablemente serían relevantes. Consecuentemente, este
acercamiento promueve el compartir el conocimiento, desde que la misma ontología base se usa para desarrollar
ontologías en dominios particulares.
METHONTOLOGY [19] es una metodología, creada en el Laboratorio de Inteligencia Artificial de la
Universidad Técnica de Madrid (UPM), para la construcción de ontologías ya sea desde la nada, reusando otras
ontologías, o por un proceso de reingeniería. El marco de trabajo METHONTOLOGY posibilita la construcción de
ontologías según el nivel de conocimiento. Incluye: La identificación del proceso de desarrollo de la ontología, un
ciclo de vida basado en desarrollar prototipos (mostrado en la Figura 2), y las técnicas particulares para llevar a
cabo cada actividad. El proceso de desarrollo de la ontología identifica cuales tareas deberían ser realizadas al
construir la ontología (la planificación, el control, la comprobación de calidad, la especificación, la adquisición de
conocimiento, la conceptualización, la integración, la formalización, la implementación, la evaluación, el
mantenimiento, la documentación y la administración de configuraciones). El ciclo de vida identifica las etapas a
través de las cuales la ontología pasa durante su duración de su vida, así como también las interdependencias con el
ciclo de vida de otras ontologías. Finalmente, la metodología especifica que técnicas que se usaron en cada
actividad, los productos que cada actividad devuelve y como tienen que ser evaluados. La fase principal en el
proceso de desarrollo de la ontología usando el acercamiento METHONTOLOGY es la fase de conceptualización.
Las herramientas como WebODE [20,21] y la ODE [22] proveen soporte para METHONTOLOGY. Sin embargo,
otras herramientas pueden también usarse para desarrollar ontologías siguiendo esta metodología.
10
Figura 2: Ciclo de vida de una ontología en METHONTOLOGY.
La metodología On-To-Knowledge incluye la identificación de metas que deberían ser logradas por
herramientas de administración del conocimiento y se basa en un análisis de escenarios de uso. Los pasos propuestos
por la metodología son: El kick-off, donde los requisitos de la ontología son captados y especificados, las preguntas
de aptitud son identificadas, las ontologías potencialmente reusables son estudiadas y una primera versión en
borrador de la ontología se desarrolla; El refinamiento, donde una ontología madura y de orientación aplicativa se
produce; La evaluación, donde los requisitos y las preguntas de aptitud son comprobados, y la ontología es probada
en el ambiente aplicativo; Y el mantenimiento de la ontología.
Finalmente, CO4 es un protocolo para lograr un consenso entre varios KBs, los cuales son organizados en
un árbol. Las hojas son llamadas usuario KBs, y los nodos intermedios, grupos KBs. Los usuarios KBs no necesitan
tener conocimiento consensual. En cada nodo intermedio, hay conocimiento consensuado entre todos sus hijos y sus
hermanos. El consenso de conocimiento es logrado por el cambio de mensajes entre usuarios.
En esta sección, hemos presentado varias metodologías y métodos para el desarrollo de ontologías. Por
ejemplo, si comparamos al KACTUS y el método Sensus, entonces en el primero la ontología es fortalecida por
medio de un proceso de abstracción de una base inicial de conocimiento, mientras en el segundo el esqueleto de la
ontología es automáticamente generado de una gran ontología. Los otros métodos y las otras metodologías pueden
servir para desarrollar ontologías, ya sea desde la nada o reusar otras ontologías.
Estos avances pueden ser comparados en cuento al grado de dependencia de la ontología desarrollada y su
aplicación final. En este sentido, podemos concluir: (a) el método usado en el proyecto KACTUS y la metodología
del On-To-Knowledge son dependiente de la aplicación, desde que la ontología se desarrolla con base en una
11
aplicación dada; (b) la metodología de Grüninger y Fox y el método basada en Sensus son medio dependientes en la
aplicación; (c) los métodos Cyc y Uschold King, y la metodología METHONTOLOGY son independientes en la
aplicación, desde que el proceso de desarrollo de ontología es completamente independiente de los usos de la
ontología.
Según el análisis previo y el trabajo reportado en [18], podemos concluir:
• Ninguno de los acercamientos presentados están maduros si los comparamos con metodologías de
ingeniería del software y de ingeniería del conocimiento. Como se resume en la Tabla 1 del anexo 1,
muchas actividades cruciales no están propuestas para la mayor parte de ellos. El acercamiento más maduro
es METHONTOLOGY, lo cual ha sido recomendado por FIPA para la tarea de construcción de ontologías.
• Las propuestas actuales no son unificadas: Cada grupo aplica su propio acercamiento. Consecuentemente, el
gran esfuerzo es precisado para crear una metodología consensuada para la construcción de ontologías.
• La colaboración entre diferentes grupos para unificar sus avances parece ser la más razonable forma de
lograrla.
2.3. Herramientas de desarrollo de Ontologías
En los últimos años, el número de ambientes y herramientas para la construcción de ontologías han crecido
exponencialmente. Estas herramientas están dirigidas al suministro de soporte para el proceso de desarrollo de las
ontologías y para el subsiguiente uso de las ontologías. En esta sección, son presentados los más pertinentes.
El Ontolingua Server [23] fue la primera herramienta de creación de ontologías. Fue desarrollado en el
Knowledge Systems Laboratory (KSL) en Stanford University. El Ontolingua Server apareció en los 1990s, y fue
creado para aliviar el desarrollo de ontologías Ontolingua con una aplicación basada en la Web. Inicialmente, el
modulo principal dentro de Ontolingua Server fue el editor de ontologías, luego otros módulos fueron incluidos en el
ambiente, algo semejante a un Webster, una maquina para resolver ecuaciones, un servidor OKBC (Open
Knowledge Based Connectivity), Chimaera (una herramienta de unión de ontologías) [24], etc. El editor de
ontologías también provee los traductores para los lenguajes, algo semejante como Loom, Prolog, CORBA’s IDL,
CLIPS, etc. Los editores remotos pueden hacer una lectura ligera y pueden revisar ontologías, y las aplicaciones
remotas o locales pueden tener acceso a cualquiera de las ontologías en la biblioteca de ontologías con el protocolo
OKBC [25].
Al mismo tiempo, Ontosaurus fue desarrollado por el Information Sciences Institute (ISI) de la University
of South California. OntoSaurus consta de dos módulos: Un servidor de ontologías, que usa Loom como su sistema
de representación de conocimiento, y un navegador Web para las ontologías Loom. Los traductores desde Loom a
Ontolingua, KIF, KRSS y C++ están disponibles. Las ontologías OntoSaurus pueden ser también accedidas con el
protocolo OKBC.
12
En 1997, el Knowledge Media Institute (KMI) de la Open University desarrollo el Tadzebao y WebOnto
[26]. WebOnto es un editor de ontologías para ontologías OCML. Su principal ventaja sobre otras herramientas
disponibles es que respalda la edición de ontologías colaborativamente.
La principal similitud entre dichos ambientes es que todos ellos tienen una estrecha relación con un lenguaje
especifico (Ontolingua, LOOM y OCML, respectivamente). Realmente, fueron creados para permitir hacer una
lectura y revisión ligera y fácil de las ontologías en esos lenguajes. Además, estaban estrictamente orientados para
analizar actividades y la mayor parte de a ellos se desarrollaron como herramientas aisladas que no proveyeron
mucha extensibilidad.
En los últimos años, una nueva generación de ambientes de ingeniería de ontologías ha sido desarrollada.
Los criterios del diseño de estos ambientes son mucho más ambiciosos que los de las herramientas mencionadas.
Han sido creados para integrar tecnología de ontología en los sistemas de información reales. De hecho, se
desarrollaron como ambientes integrados robustos o suites que proveen soporte tecnológico a la mayor parte de las
actividades del ciclo de vida de las ontologías. Tienen arquitecturas extensibles, basadas en componentes, donde los
nuevos módulos pueden fácilmente agregarse para proveer más funcionabilidad al ambiente. Además, el
conocimiento modelado bajo estos ambientes es lenguaje independiente. Entre estos ambientes, podemos hablar de
Protégé 2000, WebODE y OntoEdit.
El recomendado Protégé 2000 [27] ha sido desarrollado por el Stanford Medical Informatics (SMI) de la
Stanford University, y es la última versión de la línea de herramientas Protégé. Es una fuente abierta, es una
aplicación auto sostenible con una arquitectura extensible. El corazón de este ambiente es el editor de ontologías, y
una biblioteca de plugins que añaden más funcionabilidad al ambiente.
WebODE es el sucesor de ODE (Ontology Design Environment), y ha sido desarrollado en el Laboratorio
de Inteligencia Artificial de la Universidad Técnica de Madrid (UPM). Es también una suite de ingeniería de
ontologías creada con una arquitectura extensible. WebODE no es utilizado como una aplicación auto sostenible,
pero si como un servidor Web con una interfaz Web. Las ontologías de WebODE son almacenadas en una base de
datos relacional. Finalmente, WebODE cubre y da soporte a la mayor parte de las actividades complejas en el
proceso de desarrollo de ontologías declaradas por METHONTOLOGY, aunque esto no lo impide ser usado con
otras metodologías o sin seguir cualquier metodología.
OntoEdit [28] ha sido desarrollado por AIFB en la Karlsruhe University. Es similar a las herramientas
previas: Es un ambiente extensible y flexible, basado en una arquitectura de plugins, lo cual provee funcionabilidad
para editar ontologías. Incluye plugins que se encargan de inferir usando Ontobroker [29], de exportar e importar en
diferentes formatos (FLogic, XML, RDF(s), DAML+OIL), etc. Dos versiones de OntoEdit están disponibles:
OntoEdit Free y OntoEdit Professional. Recientemente, la suite de la herramienta KAON (Karlsruhe Ontology) ha
sido desarrollada como el sucesor de OntoEdit.
Finalmente, con el surgimiento de la Web Semántica, las herramientas para el desarrollo de DAML+OIL y
ontologías RDF(s) fueron proliferando. De hecho, las suites previas (Protégé 2000, el WebODE y OntoEdit)
permiten tener importar y exportar las ontologías de DAML+OIL y RDF(s). Hay también varias herramientas
13
aisladas que crean ontologías DAML+OIL de diferentes perspectivas; El mayor representante es: OILEd (una
herramienta basada en DL), y DUET (un plugin basado a UML para Rational Rose).
OILEd [30] fue inicialmente desarrollado como un editor de ontologías para ontologías OIL, en el contexto
del proyecto europeo IST del On-To-Knowledge. La Universidad de Manchester, la Universidad Libre de
Ámsterdam e Interprice GmbH participaron de este desarrollo. Sin embargo, OILEd ha evolucionado y ahora es un
jefe editor de ontologías DAML+OIL. Los usuarios de OILEd pueden conectarse a la maquina de inferencias FaCT
[31], la cual provee de inspecciones de consistencia y la clasificación automática de conceptos. OILEd también
provee varias opciones de documentación (HTML, visualización gráfica de ontologías, etc.).
DUET [32] fue desarrollado por AT&T Government Solutions Advanced Systems Group. Ofrece una
visualización UML y ambiente de desarrollo para DAML+OIL, lo cual es integrado como un plugin en la suite de
Rational Rose. El corazón de los conceptos DAML+OIL están siendo mapeados a UML a través de un perfil UML
para DAML+OIL. Esta herramienta no es pretendida para la ingeniería del conocimiento sino para diseñadores de
base de datos e ingenieros de sistemas, quienes pueden modelar sus ontologías con UML y luego las pueden traducir
en DAML+OIL, lo cual puede ser aplicado para los sistemas del software que desarrollan. Esta no es la única
herramienta que es integrada como un plugin en la suite de Rational Rose; Por ejemplo, el Medius Visual Ontology
Modeller (VOM) [33] ha sido también creado de modo semejante.
Muchas otros prototipos de herramientas relacionadas en ontología existen hoy día: Hay herramientas
especializadas en el anexo de ontologías (Chimaera, Protégé-PROMPT), la traducción de ontologías entre lenguajes
(Ontomorph [34]), la anotación de paginas Web basada en ontologías (COHSE, OntoMat, SHOE Knowledge
Annotator), la evaluación de ontologías (OntoAnalyser, ONE-T, ODEClean), motores de consulta RDF (RDFSuite,
Sesame, Inkling, Jena, etc.), etc. Esta sección se enfocara en las herramientas de desarrollo de ontologías.
A continuación se presentan algunas conclusiones acerca de las herramientas mostradas anteriormente,
resultados están resumidos en la Tabla 2 del anexo 1. Se han comparado todas estas herramientas con relación al
mismo marco de trabajo de evaluación. Esta comparación ha sido realizada en el contexto del grupo SIG en
Enterprise-Standard Ontology Environments de la red temática OntoWeb, y es publicado en su entregable D1.3
entregable (‘‘Asurvey on ontology tools’’) [35].
Del punto de vista del paradigma KR, hay dos familias de herramientas. El OILEd y OntoSaurus, las cuales
son herramientas basadas en descripción lógica, y el resto de las herramientas, que permiten representar el
conocimiento entendiendo un acercamiento hibrido basado en marcos y la lógica de primer orden. La expresividad
del modelo subyacente de conocimiento de la herramienta es también importante. Todas las herramientas permiten
representar clases, particiones, relaciones, atributos, instancias y axiomas. Sin embargo, solo Ontolingua Server,
Ontosaurus y Protégé 2000 proveen componentes flexibles de modelado como las metaclases. Antes de seleccionar
una herramienta para desarrollar una ontología, es importante saber los servicios de inferencia que la herramienta
incluye.: La restricción y los mecanismos de comprobación de consistencia, el tipo de clasificaciones de la herencia
(simple, múltiple), clasificación automáticas, excepciones de manipulando y la ejecución de procedimientos.
Podemos decir que Ontolingua Server y Protégé 2000 no tiene un motor de inferencias. OILEd realiza inferencias
usando el motor de inferencias FAC, OntoEdit usa Ontobroker, Ontosaurus usa el clasificador Loom [36], WebODE
14
usa Ciao Prolog [37] y WebOnto usa OCML [38]. Además, Ontosaurus y WebODE proveen instalaciones de
evaluación. WebODE incluye un modulo que realiza evaluaciones de ontologías según el método OntoClean. OILEd
y OntoSaurus son los únicos que realizan clasificaciones automáticas, basándose en los lenguajes de de descripción
lógica (DL). Finalmente, ninguna de las herramientas provee mecanismos de manejo de excepciones.
Otro aspecto importante es la evolución de la arquitectura del software y de la herramienta, lo cual considera
que hardware y plataformas de software son necesarias para usar la herramienta, su arquitectura (standalone, cliente/
servidor, aplicación n-tier), su extensibilidad, el almacenamiento de las ontologías (bases de datos, archivos ASCII,
etc.), tolerancia a fallas, administración de backup, la estabilidad y las políticas de manejo de versiones de la
herramienta. De esa perspectiva, la mayor parte de las herramientas se mueven hacia plataformas Java: WebOnto,
OILEd, OntoEdit, Protégé 2000 y WebODE. El almacenamiento en bases de datos es aun un punto débil de las
herramientas ontológicas, unos cuantos de ellos usan bases de datos para almacenar las ontologías: La versión
comercial del OntoEdit, la de Protégé 2000 y WebODE. La funcionabilidad de administración de backup esta
simplemente prevista por WebODE, y las instalaciones de extensibilidad de OntoEdit, Protégé 2000 y WebODE.
La interoperabilidad con otras herramientas de desarrollo de ontologías, las herramientas de anexado,
sistemas de información y bases de datos; Así como traducciones para y de algunos lenguajes de ontologías es otro
rasgo importante para integrar aplicaciones de ontologías. La mayor parte de las herramientas nuevas exportan y
tienen importación para XML y otros lenguajes de marcado. Sin embargo, no hay un estudio comparativo acerca de
la calidad de todos estos traductores. Además, no hay resultados empíricos acerca de la posibilidad de intercambiar
ontologías entre diferentes herramientas y acerca de la cantidad de conocimiento que se pierde en los procesos de
traducción.
Respecto a la metodología a la que la herramienta da soporte, WebODE da soporte a METHONTOLOGY,
y OntoEdit da apoyo a On-To-Knowledge. Sin embargo, ninguna de las herramientas analizadas incluyen: La
administración del proyecto, (semi) automática adquisición de conocimiento, el mantenimiento y proveen poco
soporte para la verificación de ontologías.
Relacionado con la construcción cooperativa y colaborativa de ontologías, WebOnto tiene características
que le dan una ventaja. En general, más características son necesarias para asegurar la construcción colaborativa
exitosa de ontologías. Finalmente, los aspectos Usabilidad guardan relación con sistema de ayuda, edición y
visualización, etc., Esta característica debería ser mejorada adentro en la mayor parte de las herramientas.
2.4. Los Lenguajes de Ontologías
A principios de los 1990s, un conjunto de lenguajes para la implementación de ontologías basados en IA fueron
creados. Básicamente, bajo el paradigma KR tales lenguajes de ontologías se basan en la lógica de primer orden (ej.
KIF), sobre marcos combinados con lógica de primer orden (ej. Ontolingua, OCML y FLogic) o en DL (ej. Loom).
KIF [39] es un lenguaje basado en la lógica de primer orden creado en 1992 como un formato de
intercambio para diversos sistemas KR. Ontolingua, que se fundamenta en KIF, fue desarrollada en 1992 por el KSL
en la Stanford University. Combina los paradigmas KR y el cálculo de predicado de primer orden (KIF). Es el más
15
expresivo de todos los lenguajes que han servido para representar ontologías, representa de conceptos, las
taxonomías de conceptos, funciones, axiomas, instancias y procedimientos. Su alta expresividad condujo a
dificultades en mecanismos de creación de razonamiento para este. Por lo tanto, ningún soporte razonador es
provisto para el lenguaje.
Loom fue desarrollado simultáneamente con Ontolingua en el Instituto de Ciencias de la Información (ISI)
en la University of South California. Inicialmente, no fue pensado para implementar ontologías, sino que para KBs
generales. Loom se basa en DL y la producción de reglas, y provee clasificaciones automáticas de conceptos. Los
siguientes componentes de ontologías pueden ser representados con este lenguaje: Los conceptos, las taxonomías de
concepto, las relaciones, las funciones, los axiomas y las reglas.
OCML fue desarrollado más tarde, en 1993, en el KMI en la Open University. Fue creado como un tipo de
“Ontolingua operacional”. De hecho, la mayor parte de las definiciones que están expresada en OCML son similares
a las definiciones correspondientes en Ontolingua, y se pueden definir algunos componentes adicionales: Las reglas
de producción y deducción, definiciones operacionales para las funciones. OCML fue creado para desarrollar
ontologías ejecutables en y métodos para modelos de resolución de problemas.
FLogic [40] fue desarrollado en 1995 en la Karlsruhe University. FLogic (el frame Logic) combina frames y
lógica de primer orden, permitiendo representar conceptos, taxonomías de concepto, relaciones binarias, funciones,
instancias, axiomas y reglas deductivas. Su motor de inferencias, Ontobroker, puede servir para chequear
restricciones y deducir información nueva.
En 1997, comenzó el programa High Performance Knowledge Base (HPKB). Este programa de
investigación fue patrocinado por DARPA, y su objetivo fue solucionar muchos problemas que usualmente aparecen
cuando ocupamos grandes KBs (respecto a la eficiencia, creación, integración del contenido disponible en los
diferentes sistemas, etc.). Uno de los resultados de este programa fue el desarrollo del protocolo OKBC (Accesible
Knowledge Base Connectivity). Este protocolo permite tener acceso a KBs almacenados en los diferentes sistemas
de representación de conocimiento (KRSs). De los sistemas presentados de antes, Ontolingua y Loom son
compatibles con OKBC.
El desarrollo de la Internet condujo a la creación de lenguajes de ontologías que sacaran provecho a las
características de la Web. Tales lenguajes son usualmente designados lenguajes de ontología basada en la Web o
lenguajes de marcado de ontología.
SHOE [41] fue construido en 1996 como una extensión de HTML, en la University of Maryland. Usa
etiquetas diferentes a las de la especificación de HTML, logra la inserción de ontologías en documentos de HTML.
SHOE combina frames y reglas. SHOE permite representar conceptos, sus taxonomías, sus relaciones de n-aria, sus
instancias y las reglas de deducción, las cuales son usados por su motor de inferencias para obtener un nuevo
conocimiento.
Luego, XML [42] fue creado y ampliamente adoptado como un lenguaje estándar para el marcado de
información en la Web. La sintaxis de SHOE fue modificada para usar XML y luego, otros lenguajes de ontología
fueron desarrollados en la sintaxis XML.
16
XOL [43] fue desarrollado por el centro internacional de IA de SRI, en 1999, como una XMLización de un
subconjunto pequeño de primitivas del protocolo OKBC, llamado OKBC-LITE. Es un lenguaje muy restringido
donde solo conceptos, las taxonomías de concepto y relaciones binarias pueden ser especificadas. No tiene ningún
motor de inferencia, ya que fue principalmente diseñado para el intercambio de ontologías en el dominio biomédico.
RDF [44] fue desarrollado por el W3C (World Wide Web Consortium) como una la red de trabajo
semántica basada en un lenguaje para describir recursos Web. RDF Schema [45] fue creado por el W3C como una
extensión para RDF con frames basados en primitivas. La combinación de ambos RDF y RDF Schema es
normalmente conocida como RDF(s). RDF(s) no es muy expresivo, simplemente permite la representación de
conceptos, las taxonomías de concepto y las relaciones binarias. Algunos motores de inferencias han sido creados
para este lenguaje, principalmente para la evaluación de restricciones.
Estos lenguajes han establecido las bases de la Web Semántica. En este contexto, tres lenguajes más han
sido desarrollados como extensiones para RDF(s): OIL, DAML +OIL y OWL.
OIL fue desarrollado en el marco del proyecto europeo IST On-To-Knowledge. Agrega primitivas basadas
en frames KR para RDF(s), y su semántica formal se basa en DLs. El clasificador FaCT se usa para realizar
clasificaciones automáticas de conceptos.
La especificación DAML-ONT fue la que más tarde se lanzo al mercado en el contexto de DARPA de la
iniciativa DAML (DARPA Agent Markup Language). En diciembre del 2000, fue mejorado a DAML +OIL [46], el
cual fue creado por una comisión mixta del US y el EU en el contexto de DARPA del proyecto DAML. DAML+OIL
también agrega primitivas DL basadas KR para RDF(s). Ambos OIL y DAML+OIL permiten representar conceptos,
taxonomías, relaciones binarias, funciones e instancias. Muchos esfuerzos se hicieron para proveer mecanismos de
razonamiento DAML+OIL.
Finalmente, en 2001, el W3C creo un grupo de trabajo designado Web-Ontology (WebOnt) Working
Group. La meta de este grupo era hacer un lenguaje nuevo de marcado basado en ontologías para la Web Semántica,
lo llamaron OWL (Web Ontology Language). Ya han definido una lista de casos de uso para la Web Semántica, ha
tomado características de DAML+OIL como entrada principal para OWL y propusieron la primera especificación de
este lenguaje [47]. OWL esta dividido en dos capas: El OWLlite y OWL.
A continuación se presentan algunas conclusiones de esta sección. Se han desarrollado estas conclusiones
comparando todos los lenguajes con relación al mismo marco de trabajo de evaluación [48]. El símbolo ' + ' quiere
decir que el rasgo es al que se dio más soporte por el lenguaje, el símbolo ' - ' quiero decir que el rasgo no es al que
se dio más soporte por el lenguaje, y el símbolo ‘±’ significa que el rasgo no es soportado inmediatamente por el
lenguaje pero se puede representar usando un workaround. Los resultados de esta confrontación están resumidos en
Tabla 3 del anexo 1. En esta tabla, no se presenta los resultados para OWL.
Los conceptos, organizado en taxonomías, relaciones binarias y las instancias son los únicos componentes
que se representan en todos los lenguajes presentados. Sin embargo, existen algunas diferencias en las primitivas
disponibles en cada lenguaje para representar taxonomías de concepto. En este sentido, Ontolingua, Loom, OCML,
OIL, DAML+OIL y OWL son más expresivos, permiten crear particiones exhaustivas y disjuntas de subclase de un
concepto.
17
En Ontolingua y SHOE, las relaciones arbitrarias n-aria pueden ser creadas. En el resto de lenguajes, estas
relaciones deben ser representadas por su descomposición en relaciones binarias.
Las funciones pueden estar definidas fácilmente en DAML+OIL, Ontolingua, Loom, OCML, OIL y OWL.
En FLogic pueden ser creados definiendo una relación y que un axioma adicional de una restricción al número de
valores que puede tener.
Los axiomas formales son la manera más poderosa de representar el conocimiento en las ontologías, y se
usan usualmente para representar esas partes de conocimiento que no pueden ser representadas con otras primitivas
del lenguaje. Los axiomas formales pueden estar definidos en Ontolingua, Loom, OCML y FLogic.
Finalmente, las reglas solo pueden estar definidas en Loom y OCML, y los procedimientos solo pueden
estar definidos en Ontolingua (aunque no pueden ser ejecutados), Loom y OCML.
Con respecto a los mecanismos de inferencia agregados en cada lenguaje, son diversos. Excepto por el
motor de inferencias de OIL (FaCT), los motores de inferencias se usan para deducir nuevo conocimiento de las
ontologías o chequear inconsistencias en sus axiomas formales. En Loom y OIL, el motor de inferencias también
realiza clasificaciones automáticas de conceptos.
La lección principal para aprender de esta sección es que si necesitamos implementar una ontología,
deberíamos decidir primero nuestras necesidades aplicativas en términos de la expresividad y los servicios de
inferencia, porque no todos los lenguajes existentes permiten representar los mismos componentes. La representación
y el razonamiento con información básica, como los conceptos, las taxonomías y las relaciones binarias, no son
usualmente suficientes si queremos crear una ontología de peso pesado y si queremos hacer razonamientos
complicado con ella. Por lo tanto, realizar una buena decisión del lenguaje específico a usar para representar
ontologías es crucial para desarrollar una aplicación basada en ontologías.
Figura 3: Pila de Lenguajes de marcado basado en ontologías.
18
2.5. Aplicaciones de las Ontologías.
Las ontologías entregan una comprensión compartida y consensuada del conocimiento de un dominio, que puede ser
comunicada entre sistemas heterogéneos y personas. Para la reutilización de conocimientos desde otros sistemas es
necesario conocer y estar de acuerdo con la terminología y su significado. Es por eso que existen los acuerdos
ontológicos, que son acuerdos terminológicos necesarios para reutilizar el conocimiento. La idea es convertir la
información en conocimiento.
Existe un amplio desarrollo en la investigación de las ontologías y esto lleva a un gran aumento en el uso de
éstas, inclinándose más frecuentemente en el campo de la Web Semántica, la Ingeniería del Conocimiento o los
Sistemas de Información y otros más.
En la Web Semántica.
• Se utiliza en la indización de documentos, que hace que la indexación de un sitio Web con apoyo de una
ontología terminológica comienza con la extracción de los términos más relevantes de cada página, y
después de asociar a estos términos conceptos candidatos, se evalúa la capacidad de representación de la
pagina de cada uno de estos conceptos, que determina su nivel de representatividad y finalmente se
construye el índice. Así las consultas se procesaran a un nivel conceptual, lo que nos llevara a un mayor
grado e acierto.
• Se aplica al agrupamiento, en donde las ontologías aportan las herramientas para que los distintos equipos
puedan entenderse entre sí y funcionar como si fuera uno solo.
• En lo que respecta a servicios Web, las ontologías representaran los datos en la red de tal forma que puedan
ser utilizados y comprendidos por las maquinas sin necesidad de la intervención humana.
• Ahora en el comercio electrónico, existen ontologías orientadas a aplicaciones que facilitan el comercio
electrónico (MKBEEM, Multilingual Knowledge Based European Electronic Marketplace), que combina
procesamiento basado en ontologías y procesamiento de lenguaje humano en un portal multilingüe.
En la Ingeniería del conocimiento
• Para la ingeniería del conocimiento, por un lado en el modelado conceptual se crea un glosario de la
terminología del dominio de la aplicación (conceptos), las relaciones entre dichos términos y las
restricciones de uso. Este modelo conceptual explícito es la ontología. Por otro lado, la construcción de la
base de conocimiento usa la ontología definida en la etapa anterior como un conjunto de esquemas o
contenedores de conocimiento.
• Para el procesamiento del lenguaje natural, una ontología puede mantener la definición de elementos
gramaticales del lenguaje y sus relaciones, permitiendo, por ejemplo, el análisis sintáctico de un texto.
• Para la distribución del conocimiento desde el punto de vista de la reutilización, uno de los fines
principales de la utilización de una ontología en un sistema es poder reutilizar conocimiento para sistemas
futuros. Se podrán integrar ontologías para la constitución de una nueva, más grande, que mejore la
19
conceptualización que aportaban todas ellas por separado. Sistemas distintos podrán entender la
información almacenada en una ontología sobre un dominio y trabajar con dicha información aunque no
haya sido generada por y para ellos.
• En la distribución de conocimiento como un camino para resolver la integración de sistemas basados en
conocimiento, se utiliza la integración inteligente de información. Como se ha señalado en puntos
anteriores, la distribución de un conocimiento de forma estandarizada se traducirá en importantes mejoras
en el desarrollo de agentes inteligentes que tendrán a su disposición un mayor número de bases de
conocimiento disponibles.
• Para la implementación de agentes software inteligentes, una posible meta es poder disponer de un agente
software para cada dominio o cada tarea que tenga que realizar un humano facilitándole la obtención de
resultados.
En los Sistemas de Información
• Para la interoperabilidad entre sistemas heterogéneos, las ontologías se presentan como una solución para
lograr una integración inteligente. Con una ontología terminológica, se pueden organizar los términos que
son usados en interacciones entre sistemas heterogéneos, de manera que reconozca cuándo una aplicación
está usando un término que es más general o más específico que otro que está en uso por otra aplicación.
• En los sistemas de información cooperativa, el objetivo es que múltiples sistemas de información sean
capaces de trabajar de forma cooperativa combinando sus datos y funcionalidades, con ayuda de las
ontologías.
• En los medios de distribución de conocimiento dentro de aplicaciones de software y entre aplicaciones de
software, mediante la comunicación entre aplicaciones sin intervención humana, utilizando estándares y
protocolos para el entendimiento recíproco.
• En la recuperación de información, enfocado a mejorar la formulación de consultas, si se añade semántica
a las consultas y no sólo se efectúan por palabras clase, se proporciona una calidad superior en los
resultados de una búsqueda. Las consultas serán tratadas desde un punto de vista conceptual. De este modo,
se reducirá el ruido y el silencio en los resultados de una búsqueda, lo que permitirá que no se omitan
aquellos resultados, que aún siendo conceptualmente sinónimos al de la consulta, no se encuentran por ser
distintos terminológicamente.
• En la normalización de sistemas documentales, la documentación generada por los nuevos sistemas
contará con características como la identificación del contenido documental (información) mediante el uso
de códigos de identificación y descriptores, el etiquetado de la documentación legible en las fuentes y en los
instrumentos de representación (catálogos, listados, bases de datos, etc.), el establecimiento de una
estructura base que permita la relación de los términos empleados en la identificación documental y la
creación de instrumentos auxiliares para la recuperación de la información como índices, tablas, etc.
20
Otras posibles aplicaciones y usos de las ontologías pueden ser:
• En los repositorios para la organización del conocimiento.
• Servir de herramientas de referencia en la construcción de sistemas de bases de conocimiento que aporten
consistencia, fiabilidad y falta de ambigüedad a la hora de recuperar información.
• Normalizar los atributos de los metadatos aplicables a los documentos.
• Crear una red de relaciones que aporte especificación y fiabilidad.
• Posibilitar el trabajo cooperativo al funcionar como soporte común de conocimiento entre organizaciones,
comunidades científicas, etc.
• Permitir la integración de diferentes perspectivas de usuarios.
• Permitir la construcción automatizada de mapas conceptuales y mapas temáticos.
• Permitir la reutilización del conocimiento existente en nuevos sistemas.
• Establecer modelos normativos que permitan la creación de la semántica de un sistema y un modelo para
poder extenderlo y transformarlo entre diferentes contextos.
• Servir de base para la construcción de lenguajes de representación del conocimiento.
2.6 El rol de las ontologías en los SI
Se puede decir que un SI tiene su propia ontología implícita, ya que se atribuye significado a los símbolos usados
según una visión particular del mundo. Sin embargo, de manera explícita, una ontología puede tener distintos roles
en un SI.
Basados en Guarino, Jasper y Uschold, Milton, Wand y Weber y, teniendo en cuenta los beneficios que ofrecen
las ontologías en los SI, se aborda el rol de las ontologías en los SI desde dos perspectivas:
• Como un soporte para el análisis conceptual de métodos y técnicas de los SI.
• Como un soporte para el diseño, desarrollo y uso de los SI. En esta perspectiva se analizan dos dimensiones:
la visión de los desarrolladores, concerniente a la manera en que una ontología ayuda o se usa para
desarrollar un SI y la visión del usuario, relativa a la manera en que una ontología facilita la tarea del
mismo al interactuar con el SI.
En la figura 4 se muestra una clasificación del rol de las ontologías en los SI.
21
Figura 4: Rol de las Ontologías en los SI
2.6.1 Las Ontologías como Soporte al Análisis Conceptual
Un SI es, en esencia, una representación de fenómenos del mundo real [49]. Por lo tanto, si se conoce cómo está
constituida la realidad, se podrán elaborar mejores modelos de la misma y, por ende, mejores SI. Es por ello que los
investigadores se esfuerzan en la construcción de teorías dirigidas a determinar cómo se estructuran los SI en base a
diversas posturas ontológicas referidas a cómo está constituido el mundo real.
Así, surgen los diferentes modelos ontológicos de los SI que consisten en construcciones abstractas que
indican los principales componentes estructurales y dinámicos de un SI, conforme a una ontología filosófica
determinada.
El filósofo Chisholm [50] propuso una ontología de sentido común crítico. El sentido común crítico
demanda un estándar riguroso de soporte para el conocimiento a adquirir. En base a esta postura epistemológica,
Milton y Kazmierczak sostienen que la ontología de Chisholm puede ser utilizada (sin necesidad de adaptaciones)
para el análisis ontológico de los lenguajes de modelación de datos. Para ello, estos autores propusieron un modelo
que permite evaluar los lenguajes desde el punto de vista ontológico. Por lo tanto, se puede considerar que la
ontología de Chisholm constituye en sí misma un modelo ontológico de SI.
Por otra parte, Bunge [51,52] es el autor de ontología filosófica qué más influencia tuvo en los SI. Esta
ontología se basa en un realismo científico, el cual requiere una compresión teórica profunda y detallada de la
realidad, propia de la ciencia contemporánea. La ontología de Bunge sostiene que el mundo está hecho de sistemas
interconectados. En base a esta postura epistemológica, Wand y construyeron el modelo ontológico BWW (Bunge-
22
Wand-Weber). Este es un modelo de descomposición de los SI. Es formal, libre de contenido, compuesto por: el
modelo de representación, el modelo de transición de estados y el modelo de buena descomposición.
Estos modelos abstractos de los SI constituyen un importante soporte teórico para el proceso de modelación
y, por lo tanto, se utilizan para la evaluación de los lenguajes o técnicas de análisis y diseño de SI. En general, esta
evaluación radica en que los lenguajes que cumplen con los aspectos considerados en los modelos ontológicos son
más eficientes que aquellos que no los contemplan.
En síntesis, se dice que la Ontología de Chisholm es útil para la modelación de fenómenos que están
relacionados a dominios de aplicación donde dominan los temas sociales o humanos, debido a que se trata de una
ontología de sentido común. Por el contrario, la ontología de Bunge se adaptaría mejor a ambientes de
implementación o dominios de aplicación donde los aspectos humanos o sociales están ausentes. En la figura 5 se
observa como, a partir de las ontologías filosóficas y los modelos ontológicos de los SI disponibles, se pueden crear
y/o modificar lenguajes o técnicas de modelación de los SI.
Figura 5: Análisis Conceptual Ontológico de las Técnicas de Modelación de SI.
Casos típicos de la utilización de ontologías como análisis conceptual son los siguientes:
• En 1998, Opdahl y Henderson Sellers realizaron una evaluación ontológica de lenguajes de análisis y diseño
orientado a objetos utilizando el modelo ontológico BWW. Tales autores tomaron los lenguajes UML
(Unified Modelling Language) y OML (Open Modelling Language) y los analizaron ontológicamente en
base a las estructuras que el modelo de BWW define para los SI. Como producto de este estudio se obtuvo
la definición, integración y formalización apropiada de construcciones y diagramas de modelación de los
lenguajes UML y OML.
23
• Milton, Kazmierczak y Keen desarrollaron en 2001 un método de análisis conceptual de los lenguajes de
modelación de datos basado en la ontología filosófica de Chisholm. Los autores tomaron cinco lenguajes de
modelación estándar y los analizaron contrastándolos con las estructuras del mundo real propuestas por
Chisholm. Los lenguajes evaluados fueron: Entidad-Relación (ER), Modelos de Datos Funcionales (FDM),
el Modelo de Datos Semántico (SDM), NIAM y la Técnica de Modelación de Objetos (OMT). Los
hallazgos de la investigación sirven para optimizar las técnicas de modelación en base a nuevas teorías
construidas dentro del campo de los SI. Los autores concluyen en que la ontología de Chisholm tiene la
potencia necesaria para ser una teoría unificadora de los modelos de datos.
2.6.2 Las Ontologías como Soporte de los SI
2.6.2.1 Desde la visión del desarrollador
El desarrollador de software se enfrenta con problemas relacionados con la identificación, captura y representación
del conocimiento de un dominio específico y las principales tareas que aborda son:
a) El análisis de requisitos del sistema, en donde se analizan y documentan las necesidades de información
que deberán ser soportadas por el sistema a desarrollar.
b) La especificación funcional del sistema (arquitectura lógica) de forma independiente del entorno técnico.
c) El diseño del sistema que se aplica a cuatro características distintas del software: la estructura de los datos,
la arquitectura de las aplicaciones, la estructura interna de los programas y las interfaces.
a) Especificación de requisitos
Es factible usar una ontología que modele el dominio de aplicación y proporcione un vocabulario para la
especificación de requisitos (ER) del sistema a diseñar. El rol que la ontología juega en la especificación varía con el
grado de formalidad y automatización de la metodología de diseño.
En una aproximación informal, las ontologías facilitan el proceso de identificación de los requisitos de un
sistema y el entendimiento de las relaciones entre los componentes del sistema. Esto es importante cuando se
desarrollan SI en el que intervienen equipos de personas que trabajan en dominios diferentes. En una aproximación
formal, una ontología provee una especificación declarativa de un SI que permite razonar para qué el sistema está
diseñado.
Por otra parte, es necesario destacar que las técnicas de educción, utilizadas en Ingeniería del Conocimiento,
cada vez se utilizan con mayor frecuencia en la educción de requisitos en un contexto organizacional determinado.
En este sentido, el usuario es considerado como un experto en su ámbito de trabajo.
24
Figura 6: Especificación de Requisitos con Ontologías
En la figura 6 se esquematiza el rol de las ontologías para el ER. Como se observa, se adquiere
conocimiento tanto de los expertos / usuarios (educción) como de las ontologías existentes en una biblioteca
determinada (extracción/reuso). Las ontologías también pueden usarse para automatizar la educción de
conocimientos.
Los principales beneficios de utilizar ontologías en la ER son la fiabilidad de la especificación obtenida la
disminución de ambigüedad en los requisitos, la mejor documentación y la reducción del tiempo insumido en la
adquisición de información/conocimiento.
b) Modelado de datos
Un modelo de datos describe la estructura lógica de los datos y su aplicación. Es decir, es la descripción esquemática
de las instancias del modelo, estas instancias representan los datos que son usados por la aplicación. Se han hecho
muchas extensiones del modelo entidad - relación para tratar de capturar el significado de los datos (la parte
semántica); por ejemplo, el modelo de datos orientados a objetos. Sin embargo, estos modelos aún presentan
limitaciones tales como considerar un solo punto de vista del mundo y una sola posible interpretación de las
instancias de interés.
En el uso de ontologías para el modelado de datos, es necesario diferenciar dos situaciones según el momento en que
se encuentra el SI: en tiempo de desarrollo o en tiempo de mantenimiento.
25
Figura 7: Modelado de datos con Ontologías en tiempo de desarrollo.
• En tiempo de desarrollo
En la figura 7, se observa que el esquema de la BD se obtiene a partir del análisis de los datos del dominio, del
documento de ER y del conocimiento extraído de ontologías existentes en la Web (ontologías extrínsecas).
El modelado de datos con ontologías tiene los siguientes beneficios: a) disminución del tiempo de diseño
del esquema al reusar el conocimiento existente de ontologías disponibles y b) disminución de heterogeneidad
semántica, ya que las BD, de las aplicaciones existentes o futuras, de un mismo dominio comparten la misma
ontología, resultan ser homogéneas o con escasa posibilidad de heterogeneidad semántica.
• En tiempo de mantenimiento
Este es el caso de las BD que están en funcionamiento, existen otros SI o BD en el mismo contexto que necesitan
interoperar. Generalmente, en esta situación, surgen problemas de operabilidad debido a la heterogeneidad de
esquemas e incompatibilidades semánticas. La heterogeneidad semántica aparece cuando los SI no tienen la misma
interpretación de la información que pretenden intercambiar, o sea, el significado de un ítem es diferente para los
distintos SI o BD.
En la figura 8 se muestran los principales procesos que intervienen en la integración de BD con ontologías.
El proceso de integración se desagrega (figura 8) de acuerdo a los distintos enfoques existentes.
En la figura 9 (a) se observa un enfoque de integración con una única ontología. En este caso, se integran
BD existentes y heterogéneas usando una ontología (creada por el desarrollador para ese fin) que proporciona un
vocabulario compartido.
En la figura 9 (b) se muestra el enfoque de integración con ontologías múltiples. Cada fuente de
información o BD se describe con su propia ontología. Esta arquitectura ontológica puede simplificar la tarea de
integración y soporta el cambio; por ejemplo, la inserción y eliminación de fuentes de información o BD.
26
En la figura 9 (c) se observa el enfoque de integración híbrido . Al igual que los enfoques de ontologías
múltiples, las semánticas se describen con su propia ontología. Con el fin de permitir que las ontologías locales sean
comparables entre sí se desarrolla un vocabulario compartido global.
Figura 8: Modelado de datos con ontologías en tiempo de mantenimiento
Estos enfoques de integración usando ontologías permite la interoperatividad entre múltiples aplicaciones, esto es
posible porque se accede a la misma información almacenada en BD distintas.
Figura 9: Distintos enfoques de integración.
27
c) Diseño del sistema
• Diseño de programas de aplicación: los programas de aplicación son una parte importante de muchos SI.
Normalmente contienen mucho conocimiento del dominio que, por varias razones, no se guarda explícitamente en
una BD. Algunas partes de este conocimiento se codifican en la parte estática del programa en la forma de tipo o
declaraciones de clases, otras partes están implícitamente en la parte procedimental del programa. Ambas partes son
susceptibles de transformarse con la ayuda de una ontología.
En la figura 10, se observa como, a partir de una ontología, la parte declarativa y procedimental se
convierten en una base de conocimiento y en un motor de inferencias, respectivamente. Se obtiene de esta manera un
sistema basado en conocimiento (SBC).
En el caso del desarrollo de un nuevo SI, los programas se diseñan y desarrollan usando ontologías,
obteniendo, de esta manera, un SIBO. En cambio, si los programas ya existen, pueden ser convertidos usando
ontologías.
Los beneficios de diseñar o convertir programas de aplicación mediante ontologías radican en que se
aumenta la calidad interna del software y se facilita el mantenimiento, la extensibilidad, la flexibilidad y la
transparencia.
• Diseño de Interfaz de Usuario: en el diseño de interfaces se pueden utilizar ontologías y de esta manera incluir
conocimiento semántico.
Los beneficios de usar ontologías en la interfaz de usuario radican en que el diseño obtenido tiene calidad externa y
se facilita la tarea del desarrollador porque la interfaz incluye una verificación de las restricciones contenidas
implícitamente en las clases, relaciones y axiomas de la ontología (Figura 11).
Figura 10: Programas de aplicación
28
Figura 11: Diseño de Interfaz de usuario.
2.6.2.2 Desde la Visión del Usuario
a) Uso explícito: en esta situación el usuario es consciente, o sea conoce la existencia de la ontología y puede usar la
misma como vocabulario. El usuario es libre de adoptar sus propios términos en el lenguaje natural los cuales son
mapeados al vocabulario del SI (figura 12).
b) Uso implícito: en esta situación el usuario no es consciente del uso de la ontología. El usuario usa la ontología
como parte normal de su interacción con el SI para hacer preguntas o para navegar (figura 13). Las preguntas del
usuario son manejadas por una ontología e indirectamente apoyan el proceso de las consultas para acceder a la
información del sistema. Estas preguntas son más intuitivas para el usuario no experimentado.
Los beneficios de utilizar ontologías, desde el punto de vista del usuario, radican en que se facilita la
navegación en el SI y la posibilidad de usar diferentes términos (sinónimos, hiperónimos, e hipónimos) del dominio
de aplicación.
De esta manera, se consigue mayor amigabilidad y se alivian los problemas relacionados con la semántica
de la información.
29
Figura 12: Interfaz de usuario Explícita
Figura 13: Interfaz de usuario Implícita.
2.7. Integración con Ontologías
[53] El hablar de mapping de ontologías se refiere a una manera de realizar integración de información desde fuentes
de datos heterogéneas.
Dentro de la integración de información según H. Wache [54] las ontologías pueden ser utilizadas para
describir la semántica de las fuentes de información y hacer explícito su contenido. Por lo tanto, son útiles para la
integración de fuentes de datos, porque identifican y asocian conceptos semánticamente correspondientes.
Para poder utilizar una ontología es necesario solucionar el problema de la interoperabilidad, es decir, que la
información que será compartida no sólo necesita proporcionar accesibilidad completa a los datos, sino que también
requiere que los datos accesados puedan ser procesados e interpretados por sistemas remotos.
30
Los problemas que pueden surgir debido a la heterogeneidad de los datos ya son conocidos dentro de la
comunidad de sistemas de bases de datos distribuidas y corresponden a la heterogeneidad semántica y la
heterogeneidad estructural.
La heterogeneidad semántica se describe en H. Wache y ocurre cuando diferentes sistemas de información
almacenan sus datos en diferentes estructuras. Por lo tanto, se consideran los contenidos de un ítem de información y
su significado. Para alcanzar la interoperabilidad semántica, el significado de la información que será intercambiada
debe ser comprendido por todos los sistemas que interactuarán.
En F. Wiesman [55] se identifican tres conflictos que impiden lograr la heterogeneidad semántica:
• Conflicto Estructural que ocurre cuando los conceptos parecen tener el mismo significado, pero en
realidad difieren, es decir, tienen diferencias en su estructura semántica.
• Conflictos de datos que ocurren cuando se utilizan diferentes representaciones del mismo dato.
• Conflictos de Nombre que ocurre cuando se utilizan diferentes nombres para el mismo tipo de información
o los mismos nombres para diferentes tipos de información. Un fenómeno frecuente es la presencia de
homónimos y de sinónimos.
El uso de ontologías para la aplicación de conocimiento implícito y oculto es una alternativa posible para
superar el problema de la heterogeneidad semántica.
A continuación se discute una aplicación importante de mapping dentro de lo que es integración de
información analizadas desde H.Wache y se trata del mapping entre las ontologías y la información que ellas
describen.
El mapping de ontologías se asocia con la tarea de relacionar el vocabulario de dos ontologías que comparten
el mismo dominio, es decir, mapear conceptos encontrados en una ontología con los conceptos que se encuentren en
la otra. El mapping no se puede percibir como un modelo autónomo del mundo, más bien debe parecer como un
pegamento que junta información de distinta clase.
La primera y más obvia aplicación de mapping es relacionar la ontología al contenido actual del sistema de
información. Una ontología se puede relacionar a modelos de base de dato así como a un único término dentro de la
base de datos.
A continuación se describen tres formas diferentes de integrar información a través de ontologías.
2.7.1. Utilizando una Única Ontología
Este enfoque utiliza una única ontología global que proporciona un vocabulario común para la especificación
semántica. Todas las fuentes de información se relacionan a esta ontología global como se muestra en la figura 14.
31
Figura 14: Integración utilizando una única ontología [53].
La ontología global también puede ser combinada con varias ontologías especializadas. Esto se puede realizar
importando otros módulos de distintas ontologías.
Esta metodología de unificación se puede aplicar cuando todas las fuentes de información que serán
integradas proporcionan casi la misma visión del dominio. Pero si una fuente de información tiene una visión distinta
del dominio este tipo de mapping se vuelve dificultoso.
La aplicación de mapping a través de una única ontología es susceptible a cambios en las fuentes de
información, los cuáles pueden afectar a la conceptualización del dominio representado en la ontología.
2.7.2. Utilizando Múltiples Ontologías
Al utilizar múltiples ontologías cada una de las fuentes de información es descrita por su propia ontología. En un
principio la ontología fuente puede ser una combinación de varias ontologías, pero no se puede asumir que diferentes
ontologías fuentes comparten el mismo vocabulario. En la figura 15 se describe esta arquitectura.
Figura 15: Integración utilizando múltiples ontologías [53].
En este enfoque cada ontología fuente se construye sin considerar otras fuentes de información o sus
ontologías. Su arquitectura puede simplificar las tareas de integración y apoyar los cambios, por ejemplo, agregando
o removiendo fuentes de información. Por otro lado, carece de un vocabulario común lo que dificulta poder comparar
distintas ontologías fuentes. Para solucionar este problema es necesario definir una representación de mapping
32
interontología que identifica términos semánticamente correspondientes desde diferentes ontologías fuentes, donde
los términos son semánticamente iguales o parecidos. Pero el mapping también tiene que considerar diferentes
visiones sobre un dominio a través de diferentes agregaciones o granularidad de los conceptos de la ontología.
Para evitar una pérdida semántica, se tiene que permanecer dentro de la representación del lenguaje formal
cuando se define un mapping entre distintas ontologías [54]. Una manera directa de permanecer dentro del
formalismo es relacionar todas las ontologías usadas con una de nivel superior. Esto se puede hacer heredando los
conceptos de la ontología de nivel superior. Este tipo de mapping puede utilizarse para resolver conflictos y
ambigüedades. Además permite establecer conexiones entre los conceptos de diversas ontologías en términos de
súper clases comunes, pero no establece una correspondencia directa. Porque puede conducir a problemas cuando se
requiere una correspondencia exacta entre conceptos.
La correspondencia semántica intenta superar la ambigüedad que se presenta cuando se realiza un mapping
indirecto de conceptos a través de un nivel superior, intentando identificar correspondencias semánticas bien
fundamentadas entre los conceptos de las diferentes ontologías. Para poder procesar correspondencias entre campos
de una base de datos se pueden utilizar etiquetas semánticas. Esto se puede lograr construyendo un modelo
descriptivo lógico de los términos de las diferentes fuentes de información, demostrándose que el razonamiento se
puede utilizar para establecer relaciones entre diferentes terminologías.
Para evitar mapping arbitrario entre los conceptos la correspondencia semántica maneja un vocabulario
común para definir conceptos a través de diferentes ontologías.
2.7.3. Utilización de Ontologías Híbridas
Utilizar ontologías híbridas soluciona los problemas presentados en la utilización de ontologías únicas y múltiples.
Este enfoque es similar al de múltiples ontologías ya que la semántica de cada fuente de información es descrita por
su propia ontología. Pero para hacer comparables las ontologías locales cada una de ellas se construye desde un
vocabulario global compartido. El vocabulario compartido contiene términos básicos (primitivos) de un dominio, el
cual es combinado en la ontología local para describir semánticas más complejas. En ocasiones el vocabulario
compartido también es una ontología.
En el enfoque híbrido el punto interesante es cómo la ontología local es descrita. Una forma es asignar valores
a los atributos dentro de un vector. Para este caso los términos derivan de una ontología de dominio global. Otra
forma de describir la ontología local es ingresar cada concepto en etiquetas las cuales combinan los términos
primitivos (raíz de una palabra) desde un vocabulario compartido. La combinación de operadores es similar a la de
operadores conocidos desde una descripción lógica pero extendida, por ejemplo, un operador puede indicar que una
palabra es una agregación de varias palabras separadas.
La ventaja de utilizar ontologías híbridas es que se pueden agregar nuevas fuentes de información con
facilidad sin necesidad de hacer modificaciones. También apoya la adquisición y evolución de las ontologías.
La desventaja de este enfoque es que las ontologías existentes pueden no ser reutilizadas con facilidad, por lo
tanto, se hace necesario que sean reconstruidas desde cero. La figura 16 describe la arquitectura de ontologías
híbridas.
33
Figura 16: Integración utilizando ontologías híbridas [53].
2.8. Ejemplos de Uso de Ontologías
2.8.1 Ontología de Mikrokosmos [56]
En el mundo de las ontologías no existen verdades absolutas, ya que éstas son entidades construidas artificialmente,
que se crean, no se descubren. Esta es la razón por la que se sugieren tantos modelos de bases de conocimiento. En
este caso en particular lo que se desea representar es un sistema ontológico para la traducción automática; si bien son
demasiado limitados, estrictos y formales o, todo lo contrario, amplios, flexibles y en este caso concreto,
inabarcables. La opción es trabajar con una ontología negociada entre las distintas partes involucradas, cuyo
contenido esté en un formato que permita el intercambio de conocimiento no sólo experto; una ontología meramente
pragmática y adaptada a necesidades especificas, y que cubra, por supuesto, buena parte del léxico general.
Específicamente en la traducción de lenguajes se encuadra de lleno en el concepto de Situated Ontology, concepto
retomado por el equipo de Mikrokosmos. Es por esto que se explicará la ontología de Mikrokosmos basándose
específicamente en un sistema KBMT.
Mikrokosmos es un sistema de KBMT interlingüe (sistema de traducción basado en conocimiento)
desarrollado por el Computing Research Laboratory (CRL) de la New Mexico State University (NMSU) de EE.UU.
y financiado por el Ministerio de Defensa de este país. A diferencia de otros proyectos basados en KBMT anteriores
(p. ej. Pangloss), Mikrokosmos es un sistema práctico a gran escala, enfocado en principio a traducir entre los
idiomas inglés y español y que actualmente está siendo expandido para dar cabida a otros idiomas y otras
aplicaciones.
Mikrokosmos comenzó siendo un proyecto derivado de Pangloss, que se inició con el objetivo de superar
las deficiencias mostradas por el motor de KBMT de este sistema. En la actualidad, este sistema traduce artículos
periodísticos españoles sobre adquisiciones y fusiones empresariales sin restricciones de entrada. Para ello utiliza una
34
serie de lexicones específicos para cada lengua y una ontología de conceptos independiente de cualquiera de las
lenguas. Estos dos recursos son utilizados para generar las denominadas TMRs (Text Meaning Representations) que
constituyen las representaciones interlingües propiamente. Además del parser sintáctico, que es el mismo que el
utilizado en el proyecto Pangloss, en Mikrokosmos se están desarrollando una serie de algoritmos específicos para
problemas concretos que son denominadas "microteorías". Por ejemplo se contemplan teorías específicas para el
aspecto, el tiempo, el género, etc.
La Figura 17, ilustra la arquitectura de Mikrokosmos para el análisis de textos. Como se puede observar,
existen cuatro componentes clave en el sistema: el lexicón, la ontología, las representaciones interlingües (TMRs) y
las microteorías. Como se puede observar existen tres entidades superiores, OBJECT, EVENT y PROPERTY a
partir de las cuales se desarrollan todas las demás. La jerarquía es una red semántica de marcos.
Cada uno de estos marcos posee una rica estructura interna que le permite una gran expresividad. La
ontología puede ser considerada como una entidad autónoma en el sentido de que se define a sí misma. Por ejemplo,
todas las propiedades adscritas a los objetos o eventos (excepto algunas de significado especial y otras de
seguimiento, como la definición en lenguaje natural) se hayan definidas en algún punto de la rama PROPERTY. Por
otra parte, las propiedades de los objetos y eventos se heredan a lo largo de los sucesivos niveles de la jerarquía. Por
ejemplo, todos los events heredan por omisión la propiedad de requerir un agent. Si especificamos esta característica
al nivel event, todos los conceptos hijos de éste heredarán esta propiedad. Además, la herencia puede ser no
monotónica, también llamada herencia negativa, es decir, ha de ser posible especificar que algún elemento no herede
alguna propiedad. Por ejemplo, los passive-cognitive-events y los involuntary-perceptual-events no requieren un
agente. Las entradas del lexicón son referidas a uno o más de los marcos contenidos en la ontología con lo que se
consigue acceder a toda la información contenida en ésta, simplificando enormemente la cantidad de información
requerida en el lexicón propiamente y eliminando la redundancia. La creación de una ontología de estas
características resulta enormemente interesante pero también tropieza con una serie de problemas que no existen en
la lexicografía y que requieren plantearse algunas normas a seguir. Los diseñadores de Mikrokosmos establecieron
esta normativa para la creación de su ontología además de establecer una serie de restricciones en el interfaz del
lexicógrafo. De todos modos, se trata de una ardua labor, porque conlleva la estructuración del conocimiento humano
partiendo no desde un dominio determinado sino desde el nivel más alto.
35
Figura 17: Arquitectura NLP de Mikrokosmos
2.8.2. KAICO (Kit de Acceso a Invidentes Con Ontologías) [57]
Hoy en día existen dos tipos de acceso a la Web para las personas invidentes, una que consiste en lectores de pantalla
que interpretan el contenido que muestran los monitores presentándolo a través de audio, el otro tipo son los
navegadores por voz, estos a diferencia de los anteriores interpretan el HTML y presentan el contenido con diversas
voces para un mejor entendimiento.
Esta iniciativa utiliza una ontología para que los editores de páginas Web y los analizadores la utilicen para
agregar e interpretar respectivamente los elementos de las páginas Web.
KAICO está formado por una ontología como esquema de conocimiento, aplicaciones SW para añadir y
extraer marcas semánticas a los elementos de las páginas Web y periféricos para la comunicación con los invidentes.
Los elementos que forman la arquitectura son las siguientes:
• OntoBlind. Ontología en la se basan los SW del sistema, esta ontología contiene el modelo conceptual de
los elementos que pueden ser incluidas en las páginas Web con los atributos y relaciones entre ellos.
36
• OTBMarker. Editor de páginas con anotaciones semánticas en los elementos de acuerdo a OntoBlind.
• OTBExtractor. Es un plugins para el navegador que interpreta las anotaciones semánticas haciendo
referencia a OntoBlind y las muestra al invidente gracias a la ayuda de los periféricos. Las páginas sin
anotaciones semánticas son interpretadas según su grado de accesibilidad.
• WebTouch. Es el conjunto de periféricos y componentes SW que sirven de interfaz para los invidentes
obtener información adicional de ellos. Ejemplos de esto son: Enlaces, DirecciónDeCorreo, Teléfono.
Figura 18. Arquitectura KAICO.
2.8.3. Ejemplos de Ontología en el Dominio de la Universidad: “University-Ont”
La descripción que se mostrará a continuación corresponde a la Versión 1.0 de la Ontología que fue desarrollada por
el grupo Parallel Understanding Systems, del Departamento de Ciencias de la Computación de la Universidad de
Maryland.
Esta ontología define elementos para describir universidades y las actividades que ocurren en ellos. Incluye
conceptos como departamentos, facultad, estudiantes, cursos, investigación, y las publicaciones.
2.8.3.1. Taxonomía
La siguiente taxonomía es la colección de categorías declaradas en esta ontología. La forma jerárquica es pretendida
para mostrar la cadena ISA. Las categorías en [] no están definidas aquí pero están definido en una ontología
extendido por ésta. Los elementos de adentro {} son súper categorías adicionales de la categoría inmediatamente
37
antes de ellas (significando herencia múltiple). Las categorías seguidas por un asterisco están definidas en otra
ontología pero son provistas de un alias local.
Person* Employee* Faculty Professor AssistantProfessor AssociateProfessor FullProfessor VisitingProfessor Lecturer PostDoc Assistant ResearchAssistant TeachingAssistant AdministrativeStaff Director Chair {Professor} Dean {Professor} ClericalStaff SystemsStaff Student UndergraduateStudent GraduateStudent Organization* EducationOrganization* Department Institute Program ResearchGroup School University Publication* Article* BookArticle* ConferencePaper* JournalArticle* WorkshopPaper* Book* Periodical* Journal* Magazine* Proceedings* Thesis* DoctoralThesis* MastersThesis* Work* Course Research [base.SHOEEntity] Schedule [gen.Event] Conference
38
2.8.3.2. Relaciones
Las relaciones son declaradas entre uno o más argumentos, dónde cada uno de los argumentos es ya sea un tipo o una
categoría. Si el argumento es una categoría, entonces cualquier subcategoría de esa categoría es válida también. Las
relaciones que tienen un alias local pero están definidas en otra ontología son seguidas por un asterisco.
advisor(Student, Professor) affiliateOf(Organization, Person)* affiliatedOrganization(Organization, Organization)* alumnus(Organization, Person)* containedIn(Document, Document)* doctoralDegreeFrom(Person, University) emailAddress(Person, .STRING)* head(Organization, Person)* listedCourse(Schedule, Course) mastersDegreeFrom(Person, University) member(SocialGroup, Person)* name(base.SHOEEnity, .STRING)* offers(University, Course) publicationAuthor(Document, Person)* publicationDate(Document, .DATE)* publicationOrg(Document, Organization)* publicationResearch(Publication, Research) publisher(Document, Organization)* researchInterest(Person, Research) researchProject(ResearchGroup, Research) subOrganizationOf(Organization:"suborganization", Organization:"superorganization")*subject(Document, .SHOEEntity)* takesCourse(Student, Course) teacherOf(Faculty, Course) teachingAssistantOf(TeachingAssistant, Course) tenured(Professor, .TRUTH) undergraduateDegreeFrom(Person, University)
39
3. ESCUELA DE INGENIERIA INFORMATICA
En este capítulo, se expondrá la situación actual en que se encuentra la Escuela de Ingeniería Informática de la
Pontificia Universidad Católica de Valparaíso con respecto a la administración y a la automatización de procesos.
3.1. Introducción
Esta Unidad Académica fue creada el 2 de febrero de 1972 como el Centro de Ciencias de la Computación e
Información y fue incorporado a la Facultad de Ingeniería el 2 de junio de 1982. Luego el 30 de septiembre de 1982
se le da su actual denominación.
Además el 30 de Septiembre de 1982 se crea el Título Profesional de Ingeniero de Ejecución en Informática
y el de Ingeniero Civil Informático a partir de 1997.
En la actualidad, la Escuela de Ingeniería Informática, formando parte de la Facultad de Ingeniería,
desarrolla su actividad académica impartiendo las carreras de Ingeniería Civil Informática e Ingeniería de Ejecución
en Informática.
En los últimos años, la Escuela ha implantado un régimen de estudio de Postgrado. Dicho programa busca
generar la llamada “educación continua” motivando a sus alumnos, y profesionales de otras áreas a obtener
herramientas que les permitan estar acorde con los requerimientos solicitados por el mercado.
3.2. Descentralización Administrativa (DA) de Unidades Académicas
La autonomía y flexibilidad obtenida por la Escuela se inscribe en el concepto de Descentralización Administrativa
que es el proceso de traspaso de atribuciones y responsabilidades en el ámbito de la administración académica y
gestión presupuestaria, desde la administración central hacia las unidades académicas. De este modo, haciendo uso
de las capacidades y potencialidades que aquellas poseen con relación a su entorno focal, se facilita el desarrollo y
crecimiento global de cada unidad académica y por ende a toda la Universidad.
La implementación de una Administración Descentralizada se guía por los siguientes criterios:
• Las unidades académicas dispondrán de todos los ingresos que provengan por la cancelación del arancel de
inscripción, del arancel de mátricula de la totalidad de los alumnos en las carreras y programas que dicte, y
por aporte fiscal indirecto. El aporte fiscal directo continuará bajo la administración de las autoridades
centrales.
• Las unidades académicas destinarán un porcentaje de los ingresos indicados precedentemente al presupuesto
general de la Universidad. El porcentaje final será igual para todas las unidades académicas.
• Los servicios académicos recibidos y entregados serán contratados a valores que se acordarán en cada caso.
Los servicios que no puedan ser provistos internamente, de acuerdo a las necesidades de la unidad
académica, serán requeridos externamente.
• Los aranceles de inscripción y de matricula serán fijados por la autoridad central de acuerdo a políticas
generales.
40
• Las vacantes anuales podrán ser modificadas autónomamente por la unidad académica hasta un 30%,
variaciones mayores requerirán del acuerdo de las autoridades centrales.
• Las unidades académicas podrán contratar profesores de planta. Para ello deberán demostrar a las
autoridades centrales que sus estimaciones presupuestarias permiten tal contratación.
• Las unidades académicas se hacen cargo de financiar el pago de todo su personal académico, administrativo
y de servicio, de los servicios académicos que se soliciten a otras unidades académicas o instituciones, de la
compra de libros, suscripciones a revistas, equipos computacionales y tecnológicos, de los gastos
operacionales y de los costos asociados en la expansión del espacio físico.
3.3. Misión y Visión de la Escuela
Misión
La misión de la Escuela de Ingeniería Informática es el cultivo, a la luz de la fe, de las ciencias y las tecnologías, a
través de la creación y comunicaron del conocimiento, y la formación de profesionales en el área de la Informática,
con vocación de servicio a la sociedad, en el marco valórico del Magisterio de la Iglesia. En el ejercicio de su misión,
la Escuela de Ingeniería Informática garantiza a sus miembros libertad académica y resguarda la igualdad de
oportunidades de los estudiantes en el acceso a sus aulas.
Visión
Se visualiza una escuela con calidad académica reconocida a nivel nacional e internacional, que presenta un
crecimiento sostenido en el saber y muestra buenos resultados en sus procesos formativos. La Escuela manifiesta una
actitud de responsabilidad con la sociedad, a través de acciones rigurosas e innovadoras, y de la vinculación con los
ámbitos regionales, nacionales e internacionales. Sus egresados poseen el sello de la formación valórica en la
Pontificia Universidad Católica de Valparaíso, competencia para un desempeño profesional prestigiado,
preocupación constante por su formación y actualización, en lo personal y profesional, y con una capacidad para
asumir tareas en diferentes ámbitos.
3.4. Estructura y Funciones
La Escuela de Ingeniería Informática se estructura sobre la base de una Dirección y una Secretaria Académica,
además de jefaturas para sus actividades principales, esto es, Docencia, Investigación y Extensión. Adicionalmente,
tiene una instancia especial para la gestión de actividades de Asistencia Técnica y Consultaría hacia Empresas. En la
Figura 19 se muestra el organigrama.
41
Figura 19: Organigrama estructural de la Escuela.
Esta estructura es meramente formal siendo en la práctica representada por un espíritu de colaboración
directa en una estructura menos rígida de lo que se ve en el organigrama.
El Director es la autoridad superior de la unidad académica, representa a ésta ante los organismos y
autoridades de la Universidad o de entidades externas; preside los consejos de profesores y, en general, se
responsabiliza de la marcha académica y económica de la Escuela. Además, en él recae la responsabilidad de
elaborar el presupuesto y el plan anual de actividades de la Escuela. Por lo tanto, su papel es fundamental en el curso
que tome la estructura organizacional, administrativa y financiera de la Escuela. Por supuesto, tanto el plan de
actividades como el presupuesto deben ser presentados al consejo para ser aprobado.
El Secretario Académico es ministro de fe de la Escuela y el colaborador directo del director en sus
funciones de gobierno y administración académica. Además, debe dirigir, en el marco de las políticas fijadas por la
Universidad, al personal administrativo y de servicio perteneciente a la Escuela. Es un nexo importante entre las
tareas académicas y administrativas que se desarrollan en la Escuela.
El Jefe de Docencia se encarga de la programación y coordinación de los cursos (profesores, ayudantes,
salas, exámenes) y del cumplimiento de los programas de las asignaturas. Es el responsable de velar por el normal
desarrollo de la actividad docente con las atribuciones y deberes que contempla la reglamentación interna de la
Universidad.
El Jefe de Investigación coordina todas las actividades de investigación y aquellas con los organismos de
financiamiento de las mismas.
El Jefe de Extensión se responsabiliza de las relaciones con el exterior, manteniendo estrechos vínculos con
los ex alumnos, con establecimientos de enseñanza media, con empresas y con universidades e instituciones de otros
países.
42
3.5. Panorama de la Escuela
En el funcionamiento de una escuela existen ciertos procesos que son claves para una buena gestión. Muchos de
estos procesos tienen que ver con el trabajo que muchas veces realizan las secretarias como podrían ser la Secretarias
de Dirección, Docencia y Postgrado.
Otros procesos tienen que ver con las labores que tienen que desempeñar tanto el Director de la Escuela,
Jefe de Docencia, Secretario Académico, Jefe de Extensión, Jefe de Investigación.
A pesar que el sistema de Gestión Universitaria de la PUCV llamado UNIVERSIS cubre una gran cantidad
de procesos (como lo muestra la figura 20), existen muchos procesos que paradójicamente no se han automatizado en
nuestra Escuela.
Universis es el Sistema de Información de la Pontificia Universidad Católica de Valparaíso. Fue
desarrollado por la DSIC en el año 2001 con el objetivo de apoyar todos los procesos relacionados con la
administración docente de la Universidad -tales como inscripción de cursos, matrícula, programación de docencia,
registro de actas de curso, etc.- de modo que éstos puedan realizarse de forma expedita y entregando información
relevante a todos los involucrados. (Alumnos, Facultades, Unidades Académicas, Profesores, Administración
Central).
A través de Universis, los alumnos actualmente cuentan con información actualizada de su situación tanto
académica como administrativa, siendo así un eficaz apoyo en las decisiones relacionadas con su avance curricular.
Al estar basado en un esquema Web, nuestros estudiantes pueden acceder al sistema desde cualquier computador
conectado a Internet.
De la misma forma, Unidades Académicas, Profesores, Facultades y Unidades de la Administración Central
pueden visualizar y actualizar la información relacionada con las actividades en las que participan, de manera que
pueden llevarlas a cabo con todas las facilidades que significa contar con información oportuna y de fácil acceso.
Figura 20: Sistema Universis.
43
3.5.1. Procesos No Automatizados
Algunos de los procesos que la Escuela no ha automatizado aún son los siguientes:
• Administración de la información de Proyectos de Título (Proyecto 1 y proyecto 2). Lo ideal sería que le
diera visibilidad a todo el proceso desde las fechas de entrega de los informes hasta las fechas en que los
profesores devuelven las correcciones.
• Seguimiento de la tesis, es decir desde que se egresa y se le hacen las correcciones, pasando por informar la
documentación necesaria o requisitos no cumplidos.
• El proceso de Práctica, el cual comienza con una Solicitud de Práctica, a lo cual el Alumno recibe una
autorización para inscribir la práctica, luego esta se inscribe, una vez terminada la práctica el Alumno
cuenta con un plazo de un mes para presentar su informe y presentar la evaluación que le realizó la empresa,
luego el informe más la evaluación son asignados a un profesor.
• Otro es la de realizar ofertas de trabajo, ya que muchas veces estas llegan a la Escuela por teléfono o por
mail y la idea que tiene el Jefe de docencia es que estas se filtren según los temas de Proyecto de los
alumnos o ex alumnos por las practicas realizadas.
3.5.2. Procesos Automatizados
Existe una gran cantidad de sistemas que han sido desarrollados por alumnos de la Escuela como proyectos de título
o trabajos de cierto Curso ramo y la realidad dice que muchos de estos proyectos no pasan de ser un simple prototipo
ya que el gran problema que suelen tener es la interoperabilidad con los sistemas actuales.
El espíritu de la Escuela es tratar de automatizar lo más posible siempre respetando los siguientes principios
fundamentales:
• Respeto y ajuste a las normativas existentes.
• Sistematizar procesos no tareas.
• Quien es responsable del dato es quien lo registra.
• Acceso a la información en base a perfiles, restringidos a las operaciones que les corresponden.
• Mejorar la calidad de servicio a los alumnos.
• Integración de información en torno a un solo modelo de datos.
• Facilitar el acceso a la información.
• Apoyo a la operación.
A continuación se muestran una serie de sistemas que fueron desarrollados por alumnos de la Escuela y que
tenían como objetivo automatizar procesos de la misma.
44
3.5.2.1. Sistema de Administración de salas UCV.
El Sistema de administración de salas (SAS-UCV) [58] permite que las Unidades Académicas de la Universidad
soliciten salas para la realización de las diferentes asignaturas que en ellas se imparten. Lo que este sistema solucionó
fue el gran problema que se presenta al momento de la solicitud de una sala de clases, el tiempo que se demoraba en
saber si existía una sala desocupada con las características que se requerían era muy alto.
La finalidad del proyecto fue permitir administrar las salas de clases de manera automática, de manera de
reducir los tiempos para encontrar una sala desocupada en un horario determinado.
El sistema permite realizar tareas como:
• Manejo de asignación de las salas de clase, tanto en período normal, como en período de exámenes.
• Minimizar el tiempo de espera para obtener la información de salas disponibles.
• Generar con mayor rapidez los memos de oficialización de asignaciones, lo que permite también enviarlos
con mayor rapidez.
Otro problema que solucionó este sistema fue el asignar las salas en período de examen, que es un problema
distinto, ya que en este período las salas se solicitan para un día y un horario específicos, por lo tanto se hace
necesario manejar la información de forma diaria, ya que debido a esto la asignación de salas de una semana va ser
distinta a la de otra semana.
45
Figura 21: Clases del Sistema.
3.5.2.2. Sistema de Consulta De Alumnos Titulados.
Sistema creado específicamente para facilitar el trabajo de la Secretaria de Dirección de administración de
información de los alumnos ya titulados o en que ya aprobaron su malla curricular (en proceso de titulación) y que
deben realizar ciertos trámites [59].
Lo que realiza el sistema es automatizar ciertas tareas:
• Genera cartas que son enviadas a los alumnos indicándole qué documentos le hacen falta para titularse.
• Genera la carta que indica al alumno que se tituló.
• Genera el documento de antecedentes personales.
• Genera un informe de los documentos que son necesarios para titularse.
Este sistema entrega información relevante para la Dirección de la Escuela, Alumnos, Secretaria General y a
Empresas externas.
46
3.5.2.3 . Sistema de apoyo Al Control Académico de la Jefatura de Docencia
El sistema trata de ayudar a eliminar, aliviar o agilizar tareas tediosas y largas que los Jefes de Docencia o sus
Secretarias deben realizar [60].
El sistema permite: mantener los datos actualizados de los alumnos, confeccionar certificados y otro tipo de
documentos, proporcionar el plan de estudio para personas que se quieren cambiar de carrera, mantener actualizado
los archivos de publicaciones e investigaciones realizados por la Escuela.
Figura 22: Archivos del Sistema.
47
3.5.2.4. Sistema de Asignación de Horarios de Clases [61]
Consiste en un sistema que permite automatizar la asignación de horarios para la Escuela, logrando con esto reducir
el tiempo que demora el estudio y desarrollo de esta tarea para las personas que están a cargo.
El proceso es efectuado por el Jefe de Docencia y generalmente era realizado manualmente, con lo cual no
se lograba una buena solución debido a lo complejo del problema, este problema considera múltiples restricciones.
Figura 23: Clases Presentes en el Archivos del Sistema.
48
Figura 23: Modelo Entidad-Relación Básico.
3.5.2.54. Algunas diferencias entre los Sistemas
Diferencias en como se definen las clases, archivos y entidades son claves a la hora de lograr un modelo común y
con ello la integración de los múltiples sistemas.
Una de las diferencias más importante es como se define un ALUMNO:
ALUMNOS
rol
dv
nom_alumno
app_alumno
apm_alumno
domicilio
fono
cod_carr
mencion
ALUMNO
Rol_Alumno
Rut_Alumno
Nombre_Alumno
Direccion_Alumno
Mail_Alumno
Fono_Alumno
Figura 24: Formas de Representación de un ALUMNO.
49
Las diferencias que aquí se pueden notar son que en una forma el rol del ALUMNO es simplemente un
atributo (Rol_Alumno) y en la otra tiene dos atributos para formarlo (rol, dv), otra diferencia es en como tratan el
nombre del ALUMNO mientras que en una esta compuesto por tres atributos (nom_alumno, app_alumno,
apm_alumno) en otra es simplemente un atributo (Nombre_Alumno), finalmente la otra gran diferencia es que en
una representación la unica forma de distinguir un alumno de otro es el Rol UCV (rol,dv) en la otra es el Rol UCV y
el RUT (Rol_Alumno, Rut_Alumno).
Diferencias en la definición de PROFESOR:
Figura 25: Formas de Representación de un PROFESOR.
En una forma aparece el Rut del Profesor (Rut_Profesor), mientras que en la otra no. En una aparece solo un
atributo para definir el nombre (nombre de pila, apellido paterno, apellido materno) del profesor (Nombre_Profesor)
en cambio la otra tiene tres atributos para representar el nombre (nom_prof, app_prof, apm_prof).
Diferencias en la definición de ASIGNATURAS:
ASIGNATURA
Sigla
Clave
Nombre
Creditos
Objetivos
Asignaturas
Sigla
Codigo
CodUA
Nombre
Creditos
HorasTeoricas
HorasPracticas
HorasLaboratorio
Regimen
Estado
Figura 26: Formas de Representación de una ASIGNATURA.
Aquí no existen grandes diferencias salvo que una forma de representación contiene atributos que pueden
entregar información más relevante como las horas de Cátedra.
Diferencias en la definición de AYUDANTE:
50
Figura 27: Formas de Representación de una AYUDANTE.
51
4. MODELADO DE PROCESOS
Procesos podemos encontrar desde las actividades más cotidianas de nuestras vidas, hasta las operaciones más
complejas en el mundo organizacional o tecnológico. Una definición de proceso es una sucesión de acciones
continuas regulares, que llevan al cumplimiento de algún resultado. Otra definición de proceso podría ser un
conjunto de roles que realizan una serie de actividades repetibles, parcialmente ordenadas y que interactúan para
lograr un objetivo.
El modelamiento de procesos, permite conocer las áreas problemáticas y que pueden ser mejoradas, los
niveles y delegación de autoridad, las áreas de alto riesgo, el volumen de sus operaciones y el ciclo de vida de los
procesos. Luego pueden ser utilizados para acelerar o transformar la manera de llevar a cabo los procesos y definir
los puntos de interés de la organización. Para que una organización obtenga resultados exitosos en sus procesos, es
recomendable que tenga conocimiento de sus procesos y en su defecto que los tenga modelados.
El modelado de procesos servirá para aplicar el uso de la ontología, esto se ve reflejado en la aparición de
de clases y propiedades pertenecientes a la ontología en el modelado de procesos pertenecientes a la Escuela.
El modelado de procesos será un complemento a la ontología en el tema de compartir el conocimientos obre
el dominio de la Escuela, en especial en la estructura de ciertas actividades que se realizan dentro del funcionamiento
diario de la Escuela, esto permitirá reutilizar el conocimiento para una eventual automatización de procesos dentro de
la Escuela, lo que será más fácil si se consideran tanto la ontología como el modelado en conjunto.
En el modelado de procesos se destacaran tanto las clases como las propiedades de ellas que aparezcan
dentro del diagramado de los procesos.
4.1. Importancia del Modelado de Procesos
El modelamiento es importante porque es usado para documentar y dar soporte a los procedimientos de una
organización en una forma consistente y uniforme. El modelado es una actividad compleja que debe hacerse
cíclicamente y que requiere de un análisis sobre la forma en que las personas realizan el trabajo. La gran diferencia
del modelado de procesos con otros tipos de modelado en las Ciencias de la Computación es que modelan
fenómenos que son realizados por personas en vez de máquinas.
Los usos y las ventajas del modelado de proceso pueden ser:
• Facilita la comprensión y Comunicación Humana: Formaliza el proceso de modo que las personas puedan
trabajar más eficientemente; proporciona bastante información para permitir que una persona realice el trabajo.
• Proporciona soporte a la administración del proceso: Provee las bases para definir y analizar procesos y
facilita la selección e incorporación de tecnología de apoyo al proceso.
• Proporciona soporte a la administración del proceso: Facilita el monitoreo, el manejo y la coordinación del
proceso y provee ayuda en su medición.
• Automatiza la Dirección del proceso: Se almacena la representación de un proceso para ser reutilizable.
52
• Automatiza el apoyo de la ejecución: Automatiza porciones del proceso, cumpliendo reglas para asegurar la
integridad del mismo dentro del ambiente automatizado.
La información requerida para entender y modelar las características de los procesos puede ser obtenida de
preguntarse ¿Qué se va hacer?, ¿Quién lo hará?, ¿Cuándo y donde se va hacer?, ¿Cómo y por qué será hecho? Y
¿Quién es el responsable de que se haga?
Las cuatro perspectivas comúnmente utilizadas para lograr entender los procesos, capturar sus
características y responder a las preguntas anteriores son:
• Funcional: representa los elementos del proceso que se están ejecutando (actividades) y cual es el flujo. Se
establece una relación de precedencia o secuencia entere las diferentes actividades del proceso.
• Informacional : tiene que ver con las unidades de información producidas y manipuladas por el proceso. Esto
hace que el modelado esté basado en la creación de unidades de información. Estas unidades pueden ser datos,
artefactos, productos parciales o finales y objetos, su estructura y las relaciones entre ellos.
• De Comportamiento: representa cuando y/o bajo qué condiciones los elementos del proceso se realizan a través
de ciclos de retroalimentación, iteraciones, decisiones, entradas y salidas críticas. Representa la secuencia en que
son realizados los elementos o pasos del proceso.
• Organizacional: especifica donde y por quien están siendo ejecutados los elementos del proceso en la
organización.
4.2. Metodología para el estudio de Procesos
Una metodología es una manera sistemática o claramente definida para alcanzar un fin. Según Kettinger, existen
muchas metodología para analizar y rediseñar procesos. Preguntas como ¿Qué tan radicales se desean los cambios?,
¿Cuál es el nivel de TI que se requiere?, ¿Qué tan estructurado es el proceso bajo estudio?, son preguntas que se
deben realizar al momento de seleccionar una metodología.
Algunas de las metodologías:
• Rápida Reingeniería orientada a los negocios, formada por cinco etapas: Preparación, Identificación, Visión,
Solución y Transformación y cada etapa se divide en tareas.
• Metodología para el análisis y diseño de procesos (PADM-Process Análisis Design Methodology), consta de
las etapas de Captura, Modelado, Evaluación, Rediseño y eventualmente la etapa de Soporte.
• Gateway, es una metodología que consta de los siguientes estados: reparación, identificación, visión,
transformación, diseño técnico y social. Estos se categorizan de acuerdo a las actividades que contienen en los
siguientes escenarios: Prevención, Iniciación, Diagnostico, Rediseño, Reconstrucción y Evaluación.
Los siguientes criterios o características se deben considerar para la selección de la metodología del modelado:
1. Que sea considerada para el trabajo de que se trata. No solamente para la Ingeniería Industrial o de Software.
2. Que sea lo suficientemente flexible para ser aplicadas en diversas áreas.
3. Que se pueda aprender o utilizar por los miembros de la organización para que no haya necesidad de expertos.
53
4. Que identifique problemas específicos u oportunidades.
5. Que produzca resultados factibles de poner en práctica, por ejemplo por el concepto de costos.
Para este proyecto se selecciono la PADM como metodología, ya que incluye explicita e implícitamente
todas las etapas de las otras y utiliza RADs en su etapa de Modelado. A continuación se describen las etapas de
RADs.
En la captura se obtiene la información de como se realiza el proceso, a traves de entrevistas, cuestionarios,
observación, documentos relevantes al proceso y con la participación de los agentes involucrados. El resultado es
una descripción textual del proceso, identificación de responsabilidades.
El modelado del proceso utilizando técnicas diagramáticos, aquí se analizan objetivos, actividades, roles,
controles e interacciones. En esta etapa el modelado del proceso es revisado por las personas involucradas, para
validar y corregir la información y/o terminología. Los procesos de captura y modelado son iterativos.
En la evaluación se verifica que el proceso describa lo más cercano posible para continuar con el análisis. Si
esto no se lleva a cabo los modelos podrían contener información incorrecta o faltarle información, lo que podría
hacer tomar decisiones erróneas en posibles rediseños.
Cambio o Rediseños de actividades aquí lo que se busca es proponer mejoras al proceso. Se pone énfasis en
la eliminación de todas las actividades que no agregan valor. La propuesta de rediseño puede incluir acciones de
eliminación, simplificación, integración, automatización e incluso coordinación.
En la etapa de soporte se construye o adecua la TI que auxilie a la ejecución del proceso de acuerdo a lo
obtenido en las etapas anteriores.
4.3 Modelado con Técnicas Diagramáticos
Existe una gran variedad de técnicas para el modelado de procesos enfocados, de una forma estática, al flujo
secuencial de acciones (actividades) o información.
El modelado estático describe a las organizaciones en términos de sus procesos con la utilización de
diferentes técnicas de diagramáticas. Generalmente las técnicas de diagramación tienen un soporte por medio de
herramientas de Software. La mayoría de las técnicas diagramáticas, capturan la descripción del proceso con una
representación grafica por medio de cajas, flechas, líneas y otros, mostrando las actividades y los objetivos del
proceso.
Entre las técnicas diagramáticas para el modelado de proceso, destacan las siguientes:
• IDEF (Integrated DEFinition method): describe el proceso como una serie de actividades (cajas) definidas en
términos de sus entradas, salidas, controles y mecanismos. No solo direccional el flujo del proceso sino también
su control y además proporciona algunos del comportamiento, es recomendada para analizar aspectos
funcionales, informacional y de comportamiento del proceso.
54
• Diagrama de Flujo: se usa para representar el orden de las actividades y como las decisiones afectan el flujo
del proceso. Es fácil de entender, ya que utiliza símbolos acompañados de una descripción textual para describir
procesos, decisiones, bases de datos, entre otros, es considerada una técnica informal.
• Diagramas Rol Actividad (RAD por Rol Activity Diagrams): los RADs proporcionan información de las
perspectivas funcional, de comportamiento y organizacional; el soporte a la perspectiva informacional es escaso,
ya que depende de la descripción del proceso por parte del modelador. Su representación es desde el punto de
vista de los roles, actividades e interacciones.
Figura 28: Muestra un análisis comparativo de las características de IDEF, diagrama de flujo y RADs.
4.4. Uso de los Diagramas de Actividad para el Modelado de Procesos del Negocio
Los diagramas de actividad forman parte del modelado del negocio. Al realizar el diagrama de actividades
podemos ver claramente todas las actividades y su flujo lógico, incluyendo actividades que se ejecutan en paralelo y
no solamente el flujo secuencial, flujo de actividades y no de datos, esto es lo que hace la diferencia con otros tipos
de diagramas de flujo.
Los diagramas de actividad no son sólo usados en la ingeniería de software, también son usados en otras
áreas donde es necesario definir procesos de trabajo, ya que estos diagramas permiten representar la secuencia lógica
de un proceso de negocio, desglosando las actividades de los procesos.
Los diagramas de actividad se incluyeron en la versión 1.3 de UML y es uno de los más utilizados para el
modelado de los aspectos dinámicos del sistema. Los diagramas de actividad se basan en los diagramas de eventos de
Jim Odell y otras técnicas de modelado como SDL y Redes de Petri.
Entonces podemos decir, los diagramas de actividad representan el comportamiento interno de una
operación o de un caso de uso, bajo la forma de un desarrollo por etapas, agrupadas secuencialmente. El propósito de
este tipo de diagramas es: Modelar el flujo de tareas y Modelar Operaciones. Alguna de las características de los
diagramas de actividad es que permiten elegir el orden en que pueden hacerse las cosas y establecen las reglas de
secuencia a seguir.
55
4.4.1. Elementos de los Diagramas de Actividad
Carriles (swimlanes) o Calles
Es una franja vertical que muestra las actividades que son responsabilidad de un determinado objeto. Puede
representar a un actor o trabajador del negocio que participa en el proceso.
Figura 29: Carriles o Calles.
Nodo Inicial
Indica el comienzo del flujo de actividades, es decir el comienzo del flujo de trabajo del proceso de negocio. Se
representa a través de un círculo de color negro y se coloca dentro del carril correspondiente al rol que comienza el
caso de uso. Otra característica de este elemento es que es un estado único para el flujo de actividades.
Figura 30: Nodo Inicial o Estado Inicial.
Nodo Final
Este elemento indica el final del flujo de actividades del proceso. Se representa a través de un círculo de color negro
dentro de un círculo transparente. Se coloca dentro del carril correspondiente al rol que termina el proceso. Puede
haber más de un estado final dependiendo de las diferentes maneras de acabar el proceso.
Figura 31: Nodo Final o Estado Final.
Actividad
56
Representa una tarea, actividad o paso dentro del flujo de trabajo del proceso. Se representa a través de un rectángulo
ovalado en los extremos. El nombre de la actividad debe ser simple y breve, ser un verbo o frase verbal en infinitivo,
incluir el objeto de la actividad y colocarse dentro del símbolo de la actividad.
Figura 32: Representación de una Actividad.
Flujo de Control (Transición)
Este elemento señala la dirección en que fluyen las actividades y representa la secuencia de cada elemento dentro del
diagrama. Al completarse la ejecución de una actividad el flujo de control pasa a la siguiente actividad.
Figura 33: Flujo de Control.
Nodo de Decisiones
Sirven para representar momentos en los que se pueden tomar caminos alternativos. Se representan por un rombo y
se acompaña de la pregunta que debe hacerse el proceso para tomar la decisión.
Figura 34: Nodo de decisión.
Nodo Fork y Nodo Join
Representan actividades que se van a desarrollar simultáneamente. Se representa por una línea horizontal o vertical
gruesa. También se les conoce como barras de sincronización y se utilizan para especificar la división o unión de los
flujos de trabajo paralelos.
57
Figura 35: Nodos de sincronización.
58
5. DESARROLLO DE LA ONTOLOGIA PARA LA ESCUELA DE IN FORMATICA
DE LA PUCV “ONTO INF-PUCV”
En esta sección, se describe el desarrollo de la ontología, de acuerdo a la estructura planteada en la planificación
inicial.
La creación de una ontología en el dominio de la Escuela de Informática está fundamentada en la necesidad
de establecer un lenguaje común para compartir y recuperar los datos a partir de la descripción de los conceptos y
términos que intervienen en los procesos de gestión de la Escuela. Su finalidad es que estos conceptos y términos
puedan ser entendidos por los distintos usuarios de la información.
El dominio del problema es la Escuela de Ingeniería Informática de la PUCV. La Escuela es un centro
dedicado a la enseñanza y a la investigación. Este modelado aborda la Escuela mucho más allá que ser un lugar de
enseñanza. Las distintas perspectivas en que fue vista la universidad son vistas a continuación:
Desde el punto de vista de las Personas. Dentro de este sub dominio de la Escuela se encuentran todas las
personas que integran la Escuela, siendo estos sus Alumnos (pregrado y postrado), Profesores (de planta o no),
autoridades (Secretario Académico, Jefe de Docencia, Director) y Personal (Secretarias, Auxiliares).
Desde el punto de vista de los proyectos de investigación en que incurre. Aquí están tanto las
publicaciones realizados por los docentes de la Escuela, así como las tesis llevadas por los alumnos de Pregrado y
Postgrado.
Desde el punto de vista de eventos realizados. La Escuela realiza actividades como conferencias,
exhibiciones y seminarios. Es necesario mostrar estos separadamente porque no responden a un curso normal de la
actividad académica de la Escuela. Incluso los asistentes a estos actos no necesariamente son alumnos matriculados
en la Escuela.
Desde el punto de vista de la continuidad de los Programas de estudio. Aquí se ven las distintas
modalidades de programas de estudio más allá del Pregrado, como pueden ser el Magíster (Postgrado).
La decisión de modelar la Escuela en una ontología responde, primero que todo, es un entorno conocido por el
autor de este documento. Segundo porque sobre todo en la PUCV, muchas escuelas se encuentran dispersas a nivel
físico y esto probablemente, si no se toman las medias, desencadena en un problema de información dispersa (cada
escuela podría tener su propio sistema de información no compatible con los de otras escuelas incluso con los de la
universidad). La Pontificia Universidad Católica de Valparaíso que cuenta con sedes en varías zonas de la V región.
Así se hace necesario tener una ontología para poder comunicar la información dispersa en sus distintas
dependencias (si es que no posee un sistema unificado). Esta ontología podría servir de punto de partida para un
lenguaje común entre las distintas escuelas y así poder permitir una comunicación más fluida entre ellas.
Es importante mencionar que este trabajo constituye un prototipo de ontología y no una versión final, por lo
tanto han quedado fuera algunas clases y sus asociaciones como las que pueden estar relacionadas con la gestión de
espacios físicos de la Escuela, la Gestión Financiera por nombrar algunas áreas que no se incluyeron en esta
ontología.
59
5.1.Consideraciones y Elecciones de Implementación
5.1.1. Uso de la Metodología METHONTOLOGY
Para la construcción de la ontología se comenzó con incluir todos los términos relevantes del dominio (conceptos,
instancias, atributos, relaciones entre conceptos, etc.), sus descripciones en lenguaje natural, y sus sinónimos y
acrónimos. También se fueron describiendo las relaciones existentes entre los conceptos de la ontología.
Luego se seleccionaron del glosario aquellos términos que son conceptos y que pueden ser identificados
como clases. Esta taxonomía sirve para definir la jerarquía entre los conceptos (clases) del dominio.
En estas etapas se tomaron la opinión de las secretarias de la Escuela, se consideraron documentos como
informes de proyectos de alumnos de la Escuela y se establecieron breves entrevistas con el Secretario Académico, a
continuación los conceptos que aparecían de estas interacciones se procedía a organizar y estructurar el conocimiento
adquirido (modelo conceptual) usando lenguajes de representación (tablas, UML, modelos de jerarquías) los cuales
eran independientes de los lenguajes de implementación en él que finalmente iría la ontología.
Finalmente después de cada iteración se iba modificando la implementación de la ontología en OWL. No
olvidar que esta metodología se basa en prototipos evolutivos.
5.1.2. Utilización de Protégé
Se utilizará la herramienta Protégé para la creación de la Ontología, ya que Protégé permite una implementación
rápida, a través de una interfaz bastante cómoda. Protégé facilita tanto la creación de las clases, como la
instanciación de individuos, además de la implementación de las propiedades, tanto de objetos, como de tipo de
datos, además frece además toda la potencia de OWL-DL para poder incluir reglas sobre las cuales se podrá inferir
conocimiento, con la ayuda de un razonador DIG.
A través de plugins es posible visualizar gráficamente las clases de la ontología, y no sólo eso, sino también
los individuos de cada clase, de una forma didáctica.
A continuación se muestran características de Protégé:
• El código fuente es gratis, bajo la licencia de código abierto Mozzilla Public License (MPL)
• Su extensibilidad es a través del uso de plug-ins
• Concepto de herencia múltiple y jerarquías de relación (con una única clase de instancia); metaclases; soporte
de especificación de instancias; axiomas con restricciones Prolog, FLogic, OIL y el lenguaje de axiomas
Protégé (PAL) mediante plug-ins.
• Lenguaje base usado para codificar la ontología es OKBC (Open Knowledge Base Connectivity), que es un
API para acceder a la base de conocimiento almacenado en sistemas de representación del
conocimiento.(KRSs).
• Plataformas donde puede ejecutarse: Protégé-2000 funciona en cualquier plataforma que soporte la versión
1.3 del JDK.
60
• Visualización de clases y propiedades globales mediante el plug-in GraphViz y vistas de gráficos anidados
con el plug-in de editor Jambalaya.
• Existen plug-ins para añadir y chequear los axiomas que imponen las restricciones: PAL, FaCT.
• Es muy intuitivo y fácil de usar. La creación de ontologías se hace a través de distintos menús y
los datos se introducen mediante formularios.
Protégé es un editor de ontologías, es uno de los editores más utilizados y estables para la construcción de
Ontologías. Fue diseñado por la Universidad de Stanford y continuamente es actualizado.
Está basado en plataforma Java y por lo mismo es extensible y flexible para la construcción de tus estructuras
ontológicas. Puedes construir ontologías en RDF, OWL Y XML schema.
La interface de usuario de Protégé Frames está organizada a través de una serie de tablas donde cada una enfoca
un aspecto particular de la ontología:
Figura 36: Herramienta Protégé.
La interfaz de Clases es un editor de ontologías donde puedes definir las clases y sus jerarquías, los slots y sus
restricciones, las relaciones entre las clases y las mismas propiedades de estas relaciones.
La interfaz de Formularios genera un formulario Default para que los slots adquieran instancias que ya han
sido especificadas. Este formulario puede ser customizado por ti, o sea puede ser modificado por el usuario,
cambiando el tipo de ventanas, tamaños, etc. De acuerdo a como quieras que sean vistas en pantalla.
61
La interfaz de instancias es una herramienta de adquisición de conocimiento que tú puedes usar para
adquirir instancias de las clases definidas en tu ontología.
El editor Protégé OWL es una extensión de Protégé que soporta lenguaje Web para ontologías, incluye
descripciones de Clases, propiedades e instancias para la construcción de tus ontologías. Este editor también puede
ser usado para editar código RDF. Además tiene algunas extensiones como el OWLViz con el puedes ver la
ontología OWL de forma gráfica.
Éstas y muchas otras más son las ventajas que ofrece Protégé para la construcción y edición de Ontologías y
por las cuales ha sido elegida como la herramienta a utilizar en el desarrollo de este proyecto.
5.1.3. Utilización de Pellet
Pellet es un razonador de OWL-DL basado en Java. Mediante su uso es posible validar, comprobar la consistencia de
ontologías, clasificar la taxonomía y contestar a un subconjunto de consultas RDQL (conocido como consultas a
ABox en terminología del DL). Soporta todas las construcciones del OWL DL incluyendo las relacionadas con los
nominales, es decir, owl:oneOf y owl:hasValue. Recalcar que este razonador se utilizo para comprobar la
consistencia de la ontología.
5.1.4. Lenguaje, OWL
OWL es el acrónimo del inglés Ontology Web Language [62] o Lenguaje ontológicos para la Web, un lenguaje de
marcado para publicar y compartir datos usando ontologías en la WWW. OWL tiene como objetivo facilitar un
modelo de marcado construido sobre RDF y codificado en XML. Tiene como antecedente DAML+OIL, en los
cuales se inspiraron los creadores de OWL para crear el lenguaje. OWL está diseñado para usarse cuando la
información contenida en los documentos necesita ser procesada por programas o aplicaciones, en oposición a
situaciones donde el contenido solamente necesita ser presentado a los seres humanos. OWL puede usarse para
representar explícitamente el significado de términos en vocabularios y las relaciones entre aquellos términos. Esta
representación de los términos y sus relaciones se denomina una ontología.
En realidad, OWL es una extensión del lenguaje RDF y emplea las tripletas de RDF, aunque es un lenguaje
con más poder expresivo que éste. OWL posee más funcionalidades para expresar el significado y semántica que
XML, RDF, y RDFS, pero OWL va más allá que estos lenguajes pues ofrece la posibilidad de representar contenido
de la Web interpretable por máquina. OWL es una revisión del lenguaje de ontologías Web DAML+OIL que
incorpora lecciones aprendidas desde el diseño y aplicaciones de DAML+OIL. El lenguaje OWL tiene 3 sub-
lenguajes que incrementan su expresión: OWL Lite, OWL DL, y OWL Full.
OWL Lite:
• Apoya a esos usuarios que necesitan sobre todo una jerarquía de la clasificación y apremios simples.
• Permite solamente valores de 0 ó 1. proporciona una trayectoria rápida de la migración para otras
taxonomías.
• OWL Lite tiene una complejidad formal más baja que OWL DL
62
OWL DL:
• Expresividad máxima.
• El OWL DL incluye todas las construcciones de la lengua del OWL, pero pueden ser utilizadas solamente
bajo ciertas restricciones.
• OWL DL es así que nombrada debido a su correspondencia con lógicas de la descripción.
OWL Full:
• Expresividad máxima y la libertad sintáctica de RDF (sin garantías de cómputo).
• OWL permite que una ontología aumente el significado (RDF o OWL) del vocabulario predefinido.
5.2. Glosario de Términos
La siguiente tabla, presenta un listado de los términos relevantes, identificados en el dominio de la ontología, su
descripción en lenguaje natural y el tipo.
CLASE DESCRIPCION
ACTIVIDAD_ACADEMICA Corresponde a las que se realizan dentro del marco de un curso, pueden ser:
Cátedra, ayudantía, Taller o Laboratorio.
ASIGNATURA Componente del currículo de grado o título relacionado con las actividades de
enseñanza-aprendizaje de una determinada área o disciplina. Pueden ser Optativas,
Obligatorias o Generales.
AVANCE_CURRICULAR Corresponde a los Asignaturas ya aprobadas por los Alumnos de un determinado
Plan de Estudio.
CARPETA_ALUMNO Corresponde a una carpeta que es preparada para el Alumno para motivos de su
titulación, esta compuesta por una determinada documentación como por ejemplo:
certificado de nacimiento, de notas entre otros.
CARRERAS Carreras de especialización de la Escuela. Hoy la escuela posee dos carreras
Ingeniería Civil Informática e Ingeniería Ejecución en Informática.
CONSTANCIA Documento que da una constancia de que un Alumno haya Cursado cierta
asignatura o que es Alumno de alguna carrera.
CURSO Corresponde a la Asignatura dictada en un período académico determinado y que se
estructura en paralelos.
DIRECCION Corresponde al domicilio de una persona.
EMPRESA Entidades externas que interactúan con la Escuela como por ejemplo a través de las
Prácticas.
63
ESPACIO_FISICO Corresponden a las dependencias de la Escuela como salas, laboratorios.
EVENTOS Evento organizado por la Escuela. Pueden ser seminarios, exhibiciones,
conferencias.
HORARIO Horario en que se realiza alguna actividad académica u evento.
INFORME_DE_PRACTICA Corresponde al Informe que realiza un Alumno una vez que termina su Práctica y
corresponde a una parte de su evaluación.
MALLA_CURRICULAR Componente del Plan de Estudio de una carrera, que establece las asignaturas a cursar,
agrupadas en períodos, y los pre-requisitos necesarios para su inscripción.
PERSONA Personas que forman parte de la Escuela, como Alumnos, Profesores, Secretarias, etc.
PLAN_DE_ESTUDIO Exigencias establecidas dentro de una carrera para la obtención de un título y/o grado en
una carrera.
PRACTICA Trabajo que realiza el alumno en las dependencias de alguna empresa como parte de su
formación.
PROYECTO Proyectos que realizan miembros de la Escuela, ya sea como parte de su titulación en el
caso de los alumnos o como investigación en el caso de los profesores.
TIPO_DE_INGRESO Forma a través de la cual el Alumno logro dicha condición.
PROPIEDAD DE OBJETO DESCRIPCION
A_cargo_de Identifica que Persona tiene a cargo cierta Actividad Académica.
Actividades_del_curso Identifica las Actividades Académicas que forman parte de un curso por
ejemplo Cátedras, Ayudantías u Laboratorio.
Asigna Corresponde a la facultad del Jefe de Docencia de asignar los horarios
(Cátedras, Ayudantías).
Asignado_en_un_horario Tiene como dominio los espacios físicos y tiene que ver con los horarios
en los cuales han sido asignados estos tanto para eventos como para
actividades académicas.
Asignatura_Prerequisito Tiene que ver con las asignaturas que son requisitos para poder cursar
otra asignatura.
Contiene_Asignaturas Define las asignaturas que conforman una malla curricular de algún plan
de estudio.
Dicta_curso Indica que profesor dicta un determinado curso.
Dio_la_practica Indica que cierta Empresa dio una determinada práctica.
Es_Autor_de_Tesis_Postgrado Indica que alumno de postgrado es el autor de una cierta tesis.
Es_Autor_de_Tesis_Pregrado Indica que alumno de pregrado es el autor de una cierta tesis.
Es_Dictado_por Indica que el curso es dictado por cierto profesor.
Es_direccion_de Representa que una direccion pertenece a cierta Empresa o Persona.
64
Informe_Realizado_Por Indica que alumno realizo un cierto informe de Práctica.
Ingreso_a_traves_de Indica que un Alumno ingreso a la Universidad mediante un determinado tipo
de ingreso, ya sea a través de la PSU, Ingreso especial.
Pertenece_al_Plan Indica la malla curricular que pertenece a cierto plan de estudio.
Plan_de_la_carrera Indica los planes de estudio que posee cierta carrera.
Profesor_Guia Indica el profesor que hace de guía en un proyecto de título.
Realiza Indica que un alumno realiza una práctica.
Realiza_Informe Indica que un alumno de pregrado realiza un informe de práctica.
Tiene_Actividades Indica las actividades académicas academicas que pertenecen a un cierto
curso.
Tiene_como_Autor Indica el alumno autor de un proyecto de título.
PROPIEDAD DE DATO DESCRIPCION
Alumnos_Inscritos Indica el número de Aalumnos inscritos en un Ccurso. Tipo de dato entero.
Apellido_Materno Indica el apellido materno de una Persona. Tipo de dato string.
Apellido_Paterno Indica el apellido paterno de una Persona. Tipo de dato string.
Autor_Proyecto Indica el autor de un Proyecto de Título. Tipo de dato string.
Autor_Tesis Indica el autor de una Tesis. Tipo de dato string.
Calle Corresponde a la calle de una Dirección (domicilio) de una Persona. Tipo de
dato string.
Capacidad_personas Corresponde a la capacidad en cuanto a Personas de un Espacio Físico. Tipo
de dato entero.
Celular Corresponde al número de teléfono móvil de una Persona. . Tipo de dato
entero.
Clave Corresponde a la clave de un Horario. Tipo de dato entero.
Clave_espacio Corresponde a una forma de identificación de un Eespacio Físico como por
ejemplo IBC 2-3. Tipo de dato string.
Codigo_Asignatura Corresponde a un codigo que identifica a una Asignatura. Tipo de dato string.
Codigo_Carrera Corresponde a un codigo que identifica a una Carrera. Tipo de dato entero.
Comuna Corresponde a la comuna de una Dirección. Tipo de dato string.
Creditos_Asignaturas_Generales Corresponde a los créditos que son una especie de puntuación que tienen las
Asignaturas Generales. Esta puntuación es igual para todos los Alumnos de la
Universidad. Tipo de dato entero.
Creditos_Asignaturas_Obligatorias Corresponde a los créditos que son una especie de puntuación que tienen las
Asignaturas Obligatorias que forman parte de una Malla. Tipo de dato entero.
65
Creditos_Asignaturas_Optativas Corresponde a los créditos que son una especie de puntuación que tienen las
Asignaturas Optativas que forman parte de una Malla. Tipo de dato entero.
Cupo Cantidad de Alumnos que pueden ser inscritos en un Curso. Tipo de dato
entero.
Decreto Corresponde al Decreto que establece un Plan de Estudio. Tipo de dato string.
Departamento Corresponde al departamento en donde vive una Persona, es decir es parte de
la dirección (domicilio) de una Persona. Tipo de dato string.
Día Corresponde al día de un horario, por ejemplo día martes clave 9-10. Tipo de
dato string.
Duracion_Carrera_Semestres Cantidad de semestres que dura una carrera. Por ejemplo la Carrera de
Ingeniería Civil Informática dura 12 semestres. Tipo de dato entero.
Email Corresponde al correo electrónico de una Persona. Tipo de dato string.
Fecha_de_Inicio Corresponde a la fecha en que comienza un periodo de Práctica. Tipo de dato
Date.
Fecha_de_Termino Corresponde a la fecha en que termina un periodo de Práctica. Tipo de dato
Date.
Fecha_Inicio Corresponde a la fecha en que se realizara (comienzo) un determinado
Evento. Tipo de dato Date.
Fecha_Fin Corresponde a la fecha en que se termina un determinado Evento. Tipo de
dato Date.
Giro Corresponde al giro de una Empresa. Tipo de dato string.
Grado Corresponde al grado que otorga un determinado Plan de Estudio. Tipo de
dato string.
Maximo_Semestres Corresponde al máximo de semestres que puede cursar un Alumno para poder
terminar un Plan de Estudio. Tipo de dato entero.
Nombres Corresponde al primer nombre y si corresponde al segundo nombre de una
Persona. Tipo de dato string.
Nombre_Asignatura Corresponde al nombre de una Asignatura. Tipo de dato string.
Nombre_Carrera Corresponde al nombre de una Carrera. Tipo de dato string.
Nombre_Empresa Corresponde al nombre de una Empresa. Tipo de dato string.
Nombre_Evento Corresponde al nombre de un Evento. Tipo de dato string.
Nombre_Proyecto Corresponde al nombre de un Proyecto. Tipo de dato string.
Nombre_Seminario Corresponde al nombre de un Seminario. Tipo de dato string.
Numero Corresponde al número en donde vive una Persona, es decir es parte de la
dirección (domicilio) de una Persona. Tipo de dato entero.
RUT Corresponde al RUT de una Persona. Tipo de dato string.
66
Titulo Corresponde al titulo que se obtiene al finalizar un Plan de Estudio. Tipo de
dato string.
Titulo_Tesis Corresponde al título de una Tesis. Tipo de dato string.
Version_malla Corresponde a la versión de la malla curricular. Tipo de dato string.
Telefono_Fijo Corresponde al teléfono fijo que sirve de contacto con una Persona. Tipo de
dato string.
Región Corresponde a la región en donde vive una Persona, es decir es parte de la
dirección (domicilio) de una Persona. Tipo de dato string.
Provincia Corresponde a la provincia en donde vive una Persona, es decir es parte de la
dirección (domicilio) de una Persona. Tipo de dato string.
Promocion_de_Ingreso Corresponde al año de ingreso a la Carrera de un Alumno. Tipo de dato
entero.
CLASE SUBCLASE PROPIEDAD DE DATO PROPIEDAD DE OBJETO
Ayudantia Tiene_Horario Actividades_Academicas Catedra Actividades_del_curso Laboratorio A_cargo_de Taller
Tipo_Asignatura: String Asignatura_Prerequisito Estudios_Generales Sigla_Asignatura: String Pertenece_a_una_malla Asignatura Obligatoria Nombre_Asignatura: String
Optativa Prerequisito_Semestre_Cursado: Int
Codigo_Asignatura: String Duracion_Asignatura: String
Avance_Curricular
Carpeta_Alumno Pertenece_a_un
Carrera Codigo_Carrera: Int Tiene_un_Plan Duracion_Carrera_Semestres: Int Nombre_Carrera: String
Constancia Es_Solicitada
Cupo: Int Es_Dictado_por Curso Periodo_Academico: String Pertenece_a_la_Asignatura Alumnos_Inscritos: Int Tiene_Actividades Paralelo: Int
67
Decanato
Provincia: String Es_direccion_de Region: String Poblacion_Villa_Condominio: String Direccion Departamento: String Calle: String Comuna: String Numero: Int
Direccion_de_Procesos_Docentes
Nombre_Empresa: String Dio_la_practica Empresa Giro: String Tienen_Direccion_Permanente
Clave_Espacio: String Asignado_en_un_horario Espacio_Fisico Capacidad_personas: Int Descripcion: String
Conferencias Nombre_Evento: String Tiene_Horario Eventos Exhibición Lugar_Evento: String Seminario Fecha_inicio: Date Fecha_Fin: Date
Expediente
Horario Dia: String En_un Clave: String
Informe_Practica Informe_Realizado_Por
Informe_Licenciatura
Contiene_Asignaturas Malla_Curricular Version_Malla: String Pertenece_al_Plan
Apellido_Paterno: String Tienen_Direccion_Permanente Alumnos Apellido_Materno: String Director Nombres: String Jefe_Docencia Email: String Persona Jefe_Extension Telefono_Fijo: String
68
Jefe_Investigacion RUT: String Personal Celular: Int Secretario_Academico Profesor
Creditos_Asignaturas_Optativas: Int Plan_de_la_carrera Grado: String Tiene_una_Malla Postgrado Tasa_de_Avance: Float Decreto: String
Creditos_Asignaturas_Generales:Int
Plan_de_Estudio Maximo_Semestres: Int
Creditos_Asignaturas_Obligatorias: Int
Pregrado Version: Int
Numero_de_Practicas_Profesionales: Int
Titulo: String
Id_Practica: String Realizada_por Practica Fecha_de_Inicio: Date Se_Realiza_en Fecha_de_Termino: Date
Proyecto_de_Investigacion Titulo_Proyecto: String
Proyecto Nombre_Proyecto: String Proyecto_de_Titulo
Rector
Secretaria_General
Tesis_Postgrado Autor_Tesis: String Tesis Titulo_Tesis: String Tesis_Pregrado
Tercera_Oportunidad
Especial Tipo_de_Ingreso PSU Resolucion_DAE
Seminario Nombre_Seminario: String
Profesor Sigla_Profesor: String Dicta_curso
69
Realiza_practica Es_adscrito_a_un_Plan
Alumnos Ingreso_Plan_actual: String Tiene_una_Direccion_de_Estudiante
Tiene_carpeta Tuvo_un_Ingreso Promocion_de_Ingreso: Int Posee_Avance Solicita Realiza_la_ayudantia
Conferencia Tema: String
Proyecto_de_Titulo Autor_Proyecto: String Profesor_Correferente Profesor_Guia Tiene_como_Autor
Alumno_Pregrado Realiza_Informe Es_Autor_de_Tesis_Pregrado
Director Tiene_que_Ser
Jefe_Docencia Tiene_que_Ser Asigna
Secretario_Academico Tiene_que_Ser
Jefe_Investigacion Tiene_que_Ser
Alumno_Postgrado Es_Autor_de_Tesis_Postgrado
Ayudantia Tiene_Ayudante
Proyecto_de_Investigacion Investigador
70
5.3. Métricas del Modelo OWL Obtenido
El modelo owl está compuesto por un total de 65 clases, 106 propiedades de las cuales 44 son de tipo
ObjectProperty, 62 de tipo DataType. La siguiente figura ilustra el resumen proporcionado por Protégé en cuanto a
la estructura de la Ontología Desarrollada.
Figura 37: Métricas del Modelo OWL.
La figura 37 ilustra el resumen proporcionado por Protégé en cuanto a la estructura de la Ontología
Desarrollada.
71
5.4. Detalle de Parte del Código OWL
<owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Contiene_Asignaturas"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Asignatura"/> </owl:someValuesFrom> </owl:Restriction>
Esta restricción indica que una Malla_Curricular Contiene al menos una Asignatura.
<owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Pertenece_al_Plan"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:someValuesFrom> </owl:Restriction> Esta restricción indica que una Malla_Curricular Pertenece al menos a un Plan de Estudio.
<owl:ObjectProperty rdf:about="#Realiza_practica"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Practica"/>
<owl:inverseOf> <owl:ObjectProperty rdf:ID="Realizada_por"/> </owl:inverseOf>
</owl:ObjectProperty>
Es trozo de código define la propiedad de objeto Realiza_practica cuyo dominio es la clase Alumnos y su rango es la
Clase Practica, además define que esta propiedad corresponde a la inversa de Realizada_por que por ser la inversa
tiene como dominio Practica y como rango Alumnos.
<owl:ObjectProperty rdf:about="#Asignatura_Prerrequisito"> <rdfs:domain rdf:resource="#Asignatura"/> <rdfs:range rdf:resource="#Asignatura"/>
</owl:ObjectProperty>
Esta es la manera en que se define en OWL la Propiedad de Objeto Asignatura _ prerrequisito e indica que una
asignatura tiene como prerrequisito otra Asignatura, es decir tiene como dominio la clase Asignatura y la misma
clase como rango.
<owl:DatatypeProperty rdf:ID="Sigla_Profesor"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Profesor"/>
</owl:DatatypeProperty>
Aquí se observa la propiedad de dato Sigla_Profesor de la clase Profesor y que es del tipo string.
72
<owl:DatatypeProperty rdf:about="#Apellido_Paterno"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Apellido_Materno">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Nombres">
<rdfs:domain rdf:resource="#Persona"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Email">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Telefono_Fijo">
<rdfs:domain rdf:resource="#Persona"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="RUT">
<rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Celular">
<rdfs:domain rdf:resource="#Persona"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty>
En el trozo de código OWL se muestran las propiedades de tipo de datos de la clase Persona: Apellido_Paterno del
tipo String, Apellido_Materno del tipo String, Nombres del tipo String, Email del tipo String, Telefono_Fijo del tipo
String, el RUT del tipo string y finalmente Celular del tipo String.
<owl:ObjectProperty rdf:about="#Es_Dictado_por"> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Dicta_curso"/> </owl:inverseOf> <rdfs:range rdf:resource="#Profesor"/> <rdfs:domain rdf:resource="#Curso"/>
</owl:ObjectProperty>
Finalmente este código indica la propiedad de objeto Es_Dictao_por que corresponde a la propiedad inversa de
Dicta_curso, el Dominio de la propiedad Es_Dictado_por tiene como dominio la clase Curso y su rango es Profesor.
Para ver más detalles del código OWL obtenido ver ANEXO 3.
73
5.5. Taxonomía Conceptual
Figura 38: Taxonomía Conceptual.
Una vez obtenido el glosario de términos, se construyen los árboles de clasificación de conceptos, que serán
las súper-clases de las cuales se derivan otras. La figura 38 muestra los conceptos de clasificación identificados y sus
conceptos derivados.
74
5.6. Otras Vistas de la Ontología
Al crear todas las clases y subclases en Protégé, las taxonomías mostradas fueron las siguientes:
En la figura 39 se muestra la clase Curso, la cual tiene como propiedad de datos Cupo, Paralelo,
Alumnos_Inscritos, además de las propiedades de objetos: Es_Dictado_Por, haciendo alusión al Profesor que dicta
un determinado Curso y Pertenece_a_la_Asignatura. En la figura 39 también se puede ver que la propiedad
Es_dictado_Por tiene como dominio la clase Curso y como rango la clase Profesor, además se puede ver que la la
propiedad debe existir. Para la propiedad de datos Alumnos_inscritos se establece una cardinalidad mayor o igual a 1
alumno. En el caso de Cupo la cardinalidad tambien es de mayor o igual que uno .en la figura se ve que un Curso
debe pertenecer a una Asignatura y solo a una y que un Curso tiene que poseer a lo menos una Actividades
Académicas ya sea Cátedra, Ayudantía, Laboratorio, Taller.
Figura 39: Vista de la Clase Curso.
75
Figura 40: Vista de la Clase Actividades_Academicas.
En la figura 40 podemos observar la Súper Clase Actividades_Academicas, la cual tiene como subclases
Taller, Laboratorio, Cátedra, Ayudantía. También la figura muestra las propiedades de objeto de esta clase como
Actividades_del_Curso cuyo dominio es Actividades_Academicas y su rango es la clase Curso, la cardinalidad de
esta propiedad es de uno, es decir la actividad debe ser una actividad académica de un solo curso. Las Actividades
Académicas deben estar A_cargo de una Persona que en el caso de la Cátedra es un Profesor, en el caso de una
Ayudantía es un Alumno y en el Laboratorio puede ser tanto un Profesor como un Alumno.
76
Figura 41: Vista de la Súper Clase Personas.
En la figura 41 se representa la súper clase Persona la cual tiene como Propiedad de tipo de Datos RUT que
es de tipo String, Apellido_Paterno cuya cardinalidad es uno, Apellido_Materno de cardinalidad uno, Nombres de
cardinalidad mayor o igual a uno, Telefono_Fijo, Email siendo todos del tipo String, esta clase tiene como propiedad
de objeto Tiene_Direccion_Permanente cuyo rango es la clase Dirección y que tiene como restricción que tiene que
tener a lo menos una y solo una Dirección. La clase Persona tiene como subclases Alumnos, Director,
Jefe_Docencia, Jefe_Extensión, Jefe_Investigacion, Personal, Profesor, Secretario_Academico. La clase Personal
tiene como subclases: Encargado_Laboratorio, Administrador_Recursos_TI, Secretaria_Docencia, Auxiliar,
Secretaria_Postgrado y Secretaria_Direccion. Se puede ver también que la clase Jefe_Investigacion al igual que las
clases Director, Jefe_Docencia, Secretario_Academico tienen una propiedad de objeto llamada Tiene_que_Ser un
Prosefor de Jornada_Completa. En la clase Profesor se ve que esta tiene una propiedad de tipo de dato llamada
Sigla_Profesor y la propiedad de objeto Dicta_Curso. En el caso de la clase Alumnos podemos observar la propiedad
de objeto Realiza_la_Ayudantia cuyo rango es la clase Ayudantía, la propiedad de objeto Tiene_Carpeta,
Ingreso_a_traves_de, Es_adscrito_a_un_Plan y Realiza_Practica cuyos rangos Carpeta_Alumno, Tipo_de_Ingreso,
Plan_de_Estudio, Práctica.
77
Figura 42: Vista de la Clase Alumnos.
La Figura 42 muestra la clase Alumnos, la cual tiene una propiedad de tipo de dato llamada
Ingreso_Plan_Estudio del tipo String, además de las propiedades de objeto mencionadas en la descripción de la
figura anterior. En la figura se ve que la clase Alumnos tiene como subclases Alumno_Pregrado y
Alumno_Postgrado. En el caso de un Alumno este debe tener una Dirección de Estudiante y una Carpeta_Alumno
por obligación, un Alumno_Pregrado debe estar adscrito a un Plan de Estudio de Pregradoy debe realizar Practicas
Profesionales y un Informe de Práctica, los Alumnos_Postgrado deben estar adscrito a un Plan de Estudio de
Postgrado.
78
6. Validación de la Ontología mediante la Diagramación de Procesos de la Escuela
Utilizaremos la diagramación de algunos de los procesos para validar la Ontología, es decir, para validar los términos
que aparecen en ella. Los términos que provengan de la Ontología serán subrayados en los diagramas de actividad
que representan los procesos.
Para que los términos de la Ontología que aparezcan en el diagramado queden aun más claros mostraremos
una vista de la ontología en la cual aparecerán dichos términos.
La idea es que junto con la ontología los diagramas de los proceso ayuden a dar una imagen más clara del
funcionamiento de la Escuela y así permitir que por ejemplo los futuros desarrolladores de sistemas para la Escuela
tengan una visión más completa de ella y de sus necesidades.
Además de servir para la validación de la Ontología se espera que ésta diagramación de procesos sirva
dentro de la Escuela para:
• Capacitación de personal nuevo en la Escuela.
• Verificación del proceso real respecto del proceso diseñado.
• Detección de actividades o grupos de actividades que reducen la calidad y la productividad.
• Facilitan la coordinación y la comunicación.
• Facilitan el análisis de opciones de mejoramiento.
En el diagrama del proceso 1 se puede observar la aparición de clases que se encuentran representadas en la
ontología. Por ejemplo los actores Jefe de Docencia, Secretaria de Docencia y Profesor, estos corresponden a
subclases de la clase Persona dentro de la Ontología. Dentro de las actividades de este proceso se encuentran
conceptos como Ayudantes que es el nombre que recibe el Alumno que realiza una Ayudantía, entonces aquí vemos
representada la propiedad de objeto Realiza_la_Ayudantia, también este termino aparece en la propiedad de objeto
Tiene_Ayudante que tiene como dominio la clase Ayudantia y como rango la clase Alumno. Otra clase que aparece
en el diagrama de este proceso es Asignatura.
En el diagrama 2 aparecen las subclases de la clase Persona, estas son Alumno, Secretaria de Docencia quien
además es subclase de Personal, Jefe de Docencia. Otra clase que aparece es Práctica, Avance Curricular y Plan de
Estudios. El Plan de Estudio corresponde a las exigencias establecidas dentro de una Carrera para la obtención de un
Título y/o Grado en una Carrera, el Avance Curricular corresponden a las exigencias de Tasa de Avance, Periodo
Aplicación, máximo de semestres, entre otras.
En el proceso 3 aparecen clases como Alumno, Secretaria de Docencia, Jefe de Docencias todas ellas subclases
de la clase Persona. Además en este proceso aparece un concepto que podría ser tomado como una clase en un
trabajo futuro sobre esta ontología como es Acta.
79
Entrega Cantidad de
Ayudantes Necesarios
por Asignatura para el
Semestre
Elaboración Lista de Ayudantes
Necesarios por Asignatura
Publica la lista de Ayudantías
disponibles y pone a disposición
del Alumno el formulario de
Postulación
Llena Formulario
Postulación
Archiva Formulario
Postulación
Envio de Lista de
Postulantes
Recepción Lista de
Ayudantes para sus
Asignaturas
Selección de Alumnos
para las Ayudantias
Entrega de Ayudantes
Seleccionados
Publicación Lista de
Ayudantes
Seleccionados
PostulanteSecretaria Docencia ProfesorJefe Docencia
Diagrama 1: Proceso de Selección de Ayudantes.
Para este proceso se quiere que se comience a utilizar el factor de riesgo (que es un factor que se puede obtener de
la Súper Ficha del Alumno desde el Navegador Académico), como un factor para la selección del ayudante.
80
Solicitud
Autorización
Practica
Recepción Solicitud
Autorización Practica
Verificación Requisitos Alumno según
Reglamento para realizar Practica
(Avance Curricular v/s Plan de Estudio)
Indica se Acepta
Solicitud
Indica No se
Acepta Solicitud
Verificación Correcta Verificación Incorrecta
Archiva Solicitud
Autorizada
Publica
Resultados
Solicitudes
AlumnoSecretaria
Docencia
Jefe
Docencia
Diagrama 2: Proceso de Solicitud de Autorización para realizar Práctica
Al finalizar este proceso se encuentra disponible una carta que certifica que el Alumno está en condiciones y autorizado por
la Escuela para realizar la Práctica Profesional.
Una situación que se puede dar en este proceso es que el alumno se encuentre cursando algún ramo que le
permitiría cumplir con los requisitos, en estos casos la solicitud queda pendiente hasta que se tienen los resultados de esos
ramos para ver si los aprobó.
En caso de ser la práctica de un Alumno de Ejecución: el requisito es tener el Sexto semestre aprobado. En caso de ser un alumno de Civil el requisito es haber aprobado el Octavo semestre en caso de ser la Primera Practica y el Décimo en caso de ser la segunda Práctica
Una vez finalizado este proceso y habiendo obtenido la autorización el Alumno esta en condiciones de Inscribir la Practica
81
Alumno
Solicitud de
Recorrección de Acta
Recepción Solicitud
de Recorrección de
Acta
Verificación con
Profesor Involucrado
Elaboración Memo
según formato
establecido
Verificación Correcta
Secretaria Docencia Jefe Docencia Dirección
Docencia (CC)
Firma Memo
Entrega Memo a
Dirección DocenciaRectificación Acta
Despacho de 2
copias de Resolución
Recepción de
Resolución
Archivar copia de
Resolución
Ingresar nueva
Nota al Sistema
Retiro Resolución
Verificación Incorrecta
Diagrama 3: Proceso de Rectificación de Actas
Esto sucede cuando un profesor se equivoca en las notas de un ramo. En este caso el alumno puede pedir que estas se le
rectifiquen.
82
En el proceso 4 encontramos las subclases de Persona como Alumno, Secretaria de Docencia, Jefe de Docencia,
siendo además estas dos ultimas clases subclases de la clase Personal. Otra clase que aparece aquí es Dirección de Procesos
Docentes, Decanato, Tercera Oportunidad y Alumno. Ramo es un concepto que aparece dentro del diagrama pero no dentro
de la ontología, ya que el término más apropiado dentro de la ontología debiera ser Asignatura.
El proceso 5 diagrama el proceso de levantamiento de prerrequisito, el concepto de prerrequisito aparece dentro de
la ontología representado como una propiedad de objeto cuyo dominio es la clase Asignatura y su dominio es la misma
clase Asignatura, el concepto de prerrequisito corresponde a que para poder cursar una determinada Asignatura es necesario
haber cursado y aprobado otra Asignatura. En este proceso nuevamente aparecen las clases Alumno, Secretaria de
Docencia, y Jefe de Docencia.
En el proceso 6 aparecen las clases Constancia, Alumno, Secretaria de Docencia y Secretario Académico.
En el proceso 7 las clases que en él aparecen son Alumno, Secretaria de Docencia, Jefe de Docencia y Carpeta
Alumno.
En el proceso 8 tiene que ver con el concepto de Practica Profesional que realizan los Alumnos a lo largo de la
Carrera. Las clases que aparecen en este proceso son Alumno, Secretaria de Docencia, Empresa y Profesor, siendo la clase
principal Práctica, también aparece la clase Informe de Práctica.
Finalmente en el proceso 9 aparecen las siguientes subclases de la clase Persona: Alumno, Secretaria de Dirección,
Secretaria de Docencia y Secretario Académico. Otras clases que corresponden a actores importantes de este proceso son
Decanato, Dirección de Procesos Docentes, Secretaría General y Director.
Dentro del proceso aparece la verificación del cumplimiento de haber aprobado todas las Asignaturas Obligatorias
al 10º Semestre, además de que el Alumno cumpla con tener aprobados 9 créditos de Asignaturas Optativas y 10 créditos de
Asignaturas de Estudios Generales, en esta verificación aparecen las subclases de la clase Asignatura, Obligatoria, Optativa
y Estudios Generales, además aparecen las propiedades de tipo de datos como Créditos de Asignaturas Optativas, Créditos
de Asignaturas Obligatorias y Créditos de Estudios Generales.
Otras clases que aparecen en este proceso son Informe de Licenciatura, Expediente. Este proceso además sugiere
ciertos conceptos que podrían ser considerados como clases en un futuro estos son: Decreto, Licenciado y Hoja de
Antecedentes.
83
Alumno
Solicitud de
Tercera
Oportunidad
Recibe Solicitud de
Tercera Oportunidad
Secretaria Docencia
Verifica si puede
otorgar la Tercera
Oportunidad
Firma y Timbra la
Autorización Para
Cursar un Ramo por
Tercera
Aprobada
Recibe Autorización
de Tercera
Oportunidad
Publicación de
Resultados
Solicita Liberación
del Alumno
Jefe Docencia
Libera al Alumno
para que pueda
Cursar el Ramo
Dirección de
Procesos
Docentes
Rechazada
Envía Solicitud de
Tercera Oportunidad
para Resolución del
Decanato
Decanato
Decide la Otorgación
de la Tercera
Oportunidad
Aprobada
Rechazada
Recibe Resolución
Negativa
Comunica Resolución
Positiva
Diagrama 4: Proceso de Solicitud de Tercera Oportunidad
El Jefe de Docencia otorga las dos primeras Terceras Oportunidades. La primera se llama Invoco la cual es la única solicitud sin
Resolución. Una vez que el Alumno queda liberado deberá inscribir el ramo durante las tutorías.
84
Alumno Solicita
Levantamiento Pre-Requisito,
llenando el Formulario de
Solicitud
Recibe Solicitud
Levantamiento Pre-Requisito
Fin Fecha de Recepción de
Solicitudes
Recepción de Lista de
Alumnos que Solicitan
Levantamiento de Pre-
Requisito
Archiva Solicitud
Estudia el caso de cada
Alumno y decide si Acepta o
No el Levantamiento
Entrega Lista de Resultado de
las Solicitudes
Publicación de Resultado de
las Solicitudes
AlumnoSecretaria
Docencia
Jefe
Docencia
Diagrama 5: Proceso Levantamiento de Pre-Requisito.
Cada caso de este proceso va depender de la situación académica del Alumno y del Ramo al cual quiera hacerle
levantamiento de Pre-Requisito. Si se acepta el Levantamiento de Pre-Requisito el Alumno deberá Inscribir el ramo en las
tutorías.
85
Diagrama 6: Proceso de Solicitud de Constancias
86
Recepción Lista Alumnos
matriculados primer año
Recepción Lista Alumnos
matriculados primer año
Archivar fichas Alumnos en sus
respectivas Carpetas
Preparar Carpeta Alumnos
Archiva Carpetas
Secretaria Docencia Jefe Docencia
Realización de Ficha única por
Alumno, ingresando foto
Entrega Ficha Personal y foto
Alumno
Solicita Ficha Personal al
Alumno y foto
Diagrama 7: Proceso de Ingreso de Alumnos Nuevos de Primer Año.
Este proceso comienza una vez terminadas las Matriculas de Alumnos de Primer año y termina con la consolidación de la
información de la ficha personal junto a la foto que entrega el Alumno en sus primeros días de clases.
87
Diagrama 8: Proceso de Inscripción, Realización y Evaluación de Práctica Profesional.
Este proceso se realiza una vez que el Alumno es Autorizado para Realizar la Práctica. El Alumno podría Solicitar el Seguro
Escolar que es un documento que muchas Empresas solicitan al momento de recibir Alumnos en Práctica. Generalmente la
práctica se lleva a cabo durante el verano.
88
Alumno
Solicita Grado
Licenciado
Verifica el no
otorgamiento del
grado al Alumno
Secretaria
Dirección
Firma Hoja de
Antecedentes
Solicita Formulario
Informe Licenciatura
Secretaria
DocenciaSecretario
Académico
Verificación de todas
las Asignaturas
Obligatorias del 10º
semestre aprobadas
Verifica si Alumno tiene
aprobados 9 créditos de
Asignaturas Optativas y 10
Créditos de Estudios
Generales
Elabora Formulario
Informe Licenciatura
Firma Formulario
Informe Licenciatura
Envía Formulario
Informe Licenciatura
Verifica
Documentación
Requerida
DecanatoDirección
de Procesos
Docentes
Secretaria
General
Director
Continua en la
siguiente pagina
La documentación
requerida: Certificado de Nacimiento, Licencia de Enseñanza
Media, Certificado de Calificaciones
para Licenciado
89
AlumnoSecretaria
Dirección
Secretaria
DocenciaSecretario
Académico
Recibe Formulario
Informe Licenciatura
Elabora Expediente
Firma
Expediente
Elabora Certificado
para Tramite
Licenciatura
Firma Certificado
para Tramite
Licenciatura
Elabora Ficha Datos
Personales del Alumno
para el Decanato
DecanatoDirección
de Procesos
Docentes
Secretaria
General
Envia Expediente
para ser firmadoFirma Expediente
Director
Firma Expediente
Viene
de la pagina anterior
Continua en la
siguiente pagina
90
AlumnoSecretaria
Dirección
Secretaria
DocenciaSecretario
Académico
Envía Expediente , Hoja de
Antecedentes, Certificados
de Tramite Licenciatura y la
demás DocumentaciónVerificación
Documentación
Completa
DecanatoDirección
de Procesos
Docentes
Tramitación
Expediente de
Licenciado
Elaboración Decreto
que Dicta nuevo
Alumno con grado de
Licenciado firmado por
Rector
Secretaria
General
Llegada Decreto
Archivar Decreto
Junto a Expediente
Recepción del
Decreto de
Grado
Director
Viene de la pagina anterior
Diagrama 9: Proceso de Obtención de Grado de Licenciado.
91
7. CONCLUSIONES Y TRABAJO FUTURO
El objetivo general del proyecto consistió en la creación de una ontología para el dominio de la Escuela Ingeniería
Informática.
Se han estudiado las metodologías, herramientas y lenguajes necesarios para la realización del proyecto.
Para la creación y edición de la ontología se ha optado por Protégé, herramienta con una interfaz gráfica de usuario
muy intuitiva.
La elección sobre qué lenguaje de especificación implementar al desarrollar una ontología también toma
gran importancia, ya que estos son la base para lo que luego serán las potencialidades de la ontología misma. En
estos momentos, OWL ha ganado cierta ventaja sobre los demás lenguajes, principalmente por sus características de
escalabilidad y compatibilidad con los más recientes estándares Web.
Las Ontologías quizás para muchos pueda resultar un tema nuevo, pero en el capitulo 2 permite darse cuenta
que es un tema en el cual se ha venido trabajando hace un largo tiempo y en el cual se seguirá trabajando ya que se le
puede sacar muchos beneficios por ejemplo en lo que atañe al dominio de este proyecto la reutilización y la
documentación orientada a los sistemas de información.
El trabajo futuro para este proyecto es el refinamiento de la Especificación, Conceptualización e
Implementación de la Ontología con el fin de ponerla a disposición de los potenciales desarrolladores. Una vez que
la ontología esté implementada vendrá la validación de la misma a través de darle un uso o de la opinión de personas
que se vean involucradas en las actividades de la Escuela.
El modelo ontológico puede extenderse, al igual que la base de conocimiento. Mientras más individuos
existan en la base de conocimiento, y más propiedades entre ellos, más rico para aplicar inferencias será.
La idea de realizar una ontología para la Escuela cobra importancia porque como se pudo ver en este
documento la cantidad de sistemas que se realizan para la escuela no es menor y lo que tampoco es menor es la
cantidad de sistemas que no llegan a tener uso, por esto la integración y la interoperabilidad que puede lograrse con
una ontología sientan un buen precedente para los trabajos futuros.
Como Trabajo futuro queda seguir refinando la especificación de la ontología y el modelado de procesos a
fin de que esto pueda ayudar de alguna forma a los futuros desarrolladores y a la Escuela misma en la
estandarización de procesos y una posterior automatización.
Esta ontología muestra una visión de la Escuela y una de sus principales características es su adaptabilidad a
otras Escuelas, sobre todo aquellas que tengan problema de integración de información.
Respecto a la ontología en OWL y la ontología modelada se abarcó un dominio que puede ser fácilmente
entendido por la gente que pueda leer este documento. Sin embargó se abarcó el tema en profundidad y amplitud
viendo variados temas de la ontología desde las personas hasta sus carreras, de sus divisiones organizacionales hasta
sus proyectos de investigación.
Como trabajo futuro se podría mencionar que al ser la Ontología una nueva base de conocimiento, se debe
estudiar su almacenamiento y recuperación para la satisfacción de las necesidades de los posibles usuarios.
92
También queda como trabajo futuro el compartir y poner a disposición de otras Escuelas la Ontología a fin
de perfeccionarla y de lograr que los sistemas de diversas Escuelas sean capaces de entenderse, es decir lograr la
integración e interoperabilidad a nivel semántica de estos sistemas.
BIBLIOGRAFÍA
[1] Fernández, M., Gómez-Pérez, A., and Juristo, N., METHONTOLOGY: From Ontological Art Towards
Ontological Engineering. Working Notes of the AAAI Spring Symposium on Ontological Engineering, University of
Stanford, CA (USA), March 24-25, 1997: p. 33-40.
[2] IEEE, IEEE Standard for Developing Software Life Cycle Processes. STD 1074-1995, 1995.
[3] R. Neches, R.E. Fikes, T. Finin, T.R. Gruber, T. Senator, W.R. Swartout, Enabling technology for
knowledge sharing, AI Magazine 12 (3) (1991) 36–56.
[4] T.R. Gruber, A translation approach to portable ontology specification, Knowledge Acquisition 5 (1993)
199– 220.
[5] W.N. Borst, Construction of Engineering Ontologies, PhD Thesis, University of Tweenty, Enschede, NL––
Centre for Telematica and Information Technology, 1997.
[6] R. Studer, V.R. Benjamins, D. Fensel, Knowledge engineering: principles and methods, Data and
Knowledge Engineering 25 (1998) 161–197.
[7] N. Guarino, M. Carrara, P. Giaretta, Ontologies and knowledge bases: towards a terminological
clarification, in: N. Mars (Ed.), Towards Very Large Knowledge Bases, Knowledge Building and Knowledge
Sharing, IOS Press, Amsterdam, 1995, pp. 25–32.
[8] A. Bernaras, I. Laresgoiti, J. Corera, Building and reusing ontologies for electrical network applications, in:
Proc. European Conference on Artificial Intelligence (ECAI’96), Budapest, Hungary, 1996, pp. 298–302.
[9] Ath. Schreiber, B. Wielinga, W. Jansweijer, The KACTUS view on the ‘O’ word. Technical Report,
ESPRIT Project 8145 KACTUS, University of Amsterdam, The Netherlands, 1995.
[10] B. Swartout, P. Ramesh, K. Knight, T. Russ, Toward Distributed Use of Large-Scale Ontologies, AAAI
Symposium on Ontological Engineering, Stanford, 1997.
[11] M. Uschold, R. Jasper, AFramework for Understanding and Classifying Ontology Applications, in: Proc.
IJCAI99 Workshop on Ontologies and Problem-Solving Methods, Stockholm, 1999.
[12] D.B. Lenat, R.V. Guha, Building Large Knowledge-Based Systems: Representation and Inference in the
Cyc Project, Addison-Wesley, Boston, 1990.
[13] M. Uschold, M. King, Towards a Methodology for Building Ontologies, in: IJCAI95 Workshop on Basic
Ontological Issues in Knowledge Sharing, Montreal, 1995.
[14] M. Grüninger, M.S. Fox, Methodology for the design and evaluation of ontologies, in: Workshop on Basic
Ontological Issues in Knowledge Sharing, Montreal, 1995.
[15] A. Gómez-Pérez, M. Fernández-López, A. de Vicente, Towards a Method to Conceptualize Domain
Ontologies, in: ECAI96 Workshop on Ontological Engineering, Budapest, 1996, pp. 41–51.
[16] S. Staab, H.P. Schnurr, R. Studer, Y. Sure, Knowledge processes and ontologies, IEEE Intelligent Systems
16 (1) (2001) 26–34.
[17] J. Euzenat, Corporative memory through cooperative creation of knowledge bases and hyper-documents, in:
Proc. 10th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW96), Banff, 1996.
[18] M. Fernandez-Lopez, Overview of Methodologies for Building Ontologies, in: IJCAI99 Workshop on
Ontologies and Problem-Solving Methods: Lessons Learned and Future Trends, Stockholm, 1999.
[19] M. Fernandez-Lopez, A. Gomez-Perez, A. Pazos-Sierra, J. Pazos-Sierra, Building a chemical ontology
using METHONTOLOGY and the ontology design environment, IEEE Intelligent Systems & their applications 4 (1)
(1999) 37–46.
[20] J.C. Arpírez, O. Corcho, M. Fern_andez-L_opez, A. G_omez-P_erez, WebODE: a scalable ontological
engineering workbench, in: First International Conference on Knowledge Capture (KCAP_01), ACM Press,
Victoria, 2001, pp. 6–13.
[21] O. Corcho, M. Fernández-López, A. Gómez-Pérez, O. Vicente, WebODE: an integrated workbench for
ontology representation, reasoning and exchange, in: A. Gómez-Pérez, V.R. Benjamins (Eds.), 13th International
Conference on Knowledge Engineering and Knowledge Management (EKAW_02), Lecture Notes in Artificial
Intelligence, vol. 2473, Springer, Berlin, 2002, pp. 138–153.
[22] M. Blázquez, M. Fernández-L_opez, J.M. García-Pinar, A. Gómez-Pérez, Building ontologies at the
knowledge level using the ontology design environment, in: B.R. Gaines, M.A. Musen (Eds.), 11th International
Workshop on Knowledge Acquisition, Modeling and Management (KAW_98) Banff, 1998.
[23] A. Farquhar, R. Fikes, J. Rice, The Ontolingua Server: A Tool for Collaborative Ontology Construction, in:
Proc. 10th Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW96) Banff, 1996, pp. 44.1–
44.19.
[24] D.L. McGuinness, R. Fikes, J. Rice, S. Wilder, The Chimaera Ontology Environment, in: 17th National
Conference on Artificial Intelligence (AAAI_00), Austin, 2000.
[25] V.K. Chaudhri, A. Farquhar, R. Fikes, P.D. Karp, J.P. Rice, Open Knowledge Base Connectivity 2.0.3,
Technical Report, 1998. Available from <http://www.ai.sri.com/~okbc/okbc-2-0-3.pdf>.
[26] J. Domingue, Tadzebao and WebOnto: Discussing, Browsing and Editing Ontologies on the Web, in: Proc.
11th Knowledge Acquisition Workshop (KAW98), Banff, 1998.
[27] N.F. Noy, R.W. Fergerson, M.A. Musen, The knowledge model of protege-2000: combining
interoperability and flexibility, in: 12th International Conference in Knowledge Engineering and Knowledge
Management (EKAW’00), Lecture Notes in Artificial Intelligence, vol. 1937, Springer, Berlin, 2000, pp. 17–32.
[28] Y. Sure, M. Erdmann, J. Angele, S. Staab, R. Studer, D. Wenke, OntoEdit: collaborative ontology
engineering for the semantic web, in: First International Semantic Web Conference (ISWC_02), Lecture Notes in
Computer Science, vol. 2342, Springer, Berlin, 2002, pp. 221–235.
[29] S. Decker, M. Erdmann, D. Fensel, R. Studer, Ontobroker: Ontology based access to distributed and
semistructured information, in: Semantic Issues in Multimedia Systems (DS8), Kluwer Academic Publisher, Boston,
1999, pp. 351–369.
[30] S. Bechhofer, I. Horrocks, C. Goble, R. Stevens, OilEd: a reason-able ontology editor for the Semantic
Web, in: Joint German/Austrian conference on Artificial Intelligence (KI_01), Lecture Notes in Artificial
Intelligence, vol. 2174, Springer, Berlin, 2001, pp. 396–408.
[31] I. Horrocks, U. Sattler, S. Tobies, Practical reasoning for expressive description logics, in: 6th International
Conference on Logic for Programming and Automated Reasoning (LPAR_99), Lecture Notes in Artificial
Intelligence, Springer, Berlin, 1999, pp. 161–180.
[32] P. Kogut, S. Cranefield, L. Hart, M. Dutra, K. Baclawski, M. Kokar, J. Smith, UML for ontology
development, The Knowledge Engineering Review 17 (1) (2002) 61–64.
[33] E.F. Kendall, M.E. Dutra, D.L. McGuinness, Towards a commercial ontology development environment,
in: First International Semantic Web Conference (ISWC_02), Lecture Notes in Computer Science, vol. 2342,
Springer, Berlin, 2002.
[34] H. Chalupsky, OntoMorph: a translation system for symbolic knowledge, in: Seventh International
Conference on Principles of Knowledge Representation and Reasoning (KR2000), Morgan Kaufmann, San
Francisco, 2000, pp. 471–482.
[35] A. Gómez-Pérez, A Survey on Ontology Tools, OntoWeb deliverable 1.3, 2001.
[36] R. MacGregor, Inside the LOOM clasifier, SIGART bulletin 2 (3) (1991) 70–76.
[37] M. Hermenegildo, F. Bueno, D. Cabeza, M. Carro, M. Garc_ıa, P. L_opez, G. Puebla, The Ciao Logic
Programming Environment, in: International Conference on Computational Logic (CL2000) 2000.
[38] E. Motta, Reusable Components for Knowledge Modelling, IOS Press, Amsterdam, 1999.
[39] M. Genesereth, R. Fikes, Knowledge interchange format, Technical Report Logic-92-1, Computer Science
Department, Stanford University, 1992.
[40] M. Kifer, G. Lausen, J. Wu, Logical foundations of object-oriented and frame-based languages, Journal of
the ACM 42 (4) (1995) 741–843.
[41] S. Luke, J. Heflin, SHOE 1.01. Proposed Specification, SHOE Project technical report, University of
Maryland, 2000. Available from <http://www.cs.umd.edu/projects/plus/SHOE/spec1.01.htm>.
[42] T. Bray, J. Paoli, CM. Sperberg-McQueen, E. Maler, Extensible Markup Language (XML) 1.0, second ed.,
W3C Recommendation, 2000. Available from <http://www.w3.org/TR/REC-xml>.
[43] R. Karp, V. Chaudhri, J. Thomere, XOL: An XML-Based Ontology Exchange Language, technical report,
1999. Available from <http://www.ai.sri.com/~pkarp/xol/xol.html>.
[44] O. Lassila, R. Swick, Resource description framework (RDF) model and syntax specification, W3C
Recommendation (1999), http://www.w3.org/TR/REC-rdf-syntax/.
[45] D. Brickley, R.V. Guha, RDF Vocabulary Description Language 1.0: RDF Schema, W3C Working Draft,
2002. Available from <http://www.w3.org/TR/PR-rdf-schema>.
[46] I. Horrocks, F. van Harmelen, Reference Description of the DAML+OIL (March 2001) Ontology Markup
Language, Technical report, 2001. Available from <http://www.daml.org/2001/03/reference.html>.
[47] M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D.L. McGuinness, P.F. Patel-Schneider,
L.A. Stein, OWL Web Ontology Language 1.0 Reference, W3C Working Draft, 2002. Available from
<http://www.w3.org/TR/owl-ref/>.
[48] O. Corcho, A. G_omez-P_erez, Aroadmap to ontology specification languages, in: 12th International
Conference in Knowledge Engineering and Knowledge Management (EKAW_00), Lecture Notes in Artificial
Intelligence, vol. 1937, Springer, Berlin, 2000, pp. 80–96.
[50] Weber, R. “The Information Systems Discipline: The need for and nature of a Foundational Core”.
Proceedings of the Information Systems Foundations Workshop. Department of Computing, Macquarie University,
1999.
[51] Chisholm, R. A. “Realistic Theory of Categories – An Essay on Ontology”. Cambridge University Press,
1996.
[52] Bunge, M. “Treatise on Basic Philosophy: Ontology I”, Reidel, 1977.
[53] Cinthya Andrea Acosta Sepúlveda, PUCV, Escuela de Ingenieria Informatica, proyecto tesis 2007,”
Integración de sistemas de certificación mediante ontologías, certificate supplement y técnicas de information
retrieval”
[54] H.Wache, T. Vögele, U.visser, H. Stuckenschmidt, G. Schuster, H. Neumann and S (2001). Hübner,
Ontology- Based integration of Information – A Survey of Existing Approaches.
[55] Floris Wiesman, Nico Roos (2004).Domain Independent of Ontology Mapping.
[56] Ontología Mikrokosmos: Estado del Arte y Aplicaciones Víctor Caneo A., Franklin Johnson P. y José
Miguel Rubio L, Pontificia Universidad Católica de Valparaíso, Magíster en Ingeniería Informática, 2008.
[57] Ejemplos de Aplicación de Ontologías Claudio Castillo, Renato Otaíza, Oscar Silva Pontificia Universidad
Católica de Valparaíso, Escuela de Ingeniería Informática, Magíster en Ingeniería Informática, 2008.
[58] SAS-UCV, Claudia Herrera Allendes, Septiembre de 1999, UCV.
[59] Sistema de Consulta De Alumnos Titulados (SACT), Roberto Bravo Brito, Patricio Escobar Ferrand, julio
1997, UCV.
[60] Sistema de Apoyo al Control Académico de la Jefatura de Docencia, Dense Espinoza, Leonor Pola,
diciembre 1994.
[61] Sistema de Asignación de Horarios de Clases, Silvan Abarca Brieda, diciembre 1996.
[62] Utilización de Protégé en el Desarrollo de una ontología de Dominio, Cristhy Jiménez, Christian Riquelme,
Luis Suárez, Pontificia Universidad Católica de Valparaíso, Facultad de Ingeniería, Escuela de Ingeniería
Informática, 2008.
ANEXO 1 Comparación de metodologías para construir ontologías.
Comparación de los lenguajes para representar ontologías
Tabla 1
Comparación de metodologías para construir ontologías Característica Usdhold Grüninger On-To-
Cyc and King and Fox KACTUS METHONTOLOGY SENSUS Knowledge
Proceso de administración de proyecto Inicio del proyecto NP NP NP NP NP NP P
Monitoreo y control del proyecto NP NP NP NP NP NP P Administración de calidad de la ontología NP NP NP NP NP NP P
Desarrollo de ontologías orientado a procesos Proceso de Pre-desarrollo
Exploración de conceptos NP NP NP NP NP NP P Localización de sistemas NP NP NP NP NP NP NP
Proceso de Desarrollo Requerimientos NP P P P DD P P Diseño NP NP D D DD NP P Implementación P P D P DD D P
Proceso Post-desarrollo Instalación NP NP NP NP NP NP NP Operación NP NP NP NP NP NP NP Soporte NP NP NP NP NP NP NP Mantención NP NP NP NP P NP P Retiro NP NP NP NP NP NP NP Proceso Integral
Adquisición de conocimiento P P P NP DD NP P Verificación y validación NP P P NP DD NP P
Administración de configuración de la ontología NP NP NP NP DD NP P Documentación P P P NP DD NP P Entrenamiento NP NP NP NP NP NP NP
P: Propuesto NP: No Propuesto D: Descrito DD: Descrito en Detalles
Tabla 2: Comparación de Herramientas para el desarrollo de Ontologías. DUET OILED OntoEdit
Profesional Ontolingua OntoSaurus Protégé
2000 WebODE WebOnto
Conceptos Generales
Desarrolladores AT&T University Manchester
Ontoprise KSL (Stanford University)
ISI (USC) SMI (Stanford
University)
UPM KMI (Open University)
Versión y fecha 0.3 (Jul2002) 3.4 (Abr2002) 3.0 (Ago2002) 1.0.649 (Nov2001)
1.9 (Mar2002) 1.8 (Jul2002) 2.0 (Mar2002) 2.3 (May2001)
Licencia Freeware Freeware Freeware Y licencias
Acceso Web libre
Open Source Versión de evaluación
Open Source Acceso Web Libre
Acceso Web libre
Arquitectura SW
Arquitectura SW Plugin Standalone Standalone y Cliente/Servidor
Cliente/Servidor Cliente/Servidor Standalone 3-tier Cliente/Servidor
Extensibilidad No No Plugins No No Plugins Plugins No Almacenamiento de Ontología
No Archivo Archivo DBMS (v3.0)
Archivos Archivos Archivo DBMS (JDBC)
DBMS (JDBC)
Archivos
Administración de Backup
No No No No No No Si Si
Interoperabilidad al trasladar desde y hacia el Lenguaje
Importar desde Lenguajes
DAML+OIL RDF(s) OIL
DAML+OIL
XML RDF(s) Flogic
DAML+OIL
Ontolingua, IDL KIF
Loom IDL ONTO KIF
C++
XML RDF(s) XML
Schema
XML RDF(s) CARIN
OCML
Exportar al lenguaje DAML+OIL OIL RDF(s) DAML+OIL
SHIQ Dotty HTML
XML RDF(s), Flogic
DAML+OIL SQL-3
KIF-3.0 CLIPS CML ATP CML Rule engine EpiKit IDL KSL Rule
engine Loom OKBC
Syntax
Loom, IDL ONTO KIF
C++
XML RDF(s) XML
Schema Flogic CLIPS JAVA HTML
XML RDF(s) OIL DAML+OIL
CARIN Flogic Prolog Jess
JAVA
OCML Ontolingua
GXL RDF(s)
OIL
Representación del conocimiento y
Soporte Metodológico Paradigma KR del modelo de conocimiento
Orientado a Objetos de
Clases
DL (DAML+OIL)
Frames+FOL Frames+FOL (Ontolingua)
DL (Loom) Frames+FOL +Metaclases
Frames+FOL
Frames+FOL
Lenguajes de Axiomas No Si (DAML+OIL)
Si (Flogic) Si (KIF) Si (Loom) Si (PAL) Si (WAB) Si (OCML)
Soporte Metodológico Si (Racional Rose)
No Si (Onto-Knowledge)
No No No Si (Methontology)
No
Servicio de Inferencias
Construir inferencias en un motor
No Si (FaCT) Si (OntoBroker) No Si Si (PAL) Si (Prolog) Si
Otros motores de inferencias adjuntos
No No No ATP SI Jess FaCT Flogic
Jess No
Chuequear restricciones de consistencias
No Si Si No Si Si Si Si
Clasificaciones Automáticas
No Si No No Si No No No
Manejo de Excepciones No No No No No No No No
Usabilidad
Grafica de la Taxonomía
Si No No Si No Si Si Si
Tabla 3 Tabla 3: Comparación de los lenguajes para representar ontologías
Ontolingua OKBC OCML LOOM FLogic XOL SHOE RDF(S) OIL DAML+OIL
REPRESENTACIÓN DE CONOCIMIENTO
Conceptos
Definir metaclases + + + + + + - + - -
Particiones + - - + - - - - - -
Atributos de instancias + + + + + + + + + +
Atributos de Clases + + + + + + - + ± ±
Atributos Polimórficos + + + + + - - - + +
Atributos Locales + + + + + + + + + +
Valores por defecto + + + + + + - - - -
Tipo exigido en atributos + + + + + + + + + +
Cardinalidad exigida en atributos + + + + ± + - - + +
Documentación + + + + - + + - + +
Conocimiento operacional - - + + - - - - - -
Añadir nuevas facetas + + - + - - - - - - Taxonomías
Relación Subclase_de + + + + + + + + + +
Descomposiciones exhaustivas + - ± + ± - - - - +
Descomposiciones disjuntas + - ± + ± - - - + +
Relación No_Subclase_de ± - - ± - - - - + + Relaciones
Funciones + + - + + - - - + +
Relaciones N-arias + ± + + ± - + + ± ±
Tipos de conceptos restringidos + + + + + - + + + +
Restricciones de integridad + + + + + - - - - -
Definiciones operacionales - - + + + - - - - - Axiomas
Lógica de primer orden + ± + + + - ± ± - -
Lógica de segundo orden + ± - - - - - - - -
Permite axiomas independientes + + + - - - - - - - Instancias/Hechos/Afirmaciones
Definir Instancias + + + + + + + + - +
Definir Hechos + + + + + + + + + +
Definir Afirmaciones ± - - - - - + + - - Reglas de Producción
Premisas conjuntivas - - + + - - - - - -
Premisas disyuntivas - - + + - - - - - -
Valores de verdad en consecuente - - - - - - - - - -
Ejecución de procedimientos - - ± + - - - - - -
Actualización de la base de conocimiento - - + + - - - - - - MECANISMOS DE INFERENCIA
MI completo - - + + + - - - + +
MI correcto + - - - + - + + + +
Clasificaciones automáticas - - - + - - + - + +
Maneja excepciones - - - - + - - - - -
Herencia monótona + + + + + D + D + +
Herencia no monótona - + - + + D - D - -
Herencia simple + + + + + D + + + +
Herencia múltiple + + + + + D + + + +
Ejecuta procedimientos + + + + - - - - - -
Chequea restricciones + + + + + - - - + +
Encadenamiento hacia atrás y delante - - + + + - D - - - D: Desconocido
ANEXO 2 Vistas de la Ontología
Figura 2.1: Clase Malla_Curricular
Figura 2.2: Clase Tipo_de_Ingreso.
Figura 2.3: Clase Eventos.
Figura 2.4: Vista de la Ontología con Jambalaya.
Figura 2.5: Clase Asignatura.
Figura 2.7: Otra vista de la Ontología con Jambalaya.
Figura 2.8: Clase Tesis.
ANEXO 3
CODIGO OWL
<?xml version="1.0"?> <rdf:RDF xmlns:xsp="http://www.owl-ontologies.com/2005/08/07/xsp.owl#" xmlns:swrlb="http://www.w3.org/2003/11/swrlb#" xmlns:swrl="http://www.w3.org/2003/11/swrl#" xmlns:protege="http://protege.stanford.edu/plugins/owl/protege#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xsd="http://www.w3.org/2001/XMLSchema#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:owl="http://www.w3.org/2002/07/owl#" xmlns="http://www.owl-ontologies.com/unnamed.owl#" xml:base="http://www.owl-ontologies.com/unnamed.owl"> <owl:Ontology rdf:about=""/> <owl:Class rdf:ID="Resolucion_DAE"> <rdfs:subClassOf> <owl:Class rdf:ID="Tipo_de_Ingreso"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="PSU"> <rdfs:subClassOf> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Obligatoria"> <rdfs:subClassOf> <owl:Class rdf:ID="Asignatura"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Director"> <rdfs:subClassOf> <owl:Class rdf:ID="Persona"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Jefe_Extension"> <rdfs:subClassOf> <owl:Class rdf:about="#Persona"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Exhibicion"> <rdfs:subClassOf> <owl:Class rdf:ID="Eventos"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Conferencias"> <rdfs:subClassOf> <owl:Class rdf:about="#Eventos"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Optativa"> <rdfs:subClassOf> <owl:Class rdf:about="#Asignatura"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Laboratorio"> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom>
<owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:ID="Alumnos"/> <owl:Class rdf:ID="Profesor"/> </owl:unionOf> </owl:Class> </owl:someValuesFrom> <owl:onProperty> <owl:SymmetricProperty rdf:ID="A_cargo_de"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Class rdf:ID="Actividades_Academicas"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Catedra"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:SymmetricProperty rdf:about="#A_cargo_de"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Profesor"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Class rdf:about="#Actividades_Academicas"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Alumno_Pregrado"> <rdfs:subClassOf> <owl:Class rdf:about="#Alumnos"/> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Realiza_practica"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:ID="Practica"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Es_adscrito_a_un_Plan"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:ID="Pregrado"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Proyecto"> <owl:disjointWith> <owl:Class rdf:ID="Rector"/> </owl:disjointWith>
<owl:disjointWith> <owl:Class rdf:ID="Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Secretaria_General"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Direccion"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Horario"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Espacio_Fisico"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Decanato"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Eventos"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Expediente"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Constancia"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Direccion_de_Procesos_Docentes"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Carrera"/> </owl:disjointWith>
<owl:disjointWith> <owl:Class rdf:ID="Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Jefe_Investigacion"> <rdfs:subClassOf> <owl:Class rdf:about="#Persona"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Constancia"> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Rector"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Direccion"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Eventos"/> </owl:disjointWith> <owl:disjointWith>
<owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Espacio_Fisico"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Direccion_de_Procesos_Docentes"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Decanato"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Expediente"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Estudios_Generales"> <rdfs:subClassOf> <owl:Class rdf:about="#Asignatura"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Pregrado"> <rdfs:subClassOf> <owl:Class rdf:about="#Plan_de_Estudio"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Rector"> <owl:disjointWith> <owl:Class rdf:about="#Direccion_de_Procesos_Docentes"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Decanato"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Expediente"/> </owl:disjointWith> <owl:disjointWith>
<owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Eventos"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Direccion"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Espacio_Fisico"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Ayudantia"> <rdfs:subClassOf> <owl:Class rdf:about="#Actividades_Academicas"/> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom> <owl:Class rdf:about="#Alumnos"/> </owl:someValuesFrom> <owl:onProperty> <owl:SymmetricProperty rdf:about="#A_cargo_de"/> </owl:onProperty> </owl:Restriction>
</rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Direccion_de_Procesos_Docentes"> <owl:disjointWith> <owl:Class rdf:about="#Expediente"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Decanato"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Espacio_Fisico"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Eventos"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith>
<owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Direccion"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:about="#Eventos"> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Expediente"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Direccion"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Espacio_Fisico"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom> <owl:Class rdf:about="#Horario"/> </owl:someValuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:ID="Tiene_Horario"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Decanato"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith>
<owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Seminario"> <rdfs:subClassOf rdf:resource="#Eventos"/> </owl:Class> <owl:Class rdf:ID="Especial"> <rdfs:subClassOf> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Espacio_Fisico"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:DatatypeProperty rdf:ID="Clave_espacio"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith>
<owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Asignado_en_un_horario"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Horario"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Decanato"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Direccion"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Expediente"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> </owl:Class> <owl:Class rdf:about="#Expediente">
<owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Direccion"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Decanato"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith>
</owl:Class> <owl:Class rdf:about="#Direccion"> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom> <owl:Class rdf:about="#Persona"/> </owl:someValuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:ID="Es_direccion_de"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Decanato"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/>
</owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> </owl:Class> <owl:Class rdf:about="#Decanato"> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Empresa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith>
<owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Secretaria_Direccion"> <rdfs:subClassOf> <owl:Class rdf:ID="Personal"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Empresa"> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Dio_la_practica"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Practica"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith>
<owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom rdf:resource="#Direccion"/> <owl:onProperty> <owl:ObjectProperty rdf:ID="Tienen_Direccion_Permanente"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Plan_de_Estudio"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Proyecto_de_Investigacion"> <rdfs:subClassOf rdf:resource="#Proyecto"/> </owl:Class> <owl:Class rdf:ID="Tesis"/> <owl:Class rdf:ID="Auxiliar"> <rdfs:subClassOf> <owl:Class rdf:about="#Personal"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Plan_de_Estudio"> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion"/>
<owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Horario"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Expediente"/> </owl:Class> <owl:Class rdf:about="#Horario"> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/>
</owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="En_un"/> </owl:onProperty> <owl:someValuesFrom rdf:resource="#Espacio_Fisico"/> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Secretaria_General"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Secretario_Academico"> <rdfs:subClassOf> <owl:Class rdf:about="#Persona"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Postgrado"> <rdfs:subClassOf rdf:resource="#Plan_de_Estudio"/> </owl:Class> <owl:Class rdf:ID="Hora"> <rdfs:subClassOf> <owl:Class rdf:about="#Profesor"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:ID="Jornada_Completa"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:ID="Jornada_Parcial"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Administrador_Recursos_TI"> <rdfs:subClassOf> <owl:Class rdf:about="#Personal"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Secretaria_General"> <owl:disjointWith>
<owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carrera"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> </owl:Class> <owl:Class rdf:about="#Carrera"> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Direccion"/>
<owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith> <owl:Class rdf:about="#Curso"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith rdf:resource="#Constancia"/> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom rdf:resource="#Plan_de_Estudio"/> <owl:onProperty> <owl:ObjectProperty rdf:ID="Tiene_un_Plan"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:about="#Curso"> <owl:disjointWith rdf:resource="#Horario"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Es_Dictado_por"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Profesor"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith>
<owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Tercera_Oportunidad"/> </owl:disjointWith> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom> <owl:Class rdf:about="#Asignatura"/> </owl:someValuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:ID="Pertenece_a_la_Asignatura"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Expediente"/> <rdfs:subClassOf> <owl:Restriction> <owl:valuesFrom> <owl:Class rdf:about="#Asignatura"/> </owl:valuesFrom> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> <owl:onProperty> <owl:ObjectProperty rdf:about="#Pertenece_a_la_Asignatura"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith>
<rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Tiene_Actividades"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:minCardinality> <owl:onProperty> <owl:DatatypeProperty rdf:ID="Cupo"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:DatatypeProperty rdf:ID="Alumnos_Inscritos"/> </owl:onProperty> <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:about="#Jornada_Completa"> <rdfs:subClassOf> <owl:Class rdf:about="#Profesor"/> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Jornada_Parcial"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Hora"/> </owl:Class> <owl:Class rdf:about="#Tercera_Oportunidad"> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Curso"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/>
</owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith> <owl:Class rdf:about="#Tipo_de_Ingreso"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Expediente"/> </owl:Class> <owl:Class rdf:about="#Tipo_de_Ingreso"> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Espacio_Fisico"/>
<owl:disjointWith> <owl:Class rdf:about="#Asignatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith rdf:resource="#Curso"/> </owl:Class> <owl:Class rdf:ID="Tesis_Pregrado"> <rdfs:subClassOf rdf:resource="#Tesis"/> </owl:Class> <owl:Class rdf:about="#Personal"> <rdfs:subClassOf> <owl:Class rdf:about="#Persona"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Asignatura"> <owl:disjointWith> <owl:Class rdf:about="#Malla_Curricular"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith rdf:resource="#Curso"/> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <rdfs:subClassOf> <owl:Restriction> <owl:allValuesFrom rdf:resource="#Asignatura"/> <owl:onProperty> <owl:ObjectProperty rdf:ID="Asignatura_Prerequisito"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <owl:disjointWith rdf:resource="#Empresa"/>
<owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> </owl:Class> <owl:Class rdf:ID="Tesis_Postgrado"> <rdfs:subClassOf rdf:resource="#Tesis"/> </owl:Class> <owl:Class rdf:ID="Secretaria_Docencia"> <rdfs:subClassOf rdf:resource="#Personal"/> </owl:Class> <owl:Class rdf:about="#Malla_Curricular"> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith rdf:resource="#Constancia"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Pertenece_al_Plan"/> </owl:onProperty> <owl:someValuesFrom rdf:resource="#Plan_de_Estudio"/> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Curso"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Asignatura"/> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Contiene_Asignaturas"/> </owl:onProperty> <owl:someValuesFrom rdf:resource="#Asignatura"/> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Carpeta_Alumno"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith>
<owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith rdf:resource="#Horario"/> </owl:Class> <owl:Class rdf:ID="Alumno_Postgrado"> <rdfs:subClassOf> <owl:Class rdf:about="#Alumnos"/> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#Es_adscrito_a_un_Plan"/> </owl:onProperty> <owl:someValuesFrom rdf:resource="#Postgrado"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:ID="Jefe_Docencia"> <rdfs:subClassOf> <owl:Class rdf:about="#Persona"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Carpeta_Alumno"> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Proyecto"/> <rdfs:subClassOf> <owl:Restriction> <owl:valuesFrom> <owl:Class rdf:about="#Alumnos"/> </owl:valuesFrom> <owl:onProperty> <owl:ObjectProperty rdf:ID="Pertenece_a_un"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_Licenciatura"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Curso"/> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Asignatura"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/>
<owl:disjointWith rdf:resource="#Malla_Curricular"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Constancia"/> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> </owl:Class> <owl:Class rdf:ID="Proyecto_de_Titulo"> <rdfs:subClassOf rdf:resource="#Proyecto"/> </owl:Class> <owl:Class rdf:about="#Alumnos"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Tiene_una_Direccion_de_Estudiante"/> </owl:onProperty> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Class rdf:about="#Persona"/> </rdfs:subClassOf> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom rdf:resource="#Carpeta_Alumno"/> <owl:onProperty> <owl:ObjectProperty rdf:ID="Tiene_carpeta"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Informe_Licenciatura"> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <owl:disjointWith rdf:resource="#Asignatura"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Curso"/> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Carpeta_Alumno"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith rdf:resource="#Malla_Curricular"/>
<owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith> <owl:Class rdf:about="#Actividades_Academicas"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> </owl:Class> <owl:Class rdf:about="#Profesor"> <rdfs:subClassOf> <owl:Class rdf:about="#Persona"/> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Actividades_Academicas"> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Informe_Licenciatura"/> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith rdf:resource="#Carpeta_Alumno"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <rdfs:subClassOf> <owl:Restriction> <owl:someValuesFrom rdf:resource="#Horario"/> <owl:onProperty> <owl:ObjectProperty rdf:about="#Tiene_Horario"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith> <owl:Class rdf:about="#Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Asignatura"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:ID="Actividades_del_curso"/> </owl:onProperty> <owl:valuesFrom rdf:resource="#Curso"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith>
<owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith rdf:resource="#Curso"/> <owl:disjointWith rdf:resource="#Malla_Curricular"/> <owl:disjointWith rdf:resource="#Carrera"/> </owl:Class> <owl:Class rdf:ID="Secretaria_Postgrado"> <rdfs:subClassOf rdf:resource="#Personal"/> </owl:Class> <owl:Class rdf:ID="Taller"> <rdfs:subClassOf rdf:resource="#Actividades_Academicas"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:SymmetricProperty rdf:about="#A_cargo_de"/> </owl:onProperty> <owl:someValuesFrom> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Alumnos"/> <owl:Class rdf:about="#Profesor"/> </owl:unionOf> </owl:Class> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Practica"> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Actividades_Academicas"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Informe_Licenciatura"/> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <owl:disjointWith rdf:resource="#Malla_Curricular"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Carpeta_Alumno"/> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Asignatura"/> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith> <owl:Class rdf:about="#Persona"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith rdf:resource="#Curso"/> </owl:Class> <owl:Class rdf:about="#Persona"> <owl:disjointWith rdf:resource="#Espacio_Fisico"/>
<owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Empresa"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Malla_Curricular"/> <owl:disjointWith rdf:resource="#Horario"/> <owl:disjointWith rdf:resource="#Informe_Licenciatura"/> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith rdf:resource="#Carrera"/> <rdfs:subClassOf> <owl:Restriction> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> <owl:onProperty> <owl:DatatypeProperty rdf:ID="Apellido_Paterno"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <rdfs:subClassOf> <owl:Restriction> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> <owl:onProperty> <owl:DatatypeProperty rdf:ID="Apellido_Materno"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Curso"/> <rdfs:subClassOf> <owl:Restriction> <owl:minCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:minCardinality> <owl:onProperty> <owl:DatatypeProperty rdf:ID="Nombres"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Actividades_Academicas"/> <owl:disjointWith rdf:resource="#Carpeta_Alumno"/> <owl:disjointWith> <owl:Class rdf:about="#Informe_de_Practica"/> </owl:disjointWith> <owl:disjointWith rdf:resource="#Secretaria_General"/> <owl:disjointWith rdf:resource="#Direccion"/> <rdfs:subClassOf> <owl:Restriction> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> <owl:onProperty> <owl:ObjectProperty rdf:about="#Tienen_Direccion_Permanente"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <owl:disjointWith rdf:resource="#Practica"/> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/>
<owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Asignatura"/> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty> <owl:ObjectProperty rdf:about="#Tienen_Direccion_Permanente"/> </owl:onProperty> <owl:someValuesFrom rdf:resource="#Direccion"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <owl:Class rdf:about="#Informe_de_Practica"> <owl:disjointWith rdf:resource="#Direccion"/> <owl:disjointWith rdf:resource="#Secretaria_General"/> <rdfs:subClassOf rdf:resource="http://www.w3.org/2002/07/owl#Thing"/> <owl:disjointWith rdf:resource="#Curso"/> <owl:disjointWith rdf:resource="#Persona"/> <owl:disjointWith rdf:resource="#Eventos"/> <owl:disjointWith rdf:resource="#Proyecto"/> <owl:disjointWith rdf:resource="#Espacio_Fisico"/> <owl:disjointWith rdf:resource="#Plan_de_Estudio"/> <owl:disjointWith rdf:resource="#Decanato"/> <owl:disjointWith rdf:resource="#Tipo_de_Ingreso"/> <owl:disjointWith rdf:resource="#Carpeta_Alumno"/> <owl:disjointWith rdf:resource="#Informe_Licenciatura"/> <owl:disjointWith rdf:resource="#Direccion_de_Procesos_Docentes"/> <owl:disjointWith rdf:resource="#Expediente"/> <owl:disjointWith rdf:resource="#Actividades_Academicas"/> <owl:disjointWith rdf:resource="#Constancia"/> <owl:disjointWith rdf:resource="#Practica"/> <owl:disjointWith rdf:resource="#Tercera_Oportunidad"/> <owl:disjointWith rdf:resource="#Asignatura"/> <owl:disjointWith rdf:resource="#Malla_Curricular"/> <owl:disjointWith rdf:resource="#Horario"/> <rdfs:subClassOf> <owl:Restriction> <owl:valuesFrom rdf:resource="#Alumno_Pregrado"/> <owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#int" >1</owl:cardinality> <owl:onProperty> <owl:ObjectProperty rdf:ID="Informe_Realizado_Por"/> </owl:onProperty> </owl:Restriction> </rdfs:subClassOf> <owl:disjointWith rdf:resource="#Carrera"/> <owl:disjointWith rdf:resource="#Rector"/> <owl:disjointWith rdf:resource="#Empresa"/> </owl:Class> <owl:Class rdf:ID="Encargado_Laboratorio"> <rdfs:subClassOf rdf:resource="#Personal"/> </owl:Class> <owl:Class rdf:ID="Avance_Curricular"/> <owl:Class rdf:about="#Jornada_Parcial"> <rdfs:subClassOf rdf:resource="#Profesor"/> <owl:disjointWith rdf:resource="#Jornada_Completa"/> <owl:disjointWith rdf:resource="#Hora"/> </owl:Class> <owl:ObjectProperty rdf:ID="Pertenece_a_una_malla"> <rdfs:range rdf:resource="#Malla_Curricular"/> <owl:inverseOf>
<owl:ObjectProperty rdf:about="#Contiene_Asignaturas"/> </owl:inverseOf> <rdfs:domain rdf:resource="#Asignatura"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Profesor_Correferente"> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Jornada_Completa"/> <owl:Class rdf:about="#Jornada_Parcial"/> </owl:unionOf> </owl:Class> </rdfs:range> <rdfs:domain rdf:resource="#Proyecto_de_Titulo"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Tiene_carpeta"> <rdfs:range rdf:resource="#Carpeta_Alumno"/> <rdfs:domain rdf:resource="#Alumnos"/> <owl:inverseOf> <owl:ObjectProperty rdf:about="#Pertenece_a_un"/> </owl:inverseOf> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Informe_Realizado_Por"> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Realiza_Informe"/> </owl:inverseOf> <rdfs:range rdf:resource="#Alumno_Pregrado"/> <rdfs:domain rdf:resource="#Informe_de_Practica"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Es_Dictado_por"> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Dicta_curso"/> </owl:inverseOf> <rdfs:range rdf:resource="#Profesor"/> <rdfs:domain rdf:resource="#Curso"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Profesor_Guia"> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Jornada_Completa"/> <owl:Class rdf:about="#Jornada_Parcial"/> </owl:unionOf> </owl:Class> </rdfs:range> <rdfs:domain rdf:resource="#Proyecto_de_Titulo"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Dicta_curso"> <rdfs:domain rdf:resource="#Profesor"/> <owl:inverseOf rdf:resource="#Es_Dictado_por"/> <rdfs:range rdf:resource="#Curso"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Tiene_que_Ser"> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Director"/> <owl:Class rdf:about="#Jefe_Docencia"/> <owl:Class rdf:about="#Jefe_Investigacion"/> <owl:Class rdf:about="#Secretario_Academico"/>
</owl:unionOf> </owl:Class> </rdfs:domain> <rdfs:range rdf:resource="#Jornada_Completa"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Tiene_como_Autor"> <rdfs:domain rdf:resource="#Proyecto_de_Titulo"/> <rdfs:range rdf:resource="#Alumnos"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Tiene_una_Direccion_de_Estudiante"> <rdfs:range rdf:resource="#Direccion"/> <rdfs:domain rdf:resource="#Alumnos"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Pertenece_a_un"> <rdfs:range rdf:resource="#Alumnos"/> <rdfs:domain rdf:resource="#Carpeta_Alumno"/> <owl:inverseOf rdf:resource="#Tiene_carpeta"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Tienen_Direccion_Permanente"> <rdfs:range rdf:resource="#Direccion"/> <owl:inverseOf> <owl:ObjectProperty rdf:about="#Es_direccion_de"/> </owl:inverseOf> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Persona"/> <owl:Class rdf:about="#Empresa"/> </owl:unionOf> </owl:Class> </rdfs:domain> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Tiene_un_Plan"> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Plan_de_la_carrera"/> </owl:inverseOf> <rdfs:range rdf:resource="#Plan_de_Estudio"/> <rdfs:domain rdf:resource="#Carrera"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Realiza_Informe"> <rdfs:range rdf:resource="#Informe_de_Practica"/> <rdfs:domain rdf:resource="#Alumno_Pregrado"/> <owl:inverseOf rdf:resource="#Informe_Realizado_Por"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Realiza"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Practica"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Pertenece_a_la_Asignatura"> <rdfs:domain rdf:resource="#Curso"/> <rdfs:range rdf:resource="#Asignatura"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Tuvo_un_Ingreso"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Tipo_de_Ingreso"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Es_Autor_de_Tesis_Postgrado"> <rdfs:range rdf:resource="#Tesis_Postgrado"/> <rdfs:domain rdf:resource="#Alumno_Postgrado"/> </owl:ObjectProperty>
<owl:ObjectProperty rdf:ID="Tiene_Ayudante"> <rdfs:range rdf:resource="#Alumnos"/> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Realiza_la_ayudantia"/> </owl:inverseOf> <rdfs:domain rdf:resource="#Ayudantia"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Investigador"> <rdfs:range rdf:resource="#Jornada_Completa"/> <rdfs:domain rdf:resource="#Proyecto_de_Investigacion"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Asignado_en_un_horario"> <rdfs:range rdf:resource="#Horario"/> <owl:inverseOf> <owl:ObjectProperty rdf:about="#En_un"/> </owl:inverseOf> <rdfs:domain rdf:resource="#Espacio_Fisico"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Actividades_del_curso"> <owl:inverseOf> <owl:ObjectProperty rdf:about="#Tiene_Actividades"/> </owl:inverseOf> <rdfs:range rdf:resource="#Curso"/> <rdfs:domain rdf:resource="#Actividades_Academicas"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Realiza_practica"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Practica"/> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Realizada_por"/> </owl:inverseOf> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Dio_la_practica"> <rdfs:range rdf:resource="#Practica"/> <rdfs:domain rdf:resource="#Empresa"/> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Se_Realiza_en"/> </owl:inverseOf> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Asignatura_Prerequisito"> <rdfs:domain rdf:resource="#Asignatura"/> <rdfs:range rdf:resource="#Asignatura"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Posee_Avance"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Avance_Curricular"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Contiene_Asignaturas"> <owl:inverseOf rdf:resource="#Pertenece_a_una_malla"/> <rdfs:range rdf:resource="#Asignatura"/> <rdfs:domain rdf:resource="#Malla_Curricular"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Tiene_una_Malla"> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> <owl:inverseOf> <owl:ObjectProperty rdf:about="#Pertenece_al_Plan"/> </owl:inverseOf> <rdfs:range rdf:resource="#Malla_Curricular"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Es_direccion_de">
<rdfs:domain rdf:resource="#Direccion"/> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Empresa"/> <owl:Class rdf:about="#Persona"/> </owl:unionOf> </owl:Class> </rdfs:range> <owl:inverseOf rdf:resource="#Tienen_Direccion_Permanente"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Es_adscrito_a_un_Plan"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Plan_de_Estudio"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Ingreso_a_traves_de"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Tipo_de_Ingreso"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Es_Solicitada"> <rdfs:domain rdf:resource="#Constancia"/> <rdfs:range rdf:resource="#Alumnos"/> <owl:inverseOf> <owl:ObjectProperty rdf:ID="Solicita"/> </owl:inverseOf> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Tiene_Actividades"> <rdfs:domain rdf:resource="#Curso"/> <rdfs:range rdf:resource="#Actividades_Academicas"/> <owl:inverseOf rdf:resource="#Actividades_del_curso"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Asigna"> <rdfs:range rdf:resource="#Horario"/> <rdfs:domain rdf:resource="#Jefe_Docencia"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Solicita"> <rdfs:range rdf:resource="#Constancia"/> <owl:inverseOf rdf:resource="#Es_Solicitada"/> <rdfs:domain rdf:resource="#Alumnos"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Tiene_Horario"> <rdfs:range rdf:resource="#Horario"/> <rdfs:domain> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Actividades_Academicas"/> <owl:Class rdf:about="#Eventos"/> </owl:unionOf> </owl:Class> </rdfs:domain> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Se_Realiza_en"> <rdfs:range rdf:resource="#Empresa"/> <rdfs:domain rdf:resource="#Practica"/> <owl:inverseOf rdf:resource="#Dio_la_practica"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Realizada_por"> <rdfs:range rdf:resource="#Alumnos"/> <rdfs:domain rdf:resource="#Practica"/> <owl:inverseOf rdf:resource="#Realiza_practica"/>
</owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Es_Autor_de_Tesis_Pregrado"> <rdfs:range rdf:resource="#Tesis_Pregrado"/> <rdfs:domain rdf:resource="#Alumno_Pregrado"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Realiza_la_ayudantia"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="#Ayudantia"/> <owl:inverseOf rdf:resource="#Tiene_Ayudante"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#En_un"> <rdfs:domain rdf:resource="#Horario"/> <rdfs:range rdf:resource="#Espacio_Fisico"/> <owl:inverseOf rdf:resource="#Asignado_en_un_horario"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Plan_de_la_carrera"> <owl:inverseOf rdf:resource="#Tiene_un_Plan"/> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> <rdfs:range rdf:resource="#Carrera"/> </owl:ObjectProperty> <owl:ObjectProperty rdf:about="#Pertenece_al_Plan"> <owl:inverseOf rdf:resource="#Tiene_una_Malla"/> <rdfs:domain rdf:resource="#Malla_Curricular"/> <rdfs:range rdf:resource="#Plan_de_Estudio"/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="Id_Practica"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Practica"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Fecha_de_Termino"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> <rdfs:domain rdf:resource="#Practica"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Departamento"> <rdfs:domain rdf:resource="#Direccion"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Fecha_de_Inicio"> <rdfs:domain rdf:resource="#Practica"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Nombre_Evento"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Eventos"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Clave_espacio"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Espacio_Fisico"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Creditos_Asignaturas_Optativas"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Nombre_Seminario"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Seminario"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Codigo_Carrera"> <rdfs:domain rdf:resource="#Carrera"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Region"> <rdfs:domain rdf:resource="#Direccion"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Giro"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Empresa"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Provincia"> <rdfs:domain rdf:resource="#Direccion"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Tipo_Asignatura"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Asignatura"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Poblacion_Villa_Condominio"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Direccion"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Periodo_Academico"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Curso"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Sigla_Asignatura"> <rdfs:domain rdf:resource="#Asignatura"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Capacidad_personas"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#Espacio_Fisico"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Titulo_Proyecto"> <rdfs:domain rdf:resource="#Proyecto"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Grado"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Email"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Tasa_de_Avance"> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#float"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Calle"> <rdfs:domain rdf:resource="#Direccion"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Nombre_Proyecto"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Proyecto"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Sigla_Profesor"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Profesor"/>
</owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Version_malla"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Malla_Curricular"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Autor_Tesis"> <rdfs:domain rdf:resource="#Tesis"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Nombres"> <rdfs:domain rdf:resource="#Persona"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Nombre_Empresa"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Empresa"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Cupo"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#Curso"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Apellido_Paterno"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Decreto"> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Creditos_Asignaturas_Generales"> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Comuna"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Direccion"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Apellido_Materno"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Maximo_Semestres"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:about="#Alumnos_Inscritos"> <rdfs:domain rdf:resource="#Curso"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Lugar_Evento"> <rdfs:domain rdf:resource="#Eventos"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Creditos_Asignaturas_Obligatorias"> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Telefono_Fijo"> <rdfs:domain rdf:resource="#Persona"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="Dia"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Horario"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Nombre_Asignatura"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Asignatura"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Duracion_Carrera_Semestres"> <rdfs:domain rdf:resource="#Carrera"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Descripcion"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Espacio_Fisico"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Ingreso_Plan_actual"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Alumnos"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Titulo_Tesis"> <rdfs:domain rdf:resource="#Tesis"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Tema"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Conferencias"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Promocion_de_Ingreso"> <rdfs:domain rdf:resource="#Alumnos"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Version"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Prerequisito_Semestre_Cursado"> <rdfs:domain rdf:resource="#Asignatura"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Numero"> <rdfs:domain rdf:resource="#Direccion"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Nombre_Carrera"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Carrera"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Numero_de_Practicas_Profesionales"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Paralelo"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> <rdfs:domain rdf:resource="#Curso"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="RUT"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Persona"/> </owl:DatatypeProperty>
<owl:DatatypeProperty rdf:ID="Fecha_inicio"> <rdfs:domain rdf:resource="#Eventos"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Celular"> <rdfs:domain rdf:resource="#Persona"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#int"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Codigo_Asignatura"> <rdfs:domain rdf:resource="#Asignatura"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Titulo"> <rdfs:domain rdf:resource="#Plan_de_Estudio"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Fecha_Fin"> <rdfs:domain rdf:resource="#Eventos"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#date"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Autor_Proyecto"> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> <rdfs:domain rdf:resource="#Proyecto_de_Titulo"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Clave"> <rdfs:domain rdf:resource="#Horario"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Duracion_Asignatura"> <rdfs:domain rdf:resource="#Asignatura"/> <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/> </owl:DatatypeProperty> <owl:SymmetricProperty rdf:about="#A_cargo_de"> <rdfs:range rdf:resource="#Persona"/> <rdfs:domain rdf:resource="#Actividades_Academicas"/> <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#ObjectProperty"/> </owl:SymmetricProperty> </rdf:RDF> <!-- Created with Protege (with OWL Plugin 3.4.1, Build 536) http://protege.stanford.edu -->