View
214
Download
0
Category
Preview:
Citation preview
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
Recommended