Benutzer Diskussion:Ben/Freie Bibelsoftware

Aus Die Offene Bibel

Wechseln zu: Navigation, Suche

Vision und Umsetzung[Bearbeiten]

Toll, dass bisher schon vier verschiedene Diskussionsteilnehmer mitgemacht haben. Das zeigt, dass wir bei der Offenen Bibel eine natürliche Affinität zu dem Thema haben. Ein Thema darf auf keinen Fall vernachlässigt werden, wenn diese Diskussion nicht theoretisch bleiben soll, sondern daraus tatsächlich etwas erwachsen soll: Die Umsetzung.

Meine Hoffnung ist momentan, dass eine gute, ausgereifte Vision eine Gruppe hochmotivierter Macher anziehen könnte. Hier könnten wir auf das kleine Netzwerk zurückgreifen, das die Offene Bibel schon hat, und weiter aktiv netzwerken. Reicht das noch nicht aus, könnte man über finanzielle Anreize a la Bountysource oder Crowdfunding nachdenken. Eine Vision und initiatives Planen vorausgesetzt, ist es zumindest vorstellbar, dass das christliche Internet bereit wäre, etwas Geld in die Verwirklichung zu investieren. Ein Brainstorming zum Crowdfunding der Offenen Bibel hatten wir schonmal. Für das Markusprojekt haben wir es auch durch einen wohlwollenden Spender geschafft, für ein vergleichbares FOSS-Projekt finanzielle Mittel aufzutun.

Vorschläge, Korrekturen, weitere Gedanken von irgendjemandem? --Ben 20:24, 16. Feb. 2015 (CET)

Die 80:20-Regel[Bearbeiten]

Die 80:20-Regel ist eine Weisheit, die besagt, dass in vielen Fällen 20% der Umstände oder Maßnahmen für 80% des Resultats verantwortlich sind, während die restlichen 80% nur zu 20% des Resultat führen. Beim Schreiben eines Romans oder einer wissenschaftlichen Arbeit etwa gehen nur 20% der Arbeit in die Kerntätigkeit, das Schreiben an sich – 80% gehen in Überarbeitung, Recherche, etc. In vielen Kirchengemeinden übernehmen 20% der Gottesdienstbesucher 80% der Aufgaben, während die restlichen 80% eben nur 20% der Gemeindeaufgaben ausführen. Bei der Offenen Bibel könnte man auch sagen: 20% der aktiven Mitarbeiter machen 80% der Arbeit.

Diese Regel kann man beim Planen benutzen, um zu analysieren, welche 20% geplanter Maßnahmen 80% des gewünschten Effekts erzielen werden. Bei einem Programm läuft das auf die Frage hinaus: Welche Funktion wird den Durchbruch bringen, wird also zum Killer-Feature?

Ich glaube, dass wir den einen Faktor, der wesentlich für den Erfolg eines kostenlosen Bibelprogramms verantwortlich ist, schon identifiziert haben: Nämlich, ob die Community leicht eigene Module erstellen und dann aus einer großen Anzahl solcher Module wählen kann. Neben grundlegenden Programmfunktionen (s.u.: 1. Lesen/Vergleichen, 2. Suchen, 3. Grundlegende Wortforschung) sind also Inhalte, nicht Funktionen, der entscheidende Faktor.

In diesen Kontext übertragen, wäre eine große Modulauswahl also nicht verhandelbar. Aber sind das allein schon die 20%, die den Unterschied machen? Ich glaube nicht, weil das kein genügendes Alleinstellungsmerkmal gegenüber der Konkurrenz e-Sword und TheWord wäre.

Welche andere Funktion könnte dazu also beitragen?

  • Anständige Kanon- und Vershandhabung, wie weiter unten gewünscht?
  • Erweiterte Funktionen, die u.a. für Theologen interessant wären (ebenfalls s.u.)?
  • Flexible Handhabung von Dateiformaten – etwa indem man gleich die Nutzung von TheWord-Modulen möglich macht (und sich für Bibeln evtl. ein anderes Format sucht?)?
  • Design der Benutzer-Oberfläche und sauberes Funktions- und Bedien-Konzept, auch wenn man dann bei 0% beginnen müsste?
  • Vorher unzugängliche deutsche Inhalte, wie deutsche Wörterbücher und Grammatiken; möglicherweise Kommentare; oder eine maximal effektive Integration der Studienfassung/anderer OfBi-Elemente?

--Ben 21:02, 21. Feb. 2015 (CET)

Wie könnte man das herausfinden? Durch eine Umfrage? --Ben 17:50, 27. Feb. 2015 (CET)

Die Lean-Startup-Theorie besagt: durch Beobachtung des Nutzerverhaltens und indem man den konkreten Bedarf verifiziert. Jetzt ist bei Bibelsoftware der „Markt“ im wirtschaftlichen Sinne ziemlich irrelevant, aber man kann diese Methoden durchaus einsetzen, um Aufgabenstellungen zu identifizieren, die dringender einer Lösung bedürfen als andere. Auch könnte man recherchieren, welche Meinungen dazu bereits im Web zu finden sind, statt künstlich Umfrageteilnehmer zu rekrutieren. Eine Umfrage macht natürlich trotzdem sehr viel Sinn, gerade in den vielen christlichen Foren dürften sich Interessenten finden, mit denen man dann auch einen längeren Austausch beginnen könnte. --Skreutzer 14:06, 28. Feb. 2015 (CET)

Ideen, mögliche Funktionen[Bearbeiten]

Was wünschen sich Theologen mögliche Nutzer, also Laien wie Theologen?

Wer ist überhaupt die Zielgruppe? Sind es nur Theologen? Oder primär Theologen? Was ist mit "normalen" Gläubigen, die kritisch denken und die gehörten Sonntagslesungen nochmals in einer anderen Bibelausgabe nachlesen und vergleichen möchten? --mihi 16:39, 15. Feb. 2015 (CET)

Völlig richtig. Mann, war das chauvinistisch von mir. Der Denkfehler war: Normale Leser sind mit grundlegenden Funktionen gut bedient oder können dieselben Funktionen benutzen wie "Theologen". Aber das muss ja nicht stimmen. Und noch wichtiger: Es sind wohl die normalen Leser (von denen es einfach mehr gibt), die den Grundstock einer Community bilden würden.

Da wir hier bisher nicht mehr tun, als zusammen nachzudenken (und im besten Fall etwas Schwung zu sammeln), muss die Frage frei diskutiert werden. Für mich wären fortgeschrittene Funktionen schon deshalb wünschenswert, weil es bisher noch nichts vergleichbares gibt. Zu MS Office, zu Photoshop, Browsern oder Programmierumgebungen gibt es hoch komplexe Open-Source-Alternativen. Bei der Bibelsoftware sieht es im Vergleich dazu relativ düster aus. Mein Leitgedanke wäre also: Komplexität muss Zugänglichkeit nicht ausschließen, Zugänglichkeit darf aber kein Nachgedanke sein. --Ben 21:16, 15. Feb. 2015 (CET)

Kanonbeschränkung[Bearbeiten]

Was mich als Katholik persönlich am meisten stört, ist die Beschränkung vieler Bibelprogrammme (auch theWord fällt, trotz des Erfolgs, darunter) auf den protestantischen Kanon. Aus protestantischer Sicht deuterokanonische Schriften sind in theWord-Modulen nicht enthalten, und lassen sich (aufgrund technischer Beschränkungen) auch nicht bei selbst konvertierten Bibeln ergänzen. Da diese Schriften aus katholischer Sicht nicht "besonders" sind und auch wie andere Schriften in Sonntagslesungen zu etwa 3% (und auch in Werktagslesungen) vorkommen, fällt das beim Vergleich mit anderen Bibelausgaben besonders auf (auch wenn diese Bibelausgaben im Original die deuterokanonischen Schriften enthalten haben, sind sie in Versionen, die man im Internet findet, häufig nicht mehr vorhanden).

In eine ähnliche Richtung geht die (Un-)Fähigkeit vieler Bibelprogramme, mit umsortierten Versen umzugehen (z. B. 2.Kön 20 hat in der Einheitsübersetzung die Verse in der Reihenfolge ..., 6, 8, 9, 10, 11, 7, 12, ...). Da die (für Katholiken aus dem Gottesdienst bekannte) Einheitsübersetzung in insgesamt 68 verschiedenen Kapiteln [wenn jemand Details will, kann ich die gerne nachliefern] davon Gebrauch macht, fällt es doch relativ bald auf, wenn man in Onlinebibeln wie bibleserver.com liest, die diese Umsortierungen "zurücksortieren". Hier gibt es einen einfachen Workaround (die Verse in die falschen Verse zu packen und davor als Text die richtigen Nummern zu setzen), was in der Praxis ausreichend gut funktioniert und höchstens beim Vergleich mehrerer Bibelausgaben auffällt (und da wiegt die unterschiedliche Versifikation unterschiedlichsprachiger Bibelausgaben definitiv schwerer als diese paar umsortierten Verse), daher ist mir der Punkt nicht so wichtig wie der vorherige.

--mihi 16:55, 15. Feb. 2015 (CET)

Das mit der Kanonbeschränkung ist tatsächlich frustrierend! Auch wer ernsthaft mit Septuaginta oder Vulgata (alten griechischen und lateinischen Bibeln) arbeiten will, braucht mehr als nur den protestantischen Kanon. Das müsste man wohl gleich im Modulformat berücksichtigen, oder? SWORD hat übrigens die gleichen Einschränkungen für Bibelmodule.

Umsortierte Verse sind nur ein Aspekt der ganzen Situation mit abweichenden Verssystemen. Die gibt es zwischen englischen und deutschen sowie im AT zwischen den hebärischen und griechischen Schriften. Das einzubauen, wäre vermutlich eine ziemliche Herausforderung, oder? Mir ist kein freies Projekt bekannt, das das wirklich geschafft hat. (Den Versuch hat mal Verity unternommen, aber das war ziemlich schnell tot. Auch TheWord macht das m.W. noch nicht!) --Ben 21:16, 15. Feb. 2015 (CET)

Naja, freie Software ist nichtdiskriminierend, sodass allerlei verschiedene Kanons und Verszählungen nicht verhindert werden können. Gleichzeitig müssen sie aber auch nicht aktiv unterstützt werden von Leuten, die einen anderen Kanon oder eine andere Verszählung bevorzugen. Nach meiner Einschätzung wäre es darum nicht verkehrt, Module einfach neutral zu sammeln und dafür zu sorgen, dass seitens verarbeitender Software genügend Flexibilität vorhanden ist, damit keine Abspaltungsprojekte entstehen, welche Kapazitäten zerstreuen und ultimativ zu inkompatibler Entwicklung, gar zu einem Verlust der Arbeit eines ganzen Abspaltungszweigs führen können, nur weil z.B. die Verszählung unterschiedlich ist. Man könnte das alternativ auch datengetrieben organisieren, oder hinter APIs verbergen/wegabstrahieren, oder formale Definitionen der verwendeten Einteilung und Bestandteile sowie Mappings zwischen verschiedenen Definitionen vorsehen, die aber dann freilich auch von den jeweiligen Interessensgruppen selbst hervorgebracht und gepflegt werden müssen. Sofern sie aber da sind, gibt es keinen Grund, weshalb sie nicht unterstützt werden sollten. Die digitalen Grundrechte des Nutzers erlauben diesem jedenfalls, Programme den eigenen Anforderungen gemäß anzupassen, und davon muss man schließlich selbst oft genug oder kollektiv Gebrauch machen können, wie andere Leute das eben auch tun werden.

--Skreutzer 23:30, 15. Feb. 2015 (CET)

Alternative Kanon und Verssysteme in SWORD: [1]. --Patrick 23:50, 15. Feb. 2015 (CET)

Große Liste unterschiedlicher Verssysteme (als XML-Dateien): https://github.com/openscriptures/BibleOrgSys/ --mihi 20:28, 21. Feb. 2015 (CET)

Cool! Welche Optionen hätte man bzgl. des Formats, wenn man diese Sachen richtig machen möchte? --Ben 17:50, 27. Feb. 2015 (CET)

DRM[Bearbeiten]

Was sicherlich auch zum Erfolg von theWord (und vermutlich auch e-Sword) beigetragen hat, ist die Unterstützung für restriktiv lizenzierte, kommerzielle Module, die mit DRM und Restriction Policies (z. B. maximal 20 Verse auf einmal kopierbar) versehen werden können.

Na, das ist aber halt die Frage, wie denn der „Erfolg“ von theWord dann definiert ist. Wenn es um die reine Verbreitung geht, haben besagte Aspekte bestimmt zum „Erfolg“ nicht unwesentlich beigetragen, insgesamt gesehen ist theWord aber gerade wegen der restriktiven Lizenzierung und der DRM-Unterstützung ein fataler Fehlschlag für die Bibel-Welt insgesamt. Wenn selbst heute noch, wenn auch nur beispielhaft, nicht mehr als 20 Verse einer Übersetzung auf einmal kopiert werden dürfen, dann ist das ein deutliches Zeichen dafür, dass wir die letzten ca. 300 Jahre an der Stelle keinen Fortschritt gemacht haben, sondern einen signifikanten Rückschritt. In der Zeit des Buchdrucks, des Mittelalters und der Antike war der Bibeltext freier als im Zeitalter der Digitaltechnologie. --Skreutzer 23:50, 15. Feb. 2015 (CET)

Dies stellt natürlich ein Dilemma für freie, quelloffene Software unter liberalen Lizenzen dar, da einerseits Verlage Bedenken haben könnten, dass die Restriction Policies "durchsetzbar" sind (ok, das sind sie bei closed-source-Software auch nicht, sobald ein Jugendlicher die paar Stunden Zeit gefunden hat dem Programm mit einem Debugger auf den Leib zu rücken, aber das ist ein anderes Thema); andererseits schreckt allein der Support für DRM-basierte Inhalte einige "extremistische" oder "ideologische" Free-Software-Verfechter ab, so dass sie die Software dann gar nicht erst benutzen wollen/würden (auch nicht mit freiem Content).

Ja, ich z.B. kann auf solche Verlagserzeugnisse und Software gut verzichten, da ist nämlich selbst geschenkt noch zu teuer, es kostet nämlich die Freiheit und Unabhängigkeit und steht überdies im Widerspruch zu dem, was der Text über sich selbst sagt. --Skreutzer 23:50, 15. Feb. 2015 (CET)

Eine Möglichkeit, diesen Spagat zu bewerkstelligen, wäre möglicherweise ein "Open Core"-Modell: es gibt eine quelloffene Basisversion und eine davon abgeleitete proprietäre Version, die dann die entsprechenden DRM-Möglichkeiten bietet.

Und wozu soll die proprietäre Version gut sein, wenn es doch eine freie Version davon gibt? --Skreutzer 23:50, 15. Feb. 2015 (CET)

Allein die Möglichkeit von DRM reicht aber auch nicht, es müsste auch einen funktionierenden und für Normalsterbliche bedienbaren Store geben, wo die Module erworben und aktiviert werden können. (SWORD bietet auch DRM, aber bisher weiß ich gerade mal von einem kommerziellen Modul, "Hoffnung für alle", und wenn man in diverse Foren sieht, scheinen die mehr Probleme zu machen als zu funktionieren).

Ganz konkret möchte ich auch noch anmerken (damit das ganze keine theoretische Spekulation bleibt) dass ich, als ich mir 2007 das MfChi-Modul der Einheitsübersetzung gekauft hatte, vor hatte, meine anderen (freien) Bibelmodule dort auch zu importieren. Zumindest damals gab es aber keine (einfache) Möglichkeit dafür, so dass ich meine anderen Bibeln dort nicht importieren konnte. Hätte es diese gegeben, würde ich heute vermutlich immer noch MfChi nutzen (wenn es unter Windows 7 noch zum Laufen zu bekommen ist). --mihi 17:53, 15. Feb. 2015 (CET)

Fang mir gar nicht erst an mit SWORD. Das ist furchtbar. :-) DRM könnte auch, machen wir uns nichts vor, ein wichtiger Baustein zur Finanzierung sein, und zum Erfolg des Projekts sowieso. Dein Vorschlag ist echt interessant. Das müsste man mal durchdenken, wie man das Dilemma lösen kann. Ich glaube, es gibt tatsächlich noch kein besseres FOSS-Beispiel als SWORD. --Ben 21:16, 15. Feb. 2015 (CET)

Finanzierung von wem oder was? Mal ganz davon abgesehen, dass DRM auch einiges kostet. Gar nicht so sehr in der Entwicklung, aber hinsichtlich des oben erwähnten Stores. Wenn man da dann diverse Formate und Apps und Software abdecken will und den Abgriff verhindern muss, gleichzeitig aber bestimmte Leute mit bestimmten DRM-Schlüsseln und einer Anzahl von Geräten manches dürfen und manches nicht (übrigens völlig unabhängig von der tatsächlichen Rechtslage, DRM ist ein einziges Wunschkonzert ins Blaue hinein), wird das schnell kompliziert. Wenn das Geschäftsmodell darauf beruht, Zugang und Verfügbarkeit künstlich zu verknappen, dann ist das kein Geschäft, sondern für diese Art von Werken eine Sauerei. Wenn das Geschäftsmodell darin besteht, etwas verkaufen zu wollen, was jedermann mit seiner Computertechnik zum Nulltarif millionenfach zur Verfügung stellen kann, hat man kein Geschäftsmodell. Erstaunlich, hierzu Cory Doctorow bemühen zu müssen... --Skreutzer 00:05, 16. Feb. 2015 (CET)

Skreutzer, lass uns doch nicht gleich die Geschütze auspacken, sondern herzlich bleiben. :-) Denken wir daran, bei einem Brainstorm müssen Differenzen oder Denkfehler erlaubt sein, sonst würgt das die Kreativität ab. Hier treffen definitiv schon Meinungen aufeinander! Für die grundsätzliche Möglichkeit "kaufbarer" Elemente sprechen zwei Aspekte: 1. Der Wunsch der breiten Nutzermasse, der ziemlich offensichtlich ist, und der das Programm hervorheben könnte. 98% der Nutzer werden sich um inhaltliche Qualität mehr scheren als um Details der Lizenzierung. Und zweitens die Option, das Programm so (mit) zu finanzieren. Eine Finanzierung könnte beispielsweise (wie bei elementary OS) über ausgelobte Preisgelder für Features/Fixes geschehen. Oder, wenn man groß denkt, wie bei vielen Linux-Distributionen durch eine Firma.

Niemand hat etwas gegen die Kaufbarkeit von Modulen und Software, ganz im Gegenteil, kommerzielle Verwendbarkeit gehört für Werke von praktischem Nutzen mit zu den digitalen Grundrechten, gerade bei Bibeltexten muss man regelmäßig für die Vorteile im Hinblick auf die Verbreitung und qualitative Verbesserung werben. Was aber nicht geht, ist, das exklusiv zu machen und/oder auf Kosten der Freiheiten und der Unabhängigkeit des Käufers. Die inhaltliche Qualität eines Werks, welches die Nutzer aus lizenzrechtlichen Gründen niemals erhalten werden, spielt keinerlei Rolle. Nur in unserer gut ausgestatteten westlichen Welt scheint es fast so, als ob man sich um die rechtliche Thematik nicht groß scheren bräuchte, weil ja genügend pseudo- und unfreie Ressourcen an jeder Ecke zu haben sind, sodass da vermeintlich keine Knappheit herrscht (Illusion des Überflusses) und man stets ausweichen kann. Webseitenbetreiber jedoch oder jeder, der die Bibel drucken möchte, muss dazu schon einen faulen Kompromiss eingehen, sich auf freie Module beschränken oder das Projekt aufgeben. Für freie Software und Medienwerke gibt's diverse Finanzierungsmodelle, man kann da auch deutlich experimentierfreudiger damit umgehen als im restriktiven Rechteverwertertum. --Skreutzer 00:59, 16. Feb. 2015 (CET)

Ich frage mich, ob man das nicht auch über verschiedene Paketquellen verwirklichen könnte. Wenn man proprietäre Formate und Schlüssel wie bei SWORD vermeiden möchte, könnte man das vielleicht über Nutzerkonten bei den bzw. eine Verschlüsselung der proprietären Paketquellen regeln? Ist jetzt nur ein Schuss ins Blaue, ich habe ja technisch nicht wirklich eine Ahnung, und das Konzept müsste man weiter durchdenken.

DRM (vernünftiges) ist technisch als assymetrische Verschlüsselung implementiert, was sozusagen die letzte ungebrochene, noch unbrechbare Bastion der Privatsphäre und Sicherheit darstellt (nicht nur für den Endbenutzer, auch für e-Commerce usw.). Man kann das Verfahren genausogut verwenden, um Software/Module zu signieren und deren Authentizität zu überprüfen, nur ist bei DRM das genau umgekehrt, dass nicht der Nutzer den entscheidenden Zugangsschlüssel hat, sondern der Anbieter. Wenn man ein Schloss an seinen Computer und seine Dateien anbringen lässt, ohne auch den Schlüssel dafür zu besitzen, dann ist das Schloss dort mit ziemlicher Sicherheit nicht zum eigenen Vorteil dort angebracht worden. Man lässt sich freiwillig künstliche technische Einschränkungen von einer fremden Partei auferlegen, die nach Gutdünken darüber verfügen kann, was sonst der Souveränität über die eigene Datenverarbeitung unterliegt. Schließlich hat man das Gerät gekauft und auch für die Software hat man Geld ausgegeben, aber statt nur ein einfaches, eingeschränktes, nicht übertragbares Nutzungsrecht für teuer Geld zu kaufen, könnte man stattdessen dasselbe Geld in Software investieren, die einem dann auch gehört und die frei ist von künstlichen rechtlichen wie technischen Restriktionen. --Skreutzer 00:59, 16. Feb. 2015 (CET)
Das ist natürlich wahr. Wie würdest du das denn lösen? --Ben 01:56, 16. Feb. 2015 (CET)
Du hast oben bereits ein paar Optionen aufgeführt: Auftragsarbeit, Crowdfunding, Subskription (regelmäßige Beiträge), und natürlich weiterhin der Verkauf (bei digitalen Gütern zahlen Käufer in erster Linie freiwillig oder für Bequemlichkeit). Vom Crowdfunding her sind ja wahrscheinlich „Dankeschöns“ bekannt, das wären dann Sonderausgaben oder Bonusmaterial, gerne auch physisch. (Online-)Dienstleistungen könnten ebenfalls gegen Entgelt angeboten werden. Sobald Geld von der Community ins Spiel kommt, sollte ultra-transparent dargelegt werden, was dafür umgesetzt wurde und wofür noch Geld fehlt. Wenn das nicht reicht, wäre alternativ noch viel mehr Mühe darauf zu verwenden, dass Leute möglichst einfach selbst etwas Zeit einbringen können, worauf sie dann auch hingewiesen werden sollten an all denjenigen Stellen, wo Mithilfe wünschenswert wäre. --Skreutzer 16:03, 22. Feb. 2015 (CET)

Ganz abgesehen davon: Proprietäre Elemente müssten vielleicht nicht gleich zu Anfang eine Sorge sein, solange man sich diese Option für später offen hält. Es scheint mir, dass Konzept und relevante Inhalte noch eher Schlüsselelemente wären. --Ben 00:18, 16. Feb. 2015 (CET)

Die Ablösung proprietärer Elemente muss die Hauptanliegen sein, sonst bräuchte man ja gar nicht antreten, weil jetzt schon alles in bester Ordnung wäre. Proprietäre Software und Module in bester Qualität gibt es genug, aber weder wir noch der Großteil der Menschheit wird jemals etwas damit anfangen können. --Skreutzer 00:59, 16. Feb. 2015 (CET)
Ich meinte natürlich "kaufbare Elemente innerhalb des Programms". --Ben 01:56, 16. Feb. 2015 (CET)
Gegen kaufbare Elemente innerhalb des Programms ist natürlich nichts einzuwenden. --Skreutzer 16:03, 22. Feb. 2015 (CET)

Funktionen, die bibelübersetzende Theologen interessant fänden[Bearbeiten]

Freie Bibelsoftware beherrscht bis auf wenige Ausnahmen genau drei Funktionen: 1. Lesen/Betrachten (von Karten, Bildern), einzelner oder mehrere Module; 2. Durchsuchen der Bibel; 3. Lexikalische Informationen erforschen (meist nur rudimentär).

Das ist zum "einfachen" Lesen der Bibel auch häufig ausreichend, aber in einigen Fällen bräuchte man als Theologe einige tiefer gehende Analysemöglichkeiten.

  • Wortstudienfunktionen (morphologische Analyse, Parallelstellen, tiefer gehende Lexika; vielleicht sogar Konzeptstudien und Verwendungsanalyse)
  • Erweiterter Textvergleich sowohl von verschiedenen Übersetzungen als auch von verwandten Bibelstellen.
  • Vielleicht sogar eine Syntax-Suche, aber das wäre äußerst aufwendig.

Dazu inhaltliche Funktionen, bei denen man überlegen könnte, ob eine Umsetzung irgendwie machbar wäre:

  • Wenn nicht aktuelle, dann zumindest brauchbare Schlüssel-Sekundärliteratur, d.h. Wörterbücher, Grammatiken und Kommentare.
  • Äußerst hilfreich wären Datenbanken mit Parallelstellen, Perikopenabgrenzungen, synoptischen Passagen usw. usf. und deren Integration in den Text, die Suche oder ein Exegese-Werkzeug.
  • Für Theologen unschätzbar wäre die Möglichkeit, eine Art integrierter, durchsuchbarer Aufsatzdatenbank für PDFs anlegen zu können. So könnte man PDFs mit relevanten Aufsätzen direkt im Programm mitbenutzen. Die Umsetzung wäre zweifellos eine Herausforderung.

Das sind erstmal meine Gedanken dazu. --Ben 21:16, 15. Feb. 2015 (CET)

PDFs?[Bearbeiten]

Für Theologen unschätzbar wäre die Möglichkeit, eine Art integrierter, durchsuchbarer Aufsatzdatenbank für PDFs anlegen zu können. So könnte man PDFs mit relevanten Aufsätzen direkt im Programm mitbenutzen. Die Umsetzung wäre zweifellos eine Herausforderung. --Ben 21:16, 15. Feb. 2015 (CET)

PDF ist hier wie überall sonst auch der Tod für Maschinenlesbarkeit und sollte außer im Print-Bereich eigentlich keine Rolle mehr spielen, leider sind viele Altbestände ganz vergleichbar mit Scans alter Bücher noch darin verbuddelt, und schlimmer noch, wird teils auch heute noch mit Print-First-Strategien fortgefahren. Damit tun wir weder uns noch unseren Mitmenschen noch der Nachwelt einen Gefallen, ganz im Gegenteil, es wird sich erneut jemand um die Digitalisierung solcher Dokumente kümmern müssen, wenn keine maschinenlesbare Fassung vorliegt und zugänglich ist. Bestehende alte PDFs und Scans könnte man aber trotzdem gut einbinden, bei neueren Publikationen soll der Herausgeber ein vernünftiges Format bereitstellen. --Skreutzer 00:13, 16. Feb. 2015 (CET)

Tatsache ist erstmal, dass ernsthafte Forschung nicht ohne PDFs geht. Fakt ist, dass 99,X% der digitalen wissenschaftlichen Werke als PDF und nicht anders zur Verfügung gestellt wird (der Rest ist HTML oder, ganz manchmal, epub). Mir ist klar, dass das kein ideales Format ist, aber man kann den Ist-Zustand auch nicht ändern.

Die Frage ist also nicht, wie gut PDFs sich eignen, sondern ob es realistisch ist, damit zu arbeiten. Ich will nicht gleich ein Denkverbot aufrichten. Wenn man eine Möglichkeit nicht prüft, wird man nie herausfinden, ob sie realistisch ist. Um dir mal ein Beispiel zu geben: Sogar bei Logos, wo die meisten Nutzer 1000e von Dollar in digitale Bibilotheken von 3- oder 4-stelliger Größe investiert haben und wo man relativ leicht persönliche Module einbinden kann, zählt PDF-Integration zu den meistgewünschten (aber kategorisch ausgeschlossenen) Funktionen. --Ben 00:24, 16. Feb. 2015 (CET)

Es spricht ja nichts grundsätzlich gegen PDFs, sofern die für den Druck verwendet werden. Wenn sie zur Betrachtung herangezogen werden sollen, wird es schon schwierig, weil PDFs auf feste Abmessungen ausgelegt sind, Anzeigeflächen und Displaygrößen sich aber unterscheiden. Interessant wäre, mal zu erfahren, warum Logos da keine Anbindung dafür macht, denn man könnte die Dokumente kontextsensitiv ja durchaus auflisten, eben gerade für den darauffolgenden Ausdruck. Bei der Anzeige im Bibelprogramm geht es dann aber schon los, mit besagtem o.g. Problem, und weil dann das nächste meistgewünschte Feature wird, aus den PDFs Text kopieren, markieren, annotieren usw. zu können, und dann sitzt man wieder genau in derselben Patsche der mangelnden Maschinenlesbarkeit. Für alte PDFs und Scans könnte dann gleich das Digitalisierungsinterface aufgehen, wenn da aber PDFs aus heutiger Produktion enthalten wären, müsste man sich echt an den Kopf langen. Dass der Wissenschaftsbetrieb mit seiner Praxis dieses Grab weiter schaufelt, ist bekannt, aber es gibt da auch einige Fortschritte, wenn man z.B. an Open Access denkt, in dem Zuge ist auch die Ausrichtung auf primär Print-Publikation zunehmend verhandelbar, weil ja auch die Bibliotheken mit öffentlichen Geldern Forschungsergebnisse aufkaufen sollen, deren Erarbeitung ebenfalls mit Steuergeldern finanziert wurde, nur mit einem restriktiven Rechteverwerter-Wissenschaftsverlag dazwischen, der die Rechte einbehält, die Gelder einstreicht und den Zugang zu diesen Resultaten künstlich verknappt (bis hin zu Skandalen wie der um Aaron Schwartz und JSTOR). --Skreutzer 01:06, 16. Feb. 2015 (CET)

Gerade Open-Access-Werke sind allesamt PDF. Auch die Literaturverwaltungsprogramme arbeiten alle mit PDFs. Blöd, aber nicht zu ändern! Ich vermute, Logos implementiert das Format erstens wegen der Formatschwierigkeiten nicht und zweitens, weil ihnen SEHR viele Einnahmen verloren gingen, wenn die Nutzer ihre eigene Bibliothek einbinden könnten. Vollkommen nachvollziehbar wegen der kommerziellen Zwänge.

Eine grundsätzliche Funktion zum Verwalten, Lesen und Durchsuchen wäre klasse. Darüber hinausgehende Funktionen könnte ja folgen lassen, wer den Wunsch dazu hat. Vielleicht wären andere auch der Meinung, dass man PDF-/Literaturverwaltung besser auslagert; gerade wenn man nichtakademische Benutzer mit ins Auge fasst. Ich weiß, dass ich über ein Bibelprogramm sehr glücklich wäre, das meine Zotero-Datenbank integrieren, durchsuchen und lesen könnte.

Eine andere Möglichkeit wäre eine indirekte Einbindung von Aufsatzsammlungen, z.B. indem man verfügbare Aufsätze/Bücher (durch eine Zotero-Datenbank? Eine Online-Open-Access-Bibliographie?) bibliographisch und durch Tags einbindet und dann extern öffnen kann. Dazu bräuchte man aber zumindest die Tags.

Digitalisierung mit OCR etc. kann ich persönlich mir noch eher in einem gesonderten (Schwester?-)Programm vorstellen. Das wäre ja noch einmal ein weiterer Komplexitätsgrad. --Ben 02:11, 16. Feb. 2015 (CET)

Nee, denn auch bei Open Access müssen die PDFs wie alle anderen PDFs auch ja irgendwoher kommen. Es ist schon richtig, dass auch bei Open-Access-Publikationen das Endergebnis dann als PDF in irgendwelche Repositories eingespeist wird sowie von Journalen in gedruckter Form in Umlauf gebracht wird, nur ist die doppelte Aufbereitung für Web/Print eine recht kostspielige und unnötige Angelegenheit, während die Repositories und Nutzer derselben immer höhere Webtauglichkeits-Anforderungen stellen, sodass man also zunehmend und erst Recht in Zukunft auf Single-Source-Publishing setzen wird, wo die Quelldaten zielformatneutral vorliegen, was auch jetzt schon bei den großen Verlagen ein ständiges Thema ist, weil die Online-Dienste und Mobilgeräte bedienen wollen/müssen, und da mit ihren PDFs für DIN A4 sowie printorientierten Quelldateien merken, dass sie dieselben Gelder nochmal investieren müssen, nur um zum selben Ergebnis, geschweige denn zu einem besseren, zu gelangen.

Verstehe ich das dann richtig, dass die Logos-Kunden mit dem Kauf von Logos-Bibliotheken dafür bezahlen, dass ihnen eine Software entwickelt wird, mit denen sie absichtlicherweise keine eigenen, sondern nur Logos-Bibliotheken einbinden können? Klingt sehr nach Arbeitsbeschaffungsmaßnahme ;-) Solange die Kunden das mitmachen...

Funktional gesehen könnte man ja durchaus mit einer rudimentären PDF-Unterstützung anfangen, und das dann, soweit eben möglich, ausbauen, während logischerweise maschinenlesbare Formate gleichzeitig ebenso und mehr unterstützt werden sollten. Außer, es lägen wirklich bereits große Bestände von vermutlich hauptsächlich gemeinfreien Scans vor, sodass also ein gewisser Nutzen aus deren baldiger Einbindung erwachsen würde.

--Skreutzer 16:28, 22. Feb. 2015 (CET)

Da bin ich ganz deiner Meinung. Das Format ist wirklich nicht optimal, aber es ist Realität. Ein weiterer Vorteil wäre, dass man aus Digitalisaten einfach PDF-Sandwiches machen und diese dann verwenden könnte.

Neinnein, man kann in Logos schon eigene Ressourcen einbinden, aber eben nicht als PDF. Das Programm hat wunderbare Datenbanken, exegetische Werkzeuge, kaufbare Werke und man kann damit extrem schnell sogar Handouts und Präsentationen zusammenstellen. Die Kunden kriegen also ausgesprochen viel für ihr Geld. :-)

Eine Qt-Technologie, die mit PDFs helfen könnte, wäre okular-part, ein ziemlich guter PDF-Viewer, der sich in andere Programme einbinden lässt. Einige Programme wie KBibtex oder das Firefox Kparts-plugin machen davon Gebrauch. --Ben 17:50, 27. Feb. 2015 (CET)

Eine interessante Funktion von Bibledit: Webseiteneinbindung[Bearbeiten]

Bibledit ist eigentlich kein Bibelprogramm, sondern eher ein einfaches Bibelübersetzungsprogramm. Man gibt den übersetzten Text ein und kann damit dann auch einige verschiedene Bibelmodule erstellen.

Eine Funktion des Programms hat mich jedoch fasziniert: Man kann darin Webseiten einbinden. Die werden dann einfach in einem Unterfenster geladen. Mit dieser Funktion könnte man sich allerlei spezialisierte Online-Programme quasi direkt in sein Bibelprogramm holen: Ob es das Wibilex ist, Wikipedia, eine Logos-Bibliothek über biblia.com, eine Aufsatzdatenbank wie biblicalstudies.co.uk, kommerzielle Bibelübersetzungen (z.B. mit bibleserver.com) oder youversion.com, vielleicht sogar ein Online-Bibelprogramm wie STEP?

In Bibleedit war der Effekt, dass man einerseits nicht Fenster wechseln und andererseits solche Seiten quasi an einem Ort sammeln konnte. Ob man Webseiten allgemein (oder Webdienste im Speziellen?) noch tiefer in ein Programm integrieren könnte, weiß ich nicht, und es hängt sicher auch von der gewählten Plattform ab.

Wollte diese Funktion nur mal vorstellen. Wie nützlich sie ist, ob sie sinnvoll wäre, ob sie sich anständig umsetzen und "maintainen" ließe, ist eine ganz andere Frage. :-) --Ben 21:19, 21. Feb. 2015 (CET)


People and Projects working on unchaining the Bible in the Digital Age[Bearbeiten]

The text in this section is early work in progress and licensed under GNU AGPL3 or later, CC BY-SA 3 and CC BY-SA 4. Do not modify or add to the following text of this section if you don't accept licensing it under the mentioned licenses, or if you don't own all necessary rights required by those licenses!

Tim Jore of Distant Shores Media laid important groundwork with his book “The Christian Commons”, which gives a problem description, elaborates on what digital technology changes for the creation and dissemination of christian works and suggests ways to solve the issue. One remarkable position of his is that we don't need so much to improve the wealth of works in the western world, but should care about the miserable situation for most language groups regardless of their size. On the other hand, he believes that artificial restrictions of christian works isn't unethical, which has to be disagreed and suggests he's more in favor for an Open Source than a Free Software approach. His book is licensed under CC BY-SA 3, and we still haven't found the time to translate it or even parts of it yet. If somebody wants a hardcopy of it, we will try to provide it, but also consider the EPUB and PDF version.

Open Scriptures operated by Weston Ruter came into existence after the German Bible Society threatened various sites including a much-appreciated bible study tool on zhubert.com. Since then, efforts continue to improve the interlinkage of data and Scripture. Unfortunately, many resources on the historical background vanished, maybe we should start to try to preserve them.

Freely-Given.org by Robert Hunt provides a collection of Bible texts in various formats, he has also developed several converters. Unfortunately, he's concerned about price, not liberty. The materials provided on his website need to be furtherly examined.