Closed mbaudis closed 3 years ago
+1 on using the GA4GH recommended approach. I don't see the counts having a place in the current context for filtering terms yet, but seems an interesting idea.
Counts are very informative & e.g. used by us then in the front end to calculate statistics over the returned items (Beacon response -> front end fetches biosamples from handover link -> calculates frequencies of observed / filter base count). Also shows counts per filter in the search form etc. So IMO good as optional parameter; but YMMV ...
What does the count
count? The number of samples with this term? The number of individuals? If the term applies to both entities, what do we count?
@sdelatorrep Correct question, w/ several answers:
biosamples
; additional filters are shown w/o countscode_matches
; i.e. count
refers to the code + children, code_matches
to the specific assignments in the proposed filter use á la @tb143 this would be THIS:code
vs. THIS:code+
on the search levelfiltering_terms
endpoint, too; a general one, which has just lists of all filters, and then separate ones for biosamples
etc. Or declare that the biosample
(or individual) is the default scope.Also: Declare filtering_terms per dataset?
I will close this & open as a new issue regarding the response format.
While the example implementation presents a
filtering_terms
endpoint https://beacon-giab-demo.ega-archive.org/api/filtering_terms there is no specification for this to be found. Also, the format looks wrong:id
andlabel
ontology
parameter which is also an odd name in case of a custom filter and...ontologyTerms
butfilteringTerms
(as the path says).There is IMO no problem w/ additional fields; instead of the
ontology
attribute one could just have the standarddescription
, or aprovenance
, if needed.An IMO better use is presented in our implementation: