Wir hatten das letzte Mal uns unterhalten über formale Semantik für RDF-S, also RDF und RDF-S. Aber ich möchte noch mal kurz quasi einen Rundumschlag machen, was wir denn bisher schon können und womit es jetzt eigentlich weitergeht. Wenn wir uns zurückerinnern, wir hatten als allererstes kennengelernt, um irgendwelche Dinge im Semantikweg adressieren zu können und um da irgendwelche Aussagen über Dinge zu machen,

brauchen wir einen Identifikator, der möglichst eindeutig ist. Dafür haben wir URIs hergenommen, gibt es ja schon im Web, kein Problem. Wenn wir die Dinge identifizieren können, müssen wir darüber auch irgendwas sagen können. Das heißt, wir müssen das, was wir darüber die Dinge sagen, in irgendeiner Art und Weise kodieren, mit einer einheitlichen Kodierung. Dafür haben wir XML hergenommen und das Hin und Her schicken von diesen Nachrichten oder Wissensrepräsentationen dann am Ende.

Dafür haben wir ganz einfach die im Web vorhandenen Transfermechanismen, nämlich das HTTP-Protokoll, hergenommen. So weit so gut. Wir hatten festgestellt, mit XML kann ich zwar schöne syntaktische Strukturen aufbauen, in denen steckt aber so gut wie keine, zumindest für uns nutzbare Semantik, die irgendwie für die Wissensrepräsentation von Vorteil wäre.

Deshalb haben wir dann gleich als erstes RDF und RDFS kennengelernt, wobei das nichts anderes ist als quasi ein bestimmtes XML-Vokabular, dem eine ganz bestimmte minimale Semantik mitgegeben worden ist, die wir hier auch formalisiert haben. Und da ging es darum, eben Zusammenhänge zwischen einzelnen Objekten, zwischen Klassen irgendwie formulieren zu können,

Klassenhierarchien aufzubauen, Property-Hierarchien aufzubauen und Ähnliches. Und eben über diese formale Semantik rudimentäre Regeln zu bekommen, wie ich eben Schlussfolgern kann. Schlussfolgerungen ziehen, dient eben bei uns dazu, auf der einen Seite implizit vorhandenes Wissen explizit zu machen,

also Wissen irgendwie zu bergen. Das Verborgen liegt in dem, was wir bisher schon haben, und eben um überprüfen zu können, ob Schlussfolgerungen korrekt oder nicht korrekt sind. Wir hatten dann festgestellt, wir brauchen natürlich ausdrucksmächtigere Dinge als das, was wir hier mit RDF und RDFS machen können und hatten uns dann mal angeguckt, ja, es gibt ja noch die Logik.

Alles basiert ja hier irgendwie auf der Logik. Das haben wir auch auf einen ganz bestimmten Grund gemacht. Also wir hatten uns erst die Aussagenlogik, dann die Prätikatenlogik angeguckt. Die Aussagenlogik hatten wir festgestellt, ist relativ unhandlich bzw. für das, was wir machen wollen, ungeeignet, weil ich muss eben über jedes explizit statische Ding kann ich zwar Aussagen treffen, allerdings kann ich keine Gruppen zusammenfassen,

also so aggregierte Aussagen und sowas. Dafür reicht die nicht. Ich schreibe also sehr, sehr viel und habe in diesen atomaren Aussagen nur relativ wenig Raum, um tatsächlich Semantik drin unterzubringen. Besser dazu geeignet war dann die Prätikatenlogik, mit denen ich Gruppen von Dingen zusammenfassen kann, Aussagen über Gruppen machen kann, Prätikate einführen kann, deren Wahrheitsgehalt ich testen kann.

Also die ist schon ausdrucksstark genug für das, was wir vorhatten. Und dann hatten wir kennengelernt, wenn wir damit tatsächlich dann automatisch arbeiten wollen, dann brauchen wir natürlich Verfahren, die irgendwie in der Lage sind, die Semantik von diesen Logiken quasi zu verstehen

und darauf aufbauend valide Schlussfolgerungen zu ziehen. Wir hatten das kennengelernt über die modelltheoretische Semantik, die von Tarski eingeführt worden ist. Und die modelltheoretische Semantik ist ein ganz wichtiges Ding, weil die versetzt uns nämlich in die Lage, dass wir in einer Interpretation oder was die Semantik angeht, nicht alle möglichen Interpretationen,

die quasi klappen könnten, untersuchen, sondern eben alles auf ein einziges oder ein mögliches Modell abbilden und dann auf Basis dieses Modells sind wir in der Lage, syntaktische Regeln anzuwenden, deren Korrektheit natürlich formal bewiesen werden muss. Und mit Hilfe dieser syntaktischen Regeln, die auf dem Modell basieren, kann ich dann hergehen

und kann Schlussfolgerungen ziehen anhand meiner Aussagen, die ich mit der Logik getroffen habe, beziehungsweise kann überprüfen, ob die formal korrekt oder nicht korrekt sind. Einfach indem ich es runterbreche auf die syntaktische Ebene, damit der Rechner damit auch einfach arbeiten kann oder wir einfach mitarbeiten kennen können. Und da hatten wir zwar einfache Verfahren kennengelernt,

mit denen man die Korrektheit von Schlussfolgerungen prüfen kann. Das eine war die Resolution, kannten Sie schon aus der Basisvorlesung, und dann auch noch das Tableauverfahren, das ein bisschen effizienter arbeitet als die Resolution jetzt an sich. Das hatten wir kennengelernt für die Aussagenlogik, für die Prädikatenlogik erster Stufe hatten wir es kennengelernt.

Und wir hatten uns dann gefragt, ja, die Prädikatenlogik ist schön und gut, können wir die irgendwie mit ins Symantikweb reinbringen? Sie hat einen entscheidenden Nachteil. Sie ist relativ aussagekräftig. Es gibt sehr, sehr viele Möglichkeiten, bei der Modellierung dasselbe auszudrücken. Deshalb ist es sehr kompliziert, sich immer auf das Richtige zu einigen.

Und deshalb werden auch die Algorithmen, mit denen ich Gleichheit und Ähnliches überprüfen kann, sehr komplex, so komplex, dass sie gar nicht mehr entscheidbar sind am Ende. Das ist eben das Problem bei der Prädikatenlogik. Und deshalb hat man versucht eben ein Zwischending zu finden, quasi abzuschwächen, die Prädikatenlogik hin zur sogenannten Beschreibungslogik oder den Beschreibungslogik kennen,

die eben quasi sehr, sehr ausdrucksstark sind, aber auf der anderen Seite immer noch berechenbar, das heißt handhabbar sind. So und das ist eigentlich das, wo wir dann letztendlich hinwollen. Für die Beschreibungslogiken haben wir auch Symantik kennengelernt. Für die einfachste Beschreibungslogik, die man hier verwenden kann, für ALC, hatten wir uns die Symantik angeguckt.

Und dann hatten wir auch ein Verfahren kennengelernt, mit der wir dort Schlussfolgerungen ziehen und überprüfen können, nämlich das Tableauverfahren, das wir mit einem Trick quasi so weit bringen mussten, dass es dann auch tatsächlich endet. Ja und jetzt sind wir an dem Punkt angelangt, wo wir uns fragen müssen, ja, schön und gut, die Beschreibungslogik,

wie kriegen wir die jetzt in Symantikweb mit rein? Das ist ja auch eine ganz andere Notation, Schreibweise oder sonst was im Vergleich zu dem RDF und RDFS. Wir hatten ja irgendwie am Anfang so ein Layer-Modell und das soll alles irgendwie aufeinander aufbauen. Das heißt, ich muss irgendwie, wenn es geht, RDF, RDFS und auch die Beschreibungslogik gemeinsam verarbeiten können.

Und dafür werden wir eben heute kennenlernen hier bei den Sprachen der Symantikweb. Die nächste quasi Ebene, in der jetzt AOL angesiedelt ist, die Web Ontology Language und deren Symantik. Das nächste Mal werden wir auch noch die Erweiterung oder die neueste Variante davon betrachten, AOL 2.

Da kommt noch mal ein bisschen was dazu, wird noch ein bisschen aussagekräftiger, ausdrucksstärker und man unterscheidet noch mehrere unterschiedliche Varianten, aber dazu später mehr. Heute also geht es weiter mit AOL, der Web Ontology Language und wir werden als erstes mal uns eine kurze Übersicht verschaffen. Was ist das überhaupt? Wir werden uns die Syntax anschauen.

Ich werde Ihnen, das ist nicht allzu viel, ein bisschen was an Werkzeugen zeigen, was da ist. Und wir werden uns natürlich dazu auch die Symantik betrachten müssen, weil, genauso wie bei RDFS, muss natürlich auch AOL auf einer validen Symantik basieren, damit wir damit tatsächlich auch arbeiten können. Das heißt, wir müssen das irgendwie abbilden auf eine Beschreibungslogik, die wir kennen, deren Symantik wir schon gezeigt haben, um damit tatsächlich Schlussfolgerungen valide ziehen zu können.

Okay, stürzen wir uns mitten rein. Die erste Frage, die sich jedem stellt, warum heißt das Ganze AOL und nicht WOL, wenn das Ganze schon Web Ontology Language heißt. Da gibt es wie immer mehrere Erklärungen, keine davon ist irgendwie ganz richtig. Die schönste Anekdote, die es dazu gibt, die ist verband mit diesem Kinderbuch Winnie the Pooh von einem Herrn namens Mayan.

Da drin gibt es, wer von Ihnen kennt Winnie the Pooh? Die Geschichten von diesen Bären ist auch von Disney irgendwann verfilmt worden, wenigstens einer. Genau, also da gibt es lauter Tiere neben diesen Bären.

Eine der beiden und eins von den Tieren ist natürlich eine Eule, AOL, und die ist eigentlich in diesem Buch bzw. wenn man den Film mal gesehen hat, die ist eigentlich relativ smart oder glaubt, recht intelligent zu sein, tut zumindest immer so, aber wenn die Eule dann tatsächlich mal was unterschreiben muss, ist nicht in der Lage ihren dreibuchstabigen Namen richtig zu schreiben, sondern die schreibt immer WOL statt AOL.

Und deshalb dachte man sich, hey, das ist ja eine coole Verbindung, wir nennen das Ding jetzt nicht WOL, sondern wir nennen es AOL. Aber die Geschichte ist quasi erst im Nachhinein erfunden worden. Letztendlich hat man versucht, aus dem WOL irgendein Akronym zu bilden, das Sinn macht, und hat sich gedacht, wenn wir AOL nehmen und das irgendwie umstellen, da könnte man irgendwie coole Logos machen, das vermarktet sich besser,

also das war so eine Art Marketing-Entscheidung. Eine andere Geschichte, die es noch gibt, ist, es gab in den 70er-Jahren einen Forscher im Bereich der künstlichen Intelligenz, William Martin hieß der, und der hat sich mit Wissensrepräsentationen schon in den 70er-Jahren beschäftigt und hat auch eine Sprache entwickelt zur Wissensrepräsentation,

die nannte sich One World Language, OWL, genauso abgekürzt wie das, und man kann auch sagen, ja, in honor of Herrn Martin wäre das so genannt worden, ist aber auch nicht so der Fall. Also man weiß es heutzutage wissen es nur noch die Beteiligten, die drei, die diesen Standard geschrieben haben, unter denen war der Guss Schreiber

aus den Niederlanden, und der hat mal gesagt dazu, why not be inconsistent in at least one aspect in a language that is all about consistency, also warum soll man nicht wenigstens in einem Aspekt dieser Sprache inkonsistent sein, wo doch alles hier um Konsistenz geht. Okay, also das ist die Geschichte OWL und nicht Woll, OWL klingt natürlich viel schöner.

Ist jetzt nicht ganz neu, Sie sehen, 2004 gab es die erste W3C-Recommendation, erweitert worden 2009 auf OWL 2 mit den entsprechenden Erweiterungen, die wir auch noch kennenlernen werden. Generell besteht so eine OWL-Ontologie, also das ist ja eine Ontologie-Beschreibungssprache, wie wir es uns schon gedacht haben, da das Ganze ja auf der Beschreibungslogik

oder einer Beschreibungslogik basiert aus Klassen, Properties und Individuen, und Individuen, das sind halt die Instanzen der Klassen. Darüber hinaus, sagt man, wie eben in den Beschreibungslogiken übrig, übrig bei OWL gilt die Open World Assumption, das heißt, das Fehlen von Informationen wird eben nicht negativ gewertet,

im Gegensatz zur Closed World Assumption. Wenn wir ein Beispiel dazu anschauen, wenn ich jetzt eine Relation habe, Person A sitzt neben Person B, dann heißt das, dass Person A durchaus auch noch neben anderen Personen sitzen kann, das ist also nicht exklusiv und es kann nicht ausgeschlossen werden, dass A nicht auch noch neben anderen Personen sitzt.

Darüber hinaus gilt bei OWL auch noch die sogenannte Unique Name Assumption, oder nee, die gilt eben nicht die Unique Name Assumption, das heißt, wenn ich irgendein Individuum benenne, und ich habe ein Individuum mit dem anderen Namen, also zwei verschieden benannte Individuen, dann können die potentiell gleich sein, das liegt auch letztendlich an der Open World Assumption begründet. Ich muss also, wenn zwei Individuen mit unterschiedlichen Namen

explizit unterschiedlich sind, deren Unterschied auch explizit ausdrücken, ansonsten sind sie immer potentiell auch gleich und haben nur unterschiedliche Namen, also das macht es ein bisschen komplizierter, aber Person A kann also dieselbe Instanz bezeichnen wie Person B, außer ich sage Person A ist explizit nicht dieselbe Person wie Person B.

Das sind also so diese Grundregeln, die für diese Wissensbeschreibungssprache, diese Ontologiebeschreibungssprache gelten. Insgesamt ist OWL ein semantisches Fragment der Prädikatenlogik erster Stufe, also der First Order Logic,

und es gibt mittlerweile fünf Varianten, die für uns interessant sind, hier eingeordnet in so einen schönen Abhängigkeitsgrafen, da sieht man dann, was ist worin enthalten oder wovon abhängig, und da sehen Sie auf der einen Seite die drei Geschichten, die zu OWL I gehören, nämlich OWL Light, OWL DL und OWL Full.

OWL Light ist ein Fragment von OWL DL, und OWL Full ist nichts anderes als OWL DL Plus an auch noch die Kompatibilität zu RDFS, das heißt bei OWL Full kann man dann auch noch komplett die RDFS-Syntax mitverwenden, inklusive Reifikation, inklusive Inkonsistenzen bei der Klassen- und Individuumbeziehung,

das heißt ich kann eine Klasse zum Individuum machen, ich kann Aussagen über Klassen machen und ähnliche Sachen, das macht das Ganze dann letztendlich auch unentscheidbar, also OWL Full ist unentscheidbar, OWL DL, DL steht für Description Logic, das ist genau die Variante, mit der wir erstmal arbeiten werden, und OWL Light ist heutzutage nicht mehr interessant,

dafür gibt es dann die drei, die hier links davon angegeben sind, und die sind eben hier aus dem OWL II Repertoire mit dazu gekommen, OWL EL, OWL RL und QL, die werden wir auch das nächste Mal noch kennenlernen, da geht es um Sprachdialekte, denen jetzt einige von den Konstruktoren,

die in OWL DL dabei sind, fehlen explizit, aber die auf jeden Fall berechenbar sind, also entscheidbar, und nicht nur das, sondern die sollen sogar möglichst effizient entscheidbar sein, das heißt, da wird einiges weggelassen, um jetzt hier sehr, sehr schnelle Entscheidbarkeit modellieren zu können, auch im Hinblick auf, was die Kompatibilität zu anderen Wissensrepräsentationen aus der künstlichen Intelligenz angeht,

hat man da eben dran gedacht. Ja, und das werden wir uns eben in der nächsten Woche, bzw. jetzt hier in den nächsten Minuten, die vor uns liegen, anschauen, also hier nochmal für OWL II, gilt hier noch OWL EL, OWL RL und QL, die sind wiederum in OWL DL enthalten,

und OWL DL wiederum ist in OWL FULL enthalten, wobei FULL eben immer nicht entscheidbar ist. Die drei Basisdialekte nochmal angeguckt, also OWL LITE entspricht einer bestimmten Entscheidungslogik, nämlich SHIFT D, jetzt können wir uns wieder fragen, ja, wofür standen noch genau diese einzelnen Buchstaben,

werden wir auch später nochmal genauer angucken, was es eben gegenüber dem normalen OWL DL nicht kann, also es gibt keine Nominale, keine Aufzählungsklassen, Kardinalität gibt es nur 0 und 1, und Disjunktheit kann ich damit ausdrücken oder nicht, schauen wir uns gleich mal an. Das Schöne dran ist, schön ist ja gut,

die Worst-Case-Komplexität ist hier noch exponentiell, deterministisch exponentiell immerhin, das ist dann bei OWL DL entweder in der Variante 1 oder 2 schon ganz anders, das ist diese scheuen D, haben wir schon mal drüber geredet, über diese Discription-Logik bzw. in der OWL 2 Variante Schreuk,

Schreuk ist irgendwie anders, da ist das R mit dabei, ich kann nämlich dort auch rollen, das heißt, Relationen hier, Properties definieren und zusammensetzen, komplexe Properties aus einfachen zusammensetzen, das macht das R, und ich kann qualifizierte Zahlenrestriktionen, das ist das Q hier hinten noch machen, dann schauen wir uns dann auch noch mal im Detail letztendlich an.

Das Schöne dran ist, genau für die gibt es eine formal definierte Semantik, weil das ist exakt auch eine Beschreibungslogik, das ist entscheidbar, es ist vollständig und es ist korrekt. Entscheidbar heißt, dass ich sämtliche Schlussfolgerungen, die ich ziehen kann, hier natürlich in endlicher Zeit ziehen kann,

vollständig heißt, dass ich auch wirklich alle Schlussfolgerungen ziehen kann, und korrekt heißt, dass ich die eben auch korrekt ziehen kann. Da sieht es mit der Komplexität schon ein bisschen schlimmer aus, weil wenn ich dort tatsächlich herausfinden möchte, also die Erfüllbarkeit, auf die ich quasi das Überprüfen von Schlussfolgerungen zurückführen kann,

dort ist die Komplexität oder die Rechenzeit, die das braucht, dann ebenfalls exponentiell, aber nicht deterministisch exponentiell, und das ist natürlich schon eine ganze Größenklasse, quasi schlechter als oben die exponentielle Zeit, die ich brauche, Und bei Aool-Full, das hatte ich ja schon gesagt,

da kommt RDFS und die komplette Aool-Syntax letztendlich am Ende mit zusammen. Ich habe dort die Möglichkeit zu schachteln, mit Hilfe der Reifikation oder Metamodellierung, dass ich Aussagen auch über Klassen machen kann, und das ist unentscheidbar, das ist also keine Beschreibungslogik, was ich da in Aool-Full drin habe, ganz einfach wegen diesem RDFS-Vokabular,

dass ich in keine Entscheidungslogik letztendlich mit reinbringen kann. Was kann ich mit dem Aool alles machen? Ich kann die Disjunktheit von Klassen ausdrücken, das ist hier sehr wichtig bei uns, also ich kann sagen, dass beispielsweise die Klasse Person und Klassengedrängt disjunkt sind, das kann ich sagen, ich kann inverse Properties verwenden, also ich kann sagen, ich mag, ist genau das Gegenteil von,

ich werde gemocht von, inverse heißt immer, wir tauschen da hier ganz einfach Domain und Range letztendlich aus, und ich muss die Verschiedenheit von Instanzen wegen dieser nicht vorhandenen Unique-Name-Instanzen immer ausdrücken, ich muss also sagen, wenn Person A und Person B tatsächlich unterschiedlich sind,

dann muss ich hier gehen und muss das explizit dann sagen. Und ich kann komplexe Klassen definieren, wie Sie das aus den Beschreibungslogiken schon kennen, zum Beispiel kann ich die Klasse der Kaffeeliebhaber dann definieren, die besteht dann aus Mitgliedern der Klasse Person, für die jetzt ein bestimmtes Property, nämlich das Property Mark, den Wert Kaffee besitzt zum Beispiel,

also solche und ähnliche Dinge kann ich mit Aul machen. Wie wir das machen, schauen wir uns an, wenn wir uns jetzt die Aul-Syntax mal näher anschauen. Wenn Sie jetzt dachten, das wäre irgendwie einfach, da gibt es nur eine Syntax, oder es gäbe zwei, wie wir das schon bei RDF kennengelernt hatten, mit Turtle und der RDF XML-Syntax, hier gibt es natürlich noch mehr,

und für Aul 2 werden wir dann nochmal zwei zusätzliche kennenlernen, also wir haben hier einmal für Aul 1 die normale RDF-Variante, die eben auch aussieht wie so eine XML-Serialisierung, wir haben eine abstrakte Syntax und wir haben eine Description-Logic-Syntax, und dazu haben wir dann Gesundheit auch noch Turtle. Dazu kommen dann noch bei Aul 2 eine funktionale Syntax und eine Manchester-Syntax,

die Manchester-Syntax ist angelehnt an vorhandene oder schon existierende Beschreibungslogische oder Sprachen zur Wissensrepräsentation und die funktionale Syntax, das ist die, bei der man mit den wenigsten Zeichen auskommt, sage ich immer. Also viele von den Dokumenten, die Sie im Web finden werden,

bezüglich Aul 2, sind in der funktionalen Syntax gehalten, weil man dazu am wenigsten schreiben muss. Letztendlich muss jedes Tool, das irgendwie Aul-compliant ist, das also Aul gemäß den W3C-Bestimmungen versteht, diese RDF-Syntax irgendwie verstehen.

Und für uns am einfachsten eigentlich nachzuvollziehen und auch am wenigsten zu schreiben, ist Turtle. Das kennen wir schon aus RDF. Das heißt, wir werden jetzt hier die Beispiele, die wir uns anschauen, erstmal anschauen, immer in dieser RDF-Syntax, damit wir mal sehen, wie es offiziell aussieht. Und wir werden uns das Ganze dann auch noch anschauen in Turtle. Beziehungsweise, falls Sie jetzt gerade schon die Folien verwenden

oder mit draufschauen, die ich schon ins Netz gestellt hatte vorhin, bei denen ist der Turtle-Anteil noch nicht mit drin, damit wir ein bisschen was haben zum Mitdenken und Mitschreiben. Den Turtle-Anteil, den Sie hier jetzt schon auf den Folien mitsehen, den werde ich dann später mit ins Netz hineinstellen. Okay, also was wir uns anschauen werden, ist diese Aul-RDF-Syntax.

Aul-Dokumente sind in dem Sinne als RDF-Dokumente, zumindest was jetzt hier die Syntax oder die Standard-Syntax angeht. Das heißt, man hat hier auch einen Kopf für die Ontologie, die man hier definiert und dann quasi kommt die eigentliche Ontologie. Und da müssen wir natürlich einen neuen Namespace mit aufnehmen, den Aul-Namespace, beziehungsweise die neue Aul-Definition,

den neuen Namespace für Aul 2. Aber jetzt sind wir erst einmal bei der alten Variante. Was die Syntax betrifft, habe ich das Ganze nochmal unterteilt, weil da kommt ganz schön viel mit zusammen. Also wir fangen jetzt mal an aufzurollen, wir fangen an, den Dokumentenheader zu betrachten, wir gucken Klassenrollen, Individuen an. Wir schauen uns dann komplexere Klassen an,

Rollen und Eigenschaften von Rollen und schauen uns dann die einzelnen Aul-Varianten, light, dl und full an und gucken dann, was kann ich denn mit dem Aul eigentlich beantworten, wenn ich jetzt eine Aul-Wissensbasis habe. Das sind dann diese Anfragen an Aul, die wir uns jetzt als nächstes ansehen. Ich kann eine Ontologie in Aul immer so beginnen,

dass ich sie erstmal in irgendeiner Art und Weise in Form eines Headers beschreibe. Das heißt, ich kann dazu in schriftlicher Form Kommentare mit abgeben, ich kann Versionsinformationen mit angeben, ich kann sagen, dass irgendwelche anderen Ontologien importiert werden und ich kann auch noch sagen, das ist jetzt eine Version und dazu gibt es eine ältere Version zu dieser Ontologie.

Das heißt, man hat auch versucht, ein bisschen so vokabular für Versionsmanagement mit aufzubauen. Dazu hat man einen Teil davon von RDFS schon geerbt und verwendet das weiter, also RDFS-Command, RDFS-Label kennen Sie, See also und is defined by kann man hier verwenden und jetzt als Neues hat man noch Aul-Imports und eben zur Versionierung hat man Version-Info,

Prior-Version, Backward-Compatible-Width und die Sachen bedeuten eben genau das, was dahinter auch steht, also wie Sie es verstehen würden. Also deprecated class wäre eine veraltete Klasse, das bedeutet, die steht da zwar drin, diese Klasse, die jetzt hier als deprecated class oder deprecated property gekennzeichnet ist, man kann sie verwenden, aber man sollte sie nicht verwenden, weil sie bald dann irgendwann mal illmallide wird.

Ich kenne allerdings nicht sehr viele Ontologien, die das tatsächlich, dieses Vokabular auch mit benutzen. Das ist das, was quasi im header stehen kann, für uns interessant ist das, was ich tatsächlich an Wissen dann mit reinpacken kann. Und dazu schauen wir uns mal an, wie eben Klassen, Rollen und Individuen

in Aul definiert werden können. Wir kennen das ja schon aus RDF oder RDFS, Klassen hatten wir ja da auch, das heißt, die Klassen, die ich in Aul habe, sind natürlich vergleichbar mit Klassen, die ich in RDF und RDFS hatte, nur mit der Eigenschaft, ich kann eben symmantisch mehr über diese Klassen aussagen. Genauso gibt es Individuen, vergleichbar mit den Objekten in RDFS

und es gibt Rollen, vergleichbar mit den Properties in RDFS. Das Schöne ist, alles heißt hier natürlich gleich mal wieder anders und im Englischen, wenn Sie da englische Dokumente zu lesen, nennt man das dann zwar auch Roll, aber da hat man dann für die Rollen auch noch die Beschreibung oder die zwei Namen, man unterscheidet in sogenannte Object Properties und Data Type Properties. Also es gibt sehr viele Namen für ein und das gleiche Ding

und damit müssen wir im Moment halt erst noch leben. Klassen. Beschreibungslogiken, das wissen wir selber, die haben immer irgendwie so ein Klasselement drin, eine Klasse, die alle anderen enthält und eine Klasse, die nichts enthält bzw. von denen keine andere Klasse irgendwie Subklasse ist, das ist das einmal das Top-Element und das Bottom-Element

und in Aul werden die bezeichnet mit den Klassen namens Thing, das ist das Top-Element und Nothing, das ist das leere Element oder das ist quasi die Bottom-Klasse und wenn ich eine Klasse in Aul definieren möchte, ist das eigentlich ganz einfach, also die RDF-Syntax sehen Sie hier selber, ich definiere hier ein Klassen-Element

und gebe dem einen Namen, nämlich den Namen Wein und fertig und wenn ich das in Turtle hinschreibe, ist das noch viel kürzer, da sage ich, dass Wein eine Klasse ist und Punkt. Also, Klassen definieren, wenn es einfache Klassen sind, ganz einfach. Individuen, die zu einer Klasse gehören, kennen Sie auch schon,

da kann man sich quasi an RDF anlehnen, wir kennen das schon aus RDF, man legt hier ein Individuum an mit einer RDF-Description und sagt dann einfach, die gehört, dieses Individuum ist von einem Typ dieser Klasse, die dahinter steht, also das hat man aus RDF letztendlich annektiert von der Sprache her und das heißt, man macht das eigentlich auch ganz genauso hier unten in Turtle,

da kann ich jetzt sagen, dass dieser Wein, den ich hier definiert habe, in der Wege der Rheingau-Riesling, das wäre ein Wein. Ist also in Turtle ganz einfach zu sagen. Also, Klassendefinitionen, Individuendefinitionen können Sie quasi lesen, als wäre es in natürlicher Sprache geschrieben. Ganz einfach. Interessanter wird es jetzt, wenn wir Klassen und Individuen irgendwie

über Rollen oder Properties eben hier miteinander verbinden. Wir wissen, dass es zwei verschiedene Varianten gibt. Es gibt die Object Properties und die Data Type Properties. Object Properties sind diejenigen, die jetzt quasi eine Entität mit einer anderen Entität verbinden und die Data Type Properties sind

Properties, die eine Entität mit einem Literal verbinden oder einem typisierten Literal. Und um die Verwirrung komplett zu machen, hat man das im Deutschen so übersetzt, dass man sagt, man hat abstrakte Rollen, das sind die Object Properties und man hat konkrete Rollen, das sind die Data Type Properties. Also, ärgern Sie sich nicht,

dass Sie mit den Namen irgendwie durcheinander kommen. Ich habe mich jetzt hauptsächlich immer, wenn ich es mir selber merke, auf die Englischen kapriziert und habe die Deutschen nur der Vollständigkeit hingeschrieben, falls Sie eines der Bücher, die wir hier haben, in der deutschen Übersetzung lesen, dass Sie nicht durcheinander kommen, wenn dort von abstrakten und konkreten Rollen die Rede ist. Fangen wir an mit den abstrakten Rollen. Also ich definiere hier beispielsweise

ein Object Property, das nennt sich wird hergestellt aus und ich muss dazu natürlich Domain und Range angeben und sage dann wird hergestellt aus, Domain wäre Wein wird hergestellt aus, Weintraum. Da hätte ich jetzt ein wunderschönes Property, das eben jetzt zwei Klassen miteinander verbindet, nämlich die Klasse Wein und die Klasse Weintraum. Wenn ich das Ganze jetzt in Turtle hinschreiben möchte,

wird es natürlich ganz einfach, wird hergestellt aus, das ist ein Object Property, mir muss ich dazu nicht sagen und dann, wenn ich noch Domain und Range angeben möchte, kann ich sagen, ich fange also nochmal an, wird hergestellt aus, ist ein Object Property mit der Domäne Wein und dem Range Weintraum und fertig.

Also Sie sehen, soweit bisher ganz einfach. Schauen wir uns das Ganze an mit konkreten Rollen oder Data Type Properties, da geht es eben darum, dass man im Range dann irgendwo dann einen Datentyp, ein Literal dann stehen hat. Daher kommt der Name mit diesen Datentypen. Deshalb heißt das Ding Data Type Property

hier, definiere ich eine Qualitätsstufe als Data Type Property und sage, okay, die Domäne hier ist diesmal auch Wein und der Range, das soll einfach nur ein String sein. Da gebe ich eben den Namen der Qualitätsstufe an. Und Datentypen kann ich hier verwenden, nämlich alles Mögliche, was ich hier quasi auch von XML-Datentypen

vorgegeben habe. Also Integer und String stehen im alten Standard drin, String stehen im alten Standard drin und mittlerweile sind da noch viel mehr mit dabei, die ich verwenden kann. In Turtle übersetzt, wieder ganz einfach, Qualitätsstufe, das ist eine Data Type Property und hier unten Domäne und Range brauche ich nur unten anzuhängen, Domäne, Wein

und Range wäre dann XSD String, wobei ich XSD natürlich den entsprechenden Präfix, wenn ich das Turtle verwende, mit angeben muss, also den Namensraum muss ich dann entsprechend als Präfix noch mitdefinieren. Dann funktioniert das Ganze. So und jetzt haben wir Klassen, Individuen und Rollen. Jetzt kann ich

das Ganze miteinander verbinden. Also beispielsweise habe ich hier der Wegeler Rheingau Riesling, der wird hergestellt aus Riesling-Trauben und der soll jetzt eine Qualitätsstufe haben, nämlich die Qualitätsstufe Spätlese. Spätlese ist hier wieder ein String. Schauen wir uns das Ganze mal in Turtle an.

Wegeler Rheingau Riesling ist also ein Wein, wir haben hier die Klassenzuordnung, der wird hergestellt aus Riesling-Trauben und der hat die Qualitätsstufe Spätlese. Total einfach. Dann steht hier unten noch, Rollen sind im Allgemeinen nicht funktional. Was heißt das?

Wenn Sie es auf unser Beispiel mit dem Wein irgendwie nehmen, dort haben wir ja quasi nur, es sieht erstmal so aus, als wären das funktionale Attribute. Ein Wein wird hergestellt aus einer Sorte Weintrauben. Jetzt wissen natürlich diejenigen, die sich mit Wein auskennen, es gibt Weine, die werden aus unterschiedlichen Weintrauben hergestellt. Das heißt, das wäre ein nicht

funktionales Property, wenn ich nämlich jetzt irgendeinen anderen Wein hätte, nehmen Sie einen Spanischen, einen Rioja, der wird beispielsweise aus Tempranillo und Grenache und anderen Tauben irgendwie zusammen hergestellt. Das heißt, da müsste ich mehrere wird hergestellt aus angeben können. Und das ist einfach erstmal der Standardfall, wenn ich möchte, dass in Aul ein bestimmtes Property tatsächlich funktional ist, das heißt, nur einen Wert

quasi abbilden kann auf ein bestimmtes Subjekt, dann muss ich es extra dazu sagen, dass dieses Property funktional ist. Ansonsten wird das Gegenteil angenommen. So, damit kann ich schon eine ganze Menge sagen, allerdings, viel Semantik steckt noch nicht drin. Jetzt müssen

wir auch hergehen und müssen genauso wie wir es in RDFS hatten, wo wir Klassenhierarchien hatten, Property-Hierarchien hatten, das gibt es natürlich auch dann hier in Aul, weil wir werden ja sehen, Aulklassen sind ja ein bisschen was anderes als RDF und RDFS-Klassen. Also muss ich für Aulklassen auch Subklassenhierarchien definieren, bediene mich dabei aber des

Vokabulars, das ich aus RDF habe, weil eine Subklasse im Prinzip ist bei Aul nichts anderes als auch in RDF oder RDFS. Also hier habe ich definiert, Wein ist ein alkoholisches Getränk und ein alkoholisches Getränk, das ist halt ein Getränk. So, und jetzt kann ich hier

gehen und kann natürlich schließen mit Hilfe der Aulsemantik, die wir noch nicht haben, dass das eben jetzt hier so definiert ist, dass Wein natürlich auch ein Getränk ist, über diese stufenweise aufgebaute Subklassenbeziehung. Also ganz einfach. Wenn wir das schreiben wollen als Turtle, und hier habe ich immer erst die Klassendefinition

vornerang gestellt, ich sage Wein ist eine Klasse und ist eine Subklasse von alkoholisches Getränk und alkoholisches Getränk ist ebenfalls eine Klasse und das ist eine Subklasse von Getränk. Also das geht sehr einfach. Interessant wird es dann, Klassen können ja jetzt im Gegensatz zu RDF und RDFS noch andere Beziehungen zueinander haben,

denn die können, das hatten wir ja bei RDF und RDFS festgestellt, da geht das nicht, die können hier in Aul auch disjunkt sein. Disjunkt heißt, dass eben ein Individuum nur in einen von beiden Klassen sein kann und niemals in beiden. Also hier beispielsweise habe ich ein Beispiel für die Disjunktheit. Ich habe hier, was habe ich hier geschrieben? Ich habe hier zwei

Klassen und Subklassendefinitionen, Wein ist ein alkoholisches Getränk und Pizza ist ein Hauptgericht und ich sage, dass eben ein alkoholisches Getränk disjunkt ist mit einem Hauptgericht. Und ja, sind Sie aufgewacht gerade?

Ja, gut, in Bayern ist das natürlich anders. Da gilt zumindest Bier als auch noch als Lebensmittel und nicht als Getränk, also da kann man sich dann streiten. Aber letztendlich kann ich aus dieser Definition dann herleiten, dass auch Wein und Pizza natürlich disjunkte Klassen sind. Gut, jetzt wollen wir dasselbe in Turtle

ausdrücken, das geht wieder genauso einfach, wenn Sie sich das anschauen. Wein ist eine Klasse und eine Subklasse von alkoholischem Getränk, Pizza ist eine Klasse und Subklasse von Hauptgericht und wenn ich jetzt sagen möchte, dass zwei Klassen disjunkt sind, dieses Aul disjoint with sehen wir, das ist ja ein Property, erkennt man woran, dass das ein Property sein muss.

An der Schreibweise fängt also mit einem kleinen Buchstaben an, kleine Buchstaben sind Properties, große Buchstaben sind Klassen, da kann man sich immer ein bisschen weiterhelfen, wenn man versucht, irgendwas in Turtle auszudrücken, was man noch nicht ausgedrückt hat, mit einem Vokabular, das vorgegeben ist. Also alkoholisches Getränk ist hier disjoint mit Hauptgericht und das heißt, dass eben

mit Ausnahme von Bayern, dass wir semantisch hier nicht betrachten, kein alkoholisches Getränk auch gleichzeitig ein Hauptgericht sein kann. Gut, auf der anderen Seite, wenn ich jetzt die Umgebungtheit irgendwie festgelegt habe, muss ich auch quasi sagen können, dass zwei Klassen identisch miteinander sind, das heißt, Klassenequivalenz muss ich irgendwie ausdrucken können, das kann ich

hier auch machen, ich habe hier wieder den Wein als Subklasse von alkoholisches Getränk und dann kann ich hier sagen, das alkoholische Getränk wäre äquivalent zu einer anderen Klasse, die heißt hier Alcoholic Beverage, die kann von mir aus auch aus einer anderen Ontologie kommen, dann muss ich da natürlich noch den entsprechenden Namenspräfix davor schreiben, aber damit kann man quasi Mappings und Abbildungen zwischen unterschiedlichen

Ontologien herstellen, indem man quasi die Äquivalenz von zwei Klassen, die Gleichheit von zwei Klassen über dieses Äquivalentglas hier letztendlich quasi mit verwendet und außerdem kann ich jetzt hier auch noch einen Schluss ziehen, wenn ich die Alsemantik dann mit verwende, nämlich, dass Wein auch eine Subklasse ist von

Alcoholic Beverage, weil wir hier eben diese Klassenäquivalenz mit dabei haben. In Turtle sieht das ganze auch wieder ganz einfach aus, wir haben hier Wein ist eine Klasse, ist eine Subklasse von alkoholischem Getränk und die beiden Klassen, Alkoholisches Getränk und Alcoholic Beverage sind äquivalent über All

Equivalent With. Also bisher, sehen Sie, ist das Ganze ein Spaziergang und ganz einfach, es wird dann schon noch komplizierter, wenn wir dann komplexe Klassenkonstruktoren betrachten. Gut, jetzt kann ich natürlich noch mehr Schlussfolgern, wenn ich auch betrachte, wir haben Individuen, Individuen sind in Klassen, ich habe Klassenhierarchien und Klassenbeziehungen,

jetzt kann ich mal schauen, was ich so noch alles ausdrucken kann. Schauen wir mal, was wir hier stehen haben. Also was steht denn in dem Grauen hier im Moment da, wenn ich das mal in natürlicher Sprache sagen würde, ganz einfache Aufgabe. Also das ist noch nicht schwer, das ist primitiv. Wir haben es ja auch schon gesagt, wer möchte? Versuchen Sie es,

ist doch einfach. Ja, genau.

Und das erste, was Sie gesagt haben, dass er auch gleichzeitig ein alkoholisches Getränk ist, kann man aus der ersten Zeile schon schließen. Zum zweiten Teil letztendlich Schlussfolger. In Törtl sieht das hier auch ein bisschen viel aus,

ist aber auch ganz einfach, der Wegelehrer Rheingau-Riesling ist ein Wein, wird hergestellt aus Rieslingtrauben, Qualitätsstufe Spätliese. Wein ist, falls ich es noch nicht behauptet habe oder bemerkt habe, eine Klasse, wird normalerweise, oder kann man implizit auch oben aus dieser ersten Zeile schon schließen. Und ich kann sagen, es ist die Subklasse von einem oder von alkoholisches Getränk.

Das Ganze kann ich dann wieder weiter spinnen, beispielsweise wenn ich jetzt hier auch noch sage, dass mein, was habe ich hier, Wegeler Rheingau-Riesling irgendwo anders noch in einer anderen Ontologie oder wo auch immer vorkommt unter einem anderen Namen, dann kann ich nämlich auch sagen,

dass zwei Individuen quasi gleich sind oder dasselbe bezeichnen. Hier habe ich beispielsweise noch irgendein Individuum mit dem Namen WRR012345 und wenn diese beiden tatsächlich identisch sind, dann kann ich das hier auch sagen, nämlich mit all same as. Also wenn ich dann eine Inferenz über das ziehe, was ich vorhin schon gesagt habe,

kann ich auch sagen, dass WRR012345 ein alkoholisches Getränk ist. Das ist ebenfalls wichtig, wenn es darum geht, wieder unterschiedliche Ontologien aufeinander abzubilden, mehrere Vokabularien zu benutzen, dann brauche ich same as Beziehungen, die wir sagen, dieses Individuen in der Ontologie A entspricht dem Individuum in der Ontologie B.

Das mache ich über same as normalerweise. Und genauso habe ich auch die Möglichkeit, die Verschiedenheit auszudrücken zwischen Individuen. Das mache ich dann mit different from. Schauen wir uns vorher das Ganze noch mal an in Turtle. Sie sehen, man muss weniger schreiben. Wegeler Rheingau-Riesling ist ein Wein, wird hergestellt aus Riesling,

Qualitätsschufe Spätlese und ist dasselbe wie WRR012345. Gleichheit same as, Verschiedenheit mit different from. Jetzt sind wir hier 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15 Studenten.

Wenn ich jetzt ausdrücken wollte, dass sie alle voneinander verschieden sind, wie viele all different froms müsste ich schreiben?

Andere Meinungen. Aber ungefähr wissen wir es. Das heißt, Sie müssen das irgendwie vollständig vernetzen, alle mit allem kombinieren. Und da kriegen Sie normalerweise diese Gaussche-Geschichte raus. Aber ne, passt schon.

Also ist quadratisch, annähernd quadratisch, wenn Sie alle mit allen vernetzen wollen, also die Beziehung zwischen jeweils zwei Paaren herstellen wollen. Und ja, wäre ein bisschen viel hinzuschreiben. Genau. Deshalb hat man sich gedacht, hey, wir müssen das Ganze nicht hinschreiben. Der Reasoner kann das automatisch ausrechnen. Deshalb führen wir noch einen Sprachkonstrukt ein,

dass mir dieses viele Schreiben erspart. Und das ist dann quasi nichts anderes. Also man hat sich erinnert, dass es in RDF ja solche Containerkonstrukte gab. Und jetzt legt man eine Collection an, die eben einen ganz bestimmten Namen hat, nämlich all different. Und darin gibt es sogenannte distinct members. Und die sind alle voneinander verschieden.

Und das muss ich nur einmal reinschreiben. Und das ist natürlich viel, viel weniger. Und das ist wirklich nur eine verkürzte Schreibweise. Also mehr Semantik steckt hinter dem all different und distinct members nicht, als dass ich da quasi die paarweise Verschiedenheit sämtlicher einzelner Instanzen innerhalb dieser Collection damit bezeichne.

Das kann ich jetzt auf unterschiedliche Arten und Weisen wieder ausdrücken in Turtle. Das heißt, wir sehen ja hier jetzt keinen expliziten Klassenkonstruktor, der jetzt eine Klasse konstruieren würde, in der lauter solche unterschiedlichen Elemente drin sind. Wenn ich das jetzt hinschreibe in Turtle, nehme ich natürlich eine unbenannte Klasse. Ich kann ja aber Namen geben.

Hier habe ich mal die Variante, in der ich ihr irgendeinen Namen gegeben habe, damit ich dieses Konstrukt oder diese ganze Menge von unterschiedlichen Individuen irgendwann mal später wieder referenzieren kann. Das heißt, die habe ich hier mit dem Blanknote mit dem Namen X1 bezeichnet. Und ich sage, das ist eine Collection vom Typ all different.

Die hat Members. Und dann kommt quasi die Aufzählung der einzelnen Members hintereinander, nämlich diese drei verschiedenen Weine, Wegella, Rheingau, Riesling, Alto Adice, Chardonnay und Chateau Lafite, Rothschild. Ja, andere Möglichkeit dazu wäre, ich mache das ohne diese Namensfestlegung und beginne einen Blanknote anzulegen in Turtle, indem ich also mit einer eckigen Klammer anfange.

Das werden wir später auch noch mal sehen. Spare ich mir noch ein bisschen was, kann das aber später nicht mehr referenzieren. Muss man dann immer jeweils wissen, was man am besten verwendet. Gut, das waren jetzt Beziehungen zwischen Individuen. Ich kann also Gleichheit, Ungleichheit ausdrücken und habe hier jetzt dazu auch noch die Möglichkeit, mir einiges an Schreibarbeit zu sparen,

indem ich hier solche Klassen mit unterschiedlichen Individuen definieren kann. Des Weiteren bietet Aul noch die Möglichkeit, ich kann sogenannte abgeschlossenen Klassen definieren, sogenannte Nominale. Das sind nämlich Klassen, die tatsächlich jetzt nur aus den Individuen

oder aus den Klassen bestehen, die ich hier entsprechend aufzähle. Das ist eine abgeschlossene Klasse. Und hier sage ich beispielsweise definiere ich eine Klasse, die heißt Rotweine im Warenbestand. Und dann kommt das Aul-Schlüsselwort One-Off und damit definiere ich eben eine abgeschlossene Klasse, die genau besteht aus Chateau Latour-Puyak und Chateau Lafite-Rotschild.

Das sind die zwei Weine, die ich jetzt hier im Warenbestand habe und das besagt, dass es genau diese zwei Rotweine im Warenbestand gibt und sonst erstmal nichts. Funktioniert in Turtle wieder genauso. Ich muss natürlich sagen, dass diese beiden Weine tatsächlich auch Weine sind. Also Chateau Latour-Puyak und Chateau Lafite-Rotschild, das sind jeweils Weine.

Und ich sage, Rotweine im Warenbestand ist eine Klasse und das ist eine Aufzählungsklasse, die eben aus genau diesen beiden Weinen besteht und sonst nichts. Also auch sehr einfach und im Moment noch nicht groß kompliziert. Machen wir das Ganze jetzt ein Stückchen komplizierter.

Wir definieren jetzt noch zusätzlich einen dritten Wein und zwar definieren wir ihn so, dass es ein anderer Wein sein soll als eben die zwei, die ich schon hatte. Nämlich ich definiere jetzt hier diesen Alto Adige Sauvignon Blanc mit dazu. Der ist eben nicht gleich dem Chateau Latour und nicht gleich dem Chateau Latour.

Und das Schöne daran ist, wenn ich jetzt diese beiden Definitionen zusammennehme, einmal die abgeschlossene Klasse und einmal definiere ich mir hier einen Wein, der nicht den anderen beiden Weinen entspricht, also ein anderer ist, dann kann ich daraus schließen, dass dieser Wein nicht im Warenbestand ist, weil das andere ja eine abgeschlossene Klasse ist. Das heißt, da ist nicht mehr drin als das, was wir definiert haben

und wir auch ausgeschlossen haben, dass dieser Alto Adige Sauvignon Blanc gleich einem der anderen Weine ist und nur einen anderen Namen hat. Also Sie sehen, man kann hier mit relativ wenig, schon ziemlich viel dann auch ausdrücken. Versuchen wir das Ganze nochmal in einem Törtel. Wir definieren also diesen Wein, jetzt Alto Adige Sauvignon Blanc als Wein

und sagen dann noch, die anderen hier wären alle voneinander unterschiedlich, kennen wir ja auch schon. Also wir sagen, jetzt sehen Sie, hier habe ich mal ein RDF-Type verwendet und kein A. Und dann kommt die Aufzählung der einzelnen Klassenelemente, diese aufgeschlossenen Klasse und die sind alle unterschiedlich.

Ja, also fassen wir nochmal zusammen. Wir haben Klassen definiert, wir haben Rollen definiert, wir haben Individuen definiert, wir haben Beziehungen zwischen Klassen und Rollen und Individuen uns angeschaut. Wir haben gesehen, dass man Klassengleichheit, Klassenungleichheit definieren kann, Gleichheit von Individuen, Ungleichheit von Individuen mit abgekürzter Schreibweise

und wir haben festgestellt, dass man sogenannte nominale, also Aufzählungsklassen definieren kann in Aul. Das ist schon mal wesentlich mehr, als wir tatsächlich mit Aul können. Entschuldigung, als wir tatsächlich mit RDF kann. Aber das eigentlich wirklich Schöne ist, wenn ich jetzt anfange, komplexe Klassen zu definieren, bei denen ich schon vorhandene

atomare Klassen oder Individuen irgendwie miteinander in Bezug setze und quasi mein komplettes semantisches Vokabular, das ich habe, aus der Beschreibungslogik, die ich hier verwende, mit einsetze. Dann kommt nämlich wesentlich mehr Semantik mit rein. Also wenn ich jetzt komplexe Klassen definiere und ich habe solche komplexen Klassenkonstruktoren, beispielsweise über den Schnitt mit der Konjunktion,

also das wäre Aul-Intersection-Auf. Sie sehen, das ist auch hier ein Property. Dann mit der Disjunktion, das wäre Aul-Union-Auf. Und ich kann negieren, Aul-Komplement-Auf. Die Negation ist besonders wichtig, weil damit kann ich nämlich hergehen, jetzt kann ich anfangen, Inkonsistenzen tatsächlich zu erzeugen. Ich kann auch mit der Disjungtheit schon Inkonsistenzen erzeugen.

Ich kann auch mit der Gleichheit und Ungleichheit Inkonsistenzen erzeugen. Aber jetzt mit dem Komplement, jetzt wird das Ganze auch wirklich schön. Jetzt kann ich anfangen und kann hier wirklich krude und sehr komplizierte Sachen definieren. So, und was mache ich mit diesen Konstrukturen? Damit kann ich jetzt komplexere Klassen definieren. Fangen wir mit den oberen, mit dem einfachsten mal an, mit der Intersection-Auf.

Ja, wir haben hier die Klasse Wein im Warenbestand, wie Sie hier sehen. Und die ergibt sich aus der Schnittmenge aus allem, was ich an Wein habe und allem, was ich im Warenbestand habe. Also, das ist eigentlich eine ganz einfache Sache. Wie alles andere auch, was wir hier haben.

Sie sehen, wir brauchen wieder nur dieses neue Schlüsselwort hier in der AUL RDF Beschreibung. Wenn wir uns das Ganze anschauen als Turtle, definieren wir einmal Wein als Klasse, einmal im Warenbestand als Klasse und sagen dann Wein im Warenbestand. Das ist ebenfalls eine Klasse, die besteht aus der Schnittmenge aus Wein und im Warenbestand. Also, man kann es quasi fast schon komplett so ähnlich wie natürlicher Sprache hinschreiben,

ohne jetzt viel Aufwand dafür betreiben zu müssen. Mit Union funktioniert es ähnlich. Hier habe ich jetzt quasi ausgedrückt die Tatsache, dass trockene Weine, halbtrockene Weine und liebliche Weine ebenfalls auch Weine sind. Nämlich, ich habe hier gesagt, Wein ist äquivalent zur Vereinigungsmenge

der trockenen Weine, der halbtrockenen Weine und der lieblichen Weine mit dem Schlüsselwort Union-off. Und das Ganze jetzt wieder als Turtle ausgedrückt. Ein bisschen komplizierter, weil Sie sehen, ich habe jetzt hier erstmal diese Äquivalenzbeziehung. Ich sage, dass Wein eine Klasse ist.

Dann sage ich, dass Wein äquivalent ist zu. Und jetzt kommt hier ein Blanknote eigentlich rein, auf den ich verweise und sage dann, äquivalent zu einer Klasse, die gebildet wird aus einer Union-off, also aus einer Disjunktion, bestehend aus den folgenden drei Klassen, nämlich trockener Wein, halbtrockener Wein und lieblicher Wein. So, Sie sehen, jetzt kriegen wir hier eckige und runde Klammern mit dazu.

Und je länger diese Ausdrücke werden, desto komplizierter wird es. Und wir nähern uns den Klammergebirgen, die man schon in der künstlichen Intelligenz seit Ende der 70er, Anfang der 80er Jahre kennt. Wer schon mal irgendwann Lisp gesehen hat, weiß, da gehen viele Klammern auf und wieder zu. Und so ähnlich sieht das dann am Ende auch aus.

Gut, dann schauen wir uns jetzt noch das Komplement an. Also, ich kann hier beispielsweise sagen, das Wein wäre das Gegenteil von Pizza. Womit ich auch sagen kann, oder was semantisch äquivalent zu der Aussage wäre, dass die Klassen Wein und Pizza zueinander disjunkt sind. Hingeschrieben in Turtle, Wein ist eine Klasse und ist eine Subklasse.

Eines Blanknotes, auf den ich verweise, der wiederum sagt, die Subklasse einer Klasse, die gleichzeitig Komplement der Klasse Pizza ist. Kompliziert ausgedrückt, aber das entspricht genau quasi dem RDF- oder All-RDF-Anteil, der hier oben drüber steht.

Und der untere Teil, klar, das kann ich natürlich viel kürzer schreiben, Wein ist eine Klasse und ist disjunkt mit Pizza. Okay, das sind die komplexen Klassenkonstruktoren. Jetzt haben wir natürlich noch nicht so viel Kompliziertes damit gemacht. Wir können jetzt Klassen aus anderen irgendwie zusammensetzen. Um noch einen Schritt weiterzugehen, haben wir jetzt noch die Möglichkeit,

Properties mitzuverwenden. Und wir hatten ja kennengelernt, in den Beschreibungslogiken haben wir Quantoren, die Properties quasi einschränken können. Und das Ergebnis von diesen Einschränkungen waren dann wieder Klassen-Elemente, nämlich die Sachen, die dann im Range jeweils sein dürfen. Und solche Properties, die eingeschränkt waren,

auf eben, dass im Range eine ganz bestimmte Klasse war und ich kann da Existenz oder eben All-Quanturen davor schreiben, solche Property-Restriktionen, die kommen eben jetzt in OWL ebenfalls noch mit dazu. Und damit kann ich dann noch komplexere Klassen definieren. Und da kann ich auf der einen Seite hergehen und kann Werte-Restriktionen machen. All-Values und Some-Values from, das entspricht dem All-Quantur und dem Existenzquantur,

wie wir sie in ALC kennengelernt hatten. Und wir kriegen ein was Neues dazu. Has value, das ist quasi so eine Art konstanten Definition. Da kann ich eine Rolle festlegen auf genau einen bestimmten Wert, auf ein bestimmtes Individu. Und dann kriege ich dazu noch Kardinalitätsrestriktionen.

Das ist das N in dieser Bezeichnung oder in dieser Bezeichnung der dazugehörigen Beschreibungslogik. Und zwar kann ich hier gehen und kann eine Rolle bezüglich der damit in Bezug stehenden Elemente einschränken bezüglich ihrer Kardinalität generell. Und ich kann eine minimale und eine maximale Kardinalität hier auch noch angeben

und das entsprechend begrenzen. Also das bietet mir noch weiteren Raum, noch kompliziertere semantische Ausdrücke hier letztendlich zu definieren. Schauen wir uns als erstes mal die Geschichte mit Has value an, kennen wir noch nicht. Ich habe Ihnen das mal hier oben drüber in Beschreibungslogik aufgeschrieben, wie das aussehen würde.

Also meine Lehrveranstaltungen, Haralds Lehrveranstaltungen, die werden subsummiert von oder sind eine Teilmenge von der Propertyeinschränkung. Wenn ich das Propertye wird gehalten von betrachte und dahinten einsetze, wird gehalten von wem, nämlich genau von mir, dem Individu um Harald. Das soll das sein, das sind genau meine Lehrveranstaltungen.

Da schränke ich quasi das Propertyein auf einen ganz bestimmten Wert. Und aufschreiben tue ich das mit all, indem ich eine Klasse hier definiere, meine Lehrveranstaltungen, das ist eine Subklasse von und dann habe ich eine Restriktion. Restriktionen beziehen sich hier immer auf Properties, deshalb hier Restriction on Property, dann muss ich hinschreiben, welches Property hier eingeschränkt wird

und dann kann ich sagen, welches soll denn die Konstante sein, auf die ich hier abbilde, also die Wertzuweisung, das soll dann ich sein, die Resource, das wäre dann die Resource Harald. In Turtle hingeschrieben sieht es wie immer viel, viel einfacher aus. Ich habe hier Haralds Lehrveranstaltung, das ist eine Klasse und das ist eine Subklasse von und dann definiere ich mir eine All Restriction.

Auf das Property wird gehalten von und setze dort das Wert ein, nämlich ein Individu um, nämlich mich, also Harald. Also damit kann ich hergehen und kann Klassen definieren, indem ich jetzt Einschränkungen bezüglich des Wertebereichs von Properties mache, und zwar auf eine Konstante, auf ein Individu um.

Dann habe ich noch die beiden Quantoren, Allquantur und Existenzquantur, wie wir sie eigentlich aus der Beschreibungslogik schon kennen. Hier habe ich beispielsweise hingeschrieben, Sie sehen es hier wieder in Grau, über dem Fenster Wein, dazu gehört alles oder das ist alles,

das den Hersteller als Hersteller einen Winzer hat, kann ich jetzt folgendermaßen aufschreiben. Ich definiere mir wieder die Allklasse Wein, das ist eine Subklasse von auf das Property hat Hersteller und alle quasi Werte sollen den Wert Winzer haben. Und damit definiere ich mir sämtliche, sollen zur Klasse Winzer gehören.

So rum gehört es. Und damit definiere ich mir quasi eine neue Klasse Wein, deren Hersteller quasi oder da kommen sämtliche Weine dann rein, deren Hersteller zu der Klasse Winzer gehört. Also logisch und Sie sehen, man kann damit dann recht komplizierte Dinge ausdrücken.

Das werden Sie vor allem dann im Übungsblatt merken, was man damit nicht alles anstellen kann. In Törtel sieht das Ganze wieder nicht weniger schwierig aus. Also Wein ist eine Klasse und das ist eine Subklasse einer Property Restriktion auf das Property hat Hersteller und alle Werte sollen zur Klasse Winzer gehören. Man muss hier wieder nur auf die Klammerung achten.

Achten Sie auch darauf, dass eben innerhalb dieser leeren Knoten quasi das letzte Element nicht notwendigerweise von einem Punkt abgeschlossen sein muss und ganz am Ende dann wieder ein Punkt steht. Das Gleiche geht auch noch dann mit dem Existenzquantor. Da hätten wir dann some values from. Das Beispiel, das ich ausgesucht habe, ist dann Tiere sind eine Subklasse von irgendwelchen Dingen,

bei denen es auch welche gibt, die sich von pflanzlicher Nahrung ernähren. Ist jetzt nicht so tiefgreifend, aber sehr schön, um das Ganze dann umzusetzen in Aul. Also ich definiere die Klasse Tiere. Das ist eine Subklasse auf eine Property Restriktion auf das Property ernährt sich von.

Und dann muss eben mindestens eines sich von pflanzlicher Nahrung ernähren. Ok, als Törtel ausgedrückt, auch wieder einfach. Ich habe die Tiere als Subklasse einer Restriktion auf das Property ernährt sich von. Und einige some values from müssen dann vom Typ pflanzlicher Nahrung sein.

Das kannten wir schon. Also wir können hier Rollen einschränken einmal auf eine Konstante, also auf ein Individuum. Und wir können Rollen einschränken auf Klassen und können dann dazu sagen, dass es entweder alle Individuen der Klasse quasi betreffen muss oder eben mindestens ein Individuum, von dem in einer bestimmten Klasse mit dabei sein muss.

Also mit dem Alquantor und dem Existenzquantor eingeschränkt in dem Sinne, dass das Ganze dann am Ende für diese Beschreibungslogik, die wir verwenden, noch entscheidbar bleibt. Was wir jetzt noch nicht kennen, was ich Ihnen quasi gerade schon erzählt hatte, das sind die Kardinalitätsrestriktionen.

AllCardinality schränkt quasi Properties insofern ein, dass deren Extension, wenn wir damit eine Klasse definieren, quasi eine exakte Anzahl an Mitgliedern oder Elementen vorgegeben wird. Bei AllLight, was allerdings mittlerweile schon veraltet ist, kann man nur zwischen eins und null unterscheiden. Und man kann Ober- und Untergrenzen bezüglich der Kardinalität angeben.

So kann ich hier beispielsweise sagen, ein Streichquartett, das ist irgendwas, das vier Mitglieder hat. Oder es ist eine Teilmenge von den Dingen, die vier Mitglieder haben. Und dann definiere ich mir hier die Klasse Streichquartett und dann definiere ich eine Restriktion auf das Property hatMitglied. Und da sage ich dann, die Kardinalität, die soll in diesem Falle vier sein,

also die darf nicht mehr als vier Mitglieder haben. Wenn ich das in Turtle hinschreibe und ich möchte auch hier mit reinschreiben, dass ich hier das vier vom Typ Non-negative integer sein soll, dann wird das Ganze natürlich ein bisschen länger. Aber ich habe hier das Streichquartett als Klasse und das ist die Subklasse einer Restriktion.

Auf das Property hat Mitglied mit der Kardinalität vier, wobei vier vom Typ ist Non-negative integer. Und hier habe ich natürlich entsprechend auch den Namensraum mit rein gebastelt. Deshalb ist das Ganze ein Stückchen länger geworden. Ja, und so funktionieren Kardinalitätsrestriktion.

Und damit kann ich auch minimale, also Ober- und Untergrenzen entsprechend mit angeben. Beispielsweise könnte ich sagen, dass eine Fußballmannschaft dann mindestens aus elf Mitgliedern besteht. Das könnte ich dann mit dem MinCardinality-Operator irgendwie mit angeben. Und könnte dann aber sagen, beispielsweise wenn irgendjemand eine Fußballmannschaft hätte,

die jetzt definiert ist, dass sie nur definitiv neun Mitglieder hat, die würde dann dieser Definition widersprechen, dass eine Fußballmannschaft mindestens elf Mitglieder haben muss. Und so könnte man wieder Inkonsistenzen in einer solchen Wissensrepräsentation sehr leicht entdecken. Also dafür sieht jetzt AUL.DL entsprechend noch Möglichkeiten vor. Und das sind Dinge, die jetzt über ALC, die wir schon kennengelernt hatten, hinausgehen.

Gut, wir müssen uns noch ein paar Eigenschaften von Rollen noch mit anschauen. Bisher haben Rollen ja keine Eigenschaften. Wir ahnen schon zumindest, dass wir sagen können, Rollen müssen in irgendeiner Art und Weise auch funktional sein können, wenn ich das definiere. Es gibt noch ein paar mehr. Auf der einen Seite gibt es natürlich Rollen-Hierarchien.

Genauso wie es das RDF-Subproperty gibt, gibt es hier ein AUL-Subproperty. Und man kann inverse Rollen definieren, also quasi das Gegenteil Aussagen, hatten wir auch schon kennengelernt, über AUL-Inverse. Und man kann sagen, dass es identische Rollen gibt. Das ist dann wieder für jetzt unterschiedliche Ontologien,

die ich miteinander in Bezug setzen möchte, relativ wichtig. Also hier kann ich jetzt beispielsweise sagen, ich habe ein Property, wird hergestellt aus, und das wäre ein Subproperty von besteht aus. Andererseits kann ich dann aber auch sagen, dass dieses Object Property, wird hergestellt aus, das Inverse ist zu dem Object Property, wird verarbeitet zu.

Und das ist jetzt mehr, als ich sagen kann, über ein RDFS-Property. Deshalb ist das auch ein AUL-Property und ein AUL-Subproperty, weil ich sonst mit dem Schlussfolgern entsprechend Probleme kriege, weil ich dann wieder zwischen AUL-Semantik und RDF-Semantik hin und her geworfen werde. Also hier versucht man das relativ strikt in dieser Beziehung dann auch zu trennen,

wenn man sich die Semantik dann dazu anguckt. Das Ganze wieder in Turtle, ganz einfach, wird hergestellt aus. Das ist ein Object Property, ist das Subproperty von besteht aus, wird verarbeitet zu, ist ebenfalls ein Object Property, und das Inverse zu, wird hergestellt aus.

Und in der gleichen Art und Weise kann ich jetzt hier noch angeben, transitive Properties. Transitiv ist klar. Also wenn A ist Teil von B und B ist Teil von C, dann folgt daraus, A ist auch ein Teil von C. Also Transitivität kann ich festlegen. Ich kann über das Schlüsselwort Transitive Property, über das Schlüsselwort Symmetric Property,

kann ich symmetrische Properties definieren. Nachbarschaftsbeziehungen sind ja immer symmetrisch. Wenn A Nachbar von B ist, dann ist auch B Nachbar von A. Funktionale Properties kann ich festlegen, bei denen eben klar ist, dass der Wertebereich, also das worauf ich Abbilder eindeutig sein muss. Das heißt, A hat die Mutter B und A hat die Mutter C.

Daraus muss die Gleichheit von B und C folgen, sonst ist es nicht funktional. Und ich kann auch inversfunktionale Properties angeben. Bei denen ist das Ganze nicht im Wertebereich, sondern im Bildbereich. Das heißt, B ist Mutter von A, C ist Mutter von A. Und davon muss die Gleichheit von A, A ist gleich B folgen.

Okay, versuchen wir mal ein Beispiel, das ein bisschen komplizierter ist, oder eben diese Sachen mit beinhaltet, aus unseren bereits schon bekannten oder für unsere Weinontologie vielleicht relevanten Teile mit zusammensetzen. Eine transitive Rolle. Ich definiere hier ein Leaked In, geografisch gesehen, und sage, das ist ein transitives Property. Die Domain soll sich beziehen auf alles Mögliche.

Also das möchte ich jetzt nicht einschränken, was jetzt irgendwo liegt. Weil es kann natürlich sein, dass ein Land oder ein Ort quasi innerhalb eines Landes liegt. Es kann aber auch sein, dass beispielsweise der Notebook irgendwo geografisch liegt. Also das möchte ich hier nicht so genau einschränken. Deshalb habe ich hier ein All Thing in der Domäne.

Und Range ist dann auf jeden Fall immer eine Region. Und ich sage jetzt hier beispielsweise, dass ich die Region Rhein-Hessen definiere, und die liegt in Hessen. Und ich definiere auch, Hessen wäre auch eine Region, und die liegt in Deutschland. Und durch Inferenz kann ich natürlich dann darauf schließen, dass Rhein-Hessen natürlich auch in Deutschland liegt.

In Turtle sehen Sie, geht es wieder ganz einfach. Leaked In ist eine Object Property. Die ist gleichzeitig auch eine transitive Property. Ich gebe Domain und Range an als Thing und als Region. Rhein-Hessen ist eine Region und liegt in Hessen. Hessen ist eine Region und liegt in Deutschland. Also sehr schöne Geschichte. Und damit habe ich eigentlich das Vokabular von aul.dl,

die Syntax letztendlich schon durch. Wir können jetzt hergehen. Wir können komplexe Klassen definieren mit Hilfe von einmal Klassenkonstruktoren mit dieser Disjunktion, Konjunktion und Komplement. Und wir können hergehen und können diese Property-Einschränkungen ebenfalls zur Klassendefinition benutzen.

Und damit wird dann quasi die semantische Ausdrucksstärke dieser Beschreibungssprache schon recht groß. Gut, schauen wir uns zwei Sachen noch dazu an. Das eine ist natürlich, wir müssen uns die Varianten von aul noch mal kurz anschauen, was gehört wozu von dem, was wir jetzt kennengelernt haben.

Und danach, der wichtigste Punkt, der letzte, den wir uns noch anschauen, ist dann auch auf jeden Fall die aul-Semantik, die dahinter steckt. Das Bild kennen Sie ja schon mit den drei verschiedenen Varianten aul-lite, aul-dl und aul-full. Das hier oben können Sie sich merken, das ist veraltet aul-lite. Das benutzt man nicht mehr. Es ist relativ ausdrucksschwach für diese Berechnungskomplexität,

diese exponentielle, die man hier hat. In aul-2 hat man quasi Teilmengen von aul-dl, die sogar in polynomialer Zeit die Berechnung einer Entscheidbarkeit, also quasi die Entscheidbarkeit der Enthaltenseins oder der Erfüllbarkeitsrelation gewährleisten,

was wesentlich schneller ist. Deshalb benutzt man dieses shift-d oder aul-lite heutzutage nicht mehr. Der Vollständigkeit halber ist es aber hier noch erwähnt. Schauen wir uns aul-full als erstes an. Da kann natürlich alles von dem, was wir jetzt kennengelernt haben, uneingeschränkt genutzt werden. Alle aul- und alle rdfs-Sprachelemente.

RDFS sein, sonst funktioniert es irgendwie nicht. Aber wie ich Ihnen schon gesagt habe, es ist schwierig, weil eben diese Typentrennung nicht mehr durchgezogen wird, was ist Klasse, was ist Rolle, was ist Individuum. Außerdem gibt es solche Dinge wie Owl-Thing ist eigentlich dasselbe wie eine RDFS-Resource, auf der anderen Seite dann auch wieder nicht, aber man muss es irgendwie gleich behandeln. Owl-Class und RDFS-Class ist im Prinzip

dasselbe, allerdings für eine Owl-Class kann ich diese ganzen semantischen Einschränkungen machen, für eine RDFS-Class nicht. Und wie setze ich die dann irgendwie miteinander in Beziehung? Data-Type-Property ist eine Subklasse von Object-Property und Object-Property ist eigentlich dasselbe wie ein RDFS-Property, hat man letztendlich festgelegt. Und das macht das Leben natürlich nicht einfacher, insbesondere dann, wenn Sie dann auch hergehen können und

sämtliche Klassen und Properties ebenfalls auch noch als Individuum behandeln können und Aussagen drüber machen können, dann wird das Ganze entsprechend dann noch hinreichend kompliziert und nicht mehr berechenbar und keine Beschreibungslogik in dem Sinn. Owl-DL, dort kann ich die Owl-Syntax, die wir gerade kennengelernt haben, verwenden. Ich

kann einen bestimmten Teil der RDFS-Syntax verwenden, auch die, die wir gerade kennengelernt haben. Was ich nicht verwenden darf, ist RDFS-Class und RDFS-Property, das auf gar keinen Fall. Aber ich darf natürlich RDFS-Subclass oft zum Beispiel verwenden, das haben wir ja jetzt auch viel verwendet und RDF-Type, um die Klassenzugehörigkeit

zu sagen und Ähnliches, das kann ich hier verwenden. Klassen und Rollen müssen explizit als solche immer definiert werden und eine Klasse kann niemals gleichzeitig eine Rolle sein, also hier herrscht eine strikte Typtrennung. Und dann gibt es noch die weitere Einschränkung, konkrete Rollen, also diese Data-Type-Properties, die dürfen

nicht transitiv, symmetrisch, inverse oder inverse funktional definiert werden. Das ist auch ein bisschen komisch, kann ich normalerweise auch nicht, weil ich dort ja eine Entität mit einem Literal in Verbindung bringe und transitiv auf so eine Verbindung wie beispielsweise, nehmen wir mal an, das Hasso-Platner-Institut ist zehn Jahre alt und jetzt müsste ich,

um eine transitive Aussage daraus machen zu können, zehn Jahre ist irgendwas alt, das macht irgendwie keinen Sinn. Also aus dieser Hinsicht ist genau diese Komplex, diese Konstruktion eben nicht erlaubt. Und des Weiteren darf man eben solche Zahlenrestriktionen, Kardinalitätsrestriktionen, die dürfen nicht mit

transitiven Rollen, deren Subrollen oder Inversen davon verwendet werden. Und dann ist man auf der sicheren Seite, dann ist Aul.dl in diesem Sinne entscheidbar, vollständig und korrekt. Und Aul.Lite, nur der Vollständigkeit halber, obwohl veraltet, da sind halt einige Dinge, die etwas komplizierter sind, dann nicht mehr mit erlaubt. Dazu gehört

beispielsweise Has-Value und solche Sachen, Zahlenrestriktionen, eben Dinge, die eben jetzt die Berechnungskomplexität dann am Ende hochtreiben würden. Okay, das sind die drei alten Dialekte. Was kann ich damit letztendlich machen, wenn ich Wissensrepräsentation betreibe? Also ich kann Anfragen stellen, natürlich an Aul-Ontologien, an Aul-Datenbasen,

Wissensbasen. Ich kann auf der einen Seite natürlich, wenn ich jetzt mich im terminologischen Bereich, also nur im Bereich der Ontologie bewege, kann ich fragen, sind zwei Klassen irgendwie äquivalent? Ist die eine Klasse in der anderen Klasse enthalten? Also die Subsumptionsprobleme, Subklassenbeziehungen. Ich kann fragen, sind zwei Klassen eventuell disjunkt? Ich kann nach der globalen Konsistenz einer

Wissensbasis fragen, also ist dort quasi, was herrscht dort vor? Haben wir eine Widerspruchsfreiheit? Ist die Wissensbasis erfüllbar? Gibt es also eine Interpretation, ein Modell für diese Wissensbasis? Dann herrscht Klassenkonsistenz vor. Also ist eine Klasse tatsächlich konsistenz? Oder ergibt sich eben letztendlich, dass die

Klasse äquivalent ist zu Aul-Nothing, also das heißt zum Button-Element, dass sie leer ist. Und wenn eine Klasse dann irgendwann mal leer ist, obwohl man sie komplex konstruiert hat, kann es durchaus sein, dass man eben irgendwo einen Modellierungsfehler hat, der nicht notwendigerweise so einfach zu erkennen sein sollte, wie der hier in der unteren Zeile, in der ich hier schreibe,

dass Wein die Subklasse eines Getränks ist. Und Wein soll dazu auch noch disjunkt sein zur Klasse Getränk. Das macht natürlich dann keinen Sinn. Dann komme ich am Ende heraus, dass Wein nichts ist, also die leere Klasse ist. Und damit hätte ich eben eine Klassenkonsistenz. Dann kann ich assertionale Anfragen machen. Also Anfragen, die mit

Individuen mit der A-Box zu tun haben. Ich kann fragen, gehört eine Instanz zu einer bestimmten Klasse dazu? Gehört ein Individuum zu einer vorgegebenen Klasse? Ich kann die Klassenextension berechnen, also ich kann die Individuen einer Klasse aufzählen und ich kann alle Individuen suchen, die jetzt in einer Klasse enthalten sind. Ich kann

Rollenüberprüfungen machen. Werden zwei gegebenen Individuen jetzt über eine Rolle verknüpft oder nicht? Und ich kann auch eine Rollenextension machen. Das heißt, ich suche alle Individuen, Paare, die jetzt über eine bestimmte Rolle, über ein Property miteinander verknüpft werden. Und das sind so die Grundanfragen, die man an AOL-Wissensbasis auf der einen Seite im terminologischen Bereich, also in der

Ontologie obendrein in der Wissensbasis stellen kann oder eben im assationalen Bereich. Mit solchen Arten von Aufgaben werden wir jetzt also auch in den Übungsblättern und generell, wenn wir uns mit AOL beschäftigen, rechnen müssen. Jetzt werden uns eine ganze Reihe von Werkzeugen an die Hand gegeben. Sie müssen natürlich alles nicht nur auf dem Papier machen, sondern jetzt wird es interessant, weil jetzt gibt es

sogenannte Editoren für Wissensbasen, für komplexe Wissensbasen, die Sie benutzen können. Da können Sie eben eher gehen, entweder das Ganze tatsächlich in einer Wissensbeschreibungssprache schreiben oder Sie werden damit über eine grafische Benutzeroberfläche unterstützt. Portagee haben Sie ja vielleicht schon kennengelernt, als Sie mit RDF und RDFS gearbeitet haben. Das wird jetzt bei AOL unabdingbar,

dass man mit Portagee arbeitet, weil man dort dann auch gleich in diesem Editor, wenn man einen Reasoner mit verknüpft hat, direkt die Konsistenz meiner Klassendefinition prüfen kann. Es gibt noch weitere Sachen. Swoop beispielsweise ist auch so ein lightweight Ontologie-Editor, der schon seit einiger Zeit jetzt nicht mehr aktiv weiterentwickelt

wird, ist aber noch über die Google-Code-Homepage erreichbar, kann man immer noch benutzen. Portagee in der neuesten Version ist normalerweise das Werkzeug der Wahl, weil da kann ich dann auch direkt mit AOL 2, das wir morgen kennenlernen werden, arbeiten. Und dann gibt es noch eine Reihe von Ontologietools auf der Kaon oder Kaon 2 Webseite. Können Sie sich mal angucken. Da gibt es viele unterschiedliche Tools,

was ich mit Ontologien dort machen kann, wie ich sie editieren kann, wie ich sie in Programmiersprachen mit verwenden kann, also Libraries und lauter solche Sachen. Wichtig für uns sind dann noch die Differenzmaschinen, also die eigentlichen Reasoner. Das sind die jenigen Programme, die in der Lage sind, Konsistenzen, Klassenkonsistenzen, wissensbare Konsistenzen, Schlussfolgerungen

und Ähnliches auszurechnen. Es gibt eine ganze Reihe. Hier sind nur einige davon aufgezählt. Die bekanntesten Palette ist ein sehr bekannter oder Fact oder Racer, die sind bekannt. Ich habe Ihnen in den Materialienseiten zur heutigen Vorlesung einfach die Wikipedia-Seite zu Semantic Reasoners angegeben und dort finden Sie eigentlich immer die aktuelle Aufzählung derjenigen, die es im Moment gibt, insbesondere auch noch mit einer Zuordnung.

Was können die denn alle? Können die beispielsweise Aul-Entailment, also Schlussfolgerungen mit Aul, können die Schlussfolgerungen mit Aul II und Ähnliches, da sind dann immer so Tabellen mit dabei, in denen die Sachen, die diese Reasoner tatsächlich können, entsprechend angegeben sind. Und wenn wir dann anfangen und machen

in den Übungen, sollen die Konsistenz von Wissensbasen oder die Konsistenz von Regeln, die wir gegeben haben, prüfen oder die Erfüllbarkeit, dann müssen wir den entsprechenden Reasoner benutzen, um solche Sachen dann tatsächlich ausrechnen zu können. Okay, das ist nur eine Seite gewesen, in denen die Werkzeuge genannt werden. Anschauen müssen Sie sich die schon selber. Was uns noch fehlt, wir hatten ja schon gesehen,

Aul-DL ist ein Stückchen größer als die Beschreibungslogik ALC, die wir bisher kennengelernt hatten. Wir müssen natürlich deshalb noch einen Blick auf die Aul-Semantik werfen, weil Aul ist jetzt nicht nur ALC, Aul ist ja Scheundee oder Schreuk, wie wir gesehen haben. Deshalb hier noch mal zur

Erinnerung, die einzelnen Buchstaben, wie diese Beschreibungslogiken jetzt entsprechend ihrer unterschiedlichen Operatoren benannt werden. Und wir sehen dann schon, dass bei Aul eine ganze Menge dieser Sachen mit dabei sind. Konjunktion haben wir also hier, wir haben die Werterestriktion, den Existenzquanto, wir haben Top und Button-Element, wir haben die Negation, wir haben die

Beziehungsjunktion, wir haben eine existenzielle Restriktion haben wir hier, Zahlenrestriktion haben wir dabei, wir haben Menge von Individuen, damit sind Nominale, also Aufzählungsmengen gemeint. Wir haben Beziehungshierarchien, wir haben inverse Beziehungen. Das Einzige, was wir noch nicht dabei haben, sind qualifizierte Zahlenrestriktionen. Das

kommt nämlich dann erst bei Aul-2 mit dazu. Und was hier auch nicht steht, sind Rollenkonstrukturen, R, das kommt dann auch noch bei Aul-2 mit dazu. Hier noch mal die Buchstabenzuordnung, da sehen Sie ALC, dazu hatten wir uns schon die Sonntagsrunde, die Semantik angeguckt. Scheuen Klammer auf D für Aul-1, was wir uns jetzt angucken müssen,

da kommt die Subrollenbeziehung dazu, da kommen abgeschlossene Klassen, also Nominale dazu, das O, da kommen inverse Rollen dazu, das I und da kommen Zahlenrestriktionen, das N mit dazu und dann noch Datentypen, für die ein bisschen besondere Regeln gelten, weil Datentypen, dafür lässt sich die entsprechende Semantik nur sehr schwer entsprechend

formalisieren. Das haben Sie schon gemerkt, als wir das versucht haben, Datentypen mit reinzubringen bei der RDFS- Semantik. Okay, das versuchen wir irgendwie mit reinzubringen und da müssen wir jetzt mal schauen, was ist denn jetzt genau die Beziehung mit Aul und ALC? Das heißt, was kann man denn jetzt hier von Aul mit Hilfe von ALC

repräsentieren, wofür wir die Semantik eigentlich schon mal festgelegt haben? Das heißt, alles, was ich mit ALC machen kann, dafür muss ich jetzt nicht nochmal neue irgendwelche Festlegungen treffen. Und zwar mit ALC kann ich natürlich Klassen repräsentieren, Rollen repräsentieren, Individuen repräsentieren, was ich auch mit Aul kann. Ich kann die Klassenzugehörigkeit und die Instanzen von Rollen, also Rolleninstanzen definieren. Ich habe Thing, ich habe Nothing, also ich habe das

Top- und Bottom-Element. Ich habe die Klasseninklusion, ich habe die Äquivalenz und die Disjunktheit. Ich habe die Intersection, das ist also die Konjunktion. Ich habe Union-Off, das ist die Disjunktion. Ich habe das Komplement, also die Negation. Ich habe dann diese zwei Quanturen, Alquantur und Existenzquantur als

Rolleneinschränkung und ich habe Range und ich habe Domain als Festlegung, was ist Bildbereich, was ist Wertebereich einer Rolle. Also das kann ich ohne Probleme machen, das kann ich in ALC abbilden. Jetzt muss ich nur noch das, was ich hier noch nicht mit drin habe, dafür muss ich jetzt noch die Semantik

festlegen. Und dazu gehört beispielsweise als allererstes, wenn ich aul.dl als Scheundee eben als diese Beschreibungslogik abbilden möchte. Ich brauche ein Konstrukt dafür, dass ich eben same as die Gleichheit von Individuen ausdrücken kann. Also same as gibt an, dass zwei Individuen Namen genau dasselbe Element bezeichnen, schreibe ich

dann in der entsprechenden Beschreibungslogik als a ist gleich b hin und ich kann mir auch in der Prädikatenlogik ein Gleichheitsprädikat definieren als Erweiterung, dass genau diese Semantik, nämlich die Gleichheit zwischen Individuen herleitet, das werden wir hier in dem Sinne nicht weiter vertiefen und genauso funktioniert mit different from, wenn ich die

Gleichheit habe, kann ich durch die Negation der Gleichheit in der Prädikatenlogik quasi genau das Gegenteil ausdrücken, nämlich dass zwei Individuen tatsächlich unterschiedlich sind. Sie sehen, was wir hier also machen, ist wir versuchen die Semantik dieser Scheundee Beschreibungslogik mit Hilfe der Prädikatenlogik auszudrücken. Für die Prädikatenlogik haben

wir letztendlich schon eine Semantik, die wir einfach hier in dem Sinne übernehmen. Das heißt, wir machen uns das Leben hier sehr, sehr einfach. Abgeschlossene Klassen ist schon ein bisschen komplizierter. Da geht es eben darum, dass ich eine Klasse genau durch die Aufzählung ihrer Instanzen beschreibe. Die dazugehörige Syntax in der Beschreibungslogik

sieht dann so aus, dass ich die Klasse definiere und sage, die ist äquivalent zu einer Aufzählung hier in geschweiften Klammern. Und wenn ich das dann eben versuche, das Gleiche auszudrücken in der Prädikatenlogik, dann muss ich eben diese Aufzählungsklasse, die genau aus den Individuen A, B und C besteht, abbilden auf

die Prädikatenlogik und würde dann sagen, ich definiere eine Klasse, deren Mitglieder X für die gilt. Alle X sind genau dann in der Klasse C, wenn X entweder A ist oder X ist B oder X ist C. Und sonst nicht. Das wäre quasi die eigentliche Übersetzung

der Funktionalität in die Prädikatenlogik. Genauso muss man es dann letztendlich mit Value machen. Has Value, da geht es dann darum, dass man zwingt, dass eine Rolle quasi auf ein ganz bestimmtes Individuum anzuwenden ist. Und das kann ich mithilfe des Existenzquantors

definieren und mithilfe von One-off, also mit einer Aufzählungsklasse. Wenn Sie in die Aufzählungsklasse nur ein Individuum reintun und den Existenzquantor verwenden, dann können Sie quasi mit den Bordmitteln, die Sie schon haben, Beschreibungslogik, ALC plus dann hier oben diesen One-off-Operator können Sie dann auch in der Prädikatenlogik aus- oder noch nicht mehr in der Prädikatenlogik,

also Sie können dann mit diesen Bordmitteln quasi genau diese Funktionalität von Has Value nachempfinden. Können wir uns in der Übung dann noch mal genauer angucken oder denken Sie erst mal selber drüber nach, aber es ist letztendlich ganz einfach mit diesen beiden Konstruktoren dieses Has Value hinzubekommen. Kardinalitätsrestriktion hatten wir noch nicht. Da geht es eben darum,

Dinge auszudrücken, wie hier beispielsweise eine Prüfung kann höchstens zwei Prüfer haben. Kann ich in der Beschreibungslogik natürlich hinschreiben? Prüfer, das ist eine Subklasse von, dann hat Prüfer und das sollen aber weniger als zwei letztendlich nur da vorhanden sein, also Prüfung kann höchstens zwei Prüfer haben. Kann ich in der

Prädikatenlogik jetzt folgendermaßen ausdrücken, wenn ich das hier unten hinschreibe? Schauen Sie sich den Ausdruck mal an und überlegen Sie mal, was wir hier gemacht haben. Bezieht sich natürlich nur genau auf den Fall hier oben. Der Trick ist

ganz einfach der, wenn ich oben sage, also eine Prüfung hat höchstens zwei Prüfer, gehe ich unten her und definiere quasi eine Prüfung als etwas, das genau drei Prüfer hätte und verneine das. Also damit sage ich, dass dann eine Prüfung niemals drei

Prüfer oder noch mehr haben kann, indem ich hier definiere drei Individuen. Alle drei sind hier unten unterschiedlich und ich sage dann, wenn ich die in irgendeiner Besetzung zusammensetze, das kann nicht so sein, dass das gleichzeitig gilt. Das heißt, dass alle drei gleichzeitig diese Prüfung abnehmen und damit quasi durch diese

Verneinung, die ich hier vorne noch habe, drücke ich dann quasi dasselbe aus, wie hier oben die Beschreibungslogik, in der ich sage, eine Prüfung hat maximal zwei Prüfer. Kompliziert, ein bisschen von hinten durch die Brust ins Auge, aber es geht letztendlich nur darum, dass man versucht, solche Situationen abzubilden. Wir machen das hier natürlich nur an Beispielen, man

kann das auch allgemein zeigen. Darauf habe ich hier verzichtet, weil das wird das Ganze dann sehr kompliziert. Rollenkonstruktoren gibt es auch noch, also RDFS Subproperty, das kennt man in der Beschreibungslogik, kennen Sie ja, Property Hierarchien, sehr, sehr einfach darstellen. Mit dieser

Subsumptionsbeziehung kann ich in der Prädikatenlogik, wenn ich es darauf abbilde, auch sehr einfach abbilden und ich sage dann, dass Property R ist quasi im Property S enthalten, genau dann, wenn für alle x und alle y folgt, dass ich die Beziehung x, R, y habe, also dass x über die Rolle R mit y in Beziehung steht, dann muss es

auch auf jeden Fall mit der Rolle S miteinander in Beziehung stehen. Also das kann man schön abbilden über die Implikation. Und genauso macht man es mit der Rollenequivalenz, da muss man eben beide zeiten. Das heißt, R ist in S enthalten und S ist in R enthalten, dann zeigen. Die inverse Rolle, hier

macht man es auch noch mal genauso, das tauscht man einfach zwischen diesen beiden Rollen, die zueinander invers sind, quasi hier Wertebereich und Bildbereich miteinander aus, auch jetzt hier in der Prädikatenlogik. Transitive Rollen, da muss ich natürlich quasi dann dieses Beispiel, wie immer, bemühen, mit den drei unterschiedlichen Elementen, die ich hier miteinander über die Rolle in

Bezug setze. Ich sage, wenn x und y über R verbunden sind und gleichzeitig y und z, dann impliziert das auch, dass x und z über diese Rolle verbunden sind. Das heißt, dann sind sie transitiv. Die Symmetrie entspricht nichts anderes, dass ich sage, dass R äquivalent ist zum Inversen von sich selbst und Funktionalität und

inverse Funktionalität ist auch eine sehr schöne Geschichte. Da muss man, wenn man sich's anguckt, noch mal ein bisschen drüber nachdenken. Aussagen werden hier getroffen über die Relation R, die hier auf der rechten Seite dieser Gleichung oder dieser Angabe, der in Beschreibungslogik steht. Und da sage ich dann ganz einfach, Funktionalität bedeutet

ganz einfach, dass der Werte-Bereich dieser Relation maximal quasi ein irgendein Element sein kann. Irgendein Element, deshalb steht hier auf der anderen Seite dieses Subsumptionszeichen, das Top-Element. Das kann also alles Mögliche sein. Und für die inverse Funktionalität heißt es genau dasselbe. Das heißt, dass eben hier der Grundbereich dieser

Rolle alles Mögliche sein kann, also nicht der Werte-Bereich. Also es ist genau umgedreht. Deshalb ist hier ein R und ein Minus dran, das inverse dann in dem Fall. Schauen Sie sich's noch mal an, lassen Sie sich's auf der Zunge zergehen, wenn man das normalerweise so in einem Buch findet und nicht erklärt bekommt, muss man relativ lange

drüber nachdenken, bis einem klar ist, wie das Ganze gemeint ist. So, also kann man dann letztendlich sagen, wenn wir uns die Semantik für AOL betrachten. In AOL.DL haben wir auf der einen Seite alles, was auch in ALC ist, plus dann noch die Gleichheit und Ungleichheit zwischen Individuen, abgeschlossene Klassen, Zahlen, Restriktionen, Subrollen, Rollen,

Äquivalenzen, Inverse und transitive Rollen. Fehlen uns nur noch die Datentypen und da ist das Ganze ein bisschen kompliziert. Das heißt, da hält man sich ein bisschen schwangig. Man erlaubt bestimmte Sachen, nämlich man erlaubt die Verwendung von Datentypen im zweiten Argument konkreter Rollen in der A-Box. Wer von Ihnen kann mir sagen, was damit gemeint ist?

Datentypen, die ich erlaube, sind ja beispielsweise Non-negative integer, String, Date oder irgend sowas. Und in der A-Box, wenn ich konkret irgendeinem Individuum irgendeinen Wert zuweise oder eine quasi Wertzuweisung über eine Rollenbeziehung mache

und einen typisierten Datenwert verwende, dann ist er natürlich immer quasi das zweite Argument, weil das erste Argument ist dann immer ein Wert, entweder ein String, eine Zeichenkette oder eben eine Zahl. Und dahinter kommt dann irgendein Datentyp. Also das Datentyp wird erlaubt quasi als zweites Argument einer konkreten Rolle in der A-Box.

Ja, was haben wir dann noch? Ja klar, eine Menge konkreter Daten. Das heißt, konkrete Daten hatten wir auch noch nicht kennengelernt. Damit ist gemeint, ein Literal, ein typisiertes Literal, das also noch einen Datentyp hat. Das kann eine geschlossene Klasse bilden. Und das Problem, dass wir damit generell haben, also Datentypen lassen sich nicht ohne Weiteres in der

Prädikatenlogik ausdrücken, aber man kann die Prädikatenlogik, Semantik entsprechend erweitern, dass man damit halbwegs klarkommt. Aber es ist immer irgendwie ein bisschen ein Stolperstein. Deshalb muss man da etwas vorsichtig sein, insbesondere wenn man so Semantik mit einbeziehen möchte, dass bestimmte Datentypen mit unterschiedlichen Wertzuweisungen zueinander identisch sind.

Das hatten wir ja auch kennengelernt. Also wenn man jetzt angenommen, das gibt es nicht. Aber man hätte Inches, man hätte zwei verschiedene metrische Systeme oder man hat jetzt reelle Zahlen und man hat man hat ganze Zahlen und man versucht zu sagen eins als reelle Zahl ist dasselbe wie eins als ganze Zahl. Also das sind dann unterschiedliche Datentypen, aber die bezeichnen

den gleichen Wert. Das muss man dann alles entsprechend festlegen in der Semantik. Wenn man alles versucht, zusammenzufassen als quasi als Übersicht, was man jetzt bei AUL.DL mit drin hat, da hat man einmal sämtliche Dinge, die man in ALC hat. Dann kommen dazu das N hier in Klammern

kommt dazu. Das heißt, man hat hier Zahlenrestriktion jetzt nicht auf die einzelnen Klassen, die hier hinter den Rollen noch sind, sondern nur direkt auf die Rollen. Das N kommt also da noch dazu. Man hat nominale Aufzählungsklassen. Man hat inverse Rollen kommen dazu. Subklassen, Klassenequivalenz. Dann kommen dazu an Rollenaxiomen

kommt dazu die nicht Subklassen, sondern Subproperties, Transitivität. Und man hat noch weitere Axiome für die A-Box, nämlich Instanz, dann Rolleninstanz, Gleichheit und den entsprechenden Unterschied. Plus dann kommen jetzt noch

quasi was machen die einzelnen Konstrukturen mit denen ich eine Klasse konstruieren kann. Wir haben hier Intersection. Wir haben hier Union, also für Konjunktion, Disjunktion. Wir haben das Komplement jeweils dann eben noch mit dem Beispiel und dem dazugehörigen Beispiel. Wenn ich das Ganze übersetzen würde in die Prädikaten Logik, dann kommt die Aufzählungsklasse,

die Quantoren, Alquantur und Existenzquantur und die Kardinalitäten, die ich hier entsprechend verwenden kann. Und neben den Klassen Konstruktoren gibt es da noch eine Reihe von Axiomen. Das heißt, ich kann hier Subklassenbeziehungen. Ich kann hier äquivalente Klassen definieren.

Ich kann Disjunktheit definieren. Ich kann Gleichheit von Individuen festlegen. Ich kann den Unterschied von Individuen festlegen. Ich kann Subproperty-Beziehungen festlegen, äquivalente Properties, inverse Properties, transitive Properties, funktionale Properties und inverse funktionale Properties.

Und damit habe ich es dann eigentlich ziemlich geschafft. Wichtige Aussage am Rande noch. Es ist das beliebige Schachteln von Konstrukturen erlaubt. Nämlich dann wird es nur interessant, auch wirklich komplexe Konstrukturen zu verwenden. Damit kann ich dann so schöne komplexe Aussagen machen, wie das, was hier in der ersten Zeile oder unter dem ersten Anstrichpunkt steht.

Kann einer von Ihnen das in natürliche Sprache übersetzen? Welche Klasse damit gemeint ist?

Also es muss doch schon mal irgendwie um Personen gehen, oder? Irgendwelche Einsprüche? Nö.

Gut, was, was ist denn jetzt mit den Personen? Was sagt denn jetzt der zweite Teil hier aus, den wir haben? Wenn Sie jetzt statt dem und ein oder sagen, dann passt es. Genau.

Also das sind alle Personen, deren Kinder entweder alle Doktor sind oder die Kinder haben deren Kinder wiederum von denen eines der Kinder wieder auch Doktor ist. Kompliziert auszudrücken, aber einfach schön hinzuschreiben mit Beschreibungslogik. Ja, man braucht eigentlich nur

generell die Subsumption oder die generelle Klassen Inklusion, weil die Gleichheit oder Klassequivalenz kann man ja letztendlich hier durch wechselseitige Inklusion zeigen. Und da kann man die Äquivalenz zur Prädikaten Logik natürlich sehr, sehr einfach zeigen. Wenn Sie jetzt hergehen und genau diesen schönen, diese schöne Zeile aus der Beschreibungslogik

übersetzen wollen nach Aul, sieht das Ganze so aus. Das heißt, hier sehen Sie, dass man, wenn man das Ganze dann als Aul RDF schreiben muss, natürlich sehr unübersichtlich wird, weil wenn Sie jetzt angefangen hätten und ich hätte Ihnen das gezeigt, ohne dass da oben und Sie hätten es lesen müssen, wäre es natürlich wesentlich komplizierter geworden.

Und wir wollen uns das Ganze auch gleich nochmal angucken als Törtel. Und hier sehen Sie, dass wir uns schon dem Aufbau von Klammergebirgen nähern. Also was haben wir hier? Wir definieren eine Klasse als Lehrerknoten. Wir haben ja jetzt erst mal nur hier auch vorne dran keine Klassendefinition und sagen, die Klasse wird definiert als

Schnittmenge, als Intersection of und zwar haben wir einmal eine Person. Und als zweites haben wir eine Property Restriktion auf das Property has child, wobei wir sagen, dass wir alle Werte sein sollen aus. Und jetzt kommt eine Disjunktion, also Aul Union of entweder

Doktor oder dann kommt wieder eine Restriktion auf das entsprechende Property has child. Und da können einige Werte, also existenziell quantifiziert werden als Doktor. Also es ist noch ein ganzes Stück schwieriger, das Ganze als Törtel, also genauso als Törtel, genauso wie aus

der RDF-Serialisierung dann quasi hier oben diese Kurzform in dieser deskriptiven Form herauszulesen. Deshalb werden wir immer mit beiden arbeiten. Sie müssen ein bisschen da ein Gefühl für kriegen, das werden Sie jetzt in der Übung dann entsprechend auch sehen. Und damit sind wir quasi mit dem heutigen Programm Syntax Werkzeuge und Semantik

erst mal durch. Wir werden uns dann beim nächsten Mal Gedanken drum machen, was uns noch fehlt bei Aul 2. Wir werden sehen, dass Aul 1 hier in dem Fall, das ist die kleinere Eule, da kriege ich gerade Scheundee hin und Aul 2 ist noch wesentlich mächtiger, ohne dass ich dabei so viel mehr an Berechnungskomplexität quasi dafür bezahlen muss, denn ich kriege dazu noch

Rollenkonstruktoren. Ich kann also auch komplexe Rollen aus einfachen Rollen zusammensetzen. Denken Sie an solche Sachen wie der Bruder meines Vaters ist mein Onkel. Also Onkel wird definiert als Bruder des Vaters. Das sind ja beides Rollen. Schöne Sachen, die ich jetzt hier in Aul 1 nicht definieren kann. Aber mit Aul 2 klappt das Ganze.

Nachzulesen wie immer hier in den beiden Büchern entweder das Semantik-Web-Grundlagen von Pascal Hitzler oder dann eben, wenn Sie es auf der beschreibungslogischen Ebene sich angucken wollen im Description Logic Handbook. Da steht das Ganze dann entsprechend drin. Und ich habe natürlich auch alles wieder irgendwie zusammengefasst, was wir heute genannt haben

in den Materialien zur heutigen Vorlesung. Das war es. Vielen Dank.