Gedbas4all und wikibase

gedbas-dev
1

Hallo zusammen,

nachdem hier lange Zeit Ruhe auf der Liste war, möchte ich nun einen
aktuellen Stand geben, woran gerade gearbeitet wird.

Da wir alleine mit den wenigen Ehrenamtlichen mit einem so komplexen
Thema wie gedbas4all überfordert sind, wollen wir mehr auf Kooperation
mit ähnlichen Projekten setzen. Es wäre Quatsch wenn eigentlich gleiche
Eingaben und Ausgaben an mehreren Stellen für verschiedene System
entwickelt werden. Daher soll es einen Wechsel im Backend geben. Statt
auf eine selbst entwickelte Lösung soll Wikibase verwendet werden. Damit
haben wir automatisch eine fertige (technische) Ansicht der Daten und
eine Versionsverwaltung. Andere Projekte verwenden nur die bei Wikibase
eingebaute Ansicht, das kann man aber Nutzer*innen nicht vorsetzen. Die
geplante Architektur ist in dem Diagramm im Anhang zu sehen.

Hier habe ich beschrieben, wie man sich eine rudimentär befüllte
Wikibase-Installation erstellen kann:

Außerdem habe eine öffentlich zugängliche Installation für
unser gedbas4all-Wikibase erstellt und dort die Daten von
zehn Mindener Adressbüchern importiert. Hier ein Beispiel:
http://pluto.genealogy.net:8181/wiki/Item:Q70036

Das gleiche als maschinenlesbare Daten:
http://pluto.genealogy.net:8181/wiki/Special:EntityData/Q70036.json?flavor=dump

An dieser Stelle habe ich Informationen (Vorname Heinr.=Heinrich)
zusammengefügt:
http://pluto.genealogy.net:8181/wiki/Item:Q70009

Hier habe ich drei identische Adressen zusammengefügt:
http://pluto.genealogy.net:8181/wiki/Item:Q21414

So sieht es aus, wenn man Daten aus mehreren Adressbüchern verknüpft:
http://pluto.genealogy.net:8181/wiki/Item:Q24990
http://pluto.genealogy.net:8181/wiki/Item:Q34953

Unter http://pluto.genealogy.net:8282 kann man auch SPARQL-Abfragen
stellen. Hier sind zwei super simple Beispiele:

# Alle Seiten des Mindener Adressbuchs von 1895
SELECT ?item ?itemLabel WHERE {
   ?item wdt:P8 wd:Q23.
   SERVICE wikibase:label { bd:serviceParam wikibase:language
"[AUTO_LANGUAGE],de". }
}

# Alle Personen mit Wohnort Minden
SELECT ?item ?itemLabel WHERE {
   ?item wdt:P23 wd:Q10 .
   SERVICE wikibase:label { bd:serviceParam wikibase:language
"[AUTO_LANGUAGE],de". }
}

Auch unsere Totenzettel-Sammlung lässt sich gut abbilden. Dazu habe ich
dieses Beispiel angelegt:
http://pluto.genealogy.net:8181/wiki/Item:Q70183

Bei der Komponente „Erzeugen des Suchindex“ bin ich so weit, dass aus
den beiden Personendaten mehrere Einträge (für jede Quelle einen) für
den Elasticsearch-Server erstellt werden.

Wir sind bislang mit gedbas4all so dicht an FactGrid dran, dass das
Erzeugen des Suchindex auch mit Daten aus FactGrid funktionieren würde.
Auch die hübsche Anzeige einer Person müsste mit verschiedenen
Wikibase-Installationen funktionieren.

Schöne Grüße
Jesper

Architektur.pdf (43.2 KB)

2

Hallo Jesper,

wow, das ist mal eine interessante Nachricht. Ich finde Wikibase auch einen prima Ansatz. Ich hatte ja schon vor ein paar Jahren mal vorgeschlagen das GOV in Wikibase abzubilden. Da ich auch viel in Wikidata mache und das Projekt sehr gut finde, kann ich dich nur unterstützen, diesen Weg zu gehen.

Zur Modellierung:

um näher am bisherigen gedbas4all zu bleiben, würde ich es folgendermaßen modellieren: Einträge sind Teil der Quelle, so wie Seiten Teil der Quelle sind. Sie sind im Prinzip unveränderlich, einmal angelegt bleiben sie normalerweise so wie sie sind. Jeder Personeneintrag findet sich in einem eigenen Item wieder und ist auch nicht verschmelzbar außer jemand erfasst genau dieselbe Quelle nochmals.
Im Item finden sich auch Angaben zur evtl. vorhandenen Bilddatei mit den dazugehörigen Koordinaten, das Datum des Eintrags und Verknüpfungen zu anderen Einträgen, die so in der Quelle stehen.

Personen können als eigene Items erstellt werden, die der realen Person entsprechen. Dort kann auf alle Einträge als Quelle zugegriffen werden. Es spielt dabei dann keine Rolle, welche Art von Eigenschaft das ist: das Geburtsdatum entnehme ich EintragQxxxxx aus der Verlustliste, die Angabe des Vaters dem EintragQxxxx im Adressbuch von XXX und die Angabe des Ehepartners dem EintragQxxxx aus dem kirchlichen Trauungsbuch von XXXX.

Das ermöglicht es dann, auch vermeintlich identische Personen wieder zu trennen: man legt eine neue Person an und bindet die entsprechenden Einträge neu an diese Person.

Über Constraints kann man auch schnell prüfen, ob ein Eintrag bei mehreren Personen als Quelle angegeben ist und so falsche Zuordnungen, bzw. Dopplungen finden.

Zur Benennung:

Teile einer Quelle würde ich so benennen, dass sie leicht der Quelle zuordenbar sind und keine zusätzlichen Angaben bei der Verwendung benötigt werden, also nach dem Muster:

- Adressbuch Minden 1956/57
- Adressbuch Minden 1956/57 Seite 78
- Adressbuch Minden 1956/57 Seite 78 Johann Meier
- Adressbuch Minden 1956/57 Seite 78 Johann Meier / Josef Meier (für eine Bezugsperson im Eintrag "Johann Meier")

also keine Benennung nur nach der Person "Johann Meier", um damit schon mal deutlich zu machen, dass es sich um einen Quelleintrag handelt.

Theoretisch wäre es auch denkbar, Daten aus Projekten ohne Quellenangaben wie OFB oder Gedbas zu importieren. Da die dort erfassten Personen realen Personen entsprechen, werden sie als solche importiert und können dann natürlich mit evtl. bereits vorhandenen Einträgen "bequellt" werden oder es werden nachträglich Quelleinträge erstellt.

Beste Grüße

Wolfgang

3

Hallo Wolfgang,

Da ich auch viel in Wikidata mache und das Projekt sehr gut finde, kann ich dich nur unterstützen, diesen Weg zu gehen.

Das trifft sich ja gut, dass du dort schon viel Erfahrung hast.

Zur Modellierung:

um näher am bisherigen gedbas4all zu bleiben, würde ich es folgendermaßen modellieren: Einträge sind Teil der Quelle, so wie Seiten Teil der Quelle sind.

So ist es geplant.

Jeder Personeneintrag findet sich in einem eigenen Item wieder und ist auch nicht verschmelzbar

Möglicherweise meinen wir das gleiche, aber nach meinen bisherigen
Versuchen/Überlegungen finde ich es günstige, wenn die Quellen-Items
selbst fast keine Informationen (außer Zugehörigkeit zu einer sie
enthaltenen Quelle) enthalten. Das hier wäre ein Beispiel für ein solche
Quellen-Item: http://pluto.genealogy.net:8181/wiki/Item:Q23425

Personen können als eigene Items erstellt werden, die der realen Person entsprechen. Dort kann auf alle Einträge als Quelle zugegriffen werden. Es spielt dabei dann keine Rolle, welche Art von
Eigenschaft das ist: das Geburtsdatum entnehme ich EintragQxxxxx aus
der Verlustliste, die Angabe des Vaters dem EintragQxxxx im Adressbuch von XXX und die Angabe des Ehepartners dem EintragQxxxx aus dem kirchlichen Trauungsbuch von XXXX.

So ist es auch bei http://pluto.genealogy.net:8181/wiki/Item:Q24990
gemacht.

Das ermöglicht es dann, auch vermeintlich identische Personen wieder
zu trennen: man legt eine neue Person an und bindet die entsprechenden Einträge neu an diese Person.

Die Trennung ist auch bei der Variante mit einem einzigen Personen-Item
möglich. Wir haben a) die Historie in Wikibase und b) die Fundstellen,
mit denen sich Aussagen den Quell-Items zuordnen lassen.

Hier
<Files · master · Jesper Zedlitz / gedbas4all-wikibase · GitLab;
habe ich die beiden Varianten "Modellierung des Auftretens einer Person
in einer Quelle als ein Item" vs. "Modellierung einer Person als ein
Item und Angabe der Quellen an den Statements" beschrieben, wobei ich
wie gesagt zur zweiten Variante tendiere.

Über Constraints kann man auch schnell prüfen, ob ein Eintrag bei mehreren Personen als Quelle angegeben ist und so falsche Zuordnungen, bzw. Dopplungen finden.

Sind die Contraints in Wikibase eingebaut? Dann müsstest du mir das
nochmal erklären.

Teile einer Quelle würde ich so benennen, dass sie leicht der Quelle zuordenbar sind und keine zusätzlichen Angaben bei der Verwendung benötigt werden, also nach dem Muster:

- Adressbuch Minden 1956/57 - Adressbuch Minden 1956/57 Seite 78
- Adressbuch Minden 1956/57 Seite 78 Johann Meier

>
Einverstanden. Trotzdem sollten die Informationen zur Seite (ist Teil von, Seitenzahl, Reihenfolge) nochmal in maschinenlesbarer Form angegeben sein. (Ist in den bisherigen Beispielen bisher noch nicht der Fall.)

Schöne Grüße
Jesper

4

Hallo Jesper,

Zur Modellierung:

um näher am bisherigen gedbas4all zu bleiben, würde ich es folgendermaßen modellieren: Einträge sind Teil der Quelle, so wie Seiten Teil der Quelle sind.

So ist es geplant.

Jeder Personeneintrag findet sich in einem eigenen Item wieder und ist auch nicht verschmelzbar

Möglicherweise meinen wir das gleiche, aber nach meinen bisherigen
Versuchen/Überlegungen finde ich es günstige, wenn die Quellen-Items
selbst fast keine Informationen (außer Zugehörigkeit zu einer sie
enthaltenen Quelle) enthalten. Das hier wäre ein Beispiel für ein solche
Quellen-Item: http://pluto.genealogy.net:8181/wiki/Item:Q23425

So ganz meinen wir wohl nicht das Gleiche. Mein Vorschlag ist nah an deinem ersten. Aber ich unterscheide Quell-Einträge von Personen. Ich habe mal Einträge angelegt, um es zu verdeutlichen

http://pluto.genealogy.net:8181/wiki/Item:Q70189

http://pluto.genealogy.net:8181/wiki/Item:Q70191

sind zwei Quell-Einträge (Instanz Eintrag) nur mit Inhalten wie sie in der Quelle stehen - sie sollten jeweils einem bisherigen Datensatz in der DB entsprechen. An diesen beiden Items dürfte es keine Änderungen mehr geben, da sie den kompletten Inhalt des Quelleintrags bereits widerspiegeln. Im Grunde könnten diese gesperrt werden (nur Änderungen wegen fehlerhafter Transkription sind vielleicht nötig).

In http://pluto.genealogy.net:8181/wiki/Item:Q70190 habe ich nun eine Person angelegt (Instanz Person). Diese beinhaltet auch nicht bequellte Daten, z.B. den Vornamen, der vielleicht aus einer Gedbas-DB stammt. Den Beruf habe ich bei der Person normalisiert, Originalschreibweisen können ja in der Quelle nachgelesen werden. Der Datensatz bleibt insgesamt leichter handhabbar, da man auch Eigenschaften gleichen Inhalts aber unterschiedlicher Quellen zusammenfassen kann. Die Quellen bleiben ja immer unberührt.

In diesem Personen-Eintrag stecken Vermutungen (Q70189 und Q70191 sind identisch, Vorname aus unbekannter Quelle), was sich jederzeit bei neuen Belegen schnell wieder ändern lässt ohne die Quellen Q70189 und Q70191 zu verändern. Außerdem kann man im Personendatensatz auch Normalisierungen vornehmen, auch wieder ohne die Quelleinträge zu verändern.

Dein Modell 2 zumindest ist gefährlich: löscht jemand z.B. den Beruf aus dem Personendatensatz, weil festgestellt wurde, die in der Quelle genannte Person ist eine andere, legt dann aber diese andere Person mit diesem "Beruf" nicht wieder neu an, würde damit ein Datensatz der Quelle gelöscht werden.

Über Constraints kann man auch schnell prüfen, ob ein Eintrag bei mehreren Personen als Quelle angegeben ist und so falsche Zuordnungen, bzw. Dopplungen finden.

Sind die Contraints in Wikibase eingebaut? Dann müsstest du mir das
nochmal erklären.

Nein, Constraints sind durch eine Erweiterung zu haben:

In Wikidata werden sie aber durchgängig und sehr viel verwendet, siehe z.B.

https://www.wikidata.org/wiki/Property_talk:P1082

Teile einer Quelle würde ich so benennen, dass sie leicht der Quelle zuordenbar sind und keine zusätzlichen Angaben bei der Verwendung benötigt werden, also nach dem Muster:

- Adressbuch Minden 1956/57 - Adressbuch Minden 1956/57 Seite 78
- Adressbuch Minden 1956/57 Seite 78 Johann Meier

>
Einverstanden. Trotzdem sollten die Informationen zur Seite (ist Teil von, Seitenzahl, Reihenfolge) nochmal in maschinenlesbarer Form angegeben sein. (Ist in den bisherigen Beispielen bisher noch nicht der Fall.)

Das ist sowieso klar. Es ging mir nur um die Benennung, um Quellen auch als Mensch auffinden zu können.

Beste Grüße

Wolfgang

5

Hallo Wolfgang (und natürlich auch gerne weitere "Mitüberleger*innen"),

So ganz meinen wir wohl nicht das Gleiche. Mein Vorschlag ist nah an
deinem ersten. Aber ich unterscheide Quell-Einträge von Personen.

Ist es eine Kombination von beiden, Item für Personenvorkommen +
Quellenangaben an den Properties?

Ich habe mal Einträge angelegt, um es zu verdeutlichen

http://pluto.genealogy.net:8181/wiki/Item:Q70189

http://pluto.genealogy.net:8181/wiki/Item:Q70191

sind zwei Quell-Einträge (Instanz Eintrag) nur mit Inhalten wie sie
in der Quelle stehen - sie sollten jeweils einem bisherigen Datensatz
in der DB entsprechen. An diesen beiden Items dürfte es keine
Änderungen mehr geben, da sie den kompletten Inhalt des Quelleintrags
bereits widerspiegeln. Im Grunde könnten diese gesperrt werden (nur
Änderungen wegen fehlerhafter Transkription sind vielleicht nötig).

Das mit der Sperre ist eine gute Idee. Aber war passiert, wenn jemand an
den verlinkten Items Änderungen vornimmt, z.B. die Vornamen-Items
"Heinr." und "Heinrich" verschmilzt. Dann hat sich plötzlich der Inhalt
des Quellen-Items geändert. Daher kam meine Idee mit dem Qualifier
"Originalschreibweise" als Text.

In http://pluto.genealogy.net:8181/wiki/Item:Q70190 habe ich nun eine
Person angelegt (Instanz Person).

Der ist aber nicht durch Wikibase-eigene Werkzeuge entstanden, sondern
du hast ihn von Hand angelegt?

Der Datensatz bleibt insgesamt leichter handhabbar, da man auch
Eigenschaften gleichen Inhalts aber unterschiedlicher Quellen
zusammenfassen kann. Die Quellen bleiben ja immer unberührt.

Bei meinem Ansatz lassen sich Eigenschaften auch zusammenfassen, da die
Originalschreibweise als Qualifier vorhanden ist. Es könnte allerdings
besser sein, wenn man die Originalschreibweise an die Quellenangabe hängt.

Dein Modell 2 zumindest ist gefährlich: löscht jemand z.B. den Beruf
aus dem Personendatensatz, weil festgestellt wurde, die in der Quelle
genannte Person ist eine andere, legt dann aber diese andere Person
mit diesem "Beruf" nicht wieder neu an, würde damit ein Datensatz der
Quelle gelöscht werden.

In der Tat wäre es komplizierter, das wieder zu rekonstruieren. Man
müsste in der Versionsgeschichte nachsehen.

Mit dem deutlich erhöhten Speicherplatz könnten wir wohl leben (wobei
schon jetzt absehbar ist, dass wir deutlich mehr Item und Properties als
Wikibase haben werden). Aber bei zwei Punkten habe ich noch Bedenken:

- Wie funktioniert das Zusammenfassen von Personen?
- Wir müssen sicherstellen, dass nicht der Inhalt der Quelle geändert
wird, wenn jemand ein verwendetes Item bearbeitet. Das müsste aber durch
den Qualifier "Originalschreibweise" lösbar sein.

Schöne Grüße
Jesper

7

So ganz meinen wir wohl nicht das Gleiche. Mein Vorschlag ist nah an
deinem ersten. Aber ich unterscheide Quell-Einträge von Personen.

Ist es eine Kombination von beiden, Item für Personenvorkommen +
Quellenangaben an den Properties?

Hm, die Frage verstehe ich nicht: es sind einfach zwei Arten von Objekten - einerseits statische Quelleinträge oder auch Zitate, also wörtliche Übernahmen aus der Quelle und andererseits generierte flexible Personen.

Das mit der Sperre ist eine gute Idee. Aber war passiert, wenn jemand an
den verlinkten Items Änderungen vornimmt, z.B. die Vornamen-Items
„Heinr.“ und „Heinrich“ verschmilzt. Dann hat sich plötzlich der Inhalt
des Quellen-Items geändert. Daher kam meine Idee mit dem Qualifier
„Originalschreibweise“ als Text.

Ja, die Originalschreibweise muss auf jeden Fall erhalten bleiben. Dafür gäbe es zwei Optionen:

  1. wie von dir vorgeschlagen durch einen zusätzlichen Qualifier

  2. man verwendet grundsätzlich bei den Quelleinträgen nur Properties vom Typ „monolingualtext“ und nicht vom Typ „wikibase-item“. Das würde natürlich auch die Zahl der Properties verdoppeln, da man dann z.B. die Properties „Vorname in der Quelle“ oder "Vorname (Originalschreibweise), „Nachname in der Quelle“, usw. bräuchte.

Ich kann jedoch nicht überblicken, wie sich der Vorschlag 2 dann auswirken würde.

Aber bei zwei Punkten habe ich noch Bedenken:

  • Wie funktioniert das Zusammenfassen von Personen?

Meinst du das Zusammenfassen von Quelleinträgen? Dann: Anlegen einer Person mit den Daten aus den Quelleinträgen und den entsprechenden Verweis auf die Quelleinträge.

Sind schon Personen angelegt und jemand findet zwei identische Personen geht das über die „Merge“-Funktion, siehe Help:Datenobjekte zusammenlegen - Wikidata

  • Wir müssen sicherstellen, dass nicht der Inhalt der Quelle geändert
    wird, wenn jemand ein verwendetes Item bearbeitet. Das müsste aber durch
    den Qualifier „Originalschreibweise“ lösbar sein.

siehe oben

BG
Wolfgang

8

Wie funktioniert das Zusammenfassen von Personen?

Meinst du das Zusammenfassen von Quelleinträgen? Dann: Anlegen einer Person mit den Daten aus den Quelleinträgen und den entsprechenden Verweis auf die Quelleinträge.

Sind schon Personen angelegt und jemand findet zwei identische Personen geht das über die „Merge“-Funktion, siehe Help:Datenobjekte zusammenlegen - Wikidata

Über die Merge-Funktion habe ich die Einträge bisher zusammengefügt. Wenn wir Quelleneinträge haben, reichen die Wikibase-internen Funktionen nicht mehr aus. Dann müssen wir selbst etwas programmieren, das uns die Angaben der Quellenangaben (am besten direkt den Wikibase-Daten in JSON) zu einem neuen Item zusammensetzt.

9

Da bräuchte man einen guten Javascript-Programmierer. Dann kann man ein Gadget erstellen, dass diese Funktion übernimmt.

10

Die Variante mit je einem Items für den Eintrag und einen für die Person habe ich nun umgesetzt und ein paar Daten angelegt:
https://gedbas-test.genealogy.net/wiki/Item:Q257498

Ich würde auch sagen, dass wir an den Items für die Einträge keine Properties from Typ wikibase-item brauchen. Denn dort soll der Text ja unverändert stehen bleiben und kein Merge stattfinden. Dann könnte man sich auch den Qualifier „Originalschreibweise“ am Personen-Item sparen.