Hadoop 基于Map-Reduce的OWL文件推理

Hadoop 基于Map-Reduce的OWL文件推理,hadoop,mapreduce,bigdata,distributed-computing,owl-api,Hadoop,Mapreduce,Bigdata,Distributed Computing,Owl Api,我已经创建了一个大的本体论。owl和我现在处于推理阶段。事实上,问题在于如何确保本体的可伸缩推理。我在文献中进行了搜索,发现大数据是解决这一问题的适当方法。不幸的是,我发现MapReduce不能接受作为输入OWL文件。除了SWRL等语义语言外,SPARQL不能使用 我的问题是: 我应该和其他人一起更改owl文件吗 例如,如何使用Map reduce将规则SWRL转换为可接受的格式 感谢对于这个问题来说,大数据是一个非常简单的解决方案 确保OWL本体的可伸缩性是一个非常复杂的问题。涉及的主要变量是

我已经创建了一个大的本体论。owl和我现在处于推理阶段。事实上,问题在于如何确保本体的可伸缩推理。我在文献中进行了搜索,发现大数据是解决这一问题的适当方法。不幸的是,我发现MapReduce不能接受作为输入OWL文件。除了SWRL等语义语言外,SPARQL不能使用

我的问题是:

我应该和其他人一起更改owl文件吗

例如,如何使用Map reduce将规则SWRL转换为可接受的格式


感谢

对于这个问题来说,大数据是一个非常简单的解决方案

确保OWL本体的可伸缩性是一个非常复杂的问题。涉及的主要变量是公理的数量和本体的表达能力;然而,这些并不总是最重要的特征。在很大程度上还取决于所使用的api,对于推理步骤与解析分离的api,使用的是哪种推理器

SWRL规则增加了另一个层次的复杂性,因为它们几乎具有任意的复杂性——因此一般来说不可能保证可伸缩性。对于特定的本体和特定的规则集,可以提供更好的猜测

转换为MapReduce格式/may/help,但据我所知,没有标准转换,要保证转换保留本体和规则蕴涵的语义将相当复杂。因此,该任务相当于以允许您回答需要运行的查询的方式重写数据,但这可能被证明是不可能的,具体取决于特定的本体


另一方面,这个本体的大小和分配给任务的内存量是多少?

请根据您需要的推理更新您的问题,如果没有这些输入,应该几乎无法回答。你也可以看看这里。您对SPARQL针对OWL的断言是错误的;SPARQL可以与OWL一起使用,有时也可以在bigdata上使用。请提供您找到的“文献”。谢谢您的回答。我想执行本体中的if->then规则。但我发现了可伸缩性的问题。推理机向我指出内存不足,因此我认为应该集成大数据技术。问题是我不知道如何在MapReduce中执行这些规则。我阅读的一篇文献综述是:通过数据分区和索引在MapReduce中高效地处理SPARQL查询,使用MapReduce进行可伸缩的分布式推理,使用MapReduce框架进行RDFS/OWL推理,使用MapReduce将OWL本体解析和映射到Hadoop,请更新您的问题,而不是评论。据我所知,您正在寻找一种在大型本体上应用SPARQL的方法;如果是这样,请更新您的问题,提供更多详细信息,否则没有人会回答。非常感谢。我的本体论有30000多条公理。但是大小不是固定的,它可以长得更多。在阅读了你们的答案后,你们能帮我在我的问题中找到答案吗:我能将OWL文件与Mapreduce或其他大数据技术结合使用吗。我可以使用大数据技术执行SWRL规则吗?由于SWRL规则给我的本体增加了一定程度的复杂性,我应该如何解决这个问题?我应该选择另一种推理方式吗?如果是这样,我该怎么办?非常感谢您分配的内存量是多少,本体的表达能力是多少?简短回答:这在现有库中是不可能的。答案很长:这涉及到许多公开的研究问题,因此有一些策略可能有用,但其可行性目前尚不清楚。例如:原子分解可能会有所帮助,但对于增量原子分解的研究论文,需要使用增量Google,并且使用的推理器需要支持SWRL规则。本体需要服从于原子分解——并不是所有的本体都可以通过这种方式缩小尺寸。谢谢。我的本体论的表现力是不可靠的。分配的内存是1GO。那么分布式推理呢?你应该尝试使用ELK作为你的本体——它是该概要文件的最快推理器。关于分布式推理,我不知道有任何实现。