rodenhausen
commented
8 years ago (2) we decided to not let the user continue working on an ontology that was preiously outputted (i.e. as input to a new task). Instead for a scenario like this, they should keep the task. This removes the problem that arises from keeping ontologies in different tasks synchronized with each other. E.g. if a ontology is outputted in task A, used as input in task B. But then task A keeps developing the ontology. Ontology in task B would be outdated.
(1) as discussed in the email once. The tool allows to work on a single ontology (alongside bioportal stuff) (2) the workflow can be to either create a fresh ontology OR continue with an ontology that was previously outputted by the tool (alternatively uploaded to file manager in the correct format (requires to implement a pretty rigorous format checking)) (3) in case of continue with an ontology that was previously created: The submissions that had been done to that ontology are not shown. The submissions are linked to the run, hence previous ones will not be shown. One can rewind the task to still see them, but if a new task is started they are not shown. Now, we could possibly implement a piece of code that approaches to reconstruct the submissions as good as possible from the OWL file content. these are my first thoughts also maybe to mention: the ontology view is based on the submissions and as said, the submissions are linked to the task, which means the view only shows the part of the ontology that was built inside that very task, and currently never all classes etc.