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
1 year 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?