Compart - Dokumenten und Output-Management

Trends

Daten: Augen und Ohren der künstlichen Intelligenz

Compart |

Die nächste Stufe der Digitalisierung im Dokumentenmanagement ist in vollem Gang

– und bedeutet die weitgehende Automatisierung aller dokumentenrelevanten Prozesse. Grundlage dafür sind strukturierte, konsistente und zentral verfügbare Daten. Der nachfolgende Artikel beleuchtet die unterschiedlichen Facetten eines professionellen Umgangs mit Informationen in der Dokumentenverarbeitung.

Das weltweite Datenvolumen nimmt weiterhin stark zu. Überproportional wachsen werden vor allem unstrukturierte Daten in Form von Fotos, Audiodateien und Videos sowie in Präsentationen und Textdokumenten – laut dem Marktforschungsinstitut IDC im Schnitt um 62 Prozent jährlich. Bis 2022 soll dieser Datentypus rund 93 Prozent des gesamten Volumens ausmachen.¹

Unstrukturierte Daten umfassen einer Definition von Gartner zufolge “all jene Inhalte, die nicht einem bestimmten, vordefinierten Datenmodell entsprechen. Es sind in der Regel von Menschen generierte und personenbezogene Inhalte, die sich nicht gut in Datenbanken einfügen.“ Doch sie enthalten oft wertvolle Kunden- und Verhaltensinformationen, deren Auswertung für fundierte Entscheidungen wichtig sein kann.

Eingehend analysiert bilden unstrukturierte Daten zudem die Grundlage für bessere und erweiterte Services, aus denen sogar gänzlich neue Geschäftsmodelle entstehen können. IDC geht davon aus, dass Unternehmen, die 2020 alle relevanten Daten analysieren, gegenüber weniger analytisch orientierten Mitbewerbern einen Produktivitätsgewinn von 430 Milliarden US-Dollar erzielen werden.²

Infobox

Lesedauer: 6 Min

  • Digitalisierung heißt Automatisierung
  • Anderer Umgang mit Daten erforderlich
  • Voraussetzungen für KI-gesteuertes Dokumentenmanagement

Aktuell suchen Firmen noch nach wirklich effizienten Lösungen, um nichtstrukturierte in strukturierte Daten zu überführen. Dabei sind sie mit einer Reihe an Herausforderungen konfrontiert: von der Frage nach dem geografischen Speicherort, der Art der Datenspeicherung und der Governance bis hin zur Sicherung und Analyse dieser Informationen in lokalen und Cloud-Umgebungen. So verwundert wenig, wenn die MIT Sloan Group 80 Prozent aller Daten als nicht vertrauenswürdig, unzugänglich oder nicht auswertbar einstuft. IDC schätzt, dass 2020 das „digitale Universum“ bis zu 37 Prozent Informationen enthalten wird, die wertvoll sein könnten, wenn sie denn analysiert werden würden.³

Digitalisierung heißt Automatisierung

Fest steht: Strukturierte und auswertbare Daten sind die Grundvoraussetzung für die nächste Stufe der Digitalisierung im Dokumentenmanagement. Gemeint ist damit die weitgehende Automatisierung und Standardisierung von Prozessen, so dass ein „menschliches Eingreifen“ immer weniger notwendig ist („Dunkelverarbeitung“). Routineaufgaben wie Leistungsabrechnungen, Bestätigung von Adress- und Tarifänderungen oder Terminvereinbarungen werden heute schon von Softwarelösungen, Sprachassistenten und Chatbots, die auf KI-Algorithmen (selbstlernende Systeme) basieren, übernommen.

Mehr noch: Auch Inhalte mit einem hohen schöpferischen Anteil wie Fachaufsätze und ähnliches werden früher oder später von KI-Systemen erzeugt werden. Schon heute gibt es Programme, die einfache Wikipedia-Artikel mit simpler Syntax und Grammatik produzieren können. Man definiert dazu bestimmte Bezugspunkte (Gliederung, Stichworte) (bei einem Text über eine Stadt beispielsweise die Einwohnerzahl, Jahr der Gründung, Städtepartnerschaften, geographische Daten) und das System ruft die dafür notwendigen Daten aus Wikidata ab, ergänzt die entsprechenden hinterlegten Textbausteine, die einer einfachen Grammatik folgen (Subjekt – Prädikat – Objekt) und fügt alles zu einem fertigen Text zusammen.

Vielen noch gut in Erinnerung ist der Auftritt von Google-Chef Sundar Pichai auf der Entwicklerkonferenz IO im Mai vergangenen Jahres, als er den Sprachassistenten „Duplex“ vorstellte: Der Chatbot ist in der Lage, selbstständig zu telefonieren, ohne dass der Angerufene merkt, dass er es hier mit einer „künstlichen Intelligenz“ zu tun hat.⁴

Bei anderen Prozessen dagegen wie der Kündigung einer Versicherungspolice oder der Freigabe einer Rechnung über 50.000 Euro beispielsweise wird man sicher – teilweise durch regulatorische Auflagen bedingt – auch künftig noch einen Sachbearbeiter drüber schauen lassen. Doch es ist nur eine Frage der Zeit, bis auch solche sensiblen Bereiche automatisiert werden. Je verlässlicher die Systeme werden, desto höher lässt sich letzten Endes die Schwelle für eine automatisierte Verarbeitung setzen. Dafür ist jedoch ein richtiger Umgang mit den Daten erforderlich.

Harald Grumser, Gründer und Vorstand der Compart AG, bringt es auf den Punkt: „Digitale Prozesse brauchen Zugriff auf die Inhalte der Dokumente und auch künstliche Intelligenz braucht Augen und Ohren. Es wird daher immer wichtiger, die für eine Automatisierung notwendigen Daten von Beginn an zu erhalten, sie mit einer Struktur zu versehen und richtig zu speichern.“

 

Dokumente sind die für den Menschen lesbare Darstellung von Daten

 

Das betrifft auch und gerade das Dokumentenmanagement als Schnittstelle zwischen klassischer (papiergebundener) und elektronischer Kommunikation. So werden hier typischerweise auf der Ausgangsseite digitale in analoge Daten überführt (z. B. beim Drucken, aber auch bei der Transformation von Textinhalten in Audiodateien („text-to-speech“). Demgegenüber steht die Situation im Posteingang (Input Management), wo genau das Entgegengesetzte passiert: Aus analogen Daten entstehen elektronische Dokumente (z. b. beim Scannen, aber auch bei der Umwandlung von Audio-/Videodateien in lesbaren Content) – wenn auch nicht unbedingt in einer sehr hochwertigen Form.

Die Herausforderung besteht nun darin, die in allen Bereichen der Inbound- und Outbound-Kommunikation anfallenden Informationen bzw. Daten in eine strukturierte Form zu überführen und in den richtigen „Datentöpfen“ abzulegen, damit sie für sämtliche Prozesse des Dokumenten- und Output-Managements zur Verfügung stehen – von der Erfassung eingehender Nachrichten (Input Management) über die Erstellung und Verarbeitung von Dokumenten bis zu deren Ausgabe.

Dabei ist es zunächst unerheblich, auf welchem digitalen oder analogen Medium ein Dokument einmal versendet oder angezeigt wird: Es geht immer um die Daten, denn ein Dokument ist letztlich nur deren jeweilige Repräsentation in einer für den Menschen lesbaren Form – wobei hier unterschieden werden muss zwischen nichtkodierten und kodierten Dokumenten (siehe Hintergrundwissen weiter unten).

In diesem Zusammenhang sei auf zwei wesentliche Trends verwiesen, die immer mehr an Bedeutung gewinnen und andere Entwicklungen nahezu verdrängt haben:

  • XML (Extensible Markup Language) als Auszeichnungssprache komplexer, hierarchischer Daten sowie
  • JSON (JavaScript Object Notation) als kompaktes Datenformat (ähnlich XML, nur einfacher), das heute vor allem in Webservices Anwendung findet. (siehe dazu auch das Glossar).

Beide Technologien haben sich für die Beschreibung bzw. Definition von strukturierten Daten bewährt und werden sicher eine noch größere Rolle spielen.

Daten müssen geprüft, überführt und richtig gespeichert werden

Damit die strukturierten Daten tatsächlich für eine automatisierte Verarbeitung zur Verfügung stehen, kommt es auf deren richtige Speicherung an. Hier bieten nichtrelationale Datenbanken wie NoSQL (einschließlich der Unterkategorien Graph-Datenbank und RDF) inzwischen neue Möglichkeiten. Ihr großer Vorteil gegenüber relationalen Datenbanken besteht darin, dass sie Daten auch in sehr komplexen Zusammenhängen bewirtschaften können und damit sehr spezifische Abfragen ermöglichen (siehe dazu auch das „Glossar“).

Eine der bekanntesten Anwendungen dafür ist Wikidata, die Wissensdatenbank der Online-Enzyklopädie Wikipedia, in der zig Millionen Fakten mittlerweile gespeichert sind. Wer beispielsweise wissen will, wie viele Bundesligaspieler, die in Berlin geboren wurden, mit ägyptischen Frauen verheiratet sind, wird hier bestimmt fündig. Sicher – ein sehr außergewöhnliches Beispiel, das aber die Bedeutung des Themas deutlich macht. Ziel ist es, aus strukturierten Daten über Algorithmen (Ontologien) neue Zusammenhänge/Erkenntnisse zu gewinnen. Hier kommt dann auch künstliche Intelligenz (KI) ins Spiel, über die man dann komplexe Abfragen formulieren kann (siehe dazu das „Glossar“).

Ein weiteres wichtiges Thema in diesem Zusammenhang: Die mit einer Struktur versehenen, gespeicherten Daten müssen überprüft werden – was heute ganz oft nicht gemacht wird. Dabei gibt es mit dem XML-Schema beispielsweise eine bewährte Methode, um die Korrektheit und Vollständigkeit einer XML-Datei zu garantieren. Fehler, die durch nicht geprüfte Daten entstehen, können sehr gravierend sein.

Daher ist eine konsequente Datenprüfung unerlässlich. Last but not least gilt es, die Daten auch ineinander zu überführen, und zwar über Regeln. Auch dafür existieren heute viele Möglichkeiten, eine der bekanntesten ist sicher die Programmiersprache XSLT (siehe auch das „Glossar“). Aber es gibt auch andere Regelwerke.

Statt Content zu vernichten...

Wer also den Automatisierungsgrad von Abläufen in der Kundenkommunikation im Sinne der nächsten Stufe der Digitalisierung weiter erhöhen will, muss für strukturierte, konsistente und zentral verfügbare Daten sorgen. Für das Dokumenten- und Output-Management bedeutet das, den Content von Dokumenten von Beginn an möglichst komplett zu erhalten statt ihn zu vernichten – wie beispielsweise häufig im elektronischen Posteingang von Unternehmen zu beobachten ist.

Das Problem hier: Noch immer werden in vielen Unternehmen eingehende E-Mails „vertifft“, also in ein Bildformat umgewandelt, um anschließend mittels OCR-Technologie Teile des Dokumenteninhalts wieder interpretierbar zu machen. Das ist „tiefstes Dokumenten-Mittelalter“. Es verschleißt unnötig Ressourcen, vor allem, wenn man bedenkt, dass heutzutage E-Mail-Anhänge recht komplexe Dokumente mit zig Seiten sein können.

Vor allem aber kommt dieser Medienbruch einem „Daten-Gau“ gleich: Da werden elektronische Dokumente (E-Mails), die an sich von IT-Systemen gelesen und verarbeitet werden könnten, erst einmal in TIFF-, PNG oder JPG-Dateien umgewandelt. Aus Content entstehen also „Pixelwolken“. Mit anderen Worten: Der eigentliche Inhalt wird erst verschlüsselt (Rasterbilder) und dann wieder mittels Optical Character Recognition (OCR) mühsam „lesbar“ gemacht. Das geht mit dem Verlust von semantischen Strukturinformationen einher, die aber für eine spätere Wiederverwendung notwendig sind.

Wie schön wäre es doch, wenn man E-Mail-Anhänge gleich welchen Typs beispielsweise sofort nach Eingang in strukturierte PDF konvertieren könnte? Damit wäre die Grundlage für eine langfristige, revisionssichere Archivierung gelegt; schließlich ist die Umwandlung von PDF nach PDF/A nur ein kleiner Schritt.

...lieber erhalten als Grundlage für weitere Automatisierung

Dazu folgendes Beispiel: Ein führender deutscher Versicherungskonzern bekommt über ein zentrales elektronisches Postfach täglich zig Tausende E-Mails, sowohl von Endkunden als auch von ex- und internen Vertriebspartnern. Sofort nach Empfang werden vom System automatisch die folgenden Prozesse „angestoßen“:

  • Konvertierung der eigentlichen E-Mail („Body“) nach PDF/A
  • Individuelle Konvertierung des E-Mail-Anhangs (z. B. verschiedene Office-Formate, Bilddateien wie TIFF, JPG etc.) nach PDF/A
  • Zusammenführung des E-Mail-Body mit den entsprechenden Anhängen und Generierung einer einzelnen PDF/A-Datei pro Geschäftsvorgang
  • Gleichzeitig werden aus der Datei alle wichtigen Informationen ausgelesen (extrahiert) und zentral für nachgelagerte Prozesse vorgehalten (z. B.
  • Generierung von Antwortschreiben auf KI-Basis, fallabschließende Sachbearbeitung, Archivierung)

Alles läuft automatisiert und ohne Medienbruch. Der Sachbearbeiter bekommt das Dokument in einem standardisierten Format, ohne dass er sich um die Aufbereitung (klassifizieren, lesbar machen) kümmern muss.

Dabei könnte der Versicherer den Workflow noch „splitten“ in die Dunkel- und die interaktive Verarbeitung. Bei der Dunkelverarbeitung wird grundsätzlich jede ankommende E-Mail plus Anhang automatisch in ein PDF/A umgewandelt, an die Sachbearbeitung übergeben und abschließend archiviert.

Bei der interaktiven Verarbeitung dagegen geht es um das „intelligente“ Zusammenstellen von E-Mail-Dokumenten unterschiedlichen Dateiformats zu einem elektronischen Dossier (Kundenakte/-vorgang). Der Sachbearbeiter öffnet zunächst auf seinem Mail-Client (Outlook, Lotus Notes etc.) oder seinem speziellen Sachbearbeitungsprogramm die E-Mail und den Anhang und entscheidet, was bearbeitet werden muss. Danach greift der normale Workflow wie bei der Dunkelverarbeitung: Konvertierung – Weiterleitung - Bearbeitung – Archivierung.

Die interaktive Variante ist vor allem dann sinnvoll, wenn nicht alle Dokumente archiviert werden müssen. Moderne Input-Management-Systeme sind inzwischen in der Lage, alle gängigen Formate von E-Mail-Anhängen automatisch zu erkennen und in ein vorgegebenes Standardformat (zum Beispiel PDF/A oder PDF/UA) zu konvertieren. Und: Sie extrahieren aus den Dokumenten alle notwendigen Daten gleich mit und legen sie zentral ab.

Umsetzen lassen sich solche Szenarien beispielsweise mit Systemen wie DocBridge® Conversion Hub, deren Dreh- und Angelpunkt eine zentrale Konvertierungsinstanz ist. Deren Kernstück ist eine Art "Dispatcher", der jede ankommende Nachricht (E-Mail, Fax, SMS, Messenger-Dienst, Brief/Papier) analysiert und automatisch über die für das jeweilige Dokument optimale Konvertierungsstrecke (In welches Format soll konvertiert werden? Wie hat die Weiterverarbeitung zu erfolgen?) entscheidet. DocBridge® Conversion Hub enthält außerdem eine OCR-Funktion für das Extrahieren von Inhalten und Metadaten (Optical Character Recognition) für die automatisierte Weiterverarbeitung.


¹ CIO online, 23.9.2019 („KI ebnet den Weg zu unstrukturierten Informationen“).
² Ebenda.
³ Ebenda.
⁴ Am Beispiel einer Vereinbarung für einen Friseurtermin wurde die neue Dimension intelligenter Sprachsysteme wie „Duplex“ deutlich: Bisherige Systeme lassen sich meist innerhalb weniger Wörter als „Roboter“ erkennen (unnatürlich klingende Stimme, falsche Betonung, abgehackte Sätze, falsche oder gar keine Reaktionen auf Anfragen). Nicht so KI-Tools der neuen Generation: Sie sind durchaus in der Lage, Inhalte mit komplexer Syntax zu erfassen und „unterhalten“ sich so gekonnt mit Menschen, dass diese nicht merken, wer oder was ihr Gegenüber ist.

Hintergrund: Daten, Dokumente und Prozesse in der Kundenkommunikation – Kernaussagen

Prinzipiell ist ein Dokument ist die für den Menschen lesbare Darstellung von Daten, wobei zwischen nichtkodierten und kodierten Varianten unterschieden werden muss.

1. Nichtkodierte Dokumente

  • sind Bilder, Sprachaufzeichnungen und Videos.
  • können in kodierte überführt werden, allerdings aufwändig und meist mehrstufig, beispielsweise durch Texterkennungsmethoden wie OCR (Optical Character Recognition) mit anschließender Strukturerkennung, um letztlich an die Rohdaten zu gelangen („echte Datenerkennung“).

2. Kodierte Dokumente sind

  • die reine Repräsentation von Daten in einer für den Menschen lesbaren Form (z. B. Umsatzchart, ZUGFeRD- bzw. XRechnung)
  • Inhalte mit einem hohen schöpferischen Anteil (z. B. Deutschaufsatz, Vertrag, Wikipedia-Artikel), die über eine Struktur verfügen, so dass sich daraus Daten extrahieren lassen (z. B. Verträge mit einer festgelegten Gliederung wie Paragrafen, Kapitel oder auch Wikipedia-Artikel, aus denen über die hinterlegte Wikidata-Datenbank alle im Text enthaltenen Daten ebenfalls extrahiert werden können). Selbst aus sehr prosaischen Texten lassen sich Daten extrahieren, auch wenn diese dann sehr komplex sind.

3. Daten

  • Einfache Daten sind Tabellen, z. B. relationale Datenbank, Excel-Spreadsheet.
  • Komplexe Daten besitzen in der Regel eine Struktur, beispielsweise im XML- oder JSON-Format.
  • Datenbanken wie NoSQL (einschließlich Graph-Datenbank und RDF) bieten die Möglichkeit, strukturierte Daten in komplexen Zusammenhängen zentral zu bewirtschaften. Sie bilden damit die Grundlage für sehr komplexe Abfragen (Stichwort Big Data). Prominentes Beispiel dafür ist Wikidata, die Wissensdatenbank von Wikipedia (siehe auch Glossar).
  • Metadaten sind Daten über Daten und stets eine Frage des Standorts (Wer hat das Dokument wann und wo erzeugt?) Für die automatisierte Dokumentenverarbeitung spielen sie im Prinzip keine Rolle.
  • Daten müssen geprüft werden, beispielsweise durch XML-Schemata (siehe auch Glossar).
  • Daten müssen überführt werden, z. B. durch Regeln wie XSLT (siehe auch Glossar).

4. Prozesse

  • in der Kundenkommunikation bedeuten letztlich nichts Anderes als Daten bzw. Dokumente als deren Repräsentation zu erstellen und zu verändern.
  • können mit menschlicher Interaktion ablaufen, dann spricht man in der Regel von Geschäftsprozessen.
  • lassen sich aber auch ohne manuelles Eingreifen etablieren, dann handelt es sich um rein (automatisierte) technische Prozesse („Dunkelverarbeitung“). Typisches Beispiel dafür sind Rechnungen, die zum Zeitpunkt X automatisch erstellt und versendet werden – entweder elektronisch (ZUGFeRD bzw. XRechnung), als E-Mail-
  • Anhang, Download-Datei (Kundenportal) oder auf dem klassischen Postweg.
  • Automatisierung bedeutet Austausch von Daten, nicht von Dokumenten.

Automatisiertes Input-Management
DocBridge® Conversion Hub

Die hochleistungsfähige, skalierbare und nahtlos zu integrierende Plattform DocBridge® Conversion Hub geht hinsichtlich Umfang und Intention über das Angebot herkömmlicher Software zur Dokumentenkonvertierung hinaus. Der wohl wichtigste Vorzug der von Compart entwickelten Lösung ist die nahezu unbegrenzte Formatvielfalt: Es gibt praktisch keinen Dokumententyp, der nicht von DocBridge® Conversion Hub verarbeitet werden kann.

Technologisches Fundament eines automatisierten, digitalisierten Input-Managements schafft die Voraussetzung für KI-gesteuerte Dokumentenverarbeitung

Die hochleistungsfähige, skalierbare und nahtlos zu integrierende Plattform DocBridge® Conversion Hub geht hinsichtlich Umfang und Intention über das Angebot herkömmlicher Software zur Dokumentenkonvertierung hinaus. Der wohl wichtigste Vorzug der von Compart entwickelten Lösung ist die nahezu unbegrenzte Formatvielfalt: Es gibt praktisch keinen Dokumententyp, der nicht von DocBridge® Conversion Hub verarbeitet werden kann. Hier spiegelt sich das profunde Know-how der Compart als Spezialist für Datenströme im Dokumenten- und Output-Management wider. Selbst Sprachnachrichten, beispielsweise aus Messenger-Diensten (WhatsApp, Viber, Line), Bilder in diversen Formaten, E-Mails nebst Anhänge und Inhalte in sehr proprietären bzw. veraltete Formate lassen sich mit der Lösung verarbeiten. DocBridge® Conversion Hub fungiert quasi als „Trichter“, der jedes empfangene elektronische Dokument, unabhängig von seinem Format, entgegennimmt, erkennt, aufbereitet, also in ein les- und analysierbares Format wandelt, gleichzeitig die relevanten Daten extrahiert und damit die Voraussetzungen für dessen automatisierte Weiterverarbeitung, unter anderem auf KI-basierenden Prozessen, legt.

Ausgangspunkt für die Entwicklung von DocBridge® Conversion Hub war, dass vor allem Versicherer, Banken und Energieversorger, aber auch der öffentliche Sektor zunehmend mit elektronischen Dokumenten im Posteingang konfrontiert sind. Diese schnell, automatisiert und möglichst ohne Medienbruch zu analysieren und zu klassifizieren, darin besteht die größte Herausforderung heutzutage im Input Management von Unternehmen mit hohem Dokumentenaufkommen.

Weitere Details dieser Plattform

Funktionen

Transportcontainer in der Logistik ermöglichen es, Waren jeglicher Art in einer standardisierten “Verpackung” flexibel und schnell mit unterschiedlichen Verkehrsmitteln zu verschicken und zu verteilen – ob per Schiff, Flugzeug, Bahn oder LKW. Ähnlich operieren Container in der IT: Sie verpacken eine Anwendung und alle zu ihrer Ausführung erforderlichen Dateien in ein handliches Paket.

Das vereinfacht sowohl die Installation und den Betrieb von Server-Anwendungen als auch deren Management und Verteilung. Somit erleichtern Container den Umgang mit komplexen Server-Anwendungen und ermöglichen eine weitgehende Automatisierung von Rollout-Prozessen im Rechenzentrum. Das ist besonders bei der Bereitstellung von skalierbaren, verteilten Anwendungen innerhalb von Cloud-Umgebungen wichtig.

Eine wesentliche Problematik beim Rollout von neuen Anwendungen oder neuen Releases ist es, dass jede Anwendung von gewissen Elementen ihrer Umgebung abhängt. Hierzu zählen beispielsweise lokale Einstellungen oder Funktionsbibliotheken. Oft unterscheiden sich die Einstellungen in der Entwicklungsumgebung von denen der Testumgebung und der Produktion. Dann kann es schnell passieren, dass eine Anwendung in der Produktion wider Erwarten anders oder gar nicht funktioniert.

Weitere Faktoren, die einen reibungsloses Rollout stören können, sind das der Anwendung zu Grunde liegende Betriebssystem, dessen Version und Einstellungen, alle hinzugefügten Pakete und Module oder die Konfiguration des Netzwerks. Die Bereitstellung mehrerer Anwendungen über unterschiedliche Plattformen ist also eine Herausforderung. Hier bietet der Einsatz von Containern unmittelbare Vorteile: Entwickler verpacken so ihre Anwendungen inklusive aller Abhängigkeiten wie Bibliotheken und Konfigurationsdateien in einem Container. Die Anwendungen werden also nicht mehr direkt auf den Zielsystemen installiert. Die Container stellen somit die komplette Laufzeitumgebung der Applikation in einem Paket bereit.

So haben Entwickler die Möglichkeit, Anwendungen zwischen verschiedenen Umgebungen hin- und herzuschieben – zum Beispiel für Tests in einem spezifischen Hardware-Umfeld und den Betrieb in einem anderen. Oder sie betreiben Applikationen erst auf einer physikalischen Maschine und dann in einer Private, Public oder Hybrid Cloud.

Container machen Anwendungen unabhängiger von der Umgebung, in der sie ausgeführt werden. Sie agieren damit ähnlich einer virtuellen Maschine (VM). Während eine VM jedoch ein vollständiges Betriebssystem sowie Applikationen enthält, teilen sich mehrere Container einen Betriebssystemkern. Jede Anwendung erhält lediglich einen neuen User Space und damit eine komplett isolierte Umgebung. Container verbrauchen also im Vergleich zu VMs deutlich weniger Ressourcen wie Rechenleistung, Hauptspeicher etc. Und es dreht sich hier um Megabytes bei Containern im Vergleich zu Gigabytes bei VMs. Daher passen auf einen Server sehr viel mehr Container als virtuelle Maschinen. Zudem sind Container schneller einsatzbereit: Während VMs manchmal mehrere Minuten zum Start benötigen, stehen Anwendungen hier beinahe sofort zur Verfügung.

Container ergänzen die Virtualisierung
Trotzdem werden Virtualisierungs-Lösungen weder überflüssig noch komplett ersetzt werden, da sie nicht für alle Anwendungsszenarien passen. So eignen sich Container zum Beispiel sehr gut für Infrastrukturen, in denen eine große Zahl von Applikationsinstanzen parallel laufen. Sie sind zudem ideal für Anwendungen, welche häufigen Updates und funktionalen Erweiterungen unterliegen. Bei Applikationen, die aus unterschiedlichen Komponenten bestehen und auf einer Microservices-Architektur basieren, bieten Container ebenfalls eine effiziente Möglichkeit, neue Rollouts ohne großen Overhead zu implementieren.

Für andere Anwendungsfelder hingegen ist die Virtualisierung mit Hypervisoren nach wie vor die bessere Wahl: Beispielsweise für die Bereitstellung und den Betrieb von Standard-Serverdiensten wie Datenbankservern, Directory Servern oder auch Webservern – also im Prinzip für standardisierte Anwendungen, die längeren Aktualisierungszyklen unterliegen und von Dritten bereitgestellt werden. Somit sind Container eher eine sinnvolle Ergänzung zur Virtualisierung als ein Ersatz.

Nutzen
  • hohe Effizienz bei der elektronischen Eingangsverarbeitung, unabhängig vom Input-Kanal (Wegfall bestimmter Tätigkeiten wie Drucken und Scannen)
  • Etablierung von standortunabhängigen, skalierbaren Konvertierungsstrategien mittels einer einzigen Plattform
  • auch Einbindung von dezentral erstellten Office-Dokumenten (Individualkorrespondenz)
  • kein Verlust von Content
  • schnelle und gezielte Informationsrecherche selbst in komplexen, großen Dateien;
  • Grundlage für die Zentralisierung/Konsolidierung von heterogenen Archivsystemen;
  • Möglichkeit der Verzahnung mit OM-Prozessen (Output-Management)
  • hohe Compliance (u.a. revisionssichere Langzeitarchivierung gemäß PDF/A-3, Barrierefreiheit gemäß WCAG, Schutz sensibler Daten mittels „Schwärzen“ bzw. Anonymisieren von bestimmten Dokumenteninhalten, DSGVO)
  • deutlich geringeres Fehlerrisiko bei der Dokumentenverarbeitung
  • reduzierte Kosten (u.a. durch Wegfall redundanter bzw. überflüssiger Konvertierungs-Lösungen einschließlich Wartung, Schulungen für Benutzer und Lizenzerneuerungen)
Kubernetes
  • hohe Performance und Skalierbarkeit („Abfederung“ von Lastspitzen“);
  • Parallelverarbeitung;
  • automatisierte Lastverteilung (optimale Auslastung)
  • bidirektionale Kommunikation
  • Plattformunabhängigkeit
  • nahtlose Integration in bestehende Strukturen des Dokumenten- und Output-Managements von Unternehmen
  • Monitoring via Web-UI
  • Konfiguration via GUI
  • Deployment-Konzept
  • Prioritätensteuerung
  • Integration in Cloud-Architekturen möglich
  • Hohe Ausfallsicherheit

Glossar und vertiefendes Wissen

Wikidata


Wikidata ist eine frei zugängliche und gemeinschaftlich gepflegte Wissensdatenbank, die unter anderem das Ziel hat, die Online-Enzyklopädie Wikipedia zu unterstützen. Das Projekt wurde von Wikimedia Deutschland e.V., einer gemeinnützigen Gesellschaft zur Verbreitung freien Wissens, 2012 ins Leben gerufen und stellt als gemeinsame Quelle bestimmte Datentypen für Wikimedia-Projekte bereit (z. B. Geburtsdaten, allgemeingültige Daten), die in allen Artikeln von Wikimedia verwendet werden können.

Wikidata strukturiert das Wissen der Welt in sprachunabhängigen Datenobjekten, die mit verschiedenen Informationen angereichert werden können. Sowohl Menschen als auch Maschinen und IT-Systeme können auf diesen Datenschatz zugreifen und neues Wissen generieren. Auch Wikibase, die Software hinter Wikidata, ist als freie und offene Software für alle Menschen verfügbar.

Eines der vielen Beispiele für ein mit Wikibase entstandenes offenes Datenprojekt ist Lingua Libre. Das Verzeichnis kostenloser Audio-Sprachaufzeichnungen hat das Ziel, den Klang der Sprachen der Welt und die Aussprache ihrer Wörter in Form strukturierter Daten zu bewahren und allen Menschen zur Verfügung zu stellen. Seinen Ursprung hat das Projekt in Frankreich, wo es den Initiatoren darum ging, gefährdete Regionalsprachen zu fördern. Ein Vorteil von Lingua Libre besteht darin, dass interessierte Nutzer die Aufzeichnungen vervollständigen können – sei es mit wenigen Worten, Sprichwörtern oder ganzen Sätzen. So können auch Menschen, die sich mit der Lautschrift nicht auskennen, per Klick hören, wie einzelne Worte ausgesprochen werden. Mit dem Start der Wikibase-Installation Lingua Libre 2018 wurden rund 100.000 Audiodateien in 46 Sprachen in das Verzeichnis aufgenommen.

Mittlerweile können über die Online-Anwendung bis zu 1200 Aufzeichnungen pro Stunde aufgenommen und direkt ins freie Medienarchiv Wikimedia Commons hochgeladen werden. Über die Anbindung an Wikidata bereichern die aufgezeichneten Klänge vor allem Wikimedia-Projekte wie Wikipedia oder auch das freie Wörterbuch Wiktionary – sie unterstützen aber auch Spezialisten für Linguistik in ihrer Forschung.

Seit dem Start verzeichnet Wikidata ein vergleichsweise starkes Wachstum an Inhaltsseiten, mittlerweile sind über 60 Millionen Datenobjekte vorhanden (Stand: September 2019).

Relationale Datenbanken

Relationale Daten dienen zur elektronischen Datenverwaltung in Computersystemen und beruhen auf einem tabellenbasierten relationalen Datenbankmodell. Grundlage ihres Konzeptes ist die Relation. Sie stellt eine mathematische Beschreibung einer Tabelle dar und ist ein im mathematischen Sinn wohldefinierter Begriff. Operationen auf diesen Relationen werden durch die relationale Algebra bestimmt.

Das zugehörige Datenbankmanagementsystem wird als RDBMS (Relational Database Management System) bezeichnet. Zum Abfragen und Manipulieren der Daten kommt überwiegend die Sprache SQL (Structured Query Language) zum Einsatz, deren theoretische Grundlage die relationale Algebra ist. Das relationale Datenbankmodell wurde 1970 von Edgar F. Codd erstmals vorgeschlagen und ist bis heute trotz einiger Kritikpunkte ein etablierter Standard für Datenbanken.

Ontologien

Ontologien in der Informatik sind meist sprachlich gefasste und formal geordnete Darstellungen einer Menge von Begrifflichkeiten und der zwischen ihnen bestehenden Beziehungen in einem bestimmten Gegenstandsbereich. Sie werden dazu genutzt, „Wissen“ in digitalisierter und formaler Form zwischen Anwendungsprogrammen und Diensten auszutauschen. Wissen umfasst dabei sowohl Allgemeinwissen als auch Wissen über sehr spezielle Themengebiete und Vorgänge.

Ontologien dienen als Mittel der Strukturierung und zum Datenaustausch, um

  • bereits bestehende Wissensbestände zusammenzufügen
  • in bestehenden Wissensbeständen zu suchen und diese zu editieren
  • aus Typen von Wissensbeständen neue Instanzen zu generieren.

Ontologien enthalten Inferenz- und Integritätsregeln, also Regeln zu Schlussfolgerungen und zur Gewährleistung ihrer Gültigkeit. Sie habenhaben mit der Idee des semantischen Webs in den letzten Jahren einen Aufschwung erfahren und sind damit Teil der Wissensrepräsentation im Teilgebiet Künstliche Intelligenz. Im Unterschied zu einer Taxonomie, die nur eine hierarchische Untergliederung bildet, stellt eine Ontologie ein Netzwerk von Informationen mit logischen Relationen dar.

NoSQL ("Not only SQL")

NoSQL ("Not only SQL") bezeichnet Datenbanken, die einen nichtrelationalen Ansatz verfolgen und damit mit der langen Geschichte relationaler Datenbanken brechen. Diese Datenspeicher benötigen keine festgelegten Tabellenschemata und versuchen Joins (Ergebnistabellen) zu vermeiden. Sie skalieren dabei horizontal. Im akademischen Umfeld werden sie häufig als „strukturierte Datenspeicher“ („structured storage“) bezeichnet.

RDF (Resource Description Framework)

RDF (Resource Description Framework) bezeichnet eine technische Herangehensweise im Internet zur Formulierung logischer Aussagen über beliebige Dinge (Ressourcen). Ursprünglich wurde RDF vom World Wide Web Consortium (W3C) als Standard zur Beschreibung von Metadaten konzipiert.

Mittlerweile gilt RDF als ein grundlegender Baustein des „semantischen Web“. RDF ähnelt den klassischen Methoden zur Modellierung von Konzepten (UML-Klassendiagramme, Entity-Relationship-Modell). Im RDF-Modell besteht jede Aussage aus den drei Einheiten Subjekt, Prädikat und Objekt, wobei eine Ressource als Subjekt mit einer anderen Ressource oder einem Wert (Literal) als Objekt näher beschrieben wird.

Mit einer weiteren Ressource als Prädikat bilden diese drei Einheiten ein Tripel. Um global eindeutige Bezeichner für Ressourcen zu haben, werden diese dafür nach Konvention analog zur URL geformt. URLs für allgemein häufig benutzte Beschreibungen (z. B. für Metadaten) sind RDF-Entwicklern bekannt, und können so weltweit für den gleichen Zweck verwendet werden, was u.a. Programmen ermöglicht, die Daten wiederum für den Menschen sinnvoll darzustellen.

XML

Die Extensible Markup Language), abgekürzt XML, ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten im Format einer Textdatei, die sowohl von Menschen als auch von Maschinen gelesen werden kann.

XML wird auch für den plattform- und implementationsunabhängigen Austausch von Daten zwischen Computersystemen eingesetzt, insbesondere über das Internet, und wurde vom World Wide Web Consortium (W3C) am 10. Februar 1998 veröffentlicht. Die aktuelle Fassung ist die fünfte Ausgabe vom 26. November 2008. XML ist eine Metasprache, auf deren Basis durch strukturelle und inhaltliche Einschränkungen anwendungsspezifische Sprachen definiert werden. Diese Einschränkungen werden entweder durch eine Document Type Description (DTD) oder durch ein XML Schema ausgedrückt. Beispiele für XML-Sprachen sind: RSS, MathML, GraphML, XHTML, XAML, Scalable Vector Graphics (SVG), GPX, aber auch das XML-Schema selbst.

XSLT

XSL Transformation, kurz XSLT, ist eine Programmiersprache zur Transformation von XML-Dokumenten. Sie ist Teil der Extensible Stylesheet Language (XSL) und stellt eine Turing-vollständige Sprache dar.

XSLT wurde vom World Wide Web Consortium (W3C) am 8. Oktober 1999 als Empfehlung veröffentlicht. XSLT baut auf der logischen Baumstruktur eines XML-Dokumentes auf und dient zur Definition von Umwandlungsregeln. XSLT-Programme, sogenannte XSLT-Stylesheets, sind dabei selbst nach den Regeln des XML-Standards aufgebaut.

Die Stylesheets werden von spezieller Software, den XSLT-Prozessoren, eingelesen, die mit diesen Anweisungen ein oder mehrere XML-Dokumente in das gewünschte Ausgabeformat umwandeln. XSLT-Prozessoren sind auch in vielen modernen Webbrowsern integriert, wie zum Beispiel Opera (ab Version 9), Firefox und Internet Explorer Version 5 (ab Version 6 mit vollständiger XSLT-1.0-Unterstützung). XSLT ist eine Untermenge von XSL, zusammen mit XSL-FO und XPath.

Semantisches Web (Semantic Web)

Das „Semantic Web“ erweitert das Internet derart, um Daten zwischen Rechnern besser austauschbar und für sie einfacher verwertbar zu machen; so kann beispielsweise der Begriff „Bremen“ in einem Webdokument um die Information ergänzt werden, ob hier ein Schiffs-, Familien- oder der Stadtname gemeint ist. Diese zusätzlichen Informationen explizieren die sonst nur unstrukturiert vorkommenden Daten. Zur Realisierung dienen Standards zur Veröffentlichung und Nutzung maschinenlesbarer Daten (insbesondere RDF).

Während Menschen solche Informationen aus dem gegebenen Kontext schließen können (aus dem Gesamttext, über die Art der Publikation oder der Rubrik in selbiger, Bilder etc.) und derartige Verknüpfungen unbewusst aufbauen, muss Maschinen dieser Kontext erst beigebracht werden; hierzu werden die Inhalte mit weiterführenden Informationen verknüpft.

Das „Semantic Web“ beschreibt dazu konzeptionell einen „Giant Global Graph“ (engl. ‚gigantischer globaler Graph‘). Dabei werden sämtliche Dinge von Interesse identifiziert und, mit einer eindeutigen Adresse versehen, als „Knoten“ angelegt, die wiederum durch „Kanten“ (ebenfalls jeweils eindeutig benannt) miteinander verbunden sind. Einzelne Dokumente im Web beschreiben dann eine Reihe von Kanten, und die Gesamtheit all dieser Kanten entspricht dem globalen Graphen.

JSON (JavaScript Object Notation)

JSON (JavaScript Object Notation) ist ein kompaktes Datenformat in einer einfach lesbaren Textform zum Zweck des Datenaustauschs zwischen Anwendungen. Jedes gültige JSON-Dokument soll ein gültiges JavaScript sein und per eval() interpretiert werden können. Aufgrund kleiner Abweichungen in der Menge der erlaubten Unicode-Zeichen ist es jedoch möglich, JSON-Objekte zu erzeugen, die von einem normkonformen JavaScript-Interpreter nicht akzeptiert werden. Davon abgesehen ist JSON aber unabhängig von der Programmiersprache. Parser existieren in praktisch allen verbreiteten Sprachen.

JSON wurde ursprünglich von Douglas Crockford spezifiziert. Aktuell wird es durch zwei konkurrierende Standards spezifiziert, RFC 8259 von Douglas Crockford, und ECMA-404.

JSON wird zur Übertragung und zum Speichern von strukturierten Daten eingesetzt; es dient als Datenformat bei der Datenübertragung. Insbesondere bei Webanwendungen und mobilen Apps wird es in Verbindung mit JavaScript, Ajax oder WebSockets zum Übertragen von Daten zwischen dem Client und dem Server häufig genutzt.

Quellen: Wikipedia; ITWissen.info