The refactoring of the objective specification hierarchy in SWO is part of a larger effort to merge the final distinct hierarchies in EDAM/SWO that can be usefully integrated. The EDAM operation hierarchy has been placed under information processing, and the SWO objective specification hierarchy will also be placed there. However, to do this we must drop the use of objective specification, as IAO says it sits within the information content entity hierarchy (http://www.ontobee.org/browser/rdf.php?o=IAO&iri=http://purl.obolibrary.org/obo/IAO_0000005) and not within the process hierarchy.
Changes made within SWO:
- Added domain of software and range of information processing to the object property is executed in, as well as a definition and other annotation. (See note 1 below).
- Moved all children of objective specification as children of information processing via refactoring in Protege 4. This required first moving all classes physically from swo_objectives and into swo_core.
- Refactored the URI for achieves planned objective to be http://www.ebi.ac.uk/swo/SWO_0040005, which is the URI for is executed in. This allowed, in just one step, for the ontology to remain satisfiable and for all of the axioms between software and processes (which used to be objectives) to be correct.
- Stated that EDAM operation is equivalent to SWO/ information processing.
- One class was marked as equivalent to Nothing after running the reasoner: OmniOutliner had an axiom ‘is executed in’ some ‘Outline document format’ which does not fit against the acceptable range of the is executed in property. This was changed to be linked to the information processing class Document outlining, which resolved the problem.
Still to do:
- information processing objective becomes inappropriate, and is cleaned up.
- swo_objectives is then no longer required and the file is removed from the imports in swo_core.
Note 1: on the use of is executed in: Originally, we had thought to use these two properties in SWO rather than is executed in:
If we had used is specified input of to link software to the new processes, the domain of its inverse (has specified input) is the OBI term planned process. Therefore, the appropriate hierarchy under BFO ProcessualEntity would have needed to be added: process, and then planned process, as has specified input has a domain of planned process. The simplest way of doing this is to simply change the uri of the process class within SWO; it currently points to the BFO ProcessualEntity and we simply refactored the URI of the SWO process class to match instead the BFO process class. Then we would just add an intervening child of the OBI planned process class.
This wasn’t required in the end, as it was determined that the use of the already-present SWO is executed in would be better at this stage, and simpler. Further, we determined that is executed in axioms should really only be placed on Software classes rather than also having an inverse that could go on information processing classes. If we place the input/output on the process then we define the process of, say, data normalization in terms of software, which is presumably not correct as there are data normalizations that don’t involve software, or at least specific software. If we hang it the other way we define the software in terms being able to be executed in a process, making this essential to the software (which is still not perfect) but not essential and defining for the information processing class (since the is executed in is not inverse). Neither is perfect but no one could quite think of a better way of capturing it. The problem as always is the ‘potential to do something’. Word can be used to do word processing but it can also be used to do document conversion. To do it properly properly you’d need to have processes called Microsoft Word word processing (process) which necessarily has input Microsoft Word but then you’d have dozens of specific classes for this, Star office word processing (process) Open Office word processing (process) etc.