Ontologias

UNIVERSIDAD POUTECNICA DE MADRID
FACULTAD DE INFORMTICA
TESIS DOCTORAL
MTODO BI-FASE PARA LA

CONCEPTUALIZACIN DE
ONTOLOGAS BASADO EN
META-MODELOS
Autor: Mariano Fernndez Lpez

Directora: Asuncin Gmez Prez
Octubre 2000
A mis padres
Agradecimientos
EEstas lneas que, aunque estn al principio de la memoria, se suelen escribir las ltimas, son
agradables de componer no slo porque se ve el trabajo de varios aos ya terminado, sino
tambin porque se elaboran mientras se recuerda que el camino no se ha andado en solitario.
Del mismo modo, tambin es emocionante reconocer que la tesis es, en parte, el resultado de
la fe en la persona que te gua. Por esta razn, debo empezar forzosamente mostrando mi
agradecimiento a la directora de este trabajo, Asuncin Gmez Prez. Ha sido incansable
revisora, oportuna consejera, psicloga y, en definitiva, apoyo tenaz y permanente.
En el apartado de atencin de dudas y observaciones, no pueden faltar: Natalia Juristo y
Juan Pazos, de quienes estoy agradecido por sus sugerencias despus de revisar la memoria
de la tesis; Nicola Guarino, que, muy amablemente, estuvo dispuesto a resolver dudas y
proporcionar ideas; Carlos Linares, por hacer el papel de enciclopedia informtica en los
primeros tiempos de este trabajo; los miembros de la Unidad Docente de Ingeniera del
Software, especialmente Hernn llariuzzi, pues me han aconsejado durante el desarrollo de
ODE, y han puesto a mi disposicin toda la documentacin tcnica que me ha hecho falta;
Alvaro Snchez Ladrn de Guevara, quien ha sido el consultor sobre estilo y lenguaje; los
profesores que he tenido en los cursos de mster y de doctorado, que han compartido conmigo
sus conocimientos; y aquellos que, en la prelectura, me dieron consejos, en pblico o en
privado.
Tambin debo agradecer su labor en este trabajo a: Mercedes Blzquez, Juan Manuel
Garca y scar Corcho, miembros del equipo de desarrollo del entorno software que da soporte
tecnolgico al mtodo presentado; y a Mara Dolores Rojas, Paloma Pinilla, Ester Mohedano y
el resto de las personas que han hecho posible la validacin de las ideas presentadas en esta
tesis.
Por otra parte, en la ayuda de los imprevistos y del da a da, deben estar necesariamente:
David Marn, Alberto Cruz, Socorro Bernardos, Araceli Jimnez, Julio Arprez y otros miembros
del Laboratorio de Inteligencia Artificial. Tampoco debo omitir a Lucio Rodrguez Czar, que me
ha ofrecido cualquier material que ha estado a su disposicin para facilitar el trabajo que ahora
presento.
Asimismo, puesto que una tesis doctoral requiere un trabajo con calma y sin precipitacin,
debo expresar mi reconocimiento a quienes me han ayudado a tener un trabajo que me ha
permitido, no slo satisfacer mi vocacin docente, sino tambin tener un respaldo econmico
suficiente como para no estar obligado a obtener resultados apresurados. En este punto debo
citar a: la Universidad Pontificia de Salamanca, Gustavo Lpez (el director del Departamento
de Electrnica y Comunicaciones de dicha universidad), Pepa Hernndez, Genoveva Lpez, y
el Laboratorio de Inteligencia Artificial. En este sentido, adems de ayuda, tambin he recibido
valiosos consejos de distintas personas, entre ellas Doa Pepita (la Seora) y Sofa Pinto, para
poder llegar a un punto de equilibrio entre economa y tiempo de dedicacin a la tesis.
Adems, en esta lista de agradecimientos, deben estar mis hermanas, Mara y Ana, mi
familia en general, los amigos, e incluso muchos conocidos, que han sido ese pblico que
anima como se anima a un deportista para ayudarle a decidir el juego a su favor.
Por ltimo, es decir, a mi entender en la ubicacin ms distinguida de los agradecimientos
Cunto con el principio), debo incluir a mis padres, quienes me han dado apoyo moral y, a veces,
econmico para hacerle frente a los momentos peores.
Resumen
Una ontologa proporciona una terminologa unificada, completa y coherente de un
determinado dominio que puede ser utilizada de manera consistente, precisa y adecuada en
diferentes aplicaciones.
Para construir ontologas, se han elaborado distintas metodologas en los ltimos aos. Sin
embargo, salvo METHONTOLOGY, ninguna de ellas propone y describe una etapa de
conceptualizacin. Esta situacin en el plano metodolgico se proyecta en el plano tecnolgico.
Los entornos de desarrollo de ontologas estn pensados para codificar las ontologas
directamente en los lenguajes de implementacin, sin realizar una etapa de conceptualizacin
previa. Esto origina que, durante el desarrollo de las ontologas, se aborden dos problemas
simultneamente, uno de modelizacin y otro puramente tecnolgico, pues quienes estn
desarrollando la ontologa analizan los conocimientos considerando, en todo momento, la
tecnologa que se utiliza para implementarlos.
Por otra parte, tal y como se ha comprobado en este trabajo, diferentes ontologas tienen
distintas necesidades de modelizacin; no obstante, los entornos software de desarrollo de
ontologas utilizan esquemas de modelizacin fijos y predeterminados.
Las aportaciones que se hacen en este trabajo para enmendar las carencias expuestas
anteriormente se pueden resumir en:
1. Elaboracin de un mtodo bi-fase de conceptualizacin flexible de ontologas. En
la primera fase se especifica, se conceptualiza, se formaliza y se implementa el esquema
de conceptualizacin que se va a seguir durante el desarrollo de la ontologa de dominio
y, en la segunda fase, se conceptualiza e implementa la ontologa de dominio siguiendo
el esquema descrito en la fase anterior.
Para llevar a cabo la conceptualizacin del esquema de conceptualizacin sobre el
cual se construir la ontologa de dominio, en este trabajo se propone un mtodo para
elaborar meta-modelos conceptuales que definan declarativamente esquemas de
conceptualizacin en el nivel de conocimientos. Adems, se ha elaborado un lenguaje
formal para formalizar los meta-modelos en el nivel simblico llamado LBIR
{Language for Building Intermedate Representations). Este lenguaje formal es tan
expresivo como la notacin utilizada para crear meta-modelos conceptuales.
Con el propsito de facilitar la construccin de meta-modelos, se propone un
esquema de conceptualizacin de referencia, al cual se pueden aadir o quitar
elementos de conceptualizacin segn las necesidades de modelizacin de una
ontologa concreta. Tal esquema de conceptualizacin est expresado formalmente en
LBIR, y permite modelizar los mismos componentes que la parte esttica de los
lenguajes clsicos de implementacin de ontologas.
utilizando el mtodo propuesto en este trabajo, los modelos conceptuales obtenidos

son explcitos y lo suficientemente precisos como para poder generar, con el software
adecuado, la ontologa en un lenguaje computable.
2. Construccin de un entorno tecnolgico que da soporte al mtodo propuesto:
Ontology
Design
Environment
(ODE).
Este
entorno
software
automatiza
la
transformacin de un esquema de conceptualizacin descrito con LBIR en un esquema

de base de datos relacional sin prdida de expresividad. Adems, da soporte en la
elaboracin del modelo conceptual de la ontologa de dominio, ayuda en la verificacin
de dicho modelo, y permite la traduccin automtica y directa de la conceptualizacin a
la implementacin de una ontologa de dominio en el lenguaje Ontolingua.
ODE manipula esquemas de conceptualizacin que estn descritos de manera
declarativa y que no estn embebidos en el programa, por consiguiente, un cambio en el
esquema de conceptualizacin no obliga a cambiar el programa.
Aunque la utilizacin tanto del mtodo como del entorno software se ha realizado
fundamentalmente en el rea de las ontologas, tambin se han hecho pruebas en otras reas
distintas.
Abstract
An ontology provides an unified, complete and coherent terminology o a given domain that
can be used in a consistent, accurate and suitable way in different applications.
During the last years, different methodoogies have been elaborated for building ontologies.
Nevertheless, except METHONTOLOGY, there is no methodology proposing and describing a
conceptualisation phase. This situation at metliodological level is projected at technologica
leve!. Technologica environments for developing ontologies are thought for codifying ontologies
directly using implementation languages, without carrying out a previous conceptualisation
phase. This provokes that two problems are tackied simultaneously during the development of
an ontology, one of modeiisation and another purely technologica. Indeed, the knowledge is
analysed considering, all the time, the technology to be used for implementing this knowledge.
On the other hand, as it is presented in this work, different ontologies have different needs of
modeiisation. However, software environments for developing ontologies use fixed and
predetermined modeiisation schemas.
The contributions of this work for correcting the exposed shortages can be summarised in
the following way:
1. Elaboration of a bi-phase method for conceptuaiising ontologies. In the first phase,
the
specification,
conceptualisation,
formalisation
and
implementation
of
the
conceptualisation schema to be used during the ontology development is carried out. In

the second phase, the domain ontology is conceptualised following the schema described
in the previous phase.
A method for elaborating conceptual meta-models is proposed for carrying out the
conceptualisation
of
the
conceptualisation
schema. These
meta-models
define
declaratively conceptualisation schemas at the knowledge level. Besides, a formal

language elaborated for formalsing meta-models at the symbolic level, called LBIR,
{Language for Building Intermedate Representations), has been. This formal language is
as expressive as the notation used for creating conceptual meta-models.
To faciltate the building of meta-models, a reference conceptualisation schema is
proposed. It is possible to add and remove conceptualisation elements to and from this
reference schema according to the modeiisation needs of each ontology. Such
conceptualisation schema is formally expressed in LBIR, and it can modelise the same
components as the static part of the classic languages for implementing ontologies.
Using the method proposed in this work, the obtained conceptual models are explicit
and accurate enough to genrate, using the suitable software, the ontology in a
computable language.
2. Building of a technological environment that supports the proposed method:

Ontology Design Environment (ODE). This software environment automates the
transformation, without loss of expressiveness, from a conceptualisation schema
described in LBIR to a relational datbase schema. Besides, it supports the elaboration of
the conceptual model of the domain ontology, it helps in its verification, and it allows the
direct and automatic translation from the conceptualisation to the implementation of a
domain ontology in Ontolingua language.
ODE manipulates conceptualisation schemas that are described in a declarative way,
and that are not soaked up in the program. Therefore, a changa in the conceptualisation
schema does not forc a change in the program.
Although the used both the method and software environment has been carried out
essentially n the rea of ontologies, proofs have been made in other reas.
IfDICE
1.
INTRODUCCIN
1.1
CONSTRUCCIN DE ONTOLOGAS EN EL NIVEL DE CONOCIMIENTOS
1.2
PROPUESTA DE UN ESQUEMA DE CONCEPTUALIZACIN EXPRESIVO
1.2.1 OBTENCIN DEL ESQUEMA DE REFERENCIA
1.2.2 EXPRESIVIDAD DEL ESQUEMA DE REFERENCIA
1.3
PROPUESTA DE UN MTODO BI-FASE DE CONCEPTUALIZACIN
1.4
ORGANIZACIN DE LA MEMORIA
2. ESTADO DE LA CUESTIN
2.1
INTRODUCCIN
2.2
COMPONENTES DE LAS ONTOLOGAS
2.3
METODOLOGAS PARA EL DESARROLLO DE ONTOLOGAS Y SUS
PROPUESTAS PARA CONCEPTUALIZAR
2.3.1 CYC
2.3.2 METODOLOGA DE USCHOLD YKING
2.3.3 METODOLOGA DE GRNINGER Y FOX.
2.3.4 EL ENFOQUE DE AMAYA BERNARAS Y SUS COLABORADORES
2.3.5 LA METODOLOGA BASADA EN SENSUS
2.3.6 METHONTOLOGY
2.3.7 CONCLUSIONES, ORIENTADAS A LA CONCEPTUALIZACIN, SOBRE LAS
METODOLOGAS
2.4
ENTORNOS SOFTWARE PARA EL DESARROLLO DE ONTOLOGAS
2.4.1 CYC
2.4.2 ELONTOLINGUASERVER
2.4.3 ONTOSAURUS
2.4.4 TADZEBAO-WEBONTO
2.4.5 PROTEGE 2000
2.4.6 EVALUACIN DE LOS ENTORNOS SOFTWARE PARA EL DESARROLLO DE
ONTOLOGAS
2.4.7 CONCLUSIONES SOBRE LOS ENTORNOS SOFTWARE
2.5
LOS LENGUAJES CLSICOS PARA LA IMPLEMENTACIN DE ONTOLOGAS
2.5.1 ONTOLINGUA
2.5.2 EL LENGUAJE UTILIZADO EN EL OKBC
2.5.3 OCML
2.5.4 FLOGIC
2.5.5 LOOM
2.5.6 SNTESIS SOBRE LA EXPRESIVIDAD DE LOS LENGUAJES
2.6
CONCLUSIONES SOBRE EL ESTADO DE LA CUESTIN
3. PLANTEAMIENTO
3.1
INTRODUCCIN
3.2
VOCABULARIO
3.3
VISIN GENERAL DE LA SOLUCIN PROPUESTA
3.4
APORTACIONES PRINCIPALES DEL TRABAJO
3.5
HIPTESIS DE TRABAJO
4. DESCRIPCIN DETALLADA DE LA SOLUCIN
4.1
INTRODUCCIN
4.2
ESPECIFICACIN DEL ESQUEMA DE CONCEPTUALIZACIN
4.2.1 INTRODUCCIN
4.2.2 ANLISIS DE LA EXPRESIVIDAD DE LOS ESQUEMAS
4.2.2.1 INTRODUCCIN
4.2.2.2 ENTRADAS
4.2.2.3 PRODUCTOS OBTENIDOS
4.2.2.4 PROCEDIMIENTO PARA LLEVAR A CABO LA TAREA
4.2.2.5 QUINES INTERVIENEN EN LA TAREA
1
3
9
9
10
11
14
17
19
21
22
22
23
24
25
26
27
29
30
30
30
31
31
32
32
36
37
37
38
38
39
39
40
41
45
47
47
48
52
55
57
58
58
58
60
60
61
61
61
62
4.2.3 ELABORACIN DESDE CERO DE UNA ESPECIFICACIN

62
4.2.3.1 INTRODUCCIN
62
4.2.3.2 ENTRADAS
62
4.2.3.3 PRODUCTOS A OBTENER
62
4.2.3.4 CASO PRCTICO: ESPECIFICACIN DE UN ESQUEMA
62
4.2.4 MODIFICACIN DE LA ESPECIFICACIN DE UN ESQUEMA
67
4.2.4.1 INTRODUCCIN
67
4.2.4.2 DESCRIPCIN DE LA MODIHCACIN DE CUALQUIER ESQUEMA DE
CONCEPTUALIZACIN
68
4.2.5 CASO PRCTICO: CONTROL DE CAMBIOS SOBRE UN ESQUEMA DE
CONCEPTUALIZACIN.
69
4.2.6 CONCLUSIONES SOBRE LA ESPECIFICACIN DEL ESQUEMA DE
CONCEPTUALIZACIN.
70
4.3
CONCEPTUALIZACIN DEL ESQUEMA DE CONCEPTUALIZACIN
71
4.3.1 ELABORACIN DESDE CERO DE UN META-MODELO
:...
72
4.3.1.1 INTRODUCCIN
72
4.3.1.2 ENTRADAS
73
73
4.3.1.3.1 Componentes a definir en un meta-modelo
73
4.3.1.3.2 Caractersticas que tendrn los componentes a especificar en un meta-modelo
74
4.3.1.3.3 Documentacin generada en la tarea de elaboracin desde cero de un
meta-modelo
89
4.3.1.4 PROCESO PARA LLEVAR A CABO LA TAREA
91
4.3.1.5 QUINES TIENEN QUE LLEVAR A CABO LA TAREA
92
4.3.1.6 CASO PRCTICO: DEFINICIN DE UN META-MODELO
92
4.3.1.6.1 Creacin de la ficha de descripcin general del meta-modelo
92
4.3.1.6.2 Creacin del glosario de elementos de conceptualizacin
92
4.3.1.6.3 Creacin del diagrama de orden de elementos de conceptualizacin
92
4.3.1.6.4 Creacin de las tablas de descripcin detallada de elementos de
conceptualizacin y de reglas de verificacin
96
4.3.1.6.5 Grafo de reglas de verificacin de la consistencia
117
4.3.2 MODIFICACIN DE UN META-MODELO
118
4.3.2.1 DESCRIPCIN DE LA MODIFICACIN DE CUALQUIER META-MODELO
118
4.3.2.2 CASO PRCTICO: MODIHCACIN DE UN META-MODELO ANTERIOR
121
4.3.3 CONCLUSIONES SOBRE LA CONCEPTUALIZACIN DEL ESQUEMA DE
CONCEPTUALIZACIN.
128
A.A
FORMALIZACIN DEL ESQUEMA DE CONCEPTUALIZACIN
129
4.4.1 INTRODUCCIN
129
4.4.2 ENTRADAS
131
4.4.3 PRODUCTOS A OBTENER
131
4.4.3.1 CARACTERSTICAS QUE DEBE TENER EL LENGUAJE
131
4.4.3.2 SINTAXIS DE LBIR
132
4.4.3.2.1 Explicacin intuitiva de la sintaxis de LBIR
132
4.4.3.2.2 Gramtica
134
4.4.3.3 EJEMPLOS EN LBIR DE DEFINICIONES DEL ESQUEMA DE REFERENCIA... 139
4.4.4 PROCEDIMIENTO PARA LLEVAR A CABO LA TAREA
141
4.4.5 QUINES INTERVIENEN EN LA TAREA
141
4.4.6 CONCLUSIONES SOBRE LA FORMAUZACIN DEL ESQUEMA DE
CONCEPTUAUZACIN.
141
4.5
IMPLEMENTACIN DEL ESQUEMA DE CONCEPTUALIZACIN
142
4.5.1 INTRODUCCIN
142
4.5.2 ANLISIS DEL CDIGO LBIR
146
4.5.2.1 INTRODUCCIN
146
4.5.2.2 ENTRADAS
146
146
4.5.2.3.1 Limitaciones del modelo entidad relacin con respecto a la expresividad de
LBIR
147
4.5.2.3.2 Extensin propuesta para el modelo entidad-relacin
147
148
150
4.5.2.6 EJEMPLO DE GENERACIN DE UN ESQUEMA ENTIDAD RELACIN A
PARTIR DE UN META-MODELO EN LBIR
150
4.5.3 DISEO DEL ESQUEMA DE DATOS
152
4.5.3.1 INTRODUCCIN
152
4.5.3.2 ENTRADAS
152
152
153
4.5.3.4.1 Reglas de generacin de las tablas y las vistas del esquema relacional
153
4.5.3.4.2 Ejemplo de generacin de tablas y las vistas del esquema relacional
155
4.5.3.4.3 Generacin de las reglas de consistencia expresadas en lgebra relacional
156
4.5.3.4.4 Ejemplo de generacin de las reglas de verificacin de la consistencia en lgebra
relacional
157
4.5.3.4.5 Propiedades del esquema relacional obtenido a partir de cualquier meta-modelo
en LBIR
158
4.5.4 IMPLEMENTACIN DEL ESQUEMA DE DATOS
159
4.5.4.1 INTRODUCCIN
159
4.5.4.2 ENTRADAS
159
159
159
4.5.4.5 QUINES LLEVAN A CABO LA TAREA
160
4.5.5 CONCLUSIONES SOBRE LA IMPLEMENTACIN DEL ESQUEMA DE
CONCEPTUALIZACIN.
160
4.6
CONCEPTUALIZACIN DE LA ONTOLOGA DE DOMINIO
160
4.6.1 INTRODUCCIN
160
4.6.2 ENTRADAS
161
162
162
163
4.7
IMPLEMENTACIN DE LA ONTOLOGA DE DOMINIO
163
4.7.1 INTRODUCCIN
163
4.7.2 ESTUDIO DEL LENGUAJE DESTINO.
163
4.7.2.1 INTRODUCCIN
163
4.7.2.2 ENTRADAS
163
163
165
165
4.7.3 ESPECIFICACIN DE LAS REGLAS DE GENERACIN DE CDIGO
165
4.7.3.1 INTRODUCCIN
165
4.7.3.2 ENTRADAS
165
165
4.7.3.3.1 DESCRIPCIN
165
4.7.3.3.2 EJEMPLO BREVE
166
170
170
4.7.4 CONSTRUCCIN DEL TRADUCTOR CONCEPTUALIZACIN-IMPLEMENTACIN... 170
4.7.4.1 INTRODUCCIN
170
4.7.4.2 ENTRADAS
171
171
171
171
4.7.4.6 GENERACIN DE CDIGO
171
4.7.5 CONCLUSIONES SOBRE LA IMPLEMENTA CIN DE LA ONTOLOGA DE DOMINIO 171
4.8
EL SOPORTE TECNOLGICO DEL MTODO DE CONCEPTUALIZACIN

FLEXIBLE: ODE
4.8.1 INTRODUCCIN
4.8.2 ARQUITECTURA GENERAL DE ODE.
4.8.3 METODOLOGA Y NORMAS UTILIZADAS DURANTE EL DESARROLLO DEL
SOFTWARE
4.8.4 CONCLUSIONES SOBRE ODE
5. EVALUACIN DE LA SOLUCIN
6
CONCLUSIONES
7
LNEAS FUTURAS
BIBLIOGRAFA
172
172
174
176
177
179
199
209
213
ANEXOS
I VISIN GENERAL DEL LENGUAJE ONTOLINGUA
1-3
LIKIF
1-3
1.2 EL LENGUAJE ONTOLINGUA
1-3
1.2.1 ELEMENTOS DEL LENGUAJE
1-4
1.2.2 FORMATO DE UNA ONTOLOGA EN ONTOUNGUA
1-6
II EJEMPLO DE CONCEPTUALIZACIN CON EL ESQUEMA DE REFERENCIA
II-3
i n GRAMTICAS DE LOS CAMPOS, LOS VRTICES Y LOS ARCOS
III-3
m . l GRAMTICAS DE LOS CAMPOS DE LAS TABLAS
III-3
III.2 GRAMTICAS DE LOS VRTICES Y DE LOS ARCOS DE LOS GRAFOS
III-IO
IV GRAMTICA DE LAS REGLAS DE CONSISTENCIA
IV-3
V EL ESQUEMA DE REFERENCIA EN LBIR
V-3
VI PATRONES DE TRADUCCIN DEL ESQUEMA DE REFERENCIA A ONTOLINGUA.... VI-3
VLl GENERACIN DE LA CABECERA DE LA ONTOLOGA
VI-3
VI.2 GENERACIN DE LAS CLASES
VI-4
VI.3 GENERACIN DE RELACIONES
VI-6
Vl.3.1
GENERACIN DE RELACIONES A PARTIR DE ATRIBUTOS DE INSTANCIA
VI-6
Vl.3.2
GENERACIN DE RELACIONES A PARTIR DE LOS ATRIBUTOS DE CLASE.
VI-8
VI.3.3
GENERACIN DE RELACIONES A PARTIR DE LAS RELACIONES BINARIAS
VI-8
VI.4 GENERACIN DE AXIOMAS
VI-9
VI.5 GENERACIN DE FUNCIONES
VI-11
VI.6 GENERACIN DE INSTANCIAS
VI-12
VI.6.1
GENERACIN DE INSTANCIAS A PARTIR DE LA TABLA DE INSTANCIAS
VI-12
VI.6.2
GENERACIN DE INSTANCIAS A PARTIR DLAS CONSTANTES
VI-13
VI.7 TRADUCCIN DE LAS EXPRESIONES
VM4
1. INTRODUCCIN
Mariano Fernndez Lpez
Captulo 1. Introduccin
1.1 CONSTRUCCIN DE ONTOLOGIAS EN EL NIVEL DE

CONOCIMIENTOS
En el clebre artculo The Knowledge Leve/[Newell, 82], Newell afirm lo siguiente:
Haciendo una distincin ntida entre el nivel de conocimientos y el nivel simblico, la
teora implica una distincin igualmente ntida entre los conocimientos necesarios para
resolver un problema, y el tratamiento necesario para hacer que estos conocimientos
sean operativos en tiempo real y en espacio real.
[Esta separacin entre el nivel de conocimientos (en que el computador es visto como un
agente que utiliza conocimientos) y el nivel simblico (en que el computador es visto como un
sistema que procesa cadenas de smbolos) ha tenido gran influencia en la Inteligencia Artificial
en general y en la ingeniera del conocimiento (INCO) en particular. As, metodologas como
CommonKADS [Schreiber et al.; 00], IDEAL [Gmez Prez et al.; 97], Waterman [Waterman,
86], etc. hacen una distincin entre las etapas de conceptualizacin y formalizacin, sta ltima
acercndose a la tecnologa que se va a utilizar en la implementacin. Tal planteamiento ha
facilitado enormemente el desarrollo de sistemas basados en conocimientos (SS.BB.CC), pues
quienes construyen estos sistemas no tienen que enfrentarse simultneamente a dos
problemas: el de analizar los conocimientos, y el de las restricciones que impone la tecnologa.
Esta manera de proceder es anloga al desarrollo del software tradicional, pues en el
anlisis clsico de sistemas, por ejemplo, tal y como se plantea en Mtrica [MAP, 90] o en
SSADM [Downs et al.; 98], primero se intenta ver las operaciones desde el punto de vista de
los usuarios, para lo cual se les entrevista, y se intenta aprender cmo funcionan las cosas
Gmez-Prez et al.; 97], y, a continuacin, el ingeniero cambia la perspectiva intentando ver el
problema desde el punto de vista de la mquina. Es decir, se trata de describir el proceso de
modelizacin como una transformacin de una necesidad del usuario en el dominio de la
aplicacin, a un producto software que opera en el dominio de la implementacin [Gmez
Prez et al., 96]. Esta transformacin, representada en la Figura 1.1, se descompone, a su vez,
en las siguientes transformaciones (adaptado de Blum [Blum, 96] y de Gmez Prez y colegas
[Gmez Prez et al.; 97]):
1. Tv N -> C; es decir, de una necesidad reconocida en un dominio de aplicacin a un
modelo conceptual que describe la solucin. Este modelo se caracteriza por poder ser
entendido y validado por los especialistas en el dominio.
2. Ta: C -> F; esto es, de la solucin expresada en el modelo conceptual a un modelo
formalizado que define qu debe hacer el software.
3. T3: F -^ I; es decir, del modelo formalizado a una implementacin que es correcta con
respecto al modelo formalizado.
Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos
Dominio de la
aplicacin (N)
T,
Modelos
conceptuales (C)
\
\
T
Modelos
\ formalizados (I^
Tj
<
Dominio de la
aplicacin (I).
Figura 1.1. Modelo de proceso esencial del software (adaptado de Gmez Prez y colegas [Gmez Prez
et al.; 97] y de Blum [Blum, 96])
La primera transformacin se conoce como conceptualizacin o diseo epistemolgico del

sistema. Durante la conceptualizacin, el ingeniero y el entendido en el dominio explican los
conceptos clave, las relaciones, y los flujos de informacin caractersticos necesarios para
describir el proceso de resolucin del problema en el dominio dado [Hayes-Roth et al.; 83]. Se
lleva a cabo utilizando notaciones, fnnulas y diagramas que permiten expresar los
conocimientos. Estas notaciones, por ejemplo, rboles de decisin, organigramas, tablas de
descripcin de atributos, etc., se conocen en la metodologa IDEAL [Gmez Prez et al.; 97]
con el nombre de representaciones externas intermedias, porque son independientes del
formalismo de representacin utilizado, posteriormente, en la formalizacin.
No obstante, a pesar de los beneficios obtenidos de la distincin entre nivel de
conocimientos y nivel simblico, en la construccin de SS.BB.CC ha sido necesario convivir
con dos inconvenientes: por una parte la fragilidad de estos sistemas debido a que no tienen
conocimientos de sentido comn [Lenat et al.; 90] y, por otra parte, el cuello de botella que
supone la adquisicin de conocimientos [Meches et al., 91]. Para hacerle frente al primer
problema, a mediados de los ochenta, en el proyecto Cyc [Lenat et al.; 90], se comenz a
construir una gran base de conocimientos (BC) con conocimientos de sentido comn. Esta BC
puede ser considerada una ontologa, pues el propsito de una ontoioga es captar
conocimientos del dominio de una forma general, y proporcionar una comprensin del dominio
consensuada, la cual puede ser reutilizada y compartida por aplicaciones y grupos de personas
[Chandrasekaran et al.; 99], y la BC de Cyc est pensada para que sus conocimientos sean
compartidos por distintas aplicaciones. En lo referente al problema del cuello de botella en la
adquisicin de conocimientos, en el Knowledge Sharing Efforf [Meches et al.; 91], a principios
de los noventa, se propuso construir ontologas para que fueran usadas como componentes
reutilizables en diferentes sistemas. Tanto este proyecto como el anterior, Cyc, han tenido
importantes repercusiones en otros proyectos.
Actualmente, la aplicacin de ontologas se ha diversificado. De hecho, se estn utilizando
en: sistemas de agentes [Luke et al.; 97]; sistemas de gestin de conocimientos [Domingue et
al.; 00]; plataformas de comercio electrnico [McGuinness, 99], [Fensel, 00]; generacin de
lenguaje natural [Aguado et al.; 98]; extraccin de informacin a partir de textos [AussenacGilles et al.; 00], [Maedche et al.; 00]; etc.
Para construir ontologas, se han propuesto distintas metodologas en los ltimos aos: la
metodologa utilizada en el desarrollo de Cyc [Lenat et al.; 90], la de Uschold y King [Uschold et
al.; 95], la de Grninger y Fox [Grninger et al.; 95], la de Bernaras y sus colaboradores
[Bernaras et al.; 96], la metodologa utilizada en SENSUS [Swartout et al.; 97], y
METHONTOLOGY [Fernndez et al.; 97], [Gmez Prez, 98a], [Fernndez Lpez et al.; 99],
que es la metodologa para desarrollo de ontologas
elaborada en el Laboratorio de
Inteligencia Artificial (LIA) de la Facultad de Informtica (Fl) de la Universidad Politcnica de

Madrid (UPM).
Ahora bien, la mayora de las metodologas para el desarrollo de ontologas no proponen
una etapa de conceptualizacin anterior a la formalizacin y a la implementacin, y, en los
casos en que s se propone esta etapa, no se justifica ni se establece cmo llevarla a cabo,
salvo en METHONTOLOGY. En algunos casos, incluso, como por ejemplo en la metodologa
de Uschold y King, tan siquiera se establece una etapa de formalizacin y, por tanto, la
codificacin de la ontologa se hace de manera directa una vez adquiridos los conocimientos
del dominio. Esta ausencia en el plano metodolgico se proyecta en el plano tecnolgico de tal
forma que los entornos de desarrollo de ontologas, como son el utilizado en Cyc [Lenat et al.;
90], el entorno Ontolingua Server [Farquhar et al.; 96] y Ontosaurus [Swartout et al.; 97]
(utilizado en SENSUS), estn pensados para codificar las ontologas en lenguajes de
implementacin, no para desarrollarlas en el nivel de conocimientos. Teniendo en cuenta que,
tal y como se ha dicho anteriormente, tanto en las metodologas de la INCO (CommonKADS
[Schreiber et al.; 00], IDEAL [Gmez Prez et al.; 97], Waterman [Waterman, 86], etc.) como en
las de la INSO (Mtrica [MAP, 90] o en SSADM [Downs et al.; 98], etc.) s existe una etapa de
modelizacin que es independiente de la tecnologa, resulta al menos sorprendente que en el
desarrollo
de
ontologas
no
haya,
generalmente,
una
fase
de
conceptualizacin.
Consiguientemente, cabe preguntarse: la construccin de ontologas supone una ruptura tan

radical con respecto al desarrollo de los SS.BB.CC o al desarrollo de los sistemas software
tradicionales como para no necesitar esta fase de conceptualizacin?, es ms, es mejor
codificar las ontologas directamente tal y como se hace siguiendo la propuesta Uschold y King,
o es mejor, llevar a cabo etapas intermedias entre la adquisicin conocimientos y la
implementacin?. Segn la experiencia del autor de este trabajo en el desarrollo de ontologas,
la respuesta es que la ausencia de etapas intermedias de modelizacin se debe ms a la falta
de madurez de las metodologas existentes [Fernndez Lpez, 99a] que a la conveniencia de
esta omisin. De hecho, codificar directamente las ontologas partiendo de la adquisicin de
conocimientos, y no llevar a cabo una etapa de conceptualizacin tiene inconvenientes
importantes [Fernndez Lpez et al.; 99]:
1. No obtiene una documentacin que presente los conocimientos de una manera

estructurada y cercana a los entendidos del dominio. Los conocimientos slo aparecen
reflejados en los documentos obtenidos de la adquisicin de conocimientos y en los
listados de cdigo.
2. Los modelos conceptuales de las antologas estn implcitos en los cdigos de
implementacin. El hacer explcitos los modelos conceptuales normalmente requiere un
proceso de ingeniera inversa.
3. Los entendidos del dominio y quienes vayan a utilizar la antologa no entienden las
antologas codificadas en lenguajes de implementacin [Aguado et al.; 98]. Por ejemplo,
la experiencia ha mostrado que, en las ontologas construidas con el Ontolingua Server,
los expertos y los usuarios han podido llegar a entender y validar completamente las
taxonomas, y parcialmente las instancias. Sin embargo, no han sido capaces de
entender las definiciones abstractas de los conceptos, relaciones, funciones y axiomas.
Por otra parte, desde el punto de vista de la formalizacin, estos expertos tampoco han
sido capaces de introducir sus conocimientos en este servidor.
4. Se estn resolviendo dos problemas simultneamente, una de modelizacin y otro
puramente tecnolgica, en vez de resolverlos por separado. Al igual que ocurre con los
SS.BB.CC tradicionales, llevar a cabo una codificacin directa en un lenguaje de
implementacin concreto puede ser difcil, especialmente en las ontologas complejas,
pues quienes estn desarrollando la ontologa no tienen la posibilidad de hacer un
anlisis de los conocimientos independiente de los detalles de la tecnologa que se va a
utilizar para modelizarlos.
5. Las limitaciones del lenguaje de implementacin pueden provocar que se traicione el
consenso (ontological commitments) sobre ciertos conocimientos. Esto es debido a que
algunas de las decisiones que se toman en la representacin de los conocimientos estn
basadas simplemente en la conveniencia de la notacin o de la implementacin [Gruber,
92]. Si se implementa, por ejemplo, una ontologa en C++ y se dice que cierto valor es un
flaat, no se est asumiendo que dicho valor sea un nmero real en general, sino un
nmero real con ciertas restricciones, ya que los valores posibles de un float no
coinciden con el conjunto de los nmeros reales.
6. Los desarrolladares de ontologas pueden llegar a tener problemas de comprensin con
las ontologas que construyen otros si estn implementados en distintos lenguajes a los
que conocen. En efecto, las mismas personas que se dedican habitualmente al
desarrollo de ontologas tienen muchas dificultades para entender ontologas escritas en
lenguajes que no son los que ellos suelen utilizar.
Para mostrar en conjunto algunos de estos inconvenientes, supngase que la frmula
densidad a20-C = peso atmico / volumen atmico a 20 -C
en el dominio de la qumica, se escribiera directamente en Ontolingua. El cdigo resultante

sera, segn una de las implementaciones posible, el siguiente:
(define-function densidad(?elemento) :-> ?densidad-a-20-C

"La densidad de un elemento es igual a su peso atmico dividido entre su volumen
atmico"
:iff-def
(and (elemento ?elemento)
(den$idad-a-20-C ?elemento ?densidad-a-20-C)
(exists (?peso-atmico ?volumen-atmico-a-20-C)
(and
(peso-atmico ?elemento ?peso-atmico)

(volumen-atmico-a-20-C ?elemento ?volumen-atmico-a-20-C)
(= ?densidad-a-20-C (/ ?peso-atmico ?volumen-atmico-a-20-C)))
Este ejemplo muestra que a menos que la persona que examine el cdigo est muy
familiarizada con el lenguaje Ontolingua, entender las definiciones y escribir otras nuevas es
casi imposible y, aun teniendo xito en esta tarea, se necesitara mucho esfuerzo para llevarla
a cabo. El problema no es entender que la densidad a 20 -C es igual al peso atmico dividido
por el volumen atmico a esos mismos 20 -C, sino escribir esto en el lenguaje destino. Por
consiguiente, algo que es aparentemente muy sencillo en el nivel de conocimientos, es muy
complicado cuando se expresa en el nivel de implementacin, si no se est familiarizado con el
lenguaje. Por ello, las ontologas son construidas exclusivamente por ingenieros que son
buenos conocedores de los lenguajes en que stas se implementan. Como estos ingenieros no
son necesariamente entendidos en el dominio, el esfuerzo en la adquisicin de conocimientos
puede ser muy elevado.
Se puede decir, por tanto, que a pesar de que uno de los propsitos ms importantes para
la construccin de ontologas es el de aliviar el problema del enorme coste que supone la
adquisicin en los SS.BB.CC, este objetivo slo se consigue parcialmente.
Para atenuar los inconvenientes derivados de la construccin de ontologas en el nivel
simblico, en este trabajo se presenta un mtodo de conceptualizacin de ontologas, en el
nivel de conocimientos, que permite la utilizacin de elementos de conceptualizacin (EE.CC)
grficos y tabulares que son fciles de entender, y de manejar por personas no conocedoras de
los lenguajes de implementacin de ontologas.
Ahora bien, esta manera de conceptualizar tiene, al menos, dos inconvenientes: es
necesario, tal y como se muestra en la
Figura 1.2.a, transformar el modelo conceptual
resultante de la conceptualizacin en un modelo formalizado obtenido en la etapa de

formalizacin y, luego, durante la etapa de implentacin, es necesario transformar el modelo
formalizado en un modelo computacional. En esta secuencia de modelos es necesario evaluar

cada modelo y las transformaciones entre modelos. Por esta razn, en el presente trabajo se
propone una segunda alternativa (Figura 1.2.b) que consiste en no formalizar, conceptualizar
de manera ms formal, y automatizar la transformacin de la conceptualizacin en
implementacin. Obsrvese que con este enfoque se aumenta el nivel de formalidad de la
conceptualizacin, y por ser la conceptualizacin ms formal, sta "invade" parte del "espacio"
de la formalizacin. As, es posible pasar de la conceptualizacin a la implementacin de
manera automtica, es decir, se elaboran modelos conceptuales computables.
Adquisicin
^r
Conceptualizacin
^r
Formalizacin
^r
+
^f
Implementacin
Figura 1.2.a
Adquisicin
Adquisicin
V
Conceptualizacin
--i
ConL.ptujI/iLion
Implementacin
Implementacin
r)
F igura 1.2 .b
Figura 1.2. Supresin de la formalizacin a travs de una conceptualizacin ms formalizada
En otras reas distintas a la de las ontologas se ha seguido un enfoque anlogo. En el caso

de la ingeniera del software (INSO), la programacin ha ido subiendo de "nivel", separndose
cada vez ms de la mquina y acercndose ms a la persona. As, lenguajes como FORTRAN
o COBOL, se alejaron del lenguaje mquina y, en el da de hoy, hay herramientas, como por
ejemplo, PowerDesigner (http://www.sybase.eom/detail/1,3151,1001719,00.htm!) que generan
cdigo de implementacin a partir de un modelo de anlisis. Por otra parte, en el caso de la
INCO, tambin se ha ido subiendo de nivel, de tal manera que, en la actualidad, herramientas
como Kappa y KEE, de IntelliCorp Inc., o ART, de Inference Corp., por ejemplo, automatizan el
paso de la formalizacin a la implementacin en el desarrollo de SS.BB.CC.
ODE (Ontology Design Environment), el entorno software que dar soporte tecnolgico al
mtodo de conceptualizacin presentado en este trabajo, dar la posibilidad de pasar
directamente de la conceptualizacin a la implementacin en Ontolingua [Farquhar et al.; 96],
uno de los lenguajes de implementacin ms utilizados en el desarrollo de ontologas. Este
lenguaje tiene, adems, la ventaja de tener traductores a otros lenguajes (Loom [MacGregor,
90], Epikit, IDL de CORBA [Mowbray et al.; 95], PROLOG, CLIPS y KIF puro) [Farqhuar et al.
96].
Por otra parte, en la evaluacin de ontologas, en ODE se harn aportes importantes con
respecto a los entornos software de desarrollo de ontologas ms conocidos actualmente. En
general, en los entornos software actuales, se hace una pobre evaluacin en el nivel simblico;
sin embargo, con ODE, la evaluacin se llevar a cabo en el nivel de conocimientos. De
hecho, ODE comprobar una gran cantidad de reglas de verificacin de la consistencia del
modelo conceptual por lo que los errores en la conceptualizacin no se arrastran a la
implementacin. Adems, los entendidos del dominio de una ontologa cualquiera podrn
validar el modelo conceptual de dicha ontologa, dado que les resulta comprensible.
Para acotar el alcance de este trabajo, el mtodo se ha aplicado a ontologas de dominio,
es decir, ontologas especficas para un dominio concreto [van Heist et al.; 97], como puede
ser: qumica, geologa, comercio electrnico, etc.; en contraste con ontologas de aplicacin, es
decir, aquellas que contienen las definiciones necesarias para modelizar los conocimientos
requeridos para una aplicacin particular; en contraste tambin con las ontologas genricas,
es decir, aquellas que definen trminos para muchos campos (por ejemplo, estado, evento,
accin, etc.); y en contraste con ontologas de representacin, o lo que es lo mismo, aquellas
que describen las primitivas de representacin {clase, subclase de, instancia, etc.) que se usan
para representar el resto de las ontologas. Adems, el mtodo se ha aplicado para modelizar
conocimientos estticos.
1.2 PROPUESTA DE UN ESQUEMA DE CONCEPTUALIZACIN

EXPRESIVO
Con el propsito de obtener un esquema de conceptualizacin que sirva para un conjunto
amplio de ontologas de dominio, se ha partido de un esquema inicial, el cual se ha ido
retinando de manera emprica mediante la construccin de nuevas ontologas que tenan
nuevas necesidades de modelzacin. Para llegar a este esquema de referencia, han sido
necesarios varios aos de experiencia construyendo ontologas, con diferentes caractersticas,
en dominios diversos.
Una caracterstica deseable del esquema de referencia es su completitud (en lo que a
expresividad se refiere) con respecto a la expresividad que proporcionan los lenguajes de
implementacin de ontologas. Por tanto, una vez elaborado el esquema, se ha comprobado
que permite modelizar los componentes (conceptos, atributos, axiomas, etc.) que se usan en
cualquiera de los lenguajes de implementacin de ontologas para representar conocimientos
estticos.
1.2.1 OBTENCIN DEL ESQUEMA DE REFERENCIA

A mediados de los 90, se inici en el LIA el proyecto METHONTOLOGY. Inicialmente se trabaj
en conceptualizacin, y se public el primer esquema de conceptualizacin en el Workshop on

Ontological Engineering de la conferencia ECAI celebrada en Budapest en 1996 [Gmez Prez
et al.; 96]. Dicho esquema de conceptualizacin estaba inspirado en la conceptualizacin de
conocimientos estticos propuesta por la metodologa IDEAL [Gmez Prez et al.; 97] de
construccin de SS.BB.CC tradicionales. Este primer esquema de conceptualizacin se aplic
en el desarrollo de un prototipo de Chemical-Elements, una ontologa en el dominio de los
elementos qumicos. Ese mismo ao, 1996, el autor de este trabajo present en su proyecto
final de carrera [Fernndez, 96] una versin nueva del esquema, que consista en una
modificacin del esquema anterior que permita el desarrollo de ontologas ms complejas
vinculadas a travs de la relacin de inclusin. Esta nueva versin se haba aplicado al
desarrollo paralelo de Chemical-Crystal y de Chemical-Elements, la primera de ellas en el
dominio de las estructuras cristalinas, y la segunda, en el dominio de los elementos qumicos.
Dos aos ms tarde, en 1998, se present en el Knowedge Acquistion Workshop KAW-98
[Blzquez et al.; 98] un nuevo esquema que incorporaba al de [Fernndez, 96] los EE.CC
adecuados para modelizar relaciones entre conceptos sin necesidad de expresarlas como
atributos. Este esquema estaba basado en el proceso de reingeniera sobre la ontologa de
(KA)^ [Benjamins et al.; 99], que inicialmente estaba escrita en Flogic. En el mismo ao 1998,
se hizo una mejora ms sobre el esquema incorporando una tabla que permita asignar valores
a los atributos de clase sin necesidad de utilizar axiomas. Este nuevo esquema surgi gracias a
la experiencia adquirida en el desarrollo de una ontologa de iones monoatmicos, y en el
proceso de reingeniera de Standard Units [Gruber et al., 94] presentado por Rojas [Rojas, 98].
Finalmente, en 1999, se hizo un nuevo refinamiento para modelizar instancias de relaciones.
Esta ltima versin, que se toma hoy en da como referencia, est basada en la experiencia en
la construccin de una ontologa de silicatos [Pinilla Ponz, 99], y en el desarrollo que se est
llevando a cabo de ontologas sobre hardware y software cuyo propsito es su utilizacin en la
gestin de conocimientos.
Como se puede observar, aunque algunos EE.CC fueran previsibles, se han incorporado
justo en el momento en que se poda comprobar que el formato elegido era el adecuado. Por
ejemplo, antes de 1999 ya se saba que sera necesario modelizar las instancias de las
relaciones; sin embargo, se ha esperado a la construccin de las ontologas de software y
hardware, que tienen muchas de estas instancias, para cambiar el esquema y comprobar que
este nuevo esquema es fcil de manejar, intuitivo, fcil de modificar, etc.
1.2.2 EXPRESIVIDAD DEL ESQUEMA DE REFERENCIA

Una vez obtenido un esquema de referencia estable, tomando como punto de partida el marco
propuesto por Corcho y Gmez Prez [Corcho et al.; 00] que compara la expresividad entre
lenguajes, se ha comparado la expresividad del esquema de referencia con el de los lenguajes
clsicos de desarrollo de ontologas (Ontolingua [Farqhuar et al.; 96], OKBC [Chaudhri et al.;
97], OCML [Motta, 99], Flogic [Kifer et al.; 95] y LOOM [MacGregor, 90]). No se ha hecho la
comparacin cori lenguajes basados en la Web, que tambin se estn utilizando para
10
desarrollar ontologas, por ejemplo XML [Bray et al, 98] o RDF [Lassila et al, 99], porque son
menos expresivos que los lenguajes tradicionales [Corcho et al.; 00].
En el presente trabajo se mostrar que el esquema de referencia puede modelizar los
mismos componentes que la unin de la parte esttica de los lenguajes clsicos de desarrollo
de ontologas.
1.3 PROPUESTA
DE
UN
CONCEPTUALIZACIN
MTODO
BI-FASE
DE
A lo largo de la investigacin que ahora se presenta, se ha pretendido elaborar un mtodo bifase de conceptualizacin flexible, a la medida y computable utilizando meta-modelos
definidos de manera explcita y declarativa. En este apartado 1.3 se exponen estas
caractersticas del mtodo.
En primer lugar, aunque es cierto que el esquema de referencia es cada vez ms estable, y
es muy expresivo e intuitivo, la utilizacin de un esquema prefijado sin posibles modificaciones
tiene los siguientes inconvenientes:
1. No es seguro que el esquema de referencia vaya a ser definitivo. Cabe la posibilidad de
que nuevas necesidades de modelizacin provoquen cambios en el esquema.
2. No todos los EE.CC con todos sus componentes se necesitan para todas las ontologas.
La experiencia a lo largo del trabajo que aqu se presenta ha mostrado que la utilizacin
de elementos superfluos pueden hacer engorrosa la conceptualizacin.
En consecuencia, se ha decidido dar la posibilidad de definir esquemas de conceptualizacin
a la medida. Se tiene as un mtodo flexible, pues se adapta a las necesidades de
modelizacin de cada ontologa.
La definicin de esquemas de conceptualizacin se hace de manera explcita, por lo que se
tienen las ventajas que se presentan a continuacin:
1. Se facilita a construccin de ontologas parparte de diferentes grupos. El hecho de que
haya un acuerdo en los EE.CC a utilizar y la manera de utilizarlos facilita la integracin
de componentes de conocimientos construidos por distintos grupos.
2. La reutilizacin de ontologas es ms sencilla. Al estar explcitos los mecanismos de
modelizacin, se pueden identificar de manera clara y precisa las similitudes y
diferencias entre meta-modelos de ontologas de dominio.
3. Se posibilita la realizacin de una conceptualizacin computable. Para ello tambin se
exige que los esquemas de conceptulazacin se tengan de manera formal.
Asimismo, para independizar la definicin de los esquemas del programa que los procesa,
estos esquemas se definen de manera declarativa. De esta manera, es posible construir un
11
software que soporte la flexibilidad del mtodo.

El primer paso propuesto en el mtodo bi-fase es hacer una especificacin en lenguaje
natural del esquema de conceptualizacin que se va utilizar (cuadro superior izquierdo de la
Figura 1.3). A continuacin, se conceptualiza el esquema de conceptualizacin descrito en la
especificacin. Al producto obtenido en la conceptualizacin de un esquema, se le ha llamado
meta-modelo conceptual, pues es un modelo que describe otro modelo.
NIVEL DE
CONOCIMIENTOS
NP/ELSIMBOUCO
QUE HAY QUE

MODELIZAR:
ESQUEMA DE
CONCEPTUAUZACIN
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grifos)
Formalizacin
(utilizando
LBIR)
Implementacin
(en SQL)
QUE HAY QUE

MODELIZAR:
ONTOLOGAS
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grafos)
Formalizacin
(p.e. marcos)
Implementacin
(p.e. Ontolingua)
Fases de que consta el mtodo de conceptualizacin propuesto en este trabajo
Figura 1.3. Especificacin, conceptualizacin, formalizacin e implementacin en dos planos
Ahora bien, las tablas y grafos utilizados para especificar meta-modelos conceptuales no las
puede procesar directamente un computador. Por consiguiente, para poder darle soporte
tecnolgico a la elaboracin y manipulacin de meta-modelos, es necesario expresarlos en un
lenguaje formal. Esto ha provocado que en este trabajo se haya elaborado un lenguaje formal
para
especificar
meta-modelos,
el
LBIR
{Language
for
Building
Intermedate
Representations). Se mostrar en este trabajo que LBIR tiene la misma expresividad que el
mtodo de especificacin de meta-modelos conceptuales que utiliza tablas y grafos. Para
procesar LBIR, tambin se utilizar ODE, que puede transformar un meta-modelo expresado
en LBIR en un esquema de datos computable, lo cual ha llevado a superar una dificultad
tecnolgica importante, pues en los sistemas clsicos, el esquema de datos se elabora,
prcticamente siempre, en tiempo de diseo, mientras que en ODE se hace en tiempo de
implementacin. Por otra parte, como este esquema de datos sigue el modelo relacional (se
implementa en SQL), se ha hecho otro aporte tecnolgico importante, esta vez dentro del
campo de las ontologas, que consiste en almacenar las ontologas en bases de datos
relacinales, en vez de utilizar ficheros ASCII, que es lo que utilizan los entornos anteriores a
ODE. Tal y como se explicar ms adelante, el almacenamiento en bases de datos
relacinales tiene ventajas importantes. No obstante, aunque en este trabajo se proponga la
utilizacin de bases de datos relacinales, LBIR es independiente de la tecnologa utilizada en
el almacenamiento de ontologas, es decir, diferentes grupos pueden utilizar el mismo esquema
12
en LBIR, que es computable, y usar una tecnologa distinta para procesarlo y guardar las
ontologas.
Se puede decir, por tanto, que segn este planteamiento, las ontologas de dominio tienen
las fases de especificacin y conceptualizacin (en el nivel de conocimientos), y de
formalizacin e implementacin de ontologas (en el nivel simblico) tanto en el plano de la
modelizacin de esquemas de conceptualizacin, como en el plano de la ontologa a
desarrollar.
El mtodo bi-fase propuesto tiene las caractersticas que se han establecido al principio del
apartado, pues:
1. La notacin utilizada en los pasos de la primera fase del mtodo permiten la definicin de
esquemas de manera declarativa y explcita. Adems, se tienen estos esquemas
expresados de manera formal.
2. La flexibilidad est garantizada por el hecho de tener una primera fase de definicin del
esquema de conceptualizacin que permite su adaptacin a cada ontologa.
Tal y como se ha dicho anteriormente, de las caractersticas anteriores se deduce: que la
conceptualizacin sea computable; que el mtodo sea flexible; y que se pueda tener un
software, tambin flexible, que d soporte tecnolgico al mtodo.
En la Figura 1.3, las fases de especificacin y de formalizacin de ontologas aparecen sin
resaltar. En el primer caso se debe a que la especificacin de la ontologa no se considera
dentro de la conceptualizacin, sino como una fase distinta. En el segundo caso se debe a que,
tal y como se ha dicho en el punto 1.1, ODE permite pasar directamente de la
conceptualizacin de ontologas a su implementacin, es decir, se elaboran modelos
conceptuales computables.
Concretamente, permite traducir
al lenguaje
Ontolingua
[F-arquhar et al.; 96] cualquier ontologa descrita segn el esquema de referencia. De esta
forma, cuando se conceptualiza segn este esquema, y se desea tener la ontologa en
Ontolingua o en cualquiera de los lenguajes para los que hay traductores desde Ontolingua, no
se requiere la etapa de formalizacin. Se puede decir, por tanto, que una visin general de
ODE es la que se presenta en la Figura 1.4. El mdulo LBIR recibe la especificacin de metamodelos en LBIR elaborada por personas que son, al mismo tiempo, entendidas en
conceptualizacin y conocedoras del LBIR. Este mismo mdulo genera un esquema de datos
en SQL. Por otra parte, el mdulo que permite conceptualizar el dominio de la ontologa (Core)
da la posibilidad de que una persona que no conozca el lenguaje en que se va implementar la
ontologa la conceptualice siguiendo uno de los meta-modelos. Adems, el Core almacena las
ontologas conceptualizadas siguiendo el esquema SQL obtenido del meta-modelo elegido, y
da la posibilidad de traducir la ontologa a Ontolingua.
Tanto el mtodo aqu presentado, como el entorno software, se han probado con la
construccin de 13 ontologas, en el proyecto europeo IST-1999-10589 MKBEEM, la iniciativa
13
(KA)^, el proyecto multidicisplinar AM9819, y el proyecto METHONTOLOGY, financiado por la

CICYT TIC-980741. Estos proyectos se estn, o se han, llevado a cabo junto con France
Telecom, Sema Group, la Socit Nationale des Chemins de Fer Frangais, la Open University
del Reino Unido, el SWl de la Universidad de msterdam, el AIFB de la Universidad de
Karisrhue, el SMI de la Universidad de Stanford, la Universidad Autnoma de Madrid, etc. Para
desarrollar las ontologas, se han elaborado 8 esquemas de conceptualizacin. Adems, con el
propsito de comprobar la viabilidad de la extensin del mtodo a otras reas distintas a la de
las ontologas, se ha elaborado y se ha probado un esquema de construccin de gratos
heterrquicos propuestos en IDEAL [Gmez Prez et al.; 97], y un esquema de anlisis
mediante el modelo entidad relacin [Chen, 76].
Especificacin de
meta-modelo en
LffiR
Respuesta del
procesamiento del
modelo
Peticin del experto

Documentacin de la
conceptualizacin
Procesamiento
deLBIR
Cdigo Ontolingua
META-MODELOS
EN SQL
ONTOLOGAS EN
SQL
Figura L4. Visin general de ODE
1.4ORGANIZACIN DE LA MEMORIA
Las partes de que consta esta memoria, adems de la bibliografa y los anexos, sern las
siguientes:
2. Estado de la cuestin. Se mostrar la situacin actual en el rea del desarrollo de
ontologas
desde
el
punto
de
vista
metodolgico
(haciendo
hincapi
en
la
conceptualizacin), desde el punto de vista tecnolgico, y desde el punto de vista de los

lenguajes (insistiendo en los aspectos de expresividad).
3. Planteamiento. Se identificarn las principales contribuciones del presente trabajo, se
dar una visin general de la solucin propuesta, y se establecern las hiptesis de
trabajo. Adems, se definir el vocabulario clave que se va a utilizar a lo largo de la
memoria.
14
4. Descripcin detallada de la solucin. Se har una presentacin pormenorizada,

desglosndolo en tareas, de cada paso del mtodo de conceptualizacin flexible y se
presentar ODE, el entorno software que le da soporte tecnolgico al mtodo. Los
apartados de este captulo sern los siguientes:
4.1. Especificacin del esquema de conceptualizacin (paso 1).
4.2. Conceptualizacin del esquema de conceptualizacin (paso 2).
4.3. Formalizacin del esquema de conceptualizacin (paso 3).
4.4. Implementacin del esquema de conceptualizacin (paso 4).
4.5. Conceptualizacin de la ontologa de dominio (paso 5).
4.6. Implementacin de la ontologa de dominio (paso 6).
4.7. El soporte tecnolgico del mtodo de conceptualizacin flexible: ODE.
5. Evaluacin de la solucin. Se expondr cmo se ha llevado a cabo la valoracin de la
solucin alcanzada.
6. Conclusiones.
Se
sintetizar
la
contribucin
de
este
trabajo
dentro
de
la
conceptualizacin de ontologas.
7. Lneas futuras. Donde se expondrn los trabajos que pueden surgir a partir del actual.
15
2.ESTADO DE LA CUESTIN
17
2.1
Captulo 2. Estado de la cuestin
INTRODUCCIN
A la hora de estudiar cualquier rea del conocimiento, es conveniente tener en mente sus
fundamentos bsicos, sus contribuciones metodolgicas y tecnolgicas, las notaciones
utilizadas, y las aplicaciones del rea. De todos estos aspectos, se han incluido los siguientes:
1. Dentro de los fundamentos bsicos, se han presentado los componentes de las
ontologas. A la hora de identificar estos componentes, se tomarn como base los
identificados por Gruber [Gruber, 93], que coinciden en bastante medida con los que
aparecen
en
las
ontologas
codificadas
utilizando
los
lenguajes
clsicos
de
implementacin de ontologas. Este inventario de componentes se utilizar para evaluar

la expresividad de los EE.CC propuestos en este trabajo con respecto a los lenguajes de
implementacin. En lo concerniente al resto de fundamentos bsicos, como por ejemplo,
las clasificaciones de ontologas, no se han presentado porque los aportes de este
trabajo no estn centrados en tales aspectos.
2. Dentro de las contribuciones metodolgicas, se han presentado las metodologas para el
desarrollo de ontologas y sus propuestas para conceptualizar. Se har una descripcin
breve de cada metodologa y de su propuesta de conceptualizacin, y se mostrar la
relacin que tiene la conceptualizacin con otras actividades de la metodologa. Adems,
se obtendrn unas conclusiones parciales de esta seccin donde queden reflejadas las
posibles carencias en el aspecto de la conceptualizacin. Las metodologas presentadas
son: la metodologa de Cyc [Lenat et al.; 90]; la de Uschold y King [Uschold et al.; 95]; la
de Grnigner y Fox [Grninger et al..; 95]; la propuesta por Bernaras y sus colaboradores
[Bernaras et al.; 96]; la metodologa basada en SENSUS [Swartout et al.; 97]; y
METHONTOLOGY [Fernndez et al.; 97], [Gmez Prez, 98a], [Fernndez Lpez et al.;
99]. No se ha incluido una exposicin sobre CommonKADS [Schreiber et al.; 00], porque
los mtodos de resolucin de problemas son considerados en esta metodologa como
ontologas, y es precisamente en los mtodos de resolucin de problemas {Probiem
Solving Methods) donde CommonKADS hace una exposicin detallada sobre cmo
elaborarlos y reutilizarlos. Sin embargo, no se hace tal exposicin para las ontologas
propiamente dichas.
3. Dentro de las contribuciones tecnolgicas, se han presentado los entornos software para
el desarrollo de ontologas: el entorno software utilizado en Cyc [Lenat et al.; 90], [Lenat,
95], el Ontolingua Sefve/-[Farquhar et al.; 96], Ontosaurus [Swartout et al.; 97], WebOnto
[Domingue, 98] y Protege 2000 [Protege, 00]. Se har una breve exposicin de cada
entorno, incluyendo: la forma de representar los conocimientos, los traductores a otros
lenguajes, si permite el desarrollo distribuido de ontologas, y cualquier otra caracterstica
que ayude a evaluar la herramienta. Luego, utilizando una ampliacin del marco de
Duineveld y colegas [Duineveld et al.; 99], se evaluar cada herramienta, lo cual
permitir mostrar, cuando en captulos posteriores se evale ODE, cules son los
Mtodo flexible para la conceptualizacin de ontologas
19
aportes tecnolgicos del presente trabajo.

4. Dentro de las notaciones utilizadas, se han presentado los lenguajes para la
implementacin de antologas. Se mostrar qu componentes de las ontologas permite
modelizar cada lenguaje, para as poder hacer en otros captulos un contraste entre lo
que permiten expresar los EE.CC propuestos en este trabajo, y lo que permiten expresar
los lenguajes de implementacin. Se presentarn los lenguajes clsicos de ontologas,
en concreto, Ontolingua [Farquhar et al.; 96], el lenguaje utilizado en el OKBC [Chaudhri
et al.; 97], OCML [Motta, 99], Flogic [Kifer et al.; 95] y LOOM [MacGregor, 90]. Aunque en
la actualidad tambin son muy utilizados los lenguajes basados en la Web, stos (XML
[Bray et al.; 98], RDF [Lassila et al.; 99], SHOE [Luke et al.; 00], XOL [Karp et al.; 99],
OIL [Horrocks, 00], CMUCKML [Kent, 99]) son menos expresivos [Corcho et al.; 00] que
los enumerados anteriormente. Del estudio tambin se excluir CycL, pues no hay
garantas de hacer un anlisis adecuado debido a que el sistema en que se utiliza no es
de libre distribucin.
No se han incluido las aplicaciones de las ontologas dentro del estado de la cuestin,
porque desde el punto de vista del desarrollo del presente trabajo, la construccin de
aplicaciones no ha sido un fin en s misma, sino un medio de evaluar, indirectamente, a travs
del uso de las ontologas obtenidas, el mtodo y la tecnologa aqu propuestos.
En la Figura 2.1 se muestra el paralelismo entre el estado de la cuestin y los aportes del
trabajo.
ESTADO DE LA
CUESTIN
Componentes de las
ontologas
APORTACIONES
DEL TRABAJO
Estudio de la
expresividad de los
elementos de
conceptualizacin
propuestos
Metodologas para el
desarrollo de
ontologas y sus
propuestas para
conceptu alizar
Mtodo flexible de
coneptualizacin de
ontologas
Entornos software
para el desarrollo de
ontologas
El entorno de
desarrollo ODE para
construir ontologas
en el nivel de
conocimientos
Lenguajes para la
implementacin de
ontologas
Estudio de la
expresividad de los
elementos de
conceptualizacin
propuestos
Figura 2.1. Relacin entre el estado de la cuestin y el desarrollo de este trabajo
20
2.2
COMPONENTES DE LAS ONTOLOGAS
Teniendo en cuenta la clasificacin de Gruber [Gruber, 93], y teniendo en cuenta tambin los
tipos de definiciones que se contemplan en distintos lenguajes de implementacin de
ontologas, los componentes ms relevantes que suelen tener las ontologas son los siguientes:
a. Las clases son colecciones de objetos del dominio. Dentro del rea de las ontologas, a
veces, a las clases se les llama conceptos.
b. Las meta-clases son clases que tienen como instancias otras clases. Por ejemplo, si
persona es, no slo subclase de animal, sino tambin instancia de clase, entonces se
dice que clase es una meta-clase.
c. Las particiones son conjuntos de clases que no tienen instancias comunes. Obsrvese
que aqu el concepto de particin es ligeramente distinto al definido en el campo
matemtico, pues en las particiones de clases en las ontologas no se exige la
exhaustividad.
d. Las clases en la ontologa se organizan normalmente en taxonomas. Algunas de las
relaciones ms utilizadas para construir estas taxonomas son las siguientes:
d.1. Subclase de. Se dice que una clase Ci es subclase de otra Cz si cualquier instancia
de Ci tambin lo es de ^.
d.2. Particin disjunta. Una particin disjunta de una clase es un conjunto de subclases
que forman una particin.
d.3. Particin exhaustiva. Una particin exhaustiva de una clase es un conjunto de
subclases que abarca toda la clase, es decir, que no hay ninguna instancia de la
clase padre que no sea de ninguna de las subclases de la particin.
A veces, este concepto de taxonoma acaba diluyendo el de ontologa [Studer et al.;
98], pues a veces las taxonomas son consideradas como ontologas.
e. Los atributos son propiedades que describen las clases. Puede haber atributos de clase
y atributos de instancia. Los primeros son aquellos que toman valores particulares en las
instancias, mientras que los segundos son aquellos que toman valor en los conceptos,
pues los describen de manera global. Se dice, adems, que un atributo es polimrfico si
tiene una definicin distinta en cada uno de los conceptos en que est definido.
f. Los atributos pueden tener facetas, que son propiedades de los atributos. Entre las
facetas que suelen proporcionar los lenguajes, se encuentran: el valor por defecto, el
tipo, las restricciones de cardinalidad, la documentacin (que permite incluir una
descripcin del atributo en lenguaje natural), y la definicin operacional (que permite
asociar una frmula, una regla, etc. para hallar el valor del atributo).
21
g. Las relaciones representan interacciones entre conceptos del dominio. Se pueden definir
como colecciones de ernas.
h. Las funciones son un caso especial de relaciones en que el n-simo elemento de la
relacin depende de manera unvoca de los n-1 elementos precedentes.
i. Los axiomas se utilizan para las sentencias del modelo que son siempre verdad.
j.
Las instancias se utilizan para modelizar elementos de las clases.
k. Las instancias de relaciones son elementos de las relaciones.

I. Las reglas de produccin siguen la estructura Si <condicin> entonces <accin>, y se
utilizan para expresar heursticas mediante conjuntos de condiciones y acciones, que
pueden ser representadas idependientemente de la forma en la cual sern utilizadas.
m. Procedimientos. Un procedimiento representa un mtodo para obtener un resultado.
2.3 METODOLOGAS
PARA
EL DESARROLLO
DE
ONTOLOGAS
Y
SUS
PROPUESTAS
PARA
CONCEPTUALIZAR
En este apartado se presentar brevemente metodologa de Cyc [Lenat et al.; 90]; la de
Uschold y King [Uschold et al.; 95]; la de Grnigner y Fox [Grninger et al..; 95]; la propuesta
por Bernaras y sus colaboradores [Bernaras et al.; 96]; la metodologa basada en SENSUS
[Swartout et al.; 97]; y METHONTOLOGY [Fernndez et al.; 97], [Gmez Prez, 98a],
[Fernndez Lpez et al.; 99].
2.3.1 CYC
El principal objetivo de los creadores de Cyc es construir una BC enorme con conocimientos de
sentido comn. La BC de Cyc puede ser considerada como una ontologa, pues puede ser til
como sustrato para la construccin de sistemas inteligentes diferentes y tambin como base
para su comunicacin e interaccin. La BC de Cyc est siendo construida llevando a cabo las
siguientes fases [Lenat et al.; 90]:
a. La primera fase propone codificar manualmente los conocimientos explcitos e implcitos
que aparecen en las fuentes de conocimientos sin ayuda de sistemas de aprendizaje y
lenguaje natural.
b. La segunda fase propone la codificacin de conocimientos asistida por herramientas que
utilicen conocimientos ya almacenados en la BC de Cyc. Esta situacin se dar cuando
las herramientas para analizar lenguaje natural y de aprendizaje automtico tengan la
capacidad de procesar grandes cantidades de conocimientos de sentido comn.
c. La tercera fase delega en las herramientas la mayor parte del trabajo. Las personas slo
22
recomendarn las fuentes a leer, y explicarn las partes ms difciles del texto.
Para cada fase, se llevarn a cabo dos tareas:
1. Desarrollo de una ontologa de representacin de conocimientos que contenga las
primitivas de representacin que se van a utilizar (predicados, objetos, funciones, etc.).
2. Representacin del resto de conocimientos utilizando estas primitivas.
Segn esta metodologa, los conocimientos se codifican directamente en el lenguaje de Cyc
(llamado CycL, y que combina marcos con lgica) sin hacer un diseo previo. Por lo tanto, ni
hay conceptualizacin, ni hay diseo, segn la documentacin publicada hasta ahora.
2.3.2 METODOLOGA DE USCHOLD Y KING

Est basada en la experiencia de desarrollo de la Enterprise Ontology, una ontologa para los
procesos de modelizacin de la empresa [Uschold et al.; 95]. Esta metodologa proporciona
unas lneas maestras para desarrollar ontologas. Propone identificar el propsito de la
ontologa, construir la ontologa, evaluarla, y documentarla. A la hora de construir la ontologa,
los pasos a seguir son: adquisicin de conocimientos, codificacin de estos conocimientos, e
integracin, en la nueva ontologa, de ontologas ya construidas.
En lo concerniente a la adquisicin de conocimientos, se propone identificar los conceptos
claves y relaciones en el dominio de inters; producir definiciones en lenguaje natural con texto
no ambiguo y preciso para cada uno de estos conceptos y relaciones; y nombrar estos
conceptos y relaciones. En este paso, los autores identifican tres enfoques posibles en la
estrategia de identificacin de conceptos: de los ms concretos a los ms abstractos, tambin
llamada de abajo arriba {botton-up) o de sntesis, de los ms abstractos a los ms concretos,
es decir, de arriba abajo (top-down) o de anlisis, o de los ms relevantes hacia los ms
abstractos y los ms concretos, conocida como del medio hacia fuera {middie out).
En un artculo posterior al de Grniger y Fox [Grninger et al.; 95], Uschold y Grninger
[Uschold et al.; 96] sostienen que el enfoque de abajo arriba hace que se llegue a un alto nivel
de detalle, por lo que (1) aumenta el esfuerzo total, (2) es difcil determinar los aspectos
comunes entre los conceptos relacionados, y (3) aumenta el riesgo de inconsistencias, lo que
provoca (4) rehacer trabajo y que el esfuerzo sea todava mayor.
Por otra parte, el enfoque de arriba abajo hace que se tenga un mejor control del nivel de
detalle. Sin embargo, empezar desde arriba aumenta el riesgo de elegir e imponer primitivas de
representacin (clases, instancias, relaciones, etc.) de manera arbitraria, lo que puede provocar
que, cuando el desarrollo de la ontologa ya est avanzado, se encuentren inconsistencias, y
haya que rehacer parte del trabajo. Adems, empezar a clasificar desde los conceptos ms
abstractos puede tener como consecuencia que se haga una clasificacin, aunque ntida, poco
compleja, y se obvien as aspectos comunes de los diferentes conceptos.
Mtodoflexiblepara la conceptualizacin de ontologas
23
En lo referente al enfoque del medio hacia fuera, segn los casos de prueba que exponen
Uschold y Grninger, se llega a un equilibrio en control del nivel de detalle, reconocimiento de
los aspectos comunes de los conceptos, y estabilidad del modelo.
En esta metodologa se hace el paso directo de la adquisicin a la codificacin, por lo tanto,
no hay una etapa de conceptualizacin.
2.3.3 METODOLOGA DE GRNINGER Y FOX

Est basada en la experiencia del desarrollo de la ontologa del proyecto TOVE [Grninger et
al.; 95], dentro del dominio de la modelizacin de procesos y actividades de la empresa.
En esencia se trata de construir un modelo lgico de los conocimientos que se desea
especificar con la ontologa. Este modelo no se construye directamente, sino que primero se
hace una descripcin informal de las especificaciones que debe satisfacer la ontologa y luego
se formaliza esta descripcin. Tal y como se muestra en la Figura 2.2, se empieza
determinando los escenarios que motivan la construccin de la ontologa. Posteriormente,
basndose en estos escenarios, se formulan, de manera infonnal, consultas de suficiencia, que
se espera que puedan ser representadas mediante el vocabulario de la ontologa, y que
puedan ser respondidas utilizando tambin dicho vocabulario. Luego, se especifica la
terminologa de la ontologa en un lenguaje formal, normalmente KIF [Genesereth et al.; 92]. A
continuacin, se reformulan formalmente las consultas de suficiencia que se haban expresado
de manera informal anteriormente. Despus, se especifican, mediante lgica de primer orden,
los axiomas y definiciones de los trminos de la ontologa en el lenguaje formal. Y, por ltimo,
se definen las condiciones bajo las cuales las soluciones a las consultas de suficiencia son
completas.
Escenarios
u
o
>
Preguntas
de
suflciencia
informales
>
Consultas de
suciencia
formales
Terminologa
formal
0
O
Como una vinculacin
de problemas de
consistencia con los axiomas
de la ontologa
Identiflcar de la manera
ms intuitiva posible
aplicaciones y soluciones
Identificar consultas:
Respuestas: axiomas
a^..^..
definiciones formales
Cuestiones: terminologa
Teoremas
de
completitud
O
bajo las cuales
o Condiciones
las soluciones de las
o cuestiones son completas
o
Definidos como sentencias de
primer orden que utilizan los
predicados de la ontologa
KIF
ubjetos
Axiomas
formales
_, ^^
Constantes
Atributos
^ Funciones
Relaciones-" '^ Predicados
>
Figura 2.2. Metodologa propuesta por Grninger y Fox [Gmez Prez, 98b]
24
Las consultas de suficiencia se encuentran estratificadas, y mediante operaciones de

composicin y descomposicin es posible utilizar la respuesta de una consulta para responder
a consultas ms generales, de la misma o de otra ontologa. De esta forma, se identifican
conocimientos ya representados para ser reutilizados, y se integran las ontologas.
En esta metodologa, a partir de los conocimientos representados de manera informal, se
identifican las constantes, variables y predicados que se van a utilizar en las frmulas KIF. Por
consiguiente, se puede decir que, a diferencia de las metodologas descritas en los apartados
anteriores, en sta se propone una etapa intermedia entre la adquisicin de conocimientos y la
implementacin. Ahora bien, por ser ste un paso en que se buscan elementos propios de la
formalizacin,
no se puede afirmar
que
la metodologa
proponga
una
etapa
de
conceptualizacin.
2.3.4 EL ENFOQUE DE
COLABORADORES
AMAYA
BERNARAS
SUS
Los trabajos de Bernaras y sus colaboradores se encuadran dentro del proyecto Esprit
KACTUS [KACTUS, 96]. Uno de los objetivos del proyecto KACTUS fue investigar la factibiiidad
de la reutilizacin en sistemas tcnicamente complejos y el papel de las ontologas para
sustentar esta reutilizacin [Schreiber et al.; 95].
Este enfoque de desarrollo de ontologas viene condicionado por el desarrollo de
aplicaciones. As, cada vez que se construye una aplicacin, se construye la ontologa que
representa los conocimientos necesarios para la aplicacin. En caso de que durante el
desarrollo de la aplicacin se decida reutilizar conocimientos de otras aplicaciones, las
ontologas de dichas aplicaciones se modificarn para hacerlas compatibles entre s, y se
incorporarn a la ontologa de la nueva aplicacin (Figura 2.3). Segn los autores, la
interseccin de las ontologas de las aplicaciones reutilizadas es la parte de ambas ontologas
que ms posibilidades tiene de volverse a utilizar en otros sistemas.
Bernaras y colegas consideran, de manera implcita, una etapa de conceptualizacin que se
lleva a cabo de manera similar a la conceptualizacin de cualquier SBC, pues las ontologas
surgen, en esta metodologa, abstrayendo las BB.CC de estos sistemas. No obstante, no se da
ninguna gua de cmo conceptualizar, ni tampoco se da ninguna justificacin ni a favor ni en
contra, slo se obtienen algunas conclusiones sobre la modelizacin, en general, a partir de la
experiencia de los autores. Por ejemplo, se identifica la oposicin entre el concepto de
usabilidad y de reusabilidad, puesto que las ontologas con conocimientos ms abstractos son
ms reutilizables que aquellas que contienen conocimientos ms concretos; pero es necesario
aadirles a las primeras ms conocimientos cuando se usan en las aplicaciones. Esto provoca
que, cuando se modifica la ontologa de una aplicacin para incorporarla en otra aplicacin, la
medida en que se generalicen sus conocimientos ser causa directa de la medida de su
utilidad y de su reusabilidad.
25
Reutilizacin de
las aplicaciones
AyB
Ontologa
construida
parala
aplicacin A
Interseccin
entre
dos
ontologas
Ontologa
construida
para la
aplicacin B
No se puede
reutilizar ninguna
ontologa
Ontologa
construida
partiendo
de cero
Figura 2.3. Ontologa resultante en el diseo preliminar en la metodologa de Remaras y sus

colaboradores (inspirada en una figura de los mismos autores [Bernaras et al.; 96])
2.3.5 LA METODOLOGA BASADA EN SENSUS

Est basada en la utilizacin de SENSUS, una ontologa que est siendo desarrollada en el
grupo de lenguaje natural del Information Sciences Institute (ISI) de la Universidad del Sur de
California para proporcionar una estructura conceptual amplia para el desarrollo de traductores
automticos [Knight et al.; 94] [Knight et al.; 95]. Su contenido actual se ha obtenido extrayendo
y mezclando informacin de diversas fuentes electrnicas de conocimientos: el modelo de alto
nivel de PENMAN [Bateman et al.; 89]; WordNet [Miller, 90]; diccionarios de ingls, de espaol
y de japons; etc.
SENSUS tiene 50.000 conceptos organizados en forma jerrquica segn su grado de
abstraccin. Incluye tanto trminos de alto nivel de abstraccin como de nivel medio, pero,
generalmente, no incluye trminos de dominios especficos. La construccin de una ontologa
en un determinado dominio se lleva a cabo en dos etapas. En la primera, se poda en SENSUS
los trminos que no son relevantes. Para ello, tal y como se muestra en la Figura 2.4, se toman
unos cuantos trminos del dominio como semilla; se enlazan a mano con SENSUS; se incluyen
todos los conceptos que hay en el camino de los trminos semilla a la raz de SENSUS; y,
finalmente, se aaden sub-rboies enteros segn la siguiente heurstica: "si son relevantes
muchos nudos de un sub-rbol, tambin sern relevantes los dems nudos". En la segunda
fase, despus de la poda, se incluyen a mano los trminos relevantes del dominio, segn se
muestra en la Figura 2.5.
26
1. Identificar trminos "semilla"
Z Enlazar amanlos trminos semilla a SENSUS
W"^
<>
3. Incluir los caminos de las semillas a la raz
<Si
^d
^
4. Aadir algunos sub-rboles enteros
TM-mino de SENSUS
Smilla
Camino a la raz
Padre frecuente
Trmino en un sub-rbol
Figura 2.4. Poda en la metodologa de SENSUS [Swartout et al.; 97]
Ontologa de alcance amplio (ms de 50.000 conceptos)

SENSUS
Ontologa de
un dominio
particular,
por ejemplo,
campaas
militares
areas
Ontologa de otro
dominio particular, por
ejemplo, planificacin
de transporte
Figura 2.5. Enlace de trminos de dominios concretos a SENSUS (adaptado de [Swartout et al; 97])
En esta metodologa no hay una propuesta tan siquiera de diseo de ontologas de dominio.
Se Implementan directamente en el lenguaje seleccionado una vez que se ha obtenido el
esqueleto de la ontologa de domino mediante la poda.
2,3.6 METHONTOLOGY
Esta metodologa ha sido elaborada en el LIA. El marco de referencia [Fernndez et al.; 97],
27
[Gmez Prez, 98a] de METHONTOLOGY permite la construccin de ontologas de manera

independiente de la aplicacin en que se vayan a utilizar. Se identifica: el proceso de desarrollo
de la ontologa (adaptado de [IEEE, 96]), un ciclo de vida basado en prototipos evolutivos, y
tcnicas concretas para llevar a cabo cada actividad. La Figura 2.6 muestra las actividades
propuestas por METHONTOLOGY segn el momento en que se llevan a cabo. El grosor de las
flechas indica la progresin del peso de la actividad a lo largo de la vida de la ontologa. Las
actividades propuestas estn organizadas en varios grupos. Por una parte, se identifican las
actividades de gestin, como por ejemplo la planificacin y el control. Por otra parte, se
encuentran las actividades de desarrollo, en que se proponen dos etapas intermedias entre la
especificacin y la implementacin, concretamente, la conceptualizacin, que se lleva a cabo
en el nivel de conocimientos de Newell [Newell,82], y la formalizacin, que transforma el
modelo obtenido durante la conceptualizacin en un modelo formalizado en alguno de los
siguientes paradigmas: marcos, lgica de predicados de primer orden, lgicas descriptivas, etc.
Por ltimo, se identifican actividades de soporte, por ejemplo, la adquisicin de conocimientos,
la integracin, o la administracin de la configuracin.
METHONTOLOGY ha adoptado como mtodo de conceptualizacin el esquema de
referencia propuesto en el presente trabajo.
Actividades de gestin
Control
Planificacin
05
Especifcacin
:1.
Garanta de calidad
Actividades de desarrollo
>
Conceptualizacin ' - Formalizacin
Implementacin -
Mantenimiento
Actividades de soporte
Adquisicin de conocimientos
Integracin
Evaluacin
Uocumentacion
Administracin de la configuracin
Figura 2.6. Actividades propuestas en METHONTOLOGY (adaptado de Fernndez et al.; 97])
28
2.3.7 CONCLUSIONES, ORIENTADAS A LA CONCEPTUALIZACIN,

SOBRE LAS METODOLOGAS
En la Tabla 2.1 se muestra un resumen de las propuestas, u omisiones, de las distintas
metodologas sobre la etapa de conceptualizacin. Las conclusiones a las que se llega son las
siguientes:
Metodologa
Propuesta de una etapa intermedia entre la adquisicin y

la implementacin
No
No
S
Cyc
Uschold y King
Grninger y Fox
fBrnaras%tâli- i""'"'ir **&;'""' ',.::"""'tf^~"
mtmti^mmmf
.;
SENSUS
- '"jig^"':.^!
""'''""'"'
[>'"" "j"
Propuesta de una etapa de

conceptualizacin
No
No
No
'.;'"
..'
No
No
Tabla 2.1. Propuestas segn las metodologas sobre la conceptualizacin
1. Slo dos metodologas proponen
una etapa de modelizacin
conceptual
independiente de la tecnologa. Dado que las ontologas contienen conocimientos, y

dado que estos conocimientos tienen que ser legibles por una mquina (apartado 2.2),
surge de manera natural una descomposicin del proceso de modelizacin de ontologas
en dos etapas: una en el nivel de conocimientos, independiente de la tecnologa, y otra
en el nivel simblico. Ahora bien, slo METHONTOLOGY y la metodologa de Bernaras y
colegas proponen una etapa de modelizacin independiente de la tecnologa.
2. No todas las metodologas que incluyen una etapa de conceptualizacin la
especifican con el mismo detalle. Al igual que ocurre con las dems etapas, hay una
diferencia en el grado de detalle de la exposicin del mtodo de conceptualizacin muy a
favor de METHONTOLOGY con respecto a Bernaras y colegas. De hecho,
METHONTOLOGY ha tomado prestado, como esquema de conceptualizacin, el
esquema de referencia elaborado en el presente trabajo.
3. El hecho de que una determinada
metodologa
proponga
una etapa de
conceptualizacin no va necesariamente asociado a un grado mayor de madurez

de la metodologa. La metodologa de Bernaras y colegas no est ms madura que la
de Grninger y Fox. Pues la primera no hace mencin al orden en que se han de realizar
las distintas actividades, mientras que la de Grninger y Fox se establece en qu orden
se llevan a cabo las actividades de desarrollo. Adems, la metodologa de Grninger y
Fox detalla ms la manera de llevar a cabo cada actividad.
5. Slo las metodologas de Grninger y Fox, la de Bernaras y sus colaboradores, y
METHONTOLOGY,
proponen una etapa de diseo. En las que no existe tal
propuesta, el salto de la adquisicin a la implementacin es todava ms brusco.

6. Las metodologas que dan guas para conceptualizar y formalizar tienen modelos
29
de conocimientos rgidos. No permiten adaptar los mecanismos de modelizacin a

distintas situaciones. sta es una circunstancia que se da tanto en la conceptualizacin
como en la formalizacin. Por ejemplo, hasta ahora, no se ha dado ningn consejo en
METHONTOLOGY sobre cmo crear un nuevo conjunto de RR.II para la construccin de
una nueva ontologa con sus necesidades de modelizacin particulares.
Adems de las conclusiones vinculadas de manera directa con la conceptualizacin,
tambin es importante decir que, segn el estudio antes mencionado de Fernndez Lpez
[Fernndez Lpez, 99a], ninguna metodologa ha alcanzado un grado pleno de madurez.
2.4 ENTORNOS SOFTWARE PARA EL DESARROLLO DE

ONTOLOGAS
Como se ha visto en el apartado anterior, todava no hay metodologas del todo maduras que
sirvan como gua durante todo el ciclo de vida de las ortologas. Tampoco hay entornos
software capaces de dar soporte tecnolgico a todo el proceso de desarrollo, sino slo a
algunas de sus actividades, por lo general, todas ellas en el nivel de la implementacin. Es
ms, la mayora de los entornos software no permiten la construccin de ortologas en el nivel
de conocimientos.
En el presente apartado se describirn brevemente los entornos ms utilizados, en
concreto, el entorno software utilizado en el proyecto Cyc [Lenat et al.; 90], [Lenat, 95], el
Ontolingua Server [Farquhar et al.; 96], Ontosaurus [Swartout et al.; 97], WebOnto [Domingue,
98] y Protege 2000 [Protege, 00]. Luego, se presentar la evaluacin de estos entornos y las
conclusiones del apartado.
2.4.1 CYC
La tecnologa desarrollada en el proyecto Cyc permite construir ortologas a partir de una gran
BC de sentido comn (htp://www.cyc.com), conocida como la ortologa Cyc. Dicha tecnologa
est siendo comercializada por la empresa Cycorp. La ontologa est escrita en el lenguaje
CycL, que es, esencialmente, un lenguaje basado en marcos y en lgica de predicados que no
es estrictamente de primer orden. Tambin se dispone de un motor de inferencias que realiza
deduccin lgica (incluyendo modus ponens y modus tolens) combinada con otros mecanismos
de inferencia (herencia mltiple, clasificacin automtica, etc.). Con el objetivo de mejorar la
inferencia, Cyc restringe los dominios de bsqueda mediante las micro-teoras, que muestran
conocimientos de distintos dominios desde diferentes puntos de vista. Actualmente, el sistema
funciona como un servidor al que se puede acceder a travs de cualquier navegador WWW.
2.4.2 EL ONTOLINGUA SERVER

El Ontolingua Server [Farquhar et al.; 96] es uno de los entornos de desarrollo ms utilizados
hoy en da. Se ha desarrollado en el Knowledge System Laboratory de la Universidad de
30
Stanford. La importancia de este entorno radica no slo en su gran aceptacin, sino tambin en
que ha influido notablemente en el enfoque que se le ha dado al desarrollo de otros servidores,
sobre todo Ontosaurus [Swartout et al.; 97].
El Ontolingua Senêr permite [Farquhar et al.; 96]: edicin y construccin de ontologas en
Ontolingua desde cualquier navegador Web {http://www-ksl-svc.stanford.edu:5915 o http.V/kslservices-lia.dia.fi.upm.es:5915); anlisis sintctico de ontologas; traduccin a otros lenguajes,
por ejemplo, Loom [MacGregor, 90], Epikit, IDL de CORBA [Mowbray et al.; 95], PROLOG,
CLIPS y KIF puro; acceso a una biblioteca de ontologas; desarrollo cooperativo y distribuido de
ontologas, aunque con algunos inconvenientes, por ejemplo, no hay notificacin de cambios,
es decir, no se sabe cul de los usuarios ha hecho cada modificacin; posibilidad de acceso a
fas ontologas a travs de las aplicaciones remotas mediante el protocolo OKBC [Chaudri et al.;
97] {Open Knowledge Base Connectivity) {http://www.ai.sri.com/~okbc), basado en el GFP
{Generic Frame Protocol) [Karp et al.; 95]; y ayuda para desarrollar ontologas en el nivel
simblico.
2.4.3 ONTOSAURUS
Ha sido desarrollado en el ISI {Information Sciences Institute) inspirndose en el Ontolingua
Serven Ontosaurus [Swartout et al.; 97] es un sen/idor Web {http://sevak.isi.edu:8300/
loom/shuttle.html) [Mallery, 94] al que se puede acceder a travs de cualquier navegador, y que
representa los conocimientos en LOOM [MacGregor, 90]. Permite la traduccin de LOOM a
Ontolingua, KIF y a C++. Al poseer el traductor a Ontolingua, se tiene la posibilidad de traducir
las ontologas a todos los lenguajes del Ontolingua Server Por otra parte, la traduccin a C++
facilita la integracin de las ontologas con otros sistemas, pues es un lenguaje hoy en da muy
extendido. Tambin permite el desarrollo distribuido de ontologas, aunque no es posible en
todo momento saber qu cambios se han producido en las ontologas y quines son los
responsables de estos cambios.
2.4.4 TADZEBAO-WEBONTO
Esta herramienta, desarrollada en el Knowledge Media Institute de la Open Universitiy de
Milton Keynes, permite construir ontologas utilizado el lenguaje OCML {Operational
Conceptual Modelling Language) [Motta, 98], que est inspirado en Ontolingua. En lo que al
motor de inferencias se refiere, permite: comprobar las restricciones en las cardinalidades de
las relaciones, encadenamiento de reglas hacia delante y hacia atrs, bsqueda en
profundidad con y sin vuelta atrs, herencia, etc. El sistema, al igual que los hasta ahora
descritos, consta de un servidor al que es posible conectarse a travs de un navegador WWW
{http.//webonto.open.uc.uk}; sin embargo, al contrario de lo que ocurre en Ontolingua y en
Ontosaurus, la puesta en marcha del cliente suele durar bastante tiempo; pero las operaciones
que se realizan sobre las ontologas son muy rpidas. En este entorno, se facilita que los
usuarios puedan discutir sobre las ontologas sin tener que estar fsicamente juntos.
31
2.4.5 PROTEGE 2000

Este sistema, de libre distribucin y tambin funciona en la Web, ha sido desarrollado en el
Grupo de Informtica Mdica de la Universidad de Stanford. La representacin de
conocimientos la lleva a cabo utilizando clases, instancias, ranuras de clase y de instancia, y
facetas [Protege, 00]. Adems, permite meta-ciases; da la posibilidad de hacer generacin
automtica de formularios para introducir instancias utilizando la definicin que se haya hecho
de las clases; es compatible con OKBC [Chaudri et al.; 97]; y permite representar
conocimientos en RDF [Lassila et al, 99].
2.4.6 EVALUACIN D E L O S E N T O R N O S S O F T W A R E PARA EL

D E S A R R O L L O DE ONTOLOGAS
Para llevar a cabo la evaluacin de los entornos software antes citados, se van a tomar como
referencia, haciendo algunas ampliaciones, las caractersticas propuestas en [Duineveld et al.;
99], que son las siguientes:
1. Caractersticas generales. Son aquellas que se pueden aplicar a cualquier entorno
software, sea o no para el desarrollo de ontologas. Estas caractersticas pueden ser:
a)
Claridad de la interfaz de usuario. Se refieren a si se ha tenido en cuenta si las

opciones se presentan de una forma ordenada y en el momento ms adecuado.
b)
Consistencia de la interfaz de usuario. Es decir, se evala si el sistema tiene errores

debidos a la interfaz.
c)
Velocidad de actualizacin. Se trata de estimar si se tarda mucho o poco tiempo en

insertar nuevos datos.
d)
Calidad de la visin general que se tiene de la antologa. Se evala si en cada

momento el usuario tiene una perspectiva global de la ontologa que est
construyendo.
e)
La claridad del significado de las instrucciones que se le envan al sistema. Aqu se

considera, por ejemplo, si cada vez que se elige una opcin, el sistema realiza la
funcin que cabra esperar por el nombre que recibe la opcin.
f)
La claridad a la hora de mostrar los cambios hechios en la ontologa. En este punto

se tiene en cuenta, por ejemplo, si es fcil ver los cambios que se han hecho sobre
la ontologa que se est desarrollando.
g)
Si el sistema se puede instalar en red*. Se considera si el entorno software puede

instalarse en red o si, por el contrario, se tiene que instalar en modo local.
1
Duineveld y colegas [Duinieveld et al.; 99] identifican la caracterstica inversa, es decir, instalacin
local; sin embargo, en esta tesis se prefiere evaluar la instalacin del entorno en red.
32
h)
Interconexin con otros sistemas (caracterstica no identificada por Duineveld y

colegas). Se considera si hay protocolos (por ejemplo OKBC) adecuados para
intercambiar informacin con otros sistemas.
i)
Estabilidad del sistema. Se tiene en cuenta si el sistema es robusto o, si por el

contrario, falla con mucha frecuencia.
j)
La calidad del sistema de ayuda. Para esta caracterstica se evala en qu media la

ayuda facilita la utilizacin del entorno software.
2. Caractersticas vinculadas directamente con el desarrollo de antologas. Se tiene en

cuenta:
a)
Herencia mltiple. Se tiene en cuenta si permite, o no, este tipo de herencia en el

entorno software.
b)
Descomposicin con distintas variantes. En este punto se considera, por ejemplo, si

el software permite la descomposicin de clases en otras que no comparten
instancias entre s (descomposicin disjunta), o en otras que, adems de ser
disjuntas,
contienen
todas
las
instancias
de
la
clase
descomponer
(descomposicin exhaustiva).
c)
Verificacin de la consistencia. Se hacen dos consideraciones:

c.1)
Si se hace verificacin de que los nuevos conocimientos son consistentes

con los anteriores.
C.2)
El nivel en que se verifica la consistencia. Es decir, si se hace verificacin

de tipos, de la consistencia con las definiciones de descomposiciones
disjuntas, etc.
d)
Modelizacin en el nivel de conocimientos (caracterstica no identificada por

Duineveld y colegas). Se considera si se utiliza una notacin independiente de la
tecnologa en que se implementa la ontologa.
e)
Mecanismos de modelizacin variables (caracterstica no identificada por Duineveld

y colegas). Se tiene en cuenta si es posible cambiar el esquema de modelizacin
dependiendo de las necesidades de modelizacin de cada ontologa.
f)
Ontologas de ejemplo. Se estima si las ontologas que tiene el sistema a modo de

ejemplo son suficientes para ayudarle al usuario a construir nuevas ontologas.
g)
Biblioteca de ontologas para ser reutilizadas. En este punto se estima en qu

medida la biblioteca de ontologas del entorno software puede ayudar a la
reutiiizacin de otras ontologas.
33
h)
Inventario de primitivas de representacin. Se considera si hay, o no, suficientes

primitivas de representacin.
i)
Ayuda sobre antologas. Esta caracterstica, ms que tener en cuenta la ayuda

sobre el entorno software en s, tiene en cuenta la ayuda sobre cmo se construyen
las ortologas, aparte de si se utiliza, o no, el software.
3. Caractersticas sobre el trabajo en cooperacin. Dado que uno los aspectos esenciales
de las ontologas es el consenso, es importante tener en cuenta el trabajo en
cooperacin. Dentro de las caractersticas sobre esta faceta, se encuentran:
a)
Actualizacin sincronizada. Se considera si el entorno software permite la edicin

simultnea de la ontologa por parte de distintos usuarios.
b)
Mecanismos de bloque. Esta caracterstica est vinculada con las posibilidades

que da el entorno software para evitar operaciones simultneas sobre la ontologa
que sean incompatibles, por ejemplo, que dos usuarios modifiquen el mismo dato.
c)
Posibilidades de presentar ontologas que estn bloqueadas. Se tiene en cuenta

bajo qu circunstancias puede ver un usuario el contenido de una ontologa que
est bloqueada.
d)
Visin de los cambios que hacen otros usuarios. Esta caracterstica concierne a la
manera en que cada usuario ve los cambios que llevan a cabo los dems usuarios.
e)
Posibilidades de exportar ontologas. Se considera a qu formatos se pueden

exportar las ontologas.
f)
Posibilidades de importar ontologas. Se considera en qu formatos tienen que estar

las ontologas para poder ser importadas por el entorno software.
La Tabla 2.2 presenta la evaluacin para los entornos software de los apartados anteriores
(salvo Cyc, que no es de libre distribucin). A la hora de rellenar la tabla, se utiliza el smbolo +
para significar el valor "bueno", O para el valor "razonable", y - para el valor "malo" {no good); y,
para ciertas caractersticas, tambin se utilizan los valores s o no. Cuando no se sabe algn
valor, se pone una interrogacin cerrada (?).
34
(*) Analizados en [Duineveld et al.; 99]
Ontolingua
Ontosaurus
(*)
WebOnto
Protege 2000
(*)
CARACTERSTICAS GENERALES
Claridad de la interfaz de usuario
Consistencia de la interfaz de usuario
Velocidad de actualizacin
Visin general de la ontologa
Claridad de las instrucciones al sistema
Identificacin de los cambios
Estabilidad del sistema
Instalacin en red
Inerconexin con otros sistemas
Ayuda del sistema
CARACTERSTICAS VINCULADAS DIRECTAMENTE CON EL DESARROLLO DE

ONTOLOGAS
Herencia mltiple
No
Descomposicin con distintas variantes
Verificacin de la consistencia
- Existencia de la verificacin
- Nivel de verificacin
Modelizacin en el nivel de conocimientos
no
no
no
Mecanismos de modelizacin variables
no
no
no
no
Ontologas de ejemplo
Biblioteca para reutilizacin
Inventario de primitivas de representacin
Ayuda sobre ontologas
CARACTERSTICAS SOBRE EL TRABAJO EN COOPERACIN

Actualizacin sincronizada
Mecanismos de bloqueo
Posibilidades de presentar ontologas que

estn bloqueadas
Visin de los cambios que hacen otros

usuarios
Posibilidades de exportar ontologas
S (RDF)
Posibilidades de importar ontologas
Tabla 2.2. Evaluacin de los entornos software de desarrollo de ontologas segn el marco, aqu
ampliado, publicado por Duineveld y colegas [Duineveld et al.; 99]
35
Algunas de las conclusiones obtenidas en [Duineveld et al.; 99] son (algunas de ellas estn
reflejadas en la tabla): (1) las interfaces de usuario son generalmente fciles de manejar; (2) los
sistemas locales son mucho ms rpidos que los que trabajan en red; (3) no suele haber
buenos mecanismos de ayuda al usuario; (4) a la herencia mltiple se le da un soporte correcto
en todos los entornos; (5) la facilidad con que se crean las descomposiciones disjuntas y
exhaustivas vara de unos entornos a otros; (6) en general, se hace verificacin de muchos
tipos de errores sintcticos, pero de pocos tipos de errores semnticos, por ejemplo, la
comprobacin de que una particin se ajusta a la restriccin de ser disjunta; (7) los entornos
software no suelen incluir ayuda sobre cmo construir ontologas, aparte de qu software se
utilice; y (8) la mayor parte de los entornos no permiten ver las modificaciones que llevan a
cabo los dems usuarios. Esto ltimo dificulta bastante la construccin de ontologas en
cooperacin.
2.4.7 CONCLUSIONES SOBRE LOS ENTORNOS SOFTWARE

De todo lo dicho anteriormente, en la actualidad predominan los servidores que permiten el
acceso a las ontologas a travs de casi cualquier navegador WWW; sin embargo, no suele
ser sencillo el trabajo cooperativo de varios grupos en distintos lugares geogrficos.
Aunque quizs el aspecto ms destacable de lo visto en esta descripcin de entornos
software es el hecho de que, tal y como se ha dicho en la introduccin, ningn entorno abarca
el desarrollo de ontologas durante todo su ciclo vida. Esto es una consecuencia inmediata
de la falta de metodologas maduras: si todava no se ha detallado cmo se ha de proceder en
cada momento del desarrollo de una ontologa, difcilmente se podr dar soporte tecnolgico a
este desarrollo desde que se decide la construccin de la ontologa hasta que sta ya deja de
utilizarse.
Asimismo, las actividades en que los entornos software descritos facilitan el trabajo son,
sobre todo, la implementacin y la integracin con otras ontologas ya construidas. Por tanto, la
mayora de los entornos obligan a trabajar en el nivel simblico [Newell, 82]. As, el
desarrollador tiene que conocer bien el formalismo, bien el lenguaje en que va a implementar la
ontologa. Por ello, los desarrolladores de ontologas que no conocen algunos lenguajes
determinados tienen problemas para implementar ontologas en estos lenguajes [Aguado et al.;
98]. Debido tambin a que se trabaja en el nivel simblico, los modelos conceptuales no son
explcitos.
Al mismo tiempo, los modelos conceptuales son fijos. Es decir son siempre los mismos.
Por ejemplo, en el Ontolingua Server las facetas disponibles para las ranuras son fijas para
todas las ontologas. Consiguientemente, los desarrolladores de ontologas quedan presos de
los patrones de representacin y tienen que utilizar siempre los mismos "ejes de coordenadas"
sean cuales sean los conocimientos a representar y sea cual sea la visin que se tenga del
problema.
36
Adems, al menos en lo que a los entornos software de libre acceso se refiere, en general
poseen interfaces intuitivas y fciles de manejar, pero no permiten el trabajo eficiente. Por
ejemplo, a veces no tienen una secuencia de formularios adecuada para que una parte
importante de la informacin introducida en unos se pueda copiar en otros.
Por otra parte, generalmente, los entornos almacenan las ontologas en ficheros ASCII.
Por lo tanto, puede ser interesante estudiar la posibilidad de otras alternativas de
almacenamiento que eviten problemas de consistencia, redundancia, dependencia del nivel
fsico, etc. y, al mismo tiempo, garanticen el poder de inferencia que tienen los lenguajes que
se utilizan en el desarrollo de ontologas.
2.5 LOS LENGUAJES CLSICOS PARA LA IMPLEMENTACIN

DE ONTOLOGAS
En esta seccin, se describe brevemente y se analiza la expresividad de los lenguajes clsicos
de implementacn de ontologas, concretamente, Ontolingua [Farquhar et al.; 96], el lenguaje
utilizado en el OKBC [Chaudhri et al.; 97], OCML [Motta, 99], Flogic [Kifer et al.; 95] y LOOM
[MacGregor, 90]. Este estudio servir en captulos posteriores para comprobar que, utilizando
el mtodo de conceptualizacin propuesto en el presente trabajo, se pueden modelizar los
mismos componentes que hay en la unin de la parte esttica de los lenguajes clsicos de
implementacin de ontologas.
2.5.1 ONTOLINGUA^
Ontolingua es un lenguaje basado en KIF y en la Frame Ontology. Es el lenguaje para la
construccin de ontologas que utiliza el Ontolingua Server.
KIF [Genesereth et al.; 92] {Knowledge Interchange Formaf) s una versin prefija del
clculo de predicados de primer orden, con extensiones para mejorar su expresividad como:
definicin de trminos, representacin de meta-conocimientos, definicin de funciones y
relaciones, especificacin de conjuntos, y razonamiento no montono. Algunos de los tipos de
objetos primitivos son los conjuntos, las listas, las relaciones y las funciones.
La Frame Ontology [Gruber, 93] es una ontologa escrita en KIF 3.0 donde se expresan a
travs de relaciones de segundo orden los conocimientos y las convenciones usadas al
representar conocimientos utilizando el formalismo de marcos. Proporciona definiciones
formales sobre las primitivas de representacin ms usadas en dicho formalismo como son:
subclase-de {subclass-of), particiones de clases {subclass-partition), meta-clases, etc. Como
estos trminos se pueden utilizar para hacer otras ontologas, la Frame Ontology es una
ontologa de representacin de conocimientos.
Ein el anexo I se hace una descripcin ms detallada de Ontolingua, por ser el lenguaje seleccionado para
implementar ontologas con ODE.
37
El lenguaje Ontolingua permite construir ontologas siguiendo cualquiera de las siguientes

vas: (1) solamente utilizando expresiones KIF; (2) utilizando nicamente el vocabulario de la
Frame Ontology (esto slo es posible si no se van a representar axiomas); y (3) utilizando a la
vez KIF y la Frame Ontology.
2.5.2 EL LENGUAJE UTILIZADO EN EL OKBC

OKBC [Chaudhri et al, 97] {Open Knowledge Base Connectivity) {http://www.ai.sri.com/~okbc),
conocido anteriormente como Generic Frame Protocol (GFP) versin 2.0 [Karp et al, 95],
especifica un protocolo que permite acceder a ontologas a travs de servidores OKBC. Cada
servidor OKBC est especializado en un lenguaje diferente, de tal manera que si se utiliza, por
ejemplo, un servidor OKBC de Ontolingua, ste podr manipular directamente ontologas en
Ontolingua de acuerdo con los mensajes intercambiados con las aplicaciones. Este protocolo
est fundamentado en el formalismo basado en marcos. En consecuencia, representa los
conocimientos utilizando: marcos, ranuras (atributos), facetas (propiedades de los atributos),
etc. El significado de estas primitivas es equivalente al de otras utilizadas en Ontolingua. De
hecho, en la actualidad, la Frame Ontology incluye a otra, llamada OKBC Ontology, que
modeliza en KIF las primitivas del protocolo OKBC.
Las diferencias ms significativas entre la formalizacin con OKBC y con Ontolingua son las
siguientes: las taxonomas en OKBC son ms simples que las de Ontolingua, pues con OKBC
slo se puede utilizar la relacin subclase directa de, no se utiliza la relacin subclase en una
particin disjunta, ni subclase en una particin exhaustiva; las relaciones y las funciones se
definen mediante marcos, dado que pueden considerarse tambin como entidades del universo
del discurso; sin embargo, tiene la ventaja dar la posibilidad de crear jerarquas de relaciones; y
el compromiso sobre los axiomas es menos estricto que el de Ontolingua, pues no exige que
se utilice KIF.
2.5.3 OCML
OCML [Motta, 99], el lenguaje utilizado por el entorno Tadzebao-WebOnto [Domingue, 98],
permite representar relaciones, funciones, reglas, clases, instancias y procedimientos. La
sintaxis utilizada es casi igual que la de Ontolingua, aunque Tadzebao-WebOnto tiene motor de
inferencias.
Para representar las taxonomas, en OCML slo se dispone de la primitiva bsica subclase
de. Sin embargo, de una manera indirecta, se podran definir las primitivas correspondientes a
las particiones. Ahora bien, no es posible incluir caractersticas de razonamiento que
aprovechen estas definiciones, pues habra que definir axiomas de segundo orden, para que
los que no se puede hacer deduccin con el motor de inferencias de Tadzebao-WebOnto.
Adems de las primitivas de representacin para construir ontologas, OCML da la
posibilidad de modelizar tareas y mtodos para utilizarlos en mtodos de resolucin de
38
problemas [Schreiber et al.; 00], [Benjamins et al.; 96].
2.5.4 FLOGIC
IFLogic [Kifer et al, 95] {Frame Logic) no es un lenguaje creado expresamente para la
especificacin de ontologas, sino que inicialmente se cre como una aproximacin a la
orientacin a objetos desde la perspectiva de la lgica, especialmente aplicado a las bases de
datos orientadas a objetos y a la vez deductivas. Posteriormente fue utilizado en el campo de la
Inteligencia Artificial en general, y en el rea de los lenguajes basados en marcos y de las
ontologas en particular.
Presenta al mismo tiempo la mayora de los aspectos estructurales de los lenguajes
orientados a objetos y de los lenguajes basados en marcos, concretamente, algunas de sus
caractersticas principales son: la creacin de objetos complejos, herencia, tipos polimrficos y
encapsulacin.
Permite definir conceptos, taxonomas, atributos y axiomas, que se representan con una
sintaxis mixta de lgica de predicados de primer orden y orientacin a objetos. Las particiones
se deben especificar a travs de axiomas. En lo referente a las relaciones, no son elementos
bsicos del lenguaje. Esto es paradjico debido a que tiene la lgica de primer orden como uno
de sus orgenes. Ahora bien, se pueden modelizar relaciones, al igual que ocurre con OKBC,
utilizando marcos. Por otra parte, las funciones se pueden crear bien utilizando marcos, bien
utilizando mtodos para las clases, que los proporciona el lenguaje. En este caso, los mtodos
tienen el mismo sentido que en la programacin orientada a objetos, es decir, especifican los
mecanismos de paso de mensajes entre objetos.
2.5.5 LOOM
LOOM [MacGregor, 90] est basado en el sistema de representacin de conocimientos KLONE [Brachman et al.; 85] y es, por tanto, un lenguaje de lgica descriptiva. LOOM no fue
originalmente creado para la especificacin de ontologas; sin embargo, sus caractersticas
para la representacin de conocimientos han sido aprovechadas para tal fin.
Se trata, de un lenguaje expresivo para la especificacin declarativa de modelos basada en
la clasificacin, junto con un lenguaje de consultas que permite aprovechar todas las
caractersticas de la lgica de primer orden. A su vez, el lenguaje de modelizacin est
compuesto por dos lenguajes: un lenguaje de definicin (basado en marcos) y otro de asercin
(basado en la lgica de primer orden). El lenguaje de definicin es el que permite definir
explcitamente: conceptos, particiones (tanto disjuntas como exhaustivas), relaciones, axiomas,
instancias de relaciones, procedimientos y reglas. Las funciones pueden ser entendidas en
este lenguaje como un caso especial de relaciones.
39
2.5.6
SNTESIS
SOBRE LA EXPRESIVIDAD DE LOS LENGUAJES
La Tabla 2.3, basada en el estudio de Corcho y Gmez Prez [Corcho et al.; 00], muestra qu
Ontolingua
OKBC
OCML
Flogic
LOOM
CONCEPTOS (clases)
Particiones
Meta-clases
TAXONOMAS
Subclase de
Subclase en una
particin
disjunta
+/-
+/-
Subclase en una
particin
exhaustiva
+/-
+/-
ATRIBUTOS
Atributos
instancia
de
Atributos
clase
de
Polimorfismo
FACETAS
Valor
defecto
por
Tipo
Restricciones de
cardinalidad
Definicin
operacional
+/-
+/-
Relaciones
+/-
+/-
+/-
+/-
RELACIONES
FUNCIONES
Funciones
+/AXIOMAS
Axiomas
+/INSTANCIAS
Instancias
INSTANCIAS DE RELACIONES
Instancias
relaciones
de
+/REGLAS
Reglas
produccin
de
PROCEDIMIENTOS
Procedimientos
Tabla 2.3. Expresividad de los lenguajes clsicos de implementacin de ontologas (basada en [Corcho et
al.; 00]
40
componentes de las ontologas define cada lenguaje. El smbolo "+" significa que un lenguaje
puede representar explcitamente un determinado tipo de componente de una ontologa, los
smbolos "+/-", que puede representarlo, aunque no de manera explcita, y el smbolo "-", que
no puede representarlo ni explcita ni implcitamente.
Se puede comprobar que todos ellos definen conceptos, atributos, axiomas e instancias. Sin
embargo, no todos permiten crear relaciones de manera explcita, y algunos de ellos no
permiten la creacin, al menos de manera explcita, de particiones. La mayora de los lenguajes
no dan la posibilidad de utilizar reglas ni procedimientos.
Tambin es importante tener en cuenta que la sintaxis de estos lenguajes no puede
cambiarse, por tanto, no dan la posibilidad de que cada usuario pueda adaptarlos segn las
necesidades de representacin de cada ontologa. Por ejemplo, FLogic no puede ser adaptado,
sin cambiar la definicin misma del lenguaje, para que se puedan especificar relaciones de
manera explcita.
2.6
CONCLUSIONES SOBRE EL ESTADO DE LA CUESTIN
Ein este captulo de estado de la cuestin se han identificado los componentes de las
ontologas para as poder estudiar la expresividad de los lenguajes analizados posteriormente,
y de los EE.CC que se van a proponer en captulos posteriores; a continuacin, se ha hecho
una breve exposicin sobre las metodologas para el desarrollo de ontologas; luego, se ha
hecho una descripcin y un anlisis de los entornos de desarrollo de ontologas; y la ltima
seccin ha estado dedicada a los lenguajes de implementacin de ontologas, haciendo el
anlisis de lenguajes fundamentalmente desde el punto de vista de la expresividad.
Por una parte, se ha pretendido que el estado de la cuestin ayude a comprender en
captulos posteriores cules son los aportes metodolgicos y tecnolgicos de este trabajo. Por
otra parte, este captulo proporciona una sntesis de lenguajes de implementacin
que
permitir comprobar, tambin en captulos posteriores, que, siguiendo el mtodo de

conceptualizacin propuesto en el presente trabajo, se pueden modelizar los mismos
componentes que hay en la unin de la parte esttica de los lenguajes clsicos de
implementacin de ontologas.
Entre las conclusiones ms relevantes que se pueden obtener del estado de la cuestin, se
encuentran, al menos, son las que se presentan a continuacin:
a. Sobre las metodologas de desarrollo de ontologas, se puede afirmar que las
metodologas actuales se encuentran todava en un estado de inmadurez, por tanto, no
se puede decir en el da de hoy que el rea de desarrollo de ontologas haya alcanzado
el estado adulto. As, no resulta sorprendente que haya una falta de propuestas de una
etapa de concepualizacin. Esto provoca ciertos problemas. Uno de los ms importantes
es que, para desarrollar y entender las ontologas, es necesario conocer sus lenguajes
41
de implementacin. Asimismo, hasta el desarrollo del presente trabajo, no haba

propuestas de conceptualizacin flexible, a la medida, computable utilizando esquemas
de conceptualizacin definidos de manera explcita y declarativa. Adems, hasta el
desarrollo del presente trabajo, las metodologas no daban guas sobre cmo elaborar
modelos conceptuales computables.
b. Sobre los entornos de desarrollo de ontologas, se puede sostener que no existen
entornos software que den soporte tecnolgico a lo largo de todo el ciclo de vida de
desarrollo de ontologas. En general, estos entornos se centran fundamentalmente en la
implementacin de ontologas. Adems, los esquemas de modelizacin utilizados son
fijos y predeterminados, y estn embebidos en el programa. En lo referente al
almacenamiento, las ontologas se guardan en ficheros ASCII.
c. Sobre los lenguajes clsicos de implementacin de ontologas, hay que decir que todos
ellos permiten definir conceptos (clases), atributos, axiomas e instancias, mientras que
slo algunos de ellos dan la posibilidad de definir relaciones de manera explcita.
Tampoco todos los lenguajes permiten definir reglas y procedimientos.
Para eliminar las lagunas tecnolgicas y, o, carencias de conocimientos anteriormente
expuestas, se puede trabajar en las siguientes lneas:
1. Refinamiento de las metodologas actuales, o creacin de otras nuevas que abarquen
todo el ciclo de vida de desarrollo de ontologas, y que propongan un proceso de
desarrollo, un ciclo de vida, y un conjunto de tcnicas precisos.
2. Propuestas de mtodos de conceptualizacin, en el nivel de conocimientos, flexibles,
a la medida, explcitos y computables utilizando esquemas de conceptualizacin
definidos de manera declarativa.
3. Acompaamiento de los aportes metodolgicos con aportes tecnolgicos que le
den soporte. Adems, es conveniente almacenar las ontologas utilizando una
tecnologa, como son las bases de datos relacinales, que minimice la redundancia de
los datos, sea fcil garantizar la integridad de los datos, garantice la independencia con
respecto al nivel fsico, etc.
4. Paso automtico y directo de la conceptualizacin a la implementacin. Por una parte, el
hacer
modelos
conceptuales
computables
conlleva
el
hacer
propuestas
metodolgicas para que la conceptualizacin tenga las propiedades adecuadas como

para ser traducida a la implementacin. Por otra parte, esta aportacin conlleva el
desarrollo de un software para que esta transformacin est automatizada.
Tal y como se ver en los siguientes captulos, el presente trabajo esta centrado en los
puntos 2, 3 y 4. En la Figura 2.7 se resumen las lagunas metodolgicas y tecnolgicas a las
cuales se pretende dar una solucin.
42
PLANO METODOLGICO
Falta de propuestas de una etapa de conceptualizacin
No se construyen modelos conceptuales computables
Esquemas de modelizacin:
a) fijos y predeterminados
b) no explcitos
c) no declarativos
d) no computables
PLANO TECNOLGICO
Las ontologas se codifican direc lamente en un lenguaj de implementacin
No se utilizan modelos conceptuales computables
Los esquemas de representacin son fijos y predeterminados
y estn embebidos en el programa
Las ontologas se guardan en ficheros ASCII
Figura 2.7. Lagunas detectadadas entanto en el plano metodolgico como en el tecnolgico
43
3. PLANTEAMIENTO
45
3.1
Captulo 3. Planteamiento
INTRODUCCIN
Una vez que se ha expuesto cul es la situacin actual del desarrollo de ontologas tanto desde
el punto de vista metodolgico, como desde el punto de vista tecnolgico, se presentarn en
este captulo los aportes metodolgicos y tecnolgicos que luego se desarrollarn en el
captulo 4; tambin se presentar el vocabulario bsico utilizado, y las suposiciones bajo las
cuales se ha elaborado la solucin propuesta.
3.2
VOCABULARIO
A continuacin se presenta el vocabulario bsico de la memoria:

1. Modelo conceptual. Modeliza el dominio de una ontologa concreta de manera
independiente de la tecnologa que se vaya a utilizar en su implementacin.
2. Conceptualizacin. Se asume la definicin que aparece en [Gmez Prez et al.; 97]. Es
decir, se supone que conceptualizacin es la transformacin de la necesidad, en el
dominio de la aplicacin, en un modelo conceptual que describe el producto software que
responde a dicha necesidad. En determinadas ocasiones tambin se
llamar
conceptualizacin al modelo conceptual.

3. Elemento de conceptualizacin (EC). Cualquier instrumento de modelizacin que se
utilice para elaborar el modelo conceptual.
4. Esquema de conceptualizacin. Es la descripcin de la manera de conceptualizar
ontologas concretas. En esta descripcin se establece qu EE.CC se utilizan, qu reglas
de verificacin de la consistencia entre estos elementos hay que comprobar, y en qu
orden hay que ir utilizando los EE.CC.
5. Esquema de conceptualizacin de referencia. Es el esquema de conceptualizacin que
se ha obtenido empricamente aplicando el mtodo presentado en este trabajo en el
desarrollo de distintas ontologas con diferentes necesidades de modelizacin. Este
esquema, tal y como se mostrar en el captulo 6, puede modelizar los mismos
componentes que se utilizan en los lenguajes clsicos de implementacin de ontologas
para conocimientos estticos.
6. Meta-modelo. Modelo que describe un esquema de conceptualizacin.
7. Meta-modelo conceptual. Modelo resultante de la conceptualizacin de un esquema de
conceptualizacin. En la versin actual del mtodo, los meta-modelos conceptuales se
describen utilizando tablas y gratos.
8. Comit de cambios. Grupo de personas encargadas de controlar y aprobar los cambios
sobre alguno de los componentes que se manipulen durante el desarrollo de las
ontologas (especificaciones, meta-modelos, modelos conceptuales, implementaciones.
47
etc.).
3.3
VISION GENERAL DE LA SOLUCIN PROPUESTA
En el mtodo bi-fase de conceptualizacin flexible que se ha elaborado, se da la posibilidad

de utilizar un esquema de conceptualizacin de referencia (con unas determinadas tablas,
grafos y de reglas de verificacin de la consistencia) que se ha obtenido a partir de la evolucin
de un esquema inicial que se ha ido modificando conforme se desarrollaban ontologas en
distintos dominios y con necesidades de modelizacin diferentes. Sin embargo, como no se
tiene la certeza absoluta de que este esquema de referencia sea completo, es decir, no se
tiene la certeza de que no vayan a surgir nuevas necesidades de modelizacin, en el presente
trabajo se propone que se tenga la posibilidad de modelizar de forma explcita, declarativa y
a la medida el esquema de conceptualizacin que se va a utilizar previo a la
conceptualizacin del dominio de la ontologa. Consiguientemente, se propone llevar a
cabo una especificacin en lenguaje natural y una conceptualizacin (nivel de conocimientos),
una formalizacin y una implementacin (nivel simblico) del esquema de conceptualizacin
que se vaya a utilizar en la construccin de la ontologa (Figura 3.1).
NIVEL DE
CONOCIMIENTOS
NIVEL SIMBLICO
QU HAY QUE
MODELIZAR:
ESQUEMA DE
CONCEPTUALIZACIN
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grafos)
Formalizacin
(utilizando
LBIR)
Implementacin
{en SQL)
QUE HAY QUE

MODELIZAR:
ONTOLOGAS
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grafos)
Formalizacin
(p.e. marcos)
Implementacin
(p.e. Onlolingua)
Fases de que consta el mtodo de conceptualizacin propuesto en esta tesis
En la especificacin del esquema de conceptualizacin, se debe establecer qu EE.CC

grficos y tabulares se van a utilizar, qu reglas de verificacin de la consistencia entre estos
EE.CC hay que comprobar, y en qu orden se van a utilizar tales elementos.
En la conceptualizacin del esquema de conceptualizacin, se propone la construccin
de un meta-modelo utilizando tablas y grafos. Se debe hacer un modelo conceptual de cmo
hacer un modelo conceptual de una ontologa de dominio. La relacin que existe entre los
modelos conceptuales de ontologas de dominio y los meta-modelos de los esquemas de
conceptualizacin se muestra en la Figura 3.2. Obsrvese que un meta-modelo se puede
48
aplicar a varios modelos conceptuales de ontologas, las cuales pueden ser, o no, del mismo
dominio.
META-MODELO 1 DESCRITO CON

TABLAS Y GRAFOS
Doa
Reglas de verificacin de la
consistencia
Tablas y grafos
^r
QK>*D
Gua en el
orden
1 Rellnese..
2 Rellnese..
MODELOS CONCEPTUALES DE ONTOLOGL4S
MODELO
CONCEPTUAL DE
LA ONTOLOGA 1
MODELO
CONCEPTUAL DE
LA ONTOLOGA 2
MODELO
CONCEPTUAL DE
LA ONTOLOGA n
Figura 3.2. Relacin entre modelos y meta-modelos
Ahora bien, las tablas y los grafos producidos en la elaboracin de un meta-modelo

conceptual no los puede procesar directamente un computador. Por esta razn, se ha definido
el lenguaje LBIR {Language forBuilding Intermedate Representations), un lenguaje formal que,
como se mostrar en la seccin 4.4, tiene la misma expresividad que las tablas y los grafos
utilizados para describir meta-modelos. Se puede decir, por tanto, que despus de hacer una
conceptualizacin del esquema, es necesario hacer una formalizacin del esquema de
conceptualizacin en LBIR.
49
Esta formalizacin del esquema de conceptualizacin se transforma en un esquema de

datos relacional para almacenar el modelo conceptual de la ontologa concreta. Se utiliza este
modelo de datos, tal y como se mostrar en el apartado 4.5, para aprovechar las ventajas de
las bases de datos relacinales, y para poder utilizar SQL, que est normalizado y ampliamente
extendido. El proceso de transformacin de un meta-modelo en LBIR en un esquema de datos,
llamado
implementacin
del
esquema
de
conceptualizacin,
se
puede
realizar
automticamente con ODE, el entorno software que da soporte tecnolgico al mtodo de

conceptualizacin.
Una vez que se ha generado el esquema de datos a utilizar, se hace la conceptualizacin
de la ontologa de dominio, que tambin puede estar asistida por computador. De hecho,
ODE ayuda a mantener los conocimientos conceptualizados y a verificarlos en el nivel de
conocimientos. Se puede comprobar, por tanto, que el tener descrito el esquema de
conceptualizacin de manera formal (en LBIR), y el imponer ciertas restricciones a quienes
conceptualizan el dominio de la ontologa, por ejemplo obligndoles a utilizar ciertos formatos
en los campos de las tablas, dan la posibilidad de utilizar un entorno software que ayude en la
conceptualizacin. Por otra parte, segn se ha mostrado durante el desarrollo de este trabajo
con la construccin del mdulo traductor de ODE, la imposicin de estas restricciones sobre la
conceptualizacin permite que el paso de la conceptualizacin a la implementacin de la
ontologa de dominio se pueda realizar tambin de manera automtica, y no sea necesaria la
formalizacin, que por esta razn no aparece sombreada en la Figura 3.1.
La especificacin de la ontologa de dominio tampoco est sombreada en la Figura 3.1,
porque no se considera dentro de la conceptualizacin, sino como una fase anterior.
En la Figura 3.3, se presenta la relacin entre los pasos del mtodo bi-fase a travs de sus
productos, y se muestra quin realiza cada paso. Se puede comprobar que una parte
importante del mtodo est automatizado con ODE. De hecho, la generacin de esquemas de
BB.DD en tiempo de ejecucin ha supuesto salvar una dificultad tecnolgica importante, ya que
es una tarea que suelen hacer los ingenieros en tiempo de diseo.
De manera complementaria a la Figura 3.3, en el organigrama de la Figura 3.4 se muestra
que el realizar la conceptualizacin, la formalizacin y la implementacin del esquema de
conceptualizacin depender de si se reutiliza completamente, o no, un esquema anterior,
pues si se reutiliza completamente, se puede reutilizar tambin su conceptualizacin, su
formalizacin y su implementacin. Por otra parte, el retorno al paso de especificacin del
esquema se llevar a cabo si se detectan nuevas necesidades de modelizacin mientras se
est conceptualizando la ontologa de dominio. De hecho, a lo largo de la utilizacin de este
mtodo en el desarrollo de distintas ontologas, se han llegado a cambiar ligeramente algunos
esquemas cuando la conceptualizacin de una ontologa ya estaba avanzada. No obstante, se
recomienda que el meta-modelo utilizado sea bastante estable, y que los cambios no sean
profundos cuando el desarrollo de la ontologa ya ha comenzado.
50
FASO 3.
FORMALIZACIN DEL
ESQUEMA DE
CONCEPTUALIZACIN
Necesidades
modclizacin
dominio
de
del
Quin la realiza: conocedor dely

LBIR
Meta-modelo descrito con tablas y

grafos
Especificacin en
lenguaje natural
Ontologa en un lenguaje de
implementacin
>ca
Si el meta-modelo se hace desde

cero, se hace un informe
justificando por qu
Meta-modelo en LBIR
define table...
define graph ...
define consistency .
define class ...

define relation .
Esquema de datos computable
para las ontologas que sigan
el meta-modelo
PASO 4. IMPLEMENTACIN
DEL ESQUEMA DE
CONCEPTUALIZACIN
Quin la realiza: software de

ODE
para LBIR
TablaUClave. Atributol, Atributo!)
Modelos conceptuales de ontologas siguiendo el metamodelo
cx><a
Figura 3.3. Entradas y productos de los pasos del mtodo de conceptualizacin
51
Paso 1. Especificacin del

esquema de conceptualizacin
Paso 3. Formalizacin del

Paso 2. Conceptualizacin del

Paso 4. Implementacin del

No
Paso 6. Implementacin de la
ontologa de dominio
Paso 5. Conceptualizacin de
la ontologa de dominio
Figura 3.4. Organigrama global del mtodo de conceptualizacin
3.4
APORTACIONES PRINCIPALES DEL TRABAJO
Con este trabajo se pretende hacer aportes metodolgicos y tecnolgicos dentro del rea de
desarrollo de ontologas. Los aportes metodolgicos se harn en los siguientes puntos
(vase la Figura 3.5):
1. Para resolver
el problema
de
la falta
de propuestas
en
la etapa
de
conceptualizacin, se propone un mtodo bi-fase para conceptualizar ontologas.

Esta laguna, detectada en el estado de la cuestin, conlleva que la ventaja de utilizar
ontologas para disminuir el cuello de botella que supone la adquisicin de conocimientos
52
APORTES
LAGUNA
PLANO METODOLGICO
PLANO METODOLGICO
Falta de propuestas de una etapa de conceptualizacinr

No se construyen modelos conceptuales computables i
Mtodo de cpnceptualizacin
"-"tfc
n s mnHplns rhnr.entiiale': s n n rnmniitahlp-"!
Esquemas de modelizacin
a) fijos y predeterminados I.: r:'^-""F,.j>.. -i > . .
b) no explcitos
c) no declarativos
|d) no computables
PLANO TECNOLGICO
PL iNO TE 7N0LOG1CO
Las ontologas se codifican directamente en un lenguaje r

de implementai ion
ODE ayudi i en la co iceptualizacin de ontologas
- No se utilizan moc elos conceptuales computables
- ODE traduce a Ontolingua
- Los esquemas de representacin son fijos y predeterminados t ^ ^ 4 ^ 5

y estn embebidos en el programa
Las ontologas se guardan en ficheros ASCII C
Posibilidad de esquemas a la
a) medida y
b) explcitos
c) declarativos
i
d) definidos de marsera formal
r^
- ODE manipula distintos esquemas de conceptualizacin

sin cambiar el programa
- Ontologas en BB.DD.RR + Traductores
Figura 3.5. Relacin entre los aportes del trabajo y las lagunas detectadas en el estado de la cuestin
53
Captulo 3. Mtodo de conceptualizacin basado en meta-modelos
[Meches et al.; 91] no se aproveche completamente, ya que, por ejemplo, tal y como se
ha dicho en la introduccin, los entendidos en el dominio tan siquiera entienden las
ontologas desarrolladas en los lenguajes de implementacin [Aguado et al.; 98].
Adems, las mismas personas encargadas de desarrollar ontologas se encuentran con
inconvenientes
tan
importantes
como
el
hecho
de
tener
que
enfrentarse
simultneamente a dos problemas: uno de modelizacin y otro tecnolgico. De ah que

en este trabajo se pretenda elaborar un mtodo bi-fase que permita, conceptualizar
ontologas, en el nivel de conocimientos [Newell, 82], utilizando tablas y gratos.
2. Para resolver el problema de esquemas de modelizacin fijos y predeterminados,
que no son explcitos y declarativos, se permite la elaboracin de esquemas de
conceptualizacin a la medida, explcitos, declarativos y definidos de manera
formal. Para acelerar el proceso de elaboracin de esquemas, se proporciona un
esquema de referencia que se puede reutilizar aadiendo y borrando componentes.
3. Para resolver, durante la modelizacin del dominio, el problema de tener que
transformar
manualmente
los
modelos
conceptuales
en
cdigo
de
implementacin, se conceptualiza de tal manera que los modelos conceptuales del

dominio son computables. Hasta ahora, el paso de un modelo conceptual a otro
computable se ha hecho a travs de un modelo formalizado. En consecuencia, es
necesario hacer manualmente, al menos, la transformacin del modelo conceptual en el
formalizado. Adems, hay que hacer una evaluacin de los distintos modelos obtenidos y
de los procedimientos de transformacin. Para salvar este inconveniente, en el mtodo
de conceptualizacin propuesto en este trabajo se utilizan EE.CC grficos y tabulares
que permiten modelizar las ontologas de manera ms fomial que la conceptualizacin
tradicional. En consecuencia, la conceptualizacin "invade" parte del terreno de la
formalizacin y es posible, en la segunda fase del mtodo, la traduccin directa a la
implementacin utilizando el software adecuado.
En lo concerniente a los aportes tecnolgicos, se ha construido ODE {Ontology Design
Environmenf), que supone un avance en los siguientes sentidos:
1. Para resolver el problema de ia codificacin directa de las ontologas una vez
adquiridos los conocimientos, ODE da la posibilidad de conceptualizar ontologas.
La situacin que se da en el plano metodolgico en cuanto a la carencia de propuestas
sobre la etapa de conceptualizacin tiene su reflejo en el plano tecnolgico. En efecto,
entornos software como el utilizado en Cyc [Lenat et al.; 90], el Ontolingua Server
[Farquhar et al.; 96], u Ontosaurus [Swartout et al.; 97], estn preparados para que las
ontologas sean codificadas directamente en un lenguaje de implementacin, y no para
ser desarrolladas en el nivel de conocimientos. Consiguientemente, a lo largo del
desarrollo de este trabajo se ha construido ODE {Ontology Design Environnnenf), el
entorno de desarrollo que da soporte tecnolgico al mtodo bi-fase de conceptualizacin
54
flexible. ODE permite la traduccin directa de la conceptualizacin a la implementacin,

es decir, elaborar modelos conceptuales computables, y la verificacin automtica
de los EE.CC en el nivel de conocimientos. Por lo tanto, con ODE las ontologas se
construyen en le nivel de conocimientos, lo cual supone un avance con respecto a otros
entornos muy utilizados en el desarrollo de ontologas.
2. Para resolver el problema de que los esquemas de modelizacin son fijos y
predeterminados, ODE manipula esquemas de conceptualizacin descritos de
manera declarativa y no embebidos en el programa. Por consiguiente, la creacin y
utilizacin de diferentes esquemas de conceptualizacin no implica cambios en el
programa, lo que hace ms sencillo su mantenimiento.
3. Para resolver el problema del almacenamiento en ASCII, ODE almacena las
ontologas en bases de datos relacinales. Los entornos software hasta ahora
utilizados en el desarrollo de ontologas, almacenan las ontologas en ficheros ASCII, lo
cual plantea problemas de consistencia de los datos, redundancia, dependencia del nivel
fsico, etc. Para solucionar estos problemas, en ODE se almacenan las ontologas en
bases de datos relacinales, con lo que se tiene, adems, la ventaja de poder hacer
consultas SQL sobre estas ontologas y, as, se facilita la utilizacin de stas por parte de
otras aplicaciones.
La combinacin del aporte anterior (esquemas de conceptualizacin a la medida) y
del almacenamiento de ontologas en bases de datos obliga a superar una dificultad
tcnica importante, pues los esquemas de bases de datos hay que generarlos en
tiempo de ejecucin en vez de elaborarlos en tiempo de diseo, que es la solucin ms
habitual.
Por otra parte, aunque es cierto que las bases de datos relacinales tienen menos
poder de inferencia que algunos de los lenguajes de implementacin utilizados en el
desarrollo de ontologas, tambin es cierto que ODE salva estos problemas gracias al
uso de traductores.
3.5 HIPTESIS DE TRABAJO

Las premisas que se asumen a lo largo de esta memoria son las que se muestran a
continuacin:
P1. Segn el enfoque de esta trabajo, una ontologa no se construye con el propsito de
que sea ella sola la base de conocimientos de una aplicacin. Se construye con el
objetivo de integrarla, en diferentes aplicaciones, con otras ontologas o con otros
componentes.
P2. El mtodo se ha aplicado desarrollando ontologas independientemente de la aplicacin
donde se vayan a usar. Una repercusin importante que va a tener este enfoque es
55
que, a la hora de traducir el modelo conceptual para generar el modelo operativo en un

lenguaje concreto, slo ser necesario indicar qu es aquello que ha quedado sin
traducir debido a la diferencia de expresividad entre el esquema de conceptualizacin y
el lenguaje destino. La decisin de qu hacer para solucionar esta diferencia entre
modelos se dejar para el momento en que se utilice la ontologa en una aplicacin.
Por otra parte, las restricciones que se han tenido en cuenta a la hora de elaborar el mtodo
bi-fase de conceptualizacin basado en meta-modelos son las siguientes:
R1. Las necesidades de modelizacin de la ontologa de dominio se suponen como
entradas del mtodo. Con el objetivo de limitar el alcance del trabajo, se ha decido no
incluir en el mtodo la tarea que permite realizar el anlisis de las necesidades de
modelizacin de la ontologa de dominio.
R2. El mtodo de conceptualizacin flexible slo se ha aplicado en la construccin de
antologas de dominio con conocimientos estticos. Es decir, no se ha comprobado que
el mtodo sea vlido para representar mtodos genricos de resolucin de problemas,
para modelizar acciones etc. Tampoco se ha utilizado con conocimientos deductivos y
procedimentales.
R3. El mtodo se ha aplicado con una modelizacin basada en conceptos, relaciones,
atributos, instancias, valores y axiomas expresados en lgica de primer orden. En la
seccin 2.1 se describen estos componentes.
R4. A la hora de conceptualizar, no se tienen en cuenta los mecanismos de razonamiento
de los lenguajes en que se implementarn las ontologas, aunque se supone que se
utiliza herencia de propiedades. Por ejemplo, a la hora de deducir conocimientos
utilizando los axiomas, no se asume resolucin, ni deduccin natural, etc.^ todo
depender del lenguaje de implementacin y de la aplicacin en que se utilice la
ontologa. Por otra parte, en la herencia mltiple, se asume que los conceptos se
organizan en taxonomas de especializacin y generalizacin, y que, por tanto, se
pueden heredar propiedades por varios caminos; pero no se asume ningn orden
explcito en cmo se recorre el grafo de conceptos en caso de poder aplicar herencia
de propiedades, pues cmo se aplica herencia mltiple en los lenguajes de
implementacin de ontologas, queda fuera del alcance de este trabajo.
Consiguientemente, traduciendo un modelo conceptual a diferentes lenguajes de
implementacin, se pueden tener distintos mecanismos de razonamiento. Cada uno de
ellos puede ser ms adecuado dependiendo de la aplicacin en que se vaya a utilizar la
ontologa.
56
4.DESCRIPCIN DETALLADA DE LA
SOLUCIN
57
4.1
Captulo 4. Descripcin detallada de la solucin
INTRODUCCIN
En los siguientes apartados se mostrarn los detalles de cada uno de los pasos del mtodo de
conceptualizacin flexible. Para cada paso se describir cada tarea que hay que realizar, es decir,
cada asignacin de trabajo bien definida para uno o ms miembros del proyecto.
Se podr comprobar que las descripciones de las tareas estn muy pormenorizadas. Esto se
debe fundamentalmente a que este mtodo est pensado para utilizar un soporte software. De
hecho, se ha desarrollado ODE (presentado en la seccin 4.8) para dar soporte a gran parte de las
tareas del mtodo.
4.2 ESPECIFICACIN DEL ESQUEMA DE CONCEPTUALIZACIN

4.2.1 INTRODUCCIN
Segn lo expuesto en la visin general del mtodo bi-fase, antes de comenzar la conceptualizacin
de la ontologa de dominio, es conveniente estudiar, a partir de las necesidades de modelizacin
de la ontologa, qu esquema de conceptualizacin se va a aplicar, es decir, hay que especificar
qu EE.CC se van a utilizar en la conceptualizacin de la ontologa de dominio, cules sern las
caractersticas de estos EE.CC, en qu orden hay que utilizarlos, y cules sern las reglas de
verificacin de la consistencia dentro de cada EC y entre EE.CC. La descripcin en lenguaje
natural del esquema de conceptualizacin se ha llamado especificacin del esquema de
conceptualizacin (Figura 4.1). La especificacin del esquema de conceptualizacin se puede dar
en tres escenarios distintos: que se pueda reutilizar completamente
un esquema de
conceptualizacin anterior, que se pueda adaptar un esquema anterior, o que haya que especificar
un esquema empezando desde cero. En consecuencia, este primer paso del mtodo incluye las
siguientes tareas (Figura 4.2):
1. Anlisis de la expresividad de los esquemas. A partir de las necesidades de modelizacin,
se analiza cul de los esquemas de conceptualizacin utilizados con anterioridad se ajusta
mejor a las necesidades de modelizacin de la nueva ontologa.
2. Elaboracin desde cero de una especificacin. En caso de que ninguno de los esquemas de
conceptualizacin anteriores pueda satisfacer, tan siquiera modificndolo, las necesidades
de modelizacin de la nueva ontologa, se especifica un nuevo esquema.
3. Modificacin de un esquema. Si hay algn esquema que satisface parcialmente las
necesidades de conceptualizacin de la ontologa, pero no totalmente, se modifica dicho
esquema de conceptualizacin. Obsrvese que a esta tarea tambin se puede llegar
despus
de detectar
nuevas
necesidades
de
modelizacin
cuando
ya se
est
59
conceptuallzando el dominio.
En los siguientes apartados se presentar cada una de las tareas. La descripcin de cada tarea
constar de: una introduccin para dar una explicacin general; una descripcin de sus entradas,
una descripcin de los productos obtenidos; una exposicin de cmo se lleva a cabo la tarea; y una
presentacin de quines tienen que llevarla a cabo.

esquema de conceptualizadn



No
ontologa de dominio
Figura 4.1. Relacin de la especificacin del esquema de conceptualizacin con respecto al resto del mtodo
60
Paso 2.
Conceptualizacin
del esquema de
conceptualizacin
PASO 1.
ESPECIFICACIN DEL
ESQUEMA DE
CONCEPTUAUZACIN
*
Paso 3.
Formalizacin del
esquema de
conceptualizacin
Tarea 1.1. Anlisis de

la expresividad de los
esquemas
Tarea
Elaboracin
cero
de
especificacin
Paso 4.
Implementacin del
esquema de
conceptualizacin
1.2.
desde
Tarea
1.3.
Modificacin de una
especificacin
Reutilizacfn de un
esquema de
conceptualizcin
No
ic-
ontologa de dominio
Figura 4.2. Tareas de la especificacin del esquema de conceptualizacin dentro del mtodo
4.2.2 ANLISIS DE LA EXPRESIVIDAD DE LOS ESQUEMAS

4.2.2.1
INTRODUCCIN
En esta tarea, considerando las necesidades de modelizacin de la nueva ontologa, se determina

si se puede reutilizar alguno de los esquemas de conceptualizacin usados anteriormente en la
conceptualizacin de otra ontologa.
61
4.2.2.2
ENTRADAS
Se puede utilizar la siguiente documentacin:

1. Un documento donde se describan las necesidades de modeiizacin para la nueva
ontologa. Se debe hacer una descripcin de los tipos de connponentes que se van a
necesitar, y se deben dar algunas guas sobre cmo han de ser los elementos de
conceptualizacin para que puedan ser manejados fcilmente por los entendidos en el
dominio de la ontologa a desarrollar.
2. Descripcin de los esquemas utilizados en otras ontologfas. Se utilizarn tanto las
especificaciones de los esquemas como sus meta-modelos con tablas y gratos. Los metamodelos se utilizan porque describen los esquemas de manera ms precisa que las
especificaciones.
4.2.2.3
PRODUCTOS OBTENIDOS
El resultado de llevar a cabo la tarea de anlisis de la expresividad de esquemas de

conceptualizacin puede ser la especificacin de un esquema para ser reutilizado parcial o
totalmente, o un documento donde se justifique la decisin de describir un esquema nuevo.
4.2.2.4
PROCEDIMIENTO PARA LLEVAR A CABO LA TAREA
Las acciones que hay que llevar a cabo para determinar cul de los escenarios de
conceptualizacin es el que se da para la ontologa a construir son los que se presentan a
continuacin:
Accin 1. Seleccin de un esquema de conceptualizacin candidato. La recomendacin para
este paso es partir del esquema de referencia que es el ms expresivo de los hasta
ahora utilizados. No obstante, tambin es posible tomar como esquema candidato
uno de los utilizados en ontologas de dominios similares al de la ontologa a
desarrollar.
Accin 2. Estudio de la adecuacin del esquema de conceptualizacin candidato. Se eligen
algunos de los trminos candidatos a formar parte de la ontologa, y se estudia en
qu medida es posible e intuitivo conceptualizarlos utilizando el esquema
seleccionado en el paso anterior. En caso de que el esquema de conceptualizacin
no sea adecuado, se puede volver a la accin 1 para probar con otro esquema.
Accin 3. Decisin sobre el escenario. Dependiendo del estudio del paso anterior, se propone
la elaboracin de un esquema nuevo (seccin 4.2.3), la modificacin del candidato
(seccin 4.2.4) o pasar directamente a la conceptualizacin de la ontologa de
62
dominio con el esquenna candidato (seccin 4.6).

4.2.2.5
QUINES INTERVIENEN EN LA TAREA
En la determinacin del escenario de conceptualizacin intervienen tanto los entendidos en

conceptualizacin, como las personas que van a construir las ontologas del dominio. stos ltimos
juegan un papel clave para ver si los EE.CC utilizados les resultan intuitivas y apropiadas para el
dominio a modelizar.
4.2.3 E L A B O R A C I N D E S D E C E R O D E U N A E S P E C I F I C A C I N
4.2.3.1
INTRODUCCIN
En caso tener que especificar desde el principio un esquema de conceptualizacin para la nueva
ontologa, es necesario hacer una descripcin en lenguaje natural de las EE.CC a utilizar, de sus
campos si son tablas, de sus arcos y vrtices si son gratos, de las reglas de verificacin de la
consistencia dentro de cada EC y entre EE.CC, y del orden recomendado para rellenar los EE.CC.
A modo de ejemplo, se ha aadido al final de este apartado la descripcin de un caso prctico
(seccin 4.2.3.4).
4.2.3.2
ENTRADAS
La justificacin de que ningn meta-modelo anterior es til para la nueva ontologa (apartado
4.2.2.3), y documento con las necesidades de modelizacin de la nueva ontologa.
4.2.3.3
PRODUCTOS A OBTENER
Una descripcin en lenguaje natural del esquema de conceptualizacin a utilizar.

4.2.3.4
CASO PRCTICO: ESPECIFICACIN DE UN ESQUEMA
A continuacin, a modo de ejemplo, se presenta la descripcin del esquema de referencia sin la

tabla de concepto-atributo de clase-valor, ni la columna relacin de la tabla de instancias. Estas
salvedades sobre el esquema de referencia se han hecho para mostrar, en apartados posteriores,
los mecanismos de control de cambios. En caso de que se desee ver, mediante ejemplos, el
aspecto concreto de las tablas y gratos que se estn definiendo, se puede consultar el anexo II.
Para conceptualizar segn el esquema de referencia, hay que hacer lo siguiente:
a)
Realizar una ficha de descripcin general donde aparezca: el nombre de la ontologa; la

hora y la fecha de creacin; los autores; y un campo de descripcin con el propsito, una
visin general de sta y las fuentes utilizadas.
63
b)
Elaborar un glosario de trminos que incluya, junto con sus descripciones, los conceptos,
las instancias, las relaciones, los atributos y las constantes.
Una vez que se ha conceptualizado la ontologa, es necesario asegurarse de que todos
los trminos del glosario estn descritos en alguno de los EE.CC posteriores.
c)
Elaborar una tabla de trminos a importar con los nombres de los trminos que se
importan, las ontologas de donde se obtienen, los nombres de los servidores donde estn
estas ontologas, y los nombres que reciben los trminos en la ontologa que se est
construyendo.
d)
Construir un rbol de clasificacin de conceptos que los organice segn las relaciones:
subclase de, subclase en una particin disjunta, subclase en una particin exhaustiva, etc.
Cuando se ha construido el rbol de clasificacin de conceptos, hay que verificar que
todos los conceptos estn el glosario de trminos.
e)
Dibujar un diagrama de relaciones binarias para todas aquellas relaciones que tengan
origen en algn concepto de la ontologa que se est construyendo. Este diagrama
proporciona una gua para integrar ontologas, ya que si el concepto C1 est relacionado
mediante la relacin R con el concepto C2 que est en otra ontologa, entonces la
ontologa que se est desarrollando deber incluir la ontologa que contiene C2.
Una vez que se ha terminado de construir el diagrama de relaciones binarias, hay que
comprobar que las relaciones cuyo origen es un concepto del rbol de clasificacin de
conceptos estn en el glosario de trminos, pues son relaciones definidas en la ontologa.
Tambin hay que comprobar que todos aquellos conceptos o relaciones que no aparezcan
en el glosario de trminos tienen que aparecer en la tabla de trminos a importar.
f)
Hacer un diccionario de conceptos que contenga todos los conceptos que aparezcan en el
rbol, sus instancias, sus atributos de clase y de instancia, las relaciones binarias en las
que dichos conceptos estn como origen, y los sinnimos y abreviaturas. Los atributos de
instancia son aquellos que sirven para describir instancias particulares, por ejemplo el peso
es especfico de cada persona; por otra parte, los atributos de clase describen los
conceptos de forma global, por ejemplo la edad mxima de jubilacin en los distintos
oficios y profesiones hace referencia a conceptos, no a instancias particulares de stos.
Una vez que se ha construido el diccionario de conceptos, hay que verificar que los
conceptos aparecen en el rbol de clasificacin de conceptos; que todos los conceptos del
rbol de clasificacin de conceptos aparecen en el diccionario de conceptos; que los
atributos de ciase y de instancia, as como las instancias estn en el glosario de trminos; y
64
que las relaciones se encuentran en el diagrama de relaciones.

g)
Realizar una tabla de relaciones binarias para cada una de las relaciones reflejadas en el
diccionario de conceptos. Para cada relacin se especificar: su nombre, el nombre del
concepto origen, el nmero mnimo y mximo de veces que puede aparecer una instancia
del concepto origen en la relacin (cardinalidad), el concepto destino, las propiedades
matemticas (propiedad transitiva, reflexiva, etc.), la relacin inversa y las referencias a las
fuentes utilizadas. Obsrvese que tanto el concepto destino como la relacin inversa
pueden ser trminos de otra ontologa; en ese caso, hay que importar la ontologa a la que
pertenezcan.
Cuando se han rellenado las tablas de relaciones binarias, hay que comprobar que hay
consistencia dentro de las mismas tablas de tal manera que el origen de cada relacin sea
el destino de su inversa, y al contrario. Adems, hay que verificar la consistencia con otros
EE.CC, pues es necesario comprobar que cualquier relacin descrita en una tabla de
relaciones aparece en el diccionario de conceptos en la misma fila que el concepto que
aparece en el campo 'concepto origen'; y que todas las relaciones que aparecen en el
diccionario de conceptos estn descritas en alguna tabla de relaciones.
h)
Elaborar una tabla de atributos de instancia para cada uno de los atributos de instancia que
aparezcan en el diccionario de conceptos. Debe incluir: su nombre; el concepto al que
pertenece; el tipo de valor; la unidad de medida si es un atributo numrico; la precisin en
caso, tambin, de valores numricos; el intervalo de valores; el valor por defecto; el nmero
mximo y mnimo de valores que puede tomar (cardinalidad); los atributos de instancia, de
clase y constantes que se utilizan para deducir su valor; los atributos que pueden ser
deducidos utilizando el valor del atributo que se est definiendo; las frmulas que se
pueden utilizar para hallar el valor del atributo; y las referencias utilizadas para describirlo.
Cuando se han rellenado las tablas de atributos de instancia, hay que comprobar la
regla que dice: un atributo Ai aparece en el campo 'deducido de los atributos de instancia'
de la tabla de otro atributo A2 si y slo si A2 aparece en el campo 'para deducir' de la tabla
de Al. En lo referente a las comprobaciones con otros EE.CC, es necesario verificar que
todos los atributos se encuentran en el diccionario de conceptos en la misma fila que el
concepto que aparece en el campo 'concepto'; y que todos los atributos de instancia del
diccionario de conceptos estn descritos en alguna tabla de atributos de instancia.
i)
Realizar una tabla de atributos de clase por cada uno de los atributos de clase del
diccionario de conceptos. Deber aparecer en ella: el nombre del atributo, el concepto al
que pertenece, el tipo de valor, la unidad de medida, la precisin, la cardinalidad, los
atributos de instancia que pueden ser deducidos a partir de l, y las referencias a las
65
fuentes de donde se han obtenido los conocimientos relativos al atributo.

Una vez que se han rellenado las tablas de atributos de clase, es necesario connprobar
que todos los atributos se encuentran en el diccionario de conceptos en la misnna fila que el
concepto que aparece en el campo 'concepto'; y que todos los atributos de ciase del
diccionario de conceptos estn descritos en alguna tabla de atributos de clase. Tambin
hay que comprobar la regla que dice: un atributo de instancia A aparece en el campo 'para
deducir' de la tabla de un atributo de clase A; si y slo si A; aparece en el campo 'deducido
de los atributos de clase' de la tabla de Aj)
Realizar una tabla de constantes. Para cada constante se especificar: su nombre, la

descripcin en lenguaje natural, el tipo de valor, el valor, la unidad de medida, los atributos
que se pueden deducir a partir de ella, y las referencias.
Cuando se ha rellenado la tabla de constantes, es necesario verificar que se encuentra
en el glosario de trminos y que se cumple la regia que dice: un atributo de instancia A est
en el campo 'para inferir' de una constante C si y slo si C est en el campo 'deducido de
las constantes' del atributo A.
k)
Hacer una tabla de axiomas lgicos por cada uno de los que se quieran utilizar para
describir los conceptos a travs de expresiones en lgica de primer orden. Sus campos
sern: el nombre del axioma; la descripcin en lenguaje natural; el concepto al que
describe; los atributos, relaciones, constantes y variables que intervienen en la expresin;
la expresin en lgica de primer orden; y las referencias a las fuentes.
Cuando se han rellenado las tablas de axiomas, hay que verificar que las constantes,
variables, atributos, instancias y conceptos que aparecen en la expresin son los mismos
que aparecen en los campos 'constantes referidas', 'variables', 'atributos referidos',
'instancias referidas' y 'conceptos referidos'. Adems hay que comprobar, a su vez, que las
constantes que aparecen en estas tablas estn en la tabla de constantes, que las
instancias estn en la tabla de instancias, que los atributos estn en las tablas de atributos
de clase o de atributos de instancia, y que los conceptos estn en el diccionario de
conceptos.
I)
Elaborar una tabla de frmulas por cada una de las que aparezcan en las tablas de
atributos de instancia. Sus campos sern: el nombre, el concepto al que se refiere, el
atributo que deduce, la expresin de la frmula, la descripcin en lenguaje natural, los
atributos y las constantes que intervienen, la precisin, las restricciones para aplicarla (es
una expresin en lgica de primer orden), y las referencias.
Una vez que se han rellenado las tablas de frmulas, hay que comprobar que el atributo
Mtodo flexible para la conceptualizacin de ontologfas basado en meta-modelos
66
inferido es el que se encuentra a la izquierda del igual en la expresin de la frmula, y que

los atributos bsicos son los que se encuentran a la derecha del igual. Adems, hay que
verificar que lo rellenado en las tablas de frmulas es coherente con lo rellenado en los
campos 'para deducir', 'deducido de los atributos de instancia', 'deducido de los atributos
de clase', 'deducido de las constantes' y 'frmula' de las tablas de atributos de instancia.
m) Construir rboles de clasificacin de atributos, que muestran grficamente cmo se pueden
obtener unos atributos a partir de otros o de constantes utilizando frmulas. Las relaciones
que se establecen en estos rboles son las siguientes:
Se utiliza en. Relaciona un atributo o una constante con la frmula donde se utiliza.
Obtiene. Relaciona una frmula con su atributo inferido.
Cuando se ha dibujado el rbol de clasificacin de atributos hay que comprobar que si
un atributo Ai sirve para deducir otro A2, entonces A2 no sirve para deducir A^. Tambin
hay que verificar que las deducciones que aparecen en el rbol son las mismas que se
describen en las tablas de frmulas.
n)
Elaborar una tabla de instancias para cada instancia del diccionario de conceptos. Cada
tabla incluir: el nombre de la instancia, los atributos con los valores conocidos en la
instancia, y estos valores\
Cuando se ha rellenado esta tabla, se debe comprobar que todos los atributos de
instancia estn en el diccionario de conceptos en la misma fila que el concepto que
aparece en el campo 'nombre del concepto' o en la misma fila que uno de las superclases
de este concepto.
El orden en que se deben empezar a rellenar los EE.CC es el siguiente: (1) ficha de descripcin
general; (2) glosario de trminos, y lista de trminos a importar; (3) rbol de clasificacin de
conceptos; (4) diagrama de relaciones; (5) diccionario de conceptos; (6) tablas de relaciones,
tablas de atributos de clase, tablas de atributos de instancia, y tabla de constantes; (7) tabla de
axiomas lgicos, y tablas de frmulas; (8) rboles de clasificacin de atributos; y (10) tabla de
instancias. Este orden slo implica que unos EE.CC se empiezan a rellenar antes que otros, pero
no que haya que terminar de rellenar unos antes de empezar con otros. Es decir, se admiten
concurrencias dentro de una deseada secuencialidad.
' En el ejemplo del anexo II, la tabla de instancias tiene tambin una columna de relaciones, que se ha omitido
aqu para mostrar ms adelante el control de cambios
67
4.2.4 MODIFICACIN DE LA ESPECIFICACIN DE UN ESQUEMA

4.2.4.1
INTRODUCCIN
Cuando se describe un esquema de conceptualizacin, generalmente se parte de un esquema

anterior que, a veces, se modifica para adaptarlo a las necesidades de modelizacin de la nueva
ontologa (Figura 4.3). Estas modificaciones se pueden detectar bien sea antes de empezar la
conceptualizacin de la ontologa de dominio, que es lo ms deseable, o tambin se pueden
detectar cuando ya se est haciendo la conceptualizacin de la ontologa de dominio.
Figura 4.3. Tarea de modificacin de un esquema de conceptualizacin dentro de la especificacin
68
Es fundamental tener descrita de manera precisa esta tarea de modificacin de un esquema de

conceptualizacin, sobre todo para que sea fcil llevar un control de cambios y, as, que stos no
sean caticos y desordenados.
4.2.4.2 DESCRIPCIN DE LA MODIFICACIN DE CUALQUIER ESQUEMA DE

CONCEPTUALIZACIN
A la hora de hacer cambios en un esquema de conceptualizacin, las acciones que se realizan son
los siguientes:
Accin 1. Alguien, generalmente un desarrollador de ontologas, rellena un formulario sobre
problemas de un esquema de conceptualizacin para modelizar conocimientos. Este
formulario tendr la siguiente infonnacin:
a) el nombre de la persona que ha detectado los problemas;
b) el nombre del esquema al que se refiere el formulario;
c) las carencias que tiene el esquema de conceptualizacin, y que deben ser
solucionadas; y
d) la fecha en que se ha realizado el formulario.
En este primer paso, no se proponen unos cambios concretos en el modelo debido a
que la persona que propone los cambios ha detectado algn problema en la forma
de representar conocimientos; y puede que no sepa cmo solucionarlo.
Accin 2. A continuacin, un miembro del grupo familiarizado con la definicin de los
esquemas de conceptualizacin bien resuelve el problema sin necesidad de cambiar
el esquema, bien elabora una propuesta de cambios que contendr la siguiente
informacin:
a)
Nombre del miembro del grupo que se ha encargado de hacer la propuesta;
b)
Nombre del esquema afectado por los cambios;
c)
Descripcin en lenguaje natural de los cambios a realizar;
d)
Fecha de propuesta de los cambios;
Esta propuesta se la enva al comit de cambios para que la examine y le d el visto

bueno.
y\ccin 3. Si los cambios son aceptados por el comit de cambios, se llevan cabo y se obtiene
la nueva especificacin. Otra posibilidad es que el comit no acepte los cambios tal
69
cual, pero que se llegue a un consenso. Este consenso tambin deber estar
documentado indicando qu peticin de cambios lo ha provocado.
4.2.5 CASO PRCTICO: CONTROL DE CAMBIOS

ESQUEMA DE CONCEPTUALIZACIN
SOBRE
UN
En este apartado, se han realizado dos cambios en el esquema de conceptualizacin del caso
prctico de la tarea de elaboracin de un esquema desde cero (apartado 4.2.3). Se trata de la
incorporacin de las tablas de concepto-atributo de clase-valor, y del aadido de la columna
'relacin' a la tabla de atributos de instancia. Es decir, por una parte, se propone realizar una tabla
de concepto-atributo de clase-valor para cada uno de los conceptos en los que tomen valores los
atributos de clase. Incluir: el nombre del concepto, los atributos de clase, y los valores que toman
dichos atributos. Por otra parte, para cada instancia l^ de la ontologa para la que se conozca su
instancia destino t va una relacin R, habr una fila en la tabla de instancias que conecte l^ va la
relacin f con/2.
Primero, la persona encargada del desarrollo de una determinada ontologa detecta un
problema en el meta-modelo que est utilizando y rellena el formulario de la
Figura 4.4. A continuacin, un miembro del grupo propone los cambios que se muestran en el
formulario de la Figura 4.5, y enva los dos formularios, el rellenado por la persona encargada de
conceptualizar el dominio de la ontologa, y el rellenado por l mismo, al comit de cambios. Una
vez que el comit de cambios ha examinado los problemas que tiene el meta-modelo y las
soluciones que se proponen, da el visto bueno para que se lleve a cabo la modificacin o la
rechaza. Despus, la persona que propuso los cambios u otro miembro del grupo lleva a cabo las
modificaciones concretas en la especificacin del esquema anterior.
FORMULARIO SOBRE PROBLEMAS EN META-MODELOS

Nombre de la persona que ha detectado los problema
Mara Dolores Rojas Amaya
Nombre del meta-modelo Esquema 4
Carencias
1. Es engorroso asignarle valores a los atributos de clase a travs de axiomas.
Adems, queda en este aspecto una conceptualizacin poco intuitiva.
2.
Algo similar ocurre a la hora de establecer las instancias de las relaciones,

que hay que hacerlo a travs de axiomas.
Fecha 5 de noviembre de 1999
Figura 4.4. Ejemplo de formulario sobre problemas en un esquema de conceptualizacin
70
Mciriano Fernndez Lpez
PROPUESTA DE CAMBIOS EN META-MODELOS
Nombre del miembro del grupo que hace la propuesta

Mercedes Blzquez Cvico y Mariano Fernndez Lpez
Nombre del esquema
Esquema de modelo conceptual de ontologa de referencia versin 1.3
Descripcin de los cambios propuestos
Para poder asignar valores a los atributos de clase, se aadir al esquema una
tabla de concepto de clase-atributo valor que asigne a cada atributo de clase
el valor que toma en cada concepto. Esta tabla tendr la siguiente forma:
Concepto
Atributo de clase
Valor
Por otra parte, para poder establecer cules son las instancias de relaciones,
se aadir una nueva columna a la tabla de instancias, llamada 'relacin'. As,
cuando una instancia A est relacionada a travs de una relacin R con otra
instancia i, siendo h el origen e Ij el destino, habr una fila en la tabla de
instancias de la siguiente manera:
Instancia
Ii
Atributo
--
Relacin
Valor
Fecha
7 de noviembre de 1999
Figura 4.5. Ejemplo de propuesta de cambios en un esquema de conceptualizacin
4.2.6 CONCLUSIONES SOBRE LA ESPECIFICACIN DEL ESQUEMA

DE CONCEPTUALIZACIN
En la presente seccin se ha descrito el procedimiento para especificar, partiendo de las
necesidades de modelizacin de una ontologa de dominio, su esquema de conceptualizacin.
Este paso es llevado a cabo por entendidos en conceptualizacin con la colaboracin de las
personas que van a conceptualizar la ontologa de dominio y, por consiguiente, la probabilidad de
que el esquema obtenido sea intuitivo y fcil de utilizar por parte de estas personas ser alta.
En el documento obtenido, no slo se describen los EE.CC a utilizar con sus componentes
(campos, vrtices, etc.), sino tambin las reglas de la verificacin de la consistencia que se han de
cumplir. Por lo tanto, se facilitar la verificacin en el nivel de conocimientos de la ontologa
desarrollada.
'or otra parte, tambin se ha presentado un mtodo de control de cambios sobre las
71
especificaciones de los esquemas de conceptualizacin. De esta manera se evita que se llegue al

caos en el desarrollo de la ontologa por no llevar un control sobre la documentacin manipulada.
Como se ver en las secciones posteriores, un cambio en la especificacin, tambin provocar
cambios en los meta-modelos conceptuales.
En lo referente al esquema de referencia, expuesto en los casos prcticos, permite
conceptualizar conceptos, atributos de clase, atributos de instancia, relaciones, instancias,
frmulas, axiomas y constantes. Adems, los conceptos se estructuran en taxonomas utilizando la
relacin sub-clase de, sub-clase en una particin exhaustiva, y sub-clase en una particin disjunta.
Por otra parte, los atributos tambin se estructuran en forma de rbol segn su secuencia
deductiva a travs de las frmulas. Al ser ste un esquema complejo, que incluye gratos, tablas
con distintos tipos de trminos, mltiples reglas de verificacin de la consistencia entre EE.CC del
mismo y de distinto tipo, etc., se tiene un ejemplo que sirve para mostrar que el mtodo bi-fase
expuesto en esta memoria es vlido para casos que no son de "juguete".
4.3
CONCEPTUALIZACIN
CONCEPTUALIZACIN
DEL
ESQUEMA
DE
Una vez que se tiene en lenguaje natural la especificacin del esquema de conceptualizacin, se
lleva a cabo su conceptualizacin elaborando un meta-modelo que debe describir, utilizando tablas,
y gratos, el esquema de conceptualizacin que se vaya a seguir en la construccin de la ontologa
concreta. Al igual que sucede con la especificacin del esquema, a la hora de hacer su
conceptualizacin, se pueden dar los siguientes escenarios: que se pueda reutilizar completamente
un meta-modelo anterior, que se pueda adaptar un meta-modelo anterior, o que haya que
especificar un meta-modelo empezando desde cero. As, segn se muestra en la Figura 4.6, las
tareas que incluye este paso son las siguientes:
1. Elaboracin desde cero de un meta-modelo. En caso de que en la especificacin se haya
decidido la elaboracin de un esquema de conceptualizacin nuevo, ser necesario realizar
el meta-modelo correspondiente.
2. Modificacin de un meta-modelo anterior Si en la especificacin se ha decidido modificar un
esquema de conceptualizacin, es necesario tambin modificar su meta-modelo.
En los siguientes apartados se presentarn estas dos tareas, y se terminar con un apartado de
conclusiones sobre la conceptualizacin del esquema de conceptualizacin.
72
INICIO

Escenario
CONCEPTVAUZACIN
DEL ESQUEMA D
CONCEPTVAUZACIN
Tarea 2.1. Elaboracin desde
cero de un meta-modelo
Tarea 2.2. Modificacin de un

meta-modelo anterior
Paso 3. Forraalizacin del


No
ontologa de dominio
T
Figura 4.6. Tareas de la conceptualizacin del esquema de conceptualizacin dentro del mtodo
4.3.1 ELABORACIN DESDE CERO DE UN META-MODELO

4.3.1.1
INTRODUCCIN
En caso tener que realizar desde el principio un meta-modelo para la nueva ontologa, es
necesario hacer una descripcin muy detallada, aunque fcil de entender, de las EE.CC a utilizar,
de sus caractersticas, y las reglas de verificacin de la consistencia dentro de cada EC y entre
EE.CC. Dado que se trata de una tarea densa, se ha aadido al final de este apartado la
descripcin de un caso prctico (seccin 4.3.1.6).
73
4.3.1.2
ENTRADAS
Especificacin del esquema de conceptualizacin obtenido en el paso anterior.
4.3.1.3
PRODUCTOS A OBTENER
Dado que en esta tarea se lleva a cabo la conceptualizacin de un mtodo de conceptualizacin,

en los dos primeros apartados de esta seccin se presentar en detalle qu hay que modelizar en
esta conceptualizacin del esquema de conceptualizacin y, en los siguientes apartados, se
describir la documentacin a obtener.
La estructura de esta seccin queda como sigue:
4.3.1.3.1. Componentes a definir en un meta-modelo. En este apartado, se presentar qu hay
que especificar para que un meta-modelo quede completamente definido.
4.3.1.3.2. Caractersticas que tendrn los componentes a especificar en un meta-modelo. Se
describir qu tipos de tablas se podrn definir, cmo sern los gratos, cules sern
los formatos posibles de los campos de las tablas y de las etiquetas de los gratos,
etc. Adems, se mostrar cmo son las reglas de la verificacin de la consistencia
dentro de EE.CC del mismo tipo y entre EE.CC de tipos distintos.
4.3.1.3.3. Documentacin generada. Se mostrarn las tablas y los gratos que hay que obtener
a! definir un meta-modelo.
4.3.1.3.1
Componentes a definir en un meta-modelo
Con el propsito de que cualquier meta-modelo defina de manera precisa el esquema de

conceptualizacin, se modelizarn los siguientes componentes:
1. Elementos de conceptualizacin, que incluyen:
1.1. Los representaciones tabulares que se van a emplear, as, para cada tabla se indicar:
su nombre; sus siglas, que se podr utilizar para identificarla; una descripcin en
lenguaje natural; el orden en la metodologa, es decir, cul es el EC que se debe
rellenar justo antes de la tabla considerada; etc. Adems, para cada campo, se
representar: el nombre; las siglas; el formato (trmino, descripcin, expresin
aritmtica, etc.); la multiplicidad; etc.
1.2. Las representaciones grficas que se van a emplear, especificando para cada grafo: su
nombre; sus siglas; su descripcin en lenguaje natural; y el orden en la metodologa.
Tambin, para cada tipo de arco, hay que definir el nombre, las siglas y la descripcin.
Adems, para cada tipo vrtice, se especificar: el nombre, las siglas, la descripcin, los
74
tipos de arcos que pueden entrar o salir de un vrtice que se ajuste a este tipo; cuntos
arcos de cada tipo pueden entrar en cada tipo de vrtice, o cuntos pueden salir de l.
2. Un conjunto de regias de consistencia entre EE.CC y dentro de cada EC, as para cada regla
de consistencia se dar una descripcin en lenguaje natural y otra formal.
3. Un orden en la conceptualizacin. Aunque no se exige que la persona encargada de
conceptualizar el donninio siga un orden estricto a la hora de rellenar las distintos EE.CC, el
meta-modelo s debe establecer de manera clara qu orden es el que se aconseja.
4.3.1.3.2 Caractersticas que tendrn los componentes a especificar en un

meta-modelo
En este apartado, primero se ver el formato de los EE.CC, tanto tabulares como grficos. Luego,
se mostrarn los posibles formatos de los campos, los arcos y los vrtices de los grafos. Despus,
se describirn las propiedades que se pueden definir sobre los campos de las tablas (multiplicidad,
repeticin de valores, etc.), y sobre los vrtices y los arcos de los grafos. Por ltimo, se presentar
cmo se describen las reglas de verificacin de la consistencia dentro de cada EE.CC y entre
EE.CC.
A) Formato de los elementos de conceptualizacin a especificar
Cada EC que se puede utilizar en la conceptualizacin de ontologas concretas, ser de uno de los
siguientes tipos:
A. Tablas. Que a su vez pueden ser:
A.1. Tablas horizontales. La primera fila tiene el nombre de los campos, y el resto de las filas
tienen el contenido de estos campos, segn se muestra en el ejemplo de la Tabla 4.1.
En una celda puede haber ms de un valor.
Nombre_campo_l
Nombre_campo_2
Nombre_canipo_3
Trmino_l
Trmino_2
Trmino_3
Trmino 4
Trmino 5
Trmino 5
Trmino 7
Trmino 8
Trmino 9
Tabla 4.1. Disposicin de los campos en las tablas horizontales
A.2. Tablas verticales. Tienen dos columnas, la primera para los nombres de los campos, y
la segunda para los valores que toman esos campos. Cuando se est conceptualizando
75
una ontologa concreta, se puede utilizar ms de una tabla vertical del mismo tipo
(vanse los ejemplos de la Tabla 4.2, y de la Tabla 4.2).
Nombre_campo_l
Trmino 1
Nombre_campo_2
Trmino 2
Nombre_cainpo_3
Trmino 3
Tabla 4.2. Formato de una tabla vertical
Nombre_campo_l
Trmino 4
Nombre_canipo_2
Trmino 5
Nonibre_cainpo_3
Trmino 6
Tabla 4.3. Formato de una segunda tabla vertical del

mismo tipo que la Tabla 4.2
B. Grafos. Un grato es un conjunto de vrtices, y un conjunto de arcos unidireccionales que

define una relacin binaria entre vrtices (Figura 4.7). Puede haber distintos tipos de arcos, y
distintos tipos de vrtices, que se utilizan para hacer una presentacin ms clara del grafo.
Arco de tipo 1
Arco de tipo 2
Vrtice de tipo 1
Vrtice de tipo 2
Figura 4.7. Dibujo de un grafo

B) Formatos de los campos, los vrtices y los arcos
En este apartado se describen, de manera intuitiva, los formatos de los campos de las tablas, tanto
76
Miariano Fernndez Lpez
horizontales como verticales, y los formatos de los vrtices y los arcos de los gratos. Por otra parte,
en el anexo III se encuentra una descripcin formal de estos formatos basada en gramticas libres
del contexto.
B. 1)
Formatos de los campos de las tablas
Cada valor que haya en una celda de un campo de una tabla, bien sea horizontal, bien sea vertical,
debe ajustarse a uno de los siguientes formatos:
a. Descripcin: se utiliza generalmente para explicaciones con un nmero grande de caracteres
en lenguaje natural. En una descripcin, se puede utilizar cualquier cadena de caracteres
ANS
de la tabla 850 comprendidos entre 32 y el 254, ambos inclusive [DOS, 91].
b. Texto: es como el formato descripcin; pero el texto est limitado a 255 caracteres. Se
distingue entre campos con esta limitacin y campos que no la tienen, pues, en caso de
tener campos que puedan tomar valores de gran longitud, no se podrn hacer
comparaciones entre distintos valores de estos campos, ya que requerirn muchos recursos.
Se utiliza para anotaciones cortas en lenguaje natural, por ejemplo, referencias a la
bibliografa.
c. Trmino: se utiliza para el vocabulario a describir en la ontologa y para trminos importados
de otras ontologas. Un trmino empieza por una letra, y puede contener letras, dgitos o
espacios.
d. Variable: su formato es igual que el de trmino; sin embargo, el formato variable es utilizado
generalmente para las variables de expresiones lgicas.
e. Cardinalldad es til para restringir, inferior y superiormente, el nmero de elementos de una
coleccin que pueden estar asociados a cada elemento de otra. La cardinalldad puede ser
(0,1),(1,1),(0,n)(1,n).
f. Expresin aritmtica, es el ms adecuado para las operaciones matemticas. Se pueden
usar los operadores de multiplicacin, divisin, suma y resta, y se puede hacer referencia a
cualquier funcin matemtica. Segn este formato, para representar expresiones aritmticas,
se utiliza notacin infija. Un ejemplo de expresin aritmtica puede ser
expt(x, y) + 3* sin(x)
donde expt(x, y) es x'.
g. Expresin lgica. Permite construir expresiones en lgica de primer orden utilizando los
operadores de negacin, conjuncin, disyuncin, implicacin, doble implicacin, adems del
cuantificador universal y el existencial. Un ejemplo de expresin lgica puede ser:
77
forall (x) (ion_qumico(x) and carga (x, positiva) ->

exists(y) (natural(y) and estado_de_oxidacin (x,y) and (y>0)))
h. Intervalo de valores, se utiliza para especificar un valor mnimo y otro mximo. Se puede
tener, por ejemplo, el intervalo de valores (2 * kilgramo, 5 * kilogramo).
i. Enumeracin, es til para definir tipos de valores con un nmero pequeo de valores
posibles, como es el caso del tipo da de la semana. Un ejemplo de enumeracin puede ser
[lunes, martes, mircoles, jueves, viernes, sbado, domingo].
B.2)
Formato de los vrtices y de los arcos de los gratos
Los identificado res de los vrtices (por ejemplo, vrtice 1, en la Figura 4.7) y de los arcos (por
ejemplo, arco 1) siguen el formato trmino de las tablas.
C) Propiedades que hay que definir sobre los elementos de conceptualizacin
En este apartado se describirn las propiedades que hay que definir en un meta-modelo sobre los
campos de las tablas, as como las caractersticas que hay que definir cuando se crean gratos.
C. 1)
Propiedades sobre los campos de las tablas
Las caractersticas que hay que considerar a la hora de definir cada campo de un EC tabular son
las siguientes:
1. Si el campo es principal. Son campos principales aquellos que se pretende que sirvan para
identificar cada fila de la tabla (si la tabla es horizontal), o cada tabla entre varias del mismo
tipo (si la tabla es vertical). Sobre los campos principales, se deben satisfacer las siguientes
condiciones:
a)
Todos los campos principales tienen que tomar valores en todas las filas (o en todas las
tablas si se trata de un tipo de tabla vertical).
b)
En ninguna celda de un campo principal puede haber varios valores.
c)
No puede haber combinaciones de valores repetidos de los campos principales en

distintas filas (o en distintas tablas, si stas son verticales).
Por ejemplo, si en la definicin de una tabla horizontal con: campo 1, campo 2, ..., campo
n, se establece que son principales el campo y el campo 2, entonces se puede decir que la
Tabla 4.4 se ha rellenado respetando esta definicin, pues (a) el campo y el campo 2
toman valores en todas las celdas, (b) no hay mltiples valores en ninguna celda de estos
campos y (c) no se repiten combinaciones de valores de los campos principales en
diferentes filas. En el caso de tener definido un tipo de tablas verticales, tambin con: campo
78
Miiriano Fernndez Lpez
1, campo 2, ..., campo n, si se establece que son principales el campo y el campo 2,

entonces se puede decir que las tablas verticales de la Figura 4.8 se han rellenado
respetando esta definicin, pues no hay celdas vacas para estos campos, no hay celdas
con varios valores, y la combinacin de valores de los campos principales es asimismo nica
y, en consecuencia, estos valores permiten identificar una tabla entre las dems del mismo
tipo.
Principales
ii
campo 1
1
campo 2
3
campo 3
5
campo 4
4
7
3
3
5
6
8
Tabla 4.4. Ejemplo de tabla horizontal con dos campos principales
Principales
Campo 1
Campo 1
Campo 1
Campo 2
Campo 2
Campo 2
Campo 3
Campo 3
5
7
6
Campo 3
8
9
Campo 4
Campo 4
3
5
Campo 4
Figura 4.8. Ejemplos de tablas verticales del mismo tipo con dos campos principales
2. Si el campo est asociado a otro (aplicable slo a tablas horizontales). En algunos casos,
hay parejas de campos asociados, en las que, dentro de la misma fila, existe una relacin
entre valores de ambos campos. Para establecer esta relacin de valores, no slo hay que
definirla en el meta-modelo indicando que ambos campos estn asociados, sino que,
adems, cuando se rellene la tabla en la conceptualizacin de una ontologa concreta, ser
necesario poner los valores de un campo alineados con los del otro. As, por ejemplo, si se
define una tabla con campo 1, campo 2 y campo 3, y se establece que el campo 3 est
asociado con el campo 2, entonces la Tabla 4.5 se ajusta a la definicin, pues cada valor del
campo 3 est alineado con un valor del campo 2.
79
Asociados
Campo 1
Caibpo 2
Canijo 3
3
4
5
4
4
3
4
6
2
1
Tabla 4.5. Tabla con campos asociados
3. La multiplicidad mnima y mxima. Es la cantidad mnima y mxima de valores con los que
puede ser rellenado un determinado campo en cada tabla. Por ejemplo, la Tabla 4.5 se
ajusta necesariamente a una definicin en que el campo 2 y el campo 1 deben tener
multiplicidad n, mientras que el campo 1 tendr multiplicidad 1.
4. Posible repeticin. Si se trata de un tipo de tabla horizontal, con esta propiedad se establece
si el campo puede tomar un mismo valor en varias filas distintas de la misma tabla. Por
ejemplo, la Tabla 4.5 se ajusta necesariamente a una definicin de un EC tabular en que los
valores del campo 2 pueden repetirse pues, de hecho, tanto en la primera fila de esta tabla
como en la segunda, uno de los valores del campo 2 es 4.
Por otra parte, si la posible repeticin se define sobre un tipo de tabla vertical, con esta
propiedad se establece si el campo puede tomar un mismo valor en varias tablas del mismo
tipo. Por ejemplo, las tablas de la Figura 4.8 se ajustan necesariamente a una definicin de
un EC tabular en que los valores del campo 1 se pueden repetir y, de hecho, el valor 1 se
repite en la primera y en la ltima tabla de la figura.
C.2)
Propiedades sobre los tipos de vrtices y los tipos de arcos de los gratos
Se pueden definir las siguientes propiedades:

1. Los tipos arcos que pueden entrara cada vrtice de un determinado tipo. Por ejemplo, el
grafo de la Figura 4.7 se ajusta necesariamente a un tipo de grafo en que a cualquier
vrtice de tipo 1 puede entrar un arco de tipo 1.
, 2. Los tipos arcos que pueden salir de cada vrtice de un determinado tipo. Por ejemplo, el
grafo de la Figura 4.7 se ajusta necesariamente a un tipo de grafo en que de cualquier
vrtice de tipo 1 puede salir un arco de tipo 2.
3. La multiplicidad de entrada de los arcos en los vrtices, es decir, cuntos arcos de cada
tipo pueden entrar en cada tipo de vrtice. Por ejemplo, el grafo de la Figura 4.7
pertenece necesariamente a un tipo de grafo en que la multiplicidad de de entrada de los
arcos de tipo 1 en los vrtices de tipo 1 es n, pues varios arcos de tipo 1 pueden entrar en
80
Miriano Fernndez Lpez
Captulo 4, Descripcin detallada de la solucin
un vrtice concreto de tipo 1.

4. La multiplicidad de salida, es decir, cuntos arcos de cada tipo pueden salir de un vrtice
que se ajuste a un determindado tipo de vrtice. Por ejemplo, el grafo de la Figura 4.7
pertenece necesariamente a un tipo de grafo en que la multiplicidad de de salida de los
arcos de tipo 1 con origen en los vrtices de tipo 2 es n, pues varios arcos de tipo 1
pueden salir de en un vrtice concreto de tipo 2.
D) Reglas de la verificacin de la consistencia

Dado que los conocimientos aparecen distribuidos en distintos EE.CC, para que la informacin que
contiene un EC est relacionada con la informacin de otro EC, es necesario que los valores de
ciertos campos (o vrtices) de ambos EE.CC sean valores iguales o contenidos unos en otros. Por
ejemplo, supngase que existe un tipo de tabla T1 y un tipo de tabla T2; supngase tambin que la
tabla horizontal de la Figura 4.9 es del tipo T1 y que las tablas verticales de dicha figura son del
tipo T2; y supngase que se ha establecido una regla de verificacin de la consistencia en que se
exige que los valores del campo 3 de cualquier tabla del tipo T1 estn en el campo C de las tablas
del tipo T2. Entonces, las tablas de la Figura 4.9 satisfacen dicha regla de verificacin de la
consistencia, pues los valores de la primera celda del campo 3 son los mismos que los valores del
campo C de la primera tabla vertical, adems, el nico valor de la segunda celda del campo 3 est
dentro de los valores del campo C de la segunda tabla y, por ltimo, tambin hay coincidencia de
valores entre la ltima celda del campo 3 y el campo C de la ltima tabla.
campo 1
1
campo 2
3
campo 3
5
campo 4
4
7
3
Tabla del tipo TI
6
8
9
Tablas del tipo T2
Campo A
Campo A
Campo A
Campo B
Campo B
Campo B
Campo C
5
7
Campo C
3
4
6
Campo C
8
9
Figura 4.9. Ejemplo de relacin de elementos de conceptualizacin a travs de una regla de verificacin de la
consistencia
81
A la hora de definir formalmente estas reglas de verificacin de la consistencia, se recomienda

hacer una descripcin en lenguaje natural y, adems, para facilitar la formalizacin del esquema de
conceptualizacin, tambin es conveniente describirlas de manera formal. Ahora bien, no hay
operaciones matemticas que permitan hacer estas comprobaciones directamente para las tablas
ni tampoco para los grafos; pero s es sencillo transformar estas EE.CC en matrices, de tal manera
que las reglas de verificacin de la consistencia sean predicados que utilizan matrices u
operaciones sobre matrices (Figura 4.10). Para transformar las EE.CC de una determinada
conceptualizacin en matrices, se proponen los siguientes pasos
1. Transformacin de las tablas verticales en tablas horizontales, pues stas ltimas se
transforman en matrices de manera ms sencilla;
2. Transformacin de ios grafos en tablas horizontales; y
3. Transformacin de todas las tablas horizontales, originales y obtenidas a partir de otros
EE.CC, en matrices.
Grafos
Tablas verticales
Se expresan como
Tablas horizontales
W
Operaciones sobre matrices
Utilizan
Predicados sobre matrices
Son
Reglas de verificacin de la consistencia
Figura 4.10. Descripcin formal de las reglas de verificacin de la consistencia basndose en matrices
Estas transformaciones no se deben entender como una indicacin para el procesamiento de los
82
EE.CC, sino que se deben entender como una especificacin precisa de su significado.
En los puntos que vienen a continuacin, se mostrar cmo hacer estas transformaciones,
cules van a ser las operaciones sobre matrices que van a hacer falta para definir las reglas de
verificacin de la consistencia, la especificacin de las reglas de consistencia utilizando matrices, y
su expresividad.
D. 1)
Transformacin de tablas verticales en tablas horizontales
Un conjunto de tablas verticales del mismo tipo puede dar lugar a una tabla horizontal. Para ello
Celda columna de valores de cada tabla vertical se transforma en una fila de la tabla horizontal
(vase la Figura 4.11).
Nombre..campo_l
Tnnino 1
Nombre_campo_l
Tnnino 4
Nombre_campo_l
Trmino 7
Nombre..campo_2
Trmino 2
Nombre_campo_2
Trmino 5
Nombre_campo_2
Trmino 8
Nombre.,campo_n
Trmino 3
Nombre_campo_n
Tnnino 6
Nombre_campo_n
Tnnino 9
h
W
Nombre_campo_l
Nombre_campo_2
Nombre_campo_n
Tnnino 1
Trmino 2
Trmino 3
Tmiino 4
Trmino 5
Trmino 6
^
^
lermino
Trmino i
Trmino 9
M
^
Figura 4.11. Transformacin en una tabla horizontal las tablas verticales del mismo tipo
D.2)
Transformacin de los grafos en tablas horizontales
Al igual que ocurre con las tablas verticales, los grafos tambin se pueden transformar en tablas
horizontales. Una posibilidad, la utilizada en este trabajo, consiste en generar una tabla con cinco
campos, y tantas filas como enlaces haya entre vrtices a travs de arcos. As (Figura 4.12), el
primer campo representar, para cada enlace, el nombre del vrtice origen; el segundo, el tipo del
vrtice origen; el tercero, el tipo de arco que une los vrtices; el cuarto, presentar el nombre del
vrtice destino; y el quinto, el tipo de vrtice destino.
D.3)
Representacin matricial de las tablas y los grafos
Cualquier tabla horizontal se puede representar como una matriz de conjuntos haciendo
corresponder cada fila de la tabla con una fila de la matriz, y cada columna de la tabla con una
columna de la matriz (Figura 4.13). En consecuencia, las tablas verticales y los grafos tambin se
pueden representar de forma matricial, pues se pueden transformar en tablas horizontales.
83
Cuando una tabla tiene cannpos asociados, su transformacin en una representacin matricial
tiene el matiz de que los valores de cada celda de un campo de los que intervienen en la
asociacin forman parte de una lista (vase la Figura 4.14), pues los valores de campos asociados
pueden estar repetidos dentro de la misma celda y, adems, es relevante el orden de los valores
en una celda de un campo asociado a otro^.
Arco de tipo 1
Arco de upo 2
Vrtice de tipo 1
Vrtice de tipo 2
Nombre del
vrtice origen
Vrtice 1
Vrtice 2
Vrtice 2
Vrtice 4
Tipo del vrtice origen
Tipo de arco
Vrtice de tipo 1
Vrtice de tipo 2
Vrtice de tipo 2
Vrtice de tipo 1
Arco de tipo 2
Arco de tipo 1
Arco de tipo 1
Arco de tipo 2
Nombre del vrtice

destino
Vrtice 2
Vrtice 1
Vrtice 4
Vrtice 3
Tipo del vrtice

destino
Vrtice de tipo 2-^
Vrtice de tipo 1 "^
Vrtice de tipo 1
Vrtice de tipo 2
Figura 4.12. Transformacin de un grafo en una tabla horizontal
Nombre_campo_l
Nombre_campo_2
Nombre_campo_n
Trmino 1
Trmino 2
Trmino 3
Trmino 4
Trmino 5
Trmino 6
Trmino 7
Trmino 8
Trmino 9
-^
Trmino 1
Trmino 2
Trmino 3
Trmino 4
Trmino 5
Trmino 6
.Trmino 7
Trmino 8
Trmino 9 .
Figura 4.13. Transformacin de una tabla horizontal en una matriz
Recuerdes que, en matemticas, los conjuntos no contienen elementos repetidos, y el orden de los elementos
es indiferente en la definicin de un conjunto.
84
Asociados
Campo 1
Campo 2
Campo 3
3
4
5
4
4
3
4
6
2
1
~\
(1)
([3,4,5])
{[4,4,3])
(2}
{[4,6])
{[2, 1])
V.
Figura 4.14. Transformacin de una tabla de con campos asociados en una matriz
D.4)
Operaciones sobre
matrices
A continuacin se define una serie de operaciones sobre matrices de conjuntos que sern tiles
para definir propiedades de los EE.CC y mantener la consistencia:
1. Unin de matrices. La unin de dos matrices M^ y M2 con n columnas da lugar a otra matriz
/W3 con n columnas tal que sus primeras filas son las filas de /W,, y las restantes son las de
A2 que no estn en M^. El orden en que estn las filas en /Wi y M2 se conservar en M3. La
notacin utilizada ser Ai unin M2. Un ejemplo es el de la Figura 4.15.
r {1}
Mi =
{3,4}
^{2}
{3}
{5,7}^
{2}
{3}
{5,6}
{6, 8,_gy
M3 = M^ unin M2 =
{3}
M2 =
{3,4}
{2}
Vi?, 3}
{8}
{1}
{3}
{5,7}
{3,4}
{2}
{3}
{2}
{5, 6}
{6, 8, 9}
{2}
{3}
{5}
{2,3}
{8}
(6,8}
{3}
{6,8X/
Figura 4.15. Unin de dos matrices de conjuntos
85
2. Proyeccin ordenada. La proyeccin ordenada de una matriz M sobre una serie de columnas
/i, 2,..., k es otra matriz cuyas columnas son la ii-sima, la 2-sima,..., la ik-sima de M en
el mismo orden en que aparecen en la serie. La notacin de esta operacin ser
M./i, M.2,..., M.k
pudiendo ir entre corchetes el nombre de la matriz o el nmero de las columnas si esto
facilita la legibilidad. En la Figura 4.16, se presenta un ejemplo de proyeccin en que se
construye la matriz Mt al tomar la columna 3 de Mi y la columna 1 de Mz-
(^
M4 = Mi.[3], M2.[1] =
{5, 7}
{2}"^
{3}
{3,4}
^ { 6 , 8, 9}
{2, 3 ) y
Figura 4.16. Proyeccin ordenada en una matriz de conjuntos
3. Seleccin. La seleccin en la matriz Mi con la propiedad P es otra matriz M5 que contiene

aquellas filas de yWi que cumplen P. Se puede ver un ejemplo en la Figura 4.17.
^{1}
{3}
{5,7}~\
r
Mi =
{3,4}
{2}
{3}
{2}
{5,6}
{6,8,9}
M5 =
{3,4}
{2}
{3}
J
Figura 4.17. Seleccin en M\ con la propiedad M\.[2] - {2}
Adems de estas operaciones, tambin se definen los siguientes predicados:

1. Inclusin de filas. Se dice que una fila (Conj^ ConJ2, ..., Conjn) de una matriz de conjuntos
est incluida en la fila (Conj^, Conj'2
Conj'n), de la misma o de otra matriz, si y slo si
cada Con}, est incluido en cada ConJ,. Por ejemplo, la segunda fila de la matriz Mi de la
Figura 4.18, es decir, ({3, 4}, {2}, {3}), est incluida en la en la tercera fila de la matriz Me de
la misma figura, es decir, ({3, 4}, (2), {3, 4, 5}).
2. Inclusin de matrices. Se dice que una matriz Mi est incluida en otra Me si y slo si toda fila
de Mi est incluida en al menos una de Me. Esta operacin se escribe como Mi is included in
86
MQ. En la Figura 4.18 aparece un ejemplo de inclusin de matrices. Se puede observar que
la primera fila de /Wi est incluida en la segunda de MQ, que la segunda de /Wi est incluida
en la tercera de M^, y la tercera de /Wi est incluida en la primera de /I4.
^{1}
{3,4}
Mi =
\^{2}
{3}
{5,7}"^
{2}
{5, 6}
{6, 8, 9}
{1}
{3}
{5,7}
{3, 4}
{2}
{3, 4, 5}
{1}
{4}
{6}
Ms =
{3}
{5,6}
{2}
{6,8,92^
Figura 4.18. M\ est incluida en M4
D.5)
Especificacin de las reglas de consistencia mediante la representacin

matricial
Una manera formal de expresar las reglas de consistencia de los EE.CC es a travs de inclusiones
de matrices, haciendo referencia a la representacin matricial de los EE.CC. Por ejemplo (Figura
4.19), si se desea expresar que todos los valores del campo 3 de cualquier tabla de tipo TI tienen
que estar en el campo Cde una tabla de tipo T2, se podr escribir de siguiente manera:
T1.[campo 3] is included in T2.[campo C]
TI .[campo 3] is included in
T2.[campo C]
campo 1
campo 2
campo 3
5
7
3
campo 4
4
3
Tabla del tipo TI
6
1
9
Tablas del tipo 72
Campo A
Campo A
Campo A
Campo B
Campo B
Campo B
Campo C
5
7
Campo C
3
4
6
Campo C
8
9
Figura 4.19. Ejemplo de regla de verificacin de la consistencia con su descripcin formal
87
Se Utiliza el ingls porque es el lenguaje qu se suele utilizar como lengua franca en los
proyectos internacionales, consiguientemente, es el idioma que permite una mejor comunicacin
entre las personas que intervienen, de una manera u otra, en la conceptualizacin.
En lo referente a la operacin de seleccin, slo se van a definir reglas formales con
selecciones para gratos, que es para lo que hasta ahora se ha utilizado esta operacin. Adems,
esta operacin siempre va ir acompaada de una proyeccin ordenada. La sintaxis que se va a
seguir, descrita de manera formal a travs de una gramtica libre del contexto en el anexo IV, es la
que se presenta a continuacin:
1. Grafo.TA.out.TV
para indicar que hay que seleccionar en la matriz del Grafo aquellas filas tales que
Tipo de arco] =TAy Tipo del vrtice origen] = TV
y que despus hay que proyectar sobre Nombre del vrtice origen; y
2. Grafo.TA.in.TV
para indicar que hay que seleccionar en la matriz del Grafo aquellas filas tales que
[Tipo de arco] =TAy Tipo del vrtice destino] = TV
y que despus hay que proyectar sobre Nombre del vrtice destino.
As, por ejemplo, una regla que diga: "en un grafo de tipo G, cualquier trmino que aparezca en un
vrtice de tipo Vdel que sale un arco de tipo A tiene que aparecer en el campo C de una tabla del
tipo T se puede expresar como:
G.A.out.Vis includedin T.C
En consecuencia, el grafo y la tabla de la Figura 4.20 satisfacen la regla.
88
Vrtice de tipo V
Arco de tipo A
Arco de tipo A
Vrtice de tipo V
5
1
7
3
3^-1^2
6
1
Tabla del tipo T
Figura 4.20. Ejemplo de una regla de verificacin de la consistencia de un grafo con una tabla
D.6)
Limitaciones en la expresividad de la descripcin formal de las reglas de

verificacin de la consistencia
Mediante la experiencia elaborando regias de verificacin de la consistencia para distintos

esquemas, se han identificado cuatro motivos para que una regla no se pueda expresar de manera
formal siguiendo la gramtica anterior. Estos motivos son los siguientes:
i)
La regla contiene una condicin. Por ejemplo, no se puede expresar de manera forma! la
regla que dice: "si la relacin inversa de una tabla de relaciones aparece en el glosario de
trminos, entonces tiene que aparecer en el campo 'nombre de la relacin' en otra tabla de
relaciones". Ntese que la comprobacin de si la relacin inversa tiene una tabla de
relaciones propia se hace dependiendo de si se da o no una determinada condicin.
ii)
La regla menciona una subcadena del valor del campo. Por ejemplo, la regla que dice: "en
una tabla de axiomas lgicos, cualquier constante de las que haya en el campo 'constantes
referidas' debe aparecer en la expresin del axioma". Obsrvese que una constante que
aparezca en la expresin del axioma ser una subcadena de dicha expresin.
iii)
La regla asume herencia. Por ejemplo, la regla que dice: "si en una tabla de atributos de
instancia aparece A como el nombre del atributo y C como el concepto, entonces A tiene
que aparecer en el diccionario de conceptos como uno de los atributos correspondientes al
89
concepto C o a una de sus superclases". Obsrvese que se asume que los atributos de un
concepto son aquellos que aparecen explcitamente como tales en el diccionario de
conceptos, y los que hereda de sus superclases.
iv)
La regla contiene una negacin. Un ejemplo puede ser la regla que dice: "si un atributo A^
sirve para deducir otro/A2, entonces/42 no sirve para deducir A " . .
A pesar de estas limitaciones, la experiencia ha mostrado que este mecanismo s permite

representar la inmensa mayora de las reglas necesarias para hcer una buena verificacin.
4.3.1.3.3 Documentacin generada en la tarea de elaboracin desde cero de

un meta-modelo
La documentacin generada al especificar un meta-modelo en el nivel de conocimientos con tablas
y gratos es la que se presenta a continuacin:
1. Ficha de descripcin general del meta-modelo. Debe contener:
a) El nombre del meta-modelo;
b) La fecha de la versin y variante actual,
c) Los autores;
d) descripcin del meta-modelo en lenguaje natural;
e) la bibliografa con la informacin sobre las fuentes citadas a lo largo de toda la
especificacin del modelo.
2. Glosario de EE.CC. Contendr, para cada tipo de EC, la siguiente informacin:
a) Nombre de ste.
b) Siglas que se podrn utilizar para identificarla.
c) Tipo de elemento, que puede ser tabla o grafo.
d) Descripcin en lenguaje natural.
e) Si se trata de una representacin tabular, su orientacin.
3. Diagrama de orden de EE.CC. En este grafo se establecer cundo se ha de rellenar cada
EC. Si dos EE.CC estn relacionadas a travs de una flecha, significa que la que aparece en
el origen ha de rellenarse antes que la que aparece en el destino. Si varios EE.CC estn en
el mismo nivel y no hay flechas entre ellas, entonces significa que ninguna de ellas tiene por
qu rellenarse antes que las otras.
90
4. Para cada uno de los tipos de tablas que aparecen en el glosario de EE.CC, se realizarn
las tablas que se describen a continuacin:
4.1.1. En caso de que sea necesario, una tabla de campos asociados. Habr una fila por
cada pareja de campos asociados.
4.1.2. Una tabla de descripcin de campos que, para cada campo, presentar las siguientes
caractersticas:
a) nombre del campo;
b) siglas que tambin servirn para identificar el campo;
c) descripcin en lenguaje natural. El smbolo "**" se utilizar para campos que ya
queden bien definidos con su nombre;
d. formato con el que tiene que ser rellenado (descripcin, texto, expresin aritmtica,
etc.);
e) una indicacin informando sobre si el campo es principal, o no;
f) multiplicidad mnima y mxima;
g) posible repeticin en la misma tabla si se trata de una tabla horizontal; y
h) posible repeticin del valor del campo en otras tablas del mismo tipo si se trata de
tablas verticales.
5. Para cada tipo de grafo, se elaborarn las siguientes tablas:
5.1. Una tabla de descripcin de arcos que contenga, para cada tipo de arco (tipo de arco),
la siguiente informacin:
a) su nombre;
b) sus siglas; y
c) su descripcin en lenguaje natural.
5.2. Una tabla de descripcin de vrtices con la siguiente informacin para cada tipo de
vrtice:
a) el nombre del tipo vrtice que se est describiendo;
b) las s/f/as;
c) la descripcin;
91
d) los tipos arcos que pueden entrar o salir de un vrtice que se ajuste a este tipo;
e) \a multiplicidad de entrada e estos arcos; ^
f) La multiplicidad de salida.
6. Dos tablas de reglas de verificacin de las referencias cruzadas por cada EC, una para las
referencias dentro de la misma EC, y otra para las referencias a otras EE.CC. La informacin
a considerar para cada regla de verificacin de la consistencia ser la siguiente:
a) Nombre con que se va a identificar la regla.
b) Campos y arcos fuentes en la regla, es decir, los campos de las tablas y los arcos de los
grafos cuya informacin hay que buscar en el mismo o en otros EE.CC para ver si se
verifica la regla.
c) Descripcin en lenguaje natural de la regla.
d) Descripcin formal de la regla segn se describe en 4.3.1.3.2D).
Las dos normas fundamentes que se hian de seguir a la hora de especificar reglas de
consistencia son:
a) mnima redundancia; y
b) las comprobaciones se deben hacer entre EE.CC lo ms cercanos posible dentro del
orden de la metodologa.
7. Cuando ya se han hecho varias tablas de verificacin de la consistencia, se debe hacer un
grafo de reglas de verificacin de la consistencia que relacione los EE.CC de tal manera que
tiene que haber un arco de cualquier elemento de conceptualizacin EC-\ a otro EC2 si y slo
si algn valor de EC^ tiene que estar en algn campo o vrtice de EC2. Este grafo servir
para tener una idea global de las dependencias entre EE.CC.
4.3.1.4
PROCESO PARA LLEVAR A CABO LA TAREA
Los pasos para realizar la conceptualizacin del esquema de conceptualizacin son los que se
presentan en el diagrama de GANTT de la Figura 4.21. En esta figura, si una flecha une el principio
de un paso con el principio de otro, entonces el primero se debe empezar a hacer antes que el
segundo. Adems, si el final de un paso est ms a la izquierda que el final de otro, entonces el
primero debe acabar antes de que lo haga el segundo.
En lo concerniente al orden en que se van describiendo los EE.CC, se recomienda el orden en
que aparezcan en el diagrama de orden, de esta manera, es fcil tener una visin global de lo ya
92
especificado, y es ms sencillo ir definiendo las reglas de verificacin de la consistencia a la vez

que se especifican los EE.CC.
4.3.1.5
QUINES TIENEN QUE LLEVAR A CABO LA TAREA
La conceptualizacin del esquema de conceptualizacin la tiene que llevar a cabo una persona
entendida en conceptualizacin, aunque es conveniente que las personas encargadas de
conceptuaiizar el dominio participen dando su opinin sobre lo intuitivas y lo fciles de manejar que
son los EE.CC.
4.3.1.6
CASO PRCTICO: DEFINICIN DE UN META-MODELO
Siguiendo la descripcin hecha en los apartados anteriores de la tarea de conceptualizacin del

esquema de conceptualizacin, en este apartado se presentar el meta-modelo correspondiente al
caso prctico de especificacin que aparece en la seccin 4.2.3.4. Recurdese que el esquema de
conceptualizacin descrito en dicha seccin es el de referencia, aunque sin la tabla de conceptoatributo de clase-valor, y sin la columna relacin de la tabla de instancias. Al igual que se ha hecho
con la especificacin, estas salvedades sobre el esquema de referencia se utilizarn para mostrar
cmo se hacen los cambios en un meta-modelo.
Por otra parte, si se desea seguir este caso prctico con ejemplos de tablas rellenas, se puede
consultar el anexo II, que contiene un ejemplo de conceptualizacin en el dominio de la qumica
con el esquema de referencia. En consecuencia, la nica variacin que notar el lector sern las ya
comentadas en el prrafo anterior.
4.3.1.6.1
Creacin de la ficha de descripcin general del meta-modelo
La ficha de descripcin general del meta-modelo de caso prctico es la que se presenta en la

Tabla 4.6.
4.3.1.6.2
Creacin del glosario de elementos de conceptualizacin
El glosario de EE.CC se muestra en la Tabla 4.7. Se recomienda su examen a la vez que se

examina el grafo presentado en el siguiente apartado (Figura 4.22).
4.3.1.6.3
Creacin del diagrama de orden de elementos de

conceptualizacin
En la Figura 4.22 se muestra el diagrama con el orden de los EE.CC para el meta-modelo del caso
prctico.
93
Hacer ficha de
descripcin general
del esquema
Comienza antes que
Hacer glosario de
representaciones
intermedias
Hacer diagrama de
orden de
representaciones
intermedias
Para cada esquema de tabla
Hacer tabla de
descripcin de
campos
Hacer tabla de
campos asociados
Para cada esquema de grafo
Hacer tabla de
descripcin de
arcos
Hacer tabla de
descripcin de
vrtices
Tablas de reglas de
verificacin dentro
de cada RI
Tablas de reglas de
verificacin entre
EE.CC
Grafo de reglas de
verificacin de la
consistencia
Figura 4.21. Mtodo para especificar meta-modelos utilizando tablas y grafos
94
Nombre del meta-modelo
Esquema 6
Fecha de la versin actual
Julio de 1998.
Autores
Mariano Fernndez Lpez en colaboracin con Asuncin Gmez Prez, Mercedes Blzquez Cvico
y Juan Manuel Garca Pinar, que han documentado las reglas de verificacin de la consistencia en
[Blzquez, 97] y en [Garca Pinar, 98] respectivamente.
Se ha elaborando en el Laboratorio de Inteligencia Artificial (LIA) de la Facultad de Informtica (FI)
de la Universidad Politcnica de Madrid (UPM) la metodologa utilizada en el LIA para desarrollar
sistemas basados en conocimientos. Se ha comprobado su validez construyendo ontologas en
distintos dominios. Entre las ms relevantes se encuentran:
1. CHEMICALS [Fernndez, 96], [Gmez-Prez et al.; 96], [Femndez-Lpez et al.; 99], que
contiene conocimientos dentro del domino de los elementos qumicos y las estructuras
cristalinas.
2.
La Reference-Ontology [Arprez et al.; 98], una ontologa en el dominio de las ontologas que
juega el papel de una especie de pginas amarillas de ontologas. Recoge, describe y tiene
enlaces a ontologas ya disponibles, utilizando una organizacin lgica comn.
3.
La versin re-estructurada de la ontologa (KA)^ [Blzquez et al.; 98], que contiene

conocimientos sobre la comunidad cientfica en el campo de la INCO, en concreto: cientficos,
temas de investigacin, proyectos, universidades, etc.
Descripcin
Estas ontologas se han utilizado para construir aplicaciones, concretamente:
I.
(Onto)^gent [Arprez et al.; 98]. Un agente WWW sobre ontologas que utiliza la ReferenceOntology como una fuente de su conocimiento y recoge descripciones de ontologas que
satisfacen un conjunto de restricciones dado. (Est disponible en http://delicias.dia.fi.upm.es/
OntoAgent).
Chemical OntoAgent [Arprez et al.; 98]. Un agente WWW que facilita a los estudiantes el
aprendizaje de la qumica y la evaluacin de sus conocimientos. Una de sus fuentes de
conocimientos es CHEMICALS.
Ontogeneration [Aguado et al.; 98]. Es un sistema que utiliza una ontologa de dominio
(CHEMICALS) y otra lingstica (GUM [Bateman et al.; 95]) para generar texto en espaol
como respuesta a preguntas sobre qumica realizadas por estudiantes.
Bibliograa
(La bibUografa referenciada est al final de esta memoria).

T a b l a 4 . 6 . F i c h a d e descripcin general del m e t a - m o d e l o del c a s o prctico
M t o d o flexible p a r a la c o n c e p t u a l i z a c i n d e ontologas b a s a d o en m e t a - m o d e l o s
95
Nombre del elemento de

conceptualizacin
rboles de clasificacin de atributos
rbol de clasificacin de conceptos
AC
ACC
Tipo de
elemento
Grafo
Grafo
Diagrama de relaciones
DR
Grafo
--
Diccionario de conceptos
DC
Tabla
Horizontal
Ficha de descripcin general
FDG
Tabla
Vertical
Glosario de trminos
GT
Tabla
Horizontal
Tabla de trminos a importar
TTI
Tabla
Horizontal
Tabla de constantes
TC
Tabla
Horizontal
Tabla de instancias
TI
Tabla
Horizontal
Tablas de atributos de clase
TAC
Tabla
Vertical
Tablas de atributos de instancia
TAI
Tabla
Vertical
Tablas de axiomas lgicos
TAL
Tabla
Vertical
Tablas de frmulas
TF
Tabla
Vertical
Tablas de relaciones binarias
TR
Tabla
Vertical
Siglas
Descripcin
Urientacin
Muestran grficamente cmo se pueden obtener unos atributos a partir de otros o de constantes utilizando frmulas.
Organiza los conceptos segn las relaciones: subclase de, subclase en una particin disjunta, subclase en una particin exhaustiva, etc.
Contiene todas aquellas relaciones binarias que tengan origen en algn concepto de la ontologa que se est construyendo. Este diagrama
proporciona una gua para integrar ontologas, ya que si el concepto C est relacionado mediante la relacin R con el concepto C2 que est en
otra ontologa, entonces la ontologa que se est desarrollando deber incluir la ontologa que contiene C2. Haciendo una adaptacin de la
propuesta de Guarino [Guarino, 92], se considerarn relaciones binarias los papeles relacinales que desempeen las instancias (trabaja en,
emplea a, etc.), las relaciones de agregacin (por ejemplo, es parte de) y las relaciones de abstraccin y sus inversas (por ejempo, es superclase
de 0 es subclase de). stas ltimas se representarn en el rbol de clasificacin de conceptos en vez de hacerlo en el diagrama de relaciones
binarias. Sin embargo, las etiquetas (por ejemplo, el nombre), las cualidades (color, altura, etc.), los papeles y los trminos booleanos, es decir,
los que pueden tomar valor verdadero o falso (por ejemplo, vuela, tiene plumas, etc.), se considerarn atributos.
Contiene todos los conceptos que aparezcan en el rbol, sus instancias, sus atributos de clase y de instancia, las relaciones binarias en las que
dichos conceptos estn como origen, y los sinnimos y abreviaturas. Los atributos de instancia son aquellos que sirven para describir instancias
particulares, por ejemplo el peso es especfico de cada persona; por otra parte, los atributos de clase describen los conceptos de forma global, por
ejemplo la edad mxima de jubilacin en los distintos oficios y profesiones hace referencia a conceptos, no a instancias particulares de stos.
Tendr la siguiente informacin: el nombre de la ontologa; la hora y la fecha de creacin; los autores; y un campo de descripcin con el
propsito, una visin general de la misma y las fuentes utilizadas.
Incluye, con sus descripciones, los conceptos, las instancias, las relaciones, los atributos y las constantes.
Contiene el nombre de cada trmino importado, la ontologa a que pertenece, el servidor en que se encuentra, y el nombre que recibe en la nueva
ontologa.
Para cada constante especifica su nombre, el tipo de valor, el valor, la unidad de medida, los atributos que se pueden deducir a partir de ella, y las
referencias.
Para cada una de las instancias del diccionario de conceptos, incluir: el nombre de la instancia, los atributos con los valores conocidos en la
instancia, y los valores que toman dichos atributos.
Por cada uno de los atributos de clase del diccionario de conceptos, deber haber una tabla con: el nombre del atributo, el concepto al que
pertenece, el tipo de valor, la unidad de medida, la precisin, la cardinalidad, los atributos de instancia que pueden ser deducidos a partir de l, y
las referencias a las fuentes de donde se han obtenidos los conocimientos relativos al atributo.
Por cada uno de los atributos de instancia que aparezcan en el diccionario de conceptos, debe haber una tabla con: su nombre; el concepto al que
pertenece; el tipo de valor; la unidad de medida si es un atributo numrico; la precisin en caso, tambin, de valores numricos; el intervalo de
valores; el valor por defecto; las cardinalidades mxima y mnima; los atributos de instancia, de clase y constantes que se utilizan para deducir su
valor; los atributos que pueden ser deducidos utilizando el valor del atributo que se est definiendo; las frmulas que se pueden utilizar para
hallar el valor del atributo; y las referencias utiUzadas para describirlo.
Los axiomas lgicos describen los conceptos a travs de expresiones en lgica de primer orden. Sus campos sern: el nombre del axioma; la
descripcin en lenguaje natural; el concepto que describe; los atributos, relaciones, constantes y variables que intervienen en la expresin; la
expresin en lgica de primer orden; y las referencias a las fuentes.
Por cada frmula de las que aparezcan en las tablas de atributos de instancia se elaborar una tabla con los siguientes campos: el nombre, el
concepto al que se refiere, el atributo que deduce, la expresin de la frmula, la descripcin en lenguaje natural, los atributos y las constantes que
intervienen, la precisin, las restricciones para aplicarla (es una expresin en lgica de primer orden), y las referencias.
Para cada relacin de las que aparecen en el diccionario de conceptos, se construir una tabla con: su nombre, el nombre del concepto origen, la
cardinalidad del origen, el concepto destino, las propiedades matemticas (propiedad transitiva, reflexiva, etc.), la relacin inversa y las
referencias a las fuentes utilizadas. Obsrvese que tanto el concepto destino como la relacin inversa pueden ser trminos de otra ontologa; en
ese caso, hay que importar la ontologa a la que pertenezcan.
Tabla 4.7. Glosario de elementos de conceptualizacin del meta-modelo del caso prctico
96
Ficha de
descripcin
general
ir
Lista de
trminos a
importar
Glosario
de
trminos
rbol de
clasificacin
de conceptos
Diagrama de
relaciones
Diccionario
de conceptos
Tablas de
relaciones
Tablas de
atributos
de clase
Tablas de
atributos de
instancia
Tablas de
axiomas
lgicos
Tabla de
constantes
Tablas de
frmulas
rboles de
clasificacin
de atributos
Tabla de
instancias
Figura 4.22. Diagrama de orden de los elementos de conceptualizacin
4.3.1.6.4 Creacin de las tablas de descripcin detallada de elementos de

conceptualizacin y de reglas de verificacin
Se presentan, en los siguientes apartados, las tablas de descripcin de los campos que
aparecen en los EE.CC tabulares del esquema de referencia, las tablas de descripcin de los
arcos de los EE.CC grficas, las tablas de descripcin de vrtices y las tablas de referencias
97
cruzadas de todas los EE.CC, segn la documentacin descrita en la seccin 4.3.1.3.3.
A) Ficha de descripcin general

La Tabla 4.8 presenta la conceptualizacin de un glosario de trminos.
Nombre
Siglas
Nombre
Fecha y hora de
creacin
FH
Autores
Descripcin
Formato
Descripcin
**
'
El momento en el que se ha
empezado a conceptualizar la
ontologa
Quines intervienen en el
desarrollo de la ontologa
Se explica el propsito, se
muestra una visin general de
la ontologa y las fuentes de
conocimientos utilizadas
Repeticin en la
misma tabla
No
No
No
(1,1)
No
No
(1,1)
No
No
(1,1)
Es principal
Identificador
Descripcin
Descripcin
Multiplicidad
(1,1)
Descripcin
Tabla 4.8. Tabla de descripcin de campos de la ficha de descripcin general
B) Glosario de trminos
La Tabla 4.9 presenta la conceptualizacin de un glosario de trminos. Adems, la Tabla 4.10
presenta la conceptualizacin de las reglas de verificacin de la consistencia del glosario de
trminos con otros elementos de la conceptualizacin.
Campo
Descripcin
Siglas
Nombre
Descripcin
**
Descripcin en lenguaje
natural
Formato
Es principal
Identificador
Repeticin en la
misma tabla
No
No
No
Descripcin
Multiplicidad
(1,1)
(1,1)
Tabla 4.9. Tabla de descripcin de campos del glosario de trminos
Nombre
Regla GT-1
Campo fuente
Nombre
Descripcin en lenguaje natural

Cualquier nombre de un trmino del glosario debe
estar en la tabla de constantes, o en el diccionario
de datos en uno de los siguientes campos: nombre
del concepto, instancias, atributos de clase.
atributos de instancia, relaciones binarias.
Descripcin formal
GT.nombre is included in
(DC.NC unin
DC.I unin
DC.AI unin
DC.AC unin
DC.R unin
TC.NC)
Tabla 4.10. Tabla de reglas de verificacin del glosario de trminos con otros elementos de
conceptualizacin
C) Tabla de trminos a importar

La Tabla 4.11 presenta la conceptualizacin de una tabla de trminos a importar. Adems, la
Tabla 4.12 presenta la conceptualizacin de las reglas de verificacin de la consistencia de la
tabla de trminos a importar con otros elementos de la conceptualizacin.
98
Ntese que tanto el nombre del trmino origen, como el nombre de la ontologa e, incluso, el
servidor son campos principales, pues puede darse el caso de poder importar el mismo
trmino, de la misma ontologa, pero de distinto servidor.
Campo
Nombre del
trmino en el
origen
Nombre de la
ontologa
Nombre del
servidor
Nombre del
trmino en el
destino
Siglas
NR
NO
NS
NT
Descripcin
Trmino que pertenece a otra
ontologa y que se utiliza en la
ontologa
que
se
est
desarrollando. En este campo
aparece con el nombre que recibe
en la ontologa de origen.
Ontologa a que pertenece el
trmino a importar
Servidor en que se encuentra la
ontologa
Aparece el trmino con el nombre
que se le da en la ontologa que se
est construyendo.
Formato
Es principal
Repeticin
en la misma
tabla
Multiplicidad
Identicador
(1,1)
Identificador
(1,1)
Identicador
(1,1)
Identificador
No
No
(1,1)
Tabla 4.11. Tabla de descripcin de campos generales de la tabla de trminos a importar

Nombre
Regla TTI-1
Campo fuente
Nombre del trmino

en el origen

Descripcin formal
El nombre de cada trmino debe aparecer en, al
menos, uno de los siguientes campos:
concepto destino de una tabla de

relaciones binaras;
relacin
inversa de una tabla de
relaciones binarias;
tipo de valor de una tabla de atributo de

clase, de atributo de instancia, o de
TTI.NT is included in
constantes (todava no se puede expresar
(TR.CD unin TR.RI unin
de manera formal porque el trmino
TALCR unin
puede ser una subcadena del tipo de
TALAR unin
valor, por ejemplo, si el tipo de valor es
TAL.RR unin
cantidad de masa / cantidad de volumen);
TAL.CS unin
unidad de medida de una tabla de atributo

TALIR
de clase, de atributo de instancia o de
constantes (todava no se puede expresar
de manera formal porque el trmino
puede ser una subcadena dentro de la
unidad de medida).
Relacin, atributo, constante, instancia o

concepto referido en una tabla de
axiomas lgicos.
Tabla 4.12. Tabla de reglas de verificacin de la lista de trminos a importar con otros elementos de
conceptualizacin
D) rbol de clasificacin de conceptos

La Tabla 4.13 y la Tabla 4.14 presentan la conceptualizacin de un rbol de clasificacin de
conceptos. Adems, la Tabla 4.15 presenta la conceptualizacin de las reglas de verificacin
de la consistencia del rbol de clasificacin de conceptos con otros elementos de la
conceptualizacin.
Obsrvese que, segn las multiplicidades mximas de salida de los arcos, esta definicin
permite construir mltiples clasificaciones de un concepto y, por consiguiente, se da la
posibilidad de que exista herencia mltiple en el esquema de referencia.
99
Arco
Siglas
Subclase de
Subclase en una particin disjunta
SPD
Subclase en una particin exhaustiva
SPE
Descripcin
Una clase C es una subclase de la clase padre P si y slo si cualquier instancia
de C es tambin instancia de P.
Una particin disjunta de una clase es un conjunto de sudases de la misma que
no tienen instancias comunes.
Una particin exhaustiva de una clase es un conjunto de subclases que abarca
toda la clase, es decir, que no hay ninguna instancia de la clase padre que no
sea de ninguna de las subclases de la particin.
Tabla 4.13. Tabla de descripcin de arcos
Nudo'
Concepto
Siglas
C
Descripcin
**
Arcos que pueden entrar o salir

Subclase de
Subclase en una particin exhaustiva
Multiplicidades
de entrada
(0,n)
(O.n)
(0,n)
Multiplicidades
de salida
(0,n)
(0,n)
(0. n)
Tabla 4.14. Tabla de descripcin de campos de los nudos del rbol de clasificacin de conceptos
Regla
Regla ACC-1
Arco fuente
Subclase de
Subclase en una
particin disjunta
Subclase en una
particin exhaustiva
Regla ACC-1_1
Subclase de
Regla ACC-1 _2
Subclase de
Regla ACC-1_3
Subclase en una
particin exhaustiva
Regla ACC-1_4
Subclase en una
particin exhaustiva
Regla ACC-1_5
Subclase en una
particin disjunta
Regla ACC-1_6
Subclase en una
particin disjunta
Descripcin formal
Todos los nudos deben aparecer en el campo

'nombre' dentro del glosario de trminos. Las
distintas variantes de esta regla son la ACC-1_1,
ACC-1_2 y as sucesivamente hasta la ACC-1_6
Cualquier trmino que aparezca en un nudo

'concepto' del que sale un arco 'subclase de'
tiene que aparecer en el campo 'nombre' del
glosario de trminos
Cualquier trmino que aparezca e un nudo
'concepto' al que entra un arco 'siibclase de'
tiene que aparecer en el campo 'nombre' del
glosario de trminos
'concepto' del que sale un arco 'subclase en una
particin exhaustiva' tiene que aparecer en el
campo 'nombre' del glosario de trminos
'concepto' al que entra un arco 'subclase en una
particin disjunta' tiene que aparecer en el
ACC.S.out.Concepto is included in
GT.Nombre
ACC.S.in.Concepto is included in
GT.Nombre
ACC.SPE.out.Concepto is included in
GT.Nombre
ACC.SPE.in.Concepto is included i
GT.Nombre
ACC.SPD.out.Concepto is included in
GT.Nombre
ACC.SPD.in.Concepto is included in
GT.Nombre
Tabla 4.15. Tabla de reglas de verificacin en el rbol de clasificacin de conceptos con otros elementos
de conceptualizacin (1/2)
En este trabajo se ha preferido utilizar la palabra "nudo" en vez de "nodo" que es mucho ms habitual
en el lenguaje informtico. En realidad, cuando alguien que est hablando o escribiendo sobre informtica
menciona la palabra "nodo", se est refiriendo a un punto donde se unen varios ramales. Ahora bien,
segn la Real Academia Espaola [RAE, 92] y otras entidades y personas dedicadas al estudio del
lenguaje, "nudo" puede utilizarse con este significado, mientras que "nodo" no admite ninguna acepcin
que tenga un sentido semejante al comentado. La razn por la que se incurre tan a menudo en el error de
confundir ambas palabras es que en ingls, la lengua en la que se escriben la mayor parte de los textos de
informtica, node puede traducirse al castellano por "nodo" y por "nudo".
100
Arco fuente
Regla
Subclase de
Subclase en una
particin disjunta
Regla ACC-2
Subclase en una
particin exhaustiva
Regla ACC-2_1
Subclase de
Regla ACC-2_2
Subclase de
Regla ACC-2_3
Subclase en una
particin exhaustiva
Regla ACC-2_4
Subclase en una
particin exhaustiva
Regla ACC-2_5
Subclase en una
particin disjunta
Regla ACC-2_6
Subclase en una
particin disjunta

Todos los nudos deben aparecer en el campo
'nombre del concepto' dentro del diccionario de
conceptos. Las distintas variantes de esta regla
son la ACC-2_1, ACC-2_2 y as sucesivamente
hasta la ACC-2_6. La comprobacin se hace con
el diccionario de conceptos y no con el diagrama
de relaciones porque puede haber algn
concepto que no est implicado en ninguna
relacin salvo las que aparecen en el rbol de
clasificacin de conceptos.
'concepto' del que sale un arco 'subclase de'
tiene que aparecer en el campo 'nombre del
concepto' del diccionario de conceptos
'concepto' al que entra un arco 'subclase de'
tiene que aparecer en el campo 'nombre del
concepto' del diccionario de conceptos
'concepto' del que sale un arco 'sublcase en una
campo 'nombre del concepto' del diccionario de
conceptos
conceptos
conceptos
conceptos
Descripcin formal
--
ACC.S.oul.Concepto is inctuded in
DC.NC
ACC.S.in.Concepto is included in
DC.NC
ACC.SPE.out.Concepto is included in
DC.NC
ACC.SPE.in.Conceplo is included in
DC.NC
ACC.SPD.out.Concepto is included in
DC.NC
ACC.SPD.in.Concepto is included in
DC.NC
Tabla 4.15. Tabla de reglas de verificacin en el rbol de clasificacin de conceptos con otros elementos
de conceptualizacin (2/2)
EE) Diagrama de relaciones binarias

La Tabla 4.16 y la Tabla 4.17 presentan la conceptualizacin de un diagrama de relaciones
binarias. Adems, la Tabla 4.18 presenta la conceptualizacin de las reglas de verificacin de
la consistencia
del
diagrama
de
relaciones
binarias
con
otros
elementos
de
la
conceptualizacin.
Obsrvese que, al ser posible la repeticin del nombre de la relacin en distintos conceptos
origen, se est estableciendo que las relaciones son locales a los conceptos.
Arco
Origen
Destino
Siglas
Descripcin
Parte del concepto que acta como sujeto del verbo que representa a la
relacin,, yj llega
a la relacin
n
Parte de la relacin y llega al concepto que acta como complemento del
verbo que representa a la relacin
Tabla 4.16. Descripciones de los tipos de arcos del diagrama de relaciones binarias
101
Nudo
Siglas
Concepto
Relacin
Descripcin
**
Arcos que
pueden
entrar o
salir
Origen
Destino
Asocia dos conceptos.
Se representa como un
verbo que puede ir
acompaado por un
complemento
o, Origen
tambin,
por
una
preposicin (trabaja en,
es parte de, etc.)
Destino
Multiplicidades
de entrada
Multiplicidades de salida
--
(0, n) Al ser obligatorio que

cada relacin tenga una
inversa, se puede pensar que
todo concepto del diagrama
tiene que ser origen de alguna
relacin; sin embargo, puede
darse el caso de que un
concepto sea origen y destino
de la misma relacin, y que
esta relacin sea la inversa de
s misma, por lo que no tiene
sentido replicar el arco. Este
mismo razonamiento se puede
hacer para el resto de las
multiplicidades de este EC.
(0,n)
(1,1)
. .-
(1,1)
Tabla 4.17. Caractersticas de los nudos del diagrama de relaciones binarias

Nombre
Arco fuente
Regla DR-1 Origen
R?glaDR-2 Destino
Regla DR-3 Origen
Descripcin formal
El origen de- una relacin debe estar bien en el rbol de DR.O.in.R is included in
ACC.S.in.Concepto unin
clasificacin de conceptos bien en la lista de trminos a
ACC.S.out.Concepto unin
importar. La razn por la que un concepto origen puede ser un
ACC.SPE.in.Concepto unin
trmino importado es la siguiente; toda relacin tendr una
ACC.SPE.out.Concepto unin.
inversa, y puede haber conceptos del diagrama que no estn en
ACC.SPD.in.Concepto unin ,
la ontologa, por consiguiente, estos conceptos importados
ACC.SPD.out.Concepto
sern destino de alguna relacin, pero origen de su inversa.
DR.D.out.R is included in
El destino de una relacin debe estar bien en el rbol de
clasificacin de conceptos, bien en la lista de trminos a
ACC.SPE.out.Concepto unin
importar, pues el concepto destino puede, o no, pertenecer a la
ACC.SPD.in.Concepto unin
ontologa.
ACC.SPD.out.Concepto unin
TTl.m
Las relaciones cuyo concepto origen est en el rbol de
clasificacin de conceptos han de aparecer en el glosario de
trminos, mientras que las relaciones cuyo concepto origen est
en la tabla de trminos a importar tambin han de aparecer en
esta lista. (Todava no se puede expresar de manera formal
porque la comprobacin se hace sobre el glosario de trminos o
sobre la tabla de trminos a importar dependiendo de una
condicin).
Tabla 4.18. Tabla de reglas de verificacin en el diagrama de relaciones binarias con otros elementos de
conceptualizacin
102
F) Diccionario de conceptos
La Tabla 4.19 presenta la conceptualizacin de un diccionario de conceptos. Adems, la Tabla
4.20 presenta la conceptualizacin de las reglas de verificacin de la consistencia del
diccionario de conceptos con otros elementos de la conceptualizacin.
Segn las posibles repeticiones de valores, las relaciones y los atributos son locales a los
conceptos. Adems, tal y como ya se ha indicado en la conceptualizacin del rbol de
clasificacin de conceptos, existe herencia mltiple, pues la misma instancia puede estar en
varios conceptos.
Campo
Siglas
Nombre del concepto

Sinnimos
Abreviaturas
NC
S
A
Instancias
Atributos de clase
AC
Atributos de instancia Al
Relaciones
Repeticin en
la misma
tabla
No
No
No
Descripcin
Formato
Es principal
**
**
*#
Identificador
Identicador
Identificador
NO
No
Identificador
No
: (0, n)
Identificador
No
(O.n)
Identificador
No
(0,n)
Identificador
No
(0,n)
Instancias que son

casos particulares de
concepto
Describen
los
conceptos en s
mismos.
Aquellos que sirven
para
describir
instancias
particulares
del
concepto.
Relaciones binaras
"ad hoc" que se
establecen con otros
conceptos.
SI-
Multiplicidad
(1,1)
(0,n)
(0,n)
Tabla 4.19. Tabla de descripcin de campos del diccionario de conceptos
Nombre
Campo
fuente
Regla DC-1
Nombre del
concepto
Regla DC-2
Instancias
Regla DC-3
Instancias
Regla DC-4
Atributos de
clase

El nombre del concepto tiene que ser
un nudo del rbol de clasificacin de
conceptos, pues el diccionario de
conceptos muestra los detalles de los
conceptos incluidos en el rbol de
clasificacin de conceptos.
Descripcin formal
DC.NC is included in
ACC.S.in.Concepo unin
ACC.S.out.Conceplo unin
ACC.SPD. out. Concepto
Todas las instancias tienen que estar

DC.lnstancias is included in TI.NI
definidas en la tabla de instancias.
Todas las instancias tienen que estar
DC.Instancias is included in GT.Nombre
definidas en el glosario de trminos.
Todos los atributos de clase deben
estar definidos en el glosario de DC.AC is included in GT.Nombre
trminos.
Tabla 4.20. Tabla de reglas de verificacin del diccionario de conceptos con otros elementos de
conceptualizacin (1/2)
103
Campo
fuente
Nombre
Regla DC-5
Nombre del
concepto
Atributos de
instancia
Atributos de
instancia
Regla DC-7
Nombre del
concepto
Relaciones
Regla-DC-8
Nombre del
concepto
Relaciones
Regla DC-9
Nombre del
concepto
Descripcin formal
Atributos de
clase
Regla DC-6
Todos los atributos de clase que

estn en el campo 'atributos de clase'
de un concepto C del diccionario de
conceptos tienen que aparecer en el
campo 'Nombre del atributo' y el
concepto C en el campo 'concepto'
de alguna tabla de atributos de clase.
Todos los atributos de instancia
deben estar definidos en el glosario
de trminos.
Todos los atributos de instancia que
estn en el campo 'atributos de
instancia' de un concepto C del
diccionario de conceptos tienen que
aparecer en el campo 'Nombre del
atributo' y el concepto C en el campo
'concepto' de alguna tabla de
atributos de instancia.
Todas las relaciones que estn en el
campo 'relaciones' de un concepto C
del diccionario de conceptos tienen
que aparecer en el diagrama de
relaciones
binarias
siendo
el
concepto C el origen de la relacin.
Todas las relaciones que estn en el
campo 'relaciones' de un concepto C
del diccionario de conceptos tienen
que aparecer en el campo 'Nombre
de la relacin' y el concepto C en el
campo 'concepto origen' de alguna
tabla de relaciones binarias
DC.AC, DC.NC is inctuded in TACNA, TAC.C
DC.AI is inctuded in GT.Nombre
DC.AI, DC.NC is inctuded in TAINA, TAI.C
DC.NQ DCR is inctuded in

DR.O.out.Concepto, DR.O.in.Relacin
DCR, DCNC is inctuded in TR.NR, TR.CO
Tabla 4.20. Tabla de reglas de verificacin del diccionario de conceptos con otros elementos de
conceptualizacin (2/2)
G) Tablas de relaciones binarias

La Tabla 4.21 presenta la conceptualizacin de tablas de relaciones binarias. Adems, la Tabla
4.22 muestra la conceptualizacin de las reglas de verificacin de la consistencia entre tablas
de relaciones binarias, mientras la Tabla 4.23 presenta la conceptualizacin de las reglas de
verificacin de la consistencia de las tablas de relaciones binarias con otros elementos de la
conceptualizacin.
Campo
Nombre de la
relacin
Concepto
origen
Siglas
Descripcin
Formato
Es principal
NR
**
Identificador
CO
Si la relacin R se
establece
entre
el
concepto C y el G,
entonces Ci es el origen.
Identficador
Repeticin en otra tabla

del mismo tipo
S. Sin embargo, lo que no
puede repetirse en otra tabla
de
relaciones
es
la
combinacin del nombre de
la relacin, el concepto
origen y el concepto
destino.
S
Multiplicidad
(l.I)
(1,1)
Tabla 4.21. Tabla de descripcin de campos de la tabla de relaciones (1/2)
104
Campo
Cardinalidad
del concepto
origen
Siglas
eco
Concepto
destino
CD
Ptopiedades
matemticas
PM
Relacin
inversa
Referencias
RI
Descripcin
Formato
Se dice que el concepto

origen, Co,
tiene
cardinalidad
(p,
q),
dondepy q son nmeros
naturales, si el nmero
de instancias de Co que
satisfacen la relacin
est comprendido entre p
y q, ambos inclusive. Si
q es el carcter 'n' en
vez de un nmero
natural, se asume que no Cardinalidad
hay restricciones sobre
el valor mximo de
instancias.
Cuando q sea la letra n
en vez de un nmero, no
habr
ninguna
restriccin
sobre
el
nmero mximo de
instancias de Co que
satisfacen la relacin.
Si la relacin R se
establece
entre
el
concepto C/ y el C2, Identifcador
entonces C2 es el
destino.
Hay que especificar si la
relacin es: simtrica,
antisimtrica, transitiva,
Identificador
reflexiva, 0 tiene otras
propiedades
las
matemticas
El par (I, 2), donde /; e
[2
son
instancias,
satisface la relacin R si Identifcador
y slo si (I2, I) satisface
su inversa.
Fuentes que se han

utilizado
en
la
adquisicin
de
conocimientos:
libros,
entrevistas
con
el
entendido en el dominio,
otras ontologfas, etc.
Descripcin
Es principal
Repeticin en otra tabla

del mismo tipo
Multiplicidad
No
(1,1)
(1.1)
No
(0,n)
No
S, como se ha dicho en la
entrada del "nombre de la
relacin", una relacin se
identifica por su nombre, el
concepto origen y el
concepto destino, con las
relaciones inversas ocurre
lo mismo.
(0,1)
(0, 1). Esto no

significa
que
slo se ponga
una referencia,
sino que todas
ellas
se
consideran una
sola cadena de
caracteres, ya
que no se van a
considerar
de
forma separada.
Esta
misma
explicacin es
vlida para los
campos de otras
tablas
que
reciben tambin
el
nombre
'referencias'.
No
Tabla 4.21. Tabla de descripcin de campos de la tabla de relaciones (2/2)
Mtodo flexible para la conceptualizacin de ontologfas basado en meta-modelos
105
Nombre
Campo fuente
Regla TR-1
Relacin
inversa
Regla TR-2
Relacin
inversa
Regla TR-3
Relacin
inversa

Si la relacin inversa est en la misma
ontologa, es decir, si aparece en el glosario
de trminos, entonces el concepto origen
tendr que aparecer en el campo "concepto
destino" de la tabla de la relacin inversa.
En cualquier caso, tiene que aparecer en el
diagrama de relaciones como origen de la
relacin que se est definiendo. (Todava no
se puede expresar de manera formal, pues la
comprobacin se har dependiendo de una
condicin previa).
Si la relacin inversa est en la misma
ontologa, es decir, si aparece en el glosario
de trminos, entonces el concepto destino
deber estar en el campo "concepto origen"
de la tabla de relacin inversa o en la lista
de trminos a importar. En cualquier caso,
tiene que aparecer en el diagrama de
relaciones como destino de la relacin que
se est definiendo. (Todava no se puede
expresar de manera formal, por la misma
razn que se ha dicho en la regla anterior).
Descripcin formal
--
Si la relacin inversa, Rinv, est en la

misma ontologa, entonces la relacin que
se est definiendo, R, debe aparecer en el
campo "relacin inversa" correspondiente a
Rinv. En cualquier caso, la relacin R tiene
que aparecer en el diagrama de relaciones
como inversa de Rinv. (Todava no se puede
expresar de manera formal, por lo ya dicho
en las reglas anteriores).
--
Tabla 4.22. Tabla de reglas de verificacin de las tablas de relaciones entre ellas
Nombre
Regla TR-4
Descripcin formal
Campo fuente
Nombre de la Si, en la relacin R que se est definiendo,
se especifica que el concepto origen es Co,
relacin
entonces, en el diccionario de conceptos, TR.NR, TR.CO is includedin DC.R, DC.NC
aparecer R como una de las relaciones
Concepto
correspondientes al concepto Co
origen
Tabla 4.23. Tabla de reglas de verificacin de las tablas de relaciones con otros elementos de
conceptualizacin
H) Tablas de atributos de instancia

La Tabla 4.24 presenta la conceptualizacin de tablas de atributos de instancia. Adems, la
Tabla 4.25 y la Tabla 4.26 presentan la conceptualizacin de las reglas de verificacin de la
consistencia
de las tablas de atributos
de
instancia
con otros
elementos
de
la
conceptualizacin.
Tal y como se puede observar en la multiplicidad del campo frmula, un atributo se puede
deducir utilizando frmulas diferentes. Por ejemplo, el peso atmico de un elemento qumico
que se puede obtener de diferentes maneras dependiendo de los datos que se tengan. Por otra
parte, los tipos de valores pueden ser, adems de los bsicos, operaciones aritmticas, e
incluso conceptos.
106
Campo
Siglas
Nombre del
atributo
Descripcin
Formato
Es
principal
**
Identificador
NA
Concepto
Tipo de valor
TV
Unidad de
medida
UM
Precisin
Intervalo de
valores
rv
Valor por
defecto
VD
Cardinalidad
Deducido de
los atributos
de instancia
Deducido de
los atributos
de clase
DAI
DAC
Deducido de
las constantes
DC
Frmulas
Para deducir
PD
Referencias
Concepto al que pertenece el

atributo. Ntese que otro
Identificador
concepto puede tener un
atributo con el mismo nombre.
Texto
**
Se utiliza
numricos
en
atributos
Se
utiliza
en
atributos
numricos. Es la diferencia
mxima que puede haber entre
los valores exactos del atributo
y los que aparecen en la
ontologa
El valor mnimo y el mximo
que puede tomar el atributo
Es el valor que toma el
atributo mientras no se diga lo
contrario
Es
el
nmero
mnimo
(cardinalidad
mnima)
y
mximo
(cardinalidad
mxima) de valores que puede
tomar. Si la cardinalidad
mxima es "n", se supone que
no hay ninguna restriccin
sobre la misma.
Atributos de instancia que se
pueden utilizar para obtener el
valor del atributo en cuestin.
Atributos de clase que se
pueden utilizar para obtener el
valor del atributo en cuestin.
Constantes que se pueden
utilizar para obtener el valor
del atributo en cuestin.
Expresin
aritmtica
Repeticin en otra
tabla del mismo
tipo
S. Sin embargo, lo
que no se puede
repetir en otra tabla
de aibutos de
instancia es la
combinacin
del
nombre del atributo
con el concepto al
que pertenece
Multiplicidad
(M)
(1,1)
No
No
(1,1)
La multiplicidad
mnima es 1 si el
tipo de valor es
numrico y 0 en
caso contrario.
La
mxima
siempre es 1.
Expresin
aritmtica
No
Se da el mismo
caso que en la
unidad
de
medida.
Intervalo de
valores
No
(0,1)
Expresin
aritmtica
No
(0,1)
Cardinalidad
No
(1,1)
Identificador
No
(0,n)
Identificador
No
(0,n)
Identificador
No
(0,n)
No
No.
Pues
una
frmula slo puede
usarse para dar
valor a un atributo.
(0,n)
No
(O.n)
No
(0,1)
Frmulas que se pueden

aplicar para obtener el valor Identificador
del atributo en cuestin.
Qu atributos de instancia se
pueden obtener utilizando el Identificador
valor del atributo en cuestin
Fuentes que se han utilizado
en
la
adquisicin
de
conocimientos;
libros,
Texto
entrevistas con el entendido en
el dominio, otras ontologas,
etc.
Tabla 4.24. Tabla de descripcin de campos de las tablas de atributos de instancia
107
Nombre
Regla TAI-1
Regla TAI-2
Descripcin formal
Si un atributo A2 aparece en el
Nombre del atributo
campo "deducido de los atributos
de instancia" de la tabla de otro
TAINA, TAI.DAI is induded in TAI.PD, TAINA
Deducido
de
los atributo Al, entonces Ai deber
aparecer en el campo "para
atributos de instancia
deducir" de la tabla de A2.
Si un atributo A2 aparece en el
campo "para deducir" de la tabla de
Nonbre del atributo
otro atributo A, entonces Ai deber
TAINA, TAI.PD is induded in TAI.DAI, TAINA
aparecer en el campo "deducido de
Para deducir
los atributos de instancia" de la
tabla de A2.
Campo fuente
Tabla 4.25. Tabla de reglas de verificacin de las tablas de atributos de instancia entre ellas
Nombre
Regla TAI-3
Regla TAl-4
Regla TAI-5
Regla TAI-6
Regla TAl-7
Regla TAl-8
Campo fuente

Si en el atributo A que se est
definiendo se especifica que el
concepto es C, entonces, en el
Nombre del atributo
diccionario de conceptos, aparecer
A como uno de los atributos de
Concepto
clase correspondientes al concepto
C.
El tipo de valor est formado por
trminos tales que cada uno de
ellos bien est en la tabla de
trminos a importar, bien es uno de
los siguientes tipos: booleano,
cadena de caracteres, real 0 entero.
Tipo de valor
(Todava no se puede expresar
formalmente porque la hay que
comprobar una condicin previa y
porque
pueden
intervenir
subcadenas).
Cualquier
identificador
que
aparezca en la unidad de medida
del atributo ha de estar en la lista de
trminos a importar. (Todava no se
Unidad de medida
puede expresar forinalmente porque
un identificador que aparezca en la
unidad de medida puede ser una
subcadena).
Si un atributo de clase Ac aparece
Nombre del atributo
en el campo "deducido de los
atributos de clase" de la tabla de un
Deducido
de
los atributo de instancia A, entonces Ai
deber aparecer en el campo "para
atributos de clase
deducir" de la tabla de Ac.
Si una constante Cons aparece en el
campo
"deducido
de
las
Nombre del atributo
constantes" de la tabla de un
atributo de instancia A, entonces el
Deducido
de
las atributo A deber aparecer en el
constantes
campo "para inferir" de la tabla de
Cons
Cualquier frmula que haya en el
campo "frmulas" deber estar
definida en una tabla de frmulas.
Nombre del atributo
Adems, el atributo inferido que
aparece en la tabla de la frmula ha
Frmulas
de ser el atributo que se ha definido
en la tabla de atributos.
Descripcin formal
TAINA, TAC.C is induded in

DC.NC, DC.AI
TAINA, TAI.DACis induded in TAC.PD, TACNA
TAI.NA, TAI.DC is induded in TC.NC, TC.PI
TAINA, TAI.F is induded in TF.AI. TF.F
Tabla 4.26. Tabla de reglas de verificacin de las tablas de atributos de instancia con con otros elementos
de conceptualizacin
108
I) Tablas de atributos de clase

La Tabla 4.27 presenta la conceptualizacin de tablas de atributos de clase. Adems, la Tabla
4.28 presenta la conceptualizacin de las reglas de verificacin de la consistencia de las tablas
de atributos de clase con otros elementos de la conceptualizacin.
Campo
Siglas
Descripcin
Formato
Es principal
**
Identificador
Repeticin en
otras tablas del
mismo tipo
S. Sin embargo, lo
que no se puede
repetir en otra tabla
de atributos de
clase
es
la
combinacin
del
nombre del atributo
con el concepto al
que pertenece
Multiplicidad
Nombre del
atributo
NA
Concepto
Concepto
al
que
pertenece el atributo
Identificador
Tipo de valor
TV
**
Texto
No
(1,1)
Unidad de
medida
UM
Precisin
Cardinalidad
Para deducir
PD
Referencias
Se utiliza en atributos
numricos
Se utiliza en atributos
numricos.
Es
la
diferencia mxima que
puede haber entre los
valores
exactos
del
atributo y los que
aparecen en la ontologa.
Es el nmero mnimo
(cardinalidad mnima) y
mximo
(cardinalidad
mxima) de valores que
puede
tomar.
Si
cardinalidad mxima es
"n", se supone que no
hay ninguna restriccin
sobre sta
De qu atributos de
instancia se pueden
obtener
sus
valores
utilizando el atributo de
clase en cuestin
Fuentes que se han
utilizado
en
la
adquisicin
de
conocimientos; libros,
entrevistas
con
el
otras ontologas, etc.
(1,1)
(1,1)
Expresin
aritmtica
No
La multiplicidad
im'nima es 1 si el
tipo de valor es
numrico y 0 en
caso contrario.
La
mxima
siempre es 1.
Expresin
aritmtica
No
Se da el mismo
caso que en la
unidad
de
medida.
Cardinalidad
No
(1.1)
Identificador
No
(0,N)
Texto
No
(0,1)
Tabla 4.27. Tabla de descripcin de campos de las tablas de atributos de clase
109
Nombre

Descripcin formal
Si en el atributo A que se est definiendo se
especifica que el concepto es C, entonces,
TACNA, TAC.C is included in
en el diccionario de conceptos, aparecer A
DC.AC. DC.NC
como uno de los atributos de clase
correspondientes al concepto C.
El tipo de valor est formado por trminos
tales que cada uno de ellos bien est en la
tabla de trminos a importar, bien es uno
de los siguientes tipos: booleano, cadena de
caracteres, real o entero. (Todava no se
puede expresar formalmente porque la hay
que comprobar una condicin previa y
porque pueden intervenir subcadenas).
Todas las unidades que aparezcan en la
expresin aritmtica de la unidad de
medida han de estar en la tabla de trminos
a importar. (Todava no puede expresarse
formalmente porque es posible que haya
que
hacer
comprobaciones
con
subcadenas).
Si un atributo de instancia Ai aparece en el
campo 'para deducir' de la tabla de un
TACNA. TACPD is included in
atributo de clase Ac, entonces Ac deber
TAI.DAC TAINA
aparecer en el campo "deducido de los
atiibutos de clase" de la tabla de A.
Campo fuente
Nombre del atributo
Regla TAC-1
Concepto
Regla TAC-2
Tipo de valor
Regla TAC-3
Unidad de medida
Nombre del atributo

Regla TAC-4
Para deducir
Tabla 4.28, Referencias cruzadas de las tablas de atributos de clase con con otros elementos de
conceptualizacin
J) Tabla de constantes
La Tabla 4.29 presenta la conceptualizacin de una tabla de constantes. Adems, la Tabla 4.30
presenta la conceptualizacin de las reglas de verificacin de la consistencia de la tabla de
constantes con otros elementos de la conceptualizacin.
Campo
Nombre de la
constante
Siglas
NC
Descripcin
Formato
Es principal
Repeticin en
la misma
tabla
Multiplicidad
**
Identificador
No
(1,1)
Expresin
aritmtica
Expresin
aritmtica
Expresin
aritmtica
No
(1,1)
No
(1,1)
No
(1,1)
No
(0, n).
(0, 1). Esto no

significa que slo
se
ponga
una
referencia,
sino
que todas ellas se
consideran
una
sola cadena de
caracteres, ya que
no se van a
procesar de forma
separada
Tipo de valor
TV
**
Valor
Unidad de
medida
UM
**
Para inferir
Referencias
PI
Atributos de instancia cuyos

valores se pueden deducir Identificador
utilizando la constante
Fuentes que se han utilizado en

la
adquisicin
de
conocimientos:
libros,
entrevistas con el entendido en
el dominio, otras ontologas,
etc.
Texto
No
Tabla 4.29. Tabla de descripcin de campos de la tabla de constantes
Mtodo flexible para la coiiceptualizacin de ontologas basado en meta-modelos
110
Nombre
Regla TC-1
Campo
fuente
Nombre de la
constante
Regla TC-2
Tipo de valor
Regla TC-3
Unidad de
medida
Regla TC-4
Nombre de la
constante
Para inferir
Descripcin formal
El nombre de cualquier constante debe

TC.NC is included in GT.N
estar en el glosario de trminos.
El tipo de valor est formado por
trminos tales que cada uno de ellos bien
est en la tabla de trminos a importar,
bien es uno de los siguientes tipos:
booleano, cadena de caracteres, real o
-entero. (Todava no se puede expresar
formalmente porque la hay que
comprobar una condicin previa y porque
pueden intervenir subcadenas).
Todas las unidades que aparezcan en la
expresin aritmtica de la unidad de
medida han de estar en la tabla de
trminos a importar. (No se puede
expresar formalmente todava porque
intervienen subcadenas).
Si un atributo de instancia A est en el
campo "pata inferir" de una constante C,
TC.NC. TC.PIis included in TAI.DC,
entonces la C tiene que estar en el campo
"deducido de las constantes" del atributo TAINA
A.
Tabla 4.30. Tabla de reglas de verificacin de la tabla de constantes con otros elementos de
conceptualizacin
K) Tabla de axiomas lgicos

La Tabla 4.31 presenta la conceptualizacin de tablas de axiomas lgicos. Adems, la Tabla
4.32 y la Tabla 4.33 presentan la conceptualizacin de las reglas de verificacin de la
consistencia de las tablas de axiomas lgicos con otros elementos de la conceptualizacin.
Con estos axiomas se pueden describir frmulas de lgica de primer orden, que pueden ser
tiles para modelizar aquellos aspectos para los que otros elementos de la conceptualizacin
no tengan expresividad suficiente.
Campo
Nombre del
axioma
Siglas
NA
Descripcin
Concepto
descrito
CD
Conceptos
referidos
CR
Atiibutos
referidos
AR
Descripcin
Formato
Es principal
Repeticin en
otras tablas del
mismo tipo
Multiplicidad
**
Identicador
No
(1.1)
Descripcin
No
(1,1)
Identicador
No
(1,1)
Identiftcador
No
(0,n)
(0, n), es posible que

slo se haga referencia
a relaciones y no a
atributos
natural
Concepto que se describe a
travs del axioma
Conceptos,
aparte del
concepto descrito, que
intervienen en la expresin
formal del axioma
Atributos, de instancia o de
clase, que intervienen en la
descripcin formal del
axioma
Identificador
No
Tabla 4.31. Tabla de descripcin de campos de las tablas de axiomas lgicos (1/2)
111
Campo
Siglas
Relaciones
referidas
RR
Variables
Constantes
referidas
es
Instancias
referidas
IR
Expresin
Referencias
Descripcin
Relaciones binarias que
intervienen
en
la
descripcin formal del
axioma
Variables que intervienen
en la descripcin formal
del axioma
Constantes que intervienen
del axioma
Instancias que intervienen
del axioma
Expresin
lgica
en
notacin infija que describe
el axioma
Fuentes que se han
utilizado en la adquisicin
de conocimientos: libros,
entrevistas
con
el
otras ontologas, etc.
Formato
Es principal
Repeticin en
otras tablas del
mismo tipo
Multiplicidad
Identificador
No
(0, n), es posible que

se haga referencia a
atributos y no a
relaciones
Identificador
No
(0,n)
Identificador
No
(0,n)
Identificador
No
(0,n)
Expresin
lgica
No
No
(1,1)
Texto
No
(0,1)
Tabla 4.31. Tabla de descripcin de campos de las tablas de axiomas lgicos (2/2)
Nombre
Campo fuente
Regla TAL-1
Concepto descrito
Regla TAL-2
Conceptos referidos
Regla TAL-3
Atributos referidos
Regla TAL-4
Relaciones referidas
Regla TAL-5
Variables
Regla TAL-6
Constantes referidas
Regla TAL-7
Instancias referidas
Regla TAL-8
Expresin

El concepto descrito tiene que estar en la expresin del
concepto que se est definiendo como un predicado
unario. (No se puede expresar formalmente todava).
Los conceptos referidos deben aparecer en la expresin
del axioma como predicados unarios. (No se puede
expresar formalmente todava).
Cualquier atributo del campo "atributos referidos" tiene
que aparecer en la expresin que describe el axioma
como predicados binarios. (No se puede expresar
formalmente todava).
Cualquier relacin de las que haya en el campo
"relaciones referidas" debe aparecer en el campo
"expresin" de la tabla que se est elaborando como un
predicado. (No se puede expresar formalmente todava).
Las variables debern aparecer en la expresin que
describe el axioma. (No se puede expresar formalmente
todava).
Cualquier constante de las que haya en el campo
"constantes referidas" ha de aparecer en la expresin del
axioma. (No se puede expresar formalmente todava).
Cualquier instancia de las que haya en el campo
"instancias referidas" ha de aparecer tambin en la
expresin del axioma. (No se puede expresar
formalmente todava).
Los nicos identificadores que pueden aparecer son:
variables, predicados 0-arios (constantes en lgica),
predicados unarios y predicados binarios. Las variables
han de estar en el campo correspondiente de la tabla del
axioma que se est definiendo, las constantes en los
campos "constantes referidas" o "instancias referidas",
los predicados unarios en el concepto descrito o en los
conceptos referidos, y los predicados binarios en los
atributos, relaciones o constantes referidas. (No se puede
expresar formalmente todava).
Descripcin formal
-, . --
--
Tabla 4.32. Tabla de reglas de verificacin de las tablas de axiomas lgicos dentro de la misma tabla
112
Nombre
Campo fuente
Regla TAL-9
Concepto descrito
Regla TAL-10
Conceptos referidos
Regla TAL-11
Atributos referidos
Regla TAL-12
Regla TAL-13
Regla TAL-14

El concepto descrito deber estar en el diccionario de
conceptos.
Los conceptos referidos debern estar en el diccionario
de conceptos o en la tabla de trminos a importar.
Cualquier atributo del campo "atributos referidos" debe
estar defndo en una tabla de atributos de instancia o de
atributos de clase, o bien en la tabla de trminos a
importar.
Cualquier relacin de las que haya en el campo
"relaciones referidas" debe estar definida en una tabla de
relaciones binarias, o bien en la tabla de trminos a
importar.
Cualquier constante de las que haya en el campo
"constantes referidas" debe estar definida en la tabla de
constantes, o bien en la tabla de tnninos a importar.
Cualquier instancia de las que haya en el campo
"instancias referidas" debe estar definida en el campo
"instancias" del diccionario de conceptos, o bien en la
tabla de trminos a importar.
Descripcin formal
TAL.CD in included in
DC.NC
TAL.CR is included in
DC.NC unin TTI.NT
TALAR is included in
TAI.NA unin TACNA
unin TTI.NT
TAL.RR is included in
TR.NR unin TTI.NT
TAL.CS is included in
TC.NC unin TTI.NT
TAL. IR is includd in
DC.I unin TTI.NT
Tabla 4.33. Tabla de reglas de verificacin de las tablas de axioinas lgicos con con otros elementos de
conceptualizacin
1.) Tablas de frmulas

La Tabla 4.34 presenta la conceptualizacin de tablas de frmulas. Adems, la Tabla 4.35 y la
Tabla 4.36 presentan la conceptualizacin de las reglas de verificacin de la consistencia de
las tablas de frmulas con otros elementos de la conceptualizacin.
Obsrvese que, tal y como se advierte en la celda es principal de la fila concepto, una
misma frmula puede aparecer en dos conceptos diferentes, y en uno ser la especiaiizacin de
la definicin dada en el otro.
Campo
Nombre
dla
frmula
Concepto
Siglas
NF
Descripcin
Formato
Es principal
Repeticin
en tablas
del mismo
tipo
**
Identificador
(1,1)
S, una frmula puede aparecer en dos

conceptos diferentes y en uno ser
especiaiizacin de otro. Por ejemplo, la
frmula para hallar la densidad de un
elemento qumico consiste en dividir el
peso atmico por el volumen atmico. Se
trata de una especiaiizacin de la frmula
general donde se establece que la
densidad es igual a la masa partida por el
volumen.
(1,1)
Concepto
que
se
Identificador
describe con
la frmula
Multiplicidad
Tabla 4.34. Tabla de descripcin de campos de las tablas de frmulas (1/2)
113
Campo
Siglas
Atributo
inferido
AI
Frmula
Descripcin
Atributos
bsicos
AB
Constantes
Precisin
Restricciones
RS
Referencias
Descripcin
Formato
Atributo que se
deduce
Identificador
utilizando
la
frmula
Expresin lgica.
Est formada por
una
expresin
Expresin
aritmtica ligada al
aritmtica que
atributo deducido a
describe
la
travs
del
frmula
predicado '=', por
eso
es
una
expresin lgica.
Descripcin en
Descripcin
lenguaje natural
Atributos,
de
clase
y
de
instancia,
utilizados en la
Identificador
frmula
para
deducir
el
"atributo
inferido"
Constantes que
se utilizan para
deducir
el Identificador
"atributo
inferido"
Se utiliza en
atributos
numricos. Es la
diferencia
mxima
que
Expresin
puede
haber
aritmtica
entre los valores
exactos
del
atributo y los
que aparecen en
la ontologa
Expresin lgica
que establece las
condiciones que
se deben dar Expresin lgica
para que se
pueda aplicar la
frmula.
Fuentes que se
han utilizado en
la adquisicin
de
conocimientos:
Texto
libros,
entrevistas con
el entendido en
el dominio, otras
ontologas, etc.
Es principal
Repeticin en
tablas del
mismo tipo
Multiplicidad
No
No
(1,1)
No
No
(1,1)
No
No
(1,1)
No
(l,n)
No
(0,n)
No
(0, 1)
No
(0,
1).
Las
restricciones
se
describen con una
expresin
de
lgica de primer
orden
No
(0,1)
Tabla 4.34. Tabla de descripcin de campos de las tablas de frmulas (2/2)
114
Nombre
Campo fuente
Regla TF-1
Atributo deducido
Regla TF-2
Frmula
Regla TF-3
Atributos bsicos

Cualquier atributo inferido debe aparecer a la izquierda
del igual en la expresin del campo "frmula" de la
tabla que se est elaborando. (Todava no se puede
expresar de manera formal).
Todos los identicadores que aparezcan a la derecha
del igual en la expresin, han de estar en el campo
"atributos bsicos" o "constantes" de la tabla que se
est deniendo, y el identicador que est a la
izquierda del igual deber aparecer en el campo
"atributo inferido". (Todava no se puede expresar de
manera formal porque intervienen subcadenas).
Todos los atributos bsicos deben aparecer a la derecha
del igual de la expresin de la frmula. (Todava no se
puede expresar de manera formal porque intervienen
subcadenas).
Descripcin formal
--
--
Tabla 4.35. Tabla de reglas de verificacin de las tablas de frmulas entre ellas
Nombre
Campo fuente
Nombre de la frmula
Regla TF-4
Atributo inferido
Nombre de la frmula
Regla TF-5
Atributo inferido
Regla TF-6
Concepto
Nombre de la frmula
Regla TF-7
Atributos bsicos
Nombre de la frmula
Regla TF-8
Atributos bsicos
Regla TF-9
Constantes
Regla TF-10
Nombre de la frmula
Constantes
Regla TF-11
Restricciones

Si A es el atributo inferido en la frmula F, entonces F
tiene que aparecer en el campo "frmula" de la tabla de
A.
Si A es el atributo inferido en la frmula F, entonces
tiene que haber un arco "obtiene" en el rbol de
clasificacin de atributos desde F hasta A.
El concepto del campo "concepto" tiene que aparecer
en el diccionario de conceptos.
Si A\ es un atributo bsico de una frmula y Amt el
atributo inferido, entonces A\, tiene que aparecer bien
en el campo 'deducido de los atributos de instancia' de
la tabla de atributos de instancia Ainr, bien en el campo
'deducido de los atributos de clase' de la tabla de
atributos de instancia de Af.
Tiene que haber un arco "se utiliza en" desde cada
atributo bsico hasta la frmula en el rbol de
clasificacin de atributos.
Todas las constantes que haya en este campo tienen
que estar definidas en la tabla de constantes.
Tiene que haber un arco "se utiliza en" desde cualquier
constante del campo "constantes" hasta la frmula en
el rbol de clasificacin de atributos.
Los tnicos identificadores que pueden aparecer son:
constantes lgicas, predicados unarios y predicados
binarios. Todos ellos pueden estar en la lista de
trminos a importar; pero si alguno no lo est, debe
aparecer, segn el caso en las siguientes tablas: las
constantes en la tabla de constantes o en el campo
"instancias" del diccionario de conceptos, los
predicados unarios en el diccionario de conceptos en el
campo "nombre del concepto", y los predicados
binarios sern atributos o relaciones, por tanto, han de
encontrarse en las tablas de atributos o en las tablas de
relaciones binarias. (Todava no se puede expresar de
manera formal debido a que hay que considerar
condiciones, y que intervienen subcadenas).
Descripcin formal
TF.AI, TF.NF is included in
TAINA. TAl.F
TF.AI, TF.NF is included in
ACA.Obtiene.out.F,
ACA.Obtiene.in.AI
TF. C is included in
DC.NC
TF.AB, TF.AI is included in
TAINA. TAl.DAI unin
TAINA, TAI.DAC
TF.AB, TF.NF is included in
ACA.SE.out.AI,
ACA.SE.in.F
TF. Constantes is included in
TC.NC
TF. C, TF.NF is included in
ACA.SE.out.C,
ACA.SE.in.F
Tabla 4.36. Tabla de reglas de verificacin de las tablas de frmulas con otros elementos de
conceptualizacin
115
M) rboles de clasificacin de atributos

La Tabla 4.37 y la Tabla 4.38 presentan la conceptualizacin de rboles de clasificacin de
conceptos. Adems, la Tabla 4.39 y la Tabla 4.40 presentan la conceptualizacin de las reglas
de verificacin de la consistencia de las tablas de atributos de instancia con otros elementos de
la conceptualizacin.
Arco
Siglas
Se utiliza en
SE
Obtiene
Descripcin
Relaciona un atributo de instancia, un atributo de clase o una constante con la
frmula donde se utiliza.
Relaciona una frmula con el atributo de instancia cuyo valor permite obtener.
Tabla 4.37. Descripciones de los tipos de arcos de los rboles de clasificacin de atributos
Nudo
Siglas
Atributo de instancia
Atributo de clase
Constante
Frmula
AI
AC
Descripcin
Atributo
puede
deducido o
puede servir
deducir
atributo
instancia
Arcos que entran o

salen
que
ser
que
para Se utiliza en
otro
de
Obtiene
Atributo
que
puede servir para
deducir
un Se utiliza en
atributo
de
instancia
Obtiene
Constante
que
puede servir para
deducir
un Se utiliza en
atributo
de
instancia
Obtiene
Puede
utilizar
constantes,
atributos de clase
y atributos de
Se utiliza en
instancia,
y
permite
deducir
atributos
de
instancia
Obtiene
Multiplicidades de
entrada
Multiplicidades
de salida
(0,0)
(0,n)
(0,n)
(0,0)
(0,0)
(0, n)
(0,0)
(0,0)
(0,0)
(0,n)
(0,0)
(0,0)
(0,0)
(0,n)
(0,0)
(1,1)
Tabla 4.38. Tabla de descripcin de campos de los nudos de los rboles de clasificacin de atributos
Nombre
Regla ACA-1
Arco fuente
Se utiliza en
natural
Si un atributo Ai sirve para
deducir otro A2, entonces Ai no
sirve para deducir ^ 1 . (No se
puede formalizar, tiene una
negacin).
Descripcin formal
--
Tabla 4.39. Tabla de reglas de verificacin dentro de los rboles de clasificacin de atributos
116
Nombre
Arco fuente
Regla ACA-2
Se utiliza en
Regla ACA-3
Se utiliza en
Regla ACA-4
Obtiene
Descripcin formal
natural
Si un arco "se utiliza en"
relaciona un atributo (de clase o
de instancia) A con una frmula ACA.SE.out.AI, ACA.SE.in.F is included in
F, entonces A debe aparecer en
TF.AB, TF.F
el campo "atributos bsicos" de
la tabla de la frmula F.
Si un arco "se utiliza en"
relaciona una constante C con
una frmula F, entonces C debe ACA.SE.out.C, ACA.SE.in.F is included in
aparecer
en
el
campo
TF.C. TF.F
"constantes" de la tabla de la
frmula F.
Si un arco del modelo "obtiene"
relaciona una frmula F con un
atributo de instancia A, entonces ACA.O.out.F, ACA.O.in.Al is included in
A debe aparecer en el campo
TF.F, TF.AI
"atributo inferido" de la tabla de
la frmula F.
Tabla 4.40. Tabla de reglas de verificacin en los rboles de clasificacin de atributos con otros
elementos de conceptualizacin
N) Tabla de instancias
La Tabla 4.41 y la Tabla 4.43 presentan la conceptualizacin de una tabla de instancias.
Adems, la Tabla 4.43 presenta la conceptualizacin de las reglas de verificacin de la
consistencia de la tabla de instancias con otros elementos de la conceptualizacin''.
Campo 1
Campo 2
Atributo
Valor
Tabla 4.41. Tabla de campos asociados de

la tabla de instancias
Campo
Siglas
Nombre de la instancia NI
A
Atributo
V
Valor
Descripcin
Formato
Identificador
**
Atributos
de
instancia
que
Identificador
toman valores en
la instancia
Valores que toman
los atributos en la
Texto
instancia
Es principal
Repeticin
dentro de la
misma tabla
MultipUcidad
No
(1.1)
No
No
(0,n)
No
(0,1)
Tabla 4.42. Tabla de descripcin de campos de la tabla de instancias
'* Si se consulta el anexo II, se podr comprobar que la tabla de instancias no se ajusta al formato
especificado en este apartado pues, como se ha dicho anteriormente, se pretende que el presente caso
prctico sirva como base, en un apartado posterior, para otro caso prctico sobre modificacin de metamodelos.
117
Nombre
Campo fuente
Regla TI-1
Nombre de la instancia
Regla TI-2
Atributo

Descripcin formal
Cualquier instancia debe aparecer en el
campo instancias del diccionario de Tl.NI is included in DC.I
conceptos.
Si un atributo toma valor en una instancia,
entonces debe aparecer en el campo
"atributos de instancia" de alguno de los
conceptos padre de dicha instancia.
formalmente debido a la herencia).
Tabla 4.43. Tabla de reglas de verificacin de la tabla de instancias
4.3.1.6.5
Grafo de reglas de verificacin de la consistencia
En la Figura 4.23 se muestra el grafo de reglas de la verificacin de la consistencia. Los nudos

reciben como nombre las siglas de los EE.CC, mientras que los arcos estn etiquetados con
las reglas de verificacin que hay que comprobar entre estos elementos.
Figura 4.23. Grafo de reglas de la verificacin de la consistencia
118
4.3.2 MODIFICACIN DE UN META-MODELO

En caso de que haya una modificacin en la especificacin de un esquema de
conceptualizacin, es necesario cambiar tambin el meta-modelo asociado (Figura 4.24).
Es fundamental tener descrita de manera precisa esta tarea de modificacin de un metamodelo sobre todo para que sea fcil llevar un control de cambios y, as, que stos no sean
caticos y desordenados.
iNiao
Paso 1. Especfcacidn del
CONCEPTUAUZACION
DEL ESQUEMA DE
CONCEPTUAUZACION
Tarea 2.2. Modificacin de

un meta-niodelo anterior


No
ontologa de dominio
Figura 4.24. Tarea de modificacin de un meta-modelo dentro de la conceptualizacin del esquema de

conceptualizacin
4.3.2.1
DESCRIPCIN DE LA MODIFICACIN DE CUALQUIER METAMODELO
Recurdese que para modificar la especificacin de un esquema de conceptualizacin,
119
primero, una persona rellenaba un formulario sobre problemas del esquema. Despus, si
alguien entendido en conceptualizacin consideraba que se deban hacer cambios, entonces
elaboraba una propuesta de cambios que contena (4.2.4.2): el nombre del miembro del grupo
que haba hecho la propuesta, el nombre del esquema afectado por los cambios, la descripcin
en lenguaje natural de los cambios a realizar, y la fecha en que se haba hecho la propuesta. A
continuacin, si el comit de cambios los aprobaba, entonces se llevaban a cabo sobre la
especificacin del esquema de conceptualizacin.
En la tarea descrita en el presente apartado, se parte de la propuesta de cambios, de la
especificacin de stos, y del meta-modelo anterior. Para llevar a cabo los cambios sobre el
meta-modelo, alguien entendido en conceptualizacin elabora la siguiente documentacin:
Documento 1.
Nueva ficha de descripcin general del meta-modelo indicndose cules

han sido las modificaciones que se han realizado con respecto al metamodelo anterior.
Documento 2.
EE.CC afectados por los cambios. Este documento contendr:

a) Una tabla que contenga, para cada uno de los nuevos EE.CC aadidos
al meta-modelo, su nombre, sus siglas, el tipo de elemento (grafo o
tabla), su orientacin (en caso de que se trate de una tabla) y su
descripcin. Esta tabla tendr el mismo formato que el glosario de
EE.CC, descrito en el apartado 4.3.1.6.2.
b). Una tabla que contenga, para cada uno de los EE.CC modificados, su
nombre y una breve descripcin en lenguaje natural explicando en qu
consisten los cambios.
c) Una tabla que contenga, para cada uno de los EE.CC eliminados, su
nombre y por qu se han borrado del meta-modelo.
Documento 3.
El nuevo diagrama de orden de EE.CC, que ir acompaado de una

explicacin en lenguaje natural de los cambios que se han producido con
respecto al diagrama anterior.
Documento 4.
Los cambios concretos en los tipos de tablas modificados. Para cada tipo
de tabla modificado, se deber incluir:
a) Cules son los cambios en los datos generales. Se deber advertir si
hay algn cambio en el nombre, las siglas, la orientacin, o en la
descripcin en lenguaje natural de la tabla.
b) Cules son los cambios en los campos. Se deber incluir:
b.1) Una tabla con las nuevas asociaciones entre campos.
120
b.2) Una tabla con los campos aadidos que tendr un formato similar
al de las tablas de descripcin de campos. Tendr: el nombre del
campo, sus siglas, una descripcin en lenguaje natural, el formato,
si el campo es principal o no, la posible repeticin en tablas del
mismo tipo (si se trata de un tipo de tabla horizontal) o en tablas
de distinto tipo (si se trata de un tipo de tabla vertical), y la
multiplicidad.
b.3) Una tabla que contenga, para cada uno de los campos
modificados, su nombre y una breve descripcin en lenguaje
natural explicando en qu consisten los cambios.
b.4) Una tabla que contenga, para cada uno de los campos eliminados,
su nombre y por qu se han borrado de un tipo de tabla del metamodelo.
c) Cambios en las reglas de verificacin de la consistencia. Se deber
incluir:
C.1) Dos tablas con las reglas de verificacin de la consistencia que
tian sido aadidas. La primera tabla ser para las reglas de
consistencia dentro del mismo EC, y la segunda ser para las
reglas de verificacin con otros EE.CC. Ambas tablas tendrn el
mismo formato que el de las tablas de reglas de verificacin: el
nombre, los campos fuente, la descripcin en lenguaje natural, y la
descripcin formal.
c.2) Una tabla con los reglas modificadas.
c.3) Una tabla que contenga las reglas borradas.
Documento 5.
Los cambios concretos en los tipos de grafos modificados. Para cada grafo
modificado, se debern incluir:
a) Cambios en los datos generales. Se deber advertir si hay algn
cambio en el nombre, las siglas, o en la descripcin en lenguaje
natural.
b) Cambios en los vrtices. Se deber incluir:
b.1) Una tabla con los tipos de vrtices aadidos que tendr un formato
similar al de las tablas de descripcin de vrtices, es decir, tendr:
el nombre del tipo de vrtice, las siglas, una descripcin en
lenguaje natural, los arcos que pueden entrar o salir de un vrtice
del tipo considerado, las multiplicidades de entrada, y las
121
multiplicidades de salida.
b.2) Una tabla con los tipos de vrtices modificados.
b.3) Una tabla donde aparezcan los tipos de vrtices eliminados.
c) Cambios en los arcos. Se deber incluir:
C.1) Una tabla con los tipos de arcos aadidos. Esta tabla tendr el
mismo formato que las tablas de descripcin de arcos, es decir,
tendr: el nombre del tipo de arco, las siglas, y una descripcin en
lenguaje natural.
C.2) Una tabla con los tipos de arcos modificados.
c.3) Una tabla que contenga con los tipos de arcos eliminados.
d) Cambios en las reglas de verificacin de la consistencia dentro del
grafo y con otros EE.CC. Se debern incluir en la documentacin las
reglas aadidas, modificadas y borradas:
Documento 6.
El nuevo grafo de referencias, que ir acompaado de una explicacin en

lenguaje natural de los cambios que se han producido con respecto al
grafo anterior.
Documento 7.
El nuevo meta-modelo completo. Este ser el documento resultado de

todos los cambios.
Despus de elaborar esta documentacin, se enva al comit de cambios para que la revise.
En caso de que le d el visto bueno, se podr utilizar para conceptualizar ontologas.
4.3.2.2
CASO PRCTICO: MODIFICACIN DE UN META-MODELO

ANTERIOR
En este apartado, se han realizado dos cambios en el meta-modelo del caso prctico de la
tarea de elaboracin de un meta-modelo desde cero (apartado 4.3.1.6) segn la propuesta de
cambios presentada en el caso prctico de la modificacin de la especificacin de un esquema
(4.2.5). Recurdese que se trataba de la incorporacin de las tablas de concepto-atributo de
clase-valor, y del aadido de la columna 'relacin' a la tabla de atributos de instancia (Figura
4.25). Es decir, por una parte, se propona realizar una tabla de concepto-atributo de clasevalor para cada uno de los conceptos en los que tomen valores los atributos de clase, la cual
incluir: el nombre de! concepto, los atributos de clase, y los valores que toman dichos
atributos. Por otra parte, para cada instancia /i de la ontologa para la que se conozca su
instancia destino k va una relacin R, habr una fila en la tabla de instancias que conecte l^
va la relacin R con 2.
122
PROPUESTA DE CAMBIOS EN META-MODELOS
Nombre del miembro del grupo que hace la propuesta

Mercedes Blzquez Cvico y Mariano Fernndez Lpez
Nombre del esquema
Esquema de modelo conceptual de oncologa de referencia versin 1.3
Descripcin de los cambios propuestos
Para poder asignar valores a los atributos de clase, se aadir al esquema una
tabla de concepto de dase-atributo valor que asigne a cada atributo de clase
el valor que toma en cada concepto. Esta tabla tendr la siguiente forma:
Concepto
Valor
Atributo de clase
Por otra parte, para poder establecer cules son las instancias de relaciones,
se aadir una nueva columna a la tabla de instancias, llamada 'relacin'. As,
cuando una instancia /i est relacionada a travs de una relacin R con otra
instancia h, siendo /i el origen e 2 el destino, habr una fila en la tabla de
instancias de la siguiente manera:
Instancia
I.
Atributo
--
Relacin
R
Valor
I2
Fecha
7 de noviembre de 1999
Figura 4,25. Propuesta de cambios en un esquema de conceptualizacin hecha en el caso prctico del
apartado 4.2.5
Para trasladar esta modificacin al meta-modelo, se genera la siguiente documentacin:

Documento 1.
La nueva ficha de descripcin general. Incluye la Tabla 4.44, donde,

como se ve, se ha indicado cules son los cambios.
Documento 2.
Los EE.CC afectados por los cambios. Contiene la Tabla 4.45 y la

Tabla 4.46, que
presentan
los EE.CC
aadidos
modificados
respectivamente.
123
Nombre del meta-modelo
Esquema 8 (MODIFICADO)
Fecha de la versin actual
Noviembre de 1999. (MODIFICADO)
Autores
Mariano Fernndez Lpez en colaboracin con Asuncin Gmez Prez, Mercedes Blzquez
Cvico y Juan Manuel Garca Pinar, que han documentado las reglas de verificacin de la
consistencia en [Blzquez, 97] y en [Garca Pinar, 98] respectivamente.
Se ha elaborando en el Laboratorio de Inteligencia Artificial (LIA) de la Facultad de Informtica
(FI) de la Universidad Politcnica de Madrid (UPM), la metodologa utilizada en el LIA para
desarrollar sistemas basados en conocimientos. Se ha comprobado su validez construyendo
ontologas en distintos dominios. Entre las ms relevantes se encuentran:
1. CHEMICALS [Fernndez, 96], [Gmez-Prez et al.; 96], [Femndez-Lpez et al.; 99], que
contiene conocimientos dentro del domino de los elementos qumicos y las estructuras
cristalinas.
2.
La Reference-Ontology [Arprez et al.; 98], una ontologa en el dominio de las ontologas

que juega el papel de una especie de pginas amarillas de ontologas. Recoge, describe y
tiene enlaces a ontologas ya disponibles, utilizando una organizacin lgica comn.
3.
La versin re-estructurada de la ontologa (KA)^ [Blzquez et al.; 98], que contiene

conocimientos sobre la comunidad cientfica en el campo de la INCO, en concreto:
cientficos, temas de investigacin, proyectos, universidades, etc.
Descripcin
Estas ontologas se han utilizado para construir aplicaciones, concretamente:
1. (Onto)^*gent [Arprez et al.; 98]. Un agente WWW sobre ontologas que utiUza la
Reference-Ontology como una fuente de su conocimiento y recoge descripciones de
ontologas que satisfacen un conjunto de restricciones dado. (Est disponible en
http://delicias.dia.fi.upm.es/OntoAgent).
Bibliografa
2.
Chemical OntoAgent [Arprez et al.; 98]. Un agente WWW que facilita a los estudiantes el
aprendizaje de la qumica y la evaluacin de sus conocimientos. Una de sus fuentes de
conocimientos es CHEMICALS.
3.
Ontogeneration [Aguado et al.; 98]. Es un sistema que utiliza una ontologa de dominio
(CHEMICALS) y otra hngstica (GUM [Bateman et al.; 95]) para generar texto en espaol
como respuesta a preguntas sobre qumica realizadas por estudiantes.
(La bibliografa referenciada est al final de esta memoria).
Tabla 4.44. Ficha de descripcin general del meta-modelo resultante
124
Nombre del elementos de

conceptualizacin
Siglas
Tipo de elemento
TCAV
Tabla concepto-atributo de clase valor
Tabla
Orientacin
Horizontal
Descripcin
Para cada uno de los conceptos en los que
tomen valores los atributos de clase,
incluir: el nombre del concepto, los
atributos de clase, y los valores que toman
dichos atributos.
Tabla 4.45. Elemento de conceptualizacin aadido al meta-modelo

Nombre del EC
Descripcin del cambio

Aparece una nueva regla de verificacin de la consistencia para
garantizar que todos los atributos de clase toman valor en algn
concepto, por lo tanto, todos los atributos de clase que aparezcan en
el diccionario de conceptos tienen que estar en la tabla de
concepto-atributo de clase-valor
Para poder establecer cules son las instancias de relaciones, se
aadir una nueva columna a la tabla de instancias, llamada
'relacin'. As, cuando una instancia l\ est relacionada a travs de
una relacin R con otra instancia h, siendo \ el origen e h el
destino, habr una fila en la tabla de instancias de la siguiente
manera:
Diccionario de conceptos
Tabla de instancias
Tabla 4.46. Elementos de conceptualizacin modificados
Documento 3.
E/ nuevo diagrama de orden de EE.CC. Es el que se presenta en la

Figura 4.26, en el que se puede observar que la nica modificacin es
el aadido de un vrtice para la tabla concepto-atributo de clase-valor,
que ir entre los rboles de clasificacin de atributos y la tabla de
instancias en la metodologa.
Documento 4.
Los cambios concretos en los tipos de tablas modificados. Se llevan a

cabo los siguientes cambios:
a. En el diccionario de conceptos se aade la siguiente regla de
verificacin de la consistencia con la tabla de concepto-atributo de
clase-valor:
Regla DC-10
Atributos de
clase
No puede haber ningin atributo de

DC.AC is included in
clase que no tome valores en algin
TCV.AC
concepto
Mtodoflexiblepara la conceptualizacin de ontologas basado en meta-modelos
125
Ficha de
descripcin
general
^r
Glosario
de
trminos
Lista de
trminos a
importar
rbol de
clasificacin
de conceptos
Diagrama de
relaciones
Diccionario
de conceptos
Tablas de
relaciones
Tablas de
atributos de
instancia
Tablas de
atributos
de clase
Tabla de
constantes
Tablas de
frmulas
Tablas de
axiomas
lgicos
1'
rboles de
clasificacin
de atributos
Tabla de
concepto de
clase-atributovalor
Tabla de
instancias
Figura 4.26. Diagrama de orden de los elementos de conceptualizacin
126
b. Para la tabla de concepto-atributo de clase-valor se crea la Tabla

4.47, la Tabla 4.48 y la Tabla 4.49 que describen sus campos
asociados, la descripcin de los campos, y las reglas de verificacin
de la consistencia.
Campo dependiente
Valor
Campo del que

depende
Atributo de clase
Tabla 4.47. Asociacin de campos en la tabla

concepto-atributo de clase-valor
Campo
Siglas
Nombre del concepto
NC
Atributo de clase
AC
Valor
Descripcin
Formato
Identificador
**
Atributos de clase
que toman valores Identificador
en el concepto
Valores que toman
los atributos de
Expresin
clase
en
el
aritmtica
concepto
Repeticin
dentro de la
misma tabla
S
(l.n)
No
(l,n)
Es principal
Multiplicidad
(1,1)
Tabla 4.48. Campos de la tabla concepto-atributo de clase-valor
Nombre
Campo fuente
Regla TCV-1
Nombre del concepto
Regla TCV-2
Atributo de clase
Regla TCV-3
Valor

Descripcin formal
Cualquier concepto debe aparecer en el
TCV.NC is included in
campo concepto del diccionario de
DC.NC
conceptos.
Si un atributo toma valor en un concepto,
entonces debe aparecer en el campo
"atributos de clase" del concepto o de
alguno sus conceptos padre. (Todava no
se puede expresar formalmente porque
hay que considerar herencia).
Cualquier trmino que aparezca en la
expresin del valor debe estar en la tabla
de constantes, en el campo "instancias"
del diccionario de conceptos, o en la lista
de trminos a importar. (Todava no
puede expresarse formalmente porque hay
que considerar subcadenas).
Tabla 4.49. Reglas de verificacin de la tabla concepto-atributo de clase-valor
c. La tabla de instancias requiere las modificaciones que aparecen

desde la Tabla 4.50 a la Tabla 4.54, la primera para la nueva
descripcin que se va a hacer del EC en el glosario de EE.CC; la
segunda, para la nueva asociacin; la tercera para el nuevo campo;
la cuarta para la modificacin en uno de los campos; y la quinta, las
RR.CC.
127
Nombre del elemento de

conceptualizacin
Siglas
Tabla de instancias
Tipo de elemento
TI
Orientacin
Tabla
Descripcin
Para cada una de las instancias del
diccionario de conceptos, incluir: el
nombre de la instancia, los atributos
con los valores conocidos en la
instancia, las relaciones que tengan
como origen la instancia, los valores
que toman los atributos, y las
instancias destino de las relaciones.
Horizontal
Tabla 4.50. Modificacin de la descripcin de la tabla de instancias en el glosario de EE.CC
Campo del que

depende
Relacin
Campo dependiente
Valor
Tabla 4.51. Nueva dependencia entre

campos que se aade a la que ya haba
Campo
Descripcin
Siglas
Relacin
Valor
Formato
Relaciones en las
que es origen la
Identificador
instancia, y sabe
cul es el destino.
Valores que toman
los atributos en la
instancia,
e
Texto
instancias que son
destino en las
relaciones.
Es principal
Repeticin
dentro de la
misma tabla
Multiplicidad
No
No
(0,n)
No
(0,1)
Tabla 4.52. Nuevo campo en la tabla de instancias

Nombre del campo que se ha sufrido el cambio
Valor
Descripcin del cambio

La descripcin en la tabla de descripcin de campos pasa a ser:
"Valores que toman los atributos en la instancia, e instancias que
son destino en las relaciones."
Tabla 4.53. Modificacin el campo 'valor' de la tabla de instancias

Nombre
Regla TI-3
Campo fuente
Relacin

Cualquier relacin que aparezca en la
tabla de instancias debe aparecer tambin
en el campo "relaciones" de alguno de los
conceptos padre de dicha instancia.
formalmente debido a la herencia).
Descripcin formal
--
Tabla 4.54. Nueva regla de verificacin de la tabla de instancias
Documento 6.
El nuevo grafo de reglas de la verificacin de la consistencia es el que

se presenta en la Figura 4.27. Se puede observar que aparece un
nuevo nudo para la tabla de concepto-atributo de clase-valor (TCV), y
aparecen las flechas que parlen y salen de este vrtice representando
las reglas de verificacin de la consistencia que le ataen.
128
Figura 4.27. Nuevo grafo de reglas de verificacin de la consistencia
Documento 3.7.
El nuevo meta-modelo completo, que es el resultado de aplicar los

cambios al meta-modelo del caso prctico de la seccin 4.3.1.6.
4.3.3 CONCLUSIONES SOBRE LA CONCEPTUALIZACION

ESQUEMA DE CONCEPTUALIZACION
DEL
El primer aporte del presente apartado ha sido la descripcin precisa del proceso de
conceptualizacin de esquemas de conceptualizacin. Tambin se ha hecho una descripcin
precisa del producto a obtener, los meta-modelos. Una derivacin importante de esto ltimo
es, como se ver en el apartado siguiente, que la transformacin del modelo conceptual del
esquema de conceptualizacin en un modelo formal del esquema de conceptualizacin se
puede llevar a cabo sin tener que aadir al modelo formal informacin que no se halle en el
modelo conceptual.
Dentro de la descripcin del mtodo de elaboracin de meta-modelos, se ha definido de
manera formal un mecanismo para especificar reglas de la verificacin de la consistencia
129
entre tablas, entre grafos, y entre tablas y gratos. La sintaxis se ha especificado utilizando una
gramtica libre del contexto, y la semntica se ha descrito haciendo uso del concepto
matemtico de matriz. Este mecanismo de descripcin formal de reglas de verificacin de la
consistencia es, aunque sencillo, muy expresivo. De hecho, la mayor parte de las restricciones
de consistencia necesarias en los distintos casos de prueba se han podido representar
formalmente.
Como se ver en el captulo de evaluacin, este mecanismo de descripcin de
conceptualizaciones ha sido aplicado para ontologas de diferentes dominios y con
distintas necesidades de modelizacin. Consecuentemente, se puede afirmar que una
notacin basada en tablas y grafos se puede utilizar para modelizar conocimientos sobre la
modelizacin de conocimientos en ontologas. Es posible modelizar tablas y grafos con
diferentes formatos y con tipos de valores complejos, por ejemplo, expresiones aritmticas e,
incluso, frmulas de lgica de primer orden.
Adems, otro de los aportes importantes de la presente seccin es un mtodo de
modificacin de meta-modelos que permite controlar los cambios de una manera ordenada y
documentada.
Se han proporcionado ejemplos que muestran cmo, partiendo de la especificacin de un
esquema de conceptualizacin de ontologas concretas, se conceptualiza dicho esquema,
obteniendo un meta-modelo, se ha presentado el del esquema de referencia, que permite
herencia mltiple, subclases en particiones exhaustivas y disjuntas, atributos de clase y de
instancia locales a los conceptos, relaciones, tambin locales a los conceptos, y tipos de
valores que pueden ser conceptos.
Con el mecanismo aqu proporcionado de elaboracin de meta-modelos, se da la posibilidad
de tener esquemas de conceptualizacin flexibles, a la medida, explcitos y declarativos.
4.4
FORMALIZACIN
CONCEPTUALIZACIN
DEL
ESQUEMA
DE
4.4.1 INTRODUCCIN
La documentacin obtenida (meta-modelo) cuando se hace la conceptualizacin del esquema
de conceptualizacin es fcil de entender y de manipular por las personas; sin embargo, dicha
documentacin no est codificada de una manera adecuada para ser procesada por un
computador, portante, es necesario transformarla. El LBIR {Language for Building Intermediate
Representations) permite precisamente especificar formalmente meta-modelos de tal manera
que puedan ser procesados por un computador, por consiguiente, se lleva a cabo una
formalizacin del esquema de conceptualizacin; es decir, se formaliza el meta-modelo
resultado de la conceptualizacin. Como se ver en la siguiente seccin, esta formalizacin
permitir generar un esquema de datos en SQL que servir como base para que la
130
conceptualizacin de la ontologa de dominio est asistida por computador.

El LBIR es igual de expresivo que el que mtodo de elaboracin de meta-modelos descrito
en el apartado anterior, por tanto, los meta-modelos se transforman en LBIR sin necesidad de
aadir nada nuevo.
Este paso de formalizacin del esquema de conceptualizacin consta de una sola tarea,
pues puede llevarlo a cabo una sola persona (Figura 4.28). En los siguientes apartados de esta
seccin 4.4, se describir la tarea, y se presentarn las conclusiones del paso de formalizacin
del esquema de conceptualizacin.


PasO:'?. Fannalizacin del

esquema de concptuaUzacin

No
ontologa de dominio
Figura 4.28. Relacin de la formalizacin del esquema de conceptualizacin con respecto al resto del
mtodo
131
4.4.2 ENTRADAS
La entrada de esta tarea es la documentacin generada en el paso de conceptualizacin del
esquema de conceptualizacin (seccin 4.3), es decir, el meta-modelo especificado mediante
tablas y gratos.

Con la realizacin de la formalizacin del esquema de conceptualizacin, se debe obtener el
meta-modelo en LBIR. En este apartado se describir el LBIR, concretamente, se expondrn
las caractersticas que debe tener el lenguaje, y se mostrar su sintaxis. Adems, en anexo III
se hace la descripcin con LBIR del esquema de referencia.
4.4.3.1
CARACTERSTICAS QUE DEBE TENER EL LENGUAJE
Las caractersticas del LBIR deben ser las que se presentan a continuacin:
1. Ha de tener
la misma expresividad
que
la documentacin
generada en
la
conceptualizacin del esquema de conceptualizacin. Por lo tanto, sobre un metamodelo de conceptualizacin debe permitir describir los siguientes aspectos:
a) Para cada tipo de tabla se debe indicar: su nombre; sus siglas; su orientacin
(horizontal o vertical); la descripcin en lenguaje natural; el orden en la metodologa; y
cules son los campos principales. Adems, para cada campo, se representar: el
nombre; las siglas; el formato (trmino, descripcin, expresin aritmtica, etc.); si est
asociado con algn otro campo; la multiplicidad; y la repeticin.
b) Para cada tipo d grato se debe especificar: su nombre; sus siglas; su descripcin en
lenguaje natural; y el orden en la metodologa. Tanibin, para cada tipo de arco, hay
que definir el nombre, las siglas y la descripcin. Adems, para cada tipo vrtice, se
especificar: el nombre, las siglas, la descripcin, los tipos de arcos que pueden
entrar o salir de un vrtice que se ajuste a este tipo; la multiplicidad de entrada de
estos arcos; y la multiplicidad de salida.
c) Para cada regla de consistencia se dar una descripcin formal.
2. Su interpretacin ha de ser fcil de automatizar.
3. Ha de ser fcil de entender por las personas que se dediquen a la formalizacin de metamodelos.
4. Dado que hoy en da la lengua que predomina claramente en el mundo de la ciencia es
el ingls, sta ser la lengua utilizada para las palabras clave del lenguaje.
132
4.4.3.2
SINTAXIS DE LBIR
4.4.3.2.1
Explicacin intuitiva de la sintaxis de LBIR
La especificacin de un nrieta-modeio en LBIR tiene la siguiente estructura:

model nombre del meta-modelo
especificacin de los EE.CC
begin
campo 1 de la ficha de descripcin general
campo 2 de la ficha de descripcin general
es decir, se nombra el meta-modelo, se definen los EE.CC (tablas y gratos), y se identifican los
campos de la ficha de descripcin general, que se asume necesaria para todos los metamodelos, y se supone tambin que debe ser siempre el primer EC a rellenar. En lo que
respecta a las especificaciones de los EE.CC, el formato de definicin de una tabla es tal y
como se presenta a continuacin:
define table tipo de tabla
nombre de la tabla as siglas
definiciones de los campos

begin
lugar en el mtodo;
campos principales;
end tabla;
donde tipo de tabla puede ser horizontal o verticat, las siglas, como siempre, es opcional; el
lugar en el mtodo es el nombre del EC que le precede o la palabra clave initiat, ios campos
principales son los nombres de stos; y cada una de las definiciones de los campos tiene la
siguiente forma:
define field nombre del campo as siglas
begin
type tipo de campo;
repeated yes o no;
multiplicidad;
associated nombre de los campos de los que depende;
end field;
donde el tipo de campo puede ser: description,
text, term, variable, number, cardinality,
logicalexp, arithmeticexp, intervalo list, que coinciden bsicamente con los formatos explicados
en la seccin 0; la repeticin del valor de un campo en la misma tabla o en tablas del mismo
tipo se indica con la palabra clave repeated seguida de yes o no; la multiplicidad se expresa
como (O, 1), (1, 1), (O, n) o (1, n); y en caso de que el campo dependa de otro, como ocurre con
133
el campo 'valor' de la tabla de instancias, que depende del campo 'atributo' y del campo
'relacin', se indica con la palabra clave associated y los nombres de estos campos de los
cuales depende. En lo referente a los gratos, stos se especifican como:
define graph nombre del grafo as siglas
definiciones de los arcos
definiciones de los vrtices
begin
lugar en el mtodo;
end graph;
siendo la definicin de cada arco como sigue:
define are nombre del arco as siglas
y siendo la definicin de cada vrtice como se presenta a continuacin:
define node tipo de vrtice as siglas
begin
type tipo de vrtice;
in: multiplicidades de entrada;
out: multiplicidades de salida;
end node;
donde el tipo de vrtice puede ser term, la multiplicidad de entrada de un arco sobre el vrtice
se escribe como
multiplicity restriccin
nombre del arco
siendo la restriccin de la forma fO, 1), (1, 1), (O, n) o (1, n) etc., imponiendo as una condicin
sobre el nmero mnimo y mximo de arcos del tipo nombre de arco que pueden entrar en
cada vrtice del tipo vrtice. De la misma manera, la multiplicidad de salida se define como
muitiplicity restriccin
nombre del arco
indicndose tambin una restriccin sobre el nmero mnimo y mximo de arcos del tipo
nombre de arco que pueden salir de cada vrtice del tipo vrtice.
Despus de la cabecera y de las definiciones de los EE.CC, se define cada regla de
verificacin de la consistencia de la siguiente manera:
define consistency nombre de la regla
description descripcin informal
begin
descripcin formal
end consistency;
134
donde la descripcin informal es texto en lenguaje natural, y el fornnato de la descripcin formal

es el mismo que se ha utilizado en la seccin 4.3.1.3.2D), en la descripcin formal de las reglas
de verificacin de la consistencia.
4.4.3.2.2
Gramtica
La sintaxis utilizada para especificar reglas de consistencia sigue la gramtica
GLBIR
<TLBIR,
NLBIR, PLBIR, ALBIR>, donde
i. Se tiene
TIBIR = {a,b,
c, d, e, f, g, h, i, j, k, I, m, n, , o, p, q, r, s. t, u, v, w, x, y, z, A, B, C, D, E, F,
G, H, I, J, K. L, M. N, O, P, Q, R, S. T, U, V, W. X, Y. Z, , . , , , , , , . .
, , -, O. 1, 2, 3, 4, 5, 6, 7, 8, 9, (, ) , [, ], ., el carcter 32 del ANS de la tabla
850}
ii. Adems,
Ni3\R = {<letra en espaol>, <guin>, <espacio>, <parntesis abierto,
cerrado,
<corchete abierto,
<corchete cerrado,
<parntesis
<punto>, <coma>,
<dgito>, <identificador>, <continuacin>, <guin o espacio,

<arco de entrada>, orco
<campo>,
de entrada>, <componente>, <proyeccin
ordenada>, <matriz>, <expresin lgica>}

iii. Para las reglas de
PLBIR se
ha hecho una descripcin por pasos que van desde las reglas
ms elementales hasta el axioma de la gramtica, que es <cdigo LBIR>. Estos pasos

son:
1.
Los objetos ms elementales que se consideran son ios caracteres ANS de la tabla
850 [DOS, 91]. Se tienen las siguientes reglas:
<carcter ANSI>
:= cualquiera de los caracteres ANS de la tabla 850 con

cdigos comprendidos entre 32 y el 254, ambos
inclusive
<letra en espaol>
:=alblcldlelflglhliljlkllllllmlnllolp
IqlrlsItlulvlwlxlylzIAIBICIDIEIFI
GIHIIIJIKILIMINIOIPIQIRISITIUIVI
WIXI
YIZIlllllIIII
<espacio>
:= el carcter 32 del ANS
<parntesis abierto
:= (
<parntesis cerrado>
:= )
<corchete abierto>
:= [
135
2.
<corchete cerrado>
:= ]
<punto>
:= .
<coma>
:= ,
<puntoycoma>
:= ;
<dos puntos>
:= :
<comillas>
:= "
<dgito>
:= 1 12 13 14 I 5 16 17 1819 I O
Con letras y espacios se pueden formar los identificadores:

<identificador>
:= <letra en espaol> {<continuacin>}

I
<continuacin>
[<letra en espaoi> {<continuacin}]
:= [<guin o espacio>] <letra en espaol>

I [<guin o espaco>] <dgito>
<guin o espaco>
3.
Utilizando combinaciones de caracteres se puede elaborar texto:

<texto>
4.
:= <guin> I <espacio>
:= {<carcter ANSI>}
Con el punto y los identificadores se definen campos:

<campo>
:= <identificador>.<identificador>
donde el primer identificador es el acrnimo de la tabla a la que pertence, y segundo

el nombre del campo.
5.
A partir de los campos y con la coma, se pueden definir listas de campos:

<lista de campos>
6.
:= <campo> [{, <campo>}]
Utilizando la palabra clave "place in method" y, o bien un identificador, o bien la

palabra clave "initiai", se puede definir el lugar que ocupa el EC en el conjunto de
EE.CC de la metodologa:
<lugar en el mtodo
:= place in <identificador> I place in initiai
donde el identificador, tal y como se ver ms adelante, es el nombre de una tabla

que se toma como antecesora en la metodologa.
7.
La multiplicidad se especifica mediante la palabra clave "multiplicity" seguida de una
136
de las siguientes indicaciones "(0,1)", "(1,1)", "(O, N)", "(1, N)":

<multiplicdad>
8.
:= multiplicity (0,1)
I
multiplicity (1,1)
multiplicity (O, N)
multiplicity (1,N)
Los tipos bsicos, para los valores que pueden tomar ios campos lo constituyen las
palabras clave: "text", "description", "term", "variable", "cardinality", "logicalexp",
"arithmeticexp", "interval", "list":
<tipo de c a m p o
9.
description
text
term
variable
cardinality
logicalexp
arithmeticexp
interval
list
Las palabras clave "horizontal" y "vertical" especifican el tipo de una tabla:

<tpo de tabla>
:= horizontal
I
vertical
10. Mediante las palabras clave "main field", la coma y los identificadores se especifica
cul o cules son los campos principales de una tabla:
<campo principal>
:= main field <identificador> [{, <identificador>}]
11. Con palabras clave, los tipos bsicos de los campos e idenficadores, se declaran los
campos:
<definicin de c a m p o
:= define field <identificador> [as <identificador>]

begin
type <tipo de c a m p o ;
repeated <s o no>;
<multiplicdad>;
[associated <identificador>;]
end field;
<s o no>
:= yes I no
12. Utilizando palabras claves, identificadores, declaraciones de campos, tipos de

tablas, el lugar dentro del mtodo y el campo principal, se describen definiciones de
137
tablas:
<definicin de tabla>
:= define table <tipo de tabla> <identificador> [as

<identificador>]
{<definicin de campo>}
begin
<lugar en el mtodo;
<campo principab;
end table;
13. Utilizando palabras clave e identificadores se definen los tipos de arco de los gratos:
<definicin de a r c o
:= define are <identificador> [as <identificador>]
14. Utilizando palabras clave, identificadores, tipos bsicos y multiplicidades se definen

los tipos de vrtice de los gratos:
<definicin de a r c o
:= define node <identificador> [as <identificador>]

begin
type <tipo de c a m p o ;
in: [{<multipiicidad> <identificador>}];
out: [{<multiplicidad> <identificador>}];
end node;
En la definicin de un vrtice no pueden estar ausentes las dos multiplicidades a la

vez.
15. Utilizando
palabras
claves,
identificadores,
declaraciones
de
arcos
las
declaraciones de vrtices, se describen las definiciones de gratos:

<definicin de g r a t o
:= define graph <identificador> [as <identificador>]

{<definicin de a r c o }
{<definicin de vrtice>}
begin
<lugar en el mtodo;
end graph;
16. Las definiciones de EE.CC constan de definiciones de tablas y de definiciones de

gratos:
<definicin de EC>
:= <definicin de tabla> I <definicin de g r a t o
17. Con el punto y los identificadores tambin se definen los arcos de entrada sobre los
vrtices y los de salida:
<arco de entrada>
:= <dentificador>.<identificador>.in.<identificador>
138
o r c o de entrada>
:= <identificador>,<identificador>.out.<identificador>
donde el primer identificador es el acrnimo del grafo, el segundo el nombre del tipo
de arco y, el ltimo, el nombre del tipo de vrtice.
18. A partir de los campos, de los arcos de entrada y de los arcos de salida sobre los
vrtices, se pueden describir los componentes de las proyecciones ordenadas:
<componente >
:= <campo> I <arco de entrada> I <arco de salida>
19. Utilizando la coma y los componentes, se pueden definir las proyecciones

ordenadas:
<proyeccin ordenada>
:= <componente> [{, <componente>}]
20. Los operadores de unin e interseccin, los parntesis y los identificadores se

combinan para definir matrices:
<matrz>
:= <matriz> unin <matriz> I (<matriz>)

I <proyeccin ordenada>
21. A partir de las matrices y del operador de inclusin, se pueden obtener expresiones
lgicas que describen formalmente las reglas de consistencia:
<expresin lgica>
:= <matriz> is included n <matriz>
22. Las reglas de consistencia se definen con palabras clave, identificadores, texto y
expresiones lgicas:
<consistencia>
:= define consistency <identificador>

[description <texto>]
begin
<expresin lgica>
end consistency;
23. El cdigo LBIR est formado por una cabecera con datos generales del modelo,
definiciones de tablas y, opcionalmente, reglas de consistencia.
<codigo LBIR>
:= modal <identificador>
{<definicin de EC>}
[{<consistencia>}]
begin
{<identificador>}
end <identificador>.
En esta regla, los identificadores que aparecen entre el begin y el end se pueden
utilizar para especificar la ficha de descripcin general del modelo.
139
Puede haber tambin comentarios encerrados entre los smbolos "/*" y "7".
iv. El axioma es <cdigo LBIR>
Sobre esta sintaxis hay que imponer dos restricciones, que ningn campo de no posible
repeticin tenga formato descripcin, y que ninguna tabla vertical puede tener campos
asociados.
Los campos que aparecen al principio de la definicin del modelo (normalmente el nombre
de la ontologa, el autor, etc.) se considerarn dentro de una tabla a la que se aaden dos
campos ms que se llamarn: identificador de la ontologa, nombre del modelo, y forma de
conceptualizar {guiada o no guiada). Tendr las siguientes caractersticas:
1. El campo principal ser el identificador de la ontologa.
2. El formato de todos los campos ser descripcin, salvo para los campos aadidos a la
ficha, es decir: identificador de la ontologa, nombre del modelo, y forma de
conceptualizar, que sern de tipo trmino.
3. La tabla tendr una sola entrada y no podr estar repetida.
4. Todos los campos sern multivaluados menos los campos aadidos a la ficha.
5. Todos los campos sern opcionales menos los aadidos a la ficha.
Como se puede comprobar, se exige que los campos de la ficha de descripcin general
cumplan el mnimo de requisitos.
4.4.3.3 EJEMPLOS EN LBIR DE DEFINICIONES DEL ESQUEMA DE

REFERENCIA
A continuacin, a modo de ejemplo, se muestra, en LBIR, la definicin del rbol de clasificacin
de conceptos y la del diccionario de conceptos del esquema de referencia, definido en el
apartado 4.3.1.6 (el esquema completo est en el anexo V).
rbol de clasificacin de conceptos:

define graph [rbol de clasificacin de conceptos] as ACC
define are [Subclase de] as S;
define are [Subclase en una particin exhaustiva] as SPE;
define are [Subclase en una particin disjunta] as SPD;
define node Concepto as C
begin
type term;
in: multiplicity (0,N) S,
multiplicity (0,N) SPE,
multiplicity (0,N) SPD;
out: multiplicity (0,N) S,
140
.multiplicity (0,N) SPD ;

end node ;
begin
placed in [Glosario de trminos] ;
end graph ;
Diccionario de conceptos:
define table horizontal [Diccionario de conceptos] as DC
define field [Nombre del concepto] as NC
begin
type term;
repeated no;
multiplicity (1,1);
end field ;
define field Sinnimos as S
begin
type term;
repeated no;
multiplicity (0,N);
end field;
define field Abreviaturas as A
begin
type term;
repeated no;
multiplicity (0,N);
end field;
define field Instancias as I
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field [Atributos de clase] as AC
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field [Atributos de instancia] as Al
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field Relaciones as R
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
begin
141
placed in DR;
main field [Nombre del concepto];
end table;
Reglas de verificacin de la consistencia:
Las reglas que se van a mostrar son algunas de las que se establecen entre las
representaciones de los ejemplos anteriores, es decir, rbol de clasificacin de conceptos y
diccionario de conceptos.
define consistency [Regla A CC-2_ 1]
description "Cualquier trmino que aparezca en un nudo 'concepto' del que sale un arco
'subclase de' tiene que aparecer en el campo 'nombre del concepto' del diccionario de
conceptos"
begin
ACC.S.out.Concepto is included in DC.NC
end consistency
define consistency [Regla DC-1 simplificada]

description "El nombre del concepto tiene que ser un nudo del rbol de clasificacin de
conceptos, pues el diccionario de conceptos muestra los detalles de los conceptos
incluidos en el rbol de clasificacin de conceptos"
begin
DC.NC is included in ACC.S.in.Concepto unin ACC.S.out.Concepto
end consistency

A la hora de transcribir el meta-modelo a LBIR, se aconseja seguir el orden establecido en el
diagrama de orden que aparece en el mismo meta-modelo. De esta forma, el cdigo ser ms
legible, porque quien tenga que examinarlo se encontrar los EE.CC en el mismo orden en que
se van rellenando en la metodologa.

Esta tarea la llevan a cabo conocedores sobre conceptualizacin que estn familiarizados con
el LBIR.
4.4.6 CONCLUSIONES SOBRE LA FORMALIZACIN DEL ESQUEMA

DE CONCEPTUALIZACIN
En esta seccin se ha mostrado cmo formalizar un meta-modelo, que describe cmo
conceptualizar una ontologa, utilizando LBIR. Estos meta-modelos describen las tablas y los
gratos que se van a utilizar en la conceptualizacin de la ontologa de dominio, el orden en que
se van a ir rellenando, los formatos de los campos, las reglas de la verificacin de la
consistencia, etc.
142
Precisamente, el aporte ms importante de esta seccin es la elaboracin de LBIR. Este

lenguaje no slo tiene la misma expresividad que la documentacin propuesta en el
apartado
4.3.1.3
para
describir
meta-modelos,
sino
que,
adems,
permite
una
transformacin muy sencilla del modelo conceptual de alto nivel en el modelo formal de alto
nivel. Por otra parte, este lenguaje es fcil de entender y, al mismo tiempo, puede ser
procesado por un computador. De hecho, se ha especificado utilizando una gramtica libre del
contexto. Consiguientemente, con LBIR, no slo se puden modelizar los esquemas de
conceptualizacin de manera explcita y declarativa, sino que tambin tales esquemas son
directamente computables. Adems, este lenguaje es independente de la tecnologa que se
vaya a utilizar para almacenar las ontologas (ficheros ASCII, bases de datos relacinales,
etc.). Esto ltimo tiene la ventaja de que varios grupos pueden usar el mismo esquema
computable de conceptualizacin y, sin embargo, cada grupo puede utilizar la tecnologa de
almacenamiento que ms le conviene. No obstante, obliga a tener traductores de LBIR al
formato de representacin interna que se utilice, por ejemplo, el lenguaje de definicin de datos
del SQL. Por esta razn, en el apartado 4.5 se proponen las reglas de traduccin de LBIR en
SQL, que son las reglas que rigen el mdulo de procesamiento de LBIR de ODE (seccin 4.8).
En lo referente al tipo de conocimientos que mejor se modelizan con LBIR, se puede decir
que ste permite modelizar conocimiento esttico sobre EE.CC, encapsulando en la definicin
de cada EC su informacin sobre las caractersticas de los campos, los vrtices y los arcos, lo
que dota de una estructura bien ordenada a las especificaciones de los meta-modelos
realizadas en este lenguaje. LBIR tambin permite modelizar restricciones a travs de las
reglas de verificacin de la consistencia entre EE.CC del mismo tipo de tipos diferentes. Tal y
como se ha dicho en el apartado 4.3.1.3.2D), estas reglas tienen una sintaxis sencilla, son
fciles de entender y, al mismo tiempo, son muy expresivas. De hecho, la experiencia
elaborando meta-modelos en los ltimos aos ha comprobado que raras veces una restriccin
en las referencias cruzadas de los EE.CC no puede representarse utilizando la sintaxis del
lenguaje formal.
Adems de las restricciones fomnalizadas a travs de las reglas de verificacin de la
consistencia, se especifican otras restricciones a travs de los formatos de los campos.
Otra caracterstica de esta formalizacin es que no se tienen definidos mecanismos para
deducir unos conocimientos a partir de otros, salvo el cumplimiento o no de las reglas de
verificacin de la consistencia, y de las restricciones definidas en los formatos de los campos.
4.5
IMPLEMENTACIN
CONCEPTUALIZACIN
DEL
ESQUEMA
DE
4.5.1 INTRODUCCIN
Segn el mtodo bi-fase de conceptualizacin flexible, una vez que se tiene codificado en LBIR
el meta-modelo que se va a seguir en la conceptualizacin de la ontologa de dominio, es
143
necesario transformarlo en un esquema de datos que describa una estructura de datos

adecuada para el almacenamiento y el procesamiento, por parte de un computador, de la
conceptualizacin de la ontologa.
Dado que este paso de implementacin del esquema de conceptualizacin est
condicionado por la tecnologa que se va a utilizar, se han considerado distintas opciones
tecnolgicas: usar ficheros ASCII, utilizar un sistema gestor de bases de datos relacinales
(BB.DD.RR) [Codd, 70], o almacenarlas utilizando alguno de los entornos ya disponibles para
implementar ontologas. Cuando se manipula una cantidad grande de datos, la primera de las
opciones es problemtica, pues el alracenamiento de informacin en ficheros y su
manipulacin utilizando directamente las funciones que proporciona el sistema operativo para
el tratamiento de stos, plantea el inconveniente de tener que programar el mantenimiento de
las relaciones entre datos, las restricciones de acceso a usuarios, etc. Por otra parte, la
segunda opcin puede aprovechar las siguientes ventajas [Fernndez Lpez, 99b]:
1. Independencia de los datos. Se podra definir como la inmunidad de las aplicaciones que
utilicen la base de datos (BD) a cambios en la estructura de almacenamiento o en las
estrategias de acceso a la informacin.
2. Minimizacin de la redundancia y del espacio de almacenamiento. Permiten encontrar un
equilibrio entre la necesidad de mantener informacin redundante para agilizar los
accesos a la informacin, y la necesidad de reducir la cantidad de espacio de
almacenamiento utilizado. Hay que tener en cuenta, adems, que la redundancia lleva
asociada el peligro de inconsistencias, es decir, que las distintas copias de un mismo
dato no coincidan.
3. Integridad de los datos. En general, toda BD debe satisfacer ciertos requisitos
semnticos a los que se llama restricciones de integridad. Los SS.GG.BB.DD dan la
posibilidad de controlar automticamente la correccin de la BD siempre que se
produzca la insercin, modificacin o borrado de datos, es decir, proporcionan un
mecanismo sencillo de garantizar el cumplimiento de las restricciones de integridad,
rechazando las operaciones que alteren la consistencia semntica de la BD.
4. Comparticin de datos. Permiten el uso compartido de los datos por varios usuarios,
ofreciendo a cada uno de ellos la sensacin de ser el nico usuario.
5. Seguridad de los datos. Proporcionan mecanismos para garantizar la seguridad fsica de
los datos ante fallos en el sistema (por ejemplo, cadas de tensin), y tambin facilitan la
proteccin
ante
operaciones
no
autorizadas,
especialmente
las
que
implican
actualizaciones de la BD.
6. Se puede utilizar el SQL para acceder a los datos. Se trata de un lenguaje muy utilizado,
por lo que se facilita el acceso desde otras aplicaciones.
144
Sin embargo, la opcin de ontologas en BB.DD.RR tiene el inconveniente de la limitacin a

la hora de hacer inferencias. Por ejemplo, en una BD donde se tenga la siguiente tabla
PersonafPNI. Nombre, Primer apellido, Segundo apellido, #DNI del padre)
no existe ninguna operacin del lgebra relacional que permita obtener de una sola vez los
antecesores de una persona: su padre, su abuelo, su bisabuelo, etc.
La ltima opcin, almacenar ontologas utilizando algn entorno software de construccin de
ontologas puede resolver en algunos casos el problema de la inferencia; pero, estos entornos
suelen utilizar ficheros clsicos para almacenar los conocimientos, por consiguiente, arrastran
algunos de sus inconvenientes.
Considerando todo lo anterior, una solucin buena, y que, por tanto, es la que se asume en
este mtodo, puede ser almacenar las ontologas en BB.DD.RR, y disponer de traductores
para pasarlas a lenguajes con entornos software que tengan un motor de inferencias potente.
Como se ver en la seccin 4.8 de la memoria, como consecuencia de esta decisin en el
plano metodolgico, la opcin de BB.DD.RR y traductores es la implantada en ODE y, en
consecuencia, se ha hecho un aporte Importante con respecto a los entornos anteriores de
desarrollo de ontologas (Cyc [Lenat et al.; 90], [Lenat, 95], Ontolingua Se/ver [Farquhar et al.;
96], Ontosaurus [Swartout et ai.; 97], etc.), que generalmente almacenan las ontologas en
ficheros ASCII.
A la hora de generar, en este paso de implementacin del esquema de conceptualizacin,
esquemas relacinales a partir de meta-modelos en LBIR, primero se obtiene el esquema
entidad relacin (ER) [Chen, 76], luego, a partir de ste, se obtiene el esquema relacional
[Codd, 70] en cdigo intermedio y, por ltimo, se genera el esquema en la versin SQL que se
vaya a utilizar. Es decir, se llevan a cabo los tres pasos clsicos de anlisis, diseo e
implementacin del software tradicional.
La transformacin en distintas fases de cdigo LBIR en un esquema relacional hace que la
implementacin del esquema de conceptualizacin tenga tres tareas (Figura 4.29): anlisis del
cdigo LBIR (generacin del esquema ER), diseo del esquema de datos (generacin del
esquema relacional y de las reglas de verificacin de la consistencia en lgebra relacional), e
implementacin del esquema de datos (generacin del SQL).
Las razones por las que se propone un procedimiento en tres fases son las siguientes:
1. Fiabilldad de las reglas de transformacin. Por una parte, se ha encontrado un
procedimiento sencillo de transformacin de cualquier meta-modelo LBIR en un
esquema relacional. Por otra parte, aunque haya sido necesaria una adaptacin en este
trabajo, la transformacin de un esquema ER cualquiera en un esquema relacional est
muy estudiada ([Luque Ruiz et al.; 97], [Lpez Ruiz, 98], [Korth, 93], etc.). Adems, la
145
INICIO

PASO 4.
IMPLEMENTACIN DEL
ESQUEMA DE
CONCEPTUALIZACIN
Tarea 4.1. Anlisis del cdigo
LBIR
Tarea 4.2. Diseo del esquema

de datos
Paso 3. Forraalizacin del

Tarea 4.3. Implementacin del

esquema de datos
No
ontologa de dominio
Figura 4.29. Relacin de las tareas de implementacin del esquema de conceptualizacin con el resto del
mtodo de conceptualizacin
generacin del SQL a partir de un esquema relacional es inmediata. Estas circunstancias

facilitan la flabilidad de la transformacin de un meta-modelo LBIR en un esquema
relacional.
Otro hecho que apunta en este sentido es que, en algunos prototipos de ODE, se ha
comprobado la viabilidad de la transformacin directa de cdigo LBIR a SQL, y el
software obtenido ha sido menos robusto que el de los prototipos que implementan la
transformacin en tres fases.
2. La flexibilidad de la transformacin. Por una parte, el modelo ER es un modelo de
146
anlisis y, consecuentemente, en principio independiente de la tecnologa. Es decir, en

caso de que se produzca una evolucin en la tecnologa, no habr que cambiar las
reglas de transformacin del LBIR en el ER.
En lo concerniente a la separacin entre generacin del esquema relacional y la
generacin del SQL, es necesario advertir que no todos los gestores de bases de datos
se ajustan exactamente a los mismos patrones del lenguaje. En consecuencia, la
distincin entre el diseo del esquema relacional y la impiementacin SQL se hace
necesaria para no tener que cambiar las reglas de transformacin del ER para cada
variante del SQL.
Adems de la transformacin de la estructura de los EE.CC, tambin es necesario hacer
una conversin de las reglas de verificacin de la consistencia. stas se transforman en dos
pasos, uno para expresarlas en forma de lgebra relacional, y otro para expresarlas en SQL.
Esto se debe a que en el nivel de anlisis, las reglas de consistencia pueden permanecer igual
que en la especificacin del meta-modelo, asumiendo que las reglas en el nivel de anlisis
hacen referencia, no ya a valores que toman los campos en las tablas, sino a los que toman los
atributos en las ocurrencias de las entidades.
En los siguientes apartados, para cada una de las tareas de impiementacin del esquema
de conceptualizacin
(anlisis del cdigo LBIR, diseo del esquema de datos, e
impiementacin del esquema de datos) se har una introduccin, se mostrarn cules son las
entradas y los productos obtenidos, se presentar el procedimiento para llevarlas cabo, y se
especificar quin (ms bien qu entorno software) tiene que realizarlas. La seccin terminar
con unas breves conclusiones referentes a este paso de impiementacin del esquema de
conceptualizacin.
4.5.2 ANLISIS DEL CDIGO LBIR

4.5.2.1
INTRODUCCIN
En esta seccin se expone cmo se puede obtener un esquema ER a partir de un meta-modelo

descrito en LBIR.
4.5.2.2
ENTRADAS
Un meta-modelo descrito en LBIR, que es el lenguaje descrito en el apartado 4.4.3.
4.5.2.3
PRODUCTOS OBTENIDOS
Se obtiene un esquema ER que modeliza el meta-modelo a transformar. Ahora bien, en este

trabajo se propone una extensin del modelo entidad-relacin para que ste pueda expresar
todo aquello que pueda aparecer en una especificacin en LBIR. Por consiguiente, en esta
seccin se presentarn algunas de las limitaciones que tiene el ER, y cmo salvarlas.
147
4.5.2.3.1 Limitaciones del modelo entidad relacin con respecto a la

expresividad de LBIR
El modelo entidad-relacin, tal y como se suele presentar normalmente ([Luque Ruiz et al.; 97],
[Lpez Ruiz, 98], [Korth, 93], etc.), es menos expresivo que LBIR, al no contemplar los
siguientes detalles que el LBIR s puede describir:
1. El dominio de valores de los atributos (cadena de caracteres, nmero, etc.).
2. Si un atributo tiene que tomar valores necesariamente en todas las ocurrencias de la
entidad, es decir, si es obligatorio u opcional.
3. Si el valor de un atributo se puede repetir en varias ocurrencias de la entidad.
4. Las referencias cruzadas entre los valores de las ocurrencias de distintas entidades.
4.5.2.3.2 Extensin propuesta para el modelo entidad-relacin

En la generacin del modelo ER, el computador toma como entrada cdigo en LBIR y lo
transforma en un esquema ER. Ahora bien, tal y como se ha dicho en el apartado anterior, la
representacin grfica del modelo ER tiene el inconveniente de que no refleja todos los detalles
que s es capaz de reflejar el LBIR, es decir, su expresividad es menor. Adems, no estn
explcitas todas las caractersticas que se deben considerar para tener formalizado el ER y, por.
tanto, no queda clara cul debe ser la salida del proceso. Por estas razones, en este trabajo se
propone una representacin tabular para acompaar el grafo de entidades y relaciones. Se
construirn las siguientes tablas:
1. Una tabla de entidades con los siguientes campos:
a) Es entidad dbil, que tomar yaior por identificacin, slo por existencia, o no para cada
entidad.
b) Entidad que identifica a la entidad dbil, donde aparecer el nombre de la entidad cuyas
ocurrencias identifican a las ocurrencias de la entidad dbil.
c) Atributos de la entidad que est describiendo.
d) Atributos identificadores, donde aparecer la lista de atributos que sirven para identificar
las distintas ocurrencias de la entidad.
2. Una tabla de relaciones que tendr estos campos:
a) Entidades que asocia la relacin.
b) Cardinalidades de las entidades participantes.
c) Atributos de la relacin.
d) Atributos identificadores, donde aparecer la lista de atributos que sirven para identificar
148
la.distintas ocurrencias.
3. Una tabla de atributos por cada entidad y cada relacin con atributos que tendr los
siguientes campos:
1) Dominio descrito mediante lenguaje natural o mediante una expresin formal.
2) Opcional, que valdr s/'en caso de que el atributo pueda no tomar ningn valor, y valdr
no en otro caso.
3) Multivaluado, donde se indicar si el atributo puede tomar ms de un valor en una misma
ocurrencia de la entidad o de la relacin.
4) Repeticin, que indicar si el valor del atributo se puede repetir en varias ocurrencias de
la entidad a que pertenece.
4. Una tabla de restricciones, donde se mostrarn las reglas que han de satisfacer los datos en
todo momento, aparte de las descritas en otras tablas (repeticin, multiplicidad, etc.). Tendr
un nombre para cada restriccin, su descripcin, su descripcin en lenguaje natural y, en
caso de que sea necesario, su descripcin formal.
4.5.2.4
Se parte de un meta-modelo representado en LBIR, y se pretende generar un modelo entidadrelacin que represente la misma informacin. Fruto de la experiencia desarrollando diferentes
prototipos de ODE, se proponen las siguientes transformaciones:
1. Por cada tabla del meta-modelo se crear una entidad que represente al concepto "erna
de esa tabla", siendo el conjunto de valores de cada entrada de la tabla las distintas
ocurrencias de la entidad, y siendo cada campo de la tabla un atributo de la entidad. En
concreto, las reglas para transformar las tablas en el modelo ER sern:
RT.1.
Cada tabla del meta-modelo se transforma en una entidad, que representar al

concepto "erna de la tabla".
RT.2.
Cada campo de cada tabla que no tenga otros asociados se transforma en un

atributo que tendr las siguientes caractersticas:
i) El dominio del atributo ser el tipo del campo de la tabla a partir del cual se ha
generado.
ii) Si existe una indicacin de que el campo no puede estar repetido en la tabla,
esta indicacin se transforma en una restriccin sobre los valores del atributo,
no pudindose repetir en diferentes ocurrencias.
iii) Si el campo tiene multiplicidad mxima O en la tabla, entonces el atributo ser
opcional.
149
iv) Si el campo tiene multiplicidad mxima n, entonces el atributo ser

multivaluado.
RT.3.
Cada campo principal en la tabla pasa a ser un atributo identificador en la

entidad;
RT.4.
Si un campo C^ de una tabla tiene otro dependiente C2, se aplicarn las reglas
que se muestran a continuacin:
RT.4.1.
Ci pasa a ser una entidad dbil que depende de la entidad generada a

partir de la tabla segn la regla R.1; la entidad ser dbil por
identificacin si Ci se puede repetir, y slo por existencia en caso
contrario;
RT.4.2.
La cardinalidad mxima de la entidad dbil ser n si el C^ es

multivaluado, y 1 en caso contrario.
RT.4.4.
La cardinalidad mxima de la entidad fuerte ser n si C^ puede estar

repetido, y 1 en caso contrario.
RT.4.5. La cardinalidad mnima de la entidad fuerte ser 1.

RT.4.6.
La cardinalidad mnima de la entidad dbil depender de si C^ es

opcional o no, en el primer caso ser O, y en el segundo ser 1.
RT.4.7.
La entidad dbil tendr como atributos Ci y C2. El atributo de Ci ser el

identificador de la entidad, y el atributo generado a partir de C2 tendr
las siguientes caractersitcas:
i) el dominio delatributo ser el tipo del campo de la'tabla a partir del
cual se ha generado;
ii) Si C2 tiene multiplicidad mnima O en la tabla del meta-modelo,
entonces ser un atributo opcional en la entidad, en caso contrario
ser obligatorio.
iii) Si C2 tiene multiplicidad mxima n en la tabla del meta-modelo,
entonces ser un atributo multivaluado en la entidad.
iv) Una indicacin sobre C2 de repeticin igual a "no" en la tabla del
meta-modelo se transformar en una restriccin sobre los valores
del atributo
asociado,
no pudindose
repetir
en
diferentes
ocurrencias;
2. Por cada grato del meta-modelo se utilizarn las siguientes reglas:
RG.1.
Se crear una entidad cuyas ocurrencias sern los distintos vrtices del grafo.
150
Dicha entidad tendr como atributos el tipo y el nombre del vrtice, que sern
identificadores.
RG.2. Se crear una relacin de la entidad vrtice de ese grafo consigo misma que
tendr un atributo identificador: tipo de arco. La transformacin de las
multiplicidades que tienen los arcos en los vrtices se dejar para una versin
posterior del mtodo.
Las cardinalidades de las entidades en todas las relaciones generadas en
esta regla sern (O, n).
Segijn las reglas anteriores, el nico tipo de restriccin que se genera es aquella que impide
que el valor de un atributo aparezca en varias ocurrencias distintas de la misma entidad.
Fecurdese que las reglas de la verificacin de la consistencia no es necesario transformarlas
hasta la tarea de diseo.
4.5.2.5
Elsta tarea la puede realizar cualquiera utilizando el software adecuado, pues est pensada
para ser realizada automticamente.
4.5.2.6
EJEMPLO DE GENERACIN DE UN ESQUEMA ENTIDAD

RELACIN A PARTIR DE UN META-MODELO EN LBIR
En la Figura 4.30 y desde la Tabla 4.55 y a la Tabla 4.60 se muestra el modelo ER del rbol de
clasificacin de conceptos y del diccionario de conceptos del esquema de referencia, es decir,
ios EE.CC que aparecen en el ejemplo de la seccin 4.4.3.3.
(O.n)
EmaDC
Nombre del concepto
Sinnimos (N)
Abreviaturas (N)
Instancias (N)
Atributos de clase (N)
Atributos de instancia (N)
Relaciones (N)
C
Vrtice del ACC
Nombre del vrtice
TDO de vrtice
(O.n)
Tipo de arco
^ ^
^^^
Arc()del
^ . ^
A(: c
^ ' \ ,
^ y ^
Figura 4.30. Representacin grfica del modelo ER del rbol de clasificacin de conceptos y del
diccionario de conceptos del esquema de referencia
151
Entidad
que
identifica
ala
entidad
dbil
Es entidad dbil
EmaDC
No
--
Vrtice del ACC
No
--
Atributos
Atributos identificadores
Nombre del concepto

Sinnimos
Abreviaturas
Instancias
Atributos de clase
Atributos de instancia
Relaciones
Nombre del vrtice
Tipo de vrtice
Nombre del concepto
Nombre del vrtice

Tipo de vrtice
Tabla 4.55. Tabla de entidades del modelo entidad relacin generado
Relacin
Entidades que asocia
Arco del ACC Vrtice del ACC
Cardinalidades
Atributos
Atributos
identifcadores
(0,n)
(0,n)
Tipo de arco
Tipo de arco
Tabla 4.56. Representacin tabular de las relaciones obtenidas
EmaDC
Nombre del
concepto
Sinnimos
Abreviaturas
Instancias
Atributos de clase
Atributos de
instancia
Relaciones
Opcional
Multivaluado
Repetido
Sigue la gramtica de <term>
No
No
No

S
S
S
S
S
S
S
S
No
No
S
S
Dominio
Tabla 4.57. Representacin tabular de los atributos de la entidad ema DC
Vrtice del ACC

Nombre del vrtice
Tipo de vrtice
Dominio
Opcional
No
No
Multivaluado
No
No
Repetido
S
S
Tabla 4.58. Representacin tabular de los atributos de la entidad Vrtice del ACC
Arco del ACC

Tipo de arco
Dominio
Opcional
No
Multivaluado
No
Repetido
S
Tabla 4.59. Representacin tabular de los atributos de la relacin Arco del ACC
Restriccin
Descripcin informal
Un sinnimo no puede
No repeticin de los aparecer en ms de una
ocurrencia de la entidad
sinnimos
emaDC
Una abreviatura no
No repeticin de las puede aparecer en ms
de una ocurrencia de la
abreviaturas
entidad ema DC
Descripcin formal
lJnico(sinnimos, ema-DC)
lJnico(abreviaturas, ema-DC)
Tabla 4.60. Restricciones generadas
152
4.5.3 DISEO DEL ESQUEMA DE DATOS

4.5.3.1
INTRODUCCIN
Una vez que se ha transformado el meta-modelo en LBIR en un esquema ER, el siguiente paso
consiste en transformar este ER en un esquema relaciona!. Mientras que las reglas de la
primera tarea son completamente propias, para elaborar las reglas de esta tarea se ha
aprovechado la circunstancia de que son muchos los libros de bases de datos que proponen
reglas de transformacin de un esquema ER en un esquema relacional (por ejemplo [Luque
Ruiz et al.; 97], [Lpez Ruiz, 98] y [Korth et al.; 93]). Estas reglas que aparecen en estos libros
son tiles para los analistas que deben disear bases de datos; sin embargo, esta conversin
en el presente mtodo bi-fase de conceptualizacin est pensada para ser realizada de manera
automtica, por lo tanto, ha sido necesario elaborar unas reglas ms detalladas que las que
aparecen en estos textos.
4.5.3.2
ENTRADAS
El esquema ER generado en la tarea de anlisis del cdigo LBIR, y las reglas de la verificacin
de la consistencia en LBIR. Recurdese que las reglas de verificacin de la consistencia no
sufren ninguna transformacin hasta este paso de generacin del diseo.
4.5.3.3
PRODUCTOS OBTENIDOS
El esquema relacional en cdigo intermedio, y las expresiones, tambin en cdigo intermedio,

de las reglas de consistencia expresadas en lgebra relacional. En esta memoria, la notacin
que se va a utilizar es la siguiente:
a) Las relaciones del esquema relacional se representarn como una erna etiquetada con
el nombre de la relacin. Adems, los atributos de las claves principales Irn subrayados,
y los de las claves ajenas acompaados del smbolo sostenido (#). Por ejemplo, la tabla
7con atributos A1, A2, A3 y A4 donde Al y A2forman parte de la clave principal, y A3
es una clave ajena, se representa as
nA1.A2. #A3, A4)
b) Para las operaciones de lgebra relacional se seguir la siguiente nomenclatura:
b.1) La unin de relaciones se expresa con el smbolo u .
b.2) La reunin, unin natural ojoin se simboliza con un asterisco (*).
b.3) La diferencia se representa con el guin (-).
b.4) La proyeccin se simboliza con la pi mayscula (n).
b.5) La seleccin se nota con la sigma minscula (a).
153
b.6) El resto de las operaciones del lgebra relacional no son necesarias en esta versin
del nntodo.
4.5.3.4
En esta seccin se presentarn las reglas para obtener las tablas del esquema relacional a
partir del esquema ER; luego, se mostrar un ejemplo de aplicacin de estas reglas; a
continuacin se presentarn las reglas de generacin de las reglas de verificacin de la
consistencia en lgebra relacional; despus, se mostrar un ejemplo de aplicacin de estas
reglas; y, por ltimo, se expondrn las caractersticas del esquema relacional obtenido.
4.5.3.4.1 Reglas de generacin de las tablas y las vistas del esquema

relacional
A la hora de generar las tablas y las vistas, se hace una transformacin previa dentro del
mismo esquema entidad relacin para facilitar la obtencin del esquema relacional. Por esta
razn, la primera de las reglas que se muestran a continuacin est numerada con 0.
Las reglas de transformacin que se proponen, utilizadas en la construccin de ODE, y
aplicadas en la transformacin de esquemas con distintas caractersticas, son las siguientes:
R.O.
Se parte de un modelo ER y se transforman los atributos multivaluados en entidades

dbiles. Este ER modificado es el que servir de entrada en las reglas R.1 y
sucesivas. As, las modificaciones propuestas para el ER original son las siguientes:
R.0.1. Cada atributo multivaluado del modelo ER original pasa a ser una entidad
dbil en el ER modificado. Si un valor del atributo multivaluado puede estar
repetido en distintas ocurrencias de la entidad sobre la que estaba definido, la
entidad generada ser dbil por identificacin, y si no, slo por existencia.
R.O.2. La cardinalidad mxima de la entidad dbil obtenida ser n.
R.0.3. La cardinalidad mxima de la entidad fuerte ser n si el atributo multivaluado
que ha generado la entidad dbil poda estar repetido, y 1 en caso contrario.
R.0.4. La cardinalidad mnima de la entidad fuerte ser 1.
R.0.5. La cardinalidad mnima de la entidad dbil obtenida depender de si el
atributo del que proviene es opcional, o no. En el primer caso ser O, y en el
segundo ser 1.
R.0.6. La entidad dbil tendr como atributo el atributo multivaluado por el cual la
regla se ha aplicado.
R.0.7. Si el atributo multivaluado poda estar repetido en la entidad de donde
proviene en el ER original, entonces la entidad generada es dbil por
identificacin, y si no, slo por existencia.
154
R.l.
Cada entidad del modelo ER modificado se transformar en una tabla del modelo
relacional, siendo su clave el conjunto de atributos identificadores. A las tablas de las
entidades dbiles se les aade como atributos la clave primaria de las entidades
fuertes de la que dependen, estos atributos pasan a ser una clave ajena y formarn
tambin parte de la clave principal si y slo si la entidad es dbil por identificacin.
R.2.
A las tablas del modelo relacional obtenidas de las entidades dbiles del ER hay que
aadirles otros atributos adems de su identificador siguiendo las reglas que se
presentan a continuacin:
R.2.1
Se les aadir como atributos la clave primaria de las entidades fuertes de la

que dependen las entidades dbiles.
R.2.2. Los atributos aadidos pasan a ser una clave ajena y a formar parte de la
clave principal de la tabla.
R.2.3. La clave ajena de la tabla del modelo relacional formar parte de la clave
principal si y slo si la entidad de la que se ha obtenido esta tabla es dbil por
identificacin en el modelo ER.
R.3.
Aquellas relaciones que no asocien entidades dbiles con otras fuertes, se

transforman en una tabla que tendrn como atributos los identificadores de las
relaciones que asocian. Estos atributos formarn parte de la clave ajena y de la clave
principal de la tabla.
R.4.
Cada relacin con atributos se transformar en una tabla que tendr como
identificadores los de las entidades que asocie y, adems, aquellos atributos de la
relacin que sean tambin identificadores. Los atributos heredados de las entidades
sern claves ajenas.
R.5.
Puesto que al hacer las transformaciones anteriores algunas tablas quedan

descompuestas en varios esquemas del modelo relacional, para que esta
descomposicin quede oculta a los usuarios, se crear una vista por cada tabla
afectada que ser de la forma:
r i * Ta *... * fn
donde cada 71 es la tabla en que ha quedado descompuesta la original, y "*" es la
unin natural.
R.6.
Si en el modelo ER hay una restriccin que impide que el valor de un atributo

aparezca en varias ocurrencias distintas de la misma entidad, entonces cuando se
est operando con el modelo relacional, antes de insertar cualquier valor del atributo
en la tabla o vista correspondiente a la entidad, hay que comprobar que este valor no
se ha introducido previamente.
155
4.5.3.4.2 Ejemplo de generacin de tablas y las vistas del esquema

relacional
La representacin grfica del modelo obtenido aplicando la regla O al esquema ER de la Figura
4.30 est en la Figura 4.31, y la transformacin de este modelo modificado genera las
siguientes tablas relacinales y vistas:
(0,n)
DC-Sinnimos
Sinnimos
(0,n)
DC-Abreviaturas
Abreviaturas
(O.n)
DC-Instancias
Instancias
EmaDC
(0,n)
DC-Atributos de clase
Atributos de clase
Nombre del concepto

(O.n)
DC-Atributos de instancia
(O.n)
DC-Relaciones
Relaciones
(O.n)
C
Vrtice del ACC
Tipo de vitice
(O.n)
Tipo de arco
^
^ ^
<c
Arco del
ACC
^ \ ^
^ y ^
Figura 4.3 L Representacin grfica del modelo ER obtenido modificando el de la Figura 4.30
156
A) Tablas relacinales
Erna-DC(Nombre del concepto)
DC-Sinnimos(#Nombre del concepto, Sinnimos)
DC-Abreviaturas(#Nombre del concepto, Abreviaturas)
DC-lnstancias(#Nombre del concepto. Instancias)
DC-Atrbutos de clase(#Nombre del concepto. Atributos de clase)
DC-Atributos de instancia(#Nombre del concepto. Atributos de instancia)
DC-Relaciones(#Nombre del concepto. Relaciones)
Vrtice-del-ACC(Nombre del vrtice. Tipo de vrtice)
Arco-del-ACC(#Nombre-del-vrtice-del-aue-sale. #Tipo-de-vrtice-del-aue-sale. Tipo-de-arco.
#Nombre-del-vrtice-al-aue-entra. #Tipo-de-vrtice-al-aue-entra)
B) Vistas
Con las vistas se pretende que el usuario vea el contenido de la ontologa desde la perspectiva
de los EE.CC del meta-modelo que est utilizando, y no desde la perspectiva del
almacenamiento en las tablas generadas. As, por ejemplo, la vista sobre el diccionario de
conceptos es la reunin de todas las tablas en que se ha descompuesto.
Vista-DC = Erna-DC * DC-Sinnimos * DC-Abreviaturas * DC-Instancias * DC-Atributos de
clase * DC-Atributos de instanica * DC-Relaciones.
4.5.3.4.3 Generacin de las reglas de consistencia expresadas en lgebra

relacional
Tal y como se ha visto en el apartado 4.3.1.3.2D), las reglas de la verificacin de la
consistencia se pueden definir formalmente como inclusiones de matrices, haciendo referencia
a la representacin matricial de los EE.CC. Ahora bien, puesto que una matriz se puede ver
como una erna de ernas y, en el modelo relacional, una relacin se puede ver como un
conjunto de ernas, se tiene que las matrices slo se diferencian de las relaciones del modelo
relacional en los siguientes aspectos:
1. En las matrices importa el orden de las ernas, mientras que en el modelo relacional no.
2. En las matrices importa el orden de las componentes de las ernas, mientras que en el
modelo relacional no^.
3. En las matrices cada componente es un conjunto de valores, mientras que en el modelo
Esta caracterstica del modelo relacional no se deriva de la definicin matemtica de relacin, pues sta
es un subconjunto del producto cartesiano, y ste no es conmutativo.
157
relacional los valores de las componentes de las ernas son nicos.

De lo anterior se deriva que las reglas de transformacin de las reglas de verificacin de la
consistencia en operaciones del lgebra relacional son:
R.1.
Cada proyeccin ordenada sobre una matriz asociada a un EC pasa a ser una
proyeccin en la tabla relacional (o en la vista) generada a partir dicha EC. Ntese
que en esta regla hay que imponer la restriccin de que el orden de los atributos es
relevante en la proyeccin del lgebra relacional.
R.2.
La unin de matrices asociadas a dos EE.CC pasa a ser la unin de sus tablas
relacinales (o vistas).
R.3.
La seleccin que, como se ha dicho, slo se utiliza en los grafos, pasa a ser una
seleccin del lgebra relacional.
R.4.
La inclusin de una matriz M^ en otra /W2 pasa a ser la comprobacin de que Mz - M,

no es el vaco. En esta regla se asume la ampliacin del lgebra relacional con el
predicado de igualdad de conjuntos para comprobar el resultado de las operaciones.
4.5.3.4.4
Ejemplo de generacin de las reglas de verificacin de la

consistencia en lgebra relacional
A continuacin se muestra la transformacin de las reglas de consistencia del sub-modelo

considerado hasta ahora, es decir, las presentadas a modo de ejemplo en el apartado 4.4.3.3:
1.
Para la regla ACC-2_1, que est escrita como:

define consistency [Regla ACC-2_ 1]
description "Cualquier trmino que aparezca en un nudo 'concepto' del que sale un
arco 'subclase de' tiene que aparecer en el campo 'nombre del concepto' del
diccionario de conceptos"
begin
end consistency
se obtiene la frmula:
liNombre del vrtice del que sale ( C ' Tipo del vrtice del que sale = 'Concepto' /> Tipo de arco = 'Subclase de'
ACC))
- n[Nombre del concepto](DC)
(ArCO-Oel-
0.
Recurdese que ACC.S.out.Concepto significa que hay que seleccionar en la matriz del
rbol de clasificacin de conceptos aquellas filas tales que
[Tipo de arco] = [Subclase de] y [Tipo del vrtice origen] = [Concepto]
y que despus hay que proyectar sobre Nombre del vrtice origen.
Mtodo flexible para l conceptualizacin de antologas basado en meta-modelos
158
4.
La regla DC-1 simplificada, escrita como:

define consistency [Regla DC-1 simplificada]
description "El nombre del concepto tiene que ser un nudo del rbol de clasificacin de
conceptos, pues el diccionario de conceptos muestra los detalles de los conceptos
begin
DC.NC is included in ACC.S.in.Concepto unin ACC.S.out.Concepto
end consistency
se transforma en la siguiente frmula:
nInslancias(VSta'DC)
- (TlNombre del vrtice del que sala
'Subclase de'
(ArCO-del-ACC))
uUNombre
arco ='Subclase de' (ArCO-del-ACC)))
Tipo del vrtice del que sale = 'Concepto'A Tipo de arco =
del vrtice al que entra
Tipo del vrtice al que entra = 'Concepto' A Tipo de
4.5.3.4.5 Propiedades del esquema relacional obtenido a partir de

cualquier meta-modelo en LBIR
Un aspecto importante a tener en cuenta es que las reglas de consistencia no generan
dependencias funcionales, pues no implican restricciones que se tengan que dar en los datos
en todo momento, sino slo cuando la ontologa est completamente conceptualizada. Por esta
razn, las reglas de verificacin de la consistencia se transforman en operaciones del lgebra
relacional. Las nicas dependencias funcionales que se tienen en los esquemas generados son
las que se presentan a continuacin:
1. Las que hay entre los campos con multiplicidad mxima 1 y los campos principales, por
ejemplo
Nombre -^ Descripcin
en la tabla generada a partir del glosario de trminos.
2. Las que hay entre los campos principales y cada uno de los campos que son
simultneamente de no repeticin y no opcionales, como es el caso de la siguiente
dependencia:
Descripcin -^ Nombre
tambin en la tabla generada a partir del glosario de trminos. Sin embargo, no se da la
siguiente dependencia:
Abreviatura -^ Nombre del concepto
dado que, aunque la abreviatura no puede estar repetida, sta es opcional.
Se puede afirmar, por tanto, que el modelo obtenido tiene las siguientes propiedades:
159
1. Se conservan todas las dependencias funcionales en la descomposicin.

2. Todas las tablas estn en cuarta forma normal, pues no hay dependencias multivaluadas
que no sean funcionales, y todas las dependencias funcionales tienen en su parte
izquierda una clave del esquema.
3. Se puede recuperar ntegra toda la informacin que contienen los EE.CC.
4.5.4 IMPLEMENTACIN DEL ESQUEMA DE DATOS

4.5.4.1
INTRODUCCIN
Una vez que se tiene el esquema de datos diseado, es necesario transformarlo en un modelo
operativo en SQL, para ello es necesario utilizar una serie de reglas que son inmediatas.
4.5.4.2
ENTRADAS
Las tablas, las vistas y las expresiones en lgebra relacional generadas en la tarea anterior.
4.5.4.3
PRODUCTOS OBTENIDOS
El esquema relacional y las reglas de verificacin de la consistencia en SQL.
4.5.4.4
Las reglas propuestas son las siguientes:

R.1.
Las tablas se codifican en SQL utilizando la sentencia CRATE TABLE.
R.2.
Las vistas se codifican en SQL utilizando la sentencia CRATE VIEW.
R.3.
Las operaciones del lgebra relacional tienen las equivalencias que se muestran en la
Tabla 4.61.
R4.
La comprobacin, en las reglas de la verificacin de la consistencia, de que la

diferencia es igual al conjunto vaco se hace comprobando que la consulta SQL no
devuelve ningn valor.
Algebra relacional
ncampos(R)
Ocondicin
\^)
Rus
R - S, donde R(A, B, C) y S(E, F, G)
SQL
SELECT DISTINCT campos FROM R
SELECT DISTINCT * FROM R
WHERE condicin
SELECT* FROM R
UNION
SELECT * FROM S
SELECT DISTINCT * FROM R
WHERE NOT EXISTS (SELECT * FROM S
WHERE A = E AND B = F AND C = G)
Tabla 4.61. Equivalencias de los operadores bsicos del lgebra relacional y el SQL (adaptado de
[Fernndez Lpez, 99b])
160
Otros detalles de la transformacin, como es por ejemplo el tipo de cada atributo, dependen del
gestor que se vaya a utilizar.
4.5.4.5
QUINES LLEVAN A CABO LA TAREA
Est tarea tambin est pensada para que la realice un computador de manera automtica.
4.5.5 CONCLUSIONES SOBRE LA IMPLEMENTACIN

ESQUEMA DE CONCEPTUALIZACIN
DEL
EEn esta seccin se ha presentado cmo transformar un meta-modelo en LBIR, que describe
cmo se conceptualiza el dominio de una ontologa en un esquema de datos computable. Se
aconseja, debido a las ventajas de las BB.DD.RR y del SQL, que los esquemas se
implementen en este lenguaje.
Se ha elaborado una serie de reglas que permiten transformar el meta-modelo LBIR en un
esquema ER, el esquema ER en un esquema relacional, y el esquema relacional en cdigo
SQL. Aunque el proceso de transformacin del ER en relacional se describe en diferentes
textos de BB.DD, en el presente trabajo se proponen reglas ms precisas que en estos textos,
pues mientras que en los libros de BB.DD este proceso se muestra para que sea aplicado por
los analistas, aqu se elabora para que lo lleve a cabo un computador.
Un aporte importante de la presente seccin es que se da la posibilidad de que haya un
soporte tecnolgico al mtodo flexible de conceptualizacin de ontologas basado en metamodelos, es decir, es posible, no slo desde el punto de vista metodolgico, sino tambin
desde el punto de vista tecnolgico, construir ontologas utilizando el meta-modelo que ms se
adecu a las necesidades de modelizacin de cada problema. Adems, gracias al enfoque
seguido, las ontologas se pueden guardar en bases de datos relacinales, y se da as la
posibilidad de aprovechar las ventajas de: independencia de los datos, minimizacin de la
redundancia y del espacio de almacenamiento, integridad de los datos, comparticin de datos,
seguridad de datos, y la posibilidad de acceder a las ontologas a travs de SQL.
Dado que en el da de hoy existe un software que realiza este proceso (ODE, vase la
seccin 4.8), se puede afirmar que LBIR se puede transformar en un modelo operativo. Esto ha
provocado una dificultad tcnica importante, ya que se permite la definicin de meta-modelos
distintos para distintas ontologas y, por tanto, los esquemas de bases de datos se generan en
tiempo de ejecucin, en vez de hacerlo en tiempo de diseo que es lo habitual.
4.6
CONCEPTUALIZACIN DE LA ONTOLOGA DE DOMINIO
4.6.1 INTRODUCCIN
Segn el mtodo bi-fase de conceptualizacin aqu expuesto, antes de llevar a cabo la
161
conceptualizacin de la ontologa de dominio, se ha tenido que especificar en lenguaje natural

el esquema de conceptualizacin a seguir (Figura 4.32), luego, se ha tenido que elaborar,
utilizando tablas gratos, el meta-modelo del esquema de conceptualizacin, es decir, se ha
tenido que especificar qu tablas y qu gratos se van a usar en la conceptualizacin de la
ontologa de dominio, en qu orden, qu reglas de la verificacin de la consistencia dentro de
cada EC y entre EE.CC se tienen que cumplir, etc. Despus, se ha tenido que formalizar el
meta-modelo utilizando LBIR. Y, luego, se ha tenido que generar un esquema de datos para
almacenar la conceptualizacin de la ontologa de dominio, asumiendo as la utilizacin de un
software en dicha conceptualizacin. Es decir, con la conceptualizacin de la ontologa de
dominio, se cambia del plano de la modelizacin del esquema de la conceptualizacin, al plano
de la modelizacin de la ontologa de dominio.
NIVEL DE
CONOCIMIENTOS
QUE HAY QUE
MODELIZAR:
ESQUEMA DE
CONCEPTUALIZACIN
QU HAY QUE
MODELIZAR:
ONTOLOGAS
NIVEL SIMBLICO
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grafos)
Formalizacin
(utilizando
LBIR)
Implementacin
(en SQL)
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grafos)
Formalizacin
(p.e. marcos)
Implementacin
(p.e. Ontolingua)
Plano en que se sita la conceptualizacin de la ontologa de dominio
En la Figura 4.33 se presenta la relacin de este paso de conceptualizacin de la ontologa

de dominio, que consta de una sola tarea, con el resto de pasos del mtodo de
conceptualizacin. En esta seccin, primero se van a describir las entradas, los productos, el
procedimiento y quines intervienen en la tarea.
4.6.2 ENTRADAS
El meta-modelo que se va a utilizar, la documentacin de la adquisicin de conocimientos, y la
especificacin de la ontologa. El meta-modelo debe estar disponible tanto en forma de tablas y
grafos, como en SQL. El primer formato es para que las personas encargadas de
conceptualizar el dominio de la ontologa sepan los detalles de las normas a las que se deben
ajusfar. El segundo formato es para que el software utilizado sea til en este paso.
162
INICIO

esquema de conceptualzacin

Paso 4. Impleraentacin del

No
Pas 5. Conceptualizcii) de
la ontologa de dominio '
CT Z^^
Paso 6. Implementacn de la
ontologa de dominio
Figura 4.33. Relacin de la conceptualzacin de la ontologa de dominio con el resto del mtodo de
conceptualzacin

La documentacin generada ser la conceptualzacin de la ontologa de dominio en las tablas
y gratos que especifique el meta-modelo elegido. Los conocimientos conceptualizados sern
almacenados segn el esquema de datos obtenido en el paso de implementacn del esquema
de conceptualzacin.

Los pasos que hay que realizar, y el momento de llevarlos a cabo aparecen detallados en el
meta-modelo que se vaya a utilizar.
Mtodo flexible para la conceptualzacin de ontologas basado en meta-modelos
163

Personas entendidas en el dominio de la ontologa, junto personas entendidas en ontologas,
con ayuda de ODE.
4.7
IMPLEMENTACIN DE LA ONTOLOGA DE DOMINIO
4.7.1 INTRODUCCIN
El mtodo bi-fase de conceptualizacin aqu presentado propone que, una vez que se ha
conceptual izado el dominio de la ontologa, la conceptualizacin de este dominio se transforme
en cdigo en el lenguaje de implementacin en que se deba tener la ontologa. En este trabajo
se propone la traduccin automtica del modelo conceptual en un modelo de implementacin.
La automatizacin de la traduccin consta de las siguientes tareas: estudio del lenguaje
destino, especificacin de las reglas de traduccin, generacin del traductor conceptualizacinimplementacin, y generacin del cdigo en el lenguaje de implementacin utilizando el
traductor (Figura 4.34). Las dos primeras tareas se llevan a cabo slo si ya no existe el
traductor para el meta-modelo que se ha utilizado en la conceptualizacin.
En los siguientes apartados de esta seccin se presentarn con detalle cada una de las
tareas del paso de implementacin de la ontologa de dominio.
4.7.2 ESTUDIO DEL LENGUAJE DESTINO

4.7.2.1
INTRODUCCIN
Antes de obtener un traductor, es necesario analizar el lenguaje destino. En ocasiones, como

ocurre con Ontolingua, puede haber distintas opciones para codificar cada tipo de definicin. Si
se da esta situacin, hay que estudiar cul de las opciones es la ms adecuada.
4.7.2.2
ENTRADAS
Cualquier documentacin sobre el lenguaje. Es importante contar con un manual que describa
la sintaxis del lenguaje y su significado de manera precisa.
4.7.2.3
PRODUCTOS OBTENIDOS
Un informe describiendo el lenguaje que debe incluir los siguientes aspectos:

1. Sintaxis, pues en la siguiente tarea hay que especificar patrones de traduccin basados
en esta sintaxis.
2. Expresividad del lenguaje para establecer qu partes de la conceptualizacin de la
ontologa se van a poder traducir y qu partes no se van a poder traducir.
164



No

MPLEMEIsiTACIN DE LA
NTOLGA DE DOMINIO
Tarea 6.1. Estudio

lenguaje destino
del
Tarea 6.2. Especificacin de

las patrones de traduccin
Tarea 6.3. Construccin del

traductor conceptualizacinimplementacin
Tarea 6.4. Generacin de

cdigo
Figura 4.34. Relacin de la implementacin de la ontologa de dominio con el resto del mtodo de
conceptualizacin
165
3. Mecanismos de razonamiento de que dispone el lenguaje, sobre todo con vistas a las
futuras aplicaciones de la ontologa.
4. Traductores a otros lenguajes. De esta forma se puede establecer en cierta medida la
usabilidad de la ontologa.
4.7.2.4
Los pasos recomendados son: primero, buscar ms documentacin en caso de que sea
necesario; despus estudiar el lenguaje, e incluso hacer alguna pequea ontologa de prueba
con l; y, por ltimo, elaborar el informe.
4.7.2.5
Entendidos en la representacin de conocimientos.
4.7.3 ESPECIFICACIN DE LAS REGLAS DE GENERACIN DE

CDIGO
4.7.3.1
INTRODUCCIN
El objetivo de esta tarea es que las reglas de generacin queden especificadas de una manera
precisa. Por esta razn, la especificacin se debe ajusfar a unos patrones estrictos, aunque no
por eso dejen de ser intuitivos.
4.7.3.2
ENTRADAS
La sintaxis sobre el lenguaje destino, cualquier otra documentacin sobre el lenguaje, y el

meta-modelo a traducir.
Si fiay otro traductor al mismo lenguaje destino, se debe estudiar en qu medida es posible
obtener las reglas del nuevo traductor modificando las reglas del traductor anterior.
4.7.3.3
4.7.3.3.1
PRODUCTOS OBTENIDOS
DESCRIPCIN
Para cada componente del lenguaje destino (en Ontolingua, por ejemplo, clases, relaciones,
instancias, axiomas, etc.), se debe especificar:
1. Patrn del componente en el lenguaje destino. Se presentar una regla que describa el
patrn utilizado en la implementacin del componente a tratar. En esta regla se utilizarn
los siguientes smbolos especiales:
:=
Separador entre la parte izquierda y la parte derecha de una regla. Es decir, entre lo
que se pretende describir con la regla y su descripcin.
166
Delimitadores de los smbolos no terminales, o lo que es lo mismo, aquellos que

tienen que aparecer en la parte derecha de una regla.
{}
Lo que aparezca entre estos smbolos se puede repetir varias veces.
[]
Delimitadores de partes opcionales de la parte derecha de la regla.
Separa opciones de las que slo una es posible.
Las partes opcionales y las que se pueden repetir irn etiquetadas con nmeros para
hacer a ellas referencia y poder establecer las condiciones bajo las cuales puede
aparecer una estructura, o las veces que se puede repetir. Adems los trminos
especficos de la ontologa aparecern en cursiva, y las palabras clave en negrita.
Adems, se recomienda describir brevemente el significado de las palabras clave que
aparezcan en el patrn. De esta manera, aquellas personas que no conozcan bien el
lenguaje y que deseen consultar las reglas de traduccin, no tendrn que estar
consultando constantemente el estudio del lenguaje obtenido en la tarea anterior.
2. Correspondencia entre el lenguaje destino y el meta-modelo de conceptualizacin. Se
elaborar una tabla donde se relacionan los trminos usados en la fase de
implementacin (primera columna de la tabla) con los empleados en la conceptualizacin
(segunda columna).
3. Descripcin de las opciones y las repeticiones en el patrn de la definicin. Se elaborar
una tabla para explicar las condiciones que establecen cundo aparece cada estructura
que es optativa, y las veces que se repiten las estructuras que van entre llaves. La tabla
tendr dos columnas, la primera con las etiquetas que aparecen en las estructuras
opcionales y repetitivas, y la otra columna con una explicacin precisa de las condiciones
que rigen las veces que aparece el contenido de la estructura.
4. Ejemplo de una definicin que siga el patrn. Con el objetivo de aclarar el significado de
cada uno de los elementos descritos, se aconseja poner un ejemplo del tipo de definicin
que se est describiendo.
4.7.3.3.2
EJEMPLO BREVE
Para especificar la generacin de clases en el traductor del esquema de referencia a Ontoligua,

se tiene la siguiente descripcin:
1. Patrn del componente en el lenguaje destino. Para cada uno de los conceptos descritos
en el diccionario de conceptos se generar una clase que tendr el siguiente formato:
;;; concepto
(Define-Class concepto {"^concepto)
"descripcin"
:def
167
[(and]'
[(Individual concepto)]
{{superclase 7concepto)f
[(Superclass-Of subclases)]*
[(Has-lnstance "iconcepto instancias)f
[(Has-At-Most ? concepto atrbuto_o_relacin 1)1
(Has-One ? concepto atributo_o_relacin) T
(>= Value-Cardinality ? concepto atributo_o_relacin 0) f
(Has-Some Iconcepto atributo_o_retacin)f[)]^
[:ax\om-delf
[(Exhaustive-Subclass-Partition concepto {Seloi subclases-ex))f^
[(Disjoint-Subclass-Partition concepto {Setol subclases-disj))f [)f
[:class-slots
{{atributo__de_clase :value valores)^^^*
El significado de las palabras clave de Ontolingua y de la Frame Ontology utilizadas es el
siguiente:
i.
Define class indica que se trata de la definicin de una clase.
ii.
? precede a las variables.
iii.
:Def expresa condiciones suficientes en las que los parmetros de la definicin son
variables libres (sin cuantificar).
iv.
And es el operador lgico and.
V.
(Setof x1 x2...) es el conjunto fornnado por x1, x2, etc.
vi.
Individual es un trmino que identifica la clase de todas las instancias, por

consiguiente, si se pone (Individual x) significa que x es una instancia.
vii. Superclass of es la relacin que se establece entre cualquier clase y sus

subclases. Por consiguiente, si aparece en un axioma nombrado (superclass-of x y
z), entonces y y zson subclases de x. Por otra parte, si aparece (superclass-of y z)
dentro de la definicin de la clase x, tambin significa que y y zson subclases de x.
viii. Has-instance es la relacin que se establece entre cualquier clase y sus instancias.
Tambin es un trmino de la Frame Ontology.
ix.
Has-at-most es una relacin entre una clase, una relacin y el nmero mximo de
veces que puede aparecer una instancia de la clase en la relacin.
X.
âs-one x y) es equivalente a (has-at-most x y 1), es decir, la clase x slo puede

tener una instancia como origen en la relacin y. Cuando este predicado se
encuentra en la definicin de la clase x, el parmetro xse puede omitir.
xi.
Value-cardinality es una relacin entre una clase, una relacin y el nmero de

veces que puede aparecer una instancia de la clase en la relacin.
xii. (Has-some x y) es equivalente a (> (value-cardinality x y 1)), es decir, la clase x
168
puede tener ms de una instancia como origen en la relacin y.

xiii. :axiom-def expresa condiciones de la definicin, aunque a diferencia de las
condiciones;de/, no hacen referencia a los parmetros de sta, sino a su nombre,
por lo tanto, la expresin que aparece acompaando a :axiom-def puede trasladarse
a una definicin aparte sin cambiar conocimientos que aparecen en la ontologa.
xiv. Exhaustive-subclass-partition es una relacin entre una clase C1 y un conjunto
de clases que forman una particin tal que todas las instancias de C1 estn en la
particin.
XV. Disjoint-subclass-partition es una relacin entre una clase C1 y un conjunto de
clases que son una particin de C1.
xv. :class-slots precede a la asignacin de valores a los atributos de clase.
xvii. :value se utiliza para asignar valores a los atributos de clase.
2. Correspondencia entre el lenguaje destino y el meta-modelo de conceptualizacin. La
forma de obtener la informacin correspondiente a las palabras que aparecen en cursiva
en el patrn anterior, es decir, las que no son palabras claves, est expresada en la
Tabla 4.62.
IMPLEMENTACIN
CONCEPTUALIZACIN
Concepto
Se obtiene del campo "nombre del concepto" del diccionario de

conceptos.
Descripcin
Es la descripcin que aparece en el glosario de trminos para el

concepto que se est traduciendo.
Subclases
Las subclases del concepto que aparecen en el rbol de clasificacin

de conceptos
Instancias
Corresponde al campo instancias del "diccionario de conceptos" del

concepto
Subclases-ex
Las subclases en la particin exhaustiva del concepto que aparece en

el rbol de clasificacin de conceptos
Subclases-dis
Las subclases en la particin disjunta del concepto que aparece en el

rbol de clasificacin de conceptos
Superclase
Una superclase del concepto en el rbol de clasificacin de conceptos
Atributo_o_relacin
Ser un elemento del campo atributos de clase, atributos de

instancia, o relaciones del "diccionario de conceptos"
correspondiente al concepto
Atributo_de_clase
Se obtiene del campo atributo de clase de la tabla de conceptoatributo de clase-valor.
Valores
Se obtienen del campo valor de la tabla de concepto-atributo de

clase-valor
Tabla 4.62. Significado de los smbolos ms elementales en la descripcin de las clases en Ontolingua y
su procedencia del esquema de referencia
169
3. Descripcin de las opciones y las repeticiones en el patrn de la definicin. Como se

puede observar, en la definicin del formato, las estructuras opcionales estn
etiquetadas con super-ndices. stos se utilizan en la Tabla 4.63 para explicar las
condiciones que se deben cumplir para que estas estructuras aparezcan en la definicin
de una determinada clase.
NMERO DE
CONDICIN
EXPLICACIN
El concepto tiene instancias, atributos de clase, atributos de instancia o

relaciones en su entrada del diccionario de conceptos
El concepto no tiene superclases (la informacin se obtiene del rbol de

clasificacin de conceptos)
Se repite tantas veces esta estructura como superclases tenga el concepto.

Por consiguiente, si no tiene superclases, no aparece esta estructura. (La
informacin se obtiene del rbol de clasificacin de conceptos)
El concepto tiene subclases (la informacin se obtiene del rbol de

Tabla 4.63. Condiciones de las estructuras optativas y repetitivas en la definicin de las clases en
Ontolingua (1/2)
NMERO DE
CONDICIN
EXPLICACIN
El concepto tiene instancias en su entrada del diccionario de conceptos
La cardinalidad del atributo o relacin es (0, 1). La informacin se saca de

las tablas de atributos de instancia, de las tablas de atributos de clase o de las
tablas de relaciones, dependiendo de lo que sea atributo_o_relacin.
La cardinalidad del atributo o relacin es (1,1).
La cardinalidad del atributo o relacin es (0, n).
10
El concepto contiene una particin exhaustva o una particin disjunta (la

informacin se obtiene del rbol de clasificacin de conceptos)
11
El concepto contiene una particin exhaustva (la informacin se obtiene del

rbol de clasificacin de conceptos)
12
El concepto contiene una particin disjunta (la informacin se obtiene del

rbol de clasificacin de conceptos)
13
Se repite tantas veces como atributos de clase tomen valor en el concepto
14
Se tendr esta estructura si hay atributos de clase que toman valores en el

concepto
Tabla 4.63. Condiciones de las estructuras optativas y repetitivas en la definicin de las clases en
Ontolingua (2/2)
170
4. Ejemplo de una definicin que siga el patrn. El siguiente ejemplo muestra la clase que
se generara aplicando la especificacin del patrn al concepto "elemento" del ejemplo
del anexo II:
;;; Elemento
(Define-Class Elemento (?Elemento)
" Es una sustancia formada por tomos con el mismo nmero de
protones."
:def
(and
(Superclass-Of Reactivo No-Reactivo)
(Has-One ? Nmero-Atmico Entero)
(Has-One ? Peso-Atmico Nmero-Real}
)))
En el anexo VI se presentan todos los patrones para la traduccin del esquema de

referencia a Ontolingua.
4.7.3.4
F'rimero, para cada uno de los tipos de componentes que se mencionen en el meta-modelo a
traducir (conceptos, atributos, instancias, axiomas, etc.) se estudia qu aspectos hay que
traducir. Por ejemplo, para los atributos, puede ser interesante que aparezca en la traduccin:
la descripcin en lenguaje natural, para que el cdigo de la definicin se pueda entender; el
concepto al que pertenece el atributo; la cardinalidad; y el tipo de datos. Al mismo tiempo, hay
que identificar ios EE.CC de las que se pueden obtener los conocimientos a traducir. Despus,
se elaboran las reglas de traduccin, obteniendo as la documentacin descrita en el punto
4.7.3.3.
4.7.3.5
La tarea de especificar los patrones del lenguaje destino as como las relaciones entre los
componentes del lenguaje y los componentes del esquema de conceptualizacin deben llevarla
a cabo entendidos en la modelizacin de conocimientos. Es muy aconsejable que estos
entendidos sean los mismos que han realizado el estudio del lenguaje destino.
4.7.4 CONSTRUCCIN DEL TRADUCTOR CONCEPTUALIZACINIMPLEMENTACIN

4.7.4.1
INTRODUCCIN
Una vez que se tienen las reglas de transformacin de la conceptualizacin a la

implementacin, se debe construir el traductor.
171
4.7.4.2
ENTRADAS
El conjunto de patrones del lenguaje destino, y las asociaciones entre los patrones y ios
componentes del meta-modelo.
En caso de que haya un traductor anterior, se debe estudiar la posibilidad de reutilizar el
anlisis, diseo e implementacin del traductor.
4.7.4.3
PRODUCTOS A OBTENER
El traductor que permita la transformacin de la conceptualizacin en el meta-modelo que se

est utilizando en cdigo en el lenguaje de implementacin destino.
4.7.4.4
Si el proceso no est automatizado, se utilizan las tcnicas de ingeniera del software y se

realiza un anlisis, un diseo y una implementacin del traductor.
Es conveniente asociar un proceso a cada patrn del lenguaje destino. Por ejemplo, para
Ontolingua, se asocia un proceso para generar la cabecera, otro para generar las clases, etc.
4.7.4.5
Si el proceso se lleva a cabo de manera manual, lo deben realizar personas familiarizadas con
las tcnicas de ingeniera del software, con las herramientas para la construccin de
traductores, y entrenadas en la programacin.
4.7.4.6
GENERACIN DE CDIGO
El ltimo paso consiste en generar el cdigo de la ontologa en el lenguaje destino. Esto se

lleva a cabo simplemente ejecutando el traductor. El traductor ir leyendo la ontologa de la
BDR en que est almenada e ir generando el cdigo en el lenguaje destino.
4.7.5 CONCLUSIONES SOBRE

ONTOLOGA DE DOMINIO
LA
IMPLEMENTACIN
DE
LA
En esta seccin se muestra un mtodo para obtener cdigo en un lenguaje cualquiera de

implementacin de ontologas a partir de la conceptualizacin de una ontologa almacenada en
una base de datos relacional cuyo esquema se haya obtenido a partir de un determinado metamodelo.
Dado que ODE proporciona traductores que permiten transformar cualquier ontologa que
siga el meta-modelo de referencia en cdigo Ontolingua [Farquhar et al.; 96], y dado que en la
mayor parte de los casos se utiliza el meta-modelo de referencia con algunas modificaciones,
se puede construir con rapidez el traductor necesario para la nueva ontologa a cualquiera de
estos lenguajes. En consecuencia, el mtodo bi-fase flexible de conceptualizacin presentado
en este trabajo, apoyado con el entorno software ODE, facilita que personas que no conocen
172
los lenguajes de implentacin puedan desarrollar ontologas. En este sentido, esta combinacin
metodologa-tecnologa supone un avance muy significativo con respecto a entornos anteriores
ampliamente utilizados (Ontolingy Sever [Farquhar et al.; 96], Ontosaurus [Swartout et al.; 97],
etc.).
Esta transformacin directa y automatizada de la conceptualizacin en la implementacin es
posible gracias a que la conceptualizacin, aun siendo muy cercana a las personas entendidas
en el dominio de la ontologa, est ceida a unas reglas precisas que hacen que "invada"
parcialmente el terreno de la formalizacin.
Por otra parte, Ontolingua permite aumentar las posibilidades de reutilizacin de las
ontologas, pues existe un entorno software de libre acceso, el Ontology Server, que genera
cdigo en otros lenguajes a partir de Ontolingua (Loom [MacGregor, 90], Epikit, IDL de CORBA
[Mowbray et al.; 95], PROLOG, CLIPS y KIF puro).
Para el futuro, se tiene previsto darle soporte tecnolgico a la tarea de generacin de
traductores a partir de especificaciones. Esto agilizar todava ms el proceso de construccin
de ontologas.
4.8 EL SOPORTE TECNOLGICO DEL

CONCEPTUALIZACIN FLEXIBLE: ODE
MTODO
DE
4.8.1 INTRODUCCIN
Mientras que en los apartados anteriores se han tratado fundamente los aportes del presente
trabajo en el plano metodolgico, en ste se presentarn los aportes en el plano tecnolgico.
Bsicamente, stos aportes tecnolgicos se han ido mostrando, de manera sucinta, a travs de
la exposicin del mtodo bi-fase de conceptualizacin, pues es fundamental conocer qu
tareas tienen soporte software y cules no para saber la mayor o menor facilidad que puede
tener la aplicacin del mtodo. No obstante, en esta seccin se mostrarn los aportes
tecnolgicos de una manera integrada, y se concretarn algunos aspectos, sobre todo los
referentes a la arquitectura general del sistema.
El mtodo de conceptualizacin de ontologas visto anteriormente propone que antes de
llevar a cabo la conceptualizacin de la ontologa de dominio, se haga una especificacin en
lenguaje natural, una conceptualizacin utilizando tablas y grafos, una formalizacin en LBIR, y
una implementacin en SQL del esquema de conceptualizacin que se va a seguir. Adems,
basndose en el hecho de que este esquema de conceptualizacin est descrito de manera
precisa, es posible automatizar
la traduccin directa de la conceptualizacin
a la
implementacin.
Para darle soporte tecnolgico a este mtodo de conceptualizacin, se ha construido ODE
(Ontology Design Environmenf). Los pasos para los que ODE da soporte estn sombreados en
la Figura 4.35, aunque el paso de implementacin de la ontologa de dominio no est
173
compltamete automatizado, sino que slo existe el traductor que pasa del esquema de
referencia a Ontolingua [Farquhar et al.; 96]. Por tanto, las funciones que lleva a cabo ODE son
las que se presentan a continuacin:
NIVEL DE
CONOCIMIENTOS
QUEHAYQUE
MODEUZAR:
ESQUEMA DE
CONCEPTUALIZACIN
QUEHAYQUE
MODEUZAR:
ONTOLOGAS
NIVEL SIMBLICO
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grafos)
Formalizacin
(utilizando
LBIR)
Implementacin
(en SQL)
Especificacin
(en lenguaje
natural)
Conceptualizacin
(con tablas y
grafos)
Formalizacin
(p.e. marcos)
Implementacin
(del esquema de
referencia a
Ontolingua)
Pasos en los que ODE proporciona soporte tecnolgico
Figura 4.35. Soporte tecnolgico al mtodo de conceptualizacin flexible de ontologas
1. Procesamiento de meta-modelos en LBIR (implementacin automtica en SQL del

esquema de conceptualizacin a partir de cdigo LBIR). El sistema recibe como entrada
un fichero en LBIR, que tiene: la descripcin formal de los EE.CC que se pueden utilizar
para conceptuaiizar siguiendo el esquema de conceptualizacin, en qu orden se deben
ir rellenando estos EE.CC, y las reglas de verificacin de la consistencia dentro y entre
EE.CC. A partir de esta descripcin, crea el esquema de una base de datos relacional
necesario para desarrollar ontologas siguiendo el meta-modelo. En caso de que el
cdigo de entrada sea incorrecto, emite una serie de mensajes de error indicando si son
de tipo lxico, sintctico o semntico, en qu consiste cada error, y en qu lnea y en qu
lugar se encuentra. Consiguientemente, al permitir ODE la definicin de distintos metamodelos, permite que las ontologas se puedan conceptuaiizar utilizando distintos EE.CC
dependiendo de sus necesidades particulares de modelizacin.
2. Conceptualizacin siguiendo un meta-modelo (conceptualizacin de la ontologa de
dominio). Una vez que se ha determinado el meta-modelo que se va a seguir para
construir una determinada ontologa de dominio, el usuario puede elaborar con ODE el
modelo conceptual de dicha ontologa utilizando las tablas y los grafos especificados en
el meta-modelo. Para que el usuario se encuentre cmodo, la conceptualizacin la
realizar a travs de una interfaz grfica con ventanas que sigue las normas de Microsoft
[Blzquez; 97]. De esta manera, el aprendizaje de la utilizacin del entorno es rpido, y
el trabajo de los usuarios es eficiente.
3. Verificacin en el nivel de conocimientos (verificacin de la conceptualizacin de la
174
ontologa de dominio). En lo concerniente a la verificacin de las reglas de consistencia

dentro y entre EE.CC, la mayor parte de esta verificacin se hace de manera automtica.
Ahora bien, el momento en que se verifican estas reglas depende del modo en que
desee conceptualizar el usuario. As, el usuario tiene la oportunidad de hacer una
conceptualizacin guiada. En este caso, ODE le va avisando de las reglas de verificacin
de la consistencia que no cumple el EC que est rellenando con respecto a los EE.CC
rellenados anteriormente. Sin embargo, si se trata de un usuario que ya tiene cierta
prctica en la conceptualizacin de ontologas, puede optar por llevar a cabo una
conceptualizacin no guiada. En este otro caso, ODE slo avisa cuando el usuario
solicite explcitamente el anlisis de la reglas de verificacin de la consistencia que no se
cumplen.
3. Implementacin en Ontolingua (implementacin de la ontologa de dominio). Es
imprescindible para poder desarrollar ontologas en el nivel de conocimientos poder
contar con traductores desde la conceptualizacin a lenguajes de implementacin. En la
primera versin, se cuenta con un traductor desde el esquema de referencia de
METHONTOLOGY a Ontolingua [Farquhar et al.; 96]. Una ventaja importante de
Ontolingua es que existen, aunque sea aparte de ODE, traductores que transforman
cdigo Ontolingua en otros lenguajes, por ejemplo, en Loom [MacGregor, 90] y en
CLIPS.
En los apartados que vienen a continuacin, se presentar la arquitectura general de ODE,
la metodologa y las normas utilizadas durante su desarrollo, quines han construido el
sistema, y las conclusiones a esta seccin dedicada a la tecnologa.
4.8.2 ARQUITECTURA GENERAL DE ODE

En la Figura 4.36 se muestran los mdulos del sistema y el almacenamiento que utiliza cada
nridulo. Cuando un usuario quiere crear un meta-modelo, elige la opcin correspondiente en la
pantalla asociada al mdulo principal de ODE y se ejecuta el mdulo controlador del
procesamiento de LBIR; ste, a su vez llama al de generacin ER para obtener el esquema
entidad-relacin asociado al meta-modelo definido en LBIR; a continuacin, el controlador del
procesamiento de LBIR hace una llamada al mdulo generacin esquema relacional para
transformar el esquema entidad relacin en el esquema relacional en cdigo intermedio, y para
transformar las reglas de la verificacin de la consistencia de LBIR tambin en cdigo
intermedio; y luego, se hace una llamada al mdulo de generacin del esquema en SQL, que
obtiene una base de datos en ACCESS, y obtiene tambin las consultas correspondientes a las
reglas de verificacin de la consistencia.
175
Lectura
dato
usuario
PROCESAMIENTO DE LBIR
Mdulo controlador del procesamiento de LBIR
Escritura
para el
usuario
Escritura
para el
usuario
Mdulo principal de ODE
Generacin de
ER
Generacin
esquema
relacional
Generacin del
esquema SQL
Mdulo controlador del

Core
Lectura
dato
usuario
Escritura
para el
usuario
Controlador de la
traduccin
Lectura
dato
fichero
Anotaciones
Esquemas
relacinales
Meta-modelos en
SQL
Generacin de cdigo
Escritura
en fichero
Conceptualizacin
Conceptualizaciones
Verificacin de
la consistencia
Escritura
para el
usuario
^^^T
Figura 4.36. Arquitectura general de la primera versin de ODE
176
En el caso de que un usuario quiera conceptualizar siguiendo un meta-modelo determinado,

debe elegir la opcin correspondiente en la pantalla asociada al mdulo principal de ODE, y
este mdulo principal har una llamada al mdulo controlador del Core. Las tres operaciones
que permite Core son: conceptualizar una ontologa, traducir una conceptualizacin a
Ontolingua, y verificar una ontologa. Para cada una de estas opciones hay un mdulo
asociado.
El mdulo de conceptualizacin est conectado al almacenamiento de esquemas
relacinales porque, en caso de que el usuario desee crear una ontologa, el mdulo de
conceptualizacin copia el esquema relacional correspondiente con el meta-modelo elegido
para la ontologa a conceptualizar. La conexin de este mdulo a las anotaciones del
procesamiento de LBIR se debe a que el proceso debe conocer cul es la estructura interna del
almacenamiento de las conceptualizaciones (tablas, vistas, etc.). Adems, la conceptualizacin
est conectada con el de la verificacin de la consistencia porque, en caso de que la
conceptualizacin sea guiada, se comprueban algunas reglas de la consistencia sin que lo
solicite el usuario.
Por otra parte, El mdulo controlador de la traduccin a Ontolingua tambin hace una
llamada al de verificacin de la consistencia porque si no se verifican las reglas de la
consistencia, la traduccin no se puede llevar a cabo.
4.8.3 METODOLOGA Y NORMAS UTILIZADAS

DESARROLLO DEL SOFTWARE
DURANTE EL
Como metodologa de desarrollo de software, se ha utilizado Mtrica 2 [MAP, 90]. Las razones
para elegir esta metodologa han sido, en primer lugar, que describe de forma detallada qu se
debe documentar, cmo y cundo; y, en segundo lugar, porque es la metodologa exigida por
la administracin pblica espaola. Ahora bien, una variante importante que se ha hecho en
esta metodologa durante el desarrollo de ODE ha sido que se ha separado, por una parte, el
anlisis y el diseo globales del sistema y, por otra, el anlisis y el diseo detallados
[F-ernndez Lpez, 00]. De esta manera, se ha tenido la ventaja de tener una visin general del
sistema antes de empezar a desarrrollarlo de forma detallada.
Adems de la aplicacin de Mtrica 2, se ha seguido la recomendacin sobre planes de
calidad IEEE 829-1983 [IEEE, 83], la norma para la especificacin de requisitos IEEE 830-1998
[IEEE, 98], y las normas de interfaces de Microsoft (vase [Blzquez, 97]). Esto ltimo ha
facilitado que la interfaz de usuario de ODE sea intuitiva.
Por otra parte, con el propsito de poder construir ODE a la vez que se iba elaborando el
mtodo de conceptualizacin se ha utilizado un ciclo de vida basado en prototipos evolutivos.
En consecuencia, un cambio en el mtodo provoca la construccin, partiendo del anterior, de
un prototipo nuevo.
177
4.8.4 CONCLUSIONES SOBRE ODE

En esta seccin se ha presentado, haciendo hincapi en su arquitectura general, el entorno
software que da soporte tecnolgico al nntodo de conceptualizacin expuesto en secciones
anteriores. Concretamente, permite transformar un meta-modelo LBIR en una base de datos en
SQL y, las reglas de verificacin de la consistencia de tal meta-modelo, en un conjunto de
consultas SQL. Una vez que se ha generado el esquema de bases de datos a partir del metamodelo, la ontologa puede ser conceptualizada utilizando una interfaz grfica con ventanas
basada en las normas de Microsoft. Esta conceptualizacin puede ser traducida de rnanera
automtica a Ontolingua [Farquhar et al.; 96].
Por consiguiente, ODE permite la construccin y verificacin de ontologas en el nivel
de conocimientos. Adems, las ontologas se almacenan en bases de datos relacinales,
lo cual tiene sobre todo ventajas con respecto a la consistencia de los datos y la independencia
del nivel fsico. Adems, como el SQL es un lenguaje muy extendido, se facilita el uso de las
ontologas en otras aplicaciones. Por otra parte, los problemas de inferencia que se pueden
plantear con las bases de datos relacinales se solucionan gracias a los traductores.
Una particularidad relevante de ODE es que manipula meta-modelos descritos de
manera declarativa y no embebidos en el programa. Por lo tanto, se pueden utilizar metamodelos distintos sin cambiar el programa, lo que facilita el mantenimiento de ste. Tal ventaja
se ha podido implantar en ODE debido a que se ha salvado la dificultad tcnica de generar
esquemas de bases de datos en tiempo de ejecucin, cuando lo habitual es obtenerlos en
tiempo de diseo.
178
179
Captulo 5. Evaluacin de la solucin
Utilizando ODE, el entorno tecnolgico que da soporte al mtodo bi-fase, se han construido 13
ontologas en diferentes dominios y con distintas necesidades de modelizacin (Tabla 5.1):
unas ontologas tienen gran cantidad de instancias, mientras otras no tienen ninguna; otras
tienen slo atributos de instancia, y otras tambin atributos de clase; las hay que no tienen
relaciones; y en unas ontologas se han utilizado axiomas, mientras que en otras no. En
consecuencia, se han utilizado 8 esquemas distintos de conceptualizacin de ontologas de
dominio (Tabla 5.2) adaptndose a estas necesidades de modelizacin, lo cual muestra la
Iflexibilidad del mtodo y del entorno software.
Como se puede comprobar, al principio, se iban aadiendo EE.CC al esquema anterior. Sin
embargo, cuando la cantidad de EE.CC ya ha sido abundante, se han ido borrando elementos
innecesarios y, de esta manera, se ha ido evitando que la conceptual izacin sea engorrosa. En
todo momento se ha considerado que el esquema de referencia era aquel que tuviera todos los
EE.CC identificados hasta el momento con sus reglas de verificacin d la consistencia dentro
de cada tipo de EC y entre EE.CC diferentes.
Por otra parte, para tener varios casos de prueba de elaboracin de meta-modelos desde
cero, y para estimar las posibilidades de aplicacin tanto del mtodo como de ODE a reas
distintas a la conceptualizacin de ontologas de dominio, se han realizado meta-modelos para
describir esquemas ER (vase la Tabla 5.2.10 y la Tabla 5.2.11), y para describir gratos
heterrquicos tal y como se utilizan en IDEAL [Gmez Prez et al.; 97] (vase la Tabla 5.2.12).
El meta-modelo que describe el modelo ER se ha servido para elaborar esquemas en el
dominio de la empresa, modelizando, por ejemplo, la entidad factura, la entidad fabricante, etc.
El meta-modelo de gratos heterrquicos se ha utilizado en el dominio de la catalogacin de
edificios artsticos. Una de las ventajas que se ha apreciado con la utilizacin de los metamodelos en tareas y esquemas entidad relacin ha sido la comprobacin de las reglas de la
verificacin de la consistencia.
Como muestra de la aplicablidad tanto del mtodo bi-fase como del entorno software, se
puede decir que se han utilizado dentro de los siguientes contextos:
1. El proyecto europeo IST-1999-10589 MKBEEM {Multilingual Knowledge Based
European Electronic Marketpiace), cuyo propsito consiste en desarrollar un sistema de
mercado electrnico en que cada proveedor pueda ofrecer los productos en su idioma, y
cada cliente pueda obtener informacin sobre estos productos en el suyo propio. Junto
con la UPM, participan: Franco Telecom, Sema Group, National Technical University o
Athens, Teclinical Researcti Centre of Finland, la Socit Nationale des Chemins de Fer
Frangais, etc.
183
Conceptos
Atributos de
clase
Atributos de
instancia
Relaciones
Constantes
Axiomas
Frmulas
Instancias
TOTAL
TRMINOS
Qumica
10
20
37
Qumica
16
22
27
103
173
CHEMICALS revisada por entendidos

Qumica
en qumica [Blzquez et al.; 98]
15
20
27
103
169
78
12
47
102
239
Ontologas
23
70
lio
Unidades de medida
22
65
93
Iones relevantes en el medio

ambiente
62
82
Silicatos
84
17
109
Hardware
Hardware el LIA
49
29
56
56
190
ELLOS Ontology
Catlogos de ropa
16
20
48
Tradezone Ontology
Catlogo de productos en
general
22
SNCF Ontology
Viajes y hoteles
13
37
69
FIDAL Ontology
Contratos
15
37
Dominio
Ontologa
Prototipo de CHEMICALS
CHEMICALS
[Fernndez Lpez el al.; 99]
La reestructuracin de (KA)^
[Blzquez et al.; 98]
Comunidad
Investigadora en adquisicin
de conocimientos
Reference Ontology
[Arprez et al.; 98]
Standard Units reestructurada
[Rojas, 98], [Gmez Prez et al.; 99]
Iones monoatmicos
[Rojas, 98], [Gmez Prez et al.; 99]
Silicatos
[Pinilla Ponz, 99]
Tabla 5.1. Componentes de cada ontologa construida aplicando el mtodo de conceptualizacin flexible
184
Nombre
del
esquema
Elementos de conceptualizacin
Esquema
base
Aadidos
Modifcados
Borrados
Orden recomendado para

rellenar los elementos de
conceptualizacin
Reglas de
verificacin
Ontologas
desarrolladas
META-MODELOS ELABORADOS PARA LA CONCEPTUALIZACIN DE ONTOLOGAS BASNDOSE EN LOS ELEMENTOS DE CONCEPTUALIZACIN DE METHONTOLOGY
Diccionario de datos
(Nombre del concepto,
Sinnimos,
Acrnimos,
Instancias,
Atributos de clase.
Atributos de instancia)
rbol de clasiflcacin de conceptos
Esquema 1
[Gmez
Prez et al.;
96]
Tabla de constantes
(Nombre de la constante.
Descripcin,
Valor,
Unidad de medida.
Para inferir.
Referencias)
Tal y como aparecen escritas en

la columna "elementos de 37 reglas
conceptualizacin" de esta tabla
Tablas de atributos de instancia

(Nombre del atributo de instancia.
Descripcin,
Tipo de valor.
Unidad de medida.
Precisin,
Intervalo de valores.
Valor por defecto,
Cardinalidad,
Deducido de los atributos deinstancia.
Deducido de los atributos de clase.
Deducido de las constantes.
Frmula,
Para deducir.
Referencias)
Prototipo
CHEMICALS
(contina)
Tabla 5.2. Inventario de esquemas de conceptualizacin (1/12)
185
de
Nombre
del
esquema
Esquema
base
Aadidos
Modifcados
Borrados

conceptualizacin
Reglas de
verificacin
Ontologas
desarrolladas
(continuacin del esquema 1)

Tablas de atributos de clase
(Nombre del atributo de clase,
Nombre del atributo de la relacin,
Relacin lgica.
Valor,
Para deducir.
Referencias)
Tablas de frmulas
(Nombre de la frmula.
Atributo inferido.
Frmula,
Descripcin,
Atributos bsicos de instancia.
Atributos bsicos de clase.
Constantes,
Precisin,
Restricciones,
Referencias)
Arboles de clasifcacin de atributos
Tablas de instancias
(Nombre de la instancia.
Descripcin,
Atributos,
Valores)
186
Nombre
del
esquema
Esquema
Aadidos
Glosario de trminos
(Nombre,
Descripcin) por claridad
Esquema 2
[Fernndez,
96]
Esquema 1
Tabla de axiomas lgicos

(Nombre del axioma.
Descripcin,
Concepto,
Atributos referidos.
Expresin
Referencias) para tener ms
expresividad, concretamente, para
poder utilizar un lenguaje de lgica
de primer orden
Modificados
Tabla de atributos de clase

(Nombre del atributo de clase.
Descripcin,
Tipo de valor.
Unidad de medida.
Precisin,
Cardinalidad,
Para deducir.
Referencias) para tener ms
expresividad,ya que se
incorporan los campos de tipo
de valor, cardinalidad.
precisin y unidad de medida.
Borrados

conceptualizacin
1) Glosario de trminos
Reglas de
verificacin
Ontologas
desarrolladas
2) rbol de clasificacin de
conceptos
3) Diccionario de datos
4) Tablas
instancia
de
atributos
de
5) Tablas de atributos de clase
43 reglas
CHEMICALS
[Fernndez Lpez
et al.; 99]
6) Tablas de constantes
7) Tablas de instancias
8) Tablas de axiomas lgicos
9) rboles de clasificacin de
atributos
187
Nombre
del
esquema
Esquema
base
Aadidos
(Nombre,
Fecha y hora de creacin,
Autores,
Descripcin) para tener ms
expresividad, para poder representar
la informacin general sobre la
ontologa
Esquema 3
(primer
Esquema 2
esquema de
referencia)
Modificados
a) Se cambia el nombre del
diccionario
de datos
por
diccionario de conceptos para
que el nombre de esta tabla sea
ms representativo
Reglas de
veriflcacin
Tablas de axiomas lgicos

(Nombre del axioma.
Descripcin,
Concepto descrito.
Conceptos referidos.
Atributos referidos.
Variables,
Relaciones referidas.
Constantes referidas.
Instancias referidas.
Expresin,
Referencias)
2) Glosario de trminos y lista

de trminos a importar
3) rbol de clasificacin
conceptos
de
4) Diagrama de relaciones "ad

hoc"
5) Diccionario de conceptos
75 reglas
6) Tablas de relaciones binarias,
tablas de atributos de clase,
tablas de atributos de instancia y
tabla de constantes
7) Tablas de axiomas lgicos y
tablas de frmulas
atributos
9) Tabla de instancias
Ontologas
desarrolladas
CHEMICALS
revisada
por
entendidos
qumica,
y
la
reestructuracin de
(KA)^ [Blzquez et
al.; 98], sta ltima
en el dominio de la
comunidad
cientfica de la
adquisicin
de
conocimientos
1) Ficha de descripcin general
b) Se elimina el campo
"descripcin" del diccionario de
conceptos, de la tabla de
constantes, de la tabla de
Diagrama de relaciones "ad hoc", para
instancias, de las tablas de
tener ms expresividad
atributos de clase y de las tablas
de atributos de instancia. Para
Tabla de trminos a importar
que la descripcin slo aparezca
(Nombre del trmino en el origen.
en el glosario de trminos.
Nombre de la ontologa,
Servidor,
c) La tabla de axiomas se separa
Nombre del trmino en el destino)
en varias tablas y queda con los
para tener ms expresividad
siguientes campos para faciliar
permitiendo identificar los trminos a
la veriflcacin:
importar y su procedencia
(Nombre de la relacin,
Concepto origen,
CardinaHdad del concepto origen.
Concepto destino.
Propiedades matemticas.
Relacin inversa.
Referencias) para no forzar una
representacin poco intuitiva al
representar las relaciones como
atributos
Borrados

conceptualizacin
La reestructuracin
de (KA)^ [Blzquez
et al.; 98], sta
ltima
en
el
dominio
de
la
comunidad
cientfica de la
adquisicin
de
conocimientos
Reference
Ontology [Arprez
etal.;98]
188
Nombre
del
esquema
Esquema
base

conceptualizacin
Elementas de conceptualizacin
Aadidos
Modifcados
Borrados
Reglas de
verifcacin
Ontologas
desarrolladas

Tablas
de
instancia
atributos
de
Esquema 3
Tablas de frmulas
Arboles de clasifcacin
atributos
Tabla de instancias
de

hoc"
Tabla de constantes
Esquema 4
conceptos
de
6) Tablas de relaciones binarias

y tablas de atributos de clase
59 reglas
Standard
Units
reestructurada [Rojas,
98], [Gmez Prez et
al.; 99]
Primer prototipo de
Iones monoatmicos

8) Tabla de concepto-atributo de
clase-valor
189
Nombre
del
esquema
Esquema
base
Modificados
Aadidos
Borrados

conceptualizacin
Reglas de
verificacin
Ontologas
desarrolladas

Esquema 5
Esquema 4
Tabla de concepto-atributo de clasevalor

(Concepto,
Atributo de clase.
Valor)
Se aade para tener ms expresividad y
no tener que expresar con axiomas las
asignaciones de valores a los atributos de
clase
conceptos
hoc"
6) Tablas de relaciones binarias
y tablas de atributos de clase
61 reglas
Iones monoatmicos
[Rojas, 98], [Gmez
Prez et al.; 99]
Silicatos [Pinilla Ponz,
99]

clase-valor
190
Nombre
del
esquema
Esquema
base
Aadidos
Modificados
Borrados

conceptualizacin
Reglas de
verificacin
Ontologas
desarrolladas

conceptos
Tabla de concepto-atributo de clasevalor

(Concepto,
Esquema 3,
Esquema 6
Atributo de clase.
haciendo
(segundo
Valor)
aadidos
esquema de
del
referencia)
Se aade para tener ms expresividad y
esquema 5
no tener que expresar con axiomas las
asignaciones de valores a los atributos de
clase

hoc"
77 reglas
tabla de constantes
(Se
utiliz
en
ontologas
posteriores
tomndolo
como
base
y
modificndolo)

tablas de frmulas
atributos
clase-valor
191
Nombre
del
esquema
Esquema
base
Aadidos
Modificados

conceptualizacin
Borrados
Reglas de
verificacin
Ontologias
desarrolladas

Diagrama de relaciones "ad 2) Glosario de trminos y lista
hoc"
Esquema 7
Esquema 6
Tabla de instancias
(Instancia,
Atributo,
Relacin,
Valor)
conceptos
de
Tabla de constantes
44 reglas
Hardware
Tablas de axiomas
Se modifica para tener ms expresividad
Tablas de frmulas
Arboles de clasificacin
atributos
5) Tablas de atributos de clase y

tablas de atributos de instancia
de 6) Tabla de concepto-atributo de
clase-valor
Mtodo flexible para la conceptualizacin de ontologias basado en meta-modelos
192
Nombre
del
esquema
Esquema
base
Aadidos
Modificados
Borrados

conceptualizacin
Reglas de
verificacin
Ontologas
desarrolladas

conceptos
Esquema 8
referencia
Captulo 4
de
la
memoria
(consideran
do el caso
prctico de
modificacio
nes)
de

hoc"
Esquema 6
haciendo el
aadido del
esquema 7
Tabla de instancias
(Instancia,
Atributo,
Relacin,
Valor)
Prototipo de Ellos
Ontology
Prototipo
Tradezone
Ontology
de
80 reglas
tabla de constantes
Se modifica para tener ms expresividad

tablas de frmulas
atributos
Prototipo de SNCF
Ontology
Prototipo
de
FIDAL Ontology
(Todas dentro del
proyecto europeo
IST-1999-10589
MKBEEM
[MKBEEM, 00])
clase-valor
193
Nombre del
esquema
Esquema
base
Aadidos
Modiflcados
Borrados

conceptualizacin
Reglas de
verifcacin
Ontologas
desarrolladas
META-MODELOS ELABORADOS PARA LA CONCEPTALIZACIN Y ANLISIS AL MARGEN DE METHONTOLOGY

(Nombre,
Fecha y hora de creacin.
Autores,
Descripcin)
Glosario de trminos
(Nombre,
Descripcin)

Diagrama entidad relacin

Modelo
entidad
relacin
Tabla de entidades
(Nombre de la entidad,
Es entidad dbil.
Entidad que identifica a la entidad dbil.
Atributos,
Atributos identificadores)
Esquema de prueba
dentro del dominio
de la empresa
3) Diagrama entidad relacin
--
Tabla de relaciones
(Nombre de la relacin.
Entidades que asocia,
Cardinalidades,
Atributos,
Atributos identificadores)
--
37 reglas
4) Tabla de entidades
5) Tabla de relaciones y tabla de
atributos
Esquemas sobre la
conceptualizacin
de ontologas
6) Tabla de restricciones
(Contina)
194
Nombre del
esquema
Esquema
base
Aadidos
Modificados
Borrados

conceptualizacin
Reglas de
verificacin
Ontologas
desarrolladas
META-MODELOS ELABORADOS PARA LA CONCEPTUALIZACIN Y ANLISIS AL MARGEN DE METHONTOLOGY

(Continuacin del modelo entidad relacin)
Tablas de atributos
(Nombre del atributo.
Entidad,
Relacin,
Dominio,
Opcional,
Multivaluado,
Repetido)
Esquema de prueba
dentro del dominio
de la empresa
--
--
33 reglas
Esquemas sobre la
conceptualizacin
de ontologas
Tabla de restricciones
(Nombre de la restriccin.
Descripcin,
Entidades involucradas,
Relaciones involucradas.
Atributos involucrados,
Expresin)
195
Nombre del
esquema
Esquema
base
Aadidos
Modificados
Borrados

conceptualizacin
Reglas de
verificacin
Ontologas
desarrolladas
META-MODELOS ELABORADOS PARA LA CONCEPTUALIZACIN Y ANLISIS AL MARGEN DE METHONTOLOGY
Modelo
de
grafo
heterrquico
de tareas
--

(Nombre,
Fecha y hora de creacin,
Autores,
Descripcin)
Grafo heterrquico
2) Grafo heterrquico
Tabla de descripcin de tareas

(Nombre de la tarea.
Entradas,
Salida,
Descripcin)
2) Tabla de descripcin de tareas
17 reglas
196
(*) Analizados en [Duineveld et al.; 99]
Ontolingua
()
Ontosaurus
(*)
WebOnto
Protege 2000
ODE ()
(*)
CARACTERSTICAS GENERALES
Claridad de la interfaz de usuario
Consistencia de la interfaz de usuario
Velocidad de actualizacin
Visin general de la ontologi'a
Claridad de las instrucciones al sistema
Identificacin de los cambios
Estabilidad del sistema
Instalacin en red
No
Inerconexin con otros sistemas
Ayuda del sistema
CARACTERSTICAS VINCULADAS DIRECTAMENTE CON EL DESARROLLO DE ONTOLOGAS

Herencia mltiple
No
Descomposicin con distintas variantes
- Existencia de la verificacin
- Nivel de verificacin
Modelizacin en el nivel de conocimientos
no
no
no
Mecanismos de modelizacin variables
no
no
no
no
Ontologas de ejemplo
Biblioteca para reutilizacin
Inventario de primitivas de representacin
Ayuda sobre ontologas
Verificacin de la consistencia
CARACTERSTICAS SOBRE EL TRABAJO EN COOPERACIN

Actualizacin sincronizada
Mecanismos de bloqueo
No aplicable
Posibilidades de presentar ontologas que

estn bloqueadas
No aplicable
Visin de los cambios que hacen otros

usuarios
No aplicable
Posibilidades de exportar ontologas
S (RDF)
Posibilidades de importar ontologas
Tabla 5.3. Evaluacin de los entornos software de desarrollo de ontologas segin los criterios publicados
por Duineveld y colegas [Duineveld et al.; 99] (incluye ODE)
197
2. La iniciativa (KA)^, dentro de la modelizacin de conocimientos sobre la comunidad

cientfica en el campo de la INCO, en concreto sobre cientficos, temas de investigacin,
proyectos, universidades, etc. Junto con la Fl de la UPM, han participado: el Knowledge
Media Institute de la Open University IVIilton Keynes (Reino Unido); el SWI de la
Universidad de msterdam (Holanda); el Instituto AIFB de la Universidad de Karisrhue
(Alemania); y el SMI de la Universidad de Stanford (Estados Unidos).
3. El proyecto IVIultidisciplinar de Investigacin y Desarrollo de la Universidad
Politcnica de Madrid AM9819 llamado Prototipos de Ontologas para el Medio
ambiente, desarrollado junto con la Universidad Autnoma de Madrid.
4. El proyecto METHONTOLOGY, centrado en el desarrollo metodolgico, y con apoyo
software, de Ontologas. Est financiado por el proyecto CICYT TIC-98074.
Por otra parte, si se compara el entorno tecnolgico obtenido en el presente trabajo con
otros entornos para el desarrollo de ontologas, tal y como se muestra en la Tabla 5.3, se
pueden identificar los siguientes aportes:
1. ODE permite el desarrollo de ontologas en el nivel de conocimientos, frente a la mayora
de los entornos, que obligan a trabajar en el nivel de implementacin.
2. Con ODE los desarrolladores no estn presos de un esquema fijo y predeterminado de
modelizacin, lo que constituye un avance importante en el rea de construccin de
ontologas.
3. El nivel de verificacin de las ontologas proporcionado por ODE es mayor que el del
resto de los entornos software.
Como posibles ampliaciones del entorno software presentado en este trabajo, se plantea la
incorporacin de un mdulo de ayuda sobre la utilizacin del sistema, y la utilizacin del
sistema en red y con la posibilidad de construir ontologas de manera cooperativa. No obstante,
ninguna de estas caractersticas eran el objetivo de la investigacin aqu expuesta.
198
6 CONCLUSIONES
199
Captulo 6. Conclusiones
6. CONCLUSIONES
La aportacin terica de este trabajo consiste en un mtodo bi-fase flexible para describir
meta-modelos de forma declarativa, explcita y a la medida que sern utilizados para
conceptualizar ontologas de dominio. El mtodo consta de las siguientes fases (Figura 6.1):
Fase I.
Desarrollo del meta-modelo. Se especifica el meta-modelo a seguir durante el

desarrollo de la ontologa de dominio. Se identifican los EE.CC a utilizar, el orden
en que se tienen que ir rellenando, y las reglas de verificacin de la consistencia
entre EE.CC del mismo tipo y entre EE.CC de tipos distintos.
Fase II. Conceptualizacin de la ontologa de dominio. Siguiendo el meta-modelo

resultante de la fase I, se conceptuaiiza la ontologa.
A su vez, en cada una de estas fases se han identificado actividades tanto en el nivel de
conocimientos [Newell, 82] (especificacin y conceptualizacin) como en el nivel simblico
(formalizacin e implementacin).
NIVEL DE
CONOCIMIENTOS
FASE I. DESARROLLO
DEL META-MODELO
Especificacin
(en lenguaje
natural)
FASE II.
CONCEPTUALIZACIN
DE LA ONTOLGA
Especificacin
(en lenguaje
natural)
iponceptoaji^cin ':,
:|;S";; (con tablas y ;
. ,;;;-. grafos): ":.
Conceptualizacin
(con tablas y
grafos)
NIVEL SIMBUCO
: Formalizacin
(utilizando
LBIR)
Implementacin
(en SQL)
Formalizacin
(p.e. marcos)
Implementacin:
(p.e. Ontplingua)
Fases de que consta el mtodo de conceptualizacin propuesto en esta tesis
Como resultado de la aplicacin de la primera fase del mtodo, se obtiene un esquema de

conceptualizacin declarativo, explcito y a la medida de las necesidades de modelizacn de
la ontologa de dominio, lo que facilita la comparticin de esquemas por diferentes grupos y la
modificacin del esquema de conceptualizacin sin necesidad de hacer cambios en el software
que lo manipula. Adems, obliga a realizar un modelo conceptual de la ontologa de dominio
muy preciso, exigiendo incluso que los tipos de los campos se ajusten a alguna de las
gramticas.
201

PASO 1.
ESPECIFICACIN DEL
ESQUEMA DE
CONCEPTUALEACIN
PASO 4.
IMPLEMENTACIN DEL
ESQXJEMA DE
CONCEPTUALIZACIN
Tarea 1.1. Anlisis de

la expresividad de los
esquemas
Tarea
Elaboracin
cero
de
especificacin
Tarea 4.1. Anlisis del cdigo

LBIR
Tarea 4.2. Diseo del esquema

de datos
1.2.
desde
una
Tarea 4.3. Implementacin del

esquema de datos
Tarea
1.3.
Modificacin de una
especificacin
PASO 6.
IMPLEMENTACIN DE LA
ONTOLOGA DE DOMINIO
PASO 2.
CONCEPTUALIZACIN
DEL ESQUEMA DE
CONCEPTUALIZACIN
No

1-V
Tarea 2.2. Modificacin de un

meta-modelo anterior
"Reutilizacin
Tarea 6.1. Estudio

lenguaje destino
Tarea 6.2. Especificacin de

las patrones de traduccin
Tarea 6.3. Construccin del

traductor conceptualizacinimplementacin
Tarea 64. Generacin de

cdigo
Figura 6.2. Organigrama del mtodo de conceptualizacinflexiblede ontologas
202
Tarea
Productos
Entradas
Quin la realiza
PASO 1. ESPECIFICACIN DEL ESQUEMA DE CONCEPTUALIZACIN (seccin 4.2)

a)
Documento
con
las
Especificacin del esquema de
necesidades de modelizacin
conceptualizacin
de
un
de la nueva ontologa
esquema para ser reutilizado, o
1.1. Anlisis de la expresividad
informe justificando por qu
de los esquemas
b)
Descripcin
de
los
no se puede reutilizar ningn
esquemas utilizados en otras
meta-modelo
ontologas
a)
Documento
con
las
necesidades de modelizacin
Especificacin en lenguaje
de la nueva ontologa
1.2. Elaboracin desde cero de
natural del esquema de
una especicacin
c) Justificacin de que ningn conceptualizacin
meta-modelo
puede
ser
reutilizado
a)
Conocedores
conceptualizacin
conocimientos
de
la
de
b) Entendidos del
(opinando)
dominio
a)
Conocedores
conceptualizacin
conocimientos
de
la
de
b) Entendidos del dominio

(opinando)
a) Formulario sobre problemas

del meta-modelo a modificar
a) Entendido en el dominio
1.3. Modificacin
especificacin
de
una
Esquema a modificar
b) Propuesta de cambios
c)
Nueva
completa
b)
Entendidos
conceptualizacin
especificacin conocimientos
en
de
PASO 2. CONCEPTUALIZACIN DEL ESQUEMA DE CONCEPTUALIZAON (seccin 4.3)
2.2. Elaboracin desde cero de Especificacin del esquema de

Meta-modelo
uin meta-modelo anterior
conceptualizacin
a) Meta-modelo a modificar
a)
Conocedores
conceptualizacin
conocimientos
de
la
de
b) Entendidos del
(opinando)
dominio
a) Formulario sobre problemas

del meta-modelo a modificar
b) Especificacin del esquema

Entendidos
1.3. Modificacin de un metab) Cambios documentados
de conceptualizacin
conceptualizacin
modelo
sobre el meta-modelo
conocimientos
c) Propuesta de cambios, si la
c)
Nuevo
meta-modelo
ha habido
completo
en
de
PASO 3. FORMALIZACIN DEL ESQUEMA DE CONCEPTUALIZACIN (seccin 4.4)
3. Formalizacin del esquema Meta-modelo descrito

de conceptualizacin
tablas y grafos
con
Meta-modelo en LBIR
Entendido
en
la
conceptualizacin
de
conocimientos que conozca el
LBIR
PASO 4. IMPLEMENTACIN DEL ESQUEMA DE CONCEPTUALIZACIN (captulo 4)

4.1. Anlisis del cdigo LBIR
Meta-modelo en LBIR
Esquema entidad relacin
ODE
a) Esquema relacional
a) Esquema entidad relacin
4.2. Diseo del esquema de
b) Reglas de la verificacin de DDE
b) Reglas de la verificacin de
datos
la consistencia en lgebra
la consistencia en LBIR
relacional
a) Esquema relacional
4.3.
Implementacin
esquema de datos
del
Meta-modelo implementado en
b) Reglas de la verificacin de
ODE
SQL
la consistencia en lgebra
relacional
Tabla 6.1. Tareas concernientes a la modelizacin del esquema de conceptualizacin
203
PASO 5. CONCEPTUALIZACION DE LA ONTOLOGIA DE DOMINIO (seccin 4.6)

a) Documentacin de la
a) Tablas y grafos rellenos con
adquisicin de conocimientos.
los conocimientos de la
5. Conceptualizacin de la
ontologa de dominio
b) Especificacin
de la
ontologa de dominio
ontologa
b) Conocimientos almacenados
en una base de datos SQL
c) Meta-modelo a utilizar
Entendidos en el dominio de la
ontologa, junto con entendios
en ontologas, con la ayuda de
ODE
PASO 6. IMPLEMENTACION DE LA ONTOLOGA DE DOMINIO (seccin 4.7)
6.1. Estudio
destino
del
lenguaje
a) Documentacin sobre el
lenguaje
b) Otros traductores
generan el lenguaje
a) Informe
lenguaje
6.2. Especificacin
reglas de traduccin
de
las
que
Informe
lenguaje
Entendidos
representacin
conocimientos
describiendo
la
de
describiendo el
a)
Cualquier
documentacin
sobre
lenguaje
otra
el
b). Otros traductores

generan el lenguaje
que
Reglas de traduccin
Entendidos
representacin
conocimientos
en
la
de
Traductor
Personas familiarizadas con las

tcnicas de ingeniera del
software y con herramientas
para construir traductores, y
entrenadas en la programacin.
c) Meta-modelo a traducir
6.3. Generacin del traductor a) Meta-modelo a traducir

conceptualizacinb) Reglas de traduccin
implementacin
Ontologa almacenada en una Cdigo de la ontologa en el

ODE
base de datos
lenguaje destino
6.4. Generacin de cdigo
Tabla 6.2. Tareas de modelizacin de la ontologa de dominio
formales que se han definido en este trabajo. Esto permite la transformacin directa y
automtica del modelo conceptual de la ontologa de dominio en un modelo de implementacn,
es decir, los modelos conceptuales son computables. Estas caractersticas del mtodo han
dado la posibilidad de que se construya un software, llamado ODE, que le d soporte
tecnolgico.
En la Figura 6.2 se muestra el organigrama de todas las tareas del mtodo de
conceptualizacin presentado en este trabajo. Las tareas para las que ODE proporciona
soporte tecnolgico aparecen sombreadas. Por otra parte, en la Tabla 6.1 y en la Tabla 6.2 se
presentan las entradas de las tareas, los productos, y quines las llevan a cabo. Es decir, en
las tablas se muestran las descripciones particulares de cada tarea y, en la figura, las
relaciones entre tareas.
En la especificacin del esquema de conceptualizacin se establece, de acuerdo con las
necesidades de representacin, que se suponen entradas del mtodo, si se elabora un
esquema nuevo de conceptualizacin, o se reutiliza un esquema anterior. Si se decide elaborar
un esquema nuevo, es necesario, en este mismo paso de especificacin del esquema de
204
conceptualizacin, describirlo en lenguaje natural. Sin embargo, si se decide modificar un

esquema anterior, es necesario atenerse al mtodo de control de cambios, tambin descrito en
este trabajo, que evita que stos sean caticos y desordenados. Segn ha mostrado la
experiencia, a la hora de hacer la especificacin del esquema de conceptualizacin se suele
reutilizar en gran medida el llamado esquema de referencia, al cual se le aaden, o suprimen,
EE.CC completos o campos de algunas tablas. Este esquema de referencia se ha obtenido
mediante la unin de los meta-modelos utilizados en el desarrollo de ontologas en distintos
dominios y con diferentes necesidades de modelizacin.
Partiendo del producto obtenido en el paso anterior, en la conceptualizacin del esquema
de
conceptualizacin
se
elabora
un
meta-modelo
que
describa
el esquema
de
conceptualizacin a utilizar durante la construccin de la ontologa. Se puede observar en la

figura que si se puede reutilizar completamente un meta-modelo, se puede pasar directamente
a la conceptualizacin de la ontologa de dominio, pues tambin se puede reutilizar el cdigo
l-BIR y la implementacin en SQL. Al igual que ocurre con la especificacin del esquema de
conceptualizacin, en este trabajo se ha propuesto un mtodo de control de cambios en metamodelos.
Puesto que la documentacin obtenida de la conceptualizacin del esquema de
conceptualizacin no es adecuada para ser procesada por un computador, se hace necesario
llevar a cabo una formalizacin del esquema de conceptualizacin. En ella se codifica el
meta-modelo utilizando el lenguaje LBIR, que se ha definido tambin en el presente trabajo.
La sintaxis de LBIR se ha descrito con una gramtica libre del contexto, y la semntica de las
regas de verificacin de la consistencia se ha descrito basndose en el concepto matemtico
de matriz.
Una vez codificada la ontologa en LBIR, se transforma en un esquema de datos
computable que permita almacenar la conceptualizacin de la ontologa de dominio. Al estar
irnplementado el esquema en SQL, es posible almacenar la conceptualizacin de la ontologa
de dominio en una BOR. La implementacin del esquema de conceptualizacin consta de
tres tareas: anlisis (generacin de un esquema ER [Chen, 76] a partir del cdigo LBIR), diseo
(generacin de un esquema relacional [Codd, 70] a partir del ER), e implementacin
(generacin de cdigo SQL). Estas tareas son las mismas que llevara a cabo un ingeniero;
pero en este captulo, con el propsito de automatizarlas, se ha hecho una descripcin ms
precisa que la que suele aparecer en la documentacin de diseo de BB.DD.
Cuando se tiene generado el esquema de datos, se lleva a cabo la conceptualizacin de
la ontologa de dominio ayudndose de ODE.
Despus, se genera el cdigo de implementacin de la ontologa de dominio. Este paso
se realiza a travs de las tareas de estudio del lenguaje destino, especificacin de ios patrones
de traduccin, construccin del traductor conceptualizacin-implementacin, y generacin del
cdigo destino. No obstante, dado que en
la conceptulaizacin
del esquema de
205
conceptualizacin generalmente se reutiliza, al menos parcialmente, el meta-modelo de

referencia, y dado que ODE ya tiene traductores desde este meta-modelo, este paso de
implementacin del esquema de conceptualizacin se suele hacer de manera rpida.
El mtodo bi-fase aqu presentado es original. Las propuestas sobre conceptualizacin de
ontologas son escasas. Las nicas propuestas son las de METHONTOLOGY [Fernndez et
al.; 97], [Gmez Prez, 98a], [Fernndez Lpez et al.; 99], y la de Bernaras y sus
colaboradores [Bernaras et al.; 96], que hace una mencin implcita e imprecisa de la fase de
conceptualizacin de ontologas. Adems, este mtodo es original porque hasta ahora no se
haba planteado hacer, como pasos previos a la conceptualizacin de la ontologa de dominio,
una conceptualizacin, una formalizacin y una implementacin del mecanismo de
conceptualizacin que se va a utilizar. El presente trabajo, incluso, puede ser el primer paso
para tener un mtodo general de descripcin precisa y automatizable de esquemas de
conceptualizacin, no slo de ontologas, sino tambin de BB.CC, tal y como se muestra en la
Figura 6.3. De hecho, no se descarta combinar el mtodo propuesto en este trabajo con otros
enfoques de conceptualizacin, utilizando otros EE.CC, incluso fuera del rea de las
ontologas, o de la misma INCO. Por esta razn, durante el desarrollo de la investigacin se
han hecho algunas pruebas de modelizacin de esquemas entidad relacin y de gratos
heterrquicos (esto ltimo en IDEAL [Gmez Prez et al.; 97]). Uno de los aspectos ms
interesantes de los resultados de estas pruebas ha sido que las reglas de verificacin de la
consistencia definidas en los meta-modelos han permitido una verificacin exhaustiva de los
modelos.
PLANO SUPERIOR: MODELIZACIN DEL

ESQUEMA DE CONCEPTUALIZACIN (O
ANLISIS)
CONCEPTUALIZACIN
BASADA EN LOS
ELEMENTOS DE
CONCEPTUALIZCIN DE
METHONTOLOGY
ANLISIS
ESTRUCTURADO BASADO
EN DIAGRAMAS DE
FLUJOS DE DATOS,
MODELOS DE DATOS,
ETC.
Figura 6.3. Modelizacin de una metodologa en su fase de conceptualizacin
En lo referente a la expresividad de los elementos de modelizacin utilizados en el

desarrollo de este trabajo, se pueden obtener las siguientes conclusiones:
206
Ontolingua
OKBC
OCML
Elogie
LOOM
Esquema de
referencia
CONCEPTOS (clases)
Particiones
Meta-clases
TAXONOMAS
Subclase de
1-
Subclase en una
particin
disjunta
+/-
+/-
Subclase en una
particin
exhaustiva
+/-
+/-
ATRIBUTOS
Atributos
instancia
de
Atributos
clase
de
r'olimorfismo
FACETAS
Valor
defecto
por
Tipo
Restricciones de
cardinalidad
+/-
+/-
+/-
+/-
+ .,
+/-
i , , ' -
; " . " ;
Etefinicin
operacional
RELACIONES
+
Relaciones
+/-
. .
FUNOONES
Funciones
+/-
+
AXIOMAS
Axiomas
+/-
+
INSTANCIAS
Instancias
INSTANCIAS DE RELACIONES
Instancias
relaciones
de
+/-
' -
REGLAS
Reglas
produccin
de
PROCEDIMIENTOS
Procedimientos
i^-,.
''^-
- .
'
Tabla 6.3. Expresividad del esquema de referencia propuesto con respecto a los lenguajes clsicos de
implementacin de ontologas
207
1. En el nivel superior, el conjunto de tablas y gratos que se utilizan para describir los metamodelos tienen la misma expresividad que LBIR.
2. En el nivel inferior, el esquema de referencia propuesto permite modelizar los mismos
componentes que la parte esttica de la unin de los lenguajes clsicos de
implementacin de ontologas. Esto se puede comprobar examinando la Tabla 6.3,
donde se muestra que el esquema de referencia propuesto en el presente trabajo
permite modelizar los mismos componentes que Ontolingua [Farqhuar et al.; 96], el
lenguaje utilizado en el OKBC [Chaudhri et al.; 97], OCML [Motta, 99], Flogic [Kifer et al.;
95] y LOOM [MacGregor, 90].
Por ltimo, es importante comentar que algunas partes de este trabajo han sido publicadas
donde se indica a continuacin:
1. La exposicin sobre metodologas se ha publicado en un estudio ms amplio en el
workshop titulado Ontologies and Problem-Solving Methods: Lessons Learned and
Futura Trends de la conferencia International Joint Conference for Artificial Intelligence
(IJCAI) celebrada en Estocolmo en 1999 [Fernndez Lpez, 99a].
2. Una visin global de ODE ha sido publicada en:
2.1. La revista IEEE Intelligent Systems & their applications [Fernndez Lpez et al.; 99]
se ha presentado una visin general de ODE.
2.2. En el Knowledge Acquisition Workshop (KAW) celebrado en Banff (Canad) en
1998 [Blzquez et al.; 98].
3. Algunos de los esquemas de conceptualizacin utilizados como casos de prueba, y
algunos aportaciones sobre la conceptualizacin de ontologas, se han publicado en:
3.1. En el Workshop on Knowledge Acquisition, Modelling and Management (EKAW)
[Fernndez Lpez et al.; 00], celebrado Jean Les Pins (Francia) en el 2000.
3.2. En la revista IEEE Intelligent Systems & their applications [Fernndez Lpez et al.;
99] se expone el esquema de referencia.
3.3. Se present un esquema anterior en el Symposium on Ontological Engineering de la
American Association for Artificial Intelligence (AAAI), celebrado en Stanford
(California) en 1997 [Fernndez et al.; 97].
3.4. El primero de los esquema utilizados se propuso en el Workshop on Ontological
Engineering celebrado en la European Conference on Artificial Intelligence (ECAI)
de Budapest en 1996 [Gmez Prez et al.; 96].
208
7 LNEAS FUTURAS
209
Captulo 7. Lneas futuras
7. LNEAS FUTURAS
Los puntos en los que se puede profundizar son los que se presentan a continuacin:
1. En el plano metodolgico, las lneas a considerar son las siguientes:
1.1.
Adquisicin de conocimientos a partir de textos. Se puede investigar en la

elaboracin de mecanismos de anlisis de textos para rellenar los EE.CC.
1.2.
Elaboracin de mecanismos para la administracin de la configuracin. Aunque ya

se establece la existencia de un comit de cambios y mtodos de control de
cambios en los esquemas de conceptualizacin, es conveniente fijar un sistema
global de administracin de la configuracin en el desarrollo de ontologas.
1.3.
Utilizacin de LBIR para expresar modelos de conocimientos propuestos por otros

autores. Por ejemplo, se puede utilizar LBIR para expresar el modelo de
conocimientos de Protege 2000 [Protege, 00], o para la modelizacin mediante de
gratos conceptuales [Sowa, 84].
1.4.
Utilizacin del mtodo para modelizar conocimientos no estticos. Por ejemplo, se

puede ampliar la investigacin para modelizar reglas o procedimientos.
1.5.
Utilizacin del mtodo en la construccin de otras ontologas que no sean slo de

dominio. Por ejemplo, se puede analizar, y si es necesario modificar, el mtodo
para su posible aplicacin en el desarrollo de ontologas de tareas, ontologas de
representacin, etc.
1.6.
Aumento de la expresividad de LBIR. En versiones futuras de LBIR se puede

pensar en la inclusin de caractersticas como la posibilidad de modelizacin de
reglas que mencionan sub-cadenas de valores, reglas que asuman" herencia,
reglas que contengan negaciones, etc.
2. En el plano tecnolgico se pueden considerar las siguientes lneas de actuacin:

2.1. Mejoras de la primera versin de ODE sin necesidad de aadir nuevas fases de la
metodologa. En concreto, migracin de la aplicacin mono-usuario sobre una
plataforma PC hacia una arquitectura multi-usuario cliente-servidor. Adems, es
necesario plantearse la posibilidad de que el servidor pueda estar en la Web.
2.2. Desarrollo de ODE completo que abarque todo el ciclo de vida de desarrollo de
ontologas.
2.3. Aprovechamiento de ODE para reas distintas del desarrollo de ontologas. Se
puede utilizar ODE, por ejemplo, para gestionar la documentacin de un negocio.
211
BIBLIOGRAFA
213
Bibliografa
BIBLIOGRAFA
[Aguado et al.; 98]
Aguado, G.; Gan, A.; Bateman, J.; Bernardos, S.; Fernndez,

M.; Gmez-Prez, A. Nieto, E.; Olalla, A.; Plaza, R.; Schez, A.
ONTOGENERATION:
Reusing
doman
and
ontologies for Spansh text generation.
linguisitic
Workshop on
Applications of Ontologies and Problem-Solving
Methods.
European Conference of Artificial Ingelligence (ECAI). Brighton

(Reino Unido). Pgs. 1-10.1998.
(Arprez et al.; 98]
Arprez, J. C ; Gmez-Prez, A.; Lozano, A. Pinto, H. S.

Reference Ontology and (ONTO)Âgent: The ontology
yellow pages. Workshop on Applications of Ontologies and
Problem-Solving Methods. European Conference o Artificial
Ingelligence (ECAI). Brighton (Reino Unido). Pgs. 16-24.
1998.
[Aussenac-Gilles et al, 00]
Aussenac-Gilles, N., Bibow, B., Szuman, S. Revisiting

Ontology Design: A Methodology
Analysis. Proceedings del
Based on
Corpus
7 7'" Workshop on Knowledge
Acquisition, Modelling and Management (EKAWOO). Jean-LesPins (Francia). Octubre, 2000. Pgs. 172-188.
[Eateman et al.; 95]
Bateman, J.; Magnini, B.; Fabris, B. The Generalizad Upper

Model knowledge base: organization and use. Towards Very
Large
Knowledge
Bases.
Ed.
IOS
Press.
msterdam
(Holanda). Pgs. 60-72.1995.

[EJateman et al.; 89]
Bateman, J. A.; Kasper, R. T.; Moore, J. D.; Whitney, R. A. A

general organization of knowledge for natural language
processing: The Penman Upper Model. Information Sciences
Institute {ISl). Universidad del Sur de California. Marina del
Rey. 1989.
[Benjamins et al.; 99]
Benjamins, V. R.; Fensel, D.; Decker, S.; Gmez-Prez, A.

(KA)^: building ontologies for the Internet: a mid-term
report. International Journal of Human-Computer Studies (51).
Pgs. 687-712. 1999.
[Benjamins et ai.; 96]
Benjamins, V. R.; Fensel, D.; Straatman, R. Assumptions of

problem-solving methods and their role in knowledge
engineering. En W. Wahlster Editor. Proceedings de la
European
El entorno de desarrollo de ontologas ODE
Conference
of
Artificial
Ingelligence
(ECAI).
215
Bibliografa
Budapest (Hungra). Pgs. 408-412.1996.

[Bernaras et al., 96]
Bernaras, A.; Laresgoiti, I.; Corera, J. Building and reusing

ontologies for electrical network applications. European
Conferencia
of
Artificial
Ingelligence
(ECAI).
Budapest
(Hungra). Pgs. 298-302. 1996.

[Blzquez et al.; 98]
Blzquez,
M.;
Fernndez-Lpez,
M.; Garca-Pinar,
J.M.;
Gmez-Prez, A. Building ontologies at the knowledge level

using
the
Acquisition
Ontology
Design
Workshop
(KAW).
Environment.
Banff
Knowledge
(Canad).
1998.
(http://ksi.cpsc.ucalqarv/KAW/KAW98/blazquez).
[Blzquez, 97]
Blzquez, M. Interfaz para ODE. Proyecto Final de Carrera de

la Facultad de Informtica de la Universidad Politcnica de
Madrid. Espaa. 1997.
[Blum, 96]
Blum, B.l. Beyond Programming. Oxford University Press.

Nueva York (Estados Unidos). 1996.
[Brachman et al.; 85]
Brachman, R. J.; Smolze, J. R. An overview of the KL-ONE

knowledge representation system. Cognitive Science, 9(2):
171-216. 1985.
[Bray et al.; 98]
Bray, T.; Paoli, J.; Sperberg, C. Extensible Markup Language

(XML)
1.0.
W3C
Recommendation.
Febrero,
1998.
(http://www.w3.orq/TR/REC-xmi).
[Chandrasekaran et al.; 99]
Chandrasekaran, B.; Johnson, T. R.; Benjamins, V.
R.
Ontologies: what are they? why do we need them?. IEEE

Intelligent Systems and Their Applications. 14(1). Special Issue
on Ontologies. Pgs. 20-26.1999.
[Chaudhri et al, 97]
Chaudhri, V.K.; Farqhuar, A.; Fikes, R.; Karp, P.D.; Rice, J.P.
The Generic Frame Protocol 2.0. Teclinical Report KSL-9705. Stanford University. California (Estados Unidos). 1997.
[Chen, 76]
Chen, P. The Entity-Relationship IVlodel: Toward a Unified

View of Data. ACM Transactions on Datbase Systems. Vol. 1,
N^ 1. Pgs. 9-36. Marzo de 1976.
[Codd, 70]
Codd, E.F. A Relational Model of Data for Large Shared

Data Banks. CACM 13, 6. Pgs. 377-387. 1970.
[Corcho et al., 00]
Corcho, O; Gmez Prez, A. A Road Map to Ontology

Specification Languages. Proceedings del "" Workshop on
216
Bibliografa
Knowledge Acquisition, Modelling and Management (EKAWOO).

Jean-Les-Pins (Francia). Octubre, 2000. Pgs. 80-96.
[Domingue et al.; 00]
Donningue, J.; Motta, E. Planet-Onto: From News Publishing

to Integrated Knowledge Management Support. IEEE Expert
Systems Special Issue on Knowledge Management and
Distributlon over the Internet. Mayo-junio 2000. Pgs. 26-32.
[Domingue, 98]
Donningue,
J.
Tadzebao
and
WebOnto:
Discussing,
browsing, and editing ontologies on the web. Knowledge

Acquisition
Workshop
(KAW).
Banff
(Canad).
1998.
(http://ksi.cpsc.ucalqarv/KAW/KAW98/dominque).
[DOS, 91]
MS-DOS 5.0. Manual de usuario del sistema operativo.

Microsoft Corporation. 1991.
[Downs et al.; 98]
Downs, E.; Clare, P.; Coe, I. Structured Analysis and Design

Method (SSADM). Prentice Hall. 1998.
[Duineveld et al.; 99]
Duineveld, A. J.; Stoter, R; Weiden, M.R.; Kenepa, B.;

Benjamins, V. R. Wonder tools?. Knowledge Acquisition
Workshop
(KAW).
Banff
(Canad).
1999.
(http://sern.ucalqarv.ca/KSI/KAW/KAW99/papers/Duineveld1/
wondertools.pdf).
[Farquhar et al.; 96]
Farquhar, A.; Fikes, R.; Rice, J. The Ontolingua Server: a

Tool for collaborative ontology construction. Technical
Report KSL-96-26. Knowledge Systems Laboratory. Stanford
University. California (Estados Unidos). 1996.
[F-ensel, 00]
Fensel,
D.
Ontologies:
silver
bullet
for
Knowledge
Management and Electronic Commerce. Springer-Verlag.

Berln. 2000.
[Fernndez Lpez et al.; 00]
Fernndez Lpez, M.; Gmez Prez, A.; Rojas Amaya, M. D.

Ontologies' crossed life cycles. Workshop on Knowledge
Acquisition, Modelling and Management (EKAW).
Editor
Springer Verlag. Jean Les Pins (Francia). 2000. Pgs. 6579.

[Fernndez Lpez, 00]
Fernndez Lpez, M. Anlisis y diseo de alto nivel del

entorno de diseo de ontologas: ODE. Tesis de Mster en
Ingeniera
del Software.
Facultad de Informtica de la
Universidad Politcnica de Madrid. Espaa. 2000.
217
Bibliografa
[Fernndez Lpez, 99a]
Fernndez
building
Lpez, M. Overview
ontologies.
of
Ontologies
methodologies for
and
Problem-Solving
Methods: Lessons Learned and Future Trends. International

Joint Conference on Artificial intelligence (IJCAI). Estocolmo
(Suecia). Pgs. 4-1 a 4-13.1999.
[Fernndez Lpez, 99b]
Fernndez Lpez, M. Introduccin a las bases de datos.

Facultad de Informtica de la Universidad Pontificia de
Salamanca en Madrid. Espaa. 1999.
[Fernndez Lpez et aL; 99]
Fernndez Lpez, M.; Gmez-Prez, A.; Pazos-Sierra, A.;

Pazos-Sierra, J. Building a chemicai ontology
using
Methontology and the Ontology Design Enmvironment.

IEEE Intelligence Systems & their applications. Pgs. 37-46.
Enero-febrero 1999.
[Fernndez et al.; 97]
Fernndez
Lpez,
M.;
METHONTOLOGY:
Ontological
Gmez
From
Engineering.
Prez, A.;
ontological
Juristo,
art
Symposium
on
N.
towards
Ontological
Engineering. American Association for Artificial Intelligence

(AAAI). Stanford. California (Estados Unidos). Pgs. 33-40.
1997.
[Fernndez, 96]
Fernndez Lpez, M. CHEMICALS : ontologa de elementos

qumicos. Proyecto Final de Carrera de la Facultad de
Informtica de la Universidad Politcnica de Madrid. Espaa.
1996.
[Garca-Pinar, 98]
Garca
Pinar,
J.
M.
Transformacin
de
modelos
conceptuales de ontologas en modelos relacinales.

Proyecto Final de Carrera. Facultad de Infonntica de la
Universidad Politcnica de Madrid. 1998.
[Genesereth et al.; 92]
Geneseretfi, M. R.; Fikes, R. E. Knowledge Interchange

Format. Versin 3.0. reference manual. Tecfinical Report
KSL-92-86.
Computer
Science
Department.
Stanford
University. California (Estados Unidos). 1992.

[Gmez Prez et al.; 99]
Gmez-Prez,
A.;
Rojas-Amaya,
Reengineering
for
Reuse.
M.
D.
Ontological
Knowledge
Acquisition
Modeling and Management. European Knowledge Acquisiton

Workshop. (EKAW). Pgs. 139-156. 1999.
[Gmez Prez, 98a]
Gmez Prez, A. Knowledge sharing and reuse. Handbook of
218
Bibliografa
Expel Systems. Ed.
CRC, por Liebowitz. Londres (Reino
Unido). 1998.
[Gmez Prez, 98b]
Gmez Prez, A. Nociones de Ingeniera Ontolgica. What

is
Ontological
Engineering?.
Facultad
de
Informtica.
Universiad Politcnica de Madrid. 1998.

[Gmez Prez et al., 97]
Gmez Prez, A . ; Juristo, N.; Pazos, J. Ingeniera del

conocimiento. Ed. Ceura. Espaa. 1997.
[Gmez Prez et al.; 96]
Gmez Prez, A.; Fernndez-Lpez, M.; de Vicente, Aj..

Towards a method to conceptualize domain ontologies.
Workshop on Ontological Engineering. European Conference of
Artificial Ingelligence (ECAI). Budapest (Hungra). Pgs. 41-52.
1996.
[Gruber et al.; 94]
Gruber, T.;Olsen, G. An ontology for

Mathematics.
Teclinicai
Report
Engineering
KSL-94-18.
Knowledge
Systems Laboratory, Stanford University. California (Estados

Unidos). 1994.
[Gruber, 93]
Gruber, T. R. A translation approach to portable ontology

specifications. Knowledge Acquisition. Vol. 5. Pgs. 199-220.
1993.
[Gruber, 92]
Gruber, T. R. Toward principies for the design of ontologies

used for knowledge sharing. International Workshop on
Formal Ontology. Padova (Italia). Pgs. 907-928. 1992.
[Grninger et al.; 95]
Grninger, M.; Fox, M. S. Methodology for the design and

evaluation of ontologies. Workshop on Basic Ontological
Issues in Knowledge Sharing. Montreal (Canad). 1995.
[Guarino, 92]
Guarino, N. Concepts, Attributes and Arbitrary Relations:

Some Linguistic and Ontological Criteria for Structuring
Knowledge Bases. Data & Knowledge Engineering 8. Pgs.
249-261.
[Hayes-Roth et al.; 83]
Hayes-Roth, F.; Waterman, D. A.; Lenat, D. B. Building Expert

Systems.
Addison
Wesley
Publishing
Company,
Inc.
Massachusets (Estados Unidos). 1983.

[Horrocks, 00]
Horrocks, I. Denotation Semantics for OIL-Lite
and
Standard OIL. Department of Computer Science. Universidad

de
Manchester.
Reino
Unido.
2000.
219
Bibliografa
(http://www.ontoknowledqe.orq/oil).
[IEEE, 98]
IEEE Recommended Practice for Software Requirements

Specifcatin. ANSI/IEEE std. 830-1998.1998
[IEEE, 96]
IEEE standard for developing software life cycle processes.

IEEE Computer Society. Nueva Yori< (Estados Unidos). 1996.
[IEEE, 83]
IEEE Guide for Software Quatity Assurance Planning.

ANSI/iEEE std. 829-1983, IEEE Computer Society, Software
Engineering Teciinical Committee. 1983.
[KACTUS, 96]
The KACTUS bookiet versin 1.0. Proyecto Esprit 8145.

Septiembre,
1996.
(Iittp://www.swi.psv.uva.nl/priects/
NewKACTUS/Reports.Intml)
[Karp et al, 99]
Karp, R.; Chaudhri, V.; Thomere, J. XOL: An XML-Based

Ontology Exchange Language. Technical Report. Artificial
Intelligence SRI International. 1999.
[Karp et al.; 95]
Karp, P. D.; Myers, K. Gruber, T. The Generic Frame

Protocol. XIV International Joint Conference on Artificial
Intelligence
(IJCAI).
Montreal
(Canad).
1995.
(ftp://ftp.ai.sri.com/pub/papers/i<arp-qfp95.ps.Z).
[Kent, 99]
Kent, R. Conceptual Knowledge Markup Language: The

Central Core. Knowledge Acquisition Workshop (KAW). Banff
(Canad).
1999.
(http://sern.ucalqarv.ca/KSI/KAW/KAW99/
papers/Kentl /CKIVIL.pdf). Banff, Alberta, Canad. 1999.

[Kifer et al.; 95]
Kifer, M.; Lausen, G.; Wu, J. Lgica! fountations of object

oriented and frame based languages. Journal of the ACM.
Pgs. 741-843.1995.
[Knight et ai.; 95]
Knight, K.; Chancer, I.; Haines, IVI.; Hatzivassiloglou. V.; Hovy,

E. H.; lida M.; Luk, S.K.; Whitney, R.A.; Yamada, K. Filling
knowledge
gaps
in
broad-coverage
MT
system.
International Joint Conference on Artificial Intelligence (IJCAI).

Montreal (Canad). 1995.
[Knight et al.; 94]
Knight, K.; Luck S. Building an large knowledge base for

machine translation.
American
Association
for
Artificial
Intelligence (AAAI). Seattie (Estados Unidos). Pgs. 773-778.

1994.
[Korth et al., 93]
Korth, H.; Silberschatz, A. Fundamentos de bases de datos.
220
Bibliografa
2- Edicin. McGraw-Hill. Nueva York (Estados Unidos). 1993.

[Lassila et al.; 99]
Lassila, O.; Swick, R. Resource Descripton Framework

(RDF) Model and Syntax Specficaton. \N3C Proposed
Recommendation. 1999. (littp.7/www.w3.ora/TR/PR-rdf-svntax).
[Lenat, 95]
Lenat, B.D. Steps to sharing knowledge. Towards Very Largo

Knowledge Bases. N.J.I. Mars, Ed. IOS Press. msterdam
(Holanda). Pgs. 3-6. 1995.
[Lenat et al.; 90]
Lenat, D.B.; Guha, R.V. Building large knowiedge-based

Systems. Addison-Wesley Publising Company, Inc. Nueva
York (Estados Unidos). 1990.
[Lpez Ruiz, 98]
Lpez Ruiz, F. Diseo de bases de datos. Facultad de

Informtica de la Universidad Pontificia de Salamanca en
Madrid. Espaa. 1998.
[Luque Ruiz et al., 97]
Luque Ruiz, I.; Gmez Nieto, M. A. Diseo y uso de bases de

datos relacinales. Ed. RA-MA. Espaa. 1997.
[Luke et al, 00]
Luke S.; Heflin J. SHOE 1.01. Proposed Specification. SHOE

Project. 2000. Technical Report. Universidad de Maryland.
Estados Unidos.
(http://www.cs.umd.edu/proiects/pius/SHOE/
spec1.01.htm).
[Luke et al, 97]
Luke, S.; Spector, L.; Rager, D.; Hendier, J. Ontology-based

Web Agenta. Proceedings of the First International Conference
on Autonomous Agents. Marina del Rey. California (Estados
Unidos). Pgs. 59-66.
[Maedche et al, 00]
Maedche, A., Staab, S. Mining Ontologies from Text.

Workshop
on
Knowledge
Management (EKAW).
Acquisition,
Modelling
and
Editor Springer Verlag. Jean Les
Pins (Francia). 2000. Pgs. 189-202.

[McGuinness, 99]
McGuinness, D. L. Ontologies for Electronic Commerce.

Technical Report KSL-99-07. Knowledge Systems Laboratory,
Stanford University. California (Estados Unidos). 1999.
[MacGregor, 90]
MacGregor,
Information
R.
M.
Sciences
LOOM
users
Instituto {ISI).
manual.
ISI/WP-22.
University of
South
California. Estados Unidos. 1990.

[Mailery, 94]
Mailery, J. C. A Common LISP hypermedia server. First
221
Bibliografa
International Conference on the Word Wide Web. CERN.

Ginebra (Suiza). 1994.
[MAP, 90]
Metodologa de planificacin y desarrollo de sistemas de

informacin.
Mtrica
versin
2.
Ministerio
para
las
Administraciones Pblicas (MAP). Espaa. 1990.

[MKBEEM, 00]
Requirements, Cholee of a Knowledge Representation and

Tools. Informe D.3.1 del paquete de trabajo WP.3 en el
proyecto europeo IST-1999-10589 MKBEEM
{Multilingual
Knowledge Based European Electronic Marketpiace).

2000.
[Miller, 90]
Miller, G. WordNet: an oniine lexical datbase. International

Journal of Lexicography, 3 (4). (Special Issue). 1990.
[Motta, 99]
Motta, E. Reusable Components for Knowledge Modelling.

IOS Press. msterdam (Holanda). 1999.
[Motta, 98]
Motta, E. Reusable Components for Knowledge Models.

Tesis doctoral del Knowledge Media Institute of the Open
University. Milton Keynes (Reino Unido). 1998.
[Mowbray et al.; 95]
Mowbray, T. J.; Zahavi, J. The ESSENTIAL CORBA: System

integration using distributed objects. John Wiley and Object
fJIanagement Group. 1995.
[Meches et al., 91]
Neches, N.; Fikes, R.; Finin, T . ; Gruber, T . ; Patil, R.;

Senator, T . ;
Swartout, W.R.
Enabling
technology
for
knowledge sharing. Al Magazine, Fall 1991. Pags. 36-56.

1991.
[Newell, 82]
Newell, A. The Knowledge Level. Artificial
Intelligence.
Volumen 18. Nmero 1.. Pgs. 87-127. Enero de 1982

[Pinilla Ponz, 99]
Pinilla Ponz, P. Ontologa de minerales. Aplicacin a la

clase de los silicatos. Proyecto Final de Carrera de la
Facultad de Ciencias Ambientales de la Universidad Autnoma
de Madrid. Espaa. 1999.
[Protege, 00]
Using
Protg-2000
to
Edit
RDF.
Technical
Report.
Knowledge Modelling Group. Stanford University. California

(Estados
Unidos)
2000.
(http://www.smi.Stanford.edu/
proiects/proteae/proteqe-rdf/protege-rdf.html).
222
[Rojas, 98]
Bibliografa
Rojas, M. D. Ontologas de iones monoatmicos en

variables fsicos del medio ambiente. Proyecto Final de
Carrera de la
Facultad de Informtica de la Universidad
Politcnica de Madrid. Espaa. 1998.

[Schreiber et al.; 00]
Schreiber, G.; Akkermans, H.; Ajewierden, A.; de Hoog, R.;

Shadbolt, N.; Van de Velde, W.; Wielinga, B. Knowledge
Engineering
and
IVIanagement.
The
CommonKADS
IVIethodology. The MIT Press. Cambridge (Estados Unidos).

2000.
[Schreiber et al.; 95]
Schreiber, G.; Wielinga, B.; Jansweijer W. The KACTUS view

on the 'O' worid. National Dutch Al Conference. NAIC-95.
msterdam (Holanda). 1995.
[Sowa, 84]
Sowa, J. F. Conceptual Structures. Information Processing

in Mind and Machine. Addison-Wesley Publishing Company.
System Programming Series. Massachusets (EE.UU). 1984.
[Studer et al.; 98]
Studer,
R.;
Benjamins,
V.R.;
Fensel,
D.
Knowledge
Engineering: Principies and Methods. Data & Knowledge

Engineering. 25:161-197.1998.
[Swartout et a l . ; 97]
Swartout, B.; Ramesh P.; Knight, K.; Russ, T. Toward

distributed use of large-scale ontologies. Symposium on
Ontological Engineering. American Association for Artificial
Intelligence (AAAI). Stanford (California). Estados Unidos.
Marzo1997.Pgs. 138-148
[Uschold et al.; 96]
Uschold, M.; Grninger, M. Ontologies: Principies methods

and applications. Knowledge Sharing and Review. Vol. 2.
Pgs. 93-155. 1996.
[Uschold et al.; 95]
Uschold, M. King, M. Towards a methodology for building

ontologies.
Workshop
on
Basic
Ontological
Issues
in
Knowledge Sharing. Interntional Joint Conference on Artificial

Intelligence (IJCAI). Montreal (Canad). 1995.
[van Heist et al., 97]
van Heist, G.; Schreiber, T.; Wielinga, B. Using Explicit

Ontologies in KBS. International Journal of Human-Computer
Studies. Vol.46 (2/3). Pgsil 83-292. 1997.
[VVaterman, 86]
Watennan, D. A. A guide to expert systems. Addison-Wesley.

Masachusets (Estados Unidos). 1986.
223
ANEXO I. VISION GENERAL DEL LENGUAJE

ONTOLINGUA
Anexo I. Visin general del lenguaje Ontolingua
I VISION GENERAL DEL LENGUAJE ONTOLINGUA

En este anexo se pretende exponer algunos aspectos complementarios a los ya presentados
en la seccin 2.4.1 sobre KIF y Ontolingua.
1.1 KIF
Es un lenguaje basado fundamentalmente en la lgica de primer orden, aunque con algo ms
de expresividad. Sus sentencias estn formadas por listas cuyo primer trmino es una
constante de relacin y el resto de elementos son trminos, y por operaciones lgicas sobre
otras sentencias [Gruber, 93]. Por ejemplo (estn-casados Juan Mana) es una lista donde
estn-casados es una relacin y Juan y Mara son trminos. Otro ejemplo es (not (estncasados Juan Mara)), que es una operacin lgica, not, sobre una sentencia. Los conjuntos
estn definidos utilizando una teora de conjuntos estndar; las listas son secuencias de
objetos; las relaciones se definen como conjuntos de ernas, donde cada erna es una lista de
objetos; y las funciones son un caso especial de relaciones, en el cual el elemento n-simo se
obtiene a partir de los elementos anteriores. Las variables pueden utilizarse para individuos
(precedidas de ?) y para conjuntos si van precedidas del smbolo @. A continuacin aparece un
ejemplo
de
una sentencia
escrita
en
KIF [Fernndez,
96], que
significa
que
la
electronegatividad de aquellos elementos que son halgenos es menor que 2,8 electronvoltios:
(forall (?elemento)
=> (and (halgeno ?elemento) (afinidad-electrnica ?elemento ?valor))
(< ?valor (*2.8 electronvoltio))))
Esta expresin se puede escribir en lgica de la siguiente manera:
V elemento, halgeno(elemento) A afinidad_electrnica(elemento, valor) =>
(valor < 2'8 * electronvoltio)
Las relaciones halgeno y afinidad electrnica, as como el trmino electronvoltio tienen que
estar definidos para que se puedan utilizar dentro de la expresin KIF.
1.2 EL LENGUAJE ONTOLINGUA

utilizando KIF y el vocabulario de la Frame Ontology, en Ontolingua se pueden definir clases,
relaciones, funciones, axiomas e instancias. Bsicamente, todas las definiciones en Ontolingua
presentan el mismo patrn: una cabecera, una definicin informal en lenguaje natural y una
definicin formal. La cabecera tiene una palabra clave que identifica el tipo de definicin, su
nombre, y, a continuacin, los parmetros. La definicin en lenguaje natural es una cadena de
caracteres encerrada entre comillas. Y por ltimo, la definicin formal consta a su vez de una
palabra reservada y de una expresin KIF que va detrs. Esta expresin puede contener
trminos de la Frame Ontology. Algunas de las palabras reservadas ms importantes no
pertenecientes a la Frame Ontology son:
-
:Def para expresar condiciones suficientes en las que los parmetros de la definicin son
Anlisis y diseo de alto nivel del entorno de diseo de ontologas
1-3
variables libres.
-
:lff-def para expresar condiciones necesarias y suficientes en las que ios parmetros de
la definicin son variables libres.
:Lambda-body, en funciones, para expresar el valor de la funcin en trminos de sus

parmetros. Esta palabra se puede sustituir por :ff-def.
:Axiom-def, para expresar condiciones de la definicin, aunque a diferencia de :defe :iffdef, no hacen referencia a los parmetros de sta, sino a su nombre, por lo tanto, la
expresin que aparece acompaando a :axiom-def puede trasladarse a una definicin
aparte sin cambiar el conocimiento que aparece en la ontologa.
:Constraint, que antecede a expresiones KIF que son lgicamente equivalentes a las del
:def, sin embargo tiene otros propsitos, tales como imponer restricciones de
consistencia, por ejemplo, que un determinado trmino que aparece en un denominador
sea distinto de cero.
:class-slots precede a la asignacin de valores a los atributos de clase.
- -.valu se utiliza para asignar valores a los atributos de clase.

En los siguientes apartados se exponen los elementos del lenguaje, y el formato de una
ontologa cualquiera en Ontolingua.
1.2.1 ELEMENTOS DEL LENGUAJE

A continuacin se presentan algunos ejemplos de definiciones [Fernndez, 96]:
a. Relaciones:
El ejemplo que se presenta a continuacin expresa la condicin necesaria y suficiente
que tienen que satisfacer dos nmeros naturales para que el par formado por ellos
pertenezca a la relacin primos-entre-s:
(define-relation primos-entre-s (?num1 ?num2)
"Dos nmeros son primos entre s si y slo si el nico divisor
comn es el 1"
:iff-def (and (natural ?num1)
(natural ?num2)
(forall ?num (=> (and (natural ?num)
(divide ?num ?num1)
(divide ?num ?num2))
(= ?num 1))))
las palabras natural y divide tienen que estar definidas en la ontologa o en otra
importada.
b. Funciones:
1-4
La definicin que aparece a continuacin presenta una funcin que relaciona un nmero
con su cuadrado:
(define-function Cuadrado (?n):-> ?valor
"Bicuadrado de un nmero es el producto de l por s mismo"
:def (and (nmero ?n)
(nmero-positivo ?valor))
:lamba-body (* ?n ?n))
Tambin, como se puede ver en el siguiente ejemplo obtenido de la ontologa KifNumbers, se pueden definir funciones a intervalos:
(define-function ABS (?x)
"El valor absoluto de un nmero es el mismo nmero si ste es
positivo, y su opuesto si es negativo"
:lambda-body (if (>= ?x 0) ?x (- ?x)))
La funcin ABS devuelve el mismo valor que recibe si ste es mayor o igual que cero, y
devuelve su opuesto en otro caso.
En el ejemplo anterior se puede ver que no se ha escrito el parmetro de salida de la
funcin, sin embargo, en el ejemplo del cuadrado de un nmero s aparece. La razn es
que mientras en la funcin cuadrado el parmetro de salida aparece para imponerle una
condicin, nmero-positivo, en la funcin ABS no se hace ninguna referencia a este
parmetro.
c. Clases:
El siguiente ejemplo se ha tomado de la ontologa Standard-Units:
(define-class Unidad-SI (?unidad)
"La clase de las unidades del Sistema Internacional"
:def (Unidad-De-Medida ?unidad)
:axiom-def
(and (Sistema-De-Unidades Unidad-SI)
(= (Unidades-Base Unidad-SI)
(setof Metro Kilmetro Segundo-De-Tiempo Amperio Grado-Kelvin
Mol Candela Unidad-Identidad))))
Esta definicin significa que unidad-SI es un sistema de unidades en el que el conjunto de
unidades base est formado por: el metro, el kilmetro, etc.
d. Las instancias:
Admiten el mismo tipo de expresiones que las funciones, aunque el :lambda-body de las
instancias no tiene variables libres [Gruber, 93]. El ejemplo que viene a continuacin
tambin se ha tomado de la ontologa Standard-Units:
(define-individual Newton (Unidad-De-Medida)
"Unidad de fuerza del Sistema Internacional"
:= (* (* Kilogramo Metro) (Elevar Segundo-De-Tiempo -2))
:axiom-def
(and (= (Magnitud-Fsica Newton) Fuerza) (Unidad-SI Newton)))
1-5
En esta expresin se define el Newton como:
kilogramo x metro.
segundo
y se establece un axionna en el que se dice que la magnitud-fsica del Newton es la fuerza, y
que el Newton es una unidad-Si.
e. Los axiomas en Ontolingua:
Los axiomas se llaman nombrados cuando aparecen en la ontologa como una definicin
ms, estando formados por una cabecera, la descripcin en lenguaje natural, y la expresin
del axioma. Por ejemplo:
(define-axiomcond-primos-entre-s
"Si dos nmeros son primos entre s, entonces son distintos"
:= (forall ?num1 num2 (=> (primos-entre-si ?num1 ?num2)
(o ?num1 ?num2)))))
Los axiomas se llaman no nombrados cuando aparecen dentro de otra definicin
acompaados de la palabra clave :axiom-def, como se puede observar en el ejemplo del
Newton que aparece en el apartado c).
1.2.2 FORMATO DE UNA ONTOLOGA EN ONTOLINGUA

Una ontologa en Ontolingua comienza con una cabecera que contiene su nombre, las
ontologas que importa, una descripcin general de la ontologa en lenguaje natural, y suele
incluir tambin otros comentarios como los autores, la fecha de creacin etc. Un ejemplo de
cabecera puede ser el siguiente:
(In-Package "ONTOLINGUA-USER")
#1 Escrita por
Mariano Fernndez Lpez #
;;; Fecha: octubre de 1999
(Define-Ontology Prueba
(Frame-Ontology)
("Esta ontologa es, sencillamente, una prueba"
:lo-Package
"ONTOLINGUA-USER")
(In-Ontology (Quote Prueba)
Los puntos y coma (";"), y los sostenidos ("#") acompaados de barras verticales ("I") se utilizan
para los comentrios. El resto de la informacin relevante es el nombre de la ontologa, el hecho
de que se importa la Frame Ontology, y la documentacin en lenguaje natural describiendo la
ontologa.
1-6
Despus de la cabecera, aparecen las definiciones de los trminos de la ontologa.
1-7
ANEXO II. EJEMPLO DE

CONCEPTUALIZACIN CON EL ESQUEMA
DE REFERENCIA
Anexo II. Ejemplo de conceptualizacin con el esquema de referencia
II EJEMPLO DE CONCEPTUALIZACIN
ESQUEMA DE REFERENCIA
CON
EL
E:l ejemplo para mostrar cmo se conceptualiza una ontologa siguiendo un determinado
modelo se ha tomado de la ontologa de iones monoatmicos [Rojas, 98]. Incluye la lista de
algunos de los iones que pueden formarse a partir de los elementos qumicos en estado
fundamental. Pertenecen a la ontologa aquellos iones que se detectan en los anlisis de agua,
suelo y aire; as, una de sus utilidades principales puede ser la comprobacin de posibles
contaminaciones en estos medios.
En la Tabla 11.1 se muestra la ficha de descripcin general de la ontologa Chemical
Elements; en la Tabla 11.2, el glosario de trminos; en la Figura 11.1 el rbol de clasificacin de
conceptos; en la Tabla 11.3, la lista de trminos a importar; en la Figura 11.2, el diagrama de
relaciones; en la Tabla 11.4, parte del diccionario de conceptos; en la Tabla 11.5, se muestra la
relacin ion isoelectrnco con ion; en la Tabla 11.6, la relacin forma compuesto con; desde la
Tabla 11.6 hasta la Tabla 11.9 aparecen los atributos de instancia peso atmico, volumen atmico
a 20-y densidad a 20-, en la Tabla 11.10, se presenta un ejemplo de constante; la Tabla 11.11
muestra un axioma; la Tabla 11.12, una frmula; y, en la Tabla 11.13, se muestra parte de la tabla
de instancias.
Chemical Elements
Nombre
Fecha y hora de creacin 16 de mayo de 1996
Mariano Fernndez Lpez con la colaboracin y consejo de Asuncin Gmez
Autores
Prez
Modeliza el dominio de los elementos qumicos. El objetivo de esta ontologa es
utilizarla en la enseanza, la industria, etc. Esta ontologa se ha desarrollado
dentro de proyecto METHONTOLOGY, que tiene como objetivo establecer un
mtodo para construir ontologas.
Descripcin
[Handbook, 84-85] Handbook of Chemistry and Physics. 65' edicin. CRCPRESS, INC. 1984-1985.
[Hidalgo, 84] Hidalgo, P. J. Curso breve de qumica: electroqumica y
corrosin. Ed. ECAI. 1984.
Tabla II. 1. Ficha de descripcin general en la ontologa Chemical Elements
II-3
Descripcin
(Del griego chloros, color verde amarillento), Cl; numero atmico 55; peso atmico 35,453; valencias
1, 3, 5 y 7. Descubierto en 1774 por Scheede, que pens que contena oxgeno. Fue nombrado por
Davy, que insisti en que era un elemento. Es un halgeno que en la naturaleza se encuentra slo en
estado combinado, principalmente con el sodio [Handbook, 84-85],
La densidad de un cuerpo es la masa de una unidad de volumen.
Es una sustancia formada por tomos con el mismo nmero de protones.
(Del planeta Mercurio), Hg (hydrargyrum, plata lquida); nmero atmico 80; peso atmico 200,59 +
0,03; valencias 1 y 2. El metal se obtiene calentando el cinabrio en una corriente de aire y condensando
el vapor. Es un metal pesado de color blanco plateado; un mal conductor del calor si se lo compara con
otros metales; y un mediano conductor de la electricidad [Handbook, 84-85].
(Del latn aurum, aurora brillante), Au; nmero atmico 79; peso atmico 196,97; valencias 1 y 3.
Cuando est en cantidad, es de color amarillo metlico; pero cuando se divide en hilos finos puede ser
negro, rub o prpura. Es un metal blando y normalmente se puede estirar. Es buen conductor del calor
y de la electricidad, y no le afecta el aire ni la mayor parte de los reactivos. Se pueden obtener
fcilmente hilos y lminas. [Handbook, 84-85].
Presin a la que se llevan a cabo muchos experimentos en el laboratorio.
La masa relativa de un tomo de un elemento con respecto a la masa de la duodcima parte del istopo
carbono 12 [Hidalgo, 84].
Un elemento puede reaccionar con otro para formar un compuesto.
(De soda, que a su vez proviene del latn medieval sodanum, remedio para el dolor de cabeza). Na (del
latn nalrium); nmero atmico 11;, peso atmico 22,99; valencia 1.
Nombre
Cloro
Densidad a 20 C
Elemento
Mercurio
Oro
Presin estndar
Peso atmico
Forma compuesto con
Sodio
Temperatatura estndar
Tercera serie de transicin
Volumen atmico a 20C
Es un elemento que aparece en muchos compuestos. El primero en aislarlo fie Davy en 1807. El sodio
es bastante abundante en el Sol y las estrellas. Es el sexto ms abundante en la Tierra y el primero de
los alcalinos, representando el 2,6 % de la corteza terrestre. Es un elemento muy reactivo y no se
encuentra en estado libre. El sodio es un metal blando, brillante y plateado. [Handbook, 84-85].
Temperatura a la que se llevan a cabo muchos experimentos en el laboratorio.
El conjunto de elementos que pertenecen a los grupos Ib, Ilb, Illb, FVb, Vb, Vlb, Vllb y VIII de los
grupos de sexto periodo.
Es el volumen ocupado por un tomo gramo de un elemento a 20 C.
Tabla II.2. Glosario de trminos en la ontologa Chemical Elements
Nombre del trmino en

el origen
Atmosphere
Density Quantity
Lenght Quantity
Mass Quantity
Matter Quantity
Pressure Quantity
Temperature Quantity
Celsius Degree
Kilogram
Meter
Mole
Real number
Atontc mass unit
Nombre de la ontologa
Standard Units
Standard Dimensions
Standard Dimensions
Standard Dimensions
Standard Dimensions
Standard Dimensions
Standard Dimensions
Standard Units
Standard Units
Standard Units
Standard Units
KIF Numbers
Standard Units
Servidor
Ontolingua Server
Ontolingua Server
Ontohngua Server
Ontolingua Server
Ontolingua Server
Ontohngua Server
Ontohngua Server
Ontolingua Server
Ontolingua Server
Ontolingua Server
Ontolingua Server
Ontolingua Server
Ontolingua Server
Nombre del trmino en

el destino
Atmsfera
Cantidad de densidad
Cantidad de longitud
Cantidad de masa
Cantidad de materia
Cantidad de presin
Cantidad de temperatura
Grado centgrado
Kilogramo
Metro
Mol
Nmero real
Unidad de masa atmica
Tabla II.3. Lista de trminos a importar en la ontologa

Chemical Elements
II-4
Anexo I. Ejemplo de conceptualizacin con el esquema de referencia
- . . . - . . . .
_.i
Particin disjunta
Subclase de
Figura II. 1. rbol de clasificacin de conceptos en la ontologa Chemical Elements
Anlisis y diseo de alto nivel del entorna de diseo de ontologas
II-5
Figura II.2.
Nombre del
concepto
Elemento
Diagrama de relaciones binarias en la ontologa Chemical Elements
Sinnimos
Abreviaturas
--
--
Elm.
Serie
de
Tercera serie
transicin del
de transicin
sexto periodo
Tabla II.4.
Instancias
3ST
Oro
Hafnio
Mercurio
Osmio
Iridio
Platino
Renio
Tantalio
Wolframio
Atributos
de clase
--
Electronegativiad
Densidad a 20 "C
Estado de oxidacin
Grupo
Nmero atmico
Periodo
Peso atmico
Punto de ebullicin
Punto de fusin
Volumen atmico a 2<fC
--
Relaciones
Forma
compuesto
con
--
Diccionaro de conceptos en la ontologa Chemcial Elements
Nombre de la relacin
Concepto origen
Cardinalidad del origen
Concepto destino
Propiedades matemticas
Relacin inversa
Referencias
Forma compuesto con

Elemento
(l,n)
Elemento
Forma compuesto con
--
Tabla II.5. Relacin binaria Ae forma compuesto

con en la ontologa Chemical
Elements
II-6
Nombre de la relacin
Concepto origen
Cardinalidad concepto origen
Concepto destino
Propiedades matemticas
Relacin inversa
Referencias
Tabla II.6.
Ion isoelectrnico con elemento

Ion qumico
(I.n)
Elements
Elemenio isoelectrnico con ion

[Whilenetal.,76]
Tabla de la relacin ion isoelectrnico con

elemento [Rojas, 98]
Nombre del atributo de instancia

Concepto
Tipo de valor
Unidad de medida
Precisin
Intervalo de valores
Valor por defecto
Cardinalidad
Deducido de los atributos de instancia
Deducido de los atributos de clase
Deducido de las constantes
Frmula
Para deducir
Referencias
Tabla II.7.
ri.257]
(1,1)
Densidad a 20 C
[Hidalgo, 84]
Tabla del atributo de instancia

peso atmico en la ontologa
Chemical Elements

Concepto
Tipo de valor
Unidad de medida
Precisin
Valor por defecto
Cardinalidad
Frmula
Para deducir
Referencias
Tabla II.8.
Peso atmico
Elemento
Cantidad de masa
Urna
0,001
Volumen atmico a 20 "C

Elemento
Cantidad de volumen
centmetro'/ mol
[0, 100]
(I.n)
~
Densidad a 20 C
[Hidalgo, 84]

volumen atmico a 20 "C en la
ontologa Chemical Elements
II-7
Densidad a 20 C
Elemento
Cantidad de densidad
gramo/centmetro'
0,001
[0, 251

Concepto
Tipo de valor
Unidad de medida
Precisin
Valor por defecto
Cardinalidad

Frmula
Para deducir
Referencias
Tabla II.9.
Nombre de la
constante
(l,n)
Peso atmico
Volumen atmico
Frmula de la densidad
---

densidad a 20 "C en la ontologa
Chemical Elements
Tipo de
valor
Cantidad de
Temperatura estndar
temperatura
Cantidad de
Presin estndar
presin
Valor
25
1
Unidad de
medida
Grado
centgrado
Para deducir
Referencias
--
--
--
Atmsfera
Tabla 11.10. Tabla de constantes en la ontologa Chemical Elements
Nombre del axioma

Descripcin
Concepto descrito
Conceptos referidos
Atributos referidos
Variables
Expresin
Referencias
Alta electronegatividad de los no metales

La electronegatividad de los no metales es mayor que 2,1
Elemento
No metal
Electronegatividad
X,Y
ForalKX, Y) (No_metal(X) and Nmero_real(Y) and Electronegatividad(X, Y) -> Y > 2,1
Tabla II. 11. Axioma alia electronegatividad de los no metales en la ontologa Chemical Elements
Nombre de la frmula
Concepto
Atributo deducido
Frmula
Descripcin
Atributos bsicos
Constantes
Precisin
Restricciones
Referencias
Frmula de la densidad
Elemento
Densidad a 20 C
Densidad a 20 C = Peso atmico / Volumen atmico a 20 C
La densidad de un elemento qumico es el cociente entre su peso atmico y
su volumen atmico.
Peso atmico
Volumen atmico
Volumen atmico a 20 > 0
Tabla 11.12. Frmula de la densidad en la ontologa Chemical Elements
II-8
Se utiliza en
Obtiene
Atributo de
instancia
Frmula
Figura II.3. rbol de clasificacin de atributos en la ontologa Chemical Elements

Instancia
Cloro
Atributo
Nmero atmico
Peso atmico
Electronegatividad
Relacin
1
3
5
7
Estado de oxidacin
Mercurio
Forma compuesto con
Nmero atmico
Peso atmico
Densidad a 20 C
Electronegatvidad
Estado de oxidacin
Oro
Sodio
Estado de oxidacin
Nmero atmico
Peso atmico
Electronegatividad
Estado de oxidacin
Nmero atmico
Peso atmico
Densidad a 20 C
Electronegatividad
--
Valor
17
35,453
3,0
Forma compuesto con
Sodio
80
200,59
13,546
1,9
1
2
79
196,97
19,32
2,4
1
3
11
22,99
0,9
1
Cloro
Tabla 11.13. Tabla de instancias en la ontologa

Chemical Elements
II-9
ANEXO III. GRAMTICAS DE LOS CAMPOS,

LOS VRTICES Y LOS ARCOS
Anexo III. Gramticas de los campos, los vrtices y los arcos
III GRAMTICAS DE LOS CAMPOS, LOS VRTICES Y

LOS ARCOS
Con el propsito de precisar la sintaxis de los distintos componentes de los EE.CC, en este
anexo se muestran las gramticas de los campos de las tablas, y la gramtica de los vrtices y
los arcos de los gratos. Se utilizarn los siguientes smbolos especiales en la descripcin de la
sintaxis:
:=
Separador entre la parte izquierda y la parte derecha de una regla. Es decir, entre
lo que se pretende describir con la regla y su descripcin.
<>
Deiimitadores de los smbolos no terminales, o lo que es lo mismo, aquellos que

tienen que aparecer en la parte derecha de una regla.
{]
Lo que aparezca entre estos smbolos se puede repetir varias veces.
[]
Delimitadores de partes opcionales de la parte derecha de la regla.
Separa opciones de las que slo una es posible.
Adems, las descripciones que aparezcan en cursiva en la parte derecha de las reglas harn
referencia a definiciones bsicas.
IIII.1 GRAMTICAS DE LOS CAMPOS DE LAS TABLAS

La sintaxis de cada formato es la siguiente:
a. Descripcin. Su gramtica es GQ = <TD, NQ, PD, AD>, donde
i.
7D es cualquiera de los caracteres ANS de la tabla 850 con cdigos comprendidos

entre 32 y el 254, ambos inclusive [DOS, 91].
ii. A/D = {<carcter ANSI>, <descripcin>}

ii. Las reglas de PD son las siguientes:
<carcter ANSI> :=
Cualquier elemento de No
<descripcin>
<carcter ANSI> <descripcin>
:=
iv. El axioma (Ao) es <descripcin>

b. Texto. Su gramtica es la misma que la del formato descripcin; pero el texto est
limitado a 255 caracteres.
c. Trmino. Sigue la gramtica GT = <7V, NT, PT, Ar>, donde:
i. Se tiene
III-3
Tj=
{a, b, c, d, e, f, g, h, i, j, k, I, m, n, , o, p, q, r, s, t, u, v, w, x, y, z, A, B,
C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S. T, U, V. W. X, Y, Z, . ,
, , , , , , , , , , O, 1, 2, 3, 4, 5, 6, 7, 8, 9, el carcter 32 del
ANS}
ii. A/r = (<letra en espaol>, <dgito>, <espacio>, <dentificador>, <resto id>}

iii. Las reglas de Py son las siguientes:
<letra en espaol>
:=
aibcldlelflglhliijikllllilmlnl
lolplqlrlsltlulvlwlxl
ylzIAIBIC
I D I E I F I G I H II IJ i K I L I M I N I O I P I Q I
RISITIUIVIWIXI
YlZIlllll
I I I I l I
<dgito>
1I2I3I4I5I6I7I8I9I0
<espacio>
el carcter 32 del ANS
<letra o d g i t o
<letra en espaol> I <dgito>
<identificador>
<Ietra en espaol> I <letra en espaol> <resto

id>
<letra o dgito> <espacio> <resto id> I
<resto id>
<letra o dgito> <resto id>

iv. El axioma {Aj) es <identificador>
d. Variable: la gramtica de variable es la misma que la de trmino.
e. Cardinalidad. Un campo de este tipo debe seguir la gramtica Ge = <Tc, Nc, Pe. Ac>,
donde:
i. Se tiene
Tc=
{(,),0,
1,n}
i. A/c = {<cardinalidad>}
iii. Las reglas de Pe son las siguientes:
<cardinalidad>
:=
(0,1) I
(1,1)1
(O, n) I
(1,n)
III-4
iv. El axioma (Ac) es <cardinalidad>.

f. Expresin aritmtica. Este formato sigue la gramtica
GEA = <TEA, NEA, PEA, AEA>,
donde:
i. Se tiene
TEA =
{a,b, c. d. e, f, g, ti, i, j, l<, I, m, n, , o. p, q, r. s, t, u, v, w, x, y, z, A, B,

C. D. E, F. G, H, I, J, K, L, M, N, O, P, Q, R. S, T. U, V. W, X, Y, Z. , ,
, , , , , , , , , , _, O, 1, 2, 3, 4, 5, 6, 7, 8, 9}
ii. Adems,
WEA=
{<letra en espaol>, <dgito>, <subrayado>, <punto>, <coma>,

<parntesis
abierto>,
<parntesis
cerrado>,
<suma>,
<resta>,
<multiplicacin>, <divisin>, <letra o dgito>, <id. subrayado>, <resto

id>, <real>, <nmero>, <positivo>, <natural>, <operacin sum rest>,
<operacin multdiv>, <expresin aritmtica>, <trmino
aritmtico,
<factor aritmtico>, <identif. con parms>, <lista expr. aritmticas>,

<resto de la lista>}
iii. Las reglas de PEA se han obtenido siguiendo los pasos que se muestran a
continuacin:
1.
Los objetos ms elementales que se consideran son: las letras del alfabeto
espaol, acentuadas y no acentuadas, y con diresis; los dgitos; el carcter de
subrayado; el punto; la coma; los dos parntesis, es decir,"(" y")"; y los smbolos
de sumar, restar, multiplicar y dividir. Se tienen, por tanto, las siguientes reglas:
<letra en espaol>
:=
alblcldlelflglhliljlkllllllmlnl
ylzl AIB
I C I D I E I F I G I H 111 J I K I L I M I N I O I P
IQIRISITIUIVIWIXI
YlZIlll
lllIIII
<dgito>
:=
<subrayado>
:=
<punto>
:=.
<coma>
:=
<parntesis abierto
:=
<parntesis cerrado :=
<suma>
:=
1I2I3I4I5I6I7I8I9I0
_
III-5
2.
<resta>
:=
<multiplicacin>
:=
<divisin>
:=
Con letras, dgitos y subrayados se pueden formar los identificadores:

<letra o dgto>
:=
<d. subrayado>
:=
<Ietra en espaob I <letra en espaol> <resto

id. subr.>
<resto id. subr.>
:=
<letra o dgito> <subrayado> <resto id. subr.>

I <letra o dgito <resto id. subr.>
3.
4.
Combinando dgitos y el punto, se forman nmeros:

<nmero>
:=
<natural> I <natural>.<natural>
<natural>
:=
<dgito> I <dgito> <natural>
Con los signos de sumar, restar, multiplicar y dividir, se forman las operaciones
aritmticas bsicas:
5.
<operacin sumrest.> :=
<suma> I <resta>
<operacin multdiv.> :=
<multiplicacin> I <multiplicacin>
Con nmeros, operaciones aritmticas, parntesis, comas e identificadores se

forman las expresiones aritmticas, los identificadores con parmetros y las listas
de expresiones (ver ejemplo de la Figura III.1):
<expresin aritmtica>
:=
<expresin
aritmtica>
<operacin
sumrest.> <trmino aritmtico> I <trmino

aritmtico> I + <nmero> I
- <nmero>
<trmino aritmtico :=
<trmino aritmtico
<operacin
multdiv.>
<factor aritmtico I <factor aritmtico>

<factor aritmtico
:=
<nmero> I <id. subrayado> I <identif. con

parms> I <expr. entre params>
<expr. entre params> :=
<parntesis abierto> <expresin aritmtica>

<parntesis cerrado
<identif. con parms> :=
<id. subrayado <lista expr. aritmticas>
III-6
<trmino aritmtico>
<operacin suinrest.>
<tmiino aritmtico>
<tni)ino aritmtico>
<operacin multdiv>
<factor aritmtico>
<factor aritmtico>
<factor aritmtico
i
i
<identif con paims>

:on f
mero
<identif con parms>
<lista expr. aritmticas>

<identficador>
<parntesis abierto>
<expresin aritnitica>
<trmino aritmtico>
<resto de la lista>
<conia>
<parntesis cerrado>
<identficador>
<parntesis abierto>
<parntesis ceiTado>
+
+
<trmino aritmtico>
I arti
expt
<factor aritmtico
<factor aritmtico>
ritmt
<factor aritmtico>
<identiflcador>
<identificador>
ritm
<identificador>
I
y
Figura III. 1. Ejemplo de anlisis sintctico de la expresin aritmtica expt(x, y) + 3 * sin(x) segn la gramtica propuesta para los formatos de los campos
III-7
:=
<expr. entre params> I
<parntesis abierto <expresin aritmtica>

<resto de la lista> <parntesis cerrado
<resto de la lista>
:=
<coma> <expresin aritmtica> I

<coma> <expresin aritmtica> <resto de la
lista>
Las expresiones aritmticas estn estructuradas en varios niveles (expresiones,

trminos y factores) para permitir operaciones con distinta precedencia.
iv. el axioma (A^^) es <expresin aritmtica>
g. Expresin lgica. Sigue la gramtica
GEL = <TEL, NEL, PEL, AEL>,
donde
i. Se tiene
7EL = 7'EA U {=, <, >} (ver definicin f, la de expresin aritmtica)
ii. Adems,
Nei = /ÊA ^ {<expresin lgica>, <implicacin>, <expresin nivel 1>, <lista de
variables>, <resto de variables>, <expresin nivel 2>, <factor
lgico>, <oprel>, <cuantificador>}
iii. Las reglas de PEL son, adems de las reglas de PEA, las siguientes:
<expresin lgica>
:=
<expresin nivel 1> <implicacin> <expresin

lgica> I
<expresin nivel 1 >
<implicacin>
:=
-> I <->
<expresin nivel 1>
:=
<expresin nivel 1> or <expresin nivel 2> I

<expresi6n nivel 2>
<lista de variables>
:=
<parntesis
aberto>
<id.
subrayado
<parntesis cerrado <parntesis abierto I

<id.
subrayado
<resto
de
variables>
<parntesis cerrado
<resto de variables>
:=
, <id. subrayado I <id. subrayado <resto de

variables>
<expresin nivel 2>
:=
<expresin nivel 2> and <factor lgico I

<factor lgico
<factor lgico
:=
<identif. con parms> I
III-8
<expresin aritmtica> <oprel> <expresin

aritmtica> I
<parntesis
abierto
<expresin
lgica>
<parntesis cerrado I
<cuantificador> <lista de variables> <factor
lgico>
<oprel>
:=
= I =< I >= I < I >
<cuantificador>
:=
forall I exists
iv. el axioma (ÊL) es <expresin lgica>

h. Intervalo de valores. Sigue la gramtica Giv = <Tiv, Nv, Pm Av>, donde
i. Se tiene
7iv= TEA
ii. Adems,
A/iv = WEA ^ {<intervalo de valores>} (ver definicin f, la de expresin
aritmtica)
111. Las reglas de Piv son, adems de las reglas de PEA, las siguientes:
<intervalo de valores>
:=
<parntesis abierto <expresin aritmtica>

<parntesis cerrado
iv. el axioma (Av) es <ntervalo de valores>

i. Enumeracin. Sigue la gramtica GE = <TE, NE, PE, AE>, donde
i. Se tiene
TE =Ty<j
{[.],,}
ii. Adems,
A/E = Air u {<enumeracin>, <resto de la enumeracin>} (ver definicin c, la
de trmino)
ii. Las reglas de PE son, adems de las reglas de PEA, las siguientes:
<enumeracin>
:= [<identificador>] I
[<identificador> <resto de la enumeracin>]
III-9
<resto de la enumeracin> := , <identificador> I

, <identificador> <resto de la enumeracin>
iv. el axioma (A^) es <enumeracin>
III.2 GRAMTICAS DE LOS VRTICES Y DE LOS ARCOS DE

LOS GRAFOS
Los identificadores de los vrtices y de los arcos siguen la misma gramtica Gj = <TT, NT, PT,
AT>, es decir, la del formato trmino de las tablas.
III-10
ANEXO IV. GRAMTICA DE LAS REGLAS

DE CONSISTENCIA
Anexo IV. Gramtica de las reglas de consistencia
IIV GRAMTICA DE LAS REGLAS DE CONSISTENCIA

La sintaxis utilizada para especificar reglas de consistencia sigue la gramtica
GRC = <TFIC,
NRC, PRC, ARC>, donde
i. Se tiene
7RC
= {a,b, c, d, e, f, g, h, i, j, k, I, m, n, , o, p, q, r, s, t, u, v, w, x, y, z, A, B, C, D, E, F,
G, H. I, J, K, L, M. N, O. P, Q, R. S, T, U. V, W, X, Y, Z, , , , , , , A, , , ,
, , -, O, 1, 2, 3, 4, 5, 6, 7, 8, 9, (, ) , [. ], ., el carcter 32 del ANS de la tabla
850}
ii. Adenns,
Nfc = {<letra en espaol>, <guin>, <espacio>, <parntesis abierto>, <parntesis
cerrado,
<corchete abierto,
<corchete cerrado,
<punto>, <coma>,
<dgito>, <identificador>, <continuacin>, <guin o espacio,
<campo>,
<arco de entrada>, <arco de entrada>, <componente>, <proyeccin

ordenada>, <matriz>, <expresin lgica>}
ii. Para las reglas de PRC se ha hecho una descripcin por pasos que van desde las reglas
de la gramtica ms elementales hasta el axioma. Estos pasos son:
1.
Los objetos ms elementales que se consideran son: las letras del alfabeto espaol,
acentuadas y no acentuadas; el carcter espacio; los dos parntesis, es decir, "(" y
")"; los dos corchetes ("[" y "]"); ' punto; la coma; el guin; y los dgitos. Se tienen,
por tanto, las siguientes reglas:
<letra en espaob
:=alblcldlelflglhliljlkllllllmlnllolp
IqlrlsItlulvlwlxlylzIAIBICIDlEFI
GIHIIIJIKILIMINIOIPIQIRISITIUIVI
WIXIYIZIllllllIIIII
<guin>
:= -
<espacio>
:= el carcter 32 del ANS de la tabla 850
<parntesis abierto
:= (
<parntesis cerrado
:= )
<corchete abierto
:= [
<corchete cerrado
:= ]
<punto>
:= .
IV-3
2.
<coma>
:= ,
<dgito>
:= 1 I 2 I 3 I 4 I 5 I 6 I 7 I 8 I 9 I 0
Con letras y espacios se pueden formar los identificadores:

<identificador>
:= <letra en espaol> {<continuacin>}

I
<continuacin>
[<Ietra en espaol> {<continuacin}]
:= [<guin o espacio] <letra en espaol>

1 [<guin o espacio>] <dgito>
<guin o espacio
4.
:= <guin> I <espacio>
Con el punto y los identificadores se definen cannpos:

<campo>
:= <identificador>.<identificador>
donde el primer identificador es el acrnimo de la EC a que pertence, y segundo el

nombre del campo. En caso de tratarse de un grafo, se hace referencia a la tabla
horizontal en que se puede transformar.
5.
Con el punto y los identificadores tambin se definen los arcos de entrada sobre los
vrtices y los de salida:
o r c o de entrada>
:= <identificador>.<identificador>.in.<identificador>
o r c o de entrada>
:= <identifcador>.<identificador>.out.<identificador>
donde el primer identificador es el acrnimo del grafo, el segundo el nombre del tipo
de arco y, el ltimo, el nombre del tipo de vrtice.
6.
A partir de los campos, de los arcos de entrada y de los arcos de salida sobre los
vrtices, se pueden describir los componentes de las proyecciones ordenadas:
<componente >
7.
Utilizando la coma y los componentes, se pueden definir proyecciones ordenadas:

<proyeccin ordenada>
8.
:= <campo> I o r c o de entrada> I o r c o de salida>
:= <componente> [{, <componente>}]
Los operadores de unin e interseccin, los parntesis y los identificadores se

combinan para definir matrices:
<matriz>
:= <matriz> unin <matriz> I (<matriz>)

I <proyeccin ordenada>
9.
A partir de las matrices y del operador de inclusin, se pueden obtener expresiones
IV-4
lgicas que describen formalmente las reglas de consistencia:

<expresin lgica>
:= <matriz> s included in <matriz>
iv. el axioma (Afc) es <expresin lgica>
IV-5
ANEXO V. EL ESQUEMA DE REFERENCIA

EN LBIR
Anexo V. El esquema de referencia de LBIR
V EL ESQUEMA DE REFERENCIA EN LBIR

A continuacin se muestra, en LBIR, el esquema de conceptualizacin que se propone como
referencia en el mtodo de conceptualizacin propuesto en el presente trabajo:
modal [Esquema 5]
/*aqui aparecern las definiciones de los EE.CC y de las reglas de verificacin, que se
vern a continuacin*/
define table horizontal [Glosario de trminos] as GT
define f'ield Nombre
begin
type term;
repeated no;
multiplicity (1,1);
end field ;
define field Descripcin
begin
type descripton;
repeated no;
multiplicity (1,1);
end field;
begin
placed in initial;
main field Nombre;
end table;
define table horizontal [Tabla de trminos a importar] as TTI

define field [Nombre del trmino en el origen] as NR
begin
type term;
repeated no;
multiplicity (1,1) ;
end field;
define field [Nombre de la ontologa] as NO
begin
type term;
repeated yes;
end field;
define field [Nombre del servidor] as NS
begin
type term;
repeated yes;
end field;
define field [Nombre del trmino en el destino] as NT
begin
type term;
repeated no;
multiplicity (1,1);
end field;
V-3
begin
placed in nitial;
main field NR;
end table;
define graph [rbol de clasificacin de conceptos] as ACC
define are [Subclase de] as S;
define are [Subclase en una particin exhaustiva] as SPE;
define are [Subclase en una particin disjunta] as SPD;
begin
type term;
in : multiplieity (0,N) S,
multiplieity (0,N) SPD;
out: multiplicity (0,N) S,
multiplieity (0,N) SPD;
end node;
begin
placed in [Glosario de trminos];
end graph;
define graph [Diagrama de relaciones] as DR
define are [Origen] as O;
define are [Destino] as D;
begin
type term;
in: multiplieity (0,N) D;
out: multiplicity (0,N) O;
end node;
define node Relacin as R
begin
type term;
in: multiplicity (1,1) O;
out: multiplicity (1,1) D;
end node;
begin
placed in ACC;
end graph;
define table horizontal [Diccionario de conceptos] as DC
define field [Nombre del concepto] as NC
begin
type term;
repeated no;
multiplicity (1,1);
end field;
define field Sinnimos as S
begin
type term;
repeated no;
V-4
multplicity (0,N);
end field ;
define field Abreviaturas as A
begin
type term;
repeated no;
multipiicity (0,N);
end field;
define field Instancias as I
begin
type term;
repeated yes;
multipiicity (0,N);
end field;
define field [Atributos de clase] asAC
begin
type term;
repeated yes;
multipiicity (0,N);
end field;
define field [Atributos de instancia] as Al
begin
type term;
repeated yes;
multipiicity (0,N);
end field;
define field Relaciones as R
begin
type term;
repeated yes;
multipiicity (0,N);
end field;
begin
placed in DR;
main field [Nombre del concepto];
end table;
define table vertical [Tabla de relaciones] as TR
define field [Nombre de la relacin] as NR
begin
type term;
repeated yes;
multipiicity (1,1);
end field;
define field [Concepto origen] as CO
begin
type term;
repeated yes;
multipiicity (1,1);
end field;
define field [Cardinalidad del concepto origen] as CCO
begin
V-5
type cardinality;
repeated yes;
multiplicity(1,1);
end field;
define field [Concepto destino] as CD
begin
type term;
repeated yes;
multiplicity (1,1);
endfieid;
define field [Propiedades matemticas] as PM
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field [Relacin inversa] as Rl
begin
type term;
repeated yes;
multiplicity (0,1);
end field;
define field [Referencias] as R
begin
type text;
repeated yes;
multiplicity (0,1);
end field;
begin
placed in DC;
main field NR, CO, CD;
end table;
define table vertical [Tablas de atributos de instancia] as TAI
define field [Nombre del atributo] as NA
begin
type term;
repeated yes;
multiplicity (1,1);
end field;
define field [Concepto] as C
begin
type term;
repeated yes;
multiplicity (1,1);
end field;
define field [Tipo de valor] as TV
begin
type text;
repeated yes;
multiplicity (1,1);
end field;
V-6
define field [Unidad de medida] as UM

begin
type arithmeticexp;
repeated yes;
multiplicity (0,1);
end field;
define field Precisin as P
begin
type arithmeticexp;
repeated yes;
multipiicity (0,1);
end field;
define field [Intervalo de valores] as IV
begin
type interval;
repeated yes;
multipiicity (0,1);
end field;
define field [Valor por defecto] as VD
begin
type aritfimeticexp;
repeated yes;
multipiicity (0,1);
end field;
define field Cardinalidad as C
begin
type cardinality;
repeated yes;
multiplicity (1,1);
end field;
define field [Deducido de los atributos de instancia] as DAI
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field [Deducido de los atributos de clase] as DAC
begin
type term;
repeated yes;
multipiicity (0,N);
end field;
define field [Deducidos de las constantes] as DC
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field Frmulas as F
begin
type term;
repeated no;
V-7
multplicity (0,N);
end field;
define field [Para deducir] as PD
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field Referencias as R
begin
type text;
repeated yes;
multiplicity (0,1);
end field;
begin
placed in DC;
main field [Nombre del atributo], Concepto;
end table;
define table vertical [Tablas de atributos de clase] as TAC
define field [Nombre del atributo] as NA
begin
type term;
repeated yes;
multiplicity (1,1);
end field;
begin
type term;
repeated yes;
multiplicity (1,1);
end field;
define field [Tipo de valor] as TV
begin
type text;
repeated yes;
multiplicity (1,1);
end field;
define field [Unidad de medida] as UM
begin
type arithmeticexp;
repeated yes;
multiplicity (0,1);
end field;
begin
type arithmeticexp;
repeated yes;
multiplicity (0,1);
end field;
define field Cardinalidad as C
begin
V-8
type cardinality;
repeated yes;
multiplicity (1,1);
end feld;
define feld [Para deducir] as PD
begin
type term;
repeated yes;
multiplicity (0,N);
end feld;
defne feld Referencias as R
begin
type text;
repeated yes;
multiplicity (0,1);
end feld;
begin
placed in DC;
main feld [Nombre del atributo], Concepto;
end table;
defne table horizontal [Tabla de constantes] as TC
defne feld [Nombre de la constante] as NC
begin
type term;
repeated no;
multiplicity (1,1);
end feld;
defne feld [Tipo de valor] as TV
begin
type term;
repeated yes;
multiplicity (1,1);
end feld;
defne feld Valor as V
begin
type arithmeticexp;
repeated yes;
multiplicity (1,1);
end feld;
defne feld [Unidad de medida] as UM
begin
type arithmeticexp;
repeated yes;
multiplicity (1,1);
end feld;
defne feld [Para inferir] as Pl
begin
type term;
repeated yes;
multiplicity (0,N);
end feld;
defne feld Referencias as R
V-9
begin
type text;
repeated yes;
multiplicity (0,1);
end field;
begin
placed n DC;
main field [Nombre de la constante];
end table;
define table vertical [Tablas de axiomas lgicos] as TAL
define field [Nombre del axioma] as NA
begin
type term;
repeated no;
multiplicity (1,1);
end field ;
define field Descripcin as D
begin
type description;
repeated yes;
multiplicity (1,1);
end field;
define field [Concepto descrito] as CD
begin
type term;
repeated yes;
multiplicity (1,1);
end field;
define field [Conceptos referidos] as CR
begin
type term;
repeated yes;
multiplicity (O, n);
end field;
define field [Atributos referidos] as AR
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field [Relaciones referidas] as RR
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field [Variables] as V
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
V-10
define field [Constantes referidas] as CS

begin
type term;
repeated yes;
multiplicity (0,N);
end feld;
define field Expresin as E
begin
type logicalexp;
repeated no;
multiplicity (1,1);
end field;
begin
type text;
repeated yes;
multiplicity (0,1);
end field;
begin
placed in TAC;
main field [Nombre del axioma];
end table;
define table vertical [Tablas de frmulas] as TF
define field [Nombre de la frmula] as NF
begin
type term;
repeated yes;
multiplicity (1,1);
end field;
define field Concepto as C
begin
type term;
repeated yes;
multiplicity (1,1);
end field;
define field [Atributo inferido] as Al
begin
type term;
repeated no;
multiplicity (1,1);
end field;
define field Frmula as F
begin
type logicalexp;
repeated no;
multiplicity (1,1);
end field;
define field Descripcin as D
begin
type description;
repeated no;
V-11
multiplicity (1,1);
end field;
define field [Atributos bsicos] as AB
begin
type term;
repeated yes;
multiplicity (1,N);
end field;
define field Constantes as C
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
begin
type artithmeticexp;
repeated yes;
multiplicity (0,1);
end field;
define field Restricciones as RT
begin
type logicalexp;
repeated yes;
multiplicity (0,1);
end field;
begin
type text;
repeated yes;
multiplicity (0,1);
end field;
begin
placed n TC;
main field [Nombre de la frmula], Concepto;
end table;
define graph [rboles de clasificacin de atributos] as AC
define are [Se utiliza en] as SE;
define are Obtiene as O;
define node Constante as C
begin
type term;
in:;
out: multiplicity (0,N) SE;
end node;
define node [Atributo de clase] as AC
begin
type term;
in:;
end node;
V-12
define node [Atributo de instancia] as Al

begin
type term;
in: multiplicity (0,N) O;
end node;
define node Frmula as F
begin
type term,
in : multiplicity (0,N) SE;
out: multiplicity (1,1) O;
end node;
begin
placed in TF;
end graph;
define table horizontal [Tabla de concepto-atributo de clase-valor] as TCV

begin
type term;
repeated no;
multiplicity (1,1);
end field;
define field Atributo de clase as AC
begin
type term;
repeated yes;
multiplicity (0,N);
end field;
define field Valoras V
begin
type text;
repeated yes;
multiplicity (1,N);
associated Atributos;
end field;
begin
placed in TAI;
main field C;
end table;
define table horizontal [Tabla de instancias] as TI
define field [Nombre de la instancia] as NI
begin
type term;
repeated no;
multiplicity (1,1);
end field;
define field Atributo as A
begin
type term;
repeated yes;
multiplicity (0,N);
end field ;
define field Relacin as R
begin
type term;
repeated yes;
V-13
multiplicity (0,N);
end field;
define field Valor as V
begin
type term;
repeated yes;
multiplicity (0,N);
associated Atributo, Relacin
end field
define consistency [Regla GT-1]

descrlption "Cualquier nombre de un trmino del glosario debe estar en la tabla de
constantes, o en el diccionario de datos en uno de los siguientes campos: nombre del
concepto, instancias, atributos de clase, atributos de instancia, relaciones binarias."
begin
GT. nombre is included in
(DC.NC unin
DC.Ai unin
DC.AC unin
DC.R unin
TC.NC)
end consistency
define consistency [Regla TTI-1]
descrlption "Nombre del trmino en el origen El nombre de cada
aparecer en, al menos, uno de los siguientes campos:
a) concepto destino de una tabla de relaciones binarias.
trmino debe
b) relacin inversa de una tabla de relaciones binarias.

c) tipo de valor de una tabla de atributo de clase, de atributo de instancia, o de
constantes (todava no se puede expresar de manera formal porque el trmino puede
ser una subcadena del tipo de valor, por ejemplo, si el tipo de valor es cantidad de
masa /cantidad de volumen).
d) unidad de medida de una tabla de atributo de clase, de atributo de instancia o de
constantes (todava no se puede expresar de manera formal porque el trmino puede
ser una subcadena dentro de la unidad de medida).
e) Relacin, atributo, constante, instancia o concepto referido en una tabla de axiomas
lgicos.
begin
TTI.NTis included in
(TR.CD unin TR.RI unin TAC.TV
unin TAL.CR unin TALAR unin
TAL.RR unin TAL.Vunin
TAL.CS unin TAL.IR
end consistency
define consistency [Regla ACC-1_1]
descrlption "Cualquier trmino que aparezca en un nudo 'concepto' del que sale un
arco 'subclase de' tiene que aparecer en el campo 'nombre' del glosario de trminos"
begin
ACC.S.out.Concepto is included in
GT.Nombre
end consistency
V-14

description "Cualquier trmino que aparezca en un nudo 'concepto' al que entra un
arco 'subclase de' tiene que aparecer en el campo 'nombre' del glosario de trminos"
begin
ACC.S.in.Concepto is includedin GT.Nombre
end consistency
arco 'subclase en una particin exhaustiva' tiene que aparecer en el campo 'nombre'
del glosario de trminos"
begin
ACC.SPE.out.Concepto is included in GT.Nombre
end consistency
arco 'subclase en una particin exhaustiva' tiene que aparecer en el campo 'nombre'
del glosario de trminos"
begin
ACC.SPE.in.Concepto is included in GT.Nombre
end consistency
arco 'subclase en una particin disjunta' tiene que aparecer en el campo 'nombre' del
glosario de trminos"
begin
ACC.SPD.out.Concepto is included in GT.Nombre
end consistency
arco 'subclase en una particin disjunta' tiene que aparecer en el campo 'nombre' del
glosario de trminos"
begin
ACC.SPD.in.Concepto is included in GT.Nombre
end consistency
define consistency [Regla ACC-2_ 1]
begin
end consistency
begin
ACC.S.in.Concepto is included in DC.NC
end consistency
arco 'sublcase en una particin exhaustiva' tiene que aparecer en el campo 'nombre del
concepto' del diccionario de conceptos"
begin
V-15
ACC.SPE.outConcepto is includedin DC.NC

end consistency
arco 'subclase en una particin exhaustiva' tiene que aparecer en el campo 'nombre del
begin
ACC.SPE.in.Concepto is included in DC.NC
end consistency
arco 'subclase en una particin disjunta' tiene que aparecer en el campo 'nombre del
begin
ACC.SPD.out.Concepto is included in DC.NC
end consistency
arco 'subclase en una particin disjunta' tiene que aparecer en el campo 'nombre del
begin
ACC.SPD.in.Concepto is included in DC.NC
end consistency
define consistency [Regla DR-1]
description "El origen de una relacin debe estar bien en el rbol de clasificacin de
conceptos bien en la lista de trminos a importar. La razn por la que un concepto
origen puede ser un trmino importado es la siguiente: toda relacin tendr una
inversa, y puede haber conceptos del diagrama que no estn en la antologa, por
consiguiente, estos conceptos importados sern destino de alguna relacin, pero origen
de su inversa."
begin
DR. O. in. R is included in
A ce. SPE. out. Concepto unin
ACC.SPD.out.Concepto
end consistency
define consistency [Regia DR-2J
description "El destino de una relacin debe estar bien en el rbol de clasificacin de
conceptos, bien en la lista de trminos a importar, pues el concepto destino puede, o
no, pertenecer a la ontologa."
begin
DR.D.out.R is included in
ACC. S. in. Concepto unin
ACC.SPE.outConcepto unin
ACC.SPD.out.Concepto unin
TTI.NT
end consistency
define consistency [Regla DC-1]
Anlisis y diseo de alto nivel del entorno de diseo de oncologas
V-16
description "El nombre del concepto tiene que ser un nudo del rbol de clasificacin
de conceptos, pues el diccionario de conceptos muestra los detalles de los conceptos
begin
DC.NC is included in
A ce. S. out. Concepto unin
A ce. SPD. out Concepto
end consistency
description "Todas las instancias tienen que estar definidas en la tabla de instancias."
begin
DC. Instancias is included in TI. NI
end consistency
description "Todas las instancias tienen que estar definidas en el glosario de
trminos."
begin
DC.Instancias is included in GT.Nombre
end consistency
description "Todos los atributos de clase deben estar definidos en el glosario de
trminos."
begin
DC.AC is included in GT.Nombre
end consistency
description 'Todos los atributos de clase que estn en el campo 'atributos de clase' de
un concepto C del diccionario de conceptos tienen que aparecer en el campo 'Nombre
del atributo' y el concepto C en el campo 'concepto' de alguna tabla de atributos de
clase."
begin
DC.AC, DC.NC is included in TACNA, TAC.C
end consistency
description "Todos los atributos de instancia deben estar definidos en el glosario de
trminos."
begin
DC.AI is included in GT.Nombre
end consistency
description "Todos los atributos de instancia que estn en el campo 'atributos de
instancia'de un concepto C del diccionario de conceptos tienen que aparecer en el
campo 'Nombre del atributo' y el concepto C en el campo 'concepto' de alguna tabla de
atributos de instancia."
begin
DC.AI, DC.NC is included in TAI.NA, TAI.C
end consistency
define consistency [Regla-DC-8]
V-17
description "Todas las relaciones que estn en el campo 'relaciones' de un concepto C

del diccionario de conceptos tienen que aparecer en el diagrama de relaciones binarias
siendo el concepto C el origen de la relacin"
begin
DC.NC, DC.R is included in DR.O.out.Concepto, DR.O.in.Relacin
end consistency
description "Todas las relaciones que estn en el campo 'relaciones' de un concepto C
del diccionario de conceptos tienen que aparecer en el campo 'Nombre de la relacin' y
el concepto C en el campo 'concepto origen' de alguna tabla de relaciones binaras"
begin
DC.R, DC.NC is included in TR.NR, TR.CO
end consistency
description "No puede haber ningn atributo de clase que no tome valores en algn
concepto"
begin
DC.AC is included in TCV.AC
end consistency
define consistency [Regla TR-4]
description "Si en la relacin R que se est definiendo se especifica que el concepto
origen es Co, entonces, en el diccionario de conceptos, aparecer R como una de las
relaciones correspondientes al concepto Cg"
begin
TR.NR, TR.CO is included in DC.R, DC.NC
end consistency
define consistency [Regla TAI-1]
description "Si un atributo As aparece en el campo "deducido de los atributos de
instancia" de la tabla de otro atributo
Ai, entonces A^ deber aparecer en el campo "para deducir" de la tabla de Az."
begin
TAINA, TAl.DAlis included in TAI.PD, TAI.NA
end consistency
description "Si un atributo A2 aparece en el campo "para deducir" de la tabla de otro
atributo A^, entonces Ai deber aparecer en el campo "deducido de los atributos de
instancia" de la tabla de A2."
begin
TAI.NA, TAI.PD is included in TAI.DAI, TAI.NA
end consistency
description "Si en el atributo A que se est definiendo se especifica que el concepto
es C, entonces, en el diccionario de conceptos, aparecer A como uno de los atributos
de clase correspondientes al concepto C."
begin
TACNA, TAC.C is included in
DC.NC, DC.AI
end consistency
description "Si una constante Cons aparece en el campo "deducido de las constantes"
de la tabla de un atributo de instancia A, entonces el atributo A deber aparecer en el
campo "para inferir" de la tabla de Cons"
begin
V-18
TAI.NA. TAI.DC is included in TC.NC, TC.PI

end consistency
define consistency [Regla TAIS]
description "Cualquier frmula que haya en el campo "frmulas" deber estar definida
en una tabla de frmulas. Adems, el atributo inferido que aparece en la tabla de la
frmula ha de ser el atributo que se ha definido en la tabla de atributos."
begin
TAI.NA, TAl.F is included in TF.AI, TF.F
end consistency
define consistency [Regla TAC-1]
"Si en el atributo A que se est definiendo se especifica que el concepto es C,
entonces, en el diccionario de conceptos, aparecer A como uno de los atributos de
clase correspondientes al concepto C."
begin
TACNA, TAC.C is included in DC.NC, DC.AC
end consistency
define consistency [Regla TAC-4] "Si un atributo de instancia A aparece en el campo
'para deducir' de la tabla de un atributo de clase A^, entonces Ac deber aparecer en el
campo "deducido de los atributos de clase" de la tabla de A^
begin.
TACNA, TACPDis included in TAI.DAC, TAI.NA
end consistency
define consistency [Regla TCI]
description "El nombre de cualquier constante debe estar en el glosario de trminos".
begin
TCNC is included in GT.N
end consistency
define consistency [Regla TC4]
description "Si un atributo de instancia A est en el campo "para inferir" de una
constante C, entonces la C tiene que estar en el campo "deducido de las constantes"
del atributo A."
begin
TCNC TCPI is included in TAI.DC TAI.NA
end consistency
define consistency [Regla TAL-9]
description "El concepto descrito deber estar en el diccionario de conceptos. "
begin
TAL.CD is included in DCNC
end consistency
description "Los conceptos referidos debern estar en el diccionario de conceptos o
en la tabla de trminos a importar."
begin
TALCR is included in DCNC unin TTI.NT
end consistency
description "Cualquier atributo del campo "atributos referidos" debe estar definido en
una tabla de atributos de instancia o de atributos de clase, o bien en la tabla de
trminos a importar."
begin
TAL.AR is included in TAI.NA unin TACNA unin TTI.NT
end consistency
V-19

description "Cualquier relacin de las que haya en el campo "relaciones referidas"
debe estar definida en una tabla de relaciones binarias, o bien en la tabla de trminos a
importar"
begin
TALRR is included in TR.NR unin TTI.NT
end consistency
description "Cualquier constante de las que tiaya en el campo "constantes referidas"
debe estar definida en la tabla de constantes, o bien en la tabla de trminos a
importar."
begin
TALCS is included in TC.NC unin TTI.NT
end consistency
description "Cualquier instancia de las que haya en el campo "instancias referidas"
debe estar definida en el campo "instancias" del diccionario de conceptos, o bien en la
tabla de trminos a importar."
begin
TAL.IR is includd in DC.I unin TTI.NT
end consistency
define consistency [Regla TF-4]
description "Si A es el atributo inferido en la frmula F, entonces F tiene que aparecer
en el campo "frmula" de la tabla de A."
TF.AI, TF.NF is included in TAI.NA, TAI.F
description "Si A es el atributo inferido en la frmula F, entonces tiene que haber un
arco "obtiene" en el rbol de clasificacin de atributos desde F hasta A."
begin
TF.AI, TF.NF is included in ACA.Obtiene.outF, ACA.Obtiene.in.AI
description "El concepto del campo "concepto" tiene que aparecer en el diccionario de
conceptos."
begin
TF.C is included in DC.NC
end consistency
description "SiA^ es un atributo bsico de una frmula y Anf el atributo inferido,
entonces A^ tiene que aparecer bien en el campo 'deducido de los atributos de
instancia' de la tabla de atributos de instancia Ainf, bien en el campo 'deducido de los
atributos de clase' de la tabla de atributos de instancia de Ainf."
begin
TF.AB, TF.AI is included in TAI.NA, TAl.DAl unin TAI.NA, TAI.DAC
end consistency
description "Tiene que haber un arco "se utiliza en" desde cada atributo bsico hasta
la frmula en el rbol de clasificacin de atributos."
begin
TF.AB, TF.NF is included in ACA.SE.out.AI, ACA.SE.in.F
end consistency
define consistency [Regia TF-9]
description "Todas las constantes que haya en este campo tienen que estar definidas
en la tabla de constantes. "
V-20
begin
TF.Constantes is included in TC.NC
end consistency
description "Tiene que haber un arco "se utiliza en" desde cualquier constante del
campo "constantes" hasta la frmula en el rbol de clasificacin de atributos."
begin
TF.C, TF.NFis included in ACA.SE.out.C, ACA.SE.in.F
end consistency
define consistency [fêgla ACA-2]
description "Si un arco "se utiliza en" relaciona un atributo (de clase o de instancia) A
con una frmula F, entonces A debe aparecer en el campo "atributos bsicos" de la
tabla de la frmula F."
begin
ACA.SE.out.AI, ACA.SE.in.F is included in TF.AB, TF.F
end consistency
define consistency [Regla ACA-3]
description "Si un arco "se utiliza en" relaciona una constante C con una frmula F,
entonces C debe aparecer en el campo "constantes" de la tabla de la frmula F."
begin
ACA.SE.out.C, ACA.SE.in.F is included in TF.C, TF.F
end consistency
define consistency [Regla ACA-4]
description "Si un arco del modelo "obtiene" relaciona una frmula F con un atributo
de instancia A, entonces A debe aparecer en el campo "atributo inferido" de la tabla de
la frmula F"
begin
ACA.O.out.F, ACA.O.in.AI is included in TF.F, TF.AI
end consistency
define consistency [Regla TCV-1]
Nombre del concepto
begin
description "Cualquier concepto debe aparecer en el campo concepto del diccionario
de conceptos"
TCV.NC is included in DC.NC
end consistency
define consistency [Regla TI-1]
description "Cualquier instancia debe aparecer en el campo instancias del diccionario
de conceptos."
begin
TI.NI is included in DC.I
end consistency
begin
/*Ficha de descripcin general*/

Nombre, [Fecha y hora de creacin]. Autores, Descripcin;
end [Esquema 5].
V-21
ANEXO Vt. PATRONES DE TRADUCCIN

DEL ESQUEMA DE REFERENCIA A
ONTOUNGUA
Anexo VI. Patrones de traduccin del esquema de referencia a Ontolingua
VI PATRONES DE TRADUCCIN DEL ESQUEMA DE

REFERENCIA A ONTOLINGUA
Los patrones aqu presentados estn probados con la construccin del mdulo generador de
Ontolingua que tiene ODE. Hay una descripcin para cada tipo de definicin, incluida la
cabecera. En la seccin 2.5 y en el anexo I hay una descripcin general de este lenguaje. Por
otra parte, los elementos de conceptualizacin rellenos que aparecen traducidos en los
ejemplos estn en el anexo III.
VI.1 GENERACIN DE LA CABECERA DE LA ONTOLOGA

EEI cdigo final empieza con una cabecera que tiene la siguiente forma:
#1 Wrten by user autor l#
;;; Date: fecha
(Define-Ontology antologa
(Frame-Ontology ontologasjwportadas)
(" documentacin")
:lo-Package
"ONTOLINGUA-USER")
(In-Ontology (Quote antologa)
Aparece en negrita Frame Ontology porque en todas las ontologas se va a importar. Ntese
que quien conceptualiza no tiene por qu saber que se va a utilizar vocabulario relacionado con
el paradigma basado en marcos. Los puntos y coma (";"), y los sostenidos ("#") acompaados
de barras verticales ("I") se utilizan para los comentarios. El resto de la informacin relevante es
el nombre de la ontologa, el hecho de que se importa la Frame Ontology, y la documentacin
en lenguaje natural describiendo el objetivo de la ontologa.
En la Tabla VI.1 se muestra cmo se obtiene la informacin correspondiente a las palabras
que aparecen en cursiva a partir del modelo conceptual de la ontologa a traducir. Salvo
aquellos nombres que aparecen entre comentarios o entre comillas, a los dems hay que
quitarles los acentos y transformar las enes en otros caracteres.
A modo de ejemplo, la cabecera generada a partir de la conceptualizacin presentada como
ejemplo en el anexo II, sera la siguiente:
#1 Wrten by user
Mariana Fernndez Lpez can la colaboracin y consejo de Asuncin
Gmez Prez. I#
;;; Date: 16 de mayo de 1996

VI-3
(Defne-OntologyChemical-Elements
(Frame-Ontology
Standard-Units
Standard-Dimensions
KIF-Numbers)
("Modeliza el dominio de los elementos qumicos. El objetivo de
esta antologa es utilizarla en la enseanza, la industria, etc. Esta
antologa se ha desarrollado dentro de proyecto METHONTOLOGY,
que tiene como objetivo establecer un mtodo para construir
antologas.
[Handbook, 84-85]
Handbook of Chemistry and Physcs. 65edicin. CRC-PRESS, INC. 1984-1985.
[Hidalgo, 84] Hidalgo, P. J. Curso breve de qumica: electroqumica
y corrosin. Ed. ECAI. 1984.
.lo-Package
"ONTOUNGUA-USER")
(In-Ontology (Quote Chemical-Elements)
IMPLEMENTACIN
CONCEPTUALIZACIN
Autor
Se obtiene del campo autor de la ficha de descripcin general
Fecha
Se obtiene del campo fecha de la ficha de descripcin general
Ontologa
Se obtiene del campo nombre de la ontologa de la ficha de

descripcin general
Ontologas_importadas
Se obtiene a partir de la tabla de trminos a importar
Documentacin
Se obtiene del campo descripcin de la ficha de descripcin

general
Tabla VI. 1. Relacin entre la cabecera de una ontologa en Ontolingua y los datos generales definidos una
ontologa siguiendo el esquema de referencia
VI.2 GENERACIN DE LAS CLASES

Para cada uno de los conceptos descritos en el diccionario de conceptos se generar una clase
que tendr el siguiente formato:
;;; concepta
(Define-Class concepto {7concepto)
"descripcin"
:def
[(and]^
[(Individual concepto)]
{(superclase 7concepto)f
[(Superclass-Of subclases)f
VI-4
[(Has-lnstance ^concepto instancias)]

[(Has-At-Most ? concepto atributo_o_relacin 1) f
(Has-One ? concepto atributo_o_relacin) T
(>= Value-Cardinalty ? concepto atributo_o_reiacin 0) 1^
(Has-Some "iconcepto atributo_o_relacin)]\)f
[:axiom-def]^
[(Exhaustive-Subclass-Partition concepto (Setof subclases-e)))f\
^%\^^0
[(Disjoint-Subclass-Parttion concepto (Setof subclases-disj))f [)]
[:class-slots
{{atributo_de_clase:valu valores)^'^^*
La forma de obtener la informacin correspondiente a las palabras que aparecen en cursiva en
este apartado dedicado a las clases est expresado en la Tabla VI.2.
IMPLEMENTACIN
CONCEPTUALIZACIN
Concepto
Se obtiene del campo "nombre del concepto" del diccionario de conceptos.
Descripcin
Es la descripcin que aparece en el glosario de trminos para el concepto que se est

traduciendo.
Subclases
Las subclases del concepto que aparecen en el rbol de clasificacin de conceptos
Instancias
Corresponde al campo instancias del "diccionario de conceptos" del concepto
Subclases-ex
Las subclases en la particin exhaustiva del concepto que aparece en el rbol de

clasificacin de conceptos
Subclases-dis
Las subclases en la particin disjunta del concepto que aparece en el rbol de

clasificacin de conceptos
Superclase
Una superclase del concepto en el rbol de clasificacin de conceptos
Atributo_o_relacin
Ser un elemento del campo atributos de clase, atributos de instancia, o relaciones

del "diccionario de conceptos" correspondiente al concepto
A tributo_de_clase
Se obtiene del campo atributo de clase de la tabla de concepto-atributo de clasevalor.
Valores
Se obtienen del campo valor de la tabla de concepto-atributo de clase-valor
Tabla VL2. Significado de los smbolos ms elementales en la descripcin de las clases en Ontolingua y
su procedencia del esquema de referencia
En la Tabla VI.3 aparecen explicadas las condiciones que se deben cumplir para que estas
estructuras aparezcan en la definicin de una determinada clase.
El siguiente ejemplo muestra la clase que se generara aplicando estas reglas al concepto
"elemento" del ejemplo del anexo II:
;;; Elemento
(Define-Class Elemento (?Elemento)
" Es una sustancia formada por tomos con el mismo nmero de
protones."
:def
(and
VI-5
(Superclass-Of Reactivo No-Reactivo)

(Has-One ? Nmero-Atmico Entero)
(Has-One ? Peso-Atmico Nmero-Real)
) ) )
NMERO DE
CONDICIN
EXPLICACIN
El concepto tiene instancias, atributos de clase, atributos de instancia o relaciones en su

entrada del diccionario de conceptos
El concepto no tiene superclases (la informacin se obtiene del rbol de clasificacin de

conceptos)
Se repite tantas veces esta estructura como superclases tenga el concepto. Por consiguiente, si
no tiene superclases, no aparece esta estructura. (La informacin se obtiene del rbol de
El concepto tiene subclases (la informacin se obtiene del rbol de clasificacin de conceptos)
El concepto tiene instancias en su entrada del diccionario de conceptos
La cardinalidad del atributo o relacin es (0, 1). La informacin se saca de las tablas de
atributos de instancia, de las tablas de atributos de clase o de las tablas de relaciones,
dependiendo de lo que sea atributo_p_relacin.
La cardinalidad del atributo o relacin es (1,1).
10
El concepto contiene una particin exhaustiva o una particin disjunta (la informacin se
obtiene del rbol de clasificacin de conceptos)
11
El concepto contiene una particin exhaustiva (la informacin se obtiene del rbol de
12
El concepto contiene una particin disjunta (la informacin se obtiene del rbol de
13
Se repite tantas veces como atributos de clase tomen valor en el concepto
14
Se tendr esta estructura si hay atributos de clase que toman valores en el concepto
Tabla VL3. Condiciones de las estructuras optativas y repetitivas en la definicin de las clases en
Ontolingua
VI.3 GENERACIN DE RELACIONES

Las relaciones se obtienen de: los atributos de instancia, los atributos de clase, y las relaciones
binarias en el esquema de referencia.
Vl.3.1 GENERACIN DE RELACIONES A PARTIR DE ATRIBUTOS DE

INSTANCIA
Para cada tabla de atributos de instancia que no represente un atributo deducido en una tabla
de frmulas hay que generar una relacin en Ontolingua que tenga el siguiente formato:
VI-6
; ; ; atributo_de_instancia
(Define-Relaton atributo_deJnstancia-concepto {Iconcepto 'tipo_de_valoi)
"descripcin"
.Del
(and
{concepto Iconcepto)
\tipo_de_valor ?tipo_de_valoi))
[:Constraints
(and
(>= 7<tipo_de_valor valor_mnimo_en_notacin_prefija>)
(=< ?<tpo_de_valor valor_mximo_en_notacin_prefija>))])
La existencia de la parte opcional de esta definicin depende de si se han definido el valor
mximo y el mnimo en el campo "intervalo de valores" de la tabla de atributos de instancia.
La forma de obtener la informacin correspondiente a las palabras que aparecen en cursiva
en este apartado dedicado a las relaciones est expresado en la Tabla VI.4.
IMPLEMENTACIN
CONCEPTUALIZACIN
Atribulo de instancia
Se obtiene del nombre del atributo en la tabla de atributos de instancia
Concepto
Es uno de los conceptos a los que pertence el atributo de instancia. Esta

informacin se encuentra en el diccionario de conceptos. Hay que hacer una
definicin por cada concepto al que pertenezca el atributo.
Tipo de valor
Se encuentra en el campo tipo de valor de la tabla del atributo de instancia.
Descripcin
Es la descripcin que aparece en el glosario de trminos para el atributo de

instancia
Valor mnimo y valor mximo Para componer estos datos, es necesario obtener tanto el valor mximo como el
mnimo del campo "intervalo de valores" de la tabla del atributo de instancia y
en notacin prefija
concatenarlos con el smbolo de multiplicar y con la "unidad de medida" que hay
en la misma tabla. El resultado de la operacin anterior hay que pasarlo, para cada
uno de los dos valores (mximo y nu'nimo), a KIF segn se muestra en el apartado
VI.7.
Tabla VL4. Significado de los smbolos ms elementales en la descripcin de las relaciones obtenidas a
partir de los atributos de instancia en Ontolingua y su procedencia del esquema de
referencia
A continuacin se muestra la traduccin del atributo de instancia "peso atmico":

; ; ; Peso-Atmico
(Define-Relation Peso-Atmico {"iPeso-Atmico 1 Cantidad-De-Masa)
" La masa relativa de un tomo de un elemento con respecto a la masa de la
duodcima pane del istopo carbono 12 [Hidalgo, 84]."
:Def
(and
{Peso-Atmicol ? Peso-Atmico)
{Cantidad-De-Masa ?Cantidad-De-Masa)))
VI-7
Vl.3.2 GENERACIN DE RELACIONES

ATRIBUTOS DE CLASE
PARTIR
DE
LOS
Tienen el siguiente formato:

; ; ; atributo_de_clase
(Define-Relation atributo_de_clase (Iconcepto
"descripcin"
:Def
(and
{concepto Iconcepto)
{tipo_de_valor ? tipo_de_ valoi)))
7tipo_de_valoi)
En la tabla Tabla VI.5 se explican los smbolos elementales
relacionados con la
conceptuaiizacin.
CONCEPTUALIZACIN
IMPLEMENTACIN
Atributo de clase
Se obtiene del nombre del atributo en la tabla de atributos de clase
Concepto
Es el concepto al que pertence el atributo de clase. Esta informacin se encuentra

en el diccionario de conceptos.
Tipo de valor
Se encuentra en el campo tipo de valor de la tabla del atributo de clase.
Descripcin
Es la descripcin que aparece en el glosario de trminos para el atributo de clase
Tabla VI.5.
Significado de los smbolos ms elementales en la descripcin de las relaciones obtenidas

a partir de los atributos de clase en Ontolingua y su procedencia del esquema de
referencia
Vl.3.3 GENERACIN DE RELACIONES

RELACIONES BINARIAS
PARTIR
DE
LAS
Se obtienen de las tablas de relaciones binarias. Tienen el siguiente formato:

; ; ; relacin
(Define-Relation relacin (?cp1 ?cp2)
"descripcin"
:Def
(and
{concepto_origen ?cp1)
{concepto_destino ?cp2)
{relacinjnversa ?cp2 ?cp1)))
En las relaciones obtenidas de esta manera, el concepto origen juega el mismo papel que el
concepto de los atributos, y el concepto destino el mismo que el tipo de valor.
En
la Tabla
VI.6
se
explican
los
smbolos
elementales
relacionados
con
la
conceptuaiizacin.
Mtodo flexible para la conceptuaiizacin de ontologas basado en meta-modelos
VI-8
IMPLEMENTACIN
CONCEPTUALIZACIN
Relacin
Se obtiene del nombre de la relacin en la tabla de relaciones binarias.
Descripcin
Es la descripcin que aparece en el glosario de trminos para la relacin
Concepto origen
Es el concepto origen de la relacin en la tabla de relaciones binarias.
Concepto destino
Es el concepto destino de la relacin en la tabla de relaciones binarias.
Relacin inversa
Es la relacin inversa que aparece en la tabla de relaciones binarias.
Tabla VI.6.
Significado de los smbolos ms elementales en la descripcin de las relaciones
obtenidas a partir de las relaciones binarias en Ontolingua y su procedencia del esquema de referencia
A continuacin se nnuestra la traduccin de la relacin "forma compuesto con":

; ; ; Forma-Compuesto-Con
(Define-Relation Forma-Compuesto-Con (?cp1 ?cp2)
" Un elemento puede reaccionar con otro para formar un compuesto"
:Def
(and
(Elemento ?cp1)
(Elemento ?cp2)
(Forma-Compuesto-Con ?cp2 ?cp1)))
\ri.4 GENERACIN DE AXIOMAS

Por cada uno de los axiomas que aparecen en las tablas de axiomas, se genera una definicin
como sta:
;;; axioma
(Define-Axiom axioma
expresin_lgica_en_KIF)))
El significado de los smbolos ms elementales se muestra en la Tabla VI.7.
VI-9
IMPLEMENTACIN
CONCEPTUALIZACIN
Axioma
"Nombre del axioma" obtenido de la tabla de axiomas lgicos que se est

traduciendo
Concepto
Aparece en el campo "concepto" de la tabla de axiomas lgicos que se est

traduciendo
Expresin_lgica_en_KIF
Es la traduccin a KIF del campo "expresin" de la tabla de axiomas lgicos

segn se muestra en el apartado VI.7. Antes de llevar a cabo esta traduccin, hay
que poner un smbolo de interrogacin cerrada ("?") delante de cada variable de
la expresin que aparezca en el campo "variables".
Atributo
Uno de los trminos del campo "atributos referidos" de la tabla de axiomas

lgicos que se est traduciendo
Relacin
Uno de los trminos del campo "relaciones" de la tabla de axiomas lgicos que se
est traduciendo
Tabla VI.7. Significado de los smbolos ms elementales en la descripcin de los axiomas en Ontolingua
y su procedencia del esquema de referencia
En la Tabla VI.8 se muestra el nmero de apariciones de las estructuras repetitivas.
NMERO DE
CONDICIN
EXPLICACIN
Se repite tantas veces como atributos referidos haya en la tabla de axiomas lgicos
correspondiente.
Se repite tantas veces como relaciones referidas haya en la tabla de axiomas lgicos
correspondiente.
Tabla VL8. Repeticiones en las definiciones de los axiomas lgicos en Ontolingua y su procedencia del
esquema de referencia
A continuacin se muestra la traduccin del axioma "alta electronegatividad de los no metales":

;;;
Alta-Electronegatividad-De-Los-No-Metales
(Define-Axiom
Alta-Electronegatividad-De-Los-No-Metales
(forall (7X7Y)
(=> (and (No-Metal 7X) (Entero ? Y)
(Electronegatividad 7X ? Y))
(>?Y0)))))
VI-10
VI.5 GENERACIN DE FUNCIONES

Las frmulas del esquema de referencia se pueden expresar como funciones. En
consecuencia, por cada una de las frmulas que aparecen en las tablas de frmulas, se genera
una definicin en Ontolingua como sta:
;;; njrmula
(define-functon njrmula (Iconcepto) :-> 7atributoJnferido
"descripcin"
:iff-def
(and
{concepto "> concepto)
{atributojnferido Iconcepto latributojnferido)
(exists {?atributos_bsicos)
(and
{{atributo_bsico Iconcepto atributojbsico)]^
{expresin_lgica_en_KIF)
{expresin_aritmtica_en_KIF)))))
E:n la Tabla VI.9 se muestra el nmero de apariciones de las estructuras repetitivas.
EXPLICACIN
NUMERO DE
CONDICIN
Se repite tantas veces como atributos.

Tabla VI.9. Repeticiones en las definiciones de los axiomas lgicos en Ontolingua
En la Tabla VI.10 aparece el significado de los smbolos ms elementales que hacen referencia
a la conceptualizacin.
IMPLEMENTACIN
CONCEPTUALIZACIN
N_frmula
"Nombre de \a frmula" obtenido de la tabla de frmulas que se est traduciendo
Concepto
Aparece en el campo "concepto" de la tabla de frmulas que se est traduciendo
Atributojnferido
Aparece en el campo "atributo inferido" de la tabla de frmulas que se est

traduciendo
Descripcin
"Descripcin" de la tabla de la frmula.
ExpresinJgica_en_KiF
Traduccin a KIF de las restricciones segn se muestra en el apartado VI.7
Expresin_aritmtica_en_KIF Traduccin, segn se muestra en el apartado VI.7, a KIF de la expresin que

aparece a la derecha del igual en el campo "frmula" de la tabla que se est
considerando. Antes de llevar a cabo esta transformacin es necesario poner una
interrogacin delante de cada trmino que aparece en la expresin.
Atributos bsicos
Cada uno de los trminos que pertenecen al campo "atributos bsicos" de la tabla
de frmulas que se est traduciendo.
Atributo bsico
Uno de los trminos que pertenecen al campo "atributos bsicos" de la tabla de

frmulas que se est traduciendo.
Tabla VI. 10. Significado de cada trmino elemental que aparece en la descripcin de las frmulas en
Ontolingua y su procedencia del esquema de referencia
VI-11
La siguiente funcin define la frmula de la densidad, a 20SC, de un elemento qumico

(densidad_a_20- = peso_atmico / volumen_atmico_a_20^:
(define-function densidad (7elemento) :-> "i densidad-A-20-C
"La densidad de un elemento es igual a su peso atmico dividido
entre su volumen atmico"
:iff-def
(and
(Elemento 1 Elemento)
{Densidad-A-20-C f Elemento 7Densidad-A-20-C)
(exists (7Peso-Atmico 7 Volumen-Atmico-A-20-C)
(and
{Peso-Atmico 7Elemento 7 Peso-Atmico)
(Volumen-Atmico-A-20-C 7 Elemento
7 Volumen-Atmico-A-20-C)
(= 7 Densidad-A-20-C (17 Peso-Atmico
7 Volumen-Atmico-A-20-C)))
VI.6 GENERACIN DE INSTANCIAS

Las instancias en Ontolingua se obtienen bien de la tabla de instancias, bien de las constantes
descritas en la tabla de constantes.
Vl.6.1 GENERACIN DE INSTANCIAS A PARTIR DE LA TABLA DE

INSTANCIAS
Por cada una de las instancias que aparecen en la tabla de instancias, se genera una definicin
como sta:
; ; ; instancia
(Define-lnstance instancia{concepto)
"descripcin"
[:Axioin-def
[(and]^ {{atributo_deJnstancia_o_relacin instancia valoi)f[)]^)
En la Tabla Vi.11 se muestra el significado de los trminos elementales de este apartado (los
que estn en cursiva).
IMPLEMENTACIN
CONCEPTUALIZACIN
Instancia
"Nombre de la instancia" en la tabla de instancias
Concepto
Concepto al que pertenece la instancia. Esto se comprueba consultando el campo

"instancias" del diccionario de conceptos
Descripcin
Descripcin que aparece de la instancia en en el glosario de trminos
Atributo_de_instancia_o_
relacin
Atributo que aparece en el campo "atributos" en la tabla de instancias, o relacin que

aparece en el campo "relaciones"
Valor
Expresin KIF, obtenida segn se muestra en el apartado VI.7, a partir del valor del
atributo en la instancia y su unidad de medida. Este ltimo dato se obtiene de la tabla de
atributos de instancia del atributo, mientras que los dems se encuentran en la tabla de
instancias.
Tabla VL11.
Significado de los trminos elementales mencionados en la descripcin de las
VI-12
instancias obtenidas a partir de la tabla de instancias en Ontolingua y su procedencia

del esquema de referencia
En la Tabla VI.12 se muestra el nmero de apariciones de las estructuras repetitivas y las
condiciones de las estructuras optativas.
NMERO DE
CONDICIN
EXPLICACIN
Aparece si hay atributos que tomen valores en la instancia o si hay relaciones en que la
instancia sea origen.
Se repite tantas veces como atributos tomen valores en la instancia ms tantas veces
como se origen la instancia en las relaciones binarias.
Tabla VI. 12. Repeticiones y opciones en las definiciones de las instancias en Ontolingua
A continuacin se presenta la definicin de la instancia "oro":

;;;
Oro
(Define-lnstance Oro(Tercera-Serie-De-Transicin)
"(Del latn aurum, aurora brillante), Au; nmero atmico 79; peso
atmico 196,97; valencias 1y3. Cuando est en cantidad, es de color
amarillo metlico; pero cuando se divide en hilos finos puede ser
negro, rub o prpura. Es un metal blando y normalmente se puede
estirar. Es buen conductor del calor y de la electricidad, y no le afecta
el aire ni la mayor parte de los reactivos. Se pueden obtener
fcilmente hilos y lminas. [Handbook, 84-85]."
:Axiom-def
(and {Nmero-Atmico Oro 17)
{Peso-Atmico Oro {* 35.453 UMA))
{Forma-Compuesto-Con Oro Sodio)))
Vl.6.2 GENERACIN
CONSTANTES
DE
INSTANCIAS
PARTIR
DE
LAS
Por cada una de las instancias que aparecen en la tabla de constantes, se genera una
definicin como sta:
; ; ; constante
{Deime-lnstance constante{tipo_de_valoi)
"descripcirf'
:= valoi)
En la Tabla VI.13 se muestra el significado de los trminos elementales de este apartado (ios
que estn en cursiva).
VI-13
CONCEPTUALIZACIN
IMPLEMENTACIN
Constante
"Nombre de la constante" en la tabla de constantes
Tipo_de_valor
Contenido del campo tipo de valor en la entrada de la constante.
Descripcin
Descripcin que aparece de la constante en el glosario de trminos
Valor
Expresin KIF, obtenida segn se muestra en el apartado VI.7, a partir del valor de
la constante y su unidad de medida.
Tabla VI.13.
Significado de los trminos elementales que aparecen en la descripcin de las instancias
obtenidas a partir de las constantes en Ontolingua y su procedencia del esquema de referencia
La siguiente definicin es la de la constante "temperatura estndar":

; ; ; Temperatura-Estndar
(Define-lnstance Temperatura-Estndar (Cantidad-De-Temperatura)
"Temperatura a la que se llevan a cabo muchos experimentos en el
laboratorio."
:= (* 25 Grado-Centgrado))
VI.7 TRADUCCIN DE LAS EXPRESIONES

La Tabla VI.14 muestra cmo se traduce a KIF una expresin en notacin infija de las que
pueden aparecer en la conceptualizacin. En la columna de la izquierda de la tabla aparece la
gramtica que describe las expresiones en notacin infija, siendo el smbolo inicial
"<expresin>". En la columna de la derecha los componentes sintcticos anotados con
atributos para almacenar informacin del proceso. Estos atributos sern: prefija, que contendr
la expresin prefija asociada a un componente sintctico; y valorjxico,
que se utilizar en
componentes sintcticos que van encerrados entre " " y " " y que pueden seguir una de las
siguientes gramticas:
1. Si es trmino, la gramtica <Ti, Ni, Pi, Ai>, donde:
i. Se tiene
T=
{a,b,c,
d, e, f, g, h, i, j, /f, /, m, n, , o, p, q, r, s, t, u, v, w, x, y, z, A, B,
C, D, E, F, G, H, I, J, K, L, M, N. O, P, Q, R, S, T, U, V, W, X, Y, Z, , ,
, , , , , , , , , , O, 1, 2, 3, 4, 5, 6, 7, 8, 9, el carcter 32 del
ANS}
ii. N\ = {<letra en espaol>, <dgito>, <espacio>, <identificador>, <resto id>}
iii. Las reglas de P\ son las siguientes:
<letra en espaob
:=
alblcldlelflglhliljlkllllllmlnl
ylzIAIBIC
IDIEIFIGIHIIIJIKILIMINIOIPIQI
VI-14
RISITIUIVIWIXI
YlZIlllll
I I I I II
<dgito>
1I2I3I4I5I6I7I8I9I0
<espacio>
el carcter 32 del ANS
<letra o d g i t o
<identificador>
<letra en espaol> I <letra en espaol> <resto

id>
<resto id>
<letra o dgito> <espacio> <resto id> I

<letra o dgito> <resto id>
iv. El axioma (At) es <identificador>

Adems, de cumplir las reglas de la gramtica, un identificador subrayado no puede ser
ninguno de ios siguientes smbolos: forall, exists, andni or.
2. Si es un nmero, seguir esta otra gramtica la gramtica
<TNU, NNU, PNU, ANU>,
donde:
i. Se tiene
TNU = {1,2, 3, 4, 5,
6,7,8,9,0}
ii. A/tMu = {<nmero>, <natural>, <dgito>}

iii. Las reglas de PNU son las siguientes:
<nmero>
:=
<natural> I <natural>.<naturai>
<natural>
:=
<dgito> I <dgito> <natural>
<dgito>
:=
1I2I3I4I5I6I7I8I9I0
iv. El axioma es <nmero>

El valor lxico de una expresin es la tira de caracteres que forman dicha expresin. Por
ejemplo, el valor lxico de la expresin "2 * 3" es precisamente "2 * 3", aunque su valor
aritmtico sea 6. Los smbolos no terminales de la parte izquierda de las reglas estn anotados
con nmeros para poder distinguirlos en las acciones cuando se repiten en la misma regla.
VI-15
Regla sintctica
<expresin> := <expr_log,l>
<expresin> := <expr_arit,l>
<expr_log> := <cuantificador, 1> (<parmetros, 1>) <expr_bool, 1>
<cuantificador> := exists
<cuantificador> := forall
<parmetros> := <parmetro, 1>, <parmetros, 1>
<parmetro> := <expr_arit, 1>

<parmetro> := trmino, 1
<expr_implic> := <expr_implic,l> <op_implic,l> <comb_log,l>
<op_implic> := ->
<op_!mplic> := <->
<expr_log> := <comb_log,l>
<comb_log> := <comb_log,l> or <tnii_log,l>
<comb_log> := <trm_log,l>
<trm_log> := <tnn_log, 1 > and <factjog, 1 >
<trm_log> := <fact_log,l>
<fact_log> := (<expr_log,l>)
<fact_log> := not(<expr_log,l>)
<fact_log> := <expr_arit,l> <op_rel,l> <expr_arit,2>
<fact_log> := trmino,l(<paimetros,l>)
<fact_log> := trmino, 1
<op_rel> := <
<op_rel> := >
<op_rel> := =<
<op_rel> := >=
Operacin
<expresi6n>.prefija = <expr_log, l>.prefija
<expresin>. prefija = <expr_arit, l>.prefija
<expr_log>.prefija =
Concatenar("(",
<cuantificador, l>.prefija,"(",
<parmetros,l>.prefija " ) " ,
"( <expr_bool, 1 >.prefiia ")")
<cuantificador>.prefija = "exists"
<cuantificador>.prefija = "forall"
<parmetros>.prefija =
Concatenare
<parmetro, l>.prefija,"",
<parmetros, l>.prefija)
<parmetro>.preja =
<expr_arit, l>.prefija
trmino, l.valor_lxico
<expr_implic>.prefija =
Concatenar("(",
<op_implic,l>.prefija," ",
<expr_implic,l>.prefija," ",
<comb_log,l>.prefija,")")
<opJmplic>.prefija = "=>"
<op_implic>.prefija = " O "
<expr_log>.prefija = <comb_log,l>.prefija
<comb_log>.prefija
Concatenar("(or ",
<comb_log,l>.prefija," ",
<trm_log,l>.prefija,")")
<comb_log> = <term_log,l>.prefija
<term_log>.prefija =
Concatenar("(and ",
<trm_log,l>.prefija, " ",
<fact_Iog,l>.prefija,")")
<term_log>.prefija = <fact_log,l>.prefiia
<fact_log>.prefija =
Concatenar("(",
<expr_Iog,l>.prefija, ")")
Concatenar("(not",
<expr_log,l>.prefija,")")
Concatenar("(","
<op_rel,l>.prefija," ",
<expr_arit,l>.prefija," ",
<expr_arit,2>.prefija,")")
Concatenar("{",
trmino, l.valor_lxico,"",
<parmetros>.prefija,")")
<fact_log>.prefija = t r m i n o , valorjxico
<op_rel>.preja = "<"
<op_rel>.prefija = ">"
<op_rel>.prefija = "=<"
<op_rel>.prefija = ">="
Tabla VI.14. Traduccin de las expresiones lgicas y aritmticas (1/2)
VI-16
Regla sintctica
<expr_arit> := <expr_arit,l> <sum_rest,l> <trm_arit,l>
<sum rest>
<sum rest>
<expr_arit>
<term_arit>
:= +
:= := <trm_arit,l>
:= <term_arit,l> <mult_div,l> <fact_arit,l>
<mult div> := *
<mult_div> := /
<term_arit> := <fact_arit,l>
<fact_arit> := (<expr_arit,l>)
<fact_arit> := nmero, 1
<fact_arit> := t n n i n o , !
<fact_arit> := <fi]nc_l_arg,l> (<expr_arit,l>)
<fact_arit> := <func_2_arg,l> (<expr_arit,l>, <expr_arit,2>)
<func_l_param> := abs
<func_l_ param >:= acos
<func_l_ param >:= asn
<func_l_ param >:= atan
<func_l_ param > := ceiling
<func_l_ paiam >:= eos
<func_l_ param >:= floor
<func_l_ param >:= signum
<func_l_ param >:= sin
<func_l_ param >:= tan
<func_l_ param >:= trncate
<func_2_ parara >:= expt
<func_2_ parara >:= log
<func_2_ param >:= max
<func_2_ param >:= min
Operacin
<expr_arit>.prefija =
Concatenar("(",
<sum_rest,l>.prefija, " ",
<trm_arit,l>.prefija,")")
<sum_rest>.prefija = "+"
<sum_rest>.prefija ="-"
<expr_arit>.prefija = <term_arit,l>.prefiia
<term_arit>.prefija =
Concatenar("(",
<mult_div,l>.prefija," ",
<term_arit,l>.prefija, " ",
<fact_arit,l>.prefiia,")")
<mult_div>.prefija = "*"
<rault_div>.prefija = "/"
<term_arit>.prefija = <fact_arit,l>.prefija
<fact_arit>.prefija = <expr_arit,l>.prefiia
<fact_arit>.prefija = nmero, l.valor_lxico
<fact_arit>.prefija = trmino, l.valor_Ixico
<fact_arit>.prefija =
Concatenar("(">
<ftinc_l_arg>.prefija," ",
<expr_arit,l>.prefija,")")
<fact_arit>.prefija =
Concatenar("(">
<func_2_arg>.prefija," ",
<expr_arit,2>.prefija ")")
<fiinc_l_param> .prefija = "abs"
<func_l_param>.prefija= "acos"
<func_l_param>.prefija = "asin"
<func_l_param>.prefija = "atan"
<func_l_parara>.prefija = "ceiling"
<func_l_param>.prefija = "eos"
<func_l_param>.prefija = "floor"
<fune_l_param>.prefija = "signum"
<func_l_param>.prefija = "sin"
<func_l_param>.prefija = "tan"
<func_l_param>,prefija = "trncate"
<ftinc_2_param>.prefija = "expt"
<func_2_pararn>.prefija = "log"
<func_2_param>.prefija = "max"
<func_2_parara>.prefija = "min"
Tabla VI. 14. Traduccin de las expresiones lgicas y aritmticas (2/2)
VI-17

Ontologias

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ontologias

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD POUTECNICA DE MADRID

MTODO BI-FASE PARA LA

Autor: Mariano Fernndez Lpez

utilizando el mtodo propuesto en este trabajo, los modelos conceptuales obtenidos

transformacin de un esquema de conceptualizacin descrito con LBIR en un esquema

conceptualisation schema to be used during the ontology development is carried out. In

declaratively conceptualisation schemas at the knowledge level. Besides, a formal

2. Building of a technological environment that supports the proposed method:

4.2.3 ELABORACIN DESDE CERO DE UNA ESPECIFICACIN

EL SOPORTE TECNOLGICO DEL MTODO DE CONCEPTUALIZACIN

Mariano Fernndez Lpez

1.1 CONSTRUCCIN DE ONTOLOGIAS EN EL NIVEL DE

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

La primera transformacin se conoce como conceptualizacin o diseo epistemolgico del

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

Inteligencia Artificial (LIA) de la Facultad de Informtica (Fl) de la Universidad Politcnica de

Consiguientemente, cabe preguntarse: la construccin de ontologas supone una ruptura tan

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

1. No obtiene una documentacin que presente los conocimientos de una manera

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

en el dominio de la qumica, se escribiera directamente en Ontolingua. El cdigo resultante

(define-function densidad(?elemento) :-> ?densidad-a-20-C

(peso-atmico ?elemento ?peso-atmico)

Figura 1.2.a, transformar el modelo conceptual

resultante de la conceptualizacin en un modelo formalizado obtenido en la etapa de

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

formalizado en un modelo computacional. En esta secuencia de modelos es necesario evaluar

Figura 1.2. Supresin de la formalizacin a travs de una conceptualizacin ms formalizada

En otras reas distintas a la de las ontologas se ha seguido un enfoque anlogo. En el caso

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

1.2 PROPUESTA DE UN ESQUEMA DE CONCEPTUALIZACIN

1.2.1 OBTENCIN DEL ESQUEMA DE REFERENCIA

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

en conceptualizacin, y se public el primer esquema de conceptualizacin en el Workshop on

1.2.2 EXPRESIVIDAD DEL ESQUEMA DE REFERENCIA

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

software que soporte la flexibilidad del mtodo.

QUE HAY QUE

QUE HAY QUE

Fases de que consta el mtodo de conceptualizacin propuesto en este trabajo

Figura 1.3. Especificacin, conceptualizacin, formalizacin e implementacin en dos planos

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

Concretamente, permite traducir

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

(KA)^, el proyecto multidicisplinar AM9819, y el proyecto METHONTOLOGY, financiado por la

Peticin del experto

Figura L4. Visin general de ODE

conceptualizacin), desde el punto de vista tecnolgico, y desde el punto de vista de los

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos

Mariano Fernndez Lpez

4. Descripcin detallada de la solucin. Se har una presentacin pormenorizada,

Mtodo flexible para la conceptualizacin de ontologas basado en meta-modelos