Einleitung
In der ersten Phase unseres Projekts 1dok.org arbeiten wir, neben der Initiierung eines Community- Prozesses, an der Erstellung eines Anforderungskataloges in Abstimmung mit öffentlichen Einrichtungen, interessierten Wirtschaftsunternehmen und Bürgern.
Während dieser Arbeit wurden wir auf das Dateiformat von OpenOffice.org aufmerksam, welches die meisten unserer bisher zusammengetragenen Anforderungen erfüllt.
Aus unserer Sicht fehlt allerdings ein erweiterbares, hierarchisches Metadatenmodell, welches es Dokumentenmanagement-, Workflowmanagement- sowie Archivierungssystemen ermöglichen würde, Dokumente und deren anwendungsbezogenen Inhalt (z.B. Adressfelder, Auftragsnummern ...) automatisch zu identifizieren und zu bearbeiten.
Im Hinblick auf die Notwendigkeit semantischer Strukturen teilen wir die Meinung der Linux Informations Systemen AG, die zu ähnlichen Resultaten in ihrer Studie kamen, die bereits auf OpenOffice.org besprochen wurde.
Die Implementierung eines Metadatenmodells würde zu einem neuen Paradigma für das Bearbeiten von in elektronischen Dokumenten enthaltenen Informationen führen. Dies betrifft die Vorgangsbearbeitung innerhalb von Organisationen sowie den Austausch von Informationen mit externen Partnern in den verschiedensten Kommunikationsbeziehungen, wie B2B, B2C, G2C (Verwaltung zum Bürger) oder G2G (Verwaltung zur Verwaltung).
Basierend auf dieser Technologie könnte z.B. eine öffentliche Einrichtung ein Antragsformular für "irgendetwas" (template) bereitstellen, welches dann von Bürgern heruntergeladen, ausgefüllt und zurückschickt werden könnte. Das zurückgeschickte Dokument würde dann durch ein Workflowmanagementsystem automatisch als Antragsformular für "irgendetwas" erkannt und es könnte ein entsprechender Workflow gestartet werden.
Sogar auf dem PC des Bürgers könnte ein neues assoziatives Paradigma der Speicherung von Dokumenten eingeführt werden: Um das Dokument zu sichern, müsste der Anwender nur die "Speichertaste" drücken, ohne zusätzlich ein Verzeichnis oder einen Dateinamen anzugeben.
Durch das Office-Produkt, z.B. OpenOffice.org, würde das Dokument aufgrund der enthaltenen Informationen als Antragsformular für "irgendetwas", erstellt von "irgendjemand" am "Datum", gesendet an " irgendjemand " usw. gespeichert. Das Dokument könnte durch Angabe dieser Attribute später wieder abgerufen bzw. hervorgeholt werden.
Vorschlag
Erweiterung des OpenOffice.org Dateiformates
Wir schlagen vor, die Möglichkeit der Speicherung beliebiger, semantisch strukturierter Inhalte, spezifiziert durch XML Schemata innerhalb des OpenOffice.org Dateiformats, einzuführen. Das zugrundeliegende Metadatenmodell sollte in objektorientierter Weise hierarchisch sein. Das bedeutet, dass ausgehend von einem Basisdokument, das nur rudimentäre Informationen, wie Dokumentenklasse, Autor, Erstellungsdatum, Version des Dateiformats etc. enthält, komplexere Dokumente wie Antragsformulare, Lieferscheine, Rechnungen etc. abgeleitet werden könnten. Eine Dokumentenklasse innerhalb dieser hierarchischen Struktur würde alle Attribute seiner Vorgänger erben.
Um unsere Intension nochmals klar herauszustellen, betonen wir ausdrücklich, dass die zu speichernden Inhalte nicht Gegenstand dieses Vorschlags sind. Unser Fokus liegt einzig und allein auf der Fähigkeit eines Dokumentenformats diese aufnehmen zu können. Informationen über mögliche, anwendungsbezogene Inhalte, können anderen Spezifikationen wie EDIFACT, ebXML, openTRANS, DOMEA etc. entnommen werden.
Zur Illustration des vorgeschlagenen 1dok Metadatenmodells siehe unter www.1dok.org/de/ .
Speicherung von Dokumenten
Dokumente könnten, wie in der Einleitung beschrieben, assoziativ gespeichert werden.
Bearbeitung von Formularen
OpenOffice.org könnte eine Toolbox basierend auf einem XML Schema mit spezialisierten Steuerelementen anbieten.
Wenn, z.B. OpenOffice.org, die Definition für den Elementtyp einer ISBN innerhalb eines gegebenen XML Schemas vorfände, könnte ein entsprechendes, spezialisiertes Texteingabefeld für eine ISBN innerhalb der Toolbox angeboten werden.
Die Elementtyp-Definition könnte von dem Basistyp xsd:string abgeleitet sein und mittels einen regulären Ausdrucks spezialisiert sein, der die syntaktische Struktur einer ISBN, wie unten dargestellt, definiert:
Wenn das ISBN Feld in das Formular eingefügt würde,
sollte ein entsprechend benanntes XML Element innerhalb des Dokuments generiert und abgelegt werden, z.B. in der meta.xml.
Alternativ wäre die Ablage, wie von der Linux Informationssysteme AG vorgeschlagen, innerhalb der content.xml selbst möglich.
Die in einem ausgefüllten Formular enthaltenen Daten könnten unter Verwendung des XML Schemas validiert und innerhalb der zugeordneten XML Datenstruktur gespeichert werden, wo sie für jede beliebige Applikation zur Weiterverarbeitung zur Verfügung stünden.
Gruß
Bernd Schuster
1dok.org
top