本体中的类/实例答案

【问题标题】：Classes / instances in Ontology本体中的类/实例
【发布时间】：2010-04-17 03:06:53
【问题描述】：

我正在尝试理解本体基础知识。这是一个例子：

汽车（类）
2009 VW CC（子类还是实例？）
我邻居的2009款大众CC（实例）

我的问题是了解什么是“2009 VW CC”（作为汽车模型）。如果您正在使产品模型成为本体中的子类 - 突然之间，您的本体会因“汽车”的数千个子类而变得臃肿。那是多余的。同时我们不能说“2009 VW CC”是一个实例，至少它不是一个类的物质实例。

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

另一方面，如果两者都是实例（可以说是不同性质的），那么实例如何继承非类的属性/关系？

【问题讨论】：

标签： ontology

【解决方案1】：

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

如果您需要为世界上的每辆汽车建模，并且有可以调用它们的方法（例如“更换轮胎”，每个模型的过程都非常不同），那么是的，您将有很多臃肿的类，因为你现实世界的情况也很臃肿。

如果你只是想要一个原型车图片的数据库，而不管是你邻居实例的图片还是你姐姐的实例图片你都不开车，那么你可以去掉底层。 “2009 VW CC”很可能是一个实例，尽管您可以想象它也是另一个模型中的一个类。

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

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

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

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

【讨论】：

我不打算为汽车的每个实例（或任何产品）建模，但我想在我的应用程序中提供一种方法来做到这一点。例如，如果产品以限量版发布，或者足够独特/定制。
那么也许混合模型是合适的。 Standard_Car 继承自 Car，并引用了它支持的不同模型的数据库。 Custom_Car 继承自 Car 并且它本身对每种类型的汽车都有子类，这些子类既不同又重要，足以在代码中进行昂贵的建模步骤。您邻居的汽车可能是 Standard_Car 的实例或 Car 的自定义子类之一，具体取决于其新颖性。

【解决方案2】：

你说反了。

2009 VW CC 继承自类 car。因此2009 VW CC 需要知道car，但car 不需要知道2009 VW CC。尽管我们在现实中偶尔会使用“子类”一词，但car 对它的任何子类一无所知。

更有趣的是，如果您考虑原型继承（如在 javascript 中），其中对象直接从其他对象继承（想象一下，如果您的 2009 VW CC 继承了您邻居的 2009 VW CC 的方面）。实际上，这是如何实现的，新对象有一个秘密指针，指向它们继承的对象。如果您考虑一下这个秘密指针，您会发现原始对象不会变得臃肿。

现在，如果您认为多重继承和长家族树会导致结构混乱，那么我同意您的看法。

【讨论】：

我同意你的第二段，但我看不出 SODA 在哪里不同意或倒退。我什至看不出他在哪里建议多重继承或长家谱。他似乎很担心车底下的 WIDE 家谱。
他认为类需要知道子类。这是倒退。只有子类需要知道类。
谢谢，这些想法很棒。所以看起来在现实生活中，如果我们保持结构可管理，我们可以说产品（在产品模型的意义上）都是实例，它们可以有更具体的实例和更具体的属性？
我没有暗示（或什至考虑一个概念）类或子类“知道”任何东西。不过，这是一种有趣的看待方式。
奇怪的想法——确切地说，我关心的是保持本体的可管理性，所以通常会成为实例的东西并不完全是实例，因为存在“真实世界”实例，但使它们成为子类最终会转化变成一个难以管理的本体。

【解决方案3】：

我真的同意奇思妙想。另外，如果您需要汽车模型作为类，“突然之间，您的本体变得臃肿，有成千上万的汽车子类”实际上不是问题。为什么应该这样？您只需定义类而不是个体，您可能有一个“抽象”本体，带有基类，以及一个“具体”本体，带有代表现实世界中特定情况的类。这不是 OOP，定义实际上介于实例和类之间的数千个类没什么大不了的，至少在概念上，没有人认为这“臃肿”或以任何其他方式奇怪。事实上，他们在我的领域一直这样做（生命科学，我们通常不关心我们体内的蛋白质 P53，所以 P53 是一个类，尽管它也用于对关系数据库中的记录进行建模） .

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

【讨论】：