ICEES KG endpoint example queries not compatible with ICEES about plater HOT 7 CLOSED

@YaphetKG is it possible to customize the example queries per-plater instance? All of the ones on the automat site use this same disease to chemical entity query, even though it's not really a valid query for most of them.

Also, is it the case that the prefixes in meta_knowledge_graph are built from the data? Or does plater make assumptions about what the data ought to look like?

from plater.

Hi @cbizon , @karafecho
For the example query i think we can replace the example on deployment by mounting a custom json inplace of the default file. That way we can customize each instance with no code change to the repo.

As for prefixes , meta_kg is built from the data (

I checked the ICEES neo4j for nodes that have that curie listed in their id as well as equivalent ids

match (c) where any (x in c.equivalent_identifiers where x starts with 'RXNORMCUI') return c limit 1

but there seems to be no result. Could be the data is something different(?)

from plater.

Thanks for investigating, Yaphet.

Please let me know if you need anything from me to address the example queries.

WRT the meta KG prefixes, I'm confused. I had initially brought the issue to Max's attention, but he thought it was a Plater issue. @maximusunc, any insights?

from plater.

@YaphetKG @cbizon : So, Max reminded me that the current issue reflects a decision I made a while back. In short, Max, Hong, and I have been refactoring ICEES into two separate services: ICEES (fully featured, dynamic, non-TRAPI) and ICEES KG (limited in features, static, TRAPI). As part of that effort, we've been working to more fully automate and improve the various mapping steps, which had been introducing a lot of noise and incorrect mappings. The new process begins with a file that I manually created and that is leveraged for various downstream mapping and enumeration steps. The mapping of ICEES feature variables to Biolink prefixes/CURIES is based on search_term entries and limit parameters that I provided and that are used to programmatically call Name Resolver and retrieve Biolink CURIES for each variable. I tested the approach extensively and was aware of the limitations but felt it was best to harmonize with Translator than to harmonize with FHIR. However, when I looked at the meta KG, I had second thoughts.

I'm thinking that we should stick with the current approach, recognizing the limitations but accepting them. Note that there are related GitHub tickets that should eventually address these issues.

RxNorm: Biolink resolved RxNorm issue, moved issue to Node Normalizer, TranslatorSRI/NodeNormalization#127

ICD: open Biolink ticket, biolink/biolink-model#933

LOINC: open Biolink ticket, biolink/biolink-model#334; will not be a Biolink issue if we adopt LOINC2HPO

from plater.

Example queries are generated based on the SRI testing data file specific to that plater now, so the examples should always be valid.

from plater.

Yep, can confirm that the example query for automat icees-kg works. Thanks Evan!

from plater.

Thanks, all. Looks good now.

from plater.