Scoping `repository-artifact` less narrowly in future versions?

[sdruskat]

While the scope of repository-artifact is documented to be somewhat narrower than CodeMeta's downloadUrl, its main use case is discovery (e.g. for reuse and reproducibility), which is arguably the same as for downloadUrl. Therefore the two can be assumed to signify the same. Future versions of CFF could document this more clearly.

In terms of key name, when a website (software homepage, GitHub release page) provides binaries, I'd argue that it fulfills the function of a repository, and thus no name change would be needed.

Wouldn't break "API", so could just be part of a MINOR release.

[sdruskat]

Clarification: This is only advocating for a small change in documentation wording, e.g., "The URL of the work in a build artifact/binary repository (when the work is software)." -> "The URL to a build artifact/binary of the work (if the work ...)"

[acli]

What was the intended purpose of repository-artifact? What exactly qualifies as one?

For example (we can find examples right here on Github), when a library of binary artifacts (e.g., sound clips) is hosted in a code repository, is the url a repository-code or a repository-artifact? Is freesound (for example), a repository-artifact? or is it a repository? or is it just a url?

I find it very hard to distinguish between repository-artifact, repository and url. My code cites freesound several times and I concluded that freesound is not a repository-artifact, probably not even a repository, but just a url. If my conclusion is incorrect we probably need to either describe these fields better, or provide some (realistic) examples, or both.

[jspaaks]

@acli how well does identifiers with type url fit your purposes? That allows describing what a given url is in description so that at least humans know how to interpret the link (In the future, we may expand this to machine readability too, see https://github.com/citation-file-format/citation-file-format/issues/69#issuecomment-551066432)

[sdruskat]

From a discussion with @jspaaks we feel that this is actually a confusing field, as its scope is neither narrow enough to be very clear.

What we could do is:

• [ ] Analyze the CFF corpus to see if people actually use it
• [ ] Consider it for deprecation
• [ ] Consider to replace it with other things like: package manager, publication repository or somesuch.

Also, in the context of, e.g., SE research, source code is also artifacts, and so what is the distinction between this key and repository-code?