Diskussion zur Zielsetzung von KnowMore

Ständig in Bearbeitung !!



Welche Fragen will ich warum stellen?

Jede technische Detaillierung (und die ist unerläßlich !) kann m.E. erst erfolgen, wenn wir uns wesentlich klarer über die konkrete Zielsetzung des Projekts sind.

In den letzten Tagen habe ich 2-5 konkretere Szenarios mit verschiedenen Leuten diskutiert, bzw. mir aus Papieren selber konstruiert, die alle mit unserem Antrag m.E. verträglich sind und alle m.E. ganz unterschiedliche Projektschwerpunkte implizieren. Leider Gottes implizieren auch die meisten viel Beschäftigung mit Themen, die man boshafterweise als gelöst einstufen könnte (z.B. die semantische Unifikation durch Herrn Bachmann).

Ich will jetzt einmal versuchen, das compiliert wiederzugeben, was ich als Knut's Sicht herausgefunden zu haben glaube. Das erscheint mir konsistent mit Otto's KnowMore. Die Sache steht hiermit zur Diskussion. Etliches wird redundant bzw. löchrig sein. Überall dort sind Angriffspunkte und Unklarheiten, die wir gnadenlos ausdiskutieren müssen, um mögliche Angriffe von außen vorwegzunehmen.

In welcher Richtung auch immer, noch in diesem Monat müßten wir auf Papier gebannt mindestens folgendes geklärt haben:


Umfeld

Wir bewegen uns in einem Unternehmen. In einem Unternehmen hat man eine zwar im Fluß begriffene, aber zu jedem Zeitpunkt i.w. bekannte und überschaubare Menge von Informationsquellen. Im Prinzip kann man mit diesen nach Belieben hantieren (d.h. wir lassen uns zuerst einmal nicht auf die Unbekanntheiten z.B. des Internet ein).

In diesem Unternehmen gibt es knowledge work, d.h. komplexe, wissensintensive Prozesse gut ausgebildeter Fachkräfte, die Informationen suchen, nutzen, verarbeiten und erzeugen.

Diese Prozesse sind öfters wiederholte Tätigkeiten und erfordern Wissen, Datenverarbeitung und Dokumenthandling.

Diese Prozesse kann und will man auf absehbare Zeit nicht automatisieren, sondern man will durch eine Intensivierung von Informationserfassung und -bereitstellung die Qualität und Effizienz der Arbeit steigern. Begründen !!

In einem solchen Arbeitsvorgang spielt das Wissen neben Daten und Dokumenten keine gleichrangige Rolle, sondern führt den Prozeß.

In concreto kann das bedeuten: Wissen

Uns bekannte Beispiele für solche Aktivitäten:

Welche Rolle spielen die einzelnen Informationsformen hier?

Produktentwurf: es gibt Dokumente mit funktionalen Anforderungen und mit Entwurfsrichtlinien bzw. Normen, es gibt Listen mit Normteilen sowie Entwürfe früherer Aufträge. Wissen kann sein: in welcher Situation muß ich mich um welche Richtlinie kümmern? Wie erkenne ich aus einer funktionalen Spezifikation, daß ein Normteil paßt? Wie hängen Anforderungen und Entwurfscharakteristika zusammen? Wie folgen lokale Entwurfsentscheidungen aus Objektdaten des momentanen Entwurfszustands (KONUS)?

Kreditwürdigkeit: Eingabe sind Rohdaten der Bilanz und Kontenbewegungen, Einschätzungen von Auskunfteien, Meldungen aus der Presse, Kreditrichtlinien der Bank und gesetzliche Vorgaben. Wissen betrifft die Interpretation, Bewertung und Abwägung der einzelnen Hinweise gegeneinander.

Beratungstätigkeit: Ausgangsbasis sind Archive mit Best-Practice- und Lessons-Learned-Beschreibungen. Für ein neues Kundenproblem ist zu erkennen, daß die Situation genügend Ähnlichkeit mit einer der abgespeicherten Situationen besitzt, daß man die dort verwandten Vorgehensweisen ganz oder teilweise übertragen kann.

Bessere Beispiele ? Andere? ...

Nochmal anders herum: es geht darum, Daten und Dokumente durch Wissen zu nutzen, sie um es anzureichern oder es aus ihnen zu gewinnen. Dazu haben wir Beispiele:


Zweck der Übung

Da die Wissensanteile die wertvollen Bestandteile der Fachexpertise sind, der added value, der im Projektverlauf erzeugt und genutzt wird, sind sie Objekt unserer Begierde.

Das heißt: wir wollen nicht durch Hinzutun von Metawissen formales Wissen, Daten und Dokumente als gleichrangige Informationsträger besser zugreifbar, nutzbar und integriert verarbeitbar machen. Wir wollen also kein verbessertes Information Retrieval, keinen intelligenten Informationsbeschaffungsassistenten, kein Informations-XPS, kein Query Planning oder Integration Management.

Ziel ist es, zuvorderst Wissensanteile in Projekten zu erfassen, bzw. die Informationen zu liefern, die zum Wissensaufbau oder zu seiner Nutzung erforderlich sind.

Im Einklang mit den meisten CoMem-Ansätzen gehen wir nun davon aus, daß zur Zeit in Unternehmen solches Wissen, wenn überhaupt, dann in Dokumenten gefaßt ist - in Memos, Richtlinien, E-Mails, Kommentaren, ...

Im Gegensatz zu vielen CoMem-Ansätzen gehen wir weiterhin davon aus, daß es erstrebenswert ist, dieses Wissen überwiegend auch in den Dokumenten zu belassen.

Warum?

Unser Ziel ist es somit, im Unternehmen, mit möglichst wenig Wissensakquisitionsaufwand (d.h. möglichst on-the-fly), nützliches Wissen in Dokumentform zu speichern und immer dann diese Dokumente zur Verfügung zu stellen, wenn dies nützlich ist. Der Aufwand, der zu leisten ist, betrifft i.w. die Strukturierung der Wissensquellen und der Wissensinhalte.

Wir sind damit in der Zielsetzung bei van Heijst et al (Banff-KAW) und Gaele Simon (Banff-KAW), die unter dem Credo der besseren Capitalization vorhandenen Wissens fallbasierte Systeme, Papierarchive und ähnliche Beispiele aus der Praxis beschreiben (diese Beispiele sollte man im einzelnen durchgehen, herausfinden, wo Schwächen liegen könnten und ob wir zur Behebung beitragen könnten).

Meta-Bemerkung (AA): hier muss man noch weiter ausarbeiten, welche Rolle andere Wissensquellen als Dokumente spielen. In der momentanen Form sind die Dokumente absolut stark akzentuiert. So war die letzte Fassung, die ich mit Knut diskutiert hatte, wenn man sie soweit konsequent durchdenkt, wie das m.E. notwendig ist. Das heißt, wir verlieren u.U. viele interessante und machbare Dinge, z.B. im Bereich Query Planung, Zusammenschau heterogener Quellen, Informationssuche etc. ABER: so kann man die Geschichte auch soweit einengen und konkretisieren, daß man Land sieht bei der Frage, was wir denn nun eigentlich wirklich machen wollen. Man müßte m.E. jetzt bewußt und explizit einige Freiheitsgrade einschränken , um zur KONKRETEN Projektzielsetzung zu kommen. Das können ganz verschiedene sein. Was wäre hier möglich? Link machen!


Ansatz

Damit bewegt sich die KnowMore-Zielsetzung im klassischen Organizational Learning oder Corporate Memory-Bereich, nicht primär in der Gegend von z.B. Global Information Systems oder Multidatabase Systems.

In diesem Bereich muß man für ein eigenes Profil sich zumindest von klassischen XPS und vom Case-Based Reasoning abgrenzen, außerdem muß man ein eigenes Profil gegenüber etablierten Corporate Memory Gruppen, wie z.B. de Hoog/van der Spek oder Gael Simon zeigen. Dieses Profil kann nur geprägt sein von unserer Expertise aus ARC-TEC/IMCOD/VEGA heraus, basieren auf den praktischen Erfahrungen, die i.w. Otto gemacht hat und sollte Nutzen ziehen aus der Nähe zur Dokumentanalyse.

Abgrenzung zu XPS: to be filled in

Abgrenzung zu CBR: to be worked out

Unser Ansatz beruht somit auf folgenden Überlegungen:

  1. Dokumente und sonstige Informationsquellen werden defensiv formalisiert, d.h. wir annotieren auf einer Meta-Beschreibungsebene, dem Knowledge Description Layer. Die Annotation enthält das, was notwendig ist, um eine Informationsquelle für eine spätere Verwendung als relevant zu erkennen. Wissensquellen werden nicht in eine einheitliche, formal verarbeitbare Form gebracht, Dokumente werden nicht in ihrem semantischen Kontent möglichst vollständig formal erfaßt, sondern für die Verwendung wesentliche Beschreibungsmerkmale werden extrahiert.
  2. Anmerkung: Beschreibungsmerkmale aus der Natur des Wissens heraus, aus der Natur der Anwendungsbereiche heraus (Relevanz), mittendrin, Struktur der Unternehmung- die der Wissensquelle innewohnende Struktur kann wichtig sein - die Dienste, die das Dokument leistet (KQML) - die Inhalte festgemacht an Unternehmensmodellierung - die Zugriffsgeschichten - ...
  3. Ziel dieser Annotation ist es somit, die Wiederverwendung beliebiger Informationsquellen, d.h. insbesondere auch informalen und teilformalen Wissens in der Unternehmung zu ermöglichen. Ausgehend von dieser Problemstellung liegt es nahe, die beim Knowledge Sharing and Reuse zur Wiederverwendung formalen Wissens angestellten Überlegungen anzuschauen. Ausgehend vom Problemlösungsansatz, Strukturen auf Wissensarchive und Verwendungssituation zu legen, deren einfacher Match dann die Auswahl nützlichen Wissens erlaubt, kann man an sich an die Vorgehensweise des Knowledge Engineering nach KADS anlehnen.
  4. Kann man Kontextbildung aus der Konzentration auf nicht-formale Inhalte noch besonders motivieren??
  5. Unausgegoren: Mir scheint, die Kontextbildung wie im Saarberg-Beispiel mit der Neigung ist verwendungsspezifisch, daher von der Relevanz her zu motivieren. Andere Gruppierungen sind eine Sache der Darstellungsökonomie oder der Logik, weil sie sich auf Item-Gruppen oder Item-Klassen oder ganze Sourcen beziehen. Überhaupt sollte jede Beschreibungsinformation an beliebigen Objektmengen festgemacht werden können. Da auch Kontexte ihrerseits Mengen von Beschreibungselementen sein können, die ihrerseits auch im OL abgespeichert sein können, läuft das Ganze i.w. auf das Zusammenbinden von IE-Mengen mit IE-Mengen hinaus (IE definiere ich hiermit als Informationseinheit, infon bei van Rijsbergen).


Knowledge Description Layer

Anforderungen:

Inhalte: Merkmale von Wissensitems oder -Sourcen betreffen:

Die Definition der Beschreibungsdimensionen und ihrer Wertemengen kann man als Erstellung der Ontologie des Unternehmenswissens betrachten. Es ist zu fragen, wie weit man hier zu first principles gehen kann bzw. muß. Ottos Beispiel: man weiß, daß es Design Rules gibt, Qualitätsmaßstäbe, Entwurfsrichtlinien, ... Da man die Struktur hier m.E. nicht unabhängig vom Inhalt betrachten kann (Definition der Funktion eines Qualitätsmaßstabes bedingt eine Repräsentation von Unternehmenszielen), muß man sich über die Einbettung der Informationsontologie in die übrigen Unternehmensontologien Gedanken machen. Es mag aber auch sein, daß man sich hier rein auf der nicht-physischen Ebene bewegen kann.

Versucht man, in der Denke von KADS eine angepaßte Struktur der Welt auf Unternehmensinformationen zu entwerfen, ist es denkbar, daß es aus der Sache gerechtfertigt oder aus dem Machbarkeitszwang geboten ist, hier nur die Meta-Modellierungstools anzubieten, die eine unternehmensspezifische Strukturierung erlauben. Dann muß man ein Beispiel selber konkrete machen. Da auch die Erstellung einer solchen Ontologie unrealistisch erscheint, muß man sowohl die Integration existierender Modellierungsmethoden wie auch die Kopplung generischer First-Principle-Methoden mit konkreter Instanziierungsinformation bedenken.



Kontextbildung


Relevanzbeschreibungen



Einordnung in die KI

KI-Anwendungsgebiet

KI-Technologiebereiche

KI-Techniken

ENDE  !!

jetzt folgt nur noch baustelle ...


Was sind in diesem Zusammenhang typische Probleme beim Wissens-/Informationshandling?


=> wenn man das tut hat man aus kostengruenden die notwendigkeit zur wiederverwendung, schon die erste benutzung ist eine wiederverwendung, da man nie exakt die gleiche situation hat,

das knowledge sharing problem, das man versucht durch strukturierung nach allgemeinen gesichtspunkten (domaene, task, ...) zu loesen, haben wir in aehnlicher form - wieweit greifen die KI-Loesungen fuer allgemeine Probleme? wieweit traegt zumindest die denkweise, d.h. der ansatz, wenn auch nicht die loesung? - der nutzen kann sehr eingeschraenkt sein, weil wir ja keine problemloesung verkaufen, die wir beliebig irgendwo wiederverwenden wollen, sondern der grossteil der kreativen taetigkeit beim menschen bleibt und man nur verwendbare dinge liefern will

=> Wissen ist nun nicht dekontextualisiert moeglich - deshalb kontextfaktoren identifizieren und effektive Verwaltung ermoeglichen -