| | | |
|---|
Allgemeines | Alle | Wiedervorlage: @Christin Seegert gibt den Vorsitz von D-MM auf, da sie aufgrund eines Stellenwechsels den Arbeitsbereich Folio verlässt. @Regina Hartwigsen bleibt Stellvertretung und übernimmt die Organisation der Sitzung im Dezember. Alle Teilnehmer:innen werden gebeten, zu prüfen, ob sie den Vorsitz übernehmen möchten. Ggf. könnten zwei Co-Vorsitzende sich die Arbeit auch teilen. @Felix Hemme bespricht sich zum Thema bilateral mit @Regina Hartwigsen .
| |
Signaturen-dubletten-kontrolle | Alle | Nachfrage @Felix Hemme : Es gab die Frage, ob es eine Seite gibt, auf der dieses Thema als Diskussionsthema in die SIG eingebracht werden kann. In MM haben wir dazu https://folio-org.atlassian.net/wiki/spaces/MM/pages/4667860/MM+SIG+Parking+Lot#MMSIGParkingLot-NEWMMimplementationtopics,questionsorissues. In der Regel werden Themen zur Diskussion jedoch direkt an Raegan Wiechert und/oder mich gemeldet und wir übernehmen die Koordination, um z. B. dafür zu sorgen, dass die notwendigen POs zur Sitzung informiert und eingeladen werden. Der Abgleich auf alle Felder des effectiveCallNumber-Objekts und der numberOfPieces bei jedem Anlegen und Speichern eines Holdings und Items klingt erstmal nicht ohne, was die Performanz angeht. Über mod-search kommt man mit der aktuellen Implementierung nicht an numberOfPieces, weshalb man direkt in mod-inventory-storage abfragen müsste. Dort ist alles notwendige enthalten:
"effectiveCallNumberComponents": {
"callNumber": "Signatur im Holdings",
"prefix": "Präfix im Holdings",
"suffix": "Suffix im Holdings",
"typeId": "6caca63e-5651-4db6-9247-3205156e9699"
},
"numberOfPieces": "Anzahl der Teile im Item",Bei einer Diskussion in der MM SIG sollten dabei sein: Ryan Taylor: PO für ui-inventory (das neue Modal) und mod-inventory (die Business Logic, die auf die Dubletten prüfen würde) Christine Schultz-Richert: PO für mod-inventory-storage und mod-search (für die Abfrage nach Dubletten bei jedem Speichern und wogegen diese Anfrage am besten laufen sollte)
Exkurs MM SIG: Der PCC hat alle SIGs dazu aufgefordert, eine Priorisierung für ihren Arbeitsbereich aufzustellen. Dazu werden Jira-Tickets mit dem Tag metadatamanagement versehen, sodass auf einen Blick erkannt werden kann, welche Tickets, die von der MM SIG hoch gevotet wurden, noch nicht in Entwicklung sind.
| |
Katalog App / Buchnummer-Suche | @Heiko Schorde / hebis | In der Katalog App ist als Default die Instanzsuche gesetzt und der Suchindex auf "Stichwort" gestellt. Darin ist die Buchnummer nicht enthalten.
Häufig bis meistens wird nach der Buchnummer gesucht werden. Bei gedruckten Medien ist diese einfach und schnell zugänglich.
Entweder man wechselt dazu im Suchindex auf "Alle" oder man wechselt zur Exemplarsuche und stellt "Barcode" ein.
Beide Varianten sind etwas umständlich. Nutzt man die Funktion "Alles zurücksetzen" kann man das erneut machen. Es wäre gut, wenn die Suche nach der Buchnummer einfacher zugänglich wäre. Kann vielleicht der Suchindex "Alle" als Default gewählt werden? Oder kann die Buchnummer in den Index "Stichwort" aufgenommen werden?
Das ist sicher nicht dringend, würde aber die alltägliche Arbeit erleichtern. Anmerkung @Felix Hemme : Während einer Session auf der WOLFcon 2024 wurde eine Live-Umfrage durchgeführt, welche Verbesserung die vor Ort und remote Anwesenden TN gerne sehen würden, s. https://folio-org.atlassian.net/wiki/x/lQD0Hg. Dabei wurde “Add barcode to keyword search” als Nr. 1 gerankt.  Es gibt auch schon zwei Jira-Tickets für diesen Wunsch: Ich gehe davon aus, dass wir diese Verbesserung bald in der Entwicklung sehen. Die Default-Suche auf “Alle” umzustellen halte ich für nicht umsetzbar, da die Suche nach allen Feldern gezielt in mod-search aktiviert werden muss, s. https://github.com/folio-org/mod-search?tab=readme-ov-file#search-by-all-field-values. Außerdem ist sie, entgegen der Stichwortsuche, nicht optimiert. Für die Aufnahme in den Stichwort-Index würde auch sprechen, dass dieser weniger fehleranfällig ist, was aus Versehen mit kopierte White Spaces betrifft.
| |
“Autocomplete” für Item-Daten | @Felix Hemme | In letzter Sitzung als Idee von Alexander Prüfling angesprochen und von an Anwesenden TN als sehr spezifisch bewertet. Hinweis, dass es (alte) Tickets zur Erstellung von Vorlagen (Templates) für Inventory-Datensätze gibt: Die Vorlagen sollen in den Einstellungen erstellt werden können. Die Funktion gibt es schon in der Orders-App. Dazu müsste man während der Erstellung eines neuen Datensatzes die Vorlage auswählen, was die gewünschten Felder dann mit Werten vorbelegen würde und bei Bedarf auch Felder ausblenden würde, die für diesen Typ Datensatz nicht benötigt werden. @Regina Hartwigsen und @Alexander Prüfling verfolgen das Thema BVB-intern weiter. Dabei ist zu bedenken, dass eine solche Funktionalität im Zweifelsfall schon in der Inventarisierungs-App hinterlegt sein müsste.
| |
Entfernen von Whitespaces in den Inventory-Daten | @Felix Hemme | Rückmeldung zu Thema von Andrea: Ja, das ist momentan echt schlecht gelöst und ist (hauptsächlich US-)Bibliotheken, die bereits live sind, auch aufgefallen. Es gibt deshalb das Ticket Inventory: Strip leading, trailing, and double spaces out of data in some elements (instance, holdings, item) (https://folio-org.atlassian.net/browse/UXPROD-3473), was bereits mehrfach in der SIG besprochen wurde. Das Thema ist komplexer als man auf den ersten Blick vermutet. Die SIG konnte sich in Zusammenarbeit mit der zuständigen PO Christine Richert-Schultz darauf einigen, dass zu Beginn nur führende und abschließende Whitespaces (darunter Leerzeichen, aber auch Tabs o. ä.) beim Abspeichern aus den Feldern entfernt und nicht gespeichert werden. Bisher gibt es dazu aber noch kein Release, für das diese Funktion geplant ist. @Felix Hemme fragt bei Khalilah Gambrell nach dem Stand (CC @Andrea Mohr )
| |
Übersetzungen, speziell Inventory | @Felix Hemme | Rückmeldung zu fehlender dt. Inventory-Übersetzung bei einigen Tenants: Generell: Die Fachgruppe D-Übersetzungen ist aktiv und trifft sich ca. 2x/Jahr, immer vor einem neuen Release. Wir haben eine Wikiseite und einen offenen Slack-Channel #d-übersetzungen. Die Converschaft hat Felix ca. Anfang 2024 übernommen, da Martina Schildt sie abgeben wollte. Die Übersetzung der Begriffe wird mit der Software Lokalise durchgeführt. Ich finde keine offenen englisch-deutsch-Übersetzungen für die Dateien Die in einer Modulversion enthaltenen Übersetzungen können aber vom Stand in Lokalise abweichen. Man findet sich auf GitHub immer im UI-Repository, z. B. https://github.com/folio-org/ui-inventory/blob/41c095ad1ada82a8a91d66f52889e7d7404af204/translations/ui-inventory/de.json. Im GBV werden die Übersetzungen in den dort betriebenen Tenants per Script aktuell gehalten, s. https://github.com/gbv/folio-translations. Um das auszuführen, muss man aber die entsprechenden Berechtigungen als SysOps besitzen. In quickMARC gibt es aber durchaus noch offene Übersetzungen. Falls das für eine Einrichtung von Belang ist, kann sie sich gerne darum kümmern. Gerne vorab eine kurze Info per Slack, damit wir die https://folio-org.atlassian.net/wiki/spaces/Deutsche/pages/1770693/Zust+ndigkeiten aktualisieren können. Um zu prüfen, ob man ein Begriff schon übersetzt wurde, sollte man am besten in der aktuellen Snapshot-Version prüfen, ob schon eine Übersetzung existiert. Vermutlich muss dann die eigene Instanz auf den aktuellen Stand gebracht werden.
| |
Überlegungen zur Erweiterung von bibliografischen Daten auf Titelebene aufgrund Reporting-Anforderungen | @Axel Dörrer | Outcome aus D-Reporting Workshop in Bamberg: DBS grundsätzlich möglich auf Titelebene möglich Über die Anforderungen der DBS hinaus: weitere (wenige) Attribute sollten zusätzlich aus dem Zentralkatalog übertragen werden schlanker Katalog vs. nötiger Attribute für ausreichende Auswertungen mögliche Anreicherung über MetaDB oder Datawarehouse kann nicht als übergreifende Lösung gesehen werden
Neben allen Begriffen der Art des Inhalts (nature of content, siehe dazu auch RDA DACH https://sta.dnb.de/doc/RDA-E-W075) sollen möglichst auch die Inhaltstypen sowie die Formate vollständig vorhanden sein. In den an ein CBS angeschlossenen Folio-Systemen ist das schon jetzt der Fall. Diese teilen sich auch die UUIDs. In den Folio-Systemen in Bayern weichen die UUIDs schon jetzt teilweise ab. @Axel Dörrer nimmt diese Problematik zurück in die D-Reporting und prüft, inwieweit die Statistik-Skripte so weit generalisiert werden können, dass die Wahl der UUIDs irrelevant ist.
| |