Some of our data adapters work by combining data from two different APIs, with different conventions for representing values. Although these adapters are generally aimed at APIs that follow LZ conventions closely, in practice they often are used for data formatted in many ways.
As we expand usages of these data sources, we will need to take into account differing usage scenarios.
GwasCatalogLZ -> combineChainBody: chooses the most significant hit based on log_pvalue. Need to auto-detect the correct match field, and choose the sign of the comparison (log_pvalue vs pvalue)
Low priority because almost no one will be creating their own gwas catalog endpoint.
AssociationLZ:normalizeResponse sort option: most datasets are already sorted by position, but some are not; this opt-in config setting assumes that they sort field is a specific string. ("position").
Some of our data adapters work by combining data from two different APIs, with different conventions for representing values. Although these adapters are generally aimed at APIs that follow LZ conventions closely, in practice they often are used for data formatted in many ways.
As we expand usages of these data sources, we will need to take into account differing usage scenarios.
GwasCatalogLZ->combineChainBody: chooses the most significant hit based onlog_pvalue. Need to auto-detect the correct match field, and choose the sign of the comparison (log_pvaluevspvalue)AssociationLZ:normalizeResponsesort option: most datasets are already sorted by position, but some are not; this opt-in config setting assumes that they sort field is a specific string. ("position").