Desarrollo de la ontología 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 las ontologías -especificaciones formales explícitas de los
términos en el dominio y de las relaciones entre ellos (Gruber 1993)- ha pasado del ámbito de los
laboratorios de Inteligencia Artificial al de los escritorios de los expertos en dominios. 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 en venta y sus
características (como en Amazon.com). El Consorcio WWW (W3C) está desarrollando el Resource
Description Framework (Brickley y Guha 1999), un lenguaje para codificar el conocimiento en páginas
Web y hacerlo 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 el Lenguaje de Marcado de Agentes DARPA (DAML) mediante la extensión del RDF
con construcciones más expresivas dirigidas a facilitar la interacción del agente en la Web (Hendler y
McGuinness 2000). Muchas disciplinas desarrollan ahora ontologías estandarizadas que los expertos en
la materia pueden utilizar para compartir y anotar información en sus campos. La medicina, por
ejemplo, ha producido grandes vocabularios estandarizados y estructurados como snomed (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 ontologías de propósito general. Por ejemplo, el Programa de
las Naciones Unidas para el Desarrollo y Dun & Bradstreet combinaron sus esfuerzos para desarrollar
la ontología del 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áquinas 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 una comprensión común de la estructura de la información entre personas o agentes de

software.

- Para permitir la reutilización del conocimiento del dominio

- Para hacer explícitas las suposiciones del dominio

- Separar el conocimiento del dominio del conocimiento operativo

- Analizar el conocimiento del dominio

Compartir una comprensión 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, supongamos que varios sitios web diferentes contienen información médica o
proporcionan servicios médicos de comercio electrónico. Si estos sitios web comparten y publican la
misma ontología subyacente de los términos que todos utilizan, entonces 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 de los dominios fue una de las fuerzas que impulsaron el
reciente aumento de la investigación en 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.
Adicionalmente, si necesitamos construir una ontología grande, podemos integrar varias ontologías
existentes describiendo porciones del dominio grande. También podemos reutilizar una ontología
general, como la ontología de UNSPSC, y ampliarla para describir nuestro dominio de interés.

El hecho de hacer suposiciones explícitas de dominio subyacentes a una implementación permite

cambiar fácilmente estas suposiciones si cambia nuestro conocimiento sobre el dominio. Las
suposiciones sobre el mundo en el código del lenguaje de programación hacen que estas suposiciones
no sólo sean difíciles de encontrar y entender, sino también 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 lo que 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 según una
especificación requerida e implementar un programa que realice esta configuración
independientemente de los productos y componentes mismos (McGuinness y Wright 1998). A
continuación, podemos desarrollar una ontología de los componentes y características del PC y aplicar
el algoritmo para configurar PCs hechos a medida. También podemos utilizar el mismo algoritmo para
configurar los ascensores si le "alimentamos" con una ontología de los componentes del ascensor
(Rothenfluh et al. 1996).

El análisis del conocimiento del dominio es posible una vez que se dispone de una especificación
declarativa de los términos. El análisis formal de los términos es extremadamente valioso cuando se
trata de reutilizar ontologías existentes y de ampliarlas (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 otros programas los utilicen. Los
métodos de resolución de problemas, las aplicaciones independientes del dominio y los agentes de
software utilizan ontologías y bases de conocimiento construidas a partir de ontologías como datos. Por
ejemplo, en este trabajo desarrollamos una ontología del vino y la comida y combinaciones apropiadas
de vino con comidas. Esta ontología puede ser utilizada como base para algunas aplicaciones en un
conjunto de herramientas de gestión de restaurantes: Una aplicación podría crear sugerencias de vino
para el menú del día o responder a consultas de camareros y clientes. Otra aplicación podría analizar
una lista de inventario de una bodega y sugerir qué categorías de vino ampliar 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 utilizando Protégé-2000 (Protege 2000), Ontolingua (Ontolingua
1997), Chimaera (Chimaera 2000) como entornos de edición de ontologías. En esta guía, usamos
Protégé-2000 como ejemplo.

El ejemplo de vino y comida que utilizamos a lo largo de esta guía, se basa vagamente en un ejemplo
de base de conocimiento presentado en el documento que describe CLASSIC, un sistema de
representación del conocimiento basado en un enfoque de descripción y lógica (Brachman et al. 1991).
El tutorial CLASSIC (McGuinness et al. 1994) ha desarrollado más este ejemplo. Protégé-2000 y otros
sistemas basados en marcos describen las ontologías de forma declarativa, indicando explícitamente
cuál es la jerarquía de clases y a qué clases pertenecen los individuos.

Algunas de las ideas de diseño ontológico de 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 la
ontología 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 métodos en clases: un programador toma
decisiones de diseño basadas en las propiedades operativas de una clase, mientras que un diseñador de
ontologías toma estas decisiones basándose en las propiedades estructurales de una clase. Como
resultado, una estructura de clases y las relaciones entre clases en una ontología son diferentes de la
estructura para un dominio similar en un programa orientado a objetos.

Es imposible cubrir todos los temas con los que un desarrollador de ontologías puede tener que lidiar y
no estamos tratando de tratarlos todos en esta guía. En cambio, 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. Al
final, sugerimos lugares para buscar explicaciones de estructuras más complicadas y diseñar
mecanismos si el dominio lo requiere.

Finalmente, no existe una metodología única y correcta de diseño ontológico y no hemos intentado
definirla. Las ideas que presentamos aquí son las que encontramos útiles en nuestra propia experiencia
de desarrollo ontológico. Al final de esta guía sugerimos una lista de referencias para metodologías
alternativas.

2 ¿Qué hay en una ontología?

La literatura de la Inteligencia Artificial contiene muchas definiciones de una ontología; muchas de

ellas se contradicen entre sí. Para los fines de esta guía, una ontología es una descripción formal
explícita de conceptos en un dominio del discurso (clases (a veces llamadas conceptos)), propiedades
de cada concepto que describen varias características y atributos del concepto (ranuras (a veces
llamadas roles o propiedades)), y restricciones en las ranuras (facetas (a veces llamadas restricciones de
rol)). Una ontología junto con un conjunto de instancias individuales de clases constituye una base de
conocimiento. En realidad, hay una fina línea 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 ejemplos de esta
clase. El vino de Burdeos en la copa delante de usted mientras lee este documento es un ejemplo de la
clase de vinos de Burdeos. Una clase puede tener subclases que representan conceptos más específicos
que la superclase. Por ejemplo, podemos dividir la clase de todos los vinos en tintos, blancos y rosados.
Alternativamente, podemos dividir una clase de todos los vinos en vinos espumosos y no espumosos.

Las ranuras describen las propiedades de las clases e instancias: El Château Lafite Rothschild Pauillac
es un vino de cuerpo entero, producido por la bodega Château Lafite Rothschild. Tenemos dos slots que
describen el vino en este ejemplo: el cuerpo del slot con el valor lleno y el slot maker con el valor
Château Lafite Rothschild winery. A nivel de clase, podemos decir que las instancias de la clase Vino
tendrán ranuras que describen su sabor, cuerpo, nivel de azúcar, el fabricante del vino, etc.[1].

Todas las instancias de la clase Wine, y su subclase Pauillac, tienen un slot maker cuyo valor es una
instancia de la clase Winery (Figura 1). Todas las instancias de la clase Bodega tienen un espacio de
producción que se refiere a todos los vinos (instancias de la clase Vino y sus subclases) que produce la
bodega.

En términos prácticos, el desarrollo de una ontología incluye:

- definiendo clases en la ontología,

- organizar las clases en una jerarquía taxonómica (subclase-superclase),

- definir las ranuras y describir los valores permitidos para estas ranuras,

- rellenando los valores de las franjas horarias para las instancias.

A continuación, podemos crear una base de conocimientos definiendo instancias individuales de estas
clases rellenando la información específica sobre el valor de las ranuras y las restricciones adicionales
de las mismas.

Figura 1. Algunas clases, instancias y relaciones entre ellas en el ámbito del vino. Usamos el negro
para las clases y el rojo para los casos. Los enlaces directos representan slots y enlaces internos como
instancia-de y subclase-de.
3 Una metodología simple de ingeniería del conocimiento

Como dijimos antes, 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 la ontología: 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, discutimos las decisiones de modelado que un diseñador necesita tomar, así
como los pros, contras e implicaciones de las diferentes soluciones.

En primer lugar, 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 hay una manera 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 de las extensiones que anticipe.

2) El desarrollo de la ontología 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 frases
que describan tu 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, tendremos que
determinar cuál funcionaría mejor para la tarea proyectada, sería más intuitiva, más extensible y más
mantenible. También necesitamos 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 ambos. Como resultado, es casi seguro que
tendremos que revisar la ontología inicial. Este proceso de diseño iterativo probablemente continuará a
lo largo de todo el ciclo de vida de la ontología.

Paso 1. Determinar el dominio y el alcance de la ontología

Sugerimos iniciar el desarrollo de una ontología definiendo su dominio y alcance. Es decir, responder a
varias preguntas básicas:

- ¿Cuál es el dominio que cubrirá la ontología?

- ¿Para qué vamos a usar la ontología?

- ¿Para qué tipo de preguntas la información de la ontología debe 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 introdujimos anteriormente. La representación de los
alimentos y los 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
alimentos, 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 del inventario en una bodega o de los empleados en un restaurante, aunque estos conceptos
estén relacionados con las nociones de vino y comida.

Si la ontología que estamos diseñando se utilizará para ayudar en el procesamiento en lenguaje natural
de artículos de revistas de vino, puede ser importante incluir sinónimos e información de parte del
habla para los conceptos de la ontología. Si la ontología se va a utilizar para ayudar a los clientes de los
restaurantes a decidir qué vino pedir, necesitamos incluir información sobre los precios al por menor.
Si se utiliza para los compradores de vino en el almacenamiento de una bodega de vino, el precio al por
mayor y la disponibilidad puede ser necesario. Si las personas que mantendrán la ontología describen
el dominio en un idioma diferente al de los usuarios de la ontología, es posible que necesitemos
proporcionar el mapeo entre los idiomas.

Cuestiones 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 ser capaz de responder, preguntas de competencia
(Gruninger y Fox 1995). Estas preguntas servirán como prueba de fuego más adelante: ¿Contiene la
ontología suficiente información para responder a este tipo de preguntas? ¿Las respuestas requieren un
nivel particular de detalle o de representación de un área en particular? Estas preguntas de competencia
son sólo un esbozo y no necesitan ser exhaustivas.

En el ámbito del vino y la gastronomía, 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?

- ¿El Cabernet Sauvignon va bien con los mariscos?

- ¿Cuál es la mejor opción de vino para carnes a la brasa?

- ¿Qué características de un vino afectan a su idoneidad para un plato?

- ¿Un bouquet o cuerpo de un vino específico cambia con el año de cosecha?

- ¿Cuáles fueron las buenas cosechas para Napa Zinfandel?

A juzgar por esta lista de preguntas, la ontología incluirá la información sobre diversas características y
tipos de vino, años de cosecha -buenos y malos-, clasificaciones de los alimentos que importan para
elegir un vino apropiado, combinaciones recomendadas de vino y comida.
Paso 2. Considerar la reutilización de ontologías existentes

Casi siempre vale la pena considerar lo que alguien más ha hecho y comprobar si podemos refinar y
ampliar las fuentes existentes para nuestro dominio y tarea particulares. La reutilización de ontologías
existentes puede 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 forma electrónica y pueden ser importadas 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 en
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 utilizar la
biblioteca de ontología de Ontolingua (http://www.ksl.stanford.edu/software/ontolingua/) o la
biblioteca de ontología de DAML (http://www.daml.org/ontologies/). También hay varias ontologías
comerciales disponibles al público (por ejemplo, UNSPSC (www.unspsc.org), RosettaNet
(www.rosettanet.org), DMOZ (www.dmoz.org)).

Por ejemplo, es posible que ya exista una base de conocimientos sobre los vinos franceses. Si podemos
importar esta base de conocimientos y la ontología en la que se basa, tendremos no sólo la clasificación
de los vinos franceses, sino también la primera etapa en la clasificación de las características del vino
utilizadas para distinguir y describir los vinos. Las listas de propiedades de vinos pueden estar ya
disponibles en sitios web comerciales como www.wines.com que los clientes consideran utilizar para
comprar vinos.

Para esta guía, sin embargo, asumiremos que ya no existen ontologías relevantes y empezaremos a
desarrollar la ontología desde cero.

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

Es útil anotar 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 estos términos? Por ejemplo, los términos importantes
relacionados con el vino incluirán vino, uva, bodega, ubicación, color, cuerpo, sabor y contenido de
azúcar de un vino; diferentes tipos de alimentos, como pescado y carne roja; subtipos de vino, como
vino blanco, etc. 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 los conceptos puedan tener, o si los conceptos son clases o slots...

Los dos pasos siguientes -desarrollar la jerarquía de clases y definir las propiedades de los conceptos
(slots)- están estrechamente entrelazados. Es difícil hacer una de ellas primero y luego hacer la otra.
Típicamente, 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
más importantes en el proceso de diseño ontológico. Los describiremos aquí brevemente y luego
pasaremos las siguientes dos secciones discutiendo los temas más complicados que deben ser
considerados, las trampas más comunes, las decisiones a tomar, y así sucesivamente.
Paso 4. Definir las clases y la jerarquía de clases

Existen varios enfoques posibles para desarrollar una jerarquía de clases (Uschold y Gruninger 1996):

- Un proceso de desarrollo de arriba hacia abajo 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 de Vino y Comida. Luego nos especializamos en
la clase de vinos creando algunas de sus subclases: Vino blanco, vino tinto, vino rosado. Podemos
categorizar aún más la clase de vino tinto, por ejemplo, en Syrah, vino tinto de Borgoña, Cabernet
Sauvignon, y así sucesivamente.

- Un proceso de desarrollo de abajo hacia arriba 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, empezamos definiendo clases para los vinos Pauillac y Margaux. Luego
creamos una superclase común para estas dos clases -Medoc- que a su vez es una subclase de Burdeos.

- Un proceso de desarrollo combinado 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 apropiadamente. Podríamos empezar con algunos conceptos de alto nivel como Vino, y
algunos conceptos específicos, como Margaux. Podemos entonces relacionarlas con un concepto de
nivel medio, como Medoc. Entonces puede 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 la taxonomía del vino: Vino, vino tinto, vino blanco, vino rosado
son conceptos más generales, el nivel superior. Pauillac y Margaux son las clases más específicas de la
jerarquía, el nivel inferior.
Ninguno de estos tres métodos es inherentemente mejor que 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 utilizar el enfoque de arriba hacia abajo. El
enfoque de combinación es a menudo el más fácil para muchos desarrolladores de ontologías, ya que
los conceptos "en el medio" tienden a ser los más descriptivos en el dominio (Rosch 1978).

Si usted 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 prefieres empezar por ponerte a
trabajar con ejemplos específicos, el enfoque de abajo hacia arriba puede ser más apropiado.

Cualquiera que sea el enfoque que escojamos, normalmente empezamos por definir las clases. De la
lista creada en el Paso 3, seleccionamos los términos que describen los objetos que tienen 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 anclajes en la jerarquía de clases[2] Organizamos 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 otra clase.

Si una clase A es una superclase de 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 una "especie de" A.

Por ejemplo, cada vino Pinot Noir es necesariamente un vino tinto. Por lo tanto, la clase Pinot Noir es
una subclase de la clase Vino Tinto.

La figura 2 muestra una parte de la jerarquía de clases de la ontología del vino. La sección 4 contiene
una discusión detallada de las cosas que se deben buscar cuando se define una jerarquía de clases.

Figura 3. Las ranuras para la clase Vino y las facetas de estas ranuras. El icono "I" al lado de la ranura
del fabricante indica que la ranura tiene una posición inversa (Sección 5.1).
Paso 5. Definir las propiedades de las clases-ranuras

Las clases por sí solas no proporcionarán suficiente información para responder a las preguntas de
competencia del Paso 1. Una vez definidas 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 plazos restantes sean propiedades de estas clases. Estos términos incluyen, por ejemplo,
el color, el cuerpo, el sabor y el contenido de azúcar de un vino y la ubicación de una bodega.

Para cada propiedad de la lista, debemos determinar qué clase describe. Estas propiedades se
convierten en slots vinculados a las clases. Por lo tanto, la clase Vino tendrá las siguientes ranuras:
color, cuerpo, sabor y azúcar. Y la clase Winery tendrá un espacio de ubicación.

En general, hay varios tipos de propiedades de objetos que pueden convertirse en slots en una
ontología:

- propiedades "intrínsecas" como el sabor de un vino;

- propiedades "extrínsecas" como el nombre del vino y la zona de la que procede;

- partes, si el objeto está estructurado; éstas pueden ser tanto "partes" físicas como abstractas (por
ejemplo, los platos de una comida)

- relaciones con otros individuos; éstas son las relaciones entre los miembros individuales de la clase y
otros elementos (por ejemplo, el fabricante de un vino, que representa una relación entre un vino y una
bodega, y la uva con la que se elabora el vino).

Por lo tanto, además de las propiedades que hemos identificado anteriormente, necesitamos añadir las
siguientes ranuras a la clase de vino: nombre, área, fabricante, uva. La figura 3 muestra las franjas
horarias para la clase Vino.

Todas las subclases de una clase heredan el espacio de esa clase. Por ejemplo, todas las franjas horarias
de la clase Vino serán heredadas a todas las subclases de Vino, incluyendo Vino Tinto y Vino Blanco.
Añadiremos una ranura adicional, nivel de taninos (bajo, moderado o alto), a la clase de vinos tintos. El
nivel de taninos será heredado por todas las clases que representan a los vinos tintos (como Burdeos y
Beaujolais).

Se debe colocar una ranura en la clase más general que pueda tener esa propiedad. Por ejemplo, el
cuerpo y el color de un vino deben ser adjuntados a la clase Vino, ya que es la clase más general cuyas
instancias tendrán cuerpo y color.
Paso 6. Definir las facetas de las ranuras

Las ranuras = (INTÉRVALOS/ESPACIOS) 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 ranura. Por ejemplo, el valor de una ranura de nombres (como en "el nombre de un
vino") es una cadena. Es decir, el nombre es una ranura con el tipo de valor String. Una ranura produce
(como en "una bodega produce estos vinos") puede tener múltiples valores y los valores son instancias
de la clase Vino. Es decir, produce es una ranura con el tipo de valor Instancia con Wine como clase
permitida.

A continuación describiremos varias facetas comunes.

Cardinalidad de la ranura

La cardinalidad de la ranura define cuántos valores puede tener una ranura. Algunos sistemas
distinguen sólo entre cardinalidad única (que permite como máximo un valor) y cardinalidad múltiple
(que permite cualquier número de valores). Un cuerpo de un vino será una única ranura de cardinalidad
(un vino sólo puede tener un cuerpo). Los vinos producidos por una bodega en particular llenan un
espacio de múltiples cardinalidades producido para una clase de Bodega.

Algunos sistemas permiten especificar una cardinalidad mínima y máxima para describir con mayor
precisión el número de valores de ranura. La cardinalidad mínima de N significa que una ranura debe
tener al menos valores de N. Por ejemplo, la ranura de uva de un vino tiene una cardinalidad mínima de
1: cada vino está hecho de al menos una variedad de uva. La máxima cardinalidad de M significa que
una ranura puede tener como máximo valores de M. La cardinalidad máxima de la ranura de la uva
para los vinos monovarietales 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 la ranura

Una faceta de tipo de valor describe qué tipos de valores pueden llenar el espacio. A continuación se
muestra una lista de los tipos de valores más comunes:

- String es el tipo de valor más simple que se utiliza para ranuras como nombre: el valor es una cadena
simple.

- Número (a veces se utilizan tipos de valores más específicos de Flotador y Entero) describe ranuras
con valores numéricos. Por ejemplo, un precio de un vino puede tener un tipo de valor Float

- Las ranuras booleanas son simples banderas de sí-no. Por ejemplo, si elegimos no representar los
vinos espumosos como una clase separada, si un vino es espumoso o no, puede ser representado como
un valor de una ranura booleana: si el valor es "verdadero" ("sí") el vino es espumoso y si el valor es
"falso" ("no") el vino no es espumoso.

- Las ranuras enumeradas especifican una lista de valores específicos permitidos para la ranura. Por
ejemplo, podemos especificar que la ranura de sabor puede tomar uno de los tres valores posibles:
fuerte, moderado y delicado. En Protégé-2000 las ranuras enumeradas son de tipo Símbolo.

- Los slots de tipo instancia permiten definir las relaciones entre individuos. Las ranuras con el tipo de
valor Instancia también deben definir una lista de clases permitidas de las que pueden proceder las
instancias. Por ejemplo, una ranura produce para la clase Bodega puede tener instancias de la clase
Vino como sus valores[3].

La figura 4 muestra una definición de la ranura que se produce en la clase Bodega.

Figura 4. La definición de un slot produce que describe los vinos producidos por una bodega. La ranura
tiene múltiple de cardinalidad, tipo de valor Instancia, y la clase Wine como clase permitida para sus
valores.
Dominio y alcance de una ranura

Las clases permitidas para los slots de tipo Instancia se llaman a menudo un rango de un slot. En el
ejemplo de la Figura 4, la clase Wine es el rango de la ranura de producción. Algunos sistemas
permiten restringir el alcance de una ranura cuando la ranura está conectada a una clase particular.

Las clases a las que se asigna una franja horaria o las clases que pertenecen a una franja horaria se
denominan el dominio de la franja horaria. La clase Bodega es el dominio de la ranura de productos. En
los sistemas en los que asignamos franjas horarias a las clases, las clases a las que se asigna la franja
horaria suelen constituir el dominio de esa franja horaria. No es necesario especificar el dominio por
separado.

Las reglas básicas para determinar un dominio y el rango de una ranura son similares:

Al definir un dominio o un rango para una ranura, busque las clases o clases más generales que pueden
ser respectivamente el dominio o el rango para las ranuras .

Por otra parte, no defina un dominio y una gama que sea demasiado general: todas las clases en el
dominio de una franja horaria deben ser descritas por la franja horaria y las instancias de todas las
clases en la gama de una franja horaria deben ser rellenadores potenciales para la franja horaria. una
clase demasiado general para la gama (es decir, uno no querría hacer la gama Cosa), sino que querría
elegir una clase que cubra todas las rellenadoras.
En lugar de enumerar todas las subclases posibles de la clase Vino para el rango de la ranura de
productos, sólo enumere Vino. 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 una ranura incluye una clase y su subclase,
elimine la subclase.

Si el rango de la ranura contiene tanto la clase Vino como la clase Vino Tinto, podemos eliminar el
Vino Tinto del rango porque no añade ninguna información nueva: El vino tinto es una subclase de
vino y, por lo tanto, la gama de franjas horarias ya lo incluye implícitamente, así como todas las demás
subclases de la clase de vino.

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í misma, el rango debe contener sólo la clase A y no las subclases.

En lugar de definir el rango de la ranura para incluir Vino Tinto, Vino Blanco y Vino Rosado
(enumerando todas las subclases directas de Vino), podemos limitar el rango a la clase Vino en sí.

Si una lista de clases que definen un rango o un dominio de una ranura contiene todas las subclases de
una clase A excepto unas pocas, considere si la clase A haría una definición de rango más apropiada.

En los sistemas en los que adjuntar una ranura a una clase es lo mismo que añadir la clase al dominio
de la ranura, se aplican las mismas reglas a la inserción de la ranura: Por un lado, debemos intentar que
sea lo más general posible. Por otra parte, debemos asegurarnos de que cada clase a la que fijamos la
franja horaria pueda tener efectivamente la propiedad que representa la franja horaria. Podemos
adjuntar el nivel de taninos a cada una de las clases que representan a los vinos tintos (por ejemplo,
Burdeos, Merlot, Beaujolais, etc.). Sin embargo, dado que todos los vinos tintos tienen la propiedad de
tener un nivel de taninos, en lugar de ello deberíamos añadir la ranura a esta clase más general de vinos
tintos. Generalizar aún más el dominio de la franja de nivel de tanino (adjuntándolo a la clase Vino) no
sería correcto, ya que no utilizamos el nivel de tanino 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) rellenar
los valores de la ranura. Por ejemplo, podemos crear un ejemplo individual Chateau-Morgon-
Beaujolais para representar un tipo específico de vino Beaujolais. Chateau-Morgon-Beaujolais es un
ejemplo de la clase Beaujolais que representa todos los vinos Beaujolais. Esta instancia tiene definidos
los siguientes valores de ranura (Figura 5):

- Cuerpo: Luz

- Color: Rojo

- Sabor: Delicado
- Nivel de tanino: Baja

- Uva: Gamay (instancia de la clase de uva de vino)

- Creador: Chateau-Morgon (ejemplo de la clase Bodega)

- Región: Beaujolais (ejemplo de la clase de la Región Vitivinícola)

- Azúcar: Seco

Figura 5. La definición de una instancia de la clase Beaujolais. El ejemplo es Chateua Morgon

Beaujolais de la región de Beaujolais, producido a partir de la uva Gamay por la bodega Chateau
Morgon. Tiene un cuerpo ligero, sabor delicado, color rojo y bajo nivel de taninos. Es un vino seco.

4 Definir clases y una jerarquía de clases

Esta sección discute cosas que hay que tener en cuenta y errores que son fáciles de cometer cuando se
definen las clases y la jerarquía de clases (Paso 4 de la Sección 3). Como hemos mencionado
anteriormente, no existe una única jerarquía de clases correcta para un dominio determinado. 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, a veces, 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 nuevas clases, es útil dar un paso atrás y comprobar si la jerarquía emergente
se ajusta a estas directrices.
4.1 Asegurarse de que la jerarquía de clases es correcta
Una relación "is-a

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

Una subclase de una clase representa un concepto que es una "especie" del concepto que representa la
superclase.

Un solo vino no es una subclase de todos los vinos

Un error común de modelado es incluir tanto una versión singular como una plural del mismo concepto
en la jerarquía, convirtiendo a la primera en una subclase de la segunda. Por ejemplo, es un error
definir una clase Vinos y una clase Vino como una subclase de Vinos. Una vez que se piensa en la
jerarquía como la representación de la relación "tipo de", el error de modelado se vuelve claro: un solo
Vino no es una especie de Vinos. La mejor manera de evitar tal error es siempre usar singular o plural
en las clases de nombres (ver Sección 6 para la discusión sobre los conceptos de nombres).
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 clase Vino, y luego definir una clase Vino Blanco como una subclase
de Vino. Luego definimos una clase Chardonnay como una subclase de vino blanco. La transitividad de
la relación de la subclase significa que la clase Chardonnay es también una subclase del vino. A veces
distinguimos entre subclases directas y subclases indirectas. Una subclase 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, el
Chardonnay es una subclase directa de vino blanco y no es una subclase directa de vino.

Evolución de una jerarquía de clases

Mantener una jerarquía de clases coherente puede convertirse en un reto a medida que evolucionan los
dominios. Por ejemplo, durante muchos años, todos los vinos de Zinfandel fueron tintos. Por lo tanto,
definimos una clase de vinos Zinfandel como una subclase de la clase de vinos tintos. A veces, sin
embargo, los productores de vino comenzaron a prensar las uvas y a quitarles 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 dividir la clase Zinfandel en dos clases de zinfandel
-zinfandel blanco y zinfandel rojo- y clasificarlos como subclases de vino rosado y vino tinto
respectivamente.
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 clase Camarones, y
luego cambiarle el nombre a Camarones - la clase sigue representando el mismo concepto. Las
combinaciones apropiadas de vino que se refieren a los platos de camarones deben referirse a los platos
de camarones. En términos más prácticos, siempre se debe seguir la siguiente regla:

Los sinónimos de un mismo concepto no representan clases diferentes

Los sinónimos son sólo nombres diferentes para un concepto o un término. Por lo tanto, no deberíamos
tener una clase llamada Camarones y una clase llamada Gambas, y, posiblemente, una clase llamada
Crevette. Más bien, hay una clase, llamada Camarón o Langostino. 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, los sinónimos siempre pueden aparecer en la documentación de la clase.

Evitar los ciclos de clases

Debemos evitar los ciclos en 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, puesto que B es una
subclase de A, todas las instancias de B deben ser instancias de la clase A. Puesto que A es una subclase
de B, todas las instancias de A deben ser también instancias de la clase B.

4.2 Analizar a los hermanos en una jerarquía de clases

Hermanos en una jerarquía de clases

Los hermanos en la jerarquía son clases que son subclases directas de la misma clase (ver Sección 4.1).

Todos los hermanos en la jerarquía (excepto los de la raíz) deben estar en el mismo nivel de
generalidad.

Por ejemplo, el vino blanco y el Chardonnay no deben ser subclases de la misma clase (por ejemplo,
Vino). El vino blanco es un concepto más general que el Chardonnay. 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 un esquema de libro.

Sin embargo, los conceptos en la raíz de la jerarquía (que a menudo se representan como subclases
directas de algunas clases muy generales, como Thing) representan divisiones importantes del dominio
y no tienen por qué ser conceptos similares.
¿Cuántos son demasiados y cuántos son pocos?

No hay reglas estrictas para el número 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,
las dos directrices siguientes:

Si una clase tiene sólo 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, puede ser necesario establecer
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 sólo un punto. Por ejemplo, la mayoría de los vinos tintos de Borgoña son
vinos de Côtes d'Or. Supongamos que quisiéramos representar sólo este tipo mayoritario de vinos de
Borgoña. Podríamos crear una clase Borgoña Roja y luego una sola subclase Cotes d'Or (Figura 6a).
Sin embargo, si en nuestra representación los vinos tintos de Borgoña y de 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), la creación de la clase Cotes d'Or no es necesaria y
no añade ninguna información nueva a la representación. Si incluyéramos los vinos de Côtes
Chalonnaise, que son vinos de Borgoña más baratos de la región al sur de Côtes d'Or, entonces
crearíamos dos subclases de la clase Borgoña: Cotes d'Or y Cotes Chalonnaise (Figura 6b).

Figura 6. Subclases de la clase Borgoña Roja. Tener una sola subclase de una clase generalmente indica
un problema en el modelado.

Supongamos ahora que enumeramos todos los tipos de vinos como subclases directas de la clase Vino.
Esta lista incluiría tipos de vino más generales como el Beaujolais y el Bordeaux, así como tipos más
específicos como el Paulliac y el Margaux (Figura 7a). La clase Vino tiene demasiadas subclases
directas y, de hecho, para que la ontología refleje los diferentes tipos de vino de una manera más
organizada, Medoc debería ser una subclase de Burdeos y Cotes d'Or debería ser una subclase de
Borgoña. Tener también categorías intermedias como el vino tinto y el vino blanco también reflejaría el
modelo conceptual del dominio de los vinos que mucha gente tiene (Figura 7b).

Sin embargo, si no existen clases naturales para agrupar conceptos en la larga lista de hermanos, no hay
necesidad de crear clases artificiales - simplemente dejar las clases como están. Después de todo, la
ontología es un reflejo del mundo real, y si no existe categorización en el mundo real, entonces la
ontología debería reflejar eso.
Figura 7. Categorización de los vinos. Tener todos los vinos y tipos de vino frente a tener varios niveles
de categorización.

4.3 Herencia múltiple

La mayoría de los sistemas de representación del conocimiento permiten la herencia múltiple en 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, la clase de vinos de postre. El vino de Oporto es tanto un
vino tinto como un vino de postre[4] Por lo tanto, definimos un Oporto de clase para tener dos
superclases: Vino tinto y vino de postre. Todas las instancias de la clase Oporto serán instancias de la
clase de vino tinto y de la clase de vino de postre. La clase Port heredará sus slots y sus facetas de
ambos padres. Por lo tanto, heredará el valor SWEET para la ranura Sugar de la clase de vino Dessert y
la ranura de nivel de taninos y el valor para su ranura de color de la clase de vino tinto.
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 las ranuras. Sin embargo,
no es fácil encontrar el equilibrio adecuado.

Hay varias reglas generales que ayudan a decidir cuándo introducir nuevas clases en una jerarquía.

Las subclases de una clase suelen (1) tener propiedades adicionales que la superclase no tiene, o (2)
restricciones diferentes a las de la superclase, o (3) participar en relaciones diferentes a las de las
superclases.

Los vinos tintos pueden tener diferentes niveles de taninos, mientras que esta propiedad no se utiliza
para describir vinos en general. El valor de la franja azucarera del vino de postre es DULCE, mientras
que no es el caso de la superclase de la clase de vinos de postre. Los vinos Pinot Noir pueden ir bien
con los mariscos, mientras que otros vinos tintos no lo hacen. En otras palabras, introducimos una
nueva clase en la jerarquía normalmente sólo cuando hay algo que podemos decir sobre esta clase que
no podemos decir sobre la superclase.

En términos prácticos, cada subclase debería tener nuevas ranuras añadidas, 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 ninguna propiedad
nueva.

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 varias enfermedades. Esta clasificación puede ser sólo
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 fáciles y (2) permitirá al médico elegir fácilmente un nivel de
generalidad del término que sea apropiado para la situación.

Otra razón para introducir nuevas clases sin nuevas propiedades es modelar conceptos entre los cuales
los expertos en dominios comúnmente hacen una distinción aunque hayamos decidido no modelar la
distinción en sí misma. Dado que utilizamos ontologías para facilitar la comunicación entre expertos en
la materia y entre expertos en la materia y sistemas basados en el conocimiento, nos gustaría reflejar el
punto de vista del experto sobre el dominio en la ontología.

Por último, no debemos crear subclases de una clase por cada restricción adicional. Por ejemplo,
introdujimos las clases de vino tinto, vino blanco y vino rosado porque esta distinción es natural en el
mundo del vino. No introdujimos clases para vinos delicados, vinos moderados, 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 tenemos que decidir si modelar una distinción específica (como vino
blanco, tinto o rosado) como valor de propiedad o como un conjunto de clases depende del alcance del
dominio y de la tarea a realizar.

¿Creamos un vino blanco de la clase o simplemente creamos un vino de la clase Wine y rellenamos
diferentes valores para el color de la ranura? La respuesta suele estar en el alcance que hemos definido
para la ontología. ¿Qué importancia tiene el concepto de vino blanco en nuestro ámbito? Si los vinos
tienen una importancia marginal en el dominio y el hecho de que el vino sea o no blanco no tiene
ninguna implicación particular en 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, y así sucesivamente. Del mismo modo, el color del vino es
importante para la base de conocimiento de los vinos que podemos utilizar para determinar el orden de
degustación de los mismos. Así, creamos una clase separada para el vino blanco.

Si los conceptos con diferentes valores de ranura se convierten en restricciones para diferentes ranuras
en otras clases, entonces debemos crear una nueva clase para la distinción. De lo contrario,
representamos la distinción en un valor de la ranura.

Del mismo modo, nuestra ontología vitivinícola tiene clases como Merlot Tinto y Merlot Blanco, en
lugar de una sola clase para todos los vinos Merlot: los Merlot tintos y los Merlot 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 las posibles instancias individuales 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 debería cambiar con frecuencia.

Usualmente cuando usamos propiedades extrínsecas en lugar de propiedades intrínsecas de los

conceptos para diferenciar entre clases, las instancias de esas clases tendrán que migrar frecuentemente
de una clase a otra. Por ejemplo, el vino frío no debería ser una clase de una ontología que describe las
botellas de vino en un restaurante. La propiedad chilled debería ser simplemente un atributo del vino en
una botella, ya que una instancia de Chilled wine puede dejar de ser fácilmente una instancia de esta
clase y volver a ser una instancia de esta clase.

Normalmente los números, los colores, las ubicaciones son valores de ranura y no causan la creación de
nuevas clases. El vino, sin embargo, es una excepción notable ya que el color del vino es tan importante
para la descripción del vino.
Para otro ejemplo, considere la ontología de anatomía humana. Cuando representamos costillas,
¿creamos una clase para cada una de las "1ª costilla izquierda", "2ª costilla izquierda", etc.? 5] Si la
información sobre cada una de las costillas que representamos en la ontología es significativamente
diferente, entonces deberíamos crear una clase para cada una de las costillas. Es decir, si queremos
representar los detalles de adyacencia e información de ubicación (que es diferente para cada costilla),
así como las funciones específicas que cada costilla y órganos que protege, queremos las clases. Si
estamos modelando la anatomía a un nivel ligeramente inferior de generalidad, y todas las costillas son
muy similares en lo que se refiere a nuestras aplicaciones potenciales (sólo hablamos de qué costilla se
rompe en la radiografía sin implicaciones para otras partes del cuerpo), es posible que queramos
simplificar nuestra jerarquía y tener sólo la clase Rib, con dos ranuras: posición lateral, orden.

4.6 ¿Una instancia o una clase?

Decidir si un concepto en 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 dónde
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 se determina a su vez por una posible aplicación de la
ontología. En otras palabras, ¿cuáles son los elementos más específicos que se van a representar en la
base de conocimientos? Volviendo a las preguntas de competencia que identificamos en el Paso 1 de la
Sección 3, los conceptos más específicos que constituirán las respuestas a esas preguntas son muy
buenos candidatos para los individuos en la base de conocimientos.

Las instancias individuales son los conceptos más específicos representados en una base de
conocimientos.

Por ejemplo, si sólo vamos a hablar de maridar el vino con la comida, no nos interesarán las botellas de
vino físicas específicas. Por lo tanto, términos como Sterling Vineyards Merlot son probablemente los
términos más específicos que usamos. Por lo tanto, Sterling Vineyards Merlot sería un ejemplo en la
base de conocimientos.

Por otro lado, si queremos mantener un inventario de vinos en el restaurante además de la base de
conocimientos de los buenos maridajes de vino y comida, las botellas individuales de cada vino pueden
convertirse en instancias individuales en nuestra base de conocimientos.

Del mismo modo, si queremos registrar diferentes propiedades para cada cosecha específica de Sterling
Vineyards Merlot, entonces la cosecha específica del vino es una instancia en una base de conocimiento
y Sterling Vineyards Merlot es una clase que contiene instancias para todas sus cosechas.

Otra regla puede "mover" algunas instancias individuales al conjunto de clases:

Si los conceptos forman una jerarquía natural, entonces debemos representarlos como clases

Considere las regiones vinícolas. Inicialmente, podemos definir las principales regiones vinícolas,
como Francia, Estados Unidos, Alemania, etc., como clases y regiones vinícolas específicas dentro de
estas grandes regiones como ejemplos. Por ejemplo, la región de Bourgogne es un ejemplo de la clase
de región francesa. Sin embargo, también nos gustaría decir que la región de Cotes d'Or es una región
de Borgoña. Por lo tanto, la región de Bourgogne debe ser una clase (para tener subclases o instancias).
Sin embargo, hacer de la región de Bourgogne una clase y de la región de Cotes d'Or un ejemplo de la
región de Bourgogne parece arbitrario: es muy difícil distinguir claramente qué regiones son clases y
cuáles son ejemplos. Por lo tanto, definimos todas las regiones vitivinícolas como clases. Protégé-2000
permite a los usuarios especificar algunas clases como Abstract, lo que significa que la clase no puede
tener ninguna instancia directa. En nuestro caso, todas las clases regionales son abstractas (Figura 8).

Figura 8. Jerarquía de las regiones vitivinícolas. Los iconos "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" en los nombres de las
clases. No podemos decir que la clase Alsacia sea una subclase de la clase Francia: Alsacia no es una
especie de Francia. Sin embargo, la región de Alsacia es una especie de región francesa.

Sólo las clases pueden organizarse en una jerarquía: los sistemas de representación del conocimiento no
tienen una noción de substancia. 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 ámbito de aplicación

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 una definición de 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 extra en cada
dirección).

Para nuestro ejemplo de vino y comida, no necesitamos saber qué papel se usa para las etiquetas o
cómo cocinar platos de camarones.
Del mismo modo, la ontología no debe contener todas las posibles propiedades y distinciones entre las
clases de la jerarquía.

En nuestra ontología, ciertamente no incluimos todas las propiedades que un vino o un alimento puede
tener. Representamos las propiedades más destacadas de las clases de ítems de nuestra ontología.
Aunque los libros de vino nos dirían el tamaño de las uvas, no hemos incluido este conocimiento. Del
mismo modo, no hemos añadido todas las relaciones que uno podría imaginar entre todos los términos
de nuestro sistema. Por ejemplo, no incluimos relaciones como vino y comida favoritos en la ontología
sólo 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 de organismos biológicos. También contendrá el concepto de un
Experimentador realizando un experimento (con su nombre, afiliación, etc.). Es cierto que un
experimentador, como persona, también resulta ser 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 experimentadores mismos. Si estuviéramos representando todo lo que podemos
decir sobre las clases en la ontología, un Experimentador se convertiría en una subclase del Organismo
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 realmente duele: ahora una
instancia de un Experimentador tendrá espacios para el peso, la edad, las especies y otros datos
relativos a 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 examinarán esta ontología y que pueden no estar al tanto de la aplicación
que teníamos en mente.

4.8 Subclases disociadas

Muchos sistemas nos permiten especificar explícitamente que varias clases son inconexas. Las clases
son disociativas si no pueden tener ninguna instancia en común. Por ejemplo, las clases de vino de
postre y de vino blanco en nuestra ontología no son disímiles: hay muchos vinos que son ejemplos de
ambos. El Riesling Rothermel Trochenbierenauslese de la clase Riesling Dulce es un ejemplo de ello.
Al mismo tiempo, las clases de vino tinto y de vino blanco son disímiles: ningún vino puede ser
simultáneamente tinto y blanco. Especificar que las clases son disociadas permite al sistema validar
mejor la ontología. Si declaramos que las clases de vino tinto y blanco son disociadas y luego creamos
una clase que es una subclase tanto de Riesling (una subclase de vino blanco) como de Oporto (una
subclase de vino 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 cuando se definen los espacios en la
ontología (Paso 5 y Paso 6 en la Sección 3). Principalmente, discutimos las ranuras inversas y los
valores por defecto para una ranura.

5.1 Ranuras inversas

El valor de una ranura puede depender del valor de otra ranura. Por ejemplo, si un vino fue producido
por una bodega, entonces la bodega produce ese vino. Estas dos relaciones, fabricante y productor, se
llaman relaciones inversas. El almacenamiento de la información "en ambas direcciones" es
redundante. Cuando sabemos que un vino es producido por una bodega, una aplicación que utiliza la
base de conocimiento siempre puede inferir el valor de la relación inversa que la bodega produce el
vino. Sin embargo, desde la perspectiva de la adquisición de conocimientos es conveniente tener ambas
informaciones explícitamente disponibles. Este enfoque permite a los usuarios rellenar el vino en un
caso y la bodega en otro... El sistema de adquisición de conocimientos podría entonces completar
automáticamente el valor de la relación inversa asegurando la consistencia de la base de conocimientos.

Nuestro ejemplo tiene un par de ranuras inversas: la ranura del fabricante de la clase Vino y la ranura
del productor de la clase Bodega. Cuando un usuario crea una instancia de la clase Wine y rellena el
valor de la ranura del fabricante, el sistema añade automáticamente la instancia recién creada a la
ranura de producción de la correspondiente instancia de Bodega. Por ejemplo, cuando decimos que
Sterling Merlot es producido por la bodega Sterling Vineyard, el sistema automáticamente agregaría
Sterling Merlot a la lista de vinos que produce la bodega Sterling Vineyard. (Figura 9).

Figura 9. Instancias con ranuras inversas. La ranura que se produce para la clase Bodega es la inversa
de la que se produce para la clase Vino. Al rellenar una de las casillas se activa una actualización
automática de la otra.

5.2 Valores por defecto

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

Por ejemplo, si la mayoría de los vinos que vamos a discutir son vinos con mucho cuerpo, podemos
tener "lleno" como valor por defecto para el cuerpo del vino. Entonces, a menos que digamos lo
contrario, todos los vinos que definimos tendrían mucho cuerpo.

Tenga en cuenta que esto es diferente de los valores de la ranura. Los valores de la ranura no se pueden
cambiar. Por ejemplo, podemos decir que el azúcar de ranura tiene un valor DULCE para la clase de
vino de postre. Entonces todas las subclases e instancias de la clase de vinos de postre tendrán el valor
DULCE para el azúcar de ranura. Este valor no puede ser cambiado 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 sólo 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 los conceptos. A
menudo no hay ninguna razón en particular para elegir una u otra alternativa. Sin embargo, necesitamos

Defina una convención de nomenclatura para clases y slots y adhiérase a ella.

Las siguientes características de un sistema de representación del conocimiento afectan a la elección de

las convenciones para fijar nombres:

- ¿Tiene el sistema el mismo espacio de nombres para clases, slots e instancias? Es decir, ¿permite el
sistema tener una clase y una ranura con el mismo nombre (como una bodega de clase y una bodega de
ranura)?

- ¿El sistema distingue entre mayúsculas y minúsculas? Es decir, ¿trata el sistema los nombres que
difieren sólo en caso de que sean diferentes (como Bodega y Bodega)?

- ¿Qué delimitadores permite el sistema en los nombres? Es decir, ¿pueden los nombres contener
espacios, comas, asteriscos, etc.?

Protégé-2000, por ejemplo, mantiene un único espacio de nombres para todas sus tramas. Se distingue
entre mayúsculas y minúsculas. Por lo tanto, no podemos tener una bodega de clase y una bodega de
slot. Podemos, sin embargo, tener una Bodega de clase (no la mayúscula) y una bodega de slot.
CLASSIC, por otro lado, no distingue entre mayúsculas y minúsculas y mantiene diferentes espacios de
nombres para clases, slots e individuos. Por lo tanto, desde una perspectiva de sistema, no hay ningún
problema en nombrar tanto una clase como una bodega de slot.
6.1 Capitalización y delimitadores

En primer lugar, podemos mejorar enormemente la legibilidad de una ontología si utilizamos

mayúsculas y minúsculas para los nombres de los conceptos. Por ejemplo, es común poner en
mayúsculas los nombres de clase y usar minúsculas para los nombres de ranura (suponiendo que el
sistema distingue entre mayúsculas y minúsculas).

Cuando el nombre de un concepto contiene más de una palabra (como curso de comida) necesitamos
delimitar las palabras. Aquí hay algunas opciones posibles.

- Usa el espacio: Curso de comida (muchos sistemas, incluyendo Protégé, permiten espacios en los
nombres de los conceptos).

- Ejecute las palabras juntas y escriba en mayúsculas cada palabra nueva: MealCourse

- Utilice un guión bajo o guión u otro delimitador en el nombre: Meal_Course, Meal_course, Meal-
Course, Meal-Course, Meal-course. (Si utiliza delimitadores, también tendrá que decidir si cada nueva
palabra está en mayúsculas o no).

Si el sistema de representación del conocimiento permite espacios en los nombres, su uso 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 pueda interactuar. Si esos sistemas no utilizan
espacios o si su medio de presentación no maneja bien los espacios, puede ser útil utilizar otro método.

6.2 Singular o plural

Un nombre de clase representa una colección de objetos. Por ejemplo, una clase Wine representa
realmente todos los vinos. Por lo tanto, podría ser más natural para algunos diseñadores llamar a la
clase Wines en lugar de Wine. Ninguna alternativa es mejor o peor que la otra (aunque el singular para
los nombres de las clases se utiliza con más frecuencia en la práctica). Sin embargo, cualquiera que sea
la elección, debe ser coherente en toda la ontología. Algunos sistemas incluso requieren que sus
usuarios declaren de antemano si van a usar singular o plural para los nombres de concepto y no les
permiten desviarse de esa elección.

El uso de la misma forma todo el tiempo también evita que un diseñador cometa errores de modelado
como crear una clase Vinos y luego crear una clase Vino como su subclase (ver Sección 4.1).

6.3 Convenciones de prefijo y sufijo

Algunas metodologías de base de conocimiento sugieren el uso de convenciones de prefijos y sufijos

en los nombres para distinguir entre clases y slots. Dos prácticas comunes son añadir un hast-o un
sufijo-de a los nombres de las tragaperras. Así, nuestras ranuras se convierten en has-maker y has-
winery si elegimos la convención has-. Las tragamonedas se convierten en creadoras y vendedoras de
vino si elegimos la convención. Este enfoque permite a cualquiera que observe un término determinar
inmediatamente si el término es una clase o una franja horaria. Sin embargo, los nombres de los
términos se vuelven un poco más largos.
6.4 Otras consideraciones de denominación

A continuación se presentan algunas cosas más que se deben tener en cuenta al definir las convenciones
para fijar nombres:

- No añada cadenas como "class", "property", "slot", etc. a los nombres de los conceptos.

Siempre está claro en el contexto si el concepto es una clase o una ranura, por ejemplo. Además, se
utilizan diferentes convenciones para fijar nombres para las clases y las franjas horarias (por ejemplo,
capitalización y no capitalización, respectivamente), el nombre en sí mismo sería indicativo de lo que
es el concepto.

- Por lo general, es una buena idea evitar abreviaturas en los nombres de los conceptos (es decir,
utilizar Cabernet Sauvignon en lugar de Cab).

- Los nombres de las subclases directas de una clase deben incluir o no el nombre de la superclase. Por
ejemplo, si estamos creando dos subclases de la clase Vino para representar vinos tintos y blancos, los
dos nombres de las subclases deberían ser Vino Tinto y Vino Blanco o Vino Tinto y Blanco, pero no
Vino Tinto y Blanco.

7 Otros recursos

Hemos utilizado Protégé-2000 como un entorno de desarrollo ontológico para nuestros ejemplos.
Duineveld y sus colegas (Duineveld et al. 2000) describen y comparan una serie de otros entornos de
desarrollo ontológico.

Hemos tratado de abordar los aspectos básicos del desarrollo de la ontología y no hemos discutido
muchos de los temas avanzados o metodologías alternativas para el desarrollo de la ontología. Gómez-
Pérez (Gómez-Pérez 1998) y Uschold (Uschold y Gruninger 1996) presentan metodologías alternativas
de desarrollo ontológico. El tutorial de Ontolingua (Farquhar 1997) discute algunos aspectos formales
del modelado del conocimiento.

Actualmente, los investigadores enfatizan no sólo el desarrollo ontológico, sino también el análisis
ontológico. A medida que se generen y reutilicen más ontologías, se dispondrá de más herramientas
para analizar ontologías. Por ejemplo, Chimaera (McGuinness et al. 2000) proporciona herramientas de
diagnóstico para el análisis de ontologías. El análisis que Chimaera realiza incluye tanto la
comprobación de la corrección lógica de una ontología como el diagnóstico de errores comunes de
diseño ontológico. Un diseñador de ontología puede querer realizar diagnósticos de Quimera sobre la
ontología en evolución para determinar la conformidad con las prácticas comunes de modelado de
ontología.

8 Conclusiones

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

Agradecimientos

Protégé-2000 (http://protege.stanford.edu) fue desarrollado por el grupo de Mark Musen en Stanford

Medical Informatics. Generamos algunas de las figuras con el plugin de OntoViz para Protégé-2000.
Importamos la versión inicial de la ontología del vino de la biblioteca de ontología de Ontolingua
(http://www.ksl.stanford.edu/software/ontolingua/) que a su vez utilizó una versión publicada por
Brachman y sus colegas (Brachman et al. 1991) y distribuida con el sistema de representación del
conocimiento CLASSIC. Luego modificamos la ontología para presentar los principios del modelado
conceptual para las ontologías basadas en marcos declarativos. Los extensos comentarios de Ray
Fergerson y Mor Peleg sobre borradores anteriores mejoraron enormemente este documento.