Jusletter IT

Die Servicebeschreibungssprache USDL, welche im THESEUS/TEXO-Projekt entstanden ist, stellt umfangreiche Möglichkeiten zur funktionalen und nicht-funktionalen Beschreibung von Web Services zur Verfügung.

Um eine möglichst große praktische Einsetzbarkeit zu gewährleisten, wurde auf eine strukturierte, XML-basierte Modellierung ohne semantische Informationen gesetzt. Diese werden jedoch benötigt, um die in USDL beschriebenen Dienste mit Hilfe einer ebenfalls im TEXO-Projekt entstandenen Datenschutzontologie nach datenschutzrechtlichen Kriterien zu überprüfen.

In dieser Arbeit wird daher, wie in Abbildung 1 gezeigt, eine semantische Schicht oberhalb von USDL entwickelt, die Sachverhaltsontologie (SVO), welche basierend auf Begriffen aus der Service-Theorie die nötigen Informationen enthält, um ein automatisches Matching mit der Datenschutzontologie durchführen zu können. Bevor die eigentliche Arbeit vorgestellt wird, werden in diesem Kapitel die zwei grundlegenden Bausteine beschrieben, auf denen der Ansatz basiert: Auf der einen Seite steht die Formalisierung des Rechts in Form der TEXO-Datenschutzontologie, auf der anderen Seite die USDL-Servicebeschreibung.

Die Universal Service Description Language (USDL)¹ wurde im Rahmen des THESEUS/TEXO-Projektes entwickelt, um eine umfassende Beschreibungsmöglichkeit für Services zur Verfügung zu stellen. Unter dem Begriff „Service“ werden dabei sowohl klassische Web Service verstanden, als auch elektronisch beauftragte, aber manuelle ausgeführte Dienstleistungen wie ein Mietwagenservice. Der Fokus von USDL lag dabei auf der praktischen Anwendbarkeit der Beschreibungssprache, sodass statt eines semantischen ein strukturierter, XML-basierter Ansatz gewählt wurde.

In dieser Arbeit nehmen die USDL-Servicebeschreibungen die Rolle des Sachverhalts ein, welcher nach rechtlichen Aspekten, insbesondere dem Datenschutzrecht, beurteilt wird. USDL wurde für diesen Zweck ausgewählt, da es durch seinen umfassenden Ansatz einen genügend großen Informationsgehalt besitzt. Im Folgenden sollen die Kernpunkte von USDL beschrieben werden, insbesondere im Hinblick auf den Einfluss auf die in dieser Arbeit vorgestellten semantischen Erweiterungen.

• Funktionale und nicht funktionale Attribute. USDL beinhaltet sowohl die nichtfunktionalen Attribute eines Services wie Preisinformationen, QoS Parameter oder administrative Daten als auch die funktionalen Attribute, also die Schnittstellenbeschreibung. Diese liegt in abstrakter Form vor, so dass eine Implementierung nach verschiedenen Standards, z.B. WSDL oder REST, möglich ist.
• Modularität. Um die Komplexität der Sprache zu begrenzen wurde ein modularer Ansatz gewählt, bei dem das Beschreibungsschema in thematisch klar abgegrenzte Bereiche unterteilt wurde, welche jeweils von Domainexperten modelliert wurden. Beispiele für diese Module sind das Preismodul, das technische Modul oder das Interaktionsmodul.
• Erweiterbarkeit. Ein weiterer Vorteil der Modularisierung ist die einfache Erweiterbarkeit um neue Module. Diese können der Sprache hinzugefügt werden, ohne den bisherigen Stand zu ändern.
• Standardisierung. Um eine breite und langfristige Unterstützung von USDL zu sichern, wurde USDL beim W3C zur Standarisierung eingereicht. Derzeit besitzt USDL den Status eines Incubators.2

 

Für den praktischen Einsatz ist es neben diesen Eigenschaften wichtig, dass mit dem USDL Editor eine leistungsfähige, benutzerfreundliche Modellierungsumgebung vorliegt. Des Weiteren existiert mit dem TEXO Service Marketplace³ eine Plattform, auf welcher die in USDL beschriebenen Services gehandelt werden können.

 

Die Datenschutzontologie wurde, wie auch USDL im Rahmen des THESEUS/TEXO-Projekts entwickelt und dient als Referenzontologie für das automatisierte Matchmaking mit der in dieser Arbeit erstellten Sachverhaltsontologie.

In der TEXO-Datenschutzontologie wurden ausgewählte Teile des Bundesdatenschutzgesetztes (BDSG) formalisiert. Als Sprache kam dabei F-Logic⁴ zum Einsatz, welches sich optimal zur Umsetzung der regelartigen Struktur der Rechtssätze eignet.

Die Erstellung der Ontologie orientierte sich an der LEL-Methodik⁵ , welche die Modellierung in zwei Phasen unterteilt. Im ersten Schritt werden alle zu formalisierenden Begriffe gesammelt und mit Zusatzinformationen angereichert in eine strukturierte Form gebracht. Erst im zweiten Schritt wird daraus die eigentliche Ontologie erstellt.

Im Falle der Datenschutzontologie wurden in diesen Zwischenschritt Informationen über die Beziehungen der Begriffe untereinander (z.B. Ober/Unterbegriffe) sowie semantische Metainformationen (Ontoclean Tags sowie DOLCE-Kategorien) hinzugefügt.

Auf diese Art wurde eine Ontologie erstellt, deren Größe ausreichend für eine aussagekräftige Evaluation der hier gezeigten semantischen USDL-Erweiterung ist. Ein Ausschnitt der Datenschutzontologie ist in Abbildung 2 gezeigt.

Aufbauend auf den zuvor dargelegten Grundlagen wird in diesem Kapitel der eigentliche Kern der Arbeit, die Sachverhaltsontologie, sowie deren Anwendung auf die USDL-Beschreibungssprache beschrieben. Anschließend wird durch die beispielhafte Erweiterung von ausgewählten USDL-Attributen das Verfahren in der Praxis gezeigt.

Zunächst werden jedoch die Anforderungen erläutert, welche die SVO erfüllen muss.

Wie schon in der Einleitung beschrieben, ist der Hauptzweck der SVO die Erweiterung der Servicebeschreibungssprache USDL um Informationen, die eine automatische rechtliche Beurteilung mit Hilfe einer Formalisierung von Gesetzen ermöglicht. Daraus ergibt sich unmittelbar die erste Anforderung:

• (A1) Die SVO muss in ihrer Implementierung, also Sprache und Struktur, kompatibel zur vorhandenen Datenschutzontologie sein.
• (A2) Die SVO muss sich in die USDL-Servicebeschreibung integrieren lassen. Dabei ist insbesondere zu beachten, dass zwischen den Klassen der SVO und den USDL-Attributen N:M-Beziehungen bestehen können.

Neben diesen grundlegenden Anforderungen ergeben sich weitere, durch den Anwendungszweck motivierte Punkte, die bei der Modellierung beachtet werden müssen:

• (A3) Eine hohe Qualität der Ontologiemodellierung muss sichergestellt werden. Dazu zählen auch die Überprüfbarkeit sowie die Nachvollziehbarkeit der Ontologieerstellung.
• (A4) Die Modellierung muss alle relevanten Begriffe des aktuellen Standes der Service Science enthalten.
• (A4) Die modellierten Begriffe sind inhaltlich unabhängig von einem bestimmten Rechtsgebiet, um die allgemeine Einsetzbarkeit der Ontologie zu gewährleisten.

Da es sich bei der Datenschutzontologie um die Formalisierung des deutschen BDSG handelt, wurde für die SVO Deutsch als Sprache gewählt, englische Fachbegriffe wurden übersetzt.

Bevor die eigentliche Ontologie vorgestellt wird, werden die grundlegenden Designentscheidungen erläutert, welche sich direkt aus den zuvor aufgestellten Anforderungen ergeben.

Die größte Rolle dabei spielt die Sprache, in welcher die Ontologie modelliert wird. Sie bestimmt die Möglichkeiten, welche dem Modellierer bei der Erstellung der Ontologie zur Verfügung stehen sowie die möglichen Anwendungsgebiete. Aus Anforderung A1 ergibt sich direkt, dass für die SVO die gleiche Sprache wie für die in Kapitel REF _Ref313967632 \r \h 1.2. vorgestellte Datenschutzontologie verwendet werden muss, das schon in diesem Kapitel vorgestellte F-Logic. Die Wahl dieser Sprache stellt für die geforderte Qualität und Funktionalität der Modellierung keine Einschränkungen dar, es liegen mit OntoStudio sowie Ontobroker eine ausgereifte Entwicklungsumgebung sowie ein Reasoner vor, welche im Rahmen dieser Arbeit verwendet werden.

Eine weitere Entscheidung, welche sich aus Anforderung A2 ergibt, betrifft die Integration mit USDL. Hierbei muss zunächst geklärt werden, in welcher Richtung (also USDL --> SVO und/oder SVO <-- USDL) Verweise angelegt werden müssen.

Um diese Entscheidungen treffen zu können, müssen die Anforderungen untersucht werden, welche sich aus dem Hauptzweck der SVO ergeben, dem automatischen Matchmaking mit der Datenschutzontologie. Dieses Matching findet auf der Ebene der SVO statt, somit werden zu den gefundenen Treffern Verweise auf die entsprechenden Attribute in der USDL-Servicebeschreibung benötigt.

Um diese Verweise zu realisieren wurde in der Ontologie die Klasse „USDL_Ref “ angelegt, welche die URI eines USDL-Attributes enthält und über die Relation „besitzt_Referenz“ an jede Klasse der SVO gehängt werden kann.

Als Kardinalität wurde dabei festgelegt, dass sich eine Klasse der SVO auf mehrere USDL-Attribute beziehen kann und auch umgekehrt ein USDL-Attribut unter mehreren Klassen hängen kann. Es handelt sich also um eine echte N:M-Beziehung.

Neben den oben getroffenen, eher technischen Entscheidungen betreffen die Anforderungen A3 sowie A4 den Modellierungsprozess.

Dieser beginnt mit der Auswahl der zu modellierenden Begriffe, welche im Falle der SVO aus der einschlägigen Literatur zu theoretischen Grundlagen von Web Services bzw. Services im Allgemeinen stammen. Insbesondere wurde auf den Artikel „Towards an ontological foundation for services Science“⁶ zurückgegriffen, welcher explizit die ontologischen Grundlagen von Services zum Thema hat. Neben diesem Artikel dienten „A research manifesto for services science“⁷ , sowie „Countering service information challenges in the internet of services“⁸ als Grundlagen für eine Liste von 98 Begriffen, welche in der SVO als Klassen modelliert wurden. Daneben wurden weiter Informationen, wie zum Beispiel der Name des USDL-Moduls des jeweiligen Attributes in die Ontologie aufgenommen.

Die Methodik der Erstellung orientierte sich an der LEL-Methode. Wie in Kapitel REF _Ref313967632 \r \h 1.2. beschrieben, wurde im ersten Schritt eine Liste von relevanten Begriffen aus der oben genannten Literatur zur Service-Theorie erstellt. Zu jedem Begriff in dieser Liste wurden im nächsten Schritt zusätzliche Daten hinzugefügt, vor allem Relationen zwischen den Begriffen. Daneben wurden, wie auch schon in der Datenschutzontologie, DOLCE-Kategorien für die Begriffe festgelegt.

Aus diesem strukturierten Zwischenschritt wurde abschließend mit Hilfe des Ontologieeditors OntoStudio eine F-Logic-Ontologie erstellt.

Wie erwähnt wurde DOLCE⁹ als Grundlagenontologie verwendet. Dies ist eine direkte Konsequenz, die sich sowohl aus Anforderung A1 als auch aus Anforderung A3 ergibt. DOLCE wird auch in der Datenschutzontologie verwendet und kann somit einen wichtigen Beitrag zum geplanten Matching leisten. Des Weiteren verbessert die Einordnung der Begriffe aus der SVO unter DOLCE die Qualität der Modellierung, da sich durch eine solche Zuordnung bereits Fehler erkennen lassen, wenn z.B. Unterklasse und Oberklasse unter verschiedenen DOLCE-Kategorien eingeordnet werden können.

Interessant bei der Verwendung von DOLCE ist die technische Umsetzung. Da DOLCE in OWL vorliegt, musste ein Weg gefunden werden, die Ontologie dennoch in der F-Logic-basierten SVO zu verwenden.

Da sowohl in der Datenschutzontologie als auch in der SVO nur die Kategorisierung durch DOLCE verwendet wird, nicht aber die Beziehungen der Klassen untereinander, wurde die Integration über eine Umsetzung der untersten DOLCE-Klassen nach F-Logic realisiert. Diese wurde manuell erstellt und ist auch ausreichend für eine spätere Verwendung in der Matchmaking-Komponente.

Nachdem die grundlegenden Entscheidungen bei der Erstellung der Ontologie motiviert und beschrieben worden sind, sollen im Folgenden die wichtigsten Klassen und Relationen der SVO vorgestellt werden.

• Teilnehmer. An einem Serviceprozess nehmen unterschiedliche Teilnehmer in unterschiedlichen Rollen teil. Ein Teilnehmer kann sowohl ein Unternehmen als auch eine natürliche Person sein. Nach Guarino existieren vier Unterklassen von Teilnehmern, welche auch so in der SVO modelliert sind: Service-Produzent, Service-Anbieter, Service-Kunde und Service-Verbraucher. Dabei kann ein Teilnehmer gleichzeitig verschiedene Rollen einnehmen, z.B. Kunde und Verbraucher. Die Klasse Teilnehmer sowie ihre Unterklassen sind wichtig für die datenschutzrechtliche Beurteilung, sowohl, was ihre Art (natürliche oder juristische Person) betrifft als auch die Beziehung zueinander (z.B. Serviceaufruf innerhalb einer Firma).
• Service-Lokation. Die Klasse Lokation bezieht sich auf einen geographischen Standort und wird für das Servicemodell in verschiedenen Ausprägungen verwendet, welche sich an den oben beschriebenen Teilnehmern orientieren.
• Serviceprozess. Die Klasse Serviceprozess dient als Sammelklasse, unter der die einzelnen Prozesschritte (z.B. Serviceerstellung oder Serviceaufruf) der Service-Lebenszyklus untergeordnet werden (Relation „ist_Teil_von''. Diese Schritte sind wiederum eng verknüpft mit den oben beschriebenen Klassen Lokation und Teilnehmer.

Diese drei hier vorgestellten Klassen geben bereits einen guten Einblick in den Aufbau und Inhalt der SVO. Entsprechend den Anforderungen, welche sich aus der automatischen Rechtsfolgenermittlung ergeben, wird die Ontologie laufend erweitert und angepasst.

In dieser Arbeit wurde beschrieben, wie eine vorhandene, nicht-semantische Servicebeschreibungssprache um semantische Informationen erweitert werden kann, um ein automatisches Matchmaking mit einer Datenschutzontologie durchzuführen. Für die sogenannte Sachverhaltsontologie wurden Begriffe aus der Service-Theorie sowie DOLCE als Grundlagenontologie verwendet.

Zukünftige Arbeiten werden sich folglich mit dem eigentlichen Matchmaking der beiden Ontologien befassen, um zu evaluieren, inwieweit eine automatische rechtliche Subsumtion mit Hilfe semantischer Technologien möglich ist, wenn sowohl die Sachverhalts- als auch die Tatbestandsebene semantisch modelliert vorliegen.

Dies kann nicht nur mit der oben beschriebenen Datenschutzontologie erfolgen, sondern auch mit anderen Rechtsontologien, sofern sie dasselbe Format besitzen.