Vorschlag SLUB Dresden

Beschreibung

• Einem Datensatz sollen mehrere Signaturen zugewiesen werden können. Dies betrifft zur Zeit die folgenden Felder:      
  • Signaturtyp
  • Signatur-Präfix
  • Signatur
  • Signatur-Suffix
  • Primär
• Ebenen: Dies bezieht sich sich auf die Signaturen in den Ebenen:
  • Item (Exemplar) 
  • Holding (Bestand)
• Hauptsignatur: Die zur Zeit gültige Signatur ("Hauptsignatur") soll durch eine Funktion markiert werden können, die folgende Eigenschaften umfasst:
  • Eine Signatur muss als Hauptsignatur gekennzeichnet sein
    • Es muss mindestens eine Signatur als Hauptsignatur markiert sein - idealerweise wird die erste Signatur immer als Hauptsignatur markiert (unabhängig, ob manuell oder maschinell hinzugefügt).
    • Das Feld Primär wird mit dem Pflichtfeld-Symbol (hochgestellter Stern) gekennzeichnet. 
    • Wenn keine Signatur als Hauptsignatur markiert ist, wird ein Hinweis angezeigt. Dieser Hinweis sollte dem bestehenden Konzept (Siehe Entwurf) der Pflichtfeld-Validierung auf Exemplarebene entsprechen. 
      
      • Bitte auswählen, um fortzufahren
  • Eine nachträglich hinzugefügte Signatur muss bei Bedarf explizit als Hauptsignatur markiert werden.
    • Dadurch wird die Markierung der bisherigen Hauptsignatur entfernt 
    • Es darf nur eine Signatur als "Hauptsignatur" markiert werden
  • Die Hauptsignatur wird zum Beispiel in Folio in den Tabellen, oder in Katalogen angezeigt
  • (Vorschlag) Bezeichnung Button inaktiv: Zur Hauptsignatur machen
  • (Vorschlag) Bezeichnung Button aktiv: Primär
  • (Vorschlag) Bezeichnung Feld: Primär
• Löschen: Jede Signatur soll einzeln mit allen zugehörigen Signaturfeldern gelöscht werden können.  
• Indexierung: Alle Signaturen sollen im Signaturindex enthalten sein, damit man danach recherchieren kann.
• Filter/Suche: Es soll eine Filtermöglichkeit implementiert werden, um die Treffermenge auf die Hauptsignaturen einzuschränken zu können. 
• Exporte: Alle Signaturen sollen in Exporten enthalten sein, sofern sie nicht als "Anzeige im Discovery unterdrücken" ausgezeichnet sind. 

Entwurf

• In dem folgenden Entwurf für die Signatur-Felder wurde das Konzept des Feldes Mitwirkende/-n auf der Instanz-Ebene als Grundlage genutzt. 
  • Vorlage: Mitwirkende/-r
    • Version: ohne Fehlermeldung
      
    • Version: mit Fehlermeldung
      
  • Vorschlag: Signatur
    • Version 1
      
    • Version 2 (13 Mar 2023) 
      

Erstellte Jira-Tickets

• -

Aktueller Stand

• VORSCHLAG IN BEARBEITUNG: Der Vorschlag für die Anforderung wird noch bearbeitet und kann noch nicht in der D-Metadaten Management vorgestellt werden. 
• VORSCHLAG FORMULIERT: Der Vorschlag für die Anforderung wurde formuliert und kann in der D-Metadaten Management vorgestellt werden. 
• VORGESTELLT IN D-ERWERBUNG: Der Vorschlag für die Anforderung wurde in der Gruppe D-Metadaten Management vorgestellt.  
• ANPASSUNG DES VORSCHLAGS: Der Vorschlag wurde nach der Vorstellung in der Gruppe D-Metadaten Management diskutiert sowie mit ähnlichen oder konkurrierenden Vorschlägen verglichen und gegebenenfalls angepasst. Die Gruppe D-Erwerbung ist mit dem Vorschlag einverstanden. 
• PRÜFUNG IMPLEMENTER LISTE: Der Vorschlag wird hinsichtlich der Aufnahme in der Implementer Liste geprüft. 
• PRIORISIERUNG: Der Vorschlag wird in der Gruppe D-Metadaten Management priorisiert. Je höher die Priorität gewählt wird, desto eher wird die Entwicklung angestrebt. 
• VORSTELLUNG SIG ???: Der Vorschlag wird in der SIG ??? vorgestellt. 
• BEAUFTRAGUNG DER ENTWICKLUNG: Der Vorschlag wird mit den notwendigen Ressourcen in den Entwicklungsprozess eingebracht. 

Weitere Informationen

Vorstellungen

• 2023-05-04 Metadata Management Meeting notes
  • Effective Call number
    • Das sollte immer die primäre Signatur sein
  • Browsing
    • Die Auswirkungen müssen noch geprüft werden

Funktionsanalyse

• Erfassung mehrerer Signaturen - Funktionsanalyse

Relevante Anforderungsanalysen

• -

Relevante Entwicklungen und Quellen

• -

Relevante vorhandene Jira-Tickets