Charakterisierung semantischer Web-Applikationen und ...lips.informatik.uni-leipzig.de/files/MasterThesis.pdf · denen semantische Technologien zum Einsatz kommen. Auf dieser Basis

UNIVERSITT LEIPZIGFakultt fr Mathematik und Informatik

Institut fr Informatik

Charakterisierung semantischerWeb-Applikationen und Vorstellung eines

Anwendungsfalles

Masterarbeit

Leipzig, 25. Juni 2008 vorgelegt von

Michael Martingeb. am: 22.12.1979

Studiengang Informatik

Verantwortlicher Hochschullehrer: Prof. Dr. Ing. habil. Klaus-Peter FhnrichBetreuer: Dr. rer. nat. Sren AuerAbteilung Betriebliche Informationssysteme

Abstract

Informationen im World Wide Web (WWW) werden zunehmend mittels Web-Applikationen wiebeispielsweise Content-Management-Systeme, Diskussionsforen und Web-Shops erstellt und ver-ffentlicht. Im Zuge der Erweiterung des WWW um eine semantische Schicht (Semantic Web),stehen Entwickler von Web-Informationsangeboten vor der Herausforderung die genutzten Web-Applikationen zu semantifizieren oder auch neue Web-Informationsangebote auf Basis semanti-scher Technologien zu realisieren.

In dieser Arbeit wird ein berblick ber herkmmliche und semantische Web-Technologien gege-ben. Um eine Verbindung zwischen den Merkmalen von Web-Applikationen und dem SemanticWeb zu schaffen, wird der Begriff semantische Web-Applikation definiert und eine darauf auf-bauende Klassifizierung prsentiert. Dies dient der Charakterisierung von Web-Applikationen, indenen semantische Technologien zum Einsatz kommen. Auf dieser Basis ist es einerseits mg-lich, semantische von herkmmlichen Web-Applikationen abzugrenzen und andererseits semanti-sche Web-Applikationen untereinander zu unterscheiden. Weiterhin wird der Aufbau und bedeu-tende Teile der Implementierung des Anwendungsfalles vakantieland.nl, einem Tourismusportalaus den Niederlanden, vorgestellt. Anhand dessen wird der Einsatz semantischer Technologien inWeb-Applikationen sowie die damit verbundenen Vor- und Nachteile prsentiert.

INHALTSVERZEICHNIS ii

Inhaltsverzeichnis

1 Einleitung 1

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 3

2.1 Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.2 Eindeutige Identifikation von Informationsressourcen . . . . . . . . . . . . . . . . . 5

2.3 Web-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Reprsentationssprachen fr Wissensbasen . . . . . . . . . . . . . . . . . . . . . . . 8

2.5 Folksonomy und Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Vorstellung des Anwendungsfalls 14

3.1 Die Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2 Motivation zur Neuentwicklung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3 Vorstellung der aktuellen Version . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.1 Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3.2 Entwicklungsvorgehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.3 Designentscheidungen und Darstellung der aktuellen Version . . . . . . . . . 18

4 Stand der Technik 21

4.1 Werkzeuge fr das Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 Vokabulare im Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.3 Existierende Semantic Web Datasets . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.4 Semantic Web Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

INHALTSVERZEICHNIS iii

5 Charakterisierung semantischer Web-Applikation 29

5.1 Web-Applikationen im Semantic Web . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.2 Technologien des Semantic Web auf Modellebene . . . . . . . . . . . . . . . . . . . 30

5.2.1 Modellierung des Schemas . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5.2.2 Speicherung von Wissensbasen . . . . . . . . . . . . . . . . . . . . . . . . 31

5.2.3 Serialisierung und Deserialisierung von Daten . . . . . . . . . . . . . . . . . 33

5.2.4 URI-Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2.5 Benutzung existierender Vokabulare und Datasets . . . . . . . . . . . . . . . 37

5.2.6 Reasoning in Web-Applikationen . . . . . . . . . . . . . . . . . . . . . . . 38

5.2.7 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3 Technologien auf Oberflchenebene . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.3.1 Clientseitige Reprsentation von Informationen . . . . . . . . . . . . . . . . 41

5.3.2 Widgets und asynchrone Datenbertragung . . . . . . . . . . . . . . . . . . 44

5.4 Semantic Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.5 Vorstellung existierender semantischer Web-Applikationen . . . . . . . . . . . . . . 46

5.6 Linked Data - eine Semantic Web Architektur . . . . . . . . . . . . . . . . . . . . . 47

5.7 Definition des Begriffes der semantischen Web-Applikation . . . . . . . . . . . . . . 49

6 Semantische Technologien im vorgestellten Anwendungsfall 53

6.1 Modellierung der Ontologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

6.1.1 Identifikation von Klassen und Eigenschaften . . . . . . . . . . . . . . . . . 53

6.1.2 Granularitt der modellierten Zusammenhnge . . . . . . . . . . . . . . . . 55

6.1.3 Importieren bestehender Datenbestnde . . . . . . . . . . . . . . . . . . . . 56

6.2 Beschreibung der Modelkomponente . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2.1 Aufbau der Modelkomponente . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2.2 Verwendung von Suchkriterien zur Filterung von Point of Interests . . . . . . 59

6.2.3 Erzeugung eines Point of Interest . . . . . . . . . . . . . . . . . . . . . . . 66

6.3 Steuerung der Web-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6.4 Clientseitige Reprsentation von Informationen . . . . . . . . . . . . . . . . . . . . 70

INHALTSVERZEICHNIS iv

6.5 Skizzierung der Performanzsteigerung whrend der Entwicklung . . . . . . . . . . . 72

6.6 Ontowiki als Werkzeug zur Administration der Daten . . . . . . . . . . . . . . . . . 73

7 Zusammenfassung und Ausblick 76

Verzeichnisse 79

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Listings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Abkrzungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

1 EINLEITUNG 1

1 Einleitung

Die Entwicklung des Internet als weltweites Informationsnetz ist lngst nicht abgeschlossen. DieMenge der im Internet verfgbaren Informationen wchst stetig, whrend die Relevanz der berSuchmaschinen auffindbaren Dokumente sinkt. Weiterhin besteht mittlerweile weniger das Problem,Informationen einer Domne im Internet zu finden. Problematisch ist es hingegen, przise Filter zuermitteln, welche die Menge an wirklich relevanten die gewnschten Informationen enthaltenden Dokumenten einschrnkt. Existierende Programme knnen hierbei ebenfalls nur mangelhafte Un-tersttzung geben, da die fr Menschen generierte Reprsentationsform der Informationen ohneKontextinformationen von Maschinen nur schwer zu interpretieren sind. Die voranschreitende Ent-wicklung an Technologien des Semantic Web erffnet viele Mglichkeiten diesem Umstand entge-genzuwirken und ermglicht zudem Neuerungen zur Erstellung von Web-Applikationen. In dieserArbeit wird ein Auszug semantischer Technologien sowie Web-Anwendungen, die diese benutzen,vorgestellt und der Begriff der semantischen Web-Applikation definiert. Um den Einsatz dieserTechnologien in einer Web-Applikation und die damit verbundenen Vor- und Nachteile darzustellen,wird der Aufbau und signifikante Teile der Implementierung eines Anwendungsfalles prsentiert.

1.1 Motivation

Auf der dritten International Semantic Web Conference 20041 (ISWC) wurde zur Klrung der Be-grifflichkeit semantische Web-Applikation aufgerufen2. Dies geschah als Teil der zweiten SemanticWeb Challenge3 und forderte zur Publikation von Web-Applikationen auf, welche Technologien desSemantic Web einsetzen. Seit dem werden jedes Jahr eine Menge an solchen Web-Applikationen vor-gestellt, die alle in Idee und Umsetzung einzigartig sind, aber nur wenige einen protoypischen Statusberwinden. Zudem ist der Begriff immer noch in Diskussion, weshalb in dieser Arbeit ein Beitragzur Klrung des Begriffes geleistet wird.

Der entwickelte und in dieser Arbeit prsentierte Anwendungsfall vakantieland.nl ist ein Redesign alssemantische Web-Applikation eines bestehenden niederlndischen Tourismusportals. Dieser Anwen-dungsfall wird von einer groen Anwendergemeinde genutzt und die bisherige Implementierung folgtdem Aufbau klassischer Web Applikationen. Zu Beginn der Neuentwicklung von vakantieland.nl gabes nur eine grobe Vorstellung dessen, was eine semantische Web-Applikation ausmacht, was verschie-den von herkmmlichen Web-Applikationen ist und welche Technologien zustzlich oder ersetzendzum Einsatz kommen. Diese Fragen werden in dieser Arbeit nicht eindeutig geklrt, ermglichenallerdings auf Basis der im weiteren Verlauf vorgestellten Begriffsdefinition weitere Arbeiten zur

1http://iswc2004.semanticweb.org/2http://iswc2004.semanticweb.org/CF/semWebChallenge.html3http://challenge.semanticweb.org/

http://iswc2004.semanticweb.org/http://iswc2004.semanticweb.org/CF/semWebChallenge.htmlhttp://challenge.semanticweb.org/

1 EINLEITUNG 2

Evaluation von Best Practices mglicher einsetzbarer Vorgehensmodelle sowie Entwurfs- und Archi-tekturmuster zur Entwicklung semantischer Web-Applikationen.

1.2 Zielsetzung

Das Ziel dieser Arbeit ist die Charakterisierung semantischer Web-Applikation. Hierzu werden grund-legende Technologien vorgestellt, die bei der Entwicklung aller Web-Applikation zum Einsatz kom-men und Spezifika des Semantic Web dargelegt. Allgemeine Web-Applikations-Technologien und diedes Semantic Web werden in dieser Arbeit miteinander in Verbindung gebracht, was in der Begriffs-definition der semantischen Web-Applikation resultiert. Weiterhin werden zur Charakterisierungsemantischer Web-Applikationen Technologiebereiche benannt, die auf unterschiedliche Weise einenZugewinn fr das Semantic Web im Allgemeinen und Web-Applikationen im Semantic Web im Spe-ziellen bieten. Zur Vorstellung des Einsatzes spezieller semantischer Technologien wird der Aufbauund signifikante Teile der Implementierung des Anwendungsfall vakantieland.nl herangezogen.

Das zur Verfgung stehende Spektrum an herkmmlichen und semantischen Technologien fr denEinsatz in Web-Applikation ist sehr umfassend, weshalb sich in dieser Arbeit auf einen signifikantenAuszug der Menge an verwendbaren Technologien beschrnkt wird. Auch das Thema Reasoning, alseines der ermglichten Eckpfeiler des Semantic Web, wird in dieser Arbeit zwar erwhnt und dessenEinsetzbarkeit in semantischen Web-Applikationen angeschnitten, in seinen Einzelheiten allerdingsnicht vollstndig vorgestellt.

1.3 Aufbau

Im Kapitel 2 werden Grundlagen des Semantic Web mit den proklamierten Visionen, grundlegen-den Technologien, Sprachen und Begriffen beschrieben.. Ferner wird die Definition der Begrifflich-keit Web-Applikation fr diese Arbeit vorgenommen. Im Kapitel 3 werden die Vorgngerversion,die Anforderungen und grundlegende Designentscheidungen sowie der daraus resultierende aktuelleStand des erwhnten Anwendungsfalles vorgestellt. Das Kapitel 4 Stand der Technik enthlt Infor-mationen ber wichtige Werkzeuge, Vokabulare, Bibliotheken und Datasets, die bei der Verwendungsemantischer Technologien in Web-Applikationen von Interesse sind und deren Einsatz in diesem Ka-pitel und im weiteren Verlauf der Arbeit vorgestellt werden. Aufbauend auf den Grundlagen und demStand der Technik werden Merkmale, Technologien und Umsetzungen zielfhrend zur Begriffsdefini-tion der semantischen Web-Applikation in Kapitel 5 dargestellt. Im Anschluss werden die Designent-scheidungen, die bei der Erstellung des Anwendungsfalles getroffen wurden, in Kapitel 6 przisiertund signifikante Teile der Implementierung vorgestellt. Abschlieend wird in Kapitel 7 die vorliegen-de Arbeit zusammengefasst und ein Ausblick auf weitere Arbeiten gegeben.

2 GRUNDLAGEN 3

2 Grundlagen

In diesem Kapitel werden die zum besseren Verstndnis dieser Arbeit beitragenden Begriffe undBasis-Technologien vorgestellt. Hierzu gehren Visionen und Eigenschaften des Semantic Web, Iden-tifikatoren von Informationsressourcen, Reprsentationssprachen und die Begriffe Ontologie, Folkso-nomy und Web-Applikation, die folgend skizziert werden.

2.1 Semantic Web

Das derzeitige World Wide Web (WWW) lsst sich als ein syntaktisches Web bezeichnen [BCT07],was bedeutet, dass in diesem enthaltene Informationen ohne maschinenauswertbare Interpretations-vorschriften zur Verfgung gestellt werden. Nachdem 1989 das WWW entwickelt wurde, beschriebTim Berners-Lee diese Erfindung wie folgt [BLCGP92]:

[...]The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initia-tive aiming to give universal access to a large universe of documents.[...]

Damit beschreibt er den ursprnglichen Gedanken, der zur Entwicklung des WWW fhrte, nmlichdem Vernetzen von Dokumenten (einst im Kontext wissenschaftlichen Arbeitens), um diese unterein-ander (von Maschinen oder Personen aus) erreichen zu knnen.

Genannte Dokumente enthalten Daten, die fr den Lesenden unter Betrachtung des dahinter stehen-den Kontextes zu Informationen werden. Die Interpretation von Daten beziehungsweise die Identi-fizierung relevanter Informationen ist derzeit noch grtenteils dem Menschen berlassen. Es gibtzwar diverse Algorithmen und Technologien, die den Suchenden bei der Recherche nach relevantenInformationen untersttzen (Beispiel: Verschlagwortung von Dokumenten und diverse sehr ausge-feilte statistische Methoden), was allerdings zumeist mit erhhtem Speicherplatzbedarf und einemgroen Pflegebedrfnis einhergeht und zudem noch immer keine perfekten Ergebnisse liefert. Weiter-hin werden tglich neue Dokumente im Millionenbereich dem WWW hinzugefgt (Bei Google4 sindderzeit ber 8 Milliarden Webseiten indexiert). Suchende mssen dadurch immer lnger werdendeErgebnislisten auswerten oder komplexere Suchanfragen stellen, um die Przision wieder zu erh-hen. An dieser Stelle kommt der Begriff des Semantic Web zum Einsatz. Um die Probleme, die einrein syntaktisches Web mit sich bringt, bewltigen zu knnen, gibt es die Mglichkeit existierendeund neu hinzukommende Daten mit zustzlichen Informationen so anzureichern, dass eine maschi-nelle Verarbeitung auch auf Bedeutungsebene ermglicht wird [uHM06]. Dabei wird das bestehendeWWW nicht neu erfunden, sondern nur erweitert, wie an folgender Aussage von Tim Berners-Lee[BLHL01] zu sehen ist:

4http://www.google.com

http://www.google.com

2 GRUNDLAGEN 4

[...] The Semantic Web is not a separate Web but an extension of the current one, inwhich information is given well-defined meaning, better enabling computers and peopleto work in cooperation. The first steps in weaving the Semantic Web into the structureof the existing Web are already under way. In the near future, these developments willusher in significant new functionality as machines become much better able to processand understand the data that they merely display at present. [...]

Quelle des Originals: http://www.w3.org/2007/03/layerCake.png von Mrz 2007

Abbildung 1: Schichtenmodell des Semantic Web

Die Anreicherung von Daten mit maschinell auswertbaren Informationen auf semantischer Ebene istein Grundkonzept des Semantic Web. Weiterhin beansprucht das Semantic Web Konzepte wie dieder Verteilung von Informationen in groen Mengen und der automatischen beziehungsweise semi-automatischen Extraktion von Semantik aus strukturierten Datenbestnden. Diese Konzepte sind zwarnicht erst fr das Semantic Web entwickelt worden, in Ihrer Kombination allerdings etwas Neues. An-hand des Schichtenmodells des Semantic Web (siehe Abbildung 1), welches sich seit dessen erstenErwhnung einige Male nderte, ist zu sehen, mit welchen Technologien die genannten Konzepteumgesetzt werden und wie diese Technologien aufeinander aufbauen. Die unterste Ebene URI/IRI(vgl. Abschnitt 2.2) sowie die Ebene XML (eXtensible Markup Language) [BPSM+06] beschreibenTechnologien, die eigentlich nicht Teil des Semantic Web sind, sondern schon vor dessen ersten Er-

http://www.w3.org/2007/03/layerCake.png

2 GRUNDLAGEN 5

whnung existierten. Die darauf aufbauenden Technologien RDF, RDFS und OWL werden in 2.4nher beschrieben und ermglichen einen zentralen Bestandteil des Semantic Web, dem Reasoning[May06]. Die Bedeutung diesen Begriffes lsst sich als das Ziehen von begrndeten und vernnfti-gen Schlssen zusammenfassen und ist in der Ebene Proof anzusiedeln. Reasoning lsst sich unteranderem in die drei Arten abduktives, deduktives und induktives Reasoning unterteilen. Zu den letz-ten beiden Arten sind im Abschnitt 4.1 einige Implementierungen gelistet. Reasoning auf Basis vonRDFS oder OWL ist allerdings aufgrund der begrenzten Ausdrucksmchtigkeit dieser Sprachen be-schrnkt, weshalb diese Sprachen durch Regeln (RIF-Ebene) ergnzt werden knnen. Unifying Logicbezeichnet eine Ebene in dem beides, Wissen (ausgedrckt in einer Sprache) und Regeln, verknpftwird, um Reasoning nicht auf getrennten Mengen zu gestalten. Die Anfragesprache SPARQL wirdin Abschnitt 5.2.3 skizziert und anhand von Beispielen in Abschnitt 6.2.2 nher beschrieben. DieSchichten Proof, Trust und Crypto stehen fr die Sammlung von Technologien, die zur Lsung vonSicherheitsproblemen und Vertrauensfragen unter verschiedenen Aspekten eingesetzt werden knnen.In der obersten Schicht des semantischen Schichtenmodells User Interface & Applications werden alldiejenigen Technologien und Sprachen angesiedelt, die zur Erstellung von Benutzer-Oberflchen oderkompletten Web-Applikationen bentigt werden. Hierbei ist allerdings fraglich ob die Erstellung vonOberflchen und Web-Applikationen nur auf Basis aller darunter angeordneter Schichten mglich ist,oder gar auf jeder Schicht. Die zuletzt genannten Schichten RIF, Unifying Logic, Proof, Trust, Cryptound User Interface & Applications sind noch Gegenstand der aktuellen Forschung.

2.2 Eindeutige Identifikation von Informationsressourcen

Zur eindeutigen Identifikation beliebiger Objekte wurde 1994 von Tim Berners-Lee der Begriff desUniversal Resource Identifier (URI) [BL94] eingefhrt und im RFC 1630 beschrieben. Diese belie-bigen Objekte, oder allgemeiner Ressourcen, knnen konkrete Elemente der realen Welt oder aberauch abstrakte, nicht-physische Objekte wie beispielsweise Webseiten im Internet sein. Spter wurdedieser Begriff zur Uniform Resource Identifier abgendert. Der allgemeine Aufbau von URIs5 ist in[BLFM05] beschrieben und kann wie folgt kurz zusammengefasst werden:

:

Jede URI muss, wie zu sehen ist, mit dem Schemanamen beginnen und wird durch einen Doppelpunktvon der im Schema festgelegten Struktur getrennt. Weiterhin sind im RFC 3986 noch die ZeichenSlash ( / ), Fragezeichen ( ? ) und Raute ( # ) als Begrenzungszeichen definiert, um signifikanteTeile von URIs von einander zu trennen. Dies ermglicht es Parsern, URIs zu interpretieren.

Der spezielle Aufbau von URIs ist abhngig vom verwendeten URI-Schema. Viele Schemata besitzen5URI: RFC3986

2 GRUNDLAGEN 6

einen hierarchischen Aufbau, wie beispielsweise das Hypertext Transfer Protocol6 (HTTP) und FileTransfer Protocol7 (FTP) in denen unter anderem der Benutzername, Passwort, Server und Port indieser Reihenfolge angegeben werden kann. Weitere Beispiele fr Schemata sind LDAP , FILE undXMPP.

Des Weiteren lassen sich URIs in zwei Arten unterteilen. Zum einen ist das der Uniform ResourceLocator8 (URL) welche der exakten Lokalisierung einer Ressource im Netz dient. Als Beispiel hierfrdient die Web-Adresse des PNG-Bildes zum Schichtenmodell des Semantic Web.

http://www.w3.org/2007/03/layerCake.png

Die zweite Art von URIs sind Uniform Resource Names9 (URN) mit deren Hilfe Ressourcen anhandeines frei zu vergebenden Namen identifiziert werden knnen. Dies ist insbesondere dann von Interes-se, wenn die Ressource zwar zu beschreiben ist, dieser aber kein eindeutiger Ort zugewiesen werdenkann. Als Beispiel wird hierzu in der Literatur oft die Identifikation eines Buches anhand seiner ISBNNummer erwhnt.

urn:isbn:978-3-540-33993-9

Diese URN referenziert auf ein Buch, reprsentiert durch dessen ISBN-Nummer, ohne eine Angabeber dessen Ort zu treffen.

Der Begriff Internationalized Resource Identifier10 (IRI) wurde in [DS05] definiert und erweitert dieDefinition der URI um den verwendbaren Zeichensatz. Bei IRIs knnen alle im Unicode11 definiertenZeichen zur eindeutigen Identifikation von Ressourcen verwendet werden.

2.3 Web-Applikation

Der Begriff der Web-Applikation (oder auch Webanwendung beziehungsweise Web-basierte Anwen-dung) wird in der Literatur sehr umfassend beschrieben und lsst sich sehr verschiedenartig subka-tegorisieren. In diesem Abschnitt wird ein kurzer berblick zur grundlegenden Architektur Web-basierter Anwendungen gegeben. Im Abschnitt 2.1 wurde der ursprngliche Gedanke benannt, derzur Entwicklung des WWW fhrte. Daraufhin wurden hauptschlich statische Dokumente in ent-sprechenden Formaten verffentlicht, welche wiederum mittels den in Abschnitt 2.2 eingefhrtenURLs vernetzt werden konnten. Wie beschrieben, sind URLs einem Schema entsprechend aufge-baut und enthalten den Namen des Protokolls sowie den Ort, an dem sich das Dokument befindet.

6HTTP/1.0: RFC1945 und HTTP/1.1: RFC26167FTP: RFC9598URL: RFC17389URN: RFC2141

10IRI: RFC398711Unicode: ISO 10646

2 GRUNDLAGEN 7

Zur Kommunikation zwischen Server (Datenquelle) und Client (Datensenke) im WWW wird dasHTTP-Protokoll benutzt. Damit ein Server eine HTTP-Anfrage (HTTP-Request) zum Senden einesDokumentes beantworten kann, bentigt dieser ein spezielles Programm, den Webserver. Dieser in-terpretiert die bergebene URL und adressiert daraufhin das gewnschte Dokument, um eine Kopiedavon im folgenden Schritt an den Client zu senden. Webserver und Web-Clients haben sich seitBeginn des WWW sehr schnell weiterentwickelt und sind in ihrem Funktionsumfang wesentlich dif-ferenzierter als frhere Versionen. Zustzlich zur direkten Adressierung von statischen Dokumentenbieten Webserver die Mglichkeit, Erweiterungen der Webserver-Funktionalitt (Module) oder aberauch externe Programme zur Generierung dynamischer Dokumente zu benutzen. Beide Mglichkei-ten knnen zur Realisierung serverseitiger Web-Applikationen verwendet werden. Zumeist wird dieAuszeichnungssprache Hypertext Markup Language (HTML) [RHJ99] zur Festlegung der logischenStruktur eines Dokumentes benutzt. Dokumente diesen Formates werden von speziellen Clients, denWeb-Browsern, entgegengenommen und in einer graphischen Reprsentation dargestellt, die zustz-lich in weiteren Formaten festgelegt werden kann, wie beispielsweise Cascading Style Sheets (CSS)[BeHL07]. Zudem ermglichen Web-Browser die Benutzerinteraktion mit der serverseitigen Web-Applikation, welche durch Technologien wie ActiveX 12, Flash ActionScript13, JavaScript[Int99] undasynchroner Datenbertragung (vgl. Abschnitt 5.3.2) weiter verstrkt werden kann. Web-Browser las-sen sich somit als clientseitige Web-Applikationen bezeichnen [Tur99].

In dieser Arbeit wird der Begriff Web-Applikation nicht anhand dieser Trennung, sondern als Drei-Schichten-Architektur (3-Tier-Architektur) betrachtet. In diesem Architekturmuster wird eine An-wendung in Prsentationsschicht (client tier), Logikschicht (business tier) und Datenhaltungsschicht(data server tier) unterteilt. Die erste Schicht ist fr die Erzeugung der Benutzerschnittstelle zur Ein-gabe und Ausgabe von Daten verantwortlich, die zweite fr die Programmlogik und die letzt genanntezur Speicherung und dem damit verbundenen Zugriff auf die Daten. Somit ergibt sich folgende Defi-nition:

Definition 1 (Web-Applikation) Eine Web-Applikation kann folgendermaen charakterisiert wer-den:

1. Sie ist ein in einer adquaten Programmiersprache implementiertes Programm, dass auf einemWebserver ausgefhrt wird.

2. Ihre Ausfhrung wird mit Hilfe des HTTP-Protokolls zur Kommunikation unter der Nutzungvon URLs gestartet und gesteuert.

12http://activex.microsoft.com/activex/activex/13http://livedocs.adobe.com/flash/9.0_de/main/

http://activex.microsoft.com/activex/activex/http://livedocs.adobe.com/flash/9.0_de/main/

2 GRUNDLAGEN 8

3. Nach Ausfhrung erfolgt eine adquate Ausgabe der Ergebnisse in einem vom W3C spezifi-zierten Format zur Reprsentation im Web-Browser (z.B. die Formate HTML, CSS, XML) odereinem anderen HTTP-Client.

Eine Web-Applikation ist meist entsprechend einer Drei-Schichten-Architektur konzipiert und enthlteine Prsentationsschicht, Logikschicht und, falls Daten in der Web-Applikation vorgehalten werden,auch eine Datenhaltungsschicht.

2.4 Reprsentationssprachen fr Wissensbasen

Um den Ansprchen des Semantic Web gerecht zu werden, hat das World Wide Web Consortium(W3C) grundlegende Standards schaffen mssen. Zum einen mssen Informationen in einer ma-schinenlesbaren Art und Weise zur Verfgung gestellt werden und andererseits sind einheitliche undoffene Standards zu schaffen, die fr den Informationsaustausch zwischen verschiedenen Anwendun-gen bentigt werden (Interoperabilitt) und gleichzeitig Flexibilitt und Erweiterbarkeit ermglichen[HKRS07]. Aus diesen Anforderungen resultierten die Informationsspezifikations-Sprachen RDF(S)[Bec04; BG04] und OWL [PSHH04], zu denen auch XML gehrt. RDF(S) und OWL werden auchals Ontologiesprachen bezeichnet und wurden speziell fr das Semantic Web geschaffen. Auf denBegriff der Ontologie wird im Abschnitt 2.5 noch nher eingegangen.

RDF Mit dem Resource Description Framework (RDF) knnen Daten strukturiert, Informationenber Daten (Metadaten) und Vernetzungen der Daten ausgedrckt und in einer durch Maschinen in-terpretierbaren Form gespeichert werden. Eines der bekanntesten Metadatenschemata ist Dublin Core(vgl. Abschnitt 4.2), welches zur Beschreibung von Dokumenten dient. Mit Dublin Core knnen un-ter anderem die Sprache des Dokumenteninhaltes sowie der Autor, der Titel und der Herausgeber desDokumentes beschrieben werden. Dieses Schema enthlt zudem auch Mglichkeiten, Dokumente mitanderen Dokumenten zu vernetzen. Im RDF Modell sind die drei Objekttypen Ressource (Subjekt),Eigenschaft (Prdikat) und Objekt definiert, welche kombiniert ein RDF-Tripel bilden. Diese Tripelwerden auch als Statement bezeichnet, mit denen man Aussagen ber physikalische oder abstrakteObjekte innerhalb einer Domne festlegt. Weiterhin bilden Statements selbst Ressourcen ber diesewieder Aussagen getroffen werden knnen. Das Bilden von Aussagen ber Aussagen wird Reifikati-on [MM04] genannt. Tripel hneln der Struktur von einfachen Aussagestzen mit transitiven Verben.Das Subjekt ist das Element eines Tripels, ber welches eine Aussage getroffen wird. Das Prdikathat wie in natrlichsprachlichen Stzen, die Funktion etwas ber das Subjekt auszudrcken und ver-bindet somit das Subjekt mit dem Objekt. Der Wert des Prdikats wird durch das Objekt reprsentiert,welches entweder eine Literal (trivialer Datentyp) oder wieder eine Ressource oder gar leer (BlankNode) sein kann.

2 GRUNDLAGEN 9

Darstellungskonvention: Ressourcen als ovale Knoten, Prdikate als mit URI-Referenzenbeschriftete und gerichtete Kanten und Literale als rechteckige Knoten

Quelle: [Bec04]

Abbildung 2: Beispiel fr die Darstellung von RDF als Graph

RDF kann in verschiedenen Notationsformen gespeichert werden, wie beispielsweise Notation 3 (N3)[BLC08], RDF/XML [Bec04] und Turtle [BBL08]. Aufgrund der guten Lesbarkeit wurde fr Men-schen der RDF-Graph, ein gerichteter Graph zur Visualisierung von Tripel-Mengen, als Standardent-wicklungsmethode vom W3C erklrt (siehe Abbildung 2).

RDFS Mit RDF lassen sich Daten durch genannte Tripel beschreiben. Um einen Austausch vonDaten so zu gewhrleisten, dass diese Daten bei Datenquelle und Datensenke gleichermaen inter-pretiert werden knnen, wird ein Vokabular fr die entsprechende Domne bentigt, welches mit-tels dem Resource Description Framework Schema (RDFS) definiert werden kann. Das genannteMetadatenschama Dublin Core ist ein solches Vokabular, welches, wie jedes andere in RDFS defi-nierte Vokabular auch, durch einen Namensraum (Namespace) eindeutig identifizierbar ist. Der Na-mensraum von Dublin Core ist http://purl.org/dc/elements/1.1/. RDFS basiert aufeinem mengentheorethischen Klassenmodell, in welchem Klassen und Eigenschaften separat mo-delliert werden. Dieses Konzept ermglicht die formale Beschreibung der Semantik der in RDFdefinierten Elemente. In RDF existiert zur Typisierung von Ressourcen nur das rdf:type-Element( http://www.w3.org/1999/02/22-rdf-syntax-ns#type), welches im RDF Namens-raum definiert ist. In RDFS sind weitere Ressourcen zur Typisierung vorhanden, die unter anderemeine Definition von Klassen, Relationen zwischen Eigenschaften und Klassen und Relationen vonKlassen untereinander erst ermglichen. RDFS ist ebenfalls wieder ein Vokabular, in welchem bei-spielhaft die folgenden ausgewhlten Bezeichner durch die vollstndige URI beziehungsweise mittelseines definierten Prefixes dem RDFS Namensraum zugeordnet werden.

2 GRUNDLAGEN 10

1. http://www.w3.org/2000/01/rdf-schema#Class oder rdfs:Class

2. http://www.w3.org/2000/01/rdf-schema#SubClassOf oder rdfs:SubClassOf

3. http://www.w3.org/2000/01/rdf-schema#label oder rdfs:label

4. http://www.w3.org/2000/01/rdf-schema#domain oder rdfs:domain

5. http://www.w3.org/2000/01/rdf-schema#range oder rdfs:range

6. und so weiter ...

Mit dem ersten Bezeichner lsst sich eine Ressource als Klasse auszeichnen. Der zweite Bezeich-ner wird prdikativ verwendet und definiert eine als Klasse ausgedrckte Ressource als Subklasseeiner weiteren Klasse. Der dritte Bezeichner wird verwendet, um Ressourcen eine unter Umstndenauch sprachabhngige Bezeichnung (Label) zuzuweisen. Hierzu wird der Eigenschaft rdfs:labeldas Attribut xml:lang aus dem XML-Vokabular und die entsprechende Sprachetikette als Werthinzugefgt. Mittels des vierten und fnften Bezeichners werden Relationen zwischen Klassen undEigenschaften (Properties) hergestellt. Somit knnen auch Assoziation zwischen Klassen aufgebautwerden. Aufgrund der Existenz der Klasse rdfs:Datatype beziehungsweise rdfs:Literalin RDFS, kann mittels rdfs:domain einer Eigenschaft auch dieser sehr allgemeine Datentyp zu-gewiesen werden. Dies wird allerdings in der im Folgenden beschriebenen Ontologiesprache OWLnoch erweitert. Weitere Anstze, die neben RDFS entstanden, sind Frame Logic (F-Logic) [AL04]und Darpa Agent Markup Language + Ontology Inference Layer (DAML+OIL) [HM00].

OWL Die Ontology Web Language (OWL) wurde 2004 vom W3C als Ontologiesprache standardi-siert (Zum Begriff der Ontologie vergleiche Abschnitt 2.5). Diese Sprache erweitert das RDFS Voka-bular, weshalb im Schichtenmodell des Semantic Web (siehe Abbildung 1) OWL oberhalb von RDFSpositioniert wurde. RDFS ist weniger ausdrucksstark als OWL und ist fr komplexe Zusammenhngenicht ausreichend. Allerdings mussten bei der Schaffung von OWL ebenfalls einige Schwierigkeitenberwunden werden. Je differenzierter die Ausdrucksmglichkeit von Sprachkonstrukten einer Spra-che fr implizites Wissen ist, desto grer sind die Komplexitten (schlechte Skalierbarkeitseigen-schaft) und die Wahrscheinlichkeit von Unentscheidbarkeit [HKRS07]. Um dieses Problem zu lsen,also einerseits die Ausdrucksmchtigkeit nicht zu beschrnken und andererseits effizientes Schluss-folgern zu ermglichen, wurde sich darauf geeinigt, sich je nach Anforderung fr eine geeigneteAusdrucksmchtigkeit zu entscheiden. Daraufhin entstanden drei unterschiedliche Teilsprachen vonOWL. Die ausdrucksstrkste Teilsprache ist OWL Full. Diese enthlt das komplette RDFS Vokabular,ist allerdings unentscheidbar und wird von aktuellen Software-Werkzeugen nur bedingt untersttzt.Aufgrund der nicht vorhandenen Beschrnkungen dieser Sprache (alle OWL Sprachelemente drfen

2 GRUNDLAGEN 11

gemeinsam mit den RDF(S) Sprachelementen genutzt werden) sind prdikatenlogische Ausdrckehheren Grades mglich. Die Teilsprachen OWL Full und OWL Lite benutzen das gleiche Vokabu-lar, obgleich OWL Lite einigen Einschrnkungen unterliegt. Die wichtigste Einschrnkung ist dabeidie Typenunterscheidung. Als Beispiel hierfr wird in [MvH04] angefhrt, dass eine Klasse nichtgleichzeitig eine Instanz (Individual) oder Eigenschaft (Property) sein kann. Die Teilsprache OWLDL ist entscheidbar und wird derzeit von Software-Werkzeugen fast vollstndig untersttzt. Der Zu-satz DL steht dabei fr description logic (Beschreibungslogik). Die ermglichte Semantik von OWLDL kommt der von DAML+OIL am nchsten und ist zu einem Fragment der Prdikatenlogik ersterStufe (first order logic) quivalent. Um die Entscheidbarkeit der Teilsprache OWL DL zu ermg-lichen, mussten einige Einschrnkung definiert werden. Als Beispiel lsst sich hierfr das Verbotanfhren rdfs:Class und rdf:Property zu verwenden. Weitere Einschrnkungen wie die derBestimmungen zu Typentrennungen und Deklarationen sowie der Einschrnkungen zu abstrakten undkonkreten Rollen sind in der W3C-Empfehlung (W3C Recommendation) zu OWL [PSHH04] nach-lesbar. Die dritte Teilsprache von OWL ist OWL Lite. Diese ist eine Teilmenge von OWL DL undsomit logischerweise ebenfalls entscheidbar. Sie ist weniger ausdrucksstark als die anderen Teilspra-chen. OWL Lite enthlt nur die wichtigsten Sprachelemente und weit deshalb auch eine geringereKomplexitt auf. Die Menge an Einschrnkungen fr OWL DL, wird bei OWL Lite noch erweitert.So sind beispielsweise die Benutzung von Klassenkonstruktoren und Zahlenrestriktionen beschrnkt.Weiterhin sind in manchen Situationen Klassennamen und Rollenrestriktionen vorgeschrieben. Wei-tere Einschrnkung sind ebenfalls in der W3C-Empfehlung zu OWL auffindbar.

2.5 Folksonomy und Ontologie

Konzepte zur Reprsentation von Informationen knnen hinsichtlich ihrer semantischen Reichhal-tigkeit in verschiedene Stufen eingeteilt werden, was in Abbildung 3 verdeutlicht wird. Der Begriff

Quelle: [BP06]

Abbildung 3: Semantische Treppe

2 GRUNDLAGEN 12

der Folksonomy und der Ontologiebegriff werden in diesem Abschnitt nher erlutert, da diese unteranderem im Semantic Web eine entscheidende Rolle einnehmen.

Der Begriff der Folksonomy In sozialen Netzwerke (social web), die zur gemeinsamen Verschlag-wortung(Tagging) von Ressourcen unterschiedlichen Typs entwickelt wurden, entstehen Beziehungs-netzwerke aus Schlagwrtern (Tags), Benutzern (User) und Ressourcen [CS06]. Benutzer erhaltendadurch die Mglichkeit sich in einem solchen Netzwerk durch das Beitragen von Wissen zu pro-filieren und selbst vom gesammelten Wissen anderer Benutzer zu profitieren. Ein so entstehendesBeziehungsnetzwerk wird als Folksonomy bezeichnet und lsst sich wie folgt formal definieren (ausQuelle: [CS06] entnommen):

Definition 2 (Formales Folksonomy Modell) Eine Folksonomy ist ein Tupel F := (U, T, R, Y) wobei

U, T, R endliche Mengen sind, deren Elemente man Users, Tags, und Ressourcen nennt,

Y eine ternre Beziehung zwischen diesen ist, d.h. Y U T R gilt.

Beispiele fr Web-Applikationen, die eine Folksonomy benutzen, sind Flickr14 (Ressourcentyp Bil-der), del.icio.us15 (Ressourcentyp Bookmarks) und BibSonomy16 (Ressourcentypen Bookmarks undBIBTEX-Eintrge). Die obige Definition 2 lsst sich durch die Definitionen von Untertag/Obertag-Beziehungen und Personomy eines Benutzers (Einschrnkung von F auf u mit u U ) weiter verfei-nern, wie in der benutzen Folksonomy von BibSonomy bentigt. Grob umrissen ist eine Personomydie Menge von Schlagwrtern fr Ressourcen eines konkreten Benutzers. Alle Personomies einesSystem zusammengenommen ergeben dann die Folksonomy des entsprechenden Systems.

Der Begriff der Ontologie Im Gegensatz zur Folksonomy ist der Ontologie-Begriff im Bezug aufihre semantische Reichhaltigkeit sehr weit fortgeschritten (vgl. Abbildung 3). Der Begriff der Onto-logie wird allerdings in der Literatur und in verschiedenen Wissenschaftsbereichen unterschiedlichdefiniert. In der Philosophie wird dieser Begriff beispielsweise als die Lehre vom Sein oder von denMglichkeiten und Bedingungen des Seienden beschrieben. Im Gegensatz dazu formulierte Tom Gru-ber dies in [Gru93] folgendermaen:

[...]An Ontology is an explicit specification of a shared conceptualization[...]14http://www.flickr.com15http://del.icio.us/16http://www.bibsonomy.org

http://www.flickr.comhttp://del.icio.us/http://www.bibsonomy.org

2 GRUNDLAGEN 13

Also eine explizite Spezifikation einer gemeinsamen Konzeptualisierung. Diese Definition ist im Be-reich des Semantic Webs verwendbar und ermglicht, den Begriff der Ontologie folgendermaen zuabstrahieren [Hes02]:

[...]Eine Ontologie beschreibt einen Wissensbereich (knowledge domain) mit Hilfeeiner standardisierten Terminologie sowie Beziehungen und ggf. Ableitungsregeln zwi-schen den dort definierten Begriffen. Das gemeinsame Vokabular ist in der Regel in Formeiner Taxonomie gegeben, die als Ausgangselemente Klassen, Relationen, Funktionenund Axiome enthlt.[...]

Somit kann Wissen einer Domne mit Ontologien formal reprsentiert werden, ohne dabei die Nut-zung spezieller Programme zur Wiederverwendung voraus zusetzen. Dies ermglicht es Semantikstrukturierter beziehungsweise semi-strukturierter Informationen auszudrcken, was eine Unifikati-on und Transformation zwischen verschiedenen Formen der Wissensreprsentation ermglicht. Zu-stzlich zu den Domnen-spezifischen Ontologien (domain ontologies) gibt es noch bereichsber-greifende Ontologien (top level ontologies), die genauso in den folgenden Anwendungsfeldern derInformatik benutzt werden knnen [GL02] :

Kommunikation zwischen Maschinen, Kommunikation zwischen Mensch und Maschine, Kom-munikation zwischen Menschen,

automatisches Schlussfolgern

Reprsentation und Wiederverwendung von Wissen

Im weiteren Verlauf der Arbeit wird als Pendant zum Begriff der Ontologie auch der Begriff Wis-sensbasis benutzt. Damit sind ebenfalls schematische Informationen und Regeln sowie die Menge anDaten gemeint, die das definierte Vokabular zur Reprsentation nutzen.

3 VORSTELLUNG DES ANWENDUNGSFALLS 14

3 Vorstellung des Anwendungsfalls

Wie im weiteren Verlauf dieser Arbeit noch gezeigt wird, werden bei semantischen Web-Applikationen im Vergleich zu herkmmlichen Web-Applikation die gleichen , hnliche aber auchgesonderte Technologien zur Speicherung, Verarbeitung und Anzeige von Daten benutzt. Zur Vorstel-lung dieser Verfahrensweisen wird unter anderem der in diesem Kapitel vorgestellte Anwendungsfallvakantieland.nl [Mar07] herangezogen.

Die Web-Applikation vakantieland.nl ist ein ehemals in den Niederlanden entwickeltes und ebenfallsdort verffentlichtes Tourismusportal. In diesem knnen Benutzer einen umfassenden berblick bermgliche touristische Ziele (folgend Point of Interest oder kurz als POI bezeichnet) erhalten. Zudemwerden zu jedem einzelnen POI relevante und weitergehende Informationen gehalten und verffent-licht. Ein Beispiel hierfr wre ein konkretes Museum in Amsterdam, welches unter anderem durchdessen Namen, Anschrift und Klassifizierung aber auch durch die ffnungszeiten, Lage in der Stadtund in dessen Umgebung vorhandenen POIs beschrieben sein knnte.

Im Folgenden werden die Vorgngerversion, die Motivation zur Neuentwicklung und die Anforde-rungen sowie der Aufbau der aktuellen Version vorgestellt.

3.1 Die Ausgangssituation

Die Vorgngerversion von vakantieland.nl produzierte die Darstellung genannter touristischer Zielemittels einer in Active Server Pages (ASP) geschriebenen Web-Applikation. Alle textuellen Informa-tionen zu den einzelnen POIs waren in einer nicht-normalisierten relationalen Datenbank gespeichertund wurden mittels der Structured Query Language (SQL) von der Applikation abgerufen. Wie inAbbildung 4 zu sehen, wurde eine Liste von POIs entsprechend gegebener Suchbegriffe beziehungs-weise einer zuvor ausgewhlten Kategorie angezeigt. ber diese Liste konnte man sich ein entspre-

Abbildung 4: Vorgngerversion vakantieland.nl bersichtsseite


chendes touristisches Ziel auswhlen und die dazugehrigen Detailseiten erreichen. In Abbildung 5und Abbildung 6 sind die zwei Detailsseiten zu sehen, auf denen der Besucher der Web-Applikationdie Adress- und Kontaktdaten beziehungsweise die Beschreibung und die am POI gespeicherten Leis-tungen in Erfahrung bringen konnte. Es existierten noch weitere Detail-Seiten, auf denen falls vor-handen Broschren und Bilder sowie eine Umgebungskarte dem Nutzer zur Verfgung gestelltwurden. Die Umgebungskarte enthielt andere in der Umgebung liegende POIs, die entsprechend derBildkoordinaten des angezeigten Kartenausschnitts angezeigt wurden.

Des Weiteren konnten Daten, mittels eines in Visual Basic for Applications (VBA) geschriebe-nen XML-Exports, entsprechend verschiedener Kriterien extrahiert werden um diese auf ande-ren Web-Seiten wie beispielsweise http://www.startpagina.nl anzuzeigen. Die durchdie Applikation verarbeiteten Informationen konnten entweder direkt ber ein Datenbank-Administrationsprogramm aber auch ber einem Administrationsmodus der vakantieland.nl-Oberflche hinzugefgt, modifiziert und gelscht werden.

Abbildung 5: Vorgngerversion vakantieland.nl Detailseite Adresse

3.2 Motivation zur Neuentwicklung

Derzeit sind in etwa 20.000 POIs in der Web-Applikation vakantieland.nl enthalten. Zu sehr vielen invakantieland.nl registrierten touristischen Zielen sind Informationen vorhanden, die sich oft ndernknnen (Kontaktdaten, Broschren, Veranstaltungen, ffnungszeiten, Angebote und so weiter). Weildiese Daten vom Betreiber von vakantieland.nl selbst hinzugefgt und gepflegt werden mssen, sinddiese nicht immer auf dem aktuellsten Stand beziehungsweise nicht vollstndig.

Aufgrund dieser Ausgangssituation wurden Ideen geuert, zum einen die anzeigbare Informations-menge zu erhhen, diese maschinell interpretierbar zu gestalten und den Wartungsaufwand der Daten

http://www.startpagina.nl


Abbildung 6: Vorgngerversion vakantieland.nl Detailseite Beschreibung

zu verringern. Um dies zu bewerkstelligen, bieten sich die im Abschnitt 2.1 zum Semantic Webgenannten Mglichkeiten an. Zum einen lassen sich bestehende Datenbestnde semantisch annotie-ren (Speicherung in einer Ontologie) und zum anderen weitere Daten anderer Wissensbasen abfra-gen. Der Wartungsaufwand lsst sich durch eine strkere Einbindung der relativ groen Benutzer-Gemeinschaft (folgend als Community bezeichnet) verringern. Benutzer, die weitere Informationenzum entsprechenden POI besitzen, knnten diese in die neu zu erstellende Wissensbasis mit ein-bringen oder mglicherweise auch veraltete Informationen direkt ndern. Durch die Speicherung derDaten in einer Ontologie wre die Applikation in der Lage, diese Daten intern mit semantischen Tech-nologien selbst zu verarbeiten und zudem auf verschiedene Art und Weise dem Nutzer zur Verfgungzu stellen. Weiterhin werden unter dem Begriff Web2.017 diverse Technologien beschrieben, die eineBenutzbarkeit der Seite weiter erhhen knnten. Diese werden im folgenden Verlauf der Arbeit nochweiter ausgefhrt.

17http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.

html

http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.htmlhttp://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html


3.3 Vorstellung der aktuellen Version

Von einer mglichen Erweiterung der Applikation wurde abgesehen, um fehlerhafte Designentschei-dungen der Vorgngerversion nicht in die neu zu erstellende Applikation mit aufzunehmen. Zudemhtten in allen bestehenden Komponenten nderungen vorgenommen werden mssen, was ein kom-plettes berarbeiten bestehenden Quellcodes erfordert htte und durch die zuvor benutzte Scriptspra-che ASP wren Hrden bei der Benutzung aktueller APIs zu berwinden gewesen.

Im Folgenden werden die Anforderungen an die neu erstellte Web-Applikation aufgelistet, das Ent-wicklungsvorgehen skizziert und die Designentscheidungen sowie der aktuelle Stand vorgestellt.

3.3.1 Anforderungen

Eine vor Projektbeginn gefhrte Anforderungsanalyse fhrte zu folgender Auflistung von Anforde-rung. Die darin enthaltenen Punkte sind als Mindestkriterium aufzufassen und mssen somit erflltwerden.

1. Reimplementierung bestehender Funktionalitten: Die neu zu erstellende Applikation sollmindestens den Funktionsumfang wie die zuvor vorhandene Applikation enthalten. Dazu ge-hren folgende Hauptfunktionalitten:

(a) Einschrnkung der Menge anzuzeigender POIs mittels Kategorienauswahl

(b) Einschrnkung der Menge anzuzeigender POIs mittels der Eingabe von Suchbegriffen

(c) Auflistung der POIs entsprechend einer gewhlten Kategorie und/oder Suchbegriffen

(d) Auswahl eines konkreten POIs und Anzeige von Detailinformationen (Address- und Kon-taktdaten, Beschreibungen, Kategorien, Umgebungskarte, Broschren und Fotos)

(e) Anzeige statischer Seiten mit Informationen wie Impressum und Partner

(f) Administrierbarkeit der Daten

2. Datenhaltung: Die Speicherung der semantisch annotierten Daten in einem flexiblen Informa-tionsmodel wird gefordert.

3. Datenimport: Die existierenden Datenbestnde sind mittels einer adquaten Funktion aus derrelationalen Datenbank auszulesen und in das neu zu erstellende Repository zu importieren.

4. Ausgabe der Daten: Die Informationen sollen semantisch annotiert ausgegeben werden. Zu-dem soll die zu entwickelnde Web-Applikation Mehrsprachigkeit untersttzen.


5. Kartendarstellung: Die Benutzung ffentlich verfgbaren Kartenmaterials zur Anzeige vontouristischen Zielen mittels deren Koordinaten ist gewnscht.

6. Performanz: Geringe Ausfhrungszeiten (im Optimalfall hnlich die der Vorgngerversion)sind erforderlich.

7. Ausbau des Funktionsumfanges: Erweiterung des Funktionsumfanges um Funktionen, wel-che die Bedienbarkeit verbessern, die Community in die Erweiterung und Pflege des Datenbe-standes integriert und Funktionen, die der Vergrerung der Informationsmenge dienen.

Der genannte Punkt zur Administrierbarkeit der Daten ist in den Anforderungen nher spezifiziertgewesen. Hierfr wurde Ontowiki [ADR06], ein Werkzeug zur Untersttzung von agilen, verteil-ten Knowledge Engineering Szenarios, gefordert. Dieses Werkzeug ermglicht die Darstellung undVerwaltung von Wissensbasen und kann somit, hnlich einem Administrationsprogramm fr Daten-banken, als Managementwerkzeug fr Ontologien eingesetzt werden.

3.3.2 Entwicklungsvorgehen

Auf Basis des sehr geringfgig ausgearbeiteten Anforderungsdokumentes konnte kein klassischesVorgehensmodell zur Entwicklung der neuen Applikationsversion herangezogen werden. Einige derzu verwendenden APIs, die im weiteren Verlauf der Arbeit noch aufgefhrt werden, waren zum Pro-jektbeginn noch nicht stabil genug, um eine Abschtzung ber deren Funktionsumfang und Anwend-barkeit abzugeben. Zudem war aufgrund der Vielfalt an technischen Mglichkeiten zur Umsetzungder genannten Anforderungen zu diesem Zeitpunkt noch keine genaue Spezifikation mglich. Somitwurde die Entscheidung getroffen die Implementierung mittels des agilen Vorgehensmodels evolutio-nres Prototyping[BJK02] zu beginnen. Im evolutionren Prototyping ist verankert, dass ein initialerPrototyp der Applikation implementiert wird, welcher nach und nach bis zur Produktreife weiterzu entwickeln ist. Zwischen den einzelnen Implementierungsschritten wird einer kleinen Anwender-gruppe inklusive dem Auftraggeber Zeit fr Feedback gegeben, welches direkt in die weitere Imple-mentierungsarbeit mit einfliet.

3.3.3 Designentscheidungen und Darstellung der aktuellen Version

Aufgrund der Forderung, dass das in PHP (PHP Hypertext Preprocessor) implementierte Ontowikials Ontologie-Administrationsprogramm zu benutzen ist, wurde die Entscheidung zur Verwendungvon PHP fr die Implementierung der neuen Version von vakantieland.nl gefllt. Zudem enthlt Onto-wiki ein Plugin-System und eine Widget-Bibliothek, die Elemente fr die Erstellung von graphischenOberflchen in Web-Applikationen zur Verfgung stellt.


Abbildung 7: Architektur des Redesigns von vakantieland.nl

Weiterhin fiel eine Entscheidung zu Gunsten des weit verbreiteten Architekturmusters Model ViewControl (MVC) [Ree03], um Komponenten unabhngig von einander entwickeln zu knnen. Auf-grund dessen, dass die bestehenden Informationen ber POIs in einer Ontologie zu beschreiben sind,musste ein geeignetes Datenhaltungssystem und eine adquate API eruiert werden, mittels welcherdie Daten den anderen Ebenen der Web-Applikation zur Verfgung gestellt werden. Wie in Abbil-dung 7 zu sehen ist, wurde sich fr eine Speicherung in einem datenbankgesttzten RDF-Triple-Storeentschieden, dessen grundlegender Aufbau und Verwendung in Abschnitt 5.2.2 beschrieben wird. DiepOWL-API [Aue06] wurde zu Beginn der Entwicklung als Abstraktionsschicht verwendet, um die imRDF-Triple-Store enthaltenen Daten abzufragen. Diese pOWL-API bezieht als Ressourcen gekapsel-te Informationen mittels der RDF-API for PHP (RAP) [OBW06] aus genanntem RDF-Triple-Store,um diese der anfragenden Applikation als komplexe Objekte zur Verfgung zu stellen.

Aufgrund der Eigenschaft, dass Schema und Daten innerhalb einer Ontologie gespeichert werdenknnen, kann auf applikationsseitig implementierte Model-Klassen verzichtet werden. Trotzdem ent-hlt die Modelkomponente der hier vorgestellten Web-Applikation eine Klassenstruktur, die den Zu-griff auf die Ontologie kapselt. Dies ermglichte den spteren Umstieg auf die Erfurt-API, ein ob-jektorientiertes Redesign der pOWL-API. Durch die Nutzung der Erfurt-API wurde weiterhin dieMglichkeit geschaffen, Anfragen an den RDF-Triple-Store mit SQL grtenteils zu umgehen. Dieswurde durch einen in der RAP-API integrierten SPARQL-Prozessors [Wei07] ermglicht, der Anfra-gen in der auf Eigenschaften von RDF spezialisierten Anfragesprache SPARQL (SPARQL Protocoland RDF) [CFT08] verarbeitet.

Zur kartographischen Visualisierung der POIs wird die Google Map API eingesetzt, wie in Abbildung


8 zu sehen ist. Diese API bietet ein groes Spektrum an Mglichkeiten zur Konfiguration der darge-stellten Karten und den darauf anzuzeigenden Punkten. Weiterhin knnen Geo-Koordinaten mittelsspezieller Web-Services von Google abgerufen und in gewnschten Formaten empfangen werden.

Die Merkmale der einzelnen POIs mssen semantisch annotiert sein, um eine eindeutige maschinel-le Interpretation der Daten zu ermglichen. Einerseits sind die Daten innerhalb der HTML Ausgabe(siehe Abbildung 9) mittels geeigneter Microformats beziehungsweise durch RDFa mit Semantikanzureichern und andererseits in RDF eingebettet auszugeben (vgl. Abschnitt 6.3 und 6.4). Im Ka-pitel 6 sind der Aufbau und die Implementierung ausgewhlter implementierter Programmfragmenteskizziert sowie verschiedene Funktionalitten, die in weiteren Entwicklungsphasen hinzukommenwerden. Dazu gehrt die Anreicherung der Informationsmenge mittels der Abfrage von DBpedia[ABL+07], sowie die Integration eines SPARQL-Endpoints.

Abbildung 8: bersichtsseite von vakantieland.nl

Abbildung 9: Detailseite von vakantieland.nl mit Kontakt und Addressdaten

4 STAND DER TECHNIK 21

4 Stand der Technik

Zur Entwicklung von Web Applikationen sind in den verschiedenen softwaretechnischen Phasen di-verse Designentscheidungen zu treffen. So muss beispielsweise ein entsprechendes Werkzeug zurModellierung des Datenmodells gefunden werden, welches unter Anderem hinreichende Unterstt-zungsmglichkeiten zur Vermeidung von Fehlern bietet. Weiterhin sind mglicherweise Entscheidun-gen zu Bezugsquellen externer Daten und applikationsinternen Datenverwaltung zu fllen. In diesemKapitel werden ausgewhlte Werkzeuge, Vokabulare, DataSets und APIs vorgestellt, die Verwendungim Semantic Web bei der Entwicklung von Web Applikationen finden.

4.1 Werkzeuge fr das Semantic Web

Bei der Entwicklung und zur Laufzeit von Web Applikationen knnen spezielle Werkzeuge zumEinsatz kommen. Werkzeuge die im Semantic Web untersttzend eingesetzt werden, lassen sich indie drei Kategorien Ontologie und Metadaten Editoren, Plugins und APIs sowie Reasoner unterteilen[BCT07]. Fr die Beschreibung von APIs sei auf Abschnitt 4.4 verwiesen. In Tabelle 1 sind eineAuswahl von Werkzeugen mit entsprechender Werkzeugkategorie gelistet, die folgend beschriebenwerden.

Werkzeug Kategorie LizenzDC-Dot Metadaten Editor -Ontowiki Ontologie Editor Gnu Public License (GPL)Protg Ontologie Editor Mozilla Public LicenseSWOOP Ontologie Editor MIT-LicenseJambalaya Protege Plugin freeOWLViz Protg Plugin Lesser GPL (LGPL)Piggy Bank Browser Plugin BSD-LicenseTails Browser Plugin MIT-LicenseTriplify Web Applikations Plugin LGPLD2R SPARQL-Endpoint GPLDL-Learner Reasoner GPL 3FaCT++ Reasoner GPLKAON2 Reasoner free for academic usePellet Reasoner MIT-LicenseRacerPro Reasoner free for academic use

Tabelle 1: Auswahl von Semantic Web Werkzeugen


Ontologie Editoren Die erste Kategorie von Semantic Web Werkzeugen sind Ontologie Editoren.Diese dienen einerseits der initialen Erzeugung von Ontologien und andererseits der Pflege darinenthaltener Informationen (Beides ist Teil des Ontology Engineering). Zudem stehen einigen Edi-toren Plugins zur Verfgung, die zur Verbesserung der Bedienbarkeit beitragen. Im Gegensatz zuMetadaten-Editoren (Beispiel: DC-Dot18), die beispielsweise HTML-Ausgaben von Web Applika-tionen nach Daten durchsuchen, um Informationen ber Informationen (Metadaten) mit einem spe-ziellen Vokabular auszudrcken (Dublin Core Vokabular bei DC-Dot), enthalten Ontologie-Editoreneinen wesentlich greren Funktionsumfang. In den Desktop-Applikationen Protg19 und SWOOP20

werden unter anderem die Sprachen RDF(S) und OWL (vgl. Abschnitt 2.4) benutzt, um Konzepte undDaten mit eigens entwickelten oder vorhanden Vokabularen zu definieren. Fr Protg stehen zudemviele Erweiterungen zur Verfgung, um Konzepthierarchien (OWLViz-Plugin21) und Abhngigkei-ten (Jambalaya-Plugin22) graphisch zu visualisieren. Weiterhin knnen in beiden Editoren Reasonereingebunden werden, um Inferenzen und Inkonsistenzen zu ermitteln. Wie im Abschnitt 2.1 erwhnt,werden Regeln benutzt, um definierte Informationen der Ontologie weiter zu spezifizieren. Ein mg-liches Format zur Definition von Regeln ist die Semantic Web Rule Language (SWRL) [HPSB+04].Hierfr existiert ebenfalls ein Protg-Plugin (SWRLTab23) mit dem Regeln in SWRL erzeugt, edi-tiert und angewendet werden knnen.

Ein weitere Mglichkeit zur Bearbeitung von Ontologien bietet Ontowiki24. Diese auf Wiki-Anstzenbasierende Web Applikation kann ebenfalls als Ontologie Editor benutzt werden. Die Standard-Oberflchen bieten eine generische Sicht auf die Konzepte und Daten importierter Ontologien.Darber hinaus werden Ontologien in einem RDFS-Triple-Store gespeichert und knnen kollabora-tiv manipuliert und erweitert werden. Durch die existierende Plugin-Schnittstelle kann Ontowiki alsBasis fr eine (auf eine oder mehrere konkrete Ontologie(n) und dem Anwendungsfall angepassten)Web Applikation dienen.

Reasoner Die nchste Kategorie von Semantic Web Werkzeugen sind Reasoner, die zumeist frdeduktives Reasoning Verwendung finden. Bis auf den Reasoner DL-Learner25 untersttzen die auf-gelisteten Reasoner nur deduktives Reasoning, was auch als logisches Schlussfolgern aus gegebenemWissen oder mit Inferenz beschrieben werden kann. Beispiele fr Implementierungen derartiger Me-

18http://www.ukoln.ac.uk/metadata/dcdot/19http://protege.stanford.edu20http://code.google.com/p/swoop/21http://www.co-ode.org/downloads/owlviz/22http://www.thechiselgroup.org/jambalaya23http://protege.cim3.net/cgi-bin/wiki.pl?SWRLTab24http://ontowiki.net/Projects/OntoWiki25http://dl-learner.org/Projects/DLLearner

http://www.ukoln.ac.uk/metadata/dcdot/http://protege.stanford.eduhttp://code.google.com/p/swoop/http://www.co-ode.org/downloads/owlviz/http://www.thechiselgroup.org/jambalayahttp://protege.cim3.net/cgi-bin/wiki.pl?SWRLTabhttp://ontowiki.net/Projects/OntoWikihttp://dl-learner.org/Projects/DLLearner


chanismen sind Pellet26, FaCT++27, KAON228 und RacerPro29. Der Reasoner DL-Learner untersttztzustzlich zu Inferenzmechanismen auch induktives Reasoning. Die Implementierung dieses in Javageschriebenen Werkzeuges benutzt einen der genannten deduktiven Reasoner (konfigurierbar), umauf Basis von Hintergrundwissen (In Ontologie definiert) und gegebener positiver und negativer Bei-spiele neue Konzepte zu erlernen, weshalb induktives Reasoning auch als Lernen bezeichnet wird. InAbbildung 10 ist die Architektur des Reasoners DL-Learner skizziert.

Quelle:http://aksw.org/Projects/DLLearner/Overview von Mai 2008

Abbildung 10: Architektur des induktiven Reasoner DL-Learner

Der DL-Learner wird in den nchsten Entwicklungszyklen des Ontowiki-Projektes durch ein noch zuentwickelndes Ontowiki-Plugin in Ontowiki integriert. Dadurch tritt der DL-Learner auch als Frame-work fr alle integrierten deduktiven Reasoner auf und ermglicht es, im Ontowiki und den daraufaufbauenden Web Applikationen induktives und deduktives Reasoning zu betreiben. Alle genann-ten Reasoner knnen bei der Ontologie-Erzeugung (und -Pflege) sowie als Basis fr diverse demAnwendungsfall entsprechenden Funktionen in Web Applikationen eingesetzt werden.

Plugins Die dritte Kategorie von Werkzeugen, die im Semantic Web Anwendung finden, sindPlugins. Plugins sind Erweiterungen von Applikationen jeglicher Art, die nicht integraler Bestand-teil dieser Applikationen sind und zustzliche Funktionalitten bieten. Einige Plugins, die bei derEntwicklung von Ontologien beispielsweise zur Visualisierung von Graphen benutzt werden kn-

26http://pellet.owldl.com/27http://owl.man.ac.uk/factplusplus/28http://kaon2.semanticweb.org/29http://www.racer-systems.com/

http://aksw.org/Projects/DLLearner/Overviewhttp://pellet.owldl.com/http://owl.man.ac.uk/factplusplus/http://kaon2.semanticweb.org/http://www.racer-systems.com/


nen, wurden in diesem Kapitel schon erwhnt. In Web Applikationen knnen, wie am Beispiel desOntowiki-Projektes erwhnt, ebenfalls Plugins zum Einsatz kommen. Eine einfache Mglichkeit frherkmmliche Web-Applikationen Daten zum Semantic Web beizutragen bietet Triplify 30. DiesesWeb-Applikations-Plugin extrahiert Daten aus relationalen Datenbanken und konvertiert diese in For-mate wie RDF, JSON (JavaScript Object Notation) oder Linked Data (vgl. auch Abschnitt 5.6). Wei-terhin knnen auch SPARQL-Endpoints in Web-Applikationen eingebunden werden, wie dies derD2R Server31 bietet.

Eine weitere Plugin-Art kann clientseitig in Web-Browsern wie beispielsweise dem Firefox32 einge-setzt werden. Derartige Plugins knnen verschiedenartige Einsatzmglichkeiten bieten. Ein Beispielhierfr ist Tails 33, einem Firefox-Plugin, welches in Web-Seiten benutzte Microformats erkennt undzur Anzeige bringt. Dabei werden die Microformats Contact Information (hCard), Calendar Infor-mation (hCalendar), Reviews (hReviews), Bookmarks (xFolk), Blog Entries (hAtom) ,Resumes (hRe-sume) und Map Coordinates (geo) untersttzt. Die mit Tails ermittelten Informationen knnen alsInput fr weitere Anwendungen wie beispielsweise dem lokalen Adressbuch oder einem Kalenderdienen. Eine weiteres Beispiel fr Firefox-Plugins ist Piggy Bank34. Mit diesem Werkzeug knnenunter anderem semantisch annotierte Informationen aus Web-Seiten, Tags und RSS-Feeds gespei-chert werden, um diese zu einem spteren Zeitpunkt in einer von Piggy Bank gestellten Oberflchezu durchsuchen, zu sortieren und mit anderen Benutzern zu teilen [HMK05].

4.2 Vokabulare im Semantic Web

Aufbauend auf den Sprachen RDF(S) und OWL knnen Vokabulare fr spezielle Einsatzzwecke ver-wendet oder erzeugt werden. In diesem Abschnitt wird ein Auszug der bekanntesten Vokabulare

Vokabular Prefix NamensraumDublin Core dc http://purl.org/dc/elements/1.1/FOAF foaf http://xmlns.com/foaf/0.1/Fresnel f http://www.w3.org/2004/09/fresnel#SIOC sioc http://rdfs.org/sioc/ns#SKOS skos http://www.w3.org/2004/02/skos/core#WGS84 wgs84 http://www.w3.org/2003/01/geo/wgs84_pos#

Tabelle 2: Prefixe und Namensrume bekannter Vokabulare30http://triplify.org31http://www.wiwiss.fu-berlin.de/suhl/bizer/d2r-server/32http://www.mozilla-europe.org/de/products/firefox/33http://blog.codeeg.com/tails-firefox-extension-03/34http://simile.mit.edu/wiki/Piggy_Bank

http://purl.org/dc/elements/1.1/http://xmlns.com/foaf/0.1/http://www.w3.org/2004/09/fresnel#http://rdfs.org/sioc/ns#http://www.w3.org/2004/02/skos/core#http://www.w3.org/2003/01/geo/wgs84_pos#http://triplify.orghttp://www.wiwiss.fu-berlin.de/suhl/bizer/d2r-server/http://www.mozilla-europe.org/de/products/firefox/http://blog.codeeg.com/tails-firefox-extension-03/http://simile.mit.edu/wiki/Piggy_Bank


(siehe Tabelle 2) vorgestellt, die im Semantic Web eingesetzt werden beziehungsweise bei der Ent-wicklung von Web Applikationen dienlich sind.

Dublin Core Zur Beschreibung von Dokumenten und anderen virtuellen Objekten erzeugte dieDublin Core Metadata Initiative35 (DCMI) eine Sammlung von Konventionen namens Dublin Core[PNNJ05]. Dieses Vokabular wird benutzt, um Metadaten wie beispielsweise Autor, Titel, Beschrei-bung, Format und Datum der Verffentlichung/nderung des Dokumentes zu definieren. Weiterhinlassen sich Eigenschaften zur Vernetzung von Dokumenten (Zitate, Referenzen etc.) aus diesem Vo-kabular benutzen. Das Dublin Core Vokabular kann unter anderem in RDF [MNN08], aber auch imheader eines HTML-Dokumentes als Meta-Tag [Pow03] benutzt werden.

FOAF (Friend of a Friend) Dieses zur Modellierung sozialer Netzwerke geschaffene Vokabular(spezifiziert in [BM05]), stellt semantische Konstrukte auf Basis von RDF(S) bereit, um unter ande-rem personenspezifische Angaben und Relationen zwischen Personen zu speichern. Hierbei knnenAussagen ber die eigene Person (Name, E-Mail-Adresse, Messenger-ID, Web-Seite, Interessen etc.),andere Personen, Gruppen und Organisationen sowie ber Dokumente, Bilder und Projekte getroffenwerden.

Fresnel Fresnel ist ein Vokabular zur anpassbaren Darstellung von RDF-Graphen [Fre05]. UmRDF-Graphen in Browsern adquat darzustellen gibt es die Mglichkeit diese mit Technologien wieXSLT [Cla99] zu transformieren. Dies ist in Abhngigkeit vom darzustellenden RDF-Graphen sehrkomplex wenn nicht gar unmglich. Fresnel bietet die Mglichkeit Darstellungsdefinitionen zu ko-dieren um diese entweder direkt an Browser auszuliefern [PBKL06], die dieses Vokabular zur Dar-stellung auswerten knnen, oder definierte Eigenschaften in Fresnel applikationsseitig auszuwertenund darzustellende Informationen mit CSS-Angaben zu verbinden. Letzteres ermglicht es browse-runabhngige Darstellungen des RDF-Graphen zu untersttzen. Browser, die das Fresnel-Vokabularauswerten knnen, sind beispielsweise Longwell36 und LENA37.

SIOC (Semantically Interlinked Online Communities) Das SIOC-Projekt38 bietet mittels demSIOC-Vokabular [sio07] die Mglichkeit, Online-Communities nher zu beschreiben. In SIOC sindKonzepte und Eigenschaften verankert, die unter anderem der Definition von Foren und Wikis so-wie deren Eintrgen und Autoren dienlich sind. Dieses Vokabular kann mit anderen Vokabularen

35http://dublincore.org/36http://simile.mit.edu/wiki/Longwell37http://isweb.uni-koblenz.de/Research/lena38http://sioc-project.org/

http://dublincore.org/http://simile.mit.edu/wiki/Longwellhttp://isweb.uni-koblenz.de/Research/lenahttp://sioc-project.org/


wie beispielsweise FOAF kombiniert werden, um Verbindungen zwischen persnlichen Profilen undInformationen aus sozialen Netzwerken zu modellieren.

SKOS (Simple Knowledge Organisation System) SKOS, entwickelt zu Reprsentation von Taxo-nomien, Thesauri, Klassenschemata und weiteren strukturierten und kontrollierten Vokabularen, bautebenfalls auf RDF(S) auf und bietet eine einfache Mglichkeit, genannte kontrollierte Vokabularemaschinenlesbar zu publizieren [MB08]. Somit werden diese althergebrachten Konzepte zum Einsatzim Semantic Web aufbereitet, ohne dabei die komplexere OWL-Syntax beachten zu mssen.

WGS84 (Geo Positioning) Zur Positionsangabe realer Objekte auf der Erde kann das VokabularWGS84 Geo Positioning benutzt werden. Dieses Vokabular gibt die Mglichkeit Koordinaten in einemstandardisierten Format auf Basis des World Geodetic Systems 1984 [wgs04] zu definieren, dass auchals Basis fr das Global Positioning System (GPS) dient.

4.3 Existierende Semantic Web Datasets

Eine Mglichkeit externe Datenbestnde zu nutzen, bieten Datasets (groe zusammenhngende Da-tenmengen). Diese knnen einerseits unter Nutzung von Web-Services mit gegebenen Parameternabgefragt werden, um so die erwnschte Einschrnkung auf die Datenmenge zu erzielen und diese

Name Themenbereich BeschreibungDBLP bibliographische

Informationen berwissenschaftlichePublikationen

Abfrage von bibliographischen Daten ber einenSPARQL-Endpoint oder Linked Data, URL: http://www4.wiwiss.fu-berlin.de/dblp/

oder http://dblp.l3s.de/d2r/

DBpedia uneingeschrnkt teilweise Extraktion von Daten aus der WikipediaEnzyklopdie,automatische Semantifizierung undSpeicherung in einem RDF-Triple-Store, um dieseber einen ffentlichen SPARQL-Endpoint oder Lin-ked Data abzufragen. URL:http://dbpedia.org

GeoNames geographischeDaten

Abfrage von Informationen ber geographische Ele-mente mittels Linked Data, URL: http://www.geonames.org

Tabelle 3: Auszug existierender DataSets mit dem Angebot von Semantic Web Technologien

http://www4.wiwiss.fu-berlin.de/dblp/http://www4.wiwiss.fu-berlin.de/dblp/http://dblp.l3s.de/d2r/http://dbpedia.orghttp://dbpedia.orghttp://www.geonames.orghttp://www.geonames.org


in einem bentigten Format zu erhalten. Andererseits besteht die Mglichkeit, Daten mittels LinkedData abzurufen (vgl. Abschnitt 5.6), wie dies bei den in Tabelle 3 aufgefhrten Anbietern groersemantisch annotierter Datenbestnde der Fall ist. Eine weitere Liste von Datasets wird in [Dat08]aufgefhrt.

4.4 Semantic Web Bibliotheken

Zur Erstellung von Web Applikationen knnen Frameworks und Bibliotheken zum Einsatz kom-men. Dies dient einerseits der vereinfachten Handhabung und andererseits der Unabhngigkeit durchAbstraktion von zugrunde liegenden benutzten Kernkomponenten der verwendeten Architektur derjeweiligen Web Applikation. Zur Nutzung von semantischen Technologien stehen ebenfalls eine Viel-

Name Typ Sprache BeschreibungARC SPARQL-

ServerPHP leichtgewichtiger SPARQL-Server, der direkt auf

einer MYSQL Datenbank arbeitet

Jena Framework Java Framework/Bibliothek zum erzeugen von Se-mantic Web Applikationen, enthlt Umgebungfr RDF(S), OWL, SPARQL, GRDDL und eineregelbasierte Inference Engine. Ist auch benutz-bar als RDF Datenbank ber den Joseki Layer

OpenLinkVirtuoso

universellerServer

C++ Web Applikations Server und ORDBMS, derSQL, XML und RDF Management untersttzt,sowie Support fr SPARQL, ODBC, GRDDL,JDBC, ADO.NET, WebDav etc. leistet.

RDF-Api forPHP (RAP)

RDF-Triple-Store

PHP Open-Source Klassenbibliothek zur Manipulati-on von RDF-Modellen und parsen/serialisierenvon RDF

Redlandlibrdf

Framework C und An-bindung anPHP, TCL,Perl, Ruby,Java ...

Sammlung von Bibliotheken zur Untersttzungder Arbeit mit RDF. Untersttzt auch Turtle,N3, Atom, RSS und enthlt eine SPARQL undGRDDL Implementierung

Sesame Framework Java und Py-thon Wrap-per

Open-Source RDF-Datenbank mit Bibliothek zurArbeit mit RDF-Daten

Tabelle 4: Semantic Web Bibliotheken


zahl an Bibliotheken, Servern, und Frameworks zur Verfgung, die im ESW-Wiki39 zu groen Teilenaufgelistet sind. In Tabelle 4 sind die wichtigsten Implementierungen aufgefhrt, welche die Arbeitmit RDF vereinfachen. Weiterhin stehen zur Darstellung von Informationen im Web-Browser ei-ne Menge an Bibliotheken zur Verfgung, die der Benutzergruppe der jeweiligen Web-Applikationeine hhere Performanz und Bedienbarkeit durch Technologien wie Asynchronous JavaScript andXML (AJAX) [Gar05] ermglichen. Zudem knnen diese Bibliotheken zur Minimierung des Ent-wicklungsaufwandes beitragen. In Tabelle 5 sind Implementierungen aufgefhrt, die zur Erstellungenvon Oberflchen in semantischen Web-Applikationen benutzt werden knnen. Besonders hervorzu-heben ist die API rdfapi-js [DHP08] (nicht in der ESW-Wiki-Liste aufgefhrt), die in der Oberflcheim Ontowiki-Projekt zur Verwaltung von RDF-Daten zum Einsatz kommt. Durch Nutzerinteraktionherbeigefhrte Vernderungen in der clientseitigen RDF-Reprsentation werden mit dem serverseitgserialisierten RDF-Model mittels asynchroner Datenbertragung mit Hilfe dieser API synchronisertund die (X)HTML-RDF-Reprsentation in der Oberflche aktualisiert. Dadurch werden keine zustz-lichen Anfragen an die Web Applikation zur Generierung einer Ausgabe bentigt.

Name Typ Sprache BeschreibungAjax Client forSparql

GUI-Bibliothek JavaScript leichtgewichtiger AJAX-Client frSPARQL-SELECT-Anfragen, die anSPARQL-Endpoints gestellt werdenknnen

Dojo Data GUI-Bibliothekund RDF-Store

JavaScript Modul zur Behandlung von RDF-Daten

rdfapi-js GUI-Bibliothek JavaScript Erzeugung von JavaScript Objektenunter Nutzung eines RDF/a Parsers umclient-seitig RDF Daten zu verwalten

RDFParser GUI-Bibliothek JavaScript verarbeitet direkt RDF/XML und istbenutzbar mit Web-Browsern, dieDOM-Level 2 fhig sind

Tabelle 5: Semantic Web GUI Bibliotheken

39http://esw.w3.org/topic/SemanticWebTools

http://esw.w3.org/topic/SemanticWebTools

5 CHARAKTERISIERUNG SEMANTISCHER WEB-APPLIKATION 29

5 Charakterisierung semantischer Web-Applikation

Im Grundlagenkapitel Abschnitt 2.1 wurde der Begriff des Semantic Web eingefhrt. Um den Begriffder semantischen Web-Applikation zu beschreiben, werden folgend einerseits semantische Technolo-gien und andererseits bestehende Web-Applikationen begutachtet, die diese Technologien benutzen.Zuvor wird im Abschnitt 5.1 eine erste Charakterisierung von Web-Applikationen zum Umgang mitsemantischen Daten vorgenommen.

5.1 Web-Applikationen im Semantic Web

Wie Alex Iskold, der Grnder von Adaptive Blue40, auf dem Weblog ReadWriteWeb41 in mehrerenArtikeln42 beschreibt, existieren unterschiedliche Szenarien, in denen Web-Applikationen mit seman-tisch annotierten Daten umgehen.

Im klassischen Szenario wird die Bottom-Up Methode benutzt, welche die Erzeugung von semanti-schen Daten beschreibt. Hierbei besteht die Mglichkeit, solche Daten einerseits manuell durch dieCommunity generieren zu lassen und andererseits dies mit Automatismen zu bewerkstelligen. Mittelsbeider Techniken knnen daraus resultierende semantische Datenbestnde im WWW beispielsweiseim RDF-Format oder innerhalb von HTML mit Microformats reprsentiert werden. Somit werdendiese Daten publiziert und knnen wiederverwendet werden.

Wiederverwendbare Daten ermglichen das zweite Szenario, welches mit dem Top-Down Ansatz be-zeichnet wird. In diesem Ansatz wird die Wiederverwendung von Daten beschrieben. Damit werdeneinerseits Web-Applikationen ermglicht, die selbst ber keine semantischen Datenbestnde verf-gen, sondern diese von externen Quellen beziehen und in irgendeiner Art und Weise benutzen. An-dererseits knnen Web-Applikationen sich in deren eigenen Wissensbasen auf externe semantischeDatenbestnde beziehen und beispielsweise weitere Aussagen ber entfernt vorhanden Informatio-nen im Web zur Verfgung stellen.

Somit lsst sich eine erste Charakterisierung verschiedener Arten semantischer Web-Applikationenaufstellen:

1. Bottom-Up Ansatz: Web-Applikationen, die semantische Daten generieren.

2. Top-Down Ansatz: Web-Applikationen, die semantische Daten externer Wissensbasen wie-derverwenden.

40http://www.adaptiveblue.com/41http://www.readwriteweb.com42http://www.readwriteweb.com/archives/semantic_web_difficulties_with_classic_

approach.php und http://www.readwriteweb.com/archives/the_top-down_semantic_web.php

http://www.adaptiveblue.com/http://www.readwriteweb.comhttp://www.readwriteweb.com/archives/semantic_web_difficulties_with_classic_approach.phphttp://www.readwriteweb.com/archives/semantic_web_difficulties_with_classic_approach.phphttp://www.readwriteweb.com/archives/the_top-down_semantic_web.php


3. Kombinierter Ansatz: Web-Applikationen, die semantische Daten generieren und Informatio-nen externer Wissensbasen wiederverwenden.

5.2 Technologien des Semantic Web auf Modellebene

Als RDF(S) und OWL vom W3C unter anderem als Formate zur Speicherung und Verarbeitung vonWissensbasen empfohlen wurde (siehe Abschnitt 2.4), war die Entwicklung von Komponenten, diediese Formate verarbeiten knnen, schon in vollem Gange. In herkmmlichen Web-Applikation wer-den zumeist relationale oder objekt-relationale Datenbank-Management-Systeme verwendet. Mittelsdieser Datenbank-Management-Systeme werden Datenbanken verwaltet, in denen Entitten einemfesten Datenbank-Schema entsprechend gespeichert sind. Aufgrund dieser festen Schemata ist eseiner Web-Applikation mglich, Daten in der Datenbank zu speichern beziehungsweise Daten ausdieser abzurufen. Web-Applikationen, die semantische Technologien auf Basis von RDF zur Verwal-tung von Datenstzen benutzen, speichern deren Daten ebenfalls mittels einem definierten Schema.Dieses muss im Gegensatz zu herkmmlichen Web-Applikationen bei sich ndernden Anforderungenan die Datenhaltung allerdings nicht modifiziert werden. Im Folgenden werden die Mglichkeiten derDatenhaltung sowie der Verwaltung von Daten in semantischen Web-Applikationen beschrieben.

5.2.1 Modellierung des Schemas

Vor Entwicklungsbeginn der Modelkomponente einer Web-Applikation muss das Schema modelliertwerden, in dem spter die Daten gespeichert werden sollen. Bei herkmmlichen Web-Applikationmuss entschieden werden, welches Repository zum Einsatz kommen soll. Einerseits ist es mglichdie Daten in Datenbanken abzulegen, die mittels der Datenbanksprache SQL zur Definition (DDL:Data Definition Language), Abfrage und Manipulation(DML: Data Manipulation Language) vonDaten operieren. Andererseits besteht unter anderem auch die Mglichkeit Daten in XML-basiertenRepositories abzulegen, welche mit XPath [CD99] und XQuery [BCF+07] interagieren. Die der mo-dellseitigen Datenverarbeitung zugrunde liegenden Technologien sind vom verwendeten Reposito-ry abhngig, allerdings wird bei jedem Repository ein Schema zur Datenstrukturierung festgelegt.Hierzu werden zumeist Objekttypen, Relationen, Operationen und so weiter identifiziert, die dannmit Tabellen oder Knotentypen, Attributen, Datentypen, Beziehungen und Regeln umgesetzt werden.Das bedeutet, dass nur Datenstze gespeichert werden knnen, die genau der definierten Strukturentsprechen. Kommen Datenstze hinzu die nicht dieser expliziten Struktur entsprechen, mssen n-derungen am Schema vorgenommen werden, dass unter anderem Konsistenzprfungen bestehenderDatenstze sowie nderungen der applikationsseitigen Modell-Komponenten zur Folge hat.

Bei der Modellierung eines Schemas fr semantische Web-Applikationen sind einige Vorteile direkt


ersichtlich. Hierbei werden Ontologien mit RDF(S) und OWL Vokabularen modelliert. In RDF(S)und OWL modellierte Ontologien werden alle Definitionen von Elementen als Ressourcen betrachtet,ber die Aussagen gemacht werden. Diese Aussagen lassen sich in Tripel-Form ausdrcken. Somitbesteht das Tripel-Form-Schema, minimal aus den drei Typen Subjekt Prdikat und Objekt.Repositories, die Daten in Tripel-Form speichern, werden als RDF-Triple-Store bezeichnet. Wirdbeispielsweise eine so modellierte Ontologie in einer Datenbanktabelle gespeichert, so htte diesemindestens diese drei Typen als Spalten. Das eigentliche Schema der Ontologie, also Klassen, Ei-genschaften, Relationen und so weiter wrde dann zusammen mit den Instanzen, also den konkretenWertbelegungen der im Schema definierten Typen, gespeichert werden. Dies hat den Vorteil, dass n-derungen am Schema der Ontologie keine nderungen am Schema des RDF-Triple-Stores erfordernund generische Komponenten zur Abfrage und Manipulation der Daten verwendet werden knnen.

5.2.2 Speicherung von Wissensbasen

In diesem Abschnitt werden Anstze zur Speicherung von RDF-basierten Wissensbasen vorgestellt.Einerseits kann eine Wissensbasis in einem RDF-Dokument in gewnschter Notationsform wie N3,Turtle und RDF/XML gespeichert werden. Aufgrund dessen, dass RDF auf XML aufbaut, wie in Ab-bildung 1 zu sehen, ist es mglich, Anfragen an eine so serialisierte Wissensbasis mit bestehendenTechnologien wie XPath und XQuery zu gestalten. Zudem existieren Implementierungen, die sichan diesen Technologien orientieren beziehungsweise diese erweitern, wie das bei XUL 43, Versa 44

und RxPath 45 der Fall ist. Andererseits knnen die in der RDF-basierten Wissensbasis enthaltenenRessourcen als Tripel extrahiert werden, um diese in einem RDF-Triple-Store zu speichern. Die mini-mal im Speicher-Schema eines RDF-Triple-Stores enthaltenen Definitionen wurden schon erwhnt,werden folgend aber genauer ausgefhrt. Aufgrund der Tatsache, dass die Speicherung von RDF-Triple-Stores meistens auf relationalen Datenbanken aufsetzen, wird sich hier auf die Darstellung desmglichen Datenbankschemas beschrnkt.

Der einfachste Ansatz des Aufbaus eines RDF-Triple-Stores ist monolitisch, wie in Abbildung 11 46

zu sehen ist. Die Tripel werden in den Spalten subject, predicate und object getrennt gespeichert. DieisLiteral-Spalte dient der Identifikation des Typs des Objektes. Dieser muss zwischen Literal und URIunterschieden werden.

Alle Bestandteile eines jeden Tripels werden in einer Tabelle gespeichert, was den Import und Ex-port groer Dokumente sowie Anfragen mittels SQL einfach gestalten lsst. Dieser Ansatz lsst sich

43http:\www.mozilla.org/projects/xul/ von 200144http://www.xml.com/pub/a/2005/07/20/versa.html45http://www.idealliance.org/papers/extreme/proceedings/html/2006/Souzis01/

EML2006Souzis01.html46http://infolab.stanford.edu/~melnik/rdf/db.html vom 3.12.2001

http:\www.mozilla.org/projects/xul/http://www.xml.com/pub/a/2005/07/20/versa.htmlhttp://www.idealliance.org/papers/extreme/proceedings/html/2006/Souzis01/EML2006Souzis01.htmlhttp://www.idealliance.org/papers/extreme/proceedings/html/2006/Souzis01/EML2006Souzis01.htmlhttp://infolab.stanford.edu/~melnik/rdf/db.html


Abbildung 11: Nicht-normalisierter Ansatz eines datenbankbasierten RDF-Triple-Stores

allerdings noch normalisieren, was unter dem Aspekt sinnvoll ist, dass in den Spalten subject, pre-dicate und object meistens URIs gespeichert werden. In RDF-Graphen ist die Kantenmenge sehr oftgrer als die darin reprsentierte Knotenmenge. Sind in einer Ontologie beispielsweise 1000 Instan-zen ein und der selben Klasse enthalten, wird die URI der Klasse 1000 mal in der object-Spalte unddie rdf:type-Property wre eben so oft in der predicate-Spalte gespeichert. Um dies aufzulsen, kannzustzlich zur Tabelle statements noch die Tabelle ressources hinzugefgt werden, in der alle Res-sourcen und Werte von Literalen gespeichert werden. Die Felder der statements-Tabelle wrden dannnur noch die eindeutigen Identifier der URIs als Werte enthalten sein. Bei der Suche nach bestimm-ten Aussagen im RDF-Triple-Store mssten allerdings immer noch sehr groe Mengen an Eintrgendurchsucht werden. Hierzu lassen sich weitere Tabellen hinzufgen, um die Menge der Eintrge derTabelle resources zu verteilen. Eine Mglichkeit ist die gesonderte Speicherung von Literalen undEigenschaften. Aufgrund der Beschaffenheit von Ressourcen-URIs, dass diese den Namensraum ent-halten in dem die jeweilige Ressource definiert ist, wre ebenfalls eine Auslagerung des Namens-raumes in eine separate namespaces-Tabelle sinnvoll. Das daraus resultierende Datenbank-Schemawrde in etwa dem in Abbildung 12 entsprechen.

Um weiterhin Aussagen ber Modelle, aus denen Ressourcen genutzt werden, definieren zu knnen,lsst sich noch eine models-Tabelle hinzufgen. In dieser werden alle erzeugten, importierten undreferenzierten Modelle gelistet. Zustzlich wird in der statements-Tabelle eine model-Spalte hinzuge-fgt, in welcher fr jedes Statement die Referenz auf das entsprechende Modell gespeichert wird. AlsBeispiel fr einen solchen Aufbau sind die RDF-Triple-Store, die von RDF Gateway 47 und RDF Apifor PHP48 (RAP) [OBW06] benutzt werden.

Ein weiteres Konzept zur Speicherung von Tripeln in Datenbanken wird von Jena Semantic Web Fra-mework49 (Jena) [WSKR03] benutzt und ist eigenschaftsorientiert. Dieses Konzept nutzt die Eigen-schaft von Wissensbasen, dass wenige Eigenschaften oft wiederverwendet werden. Fr jede verwen-dete Eigenschaft wird eine separate Tabelle mit den Attributen subject, object und isLiteral angelegt.

47http://www.intellidimension.com/48http://sourceforge.net/projects/rdfapi-php/49http://jena.sourceforge.net/

http://www.intellidimension.com/http://sourceforge.net/projects/rdfapi-php/http://jena.sourceforge.net/


Abbildung 12: Normalisiertes Datenbank-Schema des RDF-Triple-Stores

Die ersten beiden Attribute verweisen auf Eintrge in einer resources-Tabelle und die letzte Spaltedient, wie auch im vorherigen Ansatz, der Unterscheidung des Objekt-Wertes zwischen Literal undURI. Zustzlich muss eine Tabelle eingefhrt werden, die alle Namen von Eigenschaftstabellen denentsprechenden URIs der Eigenschaften zuordnet. Das ist notwendig, weil Tabellennamen nicht ausSonderzeichen bestehen drfen, wie diese in URIs zulssig sind. Der Vorteil eines so aufgebautenRDF-Tripel-Store ist ersichtlich. Beim Suchen nach Ressourcen mittels Anfragen, bei denen das Pr-dikat gegeben ist, muss nur die dem Prdikat entsprechende Tabelle durchsucht werden. Anfragen beidenen das Prdikat nicht gegeben ist, entsteht allerdings ein Nachteil, da alle Eigenschaftstabellen zudurchsuchen sind [Gro03].

Zur Speicherung von Wissensbasen in datenbankgesttzten RDF-Triple-Stores gibt es weitere An-stze, die hier in ihrer Vollstndigkeit allerdings nicht aufgefhrt werden. Zuletzt sei aber noch einobjektrelationaler Ansatz erwhnt, bei welchem sich unter anderem die Eigenschaft objektrelationalerDatenbankmanagementsysteme (ORDBMS) zu Nutze gemacht wird Tabellenhierarchien zu erzeugen[ACK+01]. Diese Eigenschaft ermglicht es, Konzepthierarchien, die in RDF(S) und OWL erzeugtwerden knnen, direkt auf Tabellen abzubilden.

5.2.3 Serialisierung und Deserialisierung von Daten

Im letzten Abschnitt 5.2.2 wurde der Begriff RDF-Triple-Store vorgestellt und mgliche Umsetzun-gen skizziert. Um Daten, die in Tripel-Form in diesen Repositories gespeichert werden, zu seriali-sieren und zu deserialisieren, gibt es mehrere Verfahrensweisen und anwendbare Technologien. Ru-dimentr besteht die Mglichkeit, Daten mittels der fr Datenbanken gebruchlichen Sprache SQL


zu extrahieren, hinzuzufgen und zu manipulieren. Wie im letzten Abschnitt allerdings beschriebenwurde, gibt es mehrere Mglichkeiten wie ein RDF-Triple-Store aufgebaut sein knnte. Mglicher-weise ist ein solcher RDF-Triple-Store auch datenbankunabhngig implementiert und wrde SQLunter Umstnden gar nicht ermglichen. Wrde also eine Applikation Anfragen mittels SQL an einRDF-Repository stellen, mssten diese fest mit der Implementierung des RDF-Repositories ver-zahnt werden. Um diesen Umstand aufzulsen, existieren weitere Sprachen, die zudem noch an dieSpeicherung von Daten in Tripel-Form angepasst sind. Eine der bedeutensten Sprachen zur Abfragevon Tripeln ist SPARQL [CFT08]. Diese wurde am 15. Januar 2008 vom W3C zur Empfehlung (Re-commendation) erklrt und baut auf zuvor entwickelte Sprachen wie RQL [KAC+02], RDQL [Sea04]und SquishQL [MSR02] auf. Mittels dieser Sprachen knnen allerdings noch keine Datenmanipula-tionen vorgenommen werden, was zur Folge hat, dass RDF-Triple-Stores derzeit noch spezielle, anderen Aufbau angepasste Methoden dafr zur Verfgung stellen mssen. hnlich der mittlerweilestandardisierten Abfragesprache SPARQL wird derzeit eine Begleitsprache mit dem Namen SPAR-QL/Update (SPARUL) [SM08] entwickelt, die diesen Umstand auflsen soll.

Implementierung RDQL SPARQLARC Nein JaARQ (Jena) Ja JaJoseki Nein JaOpenLink Virtuoso Nein Ja + Sparql embedded in SQLRedland librdf Ja JaRDF Api for PHP (RAP) Ja JaopenRDF Sesame Ja JaQuelle: http://esw.w3.org/topic/SparqlImplementations

Tabelle 6: Support von Abfragesprachen in Bibliotheken und Servern (Auszug)

Die meisten bekannten Bibliotheken und Server, die als Abstraktionsschicht zwischen Applikationund RDF-Repository eingesetzt werden knnen, bieten die Mglichkeit mit genannten Sprachenumzugehen. In Tabelle 6 sind einige der wichtigsten Implementierungen gelistet, die Anfragen viaRDQL und/oder SPARQL ermglichen. Um mittels SPARQL auf einen datenbankgesttzten RDF-Triple-Store zugreifen zu knnen, werden SPARQL-Anfragen beziehungsweise RDQL-Anfragen inadquate SQL-Anfragen bersetzt, in welchen die Merkmale des jeweiligen RDF-Triple-Store be-dacht sind. In [Wei07] ist die Implementierung des SPARQL-Prozessors dokumentiert, wie er in derRAP-API [OBW06] eingesetzt wird. Der Umgang mit SPARQL wird anhand von beispielhaften An-fragen im Anwendungsfall vakantieland.nl im Abschnitt 6.2.2 nher erlutert.

In den bisher beschriebenen Mechanismen zur Extraktion von Daten werden alle Informationen als

http://esw.w3.org/topic/SparqlImplementations


Ressourcen in Tripel-Form betrachtet. Selbst wenn OWL-Dokumente in einem RDF-Triple-Store ab-gebildet werden, sind bei einer Anfrage mittels einer entsprechenden SPARQL-Anfrage grundlegendnur Ressourcen in der Ergebnismenge enthalten. Diese knnen dann applikationsseitig zu komplexenObjekten zusammengesetzt werden. Wenn also beispielsweise eine durch eine URI referenzierbareInstanz mit allen dazugehrigen Eigenschaften deserialisiert werden soll, muss zumeist eine sehr um-fangreiche Anfrage oder gar mehrere Anfragen in Folge gestellt werden. Unter Umstnden werdeninnerhalb der Applikation nicht nur die Eigenschaften und deren Wertbelegungen bentigt, sondernauch Schemainformationen wie beispielsweise der entsprechende Datentyp. Hierzu bietet sich bei-spielsweise die pOWL-API, die in spteren Entwicklungsschritten zur Erfurt-API erweitert wurde,als weitere Abstraktionsebene an (siehe Abbildung 7). Diese stellt, wie schon im Abschnitt 3.3.3 kurzskizziert, Anfragen an die zugrunde liegende RAP-API und erzeugt aus den entsprechenden Ressour-cen der jeweilig resultierenden Ergebnismenge komplexe Objekte, die alle bentigten Informationenzur Verfgung stellen. Die erzeugten Objekte sind unter anderem vom Typ Model (model), Klasse(class), Instanz (instance) und Eigenschaft (property). Auf diese Art und Weise identifizierbare Ob-jekte erleichtern den Umgang mit Informationen innerhalb einer Applikation und schaffen zudem dieMglichkeit auf feingranulare Modelkomponenten zu verzichten.

5.2.4 URI-Design

Idealerweise sind in Web-Applikationen, die mittels des HTTP-Protokoll mit den Clients interagie-ren, URLs den REST-Prinzipien [Fie00] entsprechend aufgebaut. Da das HTTP-Protokoll zustandslo-se Kommunikation spezifiziert, sollte auf Techniken verzichtet wer

Documents

Charakterisierung semantischer Web-Applikationen und ...lips.informatik.uni-leipzig.de/files/MasterThesis.pdf · denen semantische Technologien zum Einsatz kommen. Auf dieser Basis