我刚刚阅读this article并且它提到某个组织将Ontology作为(?)他们的数据库(?)层,并且这样做的决定很糟糕。问题是我之前没有听说过,所以我不明白为什么这很糟糕。
所以我尝试使用谷歌搜索数据库和本体,并从2006年开始有很多pdf,我们充满了难以理解的内容(我的想法)。我读了其中的一些,在这一点上仍然完全不知道他们在说什么。
我目前的印象是2006年有些学者试图卖掉我们,这是一种疯狂的时尚,但由于他们的想法的措辞而失败了。但是,如果有人真正知道这实际上是什么,我仍然很好奇。
答案 0 :(得分:27)
Karussell已经提供了维基百科的定义:
“正式代表 知识由一系列概念组成 域和它们之间的关系 那些概念“。
为了实现这种表示,已经开发了几种语言。目前最受关注的可能是Web Ontology Language (OWL)。
在传统的关系数据库中,概念可以使用表存储,但系统不包含任何有关概念含义以及它们如何相互关联的信息。 Ontologies do 提供了存储此类信息的方法,这允许更丰富的方式来存储信息。这也意味着可以构建相当先进和智能的查询。 SPARQL等查询语言专门用于此目的。
对于我的硕士论文,我曾与OWL本体论合作,但这是一项相当学术研究的一部分。我不知道这项技术目前是否在实践中使用过,但我确信潜力是存在的。
关于本体的“意义”和推理的一个例子:假设你在本体中定义了一个类Pizza
,一个类Vegetarian Pizza
,它是Pizza
没有{ {1}}属于班级Ingredients
。如果您现在创建一个Meat
的实例,恰好没有任何肉类成分,系统可以自动推断您的披萨也是Pizza
,即使您没有明确指定它。
答案 1 :(得分:10)
本体是描述域中类型(可能还有某些个体)的模式(模型),类型和个体之间可能存在的关系,以及个体和属性组合方式的约束。
一个类比是UML类图 - 但是本体具有形式语义,因此可以进行机器解释,而不仅仅是人类消费的图表。
示例强> :
类:Project,Person,ProjectManager。 ProjectManager是Person的子类(显然)。人与项目是不相交的
关系:worksOn,manage。管理是worksOn
的子属性约束:人们在项目上工作,而不是相反。只有项目经理才能管理项目。
这个简单的例子可以实现机器推断,例如:如果X管理Y,那么我们可以推断Y是项目,X是项目经理,因此是人。
答案 2 :(得分:5)
曾几何时,我已经将这样的问题分配给一个优秀的开发人员作为一项任务来回答,因为我的上司相信Ontology。它没有实现任何尖锐的答案,我的上司在一段时间后被解雇了。我还好奇。
我目前的理解是,这是一种自然语言(或“实体”)中的单词的概念,它们以不同的关系相互连接。然后我们将这个想法推广到任何数据库实体。基本上,我们最终没有任何有趣的,没有有用的查询语言。
我可能错了。
答案 3 :(得分:5)
答案 4 :(得分:2)
答案 5 :(得分:1)
很久以前,我使用了在斯坦福 (Protege) 开发的本体数据库。
这个想法是为了跟踪引用。书籍有作者和引述。引用有一个链接到一本书,以及一个页码。作者有书籍链接,书籍有出版商,出版日期,作者链接。文章和视频也是如此。
我的想法是插入引文,并且可以随时访问属性,因此我下次使用时不再需要跟踪引文是在哪本书和哪页上找到的。
本体数据库提供了一种极好的数据建模方式。但使用它是另一回事。从数据库中提取参考文献的部分比从 Word 文档中复制完整的引用和参考信息花费的时间更多。
让这样的东西真正有用所需要的只是集成到文字处理器中。 (理想情况下,您通常会或多或少地添加引用,然后保存它们以备后用,并附上指向您使用的位置的链接!:__)
答案 6 :(得分:0)
我是一个完全的门外汉,但在我看来,人工智能研究的周期是50 year history。
我们已经两次绕过这个周期。可能这次会有所不同......?
答案 7 :(得分:0)
上面的一些评论似乎有点不屑一顾。 我在实际产品中使用了本体数据库,这是解决问题的唯一方法。本体可用于创建一个数据库,该数据库可以比关系数据库更好地包含现实世界的复杂性。比“数据”更多的“信息”。当关系复杂且信息集很大且不完整时,它尤其好。 特别简洁的是良好的本体数据库中的查询机制 - 它智能地使用模式/本体(例如任何类层次结构)来返回否则将找不到的答案。
答案 8 :(得分:0)
本体论(Ontology)来自生物科学,代表了一个非常简单的主意,但由其他不常用的词定义。
通过领域内的一组概念以及这些概念之间的关系对知识进行形式化表示
因此,用计算机科学的术语来说,它是一张图,其中节点对应于所有属于同一主题的事物,并用与主题相关的数据进行注释,并与其他具有关系注释边缘的节点连接。
由于该模型不太适合关系数据库,因此,如果您打算存储本体,则可能要使用图形数据库或一种流行的关系数据库图形存储技术。
Ontologize尚未在所有方面超过关系数据库的主要原因是因为关系数据库提供了一种简单的方法(即使灵活性较差),可以将外键这两个项目联系起来。尽管此键不允许使用大量注释来描述这种关系,但是它确实限制了数据结构化方法的数量,从而阻止人们创建各种类型的关系(幸运的是,这意味着限制了浪费的关系的数量)。
例如,在基于本体的“家谱”数据库中
请注意,现在到了棘手的部分。您有“母亲”和“父亲”,但是“父母”呢?如果省略“父母”,则查找逻辑更为复杂,因此让我们包括一个新的关系“父母”,这意味着一个人的“母亲”现在具有两个链接,“母亲”和“父母”(父亲也是如此)。
那“祖父母”呢?再次,从逻辑上讲,它将某些信息保留在数据库之外,但是存储它会增加维护数据库的开销。
“叔叔”,“阿姨”,“公婆”,“岳父”等都加入了一种新的关系,而本体论的力量在于,您不受任何种类的约束您希望添加的关系;但是,困难在于知道哪些关系直接影响解决方案(如果不直接存储关系,则通常会缺乏性能,因为您需要进行多次数据库查找才能找到“组合关系”)。