3. Componentes del Modelo de Conocimiento

Transcripción

1 La metodología CommonKADS 3. Componentes del Modelo de Conocimiento 3.1 Introducción 3.2 Conocimiento de Dominio 3.3 Conocimiento de Inferencia 3.4 Conocimiento de Tarea Carlos Alonso González Dpto. de Informática Universidad de Valladolid

2 3.1 Introducción Naturaleza del Conocimiento Desafíos del Modelado de Conocimiento El Modelo de Conocimiento Contexto Categorías 2

3 Naturaleza del conocimiento Información sobre la información Ejemplo: jerarquía de clases Frontera difusa entre información y conocimiento Simplificación: El conocimiento es simplemente información compleja que nos dice algo sobre otra información 3

4 Conocimiento: Naturaleza/Desafíos person age income has loan loan amount interest INFORMATION John has a loan of $1,750 Harry has a loan of $2,500 KNOWLEDGE A person with a loan should be at least 18 years old A person with an income up to $10,000 can get a maximum loan of $2,000 A person with an income between $10,000 and $20,000 can get a maximum loan of $3,000 4

5 Desafíos del modelado de conocimiento Encontrar patrones o esquemas que permitan estructurar el conocimiento 5

6 Patrones Un esquema de conocimiento A person with a loan should be at least 18 years old Otros esquemas A person with an income up to $10,000 can get a maximum loan of $2,000 A person with an income between $10,000 and $20,000 can get a maximum loan of $3,000 6

7 Estructurar la Base de Conocimiento Rule 1: IF... THEN... Rule 2: IF... THEN... Rule 3: IF... THEN... Rule 4: IF... THEN... Rule 5: IF... THEN... Rule 6: IF... THEN... Rule 7: IF... THEN... Rule 8: IF... THEN... Rule 9: IF... THEN... Rule 10: IF... THEN... Rule 11: IF... THEN... Rule 12: IF... THEN... <plus many others> rules of type A rules of type C rules of type B rules of type D single flat knowledge base multiple rule sets containing rules with similar structure 7

8 Modelo de Conocimiento Herramienta de análisis de tareas que hacen un uso intensivo del conocimiento Especifica el conocimiento y su uso para realizar una tarea Se desarrolla como parte del análisis Orientada aplicaciones reales vocabulario de la aplicación, dominio(coche, casa...), razonamiento (diagnosis, evaluación...) Abstrae aspectos de comunicación Independiente de la implementación Reutilización 8

9 Modelo de Conocimiento: Contexto Modelo de Organización Modelo de Tarea Modelo de Agente Tarea que usa conocimiento Seleccionada en Estudio Viabilidad Más detallada en modelos de Tarea y Agente Modelo de Conocimiento Modelo de Comunicación Especificación Requisitos Funcionales Razonamiento Modelo de Diseño Especificación Requisitos Funcionales Interacción 9

10 Modelo de Conocimiento: Categorías Conocimiento de Dominio (Domain Knowledge) Conocimiento y Definiciones de tipos específico del dominio Definiciones de enfermedades, síntomas, pruebas y relaciones entre ellos Su descripción es comparable a un modelo de datos o de objetos Estático Conocimiento de Inferencia (Inference Knowledge) Pasos de inferencia básicos Plantear hipótesis, verificar Equivalente Ingeniería Software: nivel mínimo de descomposición funcional Conocimiento de Tarea (Task Knowledge) Metas y como obtenerlas mediante descomposición en subtareas e inferencias Descripción comportamiento dinámico: control Equivalente Ingeniería Software: máximo nivel de descomposición funcional + control 10

11 Modelo de Conocimiento: Categorías Conocimiento de Tarea metas de la tarea descomposición de la tarea control de la tarea DIAGNOSIS (tarea) Conocimiento de Inferencia inferencias básicas papeles Plantear Hipótesis (Inferencia) Verificar (Inferencia) Conocimiento de Dominio Tipos del dominio Síntoma Enfermedad Prueba Reglas del dominio Hechos del dominio (tipo) (tipo) (tipo) 11

12 Ejemplo: diagnosis de automóviles fusible fundido batería baja depósito combustible vacío 1 inspección fusible roto indicador batería cero indicador combustible cero 6 potencia desconectada comportamiento motor no arranca 7 8 combustible en motor falso comportamiento motor se para 9 Fragmento de conocimiento de dominio 12

13 3.2 Conocimiento de Dominio Describe la información estática y los elementos del dominio de la aplicación Consta de uno o más esquemas de dominio patrones una o más bases de conocimiento instancias 13

14 3.2 Conocimiento de Dominio Esquema de Dominio (Domain Schema) Descripción esquemática del conocimiento e información dependiente del dominio mediante definiciones de tipo Información estática /estructura del conocimiento Perspectiva IS: similar a modelo de datos u objetos Base de conocimiento (Knowledge Base) Instancias de los tipos especificados en el esquema de dominio Principal diferencia con otros sistemas de información (e.g. Base de datos): las particularizaciones que contiene la Base de Conocimiento son de interés en el análisis (e. g. las tuplas de una Base de Datos no) 14

15 Especificación Esquema de Dominio Conjunto de constructores que permiten especificar un esquema de dominio Notación Textual: Conceptual Modelling Language Gráfica: diagramas de clase UML Constructores básicos: CONCEPT, RELATION, RULE TYPE 15

16 Conceptos CONCEPT describe un conjunto de objetos o instancias que comparten características similares semejante a las clases UML, pero sin funciones (marcos) ATTRIBUTE describen las características de los conceptos Pueden tener un valor, por defecto único Necesariamente tipo Valores atómicos, descritos mediante VALUE TYPE (además tipos estándar, UNIVERSAL, enumerado) Los atributos no puede referenciar otros conceptos Usar RELATION 16

17 Conceptos: Especificación gráfica y textual indicador combustible valor: valor-indicador CONCEPT indicador-combustible; ATTRIBUTES: valor: valor-indicador; END CONCEPT indicador-combustible; depósito combustible estado: { lleno, casi-vacío, vacío} CONCEPT depósito combustible; ATTRIBUTES: estado: {lleno, casi-vacío, vacío}; END CONCEPT depósito combustible; VALUE-TYPE valor-indicador; VALUE-LIST: {cero, bajo, normal}; TYPE: ORDINAL; END VALUE-TYPE valor-indicador; 17

18 Jerarquías SUPER-TYPE-OF/SUB-TYPE-OF permiten modelar relaciones de generalización/especialización organizar los conceptos/relaciones en jerarquías de herencia UML generalization Semántica subtype? Tres tipos de especializaciones básicas Nuevas características: añadir nuevos atributos Restricción de tipo Restricción cardinalidad Excepciones?, Contradicciones? 18

19 observable coche valor: universal indicador combustible valor: valor-indicador indicador batería valor: valor-indicador inspección fusible valor: {normal, roto} Relaciones subtipo en el dominio de la diagnosis de automóviles (I) 19

20 estado coche status: universal observable: boolean estado coche no visible observable: {false} fusible status: {normal, fundido} batería potencia status: {normal, status: {on, baja} off} estado coche visible observable: {true} comportamiento motor status: {normal, no-arranca, se-para} depósito combustible status: {lleno, casi-vacío, vacío} combustible en motor status: boolean Relaciones subtipo en el dominio de la diagnosis de automóviles (II) 20

21 Subtipos Vivienda residence CONCEPT house; DESCRIPTION: "a residence with its own territory"; SUB-TYPE-OF: residence; ATTRIBUTES: square-meters: NATURAL; END CONCEPT house; house square-meters: natural apartment entrance-floor: natural lift-available: boolean CONCEPT apartment; DESCRIPTION: "part of of a larger estate"; SUB-TYPE-OF: residence; ATTRIBUTES: entrance-floor: NATURAL lift-available: BOOLEAN; END CONCEPT apartment; 21

22 Relaciones RELATION o BINARY-RELATION permite definir relaciones entre conceptos UML association similar a atributos cuyo valor es otro concepto Se definen mediante ARGUMENTs tipo, cardinalidad, papel Pueden tener Atributos (Association class) Pueden tener dirección (si binarias) 22

23 Relaciones: espec. gráfica y textual a) b) coche coche 0+ pertenencia posee 0-1 persona persona BINARY-RELATION poseido-por; INVERSA: posee; ARGUMENT-1: coche; CARDINALITY: 0-1; c) coche persona ARGUMENT-2: persona; CARDINALITY: ANY; ATTRIBUTES: poseido-por fecha compra: date fecha compra: DATE; END BINARY-RELATION poseido-por; 23

24 Modelado de reglas Las reglas permiten representar con facilidad el conocimiento de naturaleza heurística: Relaciones ente elementos del dominio (síntomas y enfermedades, por ejemplo) No necesariamente formales En al análisis se buscan reglas con una estructura común Estructura definida por rule type 24

25 Tipo Regla Permite modelar relaciones entre expresiones sobre valores de atributos de conceptos esencial en CommonKADS depósito-combustible.status = vacío => combustible-en-motor.status = false batería.status = baja => indicador-batería.valor = cero Se trata de encontrar conjuntos de reglas del dominio de aplicación que tengan estructura similar Reglas naturales: relación existente entre expresiones No necesariamente implicaciones lógicas Especificar símbolo de conexión 25

26 Ejemplo tipo regla person name: string income: integer 1+ restricts loan amount: integer interest-rate: number loan constraint person.income <= 10,000 RESTRICTS loan.amount <= 2,000 person.income > 10,000 AND person.income <= 20,000 RESTRICTS loan.amount <= 3,000 A person with an income up to $10,000 can get a maximum loan of $2,000 A person with an income between $10,000 and $20,000 can get a maximum loan of $3,000 26

27 Estructura tipo regla <antecedente> <símbolo-conexión> <consecuente> Ejemplo de regla depósito-combustible.status = vacío CAUSA combustible-en-motor.status = false 27

28 Relaciones entre expresiones fusible fundido batería baja depósito combustible vacío 1 inspección fusible roto indicador batería cero indicador combustible cero 6 potencia desconectada 7 8 combustible en motor falso 9 comportamiento motor no arranca comportamiento motor se para Fragmentos de conocimiento en el dominio de la diagnosis de automóviles 28

29 Ejemplo reglas dependencia estado depósito-combustible.status = vacío => combustible-en-motor.status = false RULE-TYPE dependencia-estado; ANTECEDENT: estado coche no visible; CARDINALITY: 1; CONSEQUENT: estado coche; estado coche no visible 1 1 causa estado coche CARDINALITY: 1; CONECTION-SYMBOL: dependencia estado causa END RULE-TYPE dependencia-estado; Modela relaciones 2, 3, 6, 7, 8, 9 29

30 Ejemplo reglas dependencia estado combustible-en-motor.status = false => depósito-combustible.status = vacío RULE-TYPE dependencia-estado; ANTECEDENT: estado coche; CARDINALITY: 1; CONSEQUENT: estado coche no visible; estado coche 1 1 Causado-por estado coche no visible CARDINALITY: 1; CONECTION-SYMBOL: dependencia estado causado-por END RULE-TYPE dependencia-estado; Modela relaciones 2, 3, 6, 7, 8, 9 30

31 Ejemplo reglas manifestación batería.status = baja => indicador-batería.valor = cero RULE-TYPE regla-manifestación; DESCRIPTION: Regla que establece la relación entre un estado interno y su comportamiento externo en términos de estado coche no visible 1 se 1 manifiesta observable coche un valor observable ; ANTECEDENT: estado coche no visible; CONSEQUENT: observable coche; regla manifestación CONECTION-SYMBOL: se-manifiesta; END RULE-TYPE regla-manifestación; Modela relaciones 1, 4, 5 31

32 Base de conocimiento Instancias de los tipos (de conocimiento) especificados en el esquema de dominio Consta de Slot USES, que indica los tipos utilizados y esquemas de dominio que los declaran <type> FROM <domain schema> Slot EXPRESSIONS, que contiene las instancias de reglas 32

33 Base de Conocimiento red-causal-automóvil KNOWLEDGE-BASE red-causal-automóvil; USES: dependencia-estado FROM esquema-diagnosis-automóvil; regla-manifestación FROM esquema-diagnosis-automóvil; EXPRESSIONS: /* dependencias de estado */ fusible.status = fundido CAUSA potencia.status = off; batería.status = baja CAUSA potencia.status = off; potencia.status = off CAUSA comportamiento-motor.status = no-arranca; depósito.combustible.status = vacío CAUSA combustible-en-motor.status = false; combustible-en-motor.status = false CAUSA comportamiento-motor.status = no-arranca; combustible-en-motor.status = false CAUSA comportamiento-motor.status = se-para; /* reglas de manifestación */ fusible.status = fundido SE-MANIFIESTA inspección-fusible.valor = roto; batería.status = baja SE-MANIFIESTA indicador-batería.valor = cero; depósito-combustible.status = vacío SE-MANIFIESTA indicador-combustible.valor = cero; END KNOWLEDGE-BASE red-causal-automóvil; 33

34 Base de Conocimiento red-causal-automóvil KNOWLEDGE-BASE red-causal-automóvil; USES: dependencia-estado FROM esquema-diagnosis-automóvil; regla-manifestación FROM esquema-diagnosis-automóvil; EXPRESSIONS: /* dependencias de estado */ potencia.status = off CAUSADO-POR fusible.status = fundido; potencia.status = off CAUSADO-POR batería.status = baja; comportamiento-motor.status = no-arranca CAUSADO-POR potencia.status = off; combustible-en-motor.status = false CAUSADO-POR depósito.combustible.status = vacío; comportamiento-motor.status = no-arranca CAUSADO-POR combustible-en-motor.status = false; comportamiento-motor.status = se-para CAUSADO-POR combustible-en-motor.status = false; /* reglas de manifestación */ fusible.status = fundido SE-MANIFIESTA inspección-fusible.valor = roto; batería.status = baja SE-MANIFIESTA indicador-batería.valor = cero; depósito-combustible.status = vacío SE-MANIFIESTA indicador-combustible.valor = cero; END KNOWLEDGE-BASE red-causal-automóvil; 34

35 Sintaxis CML Conocimiento de dominio (1) domain-knowledge ::= domain-knowledge Domain-knowledge; <domain-schema knowledge-base>* end domain-knowledge domain-schema ::= domain-schema Domain-schema; <domain-construct ;>* end domain-knowledge [Domain-knowledge] domain-construct ::= binary-relation concept mathematical-model relation rule-type value-type 35

36 Sintaxis CML Conocimiento de dominio (2) knowledge-base ::= knowledge-base knowledge-base; use: knowledge-base-use [[instances:] <instance tuple>+] [variables: variable-declaration;... ;] [expresions :knowledge-based-expresion... ;] [annotations: Text ;] [attributes] end knowledge-base [ knowledge-base ] knowledge-base-use::= Domain-schema Rule-Type from Domain-schema knowledge-base-expresion::= variable-declaration rule-type-instance text 36