Minimal requirements of "publishable ARCs"

[Brilator]

Lines 270 and 271 of the specification:

1. Investigation Person Mid Initials

I would suggest to remove this, since not everyone has mid initials (It is currently not tested by https://github.com/nfdi4plants/arc-validate)

2. Investigation Person Email

I would suggest to adapt this towards requiring at least the email of one person. Making this a hard requirement for every person added (and thus fail-validate all ARCs where just one email is missing) might be too much, since this is also data not frequently shared publicly. Coming from the use-case of retrospectively creating an ARC for an already published paper where you typically only find the email of the corresponding author. Email are also not as stable as ORCIDs, so don't necessarily help in terms of crediting.

[Brilator]

Created as an issue here rather than PR, since it would also need to be updated in https://github.com/nfdi4plants/arc-validate

@omaus @kMutagene

[kMutagene]

Created as an issue here rather than PR, since it would also need to be updated in https://github.com/nfdi4plants/arc-validate

arc-validate V2 will take the spec as absolute ground truth. I want to get away from testing and hot-fixing validation for different tools creating different arcs that follow different versions of the spec. Once the spec is released, there is only one ground truth that will be validated. So here is the best (and only) place to discuss and update these kind of things IMO.

[kMutagene]

I however agree with removing that requirement as not everyone has mid initials 😆

[HLWeil]

Not sure whether the publishability requirements belong here in the specification. Maybe we just link here?

[HLWeil]

@Brilator @kMutagene

[kMutagene]

I have mixed feelings about this. Ideally i would like this to be formalized somewhere else than the tool that is exporting and/or validating it, since i very much prefer the "specification is the truth" approach over "the tool defines it's own truth".

OTOH i see that a formal specification might not be the ideal place for something as dynamic as 'publishability'. Maybe we create a separate repository that tracks things like this? This could also serve as the truth for other validation / export workflows and packages.

[kMutagene]

For clarification, I mean a separate repo that contains a specification file for any kind of format mapping or metadata validation in text form. This can then serve as the basis for things such as validation packages or exporter tools.