Umgekehrte Datenbank-Verknüpfung

[derjahn]

Aw: Umgekehrte Datenbank-Verknüpfung

Es ist vom technischen aufwand im Hintergrund her einfacher, den markierten Text in die Datenbank zu legen und in dieser Datenbank mit den Schlagworten zu verbinden,

als im Maunskript im Text Markierungen von…bis zu setzen und diese mit Verweisworten zu verknüpfen.

Uli mag mich eines besseren belehren.

Eine Datenbank funktioniert immer in beide Richtungen:

ich kann Text anklicken die Datenbank liefert die verknüpften Schlagworte aus oder ich gebe als Suche ein Stichwort und die Datenbank liefert den damit verbundenen Textabschnitt.

Der Arbeitsaufwand für den Autor ist genau derselbe:

er muss den Text selektieren und markieren und er muss das Suchwort vergeben und das Ganze dann abspeichern.

auf dem Notizzettel muss er die Noitz erstellen (abspeichern) und dann muss er sie bei Bedarf suchen und finden und dann händisch alle Änderungen, nachdem er sie im Text vorgenommen hat, dann NOCH EINMAL auf dem Noitzzettel aktualisieren. Bei der Datenbankvariante fällt dieser Arbeitsschritt ersatzlos weg.

Nochmal:

ein Kommentar ist eine beim Text (oder eben auch in einer Datenbank, denn nicht anders wird es praktisch umgesetzt) hinterlegte ZUSATZinformation, die NICHT im Text steht.

Die Personen und/oder Ereignisdatenbank (!) dienst dem Sammeln von Informationen, die dann beim Erarbeiten des Textes verwendet werden.

Der Zeitstrahl dient der chronologischen Sortierung.

Die hier gesuchte Funktion hat eine andere Aufgabe.

Ja, in der Benutzung ist es ein Sprung vom Schlagwort zur Textstelle.

Aber ich bekomme (um beim passenden Beispiel des Blogs zu bleiben) alle Textstellen angezeigt, die mit dem Suchbegriff verbunden sind - gleichzeitig (nacheinander aufgereiht, mit Zielhinweisen, wie Kapitel oder so).

Ich habe also alle betreffenden Textauszüge dargestellt und kann direkt vergleichen und ändern.

Ich muss nicht hin-und-herspringen.

Und wenn ich eine Änderung gespeichert habe, steht sie an der korrekten Stelle im Text.

Versteht ihr nicht, wie ein Blog funktioniert?

Ich verstehe nicht, wie man den Sinn des Ganzen nicht verstehen kann.

Ob man das braucht/habenwill, ist eine ganz andere Frage - da wird es viele Meinungen geben.

Aber den Sinn nicht zu verstehen, verstehe ich nicht.

[system]

Aw: Umgekehrte Datenbank-Verknüpfung

Eigentlich verstehe ich sogar ziemlich gut, wie ein (nehmen wir als Beispiel einmal einen gängigen WordPress-) Blog funktioniert. Dort ist es nämlich so, dass sämtliche Inhalte ausschließlich in der Datenbank vorliegen. Die Blogsoftware (Serverkomponente) in Verbindung mit dem Browser des Benutzers (meist ganz viel JavaScript + CSS) rendert daraus die Seiten. Was man im Browser sieht, ist also nur eine Sicht auf die Inhalte der Datenbank. Wenn ich die Inhalte verändern möchte, dann verändere ich die zuerst die Inhalte der Datenbank (über eine spezielle Pflegeseite) und erst danach kann ich mir die Seite im Browser mit den veränderten Inhalten ansehen. Es geht also immer nur in der Richtung Datenbank → Darstellung. Erst wenn ein Inhalt in der Datenbank ist, ist er auch für andere Benutzer (außer dem momentanen Autor) sichtbar. Außer auf dem Weg über die Datenbank gibt es keine Inhaltsänderungen.

Bei Papyrus ist das aber ganz anders. Hier ist der Text (der Inhalt) originär im Papyrus-Dokument gespeichert. Die Papyrus-Anwendung rendert also den Inhalt für den Benutzer indem sie das ganze Markup drumherum interpretiert und so den Inhalt für den Benutzer lesbar (und editierbar) darstellt.

Die Papyrus-Datenbank hat dagegen nichts mit dem Dokumenteninhalt zu tun. Das Dokument enthält den Inhalt, nicht die Datenbank. Allenfalls besitzt der Text Verknüpfungen zu Datensätzen der Datenbank, zeigt aber niemals direkt Inhalte aus der Datenbank an (außer bei Serienbriefen und Adressetiketten, hier pflegt man aber die Inhalte ausschließlich in der Datenbank und der Text selbst enthält nur einen Platzhalter. Es gibt keine Synchronisation Text → Datenbank). Das bemerkt man auch daran, dass man stets Dokumente mit Datenbanken verknüpfen muss, aber man aus einer Datenbank heraus keinerlei Bezug zu Dokumenten herstellen kann. Außerdem: Kommentare sind eben nicht in der Datenbank abgelegt sondern müssen ja auch ohne Datenbank funktionieren, sie sind also Teil des Textes. Das kann man sehr schön sehen, wenn man ein Papyrus-Dokument als RTF abspeichert und dann mit einem Texteditor öffnet. Neben dem eigentlichen Text sind dort jede Menge Metadaten im Markup hinterlegt: Formatierungen, Szenentitel, Autor, Kommentare, etc.

Für die Papyrus-(Schreib)Anwendung ist also das Papyrus-Dokument quasi die “Datenbank”. Als Analogie:

Blog (z.B. WordPress): Datenbank ist MySQL, die Anwendung ist eine Kombination aus PHP-Server und Browser

Papyrus: “Datenbank” ist das Papyrus-Dokument, die Anwendung ist die Papyrus.exe (genauer der Teil, der davon die Schreibanwendung darstellt, denn die Datenbankanwendung ist m.E. keine eigene .exe)

Um bei deinem Blog-Beispiel zu bleiben: Die geforderte Funktionalität bedeutet eine Zwei-Wege Synchronisierung zwischen Dokument und Datenbank. Ein programiertechnischer Albtraum. Das wäre so, als würdest du, zusätzlich zu der üblichen Weise über den Edit-Button eines Blog-Beitrags, im Browser den momentan angezeigten Seitenquelltext ändern wollen, und erwarten, dass sich daraufhin die Daten in der Serverdatenbank ändern. Genau so funktioniert ein Blog aber nicht, daher ist das Blog-Beispiel falsch.

Ich denke, ich habe die geforderte Funktionalität verstanden, was ich aber nicht verstehe, ist, warum ihr darauf beharrt, vorzuschreiben, wie man die Funktionalität umsetzen sollte, nämlich durch Speichern der Textinhalte in der Datenbank, wenn es doch, wie mehrfach in diesem Thread erwähnt, funktional äquivalente Lösungen gibt, die wesentlich einfacher zu realisieren wären.

Ulli möge mich korrigieren, wenn ich die Papyrus betreffenden Sachverhalte nicht richtig wiedergegeben habe.

[Ulli]

Aw: Umgekehrte Datenbank-Verknüpfung

Selbstverständlich “verstehen” die anderen wie ich den “Sinn” - wir bezweifeln ihn allerdings in seiner Produktivität.

Auch die technische Umsetzung ist - hier belehre ich dann wie gewünscht - viel komplexer. Vor allem aber für den Anwender, was das eigentliche “Verbraten” von sinvollerer verbrachter Zeit wäre.

Wir planen andere sinnvolle Dinge, die da mehr bringen, bessere Suchfunktionalität, bspw. Aber eine Datenbank-Verschlagwortung sehen wir nicht als wirklich hilfreich an - insbesondere für den Anwender in Sachen Kosten/Nutzen an Arbeitszeit und Gehirnschmalz wie auch an effektivem Nutzen.

[derjahn]

Aw: Umgekehrte Datenbank-Verknüpfung

sehr gern lasse ich mich belehren.

Am Ende wäre es mir schnurz, auf welche technische Weise das Ganze erledigt wird.

Ich finde die Funktionsbeschreibung wichtiger als die Diskussion um die technische Realisierung.

Wie viel Prozant der Autofahrer wissen, wie ein Motor funktioniert und wie die Energie in Fortbewegung umgesetzt wird und weshalb das Auto startet, wenn man den Schlüssel rumdreht…?!

Um beim Beispiel zu bleiben:

Ob ich im Backend im Editor einen text schreibe oder im Papyrus-Manuskript, ist egal - der Text wird erfasst und ggf später verändert.

Jetzt kommt es nur darauf an, dass ein gewünschter Textabschnitt markiert und mit Stichworten verknüpft werden kann und dass dieser Textabschnitt dann gemeinsam mit allen anderen Textabschnitten, die mit gleichen Stichworten versehen sind, aufgelistet (und dann auch direkt bearbeitet) werden kann.

Mir wäre es Jack wie Hose, ob das mittels Datenbank funktioniert.

Jedenfalls geht solche Funktionalität in einem RTF verloren, was kein Problem darstellt, da diese Funktion eine Arbeitshilfe sein soll und nicht zusätzliche Informationen, die man ggf dem Dokument mitgeben muss/will, damit ein Leser sie auch bekommt.

Ich halte eine separate Verwaltung der Textabschnitte in einer Datenbank für sinnvoll, da diese auch in einem neu verbundenen Importdokument (vielleicht eine vom Testleser bearbeitete Textversion) verknüpft werden könnte (der übereinstimmende Text kann ja wiedergefunden werden.

Und irgendwo muss ein/das Programm sich ja auch merken, welcher Text an welcher Stelle im Dokument und von wo bis wo reichender Abschnitt mit genau welchem Stichwort verbunden sein muss.

Also müssen zwei Dinge gespeichert werden:

das/die Stichwort/e und der/die Textabschnitt/e und dann müssen diese zwei Elemenete verknüpft und auf Abfrage ausgeliefert werden - DAS IST eine Datenbankfunktion par Excellence.

Aber wenn man das anders einfacher lösen kann, ist das natürlich eine tolle Sache.

Nochmal:

das “Totverwalten” halte ich für ein Totschlagargument, welches nicht stichhaltig ist, weil das eine sehr individuelle Geschichte ist, die mit Sichtweise, Gewohnheit, Tradition, Technikaffinität und Faulheitsgrad des Einzelnen zu tun hat.

Richteten wir uns nach den Zweiflern, rennten wir heute noch im Busch herum.

[Ulli]

Aw: Umgekehrte Datenbank-Verknüpfung

Richteten wir uns nach den Zweiflern, rennten wir heute noch im Busch herum.

Das genau sticht hier nicht. Technik-affin dürften alle sein, die gern mit Papyrus arbeiten. Dennoch ist gerade das Fokussieren der Technik aufs Wesentliche hierbei der entscheidende Punkt.

Das Arbeiten muss überschaubar und komfortabel bleiben. Funktionen sollten erkennbar größeren Sinn und Nutzen mit sich bringen.

Wir hätten’s wahrscheinlich nie auf den Mond geschafft, wenn alle Ideen, die die NASA so hatte, auch unbedingt in die Apollos hätten Eingang finden müssen - und so manches davon hätte wahrscheinlich auch einen sinnvollen Flug behindert.

Man darf letztlich nicht das Ziel aus den Augen verlieren: ein möglichst perfektes Buch. Was man sich alles an Notizen und sonstigem Beiwerk erstellt hat, ist dann nur noch Müll, wenn alle dazugehörigen Texte veröffentlicht sind.

Ich denke mal, es ist erst einmal alles zum Thema gesagt, belassen wir’s erst einmal dabei.

[Norina]

Ich kenne mich nicht so gut aus in Papyrus, aber was ich in der Demo Verione sehen konnte, ist bei den Figure doch genau das was hier beschrieben wird, oder?
Ich habe eine Figur in de Datenbank mit Name Heidi, sie hat gelbe Haare. Nun möchte ich die Haarfarbe ändern, klicke im Text auf ihren Namen, die Kartei öffnet sich, ich ändere die Haarfarbe auf Braun, und gut ist.

Ich finde die Idee genial.

[tomP]

Nein. Was du da von vor 7 Jahren ausgegraben hast, sollte in die andere Richtung funktionieren.

Um ein Beispiel zu bringen: Die Fantasygeschichte, die ich damals gerade angefangen hatte, steht nun vom Text und hat 1600 Seiten. Eine Prophetie wird immer wieder zitiert.

Der Vorschlag damals hätte es möglich gemacht, dass diese Prophetie in einer Datenbank gestanden hätte und an entsprechend markierten Stellen (ähnlich einem Serienbrief nur ohne Serie) eingefügt worden wäre.

Natürlich wurde über die Jahre massiv am Text gefeilt und diese Prophetie auch mindestens viermal umformuliert. Durch die vorgeschlagene Funktion hätte sie nur an einer einzigen Stelle (in der Datenbank) ausgetauscht werden müssen. Das hätte mein Leben tatsächlich vereinfacht, denn ich habe nicht die geringste Ahnung, wo dieser Text überall zitiert wird.

[Norina]

Verstehe ich das richtig, trozt der Nachfrage von vielen Nutzer, wurde die Möglichkeit Tags anzulege noch nicht umgesetzt?

[Stephan_C]

(Nachtrag: Ich habe erst später gesehen, dass die Debatte 7 Jahre alt ist. Vielleicht ist die Anregung ja trotzdem was Wert.)

Hallo in die Runde,

ich will das mal von einer anderen Seite beleuchten, indem ich eine wünschenswerte Funktion beschreibe, die letztlich das gleiche bewirkt:

Eine relationale Textbaustein-Datenbank
(Das würde in meinen Augen die Erstellung eines sehr komplexen Textes deutlich erleichtern, besonders, wenn man es intuitiv benutzen kann. Siehe unten.)

Was jetzt bereits geht:

Eine Datenbank mit diversen Schlüsseln, einem Textfeld und evtl. Hinweis auf letzte Änderung. Fertig ist die Sammlung von Textbausteinen.

Was schön wäre:

Hat man einen Textbaustein aus der Datenbank heraus in ein Dokument integriert, wirken sich spätere Änderungen in der Datenbank auf Wunsch auch im Textdokument aus. UND UMGEKEHRT ändert sich der Text in der Datenbank auf Wunsch, wenn der Text im Dokument geändert wird.

Das heißt, beide Textbereiche sind so lange synchron, bis man sich entscheidet, die 1:1 Verknüpfung zu lösen. Die Sprungmarken zwischen Datenbank und Dokument sollten aber in jedem Fall erhalten bleiben.

Was noch schöner wäre (und damit sind wir beim Wunsch, der hier besprochen wird):

Im Dokument markiert man einen Abschnitt und per Rechtsklick (oder wohin auch immer klicken) kommt dann die Frage nach dem Schlüsselwort und das erzeugt dann den Eintrag in der Textbaustein-Datenbank samt Datum, Dokumentenname, Sprungmarke und natürlich dem Textabschnitt. - Das wäre dann schön intuitiv, einfach nutzbar und ein echter Mehrwert.

Man kann dann entscheiden, ob man das Ganze als Textbaustein Sammlung verwendet oder als ein (wie auch immer geartetes) Hilfsmittel, um die Übersicht zu verbessern.

Weiterführende Überlegung, die aber vielleicht doch zu komplex wird:

Man könnte darüber nachdenken, statt nur reinen Text in der Datenbank zu halten, ganze Seiten inkl. Formatierung, etc. in der Datenbank zu speichern. (Also eigentlich eine Art Dokumentenmanagement.) Das dann mit 1:1 Synchronisierung.