SMART Systems (Vorlesung: KI & XPS) zBeim vorigen Mal: yRDFS, Vertiefung der Anwendung der DL...

SMART Systems (Vorlesung: KI & XPS)

Beim vorigen Mal: RDFS, Vertiefung der Anwendung der DL ALCQHIR+ Konkrete Domänen, Lineare Constraints über reellen Zahlen

Inhalt heute: XML-Schema, DAML Schließen mit verschiedenen Ontologien

Lernziele: Verstehen von praktischen Internet-Modellierungssprachen Verstehen der logischen Grundlagen (im DL-Kontext)

Ralf Möller, Univ. of Applied Sciences, FH-Wedel

Vertiefung: Informationsintegration

Datenmodellierungsschemata nicht konform Stichwort: Interoperabilität Ableitung von Ontologien aus UML/ER-Modellen Inter-Schema-Axiome Taxonomie bestimmen Verwendung der

Taxonomie zurAnfrageberechnungund Anfrageverteilung

Inter-Schema-Axiome: Beispiel 1

Axiome aus EER-Modell1 (DB1):

Inter-Schema-Axiome: Beispiel 1

Axiome aus EER-Modell (DB2)

Interschema-Aussagen

Inter-Schema-Axiome: Beispiel 2

Axiome aus EER-Modell (DB3):Annahme: has_cargo_storage sei transitiv

Woher kommen Schema-Informationen in der Praxis? -> RDFS, XML-Schema, DAML+OIL

Wiederholung RDF / RDFS

Nachteile von XML Vielfache Repräsentationsmöglichkeiten für die

„gleiche Sache“ Keine Graphstrukturen über Dokument hinaus

(eingeschränkte Verwendung von IDREF)RDF

SPO-Darstellung Ressourcenidee, URIs statt IDREFs RDFS-Dokument ≈ Tbox RDF-Dokument ≈ Abox

XML-Schemata I: Bewertung von DTDs

Zur Erinnerung: DTDs definieren kontextfreie Grammatiken Rekursive Definitionen sind

möglich

<!DOCTYPE paper [<!ELEMENT paper (section*)><!ELEMENT section ((title, section*)|text)><!ELEMENT title (#PCDATA)><!ELEMENT text (#PCDATA)>

]> DTD DTDs weisen bei der Definition eines Schemas jedoch

einige Schwächen auf: Ungewollte Festlegung der Reihenfolge:

<!ELEMENT person ( name, phone ) > Workaround: <!ELEMENT person ( (name, phone ) | ( phone, name ) ) >

Kann teilweise zu vage werden: <!ELEMENT person ( ( name | phone | email )* ) >

Referenzen können nicht eingeschränkt (typisiert) werden Alle Elementnamen sind global in einem Namensraum

XML-Schemata II: XML-Schema Echter Schemamechanismus mit vielen Erweiterungen über

DTDs hinaus Benutzt selbst wieder XML-Syntax zur Schemadefinition

<schema> <element name=“bib”> <complexType> <element name=“paper” minOccurs=“0” maxOccurs=“unbounded”> <complexType> <attribute name=“id” type=“ID” use=“required”/> <sequence> <element name=“author” type=“authorType” maxOccurs=“unbounded”/> <element name=“year” type=“string”/> <element name=“publisher” type=“string” minOccurs=“0”/> </sequence> </complexType> </element> </complexType> </element></schema> XML-Schema

<!DOCTYPE bib [<!ELEMENT bib (paper*)><!ELEMENT paper (author+, year, publisher?)><!ATTLIST paper id ID #REQUIRED><!ELEMENT author (firstname*, lastname)><!ATTLIST author age CDATA #IMPLIED><!ELEMENT firstname (#PCDATA)><!ELEMENT lastname (#PCDATA)><!ELEMENT year (#PCDATA)>

<!ELEMENT publisher (#PCDATA)>...

]> DTD

1:1-Abbildung(bis auf author)

XML-Schema: Elemente Syntax:

<element name=“Name“/> Optionale Zusatzattribute:

Typ type = “Typ“ atomarer, einfacher oder komplexer Typname

Kardinalitäten (Vorgabe [1,1]): minOccurs = “x“ x { 0, 1, n } maxOccurs = “y“ y { 1, n, unbounded }

Wertvorgaben (schließen sich gegenseitig aus!): default = “v“ veränderliche Vorgabe fixed = “u“ unveränderliche Vorgabe

Beispiele: <element name=“bib”/> <element name=“paper” minOccurs=“0” maxOccurs=“unbounded”/> <element name=“publisher” type=“string” minOccurs=“0”/>

XML-Schema: Attribute Syntax:

<attribute name=“Name“/> Optionale Zusatzattribute:

Typ: type = “Typ“

Existenz: use = “optional“ Kardinalität [0,1] use = “required“ Kardinalität [1,1]

Vorgabewerte: use = “default“ value = “v“ veränderliche Vorgabe use = “fixed“ value = “u“ unveränderliche Vorgabe

Beispiele: <attribute name=“id” type=“ID” use=“required”/> <attribute name=“age” type=“string” use=“optional”/> <attribute name=“language” type=“string” use=“default”

value=“de”/>

XML-Schema: Typen In XML-Schema wird zwischen atomaren, einfachen und

komplexen Typen unterschieden Atomare Typen:

Eingebaute Elementartypen wie int oder string Einfache Typen:

Haben weder eingebettete Elemente noch Attribute In der Regel von atomaren Typen abgeleitet

Komplexe Typen: Dürfen Elemente und Attribute besitzen

Zusätzlich kann man noch folgende Unterscheidung treffen: Reine Typdefinitionen beschreiben (wiederverwendbare)

Typstruktur Dokumentdefinitionen beschreiben welche Elemente wie im

Dokument auftauchen dürfen

XML-Schema: Atomare Typen

XML-Schema unterstützt eine große Menge eingebauter Basistypen (>40): Numerisch: byte, short, int, long, float, double, decimal,

binary, … Zeitangaben: time, date, month, year, timeDuration,

timePeriod, … Sonstige: string, boolean, uriReference, ID, …

Beispiele:<element name=“year“ type=“year“/><element name=“pages“ type=“positiveInteger“/><attribute name=“age“ type=“unsignedShort“/>

XML-Schema: Einfache Typen Zusätzlich können von bestehenden Typen noch weitere, sog.

einfache Typen, abgeleitet werden: Typdefinition:

<simpleType name=“humanAge“ base=“unsignedShort“><maxInclusive value=“200“/> </simpleType>

Dokumentdefinition:<attribute name=“age“ type=“humanAge“/>

Solche einfachen Typen dürfen jedoch keine verschachtelten Elemente enthalten!

In ähnlicher Weise können Listen definiert werden: Typdefinition:

<simpleType name=“authorType“ base=“string“derivedBy=“list“/>

(Name eines Autors als mit Leerzeichen getrennte Liste von Zeichenketten) Dokumentdefiniton:

<element name=“author“ type=“authorType“/>

XML-Schema: Komplexe Typen Komplexe Typen dürfen im Gegensatz zu einfachen Typen

eingebettete Elemente und Attribute besitzen Beispiel:

Typdefinition:<complexType name=“authorType“><sequence><element name=“firstname“ type=“string“ minOccurs=“0“maxOccurs=“unbounded“/><element name=“lastname“ type=“string“/></sequence><attribute name=“age” type=“string” use=“optional”/> </complexType>

Gruppierungs-Bezeichner: <sequence> … </sequence> Feste Reihenfolge (a,b) <all> … </all> Beliebige Reihenfolge (a,b oder b,a) <choice> … </choice> Auswahl (entweder a oder b)

XML-Schema: Komplexe Typen

<complexType name=“authorType“><sequence>

<element name=“firstname“ type=“string“minOccurs=“0“maxOccurs=“unbounded“/>

<element name=“lastname“ type=“string“/></sequence><attribute name=“age” type=“string” use=“optional”/>

</complexType>

Typhierarchien

Gesetzmäßigkeit zwischen zwei Typen Typdefinition durch

Erweiterung (engl. extension) oder Restriktion (engl. restriction) einer bestehenden Typdefinition

Alle Typen in XML-Schema sind entweder Atomare Typen (z.B. string) oder Erweiterung bzw. Restriktion bestehender Typen

Alle Typen bilden eine Typhierarchie Baum mit Wurzel: Typ Zeichenkette Keine Mehrfachvererbung

Typen sind entlang der Typhierarchie abwärtskompatibel: Für Typinstanzen gilt das Substituierbarkeitsprinzip Elemente eines bestimmten Typs akzeptieren auch Daten einer

Erweiterung oder Restriktion des geforderten Typs

Typen können konstruktiv um weitere Elemente oder Attribute zu neuen Typen erweitert werden

Beispiel:<complexType name=“extendedAuthorType“>

<extension base=“authorType“><sequence>

<element name=“email“ type=“string“ minOccurs=“0“maxOccurs=“1“/>

</sequence><attribute name=“homepage” type=“string” use=“optional”/>

</extension></complexType>

Erweitert den zuvor definierten Typ authorType um Ein optionales Element email Ein optionales Attribut homepage

Typhierarchien: Erweiterung von Typen

Die Erweiterungen werden an die bestehenden Definitionen angehängt:<complexType name=“extendedAuthorType“>

<sequence><element name=“firstname“ type=“string“ minOccurs=“0“

maxOccurs=“unbounded“/><element name=“lastname“ type=“string“/><element name=“email“ type=“string“ minOccurs=“0“

maxOccurs=“1“/> </sequence><attribute name=“age” type=“string” use=“optional”/><attribute name=“homepage” type=“string” use=“optional”/>

</complexType>

Typhierarchien: Erweiterung von Typen (2)

<complexType name=“authorType“><sequence><element name=“firstname“ type=“string“ minOccurs=“0“maxOccurs=“unbounded“/><element name=“lastname“ type=“string“/></sequence><attribute name=“age” type=“string” use=“optional”/> </complexType>

Typhierarchien: Restriktion von Typen

Typen werden durch Verschärfung von Zusatzangaben bei Typdefinitionen in ihrer Wertemenge eingeschränkt

Beispiele für Restriktionen: Bisher nicht angebene type-, default- oder fixed-Attribute Verschärfung der Kardinalitäten minOccurs, maxOccurs

Substituierbarkeit Menge der Instanzen des eingeschränkten Untertyps muß immer

eine Teilmenge des Obertyps sein! Restriktion komplexer Typen

Struktur bleibt gleich: es dürfen keine Elemente oder Attribute weggelassen werden

Restriktion einfacher Typen Restriktion ist (im Gegensatz zur Erweiterung) auch bei einfachen

Typen erlaubt

Typhierarchien: Restriktion von Typen (2) Beispiel (Komplexer Typ):

<complexType name=“restrictedAuthorType“><restriction base=“authorType“>

<sequence><element name=“firstname“ type=“string“ minOccurs=“0“

maxOccurs=“2“/><element name=“lastname“ type=“string“/>

</sequence><attribute name=“age” type=“string” use=“required”/>

</restriction> </complexType>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

Syntax und Ausdruckskraft von XML-Schema sind sehr umfangreich

Formale Fundierung durch Beschreibungslogiken zum Teil möglich (problematisch: Defaults -> kommt später)

Weiteres Merkmal: Konsistenzbedinungen (z.B. Schlüssel, Fremdschlüssel): hier nicht im Fokus

Mehr zu XML-Schema im Web: http://www.w3.org/TR/xmlschema-0/ Einführung http://www.w3.org/TR/xmlschema-1/ Teil I: Strukturen http://www.w3.org/TR/xmlschema-2/ Teil II: Datentypen

DAML - Darpa Agent Markup Language

Rapides Anwachsen der Informationen im WebÜbersteigt menschliche Fähigkeit,

Datenmengen in Informationen zu verarbeiten Relationen in maschinenlesbarer Weise

darstellenEinsatz von Webagenten

DARPA Agent Markup Language (offizieller Beginn: August 2000 in den USA) Zusammenschluß mit europäischen Entwicklungen

DAML+OIL

Verwendung von Ontologien im Agentenkontext

Gegeben in Form von Tboxen: Basis-Ontologie I, Basis-Ontologie II Übersetzungsaxiome: BasisOnto I zu BasisOnto II Anwendungsontologie I (Vokabular Agent I) mit

Bezug auf Basis-Ontologie I Anwendungsontologie II (Vokabular Agent II) mit

Bezug auf Basis-Ontologie IIKlassifikation der Gesamt-Tbox ergibt

Beziehungen von Konzeptnamen aus BasisOntoI und BasisOntoII

DAML-Beispiel (1)

DAML-ONT ist in RDF geschrieben, dasselber in XML codiert ist und XML – NS verwendet.

<rdf:RDF xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"

xmlns ="http://www.daml.org/2000/10/daml-ont#"

xmlns:daml ="http://www.daml.org/2000/10/daml-ont#">

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.

<Ontology about="">

<versionInfo> $Id: myontologie.daml, vers. 1.2</versionInfo>

<comment>An Beispiel ontology</comment> <imports resource="http://www.daml.org/2000/10/daml-

ont"/>

</Ontology>

„leere“ Assertion

DAML-Beispiel (3)

Definitionen von Klassen und Eigenschaften in DAML.

<Class ID=“Human">

<label>Human</label> <comment>The class is illustrative of ontological

idioms</comment> </Class>

<Class ID="Male"> <subClassOf resource="#Human"/> </Class>

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.

<Class ID="Female"> <subClassOf resource="#Human"/> <disjointFrom resource="#Male"/> </Class>

<Property ID="parent"> <domain resource="#Human"/> <cardinality>2</cardinality> </Property>

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

<Class ID="Person"> <subClassOf resource="#Human"/> <restrictedBy> <Restriction> <onProperty resource="#parent"/> <toClass resource="#Person"/> </Restriction> </restrictedBy> </Class>

Der Bildbereich der Relation Parent wird für Personen auf Personen eingeschränkt

Existenzrestriktion:hasClass statt toClass

DAML-Beispiel (6)

Subrelationen

<Property ID="father"> <subProperty resource="#parent"/> <range resource="#Man"/> <cardinality>1</cardinality> </Property>

<UniqueProperty ID="mother"> <subProperty resource="#parent"/> <range resource="#Woman"/> </UniqueProperty>

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<Class ID="Man"> <subClassOf resource="#Person"/> <subClassOf resource="#Male"/> </Class>

<Class about="#Person"> <disjointUnionOf parseType="daml:collection"> <Class about="#Man"/> <Class about="#Woman"/> </disjointUnionOf> </Class>

Konjunktion von Klassen

Elemente wie oneOf oder disjointUnionOf werden mit „daml:collection“ geparst

DAML-Beispiel (8)

Verschiedene Relationstypen

<Property ID="child"> <inverseOf resource="#parent"/> </Property>

- weiterhin gibt es noch andere Relationstypen:- Bsp.: Transitive Relation...

Inverse Relation

DAML-Beispiel (9)Synonyme, Kardinalitätsbereich und Komplement

<Property ID="mom"> <equivalentTo resource="#mother"/> </Property>

<Property ID=”profession"> <maxCardinality>1</maxCardinality> </Property>

<Class ID=“Animal"> <subClassOf><Class> <complementOf resource="#Person"/> </Class></subClassOf> </Class>

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

<Person ID="Adam">…</Person> <Property ID="height"> <domain resource="#Person"/> <range resource="#Height"/> </Property>

<Class ID="Height"> <oneOf parseType="daml:collection"> <Height ID="short"/> <Height ID="medium"/> <Height ID="tall"/> </oneOf> </Class>

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

<Class ID="TallThing"> <restrictedBy> <Restriction> <onProperty resource="#height"/> <toValue resource="#tall"/> </Restriction> </restrictedBy> </Class>

Spezifizieren einer neuen Klasse

DAML-Beispiel (12)

Durchschnittsbildung spezifiziert neue Klassen aus bereits vorhandenen

<Class ID="TallMan"> <intersectionOf parseType="daml:collection"> <Class about="#TallThing"/> <Class about="#Man"/> </intersectionOf> </Class></rdf:rdf>

Durchschnittsbildung von Klasse „TallThing“ und der Klasse „Man“

Abschluß der Ontologie-Definition über RDF

DAML – Fazit:

Die Repräsentationssprache DAML+OIL ist eine syntaktische Variante von ALCQHIR+ mit einer speziellen Erweiterung: den sogenannten Extensionalen Beschreibungen

Eine spezielle Ontologie heißt DAML-S und beschreibt „Dienste“. Wir kommen darauf zurück.

DAML ist weiterhin eine Sammlung von Tools zum Umgang mit Ontologien.

Zusammenfassung, Kernpunkte

XML, XML-SchemaDAMLAgenten können in Kontext eintreten und

Ontologie-Informationen verarbeiten (RDFS, XML-Schema oder DAML), in dem eine DL-Inferenzmaschine verwendet wird

Detailliertere Beispiele kommen etwas späterMögliche Studien- und Diplomarbeiten

Was kommt beim nächsten Mal?

Inter-Schema-Schließen zweiter TeilGrundlagen von Schlußalgorithmen für das

Abox-Konsistenzproblem