Manejo hbrido local y global de Ontologas en un Sistema Multiagente
Hctor G. Ceballos y Ramn F. Brena
Instituto Tecnologico de Monterrey, Campus Monterrey
Centro de Sistemas Inteligentes
Monterrey, Mexico
RESUMEN
A medida que el conocimiento Ontolgico cobra ms
importancia en sistemas basados en agentes, su manejo se
vuelve crucial para aplicaciones exitosas. Pero colocar to-
das las capacidades para el manejo de ontologas en cada
uno de los agentes del sistema puede volverlo demasiado
pesado. Proponemos un enfoque hbrido en el cual parte
de la ontologa es manejada localmente, usando un com-
ponente cliente, y el resto del conocimiento sobre la on-
tologa es manejado por un agente de ontologas, el cual combinar ontologas centralizadas con ontologas distru-
es accesado por otros agentes en el sistema a travs de
su componente cliente. Proponemos mtodos especficos
para representar, almacenar, consultar y traducir ontologas
para su uso efectivo en el contexto del sistema JITIK, el
cual es un sistema multiagentes para distribucin de cono-
cimiento e informacin. Asmismo reportamos la imple-
mentacin de un prototipo operativo de nuestra propuesta.
1 INTRODUCCIN
Es ampliamente aceptado que la comunicacin es un re-
querimiento absoluto para la mayora de las aplicaciones
de sistemas multiagentes. An cuando la comunicacin
a nivel sintctico no est completamente resuelta, lo ms
retador ahora es tomar en cuenta el significado de los men-
sajes de los agentes. Este es uno de los aspectos cruciales
que tenemos que tratar para construir aplicaciones reales
basadas en agentes[3].
El trmino ontologa se refiere a la definicin de los
significados de trminos usados en comunicaciones en-
tre agentes[4]. Las ontologas permiten definir concep-
tos y sus relaciones, propiedades, operaciones, y todo
ello en forma estructurada. Estndares abiertos como
DAML+OIL[12], o ms recientemente OWL[14], per-
miten publicar conocimiento ontolgico en una manera en-
tendible tanto por humanos como por mquinas.
Pero an teniendo una representacin estndar, hay que
decidir dnde poner cada pieza de conocimiento a repre-
sentar. Algunos esfuerzos como el proyecto Cyc[16] sug-
ieren construir un enorme repositorio centralizado de co-
nocimiento enciclopdico. Otros consideran esto imprc-
tico en trminos de desempeo y robustez, y prefieren en-
foques descentralizados[6]. Pero manejar ontologas dis-
tribudas genera nuevos problemas como: 1) dnde poner
o de dnde tomar las piezas de conocimiento, esto es,
cmo distribuir el conocimiento; 2) cmo mantener algn
grado de coherencia entre las diferentes piezas -o inclusive
versiones- de conocimiento ontolgico.
El mtodo que presentaremos en este trabajo est dis-
eado para ser usado en el contexto del proyecto JITIK[5].
JITIK -que significa Just-In-Time Information and Knowl-
edge- es un sistema basado en multiagentes para distribuir
piezas de conocimiento entre los miembros de una orga-
nizacin grande o distribuida, por esto soporta la funcin
de administracin de conocimiento. A pesar de que nues-
tra propuesta de manejo de ontologas fue primariamente
orientada para su aplicacin en el sistema JITIK, lo cual
impone una arquitectura as como otras restricciones, es
aplicable en principio a un amplio rango de sistemas basa-
dos en agentes.
1.1 Nuestro enfoque
En este trabajo proponemos una solucin a uno de los as-
pectos de esta problemtica: proponemos un mtodo para
ibidas. Consideramos un repositorio central encapsulado
en un agente de ontologias, (AO) que provee respues-
tas a preguntas acerca de la ontologa a otros agentes en
el sistema. Pero adems de eso, dotamos a cada agente
en el sistema con un componente cliente de la ontologa
(CCO), el cual le proporciona las capacidades bsicas para
manejo de ontologas. Este esquema funciona de la sigu-
iente manera:
Los agentes regulares inician con un subconjunto
de la ontologa comn, la cual es cargada al arranque
desde un recurso en internet.
Los agentes regulares utilizan sus ontologas locales,
manejadas por el CCO, mientras su conocimiento lo-
cal sea suficiente para la actividad del agente.
Cuando ms conocimiento es requerido -por ejemplo,
un trmino desconocido llega desde otro agente- el
CCO consulta al AO, y recibe un anexo a la ontologa
bsica, que le permite al agente continuar trabajando.
El CCO almacena localmente la adicin a la ontologa
para poderla usar en el futuro.
Esta solucin simplifica alguna de las complejidades inher-
entes de la distribucin de conocimiento, porque:
1. No hay riesgo de incoherencia -cada pieza de cono-
cimiento viene a final de cuentas de una ontologa
comn- ya sea desde la ontologa inicial o como re-
sultado de una consulta al AO.
2. No hay decisiones a priori acerca de cmo distribuir o
especializar el conocimiento, porque el conocimiento
local se va especializando automticamente a medida
que la operacin del agente procede.
Hacemos notar, sin embargo, que este enfoque no es ade-
cuado para todo tipo de situaciones. En particular, en
ambientes abiertos y dinamicos como el internet, donde
concurren ontologias distintas y hasta contradictorias, no
se puede sostener la hipotesis de una ontologia global y
coherente. Sin embargo, en ambientes tales como una
empresa en particular, nuestra hipotesis de una ontologia
global es perfectamente razonable.
En la seccin 2 detallamos nuestro mtodo. La seccin
4 describe un prototipo funcional. Los resultados de los
experimentos se presentan en la seccin 5. En la seccin
6 presentamos algunos trabajos relacionados, y finalmente
en la seccin 7 damos algunas conclusiones.

Figure 1: Agentes de JITIK
2 SOLUCIN PROPUESTA PARA
MANEJO DE ONTOLOGAS EN JITIK
En la figura 1 mostramos la arquitectura de JITIK, com-
puesta por varios tipos de agentes, como el agente de Sitio,
quien tiene a su cargo la distribucin de informacin a dis-
tintos agentes personales, los cuales interactan con un
usuario final; tambin hay agentes bridge para interactuar
con programas tradicionales (aplicaciones heredadas). Los
agentes de sitio son el corazn de un grupo compuesto
por un agente de sitio y varios agentes personales atendidos
por el primero. En una organizacin, los grupos pueden
estar asociados a departamentos, divisiones, etc., depen-
diendo del tamao de estos. Las redes pueden ser hechas
conectando varios agentes de sitio. Las organizaciones dis-
tribuidas como compaas multinacionales pueden tener
una red de muchos agentes de sitio conectados. Tambin
hay agentes de ontologa, los cuales discutiremos a contin-
uacin.
Desde el punto de vista de manejo de ontologas,
podemos clasificar los agentes en dos categoras: agentes
de ontologas, y agentes regulares, que son todos
los otros agentes. Algunas veces llamaremos agentes
clientes a los agentes regulares, porque actan como
un cliente respecto al agente de ontologas. El AO y los
clientes corresponden a los roles iniciador y responde-
dor en metodologas estndar de diseo de agentes como
[7].
Los agentes regulares accesan las ontologas a travs del
CCO previamente introducido, y el CCO eventualmente se
comunica con el AO. La arquitectura tanto del agente de
ontologas como del agente cliente se muestra en la figura
2. Ah se muestra al AO en el lado izquierdo, con algunos
componentes internos que se discuten posteriormente, y un
agente cliente en el lado derecho, donde el CCO aparece
etiquetado como Vista Dinmica de la Ontologa por
las razones que vamos a explicar. Pero antes de discutir
los detalles internos del AO y del CCO, debemos tratar
algunos aspectos esenciales de manejo de ontologas que
impactarn en gran medida el diseo del AO y del CCO.
Principalmente, tenemos que presentar nuestras opciones
de codificacin de ontologas, de formatos y de almace-
namientos, lenguajes y mtodos de consulta, y finalmente
interpretacin de respuesta y manejo del lado del cliente.
2.1 Agente de ontologas y Agentes clientes
El AO encapsula la funcionalidad para jugar el rol de
proveedor de conocimiento, almacenar la ontologa conve-
nientemente codificada, traducir, interpretar y ejecutar las
consultas recibidas, y luego traducir los resultados a un for-
mato entendible por los agentes clientes. Esta separacin
de formatos provee una capa de independencia, de manera
que la representacin de la ontologa pueda ser cambiada
en el AO sin impactar a los agentes clientes.
Los agentes clientes acceden las definiciones de la on-
tologa a travs de su CCO. Al arranque cargan una on-
tologa base, la cual es evidentemente dependiente de la
aplicacin, y tratan de usarla mientras sea suficiente para
su operacin. En el sistema JADE[1], las ontologas son
necesarias para propsitos de validacin de mensajes en
primera instancia. Cada trmino en las conversaciones de
los agentes debe ser validado contra una definicin en la
ontologa. Por esto, normalmente la ontologa base con-
tendr definiciones de trminos comunes y poco especial-
izados. El tamao de la ontologa base debe hallar un punto
de equilibrio entre eficiencia en espacio -lo que lleva a una
ontologa inicial pequea- y eficiencia en tiempo -lo que
lleva a maximizar la cobertura del conocimiento local de
manera que se minimizen las consultas remotas.
2.2 Mecanismo de Consulta
Caracterizamos el mecanismo de consulta en tres partes:
lenguaje de consulta, motor de consulta y formato de re-
spuesta. Agrupamos estos tres elementos pues su imple-
mentacin esta ntimamente relacionada.
Investigamos varios lenguajes de consulta, encontrando
que actualmente la mayora de ellos estn orientados a
RDF. Uno de los lenguajes de consulta ms simples que
estudiamos fue RQL [15], que a pesar de estar orientado
a RDF, tiene una sintaxis similar a SQL, as que la codifi-
cacin de consultas no es difcil. Aunque a final de cuentas
utilizamos Jena Toolkit pues nos permita tener un mecan-
ismo de consulta integrado y porttil en Java.
El motor de consultas es responsable de resolver las con-
sultas hechas a la ontologa. Su desempeo ser uno de los
factores ms crticos en el desempeo global del AO, dado
que estar respondiendo constantemente preguntas prove-
nientes de otros agentes. Un ejemplo de motor de consulta
es RQL sobre RSSDB de RDFSuite[9]. Jena cuenta con
un motor de consulta (RDQL), adems de mtodos de con-
sulta sobre la ontologa.
Las respuestas a las consultas se codifican en un for-
mato de respuesta. Una vez que el cliente reciba una
respuesta del AO, puede procesar su informacin. Este
procesamiento-decodificacin puede ser costoso tanto para
el agente cliente como para el AO si no se eligen formatos
adecuados.
Entre los formatos de respuesta disponibles encon-
tramos RDF sobre XML, y los formatos de frames provis-
tos por el soporte para ontologas de JADE. RSSDB arroja
respuestas en XML, as que hay que hacer la traduccin
a frames de JADE, ya sea en el servidor o en el cliente.
Consideramos preferible hacer la traduccin en el lado del
servidor (el AO), porque de esta forma el proceso se vuelve
transparente para los agentes clientes, y as un remplazo de
tecnologa en el AO no tiene que ser notado en los agentes
clientes.
2.3 Interpretacin de Resultados
La ltima parte del proceso que estamos describiendo
ocurre dentro del agente cliente, el cual tiene que inter-
pretar el resultado que arriba del AO como una respuesta
a una consulta, basndose en la metaontologa. Dicha in-
terpretacin es esencialmente un mapeo entre las respues-
tas a las consultas y las estructuras internas del agente.
Este mapeo puede ser hecho manual (por el programador
mismo) o automticamente. El mapeo puede automati-
zarse en varios niveles, desde la conversin automtica
de respuestas de consultas a una estructura del programa,
hasta proveer interpretacin transparente de un concepto
desconocido.
3 EL COMPONENTE CLIENTE DE LA
ONTOLOGA (CCO)
El acceso local a la ontologa se encapsula en el CCO el
cual es incorporado en el agente cliente. Al arranque del
agente, el CCO es responsable de obtener -normalmente de
 Figure 2: Arquitectura para manejo de ontologas
una direccin en internet- una ontologa base. Este mecan-
ismo es suficientemente general para ser personalizado de
manera que diferentes tipos de agentes carguen diferentes
ontologas base, a pesar de que no hicimos esto en nuestro
prototipo.
Para subsanar las limitaciones de la ontologa base, el
CCO es responsable de accesar al AO para extender su co-
nocimiento sobre la ontologa, a travs de mecanismos de
consulta que hemos descrito. Los resultados de la consulta
son incorporados por el CCO a la ontologa local, exten-
diendo automticamente la ontologa conforme sea nece-
sario.
En este modelo, la existencia del AO es transparente al
agente cliente, dado que este ltimo dirige todas sus con-
sultas al CCO, ste toma a su cargo el proceso completo
hasta que llega una respuesta al agente -ya sea que venga
de una consulta al CCO o de una consulta del CCO al AO.
Como se puede ver en el diagrama de la figura 2, el CCO
tiene los siguiente elementos:
Representacin Local de la Ontologa. Permite alma-
cenar un subconjunto de la ontologa y soporta con-
sultas locales.
Resolvedor Local de Consultas. Sirve de interfaz en-
tre el agente mismo y la vista de la ontologa. Provee
mtodos usados por el agente para consultar acerca de
los esquemas o instancias en la ontologa.
Validacin de Mensajes. Dado que el CCO contiene
definiciones de trminos de la ontologa base y de las
consultas al AO, permite validar mensajes en trminos
de una ontologa, como es requerido por la plataforma
JADE.
Contenedor de Esquemas y de Instancias. Deseamos
que la informacin de esquemas est separado de la
informacin de instancias por razones de desempeo,
particularmente cuando involucra un nmero grande
de instancias. La informacin de instancias puede ser
accesada ya sea directamente desde el agente cliente
o exportando a una clase Java a travs del uso del In-
trospector.
Mecanismo de Agregacin. El nuevo conocimiento
proveniente del AO como respuesta a una consulta es
incorporada en la vista local. Por supuesto, el uso im-
prudente de esta caracterstica puede degradar el de-
sempeo del CCO.
4 PROTOTIPO
Hemos desarrollado una implementacin algo simplificada
de las ideas presentadas aqu. Las simplificaciones que in-
trodujimos fueron las siguientes:
A pesar de que trabajamos con el paquete RDFSuite,
y de hecho construimos un prototipo muy bsico con
esta tecnologa, slo soport ontologas RDF. As que
tenamos que desarrollar la traduccin mencionada de
estructuras JADE a RQL. Decidimos nicamente usar
el paquete Jena en su lugar, el cual en algn punto
de nuestro proyecto incorpor almacenamiento per-
sistente, volvindose as una solucin muy atractiva.
Descartamos RDFSuite por lo mismo.
El acceso a las ontologas en los agentes clientes y
en el AO era idntico, ambos basados en una clase
ClientOntology que desarrollamos, la cual utiliza car-
actersticas del paquete Jena. ClientOntology es im-
plementado tanto en el CCO como en el AO.
El CCO no redirecciona automticamente las consul-
tas al AO. En lugar de eso, el agente cliente especifica
con cul componente hacer la consulta, ya sea al CCO
o al AO.
No se hace distincin entre instancias y esquemas
para propsitos de almacenamiento.
4.1 Formato de Ontologa
Utilizamos particularmente RDF[13] y DAML+OIL[12]
como lenguaje de representacin. RDF, con su extensin
RDFS, contiene todos los elementos mnimos necesarios
para representar nuestras ontologas, pero DAML+OIL
provee mejores caractersticas ontologcas que nos permi-
tiran extender nuestro sistema en un futuro.
Buscamos un software intermedio que encapsulara el ac-
ceso a la ontologa, de forma que cualquier cambio en el
formato permaneciera local al software y transparente para
el resto del sistema. Se eligi Jena Toolkit [8] para esta
tarea. Jena est conformado de libreras JAVA para manejo
de ontologas RDF y DAML+OIL.
4.2 Estructura del prototipo
Un componente encapsulado en la clase
xont.ClientOntology constituye el ncleo del prototipo.
Dicho componente aparece tanto en el agente cliente como
en el AO. Sus elementos principales son: 1) la ontologa
DAML es almacenada utilizando Jena Toolkit; 2) hay un
Resolvedor de Consultas, el cual traduce las consultas de
frames JADE a llamadas de mtodos Jena; 3) en el lado
del AO los resultados son ensamblados en la forma de
frames JADE, para ser enviados al agente cliente.
En el agente cliente se pueden encontrar los Conceptos
Dinmicos JADE que constituyen las estructuras ontolg-
icas JADE que almacenan la ontologa DAML leda por
medio de Jena. La ontologa en el CCO tiene un formato
doble, por una parte se almacena en estructuras de Jena
(DAML+OIL) y por otra en estructuras de JADE (frames).
Ambas versiones estn sincronizadas y tienen usos distin-
tos: la primera se utiliza para hacer consultas, mientras
que la segunda permite que JADE valide los mensajes en-
tre agentes.
Un problema tcnico para construir las ontologas
JADE en paralelo es que los conceptos JADE no pueden
pertenecer a varias clases al mismo tiempo. Para resolver
esta incompatibilidad, introdujimos las instancias mixtas,
que son instancias definidas en DAML+OIL con varios
tipos, y que al momento de traducirse se definen como in-
stancias de una clase compuesta. Esto est detallado en
[2].
Durante la inicializacin, el AO carga varias piezas de
ontologas de una lista de URLs, en la cual se incluye la
ontologa base, entre otras. Los agentes clientes slo car-
gan la ontologa base al inicio.
Cuando un agente cliente necesita hacer una consulta,
tiene dos opciones: ya sea que pregunte a su CCO, o al AO.
Se deja a consideracin, en este prototipo, que el agente
cliente decida a cul ontologa es mejor preguntar. Como
regla general, sera buena idea preguntar al CCO primero,
en orden de reducir el trfico en la red.
Las consultas se codifican como objetos de la clase Ab-
sIRE de JADE, los cuales son construidos por medio de
cdigo Java en el agente cliente. Despus son eventual-
mente enviados al AO usando mensajes en FIPA ACL, y
luego son interpretados y resueltos conforme van llegando.
Luego los mtodos de Jena se hacen cargo de la consulta.
Cuando el CCO es consultado, el preoceso es exactamente
el mismo, excepto que no se enva mensaje ACL para hacer
la pregunta.
La respuesta se obtiene haciendo mltiples llamadas a
las mtodos de Jena y se traduce de nuevo a frames JADE
por medio del CCO. Tanto si se pregunta al AO o al CCO,
se utiliza un mensaje ACL como vehculo para recibir la
respuesta; de esta manera se tiene un mtodo nico de re-
cepcin de respuestas.
4.3 Resolucin de Consultas
Las consultas consisten de un cuantificador (indica si quer-
emos todos los resultados o slo el nmero de incidencias),
una variable (que especifica el tipo de dato buscado), y un
operador de consulta.
Los operadores de consulta estn definidos de forma que
su evaluacin se realiza en dos pasos: primero, se especi-
fican las caractersticas de los objetos, y segundo, se es-
pecifica el elemento buscado. Durante el primer paso, Jena
extrae una lista de esquemas DAML+OIL que satisfacen
la especificacin dada, y en el segundo paso se construyen
los resultados.
Por ejemplo, asumamos que deseamos conocer cules
propiedades estn definidas en la clase Trabajador. Us-
aremos el cuantificador ALL, as que las propiedades mis-
mas, y no slo el nmero de ellas, es devuelto. Ahora
definimos la variable x de tipo CLASS_PROPS, la cual
almacena una lista de propiedades definidas en una clase.
Finalmente, el operador DescWhere es introducido, us-
ando como parmetros un filtro y la estructura de los resul-
tados. En el ejemplo a continuacin, el filtro es un nombre
de clase (Trabajador), y la estructura del resultado usa la
variable x para almacenar la respuesta. La consulta en
nuestro ejemplo podra ser como sigue:
(ALL
:VARIABLE (Variable :VALUETYPE CLASS_{P}ROP
:PROPOSITION (DESCWHERE
:DESC (CLASSDESCRIPTOR :CLASS_{P}ROPS
(Variable :VALUETYPE CLASS_{P}ROPS :NAM
:WHERE (CLASSDESCRIPTOR :CLASS_{N}AME Tra
Usando nuestra ontologa ejemplo, el resultado obtenido
sera el siguiente:
(RESULTS :RESULTS_SET (DESCLIST
#0 (CLASSDESCRIPTOR
:CLASS_{N}AME Worker
:CLASS_{P}ROPS (PROPLIST
#0 (PROPERTYDESCRIPTOR :PROP_NAME id)
#1 (PROPERTYDESCRIPTOR :PROP_NAME puest
#2 (PROPERTYDESCRIPTOR :PROP_NAME email
#3 (PROPERTYDESCRIPTOR :PROP_NAME telef
#4 (PROPERTYDESCRIPTOR :PROP_NAME nombr
Podemos ver que la clase Trabajador agrupa en el resul-
tado la lista de propiedades por las cuales preguntamos.
Incluimos el nombre de la clase de manera que la respuesta
este autocontenida, y pueda ser incorporada en la ontologa
local del agente cliente de manera significativa. Ntese que
la lista de propiedades devuelta en este ejemplo incluye no
slo las propiedades directas de Trabajador, sino tambin
aquellas definidas en sus superclases tambin.
Se deja al programador la tarea de interpretar y usar
los resultados dados por las caractersticas ontolgicas en
nuestro prototipo. El sistema nicamente lleva a cabo au-
tomticamente la unin de las respuestas que llegan con la
ontologa local, como se discute en la siguiente subseccin.
5 EXPERIMENTOS Y RESULTADOS
Diseamos y llevamos a cabo experimentos enfocados a
asegurar que cada posible consulta pueda ser resuelta por
nuestro sistema, y esa traduccin funcione adecuadamente.
Asumimos que el software sobre el cual estamos con-
struyendo (JADE, Jena) trabaja correctamente.
Llevamos a cabo una metodologa de pruebas formal,
ordenando primero todas las posibles consultas en una se-
cuencia lineal, y luego tomando aleatoriamente algunas de
las consultas, hasta que un tamao de muestra es alcan-
zado. Los detalles de nuestro mtodos de prueba se repor-
tan en [2].
Usamos una ontologa de prueba acerca de una universi-
dad (Tecnolgico de Monterrey), representando la estruc-
tura organizacional, as como propiedades de gente que es-
tudia y trabaja ah. Los archivos DAML (itesmcore.daml y
personal.daml, para esquemas e instancias), son accesibles
por internet. Se us la herramienta OilEd [17] para edi-
tar nuestra ontologa de prueba. Algunos ajustes manuales
fueron necesarios para hacerla usable por Jena.
El principal resultado de nuestros experimentos fue que
el 100% de la muestra de 15 consultas fue resuelta correc-
tamente con diferentes parmetros. Un nmero mayor de
pruebas se consider innecesaria, debido al 100% de los
xitos, y al alto nivel de redundancia que se hizo evidente
a medida que se incrementaba la complejidad de las con-
sultas.
Cabe aclarar que los resultados mencionados prueban
unicamente la correccion del prototipo. No demuestran,
por ejemplo, que nuestro enfoque global y local para el
manejo de ontologias sea mas eficiente en terminos com-
putacionales que otros enfoques, Este tipo de experimentos
ocupara nuestro trabajo en el futuro inmediato.
6 TRABAJOS RELACIONADOS
En el proyecto KAON [20] el enfasis es en reusar ontolo-
gias y en propagar los cambios a ontologias distribuidas.
Se lleva un registro de as URI de las ontologias cono-
cidas para el sistema en unos servidores de ongologias,
los cuales toman a su cargo admninistrar la evolucion de
las ontologias (inclusion, actualizacion, cambios, propaga-
cion, etc.). Cada servidor de ontologias provee un servicio
de interrogacion a su comunidad de agentes. En el servi-
dor de ontologias se guarda una copia local de la ontologia
original, tomada inicialmente del URI dado, y actualizado
en curso de funcionamiento, para propositos de interroga-
cion.
Nuestro AO, en cambio, utiliza ontologias DAML+OIL.
En nuestro enfoque, es el COC quien actualiza su ontolo-
gia, no el servidor (esto es, el AO). En el lado negativo,
nosotros no hemos tomado en cuenta aun el aspecto de la
evolucion de las ontologias, principalmente porque esto
acarrea problemas de mantener la coherencia y detectar
cuando se ha perdido esta.
En el proyecto COMMA [18], como en JITIK, se tiene
una ontologia global que es propagada al conjunto de
agentes conocidos. Cada agente recibe una copia completa
de la ontologia, y puede resolver consultas por si mismo.
COMMA usa RDF como el lenguaje de codificacion de
ontologias. Incluye un API especializado en el acceso a
ontologias por los agentes del sistema, y hay un archivista
de ontologias que administra el acceso. Obviamente este
enfoque se ubica en el extremo centralizado del espectro.
En el sistema FRODO [19] se consideran los roles de
proveedor y consumidor de ontologias. En los provee- idad de afinar el compromiso entre acceso central y dis-
dores se concentra la provision de servicios de ontologias,
incluyendo su mantenimiento. Los consumidores simple-
mente usan las ontologias para ejecutar sus aplicaciones.
En FRODO hay dos niveles de distribucion de ontologias:
interno a una comunidad de agentes y externo o intersis-
temas. En JITIK tenemos solamente un nivel de distribu-
cion de ontologias, pues aun no hemos considerado la co-
municacion entre agentes de ontologias de dos grupos de
agentes distintos, cada uno alrededor de un agente de sitio.
En FRODO se definen tres categorias respecto a las capaci-
dades de manejo de ontologias: uso de ontologias, evolu-
cion de ontologias y socializacion de ontologias. En el uso
de ontologias se encuentra la formulacion de consultas y su
solucion. En JITIK consideramos el uso y la socializacion
de las ontologias, pero no la evolucion.
7 DISCUSIN
La arquitectura conceptual ilustrada en la figura 2 usa al-
macenamiento persistente explcito, as como separacin actualizando las ontologas del AO con adiciones a las on-
entre esquemas e instancias. Esto puede ser preferible
sobre esquemas ms homogeneos como Jena en el caso
de un nmero de instancias extremadamente grande, pues
podemos aprovechar consultas eficientes a bases de datos,
en vez de mecanismos de inferencia ontolgicos especial-
izados.
Nuestro prototipo no usa ninguna forma de almace-
namiento persistente, a pesar de que Jena ha ofrecido re-
cientemente soporte para persistencia. As que, incorporar
persistencia es principalmente cuestin de actualizar nues-
tra versin de Jena. A pesar de ello pensamos que la persis-
tencia no es esencial para el CCO en el lado del cliente; el
cliente puede cargar la ontologa base tal como se hace en
el prototipo, y obtener definiciones adicionales del almace-
namiento persistente en el lado del AO como explicamos
anteriormente. Claro que, si la ontologa va a ser enrique-
cida por los agentes clientes, las definiciones de nuevos
conceptos deben ser almacenados permanentemente ya sea
en el almacenamiento permanente local en el CCO, o en-
viado al AO para enriquecer la ontologa comn.
7.1 Conclusiones
Hemos presentado una arquitectura y un prototipo que re-
suelve el problema de manejo de ontologas para el sis-
tema JITIK, y que puede ser aplicado a otros sistemas
multiagente tambin. El principal requerimiento para
aplicar nuestra arquitectura es que debe haber una on-
tologa comn, la cual es en un principio aceptada por
todo el sistema, pero que no es completamente conocida
por cada agente en el sistema. Asi, proponemos una forma
de compartir el conocimiento de la ontologa comn res-
idente en el Agente de Ontologas, pero evitar los cuel-
los de botella que podran resultar de un manejo de on-
tologas centralizado. Por esto, hemos incorporado a todos
los agentes en el sistema un Componente Cliente de la On-
tologa, el cual es capaz de resolver localmente parte de
la consultas ontolgicas. Este sistema hbrido, pensamos,
puede permitir un mejor escalamiento en el tamao del sis-
tema.
Hemos usado estndares abiertos conocidos para rep-
resentar ontologas como DAML+OIL. Adems, combi-
namos esos formatos estndar con un formato especfico
de multiagentes ofrecido por la plataforma JADE.
Se reporta un prototipo, el cual implementa los elemen-
tos bsicos de nuestra arquitectura, haciendo uso exten-
sivo de Jena Toolkit. Se desarroll una librera (xont) que
encapsula toda la funcionalidad adicional requerida para
cargar y consultar ontologas DAML+OIL desde JADE.
Los experimentos llevados a cabo demostraron las capaci-
dades bsicas para consultar e inferir, aunque no demues-
tran cuantitativamente la ventaja de usar un enfoque com-
binado global y local.
Pensamos que un enfoque hbrido introduce la posibil-
tribuido a la ontologa, bsicamente variando el tamao de
la ontologa local. En un extremo, una ontologa vaca en el
CCO es equivalente a una solucin centralizada, mientras
que una ontologa en el CCO idntica a la del AO equivale
a una solucin completamente descentralizada. Cualquier
solucin intermedia es posible en principio.
7.2 Trabajo Futuro
En primer lugar vamos a realizar experimentacion cuanti-
tativa que demuestre fehacientemente las ventajas de nue-
stro enfoque en terminos de eficiencia, con respecto a otros
metodos, en particular con respecto a un metodo total-
mente global o totalmente local.
Pretendemos trabajar en un sistema de cach de
las definiciones usadas ms frecuentemente; el alma-
cenamiento indiscriminado de los resultados de consul-
tas al AO puede hacer crecer el CCO indefinidamente.
Asmismo, definir un mecanismo para mantener la sin-
cronizacin entre las ontologas centrales y distribuidas,
tologas cliente.
REFERENCES
[1] Bellfemine, Fabio; et alt. JADE Administrators
Guide. TILAB S.p.a. 2002. http://sharon.
cselt.it/projects/jade/
[2] Ceballos H. Manejo de Ontologas en Sistemas
Multiagentes por medio de un Agente de Ontologas
aplicado a JITIK master thesis Monterrey Tech
June 2003.
[3] H. S. Nwana & D. T. Ndumu, A Perspective on Soft- [19] van Elst, L., Abecker, A. Domain Ontology Agents
ware Agents Research, In: The Knowledge Engineer- in Distributed Organizational Memories, Knowledge
ing Review, Vol 14, No 2, pp 1-18, 1999. Management and Organizational Memories, Rose
Dieng-Kuntz and Nada Matta (eds.), Kluwer Acad-
[4] M. Wooldridge, Introduction to MultiAgent Systems emic Publishers, Julio 2002.
John Wiley and Sons in March 2002.
[20] Maedche, A., Motik B., Stojanovic L., Studer R.,
[5] R. Brena, J.L. Aguirre, A.C. Trevio, Just-in- Volz R. An Infrastructure for Searching, Reusing and
Time Knowledge Flow for Distributed Or- Evolving Distributed Ontologies, WWW2003 pro-
ganizations using agents technology, Knowl- ceedings, ACM, Budapest, Hungria, Mayo 20-24,
edge Technologies 2001 Conference, Austin, 2003.
Texas, 4-7 March 2001, http://www2.gca.
org/knowledgetechnologies/2001/
proceedings/index.asp.
[6] F. Weichhardt, C. Fillies, R. Smith, The Seman-
tic Web is the Database: Decentralised Modeling
with central Coordination, 2002 http://www.
semtalk.com/pub/spain2.htm.
[7] Jaron Collis, Divine Ndumu. The Zeus Agent Build-
ing Toolkit. The Role Modelling Guide. British
Telecommunications plc. 1999
[8] HP Labs. Jena Semantic Web Toolkit - Data
Sheet http://www.hpl.hp.com/semweb/
jena-datasheet.htm.
[9] Alexaki, Sofia; Athanis, Nikos; Vassilis,
Christophides; Karvounarakis, Greg; Maganaraki,
Aimillia; Plexousakis, Dimitris. The ICS-FORTH
RDFSuite: High level scalable Tools for the Seman-
tic Web. Poster Session of the Eleventh International
World Wide Web Conference (WWW02). Honolulu,
Hawaii, USA, May 8, 2002.
[10] Caire, Giovanni.JADE Tutorial. Application-
Defined Content Languages and Ontolo-
gies. TILab S.p.a. Grecia. 2002. http:
//sharon.cselt.it/projects/jade/
[11] Kifer, Michael; Lausen, Georg. F-logic: a higher-
order language for reasoning about objects, inheri-
tance, and scheme. SIGMOD RECORD, Vol: 18, No:
6, June 1990, pp. 134-146 . citeseer.nj.nec.
com/kifer90flogic.html
[12] Conolly, Dan; et alt. DAML+OIL (March 2001)
Reference Description. W3C Note 18 Dec
2001. http://www.w3.org/TR/2001/
NOTE-daml+oil-reference-20011218
[13] Lassila, Ora; R. Swick, Ralph. Resource De-
scription Framework (RDF) Model and Syntax
Definition Specification. W3C Recommendation,
Feb 1999. http://www.w3.org/TR/1999/
REC-rdf-syntax-19990222
[14] Mike Dean, Guus Schreiber, et. alt.OWL Web Ontol-
ogy Language Reference. W3C Working Draft, 31
March 2003. http://www.w3.org/TR/2003/
WD-owl-ref-20030331/
[15] G. Karvounarakis S. Alexaki V. Christophides D.
Plexousakis M. Scholl RQL: A Declarative Query
Language for RDF In The 11th Intl. World Wide
Web Conference (WWW2002) citeseer.nj.
nec.com/556066.html.
[16] Lenat, D., Context dependence of representations
in CYC. Colloque ICO93, Montreal, Canada, May
1993.
[17] Bechhofer, S. Horrocks, I. Goble, C. Stevens, R.,
OilEd: A Reason-able Ontology Editor for the Se-
mantic Web, 24th German / 9th Austrian Conference
on Artificial Intelligence, 2001.
[18] Gandon, F., Agents handling annotation distribution
in a corporate semantic web, Web Intelligence and
Agent Systems. Volume 1, Number 1. 2003. OIS
Press.