UNIDAD 2

Modelado y administración del conocimiento.

Unidad 2. Modelado y administración del conocimiento.

• 2.1 Introducción al modelado y administración del conocimiento. • 2.2 Métodos de modelado: modelos organizacionales CommonKADS, Modelos de procesos IDEF, Diagramas de clases UML, modelos relacionales de datos, ontologías. • 2.3 Formalización del conocimiento. • 2.4 Construcción y razonamiento.

2.1 Introducción al modelado

y administración

del conocimiento.

En la actualidad es cada vez más común utilizar el término gestión del conocimiento

(knowledge management) en las organizaciones,

según [1] “The Knowledge Creating

Company”, en una economía donde la única certeza es la incertidumbre, la única fuente

segura de ventaja competitiva es el conocimiento y de esto cada vez son más las

empresas que se dan cuenta.

Asimismo las últimas investigaciones, estudios y artículos acerca de la gestión

del conocimiento mencionan la importancia de herramientas que faciliten la captura, conservación,

organización, procesamiento y sobre todo difusión del conocimiento, de tal

forma que se transforme dicho recurso, hoy disperso, en un

“capital intelectual” administrable

Finalmente es importante aclarar, como se verá más adelante, que las tecnologías de información juegan un rol muy importante pero no son

el componente principal de la gestión del conocimiento y a

medida que se investiga más sobre este tema más se tiene la certeza que la esencia de la gestión del conocimiento son las personas.

En la actualidad, entender cuál es el rol de las tecnologías de información entorno a la gestión del conocimiento es la pieza clave

para no cometer un error de concepto.

Este error radica en concebir la implantación de la gestión del conocimiento como un tarea de la tecnologías de información.

Es importante comprender que las

tecnologías de información proveen el marco, pero no el contenido.

Antes de seleccionar y clasificar las diversas tecnologías de información es necesario entender el significado de lo que diversos autores llaman :

1.- herramientas de la gestión del

conocimiento O

2.- software de la administración del conocimiento.

Una de las mejores definiciones aportadas es la de: Ruggles (1997)2 que concibe este concepto como el software o herramienta que apoya y da soporte a las aplicaciones, actividades o acciones como la de generación, codificación y transferencia del conocimiento.

• Nonaka (1995) 1

• Takeuchi (1995) 2

Las clasificación de las tecnologías de información según la capacidad de generar o crear, codificar y transferir conocimiento con base en el Modelo de :

Espiral de creación del conocimiento:

• Sociabilización

• Externalización

• Internalización

• Combinación

Objetivo del modelo

• De está manera según el objetivo que persigue el modelo en vías de gestionar el conocimiento, la clasificación de las tecnologías de información sería la siguiente:

• Tecnologías enfocadas a la codificación y transferencia de conocimiento.

• Tecnologías enfocadas a la generación, codificación y transferencia de conocimiento

• Tecnologías enfocadas a la generación y codificación del conocimiento

1. Tecnologías enfocadas a la codificación y transferencia de conocimiento

Intranets Sitios web Document

management systems

2. Tecnologías enfocadas a la creación, codificación y transferencia de conocimiento

Groupware systems:

(Lotus Notes y Microsoft Exchange)

Business intelligence:

• - DSS Modelado Multidimensional

• -Data Warehousing, Data Marts y Data Mining

• -OLAP (On line analitic procesing)

-• Herramientas de consulta y reporte de datos

-• Portales de informacion empresarial

Knowledge based systems

3. Tecnologías enfocadas a la creación y codificación del conocimiento

Workflow systems

Knowledge map systems

2.2 Métodos de modelado: modelos organizacionales Common KADS, Modelos de procesos IDEF, Diagramas de clases UML, modelos relacionales de datos, ontologías.

La Ingeniería del Conocimiento (IC) posibilita la construcción de productos del aprendizaje tales como cursos, talleres, programas educativos, etc.; de manera interactiva, no lineal y a distancia; en las modalidades semi-virtual, virtual y colaborativa. Entre las metodologías con que cuenta la IC se destaca CommonKADS como el estándar europeo para el desarrollo de sistemas basados en el conocimiento.

Esta metodología es el resultado del proyecto ESPRIT KADS-II (P5248) que es una continuación del proyecto KADS. Cubre todos los aspectos del desarrollo de un SBC enmarcados en un único ciclo de vida de carácter espiral, que llega incluso a la definición del programa que finalmente será ejecutado. KADS-I (ESPRIT-I P1098) se quedaba en la definición del modelo conceptual. Una de las principales contribuciones de este proyecto es el introducir las últimas técnicas aplicadas en la ingeniería del software en el campo de la IA.

El trabajo se comenzó en 1983 En ese momento, la construcción de sistemas de conocimiento estaba enmarcada bajo el paradigma de desarrollo por prototipos y de representación del conocimiento a través de reglas de producción, con hardware y software de propósito especial como máquinas LISP y PROLOG

A pesar de que el proyecto terminó en 1994, se han seguido desarrollando investigaciones alrededor de CommonKADS. La metodología CommonKADS abarca todo el ciclo de desarrollo de software El proceso de desarrollo de SBC consiste en rellenar un conjunto de .plantillas de los modelos. Asociados a estas plantillas, CommonKADS define estados. de los modelos que caracterizan hitos en el desarrollo de cada modelo. Estos estados permiten la gestión del proyecto, cuyo desarrollo se realiza de una forma cíclica dirigida por los riesgos.

Hay seis modelos definidos en CommonKADS:

1.- Modelo de la Organización (OM): es una herramienta para analizar la organización en que el SBC va a ser introducido, y pretende descubrir problemas y oportunidades. 2.- Modelo de Tarea (TM) (Subpartes relevantes del proceso): describe a un nivel general las tareas que son realizadas o serán realizadas en el entorno organizativo en que se propone instalar el SBC y proporciona el marco para la distribución de tareas entre agentes.

3.- Modelo de Agente (AM): un agente es un ejecutor de una tarea. Puede ser humano, software o cualquier otra entidad capaz de realizar una tarea. Este modelo describe las competencias, características, autoridad y restricciones para actuar de los agentes. 4.- Modelo de Comunicaciones (CM): detalla el Intercambio de información entre los diferentes agentes involucrados en la ejecución de las tareas descritas en el modelo de tarea.

5.- Modelo del Conocimiento (de Pericia o de Experiencia - EM): este es el corazón de la metodología CommonKADS y modela el conocimiento de resolución de problemas empleado por un agente para realizar una tarea. El modelo de la experiencia distingue entre el conocimiento de la aplicación y el conocimiento de resolución del problema. El conocimiento de la aplicación se divide en tres subniveles: a) nivel del dominio (conocimiento declarativo sobre el

dominio) b) nivel de inferencia (una biblioteca de estructuras

genéricas de inferencia) c) nivel de tarea (orden de las inferencias).

6.- Modelo de Diseño (DM): mientras que los otros cinco modelos tratan del análisis del SBC, este modelo se utiliza para describir la arquitectura y el diseño técnico del SBC como paso previo a su implementación. En general produce la especificación técnica en términos de arquitectura, plataforma de implementación, módulos de software, construcciones de representación, y mecanismos computacionales para la implementación de SC.

Para los tres primeros modelos, del contexto, es posible utilizar 9 formularios o plantillas propuestas por CommonKADS:

Modelo Organizacional. Son 5 cuestionarios:

OM-1. Identificación del problema / oportunidad (lista de problema/oportunidades

percibidas, contexto organizacional [misión-visión-objetivos de la organización], lista de posibles soluciones).

OM-2. Aspectos Variantes (describe los aspectos que

podrían cambiar o ser afectados por la solución dada

por un sistema de

conocimiento).

OM-3. Proceso de la organización dividida en

partes (llenado

para cada tarea de la descripción del proceso).

OM-4. Activos de conocimiento (detalle del

elemento conocimiento de OM-2, descripción con granulo grueso, refinado en el modelo tarea y modelo conocimiento)

OM-5. Factibilidad (beneficios esperados, valor agregado esperado, costos esperados, comparación entre

posibles soluciones, cambios organizacionales requeridos, riesgos e

incertidumbres económicas y de negocios).

Para los tres primeros modelos, del contexto, es posible utilizar 9 formularios o plantillas propuestas por CommonKADS (continuaciíon):

Modelo de Tareas: 2 formularios (subporción de un proceso de la organización, actividad que agrega-valor de manera dirigida por metas).

• Análisis y descripción de la tarea dentro del proceso. TM-1.

• Elementos de conocimiento de la tarea. TM2.

Para los tres primeros modelos, del contexto, es posible utilizar 9 formularios o plantillas propuestas por CommonKADS (continuaciíon):

Modelo de agentes: 1 formulario (perspectiva proceso/tarea, perspectiva de agentes individuales).

•Formulario Agente

AM-1

Para los tres primeros modelos, del contexto, es posible utilizar 9 formularios o plantillas propuestas por CommonKADS (continuaciíon):

Resumen:

•Formulario 1

MODELO DE CONOCIMIENTO: Este modelo, describe el conocimiento que tiene un determinado agente y que es relevante para la consecución de una determinada tarea, además de describir la estructura del mismo en función de su uso. Para poder llevar a cabo este modelado de los distintos papeles que puede jugar el conocimiento, éste está distribuido en tres categorías:

MODELO DE CONOCIMIENTO: Conocimiento de Tareas: Conocimiento del Dominio: - Ontologías del Dominio - Modelos del Dominio - Conceptos - Propiedades - Expresiones - Relaciones Conocimiento sobre Inferencias:

MODELOS DE PROCESOS IDEF Es un subconjunto de la metodología del SADT (Structured Analysis and Design Technique) y se caracteriza por ser un método formalizado de descripción de procesos que permite evitar las dificultades que implica el uso de diagramas (por ejemplo, "grafos").

En el programa norteamericano del Departamento de Defensa denominado "Integrated Computer-Aided Manufacturing - (ICAM)" se ha reconocido su utilidad y se le ha estandarizado en llamado IDEF0 (ICAM Definition Method Zero[1]) - se pronuncia "eyedeff- zero"[2].

Bajo este nombre de IDEF0, la metodología del SADT se utiliza en cientos de organizaciones relacionadas con la defensa y en industrias de altas tecnologías.

En 1989 se constituyó una asociación de usuarios, el IDEF-Users Group (IDEF-UG).

El IDEF0 es muy utilizado para describir procesos de negocio (atendiendo a los objetivos centrales) y existen numerosas aplicaciones de software que apoyan su desarrollo. El IDEF0 guía en la descripción de cada proceso (o actividad) considerada como combinación de cinco magnitudes básicas que se representan gráficamente como:

Procesos o actividades

inputs (insumos)

controles

mecanismos o recursos para la realización de

tareas

Outputs o resultados

conseguidos en el proceso

* Pueden servir de entrada a otros procesos

*

El IDEF0 utiliza unos grafos de visualización de sus elementos, no sólo para facilitar la aplicación del método, sino para diferenciar claramente las magnitudes a tratar en aplicaciones de software. En realidad, esas magnitudes del modelo constituyen una variante del clásico modelo de bases de datos:

entity-relationship.

El elemento central del "diagrama" en que se describe (modeliza) el proceso es una forma rectangular a la que se unen ciertas flechas que representan inputs, outputs, controles, mecanismos que permiten funcionar:

Por ejemplo: en un proceso de producción: Los "inputs" designan la materia prima que es

transformada en la actividad (barra de acero a transformar en tubo, planos de trabajo).

Los "controles" designan las actividades o entidades que

influencia la forma en que trabaja el proceso; p.ej.: cumplir normas de seguridad, responder a exigencias del cliente, ejecutar planes de trabajo. El control marca restricciones u obligaciones y dirige las actividades.

Los "mecanismos" designan los factores que permiten las

operaciones desarrolladas en el proceso; p.ej.: personas, herramientas, software, información.

Los "outputs" designan el resultado de la actividad y se

transmiten a otros procesos

En el nivel más elevado puede tratarse de representar un proceso de negocios completo. A continuación y a un nivel inferior, este proceso se divide en varios bloques de actividades. De este modo se efectúa una descomposición en niveles jerárquicos de mayor detalle hasta llegar a un punto en que se disponga de datos suficientes para poder planificar los cambios que se consideren necesarios

Evidentemente, un proceso complejo consta de múltiples unidades sencillas encadenadas como se muestra en la fig. IDEF-3

La metódología del IDEF trabaja con una lógica de desglose que permite pasar del análisis de un proceso global al de sus subprocesos (similar a la lógica en la programación por objetos). Esto es lo que visualiza la figura IDEF-4

El "nudo" (rectángulo) del diagrama se desompone - en una especie de Zoom – en subnudos (sub-diagramas) que pueden oscilar entre tres y seis rectángulos, luego éstos se descomponen a su vez (si se considera necesario) en otros subdiagramas de cada nudo. Las conexiones entre los nudos del diagrama desglosado se articulan en los siguientes tipos:

Se prosigue la descomposición hasta completar la descripción de todos los aspectos y magnitudes relevantes del proceso.

Ventajas del uso del IDEF0 Como ventajas del IDEF para el análisis de procesos se consideran: La descomposición en niveles jerárquicos facilita la rapidez en la determinación del mapa de procesos y posibilita visualizar al nivel más alto las relaciones de cambio con los factores de éxito. Esto ayuda sobre todo en cambios radicales. El remontar a contracorriente la cadena/flujo de inputs-outputs permite determinar facilmente elementos que no agregan valor, o detectar limitaciones y cuellos de botella

Cuándo se recomienda el uso del IDEF0 · Cuando hay que preparar un modelo de proceso que facilite exactitud, detalle, y claridad en la descripción. · Cuando el proceso posee cierta complejidad y los otros métodos de descripción darían lugar a diagramas confusos. · Cuando se trata de modelar una amplia gama de procesos distintos en un PDL (Process Description Language) consistente y con capacidades de metrización . · Cuando se posee cierto tiempo para trabajar y desarrollar una descripción/modelo completo y correcto del proceso. · En el flujo de proceso. el uso de IDEF0 se recomienda en los puntos de identificación/definición (con aspectos metrizables), en la comprensión y delimitación de aspectos de problemas que se plantean en el proceso, en la presentación de soluciones, y en la estandarización de las mejoras/cambios.

ONTOLOGÍA

Ontología La ingeniería del conocimiento, y en particular el procesamiento de ontologías, son uno de los problemas en los que más se está centrando la atención en la informática actual. La razón principal es la emergencia de un nuevo conjunto de aplicaciones en las que las ontologías juegan un papel fundamental, la mayoría de las cuales se encuentran en dos campos: 1. la última generación de sistemas para la

Web (Web 2.0, Web Semántica)

2. la necesidad de integración de aplicaciones empresariales cada vez más distribuidas.

Definición de Ontología

• En la práctica informática, el término ontología ha adoptado unas connotaciones peculiares, alejadas de su sentido filosófico original.

• A partir de principios de la década de 1990 han proliferado las definiciones de ontología en la literatura informática.

• Gómez Pérez et al. (2005) proporcionan una discusión

completa; pero dentro de las más relevantes, entre las que destaca la dada por Gruber (1993), que es la más citada:

Definición de Ontología • A conceptualization is an abstract, simplified view of the

world that we wish to represent for some purpose.

• Every knowledge base, knowledge-based system, or knowledge level agent is committed to some conceptualization, explicitly or implicitly.

• An ontology is an explicit specification of a

conceptualization. The term is borrowed from philosophy, where an Ontology is a systematic account of Existence.

• For AI systems, what “exists” is that which can be represented

Definición de Ontología • La definición de Gruber fue clarificada por Borst

(1997): «An ontology is a formal specification of a shared conceptualization».

• Se pone el énfasis en dos ideas clave:

- Una ontología debe ser especificada usando un lenguaje formal, que pueda ser procesado por ordenadores y no sólo por personas

- La ontología es conocimiento compartido, fruto del consenso dentro de un grupo.

Elementos de una Ontología • Una ontología contiene reglas especificadas mediante

algún tipo de formalismo lógico.

• Estas reglas pueden cumplir varias funciones: - Restricciones y reglas de validación para asegurarse de que la ontología es coherente: “Todas las uvas deben ser o blancas o tintas” -Definición intensional de clases (en lugar de por simple enumeración de individuos): la clase “uvas” está compuesta por la unión de las “uvas tintas” y las “uvas blancas”

PARADIGMAS DE MODELADO DE ONTOLOGÍAS

• Actualmente existen diferentes formas de representación del conocimiento, desde simples listas de términos hasta lógicas muy expresivas.

• En la siguiente figura se puede apreciar el espectro de representación de conocimiento.

• En general, solo las redes semánticas y representaciones más expresivas son consideradas ontologías, aunque hay un cierto debate al respecto; obviamente, la clasificación de modelos cercanos a la frontera y de modelos híbridos es complicada, y pueden aparecer excepciones.

APLICACIONES DE LAS ONTOLOGÍAS

Comercio Electrónico

Búsqueda de Información en Internet

Biomedicina Bibliotecas Dogitales

Otros

2.3 Formalización del conocimiento

Se han de considerar los diferentes esquemas de razonamiento que se pueden utilizar para modelizar las diferentes necesidades de resolución de problemas identificadas en las fases anteriores

2.3 Formalización del conocimiento

En este punto, se ha de poder comprender la naturaleza del espacio de búsqueda y el tipo de búsqueda que habrá que hacer. Para ello, se puede comparar ésta con diferentes mecanismos prototípicos de resolución de problemas como la clasificación, abstracción de datos, razonamiento temporal, estructuras causales, etc.

2.3 Formalización del conocimiento

En esta etapa también tendrá que analizarse la certidumbre y completitud de la información disponible, dependencias temporales, o la fiabilidad y consistencia de la información. Se deberá descubrir qué partes del conocimiento constituyen hechos seguros y cuáles no. Para éstos últimos deberá adaptarse alguna metodología de tratamiento de la incertidumbre, de manera que ésta pueda ser modelizada dentro del sistema.

FIN DE LA CLASE

Discusión

• Qué podemos aprender de Francisco

• Procedimientos recomendados

• Conclusiones

Resumen

• Defina sus retos

– Tecnológico y personal

• Establezca expectativas realistas

– El dominio no se logra de la noche a la mañana

• No pierda de vista su objetivo

– Programas de orientación

Recursos

• <Texto del sitio de intranet aquí> <hipervínculo aquí>

• <Texto del material de lectura adicional aquí> <hipervínculo aquí>

• Estas diapositivas y recursos relacionados: <hipervínculo aquí>

¿PREGUNTAS?

APÉNDICE