#wikibase — Public Fediverse posts

🎮 Wikimedia Deutschland erstmals beim #gamescomcongress!

Games sind Kulturgut, prägen Communitys und erzählen viel über unsere Gesellschaft. Alan Ang spricht heute darüber, wie wir Games als digitales Kulturerbe bewahren können – und welche Rolle #Wikidata und #Wikibase dabei spielen. 👾

📍 Heute, 16:30–17:00 Uhr, Stage E

Wir freuen uns auf den Austausch! 🚀

#gamescom2026

🎮 Was bleibt von einem Video Game, wenn die Server abgeschaltet sind?

Video Games sind Kulturgut – aber erstaunlich vergänglich. Beim gamescom congress am 27. August sind wir erstmals dabei: Unser Senior Partner Manager Alan Ang spricht darüber, warum es wichtig ist, Video Games zu bewahren, welche Rolle #wikibase dabei spielen kann – und wie Game Design unsere Gesellschaft verändert.

Wir freuen uns auf den Austausch! 🚀

#gamescom2026

Public service announcement for people who do stuff around @wikipedia and @wikidata.

Lately, because of #Wikimania and other things, I got to speak in English about things related to Wikidata to several people whose first language is not English. They kept saying a word I couldn't understand. Then I realized that they're talking about #Wikibase, but instead of pronouncing the last syllable as "bays", they were pronouncing it as "bahz", "bahs", "BAH-ze", etc.

I hope it helps people communicate!

Missed the "Bridging Institutions, Wikidata & Generative AI" talk at Wikimania Paris?

Key Takeaways:
🏛️ GLAMs often back open access (but want AI safeguards) — attribution, context, reciprocity
🔗 An uploads alone doesn't add value. Data needs curation & Wikipedia/Commons sitelinks
🗃️ Institutions can hold data in Wikibase; Wikidata can connect it
🤖 Challenge: open knowledge + sustainable infrastructure

Watch: https://www.youtube.com/watch?v=RWNgzZChMiA

#Wikidata #Wikimania #OpenData #LinkedData #Wikibase

Vereinfachte Eingabe von komplexen Daten in Wikibase

Datenmodelle können komplex sein und viele Klassen sowie Properties (oder Eigenschaften) enthalten, die miteinander verbunden sind – da verliert man schnell den Überblick. Gerade wenn man länger keine Daten mehr in einem Daten-Management-System wie Wikibase angelegt hat, kann es leicht passieren, dass man erst wieder die Datenmodell-Dokumentation lesen muss, bevor man loslegen kann.

Wikibase ist die freie Open-Source-Software, auf der Wikidata, die öffentliche Wissensdatenbank der Wikimedia-Bewegung, basiert. Wikibase ist ein bekanntes und weit verbreitetes Werkzeug in GLAM- und Forschungsdaten-Communities. Es ist beliebt wegen der Vielzahl an Funktionen, die es standardmäßig bietet, der großen Open-Source-Community, die Erweiterungen dafür entwickelt, und der Flexibilität, es an individuelle Datenanforderungen anzupassen. Diese Flexibilität kann jedoch auch zu Problemen bei der Benutzerfreundlichkeit führen.

Denn wenn man eine neue Entität für eine bestimmte Klasse anlegen möchte, weiß man auf den standardmäßig eingerichteten Wikibase-Seiten nicht:

• Welche Informationen, die für diese Art von Entität zu erwarten wären, fehlen?
• Welche Eigenschaft sollte für die jeweilige Information verwendet werden (zum Beispiel „Land“ vs. „Herkunftsland“)?

Genau für diesen Fall war es das Ziel, innerhalb einer Wikibase4Research-Instanz ein Formular für ein Datenmodell rund um Theaterproduktionen und Aufführungen zu entwickeln. Wikibase4Research ist ein individuell konfigurierbarer Docker-Container, der die Standard-Wikibase-Distribution erweitert. Er wurde vom Open Science Lab der TIB im Rahmen des NFDI4Culture-Konsortiums entwickelt und wird für Projekte wie die von der Universität Leipzig initiierte Performing Arts Database (PAD) genutzt.

Bei der Recherche nach geeigneten Lösungen für den PAD-Anwendungsfall sind wir auf forage gestoßen. Das User Script fügt jedem Wikibase-Item einen neuen Reiter hinzu, über den sich ein Formular öffnet, das alle für das aktuelle Item relevanten Properties anzeigt. Die Dateneingabe wird dabei durch vereinfachte Eingabefelder erleichtert.

Das Skript hat bei den ersten Tests sehr gut funktioniert, allerdings fehlten uns noch einige Features. Wir haben uns daher entschieden, das öffentliche Repository zu forken und eine Erweiterung zu schreiben. Das daraus entstandene Skript „forage extended“ ist weiterhin Open Source und im Gitlab von Wikibase4Research für alle verfügbar.

Folgende Features wurden neu integriert:

• Schema-basiertes Formularlayout:
  Eigenschaften werden über ein Konfigurationsobjekt nach Entitätstyp gruppiert und sortiert.
• Neues Item anlegen für bestimmte Klasse:
  Beim Öffnen der „Formulare“ in Forage für ein leeres Element wird ein Bildschirm zur Klassenauswahl angezeigt; durch Anklicken einer Klasse werden die erforderlichen Eigenschaften automatisch gesetzt und das Formular neu geladen – dies kann im Konfigurationsobjekt festgelegt werden.
• Unterstützung von Qualifikatoren:
  Konfigurierbare Qualifikator-Eingabefelder erscheinen direkt unter der übergeordneten Eigenschaft. (So kann beispielsweise ein Rollenname für die Eigenschaft Schauspieler:in direkt hinzugefügt werden.)
• Validierung von Pflichtfeldern:
  Als Pflichtfelder markierte Felder werden mit einem roten Sternchen gekennzeichnet und in einem Warnbanner aufgelistet, bis ein Wert gespeichert wurde.

Das daraus entstandene Skript vereinfacht die manuelle Erfassung neuer Entitäten erheblich: Man muss nicht mehr selbst nach den richtigen Eigenschaften suchen, sondern hat sie immer direkt vor Augen.

Wir planen, „Forage Extended“ über einen Merge-Request an das Repository, in dem die Originalversion gehostet wird, wieder in das breitere Open-Source-Ökosystem einzubringen und damit anderen Mitgliedern der Wikibase-Community dabei zu helfen, ihre komplexen Daten einfacher einzugeben.

Video zum Online-Meeting: FactGrid-Plattform für die Familienforschung nutzen

https://www.compgen.de/2026/07/video-zum-online-meeting-factgrid-plattform-fuer-die-familienforschung-nutzen/

CompGen Online-Meeting am 16.07.2026: FactGrid-Plattform für die Familienforschung nutzen

https://www.compgen.de/2026/07/compgen-online-meeting-am-16-07-2026-factgrid-plattform-fuer-die-familienforschung-nutzen/

After exploring Wikifunctions and Abstract Wikipedia to document Pride during Pride Month, I’m now testing another parallel approach: what would a scaled-down, Wikifunctions- and Wikibase-powered Abstract Blog look like?

Glad to share some initial screenshots.

Current goal: generate blog-style content in 8 human languages, inspired by the vision of Abstract Wikipedia.

https://johnsamuel.info/Q315/Q3062/index.html

#lgbt #lgbtqia #wikipedia #abstractwikipedia #wikibase

What do we mean when we talk about AI and open knowledge?

Reflections on the future of sovereign, decentralised data management – Wikibase, Wikidata and beyond at the AI-Bridges Symposium

The AI-Bridges Symposium (28–29 May 2026) [1], hosted at Senate House, University of London, brought together diverse stakeholders from policy makers to academics, open knowledge advocates and funders, to discuss how AI is affecting the landscape of open knowledge. The underlying framework of the event was the recognition of the need for collective action when engaging with AI-related issues – a shorthand for an entangled bundle of tools and services, actually. Over the course of the symposium, two main themes emerged: 1) The threat posed by commercial AI applications scraping the commons (open knowledge spaces) in an extractive manner; overloading the capacity of the socio-technical infrastructure without regard for the labour, codes of conduct and maintainer culture of commons communities, leaving behind frustration and distrust. 2) The flip side of this – the possibilities of using AI-supported workflows in actually lightening the load on maintainer communities; ensuring open knowledge continues to be shared freely and widely on the web through more accessible tooling for data integration, formatting and validation, with version controlled change histories.

Both themes open much room for discussion and potentially different routes for action. Mapping the landscape of relevant activities already happening in the common spaces was also part of the agenda. The various Wikimedia communities, both formal Foundation staff and affiliates as well as volunteers, are actively putting mechanisms in place to address threats and potential negative impacts (rate limits, targeted blocking, bans on AI-generated contributions, and more) and debating with mixed feelings the ifs and hows of AI-supported workflows [2]. At the same time there are also efforts across the research and public funding sector to deal with similar issues. Why not bring these efforts together?

This was one of the core propositions of the symposium: Why not consider how shared cultural heritage initiatives, such as Europeana or the European Culture Heritage Cloud among others, might help address the challenges also faced by the communities behind projects like Wikipedia, Wikidata, and Wiki Commons, and vice versa? And furthermore – the event asked us to think about the role of public funding bodies and government policies: Where can the positive energy and concern for democratic processes, knowledge sharing, and civic care converge rather than continue in isolated, siloed efforts with lower impact? [3] Participating as representative of both the EU-funded ECHOLOT project and the DFG-funded NFDI4Culture, I was at the right place for “staying with the trouble” [4] at the intersection of national and international research infrastructures and the digital commons.  

Day 1: Training day

The first day was a hands-on training day within a smaller group of participants (~50) which offered the opportunity to level the ground with a common understanding of the data spaces of the Wikimedia ecosystem, namely Wikidata and Wikibase (and by extension their role in the AI development landscape). Solenne Lazare and Lydia Pintscher from Wikimedia Germany started off with an introduction to Wikidata, the large public knowledge base powering data in Wikipedia, while Leif Lobinsky ran the introduction session to Wikibase, the open source software suite behind Wikidata: What are the possibilities for sharing structured data within these systems, what example projects from diverse fields of knowledge already use them and what are current limitations and performance pain points?

As part of the hands-on testing, participants were invited to try modeling complex topics as data (e.g. news involving assumptions, uncertainties, etc.) within test instances of wikibase.cloud. The modeling experiment proved to be quite a challenge: while in Wikidata there are the existing items that can be used as guiding posts, in the case of Wikibase instances, starting from scratch offers flexibility at the cost of a high learning-curve. The way new users approach Wikibase as a data management tool might be to begin with federated properties and classes from Wikidata (if they’re already involved in that community), or to attempt to (re)build an ontology they might know from their domain (e.g. CIDOC-CRM in the culture heritage domain). The possibility of not having to start from scratch with basic properties and classes was discussed as a potential usability gain [5]. Clear patterns were emerging where additional support to users throughout different parts of the data management process would be beneficial.

In the afternoon, Philippe Saadé from Wikimedia Germany introduced the Wikidata Vector Database, what use cases it aims to support (e.g. Retrieval Augmented Generation, named entity recognition/ disambiguation, and classification) and where there is potential for more community engagement. Expanding the multilingual reach is one such goal, since currently vectors are calculated per language (so far: English, German, French and Arabic), but the search query entered in the LLM interface can be multilingual. A complementary development is the Wikidata MCP with a set of available tools. Using LLMs like Mistral (where connection to the internet can be closed down, so that the only source of truth becomes Wikidata) was demoed with promising results but is not entirely error-free yet, especially for SPARL query formulation. A brand new Wikibase MCP extends the connectivity to independent instances. 

These recent developments engage seriously with the idea of AI-supported workflows that can increase the efficiency, accuracy and usability of the interactions between open knowledge communities and the data spaces offered by Wikidata or independent Wikibase instances. Gaps are admitted (e.g. in the case of language limits) and more community testing and contribution is actively encouraged – entirely in keeping with the spirit of free and open source software development. For example, fully fledged data reconciliation workflows that take advantage of the vector database are already being developed outside Wikimedia Germany, but in close discussion among the relevant communities [6]. This framing of ‘AI’ as software, as tools and services, which can actually be developed following FOSS principles, opened up the space to expand the discussion over the next days beyond the monolithic image of an external force, outside the control of the affected communities. 

Community debates

In the last part of the day, a community gathering, led by Wikimedia Switzerland and Open Future, debated a new multi-partnership initiative for the Wikimedia movement that would be dedicated to addressing the AI-paradigm shift in a concerted and transparently-governed manner. The opening of the gathering was framed in a rather cautionary way: the urgent need to prevent extractive behaviours (both by bots and Big Tech commercial players), and implement stricter regulations and/or legal frameworks. At the same time, it is important to recognise how much of the existing tooling ecosystem is built around notions of usability dating from several decades ago and is still not open enough, or inviting enough, to diverse communities – humanities disciplines still struggle with the accurate modelling and translation of their qualitative work into data, while indigenous communities have established much more nuanced rights management pathways that fall outside the strict open/closed paradigm, to name just a few examples [7].

New paradigms in human-computer interaction, including natural language interfaces, as well as new legal frameworks that would effectively regulate access rights including bot/agent access, could actually be used to support and complement the interaction with the open knowledge ecosystem in ways that make the entire ecosystem more equitable – addressing problems that have been simmering below the surface far longer than the recent AI-hype cycles. The devil, as always, is in the details.

At this point in the day, I brought up the work of Audrey Tang from the Civic AI research project [8], which in a timely manner argues for the need to think about the original idea(l)s of FOSS – the open source freedoms – as applied to AI. If we frame AI as software, rather than as the threat of replacing human knowledge – a threat admittedly close to the heart of open knowledge communities – software can be governed through the principles of the FOSS freedoms. Moreover, these principles can encompass the right of refusal and rejection of extractive interactions, while adopting and adapting further beneficial workflow optimisations.

The notion of AI in the loop of communities, as elaborated by Tang, rather than the notion of the human in the loop of the AI, resonated strongly in the context of the Wikimedia movement and the link to Tang’s work was quickly circulated around the table. The gathering started with the proposition of taking an active stance as a global community of open knowledge advocates and concluded with the need to also put forward a positive vision and viable alternative, instead of merely (re)acting against Big Tech.

Reactionism can catalyse valuable critical points that need to be taken into account, but it cannot unite the movement when there is already a significant strain on the goodwill of volunteers dealing with overwhelming amounts of poor-quality, AI-generated data or harmful pull requests. A positive vision is necessary to recognise where the current ecosystem was found lacking even before the arrival of mainstream AI applications, and where it could be improved when it comes to dealing with sensitive topics, cultural nuances, and access rights. More relevant now than ever – where automated (mis)use can be scaled to unprecedented levels – advocates who have dealt with these topics in the past can bring in valuable insights to shaping the movement’s future. 

Day 2: The symposium

Day two featured extended discussions within an even wider group of participants, starting off with presentations from the AI-Bridges partners, leading to an expert panel and then a set of roundtable sessions. The panel discussion engaged a number of leaders from academic funding, policy making and Wikimedia communities, including Jimmy Wales, Denny Vrandečić and many more. The panel host, Shani Evenstein Sigalov, asked each panelist a particularly tough question which then required a succinct, but precise answer. The question addressed to me asked what is still missing in Wikibase and Wikidata infrastructures when it comes to meeting the needs of researchers and knowledge institutions. My answer, summarising the current status quo, what works and what doesn’t, is shared in full below (see Postscript).

In this context, ECHOLOT emerged as one of the much needed bridges across initiatives such as Europeana, the European Culture Heritage Cloud and the Wikimedia communities. As pointed out also by our panel host, all of these initiatives and communities deal with similar issues connected to aggregating open data on cultural heritage, protecting data from abuse (whether machine- or human-operated) and at the same time actively encouraging fair (re)use of that data. But the (re)use that could lead to scientific, societal and even economic value generation (for stakeholder communities), rather than value extraction, is hampered by the fact that the majority of the platforms are still not particularly easy to integrate with, to extract data from or to reuse that data, while respecting relevant copyrights. In short, there is a lot of open room for alignment and collaboration.

The panel also discussed the implications of missing the mark on using the productive capacity of the tools and services that AI methods can afford due to slow change cultures in some institutions. Nevertheless, the concerns coming from the GLAM community, the academic community, and also the volunteer citizen science knowledge commons, require paying attention to, as they are rarely born purely out of resistance to (fast) change. We can recognise, in the words of Denny Vrandečić, that LLMs trained on Wikipedia and Wikidata knowledge are objectively better for democratic societies compared to LLMs trained on data only from e.g. Twitter/X. Nevertheless, the care with which that knowledge has been put together originally has to be respected and has to be factored in the development of any new, value-generating tools. 

One of the topics of the panel was also regulation: as a way to protect knowledge creation communities and regulate what value is generated and for whom. Paraphrasing the remarks of Aaron Halfaker (Principal at Microsoft): Big Tech could actually benefit from regulations. When the workers in these companies care about how these tools are being used, which is purportedly the case, regulation can help stimulate more fair business and market competition. If all companies have to compete on fair ground, theoretically they are more likely to develop tools wherein the benefits outweigh the harms.

I found this line of thinking productive, because it moved away from the ‘human-vs-machine’ discourse and brought back the companies into the picture; companies are legal entities that can in fact be subject to laws and regulation (though of course, how successfully regulation is implemented is another matter altogether). The ‘performer’ (e.g. contributors, users and developers of open knowledge platforms) vs the ‘tool maker’ (e.g. the company employees developing AI applications) paradigm, introduced in the book Behind Deep Blue [9] as an alternative to ‘human-vs-machine’, recognises people with one set of tools engaging with people with another set of tools [10]. If the human involvement is not abstracted away on one side of the equation, both sides can be subject to dedicated regulatory procedures. Crucially, regulation should not be restricted to licensing and/or IP attribution. As, Audrey Tang reminds us, FOSS is more than just licensing [11]. And caring about the rights of the ‘performers’ may not be enough, if the FOSS principles (and freedoms) are not fully applied to AI and its ‘tool makers’, including the right to refuse.

Jimmy Wales’s closing panel remarks also touched on the topic of trust, something Wikimedians and FOSS communities have managed remarkably well over time, and something that the AI-‘tool makers’ are currently less invested in building up, leading to the ongoing mixed-feelings or outright hostility amongst ‘performer’ communities.

Collaboration in practice, and not just in theory

The panel ended on the positive note that everyone in the room seems interested and willing to collaborate, and of course everyone’s question was: how to make this happen instead of simply navel-gazing and wishful thinking? The roundtables in the afternoon provided an opportunity to think through some concrete actions. The setup meant that participants could take part in small group discussions across 18 different topics [12] via dedicated roundtables and take part in noting down:

• what current issues can be observed;
• what patterns emerge across connected issues;
• what are the next steps.

At the round table on the future of Wikibase, we noticed known issues related to data ingest, modelling, reconciliation and export workflows, still repeatedly being brought up and needing adequate measures to meet user needs, especially when scaling from manual curation to bulk operations. This is in fact the core motivation of applying AI methods to the tooling for managing structured data: the need to be able to more easily ingest the data, structure it, enrich, and then export to further platforms, supporting reuse.

Discussing the outcomes of the roundtable with colleagues from Wikimedia Germany, we came to the conclusion that we can’t build everything the community needs alone, but together there is a much stronger possibility. There are certain parts of the stack that make a lot of sense to be developed within the core product development at Wikimedia Germany, while other parts, such as micro-services that provide AI-supported automation, can be developed from external projects such as ECHOLOT and NFDI4Culture, among others.

We concluded the event with concrete commitments for joint meetings to plan the future development roadmap: interconnecting MediaWiki, Wikibase, new extension developments and the broader ecosystem of structured data, that can both be supported by AI-tooling and itself support the training of better and more equitable AI models. 

Postscript: Short position statement at the panel discussion

I will talk about Wikibase specifically, because Wikidata in general for all its scaling issues performs remarkably well on most levels that researchers and institutions need it to. As a tool offering openly licensed data and the possibility to freely link entities through their external identifiers, it offers the perfect hub for linked open data integration [13]. Wikibase, as its underlying open source software, appears to be the perfect starting point for researchers or cultural practitioners who want to model and make their original research data available, before it becomes a reference point for Wikidata – where we are not supposed to really directly add original research data. This very premise is compelling: I can have all my highly specialised or copyrighted data in a Wikibase and then seamlessly link it, or parts of it, via Wikidata by virtue of the fact that the two deploy the same software paradigm. In fact, it is the backbone of the idea of a federated ecosystem of instances around Wikidata shown in one particularly widely shared diagram [14]. 

And yet – there are issues. Wikibase is a complex Swiss-army-knife tool, it does a lot but it requires a high degree of technical skill and know-how to run and maintain in the long run – such skills are often not easy to come by in domain-specific research. It does not support easy compatibility with standard domain-specific schemas or ontologies. There is no simple upload schema button. There is no standard data validation in the sense required by typical FAIR research data projects. There are also no easy, straightforward export options to connect data from Wikibase even to Wikidata, or any other research data infrastructure. The latter is often a requirement for research – publish data to various national or international data aggregators. This is fine; Wikibase was never meant to solve for such cases. And yet, one can imagine the possibilities. Many of the limitations can be overcome with custom scripts, extensions and additional tooling, but maintaining, documenting and sharing this oftentimes lacks real reuse and reproducibility. This is more a fault of the scientific community, though, not the open knowledge community and is tied to the unsustainable funding cycles of research projects.

Efforts from the open knowledge community, such as wikibase.cloud – an important, major undertaking trying to resolve some of the learning-curve and maintenance limitations of the software suite – do not yet go far enough: images, for example. For many years now, I have advocated that the open knowledge community can learn a lot from research and GLAM communities when it comes to respectful and sensitive handling of copyrights, whether we are dealing with contemporary culture or indigenous rights [15]. Equally academia can learn a lot from the Wiki movement when it comes to long-term maintenance and keeping up infrastructure running. With the ECHOLOT project I’m now leading, we’re trying to offer a new bridge with concrete software development outcomes between EU research infrastructure and Wikimedia platforms and software. We are building better schema and copyrights handing models, easier export and integration possibilities with built-in, AI-supported processing workflows, wrapped around existing software. Not reinventing the wheel, but making it fit for different road conditions. We are open to collaboration and working together with anyone around the table today. 

Acknowledgements

Thanks to Shani Evenstein Sigalov for the invitation and the opportunity to contribute to the Symposium and to the Wikimedia Germany team, and especially Leif Lobinsky for the productive discussions. Travel to the Symposium was supported by the ECHOLOT project, funded by the European Union under Grant Agreement n.101233096.

Notes

1. AI-Bridges is funded by the European Commission through a Marie Skłodowska-Curie Postdoctoral Research Fellowship. Led by Dr Shani Evenstein Sigalov and hosted at Digital Humanities Research Hub, School of Advanced Study, University of London, the project includes partnerships with the Wikimedia chapters in Germany, UK, Brazil, and Switzerland, and AI-experts Pleias.

2. Recent examples include dedicated sessions at the Wikimedia Hackathon 2026 in Milan, summarised with great nuance in a blog article by Hay Kranen, as well as upcoming sessions at Wikimania 2026 to be held in Paris in July. 

3. The European Tech Sovereignty Package and EU Open Source Strategy were published on June 3rd, 2026, positioning open source and the digital commons as critical to Europe’s “resilience, competitiveness and strategic autonomy”. The strategy also admits that despite over 3 million open source contributors (according to the strategy fact sheet, but other sources point to even higher numbers), the European open source ecosystem faces “structural challenges” and lower impact due to value extraction outside Europe. The analysis from the Open Knowledge Foundation Network outlines further details. 

4. See Donna J. Haraway (2016) Staying with the Trouble: Making Kin in the Chthulucene. Duke University Press. 

5. Here, NFDI4Culture’s development of Wikibase4Research, which was mentioned as an example project application can be quite helpful, as it provides (among other resources), a GitLab repository with a sample ontology for the culture domain with scripts for transforming and loading the ontology in a fresh Wikibase instance.

6. At least one such example is the reconciliation of Basque entities currently underway at HiTZ-EHU as part of ECHOLOT, but there are likely many more.

7. See the published work of Anne Chen, Stacy Allison-Cassin and Kim Christen, among others.

8. ‘Software Freedom as Civic Care’ (published timely on May 22, 2026), part of the Civic AI project at the Oxford Institute for Ethics in AI.

9. The 2002 book by Feng-hsiung Hsu, the system architect of Deep Blue, which tells the story of how Deep Blue, “the ultimate chess machine,” beat Gary Kasparov in 1997. 

10. This useful parallel to the discussions in Behind Deep Blue was initially drawn by Hay Kranen in his blog post on the Wikimania Hackathon. 

11. See note #8.

12. Topics covered four broader areas such as AI Policy, Tools & Infrastructure, Trust & Education, Cultural Heritage & GLAMs. Full list is available here.

13. See Sohmen, L., Rossenova, L. and Blümel, I. (2026) ‘Wikidata 4 Open Culture: Lessons Learned from Hands-On Work with Cultural Heritage Data in the Expanded Wikibase Ecosystem’, Journal of Open Humanities Data, 12(1), p. 52. Available at: https://doi.org/10.5334/johd.440.

14. The image referred to is this one.

15. For example, see this blog post on provenance and museum data in the Wikiverse.

It’s been over two years since I last submitted a #Wikimedia #Phabricator ticket, so I guess I should submit a new one for a weird bug on #WikimediaCommons involving structured data via #Wikibase. 😝

https://phabricator.wikimedia.org/T429008

Our customer @Kunstenpunt shares their #Wikibase success story on the @wikimediaDE blog: https://tech-news.wikimedia.de/2026/06/02/kunstenpunt-a-whos-who-of-the-flemish-art-scene/

In the blog, @ruettet lists game changing Wikibase extensions, shares the story of choosing Wikibase, and shows off some nifty tools.

At the AI Bridges symposium in London today, Leif Lobinsky from @wikimediaDE covers #Wikibase current use cases, applications and examples from the ecosystem, featuring also #Wikibase4Research from @nfdi4culture @tibo.

More sessions and discussions throughout the two days bringing together Wiki communities, policy makers, users and developers with the special focus on considering implications of current AI developments for the whole movement and ethos of #wikimedia projects.

Kennen Sie schon … das Wiki zu den Meistersiegeln der Nürnberger Steinmetzbruderschaft?
» https://meistersiegel.tibwiki.io/wiki/Main_Page
Hintergrund-Informationen zu dieser Sammlung gibts im Blog der @tibhannover :
https://blog.tib.eu/2026/05/11/eingepraegte-geschichte-das-meistersiegel-wiki-ist-online/
#Nürnberg #Architektur #Baugeschichte #GESAH+ #Siegel #Wikibase

Eingeprägte Geschichte – das Meistersiegel-Wiki ist online

Wer im Mittelalter und der Frühen Neuzeit etwas auf sich hielt, der führte ein eigenes Wappen oder eine individuelle Marke, mit der er auf Dokumenten oder Urkunden siegelte. Auch bei den Meistern der Nürnberger Steinmetzbruderschaft war es Brauch, Gutachten oder Pläne mit ihren eigenen Meisterzeichen zu kennzeichnen. Meist geschah das in Form von Blind- oder Prägesiegeln, die mit einem Ring oder Stempel in das Papier eingedrückt wurden. In einer an der TIB im Open Science Lab in Zusammenarbeit mit dem Fachgebiet Bau- und Stadtbaugeschichte der Leibniz Universität Hannover entwickelten Wikibase-Instanz, dem Meistersiegel-Wiki, werden nun erstmals solche Siegel erfasst und systematisch beschrieben.

Die Nürnberger Proberisse – besondere Zeugnisse der Steinmetzausbildung

Als Corpus für die Erfassung dient ein bisher kaum von der Forschung wahrgenommenes Konvolut von 34 Blättern mit sogenannten „Proberissen“, das sich in der Ende des 19. Jahrhunderts zusammengetragenen Sammlung des Hannoveraner Bauhistorikers und Architekten Albrecht Haupt (1852-1932) erhalten hat.

Diese Risse entstanden im Rahmen des Meisterstücks, das der Geselle zur Erlangung des Meisterstatus anzufertigen hatte und zeigen musterhafte Entwürfe und Konstruktionen von Gewölbeanlagen und Gebäuden. Schon früh wurden diese Blätter in das Umfeld der Nürnberger Steinmetzbruderschaft eingeordnet, ohne jedoch im Hinblick auf ihre Provenienz und Zusammensetzung genauer betrachtet worden zu sein.

Als Architektur- und Werkzeichnungen, die im Kontext der Steinmetzlehre angefertigt wurden, sind sie besondere Zeugnisse der handwerklichen Ausbildung im Bauwesen in der Übergangszeit ab dem Spätmittelalter bis zur Auflösung des Zunftwesens Ende des 18. Jahrhunderts.

Die zahlreichen, auf den Blättern oft kaum sichtbaren Blindsiegel der prüfenden Meister machen sie zu einem besonderen Studienobjekt, zumal es sich um ein individuelles – bislang nur für die Nürnberger Steinmetzbruderschaft nachweisbares − Phänomen handelt.

Im Rahmen des von der Deutschen Forschungsgemeinschaft (DFG) geförderten Projekts zur Erschließung der umfangreichen, heute in der TIB aufbewahrten Sammlung Haupts (GESAH) ist das Konvolut der Proberisse Bestandteil einer Tiefenerschließung und diente mit seinen Meistersiegel- bzw. Meisterstempelabdrücken als Fallstudie zur Verknüpfung mit der Forschungsdateninfrastruktur von NFDI4Culture.

Das Meistersiegel-Wiki

Die neue Wikibase-Datenbank zu den Meistersiegeln erfasst sämtliche Siegelmotive, die sich als Blindsiegel-Prägungen auf den Blättern erhalten haben. Mit ihrer Erfassung lassen sich Beziehungen der Siegler untereinander und zeitliche Entstehungszusammenhänge innerhalb der Blätter, aber auch zu darüber hinaus vorhandenen Quellenmaterialien nachvollziehen.

Vorbereitend für die Erfassung der Nürnberger Meistersiegel in einer eigenen Wikibase-Instanz wurden alle erkennbaren Siegelabdrücke umgezeichnet, in ihren jeweiligen Charakteristika, Kombinationen und Gruppierungen tabellarisch aufgenommen und beschrieben. Für die Beschreibungen der auf den Siegeln enthaltenen Steinmetz- und Hausmarken wurden eigene, auf der Fachterminologie der Blasonierung basierende Kategorien entwickelt und ein umfangreiches fachspezifisches Glossar angelegt. Insgesamt ließen sich auf diese Weise 18 unterschiedliche Siegel auf den Blättern identifizieren und beschreiben, drei weitere konnten nur im rudimentären Zustand erfasst werden. Weitere neun Siegelmotive wurden aus der historischen Literatur in die Aufstellung übernommen.

Im Abgleich mit den im Zuge der Archiv- und Literaturquellen ermittelten über 150 belegbaren Meister konnte ein Großteil der Siegler identifiziert werden. Über die überlieferte Kombination der Siegel wurden so genauere entstehungsgeschichtliche Zusammenhänge sichtbar, die unter anderem zur Korrektur der zeitlichen Einordnung und Reihenfolge von bislang nur über die Wasserzeichen grob datierbaren Zeichnungen führte.

Für den Aufbau der Wikibase wurden Klassifizierungen und Unterklassifizierungen vorgenommen, die ein bestmögliche und anschauliche Darstellung der Bezüge zwischen Siegel, Sieglern, den jeweiligen Trägern, ihren inhaltlichen und formalen Merkmalen (zum Beispiel Wasserzeichen) erlauben.

Für die Siegel wurden zunächst feste IDs vergeben. Basierend auf den beschreibenden Properties Siegeln lassen sich über sogenannte Qualifiers komplexere Merkmale und Aussagen zu Siegel und siegelführender Person angeben und verknüpfen. Weitere Informationen zu Objekten und Personen (zum Beispiel Referenzen auf Archiv- und Literaturquellen oder Bemerkungen zur Identifizierung der Siegel) können durch eine Kommentarfunktion ergänzend hinzugefügt werden. Bei den Werkeinträgen im Vitro/SAH-Portal ist ein direktes Referenzieren auf die IDs der Marken möglich. Gleichzeitig sind über die Wiki-Base direkte Verweise auf die Pläne mit ihren Werkeinträgen im SAH-Portal angelegt.

Eine Besonderheit ist das mit Piktogrammen unterstützte Glossar, das als begleitendes Corpus zu den beschreibenden Feldern der Siegelmotive und der Zusammensetzung der jeweiligen Marken herangezogen werden kann. Es beruht auf einem vereinheitlichten Fachvokabular (angelehnt an das Vokabular der Blasonierung für Hausmarken), auf das nun generell referenziert werden kann.

Durch die fokussierte Betrachtung eines einzelnen – leicht übersehbaren – Phänomens auf den Nürnberger “Proberissen” können nun neue Einsichten in die Geschichte und Entwicklung des Bauhandwerks und der Baupraxis in der Frühen Neuzeit gewonnen werden. Gleichzeitig wurde eine Wissensdatenbank aufgebaut, die mit ihren gesammelten Daten im Linked-Data-Format öffentlich zugänglich und verknüpfbar ist und in Zukunft weiter kollaborativ bearbeitet und erweitert werden kann.

Wikibase for Digital Humanities, documentation by the DARIAH-EU DHwiki working group:

"These pages explore the significant role of Wikibase, the software behind Wikidata, as a powerful and versatile tool for creating structured knowledge bases following the principles of Linked Open Data (LOD). "

https://dhwiki.wikibase.cloud/wiki/Documentation

#wikibase #wikidata #mediawiki @wikimediaDE

Normdaten & Personendaten: Anreicherung mit Wikibase
📅24.04.2026
📍Online

Nach einem Vortrag von Ruth Bruchertseifer zur Arbeit im Projekt „Aschkenas in neuen Lebenswelten“, sind Sie gefragt!
Mit den Expert*innen Dr. Katrin Moeller und Dr. Olaf Simons können Sie Ihre eigenen Personendaten in einer Wikibase anreichern.
Sichern Sie sich die letzten Plätze!

👉Alle Infos unter: https://hermes-hub.de/aktuelles/events/byodl-2026-04-24.html

#HERMES #Wikibase #Enriching #BringYourOwnData #TrierUniversity

Upgrade abgeschlossen: Semantic Wikibase kompatibel mit MediaWiki 1.43

Wir freuen uns, bekanntzugeben, dass Semantic Wikibase erfolgreich auf Kompatibilität mit MediaWiki 1.43 aktualisiert wurde. Mit diesem Schritt stellen wir sicher, dass Semantic Wikibase weiterhin mit der aktuellen Longterm-Support-Version von MediaWiki kompatibel bleibt und als stabile Grundlage für semantisch angereicherte Wissensinfrastrukturen dient.

Über Semantic Wikibase

Viele Forschungsprojekte setzen das Mediawiki-Framework als Werkzeug für Forschungsdatenmanagement ein. Mit über 1.500 Erweiterungen lässt sich dieses an die individuellen Anforderungen anpassen:

• als reines Wiki mit Text und Medien, organisiert in Artikelseiten nach dem Vorbild von Wikipedia,
• als strukturierte Wissens-Datenbank zur Linked-Open-Data Implementierung von Wissensgraphen und Terminologien mittels Wikibase,
• als semantischer Wissensspeicher zur Datenvisualisierung mittels Semantic Mediawiki.

Semantic Mediawiki vs. Wikibase

Insbesondere Wikibase und Semantic Mediawiki werden häufig im Forschungsumfeld verwendet. Beide Erweiterungen haben unterschiedliche Stärken und Schwächen:

Semantic Mediawiki und Wikibase

Die Entwicklung von Semantic Wikibase (SWB) ermöglichte es erstmals, beide Erweiterungen gemeinsam auf einem System zu verbinden und so die Vorteile beider Systeme gemeinsam zu nutzen. Während strukturelle Wissensdaten in Wikibase gespeichert und verwaltet werden, sorgt die SWB-Erweiterung dafür, dass diese auch in Semantic Mediawiki für die Visualisierung in Wiki-Artikeln verfügbar sind. SWB dient also quasi als Brücke zwischen den beiden Erweiterungen, wobei der Datenfluss nur von Wikibase nach Semantic Mediawiki (nicht umgekehrt) erfolgt. Dies dient dazu, Datenkonflikte zu vermeiden.

Semantic Wikibase wurde im September 2020 in einer ersten Version vom Unternehmen ProfessionalWiki veröffentlicht. Dieser erste Prototyp war nur mit der älteren Mediawiki Version 1.35 kompatibel, aber unterstützte bereits grundlegende Datentypen. Im Open Science Lab sahen wir in der Entwicklung einen Baustein, der das Potenzial hat, im Mediawiki-Umfeld eine bedeutende Lücke zu schließen: Die Kombination aus strukturierter, föderierbarer Datenverwaltung und Datenpräsentation. Unser Ziel war es, die Erweiterung zu testen, bei Bedarf weiterzuentwickeln und künftig als unser Content-Management-System zur Unterstützung von Forschungsprojekten zu verwenden.

Case Studies

Mitte 2024 wurde mit dem Projekt PhiWiki ein erster Prototyp für Mediawiki 1.39 in Zusammenarbeit mit der Akademie der Wissenschaften und der Literatur Mainz sowie der AG Digitale Philosophie erfolgreich getestet. Es folgte mit Semantic Glossar ein weiteres Projekt zur kollaborativen Entwicklung von Terminologien mittels Semantic Wikibase.

Ende 2024 konnten wir im Rahmen des Projekts Herrenhäuser des Ostseeraums Semantic Wikibase dann in einem umfangreichen Projekt einem herausfordernden Lasttest unterziehen. Mit über 14.000 Wikibase-Objekten, die auf mehr als 300 Artikelseiten dynamisch eingebettet als Karten, Zeitstrahlen, Tabellen und Suchformulare verwendet werden, konnten wir die bestehenden Schwächen von Semantic Wikibase identifizieren und beheben. Dazu gehörte unter anderem die Unterstützung des vollen Wikibase-Datenmodells mittels Qualifiers, eine erste grundlegende Unterstützung des Extended Datetime Formats (EDTF) sowie die Einbettung von 3D-Visualisierungen aus Semantic Kompakkt. Entscheidend war hierfür die interdisziplinäre Zusammenarbeit zwischen dem Enwicklerteam und den LOD- und Wikibase-Datenmodell-Expertinnen Lozana Rossenova und Lucia Sohmen.

Die im Projekt entwickelten Best-Practices umfassten unter anderem:

• Nutzung individueller Formulare für Suchfilter und Dateneingabe
• Verknüpfung von Wikibase-Items mit Mediawiki-Kategorien
• Verlinkung von Artikelseiten mit Wikibase-Items
• Nutzung des vollen Wikibase-Datenmodells in SMW Inline Queries
• Performance von Datenvisualisierungen trotz hoher Anzahl an Wikibase-Objekten
• Best Practices zur Informationsmodellierung im Generic Wikibase Model for Cultural Data

Warum MediaWiki 1.43 wichtig ist

Mit der Version 1.39 war Semantic Wikibase kompatibel mit der damaligen Longtime Support Version(LTS) von Mediawiki. Diese Unterstützung war aber gemäß des Mediawiki Lifecycle nur bis Ende 2025 gegeben.

MediaWiki 1.43 bringt als aktuelle LTS-Version (Support bis 2028) zahlreiche technische Verbesserungen, Performance-Optimierungen sowie langfristige Wartungsvorteile mit sich. Für viele Wikibase-Installationen ist die Orientierung an den aktuellen MediaWiki-Versionen essenziell, um Sicherheit, Stabilität und Zukunftsfähigkeit zu gewährleisten. Durch Versionskonflikte zwischen verwendeten Bibliotheken in Wikibase und Semantic Mediawiki, konnte SemanticWikibase aber nicht ohne Anpassung in dieser neuen Version eingesetzt werden.

Unsere größte Befürchtung war, dass die aktuellen Versionen grundlegende Änderung vorgenommen hatten, die einen Weiterbetrieb von Semantic Wikibase technisch unsauber bzw. unwirtschaftlich machen würden. Ende 2025 schaffte Open-Science-Lab-Entwickler Lukas Günther die entscheidende Grundlage für das Upgrade, indem er unser Installationstool Wikibase4Research aktualisierte und so mit der Mediawiki Version 1.44 kompatibel machte. Da Semantic Wikibase sich mittels Wikibase4Research automatisiert installieren lässt, war so ein geeignetes Test-Setup geschaffen, um die Entwicklung in Angriff zu nehmen. Letzendlich war es uns so möglich, Semantic Wikibase mit der aktuellen LTS-Version von Mediawiki zu betreiben und das sogar ohne Änderungen am Wikibase- oder SemanticMediawiki-Code vorzunehmen. Sämtliche bisher unterstützten Datentypen sind auch weiterhin funktional, was auch ein Update bestehender Installationen auf die neue Version ermöglicht.

Ausblick

Die kontinuierliche Synchronisierung von Semantic Wikibase mit dem MediaWiki-Releasezyklus ist ein zentraler Baustein für nachhaltige, semantische Wissensinfrastrukturen. Mit diesem Update schaffen wir die Grundlage für kommende Weiterentwicklungen und eine langfristig stabile Integration in das Wikibase-Ökosystem. Der Einsatz von Semantic Wikibase bedeutet für unsere Forschungsdaten- und Terminologie-Projekte im Open Science Lab:

• Fokussierung auf eine gemeinsame technologische Basis für alle Projekte
• Bündelung von Wissen und Ressourcen
• Zeitersparnis bei der Projektumsetzung durch Best Practices und Synergieeffekten zwischen Projekten
• Koordinierter Aufbau von Services innerhalb eines bestehenden Software Ökosystems
• Support der Open-Source und Linked-Open-Data Community durch unsere Entwicklungen

Wir freuen uns auf die weitere Entwicklung und die vielfältigen kommenden Projekte mit Semantic Wikibase.

Relevante Links

• Wikibase4Research
• Generic Wikibase Model for Cultural Data

Bessere KI-Antworten – auch ohne Hochleistungsrechner

KI-Systeme, die Texte nicht nur generieren, sondern gezielt in Dokumenten recherchieren, sind mittlerweile etablierter Stand der Technik. Einer dieser Ansätze heißt Retrieval-Augmented Generation (RAG): Stellt ein Benutzer eine Frage, sucht das System relevante Informationen in einer Wissensbasis – zum Beispiel in einem Wiki – und nutzt diese als Grundlage, um relevante Inhalte bzw. Quellen aufzulisten oder mittels KI Antworten daraus zu generieren.

Das Problem: Damit ein solches System gut funktioniert, müssen viele Stellschrauben richtig eingestellt werden. Diese sogenannte Hyperparameter-Optimierung ist normalerweise entweder zeitaufwändig oder rechenintensiv und in jedem Fall technisch anspruchsvoll. Unsere aktuelle Untersuchung zeigt jedoch: Eine automatisierte Optimierung ist möglich – sogar auf einem normalen Laptop.

Ausgangslage

Grundlage unserer Untersuchung im Open Science Lab war die Weiterentwicklung unseres RAG-Moduls für Wikibase4Research. Mit dem zuvor bestehenden System war es bereits sehr einfach möglich, eine Mediawiki Installation zu erhalten, deren Inhalte KI-gestützt via RAG durchsuchbar sind. Egal ob es nun um Artikelseiten in einem einfachen Mediawiki, strukturierte Wissensdaten in einer Wikibase oder eine Kombination aus beidem wie zum Beispiel Semantic Mediawiki oder Semantic Wikibase geht.

Eine Einführung in die grundlegende Funktionsweise von RAG und Wikibase4Research liefert das folgende Video:

Um eine hohe Qualität der KI-basierten Suchergebnisse und Antworten zu erhalten, ist es aber nötig, das System entsprechend der verwendeten Daten zu konfigurieren. Für diese Einstellungen gibt es keine Standardfälle, es gehört in das Arbeitsfeld eines Data Scientist die Systemparameter zu testen und zu verbessern. In diesem Prozess wird daher klassisch ein hohes Maß an Erfahrung und Fachwissen benötigt, um optimale Ergebnisse zu erhalten.

Die Alternative ist der nun in Wikibase4Research integrierte AutoRAG Ansatz, der die Parameter vollautomatisch optimiert. Dieser Prozess wird im Farchjargon „Hyperparameter Tuning“ oder auch „Hyperparameter Optimierung“ genannt.

Anforderungen

Die Rahmenbedingungen für ein Hyperparameter Tuning können sehr unterschiedlich sein. In unserem Fall ergeben sich die Anforderungen vor allem aus der Nutzergruppe von Wikibase4Research.

Forscher/Innen

Im Forschungskontext haben wir es mit fächerspezifischen Daten zu tun. Die beteiligten Wissenschaftler sind Experten in ihrer jeweiligen Fachdomäne. Expertise im Bereich spezieller Data-Science-Anwendungen ist in den Projektteams meist nicht vorhanden. Dies ist durchaus sinnvoll, denn das Projektteam ist somit auf die im Projekt zu bearbeitenden Forschungsfragen spezialisiert.

Daten

Für die Optimierung wird ein Test-Datensatz benötigt, der mögliche Fragen (Suchanfragen) mit den optimalen Quellen in den Daten verknüpft. Dieser Datensatz wird mit den Suchergebnissen des Systems verglichen, um die Qualität der Systemeinstellung bewerten zu können (Idealdaten). Solche Testdaten liegen in den überwiegenden Fällen nicht vor.

Endnutzer/Innen

Wer nutzt die Daten letztendlich und welche Art von Anfragen werden gestellt? Diese Frage ist entscheidend bei der Optimierung. Werden die Endnutzer spezifische Fakten aus den Daten abfragen wie zum Beispiel Jahreszahlen bestimmter Ereignisse oder eher Zusammenfassungen ganzer Absätze oder Artikel erwarten? Zu welchen Themen werden voraussichtlich Fragen gestellt? Erwarte ich eher Fragen zum Inhalt der Daten oder Fragen auf der Metaebene wie zum Beispiel zur Anzahl von Quellen, der Struktur und Länge von Texten, des Schreibstils oder zur Medienart? Werden Suchanfragen von Wissenschaftlern im Fachjargon gestellt oder eher in Umgangssprache formuliert? Die frühzeitige Definition grundlegender Personas für die zu erwartende Nutzergruppe hilft nicht nur bei der Optimierung von RAG, sondern ist auch ein wichtiger Schritt bei der Erstellung von Design und Benutzeroberflächen in der Präsentation der Forschungsergebnisse.

Infrastruktur

Hohe Rechenkapazitäten, Zugang zu GPU-Processing und Budget für industrielle KI-Services ist in vielen Projekten nicht vorhanden. Wikibase4Research bietet die Option, externe Schnittstellen wie Huggingface, OpenAI oder die SAIA-Umgebung der GWDG zur Ausführung von KI-Modellen zu nutzen. Die dort bestehenden Limits für kostenlose Nutzung reichen aber meist nicht aus, um die Vielzahl an Parameter-Konfigurationen zu testen, die zur Optimierung eines RAG-Systems notwendig ist. Ideal wäre also, die Ausführung lokal auf allgemein verfügbarer Hardware durchführen zu können, was auch unter dem Aspekt der ressourcenschonenden Nutzung von KI ein erstrebenswertes Ziel ist.

Es ergibt sich für unseren Ansatz daher folgender Anforderungskatalog:

• Anpassung auf die verwendeten Daten
• vollautomatische Optimierung
• keine technischen Vorkenntnisse nötig
• Test-Datensatz wird generiert
• User-Persona-Profile berücksichtigen
• möglichst effizient, mit geringem Ressourcenbedarf

Methodik

Daten

Als Datengrundlage dienten jeweils 50 zufällige Artikel aus drei MediaWiki-basierten Wissenssammlungen:

• Wikipedia
• Herrenhäuser
• Kungfu-Wiki

Um die Qualität der Suche zu bewerten, wurden automatisch Frage-Kontext-Antwort-Tripel erzeugt. Zum Einsatz kam dafür das mehrsprachige Sprachmodell IBM Granite 4 350M Nano, das speziell für Umgebungen mit geringer Rechenleistung wie zum Beispiel für On-Device-Anwendungsfälle entwickelt wurde.

LLM-Prompt

Um hinsichtlich der erwarteten Nutzung realistische Fragen zu generieren, wurde der an das Modell gelieferte Prompt („Erstelle Fragen aus dem Seiteninhalt“) um speziell angepasste Rollenbeschreibungen (Personas) ergänzt, die per Konfigurationsdatei individualisiert werden können. Eine solche Persona-Definition könnte zum Beispiel lauten: „You are a scientist who wants to learn about historic manorhouses in Europe“.

Parameter

In einem RAG-Prozess werden die zu durchsuchenden Daten in einer speziellen Datenbank indiziert, um später schnell und effizient relevante Inhalte zu finden.

Die meisten von uns verwendeten Parameter optimieren diesen Prozess der Informations Extraktion (IE). Dabei wird bestimmt, in welcher Form die Daten gespeichert werden und ob diese ggf. vor dem Speichern um Metadaten wie Schlagworte, Titel oder Zusammenfassungen ergänzt werden. Für die Vektorisierung verwendeten wir das Modell Qwen3-embedding:0.6B. Die mittels AutoRAG optimierten Parameter sind im Folgenden aufgelistet:

• Chunk_Size: Wie groß sind die Informationsabschnitte, die später zugreifbar sein sollen?
• Chunk_Overlap: Wie stark überlappen sich die Informationsabschnitte?
• Extractors: Welche Datenanreicherungen sollen erfolgen (zum Beispiel Zusammenfassung erstellen, Fragen generieren)?
• Top_K: Wieviele Chunks werden als Suchergebnis geliefert?

Sind die Daten eingelesen und wird eine Suchanfrage gestellt, wird das System nach relevanten Informationsabschnitten durchsucht. Dieser Prozess wird „Information Retrieval“ genannt. Man kann es mit den Ergebnissen einer Google-Suche vergleichen, bei der die relevantesten Ergebnisse nicht zwangsläufig an erster Stelle der Liste stehen.

Information Retrieval bedeutet, zur Frage des Nutzers relevante Informationen zu finden. In diesem Prozessschritt optimieren wir den Parameter „Top_K“, der definiert, wie viele der Suchergebnisse im weiteren Prozess berücksichtigt werden. Ist Top_K zu klein, sind wichtige Quellen eventuell nicht enthalten. Ist Top_K zu groß, verarbeitet man eventuell eine große Menge wenig relevanter Inhalte.

Optimierungsverfahren

Statt alle möglichen Kombinationen auszuprobieren (was sehr lange dauern würde), kommt ein Suchalgorithmus zum Einsatz, der die verschiedenen Parameter stufenweise verbessert. Dieses als Greedy („gierig“) benannte Verfahren optimiert zunächst nur einen einzigen Parameter, dann den nächsten usw. Wir verzichten damit auf optimale Lösungen, erreichen aber hinreichend gute Ergebnisse mit akzeptablem Aufwand.

Als Bewertungsmaß für die Optimierung dient dabei der sogenannte Mean Reciprocal Rank (MRR) – ein Maß dafür, an welcher Position relevante Inhalte in der Trefferliste platziert sind. Ein entscheidender Vorteil:
Die Bewertung erfolgt vollständig ohne KI-Antwortgenerierung. Es wird also nur getestet, wie gut das System relevante Inhalte findet, nicht wie gut eine KI daraus später Antworten generiert. Dadurch wird erheblich Rechenzeit gespart.

Technische Umsetzung

Die Implementierung erfolgte vollständig im MediaWiki-Umfeld mit:

• Wikibase4Research
• einer Docker-basierten Python-API
• dem RAG-Framework LlamaIndex
• lokaler Modellbereitstellung über Ollama

Die Experimente liefen auf einem handelsüblichen Laptop aus dem Jahr 2022 (Dell Latitude 5421, Intel Core i7-11850H mit 8 Kernen, 16 GB RAM) – ohne GPU-Beschleunigung.

Ergebnisse

Trotz der bewusst schlanken Hardware-Ausstattung konnte die Optimierung meist bereits innerhalb einer Stunde abgeschlossen werden. Dabei wurde bei allen Datensätzen eine starke Verbesserungen der Abfrageergebnisse erzielt.

Für unser Qualitästmaß, den Mean Reciprocal Rank (MRR), ergab sich eine Steigerung von durchschnittlich 12 bis 25 Prozent gegenüber den voreingestellten Parametern. Das bedeutet, in den Ergebnissen der Suchanfrage waren mehr relevante Quellen aufgeführt und relevante Quellen standen in der Ergebnisliste an höherer Stelle als zuvor. In einzelnen Datensätzen ergaben sich sogar Verbesserungen von bis zu 50 Prozent. Dabei ließen sich vergleichbare Ergebnisse auch mit Artikeln erreichen, die nicht Teil der Optimierungsschleife waren (Cross-Validation).

Warum ist das relevant?

Für wissenschaftliche Infrastrukturen wie digitale Bibliotheken, Fachrepositorien oder Forschungsdatenplattformen ist es entscheidend, KI-Systeme effizient und ressourcenschonend betreiben zu können. Die Ergebnisse zeigen: Sinnvolle RAG-Optimierung ist auch ohne Rechenzentrum machbar.

Das senkt technische Hürden, reduziert Kosten und macht den Einsatz moderner KI-Technologien auch in kleineren Projekten realistisch.

Ausblick

Die für die Suche verwendeten Embedding-Vector-Modelle haben einen erheblichen Einfluss auf die Ergebnisse (vgl. Orbach et al. (2025)) und zwar sowohl auf die Rechenzeit als auch auf die Ergebnisqualität. Dabei zeigen Modelle nicht auf allen Datensätzen die gleichen Ergebnisse.

Es ist auch nur begrenzt möglich, die Optimierung mit extrem kleinen oder schnellen Embedding-Modellen auszuführen und die optimierten Parameter dann zusammen mit einem anderen, leistungsfähigen Modell im Live-Betrieb einzusetzen. Sind die eingesetzten Embedding-Modelle nicht angepasst genug an die verwendete Wissensdomäne, liefert auch die Optimierung nur suboptimale Ergebnisse.

Genau an diesem Punkt wird unsere Arbeit im Open Science Lab in der nächsten Zeit ansetzen. Gemeinsam mit den Fachinformationsdiensten FID Material Science, FID Move, FID Pyhsik und FID Philosophie evaluieren wir die Möglichkeit einer stärkeren Vernetzung von NFDI und FIDs mit dem Ziel, die einzelnen Wissendomänen mit fachspezifischen Embedding-Modellen zu versorgen. Zielsetzung ist es, damit den Zugang zu dieser Technologie noch weiter zu vereinfachen sowie die Qualität der Ergebnisse von KI-Anwendungen im Forschungs- und Bibliotheksumfeld gezielt zu erhöhen.

Prof. Dr. Ina Blümel, Open Science Lab // Foto: TIB/C. Bierwagen

„AutoRAG ist für uns ein wichtiger Innovationsschritt: Es macht RAG in offenen Wissensräumen wie Wikibase messbar, wiederholbar und mit überschaubaren Ressourcen betreibbar. Für Projekte wie NFDI4Culture und weitere Vorhaben im Open Science Lab bedeutet das spürbar bessere, nachvollziehbare KI-gestützte Suche über heterogene Bestände – ohne dass tiefes Spezial-Know-how aufgebaut werden muss. Nächster Schritt ist der Ausbau fachspezifischer Embeddings, kuratierter Testsets und transparenter Workflows, damit die Qualität und Nachnutzbarkeit langfristig steigt.“

Relevante Links

• Wikibase4Research: https://gitlab.com/nfdi4culture/wikibase4research/wikibase4research
• Wikibase4Research-RAG Modul: https://gitlab.com/nfdi4culture/wikibase4research/wikibase-RAG

WikiApiary is back online after having been down and overloaded for a long time.

Bawolff brought it back and did a ton of full stack performance work to optimise the whole system. Adding HTTP caching, tuning InnoDB, and more!

https://blog.bawolff.net/2026/03/giving-wikiapiary-kick.html

#MediaWiki #WikiApiary #Wikibase #Wikidata #VinylCache #VarnishCache #MariaDB #MySQL #webperf #SRE

RE: https://wikipediapodden.se/wikibase-cloud-martyn-ranyard-360/

I got the chance to speak with Martyn Ranyard, Engineering manager at Wikibase Cloud. (Ping @Wikibase ) #Wikibase

@lozross von @tibhannover bei #awl2026 zum ECHOLOT Projekt, das die Europäische Kulturerbe Cloud (ECCCH) und Europeana besser mit dem Wikiversum verbinden soll

#mediawiki #wikibase #wikidata #openglam

Introducing NeoWiki... and more

NeoWiki is the modern #OpenSource collaborative knowledge management solution. Co-presented with @krabina who covered @ECHOLOT_Project

Discover #NeoWiki, MediaWiki #MCP, and #Wikibase extensions via our recap of the #MediaWiki Users and Developers Conference

https://professional.wiki/en/news/our-talks-at-mudcon

📝 An article we co-authored with @tibosl @tibhannover, colleagues Ina Blümel & Lucia Sohmen is finally out via the Journal of Open Humanities Data (special issue on #Wikidata): https://doi.org/10.5334/johd.440

It outlines hands-on learnings from the data curation workflows Lucia Sohmen has implemented in our lab within three concrete (and openly accessible) datasets. In addition, the article sets out the overall strategy Ina Blümel and myself have developed for managing cultural heritage data projects in the context of an interconnected Linked-Open-Data-driven Wikibase Ecosystem.

Check out the article, the supplement (with links to live queries & data viz) and let us know if it resonates with how you implement Wikidata in your digital humanities / cultural heritage projects!

#CulturalHeritage #Wikidata #Wikibase #DigitalHumanities #OpenScienceLab #LinkedOpenData

Segnaliamo un workshop organizzato dal Naples Dante Project in collaborazione con Wikimedia Italia.

25 marzo 2026 h. 10-13, presso la Biblioteca BRAU, Camillo Carlo Pellizzari di San Girolamo (coordinatore regionale Toscana e dottorando presso la Scuola Normale Superiore di Pisa)

"Open Data per la ricerca umanistica. Workshop sull'utilizzo di Wikidata e Wikibase".

#OpenData #Wikidata #Wikibase