You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following the Translator engineering call, we had an async cross-team discussion about how the new statistical significance qualifier should be filtered by default, and where in the stack that filtering should live. Participants: @tokebe (Retriever), @maximusunc (Gandalf), @SkyeAv (ARAX + Shepherd). This issue records those decisions in writing so they can be referenced from subsequent issues and PRs; until now they existed only in the engineering call notes.
Decisions
Filtering is a Gandalf thing. Any implicit filtering should happen in Gandalf itself — filtering before retrieving all possible paths is always going to be faster, and Gandalf is not the performance bottleneck. It does not belong in Shepherd or anywhere else in the stack.
Defaults are overridable via TRAPI. The statistical significance qualifier gets a default significance cutoff (value TBD) that standard TRAPI qualifier constraints can override. The same discussion covered negated edges, which follow the same default-and-override shape (excluded by default, clients opt in via query).
Open questions
What is the exact TRAPI standard for communicating the cutoff override (and filter overrides generally)? A companion Retriever issue will coordinate the override standard and the Retriever-side pass-through.
Context
Following the Translator engineering call, we had an async cross-team discussion about how the new statistical significance qualifier should be filtered by default, and where in the stack that filtering should live. Participants: @tokebe (Retriever), @maximusunc (Gandalf), @SkyeAv (ARAX + Shepherd). This issue records those decisions in writing so they can be referenced from subsequent issues and PRs; until now they existed only in the engineering call notes.
Decisions
Open questions
Related