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 ingls por: Erick Antezana e September 19, 2005

erant@psb.ugent.be

Contents
1 Por qu desarrollar una ontolog e a? 2 Qu es una ontolog e a? 3 Una simple metodolog de ingenier del conocimiento a a 4 Denicin de las clases y de la jerarqu de clases o a 4.1 Asegurarse que la jerarqu de clases es correcta . . a 4.2 Anlisis de clases hermanas en la jerarqu de clases a a 4.3 Herencia mltiple . . . . . . . . . . . . . . . . . . . . u 4.4 Cundo introducir (o no) una nueva clase? . . . . . a 4.5 Una nueva clase o un valor de propiedad? . . . . . . 4.6 Una instancia o una clase? . . . . . . . . . . . . . . 4.7 Limitacin del alcance . . . . . . . . . . . . . . . . . o 4.8 Subclases disjuntas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 6 15 15 17 18 18 20 21 23 23

5 Denicin de las propiedades (ms detalles) o a 24 5.1 Slots inversos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2 Valores por defecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 6 Qu est en un nombre? e a 6.1 Maysculas/minsculas y delimitadores u u 6.2 Singular o Plural . . . . . . . . . . . . . 6.3 Convenios: prejos y sujos . . . . . . . 6.4 Otras consideraciones de nombrado . . . 7 Otros recursos 8 Conclusiones 9 Agradecimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 26 26 26 26 27 27 28

Por qu desarrollar una ontolog e a?

En los ultimos aos el desarrollo de ontolog (especicaciones formales y especicas de los n as trminos y relaciones entre ellos (Gruber 1993)) ha estado movindose del dominio de los labe e oratorios de Inteligencia Articial 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 categorizaas 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 codicar conocimiento en pginas Web para hacerlas entendibles a los agentes a electrnicos que buscan informacin. La agencia de proyectos de investigacin avanzada en deo 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 ms expresivas buscando facilitar la interaccin de agentes en el Web (Hendler and McGuinness a o 2000). Muchas disciplinas desarrollan ahora ontolog estandarizadas que los expertos de cieras tos dominios pueden usarlas para compartir y anotar informacin 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 semntica Unied Medical Language a System (Humphreys and Lindberg 1993). Estn tambin surgiendo otras ontolog amplias y a e as de propsito general. Por ejemplo, el programa de desarrollo de las naciones unidas (United Nao 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 dene un vocabulario comun para investigadores que necesitan compartir a informacin en un dominio. Ella contiene deniciones 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 comn de la estructura de informacin entre personas o u o agentes de software. Permitir la reutilizacin 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 comn de la estructura de informacin entre personas y agentes u o de software es una de las ms importantes metas al desarrollar ontolog (Musen 1992; Gruber a as 1993). Por ejemplo, supongamos que varios distintos sitios Web contengan informacin mdica o e o provean servicios de e-commerce mdico. Si esos sitios Web comparten y publican la misma e ontolog subyacente de los trminos que usan, entonces agentes de software podr extraen a e an y agregar informacin de eso esos sitios diferentes. Los agentes podr usar esta informacin o an o agregada para responder solicitudes de los usuarios o servir como datos de entrada a otras aplicaciones. Permitir la reutilizacin de conocimiento de un dominio fue una de las fuerzas conduco toras detrs recientes trabajos en la investigacin sobre ontolog a o as. Por ejemplo, modelos para diferentes dominios necesitan representar la nocin de tiempo. Esta representacin 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

podemos integrar varias ontolog existentes que describen porciones del dominio mas grande. as Tambin podemos reusar una ontolog general, tal como la ontolog UNSPSC, y extenderla e a a para describir nuestro dominio de inters. e La explicitacin de suposiciones de un dominio, que subyacen bajo una implementacin, o o permite cambiar esas suposiciones fcilmente si el conocimiento del dominio cambia. Suposia ciones codicadas expl citamente acerca del mundo en algn lenguaje de programacin hacen u o que las suposiciones no solo sean dif ciles de hallar sino tambin diciles de cambiar, en pare ticular para alguien sin competencias en programacin. Adems, las especicaciones explicitas o a del dominio de conocimiento son utiles para nuevos usuarios que deben aprender el signicado de los trminos del dominio. e La separacin del conocimiento del dominio del conocimiento operacional es otro uso comn o u de las ontolog as. Podemos describir la tarea de conguracin de un producto a partir de sus o componentes de acuerdo a especicaciones requeridas e implementar un programa que hace independiente esta conguracin 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 congurar PCs ordenadas a medida. Podemos usar el mismo algoritmo para congurar elevadores si alimentamos nuestra ontolog con elevador como componente (Rothena uh et al. 1996). Analizar el conocimiento de un dominio es posible una vez que una especicacin declarativa o de los trminos esta disponible. El anlisis formal de los trminos 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 denir un conjunto de datos y sus estructuras para que otros proa gramas los usen. Mtodos 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 publicacin 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 gestin de un restaurante: o Una aplicacin podr crear sugerencias de vino para el men del d o responder a solicitudes o a u a de camareros y clientes. otra aplicacin 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 mens as u futuros o recetarios. Acerca de esta gu a Nos basamos en nuestra experiencia usando Protg-2000 (Protege 2000), Ontolingua (One e tolingua 1997), Chimaera (Chimaera 2000) como entornos de edicin de ontolog o as. En esta gu usamos Protg-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 publicacin que describe CLASo SIC (un sistema de representacin de conocimiento basado en lgicas de descripcin (Brachman o o o et al. 1991)). El tutorial de CLASSIC (McGuinness et al. 1994) ha desarrollado este ejemplo ulteriormente. Protg-2000 y otros sistemas basados en marcos describen las ontolog declare e as ativamente, estableciendo explicitamente cual es la jerarqu de clases y a que clases individuales a pertenecen. Algunas ideas de diseo de ontolog en esta gu se originaron a partir de la literatura sobre n as a diseo orientado a objetos (Rumbaugh et al. 1991; Booch et al. 1997). Sin embargo, el desarrollo n de ontolog es diferente a diseo de clases y relaciones como en la programacin orientada a as n o objetos. La programacin orientada a objetos se centra principalmente alrededor de mtodos en o e clases - un programador toma decisiones de diseo basndose en las propiedades operacionales n a 4

de una clase, mientras que un diseador de ontolog toma esas decisiones basndose 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 diseadores de ontolog a a n as desarrollar ontolog Al nal, sugerimos lugares para buscar explicaciones sobre estructuras y as. mecanismos de diseo ms complicados si el dominio los requiere. n a Finalmente, no hay una simple y correcta metodolog de diseo de ontolog y no intentaa n as mos denir una. Las ideas que presentamos aqui son las que encontramos utiles dentro nuestra experiencia de desarrollo de ontolog as. Al nal de esta gu sugerimos una lista de referencias a de metodolog alternativas. as

Qu es una ontolog e a?

La literatura de inteligencia articial contiene varias deniciones de ontolog muchas de ela; las contradicen otras. Para los propsitos de esta gu una ontolog es una descripcin exo 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 veces 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 cos 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 cos 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 Late Rothschild. A nivel de la clase, podemos decir que las instancias de la clase Vino tendran slots que describen su sabor, cuerpo, nivel de azcar, 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 vincola (Figura 1). Todas las instancias de la clase Establecimiento vincola tienen un slot produce que se reere a todos los vinos (instancias de la clase Vino y sus subclases) que el establecimiento vin cola produce. En trminos prcticos, desarrollar una ontolog incluye: e a a denir clases en la ontolog a, organizar las clases en una jerarqu taxonmica (subclase-superclase), a o denir slots y describir valores permitidos para esos slots,
Los nombres de las clases comienzan con mayusculas y los nombres de los slots estn en minsculas. Usamos a u tambin la fuente de typewriter para todos los trminos del ejemplo de la ontolog e e a.
1

 llenar los valores de los slots para las instancias. Podemos entonces crear una base de conocimientos deniendo las instancias individuales de esas clases, precisando los valores especicos 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.

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 sideracin y ofrecemos uno de los procedimientos posibles para desarrollar una ontolog Deo a. scribimos un enfoque iterativo en el desarrollo de la ontolog comenzamos por abordar la a: ontolog de manera frontal. A continuacin volvemos sobre la ontolog que consideramos a o a, en proceso de evolucin, anndola y conpletndola con detalles. A lo argo de este proceso o a a discutimos las decisiones de modelizacin que toma el diseador, as como los pros, los contras o n y las implicaciones de diferentes soluciones. Inicialmente, queremos enfatizar algunas reglas fundamentales e el diseo de ontolog a las n as cuales nos referiremos varias veces. Esas reglas pueden parecen algo dogmticas. Ellas pueden a ayudar, sin embargo, para tomar decisiones de diseo en muchos casos. n 1. No hay una forma correcta de modelar un dominio - siempre hay alternativas viables. La mejor solucin casi siempre depende de la aplicacin 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 lgicos) y relaciones o en tu dominio de inters. 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 cun 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

las varias alternativas viables, necesitaremos determinar cul funcionar mejor para la tarea a a proyectada, cul ser ms intuitiva, ms extensible y ms mantenible. Necesitamos tambin 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 reejar esta realidad. Despus de que hayamos denido una versin inicial de la ontolog e o a, podemos evaluarla y depurarla usndola en aplicaciones o mtodos que resuelvan problemas o a e discutindola con expertos en el rea. En consecuencia, casi seguramente necesitaremos revisar e a la ontolog inicial. Este proceso de diseo iterativo probablemente continuara a travs 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 deniendo su dominio y alcance. Es a decir, responder a varias preguntas bsicas: a Cul es el dominio que la ontolog cubrir? a a a Para qu usaremos la ontolog e a? Para qu tipos de preguntas la informacin en la ontolog deber proveer respuestas? e o a a Quin usar y mantendr la ontolog e a a a? Las respuestas a esas preguntas pueden cambiar durante el proceso del diseo 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 representacin 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 nocin de una buena combinacin de vino y alimento y la mala combinacin guo 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 estn de alguna manera relacionados a las nociones de vino y alimento. a Si la ontolog que estamos diseando ser usada para ayudar en el procesamiento de lenguaje a n a natural de art culos en las tiendas de vino, seria importante incluir sinnimos e informacin 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 informacin 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 sern 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 servirn despus como a e prueba de control de calidad: La ontolog contiene suciente informacin para responder esos a o tipos de preguntas? Las respuestas requieren un nivel particular de detalle o representacin 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

 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? Cul es la mejor eleccin de vino para acompaar 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 especico cambia con su ao de cosecha? n Cules fueron buenas cosechas para el Napa Zinfandel? a Juzgando a partir de esta lista de preguntas, la ontolog incluir la informacin de varias a a o caracter sticas de vinos y tipos de vinos, aos de cosechas (buenos y malos), clasicacin de n o alimentos que importan para elegir un vino apropiado, combinaciones recomendadas de vinos y comidas. Paso 2. Considerar la reutilizacin de ontolog existentes o as Casi siempre vale la pena considerar lo que otra persona ha hecho y vericar si podemos renar 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 aplicaciones que ya se han dedicado a ontolog particulares o vocabularios controlados. Muchas as ontolog ya estn disponibles en forma electrnica y pueden ser importadas dentro un entorno as a o de desarrollo de ontolog que ests usando. El formalismo en el cual una ontolog est exas a a a presado a menudo no interesa, puesto que muchos sistemas de representacin de conocimiento o pueden importar y exportar ontolog Aun si el sistema de representacin 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/). Tambin hay un as e cierto nmero de ontolog comerciales pblicamente 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, tena a dremos no solamente la clasicacin de vinos Franceses sino tambin el primero paso hacia la o e clasicacin 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 comena, a zaremos la ontolog desde el principio. a Paso 3. Enumerar trminos importantes para la ontolog e a Es util escribir una lista con todos los trminos con los que quisiramos hacer enunciados e e o dar explicacin a un usuario. Cules con los trminos de los cuales quisiramos hablar? o a e e Qu propiedades tienen esos trminos? Por ejemplo, trminos importantes relativos a los e e e vinos incluirn vino, cepaje, establecimiento vincola, localidad, color del vino, cuerpo, a sabor, contenido de azcar; diferentes tipos de alimentos, tales como pescado y carne roja; u 8

subtipos de vino tales como vino blanco, etc. Inicialmente, es importante obtener una lista integral de trminos sin preocuparse del recubrimiento entre los conceptos que representan, e relaciones entre los trminos, 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 deniendo las propiedades de a los conceptos (slots)) estn estrechamente relacionadas. Es dif hacer primero uno de ellos y a cil luego hacer el otro. T picamente, creamos unas cuantas deniciones de los conceptos en la jerarqu y luego continuamos describiendo las propiedades de esos conceptos y as sucesivamente. a Esos dos pasos son tambin los ms importantes en el proceso de diseo de la ontolog Los e a n a. describiremos brevemente y dedicaremos las siguientes dos secciones a discutir los asuntos ms a complicados que necesitan ser considerados, peligros comunes, decisiones a tomar, etc. Paso 4. Denir 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 denicin de los conceptos ms geno a erales en el dominio la subsecuente espicializacin de los conceptos. Por ejemplo, podemos o comenzar creando clases para los conceptos generales de Vino y Alimentos. Luego especializamos 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 denicin de las clases mas especio cas, las hojas de la jerarqu con el subsecuente agrupamiento de esas clases en conceptos a, ms generales. Por ejemplo, comenzamos deniendo clases para los vinos Pauillac y a Margaux. Luego creamos una superclase comn 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 denimos los conceptos ms sobresalientes y luego los a generalizamos y especializamos apropiadamente. Podr amos comenzar con unos cuantos conceptos de nivel superior como Vino, y unos conceptos espec cos, 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 consecuencia un cierto nmero de conceptos de nivel medio. u La Figura 2 muestra una posible descomposicin entre los diferentes niveles de generalidad. o Ninguno de esos tres mtodos es inherentemente mejor que cualquiera de los otros. El e enfoque a tomar depende fuertemente de la visin personal del dominio. Si un desarrollador o tiene una visin sistemtica top-down del dominio, entonces ser ms fcil usar el enfoque o a a a a top-down. El enfoque combinado es a menudo es el ms fcil para muchos desarrolladores de a a ontolog puesto que los conceptos del medio tienden a ser conceptos ms descriptivos en el as, a dominio (Rosch 1978). Si tiendes a pensar en vinos distinguiendo primero la clasicacin ms general, entonces o a el enfoque top-down podr funcionar mejor para ti. Si preeres comenzar listando ejemplos a espec cos, el enfoque bottom-up podr ser el ms apropiado. a a Sea cual sea el enfoque que elijamos, usualmente comenzaremos deniendo las clases. De la lista creada en el Paso 3, seleccionamos los trminos que describen objetos que tienen existencia e independiente en lugar de trminos que describen esos objetos. Esos trminos sern las clases e e a 9

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 ms generales a (nivel superior (top level)). Pauillac y Margaux son las clases ms espec a cas en la jerarqu a (nivel inferior (bottom level)). de la ontolog y llegarn a ser anclas en la jerarqu de clases2 . Organizamos las clases en una a a a taxonom jerquica preguntando si siendo una instancia de una clase, el objeto necesariamente a a ser (i.e., por denicin) 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 tambin 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 seccin a a o 4 contiene una discusin detallada de algunos aspectos a considerar cuando se est deniendo o a una jerarqu de clases. a Paso 5. Denir las propiedades de las clases: slots Las clases aisladas no proveern suciente informacin para responder las preguntas de a o competencia del Paso 1. Una vez que hemos denido algunas de las clases, debemos describir la estructura interna de los conceptos. Ya hemos seleccionado clases de la lista de trminos creada en el Paso 3. La mayor de los e a trminos restantes son muy probablemente propiedades de esas clases. Esos trminos incluyen, e e
Podemos tambin 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? Cul es el sabor de a este objeto?
2

10

por ejemplo, un color de vino, cuerpo, sabor, contenido de azcar y localizacin 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 azcar. Y la clase Establecimiento vincola a u tendr un slot localizacin. 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 relacion entre un vino y un establecimiento vin cola, y la uva con la cual el vino est producido.) a De esta forma, adems de las propiedades que hemos identicado previamente, necesitamos a aadir 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 sern 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 ms general que pueda tener esa propiedad. Por a a ejemplo, el cuerpo y color de un vino debern estar adosados a la clase Vino, puesto que sta a e es la clase ms general cuyas instancias tendrn 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 ms generales, el nivel e a superior. Pauillac y Margaux son las clases ms espec a cas en la jerarqu el nivel inferior. a, Paso 6. Denir las facetas de los slots Los slots puedes tener diferentes facetas que describen el tipo de valor, valores admitidos, el nmero 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

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 mltiples 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 dene cuantos valores un slot puede tener. Algunos sistemas solamente distinguen entre cardinalidad simple (admitiendo a lo sumo un valor) y cardinalidad mltiple (admitiendo cualquier cantidad de valores). Los vinos producidos por un establecu imiento vin cola particular completan el slop produce que es de cardinalidad mltiple para la u clase Establecimiento vincola. Algunos sistemas admiten la especicacin de una cardinalidad m o nima y mxima para a describir la cantidad de valores de un slot con ms precisin. Una cardinalidad m a o nima N signica 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 mxima M siginica que un slot puede tener a lo sumo M valores. La cardinalidad a mxima 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 jar la mxima cardinalidad en 0. a Esta denicin indicar que el slot no puede tener ningn 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 ms comunes: a String es el tipo de valor ms 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 ms a espec cos) describe slots con valores numricos. 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 especican una lista espec ca de valores admitidos para el slot. Por ejemplo, podemos especicar que slot sabor puede tomar uno de los siguientes valores posibles: fuerte, moderado y delicado. En Protg-2000 los slots enumerados e e son del tipo Symbol. Los slots del tipo Instance admiten la denicin de relaciones entre individuos. Los slots o con tipo de valor Instance deben tambin denir una lista de clases admitidas de las cuales e las instancias pueden provenir. Por ejemplo, el slot produce de la clase Establecimiento vincola puede tener instancias de la clase Vino como sus valores3 .
Algunos sistemas solo especican el tipo de valor con la clase en lugar de exigir un enunciado especial de slots de tipo instancia.
3

12

La Figura 4 muestra la denicin del slot produce en la clase Establecimiento vincola o (Winery). El slot tiene cardinalidad mltiple, Instance como tipo de valor, y la clase Vino u (Wine) como clase admitida para sus valores.

Figure 4: La denicin 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 vincola 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 especicar el dominio separadamente. Las reglas bsicas para determinar un dominio y un rango de un slot son similares: a Cuando se dene un dominio o rango de un slot, se debe encontrar las clases o clase ms a generales que puedan ser respectivamente el dominio o rango de los slots. Por otro lado, no denir 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 intil 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 especicar el rango del slot como COSA (THING: la clase ms general en una ontolog a a). En trminos ms especicos: e a 13

Si una lista de clases que denen 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 aade nueva informacin: El Vino Rojo es una subclase de Vino y por n o lo tanto el rango del slot ya lo incluye impl citamente como tambin todas las otras subclases e de la clase Vino. Si una lista de clases que denen 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 denir el rango del slot para incluir Vino Rojo, Vino Blanco y Vino Rosado (enumeracin de todas las subclases directas de Vino), podemos limitar el rango a la clase Vino o como tal. Si una lista de clases que denen un rango o dominio de un slot contiene unas cuantas subclases de la clase A, considerar si la clase A dar una denicin de rango ms 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 ms general de Vinos a Rojos. Si adicionalmente, generalizamos el dominio del slot del nivel de tanino (adosndolo a 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 denicin 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 instancia individual Chateau-Morgon-Beaujolais para representar un tipo espec co de vino Beaujolais. Chateau-Morgon-Beaujolais es una instancia de la clase Beaujolais que representa a todos los vinos Beaujolais. Esta instancia tiene denidos 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 vincola) Regin: Beaujolais (instancia de la clase Regin-Vino) o o Azcar: Seco u 14

Figure 5: La denicin de una instancia de la clase Beaujolais. La instancia es Chateau Morgon o Beaujolais de la regin 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.

Denicin de las clases y de la jerarqu de clases o a

Esta seccin discute aspectos en los cuales hay que tener cuidado y errores que son fciles o a de cometer cuando se denen clases y jerarqu de clases (Paso 4 de la Seccin 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 aplicacin, 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. Despus de haber denido un nmero considerable de nuevas clases, es a e u util detenerse y vericar si la jerarqu emergente va de acuerdo a esas recomendaciones. a

4.1

Asegurarse que la jerarqu de clases es correcta a

Una relacin is-a o la jerarqu de clases representa una relacin is-a (es-un, es-una): una clase A es una a o subclase de B si cada instancia de B es tambin una instancia de A. Por ejemplo, Chardonnay e es una subclase de Vino Blanco. Otra forma de pensar en la relacin taxonmica es vindola o o e como una relacin kind-of (tipo-de): Chardonnay es un tipo de Vino Blanco. Un avin o o comercial es un tipo de avin. 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 comn de modelamiento es el de incluir una versin 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 denir una clase Vinos y una clase Vino como una subclase de Vinos. Cuando tu piensas en la jerarqu como representacin de la relacin kind-of (tipo-de), el error de modelamiento se a o o 15

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 Seccin 6 sobre la o discusin del nombrado de conceptos). o Transitividad de las relaciones jerrquicas a Una relacin 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 denri la clase Vino, y luego denir la clase Vino Blanco como una subclase de Vino. Luego denimos una clase Chardonnay como una subclase de Vino Blanco. La transitividad de la relacin de subclase signica que la clase Chardonnay es tambin una o e subclase de Vino. Algunas veces hacemos la distincin entre subclases directas y subclases o indirectas. Una subclase directa es la subclase ms 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. Evolucin de una jerarqu de clases o a Mantener una jerarqu consistente de clases puede llegar a ser desaante a media que el a dominio evoluciona. Por ejemplo, por muchos aos, todos los vinos Zinfandel fueron rojos. n Por lo tanto, denimos 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, modicando 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 clasicarlos 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 trmino a e como tal representa la realidad objetiva en el mundo. Por ejemplo, podemos crear un clase Camarn y luego renombrarla a Gamba (la clase aun representa el mismo concepto). Combinao ciones apropiadas de vinos que hacen referencia a platos con camarones deben hacer referencia a platos con gambas. En trminos ms prcticos, la siguiente regla siempre debe ser seguida: e a a Los sinnimos para el mismo concepto no representan clases diferentes. o Los sinnimos son solo nombres diferentes para un concepto o trmino. Por lo tanto, no o e deber amos tener una clase llamada Camarn y una clase llamada Gamba, y posiblemente una o clase llamada Crevette. En su lugar, hay una clase, llamada Camarn o Gamba. Muchos sistemas o admiten la asociacin de una lista de sinnimos, traducciones, o nombres de presentacin con o o o una clase. Si un sistema no permite estas asociaciones, los sinnimos siempre podr ser o an listados en la documentacin de la clase. o Evitar ciclos en las clases 16

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 tambin 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 tambin ser e instancias de la clase B.

4.2

Anlisis 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 Seccin 4.1). o Todas las clases hermanas en una jerarqu (excepto para las que estn 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 ms 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 estn al mismo nivel de generalidad. En ese sentido, los requerimientos a para una jerarqu de clases son similares a los requerimientos para una estructuracin 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. Cun mucho es demasiado y cun poco es insuciente? a a No hay reglas que digan el nmero de subclases directas que una clase deber tener. Sin emu 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 ms 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 composicin tipogrca en la que las o a listas con vietas nunca deber tener solamente una vieta. Por ejemplo, la mayor de los n an n a vinos rojos de Borgoa son vinos Ctes dOr. Supongamos que queremos representar solamente n o este tipo de mayoritario de vinos de Borgoa. Podr n amos crear una clase Borgo~a Rojo y luego n una simpel subclase C^tes dOr (Figura 6a). Sin embargo, si en nuestra representacin los o o vinos rojo de Borgoa y Ctes dOr son esencialmente equivalentes (todos los vinos rojos de n o Borgoa son Ctes dOr y todos los vinos Ctes dOr son rojos de Borgoa), la creacin de la n o o n o clase C^tes dOr no es necesaria ya que no adiciona nueva informacin a la representacin. Si o o o deber amos incluir los vinos Ctes Chalonnaise, los cuales son vinos de Borgoa ms baratos o n a de la regin sur de Ctes dOr, 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 ms generales de vinos tales como Beaujolais y Bora a deaux, como tambin tipos ms espec e a cos de vinos tales como Paulliac y Margaux (Figura 7a). 17

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 reeje los difera entes tipos de vino en una manera ms organizada, Medoc deber ser una subclase de Bordeaux a a y Cotes dOr deber ser una subclase de Borgoa. Tener tales categor intermedias como a n as Vino Rojo y Vino Blanco tambin reejar 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 articiales (dejar las clases en la forma que estn). Despus de todo, la ontolog es un reejo del mundo real y si no existen categorizaciones a e a en el mundo real, entonces la ontolog deber reejar eso. a a

4.3

Herencia m ltiple u

La mayor de los sistemas de representacin de conocimiento admiten herencia mltiple 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, denimos una clase Porto con dos superclases: Vino Rojo y Vino de Sobremesa. Todas las instancias de la clase Porto sern 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 Azcar 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

Cundo introducir (o no) una nueva clase? a

Una de las ms dif a ciles decisiones de tomar durante el modelamiento es cundo introducir una a nueva clase o cundo representar una desemejanza a travs 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 informacin codicada en los slots. Sin a o embargo, no es fcil encontrar el balance apropiado. a Hay varias reglas de base que ayudan a decidir cundo introducir nuevas clases en la jera 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.
Decidimos representar solamente vinos Portos rojos en nuestra ontolog existen tambin Portos blancos a: e pero son sumamente raros.
4

18

Figure 7: Categorizacin de vinos. Contar con todos los vinos y tipos de vino en contraste a o contar con varios niveles de categorizacin. 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 azcar 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 prctica, cada subclase debe tener nuevos slots a a adidos a sta, o tener nuevos valores e denidos 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 jerrquicas no necesitan introducir nuevas propiedades. as a Por ejemplo, algunas ontolog incluyen grandes jerarqu de referencia con trminos coas as e munes usados en el dominio. Por ejemplo, una ontolog que es subyacente a un sistema de a registro electrnico medico puede incluir una clasicacin de varias enfermedades. Esta clasio o cacin puede ser solo eso: una jerarqu de trminos sin propiedades (o con el mismo conjunto o a e de propiedades). En ese caso, es an util organizar los trminos en la jerarqu en lugar de u e a en una lista plana porque (1) permitir una exploracin y navegacin ms fcil y (2) facilitar a o o a a a 19

al mdico la fcil eleccin de un nivel de generalidad del trmino que es apropiado para la e a o e situacin. o Otra razn para introducir nuevas clases sin nuevas propiedades es para modelar conceptos o entre los cuales los expertos del dominio comnmente hacen una distincin an cuando no u o u hayamos decidido modelar la distincin en s Puesto que usamos las ontolog para facilitar o . as la comunicacin entre los expertos de un dominio y entre ellos mismos y los sistemas basados o en conocimiento, deseamos reejar en la ontolog la visin del experto sobre el dominio. a o Finalmente, no deber amos crear subclases de una clase para cada restriccin adicional. o Por ejemplo, introdujimos las clases Vino Rojo, Vino Blanco, y Vino Rosado porque esta distincin es natural en el mundo de los vinos. No introdujimos clases para los vinos delicado, o moderado, etc. Cuando denimos una jerarqu de clases, nuestra meta es de encontrar un a balance entre crear nuevas clases utiles para la organizacin 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 distincin eso pec ca (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 diferentes valores para el slot color?. La respuesta usualmente est en el alcance que hemos denido 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 implicacin 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 distincin no es importante. Por el contrario, para la representacin 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 asucesivamente. 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 degustacin 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 distincin. Caso contrario, o representamos la distincin 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 distincin es importante. a o Si la distincin es importante en el dominio y pensamos en los objetos con diferentes valores o para la distincin como diferentes tipos de objetos, entonces deber o amos crear una nueva clase para la distincin. o Considerar potenciales instancias individuales de una clase puede ser tambin 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

Usualmente, cuando usamos propiedades extr nsecas en lugar de intr nsecas de los conceptos para diferenciarlos entre las clases, las instancias de esas clases tendrn 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 fcilmente dejar de ser una instancia de esta clase y llegar a ser llegar a ser instancia de esta a clase de nuevo. Usualmente, los nmeros, colores, localizaciones son valores de slots y no conducen a la u creacin de nuevas clases. En el caso del vino, sin embargo, existe una notable excepcin puesto o o que el color del vino es primordial para la descripcin del vino. o Tomemos otro ejemplo, consideremos una ontolog de la anatom humana. Cuando repa a ra costilla izquierda, 2da costilla izquierda y resentamos las costillas, creamos clases para 1 as sucesivamente? O creamos una clase Costilla con slots para el orden y la posicin lateral o (izquierda-derecha)?5 Si al informacin de cada costilla que representamos en la ontolog es o a signicativamente diferente, entonces deber amos de hecho crear una clase para cada una de las costillas. Es decir, si deseamos representar detalles de la informacin de adyacencia y loo calizacin (la cual es diferente para cada costilla) como tambin funciones espec o e cas 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 simplicar nuestra jerarqu a y tener simplemente la clase Costilla, con dos slots: posicin 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 cules son las aplicaciones potenciales de la ontolog Decidir dnde las clases terminan y a a. o las instancias comienzan, empieza por la decisin de cul es el nivel ms bajo de granularidad en o a a la representacin. El nivel de granularidad es a su vez determinado por una aplicacin potencial o o de la ontolog En otras palabras, ?Cules son los a. a tems ms espec a cos que representaremos en la base de conocimientos? Volviendo a las preguntas de competencia que hemos identicado en el Paso 1 de la Seccin 3, los conceptos ms espec o a cos que constituirn respuestas a esas a preguntas sern muy buenos candidatos para ser individuos en la base de conocimientos. a La instancias individuales son los conceptos ms espec a cos representados en una base de conocimientos. Por ejemplo, si solo hablaremos del emparejado de vinos con alimentos, no estaremos interesados en espec cas botellas f sicas de vino. Por lo tanto, trminos como Sterling Vineyards e Merlot sern probablemente los trminos ms espec a e a cos 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 adems de la a base de conocimientos de buenas parejas vino-alimento, las botellas individuales de cada vino llegarn a ser instancias individuales en nuestra base de conocimientos. a De manera similar, si deseamos registrar las diferentes propiedades de cada cosecha espec ca de los Sterling Vineyards Merlot, entonces la cosecha espec ca de vino es una instancia en
Asumimos que cada rgano anatmico es una clase puesto que queremos tambin 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.
5

21

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 produccin de vino. Inicialmente, podemos denir regiones o principales produccin de vino, tales como Francia, Estados Unidos, Alemania, y as sucesivao mente, como clases, y regiones espec cas de produccin de vino dentro esas grandes regiones o como instancias. Por ejemplo, la regin de Borgoa es una instancia de la clase de Regin o n o Francesa. Sin embargo, tambin quisiramos decir que la Regin Cotes dOr es una Regin e e o o de Borgo~a. En consecuencia, la Regin de Borgo~a debe ser una clase (para tener subclases n o n o instancias). Sin embargo, parece arbitrario hacer que la Regin de Borgo~a sea una clase y o n que la Regin Cotes dOr sea una instancia de la Regin de Borgo~a: es muy dif distino o n cil guir claramente qu regiones son clases y cules son instancias. Por lo tanto, denimos todas e a las regiones de produccin de vino como clases. Protg-2000 permite a los usuarios especio e e car 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 produccin de vino son o abstractas (Figura 8).

Figure 8: Jerarqu de las regiones de produccin 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 regin 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 regin de Alsacia es un tipo de o regin de Francia. o Solamente las clases pueden ser dispuestas en una jerarqu (los sistemas de representacin a o de conocimiento no tienen la nocin de de sub-instancia). Por lo tanto, si existe una jerarqu o a natural entre los trminos, como en las jerarqu terminolgicas de la Seccin 4.2, debemos e as o o denir esos trminos como clases aunque no tengan ninguna instancia propia. e

22

4.7

Limitacin del alcance o

Como nota nal sobre la denicin 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 informacin posible del dominio: no necesitas a a o especializar (o generalizar) ms de lo que necesitas para tu aplicacin (como mximo 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 cmo 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 ms sobresalientes de las clases de a tems en nuestra ontolog Aunque los libros de vinos nos dirn el tamao de las uvas, no incluimos ese a. a n conocimiento. De manera similar, no hemos agregado todas las relaciones que podr amos imaginar entre todos los trminos de nuestro sistema. Por ejemplo, no incluimos las relaciones tales e como vino favorito o alimento preferido en la ontolog para tener una representacin ms a o a completa de todas las interconexiones entre los trminos que hemos denido. e Las ultimas reglas tambin se aplican para establecer relaciones entre conceptos que ya e los hemos incluido en la ontolog a. Consideremos una ontolog que describe experimentos a biolgicos. La ontolog probablemente contendr un concepto de Organismos Biolgicos. o a a o Tambin contendr el concepto de un Experimentador que ejecuta un experimento (con su e a nombre, aliacin, etc.). Es cierto que un experimentador es una persona, y como persona, o tambin es casualmente un organismo biolgico. Sin embargo, probablemente no debamos e o incorporar esta distincin en la ontolog para los propsitos de esta representacin un experio a: o o mentador no es un organismo biolgico y probablemente nunca ejecutemos experimentos en los o experimentadores como tal. Si estuviesemos representando todo lo que podamos decir de las clases en la ontolog un Experimentador llegar a ser una subclase de Organismo Biolgico. a, a o Sin embargo, no necesitamos incluir este conocimiento para las aplicaciones previsibles. De hecho, la inclusin de este tipo de clasicacin 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 biolgico, pero absolutamente irrelevantes en el contexto o de la descripcin de un experimento. Sin embargo, debemos registrar tal decisin de diseo en o o n la documentacin para el benecio de los usuarios que mirarn esta ontolog y que no estarn o a a a enterados de la apliacin que ten o amos en mente.

4.8

Subclases disjuntas

Muchos sistemas nos permiten especicar expl citamente que varias clases sean disjuntas. La clases son disjuntas si no pueden tener ninguna instancia en comn. 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: ningn vino puede ser simultneamente rojo y blanco. La especicacin 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

Denicin de las propiedades (ms detalles) o a

En esta seccin discutimos muchos ms detalles a tener en cuenta cuando denimos los slots de o a una ontolog (Paso 5 y Paso 6 de la Seccin 3). Principalmente, discutiremos sobre los roles a o inversos y valores por defecto de un slot.

5.1

Slots inversos

Un valor de un slot puede depender de un otro valor de otro slot Por ejemplo, si un vino fue producido por un establecimiento vincola, entonces el establecimiento vincola produce ese vino. Esas dos relaciones, productor y produce, son llamadas relaciones inversas. Almacenar la informacin en ambos sentidos es redundante. Cuando sabemos que o un vino es producido por un establecimiento vin cola, una aplciacin que usa una base de o conocimientos puede siempre inferir el valor de la relacin inversa: el establecimiento vin o cola produce el vino. Sin embargo, desde la perspectiva de adquisicin de conocimiento, es conveo niente tener ambas piezas de la informacin disponibles expl o citamente. Este enfoque permite a los usuarios introducir vinos en algunos casos y establecimientos vin colas en otros. El sistema de adquisicin de conocimiento podr entonces completar automticamente el valor de la o a a relacin inversa asegurando la consistencia de la base de conocimientos. o Nuestro ejemplo tiene un par de slots inversos: el slot productor de la clase Vino y el slot produce de la clase Establecimiento Vincola. Cuando un usuario crea una instancia de la clase Vino e introduce el valor para el slot productor, el sistema automticamente aade a n la instancia recin creada al slot produce de la instancia correspondiente Establecimiento e Vincola. Por ejemplo, cuando decimos que el Sterling Merlot es producido por el establec imiento vin cola Vi~edos Sterling, el sistema automticamente agregar Sterling Merlot n a a a la lista de vinos que el establecimiento vin cola Vi~edos Sterling (Sterling Vineyard) n produce (Figura 9).

5.2

Valores por defecto

Muchos sistemas basados en marcos permiten la especicacin de valores por defecto para los o slots. Si un valor particular de un slot es el mismo para la mayor de las instancias de una a clase, podemos entonces denir como el valor por defecto para el slot. Entonces, cuando cada nueva instancia de una clase que contenga este slot sea creada, el sistema lo llenar con el valor a por defecto automticamente. Luego podemos cambiar ese valor a otro valor que las facetas a lo permitan. Es decir, los valores por defecto estn ah por comodidad: no imponen ninguna a nueva restriccin sobre el modelo ni cambian el modelo en alguna forma. o Por ejemplo, si la mayor de los vinos de los cuales vamos a discutir son vinos de cuerpo a completo, podemos tener completo como valor por defecto para el cuerpo del vino. Entonces, a menos que indiquemos otra cosa, todos los vinos que denamos sern de cuerpo completo. a Notar que esto es diferente de los valores de los slots. Los valores de los slots no pueden ser cambiados. Por ejemplo, podemos decir que el slot azcar tiene el valor DULCE para la u clase Vinos de Sobremesa. Entonces, todas las subclases e instancias de la clase Vino de Sobremesa tendrn el valor DULCE para el slot azcar. Este valor no puede ser cambiado en a u ninguna de las subclases ni instancias de la clase.

Qu est en un nombre? e a

La denicin de convenios sobre los nombres de los conceptos en una ontolog y su uso estricto, o a no solamente que la ontolog sea fcil de entender sino tambin ayuda a evitar algunos errores a a e 24

Figure 9: Instancias de slots inversos. El slot produce (produces) de la clase Establecimiento Vincola (Winery) es un slot inverso del slot productor (maker) de la clase Vino. El llenado de uno de esos slots activa una actualizacin automtica del otro. o a comunes de modelamiento. Existen muchas alternativas para nombrar los conceptos. A menudo no hay ninguna razn particular para elegir un o otra alternativa. Sin embargo, necesitamos: o denir un convenio de nombrado de clases y slots, y adherirnos estrictamente a ste. e La siguientes caracter sticas de un sistema de representacin de conocimiento afectan la o eleccin de convenios de nombrado: o Tiene el sistema el mismo espacio de nombres para las clases, slots e instancias? Es decir, permite el sistema tener una clase y un slot con el mismo nombre (tales como la clase establecimiento vincola y el slot establecimiento vincola)? El sistema diferencia entre maysculas y minsculas? Es decir, el sistema trata los u u nombres de manera diferente si si estn escritos en maysculas o minsculas (tales como a u u Establecimiento Vincola y establecimiento vincola)? Qu delimitadores permite el sistema en los nombres? Es decir, los nombres pueden e contener espacios, comas, asteriscos y as por el estilo? Protg-2000, por ejemplo, mantiene un solo espacio de nombres para todos sus marcos. e e Diferencia entre maysculas y minsculas. En consecuencia, no podemos tener una clase u u establecimiento vincola y un slot establecimiento vincola. Sin embargo, podemos tener una clase Establecimiento Vincola (maysculas) y un slot establecimiento vincola. u CLASSIC, por otro lado, no diferencia entre maysculas y minsculas y mantiene diferentes esu u pacios de nombres para las clases, slots e individuos. De esa manera, desde la perspectiva del sistema, no hay problema en nombrar la clase y el slot Establecimiento Vincola. 25

6.1

May sculas/min sculas y delimitadores u u

Primero, podemos mejorar enormemente la legibilidad de una ontolog si usamos de manera a consistente los convenios sobre maysculas y minsculas para los nombres de conceptos. Por u u ejemplo, es practica comn el escribir en maysculas los nombres de las clases y usar minsculas u u u en los nombres de los slots (asumiendo que el sistema diferencia entre maysculas y minsculas). u u Cuando el nombre de un concepto contiene ms de una palabra (tal como Plato de comida) a necesitamos delimitar las palabras. Aqu hay algunas posibles opciones: Usar espacios: Plato de comida (muchos sistemas, incluyendo, Protg, permiten espae e cios en los nombres de conceptos). Escribir todas las palabras juntas y poner en maysculas cada nueva palabra: PlatoDeComida. u Usar un subrayado o guin u otro delimitador en el nombre: Plato De Comida, Plato de comida, o Plato-De-Comida, Plato-de-comida. (Si usas delimitadores, necesitars tambin decidir a e si cada nueva palabra debe comenzar con una letra en maysculas). u Si el sistema de representacin permite espacios en los nombres, su uso ser la solucin ms o a o a intuitiva para muchos desarrolladores de ontolog as. Es, sin embargo, importante considerar otros sistemas con los cuales tu sistema podr interactuar. Si esos sistemas no usan espacios o a si tu medio de presentacin no maneja bien los espacios, ser util usar otro mtodo. o a e

6.2

Singular o Plural

Un nombre de una clase representa una coleccin de objetos. Por ejemplo, la clase Vino repo resenta a todos los vinos. Por lo tanto, ser ms natural para algunos diseadores nombrar la a a n clase Vinos en lugar de Vino. Ninguna alternativa es mejor o peor que otra (aunque la forma singular para las clases es usada ms a menudo en la prtica). Sin embargo, cualquiera sea a a la eleccin, debe ser consistente a lo largo de toda la ontolog Algunos sistemas solicitan a o a. sus usuarios declarar por adelantado si ellos usarn singular o plural para los nombres de los a conceptos y no permiten desviarse de esa eleccin. o El uso de la misma forma todo el tiempo tambin previene al diseador de cometer errores e n de modelamiento como crear una clase Vinos y luego crear una clase Vino como su subclase (ver Seccin 4.1). o

6.3

Convenios: prejos y sujos

Algunas metodolog de bases de conocimiento sugieren usar convenios sobre el uso de prejos as y sujos en los nombres para distinguir entre clases y slots. Dos prcticas comunes son: aadir a n tiene- como prejo o el sujo -de a los nombres de los slots. De esta forma, nuestro slots sern a tiene-productor y tiene-establecimiento vincola si elegimos el convenio que sugiere el uso de tiene-. Si elegimos usar el convenio que sugiere que se emplee -de, los slots sern a productor-de y establecimiento vincola-de. Este enfoque permite que los usuarios vean el trmino para poder determinar inmediatamente si el trmino es una clase o slot. Sin embargo, e e los nombres de los trminos llegan a ser ligeramente largos. e

6.4

Otras consideraciones de nombrado

Aqu estn unas cuantas cosas ms a considerar cuando se denan los convenios de nombrado: a a

26

 No agregar cadenas tales como clase, propiedad, slot, y as sucesivamente a los nombres de conceptos. Siempre est claro a partir del contexto si el concepto es una clase a o un slot. Adems, si usas diferentes convenios de nombrado para las clases y slots (por a ejemplo, maysculas y minsculas respectivamente), el nombre como tal ser indicativo u u a de qu es el concepto. e Usualmente es buena idea evitar abreviaciones en los nombres de conceptos (es decir, usar Cabernet Sauvignon en lugar de Cab). Los nombres de las subclases directas de una clase deber todas incluir o no incluir el an nombre de la superclase. Por ejemplo, si estamos creando dos subclases de la clase Vino para representar vinos rojos y vinos blancos, los dos nombres de las subclases deber an ser Vino Rojo y Vino Blanco, y no as Vino Rojo y Blanco.

Otros recursos

Hemos usado Protg-2000 como entorno de desarrollo de ontolog para nuestros ejemplos. e e as Duineveld y sus colegas (Duineveld et al. 2000) describen y comparan otros entornos de desarrollo de ontolog as. Hemos tratado de introducir los fundamentos del desarrollo de ontolog y no hemos disas cutido muchos de los tpicos avanzados o metodolog alternativas para el desarrollo de ono as tolog as. Gmez-Prez (Gmez-Prez 1998) y Uschold (Uschold y Gruninger 1996) presentan o e o e metodolog alternativas para el desarrollo de ontolog as as. El tutorial Ontolingua (Farquhar 1997) discute algunos aspectos formales del modelamiento de conocimiento. Actualmente, los investigadores enfatizan no solamente el desarrollo de ontolog as, sino tambin el anlisis de ontolog e a as. Por ejemplo, Chimaera (McGuinness et al. 2000) provee herramientas de diagnstico para analizar ontolog o as. El anlisis que Chimaera desempea a n incluye una vericacin de la exactitud lgica de una ontolog y un diagnstico de errores o o a o comunes de diseo de ontolog n as. Un diseador de ontolog podr ejecutar diagnsticos n as a o con Chimaera sobre la ontolog que evoluciona para determinar la conformidad con practicas a comunes de modelamiento de ontolog as.

Conclusiones

En esta gu hemos descrito una metodolog de desarrollo de ontolog para sistemas declara, a as ativos basados en marcos. Listamos los pasos del proceso de desarrollo de ontolog y hicimos as referencia a los aspectos complejos de la denicin de jerarqu de clases y propiedades de clases o as e instancias. Sin embargo, despus de seguir todas las reglas y sugerencias, una de las cosas e ms importantes que recordar es la siguiente: no hay sola ontolog correcta para un dominio a a dado. El diseo de ontolog es un proceso creativo y dos ontolog diseadas por personas n as as n diferentes no sern iguales. Las aplicaciones potenciales de la ontolog y el entendimiento y a a aspecto del dominio desde el punto de vista del diseador afectarn sin duda las opciones de n a diseo de la ontolog No se sabe si algo es bueno hasta que se lo pone a prueba: podemos n a. evaluar la calidad de nuestra ontolog solamente usndola en aplicaciones para las cuales la a a diseamos. n

27

Agradecimientos

Protg-2000 (http://protege.stanford.edu) fue desarrollado por el grupo de Mark Mune e sen en el centro de Informtica Medical de Stanford (Stanford Medical Informatics). Gena eramos algunas de las guras con el plug-in OntoViz de Protg-2000. Importamos la vere e sion inicial de la ontolog de vinos a partir de la biblioteca de ontolog Ontolingua (http: a as //www.ksl.stanford.edu/software/ontolingua/) la cual a su vez us una versin publio o cada por Brachman y sus colegas (Brachman et al. 1991) y distribuida con el sistema de representacin de conocimiento CLASSIC. Luego modicamos la ontolog para presentar los o a principios del modelamiento conceptual para ontolog declarativas basadas en marcos. Los coas mentarios de Ray Fergerson y Mor Peleg sobre los borradores iniciales mejoraron enormemente este art culo.

References
[1] Booch, G., Rumbaugh, J. and Jacobson, I. (1997). The Unied Modeling Language user guide: Addison-Wesley. [2] Brachman, R.J., McGuinness, D.L., Patel-Schneider, P.F., Resnick, L.A. and Borgida, A. (1991). Living with CLASSIC: When and how to use KL-ONE-like language. Principles of Semantic Networks. J. F. Sowa, editor, Morgan Kaufmann: 401-456. [3] Brickley, D. and Guha, R.V. (1999). Resource Description Framework (RDF) Schema Specication. Proposed Recommendation, World Wide Web Consortium: http://www.w3.org/ TR/PR-rdf-schema. [4] Chimaera (2000). Chimaera Ontology Environment. www.ksl.stanford.edu/software/ chimaera [5] Duineveld, A.J., Stoter, R., Weiden, M.R., Kenepa, B. and Benjamins, V.R. (2000). WonderTools? A comparative study of ontological engineering tools. International Journal of Human-Computer Studies 52(6): 1111-1133. [6] Farquhar, A. (1997). Ontolingua tutorial. http://ksl-web.stanford.edu/people/axf/ tutorial.pdf [7] Gmez-Prez, A. (1998). Knowledge sharing and reuse. Handbook of Applied Expert Syso e tems. Liebowitz, editor, CRC Press. [8] Gruber, T.R. (1993). A Translation Approach to Portable Ontology Specication. Knowledge Acquisition 5: 199-220. [9] Gruninger, M. and Fox, M.S. (1995). Methodology for the Design and Evaluation of Ontologies. In: Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing, IJCAI-95, Montreal. [10] Hendler, J. and McGuinness, D.L. (2000). The DARPA Agent Markup Language. IEEE Intelligent Systems 16(6): 67-73. [11] Humphreys, B.L. and Lindberg, D.A.B. (1993). The UMLS project: making the conceptual connection between users and the information they need. Bulletin of the Medical Library Association 81(2): 170. 28

[12] McGuinness, D.L., Abrahams, M.K., Resnick, L.A., Patel-Schneider, P.F., Thomason, R.H., Cavalli-Sforza, V. and Conati, C. (1994). Classic Knowledge Representation System Tutorial. http://www.bell-labs.com/project/classic/papers/ClassTut/ClassTut. html [13] McGuinness, D.L., Fikes, R., Rice, J. and Wilder, S. (2000). An Environment for Merging and Testing Large Ontologies. Principles of Knowledge Representation and Reasoning: Proceedings of the Seventh International Conference (KR2000). A. G. Cohn, F. Giunchiglia and B. Selman, editors. San Francisco, CA, Morgan Kaufmann Publishers. [14] McGuinness, D.L. and Wright, J. (1998). Conceptual Modeling for Conguration: A Description Logic-based Approach. Articial Intelligence for Engineering Design, Analysis, and Manufacturing - special issue on Conguration. [15] Musen, M.A. (1992). Dimensions of knowledge sharing and reuse. Computers and Biomedical Research 25: 435-467. [16] Ontolingua (1997). Ontolingua System Reference Manual. http://www-ksl-svc. stanford.edu:5915/doc/frame-editor/index.html [17] Price, C. and Spackman, K. (2000). SNOMED clinical terms. BJHC&IM-British Journal of Healthcare Computing & Information Management 17(3): 27-31. [18] Protg (2000). The Protg Project. http://protege.stanford.edu e e e e [19] Rosch, E. (1978). Principles of Categorization. Cognition and Categorization. R. E. and B. B. Lloyd, editors. Hillside, NJ, Lawrence Erlbaum Publishers: 27-48. [20] Rothenuh, T.R., Gennari, J.H., Eriksson, H., Puerta, A.R., Tu, S.W. and Musen, M.A. (1996). Reusable ontologies, knowledge-acquisition tools, and performance systems: PROTEGE-II solutions to Sisyphus-2. International Journal of Human-Computer Studies 44: 303-332. [21] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W. (1991). Objectoriented modeling and design. Englewood Clis, New Jersey: Prentice Hall. [22] Uschold, M. and Gruninger, M. (1996). Ontologies: Principles, Methods and Applications. Knowledge Engineering Review 11(2).

29