英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
OWL API：用于OWL本体的Java API
抽象
我们介绍了OWL API，这是一种用于处理OWL本体的高级应用程序编程接口（API）。OWL API与OWL 2结构规范紧密结合。它支持W3C规范中定义的语法（功能语法，RDF / XML，OWL / XML和Manchester OWL语法）的解析和渲染；本体结构的操纵；以及推理引擎的使用。用Java编写的OWL API的参考实现包括用于各种OWL 2配置文件的验证器-OWL 2 QL，OWL 2 EL和OWL 2 RL。OWL API在各种工具和应用程序中得到了广泛的使用。
1.简介
自2004年以来，Web本体语言OWL就成为W3C建议[32]，其中OWL 2 [41]完善并扩展了原始规范。语言成功和采用的先决条件是工具的存在，OWL也不例外，现在可以使用多种工具（免费，开源和商业）。这些工具支持OWL本体的创建和编辑，本体论推理以及应用程序中本体的使用。
在本文中，我们讨论了OWL API，这是一个高级应用程序编程接口（API），它支持OWL本体的创建和操作。OWL API自2003年以来就可用，并且已进行了许多设计修订，尤其是跟踪OWL本身的发展。OWL API的关键方面包括以公理为中心的抽象，一流的更改支持，通用推理程序接口，各种OWL 2概要文件的验证器以及对各种语法的本体进行解析和序列化的支持。OWL API还具有灵活性
2.OWL API设计理念
OWL API的最初灵感来自对XML文档对象模型（DOM）提供[40]的影响的观察。DOM以及免费提供的实现（例如Sun的JDK [38]中的Java实现）使大量开发人员可以在应用程序中使用和操纵XML，从而促进了XML的广泛采用。我们的信念是证明类似的努力将对采用OWL很有好处。通过提供OWL API，开发人员可以在适当的抽象级别上工作，从而将它们与潜在问题（例如，数据结构的序列化和解析）隔离开来。考虑到OWL与RDF的紧密关系[24]及其三重表示，这是OWL的一个特殊考虑。为了提供这种“高级视图”，OWL API的设计直接基于OWL 2结构规范[30]。本体被简单地视为一组公理和注释，如图1所示。OWL API中实体允许第三方为所有主要组件提供替代实现的设计。OWL API用Java实现，可以根据LGPL许可证1作为开源使用。
自2003年进行初步开发[8]以来，OWL API已用于多个开发项目中，包括Proteacute;geacute;-4[25]，SWOOP [23]，NeOn工具包[17]2，OWLSight3，OntoTrack [26]，Pellet推理程序[36]4和许多在线验证和转换服务5。早期版本的OWL API的工作为WebOnt工作组6贡献了宝贵的实施经验[3]，从而促进了OWL建议书的产生。在所有版本中，OWL API的下载量都超过34,000（去年一年每月下载量超过500），这进一步增强了我们的观点，即它在促进OWL的使用和使用中一直发挥着并将继续发挥关键作用。类表达式和公理的接口的名称和层次结构与结构规范紧密对应，将高级OWL 2规范直接与OWL API的设计相关。OWL API支持加载和保存本体的各种语法。但是，OWL API中的任何模型接口都不能反映或不偏向任何特定的具体语法或模型。例如，与其他API（例如Jena [12]或Proteacute;geacute;3.X API）不同，类表达式和公理的表示不在RDF三元组级别。
图1 一个UML图，显示了OWL API中的本体管理。OWLOntology接口为访问器提供了有效获取本体中包含的公理的访问器。存储公理的方法由OWLOntology接口的不同实现提供。API的设计使混合和匹配实现成为可能，例如，
-内存本体可以与存储在数据库中的本体和存储在某种三重存储中的本体一起使用。OWL API参考实现提供了一种有效的内存存储解决方案。
3.详细设计原则
3.1.模型
OWL API的模型通过许多接口和类定义提供对OWL本体的访问。模型接口是只读的，因为它们不提供用于更改基础数据结构的显式功能（请参阅第3.2节）。
遵循OWL 2结构规范，该模型提供了以OWL本体为基础的以公理为中心的视图（请参见图1），并且OWLOntology包含许多OWLAxiom对象。还可以使用方便的方法来回答包含问题，例如“本体论O是否包含C类？”，其中包含是指本体论中包含引用C的公理。这支持了我们所谓的信息局部性，因为有关类的所有断言都与特定的本体相关联。由于OWL在开放的Web上下文中运行，因此不同的本体可以对相同的类和属性进行不同的声明。
尽管这种“以公理为中心”的视图不同于原始的OWL API设计，后者提供了“面向框架”的模型，但仍希望提供一种抽象级别，以使开发人员和应用程序与基础语法表示（尤其是RDF或基于三重表示形式）隔离一直是OWL API方法的基石。
模型数据结构充分利用了访问者模式[14]，该模式允许将数据结构与功能分离。通过访问者，可以更轻松地向类层次结构添加功能（并且特别适合数据结构代表抽象语法的情况。但是，Visitor模式确实有一个缺点，即更改数据结构可能会很昂贵，因为它可能需要更改Visitor实现。但是，对于OWL API，如果数据结构稳定，则该模式非常合适。
数据模型的规范主要通过Java接口实现，从而可以使用替代实现策略。参考实现提供了用于有效地在内存中表示本体的数据结构。对于许多目的来说，这就足够了。例如，最新版本的美国国家癌症研究所（NCI）本体可以轻松容纳约700MB的内存（100MB的内存不带注释）。但是，API的设计使得可以为诸如关系数据库或三重存储之类的本体提供其他存储机制，并可以“混合和匹配”存储实现，以便本体导入闭包可以包含本体中的内存表示形式。本体以自定义数据库的形式保留在二级存储中，而本体则存储在三重存储中。
尽管API并未提供现成的这些替代存储机制，但第三方已经开发了此类解决方案。Henss等人[20]已经开发了一种示例性的解决方案，称为OWLDB。他们的解决方案使用OWL构造的“本机”映射（与对三元组的映射相反）到自定义数据库模式，将本体存储在关系数据库中。Redmond在[34]中采用了类似的方法。
3.1.1.本体管理
除了用于表示实体，类表达式和公理的模型接口之外，还必须允许应用程序管理本体。图1展示了此图片的高级概述。OWLOntology接口为访问本体中包含的公理提供了一个点。如上所述，OWLOntology接口的不同实现可以为本体提供不同的存储机制。
OWLOntologyManager提供了一个创建，加载，更改和保存本体的中心点，本体是OWLOntology接口的实例。每个本体都是由本体管理器创建或加载的。本体的每个实例对于特定的管理者都是唯一的，并且对本体的所有更改都通过其管理者来应用。
这种集中式管理设计允许客户端应用程序具有对本体的单个访问点，为加载本体提供重定向机制和其他自定义，并允许客户端应用程序监视应用于任何已加载本体的所有更改。管理器还隐藏了与选择适当的解析器和渲染器以加载和保存本体相关的许多复杂性。
3.2更改
本体本体模型的核心接口是只读的，通过使用显式的更改对象来处理更改问题（公理的添加和删除）。OWLOntologyChange类提供了顶级更改对象，该对象包含定义了封装特定更改的其他子类。然后，通过进一步使用Visitor模式来提供更改法规，其中OWLOntologyChangeVisitor对象用于制定更改。
显式更改对象的这种使用遵循命令设计模式[14]，该模式将更改请求封装为对象。然后由Visitor对象制定更改。
命令模式的这种使用有助于对诸如撤消或重做之类的操作的支持，并且随着操作的进行封装封装提供了一种跟踪更改和支持版本管理的机制。更改对象还为存储有关更改的元数据（例如，请求更改的用户）提供了方便的位置-信息对于支持本体管理和编辑过程同样至关重要。
所有本体更改都通过本体管理器应用。这意味着可以将一个本体更改列表应用到一个单元中，该列表将对多个本体进行多个更改。这对于诸如本体编辑器之类的应用程序效果很好，其中诸如实体名称更改（实体IRI更改）之类的编辑操作可能涉及从多个本体中添加和删除多个公理-可以将更改分组在一起以形成一个“编辑器”。操作”，然后一次应用这些更改。
3.3推论与推理
OWL的一个关键方面是提供语义，该语义精确地定义了有关OWL本体的含义，并提供了诸如一致性之类的属性的形式化描述。即时通讯。
这些语义的实现不是一件容易的事。通过分离推理功能，我们可以减轻实现者的负担，同时允许那些提供此类实现的人在其所宣传的功能中对此明确。另外，如[8]中详细讨论的，断言和推理的分离在OWL的实现中很重要，尤其是在开发用户应用程序时，因为用户可能需要明确指示为什么存在分层关系。
OWLReasoner界面提供对与OWL本体推理过程相关的功能的访问，支持诸如一致性检查，类或属性层次结构的计算和公理需要之类的任务。当然，提供方法签名并不能一味地宣告实现的功能–无法保证实现接口的组件必须正确实现语义。但是，推理程序接口的签名和详尽的详细文档在某种程度上有助于提供对所支持操作的期望。从客户的角度来看，拥有定义良好的推理程序界面的好处不能被夸大。在客户端应用程序中将一个推理程序实现交换为另一个推理程序实现的能力，并且知道在查询回答方面，每个推理程序实现都应表现出相同的行为，这是一个主要优势。测试数据的收集（例如OWL测试用例[11]）可以进行系统的测试，并可以确定实施是否正确执行。
设计了推理程序接口，以使推理程序能够公开提供增量推理支持的功能。OWL API允许初始化推理器，以便侦听本体更改，并立即处理更改或将其排队在缓冲区中，以便以后处理。该设计适合在本体编辑器中使用推理机的场景，并且在某些情况下必须在提示对本体进行编辑时做出响应，或者在推理机到达时要对本体更改做出响应的情况。
包括CEL [1]，FaCT [39]，HermiT [29]，Pellet [36]和Racer Pro [16]在内的许多现有实现以及SnoRocket推理程序都提供OWL API包装器。因此，这些推理引擎可以轻松地集成到基于OWL API的应用程序中，例如Proteacute;geacute;-4或NeOn Toolkit。
3.4.解析和渲染OWL本体
使OWL API与OWL 2结构规范保持一致的好处是，无需承诺使用特定的具体语法。符合[37]的OWL实现或工具必须支持RDF / XML，但存在其他几种语法已针对不同目的进行了优化。例如，Turtle语法[9]提供了RDF序列化的“紧凑而自然的文本形式”。曼彻斯特OWL语法[18]为OWL本体提供了人类可读的序列化。
OWL API包括对多种语法的本体的读写支持，包括RDF / XML，Turtle，OWL / XML，OWL功能语法，Manchester OWL语法，KRSS语法7和OBO平面文件格式（ 8。由于API的基础设计，因此本体的import封闭可能包含从以不同语法编写的本体文档中解析出来的本体。
OWL API的参考实现使用解析器和渲染器的注册表，支持添加自定义语法。加载本体时，将在运行时自动选择适当的解析器。默认情况下，本体将保存为解析时所用的格式，但是可以覆盖此本体，以便在编辑器中执行语法转换任务和“另存为”操作。
4.演变
已经开发了三个版本的OWL API。第一个版本[8]借鉴了OilEd [5]的实施的早期经验，OilEd [5]是最早使用描述逻辑推理服务（通过使用DIG协议）来帮助用户构建OIL和DAML 的用户工具之一石油本体。尽管OilEd被广泛使用（下载请求超过10,000个），但基础实现遇到了问题，尤其是接口与实现之间缺乏分隔。OWL API的第一个版本解决了许多这些问题，同时提出了其他设计决策，例如广泛使用Visitor模式[14]。
OWL API版本2中的一个关键更改是Java Generics9的引入，它可以对方法类型进行更严格的控制，从而确保（例如）对等价类的查询结果作为一组类表达式返回。第2版还跟踪了OWL（在当时称为OWL 1.1 [33]）的拟议更改，这是由OWL工作组的工作引起的，其中包括增加了合格的基数限制。特别是从基于框架的数据结构向面向公理的模型转变。
最新的版本3看到方法和类名与OWL 2结构规范[30]中使用的一致。这可能会导致OWL API早期版本向后兼容的问题，但是我们的决定是与规范的一致带来了很多好处，而这些好处远远超过了这些。例如，W3C规范现在可以自己用作代码库的其他文档。阅读OWL 2规范文档后，用户应该能够轻松识别OWL API与规范之间的对应关系。尽管那时名称更改在很大程度上是语法上的，从而允许使用查找和替换脚本来解决大多数不兼容问题，但实质性更改的一个领域是公理注释的建模，该更改已更改为与OWL 2规范保持一致。现在特别是公理注释是嵌入的公理，因此对结构标识具有影响。为了符合OWL 2建议，现在使用IRI标识OWL本体中的实体。
5.附加功能
在这里，我们讨论核心OWL API下载中提供的一些增强功能，这些功能支持诸如配置文件验证，说明和模块化之类的任务。
5.1 配置文件验证
OWL 2规范定义了与OWL 2语言的语法子集相对应的OWL配置文件。概要文件在OWL 2概要文件文档中定义，即OWL 2 EL，OWL 2 QL和OWL 2 RL。每个配置文件旨在交易一些表达能力。推理效率的力量。例如，OWL 2 EL配置文件出于表达多项式时间包含测试的目的而交换了表达性。类似地，可以使用规则引擎来实现OWL 2 RL配置文件的推理。
对于
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[239576]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
