Upload
hannelore-welp
View
106
Download
1
Tags:
Embed Size (px)
Citation preview
Intelligente Systeme C
Semantic Web und Wissensrepräsentation
Prof. Dr. Wolfram Conen
WS04/05, FH Gelsenkirchen
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
Ü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
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!
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.
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!
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
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.
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
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.
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“)
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.
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)
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)
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
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
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
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
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)
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
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
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]
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 Schwefelein Metal ist, dann können Schweine fliegen“
Ist dieser Satz „wahr“ oder „falsch“? (mit den Vorgaben von oben)
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.
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
0 0 1 0 0 1 1 0
0 1 1 0 1 1 0 1
1 0 0 0 1 0 0 1
1 1 0 1 1 1 1 0!, $ 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)
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
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?
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
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)
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...
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)
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)
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!
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“!
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))
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)
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)))
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
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
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]
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?
Prolog, einige Aspekte
Folgende Aufgabe: 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
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).
Prolog, einige Aspekte
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
Prolog, einige Aspekte 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
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?)
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)
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).
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,Y). pfad(X,Y) :- kante(X,Z), kante(Z,Y). 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!
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
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
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
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...
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.
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!
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. fak(0,1).
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).
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 =< 2000. % 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.
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.
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
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([],M,M). union([E|T],M,V) :- member(E,M), !,
union(T,M,V). 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
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.
OWL/RDF und das Semantic Web
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
RDF Graph
[http://www.w3.org/TR/rdf-syntax-grammar http://purl.org/dc/elements/1.1/title "RDF/XML Syntax Specification (Revised)„]
[_:genid1 http://example.org/stuff/1.0/fullName "Dave Beckett„] [_:genid1 http://example.org/stuff/1.0/homePage http://purl.org/net/dajobe/] [http://www.w3.org/TR/rdf-syntax-grammar http://example.org/stuff/1.0/editor :genid1]
RDF Graph
Darstellung als N-Triple: <http://www.w3.org/TR/rdf-syntax-grammar> <http://purl.org/dc/elements/1.1/title>
"RDF/XML Syntax Specification (Revised)" . :genid1 <http://example.org/stuff/1.0/fullName> "Dave Beckett" . :genid1 <http://example.org/stuff/1.0/homePage> <http://purl.org/net/dajobe/> . <http://www.w3.org/TR/rdf-syntax-grammar> <http://example.org/stuff/1.0/editor> :genid1 .
RDF Graph Darstellung als N-Triple: <http://www.w3.org/TR/rdf-syntax-grammar> <http://purl.org/dc/elements/1.1/title>
"RDF/XML Syntax Specification (Revised)" . _:genid1 <http://example.org/stuff/1.0/fullName> "Dave Beckett" . _:genid1 <http://example.org/stuff/1.0/homePage> <http://purl.org/net/dajobe/> . <http://www.w3.org/TR/rdf-syntax-grammar> <http://example.org/stuff/1.0/editor>
_:genid1 .
RDF/XML-Syntax (eine Variante...mehr finden sie in der RDF/XML Syntax Specification):
<?xml version="1.0"?> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/„xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar„ 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="http://purl.org/net/dajobe/"/>
</rdf:Description> </rdf:RDF>
RDF Listen Listen mit expliziten Element-Nummer-Properties: <?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Seq rdf:about="http://example.org/favourite-fruit">
<rdf:_1 rdf:resource="http://example.org/banana"/> <rdf:_2 rdf:resource="http://example.org/apple"/><rdf:_3 rdf:resource="http://example.org/pear"/>
</rdf:Seq> </rdf:RDF> Listen mit rdf:li Properties: <?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <rdf:Seq rdf:about="http://example.org/favourite-fruit">
<rdf:li rdf:resource="http://example.org/banana"/> <rdf:li rdf:resource="http://example.org/apple"/> <rdf:li rdf:resource="http://example.org/pear"/>
</rdf:Seq> </rdf:RDF> Beide haben die gleiche n-Triple-Repräsentation: <http://example.org/favourite-fruit> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq> . <http://example.org/favourite-fruit> <http://www.w3.org/1999/02/22-rdf-syntax-ns#_1>
<http://example.org/banana> . <http://example.org/favourite-fruit> <http://www.w3.org/1999/02/22-rdf-syntax-ns#_2>
<http://example.org/apple> . <http://example.org/favourite-fruit> <http://www.w3.org/1999/02/22-rdf-syntax-ns#_3>
<http://example.org/pear> .
RDF Collections Eine Liste, die als Collection angegeben wird: <?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#„ xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://example.org/basket"> <ex:hasFruit rdf:parseType="Collection"> <rdf:Description rdf:about="http://example.org/banana"/> <rdf:Description rdf:about="http://example.org/apple"/> <rdf:Description rdf:about="http://example.org/pear"/> </ex:hasFruit></rdf:Description>
</rdf:RDF>
Als N-Triple: :genid1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <http://example.org/banana> .
:genid2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <http://example.org/apple> .:genid1 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> _:genid2 .:genid3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> <http://example.org/pear> .:genid2 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> _:genid3 . _:genid3 <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest>
<http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> . <http://example.org/basket> <http://example.org/stuff/1.0/hasFruit> _:genid1 .
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)
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]
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...
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
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
OWL Varianten
OWL – Abstract Syntax
Namen sind RDF URI-Referenzen. Verwendete Abkürzungen (Namespaces):
Namespace Name
Namespace
rdf http://www.w3.org/1999/02/22-rdf-syntax-ns#
rdfs http ://www.w3.org/2000/01/rdf-schema#
xsd http ://www.w3.org/2001/XMLSchema#
owl http ://www.w3.org/2002/07/owl#
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.
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.
OWL – Abstract Syntax datatypeID ::= URIreference
classID ::= URIreference individualID ::= URIreference ontologyID ::= URIreference datavaluedPropertyID ::= URIreferenceindividualvaluedPropertyID ::= 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.
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
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 ')'
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@languageTaglexicalForm ::= as in RDF, a unicode string in normal form ClanguageTag ::= as in RDF, an XML language tag
fact ::= 'SameIndividual(' individualID individualID {individualID} ')'
| 'DifferentIndividuals(' individualID individualID {individualID} ')'
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 } )'
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)'
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.
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
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 1. it is specified as being functional or inverse-functional, 2. there is some cardinality restriction that uses it, 3. it has an inverse that is complex, or 4. 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.
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'
OWL – Properties in OWL Lite
axiom ::= 'EquivalentProperties(' datavaluedPropertyIDdatavaluedPropertyID { datavaluedPropertyID } ')'
| 'SubPropertyOf(' datavaluedPropertyID datavaluedPropertyID ')'
| 'EquivalentProperties(' individualvaluedPropertyID individualvaluedPropertyID { individualvaluedPropertyID } ')‚
| 'SubPropertyOf(' individualvaluedPropertyID individualvaluedPropertyID ')'
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 } )' 2.3.2.2. OWL
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 } )' 2.3.2.2. OWL
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 } ')'
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 ')'
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.
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.
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(' individualvaluedPropertyIDindividualvaluedPropertyID ')'
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
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>
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)))
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)))
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.
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
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)
OWL – Einige Minibeispiele Enumerated classes
Defining a class by enumerating its instances:
Class(FamousTuscanWine oneOf(
BrunelloDiMontalcino VineNobileDiMontepuciano))
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!
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]