Open aschampion opened 6 years ago
That's a great idea! We should indeed leverage existing annotations more and allow CATMAID's general ability of semantic annotations to be used for more interesting features like you describe. The existing ontology and classification APIs of the Ontology Tool in CATMAID are too limited and were designed without neurons or tens of thousands of linked objects in mind. And while the existing neuron annotation API is quite flexible, it can't handle complex queries at all. To allow more robust implementations on top of such an API, I agree, GraphQL sounds reasonable. And being able to formulate relational queries to this annotation graph would be super cool and would really simplify (and make possible) some use cases.
As a second step, it might even be useful to introduce proxy models for annotations (to not require explicit annotation class references), but that's nothing needed initially (or possibly at all). Just having the models you suggested would be nice already.
Also CATMAID's Ontology Tools also don't have any particular requirements for the models you list. If we would update the Ontology Tools to use the GraphQL API, we could add the additionally required models like constraints/restrictions, which are not used anywhere else.
If I understand it correctly, with graphene-django
we would have one endpoint. Should that just be /{project_id}/graphql
or would you suggest something else? And we probably don't need any client library, do we?
In order to enable #1569, which is essential both for exploring repeated-motif and cross-project (i.e., comparative connectomics) circuits, I'm planning to expose a GraphQL endpoint for annotations. Specifically, the endpoint would use graphene-django to expose GraphQL models initially for:
Project
Class
ClassClass
ClassInstance
ClassInstanceClassInstance
Relation
RelationInstance
This would enable arbitrary, complex annotation/ontology querying from the client beyond what is available in the neuron search widget and with a distinct domain of use. On top of this simpler UI could be built exploiting annotation conventions (e.g., finding lateral/segment/cross-project homologous sets of skeletons) as described in #1569.
I'm planning to start on this 2 weeks from now, so this issue is to collect any objections or additional requirements (esp. from @tomka).