• Like
  • Save
Die "Semantic Web Recommendations" und das Jena Framework
Upcoming SlideShare
Loading in...5
×
 

Die "Semantic Web Recommendations" und das Jena Framework

on

  • 1,561 views

Semantic Web: Nach dem Web 2.0 ein neues Schlagwort das für die Weiterentwicklung des World Wide Web stehen soll. ...

Semantic Web: Nach dem Web 2.0 ein neues Schlagwort das für die Weiterentwicklung des World Wide Web stehen soll.
In diesem Paper geht es um die Empfehlungen des W3C für das Semantic Web und um eine Implementierung dieser Semantic Web Recommendations, das Jena Framework.

Dieses Paper wurde im Rahmen des Proseminars "Softwarequalität und -sicherheit" an der Universität Paderborn erstellt.

Der dazugehörige Seminarvortrag:
http://www.slideshare.net/jmaicher/die-semantic-web-recommendations-und-das-jena-framework-4808117

Statistics

Views

Total Views
1,561
Views on SlideShare
1,560
Embed Views
1

Actions

Likes
1
Downloads
0
Comments
1

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • Hallo Julian, besteht auch die Möglichkeit neben der Präsentation deine Seminar-Arbeit 'Semantic Web Recommendations' und das Java Framework' nachzulesen?

    Grüße
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Die "Semantic Web Recommendations" und das Jena Framework Die "Semantic Web Recommendations" und das Jena Framework Document Transcript

    • Fakult¨t f¨r Elektrotechnik, Informatik und Mathematik a u Heinz Nixdorf Institut und Institut f¨r Informatik u Fachgebiet Softwaretechnik Warburger Straße 100 33098 Paderborn Die Semantic Web ” Recommendations“ und das Jena Framework Seminar-Ausarbeitung im Rahmen des Studiengangs Informatik und des Pro-Seminars Softwarequalitat und -sicherheit 2010 ¨ von Julian Maicher Br¨derstraße 4 u 33098 Paderborn vorgelegt bei Prof. Dr. Wilhelm Schafer ¨ Paderborn, August 2010
    • Inhalt 1 Einleitung 1 1.1 Das World Wide Web: Eine Bestandsaufnahme . . . . . . . . . . 1 1.2 Das Semantic Web: Eine Vision . . . . . . . . . . . . . . . . . . . 2 2 Die Semantic Web Recommendations 3 2.1 Unified Resource Identifier . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Resource Description Framework . . . . . . . . . . . . . . . . . . 4 2.3 RDF Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Web Ontology Language . . . . . . . . . . . . . . . . . . . . . . . 7 2.5 SPARQL Protocol and RDF Query Language . . . . . . . . . . . 8 2.6 Zusammenfassung und Ausblick . . . . . . . . . . . . . . . . . . . 9 3 Das Jena Framework 10 3.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 RDF-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3.1 Input/Output . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.4 Ontology-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.5 Query-API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.6 Fazit und Praxiserfahrungen . . . . . . . . . . . . . . . . . . . . . 16 4 Zusammenfassung 17 4.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Literatur 19 ii
    • 1 Einleitung Das World Wide Web (WWW) hat in seiner Entwicklung verschiedene Trends und Entwicklungen durchlebt. Angefangen hat die Entwicklung mit dem, was heute als Web 1.0 bezeichnet wird. Ein entscheidendes Merkmal von Webseiten aus dieser Generation ist, dass Anbieter und Benutzer einer Webseite in einem reinen Produzenten-Konsumenten Verh¨ltnis stehen. Der Webseitenanbieter stellt Daten auf der Webseite zur Verf¨gung a u und diese werden von dem Benutzer konsumiert. Anfang des 20. Jahrhunderts wurde das Schlagwort Web 2.0 gepr¨gt und steht a seither f¨r eine Generation von interaktiven und kollaborativen Webseiten. Der Be- u nutzer bricht aus seiner klassischen Rolle als Konsument und kann neben der Ver- arbeitung auch Daten f¨r sich und andere Benutzer erstellen. Ihm wird erm¨glicht, u o die Rolle des Konsumenten und des Produzenten auf einer Webseite einzunehmen. Das Semantic Web gilt als neuer Trend im WWW. Im Vordergrund steht hier nicht das Nutzerverhalten oder die Herkunft von Daten, sondern die logische und semantisch richtige Auszeichnung von Daten. In dieser Arbeit geht es um die Semantic Web Recommendations, eine Empfeh- lungen des World Wide Web Consortium (W3C), und das Jena Framework, eine Implementierung der Empfehlungen des W3C. 1.1 Das World Wide Web: Eine Bestandsaufnahme Das WWW wird auch als Web of documents“ [W3C10] bezeichnet. Es ist ein ” Netz aus verkn¨pften Dokumenten, die prim¨r f¨r die Verarbeitung durch den u a u Menschen ausgelegt sind [BA10]. Dokumente im WWW basieren haupts¨chlich auf der Auszeichnungssprache a Hypertext Markup Language (HTML) und der Stylesheet-Sprache Cascading Sty- ¨ le Sheets (CSS). HTML kann zwar grundlegende Elemente wie zum Beispiel Uber- ¨ schriften oder Paragraphen unterscheiden, allerdings kann einer Uberschrift oder einem Paragraphen keine weitere semantische Bedeutung zugeordnet werden. Aufgrund dieser Einschr¨nkung kann die Semantik von Daten innerhalb von a Dokumenten maschinell ohne weiteres nicht interpretiert werden. Der Mensch kann sich hingegen aus dem Kontext und der visuellen Aufbereitung des Dokumentes die Bedeutung von Daten erschließen. Die Problematik der maschinellen Interpretation von Semantik f¨hrt zu wei- u teren Problemen wie z.B. bei der Suche nach Daten. Oftmals k¨nnen semantisch o relevante Informationen von Suchalgorithmen nicht gefunden werden, da sie in kei- 1
    • 1.2 Das Semantic Web: Eine Vision nem Kontext zu dem gesuchten Datum stehen. Die Suche im WWW beschr¨nkt a sich auf eine Stichwort- oder Patternsuche. 1.2 Das Semantic Web: Eine Vision Die Vision des Semantic Web stammt von Tim Berners-Lee, der als Erfinder“ ” des WWW gilt und sowohl Gr¨nder als auch Vorstandsmitglied des W3C ist. u Er verfolgt das Ziel, aus dem Web of documents“ das Web of data“ zu machen ” ” [W3C10]. Ein Netzwerk von Daten, die auf Basis ihrer Bedeutung miteinander verkn¨pft sind und dessen Semantik maschinell interpretierbar ist. u Durch eine klare Definition der Semantik von Daten, Eigenschaften, Beziehun- gen und logischen Regeln ergeben sich eine vielzahl von M¨glichkeiten. Ein gutes o Beispiel daf¨r ist die Suche nach Daten. Maschinen k¨nnen semantische Zusam- u o menh¨nge zwischen Daten erkennen und somit die Suchergebnisse hinsichtlich a ihrer Relevanz verbessern. Außerdem wird es Maschinen erm¨glicht, eigenst¨ndig o a neues Wissen durch logische Schl¨sse zu erschließen. u Zur Erreichung dieser Ziele hat das W3C die Semantic Web Activity 1 gegr¨ndet. u Dabei handelt es sich um eine aktive Arbeitsgruppe, die Standards f¨r die Imple- u mentierung eines Semantic Web empfiehlt, die Semantic Web Recommendations. Im Rahmen dieser Arbeit werden zun¨chst die Semantic Web Recommendations a erl¨utert. Darauf aufbauend wird das Jena Framework vorgestellt, ein Framework, a welches die Empfehlungen des W3C umsetzt und bei der Implementierung eines Semantic Web unterst¨tzen soll. u 1 Semantic Web Activity: http://www.w3.org/2001/sw 2
    • 2 Die Semantic Web Recommendations Die Semantic Web Recommendations beinhalten Empfehlungen f¨r die Umsetzung u eines Semantic Web. Um den Anforderungen an ein Semantic Web gerecht zu werden, muss zun¨chst a eine Syntax zur einheitlichen Beschreibung und Speicherung von Daten gefunden werden. Um einen hohen Grad an Flexibilit¨t zu gew¨hrleisten, sollte diese Syntax a a frei von Semantik sein. So wird erm¨glicht, dass Daten innerhalb von unterschied- o lichen Kontexten verschiedene Bedeutungen haben k¨nnen. Ein Beispiel daf¨r ist o u die Ehe-Beziehung in verschiedenen Kulturen. Die Semantik der Daten sollte des- halb in einer unabh¨ngigen Syntax beschrieben werden. Weiterhin ist es wichtig, a dass eine Schnittstelle zur Abfrage von Daten bereit gestellt wird. Abbildung 2.1 visualisiert die von der Semantic Web Activity-Gruppe ver¨ffent- o lichten Empfehlungen. Daten werden als Ressourcen beschrieben und k¨nnen uber einen Unified Re- o ¨ source Identifier (URI) identifiziert werden. Eine Ressource kann alles repr¨sentie- a ren: Eine bestimmte Person, ein Haus, eine Internetseite oder auch einen Planeten. Zur Beschreibung und als Austauschformat von Ressourcen empfiehlt das W3C die abstrakte Syntax des Resource Description Framework (RDF)1 . Diese Syntax basiert auf XML, ist frei von Semantik und dient als universelle Datenstruktur. Als unabh¨ngige Syntax zur Beschreibung von Semantik wird RDF Schema a (RDFS) und die Web Ontology Language (OWL) empfohlen. Die Semantic Web Activity hat weiterhin die SPARQL Protocol and RDF Query Language (SPAR- QL) als Anfragesprache entwickelt. Auf Unified Resource Identifier, das Resource Description Framework, RDF Schema, die Web Ontology Language und auf SPARQL wird im Folgenden n¨her a eingegangen. Die Schichten Rule: RIF, Crypto, Unifying Logic, Proof, Trust und User Interface & Applications sind f¨r das grundlegende Verst¨ndnis des Jena u a Framework s nicht erforderlich. Daher werden diese Schichten im Rahmen dieser Arbeit nur der Vollst¨ndigkeit halber erw¨hnt. a a 2.1 Unified Resource Identifier Ein URI identifiziert eine Internetressource eindeutig und enth¨lt keinerlei se- a mantische Informationen uber die dazugeh¨rige Ressource. Als Unterart von URI ¨ o 1 RDF Syntax Specification http://www.w3.org/TR/rdf-syntax-grammar 3
    • 2.2 Resource Description Framework Abbildung 2.1: Layercake der Semantic Web Recommendations, Quelle: http: // www. w3. org/ 2001/ sw identifiziert und lokalisiert ein Uniform Resource Locator (URL) zum Beispiel eine Ressource uber das Netzwerkprotokoll (z.B. HTTP) und den Ort der Ressource ¨ (z.B. uber die IP-Adresse des Servers). Beim t¨glichen Surfen im Internet werden ¨ a URLs, also URIs zum Ansteuern von Webseiten verwendet. Ein weiteres Beispiel f¨r eine URI in der t¨glichen Verwendung sind E-Mail Adressen. u a Internationalized Resource Identifier (IRI) sind eine Internationalisierung der URI und erlauben fast alle Zeichen des Unicode Standards. Eine URI k¨nnte beispielsweise innerhalb von RDF die Person John Doe“ o ” identifizieren. 2.2 Resource Description Framework Als universelle Datenstruktur erm¨glicht RDF die Beschreibung von Informatio- o nen und dient als Standard zum Datenaustausch. RDF/XML verwendet zur Beschreibung von Informationen eine Triple-Syntax [Bec10]. Wie im deutschen Satzbau werden Informationen mittels Subjekt (S), Pr¨dikat (P) und Objekt (O) beschrieben, so dass ein Triple (S, P, O) entsteht. a 4
    • 2.2 Resource Description Framework Das Subjekt innerhalb eines Triples ist ein Datum, uber das eine Aussage ge- ¨ troffen werden soll. Dieses Datum wird innerhalb von RDF durch eine Ressource repr¨sentiert und wird uber ihren URI angegeben. Ein Pr¨dikat wird ebenfalls a ¨ a uber ihren URI identifiziert und beschreibt entweder eine Relation zwischen zwei ¨ Ressourcen oder eine Zuweisung eines Datenwertes zu einem Attribut des Sub- jektes. Daher kann es sich bei dem Objekt ebenfalls um eine Ressource oder um ein Literal handeln. Ein Literal kann einen festen Datentyp haben (Typed Literal ) oder einen universellen Datentyp, der alle unterst¨tzten Datenwerte (siehe dazu u [Bec10]) speichern kann (Plain Literal ). Zum besseren Verst¨ndnis folgt ein kurzes Beispiel. Die Person John Doe“ a ” wird innerhalb von RDF durch eine Ressource mit der URI http://.../John Doe repr¨sentiert. Diese Ressource hat ein Attribut family name. Nun kann die Aus- a sage John Doe hat Familienname Doe‘“ getroffen werden. Beispiel 2.1 zeigt, wie ” ’ diese Aussage mit RDF/XML repr¨sentiert werden kann. a <h t t p : / / . . . / John Doe> <family name> <’Doe’> Beispiel 2.1: RDF-Tripel zu John Doe hat Familienname Doe‘“ ” ’ Das Subjekt ist in diesem konkreten Fall die Ressource http://.../John Doe, das Attribut family name ist das Pr¨dikat und das Objekt ist ein Stringliteral a mit dem Wert Doe. Wie in Abbildung 2.2 zu sehen ist, l¨sst sich das Tripel aus dem Beispiel als a Graph visualisieren. http://../John_Doe family_name Doe Abbildung 2.2: Grafische Repr¨sentation von John Doe hat Familienname Doe‘“ a ” ’ Subjekt und Objekt werden durch Knoten repr¨sentiert, wobei Ressourcen als a Ellipse und Literale als Rechteck gekennzeichnet werden. Pr¨dikate werden als a Pfeil in Richtung des Objektes visualisiert. Die Gesamtheit aller Tripel formt den RDF-Graphen. Innerhalb des RDF-Graphen sind Ressourcen als Knoten einmalig. Sie erhalten als Subjekt innerhalb eines Tri- pels eine Ausgangs- und als Objekt eine Eingangskante. 5
    • 2.3 RDF Schema 2.3 RDF Schema RDF bietet eine allgemeine M¨glichkeit Ressourcen zu beschreiben. Es ist jedoch o nicht m¨glich Ressourcen zu klassifizieren oder mit spezifischen Eigenschaften zu o beschreiben. RDF Schema ist eine semantische Erweiterung von RDF und stellt ein Vokabu- lar zur Verf¨gung um diesen Anforderungen gerecht zu werden. u RDFS bietet ein Klassen- und Typkonzept. Um Ressourcen zu klassifizieren k¨nnen durch das RDFS-Vokabular Klassen erstellt und mit Hilfe der RDF-Eigenschaft o rdf:type einzelnen Ressourcen zugewiesen werden. Da RDFS eine Erweiterung von RDF ist, werden Klassen ebenfalls als Ressource mit dem Typ rdfs:class defi- niert. Die Vorgehensweise bei der Klassifizierung von Ressourcen erinnert stark an Konzepte bei der Objekt-orientierten Programmierung [DB10]. Um eine Klasse weiter zu spezialisieren, kann eine Unterklasse erstellt werden, die von der weniger speziellen Klasse erbt. Diese Beziehung zwischen Klassen l¨sst sich mit Hilfe der a Eigenschaft rdfs:isSubClassOf ausdr¨cken. u Zur Semantischen Erweiterung kann nun der Ressource http://.../John Doe aus Beispiel 2.1 die Klasse Human und spezieller die Klasse Man zugeordnet werden. Offensichtlich ist Man eine spezielle Form von Human. Siehe dazu Beispiel 2.2. <r d f : D e s c r i p t i o n r d f : ID=" Human "> <r d f : t y p e r d f : r e s o u r c e=" http ://.../ rdf - schema # Class "/> </ r d f : D e s c r i p t i o n > <r d f : D e s c r i p t i o n r d f : ID=" Man "> <r d f : t y p e r d f : r e s o u r c e=" http ://.../ rdf - schema # Class "/> <r d f s : s u b C l a s s O f r d f : r e s o u r c e=" # Human "/> </ r d f : D e s c r i p t i o n > <r d f : D e s c r i p t i o n r d f : ID=" Woman "> <r d f : t y p e r d f : r e s o u r c e=" http ://.../ rdf - schema # Class "/> <r d f s : s u b C l a s s O f r d f : r e s o u r c e=" # Human "/> </ r d f : D e s c r i p t i o n > Beispiel 2.2: Klassen und Vererbung in RDFS Mit der Eigenschaft rdfs:subPropertyOf lassen sich diese Vererbungsstrukturen auch auf Objekteigenschaften abbilden. Des Weiteren erlaubt RDFS uber rdfs:domain und rdfs:range die Zuordnung von ¨ Definitions- und Wertebereichen zu Eigenschaften. Eine vollst¨ndige Spezifikation a wurde vom W3C unter http://www.w3.org/TR/rdf-schema ver¨ffentlicht. o 6
    • 2.4 Web Ontology Language 2.4 Web Ontology Language Die Web Ontology Language erlaubt die Beschreibung von komplexen Ontologi- en2 . Eine Ontologie beschreibt Objekte, Beziehungen und logische Regeln inner- halb einer bestimmten Dom¨ne. a OWL erweitert das Vokabular von RDF und RDFS um mehr Komplexit¨t bei a der Beschreibung von Klassen und Eigenschaften. Unter anderem k¨nnen damit o Relationen zwischen Klassen (z.B. Gleichheit, Disjunkheit), Kardinalit¨ten (z.B. a genau eins“) und diverse Charakteristika von Eigenschaften (z.B. Symmetrie) ” beschrieben werden [DLM10]. Mit dem vollst¨ndigen Vokabular und ohne Einschr¨nkungen bei der Verwen- a a dung von Vokabeln lassen sich so komplexe Sachverhalte abbilden, dass die Bere- chenbarkeit und die Entscheidbarkeit von Ontologien nicht gew¨hrleistet werden a kann. Deshalb enth¨lt die Spezifikation von OWL drei Teilsprachen die sich in a ihrer Komplexit¨t unterscheiden [DLM10]. a • OWL Lite erlaubt die Beschreibung von einfachen Hierarchien und Bezie- hungen. Es sind zum Beispiel Kardinalit¨ten erlaubt, allerdings nur mit den a Werten 0 und 1. • OWL DL bietet maximale Ausdrucksm¨glichkeiten bei gleichzeitiger Garan- o tie von Berechen- und Entscheidbarkeit. Es sind zwar alle Sprachkonstrukte erlaubt, allerdings existieren Restriktionen bei ihrer Verwendung. Zum Bei- spiel darf eine Klasse von mehreren Klassen erben, allerdings darf sie keine Instanz einer anderen Klasse sein. • OWL Full bietet maximale Ausdrucksm¨glichkeiten und keine syntaktischen o Einschr¨nkungen. Es kann keine Garantie bei der Berechen- oder Entscheid- a barkeit gegeben werden. Zur Veranschaulichung folgt ein Beispiel f¨r die Verwendung von OWL. Auf- u bauend auf Beispiel 2.2 und auf einem Beispiel aus der OWL Referenz3 soll die Ehe-Beziehung zwischen Mann und Frau repr¨sentiert werden. Dazu definieren a wir die Eigenschaft husband f¨r die Klasse Woman und die Eigenschaft wife f¨r u u die Klasse Man. 2 What is an Ontology? http://www.w3.org/TR/webont-req/#onto-def 3 OWL Referenz http://www.w3.org/TR/owl-ref 7
    • 2.5 SPARQL Protocol and RDF Query Language <owl : O b j e c t P r o p e r t y r d f : about=”#w i f e ”> <r d f : t y p e r d f : r e s o u r c e =”owl : F u n c t i o n a l P r o p e r t y ” /> <r d f s : domain r d f : r e s o u r c e=”#Man” /> <r d f s : r a n g e r d f : r e s o u r c e=”#Woman” /> <owl : i n v e r s e O f r d f : r e s o u r c e=”#husband ” /> </owl : O b j e c t P r o p e r t y > <owl : O b j e c t P r o p e r t y r d f : about=”#husband”> <r d f : t y p e r d f : r e s o u r c e =”owl : F u n c t i o n a l P r o p e r t y ” /> <r d f s : domain r d f : r e s o u r c e=”#Woman” /> <r d f s : r a n g e r d f : r e s o u r c e=”#Man” /> <owl : i n v e r s e O f r d f : r e s o u r c e=”#w i f e ” /> </owl : O b j e c t P r o p e r t y > Beispiel 2.3: Modellierung der Ehe-Beziehung zwischen Mann und Frau in OWL In Beispiel 2.3 k¨nnen die verwendeten OWL-Konstrukte uber den owl -Namespace o ¨ identifiziert werden. Eine ObjectProperty vom Typ FunctionalProperty kann nur maximal einen, eindeutigen Funktionswert haben. Nach dieser Definition kann ein Mann also maximal eine Frau und eine Frau maximal einen Mann haben. Ein gutes Beipiel daf¨r, dass bei der Modellierung von Ontologien kulturelle Unterschiede u eine wichtige Rolle spielen k¨nnen [SB10]. o Des Weiteren sind die Eigenschaften husband und wife invers zueinander. Das wird uber die inverseOf -Eigenschaft beschrieben und bedeutet: ¨ Mann x hat Frau y ⇔ Frau y hat Mann x Wenn in einem Datenbestand also nur die Information Mann x hat Frau y“ ” enthalten ist, dann kann durch die inverseOf -Eigenschaft die neue Information Frau y hat Mann x“ hergeleitet werden. Das Herleiten von neuem Wissen aus ” bestehendem Wissen und gegebenen Regeln wird Inferencing genannt. Beispiel 2.3 verdeutlicht außerdem, dass es sich bei OWL lediglich um eine Erweiterung von RDF und RDFS handelt und keine eigenst¨ndige Sprache ist. a Vokabeln wie type, domain und range werden nachwievor uber den rdf - bzw. den ¨ rdfs-Namespace angesprochen und sind nicht im owl -Namespace enthalten. ¨ Unter http://www.w3.org/TR/owl-semantics ist eine vollst¨ndige Ubersicht a uber die Syntax und die Semantik der Web Ontology Language zu finden. ¨ 2.5 SPARQL Protocol and RDF Query Language Die SPARQL Spezifikation4 definiert Syntax und Semantik einer graphbasierten Anfragesprache f¨r RDF. Sie wurde entwickelt, um die von der RDF Data Ac- u cess Working Group definierten Anwendungsf¨lle und Anforderungen5 zu erf¨llen a u 4 SPARQL Query Language for RDF: http://www.w3.org/TR/rdf-sparql-query 5 RDF Data Access Use Cases and Requirements: http://www.w3.org/TR/rdf-dawg-uc 8
    • 2.6 Zusammenfassung und Ausblick [EP10]. Die Anfragen werden aus Graph Patterns konstruiert, welche die Triple- Syntax aus RDF aufgreifen. Diese erlauben zus¨tzliche Variablenbindung inner- a halb eines Tripels, so dass gezielte Ausgaben erzeugt werden k¨nnen. Ressourcen, o Eigenschaften und Relationen werden wie in RDF jeweils uber ihre URI referen- ¨ ziert. SELECT ?name ? t e l WHERE { <h t t p : / / . . / John Doe> <h t t p : / / . . / f r i e n d w i t h > ? x . ? x <h t t p : / / . . / family name> ?name . ? x <h t t p : / / . . / t e l e p h o n e > ? t e l } Beispiel 2.4: Beispielanfrage mit SPARQL Die in Beispiel 2.4 gezeigte Beispielanfrage verdeutlicht die Verwendung des Basic Graph Patterns. Diese Anfrage liefert alle Namen und Telefonnummern der Freunde von John Doe. Durch das erste Graph Pattern werden alle Freunde von John Doe selektiert und an die Variable ?x gebunden. Zu diesen Freunden werden dann die dazugeh¨rigen Namen und Telefonnummern selektiert und zur Ausgabe o an die Variablen ?name und ?tel gebunden. 2.6 Zusammenfassung und Ausblick Die Semantic Web Recommendations bieten ausf¨hrliche Empfehlungen f¨r die u u Realisierung eines Semantic Web. Dabei ist zu erw¨hnen, dass die Semantic Web a Activity aus vielen aktiven Arbeitsgruppen besteht. Dazu geh¨rt zum Beispiel o die Arbeitsgruppe zum Thema RDFa6 . Ziel dieser Arbeitsgruppe ist es, eine ein- heitliche Syntax zur Einbettung von RDF-Informationen in XHTML zu finden. Weitere noch aktive Arbeitsgruppen gibt es beispielsweise zum Thema SPARQL7 oder RIF8 . Die Tatsache, dass es noch eine Vielzahl von aktiven Arbeitsgruppen gibt, zeigt, dass die Entwicklung der Semantic Web Recommendations noch nicht abgeschlos- sen ist. 6 RDFa Arbeitsgruppe: http://www.w3.org/2010/02/rdfa 7 SPARQL Arbeitsgruppe: http://www.w3.org/2009/sparql/wiki/Main_Page 8 RIF Arbeitsgruppe: http://www.w3.org/2005/rules/wiki/RIF_Working_Group 9
    • 3 Das Jena Framework Das Jena Framework ist eine Java-Implementierung der Semantic Web Recom- mendation und ein f¨hrendes Semantic Web-Toolkit f¨r Java-Entwickler [JJC04]. u u Wie in den Semantic Web Recommendations ist das Herz des Frameworks der RDF -Graph, in dem Daten in Tripel-Syntax gespeichert werden. Diesen Daten kann mit Hilfe der RDFS- und OWL-Unterst¨tzung die n¨tige Semantik verliehen u o werden. Als Schnittstelle f¨r Anfragen an den RDF-Graph wird ARQ verwendet, u eine Java-basierte SPARQL-Implementierung. Query-API ARQ Ontology-API Reasoner Input/Output RDF/XML RDF-API Subjekt Prädikat n-triples Objekt N3 materialized graphs virtual graphs SQL inferencing in-memory database Abbildung 3.1: Stark vereinfachte Architektur des Jena Frameworks 10
    • 3.1 Architektur 3.1 Architektur Abbildung 3.1 zeigt die stark vereinfachte Architektur des Jena Frameworks. Diese wird im Wesentlichen durch vier Schichten repr¨sentiert: Die Datenhaltung zur a Speicherung und die RDF-API zur Verwaltung des RDF-Graphen, die Ontology- API f¨r die RDFS- und OWL-Unterst¨tzung und die Query-API um Anfragen an u u den Datengraph zu stellen. Neben diesen vier Schichten bietet das Jena Framework die M¨glichkeit, den Datenbestand zu im- und zu exportieren. o Das Jena Framework unterscheidet zwischen materiellen und virtuellen Tripeln. Materielle Tripel sind diejenigen, die tats¨chlich in dem Datenbestand vorhanden a sind. Als virtuelles Tripel wird ein Tripel bezeichnet, welches durch Inferencing hergeleitet wurde. Ein RDF-Graph mit virtuellen Tripeln wird als virtueller Graph bezeichnet. Der Graph aus den Basisdaten wird als materieller Graph bezeichnet. 3.2 Datenhaltung Standardm¨ßig wird der RDF-Graph im Arbeitsspeicher abgelegt und die Daten a werden nicht dauerhaft gespeichert. F¨r die persistente Datenhaltung bietet das Jena Framework zwei verschiedene u Speichermodi: TDB 1 und SDB 2 : • TDB ist eine hochperformante, native Java-Implementierung zur persisten- ten Datenspeicherung. • SDB ist eine Jena-Komponente zur persistenten Datenspeicherung, die auf konventionellen SQL-Datenbanken basiert. TDB ist eine nicht-transaktionale Datenbank-Engine, d.h. es werden keine Trans- aktionen unterst¨tzt. Lese- und Schreibsperren m¨ssen manuell gesetzt werden. u u SDB hingegen basiert auf konventionellen SQL-Datenbanken und bietet daher Unterst¨tzung f¨r Transaktionen. Außerdem k¨nnen bereits vorhandene Tools wie u u o z.B. f¨r Loadbalancing, Sicherheit, Clustering oder f¨r Backups verwendet werden. u u Sowohl TDB als auch SDB sind nicht in der Standardinstallation des Jena Fra- meworks enthalten. Beide Komponenten m¨ssen separat von der Jena-Projektseite3 u heruntergeladen werden. 3.3 RDF-API Die RDF-API ist f¨r das Erstellen und Verwalten des RDF-Graphen zust¨ndig. u a In Tabelle 3.3 sind Java-Interfaces aufgelistet, die grundlegende Komponenten aus der abstrakten RDF-Spezifikation repr¨sentieren. a 1 TDB: http://openjena.org/TDB 2 SDB: http://openjena.org/SDB 3 Jena Frameworks: http://jena.sourceforge.net 11
    • 3.3 RDF-API RDF-Spezifikation Repr¨sentation in der RDF-API a RDF-Graph Model Ressource Resource Eigenschaft Property Tripel Statement Tabelle 3.1: Implementierung der abstrakten Syntax von RDF Kern dieser API ist das Model-Interface. Ein Model besteht aus einer Menge von Tripeln, die den RDF-Graphen formen. Tripel werden in der RDF-API uber das ¨ Interface Statement abgebildet. Neben den grundlegenden Methoden zum Hin- zuf¨gen und L¨schen von Statements garantiert das Model-Interface grundlegende u o Methoden zur Navigation4 innerhalb des Graphen. Ein Beispiel daf¨r ist die Me- u thode Model.listStatements(). Diese sucht im Graphen nach Statements mit bestimmten Subjekten, Pr¨dikaten oder Objekten. Dazu wird als Argument ein a Selector ubergeben. Das Interface Resource repr¨sentiert eine RDF-Ressource ¨ a und bietet grundlegende Methoden um Eigenschaften hinzuzuf¨gen, zu l¨schen u o und aufzulisten. Eigenschaften werden in der RDF-API uber das Property-Interface ¨ abgebildet. Beispiel 3.1 soll die Zusammenh¨nge der vorgestellten Interfaces innerhalb der a RDF-API verdeutlichen. Der bereits aus Abbildung 2.2 bekannte Graph soll mit Hilfe der RDF-API abgebildet werden. Zun¨chst wird ein Model uber die a ¨ ModelFactory generiert. Anschließend fungiert das Model selber als Factory und dar¨ber wird die Ressource johnDoe und die Eigenschaft familyName generiert. u Um nun die Aussage John Doe hat den Familiennamen Doe‘“ abzubilden, wird ” ’ ein Statement erstellt. Obwohl das Statement uber das Model generiert wurde, ¨ muss es anschließend manuell dem Model hinzugef¨gt werden. Um das Navigieren u innerhalb eines Graphen zu verdeutlichen, werden anschließend alle Aussagen uber ¨ Familiennamen im Model gesucht und ausgegeben. 4 Navigating a Model: http://jena.sourceforge.net/tutorial/RDF_API/index.html# ch-Navigating 12
    • 3.3 RDF-API // d e f i n e u r i p r e f i x S t r i n g u r i P r e f i x = ” http : / / . . / ” ; // c r e a t e d e f a u l t model Model model = ModelFactory . c r e a t e D e f a u l t M o d e l ( ) ; // c r e a t e r e s o u r c e R e s o u r c e johnDoe = model . c r e a t e R e s o u r c e ( u r i P r e f i x + ” John Doe ” ) ; // c r e a t e p r o p e r t y P r o p e r t y familyName = model . c r e a t e P r o p e r t y ( u r i P r e f i x + ” f a m i l y n a m e ” ) ; // c r e a t e s t a t e m e n t Statement stmt = model . c r e a t e S t a t e m e n t ( johnDoe , familyName , ”Doe ” ) ; // add s t a t e m e n t t o model model . add ( stmt ) ; // n a v i g a t i n g i n t h e model S t m t I t e r a t o r i t = model . l i s t S t a t e m e n t s ( new S i m p l e S e l e c t o r ( n u l l , familyName , (RDFNode) n u l l ) ); w h i l e ( i t . hasNext ( ) ) { // g e t s t a t e m e n t from i t e r a t o r Statement r e s S t m t = i t . n e x t ( ) ; // p r o d u c e ou tp ut System . out . p r i n t l n ( r e s S t m t . g e t S u b j e c t ( ) . t o S t r i n g ( ) + ” has f a m i l y name ” + resStmt . getObject ( ) . t o S t r i n g ( ) ); } Beispiel 3.1: Arbeiten mit der RDF-API 3.3.1 Input/Output Die RDF-API bietet weiterhin die M¨glichkeit RDF-Daten als XML zu lesen und o zu schreiben. Der Export5 erfolgt uber die Model.write()-Methode. Diese bekommt als Pa- ¨ rameter einen java.io.OutputStream und die Zielsyntax ubergeben. Die Zielsyn- ¨ tax wird als String ubergeben und bestimmt, welches Ausgabeformat und welche ¨ RDFWriter-Implementierung verwendet wird. M¨gliche Ausgabeformate sind RD- o F/XML, RDF/XML-ABBREV, TURTLE und N3. Der Import6 von RDF-Daten funktioniert ¨hnlich zum Export. Das Model- a Interface sieht daf¨r die Methode Model.read() vor. Diese erh¨lt als Parame- u a ter einen java.io.InputStream und das Eingabeformat. F¨r jede RDFWriter- u Implementierung existiert eine dazugeh¨rige RDFReader-Implementierung, so dass o alle Ausgabeformate auch als Eingabeformat unterst¨tzt werden. Zus¨tzlich be- u a kommt die read()-Methode ein URI-Prefix ubergeben, welches bei relativen URI- ¨ Angaben im InputStream verwendet wird. 5 Writing RDF http://jena.sourceforge.net/tutorial/RDF_API/index.html# ch-Writing 6 Reading RDF http://jena.sourceforge.net/tutorial/RDF_API/index.html# ch-Reading 13
    • 3.4 Ontology-API 3.4 Ontology-API Die Ontology-API ist f¨r die semantische Interpretation der RDF-Daten und f¨r u u das Inferencing verantwortlich. Das Jena Ontology-Model ist eine Erweiterung des RDF-Models und stellt Funktionalit¨ten f¨r den Umgang mit Ontologien zur Verf¨gung. Ontology-Modelle a u u werden ebenfalls uber die ModelFactory erstellt. Es werden sowohl einfache RDFS- ¨ Ontologien, als auch OWL-Ontologien (wahlweise OWL Full, OWL DL, OWL Lite) unterst¨tzt [Jen10]. u Viele Ontologien sind kostenlos im Internet verf¨gbar. Beispiele daf¨r sind das u u Friend of a Friend -Projekt7 oder die Gene Ontology8 . Um diese Ontologien la- den zu k¨nnen stellt das Ontology-Modell die OntModel.read()-Methode zur o Verf¨gung. u Das bereits erw¨hnte Inferencing, einer der Hauptgr¨nde f¨r die Verwendung a u u von Ontologien, wird von so genannten Reasonern durchgef¨hrt. Dabei handelt u es sich um Graph-Kombinatoren, die auf den Regeln einer Ontologie arbeiten. Es existieren unabh¨ngige Reasoner f¨r RDFS und OWL wie z.B. Pellet9 , ein a u ¨ OWL2 Reasoner f¨r Java. Uber die integrierte ReasonerRegistry sind in der u Ontology-API vordefinierte Reasoner f¨r RDFS und OWL verf¨gbar, es k¨nnen u u o aber auch externe Reasoner wie Pellet verwendet werden [Jen10]. Das InfModel ist eine Erweiterung von Model und bietet zus¨tzliche Unterst¨tzung a u f¨r das Inferencing. u // g e t o n t o l o g y OntModel f O n t o l o g y = ModelFactory . c r e a t e O n t o l o g y M o d e l ( ) ; f O n t o l o g y . r e a d ( ” h t t p : / / xmlns . com/ f o a f / s p e c / 2 0 1 0 0 1 0 1 . r d f ” ) ; // g e t owl r e a s o n e r Reasoner o w l R e a s o n e r = R e a s o n e r R e g i s t r y . getOWLReasoner ( ) ; // bind r e a s o n e r t o f o a f o n t o l o g y Reasoner fOntReasoner = o w l R e a s o n e r . bindSchema ( f O n t o l o g y ) ; // u s e r e a s o n e r t o c r e a t e i n f e r e n c e model I n f M o d e l i n f M o d e l = ModelFactory . c r e a t e I n f M o d e l ( fOntReasoner , model ) ; Beispiel 3.2: Arbeiten mit der Ontology-API Beispiel 3.2 soll die Verwendung von Ontologien und Reasonern verdeutlichen. Zun¨chst wird ein OntModel generiert und die bereits erw¨hnte Friend of a Fri- a a end -Ontology (FOAF) wird uber ihre URI geladen. Danach wird der standard ¨ OWL-Reasoner an das FOAF OntModel gebunden. Das Inferencing wird bei der Erstellung des InfModel auf dem ubergebenen Model durchgef¨hrt. ¨ u 7 Friend of a Friend -Projekt: http://www.foaf-project.org 8 Gene Ontology: http://www.geneontology.org 9 Pellet: OWL2 Reasoner for Java http://clarkparsia.com/pellet 14
    • 3.5 Query-API 3.5 Query-API Die Query-API ist f¨r komplexere Anfragen auf den Datengraphen zust¨ndig. Es u a spielt bei Queries keine Rolle, ob es sich bei dem Datengraphen um einen materiel- len (repr¨sentiert durch Model) oder einen virtuellen Graphen (durch InfModel re- a pr¨sentiert) handelt. Beide Modelle werden durch das einheitliche Model-Interface a gleich behandelt. Das Herz der Query-API ist ARQ10 , eine Query-Engine f¨r Jena die SPARQL u unterst¨tzt. u Die wichtigsten Klasse f¨r grundlegende Queries sind Query und QueryExecution. u Die QueryFactory erstellt Query-Objekte. Dabei kann als Parameter der Query- string ubergeben werden. ¨ Das Resultat einer Query wird in einem ResultSet gespeichert. S t r i n g q u e r y S t r i n g = ”SELECT ?name ? t e l WHERE { <h t t p : / / . . / John Doe> <h t t p : / / . . / f r i e n d w i t h > ? x . ? x <h t t p : / / . . / family name> ?name . ? x <h t t p : / / . . / t e l e p h o n e > ? t e l }”; // c r e a t e query from s t r i n g Query query = QueryFactory . c r e a t e ( q u e r y S t r i n g ) ; // c r e a t e query e x e c u t i o n o b j e c t from query and model QueryExecution q e x e c = Q u e r y E x e c u t i o n F a c t o r y . c r e a t e ( query , model ) ; // run query ResultSet r e s u l t = qexec . e x e c S e l e c t ( ) ; w h i l e ( r e s u l t . hasNext ( ) ) { // do s t h . } Beispiel 3.3: Arbeiten mit der Query-API Die Verwendung der einzelnen Klassen wird in Beispiel 3.3 verdeutlicht. Auf- bauend auf Beispiel 2.4 sollen ebenfalls alle Familiennamen und Telefonnummern der Freunde von John Doe im Datengraph gesucht werden. Dazu wird zun¨chst a der Querystring definiert. Daraus wird anschließend uber die QueryFactory ein ¨ Query-Objekt erzeugt, welches zusammen mit dem Modell an eine Instanz der QueryExecution-Klasse gebunden wird. Die QueryExecution.execSelect()-Methode f¨hrt anschließend die Query aus und gibt ein ResultSet zur¨ck. u u 10 ARQ: http://jena.sourceforge.net/ARQ 15
    • 3.6 Fazit und Praxiserfahrungen 3.6 Fazit und Praxiserfahrungen Das Jena Framework setzt Teile der Semantic Web Recommendations in die Pra- xis um. Es implementiert die Unterst¨tzung f¨r Kernfunktionalit¨ten, um ein u u a Semantic Web zu realisieren. Dazu geh¨ren im Wesentlichen RDF, RDFS, OWL o und SPARQL. Jena unterst¨tzt jedoch nicht bei der Entwicklung von Ontologien. u Das Framework hat seine St¨rken bei der Verarbeitung und bei der Interpreta- a tion von Ontologien. F¨r die Entwicklung existieren spezielle Editoren wie zum u Beispiel Prot´g´11 . e e Eine sehr wichtige Eigenschaft eines Frameworks zur Implementierung eines Semantic Web ist die Performance im Umgang mit großen Datenmengen. Je mehr Daten innerhalb eines Semantic Web abgebildet sind, desto mehr Aussagen und logische Sch¨sse k¨nnen dar¨ber getroffen werden. Praxiserfahrungen aus dem u o u Projekt Artefact-Actor-Networks 12 (AAN) an der Universit¨t Paderborn haben a gezeigt, dass das Jena Framework mit der Verarbeitung von großen Datenmengen (mehr als 200.000 Ressourcen und 3 Millionen Tripel) erhebliche Probleme hat. Das macht sich in erster Linie bei dem Inferencing mit sehr hohen Laufzeiten bemerkbar. Es hat sich weiterhin herausgestellt, dass die Speichermodi TDB zur persisten- ten Datenspeicherung performanter als SDB ist. Allerdings setzt die Verwendung von TDB mehr Implementierungsaufwand voraus, da beispielsweise Lese- und Schreibsperren manuell gesetzt werden m¨ssen. u 11 Prot´g´: http://protege.stanford.edu e e 12 Artefact-Actor-Networks: http://artefact-actor-networks.net 16
    • 4 Zusammenfassung ¨ Dieses Kapitel soll abschließend einen Uberblick uber die Inhalte der Arbeit geben ¨ und ein Fazit ziehen. 4.1 Zusammenfassung Die Vision des Semantic Web verfolgt das Ziel aus dem Netz der Dokumente“ ” ein Netz aus Daten zu schaffen, welche aufgrund ihrer maschinell interpretierbaren Semantik miteinander verkn¨pft sind. u In dieser Seminar-Ausarbeitung ging es um die von der Semantic Web Activity entwickelten Semantic Web Recommendations und um das Jena Framework zur Implementierung eines Semantic Web. Um die Arbeitsweise des Jena Frameworks besser verstehen zu k¨nnen, wur- o den zun¨chst die Semantic Web Recommendations anhand der durch das Jena a Framework umgesetzten Empfehlungen vorgestellt. Mit diesem fundierten Wissen wurde anschließend die Implementierung im Jena Framework theoretisch und mit anschaulichen Beispielen erkl¨rt. a 4.2 Ausblick Es ging in dieser Arbeit prim¨r um die Speicherung, die semantische Interpretier- a barkeit und die Abfrage von Daten. Sowohl die Semantic Web Recommendations und das Jena Framework empfehlen beziehungsweise implementieren keine Un- terst¨tzung bei der Beschaffung von Daten. Das WWW als Netz der Dokumente u beinhaltet unz¨hlige Informationen, die allerdings nicht ohne Weiteres semantisch a verarbeitet werden k¨nnen. Es stellt sich die Frage, ob die notwendigen Daten f¨r o u ein Semantic Web aus vorhandenen Quellen extrahiert werden k¨nnen. o Ein Ansatz ist das parsen von Dokumenten nach relevanten Daten. Allerdings m¨ssen hier f¨r jedes Dokument spezielle Parser entwickelt werden und die Struk- u u tur der Dokumente d¨rfte sich im Nachhinein nicht ver¨ndern. u a Eine effektivere M¨glichkeit zur Datenbeschaffung ist die Entwicklung eines o Adapters f¨r ein Application programming interface (API). Viele Webseite der u Web 2.0 -Generation bieten eine solche Schnittstelle an. Ein großer Vorteil dieser M¨glichkeit ist, dass Daten die einer API-Schnittstelle entstammen das Resultat o einer gezielten Anfrage sind. Dadurch sind die Daten semantisch interpretierbar und k¨nnen direkt in die RDF-Syntax konvertiert werden. o 17
    • 4.2 Ausblick Eine vielversprechende Entwicklung ist das bisherige Resultat der aktiven Ar- beitsgruppe zum Thema RDFa. Damit ist es m¨glich vorhandenen XHTML- o Quellcode mit semantischen Informationen anzureichern. Hinsichtlich der Daten- beschaffung k¨nnte ein spezieller RDFa-Parser ein Dokument unabh¨ngig von der o a Dokumentenstruktur nach RDF-Informationen untersuchen und verarbeiten. Es existieren bereits RDFa-Plugins f¨r g¨ngige Content-Management-Systeme (CMS) u a 1 wie zum Beispiel f¨r Wordpress . u 1 RDFa Plugin f¨r Wordpress: http://wiki.creativecommons.org/RDFa_Plugin_for_ u WordPress 18
    • Literatur [BA10] Ben Adida, Mark B. RDFa Primer - Bridging the Human and Data Webs. online: http://www.w3.org/TR/xhtml-rdfa-primer. 2010 [Bec10] Beckett, Dave. RDF/XML Syntax Specification. online: http://www. w3.org/TR/rdf-syntax-grammar. 2010 [DB10] Dan Brickley, R.V. G. RDF Vocabulary Description Language 1.0: RDF Schema. online: http://www.w3.org/TR/rdf-schema. 2010 [DLM10] Deborah L. McGuinness, Frank van H. OWL Web Ontology Lan- guage - Overview. online: http://www.w3.org/TR/owl-features. 2010 [EP10] Eric Prud’hommeaux, Andy S. SPARQL Query Language for RDF. online: http://www.w3.org/TR/rdf-sparql-query. 2010 [Jen10] The Jena Ontology API. online: http://jena.sourceforge.net/ ontology/index.html. 2010 [JJC04] Jeremy J. Carroll, Ian Dickinson Andy Seaborne Chris Dollin Ke- vin W. Jena: Implementing the Semantic Web Recommendations. 2004 [SB10] Sean Bechhofer, Jim Hendler Ian Horrocks Deborah L. McGuinness Peter F. Patel-Schneider Lynn Andrea S. OWL Web Ontology Language - Reference. online: http://www.w3.org/TR/owl-ref. 2010 [W3C10] W3C. Semantic Web. online: http://www.w3.org/standards/ semanticweb. 2010 19