FactGrid talk:Erik-Amburger-Datenbank: Difference between revisions

From FactGrid
Jump to navigation Jump to search
 
(11 intermediate revisions by 2 users not shown)
Line 3: Line 3:
Ziel der ersten Dateneingabe war es zu allen Personen der Amburger-Datenbank korrespondierende FatGrid Items anzulegen, die sich nun von der Amburger-Datenbank aus gegenreferenzieren lassen - ein Matching das bei den folgenden ausstehenden Eingaben als Dreh- und Angelpunkt dienen kann.
Ziel der ersten Dateneingabe war es zu allen Personen der Amburger-Datenbank korrespondierende FatGrid Items anzulegen, die sich nun von der Amburger-Datenbank aus gegenreferenzieren lassen - ein Matching das bei den folgenden ausstehenden Eingaben als Dreh- und Angelpunkt dienen kann.


Bei der Eingabe fielen unmittelbar zwei Items auf ([https://database.factgrid.de/query/embed.html#SELECT%20%3FHuman%20%3FHumanLabel%20%3FAmburger_database_ID%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FHuman%20wdt%3AP2%20wd%3AQ7%3B%0A%20%20%20%20wdt%3AP533%20%3FAmburger_database_ID.%0A%20%20%3FHuman%20wdt%3AP17%20wd%3AQ876303.%0A%7D Dubletten], die zusammengezogen wurden. In einem zweiten Schritt wurden alle FactGrid-Amburger-Items mit den bislang existierenden Wikidata-Items verlinkt und diese wiederum Wikidata-seitig mit den FactGrid Items rückverbunden. Die Eingabe geschah mit Identifikation Geschlechtsangaben. Aus Wikidata wurden Väter, Mütter, Kinder und Ehepartner verlinkt, soweit diese bereits FactGrid-Nummern hatten.
Bei der Eingabe fielen unmittelbar zwei Items auf, die als  Dubletten zusammengezogen und [[https://database.factgrid.de/query/embed.html#SELECT%20%3FHuman%20%3FHumanLabel%20%3FAmburger_database_ID%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FHuman%20wdt%3AP2%20wd%3AQ7%3B%0A%20%20%20%20wdt%3AP533%20%3FAmburger_database_ID.%0A%20%20%3FHuman%20wdt%3AP17%20wd%3AQ876303.%0A%7D vermerkt] wurden.


[[Property:P533]] notiert auf jedem Personen-Item die Amburger-ID, über sich jeweils direkt in den jeweiligen Amburger-Datensatz blicken lässt. Die folgende Suchabfrage bietet mit minimalem (und damit schnell gehendem) Skript jeweils im aktuellen Stand die beiden Identifier-Spalten parallel für das Matching von jetzt folgenden Eingaben:
Im zweiten Schritt wurden alle FactGrid-Amburger-Items mit den bislang existierenden Wikidata-Items verlinkt. Diese wiederum wurden Wikidata-seitig mit den FactGrid Items rückverbunden. Die erste Eingabe kam mit Geschlechtsangaben. Aus Wikidata wurden Väter, Mütter, Kinder und Ehepartner verlinkt, soweit die Verlinkungen ihrerseits auf bereits bestehende FactGrid-Objekte verwiesen.
 
[[Property:P533]] notiert auf jedem Personen-Item die Amburger-ID, über sich nun direkt in den jeweiligen Amburger-Datensatz hinüberschalten lässt. Die folgende Suchabfrage bietet mit minimalem, schnell gehendem Skript immer den aktuellen Stand des Matching:


* [https://database.factgrid.de/query/embed.html#SELECT%20%2a%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20OPTIONAL%20%7B%20%3Fitem%20wdt%3AP533%20%3FAmburger_database_ID.%20%7D%0A%7D%0A aktuelles Matching, FactGrid/Amburger Datenbank]
* [https://database.factgrid.de/query/embed.html#SELECT%20%2a%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20OPTIONAL%20%7B%20%3Fitem%20wdt%3AP533%20%3FAmburger_database_ID.%20%7D%0A%7D%0A aktuelles Matching, FactGrid/Amburger Datenbank]


Importe von Statements aus der Amburger-Datenbank werden sich unterschiedlich komplex gestalten. Wir kommen hier von einer relationalen Datenbank mit Textfeldern, die nicht weiter verlinken in eine Graph-Datenbank, die genau hier extreme Anforderungen an Eindeutigkeit einer jeweiligen Objektidentifikation stellt.
Importe von Statements aus der Amburger-Datenbank werden sich komplex gestalten. Die Amburger-Datenbank ist eine klassische relationalen Ressource mit Textfeldern, die nicht weiter verlinken. Angaben aus diesen Textfeldern verweisen sowohl auf bereits im FactGrid bestehende (aber nicht schon identifizierte) Objekte wie auf Objekte, die erst zu bilden sind (ohne dass klar ist, wie viele verschiedene Objekte dabei gebildet, identifiziert und mit eingehenden Informationen ausgestattet werden müssen - das betrifft etwa Orte, assoziierte Personen und Organisationen wie Arbeitgeber und Ausbildungsstätten).


Unterschiedliche Arbeitspakete lassen sich ausmachen. Es wird klug sein, Aufgaben, die sich mit geringem Aufwand abarbeiten lassen, vorzuziehen und aus arbeitsaufwendige dann eventuell eigene Projekte zu machen.
Es wird klug sein, Aufgaben, die sich mit geringem Aufwand abarbeiten lassen, vorzuziehen und arbeitsaufwendige später als eigene, komplexe, eventuell Zuarbeit oder Forderung benötigende einzukreisen.


== Nachnamen ==
== Nachnamen ==
...sollten einfach sein, da sich hier ein exaktes Matching gegenüber den bestehenden herstellen lässt. Fehlende Nachnamen müssen angelegt werden, bevor sie zugewiesen werden können.
...sollten einfach sein, da sich hier ein exaktes Matching gegenüber den in FactGrid angelegten Namens-Items herstellen lässt. Fehlende Nachnamen müssen angelegt werden, bevor sie zugewiesen werden können.


* [https://database.factgrid.de/query/embed.html#SELECT%20%3FFamily_nameLabel%20%3FFamily_name%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FFamily_name%20wdt%3AP2%20wd%3AQ24499.%0A%7D Alle aktuelle verfügbaren Familiennamen des FactGrid]
* [https://database.factgrid.de/query/embed.html#SELECT%20%3FFamily_nameLabel%20%3FFamily_name%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FFamily_name%20wdt%3AP2%20wd%3AQ24499.%0A%7D Alle aktuelle verfügbaren Familiennamen des FactGrid]


'''Herausforderung:''' die Russischen Versionen transkribierter Familiennamen (scheinen nicht in der Amburger-Datenbank notiert, sind aber vielleicht über die wissenschaftliche Transkription (?) rekonstruierbar.
Eine Herausforderung werden die Russischen Versionen transkribierter Familiennamen sein. Sind die Transkription eindeutig und damit eindeutig transliterierbar?


Bei Neuanlagen von Nachnamen zur Standardisierung das Batch-Fragment benutzen.
Bei Neuanlagen von Nachnamen sollte das bestehende Batch-Fragment benutzt werden.


== Vornamen ==
== Vornamen ==
Line 30: Line 32:


== Datierungen ==
== Datierungen ==
...gibt es an verschiedensten Stellen: Geburt- und Sterbedaten, Daten des Aufgebots bei Eheschließungen etc. '''Herausforderung:''' Die beiden Kalender alter (julianischer) und neuer (julianischer) Stil. Beim Massenimport lassen sich die Varianten, wo immer sie als solche notier sind, mit der /J Erweiterung des Statements abbilden. Frage: sind die Kalender durchweg auseinander gehalten? Wie sieht es bei den baltischen Ländern aus? Wie bei Weißrussland? (Das Polnisch-Litauische Großfürstentum schritt relativ früh zum neuen Kalender.)
...gibt es als Geburt- und Sterbedaten, Daten des Aufgebots bei Eheschließungen und so fort. Eine Herausforderung stellen die divergierenden Kalender alten/julianischen und neuen/gregorianischen  Stils dar, wobei Wikibase mittlerweile auch in Masseneingaben über QuickStatements die jeweilige Kalendernotierung erlaubt.


Wenn wir Daten korrekt importieren müssen wir bedenken, dass der QueryService sie ohne spezielle Anweisung automatisch auf den Gregorianischen Kalender umgestellt wieder herausgibt, sie dürfen danach nicht als julianische weiterbehandelt werden. Importe aus Wikidata sind kritisch, da speziell massenweise generierte Wikidata-Daten ohne Rücksicht auf die Kalenderfrage als mutmaßlich gregorianische Datierungen in Wikidata generiert wurden.
Sind die Kalender durchweg auseinander gehalten? Wie sieht es bei den baltischen Ländern aus? Wie in Weißrussland, sprich im ehemaligen Polnisch-Litauische Großfürstentum?
 
Wenn wir Daten im Julianischen Kalender importieren, muss bedacht sein, dass die reguläre QueryService-Abfrage diese Daten (ohne spezielle Anweisung) automatisch auf den Gregorianischen Kalender umgerechnet auswirft. Sie dürfen danach nicht mehr als julianische Daten irgendwo notiert werden (oder es geschehen laufende Additionen von 11 bis 14 Tagen). Importe aus Wikidata sind gefährlich, da QuickStatements in den ersten Masseneingaben nur gregorianische Datierungen zuließ. Julianische Daten wurden laufend einfach als Gregorianische fixiert, was speziell im orthodoxen Kalender prekär ist.


== Familienverbindungen ==
== Familienverbindungen ==
...scheinen sich nicht ohne weiteres aus der Ambuger-Datenbank beziehen zu lassen - dort scheinen keine Vernetzungen der Identifier vorzuliegen, wie FactGrid sie automatisch verlangt. Vermutlich lassen sich Zuordnungen jedoch relativ leicht über gemeinsame Datierungen und Lokalisierungen vornehmen. Bei Eheschlüssen ist oft das Aufgebot exakt datiert. Die [[Property:P1079]] ist eingerichtet dies als Qualifier unter der jeweiligen Ehe zu erfassen.
Die Amburger-Datenbank ist üppig mit Beziehungsgeflechten ausgestattet, jedoch dies nur oberflächlich, sprich ohne jeweilige eindeutige Identifikation der gemeinten Personen. Vermutlich lassen sich Ehepartner relativ leicht einander zuweisen, da hier sehr oft das Datum des Aufgebots ([[Property:P1079]]) exakt notiert und mit Ortsangaben versehen ist. Die diesbezüglichen Angaben sind jeweils bei beiden Ehepartnern identisch womit sich vermutich ein erstes Matching vornehmen lässt.


Hat man die Ehepartner, kann man vielleicht über deren Verbindung die Kinder leichter Paaren als einzelnen Personen zuordnen.
Hat man die Ehepartner, kann man vielleicht über deren Doppelung die Kinder zuordnen - sie müssen jeweils gleiche Profile Eltern und Kinderseitig aufweisen.


::Hier hat uns am Anfang Magnus Sälgö (Q40921) bei FactGrid ziemlich geholfen, indem er einen Schub von geni:IDs neben den Verbindungen zu wd generiert hat. Vllt solltest Du ihn mal anpingen, ob er uns noch einmal helfen kann/mag. Schweden und Finnlandschweden waren ja die nächsten Nachbarn zu Batlitikum und der St. Petersburger Ecke Russlands.--[[User:Martin Gollasch|Martin Gollasch]] ([[User talk:Martin Gollasch|talk]]) 18:56, 14 March 2024 (CET)
::Hier hat uns am Anfang Magnus Sälgö (Q40921) bei FactGrid ziemlich geholfen, indem er einen Schub von geni:IDs neben den Verbindungen zu wd generiert hat. Vllt solltest Du ihn mal anpingen, ob er uns noch einmal helfen kann/mag. Schweden und Finnlandschweden waren ja die nächsten Nachbarn zu Baltikum und der St. Petersburger Ecke Russlands.--[[User:Martin Gollasch|Martin Gollasch]] ([[User talk:Martin Gollasch|talk]]) 18:56, 14 March 2024 (CET)


== Ortsbestimmungen ==
== Ortsbestimmungen ==
Line 51: Line 55:
* Ukraine (ca. 75%)
* Ukraine (ca. 75%)
* Tschechien
* Tschechien
* Lettland


Desiderate sind aktuell:
Desiderate sind aktuell:


* Slowenien
* die Slowakei
* Weißrussland
* Weißrussland
* Lettland
* Estland
* Estland
* Russland
* Russland


== Religion ==
== Religion ==
Dies müsste eine besonders schnell herstellbare Aussage sein, nachdem das Spektrum der Aussagen klein ist.
Sie müsste sich besonders schnell notieren lassen, nachdem das Spektrum der Aussagen klein ist und die Aussagen sich entsprechend leicht standardisieren lassen.


== Datensatz-Verdruß ==
== Datensatz-Verdruß ==
...ist eine interessante FactGrid-Property ([[Property:P17]]):
Die ([[Property:P17]]) ist besonders praktisch - hier die Gesamtabfrage, die jeweils aktuelle Probleme aufscheinen lässt:
* [https://database.factgrid.de/query/embed.html#SELECT%20%3FHuman%20%3FHumanLabel%20%3FAmburger_database_ID%20%3FDataset_complaint%20%3FDataset_complaintLabel%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FHuman%20wdt%3AP2%20wd%3AQ7%3B%0A%20%20%20%20wdt%3AP533%20%3FAmburger_database_ID.%0A%20%20%3FHuman%20wdt%3AP17%20%3FDataset_complaint.%0A%7D Dataset complaints]
* [https://database.factgrid.de/query/embed.html#SELECT%20%3FHuman%20%3FHumanLabel%20%3FAmburger_database_ID%20%3FDataset_complaint%20%3FDataset_complaintLabel%20WHERE%20%7B%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%20%3FHuman%20wdt%3AP2%20wd%3AQ7%3B%0A%20%20%20%20wdt%3AP533%20%3FAmburger_database_ID.%0A%20%20%3FHuman%20wdt%3AP17%20%3FDataset_complaint.%0A%7D Dataset complaints]
:Die "Amburger Datenbankdublette" (Q876303) als Datensatzverdruss kann in Regensburg abgearbeitet werden, sobald sie in dieser Liste erscheint und die beiden Personen-Items hier in Factgrid zusammengeführt sind.--[[User:Martin Gollasch|Martin Gollasch]] ([[User talk:Martin Gollasch|talk]]) 22:18, 7 May 2024 (CEST) Dazu: https://www.wikidata.org/wiki/Talk:Q4466233#c-Rostworowski-20240507192100-Rostworowski-20240507165500


== Weiterführendes ==
== Weiterführendes ==

Latest revision as of 17:16, 30 July 2024

Ausgangslage 14. März 2024

Ziel der ersten Dateneingabe war es zu allen Personen der Amburger-Datenbank korrespondierende FatGrid Items anzulegen, die sich nun von der Amburger-Datenbank aus gegenreferenzieren lassen - ein Matching das bei den folgenden ausstehenden Eingaben als Dreh- und Angelpunkt dienen kann.

Bei der Eingabe fielen unmittelbar zwei Items auf, die als Dubletten zusammengezogen und [vermerkt wurden.

Im zweiten Schritt wurden alle FactGrid-Amburger-Items mit den bislang existierenden Wikidata-Items verlinkt. Diese wiederum wurden Wikidata-seitig mit den FactGrid Items rückverbunden. Die erste Eingabe kam mit Geschlechtsangaben. Aus Wikidata wurden Väter, Mütter, Kinder und Ehepartner verlinkt, soweit die Verlinkungen ihrerseits auf bereits bestehende FactGrid-Objekte verwiesen.

Property:P533 notiert auf jedem Personen-Item die Amburger-ID, über sich nun direkt in den jeweiligen Amburger-Datensatz hinüberschalten lässt. Die folgende Suchabfrage bietet mit minimalem, schnell gehendem Skript immer den aktuellen Stand des Matching:

Importe von Statements aus der Amburger-Datenbank werden sich komplex gestalten. Die Amburger-Datenbank ist eine klassische relationalen Ressource mit Textfeldern, die nicht weiter verlinken. Angaben aus diesen Textfeldern verweisen sowohl auf bereits im FactGrid bestehende (aber nicht schon identifizierte) Objekte wie auf Objekte, die erst zu bilden sind (ohne dass klar ist, wie viele verschiedene Objekte dabei gebildet, identifiziert und mit eingehenden Informationen ausgestattet werden müssen - das betrifft etwa Orte, assoziierte Personen und Organisationen wie Arbeitgeber und Ausbildungsstätten).

Es wird klug sein, Aufgaben, die sich mit geringem Aufwand abarbeiten lassen, vorzuziehen und arbeitsaufwendige später als eigene, komplexe, eventuell Zuarbeit oder Forderung benötigende einzukreisen.

Nachnamen

...sollten einfach sein, da sich hier ein exaktes Matching gegenüber den in FactGrid angelegten Namens-Items herstellen lässt. Fehlende Nachnamen müssen angelegt werden, bevor sie zugewiesen werden können.

Eine Herausforderung werden die Russischen Versionen transkribierter Familiennamen sein. Sind die Transkription eindeutig und damit eindeutig transliterierbar?

Bei Neuanlagen von Nachnamen sollte das bestehende Batch-Fragment benutzt werden.

Vornamen

...sind komplexer als Nachnamen, da wir ihre Reihenfolge wiedergeben sollten, und da hier größere Varianz besteht mit (aufzulösenden) Abkürzungen und Transkriptionen, hinter denen Schreibweisen im kyrillischen Schriftsystem verborgen liegen.

Bei Neuanlagen von Vornamen ist das Geschlecht zu erfassen. Hierzu zur Standardisierung das Batch Fragment benutzen.

Datierungen

...gibt es als Geburt- und Sterbedaten, Daten des Aufgebots bei Eheschließungen und so fort. Eine Herausforderung stellen die divergierenden Kalender alten/julianischen und neuen/gregorianischen Stils dar, wobei Wikibase mittlerweile auch in Masseneingaben über QuickStatements die jeweilige Kalendernotierung erlaubt.

Sind die Kalender durchweg auseinander gehalten? Wie sieht es bei den baltischen Ländern aus? Wie in Weißrussland, sprich im ehemaligen Polnisch-Litauische Großfürstentum?

Wenn wir Daten im Julianischen Kalender importieren, muss bedacht sein, dass die reguläre QueryService-Abfrage diese Daten (ohne spezielle Anweisung) automatisch auf den Gregorianischen Kalender umgerechnet auswirft. Sie dürfen danach nicht mehr als julianische Daten irgendwo notiert werden (oder es geschehen laufende Additionen von 11 bis 14 Tagen). Importe aus Wikidata sind gefährlich, da QuickStatements in den ersten Masseneingaben nur gregorianische Datierungen zuließ. Julianische Daten wurden laufend einfach als Gregorianische fixiert, was speziell im orthodoxen Kalender prekär ist.

Familienverbindungen

Die Amburger-Datenbank ist üppig mit Beziehungsgeflechten ausgestattet, jedoch dies nur oberflächlich, sprich ohne jeweilige eindeutige Identifikation der gemeinten Personen. Vermutlich lassen sich Ehepartner relativ leicht einander zuweisen, da hier sehr oft das Datum des Aufgebots (Property:P1079) exakt notiert und mit Ortsangaben versehen ist. Die diesbezüglichen Angaben sind jeweils bei beiden Ehepartnern identisch womit sich vermutich ein erstes Matching vornehmen lässt.

Hat man die Ehepartner, kann man vielleicht über deren Doppelung die Kinder zuordnen - sie müssen jeweils gleiche Profile Eltern und Kinderseitig aufweisen.

Hier hat uns am Anfang Magnus Sälgö (Q40921) bei FactGrid ziemlich geholfen, indem er einen Schub von geni:IDs neben den Verbindungen zu wd generiert hat. Vllt solltest Du ihn mal anpingen, ob er uns noch einmal helfen kann/mag. Schweden und Finnlandschweden waren ja die nächsten Nachbarn zu Baltikum und der St. Petersburger Ecke Russlands.--Martin Gollasch (talk) 18:56, 14 March 2024 (CET)

Ortsbestimmungen

gibt es wie Datierungen im breiten Spektrum der Positionen. Mit OpenRefine sind bereits gegenüber Wikidata Orte erfasst. Wir sollten die Lokalitäten aber unabhängig vom Amburger-Projekt flächendeckend anlegen - das steigert die Konsistenz der gesamten Anlage.

Aktuell weitgehend erfasst sind

  • Polen
  • Litauen
  • der Oblast Kaliningrad
  • Ukraine (ca. 75%)
  • Tschechien
  • Lettland

Desiderate sind aktuell:

  • die Slowakei
  • Weißrussland
  • Estland
  • Russland

Religion

Sie müsste sich besonders schnell notieren lassen, nachdem das Spektrum der Aussagen klein ist und die Aussagen sich entsprechend leicht standardisieren lassen.

Datensatz-Verdruß

Die (Property:P17) ist besonders praktisch - hier die Gesamtabfrage, die jeweils aktuelle Probleme aufscheinen lässt:

Die "Amburger Datenbankdublette" (Q876303) als Datensatzverdruss kann in Regensburg abgearbeitet werden, sobald sie in dieser Liste erscheint und die beiden Personen-Items hier in Factgrid zusammengeführt sind.--Martin Gollasch (talk) 22:18, 7 May 2024 (CEST) Dazu: https://www.wikidata.org/wiki/Talk:Q4466233#c-Rostworowski-20240507192100-Rostworowski-20240507165500

Weiterführendes

  • Henning von Wistinghausen: Freimaurer und Aufklärung im Russischen Reich: Die Revaler Logen 1773–1820. Band III: Biographisches Lexikon (Q43277) - bislang gefühlt etwa 10-15 % Überschneidung, wobei der extreme Tiefgang bei den v. Wistinghausen-Bios sich qualitativ als sehr hilfreich bemerkbar macht.
  • Scotland, Scandinavia and Northern European Biographical Database (Q800757) - diese Datenbank der Uni St. Andrews hilft bei historischen Personen mit schottischen Wurzeln, die in Skandinavien und/oder Nordosteuropa bis nach Russland von 1580 bis 1707 aktiv waren. Das sind im Zweifel meist Offiziere.
  • Arvo Tering (Hrsg.): Lexikon der Studenten aus Estland, Livland und Kurland an europäischen Universitäten 1561–1800, Böhlau-Verlag, Köln 2018 (Q40931) für die Akademiker des Zeitraums; Tering hätte seinem Werk beim Bearbeitungszeitraum gern 15 Jahre mehr geben dürfen!--Martin Gollasch (talk) 14:24, 10 March 2024 (CET)