-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy path617accb79fb53.xml
417 lines (138 loc) · 27.9 KB
/
617accb79fb53.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
<interview><metadata><model><id>dkNET-DRP</id><version>7</version><localization>en-US</localization><time>1635439249123</time></model></metadata><result status="Accept"><compound slot="DataRepoCompliance"><atomic slot="Citable" ordinal="0" outOf="3">notCitable</atomic><atomic slot="Trustworthy" ordinal="1" outOf="3">minorConcerns</atomic><atomic slot="Open" ordinal="1" outOf="3">partiallyOpen</atomic><compound slot="Properties"><compound slot="FAIRProps"><compound slot="AccessibleProps"><atomic slot="MetadataPersistence" ordinal="0" outOf="3">no</atomic><aggregate slot="AccessibleFlags"><value>machineAccessible</value></aggregate></compound><compound slot="ReusableProps"><atomic slot="MetadataProvenance" ordinal="0" outOf="3">unclear</atomic><aggregate slot="ReusableFlags"><value>communityStandard</value></aggregate><atomic slot="ReuseLicense" ordinal="0" outOf="3">none</atomic><atomic slot="DkNetMetadataLevel" ordinal="0" outOf="3">none</atomic><atomic slot="DocumentationLevel" ordinal="0" outOf="4">lacking</atomic></compound><compound slot="InteroperableProps"><atomic slot="MetadataFAIRness" ordinal="2" outOf="3">enforced</atomic><atomic slot="StudyLinkage" ordinal="1" outOf="4">freeText</atomic><aggregate slot="InteroperableFlags"><value>fairMetadataOK</value><value>qualifiedMetadataReferencesOK</value><value>formalMetadataVocabularyOK</value></aggregate><atomic slot="MetadataReferenceQuality" ordinal="1" outOf="3">informal</atomic></compound><compound slot="FindableProps"><atomic slot="PersistentIdentifier" ordinal="1" outOf="3">internalPID</atomic><atomic slot="IdInMetadata" ordinal="1" outOf="3">partial</atomic><atomic slot="MetadataGrade" ordinal="0" outOf="3">minimal</atomic><aggregate slot="FindableFlags"><value>internalSearchOK</value></aggregate></compound></compound><compound slot="OpenProps"><aggregate slot="OpenFlags"><value>openFormat</value><value>platformSupportsDataWork</value></aggregate><atomic slot="CCLicenseCompliance" ordinal="1" outOf="5">none</atomic><atomic slot="Restrictions" ordinal="0" outOf="3">none</atomic></compound><compound slot="CitableProps"><atomic slot="MachineReadableLandingPage" ordinal="0" outOf="3">none</atomic><atomic slot="CitationMetadataLevel" ordinal="0" outOf="3">none</atomic><atomic slot="OrcidAssociation" ordinal="0" outOf="3">none</atomic></compound><compound slot="TrustworthinessProps"><atomic slot="SourceOpen" ordinal="0" outOf="3">no</atomic><atomic slot="GovernanceTransparency" ordinal="0" outOf="3">opaque</atomic></compound></compound><compound slot="FAIR"><atomic slot="Interoperable" ordinal="1" outOf="3">partiallyInteroperable</atomic><atomic slot="Findable" ordinal="1" outOf="3">partiallyFindable</atomic><atomic slot="Reusable" ordinal="1" outOf="3">partiallyReusable</atomic><atomic slot="Accessible" ordinal="1" outOf="3">partiallyAccessible</atomic></compound></compound></result><transcript><question id="[sc-drc.dg]acc"><text><![CDATA[### Does the repository provide access to the data with minimal or no restrictions?
How easy is it for users to gain access to the data? Are any impediments in place reasonable given the nature of the data, e.g., authorization for sensitive data. Repositories that make metadata available during the embargo period should not be penalized on this question.
#### Options
* **No restriction:** Accessible without a log in
* **Minimal restriction:** requiring an account and/or the user to sign data policy agreement would be considered a minimal restriction.
* **Significant restriction, Authorization required:** Requiring that someone obtain authorization ahead of downloading data, as would be the case for sensitive data, for example, even if it is understandable.
* **Significant but not justified:** The repository imposes significant restrictions for accessing datasets. Said restrictions are too strict for possible harm mis-use of the data might cause.]]></text><answer>no restrictions</answer></question><question id="[sc-drc.dg]reuse"><text><
Consider the type of data and whether the access mechanism places undue restraints on the ability to re-use the data. Also, consider the license that specifies 3rd party rights: does it allow the data to be re-used and -shared as part of a new product?
Ideally, the repository should have a clear statement about acceptable file format characteristics. In the absence of such a policy, a check can be made to ascertain which formats are available. If there are both open and closed examples they are coded as “Yes with proprietary formats”. If individual data sets are offered under multiple licenses, this can complicate the re-use process further.
#### Options
* **Yes:** Permissive license or data use terms including the right to re-distribute products arising from the data; open and well supported format
* **Somewhat:** Yes with proprietary formats, or with multiple licenses that require users to navigate the terms separately for each data set. A proprietary format that is still well used and has multiple tools that can read it, such as `xls`, is better than a custom format that is not well supported
* **No:** A proprietary format that is difficult to read without the required software. Inability to distribute data products so that others may build on them. Terms of use are unclear. ]]></text><answer>yes</answer></question><question id="[sc-drc.dg]lic-clr"><text><![CDATA[### Does the repository provide a clear license for reuse of the data?
Ideally, a metadata field `License=` or an easy to find statement on the web page stating the license under which data are released. The license should also ideally be one in common use where the usage rights are clearly stated and uncomplicated.
#### Options
* **Dataset Level:** Clear license and assigned at the level of individual data sets as part of the metadata
* **Repository Level:** Clear license provided at the level of the repository, e.g., all data are released under a CC-BY license
* **No license**]]></text><note><![CDATA[They say: Public Domain - on repository level;no specific licence]]></note><answer>no license</answer></question><question id="[sc-drc.dg]plat"><text><![CDATA[### Does the repository platform make it easy to work with (e.g. download/re-use) the data?
Most repositories provide data for download, but with very large data sets, download can be a significant impediment for reuse. In such a case, a cloud platform may make it easier for researchers to actually reuse the data.]]></text><answer>yes</answer></question><question id="[sc-drc.dg]ru-doc"><text><![CDATA[### Does the repository require or support documentation that aids in proper (re)-use of the data?
Vignettes or help that are designed not just for use of the repository, but that helps users understand the types of questions that can be answered by using the data and tools. May be at the repository level for homogeneous data or at the data set level for heterogeneous data. Repositories are expected to have basic help materials and tutorials. We are asking for a level above that to fully achieve FAIR. not just how to perform certain functions but why you can use the resource to answer certain types of questions.
#### Options
* **best:** Basic tutorials/help + accompanied by use cases or user stories at the repository level and data set level if appropriate
* **good:** Basic tutorials + encouragement and ability to add use cases even if not enforced
* **adequate:** Tutorials but no use cases
* **worst:** Inadequate tutorials + no use cases and no mention of them.]]></text><answer>worst</answer></question><question id="[sc-drc.dg]sch-ui"><text><![CDATA[### Does the repository provide a search facility for the data and metadata?
Human focused: On-line repositories should provide a means to search available data either through keyword or structured search. ]]></text><answer>yes</answer></question><question id="[sc-drc.dg]pid-g"><text>< by the Dutch Techcenter for Life Sciences.
Answer is "Yes" if this is the default option, i.e., an externally linked and registered PID, e.g., a DOI, Handle, ARK. Sometimes Accession numbers are offered as standard. These can be easily upgraded to PIDs through the Compact Identifiers functionality (e.g. by registering them at [identifiers.org](https://registry.identifiers.org)) but unless this is specified on the website, the response is "No".]]></text><answer>no</answer></question><question id="[sc-drc.dg]pid-l"><text><![CDATA[### Does the repository assign, or the contributor provide, a locally unique identifier to the data set or the data contribution?
Examples include an accession number, a UUID, or some other convention.
*Note:* The use of a title or free text as the unique string is not considered compliant.]]></text><answer>yes</answer></question><question id="[sc-drc.dg]land-pg"><text>< and the [Data citation principles](https://www.force11.org/group/joint-declaration-data-citation-principles-final) require that metadata persist, even if the data they describe are no longer available. FAIR also requires that the access rights to the data be both machine-readable and human understandable. Having the persistent identifier resolve to this page rather than to the data themselves ensures that a stable reference is provided even if the data are removed. The descriptive metadata should also include the necessary information for citing the data set (see Fenner M, Crosas M, Grethe J, Kennedy D, Hermjakob H, Rocca-Serra P, Berjon R, Karcher S, Martone M, Clark T (2016) A Data Citation Roadmap for Scholarly Data Repositories. bioRXiv Dec. 28, 2016. [https://doi.org/10.1101/097196](https://doi.org/10.1101/097196))
---
We are interpreting this as a stable landing page that contains metadata about the data set that uses the identifier for the data set in the URL. [Cool URI’s don’t change](https://www.w3.org/Provider/Style/URI.html).]]></text><answer>no</answer></question><question id="[sc-drc.dg]md-pid"><text><![CDATA[### Does the metadata clearly and explicitly include identifiers of the data it describes?
Should have a metadata field = data set identifier or equivalent that points to the PID or other identifier if no PID Sometimes it is useful to check the API services if documented about what they provide
* *all* All study IDs are included in the metadata
* *some* Some study IDs are included, e.g., accession number but not DOI
* *none* No IDs]]></text><answer>some</answer></question><question id="[sc-drc.dg]orcid"><text>< ID with a dataset?
Data sets are scholarly works and should be credited as such. The use of ORCID streamlines this process.
#### Options:
* **Required:** Required and exports relationship to ORCID
* **Supported:** Recommended but not required
* **None:** No use of ORCID]]></text><answer>none</answer></question><question id="[sc-drc.dg]md-level"><text><. These data provide an overall context for understanding what the data set is about, but don’t necessarily delve into particulars.
#### Options
* **Rich:** the majority of DCIP fields + biomedical extensions according to dkNET or Bio Schema
* **Limited:** Has some structured metadata but room for improvement
* **Minimal:** Minimal descriptive information]]></text><answer>minimal</answer></question><question id="[sc-drc.dg]md-prv"><text><![CDATA[### Are the (meta)data associated with detailed provenance?
Is the appropriate provenance provided, e.g., if they use the Gene Ontology term do we know it’s from gene ontology? In biomedicine, making sure that the relationship between subjects and specimens and data is explicit is extremely important. RRIDs should be used to make sure that all data sets that use the same strain or sample can be found and combined.
Some aspects to look at:
* Does the repository provide originating information for the data set? Lab, PI, Institution.
* Do they provide a contact person? Does the contact person provide an ORCID?
* Do they use contributor roles so that we know who performed various actions?
* Do they provide an originating publication if applicable?
* Do they provide clear dates for submission and modification?
* Do the have a clear versioning policy?
* If they use external identifiers, are they accessible by their PIDs?
* Do they make provenance of any externally imported or referenced data explicit in the (meta)data?
#### Options
* **best:** Clear provenance where required + machine readable tag; clear versioning policy and old versions can be accessed
* **good:** Some good things, e.g., clear provenance provided in free text
* **worst:** No clear provenance]]></text><answer>worst</answer></question><question id="[sc-drc.dg]md-daci"><text>< and [Pilot Project groups](https://www.force11.org/group/dcip) at FORCE11 created a set of recommendations for how to cite data. The repository should contain the relevant metadata: authors (data creators), year, title of data, repository, unique identifier and version number. For examples and more information, see [A Data Citation Primer](http://force11.github.io/data-citation-primer/authors/).-->
#### Options
* **Full support:** The repository contains a metadata field with the full citation(s).
* **Partial Support:** The repository has the required metadata elements but does not provide an easy way to cite the data. Required metadata should include all contributors just like with an article.
* **No Support:** Insufficient metadata for a full citation, e.g., no title or authors.]]></text><answer>no support</answer></question><question id="[sc-drc.dg]md-ref"><text><![CDATA[### Do the metadata include qualified references to other (meta)data?
How well specified are the relationships included in the metadata, e.g., applied in the context of publications, does the resource use the DataCite or some other schema/standard that specifies the relationship of an identifier to the data set, e.g., a PubMed ID for a publication that first reported the data set. Should be machine friendly, e.g., ID’s for publications rather than free text.
#### Options
* **best:** The relationship between the data set or element and an identifier that references an external entity is clearly specified, e.g., the people listed and the related publication are clearly specified.
* Data publication: DOI or PMID
* Author: ORCID + metadata
* Contact person: ORCID + appropriate metadata
* **good:** Identifiers provided but no explicit relationships given
* Publication: Tagged but doesn’t specify the relationship of the publication to the data set clearly
* Creators: Tagged but doesn’t specify key roles clearly
* **worst:** Authors and publication are provided in free text]]></text><answer>good</answer></question><question id="[sc-drc.dg]md-lnk"><text><![CDATA[### Does the repository support bidirectional linkages between related objects such that a user accessing one object would know that there is a relationship to another object?
E.g., does the repository provide a linkage between the publication that first described the data and the data set; does the repository maintain bidirectional linkages between versions, if a dataset has multiple parts, each deposited in a different specialist repository, are the linkages clearly specified across all repositories.
#### Options
* **best:** Repository not only records article provenance, but links that provenance to the PID such that a consumer of this metadata, e.g., DataCite, Crossref, Zenodo (OpenAIRE) or Scholix, can make use of this information
* **good:** originating article is clearly indicated with an appropriate metadata tag (check landing page metadata)
* **unclear:** publication is there but not indicated by a metadata tag, so the relationship between the data set and the publication is not clear (check landing page)
* **worst:** No record of a publication (and no clear statement that there is no publication) (check landing page)]]></text><answer>unclear</answer></question><question id="[sc-drc.dg]fmt-com"><text><![CDATA[### Does the repository enforce or allow the use of community standards for data format or metadata?
A statement by the repository on the standards they follow and their enforcement policy, including curation and/or software validation. The standards should be recognized as a community standard, e.g., in FAIRsharing or through associated publications. If no such statement can be found on the site, then “No”]]></text><note><![CDATA[EMBL format used for sequences data]]></note><answer>yes</answer></question><question id="[sc-drc.dg]md-dkn"><text>< or [Schema.org](http://schema.org) metadata, require certain fields to maximize utility as specified in dkNET’s rich metadata specification. In addition, since dkNET is fostering an information network among the centers and data bases funded by NIDDK, we are expecting that they will include relevant connections to other dkNET listed resources.
#### Options
* **Best:** plurality. Subject level metadata (ages, weights and sex of each subject rather than pooled data).
* **Good:** some basic biomedically relevant metadata
* **Worst:** only generic metadata is supplied
]]></text><answer>worst</answer></question><question id="[sc-drc.dg]md-psst"><text><![CDATA[### Does the repository have a policy that ensures the metadata (landing page) will persist even if the data are no longer available?
Is there evidence that metadata persists even when the data are no longer available. Ideally, repositories clearly state their accessioning and de-accessioning policies as per the data citation principles.
#### Options
* **by policy:** a clear persistence policy
* **by evidence:** evidence that dataset metadata is persisted when its dataset becomes unavailable (e.g., landing page makes it clear that a data set is no longer available)
* **no:** No policy stated and no evidence.]]></text><answer>no</answer></question><question id="[sc-drc.dg]md-FAIR"><text><![CDATA[### Do the metadata use vocabularies that follow FAIR principles?
Use of a community ontology, e.g., OBO, or a controlled vocabulary that follows FAIR principles in order to facilitate combining data from one repository with another.
#### Options
* **enforced:** Required mapping to appropriate FAIR community ontologies widely used in biomedicine and vocabularies where possible and clear documentation
* **allowed:** Allowed use of identifiers in the metadata scheme although not necessarily enforced; use of some identifiers but lack of mapping in some areas where it would be possible
* **minimal:** Minimal or no mapping to appropriate ontologies]]></text><note><![CDATA[Gene Ontology]]></note><answer>enforced</answer></question><question id="[sc-drc.dg]land-api"><text><.]]></text><answer>no</answer></question><question id="[sc-drc.dg]md-cs"><text><![CDATA[### Does the repository use a recognized community standard for representing basic metadata?
There are good schemas now available for general purpose data set metadata, e.g., DataCite schema, Dublin Core, schema.org. When a recognized schema is used, it promotes interoperability among data repositories and helps with data set search. Does the repository have supporting software and tools to enforce and take advantage of this standard, e.g., a validator.
#### Options
* **Yes:** When a recognized schema is mentioned.
* **No:** Otherwise.]]></text><answer>no</answer></question><question id="[sc-drc.dg]acc-api"><text><![CDATA[### Can the (meta)data be accessed via a standards compliant API?
The repository provides documentation on how to programmatically access their content and that this method uses a well recognized and used method for access, e.g., RESTful services.]]></text><note><![CDATA[no information provided]]></note><answer>no</answer></question><question id="[sc-drc.dg]md-vcb"><text><:
> Humans should be able to exchange and interpret each other’s data (so preferably do not use dead languages). But this also applies to computers, meaning that data that should be readable for machines without the need for specialised or ad hoc algorithms, translators, or mappings.
The RDF extensible knowledge representation model is a way to describe and structure datasets. The Dublin Core Schema is an example. Also includes: OWL, JSON LD, OPM (Open Provenance Model) and OntoDM (Ontology for Data Mining), EBI RDF Platform ontologies
#### Options
* **Yes:** if a formal, accessible language is explicitly listed. Some common formats (including Schema.org/microformats)
* **No:** if no evidence of such a language can be found.]]></text><answer>yes</answer></question><question id="[sc-drc.dg]sch-api"><text><![CDATA[### Does the repository provide an API-based search of the data and metadata?
Application focused: A remote system can send a query according to a structured API, and the repository will return a list of datasets or research artifacts that match the query criteria.]]></text><note><![CDATA[probably yes; but no information can be found on the website]]></note><answer>no</answer></question><question id="[sc-drc.dg]gov-tsp"><text><.
Evidence of how decisions are made that affect the repository’s scope or direction, e.g., Is there an Advisory Board? how are advisory members chosen, what are their terms, how are decisions made on behalf of the repository? Is it one person? Is there a voting system? Do we know who runs the repository?
#### Options:
* **Best:** Clear and up to date information
* **Good:** Some information but perhaps difficult to find, not exactly clear or up to date
* **Worst:** No information at all]]></text><answer>worst</answer></question><question id="[sc-drc.dg]oss"><text><![CDATA[### Is the code that runs the data infrastructure covered under an open source license?
From the principles of open infrastructures. If the repository violates the community principles, could the repository be recreated by the community? Some of them are and say so. Some things to look for:
1. Is Code maintained in an open repository?
1. Is the license for the code made clear?
1. Is it an open license?
#### Options:
* **Best:** Code maintained in an open code repository where it can be forked. The license allows for reuse by 3rd parties.
* **Good:** Code covered under an open license but not maintained in an open repository
* **No:** No evidence of the above]]></text><answer>no</answer></question><question id="[sc-drc.dg]tr-seal"><text>< or the [Core Trust Seal](https://www.coretrustseal.org/) or equivalent?
These two review processes have merged but either is acceptable and indicates that the repository has undergone an external review for trustworthiness.
#### Links
* [Data Seal of Approval](https://www.datasealofapproval.org/en/information/requirements/)
* [Core Trust Seal](https://www.coretrustseal.org/)]]></text><answer>no</answer></question></transcript></interview>