ID resolver refactoring: the resolvable vs irresolvable types

[colleenXu]

We seem to be keeping a list of semantic types that are "resolvable" by the ID resolver here.

If we are still using this list, perhaps it needs to be revised...there are now some semantic types that we can resolve that we did not before (like ChemicalEntity and MolecularMixture) and some that we now cannot resolve (like SequenceVariant).

Use this link to see what semantic types the SRI-based ID resolver resolves (note we're using dev right now)

[colleenXu]

Related to the migration to the new SRI-based ID resolver #249

[ericz1803]

Those semantic types are only used by the old resolver, the new one returns the semantic types as a simple string without any of the type checking.

[colleenXu]

@ericz1803 Can you comment on whether "resolvable" vs "irresolvable" is a distinction that we still make and use somehow?

[ericz1803]

For semantic types, no. The SRI resolver doesn't use the semantic type list and there aren't any "resolvable" or "irresolvable" semantic types

[colleenXu]

@ericz1803 I was under the impression that the concepts of "resolvable" and "irresolvable" semantic types and ID prefixes was used to:
A. decide whether to send something to the ID resolver service (now the SRI dev url) to begin with....
B. how to choose / format the equivalent IDs / names (now the node's name / biolink:xrefs, biolink:synonyms node-attributes)

Is that not what is actually happening?

And is the concept of resolvable / irresolvable semantic types involved in the logic of other code, like the api-response-transform, query-graph-handler modules?

[ericz1803]

I don't know how it is used outside the id resolver but I can explain what is happening inside the id resolver. "resolvable" ids are those that the id resolver, either the old one or SRI can find equivalent ids for, "irresolvable" is the opposite. We need to handle them differently because of this.

Before, there were two classes, one for resolvable ids and one for irresolvable ids (which is what you see if you console.log the response). With the SRI resolver, we are just building plain JS objects. For the user who actually sees the resolver output, the response shapes are the same, as in both resolvable and irresolvable IDs have the same properties/fields.

With the SRI resolver, we just pass the ID to them regardless of semantic type or prefix and it will figure out if it can resolve them so there sort of is a concept of "resolvable" and "irresolvable" semantic types and ID prefixes but when the response is sent back to the user, it is all in the same format so I don't think there should be a difference in how anything that uses the id resolver deals with "resolvable" and "irresolvable" semantic types.

[colleenXu]

Alright, I'll close this then, to keep as reference. It sounds like this stuff is basically deprecated and shouldn't affect anything downstream...