XML-Schema, DAML/OWL, Schließen mit verschiedenen Ontologien

(1)

SMART Systems (Vorlesung: KI & XPS)

 Beim vorigen Mal:

 RDFS, Vertiefung der Anwendung der DL ALCQHI

R+

 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

(2)

Vertiefung: Informationsintegration

 Datenmodellierungsschemata nicht konform

 Stichwort: Interoperabilität

 Ableitung von Ontologien aus UML/ER-Modellen

 Inter-Schema-Axiome

 Taxonomie bestimmen

 Verwendung der Taxonomie zur

Anfrageberechnung

und Anfrageverteilung

(3)

Inter-Schema-Axiome: Beispiel 1

 Axiome aus EER-Modell1 (DB1):

(4)

Inter-Schema-Axiome: Beispiel 1

 Axiome aus EER-Modell (DB2)

 Interschema-Aussagen

(5)

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

(6)

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

(7)

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)>

]>

<!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

(8)

XML-Schemata II: XML-Schema

 Echter Schemamechanismus mit vielen Erweiterungen über DTDs hinaus

 Benutzt selbst wieder XML-Syntax zur Schemadefinition

<element name=“author” type=“authorType”

maxOccurs=“unbounded”/>

</sequence>

</complexType>

</element>

</complexType>

</element>

</schema>

<element name=“author” type=“authorType”

maxOccurs=“unbounded”/>

</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)>

...

]>

<!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)

(9)

XML-Schema: Elemente

 Syntax:

 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”/>

(10)

XML-Schema: Attribute

 Syntax:

 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”/>

(11)

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

(12)

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“/>

(13)

XML-Schema: Einfache Typen

 Zusätzlich können von bestehenden Typen noch weitere, sog. einfache Typen, abgeleitet werden:

 Typdefinition:

 Dokumentdefinition:

 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:

(14)

XML-Schema: Komplexe Typen

 Komplexe Typen dürfen im Gegensatz zu einfachen Typen eingebettete Elemente und Attribute besitzen

 Beispiel:

 Typdefinition:

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

maxOccurs=“unbounded“/>

</sequence>

</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)

(15)

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>

(16)

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

(17)

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

 Beispiel:

<element name=“email“ type=“string“ minOccurs=“0“

maxOccurs=“1“/>

</sequence>

</extension>

</complexType>

 Erweitert den zuvor definierten Typ authorType um

 Ein optionales Element email

 Ein optionales Attribut homepage

Typhierarchien: Erweiterung von Typen

(18)

 Die Erweiterungen werden an die bestehenden Definitionen angehängt:

<element name=“email“ type=“string“ minOccurs=“0“

maxOccurs=“1“/>

</sequence>

</complexType>

Typhierarchien: Erweiterung von Typen (2)

</sequence>

</complexType>

(19)

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

(20)

Typhierarchien: Restriktion von Typen (2)

 Beispiel (Komplexer Typ):

maxOccurs=“2“/>

</sequence>

</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“

(21)

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

(22)

DAML - Darpa Agent Markup Language

 Rapides Anwachsen der Informationen im Web

 Übersteigt menschliche Fähigkeit, Datenmengen in Informationen zu verarbeiten

  Relationen in maschinenlesbarer Weise darstellen

 Einsatz von Webagenten

  DARPA Agent Markup Language

 (offizieller Beginn: August 2000 in den USA)

 Zusammenschluß mit europäischen Entwicklungen

DAML+OIL

(23)

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 II

 Klassifikation der Gesamt-Tbox ergibt

Beziehungen von Konzeptnamen aus BasisOntoI

und BasisOntoII

(24)

DAML-Beispiel (1)

DAML-ONT ist in RDF geschrieben, das

selber 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

(25)

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

(26)

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

(27)

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“

(28)

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

(29)

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

(30)

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

(31)

DAML-Beispiel (8)

Verschiedene Relationstypen

<Property ID="child">

<inverseOf resource="#parent"/>

</Property>

- weiterhin gibt es noch andere Relationstypen:

- Bsp.: Transitive Relation ...

Inverse Relation

(32)

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

(33)

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

(34)

Extensionale Beschreibungen: One-of (1)

(35)

Extensionale Beschreibungen: One-of (2)

(36)

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

(37)

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

(38)

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.

(39)