Warum muss der TSL/ATS generiert werden?

[andre-hohmann]

Die Generierung der Werte für das Feld TSL/ATS als auch die Speicherung Werts in dem Element erzeugt in Kitodo.Production 3 häufig zusätzliche Aufwände. Letzter Auslöser ist :

• Preserve metadata in collapsed metadata group panels during process creation #6471 (review)

Zuvor mussten andere Anpassungen durchgeführt werden, wie zum Beispiel:

• TSL/ATS is not created for children processes of Kalliope-import #5322
• TSL/ATS is not created for children processes without an own title when superordinate process exists #5321
• TSL generation still bugged for mass import #5311
• TSL/ATS is not created for children processes without an own title anymore  #5208
• TSL/ATS is not created and validated anymore during metadata import #5207
• TSL/ATS calulation does not work properly #4461
• TSL/ATS is formed too late #3600
• Missing TSL/ATS in parent process of multivolume work #3463
• Generation of “TSL/ATS” for volumes of multivolume works without title #3408

@solth wies auf folgende Diskussion hin:

• https://community.goobi.io/t/ats-und-tsl-abschaffen-warum-nicht/132

Aus meiner Sicht sollten die Gründe ermittelt werden, weshalb der TSL/ATS benötigt wird, um diese Funktion im besten Fall abzuschaffen oder zu vereinfachen.

Mir ist bekannt, dass TSL/ATS für den Vorgangstitel generiert wird und in den Metadaten gespeichert wird.
Letzteres war notwendig, um in der Migration Kitodo.Production 2 -> Kitodo.Production 3 die Vorgangstitel für die übergeordneten Vorgänge erzeugen zu können. Somit kann nicht nur auf den TSL/ATS in den Metadaten verzichtet werden.

Mittlerweile frage ich mich, ob nicht ein allgemeines Präfix wie "K10plus" oder "Kalliope" genügt, um die PPN oder andere Identifier im Vorgangstitel zu qualifizieren, oder ob die PPN oder andere Identifier überhaupt qualifiziert werden müssen.

Ich würde mich sehr darüber freuen, weitere Gründe zu erfahren, weshalb TSL/ATS generiert und gespeichert wird.

[BartChris]

In diesem Zusammenhang auch einschlägig:

Additional note: developing this feature revealed some functional metadata types that currently are only used in tests, like authorLastName, dataSource (the corresponding information is currently saved as "ImportConfiguration" directly with the process object in the database) and title, which therefor are probably not required anymore. Those metadata could be removed from the system, but that should be discussed separately from the changes in this pull request.

#6629 (comment)

[andre-hohmann]

Vielen Dank für den Hinweis!

[anspallek]

Aus einer operativen Perspektive sind TSL/ATS benutzerfreundlich und kommunikativ, da der TSL bzw. TSL/ATS eine syntaktische Referenz zum eigentlichen Titel bzw. Autor*in hat. Für Menschen sind ggf. Buchstaben einfacher als Zahlen zur merken.

In der Praxis läuft die menschliche Kommunikation über die TSL/ATS nicht über die ID oder den Gesamttitel, zumal bei den Aufgaben, bei denen noch mit dem physischen Exemplar gearbeitet wird. „Richtig, Namen lassen sich leichter zuordnen“ (Zitat). Use Case: Verschiedene Zeitschriften werden parallel digitalisiert und sind einfach über ihren TSL unterscheidbar. Es müssen sich nicht für den Menschen Random-Zahlen gemerkt werden.

Manche ID-Syntaxen sind für Menschen nur schwer unterscheidbar, z.B. sind bei der MMS-ID von Alma Anfang und Ende gleich, nur die Mitte unterscheidet sich. Daher steigen wir von der MMS-ID wieder zur BV-ID in Kitodo um. Aber als die MMS-ID verwendet wurde, war die direkte Zuordnung für den Menschen nur über den TSL/ATS möglich.

Des weiteren sind Zusammenhänge für Menschen einfach erkennbar und auch direkt über den Suchschlitz in K3 suchbar (wenig Klicks):

Vorgänge derselben Person/desselben Namen über den ATS (ggf. auch die der Doppelgänger, wenn es ein häufiger Name ist)
Vorgänge desselben mehrteiligen Dokumentes über den TSL bzw. TSL/ATS
verschiedene Auflagen desselben Titels mit einem einheitlichen TSL/ATS
Der letzte Beitrag der anderen Diskussion weist ebenfalls auf die Suchproblematik hin.

Außerdem ergeben sich vielleicht so weniger Entfremdungseffekte im Workflow für den Menschen, da es einen sinnhaften Bezug gibt.

Zusammengefasst lässt sich neben der IT-Perspektive auch eine Accessibility- und Usability-Perspektive einnehmen. Der TSL/ATS verstärkt für den Menschen die sprechende Bedeutung der Kitodo-Vorgangsnummer als natürlichem Schlüssel im Gegensatz zur technischen Datenbank-ID .

Ggf. hängen diese Überlegungen auch von der eigenen Projektorganisation und -dimension ab.

[anspallek]

Genau, es geht um eine schnelle und eindeutige Identifizierung für den Menschen. Ich könnte mir vorstellen, dass der TSL/ATS in Kitodo bzw. Goobi eingeführt wurde, um ein bibliothekarisches System nachzubilden, in dem die Titeldaten und der Identifier immer in Kombination in der Trefferanzeige  für die Identifizierung durch den Menschen vorkommen. 

Im regulären Workflow wird meistens nur mit "Aufgaben" und nicht mit "Vorgänge" gearbeitet.

Wenn ein Mitarbeitender nur Zugriff auf "Aufgaben" hat, hat er bei manchen Aufgaben gar keinen Zugriff auf die Titeldaten oder müsste erstmal mehrmals klicken, um sich die Titeldaten im Editor anzeigen lassen zu können. Der TSL/ATS unterstützt so die Identifizierung, wenn kein Zugriff auf die Titeldaten vorliegt.

Bei diesen Überlegungen ist mir bewusst geworden, dass mir das Verhältnis von "Aufgabe" und "Vorgänge" auch nicht klar ist.

Brauchen Mitarbeitende neben dem Zugriff auf "Aufgaben" auch immer einen auf "Vorgänge"?  Um z.B. bei Bedarf die Titeldaten nachlesen zu können? Weitere Gründe?

Praktisch gesehen, arbeiten die Rollen "Scannen," "Qualitätskontrolle" und "Struktur- und Metadatenerfassung" nur mit "Aufgabe", während die Workflow-Administration/-Leitung eher nur mit "Vorgängen" arbeitet.

Wenn ein "nicht sprechender" Identifier in Kitodo verwendet werden soll, reicht es dann nicht aus, direkt die Datenbank-ID als Vorgangsnummer zu verwenden, da diese für die IT-Admnistration benötigt wird?  Die bibliothekarische Identifier sind ja eh als Record Identifier bzw. Shelfmark (Signatur) hinterlegt und suchbar in "Vorgänge"(?).

Use Case 1: Wenn mensch bei der Aufgabe Scannen unsicher ist, ob Buch/Scans und Kitodo-Metadaten zusammenpassen, wird u.a. die Signatur überprüft.

Use Case: 2 Wenn mit der IT kommuniziert wird, will sie nicht die Vorgangsnummer wissen, sondern die Datenbank-ID, d.h. als Mensch muss ich mit zwei Identifiern für denselben Vorgang in Kitodo umgehen. Für den Vergleich  bzw. Merken ist dann auch wieder der TSL/ATS (und die ID) einfacher zu handhaben.

Das mit dem Attribut displaySummary habe ich noch nicht ganz verstanden. Wird dieses auch bei "Aufgaben" angezeigt und wenn ja wo (Startseite Aufgabe/ Aufgaben alle)? Wie gesagt, wird "Aufgabe" nicht, "Vorgänge" hauptsächlich für den Workflow benutzt. Die 3.9-Version kenne ich noch nicht.

Wenn der Record Identifier für die Kitodo-Vorgangsnummer benutzt wird, muss bei Zeitschriftenbänden immer die Bandnummer noch angehängt werden, da sie keinen eigenen Katalogsatz haben, sondern nur einen Exemplarsatz mit der Signatur. Wie wird in anderen Kitodo-Bibliotheken die Vorgangsnummer für Zeitschriftenbände erzeugt? 

Hinweis: Wenn bei mir die ID für "Alle Aufgaben" in 3.8 aktiviert ist, wird sie nicht auf der Startseite unter "Aufgaben" angezeigt.

[BartChris]

Das sind alles berechtigte Fragen, ich unternehme mal den Versuch einer Antwort.

Bei diesen Überlegungen ist mir bewusst geworden, dass mir das Verhältnis von "Aufgabe" und "Vorgänge" auch nicht klar ist.

Brauchen Mitarbeitende neben dem Zugriff auf "Aufgaben" auch immer einen auf "Vorgänge"?  Um z.B. bei Bedarf die Titeldaten nachlesen zu können? Weitere Gründe?

Man kann theoretisch bei jeder Aufgabe den Haken bei "Metadaten" setzen.

So kommt man immer aus der Aufgabe in den Metadateneditor. Der Nachteil ist natürlich, dass dafür die Aufgabe erstmal angenommen werden muss. Und es ist ein zusätzlicher Klick.

Es kann allerdings in beiden Listen nach Metadatenfeldern gesucht werden

Use Case 1: Wenn mensch bei der Aufgabe Scannen unsicher ist, ob Buch/Scans und Kitodo-Metadaten zusammenpassen, wird u.a. die Signatur überprüft.

Ich gehe jetzt mal direkt von Kitodo 3.9 aus, da es ja nun releast ist und das verbesserte Metadaten-Suchmöglichkeiten hat
Es kann sowohl in der Vorgangsliste als auch in der Aufgabenliste direkt im entsprechenden Metadatenfeld nach der Signatur gesucht werden. Hier "shelfmark:XXX"

Ab Kitodo 3.9 sollte also zumindest in allen Metadatenfeldern gesucht werden können. Was als Desiderat bleibt wäre, dass eine Anzeige von Metadateninformationen oder des TSL/ATS fehlt. Der Benutzer weiß also weder in der Vorgangs- noch in der Aufgabenliste genau, um welches Objekt es sich eigentlich handelt ohne in den Metadateneditor zu gucken.

Die grundsätzliche Schwierigkeit ist, dass es so etwas wie standardisierte Metadatenfelder, die man immer anzeigen könnte nicht gibt. Jede Institution hat eigene Metadaten, insofern kann man in der Liste auch nicht so einfach Metadaten anzeigen.

Hier kommt die displaySummary ins Spiel.

Das mit dem Attribut displaySummary habe ich noch nicht ganz verstanden. Wird dieses auch bei "Aufgaben" angezeigt und wenn ja wo (Startseite Aufgabe/ Aufgaben alle)?

Die displaySummary ist ein Attribut, dass 1-n Metadatenfelödern eines Dokumententyps zugewiesen werden kann, also z.B. dem "Titel" und der "Signatur". Kitodo kann diese Felder dann verkettet anzeigen, also in etwa so:

"Mein schöner Titel - SAB_AJ_XY"

Aktuell wird das Feature nur bei der ANLAGE von Bänden innerhalb einer Überordnung benutzt. Man KÖNNTE aber auch bei allen Einträgen in der Aufgaben- und Vorgangsliste diese `displaySummary anzeigen. Der Vorteil wäre, dass jede Institution eine eigene Kombination von individuellen Metadatenfelder je Medientyp zusammenstellen kann, die dann als "displaySummary" ausgegeben würde.

Bei Monographien also z.B.:

"Mein schöner Titel - SAB_AJ_XY"

und Bei Zeitschriften:

"Mein Zeitschriftentitel - Band 12, 1922"

[BartChris]

Wenn der Record Identifier für die Kitodo-Vorgangsnummer benutzt wird, muss bei Zeitschriftenbänden immer die Bandnummer noch angehängt werden, da sie keinen eigenen Katalogsatz haben, sondern nur einen Exemplarsatz mit der Signatur. Wie wird in anderen Kitodo-Bibliotheken die Vorgangsnummer für Zeitschriftenbände erzeugt? 

Vielleicht kann @andre-hohmann hierzu etwas sagen?

[andre-hohmann]

In der SLUB wird seit einiger Zeit ein Suffix in der Form -YYYYMMDD angefügt. MM und DD sind in der Regel 00, weil Zeitschriftenbände nicht so granular erscheinen.
Wir haben uns an den Zeitungsausgaben orientiert, für die Monate und Tage in der Regel berücksichtigt werden müssen.
In den Altdaten wurde der Barcode des Bandes angewendet und mit "Z" ergänzt.

Beispiele der derzeitig angewendeten Form:
Bände von

• http://digital.slub-dresden.de/id359480586
• http://digital.slub-dresden.de/id416501729

An der OAI-Schnittstelle ist der record identifier der Bände auch in den Links der XML-Dateien der Bände in <mets:structMap TYPE="LOGICAL"> der Überordnung enthalten.

• https://digital.slub-dresden.de/oai/?verb=GetRecord&metadataPrefix=mets&identifier=oai:de:slub-dresden:db:id-359480586

[anspallek]

@BartChris Danke für den Hinweis auf die Eigenschaft Metadaten bei der Aufgaben-Definition. Das hilft schon mal weiter.

Ich kann mir vorstellen, dass displaySummary als allgemeines Feature sehr hilfreich sein kann.

Der TSL/ATS bietet bisher eine einfache und automatische Lösung dafür an, wie Titel eindeutig gekürzt werden können. Beim displaySummary müsste ggf. vom Menschen definiert werden, wie mit ähnlichen und langen Titeln umgegangen werden muss. Z.B. mehrere Zeitschriften beginnen mit "Zeitschrift für...."