本体中的类/实例

Question

我正在尝试理解本体基础。下面是一个例子：

• car (级)
• 2009大众CC (子类或实例？)
• ，我邻居的2009年大众CC (实例)

我的问题是理解什么是“2009年大众CC”(作为汽车模型)。如果您正在使产品模型成为本体中的子类--突然之间，您的本体就会因成千上万的“汽车”子类而变得臃肿起来。那是多余的。同时，我们不能说"2009大众CC“是一个实例，至少它不是一个类的物质实例。

区分常规实例和物质(不同的物理对象)是否有意义？

另一方面，如果两者都是实例(可以这么说)，那么实例如何继承非类的属性/关系？

Answer 1

我不想说它取决于，但它取决于。

如果你需要为世界上的每一辆汽车建模，并且有你可以调用它们的方法(比如“更换轮胎”，这对于每个型号来说都是一个非常不同的过程)，那么是的，你会有很多臃肿的课程，因为你的真实世界也会膨胀。

如果你只是想要一个原型汽车图片的数据库，而你不开车，不管它是你邻居的实例还是你姐姐的实例，那么你可以放下底层。"2009大众CC“很可能是一个例子，尽管你可以想象它也是另一个模型中的一个类。

或者，您根本不需要让它成为一个真正的子类。一个简单的引用可能就足够了。例如，一家保险公司知道大量的汽车型号和年份，但是开发人员并不为每个子类编写一个子类。相反，他们有一个汽车模型的数据库，其中一行可能代表2009年大众CC。当您为您的汽车保险，他们创建一个实例的“保险汽车”与参考“2009年大众CC”实例。

这并不严格遵循“为' is -a‘关系使用继承”，但是对所有汽车类型的操作都是相同的--只是参数(例如每年的保险价格)发生了变化，新车模型被记录在数据库中，而不是代码中。

这里的一个假设是，您可以将差异模型之间的差异建模为在car上相同方法的参数。

(旁白:当iPhone开始通过手机公司的网站提供时，我注意到它打破了他们的分类模式-他们的网站似乎在一个页面上处理了几十个品牌和手机模型--大概使用了一个简单的手机及其功能数据库，然后需要一个特殊的页面来处理iPhone模型，大概是因为他们的类需要新的特殊方法来支持iPhone销售的某些方面。自动销售部会说：“按1键购买手机，按2键购买iPhone。”

Answer 2

你倒过来了。

2009 VW CC继承自类car。因此，2009 VW CC需要了解car，但car不需要了解2009 VW CC。虽然我们在现实中偶尔使用“子类”这个术语，但car对它的任何子类一无所知。

更有趣的是，如果考虑原型继承(如javascript中的继承)，对象直接从其他对象继承(想象一下如果您的2009 VW CC继承了邻居2009 VW CC的各个方面)。实际上，这是如何实现的，新对象有一个指向他们继承的对象的秘密指针。如果考虑到这个秘密指针，您可以看到原始对象是如何不会膨胀的。

如果你认为多重继承和长家族树会导致混乱的结构，那么我会同意你的观点。

Answer 3

我真的同意奥德的想法。另外，如果您需要将汽车模型作为类，“突然之间，您的本体就会被成千上万的汽车子类所膨胀”实际上并不是一个问题。为什么要这样？您只需要定义类而不是个人，您可能有一个“抽象”本体、一个基类，以及一个“具体”本体论，其类代表了现实世界中的特定情况。这不是面向对象( OOP )，在实例和类之间定义上千个类并不重要，至少在概念上，没有人认为这种“臃肿”或奇怪之处在任何其他方面。事实上，在我的领域(生命科学，我们通常不关心我们体内的蛋白质P53，所以P53是一个类，尽管它也用于在关系数据库中建模)。

除了，嗯，我的经验是，像Virtuoso这样的工具似乎对少数类和许多实例的情况进行了优化。事实上，当我将Virtuoso中的数百万个类转化为实例时，我观察到了显著的性能改进。所以这很复杂..。