Jusletter IT

Das Kriegsopferversorgungsgesetz¹ (im Folgenden KOVG) normiert bestimmte Versorgungsleistungen für Personen, die für die vormalige österreichisch-ungarische Monarchie oder deren Verbündete oder nach dem 13. März 1938 als Soldaten der ehemaligen deutschen Wehrmacht militärische Dienste geleistet und dadurch oder durch die vormilitärische Ausbildung eine Gesundheitsschädigung (Dienstbeschädigung) erlitten haben.² Diesen Versorgungsberechtigten (im Folgenden „Beschädigte“ genannt) sind diverse andere Personen gleichgestellt³ . Hat das schädigende Ereignis den Tod des Versorgungsberechtigten verursacht, so sind dessen Hinterbliebene versorgungsberechtigt.

Eine Gesundheitsschädigung, die im unmittelbaren ursächlichen Zusammenhang mit den durch die militärische Besetzung Österreichs geschaffenen Verhältnissen ohne Verschulden des Beschädigten eingetreten ist, wird wie eine Dienstbeschädigung entschädigt.⁴ Damit sind also auch Fälle erfasst, in denen Personen unverschuldet durch Kriegsrelikte, wie z.B. Blindgänger, verletzt werden.

Das KOVG gewährt dem Antragsteller neben monetären Versorgungsleistungen auch medizinische und soziale Rehabilitationsmaßnahmen.⁵ In der ersten Ausbaustufe des Systems sollen zuerst die Normen der „Beschädigtenrente“,⁶ die in Abschnitt 3 des KOVG normiert sind, formalisiert und anschließend automatisiert vollzogen werden.

Der Beschädigte hat Anspruch auf die Beschädigtenrente, wenn und solange eine Minderung der Erwerbsfähigkeit von mindestens 20% vorliegt. Die Versorgungsberechtigten sind verpflichtet, jede ihnen bekannte Veränderung in den rechtlichen Voraussetzungen für den Rentenbezug, die den Verlust, eine Minderung oder ein Ruhen des Anspruches begründet, binnen zwei Wochen dem Bundesamt für Soziales und Behindertenwesen anzuzeigen.⁷

Beschädigte, die eine Dienstbeschädigung erlitten und eine Minderung der Erwerbsfähigkeit von mindestens 20% aufweisen, werden in diesem Beitrag als „Anspruchsberechtigte“ bezeichnet. Die Minderung der Erwerbsfähigkeit wird nach durch zehn teilbaren Hundertsätzen festgestellt und ist nach Richtsätzen einzuschätzen, die wissenschaftlichen Erfahrungen entsprechen. Das „Bundesministerium für soziale Verwaltung“⁸ ist ermächtigt, durch Verordnung verbindliche Richtsätze festzulegen.^{9 /10} Dem Arzt wird dabei für die Beurteilung der Minderung der Erwerbsfähigkeit bei den meisten Gesundheitsschädigungen ein gewisser Spielraum eingeräumt, wobei für einzelne Krankheiten und Verletzungen auch ein fixer Wert vorgegeben wird.

Das Gesetz unterscheidet nach Minderung der Erwerbsfähigkeit verschiedene Personenkreise, an die bestimmte Versorgungsleistungen, sowie deren Höhe, geknüpft sind.¹¹ Beschädigte mit einer Minderung der Erwerbsfähigkeit von mindestens 50% nennt das Gesetz „Schwerbeschädigte“. Ab einer Minderung der Erwerbsfähigkeit von 90% gelten Schwerbeschädigte als erwerbsunfähig („erwerbsunfähige Schwerbeschädigte“).

Grundsätzlich gilt, je höher die Minderung der Erwerbsfähigkeit ist, desto mehr Versorgungsleistungen stehen dem Antragsteller zu und desto höher ist bei monetären Leistungen die monatliche Rate, die gewährt wird. Bei der Feststellung, welche Versorgungsleistungen gebühren, sowie bei der Bemessung der Höhe der Zahlungen, sind diverse Faktoren wie das Geschlecht, das Alter, die Höhe des Einkommens, die Anzahl der Familienangehörigen, die Anzahl der Dienstbeschädigungen des Antragstellers und weitere zu berücksichtigen.

Gemäß § 63 KOVG hat der Bundesminister für Arbeit und Soziales den für Leistungen nach dem Allgemeinen Sozialversicherungsgesetz vorgesehenen Anpassungsfaktor auch für die im Kriegsopferversorgungsgesetz vorgesehenen Leistungen für verbindlich zu erklären. Die im KOVG angeführten Beträge sind mit diesem Anpassungsfaktor zu vervielfachen und durch Verordnung des Bundesministers für Arbeit und Soziales festzustellen.¹²

Die Feststellung, welche Versorgungsleistungen gebühren, stellt sich demnach als durchaus anspruchsvoll dar. Ein Softwaresystem muss sämtliche dieser Regeln implementieren, um korrekte Ergebnisse zu liefern.

Abschließend soll hier noch erwähnt werden, dass für die Entscheidung in erster Instanz das Bundesamt für Soziales und Behindertenwesen zuständig ist, gegen dessen Entscheidungen die beim Bundesministerium für soziale Sicherheit, Generationen und Konsumentenschutz eingerichtete Bundesberufungskommission für Sozialentschädigungs- und Behindertenangelegenheiten angerufen werden kann.¹³

An dieser Stelle soll nun das Softwaresystem zur (weitgehend) automatisierten Vollziehung des KOVG dargestellt werden. In der ersten Ausbaustufe des Systems soll in erster Linie die Beschädigtenrente von der Software berechnet und anschließend ein entsprechender Bescheid erlassen werden. Die folgende Darstellung skizziert in Grundzügen den Ablauf des automatisiert durchgeführten Verfahrens.

Die E-Government-Software wird als Webanwendung konzipiert, die sich aus mehreren Modulen zusammensetzt. Der modulare Aufbau der Software gewährleistet eine bessere Wartbarkeit und erleichtert die Durchführung (automatisierter) Tests während der Entwicklung. Die Bedienung dieser Software erfolgt über einen herkömmlichen Browser.

Die Authentifizierung des Antragstellers erfolgt ausschließlich mit der Bürgerkarte¹⁴ . Danach findet die Erhebung der Daten für den Antrag statt.

Die Software unterstützt den Antragsteller bei der Einbringung des Antrags mit einem textbasierten Dialogsystem, um die relevanten Fakten zu erheben. Dem Antragsteller werden dabei bereits vorhandene Daten vorgeschlagen, die dieser schließlich annehmen oder bei Bedarf ändern kann. Die Erhebung der Daten geschieht also durch einen Dialog zwischen Mensch und Maschine, wobei der Antragsteller stets die Möglichkeit hat, vorgeschlagene Daten zu ändern und besondere Vorkommnisse anzumerken.

Um den Antragsteller bestmöglich zu unterstützen, werden nicht nur Daten vorgeschlagen, die im eigenen System bereits vorhanden sind, sondern auch Register (Services) anderer Behörden, z.B. das „Zentrale Melderegister“, abgefragt. Die Authentifizierung mittels Bürgerkarte schafft die dafür notwendigen Voraussetzungen, da mit Hilfe des „bereichsspezifischen Personenkennzeichens“ des Antragstellers auch Daten aus einem anderen Verwaltungsbereich abgefragt werden können. Zusätzlich könnten auch Services von privaten Unternehmen abgefragt werden, um z.B. die Höhe des Einkommens des Antragstellers zu ermitteln. Diese Zusammenführung von Daten aus vertrauenswürdigen Quellen wird unter dem Begriff „Federated Identity“ verstanden.¹⁵ Die Verwendung von bereits vorhandenen Daten führt nicht nur zu einer wesentlichen Effizienzsteigerung von E-Government-Systemen, sondern bietet dem Antragsteller die Möglichkeit, seinen Antrag vollständig und korrekt in kürzerer Zeit einzubringen.

Nach der Erfassung der Daten wird der Antrag einem fachkundigen Sachbearbeiter (in der Regel dem zuständigen Beamten) vorgelegt, damit dieser grundsätzliche Plausibilitätsprüfungen vornehmen kann. Die Authentifizierung des Sachbearbeiters erfolgt – ebenso wie jene des Antragstellers – mittels Bürgerkarte. Je nachdem welche Daten der Software aufgrund der vorherigen Schritte zur Verfügung stehen, könnte auch eine automatisierte Überprüfung der eingegebenen Daten stattfinden, um anschließend Widersprüche oder Fehler dem Sachbearbeiter automatisch aufzeigen zu können. Nachdem der Sachbearbeiter die grundsätzliche Prüfung des Antrags durchgeführt hat, entscheidet er, ob der Antrag begründet ist oder abgewiesen wird. Falls der Antrag unbegründet ist, wird vom System ein entsprechender Bescheid erstellt, der das Begehren abweist, und dem Antragsteller elektronisch zugestellt.

Wenn der Antrag begründet ist, wird ein ärztlicher Sachverständiger mit der Erstattung eines Gutachtens über den Gesundheitszustand des Antragstellers beauftragt. Zu diesem Zweck wählt die Software automatisch einen Arzt aus, wobei Faktoren wie die Nähe der Praxis zum Wohnort des Antragstellers etc. automatisch berücksichtigt werden könnten. An den Antragsteller verschickt das System nach Auswahl des Arztes automatisch die Aufforderung, in einer bestimmten ärztlichen Praxis an einem festgelegten Termin zu erscheinen, damit die Untersuchung durchgeführt werden kann.

Der beauftragte Arzt meldet sich mit der Bürgerkarte im System an und erhält Einsicht in den elektronisch geführten Akt. Das Gutachten wird entweder direkt über die Weboberfläche eingegeben oder könnte auch mit Hilfe einer speziellen Software erstellt und anschließend an das System über eine definierte Schnittstelle übermittelt werden. Dafür ist es notwendig, dass die Datenstruktur und das Format des Gutachtens im Voraus definiert werden. Die Erfassung der einzelnen Gesundheitsschädigungen sowie die damit verbundene Minderung der Erwerbsfähigkeit werden strukturiert erfasst und eingebracht. Sofern eine Gesundheitsschädigung direkt mit einem bestimmten Grad der Minderung der Erwerbsfähigkeit verknüpft ist, kann die Software diese automatisch feststellen, womit eine Feststellung derselben durch den Arzt entfällt. Eine Verarbeitung des vom Arzt erfassten Gutachtens mit Technologien wie „Natural Language Processing“ ist daher nicht notwendig. Freilich können der formulierte Text des Gutachtens sowie die dazugehörigen Bilder etc. in den elektronisch geführten Akt eingebracht werden.

Das Gutachten ist ein wesentlicher Bestandteil des Verfahrens, da die vom Arzt festgestellte Minderung der Erwerbsfähigkeit ausschlaggebend ist für die Versorgungsleistungen, die dem Antragsteller gewährt werden. Die Minderung der Erwerbsfähigkeit ist, wie bereits ausgeführt, nach Richtsätzen einzuschätzen, die durch Verordnung festgelegt werden. Die vom Dialogsystem im ersten Schritt erfassten Daten des Antragstellers sowie das ärztliche Gutachten stellen die faktische Grundlage für die automatisierte Entscheidungsfindung durch die Software dar.

Die für die rechtliche Beurteilung notwendigen Regeln sollen aus der Ontologie abgeleitet werden. Dazu zählt in erster Linie das Schema für die Klassifizierung von Personen, für die Einteilung in die eingangs genannten Personengruppen¹⁶ . Ausgehend von dieser grundlegenden Qualifikation einer Person muss die Ontologie genügend Daten enthalten, um feststellen zu können, welche Versorgungsleistungen dem Antragsteller zustehen. Bei monetären Versorgungsleistungen ist es außerdem notwendig, dass die Ontologie die einzelnen Beträge und Prozentsätze enthält, die für die Berechnung der monatlichen Rente erforderlich sind. Die Software muss dabei auf die geltende Rechtslage zum Antragszeitpunkt sowie auf spezielle Sonderzahlungen, die in bestimmten Jahren gewährt werden, Bedacht nehmen.

Das System muss also in der Lage sein, die vorhandenen Fakten (Alter, Geschlecht, Minderung der Erwerbsfähigkeit usw.) unter die normativen Tatbestände zu subsumieren, um die rechtliche Beurteilung durchführen zu können. Dabei sollen die Normen in der Ontologie in einer Form modelliert werden, die sich möglichst direkt, ohne weitere (komplexe) Transformationen von der Software verarbeiten lässt. Welche geeigneten Möglichkeiten der ontologischen Modellierung denkbar sind, wird später noch genauer ausgeführt.

Nachdem die soeben skizzierte rechtliche Beurteilung von der Software durchgeführt wurde, werden die Ergebnisse dem Sachbearbeiter zur Kontrolle vorgelegt. Dieser kann gegebenenfalls Korrekturen vornehmen oder die festgestellte Minderung der Erwerbsfähigkeit sowie die gewährten Versorgungsleistungen sofort bestätigen.

Ausgehend von der rechtlichen Qualifikation muss anschließend ein rechtskonformer Bescheid mit dem erforderlichen Inhalt, insbesondere dem Spruch, der Begründung und der Rechtsmittelbelehrung, erstellt werden. Im Spruch eines stattgebenden Bescheides wird die Gesundheitsschädigung als Dienstbeschädigung anerkannt sowie die Minderung der Erwerbsfähigkeit festgestellt und die gebührenden Versorgungsleistungen gewährt. Freilich muss das System auch in der Lage sein, falls es an bestimmten Voraussetzungen mangelt, einen Bescheid zu erstellen, der den Antrag insgesamt oder teilweise abweist. Abschließend wird der Bescheid elektronisch signiert und an ein Zustellservice weitergeleitet, das die elektronische Zustellung¹⁷ an den Empfänger (den Antragsteller) vornimmt.

Mit der Zustellung ist das Verfahren grundsätzlich beendet, sofern kein Rechtsmittel eingebracht wird. Die Einbringung von Rechtsmitteln soll in diesem Beitrag allerdings nicht weiter behandelt werden.

Weitere Automatismen wie die Ausstellung eines Schwerkriegsbeschädigtenausweises¹⁸ sind denkbar, sollen aber hier ebenfalls nicht weiter erörtert werden.

Zusammengefasst setzt sich die rechtliche Beurteilung durch die Software aus folgenden Schritten zusammen: (1) Die Klassifizierung des Antragstellers anhand der festgestellten Minderung der Erwerbsfähigkeit; (2) Ermittlung der zustehenden Versorgungsleistungen anhand der vorliegenden Fakten; (3) Berechnung des monatlichen Rentenbetrages bei monetären Versorgungsleistungen.

Zweck der Ontologie ist es, die Software bei den soeben dargestellten Schritten der rechtlichen Beurteilung zu unterstützen. Die Ontologie bildet also das Regelwerk für die rechtliche Beurteilung ab.

In diesem Abschnitt soll darauf eingegangen werden, wie das ontologische Modell zur Unterstützung der Software beitragen kann bzw. inwiefern die Ontologie die automatisierte Subsumtion durch die Software unterstützen kann und wo die Grenzen des ontologischen Modells in dieser Hinsicht liegen.

Soweit möglich soll bereits die Inferenzmaschine insbesondere die notwendige Klassifizierung durchführen und Informationen über die zu gewährenden Versorgungsleistungen liefern. Aufgrund der Tatsache, dass OWL eine rein logische Sprache ist, kann die Inferenzmaschine selbst, grundsätzlich ohne spezielle Erweiterungen, keine Berechnungen durchführen. Die Auswirkungen dieser Feststellung werden im Folgenden thematisiert.

Nachdem bei monetären Versorgungsleistungen – wie der Beschädigtenrente mit ihren diversen Zulagen – Berechnungen erforderlich sind, müssen diese von der Software selbst durchgeführt werden.

Diese Problematik tritt ebenso bei der Subsumtion und der Rechtsfolgenermittlung in Erscheinung. Oftmals ist es erforderlich, dass Berechnungen durchgeführt werden, um feststellen zu können, ob eine Versorgungsleistung gewährt werden soll.¹⁹ In solchen Fällen ist es eher unwahrscheinlich, dass bereits die Ontologie im weitesten Sinne²⁰ ein fertiges Ergebnis der Subsumtion liefern kann.

Bei derartigen Problemen wird es sich eher anbieten, dass die Software die Regeln für die rechtliche Beurteilung aus der Ontologie ableitet und diese schließlich auf die vorhandenen Fakten anwendet. Dies schließt nicht aus, dass die Software nach einer derartigen Operation eine neue Aussage²¹ in die Ontologie einfügt, aufgrund derer neue Schlüsse von der Inferenzmaschine gezogen werden können und so die Subsumtion schrittweise voranschreitet.

Etwas einfacher stellt sich das Problem auf Seite der Rechtsfolgenermittlung dar. Sobald festgestellt wurde, dass die jeweilige Versorgungsleistung zu gewähren ist, muss die Software die notwendigen Berechnungen durchführen, um den monatlich zu gewährenden Betrag festzustellen.²²

Das ontologische Modell präzise zu gestalten und dabei möglichst einfach zu halten, stellt sich als eine durchaus anspruchsvolle Aufgabe heraus, die es zu lösen gilt. Es scheint darauf hinauszulaufen, dass einfache Subsumtionsvorgänge durchaus vom ontologischen Modell direkt durchgeführt werden können, während dessen kompliziertere Fragestellungen, die zumeist mathematische Berechnungen voraussetzen, von der Software – aufgrund von in der Ontologie modellierten Regeln – beantwortet werden müssen.

Wie eingangs bereits erwähnt, wird die E-Government-Software als Webanwendung konzipiert, die einem modularen Aufbau folgt. Um die Plattformunabhängigkeit zu gewährleisten, wird die Programmiersprache Java für die Implementierung verwendet werden. Vorhandene Open-Source-Software soll genutzt werden, um die Implementierung zu unterstützen. Die Verwendung von Open-Source-Programmbibliotheken erlaubt es, falls nötig, eine Feineinstellung der Programmbibliotheken durchzuführen und im Ausnahmefall sogar Anpassungen an diesen vorzunehmen.

Das Gesamtsystem folgt einem modularen Aufbau und setzt sich aus mehreren Modulen zusammen, die unterschiedliche Aufgaben erledigen. So soll u.a. ein Modul erstellt werden, das die dargestellte rechtliche Beurteilung samt den notwendigen Berechnungen durchführt. Dieses Modul wird im Folgenden als „Reasoning Module“ bezeichnet. An dieser Stelle soll auf die technische Architektur dieses Moduls näher eingegangen werden. Dieses Modul selbst setzt sich aus mehreren Schichten zusammen, die unterschiedliche Abstraktionsniveaus darstellen. Die höhere Schicht kommuniziert mit der niedrigeren Schicht über Interfaces. Um eine möglichst lose Koppelung der einzelnen Schichten aneinander zu erreichen, hat die niedrigere Schicht keinerlei Abhängigkeiten zur höheren Schicht. Die höhere Schicht ruft dabei Methoden der niedrigeren Schicht auf. Eine Kommunikation in umgekehrter Reihenfolge ist ausgeschlossen.

Die folgende Grafik dient zur Veranschaulichung der Architektur des „Reasoning Module“.

Im Folgenden werden die einzelnen Layer (Schichten), beginnend mit der untersten Schicht, beschrieben.

Ontology Layer: Dieser Layer besteht aus der zu erstellenden „KOVG Ontology“, die auf der „LKIF Core Ontology“²³ aufbauen soll. Die zuletzt genannte Ontologie definiert grundlegende rechtliche Konzepte, die für die Erstellung von fachspezifischen „Domain Ontologies“, zu denen auch die zu erstellende Ontologie zählt, nützlich sein können. Die „KOVG Ontology“ selbst enthält die formalisierten Normen des KOVG und definiert somit die bereits skizzierten Regeln für die Entscheidungsfindung. Für die Erstellung der Ontologie werden die Sprachen RDF, RDFS und OWL 2 zum Einsatz kommen. Dieser Layer ist demnach nicht ein Teil der Software selbst, sondern stellt eher eine externe „Datenquelle“ dar, derer sich das Programm bedient.

Ontology Access Layer: In diesem Layer sind eine Programmbibliothek²⁴ für den Zugriff auf das ontologische Modell sowie eine Inferenzmaschine angesiedelt, mit deren Hilfe neue Schlüsse aus den Daten gezogen werden können. Die verwendete Programmbibliothek stellt bestimmte Methoden zur Verfügung, mit deren Hilfe auf eine Ontologie zugegriffen werden kann. Diese Sammlung von Methoden wird als „Application Programming Interface“ (API) bezeichnet. Einige der verfügbaren Programmbibliotheken bieten eine Schnittstelle für die Koppelung mit einer Inferenzmaschine an. Über einen Plugin-Mechanismus kann grundsätzlich eine beliebige Inferenzmaschine verwendet werden. Ein Programm, das auf die Daten aus der Ontologie zugreifen will, kommuniziert nicht mit der Inferenzmaschine direkt, sondern ruft – wie bereits ausgeführt – Methoden der Programmbibliothek auf. Andere Programmbibliotheken haben ihre eigene Inferenzmaschine bereits integriert. Welche Programmbibliothek sich am besten eignet und daher verwendet wird, muss in weiterer Folge untersucht werden. Verfügbar sind jedenfalls mehrere vielversprechende Programmbibliotheken^{25 /26} , die unter einer Open-Source-Lizenz angeboten werden.

Rule Engine: Dieser Layer repräsentiert die Schnittstelle zwischen den eben dargestellten „ontologischen“ Schichten und der „Reasoning Engine“, die die rechtliche Subsumtion durchführt. Dabei werden die aus der Ontologie gewonnenen Daten in Objekte²⁷ transformiert, die die Regeln repräsentieren, die direkt von der auf der „Rule Engine“ aufsetzenden „Reasoning Engine“ verarbeitet werden können. Diese Abstraktionsschicht ist einerseits notwendig, um die „Reasoning Engine“ von der verwendeten Programmbibliothek für den Zugriff auf die Ontologie zu entkoppeln. Andererseits liefert die „Rule Engine“ eine Reihe von high-level-Objekten, sodass die „Reasoning Engine“ sich nicht mit den low-level-Daten aus der Ontologie befassen muss. In welcher Form diese Regeln als Objekte dargestellt werden, muss noch weiter erforscht werden. Ein derartiger Ansatz ermöglicht es jedenfalls, dass die „Reasoning Engine“ mit den beschriebenen Regelobjekten gespeist wird und so unabhängig von den darunterliegenden Schichten operieren kann. Dies erleichtert das Testen der „Reasoning Engine“ erheblich. Außerdem wäre es theoretisch möglich, dass die Regeln nicht aus einer Ontologie gewonnen werden, sondern z.B. aus einer relationalen Datenbank. Es müsste dafür lediglich die „Rule Engine“ anders implementiert werden. Die Schnittstellen, die von der „Reasoning Engine“ angesprochen werden, sind vollkommen unabhängig von der konkreten Implementierung der „Rule Engine“.

Reasoning Engine: In diesem Layer ist die eigentliche „künstliche Intelligenz“ angesiedelt, die die rechtliche Subsumtion durchführt. Sämtliche vorhandene Daten, die vom Dialogsystem gesammelt wurden, werden der „Reasoning Engine“ zu diesem Zweck zur Verfügung gestellt. Erwähnt sei, dass diese Daten wiederum durch Objekte gekapselt und in dieser Form vom Programm verarbeitet werden. Die Daten, wie z.B. der Vorname des Antragstellers oder dessen Geburtsdatum, werden durch Eigenschaften dieser Objekte repräsentiert. Die „Reasoning Engine“ muss nun anhand dieser Eigenschaften mit Hilfe der von der „Rule Engine“ gelieferten Regeln die rechtliche Subsumtion durchführen. Dabei müssen auch die notwendigen Berechnungen durchgeführt werden. Als Ergebnis liefert die „Reasoning Engine“ wiederum Objekte, die die zu gewährenden Versorgungsleistungen samt dem monatlichen Betrag, der ausbezahlt werden soll,²⁸ repräsentieren.

In diesem Kapitel soll etwas genauer auf die Ontologie eingegangen werden, von der in diesem Beitrag schon öfters die Rede war. Die hier getroffenen Ausführungen repräsentieren den aktuellen Stand der Forschungen und können in Zukunft durch neue Erkenntnisse geändert bzw. widerlegt werden.

Bei der zu erstellenden Ontologie handelt es sich allgemein um eine „fachspezifische“ Ontologie, auch genannt „Domain Ontology“²⁹ , die das in einem Fachbereich (Domäne) vorhandene Wissen repräsentieren soll. Der zu repräsentierende Fachbereich ist – wie bereits weiter oben ausgeführt – das Kriegsopferversorgungsgesetz, wobei der besondere Fokus der Ontologie auf der Unterstützung der automatisierten Subsumtion liegt. Die Ontologie soll auf der LKIF Core Ontology³⁰ aufbauen und mit den Sprachen RDF, RDFS und OWL erstellt werden.

Es empfiehlt sich vor der eigentlichen Modellierung eine Reihe von Fragen aufzustellen, die die Ontologie beantworten soll.³¹ Der damit festgelegte Zweck der Ontologie dient bei der Modellierung als Richtlinie und kann verwendet werden, um im Nachhinein die Qualität der erstellten Ontologie zu bewerten.

Im Wesentlichen, ohne an dieser Stelle zu sehr ins Detail zu gehen, soll die Ontologie folgende Fragen³² beantworten können, die sich aus der dargestellten Funktionalität der Software ergeben:

1. Welcher Personengruppe gehört der Antragsteller aufgrund der festgestellten Minderung der Erwerbsfähigkeit an?
2. Welche Versorgungsleistungen gebühren dem Antragsteller?
3. Wie lautet die Formel für die Berechnung der jeweiligen monetären Versorgungsleistung?

Die Beantwortung dieser einfachen Fragen stellt sich im Detail – wie bereits vorher in diesem Beitrag ausgeführt – als relativ kompliziert dar. Damit die Nachvollziehbarkeit und Überprüfbarkeit von Entscheidungen gewährleistet werden kann, muss die Ontologie sämtliche, auch bereits überholte, Gesetzeslagen abbilden können. Nur so kann gewährleistet werden, dass Bescheide, die auf einer früheren Gesetzeslage beruhen, im Nachhinein noch überprüft werden können.

In einem ersten Schritt sollen die grundlegenden Konzepte des KOVG identifiziert werden. Zu diesen Konzepten gehören zweifelsfrei die einzelnen Personenklassen, die in einer hierarchischen Beziehung zueinander stehen. Dies soll nun näher erläutert werden.

Das KOVG definiert, wie bereits eingangs dargestellt, unterschiedliche Personenkreise. Demnach lasen sich folgende Klassen von Personen unterscheiden:

Beschädigte: Darunter sind in erster Linie „Soldaten“ (i.S.d. KOVG) zu verstehen, die militärische Dienste geleistet und dadurch eine Gesundheitsschädigung („Dienstbeschädigung“) erlitten haben. Diese Personen haben Anspruch auf „Berufliche und soziale Maßnahmen“³³ , „Heilfürsorge“³⁴ etc., jedoch nicht auf die Gewährung einer „Beschädigtenrente“.

Anspruchsberechtigte: „Beschädigte“, deren Grad der Minderung der Erwerbsfähigkeit mind. 20% beträgt³⁵ , haben zusätzlich zu den genannten Versorgungsleistungen einen Anspruch auf Bezahlung einer monatlichen Rente (Beschädigtenrente). Aus diesem Grund sollen sie in diesem Beitrag als „Anspruchsberechtigte“ bezeichnet werden, auch wenn das Gesetz selbst diesen Terminus nicht verwendet.

Schwerbeschädigte: „Beschädigte“, deren Grad der Minderung der Erwerbsfähigkeit mind. 50% beträgt, werden vom Gesetz als „Schwerbeschädigte“ bezeichnet³⁶ und haben Anspruch auf diverse Erhöhungen der Beschädigtenrente.

Erwerbsunfähige Schwerbeschädigte: „Schwerbeschädigte“ mit einer Minderung der Erwerbsfähigkeit ab 90% gelten als erwerbsunfähig. Diese Personengruppe hat Anspruch auf sämtliche Versorgungsleistungen des KOVG.

Die einzelnen Personengruppen werden also nach der Höhe der Minderung der Erwerbsfähigkeit unterschieden, wobei Mitgliedern der höheren Gruppe sämtliche Versorgungsleistungen zustehen, die auch den Mitgliedern der niedrigeren Gruppe gebühren.

Bei genauerer Betrachtung ist jede Personengruppe mit einer höheren Minderung der Erwerbsfähigkeit eine Untergruppe der vorhergehenden Gruppe mit einer niedrigeren Minderung der Erwerbsfähigkeit. So ist – hinsichtlich der zustehenden Versorgungsleistungen – ein Mitglied der Gruppe „Schwerbeschädigte“ sowohl ein Mitglied der Gruppe „Anspruchsberechtigte“, als auch der Gruppe „Beschädigte“ etc.

Die folgende in OWL modellierte Klassenhierarchie soll dies veranschaulichen. Die Namen der Klassen wurden möglichst den im Gesetz verwendeten Termini getreu ins Englische übersetzt und muten daher (möglicherweise) etwas eigentümlich an. Die in der Grafik ersichtliche Klasse „Person“ wird von der LKIF Core Ontology definiert.

Der Antragsteller soll von der Inferenzmaschine gemäß seiner Minderung der Erwerbsfähigkeit in die jeweilige Klasse eingeordnet werden. Technisch gesprochen wird das Objekt, das die Daten des Antragstellers repräsentiert, in das Modell eingefügt und ist eine Instanz einer der soeben dargestellten Klassen. Die rdfs:subClassOf Beziehungen zwischen den Klassen sorgen dafür, dass eine Instanz einer abgeleiteten Klasse auch eine Instanz der übergeordneten Klasse ist. Die Einordnung in eine Klasse selbst soll mit Hilfe von „Restrictions“ erfolgen. Eine „Restriction“ ist ein OWL Sprachkonstrukt.³⁷

Jede Klasse soll dabei mit den Versorgungsleistungen verknüpft werden, die deren Mitgliedern zustehen. Das Konzept der „Versorgungsleistung“ selbst sowie deren Unterkategorien „Beschädigtenrente“, „berufliche Ausbildung“ etc. werden ebenfalls als eine Hierarchie von Klassen modelliert. Wie diese Verknüpfung modelliert wird, muss noch näher untersucht werden. Denkbar ist, dass diese Verknüpfung in der Form modelliert wird, sodass ein spezielles Property³⁸ von der jeweiligen Klasse auf die einzelnen, den Mitgliedern dieser Klasse gebührenden Versorgungsleistungen verweist³⁹ .

Eine besondere Herausforderung stellt die Modellierung der Berechnungen bei monetären Versorgungsleistungen wie insbes. der Beschädigtenrente dar. Eine „einfache“ Modellierung der Formel ist nicht immer möglich, da für einzelne Teile der Berechnung auf vorhergehende Berechnungsschritte zurückgegriffen werden muss. Ebenso müssen Faktoren wie insbes. das Einkommen des Antragstellers, die Anzahl der Familienangehörigen etc. in Anschlag gebracht werden, um zum korrekten Ergebnis zu gelangen. Freilich kann die Addition der im Gesetz normierten Beträge und Prozentsätze relativ einfach in der Ontologie modelliert werden.

Es scheint daher ein kombinierter Ansatz am vielversprechendsten, der einerseits die komplexen Regeln als eine Art Entscheidungsbaum⁴⁰ und andererseits die einfacheren Rechenregeln in einer aufbereiteten Form modelliert. Die gesamte Formel für die Berechnung der einzelnen monetären Versorgungsleistungen soll sich also aus Regeln dieser beiden Kategorien zusammensetzen.

Neben diesen grundlegenden Problemen muss die Ontologie mehrere Versionen einer Norm abbilden können, damit Novellen nahtlos in das Modell eingepflegt werden können. Dafür wird es notwendig sein, dass die einzelnen Regeln mit Gültigkeitszeitraum versehen werden,⁴¹ anhand dessen zu einem beliebigen Zeitpunkt festgestellt werden kann, ob die jeweilige Regel in Geltung ist oder nicht. Vorerst konzentrieren sich die Anstrengungen aber auf die Lösung der zuvor erwähnten Probleme. Danach werden erst die zeitlichen Aspekte der Ontologie in Angriff genommen.

Nachdem die Forschungen bezüglich der Ontologie insgesamt noch nicht weit fortgeschritten sind und weitere ins Detail gehende Erläuterungen den Rahmen dieses Beitrags sprengen würden, soll der Diskurs an dieser Stelle beendet sein. Weiterführende Ergänzungen, die auch die Verwendung der erwähnten LKIF Core Ontology zeigen, werden in einem späteren Beitrag erfolgen.

Im Anschluss an die Darstellung der Ontologie soll noch kurz auf das Potential dieses Ansatzes eingegangen werden.

Die automatisierte Vollziehung des KOVG durch die Software birgt großes Potential, Verfahren rascher, bei niedrigerem Ressourcenverbrauch durchführen zu können. Weitgehend erfolgt die Durchführung einzelner Verfahrensschritte automatisch durch die Software, wobei – falls notwendig – die Aktion eines Menschen erforderlich ist. Daher wird in diesem Beitrag auch von „semi-automatischer Vollziehung“ gesprochen.

Die Ontologie soll das KOVG auf eine übersichtliche Art und Weise darstellen. Diese für Menschen gut verständliche Darstellung des KOVG sollte die einfache Änderbarkeit des Modells ermöglichen, was wiederum die Häufigkeit von Fehlern verringern kann. Zudem ist vorstellbar, dass die formalisierte Darstellung des Gesetzes in Zukunft auch für dessen Vereinfachung als Grundlage dienen könnte.⁴²

Änderungen der normativen Grundlage durch Novellen sollen in das ontologische Modell eingepflegt werden und stehen damit der Software zur Verfügung. Änderungen des Programmcodes sollen dadurch in Zukunft weitgehend vermieden werden. Dies kann erheblich zu einer Senkung der Wartungskosten beitragen, da es nicht mehr erforderlich ist, einen IT-Dienstleister mit der Durchführung von Anpassungen der Software zu beauftragen.

Die Auswirkungen von Änderungen des Modells können schließlich sehr gut, auch automatisiert, getestet werden. Die dargestellte „Reasoning Engine“ wird dafür von kleinen Testprogrammen mit den entsprechenden Daten „gefüttert“ und die Ergebnisse ausgewertet. Auch für diese Tests sollten Codeänderungen nur im Ausnahmefall notwendig sein, da die „Reasoning Engine“ für die Durchführung der Tests direkt auf dem geänderten ontologischen Modell operiert und damit bereits die zu testenden Regeln anwendet.

Die weiteren Forschungen werden zeigen, inwieweit ein ontologisches Modell geeignet ist, die automatisierte Entscheidungsfindung zu unterstützen. Erwartungsgemäß soll ein Ansatz gefunden werden, wie Gesetze, die dem KOVG ähnlich sind, d.h. deren Vollziehung Berechnungen erfordert, automatisiert vollzogen werden können. Dabei soll die Komplexität der Ontologie so niedrig wie möglich gehalten werden, damit das Modell eine gute Änderbarkeit aufweist und damit weniger anfällig für Fehler ist. Die gewonnenen Erkenntnisse könnten jedenfalls von Bedeutung sein für die Modellierung des HVG⁴³ , das an mehreren Stellen auf das KOVG verweist und ähnliche Normen enthält, und das BPGG⁴⁴ etc.

Erste Experimente zeigen, dass vor allem die Modellierung der Berechnungen etwas anspruchsvoller ist. Insbesondere die Teile einer Berechnung, die auf einen anderen dynamisch berechneten Betrag verweisen, lassen sich schwer mit OWL abbilden.

Zunächst sollen jedenfalls die dargestellten Personenklassen des KOVG modelliert und anschließend ein erstes kurzes Programm implementiert werden, das das „Jena Semantic Web Framework“ bzw. die „OWL API“ verwendet, um die Klassifizierung des Antragstellers durchzuführen. Diese ersten Tests sollen auch zeigen, welche der beiden Librarys für den gegenständlichen Zweck am besten geeignet erscheint.

Fragen richten Sie bitte an den Autor, zu erreichen unter der am Anfang des Beitrags angegebenen E-Mail-Adresse.

Sartor, G. (Hrsg.), Approaches to Legal Ontologies: Theories, Domains, Methodologies, Springer Netherlands (2011).

Schweighofer, E., An Ontological Representation of EU Consular Law. In: Francesconi, E., Montemagni, S., Rossi, P., Tiscornia, D. (Hrsg.), Proceedings of the 4th Workshop on Legal Ontologies and Artificial Intelligence Techniques 2010, Florenz, S. 77–86 (2010).

Hoekstra, R., Breuker, J., Di Bello, M., Boer, A., The LKIF Core Ontology of Basic Legal Concepts. In: Casanovas, P., Biasiotti, M., Francesconi, E., Sagri, M. (Hrsg.), Proceedings of the 2nd Workshop on Legal Ontologies and Artificial Intelligence Techniques 2007, Stanford, S. 43–63 (2007).

Gangemi, A., Design patterns for legal ontology construction. In: Casanovas, P., Biasiotti, M., Francesconi, E., Sagri, M. (Hrsg.), Proceedings of the 2nd Workshop on Legal Ontologies and Artificial Intelligence Techniques 2007, Stanford, S. 65–85 (2007).

Allemang, D., Hendler, J., Semantic Web for the Working Ontologist, Morgen Kaufmann, Burlington (2008).

Hitzler, P., Krötsch, M., Rudolph, S., Sure, Y., Semantic Web, Springer, Berlin/Heidelberg (2008).

Noy, N., McGuinness, D., Ontology Development 101: A Guide to Creating Your First Ontology. http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html, aufgerufen: 1.1.2012.

Philipps, L., Anschauliche Normlogik. Zugleich eine Erinnerung an Bindings Normentheorie, in: Jusletter IT 5. Oktober 2011.

Bron, M., Eli-Ali, A., Ji, X., Klarman, S., Modeling Nomic in LKIF-Core Ontology., Leibniz Center for Law (2007).