Jochen Notholt *Die Zukunft des Semantic Web (Teil 3 und Schluss)JurPC Web-Dok. 66/2005, Abs. 1 - 49 |
| Die im vorigen Teil des Artikels beschriebenen Datenstandards des Semantic Web, wie RDF, RDF Schema und OWL, beginnen sich langsam zu verbreiten und gegen konkurrierende Konzepte und Standards durchzusetzen. Doch was nützen die so entstehenden besonders wohldefinierten und -strukturierten Daten, wenn es keine Programme gibt, die sie auch besonders "intelligent" verarbeiten können? | JurPC Web-Dok. 66/2005, Abs. 1 |
| In diesem abschließenden Teil der Artikelreihe werden die Möglichkeiten beschrieben, RDF- und Ontologiedaten im Rahmen "intelligenter" Semantic-Web-Anwendungen einzusetzen. Einerseits wird sich hier zeigen, welches Potenzial im Semantic Web steckt - das zeigen aus Sicht des Juristen gerade die hier entwickelten fachspezifischen Anwendungsvorschläge am Ende der Arbeit. Andererseits haben sich die im Folgenden beschriebenen Ebenen des Semantic-Web-Modells bisher noch nicht oder nur unzureichend etabliert. Im World Wide Web sind zu jedem beschriebenen Aspekt kurze Erläuterungen zu finden, manchmal auch erste Ansätze zur Umsetzung. Die von Tim Berners-Lee vorausgesetzte "kritische Masse" zum Durchbruch des Semantic Web ist jedoch auch nach eigener Aussage(1) noch nicht überschritten. Auch auf dieses Problem wird am Ende kurz einzugehen sein. | Abs. 2 |
|
I. Abfragesprachen für RDF |
| In den vorigen Teilen der Artikelreihe war bereits davon die Rede, dass das Semantic Web als "globale Datenbank" betrachtet werden kann. Tatsächlich bestehen gewisse strukturelle Parallelen zwischen RDF und dem relationalen Datenmodell, welches den Datenbanksektor schon seit längerem prägt. Nicht zuletzt können RDF-Daten auch in ähnlicher Weise abgefragt werden, was eine sehr effektive Datenverarbeitung ermöglicht. | Abs. 3 |
| In relationalen Datenbanken wird eine Vielzahl in gleicher Weise strukturierter Datensätze - wie z.B. Gerichtsentscheidungen - in einer Tabellenstruktur gespeichert. So könnte man zur Sammlung von Gerichtsentscheidungen eine Tabelle (eine sog. Relation) anlegen, die den Namen "Gerichtsentscheidungen" trägt und die Spalten "Name des Gerichts", "Datum", "Aktenzeichen", "Leitsätze", "Gründe" etc. enthält. Zur Speicherung werden die Daten jedoch nicht in ein normales Dokument wie z.B. eine Excel-Datei eingetragen, sondern über ein sog. Datenbank-Management-System (DBMS) verarbeitet. Eingefügt, geändert, abgefragt und gelöscht werden die Daten über eine spezielle sog. Abfragesprache(2) (engl. query language). Wie schon im ersten Teil der Arbeit erwähnt(3), hat sich hier der Standard SQL durchgesetzt. Mit SQL-Kommandos können relationale Datenbanken einfach und effizient bearbeitet, vor allem aber ausgelesen werden. | Abs. 4 |
| Um im Beispiel der oben angesprochenen Entscheidungsdatenbank alle Entscheidungen des BVerfG eines bestimmten Datums abzurufen, genügt die SQL-Anfrage: | Abs. 5 |
| SELECT FROM Gerichtsentscheidungen WHERE Gericht="BVerfG" AND Datum="2004-03-31" | Abs. 6 |
| Ausgegeben werden dann die Datensätze, also die Zeilen der Tabelle, auf die diese Beschreibung zutrifft - also diejenigen Urteile, in denen das "BVerfG" als entscheidendes Gericht und das genannte Datum als Entscheidungsdatum eingetragen wurden. SQL erlaubt noch sehr viel komplexere Abfragen, vor allem auch die Abfrage von Daten aus verschiedenen, miteinander verknüpften Tabellen. In einer durchdacht entworfenen Datenbank wird SQL so zu einem sehr mächtigen Werkzeug. | Abs. 7 |
| Abfragen wie in SQL sind mit Daten, die in HTML-Dateien gespeichert sind, kaum möglich. HTML-Daten haben nämlich keine semantische Struktur, sie stehen also nicht in Beziehungen zueinander, die eine sinnvolle Abfrage voraussetzt. Zwar lassen sich auch hier Daten zu Tabellen gruppieren, diese Gruppierung dient aber eben nur der Darstellung, nicht der Vermittlung des Bedeutungsgehalts der Daten. | Abs. 8 |
| Das ist in XML-basierten Dokumenten, wie im ersten Teil des Artikels beschrieben(4), anders; dementsprechend lassen sich Daten hier ähnlich wie in einer Datenbank abfragen. Hierzu gibt es eine spezielle, auf XML basierende Abfragesprache namens XQuery.(5) Hätte man z.B. verschiedene Gerichtsentscheidungen in einzelnen XML-Dokumenten gespeichert, die alle einem passenden Schema (wie z.B. dem Saarbrücker Standard für Gerichtsentscheidungen(6)) entsprächen, könnte man mit XQuery diese Dokumente ähnlich wie im obigen SQL-Beispiel abfragen. Die Abfrage ist allerdings an die Baumstrukturen des jeweiligen XML-Dokumentenschemas gebunden. SQL ist insoweit flexibler, die relationale Strukturierung der Daten mit der Möglichkeit der Verknüpfung verschiedener Relationen erlaubt alles in allem mächtigere Abfragen. Diese, das ist das große Problem, können jedoch immer nur innerhalb einer einzelnen Datenbank (bzw. innerhalb eines DBMS) stattfinden. Jedes einzelne DBMS ist eine "black box", die nur schwer zur Zusammenarbeit mit anderen Datenbanken zu bewegen ist. | Abs. 9 |
| Der Schritt relationaler Abfragesprachen in das Semantic Web und damit hin zur "globalen Datenbank" ist jedoch nicht weit. Denn das RDF-Datenmodell lässt sich auf Grund seiner festen triple-Struktur von vornherein als relationales Modell auffassen. Wie die Zeileninhalte einer SQL-Datenbanktabelle über ihre Spalten in einer Beziehung zueinander stehen, so stehen auch die Elemente eines triples in einem solchen Verhältnis.(7) Dementsprechend liegt es nahe, auch mit RDF-Daten SQL-ähnliche Abfragen durchzuführen. Einige dieser RDF-Abfragesprachen sind bereits entwickelt worden(8), aussichtsreichster Kandidat für eine weite Verbreitung dürfte das erst kürzlich vom W3 Consortium empfohlene SPARQL(9) sein. | Abs. 10 |
| Wenn z.B. Rechtsanwalt Meier interessante Gerichtsentscheidungen gemeinsam mit beschreibenden RDF-Daten veröffentlichen würde, könnte man basierend auf diesen Daten Abfragen durchführen, um Entscheidungen nach bestimmten Kriterien zu filtern. Welche Kriterien dies sind, ist natürlich davon abhängig, wie genau die Entscheidungen in RDF konkret beschrieben sind. Fehlen in den RDF-Beschreibungen z.B. die Entscheidungsdaten, lassen sich diese auch nicht gezielt abfragen. Das ist in SQL-Datenbanken aber nicht anders. Bei RDF-Daten ergibt sich dagegen der oben angesprochene Vorteil der Dezentralisierung. In unserem Beispiel heißt das, ein beliebiger Dritter könnte die Entscheidungsdaten ggf. in Form von RDF-Aussagen dem abzufragenden Datenbestand hinzufügen. In RDF, RDF Schema und OWL veröffentlichte Daten sind damit nicht in einer "black box" gespeichert(10), sondern machen das WWW zu"dem" offenen Datenbanksystem. | Abs. 11 |
| RDF-Abfragen über eine einzelne Datenquelle hinaus funktionieren aber nicht immer "von selbst". Nehmen wir an, es liegen zahlreiche in RDF beschriebene Gerichtsentscheidungen vor, die jedoch nicht nur von RA Meier, sondern von vielen anderen Kanzleien und auch Verlagen veröffentlicht wurden. Aus diesem Datenbestand sollen Urteile des Bundesverfassungsgerichts ermittelt werden. Rechtsanwalt Meier verwendet zur Beschreibung "seiner" Entscheidungen die (fiktive) Rechtsontologie unter http://www.rechtsontologie.de (XML-Namespace ro:), und eine einzelne Entscheidung pflegt er wie im Beispiel aus Teil 2 dieses Artikels(11) über das Prädikat ro:entschieden_von mit dem Gericht, das jeweils entschieden hat, zu verknüpfen. Ausgehend von den RDF-Entscheidungsdaten des Rechtsanwalts Meier könnte eine SPARQL-Abfrage nach allen Subjekten einer RDF-Aussage suchen, die das Prädikat ro:entschieden_von haben, und als Objekt eine Instanz der Klasse ro:Gericht mit dem Wert http://www.bundesverfassungsgericht.de. | Abs. 12 |
| Sobald RDF-Entscheidungsdaten aus anderen Quellen herangezogen werden, die diese Bezeichnungen nicht benutzen, ist die reine RDF-Abfrage nutzlos. Im Semantic Web lässt es sich nicht vermeiden, dass unterschiedliche Ontologien benutzt, also verschiedene "Sprachen gesprochen" werden. Eine Semantic-Web-Anwendung, die auf einer reinen Abfragesprache wie SPARQL basiert, kann mit diesen unterschiedlichen RDF-Bezeichnungen nicht umgehen. Unterschiede und Gemeinsamkeiten, wie z.B. die Parallele zwischen einem Prädikat ro:entschieden_von und einem Prädikat http://juront.de/elemente#hat_entschieden (abgekürzt: jo:hat_entschieden), werden nicht erkannt. Hier ist eine weitere Ebene des "Semantic Web Tower"(12) gefordert, die Logikebene. Sie und die ähnlich gelagerte Beweisebene basieren auf sog. Inferenzmechanismen, die es erlauben, logische Regeln auf RDF-Daten anzuwenden und auf diese Weise neue Daten zu erzeugen oder Daten auf ihre Richtigkeit hin zu überprüfen. | Abs. 13 |
II. Inferenzen auf der Logik- und Beweisebene |
| Um aus bestehenden RDF-Daten im Wege des logischen Schlusses neue Aussagen erzeugen, also neues Wissen produzieren (Logikebene) bzw. die Richtigkeit von Aussagen prüfen (Beweisebene) zu können, benötigt man neben den zu prüfenden Daten zweierlei: zum einen logische Regeln, zum anderen Programme, die diese Regeln ausführen. | Abs. 14 |
| Logische Regeln sind Aussagen nach dem "Wenn ..., dann ..."-Prinzip. Diese Regeln kann man ausdrücklich formulieren, muss es aber nicht tun. Im Semantic Web ergeben sich Regeln bereits aus dem Verhältnis, in dem einzelne Klassen und Eigenschaften zueinander stehen. Wenn z.B. in einem RDF Schema ausgedrückt wird, dass ro:Gerichtsentscheidung eine Unterklasse (rdfs:subclassOf) von ro:Rechtsquelle ist, dann ergibt sich hieraus die Regel: | Abs. 15 |
| "Wenn eine Ressource eine (Instanz der Klasse) ro:Gerichtsentscheidung ist, dann ist sie auch eine (Instanz der Klasse) ro:Rechtsquelle." | Abs. 16 |
| Ebenso kann man die Verhältnisse zwischen Klassen und Eigenschaften formulieren, die sich in OWL ausdrücken lassen. Im vorigen Abschnitt wurde z.B. davon ausgegangen, dass Rechtsanwalt Meier das Prädikat ro:entschieden_von benutzt, während andere Autoren das Prädikat jo:hat_entschieden verwenden. In OWL kann man, wie im vorigen Teil dieser Reihe erläutert(13), über die Eigenschaft owl:equivalentOf zum Ausdruck bringen, dass beide Prädikate gleichbedeutend sind. Das ist auch eine Regel: | Abs. 17 |
| "Wenn ein Gericht eine Gerichtsentscheidung jo:entschieden_hat, dann ist die Gerichtsentscheidung auch ro:entschieden_von diesem Gericht (und umgekehrt)." | Abs. 18 |
| Man kann logische Regeln aber auch unabhängig von RDFS- und OWL-Konstrukten formulieren: | Abs. 19 |
| "Wenn eine Gerichtsentscheidung von http://www.bundesverfassungsgericht.de entschieden wurde, und die Entscheidung ro:hat_Beschwerdegegenstand des Typs ro:Gerichtsentscheidung oder ro:Rechtsvorschrift, dann hat diese Entscheidung eine Eigenschaft ro:ist_Verfahrensart mit dem Wert ro:BVerfG_Verfassungsbeschwerde."(14) | Abs. 20 |
| Diese logischen Regeln helfen nur wenig, wenn es keine Programme gibt, die in der Lage sind, die richtigen Schlüsse aus ihnen zu ziehen. Diese Programme nennt man Folgerungs- oder Inferenzmaschinen (engl. inference engines). Die logischen Regeln bilden gemeinsam mit den Inferenzmaschinen zunächst die Logikebene des Semantic Web. | Abs. 21 |
| Inferenzmaschinen lassen sich grundsätzlich zu zwei Zwecken einsetzen: Zum einen zur sog. Instanzprüfung (instance checking), zum anderen zur Angleichung und Verknüpfung von Schemata und Ontologien (schema / ontology mapping). | Abs. 22 |
| Die Instanzprüfung kann man sich als das RDF-Gegenstück zur XML-Validierung(15) vorstellen. Genau wie in einem XML Schema kann man, wie zuvor beschrieben, auch in RDFS Begrenzungen für Eigenschaftswerte bestimmen. So wurde als Beispiel die Eigenschaft ro:entschieden_von so definiert, dass sie eine Eigenschaft der Klasse ro:Gerichtsentscheidung ist und einen Wert der Klasse ro:Gericht haben soll. Anders als in einem XML Schema ist es nun allerdings durchaus möglich, ein RDF-triple zu erzeugen, das sich an nicht diese Beschränkungen hält, aber trotzdem (als RDF/XML gespeichert) im Sinne von XML valide ist. Ein RDF Schema gibt nur ein Vokabular vor, das nicht zwingend eingehalten werden muss.(16) Jedes Programm, das mit RDF Schema und OWL arbeitet, kann selbst bestimmen (bzw. seine Entwickler können das tun), inwieweit eine entsprechende Instanzprüfung erfolgen und wie tolerant mit RDF-Daten umgegangen werden soll, die sich nicht strikt an ihre zu Grunde liegenden Schemata und Ontologien halten. Eine konfigurierbare Form der Instanzprüfung ermöglicht z.B. der Validating RDF Parser 2.0 von ICS-FORTH(17) sowie der RDFS Reasoner im Rahmen der Jena2 API(18). | Abs. 23 |
| Die Angleichung von Schemata und Ontologien ist mindestens ebenso wichtig wie die Instanzprüfung. Oben wurde gezeigt, dass "reine" RDF-Abfragesprachen wie SPARQL letztlich auf Daten aus einheitlichen Ontologien angewiesen sind. Um z.B. erkennen zu können, dass die Eigenschaft ro:entschieden_von das Gleiche bedeutet wie jo:hat_entschieden, müsste das Programm, das die Abfragen vornimmt, zusätzlich zu Abfragebefehlen auch logische Regeln interpretieren können, wie sie z.B. in RDFS, OWL oder in freier formulierter Form vorliegen können. Solche Folgerungsmaschinen lassen sich z.B. mit den Systemen BOR(19) und RACER(20) sowie mit den inference engines aus dem Jena2 Toolkit(21) "bauen", wenngleich dies bisher eher eine Aufgabe für professionelle Entwickler als für gelegentlich programmierende Juristen sein dürfte. | Abs. 24 |
| Einem ähnlichen Prinzip wie die Logikebene des Semantic Web folgt die Beweisebene (proof layer). Wenn das Semantic Web in der Lage sein soll, aus bestehenden (RDF-)Aussagen im Wege des logischen Schlusses neue Aussagen herzuleiten, dann soll das auf dieser Ebene auch umgekehrt möglich sein: Es soll bewiesen werden können, dass eine bestimmte Aussage logisch richtig ist, indem sie sich aus anderen bestehenden Aussagen herleiten lässt. Im juristischen Kontext ließen sich so z.B. Zitate und Fundstellen auf ihre Richtigkeit überprüfen.(22) Die zu dieser Form des Beweises erforderlichen Daten und Regeln entsprechen denen der Logikebene, weshalb diese häufig auch mit der Beweisebene zusammen genannt wird. Die Programme, die diese Regeln auswerten, funktionieren jedoch anders und müssen daher auch in speziellen Sprachen (proof languages) geschrieben werden. Im Web sind schon einige Ansätze erkennbar, wie eine solche Sprache gestaltet sein könnte,(23) konkrete Anwendungen haben sich hieraus aber noch nicht ergeben. | Abs. 25 |
III. Vertrauen in RDF-Aussagen |
| Die Logik- und Beweisebene sollen gewährleisten, dass zwischen den Daten des Semantic Web die logische Schlüssigkeit erhalten bleibt, damit Maschinen mit den Daten prinzipiell nicht anders umgehen müssen als wir Menschen es auch täten. In einem offenen Datenmodell wie RDF, wo prinzipiell jedermann Aussagen über alles treffen kann, bleibt jedoch darüber hinaus die Gefahr inhaltlich falscher Aussagen bestehen. Welche Folgen die Verbreitung solcher "Falschaussagen" mit sich bringen kann, wissen wir Juristen nur allzu gut. Während wir gegen die Verbreitung von Unwahrheiten üblicherweise repressiv vorgehen (vgl. nur die §§ 153 ff., 185 ff. oder auch 263 StGB), geht es im Semantic Web eher darum, die negativen Folgen inhaltlich falscher Aussagen von vornherein zu vermeiden. Dies soll die Vertrauensebene (trust layer) des Semantic Web ermöglichen, die bislang leider allenfalls in Ansätzen ausgearbeitet ist. Sie soll nicht etwa eine "Web-Zensur" begründen und verhindern, das jedermann (im Rahmen der Rechtsordnung) das, was er möchte, veröffentlichen kann. Statt dessen soll gewährleistet werden, dass die Maschinen im Semantic Web die Möglichkeit haben zu entscheiden, ob sie den Aussagen bestimmter Quellen Glauben schenken, also vertrauen möchten oder nicht. | Abs. 26 |
| Prinzipiell haben sich zwei Richtungen entwickelt, in die dieses Ziel verfolgt wird. Das W3 Consortium setzt bei seiner Umsetzung des trust layer vor allem auf technische Standards wie Verschlüsselung und digitale Signaturen.(24) Vor allem letzteren, umgesetzt mit dem Standard XML Signatures(25), kommt dabei eine zentrale Rolle zu. RDF-Aussagen werden gemeinsam mit einer digitalen Signatur veröffentlicht, um zu belegen, dass die veröffentlichende Person zu diesen Daten "mit seinem Namen steht" und die Daten seit der Veröffentlichung nicht durch Dritte verfälscht wurden. Solche Daten sind bereits prinzipiell vertrauenswürdiger als unsignierte Daten, bei denen die Möglichkeit einer Verfälschung nie ganz ausgeschlossen werden kann. | Abs. 27 |
| Ein Verfahren, das die soziale Komponente des Vertrauens im Semantic Web stärker betont, ist das trust-network-Verfahren, das vor allem auf Semantic-Web-Forscher an der Stanford University zurückgeht.(26) Es basiert auf dem sozialen Prinzip, dass wir Unbekannten nicht so leicht unser Vertrauen verschenken wie solchen Quellen und Personen, die wir kennen und deren Glaubwürdigkeit und ggf. auch Autorität wir anerkennen. Dieses Vertrauen bildet sich in der Praxis in Netzwerken aus.(27) Das heißt zweierlei: Zum einen stellen wir Vertrauen über "Zwischenstationen" im Netzwerk her - A vertraut B, B vertraut C, also kann A dem C (vermutlich) auch vertrauen. Zum anderen lässt das Vertrauen aber auch nach, je mehr dieser Stationen zwischen dem Sender und dem Empfänger von Informationen liegen. | Abs. 28 |
| Am wirksamsten dürfte ein Verfahren zur Umsetzung des trust layer sein, der technische und soziale Komponenten des Vertrauens zusammenführt. Wenn z.B. das Bundesverfassungsgericht die Entscheidung aus dem Beispiel in Teil 1 inklusive beschreibender RDF-Daten selbst veröffentlichte und die RDF-Daten auch noch digital signierte, wäre die Vertrauenswürdigkeit dieser Veröffentlichung kaum zu überbieten. Eine Semantic-Web-Suchmaschine, die eine Vertrauensebene technisch integriert hat, wird diese Veröffentlichung höher gewichten als eine Zweitveröffentlichung der gleichen Entscheidung von Rechtsanwalt Meier, wenngleich dieser immerhin noch Fachanwalt im Strafrecht und damit die Gefahr inhaltlicher Fehler recht gering ist. Falls jedoch ein Jurastudent die Entscheidung auf seiner privaten Homepage veröffentlicht, dürfte das Vertrauen der Suchmaschine vermutlich etwas geringer ausfallen - es sei denn, die Homepage des Studenten ist in Fachkreisen so weit anerkannt, dass sie im Vertrauensnetzwerk der Suchmaschine einen hohen Rang erworben hat. | Abs. 29 |
IV. Semantic Web Service |
| Wenn bisher wiederholt von "Maschinen" die Rede war, die im WWW selbstständig arbeiten, so klingt das futuristischer als es ist: Das Web ist schon längst keine reine Dokumentsammlung mehr, sondern wird von Programmen dominiert, die Online-Daten auswerten, erzeugen und ausgeben. Während die meisten dieser Programme "versteckt" ihren Dienst verrichten, ohne dass andere Online-Programme und -Nutzer etwas davon merken, richtete sich das Interesse gerade in der Wirtschaft in den letzten Jahren auf solche Dienste, die nach offenen Standards angesteuert, also angesprochen werden können und Daten als Ergebnis in standardisierter Form ausgeben. Diese Online-Programme nennt man Web Services. Als Standard für Web Services hat sich in den letzten Jahren SOAP durchgesetzt, das auf XML basiert.(28) | Abs. 30 |
| SOAP-basierte Web Services haben primär den Vorteil der einheitlichen Schnittstelle. Nehmen wir als Beispiel eine Entscheidungsdatenbank für Volltexte des Bundesverfassungsgerichts, die als Web Service funktioniert (und die es leider noch nicht gibt). Jeder Web Service benötigt einen Eingabewert, hier z.B. einen Datensatz aus Entscheidungsdatum, Urteil etc., und gibt als Ergebnis einen Datensatz aus, der den Volltext der Entscheidung enthält. Würde jeder Web Service für diese Eingabe- und Ausgabewerte ein eigenes Datenformat definieren, wäre es für Entwickler schwierig, Programme zu schreiben, die mit Web Services kommunizieren. Er müsste jedes einzelne Programm aufwändig anpassen. Dieses Problem entfällt bei SOAP-basierten Web Services, da jede Eingabe und Ausgabe in einem etwas umständlichen, aber dafür immerhin einheitlichen XML-Format vorliegt. Mit welcher Programmiersprache die Web Services ihrerseits arbeiten, muss den Entwickler, dessen Programm mit ihnen kommunizieren möchte, gar nicht interessieren. | Abs. 31 |
| Ein Problem ist jedoch die effiziente Kommunikation der Web Services untereinander. Sie sind nicht in der Lage, selbstständig miteinander zu kommunizieren, da sie die inhaltliche Bedeutung der Ausgaben anderer Web Services nicht erkennen können. Zwar existieren wiederum XML-basierte Standards für die Beschreibung der Ein- und Ausgabewerte (WSDL(29)) und des Aufgabenbereichs eines Web Services (UDDI(30), so etwas wie die "Gelben Seiten" für Web Services). Effektiver wäre es jedoch, Web Services mit den Vorzügen des Semantic Web zu verbinden. | Abs. 32 |
| Hierzu wurden zum einen zusätzliche Ontologie-Standards(31) vorgeschlagen (zunächst DAML-S, mittlerweile OWL-S(32)), die speziell auf die Kommunikation zwischen Web Services abgestimmt sind. Sie ermöglichen die Klassifizierung von Web Services und die Beschreibung ihrer Funktionalität im Verhältnis zueinander. Zudem kann man die Frage stellen, ob man im Semantic Web der "intelligenten" und flexiblen RDF- und Ontologiedaten einen relativ strikten Standard wie SOAP überhaupt noch braucht. Man könnte bei Web Services daher auch an Stelle von SOAP vollständig von RDF-Daten für die Ein- und Ausgabewerte eines Dienstes ausgehen.(33) | Abs. 33 |
V. Anwendungsmöglichkeiten für Juristen |
| Zwar existieren für das Semantic Web bereits genau definierte Datenstandards, ebenso wie umfangreiche Programmierwerkzeuge, wie Schnittstellen für gängige Programmiersprachen (sog. APIs) und Entwicklungsumgebungen (sog. IDEs).(34) Außerdem schreitet mittlerweile die Entwicklung von RDF-Vokabularen bzw. Ontologien für den "Alltagsgebrauch" voran. Als besonders anschauliches Beispiel sei hier nur das bereits im zweiten Teil dieser Arbeit angesprochene FOAF-Vokabular erwähnt, das der Beschreibung von Personen und ihren Beziehungen zueinander dient. Auf FOAF basierend wurden bereits einige kleinere Anwendungen entwickelt, die online veröffentlichte FOAF-Beschreibungen automatisch auswerten.(35) Trotzdem verläuft die praktische Umsetzung der Semantic-Web-Standards alles in allem weiterhin eher schleppend. Wenngleich erste Anbieter damit beginnen, ihre Daten in RDF zu veröffentlichen(36), fehlen bislang zumindest die "Killer-Applikationen"(37). Das dürfte vor allem an der bislang wenigstens lückenhaften Ausarbeitung der Logik-, Beweis- und Vertrauensebene liegen. | Abs. 34 |
| Im juristischen Bereich sieht es derzeit noch dürftiger aus. Der erste öffentliche Versuch des LexML-Projekts(38), ein juristisches RDF-Vokabular zu entwerfen(39), scheint inzwischen nicht weiter verfolgt zu werden. Die Integration des Semantic Web in juristische Online-Projekte beschränkt sich bislang auf theoretische Erwägungen.(40) | Abs. 35 |
| Da dieser Artikel, wie eingangs erwähnt, zur praktischen Arbeit am und im Semantic Web aus juristischer Sicht motivieren soll, schließt er mit der Beschreibung einiger Anwendungsideen ab. Zudem soll gezeigt werden, welche Schritte zur Umsetzung nötig sind, bzw. was der Einzelne tun kann, um das Semantic Web auch für Juristen nutzbar und interessant zu machen. | Abs. 36 |
1. Beschreibung von Rechtsinformationen |
| Wenn man sich auf die Ideensuche nach juristischen Semantic-Web-Anwendungen begibt, kann man sich zunächst fragen, welche juristischen Informationen zunächst zum Gegenstand semantischer Beschreibungen gemacht werden sollen. Offensichtlichster Fall sind hier die klassischen Rechtsquellen, also Gesetze, Entscheidungen und Literatur - am besten solche, die tatsächlich online veröffentlicht sind.(41) RDF-Beschreibungen dieser Dokumente können eine sehr viel effektivere Verarbeitung juristischer Fachinformationen bewirken als dies bislang möglich war. | Abs. 37 |
| Im Gegensatz zum gegenwärtigen WWW, das online veröffentliche Dokumente bloß darstellt, fördert (und fordert) das Semantic Web allgemeine Ressourcenbeschreibungen. Dies erweitert den juristischen Anwendungsbereich über die Verarbeitung online veröffentlichter Rechtsquellen hinaus. Es lassen sich nicht nur beliebige Rechtsquellen beschreiben und auswerten, sondern auch alle sonstigen Rechtsinformationen: Sachverhaltsinformationen, juristisches Strukturwissen, Probleme, Meinungen und die zugehörigen Argumente.(42) Alle diese Informationen lassen sich in ihrem tatsächlichen Bedeutungsgehalt erfassen und auswerten. Waren juristische Online-Anwendungen bisher immer dokumentenbasierte Anwendungen, können sie jetzt auch datenbasierte Anwendungen sein. Was das bedeutet, sollen die folgenden Beispiele andeuten. | Abs. 38 |
2. Anwendungbeispiele |
| Das wohl offensichtlichste Beispiel für eine wertvolle Semantic-Web-Anwendung wurde bereits angesprochen: die semantische Suchmaschine. Trotz der manchmal erstaunlich effektiven Suchalgorithmen von Google krankt die herkömmliche Suchmaschinen-Technik daran, dass sie weitgehend auf die Auswertung des Dokumenten-Volltextes, also auf die syntaktische Zeichenebene beschränkt ist. Die Auswertung wohldefinierter und -strukturierter RDF-Daten ermöglicht den Zugang zur semantischen Zeichenebene und erschließt damit auch im juristischen Bereich neue Möglichkeiten. Zwar bemühen sich Juristen seit jeher darum, ihre Rechtsquellen eindeutig zu bezeichnen und damit auf syntaktischer Ebene leicht auswertbar zu halten, z.B. durch eindeutige Gesetzesangaben und Aktenzeichen von Gerichtsentscheidungen. Die juristische Literatur (also Lehrbücher, Kommentare, Monographien, Dissertationen etc.) kann diese syntaktisch eindeutigen Kennzeichnungen jedoch nicht bieten. Wer nach einem Buch oder einem Aufsatz zu einem bestimmten Rechtsproblem sucht, wird feststellen, dass viele Autoren verschiedene Begriffe zur Beschreibung des gleichen Problems oder Themas verwenden. Hieraus ergeben sich Suchprobleme, die wohl jeder Jurist aus Ausbildung und Praxis kennt. Eine semantische Erschließung dieser juristischen Dokumente könnte Suchabfragen erheblich effektiver gestalten. Zudem wäre theoretisch eine Recherche über verschiedene (auch kommerzielle(43)) Anbieter im gesamten (semantischen) Web möglich, die so bisher höchstens in geschlossenen juristischen Datenbanken (wie z.B. juris oder Beck Online) möglich ist. | Abs. 39 |
| Da RDF-Annotationen dezentral möglich sind, könnten Metainformationen juristischer Dokumente auch nachträglich und durch Personen veröffentlicht werden, von denen das eigentliche Dokument gar nicht stammt. Mit RDF-Beschreibungen könnten z.B. Gerichtsentscheidung hinsichtlich ihrer Prüfungs- oder Praxisrelevanz, oder auch hinsichtlich ihrer juristischen Qualität (Ist die Ansicht noch herrschend? Liegt eine Fehlentscheidung vor?) beurteilt werden. So können Studenten oder Fachanwälte gezielt nach Dokumenten suchen, die für ihre individuellen Bedürfnisse relevant sind - oder sie können Portale entwickeln, die Online-Dokumente nach strukturierten Kriterien in strukturierter Form automatisch aufbereiten. | Abs. 40 |
| Diese individuellen Bedürfnisse lassen sich in RDF ebenfalls in maschinenlesbarer Form online veröffentlichen. Dies ermöglicht personalisierte Anwendungen, die für viele Entwickler den eigentlichen Reiz des Semantic Web ausmachen. Personalisierte Dienste (sog. Agenten) im juristischen Bereich könnten z.B. in einer Verbesserung von Suchmaschinen bestehen. Diese könnten anhand der persönlichen Nutzerdaten ermitteln, welche Daten oder Dokumente der einzelne Anwender benötigt. Eine Suchmaschine für juristische Dokumente könnte unterschiedliche Gerichtsentscheidungen als Ergebnis liefern, je nachdem, ob die Anfrage von einem Studenten oder einem Fachanwalt kommt. Zudem lassen sich personalisierte Dienste über den Einsatz von Web Services auch zur automatischen Geschäftsabwicklung einsetzen. Wer ein Rechtsproblem hat, könnte sich mit seinem persönlichen Semantic-Web-Agenten an einen Semantic-Web-Agenten zur Anwaltssuche wenden. Dieser tritt anhand der ihm zur Verfügung stehenden RDF-Daten von Anwälten mit dem Büro-Agenten desjenigen Anwalts in Kontakt, dessen Kanzlei in der Nähe des Mandanten liegt und dessen Tätigkeitsschwerpunkt dem Fall des Mandanten entspricht. Die Agenten vereinbaren anhand der ihnen zur Verfügung stehenden RDF-Kalendereinträge beider Parteien einen ersten Beratungstermin. Semantic-Web-Agenten könnten zudem den elektronischen Rechtsverkehr, gerade im Rahmen von Gerichtsverfahren, weiter automatisieren und damit verbessern. Eine konsequente Weiterentwicklung des XJustiz-Projekts(44) in Richtung Semantic Web wäre gerade deshalb reizvoll, weil die Gerichte wie im Falle der XML-Nutzung auch in diesem Fall ihre staatliche Autorität nutzen könnten, um neue Standards zu etablieren. | Abs. 41 |
| Ein besonderes Charakteristikum der Semantic-Web-Standards liegt darin, dass sie einheitliche "Sprachen" für Maschinen (und eben nicht für Menschen) sind. Semantic-Web-Daten können daher auch als Thesaurus oder Wörterbuch in einer oder zwischen verschiedenen menschlichen Sprachen fungieren.(45) Entsprechend könnten spezielle juristische Ontologien den Zugriff in verschiedenen Sprachen auf einheitliche Datenbestände erleichtern(46) und dabei helfen, Verständigungsschwierigkeiten in multilingualen Rechtsordnungen (wie z.B. dem EU-Recht) beizulegen. Das gilt nicht nur für den Zugriff auf internationale Rechtsdokumente, sondern auch für den grenzübergreifenden elektronischen Rechtsverkehr. | Abs. 42 |
3. Von der Theorie zur praktischen Anwendung |
| So verlockend diese Anwendungsbeispiele auch zunächst klingen mögen: Der Weg zu ihrer Umsetzung ist noch recht weit. Vor allem kann diese nicht dadurch erfolgen, dass RDF-Daten "drauflos" geschrieben werden. Bei der Entwicklung einer juristischen Semantic-Web-Anwendung sollte eine systematische Vorgehensweise eingehalten werden, um Fehlentwicklungen zu vermeiden.(47) | Abs. 43 |
| So sollte am Beginn einer Semantic-Web-Anwendung oder -Datensammlung immer eine Ontologie stehen, also ein Strukturmodell der verwendeten Klassen und ihrer Eigenschaften. Am einfachsten und zumeist auch am sinnvollsten ist es, bereits entwickelte Ontologien zu verwenden, welche z.T. online gesammelt werden.(48) Ist nichts Passendes zu finden, muss die Ontologie neu entwickelt oder eine bestehende erweitert oder sonstwie an die eigenen Bedürfnisse angepasst werden. Gerade letzteres ist wegen des beschriebenen dezentralen und offenen Charakters der Ontologie-Beschreibungen ohne weiteres möglich. Für juristische Anwendungen ist nach gegenwärtigem Kenntnisstand keine "fertige" Ontologie in Sicht. Vielleicht können die Beispiele aus dieser Arbeit den einen oder anderen interessierten Juristen motivieren, ein solches Projekt jedenfalls in Ansätzen in Angriff zu nehmen. | Abs. 44 |
| Erst nach dieser "Vorarbeit" sollte im zweiten Schritt damit begonnen werden, konkrete RDF-Daten zu entwerfen und zu veröffentlichen. Hier muss der einzelne Veröffentlichende zunächst die Frage klären, welche Daten er überhaupt beschreiben möchte, d.h. wie umfangreich und detailliert die Beschreibungen juristischer Daten sein sollen. Das dezentrale Prinzip des Semantic Web hat wie schon beim Ontologie-Entwurf den Vorteil, dass Daten, die erst später nachgefragt werden, jederzeit ergänzt werden können. Schwerer wiegen vermutlich die Probleme der praktischen Umsetzung des RDF-Entwurfs. Dieser ist schon um einiges schwerer als der Entwurf herkömmlicher Web-Angebote, und selbst mit dem sind die allermeisten Juristen überfordert. Eine entscheidende Aufgabe für die Verbreitung von RDF wird daher sein, Werkzeuge anzubieten, aus denen für bestehende (juristische) Dokument- und Datensammlungen die passenden RDF-Daten möglichst automatisch erzeugt und gepflegt werden können. Die Benutzerführung dieser Werkzeuge muss jedenfalls dann, wenn sie sich an Einzelpersonen wie Rechtsanwalt Meier richten, so einfach wie möglich sein. Doch auch für größere Anbieter, vor allem die etablierten Verlage, ist es von entscheidender Bedeutung, den Weg ins Semantic Web auf der Grundlage möglichst vieler bereits vorliegender Daten einfach und kostengünstig beschreiten zu können. | Abs. 45 |
| Der letzte Entwicklungsschritt ist der Entwurf von Programmen, die auf der Grundlage von RDF- und Ontologiedaten eine "intelligente" Verarbeitung juristischer Informationen vornehmen können. Dieser Teil der Artikelreihe hat angedeutet, welche Komponenten hierzu notwendig sind. Während die großen Verlage in ihren Entwicklungsabteilungen maßgeschneiderte Produkte entwickeln können, sind kleinere Anbieter entweder auf Standardprogramme angewiesen, oder sie stellen ihren Daten bloß öffentlichen Semantic-Web-Anwendungen wie den oben beschriebenen Suchmaschinen zur Verfügung. | Abs. 46 |
VI. Fazit und Ausblick |
| Erst durch die sinnvolle Verarbeitung der im vorigen Teil der Reihe erläuterten RDF- und Ontologiedaten können Semantic-Web-Anwendungen entstehen. Hier wurde beschrieben, wie durch datenbankähnliche Abfragen, logische Schlüsse, Beweis- und Vertrauensmechanismen Anwendungen entwickelt werden können, die denen des gegenwärtigen Web um einiges voraus sind. | Abs. 47 |
| Die oben angedeuteten Entwicklungsschritte hin zur "fertigen" Anwendung haben gezeigt, weshalb es so schwierig ist, die Zukunft des Semantic Web sicher vorherzusagen: Ontologien müssen entwickelt, RDF-Daten entworfen und Programme zu ihrer Verarbeitung geschrieben werden. Gibt es keine passenden Ontologien, können die weiteren Schritte nicht erfolgreich sein. Gibt es sie schon, und dazu große Datenmengen, auf die man sich bei der Entwicklung stützen kann, ist die Motivation, eine passende Anwendung zu entwickeln, erheblich größer. So wird die oben formulierte Aussage Berners-Lees von der "kritischen Masse", die das Semantic Web zu seinem Durchbruch überschreiten muss, verständlich. | Abs. 48 |
|
Gäbe es einen vollständigen wohldefinierten und -strukturierten RDF-Datenbestand aller in Deutschland veröffentlichen Rechtsquellen, der frei über das Web zugänglich wäre, könnte sich kein Verlag die Chance entgehen lassen, (nutzerfreundliche) Programme zu entwickeln, die diesen Datenbestand "intelligent" auswerten könnten. Doch auch wenn es diesen Datenbestand nicht gibt, wäre seine Entwicklung auf Grund der zunehmenden Verbreitung der Semantic-Web-Standards voraussichtlich keine Fehlinvestition. Sollte sich ein Standard mal nicht durchsetzen, könnten die Daten leicht maschinell in andere Standards konvertiert werden, da sie auf XML beruhen. Schließlich sind auch keine Investitionen in eine neue Infrastruktur erforderlich, da diese auf den herkömmlichen Web-Technologien und -Standards basiert.
| JurPC Web-Dok. 66/2005, Abs. 49 |
Fußnoten:(1) So Berners-Lee zuletzt im Interview: Frauenfelder, Das Unvollendete, Technology Review (dt.) 11/2004, online abrufbar unter: http://www.heise.de/tr/art ikel/52516.(2) Der Begriff der "Abfrage"sprache ist streng genommen missverständlich, da die Sprache alle Manipulationen der Datenbank über das reine Abfragekommando (also das Auslesen bestimmter Daten aus der Datenbank) ermöglichen soll. Trotzdem hat er sich eingebürgert. (3) Siehe Teil 1 des Aufsatzes. (4) Siehe Teil 1 des Aufsatzes. (5) XQuery wird vom W3 Consortium entwickelt: http://www.w3.org/XML/Query . (6) Siehe Teil 1 des Aufsatzes. (7) Vgl. Prud'hommeaux, RDF SQL Mapping (2001), online abrufbar unter: http://www.w3.org/2002/05 /24-RDF-SQL/. (8) Ein Vergleich mit Leistungsmerkmalen ist abrufbar unter: http://www. aifb.uni-karlsruhe.de/WBS/pha/rdf-query/. (9) Prud'hommeaux/Seaborne, SPARQL Query Language for RDF (2004), online abrufbar unter: http:// www.w3.org/TR/2004/WD-rdf-sparql-query-2000X012/. (10) Veröffentlicht man Semantic-Web-Daten nicht im WWW, sondern in einem Intranet, hätte man gleichwohl solch ein "geschlossenes" (Datenbank-)System. (11) Siehe Teil 2 des Aufsatzes. (12) Siehe Teil 2 des Aufsatzes. (13) Siehe Teil 2 des Aufsatzes. (14) Die Einschränkung hinsichtlich der Klassen ro:Gerichtsentscheidung und ro:Rechtsvorschrift ist nötig, um die Verfassungsbeschwerde als Klasse vom Wahlprüfungsverfahren nach Art. 41 Abs. 2 GG, §§ 13 Nr. 3, 48 BVerfGG abzugrenzen. Dieses hat rein begrifflich auch einen Beschwerdegegenstand. (15) Siehe Teil 1 des Aufsatzes. (16) Vgl. zur Verdeutlichung Brickley, Missing Isn't Broken (2004), online abrufbar unter: http://rdfweb .org/mt/foaflog/archives/000X47.html. (17) http://athena.ics.forth.gr :9090/RDF/ - vgl. auch die Kurzbeschreibung von Powers, Practical RDF (2003), S. 138 ff. (18) Die entsprechende Dokumentation ist online abrufbar unter: http://jena.sourceforge. net/inference/ - das Toolkit selbst unter: http://jena.sourceforge.net/. (19) http://www.ontotext.com/bor/. (20) http://www.sts .tu-harburg.de/~r.f.moeller/racer/. (21) http://jena.sourceforge. net/inference/ - s. bereits oben. (22) Auch die Heranziehung logischer Beweise im Rahmen "semantischer" juristischer Expertensysteme kommt in Betracht. Hierauf kommen wir im Rahmen der Anwendungsvorschläge weiter unten kurz zurück. (23) Einen Ansatz liefert Palmer, The Semantic Web: An Introduction (2001), online abrufbar unter: http://infomesh .net/2001/swintro/#trustAndProof. (24) Vgl. Berners-Lee, Semantic Web Tutorial Using N3: Trust (2003), online abrufbar unter: http://www.w3.org/2000 /10/swap/doc/Trust. (25) http://www.w3.org/Signature/. (26) Siehe das "Trust And Reputation Project": http://trust.mindswap.org/ sowie den zugehörigen Aufsatz von Golbeck/Parsia/Hendler, Trust Networks on the Semantic Web (2003), online abrufbar unter: http://www.mindswap.or g/papers/CIA03.pdf. (27) Der jüngste Trend der online-basierten "social networks" bildet dieses Prinzip auf das Web ab. Beispiele: die Dienste Friendster (http://www.friendster.com/) und Orkut (https://www.orkut.com/). (28) Eine Einführung in SOAP und einen Vergleich zu konkurrierenden Web-Service-Standards wie CORBA, RMI und XML-RPC liefert Küster, Web-Services - Versprechen und Realität, in: Fröschle (Hrsg.), Web-Services (2003), S. 5 (8). (29) WSDL: Web Services Description Language, vgl. nur Wikipedia (http://de.wikipedia.org/wiki/WSDL). (30) UDDI: Universal Description, Discovery and Integration, vgl. nur http://de.wikipedia.org/wiki/UDDI). (31) Vgl. hierzu Teil 2 des Aufsatzes. (32) Hierzu hat das W3C am 22.11.2004 eine "member submission" veröffentlicht: http://w ww.w3.org/Submission/2004/SUBM-OWL-S-2000X122/. (33) Unter http://rdfdata.org werden RDF-Datenangebote gesammelt - eine Rubrik umfasst RDF-basierte Web Services (http://rdfdata.org/data.htm l#websvc), welche z.T. unmittelbar RDF-Daten in RDF/XML oder N3 ausgeben. (34) Auf konkrete Projekte und URLs wird aus Gründen der Aktualität von einigen Ausnahmen abgesehen nicht hier, sondern auf den JuraWiki-Seiten zu dieser Aufsatzreihe verwiesen: http://jurawiki.de/SemanticWeb. (35) Eine Übersicht bietet Dodds, An Introduction to FOAF (2004), online abrufbar unter: http://www.xml.co m/pub/a/2004/02/04/foaf.html. (36) Eine laufend aktualisierte Übersicht wird unter http://rdfdata.org/data.html veröffentlicht (auch in RDF unter: http://rdfdata.org/dat/rdfda ta.rdf). Die derzeit größten Datensammlungen sind der WordNet-Thesaurus (http://www.semanticweb.org/ library/), das dmoz.org-Verzeichnis (http://rdf.dmoz.org/) sowie die Musik-CD-Datenbank musicbrainz (http://www.musicbrainz.org/MM/). (37) Darunter versteht man eine konkrete Anwendung, die einer neuen Technologie zum Durchbruch verhilft. Vgl. hierzu Wikipedia (Stand: 30.01.2005): http://de.wikipe dia.org/wiki/Killerapplikation. (38) http://www.lexml.de/. (39) http://www.lexml.de/rdf.htm . (40) So untersucht Bohrer in seiner Dissertation (Entwicklung eines internetgestützten Expertensystems zur Prüfung des Anwendungsbereichs urheberrechtlicher Abkommen (2003), S. 149 ff.) die Erweiterung eines juristischen Online-Expertensystems um Semantic-Web-Komponenten. Vgl. auch Breuker/Winkels, Use and reuse of legal ontologies in knowledge engineering and information management (2003), online abrufbar unter: http: //www.lri.jur.uva.nl/~winkels/LegOnt2003/Breuker.pdf, sowie Saias/Quaresma, Semantic Enrichment of a Web Legal Information Retrieval System (2002), online abrufbar unter: http://www.jurix.nl/pdf/j02- 02.pdf. (41) Anhand der Ausführungen in Teil 2 der Arbeit müsste klar geworden sein, dass die Adressierung von Ressourcen per URI nicht unbedingt bedeuten muss, dass das Online-Dokument tatsächlich existiert. Daher lassen sich auch "Offline"-Dokumente per URI und damit im Semantic Web beschreiben. (42) Zu einer allgemeinen Kategorisierung juristischer Informationen vgl. nur Schweighofer, Rechtsinformatik und Wissensrepräsentation (1999), S. 18 ff. (43) Kommerzielle Interessen könnten über die Integration von Zertifikats- und Micropayment-Lösungen gewahrt werden; vgl. dazu Walker, The Digital Imprimatur (2003), online abrufbar unter: http://ww w.fourmilab.ch/documents/digital-imprimatur/ (Abschnitt: "Certificates"). (44) Siehe hierzu Teil 1 des Aufsatzes. (45) Den Thesaurus-Ansatz verfolgt das bereits in Teil 1 des Aufsatzes angesprochene WordNet-Projekt: http://www.cogsci.princeto n.edu/~wn/ (RDF-Daten: http://www.semanticweb.org/ library/). (46) Vgl. den Vortrag von Schweighofer im Rahmen der Saarbrücker eJustice Dialogues am 4. Juli 2004 (http: //rechtsinformatik.jura.uni-sb.de/ejustice/info.html) - die Folien sind abrufbar unter: http://rechtsinformatik.jura.uni-sb.de/ejustice/vortrag_schw eighofer.ppt. (47) Die Methodik richtet sich nach dem Vorschlag von Saias/Quaresma, Semantic Enrichment of a Web Legal Information Retrieval System (2002), online abrufbar unter: http://www.jurix.nl/pdf/j02- 02.pdf. (48) Z.B. im SchemaWeb-Projekt: http://www.schemaweb.info/. |
| *
Der Autor ist Diplom-Jurist und Doktorand am Institut für Rechtsinformatik
der Universität des Saarlandes. Im Rahmen seiner Promotion, betreut von
|
| [online seit: 27.05.2005 ] |
| Zitiervorschlag: Autor, Titel, JurPC Web-Dok., Abs.
|
| Zitiervorschlag: Notholt, Jochen, Die Zukunft des Semantic Web (Teil 3 und Schluss) - JurPC-Web-Dok. 0066/2005 |
