> For the complete documentation index, see [llms.txt](https://docs.standardknowledge.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.standardknowledge.com/other/motivations.md).

# Motivations

Developers commonly use SDKs or other code packages (node modules, ruby gems, etc.) to interact with the API of a software tool they want to integrate into their application. These methods provide convenience over having to writing code to communicate directly using HTTP requests but still have limitations. Due to resource constraints, software tools may not have an SDK or code package targeting every programming language or execution environment a developer may be using. Even if they find suitable wrappers for the API they wish to interact with, developers are left with the task of reading API documentation to know how to translate the unique data formats and capabilities of each API to the data formats and features of their application. This is not a trivial task, especially as the number of integrations they need increases.

The data integration problems outlined above are not new. Over a decade ago, Tim Berners Lee (colloquially known as the founder of the internet), proposed the concept of Linked Data to mitigate data integration issues. Linked Data was to provide a format that is both machine and human readable, allowing software tools and their creators to have a common understanding of data and what it represents. Unfortunately, it did not gain as strong of a following by tech companies as many would have hoped and is not used widely today.

There are still proponents who call upon tech companies to convert their APIs or build Linked Data compatible versions of their APIs. There are also proponents for establishing standard API features that solve for common capabilities across APIs so that software tools and developers can more easily access similar features by attributes of the feature rather than of the API.

The success of proposed methods is dependent on developers at different companies collectively agreeing to architect their APIs according to a shared criteria that doesn’t yet exist and that could limit their innovation or development cycles. In the fast-moving world of software startups, convincing enough companies to invest in the collective establishment of these standards (sometimes in concert with their competitors) is hard to do. Large companies are also at times loath to convert to more standard data formats, ontologies, and APIs because they amass great value by controlling the flow of data through and within their ecosystems, in part through proprietary APIs. The silos of data that arise through competing technology ecosystems ultimately lead to vendor lock-in that can stifle users’ range of capabilities and broader software innovation.

There is no perfect ontology for all use cases, and part of the value of Linked Data is that anyone can easily create their own or contribute to existing ontologies. The independent proliferation of various (and sometimes competing) ontologies of Linked Data can make it so that there is still a lot of manual work that has to be done by humans to integrate data which is formatted according to different ontologies. An important missing piece is therefore the standard translation across various ontologies, representations of data, and software capabilities.