Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

09.05.1986 - 

Bürodokumentar (Teil 5):

Konfortable Bürowerkzeuge durch Dokumentklassen-Konzept

In der vorangegangenen Folge wurde gezeigt, daß das Konzept von Dokumentklassen im ODA-Standard eine wesentliche Grundlage für die Automatisierung und Unterstützung von Bürovorgängen ist und wie die Bearbeitung von Dokumenten dadurch erleichtert wird. Aber auch das Archivieren und Auffinden von Dokumenten, das Erfassen von Papierdokumenten und Konvertieren in eine elektronisch weiterbearbeitbare Form und das automatische oder halbautomatische Interpretieren von Dokumenten wird für den Benutzer komfortabler.

Vor allem wird durch den Standard dieser Komfort nicht nur innerhalb eines geschlossenen, lokalen Netzes in einem Büro geboten, sondern ist auch verfügbar, wenn Dokumente mit anderen Büros ausgetauscht werden, die lokale Netze, Workstations und Rechenanlagen anderer Hersteller haben. Letztlich sind aber auch Werkzeuge zum Erzeugen und Manipulieren von Dokumentklassendefinitionen erforderlich. Einige dieser Aufgaben sind nur durch den Einsatz von wissensbasierten Systemen möglich.

Auch im elektronischen Büro wird das Medium Papier wegen seiner einfachen Handhabung, Portabilität, Übersichtlichkeit und geringen Kosten seinen Platz behaupten. Hauptproblem bei seiner Integration in elektronische Bürosysteme ist die Überwindung des Medienbruches Papier - elektronische Repräsentation.

Erfassen von Papierdokumenten

Eine Komponente des in der vorangegangenen Folge vorgestellten Esprit-Projektes Herode (121) ist deshalb ein automatisches Dokumenterfassungssystem. Dieses kann auf zwei Arten benützt werden:

Während des Erstellen eines Dokuments wird in dieses - wie in der vorangegangenen Folge beschrieben - an einer bestimmten Stelle ein Teil eines Papierdokuments, zum Beispiel ein Foto, eingesetzt. Anders ausgedrückt, der Dokumenteditor erhält seine Eingabe entweder vom Benutzer über die Tastatur oder Maus oder vom Dokumenterfassungssystem. Es können jedoch auch vollständige Papierdokumente mit Hilfe des Dokumenterfassungssystems in das ODIF-Format konvertiert und dann archiviert oder weiter bearbeitet werden. In beiden Fällen genügt ein alleiniges Abtasten der gemischten Dokumente nicht, da es danach erst als Bitmuster vorliegt. Für die Konversion in ODIF muß das Dokument deshalb zahlreiche Verarbeitungsschritte durchlaufen (Bild 1).

Zuerst wird das Papierdokument mit einem hoch auflösenden Grauton-Scanner abgetastet und Fehler, die durch das Abtasten bedingt sind wie ungleichmäßige Beleuchtu(...) oder Schieflage des Dokuments, werden automatisch korrigiert. Im ersten Verarbeitungsschritt wird dann die abgetastete Seite in Grauton- und Schwarzweiß-Bereiche unterteilt. Ein Grautonbereich kann entweder ein "echter" Grautonbereich, wie eine Fotografie, oder ein "gerasterter" Grautonbereich, zum Beispiel aus einer Zeitung, sein. Entsprechend unterscheidet sich die weitere Bearbeitung, deren Ziel ein optimal codierter "echter" Grautonbereich ist.

Alle Bereiche werden ODA-konform kodiert

Schwarzweiß-Bereiche werden zunächst binär dargestellt. Dann wird unterschieden zwischen Bereichen, die Text enthalten, und Be(...)chen, die Grafik enthalten. Text wird mit Hilfe von OCR in eine Folge von Zeichen und Steuerzeichen umgewandelt. In grafischen Bereichen wird versucht, Elemente wie Kreise, Geraden, Rechtecke usw. zu erkennen und sie durch grafische Primitive, zum Beispiel aus CGM (Computer Graphics Metafile), zu beschreiben.

Es kann jedoch passieren, daß ein Bereich nicht eindeutig bei der Segmentierung zugeordnet werden kann. Ein solcher Konfliktfall wird dann entweder aufgrund der bis dahin abgeleiteten Informationen über den Bereich und seine Umgebung automatisch entschieden oder durch interaktiven Eingriff des Benutzers gelöst.

Schließlich werden alle Bereiche ODA-konform als eine Anordnung von Blöcken auf einer Seite kodiert, wodurch die Layoutstruktur des abgetasteten Dokuments beschrieben wird. Für die logische Struktur wird zur Zeit von folgender einfacher Annahme ausgegangen: Ein abgetastetes Dokument besteht aus einer Folge von Textabschnitten und/oder Bildern. Dadurch ist das abgetastete Dokument bearbeitbar, wenngleich der Urheber andere Objekte, wie zum Beispiel Überschriften, Kapitel oder Fußnoten, erzeugt hat und es bequemer wäre, mit diesen zu arbeiten. Dies zu erreichen, gibt es zwei Wege, die bisher jedoch noch nicht implementiert wurden.

Die erste Möglichkeit ist, daß der Benutzer beim Erfassen eines Dokuments die Dokumentklasse des zu erfassenden Dokuments angibt, wodurch dann die entsprechende Dokumentklassendefinition als Apriori-Information zur Verfügung steht. Das Erkennen der logischen Struktur ist dann vergleichbar mit dem Parser eines Compilers. Nur können die Terminalsymbole, denen hier die logischen Basisobjekte entsprechen, nicht so einfach wie in einem Compiler-Scanner analysiert werden. Logische Basisobjekte müssen aus den Blöcken der erkannten Layoutstruktur abgeleitet werden mit Hilfe der in der Dokumentklassendefinition vorhandenen Layoutobjekt-Definition und der Layoutdirektiven. Vereinfacht ist dieser Vorgang im Bild 2 dargestellt.

Noch einen Schritt weiter in die Zukunft geht der folgende Ansatz: Nach dem Erkennen der Blöcke und ihrer Eigenschaften, wie zum Beispiel Schriftgröße oder Schriftart, und auch unter Einbeziehung des Inhalts, zum Beispiel "1." oder "II" am Beginn einer Zeile, wird versucht, eine logische Struktur zu erkennen und eine entsprechende Dokumentklassendefinition abzuleiten. Dies ist der natürliche Vorgang, als ob ein Benutzer das Dokument betrachtet und interpretiert. Dieser Ansatz könnte durch die Realisierung eines entsprechenden Expertensystems realisiert werden. Das Ergebnis könnte dann anschließend einer wissensbasierten Post-Vorverarbeitung (Bal 85) unterzogen werden, die den Dokumenten zum Beispiel Bearbeitungsprioritäten zuweist oder wichtige Begriffe im Text hervorhebt. Dadurch wird der Benutzer bei der Bearbeitung der Post unterstützt.

Archivieren von Dokumenten

Weil die logische Struktur eines Dokuments unabhängig von seinem Layout ist, eignet sie sich für den Zugriff auf Dokumente in Dokumentarchiven.

Selbstverständlich muß dazu auch die Information des "Document Profiles", das bei der Übertragung Eigenschaften des gesamten Dokuments angibt, mit herangezogen werden, wie zum Beispiel Name des Autors oder das Erstellungsdatum.

Auch diese Möglichkeiten werden im Rahmen von Esprit-Projekten untersucht. National Software Center (IRL), Dansk Datamatic Center (DK) und University College Dublin (IRL) entwickeln entsprechende Modelle und Prototypen im Rahmen des Esprit-Projekts 59 "New information models for Office Filing and Retrieval". Olivetti (I), Philips (NL), Cretan Research Centre (GR), Triumph-Adler (D), Batelle Institute (D), Consiglio Nazionale della Ricerche (I) und Mnemonica Computer Services (GARc) entwickeln ein "Multimedia Filing System" im Esprit-Projekt 28.

Neben den Werkzeugen, mit denen der Benutzer Dokumente im Dialog erstellt oder verändert, gibt es auch Werkzeuge, die Dokumente "interpretieren" (Sch83). Diese ordnen Dokumenten oder Dokumentteilen Semantik zu. Durch diese werden sie gesteuert und führen Aktionen aus, wie zum Beispiel andere Dokumente erstellen, auf Datenbanken zugreifen oder andere Bürovorgänge ablaufen lassen. Eine schrittweise Vernetzung solcher Werkzeuge erlaubt eine schrittweise Büroautomatisierung. Eine grundsätzliche Forderung dabei ist, daß alle automatisch ausgeführten Bürovorgänge vom Menschen beobachtet und nachvollzogen werden können. Dies ist bei diesem Ansatz dadurch möglich, daß alle Abläufe im Austausch, Erstell(...) oder Ablegen von Dokumenten bestehen oder durch diese gesteuert werden und daß Dokumente jederzeit durch den Menschen inspiziert werden können.

Die Interpretation ausgetauschter Dokumente wird in offenen Systemen erst dadurch ermöglicht, daß ein Dokument zusammen mit der Beschreibung seiner Dokumentklasse ausgetauscht wird. Allerdings reicht hierfür die bisher im Standard festgelegte Art, Dokumentklassen zu beschreiben, noch nicht aus. ODA/ ODIF muß für diese Zwecke noch erweitert werden, zum Beispiel um das Konzept von Daten und externen Referenzen.

Das Konzept von Dokumentklassen erfordert natürlich auch Werkzeuge zum Erstellen und Ändern von Dokumentklassenbeschreibc(...)gen. Prinzipiell könnte man natürlich ODIF-Dokumentklassenbeschreibungen selbst als eine Dokumentklasse betrachten und so Dokumentklassenbeschreibungen mit dem Dokumenteditor erzeugen. Wegen der komplexen Semantik der ODIF-Konstrukte und den vielfachen Wechselwirkungen der ODIF-Attribute wäre diese Art zu erstellen jedoch vergleichbar mit dem Programmieren von Computerprogrammen und ist deshalb dem Anwender von Dokumentbearbeitungswerkzeugen nicht zumutbar. Ihm müssen Werkzeuge zur Verfügung stehen, die es erlauben, Dokumentklassenbeschreibungen auf eine "natürliche" Weise zu bearbeiten.

Im allgemeinen werden Dokumentklassenbeschreibungen von Organisationsabteilungen erstellt und in Bibliotheken zur Verfügung gestellt werden, so wie heute von diesen Abteilungen Formulare, Vordrucke für Geschäftsbriefe oder Richtlinien für Berichte herausgegeben werden. So wie man sich jedoch beim konventionellen Erstellen eines Dokuments selbst Regeln auferlegen kann, sollte es auch für jeden Benutzer des Dokumenteditors möglich sein, eine Dokumentklassendefinition zu verändern. Voraussetzung dafür wäre ein integrierter Dokument- und Dokumentklasseneditor, wie er im Bild 3 dargestellt ist.

Um den Benutzer wirkungsvoll beim Erzeugen von Dokumentklassen zu unterstützen, muß wegen der komplexen Semantik der Dokumentklassendefinitionen der ODA-Dokumentklasseneditor ein Expertensystem sein. Dieses Expertensystem erfragt im Dialog mit dem Benutzer die Informationen, die nötig sind, um eine Dokumentklasse zu definieren. Dies kann zum Beispiel über Menüauswahl geschehen und/oder dadurch, daß der Benutzer ein Seitenlayout auf dem Bildschirm skizziert. Das Expertensystem seinerseits besitzt das Wissen über ODA/ODIF, insbesondere über das ODA-Processing-Model. Somit ist es in der Lage, eine Dokumentklassendefinition zu erstellen, die den Anforderungen des Benutzers genügt. Für die Entwicklung eines solchen Expertensystems sind allerdings noch umfangreiche Forschungsarbeiten nötig.

Bei einem integrierten ODA-Dokument- und ODA-Dokumentklasseneditor ist auch folgendes zu bedenken: Der Benutzer bearbeitet ein Dokument der Dokumentklasse D und will nun diese Dokumentklassendefinition ändern zur Dokumentklassendefinition D-neuc-. Das hat zur Folge, daß das Dokument nun ein Exemplar der Dokumentklasse D-neu- sein müßte. Im allgemeinen ist dazu auch eine Änderug des Dokuments nötig. Prinzipiell kann man dabei die im Bild 4 dargestellten drei Fälle unterscheiden.

Im einfachsten Fall ist der Benutzer nur mit dem automatisch erzeugten Layout unzufrieden, und er ändert deshalb die Definition der Layoutobjektklassen, wobei alle Klassen auf die Layoutdirektiven verweisen, die weiterhin existieren müssen, oder er verändert die Layoutdirektiven in den Layout Styles der logischen Objektklassendefinitionen. Damit das Dokument dann ein Exemplar dieser neuen Dokumentklasse ist, genügt es, ausgehend von seiner logischen Struktur und seinem Inhalt, ein neues Layout gemäß der neuen Dokumentklasse automatisch zu erzeugen.

Ist der Benutzer außerdem mit den Regeln für den Aufbau der logischen Struktur nicht zufrieden, so kann er diese im einfachsten Fall aufwärtskompatibel ändern, das heißt jedes existierende Dokument der alten Klasse ist auch ein Exemplar der neuen Klasse bezüglich der logischen Struktur. Auch in diesem Fall genügt es, das Dokument neu zu formatieren.

Der allgemeinste Fall ist, daß der Benutzer die Dokumentklassendefinition beliebig ändert. Dann müssen natürlich im Dokument die existierenden logischen Objekte vom Benutzer explizit den neuen logischen Objektklassen zugeordnet werden, das heißt, er muß dafür sorgen, daß bezüglich der logischen Struktur das Dokument ein Exemplar der neuen Dokumentklasse ist. Dies kann nicht automatisch durchgeführt werden, weil diese Zuordnung allein die Entscheidung des Benutzers ist. Anschließend wird das Dokument dann automatisch formatiert.

Die in diesem Artikel beschriebenen Bürowerkzeuge zeigen, daß durch die Forderung nach Anpaßbarkeit an Dokumentklassen die Realisierung der Werkzeuge komplizierter wird im Vergleich zu konventionellen Werkzeugen. Andererseits können nur anpaßbare Werkzeuge den Benutzer von Routinearbeiten entlasten. Deshalb ist es als positiv zu sehen, daß das Dokumentklassen-Konzept Bestandteil des ODA-Standards ist. Dadurch ist dieser Standard nicht nur für die Gegenwart, sondern auch für die Zukunft.