User:Olaf Simons/Presentation

Integration

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

Repositorium für alte Daten (schwierig, da Datenstandards schlecht sind: Textfelder, Zusatzbemerkungen etc.)
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.
Forschungsumgebung (Unmittelbare Nutzung von Information durch andere, kontrollierte Rezeption der eigenen Forschung noch während man mit ihr befasst ist - bewährt sich.)
Forschungswerkzeug und Zettelkasten (praktisch aber derzeit noch zu mühselig wegen fehlender großer Datenausgangslage; man muss zu oft neue Objekte anlegen.)

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

SPARQL ist ein hermetischer Zugang. Den Query Service kann nur bedienen, wer die Datenlage und die Properties schon kennt.
Musterabfragen bieten geringe Hilfe - nutzen wir aber derzeit auf Projektseiten wie FactGrid:The Gotha Illuminati Research Base
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).
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).

SPARQL Hindernis - jedoch auch Klarheit, dass SPARQL interessant ist
Visualisierungen unterentwickelt (dynamische Visualisierungen, quantitative Darstellungen, Statistiken, historische Karten
Dateneingabe - hier ist der Vorabgleich schwierig, OpenRefine nicht breiter angenommen
Citizen Science braucht Module
Datenlandschaft unterentwickelt - die GND in FactGrid?

Große Datenlage
Breite Bearbeitung durch Forschung
Entwicklung eines attraktiven Frontends, das Dateneingabe von Datennutzung abkoppelt

Suchmaschine
Akkumulation von Information, die in der Datenbank sehr viel breiter vorhanden ist als das einzelne Item es vermuten lässt (etwa im Fall von Personen, zu denen wir Briefe etc. haben, die auf sie verlinken, respektive im Fall von Organisationen und Geographica zu denen wir Informationen aus Dokumenten und Personenbeziehungen sowie Ereignissen haben).

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