In meiner Abschlussarbeit beschäftige ich mich mit der Generierung von Vorschlägen für wissenschaftliche Publikationen. Diese Vorschläge werden automatisch berechnet. Daher ist es nötig zu prüfen, ob diese Vorschläge Sinn ergeben.

Eine Möglichkeit der Prüfung ist der Vergleich mit Datensammlungen, die von Menschen klassifiziert wurden. Ein Beispiel ist der Cora Datensatz. Eine andere Variante ist eine stichprobenartige Prüfung. Um einen Zusammenhang zwischen Publikationen bewerten zu können, ist allerdings eine gewisse Expertise erforderlich. Und diese ist bei Forschern, Lehrenden und Studierenden zu finden.

Einen Überblick über Informatik-Themen, die an der Uni Paderborn behandelt werden, erhält man durch einen Blick in die Publikationslisten. Diese sind auf den Webseiten der einzelnen Fachgebiete zu finden. Die Veröffentlichung der Dateien im Web bringt den Autoren potenzielle Leser und dadurch vielleicht auch die ein oder andere Zitierung. Für diejenigen, die an einer Sammlung der frei zugänglichen PDFs interessiert sind, sollte diese Tabelle mit Listen von PDF-Dateien nützlich sein:

Insgesamt 1317 Dateien und 1,3 Gigabyte (ermittelt mit du -sch).

Dieses Werk bzw. Inhalt steht unter einer Creative Commons Namensnennung 3.0 Deutschland Lizenz.
Wenn möglich, verwenden Sie doch einen Link zum Originalartikel:
Adrian Wilke: Informatik Publikationen der Universität Paderborn.

Um Ungleichheiten in Zeichenketten großzügig zu behandeln, kann man die Levenshtein-Distanz nutzen. Diese vergleicht zwei Zeichenketten und gibt die minimale Anzahl von Operationen (Einfügen, Löschen und Ersetzen) an, die benötigt werden, um die erste Zeichenkette die zweite umzuwandeln. Anstatt Titel auf vollkommene Gleichheit zu überprüfen, ist es hiermit also z.B. möglich, kleinere Ungleichheiten zu tolerieren.

Es gibt eine ganze Reihe von Implementierungen in verschiedenen Sprachen, z.B. in PostgreSQL. Zurzeit arbeite ich allerdings mit MySQL. Hier ist die Funktion nicht von Haus aus installiert, es gibt aber zumindest eine UDF (User Defined Function), die auf der GitHub Seite von Juan Miguel Cejuela zu finden ist. Und da die Einbindung doch ein paar Minuten in Anspruch genommen hat, folgt hier ein kleines HowTo.

Installation

Zunächst lädt man die Datei levenshtein.c runter und folgt den Installationsanweisungen im Kommentar. Bei mir fehlten zusätzliche Codedateien:

$ gcc -o levenshtein.so -shared levenshtein.c
levenshtein.c:33:23: fatal error: my_global.h: No such file or directory
compilation terminated.


Den Sourcecode kann man in Mint/Ubuntu/Debian so beziehen:

$ sudo aptitude install mysql-source-5.5


Als Nächstes wird die benötigte Datei ausfindig gemacht:

$ dpkg -L mysql-source-5.5
/.
/usr
/usr/src
/usr/src/mysql
/usr/src/mysql/mysql-source-5.5.tar.gz
/usr/share
/usr/share/doc
/usr/share/doc/mysql-source-5.5
/usr/share/doc/mysql-source-5.5/copyright
/usr/share/doc/mysql-source-5.5/changelog.Debian.gz


Das Archiv wird entpackt:

$ tar -xzf /usr/src/mysql/mysql-source-5.5.tar.gz


In den extrahierten Dateien wird nach der benötigten Headerdatei gesucht:

$ find ./ -iname "my_global.h"
./source/mysql-5.5/include/my_global.h


Ein erneuter Versuch, zu kompilieren. Dieses Mal mit Angabe des Verzeichnisses der Headerdatei:

$ gcc -o levenshtein.so -shared levenshtein.c -I source/mysql-5.5/include/
In file included from levenshtein.c:33:0:
source/mysql-5.5/include/my_global.h:77:23: fatal error: my_config.h: No such file or directory
compilation terminated.


Suche der zweiten fehlenden Datei:

$ find ./ -iname "my_config.h"
./source/mysql-5.5/builddir/include/my_config.h
./source/mysql-5.5/builddir/packaging/rpm-uln/my_config.h
./source/mysql-5.5/packaging/rpm-uln/my_config.h


Dieses Mal klappt das Kompilieren:

gcc -o levenshtein.so -shared levenshtein.c -I source/mysql-5.5/include/ -I source/mysql-5.5/builddir/include/


Suche nach dem MySQL Plugin Verzeichnis:

$ mysql
mysql> show variables;
+----------------+------------------------+
| Variable_name | Value | |
+----------------+------------------------+
| plugin_dir | /usr/lib/mysql/plugin/ |
+----------------+------------------------+


Kopieren der erstellten Datei ins MySQL Plugin Verzeichnis:

$ sudo cp levenshtein.so /usr/lib/mysql/plugin/


MySQL als root Starten und die Funktion erstellen:

$ mysql -uroot
mysql> CREATE FUNCTION levenshtein RETURNS INT SONAME 'levenshtein.so';
Query OK, 0 rows affected (0.07 sec)
mysql> CREATE FUNCTION levenshtein_k RETURNS INT SONAME 'levenshtein.so';
Query OK, 0 rows affected (0.01 sec)


Test:

mysql> select levenshtein('hello', 'world');
+-------------------------------+
| levenshtein('hello', 'world') |
+-------------------------------+
| 4 |
+-------------------------------+
1 row in set (0.00 sec)


Vladimir Levenshtein (Deutsche Übersetzung) hat den Algorithmus übrigens 1965 veröffentlicht.

Hier ist noch ein Backup der Datei mit dem C Code.

Dieses Werk bzw. Inhalt steht unter einer Creative Commons Namensnennung 3.0 Deutschland Lizenz. Wenn möglich, verwenden Sie doch einen Link zum Originalartikel: Adrian Wilke: Die Levenshtein-Distanz in MySQL.

Eine Möglichkeit der Unterbringung ist, die gesammelten Adressen dem Literaturverzeichnis hinzuzufügen. Dieser Ansatz ist stimmig, wenn die hinzugefügten URLs auf Texte verweisen, die wissenschaftlichen Publikationen ähneln. Dabei sollte aber nicht vergessen werden, eine Notiz mit der Information darüber hinzuzufügen, wann die entsprechende Seite eingesehen wurde.

Ein anderer Ansatz ist, URLs als Fußnote mit einem footnote an das Seitenende zu setzen. Kombiniert mit dem url Befehl, einem passenden Titel und dem Datum des Zugriffs ist dies auch eine schöne Lösung. Diese bietet sich an, wenn die verlinken Seiten vor allem Zusatzinformationen darstellen und ein Verweis als Randnotiz bereitgestellt werden soll. Bei einer längeren Arbeit könnte diese Lösung für jemanden, der gezielt nach einer Webadresse sucht, lästig sein.

Bisher war ich mit diesen Alternativen recht zufrieden. Es scheint allerdings, als würde meine aktuelle Arbeit ein längerer Text mit einigen URLs werden. Also wären einerseits die Adressen bei der Fußnoten-Lösung zu verstreut, auf der anderen Seite häufen sich bei dem langen Text auch viele klassische Literaturangaben an, was recht unübersichtlich werden könnte. Also entstand der Wunsch, URLs übersichtlich beieinander aufzulisten und auf diese verweisen zu können. Die erste Idee war, mittels label und ref alle Adressen im Anhang zu verstauen. Nach einer Recherche habe ich jetzt eine bessere Lösung: Zwei getrennte Bibliografien.

Verwendung mehrerer Literaturverzeichnisse

Auf UK List of TeX FAQ: Multiple bibliographies? gibt es mit multibbl, multibib, bibtopic und splitbib gleich vier Ansätze für die Verwendung mehrerer Bibliografien. Ich habe mich hier für multibib entschieden. Das Paket musste in meinem Fall erst installiert werden. Dazu gibt es hier eine kurze Anleitung: Adding a new package to a latex install on linux. Dabei muss multibib runtergeladen, entpackt und anschließend die Dateien auffindbar gemacht werden:

latex multibib.ins
sudo mkdir /usr/share/texmf/tex/latex/multibib
sudo cp multibib.sty /usr/share/texmf/tex/latex/multibib
sudo texhash

Nun können neue Befehle zur Referenzierung definiert und genutzt werden. Hier ein Minimalbeispiel für zwei getrennte Literaturverzeichnisse:

multibib.tex

\documentclass{scrartcl}
\usepackage{multibib}
\usepackage{hyperref}
\newcites{Refs,Urls}{Literaturverzeichnis,Verzeichnis der Webadressen}
\begin{document}
\bibliographystyleRefs{plain}
\bibliographystyleUrls{plain} % Erstes Beispiel
%\bibliographystyleUrls{urls} % Zweites Beispiel
\nociteRefs{*}
\nociteUrls{*}
\bibliographyRefs{Bibliography}
\bibliographyUrls{BibliographyUrls}
\end{document}

Bibliography.bib

@incollection{aan2012,
year={2012},
isbn={978-1-4471-4053-5},
booktitle={Computational Social Networks},
editor={Abraham, Ajith},
title={Mining and {V}isualizing {R}esearch {N}etworks {U}sing the {A}rtefact-{A}ctor-{N}etwork {A}pproach},
publisher={Springer London},
author={Reinhardt, Wolfgang and Wilke, Adrian and Moi, Matthias and Drachsler, Hendrik and Sloep, Peter},
pages={233--267},
}

BibliographyUrls.bib

@Misc{DDI,
title = {Didaktik der {I}nformatik},
note = {Eingesehen am 07.02.2013},
url = {http://ddi.uni-paderborn.de/},
howpublished = "\url{http://ddi.uni-paderborn.de/}",
key = {DDI},
}

Um die beiden BibTeX Dateien nutzen zu können, müssen sie per Konsolenbefehl vorbereitet werden:

bibtex Refs.aux; bibtex Urls.aux

Das Ergebnis sieht so aus:

In diesem Beispiel ist am Marker allein nicht sofort erkennbar, ob es sich um eine klassische Literaturangabe oder eine Webadresse handelt. Um dieses Problem zu umgehen, kann für die URL-Referenzen ein anderer Stil verwendet werden. Ich habe allerdings keine solche bst-Datei gefunden, die mir gefallen hat. Daher kommt mit diesem Artikel eine Datei urls.bst, die gern heruntergeladen und verwendet werden darf.

Zur Erstellung der Datei habe ich folgende Eingaben vorgenommen:

latex makebst

Name of the final OUTPUT .bst file? (default extension=bst)
\ofile=urls

STYLE OF CITATIONS:
(*) Numerical as in standard LaTeX
(a) Author-year with some non-standard interface
(b) Alpha style, Jon90 or JWB90 for single or multiple authors
(o) Alpha style, Jon90 even for multiple authors
(f) Alpha style, Jones90 (full name of first author)
(c) Cite key (special for listing contents of bib file)
Select:
\ans=c

ORDERING OF REFERENCES (if non-author/year and non-alph)
(*) Alphabetical by all authors
(c) Citation order (unsorted, like unsrt.bst)
(d) Year ordered and then by authors
(r) Reverse year ordered and then by authors
Select:
\ans=c

FINAL PUNCTUATION:
(*) Period at very end of the listed reference
(x) No period at end
Select:
\ans=x

URL ADDRESS: (without REVTeX fields)
(*) No URL for electronic (Internet) documents
(u) Include URL as regular item block
(n) URL as note
(l) URL on new line after rest of reference
Select:
\ans=u

Finished!!
Batch job written to file `urls.dbj’
Shall I now run this batch job? (NO)
\yn=y

Damit wurde eine fertige Datei urls.bst erstellt. Bei Einträgen mit dem Feld url wird in dieser generierten Zwischenlösung noch ein unschönes Präfix “URL” bei jeder Referenz eingefügt. Das kann mit einer Nachbearbeitung der Datei urls.bst behoben werden:

"\providecommand{\urlprefix}{URL }"
wird zu
"\providecommand{\urlprefix}{}"

Hier der im zweiten Beispiel genutze Code:

multibib.tex

\documentclaß{scrartcl}
\usepackage{multibib}
\usepackage{hyperref}
\newcites{Refs,Urls}{Literaturverzeichnis,Verzeichnis der Webadreßen}
\begin{document}
\bibliographystyleRefs{plain}
%\bibliographystyleUrls{plain} % Erstes Beispiel
\bibliographystyleUrls{urls} % Zweites Beispiel
\nociteRefs{*}
\nociteUrls{*}
\bibliographyRefs{Bibliography}
\bibliographyUrls{BibliographyUrls}
\end{document}

BibliographyUrls.bib

@Misc{DDI,
title = {Didaktik der {I}nformatik},
note = {Eingesehen am 07.02.2013},
url = {http://ddi.uni-paderborn.de/},
NICHT_BENOETIGT_howpublished = "\url{http://ddi.uni-paderborn.de/}",
NICHT_BENOETIGT_key = {DDI},
}

Und so sieht das finale Resultat aus:

Das ganze klappt übringens auch mit der Vorlage classicthesis von Andre Miede.

Hier noch die für diesen Artikel verwendeten Dateien:

• urls.bst
• latex-bibliography-urls.zip

Dieses Werk bzw. Inhalt steht unter einer Creative Commons Namensnennung 3.0 Deutschland Lizenz.
Wenn möglich, verwenden Sie doch einen Link zum Originalartikel:
Adrian Wilke: Literaturverzeichnis für URLs in LaTeX.

Um die Suche nach Tags, mit denen Personen und Gruppen getagt wurden zu ermöglichen, sollten zwei separate SearchQuerySets erstellt werden (für PeopleTagging und GroupTagging), die viele redundante Einträge hatten. Diese Redundanz entstand durch das mehrmalige Taggen einer Person bzw. Gruppe mit ein und demselben Schlagwort. Dafür wurde eine Funktion geschrieben, die diese Redundanz in eine Art Ranking umwandelt, mit dem man feststellen kann, welche Person oder Gruppe am häufigsten mit einem der gesuchten Begriffe getagt wurde.

Applikationsübergreifende Suche

Unabhängig von der Seite, an der sich ein Benutzer in der Web-Applikation befinden, besteht die Möglichkeit nach anderen Systemnutzer und Gruppen zu suchen. Um diese Suchfunktion zu verwenden, muss der gesuchte Begriff in die Suchleiste eingeben (vgl. Abbildung 1, Eingabefeld) und mit Return bestätigt werden.

Die Suche ist mit einer Auto-Vervollständigungs-Funktion ausgestaltet. Wenn der Benutzer mit der Eingabe der ersten Buchstaben beginnt, bekommt er Suchvorschläge, die diese Buchstabenfolge enthalten.

Abbildung 1: Sucheingabefeld im Hauptmenu

Bei der Auto-Vervollständigung werden auch Wörter angezeigt, die in Verbindung mit dem gesuchten Begriff stehen. Diese Verbindung entsteht, wenn eine Person bspw. mit „DDI“ und „HNI“ getagt. Die Suche nach dem Begriff „DDI“ kann somit auch Suchergebnisse und Auto-Vervollständigungs-Vorschläge rund um das Tag „HNI“ beinhalten.

Suchergebnisse

Die Ergebnisse werden schließlich im Hauptframe sortiert und kategorisiert ausgegeben. Im rechten Teil der Seite öffnet sich das interne Messenger-Formular. Dieses Formular hat an dieser Stelle eine wichtige Bedeutung, da die gefundenen Personen und/oder Gruppen sofort kontaktiert werden können.

Die Funktionsweise des internen Messengers wird an dieser Stelle nicht weiter erläutert, da ich hierüber schon im letzten Bericht geschrieben habe.

Die Suchergebnisse werden in 3 Register aufgeteilt (vgl. Abbildung 2):

1. Users
2. Groups
3. Virtual Groups

Abbildung 2: Suchergebnisse in SuTeCo: User

Im Tab „User“ werden alle Systemnutzer angezeigt, die mit dem gesuchten Begriff(-en) getagt wurden. Diejenigen, die am häufigsten mit einem Begriff getagt wurden, werden weiter ober in der Liste angezeigt und mit entsprechendem Zähler markiert: „was tagged X times with YZ“. Darüber hinaus sind alle gefundenen Personen mit den Tags versehen, mit denen sie am meisten in Verbindung gebracht wurden. Diese „popular Tags“ lassen grob einschätzen, in welchem Gebiet die gefundene Person Tätig ist bzw. was ihre Kompetenzen sein könnten.

Der „Groups“-Tab beinhaltet alle Gruppen, die mit dem gesuchten Begriff getagt wurden. Für die Darstellung der einzelnen Gruppen wurde das Icon mit den drei menschenähnlichen Figuren gewählt (vgl. Abbildung 3), weil für die gewöhnliche Kreisform nicht genügend Platz vorhanden ist. Um sich die detaillierten Inf­­ormationen über eine Gruppe anzusehen, muss diese angeklickt werden. Die Gruppen werden, analog zu den Usern, mit ihren populärsten Tags angezeigt.

Abbildung 3: Suchergebnisse in SuTeCo: Groups

Im Tab „Virtual Groups“ sind alle gefundenen Systemnutzer nach ihrem Ranking aufgelistet (vgl. Abbildung 4). Durch das Bewegen des Sliders, der sich über dem blauen Button „Create Virtual Group“ befindet, kann man die Gruppenzugehörigkeit von gefundenen Personen abgrenzen.

Wie auf der Abbildung ebenfalls zu sehen ist, sind zwei Personen ausgewählt worden, die ein Ranking zwischen 0 und 2 haben.

Abbildung 4: Suchergebnisse SuTeCo: Virtual Group

Wenn der Nutzer passende Ranking-Werte gesetzt hat, kann er auf den Button „Create Virtual Button“ klicken, um eine Virtuelle Gruppe zu erstellen. Wenn diese neue Gruppe angelegt wurde, erscheint sie unter der „Gruppenverwaltung“ des Users, der sie angelegt hat (vgl. Abbildung 5).

Abbildung 5: Virtuelle Gruppen in SuTeCo

Virtuelle Gruppen haben das gleiche Erscheinungsbild wie normale Gruppen und lassen sich auch beobachten (Follow-Prinzip).

Der Unterschied besteht darin, dass die Gruppenmitglieder automatisch der Gruppe zugewiesen werden. Als Kriterium für solch eine Zuweisung dient das Group Ranking, das durch den Besitzer der Gruppe beeinflusst werden kann.

Noch bestehende Probleme

Eines der größten Probleme, das noch nicht gelöst wurde, ist die Abbildung der Organisationsstruktur. Dafür müssen noch Datenstrukturen entwickelt werden, mit denen nicht nur einzelne Organisationseinheiten, sondern auch deren Ebenen abgebildet werden können.

Es wurden schon mehrere Beispiele gefunden, in denen das Darstellen von Organigrammen möglich ist. Die Fähigkeit, einzelne Ebenen abzubilden wurde jedoch in keinem dieser Beispiele realisiert (vgl. Abbildung 6).

Wenn jemand eine Lösung kennt, möge er sich bitte so schnell wie möglich bei mir melden, da es eilt.

Vielen Dank im Voraus!

Es sollen entweder eine komplette Gruppe oder einzelne Mitglieder mit dem Mauszeiger auf das Empfängerfeld gezogen werden (vgl. Abbildung 1).

Abbildung 1: Eine Gruppe per Drag&Drop in die Empfängerliste einfügen

Wenn dies gemacht wird, erscheinen alle Mitglieder der Gruppe in der Empfängeliste. Gleichzeitig erhöht sich die Anzahl der Empfänger, die im grünen Kreis unten rechts vom Briefumschlag-Icon angezeigt wird (vgl. Abbildung 2).

Abbildung 2: Vorbeireten einer nachricht zum Versenden

Eine weitere Möglichkeit die Gruppen oder deren einzelne Mitglieder in die Empfängerliste zu setzen ist das Ziehen des Briefumschlag-Icon auf die gewünschte Gruppe bzw. Person. Mit dieser Aktion werden entweder alle Mitglieder der Gruppe oder nur einzelne Personen auf die Empfängerliste gesetzt.

Wie man sehen kann (vgl. Abbildung 2), gibt es auch die Möglichkeit einzelne oder mehrere Empfänger von der Liste zu löschen, indem das Mülleimer-Icon angeklickt wird.

Klickt man auf den Send-Button, so werden alle Daten erst an den Server Übertragen, dann alle Personen auf der Empfängerliste mit den  angegebenen Schlagwörtern gettagt  und die Nachricht schließlich an alle Empfänger gesendet.
Während diese Operationen ausgeführt werden, erscheint das entsprechende Modalfenster (vgl. Abbildung 3).

Abbildung 3: Versenden einer Nachricht im Prozess

Erste Test haben jedoch ergeben, dass die Datenverarbeitung und Nachrichtenversendung so schnell abgeschlossen werden, dass die Einblendung des Modalfensters höchstwahrscheinlich deaktiviert wird.

Noch nicht gelöste Probleme
Einige Elemente werden von anderen verdeckt. Beispiel: Das Briefumschlag-Icon wird beim Ziehen durch andere Fensterkomponenten verdeckt. Hierbei scheint es sich um ein CSS-Problem zu handeln, welches in Kürze gefixt wird (vgl. Abbildung 4).

Abbildung 4: Offensichtliches CSS-Fehler bei Draggen eines Objektes.

Das Verschicken einer Nachricht im Namen eines registrierten Benutzers ist unmöglich, weil man Zugang zu seinen Persönlichen Daten braucht. Darüber wird noch mit RB Rücksprache gehalten.

Suchfunktion
Wie bereits im letzten Post erwähnt, wurde für die Suche nach Personen bzw. Gruppen das Volltextsuchsystem Apache Solr verwendet.
Als erstes wurde die Suche für Gruppen implementiert. Die ersten Tests haben eine sehr hohe Flexibilität der Suche und Qualität der Ergebnisse gezeigt. Die Geschwindigkeit konnte nicht gemessen werden, die durchsuchten Datenmengen nur sehr klein waren.
Während der Entwicklung bin ich aber auf ein Problem gestoßen, dessen Lösung wahrscheinlich irgendwo schon vorliegt. Da  Solr die Tabelle durchsucht, in der eine Gruppe mehrmals mit einem Schlagwort gettagt wurde, liefert es auch redundante Ergebnisse, was aber nicht nötig ist.
Ich brauche eine Lösung für folgendes Szenario:
Wenn eine Gruppe gefunden wird, die mindestens einmal mit dem gesuchten Begriff getaggt wurde, soll diese nur ein mal als Ergebnis ausgegeben werden.

Wenn jemand eine Lösung für mich hat, wäre ich sehr dankbar.

Here’s an excerpt:

4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 14,000 views in 2012. If each view were a film, this blog would power 3 Film Festivals

Click here to see the complete report.

Da die Gruppenverwaltung der zu entwickelnden Applikation SuTeCo um einige neue Funktionen erweitert wurde, möchte ich diese nun kurz erläutern.
Das Konzept „Gruppenkreis“, das ähnlich wie bei Google+ realisiert wurde, sieht vor, dass die Fotos der Mitglieder der Gruppen am Rand des Kreises auch in Kreisform (mit abgerundeten Ecken) angezeigt werden (Abbildung 1).
Da es aber unmöglich ist, die Fotos aller Mitglieder der Gruppe im Gruppenkreis darzustellen, werden nur acht Mitgliederfotos angezeigt, die in der jeweiligen Gruppe am aktivsten sind. Um ihre Aktivität festzustellen muss man mit dem Mauszeiger über das Profilfoto gehen. Es erscheint ein Tooltip, das die Aktivität des Mitglieds anzeigt (vgl. Abbildung 1).
Die Tag Cloud wurde auch mit einer Tooltipfunktion versehen, damit man sofort feststellen kann, wie oft der Einzelne mit einem Tag in Verbindung gebracht wurde (Abbildung 2).

Abbildung 1. Gruppenverwaltung in SuTeCo

Abbildung 2. Tag Cloud in der Gruppenverwaltung SuTeCo

Activity Stream Spezifikation
Activity Stream ist eine Liste der Aktivitäten einer Person, in der Regel auf einer Webseite, die ausgeführt wurden. Ein Beispiel dafür ist Facebook mit der sogenannten „Timeline“.
Activity stream ist ein offener Standard, der für das Sozialweb spezifiziert wurde. Eine detaillierte Beschreibung findet man unter http://activitystrea.ms

Für die Implementirung wurde Activity Schema als Basis für die Datenstruktur des Activity Stream verwendet. Der Activity Stream wird in der Datenbank gespeichert und hat folgende Datenstruktur:

• ID – Identification Number (increment)
• Actor – Objekt, das die Aktion durchführt
• Verb – die Verb Phrase, die die Wirkung der Aktivität identifiiert (z.B. tag, create, add etc.)
• Target – Das Objekt, über das die Aktivität durchgeführt wird
• Object – Objekt, das an die Aktivität angebunden ist
• Object_type – Type des Objektes, das an die Aktivität angebunden ist
• timestmp – Zeitstempel

Anhand des folgenden Beispiels soll deutlich werden, wie das Tagging einer Person (People Tagging) in der Activity Stream Datenstruktur abgebildet wird.
Aktivität: Juri Kostik die Person Franziska Reichelt mit „hni“ und „pr-team“ getagt (Abbildung 3).

Abbildung 3. Ein Eintrag in Activity Stream (SuTeCo)

Activity Stream:

• ID: 234
• Actor: Juri Kostik
• Verb: tag
• Target: Franziska Reichelt
• Object: 34 (ObjectID in der Tabelle, in der Tags gespeichert werden)
• Object_type: person
• Timestmp: 28/12/2012 04:20

Darstellung vom Activity Stream in SuTeCo
Die Activity Stream Liste erscheint auf der Profilseite eines jeden Benutzers. In dieser Liste werden alle eigene Aktivitäten des Nuters abgebildet und die Aktivitäten der Benutzer und Gruppen, die er beobachtet bzw. denen er folgt (Abbildung 4).

Abbildung 4. Activity Stream in SuTeCo

Diese Activity Stream Liste lässt sich filtern. Es kann eine von drei Optionen ausgewählt werden:

• alle Aktivitäten anzeigen. Das Bedeutet, dass sowhl eigene als auch die beobachteten Aktivitäten dargestellt werden.
• Nur eigene Aktivitäten anzeigen. Es werden nur die Aktivitäten des Benutzers angezeigt (keine beobachtete (followed) Personen bzw. Gruppen).
• Nur beobachtete Aktivitäten anzeigen. Es werden nur beobachtete Obekte wie Personen und Gruppen angezeigt, keinerlei eigenen Aktivitäten des Nutzers.

Die Anzahl von darzustellenden Aktivitäten auf einer Seite wurde aus Usability-Grunden auf zehn begrenzt. Wenn man aber ältere Aktivitäten des Benutzers sehen möchte, muss man die Activity Stream Liste ganz nach unten scrollen und an Ende der Liste den Button „Show more“ anklicken. Danach erscheinen weitere zehn.

Suchfunktion nach Benutzer bzw. Gruppen, Bildung virtueller Gruppen
Die Suchfunktion befindet sich gerade in der Entwicklungsphase. Es ist aber vorgesehen, eine Volltextsuchplattform auf Apache Solr Bais zu implementieren. Für das das Framework Django wurde eine Applikation Haystack entwickelt, die für die Volltextsuche eingesetzt wird und Apache Solr und viele andere Search Engines verwendet.

Wenn jemand schon damit Erfahrung hat, würde ich mich über Tipps oder Code Snippets freuen!

Nach eingehender Überlegung habe ich mich dafür entschieden, die bestehende Lösung für Tagging in Form eines Plug-Ins namens „Django-Tagging“ zu verwenden. Dieses Plug-In stellt ein bereit fertiges Tagging-Modell als auch umfangreiche Funktionalität zum Erstellen, Verwalten und Darstellen von Tags zur Verfügung.

Folgende Funktionen, die bereits in der zu entwickelnde Web-Applikation SuTeCo eingesetzt wurden, sind hier beispielhaft aufgeliestet:Einsatz des Variable-Typs „TagField“ bei der Definition von zwei Modellen (Gruppen, Personen)

• Einsatz des Variable-Typs „TagField“ bei der Definition von zwei Modellen (Gruppen, Personen)
• Generierung eines Tag-Clouds aus dem bestehenden Datensatz (Abbildung 1, Abbildung 2)
• Ausgabe von den meistvergebenen Tags

Darüber hinaus verwendet dieses Plug-In einige vordefinierte Template-Marker, die formatierte Ausgabe von Tags ermöglichen. Da aber dieses Template den Anforderungen der zu entwickelnden Applikation nicht entspricht, musste es erweitert werden.

Folgende Screenshots sollen den ersten Eindruck über die bereits implementierten Features fgeben.

Abbildung 1, Activity eines Benutzer mit TagClouds

Abbildung 2, Tag Cloud einer Gruppe

Activity Liste

Auf Basis von bereits implementierten Konzepten „People Tagging“ und „Following“ (Beobachtung)  kann eine Activity-Liste entstehen, die alle Aktivitäten von Benutzer bzw. Gruppen, die gefolgt (beobachtet) werden sollen, präsentiert. Eine solche Activity-Liste ist bereits bei allen Sozialen Netzwerken vorhanden. Das soziele Netzwerk Facebook bietet sogar zwei Darstellugnsformen an:

• klassische Sicht in Form einer Liste
• vertikale Sicht mit Trennung nach Datum der Aktion, das sogenannte „time line“-Konzept

In der zu entwickelnden Applikation soll eine klassische Variante implementiert werden. Diese wird mit einer Filterung versehen, um dem Benutzer die Möglichkeiten geben, nur bestimmte Aktivitäten anzuzeigen (Abbildung 1).

Meine Frage lautet: Hat jemand schon Erfahrung mit Implementierung von solchen Activitys? Mich interessiert, wie man die Daten aus verschiedenen Quellen (z. B. Aktivitäten von Personen und Gruppen) in eine Activity-Liste zusammenfast und darstellt.

Freue mich auf eure Tipps!

Im Anschluss daran ist eine Anwendung entwickelt worden, in der Lichtsensoren, Farbsensoren, Berührungssensoren, Ultraschallsensoren und Servomotoren simuliert werden können. Diese können flexibel innerhalb von aus Lego Komponenten gebauten Systemen integriert werden.

Motoren:

Bei der Umsetzung Motoren wurde auf Physikdetails (Erzeugung der Drehbewegung, Übertragung mittels Getriebe ect.) verzichtet und die Auswirkung der Motoren auf das Model fokussiert. Dabei wurde zwischen “Modell-Bewegungs-Motoren” (Bereits implementiertes Feature; Motoren, die eine Bewegung des kompletten Modelles auf der x,z Ebene bewirken) und “Interne-Bewegungs-Motoren” (Noch nicht implementiert; Motoren die Bewegungen innerhalb des Modelles bewirken – z. B. das Ausfahren des Arms eines Krans – sind dann interessant, wenn die Position von Sensoren durch die Bewegung beeinträchtigt werden).

Ultraschallsensoren:

Ultraschallsensoren wurden mithilfe eines einstellbaren (Abstand der einzelnen Rays, Öffnungswinkel des Kegels, Abtastrate ect.) Raycasting-Kegels umgesetzt. Die Evaluation der Rays bzw. die daraus zu erfolgende Bestimmung des Sensorwertes orientiert sich an den Messwerten von: ftp://ftp.tik.ee.ethz.ch/pub/students/2006-So/SA-2006-18.pdf

Lichtsensoren/Farbsensoren:

Wirklich brauchbare Evaluationsergebnisse für die Lichtsensoren und Farbsensoren lagen zum Zeitpunkt der Implementierung nicht vor. Als Problem hat sich dabei herausgestellt, dass sich die Farbe/Helligkeit von Polygonen, nicht durch ein einfaches Raycasting bestimmen lässt – die exakten Farb- und Helligkeitswerte liegen, befingt durch die LWJGL & OpenGL-Technologie auf der Grafikkarte und sind für den Entwickler grundsätzlich nicht zugänglich. Daher wurden Licht und Farbsensoren als Off-Screen-Szenenrenderer implementiert, bei dem die gerenderte Projektion mittels Offscreenshot (:-)) in den Hauptspeicher kopiert wird. Dieser zwar sehr exakte und allgemeine Sensor wirkt sich (nach ersten Erfahrungswerten) noch nicht negativ auf die Performance aus. Im Zweifelsfall wird noch ein weiterer Lichtsensor implementiert, der schneller, jedoch auf die Verfolgung von Fahrstraßen spezialisiert ist.

Berührungssensor:

Der Berührungssensor wurde als Kollisionslistener und -erkenner umgesetzt. Physikalische Details (Druckkraft, Druckwinkel) wurden dabei ignoriert. Er ist primär passiv bzw. arbeitet nur dann, wenn es eine Kollision im Szenario gegeben hat – unabhängig davon ob der Sensor selbst daran beteiligt ist. Die Arbeit des Sensors besteht darin herauszufinden, ob er selbst an einer der registrierten Kollision beteiligt gewesen ist. Intuitiv ist er daher effizient, wenn es wenige Kollisionen im Szenario gibt. Für Szenarien mit vielen Kollisionen wird eventuell ein weiterer Berührungssensor (basierend auf Raycastingtechnik), implementiert.

Für die simulierbaren Komponenten gibt es außerdem einige Spekrum an Konfigurationsparametern (Fehler, Abtastrate, Auflösung ect.). Außerdem verfügt die Anwendung über eine Ladefunktion, mit der Szenarien im XML-Format geladen werden können. Außerdem ist zu einem gewissen Maß Szenariomanipulation (Objekte hinzufügen/entfernen, Modelle hinzufügen/entfernen) und Simulationskontrolle möglich (manuelles Starten, Pausieren, Fortsetzen, Zurücksetzen, Stoppen und Löschen von primitiven Szeneobjekten und Modellen – sowohl einzeln als auch für alle Modelle/Objekte). Kontinuierliches Rendering, Kollisionserkennung, Kontrolle der Kameraposition werden unterstützt.

• Was ist das Thema der Masterarbeit?

“Analyse des IKNOW Forschungsnetzwerkes und Visualisierung von Forschungstrends – Datenbereinigung, Analyse mit Trenderkennung und Visualisierung“

In meiner Masterarbeit beschäftige ich mich mit der Analyse der eingereichten Paper der Konferenz IKNOW.
Weiterhin sollen die Ergebnisse grafisch dargestellt werden.

Datenbereinigung

• Warum ist das nötig?

Um aussagekräftige Analysen mit korrekten Daten zu erhalten, müssen die Quelldaten eine möglichst hohe Qualität aufweisen.
Durch die automatische Erkennung des KnowAAN-Tools ist diese Qualität nicht gewährleistet.
Eine manuelle Datenbereinigung erhöht die Qualität der Daten und ermöglicht erst Auswertungen zum Inhalt der vorhandenen Konferenzpaper.

• Welche Daten sind vorhanden?

Die IKNOW-Konferenz hat bisher jährlich von 2001-2012 stattgefunden.
Die vorhandenen, eingereichten Paper wurden in das KnowAAN-Tool, das durch die PG KnowAAN erstellt wurde, geladen.
Bisher sind insgesamt 622 Paper im System.
Diese können mit dem KnowAAN-Documentbrowser exploriert, und mit einer Editionsmaske bearbeitet werden.
Weitere Paper sind auf den Konferenzseiten aufgeführt, konnten aber noch nicht in das System geladen werden.
Die Konferenzseite zählt zusammen 663 Paper auf.

• Aufwandsschätzung im Vorfeld:

Um den Aufwand für die manuelle Datenbereinigung abzuschätzen, wurde die folgende Rechnung erstellt.
Bei einem Paper werden die Kopfdaten und die Referenzen bearbeitet.
Als Schätzung wurden 10 Minuten für die Kopfdaten und 20 Minuten für die Referenzen pro Paper angenommen.
Dabei werden 20 Referenzen pro Paper vermutet und jeweils 1 Minute pro Referenz gerechnet.
Bearbeitung gesamt: 30 Min. / Paper

Bei einer maximal geplanten Bearbeitungszeit zur Datenbereinigung von 2-2.5 Monaten steht folgende Zeit zur Verfügung.
Arbeitszeit: 6 Stunden / Tag ; 5 Tage / Woche (Mehr Zeit kann hier für diese Aufgabe nicht eingesetzt werden, da die Konzentration nachlässt und Fehler entstehen.)
12 Paper / Tag
60 Paper / Woche
in 10 Wochen sind somit 600 Paper bearbeitbar

Vorgehen:
Aufteilen der Korrekturen in 2 Phasen / Durchläufe.
Phase 1: Kopfdaten bereinigen
Phase 2: Referenzen bereinigen

Nachteil: Jedes Paper wird doppelt bearbeitet.
Vorteil: Man erhält schneller einen Überblick über alle Paper, da die kürzere Aufgabe zunächst für alle Paper durchgeführt wird.
Als Folge können mögliche Probleme eher erkannt werden und der weitere Aufwand kann besser abgeschätzt werden.

• PHASE 1: Kopfdaten bereinigen umfasst: Titel, Name Autor(en), Arbeitsstelle Autor(en), Ort der Arbeitsstelle, Schlüsselwörter, Jahr der Konferenz.

Die Arbeit mit 2 Bildschirmen (Editiermaske, Paper als PDF) ist sinnvoll.
Die Paper sollten der Reihenfolge nach bearbeitet werden.
Die Sortierung nach Jahr und eine alphabetische Sortierung innerhalb eines Jahres hat sich als sinnvoll erwiesen.
Man sollte hierbei mit den früheren Jahren beginnen, da man bei Papern aus späteren Jahren auf bereits korrigierte Paper aus früheren Jahren zurückgreifen kann.
Die bearbeiteten Paper sollte man sich merken/notieren.

Bei den Kopfdaten soll der Ort der Arbeitsstelle für jeden Autor erfasst werden.
Die Ortsangaben werden für Kartenansichten benötigt, die die Herkunft der Autoren darstellen.
Als Genauigkeitsmaßstab werden im Allgemeinen die Stadt und das Land angegeben.
In einigen Papern ist die Stadt jedoch nicht angegeben.
Hier ist eine zusätzliche Recherche erforderlich (mit Autor und Firma).
Die Angaben zu Abkürzungen von Kategorien werden als Schlüsselwörter mit aufgenommen.

Die Korrektureingabemaske ermöglicht die Speicherung erst dann, wenn alle Pflichtfelder gefüllt sind.
Durch fehlerhafte Erkennung in der automatischen Vorverarbeitung der Paper ist es möglich, dass die Referenzen nicht in einem “korrekten” Zustand sind.
Daher werden die vorhandenen, erkannten Referenzen soweit korrigiert, dass diese Änderungen gespeichert werden können.

Jeder Benutzer der Web-Applikation SuTeCo soll die Möglichkeit haben, einen anderen Benutzer dieser Applikation mit Schlagwörtern zu versehen bzw. zu taggen.  Außerdem soll es möglich sein, sowohl eigene als auch Follow-Gruppen zu taggen.

Die entstandene Datenbank mit Tags wird später für die Suche nach Ansprechpartnern bzw. deren Kompetenzen eingesetzt.

Das „People Tagging“- Modell
Um das „People Tagging“- Konzept zu realisieren, wird ein Django-Modell angelegt (Abbildung 1). Hier fehlt der Bindestrich, es ist unlogisch dass du es in der Überschrift in Anführungszeichen und Bindestrich schreibst und hier ohne beides, das solltest du einheitlich machen.

Abbildung 1, People Tagging Modell

Da die zu entwickelnde Applikation aber auf eine externe Datenbank zugreift, um Benutzerdaten wie BenutzerID oder E-mail abzufragen, gibt es keine Möglichkeit die Datenintegrität zwischen dem Tagging- (Abbildung 1) und User-Modell mit relationalem SQL-Modell zu realisieren (zwei Modelle direkt zu verbinden).

Wie man in der Abbildung nachvollziehen kann, werden alle Tags redundanzlos in der Tabelle „Tag“ gespeichert. Alle gespeicherten Tags werden auf der relationalen Ebene mit der Tabelle „People Tagging“ verbunden. In dieser Tabelle werden sowohl Objekt und Subjekt des People Taggings, als auch Zeitstempel und Tagging-Flag gespeichert. Eine Tagging-Flag wird gebraucht, um zu unterscheiden, ob eine Gruppe oder eine Person getagt wurde. Durch eine GroupID wird das „People Tagging“-Modell mit dem Gruppenmodell verbunden (Abbildung 2).

Abbildung 2, Relationales Modell People Tagging und Gruppenverwaltung

UIs für People Tagging
Um erhaltene und vergebene Tags für den Benutzer übersichtlich darzustellen, werden Tag Clouds (Abbildung 3) und andere Darstellungsformen (Abbildung 4) eingesetzt.

Abbildung 3, Tag Cloud

Abbildung 4, People Tagging in SuTeCo

P.S. Falls jemand eine interessante Idee oder einen Vorschlag für die Darstellung der TagCloud oder den Aufbau eines Datenmodells für People Tagging hat, schreibt mir bitte! Ich freue mich auf jeden Kommentar!

• Anzeige von eigenen Gruppen und Followed-Gruppen sowie deren Beschreibungen
• Erstellen / Löschen eigener Gruppen
• Folgen / Entfolgen von Gruppen
• Einfügen / Löschen neuer Benutzer
• Taggen von Gruppen

Wie in Abbildung 1 zu sehen, soll die Seite des Gruppenmanagements alle eigenen und Follow-Gruppen in Kreisform darstellen. Im rechten Seitenbereich werden detaillierte Informationen über die jeweils ausgewählte Gruppe dargestellt. Das Steuerungspanel mit den Buttons „Gruppe anlegen“ oder „Gruppe löschen“ wird nach vielen Überlegungen nicht hier platziert, da es aus Usability-Gründen nicht hierher passt. Die anderen Elemente der Benutzeroberfläche bleiben an der Stelle, wo sie geplant war.

Den ersten Screenshot der zu implementierenden Oberfläche sieht man auf Abbildung 2. Benutzer „Juri Kostik“ legte ein Gruppe an. Diese Gruppe hat Mitglieder, die auf dem Screenshot noch nicht zu sehen sind. Die entsprechende Funktion befindet sich noch in der Implementierung.

Abbildung 1, Gruppenverwaltung (MockUp)

Abbildung 2, Screenshot der Benutzeroberfläche “Gruppenverwaltung”

Gruppen auf Modell-Ebene abbilden
Die Usergruppen und deren Mitglieder wurden als Django-Modell angelegt und mit Hilfe von Object-Relational Mapper (ORM) auf der Datenbankebene abgebildet (Abbildung 3). Auf dieses Modell können später auch die anderen Apps zugreifen, die im Rahmen dieser Masterarbeit entwickelt werden. Dafür bietet Django eine sehr umfangreiche Funktionalität.

Abbildung 3, Datenbankmodell der Gruppenverwaltung

In Abbildung 4 sieht man, dass die Tabelle „Group“ zwei angebundene Tabellen hat: „GroupMember“, in der alle Gruppenmitglieder gespeichert werden, und „GroupFollow“, in der Follower der jeweiligen Gruppe gespeichert werden.

Abbildung 4, Gruppenverwaltung – Django Modell

Für die Darstellung von detaillierten Informationen über die ausgewählte Gruppe und deren Gruppenmitglieder werden schon realisierte Funktionen der LDAP-Abfrage benutzt. Diese Funktionen wurden ursprünglich „universell“ entwickelt, sodass sie als Ergebnis eine Datenkette im JSON-Format zurückliefern, die später ziemlich einfach dargestellt werden kann.

1. Simulationsumgebung: 3D-Visualisierung der Simulation, Umsetzung von Aktorbefehlen, Lesen von Sensorwerten (aus der Szene), Laden + Speichern von Szenarien, einfache Szenarienmanipulation
2. Emulation: Umgebung zum Schreiben der Steuerungsprogamme + Ausführung der Steuerungsprogramme (Kommunikation mit 4. erforderlich)
3. Modelleditor: Editor zum Erstellen von Modellen (z. B. Mindstorms-Roboter)
4. Szenarieneditor: Editor zur Erstellung komplexer Szenen, die den grafischen Ansprüchen der Schüler gerecht wird

Im Rahmen meiner Arbeit wird die Simulationsumgebung und ein Protokoll für die Kommunikation zwischen Emulation und Simulationsumgebung entwickelt.

Es erfolgte bisher eine Einarbeitung in Grundlagen und verwandte Arbeiten. Da durch die Verwendung einer geeigneten 3D-(Game-)Engine auf lange Sicht viel Zeit bei der Implementierung gespart werden kann, wurde außerdem ein Vergleich von 3D-(Game-)Engines durchgeführt.

Verglichen werden:

• Ardor3D
• Aviatrix3D
• Env3D
• Espresso3D
• JMonkeyEngine
• jPCT
• Xith3D

Als interessant herausgestellt haben sich die JMonkeyEngine, Xith3D und Env3D.

• JMonkeyEngine: Ist, allem Anschein nach, die am häufigsten empfohlene und verwendete Java basierte Game Engine. Sie verfügt über eine ausfürliche Dokumentation sowie eine vergleichsweise große und aktive Community und unterstützt viele Features die für NeXTsim relevant sind. (Swing kompatibel, Physik, eingebauter Renderer, Applets erstellbar, ect. …)
• Xith3D: Benutzt als einzige Game-Engine in dem Vergleich die Physikengine JOODE. Alle anderen Engines benutzen (sofern Physik überhaupt unterstützt wird) JBullet.
• Env3D: Die Spieleentwicklung soll mit Env3D besonders leicht sein. Sie ist für Didaktiker besonders interessant.  Die Engine wurde entwickelt um Schülern/Studenten Programmiertechnik zu vermitteln: durch die Entwicklung von Spielen.

3D Szene = Virtuelle 3D Welt
Modell = ein virtuelles aus Lego (Mindstorms) Komponenten aufgebautes System, das über in der Regel einen NXT-Baustein verfügt und daran angeschlossene Aktoren und Sensoren
Szenario = 3D Szene + darin platzierte Modelle

Ich bin gespannt, denn es ist ein komisches Gefühl, ein Stück Software auf die Welt “loszulassen”, von dem man selbst genau weiß, dass es noch nicht ganz perfekt ist ;-)

Website-Besucher

Ziel der Evaluation ist es, herauszufinden, ob die Bedienung von ADORE leicht verständlich (intuitiv) ist, und ob die gewählte Darstellung ein Mehrwert für den Betrachter der Seite darstellt. Dazu kommt das bereits hier im Blog vorgestellte Greasemonkey-Skript für Firefox zum Einsatz. Die Schritte sind im Einzelnen:

0. Optional, aber für das Verständnis stark empfohlen: Nochmal schnell meinen Blogpost zu ADORE und Greasemonkey lesen.

1. Greasemonkey-Plugin für Firefox installieren.

2. Das Userscript installieren.

3. TheMovieDB.org besuchen und nacheinander verschiedene Actor-Seiten ansurfen (z.B. Mark Hamill und Harrison Ford aus Star Wars).

4. Mit Klick auf “<” und “>” kann durch die Liste der gemeinsamen Filme geschaltet werden.

5. Fragebogen ausfüllen.

Danke!

Web-Designer

Ziel der Evaluation ist es, herauszufinden, wie  einfach oder schwer es ist, Beziehungen zwischen Objekten mit ADORE auszudrücken und ob die eingesetzten Methoden (JSON/CSS) sinnvoll sind.

1. Das ADORE Testbed besuchen.

2. Herumspielen, soviel man mag.

3. Fragebogen ausfüllen.

Danke!

Die einzelnen Organisationseinheiten werden wie auf der Abbildung 1 dargestellt ist, abgebildet.

Abbildung 1. Darstellungsbeispiel einer Organisationseinheit

Um die Eingabe für jOrgChart zu liefern, soll ein bestimmter Teil der LDAP-Struktur vom Django rekursiv gelesen und danach an das Plug-In übertragen werden.Für die zu entwickelnde Web-Applikation muss der Teilbaum „Groups“ mit allen Unterbäumen rekursiv gelesen und im JSON Format gespeichert werden.

Abbildung 2. Beispiel der Baumstruktur (Links)

Da mit JSON beliebig verschachtelte Datenstrukturen möglich sind, eignet sich  dieses Format für die Abbildung der hierarchischen Struktur und für die Netzwerkübertragung der Daten sehr gut.

Um benötige Daten vom LDAP zu bekommen wird das Python Modul „ldap“ eingesetzt. Dieses Modul stellt Funktionen zur Verfügung, die es erlauben, den LDAP-Baum komplett oder nur auf einen Teilbaum begrenzt zu durchsuchen.  Ein  kleines Code-Beispiel wäre:

AUTH_LDAP_SCOPE = ldap.SCOPE_ONELEVEL

scope = AUTH_LDAP_SCOPE

filter = "(&(objectclass=groupOfNames))"
 values = ['cn','owner', 'description', 'member']
 l = ldap.open(AUTH_LDAP_SERVER)
 l.protocol_version = ldap.VERSION3
 l.simple_bind_s(AUTH_LDAP_BASE_USER,AUTH_LDAP_BASE_PASS)
 result_id = l.search('ou=Groups,'+AUTH_LDAP_BASE, scope, filter, values)
 result_type, result_data = l.result(result_id, 1)

for data in result_data[1]:
 if data:
 result_set.append(json.dumps(data))

Ob der ganze Baum oder nur ein Teil davon durchsucht werden soll, entscheidet der SCOPE – Parameter. Dieser kann folgende Werte haben (Abbildung 3):

• SCOPE_BASE – nur der Startknoten des Baums (Teilbaums) betrachten
• SCOPE_ONELEVEL – alle Kinderknoten des Startknotens (Startknoten inklusiv) betrachten
• SCOPE_SUBTREE – der gesamte Baum (Teilbaum) inklusiv Startknoten betrachten

Abbildung 3. Scope Parameter für LDAP-Suche
(Quelle: http://www.idevelopment.info/data/LDAP/LDAP_Resources/SEARCH_Setting_the_SCOPE_Parameter.shtml)

Aus der Beschreibung kann man sehen, dass der Parameter SCOPE_SUBTREE sehr gut für die Suche nach einzelnen Benutzern passt, da  der komplette Baum durchgelaufen wird.

Um die hierarchische Struktur in JSON umzuwandeln, wird aber der Parameter SCOPE_ONELEVEL eingesetzt. Damit kann nur eine Ebene des Baumes durchgelaufen werden. Darauf folgend wird dieselbe Funktion rekursiv aufgerufen, um alle Unterknoten einer Elternknote herausfinden zu können.

Die JSON Datenstruktur, hat danach folgende Form.

<i>{ "cn": "DDI", "description": "Didaktik der Informatik", "owner": { "cn": "ysl", "title": "Prof. Dr.", "bcategory": "Leitung", "etype": "Leiter", "firstname": "Johannes", "lastname": "Magenheim", "fax": "05251 / 60 6336", "telephone": "05251 / 60 6341", "adres": "Heinz Nixdorf Institut, Fürstenallee 11, Paderborn 33102", "room": "F2.116", "email": "jsm@uni-paderborn.de", "description": "" }, "members": [{"cn": "wolle", "title": "Dr.", "bcategory": "wissenschaftlicher Mitarbeiter", "etype": "Mitarbeiter", "firstname": "Wolfgang", "lastname": "Rheinhard", "fax": "05251 / 60 6336", "telephone": "05251 / 60 6603", "adres": "Heinz Nixdorf Institut, Fürstenallee 11, Paderborn 33102", "room": "F2.201", "email": "wolle@uni-paderborn.de"}, {"cn": "jkostik", "title": "", "bcategory": "SHW", "etype": "Student", "firstname": "Juri", "lastname": "Kostik", "fax": "05251 / 60 6336", "telephone": "05251 / 60 6603", "adres": "Heinz Nixdorf Institut, Fürstenallee 11, Paderborn 33102", "room": "F0.107", "email": "jkostik@live.uni-paderborn.de" }], "sub":"true", "subtree": [{Untergruppen .....}] }</i>

Falls jemand eine bessere Idee hat, wie man einen LDAP-Teilbaum mit Python in JSON umwandeln kann, würde ich mich sehr freuen. :)

Hier sind die Folien zu meiner Analyse, die teilweise in der Keynote verwendet wurden (es kam übrigens sehr gut an…):

Wie in meinem zweiten Post schon bereits erwähnt wurde, habe ich mich für die Darstellung der visuellen Hierarchien (Organigramm)  für das jQuery-Basiertes Plug-In  „jOrgChart“  entschieden. Dieses Plug-In wird benutzt, um die hierarchische Struktur einer Organisation, die im LDAP  abgebildet ist, darzustellen.

Dieses Plug-In wurde von Wesley Nolte [http://twitter.com/wesnolte] entwickelt und wird nach dem GPL- und  MIT-Lizenz verbreitet.  Es besteht aus zwei Dateien: einer JavaScript-Datei (das eigentliche Plug-In) und einer CSS-Datei (Style).

Die Funktionsweise des Plug-Ins ist ziemlich einfach. Es bekommt als Eingabe eine ziemlich einfache  verschachtelte HTML-Struktur, die aus UL und LI-Tags besteht. Ein kleines Beispiel solcher Struktur wäre:

<ul id="org" style="display:none">
 <li>
 Leiter HNI<p>Prof. Dr.-Ing. Ansgar Trächtler</p>
 <ul data-content-theme="Leitung">
 <li>Fachgruppe DDI<p>Prof. Dr. Johannes Magenheim</p>
 <ul>
 <li>Sekretariat<p>Klaudia Jakob</p></li>
 </ul>
 </li>
 <li>Fachgruppe MMW<p>Prof. Dr. gerd Szwillus</p>
 </li>
 <li class="fruit">Fachgruppe PE<p>Prof. Dr.-Ing. Jürgen Gausemeier</p>
 <ul>
 <li>Team EM<p>Dipl.-Wirt.-Ing. Tobias Gaukstern</p>
 </li>
 <li>Team IM<p>Dipl.-Wirt.-Ing. Niklas Echterhoff</p>
 </li>
 <li>Team VE<p>Dipl.-Wirt.-Ing. Tobias Bensiek</p>
 </li>
 </ul>
 </li>
 </ul>
 </li>
 </ul>

Durch die Styles-Einstellungen (style=”display:none”) in der ersten Zeile wird verhindert, dass die vordefinierte Struktur als eine Aufzählungsliste ausgegeben wird, sondern vom Plug-In als Eingabe benutzt wird.

Abbildung 1.  Organigramm, das mit jOrgChart generiert wurde

Das Plug-In wandelt diese Struktur in eine Tabelle mit mehreren Untertabellen um, die aus TR-und TD-Tags besteht.  Je nachdem, ob eine Zelle der Tabelle ein Knoten ist oder ein Blatt, wird diese mit der dazu passenden CSS-Klasse versehen (Abbildung 2).

Abbildung 2. Table basierte HTML-Struktur, die vom jOrgChart Plug-In generiert wurde

Geplanter Umbau des Plug-Ins

Das Plug-In jOrgChart entspricht aber nicht allen Anforderungen, die im Rahmen dieser Masterarbeit implementiert werden sollen. Aus diesem Grund soll das Plug-In durch folgende Funktionen erweitert werden:

1. Darstellung von Ebenen, mit der Möglichkeit die ganze Ebene in die Empfängerliste zu setzen (Abbildung 3),
2. Darstellung der einzelnen Organisationseinheiten mit zusätzlichen Informationen wie Name, Vorname, Fotos etc.,
3. Drag&Drop Funktionalität,
4. PopUp-Menü Fenster,
5. Datenübertragung im JSON-Format

Abbildung 3. Geplante Umbau des Plug-Ins  jOrgChart

Eingaben für jOrgChart

Als Eingabe für das o.g. Plug-In wird ursprünglich eine ziemlich einfache HTML-Struktur benutzt, was das Plug-In ziemlich einfach und übersichtlich macht. Das Problem taucht erst dann auf, wenn die Organisationsstruktur, die dargestellt werden soll, größer als ein paar Ebenen mit 20 oder 30 Organisationseinheiten wird.  Dann sollen ziemlich große Datenmengen vom Server an den Client übertragen werden (persönliche Daten mit Fotos).

Um die Wartezeit zu verkürzen, werden die Daten im JSON Format übertragen. Die zweite Möglichkeit die Wartezeit zu verkürzen, ist die Beschränkung von sofort anzeigenden Ebenen. Das bedeutet, dass nach dem Öffnen des Fensters beispielweise nur die ersten zwei Ebenen angezeigt werden. Um weitere Ebenen anzuzeigen, sollen sie manuell per Mausklick geöffnet (expandiert) werden.

Ansonsten war ein relativ großer Arbeitsteil der letzter Zeit, dass ich mich mit der Auswertung der Umfrage beschäftigt habe, über die ich ja bereits im letzten Blogeintrag geschrieben habe. Die Ergebnisse waren insgesamt ziemlich durchwachsen, insbesondere einige der genannten negativen Dinge, widersprachen teilweise von mir bewusst getätigten Designentscheidungen. Zum Beispiel haben sich mehrere Personen alphabetisch sortierte Circos-Diagramme gewünscht, was allerdings mit der von mir eingesetzten Ordnung (um die Kantenüberlappungen zu minimieren) nicht möglich ist. Zudem hatten viele Personen Schwierigkeiten bei der Bedienung der Anwendung (also den mit Sigma.js dargestellten Graphen) und auch die Interpretation der Daten schien außergewöhnlich schwer zu sein. Daher sollte man eventuell weitere Hilfe (zum Beispiel in Form von Tool-Tipps, etc.) anbieten. Außerdem war relativ deutlich zu erkennen, dass die Beispiel-Auswertung für das Circos-Diagramm nicht ausreicht, um den Benutzern die Darstellung und Interpretation der Diagramme hinreichend genau zu erklären, da dort noch sehr viele Fehler gemacht worden sind.
Trotzdem brachte die Umfrage viele neue Ideen und Anregungen für weitere Arbeit und könnte meiner Meinung nach durchaus die Grundlage für eine ganz neue Bachelorarbeit bilden. Das Potenzial ist auf jeden Fall vorhanden.

Daten für die Unit-Tests

Drei Nutzer, zwei Gruppen und drei kleine Bäume sollen reichen, um alle Funtionen zu testen. Falls mir weitere Konstellationen einfallen oder weitere Methoden hinzukommen, werde ich das Test-Szenario erweitern.

In einer ersten Implementierung bestehen die Berechtigungen lediglich aus dem Lesezugriff. Später werde ich die Tests mindestens um Schreib- und Einfügeberechtigungen erweitern, um diese auf Korrektheit überprüfen zu können.

Zunächst die Funktionen, die ich hiermit testen werde. Statt der Methodennamen gebe ich hier nur an, was diese zurückliefern. Methoden die einen Wahrheitswert zurückliefern sind mit einem Fragezeichen versehen.

• Aufruf auf einzelnen Knoten
  • Kindknoten
  • Anzahl der Kindknoten
  • Anzahl der Nachfahren
  • Vorfahren
  • Wurzelknoten
  • Knoten ist Blattknoten?
  • Knoten ist Kind von Knoten X?
  • Knoten ist Geschwisterknoten von X?
  • Knoten ist Nachfahre von X?
• Klassenmethoden
  • Ganzer Baum
  • Wurzelknoten

Die Überprüfung der Methoden stellt sicher, dass die Struktur und die Berechtigungen korrekt erzeugt wurden und die Ergebnisse der Methoden entsprechend der Berechtigungen erzeugt werden. Die Ergebnisse variieren, je nachdem, welcher Nutzer die Methode aufruft.

Da Berechtigungen eine wichtige Rolle spielen, sind Knoten verschiedene Nutzer und Gruppen zur Berechtigung zugeordnet. Beispielsweise der Aufruf zur Anzahl der Kindknoten im Wurzelknoten im mittleren Baum sollte für Nutzer C die Anzahl 1, für Nutzer A 2 und Nutzer B 3 zurückliefern. Nutzer C hat nur auf einem Kindknoten eine Berechtigung, Nutzer A hat duch seine Gruppenzugehörigkeit die Berechtigung auf zwei Kindknoten und Nutzer B die Berechtigung auf allen Kindknoten.

Um die Bäume zu generieren habe ich eine Klassenmethode erstellt, die eine Python Liste der folgenden Struktur erwartet:

[
	{
	'data':
		{
		'name':'1',
		'authorname':'A',
		'users_allowed':['B'],
		'groups_allowed':['GA','GB']
		},
	'children':
		[
			{
			'data':
				{
				'name':'11',
				'authorname':'A',
				'users_allowed':[],
				'groups_allowed':['GB']
				}
			}
		]
	}
]

Diese Struktur ermöglicht eine leichte Erweiterung des Testaufbaus. Die Struktur der Abbildung ist bereits auf diese Weise implementiert und wird scheinbar erfolgreich geladen. Was derzeit noch fehlt, sind die weiter oben beschriebenen Testmethoden. Der Aufbau dieser Methoden sieht folgendermaßen aus: Da ich die erwarteten Ergebnisse kenne, wird das erhaltene mit dem erwarteten Ergebnis verglichen. Stimmt beides überein, ist der Test bestanden. Stimmt es nicht überein, liegt eine Fehlfunktion vor.

Sind alle Tests implementiert, kann ich alle Methoden am Stück testen lassen und sehe anschließend, welche Methode einen Fehler aufweist.

Im Rahmen dieser Masterarbeit wird beispielweise die Organisationsstruktur einzelner Arbeitsgruppen des Heinz Nixdorf Institut (HNI) abgebildet. Da aber die einzelnen Organisationseinheiten der Organisationsstruktur des HNI ziemlich viele Attribute haben (z. B. HNIStatus, HNI-ID), die im Rahmen dieser Masterarbeit nicht benutzt werden, wird ein „abgespeckte“ Schema der bestehenden Organisationsstruktur angelegt.
Ein Beispiel dieser Struktur ist:

Abbildung 1. LDAP-Struktur eines Benutzers

Da die bestehende LDAP-Struktur des HNI hauptsächlich zum Verteilen von Zugriffsrechten gedacht wurde, ist sie für die hierarchische Abbildung der Organisationsstruktur nicht gut geeignet und muss durch bestimmte Attribute erweitert werden:

• „owner“ – dadurch definiert man den Leiter einer Arbeitsgruppe bzw. eines Teams. Das Attribut wird nur einer Gruppe, bzw. einem Team zugewiesen, das einen Leiter hat (Abbildung 2).
• „businessCategory“ – gibt an, zu welcher Kategorie der Tätigkeit eine Person gehört (Abbildung 1). Dieses Attribut wird gebraucht, um die Mitarbeiter auf mehrere Ebenen zu gliedern.
• „employeeType“ – bezeichnet die Tätigkeit einer Person, wie Leiter, wissenschaftlicher Mitarbeiter, nicht wissenschaftlicher Mitarbeiter, etc. (Abbildung 1).

Abbildung 2. LDAP-Struktur einer Gruppe

Die Erweiterbarkeit des vorhandenen LDAP-Schemas durch eigene Attribute, macht den Einsatz vom LDAP sehr attraktiv.

LDAP-Module in Django
Um die Authentifizierung und Aufbau der Organigramm in der zu entwickelnden Web-Anwendung zu implementieren, werden zwei Module eingesetzt. Das erste Modul ist „django-auth-ldap“ und ermöglicht es, das Django-Projekt gegen einen beliebigen LDAP-Server zu authentifizieren. Das zweite Modul „ldap“ wird für die Abfrage der hierarchischen Struktur des LDAP-Servers benutzt.
Die beiden Module sind in der Standardinstallation von Django nicht verfügbar und sollten extra installiert werden.

Userinterface der Web-Anwendung
Um das User Interface zu gestalten wird CSS-Framework Bootstrap eingesetzt. Das Framework existiert schon als ein Toolkits für Django „django-bootstrap-toolkit“ und lässt sich ziemlich einfach einsetzen. Eine Sammlung von schon fertigen Form-Widgets erleichtert und beschleunigt die Entwicklung einer Benutzeroberfläche.
Darüber hinaus  ermöglicht Bootstrap Kompatibilität für die meist benutzten Browser, was dem Entwickler viel Arbeit abnimmt.

Visuelle Hierarchie (Organigramm)
Um das Organigramm im Browser abzubilden, ist der Einsatz vom jQuery Org Chart geplant. Da das PlugIn aber nicht allen Anforderungen entspricht, wird es weiterentwickelt.

Falls jemand andere PlugIns mit ähnlichen Funktionen kennt, wäre ich sehr dankbar!

Bei der Erarbeitung von Szenarien und einer weiter ausführenden Begründung für die Entwicklung von ELISMA gehe ich auf E-Learning im Bezug auf Cloud Computing ein. Doch die Schwerpunkte sind bei den wissenschaftlichen Beiträgen zu diesem Thema sehr unterschiedlich. Deshalb habe ich hierzu eine Bestandaufnahme vorgenommen, dessen Ergebnis ich hier kurz präsentiere.

E-Learning 2.0

Zunächst der Schritt von E-Learning 1.0 auf 2.0. Beeinflusst vom Web 2.0 wurden auch im Bereich des E-Learning Applikationen und Funktionen neu erfunden oder erweitert. Hierzu gehören folgende Applikationen beziehungsweise Funktionen: [vgl. Ebner 2007, Grosseck 2009]

• Weblogs
• Microblogging
• Wikis
• Podcasts
• Social Networking
• Social Bookmarking
• Sharing Applications (Photos/Videos/Slides)
• RSS Syndication

E-Learning an sich ist ein sehr weites Feld, welches ich in seinem Umfang auf technische Aspekte einschränken wollte. Hierzu habe ich mir einige wissenschftliche Beiträge zum Thema Lehr- und Lernmanagementsystemen angeschaut. Da es das LMS nicht gibt, sind große Unterschiede zwischen den einzelnen Systemen zu verzeichnen. Aus den wissenschaftlichen Artikeln habe ich einige wesentliche Unterstützungsfunktionen ausgewählt: [vgl. Hussain 2011]

• Dokumentenmanagement
• Content Management
• Kurse
• Forum
• Kalendar
• Portfolios
• Rollen
• Rechte

Mit Hilfe der Unterstützungsfunktionen ergibt sich bereits ein gutes Bild dessen, welche technischen Grundfunktionen von ELISMA unterstützt werden müssen.

Cloud Computing

Mit Diensten wie GMail, Dropbox oder Google Docs ist die Cloud vielen in Form von Software as a Service (SaaS) bekannt. Was die Cloud allerdings für E-Learning bedeutet, außer einer neuen Infrastruktur, ist mir bis vor kurzem eher unklar gewesen. Cloud LMS, Cloud Learning, Cloud based LMS, Cloud-based education. Diese Bezeichnungen hören sich nett an, sind auf den ersten Blick aber nicht sehr aussagekräftig, bis auf den Einsatz der Cloud. Eher eine Werbeaussage für den Einsatz moderner Technologien also.

Die große Mehrheit wissenschaftlicher Beiträge zu Cloud Computing in Verbindung mit E-Learning beschäftigen sich mit der Skalierbarkeit und Elastizität von Diensten in Bezug auf Rechen- und Speicherkapazität. Durch diese Elastizität sollen im Wesentlichen Kosten (Energiekonsum, etc.) eingespart werden.

Eine zweite wesentliche Richtung von wissenschaftlichen Beiträgen hat Dienste (SaaS) im Blick, die in einer Cloud zur Verfügung gestellt und anschließend zum E-Learning in einer Art Mashup bereitgestellt werden. Nichtsdestotrotz wird auch hier ein Augenmerk auf die Skalierbarkeit der Cloud gelegt.

Eine dritte Richtung kann als Cloud Based Learning (CBL) zusammengefasst werden. CBL steht für die Nutzung der Cloud in Form von Speicherplatz und Applikationen. Daten werden nicht mehr lokal sondern in der Cloud gespeichert, wo sie gemeinsam und unmittelbar bearbeitet werden können. Mehrfach hervorgehoben wird, dass, im Gegensatz zu einem “normalen” System, die Daten jederzeit verfügbar sind.

Meine Auffassung dazu ist folgende: Dass jederzeit alle Daten verfügbar sind, ist nicht darauf zu begründen, dass die Cloud zum Einsatz kommt. Viel mehr handelt es sich um eine neue Art von Anwendungen, die Schnittstellen bereitstellen, um Daten an jedem Ort auf verschiedenen Geräten verfügbar zu machen. Neu ist allenfalls die unmittelbare, kollaborative Bearbeitung von Dokumenten à la Google Docs, aber auch hier spielt die Cloud eine untergeordnete Rolle.

Die Cloud bietet einen flexiblen Umgang mit Ressourcen und ermöglicht so eine neue Art von Systemen. Neue Unterstützungsfunktionen für E-Learning werden hierdurch aber nicht unmittelbar ermöglicht. Vorteile der Cloud beschränken sich damit auf

• Kostenersparnis (nutzungsabhängige Abrechnung),
• Skalierbarkeit (Speicher- und Rechenkapazität) und
• einen einfachen Umgang mit (virtuellen) Ressourcen.

Habe ich etwas wesentliches vergessen? Ich bin für jeden Kommentar dankbar.

The survey can be found here and is separated into four small parts. In the first part you will see a „Co-Authorship“ graph of the ECTEL conference of the years 2006 to 2011. So, every node correspond to a scientist. Within this graph two nodes are connected, if the authors have at least one common publication. You can use this link to open the graph.

In the second part of the survey you will see a „Bibliographic Coupling“ graph of the ECTEL conference of the years 2006 to 2011. This graph connects two nodes (publications), if they have a common citation. The coupling strength of two given documents is higher the more citations they have in common. You can use this link to open the graph.

The third part of this survey will handle visualizations that has been created with Circos.
The Circos visualization that you can find here shows the top 40 co-authorships of the ECTEL from 2006 to 2011. You can use this example pdf to help you answering the questions of the survey.

The last part of the survey contains some questions taken from the INTUI questionnaire.

All in all, I would really appreciate your help by participating in this survey.
Thank you.

Als Grundlage betrachten wir TheMovieDB – eine offene Datenbank für Filme, Schauspieler und verwandte Informationen. Ein Beispiel-Screenshot zeigt eine Darsteller-Seite.

Die Idee war es nun, zu demonstrieren, dass vorhandene Websites mittels ADORE erweitert werden können. Da ich natürlich keinen Zugriff auf den Quellcode von TheMovieDB habe, habe ich das ganze als Greasemonkey Userscript implementiert. Dies hat als Bonus den Vorteil, dass verschiedene, auf ADORE basierende, Erweiterungen für eine Website einzeln ein- und ausgeschaltet werden können.

Wie sieht nun die Erweiterung für TheMovieDB aus? Da ADORE die Beziehungen zwischen (sozialen Objekten) darstellen kann, versucht die Erweiterung bei Aufruf einer Darsteller-Seite, alle Verbindungen dieses Darstellers zu einem anderen Darsteller zu finden. Der “andere Darsteller” ist in diesem Fall einfach der Darsteller, den man vor dem aktuellen betrachtet hat. Hier sind natürlich Variationen denkbar, wie z.B. alle Verbindungen des aktuellen Darstellers zu meinem Lieblings-Darsteller o.ä.

Um diese Verbindungen zu finden, habe ich die JSON API benutzt, die TheMovieDB anbietet. Da diese leider eine Begrenzung in der Anzahl der Abfragen hat, musste bei der Länge der Verbindung eine Einschränkung gemacht werden: Es wird die Verbindung meines aktuell betrachteten Darstellers zu einem anderen Darsteller über einen Film, an dem beide Darsteller gemeinsam mitgewirkt haben, angezeigt. Die CSS Formatierung, hier z.B. die Icons (= Filmplakate und Darsteller-Porträts) der Knoten wird on-the-fly generiert, ebenfalls unter Benutzung der TheMovieDB API. Aufgrund der Beschaffenheit der API und des Limits für Anfragen, sind komplexere Verbindungen leider nicht möglich. Das Ergebnis sieht dann z.B. so aus (Änderungen hervorgehoben):

Die Darstellung ist nicht vollständig formatiert, aber ich glaube das Konzept wird deutlich. Die meiste Arbeit war es, die Datensätze der JSON API von TheMovieDB zusammenzufassen und in ein ADORE-kompatibles Format zu bringen. Bei meinen Recherchen bin ich dabei auf JSON/T gestoßen – eine Möglichkeit, JSON Datensätze zu transformieren, ähnlich wie XSLT. Da ich aber, wie gesagt, komplexere Umformungen vornehmen musste, welche die Fähigkeiten von JSON/T übersteigen, habe ich meinen “Adapter” kurzerhand von Hand geschrieben.

Ein solcher Adapter ist natürlich für verschiedene Datenquellen immer neu zu schreiben, das eigentliche Userscript passt jedoch – in diesem Beispiel – in handliche 80 Zeilen.

Ich denke, das Beispiel zeigt gut, dass mit vertretbarem Aufwand vorhandene Websites durch ADORE erweitert werden können.

chr - ID1 values 0 240 green
chr - ID2 dummy 0 240 red


Dabei habe ich die zweite Zeile nur eingefügt damit ich am Ende die Hälfte des Kreises für mein Säulendiagramm benutze [ Deswegen ist das Label des zweiten Chromosoms auch dummy :) ]. Damit haben wir nun eine Chromosomlänge von 240 und können diese nun als X-Achse ausfüllen.

Hierfür können wir einfach die benötigten Daten für unsere Säulendiagramme tabellarisch in eine Datei eintragen. In dieser Datei beginnt die erste Spalte mit der ID des Chromosoms und in der zweiten und dritten Spalte befindet sich die „range“ des Eintrages (also zB. von 0 bis 5). Die letzte Spalte enthält dann den Wert für diesen Abschnitt.
In unserem Beispiel schreiben wir in diese Datei nun den folgenden Inhalt:

ID1 0 5 8
ID1 5 45 6
ID1 45 90 12
ID1 90 150 8
ID1 150 240 4


Jetzt werden diese beiden Dateien in die Circos Konfigurationsdatei eingebunden.

Da ihr die Dateien in einem gepackten Archiv herunterladen könnt, würde es wohl an dieser Stelle nicht viel Sinn machen die gesamten Dateien darzustellen, aber ich stelle mal ein paar Kleinigkeiten heraus, die nennenswert sind. In der Konfigurationsdatei ist zum Beispiel enthalten:

file_delim = \t

Dies besagt, dass die „Daten Dateien“ für die Diagramme und Chromosomen durch Tab getrennt werden und nicht wie standardmäßig eingestellt durch Leerstellen.

karyotype = /var/www/circos/blog/knoten.txt

Bindet die Datei mit den Chromosomen ein.

<colors>

green = 0,255,0

red = 255,0,0

</colors>

Hier werden benötigte Farben definiert (in RGB).

<plots>
<plot>
min = 0
max = 12
color = black
file = /var/www/circos/blog/diagram.txt
thickness = 2
fill_under = yes
r0 = 0.87r
show = yes
r1 = 0.97r
fill_color = blue
type = histogram
extend_bin = no
<backgrounds>
<background>
color = vlgrey
</background>
</backgrounds>
<axes>
color = black_a4
thickness = 1
<axis>
spacing = 0.25r
</axis>
</axes>
</plot>
</plots>

In diesem Abschnitt werden spezifische Eigenschaften des Balkendiagramm eingestellt. Eine Auflistung von diesen Parameter findet ihr in den Circos Tutorials.

Die Ausgabe von Circos sieht dann so aus:

Und nachdem wir den dummy Teil weggeschnitten haben, bleibt noch übrig:

Gerade wenn man darüber nachdenkt, dass man diese Diagramme ja nun mit allen weiteren Möglichkeiten von Circos kombinieren kann (links, etc) ist dies doch schon sehr flexibel und mächtig. Alle benötigten Konfigurationsdateien könnt ihr hier runterladen.

In der Theorie ist es natürlich einfach für jede öffentliche Methode einen oder mehrere Testfälle zu erzeugen, um dann mit Hilfe von JUnit die gesamte Anwendung komplett automatisiert durchtesten zu können. Nun wird eigentlich mein Back-end durch ein zwischengeschaltetes Java Servlet aufgerufen, welches zum Beispiel nur sehr schlecht mit JUnit testbar ist. Das liegt daran, dass es nur in einer relativ langen Methode die Parameter einließ, die über die REST Schnittstelle mitgegeben worden sind um dann die entsprechende Server Methode aufzurufen. Es gibt zwar Möglichkeiten um Servlets mit JUnit zu testen, aber bisher konnte ich damit noch keine zufriedenstellenden Ergebnis erzielen. Insbesondere da ich nichts nur Strings, sondern teilweise auch Bilder zurückgebe. Wie in dem verlinkten Blogeintrag aber deutlich wird, ist es möglich HTTP Anfragen zu simulieren:


HttpClient client = new HttpClient();
PostMethod post = new PostMethod(url);
post.setQueryString(queryString);
client.executeMethod(post);
result = post.getResponseBodyAsString();
post.releaseConnection();


Dies ist auf jeden Fall schon mal ein wichtiger Anfang, löst aber, wie bereits erwähnt, nicht alle Probleme mit JUnit und meinem Servlet.Nun lassen sich zum Glück diese Teile des zwischengeschalteten Servlet einigermaßen leicht „von Hand“ testen, da ich nur etwa Zehn Parameter habe; aber eine optimalen Lösung ist das leider (noch) nicht.

Ansonsten bestehen große Teile des Back-ends aus privaten Methoden, die ich auch nicht direkt testen kann (da ich eigentlich nicht auf eingebettete Test-Klassen zurückgreifen möchte). Allerdings kann man wohl davon ausgehen, dass wenn ich korrekte Testergebnisse auf der öffentlichen Schnittstelle erziele, dass dann auch die privaten Methoden korrekt funktioniert haben, da diese von den öffentlichen aufgerufen worden sind.

Nun möchte ich im Folgenden noch einmal ganz kurz beschreiben wie so ein JUnit-Test überhaupt aufgebaut ist. Als erstes sollte man die JUnit.jar zu seinem Java buildpath hinzufügen, danach kann man eine Test Klasse erzeugen, welche die einzelnen Tests enthält. Das Ganze kann dann zum Beispiel so aussehen:


public class Tests {
@Test public void testGenerateCircos() throws RemoteException{
Server serv = new Server();
String result = serv.getCircosPath(Settings.APACHE_PATH + "data/e77b1839e8f031e3b6ead6dfe067757d948269d77a2f50f6ff2fcb6858d6ef0e.gexf", "cc", 10);
String expected = "circos/gfx/1af0b2e56edd8bd30effc4ea8eeca098b3e7c96791d054bb4435d30f064584bf_cc_10.png";
assertTrue(expected.equals(result));
}
}


Nun kann man also in dieser Testklasse beliebig viele automatisierte Testfälle ablegen und später mit dieser Klasse die Tests ausführen. Die Tests geben danach Rückmeldung über die erfolgreichen und fehlgeschlagenen Testfälle. Abgesehen von den oben angesprochenen Ausnahmen, funktioniert dieses Verfahren auch sehr gut und ist unglaublich hilfreich :)

"paths":
        {
            "type": "array",
            "description": "This array joins edges to paths.",
            "required": true,
            "items":
            {
                "type": "object",
                "properties":
                {
                    "id":
                    {
                        "type": "string",
                        "required": true,
                        "description": "A unique ID for this path."
                    },
                    "edges":
                    {
                        "type": "array",
                        "description": "This array holds all the edges (specifically references to the IDs of the edges) belonging to this path.",
                        "additionalItems": false,
                        "items": { "$ref": "edgeType" }
                    }
                }
            }
        }

Hier wird ein Pfad beschrieben, der aus mehreren Kanten ("edges") besteht – die Beschreibung einer einzelnen Kante wird hier per Verweis eingebunden. Weiter oben in der Datei, hier nicht sichtbar, steht dann die Definition von "edgeType". Dieses Verfahren nennt man dann JSON Referencing – und hier fangen leider ein paar kleine Schwiereigkeiten an. Denn: Erstens, ist JSON Schema bis jetzt nur ein IETF Draft und es gibt genau einen vernünftigen Validator, der JSON Schema inkl. Referencing beherrscht. Leider löst dieser die Referenzen auch dann wirklich nur innerhalb von Schemata auf, benutzt man Verweise innerhalb eines JSON (Instanz-)dokumentes, kann man erstmal lange nach einem JSON Parser suchen, der JSON Referencing beherrscht. Glücklicherweise gibt es einen solchen aber.

Obwohl ich so meine Schwierigkeiten mittlerweile in den Griff kriegen konnte, verbleibt doch so etwas wie ein übler Nachgeschmack. JSON mag ein einfaches Datenformat sein, das für viele Zwecke klar XML vorzuziehen ist. (Um mal die offensichtlichste Alternative zu nennen.) Kommt man jedoch in den Bereich Validierung, bleibt es nicht aus, das man sich fast nach XML Schema sehnt. Mittlerweile wurde auch eine leistungsfähige XML-Bibliothek nach JavaScript portiert.

Das Problem scheint mir in der Philosophie von JSON zu liegen. JSON war schon immer als einfaches Datenformat geplant gewesen und die Anforderung, aufwändige Gültigkeitsprüfungen durchzuführen war hier nicht vorgesehen. Bedenkt man die geringe Auswahl an JSON Referencing-fähigen Parsern und den Fakt, dass am IETF Draft zu JSON Schema seit fast 2 Jahren keine Erweiterungen oder Veränderungen vorgenommen wurden, hat man das Gefühl, dass JSON Schema eine “Nische” bleibt.

Ein weiteres Problem ist natürlich dass manche API im Internet nur als JSON oder nur als XML zu haben ist. Wie hat schon ein anderer schlauer Mensch gesagt: “Das gute an Standards ist, dass es so viele davon gibt.

Mir hat sich recht schnell gezeigt, dass das Erstellen bestimmter Diagramme nicht so einfach ist, sobald man von den Beispielen ein wenig abrückt. Eine wichtige Voraussetzung ist eine aktuelle Version von TeX Live (unter Debian in meinem Fall). Die kurzzeitige Arbeit an einem aktuellen Ubuntu-System mit installiertem TeX Live 2009 (aktuelle Version unter Ubuntu) hat mich zwischenzeitlich einige Nerven gekostet, da sich Darstellung und Syntax in einigen wenigen Punkten unterscheiden. Außerdem ist die Version im Latex-Dokument zwecks Abwärskompatibilität anzugeben, damit die Darstellung auch bei neueren Versionen noch passt. Der Standard ist allerdings nicht die neuste Version, so dass diese explizit angegeben werden muss. Hier gibt es gravierende Unterschiede wie ich beim Vergleich zwischen TeX Live 2009 und 2012 feststellen musste.

Der Grund, Graphen mit pgfplots zu erstellen ist zum einen die Einheitlichkeit und zum anderen die direkte Integration. Außerdem können Diagramme mit der Änderung weniger Parameter in ihrer Darstellung schnell angepasst werden. Das Diagramm, was ich erstellt habe, besteht lediglich aus zwei Kurven, die das Verhältnis zwischen Last und Kapazität zeigen. Einiges habe ich aus der Dokumentation erfahren, anderes im Internet gefunden. Meine begrenzten, aber bislang ausreichenden Kenntnisse in Latex haben mich hier nicht sehr weit gebracht. Die meiste Zeit habe ich damit verbracht, herauszufinden, welche Konstukte es gibt und welche zielführend sind.

Das folgende Beispieldiagramm hätte ich mit einem Grafikprogramm in einem Bruchteil der Zeit erstellen können. Die Darstellung von Werten aus Lasttests würde allerdings mit einem Grafikprogramm schwierig, mit pgfplots ist es hingegen ein Kinderspiel. Das Diagramm in der Abbildung ist ziemlich einfach gehalten und zeigt das Verhältnis zwischen bereitgestellten Ressourcen und der Last die erzeugt wird. Mit Underprovisioning gekennzeichnet sind die Teile, in der die Last größer ist als die bereitgestellten Ressourcen. Das kann dann zum Beispiel einen Ausfall oder eine Verlangsamung des Systems zur Folge haben. Als Pendant hierzu habe ich Diagramme erstellt, die eine dynamische Bereitstellung von Resourcen zeigen, um möglichst wenig Overprovisioning und gar kein Underprovisioning zu erhalten.

Diagramm zu Over- und Underprovisioning

Hier der Latex-Code:

\begin{tikzpicture}
 \pgfdeclarepatternformonly{north east lines wide}
  {\pgfqpoint{-1pt}{-1pt}}
  {\pgfqpoint{10pt}{10pt}}
  {\pgfqpoint{9pt}{9pt}}
  {
   \pgfsetlinewidth{1.4pt}
   \pgfpathmoveto{\pgfqpoint{0pt}{0pt}}
   \pgfpathlineto{\pgfqpoint{9.1pt}{9.1pt}}
   \pgfusepath{stroke}
  }

 \pgfdeclarepatternformonly{north west lines wide}
  {\pgfqpoint{-1pt}{-1pt}}
  {\pgfqpoint{10pt}{10pt}}
  {\pgfqpoint{9pt}{9pt}}
  {
   \pgfsetlinewidth{1.4pt}
   \pgfpathmoveto{\pgfqpoint{0pt}{9.1pt}}
   \pgfpathlineto{\pgfqpoint{9.1pt}{0pt}}
   \pgfusepath{stroke}
  }

 \begin{axis}[
  legend style={
   at={(0.97,0.97)},
   anchor=north east,
   },
  area legend,
  ticks=none,
  smooth,
  xlabel={Zeit},
  ylabel={Resourcen / Auslastung},
  stack plots=y,
  area style,
  enlarge x limits=false,
  ]

  \draw[-,very thick](axis cs:1, 4.5)--(axis cs:2, 4.5)node[right]{\footnotesize{Underprovisioning}};
  \draw[-,very thick](axis cs:5,3.7)--(axis cs: 3,4.4);
  \draw[-,very thick](axis cs:2.7,3.3)--(axis cs: 2.7,3.7)node[above]{\footnotesize{Overprovisioning}};

  \addplot+[
   draw=blue,
   pattern=north east lines wide,
   pattern color=red!60!white
   ]
   coordinates
   {(0,2) (1,5) (2,3) (3,3) (4,2) (5,4) (6,2) (7,3)}
   \closedcycle;

  \addplot[mark=none,
   draw=red,
   pattern=north west lines wide,
   stack plots=false,
   area legend,
   pattern color=green!60!white
   ]
   coordinates
   {(0,3.5) (1,3.5) (2,3.5) (3,3.5) (4,3.5) (5,3.5) (6,3.5) (7,3.5)}
   \closedcycle;
  \legend{
   Auslastung,
   Kapazität,
   }
 \end{axis}
\end{tikzpicture}

Hifreich:

• StackExchange
• pgfplots auf sourceforge.net

Hin und wieder findet man ja mal sehr gut aussehende Infografiken die den Betrachter irgendwie direkt in ihren Bann ziehen (weil sie in ihrem Design aus der Menge heraus stechen uns etwas neues bieten; einen Anreiz, dass man diese Grafik sehen möchte) und man einfach unbedingt wissen möchte was man in dieser Grafik an Information findet. Spontan würde mir dabei zum Beispiel diese beiden Grafiken einfallen:

 

Colors of the web und die 2010 Social Networking Map.

Natürlich gehört zum Erzeugen von solchen Grafiken eigentlich relativ viel Talent, Erfahrung in diesem Bereich und Zeit. Häufig ist es nun allerdings meiner Erfahrung nach so, dass gerade bei Wissenschaftlern die letzten beiden Aspekte ein wenig zu kurz kommen. Die Wissenschaftler haben in der Regel keine Zeit um sich großartig mit dem Design von ihren Grafiken zu beschäftigen und daraus folgt, dass sie auch nicht viel Erfahrung darin haben solche Infografiken zu erzeugen. Dadurch kostet das Erzeugen von schönen herausstechenden Infografiken noch mehr Zeit und die Menge von ebensolchen wird noch kleiner. Es entstehen die typischen mehr oder weniger langweiligen, einfachen Diagramme die vermutlich jeder von uns schon 1000 mal gesehen hat und von denen ich deswegen hier keine weiteren Beispiele zeigen möchte ;-)

Darüber hinaus werden häufig Statistiken einfach in Form Tabellen dargelegt. Das ist wichtig und richtig, da eine Tabelle keinerlei Verfälschungen der Daten oder irgendwelche Ungenauigkeiten erzeugt. Das Problem ist allerdings meiner Meinung nach, dass Statistiken auch für die “breite Masse” sehr interessant sein könnten; hier sage ich deswegen könnten, da sich vermutlich die wenigsten nach 12 stündigen Arbeitstagen abends auf ihr Sofa setzen um dann noch eine Statistik aus einer Tabelle mit 35 Zeilen und 27 Spalten auf irgendwelche Zusammenhänge zu durchforsten.

Und das kann ihnen niemand übel nehmen.

Aber wie ich festgestellt habe, bietet Circos die Möglichkeit sehr einfach automatisch aus Graphen und/oder Tabellen sehr coole (bildlich ansprechende) Diagramme zu erzeugen und dabei muss der Benutzer definitiv kein Grafiker oder Designer sein (Anmerkung: Grafiken die „von Hand“ durch solche Personengruppen erzeugt werden, sind natürlich in der Regel noch etwas wertvoller, da sie einfach individueller und durchdachter sind). Man kann, grob ausgedrückt, die Daten im Prinzip direkt als eine, auf eine bestimmte Art und Weise sortierte, csv Datei in Circos werfen und der Rest wird von der Anwendung erledigt.

Aber kommen wir mal zu einem Beispiel:

Ich habe hier eine Circos Visualisierung von einem co-authorship Graphen, der die höchsten 35 co-authorships im Zeitraum von 2006 – 2012 zeigt. Zudem bildet der orange Ring die ‘degree centrality’ ab (als relativen Wert) und das blaue Histogramm zeigt die Anzahl von co-authorships pro Jahr (als absoluten Wert). D.h., um noch mal auf mein Argument mit der Statistik zurückzukommen, reden wir an dieser Stelle über eine Datenmatrix mit 35 × 35 Einträgen (für die Verbindungen) plus Tabellen, die die anderen Ringe abbilden. Wenn man sich das vor Augen führt, finde ich es schon ziemlich beeindruckend, wie viele Informationen man in diese eine Grafik einfügen kann; obwohl sie einigermaßen übersichtlich bleibt (vielleicht mit etwas Übung, wie die Grafik zu lesen ist).

Eine solche Grafik ließe sich auch publizieren und es bestünde zumindest die Chance, dass Leute außerhalb von rein wissenschaftlichen Kreisen sich diese einmal ansehen. Bei der Datenmatrix und den Tabellen würde ich diese Chance leider nicht sehen. So gesehen ist es sicherlich kein Zufall, dass die Wired im vorletzten Jahr Circos nutzte um eine große Grafik zu erzeugen, die die Beziehungen aller Charaktere aus Lost zueinander zeigte.

Um den Text also noch einmal in einem Satz zusammenzufassen:

Passende und intuitive Datenvisualisierung ist meiner Meinung nach wichtig und Circos hilft einem massiv bei der Erzeugung von eben solchen Diagrammen.

Ich teste meinen Algorithmus mit einem Satz von Testdaten, der 230.000 verschiedene Sätze und 124.000 verschiedene Worte umfasst. Der Algorithmus ist eine Implementierung von Fuzzysets, die die Ähnlichkeit zwischen Sätzen berechnen. Der erste Schritt ist für jeden Satz der gegen den Hintergrundkorpus geprüft werden soll einen Liste an Zielsätze zu finden, die eine gewisse Ähnlichkeit zum Quellsatz haben, um nicht den Quellsatz gegen alle Sätze des Korpus prüfen zu müssen. Hierfür baue ich eine Lookuptabelle auf, in der alle Worte auf die Sätze abgebildet sind die sie enthalten, also ein inverser Index. Hiermit können alle Sätze ermittelt werden, die z.B. zumindest ein Wort mit dem Quellsatz gemein haben. Der nächste Schritt umfasst das Holen der Zielsätze und die Berechnung der Ähnlichkeiten zum Quellsatz. Hierfür habe ich eine Tabelle die die Termfrequenzen für alle Sätze enthält. Die Sätze haben als ID einen MD5Hash über die alphabetisch geordnete Menge der Worte des Satzes (“Das ist ein Haus und ein Auto” = MD5Hash (autodaseineinhausistund)). Dies garantiert eindeutige Hashes, da die Anordnung der Worte für Fuzzyset unwichtig ist. Als letzter Schritt sollen die Ergebnisse weggeschrieben werden. Die drei Version des Algroithmuses unterscheiden sich hauptsächlich in der Anzahl und der Funktion der MapReduce Jobs. Waren es in der erst noch drei Jobs, so waren es in der zweiten 9 und in der dritten vier. Die Ausführungszeiten und die Größe der Zwischenergebnisse unterscheiden sich in den drei Versionen drastisch, so variierte die Ausführungszeit auf meinem Testsatz zwischen 2 Stunden in der dritten Version und >16Stunden in der zweiten. Auch die Größe der Zwischenergebnisse variierte drastisch. In der zweiten Version ca. 6Tb und in der dritten <3Gb.

Ein paar Kleinigkeiten die ich schmerzlich gelernt habe stehen unter den Motto “Datenstrukturen, Datenstrukturen, Datenstrukturen und an die Algorithmen denken!”. Einige Beispiele werden im Folgenden näher erläutert:

Datenstrukturen 1
Was der Begriff BigData bedeutet, habe ich festgestellt als ich darüber nachdachte, ob ich ein Integer sparen sollte oder ob ich mir den Luxus gönne. :-) (Ich fühlte mich in die Zeit versetzt als man beim 386er jedes Byte im untern Speicherbereich gespart hat um ein bestimmtes Spiel zu starten können). Hierbei ging es um die Frage, wie ich die md5 Hashes meiner Satzids speichern sollte. Hadoop stellt ein Objekt zur Speicherung von dynamisch langen Bytearrays zur Verfügung (BytesWritable). Nach meiner ersten Implementierung der Kandidatenauswahl hatte ich 3Mrd Vergleiche von Satzpaaren, was sich in 6Mrd. Ids niederschlägt. Das ByteWirtable speichert einen Integerwert für die Länge des Bytearray und das Array an sich. Da die Länge bei md5 aber fix mit 16Byte ist, sind die 4Byte für das Längenint überflüssig. Ein anderes Objekt von Hadoop, MD5HashWritable, speichert nur ein Bytearray, mit der fixen Größe von 16Byte. Das macht 25% Overhead (24Gb) bei 96GB für die ids. Es lohnt sich über die Datenstrukturen nachzudenken, denn ein gespartes Int kann mal schnell drei DVDs ausmachen.

Datenstrukturen 2
Ein weiteres Beispiel, warum es sinnvoll ist, eigene spezielle Datenstrukturen zu verwenden, anstatt von generischen, zeigt sich am Objekt MapWritable von Hadoop. Es ist zwar praktisch ein Objekt zu haben in dem die verschiedensten Writables gespeichert werden können, aber im Fall von sehr vielen kleinen Elementen auch Nachteile mit sich bringen kann. Das MapWritable speichert für jedes Key und Value jedes Elements den Datentyp als fully qualified String. Wenn beispielsweise nur IntWritable’s gespeichert werden sollen, ergibt das einen Overhead von 800% (“org.apache.hadoop.io.IntWritable” = min. 32Byte gegen Integer=4byte). Auch dies kann durch eine spezialisierte Datenstruktur vermieden werden und vermindert die Datenmenge extrem.

Datenstruktutren 3
Die Laufzeit des  Sort and Shuffle Prozess, zwischen Map und Reduce, wird maßgeblich durch die Menge der zu sortierenden Daten dominiert. In einer Version habe ich in der Map Phase die Kandidaten zu einem Quellsatz gesucht und dann die ids von Quell und Zielsatz zu einem 32Byte langen Bytearray kombiniert. Dieses Bytearray habe ich dann als Key zusammen mit einem leeren Value an die Reduce Phase gesendet. Das hat den Vorteil, dass eine totale Ordnung entstand. Der Nachteil bestand darin, dass viel Zeit zum Sortieren benötigt wurde.   Des Weiteren wurde die totale Ordnung auch nicht weiter benötigt. Hierbei werden dann 6Mrd. Elemente sortiert und geshuffelt, dann wird 6Mrd. mal die reduce Methode aufgerufen mit leeren iterable Values. Im Vergleich dazu, wenn nur die Quellid als key und die Zielids als Value zur Reduce Phase übertragen wird, fallen nur ca. 200.000 zu sortierende Elemente an und die reduce Methode wird auch nur 200.000 mal aufgerufen mit gefüllten iterable Values. Das brachte eine enorme Zeitersparnis, die mehrere Stunden umfasste.

Algrithmen
Bei meinem Ansatz hat sich herausgestellt, dass der Random Access auf die Lookupdaten in HBase die meiste Zeit beanspruchte. Hier gilt es noch eine bessere Lösung zu finden. Ich denke hier könnte PIG hilfreich sein. Auch zu große Zwischenergebnisse (Mehrere TByte) oder zu viel Sortierarbeit waren ein großes Hindernis. Schlussendlich kann ich sagen, dass ich aus den vielen Wochen der Optimierungsarbeit viel über die Funktionsweise von MapReduce gelernt habe und für den nächsten Algorithmus eine komplett andere Herangehensweise benutzen würde.

PS.: BigData stimmt bei diesem Artikel auch für die Überschrift.:-)

Allerdings können wir diese ganzen optionalen Informationen erst einmal komplett entfernen und uns den Kern des Bildes näher ansehen:

An diesen Punkt wird das Ganze schon ein wenig klarer, denn hier sind nur noch außen die Chromosomen aufgelistet (Circos ist eigentlich für biologische Visualisierung von Genomen gedacht, aus diesem Grund hat man in den Konfigurationsdateien auch eine entsprechende Terminologie), deren Größe einen Wert des Chromosoms darstellt. Zwischen diesen Chromosomen können wir jetzt Verbindungen ziehen; und an dieser Stelle bemerkt man bereits die doch ziemlich deutliche Ähnlichkeit zu den uns bekannten Graphen.

Somit habe ich mittels des Gephi Toolkits eine Klasse programmiert, die die GEXF Datei einliest und sich die Knoten und Kanten aus dem Graphen ausliest. Die Idee ist nun, dass die Knoten in einem Graphen den Chromosomen in der entsprechenden Circosvisualisierung entsprechen und die Kanten innerhalb des Graphen die Verbindungen zwischen den Chromosomen darstellen. Somit ist hier sehr einfach eine direkte Übertragung von Graph zu Circos möglich.

Zum Beispiel werden die Knoten in einer entsprechenden Datei wie folgt definiert:
chr – hs1 1 0 22

Damit meint man: „Dies ist ein Chromosom mit der id „hs1“, dem Label „1“ und der Länge 22. Einfach, oder ? In Bildern ausgedrückt entsteht auf diese Art und Weise automatisch aus folgendem Graphen

diese Visualisierung:

Zudem kann man die Kantenstärken direkt wieder verwenden, da auch in Circos die Verbindung unterschiedlich breit sein können. Netterweise kann man so sehr einfach Attribute der Knoten mit auftragen, indem man zum Beispiel die Chromosomen unterschiedlich groß darstellt (in meinem Fall werden bei den Chromosomen zusätzlich verschiedene SNA Metriken bestimmt und in die Größe der Chromosomen eingerechnet).

Allerdings habe ich in diesem Bereich noch eine Menge Arbeit vor mir, da ich die Visualisierungen noch intuitiver und aussagekräftiger werden lassen möchte … :)

ich bin Rolf und werde in den nächsten Monaten hier schreiben, womit ich mich bei meiner Abschlussarbeit beschäftige. Meine Masterarbeit trägt den Titel Elastic Information Structuring for Multiple Applications – Design und Entwicklung einer skalierbaren Applikationsplattform durch Bereitstellung einer Datenzugriffsschicht. Das sieht dann folgendermaßen aus.

ELISMA-Architekturdiagramm

Da das Architekturdiagramm und der Titel die Arbeit schon recht gut beschreiben, möchte ich auf meine Motivation eingehen, eine derartige Applikationsplattform zu erstellen. Details zur Konzeption folgen in weiteren Beiträgen.

Zu Beginn der Suche nach einem Thema für meine Abschlussarbeit, war eine Andriod- oder Webapplikation mein Ziel. Schnell stellte sich für mich allerdings heraus, dass zur Persistierung von Daten im Netz beziehungsweise “der Cloud” keine geeigneten Lösungen exisiteren, die meinen Anforderungen gerecht werden. Es gibt zwar Datenbanksysteme, wie CouchDB, die mit einer REST-Schnittstelle einfach zu handhaben sind, aber einen komplexen Aufbau einer Anwendung mit differenzierten Berechtigungsmechanismen genauso wenig erlaubt, wie andere Datenbanksysteme. Berechtigungsmechanismen werden in der Regel in der Applikationslogik oder einer Middleware behandelt. Das eigentliche Problem sehe ich darin, dass bei der Erstellung einer Applikation eine sichere Datenhaltung entworfen und implementiert werden muss und dadurch ein großer Teil der Zeit hierfür aufgewendet wird, anstatt für die Applikation an sich.

Der zweite Punkt ist, dass ein Datenmodell meist nur für eine Applikation erstellt wird. Dieses Vorgehen ist zwar effizient, um schnell ans Ziel zu gelangen, aber es ist auch kurzsichtig, wenn ein Datenmodell nur ein bestimmtes Szenario abdeckt und damit an Flexibilität verliert. Eine Erweiterung der Applikation oder die Integrierung in andere wird dadurch eher schwieriger. Die Folge sind viele verschiedene Applikationen, die unabhängig voneinander sind. Eine solche lose Kopplung von Applikationen ist ein Anlass gewesen, eine Applikationsplattform erstellen zu wollen, auf der verschiedene Applikationen auf demselben Datenmodell operieren können. Das ermöglicht die Verknüpfung der Daten untereinander und erfordert kein komplett seperates und unabhängiges Datenmodell für jede Applikation.

Den dritten Punkt nenne ich Expandierung. Getestet werden bei Anwendungen in der Regel funktionale Anforderungen. Was aber ist mit nicht-funktionalen Anforderungen wie der Skalierbarkeit? Anwendungslogik und Datenmodell können funktional gesehen gut sein, aber sie sind ungeeignet, wenn 10 000 Nutzer nicht genau so gut bedient werden können, wie 10 Nutzer. Einige Systeme werben zwar damit, auch bei “extrem vielen” Nutzern noch uneingeschränkt operieren zu können, doch Zahlen hierzu werden nicht angegeben. Zumal haben Nutzerzahlen von Systemen im Einsatz eine beschränkte Aussagekraft, da es bei 10 000 registrierten Nutzern nur eine Handvoll aktiver Nutzer geben kann.

Die Applikationsplattform ELISMA soll die Entwicklung von Applikationen unter anderem im Bereich Wissensmanagement und E-Learning vereinfachen und eine nachhaltige Perspektive bezüglich der Expandierung und Erweiterung bieten. Einen Schlüsselfaktor sehe ich hierzu im Rechtemanagement, aber dazu mehr in einem anderen Beitrag.

Ich schreibe eine Abschlussarbeit zum Thema “Author disambiguation”. In dieser Arbeit geht es darum, aus einer anhand von Metainformationen (in meinem konkreten Fall BibTeX) gegebenen Menge von Dokumenten mit Autorenangaben herauszufiltern, welche genannten Autoren identische bzw. verschiedene Personen sind.

Nachdem ich anfangs eine Menge einschlägiger Artikel gelesen habe, bei denen fast überall externe Referenzdatenbanken (CiteSeer, Google, etc.) zur Entscheidungsfindung eingesetzt wurden – dies bei meiner Arbeit aber von vornherein ausdrücklich ausgeschlossen war – habe ich mich an ein paar – zugegebenermaßen recht naiven – eigenen Ansätzen versucht, die leider schon zu Beginn der Konzeptionsphase scheiterten.

Das in [1] beschriebene Framework motivierte mich dann jedoch neu, so dass ich mich daran machte, eine derartige Implementierung im Rahmen von Hadoop und HBase vorzunehmen und nun erste Ergebnisse präsentieren kann.

Meine derzeitige Testmenge umfasst knapp 25.000 Dokumente mit rund 80.000 Autorennamen. Diese partitioniere ich gemäß Framework in Cluster von Autoren mit (nach der Normalisierung) gleichen Nachnamen und erhalte so rund 23.000 Cluster verschiedenster Größe.  Auf jedem dieser Cluster kann man nun ein Klassifizierungsverfahren einsetzen, das die enthaltenen Autoren nach einem definieriten Ähnlichkeitsmodell gruppiert und so ein plausibles Ergebnis liefert.

Aufgrund der Datenmenge ist eine manuelle Überprüfung des Ergebnisses offensichtlich nicht möglich. Leider fehlt mir auch noch eine Referenzdatenmenge, mit der ich die Korrektheit des Algorithmus überprüfen kann, weshalb ich derzeit die Struktur des Codes etwas verbessere, Laufzeiten optimiere und ein Beurteilungsschema für die Qualität der Berechnung erarbeite.

Das Laufzeitverhalten ist trotz fehlender Optimierung recht beeindruckend für die ungeheure Datenmenge: Mein lokaler Rechner (Dual-Core, 1,8 GHz) benötigt rund 5 Minuten, um die 80.000 Autorennamen zu disambiguieren.

[1] L. Bolikowski, P. J. Dendek. “Towards a flexible author name disambiguation framework”, 2011.

{
    "nodes":
    [
        { "id": "author2", "label": "Author 2", "class": "author" },
        { "id": "paperA", "label": "Paper A", "class": "paper"  },
        { "id": "paperC", "label": "Paper C", "class": "paper"  },
        { "id": "conferenceA", "label": "Conf A", "class": "conference" }
    ],
    "edges":
    [
        { "id": "edge1", "from": { "$ref": "author2" },
          "to": { "$ref": "paperA" }, "class": "authorship" },
        { "id": "edge3", "from": { "$ref": "paperA" },
          "to": { "$ref": "paperC" }, "class": "citation" },
        { "id": "edge5", "from": { "$ref": "paperC" },
          "to": { "$ref": "conferenceA" }, "class": "presentation" }
    ],
    "paths":
    [
        { "id": "path1", "edges": [ { "$ref": "edge1" }, { "$ref": "edge3" },
                                    { "$ref": "edge5" } ] }
    ]
}

die folgende Darstellung zu erzeugen.

Pfad-Darstellung in ADORE mit “bare” Skin.

Hierbei kommt der “bare” Skin zum Einsatz, ein Basis-CSS-Stylesheet, dass allein die Aufgabe hat, die Knoten und Kanten in neutraler Form darzustellen, also ohne anwendungsspezifische Formatierung. Nun kann man ein Stylesheet mit anwendungsspezifischen Formatierungen laden – hier wäre das ein Stylesheet, wie das folgende (gekürzt), das Autoren als Figuren, Papiere eben als Schriftstücke und Konferenzen durch eine Plakatwand verdeutlicht.

/* Node styles */

.author {
    background-image: url('skins/academic/img/author-node.png');
}
[...]

/* Edge styles */

._jsPlumb_connector.authorship path {
    stroke: black;
}

._jsPlumb_connector.citation path {
    stroke: green;
    stroke-dasharray: 5,5;
}

._jsPlumb_connector.presentation path {
    stroke: red;
    stroke-width: 1;
}

/* Overlay styles */

._jsPlumb_overlay.authorship {
    background-image: url('skins/academic/img/authorship-edge.png');
    background-size: 30px 30px;
    background-position: center;
    background-repeat: no-repeat;
    color: transparent;
}

Die Darstellung ändert sich entsprechend:

Pfad-Darstellung in ADORE mit “academic” Skin.

Diese Darstellung ist in skalietrer Form sicherlich auch als Widget in einer anderen Webseite nützlich. Der offensichlichste Anwedungszweck sind hier natürlich alle Formen von Social Networking Sites und artverwandtes.

Die nächsten Schritte werden darin bestehen, den theoretischen Teil der Arbeit, also meine konzeptionellen Überlegungen weiterzuführen und niederzuschreiben.

Zur Erinnerung: Es geht in meinem Projekt insgesamt darum, dass ich große Forschungsnetzwerke visualisieren können möchte. Insbesondere soll dies durch eine einfache Menüführung für den Benutzer so gestaltet sein, dass er in einen Auswahldialog die Konferenz und die gewünschten Jahre wählen kann und ab diesem Punkt die Webanwendung alles weitere übernimmt (das bedeutet: holen der Daten aus der MySQL Datenbank von KnowAAN und automatische Generierung der dazugehörigen GEXF Datei). Danach soll diese GEXF Datei automatisch durch eine Javascript Bibliothek namens Sigma.js angezeigt werden. Zudem sollen verschiedene Graphmetriken zu dem aktuell angezeigten Forschungsnetzwerk ausgerechnet werden (wahrscheinlich wird es hier noch einige Anpassungen geben, da es sehr gut wäre wenn auch wirklich nur die Metriken zu dem aktuellen Graphen -in diesem Zeitraum- angezeigt werden, denn es wird ja möglich sein die Zeiträume für die aktuelle Anzeige zu verändern und sich somit nur bestimmte Jahre anzeigen zu lassen). Alles in allem ist es in dieser Situation ein wenig ungünstig, wenn man nur die Metriken für den Gesamtgraphen über alle Jahre hinweg anzeigen kann.

Insgesamt funktioniert dies auch schon einigermaßen zuverlässig. Technisch ist die Berechnung der Metriken so gelöst, dass diese von einem Java-Server berechnet und dann per PHP über eine Rest URL abgefragt werden, um diese dem anfragenden Client anzeigen zu können. Allerdings bin ich hier auf das Problem gestoßen, dass es verschiedene Definitionen der so genannten ,closeness centrality‘ gibt. Um darauf eingehen zu können, möchte ich knapp beschreiben was diese eigentlich aussagt und danach kurz auf das Problem eingehen. Die ,closeness centrality‘ beschreibt mathematisch die Position eines einzelnen Knoten in dem gesamten Graphen. Die Idee dahinter ist, dass ein Knoten der sehr zentral in dem Netzwerk liegt, wohl auch in der Summe eine geringe Distanz zu allen anderen Knoten hat. Dafür summiert man für den einzelnen Knoten die Distanzen auf und teilt diesen Wert danach durch die Anzahl der Gesamtknoten. Ein kleines Problem bei dieser Definition ist, dass der Wert „schlechter“ wird, je größer er ist. Dies ist wiederum bei anderen Metriken nicht unbedingt so, wie zum Beispiel bei der ,degree centrality‘ für die ein „großer Wert“ gut ist; denn das bedeutet in diesem Fall, dass ein Knoten einen hohen Grad hat und damit viele Verbindungen in dem Graphen zu anderen Knoten besitzt. Natürlich gilt insbesondere in einem sozialen Netzwerk, dass eine hohe Anzahl an Verbindungskanten gut ist, da die Person dann viele Beziehungen zu anderen Personen in dem Netzwerk besitzt. Daher gibt es auch noch andere Definition von der eben genannten ,closeness centrality‘, die etwa den Kehrwert des gerade beschriebenen Wertes benutzen. In diesem Fall passt auch wieder die Intuition ins mathematische Schema. Nun habe ich ja vorhin schon geschrieben, dass diese Sachen bereits relativ zuverlässig funktionieren (es sind noch keine Tests gelaufen, aber rein von meinem Gefühl her läuft es schon relativ stabil :)).

Als nächstes soll nun die Ausgabe mit Circos implementiert werden. Dadurch werden kreisförmigen Visualisierung möglich, die tatsächlich ein sehr hohes ,data to ink ratio‘ aufweisen können.

Das bedeutet, dass man auf sehr kleinem Raum (beziehungsweise für den Druck die namensgebende Tinte) sehr viele Informationen packen kann; trotzdem bleiben diese Visualisierung meist relativ lesbar. Insgesamt wird es nötig sein, dass mein Java-Server eine Circos Konfigurationsdatei erstellt und dann per Kommandozeile Circos mit dieser Datei als Parameter aufruft. Allerdings sind, bevor ich das vollständig umsetzen kann, noch ein paar Tests nötig, da Circos auch sehr komplexe und schwierig zu lesende Diagramme erzeugen kann und ich erst noch eine Konfiguration der Anwendung finden muss, in der einigermaßen intuitive Visualisierungen erzeugt werden. Dies ist allerdings nicht ganz leicht, da ich zum gegenwärtigen Zeitpunkt noch nicht weiß, welche Art überhaupt von den Betrachter als „intuitiv“ wahrgenommen wird. Abschließend möchte ich das „Problem“ kurz an einem Beispiel zeigen:

An diesem Beispiel kann man schön erkennen, dass man ohne eine wirklich ausführliche Beschreibung über die Art und Weise, wie diese dieses Diagramm zu lesen ist, wohl nicht mehr sonderlich viel erkennt…

[Anmerkung: Die beiden Bilder entstammen dem „Circos practical course“]

Vor dem Veröffentlichen des Plugins muss zuerst ein Benutzer angelegt werden. Dies geschieht mit dem Befehl npm adduser. Daraufhin werden Benutzername, E-Mailadresse und ein Passwort abgefragt und anschließend der Benutzer auf npmjs.com angelegt.

Das Veröffentlichen des Plugins ist genauso einfach: dazu wird im Plugin-Verzeichnis der folgende Befehl ausgeführt: npm publish. Anschließend kann jeder das Plugin mit npm init installieren.

Ich habe bis jetzt zwei nützliche Plugins für Etherpad Lite veröffentlicht:
LaTeX-Export und
Spracheingabe.

Meine Masterarbeit basiert auf Konzepten und Entwicklungstechniken des People Tagging und der visuellen Kommunikation, die Sabine Mers in ihrer Bachelorarbeit eingeführt und erläutert hat.

Im Rahmen meiner Masterarbeit werde ich eine serverbasierte Web-Applikation entwickeln, die Nachrichtenverteilung durch die graphische Darstellung einer beliebigen Organisationsstruktur (Organigramm) und graphische Abbildung von gebildeten Gruppen unterstützen soll. Das Organigramm soll dabei dynamisch angeordnet werden können, z.B. durch auf- und zuklappen. Die Nachrichtenempfänger sollen visuell gewählt werde, indem man die schon bereits geschriebene Nachricht per Drag&Drop auf die gewünschte Person bzw. Hierarchieebene des Organigramms zieht.

Abbildung 1. Verschicken einer Nachricht an die Ebene „Leitung von AGs“

Dies wird auch umgekehrt funktionieren, wenn man die gewünschte Ebene der visuellen Hierarchie bzw. einzelne Person in das Empfängerfeld der Nachricht per Drap&Drop schiebt.

Abbildung 2. Verschicken einer Nachricht an die Gruppe „Java“ und eine Person aus der Gruppe „Python“

Das People Tagging wird eingesetzt, um einzelne Personen bzw. Gruppen, an die eine Nachricht verschickt wird zu verschlagworten. Dadruch entsteht der sogenannte Kompetenzkatalog, der später einer schnellen Suche von richtigen Ansprechpartnern dienen soll. Allgemein dient dieses Prinzip der Wissenskommunikation [BA Sabine Mers].

Als weitere Unterstützung der Nachrichtenverteilung soll das Konzept „Folgen“ realisiert werden, das in Form einer Pinnwand auf der Profilseite jedes Benutzers erscheinen soll. Die Pinnwand soll alle Aktivitäten der verfolgten Personen bzw. Gruppen anzeigen: WER hat WEN mit welchem Tag versehen?

Technisch gesehen soll das System auf dem schon existierenden ActiveDirectory-Schema (Abbildung des Organigramms) basieren und dieses durch eine zusätzliche Datenbank erweitern, in der alle Tags, gebildete Gruppen und deren Relationen gespeichert werden. Clientseitige Oberflächen sollen hauptsächlich in JavaScript und im serverseitigen Django implementiert werden. Für die Visualisierung graphischer Oberflächen mit allen Effekten wird jQuery verwendet.

Die weiteren Mochups und Erläuterungen dazu stelle ich beim nächsten Bloggen online.

Ich habe hier eine Tabelle die relativ eng ist, trotzdem wollte  ich eine Beschreibung der Metrik haben um die Oberfläche ein wenig präziser zu gestalten und dem Besucher die Möglichkeit zu geben die Metriken leicht nachschlagen zu können. Nun war aber einfach nicht genug Platz da, um diese Beschreibung direkt daneben zu platzieren (Stichwort: Lokalität). Daraufhin habe ich mir die Möglichkeiten von Twitter Bootstrap noch einmal näher angesehen und bin auf sehr einfach zu implementierende tooltips und popovers gestoßen (ganz wie es in GMMW vorgeschlagen wird, wenn man sich in diesem Designkonflikt befindet :)).

Als erstes binden wir die zwei Bibliotheken (für tooltip und popover) ein. Achtung: Die popover Bibliothek benötigt die andere, auch wenn man keine tooltips sondern nur die popovers benutzen will, da sie diese nur erweitert. Danach können wir direkt mit dem Folgenden kleinen JavaScript Schnipsel unseren ,popover‘ darstellen:

$(function ()
{ $("#ccHover").popover({title: 'Closeness Centrality', content: "LOREM IPSUM."});
});

Ok ok, das kleine Stück JavaScript Code braucht noch JQuery, aber ich denke mal, dass ihr das eh eingebunden habt ;-)

Wie man sieht war das Ganze eine Sache von 2 min und man hat nun die Möglichkeit beliebige tooltips auf seiner Oberfläche zu nutzen, um diese insgesamt zu erweitern und doch übersichtlich zu bleiben.

In den nächsten 3–4 Wochen werde ich verstärkt am Projekt programmieren, denn bald soll schon ein erster Prototyp fertig sein, der auch schon für erste Evaluationen verwendet werden soll. Alles weitere natürlich hier auf dem Blog!

Stellen wir uns mal die alltägliche Situation vor, dass man morgens aufwacht und sich zu seinem Morgen-Kaffee überlegt, dass man doch gerne verschiedene Metriken der Scientometrie (wie zum Beispiel ,Co-Citation‘) der eingereichten Papiere von der mlearn Konferenz aus den Jahren 2004-2006 visualisieren möchte. Zudem möchte man diese Visualisierung danach auf seinem Blog zu veröffentlichen, um irgendetwas besonderes hervorzuheben.

Leider hat man nun das Problem, dass man diese Aufgabe wohl nicht bis zum Mittagessen erledigt hat, da zwar bereits eine Webplattform existiert, die die Papiere sammelt und auch teilweise einen Export zu Gephi (einer Anwendung für die Visualisierung von Graphen) bereitstellt, aber spätestens bei dem Teil mit dem Blog wird es im Moment schon  schwierig. Und gerade diese Lücke versuche ich zu füllen.

Technisch gesehen, soll der Benutzer über einen Auswahldialog wählen können, welche Konferenz er in welchem Zeitraum darstellen möchte und um welche Metrik es ihm gerade geht. Danach wird die dazugehörige GEXF Datei erstellt und dem Benutzer angezeigt.

Da zudem ein persistenter Link generiert wird, soll das Verteilen des Links möglichst einfach gemacht werden. Immerhin ist Forschung doch immer eine kooperative Aufgabe, oder ?

[Mit den Worten von Carl Sagan, „Science is a collaborative enterprise, spanning the generations“ :) ]

Wenn man allerdings keine Visualisierung von dem gesamten Graphen möchte, dann soll sich der Benutzer auch dafür entscheiden können die Top 10/20/… in einem kreisförmigen Diagramm darstellen zu lassen. An dieser Stelle wird auf Circos zurückgegriffen, welches Tabellen in eben solche kreisförmigen Darstellungen übersetzt.

Insgesamt wird in dem Projekt reichlich auf JavaScript gesetzt, welches durch ein Java-Servlet in einem Tomcat Webserver unterstützt wird. Ansonsten muss für ein paar kleinere serverseitige Scripte PHP bemüht werden. Die Visualisierung der eigentlichen Graphen wird dann durch eine JavaScript Bibliothek namens Sigma.js erledigt, welche die Sache aktuell aber wohl nur sehr rudimentär umsetzt. Ich bin da ehrlich gesagt relativ gespannt, was ich da alles „modifizieren“ muss, bis es wirklich alles passend anzeigt und der Sigma.js interne parser nicht gefühlt alle 20 Minuten stehen bleibt.

Insgesamt könnt ihr das Projekt auf Github verfolgen und natürlich halte ich euch auch auf dem Laufenden :)

Vor Kurzem habe ich ein Plugin für die Spracheingabe in Etherpad Lite veröffentlicht. Nach dem Installieren erscheint in der Button-Leiste ein weiterer Button, der bei Klick darauf die Spracherkennung startet. Doch wie funktioniert das eigentlich? Das will ich im Folgenden erläutern.

Zuerst einmal: Spracheingabe funktioniert derzeit nur in Google Chrome. Andere Browser werden bald sicherlich nachziehen.

Um einem Eingabefeld die Spracheingabe beizubringen, muss dem Eingabefeld nur das Attribut x-webkit-speech hinzugefügt werden. Daraufhin erscheint im Eingabefeld ein Mikrofon-Symbol, das nach einem Klick die Sprachaufzeichnung startet.

Das ganze funktioniert technisch genauso wie “Siri” auf einem iPhone: die Aufnahme wird an einen Google-Server gesendet und dort ausgewertet. Der erkannte Text erscheint daraufhin im Eingabefeld.

Das versteckte Eingabefeld

Das Problem ist nun: wie schafft man es, dass nach einem Klick auf einen “normalen” Button die Sprachaufnahme gestartet wird? Die Idee dazu habe ich bei wysihtml5 gefunden: Das Eingabefeld muss über dem eigentlichen Button so positioniert werden, dass das Mikrofon-Symbol genau über dem Button liegt. Anschließend wird das Eingabefeld mit opacity: 0; versteckt. Klicken wir also auf den Button für Spracheingabe, klicken wir eigentlich auf das Mikrofon im Eingabefeld.

Wird nun der gesprochene Text erkannt, erscheint er im versteckten Eingabefeld. Diesen liest mein Plugin dann aus, löscht ihn aus dem Eingabefeld und fügt ihn anschließend ins Pad ein.

Installiert werden kann das Plugin so: npm install ep_speechinput

Weiterführende Links:
ep_speechinput bei npm
ep_speechinput bei Github
Demo von Google
Speech Input API Specification

Meine Anwendung soll diese Funktion nun verallgemeinern – statt nur Freundschaften zwischen Personen darzustellen, möchte ich einen Ansatz schaffen, um mit möglichst wenig Aufwand Verbindungen in anderen Anwendungsszenarios darzustellen. Hier kann man sich außer Sozialen Netzwerken so etwas vorstellen wie die Verbindungen zwischen Autoren, Papers, Tagungen und Zitaten in einem Research Network. Dabei soll der Ansatz so flexibel wie möglich bleiben, d.h. die Anwendung hat keine domänenspezifische “Intelligenz”. So sind auch exotische Szenarios wie z.B. die Beeinflussung von verschiedenen Musikstilen untereinander denkbar. Dazu lege ich ein Modell mit Knoten und Kanten zu Grunde, die typisiert sind. So kann ich die Kante zwischen einem Autor-Knoten und einem Paper-Knoten als “Autorenschaft” oder die Kanten von einem Paper A zu einem Paper B als “Zitat” klassifizieren.

Technisch soll das Ganze als Webapplikation in HTML5 und JavaScript implementiert werden, die ohne jegliche Server-seitige Verarbeitung auskommt. Die Applikation nimmt ein JSON-Datenfragment entgegen, dass Knoten, Kanten und Pfade enthält und zeichnet diese auf ein gegebenes HTML-Element (z.B. in einen <div>-Tag). Die typisierten Knoten (die auch nur <div>s sind) und Kanten werden per CSS formatiert. Die Kanten werden mittels des tollen jsPlumb gezeichnet. Die Idee ist es dann, für ein neues Anwendungsszenario entsprechend der typisierten Knoten und Kanten nur neue CSS-Regeln anlegen zu müssen.

Der aufmerksame Leser bemerkt hier natürlich, dass noch etwas fehlt: der eingegebene JSON-Datensatz muss natürlich zuerst einmal erzeugt werden. D.h. wir müssen die Daten aus dem Format der Fremd-Anwendung, z.B. aus der Facebook Open Graph API oder der DBLP erst einmal in unser Format konvertieren und die Daten evtl. aufbereiten (z.B. Pfade finden, wenn nur Knoten und Kanten gegeben sind) – dies soll jedoch vorerst nicht Teil dieser Arbeit sein.

Ein weitere Teil der Arbeit wird es sein, einmal zu schauen, welche Möglichkeiten, Objektrelationen mittel JavaScript zu zeichnen, es schon gibt – das sind nämlich eine Menge. Zudem unterscheiden sich diese in ihrer Flexibilität (entweder zu speziell auf ein Anwendungsszenario bezogen oder so elementar, das es ein “JavaScript-Zeichenprogramm” ist) und der Ausgefeiltheit der Implementierung (z.B. wie stark das Paradigma Trennung von Daten, Logik und Darstellung eingehalten wurde). Dieser Teil der Arbeit ist vielleicht mit der schwierigste: die Masse an vorhandenen JavaScript-Bibliotheken zu sichten und dann ein gute Begründung finden, warum denn jetzt mein Ansatz überhaupt besser ist :-)

Weitere Details werde ich regelmäßig hier auf dem Blog bekannt geben und natürlich werde ich auch über das Fortkommen der Arbeit berichten, der Quellcode wird außerdem immer auf GitHub zu finden sein.

Da es umständlich ist, eine ganze JSON-Datei selbst zu schreiben, bietet npm ein Hilfsmitel, das einen bei der Erstellung unterstützt, indem es Fragen zum Modul stellt, deren Antworten dann direkt in die package.json geschrieben werden: npm init.

Leider werden bereits installierte Module, die bereits im Verzeichnis node_modules installiert sind, nicht in die package.json aufgenommen. Dazu gibt es aber auch eine einfache Lösung: beim Installieren eines Modules den Parameter --save benutzen: npm install express --save.

Bei meiner Arbeit an SciFlowWriter habe ich mehrere Widgets implementiert, die ebenfalls über Socket.IO mit dem Server kommunizieren. Eins meiner Ziele war es, dass ein Benutzer z.B. eine Literaturliste pflegen und andere Benutzer die Änderungen sofort sehen können. Ansich funktioniert das wunderbar, nur leider bekamen alle anderen Benutzer, die mit diesem Pad nichts zu tun haben, ebenfalls diese Änderungen mit.

Jede Nachricht an den Server enthält eine Pad-ID. Anhand dieser ID werden die Daten in den Pads gespeichert. Nachrichten vom Server enthalten ebenfalls diese ID. Jetzt müsste ich in den Widgets einfach nur prüfen, ob die empfangene Nachricht für das Widget in einem bestimmten Pad bestimmt ist und ggf. die Nachricht verwerfen.

Die Bessere Lösung für das Problem sind jedoch “Räume”, die in Socket.IO benutzt werden können. Jedem Pad wird also ein eigener Raum zugewiesen. Jetzt können nur die Benutzer, die sich in diesem Raum befinden, Nachrichten erhalten, die nur an diesen Raum geschickt werden.

Für Node.js gibt es bereits mehrere Libraries, die OAuth unterstützen. Ich habe mir connect-auth und everyauth angesehen und mich u.A. wegen der einfacheren Erweiterbarkeit für everyauth entschieden. Welche weitere Gründe für everyauth sprechen, hat Brian Noguchi (der Entwickler von everyauth) auf Stack Overflow zusammengefasst.

Everyauth bietet Authentifizierung über twitter, Facebook, Google, (von mir beigesteuert und ab der nächsten Version auch) Mendeley und viele weitere bekannte Dienste.

Wie everyauth eingebunden wird, kann in der Dokumentation nachgelesen werden. Dort gibt es zu jedem Provider Code-Beispiele.

Hier sind die Folien zu meiner Abschlusspräsentation:

Die rund 120 Features (dabei handelt es sich um vorhandene und gewünschte Funktionalitäten aus Nutzersicht) waren ein guter Startpunkt, um die für die REST-Schnittstelle benötigten Ressourcen und Repräsentationen herzuleiten.

Kombiniert man das RAILS-Framework mit einer Softwarekomponente, welche die Erstellung der Repräsentationen vereinfacht (z.B. ROAR), ist die Umsetzung einer REST-Schnittstelle sehr elegant möglich.

Mir persönlich hat es sehr viel Spaß gemacht, mit den für mich ganz neuen Technologien Rails und Ruby zu arbeiten und bedanke mich für die Unterstützung aus dem ginkgo-dev-Team!

Hier nun die Folien der Abschlusspräsentation:

Ein Teil meiner Arbeit ist der Einsatz agiler Entwicklungsmethoden. Bei der Recherche nach guten Ansätzen Scrum zu erläutern bin ich auf ein meiner Meinung nach sehr gutes Video zu dem Thema gestoßen, interessiert vielleicht auch den Ein oder Anderen:

Scrum in 10 Minutes

Zu den ausstehenden Aufgaben gehören das zuende Schreiben der Grobfassung, dann der Feinschliff und anschließend noch das Korrekturlesen. Es bleiben noch genau vier Wochen dafür Zeit, die ich vermutlich auch nutzen werde. Noch lässt sich nicht absehen, ob es am Ende nochmal richtig stressig wird oder nicht aber das kann ja immer passieren. Ich denke aber, dass ich recht gut in der Zeit liege.

Direkt auf der Startseite befindet sich ein Textfeld, in dem ShareJS getestet werden kann. Es erinnert etwas an Etherpad, lässt sich jedoch mit nur vier Zeilen JavaScript-Code in eine Seite einbinden.

Besonders interessant ist die Unterstützung von JSON-Objekten. Das Demo-Spiel Hex zeigt, wie JSON-Objekte zwischen den Spielern synchronisiert werden.

In der Demo-Galerie finden sich weitere Beispiele, wie ShareJS genutzt werden kann. Darunter ein Code Editor und ein Wiki.