Normdaten als Linked Data publizieren und nutzen

lobid-gnd, OpenRefine Reconciliation und SkoHub

Adrian Pohl / Pascal Christoph / Fabian Steeg

Offene Infrastruktur, Hochschulbibliothekszentrum NRW (hbz)


WWW, 2020-06-26
Vortrag im Rahmen des Kolloquiums Digital Humanities der Universität zu Köln

Diese Präsentation:
http://slides.lobid.org/dhc-2020/
Creative Commons License

Agenda

1. Normdaten
2. Linked Data & JSON-LD
3. OpenRefine Reconciliation
4. SkoHub

Hochschulbibliothekszentrum des Landes Nordrhein-Westfalen, seit 1973

Dienstleistungs- und Entwicklungseinrichtung für digitale Services in Hochschulbibliotheken

Einige Arbeitsbereiche: Verbundkatalog, Suchportal DigiBib, Fernleihe, Konsortiale Erwerbung

ca. 90 Mitarbeitende, ca. 10% haben Informationsverarbeitung studiert, Prof. Eide im hbz-Beirat

1. Normdaten

Warum Normdaten?

Ursprüngliches Ziel: normierte Namensformen für Dinge und Personen

Ermöglicht (bereits im Zettelkatalog!) einheitlichen Einstieg in die Literatursuche

Beispiele: Suche nach Literatur von oder über eine bestimmte Person oder zu einem bestimmten Thema anhand eines normierten Namens

Was sind Normdaten? 1/2

Sammlungen von Datensätzen zur eindeutigen Identifizierung von Dingen

Dinge können z.B. sein: Personen, Organisationen, geographische und/oder administrative Einheiten, Themen

ein Normdatensatz besteht mindestens aus: ID, Vorzugsbenennung

oftmals gibt es weitere identifizierende Merkmale, z.B.: alternative Benennungen, Lebensdaten, Orte (Geburts-, Sterbeort, Wirkungsort, Sitz etc.)

Was sind Normdaten? 2/2

Normdatensätze können aufeinander verweisen, z.B. Person --geborenIn--> Ort

...oder auf Einträge zum selben Gegenstand in anderen Datenbanken

Beispiel-Normdateien: ORCiD, ISNI, Wikidata, Geonames, GRID

Die Gemeinsame Normdatei (GND)

Normdatei für Bibliotheken im deutschsprachigen Raum

Datensätze für Personen, Körperschaften, Konferenzen & Veranstaltungen, Geografika, Schlagwörter, Werke

Für die formale Erfassung einer Ressource (Autor*innen, Körperschaften etc.) und für die inhaltliche Erschließung (wer oder was sind die Themen einer Ressource)

In den letzten Jahren wird die GND vermehrt auch von Archiven, Museen und Wissenschaftler*innen genutzt

Die GND-Kooperative

Verantwortlich für die GND ist die GND-Kooperative

Die GND-Kooperative besteht hauptsächlich aus den deutschsprachigen Bibliotheksverbünden, den angeschlossenen Bibliotheken sowie der Deutschen Nationalbibliothek (DNB) als technischer Hoster

GND als LOD von der DNB

Die DNB publiziert die GND unter anderem als Linked Open Data (LOD) unter https://data.dnb.de/opendata/

Zusätzliche Anreicherungen, z.B. Links in EntityFacts

Diese Daten bilden die Grundlage für lobid-gnd

2. Linked Data & JSON-LD

Ziele

Überführung traditioneller bibl. Praktiken in das Web

Sichtbarkeit und Auffindbarkeit im Web erreichen

Nachnutzbarkeit ermöglichen

Synergieeffekte durch Verlinkung mit anderen Daten

Verbesserung der Recherchemöglichkeiten

Quelle: Pohl, Adrian / Ostrowski, Felix (2010): 'Linked Data' - und warum wir uns im hbz-Verbund damit beschäftigen." B.I.T. Online 13(3): S. 259-268. Preprint: http://www.hbz- nrw.de/dokumentencenter/produkte/lod/aktuell/pohl_ostrowski_2010_linked-data.pdf

Linked Data: Best Practices

  1. Nutze URIs als Namen für Dinge
  2. Nutze HTTP-URIs, so dass Menschen sie aufrufen können
  3. Wenn jemand einen URI aufruft, biete nützliche Informationen an unter Nutzung der Standards (RDF, SPARQL)
  4. Nimm Links zu anderen URIs auf, so dass weitere Dinge entdeckt werden können.

Tim Berners-Lee (2006ff): Linked Data – Design Issues

RDF & The Semantic Web
– cutting edge seit 1999

Linked Data

Ultimately, RDF and the Semantic Web are of no interest to Web developers. They also have a really negative public perception problem. We should stop talking about them. Let’s shift the focus to be on Linked Data, explaining the problems that Web developers face today, and concrete, demonstrable solutions to those problems.

– Manu Sporny, damals Vorsitzender der RDFa Working Group beim W3C, der JSON-LD Community Group & Mitglied weiterer Semantic-Web-Gruppen, beim Schreiben an der JSON-LD-Spezifikation
Sporny (2012)

Linked Open Data

Wissen ist offen, wenn jedeR darauf frei zugreifen, es nutzen, verändern und teilen kann – eingeschränkt höchstens durch Maßnahmen, die Ursprung und Offenheit des Wissens bewahren.

http://opendefinition.org/od/2.1/de/

Linked Open Usable Data

Source: Rob Sanderson on Twitter

"Using data"?

Daten werden mit existierender Software bearbeitet (ausgewertet, ergänzt, integriert etc.)

Entwicklung neuer Software zur Interaktion mit Daten

LOUD: Orientierung auf Bedürfnisse und Konventionen rund um Software (Entwicklung, Standards, etc.)

Nützliche Daten: Zielgruppe kennen & eigene Angebote auf sie ausrichten

Hauptzielgruppe: Entwickler*innen oder Nutzer*innen von Software für Datenzugriff und -manipulation

APIs

Software baut auf APIs auf

APIs machen Softwareentwicklung handhabbar
(für 1st- und 2nd-Party-Software)

APIs ermöglichen Nutzung und Integration
von 3rd-Party-Software

Zum Bsp. lobid-Formate und -Anwendungen

APIs entkoppeln Anwendungen von Datenquellen, Formaten und Systemen. Sie ermöglichen so modulare, zukunftsfähige Applikationen

Und wie APIs bereitstellen?

JSON (JavaScript Object Notation) über HTTP (Hypertext Transfer Protocol)

Der Web-API-Standard seit Jahren, siehe z.B. Target (2017)

The Rise and Rise of JSON

Quellen: Google Trends, Web Data Commons, W3Techs

JSON

Ein einfaches Key-Value-Format für strukturierte Daten

Key ist immer ein String

Value ist Object, Array, Number, String oder Boolean

{ "foo": "bar" }

Quelle: RFC 8259

Beispiel:
GET https://api.github.com


{
"current_user_url": "https://api.github.com/user",
"authorizations_url": "https://api.github.com/authorizations",
"emails_url": "https://api.github.com/user/emails",
"emojis_url": "https://api.github.com/emojis",
"events_url": "https://api.github.com/events",
"feeds_url": "https://api.github.com/feeds",
"followers_url": "https://api.github.com/user/followers",
"gists_url": "https://api.github.com/gists{/gist_id}",
"hub_url": "https://api.github.com/hub",
...
}
				

JSON + Linked Data = JSON-LD

JSON-LD

"designed to be usable directly as JSON, with no knowledge of RDF" – Es ist richtiges JSON!

"also designed to be usable as RDF"

https://www.w3.org/TR/json-ld/

JSON

$ curl -H "Accept: application/json" https://api.github.com/users/acka47 { "login": "acka47", "avatar_url": "https://avatars2.githubusercontent.com/u/160292?v=4", "url": "https://api.github.com/users/acka47", "type": "User", "name": "Adrian", "company": "hbz", "location": "Cologne, Germany", "bio": "Metadata, RDF, vocabularies. Working at @hbz. " }

JSON + @context + @id = JSON-LD

{ "@context": "http://schema.org/", "@id": "https://github.com/users/acka47", "login": "acka47", "avatar_url": "https://avatars2.githubusercontent.com/u/160292?v=4", "url": "https://api.github.com/users/acka47", "type": "User", "name": "Adrian", "company": "hbz", "location": "Cologne, Germany", "bio": "Metadata, RDF, vocabularies. Working at @hbz. " }

Diese allgemeine Entwicklung spiegelt sich in unserer eigenen Arbeit wider

Von LOD zu LOUD – Erfahrungen aus zehn Jahren Linked-Open-Data-Entwicklung am hbz

lobid-Dienste

lobid-resources: Daten des hbz-Verbundkatalogs

lobid-organisations: Daten des deutschsprachigen Sigelverzeichnisses und DBS-Stammdaten

lobid-gnd: Gemeinsame Normdatei

2010-2013: Alpha-Betrieb

Publikation zunächst von RDF-Dateien, dann auch SPARQL

Datentransformation mit Perl-Skript, dann hbz-Tool

Jahrelanger Prozess zur offenen Lizenzierung der Verbunddaten

2013-2017: lobid v1.x

Richtung LOUD: Von RDF-Dateien und SPARQL zu LOD-API mit generiertem JSON-LD

Datentransformation mit Metafacture

Fokus auf Schnittstelle, keine Oberflächen

seit 2017: lobid v2

Richtig LOUD: JSON-LD-y JSON-LD:
Best statt worst of both worlds

Oberflächen

OpenRefine-Schnittstellen

Beispiel: lobid-gnd

Rechercheoberfläche & LOD-API für die GND

a. Die Oberfläche

Auto Suggest

Ergebnisliste

Einzeltreffer

Beziehungsgraph

b. Die Daten

JSON-LD-Link

 
 
 

JSON(-LD)

c. Web-API

Abfragemöglichkeiten

JSON-LD-Daten in Elasticsearch-Index

Elasticsearch bzw. Lucene Suchsyntax

Parameter für Auto Suggest

OpenRefine Reconciliation Endpoint

Parameter für Bulk Downloads

Für Einzeltreffer andere RDF-Serialisierungen per Content Negotiation

Beispiel-Abfragen

Alle Entitäten, zu denen ein Architekt angegeben wurde

Personen, die während der NS-Zeit in Köln geboren wurden

lobid-gnd: Formulierung komplexer Suchanfragen

Beispiel-Nutzung

correspsearch.net: GND-Lookup

repository.publisso.de: GND-Lookup

kalliope-verbund.info: Externe Links

performing-arts.eu: Infoboxen zu Personen aus der GND

bauhaus.de: Abgleich und Anreicherung lokaler Archivdaten mit der GND

3. OpenRefine Reconciliation

OpenRefine

"A powerful tool for working with messy data"

"cleaning it; transforming it from one format into another; and extending it with web services and external data"

Oberfläche wie Tabellenkalkulation

Läuft im Browser, lokal oder gehostet

Reconciliation mit OpenRefine

Matchen eigener Daten (z.B. Liste von Namen aus Texten) auf GND-Ressourcen in OpenRefine

Übernahme von Daten aus spezifischen Feldern der gematchten GND-Einträge mittels Data Extension API

lobid-gnd war der zweite Dienst nach Wikidata, der die Data Extension API unterstützt

Große Resonanz auf das Angebot, insbesondere aus den Digital Humanities

Grundlegendes Vorgehen

Ergebnisse verbessern

Properties zur Verbessung der Matches – Beispiele

Lebensdaten

Beruf & Parteizugehörigkeit

http://blog.lobid.org/2019/09/30/openrefine-examples.html

Daten erweitern

Reconciliation API Clients

Reconciliation API für andere Clients als OpenRefine

z.B. Cocoda, "a web application to manage and create mappings between knowledge organization systems, such as classifications, authority files, and thesauri."

W3C Reconciliation Community Group: "Matching entities across data sources using different identifiers and formats [...] on the web."

Ziel: Reconciliation als Web-Standard

https://lobid.org/gnd/reconcile

4. SkoHub

SkoHub-Projekt

Hauptentwicklung März 2019 bis April 2020 vom hbz mit graphthinking GmbH

Gefördert vom Ministerium für Kultur und Wissenschaft NRW

Ziel: Infrastruktur zum Bekanntmachen und Abonnieren von Web-Ressourcen über themenbasierte Kommunikationskanäle

SkoHub-Module

SkoHub Vocabs: Prozess & Tools zur maschinen- und menschenlesbaren Publikation kontrollierter Vokabulare

SkoHub Editor: Mit JSON-Schema konfigurierter webbasierter Metadateneditor inklusive Validierung

SkoHub PubSub: Infrastruktur zur normdatenbasierten Subskription von neuen Publikationen

Anwendungsbeispiel:

Nutzung der SkoHub-Werkzeuge bei der Entwicklung eines Metadatenprofils

Exkurs: Was ist ein Profil?

Datenmodell für eine bestimmte Anwendung/Community unter Nutzung existierender Metadatenschemas

Gibt an, welche Metadatenschemas (z.B. Dublin Core, schema.org) und welche Elemente und Typen daraus benutzt werden

Definiert Einschränkungen für die Nutzung des/der Schema(s)

z. B. Einschränkungen auf Felder (welche Felder, Pflichtfeld: ja/nein, Häufigkeit) oder Werte (Formatvorgaben, kontrollierte Vokabulare)

Das LRMI-Profil

Auf LRMI (Learning Resource Metadata Initiative) und damit schema.org basierendes Profil für die Beschreibung von offenen Lehr- und Lernressourcen (OER = Open Educational Resources) im Hochschulbereich

Dient als Basis für OER Search Index (OERSI)

Wird offen entwickelt im Rahmen der OER-Metadatengruppe des Kompetenzzentrums Interoperable Metadaten (KIM)

Die Umsetzung

Zuerst JSON Schema & SkoHub-basiertes Referenz-Eingabeformular entwickeln

Wenn benötigt, kontrollierte Vokabulare mit SkoHub Vocabs publizieren

Danach: menschenlesbare Spezifikation schreiben

JSON Schema als zentrales Dokument

Das JSON Schema legt Felder, Wertetypen & referenzierte kontrollierte Vokabulare fest:
https://dini-ag-kim.github.io/lrmi-profile/draft/schemas/schema.json

Automatisierte Tests: Schema wird gegen valide/invalide Beispieldatensätze validiert

Schema lässt sich im SkoHub Editor ausprobieren:
https://skohub.io/editor/

Kontrollierte Vokabulare als separate SKOS-Datei

Kontrollierte Vokabulare/Wertelisten werden separat als SKOS-Datei veröffentlicht und im Schema referenziert, so dass es im Editor eine Lookup-Funktion gibt

(Es gibt übrigens seit Kurzem eine deutschsprachige Einführung zu SKOS – Simple Knowledge Organization System)

Wo kommen die "Subject"-Werte her?

Kontrollierte Vokabulare müssen in SkoHub Vocabs veröffentlicht sein

Pflege als Turtle-Datei auf GitHub und Publikation als HTML/JSON-LD unter skohub.io (siehe hier für Details)

Hier: Nutzung einer skosifizierten Destatis-Systematik

SkoHub PubSub: Web-basierte Subskription & Benachrichtigung

(mit ActivityPub)

Eine Inbox für jedes Thema

Anwendungen senden Benachrichtigungen an die Inbox

Anwendungen abonnieren eine Inbox und erhalten Push-Benachrichtigungen

Beispiel

Siehe auch die SWIB19-Demo und Blogbeitrag

Vorteile

Push- statt Pull-Ansatz

Unterstützt alle Web-Ressourcen

Der Nutzen von Normdaten/KOS wird maximiert

Die Erstellung und Pflege gemeinsamer, plattformübergreifender KOS wird gefördert

Anreize für Publizierende, strukturierte Metadaten zu ergänzen

Weiterführende Informationen –
Rund um lobid und Linked Data

Weiterführende Informationen – Nutzung von lobid-gnd