Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Intelligente Systeme C

Ähnliche Präsentationen


Präsentation zum Thema: "Intelligente Systeme C"—  Präsentation transkript:

1 Intelligente Systeme C
Semantic Web und Wissensrepräsentation Prof. Dr. Wolfram Conen WS04/05, FH Gelsenkirchen

2 Einführung „A new form of Web content that is meaningful to computers will unleash a revolution of new possibilities“, Tim Berners-Lee, James Hendler, Ora Lassila in The Semantic Web, Scientific American, May 2001

3 Überblick Wissen und Wissensrepräsentation
Wissenbegriff/Wissensarten Logik Produktionsregeln Semantische Netze Frame-artige Repräsentationen Description Logic „Modernes“ (uncleveres?) Internet XML / XML-Schema / Webservices (WDSL, BPEL4WS, UDDI, SOAP) „Semantic Web“ RDF / OWL OWL-S Andere Möglichkeiten: Prolog, Datalog, F-Logik Anwendungen: Security and Trust, Clever-Search Ausblick / Grenzen

4 Problem 1 In einer Firma arbeiten drei Freunde: ein C++-Programmierer, ein Java-Programmierer und ein Pascal-Programmierer. Ihre Namen sind Otto, Paul und Kai. Der C++-Programmierer hat keine Geschwister; er ist der Jüngste der drei Freunde. Kai, der mit der Schwester von Otto verheiratet ist, ist älter als der Java-Programmierer. Wer programmiert in welcher Sprache? Lösen Sie das Problem!

5 Problem 1 - Lösung In einer Firma arbeiten drei Freunde: ein C++-Programmierer, ein Java-Programmierer und ein Pascal-Programmierer. Ihre Namen sind Otto, Paul und Kai. Der C++-Programmierer hat keine Geschwister (A) Der C++-Programmierer ist der Jüngste der drei Freunde. (B) Kai ist mit der Schwester von Otto verheiratet. (C) Kai ist älter als der Java-Programmierer. (D) Wer programmiert in welcher Sprache? Notation: X = Y heißt: X „programmiert in“ Y: Aus D folgt: Kai  Java (E) Aus B und D folgt: Kai  C++ (F) Aus E und F folgt: Kai = Pascal (G) Aus C und A folgt: Otto  C++ (H) Aus G und H folgt: Otto = Java (I) Also programmiert Otto in Java und Kai in Pascal. Es folgt abschließend, dass Paul in C++ programmiert.

6 Towards your personal project...
Vortragsthemen: Webservices SOAP (Simple Object Access Protocol) WSDL, WS-Policy Registry/Discovery (UDDI, ebXML Registry) BPEL4WS XML und Konsorten: XML/XLink/XPath XML-Schema XML-Query Security Role-Based-Acess-Control (Grundlagen, Anwendungsszenarien) Nahziel: Web-Services, XML-basierte Semantic-Web-Sprachen, Prolog kennenlernen Nächstes Ziel: Verteilte, semantische Zugriffskontrolle und verteiltes, semantisches Rechtemanagement mit einer Architektur für div. Anwendung konzipieren und implementieren!

7 Wissensrepräsentation
Def. Wissen: Als das Wissen eines Wissensträgers definieren wir die Menge aller von ihm als wahr angenommenen Aussagen über die repräsentierte Welt, die tatsächlich wahr sind. Def. Überzeugungen: Die Überzeugungen eines Wissensträgers sind alle Aussagen, von denen er glaubt, sie seien wahr. Beide Definitionen stammen aus von Ulrich Reimer aus „Einführung in die Wissensrepräsentation“, Teubner Verlag, 1991

8 Wissensrepräsentation
Wie stellt man fest, über welches Wissen ein Wissensträger verfügt? Zitat aus dem Reimer-Buch: „... denn selbst Menschen sind nicht immer in der Lage mitzuteilen, was sie wissen ...“ Newell: Wissensträger sind Agent, Agenten verfolgen Ziele Agenten handeln rational: Agent A weiß, dass Handlung H zum Ziel Z führt – also führt A H aus Wissen ist dann alles, was sich dem Agenten zuschreiben lässt, damit sein Verhalten nach dem Rationalitätsprinzip berechnet oder erklärt werden kann Wissen wird so rein „funktional“ bestimmt, Trennung zwischen Wissen und Repräsentation (Strukturen/Prozessen) Def. Wissensebene, Symbolebene Als Wissensebene bezeichnen wir diejenige Ebene, auf der die Wissensinhalte zu sehen sind, aber nicht die internen Strukturen, in denen sich die Inhalte manifestieren; diese Strukturen werden erst auf der Symbolebene sichtbar.

9 Wissensrepräsentation
Wissensebene als abstrakter Datentyp: anfragen: Wissen x Anfrage ! Ergebnis mitteilen: Wissen x Aussage ! Wissen Wissenrepräsentation: Das Aufschreiben von Symbolen (Repräsentationsstrukturen), die in einer erkennbare Weise einem Ausschnitt der zu repräsentierenden Welt entsprechen Eine Repräsentation ist ein Modell für die repräsentierte Welt bzw. den Weltausschnitt, aber: (1) Eine Repräsentation erfasst einige Merkmale der repräsentierten Welt (2) Eine Repräsentation erfasst nicht zwangsläufig (in der Regel nie) alle Merkmale der repräsentierten Welt (3) Nicht alle Merkmale einer Repräsentation stehen zwangsläufig für Merkmale der repräsentierten Welt

10 Wissensrepräsentation
[Erläuterung zur vorigen Folie in ihrem Mitschrieb] Def. Repräsentation: Von einer Repräsentation sprechen wir, wenn zusätzlich zu einer Menge von Repräsentationsstrukturen Angaben dazu vorliegen, wie die Strukturen der Repräsentation auf die Merkmale der repräsentierten Welt abzubilden sind. Diese Angaben stellen die Interpretationsvorschrift dar.

11 Wissensarten - Grundbegriffe
Def. Konzept: Ein Konzept ist ein 3-Tupel (Konzeptname, Extension, Intension). Die Extension ist die Menge aller Objekte, die zu dem Konzept gehören. Die Intension gibt die Merkmale an, die ein Objekt aufweisen muß, um zu dem Konzept zu gehören (wir nennen diese Merkmale auch Konzeptmerkmale) Konzeptmerkmale sind z.B. Eigenschaften (z.B. Kai ist rot), es gibt auch Eigenschaftsklassen (Farbe) (Semantische) Beziehungen zu anderen Konzepten, z.B. Teil-von, kausale, zeitliche ... Die Unterscheidung zwischen den Begriffen Konzept, Eigenschaft und Beziehung ist einigermaßen „fuzzy“ (also „unscharf“)

12 Wissensarten – Grundbegriffe
Def. Konzeptklasse: Ein Konzept, dessen Extension mehr als ein Objekt enthält. Die Intension einer Konzeptklasse bezeichnen wir auch als (Konzept-)klassen-beschreibung. Def. Individualkonzept: Ein Konzept, dessen Extension genau ein Objekt enthält. Die Intension eines Individualkonzepts beschreibt die Merkmale dieses Objekts.

13 Wissensarten – Grundbegriffe
Individualkonzepte gehören zu Konzeptklassen: Def. Instanz-von-Beziehung: Zwischen einem Individualkonzept (N,E,I), dessen Extension, und einer Konzeptklasse (N‘,E‘,I‘) besteht die Instanz-von-Beziehung genau dann, wenn o 2 E‘ (und somit I ) I‘) Beispiel: Klassenkonzept: (Mensch, { „Kai“, „Bassam“}, kann-denken) Individualkonzept: (Ding_Kai, { „Kai“ }, kann_denken) Ding_Kai Instanz_von Mensch (Infixnotation) bzw. Instanz_von(Ding_Kai,Mensch) (Präfixnotation)

14 Wissensarten – Grundbegriffe
Klassenbeschreibung kann bestehen aus: Eigenschaften, die jedes Klassenelement besitzt (z.B. alle Klassenelemente sind rot) Eigenschaftsklassen, die für jedes Klassenelement definiert sind (z.B. alle Klassenelemente besitzen eine Farbe) Semantische Beziehungen zu anderen Konzeptklassen; jedes Klassenelement muß dann Beziehungen der angegebenen Art zu Elementen der betreffenden Konzeptklassen aufweisen (z.B. besteht für jeden Stamm eine Teil-von-Beziehung zu einem Baum) Semantische Beziehungen zu Individualkonzepten; hier weist jedes Klassenelement eine Beziehung des spezifizierten Typs zum angegebenen Individualkonzept ais (z.B. wenn alle Klassenelemente Produkt desselben Herstellers sind)

15 Wissensarten – Grundbegriffe
Es kann „speziellere“ Konzeptklassen geben: Def. Is-a-Beziehung (auch: Ober-/Unterbegriff oder Spezialisierungsbeziehung): Zwischen einer Konzeptklasse k=(N,E,I) und einer Konzeptklasse k‘=(N‘,E‘,I‘) besteht eine Is-a-Beziehung genau dann, wenn E µ E‘ (und somit I ) I‘). Die Konzeptklasse k heißt dann Unterbegriff der Konzeptklasse k‘ (die dann Oberbegriff von k heißt) Man sagt auch: k ist eine Spezialisierung von k‘ Beispiel: Tier is-a Organismus „Speziellere“ Objekte ererben Eigenschaften des Oberbegriffs Man kann nun Konzepthierarchien bauen

16 Wissensarten – Grundbegriffe
Konzeptklassen „höherer“ Ordnung „organisieren“ Konzeptklassen zu neuen Begriffen Def. Gruppenklasse: Eine Konzeptklasse (N,E,I), bei der E nur Konzeptklassen enthält. Beispiel: Seien Hund, Katze, Maus Konzeptklassen mit der naheliegenden Bedeutung, dann ist (Tierart,{Hund,Katze,Maus},Klassen_mit_Tieren_drin) eine Gruppenklasse

17 Wissensarten – Grundbegriffe
Eine wichtige „Sorte“ von Konzepten sind Ereignisse Def. Ereignisse: Unter einem Ereignis versteht man eine Zustandsänderung, für die es einen Ort und eine Zeitdauer oder einen Zeitpunkt gibt. Das Wissen um Ereignisse betrachten wir als eigene Wissensart Ereignisse, die durch ein belebtes Objekt absichtsvoll ausgelöst werden, nennen wir Handlungen

18 Wissensarten – Grundbegriffe
Def. Massenkonzept: Konzepte, die sich dadurch auszeichnen, dass sie nicht zählbar sind, heißen Massenkonzepte Def. Regelhafte Zusammenhänge: Wissen von der Art „wenn Faktum A zutrifft, dann gilt auch Faktum B“ bezeichnen wir als Wissen um regelhafte Zusammenhänge Eng damit verwandt ist das Wissen über einschränkende Bedingungen (kann man jeweils ineinander überführen) Def. Einschränkende Bedingung: Wissen über die Unzulässigkeit von Zuständen oder Zustandsänderungen bezeichnen wir als Wissen um einschränkende Bedingungen

19 Wissensarten – Grundbegriffe
Das Wissen kann einen Status (besser; eine Qualität) haben, z.B. kann es unvollständig sein („sie ist Studentin oder Schülerin“) unsicher („sie ist möglicherweise Studentin“) widersprüchlich („sie ist 8 Jahre und sie ist Studentin“) Wissen über Eigenschaft kann zudem ungenau sein („sie ist groß – aber wie groß genau?“) Ungenaue Eigenschaftsangaben können einen Bereich festlegen, aus dem der tatsächliche Wert stammt, dies kann mit Wahrscheinlichkeiten verbunden sein (diskrete Werte) bzw. einer Wahrscheinlichkeitsverteilung (kontinuierliche Werte)

20 Wissensarten – Grundbegriffe
Man kann Sachverhalte mit Modalitäten verbinden, man besitzt dann Wissen über Sachverhalte, die notwendig, möglich oder unmöglich sind (alethische Modalitäten) obligatorisch, geboten oder verboten sind (deontische Modaliäten) Wissen kann prototypisch (auch stereotypisch genannt). Das sind Aussagen, die „in der Regel“ zutreffen und als korrekt angenommen werden, solange kein gegenteiliges Wissen vorliegt (also Wissen, dass zu einem Widerspruch führen würde) Man nennt solche Aussagen Default-Aussagen Betreffen sie Konzepteigenschaften, dann heißen sie Default-Eigenschaften Besonders Konzeptklassenbeschreibungen sind häufig prototypisch, sie legt sozusagen einen idealen Vertreter der Elemente der Konzeptklasse fest, den Prototypen

21 Wissensarten – Grundbegriffe
Def. Prototypisches Wissen, Default-Aussage: Prototypisches Wissen besteht aus Default-Aussagen. Eine Aussage heißt Default-Aussage, wenn sie eine Angabe zu einem Sachverhalt macht, der in der Regel zutrifft, aber in Einzelfällen falsch sein kann Def. Definitorische vs. kontingente Aussagen: Eine definitorische Aussage zu einem Konzept betrifft den Konzeptinhalt, während dies für eine kontingente Aussage nicht zutrifft Beispiel: Eine definitorische Aussage, die zu einem Konzeptklasse K gehört, muß für ein gegebenes Individualkonzept i zutreffen, damit i zu K gehören kann. Z.B. ist die Aussage, dass der öffentliche Nahverkehr ausgebaut werden muß, kontingent für das Konzept Nahverkehr; die Aussage, dass alles Verkehrsaufkommen zur Überwindung von Entfernungen bis zu 20km als Nahverkehr gilt, ist hingegen definitorisch

22 Wissensarten – Grundbegriffe
Metawissen ist Wissen über Wissen, z.B. darüber, ob Wissen widersprüchlich, unsicher, unvollständig usw. ist. Allgemeinwissen („Commonsense Knowledge“) ist Wissen, das Menschen einsetzen, um alltägliche Probleme zu lösen. Fachwissen soll dann Wissen sein, das Experten einsetzen, um domänen-spezifische Probleme zu lösen Sehr viel ausführlichere Betrachtungen wären möglich, wir wollen aber vor dem Einsteig in die „Wissensverarbeitung“ mit Prolog bzw. im Semantic Web nur einen ersten Überblick gewinnen und dann „konkret“ werden. [Die Ausführungen stützen sich bis hier hin auf Uli Reimer, „Einführung in die Wissensrepräsentation“, Teubner, 1991]

23 Kleiner Review: Aussagenlogik
Eine Aussage ist eine sprachliche Formulierung, welcher man eindeutig einen Wahrheitswert zuordnen kann Unter Wahrheitswert verstehen wir wahr und falsch (wahr wird im folgenden mit 1, falsch mit 0 abgekürzt) „München liegt in Deutschland“ hat den Wahrheitswert 1 „Schwefel ist ein Metal“ den Wahrheitswert 0 Die (klassische) Aussagenlogik beschränkt sich auf die Betrachtung solcher Sprachgebilde, denen eindeutig ein Wahrheitswert zugeordnet werden kann Die Aussagenlogik beschäftigt sich damit, wie man solche Aussagen zu komplexeren sprachlichen Gebilden kombinieren kann und wie man den Wahrheitswert dieser komplexen Gebilde aus den Wahrheitswerten der in sie eingehenden einzelnen Aussagen (unter Anwendung logischer Prinzipien) bestimmen kann (sogar rein „mechanisch“!) Beispiel: „Wenn München in Deutschland liegt und Schwefel ein Metal ist, dann können Schweine fliegen“ Ist dieser Satz „wahr“ oder „falsch“? (mit den Vorgaben von oben)

24 Kleiner Review: Aussagenlogik
Wir abstrahieren im Weiteren von den eigentlichen Aussagen und setzen Platzhalter (Aussagenvariablen) an ihre Stelle, also A, B, C, ... usw. Die Platzhalter A,B,C,... repräsentieren atomare Aussagen Zur Kombination von atomaren Aussagen stehen uns Verbindungswörter zur Verfügung: und (Æ), oder (Ç), nicht (:) (Syntax) Mit diesen können wir Formeln F,G,H... erstellen: Zunächst ist jede atomare Aussage eine Formel. Wenn wir zwei Formeln F und G haben, dann sind (F Æ G), (F Ç G), : F und : G Formeln. Nichts anderes ist eine aussagenlogische Formel (Semantik) Eine Formel H ist genau dann wahr, wenn sie entweder eine atomare Aussage ist und diese wahr ist oder, wenn H von der Form (F Æ G) ist und sowohl F als auch G wahr sind oder, wenn H von der Form (F Ç G) ist und mindestens eine der beiden Teilformeln F, G wahr sind oder, wenn H von der Form : F ist und F falsch ist.

25 Kleiner Review: Aussagenlogik
Wahrheitswerte und ihre Bestimmung kann man hervorragend mit Wahrheitstafeln darstellen: F G : F F Æ G F Ç G F ! G F $ G F © G 1 !, $ und © sind ableitbar aus den anderen Operatoren (sogenannter „Syntactic Sugar“ - man braucht auch einen Operator von Ç bzw. Æ nicht unbedingt: F Ç G ´ :( : F Æ : G) bzw. F Æ G ´ : (: F Ç : G)

26 Kleiner Review: Aussagenlogik
Eine Zuordnung von Wahrheitswerten zu den atomaren Aussagen in einer Formel, z.B. in F = A Ç (: B Æ : A) nennt man „Belegung“, z.b. A/0, B/0. Aus einer solchen Belegung ergibt sich mit den semantischen Definitionen der Operatoren ein Wahrheitswert für F, hier eben 0 Ç (: 0 Æ : 0) = 0 Ç (1 Æ 1) = 0 Ç 1 = 1 (also ist F wahr) Für n atomare Aussagen gibt es 2n mögliche Belegungen Eine Formel F ist genau dann erfüllbar, wenn es mindestens EINE Belegung gibt, die sie wahr werden läßt. F ist genau dann gültig, wenn ALLE Belegungen, die zu ihr passen, sie wahr werden lassen (dann heißt F auch Tautologie) Eine Belegung passt zu einer Formel F, wenn die Belegung (mindestens) für alle atomaren Aussagen, die in F vorkommen, einen Wahrheitswert angibt F ist genau dann unerfüllbar (bzw. ungültig), wenn keine zu F passende Belegung F erfüllt. F ist genau dann gültig, wenn : F unerfüllbar ist (d.h. wenn F gültig ist, dann ist : F unerfüllbar und wenn : F unerfüllbar ist, dann ist F gültig, denn die Äquivalenz setzt sich aus einer Konjunktion (=Ver-Undung) von zwei Implikationen (=Folgerungen) zusammen

27 Kleiner Review: Aussagenlogik
Die Erfüllbarkeit, Gültigkeit, Unerfüllbarkeit einer Formel F kann man gut mit Wahrheitstafeln bestimmen. Wenn die Spalte unter F nur Nullen enthält, dann und nur dann ist F unerfüllbar nur Einsen enthält, dann und nur dann ist F gültig (mindestens) eine Eins enthält, dann und nur dann ist F erfüllbar Allerdings hat eine Wahrheitstafel eben 2n Zeilen...der Aufwand zur Beantwortung einer Gütligkeits/Erfüllbarkeitsfrage ist also exponentiell zur Anzahl der Vorkommenden atomaren Aussagen! Aber genau diese Fragen will man sich natürlich stellen! Geht das denn besser?

28 Kleiner Review: Aussagenlogik
Nicht wirklich: Stephen Cook hat 1971 gezeigt, dass das Erfüllbarkeitsproblem (SAT) für aussagenlogische Formeln NP-vollständig ist d.h. es ist kein deterministischer Algorithmus bekannt, der SAT-Problem generell „effizient“ ist (also einen Aufwand erfordert, der polynomiell zur Anzahl der atomaren Aussagen ist) Im zu erwartenden Mittel kann man aber etwas besser werden, als 2n, z.B. wenn man ein wenig „randomisiert“ (also den Zufall mitspielen läßt) und nur einen eingeschränkten Fall betrachtet, nämlich Formeln, die aus Konjunktionen von Disjunktionen bestehen (also in konjunktiver Normalform sind) und bei denen jede Disjunktion nur aus höchstens 3 Literalen besteht KNF: (A Ç B Ç C) Æ (: A Ç : B), konjunktive Normalform DNF: (A Æ B) Ç (: A Æ B), disjunktive Normalform Literal: atomare Aussage oder negierte atomare Aussage, z.B. A oder : A Zu jeder Formel F existieren semantisch äquivalente Formeln in konjunktiver und disjunktiver Normalform Semantisch äquivalent: Gleicher Wahrheitswertverlauf Aber substantiell hilft das auch nicht weiter... weitere Details hierzu finden Sie z.B. Uwe Schöning, „Ideen der Informatik“, Oldenbourg, 2002

29 Kleiner Review: Aussagenlogik
Beschränkt man sich allerdings auf Konjunktionen von sogenannten Hornformeln, dann gibt es einen sehr effizienten Algorithmus (Markierungsalgorithmus) Hornformeln sind Disjunktionen von Literalen, die nur höchstens ein positives Literal enthalten, eine Konjunktion solcher Formeln ist z.B. (: A Ç B) Æ (: B Ç : C Ç D) Æ (: B Ç C) Æ A Æ : E = F (A ! B) Æ ((B Æ C) ! D) Æ (B ! C) Æ (1 ! A) Æ (E ! 0) = F Jetzt wird alles markiert, was rechts von einer 1 steht (also alle As) Und dann alles, was rechts von einem Pfeil auftaucht auf dessen linker Seite alles markiert ist. Es werden jeweils alle Vorkommen markiert! Wenn etwas markiert wird, das links von einer 0 steht, dann ist die Formel unerfüllbar. Wenn das nicht passiert, dann ist sie erfüllbar (alles Markierte wird mit 1 belegt, alles andere mit 0, dann hat man eine erfüllende Belegung, diese wird auch MODELL genannt). [Suchen Sie nach einem Modell für F!] Wenn man untersuchen will, ob eine Formel F gültig ist, dann kann man den Markierungsalgo auf die Negation von F anwenden (falls : F sich als Konjunktion von Hornformeln darstellen läßt)

30 Kleiner Review: Aussagenlogik
Es gibt noch eine generelle Alternative zur Wahrheitstafelmethode (die aber auch sehr teuer werden kann), die Herleitung einer leeren „Klausel“ mittels Resolution Gegeben ist eine Formel F in KNF. Diese bringen wir in „Klauselform“: jede Disjunktion schreiben wir als Menge von Literalen, solch eine Menge heißt Klausel z.B. (A Ç B Ç : C) wird zu {A,B,:C} Aus zwei Klauseln K1,K2 kann man einen Resolventen R bilden , wenn es ein Literal L gibt, das in einer Klausel positiv und in der anderen negativ vorkommt, z.B. {A,C} = K1 und {A,B,:C} = K2. Der Resolvent R ergibt sich dann, indem die beiden gefunden „komplementären“ Literale entfernt und die jeweiligen Reste vereint, also oben R = {A,B} = {A,C} – {C} [ {A,B,:C} – {:C} Ergibt sich dabei auf irgendeinem Weg eine leere Klausel ¤ , dann ist F unerfüllbar! Warum? Sei F = ... Æ A Æ : A ..., also F = {...,{A},{: A},...}. Dann lässt sich unmittelbar die leere Klausel, also ¤, ableiten, F ist also unerfüllbar – das ist auch „logisch“, denn unabhängig vom „Rest“ sind A und : A natürlich widersprüchlich. Beim Hinzufügen von Resolventen bleibt die Formelmenge hinsichtlich der Unerfüllbarkeit äquivalent! (kann man sich auch einfach am abstrakten Beispiel überlegen) – wir „entdecken“ also nur den Widerspruch geschickt Wenn man solange Resolventen bildet, bis keine neuen Resolventen mehr gefunden werden können und dabei jeweils die neu hinzukommenden mit als mögliche Ausgangsklauseln K in Erwägung zieht, dann ist die Formel erfüllbar. Findet man bei diesem Prozeß hingegen die leere Klausel, dann ist die Formel unerfüllbar. Wenn man „geschickt“ ist, dann kann man die leere Klausel mit einer „minimalen“ Anzahl von Resolventenbildungen finden...aber auch das kann im Worst Case exponentiellen Aufwand verursachen...

31 Kleiner Review: Aussagenlogik
Weitere Details finden Sie in den INT A-Unterlagen oder z.B. in Schöning, Logik für Informatiker, 5. Aufl. Was haben wir also? Ein NP-vollständiges Problem für „volle“ Aussagenlogik mit zwei „Lösungsverfahren“ Wahrheitstafeln (immer teuer bei Unlösbarkeit) Resolution (manchmal günstig) (Vereinfachen geht auch noch manchmal) Eine Variante mit Hornformeln, die nicht alles ausdrücken kann, ... ... dafür mit einem effizienten Lösungsverfahren Ganz ähnlich ist die Situation in der Prädikatenlogik...(nur noch etwas „unangenehmer“, weil es „semi-entscheidbare“ Probleme gibt)

32 Kleiner Review: Aussagenlogik
Lösen Sie das folgende Problem: Inspektor Craig hat einen Fall zu lösen. Er hat 3 Personen in Verdacht, die Tat begangen zu haben. Als Täter kommen nur A,B oder C in Frage. Inspektor Craig hat folgende Informationen: Wenn A schuldig und B unschuldig sind, so ist C schuldig C arbeitet niemals allein A arbeitet niemals mit C Nur A, B oder C kommen als Täter in Frage Formulieren Sie die Informationen aussagenlogisch Bringen Sie die Formeln in KNF (also eine Konjunktion von Disjunktionen, eine reine Disjunktion ist auch in KNF ;-) Überprüfen Sie mittels Resolution die Vermutung Inspektor Craigs, dass B einer der Täter war (fügen Sie also : B zur Formelmenge hinzu und suchen sie nach einem Widerspruch)

33 Prädikatenlogik ultra-knapp
Gibt es etwas, das die Aussagenlogik nicht so gut kann? Schauen wir uns nochmal unser erstes Problem an: In einer Firma arbeiten drei Freunde: ein C++-Programmierer, ein Java-Programmierer und ein Pascal-Programmierer. Ihre Namen sind Otto, Paul und Kai. Der C++-Programmierer hat keine Geschwister; er ist der Jüngste der drei Freunde. Kai, der mit der Schwester von Otto verheiratet ist, ist älter als der Java-Programmierer. Wer programmiert in welcher Sprache? Können Sie das mit Aussagenlogik formalisieren? Probieren Sie es mal!

34 Prädikatenlogik ultra-knapp
Der C++-Programmierer hat keine Geschwister. Vielleicht ist es Otto? cplusplus-programmierer_otto ! keine_geschwister_otto Aber vielleicht ist es auch einer der anderen? cplusplus-programmierer_paul ! keine_geschwister_paul cplusplus-programmierer_kai ! keine_geschwister_kai Schlimmer wird es noch für die Aussage „Der C++-Programmierer ist der Jüngste“!

35 Prädikatenlogik ultra-knapp
Nochmal: Der C++-Programmierer hat keine Geschwister. Das heißt doch eigentlich: Wenn jemand C++-Programmierer ist, dann hat dieser jemand keine Geschwister Wenn wir den mysteriösen Jemand mit einem Platzhalter, z.B. x, identifizieren und als Programmierer erkennen, dann können wir schreiben Wenn ein Programmierer x c++ programmiert, dann hat x keine Schwester Programmierer(x) Æ Programmiert(x, c++) ! hat_keine_Geschwister(x) Das ist aber schäbig...man kann die Eigenschaft „hat_keine_Geschwister“ gar nicht mit der Eigenschaft „hat_Geschwister“ in Bezug setzen...besser: hat_keine_Geschwister(x) entspricht: es gibt kein y, so dass Geschwister(x,y) erfüllt wäre. In der Prädikatenlogik kann man dann schreiben: @ y Geschwister(x,y) bzw. : 9 y Geschwister(x,y) Insgesamt gilt für alle C++-programmierenden Personen: 8 x (Programmierer(x) Æ Programmiert(x, c++) ! : 9 y Geschwister(x,y))

36 Prädikatenlogik ultra-knapp
Programmierer(Kai). Programmierer(Otto). Programmierer(Paul). Language(C++). Language(Java). Language(Pascal): Geschwister(Otto,Karla). 9 x (Programmierer(x) Æ Programmiert(x,C++)). 9 x (Programmierer(x) Æ Programmiert(x,Java)). 9 x (Programmierer(x) Æ Programmiert(x,Pascal)). 8 x (Programmierer(x) Æ Programmiert(x,C++) ! : 9 y Geschwister(x,y)) 8 x (Programmierer(x) Æ Programmiert(x,C++) Æ (8 y Programmierer(y) Æ (9 z Language(z) Æ Programmiert(y,z) Æ z  C++) ! Jünger(x,y))) 8 x,y (Geschwister(x,y) ! Geschwister(y,x)). 9 x (Programmierer(x) Æ Programmiert(x,Java) Æ Jünger(x,Kai)). 8 x,y Programmiert(x,y) z (Programmiert(x,z) Æ z  y)

37 Prädikatenlogik ultra-knapp
Operatoren Ç, Æ, !, $, : wie in der Aussagenlogik. Wir können jetzt aber einzelne/alle Objekte anfassen. Es kommen also Quantoren hinzu: Existenzquantor: Es existiert ein x, so dass gilt...: 9 x Allquantor: Für alle x gilt ...: 8 x Außerdem können wir Beziehungen zwischen Objekten beschreiben mit Prädikaten: Für alle x 2 N gilt: es existiert ein y 2 N mit x “ist_kleiner_als” y 8 x (N(x) ! 9 y (N(y) Æ ist_kleiner_als(x,y))) Und wir können mit Objekten “rechnen”, also Funktionen in Prädikaten verwenden 8 x 8 y (N(x) Æ N(y) ! 9 z (N(z) Æ equals(z,x+y)))

38 Prädikatenlogik ultra-knapp
Def. Terme Jede Konstante ist ein Term (Konstanten sind 0-stellige Funktionssymbole) Jede Variable ist ein Term Sind t1,...,tn Terme und f ein n-stelliges Funktionssymbol, so ist auch f(t1,...,tn) ein Term. Def. Prädikatenlogische Formeln Ist p ein n-stelliges Prädikatssymbol und sind t1,...,tn Terme, dann ist p(t1,...,tn) eine atomare Formel. Sind F und G Formeln, dann sind auch (F Æ G), (F Ç G), (F ! G), (F $ G) Formeln

39 Statt einer Erläuterung der Semantik: Eine abgespeckte Prädikatenlogik „für Praktiker“
Prolog (s. Übungen/Folien/Tutorium auf unserer Webseite) Hervorzuhebende Aspekte: Prolog ist „fast“ Hornklausel-Logik (also eine „abgespeckte“ Variante von FOL (=first order logic), in der es in jeder Klausel nur höchstens ein positives Prädikat gibt) Prolog ist leider nicht vollständig „logisch“, denn seine „normale“ Abarbeitungsstrategie ist nicht vollständig (d.h., es findet manchmal keine Lösung, obwohl es eine gibt). Prolog besteht aus Fakten+Regeln+Anfragen. Alles in Prolog ist ein Term. Prolog verwendet eine Tiefensuche und Backtracking, um Anfragen zu beantworten. Hierbei verwendet es Unifikation (Variablen werden gleichgesetzt, z.B. X=Y, oder mit Termen identifiziert), um Bindungen an Variablen zu finden, die die betroffenen Regeln erfüllen Prolog kann auch in limitierter Weise mit Negation umgehen

40 Prolog, einige Aspekte... Wichtige „Datenstruktur“ Listen
im Grunde auch „klassische“ Terme: .(a(.(b,.(c,[]))) - Liste (a,b,c) (wird immer durch eine leere Liste abgeschlossen). Prolog bietet eine „schönere“ Notation als „Abkürzung“: [a,b,c] = [a |[b,c]] = [a,b|[c]] = [a,b,c|[]] Der senkrechte Strich trennt die Liste in Kopf | Restliste Kann man direkt in Anfragen verwenden: ?- [a,b,c,d,e] = [X|Y]. Antwort: X=a, Y=[b,c,d,e] ?- [a,b,c,d,e] = [a,b|X]. Antwort: X = [c,d,e] ?- [a,b,c,d,e] = [_,_,_|X] Antwort: X = [d,e]

41 Prolog, einige Aspekte Gegeben: Kopf :- S1,S2,...,Sn (Klausel C)
„Logisch“/“Deklarativ“: Kopf à S1 Æ S2 ... Æ Sn (Klausel C) Äquivalent auch: Kopf Ç : S1 Ç ... Ç : Sn Hier fehlen noch die Quantoren – es ist alles Allquantifiziert: 8 X 8 Y: C Ein Ziel Z ist erfüllt, wenn es eine Klausel C gibt, deren Kopf sich mit Z unifizieren läßt und alle Prädikate im „Körper“ von C (also S1,...,Sn) erfüllt sind (unter der gegebenen und gegebenenfalls zu erweiternden Variablensubstitution) Prolog findet aber leider nicht alle sinnvollen Substitutionen (es kann sich in unendliche Zweige verrennen, obwohl es eine sinnvolle Lösung gäbe). Warum?

42 Prolog, einige Aspekte Folgende Aufgabe: „Logische“ Idee:
Gegeben ist ein Graph G durch die Angabe aller Kanten: kante(a,b). kante(b,c). kante(c,d). kante(d,a). kante(d,e). Gesucht ist ein Prädikat, dass die möglichen Wege zwischen zwei Knoten beschreibt „Logische“ Idee: path(X,Y) :- path(X,Z),path(Z,Y). % Es gibt einen Weg von X nach Y, wenn es einen Zwischenhalt Z gibt, der von X erreichbar ist und von dem aus man Y erreicht. path(X,Y) ;- kante(X,Y). % Jede Kante ist ein Weg Das macht Prolog nervös, weil die erste Klausel zu einer Anfrage, z.B. ?- pfad(a,b), paßt und das erste Teilziel dann pfad(a,Z) ist ... und da wieder die erste Klausel paßt Prolog schaut sich den korrekten Lösungspfad im Baum der möglichen Lösungspfade einfach nicht an

43 Prolog, einige Aspekte Hilft eine andere Reihenfolge der Klauseln?
path(X,Y) ;- kante(X,Y). path(X,Y) :- path(X,Z),path(Z,Y). Fragen wir mal nach ?- pfad(a,b). In den Fakten war „kante(a,b).“ enthalten – Prolog antwortet korrekt. Neue Frage: ?- pfad(a,c). Die erste Klausel paßt, gibt aber nichts her. Die zweite Klausel paßt und führt zunächst zum „Aufruf“ von path(a,Z). Dazu liefert die erste Klausel eine Antwort: Z = b. Damit wird das zweite Subziel aufgerufen: path(b,c). Auch hierzu gibt es eine korrekte Antwort durch die erste Klausel, also Yes. Neue Frage: ?- pfad(a,a).

44 Prolog, einige Aspekte Antwort: YES
Hilft eine andere Reihenfolge der Klauseln? path(X,Y) ;- kante(X,Y). path(X,Y) :- path(X,Z),path(Z,Y). Neue Frage: ?- pfad(a,a). Erste Klausel liefert nichts, zweite Klausel ruft erstes Teilziel auf: pfad(a,Z). Wir finden zunächst wie eben pfad(a,b) mit der ersten Klausel. Das führt zum Aufruf von pfad(b,a). Die erste Klausel failed, Aufruf der zweiten Klausel für pfad(b,a). Aufruf des ersten Teilziels: pfad(b,Z). Erste Klausel antwortet Z = c Aufruf des zweiten Teilziels: pfad(c,a) Erste Klausel failed Zweite Klausel ruft pfad(c,Z) auf, 2. Klausel antwortet Z = d pfad(d,a) wird aufgerufen, exit aus der ersten Klausel, exit zweites Teilziel Exit erstes Teilziel Exit pfad(b,a) Exit pfad(a,b) Antwort: YES

45 Prolog, einige Aspekte ?- path(e,X).
Hilft eine andere Reihenfolge der Klauseln? path(X,Y) ;- kante(X,Y). path(X,Y) :- path(X,Z),path(Z,Y). ?- path(e,X). Die erste Klausel passt nicht (nie!) Das Path in der zweiten Klausel wird immer wieder aufgerufen, um Path zu beweisen ... Out-of-Stack! ?- path(a,f). Genauso...wir finden alle gangbaren Wege von a aus, aber dann... Übrigens: „fast“ alle gangbaren Wege von a aus erhalten sie über path(a,X). und wiederholte Eingabe von ; ... aber wenn sie nicht rechtzeitig aufhören, dann „out-of-Stack“ (wg. e) Übrigens gibt es unendlich viele gangbare Wege: a-b-c-d-a-b-c-d-a ... aber dieses „Problem“ sieht Prolog nicht, weil es soweit gar nicht kommt

46 Prolog, einige Aspekte Wo liegt das Problem für path(e,X) und path(a,f)? path(X,Y) ;- kante(X,Y). path(X,Y) :- path(X,Z),path(Z,Y). Prolog „sieht“ nicht, dass es keinen Sinn macht, noch nach path(e,X) zu suchen, wenn es keine Kanten gibt, die von e ausgehen Man kann Prolog helfen, indem man den rekursiven Aufruf „grounded“ – man sorgt dafür, dass es einen „reale“ Ausgangspunkt wirklich gibt: path(X,Y) :- kante(X,_),path(X,Z),path(Z,Y). Dann liefert path(e,X) ein korrektes NO – aber noch nicht path(a,f). Also: path(X,Y) :- kante(X,_),kante(_,Y),path(X,Z),path(Z,Y). Jetzt gehen beide, aber path(a,X) liefert unendlich oft X=b als Antwort (warum?)

47 Prolog, einige Aspekte Eine knappere Variante:
path(X,Y) ;- kante(X,Y). path(X,Y) ;- kante(X,Z),path(Z,Y). Jetzt hat jeder Pfad einen „gegroundeten“ Anfang... path(a,X) funktioniert jetzt (und liefert unendlich viele Antworten) ...aber path(a,f) geht wieder nicht mehr...warum? Weil die Daten einen Kreis bilden...und es unendlich viele Wege gibt, die vielleicht einen Abzweig nach e haben könnten... Wie wäre es mit einer Kante als Abschluß? path(X,Y) :- kante(Z,Y), path(X,Z). Das geht bei path(e,X) gar nicht gut...(warum?) – auch nicht bei pfad(f,a)

48 Prolog, einige Aspekte Also doch beides „grounden“ - geht alles?
knoten(X) ;- kante(X,_). knoten(Y) :- kante(_,Y). path(X,Y) ;- kante(X,Y). path(X,Y) :- knoten(Y), kante(X,Z), path(Z,Y). path(a,f), path(f,a), pfad(e,X) funktionieren. Aber leider geht pfad(a,X) nicht komplett: liefert b, dann a und dann immer weiter a ... ... und wenn man knoten(f) (ein unverbundener Knoten) hinzufügt, dann geht auch path(a,f) nicht mehr! Vielleicht helfen ja Anfangs- und Abschlußkante. pfad(X,Y) :- kante(X,Y). pfad(X,Y) :- kante(X,Z), kante(Z,Y). pfad(X,Y) :- kante(X,Z1), pfad(Z1,Z2), kante(Z2,Y).

49 Prolog, einige Aspekte Vielleicht helfen ja Anfangs- und Abschlußkante. pfad(X,Y) :- kante(X,Y). pfad(X,Y) :- kante(X,Z), kante(Z,Y). pfad(X,Y) :- kante(X,Z1), pfad(Z1,Z2), kante(Z2,Y). Jetzt funktionieren pfad(a,X), pfad(e,X), pfad(f,a) Aber nicht pfad(a,f)... ...weil er wieder ewig im Kreis sucht – Prolog „sieht“ nicht, dass er mit Kante(Z2,f) sofort ein fail für die zweite Klausel erzeugen könnte. Vielleicht so? pfad(X,Y) :- kante(X,Z1), kante(Z2,Y), pfad(Z1,Z2). Jetzt liefert pfad(a,X) b;c;b;b;b;b;... suchen Sie nach einer besseren Lösung!

50 Prolog, einige Aspekte Prolog findet aber leider nicht alle sinnvollen Lösungen bzw. Substitutionen (es kann sich in unendliche Zweige verrennen, obwohl es eine sinnvolle Lösung gäbe). ...und zwar, weil es eine bestimmte Reihenfolge in der „Abarbeitung“ von „passenden“ Klauseln einhält (von oben nach unten) und deshalb manche Möglichkeiten nicht verfolgt, sondern einer Spur nach unten zu lange treu bleibt ... und die Subziele in einer Klausel von links nach rechts abarbeitet (Probleme bei der Substitution, wenn links sehr viele, ev. unendlich viele Substitutionsmöglichkeiten auftreten, die man hätte „grounden“ (sprich: beschränken) können durch eine andere Reihenfolge

51 Prolog, einige Aspekte: append/2
Spaß mit append: append([],L,L). append([X|L1],L2,[X|L3]) :- append(L1,L2,L3). ?- append([1,2],[3,4],L). L = [1,2,3,4] ?- append([1|R1],[5,R2],[1,3,5,7]). R1 = [3], R2 = [7] ?- append(L1,L2,[1,2,3]). L1 = [] L2 = [1,2,3] ; L1 = [1] L2 = [2,3] ; L1 = [1,2] L2 = [3] ; L1 = [1,2,3] L2 = [] ; no

52 Prolog, einige Aspekte: Listen
Element/2 element(X,[X|_]). element(X|[_|Y]) :- element(X,Y). Deklarative Interpretation: Jede Liste, die X als führendes Element enthält, erfüllt das Prädikat. Enthält eine Liste X, so enthält auch jede um ein Element erweiterte Liste X Prozedurale Interpretation Untersuche, ob das gesuchte Element das erste Element der Liste ist Wenn nein, untersuche, ob es in der Restliste vorkommt ?- element(X,[1,2,3]). X=1; X=2; X=3; no

53 Prolog, einige Aspekte: Listen
Delete/3 delete(X,[X,T],T). delete(X,[Y|T],[Y|U]) :- delete(X,T,U). ?- append(X,[1,2,3], Rest). X = 1 Rest = [2,3] ; X = 2 Rest = [1,3] ; X = 3 Rest = [1,2] ; no Anhängen eines einzelnen Elements el_append(Element,L,LN) :- append(L,[Element],LN). Prüfen, ob eine Liste L1 Teilliste einer Liste L2 ist enthalten(L,SL) :- append(L1,L2,LS), append(L,_,L2) PS: nicht sehr effizient...

54 Prolog, einige Aspekte: Akkumulator
Umdrehen ohne Akkumulator umdrehen([],[]). umdrehen([K|Rest]) :- umdrehen(Rest,Y), append(Y,[K],X). Läuft endlos, wenn man nach zwei Lösungen für umdrehen(X,[a,b,c]) fragt. Umdrehen mit Akkumulator reverse(L1,L2) :- rev(L1,L2,[]). rev([],L2,L2) :- !. % Ein Cut rev([X|Xs],L2,Acc) :- rev(Xs,L2,[X|Acc]). Mit diesem Cut findet man nur die eine “richtige” Lösung, wenn man reverse(X,[a,b,c]) fragt. Wird er entfernt, läuft das Prädikat auch in eine Endlosschleife bei der Frage nach zwei Lösungen.

55 Prolog, einige Aspekte: Akkumulator
Akkumulator und Cut reverse(L1,L2) :- rev(L1,L2,[]). K1: rev([],L2,L2) :- !. K2: rev([X|Xs],L2,Acc) :- rev(Xs,L2,[X|Acc]). rev(L1,[a,b],[]) 1: K1 passt nicht, K2 rev([X1|Xs1],[a,b],Acc1 = []) :- rev(Xs1,[a,b],[X1|[]]) 2: K1 passt nicht, K2 rev(Xs1 = [X2|Xs2],[a,b],Acc2 = [X1|[]]) :- rev(Xs2,[a,b],[X2|[X1|[]]]) 3: K1 passt, Xs2 = [], X2 = a, X1 = b. exit 2back: rev(Xs1 = [a,[]],[a,b],Acc2 = [b|[]]) exit 1back: rev([b,[a,[]]],[a,b],[]). exit Antwort: L = [b,a] Wenn man ; eingibt, versucht Prolog, dass Subziel unter 2 nicht noch einmal zubeweisen. Wenn der Cut fehlt, wird die Regel K2 dann aufgerufen, um rev(Xs2,[a,b],[X2|[X1|[]]]) zu zeigen, dass führt zu rev(Xs2 = [X3|Xs3],[a,b],Acc3=[X2|[X1|[]]]) :- rev(Xs3,[a,b],[X3|[X2|[X1|[]]]]). ... usw., der Akkumulator ist dann zu lang, um [a,b] zu matchen – und wird immer länger!

56 Prolog, einige Aspekte: Arithmetik, Rekursion
Achtung: Arithmetik funktioniert nur wie erwartet, wenn die Variablen auf der rechten Seite gebunden sind (sonst operiert man mit nicht-ausgerechneten Termen bzw. erhält Fehler)! sumlist([H|T], Sum) :- sumlist(T,Sum1), Sum is Sum1 + H. Vertauschung der Reihenfolge der Subziele führt zu Fehlern (logisch betrachtet wäre die Reihenfolge aber „wurscht“) Berechnen Sie die Fakultät einer Zahl n rekursiv! Was ist falsch? fak(N, Fak) :- N1 ist N + 1, fak(N1, Fak1), Fak is Fak1 * N. fak(0,1). Anfrage: ?- fak(4,Fak). Korrekte Version fak(N, Fak) :- integer(N), N > 0, N1 ist N + 1, fak(N1, Fak1), Fak is Fak1 * N.

57 Prolog, einige Aspekte: Rekursion
Mehr Rekursion – sie kennen die Türme von Hanoi: Es gibt 3 Ablageplätze. Auf dem linken Platz liegen 8 Scheiben. Diese sind der Größe nach geordnet, unten liegt die größte, darüber die nächstkleinere usw. Die Aufgabe ist es nun, die Scheiben auf den Platz rechts außen umzulegen, ohne jemals eine größere auf eine kleinere Scheibe zu legen Schreiben Sie ein solches Programm! Regelkopf transportiere(Scheibenzahl,Von,Nach,Hilf) :- Aufruf: ?- transportiere(8,1,2,3). Programm: transportiere(1,V,N,_) :- write(‚Transport-von‘-V-‘nach‘-N), nl. transportiere(S,V,N,H) :- Oben is S – 1, transportiere(Oben,V,H,N), transportiere(1,V,N,H), transportere(Oben,H,N,V).

58 Prolog, einige Aspekte: Cut
Rekursion. Wünschenswert ist Tail-Rekursion, d.h. nach dem rekursiven Aufruf kommt nichts mehr (dann muß man sich nichts merken, das man im Erfolgsfall dann wieder aufgreifen müßte) Um Effizienz (und ein paar andere Dinge) geht es auch beim Cut: einkommen(X,gering) :- X < 1000. einkommen(X,mittel) :- X >= 1000, X =< % Achtung =< ! einkommen(X,hoch) :- X > 2000. Anfrage: ?- einkommen(950,B), B = hoch. Alle 3 Regeln werden probiert und scheitern. Wenn das Einkommen < 1000 ist, kommt nur die erste Regel in Frage...mit X = 950 könnte man dort aufhören und sich weiteres Suchen ersparen einkommen(X,gering) :- X < 1000, !. einkommen(X,mittel) :- X =< 2000, !. einkommen(X,hoch). Cut sagt hier: Wenn die Regel paßt, ist es genau die Richtige! Weitersuchen zwecklos.

59 Prolog, einige Aspekte: Cut
Aufgabe: Klassifikation von Tennisspielern Jemand, der sowohl gewinnt, als auch verliert, ist ein „kaempfer“ Jemand, der stets gewinnt, ist ein „gewinner“ Alle andern sind „bemueht“ typ(X,kaempfer) :- gewinnt(X,_), gewinnt(_,X), !. typ(X,gewinner) :- gewinnt(X,_), !. typ(X,bemüht) :- gewinnt(_,X). Anmerkung: Wenn man nur typ(X,bemueht) schreiben würde, wäre jedes X bemüht, auch solche, die gar nicht spielen, also nicht in der „gewinnt“-Datenbank auftauchen Auch hier hilft der Cut, weil er eine präzise Regelwahl erlaubt.

60 Prolog, einige Aspekte: Cut
Die Wirkung des Cut setzt erst beim Backtracking ein H :- B1,...,Bn, !, A1,...,Am Wenn es gelingt, B1,...,Bn zu erfüllen, dann wird bei einem eventuellen Backtracking nicht mehr versucht, B1,...,Bn neu zu erfüllen – und auch nicht H! (Das ist ganz wesentlich) Der Cut kann die „logische“ Bedeutung einer Programms verändern: p :- a,b. p :- c (a Æ b) Ç c ! p p :- a, !, b. p :- c. Die zweite Regel ist nur erreichbar, wenn a nicht gilt! (a Æ b) Ç (: a Æ c) ! p

61 Prolog, einige Aspekte: Cut
Effizienzsteigerung mit Cut union([],M,M). union([E|T],M,V) :- member(E,M), !, union(T,M,V). union([E|T],M,[E|T2]) :- not member(E, M), union(T,M,T2). Wenn E ein Member von M ist, dann kann not member nicht erfüllt werden – d.h., diese Regel brauchen wir dann auch nicht aufzurufen, um union zu erfüllen. Der Cut ist hier ein GRÜNER CUT. union([E|T],M,[E|T2]) :- union(T,M,T2). Hier ist der Cut ein ROTER Cut, denn er verändert das Ergebnis der Auswertung! ?- union([1],[1,2],X). Antwort mit Cut: X = [1,2] ; no Antwort ohne Cut: X = [1,2]; X = [1,1,2]; no

62 Prolog, einige Aspekte: Negation
K1: keine_kinder(P) :- elternteil_von(P,_), !, fail. K2: keine_kinder(P). Prädikat fail/0 ist immer „falsch“ (failed also immer) Wenn P also Kinder hat, dann schlägt die erste Regel fehl und der Cut verhindert, dass nach weiteren passenden Klauseln gesucht wird. Im anderen Fall scheitert die Regel oben vor dem Cut und die zweite Regel kommt zum Tragen. Praktisch genauso ist das Prädikat not/1, auch +/ geschrieben als Operator, definiert: not(Ziel) :- Ziel, !, fail. not(_). Achtung: not liefert nie eine Variablenbelegung, entspricht also nicht dem logischen NOT (freie Variablen sollte es keine geben im Ziel). Das ganze nennt sich: negation-as-failure (es klappt nicht für gebundene Variablen, dann muß es falsch sein!) kredit_würdig(X) :- hat_einkommen(X,Y), einkommen(Y,gering),!,fail. Die Cut-Fail-Kombination stellt hier sicher, dass jemand mit niedrigem Einkommen nicht kreditwürdig sein kann.

63 OWL/RDF und das Semantic Web

64 RDF – Ressource Description Framework
RDF spricht in Tripel-Kurzsätzen (sogenannten Statements) über die Welt [Subject Predicate Object] Subject und Predicate müssen URI-Referenzen oder Blank Nodes sein, Objekte können auch Literale sein URI steht für Uniform Ressource Locator Eine Menge von Tripeln bildet einen RDF-Graphen, die Knoten sind die Subjects und die Objects, gerichtete Kanten mit Beschriftung stehen für die Predicate

65 RDF Graph [ "RDF/XML Syntax Specification (Revised)„] [_:genid1 "Dave Beckett„] [_:genid1 [ :genid1]

66 RDF Graph Darstellung als N-Triple:
< < "RDF/XML Syntax Specification (Revised)" . :genid1 < "Dave Beckett" . :genid1 < < . < < :genid1 .

67 RDF Graph Darstellung als N-Triple:
< < "RDF/XML Syntax Specification (Revised)" . _:genid1 < "Dave Beckett" . _:genid1 < < . < < _:genid1 . RDF/XML-Syntax (eine Variante...mehr finden sie in der RDF/XML Syntax Specification): <?xml version="1.0"?> <rdf:RDF xmlns:rdf=" xmlns:dc=" xmlns:ex=" <rdf:Description rdf:about=" dc:title="RDF/XML Syntax Specification (Revised)"> <ex:editor rdf:nodeID="abc"/> </rdf:Description> <rdf:Description rdf:nodeID="abc" ex:fullName="Dave Beckett"> <ex:homePage rdf:resource=" </rdf:Description> </rdf:RDF>

68 RDF Listen Listen mit expliziten Element-Nummer-Properties:
<?xml version="1.0"?> <rdf:RDF xmlns:rdf=" <rdf:Seq rdf:about=" <rdf:_1 rdf:resource=" <rdf:_2 rdf:resource=" <rdf:_3 rdf:resource=" </rdf:Seq> </rdf:RDF> Listen mit rdf:li Properties: <?xml version="1.0"?> <rdf:RDF xmlns:rdf=" <rdf:Seq rdf:about=" <rdf:li rdf:resource=" <rdf:li rdf:resource=" <rdf:li rdf:resource=" </rdf:Seq> </rdf:RDF> Beide haben die gleiche n-Triple-Repräsentation: < < < . < < < . < < < . < < < .

69 RDF Collections Eine Liste, die als Collection angegeben wird:
<?xml version="1.0"?> <rdf:RDF xmlns:rdf=" xmlns:ex=" <rdf:Description rdf:about=" <ex:hasFruit rdf:parseType="Collection"> <rdf:Description rdf:about=" <rdf:Description rdf:about=" <rdf:Description rdf:about=" </ex:hasFruit> </rdf:Description> </rdf:RDF> Als N-Triple: :genid1 < < . :genid2 < < . :genid1 < _:genid2 . :genid3 < < . :genid2 < _:genid3 . _ :genid3 < < . < < _:genid1 .

70 RDF Man kann auch Repräsentanten für Statements definieren: [Karsten sagt [Kai trinkt Milch]] [r1 rdf:type rdf:Statement] -- r1 ist eine Ressource, die ein Statement repräsentiert [r1 rdf:subject Kai] [r1 rdf:predicate trinkt] [r1 rdf:object Milch] Das wird in RDF Reifikation genannt – ein sehr nützliches Instrument, das in RDF allerdings keine sinnvolle formale Bedeutung besitzt Das Predicate rdf:type bietet auch die wesentliche Verbindung zu RDFS, es erlaubt die „Typisierung“ von Subjects (bzw. Ressourcen)

71 RDFS RDFS führt ein Vokabular zur Klassifikation von Ressourcen ein
Man kann Ressourcen zu Klassen erklären [rdfs:Ressource rdf:type rdfs:Class] Man kann Ressourcen zu Unterklassen erklären [drive:Auto rdfs:subclassOf drive:Fahrzeug] Man kann Ressourcen an Predicate-Position verwenden, dann sind sie Properties (Eigenschaften) z.b. rdfs:subclassOf und rdf:type oben Man kann URIs aber auch explizit mit rdf:type zu Properties erklären: [fh:seminarBesuchen rdf:type rdfs:Property] Man kann Ressourcen zu Untereigenschaften erklären [fh:seminarBesuchen rdfs:subProperty fh:studieren]

72 RDFS RDFS führt ein Vokabular zur Klassifikation von Ressourcen ein
Man kann festlegen, dass alle Subjects, auf die eine Eigenschaft angewendet wird, aus einer (oder mehreren) bestimmten Klasse stammen [fh:seminarBesuchen rdfs:domain fh:Student] Man kann festlegen, dass alle Objects, die mit einer Eigenschaft an ein Subject gehängt werden, aus einer (oder mehreren) bestimmten Klassen stammen [fh:seminarBesuchen rdfs:range fh:Seminar] Anwendung: [Kai fh:seminarBesuchen HMAB] Interpretation: [Kai rdf:type fh:Student] [HMAB rdf:type fh:Seminar] Viel mehr geht schon nicht...

73 OWL – Ontology Web Language
RDF/RDFS wurden vom W3C standardisiert (d.h. sie haben Recommendation-Status, die höchste Standardisierungsstufe). Schauen sie sich zur Einführung den RDF Primer an. Eine genaue modell-theoretische (und gruselig aufwändige) Festlegung der Semantik finden sie im Dokument RDF Semantics (Editor: Pat Hayes) Syntaktisch und semantisch baut OWL auf RDF/RDFS auf. OWL gibt es in drei Geschmacksrichtung: OWL Lite, OWL DL, OWL Full

74 OWL Varianten OWL Full ("Large OWL", "Great Horned OWL")
Free mixing of OWL and RDF = high expressivity Non-standard formalization Tractability not guaranteed OWL DL ("Fast OWL") (DL = Description Logics) Maximize expressiveness while retaining tractability Standard formalization Same language constructs as OWL Full Constraints on RDF/OWL vocabulary use Correspondence theorem links the two styles of semantics: entailments in OWL DL also hold in OWL Full. OWL Lite is a syntactic restriction of OWL DL: intended to be used for classification hierarchies with simple constraints. OWL DL is closest to DAML+OIL

75 OWL Varianten

76 OWL – Abstract Syntax Namen sind RDF URI-Referenzen. Verwendete Abkürzungen (Namespaces): Namespace Name Namespace rdf rdfs http :// xsd http :// owl http ://

77 OWL – Abstract Syntax Eine OWL Ontologie in der abstrakten Syntax besteht aus einer Folge von Annotationen, Axiomen und Fakten. OWL Ontologien können benannt sein. Annotationen können verwendet werden, um z.B. Autorenschaft oder andere Metadaten zur Ontologie anzugeben, auch Import-Referenzen zu anderen Ontologien. Die wesentliche Inhalt einer OWL Ontologie findet sich in den Axiomen und Fakten, die Informationen über Klassen (classes), Eigenschaften (properties) und Individuen (individuals) enthalten.

78 OWL – Abstract Syntax ontology ::= 'Ontology(' [ ontologyID ] { directive } ')' directive ::= 'Annotation(' ontologyPropertyID ontologyID ')' | 'Annotation(' annotationPropertyID URIreference ')' | 'Annotation(' annotationPropertyID dataLiteral ')' | 'Annotation(' annotationPropertyID individual ')' | axiom | fact Zur Notation: Terminale sind ‘quoted‘ Nicht-Terminale sind fett und nicht quoted Alternatives werden entweder durch | getrennt oder in mehreren Produktionen angegeben. Komponeten, die höchstens einmal auftauchen dürfen, stehen in square brackets ([…]); Komponenten, die beliebig oft auftauchen können (auch gar nicht!) stehen in braces ({…}). Whitespace in den Produktionen ist ohne Bedeutung.

79 OWL – Abstract Syntax datatypeID ::= URIreference classID ::= URIreference individualID ::= URIreference ontologyID ::= URIreference datavaluedPropertyID ::= URIreference individualvaluedPropertyID ::= URIreference annotationPropertyID ::= URIreference ontologyPropertyID ::= URIreference Eine URI Referenz darf nicht sowohl eine datatypeID als auch eine classID in ein und derselben Ontologie sein. Eine URI Referenz darf nur einmal als datavaluedPropertyID, individualvaluedPropertyID, annotationPropertyID, oder ontologyPropertyID in einer Ontologie auftreten. Datatype denotes the set of data values that is the value space for the datatype. Classes denote sets of individuals. Properties relate individuals to other information, and are divided into four disjoint groups, data-valued properties, individual-valued properties, annotation properties, and ontology properties. Data-valued properties relate individuals to data values. Individual-valued properties relate individuals to other individuals. Annotation properties are used to place annotations on individuals, class names, property names, and ontology names. Ontology properties relate ontologies to other ontologies, in particular being used for importing information from other ontologies. Individual identifiers are used to refer to resources, and data literals are used to refer to data values.

80 OWL – Abstract Syntax Es gibt zwei vordefinierte Klassen in OWL:
die Klasse mit dem Identifier owl:Thing ist die Klasse aller Individuen die Klasse mit dem Identifier owl:Nothing ist die Klasse ohne Elemente (=leere Klasse) Die folgenden XML-Schema-Datentypen können in OWL verwendet werden: xsd:string, xsd:boolean, xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:hexBinary, xsd:base64Binary, xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN, xsd:Name, xsd:NCName, xsd:integer, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:nonNegativeInteger, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte and xsd:positiveInteger. Die anderen built-in XML Schema Datentypen sind problematisch für OWL (und RDF), s. Diskussion in Sektion 5.1 der RDF Semantics [RDF Semantics]. Der built-in RDF Datentyp, rdf:XMLLiteral, ist auch in OWL in built-in Datentyp. Es gibt auch keinen standardisierten Weg, um XML-Schema user types in OWL zu verwenden

81 OWL – Abstract Syntax Es gibt einige built-in annotation properties in OWL: owl:versionInfo, rdfs:label, rdfs:comment, rdfs:seeAlso und rdfs:isDefinedBy. rdfs:label und rdfs:comment können nur mit data literals verwendet werden. Es gibt ebenso einige built-in ontology properties: owl:imports, owl:priorVersion, owl:backwardCompatibleWith und owl:incompatibleWith. Ontology annotations, die owl:imports verwenden, führen zu einem Import der genannten Ontologie („target ontology“). Viele OWL-Konstrukte verwenden annotations, die Metadaten über die Konstruktinhalte aufzeichnen: annotation ::= 'annotation(' annotationPropertyID URIreference ')' | 'annotation(' annotationPropertyID dataLiteral ')' | 'annotation(' annotationPropertyID individual ')'

82 OWL – Abstract Syntax: Fakten
fact ::= individual individual ::= 'Individual(' [ individualID ] { annotation } { 'type(' type ')' } { value } ')' value ::= 'value(' individualvaluedPropertyID individualID ')' | 'value(' individualvaluedPropertyID individual ')‚ | 'value(' datavaluedPropertyID dataLiteral ')' type ::= classID | restriction type ::= description (nicht OWL Lite) dataLiteral ::= typedLiteral | plainLiteral typedLiteral ::= lexicalForm^^URIreference plainLiteral ::= lexicalForm | lexicalForm ::= as in RDF, a unicode string in normal form C languageTag ::= as in RDF, an XML language tag fact ::= 'SameIndividual(' individualID individualID {individualID} ')' | 'DifferentIndividuals(' individualID individualID {individualID} ')'

83 OWL – Klassenaxiome in OWL Lite
Klassen sind gleich (modality complete) oder eine Teilklasse (modality partial) von einer Konjunktion von Superklassen und/oder OWL-Lite-Restriktionen. axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { super } ')' modality ::= 'complete' | 'partial' super ::= classID | restriction axiom ::= 'EquivalentClasses(' classID classID { classID } ')' Datentypaxiome sind simpler, sie geben nur an, für welchen Datentyp eine datatypeID steht und können den Datentyp noch mit Annotationen versehen: axiom ::= 'Datatype(' datatypeID ['Deprecated'] { annotation } )'

84 OWL – Restrictions in OWL Lite
Restrictions geben lokale Constraints zu den Properties von Elementen einer Klasse an. Jeder allValuesFrom-Teil einer Restriktion besagt, dass alle Werte der betroffenen Eigenschaft von Individuen der Klasse zu einer bestimmten Klasse bzw. zu einem bestimmten Datentyp gehören müssen Jeder someValuesFrom-Teil einer Restriktion besagt, dass es für jedes Individum unserer Klasse mindestens einen Wert der betroffenen Eigenschaft geben muß, der zur angebenen Klasse oder zum angebenen Datentyp gehört. Der cardinality-Teil gibt an, wieviele verschiedene Werte es für die Property von Individuen unserer Klasse geben darf. In OWL Lite sind nur die Kardinalitäten 0 und 1 erlaubt. restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent ')' | 'restriction(' individualvaluedPropertyID individualRestrictionComponent ')‚ dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')' | 'someValuesFrom(' dataRange ')' | cardinality individualRestrictionComponent ::= 'allValuesFrom(' classID ')‘ | 'someValuesFrom(' classID ')' | cardinality cardinality ::= 'minCardinality(0)' | 'minCardinality(1)' | 'maxCardinality(0)‚ | 'maxCardinality(1)' | 'cardinality(0)' | 'cardinality(1)'

85 OWL – Properties in OWL Lite
Data-valued properties drücken die Beziehung zwischen Individuen und Datenwerte, wie integers, aus. Individual-valued properties drücken die Beziehung zwischen Individuen aus. Properties können Super-Properties haben, dies erlaubt die Konstruktion einer Property-Hierarchie (aber natürlich nicht gemischt zwischen date-valued und individual-valued entlang eines Pfades) Properties können Domains und Ranges haben (zitiert aus OWL Web Ontology Language Semantics and Abstract Syntax): A domain for a property specifies which individuals are potential subjects of statements that have the property as predicate, just as in RDFS. In OWL Lite the domains of properties are classes. There can be multiple domains, in which case only individuals that belong to all of the domains are potential subjects. A range for a property specifies which individuals or data values can be objects of statements that have the property as predicate. Again, there can be multiple ranges, in which case only individuals or data values that belong to all of the ranges are potential objects. In OWL Lite ranges for individual-valued properties are classes; ranges for data-valued properties are datatypes.

86 OWL – Properties in OWL Lite
Data-valued properties can be specified as (partial) functional: given an individual, there can be at most one relationship to a data value for that individual in the property. Individual-valued properties can be specified to be the inverse of another property Individual-valued properties R can also be specified to be symmetric: (a,b) 2 R ! (b,a) 2 R (partial) functional: (a,b) 2 R c, c  b, mit (c,b) 2 R (partial) inverse-functional: (a,b) 2 R c, c  b, mit (a,c) 2 R transitive: (a,b) 2 R, (b,c) 2 R ! (a,c) 2 R

87 OWL – Properties in OWL Lite
To preserve decidability of reasoning in OWL Lite, not all properties can have cardinality restrictions placed on them or be specified as functional or inverse-functional. An individual-valued property is complex if it is specified as being functional or inverse-functional, there is some cardinality restriction that uses it, it has an inverse that is complex, or it has a super-property that is complex. Complex properties cannot be specified as being transitive. Annotation and ontology properties are much simpler than data-valued and individual-valued properties. The only information in axioms for them is annotations.

88 OWL – Properties in OWL Lite
axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation } { 'super(' datavaluedPropertyID ')' } ['Functional'] { 'domain(' classID' ')' } { 'range(' dataRange ')' } ')' | 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation } { 'super(' individualvaluedPropertyID ')' } [ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ] [ 'Functional' | 'InverseFunctional' | 'Functional' 'InverseFunctional' | 'Transitive' ] { 'domain(' classID ')' } { 'range(' classID ')' } ')' | 'AnnotationProperty(' annotationPropertyID { annotation } ')' | 'OntologyProperty(' ontologyPropertyID { annotation } ')' dataRange ::= datatypeID | 'rdfs:Literal'

89 OWL – Properties in OWL Lite
axiom ::= 'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID { datavaluedPropertyID } ')' | 'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')' | 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID { individualvaluedPropertyID } ')‚ | 'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'

90 OWL – Klassenaxiome in OWL DL
axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { description } ')' modality ::= 'complete' | 'partial' In the OWL DL abstract syntax it is also possible to make a class exactly consist of a certain set of individuals, as follows: axiom ::= 'EnumeratedClass(' classID ['Deprecated'] { annotation } { individualID } ')' Collection of descriptions can be forced to be pairwise disjoint, or have the same instances, or that one description is a subclass of another axiom ::= 'DisjointClasses(' description description { description } ')' | 'EquivalentClasses(' description { description } ')' | 'SubClassOf(' description description ')' I axiom ::= 'Datatype(' datatypeID ['Deprecated'] { annotation } )' OWL

91 OWL – Klassenaxiome in OWL DL
The OWL DL abstract syntax has more-general versions of the OWL Lite class axioms where superclasses, more-general restrictions, and boolean combinations of these are allowed. Together, these constructs are called descriptions. axiom ::= 'Class(' classID ['Deprecated'] modality { annotation } { description } ')' modality ::= 'complete' | 'partial' In the OWL DL abstract syntax it is also possible to make a class exactly consist of a certain set of individuals, as follows: axiom ::= 'EnumeratedClass(' classID ['Deprecated'] { annotation } { individualID } ')' Collection of descriptions can be forced to be pairwise disjoint, or have the same instances, or that one description is a subclass of another axiom ::= 'DisjointClasses(' description description { description } ')' | 'EquivalentClasses(' description { description } ')' | 'SubClassOf(' description description ')' I axiom ::= 'Datatype(' datatypeID ['Deprecated'] { annotation } )' OWL

92 OWL –OWL DL Descriptions
Descriptions in the OWL DL abstract syntax include class identifiers and restrictions. Descriptions can also be boolean combinations of other descriptions, and sets of individuals. description ::= classID | restriction | 'unionOf(' { description } ')' | 'intersectionOf(' { description } ')' | 'complementOf(' description ')' | 'oneOf(' { individualID } ')'

93 OWL –OWL DL Restrictions
restriction ::= 'restriction(' datavaluedPropertyID dataRestrictionComponent { dataRestrictionComponent } ')' | 'restriction(' individualvaluedPropertyID individualRestrictionComponent { individualRestrictionComponent } ')‚ dataRestrictionComponent ::= 'allValuesFrom(' dataRange ')' | 'someValuesFrom(' dataRange ')' | 'value(' dataLiteral ')' | cardinality individualRestrictionComponent ::= 'allValuesFrom(' description ')' | 'someValuesFrom(' description ')' | 'value(' individualID ')' | cardinality cardinality ::= 'minCardinality(' non-negative-integer ')' | 'maxCardinality(' non-negative-integer ')' | 'cardinality(' non-negative-integer ')'

94 OWL –OWL DL Restrictions
A data range, used as the range of a data-valued property and in other places in the OWL DL abstract syntax, is either a datatype or a set of data values. dataRange ::= datatypeID | 'rdfs:Literal' | 'oneOf(' { dataLiteral } ')' The OWL Lite limitations on which properties can have cardinality components in their restrictions are also present in OWL DL.

95 OWL –OWL DL Property Axioms
axiom ::= 'DatatypeProperty(' datavaluedPropertyID ['Deprecated'] { annotation } { 'super(' datavaluedPropertyID ')'} ['Functional'] { 'domain(' description ')' } { 'range(' dataRange ')' } ')' | 'ObjectProperty(' individualvaluedPropertyID ['Deprecated'] { annotation } { 'super(' individualvaluedPropertyID ')' } [ 'inverseOf(' individualvaluedPropertyID ')' ] [ 'Symmetric' ] [ 'Functional' | 'InverseFunctional' |'Functional' 'InverseFunctional' | 'Transitive' ] { 'domain(' description ')' } { 'range(' description ')' } ')' | 'AnnotationProperty(' annotationPropertyID { annotation } ')' | 'OntologyProperty(' ontologyPropertyID { annotation } ')' The limitations on which properties can be specified to be functional or inverse-functional are also present in OWL DL.

96 OWL –OWL DL Property Axioms
As in OWL Lite, the following axioms make several properties be equivalent, or make one property be a sub-property of another. axiom ::= 'EquivalentProperties(' datavaluedPropertyID datavaluedPropertyID { datavaluedPropertyID } ')' | 'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')' | 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID { individualvaluedPropertyID } ')' | 'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'

97 OWL Note, however, that both OWL DL and OWL Lite do not provide all of the feature of RDF Schema. OWL Lite and OWL DL closely correspond to the description logics known as SHIF(D) and SHION(D), with some limitation on how datatypes are treated. The abstract syntax for OWL Lite doesn't contain many of the common explicit constructors associated with SHIF(D), but the expressivity remains. The abstract syntax here is less general than the exchange syntax for OWL. (OWL Full) In particular, it does not permit the construction of self-referential syntactic constructs. It is also intended for use in cases where classes, properties, and individuals form disjoint collections. These are roughly the limitations required to make reasoning in OWL be decidable, and thus this abstract syntax should be thought of a syntax for OWL DL

98 OWL – Einige Minibeispiele
<owl:Class rdf:ID="MozartDaPonteOpera"> <owl:equivalentClass> <owl:Class> <owl:oneOf rdf:parseType="Collection"> <Opera rdf:about="#NozzDiFigaro"/> <Opera rdf:about="#DonGiovanni"/> <Opera rdf:about="#CosiFanTutte"/> </owl:oneOf> </owl:Class> </owl:equivalentClass> </owl:Class>

99 OWL – Einige Minibeispiele
Cardinality restrictions Wines can have only a single color subClassOf( Wine Restriction(wineColor cardinality(1))) "subClassOf" means that this is a necessary condition. A wine contains at least one grape type subClassOf(Wine Restriction(madeFromGrape minCardinality(1)))

100 OWL – Einige Minibeispiele
Value restrictions: For all wines, if they have makers, all the makers are wineries. subClassOf(Wine Restriction(hasMaker allValuesFrom(Winery))) For all wines, they have at least one maker that is a winery. subClassOf(Wine Restriction(hasMaker someValuesFrom(Winery)))

101 OWL – Einige Minibeispiele
Property characteristics: transitivity TransitiveProperty(subRegionOf domain(GeographicalRegion) range(GeographicalRegion)) If Tuscany is a subregion of Italy and Montepulciano is a subregion of Tuscany, then Montepulciano is a subregion of Italy. Property characteristics: symmetry SymmetricProperty(adjacentRegion domain(GeographicalRegion) range(GeographicalRegion)) If the region Montalcino is adjacent to the region Montepulciano, the reverse is also true.

102 OWL – Einige Minibeispiele
Necessary and sufficient conditions Having a red color is a neessary and sufficient feature to be called a red wine. equivalentClass(RedWine intersectionOf( Wine Restriction(wineColor hasValue("red")))) Note: "equivalentClass" means that this is a necessary and sufficient condition. Note: "intersectionOf" represents an "AND" condition

103 OWL – Einige Minibeispiele
(In)Equality of individuals No closed-world assumption in OWL! Used for ontology/vocabulary mapping Ontology A: Individual(Brunello, type(vin:Wine)) Ontology B: Individual(BrunelloDiMontalcino type(vin:Wine)) sameAs(A:Brunello B:BrunelloDiMontalcino)

104 OWL – Einige Minibeispiele
Enumerated classes Defining a class by enumerating its instances: Class(FamousTuscanWine oneOf( BrunelloDiMontalcino VineNobileDiMontepuciano))

105 OWL – Einige Minibeispiele
What didn't make it into OWL? Qualified Cardinality Restrictions: "A minimal Italian dinner contains three courses of which one is an antipasto." Class(MinimalItalianDinner, subclassOf( Restriction( onProperty(hasCourse) cardinality(3))) subclassOf( QualifiedRestriction( onProperty(hasCourse) valuesFrom(Antipaso) cardinality(1)))) Das gibt es nicht in OWL!

106 Minizusammenfassung Is OWL just another knowledge-representation language? Key differences: All classes/properties/individuals have a URI as identifier RDF/XML exchange syntax enables interoperability Open-world assumption, no unique-name assumption For the rest: OWL DL is state-of-the-art concept language Semantic-layering solution was/is "research" [(zitiert nach Guus Schreiber, OWL: the Web Ontology Language]


Herunterladen ppt "Intelligente Systeme C"

Ähnliche Präsentationen


Google-Anzeigen