Anbindung eines Ontologie- basiertes Risikomanagement- systems an eine XML-Datenbank...

Anbindung eines Ontologie-basiertes Risikomanagement-

systems an eine XML-Datenbank

Datenbankseminaram Lehrstuhl für Praktische Informatik III

Vortrag von Tilo Dickopp

Agenda

• Überblick „JOntoRisk“-Projekt• Ein XPath-basierter Reasoner • Ausblick

3 / 27

Einführung

• Entwicklung einer Plattform zur Unterstützung des Risikomanagement-Prozesses: „JOntoRisk“

• Integration bestehender Tools und externer Quellen (z.B. Schadensdatenbanken)

JOntoRisk Einführung

RisikomanagementAnforderungenStandard-APIsNachteileArchitekturOntologieOntology-Views

XPath-Reasoner

Ausblick

4 / 27

Risikomanagement

• Banken und andere Finanzdienstleister sind gesetzlich gezwungen ihre Risiken zu managen.

• Ein solches Risikomanagement kann in einem Prozess mit drei Phasen verwirklicht werden:

Identifikation

Messen

Steuerung /Maßnahmen

Riskoumgebung

Abgleich

QuantitativesVerstehen

JOntoRiskEinführung

RisikomanagementAnforderungenStandard-APIsNachteileArchitekturOntologieOntology-Views

XPath-Reasoner

Ausblick

5 / 27

Anforderungen

(1) Jede Phase des Risikomanagement-Prozesses soll durch ein Tool unterstützt werden. Mindestens:

– Self-Assesment während der Identifikation (Textanalyse analog zu Abbot)

– Simulation zum Messen des Risikoausmaßes– Plausibilitätsabglich mit Schadensdatenbanken

(2) Ontologie, die das Unternehmen aus Risikosicht beschreibt, als gemeinsame Datenbasis

(3) Manche der Tools sollen auf mobilen Clients laufen (z.B. währende Besprechung eines Zinsrisikos mit einem Kunden).

(4) …

JOntoRiskEinführungRisikomanagement

AnforderungenStandard-APIsNachteileArchitekturOntologieOntology-Views

XPath-Reasoner

Ausblick

6 / 27

Architektur mit Standard APIs

Clients

Server /Reasoner

Somit bietet sich folgende Architektur an:

Ontologie

Unter Verwendung von Standard APIs zur Ontologieverarbeitung, wie „Jena“, würde das z.B. heißen:

J2ME(mobiler Client)

J2SE / Jena

Relationale DB

Middleware

JDBC

Ontologie als Jena-Objekte

Ontologie als Jena-Objekte

JOntoRiskEinführungRisikomanagementAnforderungen

Standard-APIsNachteileArchitekturOntologieOntology-Views

XPath-Reasoner

Ausblick

7 / 27

Nachteile der Architektur mit Standard APIs

• Standardbibliotheken zu groß für mobile Endgeräte (Jena: 2,5mb; obfusicated 1,7mb).

• Bruch in der Darstellungsform: Relationen, Jena-Objekte, IDL/CDR-Darstellung, …

• Ständiges Anlegen von Java-Objekten teuer.• Schwergewichtig. • Kommt nicht ohne dedizierte Server-

komponente. Somit nicht umsetzbar:

JOntoRisk

XML DB

JOntoRiskEinführungRisikomanagementAnforderungenStandard-APIs

NachteileArchitekturOntologieOntology-Views

XPath-Reasoner

Ausblick

8 / 27

Umgesetzte Architektur

In JOntoRisk verwenden wir deshalb eine davon abweichende Architektur:

JOR-Client

JOR-Server

XML DB

WS / XML-Streams

nativer Treiber (verarbeitet XPath)

Ontologie in OWLReasoning mit XML-Technologien

Ontologie in OWL oder eigene Darstellung

Ontologie in OWL(z.Z. Infonyte)

Können zusammenfallen.

JOntoRiskEinführungRisikomanagementAnforderungenStandard-APIsNachteile

ArchitekturOntologieOntology-Views

XPath-Reasoner

Ausblick

9 / 27

Ausschnitt aus der Ontologie

Resource

Random

Property

Process

Human

Technology

Integrity

Availability

Security

Correctness

Timeliness

Completeness

InBudget

InTime

InQuality

Project

IT

System

Effect

Payment

Deprication

Missed

Gain

Loss

Activity BusinessLine

Costcauses

exhibits

enables

maps

generates

behaves

influences

formsdepends

JOntoRiskEinführungRisikomanagementAnforderungenStandard-APIsNachteileArchitektur

OntologieOntology-Views

XPath-Reasoner

Ausblick

10 / 27

Ontology-Views

Ontologie

Client 1

Client 2

Brücke 1

Clients haben eine abweichende Sicht auf das Unternehmen. Diese Sichten werden durch sog. Ontology-Views erzeugt:

View 1

Legacy-Tool 1

View 2

View 3

JOntoRiskEinführungRisikomanagementAnforderungenStandard-APIsNachteileArchitekturOntologie

Ontology-Views

XPath-Reasoner

Ausblick

11 / 27

Ontology-Views

• Als Beispiel einige Definitionen aus dem View für die Simulationskomponente (nach Kühn/Neu) in Description Logic:

Asset System

Riskfactor IT Project

State Property behaves.Random

…

• In JOntoRisk werden die Views nicht in DL sondern in der OWL formuliert!

JOntoRiskEinführungRisikomanagementAnforderungenStandard-APIsNachteileArchitekturOntologie

Ontology-Views

XPath-Reasoner

Ausblick

12 / 27

Anforderungen

(1) Der Reasoner muss in der Lage sein, die verwendeten Ontology-Views umzusetzen.

(2) Er soll eine deklarative Anfragesprache zum Zugriff auf das DB-Repository benutzen.

JOntoRisk

XPath-Reasoner Anforderungen

RegelnAblaufBeispielStrukturVorbereitungMerger

Ausblick

13 / 27

b

Regeln

Der Reasoner benutzt Regeln, wie zum Beispiel:

a) Prämisse: Konjunktiv verknüpfte Formeln.Bezeichnung: Für eine Regel r bezeichnen r1,…,rn die einzelnen Formeln. Bsp.: r2=„oC2“

b) Konsequenz: Schlussfolgerbares Wissen, wenn die Prämisse wahr ist. Bezeichnung: rneu

C1C2 oC2

oC1

a C1C2 R.C3 oC2 C3, oR

oC1

JOntoRisk

XPath-Reasoner Anforderungen

RegelnAblaufBeispielStrukturVorbereitungMerger

Ausblick

14 / 27

Ablauf

Definition: Eine Substitution einer gegebenen Formel f bezeichnet eine Ersetzung aller in f vorkommenden Variablen durch Ausdrücke, die keine Variablen enthalten.

Ablauf:

Ausgabe = {}FÜR jede Regel r {

FÜR jedes mit {(r1), …, (rn)}OWL-Daten { Ausgabe = Ausgabe {(rneu)}

}}

JOntoRisk

XPath-Reasoner AnforderungenRegeln

AblaufBeispielStrukturVorbereitungMerger

Ausblick

15 / 27

Beispiel

Anwenden der Regel auf das

vereinfachte OWL-Dokuement:

C1C2 oC2

oC1

…<owl:Class rdf:ID="System"> <rdfs:subClassOf rdf:resource="#Technology"/>…</owl:Class>…<owl:Class rdf:ID="Asset"> <owl:equivalentClass rdf:resource="#System"/>…</owl:Class>…<jor:System rdf:ID="HAL9000">…</jor:System>…

JOntoRisk

XPath-Reasoner AnforderungenRegelnAblauf

BeispielStrukturVorbereitungMerger

Ausblick

16 / 27

Beispiel

Schritt 1: Suche nach „C1C2“

Werte dazu den folgenden XPath-Ausdruck aus:

//owl:Class[owl:equivalentClass]


JOntoRisk



Ausblick

17 / 27

Beispiel

Schritt 2: Binden der Variablen C1 und C2:


$C1 ./@rdf:ID$C2 .//owl:equivalentClass/@rdf:resource

JOntoRisk



Ausblick

18 / 27

Beispiel

Schritt 3: Wenn in den Schritten 1 und zwei alle Variablen gebunden wurden, suche nach „ oC2“:

//$C2 wird zu //jor:System


JOntoRisk



Ausblick

19 / 27

Beispiel

Schritt 4: Binden der Variablen o:


$O .

JOntoRisk



Ausblick

20 / 27

$O$C2

Beispiel

Schritt 5: Erzeugen der Ausgabe mittels eines Templates:

<{$C1} rdf:ID="{$O/@rdf:ID}"> {$O/*}</{$C1}>

<jor:Asset rdf:ID="HAL9000"> …</ jor:Asset>

…<owl:Class rdf:ID="Asset"> <owl:equivalentClass rdf:resource="#System"/>…</owl:Class>…<jor:System rdf:ID="HAL9000">…</jor:System>…

$C1

JOntoRisk



Ausblick

21 / 27

Struktur des Reasoners

originalOntologie

gefolgertesWissen

Merger

Regeln

Reasoning-Kern

Vorbereitung

JOntoRisk

XPath-Reasoner AnforderungenRegelnAblaufBeispiel

StrukturVorbereitungMerger

Ausblick

22 / 27

Vorbereitung

• Einschränkungen des Reasoners:– nur online– kein rekursives Anwenden von Regelnentworfen für Anfragen der Art: „Gib mir alle

Individuen der Klasse X.“

• Wenn zusätzlich keine Änderungen am Schema erlaubt sind, kann die Laufzeit optimiert werden:– Pruning der Regelmenge– Cachen der Werte von Variablen in

Formeln, die sich auf das Schema beziehen

JOntoRisk

XPath-Reasoner AnforderungenRegelnAblaufBeispielStruktur

VorbereitungMerger

Ausblick

23 / 27

Merger

<jor:System rdf:ID="HAL9000"> <jor:Completeness rdf:resource="#i1"/> </jor:System>…<jor:Asset rdf:ID="HAL9000"> <jor:Formula>NormalDist(0,1)<jor:Formula></jor:Asset>

<jor:Asset rdf:ID="HAL9000"> <jor:Completeness rdf:resource="#i1"/> </jor:Asset>

<jor:Asset rdf:ID="HAL9000"> <jor:Completeness rdf:resource="#i1"/> <jor:Formula>NormalDist(0,1)<jor:Formula></jor:Asset>

Reasoner

Merger

JOntoRisk

XPath-Reasoner AnforderungenRegelnAblaufBeispielStrukturVorbereitung

Merger

Ausblick

24 / 27

Ideen für Erweiterungen

(1) Gefolgertes Wissen speichern (+ truth maintenance).

(2) Transitiv folgerbares Wissen.(3) Regeln nicht mehr von Hand implementieren,

sondern in deklarativer Sprache definieren (angelehnt an OWL abstract Syntax).

(4) Anfrageschnittstelle generalisieren (zum Beispiel OWL-QL).

(5) Regeln in XQuery umsetzen.

Für JOntoRisk wird vermutlich nur noch Idee (3) umgesetzt.

JOntoRisk

XPath-Reasoner

Ausblick Ideen

XQuery

25 / 27

XQuerydeclare namespace rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"declare namespace owl="http://www.w3.org/2002/07/owl#"declare namespace jor="http://www.jontorisk.org/jontorisk.owl";

for $R1 in //owl:Class[owl:equivalentClass]let $C1 := $R1/@rdf:IDlet $C2 := fn:concat('jor:', fn:substring-after($R1//owl:equivalentClass/@rdf:resource, '#'))for $R2 in //*[name()=$C2]let $O := $R2return element{$C1}{attribute rdf:ID {$O/@rdf:ID}, $O/*}

JOntoRisk

XPath-Reasoner

AusblickIdeen

XQuery

26 / 27

XQuerydeclare namespace rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";declare namespace owl="http://www.w3.org/2002/07/owl#";declare namespace jor="http://www.jontorisk.org/jontorisk.owl";

for $R1 in //owl:Class[owl:equivalentClass]let $C1 := $R1/@rdf:IDlet $C2 := fn:concat('jor:', fn:substring-after(

$R1//owl:equivalentClass/@rdf:resource, '#'))for $R2 in //*[name()=$C2]let $O := $R2return element{$C1}{attribute rdf:ID {$O/@rdf:ID}, $O/*}

JOntoRisk

XPath-Reasoner

AusblickIdeen

XQuery

Anbindung eines Ontologie- basiertes Risikomanagement- systems an eine XML-Datenbank...

Documents

Transcript of Anbindung eines Ontologie- basiertes Risikomanagement- systems an eine XML-Datenbank...