Außer die, die über z. B. gedbas.genealogy.net auf eine DB zugreifen. Natürlich bleiben die bestehenden DB unberührt. Das ZdP ist nur die Oberfläche und liefert die Daten, die die mitmachenden DB speisen.
Genial! Aber wie bringt man Google oder Bing oder einer KI bei dort hinzuleiten? Die Suchmaschinen haben doch einen Index aufgebaut, der direkt zum Ziel führt, etwa wenn ich bei Google Suche: „site:*.genealogy.net Hartenthaler“ eingebe, dann lande ich direkt bei den „search results“ in GEDBAS oder im GenWiki oder bei der Metasuche. Wie soll das auf das Zentrum der Projekte umgebogen werden?
Ok, dann brauchen wir auch Menüpunkte wie
- COMPUTERGENEALOGIE
- Blog
- Team
- IT-Betrieb
- VO
- Wordpress-Web-Seite
- …
Und wir brauchen zu jedem dieser Themen, so wie von @jzedlitz angeregt:
- wo finde ich den Dienst, die Dienstleistung, die Daten?
- Wo finde ich die Stelle zum Mitmachen?
- Wo finde ich die Stelle zum Entwickeln?
- …
Suchmaschinen lassen sich doch übder die robots.txt aussperren.
Ja, das ist dann aber ein Widerspruch zu Deiner Aussage:
Wenn wir zukünftig Suchmaschinen den Zugang zu GEDBAS oder zum GenWiki verwehren, dann sind diese Datenbank-Dienste nicht mehr die gleichen wie zuvor. Ich schlage vor, dass Du mir das am Dienstag im Gespräch näher erklärst, damit ich es verstehe.
Nach dem Vortrag von @robertpaessler auf der MV in Bochum ist vielen aktiven Mitgliedern deutlicher geworden, was wir hier vorhaben. Aber es waren natürlich nicht alle dabei. Wo ist der richtige Ort, um die tragenden Leute einzubeziehen, die unsere Projekte und Dienste betreuen? Hier? Oder eher in der Ideenbörse?
@Julche @Gerhard_Stoll @JDrees @jzedlitz @Juling @BSchwend @Christopher_Ernestus @Wolfgang_Fahl und andere.
Es sollen im „Zentrum“ oder „Portal“ (auch andere Namen kommen in Frage) grundsätzlich ja Daten in zwei Richtungen nutzbar gemacht werden:
- Finden von Personen (oder Orten, Adressen, Themen uvm.) an den verschiedensten Stellen (Datenbanken, Projekten, Digibib, Genwiki usw.). Dafür müssen Daten abfragbar sein, wie bisher schon in der Metasuche oder in Geovis. Mein Eindruck ist, dass das läuft, zumindest großteils.
- Nutzer sollen sich merken können, welche Funde zusammengehören, also z.B. sich auf dieselbe Adresse oder dieselbe Person beziehen. Das wird im „Zentrum“ in einer Datenbank gesammelt, die die vom Nutzer zusammengestellten UUIDs oder anderen Identifikatoren zusammenstellt. Diese Daten sollten dann wieder von den verschiedenen Diensten (z.B. Gedbas) angezapft werden können. Auch hier gibt es sicherlich Absprachebedarf.
Name: CompGen Explorer
Warum?
-
Erkunden statt nur Suchen
-
projekt‑ und datenbankübergreifendes Arbeiten
-
Zusammenführen, Vergleichen, Verknüpfen
1 „Gefällt mir“
@GeorgFertig Wo jetzt genau der Ort für die weitere Diskussion sein sollte, kann ich auch nicht sagen. Ich finde es jeden Fall gut, ab jetzt hier einbezogen zu werden, nachdem in Bochum erstmals klar wurde, worum es dabei überhaupt geht.
Zur Namensdiskussion: Sowohl „Portal“ als auch „Explorer“ finde ich bedenkenswert, „Zentrum der Projekte“ eher nicht, weil sperrig (im Sinne der Außenwirkung) und zum Teil auch missverständlich (im Sinne der Innenwirkung auf die Mitarbeitenden der Projekte).
Genau das ist m. E. eine zentrale Frage, die mich schon länger umtreibt. Sollten die UUIDs für CompGen die entscheidende ID sein oder sollte es so etwas wie ein CompGen-Personen-ID geben?
- GND, VIAF, Wikidata werden ja immer nur Personen mit einen gewissen Relevanz umfassen, und nicht potentiell alle Personen, über die genealogisch oder biographisch irgendetwas bekannt ist.
- Wikitree, Familysearch, Ancestry, Geni, WeRelate, Geneanet, FindAGrave oder die norwegischen und schwedischen Bevölkerungsregister haben IDs, die wiederum z. B. als Eigenschaften mit WikiData verknüpfbar sind (z. B. Eigenschaft P2889 „FamilySearch person ID“) usw. So wären Querverbindungen zwischen Datenbanken möglich.
Ist vielleicht OT und zu weit voraus gedacht, aber hängt genau mit dieser Frage zusammen…
Noch ein Punkt, der mir aufgrund von Erklärungen durch @genea.logic an anderer Stelle in Kombination mit meiner aktuellen Arbeit an der JuWeL-Datenbank und einem Gespräch mit @jzedlitz deutlich geworden ist:
Überall dort, wo ein DES-Projekt abgeschlossen ist, gehört es nicht mehr ins DES, sondern in einen neuen Dienst. Bei den Adressbüchern hat Jesper das bereits gebaut: die abgeschlossenen Projekte landen bei adressbuecher.genealogy.net. Das ist auch sinnvoll, weil das eine ziemlich einheitlich strukturierte Quellengattung ist. Wir haben aber alle möglichen anders strukturierten Quellen im DES: juwel, Fahndungsbücher, Sterbebücher, Heiratsbücher, Personalkarteien, Familienkarteien usw.
Wenn so ein Projekt fertig ist, muss jeweils ein neuer Dienst für die fertigen Daten aufgesetzt werden können (ggf. ein Dienst für eine Gruppe von Projekten, die gleich strukturiert sind). Er muss die Daten mit Suchmöglichkeit enthalten, punktgenaue Verknüpfungen mit dem Scan und ein Feld zum Fehlermelden. Aus einem Gespräch mit @robertpaessler eben gerade hat sich nochmal klar ergeben, dass das „Zentrum“ genau hierfür auch geeignet ist.
1 „Gefällt mir“
Ich habe für das JuWeL-Projekt gerade UUIDs auf der Ebene von Ereignissen angelegt. Zuvor gab es UUIDs auf den Ebenen von Verzeichnungseinheiten (=Archivsignaturen) und von Einzeleinträgen (=Personen-Nennungen). Zu einem Ereignis (z.B. einer Geburt) gehören ja mehrere Personen (Vater, Mutter, Kind usw.). Ich will damit sagen: UUIDs können wir auf beliebigen Ebenen anlegen. Eine davon kann auch die einer „Personengleichsetzung“ sein, also: Vater xxx bei der Geburt von Kind yyy im Juwel-Projekt hat den Grabstein zzz im Grabsteine-Projekt. Und diese „Personengleichsetzungen“ kann man dann wieder zusammensammeln, bis man eine Person hat und diese auch mit Wikidata verbindet.
1 „Gefällt mir“
Und das ist nicht nur so für ehemalige DES-Projekte, sondern auch für jedes andere Erfassungsprojekt. So etwa für die Listen von @Eberhard_Sauerbrei . Und wir haben wohl noch etliche solcher Listen/Datenbanken.
Was wir brauchen ist ein Dienstegenerator, der basierend auf der Struktur einer Liste/Datenbank automatisch einen Web- Dienst erstellt. Der Dienst braucht eine Webseite fūr die manuelle Suche/Präsentation der Daten, eine Schnittstelle zur Metasuche und zum Explorer/Zentrum, eine Export-Funktion, eine MCP-Schnittstelle/API für KI, etc.
Ich dachte zunächst ich Träume und habe mal eine Nacht vergehen lassen.
Das klingt zwar alles etwas sperrig, aber das ist doch genau die Funktionalität
auf die ich bei CompGen schon seit mehreren Jahren warte und worüber wir
erst kürzlich in mehreren Videomeetings mit @Wolfgang_Fahl diskutiert haben.
Und dann wurde das ganze erstmal wieder auf unbestimmte Zeit verschoben.
Ich zitiere mal aus unserem damaligen Schriftwechsel
Verbesserte Suchmöglichkeiten kommen natürlich immer gut an, sollten
aber möglichst auch mit einer verbesserten Suchbasis verbunden sein.„If you can’t query it, it does not exist“
Auf Ruhr-Deutsch: Watt de nich has, dat kannze auch nich finden.
Also wenn ihr die notwendige Funktionalität einrichtet, dann würde ich,
wie besprochen, Daten aus meinen Projekten für den Test bereitstellen.
Vielleicht wird’s ja noch was, ich hatte das Thema schon abgeschlossen.
3 „Gefällt mir“
So ein Dienst-Generator muss automatisiert einen standardisierten Container erstellen, der flexibel bezüglich der Datenstruktur ist, aber immer wieder die selbe Funktionalität nach außen bietet, etwa auf einzelne Datensätze per UUID zu referenzieren, einen Daten-Import und -Export etwa für Massendatenoperationen zu bieten, eine Statusüberwachung, eine API, etc.
Alle diese Dienste kann dann der Explorer/Zentrum abfragen und die Daten untereinander verknüpfen ohne dass für den Explorer jedesmal wieder ein neuer Connector programmiert werden muss.
Vielleicht würde sich da ja eine Zusammenarbeit mit dem Projekt Data4Good von https://correlaid.org/ anbieten.
1 „Gefällt mir“
[quote=„Georg.Fertig, post:31, topic:828170“]
Damit ich es richtig verstehe: Die UUID ist ja ursprünglich dafür gedacht, einen von einem User erfassten Personendatensatz eindeutig zu kennzeichen, und zwar im Hintergrund, in der Regel für den Benutzer unsichtbar.
Also bei der Vorgehensweise wie im JUWEL-Projekt kann ich verstehen, dass man zunächst mal Einzeleinträge (=Personen-Nennungen) hat, d. h. ein Personendatensatz bezeichnet im ersten Schritt nur die Personen–Nennung (PERSONA) bei einem Einzelereignis (wobei ein Ereignis mehrere Personen-Nennungen beinhaltet).
„UUIDs auf der Ebene von Verzeichnungseinheiten (=Archivsignaturen)“ kann ich mir im Moment nicht erklären. Sind es wirklich UUIDs? oder andere Kennungen (in der Datebank finde ich neben „Verzeichnungseinheit“ auch die Begriffe „Vorgang“ und „Kennung“ … Ist das irgendwo nachlesbar dokumentiert?
Ja, mir ging es darum, wie diese am Ende durch „Sammeln“ und „Personengleichsetzung“ entstehende „reale Person“ eindeutig gekennzeichnet wird bzw. werden soll. Ist die UUID (die ja ursprünglich einen anderen Zweck hat) da wirklich die geeignete Wahl oder sollte CompGen den Weg aller anderen großen Datenbankbetreiber gehen und eine eigene Personen-ID für eine reale (gesichert aus mehreren Fakten erkannte) Person erstellen soll.
Wenn ich UUIDs richtig verstehe, ist das einfach ein langer durch Zufallsoperationen generierter String, der so lang ist, dass Doppelungen statistisch ausgeschlossen sind. Insofern kann das für
benutzt werden oder für alles mögliche sonst.
waren in den JuWeL-Daten schon vorhanden. Ich nehme an, weil das Landesarchiv die so benutzt.
Im FactGrid gibt es für eine reale Person zwei Kennungen: eine Q-Nummer und ein Label. Hier z.B. eine SPARQL-Abfrage, die für alle bisher in meinem Neckarhausen-Projekt erfassten Personen ausgibt. Sie nutzt den Service wikibase:label. Die (eindeutige) Q-Nummer ist so ein technisches Ding, durch das (nicht eindeutige, aber sprechende) Label wird sie verständlich. Ich würde für die „realen Personen“ in diese Richtung gehen. @jzedlitz und @Wolfgang_Fahl können dazu sicherlich auch etwas sagen.
Eine UID ist erst einmal etwas was Datensätze eindeutig kennzeichnet, nicht reale Personen oder Ereignisse oder Quellen. Die UID ist weltweit eindeutig, aber etwas sperrig für uns Menschen, da nicht sprechend. In anderen Systemen werden andere Identifikatoren verwendet, etwa die Q-Nummer bei Wikidata oder FactGrid.
Wenn aus mehreren Quellen Datensätze mit unterschiedlichen UID kommen (beispielsweise A = ab1243ce64232677ddddd; B = 45de7662828eeee942626; C; D; E; F) und es Indizien gibt, dass diese zusammengehören, soll es das Zentrum der Projekte erlauben, die Zusammengehörigkeit zu dokumentieren. Etwa: Quellendatensatz A beschreibt die selbe Quelle wie Quellendatensatz B; Ereignisdatensatz C beschreibt das selbe Geburtsereignis wie der Ereignisdatensatz D; Personendatensatz E und F gehören zur selben Person.
Ich bezweifle, dass wir im Genealogienetz eine weitere Personen-ID, eine Ereignis-ID oder eine Quellen-ID brauchen.
Ok, wir haben ein bisschen aneinander vorbeigeredet. Eine UUID ist tatsächlich erstmal ein ganz allgemeiner Schlüssel von 128 Bit. Ich hatte mich, ohne das deutlich genug zu sagen, auf die im GEDCOM-Standard definierte UID oder UUID bezogen. Und diese bezieht sich auf Personendatensätze. Wenn 20 Forscher die gleiche Personen unter ihren Vorfahren haben, diese in ihrem Genealogieprogramme einpflegen, ihre Daten als GEDCOM speichern und dies in einer öffentlichen Datenbank hochladen, hat die Person 20 UUIDs (es können auch 100 oder 1000 sein, je nachdem wieviele Forscher die Persone als Vorahr oder sonst relevante Person in ihrem Datenbestand haben), und zwar völlig konform mit dem GEDCOM-Standard.
Immerhin verhindert GEDCOM-UUIS zusätzliche Duplikate in folgendem Fall: Der Forscher speichert seine Daten noch einmal, lädt vielleicht einen Teilbestand erneut hoch. Dann sorgt die GEDCOM-UUID dafür, dass diese erneut aus dem gleichen GEDCOM-Bestand hochgeladenen Personendatensätze als identisch erkannt werden können. Jesper hat das vor einiger Zeit in GEDBAS realisiert und für den beschriebenen Fall funktioniert es.
Im allgemeinen gilt aber die (GEDCOM-)UUID als etwas Sperriges, mit dem der Benutzer nicht in Berührung kommen sollte, also etwas, was nur zur Kommunikation zwischen Maschinen bzw. Programmen genutzt wird. Und die (GEDCOM-)UUID ist eben keine eindeutige Kennung einer Person, sondern eines Personendatensatzes, der von irgendeinem Forscher auf der Welt angelegt worden ist.
Nicht nur, jeder Datensatz und jedes Ereignis kann eine UUID bekommen. Also auch SOUR oder INDI:BIRT, nicht nur INDI.
Zu allen anderen Aussagen von Dir: 100%-ige Zustimmung.