Approval in quality-web
This commit is contained in:
md translation bot
parent
d5789e1014
commit
c16a1ee301
|
|
@ -44,6 +44,7 @@
|
|||
"faq_a_why_is_my_cms_not_supported": "Wie im Bereich \"Technischer Hintergrund\" beschrieben, gibt es nicht bei jeder Software \u00fcber Museumsgrenzen hinweg konsistente Ausgabe- und Exportformate. museum-digital:qa kann allerdings nur solche (und die g\u00e4ngigen Austauschstandards, etwa LIDO) unterst\u00fctzen.\r\n\r\nOft liegt das Fehlen von konsistenten Ausgabe- und Exportformaten an der Anpassbarkeit der zugrundeliegenden Datenbank - ist diese bis auf die einzelnen Felder auf das Museum zugeschnitten, m\u00fcssen die Exporte ebenso auf das Museum zugeschnitten werden.\r\n\r\nGibt es allerdings ein konsistentes Ausgabeformat, das hier noch nicht ber\u00fccksichtigt wird, oder unterst\u00fctzt die Software prim\u00e4r ein standardisiertes Austauschformat, das hier noch nicht ber\u00fccksichtigt wird, w\u00fcrden wir uns freuen, auch dieses in Zukunft zu unterst\u00fctzen. Eine gro\u00dfe Hilfe w\u00e4re dabei eine Mail an quality@museum-digital.de, idealerweise zusammen mit einigen exemplarischen Exportdaten.",
|
||||
"faq_q_birth_death_dates_via_vocabs": "Lebensdaten sind in meinen Objektmetadaten nicht verzeichnet, aber es liegen Normdatenverkn\u00fcpfungen vor. Funktionieren die Checks trotzdem?",
|
||||
"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."
|
||||
"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."
|
||||
}
|
||||
}
|
||||
|
|
@ -44,6 +44,7 @@
|
|||
"faq_a_why_is_my_cms_not_supported": "As described in the section \"technical background\", not every collection management system offers export formats uniform across the different institutions using it. Besides the general open standards for museum-digital:qa can however only reasonably support those export formats that are not specific to a single institution.\r\n\r\nThe lack of a consistent export format often stems from the customizability of the underlying database structure as opposed to a superficial customizability of the interface - where the database structure is fully customized towards the use case of a museum, custom exports need to be written as well - which in turn means additional cost and effort.\r\n\r\nIf your software however supports a uniform export format across institutions, which is not yet usable with museum-digital:qa, we would be most interested in supporting it in the future as well. In such cases, please send a mail - ideally along with some sample exports - to quality@museum-digital.de.",
|
||||
"faq_q_birth_death_dates_via_vocabs": "Birth and death dates of related actors are not covered by our object metadata, but we do link them to norm data repositories. Will the plausibility checks still work?",
|
||||
"faq_a_birth_death_dates_via_vocabs": "Yes. museum-digital:qa will also check references to norm data repositories against museum-digital's controlled vocabularies to gather additional data - such as birth and death dates - if any such references are supplied.",
|
||||
"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.\r\n\r\nUsing the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa."
|
||||
"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.\r\n\r\nUsing 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. \r\n\r\nDifferent 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).\r\n\r\nIn 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.\r\n\r\nFor 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.\r\n\r\nThe 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.\r\n\r\nThe 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."
|
||||
}
|
||||
}
|
||||
|
|
@ -44,6 +44,7 @@
|
|||
"faq_a_why_is_my_cms_not_supported": "As described in the section \"technical background\", not every collection management system offers export formats uniform across the different institutions using it. Besides the general open standards for museum-digital:qa can however only reasonably support those export formats that are not specific to a single institution.\r\n\r\nThe lack of a consistent export format often stems from the customizability of the underlying database structure as opposed to a superficial customizability of the interface - where the database structure is fully customized towards the use case of a museum, custom exports need to be written as well - which in turn means additional cost and effort.\r\n\r\nIf your software however supports a uniform export format across institutions, which is not yet usable with museum-digital:qa, we would be most interested in supporting it in the future as well. In such cases, please send a mail - ideally along with some sample exports - to quality@museum-digital.de.",
|
||||
"faq_q_birth_death_dates_via_vocabs": "Birth and death dates of related actors are not covered by our object metadata, but we do link them to norm data repositories. Will the plausibility checks still work?",
|
||||
"faq_a_birth_death_dates_via_vocabs": "Yes. museum-digital:qa will also check references to norm data repositories against museum-digital's controlled vocabularies to gather additional data - such as birth and death dates - if any such references are supplied.",
|
||||
"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.\r\n\r\nUsing the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa."
|
||||
"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.\r\n\r\nUsing 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. \r\n\r\nDifferent 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).\r\n\r\nIn 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.\r\n\r\nFor 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.\r\n\r\nThe 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.\r\n\r\nThe 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."
|
||||
}
|
||||
}
|
||||
|
|
@ -44,6 +44,7 @@
|
|||
"faq_a_why_is_my_cms_not_supported": "As described in the section \"technical background\", not every collection management system offers export formats uniform across the different institutions using it. Besides the general open standards for museum-digital:qa can however only reasonably support those export formats that are not specific to a single institution.\r\n\r\nThe lack of a consistent export format often stems from the customizability of the underlying database structure as opposed to a superficial customizability of the interface - where the database structure is fully customized towards the use case of a museum, custom exports need to be written as well - which in turn means additional cost and effort.\r\n\r\nIf your software however supports a uniform export format across institutions, which is not yet usable with museum-digital:qa, we would be most interested in supporting it in the future as well. In such cases, please send a mail - ideally along with some sample exports - to quality@museum-digital.de.",
|
||||
"faq_q_birth_death_dates_via_vocabs": "Birth and death dates of related actors are not covered by our object metadata, but we do link them to norm data repositories. Will the plausibility checks still work?",
|
||||
"faq_a_birth_death_dates_via_vocabs": "Yes. museum-digital:qa will also check references to norm data repositories against museum-digital's controlled vocabularies to gather additional data - such as birth and death dates - if any such references are supplied.",
|
||||
"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.\r\n\r\nUsing the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa."
|
||||
"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.\r\n\r\nUsing 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. \r\n\r\nDifferent 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).\r\n\r\nIn 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.\r\n\r\nFor 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.\r\n\r\nThe 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.\r\n\r\nThe 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."
|
||||
}
|
||||
}
|
||||
|
|
@ -44,6 +44,7 @@
|
|||
"faq_a_why_is_my_cms_not_supported": "As described in the section \"technical background\", not every collection management system offers export formats uniform across the different institutions using it. Besides the general open standards for museum-digital:qa can however only reasonably support those export formats that are not specific to a single institution.\r\n\r\nThe lack of a consistent export format often stems from the customizability of the underlying database structure as opposed to a superficial customizability of the interface - where the database structure is fully customized towards the use case of a museum, custom exports need to be written as well - which in turn means additional cost and effort.\r\n\r\nIf your software however supports a uniform export format across institutions, which is not yet usable with museum-digital:qa, we would be most interested in supporting it in the future as well. In such cases, please send a mail - ideally along with some sample exports - to quality@museum-digital.de.",
|
||||
"faq_q_birth_death_dates_via_vocabs": "Birth and death dates of related actors are not covered by our object metadata, but we do link them to norm data repositories. Will the plausibility checks still work?",
|
||||
"faq_a_birth_death_dates_via_vocabs": "Yes. museum-digital:qa will also check references to norm data repositories against museum-digital's controlled vocabularies to gather additional data - such as birth and death dates - if any such references are supplied.",
|
||||
"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.\r\n\r\nUsing the API, specified using the OpenAPI format, researchers and software vendors can easily reuse the tools made accessible through museum-digital:qa."
|
||||
"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.\r\n\r\nUsing 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. \r\n\r\nDifferent 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).\r\n\r\nIn 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.\r\n\r\nFor 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.\r\n\r\nThe 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.\r\n\r\nThe 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."
|
||||
}
|
||||
}
|
||||
Loading…
Reference in New Issue
Block a user