CoreTrustSeal_Review_Feedback_Overview_Public

	A	B	C	D	E	F
1		Overview of community feedback received for the 2019 periodic review of the CoreTrustSeal Requirements
2	Feedback ID	Channel Received	Concerning	Feedback	Accepted (Already addressed?) / Rejected (Already addressed?) / Deferred (Explored by CoreTrustSeal/ Others?)	Board Response / Proposed Action

3	C1	Applicant Feedback	AMT	It 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	J1	Open Review Period	AMT	Please 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	E2	Applicant Feedback	Application process	The 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	G2	Open Review Period	Application 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	I1	Open Review Period	Application process	...some hints in the form would be nice: ...expected level of accessibility, ...embargo period ok?, ...do the rules distinguish between safety and security?	Rejected	The 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	P3	Open Review Period	Application process	The 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	T1	Open Review Period	Application process	Turnover 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	L1	Open Review Period	Application 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	T2	Open Review Period	Application process	Sometimes 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	T3	Open Review Period	Application process	More 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	CA3	Open Review Period	Application process	There 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.	Accepted	Clarification 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	P2	Open Review Period	Application process	An 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	BA2	Open Review Period	Application process	Based 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	M1	Open Review Period	Application process	We 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	O2	Open Review Period	Application process	Standardise 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	W1	Open Review Period	Application process	To 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	EA36	Open Review Period	Application process	When 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.	Accepted	This will be considered in the Best Practices for Reviewers document developed by the CoreTrustSeal Board.
20	EA2	Open Review Period	Background & General Guidance	Further 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)”	Rejected	There 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	CA2	Open Review Period	(Extended) Guidance	Addition 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	S1	Open Review Period	(Extended) Guidance	A few sentences of guidance as to how repositories should speak to partially applicable requirements could be a useful small addition	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.
23	E1	Applicant Feedback	(Extended) Guidance	There is a lack of guidance on what minimum requirements are needed for certification.	Rejected	The 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	G4	Open 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.	Rejected	As we expect responses to be prose text, it is not feasible to provide feedback in the manner suggested.
25	D1	Applicant Feedback	(Extended) Guidance	I'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.	Accepted	The CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
26	U1	Open Review Period	(Extended) Guidance	It might be worth adding some clarification to the guidance to narrow the definitions.	Accepted	Clarification will be added to the CoreTrustSeal website on the scope of the certification ('Who should apply').
27	G3	Open 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	O3	Open Review Period	(Extended) Guidance	Introduce 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.	Rejected	With 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	EB1	Open Review Period	Glossary	Add the definitions for: Appraisal, Curation, Stewardship, Preservation, Preservation Policy, Preservation Plan. For this the OAIS terminology should be used.	Accepted	We will ensure that definitions deemed necessary are added to the Glossary.
30	U3	Open Review Period	Glossary	It 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 application	Accepted	A definition will be added to the Glossary.
31	CA1	Open Review Period	Glossary	One 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.	Accepted	We will ensure that definitions deemed necessary are added to the Glossary.
32	P1	Open Review Period	Glossary	...include a definition of "trustworthy data repository" and which is the reference model. An illustrative model to follow could be useful	Deferred (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	O6	Open Review Period	Glossary	Define 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."	Accepted	The Glossary will be updated with a definition of the term 'Repository'.
34	EA11	Open Review Period	R0	Monitor as CoreTrustSeal that the URL of the repository is on the website, also after the certification	Deferred (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	O1	Open Review Period	R0	Heighten 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.	Accepted	The language used in the Guidance will be updated to better convey the importance of R0.
36	EA7	Open Review Period	R0, Repository Type	Add 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	EA6	Open Review Period	R0, Repository Type	Add another category: Audiovisual Archives. Distinction between Archives and Audiovisual Archives is common practice and makes sense.	Rejected	This specification of Archive type should be addressed by applicants when they describe the scope/profile of their collection profile. See also EA8.
38	EA5	Open Review Period	R0, Repository Type	Split up categories Library/Museum/Archives. Concerns entirely different types of organizations with different missions, business processes and user communities.	Accepted	The noted category will be split into three separate bullet points.
39	O5	Open Review Period	R0, Repository Type	Replace 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	DA1	Applicant Feedback	R0, Repository Type	Not 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	EA4	Open Review Period	R0, Designated Community	Designated 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.	Rejected	The 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	O7	Open Review Period	R0, Designated Community	Change 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.	Accepted	To 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	O8	Open Review Period	R0, Designated Community	Stimulate 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.	Accepted	Explanations 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	DA11	Applicant Feedback	R0, Level of Curation	Not clear why the curation level is not part of R11/R12/R14	Rejected	As 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	O9	Open Review Period	R0, Level of Curation	Describe 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.	Rejected	While 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	O10	Open Review Period	R0, Level of Curation	Include 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] Accepted	The 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	EA9	Open Review Period	R0, Outsource partners	Explain 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.”	Accepted	The name of this item will be changed to "Insourcing/Outsourcing Partners" and additional explanation included in the Guidance.
48	EA10	Open Review Period	R0, Other relevant information	Mention 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	K1	Open Review Period	R0, 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.	Accepted	This will be added as a separate question to R0.
50	T6	Open Review Period	R0, Question suggestion	Are 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	CA4	Open Review Period	R0, 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.	Accepted	Further 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	O4	Open Review Period	R0, Guidance & Glossary	Include 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.	Accepted	The Glossary and Extended Guidance will be updated with an eye to increasing clarity.
53	EA8	Open Review Period	R0, Extended Guidance	Add 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.”	Accepted	A sentence will be added to the (Extended) Guidance that asks applicants to briefly describe the scope of their collection.
54	U2	Open Review Period	R1	"does it [mission statement] refer to the a mission statement regarding management of digital assets only"	Accepted	Clarification will be added to the CoreTrustSeal website on the scope of the certification ('Who should apply').
55	EA12	Open Review Period	R1	Strict 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.	Rejected	As 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	EA13	Open Review Period	R2	Licenses 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.).	Accepted	Rights 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	CA5	Open Review Period	R3	The 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 anymore	Accepted	A 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	S2	Open Review Period	R4	...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	BA4	Open Review Period	R4	Does 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?	Rejected	The CoreTrustSeal does not provide any templates for concrete repository functions and responsibilities. The applicant should use their own Terms of Use/Disclaimer.
60	Q1	Open Review Period	R4	[Include] Adequate de-identification practices before upload	Accepted	Language 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	BA6	Open Review Period	R5	Wouldn’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.	Rejected	For 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	BA5	Open Review Period	R5	A 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.	Accepted	This issue will have to be addressed individually. The Board will look into it.
63	EA14	Open Review Period	R5, Guidance	Designated Community in section Guidance: Change into plural form	Rejected	See EA4.
64	EA16	Open Review Period	R5, Guidance	Second bullet: Change “Ideally this should be for a three- to five-year period” into “This should be for a three-year period at least.”	Rejected	In 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	EA17	Open Review Period	R5, Extended Guidance	Funding: Add a suggested balance between project budget and structural budgets	Rejected	An 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	EA15	Open Review Period	R5, Extended Guidance	The question “How often does periodic renewal occur?” Explanation of the sort of renewal that is referred to.	Accepted	It will be clarified that this refers to the renewal of funding.
67	BA7	Open Review Period	R6	This requirement has some overlap with R11.	Accepted	See BA11.
68	EA18	Open Review Period	R6, Guidance	Designated Community: Plural	Rejected	See EA4.
69	EA19	Open Review Period	R6, Extended Guidance	Change "a wider network of expertise" into "a wider network of repository and/or preservation expertise	Rejected	The 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	T11	Open Review Period	R7, Question suggestion	For 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	T12	Open Review Period	R7, Question suggestion	Which 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	EA20	Open Review Period	R7, Guidance	Last 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.	Accepted	The sentence will be removed.
73	EA21	Open Review Period	R7, Extended Guidance	Last sentence, [remove] colon after “trails”	Accepted	There is not a colon after 'trails'; however, a comma will be added after 'Audit trails' to make the sentence clearer.
74	EA23	Open Review Period	R8	Response 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.	Rejected	In 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	BA8	Open Review Period	R8, Question suggestion	Another criterion to add here is whether the repository has a mechanism, policy and process whereby the user community can propose inclusion of new datasets.	Rejected	Applicants 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	EA22	Open Review Period	R8, Guidance	Guidance: 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] Accepted	Regarding '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	BA9	Open Review Period	R9	This requirement has some overlap with R10.	Accepted	The CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
78	EA24	Open Review Period	R9, Guidance/Glossary	“preservation remit”: Add term in glossary and relate to “Levels of curation performed”	Rejected	It 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	EA25	Open Review Period	R9, Guidance/Glossary	Explain “preservation policy”: Add term in glossary and relate to Preservation plan (R10)	Accepted	We 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	BA10	Open Review Period	R10	This requirement has some overlap with R16	Accepted	The CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
81	Q2	Open Review Period	R10	[Include about] Formal contracts regarding upload and storage, clarifying responsibilities	Accepted (Already addressed)	The mentioned issues should be addressed either under R0 'Outsource Partners', and/or R10 'Preservation Plan', where deposit licenses are covered.
82	T10	Open Review Period	R10, Question suggestion	Are 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	EA27	Open Review Period	R10, Guidance	Various 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.	Rejected	We 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	EA26	Open Review Period	R10, Guidance	Make 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.	Accepted	The 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	BA11	Open Review Period	R11	This 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.	Rejected	We 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	EA29	Open Review Period	R11	This 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?	Accepted	The CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
87	EA28	Open Review Period	R11, Guidance	Designated Community: Plural	Rejected	See EA4.
88	EA280	Open Review Period	R11, Guidance	Leave 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.	Accepted	We wiil revise the text to ensure that it is more generic.
89	EA30	Open Review Period	R11, Extended Guidance	Clarify 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.	Accepted	We will revise the text to ensure better understandability.
90	EA31	Open Review Period	R12	Clarify 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?	Accepted	We will revise the text for clarity and to reduce potential overlap with other Requirements.
91	H1	Open Review Period	R12	When 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”.	Accepted	The 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	EA32	Open Review Period	R13	Reference 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”	Accepted	The wording will be revised to ensure it also addresses domains other than scientific research.
93	T4	Open Review Period	R13, Question suggestion	Which 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…	Rejected	Applicants 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	T5	Open Review Period	R13,Question suggestion	How many resources with persistent identifiers are managed by you?	Rejected	Applicants are expected to mention this if they consider it relevant; for example, because not all managed assets receive a PID.
95	T7	Open Review Period	R13, Question suggestion	Which 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	EA35	Open Review Period	R14	Clarify 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.	Accepted	The CoreTrustSeal Board will revise the Requirements, Guidance, and Extended Guidance in a manner to ensure that overlap is minimized.
97	Q3	Open Review Period	R14	[Include] Flexibility of access – allowing different levels of managed as well as public access	Accepted (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	T9	Open Review Period	R14, Question suggestion	How 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	EA34	Open Review Period	R14, Guidance	Replace 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.	Rejected	Descriptive 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	EA33	Open Review Period	R14, Extended Guidance	Designated Community: Plural	Rejected	See EA4.