基于本体的语义信息模型的验证方法

一、先简单说说整个的一个需求吧

广义的配电管理系统(DMS)涵盖配电网生产、运行和服务全过程,是整个电力企业信息集成系统的一个有机组成部分。DMS 包含着大量应用系统,由于现在配网一体化和智能化发展的要求,需要这些应用系统之间能够相互的进行数据交换(实现系统间的互操作如下图),但这些大量的系统由于开发时间和功能的不一致,造成了这些系统和相应的数据库采用了不同的接口标准和模型,相对独立,不可避免的造成信息重叠和“信息孤岛”,无法实现全局范围内的信息交互和信息共享。

目前,整个电网对此的解决方案是构建基于 SOA 的电力企业服务总线(ESB),它是基于IEC61968提出来的。这种设计为电

力企业的信息集成提供了信息机交互的可能性,从体系架构的级别保证了整个系统的松耦合性和灵活性。IEC 61968 采用基于公共信息模型(Common Information Model,简称 CIM)的消息交换机制,对配电企业中的信息模型进行扩展,包括资产、用户、工作、文档等部分,制定资产管理系统、工作管理系统、施工管理、配电网管理、停电管理等业务功能的接口消息规范 XSD(XML  Schema Definition),在消息总线上通过标准消息的传递,实现了各业务功能系统间的数据交互。但在此工程中,出现了如下问题:

1 公共信息模型(CIM)随着需求的不断提升,版本更新频繁,各厂家的产品在版本上不易保持同步,使模型语义上的差异。

2 不同应用或企业间可能需根据内部需求,对 CIM 模型做相应的扩展,那么私有扩展模型可能导致应用间的语义难以辨识。

3  信息总线上传递的消息(XML)可能未按照统一消息规范 XSD 来封装,导致消息无法正确解析,业务数据难以获取。

上述三点会直接造成信息交互失败,因此为实现消息的正确获取以及模型的一致性解析,需要研究基于 IEC 61968 标准的信息模型及消息类型的维护与验证方法,以利于多厂家、多系统间的信息集成与交互,从而为建设坚强统一的智能配电网打下坚实的基础。

二、验证的思路

验证的层次有两个:消息一致性验证和模型一致性验证

1消息一致性验证

(1)主要包括两个方面:消息封装一致性和消息格式一致性。消息一致性测试包括消息信封头定义、消息头部分测试、请求组件部分测试、消息体部分测试。

(2)主要采用的方法是XSD(xml schema)-->XML的校验

2模型一致性验证

(1)采用基于本体OWL 的信息模型验证方法,基于公理来描述类和属性的特征及相互关系,通过推理机制来实现一致性测试

(2)模型验证首先是通过解析 CIM/XML,抽取该数据模型的元数据信息,并将其与基于本体描述的语义模式做比对,该语义模式可以是基于标准 CIM 及其扩展的全模型,也可以是统一配置的子集 Profile,具体模式结合实际应用。原理如下:

(3)具体的算法和流程最核心的部分是基于本体的验证,流程如下图所示:

三、项目是基于java的,所以具体的开发基于JENA,具体后面在详说,JENA部分我也是去官网看到,地址:http://jena.apache.org/

时间: 2024-10-13 20:01:55

基于本体的语义信息模型的验证方法的相关文章

基于本体的地学数据语义检索(简介)

硕士期间做了基于本体的地学数据语义检索方面的工作,首先是传统的全文检索查询600Ma(Ma表示百万年,这里都是指百万年前): 然后是基于本体的语义检索查询结果:(600Ma处于震旦纪.下震旦世.元古宙等地质年代时间内) 具体方法会在论文中论述,此处省略4万字...(请不要打脸)

基于本体概念的语义相似度计算

最近在做基于本体概念的语义相似度的计算理论研究及实现,现在做一个相关的总结,以便今后查找或者供他人借鉴和学习. 做这个研究的目的是为了进行Agent能力模型中目标和能力的匹配,从而进行目标对能力的一个择优过程.在我们的能力模型中,capability表示为C(InConstaints,OutContaints),目标goal表示为G(TriggerConditions, FinalStates).而InConstaints,OutContaints,TriggerConditions, Fina

基于 Token 的身份验证方法

使用基于 Token 的身份验证方法,在服务端不需要存储用户的登录记录.大概的流程是这样的: 客户端使用用户名跟密码请求登录 服务端收到请求,去验证用户名与密码 验证成功后,服务端会签发一个 Token,再把这个 Token 发送给客户端 客户端收到 Token 以后可以把它存储起来,比如放在 Cookie 里或者 Local Storage 里 客户端每次向服务端请求资源的时候需要带着服务端签发的 Token 服务端收到请求,然后去验证客户端请求里面带着的 Token,如果验证成功,就向客户端

四种表单验证方法的分析和比较

前言 任何可以交互的站点都有输入表单,只要有可能,就应该对用户输入的数据进行验证.无论服务器后端是什么样的系统,都不愿意把时间浪费在一些无效的信息上,必须对表单数据进行校验,若有不符合规定的表单输入,应及时返回并给出相应的提示信息.本文将列举四种不同原理的表单验证方法,并给出各方法在 PHP 服务器上的实现. 回页首 浏览器端验证 传统上,表单数据一般都通过浏览器端的 Javascript 验证.浏览器端的验证速度快,若有不符合要求的输入,响应信息快速的返回给用户.由于验证数据不需要提交给服务器

基于jQuery的Validate表单验证

表单验证可以说在前端开发工作中是无处不在的~ 有数据,有登录,有表单, 都需要前端验证~~  而我工作中用到最多的就是基于基于jQuery的Validate表单验证~  就向下面这样~ 因为今天有个朋友问我要一个表单的验证,所以我就稍微整理了一下~  基本上有了这个表单验证插件,基本上一些常用的验证都可以搞定了~ 如果搞不定,没关系,我们还可以基于Validate来写一个自己的验证插件, 我把它取名为message_zh.js,我们可以在里面扩展自己需要的验证~~ 既然Validate是基于jQ

哪一种验证方法最好?形式验证、硬件加速还是动态仿真?

关于最佳的验证方法,最近总能在各种文章中看到.这里希望以一些新的视角来看待这些问题.所以根据一些EDA公司代表对相关问题的回答,总结出本文. 受邀回答问题的代表有:Steve Bailey,Mentor Graphics公司新兴技术总监:Dave Kelf,OneSpin解决方案营销副总裁:Frank Schirrmeister ,Cadence高级产品管理总监:Seena Shankar,Silvaco的技术营销经理:Vigyan Singhal,Oski技术总裁兼首席执行官 :Lauro R

「深入 Exchange 2013」02 CAS的身份验证方法

在上一篇咱们聊了一下CAS的架构,这一章就来聊聊CAS的验证方法 很多管理员从未纠结过客户端的验证问题,因为Exchange的默认设置在单一环境中完全够用了.当拓扑变得更复杂,环境中开始出现一些其他版本的Exchange时候,就得重视起这个玩意. 选择验证方法的重要性在于,其他的服务器都指望着着CAS角色发送过来的请求符合特定的验证方法.如果用户的邮箱处于Exchange2013的MBX上,那么CAS可以直接将请求代理给HTTP代理终结点,如果处于Exchange2007的或者是Exchange

基于CCA的fMRI信号生理噪声抑制方法

第三章 基于CCA的fMRI信号生理噪声抑制方法 3.1 引言 典型相关分析作为一种多元变量相关分析方法,可以用来提取出自相关的信号子空间,因而被广泛地用来做激活信号的提取及噪声成分的估计[48][55].基于CCA,Churchill等人[10]提出了对fMRI残差数据做成分分解,进而估计出具有自相关特性的生理噪声成分,并在真实数据集上取得了较为显著的噪声抑制效果.但该方法需要先知道实验的刺激范式作为先验知识,然后去除fMRI信号中刺激范式相关的成分以得到残差数据.这里对功能信号与噪声信号进行

基于Jquery Validate 的表单验证

基于Jquery Validate 的表单验证 jquery.validate.js是jquery下的一个验证插件,运用此插件我们可以很便捷的对表单元素进行格式验证. 在讲述基于Jquery Validate的表单验证前,我们先回顾一下基础纯JS的表单验证. 1.回顾基于JS的表单验证 我们先写一个简单的验证邮箱.手机号的表单,页面代码如下: 1 <form action="XXXX.action" method="post" onsubmit="r