Ein juristisches Datenmodell für XML
Wozu ein Datenmodell?
Ziel ist es das Internet wie eine Datenbank nach juristischen Informationen befragen zu können. "Finden statt surfen". Des weiteren soll die Möglichkeit geboten werden, praxis-, organisations-, länder- und sprachenübergreifend an Akten und Projekten "real-time" zusammenzuarbeiten. XML bietet hierfür eine systemübergreifende, globale Sprache. Es bedarf zur Erreichung dieses Ziels einer Normierung für den Informations- oder genauer gesagt - den Datenaustausch zwischen Juristen.
Bei Normierung oder Standardisierung versucht man die Wirklichkeit in einem System zu "fangen". Kein System, wie ausgeklügelt es auch ist, wird der Vielfältigkeit der Wirklichkeit gerecht. Das gilt für das Rechtssystem (summum ius, summa iniuria) genauso wie für eine Normierung für den Datenaustausch.
Für juristische Kommunikation gibt es viele Normierungen. Zum Beispiel legt das Prozeßrecht Normierungen fest. Die Zahl der verschiedenen Normierungen ist wahrscheinlich nicht viel kleiner als die Zahl der Arten der juristischen Kommunikation. Wo es eine fast unmögliche Aufgabe wäre, die Kommunikation innerhalb einer Jurisdiktion bis ins Detail zu normieren, muß eine jurisdiktionsübergreifende Normierung bis ins Detail eine unmögliche Aufgabe sein.
Es besteht bereits eine Reihe von Initiativen den Datenaustausch zwischen Juristen[1] in XML-Format zu normieren. Es geht dabei insbesondere um Festlegung der "Document Type Definitions" (DTD). Es ist zu erwarten, daß die Zahl so groß und die Arten der XML-DTD´s so vielfältig werden, wie die Normierung der juristischen Kommunikation auf herkömmlichem Weg heutzutage bereits ist. Aber... es besteht jetzt die Chance eine Richtlinie zu entwickeln, wonach eine jede XML Normierung sich richten kann. Diese Richtlinie könnte aus einem für die verschiedenen Rechtssystemen als gemeinsam empfundenen Datenmodell bestehen. Um eine Akzeptanz zu finden, muß das Datenmodell sich auf einem Niveau bewegen, das einerseits so abstrakt ist, daß sich die einzelnen XML Implementierungen einordnen können, andererseits aber konkret genug ist, daß es zu einem sinnvollen Datenaustausch kommen kann. Wo die Grenze zwischen abstrakt und konkret liegt, wird sich in der Praxis erweisen.
Das Ziel und der Weg sind hiermit einigermaßen abgesteckt. Jetzt sollen einige Begriffe definiert werden.
Datenaustausch - welche Daten
wozu?
Daten die Juristen austauschen, können grob in zwei Kategorien eingeteilt werden: Fallbezogenen Daten und rechtssystembezogene Daten. Anders gesagt: Aktendaten und Know How. Know How eignet sich für Veröffentlichung im Internet. Fallbezogene Daten sind einem kleinerem Kreis vorbehalten, der die Daten über Internet mit Sicherheitsvorkehrungen oder über direkte Telefon- oder Datenverbindungen austauschen.
Know How Daten sind jene Daten die das Rechtssystem beschreiben. Zu denken ist an Urteile, Gesetze, Aufsätze, rechtliche Gutachten. Des weiteren kann man unterscheiden zwischen veröffentlichtem und unveröffentlichtem Know How. "Unveröffentlicht" sind Daten, die nicht allgemein, sondern nur einem kleinerem Kreis zugänglich sind. Zum Beispiel gibt es in vielen Anwaltskanzleien ein internes Know How System. Es wird dort die in verschiedenen Fällen aufgebaute Rechtskenntnisse für die Verwendung in anderen Fällen gespeichert. Es gibt kaum einen Juristen, der nicht für sich selbst in irgendeiner Form ein Know How System führt.
Know How Daten stammen fast immer aus Akten. Eine klare Trennung gibt es also nicht und soll es nicht geben. Die rechtliche Würdigung in einem Schriftsatz ist ein Beispiel von Daten die einerseits "Aktendaten" und andererseits unveröffentlichte Know How Daten darstellen.
Aktendaten sind alle Daten die eine Akte betreffen. Diese Daten betreffen einerseits Daten, die als juristisch zu bezeichnen sind, wie Argumentationen, Zitate aus den Gesetzen und der Literatur, aber andererseits in größerem Umfang Daten, die die Verwaltung der Akte betreffen wie zum Beispiel der Eingang eines Faxes, Versand einer E-Mail, Besprechung, Telefonat, Eingang einer Zahlung, internes Memo usw. Diese "Mandatsereignisse" können teilweise inhaltlich juristische Daten zum Gegenstand haben. Der Eingang eines Schriftsatzes ist gedanklich aber vom Inhalt des Schriftsatzes zu trennen.
Wenn der XML Datenaustausch zwischen Gericht und Anwälte normiert wird, ist es also durchaus sinnvoll für diesen Datenaustausch Kompatibilität mit dem XML-Datenaustausch für Know How anzustreben.
Daten und Information
Über den Unterschied von "Daten" und "Information" ist viel geschrieben worden. In unserem Kontext scheint die folgende Definition sinnvoll:
Information ist eine Sammlung von Daten, die durch die
Zusammensetzung der Daten und der Verwendung dieser Daten Bedeutung für den
Empfänger hat oder erlangt.
Was Daten sind und was Information ist, hängt also maßgeblich vom Empfänger und von den Umständen während des Empfangs ab. Eine Sammlung von Daten kann für den einen eine Sammlung von Daten ohne eine darüber hinausgehende Bedeutung sein und für den anderen wirkliche Information sein. Es kann aber auch sein, daß dieselbe Sammlung von Daten für ein und dieselbe Person erst nur eine Datensammlung ist, aber in einem nächsten Fall Bedeutung hat und somit zur Information wird.
Wir tauschen Daten aus, in der Hoffnung und Erwartung, daß die Daten dem Empfänger zur Information dienen. Es ist die Zusammensetzung der Daten, die es ausmacht, ob die Sammlung zur Information für den Empfänger werden kann. Zur Beschreibung eines Datenmodells ist es deshalb sinnvoll, den Wandlungsprozeß von Daten nach Information näher zu betrachten.
Daten-Information-Objekt
Ein Beispiel: Es gibt einen Herrn Xomal, ein Grundstück, Steine, Zement, Holz, Ziegel, Fenster, Türen, einen Architekten, und eine Baufirma. Ich kenne alle diese Elemente. Ich weiß auch, daß Häuser gebaut werden können. Was ich bisher nicht wußte, ist daß Herr Xomal der Baufirma tatsächlich einen Auftrag erteilt hat, um aufgrund des Bauplans des Architekten auf dem Grundstück ein Haus zu bauen und daß das Haus inzwischen fertiggestellt worden ist. Ich kannte die Elemente, aber mir fehlte die Kenntnis, daß das Ereignis "Bauen" eingetreten ist, wodurch diese Elemente einen Zusammenhang bekommen haben.
Betrachten wir die Elemente als Daten. Nennen wir das Bauen ein "Ereignis". In dem Moment, in dem mir jemand sagt, daß das Haus gebaut ist, bin ich "informiert". Das nächste Mal, wenn mir jemand sagt, daß das Haus gebaut worden ist, bin ich nicht mehr informiert. Das Haus war für mich bereits ein Fakt, eine Tatsache. Daß Herr Xomal eine Einweihungsfeier in dem Haus gibt, wäre etwas neues und somit Information für mich. Das Haus dient dabei als Beschreibung des bevorstehenden Ereignisses, nämlich um den Ort zu bestimmen.
Es können folgende vorläufige Schlüsse gezogen werden:
Eine Sammlung von Daten, die einmal den Status Information erreicht hat und dann als Bezugspunkt zur Beschreibung eines Ereignisses dient, nennen wir ein "Objekt". Ein Objekt ist etwas, was von den Menschen im allgemeinen als zusammengehörend empfunden wird. Ein Haus oder allgemeiner formuliert, ein Ort, ein Mensch, ein Zeitpunkt, ein Dokument, eine Akte, ein Begriff, eine Zahl, ein Vorgang. Was als Objekt empfunden wird ist subjektiv. Warum das eine als Objekt empfunden wird und das andere nicht, ist nicht immer logisch. Es beruht jedoch auf einer Erfahrung, die den Menschen gemein ist. Diese Erfahrung ist sozusagen ein Archetyp.
Das Objekt-Ereignis Modell
Man stelle sich ein Kreuz vor, wobei die vertikale Achse die Objekte darstellt und die horizontale Achse den Zeitverlauf. Es ereignet sich ständig etwas auf die horizontale Zeitachse. Diese Ereignisse, werden mit den Objekten der vertikalen Achse beschrieben. Durch die Beschreibung werden Objekte mit einander verknüpft. Ein Ereignis stellt durch die Verknüpfung ein neues Objekt her. Mit dem neuen Objekt können zukünftige Ereignisse wieder beschrieben werden.
Vielleicht scheint diese Beschreibung sehr theoretisch, aber wenn man die Erfassung eines Faxeingangs in diesen Begriffen beschreibt, wird es sehr konkret: Man verbindet die Objekte Posteingang ("Vorgang"), Fax ("Dokument"), Akte, Datum des Dokuments ("Zeitpunkt"), Seitenzahl ("Zahl"), Absender (Person), Adressat (Person), Erfasser des Ereignisses ("Person") und Hyperlink mit einander.
Der Faxeingang könnte beim darauffolgenden E-Mail Ausgang als Bezugspunkt, als Objekt dienen. Man verbindet neben den genannten Objekten Postausgang, Akte usw. das eingegange Fax mit dem Begriff und Objekt "Antwort auf".
Der Hyperlink zum Speicherort des Faxes stellt eine 1 zu 1, eine einmalige, Verbindung zwischen dem Ereignis Faxeingang und dem Inhalt des Faxes her. Voraussetzung ist natürlich, daß das Fax, wie jedes andere Dokument in irgendeiner Form in Bits und Bytes auf der Festplatte eines Servers gespeichert ist. Dabei ist es unerheblich ob das Fax als Bilddatei, als ASCII Datei oder in einem sonstigen Format gespeichert ist. Hauptsache, man kann es auf dem Bildschirm aufrufen und lesen.
Der Inhalt des Faxes kann weiter in Objekten beschrieben werden (allgemeine wie der Begriff "Stellungnahme" oder spezifische wie "BGH 14.5.2000 Az 34.78900") wenn auf ein Urteil Bezug genommen wird.
Aufgabe
Wenn wir die Wirklichkeit der juristischen Arbeit und Kommunikation wie oben beschreiben, ist die Aufgabe, der wir uns gestellt haben, eigentlich erstaunlich einfach: Wir müssen lediglich verabreden, welche Objekte wir als juristische Archetypen definieren. Es wird eine lange Liste sein. Wir können für die Übersichtlichkeit eine Hierarchie erstellen: Überobjekte, Unter- Unterunter, und Unterunterunterobjekte. Besser wäre es jedoch, jedem Objekt eine fortlaufende Nummer zu geben und es zuzulassen, daß mit Bezugnahme auf die fortlaufende Nummerierung, mehrere hierarchische Strukturen innerhalb der Objektliste entwickelt werden, je nach Einsatzgebiet oder Jurisdiktion. Auf diese Weise kann das anfangs beschriebene Spagat zwischen Abstraktheit und Konkretheit des Datenmodells teilweise vermieden werden, weil das Modell eine eingebaute Flexibilität besitzt.
Da ein Objekt letztendlich mit einer Zahl definiert ist, kann die Beschreibung des Objektes in allen natürlichen Sprachen erfolgen. Anders gesagt: Jedes Objekt kann so viele Aliasnamen haben, wie es natürliche Sprachen gibt.
Die Objekte werden auf Webserver zur Verfügung gestellt. Die Verwaltung der Objektliste, in erster Linie die Vermeidung der Redundanz: das Erfassen von einem Objekt unter mehreren Nummern soll nicht stattfinden. Auch muß bei jedem Objekt entschieden werden, ob es hinreichend allgemein ist, um in die Liste aufgenommen zu werden, oder ob es einem allgemeineren Objekt zu "subsumieren" ist.
Der Jurist, der mit einem größtmöglichem Kreis von Juristen zusammenarbeiten will, beschreibt die Früchte seiner Arbeit mit den genannten Objekten. Dieser Jurist bietet damit seinen Sinnesgenossen die Möglichkeit, seine veröffentlichten Dokumente mit Abfragen auf Relevanz zu durchsuchen. Dabei ist es nicht nötig, daß der Fragesteller die im Internet veröffentlichten Seiten erst aufsucht, nein, er kann seine Abfrage "ins blaue hinein" ins Internet abfeuern und bekommt ein Suchergebnis. Darüber hinaus kann dieser Jurist mit Sinnesgenossen gemeinsam an Akten arbeiten, unabhängig von Entfernung, Sprachbarrieren, technischen und organisatorischen Differenzen.
Organisation
Die Organisation der Festlegung der Objektliste braucht nicht anders zu sein, als die jeder Normierung im Internet. Eine internationale Gruppe von Juristen, die durch eine "Open Source Haltung" Autorität gewinnt und weitere Gruppen für Jurisdiktionen und vergleichbaren Fachgebieten können diese Aufgabe wahrnehmen.
Murk Muller, Berlin 23.6.2000
[1] "Juristen" umfaßt all diejenigen die sich regelmäßig im juristischen Sinne äußern, also neben Anwälten, Richtern, Rechtswissenschaftlern, auch Beamte und Bankangestellte.