Ontology Governance | Building a Robust Ontology

频道: Palantir
视频: https://www.youtube.com/watch?v=mzBDupsPPcs
原文语言: en
统计: 共 30 轮

[0:00]

Hi, I'm Chad Wahlquist, I'm an architect at Palantir. Today I have Jonas, who's a forward deployed engineer at Palantir. Spends a lot of time, like I do, talking to customers about the ontology, how to model it, right? People think about what is this new thing? Do I shove my data warehouse into the ontology? Like, do I take my system tables? What do I need to do to model this and really govern it, right? So thank you for joining me today.Talk about this today.Hi, looking forward to talk about the ontology now.Yeah, so I think maybe I'll help set the frame of what we think about, like, when I talk about the ontology, it's like, how do I model the real world, how it actually exists? How do I model your business in the terms and the nouns and verbs of how it's actually operating, not how you need to put it in a data warehouse for some sort of reporting tool to work on it for some system scale? Really, the ontology in the Palantir ontology, the goal is to model how the real world works, which meansit's kind of weird compared to what people are used to. And so I think this is a topic we get all the time. So I'm glad that we're going to get to kind of demystify this both on the proper way to do things, but also some of the anti-patterns that we see through all of our experience.

Chad： 大家好，我是 Chad Wahlquist，Palantir 的架构师。今天请来的是 Jonas，他是 Palantir 的 forward deployed engineer（FDE，前置部署工程师），和我一样，花大量时间跟客户聊本体（Ontology）、聊怎么给它建模，对吧？大家会想：这个新东西到底是什么？我是不是该把数据仓库一股脑塞进本体？是不是把系统表直接搬过来？我要怎么做才能把它建模好、真正治理好，对吧？所以谢谢你今天来，一起聊聊这个话题。Jonas： 大家好，很期待今天来聊聊本体。Chad： 好，那我先帮大家把讨论的框架定一下，说说我们是怎么想的。我说到本体的时候，想的其实是：怎么按真实世界实际存在的样子去给它建模？怎么用你的业务真实运转时所用的那套术语、那些名词和动词去给你的业务建模——而不是为了让某种报表工具能处理、为了适配某种系统规模，把它塞进数据仓库时的那种样子？说到底，Palantir 本体的目标就是对真实世界的运转方式建模，这也意味着，它跟大家习惯的那一套比起来会显得有点怪。所以我觉得这是个我们一直被问到的话题。很高兴今天能把它讲清楚、揭开它的神秘面纱——既讲正确的做法，也讲讲我们在过往大量实践中见过的一些反模式（anti-pattern）。

[1:11]

Yeah, absolutely. And yeah, we came up with these design principles and anti-patterns. They are grounded in the theory of software engineering, but then also from what we've experienced in the field and what works in reality, what works for the business to drive a lot of value for the business.And but also for the teams that maintain the ontology and these best practices, they help a lot building a robust ontology and making it future proof.Yeah. Well, why don't we just jump into kind of starting with this? I know we put out we updated some new docs. We'll put a link out there for people to look at that.But as we go through here, maybe you can just kind of give me the high level on what you think about and how you break down the ontology design.Yeah, absolutely. So we basically we have these four fundamental best practice patterns, which is the domain driven design. Don't repeat yourself. Open, close principle and composition of our deep hierarchies.And let's start with the first one, domain driven design. So we if we take a look at the graphic here, you will basically want to model it in three steps before actually building something.You want to think and understand the domain that you're working with. Then you want to design the ontology, the object types, the links between them and the actions on these objects.

Jonas： 对，没错。我们总结出了这样一套设计原则和反模式。它们植根于软件工程理论，同时也来自我们在一线的实际经验——现实中什么管用，什么对业务管用、能给业务带来大量价值。另外，对维护本体的团队来说也一样，这些最佳实践对构建一个健壮的本体、让它经得起未来的考验，帮助非常大。Chad： 好。那我们干脆直接开讲吧？我知道我们发布了——应该说更新了一批新文档，我们会把链接放出来，方便大家去看。不过在往下讲的过程中，你能不能先给我讲讲大框架：你是怎么思考的，又是怎么拆解本体设计的？Jonas： 好，没问题。我们基本上有四条最根本的最佳实践模式：领域驱动设计（domain-driven design）、不要重复自己（Don't Repeat Yourself）、开闭原则（open/closed principle），以及组合优于深层级（composition over deep hierarchies）。我们先从第一条——领域驱动设计说起。看这张图，在真正动手构建任何东西之前，你基本上要分三步来建模。首先，你要思考并理解你所面对的业务领域。然后设计本体：object type（对象类型）、它们之间的 link（链接），以及作用在这些对象上的 action（动作）。

[2:36]

And then finally, map your source data and your logic to that ontology. So fundamentally, with that principle, you model the reality and you're not just replicating something that some other software is pushing you into.Yeah.And let's take a look at an example for this principle. So when we take a look here, we might have as an example here, have a table in our source system called order data.And if we just model that one to one into our ontology, then we would have a lot of different entities in there in that order data. You could have customer names and emails. You could have technical properties from saying here in this example, CM extracted at CM batch ID does not really have any business value.And this would, if you do it like that, would introduce anti-patterns. So one of that is what we call the got object. And it just pollutes your object type with team specific or technical properties.And then on top of that, the object type also represents multiple distinct entities.And then next to that, we also have the kitchen sink anti-pattern where you just map all source columns one to one into your object type, even though they're not really needed.And what that does is someone working on that object type, looking at these properties, maybe wants to do some changes or use it in a workshop application or any other front end.

最后，再把你的源数据和逻辑映射到这个本体上。所以从根本上说，遵循这条原则，你是在给现实建模，而不只是照搬别的软件逼你采用的那套结构。嗯。我们来看一个体现这条原则的例子。看这里，比如说，我们的源系统里可能有一张叫 order data 的表。如果我们把它一比一直接建进本体，这张 order data 里就会混着很多不同的实体：可能有客户姓名和邮箱，也可能有一些技术性的 property（属性）——比如这个例子里的 CM extracted at、CM batch ID，其实没什么业务价值。要是这么做，就会引入反模式。其中一种就是我们说的 God object（上帝对象）：它会用某个团队专属的或技术性的 property 污染你的 object type。更糟的是，这个 object type 还同时代表着好几个截然不同的实体。除此之外，还有 kitchen sink（大杂烩）反模式：把源表的所有列一比一全都映射进 object type，哪怕其实并不需要。这样做带来的问题是：有人在基于这个 object type 做东西，看着这些 property，也许想做些改动，或者想把它用到 Workshop 应用或其他前端里。

[4:15]

They are understanding the object type, they get confused, like, do I really need this? What does this actually mean?And by keeping the object types focused and actually representing different real world entities, it's way easier to understand for business people, but also for technical builders.And it's an important point though, too, is like when we think about the ontology, this is for how our humans are actually talking, not necessarily how your developers are building reports.Like what I want the ontology is how the business actually operates and talks about these terms.But also there's like weird stuff I've seen, like the batch ID and these other things.There's like these technical flags and components that are in these objects that often we find kind of get ported in rather than the function or what people are trying to go do with these things.And so it creates a constant friction that I'm having to translate back and forth for my business users because I'm talking in a different language, right?

他们在理解这个 object type 时就会犯迷糊：这个我真的需要吗？它到底是什么意思？而让 object type 保持聚焦、真正对应现实世界里各不相同的实体，无论是业务人员还是技术开发者，理解起来都会容易得多。Chad： 这一点也很重要：我们思考本体的时候，它对应的是我们人实际上怎么交流，而不一定是你的开发人员怎么做报表。我希望本体体现的，是业务实际怎么运转、怎么谈论这些概念。另外，我也见过一些很怪的东西，比如 batch ID 之类的。这些对象里有各种技术性的标记和组件，我们发现它们常常是被原样搬了进来，而不是体现这些东西的功能、或者大家到底想拿它们去做什么。于是就会产生持续不断的摩擦：我得不停地给业务用户来回翻译，因为我说的是另一种语言，对吧？

[5:11]

Yeah, exactly. Then people start talking about the same things.And it's ultimately the power of the ontology that everyone works out from the same base.Yeah. So what does this look like done right?Yeah, let's take a look at that.So rather than just having order data, we want to take a look on the domain.And if I work with orders, OK, I need to order itself.I'm interested about the customer and I'm interested in the product of that order.And so I would say, OK, I have three different object types here, which is the order, the customer and the product.And then also identify from the source data, OK, what are the properties that are needed for these different object types and how do they relate to each other?

Jonas： 对，完全正确。这样大家说的才是同一件事。说到底，本体的威力就在于每个人都从同一个基础出发。Chad： 嗯。那做对了是什么样子？Jonas： 好，我们来看一下。与其只有一张 order data 表，我们要先去看业务领域。如果我处理的是订单，好，那我需要订单本身；我关心这笔订单的客户，也关心它的产品。所以我会说，好，这里有三个不同的 object type：订单（Order）、客户（Customer）和产品（Product）。然后再从源数据里梳理清楚：这几个 object type 各自需要哪些 property，彼此之间又是什么关系？

[5:55]

And first, by modeling these things together, it's easier for people to understand looking at these object types and using the links and seeing the relationships between that.And then also future workflows can really benefit from these different entities because they can build on top of that.And if you maybe have a customer support kind of workflow that comes after this order workflow, you can just bolt it onto the customer and then really have that understanding.Don't have a high lift of remodeling your ontology just because you want to have another use case.Ultimately, that means once you build it right with the best design principles, the ontology also compounds more easily.And it's quicker to build future workflows and more robust.Yeah. And I think it's like for this here, this reminds me very much of like dimensional modeling, which can be kind of a trap here.Right. So like, you know, if I have a dimensional data warehouse, this might the order might be a fact table and the customer product might be dimensions.And so it's very tempting to just show dimensional data warehouse tables straight into ontology objects, which can work in some scenarios.But you start to get more complicated into these relationships across different measures and domains and other things as you.

首先，把这些东西放在一起建模之后，大家看着这些 object type、顺着 link 看到它们之间的关系，理解起来就更容易。其次，未来的工作流也能真正从这些不同的实体中受益，因为它们可以直接在此基础上构建。比如在这个订单工作流之后，也许又来了一个客户支持类的工作流，你直接把它挂到 Customer 上，就能真正把情况掌握清楚，不用仅仅因为想加一个用例，就大费周章地重新建模你的本体。说到底，这意味着一旦你按最好的设计原则把它搭对了，本体也更容易产生复利效应，搭建未来的工作流也更快、更稳健。Chad： 嗯。我觉得就这个例子来说，它让我强烈联想到维度建模（dimensional modeling），而这在这里可能算是个陷阱。对。比如说，如果我有一个维度数仓，那这里的订单可能就是事实表，客户和产品可能就是维度。所以人们很容易想把维度数仓里的表直接硬塞成本体对象，这在某些场景下确实行得通。但一旦涉及跨不同度量、不同领域等等的这些关系，事情就开始变复杂了，随着你……

[7:16]

And that becomes a bottleneck because I've modeled stuff in these weird domains that don't necessarily cross over nicely.And so I think this is where like, you know, a very simple example, this makes a lot of sense, but it can be very similar to a dimensional data warehouse in this case.Right.Yes. Yeah. Yeah. Yeah. Ultimately, with that modeling, it allows everyone to really work on that same ontology together.Yeah. And because I might have very complex, like we're showing many to one relationships here, but I might have many to many across different measures or at different granularities.And so traditionally, like we account for those in very kind of static or predefined ways.And I think the goal of the ontology here is actually let's just model all of those complexities and allow for the ontology to manage the scaling and performance and security and other components to be able to work across those kind of conjoined domains.Because the goal is to create that visual twin across your entire business process. Right.Right. Right. Yeah.So, okay, cool. I like this. So the domain driven design, really think about how the real world works. What's the next? What's the next one?

而这就成了瓶颈，因为我是在一些别扭的领域划分里建的模，这些领域之间不一定能顺畅地打通。所以我觉得，在这种非常简单的例子里，这样做很合理，但这种情况下它可能跟维度数仓非常像。对吧。Jonas： 是的，对，对，对。说到底，这样建模能让所有人真正在同一个本体上协同工作。Chad： 嗯。而且我可能会遇到非常复杂的情况——我们这里展示的是多对一关系，但我可能会有跨不同度量、或者不同粒度的多对多关系。传统上，我们是用非常静态、或者说预先定义好的方式来处理这些情况的。而我觉得本体在这里的目标其实是：干脆把所有这些复杂性都建模出来，让本体来负责扩展、性能、安全等等方面，从而能跨这些相互交织的领域运转。因为目标是在你的整个业务流程上构建起那个数字孪生（digital twin），对吧。Jonas： 对，对，没错。Chad： 好，挺好，我喜欢这个。所以领域驱动设计，就是要真正去想现实世界是怎么运转的。下一条是什么？下一条是？

[8:23]

Okay. Yeah. Let's take a look. The next one is don't repeat yourself.And so if we look at that, the basic principle is here. If you did something three times, let's say you have a very similar object type or almost the same three times and you want to refactor that.But you can you should also take that in mind when you start modeling the ontology and building in the ontology.So in this example, if we take a look at the left, we have three object types.One is a sales customer. One is a support customer. One is a billing customer.And that all seems to be basically the same. And okay, in reality, this can might happen.You start with a sales use case and then a support use case and maybe at some point a billing use case.But keep in mind when you maybe start with the sales use case, you don't want to have a sales customer.You want to just start with the customer and keep in mind that in the future, there might be additional use cases or additional teams working on your ontology object customer.In reality, in a business, multiple teams, multiple departments work with a customer entity.And so the problems that are being introduced here is they all have the same properties and someone needs to maintain that.

Jonas： 好，行，我们来看一下。下一条是「不要重复自己」。我们来看看，这里的基本原则是：同样的事如果你做了三遍——比如说你有三个非常相似、甚至几乎一模一样的 object type——那你就该重构了。不过，在你刚开始建模本体、在本体里构建东西的时候，就应该把这一点记在心上。在这个例子里，看左边，我们有三个 object type：一个是销售客户（sales customer），一个是支持客户（support customer），一个是计费客户（billing customer）。它们看起来基本上是一回事。当然，现实中确实可能出现这种情况：你先做了一个销售用例，接着是支持用例，也许某个时候又来了一个计费用例。但要记住，当你从销售用例起步时，你不该建一个「销售客户」，而是应该直接从「客户」开始，同时要想到，将来可能会有更多用例、更多团队来使用你本体里的 Customer 对象。现实中，一家企业里会有多个团队、多个部门跟客户这个实体打交道。而这里引入的问题是：它们都有相同的 property，还得有人去维护。

[9:42]

And updating a name and one object and not doing it in the third object can cause problems because then at one side of the ontology, your data is stale.And instead, really model the customer object or if they are really different object types, because fundamentally in the business operations, you need a separate separation.Then you can also use an interface here, which allows you to just plug in an action that knows based on the interface.Okay, I have a name, email and the phone number and I can update it with one action, for example, and don't need three different actions for each individual object type.Yeah, which I think is an important point here is like, you know, if I have, because this is how we get to not one version of the truth where I have a sales customer support customer,which we see in data landscapes all the time.So I think it's the cool, how do I model this effectively?

在一个对象里改了姓名，却没在第三个对象里同步改，就会出问题，因为这样一来，本体某一侧的数据就过时了。所以更好的做法是，真正去建一个 Customer 对象；或者，如果它们确实是不同的 object type——因为在业务运营上，从根本上就需要把它们区分开——那你也可以在这里用 interface（接口），这样就能直接接入一个基于这个 interface 来运作的 action：好，我有姓名、邮箱和电话号码，比如说用一个 action 就能完成更新，而不需要给每个 object type 各做一个、总共三个不同的 action。Chad： 对，我觉得这是很重要的一点，就是说，你知道，如果我有……因为正是这样，我们才落得没有「单一事实版本」的局面——我有销售客户、支持客户，这种情况在各家的数据版图里随处可见。所以我觉得关键就在于：好，我到底该怎么有效地建模？

[10:40]

So the single customer or the interface approach gives us that singular kind of version of the truth,but also the interoperability to allow me to work on different use cases by using interfaces or other ways to manage all the different components of it.So that I still have that one object that everyone builds off.I think this comes back to the global view of the ontology is it should be universal across the whole company.Yeah.Yeah.Yeah.Let's take a look deeper into that.Yeah.So yeah, basically if you don't adhere to the design best practice, what could happen?

所以，单一 Customer 对象或者 interface 的做法，既能给我们那种单一的事实版本，又能带来互操作性，让我可以借助 interface 或其他方式管理它的各个组成部分，去支撑不同的用例。这样我始终只有那一个对象，大家都在它的基础上构建。我觉得这又回到了本体的全局视角：它应该是全公司通用的。Jonas： 对，对，对。我们再深入看看。嗯，所以基本上，如果不遵循这些设计最佳实践，会出现什么情况？

[11:20]

And there's a few anti patterns that could be established here.So for example, if you go into sales support and billing customer each, then you would establish department silos.Of course, in your sales department, your maybe your CSS team and your billing team, they all operate on in their own world.And one, if they need to collaborate on something, being in these silos causes problems because they might look at a case from a customer, but then have different conflicting information about that customer because it was established in these silos.And then the same could be another anti pattern, which we could call the system silos.And for that one, it's just like mapping the entity, how it is in the sewer system, almost one to one.And then you just replicate your silo that you have in your existing landscape and not let the different systems like a CRM system, a helpless system or an ERP system talk to each other.And where the ontology is really good at integrating and breaking down these silos from existing landscapes.Yeah, I think the important piece there, too, is like, you know, most of our customers have N number of, you know, ERPs, for example.And we have customers that have 70 or hundreds or 150 different ERP systems alone, all with customer.

这里可能会形成几种反模式。比如说，如果你分别建了销售、支持和计费三种客户，就会形成部门孤岛（department silos）。毕竟你的销售部门、也许还有你的 CSS 团队和计费团队，都各自活在自己的世界里。一旦他们需要在某件事上协作，身处这些孤岛就会出问题：他们可能在看某个客户的一个 case，手里关于这个客户的信息却各不相同、甚至互相矛盾，因为这些信息是在各自的孤岛里建立起来的。同样，还有另一种反模式，我们可以称之为系统孤岛（system silos）。这种情况就是把实体按它在源系统里的样子，几乎一比一地映射过来。这样你只是把现有系统版图里的孤岛原样复制了一遍，并没有让 CRM 系统、helpdesk 系统、ERP 系统这些不同的系统彼此打通。而本体恰恰非常擅长做集成，打破现有系统版图里的这些孤岛。Chad： 对，我觉得这里还有一个重要的点，就是，你知道，我们大多数客户都有 N 套 ERP，举个例子。我们有的客户光 ERP 系统就有 70 套、上百套，甚至 150 套，每一套里都有客户。

[12:48]

Like, it would not be a very scalable approach or wouldn't be very useful to have a customer for each single one.And I think that how do I create this unified view, but then also be able to write back because that's the other piece of this is the bidirectional component where I need to be able to understand where did this, what system does this come from, which region, which area or which business unit this ERP is.So it's like I need to be able to combine, but understand the lineage and provenance of those things to be able to make it actionable, right?

要是每个 ERP 都单独建一个客户对象，这种做法既没法规模化，也没多大用处。所以我觉得关键在于：怎么建立起这个统一视图，同时还能回写（write back）。因为另一块就是双向这一环——我得能搞清楚这条数据是从哪儿来的、来自哪个系统、这个 ERP 属于哪个地区、哪个区域、哪个业务单元。也就是说，我既要能把它们合并起来，又得清楚这些数据的血缘（lineage）和出处（provenance），这样数据才能真正驱动行动（actionable），对吧？

[13:14]

Yes, absolutely.And then even thinking about the actions where you mentioned actionable, there we also have some anti-patterns.So if you have these three different object types all representing a customer and you need actions to update the properties like name, email and phone,then you on each individual object type, you need to have either one action or three actions.However, it is needed to update it.And that just is a multiplier of the resources that are getting built for that.And that actually also introduces anti-patterns, which we call action sprawl.So there are two angles here.One is, okay, you have actions duplicated across the same entities just because these entities are duplicated, these object types.And the other part is, which we see here in this example is, you don't want to have an action that updates individual properties like name and then another one for email and another one for phone.You would want to have one that updates maybe all three to say like update my customer contact information.And then the next one, which we can also see in this example is what we call the golden hammer hunting pattern.And this is, comes from the saying, if everything you have is a hammer, then everything looks like a nail.

Jonas： 对，完全同意。说到你刚才提的 actionable，在 action 这块我们也有一些反模式。假设你有三个不同的 object type，都代表客户，而你需要 action 去更新姓名、邮箱、电话这些 property，那每个 object type 上都得有一个或者三个 action，看你具体要怎么更新。这就让要建的资源成倍增加。而且这其实还会引出一个我们称为「action 泛滥」（action sprawl）的反模式。这里有两个角度。一是同样的实体上，action 被重复建了好几份，仅仅因为这些实体——也就是这些 object type——本身就是重复的。另一个角度，就是这个例子里能看到的：你不会想要一个 action 只更新姓名，再来一个更新邮箱，再来一个更新电话。你会想要一个 action 把三个一起更新，比如叫「更新客户联系信息」。然后这个例子里还能看到下一个反模式，我们管它叫「金锤子」（golden hammer）反模式。这个说法出自那句老话：手里只有锤子，看什么都像钉子。

[14:40]

And in this example is maybe you don't want to have an action actually to update the contact information because they don't change it frequently and it's maintained or the source is in the source system.So you might want to take a pipeline that feeds into it and not an action that you need to execute whenever something changes.There are other properties maybe in this for a customer where you want to update the properties.Yeah.I think that this is the important part because a lot of people think about modeling as data modeling, but like we're modeling a business process, the data, the logic,the action.So this action piece is really important because not only for the human piece, but as we talk about agentic world, like I need the agents to be able to understand the right level.And how do I actually go make things happen?

放在这个例子里，你可能其实根本不该用 action 去更新联系信息，因为这些信息不常变，而且是在源系统里维护的，源头就在源系统。所以更合适的可能是用一条 pipeline 把数据灌进来，而不是每次有变化都得去执行一次 action。客户身上可能还有别的一些 property，那些才是你想用 action 去更新的。Chad： 对。我觉得这点很重要，因为很多人一想到建模就以为是数据建模，但我们建模的其实是业务流程：数据、逻辑，还有 action。所以 action 这块非常重要，不光是为了人这一侧；我们现在谈 agentic 的世界，我也需要 agent 能在恰当的层面上去理解。还有，我到底要怎么真正把事办成？

[15:34]

So that's also the importance here of these actions and, and in getting this right and mapped correctly is like, I have to think about, well, how do act, how do agents, you know, work in this environment, in the ontology alongside humans?

所以这也是这些 action 的重要性所在。要把它做对、映射对，我就得去想：agent 在这个环境里、在本体里，到底怎么跟人类并肩工作？

[15:47]

Like I have to have these actions that make sense so they can go do things for me.Yes, yes, exactly.And then also when you want to drive decisions, um, uh, for people understanding what do these actions do, um, can't saying, okay, update customer contact information.Let's move a little bit to the right.How good looks like here.Um, for this, um, you know, what contact, everyone knows what contact information is and so on.And then just having actions that go into one single property and maybe then even the property in some cases has, uh, some, uh, cryptic name.Um, then, uh, it's better to give it a real good description.So everyone knows what this does and it's easily understandable.Yep.And so having this interface here, for example, allows me to implement customer across those different interfaces for the sales, a support or billing.So it gives me that flexibility while still having that standard view of what a customer is, but now it can be implemented in different ways.So this is come, this is important when we want high reuse across the ontology, which is really the compounding asset.You know, this, this is how we get the most value out of the ontology is by not repeat ourselves.

就是说，我得有这些说得通的 action，agent 才能替我去干活。Jonas： 对，对，正是这样。另外，当你想驱动决策时，要让人明白这些 action 是干什么的，直接叫「更新客户联系信息」就很清楚。我们往右边看一点，看看好的做法长什么样。像这里，联系信息是什么，大家都懂。而如果 action 只改某一个 property，有时那个 property 的名字还挺晦涩，那最好给它写一段真正清楚的描述，让大家都知道它是干什么的，一看就懂。Chad： 嗯。比如这里用上 interface，我就能让销售、支持、计费这几块各自去实现「客户」。这样既有灵活性，又保留了「客户是什么」的统一标准视图，只是现在可以用不同的方式来实现。当我们想在整个本体里做到高复用时，这点就很重要，而本体正是会产生复利的资产。你知道，要从本体里拿到最大价值，靠的就是不重复自己。

[16:59]

So we can have high reuse so that the next use case is just additive.Yes.Yep.Yeah, absolutely.And I think one thing to mention that's important here as well is, um, if we decide to use the interface because, uh, the workflows around these objects are fundamentally different.And, uh, and move from sales, customer support, customer and billing customer, uh, to an interface, then it should be probably something like it's, uh, the object should be a sales lead or a support contact or a billing account.Um, and then separately also have a customer object, um, that can be linked to that.And, um, uh, because that describes more what the purpose of that is for the workflow.Yeah.Yeah.Very good.I think that's, that's a good, rich kind of, uh, feedback loop of like how you start to actually have to decomp these things, how the real world's actually working in the, in this stuff.So that's great.Cool.All right.So we kind of see what good looks like.What's the next pattern?

这样就能高复用，下一个用例只需要往上做加法。Jonas： 对，没错，完全同意。我觉得这里还有一点值得一提：如果我们因为围绕这些对象的工作流根本不同而决定用 interface，把销售客户、支持客户、计费客户改成 interface 的形式，那这些对象大概应该叫销售线索（sales lead）、支持联系人（support contact）或者计费账户（billing account）之类的，然后再另外建一个客户对象，可以跟它们链接起来。因为这样更能说明它在工作流里的用途。Chad： 对，对，很好。我觉得这是一个很好、很丰富的反馈回路，能看出你得怎么真正把这些东西拆解开，看清现实世界在这里面究竟是怎么运转的。这很棒。好，那我们大致看到好的做法长什么样了。下一个模式是什么？

[17:59]

Yeah.So the next one is the open close principle.And, um, what it basically says is, uh, open for extension and, uh, closed for modification.And now specifically for the ontology here, uh, we have the, um, first the ability, what we see in the graphic is to make object types.Um, when you create object types, they're experimental and then you can make them active once they are ready for production.And then, um, um, it's, uh, it's, uh, it's a flag inside of the ontology that, um, shows, okay, this object type is now being used, um, uh, in a production environment.And gives a signal to developers, okay, I have to be, um, careful here.I cannot just change things just like that.And that plays together with the, um, closed for modification principle where you say, okay, I already have something and it should be designed that, um, there should not be much change with an object type that is active.And we can take a look at the example here.So we would have, uh, an equipment object.And then we now have a new use case where we see, say, okay, we now need to certify our equipment.And instead of just saying, okay, I take, um, uh, the certification, uh, information and just, uh, put it onto the equipment object as new properties.

Jonas： 好。下一个是开闭原则（open-closed principle），它的基本意思是：对扩展开放，对修改关闭。具体到本体上，首先是图里能看到的这个能力：你新建 object type 时，它是 experimental（实验）状态，等准备好上生产了，就可以把它设成 active。这是本体里的一个标记，表示这个 object type 已经在生产环境里使用了，同时也给开发者一个信号：好，这里我得小心，不能说改就改。这就和「对修改关闭」这条原则配合上了：既然已经有了现成的东西，那设计时就应该让 active 状态的 object type 不需要太多改动。我们来看这里的例子。假设我们有一个设备（equipment）对象，现在来了个新用例，比如说，我们现在需要给设备做认证。而不是直接说：好，我把认证信息拿过来，当成新的 property 直接放到设备对象上。

[19:24]

Instead, I can link a new type to, uh, the equipment object and then use an interface here.And say, okay, all my different equipment or maybe other, even other object types.Um, uh, if we think about equipment, what could it be?

相反，我可以把一个新类型链接到设备对象上，然后在这里用一个 interface。也就是说：好，我所有不同的设备，或者别的，甚至其他 object type。我们想想，说到设备，它还可能是什么？

[19:39]

It could be a truck, for example, that also at some point needs certification.And then we have our model, our equipment certification object type and, uh, link it in the future.It can also be linked to a hypothetical truck object.And through the interface, I can design my, uh, actions, uh, my kinetics to, uh, then actually, uh, wield the certifications.And drive the decisions for that.And, uh, instead of, uh, making changes in existing in production, closed, uh, object type.Yeah.And so the, the, really the concept here is like, I wanted to be additive to the component and I want, I want to be able to like extend and, um, build on this with new object types of the components.But in order if, you know, like, yes, we have global branching, we have all these kind of safeguards and change management in place.But still, if I go remove, uh, an indicator or a field out of an ontology type that will have ripple effects, you know, so yes, you could do that, but it's gonna be very expensive, uh, from a time and, you know, overhead standpoint.But really it comes back to, I want to extend it and then have these new capabilities are very additive.So I'm allowing people to then uptake new capabilities as I'm adding it rather than I'm breaking everything on existing production objects.

比如可以是一辆卡车，它在某个时候也需要认证。这样我们就有了自己的模型，也就是设备认证（equipment certification）这个 object type，将来再把它链接过去——它也可以链接到一个假想的卡车对象上。通过这个 interface，我就能设计我的 action，也就是我的 kinetics，去真正处理这些认证，并据此驱动相关决策。而不是去改动一个已经在生产环境里、已经「关闭」的 object type。Chad： 对。所以这里真正的理念是：我想对组件做加法，我希望能用新的 object type 去扩展、在它的基础上继续搭建。当然，我们有 global branching，有各种安全护栏和变更管理机制。但即便如此，如果我从本体的某个类型里删掉一个指标或者字段，还是会产生连锁反应。所以没错，你可以这么干，但无论从时间还是额外开销来看，代价都会非常高。说到底还是回到这点：我想做的是扩展，让这些新能力都以加法的方式叠上去。这样随着我不断加入新能力，大家可以逐步用起来，而不是我把现有生产对象上的一切都搞坏。

[20:53]

Yeah, exactly.Exactly.Yeah.And if we then also take a look, um, a little bit deeper into that, um, we can also see if you don't do that and you, um, so-called overload, uh, your object type with multiple end, uh, entities.We come back into this, uh, got object anti pattern.And, um, where suddenly we, we had an equipment and it represents a piece of equipment.And then the more use cases, uh, the more you extend, uh, the ontology and then add information to an individual object.We, we get this overloaded, uh, big object type and at some point, and here we can, it ties back to our first principle to think about domain driven design here again, um, to really keep everything focused and easily understandable.And links and interfaces help you with that a lot.Yeah.Uh, I mean, it's funny cause a lot of these principles are, are very similar to, um, object oriented principles, right?

Jonas： 对，没错，就是这样。如果我们再往深里看一点，也能看到：如果你不这么做，而是往 object type 里塞进多个实体——也就是所谓的「过载」——就又回到了上帝对象（God object）这个反模式。本来我们有一个设备对象，它代表的就是一台设备。可随着用例越来越多、你对本体扩展得越来越多、往单个对象上加的信息越来越多，我们就会得到一个过载的大 object type。到了某个地步——这里又跟我们的第一条原则挂上钩了——还是要回到领域驱动设计来思考，让一切真正保持聚焦、易于理解。link 和 interface 在这方面能帮上大忙。Chad： 对。说起来挺有意思的，这些原则里有很多都跟面向对象的原则非常像，对吧？

[21:55]

So, uh, you know, uh, software engineering.So this is really like, there's an amalgamation here where I see kind of the dimensional data warehousing stuff.I see object oriented.And really, I think that ontology driven design principles are, are kind of in the middle point, a middle here where I'm trying to not only design.I'd design the data and structure of how the real world works, but I'm also having to design the methods and classes of, of what I'm trying to go do in my objects around actions and other components, and then make it reusable and sustainable across.Um, across them.So it's, it is really this kind of middle ground between object oriented and data warehousing, um, that we hit with the ontology driven design.Yeah.Yeah, exactly.Yeah.Yeah.All right.So this, this really like helps me think through how I'm building the object types, the interfaces, when to break things apart, when to reuse.Um, I think it's very common.We see where it's like the God object type is, is a funny one.I laugh about that cause I've seen it so often where it's just, I'm piling new stuff in cause it's the easiest way to get something in.Then it becomes unsustainable.Um, very, very quickly.So cool.

也就是软件工程那一套。所以这里其实是一种融合：我能看到维度建模数据仓库那套东西，也能看到面向对象。我真心觉得，本体驱动设计的原则差不多就落在两者中间：我不只是在设计——我要设计现实世界如何运转的数据和结构，同时还得围绕 action 和其他组件，为我想在对象上做的事去设计方法和类，然后让它们在各处都能复用、可持续。所以本体驱动设计找到的，确实就是面向对象和数据仓库之间的这块中间地带。Jonas： 对，没错。Chad： 好。这真的帮我理清了该怎么建 object type 和 interface，什么时候该拆开，什么时候该复用。我觉得这种情况很常见。上帝对象这种 object type 就挺好笑的，我每次聊到都忍不住笑，因为实在见得太多了：就是不停往里堆新东西，因为这是把东西加进去最省事的办法。结果很快，非常快，就变得难以为继。挺好。

[23:00]

Yes.Right.So what is it?All right.So the last one, that's a composition of our, uh, deep hierarchies and, um, maybe quickly deep hierarchies.It could be multiple different object types, uh, that are linked to each other, but in reality, um, are kind of this, uh, parent child relationships that's on a very long chain.Um, and so that could be, for example, here, um, we have fear, uh, in the graphic and object type arena, office building and restaurant.And above that could be a building entity.Um, and above that, um, could be other entities, uh, in kind of this parent child chain.And rather than having this long chain.And, uh, then in reality needing to traverse a lot of links.Um, and if you want to make changes, you probably at some point need to make changes to the whole chain.And we look, we'll look a little bit deeper, uh, into an example there, but, uh, you want to use interfaces here.And, um, let's say, um, you have, uh, your different, uh, building object types and, uh, you want to be able to, um, schedule, um, that kind of building.And, uh, the behavior can be a little bit different depending on the building.So if we look at an arena, um, it's maybe you want to schedule it for events.

是的。对。那下一个是什么？Jonas： 好，最后一个是「组合优于深层级」（composition over deep hierarchies）。先快速讲讲什么是深层级。它可能是多个互相链接的 object type，但实际上构成的是一种父子关系，而且这条链非常长。比如图里这个例子，我们有场馆（Arena）、办公楼（Office Building）和餐厅（Restaurant）这几个 object type。它们上面可能还有一个建筑（Building）实体，再往上，这条父子链上还可能有别的实体。与其搞出这么一条长链——实际用的时候还得穿过一大堆 link，而且想改点什么，很可能迟早得把整条链都改一遍；待会儿我们会结合一个例子再深入看看——不如在这里用 interface。比如说，你有各种不同的建筑类 object type，希望能给这类建筑排期，而具体的排期行为会因建筑不同而略有差别。比如场馆，你可能是要给它排活动档期。

[24:19]

And, uh, that's something, uh, that needs to be scheduled for, for a day or two.And, uh, compared to an office building, um, which, uh, can also be scheduled.Um, but maybe on the lease period for a longer amount of time and all of these different entities, um, they share different properties.Um, so, but fundamentally they can inherit the same behavior.And the interface allows you to do that.And you don't need too many different actions to, um, to do that.Yeah.And so.Yeah.I was gonna say that.So this, this kind of.Also makes me think about just like our bill materials.Like something we do all the time in manufacturing space too.Is like, should I like actually explicitly lay out the bill of materials and the hierarchies of like to produce this product?

这种档期一般也就一两天。相比之下，办公楼也可以排期，但可能是按租期来，时间要长得多。这些不同的实体共享着各种 property，但从根本上说，它们可以继承同一套行为，interface 就能让你做到这一点，而且你不需要为此建太多不同的 action。Chad： 对。所以……对，我正想说呢。这多少也让我想到物料清单（bill of materials，BOM），这在制造业里也是我们一直在做的事。就是说，我到底该不该把物料清单、把生产这个产品所需的各级层级，全都明明白白地列出来？

[25:11]

Here's all the hierarchy of things in my bomb tree that I essentially need to build out.Um, or should I have an object that describes that, that allows me to actually explode that kind of bomb out and, um, use it across my, um, you know, in a non-predefined way.So like that composition piece makes a lot of sense versus, you know, predefined deep hierarchies that I have that are hard to manage updates and like use over time.So I think that starting to make sense to me as you're describing, this is like, if I try to predefine a hierarchy, like it's going to be out of date the second I publish it.And these composition and how I actually build out these object types allow me to actually be more flexible over time.Yeah. Yeah. That's exactly it.And I think here for the composition over the hierarchies, um, a very simple and a good example that we see here is all of these different, uh, building types that are in reality probably used differently.Um, share address and square footage, for example, as an example, um, with the building interface and that interface allows us to, um, use actions on all three.And we don't need to have a specific actions, uh, for all these three individual object types.

「这就是我 BOM 树里本质上需要搭建出来的全部层级。」还是说，我该用一个对象来描述它，让我能把这种 BOM 展开，然后在我的……你懂的，以一种不预先定义的方式去用？所以组合这一块就特别说得通；相比之下，我手里那些预先定义好的深层级，更新很难管理，长期用起来也费劲。听你这么一讲，我开始想明白了：如果我想预先定义一套层级，那它在我发布的那一刻就已经过时了。而靠组合、靠我实际搭建这些 object type 的方式，才能让我随着时间推移保持灵活。Jonas： 对，对，就是这样。我觉得在「组合优于层级」这一点上，这里有个很简单也很好的例子：这几种不同的建筑类型，实际用法大概各不相同，但它们通过 building interface 共享地址、面积这类 property；有了这个 interface，我们就能对这三种类型都使用 action，不需要为这三个 object type 各自配专门的 action。

[26:25]

We just need to have one that works with that interface.Yeah, no, that's very cool.I think that's, that's the, like, how do I govern and own this over time means I need to really take these into principles.Cause I mean, man, if you had separate actions and the sprawl of that would get out of control pretty quick, which I think is what people normally see in kind of the enterprise space.Absolutely.And then if we look a little bit deeper into that, um, we can also talk a little bit about the anti patterns that we have, um, in that area for the composition over, uh, hierarchies.And, uh, here in this example, okay, here we actually see, see this, uh, chain, this parent, uh, child relationship chain, and it could start with an item and the physical asset.It goes into a building, uh, then a schedulable building.And then ultimately we are at the object type, uh, the arena.And what we see here as, uh, uh, one anti pattern is what we call, uh, the misnomer.So, um, uh, so a physical asset or an item that's, um, they're just reading that, uh, I don't really know what it is.And, um, um, as it can be anything, it can be equipment.Uh, it can be inventory, uh, or it could be a building.So, uh, we wanna have good naming conventions here.

我们只需要一个作用于这个 interface 的 action 就行。Chad： 对，这个真的很酷。我觉得这就是那种——想要长期治理好、管好这套东西，就意味着我得真正把这些原则用起来。因为说真的，天哪，要是每个都单独建 action，这种泛滥很快就会失控，我觉得这也正是大家在企业里通常会看到的情况。Jonas： 完全同意。再往深里看一点，我们也可以聊聊「组合优于层级」这块会遇到的反模式。看这个例子，这里就是那条链，一条父子关系链：它可能从物品（Item）和实物资产（Physical Asset）开始，接着是建筑（Building），然后是可排期建筑（Schedulable Building），最后才到场馆（Arena）这个 object type。这里能看到的一个反模式，我们管它叫「命名失当」（misnomer）。比如「实物资产」或者「物品」，光读这个名字，我其实根本不知道它到底是什么，因为它可以是任何东西：可以是设备，可以是库存，也可以是一栋建筑。所以这里需要好的命名规范。

[27:47]

And actually in my opinion, the misnomer is one of the worst anti patterns because, um, people working with it, um, get a wrong understanding and need to gather a lot of information from other, um, colleagues in order to work with that object types.And on top of that, when we think about, um, agentic workflows, uh, and agents working with these object types, if the, the naming conventions are bad and descriptions are missing for properties or for the object types, then agents, um, don't have an understanding and, uh, make, uh, worse decisions.So building, uh, a nice agent, uh, on top of object types giving or helping building inside of the platform, for example, with our AI FTE, these descriptions, um, and, uh, naming everything right helps a lot, uh, in the production and gives the right context, which is one of the big ontology differentiators.Yeah.I think, especially when we talk about, you know, we talk about LMs plus the ontology is really where the magic is.Like how do I represent the real world, how it actually operates because these LMs were not trained on your enterprises data.Um, and so us representing the context about how things are actually operating is super important so that they can reason across it effectively.

其实在我看来，命名失当是最糟糕的反模式之一，因为用它的人会产生错误的理解，还得去找其他同事收集一大堆信息，才能用好这些 object type。更进一步，当我们考虑 agentic 工作流、考虑让 agent 去操作这些 object type 时，如果命名规范很差，property 或 object type 又缺少描述，agent 就没法理解，做出的决策也会更差。所以，无论是在 object type 之上搭一个好用的 agent，还是在平台内部协助构建——比如用我们的 AI FDE——这些描述、以及把所有东西都命名对，在生产中都大有帮助，能提供正确的上下文，而这正是本体的一大差异化优势。Chad： 对。我觉得尤其是——你知道，我们常说 LLM 加上本体，才是真正的魔力所在。也就是说，我要怎么把真实世界、把它实际的运转方式表达出来？因为这些 LLM 并不是拿你们企业的数据训练出来的。所以由我们把「事情实际是怎么运转的」这层上下文表达出来就极其重要，这样它们才能在此基础上有效地推理。

[29:05]

Versus I've created these pseudo system hierarchy languages so that a reporting structure can work that I can drill down in is not actually how the real world works.Um, right.And it's actually more convoluted.And so actually that will create a harder time for both humans and agents to get to it.Um, to the right answer verse, if I have a properly composed, like composition of, of hierarchies and relationships, um, then I can get to those answers and have agents understand and actually navigate the ontology, which is really the, the useful part is like, how do I make sure I ground the LM and the agent in the truth?

而不是我自己造出一套伪系统式的层级语言，只为了让一个能层层下钻的报表结构跑起来——那其实根本不是真实世界的运转方式，对吧。而且它实际上更绕，所以反而会让人和 agent 都更难拿到正确答案。反过来，如果我有一套恰当组合起来的层级和关系，我就能拿到这些答案，还能让 agent 理解本体、真正在本体里导航。这才是真正有用的部分：我要怎么确保 LLM 和 agent 是锚定在事实之上的？

[29:41]

Well, I need to represent the truth in the best way.And that's what I think we're talking about here.Yeah.Yeah, exactly.Very cool.So we've got four different design patterns.We've got a bunch of anti patterns, a bunch of, uh, kind of examples of what we're doing here.We've got some new docs.We just updated out on the website for everyone to go see as well.So we can put a link to those, um, out there and I'll probably also put a link to our ontology explainer out, but be honest, thank you for joining me today.This is awesome.I think this will be super helpful for, uh, everyone that asks, how do I model ontology?

那我就得用最好的方式把事实表达出来。我觉得这正是我们今天在聊的东西。Jonas： 对。对，没错。Chad： 很酷。所以我们讲了四种不同的设计模式、一堆反模式，还有不少我们具体怎么做的例子。我们还有一些新文档，刚在官网上更新了，大家也可以去看看。我们会把链接放出来，我可能还会放上我们那个本体讲解（ontology explainer）的链接。不过 Jonas，谢谢你今天来参加，这期太棒了。我觉得这对每一个来问「本体该怎么建模？」的人都会非常有帮助。

[30:13]

How do I govern it?Right.But here are just some primers for people to get started.No problem.It's great to talk about that.And the documentation is really great around that and, uh, helps a lot with understanding these.Yeah.There are also a lot of examples in there.Oh, great.That will be good for everybody.All right.Thanks again.Thank you.Thank you.

「又该怎么治理？」对吧。不过这些只是帮大家起步的一些入门材料。Jonas： 不客气，能聊这个话题很开心。而且这方面的文档写得非常好，对理解这些内容很有帮助。对，里面还有很多例子。Chad： 哦，太好了，这对大家都有好处。好，再次感谢。Jonas： 谢谢。Chad： 谢谢。