3. Componentes del Modelo de Conocimiento

3.1 Introducción3.2 Conocimiento de Dominio3.3 Conocimiento de Inferencia3.4 Conocimiento de Tarea

Carlos Alonso GonzálezDpto. de InformáticaUniversidad de Valladolid

La metodología CommonKADS

2

3.1 Introducción

• Naturaleza del Conocimiento• Desafíos del Modelado de Conocimiento• El Modelo de Conocimiento

– Contexto– Categorías

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

4

Conocimiento: Naturaleza/Desafíos

person

ageincome

loan

amountinterest

John has a loan of $1,750Harry has a loan of $2,500

A person with a loan should be at least 18 years oldA person with an income up to $10,000 can get a maximum loan of $2,000A person with an income between $10,000 and $20,000 can get a maximum loan of $3,000

INFORMATION

KNOWLEDGE

has loan

5

Desafíos del modelado de conocimiento

• Encontrar patrones o esquemas que permitan estructurar el conocimiento

6

Patrones

• Un esquema de conocimiento

• Otros esquemas

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

7

Estructurar la Base de Conocimiento

Rule 1: IF ... THEN ...Rule 2: IF ... THEN ...Rule 3: IF ... THEN ...

Rule 12: 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 ...

<plus many others>

single flat knowledge base

multiple rule setscontaining rules

with similar structure

rules of type A

rules of type D

rules of type B

rules of type C

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

9

Modelo de Conocimiento: Contexto

Modelo de OrganizaciónModelo de TareaModelo de Agente

Modelo deConocimiento

Modelo deComunicación

Modelo de Diseño

EspecificaciónRequisitos Funcionales

Razonamiento

EspecificaciónRequisitos FuncionalesInteracción

Tarea que usa conocimientoSeleccionada en Estudio ViabilidadMás detallada en modelos de Tarea y Agente

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

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

Reglas del dominio

Hechos del dominio

Síntoma

(tipo)

Prueba

(tipo)

Enfermedad

(tipo)

12Fragmento de conocimiento de dominio

fusiblefundido

bateríabaja

inspección fusibleroto

depósito combustiblevacío

indicador bateríacero

indicador combustiblecero

potenciadesconectada

combustible en motorfalso

comportamiento motorno arranca

comportamiento motorse para

12 3

4 56

78

9

Ejemplo: diagnosis de automóviles

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

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)

15

Especificación Esquema de Dominio

Conjunto de constructores que permiten especificar un esquema dedominio

• Notación– Textual: Conceptual Modelling Language– Gráfica: diagramas de clase UML

• Constructores básicos: CONCEPT, RELATION, RULE TYPE

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

17

Conceptos: Especificacióngráfica y textual

indicador combustible

valor: valor-indicador

depósito combustible

estado: { lleno,

casi-vacío,

vacío}CONCEPT indicador-combustible;

ATTRIBUTES:

valor: valor-indicador;

END CONCEPT indicador-combustible; 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;

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?

19

observable coche

valor: universal

indicador combustible

valor: valor-indicadorindicador batería

valor: valor-indicador

inspección fusible

valor: {normal, roto}

Relaciones subtipo en el dominio de la diagnosis de automóviles (I)

20

estado coche

status: universal

observable: boolean

estado coche no visible

observable: {false}

estado coche visible

observable: {true}fusible

status: {normal,

fundido}

batería

status: {normal,

baja}

depósito combustible

status: {lleno,

casi-vacío, vacío}

potencia

status: {on,

off}

combustible en motor

status: boolean

comportamiento motor

status: {normal, no-arranca,

se-para}

Relaciones subtipo en el dominio de la diagnosis de automóviles (II)

21

Subtipos Vivienda

apartment

entrance-floor: naturallift-available: boolean

residence

house

square-meters: natural

CONCEPT house; DESCRIPTION: "a residence with its own territory"; SUB-TYPE-OF: residence; ATTRIBUTES: square-meters: NATURAL;END CONCEPT house;

CONCEPT apartment; DESCRIPTION: "part of of a larger estate"; SUB-TYPE-OF: residence; ATTRIBUTES: entrance-floor: NATURAL

lift-available: BOOLEAN;END CONCEPT apartment;

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)

23

Relaciones: espec. gráfica y textual

coche persona0+ 0-1pertenencia

coche persona

poseido-por

fecha compra: date

BINARY-RELATION poseido-por;

INVERSA: posee;

ARGUMENT-1: coche;

CARDINALITY: 0-1;

ARGUMENT-2: persona;

CARDINALITY: ANY;

ATTRIBUTES:

fecha compra: DATE;

END BINARY-RELATION poseido-por;

coche personaposee 0-10+

a)

b)

c)

0+ 0-1

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

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 = falsebaterí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

26

Ejemplo tipo regla

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

loanconstraint

restricts

person.income <= 10,000 RESTRICTS

loan.amount <= 2,000

person.income > 10,000 AND person.income <= 20,000RESTRICTS

loan.amount <= 3,000

person

name: stringincome: integer

loan

amount: integerinterest-rate: number

1+

27

Estructura tipo regla

• <antecedente> <símbolo-conexión> <consecuente>

• Ejemplo de regla

depósito-combustible.status = vacíoCAUSA

combustible-en-motor.status = false

28

Relaciones entre expresiones

Fragmentos de conocimiento en el dominio de la diagnosis de automóviles

fusiblefundido

bateríabaja

inspección fusibleroto

depósito combustiblevacío

indicador bateríacero

indicador combustiblecero

potenciadesconectada

combustible en motorfalso

comportamiento motorno arranca

comportamiento motorse para

1

2 3

4 56

78

9

29

Ejemplo reglas dependencia estado

RULE-TYPE dependencia-estado;

ANTECEDENT: estado coche no visible;

CARDINALITY: 1;

CONSEQUENT: estado coche;

CARDINALITY: 1;

CONECTION-SYMBOL:

causa

END RULE-TYPE dependencia-estado;

depósito-combustible.status = vacío => combustible-en-motor.status = false

Modela relaciones 2, 3, 6, 7, 8, 9

estado cocheno visible

estadocoche

1 1causa

dependenciaestado

30

Ejemplo reglas dependencia estado

RULE-TYPE dependencia-estado;

ANTECEDENT: estado coche;

CARDINALITY: 1;

CONSEQUENT: estado coche no visible;

CARDINALITY: 1;

CONECTION-SYMBOL:

causado-por

END RULE-TYPE dependencia-estado;

combustible-en-motor.status = false => depósito-combustible.status = vacío

Modela relaciones 2, 3, 6, 7, 8, 9

estadocoche

1 1Causado-por

dependenciaestado

estado cocheno visible

31

Ejemplo reglas manifestación

RULE-TYPE regla-manifestación;

DESCRIPTION: “Regla que establece la

relación entre un estado interno y su

comportamiento externo en términos de

un valor observable”;

ANTECEDENT: estado coche no visible;

CONSEQUENT: observable coche;

CONECTION-SYMBOL: se-manifiesta;

END RULE-TYPE regla-manifestación;

batería.status = baja => indicador-batería.valor = cero

estado cocheno visible

observablecoche

1 1semanifiesta

reglamanifestación

Modela relaciones 1, 4, 5

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

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;

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;

35

Sintaxis CMLConocimiento 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

36

Sintaxis CMLConocimiento 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”