1. Desarrollo de Ontolog´
ıas-101: Gu´ Para Crear Tu Primera
ıa
Ontolog´ıa
Natalya F. Noy and Deborah L. McGuinness
noy@smi.stanford.edu and dlm@ksl.stanford.edu
Stanford University, Stanford, CA, 94305
Traducido del ingl´s por: Erick Antezana∗
e
September 19, 2005
∗
erant@psb.ugent.be
1

2. Contents
1 ¿Por qu´ desarrollar una ontolog´
e ıa? 3
2 ¿Qu´ es una ontolog´
e ıa? 5
3 Una simple metodolog´ de ingenier´ del conocimiento
ıa ıa 6
4 Definici´n de las clases y de la jerarqu´ de clases
o ıa 15
4.1 Asegurarse que la jerarqu´ de clases es correcta . .
ıa . . . . . . . . . . . . . . . . 15
4.2 An´lisis de clases hermanas en la jerarqu´ de clases
a ıa . . . . . . . . . . . . . . . . 17
4.3 Herencia m´ltiple . . . . . . . . . . . . . . . . . . . .
u . . . . . . . . . . . . . . . . 18
4.4 ¿Cu´ndo introducir (o no) una nueva clase? . . . . .
a . . . . . . . . . . . . . . . . 18
4.5 ¿Una nueva clase o un valor de propiedad? . . . . . . . . . . . . . . . . . . . . . . 20
4.6 ¿Una instancia o una clase? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.7 Limitaci´n del alcance . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . . . . . 23
4.8 Subclases disjuntas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Definici´n de las propiedades (m´s detalles)
o a 24
5.1 Slots inversos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Valores por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6 ¿Qu´ est´ en un nombre?
e a 24
6.1 May´sculas/min´sculas y delimitadores
u u . . . . . . . . . . . . . . . . . . . . . . . 26
6.2 Singular o Plural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.3 Convenios: prefijos y sufijos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4 Otras consideraciones de nombrado . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7 Otros recursos 27
8 Conclusiones 27
9 Agradecimientos 28
2

3. 1 ¿Por qu´ desarrollar una ontolog´
e ıa?
En los ultimos a˜os el desarrollo de ontolog´ (especificaciones formales y especificas de los
´ n ıas
t´rminos y relaciones entre ellos (Gruber 1993)) ha estado movi´ndose del dominio de los lab-
e e
oratorios de Inteligencia Artificial a los escritorios de los expertos de un dominio dado. Las
ontolog´ has llegado a ser comunes en el World-Wide Web. Las ontolog´ en el Web van
ıas ıas
desde grades taxonom´ que categorizan sitios Web (tales como en Yahoo!) a categoriza-
ıas
ciones de productos para vender y sus caracter´ ısticas (tales como Amazon.com). El Consorcio
WWW (W3C) est´ desarrollando el Resource Description Framework (Brickley y Guha 1999),
a
un lenguaje para codificar conocimiento en p´ginas Web para hacerlas entendibles a los agentes
a
electr´nicos que buscan informaci´n. La agencia de proyectos de investigaci´n avanzada en de-
o o o
fensa (Defense Advanced Research Projects Agency (DARPA)), conjuntamente con el W3C, est´ a
desarrollando DARPA Agent Markup Language (DAML) extendiendo RDF con construcciones
m´s expresivas buscando facilitar la interacci´n de agentes en el Web (Hendler and McGuinness
a o
2000). Muchas disciplinas desarrollan ahora ontolog´ estandarizadas que los expertos de cier-
ıas
tos dominios pueden usarlas para compartir y anotar informaci´n en sus campos de trabajo. En
o
medicina, por ejemplo, se ha producido grandes, estandarizados y estructurados vocabularios
tales como snomed (Price and Spackman 2000) y la red sem´ntica Unified Medical Language
a
System (Humphreys and Lindberg 1993). Est´n tambi´n surgiendo otras ontolog´ amplias y
a e ıas
de prop´sito general. Por ejemplo, el programa de desarrollo de las naciones unidas (United Na-
o
tions Development Program) y Dun & Bradstreet unieron esfuerzos para desarrollar la ontolog´ ıa
UNSPSC que provee terminolog´ para productos y servicios (www.unspsc.org).
ıa
Una ontolog´ define un vocabulario comun para investigadores que necesitan compartir
ıa
informaci´n en un dominio. Ella contiene definiciones de conceptos basicos y sus relaciones que
o
pueden ser interpretadas por una maquina.
¿Por qu´ alguien desear´ desarrollar una ontolog´ Algunas de las razones son:
e ıa ıa?
• Compartir el entendimiento com´n de la estructura de informaci´n entre personas o
u o
agentes de software.
• Permitir la reutilizaci´n de conocimiento de un dominio.
o
• Explicitar suposiciones de un dominio.
• Separar el conocimiento del dominio del conocimiento operacional.
• Analizar el conocimiento de un dominio.
Compartir el entendimiento com´n de la estructura de informaci´n entre personas y agentes
u o
de software es una de las m´s importantes metas al desarrollar ontolog´ (Musen 1992; Gruber
a ıas
1993). Por ejemplo, supongamos que varios distintos sitios Web contengan informaci´n m´dica
o e
o provean servicios de e-commerce m´dico. Si esos sitios Web comparten y publican la misma
e
ontolog´ subyacente de los t´rminos que usan, entonces agentes de software podr´ extraen
ıa e ıan
y agregar informaci´n de eso esos sitios diferentes. Los agentes podr´ usar esta informaci´n
o ıan o
agregada para responder solicitudes de los usuarios o servir como datos de entrada a otras
aplicaciones.
Permitir la reutilizaci´n de conocimiento de un dominio fue una de las fuerzas conduc-
o
toras detr´s recientes trabajos en la investigaci´n sobre ontolog´
a o ıas. Por ejemplo, modelos para
diferentes dominios necesitan representar la noci´n de tiempo. Esta representaci´n incluye las
o o
nociones de intervalo de tiempos, puntos en el tiempo, medidas relativas de tiempo, y cosas
por el estilo. Si un grupo de investigadores desarrollo tal ontolog´ en detalle, otros podrian
ıa
simplemente reusarla en sus dominios. Ademas, si necesitamos construir una ontolog´ grande,
ıa
3

4. podemos integrar varias ontolog´ existentes que describen porciones del dominio mas grande.
ıas
Tambi´n podemos reusar una ontolog´ general, tal como la ontolog´ UNSPSC, y extenderla
e ıa ıa
para describir nuestro dominio de inter´s. e
La explicitaci´n de suposiciones de un dominio, que subyacen bajo una implementaci´n,
o o
permite cambiar esas suposiciones f´cilmente si el conocimiento del dominio cambia. Suposi-
a
ciones codificadas expl´ ıcitamente acerca del mundo en alg´n lenguaje de programaci´n hacen
u o
que las suposiciones no solo sean dif´ ıciles de hallar sino tambi´n dificiles de cambiar, en par-
e
ticular para alguien sin competencias en programaci´n. Adem´s, las especificaciones explicitas
o a
del dominio de conocimiento son utiles para nuevos usuarios que deben aprender el significado
´
de los t´rminos del dominio.
e
La separaci´n del conocimiento del dominio del conocimiento operacional es otro uso com´n
o u
de las ontolog´ıas. Podemos describir la tarea de configuraci´n de un producto a partir de sus
o
componentes de acuerdo a especificaciones requeridas e implementar un programa que hace in-
dependiente esta configuraci´n de los productos y componentes en s´ (McGuinness and Wright
o ı
1998). Podemos desarrollar una ontolog´ de componentes de PC y caracter´
ıa ısticas y aplicar el
algoritmo para configurar PCs ordenadas a medida. Podemos usar el mismo algoritmo para con-
figurar elevadores si “alimentamos” nuestra ontolog´ con elevador como componente (Rothen-
ıa
fluh et al. 1996).
Analizar el conocimiento de un dominio es posible una vez que una especificaci´n declarativa
o
de los t´rminos esta disponible. El an´lisis formal de los t´rminos es extremadamente valioso
e a e
al intentar reusar ontolog´ existentes y al extenderlas (McGuinness et al. 2000).
ıas
A menudo, desarrollar una ontolog´ de un dominio no es la meta en s´ Desarrollar una
ıa ı.
ontolog´ es comparable a definir un conjunto de datos y sus estructuras para que otros pro-
ıa
gramas los usen. M´todos de resuelven problemas, aplicaciones independientes del dominio, y
e
agentes de software usan ontolog´ y bases de conocimiento construidos a partir de ontolog´
ıas ıas
como datos. Por ejemplo, en esta publicaci´n desarrollamos una ontolog´ de vinos y alimentos
o ıa
y de combinaciones apropiadas de vino con comidas. Esta ontolog´ entonces puede ser usada
ıa
como una base para aplicaciones como parte un las herramientas de gesti´n de un restaurante:
o
Una aplicaci´n podr´ crear sugerencias de vino para el men´ del d´ o responder a solicitudes
o ıa u ıa
de camareros y clientes. otra aplicaci´n podr´ analizar una lista de inventario de una bodega
o ıa
de vino y sugerir que categor´ de vino ampliar y que vinos particulares comprar para men´s
ıas u
futuros o recetarios.
Acerca de esta gu´
ıa
Nos basamos en nuestra experiencia usando Prot´g´-2000 (Protege 2000), Ontolingua (On-
e e
tolingua 1997), Chimaera (Chimaera 2000) como entornos de edici´n de ontolog´
o ıas. En esta
gu´ usamos Prot´g´-2000 para nuestros ejemplos.
ıa, e e
El ejemplo de vinos y alimentos que usamos a lo largo de esta gu´ est´ aproximadamente
ıa a
basado en un ejemplo de base de conocimiento presentada en la publicaci´n que describe CLAS-
o
SIC (un sistema de representaci´n de conocimiento basado en l´gicas de descripci´n (Brachman
o o o
et al. 1991)). El tutorial de CLASSIC (McGuinness et al. 1994) ha desarrollado este ejemplo
ulteriormente. Prot´g´-2000 y otros sistemas basados en marcos describen las ontolog´ declar-
e e ıas
ativamente, estableciendo explicitamente cual es la jerarqu´ de clases y a que clases individuales
ıa
pertenecen.
Algunas ideas de dise˜o de ontolog´ en esta gu´ se originaron a partir de la literatura sobre
n ıas ıa
dise˜o orientado a objetos (Rumbaugh et al. 1991; Booch et al. 1997). Sin embargo, el desarrollo
n
de ontolog´ es diferente a dise˜o de clases y relaciones como en la programaci´n orientada a
ıas n o
objetos. La programaci´n orientada a objetos se centra principalmente alrededor de m´todos en
o e
clases - un programador toma decisiones de dise˜o bas´ndose en las propiedades operacionales
n a
4

5. de una clase, mientras que un dise˜ador de ontolog´ toma esas decisiones bas´ndose en las
n ıas a
propiedades estructurales de una clase. En consecuencia, la estructura de una clase y las
relaciones entre clases en una ontolog´ son diferentes de la estructura para un dominio similar
ıa
en un programa orientado a objetos.
Es imposible cubrir todos los aspectos que un desarrollador de ontolog´ pueda necesitar
ıas
para trabajar y no estamos tratando de responderlos en esta gu´ En cambio, tratamos de
ıa.
proveer un punto de inicio; una gu´ inicial que ayude a los nuevos dise˜adores de ontolog´ a
ıa n ıas
desarrollar ontolog´ Al final, sugerimos lugares para buscar explicaciones sobre estructuras y
ıas.
mecanismos de dise˜o m´s complicados si el dominio los requiere.
n a
Finalmente, no hay una simple y correcta metodolog´ de dise˜o de ontolog´ y no intenta-
ıa n ıas
mos definir una. Las ideas que presentamos aqui son las que encontramos utiles dentro nuestra
´
experiencia de desarrollo de ontolog´ıas. Al final de esta gu´ sugerimos una lista de referencias
ıa
de metodolog´ alternativas.
ıas
2 ¿Qu´ es una ontolog´
e ıa?
La literatura de inteligencia artificial contiene varias definiciones de ontolog´ muchas de el-
ıa;
las contradicen otras. Para los prop´sitos de esta gu´ una ontolog´ es una descripci´n ex-
o ıa ıa o
plicita y formal de conceptos en un dominio de discurso (clases (a veces llamadas conceptos)),
propiedades de cada concepto describiendo varias caracter´ ısticas y atributos del concepto (slots
(a veces llamados roles o propiedades)), y restricciones sobre los slots (facetas (algunas ve-
ces llamados restricciones de rol)). Una ontolog´ junto con un conjunto de individuos de
ıa
clases constituye una base de conocimiento. En realidad, hay una linea muy delgada donde
la ontolog´ termina y la base de conocimiento empieza.
ıa
Las clases son el centro de la mayor´ de las ontolog´
ıa ıas. Las clases describen conceptos
de un dominio. Por ejemplo, una clase de vinos representa todos lo vinos. Vinos espec´ ıficos
son instancias de esta clase. El vino Bordeaux en un vaso en frente tuyo mientras lees este
documento es una instancia de la clase de vinos Bordeaux. Una clase puede tener subclases
que representan conceptos que son mas espec´ ıficos que la superclase. Por ejemplo, podemos
dividir la clase de todos los vinos en vinos rojo, blanco, y rosado. Alternativamente, podemos
dividir la clase de todos los vinos en vinos efervescentes y no-efervescentes.
Los slots describen propiedades de clases e instancias: el vino Chteau Lafite Rothschild
Pauillac est´ muy bien detallado; es producido por el establecimiento vin´
a ıcola Chteau Lafite
Rothschild. Tenemos dos slots que describen el vino en este ejemplo: el slot cuerpo con el valor
total y el slot productor con el valor del establecimiento vin´ ıcola Chteau Lafite Rothschild. A
nivel de la clase, podemos decir que las instancias de la clase Vino tendran slots que describen
su sabor, cuerpo, nivel de az´car, el productor del vino, etc.1
u
Todas las instancias de la clase Vino, y su subclase Pauillac, tienen un slot productor cuyo
valor es una instancia de la clase Establecimiento vin´cola (Figura 1). Todas las instancias
ı
de la clase Establecimiento vin´cola tienen un slot produce que se refiere a todos los vinos
ı
(instancias de la clase Vino y sus subclases) que el establecimiento vin´ ıcola produce.
En t´rminos pr´cticos, desarrollar una ontolog´ incluye:
e a ıa
• definir clases en la ontolog´
ıa,
• organizar las clases en una jerarqu´ taxon´mica (subclase-superclase),
ıa o
• definir slots y describir valores permitidos para esos slots,
1
Los nombres de las clases comienzan con mayusculas y los nombres de los slots est´n en min´sculas. Usamos
a u
tambi´n la fuente de typewriter para todos los t´rminos del ejemplo de la ontolog´
e e ıa.
5

6. • llenar los valores de los slots para las instancias.
Podemos entonces crear una base de conocimientos definiendo las instancias individuales de
esas clases, precisando los valores especificos de los slots y restricciones adicionales sobre los
slots.
Figure 1: Algunas clases, instancias, y relaciones entre ellas en el dominio de vinos. Usamos
negro para las clases y rojo para las instancias. Los enlaces directos representan los slots y
enlaces internos tales como instancia-de y subclase-de.
3 Una simple metodolog´ de ingenier´ del conocimiento
ıa ıa
Como lo dijimos antes, no existe ni una sola forma o ni una sola metodolog´ “correcta” para
ıa
desarrollar ontolog´
ıas. Aqu´ abordamos los puntos generales que deben ser tomados en con-
ı
sideraci´n y ofrecemos uno de los procedimientos posibles para desarrollar una ontolog´ De-
o ıa.
scribimos un enfoque iterativo en el desarrollo de la ontolog´ comenzamos por abordar la
ıa:
ontolog´ de manera frontal. A continuaci´n volvemos sobre la ontolog´ que consideramos
ıa o ıa,
en proceso de evoluci´n, afin´ndola y conplet´ndola con detalles. A lo argo de este proceso
o a a
discutimos las decisiones de modelizaci´n que toma el dise˜ador, as´ como los pros, los contras
o n ı
y las implicaciones de diferentes soluciones.
Inicialmente, queremos enfatizar algunas reglas fundamentales e el dise˜o de ontolog´ a las
n ıas
cuales nos referiremos varias veces. Esas reglas pueden parecen algo dogm´ticas. Ellas pueden
a
ayudar, sin embargo, para tomar decisiones de dise˜o en muchos casos.
n
1. No hay una forma correcta de modelar un dominio - siempre hay alternativas viables. La
mejor soluci´n casi siempre depende de la aplicaci´n que tienes en mente y las extensiones
o o
que anticipas.
2. El desarrollo de ontolog´ es un proceso necesariamente iterativo.
ıas
3. Los conceptos en la ontolog´ deben ser cercanos a los objetos (f´
ıa ısicos o l´gicos) y relaciones
o
en tu dominio de inter´s. Esos son muy probablemente sustantivos (objetos) o verbos
e
(relaciones) en oraciones que describen tu dominio.
Es decir, decidir para que vamos a usar la ontolog´ y cu´n detallada o general ser´ la
ıa a a
ontolog´ guiar´ a muchas de las decisiones de modelamiento a lo largo del camino. Entre
ıa a
6

7. las varias alternativas viables, necesitaremos determinar cu´l funcionar´ mejor para la tarea
a a
proyectada, cu´l ser´ m´s intuitiva, m´s extensible y m´s mantenible. Necesitamos tambi´n
a a a a a e
recordar que una ontolog´ es un modelo de la realidad del mundo y los conceptos en la ontolog´
ıa ıa
deben reflejar esta realidad. Despu´s de que hayamos definido una versi´n inicial de la ontolog´
e o ıa,
podemos evaluarla y depurarla us´ndola en aplicaciones o m´todos que resuelvan problemas o
a e
discuti´ndola con expertos en el ´rea. En consecuencia, casi seguramente necesitaremos revisar
e a
la ontolog´ inicial. Este proceso de dise˜o iterativo probablemente continuara a trav´s del ciclo
ıa n e
de vida entero de la ontolog´ıa.
Paso 1. Determinar el domino y alcance de la ontolog´
ıa
Sugerimos comenzar el s=desarrollo de una ontolog´ definiendo su dominio y alcance. Es
ıa
decir, responder a varias preguntas b´sicas:
a
• ¿Cu´l es el dominio que la ontolog´ cubrir´?
a ıa a
• ¿Para qu´ usaremos la ontolog´
e ıa?
• ¿Para qu´ tipos de preguntas la informaci´n en la ontolog´ deber´ proveer respuestas?
e o ıa a
• ¿Qui´n usar´ y mantendr´ la ontolog´
e a a ıa?
Las respuestas a esas preguntas pueden cambiar durante el proceso del dise˜o de la ontolog´
n ıa,
pero en cualquier momento dado ellas ayudaran a limitar el alcance del modelo.
Consideremos la ontolog´ de vinos y alimentos que se introdujo antes. El dominio de
ıa
la ontolog´ es la representaci´n de alimentos y vinos. Planeamos usar esta ontolog´ en las
ıa o ıa
aplicaciones que sugieran buenas combinaciones de vinos y alimentos.
Naturalmente, los conceptos que describen diferentes tipos de vinos, tipos principales de
alimentos, la noci´n de una buena combinaci´n de vino y alimento y la mala combinaci´n figu-
o o o
raran en nuestra ontolog´ Al mismo tiempo, es improbable que la ontolog´ incluya conceptos
ıa. ıa
para gestionar inventarios en un establecimiento vin´ ıcola o empleados en un restaurante aunque
esos conceptos est´n de alguna manera relacionados a las nociones de vino y alimento.
a
Si la ontolog´ que estamos dise˜ando ser´ usada para ayudar en el procesamiento de lenguaje
ıa n a
natural de art´ ıculos en las tiendas de vino, seria importante incluir sin´nimos e informaci´n de
o o
las varias clases de palabras a las cuales una palabra puede ser asignada para los conceptos de
la ontolog´ Si la ontolog´ sera usada para ayudar a los clientes de un restaurante a decidir
ıa. ıa
qu´ vino ordenar, necesitamos incluir informaci´n del precio de venta al por menor. Si es usada
e o
por compradores de vino que almacenan el vino en bodegas, el precio de venta al por mayor y
la disponibilidad ser´n necesarios. Si la gente que mantendr´ la ontolog´ describe el dominio
a a ıa
en un lenguaje que es diferente del lenguaje que usan los usuarios de la ontolog´ tendremos
ıa,
que proveer el mapeo entre los lenguajes.
Preguntas de competencia.
Una de las formas de determinar el alcance de la ontolog´ es bosquejando una lista de de
ıa
preguntas que la base de conocimientos basada en la ontolog´ deber´ ser capaz de responder,
ıa ıa
preguntas de competencia (Gruninger and Fox 1995). Esas preguntas servir´n despu´s como
a e
prueba de control de calidad: ¿La ontolog´ contiene suficiente informaci´n para responder esos
ıa o
tipos de preguntas? ¿Las respuestas requieren un nivel particular de detalle o representaci´n de
o
un ´rea particular? Las preguntas de competencia son solamente un bosquejo y no necesitan
a
ser exhaustivas.
En el dominio de los vinos y alimentos, las siguientes preguntas son posibles preguntas de
competencia:
7

8. • ¿Qu´ caracter´
e ısticas debo considerar cuando elijo un vino?
• ¿Bordeaux es un vino rojo o blanco?
• ¿El Cabernet Sauvignon va bien con comida de mar?
• ¿Cu´l es la mejor elecci´n de vino para acompa˜ar carne asada?
a o n
• ¿Qu´ caracter´
e ısticas de un vino afectan su idoneidad con un pescado?
• ¿El cuerpo o aroma de un vino especifico cambia con su a˜o de cosecha?
n
• ¿Cu´les fueron buenas cosechas para el Napa Zinfandel?
a
Juzgando a partir de esta lista de preguntas, la ontolog´ incluir´ la informaci´n de varias
ıa a o
caracter´
ısticas de vinos y tipos de vinos, a˜os de cosechas (buenos y malos), clasificaci´n de
n o
alimentos que importan para elegir un vino apropiado, combinaciones recomendadas de vinos y
comidas.
Paso 2. Considerar la reutilizaci´n de ontolog´ existentes
o ıas
Casi siempre vale la pena considerar lo que otra persona ha hecho y verificar si podemos re-
finar y extender recursos existentes para nuestro dominio y tarea particular. Reusar ontolog´ ıas
existentes puede ser un requerimiento si nuestro sistema necesita interactuar con otras aplica-
ciones que ya se han dedicado a ontolog´ particulares o vocabularios controlados. Muchas
ıas
ontolog´ ya est´n disponibles en forma electr´nica y pueden ser importadas dentro un entorno
ıas a o
de desarrollo de ontolog´ que est´s usando. El formalismo en el cual una ontolog´ est´ ex-
ıas a ıa a
presado a menudo no interesa, puesto que muchos sistemas de representaci´n de conocimiento
o
pueden importar y exportar ontolog´ Aun si el sistema de representaci´n de conocimiento no
ıas. o
puede funcionar directamente con un formalismo particular, la tarea de traducir una ontolog´ ıa
a partir de un formalismo a otro no es usualmente dif´ ıcil.
Hay bibliotecas de ontolog´ reusables en la Web y en la literatura. Por ejemplo, podemos
ıas
usar la biblioteca de ontolog´ Ontolingua (http://www.ksl.stanford.edu/software/ontolingua/)
ıas
o la biblioteca de ontolog´ DAML (http://www.daml.org/ontologies/). Tambi´n hay un
ıas e
cierto n´mero de ontolog´ comerciales p´blicamente disponibles (e.g., UNSPSC (www.unspsc.
u ıas u
org), RosettaNet (www.rosettanet.org), DMOZ (www.dmoz.org)).
Por ejemplo, es posible que una base de conocimientos sobre vinos Franceses exista. Si
podemos importar esta base de conocimiento y la ontolog´ sobre la cual est´ basada, ten-
ıa a
dremos no solamente la clasificaci´n de vinos Franceses sino tambi´n el primero paso hacia la
o e
clasificaci´n de caracteristicas de vinos usadas para distinguir y describir los vinos. Es posible
o
que listas con las propiedades de los vinos esten disponibles en sitios Web comerciales tales
como www.wines.com que los clientes consideren utilies para comprar vinos.
´
En esta gu´ sin embargo, asumiremos que no existe ninguna ontolog´ relevante y comen-
ıa, ıa
zaremos la ontolog´ desde el principio.
ıa
Paso 3. Enumerar t´rminos importantes para la ontolog´
e ıa
Es util escribir una lista con todos los t´rminos con los que quisi´ramos hacer enunciados
´ e e
o dar explicaci´n a un usuario. ¿Cu´les con los t´rminos de los cuales quisi´ramos hablar?
o a e e
¿Qu´ propiedades tienen esos t´rminos? Por ejemplo, t´rminos importantes relativos a los
e e e
vinos incluir´n vino, cepaje, establecimiento vin´cola, localidad, color del vino, cuerpo,
a ı
sabor, contenido de az´car; diferentes tipos de alimentos, tales como pescado y carne roja;
u
8

9. subtipos de vino tales como vino blanco, etc. Inicialmente, es importante obtener una lista
integral de t´rminos sin preocuparse del recubrimiento entre los conceptos que representan,
e
relaciones entre los t´rminos, o cualquier propiedad que los conceptos puedan tener, o si los
e
conceptos son clases o slots.
Los siguientes dos pasos (desarrollando la jerarqu´ de clases y definiendo las propiedades de
ıa
los conceptos (slots)) est´n estrechamente relacionadas. Es dif´ hacer primero uno de ellos y
a ıcil
luego hacer el otro. T´ıpicamente, creamos unas cuantas definiciones de los conceptos en la jer-
arqu´ y luego continuamos describiendo las propiedades de esos conceptos y as´ sucesivamente.
ıa ı
Esos dos pasos son tambi´n los m´s importantes en el proceso de dise˜o de la ontolog´ Los
e a n ıa.
describiremos brevemente y dedicaremos las siguientes dos secciones a discutir los asuntos m´sa
complicados que necesitan ser considerados, peligros comunes, decisiones a tomar, etc.
Paso 4. Definir las clases y la jerarqu´ de clases
ıa
Hay varios posibles enfoques para desarrollar una jerarquia de clases (Uschold and Gruninger
1996):
• Un proceso de desarrollo top-down comienza con la definici´n de los conceptos m´s gen-
o a
erales en el dominio la subsecuente espicializaci´n de los conceptos. Por ejemplo, podemos
o
comenzar creando clases para los conceptos generales de Vino y Alimentos. Luego es-
pecializamos la clase Vino creando algunas de sus subclases: Vino blanco, Vino Rojo,
Vino rosado. Podemos posteriormente categorizar la clase Vino rojo en, por ejemplo,
Syrah, Borgo~a, Cabernet Sauvignon, etc.
n
• Un proceso de desarrollo bottom-up comienza con la definici´n de las clases mas especifi-
o
cas, las hojas de la jerarqu´ con el subsecuente agrupamiento de esas clases en conceptos
ıa,
m´s generales. Por ejemplo, comenzamos definiendo clases para los vinos Pauillac y
a
Margaux. Luego creamos una superclase com´n para esas dos clases (Medoc) la cual a su
u
vez es una subclase de Bordeaux.
• Un proceso de desarrollo combinado es el resultado de una combinacion de los enfoques
top-down y bottom-up: primero definimos los conceptos m´s sobresalientes y luego los
a
generalizamos y especializamos apropiadamente. Podr´ ıamos comenzar con unos cuan-
tos conceptos de nivel superior como Vino, y unos conceptos espec´ ıficos, como Margaux.
Podemos luego relacionarlos en un concepto de nivel medio, tal como Medoc. Podr´ ıamos
luego desear generar todas las clases de vino regional de Francia, generando en consecuen-
cia un cierto n´mero de conceptos de nivel medio.
u
La Figura 2 muestra una posible descomposici´n entre los diferentes niveles de generalidad.
o
Ninguno de esos tres m´todos es inherentemente mejor que cualquiera de los otros. El
e
enfoque a tomar depende fuertemente de la visi´n personal del dominio. Si un desarrollador
o
tiene una visi´n sistem´tica top-down del dominio, entonces ser´ m´s f´cil usar el enfoque
o a a a a
top-down. El enfoque combinado es a menudo es el m´s f´cil para muchos desarrolladores de
a a
ontolog´ puesto que los “conceptos del medio” tienden a ser conceptos m´s descriptivos en el
ıas, a
dominio (Rosch 1978).
Si tiendes a pensar en vinos distinguiendo primero la clasificaci´n m´s general, entonces
o a
el enfoque top-down podr´ funcionar mejor para ti. Si prefieres comenzar listando ejemplos
ıa
espec´ıficos, el enfoque bottom-up podr´ ser el m´s apropiado.
ıa a
Sea cual sea el enfoque que elijamos, usualmente comenzaremos definiendo las clases. De la
lista creada en el Paso 3, seleccionamos los t´rminos que describen objetos que tienen existencia
e
independiente en lugar de t´rminos que describen esos objetos. Esos t´rminos ser´n las clases
e e a
9

10. Figure 2: Los diferentes niveles de la taxonom´ de los Vinos: Vino (Wine), Vino rojo (Red
ıa
wine), Vino blanco (White wine), Vino rosado (Ros wine) son los conceptos m´s generales
a
(nivel superior (top level)). Pauillac y Margaux son las clases m´s espec´
a ıficas en la jerarqu´
ıa
(nivel inferior (bottom level)).
de la ontolog´ y llegar´n a ser anclas en la jerarqu´ de clases2 . Organizamos las clases en una
ıa a ıa
taxonom´ jer´quica preguntando si siendo una instancia de una clase, el objeto necesariamente
ıa a
ser´ (i.e., por definici´n) una instancia de alguna otra clase.
a o
Si una clase A es una superclase de la clase B, entonces cada instancia de B lo es tambi´n de
e
A.
En otras palabras, la clase B representa un concepto que es un “tipo de” A.
Por ejemplo, cada vino Pinot Noir es necesariamente un vino rojo. Por lo tanto, la clase
Pinot Noir es una subclase de la clase Vino Rojo.
La Figura 2 muestra una parte de la jerarqu´ de clases de la ontolog´ de Vinos. La secci´n
ıa ıa o
4 contiene una discusi´n detallada de algunos aspectos a considerar cuando se est´ definiendo
o a
una jerarqu´ de clases.
ıa
Paso 5. Definir las propiedades de las clases: slots
Las clases aisladas no proveer´n suficiente informaci´n para responder las preguntas de
a o
competencia del Paso 1. Una vez que hemos definido algunas de las clases, debemos describir
la estructura interna de los conceptos.
Ya hemos seleccionado clases de la lista de t´rminos creada en el Paso 3. La mayor´ de los
e ıa
t´rminos restantes son muy probablemente propiedades de esas clases. Esos t´rminos incluyen,
e e
2
Podemos tambi´n ver a las clases como predicados unarios: preguntas que tienen un argumento. Por ejemplo,
e
“¿Este objeto es un vino?” Los predicados unarios (o clases) se diferencian de los predicados binarios (o slots):
preguntas que tienen dos argumentos. Por ejemplo, “¿El sabor de este objeto es fuerte?” “¿Cu´l es el sabor de
a
este objeto?”
10

11. por ejemplo, un color de vino, cuerpo, sabor, contenido de az´car y localizaci´n de un
u o
establecimiento vin´
ıcola.
Para cada propiedad en la lista, debemos determinar qu´ clase es descrita por la propiedad.
e
Esas propiedades se convierten en slots adosados a las clases. De esta forma, la clase Vino
tendr´ los siguientes slots: color, sabor, y az´car. Y la clase Establecimiento vin´cola
a u ı
tendr´ un slot localizaci´n.
a o
En general, hay varios tipos de propiedades de objeto que pueden llegar a ser slots en una
ontolog´
ıa:
• propiedades “intr´
ınsecas” tales como el sabor de un vino;
• propiedades “extr´
ınsicas” tales como el nombre de un vino, y el ´rea de donde proviene;
a
• partes, si el objeto es estructurado; pueden ser “partes” f´
ısicas y abstractas (e.g., los platos
de una comida)
• relaciones con otros individuos; ´stas son las relaciones entre miembros individuales de
e
una clase y otros ´
ıtems (e.g., el productor de vino, representando una relaci’on entre un
vino y un establecimiento vin´ ıcola, y la uva con la cual el vino est´ producido.)
a
De esta forma, adem´s de las propiedades que hemos identificado previamente, necesitamos
a
a˜adir los siguientes slots a la clase Vino: nombre, ´rea, productor, cepaje. La Figura 3
n a
muestra los slots para la clase Vino.
Todas las subclases de una clase heredan los slots de esa clase. Por ejemplo, todos los slots
de la clase Vino ser´n heredados por todas las subclases de Vino, que incluyen Vino Rojo y
a
Vino Blanco. Agregaremos un slot adicional, nivel de tanino (bajo, moderado, o alto), a la
clase Vino Rojo. El slot nivel de tanino ser´ heredado por todas las clases que representan
a
vinos rojos (tales como Bordeaux y Beaujolais).
Un slot deber´ estar adosado a la clase m´s general que pueda tener esa propiedad. Por
a a
ejemplo, el cuerpo y color de un vino deber´n estar adosados a la clase Vino, puesto que ´sta
a e
es la clase m´s general cuyas instancias tendr´n un cuerpo y un color.
a a
Figure 3: Los diferentes niveles de la taxonom´ de Vinos: Vino (Wine), Vino rojo (Red wine),
ıa
Vino blanco (White wine), Vino rosado (Ros´ wine) son los conceptos m´s generales, el nivel
e a
superior. Pauillac y Margaux son las clases m´s espec´
a ıficas en la jerarqu´ el nivel inferior.
ıa,
Paso 6. Definir las facetas de los slots
Los slots puedes tener diferentes facetas que describen el tipo de valor, valores admitidos, el
n´mero de los valores (cardinalidad), y otras caracter´
u ısticas de los valores que los slots pueden
tomar. Por ejemplo, el valor del slot nombre (como en “el nombre de un vino”) es una cadena
11

12. de caracteres. Es decir, nombre es un slot con String como tipo de valor. El slot produce
(como en “un establecimiento vin´ ıcola produce tales vinos”) puede tener valores m´ltiples y los
u
valores son instancias de la clase Vino. Es decir, produce es un slot con Instance como tipo
de valor y Vino como clase admitida.
Describiremos ahora varias facetas comunes.
Cardinalidad del slot
La cardinalidad de un slot define cuantos valores un slot puede tener. Algunos sistemas
solamente distinguen entre cardinalidad simple (admitiendo a lo sumo un valor) y cardinalidad
m´ltiple (admitiendo cualquier cantidad de valores). Los vinos producidos por un establec-
u
imiento vin´ıcola particular completan el slop produce que es de cardinalidad m´ltiple para la
u
clase Establecimiento vin´cola.ı
Algunos sistemas admiten la especificaci´n de una cardinalidad m´
o ınima y m´xima para
a
describir la cantidad de valores de un slot con m´s precisi´n. Una cardinalidad m´
a o ınima N
significa que un slot debe tener al menos N valores. Por ejemplo, el slot cepaje de un Vino
tiene una cardinalidad m´ ınima de 1: cada vino esta hecho de al menos una variedad de uva. Una
cardinalidad m´xima M siginifica que un slot puede tener a lo sumo M valores. La cardinalidad
a
m´xima para el slot cepaje para vinos de simple variedad de uva es 1: esos vinos son hechos de
a
solamente una variedad de uva. Algunas veces puede ser util fijar la m´xima cardinalidad en 0.
´ a
Esta definici´n indicar´ que el slot no puede tener ning´n valor particular para una subclase
o ıa u
particular.
Tipo de valor de los slots
Una faceta tipo de valor describe qu´ tipos de valores pueden llenar el slot. Aqui est´ una
e a
lista de los tipos de valores m´s comunes:
a
• String es el tipo de valor m´s simple el cual es usado por slots tales como nombre: el
a
valor es una simple cadena de caracteres
• Number (algunas veces los tipos de valores Float e Integer son usados por ser m´s a
espec´
ıficos) describe slots con valores num´ricos. Por ejemplo, el precio que un vino
e
puede tener es un tipo de valor Float.
• Los slots del tipo Boolean son simples banderas si/no. Por ejemplo, si elegimos no
representar vinos espumantes como una clase separada, que el vino sea espumante o no,
puede ser representado como un valor de un slot Boolean: si el valor es “true” (“si”) el
vino es espumante y si el valor es “false” (“no”) el vino no es espumante.
• Los slots del tipo Enumerated especifican una lista espec´ ıfica de valores admitidos para
el slot. Por ejemplo, podemos especificar que slot sabor puede tomar uno de los siguientes
valores posibles: fuerte, moderado y delicado. En Prot´g´-2000 los slots enumerados
e e
son del tipo Symbol.
• Los slots del tipo Instance admiten la definici´n de relaciones entre individuos. Los slots
o
con tipo de valor Instance deben tambi´n definir una lista de clases admitidas de las cuales
e
las instancias pueden provenir. Por ejemplo, el slot produce de la clase Establecimiento
vin´cola puede tener instancias de la clase Vino como sus valores3 .
ı
3
Algunos sistemas solo especifican el tipo de valor con la clase en lugar de exigir un enunciado especial de
slots de tipo instancia.
12

13. La Figura 4 muestra la definici´n del slot produce en la clase Establecimiento vin´cola
o ı
(Winery). El slot tiene cardinalidad m´ltiple, Instance como tipo de valor, y la clase Vino
u
(Wine) como clase admitida para sus valores.
Figure 4: La definici´n del slot produce que describe los vinos producidos por un establecimiento
o
vin´ıcola. The slot has cardinality multiple, value type Instance, and the class Wine as the
allowed class for its values.
Dominio y rango de un slot
Las clases admitidas para los slots de tipo Instance son a menudo llamadas rango de un
slot. En el ejemplo de la Figura 4, la clase Vino es el rango del slot produce.Algunos sistemas
permiten restringir el rango de un slot cuando el slot esta adosado a una clase particular.
Las clases a las cuales un slot est´ adosado o las clases cuyas propiedades son descritas por
a
un slot son llamadas dominio del slot. La clase Establecimeinto vin´cola es el dominio del
ı
slot produce. En los sistemas en los cuales adosamos slots a las clases, las clases a las cuales
el slot es adosado usualmente constituye el dominio del slot. No hay necesidad de especificar el
dominio separadamente.
Las reglas b´sicas para determinar un dominio y un rango de un slot son similares:
a
Cuando se define un dominio o rango de un slot, se debe encontrar las clases o clase m´s a
generales que puedan ser respectivamente el dominio o rango de los slots. Por otro lado, no
definir un dominio ni rango que sea demasiado general: todas las clases en el dominio de un
slot deben ser descritas por el slot y las instancias de todas las clases en el rango de un slot
deben poder ser rellenos potenciales del slot. No elegir una clase demasiado general para el
rango (i.e., es in´til de crear un rango COSA(THING)) pero es posible elegir una clase que
u
cubre todos los valores de relleno.
En lugar de listar todas las las subclases posibles de la clase Vino para el ranfo del slop
produce solo listar Vino. Al mismo tiempo, no queremos especificar el rango del slot como
COSA (THING: la clase m´s general en una ontolog´
a ıa).
En t´rminos m´s especificos:
e a
13

14. Si una lista de clases que definen un rango o un dominio de un slot incluye una clase y sus
subclases, remover la subclase.
Si el rango de un slot contiene la clase Vino y la clase Vino Rojo, podemos remover Vino
Rojo del rango porque no a˜ade nueva informaci´n: El Vino Rojo es una subclase de Vino y por
n o
lo tanto el rango del slot ya lo incluye impl´
ıcitamente como tambi´n todas las otras subclases
e
de la clase Vino.
Si una lista de clases que definen un rango o dominio de un slot contiene todas las subclases
de la clase A, pero no la clase A es s´ el rango deber´ contener solamente la clase A y no las
ı, ıa
subclases.
En lugar de definir el rango del slot para incluir Vino Rojo, Vino Blanco y Vino Rosado
(enumeraci´n de todas las subclases directas de Vino), podemos limitar el rango a la clase Vino
o
como tal.
Si una lista de clases que definen un rango o dominio de un slot contiene unas cuantas
subclases de la clase A, considerar si la clase A dar´ una definici´n de rango m´s apropiada.
ıa o a
En sistemas en los cuales adosar un slot a una clase es lo mismo que agregar la clase al
dominio del slot, las mismas reglas se aplican al adosado del slot: Por un lado, debemos tratar
de hacerla tan general como sea posible. Por otro lado, debemos asegurar que cada clase a
la cual adosamos el slot pueda en efecto tener la propiedad que el slot representa. Podemos
adosar el slot del nivel de tanino a cada clase que representa a los vinos rojos (e.g., Bordeaux,
Merlot, Beaujolais, etc.). Sin embargo, puesto que todos los vinos rojos tienen la propiedad
nivel de tanino, deber´ ıamos adosar en su lugar el slot a esta clase m´s general de Vinos
a
Rojos. Si adicionalmente, generalizamos el dominio del slot del nivel de tanino (ados´ndoloa
en su lugar a la clase Vino) no ser´ correcto puesto que no usamos el nivel de tanino para
ıa
describir por ejemplo a los vinos blancos.
Paso 7. Crear instancias
El ultimo paso consiste en crear instancias individuales de clases en la jerarqu´ La definici´n
´ ıa. o
de una instancia individual de una clase requiere (1) elegir una clase, (2) crear una instancia
individual de la clase y (3) rellenar los valores del slot. Por ejemplo, podemos crear una in-
stancia individual Chateau-Morgon-Beaujolais para representar un tipo espec´ ıfico de vino
Beaujolais. Chateau-Morgon-Beaujolais es una instancia de la clase Beaujolais que repre-
senta a todos los vinos Beaujolais. Esta instancia tiene definidos los siguientes valores de slot
(Figura 5):
• Cuerpo: Ligero
• Color: Rojo
• Aroma: Delicado
• Nivel de tanino: Bajo
• Cepaje: Gamay (instancia de la clase Uva)
• Productor: Chateau-Morgon (instancia de la clase Establecimiento vin´cola)
ı
• Regi´n: Beaujolais (instancia de la clase Regi´n-Vino)
o o
• Az´car: Seco
u
14

15. Figure 5: La definici´n de una instancia de la clase Beaujolais. La instancia es Chateau Morgon
o
Beaujolais de la regi´n Beaujolais, producida con la uva Gamay por el establecimiento vin´
o ıcola
Chateau Morgon. Tiene un cuerpo ligero, aroma delicado, color rojo y bajo nivel del tanino.
Es un vino seco.
4 Definici´n de las clases y de la jerarqu´ de clases
o ıa
Esta secci´n discute aspectos en los cuales hay que tener cuidado y errores que son f´ciles
o a
de cometer cuando se definen clases y jerarqu´ de clases (Paso 4 de la Secci´n 3). Como lo
ıas o
mencionamos antes, no hay una jerarqu´ de clases correcta para un dominio dado. La jerarqu´
ıa ıa
depende de los posibles usos de la ontolog´ el nivel de detalle que es necesario para la aplicaci´n,
ıa, o
preferencias personales, y algunas veces requerimientos de compatibilidad con otros modelos.
Sin embargo, discutiremos varias recomendaciones para tenerlas en cuenta cuando se desarrolle
una jerarqu´ de clases. Despu´s de haber definido un n´mero considerable de nuevas clases, es
ıa e u
util detenerse y verificar si la jerarqu´ emergente va de acuerdo a esas recomendaciones.
´ ıa
4.1 Asegurarse que la jerarqu´ de clases es correcta
ıa
Una relaci´n “is-a”
o
la jerarqu´ de clases representa una relaci´n “is-a” (“es-un, es-una”): una clase A es una
ıa o
subclase de B si cada instancia de B es tambi´n una instancia de A. Por ejemplo, Chardonnay
e
es una subclase de Vino Blanco. Otra forma de pensar en la relaci´n taxon´mica es vi´ndola
o o e
como una relaci´n “kind-of” (“tipo-de”): Chardonnay es un tipo de Vino Blanco. Un avi´n
o o
comercial es un tipo de avi´n. Carne es un tipo de alimento.
o
Una subclase de una clase representa un concepto que es un “tipo de” concepto que la
superclase representa.
Un simple vino no es una subclase de todos los vinos
Un error com´n de modelamiento es el de incluir una versi´n singular y plural del mismo
u o
concepto en la jerarqu´ haciendo esta anterior una subclase de la ultima. Por ejemplo, est´ mal
ıa a
definir una clase Vinos y una clase Vino como una subclase de Vinos. Cuando tu piensas en la
jerarqu´ como representaci´n de la relaci´n “kind-of” (“tipo-de”), el error de modelamiento se
ıa o o
15

16. hace claro: un simple Vino no es un tipo de Vinos. La mejor forma de evitar ese tipo de error
es utilizando siempre la forma singular o plural al nombrar las clases (ver la Secci´n 6 sobre la
o
discusi´n del nombrado de conceptos).
o
Transitividad de las relaciones jer´rquicas
a
Una relaci´n de subclase es transitiva:
o
Si B es una subclase de A y C es una subclase de B, entonces C es una subclase de A
Por ejemplo, podemos definri la clase Vino, y luego definir la 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 subclase significa que la clase Chardonnay es tambi´n una
o e
subclase de Vino. Algunas veces hacemos la distinci´n entre subclases directas y subclases
o
indirectas. Una subclase directa es la subclase “m´s cercana” de la clase: no hay clases entre
a
la clase y sus subclases directas en la jerarqu´ Es decir, no hay otras clases en la jerarqu´
ıa. ıa
entre la clase y su superclase directa. En nuestro ejemplo, Chardonnay es una subclase directa
de Vino Blanco y no es una subclase directa de Vino.
Evoluci´n de una jerarqu´ de clases
o ıa
Mantener una jerarqu´ consistente de clases puede llegar a ser desafiante a media que el
ıa
dominio evoluciona. Por ejemplo, por muchos a˜os, todos los vinos Zinfandel fueron rojos.
n
Por lo tanto, definimos una clase de vinos Zinfandel como una subclase de la clase Vino
Rojo. Algunas veces, sin embargo, los productores comenzaron a presionar las uvas y extraer
inmediatamente los elementos de las uvas que producen color, modificando en consecuencia el
color del vino resultante. Por lo tanto, obtenemos “zinfandel blanco” cuyo color es rosado.
Ahora necesitamos dividir la clase Zinfandel en dos clases de zinfandel (Zinfandel Blanco y
Zinfandel Rojo) y clasificarlos como subclases de Vino Rosado y Vino Rojo respectivamente.
Las 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 esos conceptos.
El nombre de una clase puede cambiar si elegimos una terminolog´ diferente, pero el t´rmino
ıa e
como tal representa la realidad objetiva en el mundo. Por ejemplo, podemos crear un clase
Camar´n y luego renombrarla a Gamba (la clase aun representa el mismo concepto). Combina-
o
ciones apropiadas de vinos que hacen referencia a platos con camarones deben hacer referencia
a platos con gambas. En t´rminos m´s pr´cticos, la siguiente regla siempre debe ser seguida:
e a a
Los sin´nimos para el mismo concepto no representan clases diferentes.
o
Los sin´nimos son solo nombres diferentes para un concepto o t´rmino. Por lo tanto, no
o e
deber´ıamos tener una clase llamada Camar´n y una clase llamada Gamba, y posiblemente una
o
clase llamada Crevette. En su lugar, hay una clase, llamada Camar´n o Gamba. Muchos sistemas
o
admiten la asociaci´n de una lista de sin´nimos, traducciones, o nombres de presentaci´n con
o o o
una clase. Si un sistema no permite estas asociaciones, los sin´nimos siempre podr´ ser
o ıan
listados en la documentaci´n de la clase.
o
Evitar ciclos en las clases
16

17. Debemos evitar ciclos en la jerarqu´ de clases. Se dice que hay un ciclo en una jerarqu´
ıa ıa
cuando una clase A tiene una subclase B y al mismo tiempo B es una superclase de A. Crear un
ciclo como ese en un jerarqu´ equivale a declarar que las clases A y B son equivalentes: todas
ıa
las instancias de A son instancias de B y todas las instancias de B son tambi´n instancias de
e
A. En efecto, 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 tambi´n ser
e
instancias de la clase B.
4.2 An´lisis de clases hermanas en la jerarqu´ de clases
a ıa
Clases hermanas en una jerarqu´ de clases
ıa
Las clases hermanas en una jerarqu´ son clases que son subclases directas de la misma
ıa
clase (ver Secci´n 4.1).
o
Todas las clases hermanas en una jerarqu´ (excepto para las que est´n al nivel de la ra´
ıa a ız)
deben estar al mismo nivle de generalidad.
Por ejemplo, Vino Blanco y Chardonnay no deber´ ser clases de la misma clase (digamos
ıan
Vino). Vino Blanco es un concepto m´s general que Chardonnay. Las clases hermanas deben
a
representar conceptos que caen “en la misma l´ ınea” de la misma forma que las secciones de un
mismo nivel en un libro est´n al mismo nivel de generalidad. En ese sentido, los requerimientos
a
para una jerarqu´ de clases son similares a los requerimientos para una estructuraci´n de un
ıa o
libro.
Sin embargo, los conceptos en la ra´ de la jerarqu´ (los cuales son a menudo representados
ız ıa
como subclases directas de alguna clase muy general, como Thing (Cosa)) representan divisiones
principales del dominio y no tienen que ser conceptos similares.
¿Cu´n mucho es demasiado y cu´n poco es insuficiente?
a a
No hay reglas que digan el n´mero de subclases directas que una clase deber´ tener. Sin em-
u ıa
bargo, varias ontolog´ bien estructuradas tienen entre dos y una docena de subclases directas.
ıas
Por lo tanto, consideremos las siguientes reglas:
Si una clase tiene solamente una subclase directa, puede existir un problema de modelamiento
o sino la ontolog´ no est´ completa. Si hay m´s de una docena de subclases para una clase
ıa a a
dada, entonces categor´ intermedias adicionales pueden ser necesarias.
ıas
La primera de las dos reglas e similar a la regla de composici´n tipogr´fica en la que las
o a
listas con vi˜etas nunca deber´ tener solamente una vi˜eta. Por ejemplo, la mayor´ de los
n ıan n ıa
vinos rojos de Borgo˜a son vinos Cˆtes d’Or. Supongamos que queremos representar solamente
n o
este tipo de mayoritario de vinos de Borgo˜a. Podr´
n ıamos crear una clase Borgo~a Rojo y luego
n
una simpel subclase C^tes d’Or (Figura 6a). Sin embargo, si en nuestra representaci´n los
o o
vinos rojo de Borgo˜a y Cˆtes d’Or son esencialmente equivalentes (todos los vinos rojos de
n o
Borgo˜a son Cˆtes d’Or y todos los vinos Cˆtes d’Or son rojos de Borgo˜a), la creaci´n de la
n o o n o
clase C^tes d’Or no es necesaria ya que no adiciona nueva informaci´n a la representaci´n. Si
o o o
deber´ıamos incluir los vinos Cˆtes Chalonnaise, los cuales son vinos de Borgo˜a m´s baratos
o n a
de la regi´n sur de Cˆtes d’Or, entonces crear´
o o ıamos dos subclases de la clase Borgo~a: Cotes
n
dOr y Cotes Chalonnaise (Figura 6b).
Supongamos ahora que listamos todos los tipos de vinos como subclases directas de la clase
Vino. Esta lista entonces incluir´ tipos m´s generales de vinos tales como Beaujolais y Bor-
ıa a
deaux, como tambi´n tipos m´s espec´
e a ıficos de vinos tales como Paulliac y Margaux (Figura 7a).
17

18. Figure 6: Subclases de la clase Rojo de Borgo~a (Red Burgundy). Tener una sola subclase de
n
la clase usualmente indica un problema de modelamiento.
La clase Vino tiene varias subclases directas y, de hecho, para que la ontolog´ refleje los difer-
ıa
entes tipos de vino en una manera m´s organizada, Medoc deber´ ser una subclase de Bordeaux
a ıa
y Cotes d’Or deber´ ser una subclase de Borgo˜a. Tener tales categor´ intermedias como
ıa n ıas
Vino Rojo y Vino Blanco tambi´n reflejar´ el modelo conceptual del dominio de vinos que
e ıa
mucha gente tiene (Figura 7b).
Sin embargo, si no existen clases naturales para agrupar los conceptos en la larga lista de
clases hermanas, no hay la necesidad de crear clases artificiales (dejar las clases en la forma que
est´n). Despu´s de todo, la ontolog´ es un reflejo del mundo real y si no existen categorizaciones
a e ıa
en el mundo real, entonces la ontolog´ deber´ reflejar eso.
ıa ıa
4.3 Herencia m´ ltiple
u
La mayor´ de los sistemas de representaci´n de conocimiento admiten herencia m´ltiple en la
ıa o u
jerarqu´ de clases: una clase puede ser subclase de varias clases. Supongamos que deseamos
ıa
crear una clase separada de vinos de sobremesa, la clase Vino de Sobremesa. El vino Porto es
al mismo tiempo vino rojo y vino de sobremesa4 . Por lo tanto, definimos una clase Porto con
dos superclases: Vino Rojo y Vino de Sobremesa. Todas las instancias de la clase Porto ser´n a
instancias de la clase Vino Rojo y de la clase Vino de Sobremesa. La clase Porto heredar´ a
sus slots y sus facetas de sus dos superclases. De esta forma, ´sta heredar´ el valor DULCE para
e a
el slot Az´car de la clase Vino de Sobremesa y el slot nivel de tanino y el valor para su slot
u
color de la clase Vino Rojo.
4.4 ¿Cu´ndo introducir (o no) una nueva clase?
a
Una de las m´s dif´
a ıciles decisiones de tomar durante el modelamiento es cu´ndo introducir una
a
nueva clase o cu´ndo representar una desemejanza a trav´s de diferentes valores de propiedades.
a e
Es dif´ navegar en una jerarqu´ extremadamente anidada con varias clases raras y en un
ıcil ıa
jerarqu´ muy plana que tiene pocas clases con mucha informaci´n codificada en los slots. Sin
ıa o
embargo, no es f´cil encontrar el balance apropiado.
a
Hay varias reglas de base que ayudan a decidir cu´ndo introducir nuevas clases en la jer-
a
arqu´ıa.
La subclases de un clase usualmente (1) tienen propiedades adicionales que la superclase no
tiene, o (2) diferentes restricciones de las de las superclase , o (3) participan en relaciones
diferentes que la superclases.
4
Decidimos representar solamente vinos Portos rojos en nuestra ontolog´ existen tambi´n Portos blancos
ıa: e
pero son sumamente raros.
18

19. Figure 7: Categorizaci´n de vinos. Contar con todos los vinos y tipos de vino en contraste a
o
contar con varios niveles de categorizaci´n.
o
Los vinos rojos pueden tener diferentes niveles de tanino, sin embargo esta propiedad no es
usada para describir los vinos en general. El valor para el slot az´car del Vino de Sobremesa
u
es DULCE, sin embargo no es el caso para la superclase de la clase Vino de Sobremesa. Los
vinos Pinot Noir pueden servirse con mariscos mientras que otros vinos rojos no. En otras
palabras, introducimos una nueva clase en la jerarqu´ usualmente solo cuando hay algo hay
ıa
algo que podamos decir acerca de esta clase que no podamos decir acerca de la superclase.
En la pr´ctica, cada subclase debe tener nuevos slots a˜
a ’adidos a ´sta, o tener nuevos valores
e
definidos para el slot, o sustituir (override) algunas facetas de los slots heredados.
Sin embargo, puede ser util crear nuevas clases an cuando no introduzcan nuevas propiedades.
´
Las clases en terminolog´ jer´rquicas no necesitan introducir nuevas propiedades.
ıas a
Por ejemplo, algunas ontolog´ incluyen grandes jerarqu´ de referencia con t´rminos co-
ıas ıas e
munes usados en el dominio. Por ejemplo, una ontolog´ que es subyacente a un sistema de
ıa
registro electr´nico medico puede incluir una clasificaci´n de varias enfermedades. Esta clasifi-
o o
caci´n puede ser solo eso: una jerarqu´ de t´rminos sin propiedades (o con el mismo conjunto
o ıa e
de propiedades). En ese caso, es a´n util organizar los t´rminos en la jerarqu´ en lugar de
u ´ e ıa
en una lista plana porque (1) permitir´ una exploraci´n y navegaci´n m´s f´cil y (2) facilitar´
a o o a a a
19

20. al m´dico la f´cil elecci´n de un nivel de generalidad del t´rmino que es apropiado para la
e a o e
situaci´n.
o
Otra raz´n para introducir nuevas clases sin nuevas propiedades es para modelar conceptos
o
entre los cuales los expertos del dominio com´nmente hacen una distinci´n a´n cuando no
u o u
hayamos decidido modelar la distinci´n en s´ Puesto que usamos las ontolog´ para facilitar
o ı. ıas
la comunicaci´n entre los expertos de un dominio y entre ellos mismos y los sistemas basados
o
en conocimiento, deseamos reflejar en la ontolog´ la visi´n del experto sobre el dominio.
ıa o
Finalmente, no deber´ ıamos crear subclases de una clase para cada restricci´n adicional.
o
Por ejemplo, introdujimos las clases Vino Rojo, Vino Blanco, y Vino Rosado porque esta
distinci´n es natural en el mundo de los vinos. No introdujimos clases para los vinos delicado,
o
moderado, etc. Cuando definimos una jerarqu´ de clases, nuestra meta es de encontrar un
ıa
balance entre crear nuevas clases utiles para la organizaci´n de clases y crear demasiadas clases.
´ o
4.5 ¿Una nueva clase o un valor de propiedad?
Cuando modelamos un dominio, a menudo necesitamos decidir si modelar una distinci´n es- o
pec´ıfica (como vino blanco, rojo o rosado) como un valor de propiedad o como un conjunto de
clases, nuevamente, depende del alcance del dominio y de la tarea en mano.
¿Creamos una clase Vino Blanco o simplemente creamos una clase Vino y llenamos difer-
entes valores para el slot color?. La respuesta usualmente est´ en el alcance que hemos definido
a
para la ontolog´ ‘?Qu´ tan importante es el concepto Vino Blanco en nuestro dominio? Si los
ıa. e
vinos tienen solamente importancia marginal en el dominio y si siendo blanco o no el vino no
tiene ninguna implicaci´n particular en sus relaciones con otros objetos, entonces no deber´
o ıamos
introducir una clase separada para los vino blancos. Para un modelo de dominio usado en una
factor´ que produce etiquetas de vinos, las reglas de las etiquetas de vino de cualquier color son
ıa
las mismas y la distinci´n no es importante. Por el contrario, para la representaci´n de vinos,
o o
alimentos y sus combinaciones apropiadas, un vino rojo es muy diferente de un vino blanco:
est´ emparejada con diferentes alimentos, tiene diferentes propiedades, y as´ucesivamente. De
a s
manera similar, el color del vino es importante para la base de conocimientos de vinos que
podr´ ıamos usar par determinar el orden de los elementos a considerar en la degustaci´n del
o
vino. De esta manera, creamos una clase separada para Vino Blanco.
Si los conceptos con diferentes valores de slot se vuelven restricciones para diferentes slots en
otras clases, entonces debemos crear una nueva clase para esta distinci´n. Caso contrario,
o
representamos la distinci´n en un valor de slot.
o
De manera similar, nuestra ontolog´ de vinos tiene clases tales como Rojo Merlot y Blanco
ıa
Merlot, en lugar de una simple clase para todos los vinos Merlot: los Merlots rojos y los Merlots
blancos son realmente vinos diferentes (aunque producidos del mismo cepaje) y si estamos
desarrollando una ontolg´ detallada de vinos, esta distinci´n es importante.
ıa o
Si la distinci´n es importante en el dominio y pensamos en los objetos con diferentes valores
o
para la distinci´n como diferentes tipos de objetos, entonces deber´
o ıamos crear una nueva clase
para la distinci´n.
o
Considerar potenciales instancias individuales de una clase puede ser tambi´n util al decidir
e ´
si se introduce una nueva clase o no.
Una clase a la cual una instancia individual pertenece no dber´ cambiar a menudo.
ıa
20

21. Usualmente, cuando usamos propiedades extr´ ınsecas en lugar de intr´ınsecas de los conceptos
para diferenciarlos entre las clases, las instancias de esas clases tendr´n que migrar a menudo
a
de una clase a otra. Por ejemplo, Vino Enfriado no deber´ ser una clase en una ontolog´ que
ıa ıa
describe las botellas de vino en un restaurante. La propiedad enfriado deber´ simplemente
ıa
ser un atributo del vino en una botella puesto que una instancia de Vino Enfriado puede
f´cilmente dejar de ser una instancia de esta clase y llegar a ser llegar a ser instancia de esta
a
clase de nuevo.
Usualmente, los n´meros, colores, localizaciones son valores de slots y no conducen a la
u
creaci´n de nuevas clases. En el caso del vino, sin embargo, existe una notable excepci´n puesto
o o
que el color del vino es primordial para la descripci´n del vino.
o
Tomemos otro ejemplo, consideremos una ontolog´ de la anatom´ humana. Cuando rep-
ıa ıa
resentamos las costillas, ¿creamos clases para “1 ra costilla izquierda”, “2da costilla izquierda” y
as´ sucesivamente? O ¿creamos una clase Costilla con slots para el orden y la posici´n lateral
ı o
(izquierda-derecha)?5 Si al informaci´n de cada costilla que representamos en la ontolog´ es
o ıa
significativamente diferente, entonces deber´ ıamos de hecho crear una clase para cada una de
las costillas. Es decir, si deseamos representar detalles de la informaci´n de adyacencia y lo-
o
calizaci´n (la cual es diferente para cada costilla) como tambi´n funciones espec´
o e ıficas que cada
costilla juega y ´rganos que proteje, entonces nos interesa las clases. Si estamos modelando
o
la anatom´ a un nivel ligeramente leve de generalidad y todas las costillas son muy similares
ıa
en nuestras aplicaciones potenciales (se trata de ver cu´ costilla est´ rota en los rayos X sin
l a
implicaciones en las otras partes del cuerpo), entonces podr´ ıamos simplificar nuestra jerarqu´ ıa
y tener simplemente la clase Costilla, con dos slots: posici´n lateral y orden.
o
4.6 ¿Una instancia o una clase?
Decidir si un concepto particular es una clase en la ontolog´ o una instancia individual depende
ıa
de cu´les son las aplicaciones potenciales de la ontolog´ Decidir d´nde las clases terminan y
a ıa. o
las instancias comienzan, empieza por la decisi´n de cu´l es el nivel m´s bajo de granularidad en
o a a
la representaci´n. El nivel de granularidad es a su vez determinado por una aplicaci´n potencial
o o
de la ontolog´ En otras palabras, ‘?Cu´les son los ´
ıa. a ıtems m´s espec´
a ıficos que representaremos
en la base de conocimientos? Volviendo a las preguntas de competencia que hemos identificado
en el Paso 1 de la Secci´n 3, los conceptos m´s espec´
o a ıficos que constituir´n respuestas a esas
a
preguntas ser´n muy buenos candidatos para ser individuos en la base de conocimientos.
a
La instancias individuales son los conceptos m´s espec´
a ıficos representados en una base de
conocimientos.
Por ejemplo, si solo hablaremos del emparejado de vinos con alimentos, no estaremos intere-
sados en espec´ıficas botellas f´
ısicas de vino. Por lo tanto, t´rminos como Sterling Vineyards
e
Merlot ser´n probablemente los t´rminos m´s espec´
a e a ıficos que usemos. De este modo, Sterling
Vineyards Merlot ser´ una instancia en la base de conocimientos.
a
Por otro lado, si deseamos mantener un inventario de los vinos del restaurante adem´s de la
a
base de conocimientos de buenas parejas vino-alimento, las botellas individuales de cada vino
llegar´n a ser instancias individuales en nuestra base de conocimientos.
a
De manera similar, si deseamos registrar las diferentes propiedades de cada cosecha espec´ıfica
de los Sterling Vineyards Merlot, entonces la cosecha espec´ ıfica de vino es una instancia en
5
Asumimos que cada ´rgano anat´mico es una clase puesto que queremos tambi´n discutir de “la 1ra costilla
o o e
izquierda de Juan”. Los ´rganos individuales de toda persona ser´ representados individualmente en nuestra
o ıan
ontolog´
ıa.
21

22. la base de conocimientos y Sterling Vineyards Merlot es una clase que contiene instancias
para todas sus cosechas.
Otra regla puede “desplazar” algunas instancias individuales al conjunto de clases:
Si los conceptos forman una jerarqu´ natural, entonces deber´
ıa ıamos representarlos como clases.
Consideremos las regiones de producci´n de vino. Inicialmente, podemos definir regiones
o
principales producci´n de vino, tales como Francia, Estados Unidos, Alemania, y as sucesiva-
o
mente, como clases, y regiones espec´ıficas de producci´n de vino dentro esas grandes regiones
o
como instancias. Por ejemplo, la regi´n de Borgo˜a es una instancia de la clase de Regi´n
o n o
Francesa. Sin embargo, tambi´n quisi´ramos decir que la Regi´n Cotes d’Or es una Regi´n
e e o o
de Borgo~a. En consecuencia, la Regi´n de Borgo~a debe ser una clase (para tener subclases
n o n
o instancias). Sin embargo, parece arbitrario hacer que la Regi´n de Borgo~a sea una clase y
o n
que la Regi´n Cotes d’Or sea una instancia de la Regi´n de Borgo~a: es muy dif´ distin-
o o n ıcil
guir claramente qu´ regiones son clases y cu´les son instancias. Por lo tanto, definimos todas
e a
las regiones de producci´n de vino como clases. Prot´g´-2000 permite a los usuarios especi-
o e e
ficar algunas clases como Abstract (abstractas), indicando que la clase no puede tener ninguna
instancia directa. En nuestro caso, todas las clases de las regiones de producci´n de vino son
o
abstractas (Figura 8).
Figure 8: Jerarqu´ de las regiones de producci´n de vino. Los ´
ıa o ıconos “A” junto a los nombres
de las clases indican que las clases son abstractas y no pueden tener ninguna instancia directa.
La misma jerarqu´ de clases ser´ incorrecta si omitimos la palabra “regi´n” de los nombres
ıa ıa o
de las clases. No podemos decir que la clase Alsacia (Alsace) es una subclase de de la clase
Francia: Alsacia no es un tipo de Francia. Sin embargo, la regi´n de Alsacia es un tipo de
o
regi´n de Francia.
o
Solamente las clases pueden ser dispuestas en una jerarqu´ (los sistemas de representaci´n
ıa o
de conocimiento no tienen la noci´n de de sub-instancia). Por lo tanto, si existe una jerarqu´
o ıa
natural entre los t´rminos, como en las jerarqu´ terminol´gicas de la Secci´n 4.2, debemos
e ıas o o
definir esos t´rminos como clases aunque no tengan ninguna instancia propia.
e
22

23. 4.7 Limitaci´n del alcance
o
Como nota final sobre la definici´n de una jerarqu´ de clases, el siguiente conjunto de reglas es
o ıa
siempre util para decidir si una ontolog´ est´ completa:
´ ıa a
La ontolog´ no deber´ contener toda la informaci´n posible del dominio: no necesitas
ıa ıa o
especializar (o generalizar) m´s de lo que necesitas para tu aplicaci´n (como m´ximo un nivel
a o a
extra de cada lado).
En nuestro ejemplo de vinos y alimentos, no necesitamos saber qu´ papel es usado para las
e
etiquetas o c´mo cocinar gambas.
o
De manera similar, la ontolog´ no debe contener todas las posibles propiedades de las clases
ıa
ni las distinciones entre ellas en la jerarqu´ıa.
En nuestra ontolog´ sin duda no incluiremos todas las propiedades que un vino o alimento
ıa,
pueda tener. Representamos las propiedades m´s sobresalientes de las clases de ´
a ıtems en nues-
tra ontolog´ Aunque los libros de vinos nos dir´n el tama˜o de las uvas, no incluimos ese
ıa. a n
conocimiento. De manera similar, no hemos agregado todas las relaciones que podr´ ıamos imag-
inar entre todos los t´rminos de nuestro sistema. Por ejemplo, no incluimos las relaciones tales
e
como vino favorito o alimento preferido en la ontolog´ para tener una representaci´n m´s
ıa o a
completa de todas las interconexiones entre los t´rminos que hemos definido.
e
Las ultimas reglas tambi´n se aplican para establecer relaciones entre conceptos que ya
´ e
los hemos incluido en la ontolog´ ıa. Consideremos una ontolog´ que describe experimentos
ıa
biol´gicos. La ontolog´ probablemente contendr´ un concepto de Organismos Biol´gicos.
o ıa a o
Tambi´n contendr´ el concepto de un Experimentador que ejecuta un experimento (con su
e a
nombre, afiliaci´n, etc.). Es cierto que un experimentador es una persona, y como persona,
o
tambi´n es casualmente un organismo biol´gico. Sin embargo, probablemente no debamos
e o
incorporar esta distinci´n en la ontolog´ para los prop´sitos de esta representaci´n un experi-
o ıa: o o
mentador no es un organismo biol´gico y probablemente nunca ejecutemos experimentos en los
o
experimentadores como tal. Si estuvi’esemos representando todo lo que podamos decir de las
clases en la ontolog´ un Experimentador llegar´ a ser una subclase de Organismo Biol´gico.
ıa, ıa o
Sin embargo, no necesitamos incluir este conocimiento para las aplicaciones previsibles. De he-
cho, la inclusi´n de este tipo de clasificaci´n adicional para las clases existentes en realidad es
o o
perjudicial: una instancia de un Experimentador tendr´ slots para peso, edad, especie, y otros
a
datos pertenecientes a un organismo biol´gico, pero absolutamente irrelevantes en el contexto
o
de la descripci´n de un experimento. Sin embargo, debemos registrar tal decisi´n de dise˜o en
o o n
la documentaci´n para el beneficio de los usuarios que mirar´n esta ontolog´ y que no estar´n
o a ıa a
enterados de la apliaci´n que ten´
o ıamos en mente.
4.8 Subclases disjuntas
Muchos sistemas nos permiten especificar expl´ ıcitamente que varias clases sean disjuntas. La
clases son disjuntas si no pueden tener ninguna instancia en com´n. Por ejemplo, las clases
u
Vino de Sobremesa y Vino Blanco de nuestra ontolog´ no son disjuntas: hay muchos vinos
ıa
que son instancias de ambos. La instancia Rothermel Trochenbierenauslese Riesling de la
clase Riesling Dulce es un ejemplo de ello. Al mismo tiempo, las clases Vino Rojo y Vino
Blanco son disjuntas: ning´n vino puede ser simult´neamente rojo y blanco. La especificaci´n
u a o
de clases disjuntas permite al sistema de validar la ontolog´ de mejor manera. Si declaramos
ıa
que las clases Vino Rojo y Vino Blanco son disjuntas y posteriormente creamos una clase que
es una subclase de Riesling (una subclase de Vino Blanco) y Porto (una subclase de Vino
Rojo), el sistema indicar´ que hay un error de modelamiento.
a
23