Data Model and Editing.de

🌐 English

Datenmodell und Bearbeitung

Gramps Connect arbeitet mit demselben Objektmodell wie Gramps selbst. Es gibt zehn Datensatztypen, jeder mit eigener Listenansicht, eigenem durchsuchbarem Suchfeld (standardmäßig reiner Text, oder GOQL über ein Kontrollkästchen) und eigenem REST-Endpunkt auf gramps-web-api:

Typ	Listenansicht	Abfrage-Endpunkt
Person	Personen	/api/people/query/
Family	Familien	/api/families/query/
Event	Ereignisse	/api/events/query/
Place	Orte	/api/places/query/
Repository	Aufbewahrungsorte	/api/repositories/query/
Source	Quellen	/api/sources/query/
Citation	Fundstellen	/api/citations/query/
Media	Medien	/api/media/query/
Note	Notizen	/api/notes/query/
Tag	Etiketten	/api/tags/query/

Da ein Stammbaum frei zwischen Gramps Desktop, gramps-web und Gramps Connect wechseln kann (siehe Übersicht), sind das genau die Datensatztypen und Felder, die Gramps XML und GEDCOM ohnehin schon tragen — Gramps Connect fügt keine hinzu und entfernt keine.

Durchsuchen

Einen Datensatz aus einer Liste auswählen, und alles Zugehörige — Ereignisse, Familie, Fotos, Notizen, Quellen — erscheint daneben. In eines davon klicken, öffnet dessen eigene Details darunter, während die Liste und die ursprüngliche Auswahl dort bleiben, wo sie waren, egal wie tief man geht (siehe Übersicht).

Bearbeiten

Ein Klick auf die Bearbeiten-Schaltfläche eines beliebigen Datensatzes öffnet dessen vollständiges Bearbeitungsformular für die eigenen Details dieses Datensatzes (ein Name, ein Datum, eine Beschreibung) oder seine Verbindungen zu anderen Datensätzen — etwa genau, wie ein Kind mit seinen Eltern verwandt ist.

Für kleinere, alltägliche Änderungen sind die Schaltflächen „+“ und „−“ eine Abkürzung: eine bestehende Fundstelle, ein Foto oder eine Person anhängen, ohne ein vollständiges Formular zu öffnen, oder eine bereits verknüpfte entfernen. Sie ändern nur, womit ein Datensatz verbunden ist, nicht dessen eigene Details.

Was heute vollständig bearbeitbar ist

Person- und Family-Datensätze sind am vollständigsten, mit einer bemerkenswerten Ausnahme: LDS-Ordinanzen sind vollständig schreibgeschützt — kein Bearbeiten, Hinzufügen oder Loslösen.

Was teilweise bearbeitbar ist, nach Typ

• Place — die umschließende/übergeordnete Hierarchie eines Orts kann jetzt über einen Wikidata-Abgleich ausgefüllt werden (nach Namen suchen, einen Treffer bestätigen, und es legt die Kette Stadt/Landkreis/Bundesland/Land an oder verknüpft sie, jede Ebene mit eigenen Koordinaten); es gibt weiterhin keine Möglichkeit, einen umschließenden Ort von Hand hinzuzufügen, zu entfernen oder umzusortieren, unabhängig von Wikidata. Das Type-Feld jeder Ebene wird ebenfalls aus Wikidata geraten, aus einer Tabelle mit rund 2700 Verwaltungseinheiten- und Siedlungsklassen über die meisten Länder hinweg (nicht nur die US-förmige Stadt/Landkreis/Bundesland/Land-Kette); eine nicht erkannte Klasse lässt Type auf dem Bestätigungsbildschirm weiterhin leer, zum Ausfüllen von Hand. Jede vom Abgleich angelegte Ebene bekommt einen beschreibenden Titel, der ihre bestätigten Vorfahren einschließt (z. B. „Marion County, Indiana, United States“), nicht nur ihren eigenen bloßen Namen — ihr zugrunde liegendes Namensfeld bleibt der bloße Name, sodass ein späterer Abgleich sie weiterhin als denselben Ort erkennen kann. Der Editor eines brandneuen Orts fragt zuerst, ob er von Hand oder aus Wikidata hinzugefügt werden soll, statt den Abgleich einfach als ein weiteres Feld neben den manuellen zu zeigen; ein bereits gespeicherter, erneut bearbeiteter Ort behält den Abgleich stattdessen als schlichte Anreicherungs-Schaltfläche. Derselbe Abgleich kann optional auch einen Umriss von Wikidata holen (ein Kontrollkästchen auf dem Bestätigungsbildschirm, standardmäßig aktiviert) — für jede neu angelegte Ebene und für den hinzugefügten Ort selbst — sodass die Karte dessen tatsächliche Grenze zeigt statt nur eine Nadel an seinen Koordinaten — angehängt auf dieselbe Weise wie eine von Hand gezeichnete Kartenform, danach also genau wie jeder andere Anhang aus der Medien-Ansicht bearbeitbar/entfernbar, und eingefärbt nach dem Typ des Orts und seiner Wikidata-ID, damit nicht alle Orte standardmäßig dieselbe Füllung bekommen. Bestehende/wiederverwendete Ebenen in der Hierarchie bekommen keinen nachträglich angefügt. Der eigene (primäre) Name eines Orts kann jetzt ein Datum und eine Sprache tragen, mit demselben Datumseditor, den Ereignisse und Fundstellen verwenden — das ist es, was die datumsbasierte Sichtbarkeit der Kartenüberlagerungs-Funktion ausliest (siehe Übersicht). Weiterhin fehlend: alternative Namen (Hinzufügen/Bearbeiten/Entfernen — die eigene alt_names-Liste eines Orts wird schreibgeschützt angezeigt, hat aber keinen Editor; jeder Eintrag ist ein eigener Name mit eigenem Datum/Sprache, z. B. um einen älteren Namen und die Epoche, in der er galt, festzuhalten), historische Orte und Code.
• Note — fehlend: Textformatierung/Links (Notizen sind nur reiner Text), und das Format-Flag (Fließend/Formatiert).
• Media — Beschreibung, Datum und Vertraulichkeit sind über eine Bearbeiten-Schaltfläche bearbeitbar; die Datei selbst, ihr Typ und ihre Prüfsumme bleiben vom Upload abgeleitet, serverseitig. Attribute, Fundstellen, Notizen und Etiketten sind bereits über dieselben Bereiche für verwandte Datensätze bearbeitbar, die jeder andere Datensatztyp verwendet. Fotos öffnen sich bei einem Klick bereits in voller Größe; ein Media- (oder Output-)Element, dessen Datei ein PDF, Video, Audioclip, SVG oder textartiges Format ist (HTML, JSON, reiner Text, CSV, GEDCOM, KML/XML, …), bekommt stattdessen eine Ansehen-Schaltfläche daneben, die dieselbe Datei im Browser öffnet, statt einen Download zu verlangen. HTML-Vorschauen rendern in einer Sandbox (keine Skripte), sodass die Formatierung eines erzeugten Berichts sichtbar wird, ohne je etwas darin auszuführen (allerdings lädt jedes darin per relativem Pfad verlinkte Asset nicht, da nur diese eine Datei verfügbar ist, kein Ordner mit Geschwisterdateien).

Doppelte Datensätze zusammenführen

Jeder Datensatztyp außer Tag lässt sich zusammenführen: zwei Datensätze desselben Typs auswählen (Strg/Cmd-Klick in einer Liste), dann Zusammenführen. Auswählen, welcher erhalten bleibt — dessen eigene bestimmende Felder (Name, Titel, Datum usw., je nach Typ) bleiben erhalten und die des anderen werden verworfen, während listenartige Dinge wie Notizen, Fundstellen, Medien und Attribute aus beiden kombiniert werden. Jeder andere Verweis auf den nicht erhaltenen Datensatz wird auf den erhaltenen umgebogen, bevor er gelöscht wird. Family ist der einzige Typ, bei dem sich die beiden zusammengeführten Datensätze bei einem Elternteil unterscheiden können; passiert das, wird pro Rolle (Vater/Mutter) gefragt, welche Seite behalten werden soll. Etiketten haben in Gramps selbst keinen Zusammenführungsweg, das Zusammenführen zweier Etiketten wird also stattdessen clientseitig behandelt — alles, was mit dem verworfenen Etikett versehen war, wird mit dem erhaltenen neu etikettiert, das verworfene wird dann gelöscht.

Bearbeitungsverlauf ansehen

Jeder Datensatz hat eine Verlauf-Schaltfläche neben seinen Karte-/Zeitleiste-/Diagramm-Links. Sie öffnet ein Protokoll der eigenen Änderungen dieses Datensatzes — wer jede gemacht hat, wann, und ob es ein Hinzufügen, Aktualisieren oder Löschen war — neueste zuerst, eine Seite auf einmal. Auf einen Eintrag klicken, um genau zu sehen, was sich geändert hat: ein feldweiser Vorher/Nachher-Vergleich, nicht nur die Tatsache, dass sich etwas geändert hat. Das ist die nachträgliche Ergänzung zur Live-Synchronisierung (siehe Architektur), die nur Änderungen zeigt, während sie eintreffen; beide lesen aus demselben Transaktionsprotokoll von gramps-web-api.

Es gibt noch kein Rückgängig — eine Änderung rückgängig zu machen bedeutet, den Datensatz von Hand zurückzubearbeiten. Siehe Roadmap und bekannte Einschränkungen für den aktuellen Stand dazu.

Übergreifende Lücken

• GrampsType-Felder sind größtenteils Freitext. Der Beziehungstyp von Family sowie das eigene type von Attribute/Url haben ein echtes Auswahlmenü mit Autovervollständigung gegen Gramps' bekannte Werteliste. Andere GrampsType-Felder sind funktional als reiner Text bearbeitbar, nur noch ohne diese Autovervollständigung oder Validierung.
• Gleichzeitige Bearbeitungen werden erkannt, nicht zusammengeführt. Hat sich ein Datensatz auf dem Server geändert, nachdem sein Bearbeitungsformular geöffnet wurde — durch jemand anderen, oder einen anderen eigenen Tab —, wird das Speichern mit einem Fehler verweigert, statt die fremde Änderung stillschweigend zu überschreiben. Es gibt weiterhin keine Möglichkeit, zu sehen, was sich geändert hat, oder die beiden Bearbeitungen zusammenzuführen; man muss einfach neu öffnen und die eigene Änderung wiederholen.

Siehe Roadmap und bekannte Einschränkungen für den Stand der aktiven Arbeit daran.