CoreTrustSeal_Review_Feedback_Overview_Public
 Share
The version of the browser you are using is no longer supported. Please upgrade to a supported browser.Dismiss

View only
 
ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Overview of community feedback received for the 2019 periodic review of the CoreTrustSeal Requirements
2
Feedback IDChannel Received ConcerningFeedbackAccepted (Already addressed?) / Rejected (Already addressed?) / Deferred (Explored by CoreTrustSeal/ Others?)Board Response / Proposed Action
3
C1Applicant FeedbackAMTIt would be nice to have “boxes” where URLs to resources/webpages can be entered. Preferably, multiple entries should be allowed. It would be nice if the filled-in forms could be printed as PDF for archiving. There have been several “bugs” during saves/submits.Deferred (Explored by CoreTrustSeal)These suggestions concerning the AMT have been noted and will be considered in relation to further development of the Tool. We strive to work with our developers to resolve as quickly as possible any bugs and issues that we are notified of.
4
J1Open Review PeriodAMTPlease define a Schema for machine-readability of the certification documents. This would greatly benefit adoption and recognition of the certification by other entities.Deferred (Explored by CoreTrustSeal)The first steps towards sharing information from successfully completed applications in a structured manner have been completed with the implementation of an API.
5
E2Applicant FeedbackApplication processThe procedure and timeframes for the processing of an application is unclear.Accepted (Already addressed)The procedure has been published in the Rules of Procedure, Section 4. Review and Certification Procedure for Repositories (https://doi.org/10.5281/zenodo.1142960)
6
G2Open Review PeriodApplication process...tricky to strike a balance between not enough detail and too much detail (I was originally asked for more information, but was then told my application was too long)Accepted (Already addressed)A paragraph is included in CoreTrustSeal Extended Guidance (v1.1; https://www.coretrustseal.org/why-certification/requirements/) to advise on the length of responses. Specifically, please see 'Application Structure and Length'.
7
I1Open Review PeriodApplication process...some hints in the form would be nice: ...expected level of accessibility, ...embargo period ok?, ...do the rules distinguish between safety and security?RejectedThe CoreTrustSeal Requirements do not set minimum levels. One reasoning behind this decision is that what is considered 'minimum' can differ greatly depending on the domain. In case an applicant is uncertain whether a certain repository characteristic might constitute a barrier to certification, they are highly encouraged to contact the CoreTrustSeal Secretariat (info@corestrustseal.org) for support.
8
P3Open Review PeriodApplication processThe reviewer's support could be given during construction, so further mistakes/misunderstandings could be correct step by step.Accepted (Already addressed)The CoreTrustSeal Secretariat is happy to respond to any queries concerning applications and can be contacted at info@coretrustseal.org. In addition, it is possible to 'Request Feedback' through the Application Management Tool once an application has been requested.
9
T1Open Review PeriodApplication processTurnover times: It is fully understandable that review processes can take longer, especially when several centres have to be reviewed in parallel. An early notification of this circumstance could prevent frustration on the applicant side.Accepted (Already addressed)The CoreTrustSeal Secretariat is aware of this issue and is doing its best to ensure early notifications are given.
10
L1Open Review PeriodApplication process...possible to expand the reviewers’ team to review multi-languages?...Then you will know whether the material is valid or not, and applicants don’t have to spend too much time to do the translation.Rejected (Partially addressed)The CoreTrustSeal Assembly of Reviewers currently has members from 14 different countries, 10 of which do not use English as a first language. The number of countries and languages is also increasing as more repositories become CoreTrustSeal certified and are invited to put forward a representative for the Assembly.
Wherever possible, people with the requisite language skills are assigned to an application, or are asked to assist in looking at evidence. Nevertheless, the Extended Guidance is clear that, 'responses must be in English...if evidence is in another language, an English summary must be provided in the self-assessment'. Therefore, extensive costs for translations is not necessary; if a document is not available in English, then a brief statement is sufficient in the text describing the approach, along with a link to the document. Ultimately, the public version of the application should be transparent and fully understood in isolation by the international community.
11
T2Open Review PeriodApplication processSometimes a classification of feedback could also help since it can be difficult to distinguish informal questions, a remark, a suggestion or critical feedback that needs instant adaptation.Accepted (Already addressed)The Best Practice Guidance for the Assembly of Reviewers has been updated accordingly.
12
T3Open Review PeriodApplication processMore direct communication with the reviewers: A channel for communication with reviewers besides the actual submission could be helpful and speed things up a bit. We already discussed this...and agreed that sending an e-mail to info@coretrustseal.org is a possibility for such quick interaction between review rounds. Maybe this could be promoted towards all applicants.Accepted (Already addressed)The CoreTrustSeal Secretariat email address and the AMT are well publicized, and we ensure that applicants are aware of this possibility of getting in contact with us.
13
CA3Open Review PeriodApplication processThere are concerns about the qualification of reviewers from other repository types to review biomedical repository applications. It might be useful to describe the review process in the guideline or have a link to the review process so that people can understand that the CoreTrustSeal requirements are domain agnostic.AcceptedClarification will be added to the CoreTrustSeal website on the scope of the certification. Specifically, the CoreTrustSeal Requirements examine the 'operational quality' of the repository rather than the quality of its data holdings.
14
P2Open Review PeriodApplication processAn opening basic support could be useful. The webinars assume that people know what the certification is.Accepted (Partially addressed)We are in the process of setting up a page offering introductory resources and educational material on the CoreTrustSeal and are planning to further invest into creating such resources for the benefit of the community. In the meantime, the first webinar available on https://www.coretrustseal.org/why-certification/requirements/ can serve as a short introduction to the CoreTrustSeal.
15
BA2Open Review PeriodApplication processBased on the review comments on applications...there appears to be notable variation in how the criteria are being assessed by the various reviewers, and a wide difference in the reviewers’ expectations. It would be useful to clarify expectations, both for the reviewers and the organizations applying for certification.Rejected (Partially addressed)The CoreTrustSeal Board does its best to ensure consistent reviewing. It has conducted overviews of applications from repository networks, the result of which have shown that the level of consistency across reviews is very high. Nevertheless, since we employ a peer review process, some variation has to be expected. To further ensure consistency as the Assembly of Reviewers grows, we plan to host reviewer workshops in the future, and as often as deemed necessary.
16
M1Open Review PeriodApplication processWe would find it useful CoreTrustSeal providing documention clarifying the pathway from CoreTrustSeal to ISO16363.Deferred (Explored by others)Whilst the CoreTrustSeal Board recognizes the importance of elucidating the certification pathway from Core, through Extended, to Formal, such an elaboration needs to be undertaken by the community (e.g., through the creation of a Working Group within the Research Data Alliance).
17
O2Open Review PeriodApplication processStandardise assessment report: Different templates for assessment reports exist. Some institutions have used the online form and others provided the self-assessment in a documented form. These different handing-in procedures can lead to different forms of answers, where some institutions do not stick to the given list choices, instead writing prose ansers which are hard to map and also hard to judge by the reviewers. This should be standaradized with clear routines checking for mandatory information, e.g. at least one checkbox ticked for Level of Curation performed.Accepted (Partially addressed)The different templates are a result of the fact that not all repositories have transitioned from the DataSeal of Approval and WDS Regular Member certification to the CoreTrustSeal. As more and more repositories transition to the CoreTrustSeal Requirements, the templates will become increasingly homogeneous. In addition, see J1.
We will explore if automatic checks for completeness can be added to the AMT as a future enhancement.
18
W1Open Review PeriodApplication processTo enable certification of our platform, we would like to see a certification option on a technical platform level and loosen the designated domain part. This most-likely requires a separate definition of requirements, possible as a separate (lightweight?) certification. We would be happy to be involved in provide input to these requirements.Deferred (Explored by CoreTrustSeal)This question is part of an ongoing discussion with the representatives of GLAMs and Technical Service Providers, and is to be continued after the review of Requirements has been completed.
19
EA36Open Review PeriodApplication processWhen giving feedback to applicants, the reviewers could adopt the MoSCoW method (https://en.wikipedia.org/wiki/MoSCoW_method) to make explicit what the applicant must/should/could change.AcceptedThis will be considered in the Best Practices for Reviewers document developed by the CoreTrustSeal Board.
20
EA2Open Review PeriodBackground & General GuidanceFurther elaboration on Levels of compliance.
E.g. “Levels 2, 3 and 4 should be understood as:
2. design - measures have been designed
3. existence - measures have been implemented
4. operation - measures have been functioning as designed (for a certain period of time, for example: one year)”
RejectedThere are many ways to think about maturity, and it is not obviously how the suggest method is an improvement on the one currently employed. Especially, with technological changes often occurring rapidly, that a system has been operated for a certain period is not necessarily an indicator of its quality.
The above does not mean the CoreTrustSeal Board is not open to other methods of measuring maturity, and we are constantly looking at what models exist that enable ongoing monitoring of maturity (also in relation to work on FAIR).
21
CA2Open Review Period(Extended) GuidanceAddition of guidance specific for biomedical repositories could be helpful, including making easily accessible examples of how biomedical repositories with CoreTrustSeal certification addressed each of the requirements. The same suggestion applies to other scientific domains.Deferred (Explored by others)The CoreTrustSeal Board is happy to consider and discuss input and suggestions from the Biomedical community on this matter.
22
S1Open Review Period(Extended) GuidanceA few sentences of guidance as to how repositories should speak to partially applicable requirements could be a useful small additionDeferred (Explored by CoreTrustSeal)This question is part of an ongoing discussion with the representatives of GLAMs and Technical Service Providers, and is to be continued after the review of Requirements has been completed.
23
E1Applicant Feedback(Extended) GuidanceThere is a lack of guidance on what minimum requirements are needed for certification.RejectedThe CoreTrustSeal Requirements do not set minimum levels. One reasoning behind this decision is that what is considered 'minimum' can differ greatly depending on the domain. In case an applicant is uncertain whether a certain repository characteristic might constitute a barrier to certification, they are highly encouraged to contact the CoreTrustSeal Secretariat (info@corestrustseal.org) for support.
24
G4Open Review Period(Extended) Guidance...I would have found the review process much faster and easier if I could clearly see the response to each guidance question.RejectedAs we expect responses to be prose text, it is not feasible to provide feedback in the manner suggested.
25
D1Applicant Feedback(Extended) GuidanceI'm a bit puzzled by the extended guidance document, because to me it looks like there are questions with similar aspects which makes the application a bit redundant.AcceptedThe CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
26
U1Open Review Period(Extended) GuidanceIt might be worth adding some clarification to the guidance to narrow the definitions.AcceptedClarification will be added to the CoreTrustSeal website on the scope of the certification ('Who should apply').
27
G3Open Review Period(Extended) Guidance...I also found it slightly frustrating that guidance was provided against each of the questions (e.g. "when answering, please consider the following..."), but if I actually addressed the guidance in a structured manner I was told that was not appropriate...
Accepted (Already addressed)A clarifying statement was added to the Extended Guidance ('Application Structure and Length') to explain that 'Applications should not respond to each item of guidance in a question-and-answer format. Applications should include prose responses to each Requirement...'
28
O3Open Review Period(Extended) GuidanceIntroduce OAIS in Supporting Information - Our analysis has shown that many applicants seem neither familiar with the OAIS in general, nor with its concepts like Designated Community in particular. This often leads to answers that are not compliant to the standard, not easy to compare, and difficult to assess by reviewers. We therefore recommend an implementation of a short introduction to OAIS in the Supporting Information.RejectedWith good introductions to the OAIS Reference Model already existing, it does not seem necessary to add another one. However, a reference to the 2014 DPC Technology Watch Report: The Open Archival Information System (OAIS) Reference Model: Introductory Guide (2nd Edition) by Brian Lavoie (https://doi.org/10.7207/twr14-02) will be added in the appropriate place.
29
EB1Open Review PeriodGlossaryAdd the definitions for: Appraisal, Curation, Stewardship, Preservation, Preservation Policy, Preservation Plan. For this the OAIS terminology should be used.
AcceptedWe will ensure that definitions deemed necessary are added to the Glossary.
30
U3Open Review PeriodGlossaryIt may seem obvious that CoreTrustSeal is a purely digital certification, but it isn’t clear from the guidance what ‘repository’ means in the context of the applicationAcceptedA definition will be added to the Glossary.
31
CA1Open Review PeriodGlossaryOne general concern expressed by participants was a lack of a clear definition of “data repository”. The terms database, databank, dataset, data repository, data archive, digital archive, and knowledge base are related terms that also lack clarity.AcceptedWe will ensure that definitions deemed necessary are added to the Glossary.
32
P1Open Review PeriodGlossary...include a definition of "trustworthy data repository" and which is the reference model. An illustrative model to follow could be usefulDeferred (Explored by CoreTrustSeal)This exceeds the purpose and scope of the Glossary. Instead, the Board has decided to use a blog post or a similar suitable format to address this question in more depth, and to then reference it in the CoreTrustSeal documentation.
33
O6Open Review PeriodGlossaryDefine Repository’s Boundaries - It is not clearly defined if Repository within CoreTrustSeal pertains to the technological concept or to an Archive in the OAIS sense. This definition should be clearly stated by the CoreTrustSeal, especially as further R0 questions and concepts such as Designated Community build on the OAIS understanding of Archive."AcceptedThe Glossary will be updated with a definition of the term 'Repository'.
34
EA11Open Review PeriodR0Monitor as CoreTrustSeal that the URL of the repository is on the website, also after the certificationDeferred (Explored by CoreTrustSeal)We cannot monitor changes to applicant websites after certification. However, we will look into utilizing the information from a service such as re3data for automating such checks.
35
O1Open Review PeriodR0Heighten R0 assessment relevance - Despite the importance of context information, R0 seems to be treated in a rather irrelevant manner by both reviewers and applicants alike, possibly due to the fact that there is no associated compliance level. While we acknowledge that compliance level are not necessarily applicable to R0, lacking information or incomplete answers should in our view be of consequence and not be disregarded during the review process.AcceptedThe language used in the Guidance will be updated to better convey the importance of R0.
36
EA7Open Review PeriodR0, Repository TypeAdd another category: Preservation Service Providers - In order to give organizations (commercial/ non commercial) that offer archive and preservation services to other organizations/digital collection holders, the possibility to apply for a CoreTrustSeal.Deferred (Explored by CoreTrustSeal)This question is part of an ongoing discussion with the representatives of GLAMs and Technical Service Providers, and is to be continued after the review of Requirements has been completed.
37
EA6Open Review PeriodR0, Repository TypeAdd another category: Audiovisual Archives. Distinction between Archives and Audiovisual Archives is common practice and makes sense.RejectedThis specification of Archive type should be addressed by applicants when they describe the scope/profile of their collection profile. See also EA8.
38
EA5Open Review PeriodR0, Repository TypeSplit up categories Library/Museum/Archives. Concerns entirely different types of organizations with different missions, business processes and user communities.AcceptedThe noted category will be split into three separate bullet points.
39
O5Open Review PeriodR0, Repository TypeReplace mixture of depth, width and function - with 3-level approach: Instead of mixing different levels within a Repository Type list choice, institutions should describe themselves against the three levels separately: Depth/Content - ranking from domain-specific to multidisciplinary; Width/Audience - ranking from project specific via institutional to national; Function - determining whether archiving is included or not.Deferred (Explored by others)The current list was created by the RDA/WDS Publishing Data Cost Recovery for Data Centres IG, and thus far has not been flagged by CoreTrustSeal applicants as being inappropriate. Even more, there have been extremely few 'other' repository types proposed by applicants.
Notwithstanding the above, this topic is something we encourage the community to start a discussion on—and which we are happy to participate in—such that we receive input for the next revision of the CoreTrustSeal Requirements.
40
DA1Applicant FeedbackR0, Repository TypeNot sure what is meant by "Publication repository" - for literature?
Accepted (Partially addressed)Publication repository is already defined in the Glossary. However, this definition will be re-examined and revised as deemed necessary.
41
EA4Open Review PeriodR0, Designated CommunityDesignated Community should be plural: Designated Communities. A repository can have more than one type of Designated Community at the same time (e.g the General Public AND Researchers AND Media Professionals. This situation is taken into account in different preservation policies per Designated Community, that are executed and monitored in different ways.RejectedThe OAIS Reference Model defines Designated Community as 'An identified group of potential Consumers who should be able to understand a particular set of information. The Designated Community may be composed of multiple user communities.' We will therefore continue to use it in singular, but will ensure that the (Extended) Guidance is updated to better reflect the situation of repositories with multiple user communities.
42
O7Open Review PeriodR0, Designated CommunityChange sub-headline "Brief description of Repository's Designated Community" - given the fact that the expression "Repository's Designated Community" is not compliant to OAIS, the term Repository should either be deleted or replaced by the term Archive. This would avoid one inconsistency to OAIS which we observed in our analysis.AcceptedTo avoid potential confusion, 'Repository' will be dropped from the sub-headline, and a definition of Repository added to the Glossary. The Requirements and Guidance will be checked for consistent use of 'Repository' versus 'Archive'.
43
O8Open Review PeriodR0, Designated CommunityStimulate formalized Descriptions of Designated Community - a formalized way to describe Designated Community would be helpful. It would lead to a better understanding of the concept itself, stimulate self-reflection and result in comparable answers. The interdependency of the concepts "scope", "methodologies", and "knowledge base" need to be exemplified, e.g. by referring to the Digital Preservation Coalition which states: "the broader the scope of the Designated Community, the less specialized the knowledge associated with that community". A questionnaire, e.g. on the domain-specific and professional scope of a Designated Community, would be a helpful orientation. AcceptedExplanations from the Extended Guidance will be moved into the Guidance, with revisions where necessary to stimulate more formalized descriptions of the Designated Community. We will consider providing an example description in the Extended Guidance.
44
DA11Applicant FeedbackR0, Level of CurationNot clear why the curation level is not part of R11/R12/R14
RejectedAs explained in the Guidance, knowing the level of curation performed 'will help reviewers in assessing other certification requirements'. As it is relevant for the entire application, it has been included in R0.
45
O9Open Review PeriodR0, Level of CurationDescribe Conditions for Levels Applied - few institutions follow one Level of Curation for all data. Adding a tiered model, where each applicable level is described more granular, e.g. as, “applies to (a) all objects (b) sub-collections based on depositor agreement (c) sub-collections based on external requirement / funding (d) sub-collections based on technical suitability” should lead to a meaningful assessment approach.RejectedWhile this would be a very interesting topic for research, the CoreTrustSeal Board does not consider it necessary for the purpose of reviewing applications.
A note will be added to the Extended Guidance to encourage applicants to add further details—for example, about the proportion of data in the collection curated to a certain level—in the case they selected more than one Level of Curation.
46
O10Open Review PeriodR0, Level of CurationInclude Digital Preservation-centric Model - to understand the preservation functions the repository fulfills, a preservation focused model should be included in R0. This can be either the Levels of Preservation model, or, at the simplest level, by asking the institution which of the preservation levels bit-stream / logical / semantic are implemented.[Partially] AcceptedThe Guidance for R10 contains the question 'Is the level of responsibility for the preservation of each item understood?'. Some more detail and/or scenarios will be added to the Extended Guidance to illustrate where this may be relevant; for example, if depending on the size of an object, fewer redundant copies are made.
47
EA9Open Review PeriodR0, Outsource partnersExplain in the description of this requirement that insourcing is seen as a specific (‘reversed’) form of outsourcing (https://en.wikipedia.org/ wiki/Outsourcing#Insourci ng), and that relevant insource partners should be mentioned here.

“The CoreTrustSeal Board understands that complex partnerships, vendor relationships, and outsourcing are increasingly common. We also understand that the boundaries between insourcing and outsourcing are sometimes difficult to define. We will seek to address and clarify these issues further in future CoreTrustSeal guidance, but simply ask in the meantime that dependant organizations/services/sections are named and their roles briefly defined.”
AcceptedThe name of this item will be changed to "Insourcing/Outsourcing Partners" and additional explanation included in the Guidance.
48
EA10Open Review PeriodR0, Other relevant informationMention a maximum length for this information (no longer than…)Accepted (Already addressed)A paragraph is included in CoreTrustSeal Extended Guidance to advise on the length of responses.
49
K1Open Review PeriodR0, Question suggestion...add a specific question to be answered...about the upgrades they made to their system since the previous application...It would be in line with the fact that we insist on the fact that trustworthiness building is a continuous process.AcceptedThis will be added as a separate question to R0.
50
T6Open Review PeriodR0, Question suggestionAre you part of a consortium / network that supports each other and wants to ensure sustainability together? Which consortium? Is there an agreement for cooperation on sustainability?Accepted (Partially addressed)See response to EA9 (Insourcing/Outsourcing). The question of sustainability should be addressed under R3 'Continuity of Access'.
51
CA4Open Review PeriodR0, Guidance...desire for more clarity related to the Context requirement. In particular, the user community could be very diverse for some biomedical repositories. Some examples will be helpful.AcceptedFurther guidance will be provided to describe the Designated Community; especially, an acknowledgement of the fact that it can be composed of multiple user communities.
52
O4Open Review PeriodR0, Guidance & GlossaryInclude concise Definitions and Examples - To avoid unclarity concerning terminology used in R0, we recommend that clear definitions and concrete examples are added to the Supporting Information. This applies to the list choices for Repository Type and Level of Curation Performed as well as to terms like “scope”, “methodologies”, “contextual documentation”, and “knowledge base” used in the Designated Community section. Including definitions and examples directly within the requirements might significantly improve the applicants’ understanding of R0 and omit the need to query different pieces of information.AcceptedThe Glossary and Extended Guidance will be updated with an eye to increasing clarity.
53
EA8Open Review PeriodR0, Extended GuidanceAdd to extended guidelines: “Applicants could start the Brief Description of Repository with an opening statement defining what is in scope (which datasets are preserved for which designated community) for the application, and what is not.”AcceptedA sentence will be added to the (Extended) Guidance that asks applicants to briefly describe the scope of their collection.
54
U2Open Review PeriodR1"does it [mission statement] refer to the a mission statement regarding management of digital assets only"AcceptedClarification will be added to the CoreTrustSeal website on the scope of the certification ('Who should apply').
55
EA12Open Review PeriodR1Strict demand to precise formulation of the mission statement: Drop or make less strict. The mission statement is often a simplified, abstract and popular representation of the (sometimes much broader) assignment of an organization, intended for communication and sometimes for marketing. The exact assignment may be implicitly included in the formulation or can be deduced directly from the assignment. It should be sufficient if the explicit assignment for data management and / or preservation is evidenced by supplied evidence documents such as Statutes, collection and preservation policies, applicable legislation and the like.RejectedAs a clear mission is an important factor in providing trusted curation and preservation services, this Requirement cannot be dropped. However, it is a misunderstanding that the mission can only be stated in a mission statement on the webpage. The wording in the Requirement will be rephrased to make this clearer.
56
EA13Open Review PeriodR2Licenses are only part of the story when it comes to restrictions on access to collections. If CoreTrustSeal has the ambition to be more widely used outside the research data world this requirement should be made more general in the sense of all restrictions on access to collections (archival law, GDPR, agreements with archival donors e.g.).AcceptedRights model' will be used in the Requirement and Guidance where applicable. The Requirement is then expected to cover all issues concerning rights after the next review of the CoreTrustSeal.
Intellectual Property Rights mentioned as an example for conditions of use.
57
CA5Open Review PeriodR3The Preservation plan should also include when data will not be preserved as some biomedical data may lose utility. Policy and regulatory issues may also impact the preservation of data. This may overlap with appraisal (R8). But it is not limited to select collections. It may remove data after they were collected when they are not worthwhile anymoreAcceptedA question concerning the removal of assets and potential impact on PIDs from the collection will be added to R8. The importance of reappraisal also will be emphasized.
58
S2Open Review PeriodR4...we do not have disciplinary norms follow as our repository does not have a Designated Community as currently defined by the CoreTrustSeal. Thus it was difficult to determine whether this requirement applied to our repository or not.Deferred (Explored by CoreTrustSeal)This question is part of an ongoing discussion with the representatives of GLAMs and Technical Service Providers, and is to be continued after the review of Requirements has been completed.
59
BA4Open Review PeriodR4Does CoreTrustSeal have a disclaimer for accessing data that we should display to users so that we can meet the part of this statement that says to ensure data is “used in compliance with” disciplinary and ethical norms? Otherwise, would drafting and displaying our own disclaimer on our data access pages be sufficient?RejectedThe CoreTrustSeal does not provide any templates for concrete repository functions and responsibilities. The applicant should use their own Terms of Use/Disclaimer.
60
Q1Open Review PeriodR4[Include] Adequate de-identification practices before uploadAcceptedLanguage will be added to the (Extended) Guidance to emphasize the repository's responsibility to ensure as best as possible that no personal data are uploaded to the repository unless explicitly permitted.
61
BA6Open Review PeriodR5Wouldn’t this be a key requirement to even begin an application? We don’t believe an organization would apply for certification without having funding and staffing to support its activities as a repository. If not met (especially with regard to funding) an acceptance would serve little purpose. Perhaps WDS needs to set some minimum requirements in this area; maturity expressed as the number of years of existence of an archive is one metric.RejectedFor this Requirement, an applicant is asked to demonstrate that they have sufficient resources to fulfil their mission (R1) as required by their Designated Community (R0). Becuase what can be considered a "minimum requirement" is highly dependent on context (e.g., mission, community), we do not consider it feasible to set minimum requirements in this regard.
62
BA5Open Review PeriodR5A reviewer commented that the response and the supporting document did not describe all staff. Listing and detailing the role of every staff member seems excessive.AcceptedThis issue will have to be addressed individually. The Board will look into it.
63
EA14Open Review PeriodR5, GuidanceDesignated Community in section Guidance: Change into plural formRejectedSee EA4.
64
EA16Open Review PeriodR5, GuidanceSecond bullet: Change “Ideally this should be for a three- to five-year period” into “This should be for a three-year period at least.”RejectedIn the Board's opinion, a three-year minimum as suggested is too strict; in particular, it may not align with the applicant's (re)certification schedule. Therefore, we would like to leave some flexibility in the statement (i.e., 'ideally').
65
EA17Open Review PeriodR5, Extended GuidanceFunding: Add a suggested balance between project budget and structural budgetsRejectedAn assessment of this Requirement is complex, as it is strongly dependent on context (e.g., R0 'Designated Community' and R1 'Mission') and has to take into account measures in place for Continuity of Access (R3). In this light, it does not seem feasible to make a suggestion of a best practice here.
66
EA15Open Review PeriodR5, Extended GuidanceThe question “How often does periodic renewal occur?”
Explanation of the sort of renewal that is referred to.
AcceptedIt will be clarified that this refers to the renewal of funding.
67
BA7Open Review PeriodR6This requirement has some overlap with R11.AcceptedSee BA11.
68
EA18Open Review PeriodR6, GuidanceDesignated Community: PluralRejectedSee EA4.
69
EA19Open Review PeriodR6, Extended GuidanceChange "a wider network of expertise" into "a wider network of repository and/or preservation expertiseRejectedThe suggested change narrows the scope down too much as this 'network of expertise' should also address the area of 'Community Watch' and, therefore, includes new developments in the scientific domains catered for. However, we will emphasize in the Guidance that this also refers to curation and preservation expertise, not just to scientific expertise.
70
T11Open Review PeriodR7, Question suggestionFor ongoing development: at what intervals is data versioned? Is there a "Latest Version" that is constantly changing or is every released version stable to ensure reproducibility?Deferred (Explored by CoreTrustSeal)These questions should be addressed under 'Version control strategy'. More elaboration on this topic is expected to be included in the Requirements after the next review of the CoreTrustSeal.
71
T12Open Review PeriodR7, Question suggestionWhich checksums or other mechanisms are provided to users to verify the integrity of the data during download?Accepted (Partially addressed)The Guidance currently mentions that integrity/authenticity should be addressed throughout the entire lifecycle. Language will be added to make it more explicit that this also refers to checksums/fixity checks.
72
EA20Open Review PeriodR7, GuidanceLast line in Guidance: In this sentence, guaranteeing authenticity and integrity is suddenly ("However ...") regarded as "a mindset, and the responsibility of everyone within the repository". Confusing sentence in this context. However true perhaps, such a vague remark does not fit in with requirements where it is primarily a matter of providing clear, concrete evidence that demonstrates how this guarantee of authenticity and integrity is achieved in practice.AcceptedThe sentence will be removed.
73
EA21Open Review PeriodR7, Extended GuidanceLast sentence, [remove] colon after “trails”AcceptedThere is not a colon after 'trails'; however, a comma will be added after 'Audit trails' to make the sentence clearer.
74
EA23Open Review PeriodR8Response and Guidance: Replace term Appraisal with a more appropriate term that describes the assessment process of (meta) data at intake. Suggestion: Assessment. The term Appraisal is here primarily associated with the practical and procedural aspects of data and metadata intake, based on relevance and comprehensibility for users. This is not how this term is commonly used in archives and heritage institutions.RejectedIn the opinion of the CoreTrustSeal Board, 'Appraisal' is the correct term to express the requirements that applicants have to meet to comply with R8. To ensure that this is well-understood, a definition will be added to the Glossary and the language in the Guidance will be revised to better reflect the intended meaning.
75
BA8Open Review PeriodR8, Question suggestionAnother criterion to add here is whether the repository has a mechanism, policy and process whereby the user community can propose inclusion of new datasets.RejectedApplicants are welcome to mention this under R6 'Expert Guidance' or R8 'Appraisal', but it is not something that is generally applicable across all repositories, and will therefore not be added as a criterion.
76
EA22Open Review PeriodR8, GuidanceGuidance: Designated Communities: Plural

Here, among other things, a detailed explanation must be given of how an organization serves its Designated Community (singular) with regard to their technical, access and reuse requirements (metadata, file formats, collection structure, etc.) and how these requirements are already taken into account at ingest. In case organizations have multiple Designted Communities (this applies to all heritage institutions) but will in the long run apply to all types of institutions) the respective requirements can therefore lead to entirely different (preservation) approaches.
[Partially] AcceptedRegarding 'Designated Communities', see EA4.
The CoreTrustSeal Board agrees that it is perfectly possible to have different preservation levels for different collections and/or user communities. What is important is that the selection- and decision-making processes are well-documented and that there is evidence of clear rules followed by the repository.
A clarification will be added to the Introduction and possibly to the Extended Guidance in order to convey that it is possible to cater to more than one user community (as part(s) of the Designated Community), as well as that different strategies and measures may be defined for these collections. These strategies should then be detailed in the application where applicable (e.g., under R10 'Preservation Plan').
77
BA9Open Review PeriodR9This requirement has some overlap with R10.AcceptedThe CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
78
EA24Open Review PeriodR9, Guidance/Glossary“preservation remit”: Add term in glossary and relate to “Levels of curation performed”RejectedIt does not seem necessary to add this to the Glossary. Instead, we will reword the sentence slightly to increase clarity ('Repositories that perform digital preservation.).
79
EA25Open Review PeriodR9, Guidance/GlossaryExplain “preservation policy”: Add term in glossary and relate to Preservation plan (R10)AcceptedWe will remove the bullet point here. The terms preservation policy/plan will be replaced by 'preservation approach' (except for the section title of R10).
80
BA10Open Review PeriodR10This requirement has some overlap with R16AcceptedThe CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
81
Q2Open Review PeriodR10[Include about] Formal contracts regarding upload and storage, clarifying responsibilitiesAccepted (Already addressed)The mentioned issues should be addressed either under R0 'Outsource Partners', and/or R10 'Preservation Plan', where deposit licenses are covered.
82
T10Open Review PeriodR10, Question suggestionAre your archived resources serviced? E.g. format, ongoing development, metadata maintenance,...Rejected (Already addressed)The mentioned questions are already sufficiently covered under R10 'Preservation Plan'.
83
EA27Open Review PeriodR10, GuidanceVarious CoreTrustSeal requirements can covered in a preservation plan by using OAIS-model as a clear guideline for the plan. Thus avoiding repetition and have a clearer alignment between CoreTrustSeal and OAIS.RejectedWe will review the language used in the requirements for clarity and revise where necessary. In particular, a clarification of our use of Preservation Plan will be added to R10 (see EA26). As the OAIS Reference Model does not itself give sufficiently specific guidance on how to define a preservation plan it does not seem to be an entirely suitable tool here.
84
EA26Open Review PeriodR10, GuidanceMake a clearer distinction between between a) Preservation Plan (= long-term policy), b) Preservation Action Plan (= operational plan per individual transformation / migration) and c) other types of documentation that deal with preservation planning. The term "Preservation Plan" is used here for various actions and thus seems to cover all levels of planning (strategic, tactical and operational). In practice, it is (or should be) about different types of plans.AcceptedThe term 'Preservation Plan' will be replaced by 'preservation approach' in all cases except the section title. Nevertheless, text will be added to the Extended Guidance to explain what is meant by 'Preservation plan'.
85
BA11Open Review PeriodR11This requirement has an overlap with R6. There should be one question to document the data center expertise, internal and external feedback and dataset selection process, and policies to improve these areas.RejectedWe do not think it is feasible to merge all of the suggested perspectives into one Requirement. In particular, expert guidance can be sought for every level, not just the dataset level, and therefore R6 has a wider scope than R11 'Data Quality'.
86
EA29Open Review PeriodR11This assessment is almost a repetition / doubling of issues that are already fully addressed in R7, R8 and R12. I don't quite understand why this is a separate requirement. What should be the specific angle here?AcceptedThe CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
87
EA28Open Review PeriodR11, GuidanceDesignated Community: Plural RejectedSee EA4.
88
EA280Open Review PeriodR11, GuidanceLeave out the complete 2nd sentence of the Guidance : “Such quality assessment ...from the data alone”. The Designated Community and their use and evaluation of metadata is described here exclusively from the scientific / research domain. Leave out the example or add examples from other domains.AcceptedWe wiil revise the text to ensure that it is more generic.
89
EA30Open Review PeriodR11, Extended GuidanceClarify second part of the last sentence: "..., which may involve documentation of areas where quality thresholds have not been reached". What exactly does this mean? I see no reference to or instruction for this in the Guidance.AcceptedWe will revise the text to ensure better understandability.
90
EA31Open Review PeriodR12Clarify what this requirement really is about. From which specific point of view should the answer be given? Again, a lot of overlap and doubling with R8, R9, R16 and R4 and the like, in which the organization-wide "defined workflows" are described in various ways. What information is specifically requested in this requirement?AcceptedWe will revise the text for clarity and to reduce potential overlap with other Requirements.
91
H1Open Review PeriodR12When completing the application form, some requirements caused difficulties. From our point of view, the names of the requirements do not always agree well with the requirements for which information should be provided. For example, requirement R12 “Archiving takes place according to defined workflows from ingest to dissemination”. Questions arise about the following topics: “Appraisal and selection of data” and “The types of data managed and any impact on workflow”.AcceptedThe CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized and with an eye to clearer language.
92
EA32Open Review PeriodR13Reference to requirements for "proper data citation" for "appropriate credit and linkages among related research" etc. Include less prominently (e.g use just as an example).
Is this a requirement that can be imposed on repositories other than scientific data archives? NB. Here too (implicitly) one Designated Community and one kind of use of the data are assumed, exclusively connected to the scientific domain.
Change in Extended Guidance “appropriate academic credit and linkages” into “appropriate credit and linkages conform domain standards”
AcceptedThe wording will be revised to ensure it also addresses domains other than scientific research.
93
T4Open Review PeriodR13, Question suggestionWhich persistence identifiers do you use to identify resources that have not been generated by standard print publishing processes (books, magazines, etc.) e.g. PIDs according to ISO 24619, DOI, Handle, URN…RejectedApplicants are expected to provide all relevant information concerning PIDs assigned to their digital assets. If different procedures are in place for different types of digital objects, then applicants should point this out in their response.
Notwithstanding the above, the Guidance will be updated with a question about the PID systems in use.
94
T5Open Review PeriodR13,Question suggestionHow many resources with persistent identifiers are managed by you?RejectedApplicants are expected to mention this if they consider it relevant; for example, because not all managed assets receive a PID.
95
T7Open Review PeriodR13, Question suggestionWhich search systems guarantee that data can be easily found? Is the system your own or are you involved in a network?Rejected (Already addressed)These questions are sufficiently addressed under R13. In the case functions are outsourced or offered collaboratively as part of a network, this should be explained under R0.
96
EA35Open Review PeriodR14Clarify what this requirement really is about. From which specific point of view should the answer be given? This requirement contains many things that have already been answered (several times) in other assessments (on formats, metadata, workflows, preservation plans etc.). For example: the data quality (R11) is assessed according to the possibility of sustainable (re)use of the data; the preferred formats (including R8) are determined on the basis of the possibility of sustainable (re) use; Tech Watch (in R10), is precisely a condition for guaranteed (future) reuse of the data, etc., etc. What I want to argue: all previously described workflows, procedures, facilities, (meta) data rules etc., are in the first place implemetend with the objective of sustainable accessibility and guaranteed (re)usability of the data. A separate requirement for data reuse thus automatically leads to much doubling of the information, in case all leads to much doubling of the infromation, in case all these provisions are already fully described in other requirements.AcceptedThe CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
97
Q3Open Review PeriodR14[Include] Flexibility of access – allowing different levels of managed as well as public accessAccepted (Already addressed)R14 primarily focusses on the understandability and accessibility of formats, and not on access regimes, which should be described under R2 'Licenses'.
98
T9Open Review PeriodR14, Question suggestionHow is interoperability ensured? (consider: Restrictions on data formats, Provision of tools for analysis, post-processing, conversion)Rejected (Already addressed)We believe that this is sufficiently covered unter R14 'Data reuse', which includes a question on formats used by the Designated Community. If 'interoperability' is an important characteristic of the format demanded by the Designated Community, then it should be addressed here.
99
EA34Open Review PeriodR14, GuidanceReplace Metadata by Descriptive Metadata. To clarify the type of metadata that is specifically concerned here. For comparison: the category "technical metadata" is used in other requirements, when relevant.RejectedDescriptive metadata' appears to be too narrow here as the Requirement specifically mentions changes in technology as a barrier to future use. The (re)use of data can require technical, descriptive, and rights metadata.
The use of different subcategories of metadata will be checked for consistency in the Requirements and Guidance.
100
EA33Open Review PeriodR14, Extended GuidanceDesignated Community: PluralRejectedSee EA4.
Loading...