本体中的类/实例
我正在尝试理解本体论基础知识。 下面是一个示例：
- 汽车（类别）
- 2009 VW CC（子类别或实例？）
- 我邻居的 2009 VW CC（实例）
我的问题是理解什么是“2009 VW CC”（作为汽车模型）。如果您将产品模型作为本体中的子类 - 突然间您的本体因“汽车”的数千个子类而变得臃肿。那是多余的。同时我们不能说“2009 VW CC”是一个实例，至少它不是一个类的实质性实例。
区分常规实例和材料（不同的物理对象）有意义吗？
另一方面，如果两者都是实例（可以说具有不同的性质），那么实例如何继承非类的属性/关系？
I'm trying to comprehend ontology basics.
Here's an example:
- car (class)
- 2009 VW CC (sub-class or instance?)
- My neighbor's 2009 VW CC (instance)
My issue is understanding what is "2009 VW CC" (as a car model). If you're making product model a sub-class in the ontology - all of a sudden your ontology becomes bloated with thousands of subclasses of a "car". That's redundant. At the same time we can't say "2009 VW CC" is an instance, at least it's not material instance of a class.
Does it make sense to distinguish between regular instances and material (distinct physical objects)?
At the other hand, if both are instances (of different nature so to say), then how can instance inherit properties / relations of a non-class?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不想说这取决于情况，但这取决于情况。
如果您需要对世界上的每辆车进行建模，并且有可以调用它们的方法（例如“更换轮胎”，这是每个模型都非常不同的过程），那么是的，您将会有很多臃肿的类，因为你的现实世界情况也很臃肿。
如果您只想拥有原型汽车图片的数据库，并且不关心它是您邻居实例的图片还是您姐妹实例的图片，那么您可以放弃底层。 “2009 VW CC”很可能是一个实例，尽管您可以想象它也是另一个模型中的一个类。
或者，也许您根本不需要将其设为真正的子类。一个简单的参考可能就足够了。例如，一家保险公司知道大量的汽车型号和年份，但开发人员不会为每个汽车型号和年份编写一个子类。相反，他们有一个汽车型号数据库，其中一行可能代表 2009 VW CC。当您为汽车投保时，他们会创建一个“投保汽车”实例，并引用“2009 VW CC”实例。
这并不严格遵循“使用继承来实现‘is-a’关系”，但对所有车型的操作都是相同的——只是参数（例如每年的保险价格）发生变化，以及新的车型记录在数据库中，而不是代码中。
这里的一个假设是，您可以将不同模型之间的差异建模为汽车上相同方法的参数。
（旁白：当 iPhone 开始通过电话公司网站提供时，我注意到它打破了他们的类别模型 - 他们的网站似乎在一个页面上处理数十个品牌和型号的手机 - 大概使用一个简单的手机数据库和他们的功能 - 然后需要一个特殊的页面来处理 iPhone 型号，大概是因为他们的类需要新的特殊方法来支持 iPhone 销售的某些方面，自动销售台会说“按 1 购买手机。按 2 购买手机。”买一部 iPhone。”）
I hate to say it depends, but it depends.
If you need to model every single car in the world, and have methods that you can call on them (like "change tyre", which is a process that is very different for each model) then yes, you are going to have a lot of bloated classes, because your real world situation is bloated too.
If you just want to have a database of pictures of archetypal cars, and you don't car whether it is a picture of your neighbour's instance or your sister's instance, then you can drop the bottom layer. "2009 VW CC" could well be an instance, even though you can visualise that it is also a class in another model.
Alternatively, maybe you don't need to make it a true subclass at all. A simple reference might be sufficient. For example, an insurance company knows about a large list of car models and years, but the developers don't write one subclass for each. Instead, they have a database of car models, where one row may represent 2009 VW CC. When you insure your car, they create an instance of "Insured Car" with a reference to the "2009 VW CC" instance.
This doesn't strictly follow the "Use inheritance for a 'is-a' relationship", but the operations on all the car types are identical - it is just the parameters (e.g. insurance price per annum) that change, and new car models are recorded in the database, not in the code.
An assumption here is that you can model the differences between the difference models as merely parameters to the same methods on car.
(Aside: When the iPhone started becoming available through phone company web sites, I noticed that it broke their class models - their web-sites seemed to handle dozens of brands and models of phone on one page - presumably using a simple database of phones and their features - and then needed a special page to handle the iPhone models, presumably because new special methods were required on their classes to support some aspects of the iPhone sale. Automated sales desks would say "Press 1 to buy a phone. Press 2 to buy an iPhone.")
你把它搞反了。
2009 VW CC继承自类car。因此，2009 VW CC需要了解car，但car不需要了解2009 VW CC。尽管我们在现实中偶尔会使用术语“子类”，但car对它的任何子类一无所知。更有趣的是，如果您考虑原型继承（例如在 javascript 中），其中对象直接从其他对象继承（想象一下，如果您的
2009 VW CC继承了邻居的2009 VW CC的各个方面代码>）。实际上，这是如何实现的，新对象有一个秘密指针返回到它们继承的对象。如果您考虑一下这个秘密指针，您就会发现原始对象如何不会变得臃肿。现在，如果您认为多重继承和长族谱可能会导致结构混乱，那么我会同意您的观点。
You have it backwards.
2009 VW CCinherits from the classcar. Thus2009 VW CCneeds to know aboutcar, butcardoesn't need to know about2009 VW CC. Though we do occasionally use the term "subclass" in reality,carknows nothing about any of its subclasses.What's more interesting is if you consider prototypal inheritance (like in javascript), where objects inherit directly from other objects (imagine if your
2009 VW CCinherited the aspects of your neighbor's2009 VW CC). In reality how this is implemented is that new object have a secret pointer back to the object they inherited from. If you think about this secret pointer you can see how the originating object doesn't become bloated.Now if you're suggesting that multiple inheritance and long family trees can lead to confusing structures, then I would agree with you.
我真的很同意奇思妙想。另外，如果您需要汽车模型作为类，那么“突然间您的本体因汽车的数千个子类而变得臃肿”实际上不是问题。为什么会这样呢？您只需定义类而不是个体，您可能有一个带有基类的“抽象”本体，和一个带有代表现实世界中特定情况的类的“具体”本体。这不是 OOP，定义实际上介于实例和类之间的数千个类没什么大不了的，至少在概念上，没有人认为这“臃肿”或以任何其他方式奇怪。事实上，他们在我的领域一直在这样做（生命科学，我们通常不关心我们体内的蛋白质 P53，所以 P53 是一个类，尽管它也用于对关系数据库中的记录进行建模） 。
不过，我的经验是，像 Virtuoso 这样的工具似乎针对少数类和许多实例的情况进行了优化。事实上，当我将 Virtuoso 中的数百万个类转变为实例时，我观察到了显着的性能改进。所以，好吧，这很复杂......
I really agree with Oddthinking. Plus, if you need car models as classes, "all of a sudden your ontology becomes bloated with thousands of subclasses of a car" actually is not a problem. Why should it be? You just define classes instead of individuals, you might have an 'abstract' ontology, with base classes, and a 'concrete' ontology, with classes that represent the particular situation in real world. This is not OOP, defining thousand classes that are actually somewhat in between between instances and classes is no big deal, at least conceptually, nobody consider this 'bloated' or strange in any other way. Indeed, they do it all the time in my field (life science, where we typically don't care about the proteins P53 in our body, so P53 is a class, even though it's also used to model a record in a relational database).
Except, well, my experience is that tools like Virtuoso seem optimised for the situation of few classes and many instances. In fact, I've observed significant performance improvements when I turned million of classes in Virtuoso into instances. So, well, it's complicated...