Mismatch FormalParameter with additionalType : File mapped to a PropertyValue instead of a File

[LauLauThom]

Hi,

I ran the nf-core/scrnaseq workflow with the nf-prov plugin.
I noticed in the ro-crate json that some inputs of the workflow (so called FormalParameter) like #param/input or #param/fasta with additionalType : File, are mapped to entries of type PropertyValue, where the value of the entry is actually a path to a file (e.g a csv on a GitHub repo, see example of such mapping below and json attached).

I think the type of the "value" entity should rather be File in this case too.
Entries of type PropertyValue are normally for other data-types such as boolean...
From the WF Run specs
"A FormalParameter that maps to a PropertyValue SHOULD have a subclass of DataType (e.g., Integer) — or PropertyValue, in the case of dictionary-like structured types — as its additionalType "

Parameter entry

        {
            "@id": "#param/input",
            "@type": "FormalParameter",
            "additionalType": "File",
            "conformsTo": {
                "@id": "https://bioschemas.org/profiles/FormalParameter/1.0-RELEASE"
            },
            "encodingFormat": "text/csv",
            "name": "input",
            "description": "Path to comma-separated file containing information about the samples in the experiment."
        },

Value entry

        {
            "@id": "#param/input/value",
            "@type": "PropertyValue", <= here should be "File"
            "exampleOfWork": {
                "@id": "#param/input"
            },
            "name": "input",
            "value": "https://github.com/nf-core/test-datasets/raw/scrnaseq/samplesheet-2-0.csv"
        }

ro-crate-metadata.json

[bentsherman]

I don't know if the RO-crate validator would consider that valid

[LauLauThom]

The validator actually considers it a valid Run Crate with profile 0.5 😅
Only had to remove the phone entry line 1721.
Should I just close the issue or ask if the validator should consider that too ?

Btw, I also noticed the conformsTo entry of the json is not listing a Workflow Run profile, only the workflow profile.
The provenance profile would be appropriate here I guess.

[simleo]

The validator actually considers it a valid Run Crate with profile 0.5 😅
Only had to remove the phone entry line 1721.

Even after removing the phone entry, the validator does not consider the crate valid at the REQUIRED level because there is no license. This is not a problem with the nf-prov implementation, it means that licensing info was not made available in the plugin configuration.

Btw, I also noticed the conformsTo entry of the json is not listing a Workflow Run profile, only the workflow profile.

Regarding the listing of profiles, nf-prov is already following the RO-Crate 1.2 spec, where profiles have to be listed in the conformsTo of the root data entity (which is listing all required profiles).

[simleo]

If the validator is run at the RECOMMENDED level, it finds a lot more "issues" (not violation of requirements but recommendations that have not been followed). One of them is:

     [ workflow-run-crate-0.5_11 ]: Workflow Run Crate FormalParameter
     that maps to a PropertyValue

      A FormalParameter that maps to a PropertyValue SHOULD have
      PropertyValue or a subclass of DataType as its additionalType

Following recommendations is not strictly required, but in this case it helps make the crate more accurate regarding inputs and outputs. Here following the recommendation means either changing the FormalParameter's additionalType to something like Text or using a File entity instead of the current #param/input/value PropertyValue. When an object or result is a file (possibly remote as in this case), it is more natural to represent it with a File entity. So in this case I think the plugin should use a File entity to represent the file, and keep the corresponding FormalParameter's additionalType as File.