Skip to content

Status: Wikidata Matching

Jump to bottom Edit New page
Adrian edited this page Jan 23, 2019 · 61 revisions

Inhalt

Kurze Handreichung zur Suche nach GSW und Wikidata-Links in lobid-resources

Zunächst sollen hier kurz die notwendigen Kenntnisse vermittelt werden, um selbst ein wenig die der NWBib zugrundeliegenden lobid-Daten abfragen und untersuchen zu können. Zur eigenständigen Analyse kann einfach die jeweilige Suchanfrage im lobid-resources-Suchfeld unter https://lobid.org/resources eingegeben werden.

Suche nach Titeln mit einem bestimmten GSW

GSW stehen im Feld coverage zusammen mit der Notation, zu der sie vergeben wurden. Siehe z. B. das JSON des Titels HT016002058 (zur besseren Ansicht von JSON im Browser empfiehlt sich die Installation einer Browser Extension wie JSONView für Firefox oder JSON Formatter für Chrome):

{
  "id":"http://lobid.org/resources/HT016002058#!",
  "coverage":[
    "Graefenthal <Goch> | 99"
  ]
}

Die Suche nach allen Titeln mit einem bestimmten GSW sollte somit über das Feld coverage mit einer Phrasensuche erfolgen, z.B. coverage:"Graefenthal <Goch>".

Ansicht des verlinkten Wikidata-Eintrags

Momentan zeigen wir die Wikidata-Verlinkung nicht im HTML an, so dass dafür im JSON nachgeschaut werden muss, und zwar unter dem Feld spatial, wo man im Feld 'label' die Vorzugsbezeichnung und unter id die URI des Wikidata-Eintrags findet. Siehe z.B. HT017710082:

{
  "id":"http://lobid.org/resources/HT017710082#!",
  "spatial":[
    {
      "id":"http://www.wikidata.org/entity/Q6916",
      "label":"Herzogenrath",
      "geo":{
        "lat":50.866666666667,
        "lon":6.1
      },
      "type":[
        "http://www.wikidata.org/entity/Q54935786",
        "http://www.wikidata.org/entity/Q262166"
      ]
    }
  ]
}

Anmerkung: lobid-resources beinhaltet die ganzen hbz-Verbunddaten. Allerdings finden sich die Informationen zu GSW und verlinkten Orten in Wikidata (i.e. die Felder coverage und spatial) nur bei NWBib-Titeln , so dass eine entsprechende Anfrage nicht explizit auf das NWBib-Set eingeschränkt werden muss. Falls für andere Anfragen eine solche Einschränkung nötig ist, sieht diese wie folgt aus: inCollection.id:"http://lobid.org/resources/HT014176012#!". Zum vertieften Verständnis der Abfragemöglichkeiten von JSON-Daten in Elasticsearch siehe auch den Beitrag zu lobid-gnd "Formulierung komplexer Suchanfragen".

Suche nach Titeln mit fehlender Wikidata-Verlinkung

Es lassen sich recht komplexe Anfragen mit lobid-resources generieren, z.B. nach allen Titel in der NWBib mit GSW zu den Notationen 35, 36,96, 97 oder 99 aber ohne Wikidata-Verlinkung. Hier kommt uns die _exists_-Abfrage zur Hilfe: inCollection.id:"http://lobid.org/resources/HT014176012#!" AND coverage:(99 OR 97 OR 96 OR 36 OR 35) AND NOT _exists_:spatial

Übersicht: Textstrings nach Notation

Die folgende Übersicht beinhaltet alle Notationen, bei denen zusätzlich auch "gliedernde Schlagwörter" (GSW) vergeben werden. Sie gibt folgende Informationen (Stand: März 2018):

  • wie viele Titel sind mit der jeweiligen Notation versehen ("Titel mit Notation")
  • wieviele Titel die Notation und ein GSW besitzen ("Titel mit zusätzlichen GSW")
  • welche distinkten Strings als GSW vergeben sind ("enthaltene Textstrings").
  • ob die GSW automatisch ("a") oder manuell ("m") oder gar nicht ("n") auf Wikidata-Entitäten gematcht werden.

Die Informationen sind jeweils mit Links zu den jeweiligen Titeln bzw. einer Liste der GSW versehen.

Notation Content Titel mit Notation Titel mit zusätzlichen GSW enthaltene Textstrings a/m/n
99 Städte, kreisfreie Städte, Gemeinden, Ortsteile plus teilweise Stadtbezirke und leider auch andere wie z.B. Klöster etc. 276139 276139 hier a
97 Kreise 14368 14429 hier a
96 Regierungsbezirke 1562 1565 hier a
74 Kleinere weltliche Territorien in Westfalen 534 515 hier m
72 Kleinere geistliche Territorien in Westfalen 41 39 "Hochstift Corvey" (38), "Höxter" (8), "Corvey" (2), "Herford (Reichsstift)" (1) m
54 Kleinere weltliche Territorien im Rheinland 130 109 hier m
52 Kleinere geistliche Territorien im Rheinland 51 37 "Stift Essen" (26), "Kloster Werden" (6), "Reichsabtei Kornelimünster" (4), "Reichsabtei Burtscheid" (2) m
37 Katholische Kirche. Dekanate 28 28 hier n
36 Katholische Kirche. Diözesen 1993 1969 hier a
35 Evangelische Kirche. Kirchenkreise 212 200 hier a
28 Eifel 2715 688 "Nordeifel" (389), "Hohes Venn" (130), "Monschauer Land" (76), "Rureifel" (52), "Kalkeifel (33), "Mechernicher Voreifel" (13), "Kalterherberg" (1), Eifel" (1) m
24 Niederrhein-Gebiet 6333 1259 hier ?
14 Sauerland 3173 512 hier n
12 Weserbergland 1850 1469 hier ?
10 Westfälische Bucht 4521 4313 hier n

Kein Matching

Für die Notationen 10, 14, 37 scheint ein Matching nicht sinnvoll, weil entweder überhaupt zu wenige GSW mit der Notation vergeben wurden (37) oder es sich um Einheiten handelt, die teilweise nicht in Wikidata auftauchen.

Manuelles Matching

Bei einigen Notationen (28, 52, 54, 72, 74) werden nur wenige unterschiedliche Textstrings bei den GSW verwendet, so dass ein manuelles Matching sinnvoll ist. Das Matching wurde auch teilweise bereits vorbereitet, siehe https://github.com/hbz/lobid-resources/issues/764#issuecomment-373403493 ff.

Status: umgesetzt, siehe https://github.com/hbz/lobid-resources/issues/880

Automatisches Matching

GSW der Notationen 35, 36, 96, 97, 99 werden automatisch gematcht. Das Verfahren ist hier beschrieben.

Ergebnis

Matching erfolgt

Kein Matching erfolgt

Qualität des erfolgten Matchings

Wir gehen davon aus, dass der allergrößte Teil der Matchings korrekt ist. Ab einem Matching Score von weniger als 35 Punkten finden sich allerdings zweifelhafte Matchings, so dass hier auch einmal geschaut werden muss und evtl. Anpassungen an Wikidata und/oder den Aleph-Daten vorgenommen werden müssen. Hier sind die 25 (Stand 2018-10-02) Strings mit einem Score von weniger als 35 Punkten (Quelle):

17 Heddinghausen  Preußisch Oldendorf|99 ,26.855623,Q798710
 3 Petershagen Gernheim|99 ,24.489777,Q2042265
 2 Klein Vernich|99 ,24.148233,Q1319918
 3 Herne Holsterhausen|99 ,23.69178,Q834265
 8 Holsterhausen  Herne|99 ,23.69178,Q834265
35 Förde  Lennestadt|99 ,22.672707,Q1546105
31 Burbach  Siegen Wittgenstein|99 ,22.481035,Q1625527
 2 Senne II|99 ,22.469162,Q2271193
 6 Ober Rödinghausen|99 ,22.012714,Q1661576
 1 Kreuztal Langenau|99 ,21.8439,Q1017351
 2 Langenau  Kreuztal|99 ,21.8439,Q1017351
72 Altena  Westf|99 ,20.008686,Q1157435
 1 Nordhagen|99 ,19.314178,Q257474
 1 Sudhagen|99 ,19.314178,Q257474
12 Gernheim|99 ,18.353443,Q2042265
 1 Liemke|99 ,18.353443,Q2244792
 2 Kleusheim|99 ,18.24863,Q437316
 3 Velpe|99 ,18.24863,Q2512628
 7 Bielefeld Gadderbaum|99 ,17.531101,Q23559794
 2 Eßhoff|99 ,15.024708,Q1368836
 9 Großburlo|99 ,11.652989,Q23835486
 1 Behringhausen|99 ,11.643241,Q151243
11 Hasslinghausen|99 ,11.643241,Q1592134
 7 Kirchende|99 ,9.887161,Q1506575
11 Gadderbaum|99 ,8.527262,Q23559794

Fehlerursachen

Die Ursache von Nicht- oder Fehl-Matchings ist zumeist, dass die entsprechende Einheit nicht (mehr) eine von den administrativen Einheiten ist, die für das Matching von Wikidata geholt werden (Regierungsbezirk, Landkreis (auch preußisch), kreisfreie Stadt, Gemeinde, Ortsteil, Stadtteil von Düsseldorf oder Köln) oder dass es schlicht keinen entsprechenden Wikidata-Eintrag gibt. Im folgenden einige Beispiele:

Stadtbezirke

Teilweise sind als GSW zu Notation "99" Namen von jetzigen Stadtbezirken eingetragen, die aber nicht Teil des Matching-Indexes sind. Folglich kommt es zu Nicht- oder Fehl-Matchings. "Dortmund-Nord" wird etwa gar nicht gematcht und es gibt folgende Fehl-Matchings:

Klöster

Teilweise stehen als GSW zu "99" Namen von Klöstern, die ebenfalls nicht im Matching-Index sind.

Burgen & Schlösser

Teilweise stehen als GSW zu "99" Namen von Burgen oder Schlössern, die ebenfalls nicht im Matching-Index sind. Beispiele:

Bauernschaften

Wohnplätze etc.

Kein Wikidata-Eintrag

Manche Ortsteile sind noch nicht in Wikdata verzeichnet.

  • "Sevelen " und "Issum-Sevelen" (Issum ist vorhanden: https://www.wikidata.org/wiki/Q243337)
  • Sennelager-Thune (Sennelager gibt es: https://www.wikidata.org/wiki/Q883649)
  • Mönchengladbach-Hermges
  • Hagen-Nahmer
  • "Arrode <Werther, Westfalen>" bzw. "Werther-Arrode"
  • Kirchlinde
  • Heiligenhaus-Hofermühle
  • Remscheid-Bliedinghausen
  • Köln-Hohenlind
  • Rahm
  • Mönchengladbach-Geistenbeck
  • Hagen-Halden
  • Gerlingen <Wenden, Olpe>
  • Esbeck
  • Barendorf
  • Anröchte-Klieve
  • Herscheid-Kiesbert
  • Hagen-Oege

Inkorrekte Notationen

Einige Fehlmatchings entstehen auch durch inkorrekte Notationen in den Aleph-Daten. Da wir Kreise auf Kreise matchen, gibt es Fehler bei Eintragungen eines Kreises mit einer anderen Notation als 97. Hier eine Liste dieser Fälle (Quelle ist http://stats.lobid.org/scoreCoverageCsv_alleWerte.csv):

  • "Rhein Erft Kreis |99" ist gematcht mit Q3989 (Bergheim) anstatt Q6292 (Rhein-Erft-Kreis)
  • "Mettmann Kreis |99" ist gematcht mit Q14878 (Mettmann) anstatt Q6257 (Kreis Mettman)
  • "Kreis Wesel |99" gematcht auf Q4011 anstatt Q6245
  • "Kreis Viersen |99 " und "Viersen Kreis |99" ist gematcht mit Q3902 anstatt Q6249
  • Weitere Kreise in Notation 99: "Kleve Kreis |99" , "Kreis Kleve |99 ", "Kreis Heinsberg |99 ", "Rhein Kreis Neuss |99 ", "Ennepe Ruhr Kreis |99 ", " Rhein Sieg Kreis |99 ", "Märkischer Kreis |99 "

Sonstige Nicht-Matches

Weiteres Vorgehen

Ziel

Bevor Möglichkeiten für das weitere Vorgehen genannt werden, sollen zunächst noch einmal die Ziele genannt werden. Laut dem Konzept gibt es folgende Ziele:

  • hierarchische Darstellung der Raumnotationen nach Regierungsbezirken, Kreisen, Orten und Ortsteilen (entsprechend der Verwaltungsstruktur in NRW)
  • keine Mehrfacheintragungen und Zusammenführung von Titeln zu einem Ortsteil vor und nach der Eingemeindung

Konkret bedeutet dies als Endergebnis:

  1. In Aleph werden keine Textstrings mehr verwendet, sondern ausschließlich NWBib-Notationen sowie QIDs (=Wikidata-IDs).
  2. Auf Basis der vorhandenen IDs wird eine hierarchische Repräsentation der Systematik angeboten (Prototyp für die Notationen 96, 97, 99)

Für das Erreichen des Ziels müssen technisch folgende Dinge umgesetzt werden:

  1. Alle GSW müssen in Aleph durch QIDs ersetzt oder gelöscht werden.
  2. Ein Verfahren zur leichten Übernahme von QIDs für die Katalogisierung muss existieren (siehe https://github.com/hbz/nwbib/issues/399)

Offene Fragen

Bisher ging es in der Diskussion meist nur um GSW der Notationen 96, 97, 99. Es muss geklärt werden, wie mit GSW - anderer Notationen umgegangen werden soll.

Verfahrensvorschlag

Es sollten möglichst alle GSW durch QIDs ersetzt werden, um das Projekt abzuschließen und nicht noch länger hinzuziehen. Folgende Aufgaben müssten erledigt werden:

  1. NWBib-Redaktion: Entscheidung zum Umgang mit GSW aus anderen Notationen als 96, 97, 99. Wenn Matching erwünscht, dann Kontrolle der Vorschläge zum manuellen Matching unter https://github.com/hbz/lobid-resources/issues/764#issuecomment-373403493 ff.
  2. hbz: Umsetzen des manuellen Matchings
  3. NWBib-Redaktion: Um Nicht- und Falsch-Matchings bei der automatisierten Variante wenn nicht auszuschließen, so doch zu minimieren, müssen neue Wikidata-Artikel angelegt sowie GSW in Aleph bereinigt/korrigiert werden. Frau Niemann und Frau Pflughaupt haben hier bereits einiges auf Wikidata (siehe hier und hier) und in Aleph geleistet. Einige wichtige Punkte/Fragen:
  4. hbz: Um den Fortschritt zu dokumentieren und um zu erkennen, wann ein Umstieg bei der Katalogisierung stattfinden kann, sollten regelmäßig aktualisierte Statistiken zu Nicht- und Falschmatchings geliefert werden.
Add a custom footer
Add a custom sidebar
Clone this wiki locally