Chancen von Nichtakademikern im Hochschulsystem

[1] Eine äußerst interessante Studie, aber was folgt daraus? Wenn 99% der Leute, aus welchen Gründen auch immer keinen Zugang zum Hochschulsystem haben, dann ist das in meinen Augen ein Markt. Die Frage ist jetzt welche Angebote man dieser Masse machen kann damit sie ebenfalls in den Genuss einer höheren Bildung kommen. Zum Glück gibt es dafür bereits Antworten: Youtube, social academic Networks, Google Scholar, OpenScience, wissenschaftliche Blogs usw. Die Frage ist weniger: wie kann man die komplette Gesellschaft verändern, damit die sozialen Unterschiede angeglichen werden, sondern die Frage ist wie man in der derzeitigen Ist-Situation die Nachfrage befriedigt. Da bei Internet-Technologien die Kosten anders als in klassischen Hochschulsystemen sehr viel niedriger sind, bietet sich das Konzept des Distance-Learning geradezu an. Anbieter wie Udacity und OpenCourseware von US-amerikanischen Elite-Unis konnten bereits hohe Nutzerzahlen generieren. Wan ziehen die deutschen Unis nach? Man könnte auch dort die Lehrveranstaltungen ins Internet streamen damit Leute aus Nicht-Akademiker-Familien Zugriff erhalten auf die neuesten Informationen aus der Astronomie …

WordPress und die Geburtsstunde des Web 2.0

Häufig wird das Mitmachinternet Web 2.0 aus Nutzersicht thematisiert. Geschichtlich wird das Entstehen auf Anfang der 2000’er datiert, ab dem die User angefangen haben, eigene Inhalte ins Netz zu stellen und sich in Foren, Blogs und Wikis zu vernetzen. Die Wahrheit ist jedoch, dass am Web 2.0 die User eine unbedeutende Rolle gespielt haben und es entstand auch nicht durch die gestiegene Internet-affinität. Stattdessen ist das Web 2.0 technologiegetrieben. Seine Anfänge kann man auf die Blogging-Software WordPress zurückführen, welche ab 2004 in PHP erschien. Davor funktionierte das Erstellen einer Webseite sowie das Einpflegen von neuen Inhalten ungefähr so: Man hat sich auf seinem Rechner ein Linux System installiert, dort dann dann im Terminal den ftp Befehl eingegeben und sich mit der Gegenstelle vernetzt. Dann hat man eine .html Datei auf den Server hochgeladen. HTML ist ein Auszeichnungsformat was man mit Emacs im bearbeiten kann. Wie man vielleicht schon ahnt, war diese Prozedur nur von erfahrenen Informatikern ausführbar. Es war nicht so aufwendig wie C-Programmierung, aber es war vergleichbar mit der Bash-Administration.

Durch das Aufkommen von PHP Frontends, die allesamt auf SQL Datenbanken aufsetzten änderten sich diese Prozedur schlagartig. Auch Wikisysteme und Online-Foren sind nicht so sehr nutzergetriebene Kommunikationsmittel, sondern waren technische Innovationen. Wenn man dann noch die DSL-Flatrates mit hinzunimmt welche ab Anfang der 2000’er verfügbar waren, erhält man die Zutaten für das heutige Web 2.0. All diese Technologien haben dazu geführt, dass sich der Nutzerkreis dramatisch erhöht hat, und das man heute um sein Blog zu aktulisieren keine Bash-Befehle mehr beherschen muss. Rein theoretisch kann man wohl auch sein WordPress Blog von der command-shell aus aktualisieren, aber das müsste man bei Stackoverflow erstmal ergoogeln, so selten wird dieses Feature genutzt.

Das interessante an WordPress und ähnlicher Tools war, dass sie mehr und neue Probleme erzeugt haben. Um WordPress einzusetzen, benötigt man zwingend eine SQL-Datenbank auf dem Backend. Und diese wiederum benötigt zwingend einen leistungsfähigen Premium Web-Server sonst performt sie nicht schnell genug. Das heißt, durch WordPress bestand die Notwendigkeit die Hardware in den Rechenzentren aufzurüsten, und Caching Verfahren zu verwenden.

Erstaunlich spät wurde WordPress als ernstzunehmende Alternative zu FTP Servern entdeckt. Die ersten gedruckten Anleitungen auf Englisch erschienen ab 2007. Ein Heise Bericht aus 2008 liegt hier https://www.heise.de/ct/artikel/Von-Hausmannskost-zum-Galadiner-291604.html Erst ab 2010 war WordPress und Co wirklich akzeptiert von einer breiteren Nutzergemeinde. Zeitgleich mit dem Web 2.0 entstanden auch soziale Communitys wie Facebook bei dem das Content-Management-System selbst nicht mehr für die Enduser administrierbar war, sondern man lediglich einen Account bekam, und das Layout von dem Social Network fest voreingestellt war, die häufig auch noch als Moderator in Erscheinung traten. Spätestens ab da war das Web 2.0 im Mainstream angekommen.

Mit diesem Wissen im Hinterkopf kann man leichter abschätzen wie das Web 3.0 einmal aussehen wird. Es wird keineswegs Nutzergetrieben sein, wo also die vorhandene Infrastruktur von einer breiteren Gruppe genutzt wird, sondern der Startschuss fällt durch neue Technologie. Also neue Software oder ähnliches. Derzeit kenne ich keine Software die man als Web 3.0 bezeichnen könne. Eine Zeitlang wurde innerhalb der Informatik ein Diskurs geführt über das Semantic Web was auf RDFs, Ontologien und Protege aufbaut. Doch bei Lichte betrachtet sind diese Features unter dem Stichwort XML heute bereits in Blogging Tools wie WordPress integriert und sorgen dort dafür, dass RSS Feeds aktualisiert werden.

Der Wandel beginnt im Kopf?

[1]

„Denn die eigentliche Herausforderung der Umgestaltung unserer Mobilitätssysteme ist nicht das Fehlen einer Ladesäule, sondern unser Festhalten an historischen und überholten Vorstellungen vom Wesen der Mobilität.“

Einspruch euer Ehren. Kampagnen, die auf ein verändertes Bewusstsein in Bezug auf Elektromobilität und das Auto insgesamt ausgerichtet sind werden dem Problem nicht gerecht. Sie blenden vielmehr die Gegenwart aus und orientieren sich an unrealistischen Utopien wie dem im OP zitierten Ziel bis 2020 1 Million Elektroautos auf Deutschlands Straßen zu bringen. Was wir brauchen sind keine Visionen über die Welt von morgen, sondern wir brauchen eine Zustandsbeschreibung. Warum Ziele und Utopien ein denkbar ungeeignetes Kommunikationsmittel darstellen kann man gut anhand der Kommunikation innerhalb von Echtzeitcomputerspielen deutlich machen. Dort wird im Regelfall nicht darüber debattiert, was das Team als nächstes zu tun gedenkt, sondern die Kommunikation funktioniert so, dass jeder erzählt wie seiner Meinung nach die Welt aussieht. Das impliziert, dass diese Beschreibung ungenau oder sogar falsch sein darf. Der einzelne Akteur kann sich aus der Bewertung dieser Ist-Beschreibung dann sein eigenes Weltbild zusammenfügen.

Meiner Meinung nach ist das Managementprinzip mittels Zielvorgaben ein veraltetes System was bei hochkomplexen Entscheidungsprozessen an Grenzen stößt. Wissenschaftler, Literaturexperten und Filmemacher wird man darüber nicht ansprechen können. Erinnert sei an die bekannte Szene aus Startrek TNG wo Wesley Crusher zum ersten Mal mit der Leitung eines wissenschaftlichen Teams beauftragt wird, und seinen Freunden sagen muss, was sie tun sollen. Alle Informationen laufen bei Wesley zusammen, und er entscheidet dann was der einzelne als nächstes macht. Fällt das Wesley Crusher Brain aus, ist die Gruppe handlungsunfähig.

ELEKTROAUTOS
Schauen wir uns die Ist-Situation in Sachen Elektromobilität etwas näher an. Der Anschaffungspreis solcher Autos ist doppelt so hoch wie bei normalen Benzin-Autos. Die Reichweite beträgt mit Rückwind maximal 100 km, Ladestationen im öffentlichen Raum gibt es exakt 0, Werkstätten wo man defekte Akkus austauschen kann gibt es keine obwohl gerade im Winter wenn das System lange draußen steht sowas dringend erforderlich wäre. Technische Innovationen die einen Ersatz für die brennbaren Lithium-Ionen Akkus in Aussicht stellen oder eine Preisreduktion versprechen stehen keine auf der Agenda und durch den Wegfall des Motorengeräusches steigt die Unfallwahrscheinlichkeit, weil die Fußgänger nicht gewarnt sind, wenn so ein Ungetüm sich von hinten nähert. Bei der hohen Beschleunigung eines Tesla Sportwagens dreht sich in den Insassen der Magen herum und die verbauten Autopiloten haben mehrere tödliche Unfälle verursacht.

Software für das self-driving car

COMMA.AI
Eine erste Übersicht über OpenSource Software für autonome Autos wurde bereits hier im Blog gepostet und war enttäuschend. Heute soll es um eine weitere Software gehen: „Comma.ai OpenPilot“. Die Doku hat der Erfinder George Hotz als Arxiv-Paper veröffentlicht https://arxiv.org/pdf/1608.01230.pdf und der Python Code für das Control Modul gibt es auf https://github.com/commaai/openpilot/tree/master/selfdrive/controls/lib

Die Qualität des Papers lässt sich relativ einfach einschätzen: kompletter Bullshit. Dort steht drin, dass die Steuerung des Autos mittels Autoencoder (neuronale Netze) gelernt werden soll, ein Konzept was erwiesenermaßen zum Scheitern verurteilt ist. Siehe die zahlreichen Versuche im TORCS Simulator das Auto auf Spur zu halten. Da war ja das Paper „Rooter: A Methodology for the Typical Unification of Access Points and Redundancy“ gehaltvoller, was vom Dokumentengenerator Scigen stammt.

Der Python Code sieht schon etwas professioneller aus. Dort wird das Steering Problem des Lenkrades in verschiedene Submodule unterteilt, und in einigen davon wird ausgerechnet in welche Richtung das Fahrzeug fahren muss. Dann gibt es noch Message-Boxen die aufpoppen wenn die Software in einem kritischen Zustand ist so dass der Human-driver das Fahrzeug übernehmen soll. Aber, als Software für ein richtiges Auto ist das Projekt noch nicht weit genug entwickelt, man kann sie vielleicht für den Carolo Cup als Basis nehmen um darauf aufbauend dann eine komplexere Behavior Engine zu entwickeln.

Der Erfinder schätzt die Qualität seiner Software wohl nicht so pessimistisch ein und hat auf Youtube mehrere Videos veröffentlicht wo doch tatsächlich dieser unfertige Python Code auf einem richtigen Auto ausprobiert wurde. Will jemand dazu meine Meinung wissen? Die Antwort lautet, „dont drink & drive“.

Aber etwas positives hat das ganze dennoch. George Hotz und ähnliche Leute die mit unbrauchbarerer Software oder sogar DeepLearning Autos steuern wollen, ziehen ein bestimmtes Klientel an. Also Leute, von außerhalb der Informatik die darüber den Einstieg finden. Das könnte dienlich sein, um der Idee driverless Car zu gesellschaftlicher Beachtung zu verhelfen.

Schauen wir uns zum Vergleich einmal die Software an, die beim Stanley Robotcar von Sebastian Thrun verbaut wurde http://www-cs.stanford.edu/group/manips/publications/pdfs/Montemerlo_2008_FSR.pdf Dort wird als Kernkomponente ein sogenanntes Navigation Modul eingesetzt. Dort werden Pathplanning und Behavior Engine realisiert. Letztere arbeitet mit Finite State Machines. Das heißt, das Problem des autonomen Fahrens wurde mühevoll als linguistisches Modell implementiert (per Hand natürlich). Auch die Stanley Software ist noch weit davon entfernt in der Praxis ein Auto steuern zu können, es geht aber zumindest in die richtige Richtung. Man bräuchte für ein echtes driverless Car, eine sehr komplexe Behavior Engine wo angefangen von den Verkehrsregeln, über die Reaktion auf Fußgänger bis hin zum Einparken jedes Detail modelliert ist. Diese Komponente kann man nicht mittels neuronale Netze automatisiert erzeugen, sondern man benötigt ein klassisches Wasserfallmodell wo ausgehend von einer formalen Spezifikation dann die Software programmiert wird.

STANFORD
https://sourceforge.net/projects/stanforddriving/ Es handelt sich um die Stanford self-driving Car Software welche Sebastian Thrun bei der Darpa Challange für seinen Stanley Prototypen eingesetzt hat. Dankenswerterweise steht sie im Internet zum kostenlosen Download bereit. Obwohl die gepackte Datei mit 60 MB relativ groß ausfällt, reicht es aus, wenn man sich nur das Submodul „Motion Planning“ anschaut. Also der Teil worüber die Software entscheidet wohin sie das Lenkred bewegt. Das entsprechende Directory im Sourcetree lautet „rdr_public/stacks/planner“. Dort gibt es eine Datei namens „aw_Manneuver.h“ welche die Finite State Machines spezifiziert, welche auch im PDF Paper schon erläutert wurden:
– START_MISSION
– STOP_SIGN
– CURVE_RIGHT
– PARKING
und noch einige mehr.

Vom Konzept her wird das Ganze als Scripting AI bezeichnet. Das heißt, es wird im Detail formuliert, wie das Fahrzeug reagieren soll. Negativ an dem Sourcecode fällt auf, dass offenbar die Programmierer Fans von C++ sind. Ob es eine gute Designentscheidung war, eine Compilersprache die ausgiebig Gebrauch macht von Pointern für AI Scripting einzusetzen? Besser wäre es gewesen, eine Sprache wie Python zu verwenden, weil man damit im Simulator das Verhalten der Software leichter debuggen kann, was sicherlich der Qualität gut getan hätte. Das Problem besteht darin, dass es Programmierer gibt, die außer C++ mit keinen anderen Sprachen vertraut sind. Hier mal ein kurzer Snippet wie sowas in der Praxis dann aussieht:

  while (anno_edge_it != topology->route.route.end()) {
    // add park maneuver
    if ((*anno_edge_it)->hasAnnotation(UC_MANEUVER_PARKING)) {
      assert((*anno_edge_it)->edge()->isZoneEdge());
      zone_maneuvers.push_back(*anno_edge_it);
    }

Zusätzlich sollte man wissen, dass C++ immer als Compilersprache funktioniert. Das heißt, wenn man eine winzige Änderung am Code vornimmt, muss man das komplette Projekt nochmal neu kompilieren, was dazu führt, dass die Änderungs- und Testingbereitschaft nur niedrig ist. Das führt konkret dazu, dass niemand so recht weiß was der Code für ein Verhalten in neuen Umgebungen zeigt. Hinzu kommt diese typischer C++ Style, wo man auf Speicheradressen verweist was in einer HIgh-Level-BehaviorEngine die Komplexität unnötig erhöht.

Im direkten Vergleich ist die Stanford Software höher entwickelt als die eingangs zitierte Comma.AI Software. Wenn man den Code nochmal from scratch neu entwickelt könnte man damit gut beim Carolo Cup mitfahren. Echte Autos kann man damit jedoch nicht steuern.

Evaluation von self-driving car Software

In den Medien ist häufiger die Rede davon, dass Hersteller wie Google mit der Straßenzulassung für ihre Autos Probleme haben, weil natürlich die Prüfer keine Programmierer sind und gar nicht einschätzen können wie die Software intern arbeitet. Dabei ist die Evalution von self-driving Car software erstaunlich simpel. Generell kann man sagen dass Software die in C++ programmiert wurde (wie die Junior Reihe von Sebastian Thrun) schonmal grober Murks darstellt. C++ ist eine Programmiersprache welche Konzepte vermischt die getrennt gehören: Compilersprache, Pointer, Objektorientiertung. Besser sind hingegen Systeme die aus Frontend und Backend bestehen, wo also zeitkritische Dinge in reinem C programmiert wurden, während GUI und BehaviorEngine in einer Scripting Sprache wie Python programmiert wurden. Aber das nur am Rande. Viel entscheidener ist, dass man eine self-driving Car Software auf eine simple Komponente reduzieren kann. Wichtig ist keineswegs die Funktionsweise des Lidars und auch nicht das schöne Umgebungsbild was das Auto von seiner Umwelt erstellt, sondern worauf es ankommt ist der Motion Planner. Also jener Teil wo Pathplanning, Verkehrsregeln und Steuerung des Lenkrades implementiert sind. Im Grunde reicht es aus, sich dieses Submodul anzuschauen bzw. die dazu erstellte Dokumentation zu konsultieren. Wurden dort Dinge berücksichtigt wie ein Toter Winkel, Kreisverkehr, grüner Pfeil beim Rechtsabbiegen, Rechts vor links regeln usw. und wenn ja, wie sehen im Detail die Prozeduren aus. Speziell ist zu klären ob sie gut dokumentiert wurden, und wie der Gesamteindruck der Software ist.

Die anderen Komponenten die man zu autonomen Fahren noch benötigt wie GPS, Sensorfusion, 3D Kameras, onboard Steuercomputer kann man getrost ignorieren. Wenn der Motion Controller schon den Anforderungen nicht genügt, kann das der beste SICK Laser der Welt nicht mehr ausgleichen. Um die Qualität einer Software einzuschätzen bzw. zu dem Urteil zu gelangen dass sie komplett ungenügend ist für den Personenverkehr reichen 10 Minuten herumlesen in der Dokumentation plus Überfliegen des Sourcecodes in aller Regel aus. Länger braucht es nicht, um Google, George Hotz oder Mobileye zu erklären, dass ihre Software keine Straßenzulassung erhält.

Kleines Psychogramm von George Hotz

Da George Hotz in den Medien relativ präsent ist und seine Firma Produkte verkaufen will ist es an der Zeit die Dinge ein wenig kritischer zu begutachten. Zunächst einmal ist das Gebiet was sich Hotz ausgesucht (driverless car) ein sehr interessantes. Meiner Ansicht nach wird es in 20 Jahren die erste selbst-fahrenden Autos auf den Straßen geben die dann dafür sorgen, dass die Zahl der Verkehrstoten reduziert wird. Nur, was George Hotz aktuell macht kann man eigentlich nur als Geisterfahrt bezeichnen. Das heißt, er hat sich dafür entsschieden in der Gegenrichtung unterwegs zu sein und wundert sich worum alle anderen in die falsche Richtung fahren … Was meine ich damit? Nun schaut, man sich die Präsentation von Hotz an, wo er das technische Konzept erläutert so ist dort die Rede von Convolutional Neural Networks, Recurrent neural Networks, Machine Learning und lauter solche Sachen. Und er sagt ferner, dass er aus Gigabyte weise Daten ein Modell des menschlichen Fahrens erstellt habe, dass jetzt wiederum das Auto von alleine fahren lässt.

Es ist nicht ganz leicht, das ganze objektiv einzuschätzen. Aus Sicht von Hotz der wie eingangs zitiert in der falschen Richtung unterwegs ist, macht das natürlich alles Sinn. Das also jene Leute die behaupten, man müsste richtige Software schreiben, wofür man viele Jahre braucht und was nach dem Wasserfallmodell und einem Pflichtenheft durchgeführt wird, allesamt falsch liegen weil man mit Machine Learning in wenigen Sekunden den fertigen Algorithmus erhält, der sich in den Fahrer einfühlt. Nur, mit Informatik hat der Vortrag von Hotz nicht viel zu tun, eher mit Aberglauben, alternative Heilmethoden und Religionen.

Man kann Hotz natürlich nicht verbieten, doch spaßeshalber neuronale Netze zu verwenden um die Umgebung zu erfassen und womglich sogar das Lenkrad zu steuern, nur sei darauf hingewiesen, dass Hotz mit diesem Konzept sehr alleine dasteht und dass selbst in einer virtuellen Simulation neuronale Netze komplett unfähig sind, intelligente Entscheidungen zu treffen. Die best-practice Methode zum Programmieren einer Künstlichen Intelligenz besteht in dem von Hotz abfällig beurteilten manuellen Programmieren der Software. Nur darüber lassen sich komplexe Systeme entwickeln. Was Hotz hingegen vorhat ist es, eine analogen Oszilator an ein Lenkrad anzuschließen, und den von einem Solver justieren zu lassen, damit mit viel Glück dann die KI sich alleine weiterentwickelt. Das ist keine Innovation, das ist Selbstmord.

Es ist derzeit nicht klar, ob George Hotz weiß, dass er kompletten Unsinn erzählt und sich einen Scherz daraus macht, der Öffentlichkeit kompletten Unsinn für Wissenschaft zu verkaufen. Fakt ist jedoch, dass er in der falschen Richtung unterwegs ist und offenbar plant für seinen Plan weitere Leute zu begeistern.

Was womöglich der Hidden Plan sein könnte ist, dass George Hotz natürlich weiß, dass sein Konzept kompletter Unsinn ist und comma.ai in Wahrheit ähnlich wie Udacity so eine Art von Fernuniversität ist, welche Self-driving-cars unterrichtet. Das also das Ziel darin besteht nicht so sehr echte Autos mit Software auszustatten, sondern möglichst viele Leute für die Idee zu begeistern um ihnen dann Kurse in Programmieren zu verkaufen. Vergleicht man einmal das äußere Auftreten von Hotz mit dem von Sebastian Thrun so gibt es gewisse Gemeinsamkeiten. Auch Thrun erzählt der Weltöffentlichkeit, dass Maschine Learning der richtige Ansatz wäre für autonomous driving, aber was Thrun heute betreibt ist nicht etwas Software zu programmieren, sondern Anfängerkurse in Künstlicher Intelligenz abzuhalten. Und tatsächlich, Machine Learning und neuronale Netze sind sehr gut geeignet für Leute die noch nicht mit KI Kontakt hatten, langsam an das Thema heranzuführen. Man kann damit zwar keine Autos oder Roboter steuern, aber man kann das Wissen gut in Kursen vermitteln.

Die wahrscheinlichste Erklärung dürfte darin bestehen, dass Thrun und George Hotz sehr genau wissen, dass der driverless Car Sektor nicht von ihnen bearbeitet wird, sondern von den großen Automobilherstellern, die irgendwann richtige Software programmieren und ausliefern werden. Die Zwischenzeit bis dahin wird dann eben dafür genutzt, schonmal die Leute auf Singularity einzustimmen. Das heißt, Google will nicht wirklich driverless cars ausliefern und Hotz will nicht wirklich Autos mit seiner Software steuern, sondern es geht darum, das ganze nur zu proben.

Das ist insofern schade, weil man mit Comma.ai und Udacity eben nicht über autonomes Fahren debattieren kann, sondern nur über Education. Das ist jenes Gebiet womit sich die Protagonisten wirklich auskennen.

Rückblick auf 6 Monate Academia.edu

Vor mehreren Monaten habe ich das Portal Academia.edu entdeckt. Inzwischen habe ich immerhin 10 Paper dort hochgeladen und wollte einmal über meine Erfahrungen berichten. Im Durchschnitt haben die Paper einen einen Leserkreis von 5 Personen generiert, das ist für wissenschaftliche Paper normal. Sie sind zwar über die Google Websuche auffindbar, nicht jedoch über die Google Scholar Suche. Das heißt, Academia.edu ist gegenüber einer richtigen OpenAccess Zeitschrift wie PLOS im Nachteil. Auf der anderen Seite ist der Service kostenlos und man braucht sich nicht mit Pseudo-Peer-Reviews herumzuärgern sondern lädt das PDF einfach auf den Server hoch und fertig. Irgendwelche konkreten Vorteile haben sich aus der Verwendung von Academia.edu bisher nicht ergeben, außer vielleicht das man sich als Teil einer größeren Gemeinschaft verstehen kann, die an einem anderen Wissenschaftsbetrieb interessiert sind, bei dem jeder publizieren darf, egal ob er einen Doktortitel führt oder nicht.

Ersetzen kann Academia.edu ein normales Weblog leider nicht, aber es ist eine interessante Ergänzung wenn man PDF Paper einem wissenschaftlichen Publikum zur Verfügung stellen möchte. Damit ist der Dienst konkurrenzlos, es gibt höchstens noch ResearchGate, aber dort ist die Zuigangshürde größer. Am ehesten könnte man Academia.edu als bessere blogging-Software beschreiben wo man also nicht in WordPress publiziert, sondern auf einem Dokumentenserver. Die Schwierigkeit bei WordPress ist, dass dort längere Texte mit Abbildungen und Literaturverweisen technisch gesehen keinen Sinn machen. Sondern WordPress ist eher ein Kommunikationstool und nicht so sehr ein Publikationstool. Das schöne an Academia.edu ist, dass der verwendete PDF Parser komplett störungsfrei arbeitet. Bisher gab es keinerlei Probleme beim Umwandeln der hochgeladenen PDF Paper, und es werden sogar die Abstracts halbautomatisch extrahiert. Ob das auch bei Dokumenten klappt die mittels MS-Word erstellt wurden, weiß ich nicht, ich selbst habe ausschließlich Lyx genutzt um die PDF Paper zu formatieren.

Bisher ist mein Gesamteindruck, dass Academia.edu zwar einen guten Eindruck macht, dass aber noch nicht im Detail klar ist, wozu man das eigentlich braucht. Eine Alternative zu wissenschaftlichen Zeitschriften ist es jedenfalls nicht, und eine Alternative zu Blogging-Systemen auch nicht. Es liegt irgendwo dazwischen und könnte in Zukunft vielleicht noch interessant werden. Das dürfte davon abhängen, wieviele User der Dienst an sich bindet und ob die tatsächlich Content hochladen. Das interessanteste an Academia.edu ist weniger das Portal als vielmehr die Idee die dahintersteht. Diese manifestiert sich in der Person Richard Price, der sehr eloquent über die Zukunft des wissenschaftlichen Publizieren zu berichten weiß. Objektiv betrachtet besteht Acadamia.edu vermutlich nur aus heißer Luft, die mit Versprechen operiert die nicht eingehalten werden. Aber egal, selbst wenn das Startup in 3 Jahren schon wieder weg ist vom Fenster war es der richtige Ansatz.