SMART Systems (Vorlesung: KI & XPS) zBeim vorigen Mal: yRDFS, Vertiefung der Anwendung der DL ALCQHI R+ yKonkrete Domänen, Lineare Constraints über reellen Zahlen zInhalt heute: yXML-Schema, DAML ySchließen mit verschiedenen Ontologien zLernziele: yVerstehen von praktischen Internet-Modellierungssprachen yVerstehen der logischen Grundlagen (im DL-Kontext) Ralf Möller, Univ. of Applied Sciences, FH-Wedel

Vertiefung: Informationsintegration zDatenmodellierungsschemata nicht konform zStichwort: Interoperabilität zAbleitung von Ontologien aus UML/ER-Modellen zInter-Schema-Axiome zTaxonomie bestimmen zVerwendung der Taxonomie zur Anfrageberechnung und Anfrageverteilung

Inter-Schema-Axiome: Beispiel 1 zAxiome aus EER-Modell1 (DB1):

Inter-Schema-Axiome: Beispiel 1 zAxiome aus EER-Modell (DB2) zInterschema-Aussagen

Inter-Schema-Axiome: Beispiel 2 zAxiome aus EER-Modell (DB3): zAnnahme: has_cargo_storage sei transitiv zWoher kommen Schema-Informationen in der Praxis? -> RDFS, XML-Schema, DAML+OIL

Wiederholung RDF / RDFS zNachteile von XML yVielfache Repräsentationsmöglichkeiten für die „gleiche Sache“ yKeine Graphstrukturen über Dokument hinaus (eingeschränkte Verwendung von IDREF) zRDF ySPO-Darstellung yRessourcenidee, URIs statt IDREFs yRDFS-Dokument ≈ Tbox yRDF-Dokument ≈ Abox

XML-Schemata I: Bewertung von DTDs zZur Erinnerung: DTDs definieren kontextfreie Grammatiken yRekursive Definitionen sind möglich ]> ]> DTD zDTDs weisen bei der Definition eines Schemas jedoch einige Schwächen auf: yUngewollte Festlegung der Reihenfolge: xWorkaround: yKann teilweise zu vage werden: yReferenzen können nicht eingeschränkt (typisiert) werden yAlle Elementnamen sind global in einem Namensraum

XML-Schemata II: XML-Schema zEchter Schemamechanismus mit vielen Erweiterungen über DTDs hinaus zBenutzt selbst wieder XML-Syntax zur Schemadefinition XML-Schema... ]>... ]> DTD 1:1-Abbildung (bis auf author)

XML-Schema: Elemente zSyntax: zOptionale Zusatzattribute: yTyp xtype = “Typ“atomarer, einfacher oder komplexer Typname yKardinalitäten (Vorgabe [1,1]): xminOccurs = “x“x  { 0, 1, n } xmaxOccurs = “y“y  { 1, n, unbounded } yWertvorgaben (schließen sich gegenseitig aus!): xdefault = “v“veränderliche Vorgabe xfixed = “u“unveränderliche Vorgabe zBeispiele: y

XML-Schema: Attribute zSyntax: zOptionale Zusatzattribute: yTyp: xtype = “Typ“ yExistenz: xuse = “optional“Kardinalität [0,1] xuse = “required“Kardinalität [1,1] yVorgabewerte: xuse = “default“ value = “v“veränderliche Vorgabe xuse = “fixed“ value = “u“unveränderliche Vorgabe zBeispiele: y

XML-Schema: Typen zIn XML-Schema wird zwischen atomaren, einfachen und komplexen Typen unterschieden zAtomare Typen: yEingebaute Elementartypen wie int oder string zEinfache Typen: yHaben weder eingebettete Elemente noch Attribute yIn der Regel von atomaren Typen abgeleitet zKomplexe Typen: yDürfen Elemente und Attribute besitzen zZusätzlich kann man noch folgende Unterscheidung treffen: yReine Typdefinitionen beschreiben (wiederverwendbare) Typstruktur yDokumentdefinitionen beschreiben welche Elemente wie im Dokument auftauchen dürfen

XML-Schema: Atomare Typen zXML-Schema unterstützt eine große Menge eingebauter Basistypen (>40): yNumerisch: byte, short, int, long, float, double, decimal, binary, … yZeitangaben: time, date, month, year, timeDuration, timePeriod, … ySonstige: string, boolean, uriReference, ID, … zBeispiele:

XML-Schema: Einfache Typen zZusätzlich können von bestehenden Typen noch weitere, sog. einfache Typen, abgeleitet werden: yTypdefinition: yDokumentdefinition: zSolche einfachen Typen dürfen jedoch keine verschachtelten Elemente enthalten! zIn ähnlicher Weise können Listen definiert werden: yTypdefinition: (Name eines Autors als mit Leerzeichen getrennte Liste von Zeichenketten) yDokumentdefiniton:

XML-Schema: Komplexe Typen zKomplexe Typen dürfen im Gegensatz zu einfachen Typen eingebettete Elemente und Attribute besitzen zBeispiel: yTypdefinition: zGruppierungs-Bezeichner: y … Feste Reihenfolge (a,b) y … Beliebige Reihenfolge (a,b oder b,a) y … Auswahl (entweder a oder b)

XML-Schema: Komplexe Typen <element name=“firstname“ type=“string“ minOccurs=“0“ maxOccurs=“unbounded“/>

Typhierarchien zGesetzmäßigkeit zwischen zwei Typen zTypdefinition durch yErweiterung (engl. extension) oder yRestriktion (engl. restriction) einer bestehenden Typdefinition zAlle Typen in XML-Schema sind entweder yAtomare Typen (z.B. string) oder yErweiterung bzw. Restriktion bestehender Typen zAlle Typen bilden eine Typhierarchie yBaum mit Wurzel: Typ Zeichenkette yKeine Mehrfachvererbung zTypen sind entlang der Typhierarchie abwärtskompatibel: yFür Typinstanzen gilt das Substituierbarkeitsprinzip yElemente eines bestimmten Typs akzeptieren auch Daten einer Erweiterung oder Restriktion des geforderten Typs

zTypen können konstruktiv um weitere Elemente oder Attribute zu neuen Typen erweitert werden zBeispiel: zErweitert den zuvor definierten Typ authorType um yEin optionales Element yEin optionales Attribut homepage Typhierarchien: Erweiterung von Typen

zDie Erweiterungen werden an die bestehenden Definitionen angehängt: Typhierarchien: Erweiterung von Typen (2)

Typhierarchien: Restriktion von Typen zTypen werden durch Verschärfung von Zusatzangaben bei Typdefinitionen in ihrer Wertemenge eingeschränkt zBeispiele für Restriktionen: yBisher nicht angebene type-, default- oder fixed-Attribute yVerschärfung der Kardinalitäten minOccurs, maxOccurs zSubstituierbarkeit yMenge der Instanzen des eingeschränkten Untertyps muß immer eine Teilmenge des Obertyps sein! zRestriktion komplexer Typen yStruktur bleibt gleich: es dürfen keine Elemente oder Attribute weggelassen werden zRestriktion einfacher Typen yRestriktion ist (im Gegensatz zur Erweiterung) auch bei einfachen Typen erlaubt

Typhierarchien: Restriktion von Typen (2) zBeispiel (Komplexer Typ): Gegenüber dem ursprünglichen Typ wurde die Anzahl der Vornamen (firstname) auf 2 begrenzt und das Altersattribut (age) erzwungen Vorher: maxOccurs=“unbounded“ Vorher: use=“optional“

Bewertung von XML-Schema zSyntax und Ausdruckskraft von XML-Schema sind sehr umfangreich zFormale Fundierung durch Beschreibungslogiken zum Teil möglich (problematisch: Defaults -> kommt später) zWeiteres Merkmal: Konsistenzbedinungen (z.B. Schlüssel, Fremdschlüssel): hier nicht im Fokus zMehr zu XML-Schema im Web: yhttp:// yhttp:// I: Strukturen yhttp:// II: Datentypen

DAML - Darpa Agent Markup Language zRapides Anwachsen der Informationen im Web zÜbersteigt menschliche Fähigkeit, Datenmengen in Informationen zu verarbeiten y  Relationen in maschinenlesbarer Weise darstellen zEinsatz von Webagenten y  DARPA Agent Markup Language y (offizieller Beginn: August 2000 in den USA) yZusammenschluß mit europäischen Entwicklungen DAML+OIL

Verwendung von Ontologien im Agentenkontext zGegeben in Form von Tboxen: yBasis-Ontologie I, Basis-Ontologie II yÜbersetzungsaxiome: BasisOnto I zu BasisOnto II yAnwendungsontologie I (Vokabular Agent I) mit Bezug auf Basis-Ontologie I yAnwendungsontologie II (Vokabular Agent II) mit Bezug auf Basis-Ontologie II zKlassifikation der Gesamt-Tbox ergibt Beziehungen von Konzeptnamen aus BasisOntoI und BasisOntoII

DAML-Beispiel (1) DAML-ONT ist in RDF geschrieben, das selber in XML codiert ist und XML – NS verwendet. <rdf:RDF xmlns:rdf =" xmlns =" xmlns:daml =" Zunächst werden 3 Namensräume definiert Unpräfigierte Elementnamen beziehen sich auf die Standard-Ontologie von DAML, alternativ versehen mit daml-Präfix Rdf-Präfix mit Verweis auf Standard-Definition für RDF

DAML-Beispiel (2) Nun wird erklärt, wie eine spezielle Ontologie definiert wird. $Id: myontologie.daml, vers. 1.2 An Beispiel ontology „leere“ Assertion

DAML-Beispiel (3) Definitionen von Klassen und Eigenschaften in DAML. Human The class is illustrative of ontological idioms Mit ID kann die Klasse Human extern über URI und #Human referenziert werden Male ist Unterklasse von Human

DAML-Beispiel (4) Mit dem disjointFrom-Tag können ähnlich wie in Konzeptsprachen Disjunktheitsklassen definiert werden. 2 Eigenschaft ist eine binäre Relation Der Definitionsbereich ist Human und es gibt genau 2 Eltern Klasse „Female“

DAML-Beispiel (5) Einschränkung von Relationen: Werte- und Existenzrestriktionen Der Bildbereich der Relation Parent wird für Personen auf Personen eingeschränkt Existenzrestriktion: hasClass statt toClass

DAML-Beispiel (6) Subrelationen 1 Vater wird als Subrelation von Eltern eingeführt, wobei es immer nur einen Vater gibt Notationsvariante für Relationen mit Kardinalität 1

DAML-Beispiel (7) Vererbung und Konjunktion Konjunktion von Klassen Elemente wie oneOf oder disjointUnionOf werden mit „daml:collection“ geparst

DAML-Beispiel (8) Verschiedene Relationstypen -weiterhin gibt es noch andere Relationstypen: -Bsp.: Transitive Relation... Inverse Relation

DAML-Beispiel (9) Synonyme, Kardinalitätsbereich und Komplement 1 Der Kardinalitätsbereich für Beruf ist 0 oder 1 Synonym für Mother complementOf-Tag bildet anonyme Klasse – Komplementmenge aller Personen

DAML-Beispiel (10) Definition einer Instanz von Person … Instanz von Person Eine Person hat eine bestimmte Größe (Eigenschaft) Größe wird durch eine extensional definierte Menge spezifiziert ist

Extensionale Beschreibungen: One-of (1)

Extensionale Beschreibungen: One-of (2)

DAML-Beispiel (11) Durch Wertrestriktion neue Klassen spezifizieren Spezifizieren einer neuen Klasse

DAML-Beispiel (12) Durchschnittsbildung spezifiziert neue Klassen aus bereits vorhandenen Durchschnittsbildung von Klasse „TallThing“ und der Klasse „Man“ Abschluß der Ontologie- Definition über RDF

DAML – Fazit: zDie Repräsentationssprache DAML+OIL ist eine syntaktische Variante von ALCQHIR+ mit einer speziellen Erweiterung: den sogenannten Extensionalen Beschreibungen zEine spezielle Ontologie heißt DAML-S und beschreibt „Dienste“. Wir kommen darauf zurück. zDAML ist weiterhin eine Sammlung von Tools zum Umgang mit Ontologien.

Zusammenfassung, Kernpunkte zXML, XML-Schema zDAML zAgenten können in Kontext eintreten und Ontologie-Informationen verarbeiten (RDFS, XML-Schema oder DAML), in dem eine DL- Inferenzmaschine verwendet wird zDetailliertere Beispiele kommen etwas später zMögliche Studien- und Diplomarbeiten

Was kommt beim nächsten Mal? zInter-Schema-Schließen zweiter Teil zGrundlagen von Schlußalgorithmen für das Abox-Konsistenzproblem