FactGrid talk:Remove NA: A LGBTIQ*-Knowledge Graph

From FactGrid
Jump to navigation Jump to search

Musterobjekte

Personen

Ereignisse

Vertrag

  • Unification Treaty between the Federal Republic of Germany and the German Democratic Republic (1990-08-31) - hier würde ich Target group herausnehmen und Betroffene P751 benennen. Bei der localisation würde ich nur das Kronprinzenpalais übrig lassen und die Suche auf dessen Lokalisierung ausrichten. Deutschland ist hier bei Berlin hinterlegt. "Context" kommt mir auch nicht passend gesetzt vor, Du willst eher sagen, dass es in dem Feld Auswirkungen hatte. Das sind statements, die im tangierten Feld unterzubringen sind (da es tausende Felder gibt, auf denen sich damit was änderte...) --Olaf Simons (talk) 17:25, 3 June 2022 (CEST)

NS-Opfer

Ich habe einen Testimport gemacht, nach dem Beispiel würde ich weitere hochladen: Karl Siegl - fehlen dabei Angaben? Was sollte ich ergänzen? Vermutlich werde ich noch eine "Notiz" hinzufügen, in dem z.T. recht unstrukturiert Zeitangaben stehen, die sich zT nicht ganz zuordnen lassen. Außerdem würde ich gerne pro Item eine Quelle angeben. Was wäre die Property dazu? In diesem Testfall wäre das "KZ-Gedenkstätte Dachau".

Hierarchien und andere Beziehungen zwischen Organisationen

Organisationen können verschiedenartige Beziehungen haben. Bisher sind folgende in Betrieb:

Diese Query zeigt die bisher vergebenen Beziehungstypen.

Offene Punkte

Default-Modus: Von Klein zu Groß oder umgekehrt?

Jetzt ist so, dass sich Dachorganisation vom Großen zum Kleinen bezieht und Filiale anders rum. In der Query oben kommen nun alle zusammen. Das ist in sich nicht logisch, eh klar. Jetzt Bedarf es meiner Meinung nach zumindest implizite Regeln, was der Standardmodus ist: Ein pragmatischer Angang kann sein, die Beziehung von Klein zu Groß immer zu setzen, von Groß zu Klein umgekehrt ist nice to have. Denn ja, natürlich kann man immer händisch beide Richtung setzen, das ist meines Erachtens aber 1) unrealistisch, dass das immer gemacht wird und 2) nutzt man dann nicht die Abfragemöglichkeiten.

Gibt es dazu Überlegungen aus anderen Projekten?

Oder gibt es ein Skript, das regelmäßig alles durchkämmt bei Filialen ggf. fehlende Dachorganisationen setzt?

Der Standard ist von klein zu groß linken - einfach weil man damit auf der sicheren Seite bei der Datenmenge bleibt. Eine Organisation mit 3.000 Mitgliedern zerbricht (das Limit liegt irgendwo bei 1,500, so ein Test, den ich mal durchführte). Besser also bei 3.000 Mitgliedern die Anbindung zur Organisation vermerken.
100% konsistent sind wir dabei nicht. Etwa bei Ereignissen vermerken wir die Mitglieder, doch kamen dann Ereignisse mit Hunderten Teilnehmern... --Olaf Simons (talk) 13:36, 8 June 2022 (CEST)
In Ordnung. Dann mach ich das so! Katharina Brunner (talk) 13:48, 8 June 2022 (CEST)
Ein ähnlich gelagerter Fall sind Gründer*innen: Ich kann die Personen an die Organisationen hängen - oder die Organisationen an die Personen. Ich befürchte, ich mach das inkonsistent. Gibt es da Erfahrungswerte? Katharina Brunner (talk) 13:56, 8 June 2022 (CEST)
Es hat sich irgendwie als praktisch erwiesen die Gründer auf den Organisationen zu vermerken, auch weil es kein "Career Statement" Gründer von XYZ gibt - das müsste man zu viele bauen.
Bei Funktionen wird es sehr schnell praktisch, sie als einzelne Items zu gründen (Pfarrer von St. XY) - dann, wenn lange Serien von Leuten einen Posten einnehmen.
Es fand Personen-seitig eine Bewegung statt, möglichst viel über P165 Career Statement laufen zu lassen und die Statements in logische Strukturen zu bringen. Du kannst dabei schlicht "Pfarrer" sein, oder "Pfarrer von St Anna im Lehel", falls Du die Präzision brauchst und ein Label dazu generieren willst (dass dann Subclass von Pfarrer ist.).
Andererseits hat "Employed at" (ich kann nur die Englischen Labels auswendig) viel Stellenwert gewonnen.
Man kann hier Inkonsistenz brandmarken, viel hat aber auch damit zu tun, dass man nicht immer die Datenlange hat, um die Alternative genauso gut laufen lassen zu können. Auch kommen granulierte Systeme sehr schnell mit einer bestimmten Datenlage. Für den, der eines baut, ist es gut, einfach die Aussagen wiederzugeben; aber für den der nachher vor eine SPARQL-Suche verstehen muss, was da los ist, ist es die Hölle. Keine gute Antwort meinerseits, ich weiß. (Vielleicht auch müssen wir verstehen, dass wir hier nahe an normalem Denken arbeiten. Viele Items sind "gut lesbar", ohne Datenkonsistenz zu gewinnen, da man dasselbe so oder so sagen kann und das als Mensch sofort versteht. Vielleicht liegt die Zukunft in Maschinen, die "verstehen", dass man Dinge so oder so sagen kann, ohne dass es einen Unterschied macht...) (Schon wieder datentechnisch keine gute Antwort) --Olaf Simons (talk) 14:33, 8 June 2022 (CEST)

Abgrenzung Filiale - Repräsentiert in

Wie grenzt sich Filiale von Repräsentiert in P328 ab?

Du kannst eine Filiale von Audi sein, aber in der Handwerkskammer deines Ortes repräsentiert sein.
Okay, verstehe.

Zudem schlage ich eine Umbenennung von Filiale des Lead-Labels in Unterorganisation o.ä. vor, um nicht nur Unternehmensspezifische Relationen zu benennen. --Katharina Brunner (talk) 12:52, 8 June 2022 (CEST)

An Unternehmen dachte am Anfang niemand. Wir kamen von Filial-Logen (gegenüber Mutterlogen). Ich bin mir nicht sicher, was das beste Label für alle Fälle ist. Müsste man sich mal an einer Abfrage ansehen. --Olaf Simons (talk) 13:36, 8 June 2022 (CEST)
In der Property ist ja auf die Wikidata-Variante verwiesen. Die englischen Bezeichnung sind ohnehin identisch, auf Deutsch heißt es dort "nachgeordnete Organisation", das ist eigentlich ganz gut. Das nimmt vieles mit.

Teilnehmende an Events

Bisher sind die Events der Ausgangspunkt für Personen, Organisationen, Orte. Ist es sinnvoll, die für zum Beispiel eine Person relevanten Ereignisse direkt an die Person zu hängen?

Bei den Büchern habe ich das bereits gemacht. Etwa bei Magnus Hirschfeld, der ein "Werke publiziert" hat. Er ist aber auch bei Ereignissen beteilt, hier zu sehen.

Meine Frage: Sollte ich diese Ereignisse bei einer Person hinterlegen? Und wenn ja, gibt es bereits eine passende Property? Etwa P119 Teilnehmer an? Solche Verweise kann es aber auch bei Organisationen geben und nicht nur bei Personen.

Ein Graph dazu ist hier zu finden.

Katharina Brunner (talk) 14:12, 8 June 2022 (CEST)

Generell würde ich bei Ereignissen wie bei Dokumenten und Büchern die Hinterlegung Personenseitig nicht machen. Das Problem sind wieder die Mengen. Es gibt Leute die Hunderte von Dokumenten verfassen. Und zu Ereignissen: Wir haben Tagebücher mit Hunderten von Begegnungen. Person X trifft Y, wird bei X und Y verkerkt. Das Treffen V, W, X, Y und Z vermerkt auf 5 Seiten jeweils alle vier getroffenen Personen... Da ist es besser nur auf Dokumenten, Ereignissen, Büchern die Angaben zu machen. Wir haben dennoch die Properties für die gegenläufige Option, insbesondere, da es sehr viele obskure Personen gibt, bei denen man dankbar ist für das eine Dokument, das Klarheit bot. --Olaf Simons (talk) 14:41, 8 June 2022 (CEST)