Hallo,
nach dem ich heute morgen beim Dini-KIM-Workshop begeistert vom SPARQL-Endpoint der dblp erfahren habe, habe ich mich mal wieder gefragt, warum es so wenige SPARQL-Endpoints der großen Datenplattformen im Bibliothekswesen (z.B. DNB, CultureGraph) gibt.
JSON-APIs reichen eben nicht aus, wenn man die Daten als Knowledge Graph, z.B. mittels Federated SPARQL-Queries, anwenden möchte. Und es kann ja nicht sein, dass man die Daten dann immer lokal in einen Triple Store werfen muss.
Wie steht lobid eigentlich dazu?
Viele Grüße
Hi Hans-Georg,
erstmal herzlich willkommen im metadaten.community-Forum!
Triple-Store: ja, hatten wir ja früher mal. Das Problem damals, und mutmaßlich auch heute, war die Performanz. Vor allem eine Datenaktualisierung hat unsinning lange gedauert. Du kannst dir vorstellen, dass ja u.a. erst alle bnodes gefunden und dann gelöscht werden müssen - ich stell mir eine Analogie zum Filesystem vor, wo es einfacher (=schneller) ist z.B. 1k Dateien a 10MB Größe zu löschen als 10M Dateien a 1kB. Möglicherweise haben sich die Triple-Stores aber auch wesentlich verbessert. Oder wir könnten, wie früher auch, lediglich einmal pro Woche einen Volldump einspielen.
Auf der anderen Seite - bei unserem mittlerweilen sehr elaborierten Datenmodell, wie groß ist überhaupt der lobid-resources (aka hbz-Verbund) Dump? Es sind 26M Dokumente. Die Rohdaten (XML mit bzip2) sind 15GB. Im JSON-LD wird einiges angereichert, das ist evtl. doppelt so groß (wir speichern den nicht zwischen sondern streamen direkt in den Index) … der Elasticsearch Index ist 150GB groß. Und dann ist die Frage, wer das tatsächlich braucht, und dann, wie die Performanz des Triple-Stores bei Queries über die API wäre …
Bleibt die Frage, ob die Interessierten nicht besser über die lobid-API den Teilaussschnitt holen, der von Interesse ist … ok ich sehe schon, wenn die Dokumente, die in eurem Bestand sind, auf Dokumente verweisen sollten, die nicht in eurem Bestand sind, dann wäre da euer Graph unterbrochen …
Könnten wir evtl. die jetzige API verbessern statt Ressourcen in eine Art „Parallel-API“ (mit ihren Nachteilen s.o.) zu stecken?
(das sind nur meine 2Cents, das ist also kein Nein. Evtl. wäre der Ansatz von Linked-Data-Fragments oder Triple-Fragment-Patterns interessant, Issue gibt es seit 2015 Add support for querying linked data fragments · Issue #181 · hbz/lobid · GitHub ?)
Interessant ist vielleicht der SPARQL Endpoint Status Service von OpenLink
Im Tab „Availability“ sieht man sehr viele graue („tote“) Endpoints, einer der wenigen grünen Endpoints ist data.bnf.fr von der Französischen Nationalbibliothek mit 615638230 Triples!
Ich meine mich zu erinnern, dass es schwierig ist, Queries zu verhindern, die einen Endpoint in die Knie zwingen können.
+1 Das wäre ein guter Kompromiss, der SPARQL-Queries ermöglichen aber dabei Last an den Client abgeben würd. Die Frage ist, ob eine Linked Data Fragments-Schnittstelle deinen Anwendungsfall abdecken würde, @moebius75?
Grundsätzlich kann ich die technischen Hürden „Import-Performanz“ und „problematische Queries“ aus meiner Praxis sehr gut nachvollziehen 
Allerdings stellt sich dann die Frage, warum es keine Weiterentwicklung dazu gibt. Und was macht z.B. die Französische Nationalbibliothek anders?
Das könnte durchaus ausreichend sein. Einen Versuch wäre es wert.
Von mir noch ein kleiner Hinweis. Es muss nicht immer gleich ein Triple Store sein, um eine SPARQL Schnittstelle anzubieten. Eine SPARQL Engine tuts auch.
Bspw. die Leute von der Uni Freiburg arbeiten an Qlever.
Die Daten der DNB (titel + gnd) wurden erst kürzlich aktualisiert
https://qlever.cs.uni-freiburg.de/dnb
Die gesamte GND als RDF mit Qlever zu indexieren hat auf einer unserer Maschinen mit 64GB RAM nur 15 Minuten gedauert. Wikidata nur 15 Stunden
Nachteil ist aktuell, dass noch kein SPARQL Update implementiert ist.
5 „Gefällt mir“
Danke für den Hinweis, Tracy! Das klingt sehr spannend.
Und was macht z.B. die Französische Nationalbibliothek anders?
Die haben „nur“ 616M Triple. lobid-resources hat 26M Dokumente * (arbiträr herausgepickt) 150 Triple = ~ 4G Triples. Das ist ein Faktor von 6. Die Triple Stores werden wohl auch nicht linear skalieren. Was also bei der bnf mit z.B. 12 GB RAM geht, das ginge bei uns nicht mit 84 GB.
Wir brauchen also eine Reduktion in der Komplexität…
… oder bessere Stores/Engines (meine Erfahrungen mit Triple Stores sind > 10 Jahe alt):
Qlever „… is a SPARQL engine that can efficiently index and query very large knowledge graphs with over 100 billion triples on a single standard PC or server.“ (danke für den Hinweis @Tracy_Arndt).
Wäre ein Versuch wert.