Aspectos metodológicos del desarrollo de SBCs · requieren a menudo de una interacción...

Dpto. Inteligencia Artificial.

UNIVERSIDAD NACIONAL DE EDUCACIÓN A DISTANCIA

Aspectos metodológicos del desarrollo de SBCs

Curso: 2004-05

Aspectos metodológicos del desarrollo de SBCs 1

1 Aspectos básicos del desarrollo de SBCs

1.1 Introducción al proceso de desarrollo de SBCs.

¿Por qué una metodología específica para SBCs? Algunos aspectos no difieren demasiado de la ingeniería del software: análisis de la información, gestión del proyecto, diseño modular, reusabilidad, etc. Problemas que ocurren frecuentemente en proyectos convencionales se amplifican en el caso de desarrollo de SBCs. Las aplicaciones se hacen enseguida muy complejas, tienen un mayor impacto en la estructura organizacional y requieren a menudo de una interacción hombre-máquina más sofisticada. Y también unos problemas propios, como el cuello de botella que supone la adquisición del conocimiento. Se hace realmente difícil extraer el conocimiento que un experto posee acerca de cómo realiza una cierta tarea eficientemente y de tal forma que el conocimiento pueda ser formalizado para su informatización.

Fases metodológicas:

• Identificación y Análisis del Problema • Adquisición y modelado del conocimiento • Reducción al nivel simbólico • Implementación • Validación y evaluación.

En este documento os centraremos en la adquisición y modelado del conocimiento pero sin perder de vista su reducción al nivel simbólico (diseño). Se hace una revisión histórica para comprender su evolución y los principios metodológicos que se han decantado desde los primeros planteamientos

1.2 Adquisición del conocimiento: Técnicas de elicitación

Adquirir o extraer el conocimiento desde las diversas fuentes para conseguir un sistema que reproduzca un comportamiento experto es un proceso que acompaña a todo el desarrollo, aunque bien es verdad que es al principio cuando más esfuerzo se pone en ello, en la identificación y análisis, y en el modelado. La realimentación sobre la adquisición desde las diferentes etapas de desarrollo es constante, pero es particularmente en el modelado, como veremos después, donde va a ser fundamental. El objetivo de esta etapa de adquisición es conseguir el material para el modelado. Pero conforme se va diseñando el modelo éste conduce a su vez la adquisición de más conocimiento.

En este apartado veremos diferentes técnicas clásicas que utiliza el ingeniero del conocimiento para adquirir conocimiento particularmente a partir de un experto humano , pero la interacción del mismo experto con el modelo que se va creando o se va identificando


2

(si se mira una estructura de modelo ya creada de partida o “template”) es fundamental para la velocidad y fiabilidad del desarrollo.

El método más empleado ha sido la entrevista, la charla con el experto. Se graba esta conversación, posteriormente se transcribe y se analiza para identificar elementos relevantes de conocimiento. Esto consume bastante tiempo y no proporciona las suficientes garantías de completitud del conocimiento adquirido. Para obtener la transcripción, se ha desarrollado métodos alternativos, algunos de ellos en el campo de la psicología, técnicas tales como “ordenación de fichas” [Shadbolt & Burton, 90], la “cuadrícula de repertorio” [Boose, 89] y la “cuadrícula escalonada” [Burton et al., 88]. La ventaja de estas técnicas estriba en que proporcionan categorizaciones y relaciones que aseguran un recubrimiento exhaustivo del conocimiento. A continuación describiremos estas técnicas así como algunas consideraciones acerca de las entrevistas con expertos.

Entrevistas: Como cualquier otra entrevista, puede hacerse con un guión previo o no. Una entrevista no estructurada tiene la ventaja de la naturalidad. El experto expresa, sin restricciones impuestas por formalismos, su modelo mental. Los problemas de este tipo de entrevista son obvios, a la falta de estructura le acompaña la ineficiencia y la no completitud. Ineficiencia en tanto que puede emplearse mucho tiempo en puntos no realmente relevantes para el sistema o no descritos de una forma concisa, quizá enrevesada, quizá en términos no estructurados. También se corre el peligro de que el experto no exprese conocimiento que es necesario hacer explícito pero que da por evidente (Fig. 1)

Cuadrícula escalonada. Este sistema usa preguntas predefinidas para intentar que el experto extienda sus jerarquías, sus clasificaciones, a su máxima extensión. Comenzando por un término del dominio, las preguntas pueden obtener superclases, subclases o miembros de clases que están relacionados con el objeto de partida. Algunas de las preguntas habituales son “Qué es término y un ejemplo”, ”Qué otros ejemplos de término_1 diferentes de término_2”. Así se va construyendo la taxonomía de los elementos del dominio.

Fig. 1 Ventana de la herramienta del paquete software PcPack1 que permite la edición de jerarquías.

Ordenamiento de fichas. Esta es una técnica muy simple en la que un experto categoriza fichas con términos del conocimiento del dominio. Se escriben los términos en fichas indexadas y se presenta al experto una pila de estas fichas. Se le pide que las clasifique en pilas de cualquier manera que les parezca relevante. Cuando termine, se toma nota de la clasificación resultante, se mezclan las fichas y se pide al experto que realice la clasificación de acuerdo a otro criterio. Así se obtiene un conjunto de clasificaciones de términos del dominio en una o más categorías (Fig. 2).

1 Es un producto de Epistemics LTD que permite la descarga desde http://www.epistemics.co.uk/products/download.html de una versión demo. Dispone de las principales herramientas de elicitación así como otras para el modelado.


http://www.epistemics.co.uk/products/download.html

Fig. 2 Ventana de la herramienta de ordenamiento de cartas perteneciente al paquete software PcPack.

Cuadrícula de repertorio. Es una técnica en la que un experto hace distinciones entre términos del dominio en determinadas dimensiones. Estas dimensiones son parecidas a las categorías generadas al ordenar fichas, excepto que se asume que son variables continuas. Son generadas normalmente por la técnica triádica, seleccionando tres términos del dominio al azar y pedir al experto que nombre la diferencia entre dos de ellas con la tercera. Así se clasifican todos los términos en cada dimensión, con lo que en la cuadrícula tenemos cada término categorizado en cada dimensión. Las clasificaciones en la cuadrícula pueden ser estudiadas estadísticamente, usando análisis cluster, para ver si el experto ha categorizado implícitamente en una determinada forma y podemos aprovecharla para obtener toda la jerarquía (Fig. 3).

4

Fig. 3 Ventana de la herramienta para la edición de una cuadrícula de repertorio del paquete software PcPack.

1.3 Adquisición del conocimiento: Modelado

La primera época de la Inteligencia Artificial (IA) aplicada, tras la inicial búsqueda heurística y micromundos formales, se centró en el desarrollo de lenguajes de representación del conocimiento que hicieran más fácil la elicitación y posterior uso en la inferencia. En general, cada forma de representación lleva asociada de forma natural un tipo de inferencia. Con este énfasis en el conocimiento se inicia el contacto de la IA con los problemas reales, en los que son necesarias soluciones eficientes y procesos de desarrollo sistemáticos. Sin embargo, esta primera época se centró en el prototipado rápido, en el uso de entornos de desarrollo muy orientados hacia una forma específica de representar e inferir, y con el convencimiento más o menos explícito de que la IA aplicada era un "arte". Algo que para cada caso, en cada tipo de conocimiento del dominio, debería resolver por procedimientos artesanos a partir de un cierto diálogo estructurado con el experto humano para "capturar" su conocimiento (Musen, 1993).

Mientras que la dimensión de estos prototipos experimentales no superó un cierto nivel y sus propósitos no salieron de la Universidad, los resultados fueron prometedores. Sin embargo, el intento de tránsito desde la esfera de la investigación al campo comercial no tuvo el éxito que era de esperar (Studer et al., 1998).

Emerge, entonces, la evidencia de la necesidad de una aproximación metodológica, que aborde la construcción de un Sistema Basado en Conocimiento (SBC) de forma más sistemática, partiendo de un modelado fuerte del conocimiento del dominio y de un conjunto


6

de especificaciones funcionales lo más claras, completas y precisas posible, y siguiendo con el resto de las fases de análisis y síntesis de forma similar a como actúan las ingenierías de la materia y la energía. Nace así el paso del "arte" a la Ingeniería del Conocimiento, de forma similar a como había surgido la Ingeniería de Software a partir de la crisis del desarrollo del software en general.

Ya dentro de la Ingeniería del Conocimiento, se convirtió en un tópico el considerar la adquisición del conocimiento como un "cuello de botella" en el desarrollo de SBCs. Desgraciadamente, no se miró con atención a la forma de trabajar propia de la Física y las Ingenierías de la Materia y la Energía, donde es evidente que la construcción de cualquier sistema tiene más leyes soporte, resultado del modelado previo de las relaciones causales entre las distintas variables observables. En computación debemos a Allen Newell y David Marr la introducción de los tres niveles de descripción de un cálculo (Nivel de Conocimiento, Nivel de los símbolos - el programa - y el Nivel Físico). La propuesta de Newell es más precisa que la de Marr, porque nos introduce el Nivel de Conocimiento por encima del programa, con lo que deja claro que la tarea de elicitar el conocimiento de un experto humano debe empezar por modelar un segmento del conocimiento de ese experto a nivel del conocimiento. Además, no debemos olvidar que la meta final es la versión operacional, computable, de ese modelo de conocimiento.

Así, se empieza a desbrozar el campo de la Ingeniería del Conocimiento dejando claro que los desarrollos metodológicos van encaminados a sistematizar y apoyar, primero el proceso de construcción de modelos y, posteriormente, la reducción de esos modelos a programas. Es decir, lo mismo que hace cualquier otra rama de la computación, solo que aquí tenemos que afrontar las dificultades propias de la tarea y de los peculiares dominios de la aplicación.

Una vez que queda clara la pretensión de convertir en ingeniería el proceso de modelar la solución de un problema y de hacer operacional de forma "automática" e inequívoca ese modelo, la metodología camina de forma más o menos explícita, en la línea de la teoría de sistemas, buscando primero la clasificación y descomposición de las distintas tareas, intentando construir bibliotecas de componentes reutilizables, proponiendo distintas formas de organización y uso de esas bibliotecas de acuerdo a un marco que permita la formulación del modelo. Es necesario el mismo rigor y precisión en la descripción al nivel del conocimiento que la que se requiere en la implementación, para conseguir un modelo ejecutable. El modelo en el nivel del conocimiento no por ser conceptual está obligado a ser ambiguo e impreciso. Más bien al contrario, cuanto más claro, preciso e inequívoco sea el modelo conceptual, más evidente será el proceso de reducción y, además, la interpretación será reversible.


Para la depuración y actualización del modelo operacional resultante se necesita que éste sea intuitivo y disponga de facilidades de explicación del razonamiento. Es fundamental para ello el mantenimiento de la estructura conceptual a través del diseño hasta la implementación, para que sean reconocibles todas y cada una de las estructuras del modelo de conocimiento en la codificación.

En la adquisición del conocimiento el impacto ha sido muy grande. Antes se comenzaba por la reglas que utiliza el experto, se preguntaba a éste en términos de un formalismo computacional. Ahora se puede discriminar más: ¿qué clase de modelo hace? La tarea, ¿se descompone en otras más elementales? ¿Siguen un patrón común diversas tareas?

“Existe un nivel distinto inmediatamente sobre el nivel simbólico y que es caracterizado por el conocimiento como medio y el principio de racionalidad como la ley de comportamiento. “ [Newell, 82]

La orientación clásica de adquisición del conocimiento, representación simbólica, implementación del prototipo, perfeccionamiento, se modifica a modelación conceptual, representación simbólica, arquitectura computacional, adquisición del conocimiento.

Modelos: “En su sentido más amplio: un modelo abstrae desde cierto aspecto de la realidad. Identifica objetos, relaciones, propiedades y atributos de los objetos, relaciones entre propiedades de objetos ” [Steels, 92]?, “La inteligencia surge de la capacidad de construir y usar modelos”, es decir de abstraer. Para Karbach “es una poderosa abstracción que permite reducir la complejidad de la realidad para focalizarse en ciertos aspectos” [Karbach et al., 90]. Para DeMarco, “Un modelo refleja, a través de la abstracción de detalle, la características relevantes del sistema en el mundo real” [DeMarco, 82]. Así se ponen de acuerdo en que un modelo usualmente hace referencia a la noción común de abstracción o idealización de un sistema del mundo real.

El modelado debe incluir al menos las siguientes actividades: elicitación del conocimiento no formalizado, normalmente de forma verbal, interpretación de los datos elicitados usando algunos marcos conceptuales, y la formalización de esas conceptualizaciones de tal forma que el programa posteriormente pueda hacer uso del conocimiento.

La vieja idea de intentar que el experto proporcione el conocimiento en forma de unas reglas que el ingeniero del conocimiento es capaz de implementar funciona en pocos casos. El experto, el ingeniero del conocimiento (IC) y el KBS debían compartir la misma visión en cuanto a métodos y a vocabulario. Si el experto mira el problema o el dominio de

8

una forma diferente, con unas estructuras diferentes, con distinto lenguaje, el sistema no funcionará.

Sin embargo mediante el modelado es diferente. El modelo muestra el comportamiento deseado y especificado en términos del mundo real. Así el desarrollo de un KBS es visto como la construcción de un modelo computacional con el comportamiento deseado, el exhibido por el experto.

1.3.1 Evolución histórica

El aspecto primordial de esta evolución es que la adquisición del conocimiento haya pasado de ser considerada como un proceso de "extracción por fragmentos" (Davis, 1979; Kidd, 1987), hasta su visión como tarea de modelado al nivel del conocimiento (Ford et al., 1993). Tanto que ha dado lugar ha considerar dos generaciones: 1ª Extracción por fragmentos y 2ª, Modelado.

Extracción por fragmentos (1ª Generación)

En los primeros sistemas basados en reglas la representación era plana, en un solo nivel. Los mecanismos de inferencia asociados a la solución de un problema (el razonamiento) eran las estrategias de recorrido del árbol de reglas implementado en un motor de inferencia. La adquisición del conocimiento suponía la transferencia directa desde el conocimiento del experto a la codificación en reglas. Se reconstruía el razonamiento del experto sobre el sistema computacional vía pequeños pasos inferenciales en forma de reglas, tomando como apoyo teórico el paradigma de sistemas de producción (Newell & Simon, 1972).

La representación según este formalismo fallaba en la captura de importantes distinciones conceptuales del conocimiento, impedía distinguir entre diferentes tipos de conocimiento (Clancey, 1983). Tal mezcla de tipos de conocimiento junto con la ausencia de adecuadas explicaciones de las reglas (explicaciones orientadas al sistema y no al dominio) hace el mantenimiento difícil y costoso. Estos sistemas describían el razonamiento con características de la implementación más que en términos de las estructuras del domino y procesos de razonamientos más globales.

De esta forma, la adquisición del conocimiento para un problema particular depende demasiado del experto (Freigenbaum, 1977), en contra de las características propias de la ciencia y la ingeniería, donde el resultado de un experimento no debe depender de quién lo realiza y el diseño de un puente o un amplificador, a partir de las especificaciones funcionales, tampoco debe depender del nombre del diseñador. Por u n lado, es el experto el que lleva su conocimiento a la base de reglas, sin casi intervención del ingeniero de conocimiento (IC). Por otro, la elicitación del conocimiento es incompleta por la cantidad de

conocimiento tácito (que no aparece pero existe) y dependiente del contexto. Hay autores que incluso niegan que se pueda llegar a conseguir (Dreyfus, 1979; Winograd & Flores, 1986).

Se planteó como soluciones:

- Subir el nivel de representación: Situación en un plano más cercano al experto e independiente del formalismo de representación e implementación.

- Reutilización de los métodos de resolver los problemas: Se definen métodos orientados a clases de problemas en donde se describe la organización típica del conocimiento.

Modelado del conocimiento (2ª Generación)

Newell (1981) propone el concepto de Nivel del Conocimiento donde el modelo del conocimiento es independiente de su implementación y se estructura según los diferentes tipos de conocimiento. Este nivel permite describir el razonamiento en términos de objetivos, acciones necesarias para alcanzarlos y conocimiento necesario para llevar a cabo estas acciones. No indica la representación y métodos de inferencia utilizados para resolver el problema. Inspirándose en el concepto del nivel de conocimiento, se comienza a estudiar los sistemas expertos intentando descubrir el modelo subyacente. Newell señala la necesidad de plantear modelos de forma separada a su representación en un nivel lógico superior en donde se describa el objetivo del razonamiento y el papel del conocimiento.

Niveles lógicos: ♦ N. Conocimiento: agente, conocimiento, metas, acciones.

♦ N. Simbólico: ordenador, símbolos, interpretación de instrucciones.

♦ N. Lógico: sistema digital, bits, operaciones lógicas y aritméticas.

♦ N. Circuito: sistema electrónico, voltajes, intensidades.

El término modelo habitualmente se entiende como abstracción explicita del sistema observado utilizando una representación formal. Aquí, el término se asigna al modelo del conocimiento que se atribuye a expertos de referencia para emular el comportamiento en resolución de problemas.

De esta forma, la adquisición del conocimiento se entiende como un proceso en el que el ingeniero del conocimiento crea un modelo del conocimiento de resolución de


problemas y explicación del experto de referencia, modelo que posteriormente, sobre estructuras y artefactos de representación, hará computacional (Fig. 4).

Resolución de problemas y explicación

Fig. 4 El modelado supone para el ingeniero de conocimiento la identificación y descripción de estructuras y procedimiento en la resolución del problema por el experto. Estas estructuras y procedimientos se interpretan en

términos de elementos de computación simbólica y en términos de inferencia computacional (mecanismos inferenciales).

El modelado del conocimiento proporciona una serie de ventajas:

• El sistema ofrece una visión de su arquitectura a alto nivel que mejora la comprensión del sistema

• Facilita la adquisición del conocimiento utilizando modelos genéricos que conducen el proceso

• Permite la validación a priori con el experto

• Construcción modular que facilita, a su vez, la validación y modificación

• Facilita la reutilización de módulos ya desarrollados para la construcción de otras aplicaciones

• Mejora las explicaciones

La idea de un patrón abstracto se va a desarrollar en los siguientes años en diferentes aproximaciones.

Clancey (1985) observa que en un buen número de sistemas basados en reglas éstas podían clasificarse según realizaran alguno de estos tres tipos de acciones inferenciales: abstrae, genera abstracciones a partir de los datos, asocia (match) las abstracciones con soluciones a un cierto grado de abstracción y especializa (o refina) estas soluciones hasta llegar a la solución. A partir de esto, mostró la existencia, más allá del formalismo utilizado, de un patrón inferencial abstracto implícito en MYCIN, que denominó Clasificación Heurística (Heuristic Classification, HC) (Fig. 5).

10

Solutiones abstractas match

Solución

Datos abstractos

refine

Datos

abstract

Fig. 5 Esquema inferencial de la clasificación heurística: descomposición en inferencias y papeles que desempeñan las entidades del dominio en la clasificación.

Así, las siguientes reglas constituirían un ejemplo de asociación entre expresiones del dominio sobre las que se apoyarían las inferencias abstract y match respectivamente.

IF está disponible el recuento completo de células sanguíneas y el número de células blancas es menor de 2500

THEN WBC bajo IF WBC bajo

THEN la siguiente bacteria podría causar la infección: E.coli (0.75) Pseudomonas-aeruiginosa (0.5) Klebsiella-pneumoniae (0.5)

Hay dos ventajas fundamentales en el análisis en términos de estructura de inferencia. Primeramente muestra que hay una buena cantidad de estructura que subyace en las reglas, incluyendo parte que se asume estando oculta. Hacer explícita esta estructura subyacente es importante para mantener la base de reglas, explicarla a otros o en la fase de adquisición del conocimiento del experto. Segundo, muestra la similitud entre sistemas expertos construidos para un dominio aparentemente amplio y las tareas. Clancey analizó la estructura de inferencias subyacente en una serie de sistemas expertos y mostró cómo el marco de la clasificación heurística podía aplicarse a cada uno de ellos. Esto mostró que la estructura de inferencia es una de las formas que pueden usarse para analizar una tarea y detectar su método subyacente de la solución.

Clancey proporciona también el concepto de diferenciación de papeles, que hacía posible describir el método de solución de un problema de forma genérica en términos de los papeles que juega el conocimiento del dominio en el método. Si aplicamos la clasificación heurística a diferentes dominios, en un caso hablaremos de categorías de


12

mariposas y en otro de minerales, pero en ambos casos, en el esquema inferencial de la clasificación heurística, juegan el papel de soluciones abstractas.

Esto ya supone un patrón inferencial abstracto que participaría de una metodología-ingeniería para construir sistemas pasados en un análisis de la tarea. El análisis de la pericia en términos de tareas solía ser un problema completamente dependiente del dominio. Pero diversos investigadores observaron que todas las tareas podían ser incluidas en unas determinadas clases principales [Chandrasekaran, 1986]. En campos específicos, las tareas son, así, instancias de esas tareas genéricas. Se habló de clasificación, interpretación, diagnosis y construcción (planificación y diseño). En el diagnóstico de circuitos, vehículos o enfermedades hay elementos significativos en común, especialmente, el mismo método de resolución del problema y los mismos tipos de modelos del dominio.

El mismo método de resolución del problema. La misma descomposición de una tarea en subtareas más simples se puede encontrar en diferentes dominios, como el diagnóstico del que hemos hablado y hablaremos.

Los mismos tipos de modelos del dominio. Se encuentra el mismo tipo de modelo del dominio y, por tanto, la misma clase de inferencias operando sobre esos modelos del dominio, cuando se estudian tareas de la misma naturaleza genérica. Por ejemplo, la clasificación hace uso típicamente de un modelo de dominio en forma de una catálogo de prototipos organizados jerárquicamente. De forma parecida, el diagnóstico usa modelos causales y subtareas tales como “prueba a encontrar una causa más profunda” o “intenta eliminar parte de la red a partir de una observación”.

Tras esto, la idea es que tareas genéricas y sus métodos asociados podrían implementarse a un nivel genérico y estar disponibles como módulos de software que van a ser instanciados para aplicaciones específicas. Chandrasekaran (1986) define este concepto de tarea genérica (Generic Task, GT): Una GT identifica una tarea de utilidad general, un método para hacer la tarea y las clases de conocimiento que este método necesita. En (Chandrasekaran, 1986; Chandrasekaran, 1987) se identifican varias de estas tareas:

♦ Clasificación jerárquica: Clasificación a través de la "estrategia establece y refina". CSRL (Bylander & Mittal, 1986) es una herramienta que soporta esta tarea.

♦ Ensamblado abductivo: Construye una hipótesis que es la mejor explicación de una situación planteada. Se desarrolló para ello la herramienta PEIRCE (Punch et al., 1986).

♦ Asociación de hipótesis: Dado un concepto y una serie de características que describen un estado, valora el grado de adecuación del concepto al estado. En (Johnson, 1986) se da una descripción detallada de la herramienta HYPER que soporta esta tarea.

♦ Inferencia sobre bases de datos: Razonamiento sobre datos planos.

♦ Síntesis por planificación y refinamiento: Refinamiento de planes estructurales. DSPL (Brown & Chandrasekaran, 1986) soporta esta tarea.

♦ Abstracción de estados o paso de información dirigida por conocimiento: Dados los atributos de algunas entidades se determinan otros atributos no directamente conocidos pero que pueden inferirse de los iniciales. La inferencia "abstrae" de la HC de Clancey es un buen ejemplo de esto.

Posteriormente en (Chandrasekaran, 1990), el autor ya utiliza el término PSM como método de resolver la tarea diferenciado de ésta y propone (y describe) toda una familia de métodos "Propone-critica-modifica" para tareas de diseño.

En la Fig. 6 se muestra la descomposición de la tarea de diagnóstico en tareas genéricas según Chandrasekaran.

Clasificaciónjerárquica

Ensambladoabductivo

Asociación dehipótesis

Inferencia dedatos

Diagnosis

ObservacionesAbstracciones

Niveles de confianzade las hipótesis

Explicaciones plausibles

Requiere refinamiento dehipótesis

Fig. 6 Descomposición de la tarea de diagnóstico en tareas genéricas según Chandrasekaran.

El nombre de la tarea genérica clasificación jerárquica hace referencia al método usado para resolver la tarea, establece y refina, que asume la existencia de una jerarquía de categorías. En el diagnóstico médico, por ejemplo, la jerarquía se compondría de enfermedades, desde las más genéricas en la parte alta del árbol jerárquico, hasta las más específicas, en la parte baja.

El LAIR (Laboratory for Artificial Intelligence Research) de la Universidad de Ohio ha desarrollado un entorno (The Integrated Generic Task Toolset2) que integra herramientas basadas en diferentes GTs, como por ejemplo la clasificación jerárquica o la asociación de hipótesis.

2 http://www.cis.ohio-state.edu/lair/Projects/GTToolset/toolset.html


http://www.cis.ohio-state.edu/lair/Projects/GTToolset/toolset.html

14

La diferencia de la aproximación de Chandrasekaran con la de Clancey es de zoom. Éste proporciona la HC como la estructura compuesta de inferencias, mientras que Chandrasekaran la hubiera descompuesto en sus GTs componentes (cada inferencia como una subtarea). El propósito de Chandrasekaran era encontrar un número reducido de estas tareas genéricas para poder cubrir con ellas (con su composición) un amplio espectro de problemas.

McDermott (1988) centra su trabajo en el desarrollo de programas que pudieran adquirir automáticamente el conocimiento del experto del dominio. Así, desarrolló los denominados métodos limitadores de papeles (role-limiting methods, RLM) basados en estrategias tan generales como cubre-y-discrimina (aplicable en diagnóstico, por ejemplo) y el propone-y-revisa (para diseño). Son métodos que nos guían en la adquisición del conocimiento. Especifican los papeles que los diferentes tipos de conocimiento juegan en cada método. En este sentido es una aproximación históricamente importante puesto que pone en práctica el principio de diferenciación de papeles y su juego en la adquisición del conocimiento del dominio.

Son métodos unidos indisolublemente a una herramienta que los implementa y que puede ser usada por expertos sin ayuda de los ingenieros de conocimiento. Esto ha condujo inicialmente a la implementacion de 4 métodos sobre los que operan las correspondientes herramientas:

♦ Clasificación heurística: Según la descripción de Clancey. En ella se fundamenta la herramienta MORE (Kahn, 1988).

♦ Propone-Revisa: Se basa en este método por ejemplo la herramienta SALT (Marcus, 1988b) para problemas de síntesis heurística.

♦ Cubre-Discrimina: Para problemas de clasificación se ha desarrollado MOLE (Eshelman, 1988), sucesor de MORE, pero que trabaja directamente sobre modelos causales (ver Fig. 7).

♦ Extrapola-de-un-caso-similar: Para tareas de síntesis basada en casos. La herramienta SIZZLE (Offutt, 1988) se desarrolló para problemas de dimensionamiento. Otra herramienta, KNACK (Klinker, 1988), ayuda en realización de informes, acepta como entrada un informe completo de ejemplo y conocimiento acerca de los conceptos usados en el informe, generalización del ejemplo e instancia en los nuevos informes.

La principal diferencia con las anteriores aproximaciones es que este tipo de métodos venía completamente especificado, todas las tareas y subtareas eran especificadas hasta el nivel de operaciones primitivas. Así, por su estructura prefijada, se requiere que la tarea se ajuste a un RLM cuando la mayoría de tareas se solucionarían con una

combinación de RLMs. Posteriormente ha habido propuestas de mejora como la de “RLMs Configurables” (Poeck & Gappa, 1993) en la que los RLMs pueden ser descompuestos en diversas subtareas, cada una de las cuales, a su vez, puede ser resuelta por diversos métodos. En (Puppe, 1993) se aporta el estudio detallado de una clasificación de RLMs Configurables con descripción de aplicaciones que los implementan.

Discrimina

Cubre

Explicaciones

Síntoma

Síntomasdiferenciadores

Comprueba

Síntoma

NuevasExplicaciones

Infiere

Fig. 7 Estructura inferencial (a la manera de Clancey) del RLM "cubre-y-discrimina" aplicado a una tarea de diagnóstico (Duursma, 1993).

Musen y sus colegas (Musen, 1989) desarrollan Protégé, una herramienta para la adquisición de conocimiento en tareas de planificación, basada en un RLM denominado por él Refinamiento de Plan Episódico Estructural (Episodic Skeletal Plan Refinement). Pero, por el mismo problema de rigidez de los RLMs, la herramienta requiere inmediatamente de facilidades para un desarrollo más flexible y configurable del modelado, desembocando en la arquitectura Protégé-II (Puerta et al., 1992). Esta arquitectura apoya en la configuración del modelo a través de una biblioteca de métodos y mecanismos, y en la generación de herramientas para la adquisición del conocimiento específicas de la tarea.

En la línea de proporcionar elementos para la construcción del modelo, Breuker y Wielinga (1989) propusieron un conjunto de primitivas con las que modelar las tareas a modo de lenguaje de modelado para capturar el conocimiento del dominio. Su metodología KADS (Wielinga et al., 1992) propone por un lado partir desde abajo en un proceso de síntesis con estos elementos primitivos inferenciales y desde arriba en la contrapartida de análisis, con los denominados modelos de interpretación (Wielinga & Breuker, 1984), esquemas inferenciales genéricos que solucionan un determinado tipo de problema. Ha tenido gran influencia posterior su definición de modelo de pericia (Wielinga & Breuker,


16

1986) que diferencia el conocimiento experto en 4 tipos de conocimiento: estratégico, de tareas, inferencial y del dominio.

Steels3, a principios de los 90 (Steels, 1990; Steels, 1993), propone un marco metodológico que intenta integrar las aproximaciones anteriores (de los años 80) y sus avances, y que denominó Componentes de Pericia (Components of Expertise, CoE). En esta aproximación, la estructura de tareas específica la descomposición tareas/subtareas de tareas complejas, como el diagnóstico por ejemplo. Y esta descomposición depende del método utilizado para la tarea. Si el diagnóstico se lleva a cabo mediante la clasificación jerárquica, esto implica una descomposición de la tarea de diagnóstico en establece y refina. Para establecer una hipótesis se selecciona un método que supone otra consiguiente descomposición. Así hasta llegar a las primitivas cuyo nivel de abstracción o de compromiso con el dominio se haya decidido como opción de modelado. Steels introduce ésta y otras ideas que posteriormente van a adoptar otras aproximaciones (CommonKADS, por ejemplo), como por ejemplo la idea de múltiples modelos del dominio para la aplicación y la noción de la asociación tarea-métodos para la organización de bibliotecas. La Tabla 1 resume las características diferenciadoras entre los SBCs de 1ª generación (en general basados en reglas) y los de 2ª generación.

3 Steels es quien acuña el término de "segunda generación" de sistemas expertos (Steels, 1985)


1era. Generación 2da. Generación

Formalismo de representación característico

Reglas Dependiente del nivel

Categorías de conocimiento Hechos y reglas heurísticas

La diferenciación viene guiada por papeles genéricos de conocimiento

Metodología de Adquisición del Conocimiento

Codificación directa de conocimiento elicitado sobre el sistema de reglas

Basada en modelos a nivel del conocimiento

Niveles de descripción Descripción plana, en términos de reglas.

Múltiple (ej. conocimiento y simbólico)

Paradigma de Adquisición del Conocimiento

Transferencia de pericia en forma plana y granular

Construcción de modelos por interacción entre el ingeniero de conocimiento y el experto en el dominio

Paradigma cognitivo Sistemas de producción. Visión funcional del conocimiento

Reutilización Motor de inferencia Tareas, PSMs y modelos del dominio.

Tabla 1 Resumen con características de 1ª y 2ª generación de Sistemas Expertos, adaptado de (Motta, 1997).

1.3.2 Resultados de la evolución

Como resultado de esta evolución en el modelado del conocimiento emergen dos conceptos fundamentales: Métodos de Solución de Problemas (Problem Solving Methods, PSM) y Ontologías, y un conjunto de principios de modelado:

1.3.2.1 Métodos (PSMs)

El PSM describe cómo se realiza una tarea (la tarea describe el qué, el objetivo y el método cómo alcanzarlo). Un PSM especifica la descomposición de una tarea en subtareas, el flujo de datos entre ellas con los papeles que juegan los elementos del dominio y el control en la secuencia de las subtareas.

Si anteriormente los mismos mecanismos de representación e inferencia se utilizaban para los diferentes tipos de conocimiento, ahora los PSMs se abstraen de un formalismo de representación específico y se diferencian de los motores de inferencia genéricos o mecanismos de inferencia, que se apoyan en mecanismos de representación determinados: reglas, marcos, etc.

Por otro lado, los PSMs describen el conocimiento de control independientemente del dominio de la aplicación, posibilitando su reutilización en diferentes dominios y aplicaciones.

18

Se han desarrollado diferentes bibliotecas en las diferentes aproximaciones que proporcionan distintos grados de apoyo en su reutilización para la construcción de nuevos KBSs. Entre ellas difieren en dimensiones tales como universalidad, formalización, granularidad y tamaño (Studer et al., 1998), desde procedimientos terminados hasta componentes con los que construir métodos de mayor nivel, y difieren en su organización.

La aplicabilidad de un PSM a un problema particular viene determinada por dos aspectos principales: la competencia del método para obtener el objetivo de la tarea y la disponibilidad del suficiente conocimiento del dominio para conseguir ese objetivo con ese PSM. La selección del método (Motta & Zdrahal, 1998) supone su adecuada caracterización y clasificación (Ten Teije & Van Harmelen, 1998) en la biblioteca, cuya organización y procesado automatizado es una línea de trabajo abierta (Fensel & Bejamins, 1998a). Pero una vez seleccionado el método es posible su configuración o adecuación a una aplicación particular (Ten Teije et al, 1998).

En resumen se puede dar la siguiente estructura para la especificación de los distintos PSMs (Benjamins et al., 1996):

♦ Especificacion funcional. Descripción declarativa del comportamiento en términos de sus entradas/salidas. Describe qué se puede conseguir con el PSM, la competencia del PSM en el sentido de (Wielinga et al., 1998).

♦ Suposiciones: Que describen el conocimiento del dominio necesitado por el PSM para lograr su funcionalidad (Fensel & Benjamins, 1998b; Fensel & Straatman, 1998).

♦ Especificación operacional: Especifica el proceso de razonamiento que lleva a cabo esa funcionalidad cuando se dispone del conocimiento requerido. Se compone de inferencias y control entre ellas. Las inferencias especifican los pasos de razonamiento usados para cumplir con la funcionalidad del método.

Inicialmente, las bibliotecas de PSMs se corresponden (Breuker et al., 1987; Marcus, 1988a), más que nada, a colecciones de PSMs completos, (incluso la más evolucionada de (Puppe, 1993)), que proporcionaban un apoyo-guía en la adquisición del conocimiento, conocimiento que tenía que pasar por el modelo de PSM elegido. En una siguiente generación de bibliotecas se introduce un cierto grado de flexibilidad. Las bibliotecas de (Breuker & Van de Velde, 1994) para CommonKADS, (Benjamins, 1993) en diagnóstico y (Valente, 1994a); Valente et al., 1998) en Planificación, por ejemplo, se organizan de acuerdo a la estructura tarea-método. La idea fundamental de esta estructura, introducida más o menos al mismo tiempo por Steels (1990) y Chandrasekaran (1990), es que dada una tarea, es posible encontrar diferentes métodos que la resuelvan. Son métodos denominados específicos de la tarea, diseñados para una clase determinada de problemas (por ejemplo


diagnóstico, planificación temporal, etc.). Su terminología refleja el compromiso con la tarea. Este tipo de bibliotecas incluyen diferentes colecciones de componentes reusables. Por ejemplo, la biblioteca CommonKADS incluye funciones canónicas o inferencias elementales, esquemas inferenciales y tipos de problemas (tareas).

A través de la selección de métodos para la tarea, en un problema determinado, finalmente se llega a una estructura de tareas tal como es ofrecida por los modelos de interpretación de KADS-I. La biblioteca es capaz de generar tantos modelos de interpretación como combinaciones de métodos para cada subtarea.

La labor de construcción de un método para una aplicación específica supone la navegación por una jerarquía de este tipo, proceso recursivo de descomposición de una tarea a través de un PSM seleccionado en subtareas igualmente descomponibles. La selección del método adecuado venía dirigida por características de biblioteca (Breuker & Van de Velde, 1994), restricciones pragmáticas (Steels, 1990) o suposiciones del método (Benjamins & Pierret-Golbreich, 1996). Esta organización requiere que los métodos de descomposición de tareas tengan criterios de selección que guíen en la selección de los métodos para una aplicación dada. Steels diferencia dos tipos de características de la tarea para estos criterios de selección: conceptuales, es decir, características de la naturaleza de la relación entrada-salida de la tarea, y pragmáticas, limitaciones del agente y restricciones impuestas por el entorno. En (Benjamins, 1993) coincide el primer tipo de características con la propia definición de la tarea y las segundas con lo que él denomina criterio de adecuación.

Prácticamente todas las aproximaciones existentes se basan en este tipo de estructura. Incluso se intenta automatizar mediante herramientas que lo faciliten, como en GDM donde la construcción del modelo de la tarea se lleva a cabo de una forma incremental, en pasos de descomposición en sesiones de elicitación en las que el conocimiento del dominio es contrastado con las reglas de reescritura que dirigen la elección del método.

En Fig. 8 se muestra una primera descomposición de la tarea de diagnóstico según Benjamins (1993). Las elipses representan tareas y los rectangulos métodos (alternativos) de descomposición de estas tareas.

Diagnóstico

Método inicialde diagnóstico

Detectasíntomas

Generahipótesis

Discriminahipótesis

Fig. 8 Primera descomposición de la tarea de diagnóstico según el método inicial de diagnóstico (Benjamins, 1993).

A su vez, por ejemplo, para la subtarea Genera Hipótesis, se dispone de dos métodos de descomposición, el que, el mismo autor, denomina Compilado y el Basado en Modelo (Fig. 9).

Basado en modelo

Generahipótesis

Filtraprobabilísticamente

Compilado

Encadenamientohacia atrás

Intersección Recubimientopormínima

cardinalidad

Suspensión derestricciones

Cubrimientocausal

Predicción

Recubrimientobásico delconjunto

Recubrimientopor subconjuntos

mínimos

Abstrae

Encuentracontributores

Transforma a unconjunto de

hipótesis

Filtrado basadoen predicción

Suspensión derestricciones

Simulaciónde fallo

Asocia

Fig. 9 Descomposición de la tarea Genera–Hipótesis según los métodos compilado y basado en modelo (Benjamins, 1993).

Evidentemente, cualquier tipología no concreta toda y cada una de las posibles tareas del mundo real, en todo caso abstrae y generaliza una gama mucho más amplia de posibilidades. Es esquema de diagnóstico sistemático nos vale como marco (template) para su descripción y como ayuda en la adquisición del conocimiento. Pero habitualmente, en un dominio determinado, la tarea debe se particularizada en el proceso que se denomina diferenciación del conocimiento. Puede ser un proceso de refinamiento, inferencias

20


elementales en el marco, en la particularización pueden ser composición de otras más elementales. O puede ser ampliación, incluir nuevos pasos inexistentes en el marco original. Y por último, claro está, de simplificación, eliminando inferencias sin sentido en el dominio específico de aplicación.

La diferenciación viene guiada por:

• La naturaleza del conocimiento en el dominio de aplicación.

• Las restricciones impuestas por el entorno de la tarea.

• Restricciones computacionales.

1.3.2.2 Ontologías.

La noción de ontología se ha extendido dentro de la Inteligencia Artificial desde principios de los años noventa en campos como la representación del conocimiento, el procesamiento de lenguaje natural, localización inteligente de información en Internet y gestión de conocimiento. El objetivo básicamente de una ontología es facilitar la construcción de un modelo del dominio a partir de la reutilización de toda o parte de la ontología para un problema en particular. Es necesario entonces, la compartición y común comprensión del conocimiento de un dominio accesible a personas y ordenadores. Para ello debe proporcionar un vocabulario de términos y las relaciones para el modelado del dominio.

Lo que una ontología ofrece es el conjunto de entidades, relaciones, conceptos, esquemas de clasificación y jerarquía que son comunes a varios dominios de conocimiento. Representa el vocabulario y semántica común, "desatornillable" de un dominio concreto y, por consiguiente, reutilizable. Si es verdad que los especialistas de un dominio se entienden entre ellos y si queremos que esa comprensión sea computable, debemos admitir que hay una estructura subyacente común a todos ellos (especialistas humanos y modelos computables) que capta lo genérico del conocimiento del dominio. Así, ese modelo estructural compartido y el conjunto de tablas de semántica que especifican: 1) el significado en el dominio del observador y a nivel de conocimiento, 2) la estructura formal del modelo y 3) el significado en el nivel de los símbolos, a ese modelo compartido le llamamos ontología.

1.3.2.3 Principios de modelado del conocimiento

A través de las aportaciones de las diferentes perspectivas de modelado mostradas anteriormente, es fácil encontrar una serie de principios generales, aceptados explícita o implícitamente, por toda la comunidad científica preocupada por el modelado del conocimiento a nivel del conocimiento, en el sentido de Newell, en los siguientes términos:

22

Taxonomía del conocimiento: Se abandonan los modelos planos y se distinguen dos grandes tipos de conocimiento: inferencial y del dominio. A su vez, dentro del conocimiento inferencial se distingue entre tareas (lo que hay que hacer, la descripción más clara y precisa posible de los objetivos de un programa) y los métodos (PSMs) adecuados para llevar a cabo esas tareas (cómo se resuelve la tarea).

Se acepta que una misma tarea puede llevarse a cabo usando diferentes PSMs, bien de forma exclusiva o combinada. En la descomposición de la tarea determinada por el PSM elegido se llega a las inferencias, que son las subtareas primitivas para las que no es necesario buscar nuevos métodos de descomposición ya que se pueden implementar usando solo conocimiento del dominio; diferentes inferencias pueden ser resueltas por diferentes mecanismos inferenciales. El conjunto de inferencias al que se llega tras descomponer todas las tareas mediante todos los PSMs constituye el conjunto de funciones atómicas a partir de las cuales se modela el razonamiento.

El segundo tipo de conocimiento que se acepta como componente básico de todo modelo es el conocimiento del dominio. También de él hemos hablado en el apartado anterior, donde hemos señalado la existencia de ontologías.

Limitación por roles: Un modelo del nivel de conocimiento supone la estructuración del conocimiento de un agente, indicando el papel (rol) que cada elemento de este conocimiento juega en el método (PSM). Se tipifican los elementos del conocimiento en el modelo y se les asigna un nombre significativo a este papel. Así el principio facilita el mantenimiento de un sistema, identificando el propósito de cada entrada en la base de conocimiento.

Reusabilidad. La disponibilidad de una librería de componentes de conocimiento bien documentada facilita tanto el desarrollo de KBS’s como su mantenimiento y actualización. La reusabilidad es la principal razón para introducir modelos al nivel de conocimiento. A la inversa, las descripciones al nivel de conocimiento permiten a un desarrollador identificar componentes genéricos que instanciará en su aplicación. Componentes reutilizables en diferentes niveles de genericidad, desde un modelo genérico completo, o modelo estructural, hasta primitivas de razonamiento. Los modelos estructurales especifican una parte de un modelo del conocimiento. El desarrollador debe completarlo rellenando los huecos dejados. De esta forma, el modelo es una guía en el proceso de modelado de conocimiento. Son ejemplos de este tipo de modelos reutilizables los métodos limitadores de papeles (Marcus, 1988b), modelos de interpretación (Breuker et al., 1987) y ontologías (Farquhar et al., 1996).

A partir del modelado en el nivel del dominio, hay un acuerdo en un cuarto principio metodológico:


Mantenimiento de la estructura conceptual. (Structure Preserving Design, SPD). Supone que la estructura del modelo conceptual se mantiene a través del proceso de transición hasta la implementación (Shadbolt et al., 1993; Van Harmelen & Aben, 1996; Benjamins & Aben, 1997). Esto se consigue mediante la construcción de modelos con un nivel de detalle incremental en la descripción de la funcionalidad del sistema, de forma que sean reconocibles los componentes del modelo en la implementación.

Con ello mejora el mantenimiento drásticamente puesto que existe una conexión explícita entre el modelo conceptual y la implementación, y los cambios en la implementación pueden dirigir cambios en los modelos anteriores y viceversa. Se facilita el seguimiento para la localización de una omisión o una inconsistencia en la implementación, regresando a una determinada parte del modelo conceptual. También mejora la posibilidad de reutización puesto que si una parte de un modelo conceptual se utiliza en una nueva aplicación, los refinamientos correspondientes pueden ser transportados con él. Y, por último, facilita la generación de explicación, con el lenguaje y el nivel del modelo conceptual.

1.4 Nivel conceptual y Modelo de pericia en KADS

1.4.1 Proyectos KADS

Con el fin de obtener una metodología que proporcione una aproximación sistemática al desarrollo de los Sistemas Basados en Conocimiento (KBS) (como así ocurre para la construcción de software convencional, para los que se han desarrollado múltiples metodologías), dentro del programa europeo ESPRIT se ha venido desarrollando una metodología que, con las sucesivas actualizaciones, se ha convertido en el estándar europeo de facto.

KADS (Knowledge Analysis and Design System) [Schreiber et al., 87], [Breuker & Wielinga, 89], [Gaines & Boose, 92], [Schreiber et al., 93] es el nombre de una metodología estructurada para el desarrollo de sistemas basados en conocimiento. La historia de KADS es tan larga como complicada. En 1982 Anni Brooking de la Politécnica de Suthbank (Reino Unido) vio la necesidad de una proceso de desarrollo más estructurado que el prototipado rápido que se estaba utilizando hasta ese momento. Conjuntamente con un equipo de la Universidad de Amsterdam se lanzó una propuesta al programa ESPRIT, y comenzó el proyecto P12 en 1983. Los objetivos eran el desarrollo de una metodología basada en técnicas de la ingeniería y soportada por herramientas y técnicas precisas.

Los resultados iniciales fueron limitados pero se sentó la base para posteriores trabajos. P12 resultó en un análisis sistemático de técnicas de elicitación del conocimiento, un primer intento hacia la modelación al nivel del conocimiento, y un sistema computerizado que soportaba el análisis y documentación del conocimiento, de aquí el acrónimo KADS

24

(Knowledge Analysis and Documentation System) aunque posteriormente se le dio una interpretación distinta (Knowledge Analysis and Design Support).

Un proyecto posterior, habitualmente denominado KADS-I, más largo y con más medios humanos y técnicos, continuó la tarea iniciada. El trabajo se dividió en tres áreas: desarrollo de una teoría, desarrollo de herramientas y testeo experimental de la nueva metodología a través del estudio de casos prácticos. Se reorientó el énfasis en la adquisición del conocimiento hacia una visión más amplia, de todo el ciclo de vida, interacción usuario-sistema y diseño e implementación.

Pero la metodología desarrollada carecía del grado de formalización necesario. Es en trabajos posteriores donde se realizan esfuerzos en la formalización del razonamiento en el nivel del conocimiento.

En invierno de 1990 comienza KADS-II con el mismo objetivo todavía del desarrollo de una metodología comercialmente viable que cubriese todo el ciclo del desarrollo de KBS y que como resultado del proyecto se denomina CommonKADS.

1.4.2 Modelos KADS

Un modelo refleja, mediante la abstracción de detalles, características del sistema en el mundo real. Cada modelo resalta ciertas características del sistema y abstrae otras.

Proporcionan una descomposición de las tareas de la ingeniería del conocimiento, lo que reduce su complejidad. Mientras se construye un modelo, se pueden dejar en suspenso temporalmente otros aspectos.

En CommonKADS se definen 6 modelos (Fig. 10):

Modelo de Organización: Describe y analiza las principales actividades de una empresa.

Modelo de Tareas: Analiza el esquema global de subprocesos en la organización, entradas, salidas, precondiciones y criterios de actuación, recursos y competencias.

Modelo de Agentes: Describe las características de los agentes como ejecutores de tareas: competencias, autorizaciones y restricciones.

Modelo de Comunicación: Describe de forma también conceptual las transacciones entre los agentes involucrados en una tarea.

Pericia: Describe en detalle, pero independiente del la implementación, los tipos y estructuras de conocimiento usados en una tarea y el papel que estos componentes de conocimiento desempeñan en la resolución de la tarea,

Diseño: A partir de los anteriores modelos, este modelo describe las especificaciones técnicas como arquitectura, plataforma de implementación, módulos software, elementos de representación y mecanismos computacionales, para llegar a la implementación de la funcionalidad descrita en el modelo de pericia y el modelo de comunicación.

Modelo de Organización

Descripción Conceptual

Modelo de Tareas

Modelo de Agentes

Entorno organizacional

Modelo de Pericia

Modelo de Comunicación

Modelo de Diseño

Descripción Computacional

Fig. 10 Los modelos describen tres tipos de información: sobre la organización en que se inscribe las tareas que se resuelven, que conocimiento requiere resolver el problema y que estructura tiene, y los elementos

computacionales necesarios para ello.

1.4.3 Modelo de pericia

Dentro de las fases habituales de un ciclo de desarrollo software (Análisis, Diseño e Implementación), hablamos del nivel conceptual en un sentido similar al término modelo conceptual utilizado en el diseño de bases de datos, esto es, descripciones abstractas de los objetos y operaciones que un sistema debería conocer, formuladas de tal forma que capturen el conocimiento que tiene el humano de tal comportamiento. El nivel conceptual (o modelo conceptual) de KADS comprende a su vez el modelo de pericia y el de cooperación. Este último contiene una especificación de la funcionalidad de aquellas subtareas (en el modelo de tareas) que requiere un esfuerzo cooperativo. Son tareas denominadas tareas de transferencia y que incluyen transferencias de información desde el sistema a agentes externos o viceversa. Por ejemplo, tareas de adquisición de datos activadas en determinados instantes del proceso de resolución del problema, o diferentes tipos de tareas de explicación del razonamiento.

El modelado de la pericia distingue el desarrollo de un KBS de cualquier otro sistema convencional. Se modela el conocimiento necesario para la resolución del problema, de forma independiente de una implementación particular. Se centra en el comportamiento que


debería mostrar el sistema y en los tipos de conocimiento que participan en la generación de ese comportamiento, abstrayendo los detalles de como se lleva a cabo en la implementación, de acuerdo a la distinción de [Newell, 82] entre nivel simbólico y de conocimiento (Fig. 11).

Son descripciones abstractas de los objetos y operaciones sobre los que el sistema debería tener conocimiento. El lenguaje en que se expresa no es un lenguaje formal de construcciones y técnicas computaciones, pero relaciona fenómenos reales con el marco cognitivo de el observador. En este sentido se puede decir que es subjetivo.

Mundo Real

Sistema

Modelode

DiseñoImplementación

AbstracciónModelo

Conceptual(pericia)

Transformación(técnicas AI)

Fig. 11 Desde el mundo real hasta un sistema software: conceptualización, diseño sobre técnicas de IA e implementación.

El modelo de pericia describe el comportamiento que debería mostrar el sistema que, supuestamente, mimetiza el comportamiento de un experto humano, y los tipos de conocimiento que participan en la generación de ese comportamiento, abstrayendo los detalles sobre cómo se llevará a cabo su implementación.

En el proyecto inicial KADS-I se ve la división del conocimiento formando una estructura de cuatro capas (Fig. 12):

• Conocimiento estático describiendo una teoría declarativa del dominio de aplicación (conocimiento del dominio).

• Conocimiento de diferentes tipos de inferencias que se realizan a partir de esta teoría (conocimiento inferencial).

• Conocimiento sobre la estructura de control que conforman las inferencias y papeles que el dominio desempeña para la resolución de la tarea (conocimiento de tareas).

26

• Conocimiento estratégico, estructura de control sobre las tareas de la aplicación y que dependen de condiciones de contorno (conocimiento de control).

ESTRATÉGICO

TAREAS GENÉRICAS

INFERENCIA

CONOCIMIENTO DEL DOMINIO

Fig. 12 Estructura en cuatro capas según KADS-I.

En CommonKADS, la metodología emergente del proyecto KADS-II, se prefiere hablar de tipos de conocimiento más que de capas. El conocimiento estratégico se puede considerar como parte del proceso de diferenciación del conocimiento, la elección de un determinado control en la ejecución de la tarea de acuerdo a las particularidades de la aplicación, y por tanto se puede considerar integrado en el conocimiento de tareas. Pero en cualquier caso, el modelo se presenta bajo dos premisas iniciales: Se asume que es posible y útil la distinción entre tipos genéricos de conocimiento de acuerdo a diferentes roles que pueden jugar en el proceso de razonamiento. Segundo, que esos tipos de conocimiento pueden ser organizados en varias capas con una interacción limitada entre ellas.

Las categorías en que el conocimiento de pericia puede ser analizado y descrito se basan en distinciones epistemológicas: contienen diferentes tipos de conocimiento, reflejan diferentes visiones del conocimiento. Esta distinción no es nueva, diversos autores ha aportado ideas principalmente sobre la separación del conocimiento del dominio y de control, como se ha visto anteriormente. Los trabajos de Davis (1980) introdujeron conocimiento de control explícito como medio de controlar procesos de inferencia de una forma flexible. En NEOMYCIN [Clancey, 1985] las diferentes funciones de conocimiento son explicadas separando dominio y control introduciendo una descripción explícita de las estrategias que usa el sistema.

Se entiende posible y útil la distinción entre distintos tipos de conocimiento de acuerdo a los diferentes “papeles” que puede representar en el proceso de razonamiento. Por otro lado, se asume que dichos tipos de conocimiento constituyen componentes entre los cuales la interacción es limitada. CommonKads propone una estructura que diferencia el conocimiento de la aplicación del conocimiento de resolución de problemas, considerándolos como independientes (Fig. 13). En el conocimiento de la aplicación incluye:


28

• Conocimiento del dominio. Sobre las entidades del dominio de aplicación (conocimiento del dominio), independientemente de como vayan a ser usadas por otros tipos de conocimiento, los conceptos se distinguen de las operaciones que se puedan realizar con ellos.

• Conocimiento inferencial. Acerca de los diferentes tipos de inferencias, que son pasos elementales de razonamiento que usa el experto en la resolución de una tarea. Una inferencia se define por sus entradas y su salida, que constituyen los denominados papeles del dominio, en referencia a los roles que las entidades del dominio implicadas juegan en la tarea. Una inferencia no acepta posteriores descomposiciones.

• Conocimiento de tareas. Especifica el objetivo de la tarea que se pretende solucionar y el método por el cual resuelve.

En el conocimiento de resolución de problemas incluye:

• Conocimiento sobre Métodos de Resolución de Problemas. Describir un método de solución de una tarea es definir su descomposición recursiva en subtareas y determinar el orden en que éstas deben ejecutarse para resolverla. Este tipo de conocimiento incluye pues el conocimiento de control de ejecución.

• Conocimiento estratégico. Se refiere a la planificación de la tarea, determinando las diferentes condiciones en que se llevarán a cabo métodos alternativos de ejecución. La consideración de conocimiento estratégico permite el diseño de sistemas más flexibles.

Métodos de Resolución de

Problemas

Conocimiento Estratégico

Conocimiento de Tareas

Conocimiento Inferencial

Conocimiento del dominio

Conocimiento de aplicación

Conocimiento de Resolución de Problemas

Fig. 13 Estructura del modelo de pericia según CommonKADS.

1.4.3.1 Conocimiento del Dominio

Un esquema del dominio (como ya se vio al hablar de ontologías) puede ser o provenir de:

• Esquema del dominio específico: Específico de un determinado tipo de sistema o artefacto

• Esquema del dominio genérico: Describe categorías de uso frecuente y objeto frecuente de aplicaciones (ontología)

• Esquema del dominio del método: Describe la conceptualización requerida por un determinado método para realizar la tarea

• Esquema del dominio de la tarea: Describe las mínimas conceptualizaciones para realizar una tarea, independientemente del método aplicado

En cualquier caso es un modelo del conocimiento específico de un dominio (mecánica, medicina, etc.) que se basa en la descripción de conceptos y relaciones entre estos conceptos. A su vez, los conceptos se especifican a partir de su participación en un conjunto de propiedades, de modo que concepto, propiedad-valor y relación son las tres entidades básicas en el modelado del conocimiento estático.


30

Concepto

El concepto es la entidad representativa central en el conocimiento del dominio. Un concepto se identificado por su nombre y hace referencia tanto a entidades abstractas (concepto-clase, p.e. paciente) como a las entidades concretas que las particularizan (concepto-objeto, p.e. paciente López). Se consideran conceptos todas las entidades involucradas en el razonamiento del experto. Pueden tener un referente físico (droga, análisis, imagen, …) o ser puras construcciones teóricas (síndrome, evidencia, síntoma, cliente, riesgo, deuda, dolor, …). En definitiva coincide con el concepto (clase, objeto, instancia,...) de objeto en el modelado orientado a objeto.

Propiedad/valor

Los conceptos son descritos por sus propiedades o atributos, definidos a su vez por su nombre y una descripción de los valores que pueden tomar (p.e, edad de un paciente, con valores entre 0 y 130 años). La entidad propiedad-valor constituye el “átomo” de la representación del conocimiento del dominio.

En la Fig. 14 se muestran dos ejemplos descritos ambos de una forma gráfica (a la manera de UML) y en el lenguaje KML4. El concepto Indicador de gasolina, es descrito por el atributo valor que toma valores de un tipo definido como valor-indicador. Los componentes de este tipo se dan por enumeración: cero, bajo y normal. Sin embargo, en el otro ejemplo, el concepto tanque de gasolina viene descrito por un atributo estado cuyos posibles valores se enumeran directamente (lleno, casi-vacío y vacío).

4 Knowledge Modelling Language

Indicador de gasolina

Tanque de gasolina

Valor: valor-indicador

Estado: {lleno, casi-vacío, vacío}

CONCEPT Indicador de gasolina; ATTRIBUTES: Valor: valor-indicador; END CONCEPT Indicador de gasolina;

CONCEPT Tanque de gasolina; ATTRIBUTES: Estado: {lleno, casi-vacío, vacío}; END CONCEPT Tanque de gasolina;

VALUE-TYPE valor-indicador; VALUE-LIST: {cero, bajo, normal}; END VALUE-TYPE valor-indicador;

Fig. 14 En la figura se muestran dos ejemplos de conceptos cuyas características son descritas por atributos. En ambos ejemplos los posibles valores, o valores admisibles, se dan por enumeración, bien en la misma

cláusula de descripción del concepto (a la derecha), bien a través de una cláusula de definición del tipo de datos (a la izquierda).

Relación entre conceptos.

Asociaciones, en terminología UML, que representan las relaciones mentales que efectivamente usa el experto humano para enlazar conceptos. Las más comunes son la relación de especialización y la relación de composición y por eso se tratan como relaciones estándar. La primera relaciona un concepto clase con su particularización en una subclase o instancia de esa clase. La segunda relaciona un concepto con sus componentes. El resto, relaciones más específicas (p.e, relaciones de causalidad, sugerencia de síntomas, relaciones temporales …), se encuentran, en la mayoría de los casos, en la descripción en lenguaje natural que el propio experto hace de su actividad, y requerirán una descripción de sus características. A menudo estas características no aparecerán explícitas en el discurso del experto.

Para la descripción de una relación de este tipo se tienen en cuenta:

• Argumentos: conceptos relacionados

• Cardinalidad: si los argumentos se definen a nivel de clase, es importante indicar un cuantificador de posibles elementos relacionados, uno a varios, varios a varios, etc.

• Orientación: Dirección de la relación si la semántica de la relación (y de la etiqueta) lo exige: se-compone-de, pertenece-a,...

• Papeles: Etiquetas que describen la función o papel que cada elemento asociado desempeña en la relación.


En la Fig. 15 se muestran ejemplos de descripción de estas características tanto gráficamente como a través del lenguaje KML. La relación requiere en determinados casos atributos propios de descripción. Esto supone en UML definir la relación a través de un objeto propio y en KML utilizar la cláusula ATTRIBUTES dentro de RELATION.

vehículo

pertenencia

pertenencia

Fecha compra: date;

pertenece-a

poseedor

BYNARY-RELATION Pertenece-a; INVERSE: posee; ARGUMENT-1: vehículo CARDINALITY: 0-1; ARGUMENT-2: persona CARDINALITY: ANY; ATTRIBUTES: fecha-compra: DATE; END BYNARY-RELATION Pertenece-a;

persona

vehículo

pertenencia

0+ 0-1 persona

vehículo persona

Fig. 15 Ejemplos de descripción de relaciones, con cardinalidad, orientación y papeles, y relación que exige atributos propios, tanto en esquema tipo UML como a través del lenguaje KML.

En las Fig. 16 se muestra otro ejemplo de relación orientada y en la que se han definido papeles: Felipe III hace el papel de padre en su relación con Carlos II pero hace el papel de hijo en su relación con Felipe II.

32

FelipeII

Don Carlos FelipeIII

Carlos II

Desciende de

hijo

padre

Fig. 16 Ejemplo de relación orientada en la que se definen papeles, y que conforma una jerarquía.

En la Fig. 17 mostramos otro ejemplo de relación, en este caso de tipo causal, de la que se deriva una estructura similar (causas de hemorragias) a la anterior en un dominio de diagnóstico médico.

HEMORRAGIAS

VASCULITIS VASCULITIS Disminución de plaquetas

APLASIA MEDULAR

CAUSAS INMUNES

SECUESTRO

DEFICIT FACTOR VII

DEFICIT FACTORES XII,

XI, IX u VIII

DEFICIT FACTOR X, V, Protombina o Fibrinógeno

Enfermedad en los factores de coagulación

Fig. 17 Esquema causal entre conceptos causas de hemorragias. La definición de métodos de diagnóstico de hemorragias en la capa de tarea e inferencia estará condicionada por la estructura del conocimiento del

dominio.

Los anteriores ejemplos han mostrado relaciones binarias, pero también es útil en determinados casos modelar relaciones multiargumento como la que se muestra en la siguiente figura. Es el ejemplo de Fig. 18 se ha modelado una observación médica como un relación entre un agente, un paciente, una localización y un observable, con atributos propios como valor, fecha y hora.


agente

Nombre Posición

paciente

Nombre Diagnóstico

observable

Tipo

localización

Departamento Hospital

observación

Valor Fecha Hora

Fig. 18 En determinadas ocasiones es interesante modelar las relaciones entre entidades como relaciones multiargumento. Por ejemplo, puede ser útil modelar una observación médica como un relación entre un agente,

un paciente, una localización y un observable, con atributos propios como valor, fecha y hora

Tanto en UML como en KML (y en todos los lenguajes similares) se han definido símbolos o cláusulas específicas para las relaciones estándar de especialización y composición. En la Fig. 19 se muestra el ejemplo de especialización del concepto vivienda en los subtipos unifamiliar y piso. La característica más importante asociada a este tipo de relación es la herencia. Los subtipos heredan las características del concepto ascendiente. Por otro lado, los subtipos deben restringir al concepto ancestro de dos formas posibles: añadiendo nuevas atributos o restringiendo los valores posibles de un atributo común. En el ejemplo de la figura, los conceptos unifamiliar y piso heredan las características de vivienda (metros-construidos) y restringen este concepto incluyendo los atributos metros-parcela para unifamiliar y planta y ascensor? para piso, que vivienda no tiene.

Si los subtipos definen una clasificación completa o no y si son clases disjuntas o no, se indica en KML a través de las cláusulas booleanas complete y disjoint.

34

vivienda

Metros-construidos: NATURAL

Univafimilar

Metros-parcela: NATURAL

Piso

Planta: NATURAL Ascensor?:BOOLEAN

CONCEPT Unifamiliar; SUB-TYPE-OF: Vivienda ATTRIBUTES: metros-parcela: NATURAL; END CONCEPT Unifamiliar;

CONCEPT Piso; SUB-TYPE-OF: Vivienda ATTRIBUTES: Planta: NATURAL; Ascensor?: BOOLEAN; END CONCEPT Piso;

CONCEPT Vivienda; SUPER-TYPE-OF: Unifamiliar, Piso SEMANTICS: DISJOINT: YES; COMPLETE: YES; ATTRIBUTES: metros-construidos: NATURAL; END CONCEPT Vivienda;

Fig. 19 En KML es posible indicar si los subtipos definen una clasificación completa o no y si son clases disjuntas a través de las cláusulas booleanas complete y disjoint.

UML diferencia entre la relación de composición y de agregación. En la primera, un objeto está compuesto de otros, de tal forma que sin alguno de los componentes no se completa, pero tiene entidad al margen de los componentes. Por ejemplo, un registro de visitas de un hospital se compone del registro de datos del paciente, registro de la anamnesis (interrogatorio al paciente sobre síntomas que percibe) y otras pruebas (ver Fig. 20). Por otro lado, la agregación es la relación del conjunto con sus elementos. El conjunto no tiene entidad sin elementos.


Registro visita

Fecha: Médico:

Pruebas

Datos del paciente

Nombre: Fecha-nacimiento: Sexo:

CONCEPT Registro-Visita; ATTRIBUTES: Fecha: DATE; Médico: NAME; HAS-PARTS: Datos del paciente, Anamnesis, ..., Pruebas: CARDINALITY: 0+; ROLE: pruebas-realizadas; END CONCEPT Infección;

... 0+ pruebas-realizadas

Anamnesis

Problema inicial: Síntomas adicionales: Historial:

Fig. 20 Ejemplo en que se ha utilizado la simbología para la representación de la relación de composición en UML y la cláusula HAS-PARTS de KML para relacionar un concepto compuesto con sus componentes; el

registro de datos médicos se compone del registro de datos del paciente, del registro de anamnesis, de otras pruebas, etc.

En este otro ejemplo (Fig. 21), los componentes de un vehículo son descendientes del la clase genérica componente y por lo tanto no tiene sentido la cardinalidad de esta relación. Por el contrario, en la relación de composición sí es precisa esta característica, da una información importante sobre el vehículo conocer de cuantos componentes de cada tipo consta o puede constar (según la genericidad de la representación) (Fig. 22).

36

Motor-arranque

Encendido: {on, off} (variable-estado)

Componente

variable-estado: universal observable: universal

Tanque-carburante

Estado: {lleno, vacio} (variable-estado)

Motor

Estado-carburante: {gas, no gas} (variable-estado)

Sistema-alimentación

Estado: {abierto,cerrado} (variable-estado)

Batería

Estado: {ajo, normal} (variable-estado)

Bujías

Inspeccion: {seca, mojada}(obsevable)

Circuito-arranque

Fusible: {ok, fundido} (variable-estado)

Inspección-fusible: {ok, cable-roto} (observable)

Panel-control

Dial-gas: valor-cual-dial (observable)

Dial-bateria: valor-cual-dial (observable)

Fig. 21 Descripción como ejemplo (según notación gráfica UML) de las clases descendientes de la clase genérica Componente con propiedades variable-estado u observable (por ejemplo Motor-arranque tiene la

propiedad Encendido con valores posibles on y off, y es del tipo variable-estado, mientras que Bujías tiene la propiedad Inspección que es del tipo observable con valores posibles seca y mojada.

Motor-arranque

Encendido: {on, off} (variable-estado)

Vehículo

Fecha-matriculación: Fecha...

Tanque-carburante

Estado: {lleno, vacio} (variable-estado)

Motor

Estado-carburante: {gas, no gas} (variable-estado)

Sistema-alimentación

Estado: {abierto,cerrado} (variable-estado)

Batería

Estado: {ajo, normal} (variable-estado)

Bujías

Inspeccion: {seca, mojada}(obsevable)

Circuito-arranque

Fusible: {ok, fundido} (variable-estado)

Inspección-fusible: {ok, cable-roto} (observable)

Panel-control

Dial-gas: valor-cual-dial (observable)

Dial-bateria: valor-cual-dial (observable)

1 1 1..n 1 1 1 1 1

Fig. 22 Composición del vehículo. En este tipo de relación es preciso indicar la cardinalidad.

En la Fig. 23 se han representado diferentes conceptos (como clases) que maneja un oncólogo en la aplicación de quimioterapias, asociándolos según diferentes relaciones.


Fig. 23 Clases de objetos manejados por un oncólogo y diferentes relaciones que los asocian.

Relaciones entre expresiones

Las relaciones anteriores son asociaciones entre conceptos y son estáticas en el sentido de que se plantean como inmutables, quedan durante todo el proceso. Pero el tipo de problemas que nos interesa requiere para su modelado de otro tipo de relaciones que más que asociar conceptos establece una asociación entre expresiones a la manera de una regla if..then: una expresión condicional en el antecedente y una expresión de asignación en el consecuente. Por ejemplo, el enunciado “que el tanque de carburante se quede vacío implicará que no llegue gasolina al motor” podría expresarse de la siguiente forma a partir de haber definido el concepto Gasolina-en-Motor:

Tanque-carburante.Estado == Vacío => Gasolina-en-Motor.Estado = FALSE;

De igual manera, el enunciado ”que la batería esté baja implica que no habrá energía suficiente en el sistema” se puede expresar de la siguiente regla habiendo definido el concepto Energía:

Batería.Estado = Bajo => Energía.Estado = OFF;

38

Las expresiones particulares de estas dos reglas son específicas de los conceptos que intervienen en ellas, pero la semántica es común y por lo tanto en el modelado pueden unificarse, en definitiva suponen una asociación entre causa y efecto. Se modelan así tipos de reglas etiquetadas entre antecedentes y consecuentes genéricos que posteriormente se instanciarán como emparejamientos así etiquetados entre expresiones concretas. En la Fig. 24 se muestra una asociación de dependencia de estados etiquetada como causa entre estados no visibles del vehículo y estados visibles de éste. La cláusula RULE-TYPE tiene esta función en el lenguaje KML . En la misma figura, la cláusula Knowlege-Base recoge los emparejamientos a través de las diferentes reglas genéricas previamente definidas

Estado-no visible-vehículo

Estado-vehículo

causa Dependencia-de-estados

RULE-TYPE Dependencia-de-estados; DESCRIPTION: Define la dependencia entre

estados de dos componentes del sistema ANTECEDENT: Estado-invisible-vehículo; CARDINALITY: 1; CONSEQUENT: Estado-vehículo; CARDINALITY: 1; CONNECTION-SYMBOL: CAUSA; END-RULE-TYPE Dependencia-de-estados;

KNOWLEDGE-BASE Red-causal-vehículo; USES: Dependencia-de-estados FROM esquema-diagnóstico-vehículo; Manifestación-de-estados FROM esquema-diagnóstico-vehículo; EXPRESSIONS: /* Dependencia de estados*/ Tanque-gasolina.Estado =Vacío CAUSA Gasolina-en-Motor. Estado = FALSE; Batería.Estado = Bajo CAUSA Energía.Estado = OFF; … /* Manifestación de estados*/ Batería.Estado = Bajo TIENE-MANIFESTACIÓN Indicador-batería.Valor = Cero; Tanque-gasolina.Estado = Vacío TIENE-MANIFESTACIÓN Indicador-gasolina.Valor = Cero; … END KNOWLEDGE-BASE Red-causal-vehículo;

Fig. 24 Un ejemplo de regla genéricas o tipo de regla, que define una relación entre expresiones también genéricas. A continuación, a través de la cláusula Knowledge-Base, se declaran en extenso el conjunto de tuplas

con las expresiones relacionadas ya en particular.

En la Fig. 25 se ha elegido otra notación gráfica habitual para representar las dos misma relaciones entre expresiones, causa entre las expresiones alarma (señal observable) o estado como antecedentes y otro estado efecto en el consecuente. La relación tiene-manifestación entre una expresión de tipo estado y otra tipo manifestación (efecto observable).


efecto

manifestacion estado

aviso

estado

Tiene manifestacion

causa causa causa

componente

observable

Variable estado

estado

Aviso -> booleano

Motor-no-arranca Motor-se-para

Atributos

Expresiones

Relaciones

Fig. 25 En una notación gráfica alternativa a la utilizada anteriormente, se representa la relación Tiene manifestación que enlaza un estado, que hace el papel de causa, y una manifestación. La relación causa enlaza

un estado, que también hace el papel de causa, y sus efectos: bien un aviso bien un nuevo estado.

Para describir el conocimiento del dominio es posible utilizar lenguajes específicos diseñados para este propósito en el contexto de la Inteligencia Artificial (KIF, Ontolingua, etc.), para algunos de los cuales existen herramientas de edición (Protégé), o lenguajes y notaciones afines concebidos en el marco de las metodologías de análisis orientado a objetos (UML). En esta asignatura no se esperan del alumno el aprendizaje de ninguna técnica concreta de modelado, ni la utilización de ninguna herramienta de desarrollo particular. Basta con que aprenda a identificar, a partir de una descripción en lenguaje natural del dominio de un problema dado, los conceptos que un experto utiliza, las propiedades con que los describe y las relaciones con que enlaza estos conceptos en el curso de su razonamiento.

1.4.3.2 Conocimiento Inferencial

El conocimiento inferencial se refiere al conjunto de subtareas que ya no necesitan posterior descomposición, es decir, por las “primitivas” del razonamiento. Las inferencias (también llamadas en la literatura “fuentes de conocimiento”) son los pasos elementales de razonamiento necesarios para la resolución de las tareas, descritos con abstracción del dominio de aplicación. Se describen especificando la función que realizan (que en este nivel puede especificarse ya como una función de transformación de estructuras de datos, como veremos en las secciones siguientes) y sus entradas y salidas, en referencia al conocimiento del dominio que usan. Una misma inferencia implementada en diferentes aplicaciones puede conllevar procesos más o menos complejos, pero, dado el carácter genérico de las descripciones que se incluyen en esta capa del Modelo de pericia, nunca será objeto de descomposición adicional, permaneciendo como un paso básico de razonamiento. Es importarte pues destacar que la descripción de una inferencia no supone especificar cómo se lleva a cabo, ya que esto dependerá fuertemente de la aplicación y el dominio concretos bajo análisis. Precisamente el límite de la descomposición de las tareas en el nivel de tareas

40

e inferencias se establece de acuerdo al criterio de independencia del dominio de aplicación. La conexión entre los dos niveles (tarea e inferencia y dominio) se realiza al especificar qué entidades del dominio asumen los papeles5 de entrada y salida de las inferencias y cómo utiliza el método de solución de las inferencias dichos entidades. Al encadenamiento de las inferencias de una tarea de acuerdo a sus entradas y salidas se le denomina estructura inferencial de la tarea, y a la representación de ésta, diagrama de inferencias. Una estructura inferencial incluye (Fig. 26):

Inferencias: Componentes funcionales que definen pasos básicos de razonamiento que operan en partes restringidas del conocimiento del dominio.

Papeles del conocimiento:

Papeles estáticos: A veces es útil mostrar explícitamente qué tipo de conocimiento utiliza la inferencia para derivar la salida desde la entrada. Para ello se define este tipo de papeles que señalan a elementos del dominio que son usados en el proceso de razonamiento pero que no son afectados por él.

Papeles dinámicos: Entradas y salidas de las inferencias que señalan a elementos del dominio manipulados en el proceso de razonamiento.

INFERENCE recubre; ROLES INPUT: alarma; OUTPUT: hipótesis STATIC modelo causal SPECIFICATION:

“Cuando se invoca la inferencia, se genera un candidato a solución que podría haber causado el aviso. La salida debería ser un estado inicial de un red de dependencia de estados que causalmente recubre el aviso de entrada”

END INFERENCE recubre;

alarma recubre

modelo causal

hipótesis

Fig. 26 Notación gráfica y textual (en KML) para la descripción de una inferencia (recubre) y los papeles que intervienen, dinámicos (aviso e hipótesis) y estáticos (modelo-causal).

5 Tanto el término inferencia como papel del dominio, son términos de KADS-II o CommonKADS, el segundo proyecto KADS. Son totalmente asimilables a los términos correspondientes fuente del conocimiento y metaclase del proyecto anterior KADS-I.


Funciones de transferencia: Comunicación con otros agentes.

Tipos:

• Obtiene: El agente requiere una información de un agente externo

• Recibe: El agente recibe una información de un agente externo a requerimiento de éste

• Presenta: El agente presenta una información a un agente externo

• Proporciona: El agente proporciona una información a un agente externo a requerimiento de éste

En Fig. 27 se muestra un ejemplo de función de transferencia de tipo obtiene:

TRANSFER-FUNCTION obtain; TYPE: OBTAIN; ROLES: INPUT: hallazgo-esperado; OUTPUT: hallazgo-observado; END TRANSFER-FUNCTION obtain;

obtiene

hallazgo esperado

hallazgo observado

Fig. 27 Notación gráfica y textual (en KML) para la descripción de una función de transferencia (obtiene) y los papeles del dominio que intervienen (hallazgo esperado y hallazgo observado).

Las inferencias elementales cumplen una función equivalente a la que desempeñan los módulos funcionales básicos de la electrónica, o los módulos de construcción de cualquier arquitectura modular, que se usan de forma repetida y sistemática de acuerdo con un esquema.

Pero una vez modelado el conocimiento inferencial es preciso describir la conexión de éste con el dominio de la aplicación, qué elementos del dominio desempeñan los diferentes papeles y sobre que estructura de relaciones actúa cada inferencia. En la Fig. 28 se muestra un ejemplo de este tipo de conexión. El papel alarma será desempeñado por un estado observable del vehículo, mientras que el papel de hipótesis será desempeñado por un estado no observable. Recubre infiere sobre el modelo causal definido, en este caso, como un tipo de regla (dependencia-estados) que modela la dependencia de estados y su correspondiente base de conocimiento.

42

alarma recubre

modelo causal

hipótesis

estado no observable del vehículo

conexión inferencia-dominio

tipo de regla

estado observable del vehículo

dependencia-estados

KNOWLEDGE-ROLE alarma; TYPE: DYNAMIC; DOMAIN-MAPPING: estado-observable-vehículo; END KNOWLEDGE-ROLE aviso; KNOWLEDGE-ROLE modelo-causal; TYPE: STATIC; DOMAIN-MAPPING: dependencia-estados FROM modelo-vehículo; END KNOWLEDGE-ROLE modelo-causal;

KNOWLEDGE-ROLE hipótesis; TYPE: DYNAMIC; DOMAIN-MAPPING: estado-no-observable-vehículo;END KNOWLEDGE-ROLE hipótesis;

Fig. 28 Conexión entre el conocimiento inferencial y el conocimiento del dominio.

Veamos ahora cómo se integran distintas inferencias en el “circuito” al que hemos denominado diagrama de inferencias. Como ilustración, la Fig. 29 muestra el esquema de inferencias del método de diagnóstico antes mencionado. Al igual que en la figura anterior, se usa el convenio de representar las inferencias (los” módulos funcionales”, en el símil electrónico) mediante elipses y los papeles de entrada y salida (las “señales”) mediante rectángulos. En lo que respecta al concepto de papel (role), obsérvese que un mismo dato podrá representar distintos papeles en inferencias diferentes o incluso en una misma inferencia utilizada en métodos distintos. Esperamos que, a partir de este ejemplo, el alumno sea capaz de generalizar y extrapolar con facilidad la idea subyacente. Así como en la descripción de este método hemos usado inferencias tales como recubre, predice y compara, en diferentes dominios y aplicando diferentes métodos resultará oportuno utilizar conjunto alternativos y conectarlas en diferente modo. En la elicitación de conocimiento que resulta de la interacción con el experto, en general serán los verbos que éste utiliza al describir su actividad los que darán nombre a las inferencias de la tarea.


recubre modelo causal

alarma

obtiene

el motor no arranca

tanque de gasolina vacío

reglas de dependencia de estados

indicador de gasolina = cero/bajo

indicador de gasolina = normal

distinto

hipótesis predice

modelo de efectos

hallazgo esperado

hallazgo observado

compara

resultado

Fig. 29 Ejemplo de esquema inferencial en el que se enlazan las inferencias a través de los papeles. Se muestra el encadenamiento de inferencias en la resolución de un diagnóstico de tipo abductivo.

La elección del verbo adecuado para etiquetar inferencias viene determinada por el criterio de expresividad en lenguaje natural del proceso inferencial que representa, y por tanto es, en cierto modo, arbitraria. Habitualmente, se ha venido tomando como base para ello, el conjunto de verbos-inferencias elementales consideradas en los primeros trabajos de KADS. Estos verbos son independientes de la tarea y por lo tanto poco descriptivos de su función global. Así, actualmente, este conjunto se ve más como una clasificación de inferencias cuya funcionalidad está estandarizada, de tal forma ya con asociarle al verbo en la tarea uno de estos verbos de la biblioteca se está describiendo su funcionalidad inferencial. Estudiaremos esto más detenidamente cuando hablemos de bibliotecas de componentes inferenciales para el modelado. De todas formas, la identificación de un conjunto de primitivas que proporcione al ingeniero de conocimiento el suficiente poder de expresión para describir cualquier tipo de tarea es un problema aún no resuelto.

1.4.3.3 Conocimiento de Tareas

En el apartado anterior se ha analizado el significado de los esquemas de inferencias y papeles del domino. En esta sección, se describen los conceptos de tarea y control de ejecución de subtareas.

Una tarea es un objetivo general (diagnosticar, planificar, etc.) para cuya consecución se usa un método, que conlleva una forma concreta de descomposición de la tarea en subtareas más elementales y un control o criterio de secuenciación de dichas subtareas en tiempo de ejecución de la tarea. La descomposición de una tarea según un método produce esquemas de inferencia del tipo que hemos usado en el diagnóstico sistemático. Aplicando recursivamente la descomposición sobre las subtareas de un método se alcanza un último nivel de subtareas elementales no descomponibles que denominamos inferencias. El conocimiento de control de un método, imprescindible para la implementación final de la tarea, especifica un procedimiento claro, preciso e inequívoco de “enlazar” las

44


inferencias entre sí. Este control se puede especificar, p.e., mediante seudocódigo o mediante el formalismo del autómata finito.

Método de descomposición de una tarea.

Se denomina método a la forma de llevar a cabo una tarea, el método de resolución del problema. La aplicación de un método a una tarea para su resolución es un proceso recursivo, puesto que define unas subtareas que, de forma análoga, son realizadas por correspondientes métodos.

En la descomposición en subtareas, dónde situar el nivel de inferencias elementales es una decisión de modelado, no interesa para describir el comportamiento de un experto humano (por ejemplo) describir procesos internos a las inferencias. El proceso inferencial únicamente, como hemos visto, se describe en lenguaje natural y será un determinado mecanismo inferencial el que lo lleve cabo en la implementación, por ejemplo un motor de reglas. En ocasiones, las inferencias obtenidas pueden identificarse directamente con primitivas compilables en el lenguaje de implementación seleccionado para el desarrollo de la aplicación bajo análisis. En cualquier caso, es en la fase de diseño donde se introducirá la descripción del proceso particular de cada inferencia, el mecanismo inferencial asociado.

En general, una misma tarea puede llevarse a cabo por diferentes métodos (p.e., un diagnóstico puede realizarse por el método de clasificación heurística, por el método de diagnóstico sistemático, etc). Un método puede ser bastante genérico (poco dependiente de la tarea) o más específico (orientado a una cierta tarea en particular, a su vez más o menos genérica). En el primer caso la relación tarea-método es una relación de varios-a-varios y en el segundo caso de uno-a-varios.

Habitualmente, las tareas se describen utilizando un marco formal donde se inscriben también las especificaciones funcionales y operacionales de un método de solución aplicado. Este marco está integrado por la Definición de tarea y el Cuerpo de la tarea, cuyas componentes se presentan a continuación.

Definición de tarea:

Objetivo: descripción textual del objetivo que define la tarea.

Entrada: denominaciones de los papeles de entrada y explicación de su significado.

Salida: idem para los papeles de salida

Especificación: descripción de la dependencia lógica entre entrada y salida.

Cuerpo de la tarea: Descripción del método del PSM seleccionado para llevar a cabo la tarea.

Descomposición. Si la tarea es compuesta, se indicarían las subtareas en que se descompone.

Papeles adicionales: denominación y explicación de los papeles del dominio que hacen referencia a resultados intermedios de la tarea (únicamente en tareas compuestas).

Estructura de control: Definición del control de ejecución de las subtareas, utilizando un seudocódigo o cualquier otra notación formal o seudoformal.

En KML la cláusula TASK describe la tarea, mientras que la cláusula TASK-METHOD describe la asociación de la tarea a un método. En el ejemplo de Fig. 30 se define la tarea diagnóstico-vehículos. El método que se utiliza para su resolución habitualmente se denomina recubre-diferencia (Fig. 31), pero la asignación tarea-método se ha denominado diagnóstico-a-través-de-recubre-diferencia (Fig. 32) y en esta estructura se describe el cuerpo de la tarea, es decir, descomposición, papeles y estructura de control.

TASK diagnóstico-vehículos; GOAL: “encontrar una causa del aviso de alarma del usuario”; ROLES: INPUT: alarma: “señal de que algo no funcional en el vehículo”; OUTPUT: tipo-fallo: “una hipótesis que explica la evidencia”;

evidencia: “conjunto de observaciones obtenidas durante el proceso de diagnóstico”;

ESPEC: “encuentra un estado inicial que explica la alarma y es consistente con las evidencias obtenidas”;

END TASK diagnóstico-vehículos;

Fig. 30 Definición de la tarea diagnóstico-vehículos a través de KML.

46

diagnóstico

recubre y diferencia

descomposición

obtiene recubre

predice compara

Fig. 31 El método recubre y diferencia habitualmente incluye cuatro subtareas: recubre, predice, compara y obtiene.

La asociación método-tarea se describe en la cláusula KML TASK-METHOD.

TASK-METHOD diagnóstico-a- través-sugiere-y-comprueba; REALIZES: diagnóstico-vehículo; DECOMPOSITION: INFERENCES: recubre, predice, compara; TRANSFER-FUNCTIONS: obtiene; ROLES: INTERMEDIATE: hipótesis: “una posible solución”; hallazgo-esperado: “un hallazgo que se debería observar si la hipótesis fuera cierta”; hallazgo-observado : “el hallazgo realmente observado”; resultado : “el resultado de la comparación”; CONTROL-STRUCTURE: WHILE NEW-SOLUTION recubre(aviso->hipótesis) DO predice(hipótesis->hallazgo-esperado); obtiene(hallazgo-esperado-> hallazgo-observado), evidencia:=evidencia ADD hallazgo-observado); compara(hallazgo-observado+ hallazgo-esperado -> resultado); IF resultado == igual THEN BREAK-LOOP END IF; ENDWHILE; IF resultado == igual THEN tipo-fallo:= hipótesis ELSE “no se ha encontrado solución” END IF; END TASK-METHOD diagnóstico-a- través-sugiere-y-comprueba;

Fig. 32 Ejemplo en KML en el que se define el cuerpo de la tarea diagnóstico-vehículo, es decir se describe el método utilizado para la resolución de la tarea.

La estructura de control se muestra en la siguiente figura a través del diagrama de actividades de UML.


recubre

obtiene

Comienza el diagnóstico a través de sugiere-y-comprueba

[resultado=no igual]

solución no encontrada

solución encontrada

[resultado=igual]

[sin más soluciones de recubrimiento]

[nueva solución de recubrimiento]

predice

compara

Fig. 33 En la figura se utiliza un diagrama de actividades UML para representar el control de subtareas del diagnóstico recubre-predice-compara.

1.5 Reutilización de componentes de modelado

En la construcción del modelo de una tarea, disponer de un conjunto o librería de elementos reutilizables es de gran ayuda, ya que proporciona los bloques “prefabricados” para la construcción de nuevos sistemas. En este sentido, la reusabilidad colabora en el proceso de adquisición del conocimiento, permitiendo un ahorro en el tiempo y dinero invertidos en un desarrollo. No queremos dejar de mencionar, sin embargo, las dificultades reales que el reuso de software plantea, de lo que es prueba el considerable esfuerzo invertido en este sentido en Ingeniería del Conocimiento en particular y en el campo global de la Ingeniería de Software.

El objetivo de la reutilización está promovido por el convencimiento de la existencia de abstracciones recurrentes en varias tareas y dominios y, por consiguiente, de la posibilidad de reutilizarlas. En clara analogía, la integración electrónica, cincuenta años después del descubrimiento del transistor, ofrece ya un microprocesador en un único circuito. El problema en Ingeniería del conocimiento es la falta de regularidad y estructura en los componentes modulares que se quieren integrar, y la necesidad de un conjunto de mecanismos de “ajuste” o “adaptación” de esos componentes, supuestamente genéricos, al dominio específico de cada aplicación.

El diseño de una biblioteca de componentes supone la definición de elementos reutilizables en los diferentes niveles descritos en las secciones previas (dominio, inferencia y tarea). Algunos de estos componentes reusables han sido introducidos y comentados a

48


través del ejemplo del diagnóstico y dos de sus métodos de solución (sistemático y heurístico). No obstante, vamos a recordar de nuevo las características de las distintas familias de componentes reusables.

Una tarea es una descripción de un objetivo. Por ejemplo diagnosticar, clasificar, planificar, etc. En la descripción del problema que proporciona un experto, en general se detectan objetivos claros que definen tareas.

Los métodos son los diferentes procedimientos para alcanzar soluciones para un mismo objetivo. Especifican cómo se llega a un fin. Para un diagnóstico podemos elegir entre diferentes métodos: diagnóstico sistemático, clasificación heurística, etc. Cada método implica la utilización de las inferencias y papeles del dominio que le son propias. Un método puede adaptarse, eligiendo de entre la biblioteca de inferencias y papeles del dominio aquéllos que sean más adecuados para el propósito particular de una aplicación.

Un método puede definirse a partir de un conjunto de elementos interrelacionados:

Especificación funcional: Descripción declarativa del comportamiento del método y de lo que puede conseguirse con él. Se denomina también competencia del método.

Suposiciones: Descripciones del conocimiento del dominio requerido por el método para conseguir su funcionalidad. En el ejemplo tratado en el apartado anterior una asunción es la disponibilidad de modelos causales para el diagnóstico. Las suposiciones describen también la forma en que ha de modelarse el conocimiento del domino, la interpretación en el dominio de los conceptos definidos en el modelo (tablas de semántica asociadas al modelo) y el papel de estos conceptos en el método.

Especificación operacional: Describe las inferencias y el flujo de control entre ellas (orden de ejecución).

Las inferencias pueden definirse como acciones elementales o bloques funcionales mínimos en la descomposición de tareas. En la literatura sobre el KADS se recopila un conjunto de verbos como componentes de modelado que ayudan a centrar y describir la semántica del proceso inferencial: select, match, compose, etc. En el capítulo 3 describiremos en extenso la biblioteca de Breuker de verbos inferenciales [Breuker et al., 1987].

Los papeles del dominio hacen referencia a los roles desempeñados por las entidades del dominio que las inferencias utilizan como entradas y generan como salidas. Damos algunos ejemplos en la Tabla 2.

50

Papel de dominio

Descripción

Problema Descripción de un problema o estado de un sistema

Caso Lista de propiedades y/o relaciones que describe una situación.

Sistema Lista de funciones, componentes y relaciones entre éstos, que describe un sistema de elementos interrelacionados

Especificación Descipción del comportamiento de un sistema

Estado Condición bien definida de un sistema

Restricción Conjunto de limitaciones de un concepto

Requisito Condición necesaria para que un sistema/concepto alcance un estado/atribución

Síntoma Concepto que tiene una relación, conocida o sospechada, con un fallo, o condición de un sistema

Aviso Afirmación que indica un malfuncionamiento de un sistema

Observable Concepto medible de un sistema

Tabla 2. Ejemplos de Papeles del Dominio

Las descripciones o Modelos del dominio también se pueden reutilizar, tras un mayor o menor proceso de adaptación tanto al problema específico como a las tareas e inferencias concretas que deben utilizarlos.

En definitiva, el reuso implica un proceso de selección y adaptación de elementos de diferentes bibliotecas, en las diferentes etapas del desarrollo de un modelo de pericia. El mejor de los casos se da cuando los elementos reutilizables se identifican en el nivel de implementación (métodos o inferencias se importan de las bibliotecas como módulos de código y los papeles del dominio como estructuras de datos que se instanciarán en el dominio).

Sin duda, el dominio de aplicación y la forma en que se ha modelado influyen en la elección, o adaptación, del resto de los elementos, del mismo modo que los elementos disponibles que se desea reutilizar pudieran condicionar el proceso de modelado del domino. Antes de abordar una aplicación, resulta pues útil catalogar los condicionantes anteriores en forma de un conjunto de suposiciones, afirmaciones, limitaciones, restricciones, etc., características de cada problema particular, que servirá de guía durante el proceso de desarrollo.

La alternativa a la reutilización en cualquiera de las fases mostradas en la Fig. 34 es el diseño de nuevos elementos, que, una vez definidos con el más alto nivel de genericidad posible, podrán ser incorporados a su vez a las bibliotecas.

Suposiciones

seleccionaBibliotecade tareas

seleccionaBibliotecade métodos

adapta

Biblioteca deinferencias

Bibliotecade papeles

del dominio

selecciona Bibliotecade modelosdel domino

Tareas

Métodos

Modelo deldominio

Modelo detareas e

inferencias

compone

Modelo depericia

Fig. 34 Reutilización en la definición de un Modelo de pericia. Se asume que la definición de métodos incluye la descomposición en subtareas hasta un cierto nivel, que puede no ser el último. De la biblioteca de inferencias y papeles del dominio se extraen los elementos con el fin de completar la descomposición proporcionada por el

método elegido. En cualquier fase de selección se supone una cierta adaptación, en función del domino elegido y de las suposiciones, de cualquiera de los elementos. La biblioteca de inferencias podría contener inferencias de

control.

Evidentemente, cualquier tipología de tareas expuesta en la literatura no especifica todas y cada una de las posibles tareas del mundo real; en todo caso, abstrae y generaliza una gama mucho más amplia de posibilidades. Así, p.e., la tarea de diagnóstico sistemático puede servir de marco para la descripción de una tarea específica de diagnóstico considerada, y ayudar en la adquisición del conocimiento. No obstante, habitualmente, en un dominio determinado, toda tarea deberá particularizarse en el proceso denominado de diferenciación del conocimiento. Dicho proceso puede ser un proceso de refinamiento, donde, p.e. en la particularización de inferencias que son elementales en la tarea reutilizada, surja una descomposición adicional en términos de inferencias aún más elementales. El proceso puede ser también de ampliación, incluyendo nuevos pasos de razonamiento inexistentes en el marco original. Finalmente, pueden darse procesos de simplificación, con la eliminación de inferencias que carezcan de sentido en el dominio específico de aplicación.


52

La diferenciación viene guiada por:

• La naturaleza del conocimiento en el dominio de aplicación.

• Las restricciones impuestas por el entorno de la tarea.

• Restricciones computacionales.

1.6 Construcción del modelo

Anteriormente se han dado unos principios y unos elementos de modelado estandarizados, su particularización en una determinada metodología y su descripción en lenguajes gráficos y textuales, así como la propuesta para la formación de bibliotecas y su reutilización como elementos de modelado. A partir de aquí, en la construcción de un modelo, y como fases metodológicas se proponen:

• Identificación del conocimiento:

Se localizan las fuentes de conocimiento disponibles: entrevistas con expertos, documentación, etc. Se estudia el dominio a partir de estas fuentes, consiguiendo una familiaridad con el dominio (evitando emplear demasiado tiempo y convertirse en un experto), y se seleccionan los elementos clave ya con orientación hacia la identificación de componentes potenciales de modelado, especialmente en este punto, ya descritos y disponibles. Se obtiene una lista de términos del dominio así como otra de potenciales componentes reutilizables: PSM’s, estructuras del dominio, etc. Por ejemplo, para modelar una tarea de diagnóstico podrían identificarse como apropiadas en primera instancia las estructuras de la clasificación sistemática y del diagnóstico abductivo.

En esta identificación de componentes es preciso no regirse únicamente por la etiqueta asociada, que puede equívoca puesto que no todo el mundo las entiende con el mismo significado, sino por todas sus características intrínsecas. Por ejemplo, la organización de las ubicaciones físicas de unos trabajadores en una empresa podría ser etiquetada por los expertos que la lleva a cabo como planificación, pero este es un término ambiguo utilizado en diferentes sentidos, la estructura de la tarea en este caso se correspondería con la asignación de recursos descrita en la literatura.

Si la tarea que realiza el experto en el dominio es medianamente compleja, su estructura normalmente no se corresponderá con un único modelo disponible sino que será una combinación de varios. Por ejemplo, la labor clínica de un médico es una combinación de diagnóstico y planificación de las terapias.

• Especificación del conocimiento:


El objetivo es la especificación completa del conocimiento, aunque no suelen incluirse las instancias de aplicación de la base de conocimiento, sino solamente algunos ejemplos. Esta fase supone la especificación de los tres tipos o categorías de conocimiento. Como ya sabemos esto se puede hacer a partir de la elección de componentes reutilizables. En particular desde una estructura de tarea completa o creando su estructura desde cero. Por un lado, es cierto que una estructura de este tipo, aunque no se ajuste perfectamente al problema, puede ser, de todas formas, un punto de partida en que apoyarse para la posterior adaptación o ajuste. Por otro lado, a veces puede ocurrir lo contrario, que sea la tarea la que se traduzca en términos de la estructura elegida distanciándonos de la descripción del experto. Por tanto, un primer paso sería la elección de una estructura de tarea completa, si es posible, que ayude a su vez a la adquisición del resto de conocimiento. Conviene dar ejemplos de los papeles del dominio incluidos en la estructura de inferencia.

Después o al mismo tiempo, también la construcción o reutilización del conocimiento del dominio. Hay una parte independiente de la aplicación: conceptos, estructuras reconocibles a priori independientes de su utilización posterior. Pero hay una parte más dependiente, conocimiento específico para la resolución del problema, de una forma determinada. Por ejemplo, la estructura de observaciones y patologías en medicina es utilizable tanto para un seguimiento del historial clínico como para un diagnóstico, mientras que las reglas causales que enlazan patologías con observaciones, por ejemplo, son específicas del diagnóstico y claramente orientadas al diagnóstico de tipo abductivo.

Se termina completando el modelo de PSM escogido sobre la tarea y enlazándolo con el dominio. Completar el PSM en el sentido de descomponer las subtareas que lo precisen hasta llegar a las inferencias, si es que estas subtareas no lo son ya directamente. Que haya disponibles tipos simples de conocimiento del dominio que pueden actuar como papeles estáticos de la inferencia/subtarea, es un buen indicativo de que se ha llegado al nivel inferencial. A este respecto, y por motivos de claridad, no suelen incluirse estos papeles estáticos (o de apoyo) en la descripción de tareas, únicamente en la especificación de las inferencias. Por otro lado, tampoco suelen incluirse inferencias con más de un papel de salida, lo habitual en este caso es descomponer en diferentes inferencias, una por tipo de salida. Así mismo, la ausencia de un papel de entrada ante una inferencia, debería hacer dudar que sea realmente un proceso de razonamiento.

Dar el nombre adecuado a los componentes de modelado es una labor casi esencial, los nombres de los papeles deben indicar su función en la tarea y es aconsejable que sean independientes del dominio de aplicación (mejora la reusabilidad). Para los nombres de las inferencias puede recurrirse (también aconsejable) al conjunto estándar KADS, puesto que son nombres conocidos y con un significado más delimitado y preciso.

54

Se ha comentado ya que las inferencias son cajas negras, solo definidas por sus entradas y salidas, pero por otro lado es interesante hacer constar en su especificación los métodos alternativos previsibles para la resolución de la inferencia, mirando o dando pistas para la etapa del diseño. De la misma forma, en el modelado no es preciso dar el tipo de representación exacto para el conocimiento del dominio, únicamente se ha de asegurar que ese conocimiento esté disponible. Por ejemplo, aunque el tipo de conocimiento previsto para un papel del dominio estático sea un tipo de regla, no necesariamente en el diseño éste ha de corresponderse con una regla, un demonio de un marco puede quizá soportar ese conocimiento, o quizá una restricción, o un procedimiento que responda al evento

Para enlazar el dominio con el conocimiento de tareas e inferencias, se especifican los elementos del domino que actúan en los diferentes papeles de las inferencias y en la secuencia de control.

• Refinamiento del conocimiento:

En primer lugar, validar del modelo, incluyendo tanto la verificación como la validación propiamente dicha. En cuanto a la verificación, ya sabemos que supone una validación formal, si la especificación del conocimiento es sintácticamente correcta y consistente, esto es, no faltan componentes o sobran, por ejemplo, inferencias que no se utilizan en ninguna tarea.

Para la validación en cuanto a la comprobación de que el modelo contiene todo el conocimiento necesario, lo más práctico es una simulación, bien sobre el papel, bien sobre un soporte software. En este último caso, se llevaría a cabo la simulación sobre un entorno software al que se lleva el modelo y se convierte en computable, como prototipo, desde luego de forma rápida, sin que requiera gran cantidad de tiempo y esfuerzo.

Y por último se completan las instancias del conocimiento del dominio. Por un lado los hechos relevantes para los escenarios planteado y, por otro, la base de conocimiento propiamente dicha, las instancias de los tipos de reglas, por ejemplo.

Respecto a esto último hay que advertir que por la propia esencia de un sistema basado en conocimiento, la comprobación y mantenimiento del ya existente, y la incorporación de nuevo conocimiento, no se para en ninguna etapa del desarrollo, sino que continúa con éste durante toda la vida de funcionamiento del sistema.


2 Ontologías

2.1 Introducción.

La noción de ontología se ha extendido desde principios de los años noventa en campos como la representación del conocimiento, el procesamiento de lenguaje natural, localización inteligente de información en Internet y gestión de conocimiento. El objetivo básicamente de una ontología es facilitar la compartición y común comprensión de un dominio, de cara a la comunicación entre un espectro amplio de personas, sistemas o ambos.

Lo que una ontología ofrece es el conjunto de entidades, relaciones, conceptos, esquemas de clasificación y jerarquía que son comunes a varios dominios de conocimiento. Representa el vocabulario y semántica común, "desatornillable" de un dominio concreto y, por consiguiente, reusable. Si es verdad que los especialistas de un dominio se entienden entre ellos y si queremos que esa comprensión sea computable, debemos admitir que hay una estructura subyacente común a todos ellos (especialistas humanos y modelos computables) que capta lo genérico del conocimiento del dominio. Así, ese modelo estructural compartido y el conjunto de tablas de semántica que especifican 1) el significado en el dominio del observador y a nivel de conocimiento, 2) la estructura formal del modelo y 3) el significado en el nivel de los símbolos, a ese modelo compartido le llamamos ontología. Las ontologías proporcionan la comprensión común y compartida de un dominio, permiten la comunicación entre personas y aplicaciones software sobre ese dominio.

Gruber (1993) define una ontología como "especificación formal y explícita de una conceptualización compartida". Conceptualización, puesto que hablamos de un modelo abstracto que identifica conceptos relevantes de un fenómeno, y compartida puesto que ese es su objetivo, la compartición de conocimiento y esto requiere una visión más o menos consensuado. Pero en formalización, los conceptos pierden parte de su semántica. La formalización tiene un pie en el nivel de los símbolos, se aleja del lenguaje natural y se aproxima a un lenguaje de programación, con las ventajas e inconvenientes que esto conlleva. El carácter de "compartido" de las entidades y relaciones que constituyen una ontología del conocimiento del dominio, hace referencia a la existencia de un código común a un grupo de expertos de ese dominio (cualquiera que haya trabajado con médicos, por ejemplo, entiende con facilidad las dificultades de desarrollar una ontología por este motivo). El fracaso de intentos como AIM6 por definir un conjunto mínimo de conceptos médicos con significado e implicaciones diagnóstico-terapéuticas consensuadas es paradigmático de esta

6 Programa AIM (Advanced Informatics in Medicine) de la Unión Europea.

56

dificultad. Por eso es generalmente aceptado en el estado actual del conocimiento que el papel que juegan las ontologías es de carácter estructural, dando pistas, vocabulario de entidades y relaciones que facilitan el modelado del conocimiento del dominio más que como piezas de reutilización directa.

El concepto, tal y como aquí se entiende, surge de la Inteligencia Artificial, con el objetivo de la compartición y reutilización del conocimiento: como componentes de modelado del conocimiento: los métodos de resolución de problemas describen la estructura de razonamiento de un sistema basado en conocimiento y las ontologías que describen el conocimiento estático del dominio del mismo.

El impacto de Internet ha sido fundamental para la emergencia de las ontologías, hay cada vez más organizaciones, empresas, etc. que necesitan intercambiar conocimiento con otras entidades, o dentro de la misma, como parte de la llamada “gestión del conocimiento”, capturando, representando e interpretando las fuentes del conocimiento de sus organizaciones.

En esta sesión, estudiaremos el concepto de ontología, aportaremos diferentes clasificaciones, se describirán algunas iniciativas de aplicación en diferencias áreas, principalmente en la denominada Web Semántica, las herramientas para su desarrollo, los diferentes lenguajes de representación de ontologías (especialmente en la Web) y entornos de ayuda a la reutilización.

2.2 Tipos de Ontologías y objetivos.

Se pueden identificar diferentes tipos de ontologías que cumplen diferentes papeles [Van Heijst et al., 1997] en el proceso de construcción de KBSs dependiendo de su grado de generalidad. Por ejemplo Fensel (2001) distingue:

♦ Ontologías de dominio, que capturan el conocimiento válido para un tipo particular de domino, por ejemplo en medicina [Van Heijst et al., 1995], en el dominio matemático [Gruber & Olsen, 1994], en la ingeniería [Borst el al., 1997], y el propio dominio de modelado del conocimiento [Chandrasekaran & Josephson, 1997].

♦ Ontologías de metadatos, que proporcionan un vocabulario para describir el contenido de fuentes de información on –line [Weibel, 1999]

♦ Ontologías genéricas o de sentido común, que capturan conocimiento en general sobre el mundo y proporcionan nociones básicas y conceptos para cosas como el tiempo, el espacio, estados, eventos, etc. [Pirlein & Studer, 1994].

♦ Ontologías representacionales, que no se comprometen con ningún dominio particular. Proporcionan entidades para la representación sin entrar en lo que podría representarse.


Por ejemplo, para una representación orientada a objetos o marcos, la ontología definiría entidades como marcos, atributos, restricciones, etc. [Gruber, 1993].

♦ La idea de ontología es aplicable a la descripción de conocimiento sobre tareas y métodos [Fensel & Groenboom, 1997] [Studer et al., 1996]. La ontología de la tarea proporciona términos específicos para una tarea particular. Así, por ejemplo, el término hipótesis pertenece a la ontología de la tarea de diagnóstico, que también incluye otros términos tales como observaciones, hallazgos, y diagnósticos. Esto no implica que los términos sean exclusivos de la tarea, por ejemplo, el término observaciones puede pertenecer a diferentes tareas (como monitorización). A su vez, el término hipótesis puede aparecer en la ontología de otras tareas. La ontología del método proporciona términos específicos de un particular PSM. Intenta de alguna manera resolver el problema de la interacción [Bylander & Chandrasekaran, 1988] según el cual, el conocimiento del dominio no puede ser representado independientemente de la forma en que va a ser usado en el PSM (y viceversa). Es necesario resolver esta interacción, y para ello [Fensel, 1995; Fensel & Benjamins, 1996; Benjamins et al., 1996; Fensel & Benjamins, 1998a; Fensel & Benjamins, 1998b; Fensel & Straatman, 1998] utilizan las suposiciones (assumptions), que hacen explícito el conocimiento implícito en ontologías y métodos para su adaptación en un problema particular.

Por otro lado, McGuiness (2003) diferencia entre las ontologías simples, como puedan ser:

- Listado finito de términos. Por ejemplo un catálogo, donde cada término identifica inequívocamente a un producto, por ejemplo.

- Glosario. Una lista de términos y su significad, descrito este en lenguaje natural.

- Tesauro. Proporcionan información adicional al glosario: Sinónimos, antónimos, etc.

- Jerarquía informal. Describe una relación generalización-especialización pero de tipo básico y no estricto. Esto es, un término puede ser una particularización de una clase específica pero no de una más genérica.

- Jerarquía formal: En este caso se describe una relación un-tipo-de estricta. Se definen clases y subclases.

- Jerarquía formal con instancias.

- Marcos: Se describen términos a través de atributos o propiedades. Los atributos se especifican en la clase más general posible y son heredados por sus descendientes. Asociación entre conceptos a través de las propiedades: la propiedad “está hecho de” asociará un producto con el material con el que está fabricado.

- Propiedades restringidas: Valores posibles de los atributos o propiedades que describen el concepto. Por ejemplo “esta hecho de” será un atributo cuyo tipo de valores se corresponde con los elementos de la clase (o de una subclase de) “materiales”.

- Valores restringidos. Valores de los atributos restringidos por expresiones más globales, por ejemplo, expresiones matemáticas sobre los valores de otros atributos.

58

- Características relacionales. Se especifican características de las relaciones, tales como indicación de clases disjuntas, exhaustividad, relación inversa, etc.

Cuyos objetivos no podrían ser más que:

- Disponer de un vocabulario controlado: Uso común de los mismos términos.

- La organización de un sitio Web y apoyo a la navegación.

- Prever o anticipar el contenido de un sitio Web, se puede anticipar si el contenido es de interés o no.

- Categorización desde la cual puedan colgarse particularizaciones.

- Categorización de apoyo simplemente para mejorar la visualización de contenidos.

- Categorización para mejorar la búsqueda de contenidos.

- Como apoyo para determinar la acepción de un término: Jordan, se busca el río o el jugador.

Ha habido esfuerzos importantes con este tipo de objetivos, el ya mencionado UMLS, pongámoslo como ejemplo de trabajo en un dominio específico7, de iniciativa estatal.

Otros de iniciativa privada, como el la empresa Cycorp8 que propone un diccionario de 6000 conceptos que proponen como “base para el consenso de la realidad” y 60,000 afirmaciones sobre esos conceptos que los interrelacionan, los restringen y (parcialmente) los definen.

Por último, resaltar los de índole colaborativa, como DMOZ9, del movimiento Open Source, y que pretende ser el más grande y comprenhensivo directorio de la Web, construido y mantenido por una comunidad global de editores.

También RosettaNet10 que es un proyecto de un consorcio de más de 400 empresas de tecnología de la información, componentes electrónicos, fabricantes de semiconductores para crear, implementar y promocionar estándares abiertos para el comercio electrónico.

7 http://www.nlm.nih.gov/research/umls/umlsmain.html

8 http://www.opencyc.org/

9 DMOZ Open Directory Project http://dmoz.org/

10 http://www.rosettanet.org/RosettaNet/Rooms/DisplayPages/LayoutInitial


Por otro lado, las ontologías más estructuradas pueden usarse para:

- Chequeo de consistencia: Ejem: Si la edad de una persona se corresponde con el rango de valores posibles para las personas

- Apoyo a la interoperabilidad. En ontologías más expresivas se puede definir términos en base a otros, lo que permite una operatividad superior. El ejemplo puede servir para que una aplicación que no entiende Profesor-UNED pero si comparte profesor pueda efectuar por ejemplo una búsqueda.

Profesor-UNED= miembro de la clase Profesor cuyo propiedad “da clases en” contiene el valor “UNED”

- Apoyo a la validación y verificación. Ejem: Sí se establece que un profesor no puede trabajar en más de una Universidad, esto se comprobaría buscando “da clases en” con más de un valor. Otro ejemplo: si hay un elemento de la clase profesor que no tiene un valor en “da clases en” también sería un error, puesto que un profesor se define como alguien justamente que da clases en un Centro.

- Definir tests de verificación: no solamente facilitar este tipo de comprobaciones sino realmente contenerlas. Un lenguaje de marcas podría soportar este tipo de información: definiciones de términos para ser un query de este tipo.

- Apoyo a la configuración: Pueden definirse interacciones entre propiedades, de tal forma que el valor de una propiedad pueda determinar el valor de otra. Propagación de restricciones. Ejem. Si se compra un equipo de música la selección de un altavoz determina el otro.

- Apoyo a la búsqueda estructurada, comparativa y particularizada. a partir de la ontología y de su descripción de clases, se podría efectuar una presentación comparativa de modelos etc. Apoyaría también la particularización de una búsqueda. Por ejemplo, si el resultado de una búsqueda es demasiado extenso, puede pedir al usuario que determine la búsqueda a partir de las particularizaciones de concepto, con información por ejemplo del número de respuestas por categoría.

Proponemos la lectura del artículo de Fridman Noy y Hafner (1997) que compara un conjunto de ontologías existentes a través de un marco de características tales como el propósito, nivel generalidad de la ontología, y el tratamiento del tiempo.

2.3 Razonamiento sobre ontologías

El conocimiento representado tendrá múltiples posibles usos. En principio se pueden diferenciar, según Kiryakov et al. (2002), dos tipos de usos típicos: el que denominan razonamiento terminológico, esto es, la construcción de ontologías y el que denominan razonamiento de instancias, el uso propiamente ontológico.

60

Según estos autores, el primero de estos implica a su vez la realización de tres tareas básicas: comprobar si una definición de clase es consistente por ella misma o con respecto a un conjunto de otras descripciones de clases, comprobar si una definición de clase es más general que la definición de otra clase y, por último, la construcción de una jerarquía explícita de nombres de clases en base a sus definiciones.

El uso ontológico parte de una ontología ya disponible en la que se han definido clases, las relaciones entre ellas están representadas explícitamente y hay, supuestamente, miles o millones de instancias, y supondrá la realización de las tareas:

- Encontrar la clase más específica que describe una instancia parcialmente especificada.

- Comprobar si un dato-instancia pertenece a una clase dada y encontrar todas las instancias de un conjunto de partida que pertenecen a una clase dada. En esta última tarea se podría incluir la obtención de los componentes (instancias relacionadas a través de un atributo) de estas instancias.

- Estructuras de cuestiones (Query) más complejas para responder sobre datos-instancias: por ejemplo, consiguiendo todos los pares de instancias relacionados de alguna forma.

- Comprobar la consistencia de los datos-instancia respecto de la ontología.

- Encontrar la mínima sub-ontología junto con la que un conjunto dado de instancias conforma un modelo coherente. Esto permite determinar el ámbito ontológico para un intercambio, por ejemplo, cuando cierta información (normalmente un conjunto de instancias) ha de ser intercambiado entre dos sistemas (o bases de datos o bases de conocimiento).

Uschold y Jasper (1999) proponen tres grandes categorías para clasificar todos los diferentes escenarios de aplicación de las ontologías:

Construcción neutral: Se implementa la ontología sobre un dominio determinado en un único lenguaje. Esta misma ontología será usada por diferentes aplicaciones como fuente de conocimiento, pero necesitará una traducción al lenguaje que necesite la aplicación. El beneficio fundamental es la reutilización del conocimiento. Entrarían e esta categoría aplicaciones como OntoGeneration [Aguado, 1998], que usa la ontología lingüística GUM11 (Generalized Upper Model), o el proyecto KACTUS12 que trataba de facilitar la reutilización para el modelado del conocimiento sobre diferentes sistemas técnicos.

11 http://www.darmstadt.gmd.de/publish/komet/gen-um/newUM.html

12 http://www.swi.psy.uva.nl/projects/Kactus/home.html


Acceso común a la información: La ontología construcción de la ontología proporciona un vocabulario común y consensuado para las diferentes aplicaciones, es decir, proporciona una fuente de información homogénea y comprensibles. En el caso la ontología no se traduce a diferentes lenguajes o formatos, sino que la ontología se define como estándar común para las diferentes personas y aplicaciones. La principal ventaja es la interoperatividad y un uso más efectivo de las fuentes de conocimiento. Se aplicado en el proyecto WMC13 (WorkFlow Mangement Coalition) que proporciona una ontología, descrita en lenguaje natural, a modo de glosario de términos técnicos para vendedores de sistemas de gestión

Indexación: Se utiliza la ontología como índice para localizar términos en búsquedas basadas en conceptos. La ventaja es un acceso más rápido, consensuado y controlado a los recursos de información almacenados. El proyecto, por ejemplo, IBROW3 [Benjamins et al., 1998] desarrolla un agente para la configuración de SBCs a partir de una biblioteca de métodos de resolución de problemas en la red.

2.4 Web Semántica

Básicamente, la idea de partida de la Web, en su nacimiento, es la de una web estática, compuesta por sitios donde se ubican páginas HTML.. Son páginas que inicialmente se desarrollan codificando directamente en HTML. Obligadamente el siguiente paso adelante tuvo que implicar la generación de herramientas para automatizar el desarrollo y gestión de páginas Web. Estas herramientas han permitido la extensión del número de sitios y páginas, lo que ha supuesto que el uso y búsqueda de la información allí depositada sea un objetos de estudio importantísimo para muchas aplicaciones. La información contenida en la web, llamemos convencional, es información fundamentalmente orientada al humano, en lenguaje natural, y que por tanto hace muy difícil una interpretación, gestión, búsqueda, etc. de forma automatizada. Desde luego Google14 ha supuesto un gran avance en particular en la búsqueda de información, pero no deja de ser una búsqueda a partir de palabras clave. Esto es, se busca sobre páginas de semántica plana para el buscador.

Se pretende, actualmente, una Web con páginas con semántica propia, interpretable por agentes software, no solamente humanos. Por ejemplo, que permita realizar las cuestiones de búsqueda (query) sobre una ontología común con las páginas que contienen la información, o por lo menos, a través de ontologías compatibles o traducibles

13 http://www.wfmc.org/index.html

14 http://www.google.com/

UNICODE URI

XML+NS+XMLS

RDF + RDFS

Vocabulario ontológico

Lógica

Comprobación

Confianza

automáticamente, una en términos de la otra. Por lo tanto, la información en la Web Semántica se apoya sobre páginas estructuradas de acuerdo a una determinada ontología (o esquema) justamente que le da su semántica. Los autores15 que han lanzado el concepto lo proponen como la mayor evolución desde el nacimiento de la Web. La representación explícita de la semántica de los datos, acompañada con teorías del dominio (esto es, ontologías) posibilita una Web que proporciona una nuevo nivel cualitativo de servicios. Podría tratarse de millones de páginas tratables de forma automática, esto es una cantidad ingente de conocimiento, que se ha adquirido de forma distribuida [Fensel & Musen, 2001], y que permite un razonamiento automático.

Por tanto, toda la tecnología de los lenguajes de marcas, XML, RDF(S), etc. ha adquirido una importancia vital para la ingeniería del conocimiento, conjuntamente con la reinterpretación o adaptación del modelo relacional de bases de datos. En la siguiente figura se muestra la estructura piramidal propuesta por Berners-Lee para la Web Semántica, en la que, sobre los lenguajes de marcas de W3C, se apoyan los lenguajes específicos para la descripción de ontologías formales (Fig. 35).

Fig. 35 Estructura propuesta por Berners-Lee para la Web Semántica

2.5 Herramientas de ayuda

La tecnología asociada al concepto de ontología supone el desarrollado de herramientas de diferentes tipos [Fensel et al., 2003]:

Lenguajes formales para expresar y representar ontologías

Editores para la construcción semiautomática de nuevas ontologías

Entornos que ayuden a crear nuevas ontologías reutilizando otras previas ya existentes

62

15 Principalmente e inicialmente Tim Berners-Lee, aunque hay que resaltar los numerosos trabajos, como se puede inferir del apartado de

referencias bibliográficas de este documento, de D. McGuiness de la Universidad de Stanford y D. Fensel, de la Universidad de Amsterdam. La página de

Deborah McGuiness está repleta de referencias y artículos sobre IA y Web: http://www.ksl.stanford.edu/people/dlm/en las que se encontrarán interesantes

enlaces a proyectos y artículos relacionados con ontologías. Dirección interesante: http://ksl-web.stanford.edu/kst/ontology-sources.html


Servicios de inferencia o de razonamiento sobre las ontologías

Herramientas que posibiliten a humanos el acceso inteligente (o navegación inteligente) a la información.

Servicios de traducción o integración entre diferentes ontologías que permiten intercambio multiestándar de datos y el entendimiento entre diferentes definiciones de los mismos conceptos

Hablaremos en esta sección principalmente de lenguajes y entornos de edición y construcción de ontologías. En cualquier caso, la opción será partir de la nada o desde una ontología previa y proceder a su adaptación. Existen bibliotecas de ontologías más o menos estructuradas, más formales (por ejemplo la de OntoServer) o menos formarles (como por ejemplo las proporcionadas por organizaciones y consorcios de estandarización, como el mencionado RosettaNet o el National Institute of Standar and Technology16, además de taxonomías médicas, ontologías técnicas, teorías causales, taxonomías, etc

2.5.1 Lenguajes para la descripción de ontologías

Para describir una ontología es necesario un lenguaje suficientemente expresivo, epistemológicamente adecuado.

Para ello, la orientación a marcos es altamente recomendable, los marcos han demostrado ser una construcción intuitiva y conceptualmente fácil de usar. Pero no solamente deben considerarse estructuras representacionales, también se debe considerar el razonamiento que puede ser soportado por el lenguaje o qué motores de inferencia son compatibles con las construcciones de representación del lenguaje. Y este tipo de apoyo pueden proporcionarlo las lógicas descriptivas. Por ejemplo, si puede definirse dos clases como disjuntas, evidentemente permite avisar a un usuario que intenta instanciar ambas en el mismo objeto o subclase.

Por otro lado, debería ser un lenguaje soportado por diferentes plataformas y entornos, usables por usuarios no expertos para su modelado conceptual. En este aspecto, evidentemente tiene una importancia especial la Web.

A un nivel general, el conocimiento puede ser declarativo (saber algo) o procedural (saber cómo). El conocimiento declarativo se ha venido representando históricamente mediante redes semánticas y mediante marcos (frames). Estos tipos de representación permiten el razonamiento e inferencia en tiempo de ejecución.

16 http://www.nist.gov/

64

Algunos de los lenguajes17 históricamente más relevantes en el desarrollo de ontologías han sido:

CML (Common KADS Conceptual Modelling Language) es un lenguaje de representación del conocimiento que distingue explícitamente entre conocimiento del dominio, conocimiento inferencial, conocimiento de tarea y conocimiento de resolución de problemas. Utiliza una notación muy informal, por lo cual es difícilmente utilizable por un programa.

Ontolingua18: Una ontología definida con Ontolingua consta de definiciones, es decir, de conjuntos de sentencias etiquetadas que restringen los usos de un término. Estas definiciones pueden ser de 4 tipos: de clases, de relaciones, de funciones y de instancias, y se pueden agrupar en teorías (conjuntos de definiciones sobre conceptos de un mismo subdominio). Es un lenguaje basado en KIF. También existe un servidor de ontologías desarrollado como parte de este proyecto.

UML (Unified Modelling Language): fue diseñado para la construcción de sistemas mediante lenguajes orientados a objetos. Se está ampliando para que incluya tareas de modelado más diversas y así poder representar modelos formales de conocimiento; por ejemplo, se ha definido un diagrama UML de ontología, que presenta a las clases que representan a las entidades del dominio.

Algunas ventajas del uso de UML para el desarrollo de ontologías son:

• UML proporciona un entorno gráfico ampliamente conocido.

• es un estandar abierto establecido por el OMG.

• tiene mecanismos estándar para definir extensiones para aplicaciones específicas

• tiene herramientas CASE más accesibles y extendidas que las herramientas específicas de desarrollo de ontologías como Ontolingua o Protègè.

Se han utilizado también lenguajes de especificación:

KIF (Knowledge Interchange Format) [Genesereth & Fikes, 1992] es un lenguaje que tiene una semántica declarativa y está basado en el cálculo de predicados de primer orden.

17 Para ver una revisión interesante de lenguajes visitar: http://delicias.dia.fi.upm.es/RoadMap/ontologies.html

18 http://www.ksl.stanford.edu/software/ontolingua/


Puede representar prácticamente todos los conceptos que incluyen los lenguajes avanzados de representación del conocimiento; por este motivo, la mayoría de Bases de Conocimiento existentes incorporan la posibilidad de traducción a KIF.

OKBC19 (Open Knowledge Base Connectivity), es una API que permite el acceso a bases de conocimiento, directamente o mediante red. Constituye una interfaz de acceso a sistemas de representación del conocimiento que aisla a las aplicaciones de los aspectos concretos de cada sistema y permite construir aplicaciones con acceso a diversos sistemas.

También lenguajes basados en diferentes tipos de lógicas: en lógicas descriptivas, como LOOM [McGregor,1991b] y CLASSIC [Borgida et al., 1989], en Frame Logic [Kiefer et al., 1995] o el mismo KIF antes nombrado.

Para facilitar el desarrollo de ontologías en la Web se han diseñado varios lenguajes de representación basados en marcas y en la sintaxis XML, que se han planteado como lenguajes para la Web Semántica. El uso de la sintaxis XML en el desarrollo de ontologías20 simplifica, por tanto, el trabajo de escribir los parsers correspondientes.:

SHOE21 (Simple HTML Ontology Extensions) es una extensión a HTML que permite añadir a las páginas web cierto conocimiento que pueda ser interpretado de manera automática.

XOL22 (Ontology Exchange Language) es un lenguaje para el intercambio de ontologías, basado en XML y con la semántica de los sistemas de representación del conocimiento orientados a objetos.

OML23 (Ontology Markup Language) y CKML (Conceptual Knowledge Markup Language). OML es un lenguaje para representar la estructura de la ontología (clases, relaciones, objetos y restricciones), mientras que CKML extiende OML de manera que permite representar información distribuida incorporando los conceptos asociados al flujo de información.

19 www.ai.sri.com/~okbc

20 http://www.semanticweb.org/knowmarkup.html

21 http://www.cs.umd.edu/projects/plus/SHOE/

22 http://www.ai.sri.com/~pkarp/xol/

23 http://xml.coverpages.org/oml9808.html

http://www.cs.umd.edu/projects/plus/SHOE/

http://www.ai.sri.com/~pkarp/xol/

66

RDF/RDFS24 (Resource Description Framework/Schema) es un lenguaje para representar información en la web, desarrollado por el consorcio W3C. Este lenguaje se ha usado en la ontología O’CoMMA y está en camino de convertirse en un estándar ampliamente aceptado; se ha utilizado también por las compañías eléctricas de EEUU para el intercambio de modelos de sistemas.

OIL25 (Ontology Inference Layer) extiende RDF Schema. Combina las primitivas de los lenguajes basados en frames con una semántica formal para describir el significado de los términos. Tiene una arquitectura en 4 capas de diferente funcionalidad y complejidad. Es el primer lenguaje de representación de ontologías basado en los estándares de W3C (RDF/RDF-Schema y XML/XML-Schema).

DAML26 (DARPA Agent Markup Language) es un lenguaje para representar el contenido semántico en la web que se empezó a desarrollar en el 2000 por la DARPA. Hay un proyecto conjunto con OIL y se ha implementado el lenguaje DAML+OIL; es un lenguaje muy potente en cuanto a la expresión de clasificaciones complejas y propiedades de recursos..

OWL27 (Web Ontology Language) El lenguaje DAML+OIL es la base para este nuevo lenguaje de especificación de ontologías que está desarrollando el Grupo de Trabajo WebOnt del W3C.

En la Fig. 36 se muestra una ontología a través de una simbología muy cercana a UML. Los conceptos se representan a través de un rectángulo encabezado por el nombre del concepto. Los enlaces se corresponden con relaciones entre conceptos etiquetados con el nombre de la relación y de algunas de sus características, “exhaustividad” y “disjuntividad” de la relación “subclase de”.

24 http://www.w3.org/TR/rdf-schema

25 http://www.ontoknowledge.org/oil/

26 www.daml.org

27 http://www.w3.org/TR/2002/WD-owl-semantics-20021108/

http://www.w3.org/TR/rdf-schema

http://www.ontoknowledge.org/oil/

http://www.daml.org/

Axiomas: “un servidor Unix tiene un manual de tipo Unix” “cuando una persona compra un servidor Unix tiene que comprar un manual tipo Unix”“si una persona compra un manual tipo Unix se le debe recomendar un libro genérico de tema ordenadores”

Juan

Pedro

UnixV5 UnixParaTontos

Juan compra el manual UnixV5 a Pedro

Fig. 36 Ejemplo de ontología descrita a través de una simbología cercana a UML.

Es una ontología genérica sobre material de oficina en la que se incluyen las subcategorías: mesa, ordenador y libro, entre otros. Estas dos últimas categorías se especializan en otros conceptos más concretos. Ordenador se especializa en servidor Unix y Pcs y esta clasificación es disjunta, esto es, no hay un mismo ordenador que sean servidor Unix y Pc al mismo tiempo. Libro se especializa en Manual y otros tipos que se han agrupado en el concepto LibroGenérico (esto no es una buena práctica pero tenemos no podemos ser más exhaustivo en tipos de libros). Esta relación es exhaustiva, esto es, un libro de esta ontología o es un Manual o no lo es.

Se han definido diferentes atributos de los conceptos: precio en MaterialOficina, que es un atributo univaluado (solo puede tener un valor) con un valor por defecto de 0, plataforma que describe la plataforma asociada a cada ordenador y que puede tener el valor UNX o PC respectivamente; tipo para la clase Manual y tema para la clase LibroGenérico.


68

Se han descrito tres relaciones: TieneManual que asocia Ordenador con Manual; compra que asocia Comprador, Vendedor y MuebleOficina, y EsRecomendado, que asocial Libro con Comprador.

También se describen instancias de algunos conceptos: Juan y Pedro, son instancias de Comprador y Vendedor respectivamente. UnixV5 es una instancia de Manual, y UnixParaTontos es una instancia de LibroGenérico. Se describe una instancia de asociación compra entre esas instancias: “Juan compra el manual UnixV5 a Pedro”.

Por ultimo, se incluyen varios axiomas que expresan restricciones. Por ejemplo, “un ordenador que es un Servidor Unix tiene un manual que es de tipo Unix” y “cuando una persona compra un Servidor Unix, también compral un manual de Unix”. El ultimo axioma tiene una orientación inductiva: “si una persona compra un manual de tipo Unix, se le debe recomendar un libro genérico con el tema de ordenadores”.

A continuación se muestran algunas definiciones de conceptos de esta ontologías a través de diferentes lenguajes.

En el siguiente fragmento de código DAML se define la Ontología junto con su recurso correspondiente.

<daml:Ontology rdf:about=""> <rdfs:comment>Office Material Ontology</rdfs:comment> <daml:imports

rdf:resource="http://www.daml.org/2001/03/daml+oil" />

</daml:Ontology>

Se incluye a continuación la definición de la clase Libro y de su descomposición disjunta en las clases Manual y LibroGenérico.

<daml:Class rdf:ID="Book"> <rdfs:comment>Kind of office furniture available to the

buyer</rdfs:comment> <rdfs:subClassOf rdf:resource="#OfficeMaterial" /> - <daml:disjointUnionOf rdf:parseType="daml:collection">

<daml:Class rdf:about="#Manual" /> <daml:Class rdf:about="#GenericBook" />

</daml:disjointUnionOf>

</daml:Class>

El atributo (property) plataforma que describirá una característica las clases PC y ServidorUnix (domain)


<daml:DatatypeProperty rdf:ID="platform">- <rdfs:domain>

<daml:unionOf parseType="daml:collection"> <daml:Class rdf:resource="#PC" />

<daml:Class rdf:resource="#UnixServer" /> </daml:unionOf>

</rdfs:domain> </daml:DatatypeProperty>

La descripción de la relación esRecomendado como un atributo de la clase Libro que toma valores (range) en la clase Comprador:

<daml:ObjectProperty rdf:ID="isRecommended"> <rdfs:domain rdf:resource="#Book" /> <rdfs:range rdf:resource="#Buyer" /> </daml:ObjectProperty> Por ultimo, también en DAML, incluimos la descripción de las instancias tanto de la

relación como de los conceptos. <Purchases rdf:ID="purchase0001"> <Buyer rdf:resource="#John" /> <seller rdf:resource="#Peter" /> <item rdf:resource="#UnixforDummies" /> </Purchases> <Buyer rdf:ID="John" /> <Manual rdf:ID="UnixV5" /> <GenericBook rdf:ID="UnixforDummies" /> <Seller rdf:ID="Peter" />

El lenguaje OML fue desarrollado en la Universidad de Washington y que se basó en HTML pero adaptándolo a XML. A diferencia del anterior lenguaje, este no se apoya en RDF. En el siguiente código se describe uno de los axiomas de la ontología.

<Assertion> <comment>Un ordenador que es un PC tiene un manual que es un manual de

tipo PC </comment> <Forall var="comp" type="PC">

<Forall var="man" type="Manual"> <implies>

70

<hasManual> <computer tgt="comp" /> <manual tgt="man" />

</hasManual> <Type src="man" tgt="PC" /> </implies> </Forall> </Forall> </Assertion>

2.5.2 Entornos de edición y reutilización

Los editores de ontologías facilitan la definición de jerarquías de conceptos, de atributos de conceptos y de axiomas y restricciones. Incluyen todo tipo de apoyos para el desarrollo consistente y facilidades gráficas. De forma complementaria, se está haciendo un importante esfuerzo en la reutilización de ontologías y se han desarrollado entornos que tienen esta reutilización como objetivo principal para la construcción modular de ontologías. Damos a continuación referencia de algunos trabajos que consideramos importantes en ambos sentidos.

Por ejemplo Ontolingua [Gruber, 1993; Farquhar et al., 1996], nombrado previamente, pero más que un mero lenguaje, es un sistema para la representación de ontologías que lleva asociados mecanismos para definir ontologías portables a diferentes sistemas de representación. Así, definiciones descritas en formatos estándar de cálculo de predicados (la sintaxis y semántica de las definiciones de Ontolingua se basan en la notación y semántica de KIF) son traducidas por el sistema Ontolingua en representaciones más especializadas, como por ejemplo sistemas basados en marcos, como Loom, o lenguajes relacionales, Epikit [Genesereth, 1990].

El proyecto SKC [Jannick et al., 1998] propone desarrollar un álgebra para los composición de ontologías a partir de unas ya existentes, con operaciones tales como unión, diferencia e intersección.

KARO (Knowledge Acquisition Evironment with Reusable Ontologies) [Pirlein & Studer, 1999] ofrece métodos formales, lingüísticos y gráficos para reutilizar definiciones de conceptos de una ontología dada.

Methontodology [Fernández et al., 1997; Gómez-Pérez, 1998] es una metodología para la especificación de ontologías al nivel del conocimiento a través de representaciones intermedias, previas a la representación formal. El entorno desarrollado ODE (Ontology


Desing Environment) [Gómez-Pérez et al., 1998], que soporta Methontodology, permite la traducción de estas representaciones a lenguajes formales como Ontolingua.

Al igual que ocurre con los Problem Solving Methods (PSMs), las bibliotecas de ontologías [Falasconi & Stefanelli, 1994] en general se organizan en forma de jerarquía, cada ontología se construye sobre un conjunto de subontologías. Se está haciendo un gran esfuerzo en hacer accesibles y compartibles las bibliotecas de ontologías a través de WWW, el trabajo en Ontobroker28 [Fensel et al., 1998] es un ejemplo, que además introduce, o facilita, la denominada gestión del conocimiento basada en ontologías [Benjamins et al., 1998], con el fin de hacer la información en una empresa accesible inteligentemente a sus miembros.

Protégé29 es un proyecto del grupo KMG de la Universidad de Stanford iniciado en 1985 y dedicado al desarrollo de herramientas para el modelado del conocimiento. Una de estas herramientas es Protégé-2000, una aplicación para el diseño de bases de conocimiento y para adquisición de conocimiento que proporciona un editor de ontologías. El modelo de conocimiento de Protégé-2000 está basado en frames y es compatible con OKBC (Open Knowledge-Based Connectivity Protocol30). Los frames pueden representar clases (conceptos del dominio), instancias de clase, slots (propiedades de clases y de instancias), y facetas (propiedades de los slots). Las clases tienen relaciones jerárquicas entre ellas (subclases) y pueden ser, a su vez, instancias de otras clases (metaclases). Protégé-2000 puede utilizarse siempre que los conceptos del dominio puedan representarse mediante una jerarquía de clases. Ayuda a la generación de interfaces de usuario basadas en ontologías. Es un ‘software’ libre escrito en Java y soporta RDF-Schema y OIL como formatos de salida; puede tener extensiones para otros lenguajes de representación de conocimiento.

La Fig. 37 muestra un ejemplo parcial de ontología en este entorno, en el dominio del diseño de redes neuronales, pero donde únicamente se muestra la estructura de clases.

28 http://www.aaaaifb.uni-karlsruhe.de/WBS/broker

29 http://protege.semanticweb.org

30 http://www.ai.sri.com/~okbc

http://www.aaaaifb.uni-karlsruhe.de/WBS/broker

http://protege.semanticweb.org/

http://www.ai.sri.com/~okbc

Fig. 37 Ventana del editor de ontologías de Protégé que muestra la estructura de clases en el dominio de la edición de redes neuronales [Álvarez, 1997].

Medius Visual Ontology Modeler31 ha implementado extensiones a Rational Rose; incluye ontologías base como SUO.

OilEd32 es un editor de ontologías basado en el lenguaje DAML+OIL. La Fig. 38 muestra la ventana principal del editor.

31 http://www.sandsoft.com

32 http://oiled.man.ac.uk/

72

http://www.sandsoft.com/

http://oiled.man.ac.uk/

Fig. 38 Ventana de edición de ontologías de OILEd

Ontoserver33 comprende un repositorio de ontologías, un motor de inferencia y varios traductores. KAON es el proyecto sucesor de Ontoserver para la gestión de ontologías y aplicaciones basadas en ontologías.

WebKB34 es un conjunto de herramientas para la organización del conocimiento en archivos accesibles mediante la web. Su objetivo es el desarrollo de una base de conocimiento simbólico que refleje el contenido de la web y que permita hacer comprensible a un agente ‘software’ la información textual presente en la web.

UBOT35 (UML-Based Ontology Toolset) es un proyecto de desarrollo de herramientas para la ingeniería de ontologías mediante DAML.

On-To-Knowledge36 es un proyecto para el desarrollo de métodos y herramientas de gestión del conocimiento. Uno de los resultados del proyecto ha sido el lenguaje OIL.


33 http://kaon.semanticweb.org/

34 http://meganesia.int.gu.edu.au/~phmartin/WebKB/

35 ubot.lockheedmartin.com

36 http://ontoknowledge.org

http://kaon.semanticweb.org/

http://meganesia.int.gu.edu.au/~phmartin/WebKB/

http://www.ubot.lockheedmartin.com/

http://ontoknowledge.org/

74

Ontoweb37 es un proyecto europeo para el desarrollo de métodos y herramientas para la ‘web semántica’ basados en ontologías.

KSL Ontology Server38 es un conjunto de herramientas para la creación, edición, evaluación, publicación, mantenimiento y consulta de ontologías Ontolingua que soporta el trabajo colaborativo y es accesible a través de la web.

Chimaera39 es un software que se apoya a su vez en Ontolingua para ayudar al usuario en la creación y mantenimiento de ontologías de distribuidas en la Web. Principalmente en la combinación de múltiples ontologías y diagnóstico individual y múltiple de ontologías. Apoya a los usuarios en tareas como cargar bases de conocimiento en diferentes formatos, reorganizar taxonomías, resolver conflictos de nombres, etc.

Resaltamos las siguientes posibilidades o servicios que deberían aportar este tipo de entornos:

- Apoyo al trabajo distribuido y la colaboración

- Interconectividad a través de plataformas

- Escala en términos de tamaño de ontología y número de usuarios simultáneos

- Control de versiones

- Apoyo a la adquisición, evolución y mantenimiento

- Apoyo a la diferenciación de tipos de usuarios, seguridad, facilidad de uso, estilos de presentación

- Apoyo en la extensibilidad

3 Conocimiento inferencial y de Tareas

Si en apartados se ha hablado de la reutilización en general de componentes de modelado y en particular de los componentes del modelo del dominio, en este nos

37 http://ontoweb.org

38 http://www-ksl-svc.stanford.edu:5915/doc/ontology-server-projects.html

39 http://www.ksl.stanford.edu/software/chimaera/

http://ontoknowledge.org/


centraremos en la reutilización a partir de librerías de tareas (tipos de problemas), de verbos inferenciales y de métodos de resolución de problemas (PSMs).

3.1 Tipos de problemas.

En la Fig. 39 se muestra la biblioteca original de tareas definida en el proyecto KADS, aunque es preciso comentar que la tendencia actual es minimizar el conjunto de tareas básicas, integrando objetivos (posiblemente con tres tareas sea suficiente: análisis, síntesis y modificación) y dejando la diversidad para los métodos y las inferencias. De hecho, esta es la primera utilidad u orientación propuesta por los autores: indexar y acceder a componentes de resolución. Podemos señalar por tanto que el papel de estas tipologías es doble, primero facilitan, como hemos dicho, la indexación y unificación de todos los componentes dependientes de cada tipo de problemas, por ejemplo psms o modelos del dominio. Por otro lado ayudan en la focalización en la adquisición del conocimiento, para identificar y analizar actividades en la resolución de problemas. Uno de estos tipos de problemas es una parte, a nivel alto de abstracción, de una interfaz conceptual que permite la asociación de datos del mundo real con herramientas para construir SBCs.

En [Hayes-Roth et al., 1983] se habla de “categorías genéricas de aplicaciones de ingeniería del conocimiento” en las que se incluía predicción, planificación, diagnóstico, etc. En KADS-1 se presentaron como una taxonomía de tareas genéricas que a su vez indexaba una librería de “modelos de interpretación”. Para cada tarea genérica una o varias estructuras de inferencia, descritas a alto nivel, representaban las principales dependencias en la resolución de este tipo de tareas. Aunque se confundía psm con tarea (tal como ahora se diferencia) tuvo una función como heurística muy valorada.

En una aplicación real probablemente se combinen diferentes tipos de problemas, bien como inclusión, una tarea que se corresponde globalmente con un tipo determinado de problema y que incluye tareas que se corresponden más particularmente con sendos tipos de problemas, bien como concatenación, de tal forma que la salida de una tarea actúa como entrada a otra tarea (de otro tipo de problema). Como ejemplo en ambos casos podemos situarnos en la medicina. La conclusión de un diagnóstico conduce a la planificación de una terapia, son dos tareas encadenadas correspondiendo a dos tipos de problemas, uno de análisis (diagnóstico) y otro de síntesis (planificación). Pero la decisión sobre las acciones terapéuticas adecuadas, ya en el tratamiento de un paciente, requiere de la evaluación del estado de este en determinados hitos temporales de revisión. Esta evaluación es de nuevo un diagnóstico, de nuevo dirigido por los síntomas y signos observados y que requerirán confirmación de las hipótesis planteadas.

Tareas

Identifica Predice

PrediceComporta-

miento

PrediceValoresMonitoriza Clasifica

Diagnostica

Síntesis

Modela

PlanDiseña

Configura

Análisis Modificación

Repara Supervisión

Aprendizaje

Control

Fig. 39 Jerarquía de tipos de problemas identificados por (Breuker et al., 1987) y de los cuales proporciona un

modelo de interpretación.

3.2 Verbos inferenciales.

En la literatura KADS se habla de “fuentes de conocimiento” como de la descripción funcional de un proceso primitivo de inferencia, esto es, la forma en que una relación del dominio es usada para hacer inferencias. Son los bloques mínimos de la capa inferencial, que relacionan (funcionalmente) los papeles del dominio. Habitualmente se les nombra sencillamente como inferencias. En la descripción de estructuras inferenciales genéricas (los “modelos de interpretación”), se han de incluir verbos inferenciales, las etiquetas de identifican las inferencias, no comprometidos con una tarea determinada, y específicos, en todo caso, del psm en que participan, al igual que ocurre con las etiquetas de los papeles del dominio. Se ha buscado una colección de estos verbos que i) esté bien definida su semántica en base a una determinada ontología, por ejemplo, sobre una ontología (inspirada en KL-ONE y que ya posteriormente se asume como ontología KADS ) o ii) que represente en lenguaje natural una cierta semántica a un alto nivel de abstracción y reconocible en cualquier dominio.

En los más recientes artículos de KADS se habla de funciones canónicas, con el sentido de que son verbos a los que se pueden asimilar las inferencias en la resolución de una tarea, por ejemplo, porque representan un tipo de inferencia en una estructura tan abstracta como la de un modelo de interpretación. Así, estos verbos se utilizan como etiqueta que acompaña a una inferencia en la descripción de la resolución de una tarea indicando así que clase de inferencia se lleva a cabo, sin tener en cuenta su compromiso con la ontología de la tarea. Algunos de estos verbos se describen en la Tabla 3, según [Breuker et al., 1987].

76


Inferencias Descripción

Selecciona Colección (estructurada o no) de objetos → Colección filtrada de objetos

Equipara Colección (estructurada o no) → Colección (estructurada o no)

Compone Colección de objetos → Disposición estructurada de objetos

Descompone Disposición estructurada de objetos → Colección de objetos filtrada

Ordena Colección de objetos → Colección ordenada de objetos.

Compara Conceptos (normalmente dos) → Clase de diferencia

Instancia Concepto general o atributo (clase/variable) → Objeto particular (instancia/valor)

Generaliza Colección de instancias → Concepto (que define a todas las instancias)

Abstrae Instancia → Instancia de una clase más general.

Tabla 3. Ejemplos de verbos inferenciales descritos, sobre una ontología de objetos, a través de sus entradas y salidas.

Han surgido muchos problemas de este conjunto de verbos. Por ejemplo, tal como están definidos restringen la noción de los propios verbos utilizados antes y después. Breuker define abstract como eliminar un atributo de un concepto. Esto es, la abstracción supone eliminar la restricción que supone una característica para obtener un concepto más abstracto, que es independiente de esa característica, y que por lo tanto abstrae de la misma. Sin embargo Clancey utiliza el mismo verbo para identificar la inferencia que llama abstracción cualitativa, identificando que un paciente sufre de “fiebre” si su temperatura corporal es superior a 36 grados. Es difícil ver esta visión de la abstracción como la eliminación de una característica de un concepto.

La utilización de un conjunto de verbos de este tipo ayuda a la construcción de una estructura de inferencia, pero si se definen demasiado restrictivamente, en una tipología estricta y exacta, que ayudara, por ejemplo, en su transferencia a código ejecutable, eliminaría la flexibilidad que se exige en la construcción de lo que se supone que es un modelo conceptual intuitivo.

3.3 Estructuras para la resolución de tareas.

En [Breuker et al., 1987] y otras publicaciones de KADS, se han proporcionado diferentes estructuras inferenciales especialmente pero también estructuras de control expresadas muy genéricamente con la intención de describir los pasos globales para la resolución de determinadas tareas o tipos de problemas y formas diferentes de resolver

esos problemas (psms). En [Breuker y Van de Velde, 94] se analizan esos tipos de problemas y se hace una descripción algo más detallada de las diferentes posibilidades de resolución. El objetivo de estos autores es proporcionar “templates” que ayuden al ingeniero del conocimiento en la adquisición del conocimiento, a empezar a atacar la resolución del problema y en la estructuración de su propio modelo desde un esquema genérico.

En lo que resta de este capítulo seguiremos ambos textos para describir algunos de los grandes tipos de problemas y de las estrategias de resolución, a alto nivel de abstracción.

3.4 Clasificación,

Los esquemas que veremos en este apartado se utilizan tanto en el problema de clasificación, entendido como tarea de análisis en la que se identifica la clase o categoría a la que pertenece un elemento, como en otro tipo de tareas también de análisis, como por ejemplo el diagnóstico, como pronto veremos. Son métodos de análisis que pueden formar parte, por tanto, de la resolución de cualquier tipo de tarea de análisis.

Uno de los métodos de clasificación más extendidos en la literatura, por originario como patrón inferencial, es el método de clasificación heurística, del cual se muestra en Fig. 40 su estructura inferencial. Descompone la tarea en tres subtareas: una subtarea central de equiparación heurística, y dos inferencias complementarias, abstrae y especializa. Abstrae realiza una abstracción de los datos de entrada para atribuirles una abstracción con significado en el sistema. La equiparación realiza la asociación entre estas abstracciones y soluciones a un cierto nivel de abstracción que puede requerir un refinamiento a través de la inferencia genérica especializa.

Solutiones abstractas equipara

Solución

Datos abstractos

refina

Datos

abstrae

Fig. 40 Diagrama de Inferencias de Clasificación Heurística.

78

Para la estructura de control existen diferentes posibilidades, aquí hemos traído una como ejemplo en la que el control viene dado por los datos, es la denominada solución data-driven o forward reasoning.

Clasificación heurística (Datos, -> Solución)

abstrae (Datos -> Datos abstractos)

equipara (Datos-abstractos-> Abstracción de la solución)

especializa (Abstracción de la solución -> Solución).

A continuación presentamos un ejemplo de aplicación del método de clasificación heurística al dominio de la audiología clínica (Fig. 41). La obtención de datos, la abstracción, la equiparación y la especialización se realizan en secuencia. Una vez realizada la abstracción de datos, el perfil de un paciente se caracteriza por un conjunto de variables V1…V8 (así, para un paciente de 65 años, este valor se ha abstraído en la variable V1 como “edad>60”). Algunas de estas variables describen síntomas y resultados de tests. En la figura se muestra la equiparación entre las soluciones abstractas posibles y tales variables.

Como vemos, diferentes valores observados sugieren diferentes diagnósticos. La inferencia de equiparación reduce pues el conjunto de diagnósticos posibles, pero no designa un único diagnóstico como solución. La inferencia especializa refinaría este resultado puntuando cada diagnóstico posible del siguiente modo: En primer lugar, se suman todas las ocurrencias de cada categoría en la tabla de equiparaciones (por ejemplo cochlear tiene 4 ocurrencias). A continuación, cada subcategoría hereda además los puntos de las categorías genéricas a que pertenece (por ejemplo “age-induced cochlear” hereda de “cochlear”, y “age-induced cochlear with otitis media” hereda de “otitis media”). En el ejemplo, la solución puntuada en primer lugar es “age-induced cochlear with otitis media”, y en segundo lugar “age and noise-induced cochlear”. Un refinamiento o especialización adicional permitiría finalmente comprobar cuál de éstas es la solución definitiva.


Sol. Abst.

Descripción

SA1 age-induced cochlear with otitis media SA2 age and noise-induced cochlear SA3 noise-induced cochlear SA4 age-induced cochlear SA5 normal ear ( norm) SA6 acoustic neuroma SA7 cochlear SA8 mixed SA9 otitis media SA10 possible menieres

SA11 bells palsy

Var. Descripción V1 edad>60 V2 air = mild V3 history = noise V4 speech = poor V5 tympan = a V6 acoustic_ref_c = elevated V7 acoustic_ref_u = elevated V8 o_acoustic_ref_c = elevated

EQUIPARACIÓN V1 SA1, SA2, SA4, SA9 V2 SA6, SA7, SA9 V3 SA2, SA3 V4 SA7, SA8 V5 SA5, SA7 V6 SA8, SA10 V7 SA4, SA9 V8 SA7, SA8, SA11

Fig. 41 Ejemplo de clasificación heurística aplicada a la audiología clínica. Listas de variables y soluciones, y equiparación entre ellas (emparejamiento de cada variable con los diagnósticos que sugiere).

Otro método bastante habitual es la clasificación sistemática. Su principal característica es la suposición de un modelo del sistema base que permite una descomposición sucesiva para las sucesivas hipótesis de clasificación.

Así, el proceso comienza con la selección de un modelo del sistema apropiado, de acuerdo al modelo del sistema que en principio puede ser un modelo causal (se busca la causa de un fallo en caso de diagnóstico causal) o un modelo consta-de (el diagnóstico es realidad una localización del elemento que ha fallado en el sistema). A continuación se descompone este modelo en un nivel y se selecciona una de los componentes o causas como hipótesis de trabajo. De todos los observables posibles, se selecciona alguno que pueda servir para comprobar esa hipótesis, con el fin de comparar su valor con el esperado.

80

Si se confirma esta hipótesis, el sistema ha obtenido una clasificación que puede refinarse en una nueva descomposición de clases..

En este estado, y una vez confirmada una hipótesis, se comprobaría que no hay una descomposición a un nivel inferior. Por supuesto si esto no es así, habría que descender de nivel, y realizar los mismos pasos. Si estamos en el nivel más bajo, la hipótesis confirmada es la categoría final (Fig. 42).

1

2

3

4

5

Fig. 42 Descenso sistemático del modelo del sistema a través de los nodos 1, 2, 3, 4 y 5, hasta localizar el fallo.

La comparación con la norma que todo clasificación/diagnóstico requiere, muy habitualmente no se realiza con los datos directamente extraídos de los test o pruebas, sino que sobre estos se realiza una abstracción o una cualificación previa, puesto que la observación fruto del test requiere un significado dentro del modelo elegido. Puede ser una abstracción sencilla del tipo “recuento de plaquetas < 150.000/mm3 indica un valor bajo de la variable recuento de plaquetas”, que suponga la simple asignación de unas etiquetas a diferentes rangos de la magnitud elegida. Pero también puede ser más complicada si, por ejemplo, aplicamos procesos de fuzzyficación, reglas heurísticas, etc.

La descripción de la siguiente figura se corresponde con la adaptación de este método para la resolución del diagnóstico y se ha extraído de [Tansley & Hayball, 93]. El diagrama de inferencias para esta tarea se muestra en la Fig. 43. El proceso de diagnóstico se desencadena con la llegada de una alarma que descompone el modelo del sistema para la obtención de hipótesis de orígenes del fallo. En el diagnóstico, la confirmación de una hipótesis viene de la diferencia de los valores obtenidos de las variables con respecto a lo esperado, las normas. A la inversa que ocurre en la clasificación propiamente dicha.


Alarma

Hipótesis selecciona-3

confirma

Conclusión

Modelo del Sistema

selecciona-1

descompone

Normacompara

Diferencia

selecciona-2

Variable-Valor

Observables posibles

Fig. 43 Diagrama de inferencias de la tarea de diagnóstico sistemático.

El control en la ejecución de las inferencias supone la repetición sistemática de la descomposición del modelo en hipótesis y la comprobación de todas ellas.

Systematic Diagnosis (+complaint, +possible observables, -system model) by select 1 (+complaint, -system model) REPEAT decompose (+system model, -hypothesis) WHILE number of hypotheses > 1 select 2 (+possible obsevables, -variable value) select 3 (+hypothesis, -norm) compare (+variable value, +norm, -difference) system model ⇐ current decomposition level of system model UNTIL confirm (+hypothesis).

En el siguiente código se describe el diagnóstico según este método (en un primer nivel de descomposición) a través, en este caso, de CML40. Obsérvese que las cláusulas reproducen el mismo tipo de información que las correspondientes en KML.

Task diagnóstico-según-genera-comprueba;

task-definition

40 Conceptual Modelling Language

82


goal: encontrar la causa de un comportamiento

particular de un sistema;

input: Alarma: síntoma inicial observado sobre un

sistema, que conduce al diagnóstico.

Observables posibles: observaciones realizables

sobre el sistema

output: Hipótesis: causa identificada del aviso

spec: Localiza la causa del síntoma inicial, acorde al

comportamiento observado del sistema

Task-body

type: composite:

sub-tasks:selecciona modelo, genera, comprueba;

additional-roles:

Hipótesis: Causa potencial que necesita ser comprobada.

Modelo del sistema: Modelo causal o consta-de del sistema

Conclusión: Confirmación o refutación de una hipótesis

Control-structure:

diagnostica(Aviso + Observables posibles -> Hipótesis) =

selecciona modelo (Aviso -> Modelo del sistema)

WHILE(Hipótesis ∉ Nivel inferior del Modelo) REPEAT

genera(Modelo del sistema -> Hipótesis)

comprueba(Hipótesis + Observables posibles->

Conclusión)

UNTIL (Conclusión = confirmación de hipótesis)

RETURN (Hipótesis)

Es importante observar cómo las definiciones de los nombre o literales de los papeles del dominio se refieren al papel concreto desempeñado en la tarea que se describe.

Hemos visto una forma textual de especificar el control de subtareas (en CML). La Fig. 44 muestra una representación alternativa. En la Fig. 44 se muestra como un diagrama de estados de un autómata finito.

Modelo seleccionado

Valores y Normas

comparados

Hipótesis confirmada

(Hipótesis/ descomposición en

hipótesis

( Valor de variable / observables-valores

(Diferencia relevante y ( descendientes/ sub-modelo

no( descendientes /hipótesis

Hipótesis confirmada

Valores de variables

seleccionadas

(Norma / observables-normas Normas

seleccionadas

Modelo descompuesto

(Diferencia relevante/ clase de diferencia

Aviso recibido

(Modelo del sistema/modelo del

sistema

(Diferencia no relevante/ siguiente

Aviso

Fig. 44 En la figura se utiliza un diagrama de estados (círculos) para mostrar la secuencia de control del método de diagnóstico sistemático. Las flechas indican transferencia de control, bajo la condición expresada en el rótulo adjunto (ej. ∃ hipótesis), y transferencia de datos, expresada ésta en el rótulo a continuación del carácter

“/” (ej. /hipótesis).

3.5 Diagnóstico,.

En este apartado se proporcionan y se tipifican algunos métodos de diagnóstico.

3.5.1 Diagnóstico: Primer nivel.

En un primer nivel de descomposición inferencial podemos hablar de diagnóstico como:

Diagnóstica Diagnóstico

Alarma

Modelo del sistema

Comportamiento observable

Fig. 45 Papeles de entrada y salida de la tarea de diagnóstico

84

• El comportamiento observable se refiere a toda tipo de comportamiento que pueda ser observado del sistema.

• El modelo del sistema especifica el conocimiento acerca del comportamiento esperado del sistema: tanto al correcto funcionamiento como al incorrecto.

• Alarma es una afirmación en términos del comportamiento observado, que es indeseado y que desencadena en proceso de diagnóstico.

La visión global que ofrece la figura anterior se puede descomponer en otra un poco más refinada.

Genera hipótesis

Hipótesis

Alarma

Modelo del sistema


Diagnóstico Discrimina hipótesis

Fig. 46 Primera descomposición del diagnóstico en genera-hipótesis y discrimina-hipótesis

La primera inferencia genera una lista de hipótesis y la segunda discrimina entre ellas, normalmente a partir de nuevas observaciones. En realidad hipótesis y diagnóstico pueden referirse a las mismas primitivas en el dominio, el diagnóstico es un tipo de hipótesis, la hipótesis confirmada. El conocimiento adicional, necesitado para discriminar entre las hipótesis alternativas, como el conocimiento acerca de test, es parte del conocimiento disponible en el modelo del sistema.

La secuencia “genera” y “discrimina” puede ejecutarse según estructuras de control que implementen estrategias de búsqueda del tipo extensión-primero, profundidad-primero, o estrategias intermedias.

Aparte de esta descomposición, se debe tener ya en cuenta de qué conocimiento del sistema se dispone y que tipo de salida se requiere, puesto que las siguientes descomposiciones del método dependen de ello. Aquí vemos como el proceso al nivel del conocimiento requiere sin duda una comunicación entre los niveles de inferencia/tareas y dominio. Así, tenemos que discriminar entre:

Qué tipo de salida se requiere, que tipo de elemento del dominio es el papel “diagnóstico”:


86

• Componente: uno o más componentes del sistema que no funcionan correctamente.

• Clase: una o más clases que definen o identifican el comportamiento erróneo (ej. La patología en el diagnóstico médico).

• Causa: una o más causas del comportamiento indeseado.

Cómo es el conocimiento sobre el comportamiento del sistema:

• Modelo del comportamiento.

• Asociaciones.

• Dependencias causales.

Cómo debería relacionarse el modelo del sistema con el comportamiento observado.

• Cobertura: el modelo debería predecir todo el comportamiento observado.

• Consistencia: el modelo debería ser consistente con lo observado, pero no tiene que predecirlo.

No todas las posibles combinaciones son posibles, por ejemplo, parece inconsistente la combinación de modelos de comportamiento, como conocimiento del sistema, y que se requiera una causa como salida. A continuación se describen algunas de las posibilidades descritas en la literatura de diagnósticos.

3.5.2 Diagnóstico basado en consistencia.

La salida es un componente, se basa en modelos de comportamiento y la relación puede ser de los dos tipos, consistencia y cobertura.

En este caso los papeles del dominio vistos hasta ahora serían:

• Alarma: Un aviso de discrepancia entre el comportamiento observado y el predicho.

• Comportamiento observable: observaciones del comportamiento de elementos en términos de valores de parámetros (cuantitativos o cualitativos). Puede añadirse una descripción de la estructura del sistema, esto es, descripción de los componentes y de las relaciones de entrada/salida entre ellos. Esto último es discutible, si el sistema siempre consiste del mismo conjunto de componentes y conexiones entonces puede omitirse, pero si puede variar entonces esta descripción debería incluirse.


• Modelo del sistema: Un conjunto de modelos de comportamiento que representan el comportamiento del sistema. Este modelo debe proporcionar conocimiento sobre los diferentes aspectos de las pruebas, tales como probabilidades de fallos en componentes, salidas posibles, costos de las comprobaciones de componentes.

• Hipótesis: Que pueden ser Candidatos y conflictos: conjuntos intermedios de componentes que se refieren al mismo dominio de “diagnóstico”. Conflictos se refiere a conjuntos de componentes que contribuyen a una discrepancia mientras que candidatos se refiere a conjuntos de componentes que contribuyen a todas las discrepancias.

• Diagnóstico: Identificación de uno o más componentes que manifiestan un comportamiento inconsistente con el conocimiento que proporciona el modelo del sistema sobre el comportamiento normal.

Descomposición.

Para refinar la descripción previa habría que responder a:

¿De qué tipo de conocimiento del sistema disponemos?

• Normal. Únicamente conocimiento sobre el comportamiento normal.

• Anormal. Solamente sobre el comportamiento anormal.

• Ambos.

¿Hay una jerarquía de modelos?

• No (modelo plano). La descripción del comportamiento se realiza en un único nivel de detalle de la estructura.

• Sí (jerárquico). La descripción del comportamiento se compone de niveles, cada uno de describiendo una descomposición del sistema.

¿Puede describirse el conocimiento del comportamiento de cada entidad independientemente del contexto en el que opera?

• Sí. Son modelos de comportamiento independientes del contexto.

• No. Son modelos de comportamiento dependientes del contexto.

Esta pregunta es más bien un requerimiento para que pueda aplicarse el método, puesto que si la respuesta es No habría que pensar en otro método.

¿Es muy alto el número de componentes o de modelos de comportamiento?

• Sí. Muchos componentes con muchos modelos alternativos de comportamiento.

• No.

Evidentemente la noción de ato es relativo y depende de a complejidad de las restricciones en cada modelo del comportamiento y del hardware final. De momento solo indicar que los dos primero métodos que veremos son más adecuados para la respuesta No y habría que comprobar los dos siguientes si la respuesta fue sí.

Veamos los cuatro métodos basados en consistencia:

Consistencia plana.

En este diagnóstico se considera únicamente modelos de comportamiento normal y los modelos de los componentes son independientes de contexto.

Compone Modelo del

comportamiento general

Descripción estructural

Modelo del sistema


Valor predicho Predice

Selecciona Valor de inicio

Compara

Discrepancia ComponeCompone Conflicto Candidato

Fig. 47 Variante del diagnóstico basado en la consistencia plana.

• Compone (modelo del comportamiento en conjunto): asigna un modelo de comportamiento a cada componente en la descripción estructural. La salida es un modelo que describe el comportamiento general del sistema que se diagnostica.

• Selecciona: determina los observables que son entrada para la computación, en particular los nuevos observables que proporciona el usuario y que son el punto de arranque de la computación.

88

• Predice: determina los valores que pueden predecirse en base al modelo de comportamiento general y a los observables. Cada modelo de comportamiento que ha sido asignado a un componente tiene un numero de restricciones que especifican cómo se relacionan las entradas y salidas de cada componente. Son usados, conjuntamente con los observables, para determinar los valores que debería manifestar el sistema real (sin mal funcionamiento).

• Compara: determina las discrepancias entre el valor observado y los valores predichos (o incluso entre dos valores predichos). Las diferencias significativas son indicadores del mal funcionamiento del sistema.

• Compone (conflictos): encuentra los componentes que causaron la discrepancia. Cuando esta discrepancia ocurre significa que no todos los componentes pueden funcionar correctamente. El conjunto de componentes que contribuyen a la discrepancia forman un conflicto, al menos uno de ellos debe funcionar incorrectamente.

• Compone (hipótesis): determina cuál de los componentes del conflicto son candidatos al diagnóstico final.

Cuando se han encontrado más de una hipótesis el proceso de discriminación debe continuar. Pero primero se ha de evaluar el criterio de diagnóstico. Si una hipótesis cumple esos criterios entonces el problema está resuelto.

Candidato Compara Diagnóstico

Probabilidades de fallos Componentes

Criterio

Fig. 48 Descomposición del criterio de comparación.

Si no es así, se deben solicitar nuevas pruebas. Seleccionar y evaluar las mejores pruebas (las más discriminantes) se muestra en la siguiente figura. Cuando una prueba se realiza por el usuario y se encuentra disponible, por tanto, un nuevo observable el procedimiento de diagnóstico se lleva a cabo de nuevo tal como se ha descrito, pero la parte de generación de la hipótesis hace el papel ahora de discriminación.


Prueba posible

Evalúa Prueba evaluada

Probabilidades de fallos

Relevancia a la candidatura

Criterio

Valores posibles

Fig. 49 Descomposición del criterio de evaluación.

• Compara (hipótesis): determina si un candidato (hipótesis) cumple los criterios de ser un diagnóstico adecuado.

• Evalúa (probabilidades): determina el poder discriminante de cada medida (pruebas).

• Selecciona (prueba): del conjunto de pruebas evaluadas se determina la prueba que se realizará a continuación.

Modelos de comportamiento anormal.

Si únicamente se dispone de modelos de funcionamiento erróneo, el método se mantiene casi idéntico, excepto que en vez de intentar determinar si el comportamiento normal que está modelado en el modelo del sistema es consistente con el comportamiento observable, ahora se intentaría determinar la veracidad de que ninguno de los comportamientos anormales incluidos en el modelo del sistema es consistente con el comportamiento observado.

Modelos de comportamiento múltiples.

Normalmente hay más de un modelo de comportamiento para cada componente, tanto de normal como de anormal comportamiento. Esto supone un cambio en la inferencia “compone (modelo de comportamiento)”.

• Compone (modelo de comportamiento): determina el modelo de comportamiento adecuado para el sistema. El modelo de comportamiento general puede consistir de modelos de anormal o normal comportamiento. Para decidir entre ellos la inferencia usa conocimiento sobre los candidatos (y conflictos) que se han generado previamente, solamente se asignan nuevos modelos de comportamiento a componentes que sean parte de un candidato.

90

• Predice (valores): determina los valores que pueden predecirse a partir del modelo de comportamiento general y de los observables. Igual que en la anterior inferencia, se pueden utilizar los candidatos o conflictos para focalizar mejor el problema.

Compone Modelo del

comportamiento general


Modelo del sistema


Valor predicho Predice

Selecciona Valor de inicio

Compara

Discrepancia ComponeCompone Conflicto Candidato

Fig. 50 Variante en el caso de modelos de comportamiento múltimples

Jerarquía de modelos de comportamiento.

La descomposición estructural supone que hay ya otros aspectos que influyen en la composición del modelo de comportamiento general. En vez de asignar únicamente modelos de comportamiento a elementos (componentes) presentes en la descripción estructural, la inferencia compara debe primero focalizarse en un cierta parte de la descripción estructural, descomponer esta parte en sus subcomponentes y continuar el razonamiento con esos subcomponentes. Este mecanismo facilita el razonamiento sobre un dispositivo a diferentes niveles de detalle. Vemos a continuación la descomposición de la inferencia “compone”. El papel “modelo del sistema” se refina en modelos de comportamiento y modelos de descomposición.



Selecciona Componente

Descompone

Modelo de descomposición

Subdescripción estructural

Selecciona

Modelo de comportamiento

general

Fig. 51 Variante en el caso de jerarquía de modelos

• Selecciona: determina qué componentes de la descripción estructural deben ser descompuestos.

• Descompone: usa conocimiento sobre cómo descomponen componentes especficos y genera una descripción estructural a más bajo nivel de detalle.

• Compone (modelo de comportamiento): encuentra el modelo de comportamiento más adecuado para cada uno de los componentes de la descripción estructural.

3.5.3 Diagnóstico basado en asociaciones.

Cuando las relaciones entre síntomas y enfermedades se modelan como asociaciones es importante ver si hay jerarquías:

No: entonces las asociaciones son directas en un único nivel de detalle.

Sí: entonces se asocian jerarquías de avisos/síntomas con las jerarquías de clases/fallas.

Asociacion plana.

Únicamente puede aplicarse en dominios simples donde no hay demasiados síntomas, enfermedades o asociaciones entre ambos.

Jerarquía de asociaciones.

Por ejemplo, el diagnóstico basado en clasificación heurística de Clancey: Aquí los datos de entrada son los resultado de las observaciones del sistema a diagnosticar. La primera inferencia realiza una abstracción de lo observado, para darle sentido en el sistema, por ejemplo la observación temperatura corportal = 39º es convertida en el valor alto de la

92

variable abstracta fiebre. Tras el emparejamiento con una solución de tipo abstracto se lleva a cabo, una inferencia specialize (o refine) que refina la solución.

Diagnóstico abstracto match

Diagnóstico

Abstracción de las Observaciones

specialize

Observaciones

abstract

Fig. 52 En la figura se muestra el esquema inferencial del método heurístico adaptado a la resolución del diagnóstico

La Fig. 53 muestra la relación con el dominio para cada paso inferencial. Por ejemplo, la abstracción hace uso de relaciones cualitativas, de definición y de generalización. Otras tareas pueden hacer uso de diferentes relaciones del dominio para los mismos papeles, o descomponerse en más o menos pasos intermedios.

WBC bajo

Recuento de células blancas menor de 2500

Abstracción cualitativa

Abstracción por definición

Leucopenia

Inmunosuprimido

Portador comprometido

Infección Gram-negativa

Infección E.coli Abstracción por generalización

Abstracción por generalización

Match causal

Refinamiento (subtipo)

Fig. 53 Ejemplo con instancias del dominio de aplicación, de la descomposición del proceso de abstracción según las relaciones establecidas en dicho dominio.

3.5.4 Diagnóstico Basado en dependencia causal.

Si las dependencias entre síntomas y enfermedades se modela via relaciones causales entonces es importante qué nivel de complejidad tienen esas dependencias.


94

• Simple: entonces todas las depenciencias causales pueden describirse en un nivel de detalle.

• Complejo: se requiere más de un nivel.

Modelo causal simple.

Hemos visto en otros apartado como ejemplo el diagnóstico “cover –differenciate” , descrito inicialmente en [Eshelman, 88].

Modelo causal complejo.

Se describe en [Patil et al., 81]. Las dependencias dentro del modelo y a un cierto nivel de dtalle restringen la consecuencia de hechos en modelos de otros niveles de detalle. Para determinar un diagnostico, ambos las dependencias causales dentro de cada modelo y las depecndencias jerarquicas entre modelos a diferenes niveles deberían ser conssitentes unas con otras. Las inferencias básicas serían:

• Formulación inicial: Crea una descripción inicial del paciente a partir de las alarmas y de los resultados de pruebas (paciente Specific Model PSM)

• Agregacíón: proporciona una descripcion al nivel de detalle para el siguiente nivel. Consiste de:

Identificación de los nodos en la red que son los puntos que conecta entre el modelo en este nivel y el siguiente de mayor agregación.

• Determina si las conexiones sobre un nodo focalizado en el nivel más bajo son consistentes con las conexiones causales en el siguiente nivel.

• Elaboración: Proporciona la descripción en un cierto nivel de detalle al siguiente más detallado. También consiste de:

Identificación de los nodos en la red que proporcionan la conexión entre los niveles, de arriba hacia abajo.

Determinación de si las conexiones causales alrededor del nodo focalizado en el nivel más alto son consistentes con las conexiones causales correspondientes en el nivel inferior.

• Proyección: Se utilizan modelos predefinidos para generar hipótesis y explicar el conocimiento presentado en el PSM. Los modelos pueden usarse únicamente cuando son consistentes con el conocimiento ya disponible en este PSM.

3.6 Evaluación

La evaluación es una clase de problemas que aparece tanto formando parte de otras tareas, por ejemplo en problemas de diseño o configuración donde hay una etapa de evaluación de un candidato para el diseño de acuerdo a los criterios de diseño, como también de forma aislada, por ejemplo la evaluación de solicitudes de préstamos bancarios, y en general en problemas de tipo legal, donde hay que evaluar casos reales o ficticios de acuerdo a la normativa legal.

En la siguiente figura se muestra el esquema inferencial o modelo de interpretación de la evaluación según KADS, en el que una descripción de un caso es asociada con una clase de decisión de acuerdo con el modelo del sistema. La línea inferencial de la izquierda abstrae un caso, para obtener una categoría también, y la parte derecha, por el contrario, obtiene por especificación un sistema de medida (una norma en la terminología original de KADS). La idea, por tanto, de partida es que hay dos niveles de descripción diferentes para el caso y el modelo del sistema que hay que, uno abstraer y el otro especificar, para poder llevar a cabo una asociación, una tercera línea de razonamiento, que permita una decisión.

abstraer

Descripción del caso

términos

asociar

Modelo del sistema

especificar

Sistema de medida

Descripción del caso abstracto

Categoría de decisión

Fig. 54 Esquema inferencial del modelo de interpretación de la evaluación

Veamos la descripción de estos papeles:

o Descripción del caso: Contiene una descripción estructurada del caso que necesita ser evaluado. El caso es normalmente en términos de observables,


96

desde un conjunto de variables hasta una estructura más compleja, por ejemplo, el sistema completo de datos de un banco relativos a un cliente.

o Decisión: O bien una clase de decisión que establece si o no el caso es acorde con los estándares definidos en el sistema de medida o un grado que describe la valoración del caso con los criterios especificados en el sistema de medida.

o Modelo del sistema: Es un papel estático, que contiene nos papeles interdependientes:

• Descripción del sistema: Es una descripción abstracta del sistema que se evalúa, un caso específico es básicamente una instancia de este sistema. Contiene el conocimiento que expresa cómo un caso se presenta, qué tipos de casos existen y particularmente qué términos pueden usarse en la descripción de los mismos. Normalmente estos términos se estructuran en una jerarquía de abstracción o taxonomía, de tal forma que es posible llevar a cabo razonamientos del tipo de si un cierto término pertenece a un clase más general o si una clases está incluida en otra.

• Sistema de medida: Contiene el conocimiento que determina qué decisiones son posibles y qué factores se usan para tomar la decisión. Puede tomar la forma, por ejemplo, de un conjunto de casos típicos o de un conjunto estructurado de criterios.

Desde luego estas dos partes del modelo del sistema están conectados porque el sistema de medida debería estar descrito sobre la descripción del sistema, esto es, usando los mismos términos y conceptos. En realidad, las decisiones posibles son términos abstractos descritos en el modelo del sistema. Por esto, algunos autores catalogan este tipo de tarea como de análisis, todas las soluciones posibles son conocidas de antemano.

3.7 Monitorización

Vemos en este apartado la tarea de monitorización según el modelo de interpretación KADS. En la figura se indican las entradas y salidas propuestas por estos autores para la tarea genérica.

MONITORING

Observables

Modelo del Sistema

Datos Históricos

Discrepancias de la norma

Classes de Discrepancias

Fig. 55 Entradas y salidas de la tarea monitorización

En la siguiente figura se describe la estructura de inferencias y a continuación se describen tanto los papeles del dominio como las inferencias utilizadas. Este esquema de monitorización se basa en la diferenciación entre parámetros de un modelo del sistema y que determinan el estado del sistema y los observables desde los que se infieren los valores de dichos parámetros.

Modelo del sistema

observables possibles

select1 select2

parámetros elegidas

observables relevantes

instantiate assign value

valores de normalidad

resultados/ observaciones

compare

Cualificación de los resultados

clasiffy

clases de normalidad / anormalidad

Parámetros históricos relevantes

Selection criteria

Fig. 56 Estructura inferencial del modelo de interpretación de monitorización

Descripción de los Papeles del dominio :


98

Observables (Posible observables). Conjunto de observaciones realizables sobre el sistema

Modelo del sistema. Conjunto de parámetros y características que describirían el estado del sistema. Pueden ser por ejemplo:

Selection Criteria. Criterio para seleccionar los parámetros para una determinada etapa de monitorización. En el caso del seguimiento de un paciente, por ejemplo, sería el conjunto de especificaciones de la última consulta que deciden el conjunto de pruebas que determinan el estado del paciente.,

Parámetros Históricos Relevantes. Procentes de anteriores ciclos de monitorización.

Parámetros elegidas. Subconjunto del modelo del sistema aplicando el criterio de selección y de los observables relevantes:

Observables relevantes. Subconjunto de Posible observables, seleccionados por los parámetros elegidos obtenido:

Valores normalidad. Valores de normalidad de los parámetros seleccionados.

Resultados. Valores obtenidos de las variables seleccionadas.

Cualificación de los resultados. Diferencias obtenidas entre los resultados de pruebas y los correspondientes de los valores de normalidad.

Clases de normalidad/anormalidad. Diferentes tipos de normalidad-anormalidad.

Descripción de las inferencias.

Select 1.: A partir de los observables relevantes se seleccionan los parámetros del modelo del sistema que pueden definir el estado del sistema.

Select 2. De entre los observables posibles se seleccionan aquéllos que pueden participar en la obtenciópn de valores para los parámetros que determinan el estado del sistema.

Assign-value: Obtención de los valores de los observables seleccionados.

Instantiate. Asignación de los valores de normalidad a los parámetros.

Compare. Comparación atributo por atributo.


Classify. Clasificación en base a ciertos datos históricos y estudio tanto pormenorizado como global de los resultados.

Tareas:

Disponemos de dos posibles corrientes de inferencias, partir de los observables relevantes para seleccionar las pruebas (Data driven monitoring), o partir de los parámetros seleccionados, de acuerdo a un criterio, para seleccionar los valores relevantes que conduzcan a la obtención de valores de comparación (Model driven monitoring).

En el pseudocódigo que utilizamos, se expresa también un paralelismo (inferencias separadas por “:”) en las dos líneas de inferencias (figura 7) que componen la tarea.

Data driven monitoring (+modelo sistema, +observables posibles, +selection criteria, + Parámetros Históricos Relevantes, - clase de decisión) by

REPEAT

select-2 (+observables posibles, - observables relevantes)

(Obtain-data (for relevant observables) :

select-1 (+modelo sistema, + observables relevantes, -parámetros elegidos))

(assign-value (+observables relevantes, -resultados) :

instantiate (+modelo sistema, +parámetros elegidos, -valores normalidad))

compare (+valores normalidad, +resultados, -cualificación resultados)

identify (+cualificación resultados, +historical data, -categorías-norm/anorm)

UNTIL categorías-norm/anorm <> Normalidad

Model driven monitoring (+Patient model, +possible observables, +selection criteria, +Relevant Historial Parameters, -decision class) by

REPEAT

select-1 (+modelo sistema, + selection criteria, -parámetros elegidos)

(instantiate (+modelo sistema, +parámetros elegidos, -valores normalidad) :

(select-2(+observables posibles,+Pruebas elegidas, - observables relevantes)

obtain-data (for relevant observables)

assign-value (+observables relevantes, -resultados)))

compare (+valores normalidad, +resultados, -cualificación resultados)

identify (+cualificación resultados, +historical data, -categorías-norm/anorm)

UNTIL categorías-norm/anorm <> Normalidad

3.8 Asignación de recursos

Es una tarea de carácter sintético, la solución se construye a partir de la información de que disponemos sobre componentes, recursos y restricciones. Si los recursos con los que se trabaja son de tipo temporal, se habla de scheduling. En cualquier caso, tiene una estructura del siguiente tipo: Primero se propone una solución parcial, que es verificada y si es necesario refinada o adaptada. Este método se suele referenciar como proponer-revisar.

La tarea de proponer consiste en combinar uno o más componentes con un recurso, de tal forma que al menos cumplan con las restricciones locales mas duras. Esto es: definición de una secuencia que especifique el orden en el cual los componentes deberían ser seleccionados, seleccionar una unidad de componentes (un solo componente o una agrupación: conjunto, clase u ordenación) y proponer una asignación. En la figura se ha tenido en cuenta también la posibilidad de una asignación parcial previa.

ensamblar componentes secuencia seleccionar unidad

Proponer

recursos

asignación

Restricciones locales

Fig. 57 Esquema inferencial de una primera descomposición de la subtarea “proponer”.

Tanto ensamblar como seleccionar admiten multiples métodos de resolución, que pueden incluir la clasificación de los componentes y de nuevo la satisfacción de

100

restricciones. En realidad, con los recursos puede ocurrir lo mismo, que requiera una agrupación y/o una ordenación a la hora de la asignación:

ensamblar recursos recursos

componente

asociar

Asignación propuesta

Asignaciones posibles

Restricciones locales

seleccionar

Fig. 58 Los recursos puede requerir una agrupación y/o una ordenación a la hora de la asignación.

Por otro lado, la subtarea revisar lleva asociadas, en una primer descomposición, dos subtareas: Evaluar la asignación propuesta obteniendo conflictos respecto de restricción no locales y modificar que toma un conjunto de los conflictos detectados y una asignación parcial y produce otra asignación pero modificada, en la que ya se resuelven (o minimizan) los conflictos.

Asignación parcial

evaluar Asignación

Conflictos

Restricciones no locales modificar

Fig. 59 Descomposición de revisar en evaluar y modificar.

Se pueden utilizar diferentes métodos para la tarea modificar, por ejemplo:

o Encontrar otro recurso al que se le pueda asignar el componente. Sería un backtracking cronológico, útil en problemas sencillos.

o Intentar intercambiar recursos y/o componentes entre tuplas de asignación, empezando con la tupla que intervienen en un conflicto.


102

o De forma similar al anterior, pero también intervienen combinaciones o series de intercambios.

o Otra aproximación es utilizar conocimiento explicito del dominio sobre cómo los conflictos pueden resolverse, por ejemplo, con reglas que reconozcan conflictos y propongan arreglos.

o Si intervienen restricciones sobre valores de variables, una opción es intentar modificar estos valores para resolver los conflictos.


Referencias

[Aguado, 1998] G. AGUADO, A. BAÑÓN, J.A. BATEMAN, S. BERNARDOS, M. FERNÁNDEZ, A. GÓMEZ-PÉREZ, E. NIETO, A. OLALLA, R. PLAZA & A. SÁNCHEZ. ONTOGENERATION: Reusing domain and linguistic ontologies for Spanish text generation. En Proceedings of the ECAI'98 Workshop on Applications of Ontologies and Problem Solving Methods, Brighton, U.K., 1998. European Conference on Artificial Intelligence.

[Álvarez, 1997] J.R. ÁLVAREZ. Aspectos Metodológicos en el Diseño de Redes Neuronales: Ejemplos de Aplicación en Identificación y Control. Tesis Doctoral, Facultad de Ciencias - UNED, Madrid, 1997.

[Barceló y Sánchez-Monge, 1999] G. Barceló, Mª. M. Sánchez-Monge. Evaluación de la herramienta Web Course Tool o WebCT. La experiencia de la Universitat de Les Illes Ballears, en Actas de EDUTEC’99, Sevilla, Universidad de Sevilla, 1999.

[Barr y Feigenbaum, 1981] A. Barr y E.A. Feigenbaum. The Handbook of Artificial Intelligence, William Kaufmann Vol. I., 1981. Vol. II. 1982. Reimpreso en 1986 por Addison-Wesley, Reading, MA.

[Barr et al., 1989] A. Barr, P.R. Cohen y E.A. Feigenbaum. The Handbook of Artificial Intelligence, Vol. IV. Addison-Wesley, Reading, MA, 1989.

[Benjamins y Aben, 1997] R. Benjamins, M. Aben. Structure-Preserving KBS Development through Reusable Libraries: a Case-Study in Diagnosis. International Journal of Human-Computer Studies, 47, 259-288.

[Benjamins et al., 1996] R. BENJAMINS, D. FENSEL & R. STRAATMAN. Assumptions of Problem-Solving Methods and their Role in Knowledge Engineering. ECAI'96 12th European Conference on Artificial Intelligence. (1996).

[Benjamins et al., 1998] R. BENJAMINS, E. PLAZA, E. MOTTA, D. FENSEL, R. STUDER, B. WIELINGA, G. SCHREIBER & Z. ZDRAHAL. (1998). An Intelligent Brokering Service for Knowldege-Component reuse on the Worl-Wide-Web. En Proceedings of 11th Workshop on Knowledge Acquisition, Modeling and Management (KAW'98), Banff, Aberta, Canadá. SRDG Publications, University of Calgary.

104

[Bielawski y Lewand, 1991] L. Bielawski y R. Lewand. Intelligent Systems Design: Integrating Expert Systems, Hypermedia and Database Technologies. Wiley and sons, 1991.

[Borgida et al., 1989] A. BORGIDA, R.J. BRACHMAN, D.L. MCGUINESS & L.A. RESNICK. CLASSIC: A structural data model for objects. En Proceedings of the 1989 ACM SIGMOD International Conference on Management of Data. 59-67.

[Borst el al., 1997] P. BORST, H. AKKERMANS & J. TOP. Engineering Ontologies. International Journal of Human-Computer Studies, 46, 365-406. (1997).

[Brachman y Levesque, 1985] R.J. Brachman y H.J. Levesque. Readings in Knowledge Representation. Morgan Kaufmann, San Mateo, CA, 1985.

[Breuker et al., 1987] J.A. Breuker, B.J. Wielinga, M. van Someren, R. de Hoog, A.T. Schreiber, P. de Greef, B. Bredeweg, J. Wielemaker, J.P. Billault, M. Davoodi y S.A. Hayward. Model friben knlwedge acquisition; interpretation model. ESPRIT Project P1098 Deliverable D1 (task A1), University of Amsterdam and STL Ltd., Amsterdam, The Netherlands. (1987).

[Breuker y Wielinga, 1989] J. Breuker y B. Wielinga. Models of expertise in knowledge acquisition. En: G. Guida y C. Tasso Eds., Topics in Expert System Design: Methodologies and Tools, North-Holland, Amsterdam, 1989, pp 156-195. (1989).

[Breuker y Van de Velde, 1994] J. Breuker, W. Van De Velde. Commonkads Library for Expertise Modelling. Reusable Problem Solving Components. Amsterdam, IOS Press (1994).

[Buchanan y Feigenbaum, 1978] E. Feigenbaum, B. Buchanan. DENDRAL and Meta-DENDRAL: Their applications Dimension. Artificial Intelligence, 11, pp 5-24, 1978.

[Buchanan y Shortliffe, 1984] B.G. Buchanan y E.H. Shortliffe. Rule-Based Expert Systems: The MYCIN Experiments of the Stanford Heuristic Programming Project. Addison-Wesley, Reading, MA, 1984.

[Buchanan et al., 1983] B.G. Buchanan, D. Barstow, R. Bechtal, J. Bennett, W. Clancey, C. Kulikowski, T. Mitchell y D.A. Waterman. Constructing an expert system. En: [Hayes-Roth et al., 1983], cap. 5, págs. 127-167.

[Bylander & Chandrasekaran, 1988] T. BYLANDER, & B. CHANDRASEKARAN. Generic Tasks in Knowledge–Based Reasoning: The Right Level of Abstraction for Knowledge


Acquisition. En: B. GAINES & J. BOOSE, eds., Knowledge Acquisition for Knowledge Based Systems, vol.1. Academic Press, London. (1988)

[Bylander y Mittal 1986] T. Bylander y S. Mittal. A language for Classificatory Problem Solving and Uncertainty Handling. AI Magazine 7 (3): 66-77. (1986).

[Clancey, 1993] W.J. Clancey. Notes on «Heuristic classification». Artificial Intelligence, 59 (1993) 191-196.

[Chandrasekaran, 1986] B. Chandrasekaran. Generic Tasks in Knowledge Based Reasoning: High-Level Building Blocks for Expert System Design. IEEE Expert, invierno, pp. 23-29 (1986).

[Chandrasekaran & Josephson, 1997] B. CHANDRASEKARAN & J.R.. JOSEPHSON. The Ontology of Tasks and Methods. Symposium on Ontological Engineering, AAI Spring Symposium Series. Stanford. (1997).

[Chandrasekaran et al., 1992] B. Chandrasekaran, R. J. Todd y J. Smith. Task.Structure Analysis for Knowledge Modelin”. Communications of the ACM, 35 (9). 124-136. (1992).

[Charniak y McDermott, 1985] E. Charniak y D. McDermott. Introduction to Artificial Intelligence. Addison-Wesley, Reading, MA, 1985.

[Clancey, 1985] W. Clancey. Heuristic Classification. Artificial Intelligence, 27. Pp. 289-350 (1985).

[Cohen y Feigenbaum, 1982] P.R. Cohen y E.A. Feigenbaum. The Handbook of Artificial Intelligence, Vol. III. William Kaufmann, 1982. Reimpreso en 1989 por Addison-Wesley, Reading, MA.

[Contreras y Martín, 1993] A. Contreras López y E. Martín Rodríguez. Consideraciones sobre el alumnado de la UNED. Veinte años de enseñanza a distancia (1972-1992). A Distancia (Revista de la UNED), número extraordinario “Veinte años de la UNED: 1972-1992” (1993) 36-42.

[Craik, 1943] K. Craik. The Nature of Explanation. Cambridge University Press. Cambridge, 1943.

[Cuena, 1995] J. Cuena, Notas sobre modelos de razonamiento. Facultad de Informática (UPM), Madrid. (1995).

[De Marco, 1982] T. De Marco. Structured Analysis and System Specification. Yourdon Press. New York.. (1982).

106

[Díez, 1994] F.J. Díez Vegas. Sistema Experto Bayesiano para Ecocardiografía. Tesis doctoral, Dpto. Informática y Automática, UNED, 1994.

[Dubois et al., 1993] D. Dubois, R.R. Yager y H. Prade (eds.). Readings in Fuzzy Sets for Intelligent Systems. Morgan Kaufmann, San Mateo, CA, 1993.

[Duda et al., 1976] R.O. Duda, P.E. Hart y N. Nilsson. Subjective Bayesian Methods for Rule-Based Inference Systems, en Proc. of the National Computer Conference, pp 1075-1082, (1976).

[Duda et al. 1978] R.O. Duda, P.E. Hart, N.J. Nilsson y G.L. Sutherland. Semantic Network Representation in Rule-Based Inference Systems. En D.A. Waterman y F. Hayes-Roth Eds. Pattern-Directed Inference Systems. Academic Press, New York, (1978).

[Eshelman, 88] Eshelman, L. . MOLE: A knowledge adquisiition tool for cover-and-differentiate systems. En Marcus, S. Eds. Automatic Knwledge Acquisition for Expert Sustems. Kluwer Academic Publishers, Holanda (1988).

[Falasconi & Stefanelli, 1994] FALASCONI, S. & STEFANELLI, M. A (1994). Library of Medical Ontologies. En Proceedings of ECAI94 Workshop on Comparison of Implemented Ontologie,. European Coordinating Committee for Artificial Intelligence (ECCAI). pp. 81-92. Amsterdam, The Nederlands.

[Farquhar et al., 1996] FARQUHAR, A., FIKES, R. & RICE, J. (1996). The Ontolingua Server: a Tool for Collaborative Ontology Construction. En KAW’96. SRDG Publications, University of Calgary. También disponible como Technical Report KSL-TR-96-26.

[Feigenbaum y Buchanan, 1993] E. Feigenbaum, B. Buchanan. DENDRAL and Meta-DENDRAL: Roots of Knowledge Systems and Expert Systems Applications. Artificial Intelligence, 59, pp 233-240, 1993.

[Fensel, 1995] FENSEL, D. Assumptions and Limitations of a Problem-Solving Methods: A Case Study. En B. GAINES & M. MUSEN, eds., Proceedings of the Knowledge Acquisition for Knowledge-Based Systems Workshop (KAW'95). Banff, Canadá (1995).

[Fensel, 2001] D. FENSEL. Ontologies: A Silver Bullet for Knowledge Management and Electronic Commerce. Springer-Verlag, Berling-Heidelberg, 2001.

[Fensel & Benjamins, 1996] D. FENSEL & R. BENJAMINS (1996). Assumptions in Model-based Diagnosis. 10th Banff Knowledege Acquisition for KBS Workshop (KAW'96). Banff, Canadá. SRDG Publications, University of Calgary.

http://ksl-web.stanford.edu/people/axf/papers/KSL-TR-96-26.ps


[Fensel & Bejamins, 1998a] D. FENSEL & R. BENJAMINS (1998a). Key Issues for Automated Problem-Solving Methods Reuse. En H. PRADE, ed., 13th European Conference on Artificial Intelligence (ECAI'98). John Wiley & Sons, Ltd.

[Fensel & Benjamins, 1998b] D. FENSEL & R. BENJAMINS (1998b). The Role of Assumptions in Knowledge Engineering. International Journal on Intelligent Systems, 13, 715-748.

[Fensel & Groenboom, 1997] D. FENSEL & R. GROENBOOM. Specifying Knowledge-Based Systems with Reusable Components. En Proceedings 9th International Conference on Software Engineering and Knowledge Engineering (SEKE’97), Madrid, 1997.

[Fensel & Straatman, 1998] D. FENSEL & R. STRAATMAN. The Essence of Problem-Solving Methods: Making Assumptions for Gaining Efficiency. International Journal of Human-Computer Studies, 49, 339-361.

[Fensel et al., 1998] D. FENSEL, E. DECKER, M. ERDMANN & R. STUDER. Ontobroker: Or How to Enable Intelligent Acces to the WWW. En Proceedigns of the 11th Banff Knowledge Acquisition for Knowledge-Based System Workshop (KAW98), Banff, Canada. SRDG Publications, University of Calgary, 1998.

[Fensel & Musen, 2001] The Semantic Web: A Brain for the Humankind. En el monográfico “Cooking up the Semantic Web” de IEEE Intelligent Systems, Marzo-Abril 2001.

[Fensel et al., 2003] D. FENSEL, J. Hendler, H. Lieberman & W. Wahlster (Eds): Spinning the Semantic Web. MIT Press, 2003.

[Fernández et al., 1997] FERNÁNDEZ, M., GÓMEZ-PÉREZ, A. & JURISTO, N. (1997). Methontology: From Ontological Art Towards Ontological Engineering. Spring Symposium Series. pp. 33-40. Stanford.

[Fernández-Galán et al., 1998] S. Fernández-Galán, J. G. Boticario, J. Mira. Problemas Resueltos de Inteligencia Artificial Aplicada. Addison-Wesley, 1998.

[Fridman Noy & Hafner, 1997] N. FRIDMAN NOY & C. HAFNER (1997). The State of The Art in Ontology Design. AI Magazine, Fall, 53-74.

[Gaines y Boose, 1992] R. Gaines y J.H. Boose. Knowledge Acquisition: Special Issue on KADS, n. 4. (1992).

[García-Aretio, 1994] L. García-Aretio. El material impreso en la UNED. En L. García-Aretio (ed.) Educación a Distancia Hoy. UNED, 1994.

108

[García-Aretio, 1997] L. García-Aretio. Una Propuesta de Estructura de Unidad Didáctica y de Guía Didáctica. En L. García-Aretio (ed.) El Material Impreso en la Enseñanza a Distancia. UNED, 1997.

[Genesereth & Fikes, 1992] M. R. GENESERETH & R. E. FIKES (1992). Knowledge Interchange Format, Version 3.0, Reference Manual. Logic Group, Report Logic-92-1. Computer Science Department, Stanford University.

[Genesereth, 1990] M. R. GENESERETH. The Epikit Manual. Epistemics, Inc. Palo Alto, CA. (1990).

[Gómez et al., 1997] A. Gómez, N. Juristo, C. Montes y J. Pazos, Ingeniería del Conocimiento. Centro de Estudios Ramón Areces, Madrid. (1997).

[Gómez-Pérez, 1998] GÓMEZ-PÉREZ, A. (1998). Knowledge Sharing and Reuse. En LIEBOWITZ, ed., The Handbook of Applied expert Systems. CRC-Press.

[Gómez-Pérez et al., 1998] GÓMEZ-PÉREZ, A., FERNÁNDEZ, M., BLÁZQUEZ, M. & GARCÍA-PINAR, J.M. (1998). Building Ontologies at the Knowleedge Level using the Ontology Design Environment. Disponible en http://delicias.dia.fi.upm.es/articulos/ode/ode.html

[González, 1997a] J. González. Internet y la Universidad a Distancia. A distancia, Otoño, 1997, pp. 64-69.

[González, 1997b] J. González. Material Didáctico y Servicios para la Educación a Distancia en Internet. A distancia, Otoño, 1997, pp. 70-76.

[González y Gaudioso, 1999a] J. González, E. Gaudioso. Aprender a formar en la UNED, Madrid. Editorial Paraninfo-UNED, 2000;

[González y Gaudioso, 1999b] J. González, E. Gaudioso. Un modelo operativo de Enseñanza a Distancia personalizada en Internet. En Actas de la Conferencia Nacional de informática Educativa (CONIED’99), Puertollano (Ciudad Real), noviembre 17-19, 1999.

[González y Gaudioso, 2000] J. González, E. Gaudioso. TutorT-UNED: Tutor telemático de la UNED, Madrid, UNED, 2000.

[González y Gaudioso, 2001] J. González, E. Gaudioso. Aprender y formar en Internet. Madrid, Paraninfo, 2001.


[Gruber, 1993] T. R. GRUBER. A translation approach to portable ontology specifications. Knowledge Acquisition, 5, 199-220. (1993)

[Gruber & Olsen, 1994] T. R. GRUBER & G. R. OLSEN. An Ontology for Engineering Mathematics. Stanford Knowledge Systems Laboratory Technical Report KSL-94-18. (1994).

[Hart, 1986] A. Hart. Knowledge Acquisition for Expert Systems. Kogan Page, Londres, 1986.

[Hayes-Roth et al., 1983] H. Hayes-Roth, D.A. Waterman y D.B. Lenat (eds.). Building Expert Systems. Addison-Wesley, Reading, MA, 1983.

[Heckerman, 1986] D. Heckerman. Probabilistic interpretations for MYCIN’s certain factors. En: L.N. Kanal y J.F. Lemmer (eds.). Uncertainty in Artificial Intelligence, Elsevier Science Publishers, Amsterdam, 1986, págs. 167-196.

[Heijst et al., 1983] G. van Heijst, A. T. Schreiber, B.J. Wielinga. Using explicit ontologies in KBS development. International Journal of Human-Computer Studies 45. 183-292. (1997).

[IUED, 97] Instituto Universitario de Educación a Distancia: Unidades Didácticas y Guías Didácticas: Orientaciones para su Elaboración. UNED, 1997.

[Jackson, 1990] P. Jackson. Introduction to Expert Systems. Addison-Wesley, Wokingham, GB, 1990. 2ª edición.

[Jannick et al., 1998] J. JANNINK, P. SRINIVASAN, D. VERHEIJEN & G. WIEDERHOLD (1998). Encapsulation and Composition of Ontologies. Proc. AAAI Workshop on Information Integration, AAAI Summer Conference, Madison WI.

[Juez y Díez, 1996] P. Juez Martel y F.J. Díez Vegas. Probabilidad y Estadística en Medicina. Aplicaciones en la Práctica Clínica y en la Gestión Sanitaria. Díaz de Santos, Madrid, 1996.

[Karbach et al., 1990] W. Karbach, M. Linster, A. Voss. Model-Based approaches: One label-one idea?. En Wielinga, Boose, Gaines Schreiber y Someren, Eds. Current Trend in Knowledge Acquisition. pp. 173-387. Amsterdam: IOS Press. (1990).

[Kiefer et al., 1995] M KIEFER, G. LAUSEN & J. WU. Logical Foundations of Object-Oriented and Frame-Based Languages. Journal of the ACM, 42, 1995.

110

[Kiryakov et al., 2002] A. KIRYAKOV, K. SIMOV & D. OGNYANOV. Ontology Middleware and Reasoning. En J. Davis, D. Fensel & Frank van Harmelen (eds.): Towards the Semantic Web. John Wiley & Sons, LTD. (2002)

[Klir y Folger, 1992] G. J. Klir y T. A. Folger. Fuzzy Sets, Uncertainty and Information. Prentice Hall, USA. (1992).

[Klir y Yuan, 1995] G.J. Klir y B. Yuan. Fuzzy Sets and Fuzzy Logic. Prentice-Hall, Englewood Cliffs, NJ, 1995.

[Krause y Clark, 1993] P. Krause y D. Clark. Representing Uncertain Knowledge. An Artificial Intelligence Approach. Intellect Books, Oxford, GB, 1993.

[Lacasa et al., 1989] P. Lacasa, A. Farjas, A. Oliver y P. Pardo. La Universidad Nacional de Educación a Distancia, UNED. Texto preparado por el Instituto Universitario de Educación a Distancia (UNED), Madrid, 1989.

[Laird et al., 1987] J.E. Laird, A. Newell y P.S. Rosenbloom. “Soar: An Architecture for General Intelligence”. Artificial Intelligence, Vol 33, pp 1-64, (1987).

[Lucas y van der Gaag, 1991] P. Lucas, L. van der Gaag. Principles of Expert Systems. Addison Wesley. 1991.

[Marcus, 1988] S. Marcus. Automatic Knowledge Acquisition for Expert Systems. Boston, MA, Kluwer. (1988).

[McCulloch y Pitts, 1943] W.S. McCulloch y W. Pitts. “A logical calculus of the ideas immanent in nervous activity”. Bulletin of Mathematical Biophysics, 5 (1943) 115-133.

[McGregor, 1991a] R. McGREGOR. The Evolving Tehcnology of Classification-based Knowledge Representation Systems. En J. SOWA, ed., Princples of Semantic Networks; Explorations in the Representation of Knowledge. San Mateo, Ca., Morgan Kaufmann (1991).

[McGregor, 1991b] R. McGREGOR. Inside the LOOM Classifier. SIGAR Bulletin, 2(3), 70-76, Junio 1991.

[McGuiness, 2003] D. MCGUINESS. Ontologies come of age. En D.Fensel, J. Hendler, H. Lieberman & W. Wahlster (Eds): Spinning the Semantic Web. MIT Press, 2003.

[Michie, 1993] D. Michie. “Turing’s test and concious thought”. Artificial Intelligence, 60 (1993) 1-22.


[Minsky, 1967] M. Minsky. Computation: Finite and Infinite Machines. Prentice-Hall, Englewook Cliffs, NJ, 1967.

[Miller y Masarie, 1990] R. Miller, F. Masarie. The Demise of the Greek Oracle Model for Medical Diagnostic Systems. Methods of Information in Medecine, vol. 29, pp. 1-2, 1990.

[Mira et al., 1995] J. Mira, A.E. Delgado, J.G. Boticario y F.J. Díez. Aspectos Básicos de Inteligencia Artificial. Sanz y Torres, Madrid, 1995.

[Musen y Schreiber, 1995] M.A. Musen, A. T. Schreiber. “Architectures for intelligent systems based on reusable components”. Artificial Intelligence in Medicine, 7, pp. 189-199. (1995).

[Musen et al. 1988] M.A. Musen, A.T. Schreiber. “Architectures for intelligent systems based on reusable components”. Artificial Intelligence in Medicine, 7. Pp. 189-199. (1988).

[Newell y Simon, 1963] A. Newell y H.A. Simon. “GPS, a program that simulates human thought”. En: E.A. Feigenbaum y J. Feldman (eds.). Computers and Thought, McGraw-Hill, Nueva York, 1963, págs. 279-293.

[Newell et al., 1963] A. Newell, J.C. Shaw y H.A. Simon. “Empirical explorations with the logic theory machine”. En: E. A. Feigenbaum y J. Feldman (eds.). Computers and Thought, McGraw-Hill, Nueva York, 1963, págs. 109-133.

[Newell, 1981] A. Newell The Knowledge Level. AI Magazine, summer 1981, 1-20.

[Newell, 1993] A. Newell: Reflections on the Knowledge Level. Artificial Intelligence, 59, 1993.

[von Neumann, 1951] J. von Neumann. “The general and logical theory of automata”. En: L.A. Jeffress (ed.). Cerebral Mechanisms of Behavior, Willey, Nueva York, 1951, págs. 1-41.

[Patil et al., 81] Patil, R.S., Szolovits, P. , y Schwart, W.B. Causal understanding of patient illnes in medical diagnosis. En Readingsin Medical Artificial Intelligence: The first decade. Clancey y Shortliffe (eds). Addison Wesley. MA (1981)

[Pearl, 1988] J. Pearl. Probabilistic Reasoning in Int elligent Systems: Networks of Plausible Inference. Morgan Kaufmann, San Mateo, CA, 1988. Reimpreso con correcciones en 1991.

[Pirlein & Studer, 1994] T. PIRLEIN & R. STUDER. KARO: An Integrated Environment for Reusing Ontologies. En L. STEELS, G. SCHREIBER & W. Van De VELDE, eds., A Future

112

for Knowledge Acquisition: Proc.\ of the 8th European Knowledge Acquisition Workshop, EKAW'94, pp.200-225. Berlin, Springer.

[Pople, 1981] H.E. Pople. Heuristic Mehtods for Imposing Structure on Ill-Structured Problems: The Structuring of Medical Diagostics. En P. Szolovitz ed., Artificial Intelligence in Medicine, Westview Press, Boulder Co. 1981, 119-185.

[Rich, 1983] E. Rich. Artificial Intelligence. McGraw-Hill, Nueva York, 1983.

[Ringland y Duce, 1986] G.A. Ringland y D.A. Duce. Approaches to Knowledge Representation: An Introduction. John Wiley & Sons, Nueva York, 1986.

[Rosenblueth et al., 1943] A. Rosenblueth, N. Wiener y J. Bigelow. “Behavior, purpose and teleology”. Philosophy of Science, 10 (1943) 18-24.

[Rumelhart et al. 1986] D. E. Rumelhart, G. E. Hinton, R. J. Williams: Learning Representations by Back-propagating Errors. Nature 323, pp. 533-536, 1986.

[Sánchez y Dormido, 1997] J. Sánchez, S. Dormido. Introducción a Internet e Infovía, Módulo I del Curso de Especialización Básica en Internet y sus aplicaciones en el mundo de la Educación y la Empresa, Madrid, UNED, 1997;

[Schreiber et al., 1987] G. Schreiber, B. Bredeweg, M. Davoodi y B. Wielinga, B. Towards a design methodology for KBS. ESPRIT Project P1098, Deliverable D8 (task b2). University of Amsterdam. (1987).

[Schreiber et al., 1993] G. Schreiber, B. Wielinga y J. Breuker. KADS A Principled Approach to Knowledge-Based System Development. Academic Press, Londres, 1993.

[Schreiber et al., 1999] G. Schreiber, H. Akkermans, Anjo Anjewierden, R. de Hoog, N. Shadbolt, W. Van de Velde y B. Wielinga. Knowledge engineering and Management: The CommonKADS Methodology. MIT Press, Cambridge, Mass. 1999.

[Shafer, 1976] G. Shafer. A Mathematical Theory of Evidence. Princeton University Press, New Jersey, (1976).

[Shafer y Pearl, 1990] G. Shafer y J. Pearl (eds.). Readings in Uncertain Reasoning. Morgan Kaufmann, San Mateo, CA, 1990.

[Shanon, 1950] C.E. Shanon. Programming a computer for playing chess. Philosophical Magazine, 41 (1950) 256-275.


[Shapiro, 1992] S.C. Shapiro (ed.). Encyclopedia of Artificial Intelligence. John Wiley & Sons, Nueva York, 1992, 2nd edition.

[Steels, 1992] L. Steels. “Components of Expertise”. AI Mazagine, 11(2).pp. 28-49. (1992).

[Stefik et al., 1993] M. Stefik, J. Aikins, R. Balzer, J. Benoit, L. Birnbaum, F. Hayes-Roth, E. Sacerdoti. Retrospective on the Organization of Expert Systems, a Tutorial. Artificial Intelligence, 59, pp. 221-224, 1993.

[Stefik, 1995] M. Stefik. Introduction to Knowledge Systems. Morgan Kauffmann, San Francisoc , 1993.

[Studer et al., 1996] R. STUDER, H. ERIKSSON, J.H. GENNARI, S.W. TU, D. FENSEL & M. MUSEN. Ontologies and the Configuration of ProblemSolving Methods. En B.R. Gaines & M.A. Musen (eds). Proceedings of the 10th Banff Knowledge Acquisition Knowledge-Based Systems Workshop, Banff, Canada, 1996.

[Tansley y Hayball, 1993] D.S.W. Tansley y C.C. Hayball. Knowledge-Based Systems Analysis and Design: A KADS Developer’s Handbook. Prentice-Hall, Englewood Cliffs, NJ, 1993.

[Trillas el al, 1995] E. Trillas, C. Alsina y J.M. Terricabras. Introducción a la Lógica Borrosa. Ariel, Barcelona, 1995.

[Turing, 1950] A.M. Turing. Computing machinery and intelligence. Mind, 59 (1950) 433-460.

[Ull y Usábel, 1993] E. Ull Pont y P. Usábel Hernández. La gestación de la Universidad a Distancia. A Distancia (Revista de la UNED), número extraordinario “Veinte años de la UNED: 1972-1992” (1993) 15-27.

[UNED, 2000] Anuario de Investigación 2000. UNED, Madrid, 2000.

[UNED, 2000a] Información General. Curso 2000/01. UNED, Madrid, 2000.

[UNED, 2000b] Ingeniería Técnica en Informática de Sistemas e Ingeniería Técnica en Informática de Gestión. Guía de la Carrera para el Curso 2000-01. UNED, Madrid, 2000.

[UNED, 2000c] Guía de Medios Audiovisuales 2000-01. UNED, Madrid, 2000.

[Van Heijst et al., 1995] T. Van HEIJST, S. FALASCONI, A. ABU-HANNA, G. SCHREIBER & M. STEFANELLI.. A case study in ontology library construction. Artificial Intelligence in Medicine, 7, 227-255. (1995)

114

[Van Heijst et al., 1997] Van HEIJST, G.; SCHREIBER, A. Th.; WIELINGA, B.J. “Using explicit ontologies in KBS development”. International Journal of Human-Computer Studies 45. 183-292.

[Waterman, 1986] D.A. Waterman. A Guide to Expert Systems. Addison-Wesley, Reading, MA, 1986.

[Weibel, 1999] S. WEIBEL. The state of the Dublin Core Metadata Initiative. D-Lib Magazine, 5(4), 1999.

[Winston, 1984] P.H. Winston. Artificial Intelligence. Addison-Wesley, Reading, MA, 1984.

[Zadeh, 1984] L.A. Zadeh. A Theory of Approximate Reasoning. En Machine Intelligence, 9, Hayes, J.E., Michie, D., Hulich, L.I., (Eds.), Wiley, New York, (1979).

Aspectos metodológicos del desarrollo de SBCs · requieren a menudo de una interacción...

Documents

Transcript of Aspectos metodológicos del desarrollo de SBCs · requieren a menudo de una interacción...