Generalize codebase to support more domains

[eladrion]

Feature Description

Currently, the code is rather tailored to the EDAM ontology. But in other areas, other ontologies and taxonomies exist which cannot be supported due to the partially hardcoded IRIs.

[eladrion]

This will be collaborative work with @CGru21 who has insight into other domains ontologies of interests

[vedran-kasalica]

Originally APE was domain agnostic, and I would argue that it still is for the most part.

I agree that it can be done better. Some features needed some ontology specific terms. For example CWL files are mostly used in life sciences, so we decided to make the creation easier to the average user by incorporating EDAM in the executable version of the CWL (abstract version is still domain agnostic, however it was never used so we stopped generating them by default). The ontology dependency is especially needed when you want to add features such as creation of CWL templates from existing resources, e.g. bio.tools - which is EDAM specific, those features have to be EDAM dependent.

Apart from those, APE should not depend on EDAM. Am I missing something?

[eladrion]

Hi @vedran-kasalica, what I am referring to are especially the hardcoded URLs to EDAM. This issue is rather a reminder that I need to discuss how to make the DATA_ROOT, FORMAT_ROOT, and DATA_ROOT_IRI configurable and there are different approaches here:

1. Keep the variables static but make them mutable, which limits one "APE run" to one ontology and the question is how APE behaves if it is used as an API
2. Have a "context" for each "APE run" which contains this information which is more complex to implement.

Since we want to apply APE for other domains which do not use EDAM but should work in principle, we need to resolve this somehow

[vedran-kasalica]

That's a good point. We had some issues when setting up REST APE, because even though the ontology is the same, the list of tools available was different depending on the use case. We ended up creating a new APE objects per domain/use case. Resources wise, I am not sure if allowing the user to change the configuration variables would save resources, but it might be more user friendly. We just never had other use case that needed it.