Speichern und Zugänglichmachen eine hbzID-GSW-Snapshots

[acka47]

Wie im Januartreffen besprochen, müssen wir den letzten Stand der GSW-hbzID-Zuordnung

• [x] speichern (und archivieren)
• [x] und der NWBb-Redaktion eine simple Oberfläche zur Abfrage zur Verfügung stellen.

[fsteeg]

Geht es hier im Grunde um das File aus https://github.com/hbz/nwbib/issues/464?

Ist das Thema hier in dem Kontext daher auch grad aktuell?

[acka47]

Geht es hier im Grunde um das File aus #464?

Nein, es geht darum, die Strings zu speichern, die mit dem File aus #464 überschrieben werden, das sind im Prinzip die Werte, die sich bei lobid-resources im coverage-Feld befinden. Wir müssen also die alten Werte speichern, bevor mit dem Update von hbz01 begonnen wird, sprich Ende November.

[acka47]

Die Speicherung sollte am Ende der Woche erfolgen, denn am Donnerstag wird

1. die Katalogisierung umgestellt, d.h. es werden keine GSW mehr katalogisiert und
2. werden wir die Update-Datei an die Verbundgruppe schicken (#464), so dass die hbz01 evtl. schon ab dem kommenden Wochenende aktualisiert wird.

[acka47]

@dr0i, for fetching a dump of the NWBib data in lobid please run the following command:

$ curl --header "Accept-Encoding: gzip" "http://lobid.org/resources/search?q=inCollection.id%3A%22http%3A%2F%2Flobid.org%2Fresources%2FHT014176012%23%21%22&format=jsonl" > nwbib-2019-12-05.gz

[dr0i]

Snapshot fertig, inklusive den originären MabXmlClobs:

hduser@weywot1:/data/DE-605/mabxml/snapshotNwbib$ l
drwxr-xr-x 2 hduser hadoop 4,0K Dec  5 10:17 .
drwxr-xr-x 6 hduser hadoop 4,0K Dec  5 10:06 ..
-rw-r--r-- 1 hduser hadoop  11G Dec  5 10:08 DE-605-aleph-baseline-marcxchange-20191130.tar.gz
-rw-r--r-- 1 hduser hadoop 463K Dec  5 10:16 DE-605-aleph-update-marcxchange-20191130-20191201.tar.gz
-rw-r--r-- 1 hduser hadoop  23M Dec  5 10:16 DE-605-aleph-update-marcxchange-20191201-20191202.tar.gz
-rw-r--r-- 1 hduser hadoop  28M Dec  5 10:16 DE-605-aleph-update-marcxchange-20191202-20191203.tar.gz
-rw-r--r-- 1 hduser hadoop  25M Dec  5 10:16 DE-605-aleph-update-marcxchange-20191203-20191204.tar.gz
-rw-r--r-- 1 hduser hadoop  41M Dec  5 10:16 DE-605-aleph-update-marcxchange-20191204-20191205.tar.gz
-rw-r--r-- 1 hduser hadoop 228M Dec  5 10:14 nwbib-2019-12-05.gz

It's mirrored at weywot2.

[acka47]

Ich schiebe das erstmal in den Backlog. Wenn eine Anfrage von der Redaktion kommen sollte, dass sie auf den Snapshot zugreifen wollen, dann überlegen wir, wie wir das umsetzen.

[acka47]

Da es nur um die überschriebenen 700n-Daten geht, sollten auch nur diese – verknüpft mit der jeweiligen hbz-ID – durchsuchbar gemacht werden. Derzeit gibt es zwei Use Cases, die schonmal abgedeckt sein müssen:

1. Abgleich der Snapshot-Einträge mit "Siebengebirge" in 700n gegen die jetzigen Einträge mit "Siebengebirge" in spatial. Das heißt, ich muss eine Liste mit hbz-IDs aus der Anwendung bekommen, die ich mit eine entsprechenden Liste aus den aktuellen Daten abgleichen kann.
2. Rückgabe aller hbz-IDs zur Query mettmann AND kreis AND NOT Düsseldorf, um #514 zu bearbeiten. (Idealerweise kann ich nach "Mettmann" suchen und bekomme eine Ergebnisliste, mit den hbz-IDs und dem jeweiligen Snippet, dass der Suchanfrage entspricht, um zu sehen, ob es sich auf den alten oder neuen Kreis bezieht.)

[acka47]

Ein weiterer Use Case aus eine E-Mail von U.P. vom 2019-12-05:

wir sind jetzt über das Register der Notationen in hbz01 auf einige Fehler aus der Vergangenheit gestoßen, als z.B. der Ort in 700n ohne das einleitende $a 99 oder ein GSW ohne die einleitende Notation eingegeben wurde, z.B.

HT019001149

HT004542399

Die Kolleg*innen sollten in der Lage sein, auch diese Feldinhalte zu durchsuchen.

[dr0i]

Branch heißt nwbib-467-snapshotDurchsuchen. Die Oberfläche: http://nwbibsnapshot.lobid.org/resources/search?q=mett*. Die Aggregationen funktionieren hier nicht. Der Index heißt resourcesnwbibsnapshot-staging und lässt sich aus dem internen Netz direkt abfragen. Z.B. Aggegationen:

 curl -XGET 'http://weywot4.hbz-nrw.de:9200/resourcesnwbibsnapshot-staging/resource/_search?q=mettmann' -d '
{
  "size": 0,
  "aggs": {
    "group_by_state": {
      "terms": {
        "field": "spatial.700n1b"
      }
    }
  }
}'

[acka47]

Das sieht doch schonmal sehr gut aus. Zwei Dinge hätte ich gerne noch, wenn es sich leicht umsetzen lässt:

1. Anzeige der hbz-ID in der Trefferliste links neben jedem 700n-Wert.
2. Filtern beim Klick auf eine Facette

@fsteeg, schaust du mal, ob das mit wenig Aufwand umzusetzen ist? Ansonsten lassen wir es erstmal so.

[fsteeg]

@fsteeg, schaust du mal, ob das mit wenig Aufwand umzusetzen ist? Ansonsten lassen wir es [..] so.

Hab die hbz-IDs ergänzt in der Trefferliste und die nicht funktionierenden Sortieroptionen rausgenommen. Um die Facetten-Links zu fixen wäre wohl was mehr Aufwand nötig. Habe stattdessen umgestellt, dass das keine Links mehr sind, und eine 700n1a-Facette zusätzlich zur 700n1b ergänzt.

Habe in nwbib-467-snapshotDurchsuchen gepushed, könntest du das nochmal deployen, @dr0i?

[dr0i]

Deployed. Re aggregationen: Gibt es eine Möglichkeit für den ajax-call in "facets.scala.html" an das label zu kommen? Weil, das field und das q ist ja da, und so könnte dann ein Facettenlink zusammengebaut werden ala search?q=mett* AND spatial.700n1b:"Mettmann <kreis>". Somit müsste nicht extra ein Suchparameter wie t, subject usw. implementiert werden. Zugegeben, es wäre auch nur eine Facette auswählbar, aber das wäre glaub ich ok.

[fsteeg]

Gibt es eine Möglichkeit für den ajax-call in "facets.scala.html" an das label zu kommen?

Die Links werden/wurden ja in Application.facets zusammengebaut. Das liesse sich sicher machen, das da dranzuhängen und den anderen Kram rauszunehmen, aber es wäre eben schon ein wenig Aufwand. Ich hatte Adrian vorhin hier so verstanden, dass es nicht so sinnvoll ist hier jetzt gerade weiter dran zu arbeiten (z.B. weil wir die Oberfläche vielleicht erstmal nur selber nutzen).

Hier nochmal ein Link zum aktuellen Stand: http://nwbibsnapshot.lobid.org/resources/search?q=mett*

[dr0i]

Ja, war nur so eine Interessensfrage. Es könnte IMO auf eine Änderung in Application.facets verzichtet weren und alles via die AJAX-URL gemacht werden, wenn ich mich recht erinnere - wenn es da Zugriff auf das label gebe in der facets.scala.html. Ich checke mal oben das Kästchen "Oberfläche bereitstellen".

[acka47]

+1 Wir können das erstmal schließen und werden es nur nochmal anfassen, wenn wirklich Bedarf ist.

[dr0i]

Sorry guys for accidentally deleting the index. Back again, see http://nwbibsnapshot.lobid.org/resources/search?q=spatial.700n1b%3A(%22Werne%22+AND+NOT+%22Bochum%22).

[dr0i]

Note: I've removed the index now as discussed.