Jusletter IT

Der iPad und das iPhone scheinen unser Leben und die Art, wie wir mit dem Computer umgehen, zu verändern. Software und Endgeräte haben einen nie dagewesenen Grad an Mobilität und Nutzerfreundlichkeit erreicht. Der Computer wird zu einem alltäglichen Arbeitsmittel und erobert im Sturm die Aktentaschen auch der älteren Generationen. Apps bieten Lösungen für fast jedes Problem. Ein Ergebnis dieses Hypes könnte auch die eine oder andere Spezial-App für den juristischen Gebrauch sein. Denkbar sind hier viele Anwendungen, denn die eigentliche anwaltliche oder richterliche Tätigkeit wird bisher noch kaum unterstützt.

Die Ideen sind nicht neu. Ich gebe zu, ich greife im Folgenden auf Arbeiten zurück, die ich bereits in den frühen 90er Jahren des letzten Jahrhunderts gemacht habe. Damals befand sich die Rechtsinformatik wohl eher in einer Krise und erholte sich von den überzogenen Erwartungen der 70er und 80er Jahre. Der Ruf nach Bodenständigkeit wurde laut. In dieser Zeit habe ich mich nicht nur mit dem Einsatz von Tabletts am juristischen Arbeitsplatz beschäftigt¹ sondern auch intensiv die Integration kleiner spezialisierter Anwendungen in den Arbeitsprozess des juristischen Praktikers betrachtet². Viele der damaligen Ergebnisse haben heute noch Bestand. Die technische Realisierung bedarf freilich einer Überarbeitung.

Gehen wir einmal davon aus, dass es sinnvoll ist, den juristischen Arbeitsablauf durch einzelne Apps punktuell zu unterstützen. Beispiele:

• In sehr formalisierten Verfahrensarten (z.B. Familienrecht) kann bereits der Mandant auf seinem Tablet-Computer entsprechende Formulare ausfüllen.
• In komplexen Verfahren verwendet der Anwalt eine strukturierte Graphiksoftware, um Personen und Zusammenhänge für sich zu ordnen oder für den Mandanten zu visualisieren. Zeitliche Entwicklungen werden ebenfalls graphisch abrufbar.
• Beim Lokaltermin oder gar unmittelbar bei einem Unfall dient der Computer samt eingebauter Kamera zur Aufnahme und Protokollierung des Sachverhalts.
• Im Bauprozess werden Baupläne und Schadenspositionen interaktiv zugänglich gemacht.
• Die Kamera kann auch ideal verwendet werden, um Dokumente zu scannen (fotografieren) und direkt zu einer Akte zu legen.
• Beim Anruf eines Mandanten liefert eine App den aktuellen Sach- und Streitstand inklusive der entsprechenden Dokumente und Beweise.
• Mit einem Dokumentengenerator können ohne großen Schreibaufwand Verträge formuliert und überarbeitet werden.
• Schließlich können mit dem Gerät relevante Dokumente recherchiert und zu einer Akte gelegt werden.

Das sind nur einige Beispiele, wie sich die Rechtsanwendung insbesondere aber die Sammlung der Fakten in einer Rechtssache durch Apps unterstützen ließe. Das Risiko einzelner Apps ist nun, dass diese die Daten nicht brauchbar untereinander austauschen können. Die Folge wäre, dass Daten redundant eingegeben, gepflegt und abgerufen werden müssten. Damit wären die Systeme aber kaum alltagstauglich. Es bedarf also eines konsensfähigen Ablageschemas und einer entsprechenden Schnittstelle, damit die Daten für alle Apps zugreifbar werden und ein Optimum an Nutzen bietet.

Ich spare mir hier die wissenschaftliche Diskussion unterschiedlicher möglicher Lösungsansätze ebenso wie die Unterbreitung rechtstheoretischer Grundlagen. Dennoch mag es zunächst interessant sein, warum die Frage einer Datenschnittstelle im juristischen einer ganz eigenen Behandlung bedarf.

Der Jurist maßt sich an, über jeden Sachverhalt urteilen zu können. Das setzt voraus, dass er jeden Sachverhalt in die vom Gesetz vorgesehenen Informationseinheiten zerlegen kann und dann das Gesetz darauf anwendet. Man ist geneigt, diese Einzelinformationen als Fakten zu bezeichnen. Die Menge an zu erfassenden Fakten, die für eine Entscheidung benötigt wird, ist ungleich größer und deutlich granularer, als es in klassischen Datenablagesystemen, etwa einer Adressenverwaltung üblich ist. Jeder noch so kleine Teil eines Sachverhalts kann für die Rechtsanwendung von Bedeutung sein und sollte entsprechend zugreifbar sein. Das strukturelle Grundgerüst bieten dabei Zehntausende von einzelnen Vorschriften und Millionen von Entscheidungen und anderen kasuistischen Regeln. Sie definieren, welche Sachverhaltsmerkmale (Fakten) relevant sind.

Nun gibt es feststehende Fakten in der juristischen Praxis gar nicht. Zum einen ändert sich die Realität im Laufe der Zeit, beispielsweise Ändern sich Adressen, Sachen werden zerstört oder verändert, Verträge gekündigt etc. (Parallel hierzu unterliegt übrigens auch das Regelwerk stetiger Veränderung.) Zum anderen sind Fakten immer nur das Ergebnis von Behauptungen einzelner Personen. Somit werden sie nach belieben der Beteiligten gänzlich oder teilweise unterschiedlich dargestellt. Das ergibt je nach Betrachtung ein ganz unterschiedliches Bild der Wirklichkeit. Genau dieses Bild kann sich dann noch durch sich ändernde Behauptungen auch derselben Quelle über die Zeit hin nochmals verändern. Dieses bewegliche Ziel einer Sachverhaltsdarstellung einzufrieren, um eine Entscheidungsbasis zu definieren, ist oft der wichtigste Teil der juristischen Tätigkeit. Die Anwendung der Regeln ist hingegen in vielen Fällen einfaches Handwerk.

Während klassisch Datenablagesysteme mit einer zeitlichen Veränderung der Wirklichkeit noch gut klar kommen (klassische Versionsverwaltung),  muss eine juristisches Ablagesystem den Faktenbegriff gänzlich vergessen und letztlich Behauptungen verwalten, die je nach Quelle und Zeitpunkt ihrer Abgabe ein unterschiedliches Bild der Wirklichkeit ergeben können. Zu den Behauptungen müssen ausreichende Beweismittel hinterlegt werden, die eine Behauptung stützen. Genau diese Varianz der Sichten und der Beweislage ist relevant, will man sich in Apps einer der wesentlichen praktischen Tätigkeit des Juristen widmen, nämlich der Erfassung des Sach- und Streitstandes.

(Ein ideales System könnte womöglich noch Beweislastregeln anwenden und so die aktuell relevante Sicht darstellen. Hierzu müsste es aber ein vollständiges System an Rechtsregeln verwalten.)

Klammern wir zunächst die juristische Unschärfe der Behauptung aus und betrachten den Zugriff auf Fakten. Moderne Systeme stellen die Wirklichkeit als eine Menge von (klassifizierten) Objekten dar, die bestimmte Eigenschaften haben und zueinander in Beziehungen stehen.

Beispiel Kaufvertrag: Hier haben wir auf den ersten Blick fünf Objekte, nämlich den Vertrag, Käufer und Verkäufer, den Kaufgegenstand und den Preis. Die letzten vier stehen jeweils mit dem Vertrag in der entsprechenden Beziehung.

Beispiel Klageverfahren: Hier haben wir beispielsweise die Objekte Klage, den Kläger, den Beklagten, die Prozessvertreter, das Gericht etc.

Beispiel Adresse: Eine Person ist ein Objekt, sie steht ein Beziehung etwa zum Objekt ihrer Adresse, das Sie sich aber auch mit anderen Personen teilen kann. Auch Telefonanschlüsse können als eigene Objekte betrachtet werden. Namen sind einfache Eigenschaften einer Person. Der Titel hingegen wäre spätestens dann ein Objekt, wenn er selbst zum Streitgegenstand wird...

Fakten in dieser Betrachtung sind damit die Eigenschaften von Objekten sowie die Beziehungen der Objekte untereinander. Auch die Frage, ob ein Objekt also - beispielsweise ein Vertrag - überhaupt existiert, ist ein Faktum.

Betrachten wir eine Anwendung, die ein einfaches Aktenblatt anzeigt. Sie benötigt u.a. Stammdaten der Beteiligten an einer Klage, also des Klägers, des Beklagten, der Prozessbevollmächtigten etc. Eine Anwendung, die einen Sachverhalt darstellt greift beispielsweise auf Käufer und Verkäufer eines Kaufvertrags zu. Dabei können Käufer und Kläger identisch sein. Die Erste App findet also über den Weg der Klage und die Rolle des Klägers zu einer Person (und den damit verknüpften Stammdaten) und die zweite über den Kaufvertrag und die Rolle des Käufers. Jede App verwendet also einen anderen Weg zu demselben Objekt.

Für die Beschreibung solcher Pfade greifen wir auf XPath zurück, eine sehr mächtige Sprache im Umfeld von XML. Sie dient der Bestimmung von einem oder mehreren Knoten in einem hierarchischen Baum. Die Sprache wird vom W3C unter http://www.w3.org/TR/xpath/ definiert. Einen kurzen Überblick bietet auch Wikipedia.³

Die Suche nach dem Käufer eines Kaufvertrags könnte in XPath Kaufvertrag/Käufer beschrieben werden. Dieser Ausdruck beschreibt den Pfad zu einem Objekt, das zum aktuellen Kontext in der Beziehung Kaufvertrag steht und einem weiteren Objekt oder Wert mit der Beziehung Käufer. Möchte man einen Bestandteil einer Adresse abrufen, lässt sich der Pfad erweitern auf  Kaufvertrag/Käufer/Adresse/Ort. (Wir differenzieren hier nicht zwischen der Beziehung Kläger und der Eigenschaft Ort. Die in XML denkbare Differenzierung zwischen Elementen und Attributen ignorieren wir an dieser Stelle.)

XPath geht immer von einem aktuellen Kontext aus, von dem der Pfad beschritten wird. Diesen Kontext kann man allerdings auflösen. Mit  //Käufer werden beispielsweise alle Käufer gesucht, d.h. alle Objekte, die zu einem anderen Objekt in der Beziehung Käufer stehen.

XML und damit XPath beschreiben einen Baum mit klaren hierarchischen Strukturen. Sie erwarten damit - wenigstens bisher - einen definierten Ausgangspunkt, das Root-Element. Von hieraus zeigt der Pfad in eine Richtung, vom Eltern-Objekt zum Kind-Objekt, es sei denn die Richtung wird durch entsprechende Zeiger geändert.

Insofern wird XPath hier zweckentfremdet, denn die Daten eines juristischen Falles sind eher in Form eines nicht-hierarchischen Netzes aufgebaut. Auf die Definition eines Ausgangspunkts soll deshalb genauso verzichten werden, wie auf eine definierte Richtung. Stattdessen wird auf die Gesamtheit der Daten immer mittels  // zugegriffen. und  / zeigt auch wieder zurück. Der Ausdruck Kaufvertrag/Käufer könnte also ausgehend vom Käufer auch wieder auf sich selbst zeigen.

Prinzipiell sind in jedem Vertrag auch mehrere Parteien denkbar. In XPath erhält man dann eine Liste mit mehreren Objekten oder Werten. Zur Einschränkung dienen Prädikate. Kaufvertrag[1]/Käufer[1]/Adresse/Ort sucht die Adresse des ersten Käufers im ersten Verfahren. Um mehrere Käufer abarbeiten zu können, kann die Anzahl der verfügbaren Käufer abgerufen werden: count(Kaufvertrag/Käufer). Mit dieser Information kann ein Programm alle Käufer in einer Schleife iterativ abrufen: (Kaufvertrag/Käufer)[x].

Prädikate können allerdings auch komplexere Filter enthalten. Der Ausdruck //Kaufvertrag[count(Käufer) > 1] sucht beispielsweise nach allen Kaufverträgen mit mehr als einem Käufer.

Fakten im juristischen Sinne sind zunächst Behauptungen bzw. Aussagen einer Person zu einem bestimmten Zeitpunkt. Die Behauptungen manifestieren sich in Schriftsätzen, Protokollen, mdl. Aussagen etc. Zu den Behauptungen gibt es in den entsprechenden Aussagen ggf. auch Beweisangebote bzw. Beweise. Die Dokumente, abstrakte Aussagen, deren Urheber aber auch die Beweismittel sind Objekte. Sie stehen in definierten Beziehungen zueinander bzw. haben definierte Eigenschaften.

Für die Bezeichnung dieser Beziehungen und Eigenschaften wählen wir einen (in XML typischen) eigenen Namensraum (jx), um Konflikte mit den fachlichen Namen zu vermeiden. Daraus ergeben sich definierte Namen: jx:quelle bezeichnet den Schriftsatz, das Protokoll oder die Aussage. jx:urheber bezeichnet den Autor der Quelle, jx:datum das Datum der Quelle. jx:beweis und jx:beweisangebot dienen der Verbindung einer Aussage mit einem Beweis.

Beispiel: //Kaufvertrag/Kaufpreis/Höhe[(jx:quelle/jx:urheber in //Kläger) and (jx:quelle > 31.01.2012)] sucht nach allen Aussagen zum Kaufpreis eines Klägers nach dem 31.01.2012.

Beispiel: //Kaufvertrag/Kaufpreis/Höhe[1]/jx:beweisangebot sucht nach Beweisangeboten für die erste Angabe zur Höhe des Kaufpreises.

Damit ist eine nahezu umfassende Beschreibungen von Aussagen bzw. Fakten möglich.

Die Implementierung einer Schnittstelle wirft natürlich weitere praktische Fragen auf.

Die Definition einer Sprache, also einer Syntax ist zwar ein erster Schritt bei der Schaffung einer Schnittstelle, aber de facto der weniger schwierige. Deutlich komplexer sind der semantische Teil, also die Definition der einzelnen Beziehungsklassen und Eigenschaften, und die damit verbundene Beschreibung ihrer Bedeutung. Hier tauchen wir tief in rechtsphilosophische Grundfragen ein.

Ein Patentrezept für die Bildung solche Begriffsräume gibt es sicher nicht. Man wird eine generelle Definition und einige Grundregeln in einer kleinen Arbeitsgruppe zusammenstellen und für einzelne Rechtsgebiete bzw. Anwendungsszenarien ebenfalls Arbeitsgruppen bilden. Zur Homogenisierung bedarf es einer Kontrollinstanz. Grundsätzlich gilt natürlich: Je weniger beteiligte desto schneller erhält man Ergebnisse.

Die Möglichkeit von Namensräumen haben wir uns bereits oben zunutze gemacht. Dabei handelt es sich um eindeutige Präfixe, die dem Namen etwa einer Beziehung vorangestellt werden. Damit kommen sich identische Namen mit unterschiedlicher Semantik nicht in die Quere. Die Eindeutigkeit wird über URLs erreicht. App und Schnittstelle einigen sich zunächst, welches Präfix sie für welche URL einsetzen. Bei einem vordefinierten oder voreingestellten Namensraum kann das Präfix auch ganz entfallen.

Namensräume können vielfach eingesetzt werden. Etwa können Hersteller von Apps sie nutzen, um anwendungsspezifische Informationen abzulegen. Eine App für Fallskizzen würde so beispielsweise die Koordinaten von Objekten speichern, die sicherlich keinerlei juristische Bedeutung haben. Man kann sich allerdings auch vorstellen, dass spezialisierte Arbeitsgruppen in einem eigenen Namensraum alternative Definitionen festlegen.

Auf diese Weise ist es möglich, alle Daten in einem System abzulegen, ohne auf optimale Spezialisierung verzichten zu müssen.

Technisch ist eine solche Schnittstelle als Webservice zu implementieren. Die Daten würden also in einer entsprechenden Cloud abgelegt. Der Service bietet die entsprechenden Funktionen zum Anlegen von Fällen sowie zum ablegen und abrufen von Informationen. Dazu gehören auch Upload und Download von Dokumenten, etwa Schriftsätze, Beweisfotos, Graphiken etc.

Kraft, Matthias, Austausch juristisch relevanter Fakten zwischen heterogenen Anwendungen [Medienkombination] (Computer im Recht: Bd. 8), Elwert, Marburg (1999). Zugl.: Saarbrücken, Univ., Diss., 1997, ISBN 3-7708-1118-6 (erhältlich über den Autor und über http://blog.effipub.de/wp-content/uploads/2012/10/diss_kraft.pdf) m.w.N.

 

---

 

Matthias Kraft, Rechtsanwalt, Efficient Publishing UG.

 

---