Diplomarbeit - Professur Graphische Datenverarbeitung

Сomentários

Transcrição

Diplomarbeit - Professur Graphische Datenverarbeitung
Professur für Grafische Datenverarbeitung
Fachbereich Informatik und Mathematik
Diplomarbeit
Entwicklung einer Autorenumgebung
zur Erstellung von eLearning-Kursen
aus Wiki-Inhalten
vorgelegt von
David Weiß
Prüfer: Prof. Dr.-Ing. Detlef Krömker
Frankfurt am Main, der 21. Mai 2008
Eidesstattliche Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Diplomarbeit ohne fremde
Hilfe und nur unter Verwendung der zulässigen Mittel sowie der angegebenen Literatur
angefertigt habe.
Die Arbeit wurde bisher keiner anderen Prüfungsbehörde vorgelegt und auch noch nicht
veröffentlicht.
Frankfurt am Main, den 21.05.2008
David Weiß
Zusammenfassung
Seit ihrer Entstehung Mitte der 90er Jahre haben Wikis einen immensen Siegeszug angetreten und sind mittlerweile kaum noch aus dem üblichen Netzwerk-Alltag“ wegzuden”
ken. Sie finden sich als altbekannte Homepages und aufpolierte Web 2.0-Plattformen“,
”
als Schwarze Bretter“ und Organisations-Talente“ wieder, als Ansammlungen von mehr
”
”
oder weniger nützlichen Informationen und als Grabstätten und Zeugnisse eines noch immer anhaltenden Hypes kurz nach der letzten Jahrtausendwende. Was unscheinbar als
Wissens- und Ideenverwaltungswerkzeug“ begann, entpuppte sich schnell als Verwirkli”
chung der Ursprünglichen Idee des Internets, dass Inhalte nicht nur konsumiert, sondern
auch von jedem Teilnehmer selber angeboten werden können. Dieser Paradigmenwechsel
von der Instruktion hin zur Konstruktion manifestierte sich letztendlich auch im eLearning, wo unter der Prämisse Lernen durch Lehren“ entsprechende Methoden – auch unter
”
dem Einsatz von Wikis – entwickelt und umgesetzt wurden.
Diese Tatsache, dass Lernende zu Lehrenden oder im Bezug auf eLearning zu Autoren
werden, fordert von den eigentlichen eLearning-Autoren und ihrer Funktion als Lehrende
völlig neue Praktiken und Strategien bezüglich der Vorbereitung und Planung, Begleitung
und Unterstützung bzw. der Evaluierung und inhaltlichen Aufbereitung einer Veranstaltung. Betrachtet man den Einsatz von klassischen“ eLearning-Anwendungen, erhalten
”
die Lehrenden an dieser Stelle die Unterstützung von zahlreichen Autorenumgebungen,
die ihnen diesbezüglich eine gesonderte Rolle zuschreiben, die es ihnen ermöglicht, die
Gegebenheiten mit dem nötigen Abstand zu betrachten und auf deren Basis mit entsprechenden Werkzeugen handeln zu können. Diese privilegierte Rolle fehlt den Autoren im
Umgang mit Wikis, da sie sich technisch gesehen mit den Lernenden auf einer Ebene
befinden, was insbesondere dazu führt, dass während einer Veranstaltung und im Hinblick auf die zur Verfügung stehenden Ressourcen lediglich marginal motivierend bzw.
unterstützend Einfluss genommen werden kann.
Diese und weitere Problematiken im Zusammenhang eines Autorenprozesses im Bezug
auf Wiki-Inhalte werden in dieser Diplomarbeit analysiert und mit der entsprechenden
Entwicklung einer Autorenumgebung zur Erstellung von eLearning-Kursen gelöst.
Inhaltsverzeichnis
Verzeichnisse
i
Abbildungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
Tabellenverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Abkürzungsverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Einleitung
ix
1
1.1
Motivation und Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Zielsetzung und Überblick . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.3
Aufbau dieser Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2 Grundlagen
7
2.1
Paradigmenwechsel: Wiki . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.2
Wikis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.1
2.3
Eigenschaften und Funktionalitäten . . . . . . . . . . . . . . . . . . 10
2.2.1.1
Seitenbezogen . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1.2
Seitenübergreifend . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1.3
User Interface . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.2
Wiki-Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3
Einsatzszenarien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
eLearning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.1
eLearning-Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1.1
Beispiel: LernBar . . . . . . . . . . . . . . . . . . . . . . . 24
ii
INHALTSVERZEICHNIS
2.3.2
2.4
Autorenumgebungen . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Technologieüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3 Analyse
3.1
31
Autorenprozesse und -umgebungen . . . . . . . . . . . . . . . . . . . . . . 31
3.1.1
eLearning-Autoren und Wikis . . . . . . . . . . . . . . . . . . . . . 32
3.1.2
eLearning-Software und Authoring . . . . . . . . . . . . . . . . . . 32
3.1.2.1
3.1.3
3.1.4
3.2
Wikis und Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.3.1
Beispiel: Anatomie-Wiki . . . . . . . . . . . . . . . . . . . 36
3.1.3.2
Beispiel: BasisReliPaed . . . . . . . . . . . . . . . . . . . . 38
3.1.3.3
Beispiel: OKAPI . . . . . . . . . . . . . . . . . . . . . . . 39
Zusammenfassung und Beurteilung . . . . . . . . . . . . . . . . . . 41
Wiki-Inhalte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1
3.2.2
3.3
Beispiel: LernBar . . . . . . . . . . . . . . . . . . . . . . . 33
Harmonisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2.1.1
Struktur und Layout . . . . . . . . . . . . . . . . . . . . . 44
3.2.1.2
Kontext und Metadaten . . . . . . . . . . . . . . . . . . . 45
3.2.1.3
Wiki Markup und WikiCreole . . . . . . . . . . . . . . . . 47
3.2.1.4
Wiki Interchange Format (WIF) . . . . . . . . . . . . . . 49
Integration
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2.1
Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2.2.2
DavWiki/WikiRPC
3.2.2.3
WikiGateway . . . . . . . . . . . . . . . . . . . . . . . . . 55
. . . . . . . . . . . . . . . . . . . . . 53
eLearning-Kurse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.1
Struktur und Layout . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.3.2
Standardisierungsversuche . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.2.1
IMS CP/LD und QTI . . . . . . . . . . . . . . . . . . . . 58
3.3.2.2
IEEE LOM/SMIL . . . . . . . . . . . . . . . . . . . . . . 59
3.3.2.3
SCORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
INHALTSVERZEICHNIS
iii
4 Konzept
63
4.1
Lösungsansatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3
4.2.1
Die Komponenten der API . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.2
Wrapper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Funktionen . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.2.2.2
Wiki-Schnittstellen . . . . . . . . . . . . . . . . . . . . . . 71
4.2.2.3
Übergabeformat . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.3
Funktionen der API
4.2.4
Anfrageaufbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.2.5
Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
. . . . . . . . . . . . . . . . . . . . . . . . . . 72
wikiPAGEs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.1
4.3.2
4.4
4.2.2.1
Konzept einer Wiki-Seite . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.1.1
Layout und visuelle Stile . . . . . . . . . . . . . . . . . . . 77
4.3.1.2
Metadaten . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3.1.3
Seitenkontext und IDs . . . . . . . . . . . . . . . . . . . . 78
Archive und Binärdateien . . . . . . . . . . . . . . . . . . . . . . . 79
Autorenumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.4.1
User Interface (UI) . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.4.2
Basisfunktionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.3
4.4.2.1
API-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . 82
4.4.2.2
Benutzergruppen . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.2.3
Wiki-Pools . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.4.2.4
Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Authoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.4.3.1
Kurs- und Seitenerzeugung . . . . . . . . . . . . . . . . . 85
4.4.3.2
Informationsextraktion . . . . . . . . . . . . . . . . . . . . 87
4.4.3.3
Textbearbeitung . . . . . . . . . . . . . . . . . . . . . . . 89
iv
INHALTSVERZEICHNIS
4.4.4
4.4.5
Exportmodule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.4.4.1
LernBar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.4.4.2
SCORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.4.5.1
Navigationspfade (WikiPaths) . . . . . . . . . . . . . . . . 94
4.4.5.2
Semantische Informationen . . . . . . . . . . . . . . . . . 95
5 Implementierung
97
5.1
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.2.1
Wrapper: MediaWiki . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.2.2
Anfragenaufbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.2.3
Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.2.3.1
5.3
Autorenumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.1
Funktionen und User Interface . . . . . . . . . . . . . . . . . . . . . 106
5.3.2
Datenbankdesign und Caching . . . . . . . . . . . . . . . . . . . . . 107
5.3.3
Exportmodul: LernBar . . . . . . . . . . . . . . . . . . . . . . . . . 108
5.3.3.1
Kurs- und Seitenerzeugung . . . . . . . . . . . . . . . . . 109
5.3.3.2
Textbearbeitung . . . . . . . . . . . . . . . . . . . . . . . 110
6 Zusammenfassung
6.1
wikiPAGEs . . . . . . . . . . . . . . . . . . . . . . . . . . 103
113
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Literaturverzeichnis
117
A Glossar
121
B wikiPAGEs
131
B.1 Struktur und Inhalt einer Seite (XHTML) . . . . . . . . . . . . . . . . . . 131
B.2 Layout und Kontext einer Seite (CSS/XML) . . . . . . . . . . . . . . . . . 133
Abbildungsverzeichnis
2.1
Architektur von Wikis-Systems [Fou08b] . . . . . . . . . . . . . . . . . . . 10
2.2
Komponenten der LernBar: Player . . . . . . . . . . . . . . . . . . . . . . 25
2.3
Komponenten der LernBar: Studio . . . . . . . . . . . . . . . . . . . . . . 26
2.4
Komponenten der LernBar: Portal . . . . . . . . . . . . . . . . . . . . . . . 27
3.1
Wikis im eLearning: Anatomie-Wiki . . . . . . . . . . . . . . . . . . . . . . 37
3.2
Wikis im eLearning: BasisReliPaed . . . . . . . . . . . . . . . . . . . . . . 39
3.3
Wikis im eLearning: OKAPI . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4
Bestimmungsfaktoren beim CSCL [Hin04] . . . . . . . . . . . . . . . . . . 42
3.5
WikiCreole: Vereinheitlichte Wiki-Syntax [Chr07b] . . . . . . . . . . . . . . 48
3.6
IMS Content Packaging (prinzipieller Aufbau) [Paa04] . . . . . . . . . . . . 59
4.1
Überblick des Lösungsansatzes . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2
Komponenten der API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.3
Komponenten der Autorenumgebung . . . . . . . . . . . . . . . . . . . . . 81
5.1
Startseite der Autorenumgebung . . . . . . . . . . . . . . . . . . . . . . . . 97
5.2
Klassendiagramm des Lösungsansatzes . . . . . . . . . . . . . . . . . . . . 99
5.3
Anfragenbearbeitung der API . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4
Anfragenbearbeitung der Autorenumgebung . . . . . . . . . . . . . . . . . 105
5.5
User Interface der Autorenumgebung . . . . . . . . . . . . . . . . . . . . . 106
5.6
Seitenproduktion eines LernBar-Kurses . . . . . . . . . . . . . . . . . . . . 109
5.7
Seitenbearbeitung eines LernBar-Kurses . . . . . . . . . . . . . . . . . . . 110
Tabellenverzeichnis
3.1
Elemente zur Strukturierung von Texten . . . . . . . . . . . . . . . . . . . 45
3.2
Elemente zur Gestaltung von Texten . . . . . . . . . . . . . . . . . . . . . 45
3.3
Kontext einer Wiki-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4
Metadaten einer Wiki-Seite . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.1
Funktionen des Wrappers: Kategorie 1 . . . . . . . . . . . . . . . . . . . . 70
4.2
Funktionen des Wrappers: Kategorie 2 . . . . . . . . . . . . . . . . . . . . 71
4.3
Funktionen der API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.4
Komponenten von wikiPAGEs: Struktur und Layout . . . . . . . . . . . . 77
4.5
Komponenten von wikiPAGEs: Metadaten . . . . . . . . . . . . . . . . . . 79
4.6
Komponenten von wikiPAGEs: Seitenkontext . . . . . . . . . . . . . . . . 80
5.1
Verwendete Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.2
Schnittstellen der MediaWiki . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.3
Benutzerspezifische Funktionen . . . . . . . . . . . . . . . . . . . . . . . . 107
5.4
Relationen der Autorenumgebung . . . . . . . . . . . . . . . . . . . . . . . 108
Abkürzungsverzeichnis
ix
Abkürzungsverzeichnis
ADL
Advanced Distributed Learning
Ajax
Asynchronous JavaScript and XML
ANSI
American National Standards Institute
API
Application Programming Interface
Atom
Atom Syndication Format
CAM
Content Aggregation Model
CBT
Computer Based Training
CM
Content Management
CMS
Content Management System
CP
Content Packaging
CSCL
Computer Supported Cooperative / Collaborative Learning
CSS
Cascading Style Sheets
DC
Dublin Core
DCMI
Dublin Core Metadata Initiative
DoD
Department of Defense
DOM
Document Object Model
DTD
Document Type Definition
FAQ
Frequently Asked Questions
GDV
Graphischen Datenverarbeitung
GPL
GNU General Public License
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol Secure
IEEE
Institute of Electrical and Electronics Engineers
IETF
Internet Engineering Task Force
IMS
Instructional Management System - Global
Learning Consortium
x
Abkürzungsverzeichnis
ISO
International Organization for Standardization
JS
JavaScript
JSON
JavaScript Object Notation
LAN
Local Area Network
LCMS
Learning Content Management System
LD
Learning Design
LdL
Lernen durch Lehren
LMS
Learning Management System
LOM
Learning Object Metadata
OSI-Model
Open Systems Interconnection Model
OSTP
Office of Science and Technology Policy
PHP
PHP: Hypertext Preprocessor
QTI
Question & Test Interoperability
RDF
Resource Description Framework
RPC
Remote procedure call
RSS 1.0
RDF Site Summary
RSS 2.0
Really Simple Syndication
RTE
Run-Time Environment
SCO
SCORM Content Objects
SCORM
Sharable Content Object Reference Model
SMIL
Synchronized Multimedia Integration Language
SN
Sequencing and Navigation
SOAP
Simple Object Access Protocol
SQL
Structured Query Language
SSL
Secure Socket Layer
UI
User Interface
UML
Unified Modeling Language
Abkürzungsverzeichnis
xi
URL
Uniform Resource Locator
W3C
World Wide Web Consortium
WAF
Wiki Archive Format
WAN
Wide Area Network
WBT
Web Based Training
WCMS
Web Content Management System
WebDAV
Web-based Distributed Authoring and Versioning
WIF
Wiki Interchange Format
WM
Wissensmanagement
WWW
World Wide Web
WYSIWYG
What You See Is What You Get
XHTML
Extensible Hypertext Markup Language
XML
Extensible Markup Language
XPath
XML Path Language
XSL
Extensible Stylesheet Language
XSLT
XSL Transformation
Kapitel 1
Einleitung
1.1
Motivation und Aufgabenstellung
Meine Motivation für diese Arbeit beruht größtenteils auf persönlichen Erfahrungen, die
ich sowohl als Student, als auch als unterstützende Kraft (Student Consultant) für eLearning Autoren bei dem Einsatz von Wiki-System in der Lehre und im universitären Umfeld
machen durfte [meg08]. Die dabei aufgetretenen Probleme (Abschnitt 3.1.4), sowohl für
die Lernenden aber insbesondere auch für die Lehrenden (bei denen diese Arbeit versucht
anzusetzen), schienen aufgrund ihrer hohen Dynamik und der Vielzahl an möglichen Faktoren selbst dann unumgänglich, wenn ein Muster der Problematik bereits erkennbar und
somit eine Vorhersage prinzipiell möglich war. Und in der Tat fällt ein erster objektiver
Blick auf die allgemeine Situation von Wikis im eLearning-Kontext nicht gerade positiv
aus:
Die Anzahl von eingesetzten Wikis und insbesondere die Anzahl von toten Wikis“ nimmt
”
ständig zu, was sich negativ auf die Akzeptanz und somit auf die potenzielle konstruktive
Mitarbeit der Teilnehmer auswirkt. Mal ganz davon abgesehen, dass es in den meisten
Fällen der Philosophie von Wikis widerspricht, da auf diese Weise viele voneinander unabhängige Dateninseln“ entstehen, anstatt Inhalte zweckmäßig miteinander zu vernet”
zen [Say06]. Dies führt dazu, dass die Inhalte zunehmend redundant, inkonsistent und
unübersichtlich vorliegen und sich zudem teilweise stark in der Art des Zugriffs voneinander unterscheiden, da die eingesetzten Wiki-Systeme an dem boomenden Web 2.0-Markt“
”
meist nur noch durch eine möglichst große Abgrenzung voneinander ihre Daseinsberechtigung finden [Det08]. Die größten Probleme ergeben sich aber aus meiner Sicht in der
Verwendung von Wikis in einem Echtzeitszenario“, d.h. bei Veranstaltungen im konstruk”
tivistischen Sinne, bei denen sowohl Lehrende (meist nur unterstützend) aber vor allem
2
1.2 Zielsetzung und Überblick
Lernende Inhalte kollaborativ erarbeiten, was wohl dem häufigsten Einsatz von Wikis in
der Lehre entspricht [Bre06b]. Hierbei, anders als in klassischen eLearning-Konzepten, in
denen dem praktischen Einsatz zunächst eine Planungsphase und ein Autorenprozess vorausgeht und erst im Anschluss eine Evaluierung ausgewertet werden kann, ist solch eine
chronologische Aufteilung im Umgang mit Wikis nur bedingt möglich. Der größte Teil der
Ausarbeitung (Planung, Authoring) und die entsprechende Auswertung muss während
des praktischen Einsatzes stattfinden, um als Autor in den meist sehr dynamischen Prozess eingreifen zu können [Chr07a].
Die zuvor genannten Punkte und die fehlenden Werkzeuge“, die dem Autoren einen Vor”
”
sprung“ gegenüber den Lernenden verschaffen, erfordern ein meist nicht zu bewältigendes
Maß an Engagement, Tatkraft, Know-How und zu investierender Zeit des Lehrenden. Je
nach Umfang des Szenarios und zur Verfügung stehender Ressourcen ist schon so manches
Projekt von vornherein zum Scheitern verurteilt.
Diese Missstände insbesondere auf der Seite der eLearning Autoren und mein ganz
persönlicher und grundsätzlicher Glaube an den Nutzen von Wikis (nicht nur im Sinne
der Lehre), sind die treibende Kraft, diese Problematik genauer zu untersuchen und mit
dem Erstellen eines – in diesem Sinne – nützlichen Werkzeuges zur Unterstützung der
Lehrenden eventuell Abhilfe zu schaffen.
1.2
Zielsetzung und Überblick
Unter Beachtung meiner Beweggründe, der Aufgabenstellung und eines zunächst ganz
pragmatischen Ansatzes meiner Diplomarbeit möchte ich die Zielsetzung unter dem folgenden Leitsatz“ zusammenfassen und festlegen, nämlich:
”
Den Zugriff auf die Inhalte von Wikis vereinfachen und ihren Nutzen im Sinne
der Lehre erhöhen.
Dieser zunächst ein wenig pathetisch klingende Satz scheint auf den ersten Blick eventuell
etwas zu abstrakt, auf dem zweiten allerdings entpuppt er sich als durchaus richtungsweisend und zweckmäßig. So weist er z.B. auf eine grundsätzliche Zweiteilung hin, welche
sich sowohl in meiner Analyse (Kapitel 3), als auch in meinem Konzept (Kapitel 4) und
letztendlich auch in der Implementierung (Kapitel 5) wiederfindet, die ich im Folgenden
konkretisieren möchte.
Der erste Teil bezieht sich auf den Zugriff auf Wiki-Inhalte und einer Betrachtung von
unterschiedlichsten Wikis als ein Konzept (wikiPAGEs). Ziel ist es hierbei – stets unter
1 Einleitung
3
Berücksichtigung schon bestehender Ansätze (3.2) – eine System und Engine-Unabhängige
Repräsentation von Wiki-Inhalten zu erarbeiten, welche über genau eine Schnittstelle abgefragt werden können. Konkret wird diese Funktionalität in einer API implementiert
(5.2), die auf die jeweiligen Informationen aus den unterschiedlichen Wiki-Systemen über
speziell implementierte Wrapper zugreifen kann. Diese Informationen werden dann analysiert, aufgearbeitet und an externe“ Anwendungen standardisiert weitergereicht.
”
Das diesbezüglich ausgearbeitete Konzept wird in den Abschnitten API“ (4.2) und wi”
”
kiPAGEs“ (4.3) abgehandelt.
Der zweite Teil, Nutzen im Sinne der Lehre erhöhen“, ist etwas umfassender und somit
”
auch im ersten Teil, insbesondere bei der Abstraktion von Wiki-Inhalten, von Bedeutung
und wurde deshalb in dem Abschnitt Autorenprozesse und -umgebungen“ (3.1) genauer
”
analysiert. Grundsätzlich besteht jedoch der prinzipielle Nutzen dieser Arbeit – wie bereits
im Abschnitt zur Motivation (1.1) angedeutet – in der Entwicklung eines Werkzeuges,
welches es Lehrenden ermöglicht, bei dem Einsatz von Wikis in der Lehre mit einem
gewissen Vorsprung gegenüber den Lernenden auf die Inhalte zuzugreifen und diese dann
aufzuarbeiten.
Einen wichtigen Anteil beschreibt hierbei ja schon die API, indem diese aus einer Vielzahl
von Wikis, die von einem Autoren eingesetzt werden, eine Meta-Wiki“ werden lässt,
”
welche es dem Autoren erleichtert, den Überblick zu bewahren bzw. gegebenenfalls erst
zu gewinnen. Somit kann er Information effizienter finden und in einem vereinheitlichen
Arbeitsprozess weiterverwenden.
Dieser Arbeits-/Autorenprozess wird dann in der speziell dafür entwickelten Autorenumgebung (5.3) weitergeführt, welche direkt auf der API bzw. dem Konzept wikiPAGEs“
”
aufsetzt. Grundlagen und Anforderungen für die Umsetzung dieser Umgebungen werden
in den Abschnitten eLearning-Software“ (3.3) und Produzieren von eLearning-Inhalten“
”
”
(3.1) analysiert und im Abschnitt 4.4 konzipiert.
Darüber hinaus soll es den Autoren ermöglicht werden, die bearbeiteten Inhalte durch
speziell implementierte Export-Module (5.3.3) an andere eLearning-Anwendungen (4.4.4)
weiterzureichen bzw. zu archivieren.
1.3
Aufbau dieser Arbeit
Im Kapitel 2 Grundlagen“ wird geklärt was Wikis zu Wikis macht“ und was davon zu ih”
”
rer enormen Popularität im eLearning und darüber hinaus beigetragen hat (2.1). Danach
folgt ein technisch, funktionaler Überblick (2.2) und eine Zuordnung zu den jeweiligen
Implementierungen (2.2.2). Im Anschluss folgt eine Ausarbeitung der Möglichkeiten, Wi-
4
1.3 Aufbau dieser Arbeit
kis allgemein und im Kontext der Lehre einzusetzen (2.2.3). Im Abschnitt eLearning“
”
(2.3) geht es dann darum, einen Überblick über bestehende Kategorien von eLearingSoftware zu schaffen und eine Einordnung von Wikis vorzunehmen. Bezogen auf die
unterschiedlichen Eigenschaften und Methoden dieser Software-Kategorien (2.3.1), werden dann mögliche Autorenprozesse und -umgebungen (2.3.2) abgehandelt. Abgeschlossen
werden die Grundlagen mit einem allgemeinen Überblick über die zum Einsatz gekommenen Technologien (2.4) mit Verweisen auf das Glossar am Ende dieser Arbeit.
Im Kapitel 3 Analyse“ werden die Themen aus den Grundlagen wieder aufgegriffen und
”
in Vorbereitung auf mein Konzept (Kapitel 4) untersucht und aufbereitet. Analysiert
werden drei Themenbereiche: Autorenprozesse und -umgebungen“ (3.1), Wiki-Inhalte“
”
”
(3.2) und eLearning-Inhalte“ (3.3).
”
Dabei werden zunächst die Autorenprozesse im Bezug auf das Authoring im Bereich von
eLearning-Software, insbesondere der LernBar (3.1.2), untersucht und im Gegensatz dazu
die Autorenprozesse, welche beim Einsatz von Wikis zum Tragen kommen (3.1.3). Hinzu kommt die Untersuchung der Zielgruppe: eLearning-Autoren (3.1.1) unter anderem
auch anhand von drei Beispiel Szenarien beim konkreten Einsatz von Wikis und deren
Auswertung bzw. der Gegenüberstellung gegenüber herkömmlicher eLearning-Software
3.1.4). In den beiden Abschnitten im Bezug auf Inhalte in Wikis“ und eLearning“ geht
”
”
es dann um die Eigenschaften der Inhalte beider Kategorien und wie man diese harmonisieren (3.2.1.2), integrieren (3.2.2) bzw. standardisieren (3.3.2) kann. Berücksichtigt
werden dabei bereits bestehende Lösungsansätze im Bezug darauf, wie sie in meine Arbeit
einbezogen werden können bzw. was überhaupt in Frage kommt.
Das Konzept“ (Kapitel 4) ist nach einer allgemeinen Beschreibung des Lösungsansatzes
”
(4.1) dann ebenfalls in drei Teile untergliedert.
Der erste Teil befasst sich mit dem vereinheitlichten Zugang im Bezug auf die unterschiedlichsten Wiki-Engines und einer möglichen Integration in externe Anwendungen, wie z.B.
einer Autorenumgebung. Der Zugang wird über eine API“ realisiert (4.2) und beschäftigt
”
sich im Wesentlichen mit den unterschiedlichen Schnittstellen verschiedener Engines, welche über Wrapper“ (4.2.2) angesteuert werden und der Aufbereitung der Inhalte an sich
”
(4.2.3, 4.2.4).
Der zweite und dritte Teil bezieht sich dann auf die Konzeptionen der eigentlichen Au”
torenumgebung“ (4.4) und die Art und Weise, wie sie das standardisierte Format der
API – den wikiPAGEs“ (4.3) – verarbeitet und somit dem Autoren zur Produktion von
”
eLearning-Kursen zur Verfügung stellt. Die Autorenumgebung selber unterteilt sich dabei in ihre Basisfunktionen“ (4.4.2) und ihre Funktionen zum eigentlichen Authoring“
”
”
(4.4.3), die Exportmodule“ (4.4.4) und die möglichen Erweiterungen“ im Bezug auf
”
”
andere Arbeiten (4.4.5).
1 Einleitung
5
Im vorletzten Kapitel 5, der Implementierung“, wird zunächst die Konzeption einer
”
möglichen prototypischen Umsetzung der API“ (5.2), eines Wrappers zur Ansteuerung
”
einer Wiki-Engine und dem wikiPAGEs-Format beschrieben, gefolgt von der – darauf
aufsetzenden - Umsetzung der Autorenumgebung (5.3) und den entsprechenden Exportmodulen für eine eLearning-Anwendung.
Zu guter Letzt folgt eine Zusammenfassung“ (6) der in dieser Arbeit erzielten Er”
gebnisse und ein Ausblick“ (6.1) auf mögliche Ergänzung oder diesbezüglichen An”
knüpfungspunkten für zukünftige Arbeiten.
Kapitel 2
Grundlagen
In diesem Kapitel gehe ich zunächst im Abschnitt Paradigmenwechsel: Wiki“ (2.1) auf ei”
ne allgemeine Betrachtung von Wikis ein, mit einem klaren Fokus auf ihren Ursprung und
ihren Einfluss auf die Gesellschaft. Dies ist grundlegend, um Wikis und ihre Inhalte strukturell besser begreifen zu können. Um die Inhalte technisch und im Kontext dieser Arbeit
besser verstehen zu können, folgt im Abschnitt Wikis“ (2.2) dann eine Beschreibung
”
ihrer elementaren und optionalen (aber gängigen) Eigenschaften und Funktionalitäten“
”
(2.2.1), ein Überblick der relevanten Wiki-Engines“ (2.2.2) und den daraus resultierenden
”
Einsatzszenarien“ (2.2.3).
”
Im zweite Teil geht es dann um einen Überblick und um eine Definition von eLearning”
Software“ (2.3.1) und Autorenumgebungen“ (2.3.2). Dies ist notwendig, um die Fülle der
”
existierenden eLearning-Anwendungen und deren Autorentools auf die für diese Arbeit
relevanten Unterkategorien zu beschränken und um bei der Analyse gezielt auf die Inhalte
eingehen zu können, welche bei dem Einsatz von Wikis in Frage kommen.
Im letzten Abschnitt Technologieüberblick“ (2.4) werden alle weiteren Grundlagen für
”
diese Arbeit zusammengefasst und mit Verweisen auf das Glossar am Ende dieser Diplomarbeit versehen, um eine eventuelle Recherche bezüglich der technologischen Vorraussetzungen zu erleichtern.
2.1
Paradigmenwechsel: Wiki
Zunächst als Wissens- und Ideenverwaltungswerkzeug“ für die Software-Entwicklung
”
konzipiert, entwickelte Ward Cunningham, ein US-amerikanische Informatiker, 1995 die
erste Wiki mit dem Namen WikiWikiWeb. Diese Umsetzung und all ihre Nachfolger vereint, was W. Cunningham in seinen Definitionen (zu finden in seiner Ur-Wiki [Cun05])
8
2.1 Paradigmenwechsel: Wiki
mit den Worten If you haven’t used a wiki before, be prepared for a bit of CultureShok1“
”
einleitet und fortführt mit: The beauty of Wiki is in the freedom, simplicity, and power
”
it offers.“. Diese recht allgemeine Formulierung und der vorangegange Hinweis ließen bereits damals eine gewisse Brisanz erahnen, welche sich auch durchaus mit der heutigen
Popularität und Verbreitung von Wikis deckt.
Konkreter ist mit simplicity“ die Eigenschaft von Wikis gemeint, Inhalte in Wikis und
”
somit auch Inhalte im Netz nicht weiter nur konsumieren zu können – was bis dato für
die Mehrheit der Teilnehmer im Netz der Fall war – sondern diese Inhalte auch genauso
einfach, d.h. direkt im Browser, verändern und ergänzen zu können. Womit wir auch
schon beim zweiten Schlagwort wären: freedom“. Freiheit bezeichnet in diesem Kontext
”
die Möglichkeit, dass nun prinzipiell jeder, der einen Zugang zum Netz und einen Browser
besitzt, Inhalte hinzufügen, ändern, löschen und beliebig untereinander verlinken kann.
Der Browser wird somit einfach und schnell2 (meist durch einen Mausklick) zum Editor.
D.h. der Konsument wird zum Produzent, worauf sich wohl der letzte Ausdruck power it
”
offers“ von W. Cunningham bezieht. Er war allerdings nicht der erste, der diese Macht“
”
erkannt und benannt hat, sondern vielmehr derjenige, der das Werkzeug geschaffen hatte,
um diese Kraft“ freizusetzen.
”
Als direkter Vordenker von W. Cunningham und seinem Konzept Wiki“ gilt sicherlich
”
Tim Berners-Lee, der Erfinder des World Wide Web (WWW) (1989). Bei dessen Grundidee hatte er genau diese Funktionalität (jeder kann senden und empfangen) vorgesehen,
was allerdings damals an der Umsetzung scheiterte. Ebenfalls an der Umsetzung gescheitert, aber grundsätzlich mit der selben Idee, analysierte Berthold Brecht bereits 1927-1932
den Rundfunk in seinen Radiotheorien [Wöh88]. Auszüge aus seiner Kernaussage lassen
sich fast eins zu eins von einer besseren Version des Rundfunks auf das Konzept Wiki“
”
als konsequentere Umsetzung der ursprünglichen Idee des WWWs abbilden:
Um nun positiv zu werden: das heißt, um das Positive am Rundfunk
”
aufzustöbern; ein Vorschlag zur Umfunktionierung des Rundfunks: Der Rundfunk ist aus einem Distributionsapparat in einen Kommunikationsapparat zu
verwandeln. Der Rundfunk wäre der denkbar großartigste Kommunikationsapparat des öffentlichen Lebens, ein ungeheures Kanalsystem, das heißt, er wäre
es, wenn er es verstünde, nicht nur auszusenden, sondern auch zu empfangen,
also den Zuhörer nicht nur zu hören, sondern auch sprechen zu machen und
ihn nicht zu isolieren, sondern ihn auch in Beziehung zu setzen.“
1
die Schreibweise entspricht einem Feature einiger Wikis, genannt CamelCase“ oder mixed-case“
”
”
und bezeichnet die kamelhöckerähnliche, gemischte Groß- und Kleinschreibung von Worten für die automatische Erkennung und Verlinkung von Seiten
2
das hawaiianische Wort für schnell“ heißt wiki“
”
”
2 Grundlagen
9
Somit ist das, was man heute unter “Web 2.0“ (d.h. insbesondere unter Wikis, aber auch
Blogs, Podcasts etc.) versteht und in vielerlei Hinsicht auch sicherlich kritisch betrachtet
werden kann, eigentlich nur“ die technische Umsetzung der Möglichkeit, selber zum Autor
”
der gängigen Medien (Radio, Fernsehen, Literatur) zu werden und relativ einfach seinen
Beitrag zu der gemeinschaftlichen Nutzung von unterschiedlichsten Informationen leisten
zu können.
Diese Idee und nicht zuletzt auch dann der Einsatz von Wikis war es dann auch, welcher
im Umfeld des eLearnings eine ähnliche Umwälzung“ und einmal mehr eine Wiederbe”
”
lebung“ auslöste [Hon05]. Denn wie bei der bereits in den 90ern in der Lehre eingeführten
Unterrichtsmethode Lernen durch Lehren (LdL)“ nach Jean-Pol Martin, wird auch im
”
eLearning durch den Einsatz von Wikis genau das möglich gemacht: Aus den Lernenden
werden die Lehrenden, also ein Paradigmenwechsel von der Instruktion hin zur Konstruktion. Allerdings wirft dies selbst in der normalen“ Lehre noch heute, wie von Jean-Pol
”
Martin in seinem Aufsatz Lernen durch Lehren: Paradigmenwechsel in der Didaktik?“
”
beschrieben [Jea07], noch immer und dann natürlich auch insbesondere im eLearning,
mehrere Probleme auf, auf die ich in meiner Analyse von Autorenprozessen (3.1) noch
näher eingehen möchte.
2.2
Wikis
Technisch gesehen sind Wikis asynchrone, Web-basierte kollaborative Hypertext Autorensysteme oder kollektive Webseiten, in denen es vielen Benutzern gestattet ist, über ihren
Browser Seiten zu editieren bzw. hinzuzufügen [Ala05]. Realisiert sind diese – bis auf wenige Ausnahmen (z.B. VoodooPad 3 oder TiddlyWiki 4 ) – als Client-Server-Anwendungen
(2.1), d.h. auf der Client-Seite werden Anfragen, meist mit der Hilfe eines Browsers, an
den Server geschickt, diese werden auf dem Web-Server verarbeitet und anschließend wird
das Ergebnis an den Client zurückgeschickt.
Die Verarbeitung auf dem Web-Server unterscheidet sich dabei abhängig von der WikiEngine, die sich dort im Wesentlichen in ihrer Programmiersprache, der Implementierung
und der Art und Weise ihrer Datenorganisation manifestieren. Diese Unterschiede machen sich dann letztendlich auf der Client-Seite bei der Performance, Usability und den
angebotenen Features und somit generell bei der Benutzung der Wiki bemerkbar. Deshalb ist die Wahl der richtigen Engine für den Erfolg eines Projekts – abgesehen von den
3
4
http://flyingmeat.com/voodoopad/ (implementiert als Desktop-Anwendung)
http://www.tiddlywiki.com/ (die Inhalte werden direkt per JavaScript in den HTML-Dateien spei-
chert)
10
2.2 Wikis
Bild 2.1: Architektur von Wikis-Systems [Fou08b]
allgemeinen Eigenschaften einer Wiki (2.1) – von entscheidender Wichtigkeit, weshalb im
Kapitel 2.2.2 noch einmal genauer auf die jeweiligen Engines eingegangen wird.
2.2.1
Eigenschaften und Funktionalitäten
Eine Wiki ist, auf der funktionalen Ebene betrachtet, somit zunächst ein einfacher Hy”
pertexteditor“, welchet sich von einem Textverarbeitungsprogramm im Zusammenhang
mit ausschließlich linearen Texten in folgenden Punkten unterscheidet:
• die Mittel der Textverarbeitung und des Einsatzes von Medien sind deutlich reduziert
• einzelne Seiten können nicht nur linear, sondern beliebig durch Setzen von Links
miteinander verknüpft werden
• und jede Seite kann kooperativ und kollaborativ bearbeitet werden
Diese grundsätzlichen Eigenschaften und Funktionen werden durch weitere optionale ergänzt, welche weit verbreitet sind, jedoch nicht notwendigerweise vorhanden sein
müssen:
• Die Verfügbarkeit einer Wiki oder die Integration in einem Netzwerk muss nicht
zwangsläufig mit dem Internet in Verbindung gebracht werden. Somit sind Einsätze
sowohl in einem Wide Area Network (WAN), Local Area Network (LAN) oder gar
lokal auf einem einzelnen Rechner möglich, bis hin zur reinen Desktopanwendung.
• Benutzerverwaltung, Versions- und Kollisionsbehandlung5 unterstützen zwar die kooperativen Arbeit, sind aber nicht notwendig.
5
Algorithmen zur Lösung auftretender Probleme bei der gleichzeitigen Bearbeitung von einer Text-
passage durch mehrere Benutzer
2 Grundlagen
11
• Funktionen wie eine benutzerspezifische Zugriffskontrolle auf Seiten oder auf Teilbereiche der Wiki oder wie das Verwalten, Einbinden und Anbieten von externen
Dokumenten (Grafiken, Text-, Audio-Dateien etc.) im Rahmen von Content Management (CM) sind ebenfalls optional und variieren abhängig von der zugrunde
liegenden Engine (2.2.2)
Diese Vielfalt an Funktionalitäten im Umgang mit Inhalten und insbesondere die
Fähigkeit von Wikis im Zusammenhang mit der kooperativen bzw. kollaborativen Bearbeitung und Erschaffung von Inhalten und das damit verbundene Management um
Redundanz und Inkonsistenz zu unterbinden, bringen Wikis schnell in den Kontext eines
Content Management Systems (CMS). Dies ist so auch sicherlich richtig, jedoch unterscheiden sie sich in einigen Punkten doch wesentlich. Während ein CMS eher auf der
Einschränkung von Zugriffsrechten der Nutzer ausgelegt ist, hat eine Wiki eher den Anspruch, diesbezüglich Freiheiten zu bieten. Hinzu kommt, dass die Inhalte in einem CMS
eher Hierarchien entsprechen und weniger der netzartigen Struktur von Wikis. Darüber
hinaus werden viele optionale Funktionen einer Wiki in einem CMS als notwendig angesehen.
Nach dieser allgemeinen Funktionsbeschreibung möchte ich in den folgenden beiden
Kapiteln auf die spezielleren Funktionen eingehen, welche in seitenspezifische und übergreifende unterteilt und beschrieben werden und anschließend im Abschnitt User
”
Interface“ (2.2.1.3) einer konzeptuellen Wiki zusammengefasst werden.
2.2.1.1
Seitenbezogen
An jede Seite gebunden und somit seitenspezifisch gibt es weitere Elemente einer Wiki,
die verschiede Funktionen im Bezug auf die Seite ermöglichen. Diese Funktionen sind:
• aktivieren bzw. deaktivieren des Editiermodus
• anzeigen der vergangenen Versionen einer Seite und das damit verbundene Wiederherstellen
• zusätzliche Seiten im direkten Bezug, wie Diskussions- und Statistikseiten
• Auflistungen von vorkommenden Medien, Untergliederungen, Kategorisierungen
oder eingehende und ausgehende Links
• hinzufügen bzw. entfernen von Lesezeichen bzw. Möglichkeiten zur Abonnierung
12
2.2 Wikis
von entsprechenden Feeds6
• erstellen einer Druckversion der jeweiligen Seite
• Verlinkungen auf andere Sprachversionen der gewählten Seite
Dabei ist zu beachten, dass wiederum nur der erste Punkt eine notwendige Bedingung
für die Einstufung einer Wiki ist und die darauf folgenden lediglich enginespezifische
Zusatzfunktionen, die aber durchaus gängig sind.
Bezogen auf die elementarste Funktion in einer Wiki, dem Editieren, folgt eine weitere
Auflistung bezüglich dessen grundsätzlichen Funktionen und Eigenschaften:
• Die Editoren unterstützen überwiegend kein What You See Is What You Get (WY”
SIWYG)“, d.h. der Text wird über eine spezielle und einfache Wiki-Syntax (WikiMarkup) modifiziert, welche sowohl das Layout und die Struktur der Seite, als auch
die Verlinkung untereinander und das Einbinden von Medien betrifft. Diese Syntax
sind wiederum von der zugrunde liegenden Wiki-Engine abhängig, wobei es diesbezüglich Bestrebungen gibt, diese zu Standardisieren (3.2.1)
• Somit beschränkt sich das Layout und die Struktur einer Seite meist auf die
grundsätzlichsten Elemente der Textbearbeitung, was auch durchaus Sinn macht,
um die unterschiedlichen Designvorstellungen verschiedenster Autoren in der Wiki
zumindest ansatzweise beschränken zu können und somit der Wiki zu einem einheitlicheren Look & Feel7 zu verhelfen. Die wichtigsten Elemente sind dabei:
Formatierungen: Text kann fett, kursiv, unterstrichen dargestellt werden. Seltener ist hoch-/tiefgestellt, durchgestrichen oder weitere Textdekorationen wie
z.B Kapitälchen. Im seltensten Fall kann man explizit die Schriftgröße und
-art anpassen.
Ausrichtung: Absätze können links-, rechtsbündig bzw. zentriert ausgerichtet
(Flatter-/Mittelachsensatz) werden. Seltener als Blocksatz oder weiteren Satzformen der Typographie, wie z.B. dem Rauhsatz8 .
Gliederung: Bei der Gliederung geht es um die Unterteilung einer Seite in
eine hierarchische Anordnung von Teilabschnitten, was zum einen der
6
kurze Benachrichtigungen über Aktivitäten in der Wiki per Really Simple Syndication (RSS 2.0)
oder Atom Syndication Format (Atom)
7
Beschreibt ein einheitliches Gefühl“ bzw. Aussehen“, was einem gewissen Grad an Wiedererkennung
”
”
entspricht
8
eine Variante des Flattersatzes mit einer beschränkten Flatterzone
2 Grundlagen
13
Übersichtlichkeit und zum anderen der Kollisionsprävention dient, da somit verschiedene Seitenteile von unterschiedlichen Autoren bearbeitet werden
können, ohne sich zu beeinflussen.
Strukturierung: Um Text auch innerhalb der Gliederung strukturieren zu können,
gibt es meist die Möglichkeit der Auflistung oder Aufzählung auf unterschiedlichen Ebenen oder der Anordnung von Text und Daten in Form einer Tabelle.
Entscheidend ist hierbei, dass sowohl beim Layout als auch bei der Strukturierung
im Sinne der kooperativen Bearbeitung von Texten von beiden bis zu einem gewissen
Grad abstrahiert wird, damit die Autoren – in ihrer Individualität - nicht ständig
ihr Tun im Kontext der Allgemeinheit überprüfen müssen. So kann man z.B in einer
Aufzählung, mit der entsprechenden Syntax, lediglich durch einen ∗“ gefolgt von
”
dem neuen Listenpunkt“, ein weiteres Element an jeder belieben Stelle hinzufügen,
”
wobei das Einfügen der korrekten Ordinalzahlen dann die Wiki übernimmt.
2.2.1.2
Seitenübergreifend
Zusätzlich zu den eben genannten seitenspezifischen Funktionalitäten bieten die verschieden Wikis auch Funktionen an, die sich auf die gesamte Wiki beziehen, also seitenübergreifend einzuordnen sind:
Links: Diese Elemente zählen im Rahmen einer Bearbeitung von Hypertexten [G] sicherlich zu den wichtigsten seitenübergreifenden Funktionen. Hier unterscheidet man in
Wikis prinzipiell zwischen externen und internen Links, wobei die internen Links
noch mal in eingehende und ausgehende unterteilt werden. Interne Links sind Verlinkungen auf Seiten/Seitenabschnitte der selben Wiki und erfahren ebenfalls durch
die Referenzierung nur auf Basis von Seitentiteln eine gewisse Abstraktion. Dies
ermöglicht es dann auch, den Leser des Textes anhand von unterschiedlichen Formatierungen, darauf hinzuweisen, ob sich hinter dem Link bereits eine Seite verbirgt
oder ob der Link lediglich auf eine noch leere Seite verweist. Externe Links entsprechen – bis auf syntaktische Feinheiten – den normalen HTML-Links.
Kategorien: Um innhalb der Wiki nicht nur eine Netzstruktur aufbauen zu können, hat
man die Möglichkeit, einzelne Seiten beliebigen Kategorien unterzuordnen. Auch
hier findet sich der Grundsatz: Konstruktion statt Instruktion“ und das inkremen”
telle Wachstum einer Wiki wieder, da die Kategorien von jeder Seite und von jedem
Autor zu jeder Zeit erstellt werden können und die Zuordnung der Seiten dann automatisch geschieht, wo die Autoren mehr oder weniger zufällig die selben Kategorien
benannt haben.
14
2.2 Wikis
Namensräume: Da die Verlinkung der Seiten anhand der Titel erfolgt, müssen diese
somit eindeutig sein. Da Titel aber auch durch die Autoren frei vergeben werden,
passiert es schnell, dass Seiten, Seiteninhalte und Seitentitel aufgrund von Doppelbenennung kollidieren. Um dies zu vermeiden, können Seiten in unterschiedliche und
beliebig erweiterbare Namensräume eingeordnet werden, wodurch z.B die Seite Al”
bert Einstein“ sowohl im Namensraum der Bilder, als auch im Hauptnamensraum
oder dem der Autoren liegen kann.
Die Verwendung von Medien (Bilder, Audio, Video) aber auch sonstiger Dokumente
(PDFs, Word-Dokumente etc.) setzten – über ein spezielles Formular in der Wiki –
einen Upload vorraus, welcher die Datei anhand der Datenorganisation der jeweiligen Engine auf dem Server ablegt, auf welche dann, ähnlich wie ein Link, auf eine
normale“ Wikiseite referenziert werden kann. Je nach dem, welche Formate die Wi”
ki dann wie unterstützt, werden diese direkt in der Seite gerendert, zum Download
angeboten oder in externen Anwendungen geöffnet.
Spezialseiten: Diese Seiten entsprechen einer Sammlung von Meta-Seiten, welche im
Wesentlichen administrative Zwecke erfüllen bzw. allgemeine Funktionen zur Benutzung der Wiki bereitstellen sollen. So entspricht z.B. die Suchfunktion, Uploadfunktion oder das Anmeldeformular der Benutzer jeweils einer Spezialseite, oder
aber auch eine einfache Auflistung von z.B. aller Seiten, Benutzer oder Bilder dieser Wiki. Um auch hier Kollisionen zu vermeiden und eine klare Abgrenzung zu
normalen Seiten in der Wiki vorzunehmen, befinden sich diese ebenfalls in einem
gesonderten Namensraum.
2.2.1.3
User Interface
Grundsätzlich besteht somit das User Interface (UI) und die damit verbunden Funktionen
einer Wiki aus den folgenden Elementen, die unterschiedlich prominent angeordnet, jedoch
prinzipiell den Eigenschaften einer Wiki entsprechen:
Seiteninhalt: Dieser entspricht dem größten Anzeigebereich im Browser-Fenster, da sich
hier der eigentliche Inhalt (Text, Medien etc.) befindet bzw. der Editor“ (2.2.1.1,
”
wenn dieser aktiviert ist, mit dem man den Inhalt manipulieren kann. Angezeigt wird
immer genau eine Seite (Ausnahme: TiddlyWiki siehe 2.2.2 ), welche mindestens aus
einem Titel besteht. Der Titel hat die Funktion eines Schlüssels, womit jede Seite
eindeutig identifiziert werden kann. Der Inhalt ist somit optional, was es ermöglicht,
allein durch anlegen von Links auf den Seitentitel Seiten zu generieren und anderen
Benutzern der Wiki dadurch strukturelle Vorschläge zu unterbreiten, welche im
2 Grundlagen
15
Nachhinein gefüllt werden können. Analysen bezüglich des Inhalts einer Seite folgen
in dem Abschnitt 3.2.
Navigation: Die Navigation beinhaltet unter anderem wichtige Links (meist von Administratoren gesetzt) auf beliebige Seiten innerhalb oder ausserhalb der Wiki. Das
wichtigste Element der Navigation in einer Wiki ist allerdings die Suchfunktion, da
sich die Navigation über Links, durch editieren anderer Benutzer, ständig ändern
und somit vermutete Pfade durch die Wiki unterbrochen sein können. Zusätzlich
können in dem Navigationsbereich weitere Feature der Wiki untergebracht werden,
die man den Benutzern seitenübergreifend zur Verfügung stellen möchte.
Benutzerbereich: Auch wenn Wikis prinzipiell ohne eine Benutzerverwaltung auskommen – was einige auch tun – und damit ein Maximum an Freiheit und Gleichberechtigung bieten, ist es doch oft von Nutzen, einige Funktionen und Zugriff benutzerspezifisch zu verteilen. Diese Funktionalität schlägt sich dann in einem Benutzerbereich
nieder. Dieser beinhaltet die Möglichkeiten, sich an- und abzumelden, persönliche
Einstellungen vorzunehmen oder Links zu individuellen Sammlungen von eigenen
Beiträgen, erstellten Lesezeichen oder erhaltenen Nachrichten anzubieten.
2.2.2
Wiki-Engines
Eine Wiki-Engines entspricht genau einer Implementierung des Konzept: Wiki“, basie”
rend auf der Idee der ersten Engine WikiWikiWeb“. Aufgrund dessen spricht man auch
”
oft von Wiki-Klonen (Wiki-Clones), da sie im allgemeinen eine Kopie der Funktionalitäten dieser Ur-Wiki sind. Im Speziellen allerdings unterscheiden diese sich erheblich.
Angefangen bei den weniger offensichtlichen Unterscheidungen, wie z.B der Wahl der
Programmiersprache oder die Organisation der Daten und Dateien bis hin zu den direkt
spürbaren Faktoren wie Performanz, UI und die angebotene Featurelist9 .
Mittlerweile gibt es laut mehreren Seiten10
11
, welche es sich zu Aufgabe gemacht haben,
die verschiedenen Engines aufzulisten und zu kategorisieren, um die 120. Auf diesen Seiten
kann jeder – ganz nach dem Wiki-Prinzip – selber seine programmierte Engine hinzufügen,
weshalb davon auszugehen ist, dass zumindest alle relevanten darin enthalten sind, es aber
wahrscheinlich noch mehr gibt. Ein Gegenbeispiel wäre die in Wiki-Systeme im eLear”
ning“ [Say06] untersuchte Ed.Wiki“ 12 , die in beiden nicht auftaucht. Allerdings scheint
”
9
Auflistung der markantesten Fähigkeiten
http://c2.com/cgi/wiki?WikiEngines Anzahl: 136; Stand: 2008
11
http://www.wikimatrix.org/ Anzahl: 102; Stand: 2008
12
http://www.edwiki.selbstlernarchitekturen.info/wiki.php
10
16
2.2 Wikis
diese Zahl im Moment eher rückläufig zu sein, da laut der Gesellschaft für Informatik13
im Jahre 2005 noch rund 200 waren mit der Referenz auf die selben Quellen.
Die überwiegende Anzahl der Wiki-Engines ist freie Software, d.h. ihr Quellcode wird
veröffentlicht (Open-Source) und unterliegt meist Lizenzen für Freie Software wie z.B. der
GNU General Public License (GPL). Dies und die Tatsache, das die meisten Wikis sehr
modular programmiert sind und teilweise mit einer eigenen Application Programming
Interface (API) bzw. einem Plugin-System versehen sind, entstehen immer wieder neue
Projekte, bei denen Wikis angepasst bzw. weiterentwickelt und somit ständig den sich
schnell ändernden Bedingungen im Netz angepasst werden können. Beispiele für kommerzielle Wikis sind unter anderem (hier die drei bekanntesten laut einer Untersuchung
von WikiCreole14 (Stand: 2006) basierend auf dem Maximalwert von erreichten GoogleResultaten):
Confluence15 , welche im unternehmerischen Sektor mit 4.580.000 Resultaten bei ensprechenden Google-Anfragen die bekannteste ist. Entwickelt von der Firma Atlassian
Software Systems in der Programmiersprache Java, bietet sie Features speziell für
den Einsatz in Unternehmen. Die markantesten sind: Rich Text WYSIWYG-Editor
und damit einhergehender Word-Export/Import, Vergabe von Tags16 und Einordnung in Hierarchien einzelner Seiten, Workspaces zum gezielten Einsatz mehrerer
Wikis, eine Vielzahl von Plugins (wie z.B. Kalender, Diagramme, Galerien), detaillierten Mögichkeiten zur Zugriffsbeschränkung, eine Java API und ein SOAP [G] /
XML-RPC [G] Interface zur Integration in bestehende Anwendungen.
JotSpot17 bzw. seit 2006 Google Sites liegt mit 2.300.000 Google-Treffer auf Platz 2.
Durch die Übernahme von Google liegt nun der Fokus eher auf das kollaborative
Veröffentlichen von Websites“ (Google selber verwendet auch den Begriff Wiki“
”
”
nicht mehr). Somit zählen zu den wichtigsten äusserlichen Funktionen: vorgefertigte Templates, umfangreiche Upload- und Anhang-Funktionen, Integration von
Multimedia-Inhalten und eine nahtlose Integration von Inhalten anderer GoogleAnwendungen (Präsentationen, Slide-Shows, Kalender etc.). Intern zeichnet sich
JotSpot insbesondere dadurch aus, innerhalb von Seiten mit einer eigens entwickelten Script-Sprache (JotScript) kleine Anwendungen integrieren zu können. Die Programmiersprache ist Java.
PBwiki18 auf Platz 3 mit 1.920.000 Google-Treffern, liegt somit nur knapp hinter JotSpot, bleibt aber bei den typischen Charakteristika einer Wiki. Eine direkte Kon13
http://www.gi-ev.de/service/informatiklexikon/informatiklexikon-detailansicht/meldung/96/
http://wikicreole.org/wiki/WikiPopularity
16
eine dynamischere Variante von Kategorien
14
2 Grundlagen
17
kurrenz ist sie aber insofern, da ein wichtiges Vertriebsmodel von PBwiki, Inc das
Hosting ihrer Wikis darstellt, ähnlich wie es nun auch bei Google Sites der Fall
ist. PBwiki bietet Wikis für Unternehmen und für die Lehre mit ebenfalls extra
zugeschnitten Features. Tags und Zugriffsbeschränkungen, schlichtes User Interface,
Ordner zur Dateiablage, Seitenfreigaben per E-Mail-Versand, Änderungsanzeige und
Kommentarfunktionen.
Dabei ist zu beachten, das Platz 6 (SeedWiki ) bereits um den Faktor 10 weniger häufig im
Netz zu finden ist und somit sich die meisten Wiki-Installationen ein paar wenige Engines
teilen. Bei den freien Engines ist die Verteilung noch extremer. Ebenfalls im Bezug auf
die im Februar 2007 gemachten Untersuchungen des WikiCreole-Projekts hebt sich der
1. Platz (MediaWiki ) um den Faktor 100 breits von dem 2. Platz (TiddlyWiki ) ab. Diese
beiden und weitere relevante Engines sind:
MediaWiki als Platz 1 in der Untersuchung mit 133.000.000 Treffern, verdankt ihre
enorme Popularität nicht zuletzt ihrem konkreten Entwicklungsziel einer freien und
von jederman erweiterbaren Enzyklopädie, die Wikipedia. Die MediaWiki-Engine
unterliegt der GPL, ist somit quelloffen und kann im Rahmen dessen kopiert und
weiterentwickelt werden. Programmiert ist diese in Skriptsprache PHP und greift
bei der Speicherung der Daten auf eine MySQL-Datenbank zurück. Das Editieren
der Seiten ist dabei stark an die ursprüngliche WikiWikiWeb Syntax angelehnt. Des
weiteren werden Namensräume, Kategorien und Plugins unterstützt und das Layout
wurde komplett in Skins ausgelagert. Zudem ist sie in sehr vielen Sprachen verfügbar
und besitzt eine weitreichende Dokumentation, inklusive einer dort spezifizierten
API, welche die meisten ihrer Funktionen externen Anwendungen und sich selbst
zur Verfügung stellt.
Weitere populäre Nutzungen dieser Engine sind unter der Wikimedia Foundation19
zusammengefasst bzw. initiiert worden. Jedes dieser Projekte ist multilingual und
jeder kann seinen Teil dazu beitragen. Diese sind (neben der Wikipedia):
• Wikibooks wurde 2003 ins Leben gerufen umfasste im Januar 2008 insgesamt
fast 5.000 frei verfügbaren Bücher. Diese Bücher wurden sowohl von Studenten
als auch von Lehrenden zum Einsatz für die Lehre in der Wiki verfasst.
• Wikinews dient der Sammlung und Aufbereitung von Nachrichten. Start des
Projekts: Ende 2004
19
http://wikimediafoundation.org/
18
2.2 Wikis
• Wikiversity bietet eine Anlaufstelle für verschiedene Lerngruppen um Lerninhalt produzieren und verwalten zu können. Ganz im Sinne von learning by
”
doing“.
• Wikisource sammelt seit 2003 Texte (klassische Bücher, Gesetze etc.), die
keinen Lizenzen unterliegen und somit frei verwendbar sind und somit öffentlich
zugänglich sind. Des Weiteren liegt ein Fokus auf die Übersetzung der Texte.
2008 waren davon insgesamt 315.000 in mehreren Sprachen verfügbar.
• Wikispecies umfasst eine fast 120.000 Seiten starke Sammlung, Einordnung
und Kategorisierung von jeglichem Leben auf der Erde, wie z.B Tiere, Pflanzen,
Bakterien etc.
• Wikiquote ist ebenfalls eine mehrsprachige Sammlung von Zitaten berühmter
Persönlichkeiten aus Filmen, Bücher oder anderen Quellen. Initiiert wurde diese
2003 und beinhaltet nun fast 80.000 Seiten in ca. 50 verschiedenen Sprachen.
• Wiktionary ist ein Projekt zur Erstellung eines freien Wörterbuches. Gestartet im Dezember 2002 umfasste es im Januar 2008 über 100 Sprachen mit
insgesamt 3.000.000 Einträgen.
• Commons dient zur Sammlung von sämtlichen Medien (Bilder, Videos, Texte
etc.), welche in die anderen Projekten eingebunden werden können, um, wie
bei einer dezentralen Lösung, Redundanz zu vermeiden.
Mediawiki gilt aufgrund des häufigen Einsatzes und der großen Nutzerzahlen als
äusserst zuverlässiges und schnelles System.
TiddlyWiki ist unter den Wiki-Engines eher ein Exot. Denn wie bereits vorab beschrieben, steckt dahinter kein aufwendiges Client-Server-System, sondern lediglich eine
einzige, 280 KB große HTML-Datei, deren Logik mithilfe von Javascript und dem
Document Object Model (DOM) implementiert wurde. Die Anzeige ist somit nicht
seitenbasiert wie in anderen Wikis, sondern man befindet sich immer auf einer Seite
und die eigentlichen Artikel werden in entsprechenden HTML-divs angezeigt, genannt Tiddler“ (Knirpse). Somit hat man sehr schnell eine einsetzbare Wiki, die
”
man sogar per E-Mail verschicken kann. Bei komplexeren Anforderungen, machen
sich jedoch schnell das fehlende Versionmanagement, die fehlende Benutzerverwaltung und die Tatsache bemerkbar, dass beim Einsatz im Internet immer die gesamte
Wiki zum Client geschickt wird, auch wenn dort nur eine Seite“ bearbeitet wurde.
”
Umso beachtlicher ist der Platz 2 mit 1.420.000 Zugriffen und verweist aber auf den
entsprechenden Bedarf.
2 Grundlagen
19
MoinMoin ist eine in Python programmierte Engine und mit 1.180.000 Google-Treffern
und auf Platz 4 eine der ebenfalls bekannteren Wikis. Dies liegt nicht zuletzt an
der sehr beliebten Skriptsprache, welche zahlreiche Communities um sich schart.
Der Name MoinMoin“ ist an den norddeutschen Gruß Moin“ und der bei Wi”
”
kis üblichen Dopplung (WikiWiki) angeleht. Zu den Features gehören Spamfilter,
Verwendung von CamelCase, Skin-Unterstützung und ein WYSIWYG-Editor. Des
Weiteren existieren zahlreiche Erweiterungen und Plugins.
TWiki auf Platz 7 mit 1.120.000 Treffern sieht sich eher im Einsatz von Unternehmen.
Das Hauptfeature ist dabei, die Möglichkeit einer einfachen Programmierung von
Anwendungen in TWiki-Seiten. Diesen können dann, basierend auf dem Seiteninhalt, Variablen und Formulare erzeugen und verarbeiten. Programmiert ist TWiki
in Perl, einer freien, plattformunabhängigen Skriptsprache. Zusätzlich gibt es ein
große Anzahl an Plugins und Addons. Skin, Namensräume (genannt Webs) und eine erweiterte Versions- und Zugangskontrolle zählen genauso zu den Features wie
der WYSIWYG-Editor.
UniWakka20 wurde speziell für den wissenschaftlichen Einsatz im universitären Umfeld
von Andrea Rossato entwickelt. Zu den Besonderheiten zählen, dass mehrere Wikis
als eine Wiki-Farm verwendet werden können, es eine Unterstützung zum Referenzieren gibt und zahlreiche Im-/Export-Module zur Verfügung stehen, wie z.B.
BibTEX, LATEX oder Open Office21 .
Ed.wiki22 ist, wie in [Say06] ausführlich beschrieben, eine spezielle Implementierung im
Umfeld der Lehre ( Ed“ steht dabei für Education“). Diesbezügliche Features sind
”
”
ein schlichtes und anpassbares UI, eine flexiblere Rechteverwaltung, mögliche Publikationen einzelner Seiten (ohne ersichtlicher Wiki-Herkunft), hinzufügen von Kommentaren und der Einsatz eines WYSIWYG-Editors.
Für meine Analysen und das Prototyping werde ich mich aufgrund der klaren Dominanz
hauptsächlich auf die MediaWiki -Engine spezialisieren, allerdings unter der Beachtung
von zwei weiteren, die da wären MoinMoin und TWiki. Durch ihre unterschiedlichen
Programmiersprachen, die unterschiedliche Art und Weisen der Organisation der Daten
und der leicht abweichenden Wiki-Syntax, sind diese drei gut geeignet, um ein möglichst
breites Spektrum von unterschiedlichen Wiki-Implementationen abzudecken.
21
http://de.openoffice.org/
20
2.2 Wikis
2.2.3
Einsatzszenarien
Wie schon in 2.2 erwähnt, sind Wikis prinzipiell im Bereich von Content Management
Systemen (Content Management System (CMS)) bzw. der Unterkategorie Web Content
Management System (WCMS) anzusiedeln, da die Anwendungen, die sie bedienen, ausschließlich im Netz liegen. Auch wenn sie sich ideologisch teilweise grundsätzlich von einander unterscheiden, spricht dennoch prinzipiell nichts dagegen, Wikis auch in dem Sinne
einzusetzen, d.h. den Zugriff auf Inhalte und dessen Strukturierungen eher zu beschränken
und somit Systeme zu realisieren mit der klassischen Aufteilung von produzierenden und
konsumierenden Nutzern. Diese Art der restriktiven Nutzung und die eher freiere Verwendung von Wikis ermöglichen folgende Einsatzszenarien [Ala05]:
• Software-Dokumentation und Entwicklung
• Organisationen, Koordination im Projekt-Management
• Realisierung eines Katalogs von Frequently Asked Questions (FAQ)
• Enzyklopädien oder generell als Wissensdatenbanken
• schreiben und publizieren von Büchern
• Firmenintern im Bezug auf Wissensmanagement
Im Bereich des eLearings sind Wikis unter Computer Supported Cooperative / Collaborative Learning (CSCL) einzuordnen, wo Ansätze des eLearnings beschrieben werden, welche
mit Hilfe von computerunterstützten Informations- und Kommunikationstechnologien kooperatives Lernen, d.h. Lernen in Gruppen, ermöglichen. Dies macht sie grundsätzlich
zu Learning Management System (LMS) wiederum einer Unterkategorie von CMS. Die
Unterstützung als Kommunikations- und Kooperationsplattform lässt Wikis des weiteren
häufig im Kontext von Blended Learning23 [Cub07] auftauchen, wo es um eine Kombination von verschiedenen Lernmethoden geht, aufgeteilt in eine Online- und Präsenzphase.
Somit ergeben sich, wie auch in dem Artikel Wikis im eLearning“ [Bre06b] festgehalten,
”
folgende Szenarien beim Einsatz von Wikis im Kontext der Lehre:
• zur technischen Unterstützung für kollaborative Textproduktion für das Verfassen
von Referaten und Seminarabeiten (Beispiel 2 in 3.1.3.2)
• im Einsatz zur Projektkoordination, -dokumention und Ideensammlung (Beispiel 1
in 3.1.3.1)
23
integriertes Lernen
2 Grundlagen
21
• Informelle Informations- und Kommunikationsplattform (Beispiel 3 in 3.1.3.3)
Ergänzt mit meinen vorangegangen und generellen Ausführungen im Zusammenhang mit
Wikis, ergeben sich folgende mögliche Erwartungen, die bei der Planung zum Einsatz von
Wikis motivieren könnten:
• Einfach“ im Bezug auf gemeinsames Erarbeiten von Inhalten im Netz und einer
”
gewissen Abstraktion, was das Layout oder visuelle Stile betrifft
• Frei“, da es prinzipiell keine räumliche, zeitliche oder Nutzungsbeschränkung gibt
”
und somit jeder zum Autor werden kann
• Schnell“ bei Organisation, beim Finden und Bearbeiten von Inhalten
”
• Sozial“, da Wikis der menschlichen Kommunikation und Zusammenarbeit dienen
”
• Konstruktiv“ als ein Prozess der Selbstorganisation von Wissen und dem inkre”
mentellen Wachstum
Diese aufgeführten Einsatzszenarien im eLearning und die Zusammenfassung der Erwartungen beim Einsatz von Wikis werden in dem Abschnitt Autorenprozesse“ im Kapitel
”
3.1 anhand von Beispielen analysiert und mit der Realität abgeglichen.
2.3
eLearning
Wikis nehmen im gesamten Themenkomplex eLearning“ nur einen kleinen Teil des eLear”
nings ein. Als WCMS gehören sie einer weiteren Untergruppe dem Web Based Training
(WBT) an, was einer grundsätzlichen Weiterentwicklung von Computer Based Training
(CBT) entspricht, da Lerneinheiten/-methoden nicht länger über Datenträger distribuiert
werden, sondern über das Netz.
Prinzipiell wird unter eLearning jede Art der Lehre verstanden, bei der
digitale Medien zum Einsatz kommen. Sei es zur Präsentation, Produktion und
Distribution von Lehrmaterialien oder zur Unterstützung zwischenmenschlicher Kommunikation [Ker01].
Während es allerdings zu den Anfängen des eLearnings in den 90er Jahren – wie die
Abkürzung CBT schon vermuten lässt – noch hauptsächlich um den Einsatz von Computern selbst ging, d.h. um das Erlernen des Umgangs mit diesem neuen Medium, geht
22
2.3 eLearning
es heutzutage immer mehr um die Inhalte. Dies liegt zum einen an der ständig zunehmenden Verbreitung und dem damit einhergehenden Selbstverständnis bei der Nutzung
von Computern und zum anderen an dem technischen Fortschritt. Dieser Fortschritt hat
in den vergangen Jahren dazu geführt, dass die Inhalte und dessen Repräsentationen immer mehr von der zugrunde liegenden Implementation abstrahiert wurden. Wo anfangs
eine in sich geschlossene Lehrmaschine“, also Hardware mit genau darauf abgestimm”
ter Software und einem vorbestimmten Zweck verkauft wurde, gibt es nun Wikis, die für
jeden zugänglich und frei verfügbar im Netz erst ihren Zweck durch ihren konkreten Einsatz erhalten. Diese Punkte führen insgesamt zu einem gesteigerten Konkurrenzkampf,
insbesondere auch im Bezug auf kommerzielle Software und lassen Methoden wie Evaluation und Qualitätssicherung, die Frage nach Preis bzw. Aufwand und Leistung und die
umgesetzten Autorenprozesse und ihre Umgebung (3.1) immer wichtiger werden [Bre06a].
Hinzu kommt der immer relevanter werdende Wunsch nach der Wiederverwendbarkeit von
bereits eingesetzten Inhalten um Kosten und Aufwand zu minimieren und einmal produzierte eLearning-Kurse auch softwareübergreifend wieder einsetzen zu können. Ebenfalls
nach einer vorausgehenden Phase der Qualitätssicherung und Evaluation.
Beides nimmt somit einen immer prominenteren Platz bei der Umsetzung, Planung und
Konzeption eines eLearning-Projekts einund sind neben dem eigentlichen eLearning –
Lehre unter dem Einsatzes von digitalen Medien – eine wichtige Komponente bei der
Entwicklung von eLearning-Anwendungen bzw. Autorenumgebungen.
2.3.1
eLearning-Software
Unter der vorangegangen Definition des Begriffs eLearning“ fällt eine diesbezügliche
”
Zuordnung von Anwendungen dementsprechend üppig aus, weshalb ich an dieser Stelle die
Kategorie eLearning-Software“ auf die für diese Arbeit relevanten klären und fokussieren
”
möchte.
Technisch gesehen beginnt eLearning-Software somit da, wo digitale Medien zur Unterstützung der Lehrer eingesetzt werden, was im einfachsten Fall z.B. das Abspielen
eines Schulungsfilms, eine Diashow oder die Übertragung einer klassischen“, jedoch
”
räumlich geteilten Unterrichtsmethode, dem Tele-Teaching, sein kann. Einfach insofern,
da in diesem Fall keinerlei Interaktion oder komplexere Formen der Methodik oder der
Präsentation (ausserhalb des Videos oder der Übertragung) zum Tragen kommen und
sich die Lehre somit auf eine einseitige Kommunikation beschränkt [Tri08]. Die nächste
Kategorie setzt genau da an und bietet den Lernenden, allerdings anhand eines vorher
festgelegten Ablaufplans, zudem die Möglichkeit, in die Lerneinheit einzugreifen und somit z.B. gezielt bekannte Teile überspringen zu können bzw. kritische zu wiederholen.
2 Grundlagen
23
Als einfaches Beispiel für diese kognitiven Anwendungen sei eine Animation eines schlagenden Herzens
24
der medizinischen Fakultät der Universität Utah genannt. Auch wenn
die Anwendungen dieser Kategorie – klassischerweise – zu den CBTs gezählt werden
können, finden sich gerade diese immer häufiger in Netzwerken integriert wieder, was sie
zwangsläufig unter den Begriff WBTs fallen lässt und meiner 3. Kategorie von eLearningSoftware entspricht. Die Vorteile der Distribution über ein Netzwerk (insbesondere über
das Internet) sind im Einzelnen:
1. Die Inhalte sind prinzipiell von überall zu erreichen und können aber auch relativ
einfach und zentral im Zugriff beschränkt werden (Benutzerverwaltung).
2. Die Inhalte setzten in der Regel lediglich einen gängigen Browser voraus, was
sie von einer bestimmten Anwendung unabhängig werden lässt und somit plattformübergreifend zur Verfügung stehen.
3. Die Inhalte sind zentral hinterlegt, was zum einen die Pflege (Updates etc.) und Verwaltung erleichtert und zum anderen eine zentrale Erhebung von Daten ermöglicht,
z.B. zur Auswertung von interaktiven Fragemodulen.
4. Durch die Basis eines Netzwerks können die eigentlichen eLearning-Inhalte durch
zusätzliche Angebote auf einer kommunikativen Ebene zwischen z.B den Lernenden, den Lehrenden oder den Autoren, angeboten und genutzt werden. Oder auch
Angebote auf einer organisatorischen Ebene sind denkbar, um Inhalt zu bestimmten Zeiten anbieten zu können oder in Abhängigkeit von Präsenzveranstaltungen.
Dies würde dann aber schon dem Funktionsumfang einer Lernplattform bzw. einer
Lernumgebung entsprechen und kann somit getrennt betrachtet werden.
Betrachtet man diese Punkte im Bezug auf diese Arbeit und einer Fokussierung von
eLearning-Software, zeigt sich, dass insbesondere diese Kategorie 3 der Web-basierten
eLearning-Anwendungen für die Verwendung von Inhalten aus Wikis geeignet sind. Dies
liegt zum einen natürlich am 2. Punkt, da somit die technische Ebene der Inhalte prinzipiell auch dem von Wikis entspricht und zum anderen entspricht eine schnelle, offene und
einfach zu aktualisierende Distribution der Inhalte (Punkt 1 und 2) einfach wesentlich
mehr den Eigenschaften von Wikis. Punkt 4 kann zwar auch durch Informationen, die
aus einer Wiki extrahiert wurden, unterstützend beeinflusst werden, allerdings sind
diese eher zweitrangig, da es primär um die Wiederverwendung und Aufbereitung von
Wiki-Inhalten an sich geht. Somit ergibt sich für mich die entsprechende Definition von
eLearning-Software bezüglich der Nutzung von Wiki-Inhalten:
24
http://library.med.utah.edu/kw/pharm/hyper heart1.html
24
2.3 eLearning
Im Kontext dieser Arbeit sind eLearning-Anwendungen Programme
zur Unterstützung oder Ermöglichung der Lehre (eLearning). Die vorzugsweise auf Internettechnologien basierenden Kursinhalte (HTML/XHTML, XML,
Flash etc.), entsprechen einer linearen, hierarchischen oder netzartigen Navigation durch Kursseiten, welche wiederum in kleinere Abschnitte unterteilt
sein können. Hierbei können sowohl die Navigation als auch die Seiten an sich
Möglichkeiten zur Interaktion bieten bzw. eher statisch hinterlegt sein.
Eine allgemeine Analyse von entsprechenden eLearning-Kursen und deren Inhalte wird
im Abschnitt 3.3 aufgegriffen und anhand eines Beispiels einer Software dieser Kategorie,
der LernBar, in den Abschnitten 2.3.1.1, 3.1.2.1 konkretisiert.
2.3.1.1
Beispiel: LernBar
Eine eLearning-Anwendung, welche der im vorherigen Abschnitt stehenden Definition
entspricht, ist die LernBar, entwickelt von der Professur für Graphischen Datenverarbeitung (GDV) der Johann Wolfgang Goethe-Universität Frankfurt am Main im Rahmen
des megadigitale-Projekts [meg08]. Das Handbuch der LernBar [meg07] beschreibt dabei
den Funktionsumfang sinngemäß wie folgt:
Die LernBar ist eine abgestimmte Autorenumgebung aus mehreren Komponenten. Sie beinhaltet im LernBar Release 2d Designrichtlinien, Designvorlagen (Templates), Werkzeuge zur Erzeugung und Strukturierung
von Kursinhalten und Kursen, ein Web-basiertes Portal zur zentralisierten
Präsentation und Veröffentlichung von Kursen, sowie eine Browser-basierte
Präsentationssoftware, über die existierende Kurse genutzt werden können.
Die Kursinhalte sind HTML-basiert und können als solche mit Hilfe der im
Web üblichen Erweiterungen (Adobe Flash, Java-Applets, 3D-, Audio- und
Videoinhalte etc.) angereichert werden. Zudem bietet LernBar Release 2d die
Möglichkeit, Inhalte um Fragen (Quiz, Selfassessment, Kontrollfragen) zu erweitern, Kurse flexibel zu konfigurieren, sowie diese online, offline und auf
Medien wie CD/DVD ROM verfügbar zu machen.
Die im zweiten Absatz aufgelisteten Komponenten bieten im einzelnen folgenden Funktionalitäten:
LernBar Player: Diese Komponente emöglicht es, wie in den Grundlagen beschriebenen (2.3.1), HTML-basierten Inhalte mit den üblichen Erweiterungen (z.B. Adobe
2 Grundlagen
25
Flash25 ), browser-basiert darzustellen (Bild 2.2). D.h. systemunabhängig (Mindestvoraussetzung ist ein gängiger Browser) startet er komplette LernBar-Kurse, zeigt
die Inhalte an, ermöglicht die (auf Pfaden basierende) Navigation zwischen einzelnen
Seiten, speichert server- und client-seitig Information zu besuchten Seiten, gesetzten
Bookmarks, Notizen und Daten zur Auswertung eingesetzter Fragetypen.
Bild 2.2: Komponenten der LernBar: Player
LernBar Studio: Diese Autoren-/Entwicklungsumgebung (2.3.2) ermöglicht es Autoren, ohne größere Kenntnisse über HTML/XML oder JavaScript, Inhalt und somit
LernBar-Kurse zu erzeugen und direkt (unter Verwendung der nächsten Komponente, dem Portal) zu veröffentlichen (Bild 2.3). Die Anwendung unterstützt sowohl bei
der Erzeugung von einzelnen Seiten mit einem großen Satz an vorgefertigten Templates und direktem Befüllen mit Text und Medien, als auch der Abbildung und
Umsetzung der gewünschten Navigations-Pfade. Des Weiteren werden allgemeine
Funktionalitäten zur Verfügung gestellt, wie z.B. das Einbinden eines Glossars, das
Erzeugen einer Kurs-Map, Angaben zum Copyright oder grundsätzlichen Einstellungen des Kurses, wie das Festlegen einer Startseite, von Startbedingungen oder
Zeit- und Nutzungsbeschränkungen.
25
http://www.adobe.com/de/products/flashplayer/
26
2.3 eLearning
Bild 2.3: Komponenten der LernBar: Studio
LernBar Portal: Obwohl die LernBar-Kurse auch auf klassischem Wege (2.3) distribuiert (z.B. über eine CD) und somit auch lokal auf einem beliebigen Rechner gestartet
werden können, bietet eine weitere Komponente, das LernBar-Portal, eine wesentlich komfortablere Möglichkeit (Bild 2.4). Als eine Sammlung von LernBar-Kursen
in einer dynamischen Ordnerstruktur“ erlaubt das Online-Portal den Autoren, ih”
re erstellten Kurse benutzerabhängig und mit zusätzlichen Funktionen in einem
Netzwerk (z.B. dem Internet) anzubieten. Zu diesen Funktionen gehören unter anderem das Anbieten einer Offline-Version des Kurses als Download, die Anzeige einer
PDF-Version oder entsprechend definierte Fragebögen zu benutzerspezifischen oder
anonymen Datenerhebung.
2.3.2
Autorenumgebungen
Durch die Entkoppelung der Lehrinhalte von der einzusetzenden Software (Abschnitt 2.3)
und deren ständig steigenden Möglichkeiten fallen immer mehr Aufgaben auf diejenigen
zurück, die im Sinne der Lehre handeln. Da dies dann aber eventuell nicht im Sinne
der Software und zusätzlich an entsprechenden technischen Fähigkeiten mangelt, wird
2 Grundlagen
27
Bild 2.4: Komponenten der LernBar: Portal
die Qualität von eLearing-Software zunehmend an der Qualität ihrer Autorenumgebung
gemessen, welche den Lehrenden im Umgang mit der Software und der Produktion von
Inhalten helfen soll.
Autorenumgebungen/-systeme oder auch Autorenwerkzeuge sind somit eine ergänzende Software, welche es den Lehrenden bzw. den Autoren erleichtern soll, Inhalte für entsprechende eLearning-Anwendungen
zu produzieren. Insbesondere im Bezug auf die Definition von eLearningAnwendungen (2.3.1) bedeutet dies die Erzeugung von – auf Internetttechnologien (HTML/XHTML, XML, Flash etc.) basierenden – Seiten, deren Anordnung und deren diesbezüglichen Navigation. Optional können Möglichkeiten
zur Interaktion beschrieben werden (Frageseiten etc.) oder fertig produzierte
Inhalte distributiert bzw. organisiert oder kommuniziert werden.
Prinzipiell lassen sich diese anhand von mehreren Metaphern bezüglich der Repräsentation
der Inhalt wie folgt kategorisieren [Die98]:
Stapel-Karten-Metapher entspricht einem Stapel von Karten, wobei jede Karte einer
einzelnen Bildschirmseite entspricht. Die Inhalte sind statisch angeordnet und somit
28
2.3 eLearning
sehr übersichtlich strukturiert, was bei den Autoren zu einer kurzen Einarbeitungszeit führt.
Buchseiten-Metapher ähnelt der vorherigen Metapher, jedoch werden hier die Inhalte
netzartig (nicht linear, wie man zunächst vermuten könnte) miteinander verbunden.
Zeitachsen-Metapher ähnelt in vielerlei Hinsicht der Produktion eines Filmes. D.h.
einzelne Bilder (Bildschirmseiten) werden auf einer Zeitachse platziert, um den Betrachtern eine feste Ablauffolge zu definieren. Realisiert werden somit dynamische,
interaktive Multimedia-Präsentationen. Ein Nachteil wäre, dass bei größeren Projekten schnell die Übersichlichkeit verloren geht.
Flußdiagramm-Metapher wird sehr häufig bei der Entwicklung von statischen, multimedialen CBT-Anwendungen eingesetzt. Die Interaktionen und somit Abzweigungen von linearen oder hierarchischen Pfaden im Programm, werden dabei anhand
von Pfaden in einem Flußdiagramm definiert und beschrieben.
Objekt-Metapher orientiert sich an der Objekt-Metapher aus der objektorientierten
Programmierung. Objekt bzw. ihre Eigenschaften werden dabei visuell repräsentiert
und graphisch-interaktiv manipuliert. Aufgrund des hohen Grads der Modularisierung, Wiederverwendbarkeit und Erweiterbarkeit eignet sich insbesondere diese Metaper für die Erstellung dynamischer Multimedia-Anwendungen.
Skript-Metapher ist dann, im Vergleich zur Objekt-Metapher, eher an der imperativen Programmierung angelehnt, um Aspekte, die sich nicht graphisch-interaktiv
modellieren lassen, umsetzen zu können. Hierbei ist jedoch der Nachteil, dass
grundsätzliche Programmiererfahrungen der Autoren vorausgesetzt werden müssen.
Betrachtet man diese Kategorien aus der Sicht von Wikis und ihren Inhalten, würde
die zwischen der Buchseiten- und Objekt-Metapher liegen. Allerdings werden bei keiner
Kategorie Aspekte der Flüchtigkeit von Inhalten bzw. deren konstruktiven Wachstum,
wie es beim Einsatz von Wikis-Systemen oder allgemeiner beim Einsatz von CSCL der
Fall ist, Sorge getragen. Dies ist Gegenstand dieser Arbeit und wird im Kapitel 3.1 weiter analysiert. Betrachtet man im Gegenzug dazu eine klassische Autorenumgebung, das
LernBar Studio aus dem vorangegangen Abschnitt (2.3.1.1), lässt sich diese ganz klar der
Flußdiagramm-Metapher zuordnen, was man sehr schön an der linearen bzw. hierarchischen Abbildung der Kursstruktur in den Abbildung 2.2 und 2.3 erkennen kann.
2 Grundlagen
2.4
29
Technologieüberblick
Da weitere zahlreiche technische und inhaltliche Grundlagen für diese Arbeit – wenn sie
nicht selbst Gegenstand der Untersuchungen sind – in anderen Quellen schon ausreichend
und gut beschrieben sind, werde ich an dieser Stelle lediglich einen Rahmen zur Übersicht
spannen. Um trotzdem – bei Bedarf – hinreichend auf die Grundlage eingehen zu können,
befindet sich am Ende dieser Arbeit ein Glossar (Anhang A), mit entsprechenden Kurzbeschreibungen, auf welche dann aus den jeweiligen Abschnitten und Thematiken mit
einem [G] verwiesen wird. Bei der Erstellung des Glossars wurden folgende Quellen zur
Recherche hinzugezogen: [Fou08b], [Vol03], [Mey08] und [Gmb08].
Technisch bewegt sich diese Arbeit zunächst – im weitesten Sinne - im Rahmen von
Netzwerk-/Internet-Technologien und den jeweiligen Netzstandards, wobei mein Ansatz
in den anwendungsorientierten Schichten des OSI-Modell [G] anzusiedeln ist, d.h. in den
Layern 5-7. Die dort relevanten Protokolle sind HTTP/HTTPS [G] bzw. WebDAV [G]
und XML-RPC/SOAP [G], auf die – in dem Abschnitt Integration“ (3.2.2) – näher
”
eingegangen wird. Zum Tragen kommen diese dann bei der Konzeption der API (4.2)
bzw. dem Teil der Implementierung (5.2).
Weitere Technologien bezüglich der API sind seitens der Ein- und Ausgabe,
HTML/XHTML [G] bzw. generell die Datenaustauschformaten XML [G] und alternativ JSON [G]. Bei der Aufbereitung der Inhalte zu dem Zwischenformat wikiPAGEs
(4.3, 5.2.3.1) kamen XPath/XQuery [G] zum Einsatz bzw. zur Transformierung XSLT
[G] und zur Gestalltung der Anzeige XSL-FO [G] bzw. CSS [G]. Bei der Definition der
wikiPAGEs-Seite flossen in die Betrachtung von XML Schema/DTD [G] mit ein und bei
den Metadaten RDF [G] und die Spezifikationen des Dublin Core [G].
Implementiert wurde die prototypische Umsetzung der API (5.2) und auch der Autorenumgebungen (5.3), in PHP [G], mit der Unterstützung von UML [G] in der Konzeption
(4.2) und SQL [G] bei dem Zugriff auf die verwendente relationale Datenbank. Zusätzlich
bediente sich die Autorenumgebung an dem Konzept: Ajax [G], d.h. einer asynchronen
Datenübertragung mit Hilfe von JavaScript [G] und XML [G]. Die im Bezug auf den
Export zum Tragen gekommenen Formate IMS Content Packaging (IMS CP), Sharable
Content Object Reference Model (SCORM) und Synchronized Multimedia Integration
Language (SMIL) werden im Abschnitt 3.3.2 genauer analysiert.
Im Kontext der Lehre (eLearning) und Wikis liegt die Arbeit im Bereich von CMS/LCMS
[G] bzw. LMS [G] was man allgemein auch als Wissensmanagement“ [G] zusammenfassen
”
kann.
Kapitel 3
Analyse
Analysiert werden in diesem Kapitel zunächst, auf der Grundlage von bereits beschriebenen generellen Eigenschaften von Wikis, ihren möglichen Einsatzszenarien und den allgemeinen Anforderungen einer eLearning-Autorenumgebung, die speziellen Anforderungen
an eine Autorensystem für den Einsatz von Wikis (3.1). Um mit diesem Autorensystem
keine Sonderlösung lediglich einer Wiki-Engine zu erstellen, geht es im Abschnit 3.2 um
die Untersuchung der Möglichkeiten zur Vereinheitlichung bzw. Integration von Wikis.
Abschließend werden in 3.3 dann die Anforderungen an Inhalte von eLearning-Software
betrachtet, um diese dann in meinem Konzept im Bezug auf den Export von eLearingKursen berücksichtigen zu können.
3.1
Autorenprozesse und -umgebungen
Wie in den Grundlagen zu Autorenumgebungen (2.3.2) bereits angedeutet, fehlt es
gänzlich an Unterstützung der Lehrenden im Einsatz von Wikis. Selbst auf Seiten der
Wiki-Engines, die explizit für die Lehre entwickelt wurden (2.2.2), werden diesen Bereiche einfach ausgeblendet und beschränken sich lediglich auf einen generell erleichterten
Umgang mit Wikis oder mit der Integration in bestehende Umgebungen im schulischen
oder universitären Umfeld. In beiden Fällen wird den Lehrenden aber keine gesonderte Rolle gegenüber dem Lernenden zugesprochen. Hinzukommt, dass selbst wenn es so
wäre, es durch den Ansatz einer Umsetzung einer weiteren Wiki-Engine nur zu einer Speziallösung führen würde, was dem Gesamtkonzept: Wiki (2.1), also der Vernetzung von
Inhalten, prinzipiell wiedersprechen würde.
Um nun ein Konzept einer solchen Autorenumgebung entwickeln zu können, müssen die
Unterschiede zu schon bestehenden Autorensystemen, ihren Prozessen und den verwende-
32
3.1 Autorenprozesse und -umgebungen
ten Inhalten untersucht und beschrieben werden (3.1.2 und 3.1.3). Dabei sind insbesondere
die speziellen Eigenschaften von Inhalten in Wikis zu beachten und die dadurch erhöhten
Anforderungen an die Autoren (3.1.1).
3.1.1
eLearning-Autoren und Wikis
Anders als bei dem Autorenprozess klassischer eLearning-Software, wo die Produktion
und die Präsentation der Inhalte von unterschiedlichen Personen vorgenommen werden,
sind diese im Einsatz von Wikis (insbesondere im Rahmen von Blended Learning1 (2.2.3),
oft ein und die selbe Person. Zu dieser Doppelbelastung kommt hinzu, dass die Produktion
nur ansatzweise dem Einsatz vorausgehen kann und somit hauptsächlich die Produktion
während der Präsentation“ stattfinden muss. Produktion heißt in diesem Fall, sich einen
”
Überblick zu verschaffen und aufgrund dessen motivierend, unterstützend, aber eben auch
konstruktiv und produktiv auf die Wiki einzuwirken [Bre06b].
Problematisch ist insbesondere die Vereinigung von Autoren und Tutoren [And06]. Denn
durch die rasante Entwicklung und der zunehmenden Vielfalt im eLearning und ganz besonders im Kontext von Wikis, müssen eLearning-Autoren immer mehr aufwand betreiben, um vorhandene Technologien zu überblicken und im speziellen dann das technische
Know-How zu erlangen. Diese Rolle im Einsatz von Wikis übernimmt nun der Lehrende,
mit dem Zusatz, die Technik nicht nur für sich nutzbar zu machen [Hin04], sondern auch
gleichzeitig Strategien zu entwickeln, diese Techniken den Lernenden zu unterbreiten, ohne dabei den Fokus auf die eigentlichen Inhalte der Veranstaltung zu verlieren [Say06].
Das kritische daran ist, dass je besser er dies macht (höherer Aufwand, Effizienz), desto
besser wird der Umgang der Lernenden mit der Wiki, was sich direkt auf die Komplexität
und den Umfang der Inhalte auswirkt, wodurch wiederum der Aufwand steigt.
3.1.2
eLearning-Software und Authoring
Unter Authoring im Kontext von eLearning versteht man den ganzheitlichen Prozess
(Autorenprozess) von der Planung über die Produktion bis hin zur Evaluierung von Lehrmaterialien. Dieser ist somit grob in drei Phasen unterteilt, der Vorbereitung (Analyse,
Planung, Konzept), der Produktion (Medienbearbeitung, Implementierung, Umsetzung)
und der Nachbereitung (Tests, Evaluation) im Anschluss des geplanten Einsatzes.
In der Vorbereitungsphase (1) werden somit zum einen inhaltliche Fragen geklärt, wie
z.B. der Umfang des Einsatzszenarios, die Aufteilung in kleinere Lehreinheiten oder die
1
integriertes Lernen
3 Analyse
33
didaktische Zielsetzung und zum anderen werden technischen Vorraussetzungen der verwendeten eLearning-Software und ihre gestalterischen und didaktischen Mittel analysiert.
Aufgrund dessen wird in der Produktionsphase (2) dann die einzusetzenden Medien ausgewählt und der Lernsoftware entsprechend aufbereitet, kombiniert und anhand der verwendeten Metapher in der Autorenumgebung 2.3.2 angeordnet.
Bei der Nachbereitungsphase (3) wird dann die Einhaltung der vorab gesetzten Ziele anhand von Evaluationen im direkten Einsatz oder anhand von Ergebnissen aus gesonderten
Tests überprüft.
Eine Autorenumgebung unterstützt dabei hauptsächlich die Methoden in der Phase (2),
um die zu verwendenden Inhalte auf die Struktur, das Layout und die Navigation in der
Lernsoftware abzubilden. Diese können auch zusätzlich schon Elemente der Text-, Bildund Videobearbeitung beinhalten, wobei in den meisten Fällen von bereits bearbeiteten
Medien ausgegangen wird und somit die Verwendung von externen Anwendungen vorausgesetzt werden. In seltenen Fällen stellt allerdings die Autorenumgebung auch Funktionen
für die Phase (3) zur Verfügung, um nach dem Einsatz und bei der Produktion weiterer
Lerneinheiten erzielte Ergebnisse ausgewertet und berücksichtigt werden können [Die98].
Diese drei bzw. insbesondere die beiden ersten Phasen des Autorenprozesses und der
Einsatz von Autorenumgebungen werden nun am Beispiel der LernBar konkretisiert und
untersucht.
3.1.2.1
Beispiel: LernBar
Betrachtet wird der Einsatz der eLearning-Software LernBar“ (2.3.1) und der dazu”
gehörigen Autorenumgebung LernBar Studio“ (2.3.2) im Rahmen einer Blended eLear”
ning Veranstaltung (2.2.3) zwischen der Professur für Graphische Datenverarbeitung Fachbereich Informatik und Mathematik der Universität Frankfurt und dem MPS Office
des Daimler Konzerns. Die dafür produzierten Inhalte für die LernBar konnten von Trainees in den entsprechenden Online-Phasen aufgerufen und bearbeitet werden, welche sich
direkt auf die Inhalte der vergangenen Präsenzphasen bezogen. Somit war es den Lernenden möglich, behandelte Thematiken teilweise über Quizze bzw. Self-Assessment-Tests
und teilweise über multimedial aufbereitete Versionen zu wiederholen und zu verinnerlichen. Bei diesem Projekt kamen sämtliche Komponenten (2.3.1.1) der LernBar zum
Einsatz, welche auf die speziellen Anforderungen des MPS-Office angepasst wurden. Die
drei Phasen des Autorenprozesses (3.1.2) beim Einsatz der LernBar anhand des Beispiels
Daimler“ sahen somit wie folgt aus.
”
In der Vorbereitungsphase (1) wurden die einsetzbaren Mittel innerhalb eines Kurses und
generell beim Einsatz der LernBar analysiert und mit den zu verwendenden Inhalten
34
3.1 Autorenprozesse und -umgebungen
abgeglichen. Die dafür entscheidenden Punkte waren:
• Der prinzipielle Aufbau einer Seite, d.h. Umfang (z.B. max. Zeichen pro Spalte) und
Anordnungsmöglichkeiten von Text und Medien
• Verknüpfungsmöglichkeiten von Seiten und Seitentypen, welche in der LernBar (jenseits des Hauptnavigationspfades) Abstract-Seiten, Erweiterungsseiten, Gliederungen in Lektionen und Gruppen und deren lineare Verlinkung betrifft.
• Verwendungsmöglichkeiten von Medien im Bezug auf ihre Darstellung (Vollbild,
Thumbnails) ihre Einordnung (Popup, Textfluss), gegebenenfalls der Interaktion
(Start, Stop, Laut, Leise) und ihre Möglichkeiten unter didaktischen Gesichtspunkten, wie die Synchronisation zwischen zwei Medien (z.B. Text und Audio) oder
automatischen Unterbrechung zum gezielten Einsatz von Interaktion des Lernenden
und der Anwendung (didaktische Stops).
• Verwendbare Fragetypen (Multiple Choice, Single Choize, Textfragen etc.) und deren
Möglichkeiten zur Auswertung, Bewertung, Evaluation und Vergabe von direkten
und indirekten Feedbacks.
• Mögliche Unterstützungen des Lernenden bezüglich der Verwendung des Kurses und
des verwendeten Inhalts, wie z.B. die Generierung einer Seitenübersicht (KurseMap), die Einbindung eines Glossars und dessen Umsetzung (Kann man Wörter
direkt im Text verlinken? Wie wechselt man zwischen einem Glossareintrag und
dem dazughörigen Text?)
• Unterstützung der LernBar-Nutzer an sich, wie z.B. die Möglichkeiten, Inhalte auszudrucken, Hilfe-Systeme zur allgemeinen Verwendung des LernBar-Players oder
Hinweise zum Support und weiteren Angeboten.
• Distributions und Einsatzmöglichkeiten der LernBar, um evtl. vorausgesetzte Mindestanforderung mit örtlichen Begebenheiten abklären zu können.
Anhand dieses Repertoires an möglichen strukturellen, gestalterischen und didaktischen
Mitteln wurde nun Autorendrehbücher erstellt, welche genau festlegten, wie die Inhalte
den entsprechenden Mitteln zuzuordnen bzw. anzupassen sind. D.h. konkret hatte jeder
LernBar-Kurs genau ein Drehbuch, in dem die jeweiligen Seiten jeweils einer Seite in
dem Kurs entsprochen haben. Dies betraf den Text, externe/interne Verlinkungen, Medien (Bilder, Videos, Animationen), Glossareinträge, Fragen bzw. Antworten und deren
Punktesystem usw. Kurzum wurde hier beschrieben, wie, wann und wo etwas zu passieren
3 Analyse
35
hatte und zwar auf der zuvor analysierten Basis an Möglichkeiten der eLearning-Software
LernBar“, was die folgende Phase (2) enorm vereinfachte.
”
Die Produktionsphase (2) konnte somit nämlich völlig unabhängig von den Lernenden
bzw. den Autoren durchgeführt werden, da der Ablauf, festgehalten in den Drehbüchern,
absolut klar war. Sie begann mit der Aufbereitung und Anpassung der Medien, also das
Zuschneiden von Grafiken, Bearbeiten von Videos, Erstellen von Animationen, gefolgt
von dem eigentlichen Erzeugen von LernBar-Kursen. Mit der Unterstützung der Autorenumgebung und den Angaben im Drehbuch beschränkte sich dies letztendlich auf relativ
einfache Copy&Paste-Vorgänge bzw. der Bedienung von entsprechenden Wizzards, wie
z.B. dem zur Fragengenerierung.
Ein entscheidender Punkt im Bezug auf diese Arbeit, d.h. der Entwicklung einer Autorenumgebung zur Erstellung von eLearning-Kursen aus Wiki-Inhalten, waren die Anforderungen, die sich bei der Erzeugung des Glossars ergaben. Dieses wurde zwar auch
zentral auf einem Server abgelegt und konnte von den entsprechenden Clients mit Hilfe
des LernBar Studios befüllt und automatisch generiert werden, jedoch wären gerade an
dieser Stelle die allgemeinen Möglichkeiten einer Wiki zur kollaborativen, kooperativen
Erzeugung von Texten durchaus hilfreich gewesen. Insbesondere in dem Hinblick auf die
Tatsache, dass in naher Zukunft die Anzahl der Autoren (Clients) stark ansteigen wird
und somit Funktionalitäten wie eine Kollisionsbehandlung oder unterschiedliche Nutzergruppen und Datenbestände immer wichtiger werden. Diese müssten dann mühevoll in die
bestehende Anwendung implementiert werden, obwohl in diesem Fall eine Wiki sofort einsatzbereit, von überall zugänglich und schlichtweg dafür geschaffen wäre. D.h. das Glossar
würde in der Wiki erstellt, bearbeitet und gepflegt, die Generierung übernähme dann die
Wiki-Autorenumgebung bzw. könnte dem LernBar Studio als Schnittstelle dienen.
3.1.3
Wikis und Authoring
Nach den allgemeinen Einführung im Grundlagen-Kapitel (2.1) in das Thema eLearning und Wikis möchte ich dies nun aus einem etwas konkreteren Blickwinkel betrachten
und analysieren. Dazu habe ich drei Beispiele aus meiner Arbeit als Student-Consultant
gewählt, welche im Bezug auf die möglichen Einsatzszenarien von Wikis (2.2.3) jeweils
einem entsprechen. Wichtig ist mir dabei insbesondere, einen Abgleich zwischen den Erwartungen der Initiatoren der jeweiligen Projekte und der letztendlich eingetretenen Realität zu machen, um prinzipielle Probleme zu lokalisieren und dementsprechend gezielte
Lösungsstrategien entwickeln zu können.
Jedes der gewählten Projekte fand bzw. findet im universitären Umfeld statt. In jedem
36
3.1 Autorenprozesse und -umgebungen
kommt genau eine separate Installation einer Wiki vom Typ MediaWiki“ (Wiki-Engines,
”
siehe Kapitel 3.2) zum Einsatz, womit eventuell eintretende technische Hindernisse für
jedes Beispiel als gleich angesehen und somit besser verglichen werden können. Inhaltlich
und in deren Sinn und Zweck unterscheiden sich diese allerdings teilweise erheblich.
Das erste Beispiel: Anatomie-Wiki“ ist deshalb interessant, da die Wiki veranstaltungs”
begleitend über drei Semester eingesetzt werden sollte, die Größe der Veranstaltung mit
überdurchschnittlich vielen Teilnehmern begann und der geplante Inhalt sowohl organisatorische als auch fachliche Elemente beinhaltete.
Im zweiten Projekt: Basis-ReliPaed“ wurde die Wiki ebenfalls veranstaltungsbegleitend
”
eingesetzt, jedoch war hier die Teilnehmerzahl überschaubarer und die Nutzung entsprach
der üblichen technischen Unterstützung zur kollaborativen Textproduktion für das Verfassen von Referaten und Seminararbeiten. Zusätzlich kamen bei der Erstellung der Arbeiten
ein erhöhter Medieneinsatz zum Tragen.
Als letztes Beispiel hab ich OKAPI“ gewählt, deren Einsatz einer Wiki noch einmal einen
”
ganz anderen Weg einschlägt als die beiden vorherigen, welche als klassische Beispiele für
Blended Learning (2.2.3) gelten. D.h. die hier verwendete Wiki wird nicht durch eine
Präsenzveranstaltung begleitet, sondern steht für sich alleine und ihren eigenen Zweck.
Interessant ist dabei, dass diese fachbereichsübergreifend genutzt wird und somit für unterschiedlichste Nutzergruppen eine allgemeine Anlaufstelle für eine Fülle von Informationen
und Hinweisen bieten soll.
Weitere Details zu den Projekten, den Auswertungen im Bezug auf einen Abgleich von
den – im Vorhinein gesetzten – Erwartungen und den tatsächlichen Gegebenheiten bei
der Umsetzung folgen den drei nächsten Unterkapiteln.
3.1.3.1
Beispiel: Anatomie-Wiki
Im Sommersemester 2006 wurden 600 Studenten der Humanmedizin des Universitätsklinikums Frankfurt die Möglichkeit geboten, in einer veranstaltungsbegleitenden
Wiki ihre Vorlesungsmitschriften kooperativ zu erarbeiten. Registriert haben sich 205,
von denen 13 aktiv mitgearbeitet haben.
Ziel des Einsatzes war eine Untersuchung, wie in dem Bericht MediaWiki - als Werkzeug
”
zur kooperativen Erstellung einer Vorlesungsmitschrift in der Humananatomie“ [Kla06]
nachzulesen ist, in wie weit Studenten im vorklinischen Studienabschnitt (2. Semester)
des Medizinstudiums mit Hilfe einer Wiki kollaborativ und eigenverantwortlich ein Vorlesungsskript erstellen können.
Die Anatomie-Wiki (Bild 3.1) wurde in einer Vorbereitungsphase durch die Betreuer in-
3 Analyse
37
sofern vorstrukturiert, dass die Vorlesungswochen und -stunden in Form eines Inhaltsverzeichnisses erzeugt und die wesentlichen Inhaltsfelder der Vorlesung anhand von Kategorien vorgegeben wurden. Abgesehen davon sollten sich mit dem Beginn der Veranstaltung
die Dozenten nicht aktiv an der Anatomie-Wiki beteiligen, um die von den Studierenden
”
geäußerten Befürchtungen, einer Kontrolle durch Lehrkräfte zu unterliegen“, von vornherein zu begegnen. Allerdings gab es die Möglichkeit, Kommentare und Feedbacks in den
Diskussions-Seiten der Wiki-Artikel zu hinterlassen.
Bild 3.1: Wikis im eLearning: Anatomie-Wiki
Die Studierenden wurden zu Beginn und zum Schluss nach der erwarteten Nutzung die”
ses Angebots sowie ihren Einschätzungen zum Einsatz des Wikis als Vorlesungsskript“
befragt. Zusammenfassend erwarteten sowohl die Studierenden als auch die Dozenten
mehrheitlich eine Unterstützung der Lehre und des Reflexionsprozesses in Bezug auf den
Lerninhalt. Tatsächlich wurde aber die vorgegebene Struktur, also wie sie im Sinne der
Lehre zuvor gedacht war, von den Studierenden nicht wahrgenommen und auch die Feedbacks seitens der Dozenten kamen so nicht zustande (trotz der Nachfrage seitens der
Studierenden). So entstanden Inhalte mit meist wenigen bis gar keinen Verlinkungen,
ähnlich der bekannten Glossarstruktur der Wikipedia, was darauf schließen lässt, dass die
vorbereiteten Artikel seitens der Betreuer nicht genügend strukturiert und transparent“
”
angelegt waren. Ansonsten galt der allgemeine Zeitmangel im Zusammenhang mit dem
38
3.1 Autorenprozesse und -umgebungen
Medizinstudium als generelle Erklärung für die geringe Teilnahme.
Als Fazit ergab sich in dem Bericht [Kla06], eine Wiki eher
in der Form eines
”
längerfristigen, semesterübergreifenden Informationsrepositoriums“ anzubieten, um es
den Studierenden zu ermöglichen, ohne terminliche Bindung und parallel zu den Ver”
anstaltungen eine Mitschrift auszuarbeiten und kontinuierlich zu erweitern“. Des Weiteren wird in diesem Zusammenhang immer wieder auf die nötige Wiederverwendbarkeit
der Inhalte verwiesen, um Informationsartefakte“ veranstaltungsbezogen gegebenenfalls
”
in relevante Kontexte zu setzen und diese dann in verschiedenen Anwendungsszenarien
weiterverwenden zu können.
3.1.3.2
Beispiel: BasisReliPaed
Wie der Startseite der BasisReliPaed-Wiki entnommen werden kann (Bild 3.2), ist
das Ziel dieses Projektes die Erarbeitung eines qualitätsgeprüften Online-Lexikons im
”
Blended-Learning-Verfahren für zunächst religionspädagogische, später auch gesamttheologische Fachbegriffe“. Die eingestellten Inhalte (Projektpräsentationen) der Wiki wurden
in Gruppenarbeit sowohl von Studierenden der Universität Frankfurt als auch der Universität Kassel reflektiert bzw. kommentiert. Als ergänzende Kommunikationsbasis wurden
Videokonferenzen zwischen beiden Standorten etabliert, in denen die Studierenden sich
in inhaltlichen und technischen Fragestellungen gegenseitig assistieren. Neben dem Ziel
eines Online-Lexikons“ soll ein weiterer Sinn der Wiki sein: Studierenden an die Orga”
”
nisation von Arbeits- und Gruppenprozessen heranzuführen und Ergebnisse von Anfang
an als ”geteiltes Wissen” zu verstehen“.
Insgesamt registrierten sich 69 Benutzer in der BasisReliPaed-Wiki und erarbeiteten insgesamt 64 Seiten kleinere bis mittelgroßer Artikel. Davon wurden im Schnitt 16 bearbeitet.
Der Administratorenanteil lag bei knapp 2 % und es wurden 88 Grafiken hochgeladen,
welche alle in den entsprechenden Seiten verwendet worden sind. Von den Betreuern wurden inhaltlich lediglich die Hauptseite und die Hilfeseiten vorbereitet, um den Teilnehmern
den Einstieg bei der Benutzung der Wiki zu erleichtern bzw. bei den ersten Schritten zu
assistieren. Strukturell wurde genau eine Kategorie angelegt, unter der jeder seine fertigen
Artikel einordnen sollte. Somit wurden die fertiggestellten Projektpräsentationen auf einer Seite (der Seite der Kategorie) alphabetisch gesammelt und konnten damit überblickt
und präsentiert werden.
Im Gegensatz zu dem vorherigen Beispiel wurden hier alle Vorbereitungen und Vorgaben seitens der Betreuer wahrgenommen, verstanden und umgesetzt, was wahrscheinlich maßgeblich von der inhaltlich und technisch unterstützenden Präsenzveranstaltung
begünstigt wurde. Allerdings hat sich auch hier gezeigt, dass die Inhalte wenig bis gar
3 Analyse
39
Bild 3.2: Wikis im eLearning: BasisReliPaed
nicht verlinkt wurden oder allgemeiner betrachtet, dass ein anfangs erwarteter Grup”
penprozess“ (zumindest im Bezug auf die Wiki) nicht zustande gekommen ist. D.h. die
Projektpräsentationen wurden in den aller seltensten Fällen von anderen Nutzern der Wiki als von dem Autoren selber korrigiert, ergänzt oder verlinkt, geschweige denn gänzlich
von einer Gruppe kollaborativ erarbeitet. Des Weiteren wurden bei den meisten Seiten
zusätzliche HTML-Tags verwendet, um die Grenzen des gegebenen Wiki-Markups zu untergraben, damit das Layout einer Seite nach eigenen Vorstellungen gestaltet werden kann.
3.1.3.3
Beispiel: OKAPI
OKAPI ist ein im Gegensatz zu den vorherigen beiden Beispielen ein noch laufendes Projekt, initiiert von dem Fachbereich 08 der Johann Wolfgang Goethe-Universität Frankfurt am Main zur Sammlung studienrelevanter Hinweise. Der Fachbereich umfasst vier
wissenschaftliche Betriebseinheiten: Das Historische Seminar mit der Abteilung für Alte
Geschichte, das Institut für Historische Ethnologie, das Institut für Philosophie und das
Seminar für Didaktik der Geschichte. Für diese vier werden in absehbarer Zukunft (zurzeit noch drei) im Rahmen von OKAPI, Materialien, Informationen und weiterführende
Links und Adressen zum Studienverlauf, zu verschiedenen fachspezifischen Arbeitstechni-
40
3.1 Autorenprozesse und -umgebungen
ken und zu Berufsperspektiven gesammelt, medial aufbereitet und in einer Wiki für die
Studierenden bereitgestellt.
Insgesamt gibt es in der OKAPI-Wiki (Bild 3.3) 6 registrierte Benutzer, wovon 5 Administratoren sind, was deutlich den eher zur Verfügung stellenden“ Charakter einer Infor”
mationenplattform bestätigt. Erarbeitet wurden bis zum jetzigen Stand 93 Seiten, welche
im Schnitt 12 mal bearbeitet und insgesamt 120.000 mal aufgerufen wurden. Hochgeladen
wurden 26 Dateien bzw. Grafiken. Strukturell werden die Inhalte der unterschiedlichen
Betriebseinheiten getrennt voneinander in unterschiedlichen Namensräumen der Wiki erzeugt und bearbeitet. Diese werden auf entsprechenden Portalen zusammengefasst, welche
wiederum auf der Hauptseite verlinkt sind.
Bild 3.3: Wikis im eLearning: OKAPI
Anders als bei der Anatomie-Wiki oder dem BasisReliPaed-Wiki können an dieser Stelle keine Aussagen über die Akzeptanz von Vorbereitungen bzw. deren Umsetzung, was
unter anderem daran liegt, dass das Projekt noch am wachsen und die Anzahl der aktiven Autoren überschaubar ist. Allerdings ist insbesondere diese Wiki sehr attraktiv,
was die Aufbereitung und Wiederverwendung der Inhalte betrifft. So wäre es z.B. denkbar, in einem weiteren Autorenprozess die Informationen der jeweiligen wissenschaftlichen Betriebseinheiten aufzubereiten und in entsprechende LernBar-Kurse (3.1.2.1) zu
überführen. Diese können dann von Zeit zu Zeit aktualisiert und als inhaltlich kontrollierte Versionen zusätzlich den Studierenden zur Verfügung gestellt werden. Möglich wäre
3 Analyse
41
auch eine Live-Anzeige“ der Inhalte, welche jedes mal wenn der LernBar-Kurs gestartet
”
wird aktualisiert und entsprechend aufbereitet angezeigt werden.
3.1.4
Zusammenfassung und Beurteilung
Bis auf die Wiki des OKAPI-Projekts, wo die Anzahl der Autoren sehr überschaubar und
vorbestimmt waren (3.1.3.3), bezogen sich die vorab ermittelten Erwartungen meist auf
die Förderung von kollaborativen und kooperativen Arbeitstechniken seitens der lernen”
den“ Autoren. Tatsächlich wurden jedoch Artikel meist isoliert und getrennt voneinander
erstellt und in den aller wenigsten Fällen untereinander korrigiert oder ergänzt. Dies zeigte
sich schon, wenn es nur“ darum ging, die Seiten untereinander zu verlinken (3.1.3.2) oder
”
einer schon bestehenden (in der jeweiligen Wiki üblichen) Struktur zuzuordnen (3.1.3.1).
Letzteres könnte allerdings auch prinzipiell an Problemen liegen bei dem generellen Umgang mit Hypertexten oder einem mangelnden Verständnis einer Wiki als ganzes (Global
Site View), welche auch in den Ergebnissen der Untersuchungen von [Ala05] wieder zu
finden sind. In dieser Untersuchung sollten 15 Schüler der vierten Klasse in 6 kleinen Gruppen gemeinsam Texte in einer Wiki (Lizzy Wiki) erarbeiten. Obwohl keines der Kinder
vorher mit einer Wiki gearbeitet hatte und auch diesbezüglich keine Einführung gegeben
wurde – allerdings durften die Kinder bei Problemen fragen – beendeten 5 davon die
Aufgabe erfolgreich. Bei der Auswertung der aufgetretenen Probleme kam heraus, dass
überwiegend im allgemeinen Umgang mit Hypertexten (63 %) Zusammenhänge und Konzepte nicht verstanden und dementsprechend umgesetzt wurden. Im Speziellen betrafen
davon 49 % das Erstellen und Managen von Links und 14 % das Schreiben, Aufteilen und
Verlinken der Texte im Sinne einer netzartigen Struktur. Die nächst häufigsten Probleme
waren dann mit 12 und 11 % das Hochladen von Bilder und das Editieren von Texten.
Während sich jedoch die letzten beiden Punkte, wenn man dagegen angehen möchte, relativ einfach technisch lösen lassen (z.B. durch einen entsprechenden WYSIWYG-Editor
[Sau06]) , kann man die überwiegende Anzahl von Problemen, welche im Sinne der Wikis
auch wesentlich relevanter sind, lediglich durch eine bessere Betreuung seitens der Autoren begegnen. Zusammenfassend werden diese Bestimmungsfaktoren auch in [Hin04]
beschrieben, welche im Wesentlichen aus drei Punkten bestehen (siehe Bild 3.4), die sich
direkt und indirekt gegenseitig beeinflussen.
Das Hauptproblem bleibt und ist technisch nur so zu lösen, indem man den Autoren in der
Wiki eine gesonderte Rolle zuschreibt. Deshalb liegt mein Ansatz zwischen dem Einfluss
der Technik und dem Einfluss der Pädagogik, da die Technik (die Autorenumgebung)
lediglich zur Unterstützung der Lehrenden entwickelt wird, was sich aber, wie man anhand
42
3.1 Autorenprozesse und -umgebungen
Bild 3.4: Bestimmungsfaktoren beim CSCL [Hin04]
der Grafik und Beispiele sehen kann, auch indirekt auf den Nutzen für die Lernenden
auswirkt.
Zu diesem Schluss kamen auch ansatzweise die Untersuchungen in dem Paper Is The”
re a Space for the Teacher in a WIKI?“ [And06]. Die Aufteilung der Benutzer in den
gängigen Wikisystemen beschränken sich hauptsächlich auf lese- und schreibrechte, in deren Gruppierung für die lehrende Kraft kein Platz zu sein scheint. Denn es ist klar, dass
der Lehrende im Bezug auf das Schreiben in der Wiki alle möglichen Rechte zugeteilt
werden und dies natürlich auch das Lesen betrifft. Aber was hat er für Mittel zur Hand –
wie sie z.B. in einem LMS gegeben sind – wo dem Lehrenden eine explizite Rolle als Organisierer, Moderator der Lern-Aktivitäten zugeteilt wird bzw. explizit die Möglichkeiten
erhält Lehr-Materialien und Anweisungen zu erzeugen und anbieten zu können.
In Wikis arbeiten die Lehrende mit den selben Werkzeuge wie die Lernenden und die
einzige Chance, eine Meta-Position einzunehmen, besteht darin, mehr Aufwand zu betreiben, immer und überall sich einen Überblick zu verschaffen, was ein immer komplexeres Verständnis des Mediums voraussetzt. Steigt aber dieses Know-How auch bei den
Lernenden oder einfach ihre Anzahl, nimmt der Aufwand für den Lehrenden exponentiell
zu. Daraus folgt:
Autoren mit lehrendem Hintergrund brauchen einen gesonderten Raum in
einer Wiki, von dem aus sie kontrollieren, nachverfolgen, beobachten, ansteuern, auslösen, einleiten, anregen, antreiben, fördern und reizen können, um
den Einsatz positiv beeinflussen bzw. im Nachhinein auswerten zu können.
3 Analyse
43
Das Problem bei dem Ansatz von [And06] ist wiederum, dass sie dieses über die Features der Wikis lösen möchten, was im besten Fall eine entsprechende eLearning-Wiki“
”
hervorbringt, aber wiederum Probleme aufwerfen wenn man Inhalte aus anderen Wikis einbeziehen möchte. Denn gerade in der Lehre wird immer häufiger veranstaltungs-,
fachbereichs- und organisationsübergreifend gearbeitet, was zwangsläufig zu einer Vernetzung von unterschiedlichsten Wikis und Anforderungen führt, welche sich nicht auf eine
Engine beschränken lassen. Deshalb sollte an dieser Stelle von der zugrunde liegenden
Wiki-Software abstrahiert werden.
3.2
Wiki-Inhalte
Für die Entwicklung einer Autorenumgebungen im Umgang mit Wikis und im Sinne der
Lehre ist also zunächst eine Abstraktion von den zugrundeliegenden Wikis entscheidend.
Diese Abstraktion führt zu einem Konzept: Wiki, welches einheitlich auf prinzipiell gleich
strukturierte Inhalte zugreift. Um dies zu erreichen, werden in den beiden folgenden Abschnitten sowohl die Harmonisierung von Wiki-Inhalten im Bezug auf den Inhalt an sich
und das Layout und die Struktur 3.2.1, als auch die möglichen Schnittstellen zur Integration von Wiki 3.2.2 analysiert.
Untersucht werden dabei bereits bestehende Lösungsansätze wie WikiCreole, Wiki Interchange Format (WIF) bezüglich des Inhalts und WikiGateway, DavWiki als Möglichkeiten
des Zugriffs bzw. die Gegebenheiten der Wiki-Systeme an sich.
3.2.1
Harmonisierung
Wiki-Inhalte unterscheiden sich zunächst nicht von den Inhalten, die prinzipiell in HTML/
HTML [G] möglich sind bzw. dargestellt werden können. Es gibt Möglichkeiten, Text
zu gestallten und zu strukturieren (z.B. Schriftart/-farbe oder Listen und Tabellen), es
können Medien in den Text integriert und entsprechend formatiert werden (Bilder, Videos etc.) und Textpassagen und Medien können dazu verwendet werden, um auf andere
Inhalte zu verweisen. D.h. eine Wiki-Seite entspricht von ihrer Funktionalität mehr oder
weniger einer gewöhnlichen HTML-Seite. Mehr oder weniger deshalb, da an dieser Stelle
natürlich die entsprechende Wiki-Engine den Grad des zugelassenen Funktionsumfangs
bestimmt bzw. vorgibt. Die Vorgabe findet sich in der zugrunde liegenden Wiki-Syntax
wieder, welche prinzipiell die Möglichkeiten der Benutzer definiert, wie detailliert Inhalte
strukturiert, gestalltet bzw. miteinander Verknüpfungen werden können. Denn ist hier
eine entsprechend feine Granularität nicht gegeben ist klar, dass der Parser [G] bei der
44
3.2 Wiki-Inhalte
Umwandlung in ein (von einem Browser darstellbaren) Format (HTML/XHTML) keine zusätzliche Verfeinerung mehr vornehmen kann. Des Weiteren bestimmt die Engine,
ob sie sich auf die Eingabe der in der Wiki zulässigen Syntax beschränkt oder ob sie
zusätzlich noch die Eingabe von HTML-Tags zulässt. Je nachdem, wie viel nun die Engine an zusätzlichen HTML-Code durch den Benutzer gestattet, unterscheidet sich die
Ausgabe einer Seite einer einzigen Wiki unter Umständen von der einer zweiten ähnlich
ausschauenden Seite gravierend. Leider trifft letzteres auf die meisten Wiki-Engines zu2 ,
weshalb im Sinne einer Harmonisierung an zwei Stellen angesetzt werden muss. Nur so
hat man die Möglichkeit, später zwischen automatisch generierten HTML-Code der Engine über die Wiki-Markup und zusätzlich hinzugefügten unterscheiden zu können und
Rückschlüsse auf die Intentionen des Seiten-Autors zu ziehen.
Klarer fällt da ein Versuch der Vereinheitlichung im Bezug auf Funktionen von Wikis
aus, welche nicht dem unmittelbaren Umfang einer normalen HTML-Seite entsprechen.
Dies sind, wie in dem Abschnitt über Seitenübergreifende Funktionalitäten von Wikis“
”
(2.2.1.2) näher beschrieben im Wesentlichen die Einordnung von Seiten in Kategorien
oder Namensräumen, die Unterteilung von externe/interne bzw. eingehende und ausgehende Links und die Informationsgewinnung über so genannte Spezialseiten. Auf all diese
Funktionen lässt sich, zwar immer noch Wiki-Spezifisch, aber relative einfach und klar
separiert vom restlichen Inhalt zugreifen.
In den folgenden drei Unterabschnitten wird sich immer, bis auf den Abschnitt Wiki
”
Markup und WikiCreole“ (3.2.1.3), auf die Repräsentation einer Seite als HTML-Seite
bezogen, was auch hinsichtlich der Harmonisierung dem deutlich komplexeren und allgemeineren Teil entspricht.
3.2.1.1
Struktur und Layout
Grundsätzlich haben wir es bei der Betrachtung einer Wiki-Seite mit semi-strukturierten
Inhalten zu tun [Vos06]. Die darin enthaltenen Informationen lassen sich somit nicht
so einfach extrahieren wie bei strukturierten Inhalten (Datenbanken, Tabellen etc.), sind
aber durch die verwendeten HTML-Tags auch nicht so unstrukturiert wie es z.B. bei einem
unformatierten Text in einer natürlichen Sprache der Fall wäre wo es sehr schwierig ist,
sich auf einzelne Teile des Dokumentes zu beziehen bzw. diese zu bearbeiten.
Die Elemente zur Strukturierung von Texten, auf der Basis von HTML, sind in der
Tabelle 3.1 gelistet.
2
laut WikiMatrix [Det08] unterstützen aktuell 26 von 102 Wiki-Engines ein paar HTML-Tags, 33 von
102 alle und 27 von 102 optional oder über Plugins (Stand: April 2008)
3 Analyse
45
Tabelle 3.1: Elemente zur Strukturierung von Texten
Abschnittsüberschriften:
Blockelemente:
Listen:
<h1>, <h2>, <h3>, <h4>, <h5>, <h6>
<p>, <pre>, <hr>
<dl>, <dd>, <dt>, <ol>, <ul>, <li>
Tabellen:
<table>, <tr>, <th>, <td>
Sonstige:
<img>, <a>
Die Elemente zur Gestaltung von Texten sind dementsprechend die in der Tabelle
3.2 gelisteten HTML-Tags, wobei auch diese strukturierender Natur sein können bzw.
strukturierende Elemente auch gewisses gestalterische Stile mit sich bringen:
Tabelle 3.2: Elemente zur Gestaltung von Texten
klar:
unklar:
<i>, <b>, <em>, <sub>, <sup>, <tt>
<span>, <div>
Alle aufgelisteten Tags (Tabelle 3.1 und 3.2) sind im Bezug auf die Strukturierung eines
Textes eindeutig, d.h. sie beschreiben klar wo ein zu separierender Teil anfängt und wo er
aufhört. Problematisch wird es, weniger bei den unter klar“ gelisteten Tags, als bei den
”
unter unklar“ gelisteten Tags, wenn man sich auf die visuellen Stile bezieht. Unklar ist
”
dabei, dass Formatierungen zum Teil direkt über HTML-Attribute (align=“center”) oder
über Stylesheets (style=“align:center”) bzw. Stylesheet-Klassen (class=“center”) realisiert werden können, was eine Harmonisierung an dieser Stelle schwierig macht. Ganz
davon abgesehen von den Elementen, die vom World Wide Web Consortium (W3C) zwar
nicht mehr empfohlen werden, aber teilweise immer noch in einer Vielzahl Seiten und
Wikis zu finden sind, wie z.B. Tags wie <font> oder <center> bzw. Attribute wie align,
width oder background.
3.2.1.2
Kontext und Metadaten
Betrachtet man wiederum die Möglichkeiten, die sich durch die Verwendung von HTMLTags ergeben, allerdings diesmal im Bezug auf den Kontext einer Seite bzw. deren Metadaten, stehen folgende Elemente zur Verfügung, welche in der Tabelle 3.3 gelistet sind.
Die relevanten Elemente sind dabei das <title>-Tag, was der herausragenden Rolle eines
Titels einer Wiki-Seite durchaus entspricht, da dieser auch als Schlüssel verwendet wird
46
3.2 Wiki-Inhalte
Tabelle 3.3: Kontext einer Wiki-Seite
Dokumentenkontext:
<html>, <head>, <meta>, <title>, <body>, <a>
(2.2.1.2) und das <meta>-Tag. Die anderen drei und das <a>-Tag dienen lediglich als
direkter Kontext zum betrachteten Inhalt bzw. als Mittel zum Zweck, um interne/externe
Verlinkungen zu extrahieren, falls die Wiki-Engine eine entsprechende Funktionalität nicht
direkt unterstützt.
Die anfallenden Metadaten bzw. der relevante Kontext im Bezug auf eine Seite innerhalb
einer Wiki sind der Tabelle 3.4 zu entnehmen, welche unter der Beachtung der Arbeiten
[AH05], [Kur06] analysiert wurden.
Tabelle 3.4: Metadaten einer Wiki-Seite
Wiki-
- Titel der Wiki, aus der diese Seite stammt
spezifisch:
- URL und Zugangsinformationen der Wiki
- Name der zugrunde liegenden Wiki-Engine
- Versionsnummer der Wiki-Engine
Seitenspezifisch:
- Titel der Seite (siehe <title>-Tag)
- Autor, der diese Seite erstellt bzw. als letztes bearbeitet hat
- Anzahl der Autoren bzw. der Revisionen
- Anzahl der enthaltenen Wörter oder Medien
- Schlüsselwörter im Bezug auf den Seiten-Inhalt
- Synonyme bzw. Homonyme des Titels
- Datum der ersten Version der Seite bzw. des letzen Updates
- interne bzw. externe Links, die in der Seite enthalten sind
- Kategorien und Namensräume, denen die Seite zugeordnet ist
- Weiterleitungen, die dieser Seite entsprechen
- Seiten, die auf diese Seite verlinken
- Verweis auf die erste bzw. letzte Version dieser Seite
- Verweis auf die nächst jüngere bzw. nächst ältere Version dieser
Seite
All diese Information werden von den jeweiligen Wiki-Engines unterschiedlich zugänglich
gemacht bzw. erst gar nicht betrachtet. D.h. hier ist im Bezug auf die Harmonisierung
entscheidend, die entsprechenden Daten aus den Wikis differenziert zu extrahieren und anschließend in ein vereinheitlichtes Format zu überführen, welches nach Möglichkeit leicht
3 Analyse
47
abzufragen und zu transformieren ist. Diese Vereinheitlichung ist abhängig von der jeweiligen Information und deren Komplexität und muss dementsprechend unterschiedlich
behandelt werden.
Bei den Punkten 1-4 der Wiki-spezifischen Metadaten lassen sich die anfallenden Information ohne Probleme in entsprechende <meta>-Tags unterbringen. Genauso wie die Punkte
2, 3, 4, 5, 6, 7, 12 und 13 unter der Beachtung und Einhaltung gegebener Standards wie
z.B dem Dublin Core [G] und der Angabe des Änderungsdatums bzw. des Autorens. Die
Punkte 8, 9, 10 und 11 hingegen können abhängig von dem Umfang der ursprünglichen
Wiki sehr komplex werden, weshalb eine strukturiertere Repräsentation der Daten (wie
z.B. in XML) durchaus angebracht ist.
3.2.1.3
Wiki Markup und WikiCreole
Wie im übergeordneten Abschnitt (3.2.1.1) bereits beschrieben, kann eine Harmonisierung
von Wiki-Inhalten, insbesondere im Kontext einer Autorenumgebung, nur durch den Ansatz an zwei Punkten erreicht werden. Zum einem der Interpretation und Transformation
des HTML-Quellcodes in ein einheitliches Format und zum anderen der vereinheitlichten
Betrachtungsweise von Wiki-Markups, um aus der Differenz beider gestalterische Intention ableiten zu können.
Mit dieser einheitlichen Betrachtungsweise oder Vereinheitlichung von Wiki-Markups
beschäftigt sich das WikiCreole Projekt [Chr07b]. In enger Zusammenarbeit mit dem
Wiki-Engine-Portal WikiMatrix“ [Det08] hat WikiCreole die bestehenden Wiki-Markups
”
analysiert und unter der Beachtung der Popularität einer Wiki-Engine zu einer einzigen
Syntax zusammengefasst. Diese Syntax sollte folgenden Zielen, mit abfallender Priorität,
genügen:
1. sie sollte kollisionsfrei im Bezug auf eine mögliche parallele Nutzung einer schon
bestehenden Syntax sein
2. sie sollte alles abdecken, was beim Gestalten und Strukturieren einer Wiki-Seite
entscheidend ist
3. sie sollte eher generalisieren anstatt zu spezifizieren, d.h. syntaktische Sonderlösungen werden nicht beachtet, was eine spätere Erweiterung ja nicht ausschließt
4. es soll keine neue Syntax hinzugenommen werden, d.h. jede Auszeichnung muss in
mindestens einer Wiki-Markup schon vorhanden sein
5. sie sollte schnell zu schreiben und gut zu lesen sein
48
3.2 Wiki-Inhalte
6. es sollte eine klare Trennung zwischen Inhalt und Layout geben
7. sie sollte leicht zu verstehen, d.h. zu erlernen und zu lehren sein
Die Ergebnisse bezüglich der Popularität von Wikis sind in meinem Grundlagen-Kapitel
bei der Betrachtung der Wiki-Engines zum Tragen gekommen und können dort nachgeschlagen werden (2.2.2). Die Ergebnisse im Bezug auf die entstandene einheitliche WikiSyntax lassen sich am Besten dem WikiCreole Spickzettel“ (Bild 3.5) entnehmen.
”
Bild 3.5: WikiCreole: Vereinheitlichte Wiki-Syntax [Chr07b]
Die Transformation einer bereits bestehenden Wiki-Syntax in die Syntax des WikiCreoleProjekts kann als unkritisch betrachtet werden, unter dem Vorbehalt, dass zusätzliche
3 Analyse
49
Elemente zur Verfügung stehen, in denen eventuell nicht implementierte Auszeichnungen
als Hinweis übergeben werden können. Zusätzlich deutet sich durchaus der Trend dahingehend an, dass immer mehr Wiki-Engines (ob parallel oder optional) die WikiCreoleSyntax von sich aus unterstützen und fördern wollen, was eine externe Transformierung
überflüssig werden lässt.
3.2.1.4
Wiki Interchange Format (WIF)
Unabhängig von der zugrunde liegenden Wiki-Markup einer Wiki-Seite, beschreitet das
Wiki Interchange Format (WIF) [Max06] ein wesentlich grundsätzlicheren Ansatz zur
Harmonisierung von Wiki-Inhalten, als es z.B. WikiCreole tut.
Die Idee ist, ein Austauschformat zu entwickeln, um Inhalte von Wikis – unabhängig
von der eingesetzten Engine – untereinander austauschen und möglichst in einem vollen
Funktionsumfang nutzen zu können. Hierbei war entscheidend [Kur06], dass dieses Format
einfach zu implementieren, zu generieren und zu handhaben ist, um es möglichst attraktiv
für die bestehenden und kommenden Wiki-Engines (und deren Entwicklern) zum Imund Export anbieten zu können. Zusätzlich sollte das Format an sich schon im Browser
renderbar sein, damit sich die Benutzer den Inhalt direkt (ähnlich einer Wiki) anschauen
können.
Um von den vielen unterschiedlichen Wiki-Engines im Bezug auf ihr Markup und den
Zugang zum Inhalt abstrahieren zu können, bezieht sich das WIF direkt auf die Schnittstelle, welche auch einem normalen Benutzer zur Verfügung steht, das Anfordern und
Zurücksenden von HTML-Seiten. Schwierigkeiten, die sich bei der Extraktion von Informationen ergeben können, wie z.B die Unterscheidung von internen und externen Links,
nehmen sie – angesichts der vielen unterschiedlichen Wiki-Markups – gern in kauf.
Grundlage für das Design des WIFs als Repräsentation einer Wiki-Seite und des Wiki Archive Format (WAF) für die Repräsentation einer Menge von WIFs sind XHTML-Dateien.
XHTML bzw. in diesem Fall eine Untermenge von XHTML wurde deshalb verwendet, da
sie sowohl für Menschen als auch für Maschinen – durch ihre XML-Basis – sehr gut lesbar
und somit einfach zu verarbeitet sind. Zu beachtende Details sind:
1. Einfache Metadaten werden über spezielle XHTML-Attribute und deren Werte beschrieben, komplexere über verlinkte RDF-Dateien.
2. Externe Dateien, die in den Wiki-Seiten eingebunden sind (Bilder etc.), werden
zusätzlich lokal gespeichert und relativ verlinkt.
3. Elemente der Wiki-Seiten, welche nicht unbedingt in das WIF passen (eingebun-
50
3.2 Wiki-Inhalte
den durch z.B. Plugins, Templates oder Makros), können über zusätzliche Hinweise, wie der entsprechende HTML-Code letztendlich zustande gekommen ist, beschrieben werden. Diese sind unabhängig von der Standard-WIF-Seite, d.h. einfache
Tools können diese Hinweise einfach missachten und die Seite trotzdem darstellen,
währenddessen komplexere Tools diese Informationen zur weiteren Verarbeitung
heranziehen können.
4. Letzteres ist insbesondere in der Hinsicht entscheidend, um zusätzliche Informationen bezüglich des Layouts einzelner Element unterzubringen. Dies ist teilweise
sogar notwendig, da bei der Erzeugung von WIF aus HTML im Umgang mit visuellen Stilen standardmäßig relativ rigoros vorgegangen wird, d.h. Stile die über CSSStylesheets oder über zweifelhafte HTML-Tags (wie in 3.2.1.1 schon beschrieben)
definiert wurden, werden einfach ignoriert und entzieht sich somit einer eventuellen
Entscheidungsfindung seitens des Autoren.
5. Des Weiteren sollte jede Seite und auch jedes Archiv von Seiten in UTF-8 [G]
kodiert werden, der doctype sollte XHTML 1.1 und der Titel dem der Wiki-Seite
entsprechen.
Die verwendeten XHTML-Tags entsprechen prinzipiell den im Abschnitt 3.2.1.1 beschriebenen, unterteilt in drei Untergruppen: Links (<a>), Layout (inline-level, wie z.B <i>)
und Struktur (block-level, wie z.B. <p>). Links werden deshalb als gesonderte Untergruppe angesehen, da ihre Unterteilung im Bezug auf Wikis (intern/extern und Links
auf andere Wikis) einer gesonderten Betrachtung bedarf, welcher im Wesentlichen über
unterschiedliche Werte im class-Attribut gedeckt wird.
Das Wiki Archive Format (WAF) zur lokalen Speicherung mehrerer Wiki-Seiten entspricht
dann lediglich der Zusammenfassung der zu archivierenden WIF-Seiten, deren extern
verwendete Dateien (Bilder etc.) und den entsprechenden RDF-Dateien, sowohl seiten- als
auch archivspezifisch, in einer Zip-Archive (ähnlich Javas JAR-Dateien3 oder dem Open
Office Format4 ). Die Links untereinander werden dabei bezüglich der lokal gespeicherten
Dateien korrigiert und ermöglichen es somit innerhalb der Seiten auch offline navigieren
zu können. Die Archivierung einer Seite entspricht dabei immer nur einer bestimmten
Version einer Seite.
Zusammenfassend ergeben sich somit folgende Vorteile bei der Verwendung bzw. Weiterentwicklung von WIF im Bezug auf diese Arbeit und der Nutzung eines vereinheitlichten
Zwischenformats:
3
4
http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html
http://docs.oasis-open.org/office/v1.1/OpenDocument-v1.1.html
3 Analyse
51
1. WIF kann wegen des prinzipiellen modularen Aufbaus von XHTML 1.1 sehr einfach
erweitert bzw. beschränkt und somit individuellen Bedürfnissen angepasst werden
(siehe Abschnitt 4.3 wikiPAGEs“).
”
2. WIF kann wegen der Beschaffenheit von XHTML von XML-Parser bearbeitet
werden, was das Herausfiltern von Information – im Vergleich zu dem WikiSyntax/HTML-Gemisch – wesentlich vereinfacht (siehe Abschnitt 4.4 Autorenum”
gebung“ ).
3. WIF kann direkt in einem Browser dargestellt werden, was im Bezug auf das lokale
Caching von Wiki-Seiten in der Autorenumgebung (4.4.2.4) sehr nützlich ist.
4. WIF kann über XSLT [G] sehr einfach in andere Formate“ übertragen werden,
”
was zum einen bei der Darstellung in z.B. der ursprünglichen Wiki-Syntax (siehe
Abschnitt 4.4.3.2 Informationsextraktion“) und zum anderen bei der Umwandlung
”
der Inhalte in entsprechende Formate einer eLearning-Anwendung sehr hilfreich sein
kann (siehe Abschnitt 4.4.4 Exportmodule“).
”
3.2.2
Integration
In diesem Abschnitt Integration“ von Wikis in externe Anwendungen möchte ich auf
”
die möglichen Schnittstellen seitens der Wikis und die diesbezüglich bereits bestehenden
Lösungsansätze eingehen. Nachdem sich das vorangegangene Unterkapitel (3.2.1) mit der
vereinheitlichten Repräsentation der Inhalte einer Wiki beschäftigt hat, geht es hier nun
um einen einheitlichen Zugriff, um die Inhalte zu extrahieren bzw. um Funktionen der Wiki, wie z.B. das Suchen von Seiten oder das Einloggen als Benutzer, automatisiert nutzen
zu können. Zusätzlich zu meinen eigenen Analysen und den Papern in den entsprechenden Unterabschnitten sind insbesondere die Arbeiten [Vos06] und [Kur06] als Teil meiner
Recherche zu erwähnen.
3.2.2.1
Schnittstellen
Wie bereits in dem Abschnitt ”Wiki Interchange Format (WIF)”(3.2.1.4) vorgestellt, ist
der allgemeinste und direkteste Zugang zu einer Wiki der, welcher auch einem normalen (menschlichen) Benutzer zu Verfügung gestellt wird, nämlich das Anfordern und
Zurücksenden von HTML-Seiten und Formularen. Diese Schnittstelle hat den Vorteil,
dass sie keinerlei Anforderung an die Wiki selber stellt, da das Antworten auf HTTPRequests quasi als Grundfunktionalität aller Webanwendungen angesehen werden kann.
52
3.2 Wiki-Inhalte
Des Weiteren ermöglicht sie somit den Zugang zu allen Funktionalitäten einer Wiki, welche den Benutzern ebenfalls zur Verfügung stehen. Die entscheidenden Funktionen für
diese Arbeit sind dabei:
1. Bedienung der Suchfunktion, sowohl beschränkt auf den Seitentitel, als auch als
generelle Volltextsuche.
2. Anzeigen bzw. Exportieren von Wiki-Seiten im Bezug auf ihren Inhalt und ihren
Metadaten bzw. dem Kontext innerhalb der Wiki (eingehende/ausgehende Links,
Autoren, Version etc.)
3. Einloggen als ein bestimmter Benutzer der Wiki, um auf benutzerspezifische Inhalte
zugreifen zu können.
4. Aufrufen und Nutzen von sonstigen Spezialseiten, um z.B. alle Seiten eines bestimmten Namensraumes aufgelistet zu bekommen, vorhandene Backlinks einer Seite zu extrahieren oder Beobachtungslisten, Statistiken, Dateilisten etc. auswerten
zu können.
Insbesondere für den 2. Punkt, dem Anzeigen und Exportieren von Wiki-Seiten, bieten
die jeweiligen Engines zusätzliche Möglichkeiten. Diese Möglichkeiten unterscheiden sich
im Wesentlichen in ihrem Typ und in der Repräsentation einer Seite, welche im Einzelnen
sind:
1. Die Wiki-Seite wird als direkt renderbare HTML 4.015 bzw. XHTML 1.0 Transitional6 zurückgegeben, was im Bezug auf eine Weiterverarbeitung Vor- und Nachteile mit sich bringt (siehe 3.2.1), aber durchaus als der Standardzugang zu Wikis
angsehen werden kann7 . HTML und XHTML müssen in diesen Versionen – was
ihre maschinenlesbarkeit betrifft – leider noch gleich gesetzt werden, was sich schon
alleine dadurch auszeichnet, dass beide meist unter den MIME-Type8 text/html“
”
gesendet werden.
2. Als Variante des ersten Punkts ist die Ausgabe als valides XHTML 1.19 zu betrachten, welches einen nach vorne gerichteten Dokumenttyp darstellen, der sauber von
”
den missbilligten Altlasten aus HTML 4“ implementiert wurde und somit wesentlich
5
http://www.w3.org/TR/html401/
http://www.w3.org/TR/xhtml1/
7
laut WikiMatrix [Det08] aktuell 66 von 102 Wiki-Engines (Stand: April 2008)
8
klassifiziert die Daten einer Nachricht im Internet
9
http://www.w3.org/TR/xhtml11/
6
3 Analyse
53
leichter zu parsen und zu verarbeiten ist. Allerdings wird dieser Typ im Moment
von nur wenigen Engines unterstützt10 .
3. Die Wiki-Seite wird in ihrer
Rohfassung“ ausgegeben, was im Wesentlichen
”
der Repräsentation in der entsprechenden Wiki-Syntax der Engine entspricht.
Grundsätzlich ist hierbei aber nicht auszuschließen, dass auch Teile von HTMLCode enthalten sind, welche durch den Benutzer oder Plugins eingefügt wurden. Diese Schnittstelle wird in dem übernächsten Unterabschnitt WikiGateway“ (3.2.2.3)
”
näher erläuter.
4. Die Wiki-Seite wird als XML-Datei zurückgeliefert11 , was auf den ersten Blick den
Vorteil mit sich bringen würde, dass die Seite leichter zu verarbeiten wäre und
zusätzlich mit Metainformation und ihrem Kontext versehen werden könnte. Auf de
zweiten Blick allerdings zeigt sich, dass hier die Engines, die offiziell dieses Feature
unterstützen, die Thematik unterschiedlich verstanden und umgesetzt haben. Das
Gerüst“ ist zwar immer eine valide XML-Datei, aber deren interne Daten sind, wie
”
alle anderen Ausgaben der Wiki, ebenfalls nicht standardisiert. So sind die Metadaten unterschiedlich detailliert gegeben bzw. strukturiert oder der Inhalt der Seite ist
wahlweise als Roh- oder HTML-Version enthalten, mal hängen mehrere Versionen
einer Seite an und mal nicht. Somit kann dieser Zugang, abhängig von der WikiEngine, recht komfortabel sein, bedarf aber einer entsprechenden Differenzierung.
Des Weiteren gibt es die Möglichkeit, direkt über die Datenbank bzw. den hinterlegten
Dateien (Wiki-Seiten) auf eine Wiki zuzugreifen, was aber in den meisten Fällen als zu tiefgreifender Eingriff in die jeweilige Engine zu sehen und somit abzulehnen ist. Diesbezüglich
interessanter sind dabei schon bestehende Wiki-APIs wie die hauseigene API der MediaWiki, des VoodooPads oder der TikiWiki (siehe 2.2.2), welche wegen der Beschränkung
auf jeweils eine Engine aber ebenfalls nicht in Frage kommen. Weiter Möglichkeiten ergeben sich aus den Lösungsansätzen von WikiRPCInterface oder DavWiki, welche beide in
den folgenden Abschnitt erläutert werden.
3.2.2.2
DavWiki/WikiRPC
WebDAV [G] ist ein vom Internet Engineering Task Force (IETF) entwickelter Standard
zur Bereitstellung von Dateien im Internet über eine Erweiterung des HTTP-Protokolls.
In dem Paper DavWiki - the next step of WikiRPCInterfaces?“ [Jal05] wird dieser Zugriff
”
10
11
laut WikiMatrix [Det08] aktuell 7 von 102 Wiki-Engines (Stand: März 2008)
laut WikiMatrix [Det08] aktuell 34 von 102 Wiki-Engines (Stand: März 2008)
54
3.2 Wiki-Inhalte
auf serverseitig abgelegten Dateien in Kombination mit Wikis und ihren Inhalten untersucht und erläutert. Insbesondere durch die Verwendung eines internationalen Standards
versprechen sich die Initiatoren Vorteile gegenüber den mehr oder weniger als gescheitert
erklärten Versuchen eines Wiki RPC [G].
Eines der ersten Wiki RPC APIs war das WikiRPCInterface12 . Es basiert auf der XMLRPC API [G] und bietet die Möglichkeit, grundsätzliche Funktionalitäten einer Wiki, wie
das Anfordern einer Seite in HTML oder Wiki-Markup, die Anzeige von Versionen von
Seiten oder die Anzeige der letzten Änderung, in Anwendungen ansteuern und nutzen
zu können. Wie das WikiRPCInterface auch, waren alle weiteren Wiki RPC APIs Implementierungen für einen bestimmten Typ von Wiki, eben jeweils einer Wiki-Engine. So
entstanden zu dem WikiRPCInterface in der ursprünglichen JSPWiki weitere Portierungen für MoinMoin und Twiki bzw. Neuentwicklungen wie die VoodoPadAPI, die TikiWiki
API oder die Special:Export API der MediaWiki-Engine. Diese Vielfalt an Einzellösungen
und Nachteile im Bereich der Kodierung oder dem nur lesenden Zugriff, wenigen Metadaten und keiner Abstraktion des Wiki-Markups, führten dazu, dass sich bis heute keine
Lösung bezüglich eines vereinheitlichten Zugriffs durchsetzen konnte.
Der Ansatz von DavWiki ist es nun, unter der Verwendung des internationalen Standards (WebDAV) einen weiteren Versuch zu unternehmen, einen Engine-unabhängigen
Zugang zu Wiki zu etablieren. Die Seiten einer Wiki werden dabei in einer hierarchischen
Ordnerstruktur – bezogen auf ihren Namensraum – angezeigt und können entweder als
HTML-Dateien oder im ursprünglichen Wiki-Markup geöffnet“ werden.
”
Diesbezüglich werden als Vorteile aufgeführt, dass man z.B. binäre Anhänge in der Wiki (Bild etc.) ebenfalls direkt öffnen, bearbeiten und speichern kann, ohne sie wie zuvor
runter- und hochladen zu müssen. Des Weiteren kann bei einer entsprechenden Importfunktion die Wiki direkt dadurch befüllt werden, indem man bestimmte Dateien in ein
Verzeichnis kopiert bzw. im umgekehrten Fall, dass man eine Wiki durch einfache Synchronisation von Ordnern exportieren kann. In einem weiteren Schritt wäre dann natürlich
generell die Synchronisation zwischen zwei Wikis denkbar.
Als Nachteile eines Zugangs über WebDAV wird genannt, dass die Problematik der unterschiedlichen Wiki-Markups damit immer noch nicht gelöst sei und z.B. ein Synchronisieren
von zwei unterschiedlichen Wiki-Engines natürlich nur funktionieren kann, wenn sich dabei auf ein Format geeinigt werden kann. Das Bearbeiten von Wiki-Seiten über DavWiki
ist ebenfalls problematisch, da eine funktionierende Kollisionsbehandlung, wenn gerade
zwei Benutzer auf eine Datei zugreifen, nicht ohne Weiteres umgesetzt werden kann. Hinzu
kommen Probleme bezüglich der Performance, da ein Namensraum potenziell sehr viele
Seiten beinhalten kann, was zwangsläufig zu sehr großen XML-Nachrichten führt. Des
12
http://www.jspwiki.org/wiki/WikiRPCInterface
3 Analyse
55
Weiteren wird der WebDAV Standard von unterschiedlichen Clients verschieden interpretiert was dazu führt, dass diese sich dementsprechend unterschiedlich verhalten.
3.2.2.3
WikiGateway
WikiGateway ist eine Sammlung von Open-Source-Implementationen zur automatischen
Interaktion mit unterschiedlichsten Wiki-Engines [Sha05]. Die in Python und Perl programmierten Module stellen dementsprechend Funktionen zur Verfügung, wie z.B. getPage, putPage oder getRecentChanges, um sowohl lesend als auch schreibend auf Wikis
zugreifen zu können. Diese Funktionalitäten können sowohl clientseitig über Bibliotheken
oder einem Command-Line-Tool verwendet werden, als auch serverseitig über standardisierte Protokolle, wie WebDAV, Atom oder den in 3.2.2.2 erwähnten APIs WikiRPCInterface oder XML-RPC. Allerdings wird in dem Paper eindeutig auf die Vorteile einer clientseitigen Implementation und Nutzung der Bibliotheken hingewiesen, welche es
ermöglichen würde, in einer lokalen Desktop-Anwendung völlig neue UIs und Featuresets
für Wikis zu entwickeln, unabhängig von den zugrunde liegenden Wiki-Engines.
WikiGateway fokussiert sich dabei auf die Lösung der Problematik des unterschiedlichen
Zugriffs auf eine Vielzahl von Wiki-Engines (ob lesend oder schreibend) und distanziert
sich zunächst von dem zweiten entscheidenen Faktor, welcher es letztendlich ermöglichen
würde, Inhalte zwischen unterschiedlichen Wiki-Engines beliebig austauschen zu können,
der Vereinheitlichung von Wiki-Markups.
Technisch behandelt WikiGateway die Besonderheiten der jeweiligen Wiki-Engine in so
genannten Wiki-Drivern. Diese und auch alle anderen Kernfunktionalitäten wurden in
einem Python-Modul implementiert, auf denen alle anderen Funktionen direkt oder indirekt zurückgreifen. Jeder Wiki-Driver entspricht einer Klasse, deren Objekt über zwei
Attribute (URL und Wiki Identifier) instanziiert werden und jeweils einer konkreten Wiki entsprechen. Diese Objekte stellen dann wiederum Methoden zur Verfügung, deren
Ansteuerung und Ergebnisse einheitlich von dem Perl-Modul (Wiki::Gateway) verwendet
werden können. Diese dienen als Wrapper und ergänzt das Python-Modul um zusätzlichen
Funktionalitäten. Fehler, die bezüglich der Verbindung, dem Editieren oder bei Kollisionen
auftreten, werden dabei schon in dem entsprechenden Driver abgefangen und standardisiert weitergereicht.
Interessant sind auch die eher kritischen Erwähnungen im Bezug auf einen zentralen
Zugang zu mehreren Wikis. So wird z.B. ein erhöhtes Sicherheitsrisiko genannt, da der
Zugriff ja auch potenziell eher ungewollten Benutzern zur Verfügung steht, Wiki- oder
Spam-Bots. Des Weiteren wird darauf hingewiesen, dass bestimmte Funktionen in einer
Wiki auch sinnvollerweise nicht leicht und einfach zugänglich sind, wie z.B. das Löschen
56
3.3 eLearning-Kurse
aller Seiten, was sich über WikiGateway und den entsprechenden Rechten relativ leicht
umsetzen ließe. Auch werden eventuelle negative Einflüsse bezüglich bestehender oder
entstehender Communities genannt, da z.B unterschiedliche UIs den Teilnehmern auch
unterschiedliche Sichten auf die Inhalte ihrer Wiki bieten könnten, was in einer Gemeinschaft nicht unbedingt förderlich ist.
3.3
eLearning-Kurse
Aus der Definitionen von eLearning und deren Anwendungen in den Abschnitten 2.3 bzw.
2.3.1 ergibt sich folgende Definition eines eLearning-Kurses im Kontext dieser Arbeit:
Ein eLearning-Kurs ist eine inhaltlich und technisch geschlossene Lerneinheit, welche unter dem Einsatz von digitalen Medien, die Lehre im Allgemeinen unterstützt bzw. ermöglicht. Diese Lerneinheiten können wiederum in
kleinere Einheiten unterteilt sein (z.B. Lektionen), wodurch sich hierarchische
Strukturen innerhalb des Kurse bilden können, deren kleinste Elemente die
Kurs-Seiten sind. Die eLearning-Anwendung erlaubt es nun. durch diese Inhalte zu Navigieren bzw. generell mit dem Kurs zu Interagieren. Interaktion
in eLearning-Kursen können sich sowohl auf Seiten (z.B Frageseiten oder Animationen), als auch auf den gesamten Kurs beziehen (dynamische Navigation,
Timer etc.).
Um später genau bestimmen zu können, an welchen Stellen des eLearning-Kurses man Informationen – extrahiert aus Wikis – einfließen lassen kann bzw. generell verwenden kann,
folgt in dem nächsten Abschnitt eine einsprechende Aufschlüsselung und Benennung.
3.3.1
Struktur und Layout
Ein – wie im vorherigen Unterabschnitt 3.3 definierter – eLearning-Kurs lässt sich
zunächst in drei Kategorien von möglichen Informationen unterteilen, den Metadaten (1),
dem eigentlichen Inhalt und dessen visuelle Repräsentation (2) und der Strukturierung
des Inhalts innerhalb des Kurses (3). Im Bezug auf vorzugsweise auf Internettechno”
logien basierende Kursinhalte“ aus dem Abschnitt 2.3.1 bedeutet dies in den meisten
Fällen eine Umsetzung der Inhalte in HTML [G] bzw. XHTML [G], angereichert mit den
entsprechenden Meta-Informationen im Header oder in separaten RDF-Dateien. Die Beschreibung der Struktur des Kurses liegt dabei z.B. in XML [G] vor. Die drei Bereiche
beinhalten im Einzelnen:
3 Analyse
57
Die Metadaten beziehen sich meist auf die gesamte Lernheiten und beantworten
zunächst folgende Fragen: Was ist der Inhalt des Kurses? Wann und von wem wurde der Inhalt erstellt? Wie gliedert sich der Kurs im Bezug auf andere vielleicht
übergeordnete Lerneinheiten ein?
Des Weiteren werden Informationen für die eLearning-Anwendung zur Verfügung
gestellt, wie Versionsnummer, Sprache oder Status des Kurses, welche von dann
interpretiert und ausgewertet werden können. Auch sind Informationen über didaktische Ziele oder Einordnungen in entsprechende Einsatzszenarien denkbar.
Der Seiteninhalt eines eLearning-Kurses kann wiederum in kleine Unterbereiche zerlegt
werden. Diese können Grafiken, Animationen oder z.B. Videos sein bzw. einfache
Texte z.B in der Form eines Paragraphen oder einer Tabelle. Jedes dieser Elemente
kann wiederum mit unterschiedlichen interaktiven Möglichkeiten verbunden sein,
wie z.B Multiple-Choice oder Textfragen, Bilder Quizze, steuerbare Animationen
oder Videos mit didaktischen Stops. Die Interaktionen müssen ebenfalls beschrieben
und mit Informationen hinterlegt werden, welche aber in der Regel nicht direkt
sichtbar sind (z.B. Antwortmöglichkeiten oder entsprechende Wertungen).
Insbesondere im Kontext von Internettechnologien“ spielt dementsprechend auch
”
die Verlinkung der Seiten und Seitenelemente untereinander eine große Rolle. Denn
unabhängig von der Einordnung der Seiten in die gesamte Kursstruktur (nächster
Punkt) kann gerade hier zusätzlich eine gewisse Dynamik und Vielfalt entstehen
und somit den Lerneffekt eines eLearning-Kurses enorm beeinflussen.
Die Kursstruktur beschreibt die Anordnung und Zuordnung der Seiten innerhalb eines
Kurses. So wird z.B. definiert, in welchen Verhältnis die Seiten stehen (Seite, Unterseite, Erweiterung, Ergänzung etc.) oder wie Seiten kategorisiert werden können
(Kapitel, Lektion, Kategorie oder Gruppe). Entscheidend sind an dieser Stelle auch
die Zuordnung entsprechender IDs der Seiten und deren Elemente, um sich bei Links
oder Interaktionen eindeutig auf diese beziehen zu können.
Im Bezug auf die zu entwickelnde Autorenumgebung müssen natürlich alle drei Kategorien
beachtet und bedient werden. Betrachtet man die eigentlichen Inhalte und insbesondere
denen aus Wikis, konzentriert sich dies dementsprechend in der zweiten Kategorie, dem
eigentlichen Seiteninhalt. Je nach Einsatzszenario und Verwendung der Wiki können aber
auch Informationen bezüglich der Stuktur (Links in Wiki-Seiten, Kategorien etc.) und den
Metadaten (z.B. Statistiken oder Informationen über jeweilige Autoren von Wiki-Seiten)
extrahiert werden.
58
3.3 eLearning-Kurse
3.3.2
Standardisierungsversuche
Aufgrund der ständig steigenden Anzahl an unterschiedlichen Lernplattformen und Autorensystemen und der bereits beschriebenen Trennung von dem Lernsystem und Lehrinhalt
(2.3.1) werden immer häufiger Versuche unternommen, die Inhalte, dessen Anordnung,
Interaktion und Navigation zu standardisieren. Die drei bekanntesten Gremien bzw. Initiativen und ihre Lösungsansätze sind dabei:
• Institute of Electrical and Electronics Engineers (IEEE) und ihrer Spezifikation vom
Learning Object Metadata (LOM) oder SMIL
• Instructional Management System - Global Learning Consortium (IMS) mit dem
Learning Design (LD)/Content Packaging (CP) bzw. Question & Test Interoperability (QTI)
• Advanced Distributed Learning (ADL) mit der Sammlung und Spezifikation mehrerer Standards SCORM
Alle aufgelisteten Standards basieren auf der vom W3C13 spezifizierten Auszeichnungssprache Extensible Markup Language (XML)14 , welche es ermöglicht, Daten strukturiert
und hierarchisch in Form von lesbaren Textdateien abzuspeichern. Durch Schemasprachen
wie Document Type Definition (DTD) und XML-Schema lassen sich anwendungsspezifische Einschränkungen beschreiben, um wiederum weitere XML-Sprachen, wie z.B. die
oben aufgelisteten, zu definieren. Weshalb XML auch als Metasprache bezeichnet wird.
Durch die Standardisierung erhofft man sich, einmal erstellte eLearning-Inhalte in unterschiedlichen Plattformen einsetzen zu können bzw. untereinander auszutauschen und
ohne größere Anpassungen weiterentwickeln zu können [Paa04].
3.3.2.1
IMS CP/LD und QTI
IMS haben seit 1999 eine Fülle an frei verfügbaren Spezifikationen veröffentlicht. Eine
davon ist das 2003 verabschiedete LD15 . Dabei handelt es sich um Sprache zur formalen
Beschreibung von Lerneinheiten im Fokus didaktischer Aspekte, insbesondere den Rollen,
Beziehungen, Interaktionen und Aktivitäten von Lernenden und Lehrenden. Als Teil einer
Manifest-Datei, welche zusätzlich Metainformationen und Angaben zur Beschreibung der
13
http://www.w3.org/
http://www.w3.org/TR/xml/
15
http://www.imsglobal.org/learningdesign/index.html
14
3 Analyse
59
eigentlichen Inhalte (Ressourcen) einer Lerneinheit sowie die Inhalte selber beinhaltet,
ergibt sich eine weitere Spezifikationen, die des IMS CP16 .
Bild 3.6: IMS Content Packaging (prinzipieller Aufbau) [Paa04]
Eine weitere Spezifikation, etwas spezieller in der Anwendung, ist QTI17 . Diese wurde
speziell zur Beschreibung der Daten im Kontext von Online-Fragen-Kataloge, Quizzes
und Multiple-Choice-Tests inklusive ihrer Antworten und Auswertung entwickelt.
Sowohl QTI als auch CP sind somit geeignete Kandidaten bei der einheitlichen Speicherung von Inhalten im Zusammenhang mit Wikis. Denkbar sind Online-Fragen im Anschluss einer Veranstaltung, welche sich im Autorenprozess direkt auf die Inhalte aus den
begleitenden Wikis bezieht. Oder ein generelles Verpacken von mehreren wikiPAGEs,
inklusive der verwendeten Medien.
3.3.2.2
IEEE LOM/SMIL
Zur Beschreibung von Metadaten eines Lernobjekts, welches nicht zwangsläufig digital sein
muss, entwickelte das IEEE 2002 die Spezifikation des LOM. Mit deren Hilfe kann man
in neun definierten Unterkategorien im Basis-Schema Informationen beschreiben, wie z.B
technische Voraussetzungen, Autoren, Rechtliches oder Beziehungen zu anderen Objekten
einheitlich. Die Kategorien sind im Einzelnen, wobei jede wiederum untergliedert ist:
• General: Allgemeine und grundlegende Informationen des Lernobjekts.
• Lifecycle: Status und Entwicklungsgeschichte auch im Bezug auf andere Objekte.
16
17
http://www.imsglobal.org/content/packaging/index.html
http://www.imsproject.org/question/
60
3.3 eLearning-Kurse
• Meta-Metadata: Angaben zu den Metadaten des Lernobjekts.
• Technical: Technische Merkmale und Voraussetzungen.
• Educational: Beschreibung des Lernobjekts im Bezug auf Bildung und Pädagogik.
• Rights: Nutzungsbedingungen und Angaben zum Copyright.
• Relation: Beschreibung der Beziehungen zwischen den Lernobjekten.
• Annotation: Kommentare zum Nutzen im Sinne der Lehre.
• Classification: Einordnung im Kontext eines Fachgebiets.
Im Gegensatz zum LOM beschreibt SMIL18 nicht die Metadaten einer Lerneinheit, sondern bezieht sich direkt auf die Inhalte, ihre Anordnung und ihr zeitliches Verhalten.
Somit wird es meist bei multimedialen Präsentationen eingesetzt, welche aus einer Anzeige von zeitsynchronen Medien, wie z.B. ein Video eines aufgezeichnete Vortrags und den
entsprechenden Folien einer Powerpoint-Präsentation. Ein Beispiel für den Einsatz von
SMIL ist LECTURNITY19 .
Wichtige und durch SMIL abgedeckte Kriterien diesbezüglich sind:
• das Layout kann direkt in SMIL zur besseren Integration angepasst werden
• zeitabhängige Anzeige von einzelnen Elementen (Absätze, Bilder, Seiten)
• es ist ein offener Standard
• bezüglich der Anzeige von Elementen kann die zur Verfügung gestellte Bandbreite
reguliert werden
• Inhalte können sprachabhängig angeboten werden
• eingebundene Medien können referenziert werden, was eine Live-Anzeige von WikiInhalte möglich macht
Im Bezug auf die Nutzung von Wiki-Inhalten ist insbesondere SMIL in Kombination mit
WikiPaths (4.4.5.1) interessant, um z.B. einen durchlaufenden Pfad innerhalb einer Wiki
beschreiben und anzeigen zu können. Auch die Verwendung von LOM bei der Angabe
von Metainformationen hat durch den deutlichen Fokus auf eLearning-Inhalte durchaus
18
19
http://www.w3.org/TR/SMIL2/
http://www.lecturnity.de/
3 Analyse
61
Vorteile gegenüber allgemeineren Lösungen wie z.B. dem Dublin Core (DC). Und im
Vergleich zu einem eigens definierten Satz an Metainformationen sorgt LOM für eine
generelle Vereinheitlichung aller Lehrinhalte und somit auch bei der Speicherung von
wikiPAGEs-Projekten. Insbesondere als Ergänzung zum IMS CP bietet sich diesbezüglich
eine Verwendung an.
3.3.2.3
SCORM
SCORM ist in diesem Sinne eigentlich gar keine Spezifikation, sondern lediglich eine Ansammlung und Vereinigung von schon Bestehendem und Etabliertem. Zusammengetragen
und Ausgearbeitet von ADL, eine 1997 gegründete Initiative des Department of Defense
(DoD) und dem Office of Science and Technology Policy (OSTP), besteht es im Wesentlichen aus drei Teilen:
Content Aggregation Model (CAM): Beschreibt die eigentliche Zusammenfassung
und Strukturierung der Lehrinhalte. Metadaten werden dabei in dem bereits beschriebenen IEEE LOM angegeben und abgespeichert anhand der Spezifikation des
IMS CP. Zusätzlich werden hier das beabsichtigte Verhalten im Bezug auf die Erfahrung der Lehrinhalte und eine Menge von Regeln zur Einordnung und Abfolge
von Aktivitäten.
Run-Time Environment (RTE): Beschreibt das laufzeitbezogene Verhalten eines
LMS, die Schnittstelle vom LMS zu den in CAM spezifizierten Lernpaketen definiert in einer API, die Verwendung von Benutzerdaten zur Laufzeit sowie dem
Starten von SCORM Content Objects (SCO) und Assets und dem zugrundeliegendem Datenmodell.
Sequencing and Navigation (SN): Beschreibt anhand von Aktivitätenbäumen die
mögliche Reihenfolge der Präsentation von Lerninhalten in Abhängigkeit von Benutzeraktionen innerhalb der Navigation.
Somit kann SCORM als durchaus geeigneter Kandidat, als allgemeines Export-Modul
(4.4.4) der Autorenumgebung und als standardisierte Weitergabe von Inhalten, sei es als
fertige eLearning-Kurse oder bloße Rohdaten, angesehen werden. SCORM vereinigt die in
den beiden vorangegangen Abschnitten erläuterten Aspekte und bietet dementsprechend
eine gewisse Vielfalt und Allgemeingültigkeit im Sinne eines Standards. Eventuell ist es
jedoch gerade deshalb an mancher Stelle etwas zu umfangreich, was wiederum von Fall
zu Fall entschieden werden muss.
Kapitel 4
Konzept
Auf der Basis der vorangegangen Analysen im Bezug auf den Einsatz von Wikis im eLearning, den allgemeinen und speziellen Anforderungen einer Autorenumgebung und technischen Gegebenheiten wird hier nun mein daraus abgeleitetes Konzept beschrieben. Das
Kapitel beginnt mit den Schlussfolgerungen aus dem Analyse-Kapitel und dem entsprechenden allgemeinen Lösungsansatz“ (4.1) und einer prinzipiellen Unterteilung in kleine”
re Teilaufgaben zur Lösung der Problematik: Entwicklung einer Autorenumgebung zur
”
Erstellung von eLearning-Kursen aus Wiki-Inhalten“.
Die drei wichtigsten Teilbereiche nach der allgemeinen Beschreibung des Lösungsansatzes
sind hierbei:
1. Die Konzeption einer API“ (4.2) zur einheitlichen Ansteuerung von unterschiedli”
chen Wikis
2. Eine harmonisierten Repräsentation von Wiki-Inhalten wikiPAGEs“ (4.3) zur ein”
heitlichen Weiterverarbeitung und Speicherung.
3. Und die eigentliche Autorenumgebungen“ (4.4), welche auf den beiden vorherigen
”
Abschnitten aufsetzt.
4.1
Lösungsansatz
Wie im Abschnitt 3.1.4 der Zusammenfassung und Beurteilung von Autorenprozessen und
-umgebungen im Bezug auf Wikis und eLearning-Software bereits beschrieben, liegt die
Qualität einer Autorenumgebung für Lehrende im Umgang mit Wikis in der Zuschreibung
einer exklusiven Rolle bezüglich des Zugriffs und der Aufarbeitung von Inhalten. Dieses
64
4.1 Lösungsansatz
Privileg sollte es den Lehrenden dann ermöglichen, insbesondere noch während des Einsatzes einer Wiki, bei Aktionen und Reaktionen bezüglich der Vorgänge, der Entstehung
von Inhalten und der Inhalte selber gegenüber den Lernenden einen gewissen Vorsprung
zu erhalten.
Um diesen Vorsprung“ von Grund auf bedienen zu können, ist es zunächst notwendig,
”
dem Lehrenden eine abstrakte Sicht auf die eingesetzten Wikis zu ermöglichen, um ihn von
den Details technischer Einzellösungen (2.2.1) und zeitaufwendigen Recherchen nach Inhalten (3.1.4) in unterschiedlichen Wikis zu befreien. Diese Sicht wird dem Lehrenden konkret in der Einrichtung und Verwaltung eines Wiki-Pools (4.4.2.3) zur Verfügung gestellt,
in dem er beliebig viele Wikis, unabhängig ihrer zugrunde liegenden Engine (2.2.2), einbinden kann. Technisch wird dies über eine zugrundeliegende API (4.2) realisiert, welche
über einen Webservice (siehe 4.2.5 Schnittstellen“), es generell Anwendungen ermöglichen
”
soll, einheitlich auf unterschiedliche Wikis zugreifen zu können. Entscheidend waren dabei die Untersuchungen im Abschnitt 3.2.2, welche sich mit der Integration“ von Wikis
”
auseinandergesetzt haben.
Nachdem nun einzelne Wiki-Seiten einheitlich angefordert werden können, bleibt die unterschiedliche Repräsentation jeder Seiten selber. Diese Unterschiede oder wie im Abschnitt 3.2.1.3 beschrieben, das allgemeine Wiki Markup Mess“, müssen neben dem tech”
nischen Zugang als zweiter wichtiger Teil der API ebenfalls behandelt bzw. vereinheitlicht
werden. Im Wesentlichen findet hier eine strikte Trennung von Inhalt und Layout, unter
der Berücksichtigung vieler Einzellösungen statt, welche im Zweifel durchgereicht und als
Hinweise“ dem Autoren zu Verfügung stehen. Aufgrund des größeren Umfangs und der
”
prominenten Rolle als letztendliche Schnittstelle zwischen der Menge an Informationen
in unterschiedlichen Wikis und der Anwendungen, die diese nutzen möchten, wird dies in
einem extra Abschnitt wikiPAGEs“ (4.3) behandelt, dessen Titel stellvertretend für das
”
gesamte Konzept und für den Namen der Autorenumgebung steht.
Die Autorenumgebung selbst (4.4), welche dann auf der API aufsetzt und dadurch von
der harmonisierten Schnittstelle und der einheitlichen Seiten-Repräsentationen direkt profitiert, bildet somit zunächst einmal ein User Interface (UI), welches die grundlegenden
Funktionen der API und des wikiPAGEs-Formats bedient. Das UI sollte prinzipiell dem
einer durchschnittlichen Wiki (2.2.1.3) nachempfunden sein, um dem Autoren – trotz all
der Abstraktion – das nötige visuelle Feedback geben zu können. Alle weiteren Funktionen
der Autorenumgebung lassen sich konzeptuell in zwei Bereiche gliedern. Im ersten Bereich
werden die Basisfunktionen“ (4.4.2) beschrieben, welche nur indirekt den Autor und so”
mit den Autorenprozess unterstützen. Diese sind, neben den schon genannten wie das UI
oder die Bedienung der API, eine Unterstützung von Benutzer und Benutzergruppen, die
Umsetzung des Wiki-Pools“ und das allgemeine Caching von Seiten und Anfragen. Im
”
4 Konzept
65
zweiten Bereich, behandelt in dem Abschnitt Authoring“ (4.4.3), geht es dann um den
”
Autorenprozess an sich und der Abbildung auf die Umgebungen. Hier wird beschrieben,
wie letztendlich auf Basis zur Verfügung gestellter Export-Module“ (4.4.4) neue Seiten
”
erzeugt und diese dann mit der Unterstützung der in den wikiPAGEs enthaltenen Informationen bezüglich des Inhalts, des Layouts und des Kontexts einer Seite bearbeitet
bzw. befüllt werden können. Im Export an sich werden dann die Seiten auf die jeweiligen
Navigations-Metaphern 2.3.2 der zugrunde liegenden eLearning-Anwendung automatisch
abgebildet bzw. semi-automatisch von den Autoren zugeordnet und in das entsprechende
Format transformiert.
Bild 4.1: Überblick des Lösungsansatzes
Somit besteht der konkrete Mehrwert des Einsatzes von wikiPAGEs und der anfangs
erwähnte privilegierte Zugang für Autoren zum einen in einem vereinheitlichten Autorenprozessen bei der Nutzung unterschiedlicher Wiki-Systeme und zum anderen in der
effizienteren Auswertung, Aufbereitung und Wiederverwendung von Wiki-Inhalten, und
das nicht nur im Bezug auf eine konkrete eLearning-Software.
66
4.2
4.2 API
API
Die API als Schnittstelle zwischen den zu verwendenden Wikis und der Anwendung,
welche die Inhalte der Wiki vereinheitlicht verwenden sollen, müssen also – wie zuvor
beschrieben – an zwei Punkten ansetzen: dem technischen Zugang zur Wiki und der Repräsentation einer Wiki-Seite und deren Kontext. Auf beides wurde in den Abschnitten 3.2.1 und 3.2.2 des Analyse-Kapitels eingegangen und entsprechende existierende
Lösungsansätze untersucht. Unter der Beachtung meiner Ansprüche als Grundlage für
die Autorenumgebung ist jedoch keiner der Lösungsansätze vollständig und löst somit
lediglich einen Teil der Problematik.
Aufgrund der ständig wachsenden Anzahl von Wiki-Engines und deren rasanten Weiterentwicklung ist es jedoch ratsam, um stets mit der Entwicklung schritthalten zu können,
bestehende Communities zu unterstützen und von deren Arbeit zur Lösung der Problematik der heterogenen Koexistenz von Wikis zu profitieren. Hinzu kommt, dass der inhärente
Widerspruch bei einer Vielzahl von Lösungen zur Vereinheitlichung (selbst wenn jede für
sich genommen sehr gut und auch nützlich sein mag), gerade das Gegenteil bewirkt und
somit ad absurdum geführt wird, wie es bei Open-Source-Projekten öfters der Fall ist,
da eine höhere Instanz zur Bestimmung allgemeiner Richtlinien fehlt bzw. sicherlich aus
guten Gründen ignoriert wird.
Somit ergibt sich für mich und meinen Ansatz einer generellen Wiki-API eine Lösung,
welche mehrere von diesen Ideen aufgreift, um von eventuellen Etablierungen seitens der
Communities zukünftig zu profitieren bzw. zu unterstützen. Diese Ideen werden dann anhand meiner Ansprüche kombiniert und erweitert, um somit meinen Teil zur einheitlichen
Nutzung von Wiki-Inhalten zu leisten und nicht nur auf die konkrete Anwendung in der
Autorenumgebung fixiert zu sein.
4.2.1
Die Komponenten der API
Die zentrale Idee und somit wichtigste Komponente der API im Bezug auf den einheitlichen Zugriff auf harmonisierte Wiki-Inhalte ist die Verwendung eines Zwischenformats
seitens der Ausgabe einzelner Wiki-Seiten, den wikiPAGEs (4.3). Diese entsprechen (vom
Ansatz her) dem (im Abschnitt 3.2.1.4 analysierten) WIF bzw. WAF, welches genau für
diesen Zweck (einer engineunabhängigen Speicherung von Wiki-Inhalten) konzipiert wurde. D.h. Seiten, beschrieben in den unterschiedlichsten Wiki-Syntaxen, sollen sowohl in
das WIF-Format exportiert bzw. aus dem Format heraus wieder in eine andere Wiki
(Wiki-Syntax) importiert werden können. Das Problem dabei ist, dass durch den Ansatz,
die Inhalte in beide Richtungen transformieren zu wollen, soweit von den jeweiligen Be-
4 Konzept
67
sonderheiten der einzelnen Wiki-Engines im Rahmen dieser Arbeit natürlich insbesondere
Engines mit dem Fokus auf die Lehre (siehe z.B. UniWakka, Ed.wiki in 2.2.2) abstrahiert
werden müssen, dass eventuell entscheidende Informationen für den Lehrenden (bzgl. des
Layouts und der visuellen Stile) verloren gehen können. Deshalb muss an dieser Stelle
das WIF dahingehend erweitert werden, eventuell nicht einwandfrei zuordnungsbare Informationen durchreichen zu können, welche von der Autorenumgebung bzw. dem Autoren dann differenziert ausgewertet werden können. Dies führt unter Umständen eventuell
dazu, dass Inhalte in dem gespeicherten wikiPAGEs-Format nicht vollständig in eine gegebene Wiki-Syntax zurücktransformiert werden können, weshalb die API lediglich lesend
auf die Inhalte von Wikis zugreift. Dies ist jedoch angesichts der analysierten Anforderung
der Autorenumgebung im Bezug auf Wikis im Abschnitt 3.1 auch nicht notwendig, da der
dort definierte Autorenprozess ausserhalb der Wiki stattfindet und die Produktion von
Inhalten weiterhin über die jeweilige Wiki mit ihren speziellen Vorteilen geschieht. Die
Ausarbeitung von wikiPAGEs folgt aufgrund der Prominenz, in einem entsprechenden
ausgegliederten Unterkapitel 4.3.
Bild 4.2: Komponenten der API
Die zweitwichtigste Komponente, die der Eingabe, basiert auf zwei Ideen aus der Analyse
und zwar zum einen der Vereinheitlichung der Wiki-Markup im Sinne des WikiCreoleProjekts (3.2.1.3) und zum anderen dem Prinzip des Zugriffs vom WikiGateway (3.2.2.3)
68
4.2 API
auf der Basis von modularisierten “Wiki-Drivern bzw. entsprechend meiner API den
”
Wrappern“. Während ersteres weitestgehend komplett übernommen wurde, beschränkt
”
sich der Aufgriff des Ansatzes von WikiGateway im Wesentlichen nur auf die Auslagerungen von extern programmierbaren Modulen (im besten Fall von den jeweiligen Entwicklern einer Wiki selber), um Anpassungen und Ergänzungen seitens der potentiell
einsetzbaren Wikis möglichst überschaubar und abgegrenzt von der API stattfinden zu
lassen. Prinzipiell unterscheiden sich die Wrapper von den WikiGateway-Drivern in der
Art des Zugriffs, bedingt durch unterschiedliche Anforderung und den Transformierung
bezüglich der jeweiligen Wiki-Syntax, wovon sich das WikiGateway-Projekt gezielt abgegrenzt hat. Meine grundsätzliche Idee ist diesbezüglich, die API bereits von der nötigen
Unterscheidung vieler differenzierter Wiki-Markups zu befreien und stattdessen eine einheitlich verarbeitbare Syntax zu liefern. Ausschlaggebend war dabei die Tatsache, dass der
standardisierten Wiki-Syntax des WikiCreole-Projekts immer mehr Anerkennung und Beachtung geschenkt wird, was sich dies – unter anderem – dadurch abzeichnet, dass immer
mehr Engines zusätzlich zu ihrer Syntax einen Export im WikiCreole-Markup anbieten.
Dies lässt den Aufwand zukünftig implementierter Wrapper natürlich drastisch fallen, da
die Information (in diesem Punkt) lediglich zur API durchgereicht werden muss. Einzelheiten diesbezüglich und weitere Details der Wrapper werden im nächsten Abschnitt 4.2.2
behandelt.
Bleibt die dritte und letzte Komponente der API (siehe Bild 4.2), die Überführung einer
Wiki-Seite aus dem Wrapper in das wikiPAGEs-Format, dem Parser [G]. Während alle
Informationen, die den Kontext einer Seite bzw. ihre Metadaten oder sonstige Funktionen
der Wiki (Login, Suchen, Listen etc.) betreffen, weitestgehend von den Wrapper erledigt
bzw. vorbereitet werden und somit lediglich von der API weitergereicht werden müssen,
bleibt die Aufarbeitung des Inhalts einer Seite und die Überführung in das (auf XHTML
und CSS) basierte wikiPAGEs-Format als kritisch zu erachtender Punkt. Kritisch deshalb, da nur im besten und auch seltensten Fall (siehe Abschnitt 3.1.3) eine Seite in
einem sauberen“ Zustand bezüglich ihrer Syntax vorliegen wird. In der überwiegenden
”
Mehrzahl der Seiten werden Inhalte vorhanden sein, welche z.B. über Plugins in der Wiki
eingefügt wurden (2.2.2) und somit nicht oder nur schwer interpretierbar sind. So können
Inhalte zwar syntaktisch korrekt sein aber jedoch semantisch falsch sein. Dies kann z.B.
dann der Fall wenn Benutzer Layout-Elemente zweckentfremdet haben bzw. generell zur
Gestaltung der Seite gänzlich auf HTML umgestiegen sind (3.1.3). Diese Punkte gilt es
abzufangen und möglichst nutzbringend und interpretierbar an den Autoren weiterzuleiten.
4 Konzept
4.2.2
69
Wrapper
Wie zuvor beschrieben, basieren die Wrapper prinzipiell auf der Idee der Wiki-Driver“
”
des WikiGateway-Projekts (3.2.2.3). D.h. externe Module, weitestgehend unabhängig von
der API implementierte Abstraktionen der jeweiligen Wiki-Engines mit all ihren Besonderheiten auf der einen Seite und eine standardisierte Repräsentation dessen auf der anderen Seite. Durch die gezielte Verwendung der Wikis als Sammlung von Inhalten und der
Aufbereitung in einer entsprechenden Autorenumgebung zur Erstellung von eLearningKursen ergeben sich folgende Anpassungen.
• Es werden mehr Funktionalitäten von der Wiki abverlangt, als dies bei WikiGateway
der Fall ist (Login, Suchen, Auflistungen etc.), d.h. der Zugriff beschränkt sich nicht
nur auf einzelne Wiki-Seiten, sondern muss auch Wiki-typische Aufgaben (2.2.1)
adaptieren und an die Autorenumgebung weitergeben können.
• Der Ansatz, die Wiki-Seiten über die jeweilige Editierfunktion einer Wiki zu erhalten, ist insofern gut, da somit keinerlei Vorraussetzungen an die Wiki gestellt
werden. Hinzu kam bei WikiGateway die diesbezügliche Notwendigkeit, da (wie bei
WIF ebenfalls angedacht) der Anspruch besteht, nicht nur lesend, sondern auch
schreibend auf eine Wiki zugreifen zu wollen. Allerdings ist dies (wie bereits beschrieben) bezüglich einer Autorenumgebung zur Weiterverwendung von Inhalten,
die in der Wiki entstanden sind, nicht nötig, womit ein Zugriff über eine XMLSchnittstelle (3.2.2.1) wesentlich komfortabler ausfällt und diese – mittlerweile – als
Funktionalität unter den Wiki-Engines weit verbreitet ist1 .
• Der größte und somit entscheidendste Unterschied ist jedoch, dass nicht nur der
Zugriff vereinheitlicht wird, sondern auch vorbereitend der Inhalt im Bezug auf seine Syntax, was WikiGatway ganz klar nicht zu seiner Aufgabe erklärt. Wichtig ist
in diesem Zusammenhang, dass die Wrapper sich nicht komplett mit der Harmonisierung der Seite beschäftigen müssen, da diese durchaus komplexe Aufgabe (wie
bereits beschrieben) von der 3. Komponenten der API erledigt wird. Eine Harmonisierung findet nur bezüglich der Wiki-Syntax statt, was an dieser Stelle auch sinnvoll
ist, da man die Wiki-spezifische kennt und relativ einfach und widerspruchsfrei durch
eine allgemein gültige ersetzen kann. Diese allgemein gültige, ist die Wiki-Syntax
des WikiCreole-Projekts, was wiederum den Vorteil bietet, wenn die Wiki bereits
diese Syntax unterstützt2 (meist optional und zusätzlich zur eigenen), der Wrapper
nicht einmal mehr diese relativ einfache Transformation vornehmen muss. Die API
1
2
laut WikiMatrix [Det08] aktuell 34 von 102 Wiki-Engines (Stand: März 2008)
laut WikiMatrix [Det08] aktuell 13 von 102 Wiki-Engines (Stand: März 2008)
70
4.2 API
bleibt in beiden Fällen völlig unberührt und profitiert lediglich von einer wachsenden
Anzahl an Wrapper, da die Implementierung zunehmend an Komplexität verliert.
Wie genau die Funktionen der Wrapper nun aussehen müssen, welche Wiki-Schnittstellen
wie bedient werden und wie das Format zur Übergabe an die API spezifiziert ist, wird in
den folgenden Unterabschnitten beschrieben.
4.2.2.1
Funktionen
Die Funktionen der Wrapper lassen sich bezüglich ihrer Einsatzgebiete in zwei Kategorien
einteilen. Die wichtigste Kategorie (1) bezieht sich auf das Beschaffen des eigentlichen
Inhalts einer Seite und den technisch notwendigen Funktionen zur Verwendung der Wiki
(Tabelle 4.1).
Tabelle 4.1: Funktionen des Wrappers: Kategorie 1
Funktion
Ergebnis
getPage(id)
XML-Version
search(keyword)
Beschreibung
einer
Entspricht einer Suche nach dem
Seite im WikiCreole-
Seitentitel und gibt diese bzw.
Markup
null entsprechend zurück
Liste der entsprechen-
Sucht
den Seitennamen
Schlagwort und gibt die Seitenti-
nach
dem
gegebenen
tel zurück
login(user, passwd)
Status
Erzeugt eine Session im Bezug auf
einen Benutzer der Wiki
logout()
Status
Beendet eine Session im Bezug
auf einen eingeloggten Benutzer
der Wiki
Die Kategorie (2) beinhaltetet Funktionen zur optionalen oder ergänzenden Informationextraktion im Bezug auf Meta- bzw. Kontextdaten der Wiki oder einer Wiki-Seite (Tabelle
4.2).
Alle Funktionen sind als Methoden einer Klasse zu verstehen, wobei die Klasse die entsprechende Wiki-Engine repräsentiert (z.B. MediaWiki) und die Methode jeweils auf eine
Instanz angewendet werden kann (z.B. die Wikipedia). Die Funktionen werden von der
API im Bezug auf konkrete Wikis in den entsprechenden Wrappern (MediaWiki, TWiki
etc.) aufgerufen. D.h. die Wrapper verarbeiten immer nur eine Anfrage auf eine bestimmte
Wiki und API führt die Ergebnisse dann zusammen.
4 Konzept
71
Tabelle 4.2: Funktionen des Wrappers: Kategorie 2
Funktion
Ergebnis
Beschreibung
listVersions(id)
Liste von Seitennamen“
”
Liste der Seitennamen (Versionsnamen) der Versionen einer Seite
listBacklinks(id)
Liste von Seitennamen
Liste der Seitennamen, die auf die
entsprechende Seite verlinken
listCategories(opt)
Liste der Kategorien
Optional die Kategorien einer Kategorie oder Seite
listAuthors()
Liste von Autornamen
Liste aller Benutzer einer Wiki
listImages()
Liste von Seitennamen“
”
Liste aller Bilder (Bildernamen)
einer Wiki
listPages(opt)
Liste von Seitennamen
Optional die Seiten einer Kategorie oder eines Namenraums
listRecentChanges() Liste von Seitennamen
Liste der Seitennamen mit den
letzten Änderungen, einem Timestamp und chronologisch geordnet
4.2.2.2
Wiki-Schnittstellen
Auf der Grundlage meiner Analysen aus den Abschnitten Integration“ (3.2.2) und Har”
”
monisierung“ (3.2.1) ergeben sich folgende mögliche Schnittstellen bei der Umsetzung
seitens der Wrapper.
Aufgrund einer fehlenden bzw. seltenen Unterstützung von WikiRPC oder dementsprechenden APIs und den Erläuterungen im Abschnitt 3.2.2.2 müssen die meisten der Funktionen aus der 1. bzw. 2. Kategorie (Tabelle 4.1/4.2) – bis auf die getPage-Funktion –
über die jeweiligen HTML-Seiten (meist Spezialseiten) der Wiki angefordert und relativ
aufwendig geparst und aufbereitet werden. Was aber nicht ausschließt, dass in Einzelfällen
doch eine komfortablere Variante gewählt werden kann (abhängig von der Wiki-Engine
z.B. JSPWiki und der Funktion z.B. Versionen einer Seite).
Für die getPage-Funktion werden – aus genannten Gründen in den Abschnitten 3.2.2, 3.2.1
und 4.2.2 – die speziellen Exportfunktionen der Wiki-Engines genutzt, welche eine Seite
(in der entsprechenden Wiki-Markup) und die dazugehörigen Meta- bzw. Kontextdaten
in einem leicht weiterzuverarbeitenden XML-Format liefern.
72
4.2 API
4.2.2.3
Übergabeformat
Die Wrapper geben die entsprechenden Ergebnisse prinzipiell als XML-Datensatz an die
API zurück. Dies ist begründet auf der Tatsache, dass die entscheidende Eingabe der
Wrapper – nämlich die Wiki-Seiten der Wikis nach der von mir gewählten Methode (
3.2.2) – ebenfalls in XML vorliegen und somit keine grundsätzliche Umwandlung bezüglich
der Formate vorgenommen werden muss. Auf der Seite der API haben wir den selben Fall,
da die Daten lediglich in das wikiPAGEs-Format umgewandelt“ werden müssen, was
”
ebenfalls einer Variation von XML entspricht.
Umwandlungen bezüglich des Inhalts müssen jedoch sehr wohl vorgenommen werden,
welche sich in zwei Teile gliedern lassen, nämlich der Bearbeitung des Seiteninhalts an
sich und der Bearbeitung bzw. Umwandlung von Listen.
Seiteninhalt: Der Seiteninhalt einer Wiki-Seite liegt – wie in Abschnitt 3.2.2 beschrieben – in einem unbestimmten Mix aus HTML-Tags und Wiki-Markup vor. Die umfangreiche Aufschlüsselung und Auswertung diesbezüglich findet in der API statt,
allerdings sorgen an dieser Stelle die Wrapper dafür, der API auf der Basis von
WikiCreole (3.2.1.3) eine einheitliche Wiki-Syntax zu generieren aus den in den
Abschnitten 4.2 und 4.2.2 genannten Gründen.
Listen: Alle unter 4.2.2.1 aufgeführten Funktionen liefern (bis auf getPage und login) als
Ergebnis eine einfache Liste von z.B. Seitentiteln. Wie in 4.2.2.2 beschrieben, werden
diese von den Wikis als HTML-Listen zur Verfügung gestellt. Dies bedeutet, dass
an dieser Stelle eine Transformation von <li>-Tags in eine standardisierte XMLStruktur stattfinden muss.
4.2.3
Funktionen der API
Die grundsätzlichsten Funktionen der API entsprechen zunächst einmal den Funktionen,
die von den Wrapper bereits zur Verfügung gestellt wurden (4.2.2.1). Diesbezüglich gibt
es allerdings ein paar Unterschiede zu beachten, welche im Folgenden erläutert werden.
1. Die Funktion getPage() des Wrappers liefert die Seiten in einem WikiCreole-Markup
und HTML-Gemisch und die getPage()-Funktion der API – welche letztendlich von
den externen Anwendungen benutzt wird – liefert die Seite in dem wikiPAGEsFormat.
2. Die anderen Funktionen des Wrappers beziehen sich immer entweder auf die gesamte Wiki oder auf eine Seite. Die entsprechenden Funktionen der API können sich
4 Konzept
73
allerdings auch auf mehrere Wikis bzw. auf Teile einer Seite beziehen.
3. Hinzukommt, dass prinzipiell die Funktionen der Wrapper mit anderen IDs arbeiten,
als dies die API tut. Dies liegt im Wesentlichen daran, dass der jeweilige Wrapper
sich immer nur auf eine Wiki bezieht, während die API mit einer Menge von Wikis arbeiten muss, bei denen der Seitentitel als Schlüssel gegebenenfalls nicht mehr
eindeutig ist. Wie genau die IDs in der API generiert werden, wird in dem Unterabschnitt Struktur, Layout“ 4.3.1.1 von wikiPAGEs erläutert.
”
Alle weiteren Funktionen der API (Tabelle 4.3) beziehen sich jeweils auf Informationen,
die bei der Anfrage mehrerer Wikis zustande kommen bzw. bei der Zerlegung einer WikiSeite in ihre Bestandteile und deren Auswertung. Der Vollständigkeit halber werden die
entsprechenden Funktionen der Wrapper mit aufgelistet.
4.2.4
Anfrageaufbereitung
Zunächst einmal ist die Ausgabe der API immer ein XHTML-Dokument (wikiPAGE)
und nicht wie das Übergabeformat der Wrapper reines XML. D.h. hier findet die erste
Anpassung bezüglich des Dokumententyps statt. Danach müssen – abhängig von ihrer Art
– die Informationen den entsprechenden Teilen von wikiPAGEs (4.3) zugeordnet werden.
Hierbei können drei mögliche Fälle auftreten:
1. Die API liefert genau eine Wiki-Seite als Ergebnis, wo es hauptsächlich darum
geht, die Seite auf der Basis ihrer enthaltenen HTML- bzw. WikiCreole-MarkupElemente in ihre Bestandteile zu zerlegen und in ein Standard-XHTML-Format zu
konvertieren. Das Layout wird dabei in CSS-Klassen ausgelagert und der Kontext
einer Seite als XML-Struktur angehängt.
2. Die API liefert Teile einer Wiki-Seite oder Dateien wie z.B. Bilder. In diesem Fall
ist es entscheidend, dass die Inhalte möglichst roh“ geliefert werden, damit sie di”
rekt weiterverwendet werden können. Diese Art der Anfrageaufbereitung und dessen
Ausgabe setzt natürlich Punkt (1) in einem vorangegangen Schritt voraus.
3. Die API liefert Listen von Ergebnissen, wie z.B. bei der Auflistung aller Seiten eines
Wiki-Pools. Auch wenn diese Anfragen teilweise dem Kontext einer Seite oder einer
Wiki entsprechen, werden diese Informationen nicht als XML übergeben, sondern
in XHTML und Standard CSS-Klassen. Somit kann das Ergebnis direkt im Browser
angezeigt werden und ist trotzdem zur Weiterverarbeitung geeignet.
74
4.2 API
Tabelle 4.3: Funktionen der API
Funktion
Ergebnis
Beschreibung
getSummary()
Zusammenfassung
Bezogen auf den Wiki-Pool, eine
Wiki, eine Seite oder eine Section
listWikis()
Liste von Wikinamen
Liste aller im Pool befindlichen Wikis
getWiki(id)
Instanz eines Wrappers
Ein Wiki-Objekt des Wiki-Pools
listPages(opt)
Liste von Seitennamen
Bezogen auf den Wiki-Pool oder eine Wiki
getPage(id)
listSections()
wikiPAGEs-Version einer
Liefert eine konkrete Seite einer
Seite
Wiki
Liste von Abschnitten der
Liste aller Abschnitte einer Seite
Seite
getSection(id)
Abschnitt einer Seite
Liefert einen bestimmten Abschnitt
einer Seite
listImage()
Liste von Seitennamen“
”
Bezogen auf den Wiki-Pool, eine
Wiki, eine Seite oder eine Section
getImage(id)
Bild als Datei
Liefert ein konkretes Bild als Datei
listLinks(opt)
Liste von Links
Bezogen auf eine Seite oder eine
Section. Optional auf externe oder
interne Links beschränkt
listBackLinks()
Liste von Links
Liste von Seitennamen, die auf eine
Seite zeigen
listVersions()
Liste von Seitennamen“
”
Liste der Seitennamen (Versionsnamen) einer Seite
listAuthors()
Liste von Benutzernamen
Bezogen auf den Wiki-Pool, eine
Wiki oder eine Seite
listKeywords(opt)
Liste von Schlüsselwörtern
Optional im Bezug auf Synonyme oder Homonyme des Seitentitels
oder häufige Wörter
listCategories()
Liste von Kategorien
Bezogen auf den Wiki-Pool, eine
Wiki oder eine Seite
listRecentChanges() Liste von Seitennamen
Liste der Seitennamen mit den letzten Änderungen, einem Timestamp
und chronologisch geordnet
4 Konzept
75
Die Aufbereitung im Bezug auf den 3. Punkt kann im Wesentlichen durch den Einsatz von
XSLT [G] vollzogen werden. Da die Inhalte von den Wrappern schon vorbereitet wurden,
ist dieser Punkt weitestgehend als unkritisch einzustufen.
Kritischer sind da die Punkte 1 und 2 im Bezug auf den Seiteninhalt und dessen Kontext.
Bei der Aufbereitung des Seiteninhalts geht es darum, die Information bezüglich des
Layouts, welche teilweise im Wiki-Markup (an dieser Stelle schon vereinheitlicht, siehe
4.2.2) und teilweise in HTML kodiert sind, zu extrahieren und separiert vom eigentlichen
Inhalt abzuspeichern. Hierbei können ebenfalls drei Fälle unterschieden werden:
Unkritisch (sicher): Alle Elemente der Seite, die über das WikiCreole-Markup definiert
wurden, können ohne Probleme standardisierten CSS-Klassen bzw. XHTML-Tags
(4.3) zugeordnet werden und können somit als sicher“ interpretiert werden.
”
Unkritisch (unsicher): Alle Elemente der Seite, die über diverse HTML-Tags definiert
wurden, können ebenfalls ohne Probleme standardisierten Layoutbeschreibungen
zugeordnet werden, allerdings ist die spätere Interpretation als unsicher“ einzustu”
fen.
Kritisch: Alle Elemente, die über CSS-Stylesheets in z.B. divs oder span definiert wurden, sind nur schwer bis gar nicht standardisierten Layoutbeschreibungen zuzuordnen. Sie werden deshalb als kritisch“ deklariert und die Formatierung als Layout”
Hinweise übernommen, welche optional angezeigt werden können.
Des Weiteren muss bei der Aufbereitung des 1. Punkts der Kontext einer Seite über
unterschiedliche Wege bezogen und zusammengeführt werden. So ist z.B. die Liste der
Kategorien einer Seite direkt in der Seite enthalten und müssen gefiltert und in valides
XML überführt werden, die Keywords hingegen werden beim Parsen einer Seite und
über externe Datenbanken gewonnen und Backlinks müssen zusätzlich bei den Wrappern
angefordert werden.
4.2.5
Schnittstellen
Prinzipiell entspricht die Schnittstelle der API der Verwendung der GET-Methode eines
HTTP-Requests. D.h. Funktionen und deren Parameter werden direkt über die Uniform
Resource Locator (URL) aufgerufen und das Ergebnis – im Wesentlichen – in dem bereits
beschriebenen Format (XHTML) zurückgeliefert. Ausnahmen sind Anfragen bezüglich
konkreter Dateien oder einzelner Textpassagen.
76
4.3 wikiPAGEs
Alternativ – im Bezug auf die Rückgaben der Ergebnisse – könnte zusätzlich die Ausgabe in JSON [G] angeboten werden. Dies ist gerade dann interessant, wenn die API
ausschließlich Informationen an eine externe Anwendung liefern muss, d.h. Inhalte nicht
direkt darstellbar sein müssen. Die Vorteile wären, dass die Daten direkt und ohne sonstige Verarbeitung von einem JavaScript [G] Interpretierer ausgewertet und verwendet
werden können. Insbesondere bei Web-Anwendungen, die sich an dem Konzept von Ajax
[G] orientieren, würde dies zu einer enormen Arbeitserleichterung führen, da die XHTMLDateien nicht erst wieder geparst und umgewandelt werden müssten, weil die Daten ja
bereits in JavaScript Syntax vorliegen.
4.3
wikiPAGEs
Wie in dem Abschnitt
Komponenten der API“ (4.2.1) bereits beschrieben, ist wi”
kiPAGEs eines der drei entscheidenden Elemente der API und bildet die Schnittstelle zwischen ihr und den darauf aufbauenden Anwendungen. Somit ist wikiPAGEs die
harmonisierte Fassung einer bzw. mehrerer Wiki-Seiten im Bezug auf ihre Metadaten,
ihre Struktur, das Layout und der visuellen Gestaltung. Hinzu kommt, dass durch die
Überführung in ein wohldefiniertes Format (wie XHTML) und der strikten Trennung von
Inhalten und deren Repräsentationen die Inhalte wesentlich maschinenlesbarer“ gemacht
”
werden und somit leichter zu verarbeiten sind (4.3.1). Des Weiteren werden die Inhalte im
wikiPAGEs-Format mit zusätzlichen Informationen im Kontext der Autorenumgebung
von der API angereichert, wie z.B die Bewertung von Informationen im Bezug auf die
Sicherheit von Interpretationen (4.3.1.1) oder der einheitlichen Vergabe von IDs (4.3.1.3),
um Inhalte auch Wiki-übergreifend identifizieren zu können. Darüber hinaus müssen auch
mehrere wikiPAGEs lokal gespeichert werden können, ohne dass interne Verlinkungen
oder extern eingebundene Dateien dadurch beeinflusst werden (4.3.2).
Diese zentrale Rolle und die Beschreibung der Details sind Inhalt dieses Kapitels und
dienen der entwickelten Autorenumgebung als Namensgeber.
4.3.1
Konzept einer Wiki-Seite
Das Konzept einer einheitlichen Repräsentation einer Wiki-Seite basiert auf den Analysen
der Wiki-Inhalte aus dem Abschnitt 3.2.1 und stellt letztendlich eine Erweiterung bzw.
Weiterentwicklung des Wiki Interchange Format (WIF)“ dar, dessen Vorteile bereits in
”
dem entsprechenden Unterabschnitt 3.2.1.4 dargelegt wurden.
Somit entspricht die Anforderung einer Seite einer Wiki über die API prinzipiell immer
4 Konzept
77
einer Sammlung von Datenstrukturen (wikiPAGEs), die im Einzelnen wären:
• Eine XHTML-Datei, die als Rahmen für alle weiteren Unterpunkt zur Verfügung
steht. Hauptsächlich jedoch den eigentlichen Inhalt im <body>-Tag unterbringt,
welcher in einer Standardformatierung direkt im Browser angezeigt werden kann,
bzw. Metainformationen dementsprechend im <head>-Tag (4.3.1.2).
• Mehrere Definitionen von CSS-Klassen zur Unterbringung einer unterschiedlichen
Repräsentation der Daten (visuelle Stile) oder zur Beschreibung diesbezüglicher
Interpretations-Hinweise (4.3.1.1).
• Der Kontext einer Seite hinterlegt anhand von XML-Strukturen im Bezug auf
die eingehende Verlinkungen seitens anderen Seiten oder zugeordneter Kategorien
(4.3.1.3).
Beim Anfordern von mehreren Seiten werden diese wie das Wiki Archive Format (WAF)“
”
(3.2.1.4) auch innerhalb einer Zip-Datei hinterlegt zusammen mit externen Binärdateien
und diesbezüglich korrigierten Links (4.3.2).
4.3.1.1
Layout und visuelle Stile
Wie in dem Abschnitt 3.2.1.1 bereits analysiert, ergeben sich im Kontext von Inhalten
innerhalb von Wiki-Seiten folgende Elemente, welche im Einzelnen der Tabelle 4.4 entnommen werden können.
Tabelle 4.4: Komponenten von wikiPAGEs: Struktur und Layout
Beschreibung
Elemente
Abschnittsüberschriften
<h1>, <h2>, <h3>, <h4>, <h5>, <h6>
Blockelemente
<p>, <pre>, <hr>
Listen
<dl>, <dd>, <dt>, <ol>, <ul>, <li>
Tabellen
<table>, <tr>, <th>, <td>
Links
<a>
Bilder
<img>
Layout
<i>, <b>, <em> , <sub>, <sup>, <tt>
Sonstige
<span>, <div>
Diesen Elementen werden dann mehrere visuelle Stile“ in Form von CSS-Klassen aus
”
drei Kategorien zugeordnet, die da sind: Standardformatierungen (1), Metaformatierungen (2) und Kontextformatierungen (3). Die visuellen Stile“ der Kategorie (1) werden
”
78
4.3 wikiPAGEs
prinzipiell jedem der in Tabelle 4.4 gelisteten Elemente zugeordnet und sorgen für eine
einfache, klare und grundsätzliche Gestaltung bei der Anzeige einer wikiPAGE direkt im
Browser. Die visuellen Stile“ der Kategorie (1) werden allen in 3.2.1.1 als unklar“ de”
”
finierten Elementen zugeordnet und ermöglichen die Einteilung in sichere und unsichere
Informationen. Optional können hier gänzlich die ursprünglichen Stile eines Elements untergebracht werden. Stile der Kategorie (3) beziehen sich ausschließlich auf das <a>-Tag
und dienen zur Einordnung von externen und internen Links. Dementsprechend könnten
hier auch Informationen übernommen werden, ob eine intern verlinkte Seite zum Zeitpunkt der Anforderung leer“ oder bereites gefüllt“ war (2.2.1.2).
”
”
Die in diesem Abschnitt beschriebenen Elemente und die Zuordnung von entsprechenden
CSS-Klassen sind die wesentlichen Informationsquellen bei der späteren Informationsex”
traktion“ (4.4.3.2) seitens der Autorenumgebung.
4.3.1.2
Metadaten
Wie in dem Abschnitt 3.2.1.2 analysiert, teilen sich die Metadaten in zwei Klassen, den
Wiki-spezifischen und den Seiten-spezifischen. Beide werden jeweils in entsprechenden
<meta>-Tags des Header der XHTML-Datei untergebracht, trotz eventuell auftretender
Redundanz seitens der Wiki-spezifischen Informationen. Dies wird inkaufgenommen, da
sich zum einen die spezifischen Metadaten bezogen auf die Wiki relativ dürftig ausfallen
und zum anderen dadurch jede wikiPAGE für sich alleine stehen kann und trotzdem
sämtliche Informationen beinhaltet, die die API einmal extrahiert hat. Diese können im
Einzelnen der Tabelle 4.5 entnommen werden.
Bei der Speicherung mehrerer wikiPAGEs in einem Archiv fallen zusätzliche Metadaten
an, welche wie in 4.3.2 beschrieben in einer zusätzlichen XML-Datei untergebracht sind.
Allerdings ist eine Lösung wie bei dem Wiki Archive Format (WAF)“ (3.2.1.4) ebenfalls
”
möglich, wo zusätzliche RDF-Dateien definiert und dem Archiv hinzugefügt werden.
4.3.1.3
Seitenkontext und IDs
Bei der Analyse der anfallenden Metadaten von Seiten in Wikis (3.2.1.2) ergaben sich
in der Tabelle 4.6 gelistete Daten, die aufgrund ihres Umfangs schwierig bzw. nur
unübersichtlich in den <meta>-Tags des Header der XHTML-Datei untergebracht werden konnten. Diese Informationen ließen sich im Wesentlichen dem Kontext einer Seite
zuordnen, also Verlinkungen innerhalb der Wiki im Bezug auf eine Seite. Da sich diese
Verlinkungen als eine Liste von Verweisen repräsentieren lassen, eignet sich insbesondere
die Speicherung in einer einfachen XML-Struktur.
4 Konzept
79
Tabelle 4.5: Komponenten von wikiPAGEs: Metadaten
Bezug
Metadaten
Wiki-spezifisch
- Titel der Wiki, aus der diese Seite stammt
- URL und Zugangsinformationen der Wiki
- Name der zugrunde liegenden Wiki-Engine
- Versionsnummer der Wiki-Engine
Seiten-spezifisch
- Titel der Seite (im <title>-Tag)
- Autor, der diese Seite erstellt bzw. als letztes bearbeitet hat
- Anzahl der Autoren bzw. der Revisionen
- Anzahl der enthaltenen Wörter oder Medien
- Schlüsselwörter im Bezug auf den Seiten-Inhalt
- Datum der ersten Version der Seite bzw. des letzen Updates
- Verweis auf die erste bzw. letzte Version dieser Seite
- Verweis auf die nächst jüngere bzw. ältere Version
API-spezifisch
- Benutzername, welcher die Seite angefordert hat
- Timestamp des Zeitpunkts, als die Seite angefordert wurde
Da die Verlinkungen prinzipiell in der API auch Wiki-übergreifend intern“ sein können
”
und somit eine Unterscheidung anhand des Seitentitels unter Umständen nicht mehr eindeutig ist, müssen an dieser Stelle die IDs erweitert werden. Somit wird eine Seite immer
erst über ihre Wiki, dann den Namensraum und zuletzt über ihren Namen referenziert,
was im Wesentlichen auch der URL einer Seite entspricht. Um jedoch auch Teile innerhalb
einer Seite ansteuern zu können, wird die ID an dieser Stelle fortgeführt und mit jeder Abschnittsüberschrift um einen Zähler ergänzt, bis diese maximal mit der kleinsten Einheit,
einem Paragraphen“ endet. Dabei ist der Begriff Paragraph“ nicht auf das <p>-Tag
”
”
beschränkt, sondern bezieht sich ebenfalls auf alle Blockelemente, Listen, Tabellen und
<img>-Tags.
4.3.2
Archive und Binärdateien
Wie bereits beschrieben, werden die Archive (eine Sammlung von wikiPAGEs) ähnlich
dem Wiki Archive Format (WAF)“ (3.2.1.4) innerhalb einer Zip-Datei zusammen mit
”
extern eingebundenen Binärdateien und korrigierten Links hinterlegt.
Um die einzelnen Seiten und deren Verlinkungen wiederum auf Seiten oder eingebunden
Medien konsistent zu halten, muss dafür gesorgt werden, dass innerhalb der Zip-Datei
80
4.4 Autorenumgebung
Tabelle 4.6: Komponenten von wikiPAGEs: Seitenkontext
Bezug
Metadaten
Kontext-
- interne bzw. externe Links, die in der Seite enthalten sind
spezifisch
- Kategorien und Namensräume, denen die Seite zugeordnet ist
- Weiterleitungen, die dieser Seite entsprechen
- Seiten die auf diese Seite verlinken
ein ähnliches Model zugrunde liegt wie dem der API. Da eine Abbildung von Strukturen
auf Ordner- und Dateiebene immer problematisch ist, z.B. im Bezug auf die Zeichenkodierung, die Längenbegrenzung von Datei- und Ordnernamen etc. befindet sich in der
gepackten Datei eine zusätzliche XML-Datei, welche die IDs der API auf neu generierte
Dateisystem-kompatible IDs abbildet. In dieser XML-Struktur finden sich in der obersten
Ebene die verwendeten Wikis, darunter die Namensräume und wiederum darunter die
konkreten Dateinamen der Seiten und Binärdaten und deren Abbildung auf die IDs der
API. Links oder Verwendungen von Ressourcen innerhalb der Seiten rufen somit weiterhin eine entsprechende Funktion mit der diesbezüglichen ID auf. Diese jedoch erkennt
den lokalen Status und leitet die Anfrage deshalb nicht zur API weiter, sondern schaut
stattdessen in der XML-Datei nach.
Bei der Eingliederung der archivierten Seiten wieder zurück in die Autorenumgebung wird
lediglich der Status (lokales bzw. serverseitiges Archiv) angepasst und die Seiten können
wie zuvor verwendet werden.
4.4
Autorenumgebung
Nachdem die Inhalte von Wikis nun unabhängig von ihrer Engine mittels Ansteuerung
durch die API (4.2) und Transformierung in das wikiPAGESs-Format (4.3) standardisiert
vorliegen, kann mit dem eigentlichen Autorenprozess begonnen werden. Dieser befasst sich
im Bezug auf Wiki-Inhalte (wie in 3.1 beschrieben) im Wesentlichen mit der Extraktion,
Transformation und Kombination (1) von einzelnen Wiki-Seiten (3.2) hin zu den entsprechenden Seiten“ einer externen eLearning-Anwendung (3.3) und deren Zuordnung
”
untereinander (2). Die möglichen Zuordnungen wurden im Abschnitt 2.3 erläutert und
definieren letztendlich die Navigationsstrukturen des Kurses.
Punkt (1) wird in dem Abschnitt Authoring“ (4.4.3) beschrieben und konzipiert, welcher
”
nicht unwesentlich und direkt von den Exportmodulen“ (4.4.4) abhängt. Die Exportmo”
4 Konzept
81
Bild 4.3: Komponenten der Autorenumgebung
dule entsprechen dem Teil (2) des zuvor beschriebenen Autorenprozesses und definieren
den Rahmen der zu erzeugenden eLearning-Kurse. Die für beide Punkte notwendigen Ba”
sisfunktionen“, z.B. Caching oder die Definition unterschiedlicher Benutzergruppen oder
des Wiki-Pools, werden in dem entsprechenden Unterabschnitt 4.4.2 behandelt.
In dem Abschnitt Erweiterungen“ (4.4.2) werden mögliche Ergänzungen der Autorenum”
gebung angerissen, die zusätzlich die Autoren bei ihrer Erzeugung von eLearning-Inhalten
aus Wiki-Systemen unterstützen könnten. Die dort aufgeführten Erweiterungen basieren
auf den Ergebnissen anderen Arbeiten und dienen lediglich zur Demonstration möglicher
Ansatzpunkte.
4.4.1
User Interface (UI)
Das User Interface (UI) der Autorenumgebung sollte sich an dem von Wikis im Allgemeinen orientieren, um den Autoren weiterhin das Gefühl für die praktische Nutzung
einer Wiki zu vermitteln. Das UI von Wikis wurde im Abschnitt (2.2.1.3) analysiert und
kann dementsprechend konstruiert werden. Im Wesentlichen entspricht es einer Drei- bzw.
Zweiteilung des Browserfensters, wenn man den Benutzerbereich in eine benutzerspezifi-
82
4.4 Autorenumgebung
sche Navigation einfließen lässt. Den Hauptteil nimmt dann der eigentliche Inhalt einer
Wiki-Seite ein, bei dem entweder zwischen einem Editiermodus bzw. Anzeigemodus umgeschaltet werden kann oder Inhalt direkt in einem WYSIWYG-Editor bearbeitet bzw.
angezeigt werden können.
Bei dem konkreten Erzeugen von Kursen bzw. Kurs-Seiten jedoch, muss der Arbeitsbereich um mindestens ein weiteres Element erweitert werden, um zusätzlich zum Inhalt
der Wiki auch eine Abbildung der Struktur des Kurses bzw. eine Vorschau seiner Seiten darstellen zu können. Im günstigsten Fall teilen sich die beide Anzeigen (Wiki-Inhalt
und eLearning-Kurs) den zur Verfügung stehenden Platz des Browserfenster so, dass die
Möglichkeit entsteht, Inhalte per Drag&Drop zwischen den jeweiligen Elementen austauschen zu können.
4.4.2
Basisfunktionen
Unter den Basisfunktionen der Autorenumgebung sind die Funktionalitäten zusammengefasst, welche nicht direkt im Zusammenhang mit dem Autorenprozess stehen und somit
lediglich indirekt zur Erstellung von eLearning-Kursen aus Wiki-Inhalten beitragen.
Abgesehen von noch grundsätzlicheren Funktionen, wie das prinzipielle Generieren und
Anzeigen von Seiten, eine dynamische Navigation oder die Möglichkeit sich an- und abmelden zu können, werden die relevanten Funktionen in den folgenden Unterkapiteln
beschriebenen und definiert.
4.4.2.1
API-Schnittstelle
Auch wenn sich, wie im Abschnitt 4.2.5 beschrieben, die Autorenumgebung durchaus an
Konzepten von Ajax orientiert, wird sie sich ausschliesslich auf die XHTML-Ausgabe der
API beschränken und somit auf einige der Vorteile von JSON verzichten. Die Entscheidung beruht im Wesentlichen auf zwei Punkten. Erstens müssen die Vorteile von JSON
nicht unbedingt auch gleich Nachteile von XML (XHTML) sein, wenn z.B. ein geringerer
Overhead3 seitens JSON gegenüber XML dadurch relativiert wird, wenn es entsprechend
wenig Anfragen mit verhältnismäßig vielen Nutzdaten gibt und zweites – was in diesem Fall entscheidender ist – beruht das Konzepts des Cachings der Autorenumgebung
(4.4.2.4) auf der lokalen serverseitigen Speicherung von wikiPAGEs, was mit JSON nicht
oder schwerer zu realisieren wäre.
3
Als Overhead (Verwaltungsdaten) werden Daten bezeichnet, die nicht primär zu den Nutzdaten
zählen, sondern als Zusatzinformation zur Übermittlung oder Speicherung benötigt werden.[Fou08b]
4 Konzept
83
Ansonsten stellt die Autorenumgebung, wie jede andere Anwendung auch, ihre Anfragen
an die API über das Absenden eines HTTP-Request, welcher die aufzurufende Funktion
und deren Parameter (am Ende der URL der API) beinhaltet.
4.4.2.2
Benutzergruppen
Die Autorenumgebung wikiPAGEs“ unterstützt standardmäßig drei Benutzergruppen
”
mit unterschiedlichen Zugriffsrechten und damit verbundenen Nutzungsmöglichkeiten:
Der einfachste (ohne Registrierung) und somit aber auch beschränkteste und anonyme Zugang ist über die Benutzergruppe anonymous“ bzw. dem entsprechenden Benutzernamen
”
zu erhalten. Hierbei werden lediglich die grundlegendsten Funktionen der API bedient,
d.h. Einbinden einer Wiki über optionale Login-Daten, das Suchen nach Seiten und die
Entgegennahme und Anzeige von Inhalten in dem standardisierten wikiPAGEs-Format.
Die zweite Benutzergruppe entspricht der eigentlichen Zielgruppe nämlich, den Autoren
(3.1.1). Zusätzlich zu den Funktionen eines anonymen Zugangs können hier mehrere Wikis
über einen verwalteten Pool zugänglich gemacht werden. Export-Module der einzelnen
eLearning-Anwendungen können konfiguriert und Seiteninhalte der Wikis in das Format
eines neu erzeugten eLearning-Kurse überführt und exportiert werden.
Die mächtigste Gruppe (allerdings ohne Funktionen bezügliche des Autorenprozesses)
ist die der Administratoren. Hier werden hauptsächlich die registrierten Benutzer, die
möglichen Wiki-Wrapper und die zur Verfügung stehenden Plugins (Erweiterungen, Exportmodule) verwaltet. Aber auch allgemeine Einstellungen der Autorenumgebungen, Statistiken oder Tests sollten möglich sein.
4.4.2.3
Wiki-Pools
Der Wiki-Pool“ der Autorenumgebung entspricht einer benutzerspezifischen Sammlung
”
von Wikis und ihren Zugang. Benutzerspezifisch bedeutet, dass jeder Autor seinen eigenen
Pool“ an Wikis zu verwalten und zu pflegen hat. Einzige Einschränkung ist die Tatsache,
”
dass für die jeweilige Wiki ein funktionierender Wrapper vorhanden sein muss und dieser
vom Administrator freigegeben wurde. Um nun eine Wiki der Sammlung eines Autoren
hinzuzufügen, wählt er den entsprechenden Wiki-Typ (Wiki-Engine 2.2.2), woraufhin ein
– für dieses Wiki-System relevantes – Formular ausgefüllt und gespeichert werden muss.
Dieses Formular beinhaltet folgende Standard-Punkte:
• Name zur Benennung und späteren Identifizierung einer Wiki für den Autoren.
84
4.4 Autorenumgebung
• Server, welcher die Wiki zur Verfügung stellt. Dies ist einer von drei Teilen der
gesamten URL der Wiki.
• Verzeichnis, in dem die Wiki auf dem angebenden Server zu finden ist.
• Schnittstelle der verwendeten Wiki, womit die Ansteuerung der zugänglichen
Skripte gemeint ist, falls deren Zugang durch das Apache-Modul mod rewrite“ 4
”
anders kodiert sein sollte. Je nachdem welche Wiki verwendet wird, muss dies einmal für den Seitenzugriff und einmal für Suchanfragen bzw. Login-Möglichkeiten
definiert werden.
• Login-Daten zum Zugriff auf geschützte Inhalte bzw. benutzerspezifischen Zugang
zur Wiki.
Jede dem Pool“ so hinzugefügte Wiki ist somit gleichzeitig mit all den anderen eingebun”
denen Wikis eines Autoren, durchsuchbar und potentiell nutzbar. Um jedoch durch z.B.
der Einbindung der Wikipedia eine Überflutung von Informationen zu vermeiden, kann
man im Nachhinein wieder Wikis entfernen bzw. deaktivieren oder durch die Angabe von
Prioritäten die Reihenfolge der Sucherergebnisse beeinflussen.
4.4.2.4
Caching
Beim Caching gibt zwei grundsätzliche Aspekte, die im Bezug auf die Autorenumgebung
relevant sind. Dies ist zum einen das Beschleunigen von Anfragen durch eine minimierte Nutzung der API (1), d.h. wenn eine Seite bereits angefordert wurde, sollte diese
nur noch einmal neu über die API bezogen werden, wenn Änderungen verzeichnet wurden. Dies setzt voraus, dass die API eine schnelle Funktion zur Ermittlung der letzten
Änderungen zur Verfügung stellt, was man der Spezifikation (4.2.3) entnehmen kann. Zum
anderen sollte den Autoren die Möglichkeit angeboten werden, Wiki-Inhalte gezielt offline
verfügbar zu machen (2). So könnten z.B. einzelne Seiten unter der Angabe der Tiefe ihrer ausgehenden Links oder entsprechend sämtliche Seiten eines Namensraums bzw. einer
Kategorie persistent verfügbar gemacht werden.
Technisch bedeutet dies, dass die Seiten in dem wikiPAGEs-Format (wie in 4.3.2 spezifiziert), als Bundle benutzerspezifisch auf dem Server als Dateien zwischengespeichert
werden. Bei jeder Anfrage wird dann zunächst der lokale Index durchsucht und im Fall
(1) automatisch auf Aktualität überprüft. Im Fall (2) wird grundsätzlich die Offline”
Variante“ angezeigt und nur auf Wunsch des Autoren aktualisiert.
4
Modul zur serverseitigen Manipulationen von URLs mit Hilfe von regulären Ausdrücken
4 Konzept
4.4.3
85
Authoring
Das eigentliche Authoring beginnt, wie im vorherigen Abschnitt (4.4.2) beschrieben, mit
der Registrierung als ein Benutzer (in diesem Fall als Autor - 4.4.2.2) bei wikiPAGEs, der
Autorenumgebung. Durch die Einrichtung eines Wiki-Pools (4.4.2.3) werden potentielle
Informationsquellen dem Autorenprozess zu Grunde gelegt und nutzbar gemacht. Somit
sind die Inhalte der eingebunden Wikis durch den Autoren einheitlich durchsuchbar und
lesbar.
Um nun die gewünschten Inhalte für eLearning-Anwendungen aufarbeiten und exportieren
zu können, sind folgende Schritte notwendig:
1. Aus einer Menge zur Verfügung stehender Export-Module (4.4.4), welche durch den
Administrator aktiviert werden, wählt man die gewünschte eLearning-Anwendung
für den Export. Darin enthalten befinden sich die Informationen zu den Metadaten,
den Seiten an sich und deren Verknüpfung und die allgemeine Kursstruktur.
2. Auf dessen Grundlage kann nun durch den Autoren ein neuer Kurs angelegt werden und bezüglich seiner Meta-Informationen und allgemeinen Kurseinstellung angepasst werden. In jedem dieser Schritte sollen sowohl Inhalte aus den Wikis
übernommen, bzw. neu vom Autoren eingegeben werden können.
3. Nun beginnt die eigentliche Produktion (3.1) durch das Anlegen einzelner Seiten,
welche per Drag&Drop oder manueller Eingabe befüllt werden können. Bei der
kompletten Verwendung von mindestens einem Paragraphen (siehe 4.3.1.1) kann
optional eine Live-Darstellung“ gewählt werden. Das Layout, die Struktur und der
”
Umfang einer Seite wird dabei von dem Export-Modul vorgegeben.
4. Nach der Fertigstellung des Kurses werden durch das Speichern die Inhalte in das
korrekte Format gebracht und für die gewählte eLearning-Anwendung exportiert.
4.4.3.1
Kurs- und Seitenerzeugung
Die Erzeugung eines Kurses in der Autorenumgebung beginnt somit, wie im ersten Punkt
des vorangegangen Abschnitts beschrieben, mit der Wahl eines konkreten Exportmoduls.
Diese Module, wie in 4.4.4 näher erläutert, enthalten im Wesentlichen Informationen
bezüglich der zugrunde liegenden eLearning-Anwendung, der Beschaffenheit eines entsprechenden Kurses und den Vorlagen der zu definierenden Seiten. Auf der Basis dieser
Informationen kann die Autorenumgebung nun dem Autoren Werkzeuge zur Verfügung
stellen, welche ihn in der Produktionsphase seines Autorenprozesses unterstützen bzw.
86
4.4 Autorenumgebung
ein Gerüst“ des zu erstellenden Kurses beschreiben und vorgeben. Wie dem Abschnitt
”
eLearning-Kurse“ 3.3 im Analyse-Kapitel zu entnehmen ist, beschreiben einen Kurs im
”
Wesentlichen drei Elemente, seine Metadaten (1), seine Struktur (2) und die Beschaffenheit der Seiten und deren Inhalt (3).
Die Metadaten (1) sollten während der gesamten Produktion gefüllt bzw. bearbeitet werden können, da die Metainformation sowohl zu Beginn des Authorings (z.B. durch die
Vorgaben eines Drehbuchs 3.1.2.1) als auch am Ende des Prozesses vorliegen können,
wenn sich z.B. die Erkenntnis eines didaktischen Zieles erst durch die Sichtung der entsprechenden Wiki ergibt.
In beiden Fällen ist das Befüllen jedoch unproblematisch, da sich lediglich an den technischen Anforderungen der eLearning-Anwendung orientiert werden muss, welche im Bezug
auf die Hinterlegung von Metadaten meist wohl definiert oder gar standardisiert ist (3.3.2).
Da es sich hierbei auch ausschließlich um textliche Informationen handelt, lassen sich diese
über ein einfaches Formular erheben.
Die Struktur eines Kurses (2) ist da schon weniger direkt in Erfahrung zu bringen und
definiert sich hauptsächlich über die Erzeugung und Einordnung der Seiten selber. Somit
beginnt die Produktion eines Kurses im Bezug auf seine Struktur und seinen Inhalt mit
der Erzeugung der ersten Seite. Je nachdem, welche Elemente zur Strukturierung dann in
dem Exportmodul definiert wurden, kann diese – und alle folgenden Seiten – dann diesbezüglich zugeordnet werden (eine Seite gehört zu einer Lektion oder Gruppe; eine Seite
ist eine Erweiterung oder Ergänzung etc.), woraus sich dann die Struktur eines Kurses
ergibt. Dies ist sowohl der Fall, wenn man sich diesbezüglich an eine Drehbuch halten
muss, als auch wenn der Kurs konstruktiv aus dem Inhalt der Wiki wächst. Entscheidend ist auch hierbei, dass bis zum Schluss die Zuordnungen, z.B. Seite/Lektion oder
Seite/Unterseite, überarbeitet und korrigiert werden können. Dies betrifft natürlich auch
die Reihenfolge von Seiten, Lektion, Gruppen etc. Auch an dieser Stelle – ähnlich wie bei
den Metadaten (1) – unterscheidet sich die Autorenumgebung nur unwesentlich von den
schon existierenden (2.3.2) ohne Wiki-Hintergrund, da derartige Zuordnungen auch dort
so realisiert sind und genauso wie hier lediglich Entscheidungen getroffen werden müssen,
die technisch nicht problematischer sind, nur weil die Inhalte aus Wikis extrahiert werden.
Dieser Unterschied kommt eben erst dann zum Tragen, wenn es bei der Erzeugung einer
Seite (3) neben der Einordnung in eine gewisse Kursstruktur um das Befüllen und Gestalten der Seite an sich und deren Inhalt geht. Grundlage hierfür sind wiederum in dem Exportmodul definierte Seiten-Vorlagen, welche z.B. über eine entsprechende Übersicht dem
Autoren angeboten werden und bei jeder neu erzeugten Seite zunächst gewählt werden
müssen. Die Wahl bestimmt im Wesentlichen die Positionierung der Elemente innerhalb
einer Seite und deren visuelle Stile. Je nachdem, wie viel Freiheiten nun die entsprechende
4 Konzept
87
eLearning-Anwendung zulässt bzw. anbietet, ergeben sich hier für den Autoren weitere
Möglichkeiten der Anordnung und Gestaltung von Elementen. Und genau hier zeigen
sich dann die Qualitäten einer Autorenumgebung speziell zur Erstellung von eLearningKursen aus Wiki-Inhalten. Denn diese Entscheidungen – im Bezug auf die eben erwähnten
Möglichkeiten – kann er nun, auf der Basis von Inhalten der eingesetzten Wiki und deren
dortige Anordnung, Gestaltung und Entwicklung treffen und somit zeitnah in die Produktion seiner eLearning-Inhalte einfließen lassen. Ganz davon abgesehen, dass ihm durch den
einheitlichen Zugang auf Wikis prinzipiell ein Pool an Wikis und deren Inhalte gebündelt
bzw. harmonisiert zur Verfügung steht, deren Inhalte interpretiert, aufbereitet und direkt
verwendet werden können.
Klar ist, dass es an dieser Stelle entscheidend ist, wie die Informationen dem Autoren
präsentiert werden, ohne ihn diesbezüglich zu überfluten bzw. zu viel vorzuenthalten,
worum es im nächsten Abschnitt, der Extraktion von Information, geht.
4.4.3.2
Informationsextraktion
Wie bereits beschrieben, liegt neben dem zentralen und einheitlichen Zugang auf eine Vielzahl von Wikis die Hauptfunktion der Autorenumgebung bei der Extraktion von Inhalten,
deren Layout, der Strukturierung einer Seite (ob in der Wiki oder im eLearning-Kurs) und
der visuellen Gestaltung. D.h. wo es bisher darum ging, seitens der API und wikiPAGEs
von all diesen Dingen zu abstrahieren und somit den Inhalt möglichst sauber von der
Präsentation zu separieren, geht es nun wieder darum, diese Informationen zusammenzufügen bzw. zurückfließen zu lassen.
Was die Extraktion und Verwendung von Inhalten betrifft, ist das Vorgehen unkritisch. Das wikiPAGEs-Format liefert gut strukturierte Seiten (4.3.1), deren kleinste
Einheiten Paragraphen sind und sich eindeutig aus einer Menge von Wikis und deren
Seiten bestimmen lassen (siehe IDs 4.3.1.3). Somit lassen sich, insbesondere in einer
Web-basierten Anwendung, einzelne Elemente ansteuern, aufgreifen und verschieben. Dies
würde im Wesentlichen einer Drag&Drop-Funktion entsprechen, bei der Teile einer WikiSeite auf Seiten-Vorlagen und entsprechenden Dropboxes eines eLearning-Kurses gezogen
bzw. kopiert werden. Erst dort lassen sich diese mit grundsätzlichen Funktionen einer
Textbearbeitung (4.4.3.3) ändern bzw. anpassen, da auf die Inhalte der Wikis aus genannten Gründen (4.2.1) nur lesend zugegriffen wird. Da die Funktionalität der Identifizierung und der Anforderung einzelner Teile (z.B Paragraph) einer Seite bereits die
API zur Verfügung stellt, ergibt sich jedoch eine weitere Option zur Verwendung des
Inhalts. Beide Möglichkeiten haben Vor- und Nachteile, die je nach Wiki und Einsatzsenario entscheidend sind und im Folgenden erläutert werden. Dementsprechend praktische
88
4.4 Autorenumgebung
Anwendungsbeispiele wurden bereits am Ende des Abschnitts 3.1.3.3 im Bezug auf das
Projekt OKAPI“ angedeutet und vorgestellt.
”
Offline-Inhalt entspricht dem zuvor genannten Vorgehen des einfachen Kopierens eines
Teils oder mehrerer Teile bis hin zur gesamten Seite und der anschließenden Bearbeitung. Ein Vorteil ist in diesem Fall, dass die Inhalte angepasst werden können
und im Folgenden persistent abgespeichert werden, wodurch man sich konkret auf
eine Version des Inhalts beziehen kann, auch wenn diese zukünftig, z.B durch Vandalismus in der ursprünglichen Quelle nicht mehr zur Verfügung steht. Als Nachteil
muss allerdings erwähnt werden, dass in diesem Fall nicht auf die speziellen Eigenschaften von Wikis eingegangen wird, nämlich dem sich ständig wandelnden,
wachsenden, teilweise fast organischen und sehr dynamischen Charakter.
Online-Inhalt beschreibt im Bezug auf die bei den Offline-Inhalten“ genannten Vor ”
und Nachteile genau das Gegenstück dessen. D.h. hier können die verwendeten Inhalte nicht bearbeitet und persistent hinterlegt werden, was z.B. bei Vandalismus zu
einem wirklichen Problem wird. Jedoch bekommt man dafür die Möglichkeit, Teile
von Wiki-Seiten direkt live in eine Anwendung integrieren zu können. Technisch
wird dabei beim Drag&Drop von z.B. einem Paragraphen nicht der Inhalt in dem
zu erstellenden Kurs eingefügt, sondern ein entsprechender Funktionsaufruf, welcher
über die API mit der ID des Elements den jeweiligen Inhalt anfordert.
Bei der Extraktion und Verwendung von Layouts und visuellen Stilen ist das Vorgehen nicht ganz so restriktiv. Zwar liefert das wikiPAGEs-Format diese Informationen
ebenfalls standardisiert und vereinheitlicht (4.3.1.1), allerdings wie in der Anfrageauf”
bereitung“ der API ( 4.2.4) bereits beschrieben in unterschiedlichen Abstufungen. Somit
ergeben sich folgende mögliche Quellen, deren Informationen mit abnehmender Sicherheit
interpretiert werden können:
1. Alle strukturellen Informationen einer Seite oder eines Teils einer Seite, die im Abschnitt 3.2.1.1 als klar“ deklariert wurden, können direkt den jeweiligen XHTML”
Tags entnommen werden.
2. Die visuellen Stile der XHTML-Tags können den entsprechenden CSS-Klassen entnommen werden, welche jeweils das Prädikat sicher“ oder unsicher“ mit sich
”
”
führen.
3. Alle strukturellen Informationen einer Seite oder eines Teils einer Seite, die als
unklar“ deklariert wurden, müssen über die entsprechenden Tags span und div
”
extrahiert werden.
4 Konzept
89
4. Die visuellen Stile der vorherigen Informationen können den entsprechenden Stylesheets entnommen werden, welche 1 zu 1 aus der ursprünglichen Seite übernommen
wurden.
Sowohl die Inhalte, als auch das Layout und die visuellen Stile können somit, je nachdem wie sicher Informationen zugeordnet werden kann, in unterschiedlichen Abstufungen
eines Automatismus extrahiert bzw. verwendet werden. Diese Abstufungen sind:
automatisch: Hierbei werden die Inhalte aus Wikis ohne Zutun des Autoren in die
Struktur einer Seite eines entsprechenden eLearning-Kurs transferiert und diesbezüglich formatiert. In diesem Fall werden alle als unsicher“ eingestuften Infor”
mationen ignoriert.
semi-automatisch: Hier verhält es sich zunächst wie bei dem automatisch“-Modus,
”
mit dem Unterschied, dass die unsicheren“ Informationen nicht einfach ignoriert
”
werden, sondern der Autor entscheiden kann, was mit ihnen geschehen soll.
manuell: Bei diesem Modus werden keine Informationen automatisch extrahiert bzw.
weiterverwendet. Alle Entscheidungen trifft der Autor.
4.4.3.3
Textbearbeitung
In dem Fall der Extraktion von Offline-Inhalten“ (4.4.3.2) bietet sich dem Autor die
”
Möglichkeit, übernommene Inhalte aus Wikis weiter zu bearbeiten oder zu ergänzen bzw.
das Layout und die visuellen Stile anzupassen. Was den diesbezüglichen Funktionsumfang
anbelangt, sollte sich zunächst an den Erkenntnissen aus dem Abschnitt 2.2.1.1 orientiert
werden, wo auf die einfachen und grundsätzlichsten Elemente der Textbearbeitung“ in”
nerhalb einer Wiki hingewiesen wird. Die dort aufgelisteten Funktionen sollten jedoch
mindestens zur Verfügung stehen, damit diesbezügliche Informationen von der Wiki über
die Autorenumgebung in den eLearning-Kurs nicht verfälscht wird bzw. gänzlich verloren
gehen.
Zusätzliche Formatierungen, wie z.B. die Anpassung der Schriftgröße oder -art, welche
in Wikis nicht üblich sind, sollten dennoch angeboten werden, da eventuell die später
verwendete eLearning-Anwendung diesbezüglich mehr Möglichkeiten bietet, von denen
der Autor gegebenenfalls profitieren kann. Diese sollten jedoch standardmäßig deaktiviert
sein, um den Autoren an dieser Stelle nicht zu überfordern und um ihm eher ein Fokus auf
das ursprüngliche Layout der Wiki-Inhalte darbieten zu können. Ob eine Funktion nun
zusätzlich aktiviert wird oder nicht, wird dann in dem jeweiligen Exportmodul definiert,
90
4.4 Autorenumgebung
da diese Funktionen sowieso von der verwendeten Anwendung und derer Möglichkeiten
abhängt.
Welche Informationen noch in den Exportmodulen untergebracht sind und wie sich diese
in konkreten Beispielen umsetzen lassen, folgt im nächsten Abschnitt.
4.4.4
Exportmodule
Die Exportmodule sind elementare, jedoch separierte Ergänzungen der Autorenumgebung,
welche idealerweise von den Entwicklern der zu behandelnden eLearning-Anwendung implementiert werden. Prinzipiell infrage kommende Anwendungen sind den Abschnitten
2.3.1 und 3.3.1 zu entnehmen. Wie in dem Abschnitt 4.4.3.1 zur Kurs- und Seitenerzeugung in der Autorenumgebung bereits funktional erläutert, müssen die Module technisch
folgenden Definitionen, Beschreibungen und Vorlagen beinhalten:
1. Prinzipielle technische Angaben über den Aufbau eines Kurses, d.h. die Aufteilung
und Einordnung in Dateien und Ordner, Beschaffenheit der Dateien und die Art
und Weise, wie die Informationen intern hinterlegt sind.
2. Informationen des Umfangs und der in Punkt (1) aufgeführten Begebenheiten im
Bezug auf die Metadaten des Kurses bzw. der einzelnen Seiten.
3. Angabe der Möglichkeiten einer strukturellen Einordnung von Seiten innerhalb eines
Kurses, wie der Zuordnung von Lektionen oder Gruppen, die Angabe einer Informationsebenen (Abstract-, Haupt-, Erweiterungs- oder Ergänzungsseite) und eine
Auflistung der möglichen Navigationselemente untereinander.
4. Definition der Beschaffenheit einer Seite bzw. den im Punkt (3) genannten Seitentypen im Bezug auf Punkt (1) und (2). D.h. wie genau eine Seite aufgebaut ist,
welchen Umfang sie einnehmen kann (textlich, medial) und wie sie untergliedert
bzw. erweitert werden kann.
5. Entsprechend zum Punkt (4) müssen gegebenenfalls Vorlagen (Templates) der Seiten in dem Exportmodul bereitgestellt werden, welche die Struktur, das Layout und
die visuellen Stile vorgeben. Hinzu kommt der im vorherigen Abschnitt (4.4.3.3)
erwähnte Punkt zur Angabe ergänzender Funktionen zur generell möglichen Textbearbeitung bei der Erstellung und Bearbeitung von Seiten.
Auf diese Punkte wird im Folgenden beispielhaft anhand der eLearning-Anwendung
LernBar“ (2.3.1.1) und dem eLearning-Standard SCORM“ (3.3.2.3) eingegangen bzw.
”
”
konkretisiert.
4 Konzept
4.4.4.1
91
LernBar
Wie im Abschnitt 2.3.1.1 und 3.1.2.1 bereits angedeutet, bestehen die Kurse der LernBar hauptsächlich aus einer Kombination von XHTML-Seiten (1), ihren CSS-Dateien (2)
und entsprechenden XML-Dateien (3). Dynamische Inhalte werden über JavaScript oder
durch die Einbindung von Flash-Filmen realisiert. Letzteres wird auch grundsätzlich für
den eigentlichen Player“ verwendet, welcher das Abspielen, Navigieren und Interagieren
”
im Bezug auf einen Kurs ermöglicht. Gefüllt und konfiguriert werden diese Flash-Inhalte
über die XML-Dateien (3), welche somit sowohl seitenbezogene Informationen beinhalten (Fragen und Antworten, dynamische Interaktionen), als auch kursbezogene, wie die
Aufteilung des Kurses in Lektionen und die Einordnung von Seiten zu Haupt- bzw. Erweiterungsseiten oder den entsprechenden Metainformationen. Die XHTML-Dateien (1)
beinhalten den eigentlichen unformatierten Inhalt einer Seite, welcher über eine zentrale
externe CSS-Dateien (2) und deren Klassen visuellen Stilen zugeordnet werden bzw. deren konkrete Anordnung auf einer LernBar-Seite beschrieben wird. Somit ergibt sich im
Bezug auf die 5 Punkte aus dem übergeordneten Kapitel 4.4.4 folgende Zuordnung:
1. Ein LernBar-Kurs (.lbc) ist ein gezipter Datei-Ordner, welcher sich in drei weitere
Ordner common“ (für allgemeine Kurselemente), lernbar“ (für LernBar interne
”
”
Dateien, wie dem Player oder Stylesheets etc.) und pages“ (für die eigentlichen
”
Seiten) untergliedert. Des Weiteren finden sich in der obersten Ebene eine index.htm
zum Starten des Kurses und eine course.xml, welche die unstrukturierten Seiten in
dem pages“-Ordner anhand von IDs in eine bestimmte Reihenfolge und Anordnung
”
bringt. Diese Seiten entsprechen wiederum jeweils einem Ordner, der die Seite an
sich (index.htm) und die dort verwendeten Ressourcen (Bilder, Flash-Filme etc.)
beinhaltet. Erwähnte dynamische Inhalte der Seite werden über eine interactive.xml
beschrieben und definiert.
2. Die meisten Metainformationen des Kurses können ebenfalls der in Punkt (1)
erwähnten course.xml entnommen werden, welche sich im Wesentlichen auf den
Titel des Kurses, seiner Sprache und Einstellungen (on-/offline, timer, randompages etc.) beziehen. Des Weiteren finden sich im common“-Ordner Angaben zum
”
Copyright der Lerneinheit.
3. Die Möglichkeiten einer strukturellen Einordnung von Seiten innerhalb eines Kurses
sind:
• Seiten gehören zu einer Lektion und/oder einer Gruppe innerhalb einer Lektion.
• Die jeweils erste Seite einer Lektion kann auf Abstract-Seiten verweisen.
92
4.4 Autorenumgebung
• Jede Seite kann Erweiterungsseiten besitzen, welche ähnlich den Abstracts eine
Abzweigung des Hauptpfads beschreiben.
• Abgesehen von der Zuordnung einer Seite unterscheiden sich diese technisch in
keiner Weise.
4. Eine LernBar-Seite besteht hauptsächlich aus drei Spalten, welche jeweils wieder halbiert bzw. auch spaltenübergreifend vereint werden können. Jeder Teil kann dann
Text, Bilder oder Videos und Animationen beinhalten, welche sich dem genannten Raster unterordnen. Texte können über Standardfunktionen formatiert werden
(fett, kursiv, unterstrichen) bzw. als Links definiert werden, welche zentral in CSSDateien hinterlegt und beschrieben sind (siehe Punkt 1). Links werden dabei als
intern (Wechsel zu einer anderen Kursseite), als extern (normale Links auf externe
Ressourcen) oder spezielle Popups und Glossar-Einträge verwendet werden. Bilder, Videos usw. haben die Möglichkeit, bildschirmfüllend angezeigt zu werden und
können über eine Bild-/Videounterschrift näher beschrieben und erläutert werden.
Komplett interaktive Seiten (Fragen-, Quiz-Seiten etc) ziehen – wie schon gesagt –
ihren Inhalt aus einer entsprechenden XML-Datei.
5. Die meisten der in Punkt (4) beschrieben Möglichkeit werden bei der LernBar über
einen Satz an Templates vorgegeben, welche ohne größere Anpassung, da sie bereits
in dem entsprechenden Format (XHMTL und externe CSS-Dateien) vorliegen, direkt
an die Autorenumgebung weitergegeben werden können.
Somit zeigt sich gerade am Beispiel der relativ einfachen Umsetzung eines Exportmoduls
für die LernBar und der damit einhergehenden Transformierung und Wiederverwendung
unterschiedlich repräsentierter Inhalte, dass die Verwendung von gängigen und anerkannten Standards gerade im Rahmen von eLearning und Internet-Technologien (z.B. XHTML,
XML, CSS etc.) und die konsequente Trennung von Layout und Inhalt, nur Vorteile mit
sich bringen. Und um diesen Punkt noch weiter auszuführen, wird im nächsten Kapitel
ein weiteres mögliches Exportmodul beschrieben, welches Inhalte soweit standardisiert
zur Verfügung stellt, dass diese überhaupt nicht mehr an eine bestimmte Anwendung
gebunden sein müssen, sondern softwareübergreifend verwendet werden können.
4.4.4.2
SCORM
SCORM als Ansammlung und Vereinigung von bestehenden und etablierten Spezifikationen zur Standardisierung der Austauschbarkeit, des Zugriffs und der Wiederverwendbarkeit von web-basierenden Lerninhalten in verschiedenen Umgebungen, ist (wie im Abschnitt 3.3.2.3 bereits beschrieben) ein idealer Kandidat für ein allgemeines Exportmodul
4 Konzept
93
einer jeglichen Autorenumgebung. Wie am Beispiel der LernBar (4.4.4.1) bereits klar
geworden ist, vereinfacht die Verwendung von Standards und Trennung von Inhalt, Layout und Metainformationen ungemein, was sich natürlich auch in diesem Fall und der
Betrachtung der fünf Punkte der Exportmodule (4.4.4) zeigt:
1. Der technische Aufbau eines Kurses, d.h. die Aufteilung und Einordnung in Dateien
und Ordner, werden bei SCORM in dem CAM ausführlich dokumentiert und kann
dementsprechend von einem Exportmodul (ähnlich der LernBar) bedient werden.
2. Innerhalb des CAMs werden Metadaten als IEEE LOMs (3.3.2.2) hinterlegt, welches
ebenfalls gut dokumentiert und in seinen neun Unterkategorien so umfangreich ist,
dass die Autorenumgebung in den meisten Fällen nur ein Bruchteil dessen nutzen
wird.
3. Ebenfalls recht umfangreich sind die Möglichkeiten und Beschreibung der Navigation anhand von Aktivitätenbäumen, welche ausführlich im SN-Dokument von
SCORM beschrieben werden. Auch hier ist eine Zuordnung relativ einfach, da die
Informationen, mit denen in der Autorenumgebung gearbeitet wird, sich bereits an
äquivalenten Standards orientiert, was eine Transformation meist vereinfacht (z.B.
XML und XSLT [G]).
4. Die Definition der Beschaffenheit einer Seite bzw. generell einer kleineren Einheit
des Kurses entspricht in SCORM Sammlung die Spezifikation des IMS CP (3.3.2.1)
und bietet ebenfalls alle Möglichkeit zur standardisierten Ablage von Daten im
allgemeinen, seien es XHTML-Datein oder eingebunden Grafiken und Videos.
5. Da SCORM eine allgemeine und standardisierte Form der Hinterlegung von
eLearning-Inhalten ist, sind Vorlagen prinzipiell möglich und können beliebige Elemente näher klassifizieren. Ob das so sinnvoll ist, wenn keine gezielte Anwendung der Inhalte vorgesehen ist, sei dahingestellt. Im Zweifelsfall könnten hier einfach die möglichen Formatierungen und Anordnungen einer Wiki angeboten bzw.
übernommen werden.
4.4.5
Erweiterungen
Zu den externen Erweiterungen seitens der Wrapper und der Export-Module, um die Autorenumbung für mehr Wikis und eLearning-Anwendungen nutzbar zu machen, gibt es
auch die Möglichkeit, die Umgebung bezüglich dem eigentlichen Authoring“ (4.4.3) zu
”
erweitern. Diese Plugins“ könnten ebenfalls auf der API bzw. auf wikiPAGEs aufset”
zen und zusätzliche Informationen aus den gegebenen Wiki-Inhalten extrahieren. Diese
94
4.4 Autorenumgebung
Informationen könnten dann wiederum von der Autorenumgebungen – nach kleineren Anpassung – für den Autoren zugänglich gemacht werden, um diese bei der Erstellung von
eLearning-Inhalten berücksichtigen zu können (4.4.3.2).
Während die Autorenumgebung zunächst prinzipiell einen vereinheitlichten Zugang für
eine Vielzahl von Wikis zur Verfügung stellt und die Aufbereitung des Inhalts den klaren
Fokus auf die Interpretation des Layout und der visuellen Stile erfährt, sind Erweiterung
seitens der Metainformationen (1), seitens des Kontextes von Seiten und Wikis (2) und
seitens weiterer Analysen bezüglich des eigentlichen Inhalts einer Seite (3) denkbar.
Zwei konkrete Erweiterungen in diesem Sinne wären somit die Ergebnisse aus der Diplomarbeit Extraktion semantischer Informationen aus Wiki-Systemen“ von Sarah Voß
”
und aus der Arbeit Pfadbasierte Navigation in Wiki-Inhalten“ von Lars Jung, auf welche
”
diesbezüglich in den folgenden zwei Kapiteln eingegangen wird.
4.4.5.1
Navigationspfade (WikiPaths)
Dem Punkt (2) aus dem übergeordneten Abschnitt 4.4.5 entsprechend könnten z.B. einzelne Seite durch thematisierte Pfade soweit in einen Kontext gesetzt werden, dass sich
– Wiki-übergreifend – ein roter Faden durch die Menge an Informationen eines Wikis“
”
zieht, welcher dann vom Autoren interpretiert werden kann.
Hierbei ist denkbar, dass Pfade sowohl aus Annotationen (1), die bereits in der Wiki verankert sind, als auch aus dynamischen aufgezeichnet“ bei der Erkundung einer Wiki (2),
”
generiert werden. Das Pfad-Tool“, welches diese Funktionen bzw. die generierten Pfade
”
liefert, könnte wie die Autorenumgebung selbst die API zur grundsätzlichen Beschaffung
der Informationen im Fall (1) nutzen bzw. zur Umsetzung einer eigenen Autorenumgebung, welche das Tracking (Aufzeichnen) von Wiki-übergreifenden Pfaden im Fall (2)
ermöglicht.
In beiden Fällen entstehen für die Autorenumgebung von wikiPAGEs nützliche Informationen, die z.B. bei der Definition eines Navigationspfades in einem eLearning-Kurs
automatisch übernommen werden können oder zumindest unterstützend dem Autor zur
Verfügung stehen. So wäre es z.B. möglich, dass ein Autor allein durch das Durchschreiten von Wiki-Seiten in dem Pfad-Tool Seiten eines LernBar-Kurses generiert, welche dann
graphisch und inhaltlich über die Autorenumgebung aufbereitet und letztendlich über das
LernBar-Portal als Interpretation einer eingesetzte Wiki (vielleicht zur Evaluierung) zur
Verfügung gestellt wird.
Weitere Informationen im Bezug auf eine manuelle, semi-automatische oder automatische
Ermittlung von nutzerspezifischen Navigationspfaden in Wiki-Systemen finden sich in den
4 Konzept
95
Arbeiten [Sil06] und [Bra06].
4.4.5.2
Semantische Informationen
Neben einer Erweiterung im Bezug auf den Kontext von Seiten innerhalb von Wikis und
Wiki-übergreifend (wie bei WikiPaths) sind auch Erweiterungen im Bezug auf den eigentlichen Inhalt einer Seite (2) denkbar und nützlich. In der Arbeit Extraktion semantischer
”
Informationen aus Wiki-Systemen“ von Sarah Voß [Vos06] wird genau darauf eingegangen.
Hierbei wird zunächst zwischen strukturierten, semi-strukturierten und unstrukturierten
Texten unterschieden (3.2.1.1), anhand derer anschließend analysiert wird, welche semantischen Informationen explizit bzw. implizit5 extrahiert werden können. So wurden
Algorithmen zur Extraktion von sicheren“ Informationen im Bezug auf die Wiki, eine
”
Seite oder einen Autoren entwickelt bzw. Heuristiken zur Extraktion von unsicheren“
”
Informationen. Somit wurde es ermöglicht, Aussagen über Synonyme, Akronyme oder
Homonyme der z.B. im Titel einer Seite vorkommenden Wörter zu treffen oder über die
Extraktion von hervorgehobenen bzw. häufigen Wörtern Schlüsselwörter zu definieren.
Diese könnten dann z.B. Kategorien einer Wiki zuordnen werden, aus denen man weitere
Schlüsse ziehen könnte.
All diese Informationen, die dabei bezüglich einer Seite oder der gesamten Wiki entstehen, könnten in der Autorenumgebung zur Verfügung gestellt werden, um auch hier dem
Autoren nützliche Details zu unterbreiten, die ihm in seinem Prozess der Produktion es
eLearning-Kurses und diesbezüglicher Entscheidungen unterstützen.
5
explizit sind z.B. alle ausgehenden Links, wohingegen eingehende Links nur implizit vorliegen
Kapitel 5
Implementierung
Das im vorangegangen Kapitel entwickelte Konzept einer Autorenumgebung zur Erstellung von eLearning-Kursen aus Wiki-Inhalten wird in diesem Abschnitt prototypisch implementiert und auf die Machbarkeit hin überprüft. Das Kapitel ist nach der allgemeinen
Architektur“ der Implementierung (5.1) in zwei Unterabschnitte unterteilt, dem der Um”
setzung der API (5.2), welches sich im Wesentlichen auf die Wrapper und die Überführung
der Inhalte in das wikiPAGEs-Format fokussiert und dem der eigentlichen Autorenumgebung (5.3). Letztere unterteilt sich wiederum in ihre Funktionen“ und das entsprechende
”
User Interface“ (5.3.1), das Datenbankdesign und Caching“ (5.3.2) und die Umsetzung
”
”
des entsprechenden Exportmoduls“ (5.3.3) der LernBar.
”
Bild 5.1: Startseite der Autorenumgebung
Bei der Umsetzung wurden die in der Tabelle 5.1 aufgelisteten Technologien und Anwen-
98
5.1 Architektur
dungen verwendet bzw. berücksichtigt. Des Weiteren flossen folgende Arbeiten bei der
Implementierung seitens der API und der Autorenumgebung ein: Die Arbeiten [Kur06],
[Chr07b] und [Max06] bei der Anfragenaufbereitung“ (5.2.2) und beim wikiPAGEs”
”
Format“ (5.2.3.1). Bei der Implementierung der Wrapper“ (5.2.1) die Arbeiten [Vos06]
”
und [Sha05]. Seitens der Schnittstellen“ (5.2.3) [JMC02] und bei der Transformierung in
”
den Exportmodulen“ (5.3.3) [Paa05].
”
Tabelle 5.1: Verwendete Technologien
Einsatzgebiet
Technologie
Version
Web-Server
- Apache
2.2.8
Datenbanksystem
- MySQL
5.0.45
API, Wrapper,
- PHP (serverseitig)
5.2.5
Autorenumgebung
- JavaScript (clientseitig)
1.6
Datenrepräsentation
- XHTML
1.1
- XML
1.0
Wiki-Engine
- MediaWiki
1.12.0
Arbeitsumgebung,
- Apple Mac OS X
10.5.2
Betriebssysteme
- Microsoft Windows Vista
SP1
- Microsoft Windows XP
SP3
- Microsoft Internet Explorer
6/7/8 beta
- Mozilla Firefox (OS X/Vista)
3 beta
- Apple Safari (OS X/Vista)
3.1.1
Testbrowser
Grundsätzlich erwiesen sich die Seiten des SELFHTML e.V. [SEL08], die des W3Cs
[Con08] und speziell im Rahmen der Implementierung das PHP Handbuch”[PHP08] als
”
sehr nützlich.
5.1
Architektur
Die in dem Konzept beschriebenen Funktionen der API, der Wrapper und der Autorenumgebung wurden wie folgt auf entsprechende Klassen und ihre Objekte verteilt (Bild: 5.2):
Die Autorenumgebung (4.4) erzeugt bei der Anfrage eines Autoren als oberste Schicht in
der Architektur zunächst eine Instanz der Klasse wikiPAGEs“ im direkten Bezug auf
”
den angemeldeten Benutzer (4.4.2.2) und dessen im Wiki-Pool enthaltenen Wikis. Anhand dieser Wikis, den dazugehörigen Informationen (4.4.2.3) und den entsprechenden
Anfragen an die API werden von dieser bzw. den Wrappern (4.2.2) Instanzen der Klasse
5 Implementierung
99
Wiki“ erzeugt. Diese Wiki“-Objekte liefern Ergebnisse in Form eines Page“-Objekts
”
”
”
zurück, welches von API aufbereitet und als wikiPAGEs“-Format an die Autorenumge”
bung zurückgesendet wird. Wie im Abschnitt 4.3 beschrieben unterscheidet sich diese je
nachdem, ob Seiten, Seitenteile oder allgemeinen Wiki-Funktionen angefordert wurden.
Diese Informationen werden dann dementsprechend von der Autorenumgebung interpretiert und dort dem ursprünglichen wikiPAGEs“- bzw. Wiki“-Objekt als Instanz einer
”
”
Page“ angehängt. Diese erzeugt bei deren Analyse wiederum Section“-Objekt usw.
”
”
Bild 5.2: Klassendiagramm des Lösungsansatzes
Jedes dieser Objekte bringt spezifische Methoden und Attribute mit sich, welche im einzelnen dem Bild: 5.2 entnommen werden können, was sich – wie bereits erwähnt – nur auf
die Anforderung einer Wiki, einer Seite bzw. einzelner Abschnitte bezieht. Allgemeinere
Funktionen enden bei der Erzeugung von Wiki-Objekten und werden dort abgehandelt.
Alle weiteren Funktionen der Autorenumgebung basieren auf den entsprechenden Aufrufen der abhängig von dem Objekt zur Verfügung stehenden Methoden, welche dem
100
5.2 API
jeweiligen Benutzer visualisiert werden. Die darauf basierende Produktion es eLearningKurses ergibt sich dann aus den in den Exportmodulen (4.4.4) beschriebenen Funktionen
und Eigenschaften, welche wiederum von der Autorenumgebung nur noch angezeigt und
nutzbar gemacht werden müssen.
5.2
API
Wie bereits beschrieben, nimmt die API Anfragen der Autorenumgebung (5.2.3) entgegen (A) bzw. liefert die Antworten in dem wikiPAGEs-Format (5.2.3.1) zurück (D). Die
Funktionen, die der Autorenumgebung dabei zur Verfügung stehen, werden im KonzeptKapitel 4.2.3 erläutert bzw. im vorangegangen Abschnitt 5.1 den einzelnen Komponenten
zugeteilt. Je nachdem werden die Anfragen dann diesbezüglich übersetzt und an die Wrapper (5.2.1) weitergegeben (B) bzw. deren Antwort (C) aufbereitet (5.2.2).
Bild 5.3: Anfragenbearbeitung der API
Optional könnten an dieser Stelle (halbtransparenten Pfeile) zusätzliche Anfragen von
Erweiterungsmodulen (4.4.5) angenommen oder durch die Nutzung der API gewonnene
Informationen in der Datenbank der Autorenumgebung (5.3.2) gespeichert werden, um
diese später in Ergebnisse seitens der Autorenumgebung oder der API selbst nutzen zu
5 Implementierung
101
können.
5.2.1
Wrapper: MediaWiki
Wie in dem Abschnitt über Wiki-Engines“ (2.2.2) nachzulesen ist, beschränkte ich mich
”
bei meiner Betrachtung auf drei recht populäre Open-Sources-Engines: MoinMoin, TWiki
und MediaWiki. Letztere gilt aufgrund des häufigen Einsatzes und der großen Nutzerzahlen als äusserst zuverlässiges und schnelles System und bietet mit der Wikipedia1 eine
weitreichende Möglichkeit für Testläufe. Deshalb habe ich mich bei der Implementierung
eines prototypischen Wrappers für die MediaWiki-Engine entschieden und entsprechend
umgesetzt.
Die Analysen in dem Abschnitt 3.2.2.1 ergaben vier Möglichkeiten des Zugriffs auf Wikis
und ihre Seiten. Diese sind in der Tabelle 5.2 konkret bezogen auf die MediaWiki (in
dem Fall die Wikipedia und der Artikel E-Learning“) gelistet. Die 2. Möglichkeit der
”
ursprünglichen Analyse, nämlich die Anforderung der Seite über XHTML 1.1, wird von
der MediaWiki nicht unterstützt und fehlt dementsprechend.
Tabelle 5.2: Schnittstellen der MediaWiki
Zugriffstyp
HTML:
Wiki-Syntax:
XML:
Umsetzung in der MediaWiki
. . . /index.php?title=E-Learning&action=render
. . . /index.php?title=E-Learning&action=raw
. . . /index.php?title=Spezial:Exportieren/E-Learning
Wie in dem Konzept (4.2.2.2) beschrieben, sollte nach Möglichkeit letztgenannter Zugriffstyp verwendet werden, welcher uns eine valide XML-Datei mit Metadaten und dem
eigentlichen Inhalt der Seite in der MediaWiki-Syntax liefert. Mit Hilfe von SimpleXML
(eine Erweiterung von PHP-Version 5) und dem integrierten XPath Prozessor [G] wird
nun über einfache Pfadangaben entlang der XML-Tags auf gesuchte Elemente zugegriffen
und diese weiterverarbeitet. In dem Fall des eigentlichen Seiteninhalts und im Bezug auf
das Beispiel der MediaWiki ist das der XML-Tag <text xml:space=”preserve”>“.
”
Nun wird der Inhalt der Seite mit Hilfe von regulären Ausdrücken entsprechend der
MediaWiki-Syntax geparst, deren Elemente durch die des WikiCreole-Projekts ersetzt
werden (Bild: 3.5).
Alle weiteren Funktionen aus dem Kapitel 4.2.2.1, wie z.B. das Logout, werden über
1
http://de.wikipedia.org/
102
5.2 API
einfache HTTP POST Requests bedient. In diesem Fall durch den Aufruf der URL der
Wikipedia mit dem Zusatz . . . /index.php?title=Spezial:Userlogout“.
”
Die Ergebnisse werden in jedem Fall einheitlich in Form einer XML-Struktur (wie in 4.2.2.3
beschrieben) intern an die API übergeben und entsprechend dort weiterverarbeitet. Die
Wrapper selber befinden sich in einem entsprechenden Verzeichnis und jeweils in einer
separaten PHP-Datei. Jeder weitere Wrapper einer alternativen Wiki-Engine muss somit
dementsprechend dort hinterlegt sein, woraufhin die API diesen erkennt und entsprechend
verwendet.
5.2.2
Anfragenaufbereitung
Um die erhaltene XML-Struktur (4.2.2.3) in das im nächsten Abschnitt behandelte wikiPAGEs-Format überführen zu können, müssen hauptsächlich die konkreten Seiteninhalte bearbeitet werden. Anfragen, die lediglich eine Liste oder entsprechende Statusmeldungen (4.2.4) hervorbringen, werden nun mittels einer diesbezüglich definierten XSLDatei [G] umgewandelt, um als XHTML-Datei direkt in den gängigen Browsern angezeigt
werden zu können.
Die Bearbeitung des Seiteninhalts erfolgt in zwei Schritten:
1. Alle im Abschnitt 4.2.4 als unkritisch (sicher) und unkritisch (unsicher) deklarierten Elemente der Seite werden mittels einer entsprechenden XSL-Datei in
reine XHTML-Tags überführt, deren visuellen Stile in einer vordefinierten externen
CSS-Datei vorliegen (siehe 4.3.2). Je nachdem werden sie zusätzlich entweder der
CSS-Klasse wi-derived“ oder der Klasse wi-confirmed“ zugeordnet.
”
”
2. Alle im Abschnitt 4.2.4 als kritisch erachteten Elemente der Seite werden entsprechend ermittelt und erzeugen – jedes für sich – eine eigene CSS-Klasse zur Unterbringung des eigenen Stils. Zusätzlich werden diese der CSS-Klasse wi-critical“
”
zugeordnet (siehe 4.3.2).
Somit erhält man eine valide XHTML-Datei, deren Inhalt sauber getrennt von den verwendeten visuellen Stilen vorliegt, welche von einfachen Tools missachtet und die Seite entsprechend ihrer Standard-Darstellung angezeigt werden kann, währenddessen von
komplexere Tools diese Informationen (anhand der CSS-Klassen und deren Werten) zur
weiteren Interpretation herangezogen und diesbezüglich weiterverarbeitet werden können.
5 Implementierung
5.2.3
103
Schnittstellen
Als mögliche Schnittstellen der API (siehe 4.2.5) wurden zusätzlich zu der wichtigsten,
dem Versenden von XHTML-Dateien im wikiPAGEs-Format, testweise auch Prototypen
eines SOAP-Webservices [G] und zum Versenden der Daten ein entsprechendes JSONFormat [G] implementiert. Beide bieten jeweils Alternativen im Bezug auf den Aufruf
von Funktionen (SOAP) bzw. dem Empfangen von Ergebnissen (JSON) und können – je
nachdem – angeboten werden.
Der SOAP-Webservice besteht im Wesentlichen aus den Klassen der API und deren Beschreibung der Schnittstellen in einer Web Services Description Language (WSDL)-Datei2 .
Beispielhaft werden die Funktionen der API dann in PHP wie folgt aufgerufen:
$client = new SoapClient(’.../WikiPages.wsdl’);
// show all functions of the webservice
// print_r($client->__getFunctions());
// call a function and show the return value
$page = $client->getPage(’E-Learning’);
echo $page;
Clientseitige Zugriffe, welche dem obigen Beispiel entsprechen, da die Funktion natürlich
von einem anderen Server aus aufgerufen wurde, beschränken sich nicht nur auf die Verwendung von PHP, sondern können über alternative SAOP-Clients in diversen Programmiersprachen realisiert werden.
Im Gegensatz dazu kam als Alternative beim Empfangen von Daten, entsprechend JSON
zum Einsatz. In PHP ist diesbezüglich die JSON-Erweiterung ab Version 5.2.0 standardmäßig aktiviert, was die Verarbeitung besonders einfach macht. Als Funktion stehen
dafür json decode“ und json encode“ zur Verfügung, wobei im Bezug auf die API ledig”
”
lich letzteres benötigt wurde. Die Vor- und Nachteile von JSON wurden ebenfalls – wie
auch generell im Bezug auf Schnittstellen – schon im Abschnitt 4.2.5 behandelt.
5.2.3.1
wikiPAGEs
Entsprechend des Konzepts von wikiPAGEs (4.3) wurden an dieser Stelle prototypische
Versionen zur Beschreibung einer Seite (Anhang B.1), deren Kontext (Anhang B.2) und
2
http://www.w3.org/TR/wsdl
104
5.3 Autorenumgebung
deren visuell Stile (Anhang B.2) umgesetzt. Im Einzelnen finden sich deren Konzeption,
welche im Wesentlichen 1 zu 1 bei der Implementierung übernommen wurde, in den Abschnitten Konzept einer Wiki-Seite“ (4.3.1), Layout und visuelle Stile“ (4.3.1.1) und
”
”
Metadaten“ (4.3.1.2) bzw. Seitenkontext und IDs“ (4.3.1.3) wieder.
”
”
Wie im vorangegangen Abschnitt bereits erwähnt, wird die Transformation von einer ursprünglichen Wiki-Seite hinzu einer standardisierten wikiPAGE im Wesentlichen über
XSL-Dateien (XSLT-Stylesheets) definiert. Technisch sieht das in PHP so aus, dass nach
dem Laden der XML- bzw. der XSL-Datei jeweils über ein DomDocument“-Object und
”
dem Funktionsaufruf load(’page.xml’)“ bzw. load(’wp uncritical.xsl’)“ zunächst über
”
”
new xsltprocessor“ ein entsprechendes Objekt des XSLT-Prozessors erzeugt wird. Die”
ses stellt dann wiederum Methoden zur Verfügung, um eine entsprechende XSL-Datei
zu importieren importStyleSheet($xsl)“ und auf eine XML-Datei anwenden zu können
”
transformToXML($xml)“.
”
Entsprechende Beispiele der XHTML-, XML- und CSS-Dateien finden sich – wie anfangs
in diesem Abschnitt erwähnt – im Anhang B am Ende dieser Arbeit.
5.3
Autorenumgebung
Nachdem nun die API zur Verfügung steht und die jeweiligen Funktionen über eine URL
aufgerufen werden können, sieht die Anfragenbearbeitung seitens der im Abschnitt 4.4
konzipierten Autorenumgebung wie folgt aus (Bild 5.4): Da alle Funktionen der Autorenumgebung (5.3.1) benutzerspezifisch behandelt werden, muss sich zunächst ein entsprechend registrierter Autor im System anmelden. Der Benutzername wird anhand einer
Datenbankabfrage überprüft (A), woraufhin im positiven Fall eine entsprechende Session
erzeugt wird. Diesbezüglich lädt die Autorenumgebung wiederum mit entsprechenden Anfragen an die Datenbank (5.3.2) die persönlichen Einstellungen des Autoren, allen voran
die zuvor konfigurierten Informationen seines Wiki-Pools (siehe 4.4.2.3)
Anhand des Wiki-Pools erzeugt nun das wikiPAGEs“-Objekt (Bild: 5.2) innerhalb der
”
Basistools der Autorenumgebung (B) Objekte der wiki“-Klasse, welche dann bei entspre”
chenden Funktionsaufrufen Anfragen an die API schicken (C). Die ersten Funktionsaufrufe veranlasst gegebenenfalls schon der Konstruktor, wie z.B. login(username, password),
wenn bezüglich einer Wiki im Pool ein Benutzername und das Passwort hinterlegt wurde.
Somit bezieht sich eine Anfrage an die API immer genau auf eine Wiki und dementsprechend auf eine Funktion oder eine Seite.
Als Antwort erhält die Autorenumgebung eine Wiki-Seite, einen Teil einer Wiki-Seite,
eine Liste von Wiki-Seiten oder Statusmeldungen (D), wobei die ersten beiden dem wi-
5 Implementierung
105
kiPAGEs-Format (5.2.3.1) entsprechen. Man beachte, dass die Funktionalität sowohl bei
der Anfrage, als auch bei der Antwort, absolut Wiki-unabhängig sind und der Autor
nur auf Wunsch (oder bei entsprechend spezialisierten Abfragen) erfährt, wo die Daten
ursprünglich herstammen.
Um nun die erhaltenen Informationen weiter verwenden zu können, muss der Autor ein
entsprechendes Exportmodul (5.3.3) laden, in diesem Fall das der LernBar (D). Darin enthalten finden sich Informationen (siehe 4.4.4.1) zur allgemeinen und speziellen Beschreibung zur Kurs- und Seitenerzeugung (5.3.3.1) und den entsprechenden Möglichkeiten bei
der Textbearbeitung (5.3.3.2). Nach der Fertigstellung des eLearning-Kurses werden wiederum auf der Basis der Informationen aus dem Exportmodul (D) die nötigen Dateien
entsprechend serverseitig zusammengepackt und dem Autoren zum Download angeboten.
Bild 5.4: Anfragenbearbeitung der Autorenumgebung
Wie bei dem Bild 5.3 der Anfragenbearbeitung der API auch, stellen die halbtransparenten Pfeile optionale Kommunikationsstellen dar. So könnte z.B. wie schon erwähnt die
API und die Autorenumgebung eine gemeinsame Datenbank mit zusätzlichen Informationen bezüglich der Anfragen und Ergebnisse füllen, um bei zukünftigen Anfragen eventuell
Rückschlüsse ziehen zu können. Des Weiteren sind natürlich zusätzliche Exportmodule
möglich, wie z.B. das im Abschnitt 4.4.4.2 erwähnte SCORM. Seitens der Erweiterungen
106
5.3 Autorenumgebung
(4.4.5) sind Ansatzpunkte auf der Ebene der API, der Basistools oder der Autorenumgebung und den höheren Tools denkbar bzw. realisierbar.
5.3.1
Funktionen und User Interface
Das User Interface (UI) wurde entsprechend dem Abschnitt 4.4.1 prinzipiell dem einer
Wiki nachempfunden. Es wurde bewusst auf aufwendige Effekte verzichtet, um die Seiten schlank und schnell zu halten. Das UI besteht aus einem großen Anzeigebereich für
den eigentlichen Inhalt und einer recht klein gehaltenen dynamischen Navigationsleiste,
welche je nachdem, welche Nutzerrechte vorliegen und welche entsprechenden Funktionen
zur Verfügung stehen, angepasst angezeigt wird. Rechts unten befinden sich auf jeder
Seite kleine Schaltflächen, um die Sprache der Umgebung wechseln zu können, was ebenfalls der häufigen Mehrsprachigkeit einer Wiki entspricht. Diesbezüglich wurden alle in
den Seiten vorkommenden Strings in separate Dateien ausgelagert und können jederzeit
ergänzt bzw. geändert werden. Eine ähnliche Abstraktion wurde auch seitens des Layouts
implementiert, welche es ermöglicht Skins zu definieren, die bei Bedarf gewechselt werden
können. In dem Bild 5.5 ist gerade die Seite zur direkte Anfrage (wikiPAGEs) zu sehen
mit der entsprechenden Navigation eines Standardbenutzers (Autor).
Bild 5.5: User Interface der Autorenumgebung
Jeder Navigationseintrag entspricht dabei genau einer PHP-Seite, welche serverseitig
5 Implementierung
107
die jeweilige Funktionalität zur Verfügung stellt. Clientseitige Funktionen, wie z.B. das
Drag&Drop bei der Seitenproduktion, sind entsprechend in JavaScript implementiert. Die
wichtigsten allgemeinen Funktionalitäten sind diesbezüglich im Einzelnen:
• wikiPAGEs für direkte Anfragen an eine bestimmte Wiki (muss nicht im Pool sein)
• wikiPOOL zur Konfigurierung der Wiki-Sammlung
• die Autorenumgebung für Anfragen an den Wiki-Pool und entsprechenden Zuordnungen zu eLearning-Kursen aus den Exportmodulen
• die Exportwerkzeuge zur Konfiguration der jeweiligen Module (z.B. LernBar)
• generelle Konfigurationsseiten für allgemeine Einstellung oder der Verwaltung
von Benutzern, Wrappern oder Exportmodulen
Im Bezug auf die benutzerspezifisch generierte Navigationsleiste und die im Konzept beschriebenen Benutzergruppen (4.4.2.2) bedeutet dies eine entsprechende Verteilung, welche der Tabelle 5.3 entnommen werden kann.
Tabelle 5.3: Benutzerspezifische Funktionen
Benutzergruppe
Administrator:
Funktionen
Benutzerseite, Statistiken, Tests, Benutzer, Wrapper, Exportmodule, Einstellungen, abmelden
Author:
Benutzerseite, wikiPAGEs, wikiPOOL, Autorenumgebung,
Exportwerkzeuge, abmelden
Anonymous:
5.3.2
Benutzerseite, wikiPAGEs, abmelden
Datenbankdesign und Caching
Die verwendete Datenbank in dieser prototypischen Implementation beschränkt sich
zunächst auf zwei Tabellen. Der zur Verwaltung der Benutzer-Accounts und der für die
Wiki-Pools, welche im Einzelnen der Tabelle 5.4 entnommen werden können. Alle weiteren benötigten Daten seitens der Wrapper und der Exportmodule werden auf Dateiebene
bezogen. Bei den Exportmodulen über eine entsprechende XML-Datei und seitens der
Wrapper wird prinzipiell jeder eingebunden, dessen PHP-Seite im wrapper“-Verzeichnis
”
der API liegt.
108
5.3 Autorenumgebung
Tabelle 5.4: Relationen der Autorenumgebung
Relationen
Attribute
users
username, password, forename, surname, language, reg date,
last login
wikis
username, wikiname, server, directory, interface, wiki user, wiki pass
Das im Konzept-Kapitel beschriebene Caching (4.4.2.4) setzt voraus, dass ein entsprechender Ordner mit Schreibrechten zur Verfügung steht, in dem die jeweiligen Seiten
zwischengespeichert werden können. Prinzipiell bleiben die Seiten so lange gespeichert,
bis eine Seite erneut angefordert wird und eine entsprechend neue Version in der Wiki
vorliegt.
5.3.3
Exportmodul: LernBar
Wie im Unterabschnitt des Konzepts eines LernBar-Exportmoduls (4.4.4.1) bereits beschrieben, bestehen die Module prinzipiell aus 5 Teilen zur Beschreibung eines Prozesses
zur Kurs- bzw. Seitenerzeugung (5.3.3.1) und zur Aktivierung bzw. Konfigurierung entsprechender Werkzeuge zur Textbearbeitung (5.3.3.2).
Konkret beinhaltet somit das entsprechend umgesetzte LernBar-Exportmodul folgende
in einem Ordner zusammengefasste Dateien (die Zahlen in den Klammern referenzieren
jeweils auf den in Abschnitt 4.4.4 aufgeführten Listenpunkte):
• Eine course.xml auf oberster Ebene zur Definition der allgemeinen Begebenheiten
bei der Erzeugung eines LernBar-Kurses (1) und den entsprechenden möglichen
Metainformationen (2).
• Eine page.xml zur Beschreibung der Begebenheiten bei der Erzeugung und Einordnung einer LernBar-Seite (3) und den Einstellungen bezüglich der allgemeinen
Textbearbeitung (4).
• Die entsprechenden visuellen Stile sind einer page.css hinterlegt zur angepassten
Anzeige bezüglich der Positionen von Seitenelementen bzw. deren visuellen Formatierungen (4).
• Die eigentlichen Vorlagen für die Erzeugung einer LernBar-Seite, in diesem Fall 34
XHTML-Dateien, befinden sich in einem separaten Template-Verzeichnis und einer
5 Implementierung
109
kodierten Dateibenennung im Bezug auf die enthalten Elemente (Bilder, Bildgrößen
und Texte).
Diese Art der Verteilung der in 4.4.4 geforderten Informationen auf entsprechende Dateien
kann zur Orientierung für zukünftige Exportmodule betrachtet werden.
5.3.3.1
Kurs- und Seitenerzeugung
Bei der Erzeugung eines Kurses seitens des Autoren wird nach der Wahl des entsprechenden Moduls, hier dem zuvor beschriebenen LernBar-Modul, zunächst die Informationen
aus der course.xml gelesen und diesbezüglich in einem Temp-Verzeichnis (benutzerspezifisch) ein leeres Gerüst“ eines LernBar-Kurses erzeugt. Dies entspricht einem ersten
”
Teil des 2. Punkts im Abschnitt des Konzepts zur Kurs- und Seitenerzeugung“ (4.4.3.1).
”
Der dort aufgeführte 1. Punkt im Bezug auf die benötigten Meta-Daten wie z.B. dem
Kurstitel oder den Angaben des Copyrights werden dann über entsprechende HTMLFormulare von dem Autoren angefordert und wiederum entsprechend der Informationen
in der course.xml in die bestehende Kurs-Struktur geschrieben. Hiermit sind alle For”
malitäten“ erledigt und der Autor kann mit der eigentlichen Produktion von Seiten bzw.
deren Inhalt beginnen.
Bild 5.6: Seitenproduktion eines LernBar-Kurses
110
5.3 Autorenumgebung
Über einen Link zum Funktionsaufruf Seite anlegen“ wird über ein entsprechendes For”
mular dem Autoren alle Möglichkeiten (beschrieben in der page.xml ) zur Einordnung
dieser Seite innerhalb des Kurses bzw. der zur Verfügung stehenden Templates aufgelistet. Bei später neu hinzugefügten Seiten werden die Einordnungsmöglichkeiten entsprechend der schon existierenden Kursstruktur angezeigt bzw. vorgeschlagen. Nach der Wahl
der Position und des zu verwendenden Templates wird die Seite anhand der entsprechenden template.xhtml und im Standard-Layout aus der page.css erzeugt und in einem
zusätzlichen Fenster angezeigt. Somit ergibt sich für den Autoren eine Dreiteilung des
Arbeitsbereichs (Bild 5.6), die Anzeige der Inhalte aus der Wiki und seitenspezifische
Funktionen, die modellartige Anzeige der bereits existierenden Kursseiten und der neu zu
erstellenden bzw. zu editierenden Kursseite in einem entsprechenden Popup (Bild 5.7).
Die sich auf eine Seite bezogenen Möglichkeiten der Textbearbeitung und deren Umsetzung werden in dem folgenden Abschnitt erläutert.
5.3.3.2
Textbearbeitung
Die in einem separaten Fenster angezeigte Seite enthält in der Startkonfigurationen so
genannte Dropboxen“ (einfache mit IDs versehende <div>-Tags), auf die der gewünschte
”
Inhalt einer im Hauptfenster angezeigten Wiki-Seite per Drag&Drop gezogen werden kann
(Bild 5.7).
Bild 5.7: Seitenbearbeitung eines LernBar-Kurses
Die in dem Abschnitt 4.4.3.3 beschriebenen Funktionen und die über die page.xml bestimmten Werkzeuge zur Textbearbeitung werden über ein entsprechendes Kontextmenü
in Anlehnung an die Umsetzung im LernBar-Studio (3.1.2.1) bedient. Somit können mit
5 Implementierung
111
einem Rechtsklick auf die zu bearbeitenden Textpassagen (Absätze, Wörter) oder Medien (Bilder) die entsprechend möglichen Formatierungen von dem Autoren gewählt bzw.
vorgenommen werden. Diese clientseitigen Funktionalitäten wurden im Wesentlichen mit
JavaScript [G] und dem Document Object Model (DOM) implementiert und umgesetzt.
Kapitel 6
Zusammenfassung
Wie anfangs in meiner Zielsetzung (1.2) beschrieben, sollte diese Arbeit dem dort
erwähnten Leitsatz folgen und den Zugriff auf die Inhalte von Wikis vereinfachen und
”
ihren Nutzen im Sinne der Lehre erhöhen“. Für die Entwicklung einer diesbezüglichen Autorenumgebung bedeutete dies, dass mit ihrer Unterstützung und mit einem vertretbaren
Aufwand die entsprechenden Veranstaltungen zu überblicken bzw. auszuwerten sind, um
diese dann zu interpretieren und entsprechend aufbereitet in Form von eLearning-Kursen
im Sinne der Lehre wieder zur Verfügung stellen zu können.
Dies erforderte zunächst, die entsprechenden Sachverhalte im Hinblick auf die Erwartungen der Lernenden und Lehrenden und deren Entsprechung in der Realität zu bestimmen bzw. zu untersuchen. Somit begann ich, nach einer grundsätzlichen Einführung in
das Thema Wiki“ (2.2) und eLearning“ (2.3) in dem Kapitel Autorenprozesse und ”
”
”
umgebungen“ (3.1) mit den entsprechenden Analysen. Dort erwies sich als problematisch,
dass durch die bezeichnende Philosophie einer Wiki: Jeder ist Autor“, den eigentlichen
”
Autoren, nämlich den lehrenden Kräften einer Veranstaltung, schlichtweg die Mittel fehlen, um gegenüber den Lernenden eine privilegierte Rolle einnehmen zu können (3.1.4).
Diese Rolle ist letztendlich notwendig, um mit einem gewissen Abstand die Gegebenheiten
überblicken bzw. beobachten zu können und in Folge dessen – in einem weiteren Schritt
– motivierend, unterstützend bzw. konstruktiv und produktiv auf die Wiki einzuwirken.
Zur Entwicklung eines solchen Werkzeuges“, der Autorenumgebung (4.4), ergaben meine
”
weiteren Analysen, dass es an dieser Stelle zunächst notwendig ist, von all den unterschiedlichen Wikis zu abstrahieren, um es den Autoren zu ermöglichen, nicht Wiki-spezifisch
zu arbeiten, sondern mit einem Konzept: Wiki“ im Bezug auf die Wiki-Inhalt ( wi”
”
kiPAGEs“ 4.3) und deren Zugriff ( API“ 4.2). Dies war insbesondere auch deswegen
”
notwendig, da gerade im universitären Umfeld oft interdisziplinär mit einer Vielzahl von
Wiki-Engines gearbeitet wird, weshalb eine Einzellösung innerhalb einer Engine nicht in
114
6.1 Ausblick
Frage kam.
Die Analysen bezüglich eines solchen Konzepts einer Wiki (3.2) im Hinblick auf die Integration (3.2.2) und Harmonisierung (3.2.1) von Wiki-Inhalten führten zu einer Vielzahl
von bereits bestehenden Lösungsansätzen, welche diesbezüglich untersucht und im Konzept berücksichtigt wurden. In diesem Zusammenhang etablierten sich insbesondere die
Arbeiten des WikiCreole-Projekts (3.2.1.3), das Wiki Interchange Format (3.2.1.4) und
das WikiGateway (3.2.2.3), welche jeweils in der Konzeption und Implementation der API
zum Teil erweitert bzw. angepasst eingeflossen sind.
Dieses Konzept einer modularen und somit leicht erweiterbaren API zur Engineunabhängigen Abfrage von Wikis und einem entsprechend standardisierten Zwischenformat (wikiPAGEs) mit dem Fokus auf Layout und visuelle Gestaltung von Inhalten
führten letztendlich zu dem Ergebnis: Autoren von eLearning Kursen ein Werkzeug zur
Verfügung stellen zu können, welches unter der Beachtung der Analysen von eLearningInhalten (3.3.1) und deren Standards (3.3.2) es ermöglicht, mit einem vertretbaren Aufwand die entsprechenden Wikis überblicken zu können bzw. auszuwerten und interpretiert
aufbereitet der Lehre zur Verfügung zu stellen.
6.1
Ausblick
Technisch gesehen lässt sich die Autorenumgebung in Zukunft anhand des Konzepts einer modularen Architektur an drei Stellen erweitern. Auf der Seite der zu verwendenden
Wikis sind das die Wrapper (4.2.2), deren Entwicklung eventuell durch eine steigende Popularität und Akzeptanz des WikiCreole-Projekts begünstigt wird. Leider hörten sich die
letzten Informationen bezüglich einer Unterstützung seitens der MediaWiki nicht gerade
positiv an, als Tim Starling, einer der Hauptentwickler in dem Newsletter des WikiCreoleProjekts, folgende Aussage tätigte:
I am personally not intending to implement any kind of WikiCreole sup”
port in MediaWiki, but I would welcome such support if someone implemented
it and submitted it. I support the model of having an alternative parser as an
installation option, not the ’easy edit’ model.“
Allerdings kann man es ja auch so sehen, dass die in dieser Arbeit entwickelte API (im
Speziellen die Wrapper) gerade eben dieser erwähnten Implementierung zur Unterstützung
entspricht, die er ja prinzipiell befürwortet. Somit bleibt zu hoffen, dass in absehbarer
Zukunft nach und nach immer mehr Wikis die standardisierte Syntax des WikiCreoleProjekts zumindest optional anbieten bzw. in irgendeiner Form unterstützen.
6 Zusammenfassung
115
Seitens der Exportmodule (4.4.4) und dem ständig wachsenden Markt bezüglich
eLearning-Anwendungen, die auf Internettechnoligien basieren, sollte die Wahl eines von
mir gewähltem und weit verbreiteten Standards beim Zwischenformat (XHTML) ebenfalls unterstützend wirken im Bezug auf die Entwicklung zukünftiger Module. Erweiterungen bezüglich des Autorenprozesses, welche bereits im Abschnitt 4.4.5 erwähnt wurden,
könnten zusätzlich ergänzt werden hinsichtlich einer effizienten Visualisierung von Ergebnissen und Inhalten. Insbesondere bezogen auf die Verwendung größerer Wikis und dem
entsprechend unübersichtlichen Umfang stellt diese ein nicht zu unterschätzendes Problem
dar.
Ansonsten scheint der am Anfang dieser Arbeit erwähnte Hype kurz nach der Jahrtausendwende so langsam abzuebben und sich zu beruhigen. D.h. nach der anfänglichen
Euphorie und den etlichen hinterbliebenen Sandboxes“ kehrt Ernüchterung ein und es
”
deutet sich eine Trendwende an wie z.B. auf Veranstaltungen wie dem WikiSym [RB08]
oder der Wikimania [Fou08a] zu erkennen ist, hin zur gemeinsamen Repräsentation und
Nutzung von Inhalten, was generell zu begrüßen und insbesondere im Bezug auf die in
dieser Diplomarbeit entwickelte Autorenumgebung nur zu befürworten wäre.
Literaturverzeichnis
[AH05] Hannes Gassert Andreas Harth, editor. WikiOnt: An Ontology for Describing
and Exchanging Wikipedia Articles. Wikimania Conference, 2005.
[Ala05] Alain Desilets, Sebastien Paquet, Norman G. Vinson, editor. Are Wikis Usable?
Institute for Information Technology, National Research Council of Canada,
2005.
[And06] Andreas Lund, Ole Smørdal, editor. Is There a Space for the Teacher in a WIKI?, P.O.Box 1161 Blindern, N-0318 Oslo, Norway, 2006. InterMedia, University
of Oslo.
[Bra06] Maik Braun. Ermittlung nutzergruppenspezifischer Navigationspfade in WikiSystemen. Diplomarbeit, Universität Frankfurt, 2006.
[Bre06a] Claudia Bremer. Qualitätssicherung und eLearning: Implementierungsansätze
für die Hochschule. Alexandra Sindler et al. (Hrsg.): Qualitätssicherung im
eLearning, pages S. 185–202, 2006.
[Bre06b] Claudia Bremer. Wikis im eLearning. In Proceedings der Pre-Conference, Workshops der 4. e-Learning Fachtagung Informatik DeLFI, pages S. 101 – 106. Rensing, C. (Hrsg.):, 2006.
[Chr07a] Christoph Koenig, Antje Müller, Julia Neumann. Wie können Wikis im ELearning ihr Potential entfalten? Ein Feldversuch, Eigenschaften aus der ‘freien
Wildbahn’ auf die Universität zu übertragen. Wikis: Diskurse, Theorien und
Anwendungen. Sonderausgabe von [email protected], Jg. 8, 2007.
[Chr07b] Christoph Sauer, Chuck Smith, Dr. Tomas Benz, editor. WikiCreole: A Common
Wiki Markup, Max-Planck-Str. 39, 74081 Heilbronn, Germany, 2007. Heilbronn
University.
[Con08] World Wide Web Consortium. Leading the web to its full potential... Webpage:
http://www.w3.org/, Stand08.
118
LITERATURVERZEICHNIS
[Cub07] Marija Cubric, editor. Wiki-based Process Framework for Blended Learning.
Senior Lecturer, Business School, University of Hertfordshire, UK, 2007.
[Cun05] Ward Cunningham. WikiWikiWeb. Webpage: http://c2.com/cgi/wiki, Stand:
2005.
[Det08] Detlef Hüttemann, Jörg Riebesell, CosmoCode Team. WikiMatrix. Webpage:
http://www.wikimatrix.org/, Stand: 2008.
[Die98] Dietrich Boles, Marco Schlattmann. Multimedia Autorensysteme - Graphischinteraktive Werkzeuge zur Erstellung multimedialer Anwendungen. Informatische Bildung und Computer in der Schule, 18(Heft 1):S.10–18, 1998.
[Fou08a] Wikimedia Foundation. Wikimania. Webpage: http://www.wikimania.org/,
Stand: 2008.
[Fou08b] Wikimedia Foundation.
Wikipedia - The Free Encyclopedia.
Webpage:
http://en.wikipedia.org/, Stand: 2008.
[Gmb08] DATACOM
Buchverlag
GmbH.
ITWissen.
Webpage:
http://www.itwissen.info/, Stand: 2008.
[Hin04] Dr. Udo Hinze, editor. Kooperatives E-Learning, 2004.
[Hon05] Beat Doebeli Honegger, editor. Wikis - a Rapidly Growing Phenomenon in
the German-Speaking School Community, 4502 Solothurn, Switzerland, 2005.
ICT-Kompetenzzentrum TOP, Pädagogische Hochschule Solothurn.
[Jal05] Janne Jalkanen, editor. DavWiki - the next step of WikiRPCInterfaces? Wikimania Conference, 2005.
[Jea07] Jean-Pol Martin, Guido Oebel. Lernen durch Lehren: Paradigmenwechsel in der
Didaktik? Deutschunterricht in Japan, Zeitschrift des Japanischen Lehrerverbandes, Heft 12, 2007.
[JMC02] Ph.D. Jesus M. Castagnetto. Creating Web Services for a Web Application with
XML and PHP. OSCON, [email protected], 2002.
[Ker01] Michael Kerres. Multimediale und telemediale Lernumgebungen : Konzeption
und Entwicklung, volume 2., vollst. überarb. Aufl. Oldenbourg, 2001.
[Kla06] G. Klauer. MediaWiki“ als Werkzeug zur kooperativen Erstellung einer Vor”
lesungsmitschrift in der Humananatomie. In Proceedings der Pre-Conference,
Workshops der 4. e-Learning Fachtagung Informatik DeLFI, pages S. 107 —
114. Rensing, C. (Hrsg.):, 2006.
LITERATURVERZEICHNIS
119
[Kur06] Andreas Kurz. Integration von Wiki-Inhalten - Entwurf und Implementierung
einer Schnittstelle zur Verarbeitung der Inhalte von Wiki-Seiten. Studienarbeit,
Institut AIFB Universität Karlsruhe (TH), 2006.
[Max06] Max Völkel, Eyal Oren, editor. Towards a Wiki Interchange Format (WIF)
- Opening Semantic Wiki Content and Metadata. Institute AIFB, Universität
Karlsruhe, Germany; DERI Galway, Ireland, 2006.
[meg07] megadigitale. LernBar Release 2d - Handbuch für Trainees. Universität Frankfurt, 2007.
[meg08] megadigitale.
Mediengestütztes Arbeiten zum Lernen und Lehren an
der Goethe-Universität. Projekt: http://www.megadigitale.uni-frankfurt.de/,
Stand: 2008.
[Mey08] Meyer. Meyers Lexikon. Webpage: http://lexikon.meyers.de/, Stand: 2008.
[Paa04] Sebastian Paar, editor. Standardisierungsbemühungen im Bereich E-Learning
am Beispiel von IMS LD und IEEE LOM. Technischen Universität München,
2004.
[Paa05] Sebastian Paar, editor. Der Einsatz von XSLT im Bereich E-Learning am Beispiel von IMS LD und LMML. Technischen Universität München, 2005.
[PHP08] PHP
Documentation
Group.
Php
handbuch.
http://de2.php.net/manual/en/index.php, Stand: 2008.
[RB08] James Noble Dirk Riehle Robert Biddle, Ward Cunningham. The International
Symposium on Wikis. Webpage: http://www.wikisym.org/, Stand: 2008.
[Sau06] Christoph Sauer, editor. What you see is Wiki - Questioning WYSIWYG in the
Internet Age. Wikimania Conference, 2006.
[Say06] Rihab Osman-El Sayed. Wiki-Systeme im eLearning. Diplomarbeit, Universität
Frankfurt, 2006.
[SEL08] SELFHTML e. V. SELFHTML. Webpage: http://de.selfhtml.org/, Stand: 2008.
[Sha05] Bayle Shanks, editor. WikiGateway: a library for interoperability and accelerated wiki development, San Diego, La Jolla, CA 92093, 2005. Computational
Neurobiology University of California.
120
LITERATURVERZEICHNIS
[Sil06] Silvan Reinhold.
WikiTrails: Augmenting Wiki Structure for Collaborative,
Interdisciplinary Learning, [email protected], 2006. In Proceedings of the 2006 international Symposium on Wikis (Odense, Denmark, August
21 - 23, 2006), WikiSym ’06. ACM, New York, NY, 47-58.
[Tri08] Thomas Tribelhorn. Crashkurs eLearning. Webpage: http://www.crashkurselearning.ch/, Stand: 2008.
[Vol03] Volker Claus, Andreas Schwill. Duden der Informatik, Ein Fachlexikon für Studium und Praxis, volume Auflage: 1. Bibliographisches Institut, Mannheim,
2003.
[Vos06] Sarah Voss. Extraktion semantischer Informationen aus Wiki-Systemen. Diplomarbeit, Universität Frankfurt, 2006.
[Wöh88] Dieter Wöhrle. Bertolt Brechts medienästhetische Versuche. Prometh-Verlag,
1988.
Anhang A
Glossar
A.1 Glossareinträge A-Z
A
Ajax
Asynchronous JavaScript and XML (Ajax) bezeichnet ein Konzept der asynchronen
Datenübertragung zwischen einem Server und dem Browser, welches es ermöglicht,
innerhalb einer HTML-Seite eine HTTP-Anfrage durchzuführen, ohne die Seite komplett neu laden zu müssen. Somit besteht die Möglichkeit, lediglich gewisse Teile
einer HTML-Seite oder reine Nutzdaten sukzessiv bei Bedarf nachladen zu können,
womit sich Web-Anwendungen benutzerfreundlicher gestalten lassen und mehr einer
nativen Desktop-Anwendung gleichen.
B
BibTEX
BibTEX ist ein (von Oren Patashnik entwickeltes) Programm zur Erstellung von
Literaturangaben und -verzeichnissen in TEX- oder LATEX-Dokumenten. Um ein Literaturverzeichnis zu erstellen, werden aus einem LATEX-Dokument alle Zitatverweise
herausgesucht und über eine Literatur-Datenbank dem entsprechenden Werk zugeordnet. Bei der Literaturdatenbank handelt es sich um eine Textdatei (.bib-Datei),
in der alle bekannten Angaben über ein Werk (Buch, Wissenschaftliche Publikation,
Webseite etc.) in einer bestimmten Syntax notiert werden.
C
122
A.1 Glossareinträge A-Z
CMS/LCMS
Ein Content Management System (CMS) ist eine Anwendung zur zentralen Verwaltung und Organisation von digitalen Daten, auf die mehrere Teilnehmer z.B. über ein
Intranet oder über das Internet gemeinsam zugreifen und diese bearbeiten können.
Content Management Systeme können neben der Verwaltung auch Funktionen zur
Erstellung, Präsentation und Kontrolle der Daten beinhalten.
CSS
Die Cascading Style Sheets (CSS) ist eine deklarative Stylesheet-Sprache für strukturierte Dokumente wie HTML oder XML. CSS legt dabei fest, wie ein besonders
ausgezeichneter Inhalt oder Bereich dargestellt werden soll. Diese strikte Trennung
von Inhalt und Layout wirkt sich direkt positiv auf die Maschinenlesbarkeit solch
strukturierter Dokumente aus und vereinfacht es, Änderungen im Nachhinein durchzuführen.
D
DTD
Eine Document Type Definition (DTD) ist ein Satz an Regeln, der benutzt wird, um
Dokumente eines bestimmten Typs zu repräsentieren. Ein Dokumenttyp ist dabei
eine Klasse ähnlicher Dokumente, wie beispielsweise Telefonbücher oder Inventurdatensätze. Die Dokumenttypdefinition besteht dabei aus Elementtypen, Attributen
von Elementen, Entitäten und Notationen. Konkret heißt das, dass in einer DTD
die Reihenfolge, die Verschachtelung der Elemente und die Art des Inhalts von Attributen festgelegt wird – kurz gesagt: die Struktur des Dokuments.
Dublin Core
Dublin Core ist ein simples und standardisiertes Set von Konventionen zur Beschreibung von Dokumenten und anderen Objekten im Internet, um diese mit Hilfe von
Metadaten einfacher auffindbar zu machen. Urheber dieses Schemas ist die Dublin
”
Core Metadata Initiative“ (DCMI).
H
HTML
Die Hypertext Markup Language (HTML) ist eine textbasierte Auszeichnungssprache zur Strukturierung von Inhalten wie Texten, Bildern und Hyperlinks in Dokumenten und ist somit eine Umsetzung des Konzepts Hypertext“ [G]. HTML”
Dokumente sind die Grundlage des World Wide Web und werden von einem Webbrowser dargestellt. Neben den vom Browser angezeigten Inhalten einer Webseite
A.1 Glossareinträge A-Z
123
enthält HTML zusätzliche Angaben in Form von Metainformationen, die z. B. über
die im Text verwendete Sprache oder den Autor Auskunft geben oder den Inhalt
des Textes zusammenfassen.
HTTP
Das Hypertext Transport Protocol (HTTP) ist das Standard-Protokoll zur
Übertragung von Dateien (meist HTML-Dokumente) im Internet. Es legt fest, auf
welche Art und Weise Anforderungen zum Senden von Informationen an Webserver
gesendet werden müssen und in welchem Format Header und Inhalt von Text- und
anderen Dateien zurück an das anfordernde Programm (meistens einem Webbrowser) übertragen werden müssen.
HTTPS
Bei dem Übertragungsprotokoll HTTPS (HTTP Secure) handelt es sich um eine
(mit Hilfe des SSL-Protokolls) verschlüsselte Variante des HTTP-Protokolls zur gesicherten Transaktionen durch Authentifizierung über das Internet.
Hypertext
Hypertext ist eine multi-lineare Organisation von Objekten, deren netzartige Struktur durch logische Verbindungen (so genannte Hyperlinks) zwischen Wissenseinheiten (Knoten, z. B. Texten oder Textteilen) hergestellt wird. Die Begriffe Hypertext
und Hypermedia werden meistens synonym benutzt; Hypertext betont dabei jedoch
den textuellen Anteil, Hypermedia dagegen mehr den multimedialen.
J
JavaScript
Die objektbasierte Skriptsprache JavaScript wurde mit einer an Java angelehnten
Syntax zur dynamischen Gestaltung von Webseiten entwickelt. Die Anweisungen
sind entweder direkt im HTML-Code [G] enthalten oder in einer separaten Datei
abgelegt, auf die innerhalb des HTML-Codes verwiesen wird. In der Regel wird JavaScript – im Gegensatz zu überwiegend serverseitig eingesetzten Skriptsprachen
wie z.B. PHP [G] – auf dem Client, d. h. auf dem Computer des Anwenders ausgeführt.
JSON
JavaScript Object Notation (JSON) Ist ein textbasierendes Datenaustauschformat
ähnlich XML. Daten werden in JavaScript Syntax dargestellt, die direkt ohne sonstige Verarbeitung von einem JavaScript Interpretierer ausgewertet werden kann.
Ein weiterer Vorteil im Vergleich zu XML ist die etwas kompaktere Kodierung von
124
A.1 Glossareinträge A-Z
Datenstrukturen, wodurch weniger Overhead produziert wird. XML hingegen ist
eine Auszeichnungssprache und somit vielseitiger einsetzbar, da JSON ein reines
Datenaustauschformat ist. XML genießt außerdem eine weitere Verbreitung. Beide
Formate sind nicht unbedingt zur Repräsentation von großen Binärdaten geeignet.
L
LATEX
LATEX ist ein Softwarepaket, das die Benutzung des Textsatzprogramms TEX mit
Hilfe von Makros vereinfacht. Siehe TEX [G].
LMS
Als Learning Management System (LMS) oder Lernplattform bezeichnet man – im
Kontext von eLearning – ein komplexes Softwaresystem, das zur Bereitstellung und
Organisation von Lernvorgängen dient und somit die Schnittstelle zwischen Lehrenden und Lernenden darstellt. Sie enthalten sowohl Elemente zur Erstellung und
Verwaltung von Lerninhalten, deren Koordination, als auch Elemente zur Kommunikation und Interaktion zwischen den Lernenden und dem Bildungsanbieter für
z.B. Self-Assessments.
O
OSI-Modell
Das Open Systems Interconnection Model (OSI-Model) oder auch 7-SchichtenModell ist ein Referenzmodell der International Organization for Standardization
(ISO), welches als Grundlage zur Bildung von Kommunikationsstandards dient, um
eine offene Kommunikation zwischen verschiedenen Netzwerkgeräten unterschiedlichster Hersteller überhaupt erst möglich werden zu lassen. Dies ist lediglich modellartig in sieben Schichten mit einem steigenden Grad an Abstraktion beschrieben, da
es bei dem Standard nicht um konkrete Implementationen sondern um deren Richtlinien geht. Grob unterteilt sind das die transportorientierten Schichten 1-4, welche
als Grundlage für z.B. folgende Protokolle dienten: Ethernet, IP, TCP oder UDP
und die anwendungsorientierten Schichten 5-7, welche sich z.B. in den Protokollen
HTTP oder FTP manifestierten.
P
Parser
Ein Parser ist ein Programm, welches für die Zerlegung und Umwandlung einer
A.1 Glossareinträge A-Z
125
beliebigen Eingabe in ein für die Weiterverarbeitung brauchbares Format zuständig
ist. Häufig werden Parser eingesetzt, um im Anschluss an den Analysevorgang die
Semantik der Eingabe zu erschließen und daraufhin Aktionen durchzuführen.
PHP
PHP: Hypertext Preprocessor (PHP) ist eine Skriptsprache mit einer an C bzw. C++
angelehnten Syntax, die hauptsächlich zur Erstellung von dynamischen Webseiten
oder Webanwendungen verwendet wird. PHP wird im Gegensatz zu z.B. JavaScript
[G] serverseitig ausgeführt und liefert eine dynamisch generierte Webseite dem Client
lediglich als Ergebnis. PHP zeichnet sich insbesondere durch die leichte Erlernbarkeit, die breite Datenbankunterstützung und Internet-Protokolleinbindung sowie die
Verfügbarkeit zahlreicher, zusätzlicher Funktionsbibliotheken aus.
R
RDF
Das Resource Description Framework (RDF) ist eine formale Sprache zur Bereitstellung von Metadaten im World Wide Web. RDF wurde vom W3C zusammen mit der
Web Ontology Language als Grundstein für das Semantische Web entwickelt und ist
frei verfügbar. Die Idee ist, Eigenschaften von Ressourcen im World Wide Web in einer maschinell verarbeitbaren Form zu beschreiben. Solche Beschreibungen können
nach dem RDF-Modell als Graph oder nach der RDF-Syntax als XML-Hypertext
vorliegen. Erweitert wird RDF durch das RDF-Schema, mit der komplexere Beziehungen zwischen Ressourcen beschrieben werden können.
RPC
Unter einem Remote Procedure Call (RPC) versteht man die Technik, über ein
Netzwerk auf einem entfernten Rechner einen Funktionsaufruf durchzuführen und
gegebenenfalls die Antwort entgegenzunehmen. Man unterscheidet dabei zwischen
synchronen und asynchronen RPCs, wobei der Client entweder zunächst auf eine
Antwort wartet oder ohne jegliches Feedback direkt mit seinem Programmablauf
fortfährt.
S
SOAP
Das Simple Object Access Protocol (SOAP) ist ein Netzwerkprotokoll, mit dessen
Hilfe Daten zwischen Systemen ausgetauscht und Remote Procedure Calls (RPCs)
durchgeführt werden können. SOAP hat offiziell den Status einer W3C-Empfehlung
126
A.1 Glossareinträge A-Z
und kann als Vollendung der Zwischenstation“ XML-RPC angesehen werden. Siehe
”
XML-RPC [G].
SQL
Die Structured Query Language (SQL) ist eine Datenbanksprache zur Definition, Abfrage und Manipulation von Daten in relationalen Datenbanken. SQL ist von American National Standards Institute (ANSI) und ISO standardisiert und wird von
fast allen gängigen Datenbanksystemen unterstützt, was es möglich macht, Anwendungsprogramme zu entwicklen, die vom verwendeten Datenbanksystem unabhängig
sind. Die Syntax von SQL ist relativ einfach aufgebaut, semantisch an die englische
Umgangssprache angelehnt und umfasst die folgenden Datenbanksprachen: Data
Manipulation Language, Data Definition Language, Data Control Language.
SSL
Das Secure Socket Layer (SSL) oder die standardisierte Weiterentwicklung Transport Layer Security (TLS) sind Protokolle zur Verschlüsselung von Nachrichten im
Internet. Der Datenaustausch setzt direkt auf TCP/IP auf und findet somit in der
Transportschicht des OSI-Modells statt. SSL kann in Verbindung mit SMTP, Telnet,
dem FTP-Protokoll oder HTTP bzw. HTTPS eingesetzt werden.
T
TEX
Bei TEX handelt es sich um ein von Donald E. Knuth entwickeltes Textsatzsystem
mit eingebauter Makrosprache, welche ebenfalls als TEX bezeichnet wird. Die bekannteste Makrosammlung ist LATEX und wird in der Kombination für alle Arten
von Texten verwendet, vom kurzen Brief bis zu mehrbändigen Büchern. Viele große
wissenschaftliche Verlage nutzen es für den Buchdruck bzw. Werksatz. Eine besondere Stärke ist der mathematische Formelsatz.
U
UML
Die Unified Modeling Language (UML) ist eine standardisierte, universelle grafische Sprache zur Beschreibung aller Arten objektorientierter Softwaresysteme. Sie
zielt auf eine Vereinigung der bekanntesten Beschreibungsnotationen und ist schwerpunktmäßig auf die Produkte der Softwaretechnik gerichtet.
UTF-8
Das Unicode Transformation Format auf der Basis von 8 Bits (UTF-8) ist die am
A.1 Glossareinträge A-Z
127
weitesten verbreitete Kodierung für Unicode-Zeichen. Dabei wird jedem UnicodeZeichen eine speziell kodierte Bytekette von variabler Länge zugeordnet. UTF-8
unterstützt bis zu vier Byte, auf die sich wie bei allen UTF-Formaten alle 1.114.112
Unicode-Zeichen abbilden lassen. Somit nimmt UTF-8 eine zentrale Rolle als globale
Zeichenkodierung im Internet ein und sollte stets den sprachabhängigen Kodierungen vorgezogen werden.
W
WebDAV
Web-based Distributed Authoring and Versioning (WebDAV) ist ein offener Standard zur Bereitstellung und Verwaltung von Dateien in einem Netzwerk. Technisch
gesehen ist WebDAV eine Erweiterung des HTTP-Protokolls, welche es ermöglicht,
ähnlich wie über HTTP-POST eine Datei hochgeladen werden kann, komplette Verzeichnisse zu bewegen unter der Berücksichtigung einer Versionskontrolle.
Wissensmanagement
Unter Wissensmanagement versteht man die Aufgabe, Informationsquellen innerhalb und außerhalb eines Betriebes oder Projekts zu erschließen und zu pflegen
sowie dafür zu sorgen, dass die Informationsversorgung der Führungs- und Fachkräfte oder sonstiger Mitglieder auf optimale Weise erfolgt. Zu diesem Zweck sind
organisatorische Maßnahmen ebenso notwendig wie der zweckmäßige Einsatz von
Informations- und Kommunikationssystemen. Gestaltet werden müssen der Informationsfluss und die Regelungsmechanismen für Zugang und Lieferung, Suche und
Bereitstellung, Nachfrage und Angebot von Informationen.
X
XHTML
Der W3C-Standard Extensible HyperText Markup Language (XHTML) ist eine textbasierte Auszeichnungssprache zur Darstellung von Inhalten wie Texten, Bildern
und Hyperlinks in Dokumenten. Es ist eine Neuformulierung von HTML [G] in
XML [G] und nicht wie zuvor in SGML. XHTML-Dokumente sind somit strenger in
ihrer Beschreibung, einfacher zu parsen und sind durch eine strikte Modularisierung
sehr leicht zu erweitern bzw. einzuschränken.
XML
Die Extensible Markup Language (XML) ist eine Auszeichnungssprache zur Darstellung hierarchisch strukturierter Daten in Form von einfachen Textdateien. XML
wird u. a. für den einheitlichen Austausch von Daten zwischen unterschiedlichen
128
A.1 Glossareinträge A-Z
IT-Systemen eingesetzt und kommt speziell im Bezug auf Internet zum Tragen. Des
Weiteren ist XML auch als Metasprache zu verstehen, auf deren Basis (durch strukturelle und inhaltliche Einschränkungen) anwendungsspezifische Sprachen definiert
werden. Diese Einschränkungen werden durch Schemasprachen wie DTD [G] oder
XML-Schema [G] ausgedrückt.
XML Schema
XML Schema ist eine Empfehlung des W3C zum Definieren von Strukturen für
XML-Dokumente. Anders als bei den klassischen XML-DTDs [G] wird die Struktur in Form eines XML-Dokuments [G] beschrieben. Darüber hinaus wird eine
große Anzahl von Datentypen unterstützt. XML-Schema beschreibt in einer komplexen Schemasprache Datentypen, einzelne XML-Schema-Instanzen (Dokumente)
und Gruppen solcher Instanzen. Ein konkretes XML-Schema wird auch als eine
XSD (XML-Schema-Definition) bezeichnet und hat als File üblicherweise die Dateiendung .xsd“. Im Gegensatz zu DTDs [G] kann bei Verwendung von XML-Schema
”
zwischen dem Namen des XML-Typs und dem in der Instanz verwendeten Namen
des XML-Tags unterschieden werden.
XML-RPC
Extensible Markup Language Remote Procedure Call (XML-RPC) ist eine Spezifikation, Methoden bzw. Funktionen über das Internet aufrufen zu könnnen. Die
Aufrufe nutzen das HTTP-Protokoll als Transport Layer und XML zur Kodierung.
XML-RPC wurde entwickelt, um möglichst einfach komplexe Datenstrukturen zu
übermitteln, zu bearbeiten und zurückzusenden.
XPath
Die XML Path Language (XPath) ist eine vom W3-Konsortium entwickelte Anfragesprache, um Teile eines XML-Dokumentes zu adressieren. XPath ist neben XSL-FO
[G], XSLT [G] einer der drei Grundpfeiler von XSL [G] und dient als Grundlage
einer Reihe weiterer Standards wie XPointer oder XQuery [G].
XQuery
XQuery steht für XML Query Language und bezeichnet eine vom W3C spezifizierte
Abfragesprache für XML-Datenbanken. XQuery benutzt eine an XSLT [G], SQL [G]
und C angelehnte Syntax und verwendet XPath [G] sowie XML Schema [G] für sein
Datenmodell und seine Funktionsbibliothek.
XSL
Die Extensible Stylesheet Language (XSL) ist eine Familie von Sprachen zur Erzeugung von Layouts für XML-Dokumente. Diese Sprachen sind XSLT [G], XPath
A.1 Glossareinträge A-Z
129
[G] und die zur eigentlichen Definition von Layouts XSL-FO. Diese Layouts (auch
Stylesheets genannt) können in die zu formatierenden XML-Dokumente eingebunden werden, wobei sich die Layouts speziellen Medien zuordnen lassen. So ist es
möglich, ein Layout zum Drucken und ein Layout für die Darstellung am Computer
zu verwenden.
XSLT
XSL Transformations (XSLT) als eine der drei Grundpfeiler von XSL [G] und ist
eine sehr mächtige Programmiersprache zur Transformation von XML-Dokumenten
[G]. XSLT baut auf der logischen Baumstruktur eines XML-Dokumentes auf und
dient zur Definition von Umwandlungsregeln. XSLT-Programme, sogenannte XSLTStylesheets, sind dabei selbst nach den Regeln des XML-Standards aufgebaut. Die
Stylesheets werden von spezieller Software, den XSLT-Prozessoren, eingelesen, die
mit diesen Anweisungen ein oder mehrere XML-Dokumente in das gewünschte Ausgabeformat umwandeln.
Anhang B
wikiPAGEs
B.1
1
Struktur und Inhalt einer Seite (XHTML)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
10
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<!-- meta data of the original wiki -->
<meta name="wiki.sourcewiki" content="http://en.wikipedia.org" />
<meta name="wiki.sourcewiki.pagequery" content="index.php?page=&rev=" />
<meta name="wiki.sourcewiki.engine" content="mediawiki" />
<meta name="wiki.sourcewiki.version" content="1.8" />
<meta name="wiki.sourcewiki.language" content="en" />
<!-- meta data of the original page -->
<meta name="wiki.soursepage.revisioncount" content="4" />
<meta name="wiki.soursepage.authorcount" content="7" />
<meta name="wiki.soursepage.creationdate" content="2003-10-12 14:12" />
<meta name="wiki.soursepage.lastupdate" content="2007-10-02 12:30" />
20
<!-- meta data of this page -->
<meta name="wiki.page.status" content="individual/mixed/valide" />
<link rel="stylesheet" type="text/css" href="wi-styles.css" />
<title id="revisionsnr">Wiki-Artikeltitel</title>
</head>
30
<body>
<h1 class="wi-heading-1">Wiki-Artikeltitel</h1>
<!-- abstract -->
<div class="wi-abstract wi-derived" id="0">
<p class="wi-paragraph" id="p1">Das hier ist eine Zusammenfassung
132
B.1 Struktur und Inhalt einer Seite (XHTML)
dieses Artikels.</p>
</div>
40
<!-- sections -->
<div class="wi-section" id="1">
<h2 class="wi-section-heading-1">Abschnitt 1</h2>
<!-- paragraphs -->
<p class="wi-paragraph" id="p1" >Das hier ist ein ganz normaler Absatz im Text.</p>
50
60
<p class="wi-paragraph" id="p2" >Hier einer mit
<!-- styles -->
<span class="wi-keywords wi-bold wi-derived">fetten Text</span>.
<span class="wi-keywords wi-italic wi-confirmed">kursiven Text</span>.
<span class="wi-keywords wi-emphasized wi-derived">hervorgehobenen Text</span>.
<span class="wi-keywords wi-underline wi-derived">unterstrichenen Text</span>.
</p>
<p class="wi-paragraph" id="p3" >Hier einer mit
<!-- links -->
<a href="URI der Zielseite" class="wi-link-external">einem externen Link</a>.
<a href="URI der Zielseite" class="wi-link-internal">einem internen Link</a>.
</p>
<p class="wi-paragraph" id="p4" >Hier einer mit
<!-- media -->
<object class="wi-media wi-image wi-confirmed" name="Bild"
data="http://wiki/bild.jpg" type="image/jpeg">
einem Bild, aber es kann nicht angezeigt werden
</object>.
70
<object class="wi-media wi-svg wi-confirmed" name="Verweis-sensitives_Bild"
data="http://wiki/uhr.svg" type="image/svg+xml">
einem SVG, aber es kann nicht angezeigt werden
</object>.
<object class="wi-media wi-java wi-confirmed" name="Java_Anwendung"
classid="java:zmaze3d.class"
codetype="application/java-vm">
Bitte installieren sie Java_Anwendung
</object>.
80
90
<object class="wi-media wi-avtivx wi-confirmed" name="ActivX_Controls"
classid="CLSID:05589FA1-C356-11CE-BF01-00AA0055595A">
<param name="filename" value="ritmo.mid">
</object>
<object class="wi-media wi-flash wi-confirmed" name="Flash_Anwendung"
classid="CLSID:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://active.macromedia.com/flash2/cabs/
swflash.cab#version=4,0,0,0">
<param name="movie" value="nibbles.swf">
<param name="quality" value="high">
<param name="scale" value="exactfit">
<param name="menu" value="true">
B wikiPAGEs
133
<param name="bgcolor" value="#000040">
<embed src="nibbles.swf" quality="high" scale="exactfit" menu="false"
bgcolor="#000000" width="600" height="400" swLiveConnect="false"
type="application/x-shockwave-flash"
pluginspage="http://www.macromedia.com/shockwave/download/
download.cgi?P1_Prod_Version=ShockwaveFlash">
</embed>
</object>
100
</p>
<!-- types of paragraphs -->
<p class="wi-paragraph wi-type-code" id="p5" >Hier ein Code-formatierter Absatz</p>
<p class="wi-paragraph wi-type-list" id="p6" >
<ul class="wi-list-unordered">
<li>Listenpunkt
<li>Listenpunkt
</ul>
</p>
110
<p class="wi-paragraph wi-type-table" id="p7" >
<table>
...
</table>
</p>
<!-- subsections -->
<div class="wi-section" id="1">
<h3 class="wi-section_heading-2">Abschnitt 1.1</h3>
120
<p class="wi-paragraph" id="p1" >
Das hier ist ein ganz
normaler Absatz im Text.
</p>
</div>
130
</div>
<div class="section-see-also" id="2">
<h2 class="wi-section-heading-1">Abschnitt 2</h2>
<p class="wi-paragraph" id="p1" >
Das hier ist ein ganz
normaler Absatz im Text.
</p>
140
</div>
</body>
</html>
B.2
1
Layout und Kontext einer Seite (CSS/XML)
<!-- standard structure
-->
<!-- headings: h1, h2, h3, h4, h5, h6 -->
134
B.2 Layout und Kontext einer Seite (CSS/XML)
h1 { font-family: Arial; font-size: 16px; color:black; }
<!-- blocks: p, pre, hr
-->
p { font-family: Verdana; font-size: 11px; }
10
<!-- lists: dl, dd, dt, ol, ul, li
-->
li { font-family: Verdana; font-size: 11px; }
<!-- tables: table, tr, th, td
-->
th { font-family: Verdana; font-size: 11px; }
<!-- links: a
-->
a { font-family: Verdana; font-size: 11px; text-decoration: none; }
20
<!-- wikipage-specific structure
-->
.wi-abstract { font-family: Verdana; font-size: 10px; }
.wi-section { font-family: Verdana; }
.wi-paragraph { font-family: Verdana; }
.wi-type-code { font-family: Courier; }
.wi-type-list { font-family: Verdana; }
.wi-type-table { font-family: Verdana; }
.wi-media { font-family: Verdana; }
.wi-image { width: 200px; height: 200px; }
.wi-java { width: 200px; height: 200px; }
.wi-flash { width: 200px; height: 200px; }
.keywords { font-family: Verdana; }
30
<!-- wikipage-specific context
.wi-link-external { color: blue; }
.wi-link-internal { color: red; }
.wi-link-interwiki { color: green; }
40
<!-- wikipage-specific styles
-->
.wi-bold { font-weight: bold; }
.wi-italic { font-style: italic; }
.wi-emphasized { font-style: emphasized; }
.wi-underline { text-decoration: underline; }
<!-- wikipage-specific grading
.wi-derived { style: value; }
.wi-confirmed { style: value; }
.wi-critical { style: value; }
1
10
-->
-->
<?xml version="1.0" encoding="utf-8" standalone="no" ?>
<!-- pagecontext
-->
<!-- types: wi-link-internal, wi-link-backlinks -->
<wikipages type="wi-link-backlinks">
<wikipage>
<metadata>
<title>
PAGETITLE 1
</title>
<author>
AUTHOR 1
</author>
B wikiPAGEs
20
30
40
50
<wiki name="Wikipedia" uri="http://www.wikipedia.de" />
</metadata>
<content>
<abstract>
ABSTRACT 1
</abstract>
PAGECONTENT 1
</content>
</wikipage>
<wikipage>
<metadata>
<title>
PAGETITLE 2
</title>
<author>
AUTHOR 2
</author>
<wiki name="Wiktionary" uri="http://www.wikitionary.de" />
</metadata>
<content>
<abstract>
ABSTRACT 2
</abstract>
PAGECONTENT 2
</content>
</wikipage>
</wikipages>
<!-- categories -->
<categories>
<category>
<title>
CATEGORYTITLE 1
</title>
<!-- optional additional informations -->
<!-- pages, subcategories
-->
<category>
</categories>
135

Documentos relacionados