在文献[2]中,提出了基于Thesaurus与Taxonomy构造分布式本体,并提出全局本体、局部上层本体、局部下层本体的概念及工作机制,设计使用分布式数据库实现。具体思路是：由Taxonomy形成了信息分类号码标识系统,由Thesaurus形成了受控语词（即叙词）标识——主题词标识系统。在文献[6]中讨论了通过自行开发的软件实现从《中国分类主题词表》向全局本体自动转换的方法。

在对《中国分类主题词表》环境类和《环境叙词表》等叙词表扩充概念并建立新概念的过程中,发现原有叙词表概念间关系过于宽泛和模糊,因此在叙词表向本体转换过程中需要对具体概念间关系进行改造与调整。经过对大量数据的处理,总结出概念间关系调整方案,文献[7]中给出了对面向本体与语义网的叙词表概念间关系的改造思路,并建立了新的中文概念间关系草案。

在构建局部下层本体时,采用概念云的思想。概念云由用户检索时提出的检索词（表达一个概念）积累、筛选、精炼产生。此过程在项目组开发设计的基于概念云与本体的信息检索系统IRSCCO（Information Retrieval System based on Concept Cloud and Ontology）中完成。

IRSCCO采用Web2．0环境下的内容管理工具CMS（Content Management System）进行知识概念的管理与组织,用以形成结构化的可关联数据。用标签云、概念云来帮助用户发现与自己兴趣相关的资源,并收集用户对实例标注信息充分发挥大众数据采集方法的优势,将用户的数据收集整合后形成概念,再用作本体更新的下层本体的内容。具体做法是：利用用户提交的信息计算权重,形成标签云,当标签云权重达到一定值时成为概念,形成概念云,这构成了下层本体的内容;当下层本体的概念经过检索系统实际利用后,使用效果达到标准时（即：概念云的权值达到一定时）,进入分布式本体编辑系统ADORES中;在领域专家的干预下进入上层本体库,完成上层本体的更新进化,详细内容参见文献[8]。

本体的构造过程采用自上而下与自下而上两种方式相结合,即用混合的方式构造,可以充分发挥传统信息组织方法的优势,并结合大众对信息资源的标注行为,为本体的更新提供新方法。这从研究方法上也是演绎法与归纳法相结合的方式,符合人类的认知原理及过程,同时也是Web2．0环境下的必然。这是本文及系统设计时的创新点之一。

本文按照新改造的概念间关系,开发了分布式本体编辑系统ADORES来构建分布式本体库,在领域专家的干预下,在实例检索系统中达到一定值的概念云在ADORES系统中经过系统审核、专家认定成为上层本体。在ADORES系统中概念及其关系均可以OWL、SKOS标准描述格式导出,方便不同领域的本体库建设者共享数据,及本体的更新与进化。这是ADORES系统的创新之二。

经过上述几个过程,基于 Thesaurus与 Taxonomy建立了分布式局部上层本体库,项目中实际建成环境类本体库和生物类（部分）领域本体库。

在局部上层本体库的基础上,形成全局本体库,实现分布式环境下的全局本体库的更新一致性。具体分布环境下全局本体库的更新方案：对实时性要求不高的数据,如局部上层本体概念,将分布式数据库的刷新频率设置得低一些;对实时性要求较高的数据,如局部下层本体库数据信息,将其刷新频率设置得高一些。在系统中对于实时性要求最高的内部交流信息,将其设置为立即提交的方式,即使对一个副本的修改都会被命令立即修改其他的相关数据副本。基于分布式数据库实现分布式本体的更新是系统的创新点之三。

随着本体中资源的增加,本体的结构越来越复杂,本体的查询效率成为人们普遍关注的问题。所以,如何合理地存储大规模的本体,支持高效的本体查询是一项很有意义且具有挑战性的任务。现有的本体存储方式大致可以分为两类：基于文件系统的存储和基于数据库系统的存储。

（1）基于文件系统的存储：该方式实现起来比较简单,很多本体相关工具都支持对文件格式的本体进行存取。但是,这种方法不仅效率低,而且很难适应数据量较大的情况。据研究报导,超过10MB的文件运行查询时,查询效率基本上是不可行的,因此对于规模化的本体数据库用文件系统方式存储是不可选的^{[ 9]}。

（2）基于数据库系统的存储：该方式是将本体按照一定的策略组织在数据库中,利用数据库系统对数据的操纵和管理能力来存取本体。与基于文件系统的方法相比,基于数据库系统的方法更适合处理大规模的本体。由于W3C推荐的本体描述语言都是以XML为基础的,因此可以借鉴XML数据在这方面的一些研究成果。目前有三种基于数据库的处理XML数据的方法,即关系数据库的方法、面向对象数据库的方法以及XML数据库（即Native）的方法。由于XML数据库目前仍处于研究阶段,而关系数据库技术比较成熟,应用广泛,效率比面向对象数据库高,并且它的事务系统可以确保操作的正确,无须再重新开发。所以对于规模较大的本体,利用关系数据库存储比较可行。

由于本体模型和关系模型的差异,可以有很多种在关系模型中存储本体的方法。现有的基于关系数据库的本体存储模式都有各自的局限性,不适于存储大规模的本体。大致可分为4种存储模式：水平模式、垂直模式、分解模式和混合模式。

ADORES采用垂直模式和分解模式相混合的方式,将本体信息组织在多张表中使模式结构清晰。模式中每张表的用途划分清晰,而且同一张表中元组的语义清晰,便于在该模式上实现本体的更新和查询,因为在使用关系数据库存储本体后,本体的更新和查询操作都要转换为SQL语句来实现。该存储模式结构稳定,本体中数据的变化不会引起数据库表结构的变化。因为本体是不断进化的,本体中的类、属性、实例的数目都不是固定不变的,如果设计的模式结构会随着本体中这些数据的变化而变化,数据库系统对其维护的代价就很大;而且由于本体的规模是没有限制的,如果设计的存储模式中表的个数或列数会随本体的增大而增多,则当本体增大到一定程度时就会受到数据库在表个数或列数方面的限制,影响了存储的可扩展性。该存储模式支持高效的本体查询,已往关于XML数据存储方面的研究表明,底层的存储对上层的查询处理和优化的性能有重要影响,由于本体中包含大量的数据,无论采用何种存储模式,本体查询都经常需要进行表连接操作,而数据库中表连接的效率较低,尤其是对规模较大的表做连接操作。

ADORES不仅是一个本体存储和查询的平台,而且是融本体开发、维护等功能于一体的一个整合的环境,能够实现OWL和SKOS文件的标准化导出功能等,所以不同于一般的本体工具,ADORES系统设计还要兼顾本体管理功能,尤其是对多用户协同编辑本体的支持。在协同编辑的过程中,开发者在时间和空间上具有分散性,所以会产生多个本体版本,系统可以对这些版本进行有效的管理、归纳并进行统计分析,可以统计出用户对不同版本的支持度,有利于比较和回顾,以便产生最优的发布版本。同时,ADORES能够管理多个分布的不同领域本体,实现同步更新与一致性检查。

在用户管理方面,ADORES支持对开发者进行角色分类,不同角色的开发者具有不同的本体浏览和操作权限。权限越大,能充当该角色的开发者越少;反之,权限越小,能充当该角色的开发者越多。这些开发者之间协同工作,互不干扰。

三层浏览器/服务器（Browser/Server,B/S）模式逻辑上将应用功能分为三层：客户显示层、业务逻辑层、数据层。客户显示层是为客户提供应用服务的图形界面,有助于用户理解和高效地定位应用服务。业务逻辑层位于显示层和数据层之间,专门为实现企业的业务逻辑提供了一个明确的层次,在这个层次封装了与系统关联的应用模型,并把用户表示层和数据库代码分开,同时提供客户应用程序和数据服务之间的联系,主要功能是执行应用策略和封装应用模式,并将封装的模式呈现给客户应用程序。数据层是三层模式中的最底层,用来定义、维护、访问和更新数据并管理和满足应用服务对数据的请求。三层模式有以下优点：

（1）有良好的灵活性和可扩展性。对于环境和应用条件经常变动的情况,只要对应用层实施相应的改变,就能够达到目的。

（2）可共享性。单个应用服务器可以为处于不同平台的客户应用程序提供服务,在很大程度上节省了开发时间和资金投入。

（3）较好的安全性。在这种结构中,客户应用程序不能直接访问数据,应用服务器不仅可控制哪些数据被改变和被访问,而且还可控制数据的改变和访问方式。

（4）增强了企业对象的重复可用性。“企业对象”是指封装了企业逻辑程序代码,能够执行特定功能的对象。随着组件技术的发展,这种可重用的组件模式越来越为软件开发所接受。

（5）三层模式成为真正意义上的“瘦客户端”,从而具备了很高的稳定性、延展性和执行效率。

（6）三层模式可以将服务集中在一起管理,统一服务于客户端,从而具备了良好的容错能力和负载平衡能力。

ASP．NET是一种全新的交互式网页编程技术,是网站和XML Web服务的产物,也是微软公司新的应用开发平台．NET框架中的核心要素。ASP．NET技术把面向对象的编程技术引入Web编程中,使得在编制Web应用程序的时候,就像编制Windows应用程序一样简便快捷。因此,ADORES系统开发采用ASP．NET开发环境。

（1）运行环境

Windows Server 2000（或Windows Server 2003、Windows Server 2008）操作系统;

Microsoft SQL Server 2005;

Microsoft ．NET Framework 2．0 以上版本。

（2）配置Web服务器

使用IIS配置网站,如图1、图2、图3所示。配置站点的根目录web．config文件,修改键值。

图1

	Figure Option ViewDownloadNew Window
	图1 打开IIS

图2

	Figure Option ViewDownloadNew Window
	图2 配置网站路径

图3

	Figure Option ViewDownloadNew Window
	图3 完成IIS配置

（1）不同属性关系的处理

ADORES中概念的属性类型分为对称、可逆、其他三种情况。由于概念本身可以作为其他概念的属性值（也就是说概念和属性值在物理结构上是等价的）,所以为了降低数据的冗余度,本系统在属性的存储方面做了特殊的处理。对称的属性只存储一条记录,但呈现给用户时概念的对称属性值与概念在此属性上互为对方的属性值。可逆属性都是成对出现的,因此存储一条数据后交换概念和属性值就与原属性的逆属性成为逻辑上的另一条数据,为了清晰地展示给用户,在程序中需要做逻辑处理。选取关系插入代码如下：

插入时：

if （relation．简称==＂其他关系＂）//记录其他关系

{

LRL．RelationCategory2 rc=new LRL．RelationCategory2（）;

rc．词1=lblConceptName．Text;

rc．词2=value[i]．Trim（）;

rc．描述=desc[i]．Trim（）;

rc．Add（）;

}

else//记录已定义关系

{

LRL．RelationCategory1 rc=new LRL．RelationCategory1（relation．表名．Trim（））;

if （relation．简称2==att[i]）//逆简称情况

{

rc．词1=value[i]．Trim（）;

rc．词2=lblConceptName．Text;

}

else

{

rc．词1=lblConceptName．Text;

rc．词2=value[i]．Trim（）;

}

rc．关系=relation．简称;

rc．Add（）;

}

（2）用户管理

根据分布式本体编辑的需求,ADORES分为普通用户、专家和系统用户,各种身份的用户功能又有所差异。普通用户可以对概念进行提建议式的编辑,而该级用户对概念的操作并不形成有效数据,而是存储在临时表中等待专家用户审核和采纳。由于概念和属性在数据库中逻辑结构较为复杂,也使该模块的程序实现难度增加。各种类别的属性存储在各自的数据表中,专家每次的审核程序都要对操作的数据进行辨别并按类别归位,因此需提高程序的健壮性。在ADORES中提供高级查询的功能。用户可以在概念、属性、属性值三个关键字段之间根据自己的需要选择任意组合进行查询,程序根据用户的输入情况给出不同的结果。由于概念和概念间关系在数据库逻辑结构上设计的复杂性,特别是专家对概念的删除,需做概念间关系的保护处理。ADORES提供新属性的添加功能。在完成该模块时,除了考虑属性类别的多样性等问题,还得对各关系的OWL和SKOS标签进行添加,为了确定添加属性的合法性,在满足用户需求的情况下对添加属性的类别进行了限制,确保系统的稳定。

（3）概念树形显示

ADORES对顶层概念及其下的概念提供树形查看的功能。采用递归算法以顶层概念为根进行搜索,以折叠树的形式展现给用户,方便用户的查看和对概念的编辑,实现程序如下：

protected void Page_Load（object sender,EventArgs e）

{

SessionRole．Stop（SessionRole．Role．User）;

if （！ IsPostBack）

{

try

{

string aa=Request．QueryString [＂concept＂]．ToString（）;

TreeNode ttn=new TreeNode（aa）;

TreeView1．Nodes．Add（ttn）;

LRL．RelationCategory1 rc=new LRL．RelationCategory1（＂属分关系＂）;

foreach （DataRow dr in rc．GetList（＂词1=′＂+aa+＂′＂）．Tables[0]．Rows）//遍历显示第一层子概念

{

TreeNode tn=new TreeNode（dr[＂词2＂]．ToString（））;

tn．Target=＂_blank＂;

tn．Expanded=false;

tn．NavigateUr1=＂Concept．aspx?concept=＂+Server．UrlEncode（dr[＂词2＂]．Tostring（））;

ttn．ChildNodes．Add（tn）;

AddNode（dr[＂词2＂]．ToString（）,tn）;//开始递归逐层显示概念

}

}

catch

{

Response．Write（＂参数错误！＂）;

}

}

}

private void AddNode（string word,TreeNode tn）

{

LRL．RelationCategory1 rc=new LRL．RelationCategory1（＂属分关系＂）;

DataTable dt=rc．GetList（＂词1=′＂+word+＂′＂）．Tables[0];

foreach （DataRow dr in dt．Rows）//遍历显示下层子概念

{

TreeNode tn1=new TreeNode（dr[＂词2＂]．ToString（））;

tn1．Target=＂_blank＂;

tn1．NavigateUrl=＂Concept．aspx?concept=＂+Server．UrlEncode（dr[＂词2＂]．ToStridng（））;

tn1．Expanded=false;

tn．ChildNodes．Add（tn1）;

AddNode（dr[＂词2＂]．ToString（）,tn1）;//继续递归

}

}

}

（4）OWL和SKOS文件的导出

ADORES还提供导出OWL和SKOS文件的功能。这两种都是规范的XML文件,属于各自定义的命名空间。由于各概念的属性差别很大,导出程序必须对各属性进行合法判断,以免导出错误标签和空标签。导出的文件分为按概念导出和按顶层概念导出树形结构的数据,用户可以方便地下载文件到本地磁盘,方便进行数据转换和数据交换。其SKOS导出部分代码如下：

＃region skos操作

private DataTable GetSkos（string w）

{

＃region显示属性

DataTable RelationShow=new DataTable（）;

DataColumn dc=new DataColumn（＂concept＂,typeof

（string））;

RelationShow．Columns．Add（dc）;

dc=new DataColumn（＂label＂,typeof（string））;

RelationShow．Columns．Add（dc）;

dc=new DataColumn（＂ProfessorId＂,typeof（string））;

RelationShow．Columns．Add（dc）;

dc=new DataColumn（＂UpdataDate＂,typeof（string））;

RelationShow．Columns．Add（dc）;

LRL．Relation rl=new LRL．Relation（）;

DataTable dt=rl．GetRelTable（）．Tables[0];

ArrayList al=new ArrayList（）;

LabelShow ls=new LabelShow（）;

foreach （DataRow dr in dt．Rows）

{

if （dr[＂表名＂]．ToString（）==＂其他关系＂）

continue;

DataTable dt2=LRL．DbHelperSQL．Query（＂select＊from＂+dr[＂表名＂]．ToString（）+＂where 词1=′＂+w+\′＂or 词2=′＂+w+＂′＂）．Tables[0];

foreach （DataRow dr2 in dt2．Rows）

{

if （dr2[＂词1＂]．ToString（）==w）//概念是词1情况

{

if （dr2[＂叙词表词间关系＂]==null） continue;

DataRow drr=RelationShow．NewRow（）;

drr[＂concept＂]=dr2[＂词2＂]．ToString（））;

if （ls．GetSkos（dr2[＂叙词表词间关系＂]．ToString（））！=null）

drr[＂label＂]=ls．GetSkos（dr2[＂叙词表词间关系＂]．ToString（））;

else

continue;

if （dr2[＂ProfessorId＂]！=null）

（drr[＂ProfessorId＂]=dr2[＂ProfessorId＂]．ToString（）;

if（dr2[＂UpdataDate＂]！=null）

（drr[＂UpdataDate＂]=dr2[＂UpdataDate＂]．ToString（）;

RelationShow．Rows．Add（drr）;

}

else//概念是词2情况