FactGrid talk:Erik-Amburger-Datenbank: Difference between revisions
Olaf Simons (talk | contribs) |
Olaf Simons (talk | contribs) |
||
| 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 | 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 | 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 | 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 == | == Nachnamen == | ||
Revision as of 21:10, 14 March 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 bestehenden herstellen lässt. Fehlende Nachnamen müssen angelegt werden, bevor sie zugewiesen werden können.
Herausforderung: die Russischen Versionen transkribierter Familiennamen (scheinen nicht in der Amburger-Datenbank notiert, sind aber vielleicht über die wissenschaftliche Transkription (?) rekonstruierbar.
Bei Neuanlagen von Nachnamen zur Standardisierung das Batch-Fragment benutzen.
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 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.)
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.
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.
Hat man die Ehepartner, kann man vielleicht über deren Verbindung die Kinder leichter Paaren als einzelnen Personen zuordnen.
- 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.--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
Desiderate sind aktuell:
- Slowenien
- Weißrussland
- Lettland
- Estland
- Russland
Religion
Dies müsste eine besonders schnell herstellbare Aussage sein, nachdem das Spektrum der Aussagen klein ist.
Datensatz-Verdruß
...ist eine interessante FactGrid-Property (Property:P17):
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)