This proposal is responding to the Knowledge Provider (KP) program component of OTA-19-
009 with the target of bringing high-value knowledge sources (KS) into the Translator
ecosystem and providing its underlying infrastructure and utilities (BioThings SDK + SmartAPI)
to the Translator community for future KS inclusion.
The overall goal of the Translator Program is to build a system to carry out diversified and
domain-specific queries on an integrated, scalable, continuously updated knowledge base.
Through its pilot phase, a feasible architecture design of the Translator system has been
proposed as a distributed platform with individual web APIs (or web services) from KPs as the
basic building blocks. Given the heterogeneous nature of the underlying biomedical KPs, web
APIs abstract the underlying complexity from individual KSs and provide efficient knowledge
access via web protocols (often HTTP or HTTPS) for the downstream consumers. In this
proposal, we argue that a successful Translator architecture builds upon a distributed API
ecosystem from knowledge providers.
In this distributed architecture, each KS
provides an API as the only interface for its
downstream consumers. Each API will be
maintained individually so that the burden will
be distributed as well. For downstream
consumers, they need to know precisely what
the input and output of each API are in order
to translate user queries to a sequence of API
calls and process their output. One possible
approach is to force all KS to implement APIs
with one standard, but that requires
significantly increased implementation and
on-going maintenance burdens. Sometimes,
reimplementing an API is not even possible
(e.g. a KS API from an outside group). In this
proposal, we propose a balanced solution
which allows each KS API to implement in
their own way, but provides a standard
mechanism to create semantically precise
annotations of each API’s inputs and outputs
so that the consumers know how to trigger
API calls automatically and process the
output across APIs.
We propose a staged process turning any KS into a Translator “KP-ready” API (Figure 1). For
each of the identified high-value KSs (detailed in Table 1 from the milestone section), if the KS
only provides the access of flat-file downloads, we will offer an efficient way to “API-ify” that KS
using our API development kit, BioThings SDK (Software Development Kit). Then for new APIs
we build or for existing KS APIs, we will use SmartAPI as the mechanism to semantically
annotate API’s input and output, turning them into standard-compliant KP-ready APIs to be part
of the Translator distributed knowledgebase.
During Translator’s pilot phase, BioThings SDK has been developed to power a collection of
“BioThings APIs” (https://biothings.io) which have been widely used within and outside of the
Translator community (~10 million monthly requests from ~20K of unique IPs). Our team also
developed SmartAPI (https://smart-api.info) web application, which is currently serving as the
default API registry for the Translator community.