Universität Hamburg
Fachbereich Informatik
Visualisierungs-Tools im Semantic Web II
Seminararbeit im Rahmen des Proseminars:
Proseminar Benutzungsintuition und Transparenz im Semantic Web
Eingereicht von:	Betreuer:
Birte Garreis, Matrikel Nr.: 5404510	Dr. Christina Vertan
Katja Cordes, Matrikel Nr.: 5425585
Stefan Schulz, Matrikel Nr.: 5459560

Hamburg, den 19. Januar 2004

Inhaltsverzeichnis
1.	Einleitung	1
2.	Visualisierungsschnittstellen für semantische Informationen zum Wieder finden und Durchsuchen von Daten und Dokumenten	1
2.1	Sensemaking Theorie und Information foraging Theorie	1
2.2	Visual Interfaces to Digital Libraries (DL)	2
2.3	Visualisierung von Informationsarbeitsplätzen	2
2.4	LVis Digital Library Visualizer	3
2.4.1	Data Visualization	3
2.4.2	Prototype Systems	4
2.4.3	LVis Interface to the Dido Database	4
3.	Visualisierung des Systems GridVis	5
3.1	Designmethoden	6
3.2	Das Visualisierungsdesign	6
3.3	Ein illustratives Szenario zur Benutzung von GridVis	8
3.4	Designverbesserungen von GridVis	8
4.	Web Services und Semantic Web	9
4.1	Standardisierte Web Services	9
4.2	Das SOAP-Protokoll	10
4.3	Die WSDL-Beschreibungssprache	11
4.4	Das UDDI-Verzeichnis	12
4.5	Einbindung des Semantic Web	13
5.	Recommender Systems für das Web	13
5.1	Probleme bei der Datensuche im Internet	13
5.2	Collaborative Filtering	14
5.2.1	Manuelle Collaborative Filtering Systeme	14
5.2.2	Automatische Collaborative Filtering Systeme	15
5.3	Collaborative Filtering und Semantic Web	16
6.	Interactive Interfaces für die Darstellung von E-Commerce Ontologies	16
6.1	XML basierte Kommunikation zwischen Unternehmen	16
6.2	Der Prozess der Erschaffung und des Lesens von XML Dokumenten und ihre natürliche Visualisierung	18
6.3	Technologien zur Visualisierung von XML Dokumenten	20
6.4	Ein generalisiertes Interface für die Visualisierung von XML Metadaten und ihrer Struktur	23
6.5	Web basierter Ontologie Übersetzer für E-Commerce Dokumente	24
6.6	Ausblicke	27
7.	Scalable Vector Graphics (SVG) und Geographical Information Systems (GIS) am Beispiel einer Rückenschmerzen Studie	27
7.1	Einführung	27
7.2	Die Ursachen und Untersuchungsmethoden von Rückenschmerzen	27
7.3	Technische Lösungen für die Rückenschmerzen-Daten	29
7.3.1	SVG (Scalable Vector Graphics)	30
7.3.2	ASP (Active Server Pages)	31
7.3.3	GIS (Geographical Information Systems)	31
7.3.4	Medical GIS	32
7.3.5	Web-based GIS	32
7.4	Systemvorrausetzungen und Entwicklung	33
7.4.1	ASP in Verbindung mit GIF „Körper-Landkarten“	33
7.4.2	ASP in Verbindung mit SVG „Körper-Landkarten“	34
7.4.3	GIS basierte Lösung	35
7.5	Prüfung und Vergleich der Lösungen	37
7.5.1	Vergleiche	38
7.6	Zusammenfassung	39
8.	Literaturverzeichnis	40

Abkürzungsverzeichnis
API	Application Programming Interface
ASP	Active Server Pages
CSS	Cascading Style Sheets
DHTML	Dynamic Hypertext Markup Language
DL	Digital Libraries
DOM	Document Object Model
FDP	force-directed placement
G-DOM-Tree	Generalized Document Object Model Tree
GIF	Graphics Interchange Format
GIS	Geographical Information Systems
GIS	Geographical Information Systems
HTML	Hypertext Markup Language
ICD9	International Classification of Deseases
IIS	Microsoft Information Interchange Server
ISI	Institute for Scientific Information
JPEG	Joint Photographic Experts Group
LSA	Latent semantic analysis
LVis	Library Visualizer
NHS	Norwick Park Hospital
PWS	Personal Web Server
SLIS	School of Library and Information Science
SOAP	Simple Object Access Protocol
SQL	Standard Query Language
SVD	singular value decomposition
SVG	Scalable Vector Graphics
UDDI	Universal Description, Discovery and Integration
UK	United Kingdom of Great Britain
UML	Unified Markup Language
USA	United Staates of America
W3C	World Wide Web Consortium
WSDL	Web Service Description Language
WWW	World Wide Web
XHTML	Exchange Hypertext Markup Language
XML	Exchange Markup Language
XSL	Extensible Stylesheet Language

1.	Einleitung 
Im Rahmen des Proseminars zum Thema „Semantic Web“ im WS 03/04 erstellen wir eine Ausarbeitung als Ergänzung zum Vortrag über die „Visualisierungstools im Semantic Web“. Die folgende Ausarbeitung basiert hauptsächlich auf dem zweiten Teil des Buchs von Geroimenko und Chen „Visualizing the semantic Web: XML-based internet and information visualization“. Die Gliederung dieser Ausarbeitung orientiert sich am oben genannten Buch. Die Gliederungspunkte 2 und 3 wurden von Katja Cordes, die Gliederungspunkte 4 und 5 wurden von Stefan Schulz und die Punkte 6 und 7 von Birte Garreis bearbeitet.
2.	Visualisierungsschnittstellen für semantische Informationen zum Wieder finden und Durchsuchen von Daten und Dokumenten
2.1	Sensemaking Theorie und Information foraging Theorie
Die Forschung zielt darauf ab, viele unterschiedliche Onlinedaten zu verarbeiten, zu analysieren und zu visualisieren, um den Benutzern des Webs eine bessere Orientierung zu geben und das vorhandene Wissen besser Nutzbar zu machen. Es wird davon ausgegangen, dass Benutzer unfähig sind, ihren spezifischen Informationsbedarf anzugeben. Außerdem ist bekannt, dass Informationsabfrage und -widerfindung ein sich wiederholender (iterativer) Prozess ist. Das bedeutet also, Informationsfindung und -archivierung sind nicht effizient.
Die meisten direkten Benutzerschnittstellen setzen einen Benutzer mit Überblick, Zoom- und Filterfunktionen voraus, als auch vom User ausgehende detaillierte Fragestellungen. Die Sensemaking Theorie und die Information foraging Theorie identifizieren vier hauptsächliche menschliche Aktivitäten bei sich wiederholender Informationssammelung eines Internetusers:
1. Suchen nach bestimmten Antworten mit Hilfe der Schlüsselwort- oder der relevanten Feedbacksuche
2. eine Informationsstelle ohne eine bestimmte Frage oder Darstellung im Kopf zu überfliegen oder erkunden
3. Benutzung von Überblicken, um Bereiche hoher Informationsdichte oder Relevanz zu durchschauen und um Navigationsaufgaben beim Browsen zu vereinfachen
4. Benutzung von Informationsarbeitsplätzen, um relevante Informationen zusammenzufassen und zu integrieren
Benutzer scheinen häufig zwischen diesen Aktivitäten zu wechseln. Idealerweise erleichtert und unterstützt Informationsvisualisierung alle vier Aktivitäten.
2.2	Visual Interfaces to Digital Libraries (DL)
Visuelle Schnittstellen zu digitalen Bibliotheken haben das Ziel, Suchaktivitäten zu unterstützen. Diverse Data-mining- und Visualisierungsalgorithmen können benutzt werden, um semantische Strukturen und/ oder Co-Zitatbeziehungen aus Dokumenten zu extrahieren und um Dokumente räumlich zu layouten. Dieses hilft den Benutzern sich Dokumente vorzustellen, sie schneller ausfindig zu machen und sich schneller an sie zu erinnern. Verschiedene Systeme liefern räumliche Hinweise durch die Präsentation der Dokumente in dreidimensionalen Räumen und ermöglichen es den Benutzern, durch diesen Raum zu gehen. Einige der ersten visuellen Schnittstellen zu DLs sind zweidimensionale Abbildungen auf Bildschirmen. Zu den ersten visuellen Schnittstellen gehören auch z.B. SemNet; ConTrees; ein räumliches Datenmanagementsystem von Herot und Bead, das statistische Techniken benutzt, um Dokumente basierend auf ihrer semantischen Ähnlichkeit zu analysieren und zu gruppieren und um Visualisierungen von Bibliographien zu erschaffen. Die Forschung von Chen hat zum Ziel, Leuten zu erlauben, intuitiv in einem semantisch organisierten Informationsraum zu navigieren und ihn zu erkunden. 
2.3	Visualisierung von Informationsarbeitsplätzen 

Abbildung 1, Data Mountain

Informationsarbeitsplätze haben visuelle Schnittstellen zu DLs. Die Visualisierung dieser Informationsarbeitsplätze ist sehr unterschiedlich. Balleys Arbeitsplatz erlaubt das 3D-räumliche Layout von Dokumenten. WebBook and Web Forager liefern einen Informationsarbeitsplatz für das WWW. Die Cat-a-cone Schnittstelle benutzt ein 3D+ animiertes WebBook, um eine moderate Anzahl von Dokumenten zu visualisieren. Data Mountain (siehe Abb. 1), welches ein alternatives Webbrowsersystem ist, bietet einen generischen 3D-
Raum an, wo Benutzer frei ihre Miniaturansichten der Webpages platzieren können, für die sie Referenzen erhalten möchten. Die TaskGallery (siehe Abb.2) erweitert die Benutzeroberfläche in einen 3D-Arbeitsraum, dieser präsentiert sich als eine lange 

Galerie mit Bildern, die verschiedene Aufgaben symbolisieren. Die David Gelernter`s Scopeware (siehe Abb.3) ordnet Dokumente chronologisch. 

Abbildung 3: Scopeware

Abbildung 2, Task Galerie

Diese Systeme differieren nur auf die Weise, wie 
die Dokumente bei ihnen geordnet werden (z.B. 
durch Benutzer in Stapeln, automatisch in einer 
Liste, Teilung und Hierarchie) und wie sie präsentiert 
werden (als Text, Icons, Bilder, Miniaturansichten 
etc.). Alle diese Systeme machen Gebrauch von räumlichem Erkennungsvermögen. Jedoch hatten visuelle Schnittstellen bisher nur beschränkten Erfolg. Ein 
Grund dafür ist, dass sie nicht die benutzerzentrierten Hinweise bereitstellen, die 
helfen, sich an Standorte zu erinnern.
2.4	LVis Digital Library Visualizer
Das LVis Digital Library Visualizer System wurde in Zusammenarbeit von Börner, Dillon und Dolinsky 1999/2000 entwickelt. Es benutzt LSA (Latent semantic analysis), um die semantische Ähnlichkeit von Dokumenten zu extrahieren. Es wendet Gruppierungstechniken und ein so genanntes utility measure an, um die Gruppierung zu selektieren, die am besten die semantische Struktur eines Dokumentensatzes zeigt. Das Ergebnis wird auf einem zweidimensionalen Benutzeroberflächenbildschirm oder in einer dreidimensionalen virtuellen realen Umgebung visualisiert. Zwei Prototypschnittstellen sind implementiert worden, die dafür bestimmt sind, das Browsen zu vereinfachen durch das Wieder finden von Zitat- und Bilddaten.
Latent semantic analysis (LSA), auch genannt latent semantic indexing (LSI), ist eine Methode der Vektorraumabfrage, die das so genannte Vokabularabweichungsproblem überwindet. Angesichts des Kontext von Wörtern überwindet LSA zwei grundlegende Probleme: Synonyme (Variabilität von Wortwahl, z.B. dad vs. Papa) und Polysemy (ein Wort mit mehreren Bedeutungen, z.B. Bank).
2.4.1	Data Visualization
Dokumente werden visuell auf eine Weise vorgelegt, die ihre semantischen Ähnlichkeiten zeigen. Anstatt eine statische Visualisierung von Daten zu sein, ist die Schnittstelle selbstorganisierend und hoch interaktiv. Daten werden in einer anfangs zufälligen Konfiguration angezeigt, welche sich selber in eine mehr oder weniger akzeptable Bildschirmanzeige durch einen force-directed placement algorithm (FDP) auflöst. Der Algorithmus funktioniert durch Berechnung von Anziehung- und Abstoßungsmacht durch Knoten. In unseren Anwendungen repräsentieren die Knoten Artikel oder Abbildungen, welche von anderen Knoten angezogen werden, zu denen sie eine Verbindung bzw. Ähnlichkeit haben und werden abgestoßen durch Knoten, zu welchen sie keinen Link haben. Anfangs werden die Knoten zufällig platziert und werden dann zu den entsprechenden attraction und repulsion forces bewegt, bis ein lokales Energieminimum erreicht ist. Wenn der Algorithmus kein akzeptables, visuelles Layout produziert oder wenn die Benutzer ein anderes Ergebnis möchten, können die Knoten ergriffen werden und bewegt werden. FDP-Algorithmen können keine größeren Datensätze behandeln. Deshalb wurden Semantic Treemaps entwickelt, um die Gruppierungsstruktur von Dokumenten zu visualisieren genauso wie die semantischen Beziehungen von Dokumenten in jedem Cluster.
2.4.2	Prototype Systems
Zwei Prototypsysteme sind unter Benutzung der Datenorganisation und der Visualisierungsmethode, die oben beschrieben sind, durchgeführt worden. Das erste System visualisiert Frageergebnisse von Zitatdaten von der Science Citation Index Expanded (SCI-EXPANDED) vom Institute for Scientific Information (ISI) publiziert. Dieser Index gibt Zugang zu den aktuellen bibliographischen Informationen und angeführten Literaturverzeichnissen in mehr als 5600 Zeitschriften. 
Das zweite System ermöglicht es, den Benutzern Suchergebnisse von der Dido Image Bank at the Department of History of Art an der Indiana University wieder zu finden. Dido speichert etwa 9.500 digitalisierte Bilder von der Fine Arts slide library collection von insgesamt über 320.000 Bildern.
Beide Systeme werden in Java durchgeführt und werden an der Indiana University`s School of Library and Information Science (SLIS) betrieben. Im Weiteren wird nur auf die Dido Datenbank eingegangen.
2.4.3	 LVis Interface to the Dido Database 
Die Dido Datenbank erlaubt angenehmen Zugang und Verwendung von Abbildungen für Lehr- und Forschungszwecke über eine Webschnittstelle. Jede Abbildung in Dido wird zusammen mit seiner Miniaturansicht und einer Textbeschreibung gespeichert. Bei einer Befragung von Dido wird eine Liste mit Textabbildungen zurückgegeben, basierend auf Zeichenübereinstimmung zwischen Suchzeichen und Bildbeschreibung. Miniaturansichten können angeklickt werden, um eine Abbildung zurückzuholen. LVis wurden verwendet, um eine visuelle Schnittstelle für die zurückgeholten Bilderdatensätze bereitzustellen. Im ersten Schritt werden SVD (singular value decomposition) wie auch die Gruppierungstechniken angewandt, um Dido Bilder in Gruppierungen von semantisch ähnlichen Bildern anzuordnen. Für Demonstrationszwecke wurde der Satz von 21 Abbildungen, die zum Schlüsselwort „Monet“ passen, zurückgeholt und in Abbildung 4 angezeigt. 
Das Cluster enthält 21 Bilder einschließlich zweier Portraits von Claude Monet gezeichnet von Edouard Manet. Miniaturansichten von Bildern, die von der Dido Datenbank gezogen worden sind, zeigen einige von Monets favorisierten Themen wie Heuhaufen, Kathedralen und Seerosen. Jedes Cluster ist mit dem Wort bezeichnet, das am häufigsten in den Titeln seiner Abbildungen auftritt. In diesem Beispiel ist es der Name des Künstlers. Außerdem ist eine 3D-CAVE-Schnittstelle implementiert worden. Eine Alternativ-3D-Bildschirmschnittstelle zu von Dido abgerufenen Bilderdaten ermöglicht mehreren Teilnehmern, Suchergebnisse kooperativ zu prüfen und zu erörtern.
Nachteil von LVis ist, dass es auf Textanalyse beschränkt ist- die textliche Repräsentation von Bildern wird ausschließlich benutzt, um semantische Ähnlichkeiten zu bestimmen. LVis 

Abbildung 4: Dido Visualisierung

hat aber auch Vorteile, es unterstützt menschliches Browsen basierend auf visuellen Merkmalen. Zu Browsen ermöglicht den Nutzern wieder zu erkennen anstatt eine genaue Frage im Voraus zu formulieren. Diese Kombination von Textsuche und visuellem Browsen, soll zurzeit die effektivste Methode beim Finden von interessanten Bildern sein. 
3.	Visualisierung des Systems GridVis
Große Unternehmen in der ganzen Welt sind daran interessiert ihr Wissen, das sich in ihren gespeicherten Dokumenten befindet, besser zu nutzen. Es ist viel Arbeit zu schauen, wie man automatisch relevante Daten dem richtigen Angestellten zuordnet und zur Verfügung stellt. Trotzdem soll es möglich sein, dass Angestellte schnell und effizient auf Daten und Dokumente zurückgreifen können bzw. wieder finden. Deshalb wurde ein interaktives System namens GridVis entwickelt.
3.1	Designmethoden
Die Designarbeit wird durch eine Reihe von Techniken unterstützt: 
•	Einbeziehung von potentiellen Benutzern
•	iteratives Musteranwendungsverfahren
•	formlose Nutzertests
•	experimentelle Auswertung
Der erste Entwurf einer Nutzeroberfläche wurde auf Papier gemacht, wobei generelle Designbenutzungsprinzipien als Richtlinie berücksichtigt worden sind. Jetzt konnten Angestellte ihre Wünsche und Kritik am ersten Modell äußern. Die Ideen wurden in interaktiven Modellen konkretisiert. Danach wurden mit diesen Modellen informelle Nutzertests gemacht.
3.2	Das Visualisierungsdesign
Die GridVis enthält eine Visualisierung von Dokumentenmetadaten. Die Visualisierung sind vier verbundene Teile: der Metadatatree auf der linken Seite, oben der Iconic Document Overview und im Zentrum das Grid und links das Document Window (siehe Abb.5). 

Abbildung 5: Benutzeroberfläche GridVis
Die entwickelte Taxonomie wir dazu benutzt, um die Baumstruktur zu erschaffen und die Metadaten-Tags werden zu diesem als Blattknoten hinzugefügt. Jeder Tag hat eine entsprechende Zeile im Grid. Das Iconic Dokument Overview ist eine Miniaturabbildung des Dokumentes. Das Grid zeigt, welche Metadaten-Tags zu welchem Teil des Dokumentes gehören: Jede Spalte zeigt einen Abschnitt des Dokumentes und jede Reihe einen Tag. Um zu zeigen, dass ein Tag zu einem Teil des Abschnitts gehört, ist die Zelle, wo sich Spalte und Zeile treffen, schattiert. Die Farbe der Zelle ist davon abhängig, wie viel Wert das Anwendbarkeitsattribut hat. Dieses wurde festgelegt, als den Tags die Abschnitte zugeordnet wurden. Je höher die Anwendbarkeit ist, desto dunkler ist die Farbe der Zelle. Der Benutzer kann diese Oberfläche mit der Maus benutzen. Wenn die Maus im Grid über einer Zelle ist, werden alle Tags in der Spalte hervorgehoben. Wenn der Benutzer entlang der Zeile eines interessanten Tags weiterschaut, dann kann er sehen wo und in welchem Umfang dieses Thema im Dokument vorkommt. Wenn auf eine Zelle geklickt wird, dann öffnet sich im Document Window der Textabschnitt.
3.3	Ein illustratives Szenario zur Benutzung von GridVis
Clair, eine Angestellte von Sainsbury´s, sitzt in ihrem Arbeitszimmer am Computer. Sie möchte sich das „industry update“, was wöchentlich erscheint, anschauen. Sie interessiert sich dafür, ob die Firma plant ihre US-Tochtergesellschaft zu verkaufen. Sie startet GridVis und schaut bei den Metadaten, ob dort die US Tochtergesellschaft von Sainsbury`s erwähnt ist. Sie scrollt solange bis sie in der Metadatentaxonomie „business unit“ findet. Dann schaut sie in diesem Level nach dem Tag „Sainsbury`s“. Als sie diesen gefunden hat, findet sie darunter eine Kategorie „Shaws“. Das ist eine Tochtergesellschaft von Sainsbury`s in den USA. Jetzt versucht Clair herauszufinden, ob irgendein Abschnitt dieses Dokumentes für ihre Frage relevant ist, d.h. also, steht dort irgendetwas über Verkauf. Sie schaut also das Grid in der Reihe dieses Tags durch und sieht, dass zwei Zellen farbig sind. Wenn sie mit der Maus über die erste Zelle geht, dann sieht sie farbige Zellen in derselben Spalte und deren Tags werden markiert. Die andere Zellentagerkennung ist „loyalty cards“. Sie entscheidet sich dafür, dass dieser Abschnitt nicht relevant dafür ist, und deshalb bewegt sie ihre Maus auf die nächste farbige Zelle. In diesem Fall leuchten die „acquisitions“ und „USA“ Tags auf. Das überrascht Clair, denn sie erwartete, dass Shaws zum Verkauf steht, und keine Übernahme vornimmt. Sie entscheidet sich in diesen Abschnitt zu schauen und klickt auf die Zelle. Im Document Window erscheint der neue Abschnitt.
3.4	 Designverbesserungen von GridVis
An dieser Stelle werden beispielhaft nachträgliche Designverbesserungen erläutert. Denn in Tests ist herausgekommen, dass Benutzer oft dieselben Abschnitte wiederbenutzen, und dass Benutzer oft runter und hoch scrolen. Deshalb wurde bei GridVis nicht nur der ausgewählte Abschnitt, sondern auch der vorangegangene mit eingeblendet. Als weitere spätere Verbesserung kam dazu, dass der Titel des relevanten Abschnitts über dem Iconic Document Overview eingeblendet wird, wenn die Maus über die Spalten im Grid geschoben wird. Testpersonen haben bemerkt, dass es schwer ist, die relevanten Zellen zu lokalisieren. Das Auge des Benutzers kann leicht abschweifen bei der Suche von relevanten Zellen. Dieses wurde folgendermaßen geändert: wenn die Maus im Grid herumschweift, dann werden die Grenzlinien der Reihen und Spalten unter der Maus dicker und grün unterlegt. Benutzer nutzen oft nicht die Informationen, die um den Tag herum sind, obwohl sie wichtig sind, um den Inhalt des Abschnitts besser zu verstehen. Dieses Problem wird dadurch gelöst, dass alle Tags eines Paragraphen hervorgehoben werden, wenn die Maus über die Spalte liegt. Das gibt dem Nutzer einen besseren Überblick und er sieht die anderen Tags ohne den Abschnitt zu lesen. 
4.	Web Services und Semantic Web
4.1	Standardisierte Web Services
Technologien des Semantic Webs wie RDF und DAML+OIL dienen dazu, das Zusammenspiel von Informationen verbessern. Das Ziel der Web Services in diesem Zusammenhang ist dagegen die Art des Informationsaustausches zu verbessern. Web Services liefern also die Grundlage auf die das Semantic Web aufbaut, während das Semantic Web die Qualität der darauf angebotenen Dienste verbessert. 
Als Web Services werden aber auch viele Dienste bezeichnet, die nichts mit dem Semantic Web zu tun haben, wie Suchdienste oder Übersetzungsdienste. Jedoch können diese Dienste nicht von Programmen gelesen werden. Das Problem sind u.a. die unterschiedlichen Standards und das die Dienste nicht selbstbeschreibend sind und der Computer sie deshalb nicht finden kann. 
Im Optimalfall sollte durch die Web Services der Informationsaustausch so möglich sein, dass z.B. die Abfrage einer Knowledge Base über Ontologien direkt aus dem zu verarbeitenden Programm möglich ist. Die Web Services können dabei die Grundlage liefern.
Hierzu werden aber einheitliche Standards benötigt. Diese liefert der Web Service Proocol Stack. Dies ist eine Sammlung von Protokollen, die zum definieren,
finden und implementieren von Web Services gedacht sind.
Bisher enthält dieser Stack vier Schichten:
-	XML Messaging Layer: Diese Schicht ist verantwortlich, die Nachrichten in ein allgemein verständliches XML Format umzuwandeln. Somit können sich die Rollen auf einer gemeinsamen Basis verständigen. Diese Schicht wird durch das SOAP Protokoll repräsentiert.
-	 Service Description Layer: Die Verantwortung dieser Schicht ist die Schnittstellen der Dienste einheitlich zu beschreiben (WSDL)
-	 Service Discovery Layer: Diese Schicht kümmert sich um die zentrale Führung einer Dienste Liste (Dienst-Entdeckungs-Schicht / UDDI)
-	Service transport layer: Diese Schicht kümmert sich um den Transport der Nachrichten die zwischen den Applikationen gesendet werden. Momentan sind folgende Protokolle Teil dieser Schicht: HTTP, SMTP, FTP, und neue Protokolle, so wie das Blocks Extensible Exchange Protocol (BEEP).
Unter Verwendung dieser Technologien könnte die Suchanfrage eines Programms dann so aussehen:
 1.) Das Programm fragt in einem UDDI Verzeichnis nach Diensten die Suchanfragen beantworten.

Abbildung 6, Suche nach einem Service

2.) Von diesen Diensten wählt es einen aus und holt sich davon eine WSDL-Beschreibung, wie der Dienst  zu verwenden ist. 
3.) Mit diesen Informationen nimmt das Programm nun per SOAP-Nachricht Kontakt zu dem Dienst auf und erhält das Ergebnis der Suche zurück. 
Im Folgenden werden die einzelnen Schichten mit ihren Funktionen und ihrem Aufbau genauer erklärt.
4.2	Das SOAP-Protokoll
Das Simple Object Access Protocol ist mittlerweile schon in Version 1.2 spezifiziert und wird wahrscheinlich mit nur geringen Änderungen zum vom W3C standardisierten XML Protocol Version 1.0 übernommen werden. 
Bei SOAP geht es generell um den Nachrichtenaustausch von XML-Dokumenten, meist zum entfernten Methoden- bzw. Prozeduraufruf auf anderen Rechnern. Für Typdeklarationen bietet es sich an, XML Schema zu nutzen. Der eigentliche Transport findet meist über HTTP statt. Das hat den Vorteil, dass der Verkehr nicht von Firewalls geblockt wird. 
Aber auch der Austausch über FTP, SMTP oder andere Protokolle wäre machbar. 
In der rechten Abbildung sieht man den generellen Aufbau einer SOAP-Nachricht. 
Header und Body dürfen nur XML Code enthalten. Im Body stehen die eigentlich zu übertragenden Nutzdaten. Der Header ist optional und kann somit auch entfallen. 

Abbildung 7, Aufbau einer SOAP-Nachricht

Bei der Verwendung von http als Transportprotokoll würde der ganze Envelope in eine entsprechende POST Nachricht gesetzt. 
Als Alternativen zu SOAP sind die schon länger etablierten Standards für Remote Procedure Calls wie CORBA (Common Object Request Broker Architecture), DCOM (Distributed Component Object Modell) auf Windows Systemen und RMI (Remote Method Invocation) in Java zu nennen. Aus einer früheren SOAP Version hat sich der XML-RPC abgespaltet. Diese haben aber den Nachteil keine wirklich plattform- und sprachübergreifende Kommunikation anzubieten. Entweder man ist auf Windows oder Java festgelegt, oder es fehlt einfach an Implementierung. 
SOAP ist für alle relevanten Programmiersprachen erhältlich und somit ist eine Plattform- und sprachübergreifende Kommunikation möglich.
4.3	Die WSDL-Beschreibungssprache
Die Web Service Description Language beschreibt, wie der Zugriff auf einen Web Service funktioniert. 
Durch das WSDL-Protokoll ist es möglich, dass sich der Client die Anweisung wie der Service aufgerufen werden soll über das WSDL-Dokument holt. Man muss ihm also nicht mehr explizit mitteilen, wie er den Service aufrufen soll. Das Schreiben von Clients wird also dadurch wesentlich erleichtert. So müssen auch für Änderungen am Server die Clients nicht mehr angepasst werden, sondern nur noch die entsprechende WSDL-Beschreibung. 
WSDL entspricht damit der Interface Definition Language (IDL) von CORBA und COM. 

Abbildung 8, Aufbau eines WSDL-Dokument

Eine WSDL-Beschreibung ist ein XML Dokument. Die verschiedenen Teile der Beschreibung bauen von oben nach unten aufeinander auf. Zuerst können neue Datentypen deklariert werden, die später beim Austausch Verwendung finden. Es werden Nachrichten deklariert, die aus oben definierten oder Standarddatentypen bestehen. In einem Interface werden die Nachrichten zu ihrer Verwendung wie Ein-/Ausgabe zusammengefasst. Das   Binding setzt die logischen Operationen zu physischen zusammen und definiert ein Kodierung für sie. Schließlich wird in Service eine oder auch mehrere Adressen, auf denen der Service verfügbar ist, definiert. 
Nachteil von WSDL ist, dass es nur eine technische Beschreibung des Dienstes liefert, nicht aber Informationen zur Bedeutung der Funktionen und Parameter. 
4.4	Das UDDI-Verzeichnis
UDDI ist die Abkürzung für  Universal Description, Discovery and Integration. 
Ein UDDI-Verzeichnis bietet eine Auflistung von Web Services und wo man mehr über sie erfährt. Man kann sich das Verzeichnis wie die Gelben Seiten vorstellen, nur anstelle der Telefonnummer findet man hier Verweise auf die WSDL-Beschreibung von Diensten. Außer einer Suche über den Namen der Firma, ist es natürlich auch möglich, nach einer bestimmten Dienstart zu suchen. 
Alle verwendeten Datenstrukturen werden als T-MODEL bezeichnet. Die Identifizierung findet über eindeutig vergebene Schlüssel statt. So hat jede Firma ihren eigenen Businesskey und jeder Service einen ServiceKey. Diese Nummer heißen Universally Unique Identifiers (UUID). 
Der Zugriff auf das UDDI-Verzeichnis kann selbst wieder per SOAP und über die WSDL-Beschreibung des Verzeichnisses erfolgen. Diese sollte jedem Programm gleich mitgegeben werden. 
Die UDDI-Organisation ist bereits in fast alle wichtigen Firmen vertreten. Eine Standarisierung durch das W3C ist geplant. 
Nachteil des Verfahrens ist seine geringe Sicherheit. So kann sich jeder als noch nicht vertretene Firma ausgeben und dort Einträge anlegen. 
Auch wird die Pflege der Datenbank mit der Zeit ein großes Problem werden, da der Nutzen eines Verzeichnisses mit längst verschwundenen Firmen eingeschränkt ist. So waren nach einer Studie im November 2001 schon 48% aller Links fehlerhaft. Hier spielt natürlich noch der experimentelle Status der Technologie mit. So sind zwar bis jetzt sehr viele Firmen vertreten, aber meist nur mit ihren Kontaktinformationen. Sie bieten meist jedoch noch keinerlei Web Services an. 
4.5	Einbindung des Semantic Web
Standardisierte Protokolle und Kommunikationsregeln sind für die Verbesserung des Informationsaustausches unerlässlich. Die Protokolle des Web Service Protocol Stack werden voraussichtlich in naher Zukunft durch das W3C als Standard anerkannt, allerdings ohne semantische Zusatzinformationen. Bestenfalls UDDI kann durch die hierarchische Gliederung als simple semantische Struktur angesehen werden. Ansatzpunkte für das Semantic Web findet man vor allem bei der Beschreibungssprache WSDL.  Der erwähnte Nachteil von WSDL ist, dass es nur eine technische Beschreibung des Dienstes liefert, aber nicht Informationen zur Bedeutung der Funktionen und Parameter. Hier gibt es die bereits erwähnte Beschreibungssprache DAML-S (DARPA Agent Markup Language – Services), welche auch solche Informationen unterstützt. Ihr fehlt es aber an der Firmenunterstützung, weswegen sie kaum verbreitet ist.
5.	Recommender Systems für das Web
5.1	Probleme bei der Datensuche im Internet
Die Datenmenge und die Web-Seiten im Internet nehmen stetig massiv zu. Schon längst hat die Menge an Informationen im Internet dazu geführt, dass eine effektive Nutzung und Suche nach Informationen unmöglich ist. Auch syntaktische Suchmaschinen, die das Web nach Keywords durchsuchen, liefern immer noch viel zu viele Treffer. Es ist also eine wichtige und interessante Aufgabe, Möglichkeiten zu finden, mit deren Hilfe mehr Struktur ins Web gebracht und Informationen leichter zugänglich gemacht werden können.
Durch semantische Annotationen wäre dies zu realisieren. Durch Metadaten und Ontologien wäre eine automatische bzw. computerunterstützte Suche möglich und die Effizienz erheblich verbessert. 
Eine andere Herangehensweise führt zu den Recommender Systems. Diese „Empfehlungs“-Systeme basieren in ihrer Idee auf einer großen Gemeinschaft von Usern. Jeder User einer Community beurteilt die Inhalte von Web-Seiten z.B. nach den Kriterien Qualität und Wichtigkeit. Anhand dieser Beurteilungen können Rankings und Empfehlungslisten erstellt werden, auf die andere User bei der Suche nach bestimmten Informationen zurückgreifen können. Meistens werden solche Systeme mit anderen Suchalgorithmen kombiniert, um den Suchbereich vorher einzugrenzen zu können.
Der Vorteil dieser Recommender Systeme ist ihre Unabhängigkeit von semantischen Annotationen. Man muss nicht auf die Weiterentwicklung der künstlichen Intelligenz und dem schwierigen Ausbau des Semantic Webs warten, sondern hat bereits jetzt eine unter bestimmten Umständen ziemlich effektive „Suchmaschine“. 
5.2	Collaborative Filtering
Eine Reihe von Systemen sind unter dem Namen „collaborative Filtering“ bekannt geworden. Sie vereinen Datenbanken und Suchsysteme mit Meinungen und Aktionen von Usern. Zusätzlich werden klassische Suchalgorithmen ergänzt, da gerade bei schnelllebigen Seiten, die häufig erneuert werden keine Usermeinungen vorhanden sind und collaborative filtering allein somit ineffektiv wäre. 
5.2.1	Manuelle Collaborative Filtering Systeme
Als eine der ersten entwickelte Tapestry das sogenannte „pull-active collaborative filtering“. Hierbei handelt es sich um ein System, bei dem zu Inhalten Metadaten gespeichert werden. Zusätzlich können User ihre Meinungen und Anmerkungen zu Inhalten hinterlegen. Sucht ein User nun zu einem bestimmten Thema Informationen, kann er sich die Empfehlungen der anderen User zu Nutze machen und sich die Informationen aus der Datenbank ziehen („pull-active“). 
Nachteil dieses Systems ist sicherlich, dass der suchende User die anderen User kennen muss, um deren Empfehlungen richtig einschätzen zu können. So sind die Meinungen jedes Users zu einem Inhalt sehr subjektiv geprägt und somit können sie auch stark divergieren. Kennt der suchende User die Schreiber der Empfehlungen nicht, kann er die Güte des Inhaltes trotz der Empfehlung nicht richtig einschätzen. 
Ein anderes System nennt sich „push-active collaborative filtering“ und wurde 1995 von Maltz und Ehrlich entwickelt. Die Grundidee bei diesem System ist es, das ein User ein gelesenes Dokument an andere interessierte User der Community weiterleitet. Die Firma Tacit (www.tacit.com) hat dieses System umgesetzt. Das Tacit Corporation’s KownledgeMail funktioniert wie folgt beschrieben. 
Von jedem User der Community (meistens einer Firma) wird ein persönliches Interessenprofil erstellt, wobei derUser selber entscheiden kann, welche Informationen davon öffentlich gemacht werden. Sender jetzt ein User eine e-Mail oder möchte er anderen Kollegen eine Web-Seite empfehlen, schlägt ihm das System aufgrund der Interessenprofile mögliche Empfänger vor. Die Empfänger einer e-Mail haben außerdem die Möglichkeit zu den Inhalten Expertenwissen einzuholen. Hierzu können sie das System nach möglichen Experten in dem gesuchten Gebiet befragen. 
Nachteil dieses System ist, dass der Sender einer Empfehlung trotz durch die vom System vorgeschlagene Empfängerliste nicht wissen kann, welchen User der Inhalt wirklich interessiert. Außerdem es kann schnell zu einer Überflutung mit e-Mail bei den Empfängern kommen, wenn zu viele Interessensgebiete angegeben wurden oder die Interessensgebiete nicht fein genug differenziert wurden.
5.2.2	Automatische Collaborative Filtering Systeme
Die collaborative filtering Systeme wurden weiterentwickelt. Automatisches Collaborative Filtering hat den großen Vorteil, dass der einzelne User selber nicht mehr aktiv tätig werden muss und von der Entscheidungslast der vorherigen Systeme befreit wird. Die Systeme arbeiten mit bestehenden Datenbanken und sammeln Einschätzungen und Meinungen vor Usern. Anhand dieser gespeicherten Daten werden die Zusammenhänge zwischen den Usern berechnet und User mit ähnlichen Profilen zusammengefasst. Die Einschätzungen dieser User werden dann zu Empfehlungen zusammengefasst. 

Weiterentwickelte Systeme analysieren und speichern die Surfgewohnheiten der User und zeigen ihm darauf hin bestimmte, zu seinem Profil passende Informationen an (implicit rating). Bei diesen Systemen nimmt der User die Empfehlungen und die dahinter stehenden Systeme oft gar nicht mehr wahr. Er sieht lediglich eine Web-Seite die im besten Fall genau seinen Bedürfnissen entspricht und merkt nicht, dass die Seite individuell für ihn „erstellt“ wurde. 
Diese Systeme sind öfters im Internet zu finden. So arbeitet amazon.de beispielsweise damit. Bei amazon.de werden dem User nach mehrmaligem Besuch der amazon.de Seite genau die Artikel angezeigt, die seinem Interessengebiet entsprechen. Ermittelt werden diese Interessengebiete anhand der angeklickten und gekauften Artikel vorheriger Besuche. 
Auch bei ebay finden Sie automatisches collaborative filtering. So wird beispielsweise angezeigt: „Käufer, die diesen Artikel gekauft haben, haben sich auch für folgende Artikel entschieden“ oder es werden dem User, falls er eine Auktion nicht gewonnen hat, ähnliche Artikel empfohlen.
Eine weitere Möglichkeit Empfehlungen zu erstellen ist z.B. bei Google zu finden. Um aus den Massen an Web-Seiten bei einer Suchanfrage diejenigen herauszufiltern, die als besonders gut einzustufen sind, nutzt Google eine „Linkanalyse“. Unter allen gemäß den eingegebenen Suchkriterien gefunden Web-Seiten die „besten“ zu finden, untersucht Google alle diese Seiten auf Verlinkungen untereinander. Die Seiten mit den Meisten Verlinkungen wird als besonders empfehlenswert ganz oben angezeigt. Den je mehr Links zu einem bestimmten Thema zu einer Seite gefunden werden, desto wahrscheinlicher ist es, dass diese Seite auch die gewünschten Informationen enthält. 
5.3	Collaborative Filtering und Semantic Web
Collabortive Filtering und Semantic Web können wie bereits erwähnt völlig unabhängig voneinander betrachtet werden. Es gibt jedoch auch gewisse Synergien zwischen beiden. Beide gemeinsam könnten noch wesentlich effizienter eingesetzt werden.
Semantic Web könnte beispielsweise das collaborative filtering unterstützen, indem man durch semantische Annotationen Web-Seiten besser kategorisieren und klassifizieren könnte. Dann könnten die Inhalte besser analysiert und die Effizienz der Empfehlungen gesteigert werden. 
Das collaborative filtering könnte in einem weit verbreiteten Semantic Web dazu dienen, Seiten gleichen (semantischen) Inhalts aufzuzeigen, damit der User sich die für ihn am Besten geeignetste Seite suchen kann.
Insgesamt kann sollte man aber nicht vergessen, dass die Recommender Systeme aufgrund des zur Zeit noch schwachen Semantic Web entwickelt wurden und sozusagen eine Notlösung darstellen, um bereits heute effizienter nach Informationen suchen zu können. Bei einem weiter verbreiteten Semantic Web wären diese Systeme nicht mehr nötig.    
6.	Interactive Interfaces für die Darstellung von E-Commerce Ontologies
6.1	XML basierte Kommunikation zwischen Unternehmen
XML (EXCHANGE MARKUP LANGUAGE) ist eine Metasprache, die von Unternehmen dazu verwendet wird, ihre web-domain in ihrer eigenen Sprache zu beschreiben. So kann die Sprache auf das Unternehmen und seine Eigenarten zugeschnitten werden. Dort liegt der Vorteil von XML nämlich in der Beschreibung der Domain durch speziell auf die Belange des Unternehmens abgestimmte tags (metadata labels). Diese werden auch als Vokabular (vocabulary) bezeichnet.
Das Problem liegt jetzt in der Kommunikation zwischen zwei Unternehmen, die jeweils ihre eigene XML basierte Sprache benutzen. Auf reiner Systemebene, d.h. ohne menschlich Beteiligung, ist dieses für Computer nicht möglich, da die beteiligen vocabularies zumindest teilweise, wenn nicht sogar völlig unterschiedlich sind. Es wird also eine Möglichkeit gesucht dieses Problem mit einer effektiven Technik zu lösen. Dies ist ein Ziel des Semantik Web.
Momentan benötigt man für die Problemlösung also die Kommunikation zwischen zwei Unternehmen, die mit ihrer eigenen XML basierten Sprache arbeiten, zwei Experten. Einen Wirtschaftsexperten, der erkennt das z.B. <our_price> auf der einen Seite dasselbe bedeutet wie <sale_price> auf der Seite des 2. Unternehmens. Der andere Experte muss ein Programmierer sein, der ein passendes XSLT (Extensible Stylesheet Language Transformation) Stylesheet schreibt, das Dokumente des Unternehmens 1 in solche des Zweiten übersetzt und umgekehrt. Diese Aufgabe kann teilweise automatisiert werden, wenn der Wirtschaftsexperte dazu in der Lage ist, zu erkennen, welche Metadaten dieselbe Bedeutung haben und zusätzlich die XML Daten zu manipulieren kann. Ein Spezielles Programm könnte dabei helfen, denn ein XSLT Stylesheet ist auch nur ein XML Dokument.
Der Domain Experte kann nicht und muss nicht mit der komplexen XSLT Sprache arbeiten. Er muss nur eine verständliche und logische Visualisierung der beiden Vokabulare haben, die ja nicht nur aus einer Liste von Wörtern, die als metadata label benutzt werden, bestehen, sondern durch Beziehungen miteinander verknüpft sind. Soll heißen es gibt eine bzw. zwei Ontologien.
Hier soll eine Möglichkeit gefunden werden, um Web User (besonders Domain Experten also Manager) dazu zu befähigen, durch interaktive Visualisierungsinterfaces die XML Metadaten und die zugrunde liegenden Ontologien zu verstehen und zu manipulieren. Um dieses zu erreichen, werden die natürlichen Visualisierungsmöglichkeiten wie Strukturdiagramme, Baumzeichnungen und UML Darstellungen analysiert und daraus eine neue effiziente Darstellungsmöglichkeit für XML Daten und ihre Ontologien entwickelt: das Generalized Document Object Model Tree (G-DOM-Tree) Interface. Aus der Analyse der existierenden Implementationstechniken des G-DOM-Tree Interfaces wurde ein Prototyp für einen XML Ontologie Übersetzer entwickelt und vorgestellt. Wie schon das Wort beschreibt, erstellt diese Applikation Ontologie Modelle in der G-DOM-Tree Form von zwei XML Dokumenten, die zwar dieselbe Domain beschreiben, aber in der Syntax differieren. Dadurch erlaubt sie es Web Usern, diese zu verstehen und somit eine XSLT basierte Kommunikation zwischen den zwei XML Dialekten herzustellen. Durch diese einfache Visualisierung(-slösung) von XML Ontologien wird es möglich eine Kommunikation zwischen Unternehmen zu etablieren.
6.2	Der Prozess der Erschaffung und des Lesens von XML Dokumenten und ihre natürliche Visualisierung
Bei der Erschaffung und dem Lesen von XML Dokumenten ist es notwendig die Struktur und den Inhalt zu visualisieren. Dies wird als natürliche Visualisierung bezeichnet. Diese Visualisierungen können in abgewandelter Form auch dabei behilflich sein XML Dokumente zu visualisieren.
Ein Beispiel soll helfen die wichtigsten natürlichen Visualisierungsmöglichkeiten zu analysieren und zu vergleichen. Als Beispiel wird die Erstellung eines einfachen Produktkataloges herangezogen. Die ersten Schritte sind die Auswahl von geeigneten Beschreibungsmöglichkeiten für die einzelnen Aspekte des Katalogs, die dann als Tag Namen (vocabulary) umgesetzt werden. Der zweite Schritt ist die Beziehungen zwischen diesen Vokabeln herzustellen bzw. eine Ontologie zu erstellen. Eine verbreitete Möglichkeit ist die Visualisierung mit UML (Unified Markup Language).

Abbildung 9, Beispiel UML Darstellung
Dies ist die am meisten am Menschen orientierte Darstellungsform. Sie zeigen das konzeptuelle Modell mit allen Objekten (Elementen), Properties (Attributen) und Beziehungen, in der Sicht des menschlichen Betrachters der Domain.
Die zweite Möglichkeit ist die Darstellung des Produktkatalogs in XML Schema in einer Diagramm Form.

Abbildung 10, Beispiel  XML Schema Darstellung
Prinzipiell sieht es aus wie das UML Modell und ebenso könnte das UML Modell automatisch in ein XML Schema Modell umgewandelt werden, bei komplexen Dokumenten wird dazu aber etwas menschliche Hilfe benötigt. Der Unterschied liegt in der Addition einiger technischer Details im XML Schema Modell, die für Computer notwendig sind, aber nicht für einen User, um die Struktur des Dokuments zu verstehen. Wenn ein XML Schema erstmal existiert, kann es für die Erschaffung unendlich vieler XML Dokumente als Schablone verwendet werden. Damit ist der Design-Prozess beendet. Nun folgt der Lese- bzw. Darstellungsprozess.
Der erste Schritt ist nun das Dokument mit einem XML Parser zu lesen, dieser kann eigenständig oder Teil eines Browsers sein. Dieser liest das Dokument und erstellt einen hierarchisch gegliederten Baum im Computer Speicher (XML DOM).
Der DOM des Beispiels erstellt durch einen Java basierten Parser sieht folgendermaßen aus:

Abbildung 11, Beispiel als DOM Modell
Ein DOM Modell enthält die maximal mögliche Anzahl an Knoten, die aus einem XML Dokument extrahiert werden kann. Also die maximale Anzahl an strukturellen Komponenten wie Elemente, Daten, etc.. Das sieht für den User normalerweise sehr unübersichtlich aus, da das DOM Modell alle Informationen nur in Knoten darstellt. Trotzdem ist es möglich dieses Modell als Navigationshilfe in einem graphischen User-Interface zu verwenden.
6.3	Technologien zur Visualisierung von XML Dokumenten
Ein XML Dokument hat keine immanente Darstellungsform so wie z.B. ein HTML (HYPERTEXT MARKUP LANGUAGE) Dokument durch seine Formatierungstags. Aus diesem Grund braucht ein XML Dokument spezielle externe Dateien oder sogar Applikationen für seine graphische Darstellung.
Die folgende Grafik zeigt wie das Katalog.xml Dokument aus dem Beispiel im Microsoft Internet Explorer 5 dargestellt wird.

Abbildung 12, Katalog.xml im Microsoft Internet Explorer 5
Es ist möglich XML Dokumente als HTML Files zu formatieren, um sie in einem Web Browsers mit allen damit verbundenen Möglichkeiten z.B. Links, Tabellen, Schriftarten, Farben etc. darzustellen. Dazu eignen sich wie bei HTML Cascading Style Sheets (CSS). Für komplexere Formatierung kann die Extensible Stylesheet Language (XSL) verwendet werden, die auch zur Transformation von XML Dokumenten (in HTML Dokumente) geeignet ist. Diese Darstellungsform von XML als HTML oder XHTML ist momentan der übliche Standard, aber diese Darstellungsform ist nicht in der Lage den Level von Interaktivität bereitzustellen, der benötigt wird, um effektive interaktive graphische Interfaces umzusetzen bzw. darzustellen. Diese benötigt aber der oben bereits erwähnte Ontologie-Übersetzer. Es fehlen die direkten Manipulationsmöglichkeiten (Features), die selbst mit Dynamic HTML (DHTML) nur sehr schwer implementierbar sind also keineswegs effizient einsetzbar sind. 
Möglichkeiten dieses zu verwirklichen bietet jede Programmiersprache, da XML Sprachen unabhängig einsetzbar ist. Obwohl dies theoretisch stimmt, zeigt die Praxis, dass nur einige wenige Sprachen auf breiter Basis nutzbar sind. Die beiden hauptsächlich benutzten Sprachen sind Java und ActionScript.
Es ist keine Überraschung, dass Java hier genannt wird, da es genau wie XML Plattform-unabhängig ist. D.h. eine Kombination aus XML Dokumenten mit Java Applikationen oder Java Applets erlaubt dem E-Commerce Nutzern bzw. Entwicklern eine universelle und transportable bzw. überall einsetzbare Lösung, was keine andere Programmiersprache in der Weise ermöglichen kann. Ein anderer Grund für die Java Kombination ist, dass Java aktuell die meistgenutzte Sprache ist und deshalb die Programmierer diese wählen.
Sun Microsystems Inc. bietet den Entwicklern folgende core Java Technologies für die Nutzung von Java mit XML: die JAVA API für XML Parsing (JAXP), Messaging (JAXM) und Data Binding (JAXB). Diese werden im nächsten Java Release enthalten sein und versorgen den Java Programmierer mit einem vielfältigen und einfach zu nutzenden Tool Set. 
Während Java die offensichtlichste Lösung für die XML Entwickler ist, ist ActionScript nur den wenigsten bekannt.

ActionScript ist eine komplette, sehr dem JavaScript ähnelnde Sprache, die es den Macromedia Flash 5 Entwicklern erlaubt, XML Dokumente zu lesen, zu verändern und zu generieren. Die Methoden eines ActionScript XML Objektes können benutzt werden, um XML Daten von einem Server herunterzuladen, um XML Knoten zu erfassen und manipulieren, um XML Dokumente auf einen Server hochzuladen und um sie graphisch in einem Flash Interface darzustellen. Außerdem gibt es ein vordefiniertes XML-Socket-Objekt, das eine Standleitung zu einem Server erlaubt.
Zusammengefasst offeriert ActionScript alle Möglichkeiten jeder anderen Programmiersprache. Was es einzigartig macht ist seine Verbindung zu Flash, als bekannteste Web-Technologie. Es erlaubt damit die Programmierung von verlässlichen, interaktiven, dynamischen und graphisch hervorragenden Webseiten sowohl für Unterhaltung als auch für E-Commerce.
Beide Sprachen ergänzen sich sehr wohl, denn Java ist die beste Wahl für ernsthafte und komplexe B2B Anwendungen und ActionScript ist besser geeignet für graphisch anspruchsvolle interaktive Webseiten, Portale und unabhängige E-Commerce Anwendungen (z.B. Online-Shops). Obwohl die Java Applets und Flash Movies demselben Zweck dienen, nämlich als Interface für XML Applikationen zu dienen, ist die Umsetzung mit Flash die einfachere und überzeugendere Lösung. Der Grund liegt einfach darin, dass die Auslegung von Flash eben gerade die Multimediale Anwendung, Animation und Interaktion ist bzw. war, dafür wurde es entwickelt.

Abbildung 13, Produktkatalog dargestellt durch Flash 5
Diese Abbildung zeigt die Darstellung des Beispielkatalogs in einer Flash 5 Applikation. Die Applikation kann das XML File lesen und auf grafisch hervorragende Weise interaktiv darstellen und sie ermöglicht es dem User durch den Katalog zu browsen. Entwickelt wurde sie mit Flash 5 und dem zugehörigen ActionScript. 
6.4	Ein generalisiertes Interface für die Visualisierung von XML Metadaten und ihrer Struktur
Es gibt viele Möglichkeiten ein grafisches Interface für XML Dokumente zu erstellen und dabei die natürliche Visualisierung zu nutzen. Hier wurde eines entwickelt bzw. wird eines vorgestellt, dass eine effektive visuelle Interaktionen mit XML Metadaten erlaubt. Zur Entwicklung wurden die oben genanten Visualisierungsmöglichkeiten herangezogen und noch weitere logische und experimentelle Untersuchungen der damit verbundenen Möglichkeiten. Das Ergebnis war das G-DOM-Tree Interface. Es basiert auf der XML DOM Darstellung, diese wurde generalisiert und verbessert, um sie an die (Effizienz-)Anforderungen des User-Gebrauchs anzupassen. Es übernimmt vom DOM nur die Metadatenstruktur. Durch die Implementation ähnelt es sehr der Darstellung von XML Schema und UML, aber es basiert zum größten Teil auf der Struktur des DOM Modells. 

Abbildung 14, Produktkatalog als G-DOM-Tree Modell
Es werden im G-DOM-Tree alle Metadaten (Elemente und Attribute) als Knoten dargestellt, die die Element/Attribut Namen und deren Stellung in der Dokumenten Struktur zeigen. Jedes Attribut hat den Status eines „Kind“-Elements seines „Eltern“-Elements. Das „a:“ vor einem Knoten-Namen ist der einzige Unterschied zwischen einem Attribut und einem Element. Um die Organisation des Modells besser darstellen zu können, wird jeder Strukturebene mit einer anderen Farbe dargestellt. Das Modell hat folgende Möglichkeiten:
o	Ontologien werden komplexer dargestellt als in XML oder UML
o	Sie sind einfach zu lesen und zu verstehen, wegen ihrer Einrückungen als Visualisierungshilfe und der Namen in den Tags
o	Alle Attribute werden als „Kinder“ Elemente dargestellt und mit dem Präfix „a:“ versehen
o	Technisch gesehen, kann diese Art der Darstellung ohne große Probleme in einen Flash Movie oder ein Java Applet umgewandelt werden
6.5	Web basierter Ontologie Übersetzer für E-Commerce Dokumente
Zur Implementation des Konzepts des G-DOM-Tree Modells wurde ein Arbeitsprototyp eines Ontologie-Übersetzers auf Flash Basis geschaffen. Diese Applikation liest XML Dokumente und erstellt sofort ihre generalisierten DOM Trees. In dieser Applikation kann jedes Interface Objekt direkt verändert werden durch einfaches drag and drop. Durch das Benutzen des drag and drop löst der User das im Hintergrund laufende bzw. zu Grunde liegende ActionScript aus, dass in der Lage ist die Knotenpunkte bzw. Elemente des XML Dokuments direkt umzubenennen, zu löschen oder neue zu erstellen sowie ein XSLT Stylesheet für alle Dokumente dieses Typs zu schreiben.
In folgender Grafik wird die Wirkungsweise des Ontologie Translators  visualisiert und daran auch erläutert:

Abbildung 15,  Katalog Beispiel im Ontologie Translator
Auch werden wieder die beiden verschiedenen XML Dialekte (Dokumente), die dieselbe Domain beschreiben, zu Grunde gelegt. Für menschliche Domain Experten sind die Synonym benutzen Namen der beiden Gruppen von Tags klar ersichtlich, aber nicht für Computer.
Der Vergleich fördert folgende Ähnlichkeiten und Unterschiede zu Tage:
o	Der Oberbegriff ist Katalog – einmal in britischem und einmal in amerikanischem Englisch.
o	Das Metadaten Tag „Produkt“ im ersten Dokument hat dieselbe Bedeutung wie „Item“ im Zweiten.
o	Eine synonyme Bedeutung haben folgende Tag-Paare: „Our_Price“ – „Price“, „Desc“ – „Info“, „Photo“ – „Image“.
o	Die Knotenpunkte „a: name“ – „Cat_id“ and „a: order_code“ – „Cat_no“  sind synonym, haben aber unterschiedliche Stellungen (ein Attribut versus ein Element in allen Paaren).
Wenn man sich nun vorstellt, dass man eine real-time Kommunikation zwischen dem Englischen und Amerikanischen XML basierten Sprachen herstellen möchte, um die beiden Kataloge zu verschmelzen, wird es offensichtlich, dass dies nicht ohne Experten(-wissen) möglich ist. Eine Möglichkeit wäre ein XSLT Stylesheet, wofür man aber sowohl Zeit als auch das technische Know-how benötigt.
Der Ontologie-Translator ermöglicht es jetzt jeder Person, die Domain Experte ist, aber keine XML oder XSLT Kenntnisse hat, durch einfaches drag and drop diese beiden XML Dokumente zusammenzufassen. Indem sie z.B. das „Catalogue“ Element auf das „Catalog“ Element ziehen wird dieses im Original Dokument überschreiben oder einfacher es wird eine XSLT Übersetzungsregel für die Übersetzung von einem Element in ein anderes festgelegt. Durch Löschen oder Hinzufügen des Präfixes „a:“ wird der Status eines Knotenpunktes bzw. Elementes von „Element – Attribut“ geändert und das nicht nur im Interface sondern auch im zu Grunde liegenden XML Dokument. 
Folgende Grafik zeigt den Mechanismus des Erstellens eines Gegenseitigen Verstehens durch Zusammenführen der Metadaten-Elemente der beiden Ontologien über direkte Manipulation im Interface.

Abbildung 16,  Funktionsweise Ontologie-Translator
Als Ergebnis entsteht ein XSLT Stylesheet, das die automatische Übersetzung von Britischen in Amerikanische Produktkataloge erlaubt.
Der Ontologie-Translator ist eine Prototyp-Anwendung, die visuelle Interaktionen mit den Ontologien von zwei XML basierten Domain spezifischen Sprachen  ermöglicht, um die Kommunikation zwischen diesen zu herzustellen. Diese Web- Anwendung implementiert bzw. greift zurück auf sowohl das G-DOM-Tree Interface als auch Flash XML Technologie. Sie erlaubt Domain Experten effektiv zu arbeiten, um real-life Probleme der Inkompatibilität von Web basierten XML Dokumenten zu lösen.
6.6	Ausblicke
Nach der Entwicklung des Translator Prototypen ist der nächste logische Schritt diese mit echten real-life E-Commerce Anwendungen zu testen und dadurch Aspekte zu finden, die zu erweitern, zu verbessern oder zu überdenken sind. Des Weiteren wird möglicherweise eine Java basierte Version des G-DOM-Tree Interfaces und folglich auch des Translators benötigt, um sie in Java basierte B2B Anwendungen bzw. Web-Auftritte zu integrieren.
7.	Scalable Vector Graphics (SVG) und Geographical Information Systems (GIS) am Beispiel einer Rückenschmerzen Studie
7.1	Einführung
Bei dieser Studie ging es um die datentechnische Visualisierung, Erfassung und dadurch bessere Auswertbarkeit von Patientendaten mit Rückenschmerzen in Großbritannien. Dies ist ein wichtiges Thema, da in Großbritannien 40 Prozent der Erwachsenen an Rückschmerzen leiden und dies kostete die Volkswirtschaft 1997/8 allein 9090 Millionen Pfund. Die Fehltage durch Rückenschmerzen der Erwerbsbevölkerung lag in der Zeit zwischen 90 und 100 Millionen Tage im Jahr. Es ist ein weltweites Problem. In den USA betrifft dies 19 Prozent der Erwerbsbevölkerung, wobei man bei dieser sehr viel niedrigeren Zahl beachten muss, dass in den USA nicht jeder krankenversichert ist. Aus diesen Gründen ist es wünschenswert jede Möglichkeit zur Verbesserung der Auswertung von Patientendaten und Krankheitsverläufen zu nutzen, um dadurch vielleicht mögliche Verbesserungen bei den Behandlungsmethoden der Patienten mit Rückenschmerzen zu erzielen, wodurch letztendlich der Krankenstand und somit die volkswirtschaftlichen Kosten verringert werden könnten. Dies sollte ermöglicht werden durch die verbesserte Verfügbarkeit der Patientendaten und daraus folgende verbesserte statische Analyse, d.h. es könnten Korrelationen und Zusammenhänge zwischen den Patientendaten besser erkannt werden, was der medizinischen Fachwelt erlauben würde Schlussfolgerungen zu ziehen.
7.2	Die Ursachen und Untersuchungsmethoden von Rückenschmerzen
Rückenschmerzen können zurückgeführt werden auf physische aber auch auf psychologische und emotionale Ursachen. Die Patienten mit chronischen Rückenschmerzen können sowohl unter diesen Schmerzen leiden auf Grund von körperlichen Ursachen oder weil die ständigen Schmerzen und die damit verbundenen seelischen Folgen zur psychologischen Ursache der Schmerzen geführt haben. Um die Ursachen zu untersuchen werden von den Patienten, bei denen ein Verdacht auf psychische oder emotionale Ursachen der Schmerzen besteht, Fragebogen ausgefüllt und dann mit Psychologen therapeutische Sitzungen als medizinische Behandlungsmethode durchgeführt.
Bevor diese Fragebogen ausgefüllt werden, werden die Patienten gebeten, auf so genannten Rückenschmerzen-Zeichnungen ihre Beschwerden einzuzeichnen und zwar den Ort und die Art der Schmerzen. 

Abbildung 17, Rückenschmerzen Zeichnung
Diese Zeichnungen sind dazu gedacht den Ort und die Art des Schmerzes aufzuzeichnen und werden auch dazu benutzt, um den Patienten dazu zu ermutigen über die Art und den Ort seiner Schmerzen nachzudenken – ein weitere Aspekt ist auch der beim Ausfüllen über die Ursachen nachzudenken. Diese Art der Untersuchung hat unter anderem die Vorteile ökonomisch und einfach zu handhaben (für Patienten und Personal) zu sein. Außerdem können sie noch benutzt werden, um Veränderungen der Schmerzen im Zeitverlauf darzustellen.
Da die oben schon erwähnten psychologischen Fragebogen teuer in Durchführung und Auswertung sind, werden die Zeichnungen einer konsequenten Analyse unterzogen, bei der geprüft wird, ob der Patient für eine Befragung mit den psychologischen Fragebogen in Frage kommt anders ausgedrückt, ob die eingezeichneten Schmerzen von organischer oder anorganischer Ursache sind. Diese Analyse geschieht nach verschiedenen Methoden, die auch von Hilfspersonal oder geschultem Hilfspersonal, je nach Komplexität des Verfahrens, ausgeführt werden können und trotzdem nahe an der Genauigkeit bzw. Richtigkeit der Ergebnisse der Ärzte liegen, aber zusätzlich natürlich Kosten einsparen. In mehreren Studien wurde nachgewiesen, dass diese Zeichnungen genauso verlässlich sind wie andere bekannte Methoden.
Zur Analyse der Zeichnungen wird der Körper in Dermatome, d.h. Hautabschnitte oder besser Körperregionen eingeteilt, an Hand derer die Zeichnungen ausgewertet und analysiert werden können. Die Dermatome sind jedem vom medizinischen Personal bekannt, da diese in den Grundlagen jeder Ausbildung thematisiert werden. Es sind einfach die jeweiligen Körperregionen des menschlichen Körpers (siehe Abb.10).

Abbildung 18, Einteilung des Körpers in Dermatome
Das zu lösende Problem, dass sich hier auftut, ist diese Zeichnungen, die dem Personal eben nur in Papierformat vorliegen, welches natürlich keine weitere (statistische) Analyse im weiteren Verlauf erlaubt, in ein Format zu bringen, dass eben diese Analyse zulässt. Software wie Excel und andere statistische Software-Pakete erlauben kein „Handling“ von Zeichnungen bzw. Daten, die in Diagrammform vorliegen. Hierfür eine Lösung zu finden war das Ziel der Studie.
7.3	Technische Lösungen für die Rückenschmerzen-Daten
Die Rückenschmerz-Zeichnungen, die die Patienten ausfüllen, können auf zwei mögliche Weisen aufbewahrt werden: zum einen als eingescanntes Bild im Ganzen oder in Abhängigkeit von Körperregionen. Im letzteren Fall wird das Bild erst in (Körper-) Regionen unterteilt und nur die Information aufbewahrt, die die vom Schmerz befallende Region des Körpers betrifft. Der Nachteil dieses Ansatzes ist, dass die Schmerzlokalisierung verallgemeinert wird z.B. Taubheit in der Hand würde verallgemeinert zu Taubheit im ganzen Arm, wenn das die kleinste Region ist, die die Hand enthält. Der Vorteil dieser Einteilung in Regionen ist natürlich, dass dies zu einfachen digitalisierten „Körper Landkarten“ führt, in der jede Region einzeln durch HTML mit einem bestimmten Dokument wie z.B. der Patientenakte eines Patienten verlinkt werden kann. Deshalb wird jede Körperregion zu einem „Körper-Landkarten-Hotspot“, der mit den sich auf die jeweilige Region beziehenden Patientenakten verlinkt ist. Der Vorteil solcher „Körper Landkarten“ ist, dass diese Art der Aufbewahrung einfache Querschnittsuntersuchungen ermöglicht, was bei einfach eingescannten Bildern nicht möglich ist. Demgegenüber steht der Vorteil, dass bei gänzlich eingescannten Zeichnungen das ganze Schmerzbild mit Ort und Art der Schmerzen erhalten bleibt. Wenn diese Bilder in einem angemessenen (Aufbewahrungs-)Format wie z.B. GIF (GRAPHICS INTERCHANGE FORMAT) oder JPEG (JOINT PHOTOGRAPHIC EXPERTS GROUP) vorliegen, können sie als zusätzliche Information mit dem Rest der Datenbank verlinkt werden.
In dem Lösungsansatz der Studie wird eine web-basierte „Körper Landkarte“ erstellt, wobei GIF Bilder (eingeteilt in Regionen mit Hilfe des Makromedia Fireworks package) verbunden mit HTML aber auch SVG (SCALABLE VECTOR GRAPHICS), welche es erlaubt vergrößerbare und drehbare Bilder zu erstellen, benutzt werden. Beide Arten von Bilder bzw. den hier erstellten Körperdarstellungen können in Verbindung mit ASP (ACTIVE SERVER PAGES) genutzt werden, um die Daten auf dem aktuellen Stand zu halten (dynamische Updates) und sie grafisch darzustellen. Zusätzlich wurde GIS (GEOGRAPHICAL INFORMATION SYSTEMS), ein spezielles Analyse-Tool für „Bilder-Landkarten“, eingesetzt.
7.3.1	SVG (Scalable Vector Graphics)
SVG ist ein neues Markup basiertes Vektorgrafik Format, welches das W3C (WORLD WIDE WEB CONSORTIUM) zu einem „open-web“ Standard gemacht hat. SVG ist eine XML gestylte Tag Sprache zur Beschreibung von zwei-dimensionalen Grafiken und grafischen Applikationen. Sie erlaubt es Textdateien als Vektor Grafiken zu speichern. Sie speichert nur Anfangs- und Endkoordinate und führt dadurch zu viel kleinerem Speicheraufwand als Rasterbasierte Speicherformate wie z.B. GIF und JPEG, die die Daten pixelweise erfassen. Dadurch führt zoomen bei ihnen auch zu „grobkörnigen“ Bildern und bei SVG eben nicht. SVG erlaubt es nicht nur Polygone zu erstellen und sie mit Farbe zu füllen, sondern es können ihnen auch Attribute zugeordnet werden. Deshalb können sie auch auf jede Größe gezoomt und beliebig gedreht werden. 
Abschließend vergrößert die Tatsache, dass SVG XML basiert ist und deshalb eine textbasierte Grafiksprache mit semantischen Markup, die Möglichkeiten von Suchmaschinen diese Dateien zu durchlaufen und dadurch brauchbare Informationen für den End-User zu extrahieren.
7.3.2	ASP (Active Server Pages)
ASP erlaubt es dynamische Inhalte auf einem Server im Web zu speichern, wobei dieser die Formate IIS (Microsoft Information Interchange Server) oder PWS (Personal Web Server) haben muss. Das Textdokument mit dem die Webseite erstellt wird muss Visual Basic oder Javascript benutzen und damit den Server zu bestimmten Funktionen auffordern. Kurz führt sie dazu, dass eine Interaktion zwischen Client und Server ermöglicht wird. Vor der Weiterleitung der Daten an dem Client wird ein update vorgenommen, um die aktuellste Version zur Verfügung zu stellen.
7.3.3	GIS (Geographical Information Systems)
Die GIS Tools wie ArvView bieten eine Möglichkeit Bilder räumlich darzustellen bzw. Sachverhalte räumlich zu visualisieren. GIS muss nicht ein System sein es kann aus verschiedenen Hardware und Softwarekomponenten bestehen, jedes davon erfüllt eine Aufgabe beim Speichern und Verbinden der digitalen Bilder bzw. Informationen, wobei schnelle Informationsverarbeitung ermöglicht wird. 
Die Benutzung von GIS stellt vielfältige Methoden zur Verfügung, die auf die Daten angewendet werden können z.B. die Auswahl nach geografischen Kriterien sowie alle (statischen) Standard-Datenbankenfunktionen auf die nichträumlichen Daten in der Datenbank wie Summe, Min, Max, Standardabweichung etc. Die meisten GIS benutzen relationale Datenbanken, in solchen Systemen kann dann auch SQL (STANDARD QUERY LANGUAGE) angewendet werden. Es erlaubt dem Nutzer durch seine Grafik sich die Datenbank bzw. Informationen logisch durch Klicken zu erschließen. Wenn z.B. ein Bereich ausgewählt wurde, wird dem Benutzer eine Tabelle mit allem mit diesen Inhalten in Verbindung stehenden Informationen aufgezeigt und mit diesen wieder und vice versa.
Wenn ein GIS  erstellt wird, benötigt man eine „Grundlagen Landkarte“, auf der jeder Punkt, jede Line und jedes Gebiet einen einzigartigen Identifikationscode erhält. Dieser Code kann dann mit den Informationen in der Datenbank über ein neues Datenbank-Attribut verlinkt werden, dass in die Datenbasis eingeführt wird, die Verlinkung erfolgt dann automatisch.
7.3.4	Medical GIS
Nachdem die Medizinische Gemeinschaft vor einigen Jahren realisiert hatte, wie viele Geografische Daten sie aufbewahrt hatte und wie wichtig diese sind bzw. sein könnten, wenn man in der Lage wäre, sie zu visualisieren, hat sie Mittel und Wege gefunden, diese nutzbar zu machen und zwar mit den Verknüpfungs- und Visualisierungsmöglichkeiten von GIS. GIS wird schon auf verschiedenen Gebieten angewendet z.B. Zum Managen von Material, menschlichen Ressourcen und Logistik, zum Lokalisieren des nächstliegenden Krankenhauses über das Internet, zum Finden von Infektionskrankheiten und zum Entdecken von Lücken im kindlichen Abwehrsystem etc. Zum Beispiel hat das Loma Lima Universitätskrakenhaus ein GIS entwickelt, das auf dem Environmental Systems Research Institutes ArchView basiert und eine Karte mit allen Betten des Krankenhauses beinhaltet. Diese ist verlinked mit der Patientenakte eines jeden Patienten und erlaubt es dem Klinikpersonal jeden Patienten zu finden auf eine visuelle Art und Weise. 
GIS ist nicht eingeschränkt auf Abbildungen der realen Welt, sondern es kann für alles, was in Regionen und Gebiete eingeteilt werden kann, benutzt werden, um zusammenhängende Informationen zu speichern und zu bearbeiten. Es gibt auch ein Softwarepaket genannt Bodyviewer von ESRI and GeoHealth Inc., das es erlaubt den menschlichen Körper darzustellen. Es nutzt die ICD9 Codes (International Classification of Deseases), um das menschliche Antlitz mit der Datenbasis, die die Informationen über die Patienten enthält oder anderen medizinischen Datenbasen, zu verlinken. 
7.3.5	Web-based GIS
Durch das Web gibt es noch mehr Möglichkeiten für GIS z.B. die weltweite Möglichkeit des Datenaustausches, das Finden und Analysieren von neuen Datensets über das Internet genauso wie die Verfügbarkeit von und Möglichkeit zur Informationssammlung über einfache grafische Multi-Plattform-Umgebungen auf andere Datenbanken weltweit zuzugreifen. Ebenso ist es möglich GIS in Verbindung von HTML zu nutzen, was in älteren Features nicht möglich war.
Der größte Vorteil von Web-GIS ist, dass der User nicht die Komplexitäten der speziellen Software (der betreffenden GIS-Datenbank) verstehen muss, es genügt, wenn er mit einem Web-Browser umgehen kann, um alle Informationen der Datenbank nutzen zu können. Die Datenbank kann also von jedem der den Inhalt versteht genutzt werden ohne spezielle technische Fähigkeiten vorauszusetzen.
In der Studie wurde aber nur lokales GIS eingesetzt.
7.4	Systemvorrausetzungen und Entwicklung
In der Studie wurde mit den Daten (Fragebogen und Rückenschmerzen-Zeichnungen) des NHS (Norwick Park Hospital) gearbeitet. Bisher in Papierform und als Statistiken aufbewahrt, was einen schmalen Grad an Analyse (Eins-zu-eins-Vergleiche) zuließ, aber keine Komplexen (Querschnittsuntersuchungen). Eben das sollte nun durch die Studie geändert werden. Durch Benutzung von HTML, SVG, ASP, und GIS sollte ein System geschaffen werden, dass die Querschnittsuntersuchungen  und Datenspeicherung ermöglicht. Es sollte Benutzerfreundlich sein und dem medizinischen Personal erlauben Daten und Zeichnungen hinzuzufügen und die wiederholte Auswertung ermöglichen. Man sollte nicht nur über die Zeichnungen Zugriff auf die gewünschten Daten (Patientenakten) bekommen, sondern auch über die entsprechenden Patientenakten die Highlights (Statistiken etc.) der Schmerzregionen, die mit der jeweiligen Patientenakte in Verbindung stehen, finden können.
Basieren auf diesen Anforderungen wurden letztendlich drei Vorschläge unterbreitet:
o	ASP in Beziehung mit GIF „Körper-Landkarten“
o	ASP in Beziehung mit SVG „Körper-Landkarten“
o	GIS basierte Lösung
Alle diese Lösungen interagieren mit der Rückschmerzen-Datenbank.
In der Datenbank wurden die Regionen nach den Dermatomen der Haut s.o. in Hotspots eingeteilt, wobei die Haut z.B. in RRT1 (Rear right dermatome T1) – Hinteres Rechtes Dermatom T1 benannt wird. Dazu gibt es eine Tabelle, wo jeder einzelne Körperabschnitt mit derartigen Codes bzw. Abkürzungen identifiziert wird.
7.4.1	ASP in Verbindung mit GIF „Körper-Landkarten“
In diesem Design enthält die GIF „Körper-Landkarte“ Links, die andere Optionen öffnen, die in Frames auf der Webseite dargestellt werden. Das erlaubt die Auswahl der Art des Schmerzes und der benötigten Daten, in Beziehung zum ausgewählten Körperabschnitt. Wenn eine davon ausgewählt wurde, wird eine ASP Anfrage, die auf einem Web-Server gespeichert ist, ausgeführt und durchsucht die Rückenschmerzen Datenbasis mit SQL. Das Ergebnis wird dann an den Client als Webseite ausgegeben (siehe Abb.11).

Abbildung 19, ASP mit GIF
Da die Original Rückenschmerz-Zeichnungen auch auf dem Web-Server gespeichert sind, kann kontrolliert werden, ob irgendwelche Verallgemeinerungsfehler wie oben bereits erwähnt vorliegen.
7.4.2	ASP in Verbindung mit SVG „Körper-Landkarten“
Dieses Design arbeitet genauso wie das oben beschriebene mit dem Unterschied, dass hier eine SVG „Körper-Landkarte“ als Verbindung zu den ASP-Anfragen verwendet wird. Überraschenderweise jeweils eine extra Landkarte für jede Art von Schmerzen, dadurch wird dem Benutzer ermöglicht die Auswahl der Region und des Schmerzes auf einer grafischen Oberfläche zu machen und nicht wie oben über Hyperlinks. Dies ist bei SVG möglich, obwohl die einzelnen „Körper-Landkarten“ relativ klein sind, da SVG Bilder als Vektoren nur mit den Endkoordinaten speichert und dadurch die Landkarten vergrößerbar und drehbar sind. Wenn eine Region ausgewählt wurde wird eine Webseite durch XLink Funktionen geladen mit allen Links, die mit dieser Region verbundene Daten enthalten. Alle möglichen ASP Anfragen jede Region betreffend sind auf einem PWS Server gespeichert und werden bei Anfrage jedes Mal erneut ausgeführt. In Abb.12 sieht man wieder das Ergebnis einer Anfrage.

Abbildung 20, ASP mit SVG
7.4.3	GIS basierte Lösung
Diese Lösung wurde durch Digitalisieren der Umrisse von jedem Dermatom kreiert. Diese wurden als räumliche Polygone gespeichert. Und auch hier gibt es für jede der vier Schmerzarten eine extra Landkarte. Jedes dieser vier Polygone bekam dann eine einzigartige Identifikationsnummer und dadurch konnten diese dann einfach mit der Datenbasis verlinked werden. Jedes der Dermatome dieser Polygone bekommt einen Dermatome-Code-Namen wie z.B. „RRT1“, der lautet wie die korrespondierende Region (aus der Dermatome Tabelle). 
Es wird eine neue Tabelle eingeführt, die in den Spalten die vier Schmerzarten angibt, in den Zeilen vorne die Studiennummer (Patientennummer) und in den Felder die Dermatom Codes (Abb.13).

Abbildung 21, Link Tabelle GIS Lösung
Diese Tabelle speichert unter verschiedenen Attributen die Regionen der Schmerzen, an denen ein Patient leidet (Abb.13). 

Abbildung 22, Gleichzeitige Auswahl von Schmerztyp und Region
Jedes der verschiedenen Attribute ist dann wiederum mit der korrespondierenden Dermatome Abbildung verlinked, genauso wie der Rest der Datenbasis. (Abb.14).

Abbildung 23, Schmerzort und Details von Patient 2009
7.5	Prüfung und Vergleich der Lösungen
Alle Lösungen beinhalten dieselbe Datenbasis aus den Fragebogen und eingescannten Zeichnungen sowie die Verlinkung unter korrespondierenden Daten. Alle Lösungen vielleicht mit Ausnahme der GIS Lösung, die zusätzliches Training erfordert, um ihre volle Funktionalität zu erfassen, sind leicht vom Personal handhabbar. Es können bei allen auch neue Daten hinzugefügt oder alte gelöscht werden, wobei aber bei den ASP Lösungen ein Zugang zum Web Server vorhanden sein muss. Die andere Lösung arbeitet mit einem Client/Server Framework und platziert ihre Daten auf einem Web-Server. Alle Lösungen können per grafischem User Interface also per „Point and Click“ bedient werden anstatt des Schreibens von komplexen Datenbankanfragen. Auch sind alle Zeichnungen mit der Datenbasis verlinkt und umgekehrt. Aber die einzige Lösung, die die Region in der Grafik hervorhebt bzw. anzeigt, wenn in der Tabelle bestimmte Schwerpunkte gesucht werden, ist GIS. 
Aber die ASP Lösung kann auf Grund ihres weit verbreiteten Charakters (und daraus folgender Einfachheit) nur bereits vorgegebene  Abfragen starten bzw. Analysen liefern. Dort, wo keine vorgegebene Abfrage vorhanden ist, zeigt GIS seine Stärke. Bei GIS kann man ebenfalls parallel mehrere Abfragen starten z.B. Taubheit und Pins und Nadeln (das funktioniert genauso mit verschiedenen Regionen wie mit verschiedenen Schmerzen) und dann die Korrelation dieser Daten untersuchen.
7.5.1	Vergleiche
In jeder Lösung kann der User an Hand einer Grafik auswählen, was ihn interessiert, aber dort hört die Gleichheit dann auch schon auf.
Beim GIF basierten Ansatz ist die Körper-Landschaft das Auswahlkriterium und der Rest der Auswahl erfolgt über Hyperlinks. Die Vorteile sind zum einen die Einfachheit, der User muss die zugrunde liegende Technologie nicht verstehen. Der User muss nur einen Web-Browser benutzen können. Weiter müssen Daten nicht lokal gespeichert werden und die  Datenbasis kann nur mit Administratorrechten verändert werden. Sie ist sinnvoll, weil Vergleiche auch ohne tieferes Verständnis der Datenbasis gemacht werden können.
Bei dem SVG basierten Ansatz kommt zusätzlich eine vergrößerbare und drehbare Darstellung hinzu, die eine Auswahl der Schmerzarten über Hyperlinks ersetzt. Diese wurde als die bessere der beiden angesehen wegen der erhöhten Funktionalität ihres Interfaces (also wegen des vermehrten Grafikanteils bei der Auswahl), nach Rücksprache mit den Experten vom Norwick Krankenhaus.
Bei der GIS Lösung können die Benutzer so viele Regionen wie sie möchten parallel anfragen, bei den anderen beiden jeweils nur eine zur Zeit. Außerdem können mit dem GIS Query Builder eigene Anfragen geschrieben werden z.B. Schmerzen im Arm und im Bein desselben Patienten. Ebenso ist es bei den GIF und SVG Lösungen nur möglich, ein bestimmtes Datenset zu durchsuchen z.B. Personal Datenset, Medizinisches Datenset etc. während bei GIS durch den GIS Query Builder alle durchsucht werden können. Das erlaubt Fragen wie z.B. Zeig mir die Position von jedem, der die Frage sechs auf dem psychologischen Fragebogen in einer bestimmten Art und Weise beantwortet hat. Bei den anderen Lösungen kann man nur ein Datenset also eine Patientenakte zurzeit betrachten und bei GIS wird jede Tabelle jeder ausgewählten Akte angezeigt. Der Nachteil von GIS ist seine Komplexität, die dazu führt, dass jeder Benutzer eine besondere Schulung benötigt, um sinnvoll damit arbeiten zu können und zum anderen die hohen Kosten, die dadurch entstehen.
Die Schlussfolgerungen daraus sind das die am besten geeigneten Lösungen die SVG und GIS Lösungen sind. Die SVG, wenn es darauf ankommt, möglichst vielen Personen den Zugang mit minimalem Training und zu geringen Kosten zu ermöglichen und die GIS Lösung, wenn es auf die bestmögliche Analyse der aktuellen Daten ankommt. Dazu kommen die Kosten, die Komplexität und die Tatsache, dass das System momentan noch eine spezielle Technologie benötigt, um verbreitet zu werden. Vergleich als Tabelle in Abb. 16.

Table 12.2 
SVG vs. GIS solutions			
	SVG	GIS	
Separate diagram for each pain type	Yes	Yes	
Panning and zooming	Yes	Yes	
Multiple selections of regions	No	Yes	
Distributed	Yes	Yes
Yes	
Update of database	No	Yes	
SQL	No	Yes	
Highlight linked records	No	Yes	
Training needed	No	Yes	
Data analysis	No	Yes	
Cost of System	Economical (SVG freeware	Can be expensive	
	Plug-in + Web browser)		

Abbildung 24, Tabelle Vergleich SVG und GIS

7.6	Zusammenfassung
Für das Rückenschmerz Problem, das eines der am weitesten verbreiteten ist, aber trotzdem noch kaum untersucht wurde bzw. noch kaum Datenmaterial in einer einfach verbreitbaren Form existiert also in Form von elektronischen Daten, wurde hier eine mögliche Lösung zum Austauschen, Analysieren und Verwahren gefunden.
Diese Studie führt zu einer Lösung, die es erlaubt sich durch eine Datenbank auf einer graphischen Ebenelogisch durchzuklicken. Das ist ihre Möglichkeit Informationen auf einer tieferen Ebene zu verbinden. Und gleichzeitig der Anknüpfungspunkt zu unserem Seminarthema. Denn hier geht es um die graphische und nicht semantische Verbindung bzw. Anordnung von Informationen, um besser und schneller den gewünschten Inhalt zu finden. Während es ja bisher um die Verknüpfung und bessere Suchmöglichkeiten durch die Semantik bzw. über Ontologien ging.
Auch sind einige interessante noch zu untersuchende Aspekte aufgefunden worden. Der wichtigste ist der der Körperzoneneinteilung, d.h. ist die hier verwendete die Bestmögliche oder gibt es noch andere und vielleicht Bessere? Des Weiteren könnte noch die Verwendung einer XML basierten medizinischen Markup Sprache in Verbindung mit SVG untersucht werden, um das grafische Potential von SVG auszunutzen.
8.	
Literaturverzeichnis
Geroimenko, Vladimir/ Chen, Chaomei  (eds.) (2003): Visualizing the semantic Web : XML-based internet and information visualization, Springer, London [u.a.].