Approval in quality-web

quality-web/de/quality_web.json

@@ -46,6 +46,6 @@
         "faq_a_birth_death_dates_via_vocabs": "Ja. Beim Auslesen der Daten mit bestehenden Normdatenbez\u00fcgen werden zus\u00e4tzliche Informationen zu den Akteuren - wie etwa Lebensdaten - aus den kontrollierten Vokabularen von museum-digital bezogen, so es dort bereits einen Datensatz f\u00fcr denselben Akteur gibt.",
         "outlook_text": "museum-digital:qa bietet eine Plattform, um Museumsdaten aus verschiedensten Quellen einfach ansprechen und weiterverarbeiten zu k\u00f6nnen - spezifisch, um sie Tests zur \u00dcberpr\u00fcfung der Datenqualit\u00e4t zu unterziehen. Durch die strikte Trennung der Komponenten - dem Auslesen der Daten einerseits, den Checks andererseits und schlie\u00dflich der Kommunkation zwischen den eben genannten -   ist es leicht um weitere Tools erweiterbar.\r\n\r\nMit einer OpenAPI-Definition f\u00fcr die Programmierschnittstelle k\u00f6nnen die durch museum-digital:qa verf\u00fcgbar gemachten Tools einfach durch Softwareanbieter und Forschende nachgenutzt werden.",
         "tech_background_text": "museum-digital:qa nimmt Daten aus g\u00e4ngigen und konsistent vorliegenden Eingabeformaten entgegen, bringt diese in ein internes, einheitliches Format, um diese schlie\u00dflich hinsichtlich ihrer Vollst\u00e4ndigkeit und Plausibilit\u00e4t auszuwerten. Eingabeformate k\u00f6nnen einerseits die Ausgabe- und Exportformate von verschiedenen Sammlungsmanagementsystemen, so diese f\u00fcr alle das Programm nutzenden Museen gleich geformt sind, oder die g\u00e4ngigen Austauschformate f\u00fcr Objektdaten sein. \r\n\r\nDie \u00fcblichen Sammlungsmanagementsysteme haben verschiedene Ans\u00e4tze, um mit spezifischen Anpassungen der Datenbank an einzelne Museen umzugehen. W\u00e4hrend museum-digital:musdb gezielt keine vom Museum selbst definierten Felder zul\u00e4sst, um eine konsistente Datenbankgestaltung \u00fcber Institutionsgrenzen hinweg zu erm\u00f6glichen, und so einerseits eine Vielzahl von Auswertungsfunktionen, die auf die Feldauswahl zugeschnitten sind anbieten zu k\u00f6nnen, und andererseits Export- und Suchfunktionen \u00fcber mehrere Museen hinweg zu erm\u00f6glichen, sind andere Sammlungsmanagementsysteme auch intern deutlich st\u00e4rker auf die sie nutzenden Museen zugeschnitten. Diese Anpassbarkeit kann entweder auf Ebene der Benutzeroberfl\u00e4che oder direkt auf der Ebene der Datenbankstruktur vorliegen. Ist auch die Datenbankstruktur anpassbar, hei\u00dft das gleichzeitig, dass die Exporte aus derselben Software je nach Museum sehr unterschiedlich geformt sein k\u00f6nnen. Wo nur die Benutzeroberfl\u00e4che angepasst wird, gibt es oft softwarespezifische Standard-Exportformate, die \u00fcber Museumsgrenzen hinweg konsistent geformt, gut gewartet und ggfs. vollst\u00e4ndiger als andere Exportoptionen sind (und somit etwa f\u00fcr eine Migration der Daten besonders gut geeignet sind).\r\n\r\nUm den Austausch von Daten \u00fcber Institutions- und Softwaregrenzen hinweg zu vereinfachen, haben sich verschiedene offene (Austausch-)Standards etabliert. Der f\u00fcr Museen sicherlich wichtigste ist dabei LIDO, in angrenzenden Bereichen werden etwa EAD (v.a. Archive) und MODS (v.a. Bibliotheken) verwendet. Diese Standards sind in den meisten F\u00e4llen f\u00fcr den Austausch ver\u00f6ffentlichbarer Daten gedacht, decken also in den seltensten F\u00e4llen alle lokal vorhandenen Datenfelder ab. Offene Standards sind andererseits in vielen Sammlungsmanagement-L\u00f6sungen implementiert. Mit dem 2023 ver\u00f6ffentlichten EODEM sind im Museumsbereich erste Schritte zu erkennen, auch prim\u00e4r interne Daten standardisiert austauschbar zu machen.\r\n\r\nZum Zwecke des Importierens von Daten (sei es zur Migration der Daten f\u00fcr die Inventarisierung oder zur Ver\u00f6ffentlichung) bietet museum-digital ein Import-Tool, das neben den g\u00e4ngigen Austauschformaten auch einige software-spezifische Formate beherrscht (einerseits, weil nicht alle Sammlungsmanagementsysteme die g\u00e4ngigen Austauschformate \"von Haus aus\" unterst\u00fctzen, anderseits, weil diese wie oben besprochen oft vollst\u00e4ndiger sind). Dieses Import-Tool besteht seinerseits aus drei Komponenten: 1) grundlegenden, f\u00fcr die Museumarbeit relevanten Datentypen (etwa Objekt, Schlagwort, Leihverkehr), 2) Funktionen zum Auslesen von Daten aus den erw\u00e4hnten Formaten und die \u00dcberf\u00fchrung der Eingabedaten in die eben genannten Datentypen, und 3) einem Modul zum tats\u00e4chlichen \u00dcberf\u00fchren der Daten in die Datenbank.\r\n\r\nDie Importer-Module zur Definition der Datentypen und zum Auslesen der Daten aus verschiedenen Eingabeformaten werden in museum-digital:qa nachgenutzt. So kann museum-digital:qa mit wenigen Anpassungen alle Importformate, die auch der Importer von museum-digital unterst\u00fctzt, unterst\u00fctzen (bei museumsspezifischen Importformaten lohnt es sich allerdings nicht, diese Anpassungen zu unternehmen). Ohne relevanten eigenen Code f\u00fcr das Auslesen der eingehenden Daten bleibt museum-digital:qa somit zudem sehr wartungsarm. Umgekehrt bedeutet die Nachnutzung des Auslese-Teils des Importers auch, dass alle Daten, die mit museum-digital:qa auf ihre Qualit\u00e4t \u00fcberpr\u00fcft werden k\u00f6nnen, ohne weitere Anpassungen in museum-digital importiert werden k\u00f6nnen.\r\n\r\nDie eingelesenen Daten liegen in der Folge in einer strukturierten Form vor und k\u00f6nnen verh\u00e4ltnism\u00e4\u00dfig einfach weiter verarbeitet werden, indem sie - leicht umformuliert - an die Funktionen zur \u00dcberpr\u00fcfung der Datenqualit\u00e4t weitergegeben werden. Diese Funktionen wurden im Zuge der Arbeit an museum-digital:qa aus museum-digital:musdb in eine eigene Open-Source-Bibliothek ausgelagert.",
-        "go_back": "Go back"
+        "go_back": "Zur\u00fcck"
     }
 }