LabProtocol conflates an abstract protocol and an execution of that protocol

[multimeric]

LabProtocol is built on HowTo, which I think is a good choice. Notably, HowTo does not describe an action that has happened, but rather a recipe or procedure by which something might happen. However, this model is broken by protocolOutcome, which points to an actual file that has been produced as a result of running the protocol.

In an ideal world, I would like CreateAction to have a field like following: HowTo so that we can keep LabProtocol abstract but have CreateAction be a concrete application of that protocol. It doesn't have such a field, but there are other ways to represent this using something like PROV.

[multimeric]

The fact that LabProcess is explicitly defined as the execution of a LabProtocol supports this change, I think.

[marco-brandizi]

I think this is related to #675. From the discussion in there, my understanding is that properties like protocolOutcome are intended to describe the kind of outcome, not for the outcome of a specific protocol execution.

Moreover, yes, LabProcess, currently under drafts, introduces the separation between protocol as plan an protocol as the execution of a plan.

As for the link between the two, the LabProcess draft introduces the property executesLabProtocol. While I understand the need for a specific property here, at the upper level, being LabProtocol a subclass of schema:CreativeWork, that link could be stated via schema:about, or ^schema:subjectOf.

[multimeric]

I guess it might make sense to describe the abstract outcome, but I don't think it should be a CreativeWork, since that's concrete.

[marco-brandizi]

If protocolOutcome is intended as something like "the output of this is a treated sample", then it makes sense that its value is either a text or a subclass of CreativeWork.

Then, LabProcess will use result to link an actual, concrete output for a protocol execution, and such output is related to the protocolOutcome value as LabProcess is related to LabProtocol. That is, for both, we have the generic description level and the instantiation level, same as "Tesla Model T" and this "Tesla Model T, with number plate 123".

So, this part of modelling protocols and executions is fine to me.

[ljgarcia]

Hi @multimeric @marco-brandizi thanks for this discussion.

@sebeier was looking at LabProcess and they mentioned as well this distinction between "recipe and execution". Was the idea having LabProcess as "recipe" and LabProtocol as "execution"? We should retake this LabProcess and LabProtocol discussion.

@multimeric do you have a use case? It would be useful for us to have a LabProtocol use case at hand as it has not been yet adopted by the community. Thanks!

[marco-brandizi]

@ljgarcia maybe you mean the opposite? LabProtocol is a recipe, LabExecution is this pasta I'm eating, after having cooked it following the recipe.

[multimeric]

A LabProcess represents the specific application of a LabProtocol to some input (biological material or data) to produce some output (biological material or data).

This distinction is fine. I just didn't really like the protocolOutcome. If we treat it like an abstract outcome as @marco-brandizi suggests, then I would at least want this documented accordingly in the schema.

My use case for LabProtocol and LabProcess is to document the provenance of various biological data files. So if we have a protocol such as this one, we want to be able to say "this is the abstract protocol, here is the PDF, here is the protocol ID", and save it as a LabProtocol. Then, for each sample, we have a LabProcess that executes that protocol and then links to a concrete MediaItem file that was produced by the sequencing.