Das folgende Kapitel gibt einen Überblick über die Datenformate und Bereitstellungsmethoden, die die Ingest-Pipeline derzeit „versteht“. Routinen zur Erstellung und Integration von Data Feeds in den Culture Knowledge Graph wurden von Mitgliedern der NFDI4Culture-Community zusammen mit dem Culture Knowledge Graph-Team entwickelt. Darüber hinaus werden in Kapitel 4 weitere Formate und Methoden zur Datenbereitstellung aufgeführt, für die solche Routinen in der Entwicklung sind, aber noch nicht veröffentlicht wurden.
Metadaten zu digitalen Repräsentationen und zugehörige Forschungsdaten des materiellen und immateriellen Kulturerbes können im RDF-Format bereitgestellt werden, unter Verwendung der NFDIcore Ontology und insbesondere des NFDI4Culture Ontology-Moduls (CTO). Dies ist das Zielformat, das innerhalb des Culture Knowledge Graph verwendet wird. RDF kann in verschiedenen Serialisierungsformaten bereitgestellt werden, z. B. N-Triples, Turtle oder RDF/XML.
Das Culture Graph Interchange Format (CGIF) ist eine kleine Teilmenge von schema.org. Es ist nicht so funktionsreich wie die im Culture Knowledge Graph verwendete Zielontologie, kann aber ein einfacheres Ziel für die Bereitstellung oder Konvertierung Ihrer Daten sein. CGIF-kompatible Daten können in reguläre Websites eingebettet werden, um regelmäßige Abfragen zu vereinfachen und gleichzeitig die Suchmaschinenoptimierung (SEO) Ihrer Website zu verbessern, da schema.org-Markup von vielen großen Suchmaschinen verwendet wird, um Website-Inhalte zu verstehen und sie entsprechend zu indizieren.
Lightweight Information Describing Objects (LIDO) ist ein in den NFDI4Culture Communities etablierter XML-Standard. LIDO-Dateien beschreiben einzelne Museums- oder Sammlungsobjekte oder Objektgruppen. Die größte Herausforderung bei der Umwandlung dieses Formats für den Culture Knowledge Graph ist die Extraktion von IRIs, da dies keine LIDO-Anforderung ist, insbesondere im Fall des recordInfoLink zur Identifizierung des Objekts.
Eine einfache Möglichkeit, Ihre Daten zur Verfügung zu stellen, besteht darin, sie als Daten-Dump in einem der unterstützten Datenformate (siehe oben) zu übermitteln. Anstatt jede Datei einzeln zur Verfügung zu stellen, können diese Daten-Dumps als einzelne Dateien in Dateiformaten wie JSON oder in einem ZIP-Archiv im Internet verfügbar gemacht werden. ZIP-Dateien/Daten-Dumps können in regelmäßigen Abständen neu abgerufen und ihr Inhalt neu integriert werden. Auf diese Weise können Sie Ihre ZIP-Dateien/Daten-Dumps eigenständig immer dann neu erstellen, wenn sich Ihre Daten ändern (oder wenn Ihr Server nicht stark belastet wird). Wenn Sie einen Speicherort für Ihren Datendump benötigen, wenden Sie sich bitte an den NFDI4Culture Helpdesk.
Wenn Ihre Daten über einen SPARQL-Endpunkt verfügbar sind, können Sie sogenannte CONSTRUCT Queries implementieren, um die Entitäten und Eigenschaften in Ihrem Graphen mit denen zu mappen, die von der NFDIcore/CTO Ontology benötigt werden. Abhängig von der Komplexität der Abfrage und der Datenmenge kann der Harvesting-Prozess jedoch einfacher sein und Ihren Server weniger belasten, wenn Sie die Abfrage in einer lokalen Umgebung ausführen und dem Culture Knowledge Graph Team einen Link zu einem (regelmäßig aktualisierten) Daten-Dump wie oben beschrieben zur Verfügung stellen.
Das Culture Graph Interchange Format (CGIF) ist ein leichtgewichtiges Datenaustauschformat, das auf schema.org basiert. Es enthält eine Option zur Bereitstellung von Daten eines gesamten Feeds, einschließlich Paginierung. Dies ermöglicht ein zuverlässiges und schnelles Harvesting, ohne einen Server zu belasten: Wenn Ihre Website über eine Listenansicht aller Feed-Elemente verfügt, kann das Hinzufügen des erforderlichen Markups zum Template eine sehr einfache Möglichkeit sein, Forschungsdaten für den Culture Knowledge Graph verfügbar zu machen. Alternativ dazu kann CGIF/schema.org auch über dezidierte APIs bereitgestellt werden.
Ein weiterer Ausgangspunkt für das Harvesting Ihrer Daten kann eine einfache Textdatei sein, die die URLs der Dateien enthält, die umgewandelt und integriert werden sollen. Dies kann nützlich sein, wenn Sie z. B. einzelne Feed-Element-Dateien haben, aber keine API oder kein ZIP-Dienstprogramm, um sie miteinander zu verbinden. Die Liste der URLs kann theoretisch dem Beacon-Format ähneln, sollte sich aber auf die Auflistung aller Ressourcen konzentrieren, die übernommen werden sollen, und nicht auf Links zu einer einzelnen Normdatei.
Wenn Sie Ihre Forschungsdaten bereits an einen Aggregator weitergegeben haben, besteht eine weitere Havestingroutine darin, die aggregierten Daten von dort abzurufen. Eine bestehende Routine arbeitet mit den in der Deutschen Digitalen Bibliothek (DDB) gespeicherten Daten und erfordert lediglich die Kenntnis Ihrer Anbieterkennung (ID) bei der DDB. Das Harvesting dieser Varianten Ihrer Daten sollte jedoch nur dann Ihre erste Wahl sein, wenn Sie von der Aktualität, Vollständigkeit und Qualität der Daten überzeugt sind.
Wenn Ihre Daten über eine eigene REST-API verfügbar sind, bieten folgende Routine nützliche Anregungen zur Erzeugung von RDF-Daten gemäß NFDIcore/CTO. Diese sind entsprechend ihrer Ausgangsdaten zu adaptieren: