Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

filtering terms type for ontology filters #128

Open
tb143 opened this issue Jun 3, 2024 · 4 comments
Open

filtering terms type for ontology filters #128

tb143 opened this issue Jun 3, 2024 · 4 comments

Comments

@tb143
Copy link
Collaborator

tb143 commented Jun 3, 2024

There is some inconsistency in the use of filtering terms type for ontology filters.

Sometimes this is specified as the ontology/terminology full name, sometimes it is specified as an enum value "ontologyTerm".

It is ontology/terminology full name in beaconFilteringTermsResults.json and an enum value in filteringTermsSchema.json and the documentation.

I think we need to explicitly specify the ontology used and not rely on the term identifier prefix. For example, compare the different contexts (descendant terms) of HP:0002037 when it is used in HP compared to EFO.

To reduce the repetition of long ontology names from the endpoint, I propose that instead of using the full ontology name as the type, we use the ontology abbreviation. For example, "SNOMED CT" instead of "Systematized Nomenclature of Medicine Clinical Terms".

@mbaudis
Copy link
Member

mbaudis commented Jun 3, 2024

@tb143 A technical comment: Please use the YAML version in source as reference :-)

@tb143
Copy link
Collaborator Author

tb143 commented Jun 3, 2024

@mbaudis are they different?

@mbaudis
Copy link
Member

mbaudis commented Jun 3, 2024

General comments:

  • All 3 definitions of

@mbaudis are they different?

In readability ... And, procedurally, changes should be edited in the src / .yaml` version and then converted to JSON where the conversion already tests the edits (however I guess small changes are sometimes parallel edited ...).

@mbaudis
Copy link
Member

mbaudis commented Jun 3, 2024

One main issue is to clarify/understand the 3 different filter definitions:

  1. In framework/configuration: This is where the format of a filtering term object resides; I am not sure how it ended there but I presume it is to make it model independent
  2. In framework/requests: Here we have the filtering term request object, including child parameter such as includeDescendantTerms to tune its interpretation
  3. In framework /responses/sections ...: This is the definition of the filtering terms exposed by the /filtering_terms endpoint. It can contain information which are not really derived from the terms themselves but also from their procedural use (e.g. which entities will be affected when applying this filter to the beacon - think filtering of variants by the diagnosis of their biosamples).

IMO a good start would be to tabulate the different types & their parameters against each other. And to think if they couldn't be collapsed a bit more ..,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants