Question 9 might belong under findable

[tom-h]

code state: 390fb39

Q 9. "What approach does the software take to versioning?" probably best relates to "R3. Software meets domain-relevant community standards." but arguably overlaps with "F1.2. Different versions of the software are assigned distinct identifiers.".

It's currently under R, but could go under F.

[tom-h]

Sorry, it's currently under interoperability, but it could go under R or F.

[jspaaks]

When it comes to versioning, I see 2 reasons why we would ask about that:

1. to help further define the specific software version, in addition to just having the name of the software-as-a-concept. To me, this is not findability because adding or not adding a version in a search engine makes no difference in the likelihood of a new user discovering the tool (sidenote: I think what is discovered is always a concept, never a version). Of course, adding a version to your software's identifiers is helpful when you want to download or ask for a specific version. But by then, you have found it already, "it" being a potential solution to your problem/application. See also my answer to the related issue Question 2 should be under findable #88 (comment). IMO, q4 (particularly the first answer) sufficiently covers the case of software without a version, and should stay in the Accessibility section.
2. to help communicate interoperability/compatibility, specifically when using semantic versioning (its major, minor, and patch components hold information about what version or version range will work with other software and data). Because the purpose of asking about versioning is different for this bullet point compared to the previous one, I think question 9 can stay in the Interoperability section. I prefer it in I over R, because "domain-relevant" from R3 suggests things that apply to one domain but can't be applied to another, which doesn't seem applicable for versioning if you ask me.

Having said all that, of course we can make changes if somehow users get thrown off by how the checklist asks things, but let's go with more or less this content for now, then reevaluate later once we have actual experience in the form of user reviews.

[tom-h]

Okay yes, the question as posed doesn't map to the relevant principle under findable:

F1.2. Different versions of the software are assigned distinct identifiers.

I agree with you on that.

Interoperability has a very specific definition under the FAIR4RS principles, and I think you've interpreted it quite differently:

I: Software interoperates with other software by exchanging data and/or metadata, and/or through interaction via application programming interfaces (APIs), described through standards.
--
I1. Software reads, writes and exchanges data in a way that meets domain-relevant community standards.
I2. Software includes qualified references to other objects.

I don't see how the question maps to the high level definition of the principle or the two guiding principles.

I think if the FAIR principles had originally been written with software as a primary consideration, it's possible that "interoperability" wouldn't have made the cut. We spent so much time arguing about how to interpret "Interoperability" and the reason this narrow interpretation was chosen was to avoid a lot of overlap with the meaning of reusability. That's why there's only two guiding principles against it.

But as for R, or specifically:

R1.2. Software is associated with detailed provenance.
...
R3. Software meets domain-relevant community standards.

R3 ends up doing an insane amount of heavy lifting in the end. I usually take is as meaning "community norms". And this covers a lot of practices. The intent of the wording is not to contrast domains. The intent of the principle where reasonable, do what is accepted practice across the communities you are doing this within. This would mean scientific communities, but if I was submitting to CRAN, it would mean according to their norms as well, and then I think generally if producing any software, then according to more broadly recognised best practice like software versioning.

So I would argue it belongs under R.

[jspaaks]

code state: 34430c5

As a checklist user, I would expect the Interoperability section to ask me about how my software facilitates exchanging data (Q8), how it specifies which software it depends on (Q10), as well as how it can be used in conjunction with related software (Q11) and related data (Q12). It looks like we're mostly in agreement about the questions in this section, except for Q9. Allow me to first delve a bit deeper into Q10, and then I can explain how I think Q10 relates to Q9 afterwards.

Q10: "The software" is e.g. a top level program

As an example, let's say we are using the checklist to evaluate some software ("The software") that happens to have just one dependency ("The dependency"). Both "The software" and "The dependency" have multiple released versions. The importance of interoperability becomes immediately clear when one realizes that only a small subset of "The dependency"'s version history actually works for any given version of "The software", and that this subset may be different for different versions of "The software". For example, something like this:

It is therefore important that software authors supply the necessary information to consumers, such that the latter group can unambiguously know which version of "The dependency" they should have in order to make use of "The software". Hence Q10.

Q9: "The software" is e.g. a library

Ok so that's the case where "The software" is the top program so to speak, but interoperability is equally important in the reverse case, namely where "The software" under evaluation is in fact a libary of some sort that's being used by some "Other software". In other words, something like this (I've only changed the titles on the left, everything else is the same)

In my view, Q9 is simply the reverse of Q10, and thus belongs in the interoperability section. If "The software" does not facilitate differentiating between its versions, interoperability breaks down because "Other software" cannot reliably specify its requirements. You'd have something like:

[c-martinez]

My two cents to this discussion, I don't quite agree with this statement (sorry @jspaaks):

"domain-relevant" from R3 suggests things that apply to one domain but can't be applied to another.

I don't think that something being a community standard in one domain means that it cannot be applied to another. If version control is a community standard in domain A, it doesn't mean it cannot be applied to domain B. It only means that it is yet to become a standard on domain B.

Arguably, versioning could be considered as part of software provenance (R1.2)?