Maintainer: Torsten Wöllert, Version 1, 22.12.2000	Druckversion
Projekt-Typ: halboffen	Tipp: Wer eingeloggt ist, kann eigene Kommentare korrigieren. Einloggen können sich Mitglieder
Status: Aktiv

Grundlegende Infrastruktur für die Encyclopaedia Aperta

(1) Die Infrastruktur für die Encyclopaedia Aperta besteht grob gesprochen aus zwei logisch voneinander getrennten Systemen, einem Laboratorium, in dem die Artikel der Enzyklopädie eingereicht, kommentiert, verändert, diskutiert und schließlich in einer bestimmten Form angenommen oder verworfen werden, und einem Verteilsystem, in dem die angenommenen Artikel ausschließlich konsultiert und kopiert werden können.

(2) Das Laboratorium bleibt ausschließlich den an der Encyclopaedia Aperta Mitwirkenden vorbehalten, das Verteilsystem kann dagegen von jedem benutzt werden. Praktischerweise sollten Möglichkeiten des Verteilsystems aber auch im Laboratorium zur Verfügung stehen, um auch "halbfertige" Artikel einfach unter den Mitwirkenden verteilen zu können. Bereits "fertige" Artikel sind dagegen im allgemeinen Verteilsystem verfügbar.

(3) Beide Systeme benutzen das Internet und stehen in enger Verbindung miteinander. Während die Anforderungen an das Verteilsystem sich nicht wesentlich von denen üblicher Dokumentendienste im Internet unterscheiden - außer vielleicht, dass kein Abrechunungs- und Passwortmechanismus benötigt wird, weil sämtliche zu verteilenden Informationen zur freien Nutzung kostenlos zur Verfügung stehen, dafür jedoch die Möglichkeit, den Quelltext ausgewählter oder auch aller Artikel herunter zu laden - sind die Anforderungen an das Laboratorium relativ speziell.

(4) Da es im Augenblick kein frei verfügbares System zu geben scheint, das für das Laboratorium unkompliziert benutzt werden könnte, sollen die funktionalen Anforderungen hier dargestellt werden. Ziel ist es, eine Plattform für das Laboratorium Encyclopaedia Aperta zu schaffen, die durch die GNU General Public License in ihrer Freiheit geschützt ist und deshalb auch anderen Freien Software- Projekten zur Verfügung steht.

(5) Soweit es geht, sollte bereits bestehende Freie Software benutzt und wenn nötig erweitert werden. Deswegen werden im Folgenden auch Hinweise zu artverwandten Projekten gegeben, die womöglich von Interesse sein könnten. Die Verwendbarkeit der in deren Rahmen entwickelten Software bleibt aber noch zu prüfen.

Nutzer des Laboratoriums

(6) Wichtige Nutzer des Laboratoriums sind die Verfasser, die regelmäßig Artikel zur Encyclopaedia Aperta beisteuern. Sie bevorzugen es normalerweise, ihre gewohnte Arbeitsumgebung so einzurichten, dass das bei der Encyclopaedia Aperta benötigte Format einfach erzeugt werden kann. Sie werden also in der Regel ihre Artikel bereits im richtigen Format ins Laboratorium einbringen wollen.

(7) Für Verfasser dagegen, die nur gelegentlich Artikel beisteuern, lohnt sich der Aufwand zur entsprechenden Anpassung ihrer Arbeitsumgebung nicht. Sie werden ihre Artikel in einem der gängigen von Textverarbeitungsprogrammen erzeugten Formaten ins Laboratorium einbringen wollen.

(8) Kommentatoren von Artikeln können auf drei Weisen vorgehen. Entweder sie laden den zu kommentierenden Artikel vom Laboratorium herunter, erstellen eine neue, kommentierte Version und laden diese wieder ins Laboratium. In diesem Falle haben sie ähnliche Bedürfnisse wie Verfasser. Oder sie wollen den betreffenden Artikel direkt im Laboratorium kommentieren. Oder sie möchten ganz einfach mit dem Autor Kontakt aufnehmen, um ihm ihre Kommentare direkt mitzuteilen.

(9) Lektoren haben ganz ähnliche Bedürfnisse wie Kommentatoren, nur dass sie für ein bestimmtes Sachgebiet eine gewisse Verantwortung übernommen haben und somit über die Geschehnisse in diesem Gebiet unterrichtet sein möchten. Außerdem werden sie sich gegebenenfalls mit anderen Lektoren bzw. Moderatoren abstimmen wollen, bevor sie das Resultat ihrer Arbeit öffentlich machen.

(10) Moderatoren habenen über die Tätigkeit von Lektoren hinaus die Aufgabe, über die Aufnahme oder Ablehnung eines Artikels sowie seine Einordnung in die Encyclopaedia Aperta zu entscheiden. Dafür müssen sie sich mit anderen Moderatoren bzw. Lektoren abstimmen können und eine Arbeitsumgebung für die Bestimmung der zur Einordnung des Artikels dienenden Metadaten zur Verfügung haben.

(11) Übersetzer sind einerseits Verfasser, haben aber andererseits auch spezielle Bedürfnisse. Sie wollen vor allem wissen, welche Artikel in den sie interessierenden Gebieten und den von ihnen bearbeiteten Sprachen noch nicht übersetzt sind, aber auch ob sie vielleicht schon von einem anderen Übersetzer bearbeitet werden. Wenn die Übersetzung fertig ist, benötigen sie auch Informationen darüber, ob der betreffende Artikel in der Ausgangssprache in einer neuen Version vorliegt und gegebenenfalls welche anderen Übersetzungen davon angefertigt wurden.

Allgemeine Anforderungen

(12) Das Laboratorium sollte prinzipiell allen Nutzern zur Verfügung stehen, die über einen Anschluss ans Internet verfügen. Da es sich bei der Encyclopaedia Aperta um ein weltweites Projekt handelt und Interessierte aus benachteiligten Gebieten ausdrücklich zur Mitarbeit gewonnen werden sollen, sollte die Nutzung des Laboratoriums möglichst niedrige Ansprüche an die Ausstattung mit Hardware, Software und Netzinfrastruktur stellen.

(13) Die Nutzung des Laboratoriums sollte keine Folgekosten z.B. in Form von Lizenzgebühren voraussetzen oder nach sich ziehen. Deswegen sollten nur Freie Formate und Freie Software verwendet werden.

(14) Das Laboratorium sollte rund um die Uhr zur Verfügung stehen, um nicht Mitwirkende aus bestimmten Regionen der Welt zu benachteiligen.

(15) Der Nutzer des Laboratoriums sollte die Sprache der Benutzeroberfläche auswählen können. Deswegen dürfen sprachspezifische Elemente nicht fest programmiert sondern sollen als Variablen geführt werden, um eine spätere Aufnahme weiterer Sprachen zu ermöglichen.

(16) In das Laboratorium müssen vielfältige und einfach benutzbare Kommunikationsmittel integriert sein. Denkbar sind neben Newsgroups und Mailinglisten mit dazugehörigem Archiv auch Echtzeit-Kanäle wie IRC, Instant Messaging oder Internet-Telefonie. Eine Freemail-Adresse für jeden Mitwirkenden wäre ebenfalls wünschenswert. Jeder Mitwirkende sollte angeben können, auf welchen Kommunikationskanälen er erreichbar sein möchte (und auf welchen nicht).

(17) Jeder an einem Sachgebiet Beteiligte sollte über die gewählten Kommunikationskanäle Neuigkeiten wie neue oder angekündigte Artikel, Übersetzungen, Freigaben usw. beziehen können. Ebenso sollte er die Möglichkeit haben, sich ihn interessierende, aber nicht notwendigerweise unmittelbar zu seinem Sachgebiet gehörende Nachrichten zuschicken zu lassen.

(18) Es sollte eine Übersicht der verfügbaren Mailinglisten, Foren usw. existieren, von der aus man sich unkompliziert bei einzelnen oder mehreren dieser Kanäle anmelden kann. Ebenso sollte es eine Übersicht mit den Kanälen geben, bei denen man zur Zeit angemeldet ist und von der aus man sich unkompliziert bei einzelnen oder mehreren dieser Kanäle abmelden kann.

(19) Alle Kommunikation mit dem Laboratorium sollte verschlüsselt erfolgen, ohne jedoch Interessierte von der Kommunikation auszuschließen. Dazu sollte ein nichtkommerzielles https-Zertifikat o.ä. verwendet werden.

(20) Die Dateigröße von Artikeln sollte vor dem Laden getrennt nach Text, Ton, Bild, Video usw. angezeigt werden. Es sollte möglich sein, Artikel auch ohne schwergewichtige Bestandteile wie Videosequenzen herunterladen zu können, entweder als generelle Voreinstellung oder fallweise.

(21) Das Laboratorium sollte die Mitarbeit von Behinderten ermöglichen und entsprechend den einschlägigen Empfehlungen (siehe z.B. http://www.webable.com) gestaltet werden.

(22) Jeder Projektbeteiligte sollte freiwillig Auskunft über seine Person geben können und für jede dieser Angaben entscheiden können, ob sie nur den anderen Projektmitgliedern zugänglich sein soll, oder für alle, z.B. im Rahmen eines veröffentlichten Artikels in der Enzyklopädie.

(23) Es sollten umfangreiche Suchmöglichkeiten nach Stichwort, Autor usw. (Dublin Core Metadaten) mit Trefferliste und Exportmöglichkeit aller oder ausgewählter Treffer (z.B. Autor = Brockhaus 15. Auflage) bestehen. Es sollte angezeigt werden, wie viele relevante Artikel in der jeweiligen Sprache bereits vorhanden bzw. angekündigt sind.

(24) Der Export von Artikeln und Artikelsammlungen (z.B. komplette Bereiche oder komplette Trefferliste einer Suchabfrage, z.B. alle Artikel ab einem bestimmten Aufnahmedatum) sollte in verschiedenen Standardformaten wie HTML und TXT, sowie in DocBook XML möglich sein.

(25) Da die Encyclopaedia Aperta als internationales, lokal organisiertes Projekt, also dezentral, entstehen und gedeihen soll, sollte das Laboratorium dezentrale Arbeitsweisen weitestmöglich unterstützen (peer-to-peer). D.h. dass es viele lokale/regionale/nationale Laboratorien geben können sollte, die sich untereinander synchronisieren, Informationen austauschen und ressourcen- und zugriffsoptimiert speichern. So ist es z.B. unsinnig, wenn Artikel der japanischen Enzyklopädie auf Servern in Europa gespeichert werden. Bei einer Suchanfrage bei der italienischen Enzyklopädie nach allen verfügbaren Sprachversionen eines bestimmten Artikels müssen aber auch die Informationen über japanische Varianten einschließlich Links verfügbar sein.

Anforderungen von routinierten Verfassern

(26) Routinierte Verfasser werden in der Regel die Artikel in ihrer gewohnten Arbeitsumgebung erstellen, die inhaltliche Qualität und die Korrektheit des Formats (DocBook XML, ggf. mit Metadaten in RDF) überprüfen und das Ergebnis mit möglichst geringem Aufwand und ohne große Hilfestellung ins Laboratorium stellen wollen. Dafür ist eine Mailschnittstelle für Artikel geeignet. Gegenwärtig werden diesbezügliche Überlegungen bereits für das OpenTheory-Projekt entwickelt.

(27) Unabhängig vom Transportverfahren sollten Import und Export von Artikeln in DocBook XML, sowie Hochladen im Batch-Betrieb möglich sein. Dabei benötigt der Verfasser für jeden Artikel eine Empfangsbestätigung mit Informationen über den zugewiesenen Identifizierungscode bzw. die Adresse für einen Direktzugriff. Gegebenenfalls sollten Meldungen über Fehler im Datenformat erzeugt und dem Verfasser mitgeteilt werden, damit er seine Arbeitsumgebung verbessern kann.

(28) Neben diesen Möglichkeiten zur Arbeit offline sollten online auch Funktionen zum Ansehen eigener angekündigter Artikel und zum Editieren der Liste (hinzufügen, löschen, Termin ändern usw.) zur Verfügung stehen.

Anforderungen von gelegentlichen Verfassern

(29) Gelegentliche Verfasser benötigen dagegen eine umfangreiche Hilfestellung und verfügen in der Regel über keine Arbeitsumgebung, die die benötigten Formate zuverlässig und fehlerfrei erzeugen kann. Deshalb werden sie vorzugsweise online Artikel ins Laboratorium einbringen.

(30) Deswegen ist die Eingabe von "Standardartikeln" in Web-Formulare, mit Hochlademöglichkeit von einfach formatiertem Text und anschließender Editiermöglichkeit vorzusehen, wie bereits bei OpenTheory praktiziert.

(31) Die auf diese Art ins Laboratorium gebrachten Artikel sollten automatisch nach DocBook XML etc. umgesetzt und auf formale Korrektheit geprüft werden. Bei der Speicherung sollten angegebene Verweise (Links) auf andere Artikel und auf andere Teile des Artikels ebenfalls umgesetzt werden.

(32) Die Eingabe der Ankündigung neuer Artikel (Autor, Thema, Kurzbeschreibung, geplantes Datum usw. - ggf. Dublin Core Metadaten) in Web-Formularen sollte möglich sein.

(33) Dem Verfasser sollte eine umfangreiche Hilfe bei der Einordnung von Artikeln mittels Dublin Core-Metadaten über Auswahllisten, Eingabefelder usw. geboten werden (dieser Vorschlag wird dann vom Moderator des Sachgebiets bestätigt oder verändert). Dies sollte auch für angekündigte Artikel verfügbar sein.

Anforderungen von Kommentatoren

(34) Für Kommentatoren, die direkt neue Versionen von Artikeln erstellen wollen, wird eine ähnliche Funktionalität wie die des aus der Freien Software-Entwicklung bekannten CVS-Servers (Concurrent Version System) benötigt:

(35) Wer einen Artikel fortschreiben möchte, muß sich registrieren, um für andere Kommentatoren ansprechbar zu sein. Die Sammlung von Artikeln liegt in einem gemeinsamen Verzeichnis, dem Repository. Um mit der Arbeit zu beginnen, führt man den Checkout-Befehl aus, dem man den Verzeichnispfad oder den Namen des (Teil-)Artikels übergibt, an dem man arbeiten möchte. Das CVS kopiert dann die letzte Fassung der gewünschten Dateien aus dem Repository in einen Verzeichnisbaum auf der lokalen Festplatte. Der Kommentator kann diese Dateien nun mit einem Editor seiner Wahl verändern, die Korrektheit des Formats überprüfen und das Ergebnis testen. Ist er mit dem Ergebnis zufrieden, schreibt er es mit dem Commit-Befehl in das Repository zurück und macht damit seine Änderungen anderen Kommentatoren zugänglich. Die neue Version kann jetzt mit älteren verglichen, die Änderungen können herausgefiltert und mit den Änderungen anderer Kommentatoren verschmolzen, nicht mehr benötigte Dateien gelöscht und Information über Dateien abgefragt werden. Wenn andere Kommentatoren zur selben Zeit dieselben Artikel bearbeiten, werden die verschiedenen neuen Versionen lokal mit dem update-Befehl verschmolzen. Läßt sich das Ergebnis korrekt bauen, werden die verschmolzenen Dateien gleichfalls in den CVS-Baum zurückgeschrieben. Ist das nicht automatisch möglich, müssen sich die beteiligten Kommentatoren über die Integration ihrer Änderungen untereinander verständigen. Diese als copy-modify-merge bezeichnete Methode hat den Vorteil, kein Lock der Artikel zu erfordern, d.h. Texte, die gerade von einem Kommentator bearbeitet werden, sind nicht für alle anderen gesperrt.

(36) Für Kommentatoren, die direkt im Laboratorium Artikel kommentieren wollen, wird eine ähnliche Funktionalität wie bei OpenTheory benötigt, wo man nach jedem Absatz Kommentare einfügen kann, ohne dass sie jeweils in eine neue Version des Textes eingebaut werden. Dies bleibt dem Maintainer des Textes überlassen.

(37) Wenn ein Kommentator nur Kontakt mit dem Verfasser aufnehmen will, sollte das auf allen Wegen möglich sein, die der Verfasser zugelassen bzw. für die er seine Koordinaten hinterlegt hat.

Anforderungen von Lektoren

(38) Da Lektoren die Korrektheit und Lesbarkeit der Artikel überprüfen, sind sie natürlich an den Reaktionen und Fehlermeldungen der Leser interessiert. Dies lässt sich mit Bug Reports bei der Entwicklung Freier Software vergleichen, so dass auch hier bewährte Mechanismen aus diesem Bereich benutzt werden können.

(39) Darüber schreibt Volker Grassmuck (vgrass@rz.hu-berlin.de) in "Freie Software - Geschichte, Dynamiken und gesellschaftliche Bezüge" (Version 1.0, September 2000) auf Seite 58:

(40) "Wer z.B. in Debian GNU/Linux einem Bug begegnet, schickt einen eMail-Bericht darüber an submit@bugs.debian.org. Der Bug erhält automatisch eine Nummer (Bug#nnn), sein Eingang wird dem Anwender bestätigt und er wird auf der Mailingliste debian-bugs-dist gepostet. Hat der Einsender den Namen des Pakets, in dem der Bug aufgetreten ist, angegeben, erhält auch der Maintainer dieses Pakets eine Kopie. Betrifft der Fehler eines der in der Debian-Distribution enhaltenen selbständigen Pakete (XFree86, Apache etc.), erhalten auch die Zuständigen für dieses Projekt eine Kopie. In das "Reply-to"-Feld der eMail wird die Adresse des Einsenders und nnn@bugs.debian.org eingetragen, so daß die Reaktionen darauf an alle Interessierten in der Projekt-Community gehen. Übernimmt der Maintainer oder ein anderer Entwickler die Verantwortung für die Lösung des Problems, wird auch seine Adresse hinzugefügt. Er ordnet den Bug einer von sechs Dringlichkeitskategorien (critical, grave, important, normal, fixed und wishlist) zu. Gleichzeitig wird der Bug in die Web-basierte, öffentlich einsehbare Datenbank http://www.debian.org/Bugs eingetragen. Die Liste ist nach Dringlichkeit und Alter der offenen Bugs sortiert und wird einmal pro Woche auf debian-bugs-reports gepostet."

(41) Darüber hinaus wären frei verfügbare Rechtschreibprogramme zum Arbeiten sowohl online als auch offline, sowie Verweise auf Nachschlagewerke wie Wörterbücher, Rechtschreib-, Grammatik- und Ausdruckshilfen (style guides) sehr hilfreich.

Anforderungen von Moderatoren

(42) Neben den Werkzeugen für Lektoren benötigen Moderatoren einen gesonderten Zugriff auf die Metadaten zur Einordnung von Artikeln. Spezielle Werkzeuge z.B. zur Klassifizierung sollten online und offline zur Verfügung stehen und die Einordnung so effizient wie möglich machen. Dabei muss es möglich sein, Artikel in Gruppen zusammenzufassen und deren Metadaten gemeinsam zu bearbeiten. Es könnte interessant sein zu sehen, ob und inwieweit die vom Open Meta Archive (http://oma.orang.org) entwickelten Konzepte und Programme dafür benutzbar sind.

(43) Moderatoren sollen zu jedem Artikel aber auch zu übergeordneten Begriffe, zu denen kein Artikel existiert, Foren/Mailinglisten einrichten können, falls dies nicht bereits automatisch geschehen sein sollte. Es sollte für die Moderatoren einfach möglich sein, Foren/Mailinglisten zusammenzufassen und aufzuspalten und auch notfalls den Zugang zu beschränken, um eine Zerfaserung bzw. Unübersichtlichkeit der Diskussion zu vermeiden.

Anforderungen von Übersetzern

(44) Übersetzer sollten sich alle offenen möglichen Übersetzungen von Artiklen für die von ihnen gewählten Sprachpaare (z.B. welche französischen Artikel sind noch nicht in Deutsch übersetzt) anzeigen lassen können. Dabei sollte jeweils angezeigt werden, ob es ein Originalartikel oder bereits eine Übersetzung ist.

(45) Außerdem soll auf Anfrage angezeigt werden können, welche anderen Sprachversionen eines Artikels vorhanden bzw. angekündigt sind, welches jeweils die Originalsprache ist, und aus welcher Sprache der vorlegende Artikel übersetzt worden ist.

(46) Übersetzer benötigen eine Anzeige, dass in der Originalsprache eine neuere Version als die bereits übersetzte vorhanden ist, und möglichst eine Benachrichtigung per e- mail an die Übersetzer der vorigen Version(en).

(47) Ebenfalls sehr nützlich wäre die Möglichkeit einer Suche nach Übersetzungen, um sie dann komplett in Übersetzungsspeicher oder andere Werkzeuge laden zu können.

Weitere Anforderungen

(48) Außerdem sind weitere Anforderungen denkbar ... (bitte hier anhängen)