museum-digital/handbook-de
33
0
Fork 0
Code Issues 1 Pull Requests Projects Releases Wiki Activity

Merge branch 'master' of https://gitea.armuli.eu/museum-digital/handbook-de

Browse Source
This commit is contained in:
Stefan Rohde-Enslin 2022-01-27 07:54:03 +01:00
commit 7aba2c2424
8 changed files with 188 additions and 112 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
src/SUMMARY.md
View File

@ -126,8 +126,11 @@
# Datenimporte
- [Importe: Einleitung](./import/README.md)
- [Der Import-Prozess](./import/importprozess.md)
- [Liste der importierbaren Formate](./import/liste-der-importformate.md)
- [CSVXML](./import/CSVXML.md)
- [Liste der importierbaren Formate]()
- [Technischer Aufbau](./import/Aufbau.md)
- [Automatische Bereinigung der Daten](./import/Automatische-Bereinigung.md)
-----------

18
src/assets/imports/README.template.de.md Normal file
View File

@ -0,0 +1,18 @@
# Import für das <Institution> (<Datum>)
* Ansprechpartner beim Museum:
* Ansprechpartner bei md:
## Anmerkungen
## Umgebung
* Methode: <csvxml, adlib, ...>
* Instanz: <sachsen, berlin, ...>
* Institution: <123>
* Sichtbarkeit: <Sichtbar, Unsichtbar>
## Ablauf
* Geschickt: 2022-MM-TT
* Importiert: 2022-MM-TT

20
src/import/Aufbau.md Normal file
View File

@ -0,0 +1,20 @@
# Technischer Aufbau des Import-Tools
Technisch besteht das Import-Tool aus zwei zentralen Bereichen: Einem von allen Import-Scripten gemeinsam genutzten "Kern" und einem jeweils für die verschiedenen Importformate spezifischen "Parser". Durch diese Struktur werden sowohl das Abdecken von neuen Importformaten als auch die Sicherstellung der formellen Korrektheit der Daten wesentlich erleichtert.
## Der "Kern" des Import-Tools
Der "Kern" des Import-Tools bildet die Datenbankstruktur von museum-digital in einer von anderen Scripten einfach ansprechbaren Form ab, und ist für die Kommunikation des Imports mit der Datenbank zuständig. Er überprüft die eingehenden Daten ebenfalls auf formelle Korrektheit.
Formelle Korrektheit bedeutet in diesem Fall zum Beispiel die Benutzung der erlaubten Werte aus den bei museum-digital genutzten Listen von Lizenzen, Währungen, Längeneinheiten etc. Heißt die bei museum-digital "CC BY-NC-SA" und in den Import-Daten "CC-BY-NC-SA", dann wird laut den Importdaten eine formell nicht zugelassene Lizenz benutzt. Für gebräuchliche Fälle (wie z.B. das eben genannte Beispiel) verfügt der "Kern" über Korrekturlisten, sodass die Zuordnung doch gelingt. Ist der Begriff aber bisher auch in diesen Listen nicht bekannt, wird der Importvorgang abgebrochen, sodass die Daten entweder angepasst werden oder das Format in die jeweilige Liste mit Korrektur-Zuordnungen eingetragen werden kann.
Formelle Korrektheit bedeutet aber auch die Umsetzung der bei museum-digital geltenden Regeln im Bezug auf die Qualität der zu veröffentlichenden Daten. Bei museum-digital können standardmäßig keine Objekte ohne Abbildung veröffentlicht werden. Steht in den Importdaten, dass das Objekt _veröffentlicht_ werden soll, aber keine Referenz für Abbildungen des Objektes, erkennt der "Kern" dies automatisch und stellt sicher, dass das Objekt nur _nicht öffentlich_ importiert wird.
Der "Kern" erkennt zudem auf Basis der Inventarnummer, ob ein zu importierendes Objekt schon in den Daten des Museums in museum-digital erfasst ist. Ist das der Fall, wird der vorhandene Datensatz mit den Importdaten überschrieben, sonst wird ein neuer angelegt.
Bei all dem fungiert der "Kern" aber als Programmbibliothek: Er bietet keine eigene Oberfläche (ob Web-basiert oder auf der Kommandozeile), sondern muss durch andere Scripte benutzt werden.
## Parser
Der für jedes Import-Format spezifische Teil des Importers sind die "Parser". Diese sind zuständig für das Auslesen der Daten aus einem angegebenen Import-Ordner (also das auslesen einer CSV-, JSON- oder XML-Datei), und benutzen die verschiedenen vom "Kern" bereitgestellten Funktionen, um die im Import bereitgestellten Daten den jeweiligen Datenbankfeldern in museum-digital zuzuordnen. Dadurch, dass der "Kern" die sichere Kommunikation mit der Datenbank und die Überprüfung der eingehenden Daten übernimmt, können Programmierer sich beim Schreiben eines neuen Parsers ganz auf das vorhandene Importformat und die Festlegung der Zuordnungen konzentrieren. Die meisten Parser geraten so zu recht kurzen und schnell geschriebenen Scripten.

39
src/import/Automatische-Bereinigung.md Normal file
View File

@ -0,0 +1,39 @@
# Bereinigung und Angleichung der Importdaten
Beim Importieren sind zwangsläufig immer wieder bisher unbekannte Werte in den Daten zu finden.
Bei Feldern wie Längeneinheiten oder Lizenzangaben kann das über einfache Korrekturlisten gelöst werden. "cn" ist bei Längeneinheiten ein Rechtschreibfehler, und sollte eigentlich "cm" sein. "CC-BY-NC-SA" heißt bei museum-digital "CC BY-NC-SA". Dasselbe gilt für [Ereignistypen](../Grundkonzepte/Ereignistypen.md), die in vielen anderen Programmen für die Inventarisierungsdaten über Rollenangaben für Personen abgebildet werden: Ist der Akteur bei der Herstellung als Maler gekennzeichnet, heißt das, dass es sich um ein "wurde Gemalt"-Ereignis handelt. Alle diese Beispiele haben in museum-digital vorgegebene Listen von erlaubten Werten, bei denen anderslautende Angaben als Fehler gewertet werden. Andererseits ist die Menge der von den bei museum-digital erlaubten Werten abweichenden Angaben überschaubar.
Ganz anders verhält es sich mit importierten Akteuren, Orten, Zeiten und Schlagworten. Hier wird museum-digital mit Sicherheit niemals Vollständig sein, und viele bisher unbekannte Einträge sind korrekt und sinnvoll.
Und doch sind es eben auch viele nicht - oder sie sind tatsächlich eigentlich schon bekannt. Um doch die richtigen Zuordnungen zu finden und die Einträge gleich so korrekt wie möglich zu importieren, werden verschiedene Methoden zur (halb-)automatischen Bereinigung eingetzt, von denen viele mittlerweile auch Einzug in musdb gehalten haben.
## Importieren nach Linked-Open-Data-IDs
Im Idealfall werden in den Importdaten schon Bezüge zu anderen Normdatenrepositorien wie Wikidata, den Library of Congress Subject Headings oder der Gemeinsamen Normdatei (GND) angegeben.
In diesem Fall werden die angegeben Bezüge mit den bei museum-digital schon erfassten Bezügen abgeglichen. Ist im den Importdaten dieselbe Referenz zur GND zu finden wie im Personenvokabular von museum-digital, handelt es sich um dieselbe Person.
Sind - wie bei den meisten Importen - keine Bezüge zu externen Normdatenrepositorien vorhanden, muss der angegebene Name (bei Personen: Name und Lebensdaten) als Basis für das Auffinden schon erfasster Begriffe genutzt werden.
## Vollständig automatische Korrekturen und Angleichungen
In einigen Fällen lassen sich Einträge durch automatische Korrekturen zuordnen oder gleich vollständig anreichern.
Ein erster Schritt in diese Richtung ist das allgemeine Entfernen von Leerzeichen am Anfang und Ende aller Eingaben.
Danach werden die Eingaben darauf geprüft, ob sie in den Listen der gesperrten Begriffe verzeichnet sind. Die Angabe von "_Unbekannt_" oder "_Sonstige_" ist etwa in allen vier Vokabularen verboten. Ist die Eingabe in den jeweiligen Sperrlisten verzeichnet, wird sie beim Import ignoriert.
Ist sie es nicht, folgt die Überprüfung auf Marker für Unsicherheit. Ist die Ortsangabe in den Importdaten etwa "`Berlin?`", wird das Fragezeichen am Ende des Namens automatisch als Zeichen für die Unsicherheit der Angabe erkannt. Die Ortsangabe wird in den Ortsnamen "`Berlin`" geändert, und kann so dem schon bekannten Ort Berlin zugeordnet werden. Die Ortsbeziehung wird dann als "unsicher" markiert.
Einen Sonderfall stellen Zeitbegriffe dar, die allgemein fast standardisiert gebraucht werden. Für diese gibt es eine wesentlich weitergehende Autokorrektur, die bekannte Varianten von Datumsangaben automatisch angleicht. "`1. Februar 1922`" kann so etwa automatisch zum in museum-digital gebräuchlichen Format "`01.02.1922`" umgewandelt werden.
## Korrekturen der Normdatenredaktion nachhaltig machen
In vielen Fällen helfen aber auch die vollautomatischen Bereinigungen nicht, um schon bekannte Einträge zu identifizieren. Ein klassisches Beispiel hierfür sind Titel bei Akteursangaben (bei museum-digital werden Personen ohne Titel erfasst): Fedor Jagor ist bei museum-digital erfasst. Steht in den Importdaten "Professor Fedor Jagor", wird das als neue Person ins Personenvokabular importiert.
Die Normdatenredaktion vereinigt beim Bereinigen der Daten den neuen Datensatz mit dem Alten. Bei diesem Vereinigen kann über das Drücken eines Buttons eingetragen werden, dass diese Vereinigung auch für alle neuen Eingaben gelten soll. Sollte jemand wieder versuchen, "Professor Fedor Jagor" einzugeben oder zu importieren, wird ab jetzt immer der Eintrag von Fedor Jagor gefunden und zugeordnet.
Aber selbst wenn dieser Button nicht gedrückt wurde, werden Verschmelzungen von Einträgen für Importe eines Hauses geloggt und festgeschrieben. Das ist hilfreich bei Eingaben wie "Frankfurt". Es könnte Frankfurt am Main sein, aber vielleicht auch Frankfurt an der Oder. Welches Frankfurt wirklich gemeint ist, wird sich von Benutzer zu Benutzer unterscheiden - aber es ist eine gerechtfertigte Annahme, dass die Benutzung innerhalb eines Museums konsistent erfolgt. Ein Museum in Frankfurt am Main wird mit "Frankfurt" sicher immer "Frankfurt am Main" meinen.
Wird das unzulässig verkürzte "Frankfurt" also mit "Frankfurt am Main" verschmolzen, um alle mit "Frankfurt" verknüpften Daten mit "Frankfurt am Main" zu verknüpfen, wird gespeichert, dass im importierenden Museum "Frankfurt" gleichbedeutend zu "Frankfurt am Main" ist. Bei zukünftigen Importen desselben Museums wird "Frankfurt" automatisch durch "Frankfurt am Main" ersetzt.

119
src/import/README.md
View File

@ -1,116 +1,15 @@
# Importe: Einleitung
# Importe bei museum-digital
Was ist ein Import?
-------------------
Möchte man mit museum-digital arbeiten - egal, ob es um die reine Publikation von Daten geht oder um das Inventarisieren - und hat man bestehende Daten, stellt sich schnell die Frage, ob und wie die Daten aus einem externen System in museum-digital importiert werden können.
Wenn Ihr Museum aktuell eine andere Datenbank zur Inventarisierung
verwendet, aber gerne auf die Arbeit mit museum-digital umsteigen
möchte, so gibt es die Möglichkeit eines Imports der Daten aus dem
bisherigen Programm. Gleiches gilt, wenn Sie bei Ihrer
Inventarisierungssoftware bleiben, aber museum-digital zum
Veröffentlichen Ihrer Daten nutzen möchten. Dabei werden gebündelt alle
Daten und Bilder aus der alten Datenbank in museum-digital importiert --
vorausgesetzt, die Daten erfüllen die notwendigen Vorgaben.
In diesem Kapitel wird erst der Import-Prozess beschrieben:
Ein Import kann grundsätzlich stattfinden, wenn die Metadateien im XML
oder CSV-Format und Bilddateien im JPG-Format vorliegen.
- Wer kann importieren?
- Was kann importiert werden?
- Welche Arbeit macht das importieren?
Wer importiert?
---------------
Darauf folgende Unterkapitel beleuchten verschiedene Aspekte des Importierens in museum-digital. Der Fokus fällt zuerst auf die Frage, welche Datenformate importiert werden können und wie die Daten vor einem Import vorbereitet werden sollten, damit der Import reibungslos vonstatten gehen kann.
Das Importieren Ihrer bisherigen Datenbestände wird aktuell nur von den
technischen Entwicklern von museum-digital durchgeführt. Zur
Vorbereitung eines Imports nehmen Museen in Baden-Württemberg,
Brandenburg, Bremen, Mecklenburg-Vorpommern, Rheinland-Pfalz, Sachsen,
Sachsen-Anhalt, Westfalen und Ostwestfalen-Lippe bitte mit ihrem/ihrer
jeweils zuständigen Regionaladministrator\*in Kontakt auf. Museen aus
den übrigen Regionen in Deutschland wenden sich an Stefan Rohde-Enslin.
Daraufhin folgt ein genauerer Blick auf den technischen Aufbau des Import-Tools. In diesem Zuge wird auch erklärt, wie ein neues Import-Script geschrieben werden kann.
[**\> Hier geht es zu den richtigen
Ansprechpartner\*innen!**](https:/nat.museum-digital.de/index.php?t=kontakt)
Sie sollten aber Ihre Daten selbst für den Import vorbereiten. Im
Folgenden wird beschrieben, wie das funktioniert.
Welche Daten können importiert werden?
--------------------------------------
Daten können importiert werden, wenn sie als CSV- oder XML-Datei
vorliegen. In einer CSV-Datei sind die Werte in einer Textdatei
gespeichert und werden durch ein standardisiertes Trennzeichen (zum
Beispiel ein Komma) getrennt. Tabellenprogramme können CSV-Dateien
normalerweise öffnen und darstellen -- die durch das Trennzeichen
getrennten Werte werden dabei in separaten Zellen angezeigt.
Viele Inventarprogramme bieten die Möglichkeit, die Daten als CSV-Datei
zu exportieren. Wenn das funktioniert hat, ist der nächste Schritt, die
Datenfelder aus dem alten Programm den Datenfeldern in museum-digital
zuzuordnen (siehe Abschnitt \"Zuordnen der Datenfelder\").
Die jeweils zuständen Regionaladministator\*innen überprüfen gerne die
zu importierenden Daten auf ihre Qualität und auf ihre Übereinstimmung
mit den Standards von museum-digital. Bei Bedarf unterstützen sie auch
bei notwendigen Anpassungen, damit der Import reibungslos funktioniert.
Welche Daten können nicht importiert werden?
--------------------------------------------
Daten von händisch geführten, analogen Listen oder Karteikarten können
nicht automatisiert importiert werden. Sie müssen zuerst in ein
Tabellenprogramm übertragen werden. Dabei entspricht eine Spalte einem
Datenfeld in museum-digital. Eine Zeile entspricht einem Datensatz. Wenn
in einem Tabellenprogramm inventarisiert wurde, dürfen Zellen nicht
miteinander verbunden sein. Spalten und Zeilen dürfen nicht ausgeblendet
sein.
Wenn eine Tabelle wie ein Formular verwendet wurde, d.h. mit
verbundenen Zellen und unterschiedlichen Informationen in einer Spalte,
dann müssen diese Daten zuerst händisch korrigiert werden, bevor sie
importiert werden können.
![](../assets/imports/verbundene_zellen.png)
Auf diesem Bild sieht man, dass in Spalte A zwei verschiedene Arten von
Informationen erfasst werden, die eigentlich in zwei verschiedene
Spalten gehören. Das sind \"Datum (Ankauf)\" und \"Beschreibung\".
Außerdem wurden für das Feld \"Beschreibung\" mehrere Zellen miteinander
verbunden. Die Daten dieses Beispiels können daher nicht importiert
werden.
![](../assets/imports/nicht_verbundene_Zellen.png)
In dieser Tabelle enthält jede Spalte nur eine Art von Informationen.
Es gibt keine verbundenen Zellen. Mit dieser Tabelle kann nun
weitergearbeitet werden.
Import von Bildern
------------------
Das massenhafte Hochladen von Bildern zu bereits bestehenden
Datensätzen ist nicht programmiert, das gleichzeitige Hochladen von
Bildern und zu importierenden Datensätzen ist leicht möglich. Bilder im
Internet benötigen allerdings immer Angaben zu den
Bildrechten.
Auf der im Folgenden verlinkten Seite finden sich die Titel für die
entsprechenden Spalten der vorzubereitenden CSV-Tabelle im Bereich
„Abbildungen". Man muss dort in der Spalte den tatsächlichen Bildnamen
eintragen, also „123456.jpg" und nicht den Pfad (z.B.
„c:\\\\123456.jpg") und der Import funktioniert auch nur mit
jpg-Dateien. Zudem müssen die jpg-Dateien die Mindestgröße von 540 Pixel
für die kurze Seite haben.
**[[ \> Hier geht es zur CSV-Vorlage sowie zum
Prüfassistenten.]](https://csvxml.imports.museum-digital.org/)**
Importe für große Museen
------------------------
Für große Museen mit umfangreichen Daten und Sammlungsbeständen besteht
gegebenenfalls die Möglichkeit, dass ein eigenes Importskript von den
Entwicklern von museum-digital programmiert wird. Nehmen Sie mit Ihren
Regionaladministrator\*innen oder  den Entwicklern Kontakt auf:
[**\> Hier geht es zu den richtigen
Ansprechpartner\*innen!**](https:/nat.museum-digital.de/index.php?t=kontakt)
Je nach dem, wie gut die Daten vorbereitet wurden, macht ein Import aber immer noch substanzielle Nacharbeiten nötig. Das letzte Unterkapitel beschreibt daher, wie das Import-Tool versucht, kontrollierte Begriffe automatisch korrekt zuzuordnen.

66
src/import/importprozess.md Normal file
View File

@ -0,0 +1,66 @@
# Wie läuft der Import-Prozess ab?
Um die Stabilität der Server von museum-digital sicherzustellen, werden strenge Beschränkungen auf die maximale Ausführungsdauer von einzelnen Scripten angewendet: Rufen Benutzer über das Netz ein langsames Script auf, wird die Berechnung nach spätestens 10 Sekunden abgebrochen, sodass die "teuren" Berechnungen dieses einen Scripts die verfügbaren Ressourcen für andere Scripte und andere Benutzer nicht weiter schmälern können.
Normalerweise ist das ein wichtiges Sicherheitsfeature. Beim Importieren führt es dazu, dass Importe nur von der Kommandozeile aus durchgeführt werden können[^fn-web-imports]. Das heißt auch, dass Importe auf dem Server letztlich vom Admin-Team von museum-digital durchgeführt werden.
[^fn-web-imports]:Sehr kleine Importe oder Importe ohne verknüpfte Bilddateien könnten theoretisch auch über das Web getätigt werden, aber bisher ist das nicht implementiert.
Damit das Admin-Team nicht vollends überlastet ist, hat sich ein mehrstufiger Prozess etabliert.
Bevor ein Import möglich ist, muss sichergestellt werden, dass das Museum in einer Instanz von museum-digital angelegt ist. [Hierzu benötigt es eine Mail an die jeweiligen Betreuer der lokalen Regional-Instanz von museum-digital und grundlegende Informationen zum Museum: Ein Name, eine Adresse, eine Kurzbeschreibung und ein Bild.](../musdb/Benutzerkonto/Zugang-erhalten.md)
## Lohnt sich ein Import?
Wie es weiter geht hängt stark von der Beschaffenheit und Menge der zu importierenden Daten ab:
- Handelt es sich um 50 mittelmäßig erfasste Objekte, lohnt sich oft ein händisches Eingeben der Objekte mehr als ein Import.
- Geht es um ungefähr 300 bis 500 Objekte, lohnt sich ein Anpassen der Daten an das Standard-Importformat von museum-digital. Das kann über einfache getan werden. Für diese Importtabellen bietet museum-digital ein Validierungs- und Umwandlungstool, [CSVXML](./CSVXML.md).
- Handelt es sich um tausende gut erfasste Objekte, lohnt sich ein händisches Anpassen der Daten definitiv weniger als das Schreiben eines für die Daten angepassten Imports.
- Liegen die Daten in einem Format vor, für das es schon ein eigenes Importscript gibt (z.B. LIDO oder die CSV-Exporte von Google Arts and Culture), ist ein Import mit dem vorhandenen Script meist sinnvoller als das anpassen der Daten an die Import-CSV-Tabelle von museum-digital.
- Liegen die Daten in einem automatisiert quasi nicht auslesbaren Format vor (z.B. Word-Dateien oder PDFs) lohnt sich ein Import nicht.
- Ob ein Objekt-Datensatz neu importiert oder geupdatet wird, erkennt das Import-Tool auf Basis von Inventarnummern. Sind Inventarnummern innerhalb desselben Museums doppelt vergeben, kann nicht importiert werden - sonst würden gegebenenfalls die Daten eines anderen Objektes, das dieselbe Inventarnummer hat wie ein neu zu importierendes, überschrieben.
## Vom Museum zum Regionaladministrator zum Import-Server
Wird ein Import also als lohnend eingeschätzt, werden wieder die lokalen Regional-Administratoren kontaktiert, die die Daten noch einmal genauer überprüfen und dann - wenn sie für einen Import vorbereitet sind - in einen mit den Importierenden geteilten Ordner hochladen.
Für ein einfaches Wiederfinden der Importdateien (etwa, falls es zu einem Problem im Importprozess gekommen ist und der Import wiederholt werden soll) und für ein möglichst schnelles Verständnis durch die Importierenden werden die Daten hier in einem regelmäßigen Format angelegt:
- Jeder Import hat einen ihm zugewiesenen Unterordner, der das Datum des Erhalts der Daten und ein bezeichnendes Merkmal wie z.B. den Namen des Museum im Ordnernamen trägt (also z.B. `[2022-01-01]Testmuseum`)
- Innerhalb dieses Unterordners befindet sich eine Datei, die den Import in einer regelmäßigen Form beschreibt, und mindestens eigene Unterordner für die zu importierenden Metadaten und die zu importierenden Bilddateien. Diese Ordner sollten ebenso wie der übergeordnete, allgemeine Importordner das Datum und das Museum im Namen tragen, aber für ein einfaches Kopieren in die Kommandozeile idealerweise keine Leerzeichen (gute Benennungen wären also `20220101_Testmuseum_XML` bzw. `20220101_Testmuseum_IMG`).
Die den Import beschreibende Datei wird als Datei `README.md` in den Ordner gelegt und nach der folgenden Vorlage ausgefüllt:
```
{{#include ../assets/imports/README.template.de.md}}
```
Mit den so gegebenen Daten kann der Import-Prozess - gegeben, dass es keine Probleme mit den Daten gibt - schnell von statten gehen.
Die Daten werden vom jeweiligen Importierenden aus dem geteilten Ordner auf den Server geladen und an die richtigen Stellen bewegt. Das Import-Tool importiert die Daten auf Basis einer vorgegeben Ordnerstruktur: Es gibt in jeder Instanz von [musdb](../musdb) einen zentralen Ordner, in dem Importdaten liegen. Innerhalb dieses Ordners gibt es einen Ordner `xml` für Metadaten und einen Ordner `files` für Digitalisate. Innerhalb dieser Ordner repräsentiert je ein Unterordner einen Import.
```
.
├── files
│ └── 20220101_Testmuseum_IMG
└── xml
└── 20220101_Testmuseum_XML
```
## Auf dem Server: Den Import durchführen
Ist der Import gut vorbereitet, und gibt es keine verbleibenden Probleme mit den Daten (TODO: Link zu Einschränkungen), muss jetzt nur noch ein Script auf der Kommandozeile ausgeführt werden. Beim Aufruf des Scripts sind eben die oben in der Readme-Datei angegebenen Informationen von Nöten:
- Der zu benutzende "Parser", also die zu benutzende Importroutine
- Die ID des Museums
- Der Name des Ordners, in dem sich die Importdaten befinden (Objektmetadaten)
- Der Name des Ordners, in dem sich die Digitalisate befinden (optional)
- Ob die Objekte direkt veröffentlicht werden sollen (optional, standardmäßig wird nicht öffentlich importiert)
- Die ID einer Sammlung, der die importierten Objekte zugeordnet werden sollen (optional, diese Angabe überschreibt die in den Importdaten angegebenen Sammlungszuordnungen)
Das Import-Tool importiert nun die Daten.
Dabei werden qualitativ unzureichende Objektinformationen in einer CSV-Tabelle geloggt, z.B. Objektbeschreibungen mit weniger als 25 Buchstaben. Ist eine Objektinformation grundsätzlich falsch (das betrifft vor allem korrupte oder zu kleine Bilddateien), bricht der Importer ab und es werden manuelle Verbesserungen nötig. Genauso haben viele "Parser" eine eingebaute Vollständigkeitsprüfung: Sind noch nicht importierte Daten zum Objekt in der Datei vorhanden, wenn die Objektinformationen soweit spezifiziert importiert wurden, bricht das Programm ab und erzwingt einen expliziten Umgang mit der gegebenen Information.
Ist der Parser vollständig, und sind alle Objektinformationen korrekt importierbar, vollbringt das Import-Tool sein Werk. Nach dem anschließenden Durchlaufen der üblichen Scripte für das Befüllen von Zwischenspeichern und die Analyse der Daten sind die Objekte ab diesem Zeitpunkt in musdb zum Weiterarbeiten verfügbar. Parallel dazu kann die Normdatenredaktion beginnen, neu importierte und zuvor noch unbekannte Orte, Personen, Zeiten, und Schlagworte anzureichern. Der Importierende gibt dem Museum und / oder dem Betreuer der regionalen Instanz per Mail Bescheid, dass der Import getan ist.

31
src/import/liste-der-importformate.md Normal file
View File

@ -0,0 +1,31 @@
# Liste der importierbaren Formate
In der folgenden Tabelle findet sich eine Liste der bisher vorhandenen "Parser" für die verschiedenen Formate von importierbaren Eingangsdaten.
Nur, weil ein Parser für die Exportdaten eines gegebenen Programms oder für einen gegebenen Austauschstandard besteht, heißt das nicht automatisch, dass die Daten immer korrekt und vollständig importiert werden. Gerade bei Austauschstandards wie LIDO gibt es oft substanzielle Unterschiede in der Interpretation des Standards durch verschiedene Programmierer, sodass die importierten Daten nach dem Importieren dringend noch einmal geprüft werden sollten.
Eine Abhilfe kann hierbei eine eingebaute Vollständigkeitsprüfung liefern, die in einigen Parsern eingebaut ist. Sind am Ende des Imports eines Objektes noch nicht spezifizierte Datenfelder vorhanden, wird in diesem Fall der Import abgebrochen und das Ergänzen des Parsers erzwungen. Ob eine solche Vollständigkeitsprüfung aber realistisch eingebaut werden kann, hängt auch stark vom Format der gegebenen Eingangsdaten ab. Je verschachtelter das Format, desto schwerer ist die Umsetzung der Vollständigkeitsprüfung. Ob ein Parser eine automatische Vollständigkeitsprüfung bietet ist in der Tabellenspalte _Prüfung_ zu sehen.
| Name | Datenformat | Prüfung | Notiz |
|-----------------------|-------------|-----------|-----------|
| Adlib | XML | Nein | Für die XML-Exportdaten aus [Axiell Adlib](https://www.axiell.com/de/loesungen/produkt/adlib/). Geschrieben und optimiert für das [Schwule Museum Berlin](https://www.schwulesmuseum.de/). |
| Beecollect | XML | Nein | Für die Exportdaten aus Solvatecs [Beecollect](http://www.solvatec.com/index.php?id=21). Beecollect-Parser müssen erfahrungsgemäß für jedes importierende Museum stark angepasst werden. |
| csvxml | XML | Ja | Der Referenz-Parser für das [Standard-Importformat](./CSVXML.md) von museum-digital. |
| csvxml_json | JSON | Ja | Eine JSON-basierte Variante des CSVXML-Formats. |
| First Rumos | XML | Ja | [First Rumos](https://www.firstrumos.de) hat einen Eingaben Export-Schalter für museum-digital. Dieser Parser importiert die so exportierten Daten. |
| First Rumos (CSV) | CSV | Ja | Ein Parser für die über den CSV-Export von [First Rumos](https://www.firstrumos.de) exportierten Daten. |
| Google Arts & Culture | CSV | Ja | Parser für CSV-Daten, wie sie von [Google Arts & Culture](https://artsandculture.google.com/) exportiert werden. |
| GOS | XML | Nein | Ein Parser für einen XML-Export der Daten des [Deutsch Russischen Museums in Berlin-Karlshorst](https://www.museum-karlshorst.de/). Inwiefern der Parser für andere Importe von GOS-Daten genutzt werden kann ist bisher unbekannt. |
| IKMK | JSON | Ja | Parser für die `json_ext`-Exportdaten aus den verschiedenen Instanzen des "Interaktiven Katalog des Münzkabinetts". |
| imdas pro | XML | Nein | Parser für die Export-Daten des [Landesmuseums Württemberg](https://www.landesmuseum-stuttgart.de/). Ob sich der Parser auch für die Exporte aus anderen Instanzen von [Imdas Pro](https://www.joanneum.at/digital/produkteloesungen/imdas-pro-archivis-pro) benutzen lässt, ist bisher unbekannt |
| Primus | XML | Ja | Parser für die aus [Primus](https://www.landesstelle.de/service/primus/) exportierten Daten. Deckt die Felder eines Gesamt-Exports ab. |
| LIDO | XML | Teilweise | Parser für nach dem Austauschstandard [LIDO](https://cidoc.mini.icom.museum/working-groups/lido/lido-overview/about-lido/) geformte Daten. Weil der LIDO-Standard von verschiedenen Entwicklern sehr verschieden ausgelegt wird, existieren verschiedene LIDO-Parser und neue Importe benötigen oft zusätzliche Anpassungen. |
| Museo | SQL | Nein | Parser für die seinerzeit für die Museen der Lausitz enwickelte Datenbank "Museo". |
| SRU-MODS | XML | Ja | Parser, der die Daten eines Hauses über eine externe SRU-Schnittstelle ausließt und importiert. Unterstützt bisher nur Metadaten. Entwickelt auf Basis von und optimiert für die SRU-Schnittstelle von [Kalliope](https://kalliope-verbund.info/). |
Dazu gibt es generische Parser, die für jeden Import neu angepasst werden müssen, aber eine gute Grundlage für sehr einfache Importe - wie zum Beispiel einfache, zuvor in Excel gepflegte Standortlisten - bieten:
| Name | Datenformat | Prüfung | Notiz |
|----------------------------|----------------------|---------|-------------------------------------------------------------------------------------------------------------------------------------|
| csv | CSV | Ja | Importiert gegebene Daten (welche muss für jeden Import neu definiert werden) nach Inventarnummer. |
| Bilder nach Inventarnummer | Keines / Dateisystem | Nein | Benutzt die Dateinamen, um Bilder stapelweise zu schon erfassten Objektdatensätzen zu importieren. Die Inventarnummern müssen dabei am Anfang des Dateinamens stehen und alle zu importierenden Bilder müssen im selben Ordner (ohne Unterordner) vorliegen. |

2
src/musdb/Objektsuche/Abfragesprache.md
View File

@ -8,7 +8,7 @@ Durch diese eigene Abfragesprache wird einerseits die Sicherheit erhöht - nur d
## Grundlegende Logik
Die grundlegende Logik der Such-Abfragesprache lässt sich am besten mit einem Beispiel erklären. Eine Suchabfrage mit drei zusammengesetzten Suchbedingungen mag etwa `Foto tag:132 -place:61 -name:München -length:>1000` sein. Wie im Beispiel zu sehen, werden einzelne Suchbedingungen durch ein Leerzeichen getrennt. Damit besteht eine einzelne Suchbedingung aus bis zu vier Elementen.
Die grundlegende Logik der Such-Abfragesprache lässt sich am besten mit einem Beispiel erklären. Eine Suchabfrage mit drei zusammengesetzten Suchbedingungen mag etwa `Foto tag:132 -place:61 -name:München -length:>1000` sein. Wie im Beispiel zu sehen, werden einzelne Suchbedingungen durch ein Leerzeichen getrennt (möchte man Suchen nach einem Suchbegriff, der aus mehreren Worten besteht, ausführen, muss man die Leerzeichen im Suchbegriff durch Unterstriche _ ersetzen). Damit besteht eine einzelne Suchbedingung aus bis zu vier Elementen.
Alle vier Elemente sind im Beispiel `-length:>1000` zu sehen: