graphicRequirements about codemeta HOT 3 OPEN

Hello @proycon,
Sounds reasonable even if CodeMeta strives to keep the the number of codemeta properties small.
We haven't identified this request before the March vote for the V2.0.
PMC, do you have any objection with adding this property?

@mbjones @progval @tmorrell @cboettig @abbycabs @dgarijo @arfon @proycon
A reminder: V2.1 will be released with new crosswalks without changing the vocabulary
v3.0 will be released with the labeled v3.0 issues and PRs following the March 2023 discussion and vote
We strive to keep v3.0 backward compatible (we should review this strategy for v4.0)

from codemeta.

Rather than graphicRequirements, can we generalize under hardwareRequirements? I have checked in schema.org and I have found nothing of the sort.

Other hardware requirements may arise that can be captured with this property. For example, what if you need TPUs instead of GPUs? Or what if you need a quantum architecture? (in the future).

from codemeta.

As processorRequirements is a free-text field at this point, I think it is meant to be purely a description to aid discovery and understanding, and not to be machine-parseable nor comprehensive. A GPU is a type of processor, and certainly fits there. While I don't see a problem with adding this graphicRequirements field, I also don't see a benefit -- any relevant info could be in the existing field and would serve the same purpose. As @dgarijo said, a more general field for hardware requirements could be useful (and could possibly subsume the processor field).

Whether a new field gets split out or not probably should be tied to how well its value space is defined -- splitting things out makes sense when we want to be able to perform structured queries over that field's value-space, or want to pull form a controlled vocabulary, whereas text paragraphs can generally be combined together without any decrease in search or display capability.

from codemeta.