Motivation

Die Motivation für diese Arbeit schöpft sich aus zwei Quellen: einsteils die Suche nach einfachen Lösungsansätzen für komplexe Aufgabenstellungen in einer immer komplexeren technischen Welt, und zweitens die Suche nach Möglichkeiten, all das im Zyklus der Problemanalysen und Problem­lösungen entstehende Wissen effizient zu kommunizieren.

Beiden Aufgaben fühlt sich der Autor verbunden – eine Verbundenheit, die nicht spontan entstanden ist, sondern bereits Jahrzehnte zurückreicht. Im Jahre 1977 wurde im Forschungszentrum Seibersdorf eine neue Steuerung für ein bestehendes Neutronenspektrometer geplant.
Dem Stand der Technik entsprechend sollte die veraltete Relais-Steuerung durch Mikroprozessortechnik abgelöst werden. Für die Realisierung dieser Steuerung wurde ein SC/MP-Mikroprozessor der Firma National verwendet (der unter dem Spitznamen „Scamp“, auf deutsch Taugenichts, besser bekannt war). Dieser Prozessor wurden mit 250 kHz getaktet, und die Software, die für die Ansteuerung von Motoren, Kupplungen, Hub- und Noniusmagnete des Spektrometers erforderlich war, umfasste knapp 250 Byte in Maschinenkode (nicht Kilobyte!).

Demgegenüber steht eine kürzlich erschienene Pressemitteilung (Die Presse vom 27.3.2007) mit der Schlagzeile „Das Zettabyte steht vor der Tür“. Bei dieser Meldung über einen neuen „Pegelstand der Informationsflut“ fühlt man sich zuerst unwillkürlich veranlasst, die suspekte Schreibweise in einem Fachwörterbuch nachzuschlagen, denn der Doppelkonsonant in „Zetta“ stört das bis dato bekannte Stakkato der Dimensionsrekorde: Mega – Giga – Tera – Peta – Exa.

Die Schreibweise ist tatsächlich richtig, also verbleibt nur mehr ein kleiner Rest an Unbehagen über die qualitative Botschaft: 1 Zettabyte ist eine Trilliarde Byte (10²¹), oder verständlicher ausgedrückt 1 Billion Gigabyte, oder wie man im englische Sprachraum sagen würde, one trillion billion Byte.

Woher kommt diese exorbitante Informationsflut? Wenn 5 Milliarden Erdbewohner als Autoren tätig wären, müsste jede Frau, jeder Mann und jedes Kind zwei Millionen Publikationen im Umfang einer Diplomarbeit schreiben (100.000 Zeichen). In Kenntnis solcher exorbitanter Zahlen wäre es wünschenswert, wenn sich die Informationstechnologie nicht immer nach der Decke der verfügbaren Ressourcen streckt. Aber auch Autoren sind hier gefordert, durch sorgfältige Wahl von Medien und Informationskanälen zur Reduktion der Informationsflut beizutragen.

Smarte Dokumente können in diesem Zusammenhang zwar keine universellen Patentrezepte anbieten, aber zumindest aufzeigen, das einfache und ressourcenschonende Konzepte möglich sind. Im nachfolgenden Teil dieser Einleitung wird der grundsätzliche Bedarf für „einfachen Lösungen“ an sich und für smarte Dokumente im speziellen argumentiert. Die Perspektive wird in weiterer Folge um das Thema „Wissenstransfer“ erweitert, wo smarte Dokumente in wörtlichen Sinn als „intelligente“ Lösung eine Rolle spielen.

Begriffsdefinition für smarte Dokumente

Smarte XML-Dokumente im Rahmen dieser Arbeit sind Text- oder Datendokumente, die ihr Anwendungsprogramm durch XSLT-Transformation in einem Browser selbst erzeugen und somit vollständige Anwendungen darstellen. Sie unterscheiden sich von typischen DHTML-Anwendungen durch die Möglichkeit, Neutransformationen gezielt zur Laufzeit durchzuführen und damit Aussehen und Funktionalität von Dokumente interaktiv an die Nutzerbedürfnisse anpassen zu können.

Smarte XML-Dokumente bestehen üblicherweise:

• aus einem zugrunde liegenden Dokumentmodell, das für eine Klasse von Dokumenten Struktur und Vokabular festlegt, z.B. Web-Formulare, Reports, Datenprotokolle oder „Wissensdokumente“. Wesentlicher Aspekt ist hier die Wiederverwendbarkeit der Modelle innerhalb einer Dokumentklasse;
• aus einer Stylesheet Bibliothek, die für die Produktion der Ergebnisdokumente zuständig ist, z.B. HTML/DHTML, PDF, SQL-Statements oder Graphdarstellung. Wesentlicher Aspekt ist hier die Entkopplung des spezifischen und üblicherweise aufwändigen Produktionscodes vom XML-Quelldokument;
• aus Javascript Funktionen für DHTML-Eigenschaften und DOM-Manipulationen;
• und den eigentlichen XML-Dokumenten als Instanzen der Dokumentklasse. Diese Dokumente enthalten nur die in Markup eingebetteten Daten und Texte, und keinen „unnötigen“ Code, der eine bestimmte Darstellung oder Verwendung aufzwingt.

Smarte XML-Dokumente sind in diesem Sinne vergleichbar mit der server-basierenden AJAX-Architektur, ein Konzept der asynchronen Datenübertragung zwischen Server und Browser, die es ermöglicht, HTML-Seiten zu ändern, ohne die Seite komplett neu laden zu müssen. Die asynchrone Kommunikation wird bei smarten Dokumenten ersetzt durch interaktive DOM-Manipulation.


Das nachfolgende Kapitel beschäftigt sich mit Anwendungsmöglichkeiten für Smarte Dokumente im Bereich objektorientierter Software-Entwicklung und agiler Projekte.

... weiter mit Komplexe Probleme - einfache Lösungen

Komplexe Probleme - einfache Lösungen

"For every complex problem, there is a
solution that is simple, neat, and wrong."

Dieses Zitat findet sich oft, zumindest sinngemäß, in der einschlägigen Literatur. Dem Zitat ist eigentlich nichts hinzuzufügen – außer vielleicht, dass es falsch ist. Speziell in der Software-Entwicklung gibt es eigentlich nur ein gravierendes Problem:

• dem Auftraggeber rechtzeitig klar zu machen, dass eine 90%-Problemlösung
  nur ein Zehntel der Entwicklungskosten erfordern würde,
• und dass die restlichen 10% seiner Wünsche niemals vollständig realisiert
  werden können, aber 90% der Entwicklungskosten verschlingen.

Auch wenn diese Argumentation ironisch überspitzt ist, kennzeichnet sie doch ziemlich treffend ein latentes Problem der vorausschauenden und alles umfassenden Planung, die Kundenwünsche und Produkteigenschaften bis ins Detail festlegt. Ein Problem, das sich üblicherweise in Terminverzug, Kostenüberschreitungen, unzufriedene Nutzer und fehlgeschlagene Projekte niederschlägt. Ein alternativer Lösungsansatz für IT-Projekte wäre, sich auf die Kernarchitektur zu konzentrieren und für nutzerspezifische Problemstellungen einfache und flexible Lösungen anzubieten, die erst vom Nutzer selbst finalisiert werden.

Genau hier findet sich ein Motivationsansatz für den Einsatz smarter XML-Dokumente. So einfach, wie XML als Scriptsprache im Grunde genommen ist, so einfach sind auch XML-Anwendungen zu realisieren – sofern sich die Komplexität der Aufgabenstellung in Grenzen halten lässt. Die Frage ist nur, wo gibt es einfach zu lösende Probleme zu finden? Die Antwort ist eigentlich nahe liegend: Dort, wo es komplexe Probleme gibt! Komplexe Probleme sind, wie einleitend zitiert, nicht einfach zu lösen, daher zerlegt man komplexe Probleme in einfache und lösbare Aufgabenstellungen.

:: Objektorientiertes Design – eine Architektur für einfache Lösungen

---

Insbesonders im Umfeld der objekt- und serviceorientierten Software-Entwicklung, wie zum Beispiel bei den Sprachbibliotheken Java und dotNET und den Software-Architekturkonzepten SOA und EAI, ist diese Vorgehensweise, also die Zerlegung komplexer Aufgaben in einfache und wiederverwend­bare Lösungen, eine grundlegende Design-Vorgabe.

::: Model-View-Controller Konzept (MVC)

Ein bekanntes Beispiel dafür ist das Model-View-Controller Konzept (MVC) für die Entwicklung grafischer Benutzeroberflächen in objektorientierten Anwendungen. Hier wird strikt zwischen den Aufgaben der Geschäftslogik (Model M),
der Visualisierung (View V) und
der Ablaufsteuerung (Controller C) getrennt und damit eine Aufteilung eines komplexen Gesamtproblems
auf einfacher lösbare Teilprobleme erzielt.

Die nebenstehende Abbildung zeigt das grundlegende MVC-Konzept. Dieses Konzept ist auch für smarte Dokumente interessant und wird am Beispiel eines Formulars näher behandelt.

::: Design Pattern (Software Entwurfsmuster)

Einen besonderen Stellenwert haben in diesem Umfeld bewährte Lösungskonzepte für immer wiederkehrende Problemstellungen. Diese Lösungskonzepte werden mit genauer Problem­beschreibung und Anwendungshinweisen als Design Pattern (Entwurfsmuster) publiziert.

Wiederverwendbares Design bietet erheblich mehr Vorteile (und Kostenersparnis) als wiederverwendbarer Code (Code Libraries), wie die nebenstehende Grafik andeutet [3]. Die grauen Kreise stellen anwendungsspezifische Teile der Lösung dar, während die orangen Kreise für wieder­verwendbare Software steht. Bewährte Lösungen in Form von Design-Patterns fördern die Stabilität eines Systems, da sie sich vorzugsweise auf die Kern-Architektur, also auf die immer wiederkehrenden Probleme beziehen.

Im rechten Teil der Grafik ist erkennbar, dass sich hier der Einsatz von smarten Dokumenten anbietet, die ja üblicher­weise die Schnittstelle zum Benutzer oder zu anderen Systemen bilden. Damit ließe sich im Idealfall das Design-Reuse bis zu den Endpunkten durchführen.

Am bekanntesten sind die 1995 von Gamma, Helms, Johnson und Vlissides publizierten GoF-Patterns, in weiterer Folge aber auch die von Craig Larman [14] vorgestellten GRASP-Patterns. Von den insgesamt 23 GoF-Patterns, die sehr konkrete Problemstellungen behandeln, werden
15 relativ häufig verwendet . Die GRASP-Patterns sind demgegenüber eher im Sinne von „Best Practices“ zu verstehen und hauptsächlich wegen des Buch-Bestsellers „Applying UML and Patterns“ von Craig Larman einem breiteren Entwicklerkreis bekannt. Nachfolgend einige der bekanntesten GRASP-Patterns:

• Expert (Wer soll bestimmte Aufgaben durchführen?)
• Creator (Wer soll bestimmte Objekte erzeugen?)
• Controller (Wer soll bestimmte Ereignisse behandeln?)
• Low Coupling (Wie erziele ich niedrige Abhängigkeit und hohe Wiederverwendbarkeit)
• High Cohesion (Wie halte ich die Komplexität beherrschbar?)
• Pure Fabrication (Was mache ich, wenn eine Aufgabe nicht sinnvoll zuteilbar ist?)
• Don't Talk to Strangers (Wie vermeide ich Abhängigkeit von indirekten Objekten?)

Knowing how to assign responsibilities
is what ultimately makes or breaks a system!

::: Antipattern

Antipattern beschreiben typische und immer wiederkehrende Fehler in der Software-Entwicklung. Sie sind eine interessante Alternative zum „konstruktiven“ Wissen, das Design Patterns vermitteln, denn aus Fehlern lernt man bekannterweise besonders nachhaltig. Insbesonders bei der Suche nach eleganten und einfachen Lösungen unterliegt man gerne der Magie typischer Fehler, und sei es nur schlampige Codierung oder mangelhafte Kommentierung. In diesem Sinne liefern Antipatterns daher durchaus einen Beitrag zu professionellem Vorgehen.

Einige typische Antipattern nach Brown [3] sind:

• Spaghetti Code (Design Antipattern)
• Golden Hammer (Design Antipattern)
• Reinvent the Wheel (Software-Architektur Antipattern)
• Analysis Paralysis (Projektmanagement Antipattern)
• Death by Planning (Projektmanagement Antipattern)

:: Agile Vorgehensmodelle – ein Motor für einfache Lösungen

---

Bei agilen Vorgehensmodelle, wie zum Beispiel dem Unified Process UP, sind die Bedingungen eigentlich ideal für den Einsatz einfacher und wiederverwendbarer Lösungskonzepte, zu denen smarte Dokumente zählen. Hier ist rasche Prototyp-Entwicklung und das Vertrauen auf bewährte
und getestete Lösungen gefragt.

::: Agiles Manifest und agile Prinzipien

Das agile Manifest besagt kurz und bündig:

• Personen und Interaktionen statt  Prozesse und Werkzeuge
• Funktionsfähige Software statt  umfangreicher Dokumentation
• Zusammenarbeit mit dem Kunden statt  Vertragsverhandlungen
• Reaktionen auf Änderungen statt  Verfolgung eines Plans

Und die agilen Prinzipien begründen und erweitern das agile Manifest:

1. Highest priority is the early and continuous delivery of valuable software;
2. Welcome changing requirements, even late in development;
3. Business people and developers work together daily throughout the project;
4. Working software is the primary measure of progress;
5. Agile processes promote sustainable development;
6. Simplicity - the art of maximizing the amount of work not done - is essential;
7. Continuous attention to technical excellence and good design enhances agility;
8. The best architectures, requirements and designs emerge from self-organizing teams;

Wie Larman [14] kommentarlos zu diesen Prinzipien anmerkt, traf sich 2001 eine Gruppe von Interessenten an iterativen und agilen Methoden (www.agilealliance.com) und formulierte diese Prinzipien, die den Geist der agilen Methoden ausdrücken sollen. Ob er mit diesem trockenen Kommentar eine stillschweigende Kritik verpacken wollte, ist schwer zu sagen – aber einige der Prinzipien erscheinen irgendwie unnötig oder unbegründet, z.B. „Agile processes promote
sustainable development“. Ein Prinzip wie dieses entspricht eher einem Wunschdenken und keiner nachvollziehbaren Argumentation. Besonders in der deutschen Übersetzung ist die Schwäche der Argumentation auffallend, aber „griffige“ Slogans im Original verlieren durch Übersetzung leider oft an Substanz.

Nichts desto trotz sind einige der Manifest-Punkte besonders bemerkenswert. Vor allem die positive Einstellung zu nachträglichen Änderungswünschen („Reaktion auf Änderungen statt Verfolgung eines Plans“) ist ein markantes Kennzeichen der agilen Vorgehensphilosophie. Diese Änderungswünsche werden normalerweise als besonders lästig und kontraproduktiv empfunden, hier versteht man sie aber als Generator für innovative Ideen: „Embrace change“. Die radikale Abkehr vom geradlinigen Kurs durchgeplanter Projekte setzt sich fort in der Forderung „Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen“ und „Funktionsfähige Software statt umfangreicher Dokumentation“.

Diese Prinzipien ergeben in Summe eine total neue Perspektive für Projektabläufe. Eine daraus abgeleitete Strategie könnte wie folgt aussehen:

• Vermeide detaillierte Pflichtenhefte, die Wochen oder Monate zur Erstellung erfordern und womöglich Architektur-Entscheidungen vorwegnehmen;
• Biete dem Auftraggeber statt dessen aktive Projektmitarbeit (und entsprechende Schulungen) an. Der Auftraggeber ist üblicherweise ein Fachmann für die Geschäftslogik, oder er delegiert einen Fachmann dafür;
• Lasse den Auftraggeber die Benutzeroberfläche finalisieren (Labels, Hilfstexte, Farben)
  und die erforderlichen Testfälle schreiben (nach entsprechender Schulung und mit ent­sprechendem Werkzeug). Er kennt, wie bereits erwähnt, die Geschäftslogik am besten;
• Binde den Auftraggeber in allfällige Code-Reviews ein, das fördert verständlichen und gut kommentierten Code

Voraussetzung für eine derart intensive Einbindung des Auftraggebers in die Software-Entwicklung sind natürlich einfache und verständliche "Aufgaben", wie sie zum Beispiel um Umfeld der script-basierenden Smarten Dokumente durchaus denkbar sind.

::: Der Unified Process und seine Phasen

Der Unified Process wurde parallel zur bekannten Unified Modeling Language UML von Ivar Jacobson, Grady Booch und James Rumbaugh entwickelt und veröffentlicht. Dieser Prozess, der auch als kommerzielles Produkt in Form von Entwicklungsumgebungen (Rational Unified Process RUP) zur Verfügung steht, umfasst folgende Phasen:

1. Konzeptionsphase (englisch Inception)
2. Entwurfsphase (englisch Elaboration)
3. Konstruktionsphase (englisch Construction)
4. Übergabephase (englisch Transition)

Wichtiges Merkmal ist die Unterteilung jeder Phase in Iterationen, die jeweils die Arbeitsschritte „Anforderungsanalyse“, „Geschäftsprozessmodellierung“, „Design“, „Implementierung“, „Test“
und „Auslieferung“ enthält. Der Unified Process ist somit ein evolutionär-inkrementelles Vorgehensmodell, dass durch laufende Neuorientierung typische Fehler des Wasserfall-Vorgehensmodells vermeidet.

1. Inception (Konzeptionsphase)

Die Konzeptionsphase erstreckt sich typischerweise über einige Wochen, ist also relativ kurz bemessen. Hier wird eine gemeinsame Vision aufgebaut, grundlegende Anforderungen definiert, eventuelle Risken identifiziert, eine vage Aufwandsschätzung durchgeführt und entschieden, ob das Projekt überhaupt realisierbar, oder ob z.B. Zukauf bzw. Outsourcing zielführender ist.

Nicht-Aufgabe der Konzeptionsphase sind:

• Alle Anforderungen zu definieren
• Alle Use Cases zu entwerfen
• Exakte Schätzungen abzugeben
• Die Architektur festzulegen

2. Elaboration (Entwurfsphase)

Die Entwurfsphase besteht üblicherweise aus zwei oder mehr Iterationen, die zwischen zwei bis sechs Wochen dauern. Hier entstehen:

• Die getestete Kernarchitektur (oder Prototyp)
• Lösungen für risikobehaftete Probleme
• Weitestgehende Definition der erkannten Anforderungen

Erst jetzt liegen exakte Schätzungen vor, also z.B. ob ein Projekt eine Million oder zwei Millionen Euro kosten wird. Der Auftraggeber muss also in eine mehrmonatige Entwurfsphase investieren, um zu wissen, ob er das Projekt überhaupt finanzieren kann. Demgegenüber steht aber die traditionelle Vorgehensweise: In ein detailliertes Pflichtenheft zu investieren, das spekulative Anforderungen beschreibt, und ein Ergebnis zu erhalten, das nicht den wahren Anforderungen entspricht.

Wenn die Entwurfsphase erfolgreich abgeschlossen ist, müssen funktionsfähige und herzeigbare Lösungen vorliegen. Um dieses Ziel in kurzer Zeit zu erreichen, ist es daher erforderlich, wichtige von unwichtigen Aufgaben zu trennen, und komplexe Probleme in einfach lösbare Teilaufgaben zu zerlegen. Hier bietet sich der Einsatz von XML-basierenden smarten Dokumenten an, die als selbstständige Lösungsansätze unabhängig von der entstehenden Architektur geplant werden können, z.B.:

• Abstraktion der Schnittstellen zu anderen Systemen durch XML-Dokumentmodelle;
• Simulation der Nutzerdialoge durch Smarte XML-Anwendungen wie z.B. Formulare und Reports.

3. Construction (Konstruktionsphase)

Die Konstruktionsphase wird durch die Iterationsschritte dominiert. Eine Iteration dauert etwa zwei bis sechs Wochen und beinhaltet ganz konkret definierte Aufgaben, die jeweils in der vorhergehenden Iteration geplant werden. Damit wird einsteils die evolutionäre Entwicklung unterstützt, also die durch unmittelbares Feedback getriebene Anpassung der Zielsetzungen, andererseits das unkontrollierte Anwachsen von Anforderungen und Funktionen verhindert („feature creep“).

Larman [14] weist in diesem Zusammenhang auf die große Bedeutung des Feedbacks vom Auftraggeber für die laufende Anpassung der Iterationsziele hin, z.B.:

• „Ja, so habe ich mir das vorgestellt. Aber wenn ich das jetzt ausprobiere,
  merke ich, dass es nicht ganz das ist, was ich will.“
• oder „Nein, Sie haben nicht verstanden, was ich wollte!“

4. Transition (Übergabephase)

Die Übergabephase beinhaltet auch beim Unified Process weitestgehend „Business as usual“, also Betatest, Endabnahme und gegebenenfalls Rollout und Schulung. Von Bedeutung ist in dieser Phase eventuell noch die Kontrolle und Überarbeitung der entstandenen Dokumentation, die ja laut agilem Manifest („Funktionsfähige Software statt umfangreicher Dokumentation“) keinen besonders hohen Stellenwert hat und daher ohne strikte Vorgaben nebenbei entsteht.

:: Standard Software – eine Plattform für einfache Lösungen

---

::: Client-Anwendungen mit MS Office

Microsoft Office bietet interessante Möglichkeiten für flexible Lösungen. Solche „Office-Anwendungen“ haben üblicherweise eine hohe Akzeptanz, da der Nutzer damit in einer ihm vertrauten Umgebung arbeitet. Office-Anwendungen lassen sich besonders gut als 90%-Lösungen „verkaufen“, mit dem Hinweis, dass die nutzerspezifische Finalisierung des Produktes (über Macros oder Parameter-Dateien) am besten durch den Nutzer selbst erfolgt. Das mag auf den ersten Blick etwas vermessen aussehen, aber die Qualifikation eines Durchschnitts-Nutzers sollte nicht unterschätzt werden (ein Großteil der Nutzer besitzt immerhin einen Führerschein und hat somit eine technisch anspruchsvolle Prüfung bestehen müssen!).

Solomon [23] unterscheidet hier zwischen Power-User und Programmierern. Power-User entwickeln oft eine überraschende Kreativität beim Einsatz von Standard-Software für die Automatisierung von Vorgängen, besitzen aber nicht die
grundlegenden Kenntnisse, um stabile, strukturierte und wartbare Software zu erstellen. Dieses Wissen muss von Programmierern beigestellt werden, die aber oft die Mächtigkeit der in Office integrierten Sprachunterstützung (Visual Basic) unterschätzen.

Die nebenstehende Abbildungen zeigt eine auf Excel/VBA basierende Anwendung für eine Bodenkunde-Forschungsanlage aus dem Jahr 1995. Die zugrunde liegende Excel-Umgebung ist in dieser Anwendung nur mehr indirekt erkennbar.

Die Abbildung läßt sich durch Anklicken vergrößert darstellen.

::: Browserbasierende Client-Anwendungen

Mit den lokal installierten Browsern (MS-IE, Netscape, Opera, Firefox) stehen dem Nutzer mächtige Entwicklungsumgebungen direkt zur Verfügung. Aktuelle Browser-Generationen basieren jetzt auf einer einheitlichen HTML-Interpretation und unterstützen Java-Applets und XML/XSLT.

Die traditionellen, auf CGI oder Thin-Clients basierenden Web-Anwendungen werden schrittweise durch moderne Techniken abgelöst, wobei zwei Trends erkennbar sind:

• Hochdynamische, framework-orientierte Konzepte wie z.B. AJAX,
  die durchaus mit Fat-Client Anwendungen konkurrenzieren können;
• Nutzung diverser Erweiterungsmöglichkeiten des HTML-Standards,
  z.B. durch Microformate.

Interessant ist in diesem Zusammenhang die kontroversielle Diskussion, die im Sog der Web 2.0 Euphorie entstanden ist. Das W3C [26] als maßgebliches Gremium für Web-Standards forciert Weiterentwicklungen in Hinblick auf das Semantic Web, die aber nicht immer den Erwartungen und Wünschen der Webprogrammierer entsprechen. Zum Beispiel der Versuch, mit XHTML das bewährte HTML fit für die Zukunft zu machen, hat vermutlich niemanden gedient. Andererseits wiederum wäre es schade, wenn die von Web-Designern hofierte Flash-Technik sich langfristig etablieren würde, anstelle der vom W3C geförderten XML-Sprache SVG für Grafik-Darstellungen und Animationen.

Wesentlicher Aspekt bei allen web-basierenden Anwendungen ist aber, wie bereits einleitend erwähnt, das Vorhandensein einer mächtigen Entwicklungs- und Laufzeit-Umgebung auf der Client-Seite in Form von Web-Browsern. Darauf basierend lassen sich einfach konzipierte, in ihrer Funktion aber komplexe Anwendungen realisieren.

:: Hochsichere Anwendungen – ein Zwang für einfache Lösungen?

---

Software wird in zunehmenden Maße für Anwendungen eingesetzt, deren Ausfall die Gefährdung von Menschenleben zur Folge haben kann. Ein konkretes Beispiel dafür sind elektronische Stellwerke auf Hochgeschwindigkeitsstrecken. Hier müssen Reaktionen auf Störungen im Schienennetz in Sekundenbruchteilen erfolgen, womit der Mensch als letzte Kontroll- und Entscheidungsautorität nicht mehr in Frage kommt. Rechnersysteme müssen hier autonom und „verantwortlich“ entscheiden. Um Rechnersystemen diese Verantwortung übertragen zu können, ist ein anerkannter Nachweis der Sicherheit erforderlich, der aufgrund der Unvorhersagbarkeit elektronischer Ausfälle nur auf probabilistischen Aussagen basieren kann.

Probabilistische Verfahren, wie zum Beispiel die Fault Tree Analysis FTA, verwenden zum Nachweis der Sicherheit statistischen Aussagen in der Art: „80% der Computer-Ausfälle sind hemmender Natur“. Damit lässt sich rechnerisch in einem redundant ausgelegten Voting-System ein sicherer Zustand anstreben, da „ausgefallene“ Rechner nicht mehr für eine sicherheitskritische Entscheidung „voten“ können, z.B. für das Signal „Freie Fahrt“. Für Software existieren allerdings kaum statistische Erfahrungswerte, außer der generalisierenden Vermutungen, dass Software nie fehlerfrei ist.

Sicherheitsrelevante Software-Systeme werden daher üblicherweise mehrfach redundant und in diversitärer Technik, also mit unterschiedlichen Entwickler-Teams, Programmiersprachen und Betriebssystemen realisiert, um gleichartige Software-Fehler auszuschließen. Diese unabhängigen Systeme müssen jeweils gemeinsam für eine Aktion stimmen (voten), die bei divergierenden Entscheidungen unterbleibt. Die nebenstehende Abbildung verdeutlicht dieses Prinzip:

Erkennbar in der Abbildung ist, dass ein Datenaustausch zwischen den diversitären Systemen zur gegenseitigen Kontrolle eine „unerwünschte“ Kopplung der ansonst unabhängigen Systemkonzepte darstellt. Hier wäre denkbar, den Datenaustausch durch ein unabhängig formuliertes und validierbares Dokumentmodell zu abstrahieren, XML also als zusätzliche „diversitäre“ Komponente anzuwenden, wie in der Abbildung gezeigt.

Abgesehen von dem genannten Konzept spricht allgemein viel dafür, Software für sicherheits­relevante Systeme so einfach wie möglich zu halten, um Fehler proaktiv aufzudecken oder den Nachweis der Sicherheit auf analytischem Wege zu erreichen. Eine der Möglichkeiten dazu wäre, UML-Sequenzdiagramme systematisch in Bezug auf mögliche Fehlzustände zu betrachten, wie die nachfolgende Abbildung zeigt (Quelle: http://www.softwarekompetenz.de).

Das nachfolgende Kapitel beschäftigt sich mit dem Thema Wissenstransfer und Anwendungsmöglichkeiten für Smarte Dokumente in diesem Bereich.

... weiter mit Wissenstransfer

Wissenstransfer

XML-Dokumente sind in erster Linie durch Metadaten strukturierte Textdokumente, und die Intention, anspruchsvolle Text-Informationen damit zu transportieren, stand bei der Entwicklung von XML ursprünglich im Vordergrund. Metadaten eignen sich aber naturgemäß auch besonders gut zur Strukturierung von Daten, und in der Praxis hat sich XML vorzugsweise in diesem Bereich etabliert, also als Datenprotokoll bzw. Datenschnittstelle, oder als Parameter- und Log-Datei für IT-Anwendungen.

Die ursprüngliche Intention, XML als Vehikel für anspruchsvolle Texte zu verwenden, gewinnt aber immer mehr an Bedeutung. Das zeigt sowohl der ständige Zuwachs an anwendungsspezifischen XML-Dialekten für Wirtschaft, Behörden, Forschung und Lehre, wie auch die Bemühungen, Konzepte aus dem Bereich der künstlichen Intelligenz (AI) durch XML zu repräsentieren. Die vom W3C geförderte Web Ontology Language OWL, aber auch der ISO-Standard „Topic Maps“ sind ein Beispiel dafür.

Wenn man Text als „Wissensrohstoff“ versteht, liegt es nahe, XML-Dokumente als Möglichkeit für den Wissenstransfer näher zu betrachten. Dazu ist es aber erforderlich, sich eingehender mit dem Begriffskomplex „Daten – Information –Wissen“ zu beschäftigen und allfällige Begriffsabgrenzungen durchzuführen.

:: Information und Wissen

---

::: Wissenspyramide

Eine gängige Darstellung der Begriffe „Daten“, „Information“ und „Wissen“ findet sich in der Literatur üblicherweise als Wissenstreppe oder Wissenspyramide. Hier sind diese Begriffe nach aufsteigender Wertigkeit angeordnet, wie die nachfolgende Abbildung zeigt.

:::: Daten

Daten sind Aussagen (Fakten) über Beobachtungen oder Objekte. Daten bestehen aus Zeichen wie z.B. Zahlen, Buchstaben oder Bildpunkte, die durch Grammatik, Syntax, Koordinaten oder andere Methoden in eine aussagekräftige Form gebracht wurden. Der Zahlenwert 18,5 in Verbindung mit der meteorologischen Einheit °C liefert zum Beispiel eine Aussage über eine Temperatur.

:::: Nachricht

Unter Nachricht versteht man allgemein die Übermittelung von Zeichen oder Zeichenketten zwischen Sender und Empfänger. Die Intention des Senders und eine mögliche Relevanz für den Empfänger wird dabei nicht betrachtet. Das Interesse gilt primär dem Übertragungskanal, also der ungestörten und fehlerfreien Übertragung.

:::: Information

Information besitzt im Unterschied zur Nachricht eine Relevanz für den Empfänger, üblicherweise einen Neuigkeitswert, und führt im allgemeinen zu einer Reduktion der Ungewissheit (manchmal aber auch zu einer Zunahme der Ungewissheit). Sowohl die eigentliche Begriffsdefinition wie auch die Begriffsabgrenzung zu „Wissen“ ist nicht ganz einfach. Kulen [12] zitiert einleitend:

„Information science is in the rather embarassing position
of lacking any clear understanding of its central notion“.

Weiters zählt er u. a. folgende Variationen für die Begriffsdefinition auf:

• Information ist ein Veränderungsprozess, der zu einer Zunahme an Wissen führt;
• Information ist nutzbare Antwort auf eine konkrete Fragestellung;
• Informationen sind kontextualisierte Daten;
• Information ist ein Fluss von zweckorientierten Nachrichten.

:::: Wissen

Wissen entsteht durch Vernetzung der Informationen mit persönlichen Erfahrungen, also mit bereits bestehendem Wissen. Wissen ist daher subjektiv, es existiert nur in den Köpfen der Menschen. Ohne Erfahrungskontext des Wissensträgers ist es oft nutzlos. Eine weiterführende Behandlung dieses Begriffs erfolgt im Kapitel „Implizites und explizites Wissen“.

:::: Pragmatik und Kompetenz

Pragmatik ist die Akkumulation von „handlungsrelevantem“ Wissen und darauf aufbauendem Handeln, das in weiterer Folge zu Fachwissen bzw. Kompetenz in einem bestimmten Wissensgebiet führt.

::: Weisheit und Exzellenz

Weisheit bzw. der aus betriebswirtschaftlicher Sicht passendere Begriff Exzellenz ist die Bildung von neuem Wissen durch Erkennen von Wissenszusammenhängen, die es ermöglicht, als Autorität aufzutreten bzw. einzigartig am Markt zu agieren.

:::: Implizites und explizites Wissen

Explizites Wissen kann als Spitze eines Eisberges verstanden werden, die über der Meeresoberfläche liegt und somit frei erkundbar ist. Dieses Wissen ist formalisierbar bzw. liegt bereits in formalisierter Form vor, zum Beispiel als Vortrag, Publikation oder Benutzerdokumentation.

Das Wissen über Design Patterns, um ein konkretes Beispiel anzuführen, ist nicht an einen persönlichen Erfahrungskontext gebunden, sondern lässt sich unmissverständlich als Richtlinie und Bauanleitung kommunizieren.

Dies trifft zumindest auf einen Großteil der GoF-Patterns zu, die auf spezielle Problemstellungen fokussiert sind. Für die GRASP-Patterns ist die Situation differenzierter zu sehen, sie beschreiben Basis-Konzepte im Sinne von „Best Practices“ und sind somit eher allgemein gehalten, sozusagend als „Initial-Zünder“ für eigene, kreative Umsetzungen. Hier ist bereits ein Erfahrungskontext gefordert, ein implizites Wissen, das über formalen Kenntnisse von Coding Standards und Computersprachen hinausgeht.

:: Wissenskommunikation

---

Wissenstransfer ist allgemein als Transformationsprozess zu verstehen, der Wissen aus einem subjektiven Kontext entnimmt, als Information (mehr oder weniger brauchbar) abstrahiert, und in einen neuen Kontext einbettet. Dieser Transformationsprozess verändert das ursprüngliche Wissen unter anderem durch:

• unvollständige oder missverständliche Abstraktion,
  die zu Qualitäts- und Bedeutungsverlust führen kann;
• Neubewertung und Zuordnung der Information in einem neuen Kontext,
  die zu einer Auf- oder Abwertung des Wissens führen kann;
• Bereitstellung neuer Heuristiken und Filter, die die Anwendung
  des Wissens fördern oder blockieren können.

::: Wissenstransfer-Modell

Das bekannte SECI-Modell nach Nonaka und Takeuchi, in der Literatur auch als Wissensspirale zitiert, zeigt die mögliche Phasen und Übergänge des Wissenstransfers. Das zyklische Durchlaufen dieser Wissensspirale führt zur Adaption, Verfestigung und Anreicherung des Wissensbestandes, sowohl individuell für den Einzelnen wie auch kollektiv für die Gruppe.

::: Barrieren der Wissenskommunikation

Die Wissenskommunikation wird nicht nur begrenzt durch das Unvermögen, implizites Wissen vollständig zu transferieren, sondern sie wird auch durch diverse Barrieren behindert. Altbekannt ist die Angst vor Machtverlust, die Wissensträger nur unwillig am Wissensprozess teilhaben lassen, oder aus anderer Sichtweise, das gezielte Streben nach Machterlangung, was aber im Ergebnis gleichbedeutend ist. Wenn Pöhm [20] zu Powerpoint-Folien den Ratschlag gibt: „Auf der Folie sollen nur Rumpfbotschaften stehen ... der Zuhörer darf ohne Ihre erklärenden Worte nichts damit anfangen können.“, dann geht es ihm vordergründig um die Steigerung der Spannung, nebenbei liefert er aber Wissensträgern eine Rechtfertigung für einen sparsamen Umgang mit Wissenspreisgabe.

Auch auf Empfängerseite gibt es Barrieren, die auf Verweigerung basieren. Schneider [22] zählt hier konkret auf:

• Positive Ignoranz: Zu wissen, was man nicht zu Wissen braucht;
• Schützende Ignoranz: Gewinnbares Wissen, dessen Erwerb aber sozial unverträglich oder unerwünscht wäre;
• Ignorierte Ignoranz: Halbwissen, ignorierter Qualifizierungsbedarf, Fatalismus;
• Unbewusste Ignoranz: Nichtwissen, dessen „Vorhandensein“ nicht gewusst wird.

Eine dritte Perspektive der Verweigerung, die den Bedarf an Wissenskommunikation überhaupt in Frage stellt, eröffnet sich aus strategischer Sicht, wie Dueck [5] in seiner Argumentation für „Lean Brain Management“ aufzeigt:

„Ungeheuerliche Mengen an Intelligenz werden an Probleme verschwendet,
die ihrerseits durch übermäßige Intelligenz erzeugt worden sind.“

Damit könnten auch von Seiten des Unternehmensmanagements Widerstand erwachsen, der über die reine Kosten-Nutzenbetrachtung hinausgeht. Die folgende Abbildung zeigt weitere Barrieren, die den Prozess des Wissenstransfers zwischen Sender und Empfänger behindern:

::: Wissenskommunikation – eine Illusion?

Wissen wird allgemein als persönlicher Besitz verstanden, der in einer subjektiven Erfahrungswelt verankert ist. Ob Wissen weitergebbar ist, hängt zum großen Teil von der Tiefe der Verankerung ab. Handlungsorientiertes Wissen ist aufgrund der pragmatischen Natur leichter zu beschreiben, also in eine verständliche Form zu überführen, als „emotionales“ Wissen wie zum Beispiel guter Geschmack bei Farbkombinationen. Chalmers verdeutlicht die Grenzen der Wissenskommunikation mit einer treffenden Frage: „Wie beschreibt man die mediative Qualität eines gedankenverlorenen Augenblicks?“. In einem Gedankenexperiment zeigt er auch eine Neurowissenschaftlerin, die ihr Leben lang in einem schwarz-weißen Raum eingeschlossen ist. Sie weiß zwar theoretisch alles darüber, wie das Gehirn Farbeindrücke verarbeitet, hat aber selbst noch nie eine Farbe erlebt.

Francis Crick, der gemeinsam mit J. D. Watson 1962 den Medizin-Nobelpreis für die Aufklärung der DNA-Struktur erhielt, vertritt die Meinung, dass Bewusstsein vollständig mit den Mitteln der Neurowissenschaften und Psychologie erklärbar ist:

„Ist einmal des Geheimnis … des Bewußtseins aufgeklärt,
dann wird der Mensch der Lösung des ganz großen Rätsels nahe sein,
… dem der Beziehung zwischen Gehirn und Geist“.

Mit diesem „Plädoyer für einen beherzten Pragmatismus hat Crick erhebliche intellektuelle Hektik ausgelöst“, meint Horgan, eine Hektik, die Kognitionsforscher, Philosophen, Psychiater und auch Informatiker erfasste. Horgan führt weiter aus, das abseits der pragmatischen Diskussion auch die Grundsatzdiskussion weitergeführt wird, ob Bewusstsein überhaupt erklärbar ist. Einer der Proponenten dieser als „Mystiker“ bespöttelten Gruppe, die den „radikalen Materialismus“ Cricks ablehnen, ist der bekannte Physiker Roger Penrose, der das Phänomen Bewusstsein im Bereich der nicht-deterministischen Quanteneffekte ansiedelt:

„Penrose and others have constructed a theory in which human consciousness
is the result of quantum gravity effects in microtubules. But Max Tegmark (Physical Review E)
calculated that the time scale of neuron firing and excitations in microtubules is slower than
the decoherence time by a factor of at least 10,000,000,000.“

Roger Penrose ist neben Stephen Hawking einer der populärsten Vertreter der modernen Physik und Kosmologie (Big Bang Theorie, Schwarze Löcher). Penrose wird auch mit dem bekannten Bild „Treppauf, Treppab“ von M. C. Eschers in Zusammenhang gebracht („Roger and his father are the creators of the famous Penrose staircase“).

Quellen:

• Chalmers, D. J.: Das Rätsel des bewußten Erlebens,
  Spektrum der Wissenschaft, Februar 1996, S. 42.
• Crick, F., Koch, C.: Das Problem des Bewußtseins,
  Spektrum der Wissenschaft, November 1992, S. 144.
• Horgan, J.: Ist das Bewußtsein erklärbar?, Spektrum der Wissenschaft, September 1994, S. 74.
• Roger Penrose: http://en.wikipedia.org/wiki/Roger_Penrose
• M. C. Escher: http://www.worldofescher/misc/penrose.html

:: Ansätze zur Wissenskommunikation

---

::: Wissensmanagement als Lösungsansatz

Wissensmanagement im Unternehmen ist als strategisches Anliegen relativ neu, nicht aber als geübte Praxis. Sowohl in Stabstellen (HR, QM, Marketing, Controlling) wie auch in Projekten und Teams wird Wissen seit langem in irgendeiner Form gepflegt und gefördert. Wissensmanagement im kleinen Rahmen hätte daher in erster Linie koordinierende Aufgaben, unter anderem:

• Einführung einer unternehmensweit einheitlichen Terminologie
• Förderung der Informations-Kultur
• Bereitstellung einer Informations-Infrastruktur (Intranet, Foren)
• Management der Wissensträger (Skill-Datenbank)
• Angebot an Weiterbildungsmaßnahmen

Darüber hinaus gehende Ansätze sind kaum ohne vorausgehende Bedarfserhebung, Analyse und intensive Planung sinnvoll, da sie einen erheblichen Eingriff in die Unternehmensstruktur und in eingespielte Abläufe bedeuten. Durch divisionale und hierarchische Grenzziehungen besteht ein Unternehmen üblicherweise aus vielen „Wissensinseln“, wie die nachfolgende Abbildung verdeutlicht:

::: Lean Brain Management

Dueck [5] sieht in diesem Zusammenhang einen alternativen Lösungsansatz, der auf Wissensmanagement weitgehend verzichtet:

„Lean Brain Management zerteilt rigoros alle Arbeit in einfache Routineteile und
intelligente Teile. Der Routineteil kann von jedem nach kurzem Training erledigt werden.“

Dieser Ansatz deckt sich zwar mit dem roten Faden dieser Arbeit: „Einfache Lösungen für komplexe Probleme“, nicht aber mit der Intention. Dueck sieht in weiterer Folge den Bedarf, Intelligenz im System zu verankern, und nicht in Personen, für ihn steht dabei aber das Einsparungspotential im Vordergrund („Intelligenz ist sehr teuer! Akademiker kosten Unsummen!“) und nicht die Vision eines „intelligenten Systems“ im Sinne von künstlicher Intelligenz oder sematikbasierender Technologien.

::: Wikis und „Social Software“ als Lösungsansatz

Wikis sind, soferne sie im großen Rahmen betrieben werden wie zum Beispiel Wikipedia, eine hochqualitative und systematisch organisierte Fundstelle für Wissenssuchende. Im kleinen Rahmen, z.B. als Unternehmens- oder Projekt-Wiki, sind sie mangels Informationsbreite nur bedingt nützlich. Einsteils fehlt der wünschenswerte Serendipity-Effekt, also das Auffinden unerwarteter Querverbindungen zu anderem Wissen, andernteils sind Wiki-Formate nur bedingt kompatibel zu anderen Systemen und somit nicht in eine homogene Wissenslandschaft integrierbar.

Insbesonders wenn die Fülle der scriptbasierenden Formatvorlagen genutzt wird, steigen die Anforderungen an die Autoren beträchtlich und die Wiederverwendbarkeit der Inhalte ist nicht mehr gegeben. Die nachfolgende Abbildung zeigt eine Formatvorlage für Biographien, wobei im rechten unteren Ausschnitt ein Teil des Scriptcodes erkennbar ist, der zur einheitliche Beschreibung von Personendaten verwendet wird:

Durch den oft „vertraulichen“ Charakter von Unternehmenswissen ist auch die Nutzung der öffentlichen Portale keine Alternative zu lokal installierten Wikis, obwohl gerade hier das Feedback durch die große Autorengemeinschaft besonders interessant wäre. Zu beachten ist in diesem Zusammenhang auch, dass z.B. wikipedia.de eine Stiftung nach dem Recht des US-Staates Florida ist und von der dort ansässigen Wikimedia Foundation betrieben wird. Insbesonders im Bereich von „Social Tagging“-Anwendungen wie z.B. „XING“ könnte es hier zur unerwünschten kommerziellen Auswertung der großzügig angelegten Autorenprofile und Informationen kommen.

::: Smarte XML-Dokumente als Lösungsansatz

Smarte Dokumente bieten sich für Wissenskommunikation vorzugweise dann an, wenn eine auf Datenbanken basierende Lösung nicht in Frage kommt. Dies ist üblicherweise in kleinen bis mittleren Projekten der Fall, wo umfangreiche Dokumentation nach Projektabschluss an den Auftraggeber zu übergeben ist. Der Vorteil von xml-basierenden Dokumenten gegenüber Word oder HTML ist gezielt argumentierbar, wie die aufgelisteten Transformations-Möglichkeiten zeigen:

• navigierbare Webseiten (HTML),
• Vortrags-Präsentationen (DHTML Slide-Show),
• grafische Darstellung (z.B. Wissenslandkarten)
• ausdruckbare Dokumente mit Kapitelgliederung (PDF),
• und semantische Repräsentationen

XML ist im Gegensatz zu HTML (und Word) ein objektorientiertes Dokumentformat, somit lassen sich Dokumentstellen nicht nur „verlinken“, sondern als Objekte konkret wiederverwenden. Der Bedarf dafür läßt sich am Beispiel einer Webpräsenz für Unternehmen erkennen, wo Produkte, Projekte, Publikationen, Personenprofile usw. dargeboten werden. Produkte werden in Projekten verwendet, Personen betreuen Projekte und Produkte, Publikationen beschreiben Produkte und Projekte.

Es ist erkennbar, dass hier eine große gegenseitige Abhängigkeit mit potentiell redundanten Informationen existiert. Ein einfacher Lösungsansatz ist, alle beteiligten Dokumente über eine „Wissenslandkarte“ zu indexieren und damit eine zentrale Instanz zu schaffen, die von allen Dokumenten genutzt wird. Eine ins Detail gehende Betrachtung dieser Möglichkeit erfolgt am
Beispiel „Intranet Website“.

::: Information Intelligence als Lösungsansatz

Die direkte Wissenskommunikation von Mensch zu Mensch ist im Normalfall die effizienteste Methode, da hier durch Dialog Missverständnisse unmittelbar ausgeräumt werden können. Idealerweise findet so ein Dialog zwischen „Meister und Lehrling“ statt, oder zwischen „Trainer und Schüler“. Im Berufsalltag kann man allerdings nicht von solchen Idealvoraussetzungen ausgehen, hier ist zielführende Wissenskommunikation oft ein schmaler Pfad zwischen „Dumm sterben lassen“ und manipulativer Information. Insbesonders das für Unternehmen wichtige Wissen aus dem operativen Geschehen, seien es nun Frühwarnsignale oder Verbesserungsvorschläge, wird nicht entsprechend kommuniziert oder nicht verstanden. Oft ist daher der Zugriff auf formalisiertes Wissen, das vielerorts und in vielfältiger Art bereits in Dokumentform existiert, eine interessante Alternative, wenn nicht überhaupt die einzige zielführende Möglichkeit.

Durch das Zusammenführen von komplementären, also von verschiedenen Autoren unter verschiedenen Perspektiven erstellten Informationen, lassen sich manipulative Einflüsse kompensieren und neue Gesamtzusammenhänge erkennen. Dieses als „Information Intelligence“ bekannte Vorgehen liefert in vielen Anwendungsbereichen gute Erfolge, z.B. bei der Bekämpfung der Wirtschaftskriminalität („Fraud Detection“) und bei der Analyse des Unternehmensumfeldes („Competitive Intelligence“). Im Rahmen dieser Arbeit sind es vor allem zwei konkrete Techniken, die von Interesse sind: Textmining und Vektorraummodelle.

:::: Textmining

Textmining und damit verbunden die Bedeutungsanalyse von Text basiert auf statistischen, regelorientierten und musterererkennenden Verfahren, die auf große Textmengen angewendet werden. Heyer et al. [9] beschreiben dieses Verfahren im Detail und bieten damit eine tiefen
Einblick in die zugrundeliegende Technologie des Textminings. Auf der zugehörigen Webseite
wortschatz.uni-leipzig.de sind die Ergebnisse eines Textmining-Projektes, das über 6 Millionen Worte (Vollformen) und 15 Millionen Beispieltexte umfaßt, für Interessierte zugänglich.

Die mit Textmining erzielbaren Ergebnisse sind für Linguisten zu dürftig, aber für viele Problem­stellungen der natürlichen Sprachverarbeitung eine brauchbare Unterstützung. Die syntaktische Analyse des Satzes „Der Knochen frisst den Hund“ zum Beispiel würde keinen Fehler erkennen, sehr wohl aber eine semantische Analyse, die auf der Häufigkeitsverteilung von Kookkurrenten basiert, also dem gemeinsamen Auftreten von Wortformen. Die Kookkurrenz „Der Knochen frisst“ dürfte in der Literatur eine Seltenheit und somit der Satz in Frage zu stellen sein.

:::: Vektorraummodelle

Vektorraummodelle dienen zur Klassifikation von Dokumenten bzw. zur Relevanzbestimmung von Dokumentinhalten. Hier wird auf Basis der Termfrequenz, also der in den Dokumenten enthaltenen signifikanten Begriffe, eine Ähnlichkeit der Inhalte berechnet, die es erlaubt, aus einer Vielzahl von Dokumenten zusammenpassende zu finden. Im Gegensatz
zu Textmining findet bei diesen Verfahren keine semantische Bedeutungsanalyse statt, sondern eine Abstraktion der Begriffe in einem vieldimensionalen Vektorraum.

Insbesonders die auf Kernel-Methoden, also auf maschinellem Lernen basierende „Support Vector Machine“ liefert hier gute Ergebnisse. Die nebenstehende Abbildung zeigt das grund­legende Prinzip der merkmalstrennenden Hyperebene in einem vieldimensionalen „Feature-Raum“ (Markowetz [17]). Interessant ist in diesem Zusammenhang, dass diese Methoden mit besonderem Erfolg in der Gensequenz-Analyse angewendet werden, also bei der Entschlüsselung des genetischen Codes.

Literaturverweise

1. Balzert, H.: Lehrbuch der Software-Technik, Spektrum Akademischer Verlag, Berlin/Heidelberg, 1996
2. Birbeck, M. et al.: Professional XML, 1st Edition, Wrox Press, Birmingham, 2001
3. Brown, W. J. et al.: Anti Patterns, Wiley, New York, 1998
4. Chen, C., Geroimenko, V.: Visualizing Information using SVG and X3D, 1. Edition, Springer, Berlin/Heidelberg, 2004
5. Dueck, G.: Lean Brain Management. Erfolg und Effizienzsteigerung durch Null-Hirn, Springer, Berlin, 2006
6. Forssman, F., Willberg, H. P.: Lesetypographie, Verlag Herrmann Schmidt, Mainz, 1997
7. Fuhr, N. (Editor) et al.: Advances in XML Information Retrieval: Third International Workshop of the Initiative for the Evaluation of XML Retrieval, INEX 2004, Dagstuhl Castle, 2004, Springer, Berlin/Heidelberg, 2005
8. Gomez-Peres, A. et al.: Ontological Engineering, Springer, 2004
9. Heyer, G. et al.: Text Mining. Wissensrohstoff Text, Verlag W3L, Bochum, 2006
10. Jung, E. et al.: Professional Java XML, Wrox Press, Birmingham, 2001
11. Kay, M.: XSLT Programmer's Reference, 2nd Edition, Wrox Press, Birmingham, 2001
12. Kuhlen R. et al.: Grundlagen der praktischen Information und Dokumentation, 5. Ausgabe, K. G. Saur, München, 2004
13. Krcmar, H.: Informationsmanagement, Springer, Berlin/Heidelberg, 2005
14. Larman, C.: UML 2 und Patterns angewendet. Objektorientierte Softwareentwicklung, mitp-Verlag, Bonn, 2005
15. Höhn, R., Rosenkranz, H.: Standards für ontologiebasierende Anwendungen, in Makolm, J., Wimmer, M.: Wissensmanagement in der öffentlichen Verwaltung, Österreichische Computer Gesellschaft, Wien, 2005
16. Kirk, C., Pitts-Moultis, N.: XML Black Book, Coriolis Technology Press, Scottsdale, 1999
17. Markowetz, F.: Klassifikation mit Support Vector Machines. Max Plank Institut für Molekulare Genetik, 2003
18. Mizoguchi, R. (Editor) et al.: The Semantic Web ASWC 2006: First Asian Semantic Web Conference, Beijing, China, September 3-7, 2006, Proceedings, Springer, Berlin/ Heidelberg, 2006
19. Park, J.: XML Topic Maps. Creating and Using Topic Maps for the Web, Addison-Wesley, Boston, 2003
20. Pöhm, M.: Präsentieren Sie noch – oder faszinieren Sie schon? Der Irrtum Power-Point, mvg-Verlag, Heidelberg, 2006
21. Russel, S., Norvig, P.: Künstliche Intelligenz. Ein moderner Ansatz, Prentice Hall/Deutsche Ausgabe bei Pearson Education, München, 2004
22. Schneider, U.: Das Management der Ignoranz. Nichtwissen als Erfolgsfaktor, Deutscher Universitätsverlag, Wiesbaden, 2006
23. Solomon, C.: Anwendungen entwickeln mit Office, Microsoft Press, 1995
24. Staab, S., Studer, R.: Handbook on Ontologies, Springer, Berlin/Heidelberg, 2004
25. Stein, E.: Taschenbuch Rechnernetze und Internet, Fachbuchverlag Leibzig im Carl Hanser Verlag, München/Wien, 2001
26. W3C, World Wide Web Consortium, w3.org