Approval in quality-web
This commit is contained in:
parent
8976b2ef30
commit
d5789e1014
@ -43,6 +43,7 @@
|
||||
"faq_q_why_is_my_cms_not_supported": "Warum werden Exporte aus meinem Sammlungsmanagementsystem nicht unterst\u00fctzt?",
|
||||
"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."
|
||||
"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."
|
||||
}
|
||||
}
|
@ -43,6 +43,7 @@
|
||||
"faq_q_why_is_my_cms_not_supported": "Why are exports from my CMS not supported?",
|
||||
"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."
|
||||
"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."
|
||||
}
|
||||
}
|
@ -43,6 +43,7 @@
|
||||
"faq_q_why_is_my_cms_not_supported": "Why are exports from my CMS not supported?",
|
||||
"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."
|
||||
"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."
|
||||
}
|
||||
}
|
@ -43,6 +43,7 @@
|
||||
"faq_q_why_is_my_cms_not_supported": "Why are exports from my CMS not supported?",
|
||||
"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."
|
||||
"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."
|
||||
}
|
||||
}
|
@ -43,6 +43,7 @@
|
||||
"faq_q_why_is_my_cms_not_supported": "Why are exports from my CMS not supported?",
|
||||
"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."
|
||||
"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."
|
||||
}
|
||||
}
|
Loading…
Reference in New Issue
Block a user