Ontology-Oriented Software Development
面向本体的软件开发

Palantir

Follow

14 min read

·

Jan 23, 2024

376

4

Listen

Share

By Peter Wilczynski, Product Lead for the Ontology System
作者：Peter Wilczynski，本体系统产品负责人

“Show me the incentive and I’ll show you the outcome” — Charlie Munger
“告诉我激励，我就能告诉你结果”——查理·芒格

I.  我。

As an industry, we are producing more software at an ever-increasing rate and yet the impact of this software on economic productivity has been marginal.
作为一个行业，我们正在以不断增长的速度生产更多的软件，但这些软件对经济生产力的影响却微乎其微 。

This lack of progress is inherent to how the software industry itself is organized — the vast majority of human capital is focused on developing modular components rather than on integrating these components into cohesive enterprise systems that can actually impact business outcomes. We denigrate this integration work and elevate the components to the status of “systems,” instead of appropriately conceptualizing them as instrumental pieces of a larger puzzle. Digital transformation has become a goal in its own right, rather than a journey undertaken by skilled practitioners with a destination defined by the business itself.
这种进展缓慢的现象源于软件行业自身的组织结构——绝大多数人力资本专注于开发模块化组件，而不是将这些组件集成到能够真正影响业务成果的、具有凝聚力的企业系统中。我们贬低这种集成工作，将这些组件提升到“系统”的地位，而不是恰当地将它们概念化为一个更大谜题的工具碎片。数字化转型本身就成了一个目标，而不是一段由熟练的从业者踏上的旅程，其目的地由企业自身决定。

We’ve lost the plot by tricking ourselves into believing that because it’s easier to build individual parts, someone else must be able to assemble them into something worthwhile.
我们欺骗自己，认为因为制造单个零件比较容易，所以别人一定能够将它们组装成有价值的东西，但我们却迷失了方向。

The resulting software architecture is optimized to produce returns for venture capitalists, not to achieve outcomes for customers; it rewards zero-sum competition between suppliers of individual components rather than positive sum collaboration between partners focused on overall system performance. And while these individual pieces have improved drastically over the past twenty years, the paradox is that this has come at the expense of the enterprise system as a whole. By optimizing components in isolation, it becomes increasingly difficult to synchronize changes across multiple disintegrated components. As a result, improvements at the component level have failed to deliver improvements at the system level.
由此产生的软件架构优化旨在为风险投资家创造回报，而非为客户实现成果；它鼓励单个组件供应商之间的零和竞争，而不是专注于整体系统性能的合作伙伴之间的正和合作。尽管这些单独的组件在过去二十年中得到了显著改进，但矛盾的是，这是以牺牲整个企业系统为代价的。通过孤立地优化组件，在多个分散的组件之间同步更改变得越来越困难。因此，组件级别的改进未能带来系统级别的改进。

Despite being sold modularity, customers of this software-industrial complex have received a product that is fragmented and disintegrated. Rather than enabling agility, these investments have resulted in rigid enterprise architectures.¹ This technical rigidity seeps into the broader organizational culture and creates stasis.
尽管这家软件工业综合体向客户推销模块化产品，但他们收到的产品却支离破碎、支离破碎。这些投资非但没有带来敏捷性，反而导致了僵化的企业架构¹。这种技术僵化渗透到更广泛的组织文化中，造成了停滞不前。

At Palantir, our mission is to realize the emancipatory power of technology-driven progress for humanity — by empowering organizations to build bespoke software tools which can catalyze widespread enterprise transformation. Inconveniently, we quickly realized that there wasn’t a single product that could do that across the entire economy; i.e., this mission couldn’t be achieved by metabolizing a shared set of requirements and secreting the same shrink-wrapped software to all of our customers. The artisanal software engineering had to happen in situ.
在 Palantir，我们的使命是实现技术驱动进步对人类的解放力量——通过赋能组织构建定制化的软件工具，从而催化广泛的企业转型。然而，我们很快意识到，没有一款产品能够在整个经济领域做到这一点；也就是说，这一使命无法通过消化一组共享需求并将相同的打包软件秘密分发给所有客户来实现。手工软件工程必须在现场进行。

And to make that economically feasible, we needed to build technology which could drive the marginal cost of bespoke enterprise software development to zero.
为了使其在经济上可行，我们需要构建能够将定制企业软件开发的边际成本降至零的技术。

The architecture underpinning this is the Palantir Ontology, described in Akshay’s last blog post. This technology, along with its Software Development Kit (what we call the “Ontology SDK” or “OSDK”), makes it possible to defragment the enterprise by integrating isolated components into a holistic system. By implementing a decision-centric ontology which harmonizes data, logic and action elements from across the entire IT landscape, organizations can finally begin to think creatively about the intersection between their technology assets and business priorities.
支撑这一架构的是 Palantir Ontology， Akshay 在上一篇博文中对此进行了描述。这项技术及其软件开发工具包（我们称之为“Ontology SDK”或“OSDK”），能够通过将孤立的组件集成到一个整体系统中，从而实现企业碎片整理 。通过实施以决策为中心的本体，协调整个 IT 领域的数据、逻辑和行动要素，组织最终可以开始创造性地思考其技术资产与业务重点之间的交集。

II.  二.

Consider an airline trying to reduce downtime and eliminate delays due to mechanical issues.
假设有一家航空公司试图减少停机时间并消除因机械问题造成的延误。

As soon as a warning light goes off during a routine pre-flight check, the pressure begins to mount as people across the organization start to assemble their options. Complex decisions that involve real tradeoffs between safety, employee health and customer impact need to be weighed.
一旦例行飞行前检查中出现警示灯，压力就开始增大，因为整个组织的员工开始考虑各种方案。这些复杂的决策需要权衡安全、员工健康和客户影响之间的实际权衡。

This problem is a specific example of generalized resource allocation problems seen across industries. While resources may be proactively allocated according to a statistically optimal distribution, re-allocating these resources as the situation on the ground changes is the critical measure of enterprise agility: how quickly can the enterprise react to reality?
这个问题是各行各业普遍存在的资源配置问题的一个具体例子。虽然资源可以根据统计上的最优分布进行主动分配，但随着实际情况的变化而重新分配这些资源是衡量企业敏捷性的关键指标：企业对现实的反应速度有多快？

In our notional flight example, this involves answering three questions:
在我们的虚拟飞行示例中，这涉及回答三个问题：

• Does the aircraft need to be grounded?
  飞机是否需要停飞？
• Which airports have the right replacement parts and mechanics for performing the repair?
  哪些机场有合适的替换零件和机械师来进行维修？
• What options allow us to swap the aircraft while minimizing customer impact?
  有哪些选项可以让我们更换飞机，同时最大限度地减少对客户的影响？

Using IoT data from the plane (which can produce north of two million data points per flight), we need to understand how many flight hours the plane has left. To do this, our data scientists can load the IoT data and run a predictive maintenance model to get an initial estimation of how much service life is left.
利用来自飞机的物联网数据（每次飞行可产生超过两百万个数据点），我们需要了解飞机剩余的飞行小时数。为此，我们的数据科学家可以加载物联网数据并运行预测性维护模型，以初步估算飞机的剩余使用寿命。

Assuming the flight can take off, we need to start planning a fix. This means that our operations team needs to find out which airports have the right replacement parts in stock and cross-reference that data with maintenance crew schedules to identify a certified mechanic capable of performing the repair. Rather than kicking the can down the road, our goal is to swap the aircraft immediately so that it can arrive at a destination capable of completing the repair as soon as possible, ideally without impacting any customers.
假设航班可以起飞，我们就需要开始规划维修方案。这意味着我们的运营团队需要找出哪些机场有合适的替换零件库存，并将这些数据与维修人员的排班表进行交叉比对，找到一位能够进行维修的持证机械师。我们的目标是立即更换飞机，以便飞机能够尽快抵达目的地完成维修，同时最好不影响任何乘客。

Based on this criteria, we might identify two swap options which would result in the aircraft landing at either IAD or DFW. DFW would meet all of the constraints for the repair, but because the airframe has a different seat configuration, we’ll end up bumping three passengers, costing us $5,000 plus a reduction in customer satisfaction. IAD has the part that will need to be replaced and an empty hangar to work on it, but there are no mechanics with the specific skills currently scheduled for when the plane arrives; getting the fix done overnight will require us to schedule a mechanic to work overtime at an increased cost of $2,000.
根据此标准，我们可能会确定两种更换方案，使飞机降落在华盛顿杜勒斯国际机场 (IAD) 或达拉斯沃斯堡国际机场 (DFW)。达拉斯沃斯堡国际机场 (DFW) 满足所有维修条件，但由于机身座位配置不同，最终将有三名乘客被替换，这将花费我们 5,000 美元，并降低客户满意度。华盛顿杜勒斯国际机场 (IAD) 有需要更换的部件，也有一个空机库可以进行维修，但目前安排的飞机抵达时，没有具备特定技能的机械师；如果要在一夜之间完成维修，我们需要安排一名机械师加班，成本将增加 2,000 美元。

The first solution is simpler; the second, optimal solution requires swapping the plane and coordinating with the mechanic — i.e., requires more context and more degrees of freedom.
第一个解决方案更简单；第二个最佳解决方案需要交换平面并与机械师协调 - 即需要更多的背景和更多的自由度。

Finding the optimal solution programmatically involves the coordinated orchestration of many different data, logic and action elements. Data elements come from airport operational databases, flight manifests and resource management systems. These data elements are used as input to logic elements which can predict impact, model customer behavior and evaluate risk. Finally, the output of these logic elements are used to construct action elements which write back decisions to the appropriate operational systems and distribute real-time notifications to the right people.
以编程方式寻找最优解决方案需要协调编排众多不同的数据、逻辑和操作元素。数据元素来自机场运营数据库、航班清单和资源管理系统。这些数据元素作为逻辑元素的输入，用于预测影响、建模客户行为和评估风险。最终，这些逻辑元素的输出用于构建操作元素，这些操作元素将决策回写到相应的运营系统，并将实时通知分发给相关人员。

Translating this solution into an application on top of today’s fragmented enterprise architecture requires dealing with data from core transactional business systems, reconciling that with SaaS tools and custom internal systems and orchestrating actions across multiple different parts of the value chain. An engineer implementing this solution would need to learn the APIs of each system, set up the connections with IT teams at each organization and build an application that interacts with each system directly.
将此解决方案转化为基于当今碎片化企业架构的应用程序，需要处理来自核心交易业务系统的数据，将其与 SaaS 工具和自定义内部系统进行协调，并协调价值链各个不同环节的操作。实施此解决方案的工程师需要学习每个系统的 API，与每个组织的 IT 团队建立联系，并构建一个与每个系统直接交互的应用程序。

This knowledge — the knowledge of how to interact with the systems, how to reconcile their different data models, how to access their disjointed logic elements and how to orchestrate their systems of action — would live in yet another fragmented application or service, inaccessible to other teams within the organization who are trying to perform similar tasks. While API gateways can play an important role in enabling API discovery, programmers are still stuck harmonizing system-specific representations with glue code in the application layer.
这些知识——如何与系统交互、如何协调不同的数据模型、如何访问彼此脱节的逻辑元素以及如何协调其行动系统——将存在于另一个碎片化的应用程序或服务中，组织内其他执行类似任务的团队无法访问。虽然 API 网关在实现 API 发现方面可以发挥重要作用，但程序员仍然无法将特定于系统的表示与应用层的胶水代码进行协调。

The Ontology centralizes this knowledge and encapsulates it within a shared system. This system, along with the OSDK, then functions as a higher-level abstraction for authoring business logic which operates on a harmonized layer of critical business concepts, operational processes and real-world tasks. This allows translations from component-centric representations into the shared conceptual model to happen once, rather than every time a new application is built.
本体将这些知识集中起来，并将其封装在一个共享系统中。该系统与 OSDK 一起，作为编写业务逻辑的更高层次的抽象，该业务逻辑在关键业务概念、运营流程和实际任务的协调层面上运行。这使得从以组件为中心的表示到共享概念模型的转换只需进行一次，而无需每次构建新应用程序时都进行。

And this knowledge compounds rapidly; by relying on the shared decision-centric Ontology, new applications can take advantage of the preexisting system integration work, and new components can be onboarded quickly by harmonizing their data, action and logic elements with existing representations.²
而且这些知识会迅速复合；通过依赖以共享决策为中心的本体，新的应用程序可以利用预先存在的系统集成工作，并且可以通过协调其数据、操作和逻辑元素与现有表示来快速加入新组件。²

Consider the example from above. In a world before the Ontology, a programmer would need to find the appropriate components and then interact with each one using a component-specific interface, language and / or dialect. As a result, the code itself is fundamentally component-centric:
考虑上面的例子。在本体出现之前的世界里，程序员需要找到合适的组件，然后使用特定于组件的接口、语言和/或方言与每个组件进行交互。因此，代码本身从根本上是以组件为中心的：

const mysql = require('mysql');
const nodemailer = require('nodemailer');
const fetch = require('node-fetch');

// Inventory database connection configuration
const dbConfig = {
  host: 'skyframe-internal',
  user: 'db_admin',
  password: process.env.DB_PASSWORD,
  database: 'skyframe'
};

// Email server configuration (example using Gmail)
const transporter = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: 'swapbot@skyframe.com',
    pass: process.env.EM_PASSWORD
  }
});

// Connect to the inventory database and query for airports with inventory
async function findAirportsWithInventory(parts) {
  const connection = mysql.createConnection(dbConfig);
  const query = "SELECT airport_code FROM inventory WHERE part_number IN (?)";
  return new Promise((resolve, reject) => {
    connection.query(query, [parts.map(part => part.partNumber)], (error, results) => {
      connection.end();
      if (error) return reject(error);
      resolve(results.map(row => new Airport(row.airport_code)));
    });
  });
}

// Connect to the database and query for swappable flights
async function findSwappableFlights(flightToSwap, aircraft, targetAirports) {
  const connection = mysql.createConnection(dbConfig);
  const query = `SELECT * FROM flights
                 WHERE departure_airport_code = ? AND aircraft_id = ? AND destination_airport_code IN (?)
                 ORDER BY departure_time ASC`;
  return new Promise((resolve, reject) => {
    connection.query(query, [flightToSwap.departureAirportCode, aircraft.id, targetAirports.map(airport => airport.id)], (error, results) => {
      connection.end();
      if (error) return reject(error);
      resolve(results.map(row => new ScheduledFlight(row)));
    });
  });
}

// Function to calculate optimal swaps by calling an external REST endpoint
async function calculateOptimalSwaps(flightToSwap, swappableFlights) {
  const requestBody = {
    flightToSwap: flightToSwap,
    swappableFlights: swappableFlights
  };

  const response = await fetch('https://skyframe-internal-gateway/api/calculateOptimalSwaps', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer Ym9zY236Ym9zY28'
    },
    body: JSON.stringify(requestBody)
  });

  if (!response.ok) {
    const error = await response.text();
    throw new Error(`Failed to calculate optimal swaps: ${error}`);
  }

  const swapOptions = await response.json();
  return swapOptions;
}

// Function to calculate maintenance and customer impact costs by calling an external REST endpoint
async function calculateImpactCosts(swapOptions) {
  const requestBody = {
    swapOptions: swapOptions
  };

  const response = await fetch('https://skyframe-internal-gateway/api/calculateImpactCosts', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer Ym9zY236Ym9zY28'
    },
    body: JSON.stringify(requestBody)
  });

  if (!response.ok) {
    const error = await response.text();
    throw new Error(`Failed to calculate impact costs: ${error}`);
  }

  const impactCosts = await response.json();
  return impactCosts;
}

// Function to perform the swap operation
async function swapAircraft(targetAircraft, aircraft) {
  const requestBody = {
    targetAircraft: targetAircraft,
    aircraft: aircraft
  };

  const response = await fetch('https://skyframe-internal-gateway/api/swapAircraft', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer Ym9zY236Ym9zY28'
    },
    body: JSON.stringify(requestBody)
  });

  if (!response.ok) {
    const error = await response.text();
    throw new Error(`Failed to swap aircraft: ${error}`);
  }


  console.log(`Swapping aircraft ${targetAircraft.id} with ${aircraft.id}`);
}

// Function to send an email for swap approval (using nodemailer)
async function emailSwapsForApproval(swapOptions) {
  const mailOptions = {
    from: 'swapbot@skyframe.com',
    to: 'ground-control@skyframe.com',
    subject: 'Flight Swap Approval Required',
    text: `Approval is required for the following swap options: ${JSON.stringify(swapOptions)}`
  };

  return transporter.sendMail(mailOptions);
}

// Main function to schedule preventative maintenance
async function schedulePreventativeMaintenance(aircraft, parts) {
  try {
    // Assuming aircraft.getSchedule() and schedule.getNextFlight() are defined elsewhere
    const schedule = await aircraft.getSchedule();
    const flightToSwap = await schedule.getNextFlight();

    const targetAirports = await findAirportsWithInventory(parts);
    const swappableFlights = await findSwappableFlights(flightToSwap, aircraft, targetAirports);

    const swapOptions = await calculateOptimalSwaps(flightToSwap, swappableFlights);
    const impactCosts = await calculateImpactCosts(swapOptions);

    const cheapestOption = impactCosts.reduce((cheapest, option) =>
      option.cost < cheapest.cost ? option : cheapest,
      { cost: Number.MAX_VALUE }
    );

    // Guardrails for Options
    if (cheapestOption.cost < 1000) {
      await swapAircraft(cheapestOption.swapOption.targetAircraft, aircraft);
    } else {
      await emailSwapsForApproval(swapOptions);
    }
  } catch (error) {
    console.error('Failed to schedule preventative maintenance:', error);
  }
}

This is an intentionally abbreviated example — API request and response types are overly simplified, the underlying logic and action systems are exposed via a standard API gateway pattern, authentication is relatively consistent and the error handling is exceedingly trivial. Even still, the majority of the code is spent writing functions that connect directly to the underlying systems; the main scheduling function represents only a fraction of the total amount of code.
这是一个刻意简化的示例——API 请求和响应类型被过度简化，底层逻​​辑和操作系统通过标准 API 网关模式公开，身份验证相对一致，错误处理极其简单。即便如此，大部分代码还是用于编写直接连接到底层系统的函数；主要的调度函数仅占总代码量的一小部分。

By contrast, with an ontology-oriented development model, the defragmentation code required to harmonize the data, logic and actions across systems exists within the enterprise’s ontology, substantially simplifying the client code.³
相比之下，采用面向本体的开发模型，协调跨系统的数据、逻辑和操作所需的碎片整理代码存在于企业本体中，从而大大简化了客户端代码。³

Using the Ontology Software Development Kit (OSDK), which exposes the data, logic and action elements of the Ontology in idiomatic Python, Typescript and Java, we’re able to push most of the complexity into the Ontology itself and expose enterprise objects which correspond to direct representations of actual business concepts:
使用本体软件开发工具包（ OSDK ） ，它以惯用的 Python、Typescript 和 Java 形式公开本体的数据、逻辑和操作元素，我们能够将大部分复杂性推入本体本身，并公开与实际业务概念的直接表示相对应的企业对象：

async function schedulePreventativeMaintenance(aircraft: Aircraft, parts: AircraftComponent[]) {
  const schedule: FlightSchedule = await aircraft.getSchedule();
  const flightToSwap: ScheduledFlight = await schedule.getNextFlight();

  const targetAirports: Airport[] = await OntologyClient.search()
    .airports()
    .filter(a => a.inventory.containsAll(parts))
    .all();

  // Find flights from the same departure location to airports with inventory
  const swappableFlights: ScheduledFlight[] = await flightToSwap.getDepartureAirport()
    .scheduledFlights()
    .filter(f => f.aircraft.airframe.exactMatch(aircraft.airframe))
    .filter(f => f.destination.isOneOf(targetAirports))
    .orderBy(f => f.departureTime.asc())
    .all();

  const swapOptions: FlightSwapOption[] = await OntologyClient.calculateOptimalSwaps(flightToSwap, swappableFlights);
  const impactCosts: SwapOptionCost[] = await OntologyClient.calculateImpactCosts(swapOptions);

  const cheapestOption = impactCosts.reduce((cheapestOption, option) =>
    option.cost < cheapestOption.cost ? option : cheapestOption,
    { cost: Number.MAX_VALUE },
  );

  // Guardrails for Options
  if (cheapestOption.cost < 1000)
    await OntologyClient.action.swapAircraft(cheapestOption.flight, aircraft);
  else
    await OntologyClient.action.emailSwapsForApproval(swapOptions);

As Brooks says in his seminal paper, there is no silver bullet: systems integration is replete with essential complexity which must be managed and cannot be eliminated. But by enforcing design patterns which encapsulate this complexity within the Ontology, ontology-oriented client code is able to operate at a higher level of abstraction. Much as higher-level languages allowed programmers to abstract away the internal implementation details of the hardware components that make up a physical computer, the ontology-oriented approach allows programmers to abstract away internal implementation details of software components that comprise an enterprise architecture.
正如布鲁克斯在其开创性论文中所说， 没有灵丹妙药 ：系统集成充满了本质的复杂性，必须加以管理，而无法消除。但是，通过强制执行将这种复杂性封装在本体中的设计模式，面向本体的客户端代码能够在更高的抽象层次上运行。正如高级语言允许程序员抽象出构成物理计算机的硬件组件的内部实现细节一样，面向本体的方法也允许程序员抽象出构成企业架构的软件组件的内部实现细节。

In this example, the programmer interacts with these business concepts using the OSDK and writes code in the language of the business — not in terms of rows and columns, but in terms of Airplanes, Flight Schedules, and Airports. The OSDK isn’t providing a generic API for our product — it’s providing a toolkit for building APIs for your business, in the language of your business.
在这个例子中，程序员使用 OSDK 与这些业务概念进行交互，并以业务语言编写代码——不是以行和列为单位，而是以飞机、航班时刻表和机场为单位。 OSDK 并没有为我们的产品提供通用 API — — 它提供了一个工具包，用于以您的业务语言为您的业务构建 API。

III.  三

Higher-level abstractions in software are always disruptive in the precise sense described by Clayton Christensen — they start by tackling the simplest programs, but because of their underlying structural advantages, the developing technology is then able to leapfrog the incumbents.
正如克莱顿·克里斯坦森 (Clayton Christensen) 所描述的那样，软件中更高级别的抽象总是具有颠覆性 ——它们从解决最简单的程序开始，但由于其底层结构优势，开发中的技术能够超越现有的技术。

With the Ontology, the leapfrogging occurred by supercharging our ability to build custom applications. As anyone who’s used low-code visual programming tools knows, those applications always hit a ceiling. As a result, the implicit decision you’re making when choosing a low-code development tool is to constrain the ambition of the solution you’re building.
有了 Ontology，我们通过增强构建自定义应用程序的能力实现了跨越式发展。任何使用过低代码可视化编程工具的人都知道，这些应用程序总会遇到瓶颈。因此，在选择低代码开发工具时，你所做的隐性决定就是限制你正在构建的解决方案的规模。

Establishing our application building platform on top of the Ontology changed this situation in three ways.
在本体之上建立我们的应用程序构建平台从三个方面改变了这种情况。

First, it made low-code applications more powerful. Low-code builders could leverage code-based data, logic and action elements in their low-code applications, pushing the performance ceiling higher than we’ve seen in any other low-code environment. This power enables builders to develop operational line-of-business applications directly within a visual programming environment.
首先，它使低代码应用程序更加强大。低代码构建者可以在其低代码应用程序中利用基于代码的数据、逻辑和操作元素，从而将性能上限推至比我们在任何其他低代码环境中看到的更高的水平。这种强大功能使构建者能够直接在可视化编程环境中开发可操作的业务线应用程序。

Second, when builders reached the threshold of what was possible to build using a low-code development environment, the OSDK allowed them to migrate seamlessly into a traditional code-based development environment without having to reimplement the entire application from scratch.
其次，当构建者达到使用低代码开发环境进行构建的极限时，OSDK 允许他们无缝迁移到传统的基于代码的开发环境中，而无需从头开始重新实现整个应用程序。

Third, the Ontology made it easy to build low-code and pro-code applications designed to interoperate with one another. Both low-code and pro-code approaches have different tradeoffs: low-code tools lower the threshold for getting things built and make application development more accessible, while code-based tools raise the ceiling, enabling advanced users to do more powerful things and build more complex experiences. Synthesizing the two approaches via the Ontology lets users pick the right tool for the job at hand.
第三，本体使得构建低代码和高代码应用程序变得更容易，这些应用程序旨在实现相互操作。低代码和高代码方法各有优缺点：低代码工具降低了构建门槛，使应用程序开发更容易上手；而基于代码的工具则提高了门槛，使高级用户能够执行更强大的功能并构建更复杂的体验。通过本体将这两种方法结合起来，用户可以选择适合当前工作的工具。

Recently, we’ve seen the same structural advantage provided by the Ontology play out with our AI Platform (AIP), which provides a foundational set of user-facing capabilities along with a development toolchain for building bespoke AI systems and deploying them directly into operational workflows.
最近，我们看到本体提供的相同结构优势在我们的人工智能平台 (AIP) 上得到体现，该平台提供了一套面向用户的基础功能以及用于构建定制人工智能系统并将其直接部署到操作工作流中的开发工具链。

Why were we able to release AIP so fast?
为什么我们能够这么快发布 AIP？

It’s because from one crucial perspective, AI systems are more like applications than they are like users — they interact directly with APIs!
这是因为从一个关键的角度来看，人工智能系统更像应用程序而不是用户——它们直接与 API 交互！

Since the dawn of computing, interface design has always been optimized to make digital systems more accessible to humans, either as users or programmers. Over the past century, we’ve shifted from punch cards to CLIs, and from CLIs to GUIs, always with human usability as the north star.
自计算机诞生以来，界面设计一直在不断优化，以使数字系统更容易被人类（无论是用户还是程序员）所使用。在过去的一个世纪里，我们从穿孔卡片转向命令行界面 (CLI)，又从命令行界面转向图形用户界面 (GUI)，始终以人性化为导向。

But as we transition into a world in which humans collaborate directly with progressively more functional AI systems to achieve their missions, our definition of accessibility must expand to allow autonomous systems to take on progressively more complex tasks.
但随着我们进入一个人类直接与功能越来越强大的人工智能系统合作完成任务的世界，我们对可访问性的定义必须扩展，以允许自主系统承担越来越复杂的任务。

LLM-based systems have been made in our image; like humans, they can use text-based interfaces and interact with natural language representations of the world. But this similarity is deceptive, and will not be true for all AI systems; indeed, it is not true for all AI systems today — AlphaStar does not interact with pixels or words when it plays StarCraft.⁴
基于法学硕士 (LLM) 的系统是按照我们的设想构建的；它们像人类一样，可以使用基于文本的界面，并与自然语言表征的世界进行交互。但这种相似性具有欺骗性，并非所有人工智能系统都如此；事实上，并非所有当今的人工智能系统都如此 ——AlphaStar 在玩《星际争霸》时不会与像素或文字进行交互。⁴

By deconstructing applications and data systems into their constituent data, logic and action elements, the Ontology exposes a singular, decision-centric model of the enterprise. This shared model can be used as a unitary representation which is exposed through three distinct types of interfaces:
通过将应用程序和数据系统解构为其组成数据、逻辑和操作元素，本体揭示了一个单一的、以决策为中心的企业模型。该共享模型可以用作统一的表示形式，并通过三种不同类型的接口公开：

1. Graphical User Interfaces (GUIs), which provide users with visual representations of the Ontology.
   图形用户界面 (GUI)，为用户提供本体的可视化表示。
2. Application Programming Interfaces (APIs), which provide programmers and AI systems with direct access to the Ontology.
   应用程序编程接口 (API)，为程序员和人工智能系统提供对本体的直接访问。
3. Natural Language Interfaces (NLIs), which allow humans and language-based AI systems to interact with the Ontology using natural language.
   自然语言接口 (NLI)，允许人类和基于语言的人工智能系统使用自然语言与本体进行交互。

As J. C. R. Licklider stated in Man-Computer Symbiosis, “the basic dissimilarity between human languages and computer languages may be the most serious obstacle to true symbiosis.” The Palantir Ontology is a technical solution to this linguistic challenge: instead of treating each different interface as a distinct language, an ontology represents a single language capable of being expressed in graphical, verbal and programmatic forms.
正如 JCR Licklider 在 《人机共生》一书中所说，“人类语言和计算机语言之间的基本差异可能是实现真正共生的最严重障碍。”Palantir 本体论是针对这一语言挑战的技术解决方案：本体论不是将每个不同的界面视为一种不同的语言，而是代表一种能够以图形、语言和程序形式表达的单一语言。

Realizing the potential of operational AI in an enterprise context is not an AI problem — it’s an ontology problem.
在企业环境中实现运营人工智能的潜力不是一个人工智能问题，而是一个本体论问题。

¹ Twenty-five years after publication of Big Ball of Mud, the paper’s observations about the state of enterprise architectures remain uncannily accurate; adopting new components has increased the complexity of the system, with the result that the underlying structural issues have only been exacerbated.
¹ 《泥球大战》 发表二十五年后，该论文对企业架构现状的观察依然惊人地准确；采用新组件增加了系统的复杂性，结果导致底层结构问题更加严重。

² For an example of what the end result of this development style looks like, browse through the Skywise Store to see what the result of ontology-centric development model looks like in practice.
² 要了解这种开发风格的最终结果，请浏览 Skywise Store 以查看以本体为中心的开发模型在实践中的结果。

³ It’s important to note that the actual implementations for data, logic and action elements still exist — they just exist as clearly-defined lower-level abstractions. One way to think about the Ontology is as a somewhat sophisticated monorepo which enforces certain conventions which lead to a more composable system: while it’s of course possible to abuse the Ontology and end up with the same amount of fragmentation, the patterns of encapsulation enforced by the Ontology are designed to prevent that.
³ 值得注意的是，数据、逻辑和操作元素的实际实现仍然存在——它们只是作为明确定义的低级抽象而存在。可以将本体视为一个略显复杂的单一仓库 (monorepo)，它强制执行某些约定，从而实现更可组合的系统：虽然本体当然有可能被滥用，最终导致同样程度的碎片化，但本体强制执行的封装模式旨在防止这种情况发生。

⁴ At a fundamental level, while humans interact directly with the physical world and indirectly with digital systems, AI systems interact directly with digital systems and indirectly with the physical world. As a result, the vast apparatus of logic designed for serializing and deserializing information between an abstract conceptual representation and the physical representations used by I/O devices like monitors, speakers, microphones, mice and keyboards is designed to create an interface optimized for humans; it is not necessary for building interfaces that serve AI systems, and we should expect that at the limit these systems should be able to interact directly with the abstract representation at scales that are effectively unimaginable to us at this point.
⁴ 从根本上讲，人类直接与物理世界交互，间接与数字系统交互，而人工智能系统则直接与数字系统交互，间接与物理世界交互。因此，用于在抽象概念表征与显示器、扬声器、麦克风、鼠标和键盘等 I/O 设备所使用的物理表征之间进行信息序列化和反序列化的庞大逻辑装置，旨在创建针对人类优化的界面；而构建服务于人工智能系统的界面则并非必需，我们应该预期，在极限情况下，这些系统应该能够以我们目前无法想象的规模直接与抽象表征交互。