Inteligencia Artificial Representación del conocimiento I.T. en Informática de Sistemas, 3º Curso académico: 2010/2011 Profesores: Ramón Hermoso y Roberto Centeno Índice • Introducción a la representación del conocimiento a. Ingeniería del conocimiento b. Ontologías c. Sistemas basados en reglas • Ontologías • Sistemas basados en reglas • Web Semántica Representación del conocimiento: motivación (i) • Espacio de estados – representación de los conocimientos a priori del agente • estado inicial: símbolo (s0) • estados sucesores: función expandir (s7→{s8,s10,s12,s27,s112} ) • estados meta: función meta? (s112 → true) • coste de operador: función c((s7, s112)→5) • heurística: función h* (s7 → 235 ) – se abstrae completamente de las características de los estados: • en el estado s3 se cumple que – ¿bloque A encima de bloque B? – ¿el agente se encuentra en Madrid? – ¿Jarra dos está vacía? – Problema: • complejidad de la representación del conocimiento (p.e. expandir) • mantener (estructura y datos) del conocimiento Representación del conocimiento: motivación (ii) B C A expandir A B C apilar(a,b,s0) s0 • Conocimiento a priori: – conocimiento sobre el estado s0: libre(a,s0) ∧ libre(b, s0) – conocimiento sobre acciones: ∀S ∀X ∀Y [ libre(X,S) ∧ libre(Y,S) ∧ X≠Y → encima( X,Y, hacer(apilar(X,Y),S) ) ] • Inferencia modus ponens – conocimiento sobre el estado hacer(apilar(a,b),s0): encima(a,b,hacer(apilar(a,b),s0)) Representación del conocimiento • Lenguaje de Representación del Conocimiento (LRC) – Sentencias: describir características relevantes del entorno – Inferencia: sacar conclusiones a partir de estas características – Semántica: relaciona las sentencias del LRC con los hechos del entorno entorno/ mundo Hechos producen semántica Lenguaje de representación del conocimiento sentencias del LRC Hechos semántica inferencia sentencias del LRC Índice • Introducción a la representación del conocimiento – Ingeniería del conocimiento – Ontologías – Sistemas basados en reglas • Ontologías • Sistemas basados en reglas • Web Semántica Ingeniería del Conocimiento (i) • ¿Cómo obtener conocimientos sobre un entorno? • ¿Cómo modelar / estructurar el conocimiento? • ¿Cómo usar un Lenguaje de Representación del Conocimiento para modelar conocimientos sobre un entorno? Modelo a nivel de conocimiento Instrumentación (¿cómo?) Modelo a nivel simbólico (en LRC) Racionalización (¿por qué?) observación Ingeniero del conocimiento “Agente natural”/ Experto Ingeniería del Conocimiento (ii) “Un ingeniero del conocimiento es alguien que investiga un dominio concreto, aprende qué conceptos son los importantes en ese dominio y crea una representación formal de los objetos y relaciones del dominio.” [Russell & Norvig] • Identificar la tarea – Identificar preguntas y respuestas a la base de conocimiento • Recopilar el conocimiento – Adquirir de un experto del dominio • Decidir el vocabulario – Vocabulario del dominio (ontología) • Codificar el conocimiento – Definir conocimientos en base al vocabulario • Codificar una instancia • Plantear peticiones • Depurar Ingeniería del Conocimiento (iii) • Construcción de una Base de Conocimiento: – Proceso de creación de modelos de un comportamiento inteligente deseado – Modelo a nivel de conocimiento: • ¿Cuál es el conocimiento que implica el comportamiento deseado en un agente racional? • Caracterizar y estructurar dicho conocimiento – Modelo a nivel simbólico: • Codificación del conocimiento en un Lenguaje de Representación del Conocimiento • Automatización del razonamiento/comportamiento mediante mecanismos de inferencia en la Base de Conocimiento Ingeniería del Conocimiento (iv) • Creación de aplicaciones: analogías Ingeniería del conocimiento Lenguajes de Programación Ingeniero del conocimiento Analista / Programador Lenguaje de Representación del Conocimiento Lenguaje de Programación Base de Conocimiento Programa Reglas de Inferencia Compilador Inferencia en la Base de Conocimiento Ejecución del programa Base de Conocimiento • Base de conocimiento (BC): conjunto de sentencias en un LRC + mecanismos de inferencia automática • Base de Conocimiento de un agente: – contiene los conocimientos del agente sobre su entorno • conocimiento general del dominio • conocimiento del caso – interacción con la Base de Conocimiento • Informar (sentencia): añadir nueva información a la Base de Conocimiento • Preguntar (sentencia): determinar si una sentencia se puede inferir a partir de los conocimientos de la Base de Conocimiento Arquitectura de un agente basado en el conocimiento Percepción Informar(percepción) Preguntar(x) Selección de acciones {x/respuesta} Informar(acción) Ejecutar acción Acción Base de conocimiento Tipos de Lenguaje de Representación del Conocimiento • LRC lógicos – Permitir discurso riguroso sobre diferentes aspectos del mundo real – Lógica de primer orden: estándar – Lógica modal: tiempo, creencias, procesos – Lógica difusa: incertidumbre • LRC cognoscitivos – Restringir la expresividad del lenguaje para lograr una inferencia más eficiente – Representaciones más fáciles de entender para humanos – Ejemplos: reglas, marcos, TMS, Redes Bayesianas • LRC para interoperabilidad – facilitar el intercambio de conocimiento entre agentes – Ejemplo: KIF (Knowledge Interchange Format), FIPA SL Índice • Introducción a la representación del conocimiento – Ingeniería del conocimiento – Ontologías – Sistemas basados en reglas • Ontologías • Sistemas basados en reglas • Web Semántica Ontologías: Conceptos • Definiciones de Ontología – Filosofía [Sowa, 2000] • “El estudio de las categorías que existen o deberían existir en un dominio” – Típicas en IA • • [Chandrasekaran et al., 1999] – “Representación del vocabulario, habitualmente centrado en el dominio o propósito del problema” – “La parte del conocimiento que describe un dominio en particular, utilizando un vocabulario representativo” [McGuinness, 2002] – • “Representación del conocimiento, ingeniería del conocimiento, modelado cualitativo, ingeniería del lenguaje, diseño de bases de datos, recopilación y recuperación de la información, y mantenimiento y organización del conocimiento” [Kalfoglou, 2001] – “La ontología es la representación concreta del conocimiento compartido referente a conceptos en un dominio de interés” – “Vocabulario para la representación de conceptos y relaciones en un dominio concreto” Ontologías: Representaciones (i) • Múltiples formas para representación de ontologías: – Redes Semánticas: plays Instrument Admirer attends Musician plays at records Album Event – Modelos UML – Lenguajes de representación de ontologías (Ej. OWL) – ... Ontologías: Representaciones (ii) • Múltiples formas para representación de ontologías: – Redes Semánticas: – Modelos UML – Lenguajes de representación de ontologías (Ej. OWL) – ... Ontologías: Representaciones (iii) • Múltiples formas para representación de ontologías: – Redes Semánticas: – Modelos UML – Lenguajes de representación de ontologías (p.e. OWL) <owl:Class rdf:ID=”Event”/> <owl:Class rdf:ID=”Album”/> <owl:Class rdf:ID=”Instrument”/> <owl:Class rdf:ID=”Musician”/> <owl:Class rdf:ID=”Admirer”/> <owl:ObjectProperty rdf:D=”author”> <owl:inverseOf> <owl:ObjectProperty rdf:ID=”opus”/> </owl:inverseOf> <rdfs:domain rdf:resource=”#Album”/> <rdfs:range redf:resource=”#Musician”/> </owl:ObjectProperty> <owl:Object Property rdf:ID=”player”> <rdfs:range rdf:resource=”#Musician”/> <rdfs:domain rdf:resource=”#Instrument”/> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID=”loudness”> <rdf:type rdf:resource=”http://www.w3.org/2007/07/owl#FunctionalProperty”/> <rdfs:domain rdf:resource=”#Instrument”/> </owl:ObjectProperty> ... – ... ¿Por qué ontologías? (i) • Proporcionan características útiles para sistemas inteligentes – para la ingeniería del conocimiento • Características – Vocabulario – Taxonomías – Lenguajes de representación – Compartir el conocimiento y reutilizarlo ¿Por qué ontologías? (ii) • Proporcionan características útiles para sistemas inteligentes – para la representación del conocimiento – para la ingeniería del conocimiento • Características – Vocabulario • La ontología proporciona un vocabulario (o nombre) para referencia todos los términos de un área concreto – Vocabulario controlado: catálogo finito que evita interpretaciones ambiguas – Glosario: proporciona una lista de términos con su significado – Diccionario: proporcionan información semántica adicional, en forma de sinónimos, reduciendo la ambigüedad. • El vocabulario proporciona una descripción lógica de los términos, con posibles reglas para combinarlos y sin ambigüedades. Puede ser procesado de forma automática. – Taxonomías – Lenguajes de representación – Compartir el conocimiento y reutilizarlo ¿Por qué ontologías? (iii) • Proporcionan características útiles para sistemas inteligentes – para la representación del conocimiento – para la ingeniería del conocimiento • Características – Vocabulario – Taxonomías • Clasificación de los elementos del dominio (conceptos ordenados de forma jerárquica) – según características comunes, dictadas por un sistema predeterminado – deseable que la clasificación separe los las entidades en exclusividad mutua – deseable que sea sencilla y fácil de utilizar • • Procesada de forma automática. La taxonomía el vocabulario forman la parte conceptual para discusión, análisis y recuperación de información del dominio – Lenguajes de representación – Compartir el conocimiento y reutilizarlo ¿Por qué ontologías? (iv) • Proporcionan características útiles para sistemas inteligentes – para la representación del conocimiento – para la ingeniería del conocimiento • Características – Vocabulario – Taxonomías – Lenguajes de representación • Herramienta para representación de: – – – • propiedades, posibles valores, valores, restricciones, etc. relaciones (lenguajes lógicos) Representación muy estructurada del conocimiento Características: – – comprobaciones de consistencia facilidad para la interoperabilidad entre aplicaciones (estándares) – Compartir el conocimiento y reutilizarlo ¿Por qué ontologías? (v) • Proporcionan características útiles para sistemas inteligentes – para la representación del conocimiento – para la ingeniería del conocimiento • Características – Vocabulario – Taxonomías – Lenguajes de representación – Compartir el conocimiento y reutilizarlo • Lo más importante!!! Ontología común para distintas aplicaciones – cada aplicación construye su conocimiento en base a una ontología – intercambio de conocimiento → intercambio de las instancias de la ontología • Especialización de ontologías: – utilizar jerarquía de ontología ya existente (extensión, herencia, etc.) En la práctica no es tan sencillo… ¿Para qué sirven las ontologías? (i) • Utilización: – Colaboración • Diferentes grupos de trabajo con el mismo problema: representación común del conocimiento • Diferentes sistemas inteligentes: intercambio de conocimiento (LRC para interoperabilidad) – Interoperabilidad • Integración de información desde distintas fuentes de datos (Web Semántica) – Ontologías comunes en todas las fuentes de datos → integración sencilla – Ontologías distintas en la fuentes → reglas de transformación de ontologías (Web Semántica !!!) – Educación • Ontología estructura el conocimiento → más fácil el compartir conocimiento • Medio de expresión para los expertos en el dominio – Modelado • Estructuración del conocimiento del dominio • Reutilización de definiciones de ontologías por varias aplicaciones – Más pragmático • Comercio electrónico, motores de búsqueda, etc. (de nuevo, Web Semántica) Índice • Introducción a la representación del conocimiento – Ingeniería del conocimiento – Ontologías – Sistemas basados en reglas • Ontologías • Sistemas basados en reglas • Web Semántica Bases de conocimiento basadas en reglas DEFINICIÓN mecanismo de inferencia automática conjunto de sentencias en un LRC <BH,BR,MI> BASE DE HECHOS (Memoria de trabajo) Representa conocimientos sobre el problema:datos, hechos establecidos y metas a alcanzar BASE DE REGLAS Representa conocimientos sobre la solución del problema en forma de producciones MOTOR DE INFERENCIA Razona con el conocimiento del problema y sobre su solución Determina cómo se aplican las reglas Base de Hechos (i) • Hechos – estructuras de datos: aserciones sobre objetos / situaciones, etc. – representamos hechos como listas de símbolos – pueden concebirse como relaciones entre entidades – ejemplo: (bloque A) (bloque B) (clear T) • Base de hechos (BH): – representa el modelo del mundo (o el problema en curso de solución) – cambia con el proceso de inferencia • Estado inicial: situación inicial • Estado final: situación final • Estado intermedio: situación actual o en curso de resolución – ejemplo BH: (bloque A) (bloque B) (on A B) (on B T) (clear A) Base de Hechos (ii) • Partes de la Base de Hechos: – permanente: hechos invariables • describen características que siempre se dan en el problema • Ejemplo: (bloque A) (bloque B) (clear T) – temporal: hechos variantes • cambian durante el proceso de la solución del problema • Ejemplo: (on A B) (on B T) (clear A) • Modificación de la Base de Hechos: – añadir hechos a la Base de Hechos – borrar hechos de la Base de Hechos – modificar hechos de la Base de Hechos Base de Reglas (i) • Regla: – Representa una parte del conocimiento sobre la solución del problema – Sintaxis: (defrule <nombre_regla> [...] <premisas> => <acciones>) – Ejemplo Regla: (defrule socrates_mortal antecedente (hombre socrates) => (assert (mortal socrates)) consecuente ) – Semántica • Si todas las premisas se encuentran en la Base de Hechos, se pueden ejecutar todas las acciones sobre la Base de Hechos • Ej.: Si (hombre Socrates) se encuentra en la BH, se puede añadir (mortal Socrates) a la BH • Base de Reglas (BR): – conjunto de reglas: agrupa el conocimiento sobre la solución del problema – La BH describe el problema, la BR da información para resolverlo Base de Reglas (ii) • Reglas con variables: – premisas y acciones pueden contener constantes (p.e. A, ladra, on) o variables (p.e. ? x) – Ejemplos: (defrule hombre_mortal (hombre ?x) => (assert (mortal ?x)) ) (defrule ancestro (padre ?x ?y) (padre ?y ?z) => (assert (ancestro ?x ?z)) ) • Semántica: – Una variable puede ligarse con cualquier constante de un hecho en la misma posición – Una variable ha de ligarse al mismo valor en toda la regla • Nótese: – sólo las reglas pueden contener variables, no los hechos – cualquier variable del consecuente ha de ligarse anteriormente en el antecedente Motor de Inferencia (i) • Mecanismo automático que permite contestar consultas a partir de una Base de Conocimiento basada en reglas • Dos posibles estrategias de inferencia para BC basadas en reglas – Encadenamiento hacia delante (inglés: forward chaining) Soluciones intermedias BH inicial Consulta (BH final) BR – Encadenamiento hacia atrás (inglés: backward chaining) Objetivo (Consulta) Subobjetivos BR BH inicial Soluciones Motor de Inferencia (ii) • Mecanismo de encadenamiento hacia delante: – a partir de la BH1 se intenta deducir una BHn en la que se cumple la consulta – “disparando” sucesivamente las reglas Ri de la BR – cada disparo de una regla caracteriza un ciclo de razonamiento CCk BH1 CC1 R1 CC2 R2 ... Rm CCn-1 BH2 Ri ... Rj BHn-1 BHn Rk Ciclo de Inferencia (i) Paso 1: Detección de reglas aplicables (determinación del conjunto conflicto) Paso 2: Selección de una regla aplicable (resolución del conjunto conflicto) Paso 3: Aplicación de una regla y actualización de la BH (disparo de la regla) Ciclo de Inferencia (ii): Detección de reglas aplicables • Equiparación: – Selección del conjunto de reglas candidatas para dispararse, las que son compatibles con la BH (instancias de reglas aplicables o activadas) BH (enfermedad Pepe pulmón) (enfermedad Juan corazón) (enfermedad María corazón) (edad Pepe 18) (enfermedad ?persona corazón) (enfermedad Juan corazón), ?persona=Juan (enfermedad María corazón), ?persona=María • Conjunto conflicto: – todas las (instancias de) reglas que son aplicables en el presente ciclo – puede haber varias instancias de la misma regla en el conjunto conflicto Ciclo de Inferencia (iii): Selección de una regla aplicable Estrategias de selección: • Establecer un orden de preferencia en la aplicación de las reglas • Preferencia basada en las reglas – prioridad explícita: asignar valores de prioridad a cada regla – prioridad implícita: orden de de las reglas en la BR (Prolog) – refracción: historia de una regla (la más/menos disparada) – especificidad: preferir la reglas con más/menos condiciones • Preferencia basada en las instancias de reglas – la más antigua en el conjunto conflicto (estrategia de amplitud) – la más nueva en el conjunto conflicto (estrategia de profundidad) • Preferencia basada en objetos – selección de reglas que se aplican a los objetos más recientes – prioridad explícita: asignación de prioridades a las patrones más comunes de la BH Ciclo de Inferencia (iv): Aplicación y actualización de la BH • “Disparo” de la instancia de regla seleccionada: – se ejecutan todas las acciones del consecuente de la (instancia de) regla – se modifica la BH actual dando lugar a una BH nueva al añadir y borrar elementos de la primera – la BH nueva se tomará como punto de partida en el siguiente ciclo de funcionamiento ( ¡¡ por tanto es posible que algunas reglas se eliminen del antiguo conjunto conflicto !!) • Parada del mecanismo de inferencia: – cuando no hay más reglas aplicables en el conjunto conflicto – cuando el consecuente de una regla ejecuta un comando de parada (regla de terminación, puede codificar la consulta) (halt en CLIPS) Ejemplo de inferencia hacia adelante en BC de reglas (i) CONSULTA: ¿(perro Tucky)? BASE DE REGLAS (defrule R1 (animal ?A) (esqueleto ?A si) => (assert (vertebrado ?A)) ) (defrule R2 (animal ?A) (esqueleto ?A no) => (assert (invertebrado ?A)) ) (defrule R3 (vertebrado ?A) (ladra ?A) => (assert (perro ?A)) ) BASE DE HECHOS BH1 (animal Tucky) (animal Piolin) (esqueleto Piolin si) (esqueleto Tucky si) (ladra Tucky) MOTOR DE INFERENCIA R1, R1, ?A?A == Tucky Tucky Ciclo 1: (animal Tucky) (animal Piolin) (esqueleto Piolin si) (esqueleto Tucky si) (ladra Tucky) (vertebrado Tucky) R1, ?A = Piolin Ejemplo de inferencia hacia adelante en BC de reglas (ii) CONSULTA: ¿(perro Tucky)? BASE DE REGLAS (defrule R1 (animal ?A) (esqueleto ?A si) => (assert (vertebrado ?A)) ) (defrule R2 (animal ?A) (esqueleto ?A no) => (assert (invertebrado ?A)) ) (defrule R3 (vertebrado ?A) (ladra ?A) => (assert (perro ?A)) ) BASE DE HECHOS BH2 (animal Tucky) (animal Piolin) (esqueleto Piolin si) (esqueleto Tucky si) (ladra Tucky) (vertebrado Tucky) MOTOR DE INFERENCIA Ciclo 2: R1, ?A = Piolin R3, ?A = Tucky (animal Tucky) (animal Piolin) (esqueleto Piolin si) (esqueleto Tucky si) (ladra Tucky) (vertebrado Tucky) (vertebrado Piolin) Ejemplo de inferencia hacia adelante en BC de reglas (iii) CONSULTA: ¿(perro Tucky)? BASE DE REGLAS (defrule R1 (animal ?A) (esqueleto ?A si) => (assert (vertebrado ?A)) ) (defrule R2 (animal ?A) (esqueleto ?A no) => (assert (invertebrado ?A)) ) (defrule R3 (vertebrado ?A) (ladra ?A) => (assert (perro ?A)) ) BASE DE HECHOS BH3 (animal Tucky) (animal Piolin) (esqueleto Piolin si) (esqueleto Tucky si) (ladra Tucky) (vertebrado Tucky) (vertebrado Piolin) MOTOR DE INFERENCIA R1, ?A = Tucky Ciclo 3: R3, ?A = Tucky (animal Tucky) (animal Piolin) (esqueleto Piolin si) (esqueleto Tucky si) (ladra Tucky) (vertebrado Tucky) (vertebrado Piolin) (perro Tucky) Ciclo de Inferencia (v): Aspectos de Implementación Problema: – Ineficiencia del mecanismo de inferencia debido a la Fase 1 (determinación del conjunto conflicto) – En cada ciclo se equiparan todas las reglas con todos los elementos de la Memoria de Trabajo (MT) para construir el nuevo conjunto conflicto Solución: Algoritmo de Redundancia Temporal (RETE) – se construye el conjunto conflicto de forma incremental Cambios en la MT Red RETE Cambios en el CC – la red RETE se genera al principio de la ejecución del sistema de producción mediante un compilador Ejercicio: ejecución defrule R1 (persona ?x) (madrileno ?x) => (assert (espanol ?x))) (defrule R2 (persona ?x) (toledano ?x) => (assert (espanol ?x))) (defrule R3 (persona ?x) (parisino ?x) => (assert (frances ?x))) (defrule R4 (persona ?x) (californiano ?x) => (assert (estadounidense ?x))) (defrule R5 (persona ?x) (espanol ?x) => (assert (europeo ?x))) (defrule R6 (persona ?x) (frances ?x) => (assert (europeo ?x))) (defrule R7 (persona ?x) (europeo ?x) => (assert (no_pedir_pasaporte ?x))) (defrule R8 (persona ?x) (not (europeo ?x)) => (assert (pedir_pasaporte ?x))) ( (deffacts inicial (persona marcos) (persona pedro) (persona john) (perro tucky) (persona carlos) (madrileno marcos) (toledano pedro) (californiano john) (frances tucky) (parisino carlos) (persona Hong) (chino Hong) (persona Mika) ) Índice • Introducción a la representación del conocimiento – Ingeniería del conocimiento – Ontologías – Sistemas basados en reglas • Ontologías • Sistemas basados en reglas Ontologías (i) • Proporcionan características útiles para sistemas inteligentes – para la representación del conocimiento – para la ingeniería del conocimiento • Características – Vocabulario – Taxonomías – Lenguajes de representación – Compartir del conocimiento y reutilizarlo Ontologías (ii) • Ingeniería de Ontologías – Principios de diseño – Procesos y actividades para el desarrollo – Tecnologías de apoyo – Metodologías – Ciclo de vida • Diseño • Implementación • Evaluación • Validación • Mantenimiento • Despliegue • Asociación • Integración • Compartición • Reutilización Herramientas de desarrollo de ontologías (i) • Lenguajes de representación ... • Entornos gráficos para el desarrollo ... • Aprendizaje de ontologías ... Herramientas Ontologías. Lenguajes de representación (i) • Lenguajes de representación – Lenguajes de la comunidad de IA (principios de los 90) – Lenguajes pre-XML de expertos en IA de W3C (finales de los 90) – Lenguajes basados en XML → Lenguajes de la Web Semántica – Ejemplos: • • • • • • • • • • KIF (1992) Lógica de primer orden Ontolingua (1992) basado en KIF, incluye representación de marcos Loom (1991) descripciones lógicas SHOE (2000) extensión de HTML XOL (1999) desarrollado por SRI, basado en XML y estandarizado RDF (2004) desarrollado por W3C lenguaje semántico para la red para describir recursos web RDF-Schema (2004) Extensión de RDF con primitivas de marcos OIL (2001) descripción lógica con representación de marcos DAML+OIL (2002) (DARPA Agent Markup Language) + OIL OWL (2004) DAML+OIL estandarizado por W3C. Lenguaje de la web semántica • Entornos gráficos para el desarrollo ... • Aprendizaje de ontologías ... Herramientas Ontologías. Lenguajes de representación (ii) • Lenguajes de representación – ... – Idealmente un lenguaje universal para representar el conocimiento – Realidad: sistemas heterogéneos → combinación de ontologías • Gran esfuerzo para mantener coherencia entre lenguajes de representación de ontologías • Diferentes lenguajes → diferentes niveles de expresividad – Restricciones de los entornos gráficos de desarrollo • Entornos gráficos para el desarrollo ... • Aprendizaje de ontologías ... Herramientas Ontologías. Entornos gráficos (i) • Lenguajes de representación ... • Entornos gráficos para el desarrollo – Independientemente del lenguaje, usualmente se utilizan editores de ontologías • añadir: – conceptos – propiedades – relaciones – restricciones • además de – análisis sintáctico – análisis lógico – detección de errores semánticos – Otras herramientas • Conversión entre ontologías y lenguajes • Validadores de ontologías • Adquisición del conocimiento • ... • Aprendizaje de ontologías ... Herramientas Ontologías. Entornos gráficos (ii) • Lenguajes de representación ... • Entornos gráficos para el desarrollo – ... – Protégé (Universidad de Stanford) • Creación de: – – – – – • • Modelado del conocimiento e introducción de datos Múltiples lenguajes de representación de ontologías: – • Conceptos (clases) Propiedades Taxonomías Restricciones Instancias de clases (Datos) OWL, RDF(S), ... Posibilidad de añadir plug-in (dependientes de aplicación) – Agentes FIPA, OWL-S, Jess, UML, XML, ... • Exporta ontologías a múltiples formatos • – ... Texto, CLIPS, ... • Aprendizaje de ontologías ... Herramientas Ontologías. Entornos gráficos (iii) • Lenguajes de representación ... • Entornos gráficos para el desarrollo – ... – Protégé • Aprendizaje de ontologías ... Herramientas Ontologías. Aprendizaje de ontologías (i) • Lenguajes de representación ... • Entornos gráficos para el desarrollo ... • Aprendizaje de ontologías – El proceso más complicado en las ontologías • adquisición del conocimiento y mantenimiento – El conocimiento puede ser muy amplio y dinámico – Automatización en la creación de ontologías y su mantenimiento • • Extracción de nueva información partiendo de diversas fuentes – procesado automático de extracción de información – procesado de lenguaje natural Integración de antigua información con el nuevo conocimiento adquirido – • Anotaciones, comprobaciones de coherencia de ontologías y datos, etc. Ingeniería inversa sobre datos ya existentes – Ayuda de diccionarios, asociaciones con ontologías existentes – Redefinir ontologías ya existentes con nuevos datos – Todos los procesos son interactivos (requieren supervisión humana) – En investigación • Integración en entornos como Protégé Metodologías para la creación de ontologías (i) • Tres enfoques: – construcción de ontologías – mezcla, reingeniería, mantenimiento y evolución de ontologías – metodologías genéricas de construcción de software aplicadas a las ontologías • No hay una metodología “correcta” → dificultad para modelar cada dominio • Proceso interactivo de construcción: – Determinar dominio y ámbito de la ontología – Considerar la reutilización de una ontología existente • Evitar esfuerzo de crear de cero → interoperabilidad, uso de estándares, etc. • Utilizar herramientas para conversiones de lenguajes – Enumerar términos importantes de la ontología – Definir clases y sus jeraquías • top-down, bottom-up, middle-out – Definir propiedades de las clases (slots) – Definir las restricciones, dominios y rangos de las propiedades – Crear instancias Metodologías para la creación de ontologías (ii) • En la realidad es mucho más complicado – Definición del grano de detalle de la ontología – Llegar a un consenso sobre los aspectos “importantes” de un dominio • Más aspectos en las ontologías, paralelos – Determinar el ciclo de vida de la ontología • creación hasta alcanzar la calidad deseada • integración • evaluación • mantenimiento • documentación • configuración Más sobre ontologías (i) • Metadatos, metaontologías y ontologías o Metadatos → datos acerca de los datos (contenido, variabilidad y función) Descripción de los datos representados o Metaontologías → ontologías para construir ontologías Modelos para construir modelos • ¿En un proceso típico de ingeniería del software dónde está la ontología? o Típica estructura en tres niveles (datos, lógica y presentación) o Ontología → datos o Ontología → relación entre los datos y sus propiedades (lógica) o ¿Nivel de ontología? Ejercicio: diseñamos una ontología Modelamos www.imdb.com Dominio: cine Actores, directores, información de películas, productoras Usuarios, club de fans, noticias, anuncios ... RECOPILACIÓN DEL CONOCIMIENTO Índice • Introducción a la representación del conocimiento – Ingeniería del conocimiento – Ontologías – Sistemas basados en reglas • Ontologías • Sistemas basados en reglas Bases de conocimiento basadas en reglas DEFINICIÓN mecanismo de inferencia automática conjunto de sentencias en un LRC <BH,BR,MI> BASE DE HECHOS (Memoria de trabajo) Representa conocimientos sobre el problema:datos, hechos establecidos y metas a alcanzar BASE DE REGLAS Representa conocimientos sobre la solución del problema en forma de producciones MOTOR DE INFERENCIA Razona con el conocimiento del problema y sobre su solución Determina cómo se aplican las reglas Entornos software basados en reglas • CLIPS (C Language Integrated Production System): – herramienta para desarrollar sistemas inteligentes basadas en reglas – desarrollada en C/ANSI por Software Technology Branch, NASA/Lyndon B. Johnson Space Center desde 1986 – implementación eficiente del encadenamiento hacia delante • Facilidades adicionales – diferentes estrategias de resolución de conflictos – adición dinámica de reglas – sistema de mantenimiento de verdad – lenguaje orientado a objetos: COOL (Clips Object-Oriented Language) • Extensiones: – fácilmente integrable en aplicaciones en C, ADA, Python, Perl, FORTRAN, etc. – disponible en diversas plataformas (MS-DOS/Windows, Unix, MacOSX, BSD...) – extensiones para Lógica Borrosa (FuzzyCLIPS) – JESS: versión en Java que usa el sistemas de objetos correspondiente Bases de conocimiento basadas en reglas DEFINICIÓN mecanismo de inferencia automática conjunto de sentencias en un LRC <BH,BR,MI> BASE DE HECHOS (Memoria de trabajo) Representa conocimientos sobre el problema:datos, hechos establecidos y metas a alcanzar BASE DE REGLAS Representa conocimientos sobre la solución del problema en forma de producciones MOTOR DE INFERENCIA Razona con el conocimiento del problema y sobre su solución Determina cómo se aplican las reglas CLIPS: Base de Hechos (i) • Terminología – La Base de Hechos en CLIPS se llama memoria de trabajo (MT) – puede contener diferentes tipos de hechos • Hechos ordenados (“ordered facts”) – Patrones con uno o varios campos • la posición de la información en el hecho es relevante • información tipada: símbolos, integers, real, strings, etc. • sintaxis acostumbrada – Ejemplos: (hola) (alumnos Pepe Juan Luis) (nombre “Juan”) (edad 14) (pi 3.1415) CLIPS: Base de Hechos (ii) • Patrones no ordenados (deftemplate) – Permiten definir información en forma de clases de elementos y atributos de esas clases – Permiten abstraer la estructura de un hecho asignando un nombre a cada campo • campos slot: pueden tener exactamente un valor • campos multislot: pueden tener varios valores (de varios tipos) – Se permite una cadena de caracteres como comentario (opcional) – Ejemplo: (deftemplate clase “Informacion sobre clases” (slot grupo) (slot aula) (slot hora) (multislot alumnos) (multislot profesor)) CLIPS: Base de Hechos (iii) • Hechos no ordenados (“unordered facts”, “deftemplate facts”) – hechos que “instancian” los patrones deftemplate – el primer nombre del hechos no ordenado referencia su deftemplate – el orden de los campos no tiene importancia – se pueden omotir slots del patrón deftemplate – Ejemplo: (clase (aula “II-002”) (profesor Fulanito) (alumnos)) (clase (grupo “IA-3”) (aula “II-001”) (hora 17) (profesor Ramon)) CLIPS: Base de Hechos (iv) • Hechos iniciales: – los hechos iniciales, se definen con la estructura deffacts • ejemplo 1: • ejemplo 2: (deffacts hechos-600 “informacion del 600” (modelo 600) (puertas 2) ) (deffacts OtrosHechos (cliente (nombre Juan Pérez) (id 33435)) (cliente (nombre Rosa Gómez) (id 33436)) ) – por defecto existe el hecho inicial (initial-fact) – los hechos iniciales se añadirán a la Memoria de Trabajo al ejecutar (reset) CLIPS: Base de Hechos (v) • Índices de hechos (etiquetas temporales, time-tags) – CLIPS genera para cada hechos un índice relativo al tiempo de su creación: • Al primer hecho creado le corresponde la etiqueta temporal 0: f-0 (initial-fact) • Ejemplo: Si (ladra perro) es el segundo hecho añadido a la MT, su etiqueta temporal será f-2 • Nunca disminuye y nunca se reasigna. Para cada nuevo hecho que se cree o modifique se incrementa en uno – Sirven para • Identificar de forma única y simplificada cada hecho • Saber el tiempo que lleva un hecho en la memoria de trabajo CLIPS: Base de Hechos (vi) • Órdenes básicas de manejo de la MT – (facts) Lista los hechos de la Memoria de Trabajo – (assert <hecho>) Añade un hechos a la Memoria de Trabajo – (retract <indice-hecho>) Elimina un hecho de la MT – (clear) Elimina todos los hechos y construcciones de la MT – (reset) - Elimina todos los hechos de la MT, elimina las activaciones de reglas y restaura las condiciones iniciales - Añade initial-fact e initial-object - Añade el conocimiento inicial definido con deffacts y definstances - Añade las variables globales con su valor inicial - Fija como módulo principal el módulo MAIN CLIPS: Base de Hechos (vii). Ejemplos CLIPS> (reset) CLIPS> (retract 1) CLIPS> (facts) CLIPS> (assert (hola)) f-0 (initial fact) <Fact-2> For a total of 1 fact. CLIPS> (facts) CLIPS> (assert (hola)) f-0 (initial-fact) <Fact-1> f-2 hola CLIPS> (facts) For a total of 2 facts. f-0 (initial-fact) CLIPS> (clear) f-1 hola CLIPS> (facts) For a total of 2 facts. CLIPS> Bases de conocimiento basadas en reglas DEFINICIÓN mecanismo de inferencia automática conjunto de sentencias en un LRC <BH,BR,MI> BASE DE HECHOS (Memoria de trabajo) Representa conocimientos sobre el problema:datos, hechos establecidos y metas a alcanzar BASE DE REGLAS Representa conocimientos sobre la solución del problema en forma de producciones MOTOR DE INFERENCIA Razona con el conocimiento del problema y sobre su solución Determina cómo se aplican las reglas CLIPS: Base de Reglas (i) • Sintaxis • Ejemplo (defrule marca-del-600 (defrule <nombre_regla> [<documentacion opcional>] "Marca del modelo 600" [<caracteristicas op.>] (premisa 1) (modelo 600) (premisa 2) ... => (premisa N) (assert (marca-es SEAT)) => ) (accion 1) (accion 2) • Semántica ... – Si “se cumplen” todas las (accion M) premisas ) – Se ejecutan todas las acciones CLIPS: Base de Reglas (ii) Premisas • Elementos de las premisas – Patrones • existencia / ausencia de los hechos en la Base de Hechos • pueden “instanciar” variables a partir de hechos – Restricciones • restricciones como premisas (tipo test) • restricciones de variables (conectivas) CLIPS: Base de Reglas (iii) Premisas, patrones constantes • Patrones: Constantes – equiparación con hechos concretos de la Memoria de Trabajo – Ejemplos: (defrule encontrar-dato (dato 1 azul rojo) =>) (defrule encontrar-Roberto (persona (nombre Roberto) (edad 20)) =>) CLIPS: Base de Reglas (iv) Premisas, patrones constantes • Equiparación de patrones constantes – Caso A: Hechos ordenados BR MT (defrule R1 (A B) => (assert (C D)) ) 1 equiparación Conjunto Conflicto = {R1(f-1)} La ejecución de la regla introduce en la MT a (C D) f-1 (A B) f-2 (C D) – Caso B: Hechos no ordenados BR MT (defrule R1 (clase1 (nombre1 A)) => (assert (C D)) ) f-1 (clase1 (nombre1 A)) f-2 (C D) 1 equiparación Conjunto Conflicto = {R1(f-1)} La ejecución de la regla introduce en la MT a (C D) CLIPS: Base de Reglas (v) Premisas, patrones comodines • Patrones comodines – patrones genéricos que equiparan con diferentes hechos – se usan cuando no importa el valor de un campo • • ?: Equipara con un campo $?: Equipara con cero a n campos • Ejemplos: (defrule encontrar-dato (dato ? azul rojo $?)=> ) (defrule encontrar-dato (dato $? amarillo $?)=> ) CLIPS: Base de Reglas (vi) Premisas, patrones comodines • Equiparación con comodines – cada par hecho-comodín puede dar lugar a una instanciación – Ejemplo: BR MT (defrule R1 (A $? B) =>... ) f-1 (A B) f-2 (A 3 B) f-3 (A C E D B) 3 equiparaciones de la misma regla Eq1: $? = Eq2: $? = 3 Eq3: $? = C E D Conjunto Conflicto = {R1(f-1), R1(f-2), R1(f-3)} – Un comodín repetido puede tener valores diferentes CLIPS: Base de Reglas (vii) Premisas, patrones variables • Patrones: Variables – patrones genéricos que equiparan con diferentes hechos – almacenan valores de campos para usarlos posteriormente • • ?x: variable de único $?x: variable multivalor (cero, uno o más valores) • Ejemplos: (defrule encontrar-dato (dato ?x ?y ?z)=> ) (defrule encontrar-dato (dato ?x $?y ?z)=> ) CLIPS: Base de Reglas (viii) Premisas, patrones variables • Equiparación con variables – Una variable que aparece dos o más o veces en la regla debe equipararse en todas las ocurrencias con el mismo valor BR (defrule R1 (animal ?x) (piel pelo ?x) => (especie mamifero ?x) ) MT f-1 f-2 f-3 f-4 f-5 (animal Tucky) (piel pelo Dolly) (piel pelo Tucky) (animal Dolly) (animal Dumbo) Eq1: ?x = Tucky : (animal Tucky) (piel pelo Tucky) Eq2: ?x = Dolly : (animal Dolly) (piel pelo Dolly) Dumbo no equipara por no tener (piel pelo Dumbo) en la MT Conjunto Conflicto = { R1(f-1, f-3), R1(f-2,f-4) } CLIPS: Base de Reglas (ix) Premisas, ausencia de patrones • Patrones: Ausencia de patrones – Sintaxis: (not (<patron>)) – La premisa se cumple, si no hay ningún hecho en la MT que equipara con <patron> – Ejemplo: (defrule volar (pajaro ?x) (not (avestruz ?x)) => (assert (vuela ?x)) ) – Hipótesis del mundo cerrado: • todo lo que no se encuentra en la MT es “falso” CLIPS: Base de Reglas (x) Premisas, ausencia de patrones • Equiparación basada en la ausencia de patrones – Ejemplo: BR (defrule R1 (A ?x) (not (B ?x)) => ) MT f-1 f-2 f-3 f-4 f-5 Eq1: ?x = C Eq2: ?x = B Eq3: ?x = A ?x = A no equipara porque en la MT está (B A) (A (B (A (A (B C) D) B) A) A) CLIPS: Base de Reglas (xi) Premisas, direcciones de hechos • Patrones: direcciones de hechos (referencia a la MT): – se puede almacenar referencias a los hechos de la MT en variables – dichas referencias pueden ser usadas en las acciones de consecuentes – Ejemplo (defrule matrimonio ?ref-soltero <- (soltero ?nombre) => (retract ?ref-soltero) (assert (casado ?nombre)) ) CLIPS: Base de Reglas (xii) Premisas, restricciones • Restricciones de premisa: – premisa del tipo (test (<expresión booleana>)) – forma más general para comprobar el cumplimiento de una condición – Expresiones booleanas se construyen en notación prefija sobre: • Funciones de comparación – Numérica: =, <>, <, >, >=, <= – Cualquier tipo: eq, neq • • Funciones lógicas: or, not, and Funciones de predicado: stringp, numberp, symbolp ... – Ejemplo: (defrule mes-valido (entrada ?mes) (test (and (>= ?mes 1) (<= ?mes 12) ) ) =>) CLIPS: Base de Reglas (xiii) Premisas, restricciones conectivas • Restricciones conectivas (connective constraints): – limitan la posibilidad de equiparación de variables – restricciones conectivas con constantes: • Sintaxis: ?x&~<valor> • Semántica: ?x equipara con cualquier valor menos <valor> • Ejemplos: (defrule no-rojo-ni-verde (color ?x&~rojo&~verde) =>) (defrule no-rojo-ni-verde-test (color ?x) (test (neq ?x rojo verde)) =>) (defrule datos-distintos (dato ?x ?y&~?x) =>) (defrule datos-distintos-test (dato ?x ?y) (test (neq ?x ?y)) =>) CLIPS: Base de Reglas (xiv) Premisas, restricciones conectivas • Restricciones conectivas de resultado (return value constraints) – Sintaxis ?x&=(<expresion>) – Semántica: • • ?x equipara sólo con el valor que resulta de evaluar <expresion> <expresion> puede ser de cualquier tipo (i.e. se aplica eq) – Ejemplos (defrule mas-una (dato ?x ?y&=(+ ?x 1)) =>) (defrule mas-una-test (dato ?x ?y) (test (= ?y (+ ?x 1))) =>) (defrule segundo-elemento (lista $?l) (valor ?x&=(nth$ 2 $?l)) =>) (defrule segundo-elemento-test (lista $?l) (valor ?x) (test (eq ?x (nth$ 2 $?l))) =>) CLIPS: Base de Reglas (xv) Premisas, restricciones conectivas • Restricciones conectivas de predicado (predicate constraints) – Sintaxis: ?x&:(<expr.booleanas>) – Semántica: • • ?x equipara con cualquier valor si sólo si <expr.booleana> es true <expr.booleana> también suele contener las variables – Ejemplos: (defrule valor-numerico (valor ?x&:(numberp ?x)) =>) (defrule valor-numerico-test (valor ?x) (test (numberp ?x)) =>) (defrule dos-o-mas (lista $?y&:(> (length$ ?y) 2)) =>) (defrule dos-o-mas-test (lista $?y) (test (> (length$ ?y) 2)) =>) CLIPS: Base de Reglas (xvi) Acciones de las reglas • Modificar MT: assert, retract, modify, duplicate (modify|duplicate <índice-hecho> <casilla-a-modificar>+) • donde <índice-hecho> ::= número entero no negativo (el índice del hecho a modificar) <casilla-a-modificar> ::= (<nombre-casilla> <valor-de-la-casilla>) <nombre-casilla> ::= nombre que se le asignó a una casilla al usar el constructor deftemplate <valor-de-la-casilla> ::= el nuevo valor que se le asigna a la casilla. • modify vs. duplicate modify borra el hecho anterior que modifica y crea otro nuevo duplicate funciona como modify pero sin borrar el hecho anterior NO pueden usarse con hecho ordenados CLIPS: Base de Reglas (xvii) Acciones de las reglas • Parada del proceso de inferencia: halt • Asignar valores a variables (en el consecuente): bind • Ejemplo: (defrule coste-del-envio (envio ?paquete ?origen ?destino) (dia-entrega ?paquete hoy) ?coste-inicial<-(coste ?paquete ?precio) => (retract ?coste-inicial) (bind ?suplemento (read)) (bind ?nuevo-precio (+ ?precio ?suplemento)) (assert (coste-final ?paquete ?nuevo-precio)) (printout t "Coste final es " ?nuevo-precio crlf) (halt) ) • Entrada/Salida: printout, read, readline, open, close CLIPS: Base de Reglas (xvii) Funciones predefinidas Funciones de predicado • • • • • • • • • • • • • numberp floatp integerp lexmep stringp symbolp evenp oddp multifiedp eq neq =, <>, >, >=, <, <= or, not, and Funciones campos multislot Funciones matemáticas • • • • • • • • • • • • • • • • • create$ nth$ member$ subsetp delete$ explode$ implode$ subseq$ replace$ insert$ first$ rest$ +, -, *, /, div max, min abs float integer Se pueden definir más funciones al estilo con deffunction (ver manual) Ejercicio Suponga que se han definido los siguientes elementos: (COLOR ?c ?cc) Para representar los colores de las fichas con las que juega el ordenador y el contrario Para representar que el turno lo tienen las fichas rojas si ?t toma el valor R, o bien B si el turno lo tienen las fichas blancas En la MT se tienen (COLOR R B) y (TURNO R) (TURNO ?t) Se desea representar que el ordenador sólo puede mover cuando es su turno ¿Cuál de las siguientes representaciones son correctas? A) (COLOR ?c ?cc) (TURNO ?t) (test(eq ?c ?t)) B) (COLOR ?c ?cc) (TURNO ?c) C) (COLOR ?c ?cc) (not(TURNO ?cc)) Ejercicio Escriba una regla de las siguientes características: • se activa con hechos del tipo (valor a b), siempre que a sea el doble de b • en este caso se escribe el valor de a y b en pantalla ¿Cuantas formas diferentes hay para definir reglas de este tipo en CLIPS? Ejercicio ¿Cuántas instancias de la regla R hay en el conjunto conflicto? Bases de conocimiento basadas en reglas DEFINICIÓN mecanismo de inferencia automática conjunto de sentencias en un LRC <BH,BR,MI> BASE DE HECHOS (Memoria de trabajo) Representa conocimientos sobre el problema:datos, hechos establecidos y metas a alcanzar BASE DE REGLAS Representa conocimientos sobre la solución del problema en forma de producciones MOTOR DE INFERENCIA Razona con el conocimiento del problema y sobre su solución Determina cómo se aplican las reglas CLIPS: Motor de inferencia (i) • Algoritmo de selección de reglas aplicables en CLIPS – elegir la regla aplicable con máxima prioridad – elegir la regla según estrategia de resolución de conflictos – elegir de forma arbitraria • Definir prioridades en CLIPS – asignar un valor de prioridad (entero positivo) a cada regla – se definen como propiedades de reglas (defrule marca-del-600 "Marca del modelo 600" (declare (salience 10)) (modelo 600) => (assert (marca-es SEAT)) ) – recomendación: minimizar el uso de prioridades de reglas CLIPS: Motor de inferencia (ii) Estrategias de resolución de CC • Estrategias de resolución de conflictos (i) – Depth Strategy (estrategia por defecto) • Una activación que contiene el hecho más reciente se sitúa por encima de las activaciones con igual o mayor antigüedad – Breadth Strategy • Una activación que contiene el hecho más reciente se sitúa por debajo de las activaciones con igual o mayor antigüedad – Complexity Strategy • Las nuevas activaciones se sitúan por encima de las activaciones con igual o menor especificidad (nº de comparaciones que han de realizarse en el antecedente una la regla) – Simplicity Strategy • Las nuevas activaciones se sitúan por debajo de las activaciones con igual o mayor especificidad CLIPS: Motor de inferencia (ii) Estrategias de resolución de CC • Estrategias de resolución de conflictos (II): – LEX Strategy • Se ordenan los time-tag en orden decreciente y se comparan uno a uno, hasta encontrar uno mayor que otro • En caso de que no haya el mismo número de time-tag se añaden ceros al final • Ejemplo: – Conjunto Conflicto= {R1(f-4), R2(f-2,f-4)} – Para R1: 4, 0 / para R2: 4, 2 / por tanto LEX elige R2 – MEA Strategy • Parecido a LEX, pero mirando sólo el primer patrón que equipara en la regla – Random Strategy • A cada activación se le asigna un número aleatorio para determinar su orden en la agenda. Módulos CLIPS Módulos: • Permiten estructurar la Base de Conocimiento (tanto hechos como reglas) • Permiten también estructurar la inferencia en CLIPS (al definir varias agendas separadas) Sintaxis: • (defmodule <nombre_modulo> [<documentacion_opcional>] [(<especificacion_puerto_1)] [(<especificacion_puerto_2)] ... [(<especificacion_puerto_N)] ) (defmodule MAIN (export ?ALL) ) (deftemplate tp (slot x)) (defglobal ?*max* = 1) (defmodule "modulo (import (import (export A con nombre A" MAIN deftemplate tp) MAIN defglobal max) deftemplate ?ALL) ) (deftemplate atp (slot y)) ... Módulos CLIPS Pertenencia de construcciones a módulos: • Cualquier construcción CLIPS (tanto definiciones como sus instancias) pertenece a un módulo • El uso de un identificador de módulo determina inequívocamente el módulo al que pertenece una definición (defmodule A) (defrule MAIN::r1 =>) Identificadores de módulo (deftemplate A::t1 (slot s1)) (defrule A::r1 (t1 (s1 x)) =>) (deffacts MAIN::inicial (hecho no ordenado 1)) • Si se omite (¡no recomendado!), la definición se refiere al modulo actual (el de la última declaración defmodule). El módulo actual por defecto es MAIN – 94 – Inteligencia Artificial 3º I.T. Inf. Sistemas SO: 2006/2007 Módulos CLIPS Especificaciones de puertos: • Permiten que un módulo pueda “ver” las definiciones de otro • Ejemplo de especificaciones de exportación (p.e. en los módulos MAIN y/o A): • Ejemplo de especificaciones de importación (p.e. en el módulo B): • • (export ?ALL) (export deftemplate ?ALL) (export defglobal max) (import MAIN ?ALL) (import A deftemplate ?ALL) (import MAIN defglobal max) Cualquier definición importada por un módulo ha de ser exportado por otro La relación de importación/exportación es jerárquica: si el módulo B importa algunas definiciones de A, no se permite que A importe otras definiciones de B Visibilidad y Pertenencia en Módulos CLIPS Reglas de Visibilidad y Pertenencia: • cualquier definición CLIPS (deftemplate, defrule, etc) es visible en el módulo que lo define, y en todos los módulos que la importan • las instancias de las definiciones (y, en particular, los hechos) tienen la misma visibilidad que éstas últimas • las instancias de las definiciones pertenecen al módulo que las defina, no al que crea la instancia (esto asegura la “consistencia” entre módulos) • ¡OJO con la interfaz gráfica de CLIPS 6.2! : • La ventana “facts” siempre muestra los hechos de todos los módulos, independiente del nombre de módulo que aparece en la cabecera de la ventana • Para comprobar los hechos visibles en un módulo, usar el comando (facts <modulo>) Visibilidad y Pertenencia en Módulos CLIPS: Ejemplo (defmodule MAIN ) (export deftemplate ctrl) (export defglobal max) (deftemplate MAIN::ctrl (slot d)) (defglobal MAIN ?*max* = 1) (defmodule A (import MAIN defglobal max) (import MAIN deftemplate ctrl) ) (defrule A::r1 ?d <- (MAIN::ctrl (d ?d-val&:(> ?d-val ?*max*))) => (printout t "valor d es mayor que max") (retract ?d) ) Inferencia en BC CLIPS Estructurados • Cada módulo tiene su propio Motor de Inferencia local: • La Base de Hechos/Reglas de un módulo la constituyen los hechos/reglas visibles en dicho módulo la Agenda de un módulo (Conjunto Conflicto) se calcula a partir de los hechos/reglas visibles en dicho módulo • la selección de una regla aplicable en un módulo (resolución del Conjunto Conflicto) se realiza sólo en base a la agenda de dicho módulo • el efecto de disparar una regla puede afectar a otros módulos (¡una construcción pertenece al módulo que lo define, no él que lo crea o destruye!) • • • La estrategia de control es la misma para todos los módulos Módulo enfocado: • En cada instante sólo es activo un Motor de Inferencia local, el del módulo enfocado (e.d. sólo se elige entre las activaciones de este módulo) • al iniciar la inferencia, el módulo enfocado es MAIN Inferencia en BC CLIPS Estructurados Pila de enfoque (focus stack): • El módulo enfocado siempre está en la cabeza de la pila de enfoque • Se añade el módulo M a la pila de enfoque si: • en el módulo enfocado se ejecuta una regla cuyo consecuente contiene el comando (focus M) • Una regla perteneciente al módulo M tiene la propiedad asociada (auto-focus TRUE), y la ejecución de una regla del módulo enfocado afecta a la BH del modulo M, tal que esta regla entra en la agenda local de dicho módulo • Se elimina un módulo de la pila de enfoque si su agenda está vacía (e.d. cuando ya no hay más activaciones de reglas en dicho módulo) • Al iniciar la inferencia, la pila de enfoque sólo contiene el módulo MAIN Inferencia con módulos CLIPS: Ejemplo Ejemplo: completar automáticamente slots de hechos ordenados • Módulo MAIN: se lean sucesivamente valores n para hechos expresion • Módulo EVALUAR: se calcula el resultado de la expresión para n (defmodule MAIN (export deftemplate expresion) ) (deftemplate MAIN::expresion (slot valor-n) (multislot resultado (default n n + 2 n + -)) ) (defrule MAIN::bucle-leer-valor-n (expresion) => (printout t "valor n: ") (bind ?n (read)) (assert (expresion (valor-n ?n))) ) (deffacts MAIN::valor-inicial (expresion (valor-n 1)) ) Módulos en CLIPS: Ejemplo (defmodule EVALUAR (import MAIN deftemplate expresion) ) (defrule EVALUAR::instanciar-variables (declare (auto-focus TRUE)) ?p <- (expresion (valor-n ?valor-n) (resultado $?izq n $?drcha)) => (modify ?p (resultado $?izq ?valor-n $?drcha)) ) (defrule EVALUAR::restar (declare (auto-focus TRUE)) ?p <- (expresion (resultado $?izq ?a ?b - $?drcha)) (test (numberp ?a)) (test (numberp ?b)) => (modify ?p (resultado $?izq (- ?a ?b) $?drcha)) ) (defrule EVALUAR::sumar (declare (auto-focus TRUE)) ?p <- (expresion(resultado $?izq ?a ?b + $?drcha)) (test (numberp ?a)) (test (numberp ?b)) => (modify ?p (resultado $?izq (+ ?a ?b) $?drcha)) ) Diseño de Bases de Conocimiento (i) Proceso (habitual) 1. Definir el modelo – conceptualizar el mundo: ¿qué es importante? – p.e.: bloques, mesas, posición vertical relativa de los bloques ... 2. Definir la ontología – Escoger el vocabulario – p.e. block1, clear, on, encima ... – (deftemplates ... 3. Definir conocimiento del dominio – Codificar el conocimiento general sobre el dominio – p.e.: (defrule R (on ?x ?y) => (assert (encima ?x ?y))) 4. Definir el conocimiento del caso – Codificar una descripción del caso específico (p.e.: estado actual) – p.e.: (deffacts ((On A B) (On B T))) 5. Hacer consultas Diseño de Bases de Conocimiento (ii) Ejemplo (i) • Construir una Base de Conocimiento lógica que permita contestar preguntas acerca del comportamiento del siguiente circuito 1 2 xor1 xor2 3 1 and2 and1 or1 2 Diseño de Bases de Conocimiento (iii) Ejemplo (ii) 1. Definir el modelo: – características relevantes • circuitos, puertas binarias, tipos de puertas binarias (and, or, xor), terminales de puertas/ circuitos, conexiones entre terminales, señales, señales en las terminales, ... – características irrelevantes • rutas de las líneas, posición de las puertas, tamaño de las puertas etc. 2. Definir la ontología: – Puertas: patrón ordenado puerta • Identificación puerta: slot id-puerta • Tipo de puertas: slot tipo • Terminales: slots id-entrada-1, id-entrada-2, id-salida – Circuito: patrón circuito • Identificación circuito: slot id-circuito • Terminales: multislots id-entradas, id-salidas – Conexiones entre terminales: patrón no-ordenado conexión – Señales: valores booleanos TRUE y FALSE – Señales en las terminales: patrón ordenado estado-terminal Diseño de Bases de Conocimiento (iv) Ejemplo (iii) • Declaración parcial de la ontología (patrones no-ordenados) (deftemplate puerta "Puertas logicas binarias" (slot id-puerta) (slot tipo (allowed-symbols (slot id-entrada-1 (default (slot id-entrada-2 (default (slot id-salida-1 (default AND OR XOR)) e1)) e2)) s1)) ) (deftemplate circuito "Circuito con multiples entradas y salidas" (slot id-circuito) (multislot id-entradas) (multislot id-salidas ) ) (deftemplate estado-terminal "Senyal en terminales de una puerta o circuito" (slot id-elemento) (slot id-terminal) (slot senyal (allowed-symbols TRUE FALSE)) ) Diseño de Bases de Conocimiento (v) Ejemplo (iv) • Conocimiento del dominio: comportamiento de una puerta AND (defrule logica-AND (puerta (id-puerta ?p) (tipo AND) (id-entrada-1 ?e1) (id-entrada-2 ?e2) (id-salida-1 ?s1) ) (estado-terminal (id-elemento ?p) (id-terminal ?e1) (senyal ?senyal-e1) ) (estado-terminal (id-elemento ?p) (id-terminal ?e2) (senyal ?senyal-e2) ) => (assert (estado-terminal (id-elemento ?p) (id-terminal ?s1) (senyal (and ?senyal-e1 ?senyal-e2)) ) ) ) Diseño de Bases de Conocimiento (vi) Ejemplo (v) • Conocimiento del dominio: comportamiento de una puerta OR (defrule logica-OR (puerta (id-puerta ?p) (tipo OR) (id-entrada-1 ?e1) (id-entrada-2 ?e2) (id-salida-1 ?s1) ) (estado-terminal (id-elemento ?p) (id-terminal ?e1) (senyal ?senyal-e1) ) (estado-terminal (id-elemento ?p) (id-terminal ?e2) (senyal ?senyal-e2) ) => (assert (estado-terminal (id-elemento ?p) (id-terminal ?s1) (senyal (or ?senyal-e1 ?senyal-e2)) ) ) ) Diseño de Bases de Conocimiento (vii) Ejemplo (vi) • Conocimiento del dominio: comportamiento de una puerta XOR (defrule logica-XOR (puerta (id-puerta ?p) (tipo XOR) (id-entrada-1 ?e1) (id-entrada-2 ?e2) (id-salida-1 ?s1) ) (estado-terminal (id-elemento ?p) (id-terminal ?e1) (senyal ?senyal-e1) ) (estado-terminal (id-elemento ?p) (id-terminal ?e2) (senyal ?senyal-e2) ) => (assert (estado-terminal (id-elemento ?p) (id-terminal ?s1) (senyal (not (eq ?senyal-e1 ?senyal-e2))) ) ) ) Diseño de Bases de Conocimiento (viii) Ejemplo (vii) • Conocimiento del dominio: regla para propagar señales por conexiones (defrule logica-conexion "Si dos terminales estan conectados, entonces tienen la misma senyal" (estado-terminal (id-elemento ?elemento-A) (id-terminal ?terminal-A) (senyal ?senyal)) (conexion ?elemento-A ?terminal-A ?elemento-B ?terminal-B) => (assert (estado-terminal (id-elemento ?elemento-B) (id-terminal ?terminal-B) (senyal ?senyal)))) Diseño de Bases de Conocimiento (ix) Ejemplo (viii) • Conocimiento del caso: hechos iniciales para definir los elementos de un circuito concreto (deffacts lista-de-elementos (circuito (id-circuito C) (id-entradas e1 e2 e3) (id-salidas s1 s2) ) (puerta (id-puerta X1) (tipo XOR)) (puerta (id-puerta X2) (tipo XOR)) (puerta (id-puerta A1) (tipo AND)) (puerta (id-puerta A2) (tipo AND)) (puerta (id-puerta O1) (tipo OR )) ) Diseño de Bases de Conocimiento (x) Ejemplo (ix) • Conocimiento del caso: conexiones concretas entre elementos (deffacts (conexion (conexion (conexion (conexion (conexion (conexion (conexion (conexion (conexion (conexion (conexion (conexion lista-de-conexiones C e1 X1 e1) C e1 A1 e1) C e2 X1 e2) C e2 A1 e2) C e3 A2 e1) C e3 X2 e2) X1 s1 X2 e1) X1 s1 A2 e2) A1 s1 O1 e2) A2 s1 O1 e1) X2 s1 C s1) O1 s1 C s2) ) • Regla para completar conexiones (defrule conexion "La conexion es conmutativa" (conexion ?p1 ?t1 ?p2 ?t2) => (assert (conexion ?p2 ?t2 ?p1 ?t1))) Diseño de Bases de Conocimiento (xi) Ejemplo (x) • Conocimiento del caso: leer señales iniciales en las entradas (defrule leer-entradas (circuito (id-circuito ?c) (id-entradas $? ?t $?)) => (printout t "Circuito: " ?c " Entrada: " ?t " Senyal: " ) (bind ?senyal (read)) (assert (estado-terminal (id-elemento ?c) (id-terminal ?t) (senyal ?senyal)) ) ) Diseño de Bases de Conocimiento (xii) Ejemplo (xi) • Conocimiento del caso: escribir señales deducidas en las salidas (defrule imprimir-salidas (estado-terminal (id-elemento ?c) (id-terminal ?t) (senyal ?senyal)) (circuito (id-circuito ?c) (id-salidas $? ?t $?)) => (printout t "Circuito: " ?c " Salida: " ?t " Senyal: " ?senyal crlf) ) Diseño de Bases de Conocimiento (xiii) Ejemplo (xii) • Realizar consultas – Consulta a la Base de Hechos CLIPS> (reset) CLIPS> (run) Circuito: C Entrada: e1 Circuito: C Entrada: e2 Circuito: C Entrada: e3 Senyal: TRUE Senyal: TRUE Senyal: FALSE – Respuesta: Circuito: C Circuito: C Salida: 11 Entrada: e2 Senyal: FALSE Senyal: TRUE Modelado de acciones (i) • Para modelar la función expandir: – un estado se caracteriza por un hecho en la memoria de trabajo – reglas modelan acciones: • el antecedente representa las pre-condiciones • el consecuente modela el resultado de la acción – al disparar todas las reglas activadas por un estado, se obtienen los estados sucesores • Implementación 1 (destructiva): – la regla borra el estado que la activaba y sólo deja el estado actual en la memoria de trabajo – Problema: • no queda traza de los estados visitados • al no mantener los estados hermanos en la Memoria de Trabajo no se pude dar marcha atrás Modelado de acciones (ii) • Implementación 2: – se mantienen todos los estados en la memoria (“árbol de búsqueda”) – las reglas aplicables en cada momento se encuentran en la agenda (conjunto conflicto) – completo con estrategia “breadth” (amplitud) • Ejemplo: – dos jarras, con una capacidad de 3 litros (llamada Tres) y 4 litros (llamada Cuatro) – inicialmente Tres y Cuatro están vacías y se intenta que haya 2 litros de agua en Cuatro – cualquiera de ellas puede llenarse con el agua de un grifo G – el contenido tanto de Tres como de Cuatro puede vaciarse en una pila P – es posible echar todo el agua de una jarra a la otra, pero no se dispone de dispositivos de medición adicionales Modelado de acciones (iii) • Llenar jarras del grifo (defrule llenar-cuatro-del-grifo ?nodo <- (situacion (litros-en-cuatro ?cuatro) (litros-en-tres ?tres) ) (test (< ?cuatro 4)) => (assert (situacion (padre ?nodo) (litros-en-cuatro 4) (litros-en-tres ?tres))) ) (defrule llenar-tres-del-grifo ?nodo <- (situacion (litros-en-cuatro ?cuatro) (litros-en-tres ?tres) ) (test (< ?tres 3)) => (duplicate ?nodo (padre ?nodo) (litros-en-tres 3)) ) Modelado de acciones (iv) • Vaciar jarras en la pila (defrule vaciar-cuatro-en-pila ?nodo <- (situacion (litros-en-cuatro ?cuatro) ) (test (> ?cuatro 0)) => (duplicate ?nodo (padre ?nodo) (litros-en-cuatro 0)) ) (defrule vaciar-tres-en-pila ?nodo <- (situacion (litros-en-tres ?tres) ) (test (> ?tres 0)) => (duplicate ?nodo (padre ?nodo) (litros-en-tres 0)) ) Modelado de acciones (v) • Llenar una jarra de la otra (defrule llenar-cuatro-desde-tres ?nodo <- (situacion (litros-en-cuatro ?cuatro) (litros-en-tres ?tres) ) (test (> (+ ?cuatro ?tres) 4)) (test (> ?tres 0)) (test (< ?cuatro 4)) => (assert (situacion (padre ?nodo) (litros-en-cuatro 4) (litros-en-tres (- ?tres (- 4 ?cuatro)))))) Modelado de acciones (vi) • Llenar una jarra de la otra (defrule llenar-tres-desde-cuatro ?nodo <- (situacion (litros-en-cuatro ?cuatro) (litros-en-tres ?tres) ) (test (> (+ ?cuatro ?tres) 3)) (test (> ?cuatro 0)) (test (< ?tres 3)) => (bind ?nuevo-cuatro (- ?cuatro (- 3 ?tres))) (assert (situacion (padre ?nodo) (litros-en-cuatro ?nuevo-cuatro) (litros-en-tres 3))) ) Modelado de acciones (vii) • Vaciar una jarra en la otra: (defrule vaciar-tres-en-cuatro ?nodo <- (situacion (litros-en-cuatro ?cuatro) (litros-en-tres ?tres) ) (test (<= (+ ?cuatro ?tres) 4)) (test (> ?tres 0)) => (assert (situacion (padre ?nodo) (litros-en-cuatro (+ ?tres ?cuatro)) (litros-en-tres 0)) ) ) (defrule vaciar-cuatro-en-tres ?nodo <- (situacion (litros-en-cuatro ?cuatro) (litros-en-tres ?tres) ) (test (<= (+ ?cuatro ?tres) 3)) (test (> ?cuatro 0)) => (assert (situacion (padre ?nodo) (litros-en-cuatro 0) (litros-en-tres (+ ?tres ?cuatro)) ) ) ) Modelado de acciones (viii): Ejercicio • Representación de acciones con reglas: Aunque el número de estados para el problema de las jarras es relativamente pequeño, existen muchos ciclos, por lo que se genera un árbol de búsqueda bastante grande… • ¿Cómo se podrían modificar las reglas para evitar ciclos simples? • ¿Cómo se podrían modificar las reglas para evitar todos los ciclos simples? Modelado de cambios • ¿Cómo representar las acciones en el mundo de los bloques? A C A B B C A B C B A C • Problema: – estados parcialmente caracterizados • sólo algunas propiedades del estado son relevantes • no se puede definir de antemano un deftemplate para estados – Solución • hechos ordenados: asignar un nombre a cada estado y añadirlo como argumento a cada propiedad • p.e.: (on C A S0), (on A T S0), (on B T S0), (clear C S0) Modelado de cambios: Axiomas de efecto • Reglas de efecto: – describir qué propiedades son relevantes para una acción • el antecedente describe las precondiciones para que se pueda realizar la acción • la implicación describe las nuevas propiedades (las que no se cumplen en el estado actual S1, pero sí en el estado resultante S2 (defrule efecto-move (clear ?x ?s1) (clear ?z&~?x ?s1) (on ?x ?y&~?z ?s1) => (bind ?s2 (gensym*)) (assert (on ?x ?z ?s2)) (assert (clear ?y ?s2)) (assert (clear T ?s2)) (assert (move ?s1 ?s2 ?x ?y ?z)) ) Modelado de cambios: Axiomas de marco (i) • Reglas de marco: – Problema: las acciones sólo cambian algunas de las propiedades • la mayoría de las propiedades no son afectadas por una acción • de momento, después de poner C de A sobre T en el estado s0, no se puede deducir que se cumple (on A T S1) • – Solución: • describir qué propiedades no cambian con una acción – Reglas de marco: • • reglas que indican qué propiedades no cambian aquí: una regla de marco para cada par propiedad / acción Modelado de cambios: Axiomas de marco (ii) • Reglas de marco para on: (defrule marco-move-1 (move ?s1 ?s2 ?u ?v ?z) (on ?x&~?u ?y ?s1) => (assert (on ?x ?y ?s2)) ) • Reglas de marco para clear: (defrule marco-move-2 (move ?s1 ?s2 ?x ?y ?z) (clear ?u&~?z ?s1) => (assert (clear ?u ?s2)) ) Modelado de cambios: ejemplo de ejecución: ciclo 0 • Memoria de Trabajo f-0 f-1 f-2 f-3 f-4 f-5 0 efecto-move: f-4,f-5,f-3 • Agenda (initial-fact) (on B T S0) (on A B S0) (on C A S0) (clear C S0) (clear T S0) “move(C,A,T) en S0” Modelado de cambios: ejemplo de ejecución: ciclo 1 Se ejecuta la regla efecto: “cambios producidos por move(C,A,T)” • Memoria de Trabajo • Agenda f-0 f-1 f-2 f-3 f-4 f-5 (initial-fact) (on B T S0) (on A B S0) (on C A S0) (clear C S0) (clear T S0) 0 marco-move-2: f-9,f-4 0 marco-move-1: f-9,f-1 0 marco-move-1: f-9,f-2 f-6 f-7 f-8 f-9 (on C T gen1) (clear A gen1) (clear T gen1) (move S0 gen1 C A T) “clear(C) persiste en gen1” “on(B,T) persiste en gen1” “on(A,B) persiste en gen1” Modelado de cambios: ejemplo de ejecución: ciclo 2 Se ejecuta la regla marco: “clear(C) persiste después de move(C,A,T)” • Memoria de Trabajo • Agenda f-0 f-1 f-2 f-3 f-4 f-5 (initial-fact) (on B T S0) (on A B S0) (on C A S0) (clear C S0) (clear T S0) 0 marco-move-1: f-9,f-1 0 marco-move-1: f-9,f-2 0 efecto-move: f-10,f-7,f-6 f-6 (on C T gen1) f-7 (clear A gen1) f-8 (clear T gen1) f-9 (move S0 gen1 C A T) f-10 (clear C gen1) “on(B,T) persiste en gen1” “on(A,B) persiste en gen1” “move(C,T,A) en gen1” Modelado de cambios: ejemplo de ejecución: ciclo 3 Se ejecuta la regla efecto: “on(B,T) persiste después de move(C,A,T)” • Memoria de Trabajo • Agenda f-0 f-1 f-2 f-3 f-4 f-5 (initial-fact) (on B T S0) (on A B S0) (on C A S0) (clear C S0) (clear T S0) 0 marco-move-1: f-9,f-2 0 efecto-move: f-10,f-7,f-6 f-6 (on C T gen1) f-7 (clear A gen1) f-8 (clear T gen1) f-9 (move S0 gen1 C A T) f-10 (clear C gen1) f-11 (on B T gen1) “on(A,B) persiste en gen1” “move(C,T,A) en gen1” Modelado de cambios: ejemplo de ejecución: ciclo 4 Se ejecuta la regla efecto: “on(A,B) persiste después de move(C,A,T)” • Memoria de Trabajo • Agenda f-0 f-1 f-2 f-3 f-4 f-5 (initial-fact) (on B T S0) (on A B S0) (on C A S0) (clear C S0) (clear T S0) 0 efecto-move: f-10,f-7,f-6 0 efecto-move: f-7,f-10,f-12 0 efecto-move: f-7,f-8,f-12 ... f-6 (on C T gen1) f-7 (clear A gen1) f-8 (clear T gen1) f-9 (move S0 gen1 C A T) f-10 (clear C gen1) f-11 (on B T gen1) f-12 (on A B gen1) “move(C,T,A) en gen1” “move(A,B,C) en gen1” “move(A,B,T) en gen1” Modelado de cambios: ejemplo de ejecución: ciclo 5 Se ejecuta la regla efecto: “cambios producidos por move(C,T,A)” • Memoria de Trabajo f-0 f-1 f-2 f-3 f-4 f-5 (initial-fact) (on B T S0) (on A B S0) (on C A S0) (clear C S0) (clear T S0) • Agenda f-6 (on C T gen1) f-7 (clear A gen1) f-13 (on C A gen2) f-8 (clear T gen1) f-14 (clear T gen2) f-9 (move S0 gen1 C A T) f-15 (move gen1 gen2 C T A) f-10 (clear C gen1) f-11 (on B T gen1) f-12 (on A B gen1) 0 efecto-move: f-7,f-10,f-12 0 efecto-move: f-7,f-8,f-12 0 marco-move-2: f-15,f-8 0 marco-move-2: f-15,f-10 0 marco-move-1: f-15,f-11 0 marco-move-1: f-15,f-12 ... “move(A,B,C) en gen1” “move(A,B,T) en gen1” “clear(T) persiste en gen2” “clear(C) persiste en gen2” “on(B,T) persiste en gen2” “clear(A,B) persiste en gen2” Modelado de cambios: Problemas • Problema del marco (frame problem) – explosión combinatoria de reglas de marcos: una regla para cada combinación acción/ propiedad variante – ineficiencia computacional – suposición del mundo cerrado: todo lo que no se menciona sigue igual • Problemas de cualificaciones (qualification problem) – entornos complejos / continuos – no se pueden incluir todas las propiedades potencialmente relevantes pero improbables en la condición de las reglas de efecto: no-muy-pesado(X) ∧ no-Pegado(X) ∧ no-Brazo-roto(R) ∧ ... – razonamiento no-monótono: sacar conclusiones por defecto y retirarlas cuando hay evidencia en contra • Problema de ramificaciones (ramification problem) – evitar que las reglas de marco deduzcan la persistencia de propiedades derivadas, cuya razón inicial sí ha variado – mecanismos de mantenimiento de la verdad Ejercicio Representación de cambio con reglas: Escriba una extensión de la Base de Conocimiento de reglas para el mundo de los bloques, de modo que el proceso de inferencia pare cuando se detecta un estado meta. El plan que ha llevado desde el estado inicial al estado meta debe aparecer en pantalla. Ejercicio En este ejercicio volvemos a modelar el problema de encontrar rutas en una red de carreteras, pero sobre la base de una representación en reglas Un agente desea desplazarse por carretera desde la ciudad en la que se encuentra actualmente a una ciudad destino. La acción básica que puede emprender es ir(x,y), que lo lleva de la ciudad x a la ciudad y, siempre y cuando exista una ruta directa entre ambas. Este último hecho se expresa mediante hechos (rutaDirecta x y). Puede suponer que tales hechos ya están presentes en la Base de Conocimiento del agente, y que representa la información resumida en el mapa que se muestra arriba. Ejercicio a) Elabora una Base de Conocimiento de reglas para este problema. Suponga inicialmente que el agente se encuentra en Arad. Elabore una consulta adecuada, cuyas soluciones planteen rutas posibles para alcanzar la meta (estancia en Bucarest) b) Suponga ahora que si se utiliza una ruta directa entre dos ciudades, el consumo de gasolina es igual a la distancia que separa a las ciudades. El agente inicia el recorrido con el depósito del vehículo lleno. Amplíe la representación de manera que este tipo de consideraciones queden incluidas. La consulta especificada anteriormente debe seguir funcionando y produciendo planes que sean factibles c) Supóngase ahora que algunos de los vértices son gasolineras, donde el robot llena el depósito de su vehículo mediante la acción llenar (hecho gasolinera). Incorpore las estaciones de gasolina en la representación propuesta y elabore todas las reglas que sean necesarias con el fin de que la acción llenar quede completamente descrita.