Summary Vision Statement 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.