Closed fsteeg closed 1 year ago
Für die 4 Punkte oben machen wir hier vielleicht mal einen Cut, grundsätzlich scheint es mit Alma-Daten so zu funktionieren (s. auch https://github.com/hbz/nwbib/issues/604). Probleme mit eigenen Tickets gibts noch rund um OPAC-Links (https://github.com/hbz/nwbib/issues/605) und Überordnungen (https://github.com/hbz/lobid-resources/issues/1705).
Letzteres zeigt eine Schwierigkeit beim Testen des zukünftigen Alma-only-Zustandes: die Daten linken auf Produktiv-URIs, die ja noch auf Aleph-Basis laufen. D.h. wenn man sich so durchklickt landet man immer wieder auf Produktiv-Varianten. Wir könnten in einem separaten Ticket ev. versuchen, das überall zu ersetzen, sollten uns aber dennoch darauf einstellen, dass wir manches erst nach dem echten Switch sehen.
Ich denke so könnten wir das schonmal zur Begutachtung an die Redaktion geben, ev. mit Hinweisen auf bekannte Probleme (wie die oben erwähnten OPAC-Links und Überordnungen bzw. das beschriebene Rausspringen vom Test- ins Produktivsystem).
Sieht gut aus und kann meinetwegen deployt werden.
Eine Sache werden wir noch anpassen müssen (gerne in einem anderen Ticket):
Momentan wird der Publikationsort nicht angezeigt [...] Am einfachsten wäre es, wenn wir die gleiche Darstellung wie in der aktuellen NWBib wählten
Hab ich angepasst für publication.location
und publication.publishedBy
, die jetzt Arrays sind: https://test.nwbib.de/99371528079806441
Ich habe Zweifel, ob die NWBib-Redaktionen es für sinnvoll halten, dass mit Klick auf den Verlag eine Körpderschaftssuche gestartet werden kann
Das scheint hier vom publication
-Feld unabhängig zu sein, der Verlag kommt tatsächlich als CorporateBody
in contribution.agent
rein: http://test.lobid.org/resources/99371528079806441.json
kann meinetwegen deployt werden
Für Alma-Daten haben wir ja aktuell nur ein System, https://test.nwbib.de. Aber dann könnten wir jetzt vielleicht an die Redaktion übergeben?
+1
hasItem.heldBy.id
)fulltextOnline
hat)