#wikibase — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #wikibase, aggregated by home.social.
-
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 -
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:
Vergleich von Wikibase and SMW (Grafik by Bernhard Krabina)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.
Unterstützte Datentypen in Semantic Wikibase, visualisiert im Semantic Browser von SMWAusblick
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
#LizenzCCBY40INT #Wikibase4Research #OpenScienceLab #SemanticWikibase #Wikibase #WeLoveFreeSoftware #NFDI4Culture #SemanticWeb #linkedOpenData #semanticPublishing #SemanticKompakkt #SemanticMediawiki -
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:
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.
Information Extraction und Indizierung von Daten in einem RAG-ProzessDie 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 in einem RAG ProzessInformation 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:
Antwort Generierung in einem RAG Prozess. Diese Phase wurde in der Optimierung NICHT berücksichtigt
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
-
Normdaten & Personendaten: Anreicherung mit Wikibase
Ein Online-Bring-your-own-data-Lab
📅 24.04.2026
📍OnlineNach 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.👉 Alle Infos unter: https://hermes-hub.de/aktuelles/events/byodl-2026-04-24.html
#HERMES #Wikibase #Enriching #Bring-your-own-data @trieruni
-
As with most of our events this year, the discussion was driven by our translation project of the OCLC Passage white paper. Due to the nature of LightBox Library, its audience aligns closely with the paper’s original target audiences. Their specialization in photography also allowed us to dive deeper into the case studies presented in the paper and ground the discussion in real-world practice.
#wikidata #鏈結資料 #鏈結開放資料
#LinkedOpenData #LOD
#Wikibase #OCLC #維基數據 #維基資料
#活動 #event #攝影圖書室 #臺北市 #大安區 -
Wir lernen gerade, wie man eine #Wikibase selbst aufsetzt und #Items und #Properties anlegt.
ℹ️ Man muss sich grundlegend Gedanken über das #Datenmodell machen und #Entities und #Aussagen logisch miteinander verknüpfen. Auch wenn wir schon lange mit #Daten arbeiten, ist es nicht so einfach, bei 0 anzufangen. 😎
💡 Wie benennt man Dinge, wie hängt was miteinander logisch zusammen, wie sind die #Hierarchien, was ist eine Property....
#Terminologien @FactGrid @DHd @DHdKonferenz #DHd2026 @t_duan
-
Hacking the bishops 😇 😎 auf dem heutigen #Workshop @DHdKonferenz 💻
#DHd2026 #Wikibase #Wikidata #Wikiverse @GermaniaSacra #Normdaten #Datenmodellierung #Datenqualität #Datenintegration
-
在轉換(成鏈結資料工作流程的)期間，圖書館必須分出有限的人力來處理增量的資料但是卻同時也造成人力的短缺來進行後設資料的建立。在這樣的情境下，鏈結資料(Linked Data)同時是問題的解答以及製造者。鏈結資料系統到底是降低了人力的需求呢 (相較於傳統的紀錄建立模式) ？抑或將圖書館的工作拓展至更多元的資料建立、數據鏈結機會並終將導致人力需求的提升 ？至今為止對鏈結資料所做出的努力是否已經建立足夠的高品質資產 ？畢竟只有超越臨界數量，一般大眾才能在搜尋引擎上發現並體驗圖書館的蒐藏。
雖然這些年來從圖書館社群中所輸出的鏈結資料有著顯著提升 - 包括目錄來自國立圖書館以及識別碼中心如： #美國國會圖書館 的 id.clo.gov ，以及 OCLC 的 #VIAF (Virtual International Authority File #虛擬國際權威檔案 )。鏈結資料的採用需要花費大量的先期投資在建立 "資源-描述" 標準、系統環境、以及工作流程等基礎支援，其規模往往超出一般機構組織所能承擔。這問題困擾了大多數的 #圖書館 在鏈結資料運動的努力。為了獲取所需之資源，領銜者必須先證明採用鏈結資料價值，而其價值的證明卻也需要先前投資才能進行。
摘自【透過 Wikibase 建立屬於圖書館的鏈結資料 Passage 專案的成果 臺灣譯本 簡介】
作為文化工作者、文史資料產出者，我們應該如何將資料公開並讓一般大眾能夠被搜尋到，透過圖書館在 Wikibase 平台上的探索與研究，我們可以以此為案例協助臺灣的文化資料能夠抵達大眾、國際視野。
想要深入了解如何透過鏈結資料工作流程來協助文化工作，歡迎參加 12/26 鏈結資料與圖書館的碰撞：OCLC Passage 專案成果報告翻譯與摘要 講座，活動中我們會摘要文獻中提到的工作流程，並結合臺灣過去的經驗分享未來臺灣社群可採用的方向。
活動報名頁面：https://wikidatatw.kktix.cc/events/wikidatatw2025
#wikidata #鏈結資料 #鏈結開放資料
#Linkeddata #LinkedOpenData #LOD
#Wikibase
#OCLC #維基數據 #維基資料
#活動 #event #攝影圖書室
#臺北市 #大安區 -
臺灣維基數據社群在 2025 年推動【Creating Library Linked Data with Wikibase: Lessons Learned from Project Passage】翻譯專案，一年之中除了全文翻譯為華語以外，我們也與臺灣不同族群共同合作推出了臺灣台語以及賽德克語等不同在地語言的社群摘要，期待以新的社群工作方式來推動國際鏈結資料文獻讓更多臺灣在地社群了解並應用在社群工作之中。
文件中提及的 Passage 專案就是以圖書館為對象、Wikibase 作為實驗的平台，讓圖書館工作人員實質瞭解鏈結資料的概念，並在專案結束後將 Wikibase 的使用心得整理在文件之中。
本次活動為 2025 年鏈結資料文獻臺灣翻譯發表的最終場，特別與 Lightbox攝影圖書室合作舉辦，除了內容的發表、翻譯經驗的分享以外，也特別借助這次的機會與攝影圖書館交流對於鏈結資料的看法。
歡迎社群好友共同參與，只是活動場地座位有限記得盡早報名喔！
。時間：12 月 26 日晚上七點至晚上九點
。地點： Lightbox攝影圖書室 (臺北市大安區羅斯福路三段269巷19號)
。報名頁面：https://wikidatatw.kktix.cc/events/wikidatatw2025#wikidata #鏈結資料 #鏈結開放資料
#Linkeddata #LinkedOpenData #LOD
#Wikibase
#OCLC #維基數據 #維基資料
#活動 #event #攝影圖書室
#臺北市 #大安區 -
2025 年 Wikidata Taiwan 社群與社群譯者洪哲賢共同推出：Creating Library Linked Data with Wikibase: Lessons Learned from Project Passage 臺灣譯本翻譯計畫，希望為臺灣社群建立鏈結資料(Linked Data)、Wikibase、Wikidata 的基礎文獻論述，並提供給圖書館以及 GLAM 機構如何應用 Wikibase/Wikidata 以及鏈結資料概念的參考文獻。
OCLC 的 Passage 專案是一個開放探索的實驗性計畫，旨在協助圖書館員們獲得第一手的鏈結資料經驗。並且透過這樣的實驗來對圖書館的 "資源-描述" 工作在新舊工作流程之中的異同與潛在挑戰。
在專案期間，OCLC 與來自 16 間圖書館的圖書館員們發現了許多值得進一步討論與探索的議題，其中許多顯示了鏈結資料相較於現有系統有著顯著的效益，但是另一方面也有許多新的挑戰伴隨其中。
完整原文目前已經上線，歡迎參閱專案頁面：https://hackmd.io/@wikidata-tw/oclc2019report
-
>>> the MediaWiki/Wikidata setup allows firewall setup where report text remains intact and its data #KG representation in #Wikibase can be worked on independently, where report text can also be retreived for analysis. @tibhannover Terminology service Antelope, and @orkg #Reborn are example that would carry out experiments in community enrichment
-
我們常常聽到文獻轉成華語或是華語文獻轉成英語，那你有想過有一天研究文獻翻譯到賽德克語嗎？
Wikidata Taiwan 與長期合作的 Se-cyun Wikipidiya Seejiq 賽德克族維基百科社群首次嘗試將其中一份由 #OCLC 發布的 #Wikibase 與 #鏈結化資料 報告由臺灣華語譯者進行摘要後，再進行賽德克語版本的翻譯。
其中，我們不僅僅翻譯賽德克語版本而已，更與族人合作推出 Seediq Tgdaya ( #德固達雅賽德克語 )、Seejiq Truku ( #德鹿谷賽德克語 ) 以及 Sediq Toda ( #都達賽德克語 ) 三個不同語群的獨立譯本，在不同的文化脈絡、語言使用習慣下建立專屬的譯本。
藉由本次 Wikidata 13 週年慶系列活動，我們與賽德克族維基百科社群合作舉辦 #鏈結資料文獻翻譯賽德克語成果發表會 ，除了與大家分享如何透過 Wikibase / 鏈結化資料等概念協助各社群進行資料彙整與分享，也向大家首次公開三個賽德克語社群摘要譯本，並由族人帶領大家導讀族語內容，歡迎所有關注原住民語、L10n 相關議題的社群夥伴共同參與！
活動報名頁面：https://wikidatatw.kktix.cc/events/seediq202510
主辦單位：Se-cyun Wikipidiya Seejiq #賽德克族維基百科社群 、Wikidata Taiwan #臺灣維基數據社群
協辦單位：MoWiki 定期編輯聚會#Wikidata #WikidataBirthday #維基數據 #維基資料 #社群聚會 #活動 #event
#南投縣 #埔里鎮 #籃城里
#賽德克 #seediq #seejiq #sediq -
🗄️✨ Von der eigenen Datenbank ins Forschungsrepositorium:
Dieser #Praxislabor2025 Workshop zeigt, wie Sie mit #Wikibase & #FactGrid Daten integrieren, abgleichen und für die Community nutzbar machen. 🔍ℹ️ Details & Anmeldung: https://digigw.hypotheses.org/6396
⏰ 17.09.2025, 16–17:40
🌍 #histag25 #UniBonn -
Sortir de 2 jours Wikimedia Culture et numérique enchantée et pleine d'idées #jcn2025wmfr ✅
Avoir l'impression que c'est vendredi soir ❌
Avoir juste envie de charger de nouveaux jeux de données dans #Factgrid et de retoucher à ma #wikibase #phototheque #genealogie ⌛ -
+1 (super) #Stage au pôle ingénierie numérique du #CESR
: Développement et paramétrage d’une instance #Wikibase (écosystème @mediawiki @wikidata) retenu pour créer les référentiels de données d’autorités #BVH3 mois #Tours - Candidatures jusqu’au 10/3
#devweb #HN #informatique
Missions et profil détaillés par ici >> https://bvh.hypotheses.org/12406 -
wikidata + mediawiki = wikidata + provenance == wikiprov
by @beet_keeperToday I want to showcase a Wikidata proof of concept that I developed as part of my work integrating Siegfried and Wikidata.
That work is wikiprov a utility to augment Wikidata results in JSON with the Wikidata revision history.
For siegfried it means that we can showcase the source of the results being returned by an identification without having to go directly back to Wikidata, this might mean more exposure for individuals contributing to Wikidata. We also provide access to a standard permalink where records contributing to a format identification are fixed at their last edit. Because Wikidata is more mutable than a resource like PRONOM this gives us the best chance of understanding differences in results if we are comparing siegfried+Wikidata results side-by-side.
I am interested to hear your thoughts on the results of the work. Lets go into more detail below.
#Code #CreativeCommons #Data #digitalLiteracy #Golang #mediawiki #OpenData #OpenSource #provenance #reification #reify #siegfried #SPARQL #wikibase #wikidata
-
wikidata + mediawiki = wikidata + provenance == wikiprov
by @beet_keeperToday I want to showcase a Wikidata proof of concept that I developed as part of my work integrating Siegfried and Wikidata.
That work is wikiprov a utility to augment Wikidata results in JSON with the Wikidata revision history.
For siegfried it means that we can showcase the source of the results being returned by an identification without having to go directly back to Wikidata, this might mean more exposure for individuals contributing to Wikidata. We also provide access to a standard permalink where records contributing to a format identification are fixed at their last edit. Because Wikidata is more mutable than a resource like PRONOM this gives us the best chance of understanding differences in results if we are comparing siegfried+Wikidata results side-by-side.
I am interested to hear your thoughts on the results of the work. Lets go into more detail below.
Continue reading “wikidata + mediawiki = wikidata + provenance == wikiprov”…#Code #CreativeCommons #Data #digitalLiteracy #Golang #mediawiki #OpenData #OpenSource #provenance #reification #reify #siegfried #SPARQL #wikibase #wikidata
-
wikidata + mediawiki = wikidata + provenance == wikiprov
by @beet_keeperToday I want to showcase a Wikidata proof of concept that I developed as part of my work integrating Siegfried and Wikidata.
That work is wikiprov a utility to augment Wikidata results in JSON with the Wikidata revision history.
For siegfried it means that we can showcase the source of the results being returned by an identification without having to go directly back to Wikidata, this might mean more exposure for individuals contributing to Wikidata. We also provide access to a standard permalink where records contributing to a format identification are fixed at their last edit. Because Wikidata is more mutable than a resource like PRONOM this gives us the best chance of understanding differences in results if we are comparing siegfried+Wikidata results side-by-side.
I am interested to hear your thoughts on the results of the work. Lets go into more detail below.
#Code #CreativeCommons #Data #digitalLiteracy #Golang #mediawiki #OpenData #OpenSource #provenance #reification #reify #siegfried #SPARQL #wikibase #wikidata
-
wikidata + mediawiki = wikidata + provenance == wikiprov
by @beet_keeperToday I want to showcase a Wikidata proof of concept that I developed as part of my work integrating Siegfried and Wikidata.
That work is wikiprov a utility to augment Wikidata results in JSON with the Wikidata revision history.
For siegfried it means that we can showcase the source of the results being returned by an identification without having to go directly back to Wikidata, this might mean more exposure for individuals contributing to Wikidata. We also provide access to a standard permalink where records contributing to a format identification are fixed at their last edit. Because Wikidata is more mutable than a resource like PRONOM this gives us the best chance of understanding differences in results if we are comparing siegfried+Wikidata results side-by-side.
I am interested to hear your thoughts on the results of the work. Lets go into more detail below.
#Code #CreativeCommons #Data #digitalLiteracy #Golang #mediawiki #OpenData #OpenSource #provenance #reification #reify #siegfried #SPARQL #wikibase #wikidata
-
wikidata + mediawiki = wikidata + provenance == wikiprov
by @beet_keeperToday I want to showcase a Wikidata proof of concept that I developed as part of my work integrating Siegfried and Wikidata.
That work is wikiprov a utility to augment Wikidata results in JSON with the Wikidata revision history.
For siegfried it means that we can showcase the source of the results being returned by an identification without having to go directly back to Wikidata, this might mean more exposure for individuals contributing to Wikidata. We also provide access to a standard permalink where records contributing to a format identification are fixed at their last edit. Because Wikidata is more mutable than a resource like PRONOM this gives us the best chance of understanding differences in results if we are comparing siegfried+Wikidata results side-by-side.
I am interested to hear your thoughts on the results of the work. Lets go into more detail below.
#Code #CreativeCommons #Data #digitalLiteracy #Golang #mediawiki #OpenData #OpenSource #provenance #reification #reify #siegfried #SPARQL #wikibase #wikidata
-
Also Qlever is pure magic and performance is ace.
Example federating across 3 sources: one of the #Wikibase instances from @tibosl + #Wikidata + #FactGrid - works like a charm in #Qlever, too:
https://qlever.cs.uni-freiburg.de/wikidata/BZEBw2*We do need to sort out the literals business, to minimize the bindings, but that's homework!
-
Gute Neuigkeiten zum Wochenende:
In zwei Wochen startet unsere beliebte online Vortragsreihe "From Books to Bytes" wieder.Den Auftakt macht am 25.10. Dr. Olaf Simons (Historisches Datenzentrum Sachsen-Anhalt, der Martin-Luther-Universität Halle-Wittenberg) mit seinem Vortrag über "FactGrid. Eine Wikibase-Instanz für historische Daten".
Weitere Infos zum Vortrag: https://4memory.de/task-areas/task-area-4-data-literacy/veranstaltungsreihe-from-books-to-bytes/
🗓️ Fr. 25.10., 10-11:30 Uhr
-
Stellenausschreibung: Softwareentwickler/in bei der Germania Sacra in Göttingen, mehr Infos hier:
https://adw-goe.de/germania-sacra/news/news-details/stellenausschreibung-fuer-eine-vollzeitstelle-im-bereich-webentwicklung-digital-humanities/ #factgrid #wikibase #digitalhistory #antlr #RepertoriumGermanicum #DigitalHumanities -
vormerken:
12.–14. Januar 2024
Berlin, Technische Universität, WikiBär & WMDE GeschäftsstelleInternationales Symposium zu Wikiversum + Provenienzforschung
Call zur Beteiligung folgt in Kürze
Reisestipendien können beantragt werden
#wikiverse #wikidata #wikibase #wikimediacommons #wikipedia -
Título completo: A wiki PROFMUS: a utilização da #wikibase e da @wikidata para a gestão de uma base de conhecimento sobre a condição sócio profissional dos #músicos em #Portugal entre 1750 e 1986. #wikilovesmusicaportuguesa @acessoaberto 🎼🎶🎵🧶
-
Active #SPARQL Query Services across the #LODCloud, courtesy of a #Wikibase query:
[1] https://tinyurl.com/2h7dze9u -- Tables
[2] https://tinyurl.com/2h7dze9u -- Bubble ChartA SPARQL Query Service endpoint provides access to an #HTTP-based Query Language, Wire Protocol, and Negotiable Serialization Format combo that's fully understood by #ChatGPT.