Harmonize with RO-crate profile(s) #140
Conversation
|
@Brilator can you have a look at the Licensing part of this PR and tell me if it is in line what was discussed in https://github.com/orgs/nfdi4plants/discussions/11? |
ARC specification.md
Outdated
| In other words, the creator has the exclusive right to decide how the ARC is used, distributed, or modified. | ||
| To allow others to use, distribute, or modify the ARC, the creator(s) can choose a more permissive license. Examples of permissive licenses include the [Creative Commons Attribution 4.0 International License](https://creativecommons.org/licenses/by/4.0/) and the [MIT License](https://opensource.org/licenses/MIT). | ||
|
|
||
| Obviously, more permissive licenses are more in line with the F**A**I**R** principles, as they allow others to **A**ccess and **R**euse ARCs. |
There was a problem hiding this comment.
This sentence is a bit ambiguous.
Does it mean less permissive, i.e. CC-BY = FAIR, CC-BY-NC-SA = less permissive = less FAIR?
There was a problem hiding this comment.
I think you can make a point that any copyright makes something less accessible in the broadest sense, as there are more than 0 restrictions on the accessibility.
However, from the FAIR definition site itself:
The ‘A’ in FAIR does not necessarily mean ‘open’ or ‘free’. Rather, it implies that one should provide the exact conditions under which the data are accessible
So adding any license makes the ARC more FAIR, as that clarifies (some) conditions of access. I would however argue that the general public sentiment leans towards ‘open’ or ‘free’ being more FAIR than a dataset that applies FAIR principles but is not openly accessible. You can for example also have licenses that allow full access but prevent the R in FAIR via prohibiting any re-use.
So long story short i am ambiguous on purpose here, but open for suggestions
There was a problem hiding this comment.
Under further investigation, licenses are more on the side of the R in FAIR. Access obviously cannot be handled by them directly, as once you can read the license you obviously have access to the ARC. will clarify
ARC specification.md
Outdated
|
|
||
| Obviously, more permissive licenses are more in line with the F**A**I**R** principles, as they allow others to **A**ccess and **R**euse ARCs. | ||
| However, **the choice of license is up to the creator(s) of the ARC**. | ||
| It may not be possible to openly share ARCs due to legal or ethical constraints, for example when sensitive clinical data is involved. |
| @@ -63,9 +63,11 @@ The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RE | |||
|
|
|||
| ## Extensions | |||
|
|
|||
| The ARC specification can be extended in a backwards compatible way and will evolve over time. This is accomplished through a community-driven ARC discussion forum and pull request mechanisms. | |||
| The ARC specification can be extended and will evolve over time. This is accomplished through a community-driven ARC discussion forum and pull request mechanisms. | |||
|
|
||
| All changes that are not backwards compatible with the current ARC specification will be implemented in ARC specification v2.0. | ||
| Backwards compatible changes, e.g. the addition of new optional metadata fields, will be implemented in _minor version increases_. | ||
| All changes that are not backwards compatible with the current ARC specification will be implemented in _major version increases_. |
|
|
||
| ## Inputs and Outputs | ||
|
|
||
| Each annotation table sheet MUST contain at most one `Input` and at most one `Output` column, which denote the Input and Output node of the `Process` node respectively. They MUST be formatted in the pattern `Input [<NodeType>]` and `Output [<NodeType>]`. | ||
| Each annotation table sheet MAY contain at most one `Input` column. |
| @@ -565,6 +565,9 @@ This section MUST contain the following labels, with the specified datatypes for | |||
|
|
|||
| | Label | Datatype | Description | | |||
| |----------------------------------------------------|------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | |||
| | Assay Identifier | String | A mandatory unique identifier, either a temporary identifier supplied by users or one generated by a repository or other database. For example, it could be an identifier complying with the LSID specification. A value MUST be given for this label. | | |||
| @@ -340,6 +342,28 @@ Use of `folder specific pattern` relative paths from `Assay1` and `Assay2` `Data | |||
|
|
|||
| Note, that to reference `Data` which is part of `Assays1` in `Assay2`, the `general pattern` is necessary either way. Therefore it is considered the more broadly applicable and recommended pattern. | |||
|
|
|||
| ## Licensing | |||
| @@ -340,6 +342,28 @@ Use of `folder specific pattern` relative paths from `Assay1` and `Assay2` `Data | |||
|
|
|||
| Note, that to reference `Data` which is part of `Assays1` in `Assay2`, the `general pattern` is necessary either way. Therefore it is considered the more broadly applicable and recommended pattern. | |||
|
|
|||
| ## Licensing | |||
|
|
|||
| _Disclaimer: This is not legal advice, when in doubt consult a legal professional in your jurisdiction_ | |||
This PR will take care of the Scaffold spec part of #135.
(eventually)
closes #139
closes #138
closes #136