Approval.

de/quality_web.php

@@ -59,4 +59,15 @@ Gibt es allerdings ein konsistentes Ausgabeformat, das hier noch nicht berücksi
   'outlook_text' => 'museum-digital:qa bietet eine Plattform, um Museumsdaten aus verschiedensten Quellen einfach ansprechen und weiterverarbeiten zu können - spezifisch, um sie Tests zur Überprüfung der Datenqualität zu unterziehen. Durch die strikte Trennung der Komponenten - dem Auslesen der Daten einerseits, den Checks andererseits und schließlich der Kommunkation zwischen den eben genannten -   ist es leicht um weitere Tools erweiterbar.
 
 Mit einer OpenAPI-Definition für die Programmierschnittstelle können die durch museum-digital:qa verfügbar gemachten Tools einfach durch Softwareanbieter und Forschende nachgenutzt werden.',
+  'tech_background_text' => 'museum-digital:qa nimmt Daten aus gängigen und konsistent vorliegenden Eingabeformaten entgegen, bringt diese in ein internes, einheitliches Format, um diese schließlich hinsichtlich ihrer Vollständigkeit und Plausibilität auszuwerten. Eingabeformate können einerseits die Ausgabe- und Exportformate von verschiedenen Sammlungsmanagementsystemen, so diese für alle das Programm nutzenden Museen gleich geformt sind, oder die gängigen Austauschformate für Objektdaten sein. 
+
+Die üblichen Sammlungsmanagementsysteme haben verschiedene Ansätze, um mit spezifischen Anpassungen der Datenbank an einzelne Museen umzugehen. Während museum-digital:musdb gezielt keine vom Museum selbst definierten Felder zulässt, um eine konsistente Datenbankgestaltung über Institutionsgrenzen hinweg zu ermöglichen, und so einerseits eine Vielzahl von Auswertungsfunktionen, die auf die Feldauswahl zugeschnitten sind anbieten zu können, und andererseits Export- und Suchfunktionen über mehrere Museen hinweg zu ermöglichen, sind andere Sammlungsmanagementsysteme auch intern deutlich stärker auf die sie nutzenden Museen zugeschnitten. Diese Anpassbarkeit kann entweder auf Ebene der Benutzeroberfläche oder direkt auf der Ebene der Datenbankstruktur vorliegen. Ist auch die Datenbankstruktur anpassbar, heißt das gleichzeitig, dass die Exporte aus derselben Software je nach Museum sehr unterschiedlich geformt sein können. Wo nur die Benutzeroberfläche angepasst wird, gibt es oft softwarespezifische Standard-Exportformate, die über Museumsgrenzen hinweg konsistent geformt, gut gewartet und ggfs. vollständiger als andere Exportoptionen sind (und somit etwa für eine Migration der Daten besonders gut geeignet sind).
+
+Um den Austausch von Daten über Institutions- und Softwaregrenzen hinweg zu vereinfachen, haben sich verschiedene offene (Austausch-)Standards etabliert. Der für 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ällen für den Austausch veröffentlichbarer Daten gedacht, decken also in den seltensten Fällen alle lokal vorhandenen Datenfelder ab. Offene Standards sind andererseits in vielen Sammlungsmanagement-Lösungen implementiert. Mit dem 2023 veröffentlichten EODEM sind im Museumsbereich erste Schritte zu erkennen, auch primär interne Daten standardisiert austauschbar zu machen.
+
+Zum Zwecke des Importierens von Daten (sei es zur Migration der Daten für die Inventarisierung oder zur Veröffentlichung) bietet museum-digital ein Import-Tool, das neben den gängigen Austauschformaten auch einige software-spezifische Formate beherrscht (einerseits, weil nicht alle Sammlungsmanagementsysteme die gängigen Austauschformate "von Haus aus" unterstützen, anderseits, weil diese wie oben besprochen oft vollständiger sind). Dieses Import-Tool besteht seinerseits aus drei Komponenten: 1) grundlegenden, für die Museumarbeit relevanten Datentypen (etwa Objekt, Schlagwort, Leihverkehr), 2) Funktionen zum Auslesen von Daten aus den erwähnten Formaten und die Überführung der Eingabedaten in die eben genannten Datentypen, und 3) einem Modul zum tatsächlichen Überführen der Daten in die Datenbank.
+
+Die 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ützt, unterstützen (bei museumsspezifischen Importformaten lohnt es sich allerdings nicht, diese Anpassungen zu unternehmen). Ohne relevanten eigenen Code für 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ät überprüft werden können, ohne weitere Anpassungen in museum-digital importiert werden können.
+
+Die eingelesenen Daten liegen in der Folge in einer strukturierten Form vor und können verhältnismäßig einfach weiter verarbeitet werden, indem sie - leicht umformuliert - an die Funktionen zur Überprüfung der Datenqualität weitergegeben werden. Diese Funktionen wurden im Zuge der Arbeit an museum-digital:qa aus museum-digital:musdb in eine eigene Open-Source-Bibliothek ausgelagert.',
 );

en/quality_web.php

@@ -58,4 +58,15 @@ If your software however supports a uniform export format across institutions, w
   'outlook_text' => 'museum-digital:qa offers a platform to parse and process museum data from a multitude of sources - specifically, to check them for their quality. The strictly modularization of components - the parsing of the data on one hand, the checks themselves on the other, and finally the communication between these two - makes it simple to integrate further tools and checks.
 
 Using the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa.',
+  'tech_background_text' => 'museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. 
+
+Different collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).
+
+In order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.
+
+For the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats "out of the box", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.
+
+The import tool\'s modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.
+
+The input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library.',
 );

hu/quality_web.php

@@ -58,4 +58,15 @@ If your software however supports a uniform export format across institutions, w
   'outlook_text' => 'museum-digital:qa offers a platform to parse and process museum data from a multitude of sources - specifically, to check them for their quality. The strictly modularization of components - the parsing of the data on one hand, the checks themselves on the other, and finally the communication between these two - makes it simple to integrate further tools and checks.
 
 Using the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa.',
+  'tech_background_text' => 'museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. 
+
+Different collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).
+
+In order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.
+
+For the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats "out of the box", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.
+
+The import tool\'s modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.
+
+The input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library.',
 );

ru/quality_web.php

@@ -58,4 +58,15 @@ If your software however supports a uniform export format across institutions, w
   'outlook_text' => 'museum-digital:qa offers a platform to parse and process museum data from a multitude of sources - specifically, to check them for their quality. The strictly modularization of components - the parsing of the data on one hand, the checks themselves on the other, and finally the communication between these two - makes it simple to integrate further tools and checks.
 
 Using the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa.',
+  'tech_background_text' => 'museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. 
+
+Different collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).
+
+In order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.
+
+For the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats "out of the box", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.
+
+The import tool\'s modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.
+
+The input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library.',
 );

uk/quality_web.php

@@ -58,4 +58,15 @@ If your software however supports a uniform export format across institutions, w
   'outlook_text' => 'museum-digital:qa offers a platform to parse and process museum data from a multitude of sources - specifically, to check them for their quality. The strictly modularization of components - the parsing of the data on one hand, the checks themselves on the other, and finally the communication between these two - makes it simple to integrate further tools and checks.
 
 Using the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa.',
+  'tech_background_text' => 'museum-digital:qa accepts data from common and consistent input formats, converts them into an internal, uniform format, and finally evaluates them with regard to their completeness and plausibility. Input formats may either be the software-specific export formats of various collection management systems, if these are formed in the same way across all museums using the same application, or the common open standards for the exchange of museum object data. 
+
+Different collection management systems have different approaches to dealing with the task of customization. While museum-digital:musdb purposefully does not allow museums to freely define fields in order to ensure a consistent database design across institutional boundaries, and thus to be able to offer a variety of evaluation functions tailored to the shared set of data fields on the one hand, and to enable export and search functions across multiple museums on the other hand, other collection management systems allow customization up to the level of defining a fully custom database structure. This customizability may either work on the user interface level or directly at level of the underlying database. If the database structure is also customizable, this simultaneously means that exports from the same software can come in a variety of formats similarly custom to the given museum. Where only the user interface is customizable, there are often software-specific export formats that are consistent across museum boundaries, well maintained, and possibly more complete than other export options (and thus particularly well suited for data migration, for example).
+
+In order to simplify the exchange of data across institutional and software boundaries, various open standards have been developed. The single one most relevant for museums is certainly LIDO; in related areas, EAD (mainly archives) and MODS (mainly libraries) are used. In most cases, these standards are intended for the exchange of publishable data. They thus rarely cover all locally available data fields. Open standards, on the other hand, are implemented in many collection management solutions. With the EODEM published in 2023, early steps towards fascilitating the exchange of primarily internal data have begun to be taken.
+
+For the purpose of importing data (be it for data migration or simply for publication), museum-digital offers an import tool that - in addition to the common exchange formats - also supports some software-specific formats (on the one hand, because not all collection management systems support the common exchange formats "out of the box", on the other hand, because these are often more complete, as discussed above). This import tool, in turn, consists of three components: 1) basic data types relevant to museum work (such as object, keyword, loan), 2) functions for reading data from the aforementioned formats and transferring the input data into the data types just mentioned, and 3) a module for actually transferring the data into the database.
+
+The import tool\'s modules for defining data types and parsing data from different input formats are reused in museum-digital:qa. Thus, museum-digital:qa can support all import formats that are also supported by the importer of museum-digital with a minimum of additional effor (for museum-specific import formats, however, it is not worthwhile to undertake such adaptations). Without relevant own code for reading the incoming data, museum-digital:qa thus also remains very low-maintenance. Conversely, reusing the parsing functionalities of the importer also means that all data that can be checked for quality using museum-digital:qa can be imported into museum-digital without any further adjustments as well.
+
+The input data are subsequently available in a structured form and can easily be processed further. Here, it is passed on in a slightly adapted form to the functions for checking data quality. As museum-digital:qa was written, these functions were moved from museum-digital:musdb to a separate library into a standalone, open-source library.',
 );