This paper presents an approach to representing, discovering, and exploring research (meta)data in the cultural heritage (CH) domain. One key component is the NFDI4Culture Ontology (CTO), a modular ontology for CH research data. Aligned with the Basic Formal Ontology (BFO) and extending the mid-level ontology NFDIcore, CTO enables structured, interoperable metadata integration across diverse CH domains. Another key component is the lightweight Linked Data platform SHMARQL, which supports querying and storytelling with RDF data, ofering new possibilities for data discovery, reuse, and cross-domain integration. Both CTO and SHMARQL are integrated within NFDI4Culture, a consortium of the German NFDI programme for the national research data infrastructure that focuses on material and immaterial CH data. NFDI4Culture aims to make heterogeneous and decentralized research data findable and interoperable through the NFDI4Culture-KG and Portal. Designed with modularity and reuse in mind, both tools demonstrate great generalizability and have been successfully applied beyond their original CH context.
In response to the accelerating growth of scientific publications and research artifacts, research
knowledge graphs (RKGs) have gained prominence1 [
ceur-ws.org by diferent institutions and using distinct metadata standards. Although this diversity reflects the richness of CH data ranging from art object descriptions to musical scores and historical performance events, it also resulted in data silos that prevent unified discovery and analysis. The lack of a common representation and access point for these distributed resources not only constrains data findability and interoperability, but also limits the potential for broader scholarly knowledge integration, as e.g., linking CH data with other scientific domains.
NFDI4Culture has recognized the need for an approach that represents and links CH research data in
a unified way, while respecting the specific requirements of the domain. In line with the broader vision
of scientific KGs, NFDI4Culture has been creating a unified KG 3 for CH research data with the goal of
providing a centralized, semantic index over decentralized and heterogeneous data sources. In doing
so, CH datasets from diferent institutions and disciplines are discoverable and queryable, enabling
researchers to ask complex questions across silos. One key component of this efort is the NFDI4Culture
Ontology (CTO) [
The SHMARQL tool is another key component as part of the NFDI4Culture efort. The Linked Data publishing platform has been created to easily browse the structure of the data in a KG. The tool, originally created for NFDI4Culture, has now been adopted by a number of diferent disciplines and projects. Both, CTO on the side of data representation and SHMARQL on the side of discovery and the publication of LOD are fully integrated into the NFDI4Culture Information Portal4. The portal makes available the data by means of a public SPARQL endpoint5 with currenly more than 70m triples has been made publicly available6.
This paper is guided by the following research questions: RQ1: How can cultural heritage research resources be represented to establish a unified index and centralized access point for decentralized and heterogeneous research data within the (German) cultural heritage landscape? RQ2: How can the requirements of the cultural heritage domain for the representation and discovery of research resources be met, while also providing interoperability to other domains, i.e. other NFDI consortia and beyond? RQ3: How can cultural heritage research resources be published and queried efectively to enable the discovery of decentralized research resources through a unified and centralized access point? The contributions in this paper include: C1: Knowledge representation for CH research: The NFDI4Culture Ontology (CTO) has been created for CH research (meta)data. CTO extends NFDIcore and maps to BFO and standard vocabularies (e.g. Schema.org). This paper also contributes lessons learned from applying earlier versions of CTO in a productive system. These experiences informed the development of version 3.0 and may serve as guidance for similar eforts in other domains. CTO was released on github 7.
A documentation is provided8 along with a list of resources9. The NFDI4Culture-KG, built on 3NFDI4Culture-KGhttps://nfdi4culture.de/services/details/culture-knowledge-graph.html 4NFDI4Culture Portalhttps://nfdi4culture.de/ 5Public SPARQL Endpointhttps://nfdi4culture.de/resources/knowledge-graph.html 6Public Dashboardhttps://superset.nfdi4culture.de/superset/dashboard/culture-kg-kitchen/ 7https://github.com/ISE-FIZKarlsruhe/nfdi4culture 8https://nfdi.fiz-karlsruhe.de/4culture/ 9https://nfdi.fiz-karlsruhe.de/4culture/ontology/
CTO and NFDIcore, is accessible via a SPARQL endpoint10 and currently contains more than 70m triples. Its current statistics are available through a dashboard11 C2: Discoverability via SHMARQL: The versatile SHMARQL tool provides a lightweight web user interface for scholars to intuitively navigate the graph, create queries, and visualize results without deep technical expertise. It further serves as a semantic web application framework on which experienced practitioners can build custom projects disseminating datastories explaining and analyzing their KGs. It is available as open-source software 12 with online documentation 13 .
In the following sections, the contributions of this work are placed within their scientific context (Section 2), followed by a description of the newly published CTOv3.0, which marks a substantial revision from earlier versions and is presented for the first time (Section 3), as well as the implementation of SHMARQL (Section 4). Section 5 highlights how these contributions are embedded within the NFDI4Culture framework.
This section relates the contributions of this paper to two areas central to this approach: ontologies developed for representing research data, and tools that support the publication and exploration of Linked Data.
The Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) [
The VIVO ontology [
Although CIDOC-CRM16 is widely used in the CH and digital humanities domains for research data management, it was originally designed to represent cultural objects, events, and their relationships. While CIDOC is well-suited for many heritage contexts, its event-based modeling paradigm is insuficient for the interdisciplinary requirements of the research addressed in this contribution, which demands a process-based approach.
The Scientific Knowledge Graphs Interoperability Framework (SKG-IF) 17 addresses interoperability by providing a high-level reference model for aligning heterogeneous scholarly graphs. The Core Data Set for Research (KDSF)18 is a standardized model to represent research information within the German 10https://nfdi4culture.de/resources/knowledge-graph.html 11https://superset.nfdi4culture.de/superset/dashboard/culture-kg-kitchen/ 12https://github.com/epoz/shmarql 13https://shmarql.com/ 14https://www.dublincore.org/resources/glossary/ontology/ 15http://motools.sourceforge.net/event/event.html 16https://www.cidoc-crm.org/ 17https://skg-if.github.io/ 18https://kerndatensatz-forschung.de/ academic system, designed to harmonize research reporting across universities and research institutions. However, KDSF is tied to national structures and reporting requirements, which makes it overly specific for the broader, cross-disciplinary scope of this work.
The DCAT vocabulary19 enables standardized dataset and data services descriptions to enhance discoverability across web-based catalogs. However, DCAT operates exclusively at the metadata level and lacks the semantic depth required to model domain-specific content, relationships, and provenance information. Although DCAT may complement certain aspects of research data infrastructure, it is not suitable for the sophisticated ontological modeling presented in this contribution.
Schema.org20 is a community-driven standard for structuring web data, including research data, to enhance discoverability and integration with web technologies. However, its limited semantic expressivity, inherent ambiguity, and incompatibility with certain domain standards (e.g., materials science), render it insuficient for the requirements of this work. To address this limitation, the contributed NFDIcore ontology provides Schema.org mappings, while the NFDI4Culture ontology selectively reuses relevant terms.
Several tools have been developed to support RDF data exploration and querying, addressing user needs
ranging from visual interfaces to advanced querying functionalities. The following section reviews
prominent examples focussing their relationship to SHMARQL functionality. The RDF Playground [
Linked Data browsers enable users to navigate Linked Data through interfaces that emphasize entities
and their interconnected relationships. For instance, LodLive [
Another category of RDF discovery tools comprises graph visualization platforms, such as GraphDB22 and Stardog Studio23. These tools enable users to interact with RDF data through intuitive visualizations that illuminate relationships between entities, thereby facilitating navigation of complex datasets for non-expert users. While these platforms enhance discovery through graphical representations of RDF data, SHMARQL adopts a fundamentally diferent approach centered on querying and exploring RDF data via SPARQL endpoints. This enables users to directly interact with and retrieve targeted data from any RDF knowledge graph without depending on pre-configured visual interfaces.
In summary, all aforementioned tools aim at providing streamlined and user-friendly approaches for 19https://www.w3.org/TR/vocab-dcat-3/ 20https://schema.org/ 21https://github.com/linkeddatacenter/app-lodview 22https://graphdb.ontotext.com/documentation/11.0/index.html 23https://www.stardog.com/studio/ RDF data discovery and exploration. SHMARQL distinguishes itself by ofering an on-the-fly approach that enables users to immediately explore RDF data by simply providing the URL of any SPARQL endpoint. Unlike other tools, SHMARQL’s integration with full-text search via Fizzysearch24 simplifies the incorporation of full text queries into SPARQL. This integration makes SHMARQL capable of both efortlessly querying existing KGs and publishing new ones with minimal configuration requirements.
NFDI4Culture aims to establish an information infrastructure for material and immaterial CH research
data. Throughout the NFDI4Culture project, a KG has been developed and integrated with the Culture
Information Portal, utilizing the NFDI4Culture Ontology (CTO) as its foundational model. CTO supports
the integration of research metadata through a dedicated ETL (Extract, Transform, Load) pipeline. The
NFDI4Culture-KG provides a single point of access to decentralized cultural heritage research resources
serving as an index of the communities’ research data. The comprehensive development of the KG
and Portal has been presented in previous work [
The requirements for the development of CTO were initially derived from user stories collected together
with the scientific communities engaged in NFDI4Culture at the beginning of the project involving
GLAM institutions (galleries, libraries, archives, museums), universities, academies, as well as individual
researchers. The user stories are publicly available25 and the extracted requirements are discussed
in [
REQ2: Domain Requirements and Granularity: Individual domains like musicology and the performing arts required more expressive representations than initially anticipated.
REQ3: Authority Data: In CH data references to authority data and external vocabularies are essential for identification, classification, and for revealing connections between datasets by linking entities across diferent sources. Supporting these references in a way that is more structured, understandable, and efectively queryable way became a key consideration for the revised design. REQ4: Licensing and Rights Statements: The integration of research metadata into the KG and, consequently, into the portal revealed the need for a more nuanced representation of licenses and rights statements, i.e. to support both structured license URIs and natural language usage restrictions, depending on the level of detail and format given by the data providers. REQ5: BFO Alignment: CTO extends NFDIcore, which in earlier versions was aligned with BFO 2.0.
Following a joint decision by the NFDIcore stakeholders to update the ontology and align with BFO 2020, a new requirement for the revised version of CTO was to adopt this alignment, ensure consistency with the NFDIcore ontology, and support interoperability across NFDI consortia. REQ6: Persistent IRIs and Label Independence: Experience gained from integrating CTO in a productive system revealed that human-readable labels needed to be decoupled from technical identifiers to ensure long-term maintenance, reliable referencing, and stable querying as the ontology evolves. 24https://github.com/ISE-FIZKarlsruhe/fizzysearch 25https://nfdi4culture.de/resources/user-stories.html REQ7: Transparency, Collaboration, and Quality Control: A more transparent, reproducible, and quality-controlled ontology development process was needed to better support collaboration across contributors and facilitate easier reuse of CTO.
To support interoperability across the diverse domains represented within the NFDI, which spans all scientific disciplines and humanities, and to enable federated queries across multiple consortia, a modular ontology design has been adopted. This approach balances the shared goals and structures of NFDI consortia with their individual disciplinary requirements, enabling both cross-domain knowledge discovery and domain-specific representation (REQ5).
At the center of this modular approach is NFDIcore [
NFDIcore was initially developed based on user stories and competency questions provided by
the consortia NFDI4Culture, NFDI4Memory26, NFDI-MatWerk27, and NFDI4DataScience28 [
To meet the specific needs of individual domains, NFDIcore is designed to be extended by
application ontologies such as CTO, the NFDI-MatWerk Ontology (MWO) [
CTO is designed to represent CH research data within the framework of a unified data index. Its primary scope is to enable centralized access to decentralized resources from the domains of musicology, performing arts, media studies, architecture, and art history. Thereby, CTO focuses on three core areas: (1) the representation of the consortium and its infrastructure, including persons, organizations, services, standards, and events; (2) the content of cultural heritage research data, such as objects, persons, locations, and events referenced in the metadata, along with associated media and external vocabulary links; and (3) access and reuse aspects, including legal statements, licenses, contact information, and supported export formats.
The ontology’s structure comprises four main components, illustrated in figure 2. A schema:DataFeed represents a data feed created and maintained via the Culture Information Portal once a data provider is ready to integrate their data. Each feed is described by metadata such as contact persons, licenses, export formats, and institutional afiliations. For each record within a feed, a persistent ARK-ID is issued as a schema:DataFeedItem. This stable reference entity contains minimal metadata (e.g., license and timestamps) and functions as a durable anchor in the KG, even if the underlying content is altered or deleted.
Content-related metadata are associated with a cto:CTO_0001005 (source item), representing the provided research resource. This includes media references, external identifiers, temporal metadata, and subject-specific details such as musical incipits (usually the first few bars of a musical piece, presented in standard music notation). A source item may also be linked to the real-world entity it describes (e.g., sculpture, building, person, or text); however, this linkage is only materialized when explicitly stated in the source data.
Figure 3 illustrates the use of CTO in the musicology domain. The source item Frühlingsgruß is published by the organization RISM Online29, which aggregates musical records from international collections. The associated person Robert Schumann is referenced in the original provider data. To preserve the lightweight design (REQ1), the specific relationship type is not modeled in detail but represented using the cto:CTO_0001009 (has related person) property, because in the index it is merely relevant to know ”which persons are related to this data feed”. The same modeling approach applies to related events, organizations, and locations.
An ARK-ID30 is assigned to the entity Robert Schumann in the KG due to its relation to Frühlingsgruß in the provider metadata. Since the RISM identifier is provided in the source metadata, and such identifiers must be queryable (e.g., ”Select all entities with a RISM identifier ”), the class nfdicore:NFDI_00001016 (nfdicore: rism identifier) is introduced as a subclass of iao:IAO_0000578 (iao: centrally registered 29https://rism.online/ 30https://arks.org/about/ark-overview/ identifier), as specified in REQ3. Additionally, the representation of lyrics and incipits addresses a subject-specific requirement in the musicology domain (REQ2).
Likewise, the modeling example for the performing arts domain is shown in figure 6 in Appendix A.
In this case, the provider URI references the schema:TheaterEvent which was integrated as a subclass
to bfo:BFO_0000003 (occurrent). The source metadata includes the AAT classification 31 ”plays”32.
To support such classifications, the class cto:CTO_0001027 (cto:classifier) was introduced, following
the design pattern to the nfdicore:NFDI_0000015 (nfdicore: identifier) classes. In addition to AAT,
CTO incorporates various classification systems, including Iconclass [
The presented approach addresses RQ1 by providing a consistent representation framework that supports data harvested from multiple domains within the cultural heritage landscape. Through its structured integration with the Culture Information Portal, CTO facilitates centralized access while maintaining the decentralized nature of data storage and ownership. RQ2 is addressed by showing how CTO meets the specific needs of the cultural heritage community while remaining interoperable with other NFDI consortia and tasks through its alignment with NFDIcore, BFO, and the reuse of core ontologies such as IAO and SWO. The modular design ensures compatibility across domains without sacrificing domain-specific expressivity.
CTO demonstrates its generalizability through the direct reuse by the NFDI4Memory consortium [
To meet REQ7, the Ontology Development Kit (ODK) was adopted as the foundation for the CTO
31https://www.getty.edu/research/tools/vocabularies/aat/
32http://vocab.getty.edu/aat/300201028
33https://vocabularies.unesco.org/browser/thesaurus/en/
34https://www.cerl.org/resources/cerl_thesaurus/main
development workflow [
Section 5 further describes the application of CTO together with the SHMARQL tool in the NFDI4Culture infrastructure and provides examples for its applicability in the NFDI4Culture consortium.
SHMARQL is a novel Linked Data publishing platform that enables semantic web professionals to disseminate data efectively. Similar to LODView 37, LODE [27], or YASGUI38 and integrating functionality from these systems into a cohesive whole.
SHMARQL is developed in Python39 and designed as a building-block for web application development. It is built using FastHTML40, a modern Python web application framework enabling rapid development and extension. Originally developed to support the NFDI4Culture project’s data publishing requirements, SHMARQL has since been generalized into a versatile platform and adopted by multiple other research projects. A core feature of SHMARQL is the ability to easily browse the structure of data published in a knowledge graph by navigating properties and utilizing IRIs in either subject (head) or object (tail) positions, as demonstrated in Figure 4. This feature is commonly supported in commercial KG publishing tools.41 However, when exploring a new KG that has not been published in a system exposing this feature for the first time, it typically requires cumbersome manual SPARQL query creation. 35https://obofoundry.org/ 36https://robot.obolibrary.org/ 37https://lodview.it/ 38https://yasgui.org/ 39https://www.python.org/ 40https://www.fastht.ml/ 41For example in the Triply https://triply.cc/ system SHMARQL can be used ”out-of-the-box” by any user with the goal to explore existing KGs published via a SPARQL endpoint, or it can be extended and customized as a web application for publishing new knowledge graphs from RDF data.
A distinctive feature of SHMARQL is its integrated data stories functionality, which combines markdown-based narrative documentation with dynamic charting capabilities to create compelling, interactive presentations of knowledge graph content. Data Stories work by allowing users to create Markdown42 files that seamlessly embed interactive visualizations, charts, and graphs directly within explanatory text, transforming static documentation into engaging and exploratory experiences. This integrated approach enables researchers and data publishers to craft coherent narratives around their datasets while providing immediate access to the underlying RDF data through embedded SPARQL queries and visualizations. As the KG evolves, the associated charts and data representations within these stories can be automatically updated, ensuring consistency between the narrative context and the current state of the data.
An ongoing challenge in SPARQL-based KG querying is the frequent requirement for full-text search capabilities, which are not standardized within the SPARQL specification itself. Although researchers and practitioners routinely need to perform textual searches across literal values, such as finding entities by partial name matches, searching within descriptions, or identifying concepts through keyword queries, the absence of standardized full-text operators forces implementations to rely on vendorspecific extensions or cumbersome workarounds.
To address this challenge of interoperability, SHMARQL has been designed with the explicit goal of enabling efortless KG deployment with integrated full-text search capabilities through minimal configuration requirements. Rather than forcing users to navigate complex triplestore-specific implementations or invest significant efort in setting up custom search infrastructures, SHMARQL abstracts away these technical complexities by providing a unified interface that seamlessly combines SPARQL querying with full-text search functionality.
Given a collection of n-triple or turtle files in a directory on disk, a single command is needed for a user to launch a SHMARQL instance with a fully-functional triplestore: docker run --rm -it -v $(pwd):/data -e DATA_LOAD_PATHS=/data -p 8000:8000 ghcr.io/epoz/shmarql
This approach not only eliminates the traditional barriers to implementing text-based discovery in semantic web applications but also supports the platform’s broader mission of simplifying RDF data publishing with custom styling and enabling compelling data storytelling through integrated access to underlying data for exploration and analysis.
SHMARQL is publicly available43 and ofers deployment flexibility through its containerized Docker architecture. Users can run SHMARQL as a standalone solution to ingest and publish various RDF data formats (including n-triples, n-quads, turtle, and other standard serializations) using its built-in triplestore of high performance powered by Oxigraph44, a Rust-based engine known for its speed and eficiency. Alternatively, SHMARQL can be configured as a sophisticated front-end interface to existing triplestore infrastructures, seamlessly integrating with popular solutions such as Virtuoso45, Qlever46, Apache Jena Fuseki47, GraphDB 48, or any commercial provider that exposes a SPARQL 1.1 compliant endpoint.
When using the built-in Oxigraph triplestore, there is no need to configure or manage an additional server, and importing RDF files is both fast and straightforward. The Oxigraph software is packaged 42https://en.wikipedia.org/wiki/Markdown 43https://shmarql.com/ 44https://github.com/oxigraph/oxigraph 45https://www.virtuoso.com/ 46https://github.com/ad-freiburg/qlever/ 47https://jena.apache.org/documentation/fuseki2/ 48https://graphdb.ontotext.com/ as a library directly integrated into the SHMARQL system. This integration allows users to specify the disk location of their data files, enabling automatic data ingestion during system startup. For moderately sized knowledge graphs containing up to several hundred thousand triples, this ingestion process is suficiently fast to be performed dynamically. For larger knowledge graphs, the system can be configured to persist imported data, eliminating the need for re-ingestion upon application restart.
Alternatively, when using SHMARQL as a front-end to an existing triplestore, users need only specify the target SPARQL endpoint, and all queries are proxied and cached to the existing system. The queries are executed server-side using Python code, which resolves incompatibility issues caused by CrossOrigin Resource Sharing (CORS)49 security restrictions that occur when SPARQL queries are executed from front-end JavaScript libraries against endpoints lacking proper CORS header configuration.
To extend standard SPARQL syntax with full-text and similarity search capabilities, SHMARQL leverages the FIZzysearch50 SPARQL rewriter and the bikiDATA51 RDF indexing and querying library. The FIZzysearch module employs a SPARQL syntax-aware parser52 to parse queries into concrete syntax trees and provides contextual replacements of configurable query components. This approach enables the addition of features such as full-text searching through ”magic triples” to existing triplestores, even those not originally published with SHMARQL. For example: select ?s where {
?s fizzy:fts "something" . } The system executes a full-text query to retrieve all triples containing literal strings that match the term ”something”. It also supports wildcard patterns and boolean query operations for enhanced search capabilities. Beyond full-text search functionality, the system can be extended with additional enhancements such as RDF2Vec-based knowledge graph embeddings53 or sentence embeddings54 to enable similarity-based searching.
For data story creation, SHMARQL utilizes the widely adopted MkDocs55 documentation system. A custom plugin was developed for MkDocs to enable ’shmarql’ syntax code blocks within markdown documents, which display SPARQL query results directly in the narrative rather than exposing the raw query source. This approach facilitates compelling data storytelling while preserving analytical transparency by allowing readers to access the underlying queries for further analysis or data verification (cf. Section 5).
The platform has already seen a broad uptake across diverse research initiatives, with active deployments in projects including NFDI4Memory56, RADAR57, and NFDI-Matwerk58, while generating substantial interest on integrating the system from additional projects such as Graceful 1759. This dual-mode capability makes SHMARQL particularly valuable for organizations that want to enhance their existing semantic web infrastructure with improved user interfaces and data storytelling capabilities, while also serving as a complete out-of-the-box solution for new projects. The platform’s architecture ensures that, regardless of the underlying triplestore configuration, users benefit from consistent full-text search integration, custom styling options, and the integrated data stories functionality, making it suitable for both rapid prototyping and production deployment scenarios. 49https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS 50https://github.com/ISE-FIZKarlsruhe/fizzysearch 51https://github.com/ISE-FIZKarlsruhe/bikidata 52https://tree-sitter.github.io/ 53http://rdf2vec.org/ 54https://sbert.net/ 55https://www.mkdocs.org/ and specifically the https://squidfunk.github.io/mkdocs-material/ theme 56https://4memory.de/ 57https://www.radar-service.eu/radar/en/home 58https://nfdi-matwerk.de/ 59https://graceful17.hypotheses.org/
The platform achieves the goals expressed in RQ3 by reducing the steps required to publish RDFmodeled data and lowering the cognitive load needed to configure features that support discovery and analysis tools. With a single Docker container command, a complete Linked Data environment becomes operational, providing integrated documentation, queries, analyses, and visualizations. Feedback from end-users who have deployed the SHMARQL platform has been consistently positive, with users expressing satisfaction regarding the platform’s ease of use and flexibility for data exploration.
The SHMARQL development team welcomes community contributions and is actively working to add new features that will extend and enhance the system during the next phase of NFDI4Culture consortium activities.
The application and the benefit of the presented contributions within the infrastructure of NFDI4Culture can be illustrated on the example of the digital letter edition Ferdinand Gregorovius: Poesie und Wissenschaft. Gesammelte deutsche und italienische Briefe 60 and their interconnections to musicological data from RISM Online61. The Gregorovius edition contains 1,093 annotated pieces of correspondence from the historian Ferdinand Gregorovius, whose heritage testifies a rich engagement with intellectualhistorical movements and musicians of his time. Although the data from the Gregorovius edition and RISM Online are related through shared content and authority data, no common access point existed prior to their integration into the NFDI4Culture-KG. This fragmentation prevented researchers from performing unified queries, conducting cross-dataset searches, or discovering meaningful interconnections essential for comprehensive research and data reuse. Figure 5 showcases connections on the level of persons between both data sets, which were revealed through a SPARQL query62 [28].
Furthermore, SHMARQL and CTO are employed in the data stories platform provided by NFDI4Cul60https://gregorovius-edition.dhi-roma.it/ 61https://rism.info/ 62https://nfdi4culture.de/go/kg-gregorovius-rism-example-musical-sources-letters ture63, illustrated in Figure 7 in Appendix A. This application combines semantic technologies with storytelling to promote data literacy and showcase the potential of LOD in the CH domain. Guided by narrative structures and the integration of visualizations, and interactive elements such as SPARQL queries, the data stories enable innovative exploration modes for semantically connected CH datasets within the NFDI4Culture-KG. A practical example is the data story An Italian Data Journey [29], developed within NFDI4Culture. It explores the 18th-century opera holdings of the Doria Pamphilj Archive in Rome using data from the Partitura project at the German Historical Institute in Rome and illustrates how historical musicological data can be enriched with external resources such as Wikidata64, GeoNames65, ICONCLASS66 and RISM. By integrating the dataset into the NFDI4Culture-KG and leveraging computational resources from the European Open Science Cloud (EOSC)67, the data story demonstrates how federated infrastructures can improve the interoperability and reusability of CH research data [30].
This paper contributed the NFDI4Culture Ontology (CTO) and the SHMARQL Linked Data platform as integral components for the semantic representation and discovery of CH research data. By aligning with BFO and extending the mid-level NFDIcore ontology, CTO provides a lightweight yet expressive framework for integrating decentralized CH metadata into a centralized, queryable infrastructure. SHMARQL complements this by enabling intuitive exploration and publication of Linked Data, enhanced with full-text search and narrative-based interfaces through its Data Stories feature. The contributions demonstrate how CTO and SHMARQL jointly address the challenges of cross-domain interoperability, semantic richness, and accessible knowledge graph interaction. Their adoption within and beyond NFDI4Culture, ranging from musicology and digital editions to interdisciplinary data stories, shows their potential for reuse across diverse research domains.
Acknowledgements: This work is funded by Deutsche Forschungsgemeinschaft (DFG), project number 441958017.
Declaration on Generative AI: The authors used GPT-4 and Claude Sonnet 4 for grammar and spelling check. The authors reviewed and edited the content as needed and take full responsibility for the publication’s content. 63https://datastories.nfdi4culture.de/ 64https://www.wikidata.org/ 65https://www.geonames.org/ 66https://iconclass.org/ 67https://open-science-cloud.ec.europa.eu/ [27] S. Peroni, D. Shotton, F. Vitali, The live owl documentation environment: a tool for the automatic generation of ontology documentation, in: International Conference on Knowledge Engineering and Knowledge Management, Springer, 2012, pp. 398–412. [28] L. C. Söhn, T. Tietz, J. J. Steller, P. Kehrein, A. Büttner, O. Bruns, E. Posthumus, J.-P. Grünewälder, J. Hörnschemeyer, C. Sander, V. Grund, H. Fliegl, H. Sack, T. Schrade, Nfdi4culture integration stories: Bridging gaps between isolated research resources, in: Digital Humanities 2025: Accessibility & Citizenship (DH2025), Zenodo, Lisbon, Portugal, 2025. URL: https://doi.org/10.5281/ zenodo.16570076. doi:10.5281/zenodo.16570076. [29] T. Schrade, An Italian Data Journey: Analysing Research Data about 18th-century Italian Opera Using the Culture Knowledge Graph and Federated European Research Infrastructures, NFDI4Culture Data Story (Story ID E6263), 2025. URL: https://datastories.nfdi4culture.de/story/E6263, persistent Identifier: https://nfdi4culture.de/id/E6263. [30] L. C. Söhn, T. Tietz, T. Schrade, J. J. Steller, A. Büttner, O. Bruns, E. Posthumus, H. Fliegl, H. Sack, Telling Data Stories: Linking Infrastructure, Semantics and Cultural Heritage Data in NFDI4Culture, 2025. Manuscript under review at DHd2026.
Figure 7: A data story on the NFDI4Culture platform ”An Italian Data Journey” by Torsten Schade