摘 要：为提高军事物流业务流引擎应用本体（Military Logistics Business Flow Engine Special Ontology，MLBFEO）的维护与实践应用的效率与可靠性。文章对Protégé、Jena API等持久化OWL文件到本体数据库（Ontology Database， ODB）的表结构、数据元素关系分析基础上，提出了基于RDBMS与RDF“三元组”核心思想，设计了军事物流业务流ODB的结构。文章构建的军事物流业务流ODB为军事物流业务流引擎（MLBFE）的维护和基于MLBFE的业务管理信息系统[1]（BMIS）开发夯实了数据结构根基。
　　关键词：应用本体；本体数据库；结构固化
　　中图分类号：E075 文献标识码：A
　　1 问题提出
　　目前，百分之百的军事物流业务管理信息系统（Business MIS， BMIS）的事务序列、事务内功能的耦合与聚合均编码固化，直接影响了BMIS的可修改性和功能扩展性。文献[1]提出了基于军事物流业务流引擎（Military Logistics Business Flow Engine， MLBFE）开发BMIS的技术架构，其核心是BMIS与业务流程隔离（如数据库与软件系统的物理隔离），BMIS中的事务、功能、角色及数据元素的CRUDT等关系受限于且来自MLBFE，提高了BMIS的适应性。但随着物流信息技术发展和新理念产生，军事物流业务中流程定制者和开发团队在应用不同对象时必然产生各种歧义，即语义异构和结构异构，如功能环节、事务、功能点、不同数据源的数据结构，等等，针对上述问题，为规范军事物流业务流相关概念、结构及其个体差异，文献[2]利用Protégé设计了基于OWL的军事物流业务流应用本体（MLBFEO），为MLBFE结构要素提供了明确的语义与结构。但由于本体库是以XML结构OWL语法存储的，属于文件系统，经文献[3-5]实践验证，基于文件系统的本体库存在两点不足：一是维护和检索效率低。随着本体库中类、实例数据的增加，系统的维护、用户按需检索匹配的效率不能满足实际需求；二是并发性与共享性差。本体文件同样具备文件系统的数据并发修改差的特点，进而影响本体数据共享等。
　　而关系数据库（RDBMS）是海量数据的存储与检索最为成熟的技术，它不仅实现了数据完整性约束，而且提供了数据结构和数据操作，提供了对事务ACID的完整控制。目前，将本体文件转换到DBMS的研究实践较多[3-5]持久化方式主要有：本体建模工具、第三方API按约定自动生成；按RDBMS的数据模型自构建等，无论是何种方式目的是提高本体数据的维护与检索匹配效率。本文通过利用Protégé、Jena API等方式实践，将本体文件持久化到本体数据库（Ontology Database， ODB），以RDBMS存储与管理本体，并针对上述本体数据库表结构的不足，提出了基于RDBMS和RDF“三元组”思想构建MLBFE本体数据库的建模内容。
　　2 本体结构要素
　　本体（Ontology）是共享概念模型的明确的形式化规范说明，是用来描述某个领域知识的，是实现不同主体之间共享与互操作的语义与结构基础，是计算机理解“符号”含义与推理的基础。但无论用XML、RDF、OWL等何种语言对本体建模，本体典型的结构要素由类、实例、属性和公理组成，各组成体现了类之间、实例之间、类与实例之间的三种关系[5]（即部分关系（Part-of）、继承关系（Kind-of）、实例关系（Instance-of））。而对于军事物流业务流引擎应用本体而言，本体关系主要表现为：（1）类自身约束（如，<签订采购合同>本体（SignContract）自身约束：上级本体（hasFrontNode）、下级本体（hasNextNode）的值域是自身Class约束；hasNextNode绑定到<审核采购合同>本体（AuditingContract），且可同时绑定多个具备并行特点的本体；利用owl：someValuesFrom、owl：Cardinality约束值域，等）。（2）类之间关系（如，具备不同父类的本体关系，<业务主题数据>本体（SubjectofBusinessData）与<数据元素>本体（DataElement）之间具备<包含>（hasDataSet）属性关系）。（3）类与实例关系（如，类是实例的“类型”，<数据CRUDT>本体（DataCRUDT）的具体化具有5个数据类型属性，即isCreate、isRead、isUpdate、isDelete、isTransmit）。综合可知：利用类描述与事务相关的环节、功能、实体；实例是真实存在的类的实例化，每类对应多个实例；对象属性表示类之间的层次关系，实例之间的约束关系；数据类型属性表示实例的数据类型，即值域；等。
　　那么如何将军事物流业务流引擎应用本体的结构要素持久存储到数据库中，参见文献[3-5]可知，本体数据库的建模方法主要有两类：一是，约定结构建模，自动生成ODB方式，指利用Protégé、Jena API等自动将OWL文件持久化到数据库的方式；二是，自定制结构建模，指利用开发工具（如VS.NET、JBuilder、MyEclipse等）编写对OWL文件的装载、解析、抽取、传输并存储到关系数据库的方式。
　　3 约定结构建模
　　目前，利用第三方工具将OWL文件持久化到数据库的方式主要是Protégé和Jena API。其中，Protégé是OWL/RDF（s）的建模工具，而Jena API是为Java环境下装载、解析、抽取、存储和使用本体对象集提供的操作“命令”。两种工具自动生成的本体数据库表的结构不同，Protégé将本体集存储到9个字段的1个数据库表中；Jena API按照RDF“三元组”约定，将本体集存储到7个数据库表中，如果持久化多个本体文件时，在本体数据库中创建的数据库表将大于7个（约等于“7+2n”个数据库表，其中n表示本体文件数量，值域为1、2、3、…）。 　　3.1 Protégé Database
　　Protégé Database创建ODB方式有两种：一是，创建Protégé Database工程。利用本体建模工具自动创建和更新Database数据库表；二是，创建Protégé OWL/RDFS Files工程。本体建模完毕后，利用本体转换工具（Convert Project to Format）将本体文件转换为OWL/RDF Database[6]。但无论哪种转换方式，Protégé工具生成ODB之前均需配置数据源参数，见表1。本文采用MS SQL Server 2005作为DBMS，ODBC数据源取名为（新建或选定存在的Database），数据库表取名为，用户名称与口令可根据实际自定，军事物流业务流引擎应用本体文件为。
　　参数配置完成后，Protégé按约定（数据库表结构约定）自动将OWL/RDF文件，按类、实例、属性及其关系久化到所指数据库中，并将本体存储到新建的数据库表，ODB表结构及资源见表2。
　　表2中字段含义简述如下：（1）Frame（Integer）。作用，MLBF应用本体中任一结构要素（类、实例、对象属性、数据类型）的数据库内的唯一标识，如同身份证号功能；取值，<10 000的整型是系统保留数值，主要用于本体内结构要素之间关系的唯一标识。（2）Frame_type（Smallint）。作用，表示当前本体结构要素的记录的类型；取值，9表示Class、12表示DataType Property、13表示Object Property、25表示实例（Individuals）、11/16表示Class之间的自定义约束，等。（3）Slot（Integer），4bits。作用，与Frame_type复合，描述本体属性的标识。取值：2002表示Class、2005表示subClassof、2014表示数据类型的值域、9093表示本体结构要素的Comment、2006表示Individuals的类型（Class），等等。（4）Facet（Integer）。作用，本体的相关面信息的标识；取值，3004-实例之间存在关系，大部分情况下取值为0。（5）Is_template（Smallint）。作用，指是否利用知识库中规定要素模板。取值：如果利用模板，则为1；否则为0，一般情况下为0。（6）Value_index（Integer）。作用，指确定本体结构要素的顺序。取值：顺序号。（7）Value_type（Smallint）。作用，可指本体结构要素对应的值域的类型。取值：3表示类、实例、属性等资源描述、11表示本体内结构要素之间关系的标识，等等。（8）Short_value（Varchar）。作用，本体结构要素的具体描述，及自定或系统内部自动生成的关系描述；取值，本体结构要素的rdf：ID、rdf：resource、rdf：comment等，及ODB表中Frame数值，等。（9）Long_value（Text）。作用，进一步描述类、实例、属性及类型域、值域的内容。
　　小结，Protégé Database将OWL本体中类、实例、对象属性和数据类型属性及其相关约束存储到本体数据库表中，并按Frame、Frame type、Value_type复合键描述军事物流业务流结构要素自身及其关系。特点是：（1）本体结构要素之间关系需递归检索、使用；（2）结构要素约束及其关系“重复”存储；（3）类型标识过于复杂，全面掌握类型标识含义较难，制约了实践应用。因此，Protégé Database适合于本体量少、关系简单的本体应用。
　　3.2 MyEclipse+Jena
　　MyEclipse和Jena API相结合，按照Jena API约定格式，将OWL文件分解为不同数据表，按照本体结构要素的特点组织与管理本体数据。本文选用MySQL作为存储本体的DBMS，利用Jena API持久化文件到数据库。具体步骤：首先，MySQL中创建本体数据库；第二步，在MyEclipse中利用Jena API，装载、分解和持久化本体文件到数据库。代码片段如下：
　　/*利用连接MySQL，事例化hcon，初始化模型制造器1个*/
　　ModelMaker oModelMaker=ModelFactory.createModelRDBMaker（hcon）；
　　/*创建1个默认本体模型，命名为，包含本体数据库表的结构*/
　　Model oModel=oModelMaker.createModel （"Ontology"，true）；
　　/*检测模型是否已经存在，若存在则覆盖或取消*/
　　hcon.containsModel（"Ontology"）；
　　/*建立MLBFSO本体输入流，预备待持久化的数据流*/
　　FileInputStream inputSreamfile=new FileInputStream （new File（"..＼＼MLBFEO.owl"））；
　　InputStreamReader inOStream=new InputStreamReader （inputSreamfile，"UTF-8"）；
　　oModel.read（inOStream，null）； /*关闭输入流读取器*/ in.close（）；
　　/*执行数据转换，将本体数据存入数据库*/
　　oModel.commit（）； … 　　执行完毕后，MyEclipse按Jena API约定格式自动创建陈述表和系统表到ODB内，共7个，示例见表3。其中，陈述表，由存储本体数据的DB表和按需处理后本体数据的DB表组成；系统表用于存储本体元数据和陈述表字节较大的资源DB表，主要包括：存储系统元数据的DB表、存储陈述表中不便于直接存储的长字符常量的DB表< Jena_Long_Lit>；存储陈述表中不便于直接存储的长资源URI的DB表；存储URI的前缀的DB表；存储每一个用户图的名字和唯一标志符的DB表；按需使用的动态表。实际上，存储MLBFSO中的Class、属性及其Class之间关系与约束的ODB表主要是jena_g1t1_stmt、jena_sys_stmt，但实践中发现7个表中不含实例集。
　　小结，基于Jena API约定的ODB表结构，完全按照RDF“三元组”思想，持久化军事物流业务流引擎应用本体。特点：（1）ODB表结构上。Jena API完全按照“三元组”创建与存储本体数据，较Protégé Database表结构简单，易于理解。（2）ODB本体类型标识上。Jena API可认为无整型数字类型标识，是基于资源的，而Protégé Database类型表示复杂，如不同类型本体文件字段标识不同，如RDF和OWL本体文件Class标识不同，等。（3）ODB表记录量上。Jena API生成的ODB记录数量仅是Protégé Database的记录数量的50%。（4）ODB记录查询匹配上。二者均是基于DBMS的递归查询为基，且递归参数属于复合参数，本体结构要素之间的关系不够明了。
　　4 自定制结构建模
　　第3节中，利用第三方工具生成的MLBFEO数据库的数据结构过于复杂，需要对ODB表中字段及其表功用全面掌握才能在实践中熟练应用，因此，本节基于关系数据库（RDBMS）的数据模型，在深入分析文献[3-5]关于ODB建模成果上，结合军事物流业务流引擎结构要素及其业务关系，将ODB表划分为（见图1）：（1）本体元表，主要存储对MLBFEO中的概念、个体、个体之间属性等描述内容的存储，不含类实例。主要包括：本体表_类集（存储本体库中所有Class、subClassof的陈述，不含类之间互斥、相等关系）；本体表_对象属性集（存储类之间的disjointWith、equivalentClass及自定义约束的对象属性，不含子对象属性）；本体表_值域约束集（存储类之间或实例之间的someValuesFrom、allValuesFrom、Cardinality等）；本体表_数据类型集（存储数据类型属性的声明内容，如业务流程名称、业务数据主题名称等数据类型的表）；本体表_数据权限（存储有限的数据元素的CRUDT的权限，如是否可读、是否可写等），等等。（2）本体关系表，主要是：本体表_类约束（存储类之间关系与约束的“三元组”，如disjointWith、equivalentClass、hasDataSet等）；本体表_类与主题数据关系（存储本体类与数据集合[业务数据主题]关系，包括：类标识、数据类型标识、值域约束标识、CRUDT标识等）。（3）实例关系表，以便于实例数据维护与使用，以关系表为主线构建MLBFEO实例ODB表集合，主要包括的数据表：类实例_主表（实例标识、实例名称、类标识[外键，来源本体表_类集]）；类实例_关系表（实例标识[外键]、对象属性标识[外键，来源本体表_对象属性集]、实例标识[外键]）；类实例_数据主题（实例标记，数据类型标记，值域，操作权限）；等。
　　小结，（1）ODB表关系明确。体现了现实世界的实体-联系，MLBFEO结构要素具备完整性约束特点。（2）ODB表结构合理。在充分吸收RDF“三元组”结构基础上，主表均是以类“主+谓+宾”的形式存储数据，提高了MLBFEO可操作性。（3）ODB表检索效率高。不存在递归查询结构，能够充分发挥SQL的效能。（4）ODB表结构易于理解与应用。ODB的表关系、表内字段的设计完全按照RDBMS的完整性约束实施。
　　5 结 论
　　本文为提高MLBFEO的实践维护与应用效益，针对MLBFEO文件的并发与共享性差，以及随本体文件的容量增大、文件增多势必影响对其利用效率与可靠性。基于上述问题，利用Protégé、Jena API等工具将MLBFEO文件持久化到ODB，经实践与分析得：约定结构建模中ODB表问题主要是结构字段标识过于复杂、多标识“递归”查询（并非所有DBMS都支持），不能充分体现MLBFEO结构要素之间的约束关系，需要全面掌握ODB表之间关系及其字段标识，才能够实践应用。
　　本文在分析文献[3-5]数据存储方式的基础上，基于开发者能够全面掌握ODB表结构，易于MLBFE定制的前提下，充分吸收RDF“三元组”（主体、谓词、客体）和RDBMS思想，构建了本体元表、本体关系表、实例关系表等构成的ODB。研究成果为MLBFEO的类、属性和实例的管理与定制，以及基于MLBFE的BMIS开发夯实了数据结构根基。
　　参考文献：
　　[1] 齐继东，等. 军事物流业务流程管控系统初探[J]. 物流技术，2012（2）：213-215.
　　[2] 齐继东，等. 军事物流业务流引擎应用本体研究[J]. 物流科技，2012（10）：84-88.
　　[3] 郭朝敏，等. 一种关系数据库到本体的自动创建方法[J]. 计算机工程与应用，2012，48（7）：115，248.
　　[4] 常万军，等. OWL本体存储技术研究[J]. 计算机工程与设计，2011，32（8）：2893-2896.
　　[5] 林志阳. 基于OWL语义本体的推理与存储研究[EB/OL]. （2008-05-01）[2013-03-15]. http：//wenku.baidu.com/view/Oa946141bele650e52ea9992.html.
　　[6] 齐继东，等. 物流本体数据库的应用研究[J]. 物流科技，2009（2）：63-65.