Annotation Review wants to get GO CAMs from any search criteria combination (high level definition, but there are some constraints).
of term, pmid, gene product, curator, group and species.
Annotation review is in active development, so the api request requirements are not yet stable. Below are some of the solutions (brainstorming).
Approach 1 - To have all these as optional parameters
api/models?goterm=a&pmid=b&curator=y&species=z…
Problem
There are so many permutations for this to be all optional parameters which a server doesn't know. Both in terms of combination and operations. For example
GP=”x” and PMID = “y”
GP=”x” or PMID = “y”
(GP=”x” or PMID = “y”) and (curator=”a” or group=”b”)
GP=”x” and term = “y” doesn’t make sense
(PMID = “y”) and (curator=”a” and group=”b”) if and only if curator 'a' is in group 'b'
This will be too flexible. What y'all thoughts on this one?
Approach B - Factor out one or more parameters to be required
It will mean
get models with gp=a and goterm=b AND operation
api/gp/{a}/models?goterm=b&curator=y&species=z…
get models with either gp=a or goterm=b by curator y...
api/models?goterm=a&pmid=b&curator=y&species=z… OR operation
What y'all thoughts on this one?
Some Solution – Process oriented rather than data oriented api (Local Lookup+ Search + Local Filter)
Since there are not many curators and groups. Each model entity response can return a list of curators. Then can filter curators locally and make an educated guess about groups.
But this to work it need help from other apis for filter knowledge like grouped curators
The process of getting models with either gp=a or goterm=b by curator y might be
api/groups/api/curators/api/gp/{a}/models?fields=”title,curators,id,groups”localModelsFilter(curatorId)
What y'all thoughts on this one?
For the response,
Is it possible to specify which fields a client needs just like Solr
api/models?goterm=a&pmid=y&species=z&fields=”title,curators,id,groups”
Annotation Review wants to get GO CAMs from any search criteria combination (high level definition, but there are some constraints). of term, pmid, gene product, curator, group and species.
Annotation review is in active development, so the api request requirements are not yet stable. Below are some of the solutions (brainstorming).
Approach 1 - To have all these as optional parameters
api/models?goterm=a&pmid=b&curator=y&species=z…Problem There are so many permutations for this to be all optional parameters which a server doesn't know. Both in terms of combination and operations. For example
This will be too flexible. What y'all thoughts on this one?
Approach B - Factor out one or more parameters to be required
api/curator/{orcid}/models?goterm=a&species=z .api/gp/{gp}/models?goterm=a&species=z .api/group/{groupId}/models?goterm=a&&species=z .api/species/{species}/models?goterm=a&curator=y&species=z .It will mean get models with gp=a and goterm=b AND operation
api/gp/{a}/models?goterm=b&curator=y&species=z…get models with either gp=a or goterm=b by curator y...
api/models?goterm=a&pmid=b&curator=y&species=z…OR operation What y'all thoughts on this one?Some Solution – Process oriented rather than data oriented api (Local Lookup+ Search + Local Filter)
Since there are not many curators and groups. Each model entity response can return a list of curators. Then can filter curators locally and make an educated guess about groups.
api/models?goterm=a&pmid=y&species=z&fields=”title, curators, id,groups”
But this to work it need help from other apis for filter knowledge like grouped curators
The process of getting models with either gp=a or goterm=b by curator y might be
api/groups/api/curators/api/gp/{a}/models?fields=”title,curators,id,groups”localModelsFilter(curatorId)What y'all thoughts on this one?
For the response,
Is it possible to specify which fields a client needs just like Solr api/models?goterm=a&pmid=y&species=z&fields=”title,curators,id,groups”
tagging @kltm @lpalbou @cmungall - best approach @vanaukenk @thomaspd - Annotation Review requirements