lobid stellt Rechercheoberflächen und offene Programmierschnittstellen (APIs) zur Verfügung, die auf Linked Open Data (LOD) basieren. lobid wird vom Hochschulbibliothekszentrum des Landes NRW betrieben. lobid-resources bietet Zugriff auf den hbz-Verbundkatalog. lobid-organisations bietet Informationen zu Gedächtnisinstitutionen im deutschsprachigen Raum. lobid-gnd bietet Zugriff auf die Gemeinsame Normdatei (GND).
Die Lobid-API bietet einheitlichen Zugriff auf bibliothekarische Daten über eine Web-basierte Programmierschnittstelle (application programming interface, API). Sie liefert JSON für Linked Data (JSON-LD):
Die Grundidee ist dabei eine Entkopplung von Anwendungen, die diese Daten verwenden, von spezifischen Datenquellen, Formaten und Systemen. So können sich diese Formate und Systeme ändern, ohne dass Änderungen in den Anwendungen nötig werden, die auf die Daten über die API zugreifen. Dies ermöglicht die Entwicklung von herstellerunabhängigen, nachhaltigen Anwendungen auf Basis bibliothekarischer Daten. Siehe auch: Warum Bibliotheken APIs brauchen (englisch).
Die hier beschriebenen lobid-Dienste bilden die zweite Version der im Jahr 2013 veröffentlichten lobid-APIs, die wir auf Basis der Erfahrungen mit diesem ersten System entwickelt haben. Details und Motivation für diese Entwicklung haben wir auf GitHub dokumentiert.
Das lobid 1.x-System basierte auf einer klassischen monolithischen Schichtenarchitektur: wir hatten ein Git-Repository, das die Implementierung für das Backend enthielt, mit der Logik aller Datentransformationen und der Indexschicht für alle Daten. Ein weiteres Git-Repository implementierte die APIs und ein gemeinsames Frontend für alle Datensets, die so alle innerhalb eines Prozesses ausgeliefert wurden.
Dies führte insgesamt zu einer Verquickung der verschiedenen Datensets: um etwa auf eine neuere Version unserer Suchmaschine (Elasticsearch) umzustellen, die Features bereistellt, die wir für eines der Datensets brauchten, mussten alle Datensets umgestellt werden, da die Applikation, die ja in einem einzigen Prozess lief, nicht von verschiedenen Elasticsearch-Versionen abhängen kann. Ebenso kam es zu inhaltlich eigentlich unnötigen Anhängigkeitskonflikten zwischen Software-Bibliotheken, die jeweils nur von den APIs unterschiedlicher Datensets benötigt wurden.
Daher haben wir für die 2.0-Version lobid in vertikale, in sich abgeschlossene Systeme für jedes Datenset (resources, oreganisations, gnd) aufgespalten:
Durch die Kombination dieser Module in der Horizontalen haben wir nach wie vor eine gemeinsame API und eine gemeinsame Oberfläche für alle Dienste, doch Teile dieser API und Oberfläche sind in Module gekapselt, die je ein Datenset behandeln. Diese Module enthalt den für das jeweilige Datenset spezifischen Code und die spezifischen Abhängigkeiten und können unabhängig analysiert, verändert und installiert werden.
JSON-LD ist eine W3C-Empfehlung für eine JSON-basierte Linked-Data-Serialisierung. Man kann JSON-LD aus zwei Perspektiven betrachten: einerseits als RDF-Serialisierung (wie N-Triples, Turtle oder RDF/XML), andererseits als eine Möglichkeit, JSON zum Verlinken von Daten zu verwenden. Diese doppelte Perspektive spiegelt sich auch in der JSON-LD-Spezifikation wider, die beschreibt dass JSON-LD "als RDF verwendet werden kann", und dass es "direkt als JSON verwendet werden kann, ohne Kenntnis von RDF" (Übersetzung von uns). Reguläres JSON wird durch das Beifügen eines Kontexts als RDF serialisierbar.
In der ersten Version der lobid-APIs haben wird im Zuge unserer Datentransformation N-Triples erzeugt und diese automatisch mit einem JSON-LD-Prozessor konvertiert. Hier haben wir JSON-LD vollständig als RDF-Serialisierung betrachtet:
Im resultierenden JSON-LD hatten wir so die URIs aus den Triples als JSON-Schlüsselwörter. Diese Daten haben wir als expandiertes JSON-LD in Elasticsearch indexiert. Elasticsearch erfordert konsistente Daten für ein gegebenes Feld, z.B. muss etwa der Wert von alternateName immer ein String sein, oder immer ein Array. Wenn die Werte mal ein String, mal ein Array sind, führ dies bei der Indexierung in Elasticsearch zu einem Fehler. In der kompakten JSON-LD Serialisierung werden einzelne Werte jedoch direkt serialisiert (z.B. als String), wenn jedoch in einem anderen Dokumente für das gleiche Feld mehrere Werte angegeben sind, wird ein Array verwendet. Expandiertes JSON-LD verwendet hingegen immer Arrays. Eine JSON-LD-Form, bei der kompakte Keys (Schlüsselwörter) mit expandierten Werten kombiniert sind gibt es in der Form nicht (siehe json-ld/json-ld.org#338).
Beim Ausliefern der Daten über die API haben wir die Daten dann in kompaktes JSON-LD konvertiert, um anstelle der URIs kurze, benutzerfreundliche JSON-Keys zu bekommen. D.h. wir haben im Grunde zwei verschiedene Formate erzeugt und verwendet: das interne Indexformat und das extern sichtbare API-Format.
Bei lobid-organisations, dem ersten Datenset, das wir auf den neuen Ansatz umgezogen haben, haben wir das Vorgehen umgedreht – statt manuell N-Triples anzufertigen, und diese automatisch in JSON-LD zu konvertieren, erzeugen wir das JSON mit genau der Struktur, die wir brauchen. Auf dieser Grundlage generieren wir dann RDF-Serialisierungen wie N-Triples:
Der zentrale Vorteil dieses Ansatzes ist, dass wir unseren konkreten Anwendungsfall nach vorne stellen: wir bauen explizit unsere API, so wie sie für unsere Anwendungen Sinn macht, anstatt zuerst eine Abstraktion zu erzeugen, aus der wir dann konkrete Darstellungen generieren, die von unseren Anwendungen verwendet werden.
Im Vergleich zum Ansatz im ersten lobid-System befinden wir uns hier am anderen Ende des Spektrums der Perspektiven auf JSON-LD, die wir oben beschrieben haben: wir behandeln hier JSON-LD als JSON, ohne bei der Produktion der Daten, oder bei ihrer Verwendung, Kenntisse von RDF zu erfordern.
In der neuen Version von lobid-resources haben wir einen Mittelweg genommen. Wir haben uns entschlossen, auf die bestehende Transformation der Katalogdaten in N-Triples aufzubauen. Wir verwenden dann Code, der von Jan Schnasse im Etikett-Projekt entwickelt wurde, um maßgeschneidertes JSON-LD aus den N-Triples zu erzeugen. Wie in lobid-organisations (und im Gegensatz zur ersten Version von lobid-resources), ist das maßgeschneiderte JSON-LD zugleich das Index- wie auch das von der API gelieferte Format.
Beide Ansätze erzeugen also maßgeschneidertes JSON-LD, sei es auf spezifische Weise aus N-Triples generiert, oder manuell erzeugtes JSON. Dieses maßgeschneiderte JSON-LD hat mehrere Vorteile.
Ein zentraler Aspekt der neuen Systeme ist, dass wir nun das gleiche Format liefern, das auch im Index gespeichert ist. Dies ermöglicht beliebige Abfragen der Daten über generische Mechanismen, ohne dass wir spezifische Anfragen implementieren müssen. Betrachten wir etwa einen bestimmten Datensatz, z.B. http://lobid.org/organisations/DE-605?format=json, so sehen wir folgendes:
"classification" : {
"id" : "http://purl.org/lobid/libtype#n96",
"type" : "Concept",
"label" : {
"de" : "Verbundsystem/ -kataloge",
"en" : "Union Catalogue"
}
}
Auf Basis der Daten, die wir hier sehen, können wir ein beliebiges Feld nehmen, z.B. classification.label.en (die Punkte bilden die Schachtelung der Felder ab) und eine Abfrage wie http://lobid.org/organisations/search?q=classification.label.en:Union formulieren. Im alten System, bei dem im Index expandiertes JSON-LD gespeichert war, die API aber kompaktes JSON-LD lieferte, brauchten wir spezifische Query-Parameter um Feldsuchen in praxistauglicher Art (ohne URIs als Feldnamen) umzusetzen, etwa für Titel, Autoren oder Schlagwörter, z.B.:
http://lobid.org/resource?name=Ehrenfeld
Diese können nun stattdessen über einen generischen q-Parameter und die tatsächlichen Feldnamen aus den Daten formuliert werden:
http://lobid.org/resources/search?q=title:Ehrenfeld
So vermeiden wir eine Beschränkung auf die von uns antizipierten Arten von Abfragen, und öffnen stattdessen den API-Zugriff auf die kompletten Daten.
Das generierte JSON-LD des alten Systems war eine flache Struktur mit JSON-Objekten in einem Array unter dem @graph-Schlüsselwort, z.B. in http://lobid.org/organisation?id=DE-605&format=full:
"@graph": [
{
"@id": "http://purl.org/lobid/fundertype#n02",
"prefLabel": [{
"@language": "de",
"@value": "Land"
},{
"@language": "en",
"@value": "Federal State"
}]
},{
"@id": "http://purl.org/lobid/stocksize#n11",
"prefLabel": [{
"@language": "en",
"@value": "Institution without a collection"
},{
"@language": "de",
"@value": "Einrichtung ohne Bestand"
}]
}
]
Diese Struktur war nicht sehr praktisch und entsprach nicht dem pragmatischen Geist von JSON-LD. Wenn man etwa die englische Bezeichnung des Unterhaltsträgers einer Einrichtung verwenden will, muss man hier über alle @graph-Objekte iterieren und jeweils prüfen, ob die @id die Unterhaltsträger-ID ist, dann über alle prefLabel-Objekte iterieren und jenes mit dem passenden @language-Feld suchen, das dann als @value den gesuchten Wert enthält.
In den neuen Systemen bieten wir die Daten in einem strukturierteren, JSON-typischem Format an:
"fundertype": {
"id": "http://purl.org/lobid/fundertype#n02",
"type": "Concept",
"label": {
"de": "Land",
"en": "Federal State"
}
},
"collects": {
"type": "Collection",
"extent": {
"id": "http://purl.org/lobid/stocksize#n11",
"type": "Concept",
"label": {
"de": "Einrichtung ohne Bestand",
"en": "Institution without holdings"
}
}
}
Dies ermöglicht Entwicklern und Entwicklerinnen, die mit JSON vertraut sind, einen einfachen Zugriff auf die Daten. Das gesuchte Datum aus dem obigen Beispiel etwa ist per Direktzugriff auf das geschachtelte Feld fundertype.label.en verfügbar.
Ein weiteres Beispiel für die semantische Anreicherung der JSON-Daten durch eine angepasste Struktur und die sich daraus ergebenden Auswirkungen auf die API-Nutzung sind Mitwirkende und ihre Rollen in lobid-resources.
Ein typisches Nutzungsszenario bei der Verwendung der Lobid-APIs ist die Anzeige von Labels für die URIs, die zur Identifikation von Ressourcen, Autoren, Schlagwörtern etc. verwendet werden. Für Anwendungen, die auf dem alten System basierten haben wir das Nachschlagen dieser Labels in unterschiedlichen Formen implementiert. Um diesen Anwendungsfall zu vereinfachen, liefern die neuen APIs die Labels mit den IDs zusammen aus, soweit dies möglich und sinnvoll ist. In den alten Daten hatten wir etwa zu Identifikation des Mediums einer Publikation nur eine URI:
"medium" : "http://rdvocab.info/termList/RDAproductionMethod/1010"
Um nun ein Label für eine solche URI anzuzeigen, mussten wir in den Client-Anwendungen, die die Lobid-APIs nutzten, Zuordnungen etwa in Form von Mapping-Tabellen verwalten. In den neuen APIs liefern wir die Labels mit den IDs zusammen aus (aus Konsistenzgründen wird auch hier ein einzelner Wert als Array geliefert, s.o.):
"medium": [{
"id": "http://rdaregistry.info/termList/RDAproductionMethod/1010",
"label": "Print"
}]
Wie die Erstellung des JSON-LD allgemein, unterscheidet sich auch die Implementierung dieser Labels zwischen der oben beschriebenen JSON-first und der Triples-first Umsetzung. In lobid-organisations ist die Ergänzung der Labels (wie alle Aspekte der JSON-Erzeugung) Teil der Datentransformation. In lobid-resources wird eine labels.json Datei während der Konvertierung von N-Triples in JSON-LD verwendet. lobid-gnd schließlich verwendet ein Bootstrapping-Ansatz, bei dem die vorige Version des Dienstes als Quelle für die Labels verwendet wird. Details zur Datentrasformation in lobid-gnd finden sich weiter unten.
Eine zentrale Schlussfolgerung unserer Erfahrung mit JSON-LD ist, dass JSON-LD sehr unterschiedlich erzeugt und verwendet werden kann. Wie es erzeugt wird hat dabei große Auswirkungen darauf, wie es verarbeitet werden kann und wie nützlich es Entwicklern und Entwicklerinnen mit unterschiedlichem fachlichen Hintergrund erscheint. Eine reine RDF-Serialisierung wie in unserem alten System kann etwa perfekt passen, wenn sowieso mit einem RDF-Modell gearbeitet wird, während sie Web-Entwicklern und Entwicklerinnen, die mit JSON vertraut sind, als absurd und schwer verwendbar erscheinen wird. Diese Unterschiede in dem, wie JSON-LD tatsächlich aussieht, können eine Herausforderung für die Kommunikation über die Nützlichkeit von JSON-LD sein. Zugleich ist dies aber auch eine Stärke von JSON-LD, das mit seiner Doppelnatur – als RDF-Serialisierung und als einfacher Weg, JSON-Daten zu vernetzen – unterschiedliche Nutzungsszenarien abdecken kann.
Über die hier skizzierten APIs und Datenstrukturen hinaus bietet Lobid in der neuen Version (im Gegensatz zur rudimentären Darstellung der alten Dienste) Suchoberflächen mit erweiterten Funktionen wie facettierter Suche und Kartenvisualisierungen. Eine Ausführliche Darstellung der Funktionalitäten am Beispiel von lobid-gnd findet sich weiter unten.
Ein zentraler Aspekt jeder Linked-Data-Anwendung sind ihre Vokabulare. In lobid-organisations verwenden wir schema.org als Basisvokabular. lobid-resources basiert auf DC Terms, Bibframe und anderen, wobei wir auch hier für die Modellierung der Publikationsdaten schema.org einsetzen, z.B. hier. Grundlage der Daten in lobid-gnd ist die GND-Ontologie.
Wir entwickeln die Lobid-Dienste als Open-Source-Software auf GitHub. Wir veröffentlichen nicht nur Ergebnisse auf GitHub, sondern der gesamte Prozess findet dort statt, d.h. die Planung, Issue-Tracking, Diskussion, Implementierung und Testen der Software. GitHub hat einen integrierten Issue-Tracker, dessen primäres Organisationsmittel beliebige Labels mit Farben sind. Diese lassen sich vielseitig anwenden (s.u.). Dieser Issue-Tracker ist in andere Aspekte von GitHub integriert, so lassen sich auf einfache Weise Links zu Code, Commits und Benutzern erstellen.
GitHub-Issues sind immer mit einem GitHub-Repo assoziiert. Für einen einheitlichen Blick auf alle vom Team bearbeiteten Issues in allen Repos verwenden wir zur Visualisierung des Workflows Waffle, ein Kanban-Board mit GitHub-Integration, bei dem jedes GitHub-Issue einer Karte entspricht, und die Spalten des Boards Labels der GitHub-Issues entsprechen.
In unserem Prozess durchläuft eine Karte das Board von links nach rechts. Priorisierte Karten schieben wir nach oben in der Spalte, Karten die Fehler (Bugs) beschreiben werden generell priorisiert.
| Backlog | Ready | Working | Review | Deploy | Done |
|---|---|---|---|---|---|
| Neue Issues ohne Label | Bereit, d.h. Anforderungen und Abhängigkeiten sind klar | In Bearbeitung | In Überprüfung | Bereit für Produktion | In Produktion |
Ein Kernelement unseres Entwicklungsprozesses, durch das bibliothekarische Anforderungen und Entwicklung miteinander verzahnt werden, sind die Begutachtungen bzw. Reviews. Hier unterscheiden wir zwischen funktionalem Review und Code Review.
Zur Einleitung des funktionalen Reviews stellt einer unserer Entwickler neue oder reparierte Funktionalität auf dem Staging-System bereit, beschreibt im korrespondierenden Issue, wie getestet werden kann (z.B. durch Angabe von Links auf die betreffenden Seiten im Staging-System) und weist das Issue einem Team-Mitglied zur Begutachtung zu. Dieses testet, gibt Feedback (bei Bedarf aktualisiert der Entwickler den Pull-Request und die Version auf Staging mehrfach), und schließt die Begutachtung mit einem "+1" Kommentar ab.
Nach Abschluss des Functional Reviews weist der Begutachter den zum Issue gehörigen Pull-Request einem anderen Entwickler zur Begutachtung zu (Code Review). Dieser inspiziert je nach Fall nur den Diff im Pull-Request oder testet den Branch lokal. Die Ausführung des Builds und der Tests erfolgt automatisch im Pull-Request durch Travis CI, ein in GitHub integrierter Continuous-Integration-Dienst. Auch hier wird die Begutachtung mit einem "+1" Kommentar abgeschlossen, der Begutachter weist das Issue wieder dem Entwickler zu, und verschiebt es in 'Deploy'.
Nach Abschluss beider Begutachtungsschritte wird die neue bzw. reparierte Funktionalität auf dem Produktivsystem installiert. Details zu unserem Entwicklungsprozess finden sich in unserer Dokumentation und in dieser Präsentation.
Bei der Dokumentation einer API gibt es unterschiedliche Aspekte: das Datenset als Ganzes, die Struktur von API-Anfragen und -Antworten, die verwendeten RDF-Properties und -Klassen, Provenienzinformationen. Im Folgenden beschreiben wir unsere Herangehensweise an die Dokumentation von lobid-resources und lobid-organisations, mit dem Schwerpunkt auf letzterem Dienst.
Um für die menschliche und maschinelle Nutzung der Daten einen Überblick zu geben, folgen wir im Wesentlichen der W3C-Empfehlung für die Nutzung von Daten im Web. Das Ergebnis ist eine JSON-LD-Datei und eine daraus generierte HTML-Version. Im Gegensatz zu den Beispielen der W3C-Empfehlung verwenden wir soweit möglich Vokabular von schema.org statt des DC-Terms-Vokabulars.
HTML-Version des lobid-organisations Datensets
Die API-Dokumentation (lobid-organisations, lobid-resources, lobid-gnd) führt zunächste grundlegende Konzepte der API anhand von Beispielen ein und zeigt darauf aufbauend komplexere Anfragen und spezielle Fälle wie die Suche nach URLs (in denen bestimmt Zeichen maskiert werden müssen). Für eine vollständige Referenz zur den Suchmöglichkeiten verweisen wir auf die Lucene- bzw. Elasticsearch-Dokumentation.
Im weiteren Verlauf beschreibt die Dokumentation die unterstüzten Inhaltstypen mit Beispielanfragen. Wir beschreiben den Einsatz der API zur Umsetzung einer Autosuggest-Funktionalität mit einem in die Dokumentationseite eingebetteten, funktionstüchtigen Beispiel. Schließlich beschreiben wir spezifische Funktionen der einzelnen Dienste wie ortsbezogene Abfragen, CSV-Export, und die Integration der APIs in OpenRefine (siehe dazu auch unten).
Wenn wir ein Schema und seine Verwendung verstehen wollen suchen wir häufig nach Beispielen. Oft sind Beispiele jedoch nur sekundäre Elemente der Dokumentation, wenn es überhaupt welche gibt. Sehr verbreitet ist ein beschreibender Ansatz zur Dokumentation von Vokabularen oder Applikationsprofilen, bei dem Elemente in einer Tabelle (häufig in einem PDF) aufgelistet werden, mit Beschreibungen verschiedener Aspekte in mehreren Spalten.
Eine Ausnahme bildet hier schema.org, das viele Beispiele bietet. Aber selbst hier sind die Beispiele ein Anhang der Beschreibung und manchmal fehlen sie (z.B. ist es schwierig zu erfahren, wie das Property publication oder die Klasse PublicationEvent verwendet werden). Wir sind der Ansicht, dass Beispiele Kernelement der Dokumentation sein sollten, während seitenweise Tabellen mit Elementen eines Matadatenschemas nicht sehr hilfreich und praktisch sind. Daher haben wir uns Gedanken gemacht, wie wir Beispiele ins Zentrum der Dokumentation stellen können.
Beispiele alleine sind nicht hinreichend, aber brauchen wir wirklich eine Tabelle, in der jedes Element unserer Daten beschrieben wird? Wenn wir das Beispiel in den Mittelpunkt stellen, können wir die strukturierten beschreibenden Daten (Name, Beschreibung, etc.) direkt dem Beispiel beifügen?
Hier bringen wir Werkzeuge zur Web-Annotation zum Einsatz, indem wir produktive Beispiele unserer JSON-LD Daten mit hypothes.is annotieren. Unser erster Ansatz war, direkt die JSON-Darstellungen zu annotieren (z.B. http://lobid.org/organisations/DE-38M.json), doch hier würden die Annotationen nur bei Verwendung des hypothes.is Chrome-Plugins sichtbar. Eine weitere Option wäre die Verwendung des hypothes.is via service, doch dieser unterstützt keine Annotation von Textdateien. Daher haben wir uns entschlossen, die JSON-Beispiele in die HTML-Dokumentationsseite einzubetten, und hypothes.is über JavaScript einzubinden.
In lobid-organisations reicht die Annotation eines einzigen Beispiels. Um die wesentlichen Felder in den lobid-resources Daten abzudecken annotieren wir je ein Beispiel der verschiedenen Ressourcentypen (Buch, Periodikum, Artikel, Serienband). Für lobid-gnd haben wir den Annotationsansatz noch nicht umgesetzt.
Wir annotieren jeden JSON-Key mit den folgenden Informationen:
- Name: eine menschenlesbare Bezeichnung für das Feld
- Beschreibung: eine kurze Beschreibung der Information in diesem Feld
- Abdeckung: Die Anzahl der Ressourcen mit Informationen in diesem Feld. Hier ergänzen wir häufig Beispiel-URLs zur Abfrage dieses Feldes.
- Anwendungsfälle: Beispiele zur Verwendung der Information in diesem Feld, häufig mit Beispielanfragen
- URI: die RDF-Property, die diesem Feld entspricht (d.h. die auf den JSON-Key im JSON-LD-Kontext gemappte URI)
- Provenienz: Informationen über die Felder in den Quelldaten, aus denen die Information in diesem Feld erzeugt wurde
Die ersten beiden Punkte (Name und Beschreibung) sowie die URI werden bei allen Annotationen angegeben, die anderen Werte sind (noch) nicht vollständig angegeben. Wir versuchen durch Beispielanfragen in den Annotationen ein Gefühl für Möglichkeiten zur Nutzung der API zu vermitteln, insbesondere in den Abschnitten 'Abdeckung' und 'Anwendungsfälle'.
Unter http://lobid.org/organisations/api kann man die annotationbasierte Dokumentation in Aktion sehen (für lobid-organisations gibt es auch eine deutsche Version, die lobid-resources Dokumentation ist nur auf deutsch verfügbar). Im Abschnitt zu JSON-LD öffnet sich durch einen Klick auf die hervorgehobenen JSON-Keys die hypothes.is-Seitenleiste mit Informationen über das entsprechende Element.
Beispielannotation für das "type" Feld
Die Beispiele, die zur Dokumentation annotiert werden, sollten im besten Fall Live-Daten aus dem Produktivsystem sein. So ist gewährleistet, dass bei Änderungen in den Daten das Beispiel, und damit die Dokumentation, automatisch aktuell bleibt. Dies verhindert manuellen Synchronisationsaufwand zwischen Daten und Dokumentation.
Wir hoffen und glauben, dass dieser Ansatz zur Dokumentation nützlicher und angenehmer ist als der traditionelle beschreibende Ansatz. Er bietet Nutzenden eine intuitive und interaktive Schnittstelle um die Daten der lobid-APIs zu erkunden und zu verstehen. Bei Fragen oder Unklarheiten kann innerhalb der hypothes.is-Seitenleiste auf die Annotationen geantwortet werden. So können spezifische Teile der Dokumentation diskutiert werden.
Wie im letzten Beitrag geschrieben, entwickeln wir seit einiger Zeit die neue Version des lobid-Normdatendienstes lobid-gnd, erreichbar über https://lobid.org/gnd. In der Version 1.x wurden GND-Entitäten noch über den /subject-Endpoint angeboten und es gab einen Endpoint nur für die GND-Personen (/person). Jetzt gibt es Zugriff auf alle GND-Entitäten über https://lobid.org/gnd. Noch befindet sich der Dienst im beta-Status, allerdings sind wir kurz davor, mit lobid-gnd in Produktion zu gehen. Das nehmen wir zum Anlass, um hier einen Einblick in die Funktionsweise von lobid-gnd zu geben.
Als Einstieg in die GND dient ein einfacher Suchschlitz. Die Suche unterstützt Boolesche Operatoren, Phrasensuche und Trunkierung. Für noch speziellere Abfragen wird die Lucene Query Parser Syntax unterstützt (siehe für Beispiele die API-Dokumentation). Siehe auch die Dokumentation der Elasticsearch Query String Syntax.
Während der Eingabe werden Vorschläge gemacht, um direkt den gewünschten Eintrag auswählen zu können. Zur leichteren Identifikation werden neben dem Namen auch der Typ einer GND-Entität angezeigt sowie weitere für eine Identifikation relevante Informationen wie etwa Geburts- und Sterbejahr bei Personen. Wenn kein vorgeschlagener Eintrag ausgewählt und stattdessen die Suche abgeschickt wird, öffnet sich die Suchergebnisliste.
Ein Piktogramm am Anfang jeder Zeile zeigt den allgemeinen Typ der Ressource an. Zur leichten Identifikation einer GND-Entität werden in der Zeile ebenfalls ihr spezieller Entitätstyp und weitere Informationen je nach Art des Eintrags angezeigt. Auf der rechten Seite werden Facetten angezeigt anhand derer die Suchergebnisse gefiltert werden können. Derzeit wird eine Facettierung nach Entitätstyp, GND-Sachgruppe, Ländercode und "Beruf oder Beschäftigung" (nur Personen) angeboten. In Klammern wird hinter jeder Facette wie üblich angezeigt, wieviele Ressourcen mit Klick auf die Facette herausgefiltert werden.
Mit Klick auf den Eintrag einer Suchergebnisliste wie auch der Vorschlagsliste gelangt man zur Einzeltrefferansicht.
Im Titel des Eintrags steht die präferierte Namensform plus Informationen zum Entitätstyp. Als Untertitel werden weitere identifizierende Merkmale wie auch in den Suchvorschlägen und der Ergebnisliste gezeigt. Darunter werden standardmäßig alle Beschreibungsfelder angezeigt sowie daneben – falls über EntityFacts vorhanden – eine zum Eintrag passende Abbildung. Aus EntityFacts werden auch die Links zu anderen Quellen wie Wikidata oder der Deutschen Digitalen Bibliothek bezogen (unter "Siehe auch" angezeigt).
In der tabellarischen Beschreibung finden sich sowohl textuelle Informationen als auch Links. Die Verlinkungen führen zur jeweilig verknüpften GND-Entität oder zum Eintrag im jeweiligen externen kontrollierten Vokabular (z. B. GND Geographic Area Codes oder GND-Sachgruppen). Wird die Lupe hinter einem Link geklickt, werden alle GND-Entitäten mit derselben Eigenschaft angezeigt, im Beispiel aus dem Foto z. B. alle Einträge mit Beruf oder Beschäftigung "Philosophin".
Im Tab "Beziehungen" gibt es eine anschauliche Repräsentation der GND-internen Verlinkungen in Form eines Graphen. Hier lassen sich die Knoten klicken, um zum Beziehungsgraphen eines verlinkten Eintrags zu kommen oder die Kanten, um eine Suche nach allen anderen Ressourcen mit derselben Relation anzustoßen, wie etwa alle Personen mit einer freundschaftlichen Beziehung zu Hilde Fränkel.
Das Piktogramm 
lobid-gnd ist – neben seiner Funktion als Endnutzerschnittstelle – auch eine Maschinenschnittstelle zur GND. Die Endnutzerschnittstelle basiert auf HTML für die Ansicht im Browser, aber ebenso liefern alle HTTP-GET-Anfragen auf Wunsch JSON(-LD) für die maschinelle Verarbeitung etwa durch Anwendungsentwickler. Bevor wir aber näher auf die Web-API (Application Programming Interface, deutsch: Anwendungsschnittstelle) eingehen, möchten wir zunächst beschreiben, wie und in welcher Form die GND-Daten indexiert werden.
Die Datenquelle sind die RDF-Daten der GND, die von der Deutschen Nationalbliothek (DNB) bereitgestellt werden. Das hbz hat Zugriff auf eine OAI-PMH-Schnittstelle der DNB, über die täglich Updates der Daten geholt werden, um Aktualität zu gewährleisten. Diese Daten werden dann für lobid-gnd mit einigen Anpassungen nach JSON-LD konvertiert. Für Details siehe etwa die Tickets #1, #2, #3, #24, #69, #101. Zum Teil waren die Anpassungen durch Inkonsistenzen in den Ausgangsdaten nötig, was wir zum Anlass genommen haben, Verbesserungen vorzuschlagen (u.a. auf der GND-Ontology-Mailingliste).
Die meiste Arbeit zur Optimierung der Datenstruktur übernimmt der JSON-LD-Kontext unter https://lobid.org/gnd/context.jsonld. Er bewirkt unter anderem folgende Dinge:
- Der Kontext bestimmt, welche JSON-Keys auf welche RDF-Properties gemappt werden, so dass im JSON nicht lange URIs als Keys angezeigt werden.
- Mit Einträgen wie
"AuthorityResource": "gnd:AuthorityResource"werden Typen (type) im JSON nicht als umständliche URI, sondern als einfacher String angezeigt, so dass die Daten auch für Entwickler leicht verständlich sind, die bisher nicht viel mit Linked Data gearbeitet haben. - Mittels
"@container": "@set"wird festgelegt, dass bis auf wenige Ausnahmen alle Properties ein Array als Wert haben, auch wenn es nur ein Element als Wert gibt. Dadurch ist die Datenstruktur homogener und vorhersagbarer. Dies spielt etwa für die Indexierung in Elasticsearch eine Rolle, da hier ein bestimmtes Feld immer den gleichen Datentypen (z.B. Array) haben muss. Auch bei der Nutzung der API erleichtert dies die Verarbeitung, da für ein bestimmtes Feld immer von einem identischen Typ ausgegangen werden kann. Im Zusammenspiel mit der Option compactArrays in JSON-LD ermöglicht dies eine gezielte Konfiguration einzelner Felder.
Außerdem nutzen wir einen einfachen JSON-LD Frame, um das JSON in eine hierarchische JSON-Struktur mit einem Wurzelelement zu bringen. Der Frame ist denkbar einfach:
{
"@context": "http://lobid.org/gnd/context.jsonld",
"@type": "AuthorityResource",
"@embed": "@always"
}
Damit das Framing bei jeder GND-Entität funktioniert, muss allen Entitäten der Typ AuthorityResource zugewiesen sein. Hier kommen wir zum Punkt, wo wir die Daten der DNB ergänzen, um bestimmte Funktionalitäten zu ermöglichen. Das von der DNB gelieferte RDF zum Eintrag von Hannah Arendt enthält folgende Informationen (in Turtle-Notation):
@prefix gndo: <http://d-nb.info/standards/elementset/gnd#> .
<http://d-nb.info/gnd/11850391X> a gndo:DifferentiatedPerson ;
gndo:preferredNameForThePerson "Arendt, Hannah" ;
gndo:variantNameForThePerson "Blücher, Johanna" .
Wie man sieht, wird hier nur die spezifische Klasse (gndo:DifferentiatedPerson) angegeben und typspezifische Properties (gndo:preferredNameForThePerson, gndo:variantNameForThePerson) zur Angabe der Ansetzungs- und Verweisungsformen verwendet. Dies mag für eine Abfrage der Daten über einen SPARQL-Endpoint ausreichend sein, weil die GND-Ontologie die Informationen enthält, welches die Überklassen und -Properties sind und somit mit Hilfe von Reasoning auch entsprechende Abfragen funktionieren.
Für eine einheitliche Abfrage der Ansetzungsformen aller GND-Entitäten in einem Suchmaschinenindex bzw. über eine Web-API und die Bereitstellung von Filtermöglichkeiten nach Oberklassen (Person, Schlagwort, Körperschaft, Geografikum etc.) reicht das aber nicht aus. Deshalb verzichten wir zum einen auf die Nutzung der spezifischen Namen-Properties und zum anderen ergänzen wir die Überklassen im JSON-LD. Die entsprechenden Teile im JSON-LD zu Hannah Arendt sehen in lobid-gnd etwa so aus:
{
"@context": "http://lobid.org/gnd/context.jsonld",
"id":"http://d-nb.info/gnd/11850391X",
"type":[
"DifferentiatedPerson",
"AuthorityResource",
"Person"
],
"preferredName":"Arendt, Hannah",
"variantName":[
"Blücher, Johanna",
"..."
]
}Im JSON-LD wird zu jeder in Beziehung gesetzten GND-Ressource sowie zu den GND-Sachgruppen und Ländercodes die entsprechende Ansetzungsform wie in den anderen lobid-Diensten als label mitgeliefert. Beim Eintrag zu Hannah Arendt gibt es unter anderen einen Link auf den Sterbeort, auf verschiedene Berufe/Beschäftigungen, auf drei GND-Sachgruppen und auf verwandte Personen. Wo im RDF der GND nur URIs zu finden sind, sieht es in lobid-gnd wie folgt aus:
{
"@context": "http://lobid.org/gnd/context.jsonld",
"id":"http://d-nb.info/gnd/11850391X",
"placeOfDeath":[
{
"id":"http://d-nb.info/gnd/4042011-5",
"label":"New York, NY"
}
],
"familialRelationship":[
{
"id":"http://d-nb.info/gnd/119378418",
"label":"Blücher, Heinrich"
},
{
"id":"http://d-nb.info/gnd/118502751",
"label":"Anders, Günther"
}
],
"gndSubjectCategory":[
{
"id":"http://d-nb.info/standards/vocab/gnd/gnd-sc#4.7p",
"label":"Personen zu Philosophie"
}
],
"geographicAreaCode":[
{
"id":"http://d-nb.info/standards/vocab/gnd/geographic-area-code#XA-DE",
"label":"Deutschland"
}
]
}Dies ermöglicht es API-Nutzer/innen auf einfache Weise, menschenlesbare Labels in Anwendungsoberflächen anzuzeigen anstatt bloße URIs. Es macht zudem die Suche nach Einträgen mit diesen Labels (z.B. Schriftsteller) überhaupt erst möglich wie auch Performance-kritische Anwendungsfälle, bei denen zusätzliche Lookups zu Ermittlung der Labels nicht praktikabel wären. So verwendet etwa die oben beschriebene Vorschlagsfunktion die Labels zum schnellen Auffinden des gesuchten Eintrags.
Neben dem GND-RDF stellt die DNB mit EntityFacts einen Dienst bereit, der einfaches JSON-LD zu Personen, Körperschaften und Geographika aus der GND anbietet, angereichert um Links zu anderen Datenanbietern (Wikidata, ORCID, BnF etc.) sowie zu Abbildungen einer GND-Entität auf Wikimedia Commons. Die Bereitstellung eines Dumps der EntityFacts-Daten seitens der DNB hat uns dazu ermutigt, diese zusätzlichen Informationen zu ergänzen. Für Details zur Umsetzung siehe Ticket #69. Im Beispiel Hannah Arendt sind dies unter anderem folgende Informationen:
{
"id":"http://d-nb.info/gnd/11850391X",
"depiction":[
{
"id":"https://commons.wikimedia.org/wiki/Special:FilePath/Hannah_arendt-150x150.jpg",
"url":"https://commons.wikimedia.org/wiki/File:Hannah_arendt-150x150.jpg?uselang=de",
"thumbnail":"https://commons.wikimedia.org/wiki/Special:FilePath/Hannah_arendt-150x150.jpg?width=270"
}
],
"sameAs":[
{
"collection":{
"abbr":"BNF",
"name":"Bibliothèque nationale de France",
"publisher":"Bibliothèque nationale de France",
"icon":"http://www.bnf.fr/bnf_dev/icono/favicon.ico",
"id":"http://www.wikidata.org/entity/Q19938912"
},
"id":"http://catalogue.bnf.fr/ark:/12148/cb118890622"
},
{
"collection":{
"abbr":"WIKIDATA",
"name":"Wikidata",
"publisher":"Wikimedia Foundation Inc.",
"icon":"https://www.wikidata.org/static/favicon/wikidata.ico",
"id":"http://www.wikidata.org/entity/Q2013"
},
"id":"http://www.wikidata.org/entity/Q60025"
}
]
}Mit diesen Anreicherungen kann auf der Basis von Identifikatoren Dritter in lobid-gnd gesucht werden, etwa anhand einer ORCID oder eines ISNI. Mit den Bildern können Einträge wie z.B. Autorenseiten illustriert werden. Wobei zu beachten ist, dass die Attributions- und Lizenzinformationen zu den Bildern nicht mitgeliefert werden, sondern von der Wikimedia Commons API geladen werden müssen. Zur Umsetzung siehe z.B. diesen Kommentar und unsere aktuelle Implementierung.
Das im vorherigen Abschnitt beschriebene JSON-LD indexieren wir in einen Elasticsearch-Suchmaschinenindex und bieten die Elasticsearch-Abfragesprache für Suchanfragen und zum Filtern an. Somit sind nützlichen Elasticsearch-Funktionen für interessierte Nutzer verfügbar wie z.B. Unterstützung der Lucene Query Language und exists-Abfragen. Eine Dokumentation der Elasticsearch query_string DSL findet sich hier. Darauf aufsetzend bieten wir auch einen Parameter für Auto-Suggest, dessen Rückgabefelder bei Bedarf angepasst werden können.
Für eine detaillierte API-Beschreibung verweisen wir auf die in Entstehung befindliche Dokumentation unter https://lobid.org/gnd/api. Im Folgenden seien nur ein paar Beispiel-Abfragen genannt, wobei durch Ergänzung von format=json auch im Browser JSON-LD angezeigt werden kann:
- Personen, die während der NS-Zeit in Köln geboren wurden
- Einträge, die einen DDB-Link aber keinen Wikidata-Link haben (um etwa herauszufinden, welche Personen mit Objekten in der Deutschen Digitalen Bibliothek womöglich noch nicht in Wikidata verzeichnet sind)
- Alle Entitäten, zu denen ein Architekt angegeben wurde
- "Kleinräumige Geografika" innerhalb von Berlin
lobid-gnd möchte die GND als Linked Open Usable Data anbieten. Die Daten sollen einfach zu nutzen sein, für Anwendungsentwickler/innen über die API und für Endnutzer/innen über eine intuitive Oberfläche. Wir freuen uns über jegliche Rückmeldungen, seien es Verbesserungsvorschläge, Bug-Meldungen, Lobhudeleien oder Verrisse. Bitte teilen Sie uns über Anmerkungen zu diesem Beitrag mit hypothes.is, per E-Mail oder Twitter mit, wie sie die Daten gerne nutzen würden, welche Funktionen Ihnen fehlen oder wo Sie einen Bug entdeckt haben.
Dieser Artikel bietet einen Überblick zur Suche und Navigation in lobid-gnd. Die Startseite von lobid-gnd führt auf die einfache Suchoberfläche:
Nach der Eingabe im Suchfeld kann einer der Vorschläge direkt ausgewählt werden, um zur Detailansicht zu gelangen:
Alternativ kann eine Suche über die Enter-Taste oder das Lupen-Icon ausgeführt werden:
Als alternativer Einstieg kann die gesamte GND erkundet werden:
Über beide Wege kommt man zur Trefferliste. Über den Treffern auf der linken Seite kann die Anzahl der Treffer pro Seite gewählt werden, darunter kann zwischen den Seiten gewechselt werden:
Auf der rechten Seite ermöglicht eine facettierte Suche nach Entitätstyp, GND-Sachgruppe, Ländercode und Beruf oder Beschäftigung eine Eingrenzung der Ergebnisse:
Als Standard werden in jeder Facette die fünf häufigsten Einträge angezeigt, weitere Einträge lassen sich ein- und ausblenden:
Entitätstypen sind in Untertypen differenziert:
Über die Auswahl unterschiedlicher Facetten lässt sich die Treffermenge präzise eingrenzen, z.B. zur Anzeige aller hydrologischen Geografika in Nordrhein-Westfalen:
Erweiterte Suchmöglichkeiten ergeben sich aus einer Kombination von Sucheinstieg über das Suchfeld und facettierter Suche sowie über Mehrfachauswahl innerhalb einer Facette:
Der Klick auf einen Suchtreffer führt zu einer Detailansicht. Die Detailseiten enthalten Links zu verknüpften GND-Einträgen. Über die Lupen-Icons kann eine Suche nach Einträgen mit der gleichen Beziehung angestoßen werden, z.B. alle Teile der Nordsee:
Die visuelle Darstellung im Tab "Beziehungen" erlaubt ebenso eine Navigation zu den verknüpften Entitäten per Klick auf einen Knoten des Graphs und eine Suche nach weiteren Einträgen mit der gleichen Beziehung per Klick auf eine Kante:
Im vorherigen Beitrag haben wir bereits die Oberfläche von lobid-gnd und ihre Funktionen beschrieben. Die API ermöglicht aber auch komplexere Abfragen, für die man sich ein wenig mit den zugrundeliegenden Datenstrukturen vertraut machen muss. Dies soll in diesem Beitrag an einigen Beispielen ausgeführt werden.
Bevor wir die Suchmöglichkeiten an einigen Beispielen illustrieren, werden zunächst einige generelle Informationen zur Suche geliefert.
Alle Abfragen können über das Suchfeld auf der lobid-gnd-Seite eingegeben werden:
Die Queries auch direkt als Teil der URL angegeben und im Browser geöffnet werden:
http://lobid.org/gnd/search?q=Dom+Köln
Oder auf der Kommandozeile via curl:
$ curl "http://lobid.org/gnd/search?q=Dom+K%C3%B6ln"
Standardmäßig geht eine im Suchfenster angestoßene Suche über alle Felder. Mehrere Suchterme werden dabei per default mit einem booleschen AND verknüpft. Boolesche Operatoren lassen sich aber auch passgenau für den jeweiligen Zweck angeben. Beispiele:
- [Dom UND (Aachen ODER Köln)](http://lobid.org/gnd/search?q=Dom+AND+(Aachen OR Köln))
- Geographika in (Äthiopien ODER Eritrea)
In den folgenden Beispielen wird immer wieder auf die strukturierten Daten im Format JSON-LD Bezug genommen, die es für jeden Eintrag in lobid-gnd gibt. Anzeigen lassen sich diese wie folgt:
- Mit Klick auf das JSON-LD-Zeichen in einer Detailansicht:
- Durch Anhängen von
.jsonan die URL eines Einzeltreffers, z.B. http://lobid.org/gnd/11850391X.json - Der Vollständigkeit halber: Bei Suchanfragen muss der Parameter
format=jsonangehängt werden, um die gesamte Ergebnisliste als JSON-LD anzuzeigen, z.B. http://lobid.org/gnd/search?q=hannah+arendt&format=json. (Alternativ können auch mit dem Parameterformat=jsonlJSON Lines ausgegeben werden, d.h. pro Zeile ein Eintrag als JSON, z.B. http://lobid.org/gnd/search?q=hannah+arendt&format=jsonl).
Die Bedeutung eines Feldes lässt sich im JSON-LD-Kontext unter http://lobid.org/gnd/context.jsonld nachschlagen. Will ich beispielsweise wissen, wie das Feld broaderTermPartitive verwendet wird, dann suche ich im JSON-LD-Kontext nach diesem Feld und folge dem angegebenen Link zur Beschreibung der zugrundeliegenden RDF-Property, hier ist dies die Beschreibung von "Oberbegriff partitiv" in der GND-Ontologie.
Über die <Feld>:<Suchbegriff>-Syntax kann in spezifischen Feldern gesucht werden, z.B. nach einer bestimmten Ansetzungsform:
http://lobid.org/gnd/search?q=preferredName:"Dom+Köln"
Will ich ein Feld abfragen, das sich nicht auf der obersten Ebene der geschachtelten JSON-Daten befindet, muss ich es über den Pfad identifizieren, das heißt ich gebe die Felder an, in denen das Feld eingebettet ist. Beispielsweise professionOrOccupation.label in folgenden Daten:
{
"professionOrOccupation": [
{
"id": "http://d-nb.info/gnd/4124099-6",
"label": "Sänger"
}
]
}So kann ich etwa nach professionOrOccupation.label:Sänger* suchen, wenn ich sowohl männliche wie auch weibliche Vokalist*innen finden möchte.
Häufig ist es hilfreich herauszufinden, wie viele und welche Einträge überhaupt eine bestimmte Information beinhalten bzw. in wie vielen Einträgen ein bestimmtes Feld fehlt. Dafür kann eine Anfrage in der Form _exists_:<Feldname> verwendet werden, optional mit dem booleschen NOT, um alle Einträge zu bekommen, die das jeweilige nicht haben, z.B. geschlechtslose Geister:
http://lobid.org/gnd/search?q=type:Spirits+AND+NOT+_exists_:gender
Beim Betrachten etwa des Eintrags zum Friedenspark Köln fällt auf, dass ein Architekt angegeben ist. Bei Interesse daran, welche Einträge noch Architekt*innen angeben, lässt sich das wie folgt herausfinden.
Ich schaue zunächst im JSON nach, wie das entsprechende Feld heißt:
{
"id":"http://d-nb.info/gnd/1065252633",
"architect":[
{
"id":"http://d-nb.info/gnd/118530232",
"label":"Encke, Fritz"
}
]
}Dann schreibe ich die entsprechende _exists-Anfrage:
Unterfelder werden wie beschrieben über eine Punkt-Notation angegeben, z.B. Architekten mit dem label "Fritz":
architect.label:Fritz
Aus einer E-Mail-Anfrage an das lobid-Team:
Noch eine Frage habe ich zur API. Kann ich die Suche nach Namen so einschränken, dass ich nach exakten Matches in den
variantNameoderpreferredNamesuchen kann?
Das geht über eine Kombination von booleschem OR und Phrasensuche mit "<Phrase>" in den entsprechenden Feldern:
preferredName:"Muka, Arnošt" OR variantName:"Muka, Arnošt"
Im Kontext der Anzeige eines zufälligen Bildes auf der lobid-gnd-Startseite kam die Frage auf, wie viele und welche Einträge einen Wikidata-Link aber kein Bild haben. Dafür schaue ich mir zunächst am besten die Daten eines Eintrags an der beides hat, z.B. Hannah Arendt. Hier die für uns wichtigen Ausschnitte:
{
"id":"http://d-nb.info/gnd/11850391X",
"depiction":[
{
"id":"https://commons.wikimedia.org/wiki/Special:FilePath/Hannah_arendt-150x150.jpg",
"url":"https://commons.wikimedia.org/wiki/File:Hannah_arendt-150x150.jpg?uselang=de",
"thumbnail":"https://commons.wikimedia.org/wiki/Special:FilePath/Hannah_arendt-150x150.jpg?width=270"
}
],
"sameAs":[
{
"collection":{
"abbr":"WIKIDATA",
"name":"Wikidata",
"publisher":"Wikimedia Foundation Inc.",
"icon":"https://www.wikidata.org/static/favicon/wikidata.ico",
"id":"http://www.wikidata.org/entity/Q2013"
},
"id":"http://www.wikidata.org/entity/Q60025"
}
]
}Die Verlinkung zu Wikidata findet sich innerhalb eines Objekts im sameAs-Array. Gekennzeichnet als Wikidata-Verlinkung ist sie durch die angegebene Sammlung (collection). Will ich also meine Suche auf Einträge einschränken, die einen Link zu Wikidata haben muss ich nach Einträgen mit der ID http://www.wikidata.org/entity/Q2013 im Feld sameAs.collection.id suchen:
sameAs.collection.id:"http://www.wikidata.org/entity/Q2013"
Hinweis: Damit die Suche funktioniert muss die Wikidata-URI (http://www.wikidata.org/entity/Q2013) in Anführungszeichen gesetzt werden (exakte Phrasensuche).
Wir wollen aber nicht alle Einträge mit Wikidata-Link, sondern nur jene ohne Bild. Das heißt wir müssen die Bedingung ergänzen, dass das Feld depiction nicht vorhanden ist. Hier kommt uns die oben eingeführte _exist_-Anfrage zur Hilfe. Konkret müssen wir zur Suchanfrage AND NOT _exists_:depiction ergänzen, so dass am Ende dabei rauskommt:
sameAs.collection.id:"http://www.wikidata.org/entity/Q2013" AND NOT _exists_:depiction
Wenn ich eine Frage beantworten möchte wie "Welche Personen in der GND wurden in der NS-Zeit in Köln geboren?", dann ist es sinnvoll, sich einen Eintrag zu suchen, der die nötigen Informationen zur Beantwortung einer solchen Frage besitzt. Hier z.B. die strukturierten Daten zum Eintrag von Konrad Adenauer, der folgende Informationen zu Geburtsort und -datum enthält:
{
"id":"http://d-nb.info/gnd/11850066X",
"placeOfBirth":[
{
"id":"http://d-nb.info/gnd/4031483-2",
"label":"Köln"
}
],
"dateOfBirth":[
"1876-01-05"
]
}Den ersten Schritt – die Eingrenzung auf in Köln geborene Personen – können wir auf einfache Weise über die Benutzeroberfläche für den Eintrag von Konrad Adenauer vollziehen: Mit einem Klick auf die Lupe neben "Geburtsort Köln" wird eine Abfrage nach allen in Köln geborenen Menschen in der GND gestartet.
Jetzt müssen wir die vorhandene Abfrage (placeOfBirth.id:"http://d-nb.info/gnd/4031483-2") noch um eine Einschränkung des Geburtsdatums ergänzen. Hier können wir eine range query verwenden, die Zeitrahmen mit verschiedenen Detailgraden (Jahr, Monat, Tag etc.) ermöglicht. Für unseren Fall probieren wir zunächst die tagesgenaue Eingrenzung mit dateOfBirth:[1933-01-30 TO 1945-05-08]:
placeOfBirth.id:"http://d-nb.info/gnd/4031483-2" AND dateOfBirth:[1933-01-30 TO 1945-05-08]
Ebenfalls möglich ist eine jahresgenaue Abfrage (enthält hier auch Geburtsdaten im Jahr 1933 vor dem 30.1. und im Jahr 1945 nach dem 8.5.):
placeOfBirth.id:"http://d-nb.info/gnd/4031483-2" AND dateOfBirth:[1933 TO 1945]
Je nach Zweck kann die eine oder andere Abfrage sinnvoller sein.
lobid-gnd ist auf Basis von Elasticsearch umgesetzt. Wir verweisen hier auf die vollständige Dokumentation der Elasticsearch Query String Syntax sowie der Apache Lucene Query Syntax. (Elasticsearch basiert auf Apache Lucene.)
Letzte Woche haben wir einige Funktionen zu lobid-gnd ergänzt, hier ein Überblick.
Wie auch in lobid-organisations wird nun auf der lobid-gnd-Startseite mit jedem Laden ein zufälliges Bild zu einer GND-Ressource angezeigt. Momentan gibt es knapp 200.000 Einträge mit Bild, davon sind die meisten Personen. Wer also Lust hat, die GND ein wenig näher kennenzulernen, kann ja mal die Startseite ein paar Mal neu laden.
Screenshot der lobid-gnd-Startseite mit dem Bild von Irena Sendler
Für jede lobid-gnd-Abfrage kann jetzt – wie auch in lobid-resources – die gesamte Ergebnismenge als JSON Lines heruntergeladen werden, indem einach der Parameter format=jsonl ergänzt wird. Im Antwortformat wird dann pro Zeile ein GND-Eintrag zurückgeliefert, zum Beispiel alle GND-Entitäten vom Typ "Sammlung" (Unterklasse von "Werk"):
http://lobid.org/gnd/search?filter=type:Collection&format=jsonl
Bei solchen kleineren Ergebnismengen reicht der JSON-Lines-Download aus, werden größere Untermengen der GND abgefragt, empfiehlt es sich, das Ergebnis komprimiert als gzip herunterzuladen. Dafür muss der HTTP-Anfrage nur der entsprechende Accept-Header mitgegeben werden, z.B. mit curl:
$ curl --header "Accept-Encoding: gzip" 'http://lobid.org/gnd/search?filter=type:Collection&format=jsonl'
Seit Ende letzter Woche ist die OpenRefine Reconciliation API für lobid-gnd produktiv. Damit ist es auf einfache Weise möglich, mit dem für Datenaufbereitung und -anreicherung beliebten Werkzeug OpenRefine eine Liste von Ansetzungsformen mit der GND abzugleichen, um die Textstrings auf GND-IDs zu matchen. Dafür müssen lediglich die abzugleichenden Daten in OpenRefine geladen werden, die entsprechende Spalte ausgewählt und der Reconciliation-Prozess z.B. wie folgt durchgeführt werden.
1.Start des Reconciliation-Prozesses für eine Spalte in OpenRefine
2. Ergänzen des lobid-gnd Reconciliation Endpoints (https://lobid.org/gnd/reconcile) in OpenRefine
3. (Optionale) Auswahl einer GND-Untermenge (hier "Person") für Reconciliation
4. Start der API-Abfrage mit Klick auf "Start Reconciling"