Los agentes proceden de los campos de la inteligencia artificial (IA) y de la ingeniería del software (en particular, de la orientación a objetos). Desde un punto de vista conceptual los agentes proceden del modelo de actores concurrentes que propusieron Carl Hewitt, Peter Bishop y Richard Steiger en 1973. Los actores, directos predecesores de los agentes, fueron definidos por Hewitt en 1977 como "objetos autocontenidos, interactivos y que se ejecutan concurrentemente, que poseen estado interno y capacidad de comunicarse" y como "agentes computacionales que tienen una dirección de correo y un comportamiento". Los actores se comunican mediante un intercambio de mensajes y llevan a cabo sus acciones concurrentemente (es decir, sus acciones pueden ejecutarse en paralelo, sin secuencias fijadas de antemano). La principal diferencia entre los actores y los agentes es que estos últimos suelen tener restricciones relacionadas con metas o propósitos.

Las relaciones y las diferencias entre los objetos y los agentes se detallan en http://www.wshoy.sidar.org/index.php?2007/05/08/38-los-trabajadores-de-la-web-semantica-agentes-agentes-inteligentes-y-agentes-semanticos. La ingeniería de software tiende a adoptar enfoques un tanto totalitarios: todo es un actor, todo es un objeto…

Hay una fuerte relación entre los agentes y la IA: provienen del campo de la inteligencia artificial distribuida (IAD), que estudia métodos y técnicas para la resolución de problemas mediante la cooperación de diversas entidades distribuidas, autónomas e inteligentes. En la IAD se entremezclan dos disciplinas: la IA y los sistemas distribuidos. Un sistema distribuido es, según George Coulouris, "un sistema en el que los componentes de hardware y/o software localizados en computadores en red se comunican y coordinan sus acciones intercambiando mensajes". Aunque usted no supiera qué es un sistema distribuido, seguro que ha usado alguno. Si no fuera así, no estaría leyendo esto, pues Internet y la World Wide Web son sistemas distribuidos.

En la IAD, la colaboración de unas entidades con otras produce comportamientos colectivos que resuelven problemas que serían irresolubles si se abordaran individualmente o que proporcionan soluciones eficaces en cuanto a tiempo, velocidad o calidad. Un ejemplo de inteligencia "natural" distribuida nos la proporciona una colonia de termitas: la colaboración entre ninfas, obreras, soldados y la reina permite la supervivencia de la colonia. Las termitas por separado no podrían sobrevivir (los soldados no pueden alimentarse por sí solos, la reina apenas puede moverse y las obreras no pueden defenderse); pero su cooperación les ha permitido existir desde hace millones de años en este planeta. Quién sabe, quizás sobrevivan al Homo sapiens sapiens: en el gran libro de la evolución quedan muchas páginas por escribir.

La IAD consta de tres grandes ramas de investigación: los sistemas multiagente (que estudian sistemas en que un conjunto de agentes cooperan, coordinan y se comunican para conseguir un objetivo común), la solución distribuida de problemas (que estudia la solución de problemas mediante procesamientos descentralizados) y la inteligencia artificial en paralelo (que desarrolla métodos y algoritmos paralelos de IA). Dentro de la IAD, los agentes provienen de los sistemas multiagente, que son grupos de agentes autónomos, generalmente heterogéneos e independientes, que colaboran entre sí para conseguir ciertos objetivos; esta colaboración implica que cooperen, se coordinen y negocien unos con otros. En un sistema multiagente no hay un control global del sistema ni existe un lugar donde esté toda la información.

Tal y como se menciona en http://www.wshoy.sidar.org/index.php?2007/05/08/38-los-trabajadores-de-la-web-semantica-agentes-agentes-inteligentes-y-agentes-semanticos, no es imprescindible que los agentes del sistema distribuido sean inteligentes (esto es, que tengan algún tipo de inteligencia artificial); la propia "inteligencia" puede obtenerse de la cooperación entre agentes "tontos". Este tipo de inteligencia se denomina inteligencia social, y es la empleada en los partidos de fútbol entre robots. En estos partidos, cada robot persigue dos metas bien simples: marcar gol y esquivar a los jugadores del equipo contrario. La combinación de los comportamientos individuales para lograr dichos objetivos hace emerger un comportamiento social semejante al de cualquier equipo de fútbol humano, salvo en la celebración de los goles. Las colonias de termitas, mencionadas antes, son ejemplos biológicos de inteligencia social –al igual que las colonias de hormigas o de abejas–. En las colonias, cada individuo tiene unas metas individuales, programadas genéticamente, más complejas que las de los robots futbolistas.

Los sistemas multiagente se enfrentan a varias preguntas: ¿qué lenguajes deben usar los agentes para comunicarse?, ¿cómo deben coordinarse los agentes para que consigan los objetivos del sistema?, ¿cómo pueden los agentes resolver los conflictos (de intereses, p. ej.) que pueden surgir mientras colaboran?, ¿qué relaciones sociales surgen en una comunidad de agentes?

Gran parte de las propiedades y ventajas de los sistemas multiagente proceden de los sistemas de IA distribuida. Veamos algunas de ellas:

• Modularidad. Según el Dictionary of Object Technologies: The Definitive Desk Referente, la modularidad es "la descomposición lógica de las cosas (por ejemplo, responsabilidades y software) en agrupaciones simples, pequeñas (p. ej., requisitos y clases, respectivamente), que aumentan las posibilidades de lograr las metas de la ingeniería de software". La programación modular simplifica el desarrollo de sistemas de software y reduce su coste. (Si quiere saber por qué la modularidad ganó la II Guerra Mundial puede consultar http://www.javahispano.org/tutorials.item.action?id=25 o http://www.javahispano.org/contenidos/es/orientacion_a_objetos_11/.)
• Bajo acoplamiento. Suele utilizarse el término acoplamiento para designar la dependencia entre módulos o componentes de un sistema. En un sistema de software de bajo acoplamiento, cada componente depende lo mínimo posible de los otros. En estos sistemas, los componentes pueden comunicarse a pesar de tener diseños e implementaciones muy distintas. Por el contrario, en un sistema de acoplamiento fuerte, los componentes están diseñados para trabajar estrechamente con otros y dependen fuertemente unos de otros. Por ejemplo, el controlador de una impresora tiene un acoplamiento muy fuerte con la plataforma en que se ejecuta: pasar de un PC a un Mac requeriría programar de nuevo el controlador. El bajo acoplamiento de los sistemas multiagente se traduce en flexibilidad (si hay que modificar algún agente, los cambios apenas repercutirán en el resto de los agentes) e interoperabilidad (los agentes pueden trabajar juntos aunque hayan sido diseñados y programados independientemente).
• Fiabilidad. Que un agente del sistema deje de funcionar no implica que los demás lo hagan.
• Eficacia. Las funciones del sistema se pueden dividir en tareas repartidas entre los agentes, con lo cual se consigue paralelismo (los agentes trabajan a la vez en distintas máquinas).
• Flexibilidad. Se pueden añadir y eliminar agentes dinámicamente, y éstos pueden tener diseños e implementaciones muy distintas.
• Independencia de la plataforma. Los agentes pueden funcionar en distintas plataformas. Esta independencia está relacionada con el bajo acoplamiento de los sistemas multiagente.
• Velocidad. Como los agentes que cooperan entre sí se ejecutan concurrentemente, aumenta la velocidad de ejecución del sistema en conjunto.
• Redundancia. La utilización de agentes redundantes (es decir, que desempeñan una misma tarea) mejora la tolerancia a fallos del sistema.
• Escalabilidad. El sistema mantiene su eficacia cuando aumenta significativamente el número de usuarios del sistema.

Si bien los agentes proceden del campo de la IA y forman un subcampo relevante de ella, cada vez más en continua expansión, la IA no termina en los agentes. Los agentes no resuelven todos los problemas a los que se enfrenta la IA. A saber: comprensión automática de textos en lenguaje natural, traducción de textos, reconocimiento y síntesis automáticas del habla, construcción de sistemas capaces de pensar de manera original o creativa, introducción del sentido común en máquinas, fabricación de sistemas de reconocimiento de rostros o de formas… Dirá el escéptico: "¿No debería la IA resolver todos esos problemas antes de anunciar lo listos que son los agentes?". Pobre escéptico, porque con esa exigencia jamás habría visto un agente en su vida (ni en varias vidas, si cree en la reencarnación). Dudo mucho que algún lector llegue a ver una máquina que hable así espontáneamente: "Sé que últimamente he tomado muy malas decisiones, pero puedo asegurarle que mi trabajo se normalizará. Todavía tengo gran entusiasmo y confianza en la misión, y quiero ayudarle". Hasta el momento, los agentes inteligentes trabajan en dominios muy limitados (la Web, bases de datos, colecciones de documentos, correo electrónico) y realizan tareas muy sencillas. Así, necesitan muy poca inteligencia y no tienen que enfrentarse a muchos de los problemas de la IA aún sin solución.

¿Adónde van los agentes? Por ahora, a todas partes: cada vez hay más aplicaciones comerciales y académicas basadas en ellos. Si al final son sustituidos por otra tecnología (basada en "siervos", por ejemplo), puede estar seguro de que oiremos frases como éstas: "Todo es un siervo", "La tecnología de siervos aumentará la productividad de las empresas", "Los siervos abren la puerta a una nueva era de tecnología", "Con los siervos, los usuarios no perderán el tiempo en tareas repetitivas"…

En general, se acepta que un agente es cualquier sistema capaz de percibir cambios en su entorno, de representar de algún modo la información sobre el estado actual de sus objetivos y de actuar sobre su entorno basándose en éstos y en experiencias pasadas. Cuando se consideran entornos virtuales (la Web, intranets, etc.), se habla de agentes de software; en entornos físicos, los agentes pueden ser animales, personas, robots o autómatas. Por ejemplo, el vehículo Mars Pathfinder –que recorrió la aherrumbrada superficie de Marte durante varios meses de 1997– era un agente en un entorno físico bastante agresivo para la vida humana.

En lo que sigue consideraré únicamente agentes de software, no robots ni autómatas. Según Michael Wooldridge, un agente es un sistema de software capaz de actuar autónoma y flexiblemente en un entorno cambiante. Para Gerhard Weiss, un agente es una entidad computacional que percibe y actúa autónomamente en su entorno. Ambas definiciones coinciden en que los agentes gozan de cierta libertad de actuación en su entorno; es decir, no se limitan a efectuar ciertas tareas siempre de la misma forma, sino que tienen sus propias “ideas” sobre cómo alcanzar sus objetivos. Perdóneme el lector o la lectora por personificar a los agentes: les entristece mucho que los traten como programas o subrutinas.

Según Jeffrey Bradshaw, las principales características de los agentes son éstas (no todas son obligatorias y algunas pueden darse en mayor o menor grado):

• Persistencia: El código de un agente se ejecuta continuamente, no cuando el usuario lo decide, y decide por sí mismo cuando deje ejecutar alguna acción. Los agentes siempre permanecen activos: se ejecutan en un bucle infinito y observan su entorno, actualizan su estado y determinan qué acciones realizar. Se comportan como buitres (siempre mirando, siempre esperando a que llegue el turno de actuar), pero sin sus siniestras intenciones.
• Autonomía: Un agente puede tomar decisiones sin la intervención humana o de otros agentes. Es decir, para cumplir sus objetivos, un agente controla sus propias acciones.
• Reactividad: Un agente es capaz de percibir su entorno y mantener un vínculo constante con él, de modo que puede responder adecuadamente a los cambios. Los agentes más reactivos tienen en cuenta la posibilidad de que se produzcan fallos o de que las cosas no vayan como se esperaba.
• Proactividad: Un agente no actúa dirigido solamente por los sucesos que se producen en su entorno, sino que también toma iniciativas para lograr sus objetivos. Es decir, los agentes reconocen y utilizan las oportunidades que se les presentan. Las iniciativas pueden proceder de experiencias pasadas, pues los agentes aprenden del pasado.
• Habilidad social: Un agente constituye una entidad social integrada en una sociedad, en la cual hay tareas, recursos y papeles que se distribuyen entre los agentes. Algunos objetivos sólo se pueden conseguir mediante la colaboración con otros agentes o con humanos.

Como los agentes son programas, ¿debemos concluir que los programas son también agentes? Para contestar a la pregunta, consideremos un programa conversor de euros a francos suizos. El programa funciona así: cada vez que un usuario ejecuta el programa, éste se conecta por Internet a los mercados de divisas, extrae el tipo de cambio –que fluctúa constantemente– y lo presenta por pantalla. El programa es, en cierto sentido, consciente de su entorno porque devuelve una salida (un tipo de cambio) tras recibir una entrada (la ejecución del programa) y porque se conecta a los mercados de divisas. Sin embargo, no es un agente: su salida actual no afecta a sus futuras salidas; dicho de otro modo, no tiene “memoria” de sus actos ni puede aprender de ellos. Además, el programa carece de persistencia: sólo permanece activo un tiempo muy breve; una vez que devuelve el tipo de cambio, se vuelve inactivo. Vemos, en definitiva, que no todos los programas son agentes.

Muchas personas piensan que los agentes no son más que objetos con algunas funciones añadidas; según ellos "un agente es un objeto que… [aquí añaden sus características favoritas]". Otros van más lejos: afirman que la única diferencia entre ellos radica en que "agente" es una palabra de moda, como en su día lo fue "objeto". (Si desea saber más sobre objetos, clases y la programación orientada a objetos, puede consultar http://www.javahispano.org/tutorials.item.action?id=25 y http://www.javahispano.org/tutorials.item.action?id=33). Existen ciertas semejanzas entre objetos y agentes: en primer lugar, se caracterizan por su estado y por su comportamiento; en segundo, se comunican entre sí mediante mensajes.

Con todo, también hay diferencias entre unos y otros. Primera: los objetos no tienen ningún control sobre sus acciones, que están determinadas desde su creación; por el contrario, los agentes las controlan para cumplir sus objetivos. Éstos pueden tener un comportamiento impredecible. Por ejemplo, si se pide a un agente que compre algún CD barato en alguna tienda, cualquier resultado es posible: el agente podría volver con Power, Corruption and Lies de New Order o con un CD de cantos hindúes del siglo V antes de Cristo, o sin nada. A diferencia de los objetos, los agentes pueden decir "no" (es más, algunos gozan con eso).

Segunda diferencia: los agentes gozan de más autonomía y flexibilidad que los objetos, tan esclavos ellos. Como las clases definen los métodos y atributos como públicos o privados, los objetos (instancias de las clases) no pueden cambiar la visibilidad de métodos y atributos. Si el método dispararFlecha de un objeto arcoOlímpico es público, el objeto no puede impedir que otros objetos lo usen. Un agente, en cambio, sí podría impedir que otros agentes usaran su dispararFlecha (volviéndolo privado, p. ej.), siempre que eso favoreciera sus objetivos.

Tercera diferencia: tal como se mencionó antes, los agentes siempre están activos (vigilan su entorno, actualizan su estado y determinan qué acciones son apropiadas); los objetos vienen a ser muertos a tiempo casi completo, porque sólo “viven” (están activos) cuando sus métodos son llamados por otros objetos.

Cuarta y última diferencia: los objetos jamás se equivocan (en todo caso, se equivocan quienes los programan), mientras que los agentes puede tomar decisiones equivocadas e incluso aprender de sus errores pasados. Si un objeto tiene un método calcularIVA que aplica un porcentaje equivocado (14% en lugar de 16%, verbigracia), el objeto nunca aprenderá nada de ese error, pues ya nació –mejor dicho, se instanció– con él.

Suele usarse el término agente inteligente para referirse a agentes dotados de cierta inteligencia artificial y que, por tanto, gozan de un alto grado de autonomía, reactividad, proactividad y habilidad social. El concepto de inteligencia resulta sumamente escurridizo: algunos investigadores piensan que las máquinas nunca alcanzarán una inteligencia como la humana. En apoyo de esta opinión acude este hecho: el sentido común resulta más difícil de reproducir que cualquier habilidad técnica. Otros investigadores piensan en la inteligencia como un fenómeno emergente (los fenómenos emergentes son propiedades de un sistema complejo que no pueden reducirse a las propiedades de sus partes constituyentes). En consecuencia, piensan que la inteligencia podría alcanzarse, en principio, a partir de partes constituyentes no biológicas. Para no entrar en discusiones que llevan ocupando a los filósofos desde hace siglos, empleo el término inteligencia para denotar la capacidad de adaptarse al medio y de aprender (es decir, descubrir información). Hasta el más escéptico en cuanto a las posibilidades de la inteligencia artificial coincidirá conmigo en que existen ya programas que permiten descubrir información mediante asociaciones y búsqueda de patrones.

Según Barbara Hayes-Roth, los agentes inteligentes realizan continuamente tres funciones: perciben las condiciones cambiantes del entorno; actúan para modificar las condiciones del entorno; y razonan para interpretar percepciones, resolver problemas, extraer inferencias y determinar acciones.

Algunas personas usan agente inteligente como sinónimo de agente, cuando en realidad un agente no tiene por qué tener "inteligencia" (piénsese en un cliente de correo, p. ej.). Otras reservan agente inteligente para los agentes que contienen planificaciones, calendarios, reglas, etc. Se suele emplear el término bot (abreviatura de robot) para los agentes que, siguiendo reglas estrictas e invariables, realizan tareas repetitivas: buscar productos, rellenar cuestionarios, mostrar noticias sobre un determinado asunto… Los bots usados por los buscadores de información –Google, Yahoo, MSN Search– para construir sus bases de datos se denominan arañas.

Los agentes inteligentes suelen relacionarse con los sistemas expertos. Un sistema experto es un programa que intenta imitar el comportamiento de un experto en un dominio concreto. Por ejemplo, un sistema experto en medicina podría, a partir de los síntomas del enfermo, emitir diagnósticos. Los agentes difieren de los sistemas expertos en dos aspectos esenciales: primero, éstos no interaccionan con el entorno; segundo, los agentes suelen desarrollarse con la intención de colaborar con otros agentes, mientras que los sistemas expertos no colaboran ni intercambian información entre ellos.

Dar una clasificación completa de los agentes es tarea harto compleja; pues cada autor suele proponer su propia clasificación, a menudo tan discutible como cualquier otra. Los agentes pueden clasificarse según su movilidad (estáticos, dinámicos), según si son deliberativos (contienen modelos simbólicos de su entorno y reglas de razonamiento) o reactivos (no poseen modelos simbólicos de su entorno y, por tanto, actúan siguiendo el esquema estímulo-respuesta), según las tareas que desempeñan, las características que predominan, etc. Hyacinth S. Nwana clasifica así los agentes: agentes colaboradores, agentes de interfaz, agentes móviles, agentes de información, agentes reactivos, agentes híbridos y sistemas heterogéneos de agentes.

Si consideramos como criterio de clasificación las tareas que desempeñan los agentes, existen muchos tipos de agentes. Los más conocidos están vinculados al comercio electrónico: los agentes de compra comparativa se encargan de localizar mercancías al mejor precio posible; los de subasta permiten a los usuarios pujar por una mercancía o bien; los de negociación automatizan los procesos de negociación habituales en las transacciones comerciales. En general, en casi cualquier dominio pueden usarse agentes. Por ejemplo, el proyecto Guardian (http://ksl-web.stanford.edu/projects/guardian/) desarrolló un agente inteligente para monitorizar a los pacientes de las unidades de cuidados intensivos. Este agente permite, entre otras cosas, controlar constantemente el estado de los pacientes, definir los tratamientos y cuidados necesarios a corto y largo plazo, así como diagnosticar posibles enfermedades y complicaciones. Debido a lo delicado de su tarea, el agente reacciona rápidamente a cualquier modificación del estado del paciente.

Los sistemas multiagente son sistemas distribuidos de software formados por un conjunto de agentes autónomos (nodos) que trabajan juntos para resolver problemas. Asignándose tareas unos a otros y colaborando, los agentes pueden solucionar problemas que serían irresolubles para un agente aislado. En un sistema multiagente no hay un control global del sistema ni un lugar donde esté toda la información. La "inteligencia" de un sistema multiagente puede obtenerse de dos maneras. En primer lugar, mediante el uso de agentes inteligentes para el sistema. En segundo lugar, usando agentes reactivos (como expliqué antes, son aquellos que reaccionan siguiendo el esquema conductista: estímulo-respuesta). En este caso, la inteligencia colectiva del sistema es un fenómeno emergente.

Las enormes posibilidades de los sistemas multiagente se vislumbran en Robocup Rescue (puede encontrarlo en http://www.rescuesystem.org/robocuprescue/), un sistema multiagente que simula la respuesta de los equipos de rescate a cualquier desastre natural (un terremoto, por ejemplo). La simulación consiste en la reconstrucción fotográfica de un desastre y, luego, en manejar un conjunto de agentes inteligentes (que hacen el papel de víctimas, policías, bomberos, etc.) en ese entorno. El objetivo de Robocup Rescue consiste, por un lado, en reducir al mínimo los daños en el mundo virtual que sufre el desastre; y, por otro, en sacar de la simulación conclusiones que puedan aplicarse en el mundo real a la coordinación de equipos de rescate. La complejidad de Robocup Rescue es ingente, por cuanto maneja situaciones como rescatar personas atrapadas en edificios en ruinas, en llamas o inundados. RoboCup Rescue es también una competición: los participantes construyen sus propios agentes y compiten por reducir al mínimo los efectos de los desastres naturales.

Existen muchas plataformas para crear agentes e interconectarlos: IBM Aglets, ZEUS, JADE (Java Agent Development Framework), ABLE, MadKit, JATLite (Java Agent Template Lite), Grasshopper, AgentBuilder, FIPA-OS, Concordia, Gossip, FarGo, Voyager. Si usted no tiene experiencia en agentes y desea probar alguna plataforma, le recomiendo empezar con AgentBuilder (http://www.agentbuilder.com/Documentation/product.html). Es un conjunto integrado de herramientas que permite desarrollar agentes inteligentes y aplicaciones basadas en ellos, sin necesidad de programar (la versión PRO permite desarrollar también aplicaciones multiagente). Recomiendo esta solución comercial porque me parece una de las más sencillas y rápidas para quien carezca de experiencia en el desarrollo de agentes. JADE y ABLE son más potentes que AgentBuilder, pero también son más complejas de usar.

ZEUS (http://labs.bt.com/projects/agents/zeus/) es una herramienta para desarrollar sistemas multiagente. Es una herramienta educativa y no necesita conocimientos de programación. Tanto las ontologías como los agentes se crean mediante asistentes visuales, como sucede con AgentBuilder. Al final del proceso de creación de los agentes, ZEUS genera código fuente escrito en Java. Como Java es un lenguaje multiplataforma (véase, por ejemplo, http://www.javahispano.org/articles.article.action?id=55), el código compilado puede ejecutarse en las plataformas más habituales (una plataforma es una combinación de hardware y software que permite ejecutar aplicaciones; por ejemplo, Microsoft Windows/Intel x86 es la plataforma más común). En consecuencia, con ZEUS pueden construirse sistemas multiagente donde un agente "viva" (perdón, resida) en un PC con Linux, otro en un Macinstosh con Mac OS X, un tercero en una estación de trabajo UNIX…

Los agentes semánticos son agentes que usan tecnologías de la Web semántica (RDF/RDFS, OWL, ontologías) para cumplir sus objetivos. Puede obtener una descripción de tales tecnologías en http://www.javahispano.org/tutorials.item.action?id=55. Debido a que todavía no existe una Web semántica, no hay agentes semánticos que puedan aprovechar sus posibilidades. Existen, sin embargo, agentes semánticos que operan sobre dominios muy específicos (intranets de empresas, por ejemplo); y también hay algunos agentes semánticos que actúan como buscadores de información o como asistentes personales. Por ejemplo, el navegador Amblit Navigator (http://www.amblit.com/products/AmblitNavigator.html) incluye un asistente (Intelligent Personal Agent) al que se le puede enseñar qué desea el usuario y cuándo lo desea.

Este agente admite preguntas como las siguientes: ¿Cuál es la cotización de Endesa? ¿Qué tiempo hará en París la próxima semana? ¿Cuál es el número de teléfono de María Senso Huertas? También se le pueden dar órdenes del tipo "Búscame un mapa de Hannover" o "Averigua dónde puedo encontrar la película Les 400 coups". Para entender miles de sentencias en lenguaje natural, el agente semántico de Amblit se apoya en una ontología y en un software de comprensión del lenguaje natural. Este software "traduce" las preguntas u ordenes en texto libre a conceptos de la ontología (puede encontrar más información sobre ontologías en http://www.wshoy.sidar.org/index.php?2005/12/09/30-ontologias-que-son-y-para-que-sirven).

Para mostrar las posibilidades de los agentes semánticos, considero el siguiente ejemplo: Heliodoro Gómez ha puesto en marcha una tienda de lámparas en su barrio. Se acerca la hora de hacer el primer pago fraccionado del IRPF y no sabé qué impreso usar ni cómo calcular el rendimiento neto empresarial. Preocupado por hacer mal las cosas y recibir luego una simpática carta de Hacienda, Heliodoro ha decidido usar un agente semántico para encontrar un asesor contable y fiscal. Para ello, se conecta a la Web semántica y elige un agente personal que parece fiable.

Escribe en un cuadro de texto "Busco asesor contable y fiscal (cerca de la calle Arboleda, en Soria). Quiero que sea barato y bueno", y el agente se pone en marcha. Primero obtiene una lista de todos los asesores que están a menos de dos kilómetros de la calle Arboleda; luego, para comprobar la calidad de cada uno, investiga si tienen reclamaciones de clientes, quejas ante los colegios profesionales o denuncias. A continuación, busca los que tienen tarifas bajas. Finalmente, selecciona a dos asesores y se los propone a Heliodoro.

A éste no le gusta ninguno de los dos. Uno no es todo lo barato que Heliodoro desearía, y el otro no puede atenderle hasta dentro de dos semanas (está de viaje de novios). Decepcionado con los resultados, Heliodoro escribe a su agente semántico: "Mira otras opciones". El agente repite el trabajo que había hecho, pero no encuentra más asesores que cumplan las condiciones del usuario. Entonces prepara una lista de los asesores cercanos a la calle Arboleda y de buena reputación, independientemente de que sean caros o baratos; acto seguido, contacta con los agentes semánticos de esos asesores para intentar negociar una reducción de las tarifas que aplican. Sólo uno acepta la reducción. Tras una rápida negociación entre agentes, la reducción se fija en un 20% (con la condición de que el cliente pagará cada trimestre de asesoría por anticipado y al contado).

El agente muestra a Heliodoro los datos del asesor elegido y la tarifa que ha quedado establecida. Heliodoro desconfía de la tarifa, porque le parece demasiado barata, y le pregunta a su agente: ¿Cómo has negociado la tarifa? ¿Cómo sabes que ese asesor es bueno? El agente, dotado de paciencia infinita, le proporciona pruebas de todo (para saber más sobre estas pruebas, puede consultar http://www.wshoy.sidar.org/index.php?2007/01/30/37-la-web-semantica-metadatos-ontologias-logica-y-confianza). Contento por ahorrarse un dinerillo, Heliodoro cierra su agente personal y se levanta del ordenador. Mientras se prepara un café, piensa en la Web semántica: "Es buena idea esto de la nueva Web. ¡Y pensar que hace diez años parecía ciencia-ficción! Hasta me están cayendo simpáticos los bichos esos, los agentes".

Para entender mejor las limitaciones de los metadatos, debemos antes comprender bien qué son. Etimológicamente, "metadato" significa "dato sobre datos". Los metadatos se encuentran a la vista de todo el mundo: los códigos de barras –que describen datos sobre el producto: precio, código...– son metadatos. El catálogo de una editorial es un metadato porque describe sus libros y revistas. En una revista científica, por ejemplo, las palabras del resumen de cualquier artículo son metadatos. El esquema de una base de datos es otro ejemplo de metadatos. Decir que el campo "Autor" de una base de datos es un dato de tipo String equivale a describir los datos que son válidos para ese campo (una fecha de tipo Date, vaya por caso, no sería válida en ese campo).

En general, los metadatos describen el contenido, la calidad, la condición o el origen de los datos, aunque pueden describir cualquier característica de éstos. En otras palabras, enriquecen semánticamente los datos, pues hacen más fácil su interpretación, así como la del contexto en que pertenecen.

Una de las funciones más conocidas de los metadatos es su uso para mejorar la búsqueda de información, aunque esta función aún no se emplea en todo su potencial. Hoy no existe ningún buscador comercial que "entienda" que Miguel de Cervantes fue un "escritor español". Por lo tanto, un buscador en que se busque información mediante las palabras clave "escritor español", no devolverá ningún resultado que contenga "Miguel de Cervantes" o que tenga un enlace a una página relacionada con este escritor.

Consideremos otro ejemplo: si introduce en Google el texto "Quiero averiguar qué tiendas del mueble fabrican sillones en Soria o alrededores" (sin comillas), comprobará que la búsqueda genera unas respuestas inútiles, que no tienen nada que ver con la intención del usuario. Los metadatos pueden usarse para proporcionar búsquedas más precisas. Si los documentos y disposiciones de las administraciones públicas, vaya por caso, se anotaran semánticamente con metadatos, sería posible acceder a la página de su ayuntamiento, activar el servicio de consultas y escribir en un área de texto preguntas como “Me voy a cambiar de domicilio, ¿qué tramites debo seguir?”. A continuación, el servicio de consultas mostraría la respuesta (acuda al ayuntamiento para cambiar el empadronamiento, renueve el DNI con la dirección nueva, etc.) e incluso podría mostrar una lista de preguntas similares de otros usuarios, con sus correspondientes respuestas. (Si es usted aficionado o aficionada a mundos virtuales como Second Life, imagínese a un sensual avatar respondiendo a la consulta y moviéndose seductoramente por la pantalla: tratar con la administración podría ser hasta divertido.) Actualmente, toda la información sobre esos tramites está en la Web, pero se halla desperdigada entre muchas páginas web, documentos en Word, en PDF, etc. Se necesita una persona para que vaya consultando esas páginas y documentos y para que vaya recopilando la información de interés. Anotando con metadatos los textos, un buscador podría recopilar por nosotros la información buscada.

El ejemplo propuesto resulta muy simple, pero hay infinidad de búsquedas más complejas en que los metadatos serían muy útiles para buscar información. Imagine, por ejemplo, consultas como éstas: ¿Qué pasos debe seguir una empresa para solicitar deducciones por I+D? ¿Qué requisitos se necesitan para opositar a profesor de secundaria en Pontevedra? ¿Dónde hay monumentos visigodos en Castilla y León? ¿Qué rutas turísticas puedo seguir en Asturias? ¿En qué proyectos europeos participa la empresa AIDIMA?

Desarrollaré sólo un caso: imagine una empresa multinacional de consultoría –con oficinas en más de 50 países y con más de 13.000 empleados– que desea recibir respuestas a preguntas como "¿Qué empleados tienen experiencia en modelado empresarial?", "¿Qué empleados podemos usar para el contrato con la empresa LogicHouse, que necesita implantar un sistema distribuido basado en J2EE, RMI y CORBA?". Como es de esperar, buscar esa información entre los currículos de miles de empleados precisaría semanas o meses, y consumiría el tiempo de muchas personas. Anotando con metadatos cada currículo, un buscador semántico podría contestar a esas preguntas muy rápidamente.

La Web semántica tendrá su base en los metadatos. Las ontologías actuarán como metadatos, y los recursos de la red se marcarán con instancias de las ontologías. (Para saber más sobre ontologías, véase http://www.wshoy.sidar.org/index.php?2005/12/09/30-ontologias-que-son-y-para-que-sirven y http://www.javahispano.org/tutorials.item.action?id=55 ). En la siguiente figura se muestra, como ejemplo, una ontología sobre música. Louis Armstrong es una instancia de la clase Intérprete.

Mediante el uso de ontologías como forma de añadir metadatos a los recursos de la Web actual, la Web semántica se parecerá, muy simplificadamente, a la figura a continuación.

Para ver cómo se "marcan" con metadatos los recursos de la web (es decir, cómo se anotan semánticamente), consideremos un documento tan simple que sólo contiene una frase: "Luis tiene un perro llamado Fido". Usando las tecnologías de la Web semántica, es posible construir una ontología con las clases Persona, Perro, Mamífero, Rabia y Enfermedad, y las relaciones entre ellas (por ejemplo, un Perro es un Mamífero). Para construir una ontología se puede usar cualquier editor de ontologías, como Protégé (http://protege.stanford.edu) o OilEd (http://oiled.man.ac.uk/download.shtml). Para hacer anotaciones semánticas a partir de ontologías pueden emplearse herramientas como Annotea (http://www.w3.org/2001/Annotea/) u OntoMat Annotizer (http://annotation.semanticweb.org/ontomat/index.html).

Las palabras del documento "Luis" y "Fido" pueden asociarse a las clases de la ontología. Si utilizamos el lenguaje de la orientación a objetos (http://www.javahispano.org/tutorials.item.action?id=25), diríamos –por ejemplo–, que Fido es una instancia de Perro. Esta asociación es un tipo de metadatos, pues proporcionan información adicional sobre la información del documento. Incluso se podría vincular a cada clase de la ontología una página web donde estuviera su definición. Así, la página asociada a Rabia diría algo así: "La rabia (hidrofobia) (Código CIE-9-MC: 071) es una enfermedad viral infecciosa que afecta al sistema nervioso de los seres humanos y otros mamíferos. Las personas contraen la enfermedad por la mordedura de un animal rabioso. Cualquier animal silvestre como un mapache, zorrillo, zorro, coyote o murciélago puede tener rabia y transmitirla a los seres humanos."

Aunque los metadatos anteriores pueden aclarar el sentido en que se usan los conceptos a las personas que lean el documento (en este caso, "rabia" se usa en el sentido médico, y no como "emoción primaria intensa y paroxística)", la utilidad de éstos resulta muy limitada. La potencia de la Web semántica no estriba en la mera presencia de metadatos, sino en la combinación de metadatos con la lógica y la confianza en la información.

La lógica, disciplina que estudia los principios del razonamiento, es más general que los metadatos o las ontologías y permite descubrir conocimientos y relaciones ocultos entre marañas de datos. Un motor de inferencias o razonador (programa que genera deducciones siguiendo reglas lógicas) que procese los metadatos del documento anterior deducirá automáticamente que Fido puede contraer la rabia, pues Fido es una instancia de la clase Perro, y ésta es una subclase de Mamífero. Por lo tanto, lo más adecuado sería vacunarlo cuanto antes.

Consideremos la siguientes sentencias en OWL (un lenguaje lógico de ontologías).

Un razonador deducirá de lo anterior que, como un taxista es una persona que conduce un taxi y un taxi es un vehículo, un taxista, por conducir un vehículo, debe ser un conductor.

Veamos otro de sentencias escritas en OWL, que ahora contienen instancias (individuals), no sólo clases:

Teniendo en cuenta que es_mascota_de está definida como propiedad inversa de tiene_mascota y las restricciones de dominios y rangos para tiene_mascota, un razonador podrá deducir que –como Blanquita es la mascota de Miguel y éste es una persona y sólo las personas pueden tener mascotas– Blanquita debe ser un animal, y obrar en consecuencia (no permitiendo, por ejemplo, que a Blanquita se le asigne por error un número de seguridad social).

Para la Web semántica, la gran ventaja de la lógica reside en que proporciona explicaciones para las deducciones. Éstas son muy importantes para la Web semántica porque los agentes inteligentes de la nueva Web las usarán para tomar decisiones, ejecutar acciones y colaborar entre ellos (para que las deducciones sean válidas, deben basarse en afirmaciones fiables; volveré más adelante sobre este asunto). Por caso, un agente que reciba una reclamación de otro podrá comprobar por sí mismo la información del segundo y verificar que la reclamación es válida. Así, las deducciones aumentarán la confianza del usuario en los agentes de la Web semántica.

Consideremos, en el ejemplo de Fido, que el agente inteligente de su propietario solicita una vacunación antirrábica al agente de un veterinario. El segundo agente preguntaría al primero por el motivo de su petición (no todos los animales pueden sufrir la rabia). Acto seguido, el primero enviaría los metadatos (Fido es instancia de la clase Perro, Perro es subclase de Mamífero, etc.); y el segundo usaría sus reglas de inferencia para deducir que la petición de la vacuna antirrábica para Fido es válida. En consecuencia, el agente del veterinario asignaría una fecha y un día para la vacunación y lo anotaría en la agenda electrónica del veterinario.

Una deducción es cierta si se basa en datos fiables. Es aquí donde entra en juego una palabra mencionada ya antes: la confianza. En la figura de la Web semántica podemos ver que la capa de confianza (Trust) ocupa el lugar superior.

La confianza es un concepto que aparece a menudo cuando se consideran sistemas de software o comercio electrónico. Cuando decimos “Confío en una afirmación o un documento”, queremos decir que confiamos en su verdad; cuando decimos “Confío en un programa o en un agente”, tratamos de expresar que confiamos en que funcionan correctamente.

En la Web semántica, la confianza afecta a las siguientes áreas:

1. Certificación: cuando un agente trabaja con agentes que pertenecen a otras organizaciones, debe confiar en alguna "autoridad de confianza" que autentifique esos agentes. De la misma manera que hay empresas independientes que certifican que una página web pertenece a una empresa (piénsese en el candado amarillo de muchas páginas), deberá haber empresas que certifiquen que un agente de la Web semántica ha sido verdaderamente desarrollado por una compañía.
2. Credibilidad: cuando un agente proporciona información a un usuario o a otro agente, ¿hasta qué punto es correcta? La información puede ser poco fiable porque las fuentes de información no lo sean, porque no estén actualizadas o porque los algoritmos internos del agente tengan defectos.
   La poca fiabilidad de algunas fuentes de información salta a la vista. Por ejemplo, los foros de bolsa suelen estar plagados de falsedades y de opiniones basadas en sueños imposibles y corazonadas (algunas noticias económicas, también). ¿Qué fiabilidad se le debería dar a la frase "Al inversor que compró acciones de Terra Lycos a 157 euros yo le diría, con la mano en el corazón, que ha hecho una buena inversión"? Esta frase –merecedora de ser inscrita en mármol funerario para que sirva de ejemplo a las generaciones venideras– la pronunció Joaquín Agut, presidente de Terra, en mayo de 2001. Es un claro ejemplo de que, a veces, la información puede merecer poco crédito porque su emisor carece de neutralidad o tiene motivos para proporcionar información no del todo veraz o exacta (los resultados de Terra no justificaban su precio en absoluto, pero reconocerlo hubiera perjudicado los intereses de la compañía y de algunas agencias de bolsa).
3. Abuso de confianza: cuando un usuario o una organización proporcionan información a un agente de un tercero, es posible que ésta se emplee para los propósitos del propietario del agente, y no en beneficio de aquéllos. En el mejor de los casos, el uso de un agente así puede resultar inútil para quien lo usa; en el peor, puede resultar contraproducente e incluso perjudicial.
   Si una empresa, vaya por caso, proporciona a un agente malicioso información sobre sus clientes y proveedores creyendo que éste le ayudará a planificar sus compras y ventas, podría encontrarse con la desagradable sorpresa de que los datos vayan a parar directamente a la competencia. Otro ejemplo: consideremos un agente "espía" que haya sido diseñado para obtener diseños de circuitos electrónicos. El agente, disfrazado de piel de cordero, simulará ser un comprobador de circuitos (programa que verifica que un circuito está bien diseñado), pero enviará a un tercero los diseños que se supone que debe probar.
4. Revelación de secretos: para cumplir sus objetivos, los agentes pueden revelar a terceros información delicada sobre el usuario o la organización que los usan, ya sea por accidente, por defectos en su algoritmos o por no haber considerado la confidencialidad en su diseño. Por ejemplo, un agente que esté buscando una hipoteca para su usuario podría revelar a los agentes bancarios información sobre los ingresos de éste o sobre su solvencia. La potencia de los agentes radica en trabajar en un mundo abierto, pero esto también presenta inconvenientes. En la Web semántica, los agentes deberán estar sujetos a políticas de seguridad que garanticen que no transfieran datos confidenciales.

La inclusión de metadatos, aunque primitivos, ha fracasado en la Web ordinaria por falta de confianza: las palabras que aparecían en los campos META de las páginas HTML no solían describir el contenido real de éstas. He aquí un ejemplo del uso de los campos META en una página web:

Como no había ninguna organización que controlara que las palabras descriptivas de los campos META correspondían al contenido de las páginas web, los creadores de las páginas solían incluir en ellos palabras populares o atractivas (algunos lo siguen haciendo), pero que no describían bien sus páginas. Algunos buscadores clasificaban las páginas web según las palabras clave de los campos META, pero los resultados decepcionaban a los usuarios. Al final, la picardía de algunos erradicó la utilidad de los campos META. Los buscadores más populares del momento (Google, Yahoo) no tienen en cuenta estos campos.

En la Web semántica, como sucede en la Web actual, no todas las fuentes de información serán de confianza, y habrá algunas más fiables que otras. Para evitar extraer conclusiones de datos erróneos, falsos o malintencionados, la Web semántica necesitará disponer de mecanismos de confianza y credibilidad (firmas digitales, certificados de terceras partes, recomendaciones, agencias de calificación).

No debemos imaginar que habrá una inmensa burocracia encargada de asignar cierta calificación de confianza a cada documento que se publique. En algunos casos, los propios usuarios podrán valorar la fiabilidad de los documentos. Este proceso de valoración ya se está dando con buscadores como Google, cuyas búsquedas ordenan los resultados por el número de enlaces al resultado. Cada vez que un usuario coloca en un recurso suyo un enlace a otro recurso, hace que éste sea más relevante en las búsquedas e, indirectamente, le concede cierta fiabilidad. Por tanto, cuantos más enlaces apuntan a un recurso, más confianza se puede tener en él. En otros casos, será imprescindible la existencia de autoridades de certificación (p. ej., cuando se trabaje con agentes bancarios o de subastas).

Cuando uno haga una pregunta a la Web semántica, ésta proporcionará información sobre cuán fiable es la respuesta basándose en deducciones y en la fiabilidad de las fuentes consultadas, e incluso podrá adjuntar una prueba lógica (reglas de inferencia aplicadas a afirmaciones) de cómo ha generado la respuesta. Una consulta como "¿De qué pintor es El juego lúgubre?" obtendría la respuesta "Salvador Dalí"; si el usuario preguntara por la fiabilidad de la respuesta, obtendría una lista de las fuentes en que se basa la contestación (pinacotecas, catálogos oficiales, biografías, exposiciones) y un "calificación de fiabilidad" basada en el prestigio y reconocimiento de esas fuentes de información. En el caso de un cuadro de autenticidad dudosa –dicho sea de paso, Dalí tenía cierta tendencia a estampar, previo pago, su firma en lienzos y litografías en blanco–, el buscador presentaría una calificación de fiabilidad (un 65%, por ejemplo) basándose en la calidad de las fuentes consultadas.

Debido a la evolución, los cerebros humanos –excepto en algunos casos excepcionales– no están muy bien dotados para la lógica: formular silogismos era menos útil que correr rápidamente o tener brazos fuertes. Por este motivo, disponer de pruebas lógicas para búsquedas o preguntas será más útil para los agentes que para nosotros: podrán verificar por sí mismos las respuestas dadas por otros agentes a sus preguntas, mediante pruebas y mediante comprobaciones de la confianza que merecen las afirmaciones en que se sustentan las deducciones.

Desde un punto de vista teórico, las discusiones y disputas entre agentes no tendrán cabida, del mismo modo que las disputas entre personas carecerían de sentido si la humanidad hubiera adoptado el quimérico lenguaje artificial –lógico y perfecto– propuesto por Leibniz en el siglo XVII: "Una vez conseguido el lenguaje lógico perfecto –cada palabra, un concepto; cada concepto, una palabra–, se acabarán las discusiones; bastará que los interlocutores se sienten en los extremos de la mesa y sacando sus plumas digan: "¡Calculemos!".

En la figura inferior podemos ver un ejemplo de inferencia en el cual, a partir de las afirmaciones de Rosa y Juan, puede deducirse que Pilar tiene permisos de acceso a la intranet de Muebles 110. Si esas afirmaciones fueran "de confianza" (si estuviesen certificadas por la propia empresa, p. ej.), un agente podría deducir de manera fiable que Pilar debe tener acceso a la intranet; e incluso podría dárselo si ella no lo tuviera (por ejemplo, en el caso de que acabara de llegar a la compañía).

En conclusión, el largo camino hacia la Web semántica no pasa solamente por los metadatos. Se precisa además una cualidad muy apreciada en el mundo de los seres de carne y hueso: confianza. Cuanto más complejas son las herramientas que creamos para facilitarnos las cosas, tanto más nos vemos reflejadas en ellas.

En ésta ocasión decidí que, en vez de basarme en un ejemplo de los que vienen por defecto, voy a crear mi propio ejemplo, por lo tanto tomé algunas fotos que tengo en Flickr, agregarle información geográfica obtenida gracias a Google Earth (no tengo GPS) y luego subí la información a mi sitio. El contenido del archivo es el siguiente:

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
    xmlns:foaf="http://xmlns.com/foaf/0.1/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xml:lang="es-AR"
    >

    <foaf:Image rdf:about="http://static.flickr.com/78/207671826_49a7bb854e_m.jpg">
        <dc:title>Laburando</dc:title>
        <rdfs:seeAlso rdf:resource="http://flickr.com/photos/inkel/207671826/" />
        <geo:lat>-34.595680</geo:lat>
        <geo:long>-58.597090</geo:long>
    </foaf:Image>
    
    <foaf:Image rdf:about="http://static.flickr.com/65/202397299_4a24210570_m.jpg">
        <dc:title>Tango</dc:title>
        <rdfs:seeAlso rdf:resource="http://flickr.com/photos/inkel/202397299/" />
        <geo:lat>-34.559817</geo:lat>
        <geo:long>-58.449780</geo:long>
    </foaf:Image>
    
    <foaf:Image rdf:about="http://static.flickr.com/72/196691698_d55d983c12_m.jpg">
        <dc:title>Concurso de reflejos!</dc:title>
        <rdfs:seeAlso rdf:resource="http://flickr.com/photos/inkel/196691698/" />
        <geo:lat>-34.582577</geo:lat>
        <geo:long>-58.418267</geo:long>
    </foaf:Image>
    
</rdf:RDF>

Para visualizar estos datos, lo primero que debemos hacernos es abrir Tabulator y decirle que cargue la información que se encuentra en http://f14web.com.ar/inkel/2006/08/05/tabulator-example.rdf. Una vez cargada la información, nos encontraremos con lo siguiente:

Lo que debemos hacer ahora es desplegar la información sobre las foaf:Image que se encuentran en el archivo, haciendo click sobre el botón para visualizar información (), y luego hacer lo mismo para la foto titulada Tango. Al visualizarse ésta información, presionar ALT y hacer un click sobre latitude y longitud, con lo que obtendremos lo siguiente:

¡Y llegamos a la parte tan esperada! Ahora seleccionamos la pestaña Map y presionamos el botón View and Save Current Query y veremos dos cosas: la primera, triste, es que no existen mapas de la Argentina (flojo Google ahí). La segunda, más interesante, son los 3 globos que indican que existe información en el mapa:

Eso es todo lo que tuvimos que hacer para visualizar la información geográfica que se encontraba en el archivo. Por supuesto la parte más laboriosa es recopilar estos datos, pero solo tenemos que automatizar este proceso, dado que la visualización ya está resuelta. Para visualizar cada foto, debemos presionar el globo correspondiente, y veremos la información asociada:

Queda pendiente averiguar como agregar títulos y descripciones a cada imagen, pero no puede ser muy dificil :). Espero encuentren este ejemplo de utilidad, y como siempre, escucho sus comentarios.

Con el creciente desarrollo de la web los usuarios nos vimos beneficiados por la segunda Guerra de Navegadores, donde, en una opinión plenamente personal, se destacan principalmente Firefox y Opera. Si bien sus capacidades son por todos ampliamente conocidas, han sido diseñados para la web actual y, a pesar de contar con algunas herramientas, no se adaptan correctamente a la Web Semántica en su instalación más simple. Tal vez por esta razón el padre de la WWW, Tim Berners-Lee desarrolló una página que, utilizando AJAX y los conceptos de la Web Semántica, nos proporciona un prototipo de cómo podría ser un navegador para la WS: Tabulator.

Antes de continuar, y debido a que es mucho más interesante ir siguiendo su funcionamiento a lo largo del articulo, veamos la compatibilidad con los diversos navegadores disponibles:

• Firefox: único navegador con el que se ha probado en su totalidad. Si bien hay que realizar un ajuste de las reglas de seguridad del navegador para navegar recursos remotos, las mismas no transforman al sistema en inseguro.
• Opera: no ha sido probada plenamente, y no funciona con recursos remotos, por lo que se desarrolló un widget para Opera 9.
• Safari: presenta errores extraños, por lo que no recomiendo que lo utilicen, al menos, no de momento.
• Internet Explorer: no funciona en este navegador, aunque están viendo el por qué. No se si ha sido probado con la versión 7.0, aunque de todos modos no lo recomiendo.

Pasemos ahora a la descripción de lo que podemos hacer con Tabulator. Para comenzar, digamos que es un navegador particular, en el sentido de que navega cosas y no documentos. Por supuesto que algunas de éstas cosas son documentos, pero Tabulator primero los considera una cosa y luego un documento. Es importante hacer esta distinción, dado que hasta el momento todos los navegadores solo navegan documentos: una página web, una imagen.

Por otra parte, Tabulator navega por estos recursos de manera escalable, es decir, no solo permite navegar por más de una cosa por vez, sino que, además, no es necesario cargar en memoria y luego navegar toda una base de conocimiento en RDF. Esto se ajusta a la perfección a una de las ideas de la WS, que es poder definir información parcialmente incompleta, e ir tomando la información complementaria a medida que la necesitamos. Para esto utiliza un protocolo llamado protocolo de migajas de pan.

Protocolo de Migajas de Pan

Un protocolo de migajas de pan es aquel en el cual la información se deja incompleta para luego ser incrementada, dejando un enlace a la siguiente migaja. Cualquier similitud con Hansel & Gretel, no es pura coincidencia. Si el proveedor deja un enlace al complemento de información indicando el tipo de la misma, el consumidor puede actuar en consecuencia y de antemano para discernir que fragmentos de información son necesarios. Un ejemplo de este protocolo es el de enlaces FOAF, y funciona así: el documento ?d1 hace una referencia a la cosa referenciada por ?x en el documento ?d2 cuando:

?d1 log:says { ?y foaf:mbox_sha1sum ?s. ?y rdfs:seeAlso ?d2}.
?d2 log:says { ?x foaf:mbox_sha1sum ?s }.

Si el proveedor de información de ?d1 deja esa información, el consumidor, luego de haber leido ?d1 y deseando incrementar la información de ?y busca en el documento referenciado por rdfs:seeAlso, y encuentra en ?d2 la referencia a algo con el mismo valor de foaf:mbox_sha1sum y deduce que es la misma cosa. En este caso el protocolo asume que solo una persona (o entidad) es identificado por una dirección de email univoca, de ahí la validez de la suma SHA1.

Si bien esto es claramente más complejo que un simple enlace, Tabulator puede utilizar ambos. Los enlaces que pueden ser seguidos son representados por puntos azules ().

Con esto finalizamos esta primera parte sobre Tabulator. En el transcurso de los siguientes días nos adentraremos en ejemplos de utilización y otras funcionalidades. ¡Espero lo disfruten y me dejen sus comentarios!

La Web Semántica está dejando de ser un proyecto de laboratorio para transformarse día a día en una realidad, y a través de sitios como Web Semántica Hoy tenemos la posibildad de hacer llegar ésta realidad a todos aquellos que no hablan inglés. Mi intención es a partir de ahora comenzar a difundir las noticias que vayan surgiendo, e instar a todos aquellos que desarrollen proyectos o realicen investigaciones a compartir con nosotros sus dudas y logros y entre todos crear una comunidad en nuestro idioma, con nuestros códigos y cultura. Quienes compartan ésta visión o quieran hacerme llegar sus proyectos, pueden contactarse conmigo dejando su comentario aquí o a mi casilla personal. ¡Los espero a todos!

• Los clásicos elementos meta que aparecen entre las etiquetas <head> y </head> de un documento HTML.
• El contenido de un fichero RDF, el ya conocido estándar del W3C basado en la sintáxis de XML. Una forma de representar el contenido semántico de forma comprensible para las máquinas.
• Microformatos, otra forma de representar información semántica cuyo objetivo principal es ser útil a las personas y no a las máquinas (o mejor dicho a los agentes de software). Esta información aparece entre las etiquetas <body> y </body> de un documento HTML

Cada uno de estos tipos de información semántica tiene sus características, que podemos simplificar en una incompleta lista de ventajas e inconvenientes. Espero que los comentarios de los lectores completen esta lista (Emmanuelle ya lo ha hecho, y muy bien, gracias).

Las etiquetas meta: ventajas e inconvenientes

Entre las virtudes que caracterizan a las etiquetas meta, se encuentran:

• Aparecieron en las primeras especificaciones oficiales de HTML.
• Las etiquetas meta son ampliamente conocidas, y su uso está muy extendido.
• Como consecuencia del punto anterior, los agentes de software, como los buscadores, las conocen perfectamente.
• El número de etiquetas meta es prácticamente ilimitado. Por un lado tenemos las clásicas, como <link rel="author" content="Alejandro Gonzalo Bravo García">, pero se pueden usar también otras etiquetas meta usando perfiles y esquemas, como podemos leer en Metadatos geográficos (2): Empleándolos en ficheros HTML, XHTML y RDF.
• Como consecuencia del punto anterior, su uso se puede considerar que entra dentro de los "estándares".

Pero no todas son ventajas, veamos algunos inconvenientes:

• Se ha abusado del uso de etiquetas meta, y no siempre con propósitos correctos. La consecuencia: una buena parte de los buscadores ignoran estas etiquetas.
• Otra consecuencia del punto anterior es que en la actualidad no se utilizan demasiado, por ejemplo es raro encontrarse con elementos meta en los CMS más habituales. Aunque siempre se pueden añadir plugins que cumplan esa función.
• Los valores de estas etiquetas son invisibles a los usuarios. Siempre se puede mirar el código fuente, o ver las propiedades de la página web, pero sinceramente no es muy habitual.

Ficheros RDF: ventajas e inconvenientes

Comenzamos con las ventajas...

• Es un estándar del W3C con todo lo que ésto significa.

• Según podemos leer en la propia especificación...

  Resource Description Framework (RDF) [Infraestructura para la Descripción de Recursos] es una base para procesar metadatos; proporciona interoperabilidad entre aplicaciones que intercambian información legible por máquina en la Web. RDF destaca por la facilidad para habilitar el procesamiento automatizado de los recursos Web. RDF puede utilizarse en distintas áreas de aplicación; por ejemplo: en recuperación de recursos para proporcionar mejores prestaciones a los motores de búsqueda, en catalogación para describir el contenido y las relaciones de contenido disponibles en un sitio Web, una página Web, o una biblioteca digital particular, por los agentes de software inteligentes para facilitar el intercambio y para compartir conocimiento; en la calificación de contenido, en la descripción de colecciones de páginas que representan un "documento" lógico individual, para describir los derechos de propiedad intelectual de las páginas web, y para expresar las preferencias de privacidad de un usuario, así como las políticas de privacidad de un sitio Web. RDF junto con las firmas digitales será la clave para construir el "Web de confianza" para el comercio electrónico, la cooperación y otras aplicaciones.

  Resource Description Framework (RDF) Model and Syntax Specification, traducido por Eva Méndez

  De aquí podemos extraer que tiene un potencial inmenso, desde el punto de vista técnico (interoperabilidad entre aplicaciones y procesamiento automatizado de recursos) y muchos ámbitos de aplicación.

• Para su contenido se pueden usar infinidad de namespaces, cada uno de ellos con sus correspondientes elementos, como por ejemplo Dublin Core, FOAF, XMP, DOAC...

Y seguimos con los inconvenientes...

• Si bien es cierto que RDF Site Summary ha tenido una enorme difusión, no podemos decir lo mismo de RDF.
• Requiere más conocimientos ténicos para poder usarlo (no es tan sencillo como las etiquetas meta).
• Los buscadores actualmente suelen ignorar este tipo de metadatos cuando están fuera de un documento HTML, aunque también pueden aparecer dentro del propio documento entre comentarios, como ocurre por ejemplo con las licencias Creative Commons.
• Actualmente no abundan agentes de software que aprovechen las capacidades de RDF (o al menos no hay tantos como nos gustaría).
• En general la información contenida en ficheros RDF no se muestra a las personas. Aunque siempre nos podemos encontrar con agradables excepciones, como la herramienta para visualizar informes RDF obtenidos al hacer una revisión automática con HERA y que podemos ver en funcionamiento en Informes Hera.

Microformatos: ventajas e inconvenientes

Veamos primero sus puntos fuertes:

• Las personas obtienen fácilmente la información contenida en los microformatos: es su principio básico. ¿Dónde puedo encontrar microformatos? Seguramente los hayas visto, aunque no te hayas dado cuenta. Los puedes encontrar, por ejemplo, en Gurú Web, donde se utilizan microformatos generados con Dublin Core Metadata Gen (también se usan los elementos meta y los ficheros RDF, aunque tendrás que ver el código fuente para comprobarlo).
• A pesar del poco tiempo de vida, ha tenido bastante difusión.
• Existen multitud de microformatos con diferentes aplicaciones (consultar el listado Microformats Wiki), y cada vez van saliendo más.

Y ahora sus puntos menos fuertes...

• Es bastante reciente, y todavía no está muy asentado.
• La información no es interpretada con tanta facilidad como los ficheros RDF o las etiquetas meta. Pero el hecho de usar fórmulas estándar para codificar los microformatos, debería minimizar esta dificultad a los buscadores.
• Aunque existe XMDP™ para crear pefiles para los microformatos, no están tan formalmente definidos como los perfiles para las las etiquetas meta ó los namespaces. Además en el caso de los microformatos la relación entre los elementos del perfil y los microformatos no es tan exacta e inequivoca como en los perfiles o esquemas para las etiquetas meta ó los namespaces.
• Los microformatos son menos potentes, desde el punto de vista semántico, que otras formas de definir metadatos (como los mencionados ficheros RDF). Por ejemplo, no tienen la capacidad de definir formalmente relaciones complejas que puedan servir para que los agentes de software realicen inferencias o deducciones. Su campo de actuación es más limitado.

¿Más información semántica en HTML? ¿Cómo? ¿Dónde?

Por lo visto antes, parece que la única forma de incluir información semántica es mediante metadatos, ya sea en etiquetas meta, ficheros RDF ó microformatos. Pero no es así. Como podemos leer en la ayuda de HERA, al revisar la pauta 13.2

Son contenedores de metadatos, el elemento "title", el elemento "address", el elemento "meta", la declaración de tipo de documento (DTD), el elemento "link" y los elementos "del" e "ins", así como los atributos "title" y "cite".

Ayuda de HERA, al revisar la pauta 13.2

Para ampliar información, podemos leer el artículo de Emmanuelle titulado Navegación Semántica o Meta Navegación

meta, RDF, microformatos,... ¿qué metadatos son los mejores?

Como era de esperar, la respuesta es depende. En función de las características de cada tipo de metadatos, será más apropiado para unos desarrolladores o u otros. Igualmente depende también de dónde queramos utilizarlos y porqué.

Desde mi punto de vista, si queremos algo sencillo, lo mejor es usar meta. Con unos conocimientos un poco más avanzados se pueden usar elementos de perfiles ó esquemas muy potentes y versátiles (como por ejemplo Dublin Core). Si queremos usar unos metadatos más formales, aun a riesgo de que no se aproveche todo lo que se podría (al menos actualmente), creo que es una buena idea vincular en un documento web un fichero RDF externo. Aunque si no contamos con una aplicación que los genere de forma sencilla, como por ejemplo FOAF-a-Matic (traducido por inkel al español), puede ser algo más complicado y requiere conocimientos de XML y RDF.

Si tienes algunas dudas, en el artículo Metadatos geográficos (2): Empleándolos en ficheros HTML, XHTML y RDF se explican algunos conceptos básicos.

En el caso de que la prioridad sea facilitar a las personas la percepción de ciertos metadatos, una buena opción es usar microformatos. Algunos son muy sencillos de codificar (el ejemplo más claro es rel-tag, para que technorati catalogue mejor los artículos de las bitácoras), y no requieren grandes conocimientos: con saber un poco de HTML basta. Además puedes encontrar herramientas bastante útiles, como por ejemplo hCard Creator, para hacer tarjetas de visitas virtuales. Es muy interesante contar con la posibilidad de poder usar este tipo de microformatos, sobre todo teniendo en cuenta que algunos soy muy útiles. Pero su existencia y uso no resta importancia a los metadatos codificados más formalmente (si has pensado en RDF sumamos 10 puntos en tu marcador, je je).

Elementos meta, ficheros RDF, microformatos,... tres formas de mostrar metadatos generados con Dublin Core Metadata Gen

Volvamos otra vez a Dublin Core Metadata Gen, la herramienta que presentábamos al principio de este artículo. Y recordemos que era capaz de generar metadatos de Dublin Core de tres formas distintas:

• Elementos meta
• Ficheros RDF
• Microformatos Dublin Core

Tres opciones a elegir, y todos generados de una forma sencilla: algunos inconvenientes que hemos mencionado antes como la complejidad para generarlos, desaparecen. Sólo tenemos que utilizar los metadatos que más nos interesen... sólos o en compañía de otros metadatos generados por la misma herramienta (si recuerdas que en Gurú Web se utilizaban a la vez los tres metadatos, tienes diez puntos más en tu marcador, je je).

Experimento práctico: comparar la popularidad en los buscadores de los tres metadatos

Desde aquí planteo un pequeño experimento práctico para los lectores de Web Semántica Hoy: comparar la popularidad de los tres metadatos en los buscadores más habituales. ¿Cómo? Generando metadatos sobre algún recurso que no tenga muchos resultados en los buscadores (¿una palabra inventada, tal vez?), colocarlos en diferentes páginas webs y tras unos días comparar qué documentos están mejor posicionados en algunos buscadores. El ganar esta pequeña competición no signifique que tal o cuál metadato sea mejor que los otros, sino que es reconocido con más facilidad por los buscadores (hay otras formas de compararlos, aunque quizás no sean tan sencillas).

Desde luego en la competición no todos tienen las mismas probabilidades de "ganar" (en mi opinión RDF parte con desventaja), y el éxito puede venir condicionado por otros elementos externos, como por ejemplo el elemento title, o los títulos y contenido,... por tanto habría que ser equitativo y partir de tres documentos HTML idénticos... salvo en los metadatos.

No olvidéis compartir los resultados en los comentarios.

Con las ontologías, los usuarios organizarán la información de manera que los agentes de software podrán interpretar el significado y, por tanto, podrán buscar e integrar datos mucho mejor que ahora. Gracias al conocimiento almacenado en las ontologías, las aplicaciones podrán extraer automáticamente datos de las páginas web, procesarlos y sacar conclusiones de ellos, así como tomar decisiones y negociar con otros agentes o personas. Por ejemplo, un agente inteligente que busque un vino que satisfaga las preferencias de un usuario, usará las ontologías vinícolas para elegir el vino (color, sabor, olor, embotellado) y empleará las ontologías empresariales para encargarlo a alguna tienda y regatear en el precio (siempre que se pueda). Otro ejemplo: mediante las ontologías, un agente encargado de comprar viviendas se podrá comunicar con agentes hipotecarios (de entidades bancarias) y con agentes inmobiliarios (de empresas constructoras e inmobiliarias).

Si desea más información sobre ontologías o sobre la Web semántica, puede consultar el trabajo La Web del futuro (http://www.javahispano.org/tutorials.item.action?id=55). Puede encontrar una introducción a la Web actual (estructura, protocolos, etc.) en la primera parte de Java y las redes (http://www.javahispano.org/tutorials.item.action?id=45).

Las ontologías proceden del campo de la Inteligencia Artificial; son vocabularios comunes para las personas y aplicaciones que trabajan en un dominio. Según el Grupo de Trabajo en Ontologías del consorcio W3C, una ontología define los términos que se usan para describir y representar un cierto dominio. Uso la palabra "dominio" para denotar un área específica de interés (el río Duero, por ejemplo) o un área de conocimiento (física, aeronáutica, medicina, contabilidad, fabricación de productos, etc.) Toda ontología representa cierta visión del mundo con respecto a un dominio. Por ejemplo, una ontología que defina "ser humano" como "espécimen vivo o muerto correspondiente a la especie Homo sapiens; primate bípedo que pertenece a la familia de los homínidos, como los chimpancés, gorilas y orangutanes" expresa una visión del mundo totalmente distinta a la de una ontología que lo defina como "sujeto consciente y libre, centro y vértice de todo lo que existe; todos tienen la misma dignidad, pues han sido creados a imagen y semejanza de Dios".

Así como la Ontología –nótese la mayúscula inicial– estudia los tipos de objetos que pueblan la realidad (así como sus propiedades y relaciones), las ontologías catalogan y definen los tipos de cosas que existen en un cierto dominio, así como sus relaciones y propiedades. Por ejemplo, una ontología del mundo empresarial usará conceptos como Venta, Compra, Transferencia, Pago, etc.; y relaciones como “Una Transferencia corresponde a una Venta o a una Compra”, “Un Pago corresponde a una o varias Transferencias”, etc.

Existen ontologías específicas (de términos médicos, empresariales, aeronáuticos, etc.) y ontologías de carácter general (proporcionan terminologías útiles para varios campos). En http://www.snomed.org/ se puede encontrar una ontología médica (SNOMED). WordNet (http://wordnet.princeton.edu/perl/webwn) es una ontología lingüística en línea que organiza los nombres, verbos y adjetivos del idioma inglés en grupos de sinónimos. En http://www.unspsc.org/ se describe una ontología de carácter general desarrollada por las Naciones Unidas (es un vocabulario para servicios y productos).

Cualquier persona tiene en su cabeza ontologías mediante las que representa y entiende el mundo que lo rodea. Estas ontologías no son explícitas, en el sentido de que no se detallan en un documento ni se organizan de forma jerárquica o matemática. Todos usamos ontologías en las que Automóvil representa un medio de transporte y tiene cuatro ruedas. ¿Formalizamos este tipo de ontologías? No, sería innecesario: los automóviles son tan habituales que todos compartimos la información de lo que son. Lo mismo sucede cuando pensamos en el dominio familiar: sabemos que una familia se compone de varios miembros, que un hijo no puede tener más de un padre y una madre biológicos, que los padres tienen o han tenido padres... No necesitamos explicitar este conocimiento, pues forma parte de lo que todo el mundo sabe. Sin embargo, cuando se tratan términos poco comunes o cuando se quiere que estos términos sean procesados por máquinas, se precisa explicitar las ontologías; esto es, desarrollarlas en un documento o darles una forma que sea inteligible para las máquinas.

Las máquinas carecen de las ontologías con las que nosotros contamos para entender el mundo y comunicarse entre ellas; por eso necesitan ontologías explícitas. En cuanto dos sistemas de información (sistemas ERP, bases de datos, bases de conocimiento) intentan comunicarse, aparecen problemas semánticos que dificultan o imposibilitan la comunicación entre ellos (no considero aquí los problemas técnicos de conexión o envío de datos). Los problemas semánticos son de dos tipos: de dominio y de nombre. Los conflictos de dominio aparecen cuando conceptos similares en cuanto a significado, pero no idénticos, se representan en distintos dominios. Por ejemplo, el concepto representado por Trabajador en una base de datos (BD) puede corresponder a un trabajador cualificado, mientras que otra BD puede usar Trabajador para cualquier trabajador, sea o no cualificado. Ambos conceptos están muy vinculados, pero no son equivalentes ni deberían mezclarse. Usando ontologías, podría especificarse que el primer concepto corresponde a una especialización del segundo; y un sistema de razonamiento automático basado en ontologías impediría, por ejemplo, que se contratara para tareas cualificadas a trabajadores no cualificados.

Los conflictos de nombre son de dos tipos: sinónimos y homónimos. Los sinónimos ocurren cuando los sistemas usan distintos nombres para referirse al mismo concepto. Por ejemplo, una BD puede usar Trabajador para el mismo concepto que otra usa Empleado. En ese caso, se podría usar una ontología que definiera como idénticos los dos términos. Así, las aplicaciones que manejaran esas bases de datos sabrían como llevar datos de una a otra.

Las ontologías explícitas se pueden expresar de muchas maneras. Como mínimo, deben incluir un vocabulario de términos, con la definición de cada uno. Por ejemplo, la ontología empresarial Enterprise Ontology (EO) define así Venta: “Una Venta es un acuerdo entre dos Entidades Legales para el intercambio de un Producto por un Precio de Venta. Normalmente, el Producto es un bien o servicio y el Precio de Venta es monetario, aunque se incluyen otras posibilidades”. Las ontologías sencillas suelen representarse como una jerarquía de conceptos relacionados y ordenados.

Dependiendo del grado de formalidad, las ontologías explícitas se clasifican en informales, semi-informales, semi-formales y formales. Las primeras se expresan directamente en cualquier lenguaje natural. Las segundas se expresan en una forma estructurada y restringida de algún lenguaje natural. Las terceras se expresan en lenguajes estructurados, como RDF. Por último, las ontologías formales definen los términos mediante lenguajes lógico-matemáticos cuyos símbolos se definen exactamente y sin ambigüedades; en consecuencia, estas ontologías permiten emplear teoremas y demostraciones. Los dos últimos tipos de ontologías permiten que las aplicaciones puedan usar las definiciones de los conceptos del dominio y sus relaciones. Así como los tres primeros tipos de ontologías pueden contener términos ambiguos o inconsistentes, las ontologías formales no los permiten. Preguntas tan capciosas como "El único barbero de una ciudad afeita a todos los hombres que no se afeitan a sí mismos. ¿Quién lo afeita a él?"o "¿A qué conjunto pertenece el conjunto de los conjuntos que no se incluyen a sí mismos?" no pueden representarse en una ontología formal. A continuación figura un fragmento de una ontología formal (la expreso con la sintaxis XML de OWL DL). Corresponde a un dominio cartográfico:

<owl:Class rdf:ID="Mapa">
   <rdfs:subClassOf> 
      <owl:Restriction>
         <owl:onProperty rdf:resource="#tieneEscalaPredeterminada"/>
         <owl:maxCardinality 
            rdf:datatype="&xsd;nonNegativeInteger"> 1
         </owl:maxCardinality> 
      </owl:Restriction>
   </rdfs:subClassOf> 
</owl:Class>

<owl:ObjectProperty rdf:ID="tieneEscala">
   <rdfs:domain rdf:resource="#Mapa"/> 
   <rdfs:range rdf:resource="#Escala"/> 
</owl:ObjectProperty>

<owl:ObjectProperty rdf:ID="tieneEscalaPredeterminada"> 
   <rdfs:subPropertyOf rdf:resource="#tieneEscala"/>
</owl:ObjectProperty>

Este fragmento define que las entidades Mapa tienen una propiedad llamada tieneEscala, que a su vez tiene una subpropiedad llamada tieneEscalaPredeterminada, y que un Mapa no puede tener más de una escala predeterminada.

Las ontologías se usan para favorecer la comunicación entre personas, organizaciones y aplicaciones, lograr la interoperabilidad entre sistemas informáticos, razonar automáticamente y para la ingeniería de software.

Las ontologías favorecen la comunicación entre personas, organizaciones y aplicaciones porque proporcionan una comprensión común de un dominio, de modo que se eliminan confusiones conceptuales y terminológicas. Los problemas derivados de la falta de comprensión común entre personas revisten una gran importancia en la ciencia y en la tecnología. Por ejemplo, hasta hace muy poco (septiembre de 2005) no existía un consenso general sobre la nomenclatura y clasificación de las neuronas corticales. Por lo tanto, al estudiar enfermedades como la esquizofrenia, la depresión, el trastorno bipolar y el Alzheimer, los médicos no se ponían de acuerdo sobre qué tipos de neuronas estaban afectadas. Pese a todas las investigaciones relacionadas con el cerebro, no había unanimidad a la hora de clasificar las neuronas corticales. La situación era sorprendente, tanto más cuanto que las investigaciones sobre la corteza cerebral comenzaron hace unos cien años, con el premio Nobel español Santiago Ramón y Cajal. El resultado final de dicha falta de entendimiento común durante cien años ha sido un gran retraso en las investigaciones sobre el cerebro, así como una bibliografía científica confusa y a veces contradictoria.

En los campos de la Inteligencia Artificial, la Teoría de Decisiones y la Teoría de Sistemas Distribuidos (campos muy relacionados con la Web semántica), sucede algo parecido: los investigadores de un campo no pueden leer fácilmente los resultados de los investigadores de los otros, pues se usan diferentes perspectivas y términos para las mismas ideas y conceptos. Construyendo una ontología común para los tres campos, las investigaciones de un campo serían inmediatamente aplicables a los otros.

El mundo empresarial no es tampoco ajeno a los problemas derivados de la falta de un entendimiento común: algunas empresas usan el término "recursos" para lo que son "máquinas" para otras empresas. Para otras, en cambio, los "recursos" son las "materias primas" que usan. Mediante las ontologías, se favorece la gestión de contenidos, la integración de la cadena de suministro y de la cadena de valor, así como la estandarización de la información de los mercados electrónicos (e-marketplaces). Esta estandarización resulta imperiosa para el comercio electrónico automático: si cada vendedor llama o clasifica de una manera a sus productos, resulta muy difícil automatizar las operaciones electrónicas. Por ejemplo, si un agente inteligente quiere comprar una memoria USB para un usuario o una empresa, deberá tener en cuenta que "memoria USB", "pen drive", "memoria flash USB" y "lápiz USB" designan un mismo dispositivo. En caso contrario, la aplicación no verá a muchos fabricantes y vendedores del dispositivo y, por ende, perderá muchas oportunidades de negocio.

Las ontologías favorecen también la comunicación entre aplicaciones y la comprensión común de la información entre ellas. Las ontologías serán imprescindibles en la Web semántica y en los futuros sistemas de gestión empresarial porque permitirán que las aplicaciones estén de acuerdo en los términos que usan cuando se comunican. Mediante ellas, será mucho más fácil recuperar información relacionada temáticamente, aun cuando no existan enlaces directos entre las páginas web. Por ejemplo, una ontología puede usarse para especificar que las termitas son un tipo de isóptero. De este modo, un buscador que use esa ontología mostrará páginas web sobre termitas cuando un usuario busque información sobre los isópteros.

Del mismo modo, si en una intranet empresarial se quisiese encontrar información sobre las ferias que ha visitado el director de la compañía, resultaría muy útil disponer de una ontología que incluyera una relación Visita, con relaciones "hijas" como VisitaFeria, VisitaEmpresa, etc. Clasificando los documentos con esa ontología, una búsqueda en la intranet mostraría enseguida los documentos relacionados con las visitas del director a ferias. Sin la ontología, la búsqueda se haría mediante palabras clave como "visita", "feria" y el nombre del director, lo que arrojaría una gran cantidad de resultados (muchos inútiles), que deberían ser evaluados, para determinar su pertinencia, por una o más personas.

Las ontologías también sirven para conseguir que los sistemas interoperen. Dos sistemas son interoperables si pueden trabajar conjuntamente de una forma automática, sin esfuerzo por parte del usuario. Por ejemplo, dos teléfonos móviles de distintos fabricantes y abonados a diferentes compañías telefónicas interoperan para que los usuarios puedan hablar entre sí. En el campo de la informática, las ontologías sirven para traducir los términos usados por una aplicación a otra (las aplicaciones pueden estar escritas en distintos lenguajes de programación). Consideremos una aplicación empresarial que usa el término "materia prima" y otra que emplea "suministro": ambas no podrían trabajar juntas. Para lograr que interoperen, una ontología haría de traductora entre ambas (la ontología podría usar el término "recurso"). La ontología actuaría como puente entre ambas, como una especie de lengua común. Vaya por caso, si se quiere que cuatro aplicaciones (A1, A2, A3 y A4) interoperen se necesitan seis aplicaciones que actúen de "traductores" (A1-A2, A1-A3, A1-A4, A2-A3, A2-A4, A3-A4); con una ontología común (O), sólo se necesitarían cuatro "traductores" (A1-O, A2-O, A3-O, A4-O). Según aumenta el número de aplicaciones que deben interoperar, más necesario se hace emplear ontologías traductoras.

Las ontologías resultan muy útiles para facilitar el razonamiento automático, es decir, sin intervención humana. Partiendo de unas reglas de inferencia, un motor de razonamiento puede usar los datos de las ontologías para inferir conclusiones de ellos. Por ejemplo, si establecemos estas reglas: "Todos los ríos desembocan en un mar, en un océano o en un lago" y "Si el curso de un río termina en una población, esa población está junto al mar, océano o lago donde desemboca", las máquinas pueden hacer deducciones como la mostrada en la siguiente figura.

Una de las aplicaciones más importante del razonamiento automático es la validación de datos. Consideremos, por ejemplo, una base de conocimiento que almacene hechos sobre una consultora: "El proyecto Hospital Universitario comprende las tareas A1, A2 y A3", "Luis trabaja en la tarea A1", etc. Si los hechos se almacenaran mediante una ontología formal, se podrían imponer reglas (axiomas) como "Un empleado no puede trabajar en tareas de proyectos donde no participa" o "La suma semanal de horas trabajadas por un empleado no puede diferir de la suma semanal de horas empleada en cada tarea que tiene asignada"; reglas que servirían para verificar los hechos que se van almacenando y detectar incoherencias.
Otro ejemplo: suponga una pizzería que venda, entre otros tipos, pizzas vegetarianas. Si la pizzería usara una ontología que definiera qué ingredientes son vegetarianos –y cuáles no– y estableciera una regla como "Las pizzas vegetarianas no llevan ingredientes cárnicos", la aplicación de contabilidad podría detectar, en el momento del cobro, cualquier venta en la que, por error, se hubiera añadido pollo o jamón a una pizza vegetariana.

El razonamiento automático también se usa para establecer relaciones entre ontologías (por ejemplo, Producto en la ontología O1 es Materia Prima en la ontología O2), para descubrir relaciones ocultas o inesperadas entre los datos y para integrar esquemas de bases de datos. La integración de esquemas de bases de datos resulta imprescindible cuando se trabaja con bases de datos federadas, que son vistas unificadas de bases de datos independientes. Estas bases de datos aparentan ser una sola base de datos, pero se componen de información extraída de bases de datos independientes, que pueden estar alejadas miles de kilómetros. Una BD federada aparenta ser una BD normal y corriente, pero no tiene existencia física: es una vista lógica. Las bases de datos federadas son muy importantes en la Web, pues dan una vista común de los datos procedentes de fuentes muy distintas (agencias de noticias, portales, foros, periódicos y revistas electrónicos, etc.).

En la ingeniería del software, las ontologías ayudan a la especificación de los sistemas de software. Como la falta de un entendimiento común conduce a dificultades en identificar los requisitos y especificaciones del sistema que se busca desarrollar, las ontologías facilitan el acuerdo entre desarrolladores y usuarios.