Auf dem Metadaten-Barcamp kam am Rande die Diskussion auf, ob und warum Linked Open Data von Bibliotheken im DACH-Bereich etwas eingeschlafen ist. Für Normdaten wird es genutzt, aber was ist mit den schon vor Jahren bereitgestellten Titeldaten in RDF?
Kurz darauf wurde in einem SWIB-Vortrag das Portal Share-VDE vorgestellt, in dem nach Titeln, Werken, Personen und Organisationen gesucht werden kann. Technische Grundlage ist u.A. BIBFRAME und Linked Data Patterns. Auch anderswo (Schweden, Spanien…) setzen Bibliotheken RDF produktiv nicht nur für Normdaten ein. Aus dem deutschsprachigen Raum fallen mit aber keine bibliothekarischen Anwendungen ein. Ist das auch euer Eindruck und woran könnte es liegen?
Danke, dass du hier das Thema aufgemacht hast.
Ich habe schon verschiedene Vorträge zu Share-VDE gehört. Die British Library ist seit 2023 (wenn ich mich richtig erinnere) dabei und ab 2025 wohl auch die Norwegische NB.
Wenn ich die BIBFRAME Programme der letzten Jahre ansehe, dann ist da der DACH Raum eigentlich gar nicht vertreten Bsp: BIBFRAME Workshop in Europe und der Anteil an Linked Data Beiträgen aus DACH Bibliotheken bei der SWIB hat auch abgenommen.
Ist im DACH Raum einfach MARC jetzt der Standard, der gar nicht mehr in Frage gestellt wird?
Ich kenne mich mit BIBFRAME nicht wirklich gut aus, aber man könnte doch schon sehr viele Probleme der Datenhaltung, die uns tagtäglich begegnet dann leichter lösen? Wie zb inhaltserschließende Daten besser an alle relevanten Datensätze dranbekommen?
Und die Probleme der Datenhaltung sind ja nicht nur unschön, sondern führen am Ende immer zu mehr Arbeitseinsatz, als es eigentlich brauchen sollte.
Zumindest im hbz ist Linked Open (Usable) Data über die Jahre integraler Bestandteil der Daten- und Servicelandschaft geworden. lobid ist seit vielen Jahren im Produktionsbetrieb und es kommen regelmäßig – inner- und außerhalb des hbz – produktive Anwendungen dazu, die lobid integrieren. (Seit letztem Jahr greift z.B. die offizielle DigiBib-basierte hbz-Verbundkatalogsuche auf lobid-resources zu.) Auch haben wir letztes Jahr einigen Aufwand investiert, um im Hintergrund von Aleph auf Alma umzusteigen. Anwendungen, die auf lobid setzen, konnten beim Alma-Umstieg davon profitieren, weil der Dienst ohne Unterbrechung weiterlief und die Datenstruktur sich kaum änderte, so dass die Anwendungen einfach weiterliefen und nur kleinere Anpassungen vorgenommen werden mussten (Zum Umstieg von lobid-resources auf Alma-basierte Daten | lobid.org)
Da wir nun nicht mehr das spezielle MAB/MARC-Gemisch aus Aleph nach RDF/JSN-LD transformieren, sondern eine MARC-zu-lobid-Transformation haben, sollte diese auch mit Anpassungen von anderen Verbünden und Bibliotheken adaptiert werden können. Bei Interesse bitte hier melden.
Das lobid-Anwendungsprofil basiert zum Teil auch auf Bibframe (siehe Which vocabularies to use for bibliographic descriptions? | lobid.org), allerdings reden wir vom lobid-Team nicht mehr viel über RDF oder gar SPARQL, weil seit langem der Fokus auf der Bereitstellung wohl-strukturierter JSON-LD-Daten über eine Web-API liegt. Vielleicht wurde lobid deshalb noch nicht in diesem Thread erwähnt? Wir benutzen dafür gerne den von Rob Sanderson geprägten Begriff „Linked Open Usable Data“ (LOUD) und den Rückmeldungen der Nutzer:innen nach scheint das Konzept aufzugehen und lobid in der Tat sehr gut nutzbar und nützlich zu sein.
Flankierend dazu haben wir vor einiger Zeit – zunächst für die Rheinland-Pfälzische Bibliographie – begonnen, an Erfassungsumgebungen zu arbeiten, die bei der Produktion von LOUD unterstützen. Das Ganze basiert auf dem Headless CMS Strapi und integriert lobid sowie zusätzliche SKOS-Vokabulare für Lookups auf Titel- und Normdaten. Für die Personennormdaten der Rheinland Pfälzischen Personendatenbank ist das System schon seit einiger Zeit in Produktion. Für die Daten der Rheinland-Pfälzischen Landesbibliographie steht der Umstieg des Backends von Allegro auf Strapi kurz bevor. Wir werden das gerne mal im kommenden Jahr präsentieren, vielleicht beim KIM-Workshop?
Ja, tut mir leid, natürlich ist lobid da sehr aktiv.
Aber abseits von lobid, DNB und dem ORKG von der TIB gibt es da noch weitere Aktivitäten und Bestrebungen die Vorteile verlinkter Daten zu Nutzen? Oder Diskussionen darüber? Mein subjektives Gefühl ist, dass das in den Bibliotheken kaum noch Thema ist… Oder es gibt nicht so viele die öffentlich darüber sprechen… Ich weiß es nicht.
Die TU Dortmund ist auch am Ball geblieben, ping @moebius75. Per Websuche bin ich noch auf den Artikel „Linked Open Data. Zukunftsweisende Strategien“ (2023) von Georg Petz (ÖNB) in Bibliothek Forschung und Praxis gestoßen. Dort wird offenbar EDM für digitalisierte Sammlungen genutzt und für Katalogdaten wird auf die Bibframe-Schnittstellen in Alma verwiesen. (Soweit ich weiß, verwendet Ex Libris da einfach die MARC-zu-Bibframe-Tools der LoC, oder?)
Dreht es sich in diesem Thread nur um Titeldaten? Der Titel legt es nicht nahe, der erste Kommentar schon. Falls es prinzipiell um LOD geht, könnte man auch sagen, dass alle Bibliotheken, die in irgendeiner Form IIIF implementieren, LOD machen. Und das hat sich ja auch etabliert. Wikidata und/oder Wikivase spielt sicher auch an ein paar mehr Einrichtungen eine Rolle, da habe ich aber nicht so den Überblick.
Insgesamt würde ich sagen, dass von den Verbundzentralen, die am Anfang erste LOD-Implementierungen für Titeldaten umgesetzt haben und das Thema gemeinsam mit der DNB und ZBW vorangebracht haben, eher welche abgesprungen sind. Allerdings hat sich dagegen in anderen Bereichen LOD etabliert. Dass es sich bei zwei mittlerweile etablierten Diensten/APIs (IIIF, lobid) um Umsetzungen handelt, die sich als LOUD bezeichnen, ist vielleicht kein Zufall?
Danke, @awinkler, auch OCLC ist weiter am Thema „Linked Data“ dran, ich würde es allerdings nicht als „Open“ bezeichnen. Im Fediverse hatte ich die Ankündigung des OCLC-Positionspapiers im Juli wie folgt kommentiert:
[Es beschreibt die verfügbaren Tools, die Bibliotheken dabei unterstützen, ein vernetztes Informationsangebot für Nutzer:innen zu schaffen] insofern das proprietäre Tools von OCLC sind, mit denen sie exklusiv Geld verdienen können. Open-Source-Tools aus der Community werden nicht genannt – wie z.B. #Skosmos oder @skohub zur Publikation von kontrollierten Vokabularen als LOD oder @OpenRefine und #reconciliation API für die halbautomatische Verknüpfung von Daten, #annif für die halbautomatische Inhaltserschließung oder die @lobid -gnd-API für GND-Verlinkungen usw.
OCLC arbeitet also nur an der Entwicklung einer „gemeinsamen“ Linked-Data-Infrastruktur, solange sie selbst die zentrale Kontrolle darüber haben. Denn es muss sich ja Geld verdienen lassen, was ja der neue DDC-Dienst (DDC wieder als Linked Data verfügbar) zeigt, mit dem wir nun nicht mehr schöne DDC-Notations-basierte URIs, wie http://dewey.info/class/54/ haben, die sich leicht bilden und abfragen lassen, sondern stattdessen https://id.oclc.org/worldcat/ddc/E3d4fdtMbRXJbwXFWcJ3X6r7rP, wo man nur hinkommt, wenn man erstmal für einen Dienst bezahlt hat, der einen zur DDC-Notation „54“ die neue ID E3d4fdtMbRXJbwXFWcJ3X6r7rP ausspuckt.
Sie sind nicht daran interessiert, gemeinsam einen bibliothekarischen Linked-Open-Data-Graph im Web aufzubauen, und reden auch nicht über Open-Source-Tools und wirklich offene Ansätze, obwohl sie über die Aktivitäten – nicht zuletzt durch den zuletzt 2018 durchgeführten Linked Data Survey – bescheid wissen. Immerhin betreiben sie hier kein Open-Washing, weil sie selbst in den letzten Ankündigungen zum Thema nur von „Linked Data“ sprechen…
Da ich von @acka47 schon angepingt worden bin, möchte ich auch etwas beitragen
Ich bemühe mich tatsächlich schon seit Jahren, Konzepte des Linked Data in unsere Services zu integrieren. Auch würde ich unsere Daten gerne selber als Open Data zur Verfügung stellen. Das ist aber leichter gesagt als getan (Stichwort Henne-Ei und Ressourcenmanagement…)
Jedoch habe ich es geschafft, für die nächste Strategiephase der UB Dortmund an zwei Stellen Linked Data zu platzieren. Zum einen werden wir im Rahmen der Hochschulbibliographie endlich einen Knowledge Graph aufsetzen, der die Beziehungen besser sichtbar macht. Zum anderen werden wir unserem „Discovery Service“ einen Knowledge Graph zur Seite stellen, der die zahlreichen in Suchmaschinen bzw. Quelldaten versteckten Beziehungen sichtbarer macht. Stichworte sind hier FRBRisierung, Personennetze, Inhaltserschließung und „virtuelle“ Sammlungen. Zu den Sammlungen gehören auch die Findbücher unseres Uni-Archivs, womit auch eine Brücke in nichtbibliothekarische Welten gebaut wird.
Im Sinne von federated queries werden wir hierbei u.a. lobid-resources, die GND und CultureGraph verwenden, auch wenn wir dazu selber die benötigte Query-Infrastruktur aufbauen müssen.
Ich bin gespannt, was am Ende bei diesen Vorhaben herauskommt.
Auch ein wenig relevant in diesem Kontext: Zwei bibliothekarische Organisationen, die hier bereits erwähnt wurden, weil sie an/mit Linked Data arbeiten, haben in den letzten Jahren ihre W3C-Mitgliedschaft gekündigt: DNB und OCLC.
