Traducido del inglés al español - www.onlinedoctranslator.

com

Ontology Development 101: Una guía para crear su

Primera ontología
Natalya F. Noy y Deborah L. McGuinness
Universidad de Stanford, Stanford, CA, 94305
noy@smi.stanford.edu y dlm@ksl.stanford.edu

1 ¿Por qué desarrollar una ontología?

En los últimos años, el desarrollo de ontologías —especificaciones formales explícitas de los términos
en el dominio y las relaciones entre ellos (Gruber 1993)— se ha trasladado desde el ámbito de los
laboratorios de inteligencia artificial a los escritorios de los expertos del dominio. Las ontologías se
han vuelto comunes en la World-Wide Web. Las ontologías en la Web van desde grandes taxonomías
que categorizan sitios Web (como en Yahoo!) hasta categorizaciones de productos a la venta y sus
características (como en Amazon.com). El Consorcio WWW (W3C) está desarrollando el Marco de
descripción de recursos (Brickley y Guha 1999), un lenguaje para codificar el conocimiento en las
páginas web para que sea comprensible para los agentes electrónicos que buscan información. La
Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA), en conjunto con el W3C, está
desarrollando DARPA Agent Markup Language (DAML) mediante la ampliación de RDF con
construcciones más expresivas destinadas a facilitar la interacción de los agentes en la Web (Hendler y
McGuinness 2000). Muchas disciplinas ahora desarrollan ontologías estandarizadas que los expertos
del dominio pueden usar para compartir y anotar información en sus campos. La medicina, por
ejemplo, ha producido vocabularios extensos, estandarizados y estructurados comoSNOMED(Price y
Spackman 2000) y la red semántica del Sistema Unificado de Lenguaje Médico (Humphreys y Lindberg
1993). También están surgiendo amplias ontologías de propósito general. Por ejemplo, el Programa de
Desarrollo de las Naciones Unidas y Dun & Bradstreet combinaron sus esfuerzos para desarrollar la
ontología UNSPSC que proporciona terminología para productos y servicios (www.unspsc.org).

Una ontología define un vocabulario común para los investigadores que necesitan compartir información en
un dominio. Incluye definiciones interpretables por máquina de conceptos básicos en el dominio y las
relaciones entre ellos.
¿Por qué alguien querría desarrollar una ontología? Algunas de las razones son:
• Compartir un entendimiento común de la estructura de la información entre personas o agentes de
software.
• Para habilitar la reutilización del conocimiento del dominio

• Para hacer explícitos los supuestos de dominio

• Separar el conocimiento del dominio del conocimiento operativo.

• Para analizar el conocimiento del dominio

Compartir un entendimiento común de la estructura de la información entre personas o agentes de software

es uno de los objetivos más comunes en el desarrollo de ontologías (Musen 1992; Gruber 1993). Por
ejemplo, suponga que varios sitios web diferentes contienen información médica o brindan servicios
médicos de comercio electrónico. Si estos sitios web comparten y publican la misma ontología subyacente
de los términos que utilizan, los agentes informáticos pueden extraer y agregar información de estos
diferentes sitios. Los agentes pueden utilizar esta información agregada para responder a las consultas de
los usuarios o como datos de entrada a otras aplicaciones.
Permitir la reutilización del conocimiento del dominiofue una de las fuerzas impulsoras detrás del reciente
aumento en la investigación de la ontología. Por ejemplo, los modelos para muchos dominios diferentes deben
representar la noción de tiempo. Esta representación incluye las nociones de intervalos de tiempo, puntos en el
tiempo, medidas relativas de tiempo, etc. Si un grupo de investigadores desarrolla tal ontología en detalle, otros
pueden simplemente reutilizarla para sus dominios. Además, si necesitamos construir una gran

1
ontología, podemos integrar varias ontologías existentes que describen porciones del gran dominio.
También podemos reutilizar una ontología general, como la ontología UNSPSC, y extenderla para
describir nuestro dominio de interés.
Hacer supuestos de dominio explícitossubyacente a una implementación hace posible cambiar estas suposiciones
fácilmente si cambia nuestro conocimiento sobre el dominio. Las suposiciones de codificación estricta sobre el
mundo en el código del lenguaje de programación hacen que estas suposiciones no solo sean difíciles de encontrar
y comprender, sino también difíciles de cambiar, en particular para alguien sin experiencia en programación.
Además, las especificaciones explícitas del conocimiento del dominio son útiles para los nuevos usuarios que deben
aprender qué significan los términos del dominio.
Separar el conocimiento del dominio del conocimiento operativo.es otro uso común de las ontologías.
Podemos describir una tarea de configurar un producto a partir de sus componentes de acuerdo con una
especificación requerida e implementar un programa que realice esta configuración independientemente de
los productos y componentes mismos (McGuinness y Wright 1998). Luego podemos desarrollar una
ontología de componentes y características de PC y aplicar el algoritmo para configurar PC hechas a la
medida. También podemos usar el mismo algoritmo para configurar ascensores si le "alimentamos" con una
ontología de componente de ascensor (Rothenfluh et al. 1996).
Analizando el conocimiento del dominioes posible una vez que se dispone de una especificación declarativa
de los términos. El análisis formal de términos es extremadamente valioso cuando se intenta reutilizar
ontologías existentes y extenderlas (McGuinness et al. 2000).
A menudo, una ontología del dominio no es un objetivo en sí mismo. Desarrollar una ontología es similar a definir
un conjunto de datos y su estructura para que los utilicen otros programas. Los métodos de resolución de
problemas, las aplicaciones independientes del dominio y los agentes de software utilizan ontologías y bases de
conocimientos creadas a partir de ontologías como datos. Por ejemplo, en este artículo desarrollamos una
ontología de vino y comida y combinaciones apropiadas de vino con comidas. Esta ontología se puede utilizar como
base para algunas aplicaciones en un conjunto de herramientas de gestión de restaurantes: una aplicación podría
crear sugerencias de vinos para el menú del día o responder a las consultas de los camareros y clientes. Otra
aplicación podría analizar una lista de inventario de una bodega de vinos y sugerir qué categorías de vinos expandir
y qué vinos en particular comprar para los próximos menús o libros de cocina.

Acerca de esta guía

Nos basamos en nuestra experiencia con Protégé-2000 (Protege 2000), Ontolingua (Ontolingua
1997) y Chimaera (Chimaera 2000) como entornos de edición de ontologías. En esta guía, usamos
Protégé-2000 para nuestros ejemplos.
El ejemplo de vino y comida que usamos a lo largo de esta guía se basa libremente en una base de conocimiento de
ejemplo presentada en un documento que describe CLASSIC: una representación de conocimiento
sistema basado en un enfoque de descripción-lógica (Brachman et al. 1991). El tutorial CLÁSICO
(McGuinness et al. 1994) ha desarrollado más este ejemplo. Protégé-2000 y otros sistemas basados
en marcos describen ontologías declarativamente, declarando explícitamente cuál es la jerarquía de
clases ya qué clases pertenecen los individuos.
Algunas ideas de diseño de ontologías en esta guía se originaron en la literatura sobre diseño orientado a
objetos (Rumbaugh et al. 1991; Booch et al. 1997). Sin embargo, el desarrollo de ontologías es diferente del
diseño de clases y relaciones en la programación orientada a objetos. La programación orientada a objetos
se centra principalmente en los métodos de las clases: un programador toma decisiones de diseño basadas
en laOperacionalpropiedades de una clase, mientras que un diseñador de ontologías toma estas decisiones
basándose en lasestructuralpropiedades de una clase. Como resultado, la estructura de clases y las
relaciones entre clases en una ontología son diferentes de la estructura de un dominio similar en un
programa orientado a objetos.
Es imposible cubrir todos los problemas con los que un desarrollador de ontologías puede tener que lidiar y no
estamos tratando de abordarlos todos en esta guía. En su lugar, tratamos de proporcionar un punto de partida;
una guía inicial que ayudaría a un nuevo diseñador de ontologías a desarrollar ontologías. En el

2
Al final, sugerimos lugares para buscar explicaciones de estructuras y mecanismos de diseño más
complicados si el dominio los requiere.
Finalmente, no existe una única metodología de diseño de ontología correcta y no intentamos definir
una. Las ideas que presentamos aquí son las que encontramos útiles en nuestra propia experiencia de
desarrollo de ontologías. Al final de esta guía sugerimos una lista de referencias para metodologías
alternativas.

2 ¿Qué hay en una ontología?

La literatura sobre inteligencia artificial contiene muchas definiciones de una ontología; muchos de
estos se contradicen entre sí. A los efectos de esta guía, unaontologíaes una descripción formal
explícita de conceptos en un dominio del discurso (clases(aveces llamadoconceptos)), propiedades de
cada concepto que describen varias características y atributos del concepto (tragamonedas (aveces
llamadorolesopropiedades)), y restricciones en las franjas horarias (facetas(aveces llamado
restricciones de roles)). Una ontología junto con un conjunto de individuosinstanciasde clases
constituye unbase de conocimientos. En realidad, hay una línea muy fina donde termina la ontología
y comienza la base de conocimiento.
Las clases son el foco de la mayoría de las ontologías. Las clases describen conceptos en el dominio. Por
ejemplo, una clase de vinos representa todos los vinos. Los vinos específicos son instancias de esta clase. El
vino de Burdeos en la copa frente a usted mientras lee este documento es un ejemplo de la clase de vinos de
Burdeos. Una clase puede tenersubclasesque representan conceptos que son más específicos que la
superclase. Por ejemplo, podemos dividir la clase de todos los vinos en vinos tintos, blancos y rosados.
Alternativamente, podemos dividir una clase de todos los vinos en vinos espumosos y no espumosos.

Las ranuras describen propiedades de clases e instancias:Castillo lafita Rothschild

Pauillacel vino tiene cuerpo completo; es producido por elCastillo lafita Rothschild
lagar. Tenemos dos ranuras que describen el vino en este ejemplo: el cuerpo de la ranura con el
valor completo y el creador de la ranura con el valorCastillo Lafite Rothschildlagar. A nivel de
clase, podemos decir que las instancias de la claseVinotendrán ranuras que describen su sabor,
cuerpo, nivel de azúcar,lafabricantedel vino y así sucesivamente.1
Todas las instancias de la clase.Vino,y su subclase Pauillac, tienen una ranurafabricantecuyo valor
es una instancia de la clase Bodega (Figura 1). Todas las instancias de la clase Bodega tienen un
espacioproduceque se refiere a todos los vinos (instancias de la clase Vino y sus subclases) que
produce la bodega.
En términos prácticos, desarrollar una ontología incluye:
• definir clases en la ontología,
• ordenar las clases en una jerarquía taxonómica (subclase-superclase),
• definir ranuras y describir los valores permitidos para estas ranuras,
• rellenando los valores de las ranuras para las instancias.

Luego, podemos crear una base de conocimiento definiendo instancias individuales de estas clases completando
información específica del valor del espacio y restricciones de espacio adicionales.

1Ponemos en mayúsculas los nombres de las clases y comenzamos los nombres de las ranuras con letras minúsculas. También usamosfuente de máquina de escribir

para todos los términos de la ontología de ejemplo.

3
Figura 1. Algunas clases, instancias y relaciones entre ellas en el dominio del vino. Usamos el negro para las
clases y el rojo para las instancias. Los enlaces directos representan ranuras y enlaces internos como instancia de
y subclase de.

3 Una metodología simple de ingeniería del conocimiento

Como dijimos anteriormente, no existe una forma o metodología “correcta” para desarrollar ontologías. Aquí
discutimos temas generales a considerar y ofrecemos un posible proceso para desarrollar una ontología.
Describimos un enfoque iterativo para el desarrollo de ontologías: comenzamos con un primer paso
aproximado en la ontología. Luego revisamos y refinamos la ontología en evolución y completamos los
detalles. En el camino, analizamos las decisiones de modelado que debe tomar un diseñador, así como los
pros, los contras y las implicaciones de las diferentes soluciones.
Primero, nos gustaría enfatizar algunas reglas fundamentales en el diseño de ontologías a las que nos referiremos
muchas veces. Estas reglas pueden parecer bastante dogmáticas. Sin embargo, pueden ayudar a tomar decisiones
de diseño en muchos casos.

1) No existe una forma correcta de modelar un dominio: siempre hay

alternativas viables. La mejor solución casi siempre depende de la
aplicación que tenga en mente y las extensiones que anticipe.
2) El desarrollo de ontologías es necesariamente un proceso iterativo.
3) Los conceptos en la ontología deben estar cerca de los objetos (físicos o lógicos) y
las relaciones en su dominio de interés. Lo más probable es que sean sustantivos
(objetos) o verbos (relaciones) en oraciones que describan su dominio.

Es decir, decidir para qué vamos a usar la ontología y cuán detallada o general será la ontología
guiará muchas de las decisiones de modelado en el futuro. Entre varias alternativas viables,
necesitaremos determinar cuál funcionaría mejor para la tarea proyectada, sería más intuitiva,
más extensible y más fácil de mantener. También debemos recordar que una ontología es un
modelo de la realidad del mundo y los conceptos en la ontología deben reflejar esta realidad.
Después de definir una versión inicial de la ontología, podemos evaluarla y depurarla usándola
en aplicaciones o métodos de resolución de problemas o discutiéndola con expertos en el campo,
o ambas cosas. Como resultado, es casi seguro que necesitaremos revisar la ontología inicial. Es
probable que este proceso de diseño iterativo continúe durante todo el ciclo de vida de la
ontología.

4
Paso 1. Determinar el dominio y alcance de la ontología
Sugerimos comenzar el desarrollo de una ontología definiendo su dominio y alcance. Es decir,
responde varias preguntas básicas:
• ¿Cuál es el dominio que cubrirá la ontología?
• ¿Para qué vamos a utilizar la ontología?
• ¿Para qué tipo de preguntas la información de la ontología debería proporcionar respuestas?
• ¿Quién usará y mantendrá la ontología?
Las respuestas a estas preguntas pueden cambiar durante el proceso de diseño de la ontología, pero en cualquier
momento ayudan a limitar el alcance del modelo.
Considere la ontología del vino y la comida que presentamos anteriormente. La representación de alimentos
y vinos es el dominio de la ontología. Planeamos usar esta ontología para las aplicaciones que sugieren
buenas combinaciones de vinos y alimentos.
Naturalmente, los conceptos que describen los diferentes tipos de vinos, los principales tipos de comida, la
noción de una buena combinación de vino y comida y una mala combinación figurarán en nuestra ontología.
Al mismo tiempo, es poco probable que la ontología incluya conceptos para la gestión de inventario en una
bodega o empleados en un restaurante, aunque estos conceptos están algo relacionados con las nociones
de vino y comida.
Si la ontología que estamos diseñando se usará para asistir en el procesamiento de lenguaje natural de
artículos en revistas de vinos, puede ser importante incluir sinónimos e información de parte del discurso
para conceptos en la ontología. Si la ontología se utilizará para ayudar a los clientes del restaurante a decidir
qué vino ordenar, debemos incluir información sobre precios minoristas. Si se utiliza para los compradores
de vino en el almacenamiento de una bodega de vinos, puede ser necesario el precio al por mayor y la
disponibilidad. Si las personas que mantendrán la ontología describen el dominio en un idioma que es
diferente del idioma de los usuarios de la ontología, es posible que debamos proporcionar el mapeo entre
los idiomas.

Preguntas de competencia.
Una de las formas de determinar el alcance de la ontología es esbozar una lista de preguntas que una base
de conocimiento basada en la ontología debería poder responder,preguntas de competencia
(Gruninger y Fox 1995). Estas preguntas servirán como prueba de fuego más adelante: ¿La ontología
contiene suficiente información para responder a este tipo de preguntas? ¿Las respuestas requieren
un nivel particular de detalle o representación de un área en particular? Estas preguntas de
competencia son solo un bosquejo y no necesitan ser exhaustivas.
En el dominio del vino y la comida, las siguientes son las posibles preguntas de competencia:
• ¿Qué características del vino debo tener en cuenta a la hora de elegir un vino?
• ¿Burdeos es un vino tinto o blanco?
• ¿Cabernet Sauvignon va bien con mariscos?
• ¿Cuál es la mejor opción de vino para la carne a la parrilla?
• ¿Qué características de un vino afectan su idoneidad para un plato?
• ¿Cambia un ramo o cuerpo de un vino específico con el año de cosecha?
• ¿Cuáles fueron buenas añadas para Napa Zinfandel?
A juzgar por esta lista de preguntas, la ontología incluirá información sobre diversas
características y tipos de vino, años de añada (buenos y malos), clasificaciones de alimentos
importantes para elegir un vino adecuado, combinaciones recomendadas de vino y comida.

Paso 2. Considere reutilizar ontologías existentes

Casi siempre vale la pena considerar lo que alguien más ha hecho y verificar si podemos refinar y
ampliar las fuentes existentes para nuestro dominio y tarea en particular. reutilización existente

5
Las ontologías pueden ser un requisito si nuestro sistema necesita interactuar con otras aplicaciones que ya
se han comprometido con ontologías particulares o vocabularios controlados. Muchas ontologías ya están
disponibles en formato electrónico y se pueden importar a un entorno de desarrollo de ontologías que esté
utilizando. El formalismo en el que se expresa una ontología a menudo no importa, ya que muchos sistemas
de representación del conocimiento pueden importar y exportar ontologías. Incluso si un sistema de
representación del conocimiento no puede trabajar directamente con un formalismo particular, la tarea de
traducir una ontología de un formalismo a otro no suele ser difícil.

Hay bibliotecas de ontologías reutilizables en la Web y en la literatura. Por ejemplo, podemos usar la
biblioteca de ontología Ontolingua (http://www.ksl.stanford.edu/software/ontolingua/ ) o
la biblioteca de ontologías DAML (http://www.daml.org/ontologías/ ). También hay una serie de
ontologías comerciales disponibles públicamente (p. ej., UNSPSC (www.unspsc.org), RosettaNet
(www.rosettanet.org), DMOZ (www.dmoz.org)).
Por ejemplo, es posible que ya exista una base de conocimientos de vinos franceses. Si podemos importar
esta base de conocimiento y la ontología en la que se basa, tendremos no solo la clasificación de los vinos
franceses, sino también el primer paso en la clasificación de las características del vino utilizadas para
distinguir y describir los vinos. Es posible que las listas de propiedades del vino ya estén disponibles en sitios
web comerciales comowww.vinos.co metroque los clientes consideran utilizar para comprar vinos.
Sin embargo, para esta guía asumiremos que no existen ontologías relevantes y comenzaremos a
desarrollar la ontología desde cero.

Paso 3. Enumerar términos importantes en la ontología

Es útil escribir una lista de todos los términos sobre los que nos gustaría hacer declaraciones o
explicar a un usuario. ¿Cuáles son los términos de los que nos gustaría hablar? ¿Qué propiedades
tienen esos términos? ¿Qué nos gustaría decir sobre esos términos? Por ejemplo, los términos
importantes relacionados con el vino incluiránvino,uva,lagar,localización,un vinocolor,
cuerpo,saboryContenido de azúcar;diferentes tipos dealimento,comopescadoycarne roja;
subtipos de vino comovino blanco,y así. Inicialmente, es importante obtener una lista completa
de términos sin preocuparse por la superposición entre los conceptos que representan, las
relaciones entre los términos o cualquier propiedad que puedan tener los conceptos, o si los
conceptos son clases o ranuras.
Los siguientes dos pasos, desarrollar la jerarquía de clases y definir las propiedades de los conceptos
(ranuras), están estrechamente entrelazados. Es difícil hacer uno de ellos primero y luego hacer el otro. Por
lo general, creamos algunas definiciones de los conceptos en la jerarquía y luego continuamos describiendo
las propiedades de estos conceptos y así sucesivamente. Estos dos pasos son también los pasos más
importantes en el proceso de diseño de ontología. Los describiremos aquí brevemente y luego pasaremos
las próximas dos secciones discutiendo los temas más complicados que se deben considerar, las trampas
comunes, las decisiones que se deben tomar, etc.

Paso 4. Definir las clases y la jerarquía de clases

Hay varios enfoques posibles para desarrollar una jerarquía de clases (Uschold y
Grüninger 1996):
• UNDe arriba hacia abajoEl proceso de desarrollo comienza con la definición de los conceptos más
generales en el dominio y la posterior especialización de los conceptos. Por ejemplo, podemos
empezar con la creación de clases para los conceptos generales deVinoyAlimento.Entonces
nos especializamos enVinoclass creando algunas de sus subclases:vino blanco,
Vino tinto,Vino rosado.Podemos categorizar aún más elVino tintoclase, por
ejemplo, enSyrah, Tinto Borgoña, Cabernet Sauvignon,y así.

6
 • UNde abajo hacia arribaEl proceso de desarrollo comienza con la definición de las clases más
específicas, las hojas de la jerarquía, con la posterior agrupación de estas clases en conceptos
más generales. Por ejemplo, comenzamos definiendo clases paraPauillacy
Margauxvinos Luego creamos una superclase común para estas dos clases:
Médoc—que a su vez es una subclase deBurdeos.
• UNcombinaciónEl proceso de desarrollo es una combinación de los enfoques de arriba hacia abajo y de
abajo hacia arriba: primero definimos los conceptos más destacados y luego los generalizamos y
especializamos adecuadamente. Podríamos comenzar con algunos conceptos de alto nivel como Vino,y
algunos conceptos específicos, comoMargaux.Entonces podemos relacionarlos con un
concepto de nivel medio, comoMédoc.Entonces es posible que queramos generar todas las
clases de vinos regionales de Francia, generando así una serie de conceptos de nivel medio.

La Figura 2 muestra un posible desglose entre los diferentes niveles de generalidad.

Figura 2. Los diferentes niveles de laVinotaxonomía:Vinoes el concepto más general.Vino tinto, Vino
blanco,yVino rosadoson conceptos generales de alto nivel.PauillacyMargauxson las clases más
específicas en la jerarquía (o los conceptos de nivel inferior).

Ninguno de estos tres métodos es inherentemente mejor que cualquiera de los otros. El enfoque a tomar
depende en gran medida de la visión personal del dominio. Si un desarrollador tiene una vista sistemática de
arriba hacia abajo del dominio, entonces puede ser más fácil usar el enfoque de arriba hacia abajo. El
enfoque combinado suele ser el más fácil para muchos desarrolladores de ontologías, ya que los conceptos
“en el medio” tienden a ser los conceptos más descriptivos del dominio (Rosch 1978).
Si tiende a pensar en los vinos distinguiendo primero la clasificación más general, entonces el enfoque
de arriba hacia abajo puede funcionar mejor para usted. Si prefiere comenzar con ejemplos
específicos, el enfoque de abajo hacia arriba puede ser más apropiado.
Cualquiera que sea el enfoque que elijamos, generalmente comenzamos definiendo clases. De la lista creada en el
Paso 3, seleccionamos los términos que describen objetos que tienen una existencia independiente en lugar de los
términos que describen estos objetos. Estos términos serán clases en la ontología y se convertirán en

7
anclas en la jerarquía de clases.2Organizamos las clases en una taxonomía jerárquica preguntando si
al ser una instancia de una clase, el objeto será necesariamente (es decir, por definición) una instancia
de alguna otra clase.
Si una clase A es una superclase de la clase B, entonces cada instancia de B es también una
instancia de A
En otras palabras, la clase B representa un concepto que es un “tipo de” A.
Por ejemplo, todo vino Pinot Noir es necesariamente un vino tinto. Por lo tanto, laPinot Noir clase
es una subclase de laVino tintoclase.
La Figura 2 muestra una parte de la jerarquía de clases para la ontología Wine. La Sección 4 contiene una discusión
detallada de las cosas que se deben buscar al definir una jerarquía de clases.

Figura 3. Los espacios para la claseVinoy las facetas para estas ranuras. El ícono “I” al lado delfabricante
slot indica que la ranura tiene un inverso (Sección 5.1)

Paso 5. Definir las propiedades de las clases: espacios

Las clases por sí solas no proporcionarán suficiente información para responder las preguntas de
competencia del Paso 1. Una vez que hayamos definido algunas de las clases, debemos describir la
estructura interna de los conceptos.
Ya hemos seleccionado clases de la lista de términos que creamos en el Paso 3. Es probable que
la mayoría de los términos restantes sean propiedades de estas clases. Estos términos incluyen,
por ejemplo, un vinocolor, cuerpo, saboryContenido de azúcarylocalizaciónde un
lagar.
Para cada propiedad en la lista, debemos determinar qué clase describe. Estas propiedades se convierten en
espacios adjuntos a las clases. Por lo tanto, laVinoLa clase tendrá los siguientes cupos:color,
cuerpo,sabor,yazúcar.y la claseLagartendrá unlocalizaciónranura.
En general, hay varios tipos de propiedades de objetos que pueden convertirse en ranuras en una ontología:
• “propiedades intrínsecas como lasaborde un vino;
• “propiedades "extrínsecas" tales como un vinonombre,yáreaviene de;
• partes, si el objeto está estructurado; estos pueden ser "partes" tanto físicas como abstractas (por ejemplo, los
platos de una comida)

• relaciones con otros individuos; estas son las relaciones entre los miembros individuales de la
clase y otros elementos (por ejemplo, elfabricantede un vino, representando un
relación entre un vino y una bodega, y lauvael vino está hecho). Por lo tanto, además de
las propiedades que hemos identificado anteriormente, debemos agregar lo siguiente

2También podemos ver las clases como predicados unarios: preguntas que tienen un argumento. Por ejemplo, "¿Este
objeto es un vino?" Los predicados (o clases) unarios contrastan con los predicados (o espacios) binarios: preguntas que
tienen dos argumentos. Por ejemplo, "¿Es fuerte el sabor de este objeto?" "¿Cuál es el sabor de este objeto?"

8
ranuras para elVinoclase:nombre, zona, elaborador, uva.La figura 3 muestra los espacios para la clase. Vino.

Todas las subclases de una clase.heredarla ranura de esa clase. Por ejemplo, todas las ranuras de la
clase Vinoserán heredados a todas las subclases de Wine, incluyendoVino tintoyVino blanco.
Agregaremos una ranura adicional,nivel de taninos (baja, moderada o alta), a laVino
tintoclase. Élnivel de taninola ranura será heredada por todas las clases que
representan vinos tintos (comoBurdeosyBeaujolais).
Se debe adjuntar una ranura en la clase más general que pueda tener esa propiedad. Por
ejemplo, cuerpoycolorde un vino debe adjuntarse en la claseVino,ya que es el mas general
clase cuyas instancias tendrán cuerpo y color.

Paso 6. Definir las facetas de las ranuras

Las tragamonedas pueden tener diferentes facetas que describen el tipo de valor, los valores permitidos, el número de
valores (cardinalidad) y otras características de los valores que puede tomar la tragamonedas. Por ejemplo, el valor de un
nombreranura (como en "el nombre de un vino") es una cadena. Es decir,nombrees una ranura con valor
escriba Cadena. Un espacioproduce (como en “una bodegaproduceestos vinos”) pueden tener
múltiples valores y los valores son instancias de la clase Vino. Es decir,producees una ranura con tipo
de valorInstanciaconVinocomo clase permitida.
Ahora describiremos varias facetas comunes.

cardinalidad de ranura

La cardinalidad de ranura define cuántos valores puede tener una ranura. Algunos sistemas distinguen solo entre
cardinalidad única (que permite como máximo un valor) y cardinalidad múltiple (que permite cualquier número de
valores). UNcuerpode un vino será un solo espacio de cardinalidad (un vino solo puede tener
un cuerpo). Los vinos producidos por una bodega en particular llenan un espacio de cardinalidad
múltiple produceparaLagarclase.
Algunos sistemas permiten la especificación de una cardinalidad mínima y máxima para describir el número
de valores de ranura con mayor precisión. La cardinalidad mínima de N significa que una ranura debe tener
al menos N valores. por ejemplo, eluvaslot de un Wine tiene una cardinalidad mínima de 1:
cada vino está hecho de al menos una variedad de uva. La cardinalidad máxima de M significa que una
ranura puede tener como máximo valores M. La cardinalidad máxima para eluvaranura para solo
vinos varietales es 1: estos vinos se elaboran a partir de una sola variedad de uva. A veces puede ser
útil establecer la cardinalidad máxima en 0. Esta configuración indicaría que la ranura no puede tener
ningún valor para una subclase en particular.

Tipo de valor de ranura

Una faceta de tipo de valor describe qué tipos de valores pueden llenar el espacio. Aquí hay una lista de los tipos de
valores más comunes:
• Cuerdaes el tipo de valor más simple que se utiliza para tragamonedas comonombre:el valor es una
cadena simple
• Número(a veces se usan tipos de valor más específicos de Float y Integer) describe las
ranuras con valores numéricos. por ejemplo, unpreciode un vino puede tener un valor
tipo flotante
• booleanolas tragamonedas son simples banderas de sí o no. Por ejemplo, si elegimos no
representar los vinos espumosos como una clase separada, si un vino es espumoso o no
puede representarse como un valor de un espacio booleano: si el valor es "verdadero" ("sí"), el
vino es espumoso y si el valor es “falso” (“no”) el vino no es espumoso.
• enumeradoslots especifica una lista de valores permitidos específicos para el slot. Por
ejemplo, podemos especificar que elsaborslot puede tomar uno de los tres valores posibles:

9
 fuerte, moderado,ydelicado.En Protégé-2000 las ranuras enumeradas son del
tipoSímbolo.
• Instancia-Tipo de slots que permiten definir las relaciones entre los individuos. Las ranuras con el
tipo de valor Instancia también deben definir una lista de clases permitidas de las que pueden
provenir las instancias. Por ejemplo, una ranuraproducepara la claseLagarpuede tener instancias
de la claseVinocomo sus valores.3
La figura 4 muestra una definición de la ranura.produceen la claseLagar.

Figura 4. La definición de una ranuraproduceque describe los vinos producidos por una bodega. La ranura tiene
cardinalidad múltiplo, instancia de tipo de valor y la claseVinocomo la clase permitida para sus valores.

Dominio y rango de una ranura

Las clases permitidas para espacios de tipo Instancia a menudo se denominandistanciade una ranura. En el
ejemplo de la Figura 4, la claseVinoes el rango de laproduceranura. Algunos sistemas permiten
restringir el rango de un espacio cuando el espacio se adjunta para una clase en particular.
Las clases a las que se adjunta un espacio o las clases cuya propiedad describe un espacio, se
denominandominiode la ranura ÉlLagarla clase es el dominio de laproduceranura. En el
sistemas donde nosotrosadjuntarslots a clases, las clases a las que se adjunta el slot normalmente
constituyen el dominio de ese slot. No es necesario especificar el dominio por separado.
Las reglas básicas para determinar un dominio y un rango de un espacio son similares:

Al definir un dominio o un rango para un espacio, encuentre las clases o clases más
generales que pueden ser, respectivamente, el dominio o el rango para los espacios.
Por otro lado, no defina un dominio y rango que sea demasiado general: todas las
clases en el dominio de un espacio deben ser descritas por el espacio y las instancias
de todas las clases en el rango de un espacio deben ser rellenos potenciales para el
ranura. No elija una clase demasiado general para el rango (es decir, uno no querría
hacer que el rango sea una COSA), pero uno querrá elegir una clase que cubra todos
los rellenos.
En lugar de enumerar todas las subclases posibles de laVinoclase para el rango deproduce

3Algunos sistemas simplemente especifican el tipo de valor con una clase en lugar de requerir una declaración especial de ranuras de tipo de
instancia.

10
ranura, solo listaVino.Al mismo tiempo, no queremos especificar el rango de la ranura como
COSA, la clase más general en una ontología.
En términos más específicos:

Si una lista de clases que define un rango o un dominio de un espacio incluye una
clase y su subclase, elimine la subclase.
Si el rango de la ranura contiene tanto elVinoclase y elVino tintoclase, podemos eliminar laVino
tintodel rango porque no agrega ninguna información nueva: El Vino tintoes una subclase deVino
y, por lo tanto, el rango de tragamonedas ya lo incluye implícitamente, así como todas las demás
subclases delVinoclase.
Si una lista de clases que define un rango o un dominio de una ranura contiene
todas las subclases de una clase A, pero no la clase A en sí, el rango debe contener
solo la clase A y no las subclases.
En lugar de definir el rango de la ranura para incluirVino Tinto, Vino Blanco,yVino rosado (
enumerando todas las subclases directas deVino),podemos limitar el rango a la clase Vinosí
mismo.
Si una lista de clases que define un rango o un dominio de una ranura contiene todas
menos unas pocas subclases de una clase A, considere si la clase A haría una definición
de rango más apropiada.
En los sistemas en los que adjuntar un espacio a una clase es lo mismo que agregar la clase al dominio del
espacio, se aplican las mismas reglas para la vinculación de espacios: por un lado, debemos tratar de hacerlo
lo más general posible. Por otro lado, debemos asegurarnos de que cada clase a la que adjuntemos la
ranura pueda tener la propiedad que representa la ranura. Podemos adjuntar eltanino
nivelranura para cada una de las clases que representan vinos tintos (por ejemplo,Burdeos, Merlot,
Beaujolais,etc.). Sin embargo, dado que todos los vinos tintos tienen la propiedad del nivel de taninos,
en su lugar deberíamos adjuntar la ranura a esta clase más general deVinos Tintos.Generalizando el
dominio de lanivel de taninomás ranura (fijándola a laVinoclass en su lugar) no sería correcto ya que
no usamos el nivel de taninos para describir los vinos blancos, por ejemplo.

Paso 7. Crear instancias

El último paso es crear instancias individuales de clases en la jerarquía. Definir una instancia
individual de una clase requiere (1) elegir una clase, (2) crear una instancia individual de esa clase
y (3) completar los valores de las ranuras. Por ejemplo, podemos crear una instancia individual
Château-Morgon-Beaujolaispara representar un tipo específico de vino Beaujolais.
Château-Morgon-Beaujolaises una instancia de la clasebeaujolaisrepresentando a todos los vinos de
Beaujolais. Esta instancia tiene los siguientes valores de ranura definidos (Figura 5):
• Cuerpo: Ligero
• Color rojo
• Sabor: Delicado
• Nivel de tanino: Bajo
• Uva: Gamay (instancia de laUva de vinoclase)
• Maker: Chateau-Morgon (instancia de laLagarclase)
• Región: Beaujolais (instancia de laRegión vinícolaclase)

11
 • Azúcar: Seco

Figura 5. La definición de una instancia delbeaujolaisclase. la instancia esCastillos Morgon

Beaujolaisde la región de Beaujolais, producido a partir de la uva Gamay por la
Bodega Château Morgon. De cuerpo ligero, sabor delicado, color rojo y bajo nivel de taninos. Es un vino
seco.

4 Definición de clases y una jerarquía de clases

En esta sección se analizan los aspectos a tener en cuenta y los errores que son fáciles de
cometer al definir clases y una jerarquía de clases (Paso 4 de la Sección 3). Como hemos
mencionado antes, no existe una única jerarquía de clases correcta para ningún dominio dado.
La jerarquía depende de los posibles usos de la ontología, el nivel de detalle necesario para la
aplicación, las preferencias personales y, en ocasiones, los requisitos de compatibilidad con otros
modelos. Sin embargo, discutimos varias pautas a tener en cuenta al desarrollar una jerarquía de
clases. Después de definir un número considerable de clases nuevas, es útil retroceder y verificar
si la jerarquía emergente se ajusta a estas pautas.

4.1 Asegurarse de que la jerarquía de clases sea correcta

Una relación “es-un”

La jerarquía de clases representa una relación "es-a": una clase A es una subclase de B si cada
instancia de A es también una instancia de B. Por ejemplo,Chardonnayes una subclase deVino blanco.
Otra forma de pensar en la relación taxonómica es como una relación de "especie de":ChardonnayEs un tipo
deVino blanco.Un jetliner es una especie de avión. La carne es un tipo de alimento.

Una subclase de una clase representa un concepto que es un "tipo de" el concepto
que representa la superclase.

Un solo vino no es una subclase de todos los vinos.

Un error de modelado común es incluir una versión singular y plural del mismo concepto en la
jerarquía, lo que convierte a la primera en una subclase de la última. Por ejemplo, es incorrecto
definir una claseVinosy una claseVinocomo una subclase deVinos.Una vez que piensas en el
jerarquía como la representación de la relación "tipo de", el error de modelado se vuelve claro:
un soloVinono es unmas o menosVinos.La mejor manera de evitar tal error es siempre usar
ya sea singular o plural en las clases de nombres (ver la Sección 6 para la discusión sobre nombres

12
conceptos).

Transitividad de las relaciones jerárquicas

Una relación de subclase es transitiva:

Si B es una subclase de A y C es una subclase de B, entonces C es una subclase de A

Por ejemplo, podemos definir una claseVino,y luego definir una claseBlanco de vinocomo una subclase
Vino.Luego definimos una claseChardonnaycomo una subclase deBlanco vino.transitividad
de la relación de subclase significa que la claseChardonnayes también una subclase deVino. A
veces distinguimos entre subclases directas y subclases indirectas. UNsubclase directa es la
subclase "más cercana" de la clase: no hay clases entre una clase y su subclase directa en una
jerarquía. Es decir, no hay otras clases en la jerarquía entre una clase y su superclase directa. En
nuestro ejemplo,Chardonnayes una subclase directa devino blancoy no es una subclase directa
deVino.

Evolución de una jerarquía de clases.

Mantener una jerarquía de clases consistente puede convertirse en un desafío a medida que evolucionan los
dominios. Por ejemplo, durante muchos años todos los vinos de Zinfandel eran tintos. Por lo tanto, definimos una
clase de Zinfandelvinos como una subclase de laVino tintoclase. A veces, sin embargo, los enólogos
comenzó a prensar las uvas y a eliminar inmediatamente los aspectos colorantes de las
uvas, modificando así el color del vino resultante. Así, obtenemos “zinfandel blanco”
cuyo color es rosa. Ahora tenemos que romper elZinfandelclase en dos clases
de zinfandel—Zinfandel blancoyZinfandel rojo—y clasificarlos como subclases deVino
rosadoyVino tintorespectivamente.

Clases y sus nombres

Es importante distinguir entre una clase y su nombre:
Las clases representan conceptos en el dominio y no las palabras que denotan estos
conceptos.
El nombre de una clase puede cambiar si elegimos una terminología diferente, pero el término en sí mismo
representa la realidad objetiva del mundo. Por ejemplo, podemos crear una clasecamarones,
y luego cambiarle el nombre aLangostinos-la clase todavía representa el mismo concepto. Las
combinaciones de vino apropiadas que se refieren a platos de camarones deben referirse a platos de
gambas. En términos más prácticos, siempre se debe seguir la siguiente regla:

Sinónimos para el mismo concepto no representan diferentes clases

Los sinónimos son simplemente nombres diferentes para un concepto o un término. Por lo tanto, deberíamosno
tener una clase llamadaCamaróny una clase llamadaGamba,y, posiblemente, una clase llamadaCrevette.
Más bien, hay una clase, llamada ya seaCamarónoGamba.Muchos sistemas permiten asociar una lista de
sinónimos, traducciones o nombres de presentación con una clase. Si un sistema no permite estas
asociaciones, siempre se pueden enumerar los sinónimos en la documentación de la clase.

Evitar los ciclos de clase

debemos evitarciclosen la jerarquía de clases. Decimos que hay un ciclo en una jerarquía cuando alguna
clase A tiene una subclase B y al mismo tiempo B es una superclase de A. Crear tal ciclo en una jerarquía
equivale a declarar que las clases A y B son equivalentes: todas las instancias de A son instancias de B y
todas las instancias de B son también instancias de A. De hecho, dado que B es una subclase de A, todas las
instancias de B deben ser instancias de la clase A. Dado que A es una subclase de B, todas las instancias de A
también deben ser instancias de la clase B.

13
4.2 Analizando hermanos en una jerarquía de clases

Hermanos en una jerarquía de clases

Hermanosen la jerarquía hay clases que son subclases directas de la misma clase (ver Sección
4.1).
Todos los hermanos de la jerarquía (excepto los de la raíz) deben estar en el
mismo nivel de generalidad.
Por ejemplo,vino blancoyChardonnayno deben ser subclases de la misma clase (digamos,Vino). vino
blancoes un concepto más general queChardonnay.Los hermanos deben representar conceptos que
caen "en la misma línea" de la misma manera que las secciones del mismo nivel en un libro están en el
mismo nivel de generalidad. En ese sentido, los requisitos para una jerarquía de clases son similares a
los requisitos para el esquema de un libro.
Sin embargo, los conceptos en la raíz de la jerarquía (que a menudo se representan como subclases
directas de alguna clase muy general, comoCosa)representan las principales divisiones de la
dominio y no tienen por qué ser conceptos similares.

¿Cuántos son demasiados y cuántos son demasiado pocos?

No hay reglas estrictas para la cantidad de subclases directas que debe tener una clase. Sin embargo,
muchas ontologías bien estructuradas tienen entre dos y una docena de subclases directas. Por lo tanto,
tenemos las siguientes dos pautas:

Si una clase tiene solo una subclase directa, puede haber un problema de modelado o la
ontología no está completa.
Si hay más de una docena de subclases para una clase determinada, pueden ser
necesarias categorías intermedias adicionales.
La primera de las dos reglas es similar a la regla de composición tipográfica de que las listas con viñetas
nunca deben tener una sola viñeta. Por ejemplo, la mayoría de los vinos tintos de Borgoña son vinos Côtes
d'Or. Supongamos que quisiéramos representar solo este tipo mayoritario de vinos de Borgoña. Podríamos
crear una claserojo borgoñay luego una sola subclaseCostas de Oro (Figura 6a). Sin embargo, si en
nuestra representación los vinos tintos de Borgoña y Côtes d'Or son esencialmente equivalentes (todos los
vinos tintos de Borgoña son vinos de Côtes d'Or y todos los vinos de Côtes d'Or son vinos tintos de Borgoña),
creando laCostas de OroLa clase no es necesaria y no agrega ninguna información nueva a
la representación. Si tuviéramos que incluir los vinos Côtes Chalonnaise, que son vinos de
Borgoña más baratos de la región justo al sur de Côtes d'Or, entonces crearíamos dos
subclases de laborgoñaclase:Costas de OroyCotes Chalonnaise (Figura 6b).

Figura 6. Subclases de larojo borgoñaclase. Tener una sola subclase de una clase generalmente
apunta a un problema en el modelado.

Supongamos ahora que enumeramos todos los tipos de vinos como subclases directas de laVino
clase. Esta lista incluiría tipos de vino más generales como Beaujolais y Burdeos, así como tipos
más específicos como Paulliac y Margaux (Figura 6a). La claseVinotiene demasiadas subclases
directas y, de hecho, para que la ontología refleje los diferentes tipos de vino de una manera más
organizada,Médocdebe ser una subclase deBurdeosyCostas de Orodebería ser un

14
subclase deBorgoña.Además de tener categorías intermedias comoVino tintoyvino blanco
también reflejaría el modelo conceptual del dominio de los vinos que tiene mucha gente
(Figura 6b).
Sin embargo, si no existen clases naturales para agrupar conceptos en la larga lista de hermanos, no
hay necesidad de crear clases artificiales, simplemente deje las clases como están. Después de todo, la
ontología es un reflejo del mundo real, y si no existe una categorización en el mundo real, entonces la
ontología debería reflejar eso.

Figura 7. Categorización de vinos. Tener todos los vinos y tipos de vino versus tener varios niveles de
categorización.

4.3 Herencia múltiple

La mayoría de los sistemas de representación del conocimiento permitenherencia múltipleen la jerarquía de
clases: una clase puede ser una subclase de varias clases. Supongamos que nos gustaría crear una clase separada
de vinos de postre, laVino de postreclase. El vino de Oporto es a la vez un vino tinto y un postre.

15
vino.4Por lo tanto, definimos una clasePuertotener dos superclases:Vino tintoy Vino de
postre.Todas las instancias de laPuertoclase serán instancias tanto de laVino tinto clase
y elVino de postreclase. ÉlPuertoclass heredará sus ranuras y sus facetas de ambos
padres. Por lo tanto, heredará el valor DULCE para la ranura.Azúcardesde el Vino de
postreclase y elnivel de taninoranura y el valor de su ranura de color de laVino tinto
clase.

4.4 Cuándo introducir una nueva clase (o no)

Una de las decisiones más difíciles de tomar durante el modelado es cuándo introducir una nueva clase o
cuándo representar una distinción a través de diferentes valores de propiedad. Es difícil navegar tanto por
una jerarquía extremadamente anidada con muchas clases extrañas como por una jerarquía muy plana que
tiene muy pocas clases con demasiada información codificada en ranuras. Sin embargo, encontrar el
equilibrio adecuado no es fácil.
Existen varias reglas generales que ayudan a decidir cuándo introducir nuevas clases en una
jerarquía.
Las subclases de una clase generalmente (1) tienen propiedades
adicionales que la superclase no tiene, o (2) restricciones diferentes a las de
la superclase, o (3) participan en relaciones diferentes a las de las
superclases
Los vinos tintos pueden tener diferentes niveles de tanino, mientras que esta propiedad no se usa para
describir los vinos en general. El valor de la ranura de azúcar del vino de postre es DULCE, mientras que no
es cierto para la superclase de la clase de vino de postre. Los vinos Pinot Noir pueden ir bien con mariscos,
mientras que otros vinos tintos no. En otras palabras, introducimos una nueva clase en la jerarquía
generalmente solo cuando hay algo que podemos decir sobre esta clase que no podemos decir sobre la
superclase.
En términos prácticos, cada subclase debe tener nuevas ranuras agregadas, o tener nuevos valores de
ranura definidos, o anular algunas facetas de las ranuras heredadas.
Sin embargo, a veces puede ser útil crear nuevas clases incluso si no introducen nuevas
propiedades.
Las clases en jerarquías terminológicas no tienen que introducir nuevas
propiedades
Por ejemplo, algunas ontologías incluyen grandes jerarquías de referencia de términos comunes utilizados
en el dominio. Por ejemplo, una ontología subyacente a un sistema de registro médico electrónico puede
incluir una clasificación de diversas enfermedades. Esta clasificación puede ser solo eso: una jerarquía de
términos, sin propiedades (o con el mismo conjunto de propiedades). En ese caso, sigue siendo útil
organizar los términos en una jerarquía en lugar de una lista plana porque (1) permitirá una exploración y
navegación más sencillas y (2) permitirá que un médico elija fácilmente un nivel de generalidad del término
que es apropiado para la situación.
Otra razón para introducir nuevas clases sin ninguna propiedad nueva es modelar conceptos entre los
cuales los expertos del dominio suelen hacer una distinción aunque hayamos decidido no modelar la
distinción en sí. Dado que usamos ontologías para facilitar la comunicación entre los expertos del
dominio y entre los expertos del dominio y los sistemas basados en el conocimiento, nos gustaría
reflejar la visión del experto sobre el dominio en la ontología.
Finalmente, no debemos crear subclases de una clase para cada restricción adicional.Para
ejemplo, presentamos las clasesVino tinto, Vino blanco,yVino rosadoporque
esta distinción es natural en el mundo del vino. No introdujimos clases para prendas delicadas.

4Elegimos representar solo puertos rojos en nuestra ontología: los puertos blancos existen, pero son extremadamente poco
comunes.

dieciséis
vino, vino moderado, etc. Al definir una jerarquía de clases, nuestro objetivo es lograr un equilibrio
entre la creación de nuevas clases útiles para la organización de clases y la creación de demasiadas
clases.

4.5 ¿Una nueva clase o un valor de propiedad?

Al modelar un dominio, a menudo necesitamos decidir si modelar una distinción específica (como vino
blanco, tinto o rosado) como un valor de propiedad o como un conjunto de clases, nuevamente depende del
alcance del dominio y la tarea en cuestión. .
¿Creamos una clase?vino blancoo simplemente creamos una claseVinoy complete diferentes valores para la
ranura¿color?La respuesta suele estar en el alcance que definimos para la ontología. Cuán importante es el
concepto devino blancoestá en nuestro dominio? Si los vinos tienen solo una importancia marginal en el
dominio y si el vino es blanco o no tiene ninguna implicación particular para sus relaciones con otros
objetos, entonces no deberíamos introducir una clase separada para los vinos blancos. Para un modelo de
dominio utilizado en una fábrica que produce etiquetas de vino, las reglas para las etiquetas de vino de
cualquier color son las mismas y la distinción no es muy importante. Alternativamente, para la
representación del vino, la comida y sus combinaciones apropiadas, un vino tinto es muy diferente de un
vino blanco: se combina con diferentes alimentos, tiene diferentes propiedades, etc. De manera similar, el
color del vino es importante para la base de conocimientos de vinos que podemos usar para determinar el
orden de cata de vinos. Por lo tanto, creamos una clase separada paraVino blanco.

Si los conceptos con diferentes valores de ranura se convierten en restricciones para

diferentes ranuras en otras clases, entonces deberíamos crear una nueva clase para la
distinción. De lo contrario, representamos la distinción en un valor de ranura.
De manera similar, nuestra ontología del vino tiene clases tales comoMerlot rojoymerlot blanco,en lugar de
una sola clase para todos los vinos Merlot: los Merlots tintos y los Merlots blancos son vinos realmente
diferentes (hechos de la misma uva) y si estamos desarrollando una ontología detallada del vino, esta
distinción es importante.

Si una distinción es importante en el dominio y pensamos en los objetos con diferentes

valores para la distinción como diferentes tipos de objetos, entonces deberíamos crear
una nueva clase para la distinción.
Considerar instancias individuales potenciales de una clase también puede ser útil para decidir si
introducir o no una nueva clase.
Una clase a la que pertenece una instancia individual no debe cambiar con frecuencia.
Por lo general, cuando usamos propiedades extrínsecas en lugar de intrínsecas de los conceptos para
diferenciar entre clases, las instancias de esas clases tendrán que migrar a menudo de una clase a
otra. Por ejemplo,vino heladono debería ser una clase en una ontología que describa el vino
botellas en un restaurante. la propiedad cmontañosodebería ser simplemente un atributo del vino en una
botella ya que una instancia devino heladopuede dejar fácilmente de ser una instancia de esta clase y luego
volver a ser una instancia de esta clase.
Por lo general, los números, los colores y las ubicaciones son valores de ranura y no provocan la creación de
nuevas clases. El vino, sin embargo, es una notable excepción ya que el color del vino es tan importante para la
descripción del vino.
Para otro ejemplo, considere la ontología de la anatomía humana. Cuando representamos costillas, ¿creamos una clase para cada
uno de los “1S tcostilla izquierda”, “2Dakota del Nortecostilla izquierda”, y así sucesivamente? ¿O tenemos una costilla de clase?

con ranuras para el orden y la posición lateral (izquierda-derecha)?5Si la información sobre cada una de las costillas
que representamos en la ontología es significativamente diferente, entonces de hecho deberíamos

5Aquí asumimos que cada órgano anatómico es una clase ya que también nos gustaría hablar de “Juan 1S t
costilla izquierda.” Los órganos individuales de las personas existentes se representarían como individuos en nuestra ontología.

17
crea una clase para cada una de las costillas. Es decir, si queremos representar detalles de adyacencia e
información de ubicación (que es diferente para cada costilla), así como funciones específicas que cada
costilla juega y los órganos que protege, queremos las clases. Si estamos modelando la anatomía en un nivel
ligeramente menor de generalidad, y todas las costillas son muy similares en lo que respecta a nuestras
aplicaciones potenciales (solo hablamos de qué costilla está rota en la radiografía sin implicaciones para
otras partes del cuerpo) , podemos querer simplificar nuestra jerarquía y tener solo la claseCostilla,
con dos ranuras:posición lateral, orden.

4.6 ¿Una instancia o una clase?

Decidir si un concepto particular es una clase en una ontología o una instancia individual depende de cuáles
sean las aplicaciones potenciales de la ontología. Decidir dónde terminan las clases y comienzan las
instancias individuales comienza con decidir cuál es el nivel más bajo de granularidad en la representación.
El nivel de granularidad está a su vez determinado por una posible aplicación de la ontología. En otras
palabras, ¿cuáles son los elementos más específicos que se representarán en la base de conocimientos?
Volviendo a las preguntas de competencia que identificamos en el Paso 1 en la Sección 3, los conceptos más
específicos que constituirán las respuestas a esas preguntas son muy buenos candidatos para las personas
en la base de conocimientos.

Las instancias individuales son los conceptos más específicos representados en una base
de conocimiento.
Por ejemplo, si solo vamos a hablar de maridaje de vino con comida no nos interesarán las
botellas físicas concretas de vino. Por lo tanto, términos tales comoLibra esterlina
Merlot de Viñedosprobablemente van a ser los términos más específicos que usamos. En otras
palabras, la clase Wine no es una colección de botellas de vino individuales, sino de vinos
específicos producidos por bodegas específicas. Por lo tanto,Merlot de viñedos esterlinassería
una instancia en la base de conocimientos.
Por otro lado, si deseamos mantener un inventario de vinos en el restaurante además de la base de
conocimiento de buenos maridajes vino-comida, las botellas individuales de cada vino pueden convertirse en
instancias individuales en nuestra base de conocimiento.
Del mismo modo, si quisiéramos registrar diferentes propiedades para cada añada específica del
Merlot de viñedos esterlinas,entonces la añada específica del vino es una instancia en
una base de conocimientos yMerlot de viñedos esterlinases una clase que contiene instancias para todas sus
añadas.
Otra regla puede "mover" algunas instancias individuales al conjunto de clases:

Si los conceptos forman una jerarquía natural, entonces deberíamos representarlos como
clases.
Considere las regiones vinícolas. Inicialmente, podemos definir las principales regiones vitivinícolas, como Francia,
Estados Unidos, Alemania, etc., como clases y regiones vitivinícolas específicas dentro de estas grandes regiones
como instancias. Por ejemplo,Región de Borgoñaes una instancia de laFrancés región
clase. Sin embargo, también nos gustaría decir que elCotes región de oroes un debe
Borgoña región.Por lo tanto,Región de Borgoña tienen ser una clase (para poder
subclases o instancias). Sin embargo, haciendoBorgoña regiónuna clase yCostas
región de orouna instancia deRegión de Borgoñaparece arbitrario: es muy difícil distinguir claramente qué
regiones son clases y cuáles son instancias. Por lo tanto, definimos todas las regiones vitivinícolas como
clases. Protégé-2000 permite a los usuarios especificar algunas clases como abstractas, lo que significa que
la clase no puede tener instancias directas. En nuestro caso, todas las clases de regiones son abstractas
(Figura 8).

18
Figura 8. Jerarquía de regiones vitivinícolas. Los íconos "A" junto a los nombres de las clases indican que las clases son
abstractas y no pueden tener instancias directas.

La misma jerarquía de clases sería incorrecta si omitiéramos la palabra "región" de los nombres de las
clases. No podemos decir que la claseAlsaciaes una subclase de la claseFrancia:Alsacia es
no una especie de Francia. Sin embargo, la región de Alsacia es una especie de región francesa.

Solo las clases pueden organizarse en una jerarquía: los sistemas de representación del conocimiento
no tienen una noción de subinstancia. Por lo tanto, si existe una jerarquía natural entre los términos,
como en las jerarquías terminológicas de la Sección 4.2, deberíamos definir estos términos como
clases aunque no tengan instancias propias.

4.7 Limitación del alcance

Como nota final sobre la definición de una jerarquía de clases, el siguiente conjunto de reglas siempre es útil para
decidir cuándo se completa la definición de una ontología:

La ontología no debe contener toda la información posible sobre el dominio: no

necesita especializarse (o generalizar) más de lo que necesita para su aplicación
(como máximo un nivel adicional en cada sentido).
Para nuestro ejemplo de vino y comida, no necesitamos saber qué papel se usa para las etiquetas o cómo
cocinar platos de camarones.
Similarmente,

La ontología no debe contener todas las posibles propiedades y

distinciones entre clases en la jerarquía.
En nuestra ontología ciertamente no incluimos todas las propiedades que un vino o un alimento
pueden tener. Representamos las propiedades más destacadas de las clases de elementos en nuestra
ontología. Aunque los libros de vinos nos dirían el tamaño de las uvas, no hemos incluido este
conocimiento. Del mismo modo, no hemos sumado todas las relaciones que uno podría imaginar
entre todos los términos de nuestro sistema. Por ejemplo, no incluimos relaciones comovino favoritoy
comida favoritaen la ontología solo para permitir una representación más completa de todas las
interconexiones entre los términos que hemos definido.
La última regla también se aplica al establecimiento de relaciones entre conceptos que ya hemos
incluido en la ontología. Considere una ontología que describa experimentos de biología. La ontología
probablemente contendrá un concepto deOrganismos biológicos.También contendrá un concepto
de unExperimentadorrealizando un experimento (con su nombre, afiliación, etc.). Es verdad

19
que un experimentador, como persona, también es un organismo biológico. Sin embargo,
probablemente no deberíamos incorporar esta distinción en la ontología: a los efectos de esta
representación, un experimentador no es un organismo biológico y probablemente nunca
realizaremos experimentos con los propios experimentadores. Si estuviéramos representando todo lo
que podemos decir sobre las clases en la ontología, unaExperimentadorse convertiría en una subclase
deOrganismo biológico.Sin embargo, no necesitamos incluir este conocimiento para las aplicaciones
previsibles. De hecho, incluir este tipo de clasificación adicional para las clases existentes en realidad duele:
ahora una instancia de un Experimentador tendrá espacios para el peso, la edad, la especie y otros datos
relacionados con un organismo biológico, pero absolutamente irrelevantes en el contexto de la descripción
de un experimento. . Sin embargo, debemos registrar dicha decisión de diseño en la documentación para el
beneficio de los usuarios que verán esta ontología y que pueden no estar al tanto de la aplicación que
teníamos en mente. De lo contrario, las personas que tengan la intención de reutilizar la ontología para
otras aplicaciones pueden intentar usar el experimentador como una subclase de persona sin saber que el
modelado original no incluía ese hecho.

4.8 Subclases disjuntas

Muchos sistemas nos permiten especificar explícitamente que varias clases sondesarticular. Las
clases son disjuntas si no pueden tener ninguna instancia en común. por ejemplo, elVino de postre
y elvino blancoLas clases en nuestra ontología sonnodisjuntos: hay muchos vinos que
son instancias de ambos. ÉlRothermel instancia
Trochenbierenauslese
de laVino dulcey elBlanco Riesling
Rieslingla clase es uno de esos ejemplos. Al mismo tiempo, elVino tintolas
clases son disjuntas: ningún vino puede ser simultáneamente tinto y
blanco. Especificar que las clases son disjuntas permite que el sistema valide mejor la ontología.
Si declaramos laVino tintoy elvino blancoclases para ser disjuntas y luego crear una clase que es
una subclase de ambasRiesling (una subclase deVino blanco)yPuerto (una subclase deVino tinto),
un sistema puede indicar que hay un error de modelado.

5 Definición de propiedades: más detalles

En esta sección discutimos varios detalles más a tener en cuenta al definir ranuras en la ontología (Paso 5 y Paso 6
en la Sección 3). Principalmente, discutimos las ranuras inversas y los valores predeterminados para una ranura.

5.1 Ranuras inversas

El valor de una ranura puede depender del valor de otra ranura. Por ejemplo, si unvinoera producido
porunlagar,entonces labodega produceesevino.Estas dos relaciones, fabricanteyproduce,son llamados
relaciones inversas. Almacenar la información “en ambas direcciones” es redundante. Cuando
sabemos que un vino es producido por una bodega, una aplicación que utilice la base de conocimiento
siempre puede inferir el valor de la relación inversa de que la bodega produce el vino. Sin embargo,
desde la perspectiva de la adquisición de conocimiento es conveniente tener ambas informaciones
explícitamente disponibles. Este enfoque permite a los usuarios completar el vino en un caso y la
bodega en otro. El sistema de adquisición de conocimiento podría luego completar automáticamente
el valor de la relación inversa asegurando la consistencia de la base de conocimiento.

Nuestro ejemplo tiene un par de espacios inversos: elfabricanteranura de laVinoclase y el

produceranura de laLagarclase. Cuando un usuario crea una instancia delVinoclass y
completa el valor para elfabricanteranura, el sistema agrega automáticamente la instancia
recién creada a laproduceranura del correspondienteLagarinstancia. Por ejemplo, cuando
decimos que Sterling Merlot es producido por la bodega Sterling Vineyard, el sistema sería

20
agregar automáticamente Sterling Merlot a la lista de vinos que produce la bodega Sterling
Vineyard. (Figura 9).

Figura 9. Instancias con slots inversos. El huecoproducepara la claseLagares un inverso de la ranurafabricantepara

la claseVino.Rellenar uno de los espacios desencadena una actualización automática del otro.

5.2 Valores predeterminados

Muchos sistemas basados en tramas permiten la especificación de valores predeterminados para las ranuras. Si un valor
de ranura particular es el mismo para la mayoría de las instancias de una clase, podemos definir este valor como unvalor
por defecto para la ranura. Luego, cuando se crea cada nueva instancia de una clase que contiene este espacio, el sistema
completa el valor predeterminado automáticamente. Luego podemos cambiar el valor a cualquier otro valor que permitan
las facetas. Es decir, los valores predeterminados están ahí por conveniencia: no imponen ninguna restricción nueva en el
modelo ni cambian el modelo de ninguna manera.

Por ejemplo, si la mayoría de los vinos que vamos a discutir son vinos con cuerpo, podemos tener "lleno"
como valor predeterminado para el cuerpo del vino. Entonces, a menos que digamos lo contrario, todos los
vinos que definimos serían con cuerpo.
Tenga en cuenta que esto es diferente devalores de tragamonedas. Los valores de las ranuras no se pueden cambiar. Por
ejemplo, podemos decir que la ranuraazúcartiene valor DULCE para elVino de postreclase. Entonces todos los
subclases e instancias de laVino de postrela clase tendrá el valor DULCE para el espacioazúcar.
Este valor no se puede cambiar en ninguna de las subclases o instancias de la clase.

6 ¿Qué hay en un nombre?

Definir convenciones de nomenclatura para conceptos en una ontología y luego adherirse estrictamente a
estas convenciones no solo hace que la ontología sea más fácil de entender, sino que también ayuda a evitar
algunos errores comunes de modelado. Hay muchas alternativas para nombrar conceptos. A menudo no
hay una razón particular para elegir una u otra alternativa. Sin embargo, necesitamos

Defina una convención de nomenclatura para las clases y los espacios y adhiérase a ella.
Las siguientes características de un sistema de representación del conocimiento afectan la elección de nombres

21
convenciones:
• ¿Tiene el sistema el mismo espacio de nombres para clases, espacios e instancias? Es
decir, ¿permite el sistema tener una clase y un slot con el mismo nombre (como una clase
lagary una ranuralagar)?
• ¿El sistema distingue entre mayúsculas y minúsculas? Es decir, ¿el sistema trata los nombres que difieren solo en
mayúsculas y minúsculas como nombres diferentes (comoLagarylagar)?

• ¿Qué delimitadores permite el sistema en los nombres? Es decir, ¿los nombres pueden
contener espacios, comas, asteriscos, etc.?
Protégé-2000, por ejemplo, mantiene un espacio de nombre único para todos sus marcos. Es sensible a mayúsculas
y minúsculas. Por lo tanto, no podemos tener una claselagary una ranuralagar.Sin embargo, podemos tener
una clasebodega (tenga en cuenta las mayúsculas) y una ranuralagar.CLASSIC, por otro lado, no distingue entre
mayúsculas y minúsculas y mantiene diferentes espacios de nombres para clases, espacios e individuos. Por lo
tanto, desde la perspectiva del sistema, no hay problema en nombrar tanto una clase como un espacio. Lagar.

6.1 Mayúsculas y delimitadores

Primero, podemos mejorar en gran medida la legibilidad de una ontología si usamos mayúsculas consistentes para los nombres de
los conceptos. Por ejemplo, es común poner en mayúsculas los nombres de las clases y usar minúsculas para los nombres de las
ranuras (suponiendo que el sistema distingue entre mayúsculas y minúsculas).

Cuando el nombre de un concepto contiene más de una palabra (comoplato de comida)necesitamos

delimitar las palabras. Aquí hay algunas opciones posibles.
• Usar espacio:plato de comida (muchos sistemas, incluido Protégé, permiten espacios en los nombres de
los conceptos).
• Ejecute las palabras juntas y escriba en mayúscula cada palabra nueva:Curso de comida

• Use un guión bajo, un guión u otro delimitador en el nombre:Comida_Curso, Curso de

comida,Curso de comida,Curso de comida. (Si usa delimitadores, también deberá decidir
si cada palabra nueva se escribe con mayúscula o no)
Si el sistema de representación del conocimiento permite espacios en los nombres, usarlos puede ser la
solución más intuitiva para muchos desarrolladores de ontologías. Sin embargo, es importante considerar
otros sistemas con los que su sistema puede interactuar. Si esos sistemas no usan espacios o si su medio de
presentación no maneja bien los espacios, puede ser útil usar otro método.

6.2 Singular o plural

Un nombre de clase representa una colección de objetos. Por ejemplo, una claseVinoen realidad representa
todos los vinos. Por lo tanto, podría ser más natural para algunos diseñadores llamar a la clase Vinosen vez
deVino.Ninguna alternativa es mejor o peor que la otra (aunque en la práctica se usa más a menudo el
singular para los nombres de clase). Sin embargo, cualquiera que sea la elección, debe ser consistente a lo
largo de toda la ontología. Algunos sistemas incluso requieren que sus usuarios declaren por adelantado si
van a usar o no el singular o el plural para los nombres de los conceptos y no les permiten desviarse de esa
elección.
Usar el mismo formulario todo el tiempo también evita que un diseñador cometa errores de modelado
como crear una claseVinosy luego creando una claseVinocomo su subclase (ver Sección
4.1).

6.3 Convenciones de prefijos y sufijos

Algunas metodologías basadas en conocimientos sugieren el uso de convenciones de prefijos y sufijos en los
nombres para distinguir entre clases y espacios. Dos prácticas comunes son agregar unposee-o un sufijo
- dea los nombres de las ranuras. Así, nuestras tragamonedas se conviertentiene-fabricanteytiene-bodegasi elegimos el

22
posee-convención. Las ranuras se conviertenfabricante deybodega-desi elegimos elde- convención. Este enfoque
permite que cualquier persona que mire un término determine inmediatamente si el término es una clase o un
espacio. Sin embargo, los nombres de los términos se vuelven un poco más largos.

6.4 Otras consideraciones de nomenclatura

Aquí hay algunas cosas más a considerar al definir convenciones de nomenclatura:
• No agregue cadenas como "clase", "propiedad", "ranura", etc. a los nombres de los conceptos.
Siempre queda claro en el contexto si el concepto es una clase o un espacio, por ejemplo. Además, si
usa diferentes convenciones de nomenclatura para las clases y los espacios (por ejemplo, mayúsculas
y minúsculas, respectivamente), el nombre en sí sería indicativo de cuál es el concepto.
• Por lo general, es una buena idea evitar las abreviaturas en los nombres de los conceptos (es
decir, usar Cabernet Sauvignonen vez deTaxi)
• Los nombres de las subclases directas de una clase deben incluir o no incluir el nombre
de la superclase. Por ejemplo, si estamos creando dos subclases delVinoclase a
representan vinos tintos y blancos, los dos nombres de las subclases deben ser
Vino tinto yVino blancooRojoyBlanco,pero noVino tintoyBlanco.

7 Otros recursos
Hemos utilizado Protégé-2000 como entorno de desarrollo de ontologías para nuestros
ejemplos. Duineveld y colegas (Duineveld et al. 2000) describen y comparan otros entornos
de desarrollo de ontologías.
Hemos tratado de abordar los conceptos básicos del desarrollo de ontologías y no hemos discutido
muchos de los temas avanzados o metodologías alternativas para el desarrollo de ontologías.
Gómez-Pérez (Gómez-Pérez 1998) y Uschold (Uschold y Gruninger 1996) presentan
metodologías alternativas de desarrollo de ontologías. El tutorial de Ontolingua (Farquhar 1997) analiza
algunos aspectos formales del modelado del conocimiento.
Actualmente, los investigadores enfatizan no solo el desarrollo de ontologías, sino también el análisis de ontologías. A
medida que se generen y reutilicen más ontologías, habrá más herramientas disponibles para analizar
ontologías. Por ejemplo, Chimaera (McGuinness et al. 2000) proporciona herramientas de diagnóstico para analizar
ontologías. El análisis que realiza Chimaera incluye tanto una verificación de la corrección lógica de una ontología
como un diagnóstico de errores comunes de diseño de ontología. Un diseñador de ontologías puede desear
ejecutar el diagnóstico de Chimaera sobre la ontología en evolución para determinar la conformidad con las
prácticas comunes de modelado de ontologías.

8 Conclusiones
En esta guía, hemos descrito una metodología de desarrollo de ontologías para sistemas declarativos
basados en marcos. Enumeramos los pasos en el proceso de desarrollo de ontologías y abordamos los
problemas complejos de definir jerarquías de clases y propiedades de clases e instancias. Sin embargo,
después de seguir todas las reglas y sugerencias, una de las cosas más importantes para recordar es lo
siguiente:no existe una única ontología correcta para ningún dominio. El diseño de ontologías es un proceso
creativo y no hay dos ontologías diseñadas por diferentes personas que sean iguales. Las posibles
aplicaciones de la ontología y la comprensión y la visión del dominio por parte del diseñador
indudablemente afectarán las opciones de diseño de la ontología. “La prueba está en el pudín”: podemos
evaluar la calidad de nuestra ontología solo usándola en las aplicaciones para las que la diseñamos.

23
Expresiones de gratitud
protegido-2000 (http://protege.stanford.edu ) fue desarrollado por el grupo de Mark Musen en
Stanford Medical Informatics. Generamos algunas de las figuras con el complemento OntoViz para
Protégé-2000. Importamos la versión inicial de la ontología del vino de la biblioteca de ontologías de
Ontolingua (http://www.ksl.stanford.edu/software/ontolingua/ ) que a su vez utilizó una versión
publicado por Brachman y colegas (Brachman et al. 1991) y distribuido con el sistema de representación del
conocimiento CLASSIC. Luego modificamos la ontología para presentar principios de modelado conceptual
para ontologías declarativas basadas en marcos. Los extensos comentarios de Ray Fergerson y Mor Peleg
sobre borradores anteriores mejoraron enormemente este documento.

Referencias
Booch, G., Rumbaugh, J. y Jacobson, I. (1997).La guía del usuario del lenguaje de modelado
unificado: Addison-Wesley.
Brachman, RJ, McGuinness, DL, Patel-Schneider, PF, Resnick, LA y Borgida, A. (1991). Viviendo
con CLASSIC: Cuándo y cómo usar un lenguaje similar a KL-ONE.Principios de las redes
semánticas. JF Sowa, editor, Morgan Kaufmann:401-456.
Brickley, D. y Guha, RV (1999). Especificación de esquema del marco de descripción de
recursos (RDF). Recomendación propuesta, World Wide Web Consortium: http://
www.w3.org/TR/PR-rdf-schema.
Quimera (2000). Entorno de Ontología Chimaera. www.ksl.stanford.edu/software/chimaera
Duineveld, AJ, Stoter, R., Weiden, MR, Kenepa, B. y Benjamins, VR (2000). ¿Herramientas maravillosas? Un
estudio comparativo de herramientas de ingeniería ontológica.Revista internacional de estudios humanos-
computadoras52(6): 1111-1133.

Farquhar, A. (1997). Tutorial de ontolingua. http://ksl-web.stanford.edu/people/axf/tutorial.pdf

Gómez-Pérez, A. (1998). Compartir y reutilizar el conocimiento.Manual de Sistemas Expertos Aplicados.

Liebowitz, editor, CRC Press.

Gruber, TR (1993). Un enfoque de traducción para la especificación de ontología portátil.

Adquisición de conocimientos5: 199-220.

Grüninger, M. y Fox, MS (1995). Metodología para el Diseño y Evaluación de Ontologías.

En:Actas del Taller sobre cuestiones ontológicas básicas en el intercambio de
conocimientos, IJCAI-95, Montréal.
Hendler, J. y McGuinness, DL (2000). El lenguaje de marcado de agentes de DARPA.Sistemas
inteligentes IEEEdieciséis(6): 67-73.
Humphreys, BL y Lindberg, DAB (1993). El proyecto UMLS: haciendo la conexión conceptual
entre los usuarios y la información que necesitan.Boletín de la Asociación de Bibliotecas
Médicas81(2): 170.
McGuinness, DL, Abrahams, MK, Resnick, LA, Patel-Schneider, PF, Thomason, RH, Cavalli-Sforza,
V. y Conati, C. (1994). Tutorial del Sistema de Representación del Conocimiento Clásico. http://
www.bell-labs.com/project/classic/papers/ClassTut/ClassTut.html
McGuinness, DL, Fikes, R., Rice, J. y Wilder, S. (2000). Un entorno para fusionar y probar
grandes ontologías.Principios de representación y razonamiento del conocimiento: Actas de
la Séptima Conferencia Internacional (KR2000). AG Cohn, F. Giunchiglia y B. Selman,
editores. San Francisco, CA, Morgan Kaufmann Publishers.

24
McGuinness, DL y Wright, J. (1998). Modelado conceptual para la configuración: un enfoque basado
en la lógica de descripción.Inteligencia artificial para diseño, análisis y fabricación de ingeniería:
número especial sobre configuración.
Musen, MA (1992). Dimensiones del intercambio y la reutilización del conocimiento.Informática e
Investigación Biomédica25: 435-467.

Ontolingua (1997). Manual de referencia del sistema Ontolingua. http://www-

kslsvc.stanford.edu:5915/doc/frame-editor/index.html

Price, C. y Spackman, K. (2000). Términos clínicos de SNOMED.BJHC&IM-British Journal of

Healthcare Computing & Information Management17(3): 27-31.
Protege (2000). El Proyecto Protege. http://protege.stanford.edu
Rosch, E. (1978). Principios de categorización.Cognición y Categorización. RE y BB Lloyd,
editores. Hillside, Nueva Jersey, Lawrence Erlbaum Publishers:27-48.
Rothenfluh, TR, Gennari, JH, Eriksson, H., Puerta, AR, Tu, SW y Musen, MA (1996). Ontologías
reutilizables, herramientas de adquisición de conocimiento y sistemas de rendimiento: soluciones
PROTÉGÉ-II para Sísifo-2.Revista internacional de estudios humanos-computadoras44: 303-332.

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. y Lorensen, W. (1991).Modelado y diseño orientado a
objetos. Acantilados de Englewood, Nueva Jersey: Prentice Hall.
Uschold, M. y Grüninger, M. (1996). Ontologías: Principios, Métodos y Aplicaciones. Revisión
de ingeniería del conocimiento11(2).

25