OWL 我怎么知道某个东西应该是类还是实例？

Question

我正在尝试构建一个本体来表示属性（资产），该属性应该具有诸如别墅或公寓之类的类型...

我的问题是我不知道别墅和公寓应该是类还是实例。 我怎么知道？

我正在考虑创建一个名为Property 的类和一个名为isTypeOf 的关系以及一个名为PropertyType 的类，它有两个实例apartment 和villa。请问这是正确的吗？或者我应该将Apartment 和Villa 作为PropertyType 类的子类？

Answer 1

我认为，您在这里结合了两个区别，您可能想分别争论：

1. 什么时候应该使用子类化，什么时候应该使用属性引用？
2. 何时应在 TBox 级别（子类化）以及何时在 ABox 级别（属性值、实例）表示区分？

(1) 或多或少与旧的inheritance or delegation 问题相同。答案也大致相同：当歧视是所代表对象的固有属性时，当区分属性是您的知识模型的核心，并且当区分属性没有独立存在的理由时，请使用继承。

另一方面，当歧视属性仅向您的类/对象添加附加信息或有充分理由自行“存在”时（即不完全仅与引用相关联），请使用委托目的）。在您的情况下：检查有多少信息取决于PropertyType，这取决于PropertyType 本身，而不是个人Property。如果有诸如“带游泳池和环形车道的别墅”之类的东西，并且这种区别很重要并且可以重复使用，那么您可以考虑委托。

(2) 遵循函数依赖的相同路线。

我个人的经验法则是

• 如果您希望根据细分制定其他公理，则将其设为 类，即如果您需要引用细分集，如果您需要附加数据或对象属性，或者如果您期望可能需要进一步改进（想想LuxuryApartment 或只能附加到Villa 的Garden 等）。
• 如果您希望本体是明确的并且新的子分类预计很少见，请将其设为类。但请注意，您的期望可能是错误的。
• 如果属性值不引入或非常有限的功能依赖关系，并且如果区别本身不具有任何其他属性，则将其设为属性。

但是，一般来说，不一定有正确或错误。

专业课

如果Apartment 和Villa 是类，那么基于这些类很容易制定额外的公理。例如，假设只有Propertys 和Villas 被允许拥有花园：

(∃ hasPropertyFeature . Garden) ⊑ Villa

如果你尝试使用 hasPropertyType 数据属性来制定这个，你最终会得到类似的东西

(∃ hasPropertyFeature . Garden) ⊑ (∃ hasPropertyType . "villa"^^xsd:string)

这不仅很难掌握，而且推理起来也更慢。此外，类可以被子类化，即有一种直接的方法来进行额外的细分。

对比类

但是，拥有一个没有额外限制的 hasPropertyType 属性允许您纯粹在实例级别添加额外的属性值，而无需触及原始本体。

如果townHouse是一个新的属性类型，基于类的版本需要改变原来本体的TBox，增加一个新的TownHouse类。虽然这通常没有问题（大多数情况下是保守的扩展），但它仍然是一个 TBox 更改，您基本上需要为此类更改创建一个新版本的本体。

这是版本——然而——当属性引入功能依赖时变得不太可行；见上文。

Answer 2

RDF、RDFS 和 OWL 具有必要的 t-box 术语。默认情况下，OWL DL 基于描述逻辑，它大量借鉴了集合论，因此它的自然优势在于使用类、交集和联合来描述事物。

话虽如此，我更喜欢使用稍微更软/更宽松的语义进行建模，并希望使用分类法（枚举），那么如果您对自己的领域知之甚少，那么如何查看SKOS 来帮助解决问题。

使用 SKOS，您可以创建包含各种类的概念方案，这些类被描述为比其他概念和概念方案更广泛/更窄。此外，它与 OWL 完全兼容