Web Ontology Language (OWL) und Anfragesprachen Michael Fellmann - - PowerPoint PPT Presentation
Formal Explicit explicit shared Ontology Inference domain Conceptualization conceptualization TBox/ABox Restriction semantics Shared formal Triple Pattern menatal model Web Ontology Language (OWL) und Anfragesprachen Michael
conceptualization shared semantics formal menatal model explicit domain
Michael Fellmann
Institut für Informationsmanagement und Unternehmensführung michael.fellmann@uos.de
Conceptualization Formal Ontology Restriction Shared
Triple Pattern
Explicit
TBox/ABox
Inference
Michael Fellmann
2
Michael Fellmann
3
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
4
Motivation zur semantischen Beschreibung
OWL > Motivation
Beispiel DB Netz AG – was ist ein „Gleis“?
Eine Ontologie erlaubt die Erfassung der verschiedenen Bedeutungsinhalte sowie die Auflösung von Synonymen und Homonymen (und weiteren „Defekten“)
Quelle: Schmidt, A.; Otto, B.; Österle, H. (2010): Unternehmensweite Stammdatenintegration. In: WuM 5/2010, S. 47
Michael Fellmann
5
Motivation zur semantischen Beschreibung
OWL > Motivation
Beispiel Renault – Produkt-Repräsentation mit RDF und OWL
Beispielhafte Repräsentation eines Fahrzeugs
Quelle: Badra, F.; Servant, F.-P.; Passant, A. (2011): A Semantic Web Representation of a Product Range Specication based on Constraint Satisfaction Problem in the Automotive Industry. In: Proc. of the 1st International Workshop on Ontology and Semantic Web for Manufacturing (OSEMA 2011), May 29, Crete, Greece. CEUR-WS.org Vol. 748), S. 37-50
Michael Fellmann
6
Warum OWL?
OWL > Motivation
Charakteristika Eindeutige Spezifi- kation von Konzepten und Relationen („shared conceptualization“) Maschinelle Korrektheits- prüfung Maschinelle Schlussfolgerungen Einfache Graph- struktur (S-P-O)
+ Flexible Visualisierung!
Michael Fellmann
7
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
8
Terminologische Grundlagen
Beschreibungslogiken im Allgemeinen – Es handelt sich um eine Familie von Sprachen zur Wissensrepräsentation. – Sie bauen meist auf einer Untermenge der Prädikatenlogik erster Stufe auf, sind im Gegensatz zu dieser jedoch entscheidbar - das ermöglicht Inferenzen (Schlussfolgerungen), d.h. aus vorhandenem Wissen neues zu gewinnen. – Beschreibungslogiken werden häufig im Hinblick auf effiziente Verfahren zur Schlussfolgerung entwickelt. Entwicklung und Bedeutung von Beschreibungslogiken – Das erste Beschreibungslogik-System war KL-ONE. Weitere Beispiele: LOOM (1987), BACK (1988), KRIS (1991), CLASSIC (1991), FaCT (1998), RACER (2001), KAON 2 (2005). – Die Abbildung von Ontologiesprachen (bspw. OWL) auf Beschreibungslogiken ermöglicht Schlussfolgerungen, die ein wichtiger Baustein von Semantic-Web- Technologien sind.
8
OWL > Grundlagen
Beschreibungslogik
Michael Fellmann
9
OWL 1 im Überblick
Was ist OWL (1.0)? – OWL steht für „Web Ontology Language“ und ist eine vom W3C standardisierte Ontologiesprache. – OWL ist abbildbar auf die Beschreibungslogik SHOIN(D), für die effiziente Inferenzmaschinen existieren. – OWL 1 gibt es in drei verschiedenen Versionen
Wird im Rahmen der Vorlesung verwendet)
– Mit OWL 2 gibt es bereits eine Nachfolgeversion, für die neben OWL-Full und OWL-DL noch die zusätzlichen Profile EL, RL und QL existieren. – Für die Anwendung im Rahmen der Vorlesung ist jedoch die Ausdrucksstärke von OWL-DL ausreichend.
www.w3.org/2004/OWL/
OWL > Grundlagen
Begriff, Sprachprofile
Michael Fellmann
10
OWL 1 und Beschreibungslogiken
Beschreibungslogik als Basis – (Attributive Language with Complements) ist die Grundlage vieler Beschreibungslogiken und unterstützt:
– Erweiterungen dieser Basissprache werden durch Hinzufügungen gekennzeichnet wie: transitive Rollen Rollen-Hierarchien Klassen basierend auf der Aufzählung ihrer Mitglieder inverse Rollen Kardinalität des Auftretens von Rollen (D) für Datentypen OWL-DL entspricht der Beschreibungslogik (D)
Zusammenhang
Michael Fellmann
11
OWL 1 und Beschreibungslogiken
Eigenschaften von (D) – Trotz eines relativ hohen Grades an Ausdrucksmächtigkeit vollständig berechenbar und entscheidbar.
dass jede theoretisch herleitbare Schlussfolgerung auch tatsächlich von einer Inferenzmaschine berechenbar ist.
Berechnungen in endlicher Zeit möglich sind. Eigenschaften von OWL-DL – im Gegensatz zu OWL Full ist OWL-DL berechen- und entscheidbar. – „OWL-DL supports those users who want the maximum expressiveness while retaining computational completeness (all conclusions are guaranteed to be computable) and decidability (all computations will finish in finite time)“ (McGuiness, van Harmelen 2004).
Zusammenhang
Michael Fellmann
12 12
OWL 2 im Überblick
Was ist OWL (2.0)? – OWL 2 ist eine Weiterentwicklung von OWL 1 und besitzt eine höhere Ausdrucksstärke. – In OWL 2 wurde der DL-Teil von OWL weiter aufgefächert in die Profile:
„Schema“-Anteil (d.h. einer großen TBox), Schlussfolgerungen sind in polynomialer Zeit in Abhängigkeit der TBox möglich.
Instanzdaten bestehen (d.h. eine große ABox aufweisen), über die im Rahmen von Anfragen geschlussfolgert werden muss. Dies ist mit einem garantierten Speicherverbrauch in Bezug auf die ABox-Größe möglich (LOGSPACE).
und ist für Anwendungen, in denen Abstriche bei der Performanz zugunsten einer erhöhten Ausdrucksstärke hinnehmbar sind. Wesentliche Schlussfolgerungen sind in polynomialer Zeit in Abhängigkeit von der gesamten Ontologie möglich.
www.w3.org/2007/OWL/
OWL > Grundlagen
Begriff, Sprachprofile
Michael Fellmann
13
OWL 2 und Beschreibungslogiken
Die Beschreibungslogik (D) – sROIQ ist eine Erweiterung von SHOIN – Merkmale der Beschreibungslogik sind: Einige gegenüber SHOIN zusätzliche Eigenschaften wie disjunkte, reflexive, irreflexive, asymmetrische Rollen, negierte Rollen in der ABox, reflexive Rollen in Klassenkonstruktoren etc. Komplexe Rolleninklusionen (zur Realisierung sog. „Property-Ketten“) (z.B. sind PKW-Besitzer auch Motor-Besizter, da diese Teil eines PKW sind), diese implizieren zudem (Rollen-Transitivität) und (Rollen-Hierarchie) Klassen basierend auf der Aufzählung ihrer Mitglieder Inverse Rollen Qualifizierte Kardinalität des Auftretens von Rollen (z.B. eine Hand hat als „Teile“ maximal 5 Finger, wovon einer ein Daumen ist.) (D) Unterstützung von Datentypen
www.cs.man.ac.uk/~ezolin/dl/
OWL > Grundlagen
Zusammenhang
Michael Fellmann
14 14
Bestandteile einer OWL-Ontologie
Kunde Land
Klasse (Konzept)
Produkt
Instanz (Individuum)
Belgien Paraguay China Lettland Elvis Liu Holger Anna Josef Rasierer iPhone
Property (Rolle, Relation)
Bezeichnungen
OWL > Grundlagen
Grafische Übersicht über wesentliche Konstrukte
Michael Fellmann
15
Bestandteile einer OWL-Ontologie
Eine Unterteilung der in einer Beschreibungslogik ausgedrückten Fakten wird oft in eine „Terminological box“ (TBox) und eine „Assertional Box“ (Abox) vorgenommen. TBox – Auch „Schema“ genannt, enthält Wissen über Konzepte (Klassen) einer Domäne. – Beispiele:
ABox – Auch „Daten“ genannt, enthält Wissen über Instanzen dieser Konzepte und deren Beziehungen untereinander. – Beispiele:
OWL > Grundlagen
ABox und TBox
Michael Fellmann
16
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
17 17
Klassen
Bedeutung von OWL-Klassen –
– Klassen fassen Individuen zusammen, die gleichartig beschrieben werden können. Deklaration von OWL-Klassen – Langform: Es wird eine RDF-Ressource deklariert, die als OWL-Klasse typisiert wird. Diese Form ist semantisch äquivalent zur Kurzform, wird jedoch im Folgenden aus Gründen der besseren Lesbarkeit nicht mehr weiter verwendet.
<rdf:Description rdf:ID="ABC"> <rdf:type rdf:resource="&owl;class"/> </rdf:Description> – Kurzform: Es wird die von RDF bekannte Kurzschreibweise verwendet.
<owl:Class rdf:ID="ABC"/>
OWL > Klassen
Deklaration und Verwendung
Michael Fellmann
18 18
Klassen
Vordefinierte Klassen in OWL –
–
Beziehungen jeder Klasse zu den vordefinierten Klassen – Jede Klasse ist Unterklasse von owl:Thing. –
Klassenhierarchien – Zur Bildung einer Klassenhierarchie wird rdfs:subClassOf verwendet.
<owl:Class rdf:ID="LKW"> <rdfs:subClassOf rdf:resource="#Automobil"/> </owl:Class>
DL-Syntax
⊑ LKW Automobil
DL-Syntax
(Thing) (Nothing) ⊥ ⊥ ⊥ ⊥ ⊤
OWL > Klassen
Vordefinierte Klassen, Klassenhierarchie
Michael Fellmann
19
Klassen
Grafische Veranschaulichung – owl:Thing ist Oberklasse aller OWL-Klassen. – Die Subklassenbeziehung kann auch als „is-a“ gelesen werden: Alle Instanzen von B sind auch Instanzen von A sowie Instanzen von „Thing“.
B A
DL-Syntax
B A ⊑ ⊑ ⊤
OWL > Klassen
Klassenhierarchie
Michael Fellmann
20
Klassen
Top-down-Ansatz (1) Allgemeinste Klasse einer Domäne formulieren (z.B. „Thing“) (2) Speziellere Unterklassen entwickeln (z.B. „Objekt“, „Prozess“ etc.) Bottom-up-Ansatz (1) Speziellste Klasse wird definiert (z.B. „Lieferantenadresse“) (2) Definition von allgemeineren Oberklassen (z.B. „Adresse“) Kombinierter Ansatz (Middle-out) (1) In beide Richtungen (2) Man beginnt mit den hervorstechendsten/ (vgl. Basisklassen im Kontext der intuitiv wichtigsten Konzepten Prototypentheorie)
OWL > Klassen
Ansätze zur Klassenbildung
Michael Fellmann
21
Klassen
Semantische Korrektheit – Die Hierarchie repräsentiert eine transitive „is-a“-Beziehung, daher sollte für jede Klasse geprüft werden, ob sie Subklasse aller (!) übergeordneter Klassen ist. – Keine Zyklen in der Klassenhierarchie. – Siehe auch weitere Verfahren der Evaluation wie OntoClean. Guter Stil – Klassen im Singular benennen. – Geschwisterklassen, d.h. Subklassen einer gemeinsamen Oberklasse, sollten (außer an der Wurzel) den gleichen Abstraktionsgrad aufweisen. – Synonyme Bezeichnungen der Klassen (Konzepte, Begriffe) in der Dokumentation der Klassen vermerken, nicht mehrere Klassen hierfür anlegen. – Hierarchische Struktur möglichst nicht im Namen der Klassen mitführen (z.B. Klasse „ObjektDokumentBedienungsanleitung“); der Kontext einer Klasse sollte durch die verwendete Software angezeigt werden.
21
OWL > Klassen
Empfehlungen zur Klassenhierarchie
Michael Fellmann
22
Klassen
Eine Subklasse hinzufügen, wenn eine Teilmenge der Instanzen – zusätzliche Eigenschaften besitzt, (Ausnahme: Klassen in terminologischen Hierarchien), – andere Restriktionen aufweist oder an anderen Relationen teilnimmt, oder – wenn die Unterscheidung in der betrachteten Domäne wichtig ist. Eine Instanz hinzufügen, wenn – keine weitere Spezialisierung mehr zu erwarten oder sinnvoll ist, oder – konkrete physische Objekte gemeint sind.
in einem Lager gemeint sind, dann könnte „Rotwein“ wieder zur Klasse werden. Restriktion von OWL-DL – Instanzen dürfen nicht gleichzeitig als Klassen auftreten, sonst liegt OWL-Full vor. – Diskussion und Lösungen: http://www.w3.org/TR/swbp-classes-as-values/
22
OWL > Klassen
Empfehlungen zur Verwendung von Subklassen und Instanzen
Michael Fellmann
23 23
Klassen
Disjunkte Klassen mit owl:disjointWith – Zwei Klassen können keine gemeinsamen Instanzen besitzen. – Beispiel: <owl:Class rdf:ID="Männlich"> <owl:disjointWith rdf:resource="#Weiblich"/> </owl:Class> Äquivalente Klassen mit owl:equivalentClass – Zwei Klassen gleichen sich. – Beispiel: <owl:Class rdf:ID="Automobil"> <owl:equivalentClass rdf:resource="#Kraftfahrzeug"/> </owl:Class>
DL-Syntax
Automobil Kraftfahrzeug ≡ ≡ ≡ ≡
DL-Syntax
¬ ¬ ¬ ¬ ⊑ Männlich Weiblich
OWL > Klassen
Einfache Klassenbeziehungen
Michael Fellmann
24 24
Komplexe Klassen
Schnittmenge mit owl:intersectionOf – Interpretierbar als UND-Operator auf Klassen. Individuen müssen beiden Klassen zugleich angehören. – Beispiel: <owl:Class rdf:ID="Amphibienfahrzeug"> <rdfs:subClassOf> <owl:Class> <owl:intersectionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Landfahrzeug"/> <owl:Class rdf:about="#Wasserfahrzeug"/> </owl:intersectionOf> </owl:Class> </rdfs:subClassOf> </owl:Class>
DL-Syntax
Amphibienfahrzeug Landfahrzeug Wasserfahrzeug ⊑ ⊓
OWL > Klassen
Konstruktoren
Michael Fellmann
25 25
Komplexe Klassen
Schnittmenge mit owl:intersectionOf – Grafische Veranschaulichung des Beispiels:
DL-Syntax
Amphibienfahrzeug Landfahrzeug Wasserfahrzeug ⊑ ⊓
Landfahrzeug
BMW 320d Corolla Verso Mercedes SLK LARC-5 Big Gipsy Wildflower
Wasserfahrzeug Fahrzeug Amphibienfahrzeug
OWL > Klassen
Konstruktoren
X
Michael Fellmann
26
OWL-Übung
Aufgabe: Überlegen Sie… – Gegeben sei das folgende Objekt: – Begründen Sie unter Bezugnahme auf das Objekt, warum es sinnvoll ist, die Klasse „Amphibienfahrzeug“ als Teilmenge der Schnittmenge aus Landfahrzeug und Wasserfahrzeug zu definieren (und nicht als deren Äquivalent)!
Einflügeliges Bodeneffektfahrzeug von Alexander Lippisch (Erstflug 1970)
OWL > Klassen
Michael Fellmann
27 27
Komplexe Klassen
Vereinigungsmenge mit owl:unionOf – Interpretierbar als ODER-Operator auf Klassen. Individuen müssen einer oder beiden Klassen angehören. – Beispiel: <owl:Class rdf:ID="WasserOderLandfahrzeug"> <rdfs:subClassOf> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Landfahrzeug"/> <owl:Class rdf:about="#Wasserfahrzeug"/> </owl:unionOf> </owl:Class> </rdfs:subClassOf> </owl:Class>
DL-Syntax
WasserOderLandfahrzeug Landfahrzeug Wasserfahrzeug ⊑ ⊔
OWL > Klassen
Konstruktoren
Michael Fellmann
28 28
Komplexe Klassen
Vereinigungsmenge mit owl:unionOf – Grafische Veranschaulichung des Beispiels: Landfahrzeug
BMW 320d Corolla Verso Mercedes SLK LARC-5 Big Gipsy Wildflower
Wasserfahrzeug Fahrzeug WasserOderLandfahrzeug
DL-Syntax
WasserOderLandfahrzeug Landfahrzeug Wasserfahrzeug ⊑ ⊔
OWL > Klassen
Konstruktoren
X
Michael Fellmann
29 29
Komplexe Klassen
Komplementmenge mit owl:complementOf – Interpretierbar als NICHT-Operator (d.h. Negation). Individuen dürfen nicht einer angegebenen Klasse angehören. – Beispiel: <owl:Class rdf:ID="BodenOderLuftOderRaumfahrzeug"> <rdfs:subClassOf> <owl:Class> <owl:complementOf rdf:resource="#Wasserfahrzeug" /> </owl:Class> </rdfs:subClassOf> </owl:Class>
DL-Syntax
BodenOderLuftOderRaumfahrzeug Wasserfahrzeug ¬ ¬ ¬ ¬ ⊑
OWL > Klassen
Konstruktoren
Michael Fellmann
30 30
Komplexe Klassen
Komplementmenge mit owl:complementOf – Grafische Veranschaulichung des Beispiels: Landfahrzeug
BMW 320d Corolla Verso Mercedes SLK LARC-5 Big Gipsy Wildflower
Wasserfahrzeug Fahrzeug
DL-Syntax
BodenOderLuftOderRaumfahrzeug Wasserfahrzeug ¬ ¬ ¬ ¬ ⊑
BodenOderLuftOderRaumfahrzeug
Problem: Klasse ist zu groß, besser wäre:
BLR Fahrzeug Wasserfahrzeug ¬ ¬ ¬ ¬ ⊑ ⊓
OWL > Klassen
Konstruktoren
X
Michael Fellmann
31
Klassen und Inferenz – Vorbemerkungen
Der Begriff „Inferenz“ – Auch als „Folgerung“, „Schlussfolgerung“ oder „Schließen“ bezeichnet. – Es geht grundlegend um die logisch korrekte Ableitung von neuen Aussagen (Fakten) aus bestehenden Aussagen. Inferenzmaschine – Eine Inferenzmaschine (engl. auch „Inference engine“, „Reasoner“ oder „Classifier“ genannt) leitet durch Schlussfolgerung neue Aussagen aus einer bestehenden Wissensbasis ab. – Teilweise wird auch davon gesprochen, dass durch maschinelles Schlussfolgern implizit (in der Wissensbasis) vorhandenes Wissen expliziert wird. – Aufgaben von Inferenzmaschinen sind u.a.:
OWL > Klassen
Inferenz und Inferenzmaschinen
Michael Fellmann
32
Klassen und Inferenz – Vorbemerkungen
Annahme einer offenen oder geschlossenen Welt – Die Geschlossene-Welt-Annahme beim Schlussfolgern (Closed World Reasoning)
– Die Offene-Welt-Annahme beim Schlussfolgern (Open World Reasoning)
Inferenzmaschinen für OWL-DL – Es existieren leistungsfähige Inferenzmaschinen wie
OWL > Klassen
OWA und GWA, Implementierungen von Inferenzmaschinen
Michael Fellmann
33 33
Klassen und Inferenz
Durch logisches Schließen (Inferenz) können einer Ontologie auf der Basis der verwendeten Sprachkonstrukte automatisch (mittels einer Inferenzmaschine) neue Fakten hinzugefügt werden. Im Folgenden werden hierfür Beispiele angegeben. Nutzung der transitiven Subklassenbeziehung – Gegeben: – Schlussfolgerung: Nutzung der Subklassen- und Äquivalenzbeziehung – Gegeben: – Schlussfolgerung: TBox: Fakultätsmitglied Person Professor Fakultätsmitglied ⊑ ⊑ Professor Person ⊑ TBox: Professor Fakultätsmitglied Professor Hochschullehrer ⊑ ≡ ≡ ≡ ≡ Hochschullehrer Fakultätsmitglied ⊑
OWL > Klassen
Beispiele für Schlussfolgerungen
Michael Fellmann
34
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
35 35
Abgrenzung: Properties und Eigenschaften
Properties sind Beziehungen zwischen Instanzen von Klassen, diese werden in der Literatur auch als Rollen oder (gelegentlich) Relationen bezeichnet. – In RDF wird auch davon gesprochen, dass Ressourcen (Subjekte) Properties (Prädikate) besitzen, deren Wert (Objekt) andere Ressourcen sind. – In OWL werden Properties, die Instanzen verbinden, als Objekt-Properties bezeichnet. Eigenschaften sind Beziehungen zwischen Instanzen von Klassen und Datenwerten. – In RDF wird auch davon gesprochen, dass Ressourcen (Subjekte) Properties (Prädikate) besitzen, deren Werte (Objekte) Literale sind. – In OWL werden Eigenschaften als spezielle Properties aufgefasst: Sie werden als Daten-Properties bezeichnet.
OWL-nahen Bezeichnungen „Objekt-Property“ und „Daten-Property“ gewählt.
OWL > Properties
Grundlegende Bemerkungen
Michael Fellmann
36 36
Properties
Charakterisierung von Properties – Properties in OWL sind Spezialisierungen von rdf:Property und besitzen daher
Beispiele zur Deklaration – Objekt-Property: <owl:ObjectProperty rdf:ID="besitzt"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:resource="#Objekt"/> </owl:ObjectProperty> – Daten-Property: <owl:DatatypeProperty rdf:ID="hatAlter"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:resource="&xsd;int"/> </owl:DatatypeProperty>
DL-Syntax
besitzt. Person besitzt.Objekt ∃ ∃ ∃ ∃ ∀ ∀ ∀ ∀ ⊑ ⊑ ⊤ ⊤
DL-Syntax
hatAlter. Person hatAlter.(xs:int) ∃ ∃ ∃ ∃ ∀ ∀ ∀ ∀ ⊑ ⊑ ⊤ ⊤
OWL > Properties
Charakterisierung, Deklaration
Michael Fellmann
37 37
Daten-Properties
Grundsätzlich können die von der XML-Schema-Spezifikation bekannten Datentypen verwendet werden. Ausgewählte Datentypen Name Bedeutung Beispiel xsd:float Gleitkommazahlen 2.25 xsd:int Ganzzahlen 4711 xsd:boolean Wahrheitswerte true xsd:string Zeichenkette abcdef… xsd:double Gleitkommazahlen mit hoher Präzision 3.14159… xsd:date Datum 2002-09-24 xsd:dateTime Datum mit Uhrzeit 2002-05-30T09:00:00
eigene Typen definiert werden.
OWL > Properties
Verwendbare Datentypen
Michael Fellmann
38 38
Beziehungen zwischen Properties
Äquivalente Properties –
ist, die sich aber hinsichtlich ihrer Intension unterscheiden können –
– Beispiel: <owl:ObjectProperty rdf:ID="hatEhefrau"> <owl:equivalentProperty rdf:resource="#hatGattin"/> </owl:ObjectProperty> Inverse Properties (nur bei Objektproperties möglich) –
– Beispiel: <owl:ObjectProperty rdf:ID="hatEhefrau"> <owl:inverseOf rdf:resource="#hatEhemann"/> </owl:ObjectProperty> hatEhefrau hatGattin ≡ ≡ ≡ ≡
DL-Syntax
hatEhefrau hatEhemann¯ ≡ ≡ ≡ ≡
DL-Syntax
OWL > Properties
Gleichartigkeit und Umgekehrtheit
Michael Fellmann
39 39
Zusätzliche Beziehungen zwischen Properties in OWL 2
Disjunkte Properties – Erlauben eine zusätzliche Einschränkung gültiger Ontologien. Es gilt stets: R1(x, y) ⌐R2(y, x). – Somit können einfache Wenn-Dann-Beziehungen spezifiziert werden, die als Restriktion genutzt werden können.
nicht das Property „hatStammkundenRabattStufe“ besitzen. Property-Ketten (nur bei Objektproperties möglich) – Das Auftreten eines Properties zwischen zwei Instanzen in der Wissensbasis wird an das Auftreten einer Kette von Properties zwischen den beteiligten Instanzen gebunden. – Es können somit ebenfalls einfache Wenn-Dann-Beziehungen spezifiziert werden, mit denen neues Wissen generiert wird.
Treibstoff verbraucht, dann benötigt das Fahrzeug diesen Treibstoff. Schematisch: RhatMotor(x, y), RverbrauchtTreibstoff(x, z) RbenoetigtTreibstoff(x, z)
OWL > Properties
Disjunktivität und Propertyketten
Michael Fellmann
40 40
Zusätzliche Beziehungen zwischen Properties in OWL 2
Beispiel – Grafisch: – In RDF/XML: <owl:ObjectProperty rdf:ID="benoetigtTreibstoff"> <owl:propertyChainAxiom rdf:parseType="Collection"> <owl:ObjectProperty rdf:about="hatMotor"/> <owl:ObjectProperty rdf:about="verbrauchtTreibstoff"/> </owl:propertyChainAxiom> </owl:ObjectProperty> Charakteristische Anwendungen – Übertragung von Eigenschaften in hierarchischen Ordnungen entlang der Hierarchie (z.B. Teil/Ganzes-Hierarchie, Subklassenhierarchie). – Transfer von Eigenschaften zwischen Instanzen (z.B. eine Person kennt ein Dokument, das ein Thema behandelt Person kennt das Thema).
OWL > Properties
Propertyketten
LARC-5 V-903 Engine Diesel hatMotor verbrauchtTreibstoff benoetigtTreibstoff
Michael Fellmann
41 41
Properties mit besonderen Eigenschaften
Funktionale Properties – owl:FunctionalProperty zur Deklaration von Properties, die maximal einen Wert für jede Instanz be- sitzen dürfen (äquivalent zur Kardinalitätsrestriktion von 1). – Lässt Schlüsse der Form zu: R(x, y) und R(x, z) y = z.
Inversfunktionale Properties (nur bei Objekt-Properties möglich) – owl:InverseFunctionalProperty zur Deklaration von Properties, für die verschiedene Instanzen nicht den gleichen Wert besitzen können. – Lässt Schlüsse der Form zu: R(x, y) und R(z, y) x = z.
DL-Syntax
1 hatSSN¯ ≤ ≤ ≤ ≤ ⊑ ⊤ 1 hatVorgesetzten ≤ ≤ ≤ ≤ ⊑ ⊤
DL-Syntax
OWL > Properties
Funktionalität
Michael Fellmann
42 42
Properties mit besonderen Eigenschaften
Transitive Properties (nur bei Objekt-Properties möglich) – owl:TransitiveProperty zur Deklaration – Lässt Schlüsse der Form zu: R(x, y) und R(y, z) R(x, z).
Symmetrische Properties (nur bei Objekt-Properties möglich) – owl:SymmetricProperty zur Deklaration – Lässt Schlüsse der Form zu: R(x, y) R(y, x).
In OWL 2 sind weitere Eigenschaften möglich – Reflexive und irreflexive Properties. Irreflexivität erlaubt den Schluss: R(x, y) y ≠ x. – Asymmetrische Properties. Es gilt stets: R(x, y) ⌐R(y, x).
DL-Syntax
hatPartner hatPartner¯ ≡ ≡ ≡ ≡
DL-Syntax
+
subRegion subRegion ≡ ≡ ≡ ≡
+
OWL > Properties
Transitivität, Symmetrie
Michael Fellmann
43 43
Properties mit besonderen Eigenschaften
Festlegung von Properties als Schlüssel – Ein Property oder mehrere Properties können als Schlüssel einer Klasse festgelegt
dieser Properties identifiziert werden. – Es können Objekt- und Daten-Properties verwendet werden. – Beispiel: <owl:Class rdf:about="Maschine"> <owl:hasKey rdf:parseType="Collection"> <owl:DatatypeProperty rdf:ID="hatInventarNr"/> </owl:hasKey> </owl:Class>
auf Klassenebene verwendet werden.
OWL > Restriktionen
Schlüsseleigenschaft von Properties in OWL 2
<rdf:Description rdf:about="hatInventarNr"/>
Alternative: Referenzierung eines extern deklarierten Property
Michael Fellmann
44 44
Properties und Inferenz
Nutzung der Property-Hierarchie und -Transitivität – Gegeben: – Schlussfolgerung (u. a.): Nutzung der Property-Hierarchie und inverser Properties – Gegeben: – Schlussfolgerung (u. a.): ⊑ TBox: Fluss mündetIn fließtIn fließtIn fließtIn ABox: Fluss(pegnitz), Fluss(main), Fluss(rhein) mündetIn(pegnitz, main), mündetIn(main, rhein) ≡ ≡ ≡ ≡ fließtIn(pegnitz, rhein) ⊑ TBox: Firma istGeschäftspartner istGeschäftspartner¯ istGeschäftspartner kennt ABox: Firma(a), Firma(b), istGeschäftspartner(a, b) ≡ ≡ ≡ ≡ + kennt(b, a)
OWL > Properties
Beispiele für Schlussfolgerungen
Michael Fellmann
45 45
Properties und Inferenz
Nutzung von Domäne und Wertebereich zur Klassierung – Gegeben: – Schlussfolgerungen: Nutzung inversfunktionaler Properties zur Äquivalenzbestimmung – Gegeben: – Schlussfolgerung: ⊑ ⊑ ⊑ TBox: istKFZHalterVon. Person, istKFZHalterVon.PKW, hatEhemann. Frau ABox: istKFZHalterVon(yun, q7), hatEhemann(yun, heinz) ∃ ∃ ∃ ∃ ∀ ∀ ∀ ∀ ∃ ∃ ∃ ∃ ⊤ ⊤ ⊤ Person(yun), Frau(yun), PKW(q7) TBox: 1hatUmsatzsteuerID¯ ABox: hatUmsatzsteuerID(fa_meier, "DE123456789"), hatUmsatzsteuerID(meier_gmbh, "DE123456789") ⊑ ≤ ≤ ≤ ≤ ⊤ fa_meier meier_gmbh ≡ ≡ ≡ ≡
OWL > Properties
Beispiele für Schlussfolgerungen
Michael Fellmann
46
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
47 47
Restriktionen auf Klassen
Property-Restriktionen sind Bedingungen, welche die zulässigen Property-Werte einschränken, die Instanzen einer Klasse aufweisen dürfen. – Festlegung durch <owl:Restriction>...</owl:Restriction> – Die Restriktion muss ein owl:onProperty-Element enthalten und ein oder mehrere der folgenden Deklarationen:
Weitere Restriktionen in OWL 2 – Qualifizerte Kardinalitätsrestriktionen – Selbstbezüge (owl:hasSelf) – Restriktionen über Datentypdefinitionen (vgl. Abschn. „Benutzerdefinierte Datentypen“)
OWL > Restriktionen
Grundlegendes
Michael Fellmann
48 48
Restriktionen auf Klassen
Unter- und Obergrenze der Kardinalität (Auftretenshäufigkeit) – Für das Auftreten eines Properties bei einer Instanz kann
– Beispiel: <owl:Class rdf:ID="Vorlesung"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatDozent"/> <owl:minCardinality rdf:datatype="&xsd;int">1</owl:minCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Vorlesung 1 hatDozent ≥ ≥ ≥ ≥ ⊑
DL-Syntax
OWL > Restriktionen
Kardinalitäts-Restriktion
Michael Fellmann
49 49
Restriktionen auf Klassen
Qualifizierte Kardinalität (Auftretenshäufigkeit mit Typangabe) – Für das Auftreten eines Properties bei einer Instanz kann die Anzahl (min, max, exakt) in Abhängigkeit des Wertebereichs festgelegt werden. – Beispiel: <owl:Class rdf:ID="Pruefung"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatPruefer"/> <owl:onClass rdf:resource="#Professor"/> <owl:minQualifiedCardinality rdf:datatype="&xsd;nonNegativeInteger" >1</owl:minQualifiedCardinality> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Pruefung 1 hatPruefer.Professor ≥ ≥ ≥ ≥ ⊑
DL-Syntax (Erweiterung)
OWL > Restriktionen
Qualifizierte Kardinalitäts-Restriktion in OWL 2
Michael Fellmann
50 50
Restriktionen auf Klassen
Einschränkungen des Wertebereiches – Für das Auftreten eines Properties bei einer Instanz kann vorgeschrieben werden, dass dieses Property nur bestimmte Werte annehmen darf. – Beispiel: <owl:Class rdf:ID="Vorlesung"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatDozent"/> <owl:allValuesFrom rdf:resource="#Lehrpersonal"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Vorlesung hatDozent.Lehrpersonal ∀ ∀ ∀ ∀ ⊑
DL-Syntax
OWL > Restriktionen
Wertebereichs-Restriktion
Michael Fellmann
51 51
Restriktionen auf Klassen
Forderung nach mindestens einem Wert – Für das Auftreten eines Properties bei einer Instanz kann vorgeschrieben werden, dass dieses mindestens einen Wert eines bestimmten Objekttyps aufweist. – Beispiel: <owl:Class rdf:ID="Pruefung"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatPruefer"/> <owl:someValuesFrom rdf:resource="#Professor"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Prüfung hatPruefer.Professor ∃ ∃ ∃ ∃ ⊑
DL-Syntax
OWL > Restriktionen
Existenz-Restriktion
Michael Fellmann
52 52
Restriktionen auf Klassen
Festlegung eines Vorgabewertes – Für das Auftreten eines Properties bei einer Instanz kann ein fester Wert vorgegeben werden. – Beispiel: <owl:Class rdf:ID="NiederlassungUSA"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatLand"/> <owl:hasValue rdf:resource="#USA"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Eigenschaften auf Klassenebene verwendet werden.
NiederlassungUSA hatLand.{USA} ∃ ∃ ∃ ∃ ⊑
DL-Syntax
OWL > Restriktionen
Vorgabewert-Restriktion
Michael Fellmann
53 53
Restriktionen auf Klassen und Inferenz
Nutzung der Kardinalitäts-Restriktion – Gegeben: – Schlussfolgerung: Nutzung eines Vorgabewertes – Gegeben: – Schlussfolgerung: Viele Inferenz-Beispiele, die auf Restriktionen basieren, benötigen definierte Klassen.
TBox: Fahrzeug =1 hatHalter hatHalter. Fahrzeug ABox: hatHalter(a4, sabine), hatHalter(a4, bine) ∃ ∃ ∃ ∃ ⊑ ⊑ ⊤ TBox: NiederlassungUSA hatLand.{USA} ABox: NiederlassungUSA(san_francisco) ⊑ ∃ ∃ ∃ ∃ hatLand(san_francisco, USA) sabine bine ≡ ≡ ≡ ≡
OWL > Restriktionen
Beispiele für Schlussfolgerungen
Michael Fellmann
54 54
Weitere Schlussfolgerungen
Äquivalenzbeziehung – Der Vereinigungsmengenkonstruktor (ODER) verhält sich distributiv in Existenzaussagen (der Schnittmengekonstruktor nicht!). – Es gilt: Subklassenbeziehungen – Einige Folgerungen sind schwächer als Äquivalenzen. – Beispiele:
B) ( p.A) ( p.B) ∃ ≡ ∃ ∃ ∃ ≡ ∃ ∃ ∃ ≡ ∃ ∃ ∃ ≡ ∃ ∃ ⊔ ⊔ p.(A B) ( p.A) ( p.B) ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ⊓ ⊑ ⊓
OWL > Restriktionen
…in Bezug auf Existenzaussagen
( p.A) ( p.B) ( p.A) ( p.B) ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ⊓ ⊑ ⊔ ( p.A) ( p.B) p.(A B) ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ∃ ⊓ ⊑ ⊔
Quelle: http://owl.man.ac.uk/2003/why/latest/
Michael Fellmann
55 55
Weitere Schlussfolgerungen
Äquivalenzbeziehung – Der Schnittmengekonstruktor (UND) verhält sich distributiv in Allaussagen (der Vereinigungsmengenkonstruktor nicht!). – Es gilt: Subklassenbeziehungen – Einige Folgerungen sind schwächer als Äquivalenzen. – Beispiele:
B) ( p.A) ( p.B) ∀ ≡ ∀ ∀ ∀ ≡ ∀ ∀ ∀ ≡ ∀ ∀ ∀ ≡ ∀ ∀ ⊓ ⊓ ( p.A) ( p.B) ( p.A) ( p.B) ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ⊓ ⊑ ⊔
OWL > Restriktionen
…in Bezug auf Allaussagen
p.(A B) ( p.A) ( p.B) ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ⊓ ⊑ ⊔ ( p.A) ( p.B) ( p.(A B)) ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ∀ ⊔ ⊑ ⊔
Quelle: http://owl.man.ac.uk/2003/why/latest/
Michael Fellmann
56
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
57
Primitive und definierte Klassen
Primitive Klassen – Auch „partielle“ Klassen genannt, da sie nur notwendige Bedingungen, jedoch keine hinreichenden angeben. – Die Klassenmitgliedschaft von Individuen wird i.d.R. manuell bspw. durch einen Ontologiekonstrukteur oder Ontologienutzer deklariert. Definierte Klassen – Auch „vollständige“ Klassen genannt, da sie notwendige und hinreichende Bedingungen angeben, um die Mitgliedschaft einer Instanz zu entscheiden. – Die Klassenmitgliedschaft kann automatisch durch eine Inferenzmaschine geschlossen werden. Definierte Klassen nutzen das Potenzial maschineller „Intelligenz“.
OWL > Klassenarten
Vorbemerkungen
Michael Fellmann
58
Primitive Klassen
Klasse „Unternehmensprozess“ – Notwendige Bedingung: Unternehmensprozesse werden von mindestens einer Person
– RDF/XML: <owl:Class rdf:ID="Unternehmensprozess"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatAkteur"/> <owl:someValuesFrom> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Mitarbeiter"/> <owl:Class rdf:about="#Maschine"/> </owl:unionOf> </owl:Class> </owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
Unternehmensprozess hatAkteur.(Mitarbeiter Maschine) ∃ ∃ ∃ ∃ ⊑ ⊔
DL-Syntax
OWL > Klassenarten
Beispiel für eine Klasse mit ausschließlich notwendigen Bedingungen
Michael Fellmann
59
Definierte Klassen
Klasse „KritischerProzess“ – Notwendige Bedingung: Der Prozess wird von einem Mitarbeiter ausgeführt. – Hinreichende Bedingung: Der Prozess unterstützt ein strategisches Unternehmensziel. – RDF/XML: <owl:Class rdf:ID="KritischerProzess"> <owl:equivalentClass> <owl:Restriction> <owl:onProperty rdf:resource="#hatZiel"/> <owl:someValuesFrom rdf:resource="#StrategischesZiel"/> </owl:Restriction> </owl:equivalentClass> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatAkteur"/> <owl:someValuesFrom rdf:resource="#Mitarbeiter"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
KritischerProzess hatZiel.StrategischesZiel KritischerProzess hatAkteur.Mitarbeiter ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ∃ ∃ ∃ ∃ ⊑
DL-Syntax
OWL > Klassenarten
Beispiel für eine Klasse mit notwendigen und hinreichenden Bedingungen
Michael Fellmann
60 60
Definierte Klassen
Definition einer Klasse durch vollständige Aufzählung ihrer Instanzen mit owl:oneOf – Alle Instanzen einer Klasse werden vollständig aufgelistet, die Klasse kann darüber hinaus keine weiteren Instanzen enthalten. – Beispiel: <owl:Class rdf:ID="Amphibienfahrzeug"> <owl:oneOf rdf:parseType="Collection"> <owl:Thing rdf:about="larc5"/> <owl:Thing rdf:about="amphicar"/> </owl:oneOf> </rdfs:subClassOf> </owl:Class>
DL-Syntax
Amphibienfahrzeug {larc5, amphicar} ≡ ≡ ≡ ≡
OWL > Klassenarten
Klassenbildung durch Enumeration
Michael Fellmann
61 61
Definierte Klassen
Definition einer Klasse durch vollständige Aufzählung ihrer Instanzen mit owl:oneOf – Grafische Veranschaulichung des Beispiels:
DL-Syntax
Amphibienfahrzeug {larc5, amphicar} ≡ ≡ ≡ ≡
BMW 320d Corolla Verso Mercedes SLK LARC-5 Big Gipsy Wildflower
Fahrzeug Amphibienfahrzeug
Amphicar
OWL > Klassenarten
Klassenbildung durch Enumeration
Michael Fellmann
62 62
Definierte Klassen und Inferenz
Nutzung definierter Klassen und der Vereinigungsmenge – Gegeben: – Schlussfolgerungen: Nutzung definierter Klassen, der Subklassenbeziehung und Existenz-Restriktion – Gegeben: – Schlussfolgerung: TBox: Prozess hatErgebnis.Produkt Kreditvergabe hatErgebnis.Kredit Kredit Produkt ⊑ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ Käufer Kunde Interessent Kunde ⊑ ⊑ TBox: Kunde Käufer Interessent ⊔ ≡ ≡ ≡ ≡ Kreditvergabe Prozess ⊑
OWL > Klassenarten
Beispiele für Schlussfolgerungen
Michael Fellmann
63 63
Definierte Klassen und Inferenz
Nutzung def. Klassen, Vereinigungs- und Schnittmenge sowie Existenz-Restriktion – Gegeben: – Schlussfolgerung: Nutzung definierter Klassen, Schnittmenge und der Existenz-Restriktion – Gegeben: – Schlussfolgerungen (u. a.) : TBox: WerbeEmpfänger (Käufer Interessent) hatZugestimmt.Werbemittel ABox: Interessent(max), hatZugestimmt(max, briefpost) Werbemittel(briefpost) ≡ ≡ ≡ ≡ ∃ ∃ ∃ ∃ ⊔ ⊓ InformierterKäufer(max) TBox: Interessent hatInteresseAn.Produkt Käufer hatGekauft.Produkt InformierterKäufer Interessent Käufer hatGekauft.Produkt ABox: hatInteresseAn(max, pda), hatGe ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ≡ ≡ ≡ ∀ ∀ ∀ ∀ ⊓ ⊑ ⊤ kauft(max, pda) WerbeEmpfänger(max)
OWL > Klassenarten
Beispiele für Schlussfolgerungen
Michael Fellmann
64
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
65 65
Benutzerdefinierte Datentypen in OWL
In OWL verfügbare Datentypen – Grundsätzlich unterstützt OWL eine breite Auswahl an Datentypen, die auf die XML-Schema-Spezifikation zurückgehen (vgl. http://www.w3.org/TR/owl2- syntax/#Datatype_Maps). Benutzerdefinierte Datentypen – „Benutzerdefiniert“ meint, dass ein Datentyp von einem verfügbaren, in den OWL- Standard „eingebauten“ Datentyp abgeleitet wurde. – Ein abgeleiteter Datentyp besteht aus einem Wertebereich, einem lexikalischen Bereich und einer Menge von Facetten, die den Wertebereich einschränken.
Einschränkung des Wertebereichs eines Basistyps, die durch Facetten spezifiziert wird (z.B. minInclusive für Integer). Welche Facetten verwendet werden können, ist durch die OWL-Spezifikation für den jeweiligen Basistyp festgelegt.
OWL > Datentypen
Grundlegendes
Michael Fellmann
66 66
Benutzerdefinierte Datentypen in OWL
Definition eines Datentyps für Zahlen größer Null – Ähnlich wie bspw. in XML-Schema, wird zunächst der Datentyp genannt, von dem abgeleitet wird (owl:onDatatype). Danach folgt eine Kollektion von Restriktionen. – Die Serialisierung der Typbeschreibung erfolgt in RDF/XML gemäß der Tripelstruktur:
– Beispiel in RDF/XML: <rdfs:Datatype rdf:ID="int_dauer"> <owl:onDatatype rdf:resource="&xsd;int"/> <owl:withRestrictions rdf:parseType="Collection"> <rdf:Description> <xsd:minExclusive rdf:datatype="&xsd;integer" >1</xsd:minExclusive> </rdf:Description> </owl:withRestrictions> </rdfs:Datatype>
OWL > Datentypen
Ein erstes Beispiel
66 66 DL-Syntax (Erweiterung)
int_dauer := int[> 1]
Michael Fellmann
67 67
Benutzerdefinierte Datentypen in OWL
OWL > Datentypen
Deklaration – anonym oder benannt
<owl:Class rdf:ID="Prozess"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatDauer"/> <owl:someValuesFrom> <rdfs:Datatype>
</owl:someValuesFrom> </owl:Restriction> </rdfs:subClassOf> </owl:Class> <rdfs:Datatype rdf:ID="int_dauer"> <owl:equivalentClass> <rdfs:Datatype>
</owl:equivalentClass> </rdfs:Datatype> </rdfs:Datatype> <owl:Class rdf:ID="Prozess"> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#hatDauer"/> <owl:someValuesFrom rdf:resource="#int_dauer"/> </owl:Restriction> </rdfs:subClassOf> </owl:Class>
DL-Syntax (Erweiterung) DL-Syntax (Erweiterung)
Prozess hatDauer.int[> 1] ∃ ∃ ∃ ∃ ⊑ Prozess hatDauer.int_dauer ∃ ∃ ∃ ∃ ⊑
Michael Fellmann
Verwendung von Datentyp-Ausdrücken – Datentyp-Ausdrücke können verwendet werden, um aus bestehenden (anonym oder benannt deklarierten) Datentypen neue Datentypen zusammenzusetzen. – Datentyp-Ausdrücke können innerhalb von Datentypen oder Restriktionen spezifiziert werden. Es können hierbei die gleichen Operatoren verwendet werden, die auch zur Konstruktion komplexer Klassen dienen. Operatoren zur Konstruktion Symbol Name OWL-Konstrukt Beispiel UND
ODER
NICHT
ENUM.
68 68
Komposition benutzerdefinierter Datentypen in OWL
OWL > Datentypen
Grundlegendes zu Datentyp-Ausdrücken
68 68
⊓ ⊔
{ { { { } } } }
...,...
int[> 1] int[< 23] ⊓ int[> 0] int[< 0] ⊔ int[< 0] ¬ ¬ ¬ ¬ {1, 2, 42}
Ähnliche Ausdrücke sind auch mit anderen Datentypen möglich, bspw. xsd:dateTime. Bei Schlussfolgerungen wird die Bedeutung der Datentypen berücksichtigt!
Michael Fellmann
69 69
Benutzerdefinierte Datentypen und Inferenz
Nutzung definierter Klassen und benutzerdefinierter Datentypen (1) – Gegeben: – Schlussfolgerung: Nutzung definierter Klassen und benutzerdefinierter Datentypen (2) – Gegeben: – Schlussfolgerungen: Sonderprozess(x), Normalprozess(y), Sonderprozess(z) TBox: int_dauer := int[> 0] int[<6] int_expressdauer := {1, 2} int_normaldauer := int_dauer int_expressdauer Normalprozess hatDauer.int_normaldauer Sonderp ¬ ¬ ¬ ¬ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ⊓ ⊓ rozess hatDauer.( int_normaldauer) ABox: hatDauer(x, 2), hatDauer(y, 3), hatDauer(z, 9) ≡ ∃ ¬ ≡ ∃ ¬ ≡ ∃ ¬ ≡ ∃ ¬ Expressprozess Normalprozess ⊑
Beispiele für Schlussfolgerungen
OWL > Datentypen
TBox: Normalprozess hatDauer.(int[> 0] int[< 6]) Expressprozess hatDauer.{1, 2} ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ⊓
Michael Fellmann
70 70
Benutzerdefinierte Datentypen und Inferenz
Nutzung definierter Klassen und benutzerdefinierter Datentypen (3) – Gegeben: – Schluss- folgerungen: InSummer Before2012, InWarmTime InSummer InWarmMonths InSummer, InWarmTime InWarmMonths Before2012(event), InSummer(event) InWarmMonths(event), InWarmTime(event) ≡ ≡ ≡ ≡ ⊑ ⊑ ⊑
Beispiele für Schlussfolgerungen
OWL > Datentypen
TBox: dt_in-summer := (dateTime[> "2011-06-01T00:00:00-00:00"] dateTime[< "2011-10-01T00:00:00-00:00"]) dt_heat-months := (dateTime[> "2011-08-01T0 ⊓ 0:00:00-00:00"] dateTime[< "2011-09-01T00:00:00-00:00"]) dt_in-summer-not-heat := (dt_in-summer dt_heat-months) InSummer hasDate.dt_ ¬ ¬ ¬ ¬ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ⊓ ⊓ in-summer InWarmTime hasDate.(dt_in-summer dt_heat-months) InWarmMonths hasDate.dt_in-summer-not-heat Before2014 hasDate.dateTime[< "2012-01-01T00:00:00-00:0 ≡ ∃ ¬ ≡ ∃ ¬ ≡ ∃ ¬ ≡ ∃ ¬ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ≡ ∃ ⊓ 0"] ABox: hasDate(event, "2011-07-25T04:00:00-05:00")
Michael Fellmann
71
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
72 72
Instanzen
Es existieren zwei Arten von Instanzen – Klassen-Instanzen (Individuen)
<Prozess rdf:ID="Auftragsbearbeitung"/>
– Property-Instanzen
<Prozess rdf:ID="Auftragsbearbeitung"> <hatMitarbeiter>5</hatMitarbeiter> </Prozess>
Subjekt-Prädikat-Objekt-Sätzen. Property
OWL > Instanzen
Grundlegendes
Michael Fellmann
73
Instanzen
Gleichheit mit owl:sameAs – Deklariert, dass verschiedene Bezeichner dasselbe Individuum bezeichnen. – Wichtig für Inferenz, da in OWL die Non Unique Name Assumption gilt!
<rdf:Description rdf:ID="rechnung"> <owl:sameAS rdf:resource="#faktura"/> </rdf:Description> Unterschiedenheit mit owl:differentFrom – Gegenteil von sameAs. – Deklariert, dass zwei Individuen verschieden voneinander sind.
73
OWL > Instanzen
Beziehungen zwischen Instanzen
Michael Fellmann
74
Instanzen
Mengen unterschiedlicher Instanzen mit owl:AllDifferent – Es handelt sich um eine speziell definierte, vorgegebene OWL-Klasse. – Diese kann in Verbindung mit dem Property owl:distinctMembers dazu verwendet werden, die Verschiedenheit einer Menge von Individuen zu notieren. – In semantischer Hinsicht entspricht dies einer paarweisen Deklaration der Verschiedenheit der Instanzen untereinander mit owl:differentFrom.
<owl:AllDifferent> <owl:distinctMembers rdf:parseType="Collection"> <Person rdf:about="#einstein"/> <Person rdf:about="#heisenberg"/> <Person rdf:about="#leibnitz"/> </owl:distinctMembers> </owl:AllDifferent>
74
OWL > Instanzen
Beziehungen zwischen Instanzen
Michael Fellmann
75 75
Instanzen und Inferenz
Nutzung definierter Klassen, Gleichheit und der Vereinigungsmenge – Gegeben: – Schlussfolgerungen: Nutzung def. Klassen, Unterschiedenheit u. der qualifizierten Kardinalitäts-Restriktion – Gegeben: – Schlussfolgerung: TBox: FlussUndStrassenfahrzeug Landfahrzeug Wasserfahrzeug ABox: Landfahrzeug(hans_trippels_car), Wasserfahrzeug(amphicar) sameAs(amphicar, hans_trippels_car) ⊓ ≡ ≡ ≡ ≡ TBox: AntragMitDoppelterPrüfung 2hatPrüfer.Person ABox: hatPrüfer(urlaubsantrag, chef), hatPrüfer(urlaubsantrag, sachbearbeiter), differentFrom(chef, sachbearbeiter) ≡ = ≡ = ≡ = ≡ = FlussUndStrassenfahrzeug(amphicar), FlussUndStrassenfahrzeug(hans_trippels_car) AntragMitDoppelterPrüfung(urlaubsantrag)
OWL > Instanzen
Beispiele für Schlussfolgerungen
Michael Fellmann
76
Namenskonventionen
Namenskonventionen für Ontologie definieren und konsequent anwenden – Ontologie leichter verständlich – Beugt einigen Modellierungsfehlern vor Verschiedene zu betrachtende Konventionen – Großschreibung und Trennzeichen
zusammenschreiben (sog. „CamelCase“-Schreibweise). – Bei Klassen sollte möglichst konsequent der Singular verwendet werden. – Präfix- und Suffix-Konventionen:
Oberklasse nicht wiederholen (Ausnahmen sind zur Verbesserung der Verständlichkeit teilweise aber möglich).
OWL > Instanzen
Empfehlungen (nicht nur für Instanzen)
Michael Fellmann
77
Schlussbetrachtung
Was ist OWL? – OWL ist eine Sprache zur Formulierung von Ontologien. – Mit OWL kann Wissen formal repräsentiert werden und es existieren effiziente Algorithmen für Schlussfolgerungen. …und was nicht? – OWL ist keine Programmiersprache (es ist eine deklarative Sprache, um den „Zustand der Welt“ oder „wahres Wissen“ zu beschreiben). – OWL ist keine Schemasprache wie XML-Schema (syntaktisch korrekte Dokumente zu beschreiben, ist nicht das Ziel von OWL). – Ontologien sind keine Datenbanken (können aber von DB-Technologien profitieren).
Schlussfolgerungen erlaubt!
OWL
zur OWL-Einführung
Michael Fellmann
78
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
79
Vorgehensmodelle
Vorgehensmodelle beschreiben eine sinnvolle Ordnung der in einem Gestaltungsprozess auftretenden Aufgabenstellungen und können Empfehlungen hinsichtlich der anzuwendenden Methoden, Techniken und Werkzeuge geben. Die konsequente Anwendung eines Vorgehensmodells zur Ontologiekonstruktion ermöglicht bzw. erleichtert die – effiziente Entwicklung komplexer Ontologien, – Sicherstellung von Konsistenz und Korrektheit, – verteilte Entwicklung von Ontologien durch geographisch getrennte Gruppen. Die Entwicklung von Ontologien kann in drei Bereiche, die von der Verwendung eines Vorgehensmodells profitieren, unterteilt werden: – Management (z.B. Koordination der Akteure, Überwachung, Qualitätssicherung) – Entwicklung (z.B. Machbarkeitsstudie, Implementierung, Wartung) – Unterstützende Tätigkeiten (z.B. Wissensaneignung, Evaluation, Dokumentation)
Ontologien > Methoden
Einordnung und Relevanz
Michael Fellmann
80
Beispiel eines Vorgehensmodells
Uschold & King schlagen für die Ontologiekonstruktion eine Unterteilung in 4 Prozesse vor: – Identify Purpose, Building, Evaluation, Documentation
Welchen Zweck hat die Ontologie? Wie wird sie genutzt? Schlüsselkonzepte und Beziehungen
aufstellen. Auswahl der Sprachkonstrukte mit denen die Ontologie beschrieben wird (z.B. Klassen, Entitäten,
der Konzepte in Code. Integration mit anderen Ontologien. Überprüfung ob die Ontologie den Anforder- ungen genügt. Dokumentation der Ontologie und der getroffenen Annahmen um die Kombination mit anderen Ontologien zu ermöglichen.
Identify Purpose Documentation Evaluation Capture Coding Integrating Building
Ontologien > Methoden
Vorgehensmodell von Uschold & King (1995)
Michael Fellmann
81
Beispiel eines Vorgehensmodells
Veranschaulichung der ersten beiden Teilschritte von Uschold & King am Beispiel einer Ontologie für das Themengebiet „Tourismus“: – Identify Purpose:
Übernachtung (Hotel, Model, Zelten), Züge, Busse, U-Bahnen usw. – Capture:
– Verkehrsmittel ist eine Klasse. Jedes Verkehrsmittel hat einen Abfahrtsort. – Bus ist eine Unterklasse von Verkehrsmittel. – Lokalbus ist eine Unterklasse von Bus. Bei der Klasse Lokalbus sind Abfahrtsort, Halteorte und Ziel identisch. – In den weiteren Schritten wird die Ontologie in einer Ontologiesprache codiert, mit weiteren Ontologien integriert, evaluiert und dokumentiert.
Ontologien > Methoden
Vorgehensmodell von Uschold & King
Michael Fellmann
82
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
83
Übersicht: Vorgehensmodelle zur Ontologiekonstruktion
Tabellarischer Vergleich anhand folgender Kriterien: – Vorgeschlagener Lebenszyklus – ein Lebenszyklus definiert die Phasen, die eine Ontologie durchläuft und etwaige Beziehungen zwischen ihnen.
Definitionen werden nur während der Erstellung einer neuen Version hinzugefügt.
Veränderung, Ergänzung oder Entfernung von Definitionen ist jederzeit möglich.
ausgewählte Veränderungen dauerhaft übernommen. – Abhängigkeit vom Einsatzgebiet
bestimmter Anwendungen entwickelt.
werden während der Spezifikation definiert.
Ontologien > Methoden
Erläuterung der Kriterien
Michael Fellmann
84
Übersicht: Vorgehensmodelle zur Ontologiekonstruktion
– Strategie zur Konzeptidentifikation
Verkehrsmittel UBahn Bus Taxi Shuttle Reisebus Lokalbus TopDown MiddleOut BottomUp
Erläuterung der Kriterien
Michael Fellmann
85
Übersicht: Vorgehensmodelle zur Ontologiekonstruktion
– Verwendung einer Basisontologie (auch: Core/Upper/Top-level Ontology)
– Basisontologien (Core Ontologies) werden verwendet, um eine Ontologie zu beschreiben, die im weiteren Konstruktionsprozess ausgebaut wird. Demgegenüber zeichnen sich bereichsübergreifende, abstrakte Ontologien (Upper Ontologies) i.d.R. durch einen höheren Abstraktionsgrad aus. – Basisontologien enthalten nur grundlegendste Begriffe – sie relativ abstrakt und können daher in unterschiedlichen Themengebieten genutzt werden. – Ontologien mit derselben Basisontologie sind leichter kombinierbar. – Spezifische Softwareunterstützung
Werkzeug.
Ontologien > Methoden
Erläuterung der Kriterien
Michael Fellmann
86
Übersicht: Vorgehensmodelle zur Ontologiekonstruktion
Uschold & King Methontology On-To- Knowledge DILIGENT knowledge process Vorgeschlagener Lebenszyklus keiner kontinuierliche Prototypen inkrementell mit kontinuierlichen Prototypen evolutionär Abhängigkeit vom Anwendungsbereich ja nein ja nein Vorgehensweise zur Konzeptidentifikation middle-out middle-out top-down bottom-up middle-out middle-out Verwendung einer Basisontologie nein bedingt bedingt ja Spezifische Softwareunterstützung nein ODE WebODE OntoEdit Protégé OntoEdit nein Merkmal VG-Modell
Ontologien > Methoden
Tabellarischer Vergleich ausgewählter Vorgehensmodelle
Michael Fellmann
87
Übersicht: Vorgehensmodelle zur Ontologiekonstruktion
Tätigkeit/Teilbereich Uschold & King Methontology On-To- Knowledge DILIGENT knowledge process Ontologiemanagement Koordination der Akteure
beschrieben
beschrieben beschrieben Qualitätssicherung
beschrieben beschrieben Ontologieentwicklung Vor der Entwicklung Anwendungsanalyse
Spezifikation erwähnt
beschrieben
erwähnt
erwähnt Nach der Entwicklung Wartung
erwähnt
Nutzung
beschrieben Unterstützende Tätigkeiten Wissensaneignung erwähnt
beschrieben erwähnt Evaluation erwähnt
erwähnt beschrieben Integration erwähnt erwähnt erwähnt ? Versionsverwaltung
erwähnt beschrieben Dokumentation erwähnt
beschrieben beschrieben Merging und Alignment
Ontologien > Methoden
Tabellarischer Vergleich: Unterstützung der einzelnen Teilprozesse
Michael Fellmann
88
Übersicht: Vorgehensmodelle zur Ontologiekonstruktion
Keines der Vorgehensmodelle bildet alle Aktivitäten ab. – Methodontology beschreibt die einzelnen Aktivitäten am präzisesten. – On-To-Knowledge beschreibt die meisten Aktivitäten. – DILIGENT knowledge process hat als besonderen Fokus das Zusammenwirken der Beteiligten (zwischen Experten und Benutzern). Weitere Defizite – Eine Unterstützung durch Software ist häufig nicht gegeben und die verfügbaren Tools decken nicht alle Aktivitäten ab. – Der Fokus der Vorgehensmodelle liegt in der Entwicklung und Implementation, wichtige Bereiche wie Evaluation und Evolution werden weniger ausführlich beschrieben.
Ontologien > Methoden
Abschließende Bemerkungen
Michael Fellmann
89
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
90
Ansätze zur Evaluation von Ontologien
Grundlegendes – Es existieren unterschiedliche Auffassungen, welche Tätigkeiten eine Evaluation umfassen sollte und welche Kriterien an die Ontologie anzulegen sind. – Im Wesentlichen geht es darum, festzustellen, was die Ontologie korrekt definiert, was sie nicht definiert und was sie falsch definiert. Kriterien zur Evaluation können nach (Gómez-Pérez, 1996) sein: – Konsistenz (Widerspruchsfreiheit), – Vollständigkeit (jede einzelne Definition ist vollständig und alles was die Ontologie beinhalten soll ist entweder definiert oder kann gefolgert werden) und – Präzision (keine Redundanzen, keine unnötigen Informationen). Methoden (Beispiele) – Taxonomie-Evaluation: Gómez-Pérez liefert eine Liste häufiger Fehler die als "Checkliste" verwendet werden kann. – OntoClean analysiert die Ontologie nach Fehlern bei Ober-/Unterklassen-Beziehungen mittels Meta-Kriterien wie Rigidität, Identität und Einheit (d.h. was umfasst eine Entität).
Ontologien > Methoden
Überblick
Michael Fellmann
91
Ansätze zur Evaluation von Ontologien
Allgemein: Taxonomie-Evaluation Circularity Error (Zyklen-Fehler) OntoClean (Beispiel-Kriterien): – Rigidity (Beständigkeit, Gültigkeit) – Unity (Einheits-Kriterium) Student Person SubclassOf ~R +R Hotel Gebäude SubclassOf +U +U
Problem: Studenten können aufhören, Stu- denten zu sein. Bei Personen gilt dies nicht! Problem: „Hotel“ und „Gebäude“ unterliegen unterschiedlichen Einheits-Kriterien! Problem: Zyklen in der Taxonomie führen zu falschen Schlüssen. Z.B. kann Frau nicht Unterklasse von sich selbst sein!
Ontologien > Methoden
Beispiele Weitere Prinzipien der Klassenbildung vgl. Parsons und Wand 2008 „Using Cognitive Principles to Guide Classification in Information Systems Modeling”
Michael Fellmann
92
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
93
Werkzeuge zur Ontologiekonstruktion und -Anwendung
Es existiert eine Vielzahl von Werkzeugen zur Erstellung und Verarbeitung von Ontologien wie auch Infrastruktur-Software zur Integration von Wissensrepräsentationen in Anwendungssysteme. An Geschäftsmodellen sind häufig die folgenden anzutreffen: – Open Source (meist im akademischen Umfeld) – Open Source mit kostenpflichtiger Anpassung/Unterstützung durch Hersteller – Kommerzielle Angebote Wesentliche hier betrachtete Kategorien sind: – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
Ontologien > Werkzeuge
Grundlegende Betrachtung
Michael Fellmann
94
Ontologie-Editoren
Ausgewählte Editoren: Be Informed Suite, Chimaera, CmapTools Ontology Editor (COE), DOME (DERI Ontology Management Environment), HOZO, Java Ontology Editor (JOE), KAON, KMgen, Knoodl, LinKFactory, Model Futures IDEAS AddIn, Model Futures OWL Editor, myWeb, NeOn Toolkit, OBO-Edit, OilEd, OntoStudio, Ontolingua, Protégé, ScholOnto, Semantic Turkey, Swoop, Synaptica, TopBraid Composer, Transinsight, WebODE. Im Rahmen dieser Vorlesung kann nur eine Auswahl gezeigt werden, deshalb werden nur folgende Editoren näher betrachtet: – Protégé – OntoStudio – Topbraid Composer – Semantische Wikis wie SMW oder Moki (keine Editoren im strengen Sinne)
Ontologien > Werkzeuge
Überblick
Michael Fellmann
95
Protégé
Ontologien > Werkzeuge
Nutzeroberfläche
Michael Fellmann
96
Protégé
Plattform eigenständiges Programm Lizenz Mozilla Public License (MPL) Erweiterbarkeit Ja (Plug-In-Konzept) Teil eines Frameworks nein Speicherung Datei / Datenbank Ontologiesprachen RDF, OWL Import- und Exportformate OWL/RDF, OWL/XML, Manchester, N3, TURTLE
Ontologien > Werkzeuge
Charakterisierung
Michael Fellmann
97
Protégé – Ausgewählte Erweiterungen
Collaborative Protégé
Supports collaborative ontology editing as well as annotation of both ontology components and ontology changes.
DL-Learner
The Protégé 4 DL-Learner plugin allows to learn equivalence and super class axioms based on instance data.
HTML Chat
Allows users logged into a client-server version of Protégé to chat in real time.
OntoLing
Facilitates linguistic enrichment of ontologies and includes an interface for WordNet (from 1.6 to 2.1) and DICT dictionaries.
OWL Lint
Define and run tests against a set of OWL ontologies for quality control, debugging, best practices, and many other purposes.
PROMPT
Manage multiple ontologies, create mappings, merge ontologies, extract parts and move frames from one project to another.
SWRLTab
An extension to Protégé-OWL that supports editing and execution of SWRL rules.
Axiomé
A free, open-source Protégé-OWL plug-in for SWRL rules elicitation and management.
Sub Ontology Tab
Allows manipulation of axioms across ontologies.
Taxonomy Cut+Paste Provides two quick ways to extract parts of a class hierarchy into text form for papers, presentations, etc. TerMine Plugin
Uses text mining tools to extract candidate terms from a corpus of text. Ontologien > Werkzeuge
Konstruktion
Michael Fellmann
98
Protégé – Ausgewählte Erweiterungen
Bookmarks
Drag and drop classes and properties into the bookmark view to make them accessible at any time.
Cloud Views
Visualize your ontology as a tag cloud (a set of related tags with corresponding weights.
Jambalaya
Jambalaya is a Protégé plug-in that uses Shrimp to visualize Protégé-Frames and Protégé-OWL ontologies.
Matrix
Several spreadsheet-style views of an ontology, including existential fillers, individual relationships, and an object properties view.
OntoBase
Allows Protégé to be used as "Model" and "View" for simple database applications.
OntoViz
The OntoViz Tab allows you to visualize Protégé ontologies with AT&T's highly sophisticated Graphviz visualization software.
OWL2UML
Automatically generates UML diagram which represents active OWL ontology using OMG's Ontology Definition Metamodel.
OWLPropViz
Enables graphical presentation of OWL object properties. Users can select the property or properties to be visualized in the graph.
OWLViz
Enables class hierarchies in an OWL ontology to be viewed allowing comparison of the asserted class hierarchy and the inferred class hierarchy.
Outline and Existential Tree Views Provides alternatives to the subsumption hierarchy view. See documentation below for more detail. PromptViz
Creates visual representations of the differences between two versions of an ontology.
TGViz
TGVizTab allows users to visualize Protégé ontologies using the TouchGraph library. Ontologien > Werkzeuge
Visualisierung
Michael Fellmann
99
Protégé – Ausgewählte Erweiterungen
Excel Import
Import content and generate classes from Excel or CSV files. Provide rules to create restrictions between columns.
NaturalOWL
Generates descriptions of individuals and classes from OWL ontologies. Currently it supports English and Greek.
OWLDoc
Creates a bundle of (mostly) static HTML pages for publishing to the Web or distributing to colleagues.
Queries and Export Tab This plug-in allows you to query knowledge-bases and export the results. UML Backend
Provides an import and export mechanism between the Protégé knowledge model and the object-oriented modeling language UML. Ontologien > Werkzeuge
Import und Export
Michael Fellmann
100
Protégé-Erweiterung „OntoGraf“
100
Interaktive Navigation im Ontologie-Graph
Quelle: protegewiki.stanford.edu/images/c/cd/Ontrograf_screenshot1.png
Ontologien > Werkzeuge
Michael Fellmann
101
Protégé-Erweiterung „Jambalaya“
101
Visualisierung von Zusammenhängen
Quelle: webhome.cs.uvic.ca/~chisel/imgs/jambalaya/screenshot_full.jpg
Ontologien > Werkzeuge
Michael Fellmann
102
Protégé-Erweiterungen „NavigOWL“ und „Cloud Views“
102
Visualisierung großer Datenmengen
Quelle: protegewiki.stanford.edu/images/f/f8/Protege-plugin.jpg ; protegewiki.stanford.edu/images/d/d2/Cloud.png
Layout-Optionen einstellbar Gewichtungs- Kriterium einstellbar (bspw. Menge der Instanzdaten, Hierarchietiefe…)
Ontologien > Werkzeuge
Michael Fellmann
103
Protégé-Erweiterung „OWL2UML“
103
Darstellung einer Ontologie in UML-Notation
Quelle: protegewiki.stanford.edu/images/3/34/OWL2UML.png
Ontologien > Werkzeuge
Michael Fellmann
104
Protégé-Erweiterung „Matrix“
104
Erzeugung von Listen-Darstellungen einer Ontologie
Quelle: protegewiki.stanford.edu/images/a/ab/Matrix-existential.png
Ontologien > Werkzeuge
Michael Fellmann
105
Protégé-Erweiterung „OWLDoc“
105
Erzeugung einer Hypertext-basierten Dokumentation
Quelle: www.co-ode.org/downloads/protege-x/plugins/images/owldoc-export.png
Ontologien > Werkzeuge
Michael Fellmann
106
OntoStudio
Ontologien > Werkzeuge
Nutzeroberfläche
Michael Fellmann
107
OntoStudio
Plattform Eclipse Lizenz kommerziell Erweiterbarkeit ja Teil eines Frameworks (Produktsuite) Speicherung Datei / Datenbank Ontologiesprachen OWL, RDF, F-Logic Import- und Exportformate OWL/RDF, UML 2.0, Excel-Tabellen, Outlook-Emails, Ordnerstrukturen des Dateisystems
Ontologien > Werkzeuge
Charakterisierung
Michael Fellmann
108
Topbraid Composer
Ontologien > Werkzeuge
Nutzeroberfläche
Michael Fellmann
109
Topbraid Composer
Plattform Eclipse Lizenz kommerziell, kostenfreie Version verfügbar Erweiterbarkeit ja Teil eines Frameworks ja Speicherung Dateien / Datenbank bei den kostenpflichtigen Angeboten Ontologiesprachen OWL, RDF Import- und Exportformate OWL/RDF, XML, UML, Spreadsheets, RSS/Atom Feeds bei den kostenpflichtigen Angeboten
Ontologien > Werkzeuge
Charakterisierung
Michael Fellmann
110
OWLGrEd
Ontologien > Werkzeuge
Nutzeroberfläche
Michael Fellmann
111
OWLGrEd
Plattform Eigenständiges Programm Lizenz „free to use“ Erweiterbarkeit nein (kompatibel mit Protégé) Teil eines Frameworks nein Speicherung Datei Ontologiesprachen OWL 2 Import- und Exportformate OWL/RDF
Ontologien > Werkzeuge
Charakterisierung
Michael Fellmann
112
Semantic Media Wiki
Ontologien > Werkzeuge
Nutzeroberfläche
Michael Fellmann
113
Semantic Media Wiki
Plattform webbasiert (Erweiterung des Media Wiki) Lizenz verschiedene Open-Source-Lizenzen Erweiterbarkeit nein (indirekt durch Plug-Ins zu Media Wiki) Teil eines Frameworks nein Speicherung
Ontologiesprachen proprietär Import- und Exportformate OWL/RDF
Ontologien > Werkzeuge
Charakterisierung
Michael Fellmann
114
Moki Wiki
Ontologien > Werkzeuge
Nutzeroberfläche (1/2)
Michael Fellmann
115
Moki Wiki
Ontologien > Werkzeuge
Nutzeroberfläche (2/2) OWL-Export
Michael Fellmann
116
Moki Wiki
Plattform webbasiert (Erweiterung von Semantic Media Wiki) Lizenz GPLv2 Erweiterbarkeit nein (indirekt durch Plug-Ins zu Media Wiki) Teil eines Frameworks nein Speicherung
Ontologiesprachen proprietär Import- und Exportformate OWL/RDF, eRDF
Ontologien > Werkzeuge
Charakterisierung
Michael Fellmann
117
Weitere Werkzeuge
Online-Validatoren – OWL-Validator der Uni Manchester, erlaubt die Verifizierung von OWL-Profilen
– WonderWeb OWL Ontology Validator
www.mygrid.org.uk/OWL/Validator
– Diff-Werkzeug zur Bestimmung der semantischen Differenz von Ontologien (Anzeige semantisch wirksamer/unwirksamer Hinzufügungen/Entfernungen)
Online-Visualisierungen – MyGrid OWL Ontology HTML Präsentation
www.mygrid.org.uk/OWL/Presentation
– OWLSight
pellet.owldl.com/ontology-browser
Ontologien > Werkzeuge
Ergänzungen zu den Editoren
Michael Fellmann
118
Weitere Werkzeuge
Online-Syntax-Konverter – Konverter zwischen verschiedenen OWL-Formaten wie RDF/XML, OWL/XML etc.
– Konverter von OWL 2 in ACE (Attempto Controlled English)
attempto.ifi.uzh.ch/site/docs/owl_to_ace.html
Metriken, Komplexität, Module – Metriken zu OWL-Ontologien anzeigen (z.B. Anzahl der Klassen, Ausdrucksstärke etc.)
– Komplexität einer Beschreibungslogik
– OWL-Modul-Extraktor zur Gewinnung logisch unabhängiger Ontologie-Teilbereiche
Weitere Werkzeuge – Liste mit weiteren Werkzeugen im Bereich des Semantic Web (ca. 800)
www.mkbergman.com/sweet-tools/
Ontologien > Werkzeuge
Ergänzungen zu den Editoren
Michael Fellmann
119
Agenda
OWL-Einführung – Grundlagen und Terminologie – Klassen – Properties – Restriktionen auf Klassen – Primitive und definierte Klassen – Benutzerdefinierte Datentypen – Instanzen Methodische Aspekte der Ontologiekonstruktion – Überblick und Klassifikation von Vorgehensmodellen – Ansätze zur Ontologie-Evaluation Werkzeuge zur Ontologiekonstruktion und -Anwendung – Editoren und Visualisierungswerkzeuge – Rahmenwerke und Infrastrukturen
OWL
Michael Fellmann
120
Rahmenwerke und Infrastrukturen
Ein Framework ist eine Grundstruktur, ein Rahmenwerk. – Es erleichtert die Erstellung eigener Applikationen durch die Bereitstellung von Funktionen auf die über eine API zugegriffen werden kann. – Das Framework beeinflusst die Struktur der Applikation. – Im Zusammenhang der Ontologiekonstruktion decken unterschiedliche Frameworks unterschiedliche Bereiche ab. Ein Triplespeicher (Triplestore) bildet das Rückgrat vieler Semantic-Web-Anwendungen und ist daher eine wichtige Infrastruktukomponente. – Ein Tripelspeicher enthält wie eine relationale Datenbank Informationen. – Im Gegensatz zu relationalen Datenbanken werden diese nicht in Tabellen, sondern in Tripeln gespeichert (diese können in einem RDBS in eine einzige Tabelle gespeichert werden). – Es existieren Mischformen; einige Hersteller relationaler Datenbanken bieten Zusatzfunktionalitäten an (bspw. Oracle 11g unterstützt OWL 2 RL).
Ontologien > Werkzeuge
Begrifflichkeiten
Michael Fellmann
121
Rahmenwerke
Jena – Ist eine Java-API für RDF und OWL
Import und Export von RDF/XML, N3 und N-Triples,
– jena.sourceforge.net KAON (Karlsruhe Ontology and Semantic Web tool suite) – Enthält einen Ontologieeditor OI-Modeler und eine API für die Verwaltung von Ontologien in RDFS. – Eine Wissensakquisitionskomponente TextToOnto, die aus Texten in natürlich Sprache Ontologien erstellen kann. – Es existiert ein Nachfolger KAON2 der jedoch nicht abwärtskompatibel ist und sich vorallem in den unterstützten Sprachen (OWL-DL, F-Logic) von KAON unterscheidet. – kaon.sourceforge.net (KAON) bzw. kaon2.semanticweb.org (KAON2)
Ontologien > Werkzeuge
Jena, KAON
Michael Fellmann
122
Rahmenwerke
Sesame – Ursprung im On-To-Knowledge-Projekt. – Unterstützt mehrere Anfragesprachen, sowie die Eigenentwicklung SeRQL, die sich v.a. durch Anfragen auf TBox-Elemente auszeichnet. – Bietet API für lokalen und entfernten Zugriff (über HTTP und RMI) – www.openrdf.org OWLIM – Ist eine semantische Datenbank für Sesame. – Besonderes Augenmerk liegt auf Geschwindigkeit und Skalierbarkeit. – Es existiert eine Version SwiftOWLIM für besondere Performance und eine Version BigOWLIM für besondere Skalierbarkeit. – www.ontotext.com/owlim
Ontologien > Werkzeuge
Sesame, OWLIM
Michael Fellmann
123
Rahmenwerke
NeOn Toolkit – Ist ein Hauptbestandteil der Arbeit des NeOn-Projekts, an dem 14 europäische Länder beteiligt sind. – Soll den gesamten Lebenszyklus einer Ontologiekonstruktion unterstützend begleiten. – Es werden u.a. folgende Tätigkeiten unterstützt: Annotation und Dokumentation, Ontologieentwicklung, Wissensakquisition, Ontologieverwaltung, Evaluation, Wiederverwendung von Ontologien und anderen Wissensquellen. – neon-toolkit.org
Ontologien > Werkzeuge
NeOn Toolkit
Michael Fellmann
124
Schlussbetrachtung
Potenziale – Es wurden zahlreiche Ontologien in der Vergangenheit entwickelt, sodass aus inhaltlicher Perspektive ein gutes Fundament besteht. – Mit OWL existiert eine Ontologiesprache, die im Hinblick auf eine effiziente Interpretation und Schlussfolgerung durch Maschinen entworfen wurde und für viele Einsatzzwecke ausreichend ist. – Es existiert eine Vielzahl an teils bereits ausgereiften Werkzeugen zur Konstruktion, Analyse, Visualisierung und Verarbeitung von Ontologien. Probleme – Formale Wissensrepräsentationen erfordern oft nicht nur zu ihrer Erstellung, sondern auch zu ihrer Nutzung einige Expertise und damit Aufwand (durch Tools ggf. lösbar). – Die Wissensrepräsentationen müssen aktuell gehalten werden, da ihr Nutzen ansonsten zweifelhaft ist (durch Integration in Anwendungssysteme ggf. lösbar).
Ontologien
zu methodischen Aspekten und Werkzeugen
Michael Fellmann
125
Michael Fellmann
126
ANHANG – DL-Syntax
OWL
Syntaxkonverter von OWL/XML zur DL-Syntax, realisiert als Erweiterung von SemQuu Eingabe einer OWL- Ontologie in OWL/XML- Serialisierung Anzeige der Klassen- definitionen der TBox in DL-Syntax
Auf Fragen, Bugs und Anregungen freut sich: Michael.Fellmann@uos.de
Michael Fellmann
127
ANHANG – DL-Syntax
OWL
Quelle: Krötzsch, Hitzler, Rudolph (2008): Vorlesungsunterlagen zur Veranstaltung „Semantic Web Technologies I “ am AIFB, Universität Karlsruhe. Siehe auch: www.semantic-web-grundlagen.de
Übersicht
Michael Fellmann
128
ANHANG – DL-Syntax
OWL
Quelle: Krötzsch, Hitzler, Rudolph (2008): Vorlesungsunterlagen zur Veranstaltung „Semantic Web Technologies I “ am AIFB, Universität Karlsruhe. Siehe auch: www.semantic-web-grundlagen.de
Klassenkonstruktoren
Michael Fellmann
129
ANHANG – DL-Syntax
OWL
Quelle: Krötzsch, Hitzler, Rudolph (2008): Vorlesungsunterlagen zur Veranstaltung „Semantic Web Technologies I “ am AIFB, Universität Karlsruhe. Siehe auch: www.semantic-web-grundlagen.de
Axiome
Michael Fellmann
130
Michael Fellmann
131
Agenda
Anfragen an Ontologien – Anfrageebenen und -sprachen – DL-Anfragen – SPARQL
Michael Fellmann
132
Anfrageebenen
Syntaktische Ebene – Gegenstand der Anfrage sind syntaktische Strukturen, in Bezug auf OWL also die Serialisierung einer Ontologie in einer Syntax wie RDF/XML. – Beispiel für Anfragesprachen: XPath, XQuery.
Strukturelle Ebene – Gegenstand der Anfrage sind Strukturen, bei OWL wären dies die durch das RDF- „Datenmodell“ gegebenen Tripel. – Beispiel für eine Anfragesprache: SPARQL.
Semantische Ebene – Gegenstand der Anfrage sind die durch eine Logik wie z.B. SHOIN(D) als Grundlage von OWL-DL möglichen Aussagen. – Beispiel für eine Anfragesprache: RQL, Konjunktive Anfragen
132
Anfragen
…und Beispiele für Anfragesprachen
Michael Fellmann
133
Anfrageebenen
Syntaktische Ebene – Aufgrund der Abhängigkeit von der zur Serialisierung verwendeten Syntax und auch von Reihenfolge-Aspekten ist diese Ebene ungeeignet. Strukturelle Ebene – Pro: Werden als Struktur Tripel zugrunde gelegt, sind Anfragen intuitiv durch einfache Graphmuster möglich. Mit SPARQL existiert eine vom W3C standardisierte Sprache. – Contra: Bei einer Beschränkung auf Strukturen wie Tripel und der Auslassung von Schema-Information sind manche Anfragen nur umständlich zu formulieren (das Problem kann durch die Verwendung von Inferenzmaschinen gemildert werden, die zulässige Schlüsse vor der Anfrage „materialisieren“, d.h. der Ontologie hinzufügen). Semantische Ebene – Pro: Eine Abstraktion von Strukturen ermöglicht Anfragen auf logischer Ebene. – Contra: Die Komponente, die Anfragen auswertet, benötigt eine eigene Inferenzmaschine, um Schema-Informationen zu berücksichtigen. Anfragesprachen wie konjunktive Anfragen sind bisher wenig standardisiert.
133
Anfragen
Welche Ebene ist zweckmäßig für (OWL-)Ontologien?
Michael Fellmann
134
Überblick über Anfragesprachen
Bisher wurden zahlreiche Anfragesprachen vorgeschlagen: Algae, eRQL, iTQL, Metalog, N3QL, OWL-QL, R-DEVICE, RDF Path, RDF Twig, RDF- QBE, RDFQL, RDFT, RDQL, RPath, RQL, RxPath, RxSLT, RxUpdate, SeRQL, SPARQL, SquishQL, SWQL, SQWRL, TRIPLE, TriQL, Versa, WQL, Xcerpt, XsRQL und Weitere. Merkmale zur Charakterisierung (nach Broekstra, Kapman, Harmelen 2005) – Einsatzgebiet (z.B. XML, Semantic Web, KI) – Zugehörigkeit zu einer bestimmten Sprachfamilie
– Funktionalität der Anfragesprache Weitere Merkmale – Datenintegration (z.B. Semantic Web Query Language (SWQL)) – Visualisierung (z.B. TRIPLE Views, visCerpt) – Nutzung der natürlichen Sprache (z.B. ACE-basierte konjunktive Anfragen) – Fragenbeantwortung (z.B. OWL-QL).
134
Anfragen
Anfrage auf semantischer Ebene im Kontext von OWL
Michael Fellmann
135
Agenda
Anfragen an Ontologien – Anfrageebenen und -sprachen – DL-Anfragen – SPARQL
Michael Fellmann
136
DL-Anfragen
Eigenschaften von DL-Anfragen – Grundsätzlich sind DL-Anfragen vergleichbar mit definierten Klassen in einer Beschreibungslogik, d.h. es wird eine Konzeptbeschreibung erstellt. – Mit der DL-Anfrage wird dann (ggf. unter Zuhilfenahme einer Inferenzmaschine) ermittelt, welche Objekte (Klassen, Individuen) von dieser Beschreibung subsumiert werden – d.h. in ihr mengenmäßig enthalten sind. Ein erstes Beispiel: – Natürliche Sprache: Welches Objekt unterstützt mindestens ein strategisches Ziel? – Protégé-Syntax: supportsGoal some StrategicGoal – DL-Syntax:
136
supportsGoal.StrategicGoal ∃ ∃ ∃ ∃
Anfragen > DL-Anfragen
Grundlegendes
Michael Fellmann
137
DL-Anfragen mit Protégé
137
Anfrage starten Ergebnis- Bereich Eingabe der Konzept- beschrei- bung Umfang der Ergebnisse
Anfragen > DL-Anfragen
Benutzeroberfläche
Michael Fellmann
138
DL-Anfragen
Herstellbare Produkte (und Produktklassen) mit einer DL-Anfrage ermitteln: – Natürliche Sprache: Gesucht werden herstellbare Produkte und -Produktklassen, für die gilt: Alle Produkte bestehen ausschließlich aus Teilen, für die ein interner oder externer Lieferant bekannt ist und weisen ausschließlich Produktionsschritte auf, für die ein interner oder externer Agent zur Verfügung steht. – Protégé-Syntax: hasPart only (hasSupplier some (ExternalSupplier or InternalSupplier)) and hasProductionStep only (hasAgent some (ExternalAgent or InternalAgent)) – DL-Syntax:
138
hasPart.( hasSupplier.(ExternalSupplier InternalSupplier)) hasProductionStep.( hasAgent.(ExternalAgent InternalAgent)) ∀ ∃ ∀ ∃ ⊔ ⊓ ⊔
Anfragen > DL-Anfragen
Weiteres Beispiel
Michael Fellmann
139
Agenda
Anfragen an Ontologien – Anfrageebenen und -sprachen – DL-Anfragen – SPARQL
Michael Fellmann
140
SPARQL
Begriff, Standardisierung – SPARQL steht für „SPARQL Query Language for RDF“ – Es handelt sich um einen W3C-Standard (Prud'hommeaux, Seaborne 2006), der gegenwärtig (Sommer 2010) überarbeitet wird zur Version 1.1. Merkmale von SPARQL – SPARQL ermöglicht Anfragen auf einer strukturellen Ebene basierend auf der Graph-Struktur der RDF-Tripel. – Im RDF-Graphen können Muster gefunden werden, wozu u.a. Variablen und Konstrukte für optionale Bereiche
– SPARQL besitzt eine (entfernt) an SQL erinnernde Syntax mit Schlüsselwörtern wie SELECT, FROM, WHERE, ORDER BY etc.
140
w3.org/TR/rdf-sparql-query
Anfragen > SPARQL
Grundlegendes
Michael Fellmann
141
SPARQL
Schematischer Aufbau einer einfachen SPARQL-Anfrage SELECT ?var1 ... ?varN WHERE { pattern1 . pattern2 . ... . patternN . } – Zunächst werden im Anschluss an SELECT diejenigen Variablen ausgewählt, die als Rückgabewerte der Anfrage dienen. – Anschließend wird mit Hilfe von WHERE ein Muster bestehend aus Tripeln formuliert, das zur Suche im RDF-Graphen verwendet wird.
spezifizierbar. – SPARQL unterstützt ebenfalls Namensräume, diese werden zu Beginn (vor SELECT) im Format PREFIX prefixname: <URI> notiert.
141
Anfragen > SPARQL
Struktur von Anfragen
Michael Fellmann
142
SPARQL – Daten für Beispielanfragen
142
Anfragen > SPARQL
Visualisierung als Graph
Michael Fellmann
143
SPARQL – Daten für Beispielanfragen
143
@prefix vCard : <http://www.w3.org/2001/vcard-rdf/3.0#> . @prefix : <http://example.org/process#> . :capture_order :hasAvgDuration "8" ; :hasResponsibleAgent [ vCard:Family "Jones" ; vCard:Given "Matthew" ] . :approve_order :hasAvgDuration "5" ; :hasResponsibleAgent [ vCard:Family "Smith" ; vCard:Given "Rebecca" ] . :ship_goods :hasAvgDuration "25" ; :hasResponsibleAgent [ vCard:Family "Smith" ; vCard:Given "John" ] . :write_invoice :hasResponsibleAgent [ vCard:Family "Jones" ; vCard:Given "Sarah" ] .
Anfragen > SPARQL
Darstellung in Turtle-Notation
Michael Fellmann
144
Graphmuster
Gebe eine Liste mit allen Aktivitäten aus – Anfrage: PREFIX : <http://example.org/process#"> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#"> SELECT ?activity WHERE { ?activity rdf:type :Activity } – Ergebnis:
144
activity :capture_order :approve_order :ship_goods :write_invoice
Hinweis: Präfixe werden im Folgenden nur bei ihrer ersten Verwendung deklariert. Abkürzung von „rdf:type“ durch „a“ möglich!
Anfragen > SPARQL
Beispiele für einfache Graphmuster
Michael Fellmann
145
Graphmuster
Suche von Aktivitäten mit der Bearbeitungsdauer von 5 Zeiteinheiten – Anfrage: PREFIX : <http://example.org/process#"> SELECT ?activity WHERE { ?activity :hasAvgDuration "5" } – Ergebnis:
145
activity :approve_order
Anfragen > SPARQL
Beispiele für einfache Graphmuster
Michael Fellmann
146
Graphmuster
Gebe alle Aktivitäten mit ihren Bearbeitungsdauern aus – Anfrage: SELECT ?activity ?duration WHERE {?activity :hasAvgDuration ?duration} – Ergebnis:
146
activity duration :capture_order 8 :approve_order 5 :ship_goods 25
Anfragen > SPARQL
Beispiele für einfache Graphmuster
Michael Fellmann
147
Graphmuster
Gebe eine Liste der Geburtsnamen aller Personen aus, die „Smith“ heißen – Anfrage: PREFIX vCard: <http://www.w3.org/2001/vcard-rdf/3.0#> SELECT ?givenName WHERE { ?y vCard:Family "Smith" . ?y vCard:Given ?givenName . } – Ergebnis:
147
givenName John Rebecca
Anfragen > SPARQL
Nutzung von Variablen als Platzhalter
Michael Fellmann
148
Filter
Suche alle Aktivitäten, die mehr als 10 Zeiteinheiten benötigen – Anfrage: SELECT ?activity WHERE { ?activity :hasAvgDuration ?duration . FILTER (?duration >= 10) } – Ergebnis:
148
activity ship_goods
Anfragen > SPARQL
Beispiel: Numerischer Vergleich
Michael Fellmann
149
Filter
Gebe alle Geburtsnamen aus, die ein „r“ oder „R“ enthalten – Anfrage: SELECT ?givenName WHERE { ?x vCard:Given ?givenName . FILTER regex(?givenName, "r", "i") } – Ergebnis:
149
givenName Rebecca Sara „i“ = Ohne Groß- und Kleinschreibung (case insensitive)
Anfragen > SPARQL
Beispiel: Nutzung Regulärer Ausdrücke
Michael Fellmann
150
Filter
Vergleichsoperatoren – Notation: = (gleich), < (kleiner), <= (kleiner/gleich), > (größer), >= (größer/gleich), != (ungleich), && (und), || (oder), ! (Negation) – Wirkung: Entsprechend den Datentypen wie xsd:string, xsd:integer, xsd:date, xsd:dateTime, xsd:boolean. Spezielle Operatoren BOUND(?x) true falls Variable ?x gebunden. isURI(?x) true falls der Wert von ?x ein URI ist. LANG(?x) liefert den Sprachcode eines an ?x gebundenen RDF-Literals. DATATYPE(?x) liefert die URI des Datentyp eines an ?x gebundenen RDF-Literals. REGEX(?x,?y) true falls in ?x der reguläre Ausdruck ?y gefunden wird. Weitere Vergleiche und Operatoren: www.w3.org/TR/rdf-sparql-query/#tests
150
Anfragen > SPARQL
Weitere Operatoren
Michael Fellmann
151
Optionale Graphmuster
Gebe eine Liste mit Verantwortungsträgern und Zeiten (wenn bekannt) aus – Anfrage: SELECT ?activity ?agent ?duration WHERE { ?activity :hasResponsibleAgent ?x . ?x vCard:Family ?agent . OPTIONAL {?activity :hasAvgDuration ?duration } } – Ergebnis:
activity agent duration :capture_order Jones 8 :approve_order Smith 5 :ship_goods Smith 25 :write_invoice Jones
Anfragen > SPARQL
Graphmuster, die nicht zwingend erfüllt werden müssen
Michael Fellmann
152
Optionale Graphmuster
Gebe eine Liste mit Verantwortungsträgern aus u. optional den Zeiten, falls größer 5 – Anfrage: SELECT ?activity ?agent ?duration WHERE { ?activity :hasResponsibleAgent ?x . ?x vCard:Family ?agent . OPTIONAL { ?activity :hasAvgDuration ?duration . FILTER (?duration > 5) } } – Ergebnis:
152
activity agent duration :capture_order Jones 8 :approve_order Smith :ship_goods Smith 25 :write_invoice Jones
Anfragen > SPARQL
Kombination mit Filtern
Michael Fellmann
153
Optionale Graphmuster
Gebe eine Liste mit Aktivitäten und deren Verantwortlichen aus, für die keine Bearbeitungszeiten bekannt sind, oder diese länger als 20 Zeiteinheiten sind – Anfrage: SELECT ?acitvity ?agent ?duration WHERE { ?activity :hasResponsibleAgent ?x . ?x vCard:Family ?agent . OPTIONAL { ?activity :hasAvgDuration ?duration } . FILTER ( !bound(?duration) || ?duration > 20 ) } – Ergebnis:
153
activity agent duration :ship_goods Smith 25 :write_invoice Jones
Anfragen > SPARQL
Ungebundene Variablen oder Werte als Filterkriterium
Michael Fellmann
154
Optionale Graphmuster
Verwendung von OPTIONAL – OPTIONAL bezieht sich immer auf genau ein nachfolgendes Muster { … } – OPTIONAL bezieht sich auf die gesamten, links von ihm befindlichen Bereich, d.h. es ist linksassoziativ. – Mehrere OPTIONAL-Bereiche werden unabhängig voneinander getestet – treten Variablen jedoch nur in OPTIONAL-Zweigen auf (d.h. nicht im Basismuster außerhalb der Optional-Bereiche), so können sich die Variablen gegenseitig beeinflussen.
Anfragen > SPARQL
Hinweise
Michael Fellmann
155
Alternative Graphmuster
Gebe eine Liste mit Aktivitäten und deren Verantwortlichen aus – Annahme: Die Namen der Verantwortlichen können entweder mit dem FOAF- Vokabular oder dem vCard-Vokabular gespeichert werden. – Anfrage: SELECT ?agent ?activity WHERE { ?activity :hasResponsibleAgent ?x . { ?x foaf:name ?agent } UNION { ?x vCard:Family ?agent } } – Ergebnis:
155
agent activity Smith :capture_order Smith :capture_order Jones :approve_order ... ... Dubletten bei mehreren Variablen-Bindungen!
Anfragen > SPARQL
Vereinigung von Ergebnismengen
Michael Fellmann
156
Alternative Graphmuster
Gebe eine Liste mit Aktivitäten und deren Verantwortlichen aus – Annahme: Die Namen der Verantwortlichen können entweder mit dem FOAF- Vokabular oder dem vCard-Vokabular gespeichert werden. – Anfrage: SELECT DISTINCT ?agent ?activity WHERE { ?activity :hasResponsibleAgent ?x . { ?x foaf:name ?agent } UNION { ?x vCard:Family ?agent } } – Ergebnis:
156
agent activity Smith :capture_order Jones :approve_order ... ...
Anfragen > SPARQL
Vereinigung von Ergebnismengen
Michael Fellmann
157
Alternative Graphmuster
Verwendung von UNION – UNION bezieht sich immer auf genau ein nachfolgendes Muster { … }. – UNION bezieht sich auf die gesamten, links von ihm befindlichen Bereich, d.h. es ist linksassoziativ. – Mehrere UNION-Bereiche werden unabhängig voneinander getestet – treten Variablen nur in OPTIONAL-Zweigen auf (d.h. nicht im Basismuster außerhalb der Optional-Bereiche), so können sie voneinander unabhängig gebunden werden, d.h. die Variablen beeinflussen sich nicht gegenseitig.
Anfragen > SPARQL
Hinweise
Michael Fellmann
158
Gruppierung von Optionen und Alternativen
Gleichheit von Optionen und Alternativen – Die Schlüsselwörter OPTIONAL und UNION sind gleichwertig. – Es besteht kein Vorrang eines Operators vor einem anderen. OPTIONAL und UNION sind linksassoziativ – Bespiel ohne explizite Klammerung { {s1 p1 o1} OPTIONAL {s2 p2 o2} UNION {s3 p3 o3} OPTIONAL {s4 p4 o4} OPTIONAL {s5 p5 o5} } – Gleichbedeutendes Bespiel mit expliziter Klammerung {{{{{s1 p1 o1} OPTIONAL {s2 p2 o2} } UNION { s3 p3 o3} } OPTIONAL {s4 p4 o4} } OPTIONAL {s5 p5 o5} }
Quelle: Hitzler et al. (2008): Semantic Web. Springer : Berlin, S. 211 ff.
Anfragen > SPARQL
Gleichheit und Linksassoziativität
Michael Fellmann
159
SPARQL
Gegeben sind die folgenden Daten (in N3-Notation, belieb. Namensraum): schicke_werbung erfordert kundendaten . kundendaten gespeichertIn crm_system . erstelle_rechnung erfordert stammdaten . erstelle_rechnung erfordert bestelldaten . stammdaten gespeichertIn erp_system . bestelldaten gespeichertIn erp_system . erp_system erfordert db1 . Erstellen Sie SPARQL-Anfragen zur Beantwortung der folgenden Fragen:
und wovon sind diese ggf. abhängig?
159
Anfragen > SPARQL
Übung
Michael Fellmann
160
Weitere Möglichkeiten von SPARQL
Lösungsmodifikationen – Sortierung mit ORDER BY
– Ausschnitt aus der Ergenismenge mit OFFSET und LIMIT
– Eindeutige Variablen-Werte-Kombinationen mit DISTINCT
Beispiel SELECT DISTINCT ?name WHERE {?x foaf:name ?name} ORDER BY DESC(?name) LIMIT 5 OFFSET 10
160
Anfragen > SPARQL
Lösungsmodifikatoren
Michael Fellmann
161
Weitere Möglichkeiten von SPARQL
Kombination mehrerer Graphen in einer Anfrage – Mit dem Schlüsselwort FROM können weitere Graphen angegeben werden. – Mit dem Schlüsselwort FROM NAMED kann eine Graph (eine Datenquelle) innerhalb einer Anfrage benannt werden. – Innerhalb der Anfrage kann mit dem Schlüsselwort GRAPH und der Angabe einer Variablen der Name des Graphen ausgelesen werden. Beispiel PREFIX foaf: <http://xmlns.com/foaf/0.1/> SELECT ?src ?myNick FROM NAMED <http://example.org/foaf/friends> FROM NAMED <http://another.example.org/foaf/friends> WHERE { GRAPH ?src {?x foaf:mbox <mailto:bob@work.example> . ?x foaf:nick ?myNick} }
161
Anfragen > SPARQL
Benannte Graphen
Michael Fellmann
162
Weitere Anfrageformen
ASK – Verwendung, wenn nur eine Ja/Nein-Antwort erforderlich ist. – Beispiel: ASK { :erstelle_rechnung rdf:type :Activity } DESCRIBE – Verwendung, wenn alle Fakten über ein Objekt zurückgegeben werden sollen. – Beispiel: DESCRIBE :erstelle_rechnung Weitere Anfrageformen und deren Verwendung – CONSTRUCT: Konstruktion von Graphen im Kontext von Anfragen. – UPDATE: Änderung von Fakten. – INSERT DATA: Eingabe von Fakten. – DELETE: Löschung von Fakten.
162
Jena/ARQ-spezifisch
Anfragen > SPARQL
ASK, DESCRIBE und Weitere
Michael Fellmann
163
Abkürzungen in SPARQL-Anfragen
Mehrere Graphmuster mit gleichem Subjekt – Beispiel Langform: s1 p1 o1 . s1 p2 o2 . – Beispiel Kurzform: s1 p1 o1 ; p2 o2 . Mehrere Graphmuster mit gleichem Subjekt und Prädikat – Beispiel Langform: s1 p1 o1 . s1 p1 o2 . – Beispiel Kurzform: s1 p1 o1 , o2 . Graphmuster mit anonymem Knoten – Anonyme Knoten können an der Subjekt- oder Objekt-Position eines Graphmusters
– Beispiel Langform: s1 p1 o1 . o1 p2 o2 . – Beispiel Kurzform: s1 p1 [ p2 o2 ] .
Anfragen > SPARQL
Abkürzungen der N3-Syntax sind anwendbar
Michael Fellmann
164
Abkürzungen in SPARQL-Anfragen
Kombination der Abkürzungen – Beispielanfrage: „Finde Funktionen und deren übergeordnete Organisationseinheiten (mit Name und ID), an denen die Organisationseinheit :vorstand beteiligt ist.“ – Langform: SELECT ?func ?nameSuperOrg ?idSuperOrg WHERE { ?func :hasOrg ?org1 . ?org1 :isSubOrgOf ?org2 . ?org2 :hasName ?nameSuperOrg . ?org2 :hasID ?idSuperOrg . ?func :hasOrg :vorstand . } – Kurzform: SELECT ?func ?nameSuperOrg ?idSuperOrg WHERE { ?func :hasOrg [ :isSubOrgOf [ :hasName ?nameSuperOrg ; :hasID ?idSuperOrg ] ] , :vorstand . }
Anfragen > SPARQL
Abkürzungen der N3-Syntax sind anwendbar
Michael Fellmann
165
SPARQL mit SemQuu praktisch anwenden
165
URI der Ontologie SPARQL Anfragen Optionen zur Validierung Optionen für Anfragen Ergebnis- Bereich
Auf Fragen, Bugs und Anregungen freut sich: Michael.Fellmann@uos.de
Anfragen > SPARQL
Download im „Dateien“-Bereich der Vorlesung! Regeln erfassen u. speichern SPARQL Anfragen mit Vorschlags- Funktion
Michael Fellmann
166
Schlussbemerkung
Anfragesprachen – Es existiert eine Vielfalt an Anfragesprechen. – Für OWL sind derzeit vor allem DL-Anfragen und SPARQL-Anfragen relevant
zur Anfrage eingesetzt werden sollen.
Rückgabe als Tabellen intendiert werden. – Zur Anfrage in semantischen Wikis werden teils eigene Sprachen wie SMW-QL
166
zu Anfragesprachen
conceptualization shared semantics formal menatal model explicit domain
Michael Fellmann
Institut für Informationsmanagement und Unternehmensführung michael.fellmann@uos.de
Conceptualization Formal Ontology Restriction Shared
Triple Pattern
Explicit
TBox/ABox
Inference