Hi,
Uli hat uns das schon auf der CeBIT gezeigt, aber nun ist ein Mockup dr ersten Seite online:
http://upload.wikimedia.org/wikipedia/de/9/9c/Demo_ulis_fork.pdf
Wenn man tatsächlich wikipedia drucken will, wäre sein Weg sicher ein möglicher (auch wenn ich im Detail einige Aspekte scheisse finde).
Wie üblich gilt:
Alle Leute halten freie Lizenzen gut, nur für die eigenen Projekte funktioniert das Modell nicht (hier: wiki-Syntaxderivat -> PDF)...
Naja, auch bei Uli ist die Einsichtswahrscheinlichkeit nicht 0.
Mathias
Am Sonntag, 20. März 2005 17:53 schrieb Mathias Schindler:
Hi,
Uli hat uns das schon auf der CeBIT gezeigt, aber nun ist ein Mockup dr ersten Seite online:
http://upload.wikimedia.org/wikipedia/de/9/9c/Demo_ulis_fork.pdf
Ist kein Mockup - das Ding kommt zu 100% aus meiner Schriftsetzungs-Engine.
Wenn man tatsächlich wikipedia drucken will, wäre sein Weg sicher ein möglicher (auch wenn ich im Detail einige Aspekte scheisse finde).
Welche?
Wie üblich gilt:
Alle Leute halten freie Lizenzen gut, nur für die eigenen Projekte funktioniert das Modell nicht (hier: wiki-Syntaxderivat -> PDF)...
Korrekt. Derzeit ist der Bedarf für solche Software zu klein, um das dreiviertel Jahr Entwicklungsaufwand, das ich mittlerweile reingesteckt hab, über Beratung oder ähnliches refinanziert zu bekommen. Das ganze rentiert sich nur, wenn es ein Teil eines Gesamtkonzeptes ist, und dieses Gesamtkonzept heißt derzeit: Wikipedia-Fork mit besseren Autoren, besseren Inhalten, besserer Community und besserer Software, was in Summe vielleicht ein so bekanntes Webprojekt ergibt, dass man darüber die Software verkaufen und die Inhalte per bestens dazu passender Software vermarkten kann und so den Aufwand, tatsächlich freie Inhalte(!) zu bekommen, refinanzieren kann. Nicht jeder verfügt wie Wikimedia über zigtausende zum Fenster rauswerfbare Spendendollars.
Naja, auch bei Uli ist die Einsichtswahrscheinlichkeit nicht 0.
Stimmt. Lange darüber nachgedacht und zu der Einsicht gekommen, dass closed source in dem Fall die besse Lösung ist.
Uli
Ist das in PHP realisiert? Wenn ja, mit PDFlib oder freePDF und PHP5? Mario
-----Original Message----- From: wikide-l-bounces@Wikipedia.org [mailto:wikide-l-bounces@Wikipedia.org] On Behalf Of Ulrich Fuchs Sent: Sunday, March 20, 2005 8:00 PM To: Mailingliste der deutschsprachigen Wikipedia Subject: Re: [Wikide-l] Wikipedia-Inhalte knuddeln und drucken...
Am Sonntag, 20. März 2005 17:53 schrieb Mathias Schindler:
Hi,
Uli hat uns das schon auf der CeBIT gezeigt, aber nun ist ein Mockup dr ersten Seite online:
http://upload.wikimedia.org/wikipedia/de/9/9c/Demo_ulis_fork.pdf
Ist kein Mockup - das Ding kommt zu 100% aus meiner Schriftsetzungs-Engine.
Wenn man tatsächlich wikipedia drucken will, wäre sein Weg sicher ein möglicher (auch wenn ich im Detail einige Aspekte scheisse finde).
Welche?
Wie üblich gilt:
Alle Leute halten freie Lizenzen gut, nur für die eigenen Projekte funktioniert das Modell nicht (hier: wiki-Syntaxderivat -> PDF)...
Korrekt. Derzeit ist der Bedarf für solche Software zu klein, um das dreiviertel Jahr Entwicklungsaufwand, das ich mittlerweile reingesteckt hab,
über Beratung oder ähnliches refinanziert zu bekommen. Das ganze rentiert sich nur, wenn es ein Teil eines Gesamtkonzeptes ist, und dieses Gesamtkonzept heißt derzeit: Wikipedia-Fork mit besseren Autoren, besseren Inhalten, besserer Community und besserer Software, was in Summe vielleicht ein so bekanntes Webprojekt ergibt, dass man darüber die Software verkaufen und die Inhalte per bestens dazu passender Software vermarkten kann und so den Aufwand, tatsächlich freie Inhalte(!) zu bekommen, refinanzieren kann. Nicht jeder verfügt wie Wikimedia über zigtausende zum Fenster rauswerfbare Spendendollars.
Naja, auch bei Uli ist die Einsichtswahrscheinlichkeit nicht 0.
Stimmt. Lange darüber nachgedacht und zu der Einsicht gekommen, dass closed source in dem Fall die besse Lösung ist.
Uli
Am Sonntag, 20. März 2005 23:44 schrieb Mario Ihme:
Ist das in PHP realisiert? Wenn ja, mit PDFlib oder freePDF und PHP5?
In Java/J2EE (ich benutze nur Programmiersprachen ;-). Das Umbrechen/Bilder platzieren etc. erfolgt über eine eigene Engine, die ihr Ergebnis mit der itext-Library nach pdf ausgibt.
Uli
On Mon, 21 Mar 2005 09:20:49 +0100, Ulrich Fuchs mail@ulrich-fuchs.de wrote:
Am Sonntag, 20. März 2005 23:44 schrieb Mario Ihme:
Ist das in PHP realisiert? Wenn ja, mit PDFlib oder freePDF und PHP5?
In Java/J2EE (ich benutze nur Programmiersprachen ;-). Das Umbrechen/Bilder platzieren etc. erfolgt über eine eigene Engine, die ihr Ergebnis mit der itext-Library nach pdf ausgibt.
Den gleichen Ansatz (über iText) habe ich auch versucht im Eclipse Plugin für den PDF export zu implementieren: sf.net/projects/plog4u
Im Gegensatz zu deiner Engine, habe ich allerdings nur den simplen (schon in iText eingebauten) HTML nach PDF Konverter benutzt. Um das Ganze qualitativ hochwertiger zu gestalten, kommt wohl um eine eigene Konvertierungsengine nicht herum.
Ulrich Fuchs wrote:
Ist kein Mockup - das Ding kommt zu 100% aus meiner Schriftsetzungs-Engine.
Stimmt ja...
Wenn man tatsächlich wikipedia drucken will, wäre sein Weg sicher ein möglicher (auch wenn ich im Detail einige Aspekte scheisse finde).
Welche?
Du machst mal wieder eine neue Syntax auf, beispielsweise.
Korrekt. Derzeit ist der Bedarf für solche Software zu klein, um das dreiviertel Jahr Entwicklungsaufwand, das ich mittlerweile reingesteckt hab, über Beratung oder ähnliches refinanziert zu bekommen.
Wie schon auf der CeBIT gesagt:
* Wenn deine Idee über die Fragmente der ersten zwei Seiten nicht herauskommt, grüße an den Staub der Geschichte
* Wenn du damit Erfolg hast, bin ich mir sicher, daß sich Leute für eine freie Reimplementation finden.
Das ganze rentiert sich nur, wenn es ein Teil eines Gesamtkonzeptes ist, und dieses Gesamtkonzept heißt derzeit: Wikipedia-Fork mit besseren Autoren, besseren Inhalten, besserer Community und besserer Software, was in Summe vielleicht ein so bekanntes Webprojekt ergibt, dass man darüber die Software verkaufen und die Inhalte per bestens dazu passender Software vermarkten kann und so den Aufwand, tatsächlich freie Inhalte(!) zu bekommen, refinanzieren kann.
Das Gesamtkonzept sehe ich wohl.
Nicht jeder verfügt wie Wikimedia über zigtausende zum Fenster rauswerfbare Spendendollars.
Welcher Euro wurde von Wikimedia (Foundation?) zum Fenster herausgeworfen?
Naja, auch bei Uli ist die Einsichtswahrscheinlichkeit nicht 0.
Stimmt. Lange darüber nachgedacht und zu der Einsicht gekommen, dass closed source in dem Fall die besse Lösung ist.
Aus oben genannter Alternative kann ich dir nur Erfolg wünschen.
Mathias
Am Montag, 21. März 2005 07:58 schrieb Mathias Schindler:
Nicht jeder verfügt wie Wikimedia über zigtausende zum Fenster rauswerfbare Spendendollars.
Welcher Euro wurde von Wikimedia (Foundation?) zum Fenster herausgeworfen?
Hast Du Dich mal gefragt, ob man, würde man ein restriktiveres Zugangssystem haben, weit weniger Geld ausgeben müsste, weil die Serverlast weit geringer wäre? Die Masse der sogenannten Mitarbeiter bei Wikipedia sind heute keine mehr, sie sind nur Traffic-Erzeuger. Man steckt also Geld in etwas, das keinen Content sondern Rauschen produziert. Wobei ich natürlich dahingestellt lasse, ob man die vielen, nichts Produktives beitragenden Leute wirklich braucht, um ein paar wenige andere dazu anzuhalten, was Produktives beizutragen. Könnte durchaus sein - ich weiß es nicht. Wird sich rausstellen, wenn mein Fork nicht klappt, wird dem wohl so sein.
Uli
Am Sonntag 20 März 2005 20:00, schrieb Ulrich Fuchs:
Ist kein Mockup - das Ding kommt zu 100% aus meiner Schriftsetzungs-Engine.
Hint: Spaltenausgleich. Wenn Du mal ne freie Minute hast, dann kannst Du Dich ja mal dranmachen und das Layout so gestalten, dass die Spalten bündig abschließen bzw. die Zeilen alle auf gleicher Höhe sind. Das wird durch die Bilder im Text etwas schwierig, doch kann behoben werden wenn Bilder immer eine Höhe von n*Zeilenhöhe einnehmen ... das Bild eben in der Mitte eines Rahmens platzieren, der ganze Zeilenhöhen umfasst und mindestens so hoch ist wie das darin platzierte Bild.
Hint 2: Was bisher noch niemand macht, was aber extrem fein wäre, ist ein Blocksatz, bei dem Trennzeichen, Punkte und Kommatas aus dem Block nach außen gezogen werden. Damit wird der Blocksatz dann zu einem echten (auch optischen) Blocksatz (wie Früher, als man das alles per Hand machte).
CU/2 Hartwin
Am Montag, 21. März 2005 10:46 schrieb harko:
Am Sonntag 20 März 2005 20:00, schrieb Ulrich Fuchs:
Ist kein Mockup - das Ding kommt zu 100% aus meiner Schriftsetzungs-Engine.
Hint: Spaltenausgleich. Wenn Du mal ne freie Minute hast, dann kannst Du Dich ja mal dranmachen und das Layout so gestalten, dass die Spalten bündig abschließen bzw. die Zeilen alle auf gleicher Höhe sind. Das wird durch die Bilder im Text etwas schwierig, doch kann behoben werden wenn Bilder immer eine Höhe von n*Zeilenhöhe einnehmen ... das Bild eben in der Mitte eines Rahmens platzieren, der ganze Zeilenhöhen umfasst und mindestens so hoch ist wie das darin platzierte Bild.
Was den Spaltenausgleich im Moment kaputthaut, sind nicht die Bilder, sondern der anderthalbfache Zeilenabstand zwischen Absätzen. Die Engine würde es schon hergeben, dass ich alle Zeilen an einem festen Raster ausrichte, aber dann muss ich eben auf diesen Durchschuss verzichten. Ich weiß noch nicht, was besser aussieht, da muss ich noch ein wenig rumspielen. Beides zu kombinieren, ist automatisiert vermutlich schon nicht mehr möglich. Ich will auch nicht alle Zeit der Welt in die Engine stecken, sie ist für den Start gut genug. Besser 90% jetzt als 100% nie.
Uli
Am Montag 21 März 2005 11:23, schrieb Ulrich Fuchs:
Hint: Spaltenausgleich. [...] abschließen bzw. die Zeilen alle auf gleicher Höhe sind. Das wird
Was den Spaltenausgleich im Moment kaputthaut, sind nicht die Bilder, sondern der anderthalbfache Zeilenabstand zwischen Absätzen. Die Engine würde es schon hergeben, dass ich alle Zeilen an einem festen Raster ausrichte, aber dann muss ich eben auf diesen Durchschuss verzichten. Ich weiß noch nicht, was besser aussieht, da muss ich noch ein wenig rumspielen. Beides zu kombinieren, ist automatisiert
Hmm ... das ist dann wohl eher Geschmackssache, doch ich halte diesen immer wieder zu sehenden Durchschuss zwischen Absätzen für nicht sehr sinnvoll. Da ist eher schon die Einrückung der jeweils ersten Zeile angemessen. So ein Durchschuss als Absatztrenner hat auch die Macke, dass er bei einer vollen letzten Absatzzeile am Seitenende komplett versagt - der nächste Absatz auf der nächsten Seite macht dann nämlichüberhaupt nicht mehr den Eindruck, ein nächster Absatz zu sein.
Uli
CU/2 Hartwin
On Mon, Mar 21, 2005 at 12:36:45PM +0100, harko wrote:
Hmm ... das ist dann wohl eher Geschmackssache, doch ich halte diesen immer wieder zu sehenden Durchschuss zwischen Absätzen für nicht sehr sinnvoll. Da ist eher schon die Einrückung der jeweils ersten Zeile angemessen. So ein Durchschuss als Absatztrenner hat auch die Macke, dass er bei einer vollen letzten Absatzzeile am Seitenende komplett versagt - der nächste Absatz auf der nächsten Seite macht dann nämlichüberhaupt nicht mehr den Eindruck, ein nächster Absatz zu sein.
Wollt ich auch schon sagen. Beim WR Digest ist es so der Fall, macht die Sache viel kompakter. Die Registerhaltigkeit (Zeilen auf gleicher Höhe) sollte auch eingehalten werden, ich weiß ja nicht wie du deine Bilder und Tabellen einfügst, aber wenn deren Höhe ein vielfaches der Zeilenhöhe ist dann sollte es von ganz alleine stimmen.
ciao, tom
Am Montag 21 März 2005 13:11, schrieb Thomas R. Koll:
nicht sehr sinnvoll. Da ist eher schon die Einrückung der jeweils ersten Zeile angemessen. So ein Durchschuss als Absatztrenner hat auch die Macke, dass er bei einer vollen letzten Absatzzeile am Seitenende komplett versagt - der nächste Absatz auf der nächsten
Die Registerhaltigkeit (Zeilen auf gleicher Höhe) sollte auch
Das war ja mein Kritikpunkt an dem Teil ... ist zwar eher so ein kleines Haar in der Suppe als eine komplette Entwertung, aber erwähnenswert auf alle Fälle.
eingehalten werden, ich weiß ja nicht wie du deine Bilder und Tabellen einfügst, aber wenn deren Höhe ein vielfaches der Zeilenhöhe ist dann sollte es von ganz alleine stimmen.
Naja, ich setz das als extra Elemente, welche sich in den Taxtblöcken ihren Platz schaffen. Mehr als ein Bild pro Spalte ist eh nicht sinnvoll und die Textböcke werden auf der Fußzeile ausgeglichen. Damit kommt die Registerhaltigkeit von ganz allein.
ciao, tom
CU/2 Hartwin
On Mon, 21 Mar 2005 12:36:45 +0100, harko wrote:
Am Montag 21 März 2005 11:23, schrieb Ulrich Fuchs:
Was den Spaltenausgleich im Moment kaputthaut, sind nicht die Bilder, sondern der anderthalbfache Zeilenabstand zwischen Absätzen.
Hmm ... das ist dann wohl eher Geschmackssache, doch ich halte diesen immer wieder zu sehenden Durchschuss zwischen Absätzen für nicht sehr sinnvoll. Da ist eher schon die Einrückung der jeweils ersten Zeile angemessen.
Soweit ich weiß, ist "kein Durchschuss + Einrücken der ersten Zeile" anglophone Satztradition, während germanophone Tradition eben "Durchschuss + kein Einrücken" ist.
Gruß, Philip
Am 22.03.2005 um 06:49 schrieb Philip Newton:
Hmm ... das ist dann wohl eher Geschmackssache, doch ich halte diesen immer wieder zu sehenden Durchschuss zwischen Absätzen für nicht sehr sinnvoll. Da ist eher schon die Einrückung der jeweils ersten Zeile angemessen.
Soweit ich weiß, ist "kein Durchschuss + Einrücken der ersten Zeile" anglophone Satztradition, während germanophone Tradition eben "Durchschuss + kein Einrücken" ist.
Auch in deutschen Büchern werden Absätze üblicherweise mit einem Einzug im Geviert ohne Leerzeile markiert. Das ist auf jeden Fall vorzuziehen und ermöglicht auch eine Staffelung, denn die Leerzeile steht noch als zusätzliche Markierung für größere Abschnitte zur Verfügung.
Rainer
Mathias Schindler wrote:
Wenn man tatsächlich wikipedia drucken will, wäre sein Weg sicher ein möglicher
Allein: Wer will das denn? Wenn ich eine gedruckte Enzyklopädie brauche, dann kaufe ich mir einen Brockhaus, aber drucke doch nicht 1000 Seiten selber aus?
Das interessanteste an Wikipedia ist, dass es online verfügbar ist, und das man in den Artikeln genügend Platz hat, um normale Sätze zu formulieren, die vernünftig gegliedert werden können etc.
Insofern: Netter Versuch, und vermutlich die direktere Brockhaus-Konkurrenz, die möglich ist - aber darunter leiden die Vorteile, die das Internet sonst bietet.
Konkurrenz für Wikipedia ist das sicherlich in keiner Hinsicht.
(auch wenn ich im Detail einige Aspekte scheisse finde).
Beispielsweise beim Urheberrecht, wo Uli den "Standard" der Wikireader fortsetzt (alle Autoren am Schluss in einer langen Liste). Ob sich irgendeiner der professionellen Wissenschaftler (die ja die Zielgruppe sein sollen) damit zufrieden gibt, dass sein Name in einer "ferner liefen"-Liste auftaucht, ist fraglich. Auch für die Seriösität und Glaubwürdigkeit wäre es ein Gewinn gewesen, wenn über den Artikeln die Namen der Fachleute stehen würden. Meiner Meinung nach wäre es deutlich sinnvoller gewesen, dorthin Zeit zu investieren, statt in irgendwelche PDF-Engines.
Matthias
On Mon, Mar 21, 2005 at 12:54:32AM -0500, Matthias Walliczek wrote:
(auch wenn ich im Detail einige Aspekte scheisse finde).
Beispielsweise beim Urheberrecht, wo Uli den "Standard" der Wikireader fortsetzt (alle Autoren am Schluss in einer langen Liste). Ob sich irgendeiner der professionellen Wissenschaftler (die ja die Zielgruppe sein sollen) damit zufrieden gibt, dass sein Name in einer "ferner liefen"-Liste auftaucht, ist fraglich. Auch für die Seriösität und Glaubwürdigkeit wäre es ein Gewinn gewesen, wenn über den Artikeln die Namen der Fachleute stehen würden.
Und der Brockhaus, wie ist das bei dem gelöst? Werden die Autoren da _überhaupt_ genannt?
ciao, tom
Thomas R. Koll wrote:
Und der Brockhaus, wie ist das bei dem gelöst? Werden die Autoren da _überhaupt_ genannt?
Jetzt mal unabhängig von GNU FDL: Uli hat in einem Punkt definitiv recht: Eine Enzyklopädie, die von keinen unbekannten und anynomen Brockhaus-Redaktion, sondern von anerkannten Fachleuten geschrieben wird - das wäre definitiv ein gewaltiger Gewinn. Und er hat in einem anderen Punkt auch recht: Auf Wikipedia ist so eine Vision wenigstens momentan ziemlich aussichtslos. Andererseits stellt sich die Frage, warum es bei seinem Projekt ausgerechnet klappen soll. Ein "Nature"-Magazin, in dem jeder vertreten sein will, kann man nicht einfach von heute auf morgen gründen, indem man die Software programmiert und einen Webserver aufsetzt. Und selbst in trollfreier Umgebung wird es schwierig sein, ohne destruktiven Streit zwischen den einzelnen Wissenschaftlern einen gemeinsamen Text zu erstellen.
Kurzum: Ich sehe Ulis Projekt als Bereicherung, vielleicht auch als GNU FDL-Textquelle für Wikipedia, aber eben auch als sehr ambitioniertes Projekt.
Matthias
Matthias Walliczek wrote:
Allein: Wer will das denn? Wenn ich eine gedruckte Enzyklopädie brauche, dann kaufe ich mir einen Brockhaus, aber drucke doch nicht 1000 Seiten selber aus?
Es gibt eine Erfindung namens Druckerei...
Das interessanteste an Wikipedia ist, dass es online verfügbar ist, und das man in den Artikeln genügend Platz hat, um normale Sätze zu formulieren, die vernünftig gegliedert werden können etc.
Das ist *ein* interessanter Aspekt an wikipedia.
Insofern: Netter Versuch, und vermutlich die direktere Brockhaus-Konkurrenz, die möglich ist - aber darunter leiden die Vorteile, die das Internet sonst bietet.
Wikipedia war von anfang an als Druckwerk gedacht. Das hat nichts mit Konkurrenz zu tun. Weder zu Brockipedia noch zu Bröckelstein noch zu Wikipedia.
Beispielsweise beim Urheberrecht, wo Uli den "Standard" der Wikireader fortsetzt (alle Autoren am Schluss in einer langen Liste). Ob sich irgendeiner der professionellen Wissenschaftler (die ja die Zielgruppe sein sollen) damit zufrieden gibt, dass sein Name in einer "ferner liefen"-Liste auftaucht, ist fraglich. Auch für die Seriösität und Glaubwürdigkeit wäre es ein Gewinn gewesen, wenn über den Artikeln die Namen der Fachleute stehen würden. Meiner Meinung nach wäre es deutlich sinnvoller gewesen, dorthin Zeit zu investieren, statt in irgendwelche PDF-Engines.
Wenn du glaubst, daß deine Rechte durch diesen Weg verletzt werden, dann regel das mit dem, von dem du glaubst, daß er deine Rechte verletzt.
Mathias
Mathias Schindler wrote:
Insofern: Netter Versuch, und vermutlich die direktere Brockhaus-Konkurrenz, die möglich ist - aber darunter leiden die Vorteile, die das Internet sonst bietet.
Wikipedia war von anfang an als Druckwerk gedacht. Das hat nichts mit Konkurrenz zu tun. Weder zu Brockipedia noch zu Bröckelstein noch zu Wikipedia.
Wenigstens mittlerweile scheint das aber nicht mehr Hauptzweck zu sein, sonst wäre Ulis Weg tatsächlich der einzig richtige. Und jenseits von jeglichere Relevanz- oder Niveaudiskussion finde ich das auch gut: Durch die Festlegung auf das Internet als entscheidende Veröffentlichungsquelle bleibt genügend Platz für ausführliche Erklärungen, genügend Bilder, Gliederungen und flüssigen Text. Bei den exzellten Artikeln hat sich ja herausgestellt, dass Größe nicht mit Schwafelei verwechselt werden darf, manche Sachen tatsächlich besser mit Bildern zu erklären sind und es mehr Spass macht, flüssigen Text zu lesen als Enzyklopädie-Abkürzungs-Pseudotexte. Ganz abgesehen davon ist der Text im Internet (meinetwegen auch auf CD) besser erschlossen, einfacher zu durchsuchen und er erreicht komplett neue Bevölkerungsschichten, die sich sonst niemals irgendeine Enzyklopädie kaufen würden. Die gedruckten WikiReader haben natürlich auch ihre Berechtigung (und sollten noch weiter ausgebaut werden) - aber Hauptziel ist doch mittlerweile das Internet.
Wenn du glaubst, daß deine Rechte durch diesen Weg verletzt werden, dann regel das mit dem, von dem du glaubst, daß er deine Rechte verletzt.
Es geht mir gar nicht um meine Rechte - ich denke nur laut darüber nach, wie Uli sein Projekt verbessern könnte.
Matthias
Am Montag, 21. März 2005 07:53 schrieb Mathias Schindler:
Matthias Walliczek wrote:
Allein: Wer will das denn? Wenn ich eine gedruckte Enzyklopädie brauche, dann kaufe ich mir einen Brockhaus, aber drucke doch nicht 1000 Seiten selber aus?
Es gibt eine Erfindung namens Druckerei...
Das interessanteste an Wikipedia ist, dass es online verfügbar ist, und das man in den Artikeln genügend Platz hat, um normale Sätze zu formulieren, die vernünftig gegliedert werden können etc.
Das ist *ein* interessanter Aspekt an wikipedia.
Ein anderer wäre beispielsweise ein echtes Printing on demand mit ner echten Auflage Eins. Du brauchst ein Fachlexikon Wale? Ein Handbuch Projektmanagement? Ein Personenlexikon des Mittelalters? Kein Problem: Stelle die entsprechenden Artikel zusammen, klicke einen Knopf, und drei Tage später liefert Dir die Druckerei das Buch ins Haus, mit Ledereinband, Goldschnitt und Lesebändchen. Ach so: Enzyklopädie ist eine Sache. Aber es gibt Reiseführer, Kochrezepte, gemeinfreie Gedichte und vieles mehr, die man mit einem ähnlichen Prinzip erzeugen, zusammenstellen und verfügbar machen könnte. Nicht jeder will in jeder Situation einen Computer anschalten. Ich kann (zumindest im Prinzip) eine Vorlage aus beliebig kombinierbaren Einzelbausteinen liefern - und mit der Verfügbarkeit von Digitaldruckmaschinen (hier ein Fragezeichen) müsste die vollelektronisch durchgeführte Produktion und der Versand eines altmodischen, praktischen Buches eigentlich nur noch eine Frage der Automatisierungstechnik sein.
Wenn du glaubst, daß deine Rechte durch diesen Weg verletzt werden, dann regel das mit dem, von dem du glaubst, daß er deine Rechte verletzt.
Hast Du glaube ich falsch verstanden, so war's von Matthias nicht gemeint.
Uli
Ulrich Fuchs wrote:
Ein anderer wäre beispielsweise ein echtes Printing on demand mit ner echten Auflage Eins. Du brauchst ein Fachlexikon Wale? Ein Handbuch Projektmanagement? Ein Personenlexikon des Mittelalters? Kein Problem: Stelle die entsprechenden Artikel zusammen, klicke einen Knopf, und drei Tage später liefert Dir die Druckerei das Buch ins Haus, mit Ledereinband, Goldschnitt und Lesebändchen.
Dafür gibt es doch schon die Wikireader. Wahr ist: Das Zusammenstellen ist eben doch nicht so einfach, sondern erfordert einige Sachkenntnis, sonst stellt man erst bei der Lektüre fest, welche wichtigen Artikel fehlen. Wahr ist auch: Momentan ist es äußerst schwierig, die Wikireader manuell zusammenzustellen. Insofern wäre dein Redaktionssystem durchaus ein Gewinn - wenn es denn unter einer freien Lizenz erstellt worden wäre. Durch den Verzicht darauf verzichtest du auch auf viele helfende Hände, die ja auch Linux erst zu dem gemacht haben, was es jetzt ist.
Matthias
Nochmal hai,
At 17:40 21.03.2005, you wrote:
Ulrich Fuchs wrote:
Ein anderer wäre beispielsweise ein echtes Printing on demand mit ner echten Auflage Eins. Du brauchst ein Fachlexikon Wale? Ein Handbuch Projektmanagement? Ein Personenlexikon des Mittelalters? Kein Problem: Stelle die entsprechenden Artikel zusammen, klicke einen Knopf, und drei Tage später liefert Dir die Druckerei das Buch ins Haus, mit Ledereinband, Goldschnitt und Lesebändchen.
Dafür gibt es doch schon die Wikireader. Wahr ist: Das Zusammenstellen ist eben doch nicht so einfach, sondern erfordert einige Sachkenntnis, sonst stellt man erst bei der Lektüre fest, welche wichtigen Artikel fehlen. Wahr ist auch: Momentan ist es äußerst schwierig, die Wikireader manuell zusammenzustellen.
Ich denke, das wird auch weiterhin nicht zu umgehen sein, zumindest nicht, wenn man inhaltlich aufeinander abgestimmte Artikelsammlungen produzieren will. Eine Software kann zwar schön Artikel nach einem vorher festgelegten Algorithmus zusammenstellen, etwa von A-Z, aber spätestens wenn eine wie auch immer geartete Systematik oder Ordnung eine Rolle spielt ist die Software hilflos. Wie etwa soll ein automatisch generiertes Fachlexikon über Wale aussehen? Der einzig logische Aufbau ist eine phylogenetische Aufstellung, die eine Software schlicht nicht liefern kann. Was nützt einem eine alphabetisch sortierte Sammlung von Artikeln, wo dann der [[Pottwal]] beim [[Perrin-Schnabelwal]] und dem [[Peale-Delfin]] steht, der nahe Verwandte [[Kleinpottwal]] aber zwischen [[Kamerun-Flußdelfin]] und [[Kurzflossen-Grindwal]] und der [[Zwerpottwal]] sogar ganz hinten irgendwo beim [[Zwerggrindwal]] und den [[Zwergwale]]n. Ohne eine Person, die diese Artikel systematisch ordnet macht die Sammlung also gar keinen Sinn. Der einzige Arbeitsvorteil wäre dann also eine softwareunterstützte Layouthilfe.
Insofern wäre dein Redaktionssystem durchaus ein Gewinn - wenn es denn unter einer freien Lizenz erstellt worden wäre. Durch den Verzicht darauf verzichtest du auch auf viele helfende Hände, die ja auch Linux erst zu dem gemacht haben, was es jetzt ist.
Wofür helfende Hände, es gibt Leute, die können viel besser alleine arbeiten. Dann kann es auch nicht passieren, dass andere nicht nach den eigenen Vorstellungen denken und handeln. Der Nachteil: Man findet niemanden, dem man die ganze Scheiße anlasten kann, wenn sie in die Hose geht.
Gruß, Achim
Achim Raschka wrote:
Dafür gibt es doch schon die Wikireader. Wahr ist: Das Zusammenstellen ist eben doch nicht so einfach, sondern erfordert einige Sachkenntnis, sonst stellt man erst bei der Lektüre fest, welche wichtigen Artikel fehlen. Wahr ist auch: Momentan ist es äußerst schwierig, die Wikireader manuell zusammenzustellen.
Ich denke, das wird auch weiterhin nicht zu umgehen sein, zumindest nicht, wenn man inhaltlich aufeinander abgestimmte Artikelsammlungen produzieren will. [...] Der einzige Arbeitsvorteil wäre dann also eine softwareunterstützte Layouthilfe.
Exakt das meine ich: Das Zusammenstellen muss natürlich ein Experte von Hand machen - aber es muss eben ein Experte machen und es kann nicht mal eben ein interessierter Leser machen. Aber nach den Berichten hier ist das Layout und die PDF-Erzeugung eben doch noch etwas problematisch und zeitaufwändig - und da könnte Ulis System vielleicht helfen.
Matthias
Am Montag, 21. März 2005 06:54 schrieb Matthias Walliczek:
Mathias Schindler wrote:
Wenn man tatsächlich wikipedia drucken will, wäre sein Weg sicher ein möglicher
Allein: Wer will das denn? Wenn ich eine gedruckte Enzyklopädie brauche, dann kaufe ich mir einen Brockhaus, aber drucke doch nicht 1000 Seiten selber aus?
Korrekt. Wenn Du aber mal den Themenkreis "Kostenrechnung" oder den Themenkreis "2. Punischer Krieg" geschlossen drucken möchtest, weil Du nur etwa 10 Seiten statt nem Laptop mitschleppen möchtest, um den ganzen Kram im Stadtpark in der Sonne liegend zu lernen, sieht die Sache anders aus.
Das interessanteste an Wikipedia ist, dass es online verfügbar ist, und das man in den Artikeln genügend Platz hat, um normale Sätze zu formulieren, die vernünftig gegliedert werden können etc.
Ich halte mittlerweile die (ursprünglich auch von mir befürwortete) Ausführlichkeit der Wikipedia für eines ihrer Probleme. Dieser informelle Styleguide verleitet zum Labern und zum Aufschwemmen der Artikel mit Bestandteilen wie ausführlichen Beispielen etc., die in einer Enzyklopädie nichts verloren haben. Wikipedia sollte ein Nachschlagewerk sein, kein Lehrbuch - die Artikel tendieren zunehmend Richtung Lehrbuch.
Beispielsweise beim Urheberrecht, wo Uli den "Standard" der Wikireader fortsetzt (alle Autoren am Schluss in einer langen Liste). Ob sich irgendeiner der professionellen Wissenschaftler (die ja die Zielgruppe sein sollen) damit zufrieden gibt, dass sein Name in einer "ferner liefen"-Liste auftaucht, ist fraglich.
Technisch gesehen kein Problem (in der Online-Anzeige erscheinen die Namen der fünf Hauptautoren unter der Artikelüberschrift). In der pdf-Version ist's ne Platzfrage, es macht wenig Sinn, hinter einen Zweizeiler noch zwei Zeilen mit den fünf Hauptautoren zu packen. Vermutlich wirds auf eine Mischung rauslaufen, bei der man Artikellänge und Anteil eines Autors kombiniert, um zu entscheiden, ob ein voller Name oder nur eine Nummer angedruckt wird.
Uli
Am Montag 21 März 2005 09:28 schrieb Ulrich Fuchs:
Ich halte mittlerweile die (ursprünglich auch von mir befürwortete) Ausführlichkeit der Wikipedia für eines ihrer Probleme. Dieser informelle Styleguide verleitet zum Labern und zum Aufschwemmen der Artikel mit Bestandteilen wie ausführlichen Beispielen etc., die in einer Enzyklopädie nichts verloren haben. Wikipedia sollte ein Nachschlagewerk sein, kein Lehrbuch - die Artikel tendieren zunehmend Richtung Lehrbuch.
Die Beispiele sind vermutlich für die vielzitierte Oma (die nie meine Zielgruppe war) und Personen, die die Fähigkeit abstrakt zu denken nicht besitzen (auch nie meine Zielgruppe gewesen).
-- Ivo Köthnig
At 09:58 21.03.2005, you wrote:
Am Montag 21 März 2005 09:28 schrieb Ulrich Fuchs:
Ich halte mittlerweile die (ursprünglich auch von mir befürwortete) Ausführlichkeit der Wikipedia für eines ihrer Probleme. Dieser informelle Styleguide verleitet zum Labern und zum Aufschwemmen der Artikel mit Bestandteilen wie ausführlichen Beispielen etc., die in einer Enzyklopädie nichts verloren haben. Wikipedia sollte ein Nachschlagewerk sein, kein Lehrbuch - die Artikel tendieren zunehmend Richtung Lehrbuch.
Die Beispiele sind vermutlich für die vielzitierte Oma (die nie meine Zielgruppe war) und Personen, die die Fähigkeit abstrakt zu denken nicht besitzen (auch nie meine Zielgruppe gewesen).
Zielgruppe ist ein gutes Stichwort. Natürlich würde es einem Informatiker vollkommen reichen, über eine ihn wenig interessierende Tiergruppe wie die Stachelhäuter ( http://de.wikipedia.org/wiki/Stachelh%C3%A4uter ) einen Artikel zu finden, der in Länge und Inhalt etwa folgendem entspricht:
" Die Stachelhäuter (Echinodermata) (von lat. echinatus = stachelig und gr. dermis = Haut) sind ein zu den http://de.wikipedia.org/wiki/DeuterostomierDeuterostomiern gehörender Tierstamm. Weltweit sind etwa 6.300 Arten der Stachelhäuter bekannt, womit sie die zweitgrößte Tiergruppe innerhalb der http://de.wikipedia.org/wiki/NeumundtiereNeumundtiere (Deuterostomia) nach den http://de.wikipedia.org/wiki/ChordatiereChordatieren (Chordata) bilden. Es handelt sich bei ihnen durchweg um Meeresbewohner, die bis auf wenige Tiefseearten reine Bodenbewohner sind. "
Reicht ein solches Stüblein aber auch dem biologisch Interessierten oder sogar dem Biologen? Im Prinzip will jeder etwas anderes lesen und eine Enzyklopädie sollte eine Thema so umfangreich wie möglich und zugleich auch für den Laien nutzbar abbilden. Aus dem Grunde gibt es eine Einleitung für den jenigen, der lieber ein Lexikon gegriffen hätte und einen ausführlichen Text für den Freund der Fachenzyklopädie, von einer Monographie im Sinne eines echten zoologischen Fachbuchs kann man aber noch lange nicht sprechen. An dem oben benannten Artikel arbeite ich im Moment und er ist noch nicht fertig, da imho noch eine ganze Menge über das innere Organsystem (speziell das Ambulacralsystem) fehlt sowie einiges zum Verhalten und zur Evolution bzw. zum erdgeschichtlichen Auftreten.
Stellt sich also die Frage: Aufgeblasen, too much für eine Enzyklopädie? Ich würde sagen too much für Brockhaus, aber wenn man meinen bisherigen Text mit dem Artikel der Encyclopaedia Britannica vergleicht bin ich an dessen Umfang noch lange nicht dran (auch wenn dort ein paar für mich als Zoologen nicht nachvollziehbare Dopplungen (Schwafeleien?) drin sind).
Dieses Beispiel lässt sich imho auf jedes Thema übertragen, sei es nun eine mathematische Konstante wie die [[Kreiszahl]], ein staatliches Organ wie der [[Bundestag]] oder ein brandenburgisches Bächlein wie das [[Pfefferfließ]]. Gerade Themen wie dem letzteren wird die Schwafelei gerne vorgeworfen, aber niemand wird gezwungen, sich mehr als die Einleituing durchzulesen und Freunde der Landschaftsbeschreibung und der Verknüpfung mit Landschaftspoesie haben an dem Artikel ihre Freude, rein enzyklopädisch.
Nen lieben Gruß von dem, der die Enzyklopädie mit fundierten Texten kaputtgemacht hat,
;O) Achim
Am Montag, 21. März 2005 10:41 schrieb Achim Raschka:
der [[Bundestag]] oder ein brandenburgisches Bächlein wie das [[Pfefferfließ]]. Gerade Themen wie dem letzteren wird die Schwafelei gerne vorgeworfen,
Formulierungen wie: "der Name des Fließes entstammt angeblich der Lautmalerei "es peperte so", womit der Klang des Fließes und der Mühlsteine ausgedrückt werden sollte" *sind* Schwafelei, haben in einer Enzyklopädie nichts verloren (sondern bestenfalls im Werbeprospekt der örtlichen Tourismusstelle, wo's nicht so drauf ankommt, ob's stimmt oder nicht) und sollten eigentlich jedem in's Auge springen, der darüber nachdenkt, sowas zum "exzellenten" Aushängeschild einer Enzyklopädie zu machen.
Uli
Ulrich Fuchs wrote:
Ich halte mittlerweile die (ursprünglich auch von mir befürwortete) Ausführlichkeit der Wikipedia für eines ihrer Probleme. Dieser informelle Styleguide verleitet zum Labern und zum Aufschwemmen der Artikel mit Bestandteilen wie ausführlichen Beispielen etc., die in einer Enzyklopädie nichts verloren haben. Wikipedia sollte ein Nachschlagewerk sein, kein Lehrbuch - die Artikel tendieren zunehmend Richtung Lehrbuch.
Eine der beiden historischen Haupt-Wurzeln der Enzyklopädie seit der Spätantike *sind* Lehr- und Bildungsbücher gewesen (Stichwort: Septem artes liberales), teilweise waren sie sogar explizit für den Schulgebrauch konzipiert (vgl. Rudolf Schenda, "Hand-Wissen", in: Tomkowiak (Hg.): Populäre Enzyklopädien, Zürich 2002). Zumindest bis hin zu den großen Konversationslexika ist die *Belehrung* ein expliziter Modus der Enzyklopädie.
Der andere Modus, der des Konsultierens, speist sich aus der anderen Wurzel der Enzyklopädie, also dem Wörterbuch. M.E. ist das Problem, das du ansprichst, weniger ein inhaltliches, als vielmehr ein (software-) technisches, nämlich: Wie kann man die die beiden Modi bei der Präsentation für den Endbenutzer sinnvoll trennen?
Wenn die Wikiedia-Artikel tatsächlich signifikant länger werden (als auf Makroebene nicht mehr überwiegend Breiten- sondern zunehmend auch Tiefenwachstum), benötigen wir einen Mechanismus, der dem Nachschlagenden die knappe Information (Definition plus x) und dem Mehr-Wissen-Wollenden den Hintergrund (kompletter Artikel) liefert. Denkbar wäre beispielsweise eine Untergliederung des Artikelfeldes wie sie in CMS-/ Redaktionssystemen à la Bricolage eingesetzt wird: Ein Feld für den Anreißer (Kurzinformation) und eins für den Rest.
Weiterhin wäre zu überlegen, dass aktuelle Lehrbücher systematisch aufgebaut sind, man bräuchte also einen ergänzenden Präsentationsmodus, der die hypertextifizierten Partikel zusammenführt (das bringt mich wieder zu dem alten K3-Problem). M.a.W. wäre eine Technik notwendig, um zumindest Artikelfolgen oder -sequenzen zu definieren; so etwas wurde auf Meta bereits vor längerer Zeit angedacht, aber nie implementiert.
MfG -asb
Agon S. Buchholz wrote:
Wenn die Wikiedia-Artikel tatsächlich signifikant länger werden (als auf Makroebene nicht mehr überwiegend Breiten- sondern zunehmend auch Tiefenwachstum), benötigen wir einen Mechanismus, der dem Nachschlagenden die knappe Information (Definition plus x) und dem Mehr-Wissen-Wollenden den Hintergrund (kompletter Artikel) liefert.
Warum Technik, wenn es auch anders geht? Die meisten Artikel sind doch so gegliedert, dass in der Einleitung zuerst die Definition + Kurzfassung des sonstigen Inhalts kommt und erst danach die ausführliche Darstellung.
Wenn man diese Gliederung beibehält bzw. bei allen Artikeln einbaut (und das wird bei der Exzellenten-Diskussion und im Review ja gemacht), dann kann jeder die Informationen finden, die er sucht.
Matthias
Matthias Walliczek wrote:
Warum Technik, wenn es auch anders geht? Die meisten Artikel sind doch so gegliedert, dass in der Einleitung zuerst die Definition + Kurzfassung des sonstigen Inhalts kommt und erst danach die ausführliche Darstellung. Wenn man diese Gliederung beibehält bzw. bei allen Artikeln einbaut (und das wird bei der Exzellenten-Diskussion und im Review ja gemacht), dann kann jeder die Informationen finden, die er sucht.
Darum geht es nicht; Uli beschrieb ein ganz anderes Problem, das Du so nicht lösen kannst, nämlich die Trennung zwischen den Komplexen "zentrale Information" und "Hintergrundinformation/ Gelaber". Uli beklagte die Zunahme von letzterem und artikulierte das Bedürfnis, die Komponente "zentrale Information" separat zu verwenden. Würde man Ulis Problem genau darauf reduzieren, wäre ein Fork m.E. nicht erforderlich, sondern eine kleine Modifikation der Software ausreichen.
Jeder Parser müsste raten, ob der definitorische Absatz einen, zwei oder mehr Absätze umfasst, oder man müsste per Konvention festlegen, dass der definitorische Abschnitt immer den gesamten Text bis zur ersten Überschrift umfasst etc.
So lange die Software kein semantisches Verständnis über die exakte Artikelstruktur hat, ist es unmöglich, gezielt auf Teile des Artikelbestandes zuzugreifen. Unabhängig von der o.g. Problemstellung hätte eine solche Trennung auch andere Vorteile, beispielsweise die Möglichkeit der vollautomatischen Generierung von thematischen Glossaren, beispielsweise basierend auf Kategorien.
MfG -asb
Wenn die Wikiedia-Artikel tatsächlich signifikant länger werden (als auf Makroebene nicht mehr überwiegend Breiten- sondern zunehmend auch Tiefenwachstum), benötigen wir einen Mechanismus, der dem Nachschlagenden die knappe Information (Definition plus x) und dem Mehr-Wissen-Wollenden den Hintergrund (kompletter Artikel) liefert. Denkbar wäre beispielsweise eine Untergliederung des Artikelfeldes wie sie in CMS-/ Redaktionssystemen à la Bricolage eingesetzt wird: Ein Feld für den Anreißer (Kurzinformation) und eins für den Rest.
Gute Wikipedia-Artikel haben dieses Feature: Ein Einleitungssatz für das extrem kurze Nachschlagen, dann ein Einleitungsabsatz für das kurze Nachschlagen. Dann folgt üblicherweise das erstemal ein Unterkapitel, ab da ist es für die Leute die es genau wissen wollen. Softwaremäßig müßte man dann also alles bis zum ersten == abgreifen und man hat die gewünschte Funktion.
Viele Gruesse
Philipp
Ulrich Fuchs wrote:
Technisch gesehen kein Problem (in der Online-Anzeige erscheinen die Namen der fünf Hauptautoren unter der Artikelüberschrift). In der pdf-Version ist's ne Platzfrage, es macht wenig Sinn, hinter einen Zweizeiler noch zwei Zeilen mit den fünf Hauptautoren zu packen. Vermutlich wirds auf eine Mischung rauslaufen, bei der man Artikellänge und Anteil eines Autors kombiniert, um zu entscheiden, ob ein voller Name oder nur eine Nummer angedruckt wird.
Na, das klingt doch schon sehr interessant.
Letztlich wären auch dieser Mechanismus für Wikipedia interessant - zumindest für die Wikireader.
Gäbe es die Option, deine gesamte Software unter einer freien Lizenz zu veröffentlichen, falls die Sache mit dem Fork scheitert? Oder sollen die Ideen und Überlegungen in diesem Fall mit dem Fork zusammen untergehen?
Matthias
Am Montag 21 März 2005 06:54, schrieb Matthias Walliczek:
(auch wenn ich im Detail einige Aspekte scheisse finde).
Beispielsweise beim Urheberrecht, wo Uli den "Standard" der Wikireader fortsetzt (alle Autoren am Schluss in einer langen Liste).
Dieser Standard war mal einer. Zumindes was aus Richtung necro und mir kommt wird nach jedem Artikel eine Auflistung der Autoren und Quellen beinhalten.
Auch für die Seriösität und Glaubwürdigkeit wäre es ein Gewinn gewesen, wenn über den Artikeln die Namen der Fachleute stehen würden.
Da der Leser eines Artikels nicht unbedingt erpicht darauf ist, die Autoren und Quellen erst einmal zu studieren um dann irgendwo einen Artikel zu finden, sollte eine Nennung am Ende des Artikels besser sein (wie es auch bei fast allen mit bekannten Fachzeitschriften der Fall ist).
Meiner Meinung nach wäre es deutlich sinnvoller gewesen, dorthin Zeit zu investieren, statt in irgendwelche PDF-Engines.
Mich würde brennend interessieren, was das eine mit dem anderen zu tun hat ... außer, dass die Autorenliste wie der Rest des Artikels mit der Engine gesetzt wird und natürlich erscheinen kann wo es der Betreiber des Programms gern hätte.
CU/2 Hartwin