Ingeniería de Conocimiento 5º curso Ingeniería Informática

Transcripción

1 1 Ingeniería de Conocimiento 5º curso Ingeniería Informática Ingeniería de Conocimiento Curso 2011/12

2 2 Modelo del Conocimiento dependiente del dominio Conocimiento del Dominio Conocimiento Inferencial Independiente del dominio Conocimiento de la Tarea Conocimiento e información estáticos relevantes del dominio Equivale al modelo de datos o al modelo de objetos en IS Pasos básicos de razonamiento Equivale al nivel de descomposición funcional más bajo en IS Qué y Cómo Orientado a la meta Aplica las inferencias al conocimiento del dominio para lograr los objetivos Curso 2011/12 Ingeniería de Conocimiento

3 3 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Tarea Método Tarea Curso 2011/12 Ingeniería de Conocimiento

4 Describe metas, como por ejemplo: asesorar la suscripción de una hipoteca para minimizar el riesgo de perder dinero. Diseñar un ascensor para un edificio nuevo Describe las estrategias que se pueden utilizar para realizar esas metas Se describe normalmente en modo jerárquico. Tareas-Métodos-Subtareas Tiene dos partes: La Tarea (TASK) y El Método de la tarea (TASK-METHOD). 4

5 Tarea (TASK): Define el objetivo del proceso de razonamiento que se está intentando modelar en función de las entradas y salidas. Asesorar la suscripción de una hipoteca para minimizar el riesgo Diseñar un ascensor para un edificio nuevo La diferencia principal con las funciones tradicionales es que los datos manipulados por la tarea se describen también independientemente del dominio. Por ejemplo, la salida de una tarea de diagnóstico médico no sería una enfermedad, sino un nombre abstracto, como categoría de avería 5

6 Método de la tarea (TASK-METHOD): Define la estrategia que hay que seguir Especificación de su descomposición tareas, inferencias y funciones de transferencia, y Especificación del control Descripción independiente del dominio. Ingeniería de Conocimiento Curso 2008/09 6

7 Task (Tarea) Task Method (Método tarea) Diagnosis Diagnosis mediante Generate-and-test ESTRUCTURA DE TAREAS descomposición cover predict Inferencias compare obtain Función transferencia 7

8 TASK Diagnosis GOAL: Encontrar la causa más probable que responda a la queja del usuario"; ROLES: INPUT: complaint: Queja acerca del comportamiento del sistema"; OUTPUT: fault-category: Una hipótesis que explique las evidencias encontradas"; evidence: Conjunto de observaciones que se obtienen durante el proceso diagnóstico"; SPECIFICATIONS: Encontrar un estado inicial que explique la queja y que sea consistente con las evidencias que se han encontrado"; END TASK diagnosis; 8

9 La descripción en la tarea es independiente del dominio----> Posibilidad de Reutilización del software Como vemos en el ejemplo, tenemos tres slots: Slot GOAL: descripción textual informal de la meta de la tarea Slot SPECIFICATION, que describe de manera textual e informal la relación entre la entrada y la salida de la tarea Slot ROLES La I/O se especifica en forma de roles funcionales, como en las inferencias. Diferencias: no hay roles estáticos. no hay mapeado de los roles en términos específicos del dominio. Los roles de las tareas tienen links a los roles inferenciales a través de la estructura de control. Cada tarea tiene un método asociado, que describe cómo se realiza ésta en términos de subtareas y/o inferencias 9

10 Describe cómo se realiza una tarea mediante su descomposición en subfunciones Indica cómo utilizar y aplicar al conocimiento del dominio las subtareas, inferencias y funciones de transferencia para alcanzar el objetivo Las subfunciones pueden ser otra tarea, inferencias o funciones de transferencia. Parte central del método: estructura de control (CONTROL- STRUCTURE) describe el orden de las subfunciones captura la estrategia de razonamiento que se emplea para resolver el problema pequeño programa, subfunciones=procedimientos y roles= parámetros de los procedimientos puede definir roles de tareas adicionales, que se usan para almacenar resultados temporales 10

11 TASK-METHOD diagnosis-trough-generate-and-test; REALIZES: Diagnosis; DESCOMPOSITION: INFERENCES: cover, predict, compare; TRANSFER-FUNCTIONS: obtain; ROLES: INTERMEDIATE: hypothesis: Una solución candidato ; expected-finding: El hecho que se predice, en el caso de que la hipótesis sea cierta"; actual-finding: El hecho que se observa"; result: El resultado de la comparación CONTROL-STRUCTURE: WHILE NEW-SOLUTION cover (complaint -> hypothesis); DO predict (hypothesis -> expected-finding); obtain (expected-finding -> actual-finding); evidence := evidence ADD actual-finding; compare (expected-finding + actual-finding -> result); IF result== equal; THEN break from loop ; END IF END WHILE IF result== equal; THEN fault-category:= hypothesis; ELSE no solution found ; END IF END TASK-METHOD diagnosis-trough-generate-and-test; (cont.) 11

12 Llamadas a procedimientos Invocación de tareas, inferencias, funciones de transferencia Operaciones de datos sobre valores de roles Asignar un valor a un rol, sumar/añadir, restar/borrar, recuperar,.. Primitivas de control repeat-until, while-do, foreach-do, if-then-else Condiciones: expresiones lógicas sobre roles: until diferencial = vacío dos condiciones especiales: Has-solution invocación de inferencia que puede fallar New-solution invocación de inferencia que puede tener éxito varias veces 12

13 start diagnosis through Generate-and-test cover [result= not equal] [no más soluciones de cover] No solución New solution de cover] predict [result = equal] Solución encontrada obtain compare 13

14 14 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Inferencias Roles de Conoc. Func. Transferencia Curso 2011/12 Ingeniería de Conocimiento

15 Describe el nivel inferior de descomposición funcional Describe cómo las estructuras estáticas del conocimiento del dominio se pueden usar para realizar el proceso de razonamiento Permite la reutilización del conocimiento Los elementos principales son: Inferencias----razonamiento. Unidades básicas de procesado de información Funciones de transferencia--- comunicación con otros agentes Roles de conocimiento --- relación indirecta con el conocimiento del dominio 15

16 La característica que distingue a las inferencias de las funciones tradicionales es la forma en la que se definen los datos sobre los que operan La E/S de las inferencias se describen en forma de roles funcionales. Nombres abstractos que indican el rol en el proceso de razonamiento. Se llaman roles de conocimiento Dinámicos son la E/S de la inferencia en tiempo de ejecución. Estáticos son estables en el tiempo especifican la colección de conocimiento del dominio que se usa para poder realizar la inferencia. 16

17 Entrada rol dinámico inferencia Rol salida dinámico Complaint cover Hypothesis Mi coche no arranca Tanque de gasolina vacío causal model Rol estático Tanque de gasolina vacío lleva a falta de gasolina en motor Si no hay gasolina en el motor, entonces el coche no enciende 17

18 Completamente descrita a través de una especificación declarativa de propiedades de su E/S. Los procesos internos de la inferencia son una caja negra carencia de interés para el modelado de conocimiento. E/S descrita usando nombres de roles funcionales, que no son parte del esquema del dominio (modelo de datos) 18

19 Nombre funcional para elementos dato/conocimiento. El nombre captura el rol del elemento en el proceso de razonamiento. Mapeado explícito a los tipos del dominio Rol dinámico: variantes E/S Rol estático: entrada invariante una base de conocimiento 19

20 INFERENCE cover; ROLES: INPUT: complaint; OUTPUT: hypothesis; STATIC: causal-model; SPECIFICATION: Cada vez que se invoca esta inferencia, se genera un candidato solución que puede haber causado la queja. La salida debe ser, por tanto, un estado inicial en el circuito de dependencia de estados que debe explicar causalmente la queja de entrada ; END INFERENCE cover; 20

21 KNOWLEDGE-ROL complaint; TYPE: DYNAMIC; DOMAIN-MAPPING: visible-car-state; END KNOWLEDGE-ROL complaint; KNOWLEDGE-ROL hypothesis; TYPE: DYNAMIC; DOMAIN-MAPPING : invisible-car-state; END KNOWLEDGE-ROL hypothesis; Ingeniería de Conocimiento Curso 2008/09 21

22 KNOWLEDGE-ROL modelo- causal; TYPE:STATIC; DOMAIN-MAPPING: dependencia-estado FROM circuito-coche; END KNOWLEDGE-ROL modelo-causal; invisible Car state 1 1 causa Car state dependencia estado Ingeniería de Conocimiento Curso 2008/09 22

23 observable coche valor universal Car state estado: universal observable: booleano invisible car state visible car state Dial gas Dial batería fuse observable: {false} observable: {true} valor: valor dial valor: valor dial status: {normal, blown} Inspección fusible Valor: {normal, roto} battery status: {normal, bajo} fuel tank power status: {on, engine behavior off} status: {normal, does-not-start, gas in engine stops} status: {full, status: boolean almost-empty, empty} 23

24 invisible car state 1 1 causa Car state dependencia estado invisible car state 1 tiene manifestación 1 Visible car state manifestación regla 24

25 RULE_TYPE manifestación- regla; DESCRIPTION: Regla que establece una relación entre un estado interno y un comportamiento externo en términos de un valor observable ; ANTECEDENT: invisible-car-state; CONSEQUENT: Visible-car-state; CONNECTION-SYMBOL: tiene-manifestación; END TIPO-DE-REGLA manifestación- regla; 25

26 Conoc. Inferencial Complaint cover hypothesis Mapeado Inferencia-dominio causal model Visible car state concepto Conoc. Dominio Dependencia estados Tipo de regla Invisible car state concepto 26

27 Inferencias Describen procesos de razonamiento primitivo Nivel más bajo de descomposición funcional Referencia indirecta al Dominio Permite la reutilización de conocimiento Roles Etiquetas abstractas que indican el papel que juega el conocimiento en el proceso de razonamiento Roles Dinámicos Roles Estáticos complaint caso cover abstr aer hypothesis caso abstraído Paciente con mareos Edad del usuario es 17 Coche no arranca Temperatura del paciente es 38.7º Problema en el oído interno Usuario es adolescente Batería agotada Paciente con fiebre 27

28 Roles dinámicos queja cubrir hipótesis Rol estático Modelo causal INFERENCE cubrir; OPERATION TYPE : COVER; ROLES : INPUT : queja ; OUTPUT : hipótesis; STATIC : modelo-causal; SPECIFICATION : Cada vez que se activa, genera un c onjunto de posibles causas al fallo introducido como entrada ; END INFERENCE cubrir; 28

29 Conocimiento inferencial Rol dinámico de entrada caso inferencia abstrae r Rol dinámico de salida caso abstraido Conocimiento de abstracción Rol estático Conocimiento del dominio solicitud Reglas abstracción solicitud Correspondencia Inferencia-dominio 29

30 caso abstrae r Conocimiento de abstracción caso abstraido KNOWLEDGE-ROLE conocimiento - abstraccion ; TYPE: STATIC; DOMAIN-MAPPING: regla- abstracción FROM asesoramiento-ordenador ; END KNOWLEDGE-ROLE conocimiento - abstraccion ; KNOWLEDGE-ROLE caso ; TYPE: DYNAMIC DOMAIN-MAPPING: solicitud ; END KNOWLEDGE-ROLE caso ; KNOWLEDGE-ROLE caso-abstraído ; TYPE: DYNAMIC DOMAIN-MAPPING: solicitud ; END KNOWLEDGE-ROLE casoabstraído ; 30

31 Ventajas de la utilización de roles en la especificación Se desacopla la especificación del Conocimiento del Dominio del de Inferencias Posibilita llevar ambas especificaciones en paralelo Vocabulario sobre cómo se utiliza el conocimiento independientemente del dominio de aplicación Reutilización A diferencia de la IS no se necesita una especificación detallada de las inferencias Son cajas negras descritas a través de sus entradas y salidas 31

32 Transfiere un item de información entre el agente de razonamiento del modelo de conocimiento y otro agente del mundo externo (usuario, otro sistema,..) desde el punto de vista del modelo de conocimiento es un caja negra: sólo interesa su nombre y su E/S la especificación detallada de las funciones de transferencia es parte de otro modelo, el de comunicación nombres estándar: OBTAIN, RECEIVE, PRESENT, y PROVIDE. 32

33 Iniciativa sistema Iniciativa externa TRANSFER-FUNCTION obtener; TYPE: OBTAIN; ROLE: INPUT: observable; OUTPUT: hallazgo; END TRANSFER-FUNCTION obtener; Información externa OBTAIN RECEIVE Información interna PRESENT PROVIDE 33

34 La combinación de los diferentes conjuntos de inferencias especifica la capacidad inferencial básica del sistema en desarrollo. El conjunto de inferencias se puede representar gráficamente en una Estructura Inferencial. Enfásis en los aspectos dinámicos del flujo de datos---> Roles estáticos opcionales 34

35 complaint Roles conoc. dinámicos cover Inferencias Rol estático F.de transferencia causal model Obtain Real fact hypothesis generate Expected fact compare Manifestation model result 35

36 Son una representación abstracta de los posibles pasos del proceso de razonamiento Vehículo importante de comunicación durante el proceso de desarrollo A menudo son provisionales Suele ser útil realizar anotaciones con ejemplos específicos del dominio. Define las capacidades inferenciales del sistema, el vocabulario y las dependencias para el control, pero no el control en sí, del que se ocupa el conocimiento de la tarea 36

37 complaint motor no enciende Reglas Dependencia estado Dial gasol= normal cover Causal Model Obtain Real fact hypothesis Tanque gasolina vacío generate Expected fact Dial gas= cero/bajo compare Reglas de manifestación Manifestation Model No igual result 37

38 Plantilla inferencial: especifica las capacidades de razonamiento básicas del sistema caso obtener abstr aer Modelo causal caso abstraído especi ficar normas selecci onar Normas específicas caso decisión encaj ar evalu ar valor - norma norma 38

39 caso Datos sobre el cliente y sus preferencias, p.e., usuario de 32 años quiere un portátil PC compatible para uso científico abstrae r caso abstraíd o Modelo causal usuario.edad= 32 años se abstrae en usuario.categoría-edad = joven decisión Normas específicas caso procesador-mobile especific ar encajar Procesador = tipo mobile pentium GHz Criterios como necesidades-memoria necesidadesprocesador normas evaluar valor - norma seleccion ar norma Un único criterio, p.e., necesidadesprocesador tipo-ordenador = PC compatible necesidades-procesador= alta procesador-mobile = true 39

40 Estado ideal: disponer de un conjunto estándar de inferencias Usar nombres estándar en lo posible 40

41 Si el comportamiento interno de una función es importante para explicar el comportamiento del sistema como un todo, entonces es necesario definir esta función como una tarea Durante el desarrollo: estructuras inferenciales provisionales Función = tarea o inferencia (o función de transferencia) 41

42 TASK-KNOWLEDGE identificador Descripción de tareas y métodos de tareas END TASK-KNOWLEDGE INFERENCE-KNOWLEDGE identificador; Especificación de inferencias; Especificación de roles de conocimiento; Especificación de funciones de transferencia; END INFERENCE-KNOWLEDGE identificador; 42

43 43 Modelo del Conocimiento dependiente del dominio Conocimiento del Dominio Conocimiento Inferencial Independiente del dominio Conocimiento de la Tarea Conocimiento e información estáticos relevantes del dominio Equivale al modelo de datos o al modelo de objetos en IS Pasos básicos de razonamiento Equivale al nivel de descomposición funcional más bajo en IS Qué y Cómo Orientado a la meta Aplica las inferencias al conocimiento del dominio para lograr los objetivos Curso 2011/12 Ingeniería de Conocimiento

44 44 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Curso 2011/12 Ingeniería de Conocimiento

45 Describe la información estática más importante y los objetos de conocimiento en un determinado dominio. Tiene dos partes: Esquema del dominio Describe la estructura estática de la información/conocimiento a través de definiciones tipo comparable al modelo de datos/modelo de objetos en IS definido a través de los constructos del dominio Base de conocimiento contiene instancias de los tipos que se especifican en el esquema del dominio (es decir, es un conjunto de instancias de conocimiento) comparable al contenido de una bbdd 45

46 46 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla Constructos Curso 2008/09 Ingeniería de Conocimiento

47 La mayoría son similares a los de O-O, en especial a los diagramas de clases Se incluyen además otros constructos para cubrir aspectos específicos del modelado en SBC, como: Conceptos Relaciones Tipos de Regla Otros: SUPERTIPO/SUBTIPO-DE y AGREGADO/PARTE 47

48 Conceptos describen un conjunto de objetos o instancias del dominio que comparten características similares. como clases de objetos, pero sin operaciones ni métodos de O-O Relaciones como las Asociaciones en O-O Atributos valores primitivos. Características de los conceptos Tipos de reglas introduce expresiones => no hay equivalente en IS 48

49 Concepto describe un conjunto de objetos o instancias. Ej: batería (concreto) o diseño del coche (abstracto) Las características de los constructos se definen mediante Atributos (attribute) Un atributo puede tener un Valor (value) Los valores son atómicos y se definen a través de un Tipo de Valor (value type), que establece los valores permitidos para el atributo (booleano, real, etc). El value type universal permite cualquier valor Por defecto, cardinality es

50 Dialgasolina Value: valor-dial Tanque gasolina status: {lleno, casi-vacío, vacío} CONCEPT dial gasolina; ATRIBUTTES: value: valor-dial; END CONCEPT dial gasolina; VALUE-TYPE valor-dial; VALUE-LIST {cero, bajo, normal}; TYPE: ORDINAL; END VALUE_TYPE valor-dial; CONCEPT tanque gasolina; ATRIBUTTES status: {lleno, casi-vacío,vacío}; END CONCEPT tanque gasolina; 50

51 manzana color: {amarillo, verde, rojo} Podrida: boolean Brillante: boolean Forma. {redonda, ovalada} Tiene-clase Clasemanz. Los conceptos son el punto de comienzo para el modelado del conocimiento Granny Smith: Clase manzana Grey Reinet: Clase manz. Golden Delicious: Clase manzana Present of England: Clase manzana 51

52 CONCEPT cliente; DESCRIPTION: Un posible cliente ; ATTRIBUTES: nombre: STRING; domicilio: STRING; edad: NATURAL;... AXIOMS: edad>=18; END CONCEPT cliente; cliente nombre: STRING; domicilio: STRING; edad: NATURAL; CONCEPT datos-solicitud; DESCRIPTION: Una solicitud de un cliente ; ATTRIBUTES: edad-usuario: NATURAL; categoría-edad: valorcategoría; uso: {científico, CAD,...} CARDINALITY: 3; inversión: NATURAL;... AXIOMS: 850<= inversión <=3.000; END CONCEPT datos-solicitud; VALUE-TYPE valor-categoría; TYPE: ORDINAL; VALUE-LIST: (infantil, adolescente, joven, maduro, tercera edad); END VALUE-TYPE valor-categoría; 52

53 53 Modelo del conocimiento Conoc. Dominio Conoc. Inferencia Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla Curso 2011/12 Constructos Ingeniería de Conocimiento

54 El modelado soporta las especificación de relaciones de generalización/ especificación. Los conceptos se pueden agrupar en jerarquías mediante el constructo SUBTYPE-OF. Se coloca en la definición del subconcepto. Los subconceptos heredan los atributos y relaciones del supertipo. Pueden tener más atributos y relaciones propios. La definición de subtipos no está limitada a los conceptos, también valdría para las relaciones. Ej. Una relación propiedad de un vehículo podría especializarse en propiedad-coche y propiedad-bicicleta. 54

55 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; 55

56 Car observable valor universal Car state estado: universal observable: booleano invisible car state observable: {false} visible car state observable: {true} Dial gas valor: valor dial Dial batería valor: valor dial fuse status: {normal, blown} Inspección fusible Valor: {normal, roto} battery status: {normal, bajo} fuel tank power status: {on, engine behavior off} status: {normal, does-not-start, gas in engine stops} status: {full, status: boolean almost-empty, empty} 56

57 Esquema del Dominio. Relación especialización/generalización portátil marca: STRING; modelo: STRING; Duración-batería: REAL; CONCEPT portátil; DESCRIPTION: ordenador portátil ; SUB-TYPE-OF: ordenador; ATTRIBUTES: duración-batería: REAL; END CONCEPT portátil; ordenador marca: STRING; modelo: STRING; CONCEPT ordenador; DESCRIPTION: ordenador personal ; SUPER-TYPE-OF: portátil, sobremesa; SEMANTICS: DISJOINT: YES; COMPLETE: YES; ATTRIBUTES: marca: STRING; modelo: STRING; END CONCEPT ordenador; sobremesa marca: STRING; modelo: STRING; CONCEPT sobremesa; DESCRIPTION: ordenador no portátil ; SUB-TYPE-OF: ordenador; END CONCEPT sobremesa; 57

58 Esquema del Dominio. Relación de agregación módulo-memoria marca: STRING; capacidad: NATURAL; velocidad: NATURAL; ordenador marca: STRING; modelo: STRING; 1+ CPU marca: STRING; modelo: STRING; velocidad: NATURAL; CONCEPT módulo-memoria; DESCRIPTION: Memoria RAM ; PART-OF: ordenador; CARDINALITY: 1+; ATTRIBUTES: marca: STRING; capacidad: NATURAL; velocidad: NATURAL; END CONCEPT módulo-memoria; CONCEPT ordenador; DESCRIPTION: ordenador personal ; HAS PARTS: CPU, modulo-memoria; ATTRIBUTES: marca: STRING; modelo: STRING; END CONCEPT ordenador; CONCEPT CPU; DESCRIPTION: Procesador ; PART-OF: ordenador; ATTRIBUTES: marca: STRING; modelo: STRING; velocidad: NATURAL; END CONCEPT ordenador; 58

59 Pueden utilizarse en forma similar al diagrama entidadrelación Las relaciones entre conceptos se definen con el constructo RELATION o BINARY RELATION. Se definen a través de la especificación de ARGUMENTOS (ARGUMENTS) la CARDINALIDAD (CARDINALITY) se define para cada uno de los argumentos, y su valor de defecto es 1. También se puede especificar un ROL (ROLE) para cada argumento Las relaciones, al igual que los conceptos, también pueden tener ATRIBUTOS (ATRIBUTES) 59

60 a) Argumento Argumento coche 0+ pertenencia 0-1 Cardinal. Relación persona No direccional BINARY_RELATION pertenencia; ARGUMENT -1: coche; ARGUMENT-2: persona; CARDINALITY: ANY; END BINARY_RELATION pertenencia; 60

61 b) coche persona Propiedad-de Direccional BINARY_RELATION propiedad-de INVERSE: posee ARGUMENT-1: coche; CARDINALITY: ANY; ARGUMENT-2: persona; CARDINALITY: 0-1; END BINARY_RELATION propiedad_de; 61

62 coche 0+ 1 persona propiedad Fecha adquis:fecha; BINARY-RELATION propiedad; ARGUMENT-1: coche; ARGUMENT-2: cliente; CARDINALITY: ANY; ATTRIBUTES: fecha-adquisición: tfecha; END BINARY-RELATION: propiedad; 62

63 agente nombre situación paciente nombre diagnóstico situación departamento hospital observable tipo observación valor fecha hora 63

64 Modelo del conocimiento Conoc. Dominio Conoc. Inferencia Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla 64

65 1 fusible Quemado 2 3 Inspección fusible Roto batería baja 4 5 Dial batería cero 6 Dial tanque cero Tanque gasolina vacío encendido off gasolina en motor falso Comportamiento motor No enciende Comportamiento motor para 65

66 Las reglas son una forma natural y común de conocimiento simbólico. Cómo representar dependencias entre los conceptos en un modelo de datos tradicional? Tanque.gasolina=vacío-->Gasolina.motor=false Indica una relación lógica entre dos declaraciones lógicas. Típicamente expresiones sobre el valor de un atributo de un concepto. Para modelar la estructura de las reglas se utiliza el constructo Tipo de Regla. Son un tipo especial de relación. 66

67 Es similar a una relación, dónde antecedente y consecuente no son instancias de conceptos, sino expresiones de esas instancias. Se modela una relación entre expresiones acerca de los valores de los atributos. dial-gasolina.valor= cero -> tanque -gasolina.estado = vacío Se modelan un conjunto de reglas de estructura similar Las relaciones no son estrictamente lógicas, es necesario especificar un Simbolo de Conexión entre antecedente y consecuente. 67

68 Es una de las diferencias más importantes con los Modelos de Datos de la IS. Modelan relaciones entre dos expresiones lógicas sobre los atributos de los conceptos. Permiten estructurar el conocimiento adquirido del experto. El análisis del conocimiento se centra en encontrar reglas con una estructura común. 68

69 persona 1+ nombre: string sueldo: integer limita préstamo cantidad: integer interés: number Límite préstamo Persona.sueldo <= 10,000 LIMITA Préstamo.cantidad<= 2,000 Persona.sueldo> 10,000 AND persona.sueldo <= 20,000 LIMITA Préstamo.cantidad<= 3,000 69

70 <antecedente> <símbolo-conexión> <consecuente> Ejemplo: alimentación-gasolina.estado=bloqueada CAUSA gasolina-en-motor.estado= falso; uso flexible de cualquier tipo de dependencia tipos múltiples para antecedente y consecuente 70

71 invisible Car state 1 1 causa Car state dependencia estado invisible car state 1 tiene manifestación 1 car observable manifestación regla 71

72 RULE_TYPE manifestación regla; DESCRIPTION: Regla que establece una relación entre un estado interno y un comportamiento externo en términos de un valor observable ; ANTECEDENT: invisible-car-state; CONSEQUENT: Car-observable; CONNECTION-SYMBOL: tiene-manifestación; END TIPO-DE-REGLA regla-manifestación; 72

73 Regla-1 : Si el cliente normalmente utiliza software científico (tipo MATLAB) entonces necesitará como mínimo 256MB de memoria RAM y un procesador Pentium IV a 1.4 Ghz o similar solicitud indica Reglas indicacione s ordenador RULE-TYPE reglas- indicaciones ; ANTECEDENT: solicitud ; CONSEQUENT: ordenador ; CONNECTION-SYMBOL: indica ; END RULE-TYPE reglasindicaciones ; Utilizan relaciones materializadas como conceptos Se benefician de las relaciones de especialización y agregación 73

74 IMPORTANTE!!! El concepto de regla que utilizamos aquí no implica la utilización de este formalismo en la implementación La representación final de este conocimiento en nuestro sistema software se decidirá más tarde durante la fase de diseño Las reglas en este nivel sólo son un vehículo de análisis para capturar dependencias lógicas que puedan ocurrir en el dominio 74

75 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla 75

76 DOMAIN-SCHEMA asesoramiento-ordenador; Especificación de conceptos; Especificación de relaciones; Especificación de atributos; Especificación de tipos de reglas; END DOMAIN-SCHEMA asesoramiento_ordenador; 76

77 Importar todas las construcciones definidas en otro(s) esquema(s): DOMAIN-SCHEMA asesoramiento-ordenador; USES: componentes-del-ordenador; /* esquema importado */... END DOMAIN-SCHEMA asesoramiento-ordenador; Importar sólo algunas construcciones definidas en otro(s) esquema(s): DOMAIN-SCHEMA asesoramiento-ordenador; USES: módulo-memoria, CPU FROM componentes-del-ordenador; categoría-edad FROM características-cliente;... END DOMAIN-SCHEMA asesoramiento-ordenador; 77

78 78 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla Curso 2011/12 Constructos Ingeniería de Conocimiento

79 = partición conceptual de la BC contiene instancias de los tipos de conocimiento definidos en el esquema del dominio Las instancias de los tipos-de-reglas contienen reglas. La especificación de una base de conocimiento tiene dos partes: el slot USES: <tipos usados> de <esquema> el slot EXPRESSIONS: <instancias> representación instancias: semiformalmente, con el símbolo de conexión separando antecedente y consecuente formalmente 79

80 . Slot USES: < tipos usados > FROM < esquema > T ipo (s) de conocimiento sobre los que se van a definir las ocurrencias KNOWLEDGE-BASE conocimiento- implicación ; USES : regla s - indicaciones FROM asesoramientoordenador ;... Slot EXPRESSIONS: < ocurrencias > solicitu indic EXPRESSIONS : d a datos-solicitud. uso = científico Reglas INDICA indicacione módulo-memoria. capacidad >= 256 ; s... END KNOWLEDGE-BASE conocimiento- implicación ; ordenado r 80

81 KNOWLEDGE_BASE red-coche; USES: dependencia-estado FROM esquema-diagnóstico-coche; manifestación-regla FROM esquema-diagnóstico-coche; EXPRESSIONS:: /* dependencias estado*/ fusible. estado = quemado CAUSA motor.estado= off; batería.estado = baja CAUSA motor.estado= off; /* manifestation reglas */ fusible.estado= quemado TIENE-MANIFESTACIÓN fusible-inspección.valor = roto; batería.estado = bajo TIENE-MANIFESTACIÓN batería-dial.valor = cero;.. END KNOWLEDGE_BASE red-coche;. 81

82 Separación entre esquema del dominio y las bases de conocimientos Nueva definición de la Adquisición de Conocimiento: Definición de los tipos de conocimiento, como los tipos de reglas. Definición de las ocurrencias, y colocarlas en la base de conocimiento. 82

83 Modelo del conocimiento Conoc. Dominio Conoc. Inferencial Conoc. Tarea Esquema Dominio Base de Conoc. Conceptos Relaciones Tipos de regla 83

84 DOMAIN-KNOWLEDGE identificador; DOMAIN-SCHEMA identificador; Especificación de conceptos, atributos, relaciones y tipos de reglas ; END DOMAIN - SCHEMA identificador; KNOWLEDGE -BASE identificador; Ocurrencias de objetos del esquema END KNOWLEDGE -BASE identificador; END DOMAIN -KNOWLEDGE identificador; 84

85 Una ontología es una especificación explícita y formal de una conceptualización consensuada Es una descripción formal de conceptos en un dominio. El desarrollo de una ontología incluye: Definir clases en la ontología Colocar las clases en un jerarquía de taxonomías (subclase-superclase) Definir [slots atributos ] y describir los valores permitidos para esos [slots] Rellenar los valores de los slots con ejemplos. 85 Curso 2011/12 Ingeniería de Conocimiento

86 ESTADOS Identificación conocimiento ACTIVIDADES TÍPICAS - Familiarización con el dominio (fuentes de información, glosario, escenarios típicos) - Lista potencial de los componentes del modelo reutilizables (componentes relacionados con la tarea y con el dominio) Especificación conocimiento - Escoger plantilla de tarea (proporciona la descomposición inicial de la tarea) - Construir la conceptualización inicial del dominio (principales tipos de información del dominio) - Especificación completa del modelo del dominio (modelo del conocimiento con bases de conocimiento parciales) Refinado conocimiento - Validar modelo conocimiento (simulación en papel, prototipo de razonamiento del sistema) - Refinado de la base de conocimiento (completar las bases de conocimiento) 86

87 METAS: Validar el modelo del conocimiento Rellenar las bases de conocimiento ACTIVIDADES: Actividad Completar las bases de conocimiento. Actividad Evaluar el modelo de conocimiento. 87

88 El esquema contiene dos clases de tipos del dominio: tipos de información que tienen instancias que son parte de un caso.(filas en una BBDD) Tipos de conocimiento que tienen instancias que son parte de un modelo del dominio Meta de la tarea: encontrar TODAS las instancias del segundo tipo. Las instancias de los casos sólo se necesitan para los escenarios. 88

89 Rellenar también actúa como un test de validación del esquema. Usualmente no es posible definir bases de conocimiento completas y correctas en el primer ciclo. Las bases de conocimiento necesitan mantenimiento el conocimiento cambia con el tiempo Técnicas: incorporar herramientas de edición para actualización de BCs, usar transcripts, trazados, entrevistas estructuradas, aprendizaje automático, etc. 89

90 Interna verificación = validación interna está correcto el modelo? Externa validación = validación frente a los requisitos del usuario es el modelo correcto?" 90

91 Interna recorridos estructurados (walk-throuhgs) herramientas software que comprueban sintaxis Externa mucho más difícil y compleja técnica principal: simulación simulación en papel sistema prototipo 91

92 DOMINIO (escenario) the user says: the car does not start a possible cause is that the fuel tank is empty in that case we would expect the gas indicator to be low MODELO (mapeado) DIAGNOSIS: Complaint: enginebehavior.status = does-not-start COVER: hypothesis; fueltank.status = empty PREDICT: expected-finding: gas-dial.value = zer 92 EXPLICACIÓN Complaint is received, for which a diagnostic task is started One of the three possible causes is produced. The expected finding provides us with a way of getting supporting evidence for hypothesis Curso 2011/12 Ingeniería de Conocimiento

93 93

94 Punto de vista CKads: no es diferente del desarrollo El desarrollo del modelo es un proceso cíclico Los modelos actúan como repositorios de información continuamente actualizados Pero esto hace que los requisitos de las herramientas de soporte sean mayores herramientas de transformación 94

95 Especificación del modelo de conocimiento Lista de todas las fuentes de información que se usan. Lista de los componentes del modelo que tenemos en cuenta para reutilización. Escenarios para la resolución del problema de la aplicación a desarrollar Resultados de las simulaciones realizadas durante la validación Material de elicitación (apéndices) 95

96 Identificación del conocimiento familiarización con el dominio de aplicación Especificación del conocimiento análisis detallado del conocimiento ayudado por modelos de referencia Refinado del conocimiento completar el modelo de conocimiento validar el modelo de conocimiento 96

97 Puede requerirse retroalimentación (feedback) la simulación en el tercer estado puede llevarnos a cambios en la especificación Las bases de conocimiento pueden requerir la búsqueda de fuentes adicionales de conocimiento. Regla general: las retroalimentaciones son menos frecuentes cuando el problema de la aplicación se entiende bien y más aún si se han resuelto problemas similares. 97

98 98

99 99

100 Directrices elección plantilla: 100

101 Validar el modelo de conocimiento: 101