Motivation des Semantic Web

(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

(2)

Semantic Web Frank Puppe 2

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

(3)

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)

(4)

Agenten

Autonome proaktive Software im Web

•

basiert auf Meta- daten, Ontologien und Logik

•

erfordert zusätzlich Agenten-Kommuni- kationssprachen und Modellierung interner Zustände

•

kommuniziert mit Menschen

(5)

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)

(6)

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's bzw. 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)

(7)

XML - Baumdarstellung

<email>

<head>

<subject> Where is your draft </subject>

</head>

<body> Grigoris, where is the draft of the paper you promised me last week

</body>

</email>

(8)

Definition einer DTD

Formulierung der Terminale:

Elemente: <!ELEMENT Name Wert>

Name: nur Buchstaben, Ziffern und "." "-" "_" sind erlaubt;

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 Elementes Attributliste: Name Typ Bedeutung

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

<!entity "kuerzel" system "Verweis">

(9)

(nachname, vorname)

(10)

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

(11)

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

(12)

Beispiel-Dokument für Anfragen

(13)

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

(14)

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

(15)

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)

(16)

Beispiel für XSLT

<xsl:template match="author">

</name>

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

</institute>

</email>

</contact>

</xsl:template>

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

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

</authors> </xsl:template>

<xsl:template match="authors">

<xsl:apply-templates

select="author"/>

</author>

</xsl:template>

(17)

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> Discrete Mathematics </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

(18)

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

(19)

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)

(20)

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

(21)

Bsp.: Graphbasierte Syntax von RDF

(22)

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

(23)

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

(24)

Bewertung von RDF

9 Relativ starke Ausdrucksmächtigkeit

9 Benutzerfreundliche Editierwerkzeuge

9 Eindeutige 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

(25)

RDF - XML-Syntax mehr Beispiele (1)

•

Dokumentanfang: Definition der Namespaces

•

Description: about: eigentlich sollten sich Identifier auf externen Namespace

(26)

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>

(27)

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,

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:li gekennzeichnet.

(28)

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)

(29)

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 staff member

admin

staff member academic staff member

tech support staff member

professor associate

professor

assistant professor

(30)

Property-Hierarchien

• ähnlich wie Klassenhierarchien gibt es auch Property- Hierarchien

–

Supproperties gelten immer, wenn die übergeordnete

Property gilt, aber nicht umgekehrt.

(31)

• ^RDF-Schema

erlaubt die Definition von Klassen und Properties, während in

RDF Instanzen dazu definiert werden.

• Typüberprü- fungen bei range und domain

RDF und RDF-Schema

(32)

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

(33)

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=

(34)

Beispiel RDF Schema: Universität (1)

(35)

Beispiel RDF Schema: Universität (2)

(36)

Beispiel RDF Schema: Universität (3)

(37)

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]

(38)

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

(39)

Probleme

mit XPATH-

basierten

Anfragen

(40)

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 involves vorkommt, einschl. der Unterproperites (isTaughtBy).

(41)

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}

(42)

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)

(43)

Anfragen an RDF Schema

• RQL erlaubt auch, Schema-Informationen abzufragen:

–

Schemavariablen sind durch Prefix gekennzeichnet

• $ für Klassen

• @ für Properties

(44)

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, $Y

from {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

(45)

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)

(46)

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

(47)

Anforderungen an Ontologie-Sprachen:

• Wohl-definierte Syntax

• Formale Semantik (erlauben nützliche Inferenzen)

• Effiziente Inferenz-Unterstützung

• Ausreichende Ausdrucksmächtigkeit

• Benutzerfreundlichkeit

(48)

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

(49)

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

(50)

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

(51)

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

(52)

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

(53)

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

(54)

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

Motivation des Semantic Web