Zeit und Ort:
6. Mai 2020, 10:00 – 12:15 Uhr, BigBlueButton UB Mannheim
TeilnehmerInnen (23):
Alan Riedel, Andreas Kempf (ZBW), Anna Bohn (ZLB), Brigitte Petermann, Hans-Georg Becker, Hans-Jürgen Becker (DNB), Harald Lordick, Heinz Kuper (digiS), Jan Kamlah, Jana Hentschke (ZBW), Joachim Neubert, Johannes Sperling (SLUB), Julian Schulz (LMU), Linus Kohl, Michael Menzel, Ralph Hafner, Renat Shigapov (UBM, BERD@BW), Sarah Hartmann (DNB), Sonja, Sonja Kümmet, Steph, Johannes Hercher (FU Berlin), timotheus kim
Austauschthemen
Installation
u.a. Hürden, Support von Wikimedia, Docker Image vs. klassische Installation
Einführung in Fragestellung: Hans-Jürgen Becker (DNB)
Demo Dockerinstallation Hans-Jürgen Becker
Gibt es Perfomanceerfahrungen mit den Wikibase-Docker-Instanzen bzw. mit Kubernetes?
Wie zufrieden mit der Docker-Installation?
- DNB: Docker-Installation läuft im Prinzip, aber etwas hakelig beim Einrichten
- UBMann: Gut mit ähnlichen Erfahrungen bezüglich YAML ( keine Erfahrungen mit QS-Service)
- digiS: öfter probleme mit wdqs.svc (scheint irgendein Netzwerkproblem bzw. Einstellung zu sein. Noch keine Lösung gefunden.)
- SLUB: Docker insgesamt deutliche Erleichterung. Aber: Abhängigkeit von den Entwicklern.
- DNB koppelt das bereits rück an Wikimedia Deutschland
Hat jemand Erfahrungen mit dem Update des Docker-Image auf neue Versionen?
- teilweise komplette Neuinstallation (mit Datenverlust/Neu-Import) nötig
- Beim Update von 1.32 auf 1.34 gab es Probleme mit dem WikidataIntegrator (hier musste ein paar händische Änderungen in den LocalSettingsfiles vorgenommen werden)
Erfahrungen Klassische Installation (vs. Docker)
- Harald Lordick: 'Klassische' Installation hakelig, mit Updates noch keine Erfahrung.
Wie verlief die Kommunikation mit den Entwicklern?
- SLUB: Kommunikationsweg mit den Entwicklern hauptsächlich über den Telegram Channel, unterstützt durch Phabricator Tickets sowie persönliche Gespräche bei Wikimedia in Berlin
- DNB: Wikibereich für Austausch mit Wikimedia (nicht direkt in Phabricator Tickets erstellen) (allerdings von beiden Seiten mittlerweile als "sperrig" empfunden), IRC, z. T. auch Webkonferenz mit Entwickler --> zukünftiger Support von WMDE?
- SLUB: Bedarf / Anforderungen von verschiedenen Anwendern sammeln / bündeln und Erfahrungen weiter austauschen
- ZBW: Guter Kontakt beim Workshop letztes Jahr
Datenimport
Wie bekommt man Daten rein. Datenflüsse aus anderen Systemen? Welche Schnittstellen? (SPARQL, Mediawiki-API)
Einführung in Fragestellung: Hans-Jürgen Becker
- DNB: für GND Import entscheidend
- Voraussetzung: properties definieren
- i. d. T. mehrstufiger Importprozess um vorhandene Verlinkungen abzubilden: QID generieren und weitere statements hinzufügen
- Importe
- 5 TN haben bereits Import in WB-Instanz
- Performance?
- SLUB: einiges 10.000 items via QS und WBcli --> hat pro Importstufe jeweils einige Stunden gedauert
- grundsätzlich qs etc. einfach zu "erlernen"
- SLUB, DNB: qs im docker hat noch ein paar bugs (z. B. strings)
- DNB: bisher nicht wikibase-cli getestet, aber wikidata integrator (performanter als qs)
- UB Mannheim: nutzt wikidata integrator
- Frage UB Mannheim: parallelisierung?
- DNB: noch nicht getestet
- SLUB: lt. adam (WMDE) sollte es möglich sein eine instanz parallel zu "befüllen"
- UB Mannheim: Ich nutze Multiprocessing-library in Python mit Wikidataintegrator.
- Kenngrößen Performance
- @DNB 6,4 Items/s (ca. 10 Properties/Item) (mit WDI und Multiprocessing-Library )
- @UBMannheim: 10 Items/s (mit WDI)
- @SLUB: mit QS 1-3 Items/s
- Frage: abhängig von Anzahl der Statements?
- DNB Idee: DB direkt befüllen? aber WMDE davon abgeraten!
- ZBW: wikidata-Quickstatements Generierung aus SPARQL (federated SPARQL queries, die Statementstrings mit QIDs, PIDs etc. generieren) -> Beispiel-Link (Pressemappe 20. Jh.: Verknüpfung von WD-Items über GND-ID): https://www.wikidata.org/wiki/Wikidata:WikiProject_20th_Century_Press_Archives/Tools_%26_tasks#Add_PM20_ID_via_GND_ID_(%22pm20_via_gnd%22) (Query und Script zur Transformation verlinkt)
- UB Tübingen: Bisherige Erfahrung:Import Entities aus Wikidata via csv und Datenimport via Quickstatements klappt bisher ganz gut.
- noch nicht erfüllter Bedarf: OpenRefine für Wikibase als Teil des Docker-Image
Oberflächenanpassungen
Wie lassen sich sowohl Präsentationsoberfläche und Daten-Erfassungselemente anpassen, um z.B. einen niedrigschwelligeren Zugang für Nutzende zu bieten und/oder Besonderheiten des jeweiligen Projekts abzubilden?
Einführung in Fragestellung: Johannes Sperling
Motivation
- Offenheit durch Visualisierung / Nutzbarkeit
- -> leider komplex – Hürde für "normale Forscher" und breite Öffentlichkeit
- -> soll zugänglicher werden
Bestandsaufnahme
Zwei Aspekte:
- Dateneingabe über einfache Eingabe-Formulare und
- Datenabfrage über einfache Such-Formulare
- SLUB: pilotmäßig eine einfache Suchabfrage-Website programmiert -> Vision, dies individuell anpassbar in das Docker-Image zu integrieren (idealerweise als Teil von Quickstatements) so dass Projekte ohne Programmierkenntnisse
- DNB: wünschen wir uns auch, v.a. Eingabeformulare -> Aussage WMDE/ Wikibase-Entwickler: wäre komplette Neuentwicklung und ziemlicher Entwicklungsaufwand
- Cradle von Wikidata -> zur Neuanlage
- Idee: gemeinsames Projekt / Entwicklung initiieren, um z. B. Erfassungsmasken / Eingabeformulare zu generieren (z.B. auch Entwicklungsimpulse durch Hackathons, Abschlussarbeiten)
Datenerfassung ("händisch": einfach)
- für Wikidata vorhanden
- gibt es WB-spezifische Tools zur Eingabe?
- -> Open Refine-Schnittstelle wichtig!
- lt WMDE aktuell nicht vorhanden wäre Neuentwicklung
Präsentation / Abfrage
- wdqs – noch immer zu komplex
- Beispiel Sächsische Reiseberichte Suchabfrage (noch nicht online)
- wünschenswert: Möglichkeit eigene Suchmasken konstruieren - ohne Programmierkenntnisse und out-of-the-box
- UB Mannheim: Flask / Python, das auf SPARQL-Queries aufsetzt und Ergebnispräsentation in Tabellen / csv. etc.
- @UB Mannheim: Link auf Frontend einfügen (<- in den nächsten Monaten)
Federation/Verlinkungen
Wie kann man Wikidata als Linking-Hub einsetzen und die darin gehaltenen Daten zu anderen Datenbeständen verlinken?
Anwendungsfall 1 (GND)
Nicht in ein und derselben Wikibase-Instanz items und properties anlegen sondern verlinken auf andere, z.B. Wikidata. Wenn in der BnF-Wikibase-Instanz eine Entität existiert, soll die GND-Wikibase-Instanz die nicht dublizieren sondern darauf verlinken und evtl. ergänzen.
Anwendungsfall 2 (UB Mannheim)
Firmen repräsentieren, mit Fokus auf domänenspezifische properties unddiese in der eigenen Instanz abbilden und ggf. auf weitere properties in anderen Instanzen (z. B. Motto) referenzieren
Lösungsmöglichkeiten
Idee: 2 Instanzen: 1x öffentlich, 1x interne Daten
Nutzerspezifische Anzeige / Editierbar (z. B. aus rechtlichen Gründen notwendig)
wie bisher in Wikibase-Instanzen umgesetzt?
- bisher entweder nur Verlinkung auf die entsprechenden Items auf Wikidata
- oder Import aus Wikidata
- Bisherige Erfahrung:Import Entities aus Wikidata via csv und Datenimport via Quickstatements klappt bisher ganz gut.
Federation: bessere Kommunikation und ggf. Weiterentwicklung von WMDE
- inzwischen höheres Bewusstsein seitens WMDE dafür
- aber noch viele offene Fragen
Unterscheiden zwischen
- federated queries / Query Federation
- geht in Wikidata, nicht in Wikibase
- WD: bei externen Federatoren müssen diese vorher angelegt werden
- Nachnutzung von Items/Properties aus WD/anderen WB in der eigenen WB:
- das ist noch komplett offene Frage
- bisher i.d.R. nur Verlinkung über die QIDs (und die muss spezifisch für jede WB-Instanz sein "Namensraum")
- --> z.B. Buchstabe der für lokale Spaces reserviert ist oder Namespaces unterscheiden
- Federated Edits
- Anforderung an Wikidata (ganz unabhängig von Wikibase): Wikipedia-Nutzer sollen in die Lage versetzt werden Änderungen an Items vorzunehmen (z.B. in Infokästen auf Wikipedia-Seiten)
Benutzerrechte
(Wie) Werden Rechte und Rollen umgesetzt?
Einführung in Fragestellung: Sarah Hartmann (DNB)
Frage: Wer hat Erfahrungen mit Benutzerrechten / roles gemacht? Wikidata roles nachgenutzt?
- SLUB: bisher nicht relevant
- UB Mannheim: noch nicht relevant, Frage wie geht man mit Daten um die nicht für die Öffentlichkeit bestimmt sind. Geht primär um Anzeige nicht um Editierbarkeit
- ZBW: keine Anforderungen, da Wikibase derzeit nur als Wegwerfinstanz vorgesehen, um Datenmodellierung und Importprozeduren für Wikidata in größerem Massstab zu testen
- lokale Daten (z. B. lokale Sacherschließung) zur Verfügung stellen / importieren
- Eingabe erleichtern als in der WINIBW
- Import / Vorschlag für die GND
Allgemeine Diskussion
- Fazit DNB-Erfahrungen: WB vielversprechend, Modellierungsmöglichkeiten sehr gut, aber vor allem bezüglich niedrigschwelliger Erfassungsformulare Bedarf, der Entwicklungskapazitäten erfordert
- Hoffnung von GND-Anwendern, dass die Eingabe niedrigschwelliger wird als über WinIBW und dadurch die Infos noch aktueller werden
Wie geht es weiter?
regelmäßiger Austausch in dieser Runde wird als sinnvoll erachtet. Auch als gemeinsames "Gremium", um Einfluss auf die weitere Entwicklung zu nehmen.
Soll weitergemacht werden?
SLUB: +1
DNB: +1
digiS: +1
UB Mannheim: +1
STI: +1
Bedarf / Anforderungen von verschiedenen Anwendern sammeln / bündeln um ggf. auch Entwicklungen anzustoßen!
Organisationsform
Idee: LinkedLibraryData Gruppe (Mailingliste, Wiki vorh.) nachnutzen oder eigene Gruppe?
Umfrage Ergebnis: 67 % für eigene Mailingliste für Erfahrungsaustausch
Frequenz: virtuelle Treffen (Umfrage 73% alle 3 Monate) und kann ja auch spontan zusätzlich notwendige Telkos zu Schwerpunktthemen umfassen?
zukünftig Ergebnissicherung gemeinsam im etherpad / hackMD und für langfristige Sicherung copy ins KIM-Wiki
Idee Chatchannel nutzen für Austausch:
- Telegram 2
- Slack 4
- Gitter 1
- no chat 3
ToDos
- Alle: über die Mailingliste organisieren, ob Slack aufgesetzt werden kann
- Alan Riedel: Termine für Erfahrungsaustausch fixen (Umfang 90 Min)
- Alle: bei Sarah Hartmann melden wegen Bearbeitungsrechten für das KIM-Wiki bei der DNB
- Jan Kamlah: Klärung ob BBB als Kanal bestehen bleibt und für Austausch weiterhin genutzt werden kann
- Jana Hentschke: richtet Wikibereich + Mailingliste für "Erfahrungsaustausch Wikibase" ein und informiert KIM-LLD-Gruppe über die neue Aktivität