Skip to end of metadata
Go to start of metadata

I just had an interesting conversation with one of my colleagues Jeroen Laross. I imagine that this could have a translation into what we are doing.

Jeroen and colleagues are building a bioinformatics pipeline out of command line tools. When a tool is updated and they build that in, the behaviour of the pipeline could change. Therefore they keep track of the tools' version numbers (e.g. by doing --version or if there is no version information do a MD5 checksum - do I spell that right?). If a tool's version has changed, they change the version number of the pipeline.

Would we be able to have something similar for workflows? I guess that including an update of a command line tool is always a deliberate step; for remote Web Services this is automatic and unseen. The workflow would not be changed, but its functionality might have. Perhaps a RO can have an additional version number reflecting underlying changes?  I would argue we would need the facility first, regardless of whether it is easy to find out if underlying services were updated.

This may seem to make published ROs mutable. However, a published RO should have time stamps all over the place: it only makes guarantees for the time of publication (analogues to paper publications). It is a best practice to keep everything working after publication.

Still, is 'version dependency' somehow a requirement for working and published ROs?

  • No labels