legen wir los. Ich begrüße Sie wieder recht herzlich heute zu unserer siebten Vorlesung Semantik Web. Die Halbzeit haben wir also eigentlich schon überschritten, 14 Vorlesungen haben wir insgesamt. 13 werden es wahrscheinlich nur werden, weil ich ja nächste Woche nicht da sein werde, sondern eben wie schon angekündigt im Blog, nächste Woche bin ich auf dem International Symposium

on Multimedia und werde dort, wie ich im Blog geschrieben habe, eine unserer Forschungsarbeiten vortragen. Deshalb fällt in der kommenden Woche die Vorlesung aus und wir haben uns mit der Übung sogar eigentlich, dass eben morgen, da wir morgen auch nicht da sein werden, morgen eben auch die Übung ausfällt und dafür die Übung in der kommenden Woche ist.

Also Mittwoch keine Übung, Dienstag drauf keine Vorlesung, Mittwoch drauf Übung. Also die Übung wird dann quasi das letzte Ereignis in dem Semester sein. Das heißt, Sie haben noch ein bisschen Zeit für die Übungsaufgaben und es gibt natürlich dann auch noch im Anschluss an die letzte Übung ein neues Übungsblatt, in dem dann Dinge,

die wir heute in der Vorlesung machen werden, entsprechend noch eingeübt werden müssen. Wo waren wir stehen geblieben? Das letzte Mal, also wir sind immer noch hier im Unterkapitel Wissensrepräsentation und Logik und hatten uns immer noch auf dem Ontologielabel bewegend, hatten wir uns das letzte Mal Aussagenlogik und Prätikatenlogik

nochmal etwas näher geführt, insbesondere eben mit beachtungsweise Semantic Web. Also für uns ist eben Logik nichts anderes als die Wissenschaft vom logischen Schlussfolgern. Also das wird hier auf axiomatische Beine gestellt und das ist für uns besonders wichtig in dem Zusammenhang. Da hatten wir einige Dinge wiederholt und wir sind heute so weit, dass wir sagen,

das, was wir kennengelernt haben über Aussagenlogik und Prätikatenlogik, das wollen wir jetzt eigentlich auf unsere Semantic Web Sprachen anwenden und die unterste Ebene, wo wir da tatsächlich arbeiten und auch schon Schlussfolgern können beziehungsweise Konsistenz, Inkonsistenz prüfen können. Das ist eben hier die RDF, RDFs Ebene.

Und deshalb heißt das Kapitel RDFs Semantik, wobei eigentlich, das ist jetzt falsch, auf meiner Folie das S in Klammern sein sollte, weil das gilt natürlich für RDF und RDFs. Ja, das Kapitel an sich ist nicht ganz so lange wie das letzte Kapitel. Wir werden aber doch einiges an Zeit brauchen, weil einige kleine

Unerfreulichkeiten drinnen vorkommen werden, die nicht so einfach zu verdauen sind, insbesondere viele neue Variablen, Abkürzungen, mit denen dann irgendwas ganz Schlimmes gemacht wird. Also ich möchte schon vorwarnen, es ist ein bisschen komplizierter, ist aber im Endeffekt, wenn wir durch sind, werden Sie sehen, das ist eigentlich gar nicht so schwer. Wenn RDFs eine Semantik hat, kann ich sehr, sehr leicht feststellen,

ob irgendwelche Aussagen logisch konsistent oder inkonsistent sind. Und ich habe dann eben jetzt auch tatsächlich unser Fundament, unser Wissensrepräsentationsfundament auf logische Beine gestellt, sodass ich dann wirklich auch maschinell rangehen kann und über die Anwendung von oder mit syntaktischen Mechanismen dann beweisen kann, ob Aussagen korrekt oder falsch sind.

Und das ist genau das, was wir eben machen wollen. Das unterscheidet ja generell unsere Form der Wissensrepräsentation mit RDF beziehungsweise mit logikbasierten System von Wissensrepräsentation, die jetzt nur auf einer rein traditionellen, auf einem Datenbankmodell basieren oder ähnlichem.

Okay, als erstes müssen wir mal klären, Sie kennen noch dieses schöne Explosionsbild des Golfs von der RDF-RDFS-Vorlesung. Zunächst müssen wir erst mal klären, warum ist denn eigentlich überhaupt eine Semantik für RDFS nötig? Die eine Sache ist natürlich, wie ich gerade gesagt habe, es wäre sinnvoll und schön, wenn ich quasi RDF-RDFS

auf Basis der Logik stellen könnte, um damit rechnen zu können. Aber das Ganze hat natürlich auch einen Hintergrund. Das Problem ist, dass die Spezifikation, wie sie vom W3C ausgegeben worden ist, jetzt keine formale Definition der RDFS-Semantik enthält. Das heißt, da haben wir Pech gehabt. Das Ganze ist nur informell letztendlich so beschrieben, wie es ist.

Und was sich daraus natürlich ergeben hat, war Hersteller veröffentlichen Tools, die irgendwie auf RDF basieren oder mit RDFS arbeiten. Und das gibt es aber in Kompatibilitäten, weil eben jetzt genau diese formale Definition einer Semantik in dem Fall fehlt. Ganz besonders schlimm oder kompliziert war das im Fall von Triple Stores.

Also stellen Sie sich einen Triple Store vor. Wir haben die gleichen RDF-Daten in unterschiedlichen Triple Stores. Wir haben die gleiche Sparkle-Anfrage, bekommen aber leider Gottes unterschiedliche Ergebnisse. Das kann passieren. Ganz genau deshalb aus dem Grund, weil eben keine formale Definition dieser Semantik tatsächlich existiert. Und ja, der Grund war eben klar,

unterschiedliche Interpretationen von RDF-Dokumenten bzw. RDF-Anfragen. Und daher ist also klar, wir brauchen natürlich eine formale Semantik, auch wenn sie vom W3C als solches jetzt nicht formal korrekt definiert worden ist. Aber es gibt sie mittlerweile auch. Und was wir dafür natürlich benötigen, ist klar,

wir wollen es auf das Fundament der Logik stellen. Also die mathematische Logik bei uns dient der Formalisierung des korrekten Ziehens von Schlussfolgerungen. Das wollen wir auch mit RDF und RDFS machen können. Also legen wir damit einfach mal los. Was brauchen wir dafür? Wir hatten das schon kennengelernt. Eine Logik besteht ja immer aus einer Menge von Aussagen,

über die dann Schlussfolgerungen gezogen werden sollen. Das war eben diese Menge von Sätzen. Erst hatten wir es, glaube ich, auch das letzte Mal genannt. Und dazu gibt es dann noch zu dieser Menge von diesen Sätzen eine Schlussfolgerungsrelation, die wir ebenfalls definieren müssen. Dann Schlussfolgerungsrelation im Englischen. Wenn Sie das mal sehen, nennt sich Entailment Relation. Die kann man jetzt auch komplett formal definieren.

Wir hatten das letztes Mal mit Beispielen definiert, mit Kleinvieh und Großvieh, wenn Sie sich erinnern. Aber letztendlich ist die Schlussfolgerungsrelation definiert oder ist definiert als Teilmenge über dem kathesischen Produkt aus der Potenzmenge sämtlicher Sätze, die wir hier haben und den Sätzen an sich. Also was bei rauskommt, wir haben am Anfang

von so einer Schlussfolgerungsrelation immer eine Menge von Sätzen stehen und haben hinter der Schlussfolgerungsrelation einen Satz stehen, der aus dieser Menge von Sätzen letztendlich folgert. Und man braucht diese Schlussfolgerungsrelation eben, um Schlussfolgerungen zu ziehen. Also es kommt dann hier raus, dass man aus irgendwelchen Mengen von Sätzen neue Sätze Schluss folgern kann.

Und das Ganze setzt dann eine Logik zusammen, wie wir es kennen. Eben hier Menge von Sätzen plus Schlussfolgerungsrelation und sowas müssen wir jetzt auch entsprechend für RDF und RDFS machen. Um dann natürlich Schlussfolgerungen ziehen zu können, brauchen wir als erstes eine modelltheoretische Semantik.

Modelltheoretische Semantik, das hatten wir letztes Jahr auch durchgesprochen, eingeführt worden, der Begriff von Tarski. Und das bedeutet eben, dass man oder dass die semantische Interpretation unserer in der Logik definierten Vokabularien eben quasi, dass diese Bedeutung genau mit der definierten

Interpretation in einem Modell gleichgesetzt wird. Dass ich also ein formales Modell konstruiere, in dem diese Interpretation abgeleitet werden kann. Generell jegliche Interpretation sieht immer so aus, dass ich einmal eine Menge, eine Grundmenge habe, über die ich arbeite, diese Domain of Discourse und dann noch eine Interpretationsfunktion und was ich dort machen muss.

Also diese Domain of Discourse, die sollte letztendlich nicht leer sein. Die Interpretationsfunktion I, die bildet auf der einen Seite immer atomare Konzepte irgendwie auf die Domain of Discourse ab und genauso natürlich dann auch Relationen, atomare Relationen auf eine Teilmenge des

kathetischen Produkts der dieser Domain of Discourse. Also das nur ganz formal. Das reicht noch nicht ganz. Ich brauche also diese Domain of Discourse plus die Interpretationsfunktion und dann muss ich letztendlich auf der anderen Seite noch irgendwie entscheiden, wann ist denn irgendwas wahr und wann ist was falsch? Das heißt, man braucht einen Satz von Kriterien zur Entscheidung, ob eben jetzt eine konkrete

Interpretation, die man gegeben hat, einen Satz aus der Menge aller Sätze erfüllt. Das ist die sogenannte Modellrelation. Die brauche ich dazu dann auch noch. Und was ich feststellen möchte, ist eben, dass eine bestimmte Interpretation I, wenn sie eben den Satz erfüllt, ein Modell dieses Satzes ist. Das hatten wir schon kennengelernt. Das ist also quasi erst mal soweit nur Wiederholung.

Und dann müssen wir dazu eine Schlussfolgerungsrelation definieren, die dann genau sagt, dass ein Satz S aus der Menge aller Sätze folgt aus einer Menge von Sätzen, S als Teilmengemenge der Sätze S, genau dann, wenn eben für jede Interpretation, die jeden Satz S Strich aus dieser Menge oder Teilmenge von S

erfüllen, dann auch ein Modell von kleinen S ist. Also wenn man sich das im großen Bild vorstellt, sieht man, kann man ein bisschen schlecht lesen. Also wir haben jetzt hier beispielsweise aus einer Menge S1 und S2 folgt S genau dann quasi, wenn eben jetzt die Modelle von S1 und die Modelle

von S2, der Bereich, der sich überlappt, genau dann, wenn es sowas gibt, dann haben wir eine Schlussfolgerungsrelation, dass tatsächlich es ein Modell für S gibt, der eben auch die beiden anderen erfüllt. Also das Ganze jetzt nur mengentheoretisch noch mal dargestellt. Wie so eine Schlussfolgerungsrelation in Modell theoretischen Semantik im Allgemeinen

definiert wird. Das ist alles noch allgemein, hat noch relativ wenig mit RDF und RDFS zu tun. Wir wollen uns aber mal anschauen. Was wir nämlich jetzt machen müssen, ist wir müssen auf der einen Seite erst mal feststellen, ja, was sind denn unsere Sätze in RDF und RDFS? Wie sehen denn die Interpretationen aus und welche Kriterien gelten denn dafür, ob was wahr oder falsch ist?

Das müssen wir jetzt der Reihe nach quasi durcharbeiten. Schauen wir es uns mal an. Also wir fangen als erstes mal an mit den Sätzen oder Aussagen in RDFS. Was sind die Sätze und Aussagen in RDF? In RDF haben wir Triple. Ich schätze, Sie wollten Triple sagen,

genau. Also jedes Triple, irgendwie auch bestehend aus Subjekt, Prädikat und Objekt, das ist ein Satz. Also das ist ganz einfach. Die Triple selbst beschreiben sich oder werden beschrieben mit Hilfe eines Grundvokabulars, das wir jetzt definieren müssen. Und da müssen wir dann sagen, was kann denn alles Subjekt sein? Was kann denn alles Prädikat sein oder Körperdesign und was kann denn alles

Objekt sein? Das heißt, als erstes brauchen wir in diesem Grundvokabular V sämtliche Uris enthalten sein. Es müssen natürlich auch leere Knoten mit irgendwie benannt werden können, also Blanknotes und Literale. Das sind also die Grundbestandteile unseres Vokabulars, das wir brauchen. Und dann können wir sagen, was ist

denn jetzt genau ein solches Triple? SPO. So ein Triple ist stets immer Element aus folgender Relation. Also hier haben wir wieder kathesisches Produkt. Vorne setzen wir ein, was denn jetzt das Subjekt sein kann. Das Subjekt kann entweder sein irgendeine beliebige URI oder ein Blanknote. Dann was kann denn das Property sein?

Property muss immer eine URI sein und was kann das Objekt sein? Objekt kann jetzt sein eine URI, ein Blanknote oder eben ein Literal. So zusammengesetzt bildet das also unser Grundvokabular und wir können schon mal definieren, was ist denn eigentlich ein Triple? Wir wissen jetzt noch nicht, was ein zuglässiges Triple ist und ähnliches, aber wir können schon mal sagen, wie ein Triple prinzipiell aussieht.

Das ist jetzt nur ein einziges Triple, aber normalerweise, wenn wir eine Wissensbasis haben, haben wir natürlich sehr, sehr viele Triple und die bilden, wie wir wissen, ein RDF Grafen und so ein RDF Graf ist in der Regel eine endliche Menge von Trippeln. Und da kann also ein einzelner Satz, also da kann ein einzelnes Triple drin sein, da

können viele Trippel drin sein und letztendlich ist jeder RDF, da bin ich eins zu weit gegangen, noch eins, noch eins, noch eins, wieder eins zu weit gegangen. Jeder RDF Graf, das wollte ich dazu nur sagen, der ist ein Satz.

Gut, also wir haben das Vokabular, haben wir schon mal da, die Sätze. Was wir jetzt brauchen, ist die Schlussfolgerungsrelation und die Schlussfolgerungsrelation, die muss uns also dann angeben, ist es möglich aus irgendeinem bestimmten Grafen einen anderen Grafen zu Schlussfolgern. Also das letztendlich soll sie irgendwie sagen.

Also wir haben eine Schlussfolgerungsrelation und die gibt an, wann irgendein RDF Graf G Strich aus einem RDF Grafen oder aus mehreren folgt. Ja, unser Definition einer modelltheoretischen Semantik haben wir also eine Menge von Interpretationen definiert und

legen fest, das ist jetzt noch das nächste, was wir machen müssen, wann eine solche Interpretation tatsächlich auch ein Modell des Grafen ist. Also wann kriegen wir tatsächlich dann wahre Aussagen oder erfüllende Aussagen hin? Das nur noch mal als illustrierendes Beispiel für das, was wir gerade gemacht haben. Wir haben Sätze, die Sätze werden dann irgendwie interpretiert. Das ist das hier unten drunter. Und da kann man dann

feststellen, in den Interpretationen gibt es dort Modelle in den Interpretationen. Und damit eine solche Schlussfolgerungsrelation gilt, muss genau unten in der Menge der Interpretationen eben hier so eine Schnittmenge. Die darf nicht leer sein. Wenn wir jetzt die Modelltheoretische Semantik, also festlegen, was ein Modell für RDF und RDFS ist, gehen wir folgendermaßen vor.

Wir machen das schrittweise. Wir definieren als erstes mal für einfache Grafen eine sogenannte einfache Interpretation. Dann müssen wir hier gehen und müssen speziell auf RDF noch mal Rücksicht nehmen und definieren eine RDF Interpretation. Und darauf aufbauend definieren wir dann noch eine RDFS Interpretation.

Wir werden gleich noch merken, warum das so schrittweise gemacht worden ist. Letztendlich sind die ganzen Sachen ineinander dann enthalten. Und man kann dann sagen, wenn man eine RDFS Interpretation hat, dann ist das auch eine gültige RDF Interpretation und eine gültige RDF Interpretation ist auch eine gültige einfache Interpretation.

Genau, das ist das, was wir jetzt im Folgenden machen wollen. Grundvokabular und Sätze haben wir schon festgelegt, was das ist. Funktioniert also aus Trippeln. Trippeln haben wir zugeordnet, einzelnen Bestandteilen, Schlussfolgerungsrelationen, wie die im Prinzip aussieht, haben wir auch schon geklärt. Wir wissen, dass wir irgendeinen Graf aus einem anderen Graf herleiten wollen. Und jetzt brauchen wir dafür natürlich bestimmte

Kriterien, die wir an der Interpretation festmachen wollen, unserer Trippel. Und dafür müssen wir diese Interpretation natürlich erst einmal aufschreiben. Wie sieht denn so eine Interpretation eigentlich aus? Und das ist der nächste Punkt. Die Interpretation in drei verschiedenen Stufen hatten wir gesagt. Einfache, RDF, RDFS Interpretation.

Und wir fangen hier an mit der einfachen Interpretation für ein Vokabular V. Und die besteht jetzt aus einer ganzen unterschiedlichen Menge von Interpretationen, nämlich ich muss jeden einzelnen Bestandteil, den ich hier betrachte, Ressourcen, Literale, Properties etc., die muss ich einzeln interpretieren. Und ich fange

natürlich an, als erstes mit meiner Interpretation für die Ressourcen und sage eben, IR ist eine nicht leere Menge von Ressourcen oder auch eben jetzt hier das Diskurs, Universum von I über das ich arbeite. Dann brauche ich eine Menge von der Properties von I in meiner Interpretation. Und neben den Properties

brauche ich natürlich auch noch, wenn ich eine Property habe, das geht ja immer von irgendeinem Subjekt zu irgendeinem Objekt. Und das Ganze nennt man dann quasi die Extension dieses Properties. Deshalb wird die Interpretation, die wir hier brauchen, I und Kleine X unten dran genannt, das ist die sogenannte Extensionsinterpretation.

Und da geht es halt darum, jedem einzelnen Property eine Menge von Paaren aus IR, also aus den Ressourcen, dann zuzuordnen. Also die Extensionsinterpretation sieht so aus, dass ich einem Property irgendwie ein Paar aus den Ressourcen zuordne.

Also Ixt von P ist dann die Extension des Properties P, wobei ich Ixt hier dann vergessen habe, tief zu setzen. In der Mitte. Das ist aber nicht so sonderlich schlimm. Ok. Was ich jetzt habe, ist, ich habe sämtliche Ressourcen interpretiert, ich habe sämtliche Properties interpretiert und ich habe auch die

Funktion, die eben hinter den Properties steckt, wo und wo, nach wo, bildet dieses Property ab, im speziellen Sinne, ebenfalls durch die Extensionsinterpretation festgelegt. Jetzt muss ich natürlich noch hergehen. Ich kann nicht so ohne weiteres beispielsweise mit Uris arbeiten, sondern ich muss natürlich irgendwie meine Uris hier in die Menge

der Ressourcen abbilden, mit denen ich arbeite. Also brauche ich dazu eine Interpretationsfunktion, die nennt sich hier jetzt Ies und das ist eine Funktion. Die bildet die Uris aus dem Vokabular V in eine Vereinigung der Mengen Ir und Ip ab. Also Properties und Ressourcen. Wir werden später da noch sehen, dass die Ip, die Menge der Properties, eine Teilmenge

der Ressourcen ist, dass es aber jetzt erst mal weniger will, sondern es geht generell darum, Uris von Ressourcen und Properties irgendwie auf Ressourcen und Properties in dieser Interpretation abzubilden. Gut, wir haben Ressourcen, Properties, wir haben Uris, die gemapped werden.

Blanknotes fehlen noch, die kommen dann später noch speziell und wir brauchen noch Literale. Also wir brauchen auch eine Interpretationsfunktion, die jetzt Literale aus V irgendwie abbildet in die Menge der Ressourcen. Und da geht es erst mal um die sogenannten getypten oder typisierten Literale, denen tatsächlich auch ein Datentyp entsprechend zugeordnet worden ist.

Und weil man hier unterscheidet zwischen typisierten Literalen und untypisierten Literalen, gibt es natürlich auch noch eine Funktion LV, die ist jetzt eine Teilmenge der Menge der Ressourcen und da sind eben die Literale drin oder die Menge der Literalwerte, die eben die ungetypten Literale aus unserem Vokabular enthalten.

Also fassen wir noch mal zusammen. Wir haben IR, das sind die Ressourcen, wir haben IP, das sind die Properties. Dann haben wir die Extensionsfunktion, da wird eben eine oder da wird eben Property quasi Domain und Range, von wo nach wo wird hier abgebildet, zugeordnet. Also jeweils sind wir eine spezielle Ressource vorne und hinten. Dann brauchen wir

eine Funktion, die die URIs abbildet auf die Menge der Ressourcen und Properties und dann müssen wir noch die Literale irgendwie interpretieren. Und da unterscheiden wir eben getypte Literale, die wir auf Ressourcen abbilden und dann eben auch noch hier die ungetypten Literale. Das sind jetzt Interpretationen, die hängen natürlich in gewisser Weise

irgendwie miteinander zusammen. Dafür muss ich eine Funktion definieren, nämlich die Interpretationsfunktion, die wir ganz am Anfang gesehen hatten. Die definieren wir als nächstes und wir definieren jetzt als erstes eine einfache Interpretationsfunktion, Punkt I nennen wir die, die eben jetzt alle im Vokabular V enthaltenen Literale und URIs auf Ressourcen

und Properties abbildet. Dabei gehen wir noch mal kurz durch, wie das für die Literale heißt. Also ungetypte Literale, die jetzt einfach nur mit Hochkomma A da stehen, die werden eben auf A, ein Symbol A abgebildet. Dann ungetypte Literale, die jetzt noch hier eine Sprachangabe hinten dran haben, die werden auf ein Paar

abgebildet und in dem Paar steht dann drin vorne das Literal, hinten die Sprachangabe. Das ist nur eine Formalie, die wir brauchen. Und dann müssen wir weiterhin jedes getypte Literal eben abbilden mithilfe der Funktion IL, die wir hatten. Und wir müssen jede URI mit der Funktion IS abbilden jetzt auf eine Ressource. Und damit haben wir jetzt

Literale und auch URIs abgebildet auf Ressourcen. Das Ganze kann man sich an einem Übersichtsbild besser veranschaulichen, als jetzt hier nacheinander, wie wir es geschrieben haben. Wir können es noch bei der Reihe nach hier in diesem Bildchen angucken. Da sieht man sehr gut, da sieht man sehr gut. Die URIs werden eben jetzt hier mithilfe der Funktion IS abgebildet,

einmal in die Menge der Ressourcen und einmal in die Menge der Properties. Die Literale werden abgebildet, wenn sie typisiert sind, direkt in die Ressourcen und wenn sie nicht typisiert sind, in eine spezielle Teilmenge der Ressourcen. Und dann haben wir hier unten noch die Extensionsfunktion, die setzt an den Properties an und bildet dann oder fügt

zu jedem Property letztendlich dann ein Paar aus den Ressourcen zu, von welcher Ressource nach welcher Ressource eben dieses Property dann entsprechend abbildet. Also so kann man sich das am Ende dann veranschaulichen. Und dann haben wir oben das Vokabular,

drunter haben wir die entsprechende Interpretation und was wir jetzt dann am Ende noch machen müssen, ist festlegen, ja wann sind denn jetzt bestimmte Teile des Vokabulars, die jetzt hier einen Satz bilden, wann sind die gültig, wann sind die nicht gültig, wann sind die wahr, wann sind die falsch. Und wir müssen also entscheiden, wann ist eine solche Interpretation

ein Modell eines Grafen. Generell, wenn wir von oben anfangen, kann man sagen, es ist klar, Modell eines Grafen ist eine Interpretation dann, wenn sie Modell für jedes einzelne Trippel in diesen Grafen ist. Das heißt also, wenn wir hier oben einen Graf haben, der aus den zwei Trippeln besteht, die ich gerne so grafisch eben zusammen darstellen kann, muss ich erst mal zeigen,

dass eben diese Interpretation für jedes einzelne Trippel unten drunter auch gilt, gültig ist. Und die Frage ist jetzt, wann ist eine Interpretation ein Modell eines Trippels und das ist eigentlich relativ einfach, genau dann, wenn in diesem Trippel S, P, O, S, P und O aus unserem Vokabular,

das wir definiert haben, stammen, also aus V sind, aus dem Grundvokabular und wenn genau das Paar bestehend aus der Interpretation von S und der Interpretation von E, also das sind eigentlich Uris, wenn die interpretiert werden, werden das entsprechend Ressourcen oder eben bei O können das auch Literale sein,

die müssen entsprechend dann Element sein der Extensionsfunktion des interpretierten Properties. Property ursprünglich auch, eine URI wird gemapt auf ein Property, Extensionsfunktion verbindet damit immer zwei Paare, entweder zwei Uris oder eine URI und ein Literal oder Blank Note in dem Fall.

Also wenn genau das gilt, dann haben wir eine gültige Interpretation, dann ist eben diese Interpretation tatsächlich auch ein Modell unseres Trippels. Das kann man jetzt wieder sehr schön grafisch darstellen, noch mal ebenfalls aus dem Buch Grundlagen Semantik Web

herausgezogen, da ist das sehr schön dargestellt, da wird eben so ein Trippel, S, P, O, dahinter einen Punkt, also ein Turtle, dem wird jetzt zugeordnet, erstmal dem Subjekt, die Interpretation des Subjekts aus der Menge der Ressourcen, dann dem Objekt, quasi die Interpretation dieses Objekts, auch irgendwo aus der Menge der Ressourcen, dem Property,

wird die Interpretation des Properties irgendwo aus der Menge der Properties zugeordnet und über dessen Extensionsfunktion, komme ich eben dazu, existiert tatsächlich dieses Paar S, I, O, I in meiner Extensionsfunktion oder nicht und danach kann ich dann entscheiden, ob das war oder falsch ist.

Eigentlich ist der Sachverhalt ganz einfach, es ist nur relativ kompliziert, das Ganze jetzt hier entsprechend dann formal auszudrücken. Eigentlich haben wir damit schon fast alles für die, in Anführungszeichen, einfache Interpretation. Das Einzige,

was uns jetzt noch fehlt, ist eine zusätzliche Möglichkeit, Blank Notes ebenfalls noch in diese Interpretationsfunktion mit reinzumappen. Also, Berücksichtigung von leeren Knoten und dazu wird eine zusätzliche Funktion, die wird hier immer mit A bezeichnet, eingeführt und die bildet dann quasi Blank Notes

ab auf Ressourcen. Also, A ist eine Funktion, die alle B-Notes auf Elemente von I, R eben von den Ressourcen abbildet. Und jetzt wird die Interpretation erweitert, also I plus A, das ist jetzt die neue Interpretation und ein Blank Note kann ich dann entsprechend interpretieren mit der neuen Interpretationsfunktion I plus A

und weise der dann quasi A von B zu, aus der Funktion, die ich hier oben gerade definiert habe. Und eine Interpretation I ist jetzt Modell eines RDF Grafen G. Wenn es ein A gibt, so dass alle Trippel bezüglich I plus A dann wahr werden. Also auch nur noch mal formal das Ganze erweitert, damit leere Knoten quasi mitbehandelt

werden können. Und jetzt hat man, jetzt ist man so weit, dass man sagen kann, wie sieht denn jetzt unsere valide Interpretation aus? Wann kann ich denn jetzt ein Modell oder sagen, wann ist eine Interpretation ein Modell? Und zwar kann ich jetzt sagen, dass ein Graph G2 einfach aus einem Graph G1 genau dann folgt. Wenn jede einfache Interpretation,

so wie ich sie gerade definiert habe, die eben Modell von G1 ist, auch Modell von G2 ist, dann haben wir quasi eine entsprechende Schlussfolgerung, eine einfache Schlussfolgerung ziehen können. Das Ganze ist jetzt recht formal und wir sollten uns das mal am besten an einem Beispiel angucken,

damit uns irgendwie klar wird, was da gemacht werden muss. Schauen wir uns erst mal den oberen Teil an. Da haben wir ein ganz einfaches RDF Beispiel. Also eine Pizza haben wir hier, die hat bestimmte Zutaten. Zutaten ist hier jetzt ein Lehrerknoten und dem werden dann eine Zutat und jeweils eine bestimmte Menge dieser Zutat zugeordnet, nämlich zum Beispiel 125G,

was wohl für 125 Gramm Mozzarella steht. Jetzt muss ich als erstes hergehen und muss sämtliche URIs, die ich habe mit dieser Funktion IS, mappen auf entsprechende Ressourcen. Ressourcen, deren Namen, die denke ich mir jetzt mal aus. Also IS mappt jetzt beispielsweise HDI Pizza auf die Ressource XI und so weiter. Hat Mozzarella,

wird gemappt auf die Zutat Nü, nee Epsilon, Nü ist das, oder? Egal. HPI hat Zutat, wird gemappt auf Tau, dann hat Zutat, wird gemappt auf, das ist ein Nü auf jeden Fall und die HPI Menge wird gemappt auf J. So IL brauchen wir nicht,

weil wir haben keine typisierten Literale, auch wenn da 125G steht, ist das kein typisiertes Literal, weil da kein XML-Datentyp eben entsprechend dahintersteht. Also das ist eigentlich ein untypisiertes Literal, in dem Fall einfach nur ein String und wir haben einen leeren Knoten, den müssen wir auch mappen, den mappen wir auf die Ressource Epsilon.

Jetzt können wir hier gehen, können sagen, was ist die Menge unserer Ressourcen? IR, das sind eben nicht sämtliche Ressourcen, die ich gerade hier festgelegt habe, inklusive dem untypisierten Literal, das dann natürlich ebenfalls hinzugehört, diese 125G, die werden dann entsprechend dann noch gemappt auf den Knoten Epsilon, brauchen wir dann auch noch, dann haben wir Properties

drinnen, Tau, Nü und Jotta, dann haben wir ein untypisiertes Literal, Menge LV, haben wir auch vorhin definiert mit drinnen und dann natürlich die Extensionsfunktion, die nichts anderes macht, als genau diese Pfeile, die wir oben in den Grafen drinnen haben, repräsentieren, nämlich wir haben einmal einen Pfeil von der Pizza, das war das C,

auf Epsilon und wir haben dann von dem Blank Note einmal einen Knoten auf den Mozzarella, einen Pfeil auf den Mozzarella und einen Pfeil auf die 125G, soweit so gut, das ist jetzt erstmal das Ganze irgendwie in ein Modell gepresst, jetzt müssen wir natürlich noch die Interpretation des Ganzen angeben oder die Interpretationsfunktion,

dazu müssen wir natürlich A entsprechend so wählen, das hatten wir gerade schon angegeben, der Leere Knoten gemappt wird hier aus Epsilon und dann ergeben sich eben die folgenden Tuppel, dass ich einmal hier einen Tuppel habe, hat Pizza, das wird interpretiert und ID1 wird interpretiert und dann kommen zwei Ressourcen raus,

die müssen wiederum sein, Element der Extensionsfunktion, der ersten Funktion, die wir drüben aufgeschrieben hatten, genauso muss es sein für Mozzarella und den Leeren Knoten und genauso muss es sein für die 125G und den Leeren Knoten und die müssen letztendlich Element dieser Extensionsfunktion sein. Und wenn jedes einzelne

eben jetzt Element der dazugehörigen Extensionsfunktion des jeweiligen Properties ist, dann ist auch der gesamte beschriebene Graph wahr und dann ist I entsprechend auch ein Modell des Graphen, bezüglich der einfachen Interpretationsfunktion, die wir festgelegt haben. Sieht furchtbar aus und wenn Sie mitgedacht haben, wenn Sie sich fragen,

ja, und wie konstruiere ich denn dann überhaupt, wenn das überhaupt möglich ist, einen Graph, der jetzt inkonsistent ist, also wo ich hier quasi kein Modell konstruieren kann, wir werden sehen, das geht auch, aber man tut sich mit RDF noch relativ hart, wirklich hier Fehler zu machen, aber auf der anderen Seite

hängt sich eben alles danach auf, gibt es jetzt bestimmte Kanten oder gibt es keine Kanten, bezüglich der Extensionsfunktion oder habe ich jetzt, das werden wir dann noch sehen, irgendwo syntaktische Fehler begangen bei der Zuordnung von XML, Literalen und Datentypen, da können noch Fehler auftreten, aber man kann relativ wenig Fehler machen. Auf der anderen Seite kann ich, das werden wir dann sehen,

insbesondere mit Konstrukten, die mir dann RDFS noch zur Verfügung stellt, wenn es darum geht, Subklassenbeziehungen festzustellen und Subproperty-Beziehungen, da kann ich dann schon einiges machen mit Schlussfolgerungen, aber hier auf dem Level im Moment, ist es noch relativ schwierig. Was ich ja jetzt gemacht habe, ist, also ich kann jetzt jeden beliebigen RDF-Grafen,

egal woher er herstammt, irgendwie einfach interpretieren, aber das Problem, das wir noch haben, ja es gibt ja in RDF bestimmtes RDF-Vokabular, nämlich alle Dinge, die Sie kennen, mit RDF-Doppelpunkt, also die irgendwie aus dem RDF-Nahmensraum stammen, denen ist ja eine bestimmte Semantik hinterlegt,

also RDF-Property oder RDF-Type, was es sonst noch gibt, die haben ja eine bestimmte Semantik und die muss ja auch ausgedrückt werden, das können wir noch nicht. Was wir im Moment wirklich können, ist nur so einfache Trippel ohne jegliche Semantik, ohne RDF-Vokabular und ohne RDFS-Vokabular, wir wissen ja auch noch nicht, was jetzt hier Subklassen, Subproperties oder ähnliche Sachen sind,

das können wir noch gar nicht interpretieren, sondern wir können jetzt solche einfachen Graphen interpretieren. Das ist schon schön und gut und es ist ziemlich schwer, Graphen zu konstruieren, bei denen genau eben jetzt diese einfache Interpretation fehlschlägt und das eben kein Modell des Graphen ist, aber das wird dann schon komplizierter, wenn ich jetzt tatsächlich noch das RDF-Vokabular mit

rein nehme und dann im nächsten Schritt das RDFS-Vokabular. Also merken Sie sich diese Dreistufigkeit, einfache Interpretation, RDF-Interpretation und RDFS-Interpretation unterscheidet sich eigentlich dadurch, dass ich jeweils dann immer nur das entsprechende Vokabular zur einfachen Interpretation mit hinzunehme und das natürlich auch interpretieren muss. Also einmal RDF und einmal RDFS

und deshalb schauen wir uns dann als zweiten Schritt an, wie ich dieses RDF-Vokabular interpretieren muss. Also wie schon gesagt, die einfache Interpretation, die behandelt alle URIs gleich,

die legt keinen Wert darauf, ob das eine jetzt aus dem Namensraum RDF oder RDFS stammt. Aber um jetzt RDF-Vokabular wirklich korrekt behandeln zu können, muss ich eben zusätzliche Anforderungen an die Menge der zulässigen Interpretation stellen, damit das Ganze dann irgendwann ein Modell wird.

Und zwar folgendes ist das RDF-Vokabular, das wir als erstes noch mit abbilden, also wir brauchen natürlich RDF-Type, dann Property, XML-Literal, dann für Listen brauchen wir nil, List, Statement brauchen wir für die Reifikation, genauso wie Subject, Predicate und Object. Und First, Rest, das ist wieder für Listen, genauso wie Sequential,

Back und Altes, das ist für Listen, genauso wie RDF-1, RDF-2 und so weiter. Das muss also entsprechend jetzt noch mitinterpretiert werden. Und das hat natürlich eine ganz bestimmte Bedeutung und da kann ich dann entsprechend auch Fehler machen und dementsprechend muss ich hier zusätzliche Anforderungen an ein Modell stellen.

Ok, schauen wir uns mal als allererstes an, die einfachsten RDF-Vokabularien und überlegen uns was ist denn deren Semantik, erst mal quasi nur auf informeller Ebene. RDF-Type ist klar, da weise ich einem bestimmten URI einen Typ zu, also da geht es um Klassenzugehörigkeit, also Klassenzugehörigkeit, der durch den URI bezeichneten

Ressource. Property ist klar, damit mache ich eine bestimmte URI zu einem Property, also das charakterisiert letztendlich alle URIs, die in Trippeln als Prädikate oder Property vorkommen können. Genauso RDF-Literal, das legt halt fest, dass jetzt ein Ding, das ich hier betrachte, tatsächlich vom Typ Literal sein soll.

Und das ist entweder, also das ist ein vordefinierter Datentyp, ein XML-Fragment, normalerweise, kennen wir ja schon, also irgendein XML-Datentyp, wobei man da unterscheiden muss, kommen wir da noch gleich drauf zwischen wohlgeformten Literalen und nicht wohlgeformten Literalen, aber das bezieht sich wiederum auf diesen XML-Datentyp, den ich hier betrachte. Weil, wenn wir das mal kurz im Kopf,

das habe ich leider nicht aufgeschrieben, sehen wir dann später noch Beispiele zu, Revue passieren lassen. Wenn wir beispielsweise eine Zahl haben, 15 und wollen die als Integer interpretieren, dann funktioniert das ja so, dass ich hochkomme, 15 schreibe, wieder hochkomme und dann diese zwei Mal, dieses Dächchen und dahinter kommt dann der XML-Datentyp

mit dem entsprechenden XML-Schema-Namensraum-Kürzel vorne dran. Und das Ganze definiert mir dann quasi einen kompletten, typisierten Datentyp und das, was vorne drin steht, diese 15, die kann wohlgeformt sein oder auch nicht wohlgeformt sein. Also 15,1 wäre immer noch wohlgeformt, aber 15,1,15,

das kann ich wiederum irgendwie schlecht interpretieren. Das wäre ein nicht wohlgeformtes Literal in dem Fall. Aber es gibt noch andere Möglichkeiten, Dinge, die zwar zulässig, aber nicht wohlgeformt sind und da kommen wir dann noch mal kurz drauf zu sprechen, weil da liegt wieder ein Punkt, wo ich dann tatsächlich auch Fehler machen kann. Okay, aber das ist nur quasi so eine Art

informelle Definition. Jetzt muss ich auch hergehen und muss diese ganzen Sachen formal entsprechend interpretieren. Und da fange ich jetzt an zu interpretieren, also eine RDF-Interpretation im Gegensatz zu einfachen Interpretationen für ein Vokabular V. Das ist eine einfache Interpretation, für das Vokabular V vereinigt mit dem RDF-Vokabular,

wobei diese RDF-Interpretation dann auch folgende Bedingungen erfüllen müssen. Jetzt kommt eine Latte von Bedingungen, die zusätzlich noch erfüllt werden müssen. Okay, schauen wir uns die der Reihe nach mal an. Die sehen erst mal immer sehr kompliziert aus, lesen sich dann aber dann doch relativ einfach. Also, schauen wir uns mal an, es geht darum, dass X

eben jetzt aus der Menge der Properties ist, und zwar genau dann, wenn das Doppel X und RDF-Property, und RDF-Property interpretiert, innerhalb der Extension ist des RDF-Vokabulars RDF-Type. Das heißt letztendlich, wenn X vom Typ Property ist,

dann ist X genau aus der Menge IP, das ist die Festlegung. Also, wir haben vorne hier hinten dran, sehen Sie quasi die Interpretation des Ganzen und wann die zulässig ist, nämlich ganz genau, wenn eben X vom Typ Property ist, dann ist X auf jeden Fall in der Menge der Properties,

das ist das, was das hier sagt. Also, lesen wir unten drunter, was da steht. X ist eine Property, genau dann, wenn es mit der durch RDF-Property bezeichneten Ressource über die RDF-Type-Property verbunden ist. Also das, was ich Ihnen gerade ein bisschen in einfacheren Worten versucht habe zu sagen. Dazu kommt man dann irgendwie, oder das führt automatisch dazu, dass jede RDF-Interpretation

oder für jede RDF-Interpretation dann gilt, dass die Menge der Properties eine Teilmenge ist, der Menge der Ressourcen. Aber das nun nebenher, das ist für uns jetzt weniger wichtig. Okay, also damit haben wir schon festgelegt, was ist ein Property? Dann können wir das entsprechend genau als RDF-Interpretation

festlegen. Als nächstes schauen wir uns Literale an. Und zwar, wir unterscheiden ja wohlgeformte und nicht wohlgeformte Literale. Also, wenn jetzt unser Literal S und dann ist das eben vom Typ RDF, XML, Literal in V enthalten ist und es ein wohlgeformtes XML-Literal ist, dann wird eben jetzt

über die Interpretationsfunktion IL diesem Literal genau der XML-Wert von S zugeordnet. Also das, was hier in den Hochkommandaten entsprechend drinsteht. Und das ist dann auch Teil von LV in dem Fall. Was haben wir ganz unten noch stehen? Da haben wir noch die Interpretation stehen.

Wann ist das Ganze ein Modell? Nämlich genau dann, wenn die Interpretation von S als Literal tatsächlich in der Extension des Properties Type ist. Das heißt nämlich, wenn das hier was vorne steht tatsächlich vom Typ Literal ist. Also das ist letztendlich doppelt gemobbelt, aber formal in dem Fall notwendig.

Dann müssen wir noch unterscheiden, wenn das jetzt kein wohlgeformtes Literal ist, dann ist es auch nicht in dieser Menge LV und dann kriegen wir entsprechend dann auch noch Probleme. Und ein nicht wohlgeformtes Literal ist es genau dann, wenn eben das jetzt nicht vom Typ Literal dann am Ende auch ist. Da kriegen wir nachher

noch mal ein Beispiel zu, das ist jetzt noch ein bisschen unklar und mir gefällt die Definition auch nicht allzu gut, aber ich werde Ihnen zeigen, dass wir das nachher dann entsprechend brauchen. Neben den Dingen, die jetzt hier festgelegt haben, was ist denn jetzt genau ein Property, was ist denn jetzt genau ein Literal und wie funktioniert die Interpretation dieses RDF-Type, gibt es noch zusätzlich dann,

das gibt es auch bei der Logik, eine Reihe von Axiomen und hier gibt es dann bei RDF sogenannte axiomatische Trippel, die wahr sein müssen für die Interpretation. Da gibt es eine ganze Liste, die sehen normalerweise immer so aus und die gelten halt dafür, die sagen dann, dass eben das, was hier auf der, das sind alles Trippel,

werden von klar von links nach rechts gelesen und die sagen eben nichts anderes aus, als alles, was hier als Subjekt steht, das ist vom Typ Property. Also Type, das ist ein Property, Subject, das ist ein Property, Predicate, das ist ein Property, Object ist ein Property, First, Rest, Value und so weiter, also nichts anderes. Also da wird nur jetzt eben

Ressourcen, die speziellen RDF-URIs zugeordnet sind und die hier als Subjekt stehen, die werden als Property interpretiert. Das sagt genau, das sagen diese axiomatischen Trippel. Und wenn ich das beachte, dass das alles Properties sind und mehr möchte ich dann noch gar nicht rein interpretieren, dann kann ich schon sagen, was eine RDF-Folgerung ist,

nämlich als ein Graf G2, RDF folgt ein Graf G1, genau dann, wenn jede RDF-Interpretation, wie wir sie gerade kennengelernt haben, die Modell von G1 ist, auch wie der Modell von G2 ist. Also noch mal zusammenfassend, was wir brauchen jetzt oder was wir bei RDF zusätzlich mit hineingenommen haben,

um das RDF-Vokabular verstehen zu können. Wir müssen wissen, was eine Property ist. Wir müssen wissen, was ein Literal ist. Das haben wir festgelegt durch die Erweiterung unserer Interpretationsfunktion. Und wir haben dann hier noch diese Erweiterung durch axiomatische Trippel, dass eben Teile des Vokabulars, das wir noch zur Verfügung haben, als Property interpretiert werden müssen.

Das ist jetzt nur eine eingeschränkte, keine komplette Semantik oder Interpretation. Das ist nämlich, wenn man es genau betrachtet, eine sogenannte intensionale Semantik. Und es gibt dazu noch eine extensionale Semantik, die beispielsweise noch mehr sagt, was denn jetzt quasi ein First, ein Rest oder so was

quasi in Bezug auf eine Liste definiert. Also die Eigenschaften einer Liste, wie die aufgebaut ist, das haben wir eigentlich auch nur auf einem informellen Level uns angesehen. Und das werden wir jetzt logisch nicht nochmal quasi in Form einer extensionalen Semantik festlegen, sondern wir bleiben auf diesem niedrigen Level der intensionalen Semantik und legen nur fest, was ist ein Property, was ist ein Literal

und wie werden andere Bestandteile des RDF-Vokabulars als Property oder als Vokabular definiert. Mehr brauchen wir dazu nicht. Das andere nämlich genau jetzt auch auf dieselbe Art und Weise festzulegen, was ist denn eine Liste, wie darf die aufgebaut sein und ähnliches. Das ist ziemlich weitführend und das ist relativ kompliziert und würde auch den Rahmen hier sprengen,

weil wir noch lange Listen von Interpretationsfunktionen und Beispielen angucken müssten, um das irgendwie vollständig auszuführen. Deshalb hier also nur eine intentionale Semantik. Gut, jetzt wissen wir, was eben eine einfache Interpretation ist eines Grafen und wir wissen, was eine RDF-Interpretation

eines RDF-Grafen ist. Jetzt kann es natürlich sein, dass eben RDFS-Vokabular noch mit dazu kommt. Kommt ja meistens mit dazu, wenn ich irgendwelche eigenen Datentypen, Klassen und Klassenzusammenhänge definiert habe.

Also RDFS-Interpretationen müssen wir uns noch angucken und dann ist klar, es kommt halt jetzt noch zu dem ursprünglichen Vokabular, das wir uns schon angeschaut haben, noch zusätzlich das RDFS-Vokabular dazu. Also habe ich hier falsch geschrieben, nicht RDF-Vokabular, sondern RDFS-Vokabular V RDFS. Und da kommen dann so Sachen dazu

wie Domain und Range, eine Ressource, nochmal Literal, Data Type, Class, Subclass, Subproperty und so weiter. Sie kennen die ganzen Bestandteile ja schon. Was ich dazu brauche, also was wir vorher noch nicht hatten, ist auf der einen Seite, wir brauchen Klassenbezeichner, um URIs als Ressource beispielsweise auszuweisen

oder als ungetübtes Literal auszuweisen oder eben jetzt als Klassenbezeichner zu kennzeichnen. Wir brauchen Property, URIs für Gegenstand und Wertebereich, also Domain und Range. Und wir müssen hierarchische Beziehungen zwischen Klassen und zwischen Properties noch irgendwie festlegen können.

Okay, erster Unterschied zu dem normalen RDF-Vokabular ist, wir betrachten halt jetzt nicht nur Instanzen, sondern wir betrachten Klassen und Instanzen, also terminologisches Modell plus noch assationales Modell. Und deshalb müssen wir irgendwie feststellen, was gehört denn zu einer Klasse dazu, welche Instanzen gehören zu einer Klasse. Und das macht man normalerweise über eine sogenannte Klassen-Extensionsfunktion.

Also die Extension der Klasse sind eigentlich die einzelnen Klassenmitglieder, die Instanzen der Klasse. Dazu brauchen wir hier dann eine Klassen-Extensionsfunktion, IC für Klasse und dann EX, noch mal Extension. Und die macht nichts anderes, als jetzt hier eine Ressource, eine Menge von Ressourcen zuzuweisen. Ist dann letztendlich so,

dass die eine Seite dann immer die Ressource eine Klasse sein muss und auf der anderen Seite stehen dann in der Regel Instanzen oder aber auch Klassen, weil man natürlich auch in RDFS die Möglichkeit hat, von wiederum Klassen aufzubauen. Okay, und wie sieht jetzt diese Extension oder Klassenextensionsfunktion aus? Die Klassenextensionsfunktion der Klasse Y,

die enthält jetzt genau diejenigen Elemente X, die eben genau vom Typ Y sind, wenn man das so lesen würde. Also bei denen das Doppel-X-Y-Element ist der Extension des Properties RDF-Type. Was so viel gelesen wird, also es ist einfacher zu lesen,

wenn ich sage X ist vom Typ Y. Dazu brauche ich dann noch eine Interpretationsfunktion oder brauche ich dann noch die Menge der Klassen. Die brauche ich natürlich noch mit dazu. Und ist das wirklich die Menge der Klassen? Nein, das ist die Klassenextension, dann eigentlich IC. Und die enthält jetzt alle Mitglieder einer bestimmten,

oder enthält alle Klassen. Genau, das sind tatsächlich alle Klassen. Und die Extensionsfunktion von RDFS-Class, weil alle Klassen sind ja vom Typ RDFS-Class, die bilden dann die Menge IC. Und IC ist dann die Extension der speziellen URI-RDFS-Class.

Klingt auch wieder kompliziert, aber IC ist eben jetzt die Menge der ganzen Klassen. Wir haben IR als Menge der Ressourcen und wir haben IP als Menge der Properties. Okay, also Klassenextensionsfunktion haben wir oben und unten Mengen der Klassen. Und jetzt können wir hier gehen und können versuchen, das Ganze entsprechend noch zu interpretieren.

Also jetzt die RDFS-Interpretationsfunktion, bei der wir eben zu dem ursprünglichen Vokabular, das wir haben, noch das RDFS-Vokabular hinzufügen müssen. Das ist eben jetzt nun eine RDF-Interpretation für eben dieses gemeinsame Vokabular, für das jetzt wieder eine ganze Reihe zusätzlicher Bedingungen gelten. Und die müssen wir jetzt versuchen,

der Reihe nach runterzulesen und zu verstehen. Okay, die erste ist eigentlich auch schon erklärt. Jede Ressource ist vom Typ RDFS-Ressource. Also es ist klar, die Menge IR, also meine Ressourcen, die sind nichts anderes als die Klassenextension der Klasse Ressource. Alles ist eine Ressource. Jede Ressource ist vom Typ RDFS-Ressource.

Das zweite steht auch unten drunter, wie man es liest. Also jedes ungetübte und jedes wohlgeformte getübte Literal ist vom Typ RDFS-Literal. Also die Menge LV, die wir hier haben, die ist genau die Klassenextension des Properties RDFS-Literal.

Nicht das Properties, doch der Klasse RDFS-Literal. Ich kriege das auch immer durcheinander, wenn ich es vorlesen muss. Kompliziert genug. Also haben wir als erstes erklärt, was ist denn nun eine Ressource, was ist ein Literal letztendlich, wenn wir es aus Klassengesichtspunkten uns anschauen wollen.

Okay, nächster Punkt, der kommt nach eben jetzt Ressource und Literal, ist Domain und Range für die Properties. Die müssen festgelegt werden. Die gehen eigentlich letztendlich noch einfacher. Wir können mal versuchen, das zu lesen. Drittens würde dann sagen, was bedeutet Domain? Und viertens würde sagen, was bedeutet Range?

Also kann man so liegen, lesen X ist jetzt hier in dem Fall das Property. Y ist die Grundmenge von X. Und dann haben wir das Triple UVX, das dahinter steht. Und dann kann man natürlich sagen, dass U auf jeden Fall aus der Grundmenge von Y ist.

Habe ich jetzt richtig gelesen? Ich versuche es nochmal von vorne. Wir haben also das Triple XY. Das ist Element der Extension von Domain. Was soviel heißt, ist X gehört oder die Domain von X ist Y. X ist das Property. Dann haben wir dahinter ein Tupel stehen, nämlich U und V,

die in der Extension dieses Properties X stehen. Und dann kann man sagen, U, das gehört auf jeden Fall zur Domain von hier Y. U gehört zu Y, weil Y die Domain von X ist. Ich glaube, ich verhetter mich immer mehr.

Jetzt habe ich es zwar richtig gesagt. Ist Ihnen das alles klar? Oder muss ich es nochmal richtig sagen? Ich kann es auch nochmal so sagen, dass es wirklich stimmt. Das Problem ist, ich muss ja hier immer ständig das interpretieren und dann versuchen nochmal richtig herauszukriegen. Also X ist die Domain von Y. Habe ich das jetzt richtig gesagt? Nein.

X hat die Domain Y. Jetzt habe ich es richtig gesagt. Y ist in dem Fall, X ist das Property. Quatsch, anders funktioniert es ja nicht. X ist das Property und Y ist dann entsprechend die Domain. Und das Triple, das hier stehen würde, das wäre X RDFS Domain Y. Also X hat die Domain Y.

Dann haben wir hier ein weiteres Triple. Da würde dann stehen U, X, V. Und U gehört dann quasi in die Domain. Und V gehört dann in das Range. Und dann steht als letztes ganz einfach da, dass U eben zur Klassenextension von Y gehört. Und Y hatten wir ja gesagt, war die Domain von X.

Meine Güte, das ist schwierig. Ich schreibe es nochmal hin. Sonst vergesse ich das selber wieder. Also wir haben hier stehen X. Dann haben wir RDFS Domain Y.

Das war das eine Triple. Und dann haben wir das nächste Triple, das ist Punkt. Dann haben wir hier stehen U, X, V. Und was wir dann daraus schlussfolgern, ist klar, dass U quasi ein Element ist

aus der Klassenextension von Y. Also das ist das, was unten drunter dann irgendwie steht. Das ist klar, weil U, das hier gehört zur Domain. Umgekehrt ist es genauso mit dem Range.

Also wenn jetzt hier stehen würde X RDFS Range Y. Und wir hätten hier wieder U, X, V. Dann ist natürlich V Element von Y, weil V in den Range gehört.

Und das steht hier in der Zeile mit dem Viertens letztendlich drin. Also wie habe ich es unten drunter interpretiert, ist X und Y durch Property RDFS Domain oder RDFS Range verbunden und verbindet das Property X, die Ressourcen U und V. Dann ist U vom Typ Y beziehungsweise V vom Typ Y.

Kompliziert ausgedrückt, aber letztendlich wirklich nur ganz einfache Geschichte. Okay, wir haben Klassen, wir hatten Literale, wir hatten, was hatten wir vorher noch kennengelernt? Ressourcen Literale Domain Range. Was uns jetzt noch fehlt sind Klassen- und Property-Hierarchien.

Fangen wir an mit den Property-Hierarchien. Das werden wir wieder interessant lesen müssen. Und zwar habe ich mir hier was markiert. Ich hatte Ihnen in der RDFS Vorlesung, falls Sie sich noch daran erinnern, war auf zwei Fehlern eine fehlerhafte Interpretation der Sub-Property und der Sub-Class Eigenschaften.

Dort stand, dass die irreflexiv wären. Ist aber tatsächlich nicht der Fall. Die werden hier als reflexiv definiert. Ich habe mittlerweile in der Literatur beides gefunden und habe mich darauf geeinigt, ich mache das so, wie der Pascal Hitzler das gemacht hat. Ich mache das also als reflexives Property. Das werden wir dann auch noch mal treffen bei Aul. Bei Aul ist Sub-Class und Property dann definitiv

und in allen Quellen immer als reflexiv definiert. Reflexiert bedeutet eben, dass eine Klasse immer oder ein Property immer Sub-Property von sich selbst und eine Klasse auch immer Sub-Klasse von sich selbst ist. Also reflexiv muss hier gelten. Und da stand in der vierten Vorlesung auf den Folien, das wäre irreflexiv und das ist also falsch.

Das müssen Sie ändern, vergessen und das hier entsprechend dann für einsetzen. Okay, was steht da jetzt also dort? Es steht nichts anderes dort. Das eben jetzt hier das RDFS Sub-Property auf. Das verbindet jede Property mit sich selbst. Also es ist reflexiv. Und bildet eben auch ist transitiv in dem Sinne.

Wenn wir Beispiele dazu dann auch nochmal dann weiter sehen, gucken wir uns sechstens an. Was haben wir da dann noch stehen? Also wenn eben jetzt X Sub-Property von Y ist, also so kann man es wesentlich einfacher lesen, dann sind natürlich beides Properties, also X und Y sind Element von IP.

Und es ist dann klar, dass die Menge X Teilmenge ist oder dass das X Teilmenge ist von Y, weil es ist ja klar, X ist ein Sub-Property von Y. Was haben wir als letztes noch dort stehen?

Wenn X eine Klasse ist, dann muss es auch Unterklasse der Klasse aller Ressourcen sein. Das ist auch irgendwie klar. Also X ist Unterklasse von Ressourcen muss immer gelten, nämlich genau dann, wenn X tatsächlich eine Klasse ist. Also jede Klasse ist immer eine Ressource,

beziehungsweise jede Klasse ist Subklasse einer Ressource. Das hatten wir in dem Modell, das wir uns mal angeguckt haben, für RDFS auch gesehen. Das ist aber leider noch nicht alles. Es geht noch ein ganzes Stück weiter. Also jetzt haben wir es für Sub-Property, haben wir uns schon angeguckt. Wir haben jetzt festgelegt, was ist eine Klasse. Jetzt kommt natürlich dann Subklassenbeziehungen.

Subklassenbeziehungen, da gilt dasselbe wie für Property-Beziehungen, nämlich also wenn X und Y in Subklassenbeziehungen stehen, dann sind X und Y natürlich Klassen. Und die Klassenextension von X, die ist Teilmenge der Klassenextension von Y. Also genauso wie vorhin für das Subproperty.

Dann, wieder im Gegensatz zur vierten Vorlesung, auch die Subklasse ist hier reflexiv und transitiv. Transitiv hatten wir irgendwie entsprechend richtig interpretiert. Und 10, das bezieht sich jetzt hier wieder auf Container und andere Klassen. Also hier jetzt das Container-Membership-Property.

Das hier ist ein Subproperty von Member. Member ist also quasi dann das Oberproperty oder Superproperty, wenn es jetzt darum geht, irgendwie Teil eines Containers zu sein oder irgendeiner Klasse, eine Aufzählungsklasse. Und dann haben wir hier noch, wenn X irgendein Datentyp ist,

dann ist das auch auf jeden Fall eine Subklasse vom Literal. Also wenn X irgendwie zur Klassenextension von RDFS Data Type gehört, dann ist es auch Subklasse von Literal. Jetzt kann man sich diese ganzen Sachen natürlich nie komplett merken.

Das Ganze ist natürlich auch dann dazu gedacht, dass man es irgendwann mal automatisch verarbeitet. Jetzt kommt noch zu RDFS, genauso wie bei RDF, Dinge dazu, die ich jetzt nicht in dieser Art und Weise ausdrücken kann, sondern dann eben als axiomatisches Trippelausdrücke. Und das werden noch mal wesentlich mehr, also sie sind so klein, dass sie hier kaum lesen können,

die jetzt noch mal bei RDFS dazu kommen. Sie sind aber relativ einfach zu lesen. Also wir haben zwei Gruppen, oben und unten. Einmal wird hier gesagt, das sind Trippel mit dem Prädikat Domain. Und unten drunter kommen dann Trippel mit dem Prädikat Range. Und zwar wird dann nur gesagt, das Typ, die Domain Resource hat, das Domain, die Domain Property hat und so weiter.

Also vorne dran haben wir wieder Properties stehen. Und dazu haben wir dann, was ist dann deren Domain, was ist dann deren Range. Das wird hier einfach festgelegt mit diesen ersten axiomatischen Trippeln. Dann beim nächsten wird einiges festgelegt für eben jetzt wieder Aufzählungstypen, also hier für Container Membership Properties und ähnliches. Dann noch für XML-Literale und solche Dinge,

die brauchen wir uns aber nicht exakt dann noch mal angucken. Und die sind dann relativ wichtig, wenn man dann tatsächlich dahingeht, automatisch Schlussfolgerungen ziehen zu wollen oder die Korrektheit und Konsistenz von einem RDFS-Graf nachzuweisen.

Also, was jetzt mit RDFS dazu gekommen ist, ist alles, was mit dem RDFS-Vokabular dazugehört. Wir haben bezüglich der Klassen eine neue Menge eingeführt, nämlich die Menge der Klassen. Die wurde dann über eine Klassenextensionsfunktion wurde der Zusammenhang zwischen Klassen und Mitgliedern von Klassen irgendwie aufgezeigt. Und dazu haben wir dann eine ganze Reihe von speziellen Interpretationen

oder Bedingungen, die an RDFS-Interpretationen gestellt werden müssen, damit diese erfüllt sind oder ein Modell bilden gestellt. Das waren diese 1 bis 8 plus dann auch noch diese axiomatischen Trippel. Und das Ganze zusammengezählt ergibt dann nichts anderes als eben jetzt die Definition, wann folgt ein Graf G2-RDFS aus einem Graf G1,

nämlich dann, wenn jede RDFS-Interpretation die Modell von G1 ist, auch Modell von G2 ist. So, und jetzt werden Sie sich sagen, das ist ja alles schön und gut, aber das jetzt wirklich zu implementieren und für jede Interpretation abzuprüfen, ob so ein Ding jetzt tatsächlich eine RDFS, eine gültige oder ein Modell

einer RDFS-Interpretation ist oder nicht, das ist ja irgendwie relativ endlos. Irgendwie muss man das anders machen. Es gibt ja auch in der Aussagenlogik oder in der Prätikatenlogik wesentlich einfachere Regeln, mit denen ich eben solche Schlussfolgerungen durchführen kann und das Ganze irgendwie abkürzen kann. Der Trick, den man nämlich macht in der Aussagen- und Prätikatenlogik,

ist, dass man diese ganze Semantik runterbricht auf die Ebene der Syntax. Das heißt, syntaktische Regeln einführt, Schlussfolgerungsregeln. Also eigentlich so, wie es ganz ursprünglich die alten Griechen mal mit ihren Syllogismen gemacht haben. Es gibt eine Reihe von Schlussfolgerungsregeln, die kann ich syntaktisch nehmen und einfach anwenden und in denen steckt Semantik drin.

Dass diese Schlussfolgerungsregeln tatsächlich auch gelten, das muss ich in der Regel erst immer beweisen. Das sparen wir uns hier aber. Aber es gibt einfache Schlussfolgerungsregeln jetzt auch für RDFS. Das sind diese RDFS-Folgerungen und die sind dann, wenn die dann bewiesen sind, wenn deren Korrektheit bewiesen ist, wesentlich einfacher zu benutzen und auch für uns dann tatsächlich in der Übung handhabbar.

Also es geht hier darum, modelltheoretische Semantik, die beschreibt eben das Verhalten einer Logik bezüglich korrekter Schlussfolgerungen. Aber wenn man es wirklich anmelden möchte, algorithmisch anwenden möchte, dann ist das relativ schwierig und das ist dafür nicht unbedingt geeignet. Was man also macht, eben um mit Hilfe der modelltheorischen Semantik zu zeigen,

dass irgendein Graf aus einem anderen folgt, das aus G1, G2 folgt, müssen normalerweise in der Semantik eben alle RDFS-Interpretationen betrachtet werden. Und um das zu vermeiden, das hatte ich Ihnen gerade gesagt, deshalb hat man versucht, Verfahren zu entwickeln, Schlussfolgerungsverfahren, die eben jetzt diese Gültigkeit syntaktisch entscheiden können.

Und die arbeiten letztendlich nur auf den Sätzen der Logik, ohne auf die Interpretation, die wir jetzt mühsam definiert haben, zurückzugreifen. Aber es ist natürlich klar, dass diese Verfahren, diese Schlussfolgerungsregeln, die müssen vorher erst bewiesen werden, deren Korrektheit muss bewiesen werden. Und das heißt, die Korrektheit beweisen, in dem Fall muss man zeigen, dass die operationale Semantik in dem Fall korrekt ist.

Das heißt, die Resultate des algorithmischen Verfahrens, die müssen mit der modelltheoretischen Semantik übereinstimmen. Und das können wir uns sparen. In der Logik haben Sie das sicherlich schon mal gesehen, da gibt es solche Deduktionsregeln, also Ableitungsregeln. Und genau das können wir dann auch für RDF und RDFS hernehmen.

Und zwar geht es eben darum, dass sich die Sätze S1 bis Sn, das sind die, die über dem Strich stehen, die sind in der Menge der bekannten und gültigen Aussagen. Und daraus kann dann gefolgert werden irgendwie der Satz S. Natürlich stimmt sowas nicht allgemein. Ich muss natürlich davon die Korrektheit erst mal prüfen, dass ein solcher Satz gilt.

Aber solche auf Deduktion aufgebauten Regeln, die nennt man dann auch Deduktionskalkül. Und so ein Deduktionskalkül, das ist auch für RDF und RDFS aufgestellt worden. Und wenn man damit arbeitet, was sich woraus herleiten kann, ohne jetzt sämtliche Interpretationen zu betrachten, damit kann ich dann auch letztendlich Schlussfolgerungen

in RDF und RDFS auf syntaktische Art und Weise sehr schnell ausführen. Dazu brauchen wir natürlich erst mal eine allgemeine Notationsregel. Wie notiere ich denn solche RDFS Ableitungsregeln? Natürlich habe ich wieder Dinge, die über dem Strich und unter dem Strich stehen, also oben steht, was ist die Voraussetzung, unten steht, was folgt daraus.

Ich muss natürlich URIs irgendwo da einsetzen können, also A und B, das sind in unserem Fall dann eben beliebige URIs, die in einem Trippel eben erstmal in der Mitte stehen können an der Stelle des Prädikats. Dann habe ich Leereknoten, die benenne ich jetzt mal hier mit anderscore-doppelpunkt-n, also das ist ein bisschen angelehnt an unsere Turtle Syntax. Dann

brauche ich noch für das Subjekt bestimmte Bezeichner, nämlich U und V, nämlich jetzt hier für URIs, Blanknotes oder I.D.s, die eben jetzt hier für an der Stelle des Subjekts stehen können. Dann Literale, das wird ein L, das wird ein beliebiges Literal und dann brauche ich auch noch für das Objekt

Buchstaben, das wären X und Y. Wir werden sehen, dass es dann, wenn man es anwendet, kann man es relativ einfach unterscheiden, so klingt es jetzt wieder fürchterlich kompliziert. X und Y, die stehen dann eben für das Objekt und zwar können das sein URIs, I.D.s von Blanknotes oder eben auch Literale, die in einem Trippel an der Stelle des Objekts stehen. Und jetzt können wir Regeln aufstellen, einmal für einfache

Folgerungen, die auf einfachen Interpretationen basieren, für RDF-Folgerungen, die auf RDF-Interpretationen basieren und für RDFS-Folgerungen, die auf RDFS-Interpretationen basieren. Einfache Folgerungen, die sind noch relativ einfach, da kann ich nicht allzu viel machen. Wir hatten ja auch gesagt, das ist relativ schwer,

einen inkonsistenten Grafen da tatsächlich aufzubauen und deshalb gibt es nur eigentlich zwei einfache Ableitungsregeln für einfache Folgerungen, die hier mal notiert sind. Und zwar, wenn wir uns angucken, erste Regel, also die Regeln sind immer benannt, das sind immer die Kürzel, die hier neben dem Strich

auf der rechten Seite stehen, SE1 und SE2, das ist für einfache Folgerung 1 und einfache Folgerung 2. Und wenn ich jetzt irgendein Trippel habe, das besteht aus Subjekt, Prädikat, Objekt, bei U und V waren hier immer Subjekt, x, y waren immer Objekte, A und B waren immer irgendwie Prädikat,

dann kann ich daraus auf jeden Fall immer herleiten, einen Grafen, der eben an der Stelle des Subjekts oder anstelle des Objekts einen Leerenknoten stehen hat. Was ich da mache, ist nichts anderes, also ich erweitere den Grafen durch einen Leerenknoten. Und der kann eben als Subjekt oder Objekt vorkommen.

Einfach gesagt, also man ersetzt in einem Grafen einen Teil der Vorkommen eines bestimmten URIs durch einen Leerenknoten. Einfache Vorbedingung ist, der Knoten der Leere darf natürlich noch nirgends woanders benutzt worden sein. Sonst gilt er als gebunden. Man darf also nur irgendwelche freien Leerenknoten neu mit einfügen und dann

lässt sich zeigen, müssten wir jetzt, machen wir nicht, aber der Satz, der dann gezeigt werden würde, ist dann, dass ein Graf G2 einfach aus einem Graf G1 folgt, wenn G1 mithilfe der Regeln SE1 und SE2 zu einem Graf G1 Strich ergänzt werden kann. Also wir erweitern den Grafen G1 mithilfe dieser Regeln, indem wir eben neue Leereknoten hier mit einsetzen.

Und zwar so, dass G2, das ist der Graf, der geschlussfolgert werden soll, in G1 Strich, in dem erweiterten Grafen dann tatsächlich enthalten ist. Wenn ich das hinkriege mit diesen Erweiterungsregeln, dann habe ich gezeigt, dass eben G2 einfach aus G1 folgt.

Ist jetzt noch nicht allzu viel und allzu kompliziert. Wenn Sie sich das dann auch in der Übung mal angucken, kann man dann eben zeigen, dass man quasi G2 hier aus G1 folgern kann, weil man nämlich einen Graf G1 so weit erweitern kann, dass man einen Graf bauen kann, von dem dann der Graf G2 tatsächlich eine Teilmenge.

Darstellt. Kompliziert sieht es nicht aus, aber man ersetzt dann halt immer nur Teile des Grafen durch irgendwelche oder ersetzt die durch Leereknoten beziehungsweise erweitert Leereknoten mit bereits vorhandenen Prädikaten, die man hier drin hat.

Mehr wird da letztendlich nicht gemacht. Aber da können wir noch nicht allzu viel machen. Ich gehe nochmal hier vor, da können wir wirklich nur machen. Man sieht es ja entsprechend anstelle des Subjekts oder anstelle des Objekts einen Leerenknoten reinsetzen. Und der Leereknoten kann eben auch, das ist das Besondere hier, anstelle eines Literals gesetzt werden.

Nochmal Literale dürfen hier immer nur durch neue Leereknoten ersetzt werden. Aber das sehen wir dann nochmal in der Übung. Das war die einfache Folgerungsregel. Also da gibt es nur die zwei, SE1, SE2, mit denen ich solche einfachen Folgerungen machen kann.

Um RDF-Folgerungen quasi aufzustellen, das heißt, ich möchte wiederum sehen, irgendein Graph G2 lässt sich aus einem Graph G1 herleiten. Und zwar muss ich dann wieder hergehen und muss aus dem Graph G1 mithilfe dieser Ableitungsregeln den Graph wieder erweitern oder eben einschränken, sodass G2 dann irgendwie herauskommt.

Und da habe ich jetzt folgende Regeln, die ich abarbeiten kann. Das erste RDF AX, das ist eine axiomatische Regel und die besagt nichts anderes, dass ich aus nichts, also überm Strich steht ja auch nichts, immer ein sogenanntes axiomatisches Trippel, ein axiomatisches Trippel UAX, herleiten kann. Axiomatische Trippel, haben wir gesagt, die müssen ja immer wahr sein für die RDF-Folgerungen

beziehungsweise auch RDFS-Folgerungen. Mit denen kann ich also stets jeden Graph erweitern. Das nächste ist die LG-Regel und die besagt halt, dass Literale durch anderweitig oder nicht anderweitig gebundene leere Knoten ersetzt werden können.

Also mit der LG-Regel kann ich hergehen und kann ein Literal, das hier oben als Objekt steht, ersetzen durch einen leeren Knoten. Das ist auch nicht viel anders als jetzt diese Geschichte aus SE1, aber bezieht sich hier jetzt speziell nur auf Literale,

die wir ja dann im RDF-Vokabular explizit auch mit drin haben. Nächste Ableitungsregel, für jedes Trippelpredikat kann abgeleitet werden, dass es eine Entität aus der Klasse der Properties ist. Also wir haben hier das Trippel UAY, A ist hier das Property in der Mitte in dem Trippel

und da können wir natürlich draus ableiten, dass A vom Typ Property ist. Also eine ganz einfache Sache. Das ist die RDF-1-Regel. Genauso können wir ableiten, dass aus dem Trippel UAL, wenn L ein Literal ist und L quasi vorher, wobei über die LG-Regel zuvor quasi dieser leere Knoten N

zugewiesen ist, dann können wir sagen, dass N vom Typ Literal ist, XML-Literal. Also das ist wieder kompliziert. Wir haben UAL. L wird durch die Regel LG der leere Knoten N quasi zugewiesen

und dann können wir sagen, dass M natürlich vom Typ Literal ist. In RDF-Folgerungen können wir das sagen. Und die vier, die reichen dann schon mal aus, wenn wir die benutzen kann, um eben jetzt so eine Herleitungsregel anzugeben. Und zwar der Graph G2 folgt, RDF oder RDF folgt aus einem Graph G1 genau dann,

wenn es einen Graphen G1 Strich gibt wiederum, der mit Hilfe der Regeln RDF AX, L, G, RDF 1 und RDF 2 hergeleitet werden kann, aus dem G2 einfach folgt. Also einfach folgt heißt dann wieder, dass man den dann wieder weiter erweitern kann

mit den Erweiterungsregeln SE1 und SE2, um zu zeigen, dass der auch tatsächlich einfach folgt. Also das ist jetzt hier dann schon eine zweistufige Herleitung. Erst RDF-Ableitungsregeln anwenden, dann die einfachen Ableitungsregeln anwenden. Und Sie können sich jetzt vorstellen, wenn wir das Ganze tatsächlich auch noch

für RDFS machen wollen, dass wir auch noch einen ganzen Satz von RDFS-Ableitungsregeln brauchen für Schlussfolgerungen. Die ersten sehen natürlich so aus, dass ich wieder axiomatische Trippel in RDFS mit ableiten kann. Dann das nächste sieht so aus, dass ich eben diese LG-Regel für die Literale umdrehen kann.

Also wenn ich vorher irgendwann mal ein Literal einem Lernknoten zugewiesen habe, dann kann ich entsprechend die Umkehrung wieder machen, kann ein neues Trippel nochmal einführen, in dem nochmal UAL steht. Also wäre auch kein Problem. Die nächste Regel sieht wiederum so aus, dass wenn ich ebenfalls jetzt ein Trippel habe UAL,

wobei L ein ungetübtes Literal da steht, und N durch die Anwendung der LG-Regel vorher dem Literal L zugewiesen worden ist und ein Blanknote darstellt, dann ist L in dem Fall dann ein Literal.

Dann gibt es entsprechend noch Property-Einschränkungen für Domain und Range. Das ist auch klar, wenn ich eben angegeben habe, dass A die Domain X hat und ich habe dann ein Trippel UAY, dann ist U vom Typ X kann ich dann herleiten. Und genauso kann ich das mit dem Range machen, wenn ich das hier stehen habe,

dass A den Range X besitzt und ich habe das Trippel UAY, dann kann ich sagen, dass Y den Typ X dann hat. Also Domain und Range kann ich ableiten entsprechend. Zudem ist alles irgendwie eine Ressource. Also ich habe ein beliebiges Trippel UAX und kann dann natürlich sagen, dass U natürlich eine Ressource ist, also vorne das Subjekt, und dass auch das Objekt, das X, eine Ressource ist.

Also soweit so gut. Jetzt muss ich noch irgendwie Klassen- und Property-Hierarchien mit einbeziehen, nämlich haben wir hier auf der ersten Seite die Subproperties, und da haben wir einmal hier stehen in RDF 5. Was haben wir da drin stehen? Kann einer von Ihnen lesen? Versuchen wir das mal zu lesen.

U ist Subproperty von V. V ist Subproperty von X. Daraus folgt, dass U Subproperty von X ist. Das ist ganz einfach die Transitivität. Genau. Der nächste drunter, RDF 6, da haben wir U ist vom Typ Property.

Was kann ich daraus ableiten? Da kann ich davon ableiten, dass U Subproperty von sich selbst ist. Das ist also die Reflexivität, die hier zur Anwendung gebracht wird. So, und jetzt kommt dann was mit dem Oberproperty, nämlich wenn A Subproperty von B ist, und ich habe das Trippel U A Y, dann kann ich anstelle von A, von diesem Subproperty,

kann ich auch dessen Superproperty oder Oberproperty hinschreiben und kann sagen, dass U B Y als Trippel existiert. Sie sehen also, ich kann immer jeden beliebigen Grafen, genauso wie wir es kennengelernt haben, als wir hier versucht haben, in einer Klauselmenge zu resolvieren, kann man hierher gehen, wenn man die zwei Richtigen findet, kann man dann quasi eine neue dafür schreiben und einsetzen

und erweitert somit dann letztendlich seinen Grafen. Genauso funktioniert es hier nochmal mit Subklassen. Ich habe hier oben drüber wieder Subklassen stehen, und zwar, was haben wir hier stehen? Nummer 8. Da haben wir stehen, U ist vom Typ Class und daraus folgt dann, dass U natürlich die Subklasse einer Ressource ist. Das ist auch einfach.

Also jede Klasse ist eben Subklasse einer Ressource. Dann RDFS 9. Was haben wir da stehen? U ist Subklasse von X und V ist vom Typ U. Dann ist natürlich auch V vom Typ der Oberklasse, also V ist vom Typ X. RDFS 10. Schauen wir uns das nochmal an.

U ist vom Typ RDFS Klasse. Dann ist U natürlich auch Subklasse von U. Das ist also die Reflexivität. Und das letzte wird dann wie immer die Transitivität sein. U ist Subklasse von V. V ist Subklasse von X. Daraus folgt Transitiv. U ist natürlich auch Subklasse von X.

Dann gibt es jetzt noch bezüglich des Containers eine Regel, das nämlich immer, hatten wir ja gesagt, Container Membership Property. Also wenn ich einen Container Membership Property habe, dann ist das ein Subproperty von Member. Hatten wir auch schon kennengelernt. Und dann haben wir jetzt hier noch, wenn U vom Typ Data Type ist, dann ist das eine Subklasse auch vom Literal.

Und das sind dann sämtliche Ableitungsregeln, die ich letztendlich mit RDFS oder für RDFS brauche, um die RDFS Schlussfolgerungsregel irgendwie feststellen zu können.

Jetzt kann ich das natürlich nutzen, um quasi Inkonsistenzen irgendwie zu Schluss folgern oder herauszufinden. Also um aus einem gegebenen, ein Problem ist, dass ich aus jedem gegebenen Inkonsistenzen Grafen dann quasi jeden beliebigen Grafen Schluss folgern kann mit Hilfe dieser Regeln. Das möchte ich natürlich nicht. Die Frage ist jetzt, was ist hier jetzt genau eine Inkonsistenz?

Eine Inkonsistenz heißt also, es gibt keine Interpretation I, für die eben der Graf, wenn ich den interpretiere, tatsächlich war es. Allerdings habe ich auch mit RDFS nur eine sehr eingeschränkte Möglichkeit zur Erzeugung von Inkonsistenzen. Und eine Möglichkeit der Erzeugung von Inkonsistenzen, das funktioniert mit Hilfe dieser XML-Datentypen.

Das ist auch bekannt, das Beispiel unter dem Namen XML Clash. Und da gibt es ein schönes Beispiel dazu, nämlich beispielsweise dieses hier. Wenn ich sage HPI hat Smiley, das ist ein Property mit dem Range RDF Literal und ich mache dann hier eine direkte Instanzierung, eine HPI böse Bemerkung, die hat eben jetzt einen bestimmten Smiley,

nämlich den Smiley für böse Bemerkung. Und wenn ich den so reinschreibe, dann ist das, wie Sie feststellen müssten, kein wohlgeformtes XML, weil, wer weiß warum, dass kein wohlgeformtes XML ist.

XML ist da relativ böse und nickelig, also das interessiert den überhaupt nicht, ob da jetzt Anführungszeichen stehen oder nicht. Wenn innerhalb dieser Anführungszeichen hier jetzt auch steht, zweimal eckige Klammer zu, fehlt dem irgendwann diese, oder Spitze Klammer zu, fehlt dem diese Spitze Klammer auf. Und dementsprechend fehlt das Gegenstück, weil die glauben,

das wäre eine Tech-Begrenzung. Zumindest in dem Sinne, in dem RDF Literal. Gucken Sie sich das mal an, das steht nochmal, das finden Sie auch entsprechend im Buch, beziehungsweise auch nochmal im Netz, da steht genau dieses Beispiel drin. Und das Problem ist halt, dass es keine Interpretation gibt, für dass beide eben gleichzeitig dann tatsächlich wahr sind. Muss man sich nochmal angucken.

Was uns noch fehlt, ist jetzt genau, was ist eine RDFS Schlussfolgerung, nämlich ein Graph G2, RDFS folgt aus einem Graph G1, und jetzt muss ich das dreistufig machen, nämlich einmal, wenn es einen Graphen G1 Strich gibt, der aus G1 mit Hilfe der Regeln, jetzt kommen sämtliche RDFS Regeln eigentlich,

hier vorne muss und RDF Regeln hergeleitet werden kann, also RDF und RDFS Regeln, so dass G2 aus G1 einfach folgt oder G1 einem XML Clash enthält. Wenn ein solcher XML Clash enthalten ist, wenn das inkonsistent ist, kann ich immer irgendeinen Graph draus Schluss folgern, weil aus was Falschem kann ich, egal, alles Mögliche Schluss folgern.

Das ist ja das Problem aus der Sache. Also dieser zweite Teil ist quasi nur der Vollständigkeit drunter, den bräuchte man eigentlich nicht, wenn man wirklich mitarbeiten will, gibt aber an, dass man eben quasi aus einem inkonsistenten Graphen alles folgern kann und deshalb entsprechend immer vorsichtig sein sollte, was man als Ausgangsbasis zum Schlussfolgern eben jetzt hier hernimmt.

Dann kann ich es Ihnen nicht ersparen, aber wir müssen uns auch nochmal kurz angucken, Regeln für externe Datentypen, die hier noch dazukommen, aber das ist letztendlich Gott sei Dank nur sehr, sehr wenig. Externe Datentypen, die können hier immer über RDFS-Data-Type charakterisiert werden.

Die Funktionsweise, was hinter diesem Datentyp dann immer steht und ob da irgendwelche Zusammenhänge bestehen, dass quasi 1000 Gramm ein Kilogramm sind oder ähnliche Dinge, die werden natürlich für externe Datentypen hier jetzt nicht in der RDFS-Semantik entsprechend mit eingebracht, sondern es gelten nur ein paar einfache Ableitungsregeln,

nämlich beispielsweise wenn D ein RDFS-Data-Type ist, also ein Datentyp ist und man hat irgendwo das Drippel U, A und dann kommt hier ein Literal mit dem Datentyp D, dann kann ich da jedes Mal immer irgendwie quasi sagen, also wenn es das Literal gibt und wenn das ein wohlgeformtes, getyptes Literal ist,

dann kann ich auch auf die Existenz irgendeiner Ressource schließen, die genau von diesem Typ ist, sonst hätte ich diesen Datentyp nicht eingeführt. Und wenn ich auf die Existenz einer Ressource schließen kann, kann ich dafür jederzeit einen leeren Knoten, der keine URI hat, also einen Blanknote einführen, der genau von diesem Typ ist und mit dem kann ich dann weiter irgendwas natürlich dann machen.

Dann gibt es noch das Problem, dass ich, wenn ich Datentypen verwende, unterschiedliche Datentypen dasselbe aussagen können, das ist eigentlich da das komplizierteste Problem, also dass so Werte-Typen von Datenbereichen quasi sich überlappen, Doppel enthält beispielsweise auch die Zahl 15 als Integer-Datentyp und da muss ich natürlich irgendwie sagen können,

dass eben zwei verschiedene Elemente, die jetzt unterschiedlichen Datentypen haben, dass die miteinander übereinstimmen und dazu braucht man eben jetzt diese Regel, die sagt, dass D ein Data-Type ist und E ein Data-Type und wenn man dann eben Datentypen hat, die tatsächlich dasselbe ausdrücken, aber unterschiedlich sind, dann kann ich da entsprechend aus einem Triple, der mir sagt, dass U quasi irgendwann literal von dem Datentyp D zugewiesen bekommt,

dann kann ich dem dasselbe natürlich nochmal hinschreiben, entsprechend dann mit dem Datentyp E, wobei S mit Datentyp D genau dasselbe sein muss wie T mit Datentyp E. Also da kommt nochmal externe Semantik mit rein,

das ist schon keine so schöne Regel, aber die braucht man ab und an dann auch noch. Ja und wenn der Wertebereich eines Datentyps D im Wertebereich des Datentyps E liegt, wieder extensionale Semantik kommt irgendwie von außen, dann kann ich ja auch noch diese Regel verwenden, dass ich sagen kann, dass D dann natürlich eine Subklasse von E ist.

So weit so gut, damit kann ich dann tatsächlich jetzt RDFS Schluss folgern. Es gibt noch ein paar mehr Kleinigkeiten, die wir allerdings jetzt hier für unsere Betrachtung nicht genau brauchen oder nicht unbedingt brauchen. Die Grenzen letztendlich liegen dort, hatte ich schon erwähnt, dass wir nämlich nur eben eine intentionale Semantik angegeben haben.

Die angegebene intentionale Semantik ist nicht die einzige sinnvolle Semantik, das ist halt jetzt eine Standard Semantik, auf die sich mehrere geeinigt haben, entsprechend die dann zu benutzen. Andere Semantiken können noch strengere Anforderungen stellen, da braucht man dann noch mehr Regeln für die Interpretation. Das heißt, da brauchen wir dann quasi das, was wir jetzt noch hinein interpretieren,

was manche Sachen bedeuten, das wäre die extensionale Semantik, die kann man auch noch formalisieren, das Ganze wird aber noch immer komplexer und immer mehr Restriktionen kommen da letztendlich mit rein. Was für uns natürlich gilt, die Ableitungsregeln der intentionalen Semantik,

die lassen sich vom implementationstechnischen Standpunkt aus einfacher umsetzen, als wenn ich jetzt auch noch Regeln der extensionalen Semantik versuche, hiermit abzubilden und tatsächlich mit reinzunehmen. Ein Problem, das wir aber generell noch haben, liegt begründet in der Ausdrucksmächtigkeit von RDFS, also das entspricht ja noch lange nicht dem,

was jetzt tatsächlich eine Aussagen- oder Prädikatenlogik uns bieten würde, weil wir haben ja beispielsweise das Problem, dass wir in RDFS nichts negieren können. Wir können zwar sagen, dass irgendeine Instanz zu irgendeiner Klasse gehört, aber wir können nicht sagen, dass eine Instanz auf keinen Fall zu einer Klasse, also zu einer Klasse nicht gehört.

Bei RDFS haben wir eben diese Open-World-Assumption, alles ist eine offene Welt. Wenn irgendein Triple mal nicht genannt ist, dann heißt das noch lange nicht, dass das Gegenteil davon gilt. Also offene Welt bei RDFS hat eben das Problem, wenn wir keine explizite Negationsmöglichkeit haben, müssen wir immer davon ausgehen,

dass eben auch bei Beispielen wie diesen, die sich eigentlich ausschließen würden gegenseitig, dass eben beide gelten und sowas nicht zum Widerspruch führt. Also wenn ich jetzt sage, dass ich Raucher und gleichzeitig Nichtraucher bin, dann würde das funktionieren nach RDFS-Gesichtspunkten, nach einer extensionalen Semantik, die genauer sagt, was denn Nichtraucher und Raucher sein heißt, würde das nicht gelten, aber um das tatsächlich ausdrücken zu können,

brauchen wir irgendein semantisch ausdrucksstärkeres Mittel, nämlich eine Beschreibungslogik oder da entsprechend dann eben Aul. Und damit mit Aul, wenn wir später dann auch weitermachen, das heißt eigentlich, wenn wir jetzt weitermachen, RDFS-Semantik, dazu werden Sie sehen,

da werden wir ein, zwei Übungsaufgaben rechnen, in denen Sie halt dann einfaches RDF-Modell, einen RDF-Graf und quasi mal die Interpretation davon angeben müssen und eventuell diese Schlussfolgerungsregeln, die Sie gerade gesehen haben, anwenden müssen, um herzuleiten, dass ein Graf aus einem anderen folgt. Das ist aber halb so wild, das ist halb so schwer, da haben wir keine so komplexen Beispiele.

Wir machen dann weiter, wie Sie sehen, nach den Ferien mit Beschreibungslogiken und Aul. Die Reihenfolge ist mit Bedacht gewählt. Wir hatten ja schon Aussagenlogik und Prädikatenlogik kennengelernt. Bevor wir uns die Aulsyntax betrachten, wollen wir natürlich wissen, was sie bedeutet. Dazu brauchen wir generell noch mal eine Stunde,

in der wir uns die Beschreibungslogiken anschauen, auf denen Aul basiert und dann schauen wir uns danach tatsächlich die Aulsyntax an und bilden dann Aul tatsächlich auf eine Logik ab. Und damit haben wir dann auch die Aulsemantik erklärt und können wirklich damit arbeiten und damit rechnen. Das heißt, wir bleiben noch mit zeitlang genau auf diesem Level,

dem Ontologielevel, bevor wir jetzt dann mit Aul anfangen und dann auch noch mit Regeln Dinge, die man eben dann nicht mehr mit Aul machen kann. Und Beschreibungslogiken und Aul, die kommen entsprechend nach den Ferien. Nachlesen können Sie den größten Teil der RDFS-Semantik und sogar noch ein bisschen mehr hier in dem Semantik-Webbuch.

Es gibt davon mittlerweile auch eine englische Ausgabe, die ist ein klein bisschen neuer. Die ist, glaube ich, noch nicht in der Bibliothek vorhanden. Die ist auch erst dieses Jahr jetzt erschienen. Und da wird das Ganze sogar noch ein bisschen erweitert in der Beziehung. Gut, das war es soweit von meiner Seite. Ich wünsche Ihnen schöne Feiertage.

Wir sehen uns wieder nach den Ferien. Tja, bis dahin. Tschüss.