We've noticed an issue, where BTE as Service Provider (queried by other ARAs through the team-specific endpoint) returns a status 500 response with TypeError: item.upstream_resource_ids?.forEach is not a function.
So the main request is to fix this, so all upstream_resource_ids fields have values that are arrays of strings.
A second issue is that those upstream_resource_id values will likely fail TRAPI validation, because they are not infores. It seems like it'd make sense for these to be the same infores as the primary_knowledge_source...
And a note: infores:pubmed as the primary_knowledge_source seems a little vague. Has data-modeling agreed that that this is the best way to represent the provenance of this resource?
gloriachin
commented
11 months ago
We've noticed an issue, where BTE as Service Provider (queried by other ARAs through the team-specific endpoint) returns a status 500 response with
TypeError: item.upstream_resource_ids?.forEach is not a function.This has been traced back to Multiomics BigGIM-drug-response KP. For each TRAPI source object, the
upstream_resource_idsfield's value should be an array. But for some of this KP's BioThings API documents, thesources.upstream_resource_idsfield's value is a string: we found these documents with this issue, but there may be more.So the main request is to fix this, so all
upstream_resource_idsfields have values that are arrays of strings.A second issue is that those
upstream_resource_idvalues will likely fail TRAPI validation, because they are not infores. It seems like it'd make sense for these to be the same infores as the primary_knowledge_source...And a note:
infores:pubmedas the primary_knowledge_source seems a little vague. Has data-modeling agreed that that this is the best way to represent the provenance of this resource?