Jusletter IT

Um maschinell verarbeitet werden zu können, müssen juristische Sachverhalte, Texte, Regelungen etc. modelliert werden. Hierbei besteht die Gefahr, dass ihre Bedeutung verloren geht: Ein Computer «versteht» nicht, was er macht, sondern er führt nur exakt (sowie schnell und genau) diejenigen Anweisungen aus, die er durch das Programm erhält. Daher ist die Bildung des Modells und seine Verifizierung ein essentieller Bestandteil des Entwurfs bzw. der Implementierung eines juristischen Systems. Dieser Beitrag soll untersuchen, inwieweit Methoden der Informatik hierbei auch auf den juristischen Teil des Problems angewendet werden können: Ist es z.B. möglich, nicht nur die Implementation automatisiert zu testen, sondern ob darüber hinaus das juristische Modell bzw. die Regeln korrekt umgesetzt wurden?

Um für die folgende Diskussion ein einheitliches Verständnis zu schaffen, sollen einige Begriffe definiert werden: Unter «Syntax» wird hier die Lehre vom Satzbau verstanden. Es handelt sich darum, wie durch den Computer zu verarbeitende Aussagen aufgebaut sein dürfen (Zeichensatz und Codierung, sowie Regeln für den Aufbau von Wörtern/Sätzen/etc.), d.h. um Zeichenmanipulation: Was ist ein wohlgeformter (=gültiger, akzeptabler, verarbeitbarer – aber nicht notwendigerweise mit der Realität übereinstimmender – Satz und was nicht). Im Ergebnis also, was man «schreiben darf» und was nicht. Ein solcher besitzt weiters eine (möglicherweise falsche, aber jedenfalls nicht sinnfreie) Bedeutung. Diese Ebene kann problemlos von einem Computer vollautomatisch überprüft und bearbeitet werden. Ist die verwendete Sprache nach bestimmten Regeln aufgebaut, so ist auch sichergestellt, dass derartige Aktionen effizient durchgeführt werden können (wobei dies vielfach keine relevanten Einschränkungen bedeutet)¹ . Das Ergebnis ist per Definition immer «richtig», sofern die Regeln und die Ausgangspunkte (Axiome) korrekt sind. Allerdings bedeutet die «Richtigkeit» hier nur, dass es sich um einen korrekt geformten Satz innerhalb des Systems handelt: So ist z.B. die Aussage «WENN Hinterzogene Steuer > € 1 Million DANN Todesstrafe» in einem bestimmten System problemlos als (syntaktisch) richtige Regel anzusehen und kann automatisiert verarbeitet werden. Gleichzeitig ist jedoch klar, dass ihre Übertragung in die Realität auf vielfältige Weise problematisch wäre und meist nicht im Einklang mit geltendem Recht steht.

Von der Syntax ist die Semantik zu unterscheiden; die Bedeutung die den Zeichen bzw. ihren Kombinationen zugewiesen wird. Diese wird u.A. wie folgt definiert: «Als Semantik ist sie eine Relation zwischen Zeichen, nicht eine zwischen Zeichenträgern und Gegenständen, also keine bloße Namensbeziehung. Es werden nicht Bezeichnungen und Objekte in Beziehung gesetzt, sondern Bezeichnungen mit Vorstellungen von Personen über Objektverhältnisse.»² Der erste Teil weist darauf hin, dass auch eine automatische Behandlung möglich sein könnte: «Relation zwischen Zeichen». Der zweite relativiert dies jedoch: Es geht nicht um die Verhältnisse der Objekte, sondern wie «jemand» sich diese Verhältnisse vorstellt, d.h. eine subjektive Sicht (=menschliche Interpretation). Im Hinblick auf die obige Beispielregel bedeutet daher die Semantik, was unter der Zeichenfolge «Todesstrafe» zu verstehen ist. So mag obige Regel für Österreich als völlig ausgeschlossen gelten, da die Todesstrafe in Österreich abgeschafft ist. Doch nimmt man eine besondere Bedeutung dieser Zeichenfolge an, so wird die Regel plötzlich durchaus möglich: Hinterzieht eine juristische Person Steuern in großem Stil, so könnte man durchaus eine Zwangsauflösung (=Todesstrafe für die jur. Person) festsetzen! Im Hinblick auf die Modellbildung ist es deshalb besonders wichtig, die Semantik möglichst exakt zu definieren bzw. zu beschreiben. Denn auch wenn die Interpretation des Wortes «Todesstrafe» als Verleihung eines Ordens wohl eher fern liegt, so bleibt einem Computer doch unbekannt was nun wirklich genau im konkreten Zusammenhang gemeint ist.

Es besteht daher eine Notwendigkeit, entweder die Semantik aus der Modellbildung und nutzung zu entfernen, oder sie irgendwie einzubauen. Ein vollständiger Verzicht ist zwar möglich, bedeutet jedoch auch einen Verzicht auf reale Anwendbarkeit, da das Modell auf eine rein mathematische Analyse reduziert wird. Das Ergebnis ist daher, dass ein reales Element mitsamt seiner Bedeutung auf eine syntaktische Ebene reduziert wird, wo es dann automatisiert bearbeitet werden kann, woraufhin das Ergebnis der Verarbeitung wieder mit einer realen Bedeutung zu versehen ist. Hierbei handelt es sich um die Bildung bzw. Nutzung von Modellen, die im Folgenden genauer untersucht wird. Während die Vorgänge im Modell mit Informatik-Methoden gut erfassbar und testbar sind, gilt dies nicht gleichermaßen für die Übergänge zur Realität, welche im Anschluss untersucht werden.

Bei der Modellbildung wird versucht, reale Vorgänge, Schlussfolgerungen, Regeln etc. in abstrakter Form von der Semantik-Ebene auf die Syntax-Ebene abzubilden. Bei der anschließenden Nutzung dieses Modells wird aus einem konkreten Realgeschehen eine entsprechende syntaktische Repräsentation erzeugt, diese im Modell bearbeitet, und anschließend wieder zurück transformiert («Intelligent Reasoner», [Schweighofer 2007]). Dies alles in der Hoffnung, dass das Ergebnis identisch ist, wie wenn die Regeln direkt angewendet worden wären. Es handelt sich daher um einen Umweg, der (üblicherweise; Sonderfälle hier außer Acht gelassen) dann sinnvoll ist, wenn die direkte Anwendung komplizierter bzw. aufwändiger ist als Transformation und Rücktransformation. Dies gilt insbesondere dann, wenn die direkte Bearbeitung händisch zu erfolgen hätte, jedoch die Verarbeitung des Modells automatisiert erfolgt. Idealerweise erfolgen auch die beiden Transformationen automatisch oder werden vom Computer unterstützt. Ein typisches Anwendungsgebiet für derartige Modelle ist das EGovernment, wo bereits jetzt mit Modellen als Wissensrepräsentation, z.B. bei Massenverfahren, einfachere Verwaltungsvorgänge automatisiert werden können [Schweighofer 2002]. Modelle können aber auch anderen Zwecken dienen, etwa der Schaffung als gemeinsame Basis für Kommunikation (Beispiel: «Welche rechtliche Regelung wäre besser/einfacher zu verstehen/einfacher zu administrieren/…?»), zum Rechtsvergleich (genauere bzw. leichtere Identifikation der Unterschiede; z.B. durch kommentierte Verlinkung [Schweighofer 2010]) oder zur automatischen Generierung von Fällen für den Einsatz im Unterricht.

Dieses Vorgehen wird als Meta-Modell in Abbildung 1 dargestellt und hier anhand der Lösung von Rechtsfällen erläutert und untersucht, gilt aber gleichfalls für andere Anwendungen, z.B. die automatisierte Textanalyse [Schweighofer 1999a], etwa von Gesetzestexten [Schweighofer 2006]. Der direkten Folgerung vom Sachverhalt zur Rechtsfolge auf der Realitäts-Ebene (1) entspricht die «normale» Falllösung durch Menschen. Diese soll nun durch die Abbildung des Sachverhaltes auf ein Modell (Formalisierung; 2), Deduktion innerhalb des Modells (3) auf der Syntax-Ebene, sowie die Rücktransformation in die Realitäts-Ebene (4) ersetzt werden.

Abbildung 1: Meta-Modell der Behandlung jur. Probleme mittels Informationstechnologie

Bei all diesen Schritten können Probleme auftreten. Im Bereich der Formalisierung (2) stellt sich z.B. die Frage, wie eine Entität der Realitäts-Ebene abzubilden ist, für die mehrere Repräsentation auf der Syntax-Ebene existieren. Es scheint am besten, diejenige Modellierung auszuwählen, welche die stärksten Restriktionen umfasst, die vom Sachverhalt abgedeckt werden können. Hier tritt jedoch potentiell ein Problem bei der Rücktransformation (4) auf, da sich ein detaillierteres Resultat ergeben kann, als es sollte. Als Beispiel: Wird in einem Modell zwischen «Körperverletzung», «Leichter Körperverletzung» sowie «Schwerer Körperverletzung» unterschieden, so ist eine Abbildung einer «Verletzung» auf die Kategorie «Körperverletzung» zwar sehr klar und einleuchtend, aber potentiell problematisch. Denn im Sachverhalt ist nur von einer allgemeinen Verletzung die Rede, ohne dass Informationen über ihre Schwere vorliegen. Die konkrete Formalisierung würde dann Details hinzufügen (=«normale» Körperverletzung), die nicht feststehen. Entsprechend würde das Resultat sehr viel spezifischer ausfallen als es eigentlich sollte. Konkret könnte dies ein exakter Strafrahmen sein anstatt des Erfordernisses, die Verletzungsschwere festzustellen. Da in diesem Resultat aber «Körperverletzung» nicht mehr vorkommt (sondern nur mehr z.B. «Geldstrafe»), ist eine Berücksichtigung dieser Unschärfe bei der Rücktransformation vielfach unmöglich.

Gleiches gilt für den umgekehrten Fall, wenn ein detailliertes Real-Element auf eine unspezifischere Modellrepräsentation abgebildet wird: Es geht Information verloren, welche bei der Rücktransformation nicht mehr wiederhergestellt werden kann. Im obigen Beispiel entspräche dies der Abbildung einer «Körperverletzung mit Todesfolge» aus dem Sachverhalte auf eine «Schwere Körperverletzung»: Vom Grunde her richtig, jedoch nicht vollständig.

Ein verwandtes Problem existiert bei der Rücktransformation (4), wo etwa in Falllösungssystemen bestimmte Rechtsgebiete, z.B. das Strafrecht oder das UDRP-Schiedsverfahren [Schweighofer 2000], beliebt sind. Der Hintergrund ist, dass die Interpretation des formalen Ergebnisses oft schwierig ist: Wie sollen die verschiedenen einzelnen Ergebniselemente kombiniert werden? Daher werden Rechtsgebiete mit klar definierten und kleinen Resultatsräumen bevorzugt. Geht es nur um Freispruch/Gefängnis- oder Geldstrafe sowie deren Ausmaß oder handelt es sich darum, aus einem großen Repertoire an Optionen und Kombinationsmöglichkeiten konkrete Umweltauflagen festzulegen oder bestimmte Anforderungen zu einem widerspruchsfreien und vollständigen Vertrag zu kompilieren? Es muss daher versucht werden, auch das Ergebnis möglichst detailliert abzubilden, sodass die Rücktransformation im Idealfall trivial wird («Geldstrafe € 1000» ist verhältnismäßig eindeutig und klarer zu interpretieren als «Geldstrafe in angemessener Höhe»).

Im Hinblick auf die Modellbildung sowie die Abbildung der Folgerung (1) auf die Deduktion (3) sind folgende Elemente besonders wichtig und daher beim Testen nach Möglichkeit besonders zu berücksichtigen:

• Reduktion: Das Weglassen von Details aus der Realitäts-Ebene. Im Unterschied zur Abgrenzung werden die Objekte sehr wohl repräsentiert, aber nur in einem geringeren Detailliertheitsgrad. So ist z.B. bei einer Kopie eines Musikstückes die verwendete Codierung irrelevant³ , während der Inhalt sehr wohl wichtig ist. Hierin liegt der Hauptzweck eines Modells: Eine Vereinfachung der Wirklichkeit zu erzeugen.
  
  
• Abgrenzung: Irrelevante Objekte der Realitäts-Ebene sollten nicht berücksichtigt werden, um das Modell nicht unnötig zu komplizieren. Wichtig ist, dass diese Elemente in keinem möglichen Fall eine Bedeutung für das Ergebnis besitzen dürfen. Dies kann auch als Abgrenzung des Systems zu seiner Umgebung verstanden werden: Was wird modelliert und was nicht. Siehe dazu unten die Kontextabhängigkeit. Beispiel: Bei Urheberrechtsdelikten im Internet ist die Verpackung des kopierten Werkes meist⁴ kein relevanter Faktor und kann bei der Beurteilung der Rechtmäßigkeit einer Vervielfältigung weggelassen werden, anders etwa als im Fernabsatzrecht (Versiegelung ( Kein Rückgaberecht für Computerprogramm-Datenträger).
  
  
• Dekomposition: Die Objekte werden für die automatisierte Bearbeitung in kleinere Teile zerlegt. Dies bedeutet, dass eine solche Zerlegung auch bei der manuellen Folgerung (1) zumindest potentiell erforderlich ist. Doch selbst wenn dies dort nur ein seltener Spezialfall ist, erfordert die Modellierung eine Berücksichtigung in jedem einzelnen Fall (insbesondere auch für die Formalisierung wichtig!), damit eine für die praktische Anwendung ausreichende Bestimmbarkeit gegeben ist. Als Beispiel kann das zur Verfügung stellen eines Musikstückes durch Einstellen in ein P2P Netzwerk dienen, das tatsächlich aus einem Vervielfältigten des Originals besteht, dem Kopieren auf einen Server, und dem entsprechenden Konfigurieren und Starten des Filesharingprogramms. Bei Raubdrucken ist eine solche genaue Unterteilung hingegen nicht erforderlich, da sich dort die Frage einer Privatkopie oder von Caching gar nicht stellt.
  
  
• Abstraktion: Die Bildung einer Hierarchie der einzelnen Elemente ist erforderlich, um automatisiert Verallgemeinerungen treffen zu können. Potentiell problematisch ist hierbei, dass notwendigerweise Details wegfallen. Es ist daher darauf zu achten, dass auf Verallgemeinerungen basierende Regeln auch tatsächlich für alle möglichen Interpretationen gelten und nicht nur für jene, die im Augenblick zusammengefasst werden; bzw. dass solche Einschränkungen dokumentiert werden. Als Beispiel kann dienen, dass das Einstellen auf einen anonym zugänglichen FTP Server ebenso wie das in ein Filesharing-Netz problemlos als «Zur-Verfügung-Stellen» abstrahiert werden kann. Ein ähnliches Einstellen von Dateien auf einem Sharehoster jedoch nicht unbedingt: Ohne Bekanntgabe/Veröffentlichung/Indizierung durch eine Suchmaschine des zugehörigen Links bleibt die Datei zwar technisch verfügbar, ist aber für Dritte unauffindbar, sodass zusätzliche Elemente erforderlich sind und eine direkte Einordnung unterhalb dieser Abstraktion falsch wäre.

Obwohl Ansätze bestehen, Normen automatisiert in Regeln oder Prozessdiagramme umzusetzen, und dies ein sehr erstrebenswertes Ziel ist, sind die Methoden hierfür derzeit noch nicht genügend ausgereift [Schweighofer 2005b]. Bei solcher automatischer Generierung eines Modells ist das Testen noch viel bedeutsamer, da ansonsten Fehler erst beim Einsatz erkannt werden können, sofern nicht eine vollständige (und aufwändige) manuelle Inspektion erfolgt, was den Vorteil der automatisierten Erstellung jedoch relativiert.

In diesem Abschnitt sollen einige ausgewählte Probleme der Modellbildung daraufhin untersucht werden, wie sie sich im Bereich der Rechtswissenschaft darstellen.

Die Kontextabhängigkeit ist Ausfluss der oben erwähnten Abgrenzung: Ist selbige nicht ganz «korrekt», d.h. wurden auch relevante Teile entfernt und daher nicht modelliert, so besteht eine Abhängigkeit von der Umgebung. In direkter Form (Beispiel: Tatbestandselemente eines zu bearbeitenden Deliktes) wird dies kaum vorkommen, doch in der Rechtswissenschaft existieren sehr subtile Umgebungsbedingungen, die zu Problemen führen können. Beispiele hierfür sind, dass Definitionen aus anderen Gesetzen stammen und diese Gesetze verändert werden. Derartige Punkte werden insbesondere bei einer Wartung des Modells leicht übersehen. Noch viel «heimlicher» sind Änderungen der Rechtsprechung: Ändert der EuGH (oder definiert er genauer) die Bedeutung einer Richtlinie, so hat dies keinerlei direkte Auswirkungen auf das nationale Umsetzungsgesetz. Dennoch ist im Rahmen der Richtlinienkonformen Interpretation dieser Kontext zu berücksichtigen.

Eine mögliche Abhilfe ist es, auch die Umgebung zu modellieren, d.h. die Abgrenzung weiter nach außen zu schieben. Dies wäre jedoch oft mit sehr großem Aufwand verbunden und würde eine hohe Komplexität schaffen, da diese neue Grenze selbst wieder eine Umgebung besitzt und aktuell zu halten ist. Es würde lediglich die Abgrenzung nach außen verschoben und gleichsam der Durchmesser des Kreises vergrößert, mit der Folge eines größeren Umfangs (= zu überwachenden Schnittstelle zur Umgebung)!

Die explizite Kennzeichnung bzw. Modellierung der Annahmen, Randbedingungen und Kontextabhängigkeiten, z.B. im Sinne eines ontologischen Thesaurus [Schweighofer 2004], ist eine mehr Erfolg versprechende Alternative. Diese kann einerseits rein der Dokumentation dienen, um eine spätere Aktualisierung (oder eine Überprüfung auf die Notwendigkeit einer solchen hin) zu ermöglichen, andererseits ist es ev. möglich, diese Informationen automatisiert weiterzuverarbeiten und bei der Deduktion/Rücktransformation mitzuführen. Damit könnte das jeweilige Ergebnis um seine externen Abhängigkeiten ergänzt werden, sodass auch eine konkrete Prüfung auf etwaige damit verbundenen Probleme möglich wäre.

In vielen Fällen sind juristische Modelle zeitunabhängig, d.h. statisch. Dies ist kein Problem bei der Beurteilung eines aktuellen Falles mit kurzer Sachverhaltsdauer. Erstreckt sich jedoch die Handlung über längere Zeit oder findet die Beurteilung später statt, so kann sich die Rechtslage inzwischen geändert haben, was sich im Modell widerspiegeln sollte. Weiters ist oft die Reihenfolge von Aktionen bedeutsam: Ablaufen der Schutzfrist vor bzw. nach einer Verbreitung.

Die typische Lösung hierfür ist die Versionierung: Das Modell gilt für einen ganz bestimmten Zeitpunkt. Bei allen Änderungen wird das Modell entsprechend angepasst und die alte Version archiviert⁵ . Dies ist im Hinblick auf Gesetzesänderungen für die Zukunft noch vergleichsweise einfach, doch rückwirkende Änderungen oder Änderungen in der Interpretation (z.B. was im Geschäftsleben als unlauter angesehen wird) sind bedeutend komplexer. Hier können Querverweise zu entsprechenden Datenbanken helfen, sofern dort derartige Informationen vorliegen, wie etwa in [Schweighofer 2003] beschrieben: Annotation von Judikatur als neu, klärend, bestätigend oder abändernd. Eine andere Möglichkeit ist, zeitliche Effekte als separates Element zu modellieren. Dann hängt beispielsweise die Schutzfrist nicht davon ab, wann bestimmte Ereignisse eintraten, sondern es wird lediglich modelliert «Schutzfrist abgelaufen» bzw. «Schutzfrist nicht abgelaufen». Dies führt zu Problemen, wenn sich dadurch eine Vielzahl möglicher Elemente ergibt⁶ .

Eine Alternative ist der Einsatz temporaler Logik. Dies bedeutet, dass nicht nur das Modell sondern auch die Subsumptionsregeln (3) Zeitaspekte beinhalten. Es ist dann beispielsweise nicht mehr ausreichend, dass die Tatbestandselemente A UND B vorliegen, sondern dass At UNDsimultan Bt oder At UNDbevor Bt⁷ gelten. Entsprechende Logiken existieren, doch stellt sich hier das Problem, dass technologische Unterstützung vergleichsweise schwach ist, und die üblichen Modellierungssprachen wie OWL⁸ oder Abfragesprachen wie SPARQL⁹ rein statisch ausgelegt sind. Im Gegensatz zur Versionierung lassen sich mit solcher Logik nicht nur «alte» sondern auch «lange» Fälle lösen.

Zur Dekomposition bzw. Abstraktion stellt sich die Frage, ob bei einer Zerlegung in Einzelteile die Summe der Teile noch dem Ganzen entspricht. Dies entspricht im juristischen Bereich der systematischen Interpretation: Das Ergebnis kann weder aus einer einzigen Vorschrift noch der direkten Kombination mehrere Stellen abgeleitet werden. Es muss hingegen zwangsweise aus der Zusammenschau mehrerer Elemente, ihrer Abstraktion, der Bildung eines allgemeinen Grundsatzes, und der Anwendung dieses Grundsatzes gebildet werden, sodass die Summe der einzelnen Gesetze daher nicht gleich dem Gesamtergebnis ist.

Dies ist ein besonders schwieriger Aspekt der Modellbildung, da zwar (irgend)eine Aufteilung in Einzelteile/Zusammenfassung zu allgemeineren Klassen immer möglich ist, jedoch ein Beweis der Vollständigkeit (oder des Fehlens derselben!) sehr schwer ist. Vielfach wird das konkrete Modell auch richtige Ergebnisse liefern, doch insbesondere in ausgefallenen Konstellationen besteht die Gefahr für inkorrekte Resultate.

Ein Ansatzpunkt zur Reduktion des Problems ist systematisches Testen (siehe unten). Doch bereits während des Entwurfs können bestimmte Überlegungen hilfreich sein. So sollte geprüft werden, ob die Inversion der Zerlegung auch wieder den Ursprung ergibt. Ein Beispiel hierfür sind ungeschriebene Tatbestandsmerkmale, welche bei der Zerlegung nicht abgehen, bei der Inversion aber als Fehlend auffallen würden. Es ist deshalb nicht nur die Frage zu stellen, in welche Elemente eine Bestimmung aufzuteilen ist, sondern es ist auch ein hypothetischer Fall zu konstruieren, der in allen Einzelelementen gerade eben noch ausreicht, diese Bestimmung zu erfüllen. Bei der Inversion müssen dann alle seine Teile auch tatsächlich Verwendung finden. Dies gilt prinzipiell nicht nur bei der Formalisierung (4) sondern auch bei der Rücktransformation (2), ist bei letzterer jedoch seltener ein Problem. Beispiele wären, dass «außergewöhnliche» Rechtsfolgen leicht vergessen werden, etwa die Einziehung von Verletzungshilfsmitteln (z.B. Druckplatten) oder eine Urteilsveröffentlichung.

Da die Deduktionsregeln von der Realität auf beiden Seiten (Formalisierung und Rücktransformation) getrennt sind, besteht erhöhte Fehlergefahr. Entspricht etwa eine Deduktionsregel «direkt» der Realität, kann sie dennoch falsch sein, da eine – für sich allein richtige – Formalisierung zu einer leicht veränderten Ausgangssituation auf der Syntax-Ebene führen kann, sodass sich eine Fehlinterpretation durch die Verkettung ergibt. Die syntaktische Regel ist durch die Transformation von der Semantik über eine weitere Indirektionsstufe getrennt. Die Rücktransformation wird hingen meist aus dem Ergebnissen abgeleitet und «umgekehrt», sodass diese gleich der Formalisierung direkt mit der Realität verbunden ist. Besonders leicht entstehen derartige Fehler auf der Ebene von Klassen. Gilt eine Regel immer und ausnahmslos für jedes (derzeitige, aber auch zukünftige!) Objekt dieser Klasse? Bei der Modellierung eines Heimwerkermarktes wird es sich bei «Birnen» meist um Leuchtkörper handeln. Doch bei einer Erweiterung auf allgemeine Supermärkte kann dann ein Problem mit Lebensmitteln entstehen. Dies ist noch offensichtlich. Doch sind nicht alle «Glühbirnen» auch tatsächlich solche, sondern u.U. Energiesparlampen, d.h. eigentlich Leuchtstoffröhren, und unterliegen damit anderen Entsorgungsvorschriften. Hier ist daher eine Erweiterung des Warenangebots sehr viel «gefährlicher». Derartige Homonyme zu differenzieren ist ein schwieriges Problem, insbesondere bei mangelndem Verwendungskontext (wie etwa in Suchanfragen; [Schweighofer 1999b]). Genau dieser fehlt hier, da Regeln prinzipiell allgemein formuliert werden müssen. Umso detaillierter daher die Aufgliederung, desto leichter schleichen sich derartige Fehler ein, da ein Syntax-Element (=Wort) mit steigender Spezialisierung ein immer größeres Ausmaß an Bedeutung (=Semantik) repräsentieren muss.

Folgendes Beispiel aus dem Datenschutzbereich kann, neben den Problemen von Übersetzungen, als weitere Exemplifizierung dienen: Wird die Sicherheit der Datenverarbeitung vernachlässigt und gehen Daten verloren, so kann es z.B. bei Auftragsdatenverarbeitung zu einem Schadenersatzanspruch kommen. Wird nun «Sicherheit der Daten» auf «protection of data» sowie «Datenverlust» auf «loss of data» formalisiert, so sind dies durchaus gültige Abbildungen. Gleichfalls erscheint die Umsetzung von «NICHT Sicherheit der Datenverarbeitung UND Datenverlust ( Schadenersatz» auf «NOT protection of data AND loss of data ( liability» durchaus plausibel. Dennoch ist diese Abbildung zumindest potentiell falsch, da zwischen «data protection» und «data security» zu unterscheiden ist (Datenschutz bzw. Datensicherheit) sowie «loss of data» nicht nur die Löschung sondern auch eine unberechtigte Weitergabe an Dritte bedeuten kann. Denn selbst wenn exakt definiert wird, was im konkreten Modell unter «protection» zu verstehen ist, müsste sichergestellt werden, dass sowohl bei der Anwendung des Modells (konkrete Fakten entsprechend klassifizieren/transformieren) wie auch bei einer etwaigen Erweiterung desselben immer exakt diese–und nur diese–Bedeutung verwendet würde. Vergleiche hierzu das LOIS Projekt [Schweighofer 2005a], wo durch einen multilingualen Thesaurus derartige Probleme bekämpft werden, indem Begriffe aufeinander abgebildet und mit einer Glosse versehen werden.

Eine Reduktion des Problems ist u.A. durch eine exakte Definition des Modells sowie der Deduktionsregeln möglich. Eine Nachkontrolle kann insbesondere durch ausführliches und systematisches Testen erfolgen.

In diesem Abschnitt wird erläutert, wie Modelle getestet werden können. Ähnlich wie sich das Testen von Software von einem irgendwie bei Gelegenheit durchgeführten Prozess zu einem systematisierten und fixen Element des Softwareentwicklungszyklus entwickelt hat, sollte auch das Testen juristischer Modelle entsprechend erfolgen: Von vornherein festgelegt und genau geplant. Beim Testen ist zu unterscheiden, was geprüft wird: Die korrekte Umsetzung des Modells (Verifikation) oder ob das Modell den Anforderungen bzw. der Realität entspricht (Validierung).

Eine Systematisierung des Prozesses des Testens von Modellen beinhaltet insbesondere die folgenden Elemente (typ. hinsichtlich Verifikation):

• Automatisierung: Tests sollen nach Möglichkeit automatisiert durchgeführt werden, was insbesondere beinhaltet, dass keine menschliche Überprüfung des Ergebnisses erforderlich ist. Nur hierdurch wird es möglich, Tests häufig durchzuführen, z.B. nach jeder Änderung des Programms, des Modells oder der Daten. Eine Schwierigkeit hierbei kann die Sprache sein: Wird ein Ergebnis in natürlichsprachlichen Text umgewandelt, so ist vielfach nur mehr ein Vergleich auf exakte Übereinstimmung mit einem vorgegebenen anderen Text möglich. Da jedoch nicht alle Tests immer den gesamten Zyklus (1 – 4) umfassen müssen, ist auch eine Prüfung vor der Rücktransformation möglich, wo das Ergebnis noch formalisiert und daher leichter vergleichbar ist.
  
  
• Systematisierung: In der Informatik dienen Tests nicht dazu, die Korrektheit eines Programms nachzuweisen, sondern Fehler zu erkennen. Dies bedeutet insbesondere, dass die «typischen» Fälle nur eine kleine Untermenge aller Testfälle bilden. Es ist vielmehr systematisch der gesamte Anwendungsbereich abzudecken. Dadurch kann es auch möglich sein, Spezifikationsprobleme zu erkennen, wie z.B. Fälle, die eigentlich im Modell abgebildet werden können sollten, aber durch die Definition der Systemgrenzen hinausfallen, oder zusätzliche Kontextelemente, die für korrekte Ergebnisse zusätzlich zu modellieren sind.
  
  
• Integration von Implementierung und Tests: Tests sollen vor bzw. während der Implementierung der Funktionalität erstellt werden und nicht erst nach deren Abschluss. Dies ermöglicht eine frühe Prüfung und stellt sicher, dass Tests auch tatsächlich vorhanden sind. Umso früher ein Fehler gefunden wird, desto einfacher, billiger, und schneller kann er behoben werden. Bei juristischen Modellen bedeutet dies, schon vor der Implementation (ideal: während des Entwurfs) konkrete Beispielsfälle oder -probleme inkl. ihrer Lösung zu bilden. Durch die gleichzeitige Erstellung wird weiters besser gewährleistet, dass für jeden Teil des Modells entsprechende Tests existieren (--> Systematisierung). Denn nachträgliche Erstellung führt sehr leicht dazu, dass manche Teile mehrfach überdeckt oder übersehen werden.
  
  
• Funktionale vs. Nichtfunktionale Tests: Bei funktionalen Tests wird geprüft, ob das Modell die gewünschten Ergebnisse liefert (-->Was). Nichtfunktionale Tests sollen hingegen feststellen, ob sonstige Eigenschaften (typ. unabhängig von bestimmten Funktionen oder Benutzerinteraktionen) den Anforderungen entsprechen. Hierzu gehören u.A. Wartbarkeit, Sicherheit und Skalierbarkeit. Auf diese Aspekte wird hier nicht näher eingegangen.
  

Einige Beispiele für konkrete Testmethoden aus der Informatik und ihrer Übertragung in den juristischen Bereich sind:

• Unstetigkeitsstellen-Test: Dies beinhaltet insbesondere Randbereiche bzw. Unstetigkeitsstellen: Im Rahmen der Informatik typischerweise die Verwendung von Eingabewerten, die 1 unter, exakt auf, bzw. 1 über dem Rand des gültigen Bereichs liegen. Bei juristischen Modellen entspricht dies Sachverhalten, welche gerade noch nicht bzw. gerade eben zu einer Verwirklichung des Tatbestandes führen, wo sich die Sanktion ändert (von Geld- auf Freiheitsstrafe), ab wann Auflagen für eine Genehmigung erforderlich werden etc.
  
  
• Fuzzing (auch «Affentest» genannt): Bei diesem Test wird konzeptionell ein Affe vor die Tastatur gesetzt, um beliebige Eingabe zu produzieren. Hiermit soll sichergestellt werden, dass ein Programm auch dann funktioniert (insb. nicht abstürzt), wenn die Eingabe fehlerhaft bzw. sinnlos ist. In der Praxis kommt hierzu allerdings das Testen von fast richtigen Eingaben: Diese sehen so aus als ob sie richtig und vollständig wären, besitzen jedoch einen kleinen Defekt. Diese Testmethode ist für juristische Modelle ganz besonders wichtig, da davon auszugehen ist, dass auch seltsame Sachverhalte und unvollständige oder schlechte Beschreibungen vorkommen werden. In all diesen Fällen muss das System «richtige» Antworten liefern, d.h. eine Lösung verweigern, die richtigen Zusatzinformationen anfordern, Warnhinweise ausgeben etc.
  
  
• Sicherheitstests: Überprüfungen gegen einen Missbrauch des Systems sind je nach Einsatzgebiet auszugestalten. Bei juristischen Modellen betrifft dies, neben den technischen Aspekten, das Ausnützen von Lücken in den Modellen, etwa um durch spezielle Wortwahl genau die gewünschte Formalisierung zu erreichen. Da im Sicherheitsbereich der Grundsatz gilt «Security by Obscurity doesn’t work» muss auch im juristischen Berech damit gerechnet werden, dass das gesamte Modell detailliert offengelegt ist, bzw. irgendwann bekannt wird. «Abkürzungen» oder (meist aber nicht immer gültige) Verallgemeinerungen zur Reduktion des Aufwands oder der Komplexität sind daher auf Dauer nicht geheimzuhalten.
  
  
• Assertions: In Programmcode werden vielfach sogenannte «Assertions» eingefügt. Dies sind Befehle die überprüfen, ob Parameter, Werte oder Zustände sich in einem korrekten Bereich befinden, und gegebenenfalls an genau dieser Stelle einen definierten Fehler auslösen, anstatt irgendwann/-wo später, bzw. ein falsches Ergebnis zu produzieren. Hiermit wird auch dokumentiert, welche Werte als «korrekt» angesehen werden. Diese Idee lässt sich auf juristische Modelle übertragen. Ein Schritt in diese Richtung sind Ontologien mit zusätzlichen Regeln, z.B. zur Prüfung ob ein Sachverhalt/eine Rechtsfolge möglich oder sinnvoll sind. Dies bedeutet, Regeln zu modellieren, welche zwar keine Auswirkung auf das Ergebnis besitzen, jedoch bei Problemen zu einer Modell-Inkonsistenz und einer Fehlermeldung als Ausgabe führen.

Im Bereich der Validierung ist Automatisierung schwerer zu erreichen, aber Systematisierung dennoch sehr wichtig. Beispiele für aus dem Informatik-Bereich übertragbare Vorgehensweisen hierzu sind:

• Reviews: Es wird immer wieder gegenüber der Realität bzw. «echten» Fällen überprüft, ob das Modell diese sowohl abbilden wie auch korrekt lösen kann. Es sollten nicht nur «typische» Fälle herangezogen werden sondern eine größere Anzahl, die möglichst den gesamten Nutzungsbereich abdeckt. Darüber hinaus kann es auch sinnvoll sein, nicht zu lösende Fälle zu integrieren: Diese müssen entsprechend erkannt werden bzw. dürfen ausschließlich in jenen Punkten Probleme bereiten, welche als außerhalb des Systems liegend bestimmt wurden (aber dort bei allen).
  
  
• Inkrementelle Entwicklung: Es werden zuerst kleine Teile modelliert, welche einen Teil der Fälle (u.U. bereits vollständig/korrekt) lösen können. Diese werden dann überprüft, bevor im nächsten Schritt weitere Elemente modelliert werden, um zusätzliche Fälle lösen zu können. Potentiell problematisch ist, dass im Zuge der Erweiterung ev. bereits vorhandene Teile adaptiert werden müssen. Es ist also ein grober – und laufend zu verfeinernder – Plan sehr wohl vonnöten. Lediglich die Detailumsetzung erfolgt in Zyklen, jeweils nach einer Planungs- und vor einer Testphase.
  

Eine Möglichkeit, Kontextabhängigkeiten durch Testen zu identifizieren, ist Testfälle aus der Realität zu entnehmen, z.B. Gerichtsentscheidungen. Bei deren händischer Musterlösung ist exakt mitzuschreiben, welche Vorschriften und Überlegungen miteinbezogen werden. Dies betrifft insbesondere auch solche, welche dann als im konkreten Fall ohne Auswirkung ignoriert werden. Anschließend ist zu überprüfen, ob alle diese Elemente auch tatsächlich modelliert sowie in den Deduktionsregeln berücksichtigt werden.

Hinsichtlich der Zeitabhängigkeit ist in gewissem Umfang automatisiertes Testen durch Fuzzing möglich: So können etwa zufällige Fälle generiert (oder echte zufällig abgeändert) werden, indem die Zeitaspekte modifiziert werden. Anschließend ist zu prüfen, ob das Modell das richtige Ergebnis bzw. eine entsprechende Warnung erzeugt.

Diese beiden Probleme sind durch Testen schwierig zu erkennen bzw. beheben, da Probleme schon einen Spezifikationsfehler darstellen: Das Modell wurde korrekt implementiert, aber es löst nicht notwendigerweise das anstehende Problem. Als besonders vielversprechend erscheint daher der Ansatz der inkrementellen Entwicklung, da durch kontinuierliches Feedback Fehler früher erkannt werden. Im Hinblick auf Ontologien ist dies ein besonders passendes Modell, da mit «groben» Kategorisierungen begonnen werden kann, welche später immer weiter verfeinert werden können. Im Zusammenhang mit den Deduktionsregeln ist freilich darauf zu achten, dass diese u.U. ebenfalls «mitgezogen» werden müssen: Während in der ersten Stufe eine «Kopie» noch zu einer «Urheberrechtsverletzung» führt, ist bei einer Verfeinerung durch Einführung einer «Privatkopie» diese allgemeine Regel nicht mehr gültig und muss ebenso angepasst werden (vergleiche Abschnitt 3.4. !). Es ist daher bei jeder weiteren Unterteilung oder Zusammenfassung zu überprüfen, ob alle hiervon betroffenen Regeln (( Abhängigkeitsgraph; kann automatisiert erstellt werden) weiterhin gültig sind oder ebenfalls angepasst werden müssen. Dies gilt gleichfalls für die Rücktransformation. Das gleiche Vorgehen muss bei späteren Erweiterungen der Modells oder dessen Aktualisierungen erfolgen.

Zusätzlich zur bereits oben erläuterten Testmethode sind noch weitere Strategien möglich, dieses Problem zu bekämpfen. Eine Möglichkeit ist eine Vollständigkeitsprüfung: Ist es für jede Klasse möglich, einen sinnvollen Fall zu konstruieren der diese enthält? Wenn nicht handelt es sich um eine schlechte oder unnütze Zerlegung. Dies bedeutet u.A. dass für jede Klasse eine Deduktionsregel existiert, welche diese als Eingang verwendet. Eine stärkere Untergliederung als erforderlich kann zwar dem Verständnis dienen, ist aber in dieser Hinsicht sehr gefährlich.

Ein weiterer Ansatz zur Problemreduktion ist, bei jeder Spezialisierung eine zusätzliche Klasse für den «Rest» zu bilden, der nicht durch die anderen Spezialisierungen abgedeckt wird. Anschließend ist festzustellen, ob diese Restklasse auch tatsächlich in dem Sinne «leer» ist, dass keine entsprechenden realen Sachverhalte für diese existieren. Wenn nicht, dann muss sie einen sinnvollen Namen erhalten und Eingang für eine Deduktionsregeln werden (selbst wenn es sich nur um die Feststellung handelt, dass derartige Fälle nicht bearbeitet werden).

Eine Möglichkeit ist hier wiederum die Generierung zufälliger Eingabefälle, um auf das korrekte Ergebnis zu überprüfen. Eine weitere Option besteht darin, die Rücktransformation umzukehren, d.h. das manuell erreichte Ergebnis über eine Umkehrung der Rücktransformation auf die Modellebene abzubilden. Hierdurch kann der Einfluss der Rücktransformation beim Testen ausgeschaltet werden und es kann das errechnete Ergebnis leichter mit dem auf manuellem Wege erreichten verglichen werden.

Hinsichtlich einer möglichst vollständigen Abdeckung durch systematisches Testen können folgende Grundregeln als Ansatzpunkte dienen:

• Jede Folgerungsregel muss mindestens einmal erfolgreich durchlaufen werden können. Damit wird sichergestellt, dass keine überflüssigen bzw. nicht-erreichbaren Regeln existieren: Zumindest in einem möglichen Fall wird das Ergebnis durch die Regel beeinflusst.
  
  
• Jede Folgerungsregeln muss mindestens einmal nicht-erfolgreich durchlaufen werden. Dadurch wird garantiert, dass es sich tatsächlich um Regeln und nicht um Axiome handelt, d.h. die Regel ist nicht notwendigerweise durch ihre bloße Existenz bzw. Anwendbarkeit erfüllt.
  
  
• Für jedes Eingangselement einer Regel muss ein realer und sinnvoller Fall existieren, sodass dieses Element vorliegt bzw. auszuschließen ist. Können zwei solche Fälle nicht konstruiert werden, so sind die Transformation (Korrektheit) bzw. die Deduktionsregeln (Notwendigkeit) zu überprüfen.
  
  
• Jedes Ausgangselement einer Regel muss Eingangselement einer weiteren Regel oder über eine Rücktransformation Teil einer semantisch korrekten Lösung sein. Ansonsten würde das Modell sinnlose Ergebnisse produzieren, was kaum intendiert sein wird. Dies schließt nicht aus, dass in manchen Fällen Ergebnisse nicht benötigt werden, sondern garantiert lediglich, dass dies zumindest möglich ist. Je nach Implementierung ist hier eine Ausnahme für Assertions (siehe oben) vorzusehen, welche lediglich der Konsistenzprüfung dienen und keine Eingabe für weitere Regeln erzeugen.

Es ist zu dieser Systematik anzumerken, dass sie keine Garantie auf Vollständigkeit der Überprüfung bzw. Übereinstimmung von Realität und Deduktionsregeln gibt: Dies ist je nach Modell u.U. gar nicht möglich bzw. meistens zu aufwändig. Es wird damit jedoch sichergestellt, dass zumindest keine groben Fehler der Abbildung der Semantik auf die Syntax existieren.

Testmethoden der Informatik für Computerprogramme können auch für die Verifizierung bzw. Validierung von Modellen nutzbar gemacht werden. Besonders im juristischen Bereich scheint dies ein noch wenig entwickelter Aspekt zu sein. Gerade im Hinblick auf die inhärenten Wartungsprobleme aufgrund von sich ändernder Gesetzeslage oder der laufenden Erweiterungen von Textkorpora ist dies jedoch ein wichtiges Problem, das größere Aufmerksamkeit verdient, sollen Projekte nicht im Forschungsstadium bzw. einmaligen Versuchen steckenbleiben sondern einer dauerhaften praktischen Nutzung dienen. Dieser Aufsatz soll als Denkanstoß dienen und einige grundlegende Aspekte darstellen, wie sich Techniken aus einem Wissenschaftsgebiet bei entsprechender Adaption auch auf andere Fachgebiete übertragen lassen. Gerade Prof. Schweighofer hat sich mit derartigen Modellen – insbesondere in der Form von Ontologien – beschäftigt und um solche Interdisziplinarität verdient gemacht.

[Schweighofer 1999a]Schweighofer, Erich : Wissensrepräsentation in Information Retrieval Systemen am Beispiel des EU Rechts. Wien: Wiener Universitätsverlag 1999
[Schweighofer 1999b]Schweighofer, Erich : The Revolution in Legal Information Retrieval or: The Empire Strikes Back, The Journal of Information, Law and Technology (JILT). 1999 (1)www2.warwick.ac.uk/fac/soc/law/elj/jilt/1999_1/schweighofer/ (4. Mai 2010)
[Schweighofer 2000]Schweighofer, Erich : Wer reguliert das Internet? MR 2000, 347
[Schweighofer 2002]Schweighofer, Erich : Von der Wissensrepräsentation zum Wissensmanagement im eGovernment. In: Schweighofer, Erich, Menzel, Thomas, Kreuzbauer, Günther (Hrsg.): IT in Recht und Staat. Wien: Verlag Österreich 2002
[Schweighofer 2003]Schweighofer, Erich : Wege zum elektronischen CELEX-Kommentar. In: Schweighofer, Erich, Menzel, Thomas, Kreuzbauer, Günther, Liebwald, Doris (Hrsg.): Zwischen Rechtstheorie und e-Government. Wien: Verlag Österreich 2003
[Schweighofer 2004]Schweighofer, Erich, Liebwald, Doris : Konzeption einer Ontologie der österreichischen Rechtsordnung. In: Schweighofer, Erich, Liebwald, Doris, Kreuzbauer, Günther, Menzel, Thomas (Hrsg.): Informationstechnik in der juristischen Realität. Wien: Verlag Österreich 2004
[Schweighofer 2005a]Schweighofer, Erich, Liebwald, Doris : Projekt LOIS: Juristische Ontologien und Thesauri. In: Schweighofer, Erich, Liebwald, Doris, Augeneder, Silvia, Menzel, Thomas (Hrsg.): Effizienz von e-Lösungen in Staat und Gesellschaft. Stuttgart: Boorberg 2005
[Schweighofer 2005b]Schweighofer, Erich, Liebwald, Doris : Advanced Lexical Ontologies and Hybrid Knowledge Based Systems: First Steps to a Dynamic Legal Electronic Commentary. In: Lehmann, Jos, Biasiotti, Maria Angela, Francesconi, Enrico, Sagri, Maria Teresa (Hrsg.): LOAIT – Legal Ontologies and Artificial Intelligence Techniques. Nijmegen: Wolf 2005
[Schweighofer 2006]Schweighofer, Erich : EUR-Lex: Schwerpunkt Text- oder Contentdokumentation? In: Schweighofer, Erich, Liebwald, Doris, Drachsler, Mathias, Geist, Anton (Hrsg.): e-Staat und e-Wirtschaft aus rechtlicher Sicht. Stuttgart: Boorberg 2006
[Schweighofer 2007]Schweighofer, Erich : «Intelligent Reader» statt «Intelligent Reasoner» – Fortgeschrittenes Information Retrieval oder künstliche Intelligenz im Recht? In: Schweighofer, Erich, Geist, Anton, Heindl, Gisela (Hrsg.): 10 Jahre IRIS: Bilanz und Ausblick. Stuttgart: Boorberg 2007
[Schweighofer 2010]Schweighofer, Erich : Die Rechtswissenschaften im globalen Dorf und die Rolle der Rechtsinformatik. In: Schweighofer, Erich, Geist, Anton, Staufer, Ines (Hrsg.): Globale Sicherheit und proaktiver Staat – Die Rolle der Rechtsinformatik. Wien: OCG 2010

---

Michael Sonntag,Institut für Informationsverarbeitung und Mikroprozessortechnik (FIM), Johannes Kepler Universität Linz, Altenbergerstr. 69, A-4040 Linz,sonntag@fim.uni-linz.ac.at

---