User:Olaf Simons/Presentation

FactGrid Vorstellung GND4C --Olaf Simons (talk) 12:54, 19 January 2023 (CET)

Integration

1. Gotha3
2. Wikimedia https://blog.factgrid.de/archives/118
3. DNB/GND https://blog.factgrid.de/archives/1475
4. NFDI4Memory https://blog.factgrid.de/archives/3104

Geschichte der Plattform

1. Der Datensatz, an den sich anbauen ließ FactGrid:The Gotha Illuminati Research Base
2. Projekte, die im erst einmal leeren Raum entstehen: FactGrid:Projects
3. Projekte, die ganze Fachbereiche aufbauen - wie das FactGrid:Cuneiform Project
4. Jährliche Verdoppelungsrate im Datenvolumen - und das scheint vorerst so zu bleiben; wir stehen derzeit bei 470.000 Datenbankobjekten.

Angebote: Das FactGrid als Dienstleister

• Klarnamen-Politik FactGrid:Nutzungsbedingungen
• Anforderung des transparenten Projekt-Handlings
• Arbeit ohne Relevanzkriterien
• Kollaboration an denselben Daten muss erwünscht sein
• Vernetzung im Inneren der Projekte untereinander
• Vernetzung nach außen: GND und Wikidata-Abgleich und Austausch

1. Repositorium für alte Daten (schwierig, da Datenstandards schlecht sind: Textfelder, Zusatzbemerkungen etc.)
2. Ziel-Repositorium für laufender Projekte: Wir liefern unsere Daten am Ende ein (oder wollen bis dahin unsichtbar auf der Plattform suin). Mein Rat ist hier stets: nicht erst am Ende Daten einspielen, eher das Projektdesign im Antragsstadium noch auf laufende Interaktion ausrichten.
3. Forschungsumgebung (Unmittelbare Nutzung von Information durch andere, kontrollierte Rezeption der eigenen Forschung noch während man mit ihr befasst ist - bewährt sich.)
4. Forschungswerkzeug und Zettelkasten (praktisch aber derzeit noch zu mühselig wegen fehlender großer Datenausgangslage; man muss zu oft neue Objekte anlegen.)

Was sich bewährt hat

1. Kooperation (Die Software lässt mehrere Antworten auf eine Frage zu und erlaubt konfligierende Belege)
2. Fruchtbares Klima (unsere Sorge sind nicht Edit-Wars, sondern isolierte Projekte)
3. Wissensakkumulation (bei uns hat Information Platz, die in Artikeln nicht unterzubringen ist, wir unterscheiden uns hier von Wikidata und der GND im Projekt)

Problemstellen

Adressaten draußen

1. SPARQL ist ein hermetischer Zugang. Den Query Service kann nur bedienen, wer die Datenlage und die Properties schon kennt.
2. Musterabfragen bieten geringe Hilfe - nutzen wir aber derzeit auf Projektseiten wie FactGrid:The Gotha Illuminati Research Base
3. Die Datenbankobjekte verwirren - vergleiche: Item:Q133 und die hier viel instruktiveren Visualisierungen Bruno Belhostes (https://database.factgrid.de/viewer/item/Q133) und Michael Ringgaards (https://factgrid.ringgaard.com/kb/Q213880).
4. Wir verfügen über zwei FactGrid Browser/Viewer, doch die bieten keine konklusiven Oberflächen.

• Benötigt werden interne Suchoberflächen und Menüführungen.
• Wichtig ist, dass Google auf den Viewer verweist, nicht auf die Items im FactGrid (die man erst zur Bearbeitung aufsuchen will).

Arbeit der Wissenschaftler

1. SPARQL Hindernis - jedoch auch Klarheit, dass SPARQL interessant ist
2. Visualisierungen unterentwickelt (dynamische Visualisierungen von Abläufen über die Zeit hinweg, quantitative Darstellungen (etwa wie viele Briefe gehen von einem Ort aus (so wie wir sie bei Corona Hotspot Landkarten hatten), Statistiken, Integration von Befunden auf historische Karten).
3. Dateneingabe - hier ist der Vorabgleich schwierig, OpenRefine nicht breiter angenommen (muss z.B. erst installiert werden).
4. Citizen Science braucht Module (auf denen die Bürgerwissenschaftler*innen unter sich und unter unmittelbarer Betreuung sind, sie wollen zumeist gar keinen eigenen Konten, und wollen auch nicht mit der ganzen Datenbank kommunizieren. Eingabeschablonen, die Daten sammeln, die dann durch die Projektleiter*innen eingefügt werden, sind hier notwendig).
5. Datenlandschaft unterentwickelt, wir hätten gerne alle in der GND bekannten Personen mit Basis-Date im FactGrd.

• Dubletten-Risiko (Zehntausende Dubletten können unsere Mitspieler nicht bereinigen, wir dürfen keine Datenhalde erzeugen).
• Datenfeinheit gegenüber Wikidata (ein Vorabgleich wäre hier wünschenswert).
• Wir sollten einen laufenden Datenfluss in beide Richtungen anvisieren, bei dem Fehlerbereinigungen in beiden Instanzen (durch Bots) geschehen.
• Koordinierte Arbeit mit der DNB/GND als Partner (statt eines Alleingangs unsererseits hätten wir lieber ein GND-Team an Bord).

Desiderate

1. Große Datenlage, die es Projekten erspart laufend neue Objekte anlegen zu müssen.
2. Breite Bearbeitung durch Forschung, je mehr Forscher*innen an und mit der allgemeinen Datenlage arbeiten, desto besser.
3. Entwicklung eines attraktiven Frontends, das Dateneingabe durch Forscher*innen von Datennutzung durch Öffentlichkeit abkoppelt, do beides offen sichtbar gestaltet.

• Das neue Frontend braucht eine Suchmaschine und Menüführung, die mit dem den eigenen Seiten kommuniziert.
• Das neue Frontend muss Daten aus der Vernetzung in der Datenbank auf den Item-Seiten verfügbar machen, die es generiert (etwa im Fall von Personen: deren Briefe listen, respektive im Fall von Organisationen und Geographica die Personenbeziehungen und die Ereignisse integrieren, die jeweils Personen und Ereignisseitig abgelegt sind).

Skalierbarkeit

1. Wir sind nicht wie Wikidata ein Pool der sich selbst einbringenden Individuen, sondern Plattform von Projekten (die einen anderen Betreuungsanspruch haben).
2. FactGrid hat sich selbst organisierende Communities, doch brauchen diese einen Helpdesk und Redaktionsräume.
3. Wir sollten in der NFDI mit einer Agentur zusammenarbeiten, die Projekte berät.
4. Die Gruppen und Einzelnen auf der Plattform müssen einen eigenen Trägerverein gründen.