Die "Semantic Web Recommendations" und das Jena Framework

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 Uniﬁed Resource Identiﬁer . . . . . . . . . . . . . . . . . . . . . . 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ütert. 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.

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


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 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 : ID=" Woman ">
<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 "/>

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 Speziﬁkation 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 deﬁnieren
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 ﬁnden.
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-Speziﬁkation 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-Speziﬁkation 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-Preﬁx 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 vordeﬁnierte 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 deﬁniert. 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 getroﬀen 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-
beschaﬀung 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 Speciﬁcation. 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

Die "Semantic Web Recommendations" und das Jena Framework

Recomendados

Mais conteúdo relacionado

Semelhante a Die "Semantic Web Recommendations" und das Jena Framework

Semelhante a Die "Semantic Web Recommendations" und das Jena Framework (20)

Die "Semantic Web Recommendations" und das Jena Framework