Approval in quality-web
This commit is contained in:
md translation bot
parent
7c7330ab3f
commit
baba990f46
72
quality-web/ro/quality_web.json
Normal file
72
quality-web/ro/quality_web.json
Normal file
|
|
@ -0,0 +1,72 @@
|
||||||
|
{
|
||||||
|
"quality_web": {
|
||||||
|
"puqi": "Publication Quality Index (PuQI)",
|
||||||
|
"plausi": "Plausibility Check",
|
||||||
|
"plausi_legal": "Plausibility Check for License Status of Images \/ Representations",
|
||||||
|
"puqi_explica": "The publication quality index measures the completeness and suitability of an object record's publishable information. For example, feedback is given on the availability of an object title and a tags. Objects' descriptions are checked for their length; and linked images' license status is evaluated. Based on these evaluations, a quantitative score is provided to be able to roughly measure the completeness and quality of an object record for publication.",
|
||||||
|
"plausi_explica": "During this check, the objects' events (production, usage, etc.) are checked for their logical coherence based on the provided times and actors. For example, a bike that has been produced in 1950 cannot have been used in 1870. Similarly, a photograph showing Ice-T (born 1958) cannot have been taken in 1920.",
|
||||||
|
"plausi_explica_2": "If such a logical inconsistency between or different events in the object's history is detected, a warning will be provided.",
|
||||||
|
"plausi_legal_explica": "This check aims to identify and warn about obvious issues concerning the licensing status of an object's representations (mainly images). To do so, the life dates of the recorded creators are identified - either directly taken from the provided inputs or via references to central authority files and repositories like the Library of Congress Subject Headings, Wikidata or the Gemeinsame Normdatei of the German National Library. ",
|
||||||
|
"plausi_legal_explica_2": "The check is based on the assumption that images of museum objects are meant to be documenting - meaning that in many jurisdictions (such as the EU) no copyright protection is extended to the images themselves. It is thus likely, that images of objects older than 100 years after the death of their creator are in the public domain (here, we are using the maximum number of years by which any country extends copyright protection to a work). If a license status indicating otherwise is provided, a warning will be returned. Similarly, a warning will be displayed if images of objects created by creators who are still alive or have died only within the last 50 years (as per the Berne Convention) have been set under a non-restrictive license. These checks are of course only a rough approximation - laws are complicated and diverse, and so is object data. In sum, it is hoped however, that they cover issues appearing regularly, while not producing too many falsely positive warnings.",
|
||||||
|
"citation": "Citation",
|
||||||
|
"puqi_score": "PuQI Score",
|
||||||
|
"results": "Results",
|
||||||
|
"objects_identified": "[placeholder_for_count] objects identified",
|
||||||
|
"check_passed": "Check passed",
|
||||||
|
"warning": "Warning",
|
||||||
|
"status": "Status",
|
||||||
|
"plausibility_warnings": "Plausibility Check: Warnings",
|
||||||
|
"plausibility_warnings_licenses": "Plausibility Check for Image Licenses: Warnings",
|
||||||
|
"puqi_notices": "PuQI Messages",
|
||||||
|
"types_of_evaluations": "Types of Evaluations",
|
||||||
|
"see": "See",
|
||||||
|
"step": "Step",
|
||||||
|
"select_import_format": "Select an import format",
|
||||||
|
"upload_a_file": "Upload a file",
|
||||||
|
"select_file_for_upload": "Select a file for upload",
|
||||||
|
"alt_paste_text": "Or Paste the Object Record in Plain Text",
|
||||||
|
"text": "Text",
|
||||||
|
"submit": "Submit",
|
||||||
|
"news": "News",
|
||||||
|
"click_read_more": "Click to read more",
|
||||||
|
"try_it_out": "Try it out",
|
||||||
|
"intro_text": "Since the 1980s, more and more museums have started managing their object data digitally. Where inventory cards oftentimes only covered the most rudimentary information systematically, digital record-keeping allows for a much more detailled description of the objects without any of the space limitations inherent to the medium of the inventory card. Detailed information that had often only been written down unsystematically in catalogues or research articles can now be stored and searched digitally alongside the rudimentary object data in a database. Simultaneously, an increasing number of museums has started to publish their collections in publicly accessible databases, often in collaboration with other museums, which have entirely different collections.\r\n\r\nA coverage of the collections that is at the same time systematic and detailled has thus only really been possible due to digitization. The increasingly close link between inventorization and publication of the object data on the other hand makes data quality more relevant than ever.\r\n\r\nmuseum-digital has helped museums and related institutions in collaboratively managing and publishing their collections online since 2009. In this context, a number of tools were written to measure and improve the quality of collection data.\r\n\r\nmuseum-digital:qa allows the (re-)use of these tools by users and software beyond museum-digital. They may be used directly via a web interface or via an API, which also allows for the simple embedding of the quality assessment tools into other collection management systems, which often do not feature comparable tools as of yet.",
|
||||||
|
"summary": "Summary",
|
||||||
|
"tech_background_hl": "Technical background",
|
||||||
|
"faq": "Frequently Asked Questions",
|
||||||
|
"tech_background_summary": "museum-digital:qa resuses those components of museum-digital's improt tool, which cover the tasks of parsing different input formats and converting them into a uniform format for simple processing. It thus supports reading both well-established open standards for data exchange in the cultural heritage sector as well as the specific export formats of a number of collection management systems to establish a platform for the processing of museum data from a variety of sources. The data thus read are then checked for their completeness and coherence.",
|
||||||
|
"currently_offline_msg": "You are currently offline. Evaluation happens on the server. Please try to reconnect your network first.",
|
||||||
|
"filesize_too_big": "The file is too big! The maximum allowed size of uploaded files is [placeholder] byte.",
|
||||||
|
"quality_assessment_tools": "Quality assessment tools",
|
||||||
|
"api": "API",
|
||||||
|
"outlook": "Outlook",
|
||||||
|
"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.",
|
||||||
|
"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.",
|
||||||
|
"go_back": "Go back",
|
||||||
|
"paste_as_text": "Paste in plain text",
|
||||||
|
"licensed_under": "This work is licensed under",
|
||||||
|
"reload_application": "Reload application",
|
||||||
|
"more": "More",
|
||||||
|
"select_check": "Please select the type of check(s) to run",
|
||||||
|
"minimaldatensatz_p1": "The Working Group Minimaldatensatz (\"Minimum Viable Object Record\") sets out to define a set of basic object information required or highly recommended for a worthwhile publication of objects. Its recommendations are primarily aimed at publishing in the German Digital Library (DDB), but can serve as a sane guideline in other contexts as well.",
|
||||||
|
"minimaldatensatz_p2": "As the context of this check is specifically German, the return values of the check are thus far available only in German.",
|
||||||
|
"see_also": "See also",
|
||||||
|
"log": "Log",
|
||||||
|
"launch": "Launch",
|
||||||
|
"thanks": "Thanks",
|
||||||
|
"count_new_to_vocabs": "Counters for new vocabulary entries at museum-digital",
|
||||||
|
"count_new_to_vocabs_short": "Count: new vocabulary entries",
|
||||||
|
"count_new_to_vocabs_explica_1": "museum-digital:quality strings together the parsing of input data of different formats from museum-digital's import tool with different checks. That also means that all data that can be checked using museum-digital:quality could be imported to museum-digital as well.\r\n\r\nActually importing the data however regularly also entails adding missing entries to museum-digital's controlled vocabularies for actors, places, times, and tags, which need to be cleaned and enriched in the aftermath of the import. Using this check, the number of such newly added entries can be counted.",
|
||||||
|
"samples": "Samples",
|
||||||
|
"select_activity": "What would you like to do with the data?",
|
||||||
|
"evaluate": "Evaluate",
|
||||||
|
"convert_to_xml": "Convert to XML",
|
||||||
|
"select_conversion_target_format": "Select the target format for conversion",
|
||||||
|
"other_features": "Other features",
|
||||||
|
"convert_to_xml_explica": "museum-digital:qa can leverage the XSL transformations written for musdb to convert any imported data to those XML formats musdb can export to. Next to the well-established exchange standard LIDO this includes EODEM, a recent extension to LIDO meant to simplify data exchange for registrars specifically in the case of loans between museums."
|
||||||
|
}
|
||||||
|
}
|
||||||
Loading…
Reference in New Issue
Block a user