Motivation des Semantic Web - ki.informatik.uni-wuerzburg.deki.informatik.uni-wuerzburg.de/teach/ws-2004-2005/wms/documents/WMS... · Semantic Web Frank Puppe 1 Motivation des Semantic

Semantic Web Frank Puppe 1

Motivation des Semantic Web

• Web ist für Nutzung durch Menschen konzipiert– auch automatisch generierter Inhalt wird ohne interne Struktur

präsentiert– Werkzeugunterstützung: Stichwortbasierte Suchmaschinen

• Schwächen stichwortbasierter Suchmaschinen– Hoher recall, niedrige precision– niedriger oder kein recall– Ergebnisse abhängig vom Vokabular– Ergebnisse sind einzelne Web-Seiten

• Idee: Automatische Verarbeitung des Web-Inhaltes ermöglichen– Semantic Web Initiative des W3C– Graduelle Verbesserung des bisherigen Webs


Beispiele für Semantic Web

• Wissensmanagement– notwendig besonders für große verteilte Organisationen

• B2C Electronic Commerce (Business to Customer)– Einkaufsagenten, die zu einem Produkt, Preise, ggf.

Alternativen und Reputation der Firma erkennen und ggf. verhandeln können

• B2B Electronic Commerce (Business to Business)– Datenaustausch bisher mit speziellen Format: EDI (Electronic

Data Interchange). – Verbesserung XML, aber erfordert Apriori-Vereinbarung

• Persönliche Agenten– Stellvertreter für Informationssuche und ggf. Vereinbarungen


Technologien des Semantic Web• Explizite Repräsentation von Metadaten• Ontologien: wichtige Wissensrepräsentationssprachen

– XML: Syntax, aber keine Festlegung von Semantik– XML Schema: Präzisere Dokumentenbeschreibung– RDF: Datenmodel für Objekte und ihre Beziehungen mit

einer einfachen Semantik– RDF Schema: Beschreibung seines Vokabulars als

Klassen mit Eigenschaften und Vererbung– OWL: Reichere Vokabularbeschreibungssprache, z.B.

• Beziehungen zwischen Klassen (z.B. Diskjunktion)• Kardinalität (z.B. genau ein)• Gleichheit• Reichere Typisierung von Eigenschaften (z.B. Symmetrie) • Aufzählungsklassen

• Logik: Herleiten von Schlussfolgerungen


Agenten

Autonome proaktiveSoftware im Web• basiert auf Meta-

daten, Ontologien und Logik

• erfordert zusätzlich Agenten-Kommuni-kationssprachenund Modellierung interner Zustände

• kommuniziert mit Menschen


Inkrementeller Mehrebenen-Ansatz

• Konflikt zwischen Standardisierung und Innovation• Mehrebenenansatz erfordert

– Abwärtskompatibilität (höhere Ebene beinhalten niedrigere)– partielles Verständnis höherer Ebenen (Ein Agent einer Ebene kann auch

auch Elemente höherer Ebenen verstehen, sofern sie in seine Sprachebene übersetzbar sind)


XML

• Ermöglicht im Gegensatz zu HTML die Definition eigener Tags (Elemente) und Attribute

• Baum-Modell von XML-Dokumenten: Übersichtliche Darstellung als Baum

• Definition der Tags mit DTD (Document Type Definition) oder mit XML-Schema (ausdrucksstärkere Sprache)

• Namensräume erlauben Kombination verschiedener DTD'sbzw. Schemas

• XML-Abfragesprachen basieren auf Pfad-Ausdrücken (XPATH)• XML-Verarbeitung (z.B. Anzeige als HTML oder Umwandlung

in anderes XML-Dokument) in deklarativer Form mit Style-sheets (XSLT; extensible stylesheet language transformations)


XML - Baumdarstellung<email>

<head><from name = "Michael Maher" address = "[email protected]"/><to name = "Grigoris Antoniou" address = "[email protected]"/><subject> Where is your draft </subject>

</head><body> Grigoris, where is the draft of the

paper you promised me last week</body>

</email>


Definition einer DTDFormulierung der Terminale:Elemente: <!ELEMENT Name Wert>

Name: nur Buchstaben, Ziffern und "." "-" "_" sind erlaubt; Groß- / Kleinschreibung relevant; darf nicht mit "xml" beginnen

Wert: (#PCDATA) | ANY | EMPTY | Elemente | (#PCDATA | Elemente)*>Formulierung der Regeln für Elemente (a, b, c, … = Elemente):

- Gruppierung: (a b) oder (a b c)- Alternative: a | b oder a | b | c- Sequenz: a, b oder a, b ,c- Wiederholung 0 .. n: a *- Wiederholung 1 .. n: a +- Wiederholung 0 .. 1: a ?

Attribute: <!ATTLIST Elementname Attributliste>Elementname: Name eines definierten ElementesAttributliste: Name Typ BedeutungTyp: CDATA | ID | IDREF | IDREFS | Entity | … | ( (Name | Name | … )* )Bedeutung: #IMPLIED | #REQUIRED | Name | #FIXED Name

Entitäten: <!entity "kuerzel" "Ersetzungstext"> |<!entity "kuerzel" system "Verweis">


(nachname, vorname)


Mächtigere Alternative: XML-Schema

• Syntax in XML (Einfachere technische Handhabung)• Erweiterbarkeit: Ein XML-Schema kann ein anderes erweitern• Differenzierte Datentypen

– Numerisch (int, Float, …); String; Zeit (Date, …); Zusammengesetzte Typen (sequence, all, choice); Typerweiterung; Typeinschränkung

• Definition von Tags (Elementen): Neu: Typen + Kardinalitäten


XML-Anfragesprachen

• Beispiele: XQL, XML-QL, XQuery, …• Basieren auf Pfad-Ausdrücken, d.h. XPATH

– absolute Pfade: Start mit Wurzel-Knoten– relative Pfade zu einem Kontext-Knoten


Beispiel-Dokument für Anfragen


Beispiele für XML-Anfragen in XPATH

• /library/author: liefert alle author-Elemente• //author: liefert alle author-Elemente, die irgendwo im

Dokument vorkommen (ggf. mehr als obige Anfrage)• /library/@location: liefert alle entsprechenden Attribut-Knoten• //book/@title="Artificial Intelligence": liefert alle Attribut-Knoten,

bei denen der Titel den angegeben Wert hat.• //book[@title="Artificial Intelligence"]: liefert alle Buch-Knoten,

die die Bedingung in eckigen Klammern erfüllen• //author[1]: liefert den ersten author-Knoten• //author[1]/book[last()]: liefert den letzten Buch-Knoten vom

ersten Autor• //book[not @title]: liefert alle Buchknoten ohne Titel-Attribut


Allgemeine Struktur von Pfad-Ausdrücken

• Pfad-Ausdruck besteht aus einer Folge von Schritten.• Schritt besteht aus

– Pfadelement (axis): Vom Kontext-Knoten zum aktuellen Knoten, z.B. //, / = child, parent, sibling, attribute

– Knotentest (node test), z.B. Element-Namen; * = alle Knoten;– optionalem Filter-Ausdruck (predicate or filter expression)

• Beispiel: /library/author[1]: 2 Schritte:/ = child (Pfad); library = Knotentest; / = child (Pfad); author = Knotentest; [1] = Filterausdruck


Verarbeitung

• Kernideen– Umwandlung eines XML-Ausdruck in einen anderen

(XHTML oder anderes XML) mittels Stylesheets• Anwendung von Ersetzungsregeln für bestimmte Knoten

– Zugriff aus Programmiersprache mittels sprachspezifischem Parser (z.B. Xerces für Java)

• Umwandlung in Baum• Zugriff auf Knoten in Baumstruktur mittels API (z.B. XPATH-API)• Spezielle Funktionen für Knotenbearbeitung (z.B. Inhaltsextraktion)


Beispiel für XSLT<xsl:template match="author">

<name><xsl:value-of select="name"/></name>

<contact><institute>

<xsl:value-of select="affiliation"/></institute><email> <xsl:value-of select="email">

</email></contact></xsl:template>

<xsl:template match="/"> <authors><xsl:apply-templates select="authors"/></authors> </xsl:template>

<xsl:template match="authors"><author>

<xsl:apply-templatesselect="author"/>

</author></xsl:template>


Probleme mit XML (1)

• Mit XML kann man Tags definieren, aber keine Semantik• Beispiel:

– Inhalt: David Billington is a lecturer of Discrete Mathematics– Repräsentation in XML

• <course name="Discrete Mathematics"> <lecturer> David Billington </lecturer> </course>

• <lecturer name= "David Billington"> <teaches> DiscreteMathematics </teaches> </lecturer>

• <teachingOffering> <lecturer> David Billington </lecturer> <course> Discrete Mathematics </course> </teachingOffering>

– Beispiele enthalten teilweise genau umgekehrte Einrückung– Es gibt keine Standardmethode, um aus

Elementeinrückung Bedeutung zu extrahieren• Verbesserung: RDF und RDFS


Probleme mit XML (2)

• XML-Beispiel:<academicStaffMenber> Grigoris Antoniou </academicStaffMenber> <professor> Michael Maher </professor><course name="Discrete Mathematics"> <isTaughtBy> David Billington

</ isTaughtBy > </course>

• Anfrage (XPATH)://academicStaffMember– Ergebnis: nur "Grigoris Antoniou"– unbefriedigend, da für Menschen klar ist, dass auch Michael Maher und

David Billington zum Ergebnis gehören.

• Notwendige Regeln:– Professoren sind academicStaffMember (subclass)– Kurse werden nur von academicStaffMember gelehrt

(range-Beschränkung der property <isTaughtBy>)


RDF und RDF Schema

• unglückliche Namenswahl, da es an XML und XML Schema erinnert

• Unterschied: – während XML Schema die Struktur (z.B. die erlaubte

Schachtelungstiefe) von XML-Dokumenten vorgibt,– gibt RDF Schema das Vokabular von RDF-Dokumenten vor

(deren Struktur ist dagegen in RDF festgelegt)


Grundlagen von RDF• Das Kernkonzept von RDF ist das Statement:

– Objekt-Attribut-Wert Tripel– in RDF: Resource-property-Value– Bsp.:

• resource: David Billington• property: site-owner• value: http://www.cit.gu.edu.au/~db

– 3 Sichten auf ein Statement• Tripel: (x P y) oder P(x,y)• Graph-basiert (semantisches Netz; s. rechts oben & nächste Folie)• XML-Repräsentation (s. übernächste Folie)

• Resource: Gegenstand der Betrachtung; hat URI bzw. URL• Property: Spezielle Resource, die Relationen zwischen

Resourcen beschreibt: hat auch URI bzw. URL• Value: entweder eine Resource oder ein String

www.cit.gu.edu.au/~db

David Billington

site-owner


Bsp.: Graphbasierte Syntax von RDF


XML Syntax von RDF• Festlegung von Namespaces (Präfixe rdf, mydomain)• rdf:description Statement macht Aussage über die Resource

http://www,cit.gu.edu.au/~db• Property wird in XML als Tag dargestellt• Value ist der Inhalt des Tags


Datentypen und Reification

• Datentypen: alle Datentypen des XML-Schema erlaubt.• Reification: In RDF sind statements über statements erlaubt.

– z.B.: Grigoris glaubt, dass David Billington der Autor der Web-Site http://www,cit.gu.edu.au/~db ist

– Technische Realisierung: man kann ein URI einem Statement zuweisen

• Nur Tripel, d.h. binäre Properties, erlaubt– Quadrupel müssen durch Hilfsobjekt mit 3 Relationen

(Properties) dargestellt werden.– Bsp.: Umsetzung u.a. für Reification

• Grigoris believes Belief1• Belief1 subject David Billington• Belief1 predicate Autor• Belief1 object http://www,cit.gu.edu.au/~db


Bewertung von RDF

Relativ starke AusdrucksmächtigkeitBenutzerfreundliche EditierwerkzeugeEindeutige Identifier

- Reduktion von Aussagen auf binäre Relationen umständlich- Properties (Relationen) sind spezielle Resourcen, d.h. können

wie Objekte behandelt werden: ungewöhnlich für Modellierungs- bzw. Logik-Sprachen

- Reifikation-Mechanismus entspricht Logik höherer Ordnung und erscheint für eine so einfache Sprache wie RDF zu weit gegriffen.

- XML-Syntax von RDF ist maschinenlesbar, aber nicht leser-freundlich für Menschen


RDF - XML-Syntax mehr Beispiele (1)

• Dokumentanfang: Definition der Namespaces• Description: about: eigentlich sollten sich Identifier auf externen Namespace

beziehen (z.B. www.mydomain.org/uni-ns/#949352)• Mehrere Aussagen zu einem Objekt möglich• Typ-Angabe bei Datentypen in jeder Instanz erforderlich


RDF - XML-Syntax mehr Beispiele (2)• Value der Property "isTaughtBy" = David Billington ist mehrdeutig, daher Nutzung

des rdf:resource Attributes: <uni:isTaughtBy rdf:resource="#949318">• Analog, wenn zusätzliche Eigenschaften von David Billington definiert werden

<rdf:Description rdf:ID=#949318"> <uni:Email> …</uni:Email> <rdf:Description>


Container und Collections in RDF• Container-Elemente eignen sich dazu,

in einem Statement eine Menge von Resourcen zu definieren, z.B. alle Dozenten oder alle Studenten eines bestimmten Kurses.

• Drei Typen von Containern:– rdf:Bag: ungeordneter Container mit

potentiell mehrfachem Auftreten eines Elementes

– rdf:Seq: geordneter Container mit potentiell mehrfachem Auftreten eines Elementes

– rdf:Alt: eine Menge von Alternativen (von denen nur eine zutrifft)

• Collections eignen sich für geschlossene Mengen, die besagen, dass es keine weiteren Elemente außer den genannten gibt.

Beispiel:<uni-lecturer rdf:about="949353"

uni:name="Grigoris Antoniou"uni:title="Professor"

<uni:coursesTaught><rdf:Bag><rdf:_1 rdf:resource="CIT1112"/><rdf:_2 rdf:resource="CIT3116"/></rdf:Bag></uni:coursesTaught>

</uni-lecturer>

Der Inhalt der Container-Elemente wird mit rdf_1, rdf_2, …durchnummeriert oder mit rdf:ligekennzeichnet.


Grundlagen von RDF Schema

• Sprache zur Definition von eigenem Vokabular zur Beschreibung von Resourcen.

• Definition von Klassen und Eigenschaften mit RDF Schema– RDF beschreibt dazu Instanzen– Klassen vererben Eigenschaften– Typisierung verhindert sinnlose Statements, z.B.

• Discrete Mathematics is taught by Concrete Mathematics– Kurse müssen durch Dozenten gelehrt werden (range)

• Room MZH5760 is taught by David Billington– Nur Kurse können gelehrt werden (domain)


Klassenhierachien• Klassenhierarchien werden mit "subclass" aufgebaut• Bsp.:

• Auch multiple Vererbung erlaubt• Vererbung sehr nützlich für range-Beschränkungen:

– Kurse müssen durch Dozenten (academic staff members) gelehrt werden (range)

– Gilt automatisch auch für Professor als subclass von Dozent• Properties sind (im Unterschied zu OOP) global definiert, nicht

klassenspezifisch

staff member

adminstaff member

academic staff member

tech supportstaff member

professor associateprofessor

assistantprofessor


Property-Hierarchien

• ähnlich wie Klassenhierarchien gibt es auch Property-Hierarchien

– Supproperties gelten immer, wenn die übergeordnete Property gilt, aber nicht umgekehrt.


• RDF-Schemaerlaubt die Definition von Klassen und Properties, während in RDF Instanzen dazu definiert werden.

• Typüberprü-fungen bei range und domainmöglich

RDF und RDF-Schema


RDF Schema: Syntax

• Definitionen der Sprache RDF Schema sind in der Syntax von RDF geschrieben (ähnlich wie XML Schema in XML)

• Bsp.: Generische Definition von lecturer als subclass von academicStaffMember würde erfordern:

– Resourcen lecturer, subclass, academicStaffMember definieren– subclass als property definieren– Das Tripel (lecturer, subclassof, academicStaffMember) schreiben


Modellierungsprimitive von RDF Schema

• Kernklassen – rdfs:Resource, rdfs:Class, rdfs:Literal, rdf:Property,

rdf:Statement– Bsp.:<rdfs:Class rdf:ID="lecturer"> … </rdfs:Class>

• Kernklassen zur Definition von Beziehungen – rdf:type (Instanzierung), rdfs: subClassOf (Vererbung), rdfs:

subPropertyOf– Bsp.: <rdfs:Class rdf:about "lecturer"> <rdfs:subClassOf rdf:resource

="staffMember"/> </rdfs:Class>

• KernProperties zur Beschränkung von Properties– rdfs:domain (Urbild-Beschränkung), rdfs:range (Bild-Beschränkung)– Bsp.: <rdf:Property rdf:ID=phone"> <rdfs:domain rdf:resource=

"#staffMember"/> <rdfs:range rdf:resource="&rdf;Literal"/> </rdf:Property>


Beispiel RDF Schema: Universität (1)






Inferenz-System für RDF und RDFS

• Basiert auf einigen Dutzend Regeln der Art:– Wenn E bestimmte Tripel enthält,

dann addiere zu E bestimmte weitere Tripel

• Beispiele für Regeln:– Wenn (?x, ?p, ?y) ∈ E, dann auch (?p, rdf:type, rdf:property) ∈ E– Wenn (?u, rdfs:subClassOf, ?v) ∈ E und (?v, rdfs:subClassOf, ?w) ∈ E

dann auch (?u, rdfs:subClassOf, ?w) ∈ E [Transitivität von subClassOf]– Wenn (?x, rdf:type, ?u) ∈ E und (?u, rdfs:subClassOf, ?v) ∈ E

dann auch (?x, rdf:type, ?v) ∈ E [Instanz-Transitivität von type & subClassOf]

– Wenn (?x, ?p, ?y) ∈ E und (?p, rdfs:range, ?u) ∈ E dann auch (?y, rdf:type, ?u) ∈ E [resource ?y, die als value von ?p notiert ist, muss vom Type von range (p) sein, d.h. von ?u]


Anfragesprachen für RDF

• XML-Anfragesprachen basierend auf Xpath möglich, aber ungünstig, s. nächste Folie

• Eine angemessene Anfragesprache sollte das Datenmodell von RDF und die Semantik des Vokabulars sowie die Semantik von RDF Schema kennen.

• Bisher keine Standardisierung, ca. 20 Anfragesprachen• Beispiel: RDQ als Vertreter der zentralen Ideen jeder

vernünftigen Anfragesprache


Probleme mit XPATH-basiertenAnfragen


Grundlegende Anfragen in RQL

• Um alle Instanzen einer Klasse zu erhalten, reicht es die Klasse abzufragen

– Bsp.: course: liefert alle Instanzen der Klasse course und ihrer Unterklassen; ^course lässt die Unterklassen weg.

• Um die Resourcen und Value eines Tripels mit einer speziel-len Property zu erhalten, reicht es die Property abzufragen

– Bsp.: involves: liefert alle Tripel, in denen die Property involvesvorkommt, einschl. der Unterproperites (isTaughtBy).


RQL: Select-From-Where (1)• Analog zu SQL bedeutet:

– select: gibt die Anzahl und Reihenfolge der zurückgelieferten Daten– from: dient zur Navigation durch das Datenmodell– where: beschränkt mögliche Lösungen zur Anfrage

• Beispiel-1:– Alle Telefonnummern der StaffMember

select X, Y from {X} phone {Y}

– X und Y sind Variablen – {X} phone {Y} repräsentiert ein Tripel resource-property-value

• Beispiel-2:– Alle Telefonnummern der Lecturer

select X, Y from lecturer{X} .phone {Y}

– lecturer{X} umfasst alle Instanzen von Lecturer– . bezeichnet impliziten Join


RQL: Select-From-Where (2)

• Beispiel-3:– Namen aller Kurse die vom Lecturer mit der ID 949352 gelehrt werden

select N from course{X} .isTaughtBy {Y}, {C} name {N}where Y="949352" and X=C

– in from-Teil impliziter und expliziter Join

• Außer "=" existieren auch andere Vergleichsoperator– z.B. X<Y bedeutet X niedriger als Y (als Zahl, String oder Unterklasse)


Anfragen an RDF Schema

• RQL erlaubt auch, Schema-Informationen abzufragen:– Schemavariablen sind durch Prefix gekennzeichnet

• $ für Klassen• @ für Properties


Beispiele für RDF-Schema-Abfragen• Beispiel1: Abfrage aller Instanzen und ihrer Klassen

(Resourcen) sowie der Subklassen mit property "phone"– Anfrage:

select X, $X, Y, $Yfrom {X:$X} phone {Y:$Y}

– Daten:phone ("949352","5041")type ("949352",lecturer)subclass (lecturer, staffMember)domain (phone, staffMember)range (phone, literal)

– Ergebnis:("949352", lecturer, "5041", literal)

• Beispiel2: Anfrage zu domain und range einer Property• select domain (@P), range (@P)• from @P• where @P= phone


Zusammenfassung RDF(S)

• Audrucksmächtikeit von RDF– binäre Grundprädikate– Instanzierung von Klassen

• Ausdrucksmächtigkeit von RDFS – Bildung von Hierarchien über Klassen und Properties– Definition von Range und Domain von Properties (Relationen)


Web Ontologie Sprache OWL

• Notwendig wegen Beschränkungen von RDF(S)• Vorläufer: Beschreibungslogik (Description logic) seit Mitte der

80'iger Jahre (erster Vertreter: KL-ONE)– US-Vorschlag: DAML-ONT– Europäischer Vorschlag: OIL– Kombination: DAML-OIL– Weiterentwicklung durch W3C Web Ontology Working

Group zu OWL: als Standard vorgeschlagen


Anforderungen an Ontologie-Sprachen:

• Wohl-definierte Syntax• Formale Semantik (erlauben nützliche Inferenzen)• Effiziente Inferenz-Unterstützung• Ausreichende Ausdrucksmächtigkeit• Benutzerfreundlichkeit


Nützliche Inferenzen für Ontologien

• Klassenzugehörigkeit (über Instanzen und Subklassen)• Äquivalenz von Klassen (z.B. Transitivität)• Konsistenz (z.B. darf x nicht Instanz disjunkter Klassen sein)• Klassifikation (Wenn eine Klasse A bestimmte Merkmale hat

und eine Instanz x bzw. eine andere Klasse B hat diese Merkmale, dann ist x eine Instanz von A bzw. B eine Unterklasse von A)

• Inferenz-Unterstützung erlaubt– die Konsistenz einer (verteilten) Ontologie zu überprüfen– unbeabsichtige Beziehungen zwischen Klassen zu finden– automatische Klassifikation von Instanzen


Begrenzungen der Ausdrucksmächtigkeit von RDFS

• Lokale Wirkung von Eigenschaften (rdfs:range wirkt global)– keine Möglichkeit, den Wertebereich einer Property bei verschiedenen

Klasen verschieden zu definieren, z.B. eine Property "frisst" kann nicht bei der Klasse "Kühe" den Wert "vegetarisch" haben aber bei "Löwen" "fleischfressend".

• Disjunktheit von Klassen– Bsp.: es gibt keine Möglichkeit, die Disjunktheit der Klassen "männlich"

und "weiblich" auszudrücken• Boolsche Kombination von Klassen

– keine Möglichkeit, eine neue Klasse aus der Kombination vorhandener Klassen zu definieren, z.B. eine Klasse "Person" aus der und-Verknüpfung von "männlich" und "weiblich"

• Kardinalitätsbeschränkungen– keine Möglichkeit auszudrücken, wieviele verschiedene Werte eine Pro-

perty haben darf oder muss, z.B. dass eine Person genau 2 Eltern hat.• Spezielle Merkmale von Properties

– Bsp.: Def. einer Property als transitive (größerAls), unique (mutterVon) oder als inverse zu einer anderen Property (frisst / wirdGefressenDurch)


Drei Varianten von OWL

• OWL Full: Umfasst alle Sprachkonstrukte zur Erweiterung der Beschränkungen (s. letzte Folie) von RDFS.

– Volle Kompabilität mit RDFS– Sehr mächtige Konstrukte: z.B. kann man die Bedeutung vordefinierter

Sprachprimitive ändern (geht auch in RDF) oder Kardinalitäts-beschränkungen auf die Klasse aller Klassen setzen (Beschränkung, wieviele Klassen in einer Ontologie definierbar sind)

– zu mächtig für umfassende Inferenzunterstützung (unentscheidbar)

• OWL DL (Description Logic): Beschränkung der Sprachkonstrukte– keine volle Kompatibiliät mit RDF– Anwendung von Sprachkonstrukten aufeinander nicht erlaubt

• OWL Lite: Noch stärkere Beschränkung der Sprachkonstrukte– z.B. keine Disjunkheit (auch keine Aufzählung mit oneOf), keine

beliebige Kardinalität


OWL Syntax• Verschiedene Alternativen (ähnlich wie bei RDF)

– basiert auf RDF Syntax (primäre Syntax, aber schwer lesbar)

– XML-basierte Syntax– Abstrakte Syntax– Graphische Syntax auf der Basis von UML (weit verbreitet)

• Einfaches Beispiel von OWL in RDF-Syntax<owl:Class rdf:ID="associateProfessor"><rdfs:subClassOf rdf:resource:"#academicStaffMember"

</owl:Class>

<owl:Class rdf:about="#associateProfessor"><owl:disjointWith rdf:resource="#professor"/><owl:disjointWith rdf:resource="#assistantProfessor"/>

<owl:Class>


OWL-Konstrukte

• Property-Unterscheidung bezüglich Objekten und Datentypen• Klassenelemente: class, disjointWith, equivalentClass• Property-Einschränkungen

– allValuesFrom: Alle Werte einer Klasse (∀)– someValuesFrom: Mindestens ein Wert einer Klasse (∃)– hasValue: Ein bestimmter Wert – minCardinality, maxCardinality: Kardinalitätsbeschränkung

• Spezielle Properties– transitiveProperty, symmetricProperty, funktionalProperty (hat genau

einen Wert), inverseFunctionalProperty (ist eindeutig)• Boolsche Kombinationen: union, intersection, complementOf• Aufzählungen: oneOf• Instanzen: differentFrom, allDifferent (Namensungleichheit reicht nicht)• Datentypen: Einschränkung der Datentypen aus XML-Schema


Genauere Sicht auf Varianten von OWL

• OWL Full: Alles erlaubt

• OWL DL: – Einschränkungen bei Vokabular (z.B. eine Klasse kann nicht

gleichzeitig eine Instanz sein)– explizite "Typ"-Angaben für alle Resourcen– keine transitiven Kardinalitätsbeschränkungen– beschränkte Nutzung anonymer Klassen

• OWL Lite:– folgende Konstruktoren nicht erlaubt: oneOf, disjointWith, unionOf,

complementOf, hasValue– Kardinalitätsbeschränkungen nur mit 0 und 1– equivalentClass nicht zwischen anonymen Klassen


Diskutierte Erweiterungen zu OWL• Modularisierung von Ontologien: bisher kann man eine Ontologie nur

ganz oder gar nicht importieren• Defaults: Vererbte Werte dürfen in Unterklassen bisher nicht

überschrieben werden– Problem: Defaults erfordern nicht-monotones Schließen

• Closed-World Assumption: bisher kann man aus dem Fehlschlag eines Beweises auf nichts schließen.

– Problem: CWA erfordert nicht monotones Schließen• Unique-Names Assumption: Bisher können 2 Individueen mit

verschiedenen Namen als identisch hergeleitet werden• Zugeordnete Prozeduren: Bisher: Bedeutung eines Termes nur durch

explizite Sprachdefinitionen, nicht durch Ausführung von Programmcode– Problem: Definition einer formalen Semantik

• Integration von Regeln für Properties

Aktives Forschungsgebiet

Documents

Motivation des Semantic Web - ki.informatik.uni-wuerzburg.deki.informatik.uni-wuerzburg.de/teach/ws-2004-2005/wms/documents/WMS... · Semantic Web Frank Puppe 1 Motivation des Semantic