#semanticmediawiki — Public Fediverse posts

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

I still have to deal with #WebsiteOutages , and currently I have another massive one which won't go away by purging the Varnish cache. As usual, the outage started between 23:00 and 24:00 UTC, which is _weird_.

I have asked Gandi.net customer service a few weeks ago, but beyond suggesting blocking a random crawler, they said the following:

"Personally, I would check the plugins on my various websites and the scheduled tasks (especially backup plugins)."

I don't remember installing such plugins manually. Does anyone know of such processes that are installed on either #WordPress or #MediaWiki sites by default? (Or perhaps this is done by #SemanticMediaWiki ?)

In three days I will be leaving for a vacation, so this is the last opportunity I have to improve this situation this year.

#WebsiteAdministration
https://wiki.sunkencastles.com/

Next up at #MUDCon2025, Lukas Günther from @tibosl presents the work of the OSL team in configuring a flexible setup for our combined product #Wikibase4Research which wraps together #Wikibase, #SemanticMediaWiki, #SemanticWikibase, #SemanticKompakkt & more expensions useful to our research data management use cases, including our primary use cases in the context of @nfdi4culture

📽️ Follow along live: https://www.youtube.com/watch?v=jCjaMnxgq2Q

#openscience #opensource

More from #MUDCon2025 on the topics of AI applications & #MediaWiki development: Jeffrey Wang presented an excellent experimental analysis of current state of 'vibe coding' when developing a sample MediaWiki extension. Proposal - switching to spec-driven approach & staying open for further developments in the future.

📽️ Catch up on the full talk, including demo, via the livestream: https://www.youtube.com/watch?v=WjWzELDLmkc

#opensource #semanticmediawiki

The afternoon sessions of #MUDCon2025 are underway and we have one more contribution from the @tibosl team. This time Kolja Bailly presents (via pre-recorded video) on current work to integrate RAG (retrieval augmented generation) techniques to retrieve data in more intuitive ways from our Wikibase & SemanticWikibase projects, including concrete use cases. The work builds upon previous efforts from TIB colleague Alexander Gesinn and his integration of LlamaIndex for SemanticMediaWiki. It's early stages of work-in-progress, but we plan to release alpha version of the RAG extension for Wikibase4Research by end of 2025.

Video available via the livestream: https://www.youtube.com/watch?v=WjWzELDLmkc

#openscience #opensource #semanticmediawiki #wikibase

On a meta topic of conferences, and acceptance rates and predatory practices, at the #MUDCon2025 @tibhannover's Director @soeren_auer presents on a historic #semanticmediawiki project recording data on scientific conferences. Open for further collaboration & community contribution, but also a project that can effectively explore the possibilities/challenges of using symbolic AI approaches for data curation.

Interestingly we also learn some more Leibniz trivia and the connection between the LUH logo, the binary system, China and Leibniz' notebooks.

📽️ Follow online: https://www.youtube.com/watch?v=WjWzELDLmkc

#openscience #opensource

And on the topics of #cultureheritage data and #wikibase at #MUDCon2025, our @tibosl colleague Lucia Sohmen presents our work and ongoing challenges using formal data models for cultural data in our service #Wikibase4Research, part of the @nfdi4culture service portfolio.

Lucia presented ideas on our current workarounds, but also what we see as crucially missing in current status quo, opening up the floor to discussions about future development & what #ECHOLOT might be able to offer.

Follow along (or catch up) via the live stream: https://www.youtube.com/watch?v=WjWzELDLmkc

#openscience #opensource #semanticmediawiki #wikibase

And we're officially announcing the #ECHOLOT project publicly for the first time at the #MUDCon2025 with @krabina from KMA, one of our partners in this new HORIZON Europe collaborative project. Bernhard provided some history and context to the project idea, and we outlined how we are reimagining the #MediaWiki software for the future of connected cultural heritage data together with a dozen other EU organisations. More details on the project will be published soon on the @tibhannover website.

In the meantime, stay tuned and follow along the MUDCon: https://www.youtube.com/watch?v=WjWzELDLmkc

#openscience #opensource #semanticmediawiki #wikibase

#MUDCon2025 is continuing today with various use cases for #MediaWiki software incorporating semantics – from open government data projects (@krabina) to scientific data from electronic lab notebooks (Thomas Gruber – Helmholtz-Zentrum Dresden-Rossendorf (HZDR)) and various interconnected humanities data (FlorianThiery – LEIZA), including a mention of @nfdi4culture & #SemanticKompakkt.

📽️ Follow the livestream for more throughout today and tomorrow: https://www.youtube.com/watch?v=WjWzELDLmkc

#openscience #opensource #semanticmediawiki #wikibase

@lycanmatriarch

MediaWiki (e.g. powerful search, category and template features) , maybe together with Semantic MediaWiki extension for advanced semantic tagging and data processing. Forms (like in Confluence) can easily be added by PageForms extension (https://www.mediawiki.org/wiki/Extension:Page_Forms). And much more ...

If you need commercial support and better integration out of the box, consider https://bluespice.com, that extends MediaWiki to become company-ready.

#MediaWiki #Bluespice #SemanticMediaWiki

La Conférence SemanticMediaWiki commence aujourd’hui pour 3 jours, en présentiel à Vienne et en distanciel sur YouTube.

Il sera discuté de cas d’usage de certains utilisateurs, d’extensions en développement et du panorama de la gestion de connaissances.

https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_Fall_2024
https://conference.knowledge.wiki/

#SMWCon #SemanticMediaWiki #MediaWiki #wiki

The #MediaWiki Users and Developers Conference is happening next week and features a panel on Semantic Wikibase.

Semantic Wikibase makes Wikibase data available in #SemanticMediaWiki to be queried, visualized, and exported. https://buff.ly/3Cg7Zoj

As the creators of Semantic Wikibase and key players behind both #Wikibase and @smw, our lead developer @jeroen will represent us on this #MUDCon panel. https://conference.knowledge.wiki

@MWStake will be hosting the #MediaWiki Users and Developers Conference (#MUDCon) Fall 2024 between 4/11/2024 and 6/11/2024.

#MUDCon will be a three-day conference featuring discussions of topics related to the usage of MediaWiki software by and within companies, non-profits, governments, organizations, and communities, including the #SemanticMediaWiki community.

🖳 🛈 https://www.mediawiki.org/wiki/Special:MyLanguage/MediaWiki_Users_and_Developers_Conference_Fall_2024

#SMWCon

SmartComments enables you to highlight text and comment on that section in #mediawiki, with a central page where you can review, reply to and close all comments.
With #SemanticMediaWiki it also gives semantic annotation.
Presented by our @archixl colleague Robin van der Wiel at #SMWcon
https://www.semantic-mediawiki.org/wiki/SMWCon_Fall_2023/Extension_for_creating_and_managing_inline_comments