Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Representing conditional execution #33

Closed
simleo opened this issue Oct 14, 2022 · 7 comments · Fixed by #70
Closed

Representing conditional execution #33

simleo opened this issue Oct 14, 2022 · 7 comments · Fixed by #70

Comments

@simleo
Copy link
Collaborator

simleo commented Oct 14, 2022

How should we model workflows where one or more steps are executed only if a condition is verified (e.g., when clause in CWL)?

@mr-c
Copy link

mr-c commented Oct 14, 2022

Sine this RO-Crate profile is about a particular enactment of a workflow, then it might be simpler to not model the condition.

As a bonus, I guess one could record the decision to skip a step. For CWL that would require the CWL document and the input object for that workflow step, then one could investigate the JavaScript statement that was evaluated and found to produce a False (== skip) result. For CWL steps that weren't skipped, the step input object should already be represented allowing a similar analysis post-run of the decision by a human evaluating the JavaScript statement.

@GlassOfWhiskey
Copy link
Contributor

GlassOfWhiskey commented Oct 14, 2022

This is related to #15. However, there is no SkippedActionStatus on schema.org. Maybe we need another field? Or we can use the PotentialActionStatus with that meaning?

@stain
Copy link
Contributor

stain commented Oct 17, 2022

It depends on the workflow language if conditional execution means the step is run or the datalink is rewired - presumably some evaluation happens though. Is that part of the ControlAction with no tool invocation?

Or would it be an AssessAction that could end up with either subclass IgnoreAction or ChooseAction? Might get quite elaborate as you would then as object of those have what was evaluated rather than what inputs were potentially going to be used.

{
  "@context": "https://schema.org",
  "@type": "IgnoreAction",
  "agent": {
    "@type": "Person",
    "name": "John"
  },
  "object": {
    "@type": "BefriendAction",
    "agent": {
      "@type": "Person",
      "name": "Steve"
    },
    "instrument": {
      "@type": "WebPage",
      "url": "https://www.social.com"
    }
  }
}

@simleo
Copy link
Collaborator Author

simleo commented Feb 16, 2023

StreamFlow is already using PotentialActionStatus

@simleo
Copy link
Collaborator Author

simleo commented May 31, 2023

In CWLProv, skipped actions are not recorded. Hence, in runcrate convert, the tool / subworkflow is listed in the prospective provenance but there is no corresponding action in the retrospective provenance. See ResearchObject/runcrate#45, which adds an example where a subworkflow is skipped. The approach there is to list the subworkflow and the corresponding step in the crate, but no corresponding action (like in CWLProv).

@simleo
Copy link
Collaborator Author

simleo commented Jun 22, 2023

StreamFlow is already using PotentialActionStatus

I ran the workflow used to test ResearchObject/runcrate#45 with Streamflow (0.2.0.dev5) and generated the RO-Crate: it turns out that it does not add an action with PotentialActionStatus. Instead, it behaves like runcrate after the merging of ResearchObject/runcrate#45 (subworkflow and step are listed, but no corresponding action).

@stain
Copy link
Contributor

stain commented Dec 21, 2023

TRE-FX also have execution states https://trefx.uk/5s-crate/0.4/#execution-states - but for the overall workflow. e.g. http://schema.org/ActiveActionStatus if it's still running. In theory if someone was doing similar execution steps for a workflow that is not yet finished, then some of those would be in PotentialActionStatus until it's not executed. You would need to add something like a https://schema.org/IgnoreAction control action show that the step was later NOT picked so it would get complicated. So I would support #70 for its simplicity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants