Fwd: Re: [BioVeL] Workflows in my experiment

[Alan Williams]

Hello everyone,

We have some requests from BioVeL.

Alan

-------- Original Message --------
Subject: Re: [BioVeL] Workflows in my experiment
Date: Wed, 30 Oct 2013 23:41:55 +0000
From: Jonathan Giddy <J.P....@cs.cardiff.ac.uk>
To: <bio...@cs.cardiff.ac.uk>

On 30/10/13 17:42, Alan R Williams wrote:
> @Jon - I think you should delete the BioVeL superseded group.

Done.

>
> There is a way to deprecate workflows - see
> http://www.myexperiment.org/workflows/256.html but the deprecation
> does not currently have an effect in the search results.
>
Thanks, Alan, but how can I make a message like this appear in the
workflow? Is it possible to change the top part of the message, as it is
not due to non-support of services. These workflows still work, it's
just that we don't want them to be used in new setups. Also, it would be
good to have this deprecation reflected in the summary displayed in a
search. And eventually, to remove these items from appearing in a search.

Looking back through the emails, I think there are several issues (I'd
just like to get this straight before I consider submitting JIRA issues):

1. The faces/logos appearing with the workflows should be configurable,
and should represent one or more creators of the artifact, while the
information on who uploaded the artifacts should be relegated to minor
information within the version description.

Currently, the Creator / Uploader / Original Uploader of the workflow
gets their name and image on the artifact. I'm not even sure what the
difference is between these categories. But there seem to be 3 main
"creators" of an artifact published in myExperiment:
- the creator of the myExperiment entry
- the uploader of a particular version of the artifact to the
myExperiment entry
- the creator(s) of the artifact itself

For many scientific workflow developers, all these are likely to be the
same person, so it doesn't matter. But in our project, we have several
people involved in creating a workflow, and this is not reflected in the
single user shown at the highest level of myExperiment. If the
population modelling workflows were a published paper, then Gerard,
Maria, and I would likely be co-authors. This is reflected in the
credits of the workflow, but this is a relatively minor feature of the
workflow annotations compared to the glory bestowed on the person who
happens to create the initial entry and upload the workflow.

For scientists who are searching for the workflows, Maria (the science
PAL) would likely be the face they associate with the population
modelling workflows. So, maybe it should be her face. Alternatively, it
could be all 3 faces, or it could just be the BioVeL logo as the face of
BioVeL workflows. Personally, I'm indifferent, but I think it should be
configurable by a workflow editor.

2. Maria also associated the face of the workflow with the contact for
user support. I would expect this to be a separate entry again,
allowing, for example, BioVeL support to be named instead of a
particular creator.

3. Following Gergely's suggestion, artifacts should be marked as current
and/or maintained by requiring a user (the support email?) to respond
periodically. Any workflows which do not respond are tagged as
potentially unmaintained, with a warning.

4. The Delete button should be replaced by a Deprecate button, which
allows the artifact to be accessed by direct links, but causes it not to
be shown in searches (unless overridden by a search option). In normal
operation, this allows tidying up of broken or superseded workflows
while not breaking any internal or external links to these artifacts.
Artifacts could also link to newer versions under a supersededBy annotation.

Of course, this is usually best handled, as Renato suggests, by simply
adding a new version to the same myExperiment entry, but real life can
get pretty messy, e.g. I add a new component-friendly version of the
workflow as a separate entry, so that the old "proper" version can still
be used by everyone else. Then, components become the "proper" way to do
things, and now we want everyone to use the new version, unless they're
in the middle of existing work, or reproducing work, or...

5. Real Deletion, where the link to the artifact is removed, is retained
as a less obvious operation, used mainly for special purposes (such as a
legal requirement to remove an artifact completely).

Were any of these issues dealt with in Wf4Ever? Deprecation vs deletion,
in particular, seems pretty fundamental to what Wf4Ever was trying to
achieve.

Thanks,
Jon.