Richtlinien Datenverarbeitung

<img src="https://seafile.rlp.net/seafhttp/f/da9003df26be40a0be39/?op=view"

      alt="Fürstinnen-Logo" 
      width="25%"
      style="display: block; margin: 0 auto 1em auto;">

Richtlinien zur Datenverarbeitung

Vorgaben für die Verarbeitung der Daten der Fürstinnenbibliotheken

Inhaltsverzeichnis

• Leitgedanken
  • Datenintegrität
  • Aufbau
• Richtlinien
  • Extern
  • Intern
• Zusammenfassung für Nutzende
  • Allgemeine Hinweise
  • Hinweise zu Katalogdaten
  • Hinweise zu Personendaten

Leitgedanken

Datenintegrität

Um einen reichhaltigen und vielfältig nutzbaren Datensatz zu erhalten, soll der Grundsatz der Datenintegrität so weit möglich gewahrt werden. Das bedeutet, dass die Daten vollständig, korrekt und konsistent sein sollten. Dieser Leitsatz ist gerade für historische Daten praktisch teilweise schwierig umzusetzen, da die Daten aus unterschiedlichen Erschließungsphasen stammen und in unterschiedlichen Formaten vorliegen. Dadurch ist ein großer Aufwand hinsichtlich der Vereinheitlichung nötig, um Ziele der Datenintegrität anzustreben. Um die Vereinheitlichung umzusetzen, wurden einerseits die Quellen direkt zu Rate gezogen, andererseits kamen technische Hilfsmittel zum Einsatz. So konnten fehlende Daten nachgetragen werden. Trotz äußerster Vorsicht kann es zu Datenverlusten und Fehlern kommen. Gerade bei technischer Umsetzung können systematische Fehler nicht in allen Fällen vermieden werden. Um zumindest größtmögliche Transparenz zu schaffen, wurden in Hinblick auf die Zielsetzung der Datenintegrität die folgenden Bearbeitungsvorgaben entwickelt. Um diese nicht nur dem Buchstaben nach, sondern auch der Idee nach umzusetzen, wird diese (allgemeinen Vorgehensweisen folgend, aber auf die konkrete Anwendung spezifiziert) kurz skizziert.

Korrektheit

Die Korrektheit der Daten ist von besonders großer Bedeutung. Um diese zu erreichen, ist selbst bei bestehenden Daten immer wieder der Blick in die Quellen notwendig. Es kann dabei nicht in jedem Fall nachvollzogen werden, welche Angaben korrekt sind, da viele im Laufe der Zeit verloren gegangen sind. Weiterhin kommt es zu einer Diffusität bezüglich dessen, was als korrekt zu bezeichnen ist. Historische Quellen unterscheiden sich hinsichtlich ihrer Schreibweise und Interpretation von Begriffen, wie zum Beispiel Ortsbezeichnungen. Aufgrund der Menge der Daten und dem Umfang der Umformatierungsarbeiten können nicht alle Fehler vermieden werden, daher wird die Korrektheit der Angaben laufend stichprobenartig korrigiert und geprüft.

Vollständigkeit

Es ist schlicht nicht möglich, die Angaben zu vervollständigen, da bereits durch die bruchstückhafte Ausgangslage nicht alle Angaben für alle Datensätze aufgefunden werden können. Diese Probleme können auch durch eine nachträgliche Autopsie nicht vollständig ausgeglichen werden. Weiterhin kommt es durch die Umformatierung und eine Ausrichtung der Daten auf bestimmte Fragestellungen zu Verlusten im Vergleich zu den Ausgangsdaten; Diese zeigen sich jedoch bereits in der Datenmodellierung. Zielsetzung des Projektes ist nicht das massenhafte, aber unaufgeräumte Sammeln aller möglichen Daten, sondern das Bereitstellen eines Datensatzes, der durch gezielte Selektion und Aufbereitung bestehender und ergänzter Daten möglichst vollständig und nutzbar - wenn auch weniger umfangreich - gehalten werden kann. Daher wird ein hoher Aufwand betrieben die vorliegenden Daten aufzubereiten und anzureichern, um eine gleichbleibende Qualität zu erreichen.

Konsistenz

Sind die Daten vollständig und korrekt, dann folgen sie feststellbaren Regeln. Können diese Regeln dem Datensatz entnommen werden, ermöglichen sie eine hohe Interpretierbarkeit. Gleichzeitig kann die Datenbank auf ihre Inhärenz geprüft werden, sodass mit dem Befolgen der Regeln bei einer Anreicherung der Datenbank diese leichter einheitlich und durchschaubar gehalten werden kann. Aufgrund der mit den Regeln entstandenen Vergleichbarkeit, kann zuletzt durch die Kenntnis dieser auch die Möglichkeit des Heranziehens einer anderen Datenbanken einfacher eruiert werden. Die Regeln können einerseits externen Vorgaben entnommen werden, wie der Implementation der Datenbank oder der Modellierung der Daten, andererseits setzen sie sich zusammen aus inhaltlichen, datenbezogenen Präsumtionen.

---

Aufbau

Datenbank

Als Datenbank wurde eine Wikibaseinstanz mit einer MySQL-Datenbank im Backend aufgesetzt. Die verwendete Infrastruktur erfordert eine spezielle Aufbereitung der Daten. Allgemein erfordert die Wikibase als Graphdatenbank die Aufbereitung der Daten in Form von Subjekt-Prädikat-Objekt-Beziehungen (sogenannte Tripel). Diese Art der Aufbereitung ermöglicht eine recht große Freiheit und Übersichtlichkeit in der Modellierung, da jedoch (noch) kein Werkzeug zur Verfügung steht, das die Übereinstimmung der Daten mit dem Datenmodell prüft, muss bei dem Hinzufügen neuer Datentripel und -punkte ein hohes Maß an Vorsicht aufgebracht werden. Daher werden entsprechend strikte Richtlinien erstellt und die Umsetzung dieser konsequent überprüft. Neben diesen autonomen Leitfäden gibt es noch sehr konkrete technische Vorgaben: Beispielsweise gibt es vorimplementierte Datentypen, deren Nutzung eine entsprechende Aufbereitung der Daten erfordert und eine gegebene Darstellung dieser bewirkt oder auch feste Maximalzeichenlängen für die Namen der Einträge. Weitere Einschränkungen entstehen durch die Verwendung verschiedener Werkzeuge, die die Funktionen der Wikibase teilweise nicht oder in abgewandelter Form unterstützen.

Datenmodell

<figure style="text-align: center; margin: 2em 0;"> <img src="https://seafile.rlp.net/seafhttp/f/0857ddd83306446ebcb5/?op=view"

      alt="Datenmodell als Grafik"
      style="display: block; margin: 0 auto 0.5em auto; max-width: 100%; height: auto;">

<figcaption style="font-size: 0.9em;"> Datenmodell als Grafik </figcaption> </figure> Das feststehende Datenmodell ermöglicht einen einfachen sowie treffsicheren Zugriff auf die Daten. Da die Wikibase keine Möglichkeit zur Validierung der Daten auf ein selbsterstelltes Datenmodell bereithält, handelt es sich bei der Umsetzung eher um eine freiwillige Selbstverpflichtung, die jedoch mit technischen Mitteln vorangetrieben wird. Das Datenmodell basiert auf gängigen Konzepten zur Modellierung von Buchdaten und wurde mit spezifischen Informationen erweitert. Diese betreffen vor allem die Daten zu den Katalogen, Inventaren und Briefen, die die Buchsammlungen auflisten. Außerdem kommt ein Modul bezüglich der Benutzung der Bücher hinzu. Um Probleme mit bestehenden Daten zu vermeiden ist das Modell nach der ersten Festlegung nicht mehr zu ändern, oder nur mit größter Vorsicht, denn bei einer Änderung muss der komplette bestehende Datensatz ebenso angepasst werden.

Autopsie

Weitere Hilfsmittel

Um die Daten von ihren verschiedenen Ausgangslagen in die gewünschte Form zu bringen, kommen zuerst manuelle Überarbeitung und in einem zweiten Schritt Pythonskripte zum Einsatz. Die Entstehung der Skripte ist eng mit dem Blick in die Daten selbst verknüpft. Manuelle und technische Überarbeitung stehen so in steter Wechselwirkung. Die Skripte setzen das um, was zuvor konzeptioniert wurde, werden aber mit Blick auf die entstandenen Daten immer wieder korrigiert und weiterentwickelt. Ihr Umfang und ihre Entwicklungszeit passt sich an die konkrete Problemstellung an. Soll beispielsweise lediglich eine Spalte in einem Katalog automatisiert geändert werden, muss kein großer Aufwand betrieben werden. Soll jedoch ein flexibles Programm erstellt werden, mit dessen Hilfe alle Kataloge in die Wikibaseinstanz geladen werden soll, ist es nötig entsprechend intensiv zu testen und zu dokumentieren, damit es flexibel und präzise ist. Neben diesen Skripten können für die Weiterverarbeitung auch Plugins und externe Werkzeuge zur Verwendung kommen, wobei dann wieder stärker die Kontrolle der Daten auf ihre Validität in Hinblick auf das Datenmodell im Blick gehalten werden muss.

---

Richtlinien

Extern

Wikibase

Alle Wikibaseinstanzen geben den in ihnen enthaltenen Daten bestimmte Formate und Eigenschaften vor. Diese sind in dem zugehörigen Wiki[^4] sowie in der technischen Dokumentation[^5] beschrieben. Beispielsweise können bestimmte Datentypen in der Wikibase verwendet werden[^6], oder die Wikibase schreibt vor, dass Zeichenfolgen mindestens ein Zeichen lang sein müssen, und lässt keine Zeichenfolgen zu, die dem regulären Ausdruck „^|[|$“ entsprechen (d. h. keine Zeichenfolgen, die mit einem Leerzeichen beginnen oder enden oder vertikale Leerzeichen wie Zeilenumbrüche enthalten). Die Vorgaben für die Wikibaseversion „1.44“ sowie die Dockerversion „0.3.137-wmde.20“ für den Wikidata Query Service und mit ihm in Zusammenhang stehenden Funktionen sind daher einzuhalten. [^4]: Siehe dazu: https://www.mediawiki.org/wiki/Wikibase [^5]: Siehe dazu: https://doc.wikimedia.org/Wikibase/master/php/index.html [^6]: Siehe dazu: https://www.wikidata.org/wiki/Special:ListDatatypes

Erweiterungen

Obgleich es sich bei der Wikibase selbst eigentlich um eine Erweiterung handelt, kommen weitere Werkzeuge zum Einsatz. Neben Plugins der Wikibase wie WikibaseCirrusSearch <ref>Siehe dazu: https://www.mediawiki.org/wiki/Extension:WikibaseCirrusSearch</ref> oder Nuke <ref>Siehe dazu: https://www.mediawiki.org/wiki/Extension:Nuke</ref> kommen externe Werkzeuge wie OpenRefine <ref>https://openrefine.org/</ref> zum Einsatz. Das bedeutet, dass …

Python-Bibliotheken

Für das Hochladen der Daten wird in der Hauptsache die Bibliothek WikibaseIntegrator <ref>Siehe dazu: https://wikibaseintegrator.readthedocs.io/en/stable/</ref> zum Einsatz. Einerseits prüft diese bereits größtenteils auf Konformität der Daten mit den Vorgaben der Wikibase, andererseits kommt es durch seine Nutzung zu weiteren Eingrenzungen, sei es, weil dies erwünscht ist (Übereinstimmung mit dem Datenmodell oder der Umgang mit schon bestehenden Daten), sei es aus technischen Gründen (auch hier gibt es genaue Vorgaben zu den Datentypen<ref>Gelistet sind die Datentypen in der technischen Doku: https://wikibaseintegrator.readthedocs.io/en/stable/wikibaseintegrator.datatypes.html#submodules</ref>). Zwar wird die Abhängigkeitenliste möglichst klein gehalten und größtenteils auf Standardbibliotheken zurückgegriffen, dennoch kann nicht ausgeschlossen werden, dass die Abhängigkeiten oder Unterabhängigkeiten zu bestimmten Verhalten führen. Für genauere Informationen sollte die technische Dokumentation<ref>Verlinken und veröffentlichen? Oder auf https://data.fuerstinnentest.uni-trier.de/wiki/Hauptseite?</ref> und/oder der Quellcode<ref>Veröffentlichen?</ref> in Betracht gezogen werden.

Allgemein

Neben den technischen Hintergründen gibt es auch externe Leitlinien, die herangezogen und beachtet werden. Allem voran finden bei der Erstellung und Anpassung des Datenmodells die Vorgaben von CIDOC CRM<ref>Siehe dazu: https://cidoc-crm.org/</ref> und spezifischer LRMoo<ref>Siehe dazu: https://cidoc-crm.org/lrmoo</ref> Beachtung. Ganze Bereiche wurden nach dem dort erstellten Schema<ref>Die Unterteilung von Buchinformationen in Work, Expression, Manifestation und Item.</ref> umgesetzt (das betrifft im Besonderen das sogenannte WEMI-Schema). Das Datenmodell wird einerseits mithilfe von Protégé<ref>Siehe dazu die Dokumentation: https://protegeproject.github.io/protege/</ref> als RDF-Datei erstellt und somit maschineninterpretierbar bereitgehalten. Andererseits können die Hauptaspekte des Modells. also die Objekte und deren mögliche Beziehungen untereinander in der Wikibase selbst eingesehen werden. Auch die Zugehörigkeit einer Instanz zu ihrer Klasse wird mithilfe der is_instance_of-Beziehung feststellbar.

---

Intern

Datenmodell

Neben den externen Vorgaben bezüglich des Datenmodells gibt es weitere innerhalb des Projektes gesetzte Vorgaben. Es werden zwar nicht alle Funktionen, die Protégé bereitstellt verwendet, jedoch können neben der besseren Übersichtlichkeit mithilfe des Programmes weitere Angaben gemacht werden, die die Vorgaben and die Daten weiter auf eine maschinenverarbeitbare Art präzisieren. So können Charakteristiken wie Transitivität, Funktionalität, Symmetrie oder Reflexivität der Eigenschaften gesetzt werden<ref>Siehe dazu: https://protegeproject.github.io/protege/views/object-property-characteristics/</ref> oder Unterklassenbeziehungen und Freitextbeschreibungen einfach editiert werden. Die daraus entstehende Datei ist die Grundlage für die Informationen in der Wikibase und auch die weitere Verarbeitung der Daten. Alle Informationen bezüglich des Datenmodells werden in dieser einen Datei also zentral gelagert und zu Weiterverarbeitungszwecken aus dieser entnommen. Das gilt sowohl für die Erstellung des Datenmodells in der Wikibase, als auch für den Abgleich der Daten mit dem Datenmodell. Perspektivisch ist auch der andauernde Abgleich der Daten und des Datenmodells in der Wikibase mithilfe dieser Datei umzusetzen.

Autopsie

Auch für die Autopsie gibt es Vorgaben, die spezifisch für dieses Projekt gelten. Das betrifft einerseits die Kriterien, auf welche die Bücher geprüft werden (diese finden sich in dem Datenmodell - alle dort enthaltenen Klassen werden zur Prüfung herangezogen, andere Informationen können ohnehin nicht sinnvoll dargestellt werden und sind daher für dieses Projekt nicht weiter relevant). Aus dieser Vorannahme ergibt sich weiterhin ein Prüfschema, dass sich in den Daten widerspiegelt: Angaben in Datenpunkten ohne weiteren Vermerk sind überprüft worden. Die Angabe, dass keine Angabe existiert, bedeutet, dass nachgeschaut wurde (beispielsweise bei der Angabe „ohne Verlag“ als has_publisher-Beziehung bedeutet das, dass es zu dem Verlag keine Angabe gibt und dies auch im Buch überprüft wurde). Wird keine Angabe gemacht, gibt es keine weiteren Informationen zu dem Datenpunkt, das heißt es wurde nicht geprüft oder das Wissen liegt nicht in einer weiterverarbeitbaren Form vor. Andererseits gibt es weitere Sachen, die beachtet werden (müssen), die hier noch aufzuzählen sind.

Die Dokumentation muss auf eine Weise geschehen, dass die Daten mit möglichst geringem Aufwand in die Wikibase transferiert werden können. Daher müssen sie passend zu dem Skript digital aufgearbeitet werden.

Wiederverwendete Daten

Für bereits bestehende Datensätze gelten die gleichen Grundbedingungen, wie für neu erhobene Daten. Um die Daten in die gleiche Form zu bringen, gilt es jedoch anderen Herausforderungen Rechnung zu tragen: Einerseits sind die Quellen bereits erschlossen, jedoch nicht zwangsläufig mit dem gleichen Ansprüchen und Zielen, wie dies in diesem Projekt der Fall ist. Daher können sie Informationen enthalten, die hier nicht relevant sind, problematischer wird es jedoch, wenn benötigte Informationen nicht enthalten sind oder nicht mehr (gut oder sicher) nachvollzogen werden können. Zusätzlich können die Informationen nicht immer (einfach) automatisch übertragen werden. Daher werden auch in diesem Fall weitreichende Aufbereitungsschritte durchlaufen:

Diese Schritte stellen sicher, dass die Daten möglichst korrekt in dem neuen Schema umgesetzt werden können und somit mithilfe des Skriptes einwandfrei in die Wikibase geladen werden können.

Skript zum Hochladen

Es gibt verschiedene Punkte, die bedingt durch das Skript in der letzten Form vor dem Hochladen beachtet werden müssen. Diese finden sich einerseits in der technischen Dokumentation des Skriptes wieder<ref>Siehe dazu oben.</ref>, werden weiter unten jedoch für die Anwendendenperspektive aufbereitet. Das Skript an sich benötigt vor allem durch die systematische Aufbereitung einen präzisen Datensatz, der klar definierte Aussagen trifft. Zeichenketten, die eine bestimmte Sonderrolle einnehmen, müssen diese immer in einem klar definierbaren Kontext einnehmen, sonst wird es zu Fehlern bei ihrer Verarbeitung kommen.

Um eine möglichst hohe historische Genauigkeit zu erreichen und gleichzeitig die Daten vergleichbar zu machen, werden historische Zitate von modernen Vereinheitlichungen unterschieden. Um die Datenbank jedoch nicht mit schlecht nachvollziehbaren Dopplungen zu überladen, wird in Hinblick auf die Zielsetzung bestimmten Regeln folgend selektiv vorgegangen. Hohe Transparenz und ein stimmiges Konzept sind bei diesem Vorgehen entscheidend. Das Datenmodell legt daher fest, welche Eingaben gemacht werden (können) und welche Vorgaben für diese gelten. Weiterhin wurde ein Verfahren entwickelt, dass eine einheitliche Transformation der Daten in die Wikibase unter Einhaltung des Datenmodells ermöglicht und so die Form der Daten bestimmt.

---

Zusammenfassung für Nutzende

Allgemeine Hinweise

	Form	Inhalt / Bedeutung
Konstanten	Konstantenname = Konstanteninhalt	1. Konstanten für die komplette Weiterverarbeitung 2. Einige Konstanten sind Allgemeingültig, einige werden nur für spezielle Aufgaben benötigt und müssen an die Daten angepasst werden -> konstanten.py
	trenner = "###"	Symbol für das interne Trennzeichen. ⚠️ Darf in den Daten nicht anderweitig vorkommen.
	maxzeichen	2000 – Maximale Zeichenanzahl für Bezeichner*.
	maxzeichen_zeichenkette	4000 – Maximale Zeichenzahl für Zeichenketten*.
	csv_pfad	BASE_DIR / "data/ordner/inhalt.csv" – Pfad zu Tabelle mit den Daten.
	ppn_pfad	BASE_DIR / "data/ordner/inhalt.csv" – [optional] Pfad zu Tabelle mit zusätzlichen Inhalten.
	image_grundurl	kat_link + "?image=" – Link zu einzelnen Seiten eines Kataloges.
	dnb_grundurl	'https://d-nb.info/gnd/' – Link zur DNB-Datenbank.
	ohne_angabe = "ohne Angabe"	Setzung, falls es allgemein keine Angabe gibt.
	ohne_ort = "ohne Ort"	Setzung, falls es keine Angabe für einen Ort gibt.
	ohne_publisher = "ohne Druck-/Verlagsangabe"	Setzung, falls es keine Angabe für einen Publisher gibt.
	ohne_jahr = "ohne Jahr"	Setzung, falls es keine Angabe für eine Jahreszahl gibt.
	erschlossen = "revealed"	Qualifizierer, falls eine Eigenschaftsbeziehung nachträglich erschlossen wurde.
	ist = "is"	– Qualifizierer, falls eine Eigenschaftsbeziehung Zusatzattribute erhalten soll.
	hat_preis = "has_price"	– Qualifizierer für Preis.
	hat_datum = "has_date"	– Qualifizierer für Datum.
	unsicher = "uncertain"	– Qualifizierer, falls ein Eigenschaftswert unsicher ist.
	nachträglich = "later"	– Qualifizierer, falls ein Eigenschaftswert nachträglich ist.

Daten bezüglich der Wikibase (konstanten.py und einlogdaten.json)

	Form	Inhalt / Bedeutung
Daten bezüglich der Wikibase	Zweck = Inhalt	1. Eingabe- und Verbindungsdaten 2. Daten werden für alle Verbindungen mit der Wikibase verwendet -> konstanten.py und einlogdaten.json
	"benutzername"	Individuell gesetzt in einlogdaten.json
	"passwort"	Individuell gesetzt in einlogdaten.json
	wb_api_url	"https://data.fuerstinnentest.uni-trier.de/w/api.php%22
	wb_url	"https://data.fuerstinnentest.uni-trier.de/%22
	wb_sparql_url	"https://query.fuerstinnentest.uni-trier.de%22

Nachnutzung der Objekte in Wikibase (konstanten.py: nachnutzbare_objekte)

	Form	Inhalt / Bedeutung
Nachnutzung der Objekte in Wikibase	Instanzname#bestimmterBezeichner;<br>Eigenschaft1#Eigenschaftwert1;<br>Eigenschaft2#Eigenschaftswert2,..	1. Überprüfung, ob Objekt schon existiert und verwendet werden kann. 2. Bezeichner wird immer auf Gleichheit überprüft. 3. Instanznamen, Eigenschaften und -werte können mittels „+" und „*“ dynamisch gesetzt werden (genau dieser Wert muss bereits mindestens 1 mal, bzw. beliebig oft gleich gesetzt worden sein). 4. Es wird in der folgenden Reihenfolge geprüft und der erste Treffer gewählt. -> konstanten.py: nachnutzbare_objekte
	Item;has_digital_copy#+	Item – Wiederverwendung bei identischem has_digital_copy
	"Manifestation;has_place_of_printing#*;<br>has_year_of_printing#*;has_publisher#*"	Manifestation – Wiederverwendung bei identischem Ort, Jahr und Publisher
	"Expression"	Expression – Wiederverwendung bei gleichem Bezeichner
	"Work"	Work – Wiederverwendung bei gleichem Bezeichner
	"Shelfmark"	Shelfmark – Wiederverwendung bei gleichem Bezeichner
	"Place"	Place – Wiederverwendung bei gleichem Bezeichner
	"Person#" + ohne_publisher	Person – bei ohne_publisher-Bezeichner
	"Subject"	Subject – Wiederverwendung bei gleichem Bezeichner
	"Genre"	Genre – Wiederverwendung bei gleichem Bezeichner
	"MediaType"	MediaType – Wiederverwendung bei gleichem Bezeichner
	"Language"	Language – Wiederverwendung bei gleichem Bezeichner
	"+;has_id#+"	Alle Klassen – bei identischer has_id
	"+#" + ohne_angabe	Alle Klassen – bei ohne_angabe-Bezeichner
	"Catalogue"	Catalogue – Wiederverwendung bei gleichem Bezeichner

Aufbereitung der Daten (innerhalb einer Zelle)

1. Die Implementierung gibt verschiedene Vorgaben an die Daten vor.
2. Einige Vorgaben sind beabsichtigt, um als technische Bedingung Vorgaben zu erzwingen, die zur Datenkonsistenz beitragen.
3. Einige Vorgaben sind (noch) nicht implementiert und müssen daher bei der Erstellung der Daten dringend beachtet werden.

⚠️ Kritische Zeichen: #, [, ], ;, &&&, |||

Bereinigung

Form	Inhalt / Bedeutung
Dateninhalt#ID1#ID2...	Identifizierer können an Datenpunkte angehängt werden, um has_id Eigenschaften an die Objekte anzuhängen.
[Dateninhalt]	Daten als nachträglich erschlossen markieren. → Qualifizierer auf Eigenschaftsbeziehung.
Dateninhalt1;Dateninhalt2...	Mehrere Datenpunkte in einer Zelle mit Semikolon → mehrere Eigenschaftsbeziehungen.
Dateninhalt&&&Alias1||Alias2	Aliasse mit &&& und || trennen. Matching-Probleme möglich.
[Dateninhalt&&&Alias1||Alias2#ID1#ID2]	Kombination: Reihenfolge = Bezeichner → Aliasse → IDs. Eckige Klammern für Nachträge umschließen einen vollständigen Datenpunkt.

Automatische “ohne Angabe”-Erkennung & Ortangaben (nach Bereinigung)

Form	Inhalt / Bedeutung
- has_publisher: ‚keinedrucker-/verlagsangabe' <br>- has_year_of_printing, has_year_of_birth, has_year_of_death: 'o.j.', 'o.jahr', 'ohnejahr', ‚ohnej.' -has_place_of_printing, has_place_of_activity, has_place_of_birth, has_place_of_death', 'has_localisation: 's.l.', 'o.o.', 'o.a.', 'o.ort', 'ohneort', ‚ohneo.' - Ansonsten: ‚ohneangabe'	Nach der Bereinigung (Mutation zu kleinen Buchstaben und Entfernung von Leerzeichen) werden Einträge erkannt als „ohne Angabe“. Die Inhalte werden je nach Angaben mit allgemeinen Inhalten besetzt (ohne_angabe, ohne_ort, ohne_publisher und ohne_jahr - siehe oben).
Objekte mit Eigenschaft aus ['has_place_of_printing', 'has_place_of_activity', 'has_place_of_birth', 'has_place_of_death', 'has_localisation']	Ortsangaben ohne nachgelagerte ID-Werte werden auf Übereinstimmung in der Liste hinter dem orte_pfad (in konstanten.py -> ort.csv) geprüft und gegebenenfalls wird eine ID gesetzt.
deu;lat;...###Language	Sprachangaben werden ersetzt durch Angaben aus der Liste in sprachliste_pfad (in konstanten.py -> sprachcodes_loc.csv). Der Code muss also in dieser Liste vorhanden sein (ISO-639-2). ⚠️ Kann keine Übereinstimmung gefunden werden, wird ein Fehler geworfen und die Verarbeitung abgebrochen.
ca. 1710-1712###Zeitpunkt	Momentan werden Zeitspannen (1710-1712) als mehrere Angaben (1710, 1711 und 1712) gesetzt, gleiches gilt auch für ungenaue Angaben (“171…”). Es können also defacto nur Zeitpunkte verarbeitet werden. Ungenaue Angaben (Angaben die “ca” oder “…” enthalten) erhalten den Qualifizierer “ist” mit dem Wert in “unsicher” (siehe oben). Es wird eine Wikibasegenauigkeit von 9 gesetzt, die für Jahresangaben steht
123###Menge	Mengenangaben werden überprüft auf ihre Nummernhaftigkeit. True wird als 1, False als 0 gesetzt. ⚠️ Ist keine Nummer oder True/False für eine Eigenschaftsbeziehung mit Datentyp Menge/Quantity gegeben, wird ein Fehler geworfen und die Verarbeitung abgebrochen.
Text###Zeichenkette	Zeichenketten und Bezeichner/Aliasse werden auf die entsprechende Länge gekürzt (siehe oben)
has_inverse	Inversen werden automatisch entsprechend dem Datenmodell gesetzt. Sie bedürfen keiner weiteren Behandlung.

*Vorgaben der Wikibase:

$wgWBRepoSettings['string-limits']['multilang']['length'] = 2000;
$wgWBRepoSettings['string-limits']['VT:monolingualtext']['length'] = 2000;
$wgWBRepoSettings['string-limits']['VT:string']['length'] = 4000;

Siehe: https://doc.wikimedia.org/Wikibase/master/php/docs_topics_options.html#autotoc_md348

Hinweise zu Katalogdaten

Konstanten (konstanten.py)

Format: Konstantenname = Konstanteninhalt

1. Konstanten für die komplette Weiterverarbeitung
2. Einige Konstanten sind Allgemeingültig, einige werden nur für spezielle Aufgaben benötigt und müssen an die Daten angepasst werden

	Form	Inhalt / Bedeutung
	kat_name	"Katalogname" – Bezeichner des Kataloges
	kat_link	"link-zu-externer-grafik.de" – [optional] Link zu Katalog (has_id)
	ort	"Ort der Dokumente" – [optional] Physischer Standort. ⚠️ Wird automatisch gesetzt

Mapping der Kopfzeile auf das Datenmodell

Format:Spaltenname;Eigenschaft1#Zielobjektspaltenname1:Zielobjektspaltenname2;Eigenschaft2#Zielobjekteigenschaft2

1. Kopfzeile wird auf das Datenmodell gemappt, sodass die Spalten Eigenschaftswerte zugeordnet bekommen.
2. Eigenschaftswerte werden in Tabelle mit den Wegen näher beschrieben.
3. Es können mehrere Inhalte zusammengefasst werden, indem die Spalten gleich benannt, aber durchnummeriert werden.
4. Angaben hier werden überschrieben von Angaben in der Objektliste

-> Pfad wird in konstanten.py gesetzt (mapping_datei_pfad)

Form	Inhalt / Bedeutung
id;[empty]	Spalte „id" wird weggelassen
pageCat;has_page_number	„pageCat" → has_page_number
imageCat;has_imageURL	„imageCat" → has_imageURL
numberCat;has_number	„numberCat" → has_number
itemInVolume;[empty]	Spalte „itemInVolume" wird weggelassen
titleCat;[empty]	Spalte „titleCat" wird weggelassen
titleBib;has_titleBib	„titleBib" → has_titleBib
titleNormalized;[empty]	Spalte „titleNormalized" wird weggelassen
author;has_author	„author" → has_author
contributor;has_contributor	„contributor" → has_contributor
place;has_place_of_printing	„place" → has_place_of_printing
publishers;has_publisher	„publishers" → has_publisher
year;has_year_of_printing	„year" → has_year_of_printing
format;has_historical_format	„format" → has_historical_format
histSubject;has_collection_classification	„histSubject" → has_collection_classification
subjects;[empty]	Spalte „subjects" wird weggelassen
genres;has_genre	„genres" → has_genre
mediaType;has_MediaType	„mediaType" → has_MediaType
languages;has_language	„languages" → has_language
systemManifestation;has_id#systemManifestation:idManifestation	„systemManifestation" wird mit „idManifestation" auf has_id gemappt
institutionOriginal;"has_shelfmark#institutionOriginal:shelfmarkOriginal"	„institutionOriginal" wird mit „shelfmarkOriginal" auf has_shelfmark gemappt
provenanceAttribute;has_provenance	„provenanceAttribute" → has_provenance
digitalCopyOriginal;has_digital_copy	„digitalCopyOriginal" → has_digital_copy
targetOPAC;[empty]	Spalte „targetOPAC" wird weggelassen
searchID;[empty]	Spalte „searchID" wird weggelassen
titleWork;[empty]	Spalte „titleWork" wird weggelassen
systemWork;[empty]	Spalte „systemWork" wird weggelassen
idWork;[empty]	Spalte „idWork" wird weggelassen
bound;is_bound	„bound" → is_bound
comment;has_comment	„comment" → has_comment
digitalCopy;[empty]	Spalte „digitalCopy" wird weggelassen
copiesHAB;[empty]	Spalte „copiesHAB" wird weggelassen

Objektliste

Format: Klasse;Spaltenoption1,Spaltenoption2Teil1:Spaltenoption2Teil2;... 1. Liste mit Objekten, die für einen Datensatz angelegt werden. 2. Es gibt unterschiedliche Dateien, die entsprechend den Datensätzen gesetzt werden können. 3. Es werden die Spalten angegeben, in denen nach dem Bezeichner für die vordefinierten Instanzen gesucht wird. 4. Wird kein Bezeichner gefunden, können die Instanzen nicht gesetzt werden. Falls Pfade (siehe unten) von ihnen abhängen, kann dies zu Fehlern führen. 5. Angaben hier überschreiben Angaben in dem Mapping der Kopfzeile.

-> Pfad wird in konstanten.py gesetzt (objektliste_pfad)

Form	Erklärung
Source_Entry;titleCat	„Source_Entry" findet sich in Spalte titleCat. ⚠️ „Source_Entry" ist der Startknoten für jede Datenzeile und daher immer zwingend erforderlich
Catalogue;name	„Catalogue" verwendet den Inhalt in kat_name
Item;titleBib;titleCat	„Item" prüft titleBib, wird dort kein Inhalt gefunden, wird titleCat verwendet. ⚠️ „Item" ist Teil des WEMI-Schemas und daher immer zwingend erforderlich
Manifestation;titleBib;titleCat	„Manifestation" entsprechend Item. ⚠️ „Manifestation" ist Teil des WEMI-Schemas und daher immer zwingend erforderlich
Expression;titleNormalized;titleBib;titleCat	„Expression" prüft titleNormalized und geht bei Misserfolg entsprechend Manifestation vor. ⚠️„Expression" ist Teil des WEMI-Schemas und daher immer zwingend erforderlich
Work;titleNormalized;titleBib;titleCat	„Work" entsprechend Expression. ⚠️ „Work" ist Teil des WEMI-Schemas und daher immer zwingend erforderlich
Shelfmark;institutionOriginal:shelfmarkOriginal	„Shelfmark" setzt sich zusammen aus institutionOriginal und ShelfmarkOriginal, getrennt durch einen Doppelpunkt.

Wege innerhalb des Datenmodells

Format: Startknoten;Wegeigentschaft1;Zwischenobjekt1;Wegeigenschaft2;Zwischenobjekt2;...;Zieleigenschaft1#InstanznameOderDatentypZuZieleigenschaft1 Startknoten;Wegeigentschaft1;Zwischenobjekt1;Wegeigenschaft2;Zwischenobjekt2;...;Zieleigenschaft2#InstanznameOderDatentypZuZieleigenschaft2 ...

1. Hier werden die Pfade von einem Startknoten zu einem Zielknoten innerhalb des Datenmodells nachgezeichnet. Das ist nötig, weil es häufig mehrere mögliche Wege gibt und identische Eigenschaften an mehreren Objekten angehängt sein können.
2. Es wird der erste Treffer verwendet. Mehrere Setzungen zu gleichbenannten Eigenschaften sind daher nicht möglich.
3. Startknoten ist immer Source_Entry.
4. Entlang des WEMI-Schemas wird immer der Pfad entsprechend Source_Entry refers_to Item exemplifies Manifestation is_embodied_in Expression realises Work verwendet. Dieser Pfad wird immer angegeben und daher benötigt.

-> Pfad wird in konstanten.py gesetzt (weg_pfad)

Form	Erklärung
Source_Entry;has_page_number#Zeichenkette	Weg zu has_page_number [Zeichenkette]
Source_Entry;has_imageURL#URL	Weg zu has_imageURL [URL]
Source_Entry;has_number#Zeichenkette	Weg zu has_number [Zeichenkette]
Source_Entry;has_source#Catalogue	Weg zu has_source [Catalogue]
Source_Entry;refers_to;Item;exemplifies;Manifestation;has_titleBib#Zeichenkette	(über Manifestation) Weg zu has_titleBib [Zeichenkette]
Source_Entry;refers_to;Item;has_author#Person	(über Item) Weg zu has_author [Person]
Source_Entry;refers_to;Item;has_localisation#Place	(über Item) Weg zu has_localisation [Place]
Source_Entry;refers_to;Item;has_contributor#Person	(über Item) Weg zu has_contributor [Person]
Source_Entry;refers_to;Item;exemplifies;Manifestation;has_place_of_printing#Place	(über Manifestation) Weg zu has_place_of_printing [Place]
Source_Entry;refers_to;Item;exemplifies;Manifestation;has_publisher#Person	(über Manifestation) Weg zu has_publisher [Person]
Source_Entry;refers_to;Item;exemplifies;Manifestation;has_year_of_printing#Zeitpunkt	(über Manifestation) Weg zu has_year_of_printing [Zeitpunkt]
Source_Entry;has_historical_format#Zeichenkette	Weg zu has_historical_format [Zeichenkette]
Source_Entry;has_collection_classification#Subject	Weg zu has_collection_classification [Subject]
Source_Entry;refers_to;Item;exemplifies;Manifestation; is_embodied_in;Expression;realises;Work;has_subject#Subject	(über Work) Weg zu has_subject [Subject]
Source_Entry;refers_to;Item;exemplifies;Manifestation;is_embodied_in;Expression;has_genre#Genre	(über Expression) Weg zu has_genre [Genre]
Source_Entry;refers_to;Item;exemplifies;Manifestation;has_MediaType#MediaType	(über Manifestation) Weg zu has_MediaType [MediaType]
Source_Entry;refers_to;Item;exemplifies;Manifestation;has_language#Language	(über Manifestation) Weg zu has_language [Language]
Source_Entry;refers_to;Item;exemplifies;Manifestation;has_id#Zeichenkette	(über Manifestation) Weg zu has_id [Zeichenkette]
Source_Entry;refers_to;Item;has_shelfmark#Shelfmark	(über Item) Weg zu has_shelfmark [Shelfmark]
Source_Entry;refers_to;Item;has_shelfmark;Shelfmark;is_currently_used#Menge	(über Shelfmark) Weg zu is_currently_used [Menge]
Source_Entry;refers_to;Item;has_provenance#Provenance	(über Item) Weg zu has_provenance [Provenance]
Source_Entry;refers_to;Item;has_digital_copy#URL	(über Item) Weg zu has_digital_copy [URL]
Source_Entry;refers_to;Item;is_bound#Menge	(über Item) Weg zu is_bound [Menge]
Source_Entry;refers_to;Item;has_comment#Zeichenkette	(über Item) Weg zu has_comment [Zeichenkette]
Source_Entry;refers_to;Item;exemplifies;Manifestation;is_embodied_in;Expression;realises#Work	WEMI-Schema wird immer gesetzt

---

Hinweise zu Personendaten

Mapping der Kopfzeile auf das Datenmodell

Format: Spaltenname;Eigenschaft1#Zielobjektspaltenname1:Zielobjektspaltenname2;Eigenschaft2#Zielobjekteigenschaft2

1. Kopfzeile wird auf das Datenmodell gemappt, sodass die Spalten Eigenschaftswerte zugeordnet bekommen.
2. Eigenschaftswerte werden in Tabelle mit den Wegen näher beschrieben.
3. Es können mehrere Inhalte zusammengefasst werden, indem die Spalten gleich benannt, aber durchnummeriert werden.
4. Angaben hier werden überschrieben von Angaben in der Objektliste.

-> Pfad wird in konstanten.py gesetzt (mapping_datei_pfad)

	Form	Inhalt / Bedeutung
	ID = [leer]	| <!-- -->|Vorname(n) = [leer]|Spalte „Vorname(n)“ wird weggelassen | | <!-- -->|Titel = [empty]|Spalte „Titel“ wird weggelassen | | <!-- -->|name_reconcile = [leer]|Spalte „name_reconcile“ wird weggelassen | | <!-- -->|has_birth_name|Geburtsname| | <!-- -->|has_title|Adelstitel| | <!-- -->|Lebensdaten = [leer]|Spalte „Lebensdaten“ wird weggelassen | | <!-- -->|has_imageURL|Darstellung| | <!-- -->|has_occupation|Beruf oder Beschäftigung| | <!-- -->|has_place_of_birth|Geburtsort| | <!-- -->|has_place_of_death|Sterbeort| | <!-- -->|has_place_of_activity|Wirkungsort| | <!-- -->|has_id|GND-Nummer| | <!-- -->|Titelangabe = [leer]| Spalte „Titelangabe“ wird weggelassen | | <!-- -->|Siehe auch = [leer]|Spalte „Siehe auch“ wird weggelassen | | <!-- -->|In Beziehung stehendes Werk = [leer]|Spalte „In Beziehung stehendes Werk“ wird weggelassen | | <!-- -->|Familiäre Beziehung = [leer]|Spalte „Familiäre Beziehung“ wird weggelassen | | <!-- -->|has_year_of_birth|geburt| | <!-- -->|has_year_of_death|tod| | <!-- -->|has_ownership_of|kataloge`

Objektliste

Format: Klasse;Spaltenoption1,Spaltenoption2Teil1:Spaltenoption2Teil2, ... 1. Liste mit Objekten, die für einen Datensatz angelegt werden. 2. Es gibt unterschiedliche Dateien, die entsprechend den Datensätzen gesetzt werden können. 3. Es werden die Spalten angegeben, in denen nach dem Bezeichner für die vordefinierten Instanzen gesucht wird. 4. Wird kein Bezeichner gefunden, können die Instanzen nicht gesetzt werden. Falls Pfade (siehe unten) von ihnen abhängen, kann dies zu Fehlern führen. 5. Angaben hier überschreiben Angaben in dem Mapping der Kopfzeile.

-> Pfad wird in konstanten.py gesetzt (objektliste_pfad)

	Form	Inhalt / Bedeutung
	Person;name_reconcile	„Person“ prüft name_reconcile ⚠️ „Person“ ist der Startknoten für jede Datenzeile und daher immer zwingend erforderlich
	Catalogue;kataloge	„Catalogue“ prüft kataloge

Wege innerhalb des Datenmodells

Format: Startknoten;Wegeigentschaft1;Zwischenobjekt1;Wegeigenschaft2;Zwischenobjekt2;...;Zieleigenschaft1#InstanznameOderDatentypZuZieleigenschaft1 Startknoten;Wegeigentschaft1;Zwischenobjekt1;Wegeigenschaft2;Zwischenobjekt2;...;Zieleigenschaft2#InstanznameOderDatentypZuZieleigenschaft2 ... 1. Hier werden die Pfade von einem Startknoten zu einem Zielknoten innerhalb des Datenmodells nachgezeichnet. Das ist nötig, weil es häufig mehrere mögliche Wege gibt und identische Eigenschaften an mehreren Objekten angehängt sein können. 2. Es wird der erste Treffer verwendet. Mehrere Setzungen zu gleichbenannten Eigenschaften sind daher nicht möglich. 3. Startknoten ist immer Person

-> Pfad wird in konstanten.py gesetzt (weg_pfad)

Form	Erklärung
Person;has_title#Zeichenkette	Weg zu has_title [Zeichenkette]
Person;has_id#URL	Weg zu has_id [URL]
Person;has_picture#URL	Weg zu has_picture [URL]
Person;has_imageURL#URL	Weg zu has_imageURL [URL]
Person;has_occupation#Zeichenkette	Weg zu has_occupation [Zeichenkette]
Person;has_place_of_birth#Place	Weg zu has_place_of_birth [Place]
Person;has_place_of_death#Place	Weg zu has_place_of_death [Place]
Person;has_place_of_activity#Place	Weg zu has_place_of_activity [Place]
Person;has_year_of_birth#Zeitpunkt	Weg zu has_year_of_birth [Zeitpunkt]
Person;has_year_of_death#Zeitpunkt	Weg zu has_year_of_death [Zeitpunkt]
Person;shows_ownership_of#Provenance	Weg zu shows_ownership_of [Provenance]
Person;has_birth_name#Zeichenkette	Weg zu has_birth_name [Zeichenkette]
Person;has_ownership_of#Catalogue	Weg zu has_ownership_of [Catalogue]
Person;has_ownership_of;Catalogue;has_localisation#Place	(über Catalogue) Weg zu has_localisation [Place]

<references />