EAD Verbesserung

[Johann150]

Im Moment gibt es noch ein paar Details, die noch geändert werden sollten:

• [x] addressline falsch buchstabiert (ein zweites d fehlt)
• [x] diverse Attribute für ead- und eadheader-Tags
• [x] Name für den HSA-Bestand (@vonMitzscha wahrscheinlich am besten gleich "HSA-Bestand", dafür die unitid zur ISIL-Nummer ändern?)
• [x] Ist für den Typus Kopie von Handschrift der normierte Typ Sonstige angemessen?

@vonMitzscha Außerdem müsste endlich mal eine Lösung für die Signaturen gefunden werden.

[Johann150]

hierfür ein separater Branch ead

[vonMitzscha]

Zur Signatur:

1. Die Signatur wird schon jetzt trotz #58 vergeben, da wahrscheinlich keine Gefahr besteht, dass kein Komponist oder der Gleichen falsch bzw. nicht absichtlich vergessen angegeben wurde

2. Die Frage, die sich jetzt stellt, ist die des Signatur Systems: es sollte produktiv, leicht entschlüsselbar und leicht (und natürlich auch einmalig) zu vergeben sein. Ich würde es nicht bei der Bisherigen Lösung, der Sortation nach Kasten, belassen. Zur Verfügung stehen folgende Systeme (alle System basieren darauf, es erlauben, alle Werke nach einem Erfassungskriterium zu sortieren und diese dann einfach in den Kästen zu sortieren, soweit diese den Platz haben und dann den Kasten entsprechend markieren. Dh. Die Kästen an sich bzw. der explizite Standort im wesentlichen Sinne, soll nicht mehr Bestand der Signatur sein):

• Komponisten-referenziell: d.h. jeder Komponist bekommt eine eigene ID (z.B. J. Sebastian Bach = JSB) und die Werke werden Komponist nach Art und Aufzählung (erstes Werk, zweites Werk usw.) zugeordnet: JSB-H-1, VW-KVH-23
• Sammlungs-Referrenziell: d.h. jede Sammlung (Archiv, Introitius-S.) werden die Werke beispielsweise nach Art und Aufzählung (s.o.) zugeordnet A-21-12
• Art-Referenziell: d.h. die Werke werden in der ersten Instanz der Art (Handschrift, K.v. Handschrift, Druck) nach geordnet und dann der Aufzählung nach…

Ich persönlich tendiere zum ersten System, da dort das erste, wonach man suchen würde: der Komponist eine wesentliche Rolle in der Signatur besitzt, es zulässt, das die Werke, wenn sie nach Signatur sortiert werden, auch nach Komponist in eine Sinnvolle, produktive Reihenfolge gebracht werden. Fraglich ist nur noch, ob man Buchstaben ID's oder, wie in der SLUB, Zahlencode für die Komponist vergibt und wie mit der dritten Angabe (Aufzählung) in dieser Signaturvariante verfahren wird.

@Johann150 was wäre aus Datenbankperspektive die einfachste Methode. Ich habe mich zum Archivrischn nutzen in der analogen 😄 Welt geäußert…

[Johann150]

Ich fände es ganz und gar nicht gut, die Kastennummer da ganz raus zu lassen. Die Ideen mögen ja ganz gut sein, aber es macht überhaupt keinen Sinn, den Standort nicht in die Signatur einzubesziehen. Das Suchen an sich wird wahrschelinlich sowieso nicht per Signatur geschehen, und selbst wenn, wüsste man nicht, wo man die entsprechende Signatur finden soll.

[Johann150]

Es wäre übrigens sehr umständlich, das ganze mit Buchstaben zu machen, denn dann könnte man die Signaturen nicht automatisch vergeben lassen und man müsste außerdem den Datentyp in der Datenbank anpassen.

[vonMitzscha]

Die Kastennummer kann ganz einfach rausgelassen werden! Denn erstens wird sie noch einmal explizit in der Datenbank der website erwähnt und zweitens werden, wie in jeden normalen archiv, die Kästen nach der Signatur benannt und nicht anders herum. Das heißt: wenn die Werke nach Komponist sortiert wurden, werden sie in dieser Reihenfolge auch in die Kästen geräumt. Der Kasten 1 würde dann also, fiktiv, folgendes Etikett haben: 100-20-1 bis 112-22-4. Das wäre dann also die Handschriften des Komponisten 100 bis zum 4. erfassten (alphabetisch nach Titeln sortierter) Druck des Komponisten 112…

[Johann150]

Für diese Angelegenheiten bist du ja zuständig. Trotzdem wäre eine Signatur mit Buchstaben umständlicher, aber wenn gewünscht auch machbar.

1. ist in sofern schwierig, da jedem Komponisten ein eindeutiges Kürzel bzw. eine eindeutige Nummer zugeordnet werden müsste. Dabei wären Nummern ja blöd, weil dann nicht einmal zu erahnen wäre, was sich hinter einer Nummer verbirgt. Zur Zuordnung dieses/r Kürzels/Nummer wäre dann in der Datenbank noch zusätzlich eine Tabelle mit allen möglichen Komponisten vonnöten. (zusätzlicher Speicheraufwand und Zeitaufwand, um alle Komponisten einzutragen)
2. wäre auch noch relativ einfach umzusetzen, denn es gibt im HSA ja nicht so viele Sammlungen, dass eine extra Tabelle nötig wäre.
3. wäre im Prinzip nur einen Schritt von einer plumpen Durchnummerierung entfernt, wäre dafür aber sehr leicht umzusetzen. Dies würde aber sogar ich ablehnen.

Ich würde also als Kompromiss zwischen Sinn und Komplexität 2. (sammlungs-refentielles System) vorschlagen. Dabei wäre aber bitte noch einmal zu überdenken, wie die Typen zu bezeichnen sind. Es würde ja sicher mehr Sinn machen, diese dann auch mit Buchstaben zu bezeichnen, womit sich die Änderung des Datentyps richtig lohnen würde.

Prinzipiell hätten wir ja dann aber nur noch einen Buchstaben für die Sammlung und einen für den Typus. D.h. das Format der Signatur könnte noch mal abgekürzt werden zu z.B. A/H/32. Hierbei würde ich, wie man sieht, / als Trennzeichen nehmen, da es sich ja um eine wie bei Verzeichnissen hierachische Struktur handelt.

Ich kann abschließen nur zustimmen, dass das 1. System natürlich am meisten Sinn macht und es ist natürlich umsetzbar, aber wie auch schon gesagt umständlicher als die anderen Systeme.

[vonMitzscha]

Also wenn es um meine ehrliche Meinung geht, so würde ich weiterhin bei der Tendenz 1.) bleiben. Das mit den Buchstaben war nur eine Illustration. In der SLUB wird auch mit diesen Nummercodes für Musikalische Archivalien gearbeitet. In der Sache neue Datenbank hätte ich keine Probleme mit (würde mich auch sehr gern bereit erklären, die Kürzel der Komponisten einzutragen), wenn es denn kein großer aufwand wäre, eine neue Tabelle zu schaffen. In Sachen Speicherplatz mache ich mir eigentlich keine Gedanken (Vgl. Wordpress…). Zumal wir haben insgesamt 200-"nochewas" Titel in der Datenbank von denen viele von gleichen Komponisten oder dem (ebenfalls in der SLUB am meisten vergebenen Signum) Anonymus bzw. Unbekannt stammen. In diesem Sinne sehe ich nicht allzu viel vergeben Kürzel. Beim zweiten in Frage kommenden System fehlt mir persönlich einfach der Erfassungstechnische Sinn. Natürlich: die Sammlungen, aber wir haben halt nur zwei und eine der Sammlungen macht das 3/4 des Archives aus. Ich würde daher, mit deinem Einverständnis, weil an die liegt das technische Beurteilen, als erste Bilanz meines Kommentars schließen, dass wir in der Signatur vollkommen auf Buchstabe verzichten (dh. der Komponist als Nummern-Code, der Typus, wie in der alten Signatur auch mit 20,21 oder 22 und die Anzahl natürlich als Nummer). Bei dieser "Anzahl" bleibt mir noch die Frage, ob es möglich, diese nach Alphabetischer Reihenfolge der Titel anzulegen?

[Johann150]

Wie gesagt, ist es zwar aufwendiger, mit Buchstaben, aber wenn wir jetzt sowieso schon den komplizierten Weg einschlagen wollen, dann können wir das auch noch mit machen. Ich fände Buchstaben eigentlich auch besser als dieses System mit den willkürlich gewählten Zahlen.

Also wird es 1. komponisten-bezogenes System

Ich würde allerdings erst mal die Issuu-Einbettung fertigstelllen, bevor wir große Arbeiten an der Datenbank machen.

[Johann150]

Die Kürzel für die Komponisten sind jetzt schon in einer extra Tabelle in der Datenbank. Da wir damit jetzt sowieso schon zu Buchstaben übergegangen sind, würde ich für die Kategorien folgendes umsetzen:

Kategorie	Beispiel
Handschrift	JSB-H-001
Kopie von Handschrift	JBR-K-005
Druck	GAH-D-002

Also jeweils nur einzelne Buchstaben, um die Signatur möglichst kurz zu halten. Desweiteren werde ich eine dreistellige Nummerierung mit führenden Nullen einsetzen.

[vonMitzscha]

Bilanz:

• Signaturen vergeben
• dem folgend unitid mit ISIL zusammen vergeben
• Auf das erste Kommentar bezogen denke ich, dass der Typ Sonstige für Kopie von Handschrift die einzige Alternativ-Lösung ist, da es im Archivarischen Bereich für diesen besonderen Typus keine andere Normung gibt.
• Wiki-Artikel zu Signaturen verfasst (@Johann150 gegebenefalls noch einmal gegenprüfen, nicht dass ich wieder irgendeinen Mist eingebaut habe 😄 )

[Johann150]

Gibt es wirklich nichts im Sinne von Kopie? (muss ja nicht speziell auf Handschriften bezogen sein)

[vonMitzscha]

Ich schaue noch einmal. Ich habe gerade nachgeschaut: alles, was Normen und Standards im Archiv angeht, führt der Kalliope-Verbund. @Johann150 da habe ich auch das hier zu EAD gefunden Hier. Vielleicht finden sich ja dort noch ein paar Programmierspezifische Hinweise zum Format selbst 😃

[vonMitzscha]

Mal eine wichtige Frage: ich bin gerade bei meiner Recherche auf die GND gestoßen, die es als aufgäbe hat, alle Orte und Personen auf der Welt eineindeutig zu standardisieren (für Erfassungen). Inwieweit wäre es sinnvoll, diese in die Signatur zu nehmen? https://wiki.dnb.de/display/ILTIS/Informationsseite+zur+GND

[vonMitzscha]

Vielleicht findet sich hier etwas zu Normen DIN Institut - Fachbereich Information und Dokumentation

[vonMitzscha]

Zu klärende Fragen bezüglich des EAD-Formates:

• [ ] Was für einen Normierten Typ nehmen wir für die Kopie einer Handschrift?
• [x] Soll die Introiten-Sammlung extra in EAD angelegt werden (als neuer Bestand im Findbuch)
• [x] Wie soll dann der Hauptbestand des HSA genannt werden?

[Johann150]

Ich habe mir mal erlaubt, die Intrigen-Saammlung zu korrigieren.

[Johann150]

Also es gibt in der GND, eigentlich noch besser in der VIAF gibt es natürlich schon Identifier für Komponisten. Das Problem ist allerdings, dass diese Identifier dann meist recht lang sind und somit die Signatur unnötig kompliziert machen. Beispielsweise hätte man dann für Johann Seb. Bach mal im Vergleich:

HSA-Kürzel	VIAF
JSB	12304462

Dann könnte man natürlich noch überlegen, ob man ein Kürzel von einer untergeordneten Organisation, wie der DNB, Wikidata, ... nimmt. Aber diese sind auch ähnlich lang. Dies liegt natürlich daran, dass diese Signaturen dafür gedacht sind, eine best. Person bzw. ein best. Objekt zu identifizieren. Da es im HSA aber sowieso nicht so viele Komponisten gibt, sehe ich es als gerechtfertigt, ein vereinfachtes Kürzel für den Komponisten zu nutzen.

[vonMitzscha]

Weitere Dinge, die noch Verbessert werden müssen (von @olivergoetze):

• [x] Der ISIL sollte im Attribut @mainagencycode des Elements <eadid> stehen, und nicht im Elementinhalt (im Pullrequest korrigiert).

• [x] Die ID des Bestands (unter //c[@level=“collection“]/@id) sollte in <eadid> wiederholt werden (im Pullrequest korrigiert).

• [x] <br> muss in umgewandelt werden ( ist falsch, da das Tag nicht als HTML sondern als XML interpretiert wird, und das Tag deshalb wieder geschlossen werden muss) (im Pullrequest korrigiert)

• [x] Das Ampersand muss maskiert werden ( aus & wird & )

• [x] Diegriechischen Sonderzeichen werden in ihrer Entitäts-Schreibweise (z.B. ε) so nicht in XML unterstützt. Stattdessen muss die Unicode-Schreibweise verwendet werden (z.B. Ε).

Hierfür gibt es zwei mögliche Lösungen: a) Ersetzen aller Entitätenschreibweisen durch die jeweiligen Unicode-Repräsentation (so habe ich es in der Beispieldatei einmal gemacht; eine Liste der Unicodes gibt es hier: https://gist.github.com/inanimatt/879249/40a67d792930d921c3f8311d0d026082c03f5292) b) Alternativ können die verwendeten Entitäten einmal im XML deklariert werden; anschließend kann dann auch „ε“ verwendet werden. Ein Beispiel dafür gibt es hier: http://xml.coverpages.org/xml-ISOents.txt

[Johann150]

Ich schlage vor, das direkt in der Datenbank zu ersetzen. Funktioniert auch, da HTML auch XML-Entitäten unterstützt (da HTML auch XML ist).

[Johann150]

Die letzten beiden Punkte wurden in d84c80cb525bbb94609dd9405a67126d39d8f28a gelöst.

[Johann150]

Es besteht immer noch die Frage, welcher EAD-Typus für "Kopie von Handschrift" zu verwenden ist. @olivergoetze Was wäre am besten?

[olivergoetze]

Für den Archivalientyp „Kopie von Handschrift“ würde ich im Attribut physdesc/genreform/@normal ebenfalls „Handschriften“ eintragen – ich fürchte, dass es an dieser Stelle keinen passenderen normierten Wert gibt.

[vonMitzscha]

So weit die Rückmeldung von @olivergoetze stimmt, wartet das HSA nur noch auf den nächsten Übernahme Zeitraum neuer Daten im Archivportal-D Der EAD Export muss also funktionstüchtig und weitestgehend fehlerfrei sein…