文献导读，条目仍以 sources.json 为准

文献目录（已核验首批）

文献目录（已核验首批）

核验日期：2026-11-15（Asia/Shanghai）。共 17 条。完整机器可读字段见 sources.json。访问失败与探测 404 见 ../_backup/research/logs/access-log-2026-11-15.md。

本目录区分四类来源，不可混读：

• 官方厂商能力描述：说明产品能做什么，不等于某客户已经获得经营效果。
• 论文：有方法、证据范围和作者自限。
• 标准：有规范语义，但是 Semantic Web / 描述逻辑传统，不是 Palantir 原生技术。
• 本地作者推演：在概念笔记与微实验中，用虚构制造案例说明用法，不是文献事实。

公开网页与论文全文不在此镜像或再发布。

Palantir 官方文档

论文

标准

文献之间需要分开的冲突与口径

1. 运营层 vs 语义层。 平台摘要写 “Ontology is not a semantic layer”；总览页又明确列出语义要素（对象、属性、关系）和动力学要素。更准确的读法是：它不只是报表用的语义层，还要把逻辑、动作和安全做成可运行机制。不是“完全没有语义”。
2. 数据集类比。 Core concepts 用“一张表对一个对象类型”作入门类比；平台摘要与对象类型页写 backing datasource(s)，也可以没有 backing datasource、只由动作创建对象。类比不是强制架构。
3. 权限模型。 Core concepts 仍写 Roles 是中心权限模型；安全总览区分强制控制与自主控制，并存在遗留权限文档。学习时视为文档演进中的不一致，不要写成已经冻结的最终模型。
4. 动作提交 vs 跨系统一致。 动作总览强调提交后在应用中可见；冲突与 webhook 页说明并发冲突、数据源更新、不可幂等重试和外部调用失败。不存在文档保证的通用回滚。
5. 三种“血缘”。 Why Ontology 的决策血缘、Data Lineage 的管道血缘、Workflow Lineage 的执行追踪，不是同一件事。
6. 函数是否确定。 函数可写确定性计算，也可以调用模型或外部系统。不能默认“函数=可靠规则”。
7. 概念库存 vs 产品 Ontology。 2023 论文报告的是产品概念治理；Foundry Ontology 是可运行的对象、动作与权限层。论文里概念库存是建在内部 Foundry 上的，二者有实践联系，但问题不同，不能互相代替。
8. OWL / OBDA / 知识图谱 vs Palantir Ontology。 前三者来自开放标准与学术传统，主要处理形式语义、查询重写或图数据集成；后者把动作和安全做成运营系统。可对照，不可混名。
9. 官方能力 vs 经营效果。 文档与市场表述不能当作客户成效证据。论文作者已写明早期经验尚不足以给出确定性结论。
10. 云上大模型连接。 AIP、Ontology MCP、函数代理商业模型，是产品能力。若处理客户/员工个人信息、工单原文或设备序列号，直接接入云模型（脱敏也不行）不符合本用户边界，不能推荐。

未列入首批的材料

• Palantir 博客 OSDK 文章：本环境 403。
• palantirfoundation.org 镜像：可打开，但权属未核，不用作规范出处。
• Palantir Learning 课程与需登录的租户页面：未核验全文。
• 与本主题弱相关或重复的综述、教材（如 kgbook.org 与 Hogan 综述不是同一文献，故未另占一条）。