我正在尝试构建一个Ontology来表示属性(资产),该属性应该有一个类型,如别墅或公寓......
我的问题是,我不知道别墅和公寓是否应该是班级或实例。 我怎么知道??
我正在考虑创建一个名为Property
的类和一个名为isTypeOf
的关系以及一个名为PropertyType
的类,它有两个实例apartment
和villa
。那是对的吗?或者我应该将Apartment
和Villa
作为PropertyType
类的子类?
答案 0 :(得分:3)
我认为,你在这里结合了两个区别,你可能想分别争论:
(1)与旧inheritance or delegation
问题大致相同。答案也或多或少相同:当歧视是所代表的对象的固有属性时,当歧视属性是你的知识模型的核心,以及歧视属性没有独立的存在理由时,使用继承。
另一方面,当歧视属性仅将附加信息添加到您的类/对象或有足够理由存在时,请使用委托"单独(即,不完全绑定到引用对象)。在您的情况下:请检查PropertyType
取决于PropertyType
本身而非个人Property
的信息量。如果有" 别墅有游泳池和圆形车道"而且这种区别很重要且可以重复使用,您可以考虑委托。
(2)遵循功能依赖的相同行。
我的个人经验法则是
LuxuryApartment
或只能附加到Garden
之类的Villa
等。但是,通常不一定正确或错误。
专业课程
如果Apartment
和Villa
是类,那么很容易根据这些类来制定其他公理。例如,假设只有Property
的{{1}}被允许拥有花园:
Villa
如果您尝试使用(∃ hasPropertyFeature . Garden) ⊑ Villa
数据属性进行表达,最终会得到类似
hasPropertyType
这不仅难以掌握,而且理由也较慢。此外,类可以是子类,即可以直接进行其他细分。
Contra Classes
但是,拥有(∃ hasPropertyFeature . Garden) ⊑ (∃ hasPropertyType . "villa"^^xsd:string)
属性而没有其他限制允许您纯粹在实例级别添加其他属性值,而无需触及原始本体。
如果hasPropertyType
只是一种新的属性类型,则基于类的版本需要更改原始本体的TBox并添加新的townHouse
类。虽然这通常没有问题(大部分时间都是保守扩展)但它仍然是 TBox 更改,您基本上需要为此类更改创建新版本的本体。
当属性引入功能依赖时,这是版本 - 当然 - 变得不太可行;见上文。
答案 1 :(得分:1)
RDF,RDFS和OWL具有必要的t-box术语。默认情况下,OWL DL基于描述逻辑,它大量使用集合论,因此它的自然优势在于使用类,交集和联合来描述事物。
话虽如此,我更喜欢使用略微更柔和/更宽松的语义进行建模,并且想要使用分类法(枚举)那么如果你不太了解,那么如何看待SKOS以帮助解决问题你的域名。
使用SKOS,您可以创建ConceptSchemes,其中包含描述为与其他Concepts和ConceptScheme更宽/更窄的各种类。此外,它与OWL完全兼容