forked from rdmorganiser/rdmo-catalog
-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathFAIR4RSview.xml
246 lines (244 loc) · 21.7 KB
/
FAIR4RSview.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
<?xml version="1.0" encoding="UTF-8"?>
<rdmo created="2023-08-18T09:18:26.451429+02:00" xmlns:dc="http://purl.org/dc/elements/1.1/">
<view dc:uri="https://rdmo.mpdl.mpg.de/views/FAIR4RSview">
<uri_prefix>https://rdmo.mpdl.mpg.de/</uri_prefix>
<key>FAIR4RSview</key>
<dc:comment>View of the FAIR Principles for Research Software (https://zenodo.org/record/6623556)</dc:comment>
<title lang="en">FAIR4RS</title>
<help lang="en">View of the FAIR Principles for Research Software (<a href="https://zenodo.org/record/6623556" target="_blank">https://zenodo.org/record/6623556</a>)</help>
<title lang="de">FAIR4RS</title>
<help lang="de">Ansicht der FAIR Principles for Research Software (<a href="https://zenodo.org/record/6623556" target="_blank">https://zenodo.org/record/6623556</a>)</help>
<catalogs/>
<template>{% load view_tags %}
<h1>FAIR4RS</h1>
<p><strong>Project title:</strong> {% render_value 'project/title' %}</p>
<p><strong>Start date:</strong> {% render_value 'project/schedule/project_start' %}</p>
<p><strong>End date:</strong> {% render_value 'project/schedule/project_end' %}</p>
{% get_values 'project/id' set_index=0 as id %}
<p class="explanation">Here, you can verify whether your responses to the Software Management Plan adress the the FAIR4RS principles. However, it is necessary for this that the SMP project is already filled with answers; there simply has to be enough information already available. Some questions from the SMP relate to several FAIR4RS aspects. Therefore, some answers are presented several times in different places. Likewise, several answers are also listed in the viewer under a FAIR4RS item, as they answer the item together thematically. If you discover that you have not fully addressed FAIR-related questions,
you can revisit the Software Management Plan and provide the necessary details. Please note that the FAIR4RS viewer is only available in English.</p>
<h2>Findability</h2>
<h3>F: Software and its associated metadata are easy for both humans and machines to find</h3>
<ul>
<li class="bold">F1. Software is assigned a globally unique and persistent identifier</li>
<ul>
<li class="category1">
<a class="link" href="https://qa-rdmo.mpdl.mpg.de/projects/{{id.0.value}}/questions/2515/" target="_blank">F1.1. Components of the software representing levels of granularity are assigned distinct identifiers</a>
<span class="info-icon" data-info="The use of identifiers for more than the software project (often synonymous with “software concept” or “software product”) improves findability by enabling components to be assigned distinct identifiers e.g, a software library, and a function in that library. The relationship between these components is embodied in the associated metadata.">&#9432;</span>
</li>
<ul class="answers">
<li>The single software components can be identified implicitely via the version number and the source file name.</li>
</ul>
<li class="category">F1.2. Different versions of the software are assigned distinct identifiers<span class="info-icon" data-info="To make different versions of the same software (or component) findable, each version needs to be assigned a different identifier. The relationship between versions is embodied in the associated metadata. What is considered a “version” is defined by the owner of the software: in many cases this will be something that the owner wants to specifically identify and use and/or “release” or “publish” so that others can use and reference/cite. There are existing software engineering practices (e.g., version control, semantic versioning) around the management and versioning of software that may form part of the implementation of these relationships.">&#9432;</span>
</li>
<ul class="answers">
<li>
Versioning will be handled as follows:
<ul class="nested-answers">
{% get_values 'smp/versioning' set_index=0 as keyword %}
{% for value in keyword %}
<li>{{value.value}}</li>
{% endfor %}
</ul>
</li>
</ul>
</ul>
<li class="bold">F2. Software is described with rich metadata<span class="info-icon" data-info="Software requires descriptive metadata to support indexing, search and discoverability. This metadata must itself be FAIR (F4), should follow community standards, and use controlled vocabularies. The FAIR4RS principles do not define which standards should be used, as this is better captured in guidance for implementing the principles coming out of each community. R1,R1.1, and R1.2 describe categories of metadata that enable reuse.">&#9432;</span>
</li>
<ul class="answers">
<li>{% render_value 'smp/software-metadata' %}</li>
</ul>
<li class="bold">F3. Metadata clearly and explicitly include the identifier of the software they describe<span class="info-icon" data-info="The association between the metadata (wherever it is stored; see F4) and the software should be made explicit by mentioning the software’s globally unique and persistent identifier in its associated metadata. In conjunction with A1, this means the metadata describes how the software can be obtained. Metadata are not required to include references for all of the softwares dependencies in order for software to be findable. I2 and R2 describe how references to dependencies increase the likelihood that software is interoperable and reusable.">&#9432;</span>
</li>
<ul class="answers">
<li>
The following identifiers are used:
<ul class="nested-answers">
<li>{% render_value 'smp/software-pid' %}</li>
</ul>
</li>
</ul>
<li class="bold">F4. Metadata are FAIR, searchable and indexable<span class="info-icon" data-info="Making the metadata about the software FAIR, including making it readable and discoverable byboth humans and machines, improves the findability of software by supporting searching andindexing by others. It allows the metadata to be published in or harvested by a registry orcatalog or repository, or by a search engine. FAIR metadata also enables and encourages citation of research software.">&#9432;</span>
</li>
<ul class="answers">
<li>Searchability of the software metadata is granted by the platform where the software is stored.</li>
</ul>
</ul>
<h2>Accessibility</h2>
<h3>A: Software, and its metadata, is retrievable via standardized protocols</h3>
<ul class="answers">
<li>{% render_value 'smp/software-sharing' %}</li>
</ul>
<ul>
<li class="bold">A1. Software is retrievable by its identifier using a standardized communications protocol <span class="info-icon" data-info="Different types of software have different methods for access. For instance, software that is only available in source code form may be downloaded from a repository before being compiled locally, whereas software hosted as a service on a remote server may be accessed without retrieving it. This principle states that obtaining the software should not require specialized or proprietary tools or communication methods. For much software, there are commonly used technical communications protocols used to access the software, such as HTTPS.">&#9432;</span>
</li>
<ul>
<li class="category">A1.1. The protocol is open, free, and universally implementable<span class="info-icon" data-info="It is the openness of the communications protocol (including the resolver for the identifier) that is important, not the implementation of the infrastructure that supports it. Here “open” means that there are no restrictions to implementing it and “free” means that there are no fees or licensing costs to implement it">&#9432;</span>
</li>
<ul class="answers">
<li>The communication protocol is determined by the platform where the software is stored.</li>
</ul>
<li class="category">A1.2. The protocol allows for an authentication and authorization procedure, where necessary<span class="info-icon" data-info="The FAIR Guiding Principles put specific emphasis on enhancing the ability of machines to use digital objects. In the context of software, there are often conditions of access, for instance, requiring a license server to be contacted, requirement for payment before use, or restrictions based on the privilege level of the user.">&#9432;</span>
</li>
<ul class="answers">
<li>The communication protocol is determined by the platform where the software is stored.</li>
</ul>
</ul>
<li class="bold">A2. Metadata are accessible, even when the software is no longer available<span class="info-icon" data-info="Availability of software may change over time, because there is a cost to maintaining access or because the software has degraded and is no longer safely usable, or because dependencies are no longer available. The metadata describing the software is generally easier and cheaper to store and maintain than the software itself (e.g., in the software repository, or in a software registry or catalog) and there is value in understanding the details of the software even if it is no longer accessible.">&#9432;</span>
</li>
<ul class="answers">
<li>Long-term accessibility of the software metadata is granted by the platform where the software is stored.</li>
</ul>
</ul>
<h2>Interoperability</h2>
<h3>I: Software interoperates with other software by exchanging data and/or metadata, and/or through interaction via application programming interfaces (APIs), described through standards</h3>
<ul>
<li class="bold">I1. Software reads, writes and exchanges data in a way that meets domain-relevant community standards<span class="info-icon" data-info="Software interoperates through the exchange of data. This includes the use of data and metadata types, controlled vocabularies, and formats that are formally defined through standards to facilitate the exchange. Whereas F4 requires that metadata describing the software are FAIR, this principle ensures that the way that software interacts with other software is clearly described. A domain-relevant standard is an agreed standard that addresses the needs of a given community (or communities). Examples of community standards for data are curated by the FAIRSharing Registry athttps://fairsharing.org/standards/.">&#9432;</span>
</li>
<ul class="answers">
<li>
The following coding standards and guidelines are followed:
<ul class="nested-answers">
{% get_values 'smp/coding-standards' set_index=0 as keyword %}
{% for value in keyword %}
<li>{{value.value}}</li>
{% endfor %}
</ul>
</li>
</ul>
<li class="bold">I2. Software includes qualified references to other objects<span class="info-icon" data-info="Some software includes references to external data objects required to execute the software (e.g., parameter files for certain applications). Ideally, the data would be FAIR as well, and references to external data would be fully qualified. Qualified references should be to digital objects (e.g., metadata, other software, data), as well as to non-digital objects that have a virtual presence in digital systems (e.g., samples, reagents, instruments, etc.) with which the software interacts. These qualified references should be described using identifiers and/or controlled vocabularies. “Qualified” means specifying the authoritative source for an identifier or vocabulary item, possibly including a resolvable reference to further information about the source. Ideally this is in a form that includes a resolver within the reference (e.g., in the form of a persistent identifier, or URL). This information can also improve the reusability of software by explicitly including references to articles and data sets that document its use.">&#9432;</span>
</li>
<ul class="answers">
<li>
The software relies on the following external services:
<ul class="nested-answers">
{% get_values 'smp/web-services' set_index=0 as keyword %}
{% for value in keyword %}
<li>{{value.value}}</li>
{% endfor %}
</ul>
</li>
</ul>
</ul>
<h2>Reusability</h2>
<h3>R: Software is both usable (can be executed) and reusable (can be understood, modified, built upon, or incorporated into other software)</h3>
<ul class="answers">
<li><i>Preservation of the software:</i> {% render_value 'smp/preservation' %}</li>
<li><i>Usability of the software:</i> {% render_value 'smp/re-usable' %}</li>
</ul>
<ul>
<li class="bold">R1. Software is described with a plurality of accurate and relevant attributes<span class="info-icon" data-info="It is easier to reuse (and find) software if there are many descriptive labels attached to it. F2requires software to be described by rich metadata. References provided by applying I2 can help document the use and purpose of the software. Software should be described for the categories of R1.1 (license), R1.2 (provenance), and additionally address the categories of metadata that facilitate reuse. Relevant attributes can be determined by repositories, and by communities who create and reuse software. Plurality means that, where possible, multiple terms for the same, similar, or overlapping concepts should be provided to enable the broadest possible reuse Metadata and documentation are distinct, potentially complementary, concepts. Metadata about software can be included in documentation, or in the code itself, or in a separate location. Metadata included in the documentation are generally not machine readable, or indexable. This does, however, support the reusability of software particularly from a human perspective.">&#9432;</span>
</li>
<ul>
<li class="category">R1.1. Software is given a clear and accessible license<span class="info-icon" data-info="To enable reuse, software must have a license that clearly describes how it can be used and reused, ideally with conditions that are readable by humans and machines. Licenses are often referred to by name, but machine readable licenses can be specified by reference to a standard vocabulary such as the SPDX License List4 (SPDX Consortium, 2020). To support a wide range of reuse scenarios, the license should be as unrestrictive as possible and, to avoid license proliferation, choosing a widely used and recognized license is strongly recommended. This license must also be compatible with the requirements of the licenses of the software’s dependencies so that the software can be legally combined">&#9432;</span>
</li>
<ul class="answers">
<li>
Software:
<ul class="nested-answers">
<li>{% render_value 'smp/software-license' %}</li>
</ul>
</li>
</ul>
<ul class="answers">
<li>
Third-party components:
<ul class="nested-answers">
<li>{% render_value 'smp/third-party-licenses' %}</li>
</ul>
</li>
</ul>
<li class="category">R1.2. Software is associated with detailed provenance<span class="info-icon" data-info="Software provenance is a type of metadata that describes why and how the software came to be, as well as who contributed what, when and where. Provenance is sometimes referred to as lineage or pedigree. This extends beyond capturing a log of changes to source code as it is developed. Good provenance metadata clarifies the origins and intent behind the development of the software, and establishes authenticity and trust. As a type of metadata this overlaps with the metadata called for in guiding principles F2 and F4.">&#9432;</span>
</li>
<ul class="answers">
<li>Information on provenance is granted by the platform where the software is stored.</li>
</ul>
</ul>
<li class="bold">R2. Software includes qualified references to other software<span class="info-icon" data-info="Software is rarely standalone and in most cases is built upon other software (e.g., dependencies), it should include appropriate references to other software (e.g., requirements, imports, libraries) which are necessary to compile and run the software. “Qualified” here means specifying the authoritative source for an identifier, possibly including a resolvable reference to further information about the source. To follow this principle, it is desirable but not required that the other software referenced implements the FAIR4RS Principles. In many programming languages, base methods or functions take a reference to a named entity, possibly in combination with a version number or qualifying domain and resolves this to a source. This principle goes beyond this in calling for qualified references to external dependencies, meaning that the reference itself resolves to the source via the qualifying authority. This guiding principle calls for qualified references in software to other software (in aid of reuse).Principle I2 calls for qualified references to anything other than software (in aid of interoperability).">&#9432;</span>
</li>
<ul class="answers">
<li>
This software uses the following external components and libraries:
<ul class="nested-answers">
{% get_values 'smp/external-components' set_index=0 as keyword %}
{% for value in keyword %}
<li>{{value.value}}</li>
{% endfor %}
</ul>
</li>
</ul>
<li class="bold">R3. Software meets domain-relevant community standards<span class="info-icon" data-info="Software, including its documentation and license, should meet domain-relevant community standards and coding practices (e.g., choice of programming language, standards for testing, usage of file formats, accessibility [in the sense of usable by as many people as possible]) that enable reuse. While the FAIR4RS Principles do not specify particular community standards, the intent is to ensure that practitioners are aware of what others are doing and using in the community, e.g., through initiatives like FAIRsharing (Sansone et al., 2019), whilst acknowledging that community standards are (and should be) under constant development">&#9432;</span>
</li>
<ul class="answers">
<li>
The following third-party requirements are followed:
<ul class="nested-answers">
<li>{% render_value 'smp/community-requirements' %}</li>
</ul>
</li>
</ul>
</ul>
<style>
ul{
list-style-type: none;
}
h2, h3{
margin:0;
}
h3{
line-height: 20px;
margin-bottom: 10px;
}
h2{
margin-top: 28px;
}
.link{
color: inherit !important;
text-decoration: none;
color: black;
}
.bold{
font-weight: bold;
margin-top: 10px;
}
.category{
font-style: italic;
margin-top: 10px;
}
.explanation{
font-style: italic;
}
.answers{
list-style-type: disc;
}
.category1{
font-style: italic;
text-decoration: none;
}
.info-icon{
position: absolute;
margin-left:5px;
font-style: normal;
font-weight: normal;
}
.info-icon:hover::after{
content: attr(data-info);
position: absolute;
left: 0;
top: 100%;
padding: 10px;
background-color: #fff;
color: black;
border-radius: 4px;
box-shadow: 0 2px 5px rgba(0, 0, 0, 0.2);
z-index: 1;
width: 500px;
line-height: 1.4;
font-size: 14px;
}
.nested-answers {
list-style-type: circle;
}
</style></template>
</view>
</rdmo>