Post on 27-Jul-2018
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”