I’m about to finish the current round of work on SWO, and there are a couple of issues outstanding that will need looking at by the next ontologist to work on SWO. I’ve also added these to the issue tracker.
- Software A references a particular version of Software B: In cases where we have a named or numbered version for Software A, this is straightforward. If an updated version of Software A comes out, we simply create a new class with that new version. However, in some cases, as has happened with EBI Muscle Web Tool, there was no obvious version of the web tool, and yet we know it referenced a particular version of Drive5 MUSCLE called MUSCLE 3.8.31. What happens when the web tool switches to a more up-to-date version? How do we name or otherwise model the change in the web tool? What’s the best way for situations like this?
- EDAM uses its own relationships output of / input of and their inverses. However, SWO already has such relationships via RO. It would make sense to align these two ontologies and have EDAM also use the RO relationships, if it is ontologically suited to EDAM. EDAM uses its own has input / has output, when RO already has these as well (RO_0002233 and RO_0002234). It would make sense to correctly model the RO terms (and their inverses which are already present in SWO anyway) and refactor EDAM accordingly.
- For EDAM: replace the class name “SBML file” with “SBML” or “SBML format”, as having “file” in a format class label seems a little misplaced.
- As the high level EDAM and SWO classes are now all aligned, we should tidy up the lower level classes within data, data format specification, etc. and sort them into the the nice lower hierarchies provided by EDAM.
- Ensure that all SWO URIs resolve properly to something sensible, and double check all external IDs.