Prepare LabProtocol and LabProcess for Release

[HLWeil]

Internal reference

Changes towards #715

Description

We substantially softened requirements of the LabProtocol profile and added a new property parameter to the type. We also added a profile for LabProcess.

Motivation and context

We are making use of both the LabProcess and LabProtocol types extensively in the context of our ISA-RO-Crate-Profile and the ARC in RO-Crate. Here we identified the issue of too strict and extensive profiles, which are helpful in the context of a given community but can hinder interoperability between communities as the requirements vary. In our case, we softened the requirements of the LabProtocol profile to make it alignable with the Protocol class in ISA.
We would also like to advance the stable release of these types to make them more available (#715).

Have these been tested?

We have been using LabProcess and this less strict version of LabProtocol extensively in the context of our ISA-RO-Crate-Profile and the ARC.

What should reviewers focus on?

It would be great to get feedback on whether the changes are technically sound.

Types of changes

• LabProtocol
  • Added LabProtocol1.0_Draft type (new version)
    • now contains parameter property (following the official guide)
  • Added LabProtocol1.0_Draft profile (new version)
    • no required properties anymore, just recommended (following the official guide)
• LabProcess
  • Added LabProcess0.1_Draft profile (from scratch, following the official guide)
  • Added LabProcess0.1_Draft examples (new version)

Future TO-DOs

• check machine-actionability (LabProcess missing from machine readable files #706)
• Stable Release of LabProtocol and LabProcess
• release parameter, parameterValue, and executesProtocol as bioschemas properties

[gtsueng]

The files look good to me from a technical perspective (from a formatting perspective).

From a schema perspective:

• One thing to note is that LabProcess uses 'instrument' (inherited from Action), while LabProtocol has 'labEquipment' instead. It would be good to harmonize this property between the two. Note that Sample/BioSample also use 'instrument', so I would recommend replacing 'labEquipment' with 'instrument'.

Regarding the automated conversion to bioschemas webpages:

• The conversion does NOT work on types. Types must be manually generated.
  • You have to create the page manually for the bioschemas.github.io repository

@HLWeil @floWetzels -- please confirm whether or not there is any intention to harmonize the 'instrument' and 'labEquipment' property before the this draft is merged, or if the intention is to seek community input on the matter using this draft.

[HLWeil]

Thanks for your input, @gtsueng!

We do currently make use of the labEquipment property, but I guess switching to instrument would be totally fine, if it improves potential interoperability.

[gtsueng]

Thanks for your input, @gtsueng!

We do currently make use of the labEquipment property, but I guess switching to instrument would be totally fine, if it improves potential interoperability.

@HLWeil Does the LabProcess/LabProtocol working group prefer to merge it as is before community input, or to change it before merging it and sending it out for community input?

Lastly, is there a reason why the "@type" in the examples is an array?

[floWetzels]

Also thanks from my side, @gtsueng!
I have a few questions before switching from labEquipment to instrument: As LabProtocol doesn't inherit instrument from Action, do you want to replace labEquipment completely or create an additional attribute? How does this affect backwards compatibility? Also, if we replace labEquipment, how about computationalTool, since instrument should contain both, right?
If those questions are not easy to answer, I would prefer to proceed with the type and profile as is.

[floWetzels]

Regarding the "@type" field, I don't think there's a particular reason for it being an array. Depending on the tool you use, it is sometimes generated that way automatically. Also, in some use cases and RO-Crate profiles, we use combined types, so it could be a left-over from that. Do you want us to change it, @gtsueng?

[gtsueng]

Also thanks from my side, @gtsueng! I have a few questions before switching from labEquipment to instrument: As LabProtocol doesn't inherit instrument from Action, do you want to replace labEquipment completely or create an additional attribute? How does this affect backwards compatibility? Also, if we replace labEquipment, how about computationalTool, since instrument should contain both, right? If those questions are not easy to answer, I would prefer to proceed with the type and profile as is.

--Thanks for the clarification, @floWetzels! Let's proceed as is then. Regarding the array of "@types" in the examples, I was just curious since I'd never seen it before.

[gtsueng]

@albangaignard it looks like the tokens used in Sahar's script profile generation script expired. Can you fix/refresh it?