Jusletter IT

Ist das klassische Internet noch von monolithischen Systemen mit dedizierten Betreiberinstanzen und zentraler Softwareentwicklung geprägt, deuten sich Tendenzen zu verteilten Lösungs- und Entwicklungsmechanismen an. Dies ist aus der zugrundeliegenden Transportinfrastruktur begründet, aber auch in beginnenden Infrastrukturen des Internet der Dienste¹ .

Das Internet der Dienste wird als umfassendes Ökosystem betrachtet, in dem Dienste² handelbar gemacht werden. Im Vordergrund steht dabei die Realisierung von Ad-hoc Wertschöpfungsketten im Internet, die wirtschaftlichen Wert generieren. Diese Verkettung kann in flexibler und spontaner Art und Weise geschehen. Neben neuen Herausforderungen an Geschäftsprozesse und -modelle, wirft dies auch juristische Schwierigkeiten auf.

Dem Internet der Dienste ist es immanent, dass der Einfluss einer steuernden Instanz zugunsten selbstorganisatorischer Aspekte zurückgedrängt wird. Damit löst sich die Vorstellung vom «steuernden Entwickler»³ auf bzw. muss durch Aspekte der Kooperation angereichert werden. Zudem scheidet unter dem neuen Paradigma aber auch die bislang in der Praxis geübte nachträgliche Einschaltung der Rechtsabteilung zur Detailprüfung einer komplexen Softwareimplementierung aus. Damit müssen die rechtlichen Aspekte bereits bei der Erstellung der Datenmodelle beachtet und in die technischen Systeme eingeschrieben werden.⁴ Im Ergebnis wird durch diese Entwicklung sowie den Trend zur Modularisierung und Kombination bestehender Implementierungen die Notwendigkeit eines formalen, technikgestützten Rahmens zur frühzeitigen Vermittlung von Gestaltungsanforderungen die sich aus rechtlichen Normen ergeben motiviert. Da von begrenzten Rechtskenntnissen der Dienstentwickler auszugehen ist, bietet sich eine technische Entscheidungsunterstützung für bestimmte, rechtlich geforderte Implementierungsmaßnahmen an.

Den Arbeiten liegt die Prämisse zugrunde, dass die automatisierte Ermittlung von Rechtsfolgen und mithin die Übertragung des durch den Juristen geleisteten Subsumtionsvorganges kein Problem der Logik, sondern der Semantik darstellt. Das hier vorgestellte System muss zur Übertragung des menschlichen Subsumtionsvorganges daher eine technische Repräsentation von Sachverhalt, gesetzlichen Normen und Mechanismen zur juristisch-methodischen Ermittlung von Begriffsbedeutung implementieren. Hier ist es wegen der sachlichen Nähe hinsichtlich der letztgenannten Anforderung indiziert, auf die Konzepte der Ontologiemodellierung zurückgreifen.⁵

Verwandte Arbeiten im ersten Bereich befassen sich mit der Abbildung der Regelhaftigkeit gesetzlicher Normen mithilfe formaler Logik. Arbeiten in diesem Bereich ist gemein, dass sie sich im Wesentlichen mit der Beschreibung der Rechtsdomäne und Regeln befassen, sich jedoch nicht mit der Anbindung an formalisierte Sachverhalte auseinandersetzen. Zu nennen sind bspw. die Arbeiten von Sator⁶ , welche sich in erster Linie mit der Beschreibung juristischer Normen in Logik beschäftigen. Hilfreich sind diese Arbeiten dahingehend, dass sie Hinweise auf die zur Transformation juristischer Normen benötigte Ausdrucksmächtigkeit der formalen Logik geben. Für die benutzte deontische Logik fehlen jedoch praktische Werkzeuge wie Editoren oder Inferenzmaschinen. Des Weiteren sind für die implementierungsfähige Umsetzung juristischer Normen als Regeln die frühen Arbeiten von Gordon interessant. Die dort verwendete Inferenzmaschine Oblog basiert, wie der in unseren Ansätzen verwendete Ontobroker, auf der logischen Programmierung. Auch wurden für den Umgang mit Ausnahmen einige interessante Vorgehensweisen erarbeitet. Dies mündete später in den Vorschlag nichtmonotoner Logiken.⁷ Ein weiterer Vertreter der logischen Programmierung für die Repräsentation logischer Regeln ist Kowalski⁸ . Eine andere Herangehensweise wurde in dem Projekt SESAM⁹ verfolgt. Dort wurde ein System entwickelt, das für die Abbildung von Regeln Business Rules¹⁰ verwendet. Dieses System ist zwar für bestimmte Beispiele von Normhierarchien geeignet, aber nur schwer generalisierbar.

Der zweite Bereich verwandter Arbeiten besteht aus Ontologien zur Darstellung juristischen Wissens und zur Sachverhaltsrepräsentation. Hierzu sind Ontologien bereits vielfach vorgeschlagen worden. So z.B. von Rubino u.a.¹¹ oder von van Breuker u.a.¹² im Rahmen der Workshopserie LOAIT¹³ . Einige der dort vorgestellten Beiträge sind hier interessant, da sie auch die Verwendung von Grundlagenontologien oder spezialisierter Entwurfsmustern¹⁴ zur Unterstützung des Ontologiebaus beinhalten. Beides findet auch im Rahmen des hier vorgestellten Ansatzes statt. Der Ansatz verfolgt jedoch auch das Ziel der automatisierten Subsumtion von Sachverhaltselementen unter Tatbestandsmerkmale des Gesetzes. Dies hat Rückwirkungen auf die verwendete Grundlagenontologie, die sich zur Unterstützung der Subsumtion mit der Sachverhaltsmodellierung verbinden lassen muss.

Verwandte Arbeiten im dritten Bereich verfolgen primär das Ziel der automatisierten Rechtsfolgenermittlung. Grundsätzlich kann dies auch nicht ohne eine hierfür geeignete Sachverhalts- oder zumindest Tatbestandsrepräsentation geschehen. Die Verwertbarkeit bestehender Ansätze für diesen Teil des hier vorgestellten Ansatzes ist besonders von der Perspektive des positiven d.h. kontinentaleuropäischen Rechts bestimmt. Arbeiten, die hinsichtlich der betrachteten Rechtsordnung eher auf die Common Law-Perspektive gerichtet sind, können nur sehr bedingt als relevant betrachtet werden.¹⁵ Des Weiteren scheiden Ansätze die sich zwar am positiven Recht ausrichten, aber von der juristischen Methodik der kontinentaleuropäischen Rechtsfolgenermittlung entfernen ebenfalls aus.¹⁶

Das vorgestellte Modell soll daher beim automatisierten Schließen den Umstand des neuen Paradigmas im Internet der Dienste nutzen, dass Dienste mit Hilfe der Unified Service Description Language (USDL)¹⁷ oder der Service-Ontologie¹⁸ beschrieben sind. Insofern muss die Ermittlung des Sachverhalts insbesondere in natürlich sprachlicher Form nicht betrachtet werden. Es wird stattdessen auf USDL oder die Service-Ontologie und weitere in der Produktivumgebung bereits vorliegende Informationen zurückgegriffen. Der Sachverhalt liegt also schon in strukturierter Form vor. Der Dienstentwickler pflegt hierzu bereits vorhandene Fakten über den zu erstellenden Dienst, seinen Einsatzzweck und seine Architektur in eine formale Beschreibung ein.

Um eine Unterstützung für das entscheidende Problem bei der Formalisierung von Rechtsnormen, die Modellierung und Auslegung von unscharfen Rechtsbegriffen, zu ermöglichen, muss das System juristisch-methodische Konzepte zur Auslegung implementieren und, soweit technisch möglich, zur Laufzeit die notwendigen Quellen zur Auslegung bereitstellen. Aus juristischer Perspektive ist dabei das methodische Konzept der Auslegung nach Larenz¹⁹ abzubilden.

Da es sich um ein lernfähiges System handelt, müssen dem menschlichen Akteur im Rahmen der Nutzung der Rechtsbegriffsontologie die notwendigen Informationen dann aufbereitet werden, wenn die Bedeutungsermittlung mit der vorhandenen Ontologie scheitert. Ausgangspunkt für die dann erforderliche Anreicherung der Ontologie ist zunächst der Wortlaut (z.B. durch die Integration von Allgemeinbegriffen aus Online-Wörterbüchern), es folgt die Historie durch Integration von durch Text Mining aufbereiteter Quellen, Systematik durch Auswertung der abweichenden anderweitig intendierten Bedeutung, und in der zusammenfassenden Gesamtschau der ggf. auch schon gesetzlich normierten Zweckfestlegung.

Die Basisarchitektur des Systems ist in Abbildung 1 dargestellt. Der Aufbau fußt zunächst auf drei Sprachräumen, von welchen zwei aus dem Kontext vorgegeben und der dritte Gegenstand des Entwurfs ist. Sie sind farblich unterschiedlich unterlegt und werden im Folgenden als Technisches Datenmodell, Natürliche Sprache und Juristisches Datenmodell bezeichnet.

Das technische Datenmodell ist das existierende Beschreibungskonzept der betrachteten Diensteinfrastruktur. Technisch sagt an dieser Stelle jedoch nicht, dass dieses nur technische Schemata zur Beschreibung von Diensten enthält. In der Tat waren der Ausgangspunkt für die Entwicklung dieses Modells rein technische Beschreibungen, wie sie bspw. die Web Service Description Language²⁰ standardisiert anbietet. Im Internet der Dienste werden diese durch ökonomische Aspekte ergänzt, welche mit Hilfe der bereits oben erwähnten USDL oder Service-Ontologie modelliert sind. Damit werden also z.B. Informationen über Zweck und Anbieter, Preisgestaltung, Nutzungsbedingungen und viele andere auch rechtlich relevante Details aufgenommen. Das Instanziieren dieser Beschreibungsschemata erfolgt parallel zum Entwurf und zur Entwicklung des Dienstes, so dass bekannte Fakten bereits frühestmöglich modelliert vorliegen (statischer Sachverhalt).²¹ Daneben treten Zustandsbeschreibungen, sog. Laufzeitinformationen, welche den aktuellen Zustand und das Verhalten des Dienstes beschreiben. Dieser Teil des technischen Datenmodells ist zur Entwurfszeit noch leer, denn der Dienst existiert noch nicht und kann daher noch keinen Zustand und keine Laufzeitparameter besitzen (simulierter Sachverhalt).

Der Dienstentwickler hinterlegt bereits direkt in der technischen Beschreibung so viele Informationen wie möglich, um Doppelarbeit zu vermeiden. Diese Informationen werden direkt aus der natürlichen Sprache des Entwicklers in das formale technische Datenmodell übertragen. Dazu sind für Entwickler von Diensten im Internet der Dienste bereits geeignete Werkzeuge vorhanden.²² Des Weiteren werden auch Ergebnisse der rechtlichen Begutachtung in der natürlicher Sprache wiedergegeben. Sie bildet damit die Grundlage für die gesamte Interaktion mit dem Entwickler.

Der dritte Sprachraum ist die ontologisch formalisierte abstrakte Begriffswelt des Gesetzgebers, welcher die Grundlage für die formalisierten gesetzlichen Normen bildet (Rechtsbegriffsontologie). Dieses juristische Datenmodell enthält unter Berücksichtigung ontologischer Qualitätskriterien, die gesetzgeberischen Beschreibungsschemata und Taxonomien für Tatbestände und Rechtsfolgen.

Die technischen Module des Gesamtsystems betreffen neben der eigentlichen Rechtsfolgenermittlung die Schnittstellen zwischen den einzelnen Sprachräumen. Kurz zusammengefasst werden technische Sachverhalte in das System zur Bildung vollständiger Obersätze übernommen, darauf formalisierte Rechtsnormen angewendet und die Rechtsfolge dem Entwickler in geeigneter Weise mitgeteilt, damit er fehlende Fakten ergänzen oder daraus erwachsende Anforderungen technisch umsetzen kann.

Die erste Schnittstelle zur Übernahme von technischen Sachverhalten in das Rechtsfolgenermittlungssystem wird im Schaubild als System zur Subsumtion im engeren Sinne bezeichnet und ermittelt aus den technischen Sachverhaltselementen Tatbestandsmerkmale, welche die Grundlage für die Regelabarbeitung der Rechtsfolgenermittlung darstellen.

Das System zur Bildung vollständiger Obersätze besteht aus dem logischen Inferenzsystem und dem Regelsatz, welcher die juristisch formalisierten gesetzlichen Regeln und notwendige definitorische Sätze enthält. Durch Anwendung der Regeln wird aufgrund der Tatbestandsmerkmale, welche auf der juristischen Datenmodellebene als Instanz vorliegen, ein Ergebnis abgeleitet. Ist die Faktengrundlage ausreichend, besteht dieses in einer oder mehreren Rechtsfolgen. Falls nicht besteht es aus Teilergebnissen, die sich aus der unzureichenden Faktenbasis ableiten lassen.

Der Wizard bildet die eigentliche Interaktionsschnittstelle zwischen Entwickler und Rechtsfolgenermittlungssystem. Er besteht aus zwei Komponenten. Das Erklärungssystem stellt die Schnittstelle zwischen der natürlichen Sprache und dem juristischen Datenmodell dar. Es erzeugt auf Basis der Regelabarbeitung eine natürlich sprachliche Beschreibung aller ermittelten Ergebnisse und visualisiert die zugehörigen Normgraphen²³. Anhand dieser kann der Entwickler ggf. erkennen, an welcher Stelle fehlende technische Fakten zu einer Nichtableitbarkeit einer bestimmten Rechtsfolge geführt haben. Sofern es sich um zur Entwicklungszeit stets fehlende Laufzeitinformation handelt, kann er den integriertenLaufzeitdateneditor nutzen, um einen Systemzustand zu simulieren. Der Wizard unterstützt bei der Eingabe der Daten dergestalt, dass er sie in laienverständlicher Weise abfragt. Sofern es sich um einenstatischen Sachverhalt handelt, nutzt der Entwickler den außerhalb des Systems vorhandenenService Description Editor.

Der Referenzimplementierung dieser Architektur liegt das Bundesdatenschutzgesetz (BDSG) zugrunde. Die ontologische Modellierung der gesetzgeberischen Begriffswelt des BDSG (juristisches Datenmodell) wurde zunächst in OWL²⁴ entwickelt und anschließend die Taxonomie in F-Logic²⁵ übernommen und iterativ unter Berücksichtigung ontologischer Qualitätskriterien Inkonsistenzen beseitigt sowie das Modell verfeinert.

Die Evaluierung anhand des eingangs beschriebenen Anforderungskanons führte hinsichtlich der Modellierungssprache und des Formalismus zu einer Auswahlentscheidung zugunsten F-Logic:

• F-Logic stellt als Basis eine hinreichend flexible Modellierungssprache dar, die geeignet ist, das juristische Begriffsmodell abzubilden und auch darin enthaltene taxonomische Beziehungen zu berücksichtigen.
• Des Weiteren ist es weitgehend regelbasiert, was im Vergleich zu den abzubildenden juristischen Normen eine gewisse Nähe darstellt. Unter der Voraussetzung eines hinreichenden begrifflichen Modells lassen sich juristische Normen vielfach direkt in
  F-Logic Regeln übertragen.
• Sodann verfügt F-Logic in Ontobroker²⁶ über eine technisch ausgereifte und implementierte Inferenzmaschine. Es werden mehrere Auswertungsstrategien und -kalküle unterstützt womit die Eignung zur Ermittlung von einzelnen Rechtsfolgen (Top-Down), wie auch zur Ermittlung aller Rechtsfolgen aus einem geg. Sachverhalt (Bottom-Up) gegeben ist.
• Schließlich verfügt F-Logic mit dem NeOn Toolkit²⁷ über eine frei verfügbare und mit grafischen Modellierungshilfen versehene Entwicklungsumgebung, die sowohl die Erstellung des juristischen Datenmodells als auch die Regelgenerierung ermöglicht.

Der vorgestellte Ansatz eines Systems zur automatisierten Rechtsfolgenermittlung nutzt die Vorteile des neuen Paradigmas des Internet der Dienste um die inhärenten Nachteile einer verteilten und kombinatorischen Architektur im Hinblick auf Rechtskonformität zu kompensieren. Gleichzeitig liefert der Ansatz eine Referenzarchitektur zur Formalisierung des Rechts, welche derzeit auf die spezifischen Anforderungen elektronischer Vertragsschlüsse unter Verwendung formal beschriebener AGB-Klauselsets²⁸ und eines Lizenzmanagements²⁹ fortentwickelt wird.

Oliver Raabe, Richard Wacker, Christian Funk, Karlsruher Institut für Technologie (KIT), Institut für Informations- und Wirtschaftsrecht (IIWR)
Forschungsgruppe Energieinformationsrecht und Rechtsinformatik
Vincenz-Prießnitz-Str. 3, 76131 Karlsruhe DE, http://compliance.zar.kit.edu
Forschungsgruppenleiter, Senior Researcher,raabe@kit.edu; Dissertant, richard.wacker@kit.edu;
Richter auf Probe, Sächsische Justiz, cfunk@ira.uka.de;

Daniel Oberle, Christian Baumann, SAP Research Center Karlsruhe, SAP AG, Vincenz-Prießnitz-Str. 1, 76131 Karlsruhe DE, http://www.sap.com/research
Senior Researcher, d.oberle@sap.com; Dissertant, ch.baumann@sap.com