Dlv Manual - answer set progrmming, Apuntes de Inteligencia Artificial

¡Descarga Dlv Manual - answer set progrmming y más Apuntes en PDF de Inteligencia Artificial solo en Docsity!

DLV User

Manual

Robert Bihlmeyer, Wolfgang Faber, Giuseppe

Ielpa,Vincenzino Lio,Gerald Pfeifer

Traducido por: Francisco I. Torres.

INDICE

Ejemplo 4-10. Razonamiento cauteloso con éxito, si el programa no tiene ningún modelo

• INTRODUCCIÓN
• CAPITULO 1: Empezando
• CAPITULO 2: El Lenguaje Central de DLV: Disjunctive Datalog
  • Ejemplo 2-1. Términos simples:
  • Ejemplo 2-2. Términos complejos:.....................................................................................
  • Ejemplo 2-3. Predicados:
  • Ejemplo 2-4. Átomos:
  • Ejemplo 2-5. Literales:
  • Ejemplo 2-6. Hechos:
  • Comentarios
  • Ejemplo 2-7.
  • EDB - Base de Datos Extensional
  • IDB - Base de Datos Intensional
  • Ejemplo 2-8. Reglas:
  • Ejemplo 2-9. Hechos disyuntivos:
  • Ejemplo 2- 10 Restricciones :
  • Reglas Definidas
  • Ejemplo 2-11. Uso de variables anónimas
  • Reglas Disyuntivas
  • Reglas Negativas
  • Negación Verdadera..........................................................................................................
  • Ejemplo 2-12. Negación verdadera vs. negación como falla
  • Ejemplo 2-13. Criterio de consistencia
  • Integridad de las restricciones
  • Ejemplo 2-14. Restricciones y negación
  • Restricciones Débiles
  • Ejemplo 2-16. Restricciones Débiles solo con Pesos.
  • Ejemplo 2-17. Construcción de equipos con pesos y prioridades
  • Predicados incorporados
  • Predicados Comparativos
  • Ejemplo 2-18. Predicados Comparativos:
  • Predicados Aritméticos
  • Predicados de Lista
  • Ejemplo 2-20. Predicados de Lista:
  • Hechos sobre un Rango de Enteros Fijos
  • Constantes Integradas
  • Constantes Nombradas
  • Ejemplo 2-21. Constante nombrada numérica
  • Ejemplo 2-22. Constante nombrada simbólica
  • Ejemplo 2-23. Asignar una constante nombrada a una constante nombrada
  • Ejemplo 2-24. Un programa de ejemplo extraño
  • Predicados de Agregación
  • Ejemplo 2-25. Predicados de Agregación
  • Conjuntos Simbólicos
  • Ejemplo 2-26. Sintaxis de Conjunto Simbólico
  • Ejemplo 2-27. Significado informal de Conjunto Simbólico
  • Funciones de Agregación
  • Ejemplo 2-28. Significado Informal de las Funciones de Agregación
  • Ejemplo 2-29. Empleados de Cartoons Co.
  • Ejemplo 2-30. Función de Agregación #count
  • Ejemplo 2-31. Función de Agregación #sum
  • Ejemplo 2-32. Función de Agregación #times
  • Ejemplo 2-33. Función de Agregación #min
  • Ejemplo 2-34. Función de Agregación #max
  • Representación de Conocimiento Usando Predicados de Agregación
  • Ejemplo 2-35. Árbol de Expansión Mínima con Agregados y Restricciones Débiles
  • Ejemplo 2-36. El Problema de la Distribución de Asientos
• Capítulo 3. Seguridad
  • Predicados Estándar, Aritméticos y Comparativos
  • Ejemplo 3-1. Reglas y Restricciones Seguras
  • Ejemplo 3-2. Reglas y Restricciones No Seguras
  • Agregados
  • Ejemplo 3-3. Reglas y Restricciones Seguras
  • Ejemplo 3-4. Reglas y Restricciones No Seguras
  • Verificación de Dominio Finito.
  • Predicados Aritméticos
  • Ejemplo 3-5. Programa No de Dominio Finito
  • Términos Complejos
  • Ejemplo 3-6. Programa No de Dominio Finito
  • Ejemplo 3-7. Programa de Dominio Finito
  • Ejemplo 3-8. Programa que genera listas cada vez más largas
  • Ejemplo 3-9. Listas que crecen tanto en longitud como en anidación
• Capítulo 4. Consultas
  • Ejemplo 4-1. Consultas:
  • Razonamiento Bravío
  • Ejemplo 4-2. Un ejemplo de razonamiento no concreto
  • Ejemplo 4-3. Una consulta con múltiples ocurrencias de variables
  • Ejemplo 4-4. Una consulta con negación
  • Razonamiento Bravío sobre Consultas Concretas
  • Ejemplo 4-5. Un ejemplo de razonamiento bravío con éxito
  • Ejemplo 4-6. Razonamiento bravío con fracaso
  • Razonamiento Cauteloso
  • Ejemplo 4-7. Un ejemplo de razonamiento cauteloso no concreto
  • Razonamiento Cauteloso sobre Consultas Concretas.......................................................
  • Ejemplo 4-8. Razonamiento cauteloso con éxito
  • Ejemplo 4-9. Razonamiento cauteloso con fracaso
  • Disjunctive Datalog Puro
  • Ejemplo 4-11. Consulta de Disjunctive Datalog Puro
  • Conjuntos Mágicos Dinámicos
• Capítulo 5. Interfaces
  • Tabla 5-1. Interfaces para DLV
  • Interfaz de Diagnóstico
  • Tabla 5-2. Restricciones de teoría en el razonamiento diagnóstico abductivo
  • Tabla 5-3. Restricciones de teoría en el razonamiento diagnóstico de Reiter
• Capítulo 6. Sinopsis
  • Tabla 6-1. Opciones de la Interfaz
  • Tabla 6-2. Opciones Generales
• Capítulo 7. Consejos Aleatorios/Cómo Escribir Programas en DLV

INTRODUCCIÓN

DLV es un sistema de base de datos deductivo, basado en programación lógica disyuntiva, que ofrece interfaces para varios formalismos KR avanzados.

CAPITULO 2: El Lenguaje Central de DLV:

Disjunctive Datalog

El lenguaje nativo de DLV es Disjunctive Datalog extendido con restricciones, negación verdadera y consultas. Los elementos más básicos de Disjunctive Datalog son las constantes. Estas se refieren a entidades, al igual que los objetos que se almacenan en bases de datos relacionales.

• Los nombres de las constantes deben comenzar con una letra minúscula y pueden estar compuestos por letras, guiones bajos y dígitos. Además, todos los números también son considerados constantes. Las variables son marcadores de posición para las constantes.
• Los nombres de las variables deben comenzar con una letra mayúscula y pueden contener letras, guiones bajos y dígitos. Existe una característica especial llamada " variable anónima ". La variable anónima se denota con “”. Cada aparición de "" representa una variable nueva y única, que no se encuentra en ninguna otra parte de la misma regla o restricción. Las variables anónimas pueden considerarse como declaraciones de preprocesador que se sustituyen por nombres de variables únicas (en realidad, esta descripción es bastante cercana a lo que sucede internamente). El propósito de esta característica es especificar que un argumento puede ser ignorado o no importa en la regla o restricción actual sin tener que inventar nombres de variables nuevos y únicos. Nota : "not" es una palabra reservada y no es una constante válida. Nota: Dado que las variables anónimas representan variables únicas, no tiene sentido utilizarlas en la parte principal de una regla o en un literal negativo en el cuerpo, ya que tales reglas no pueden ser seguras (consulte el Capítulo 3 ).

Un término es o bien un término simple o un término complejo. Un término simple es o bien una constante o una variable. Ejemplo 2-1. Términos simples:

• Constantes: a1, 1, 9862, aBc1, c__
• Variables: A, V2f, Vi_X Un término complejo es o bien un término funcional o un término de lista.
• Un término funcional es un símbolo de función seguido de una lista de términos entre paréntesis.
• Un símbolo de función debe comenzar con una letra minúscula y puede estar compuesto por letras, guiones bajos y dígitos. Un término de lista puede tener las dos siguientes formas: [t1,..., tn], es decir, una lista de términos encerrados entre corchetes cuadrados. [h|t], donde h (la cabeza de la lista) es un término y t (la cola de la lista) es un término de lista (sintaxis "a la Prolog"). Ejemplo 2-2. Términos complejos: Términos funcionales: f(1), g_1(a), fUN(1, a, f(5)), f(X), f(a, f(gibon(X), 1, Y), Zulu) Términos de lista: [a, [1, 2], c, [2, 3]], [1, f(1), 2, f(a)], [], [1 | [2, 3]], [a | [b | [c]]], ["Zulu", [], f([])] Los predicados corresponden a relaciones tradicionales. Los símbolos de predicado comienzan con una letra y pueden contener letras, guiones bajos y dígitos. Nuevamente, "not" no es un predicado válido. Nota: Dado que la presencia de términos complejos podría llevar a la derivación de un número infinito de nuevos términos, los programas que incluyen términos complejos se verifican para asegurar que la terminación esté garantizada de antemano (consulte el Capítulo 3 ).

Ejemplo 2-6. Hechos: weight(apple, 100, gramo).

• valid(1, igual, 0). Comentarios Un programa DLV puede ser documentado añadiendo comentarios directamente al código fuente. Cualquier línea que comience con el carácter "%" o cualquier cosa que esté entre un carácter "%" (que no ocurra dentro de una cadena entre comillas) y el final de la línea actual se considera un comentario y es ignorado por DLV. Ejemplo 2-7. Un programa con comentarios EDB - Base de Datos Extensional Datalog Disjunctivo combina bases de datos y programación lógica (de ahí el nombre). Por esta razón, DLV puede verse como un sistema de programación lógica o como un sistema de base de datos deductiva. Para ser coherente con la terminología de las bases de datos deductivas, la entrada se separa en la base de datos extensional (EDB), que es una colección de hechos, y la base de datos intensional (IDB), que se utiliza para deducir hechos. Con DLV, una forma de especificar dicha base de datos es proporcionando hechos en un archivo, pero también existe la posibilidad de importar hechos desde una base de datos relacional, a través de ODBC, como se describe en el Capítulo 8. % Esta línea es un comentario. weight(apple, 100, gramo). % Aquí hay un nuevo comentario, termina en esta fila.

El EDB puede contener conocimiento puramente proposicional, como en el siguiente ejemplo: Supongamos que lo anterior (que podría ser una descripción muy simplificada de una máquina de vapor) se almacena en un archivo llamado engine. Ahora veamos qué sucede si llamamos a DLV con esta entrada: Como se esperaba, la respuesta contiene precisamente las dos afirmaciones. Sin embargo, dado que el EDB es conocimiento fijo, mostrarlo en la salida a menudo no es deseado (ya que es redundante) o incluso contraproducente, ya que, para aplicaciones reales, el EDB será muy grande. Usando la opción - nofacts, los predicados que ocurren solo en el EDB (es decir, definidos solo mediante hechos) no se mostrarán. Nota: DLV no requiere que EDB e IDB se almacenen en archivos separados. La misma relación puede consistir en partes de EDB e IDB. Sin embargo, en general, se considera más limpio si EDB e IDB están separados. Para hacer esta separación explícita, utilizamos archivos distintos para EDB e IDB en este capítulo. Los ejemplos también funcionan si las entradas se almacenan en un solo archivo, por ejemplo. hot_furnace. valve_closed. $ DLV - silent engine {hot_furnace, valve_closed} $ DLV - silent - nofacts engine {}

IDB - Base de Datos Intensional Hasta ahora, hemos mostrado cómo especificar una base de datos que sirve como entrada (el EDB). En esta sección, mostraremos cómo definir conocimiento que puede hacer uso de estas bases de datos de entrada. Este conocimiento puede depender del EDB o puede representar conocimiento independiente pero indefinido, o ambos. Colectivamente, esta parte de la entrada se llama base de datos intensional (IDB), o a veces simplemente programa. Las reglas establecen relaciones entre literales explícitamente negados. Básicamente, las reglas tienen la siguiente forma: h1 v ... v hn :- b1, ..., bm. h1 hasta hn representan literales explícitamente negados, donde n > 0 (es decir, debe haber al menos uno de esos). El :- es la transcripción de una flecha de implicación y b1, ..., bm representan literales generales, donde m >= 0 debe cumplirse (es decir, el cuerpo se puede omitir por completo). La parte antes de :- se llama cabeza, la parte después de :- se llama cuerpo. Tenga en cuenta que los símbolos de negación por falta de éxito solo pueden ocurrir en el cuerpo. Además, las reglas deben ser seguras. Para una definición, consulte el Capítulo 3. Informalmente, si el cuerpo se evalúa como verdadero, la cabeza también debe evaluarse como verdadera. Los símbolos de negación por falta de éxito se pueden leer como "no hay evidencia de que xxx se evalúe como verdadero", como en la lógica por defecto. La cabeza representa una disyunción mientras que el cuerpo representa una conjunción.

Ejemplo 2-8. Reglas: También tenga en cuenta que los hechos se pueden ver como formas especiales de reglas, en las cuales el cuerpo está vacío. El elemento neutral de la conjunción es verdadero, por lo que los hechos siempre deben ser verdaderos. También permitimos hechos disyuntivos como un caso especial. Tenga en cuenta que debido al requisito de seguridad (consulte el Capítulo 3 ), no pueden aparecer variables en hechos disyuntivos. Ejemplo 2-9. Hechos disyuntivos: La otra forma especial de una regla, en la que la cabeza está vacía, se llama restricción. El elemento neutral de la disyunción es la falsedad, por lo que el cuerpo de una restricción no debe convertirse en verdadero, porque la cabeza nunca puede convertirse en verdadera. Estos constructos se pueden utilizar para limitar los mundos descritos por el programa, de ahí el nombre. Dado que las restricciones son formas especiales de reglas, deben cumplir con el criterio de seguridad (consulte el Capítulo 3 ).

• ok :- not - hazard. male(X) v female(X) :- person(X). fruit(P) v vegetable(P) :- plant_food(P). true v false :-. employee(P) :- personnel_info(_, P, _, _, _). true v false. edible(apple) v foul(apple).

Por ejemplo, podríamos querer definir la noción de un camino (es decir, hay una secuencia de arcos de un nodo a otro nodo) en cualquier gráfico que se defina mediante el predicado arc. El siguiente IDB hace exactamente eso: Tenga en cuenta que X, Y y Z son variables.

• El nombre de una variable es una secuencia de letras, guiones bajos y dígitos, que comienza con una letra mayúscula.
• El nombre de un predicado puede ser cualquier secuencia de letras, guiones bajos y dígitos, que comienza con una letra minúscula. Entonces, el programa anterior dice que hay un camino desde algún X hasta algún Y, si hay un arco desde X hasta Y. La segunda regla es más difícil: dice que existe un camino desde X hasta Y, si hay un camino desde X hasta algún Z (tenga en cuenta que Z no apareció antes en esta regla) y hay un arco desde este Z hasta Y. La segunda regla vale la pena examinarla. El predicado path aparece tanto en la cabeza como en el cuerpo de la regla, por lo que parece que algo se está definiendo a sí mismo, lo cual parece extraño. Sin embargo, esta es una característica común en la programación lógica y se llama recursión. Puede pensar en ello como suponer que path ya está completamente definido y especificar las condiciones que deben cumplirse para la relación definida. Tenga en cuenta que las variables que aparecen en la cabeza también deben aparecer en el cuerpo. Este es uno de los requisitos de seguridad para las reglas (consulte el Capítulo 3 ). path(X, Y) :- arc(X, Y). path(X, Y) :- path(X, Z), arc(Z, Y).

Si tomamos este programa (supongamos que está almacenado en un archivo llamado path) y lo aplicamos al gráfico definido anteriormente, vemos: De hecho, este resultado corresponde a los caminos en el gráfico. A veces, una variable se utiliza para ocultar un argumento que no se utiliza en el resto de la regla. Por ejemplo, si desea definir un nodo en algún gráfico (especificado en el mismo formato que arriba), podría escribir: En la primera regla, Y se utiliza para ocultar el segundo argumento, en la segunda regla, X oculta el primer argumento de arc. DLV proporciona una característica que nos ahorra la necesidad de inventar nombres de variables para estas variables de enmascaramiento y que aclara a los lectores de los programas que una variable solo se usa para enmascarar. Esta característica se llama variable anónima y se denota como _ (un guion bajo). A pesar de su nombre, una variable anónima no es una variable como en la descripción original. Su significado se puede describir de la siguiente manera: en una etapa de preprocesamiento, cada aparición de una variable anónima se reemplaza por una variable única (que no aparece en ninguna otra parte de la misma regla o restricción). El ejemplo anterior (definición de un nodo) se puede volver a escribir de la siguiente manera: $ DLV - silent - nofacts simple_graph path {path(1,2), path(1,3), path(1,4), path(2,3), path(2,4)} node(X) :- arc(X, Y). node(Y) :- arc(X, Y).

minimalidad. Esto significa que si hay dos modelos potenciales y uno de ellos es un subconjunto del otro, no se debe considerar porque contiene información redundante. Dado que {sunny, light_on} es un superconjunto tanto de {sunny} como de {light_on}, no se considera un modelo adecuado. Tenga en cuenta que debido a este criterio de minimalidad, una regla disyuntiva puede dar lugar a exactamente uno de sus átomos en la cabeza. Si varios átomos en la cabeza son verdaderos en una regla, debe haber otras reglas que requieran la verdad de estos átomos adicionales verdaderos. Otro ejemplo: Digamos que desea encontrar alguna coloración de nodos en un gráfico, que se representa mediante arcos. Es decir, tenemos varios colores para elegir, digamos rojo, verde y azul, y cada nodo debe asignarse a un color, pero no sabemos cuál. Para ello, reutilizamos la definición de nodo del Ejemplo 2- 11. La parte más interesante es la última regla. Al igual que en el ejemplo anterior, especificamos que para cualquier nodo X, debe ser verdadero color(X,red), color(X,green) o color(X,blue). Aquí, el criterio de minimalidad asegura que exactamente un color se asigna a un nodo. node(X) :- arc(X,). node(Y) :- arc(,Y). color(X,red) v color(X,green) v color(X,blue) :- node(X).

Veamos la salida de DLV para este ejemplo (archivo coloring) en nuestro gráfico de ejemplo en simple_graph: Reglas Negativas Aún no hemos introducido otra característica importante de Datalog Disyuntivo: la negación. Se han hecho varias propuestas sobre lo que debería significar la negación en este contexto. DLV implementa una de ellas, que ha sido ampliamente aceptada como una propuesta razonable: la Semántica de Modelo Estable. La negación se trata como "negación por falta de éxito". En otras palabras, si un átomo no es verdadero en algún modelo, entonces su negación debe considerarse verdadera en ese modelo. No entraremos en detalles aquí, los ejemplos deberían darle una idea de cómo funciona esto. Con este mecanismo, podemos, por ejemplo, definir el grafo complementario de un grafo dado. $ DLV - silent - nofacts coloring simple_graph {node(1), node(2), node(3), node(4), color(1,red), color(2,red), color(3,red), color(4,red)} {node(1), node(2), node(3), node(4), color(1,red), color(2,red), color(3,red), color(4,green)} [... y así sucesivamente ...] {node(1), node(2), node(3), node(4), color(1,blue), color(2,blue), color(3,blue), color(4,green)} {node(1), node(2), node(3), node(4), color(1,blue), color(2,blue), color(3,blue), color(4,blue)}