Auf der Zielgeraden –

Erweiterung der NWBib-Raumsystematik mit Wikidata

Adrian Pohl / @acka47 Linked Open Data, Hochschulbibliothekszentrum NRW (hbz)

Köln, 2019-01-24

Diese Präsentation:
http://slides.lobid.org/nwbib-treffen-2019//

Agenda

1. Technische Basis: lobid-resources
2. Struktur & Darstellung
3. Wikidata als Infrastruktur
4. Status: Übergangsphase
5. Aktualisierung der Aleph-Daten
6. Maßnahmen zum Änderungsschutz
7. Katalogisierung nach der Erweiterung

1. Technische Basis: lobid-resources

nwbib.de:
eine Webanwendung basierend auf der lobid-resources-API

lobid

Dateninfrastruktur für Bibliotheken, Archive, Museen

Das hbz entwickelt seit 2009 Software im Bereich Linked Open Data

Leitlinien:

1. Publikation offen lizenzierter Daten zur freien Nutzung

2. Nutzung domänenübergreifender Web-Standards

3. Bereitstellung von Web-APIs plus Endnutzeroberflächen

Datenquellen und -formate

lobid-resources: ETL-Prozess

Dokumentation

API-Dokumentation

MAB nach RDF

Morph-Datei

2. Struktur & Darstellung

Wie sollen die neuen Systemstellen in die bestehende Raumsystematik eingegliedert werden?

Fragen

Sollen Stadtbezirke angezeigt werden?

Soll die jeweilige Treffermenge angezeigt werden?

Sollen die kirchlichen Gebieten hierarchisiert werden?

Was ist mit der Euregio?

Gibt es weitere zu klärende Fragen?

Diskussion am Beispiel des Prototyps

3. Wikidata als Infrastruktur

Wikidata

Eine Knowledge Base

Ein Wikimedia-Projekt

Strukturierte Daten

Multilingual

Kollaborativ

CC0

Basierend auf Aussagen und Referenzen

Für Menschen und Maschinen

Wikidata-Statistiken

Über 54 Millionen Einträge (Entwicklung)

30-40.000 aktive Editoren pro Monat (2018, Quelle)

Ungefähr 3,5 Millionen SPARQL-Anfragen pro Tag (2018, Quelle)

Mehr Informationen und Links: Wikidata-Statistik-Seite

Wikidata-Datenmodell I

Wikidata-Datenmodell II

Eigenschaften und Klassen sind editierbar wie alle anderen Einträge auch

Vorschlagen neuer Eigenschaften und Abstimmungsprozess

Eigenschaftseinschränkungen

"Einschränkungen sind Hinweise, keine harten Einschränkungen, und sie sind als Hilfe oder Führung für den Bearbeiter gedacht." (Quelle)

Beispiel: Beschränkungen der Eigenschaft "GND"

Identifikatoren

Momentan mehr als 3.500 externe Identifikatoren enthalten

Vorschläge für Normdaten-Properties

4. Status: Übergangsphase

From strings to things

Zunächst Matching existierender Text-Strings auf Wikidata

Dann: Erweiterung der Systematik mit den gewonnenen kontrollierten Werten & hbz01-Update

Ziel: Erfassung von Systematik-IDs in der täglichen Katalogisierung

Matching-Verfahren

Extraktion der relevanten Wikidata-Einträge (Orte in NRW verschiedenen Typs) mittels SPARQL

Indexierung der Einträge mit Ansetzungs-, Verweisungsformen, Name der übergeordneten Einheit und Typ

Matching der GSW aus 700n gegen den Index

Außerdem: Liste manuell gematchter GSW

Stand des Matchings (23.01.2019)

300.535 von 301.697 Einträgen mit den Notationen 99, 97, 96,36, 35 und einem GSW sind gematcht. Das sind 99,6%.

1162 Titel ohne Wikidata-Match, Liste der nicht gematchten 23 GSW

Mit ein paar Wikidata-Anpassungen kommen wir leicht auf <50 nicht-gematchte Strings/Titel

Stand der Systematikdarstellung

Siehe den Prototyp unter https://test.nwbib.de/classification?t=Raumsystematik

Wird generiert aus den lobid-Daten

Trefferzahlen sind jeweils aktuell

Aktualisierung der Labels ist in der Übergangsphase umständlich und derzeit nicht aktuell

Ansonsten sieht es schon gut aus, ist aber instabil

Maßnahmen zum Änderungsschutz (s.u.) werden existierende Probleme beheben

Ziel: Raus aus der Übergangsphase, hin zu einem stabilen System!

5. Aktualisierung der Aleph-Daten

Verfahren und Dauer

Dauer der Batch-Anpassung im Verbundsystem etwa zwei bis drei Monate inklusive Vorbereitung

Frage: Müssen auch die Lokalssysteme aktualisiert werden? (Dann dauert es deutlich länger.)

lobid-Team spezifiziert Anpassungsbedarf, Verbundgruppe aktualisiert die Titel

Fragen zur Umsetzung

Gibt es irgendeinen Grund, die alten GSW in Aleph anstatt in einer externen Datei aufzuheben?

Was wird konkret in Aleph erfasst? – Vorschlag: IDs + Ortsansetzung

Beispiel: Vorher

<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">20</subfield>
</datafield>
<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">99</subfield>
  <subfield code="b">Duisburg</subfield>
</datafield>
<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">99</subfield>
  <subfield code="b">Essen</subfield>
</datafield>
<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">768010</subfield>
</datafield>

Nachher?

<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">20 | Ruhrgebiet</subfield>
</datafield>
<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">9Q2100 | Duisburg</subfield>
</datafield>
<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">9Q2066 | Essen</subfield>
</datafield>
<datafield tag="700" ind1="n" ind2="1">
  <subfield code="a">768010 | Einzelne Autoren (Primärliteratur)</subfield>
</datafield>

(Eventuell sollten wir die Sachnotationen erst einmal außen vor lassen...)

6. Maßnahmen zum Änderungsschutz

Mögliche Probleme der Wikidata-Nutzung

Vandalismus, inkorrekte Anpassungen (bei der Typisierung, Ortshierarchien etc.)

Downtime

Eine eigene, unabhängige, versionierte Version der Systematik ist sinnvoll

Wie setzen wir das am besten um?

Vorschlag

Erweiterung der existierenden Raumsystematik in SKOS um die neuen Systematikstellen aus Wikidata

Einrichtung einer NWBib-Eigenschaft in Wikidata (zum Verlinken auf Systematikstelle und Suchergebnisse)

Monitoring von Wikidata bzw. regelmäßiger Abgleich (und womöglich Wikidata-Korrekturen)

Sämtliche raumklassifikatorischen Funktionen in nwbib.de basieren auf der SKOS-Datei

Wikidata sollte primäres System der Systematikpflege bleiben!

Beispiel

<http://purl.org/lobid/nwbib-spatial#n9Q7924>
  a skos:Concept ;
  skos:inScheme <http://purl.org/lobid/nwbib-spatial> ;
  skos:prefLabel "Regierungsbezirk Arnsberg"@de ;
  foaf:focus <http://www.wikidata.org/entity/Q7924> ;
  skos:broader <http://purl.org/lobid/nwbib-spatial#n9> ;
  skos:narrower <http://purl.org/lobid/nwbib-spatial#9Q1295> ;
  skos:notation "9Q7924" .

<http://purl.org/lobid/nwbib-spatial#9Q1295>
  a skos:Concept ;
  skos:inScheme <http://purl.org/lobid/nwbib-spatial> ;
  skos:prefLabel "Dortmund"@de ;
  foaf:focus <http://www.wikidata.org/entity/Q1295> ;
  skos:broader <http://purl.org/lobid/nwbib-spatial#n9Q7924> ;
  skos:narrower .... ;
  skos:notation "9Q7924" .

<http://purl.org/lobid/nwbib-spatial#n9>
  a skos:Concept ;
  skos:inScheme <http://purl.org/lobid/nwbib-spatial> ;
  skos:prefLabel "Regierungsbezirke, Kreise, Orte. Euregio"@de ;
  skos:narrower <http://purl.org/lobid/nwbib-spatial#n9Q7924;
  skos:notation "9" .

7. Katalogisierung nach der Erweiterung

Prozess

Erfassung im Aleph-Client

Werte für 700n werden in administrativer Sicht im Browser gesucht

Kopieren per Mausklick und Einfügen in 700n im Aleph Client

Neuanlage

Falls keine passende Systematikstelle in SKOS-Systematik vorhanden

Ergänzung durch Anlage einer neuen Wikidata-Aussage mit NWBib-Eigenschaft

Festlegen der Notation in Wikidata?

Wikidata-Monitoring und Synchronisation

Stetige Überwachung der NWBib-Eigenschaft (Löschung, Neuvergabe)

Regelmäßige Generierung der SKOS-Systematik aus Wikidata und Kontrolle der Diffs

Ggf. Anpassung in Wikidata

Aktualisierung der SKOS-Datei

Raus aus der Übergangsphase, hin zu einem stabilen System!